1. デブログ.fm - AIで生産性を上げるエンジニアログ
  2. AIコーディングを「社長視点」..
AIコーディングを「社長視点」で回すには?Loop Engineering解説
2026-07-10 25:11

AIコーディングを「社長視点」で回すには?Loop Engineering解説

デブログfmは、現役エンジニアのinadyが、日々の業務で試したAI活用術や最新ツール、効率化のノウハウをシェアします。https://podcast.devlog.fm


番組の感想やリクエストは #デブログfm まで。番組のフォロー、星★(レビュー)いただけると嬉しいです!


▼参考資料▼

Loop Engineering(Claude Code Xポスト)

https://x.com/ClaudeDevs/status/2074208949205881033


▼取り上げた話題▼

7月7日に開催されたながらAIのオフ会に参加し、同じコンテキストを共有できるコミュニティの面白さをレポートします。続いて月額1.99ドル(キャンペーン時)のClinePassを試した所感として、DeepSeek・GLM・Kimiなどのオープンウェイトモデルが使える一方、利用上限が早く来ること、同じGLM 5.2でもCursorよりハーネスが弱いことを紹介します。メイントピックはLoop Engineeringで、ターンベース・ゴールベース・時間ベース・プロアクティブの4種類のループをClaude CodeのXポストをベースに解説します。ループを回すには終了条件のスキル化、コードベースの整理、CLAUDE.mdやSkillsでの業務明文化、サブエージェントによるコードレビュー、TDDの徹底が重要です。結論として、人間がボトルネックにならないよう大企業の社長のように委譲し、介入すべきポイントだけに集中する考え方を提案します。


▼チャプター▼

オープニング

ClinePassの料金と使えるモデル

ClinePassのハーネスと限界

Loop Engineeringとは

ターンベースループ

ゴールベースループ

時間ベースループ

プロアクティブループ

ループを回すための基盤

人間をボトルネックから外す

クロージング

感想

まだ感想はありません。最初の1件を書きましょう!

サマリー

本エピソードでは、AIコーディングのエキスパートであるinady氏が、AIを活用した開発手法「ループエンジニアリング」について、社長視点での考え方を解説します。まず、月額1.99ドルで利用できるAIコーディングツール「ClinePass」のレビューから始め、その利点と限界について考察します。続いて、AIコーディングにおける4つのループ(ターンベース、ゴールベース、時間ベース、プロアクティブ)を詳細に説明し、それぞれの特徴と活用法を紹介します。最終的に、人間がボトルネックにならないよう、AIに作業を委譲し、重要な判断に集中する「社長のような」アプローチを提案し、AI開発の効率化と高度化を目指します。

ながらAIオフ会参加レポート
このポッドキャストを聞いている方だったらご存知だと思いますが、Nagara AI というAIに関する話題を取り上げたポッドキャスト番組があります。
こちらは、ハヤカワゴミさんとウスタクさんという2人がやっているポッドキャストですけれども、こちらのオフ会が先日7月7日に行われまして、そちらに行って参りました。
非常に楽しかったですね。生ウスタクさん、生ハヤカワゴミさんと握手をさせていただいて、公開収録を聞かせていただいて、裏話なんかも聞けて非常に楽しかったです。
この会場にいる皆さんと同じ空間でこのポッドキャストを聞けたというのは非常に面白くてですね、
例えばフェーブル5の話題だとかGPTのソルがもうちょっとで出るんじゃないかみたいな、同じ話題で盛り上がれる環境って非常に面白いなというふうに思いました。
世の中一般的な人は多分フェーブル5がとかGPTのソルがって言っても、一体何のことだとその前提から話さないといけないっていうのがあると思うんですが、
ここに会場に来ている人はみんなそれを知っている前提でお話を聞いているので、そのコンテキストを共有した状態で、その面白さと分かった上で聞いて、同じところで笑える、同じところで納得できるみたいなところが非常に面白いなというふうに思いました。
また機会があれば行きたいなというふうに思っております。
またこの公開収録、ながらAIのオフ会を聞いて、私もポッドキャストを改めて頑張ろうかなというふうに思ったところでした。
ClinePassのレビューと考察
それでは今日のメインのトピックに行こうと思うんですが、ごめんなさいもう一個別件を話したいというふうに思っております。
今日はループエンジニアリングについて話してみようと思うんですが、その前にちょっとだけ最近やったことについて話そうと思います。
それはCラインパスについてですね。
Cラインパスっていうのは、まあそもそもCラインっていうのはクロードコードとかコーデックスみたいに、いわゆるターミナルでコーディングエージェントを開いて何かパチパチってプロンプトを打って、
あとは事実的にコードを書いてくれたりとか何かツールを呼び出して作業してくれるっていうそういう開発環境みたいなものですが、
そのCラインが提供したサブスクですね。クロードコードもサブスクがありますし、GPGのコーデックスもサブスクがあると思いますが、
それと同じような形でCラインパスというサブスクが開始されました。料金は9.99ドルですね。めちゃめちゃ安くて、
かつ今キャンペーン中で、ちょっといつまでやってるか、ごめんなさい、把握してないって恐縮ですが、キャンペーン中は1.99ドルで月当たり使えます。
日本円にすると300円ちょっとですね。信じられない金額ですよね。
例えばクロードコードのプレミアムプランとかだと100ドルを超える金額ですが、キャンペーン期間中だと大体2ドルぐらいで使えますということで、すごい安いですよねっていうところなんですが、
使えるモデルは、例えばDeepSeaとかGLMとかKimiみたいに、基本的には中国系のオープンウェイトモデルが基本的ですね。
使ってみた感想なんですけれども、まずリミットは結構すぐ来ます。
イメージするとクロードの一番安いプランでソネットを使ってた時に、結構もう来ちゃったなみたいなイメージあると思うんですけど、それと同じぐらいですね。
メインで使ってゴリゴリ使ってしまうと結構すぐリミットに来るかなっていうところがあるので、
キャンペーン中1.99ドルとはいえ、プラスで重量課金する必要があるかなというふうに思います。
もう1個気になった点が、ハーネスがちょっと弱いかなというふうに感じたところです。
私がメインで今回使ったのはGLMの5.2っていうモデルなんですけれども、これは非常に性能が高いと安くて性能が高いという話題ですが、
このGLM5.2をCラインで使った時とカーサーで使った時で試したんですね。
カーサーでもいろんなモデルが選べるので、それで全く同じモデルにしてやってみたんですが、
10点満点でスコアリングした時に、CラインでやったGLM5.2が6点だとすると、カーサーでやると6.5点とか7点ぐらいまでのスコアのアウトプットが出てくるんですよね。
これはモデル自体は同じで、F4とかもどっちもMAX、一番上のF4でやった結果、いろんなタスクを試したんですけど、どれをやってもだいたい一段上ぐらいの性能が出るんですけど、
これはやっぱりカーサーが持っている、どういうふうにモデルの力を最大限に使うかというシステムプロンプトとか、その周辺のツール群の差だというふうに思うんですよね。
なので、そこがちょっと弱いなというふうに感じたというのがまず1点目と、
あとは、Cラインは単純にコーディングツールとしてだけ提供されているんですが、最近のクロードとかカーサーってそれだけじゃないですよねっていうのは改めて気づきました。
例えば、クロードでいうとクロードデザインとかクロードタグとか、あとはアーティファクトとかありますし、カーサーであればバグボットもあるし、クラウドエージェントもあるし、
例えばアプローブエージェントみたいなものがある中で、単純にAIコーディングツールだけだとすると、安いとはいえこれだけでなかなか完結とは言えないかなというところがありました。
ではどういう人がこのCラインパスを使えばいいかというと、メインでなることはないかなというふうに思っていて、
例えばですけど会社がAIツールにお金を出してくれない、自分のポケットマネーでなんとかやらないといけない、でもあんまりお金は出せないという時に使うであるとか、
あとは例えば会社ではクロードとかカーサーとかを契約しているんだけど、個人で何か使う時にできるだけ安く済ませたいという時に使うのがおすすめかなと思っていて、
いずれにせよ積極的に使う必要もないかなというところが私の結論です。
最新の中華系のモデルを使いたいのであれば、カーサー経由で全然やれば十分かなというところですし、
例えばカーサーを契約していなくてですね、それでも最近のオープンメイドモデルを試しにちょっと使ってみたいっていう用途においてはいいのかなというふうに思いますが、
それをやる場合においてもハーネスの差があるというところはちょっと認識しておかないといけないかなというところを付け加えておきたいと思います。
ループエンジニアリングとは
では今日のメイントピックについてです。ループエンジニアリングについてですね。
最近巷で、巷ってよく言うんですけど、なんでしょうね巷って、Xタイムライン巷ですけれども、巷ではループエンジニアリングが話題になってきておりまして、
いろんな記事とかYouTube動画とか見てきたんですけれども、クロードコードが一個ですね、Xにポストしている記事がありまして、これが一番しっくりきたので、
これをベースにちょっと解説というか、私の何の考えというところを解説してみたいというふうに思っております。
このXのポストについては概要欄にリンクを貼っておきますので、合わせてみていただければと思いますが、
ではいきましょう。まず一つ目がターンベースループというやつですね。
これは今までのコーディングエージェントの使い方と一緒だと思ってもらったらいいと思うんですが、
何かユーザーがプロンプトを渡して、これやってほしいというふうに渡して、それをクロードコードとかが、なるほどそうだねってやってコードを書いて、
レビューしてCI回して、最終的にできましたと返ってくるというやつが、まずターンベースのループですね。
それでこのループについてはあんまり強く言及することはないんですけれども、この記事で書かれていたことで言うと、
ちゃんと終了条件を決めて、どういう状況だったらこの作業が終わるかというのをしっかりスキルにしておきましょうねということが書いていました。
例えば、バックエンドの解決をしているのであれば、CIがパスしますとかセキュリティの問題がないです。
E2Eテストをして、そこまでやったら完了ですというのをスキルにまとめておいて、それを自律的にコーディングエージェントにやってもらって、
それが終わったら終わりですというふうにしないと、プロンプト投げて帰ってきたものが、いやそうじゃなくてまずテストしましょうねとか、
それはまた帰ってきて、次はE2Eのテストしてくださいとか、一個一個回していたらループが回っていかないので、
こういう状況になるまでやり続けてくださいっていうのをスキルとして定義しておくってところが大事です。
ゴールベースループ
次がゴールベースループですね。これはクラウドコードのスラッシュゴールってやるとやれるやつなんですけど、
やらなくても同じようなことは動いてくれますけれども、何かというとこういう目的を達成するまでやってくださいっていう指示ですね。
例えばスラッシュゴールこのホームページのライトハウスっていう画面の描画スピードを測る仕組みがありますけど、
そのスコアが90点以上になるまで続けてくださいと。それが最大5回まで試していろいろ試行してやってくださいみたいな指示ですね。
これは具体的にこのコードを修正してくださいって具体の指示をしているわけじゃなくて、ゴール設定をしているだけですね。
こういう結果になったら終わりです。ここまでやったら途中でやめてくださいっていう指示をしているだけで、
それを聞いたコーディングエージェントはそれを踏まえてどういうふうにやればいいかっていうのをやってみて、
今回で言うとライトハウスのスコアが90点になったか。いや、なってないな。じゃあ次他のことやってみよう。やってみた。
まだ85点だ。もう1回やってみよう。やっている次に5回になっちゃった。でも89点だ。でも5回って言われたからこれで終わりましょう。
ループが終わるみたいなのがゴールベースのループですね。
さっきのターンベースループに比べてループの回数が多いであるとか、こうなったらこの作業は終わりですってゴール設定をするっていうところがさっきのやつとの違いかなというふうに思います。
加えてこのスラッシュゴールっていうのを使うと非常に便利で、何か作業しますよねって言って、
1ループ回った後にサブエージェントが回るんですよね。で、サブエージェントがこれってちゃんとユーザーが示したゴール条件に達成したかっていうのをチェックして、
通ってなかったらもう1回ループを回す。で、もう1回ループ回って評価の時に来たらまたサブエージェントが動いてどうかとかチェックするみたいな、
ちゃんとゴール条件に達成したかっていうのを評価して回して評価して回してっていうのが勝手に動くようになるので、このスラッシュゴールっていうのを使った上でゴールベースループをやると非常に便利かなというふうに思います。
時間ベースループ
そして次が時間ベースのループです。これはクロードコードで言うとスラッシュループとかスラッシュスケジュールみたいなやつですけれども、
私がよくやるのはスラッシュループ5分、私のプルリクエストをチェックしてCIがパスしていることを確認してパスしたらマージしてくださいみたいなやつですけれども、
これはプロンプトとしてはどういう時間ベースでどういうことができるかを確認して、それが終わったらこうしてくださいっていうCGを回すっていうやつですね。
それでこの時間ベースのループというのはさっきのゴールベースとちょっと違って、ゴールって何か目的があってその目的達成するまでやるってやつですけれども、
この時間ベースっていうのは5分後とか10分後とか毎日9時にとかそういった時間でループを回すっていうイメージですかね。
もう一個例で言うとスケジュールっていうものがありますけれども、毎朝4時になったらこのスラックチャンネルを見て、
イシューがあるか確認して、イシューがあればチケット化するみたいなそういったやつですけれども、
これもほとんど人間が介在することなくループが回る仕組みなので、これは非常に強力かなというふうに思っております。
それで例えばですけれども、アプリリクエストをコーディングエージェントに書いてもらって、
CIがパスしたかなってGitHubを見に行って、まだパスしてないやって言って、
また他の作業をして、また見に行って、CIパスしてた、失敗してた、修正しようって言って、またコーディングエージェントにやってもらって、
もう一回プッシュして、レビューを依頼して、また30分後に見に行って、アプローブされたかなって見に行ってって言って、
非常に無駄だし、人間がすごく介在してますよね。
それをやめるだけでも非常に精査性上がっていくなって私自身も思っている、体感しているので、
このループっていうのはどんどん取り入れて、いかに自分が定期的にチェックしているみたいなことがあれば、
もうすぐスラッシュループにしてしまってもやってもらうみたいなことを積極的にやっていくといいんじゃないかなというふうに思います。
プロアクティブループ
そして最後に紹介するのはプロアクティブループですね。
これは本当にここまでできたらすごいなという感じではあるんですけれども、
イメージとしては、プロンプトのイメージで言うと、
例えば毎時間このスラックチャンネルをチェックしてバグレポートがあるか確認してくださいと。
バグレポートがあったものはそのバグが解消するまで作業をして、
それが終わったらアプリリクエストを投げてレビュー以来まで出してくださいっていうのを毎時間やってくださいっていうやつですね。
これはほぼほぼユーザーが介在することなくですね、
もちろんこの実装でいいかみたいなアスクユーザークエッションされることはあるかもしれないんですけれども、
勝手に毎時間スラックチャンネルを見てバグがあるか確認して修正してプリクを出してみたいなのを、
ずっとずっと勝手に回り続けるみたいなことが例ですね。
ここまでできると本当にすごいんですけれども、
ここまでできる例っていうのは正直そんなにないかなっていうところでもあります。
このループを作る時のコツなんですけれども、
まずこのループのスタートラインは自動化しないといけない。
ユーザーからこれやってって言うとそれループ閉じてないので、
例えばスケジュールとかで毎時間見てくださいとか毎朝9時に見てくださいみたいな感じで、
ユーザーが何か指示しなくてもこのループがスタートするようにした上で、
かつゴール設定をしてこういう状態になるまでやり続けてくださいという風にやって、
またそのゴールが達成するまでで別のループが回りますよね。
ループが回った上で、かつスキル図も設定しておくんですね。
一番最初に話したターンベースのループでも話したやつですけども、
こういう状態になったら終わりですよ。
CIが回って、いついいテストやって、プリクを出して、レビューラーを出すまでか、
完了条件ですみたいなスキル図を用意しておいて、
それもやってもらうという風にすると、
いちいちユーザーに確認することもすごく減るので、
そういった工夫をした上でこの閉じたループを作りましょうというのが最後のループですね。
プロアクティブループと言いますけれども、それをやりましょうという話です。
ループを回すための基盤
ということでループいくつか説明していきましたけれども、
もうちょっとその基盤となる考え方というか、
それをループがちゃんと回るようにするにはどうしたらいいかというところを付け加えると、
まず当たり前のことではあるんですけど、コードベースをきれいにしましょうということですね。
同じロジックがいろんなところに書いてたりしたら、
これどういうことだってエージェントも迷ってしまうので、
コードベースをきれいにしましょうというところもそうですし、
あとはクロードコードに自分がやりたい業務っていうのをちゃんと名分化して渡すということですね。
例えばスキル図にしておくとかクロード.mdにしておくみたいな形で、
自分がどういうことをやっていて、このプロダクトが何でどういうことを気をつけてやらないといけないのかっていうのを渡しておかないと
AIも判断することができないのでそういうことをやりましょうということと、
あとはコードレビューをするみたいなときに、
メインのエージェントでやってしまうと自分で書いたコードを自分でレビューするので、
バイアスがかかってるんですよね。
なのでコードレビューをするときはサブエージェントを呼び出してやりましょうということを
ちゃんとクロード.mdとかスキル図に書いておきましょうっていうのが大事ですね。
クロードコードで言うとスラッシュコードレビューっていうスキルがビルトインでされていると思うんですけど、
これを呼び出すとサブエージェントが起動してそれでコンテキストを1回なくした状態で
このコードが正しいかどうかっていうのをチェックできますし、
例えばカーサーで言うとバグボットとかでコードレビューすることができるので
そういったものを使って別エージェントでレビューを回しましょうというのが大事ですね。
最後にテストをちゃんと書きましょうっていうところも大事で、
コーディングエージェントって何か答えがある状態で書くとすごく強いんですよね。
ただコードってあまり答えがある状態のものではなくて
こういうことを達成したいっていうふわっとしたものを実装しなければいけないので
そういうこれが正しいのが正しくなるのかって判断するのは非常に難しいんですけれども
テストを書いておけばコードを実装したものがテストが通ればいいし
通らなかったらダメだっていうことが非常にわかりやすくて
ループが回りやすいので必ずテストを書きましょうっていうところが大事で
とりわけですね、TDDという開発スタイルがありますけれども
それをやってくださいっていうのをちゃんとクロード.mdに書いておくということですね。
具体的にはレッド・グリーン・リファクターでやりましょうっていうことをちゃんと書いておくということで
まずレッドっていうのはまずテストコードを書きましょうとコードを実装する前にで
その状態でテストを実行したらもちろんコードを実装してないので失敗しますよね
レッドですよねっていう状態で
次は実装して実装してもう一回テストを回したら
ちゃんと実装してたらグリーン要はテストがパスしました
テストやったけどまだレッドだったらまだ実装が間違ってるからまた再実装させて
みたいなことが時々的にもあると
最後にリファクタープロセスも入れないといけなくて
結構このレッド・グリーンをやるときに色々試行錯誤してコードがだんだん汚くなっていくんですよね
それを防ぐためにレッドでグリーンでコードが動くってなったら
リファクタリングコードをきれいにするっていうのを
自動的にやってくださいっていうのをエージェントに入れておくことによって
コードベースがきれいでかつゴール設定もあって
テストケースもあってみたいなところが作ることができるので
TDDテスト駆動は開発でやりましょうというのが非常に大事な観点です
人間をボトルネックから外す(社長視点)
ということでここまでエージェントループについて話してきたんですけれども
結論から言うといかに人間をこのループの外に出すかというのは非常に悲しいことであるんですけど
人間が一番ボトルネックで人間が支持しないとエージェントって動かないですよねっていう
当たり前のことをいかに排除して
人間がいない状況でいかに物事を前に進めるかっていうところが大事
自分がいかに介在しないで勝手に動かすか動くかみたいなところを考えるっていうのが非常に大事ですね
これを人間社会に例えるとすっごい大企業の社長みたいなイメージかなというふうに思っていて
この社長が例えば本当プレイング社長で自分で何か資料も作れば何かスケジュール調整も自分でしてみたいな場合って
なんかやってる感はあるかもしれないですけど会社の規模感からすると
いやそれあなたの仕事じゃないでしょうとかそれで会社って回るんですかみたいなことが起きますよね
そうじゃなくて大きい会社の社長っていうのはちょっと私大きい会社の社長やったことないので非常にバイアスがかったイメージであるんですけれども
いかに権限とか作業を部下部署に移情するかみたいなそれのスキルだと思うんですよね
なので自分で例えばスケジュールをやるんじゃなくて師匠をつけて師匠にそれをやってもらうとか
自分でリサーチをするのではなくてマーケティングチームみたいなのを作ってそのマーケティングチームの部門長に依頼をしてやってもらうみたいなことで
社長は何をするかというとすごい極端なこと言うと5分おきに会議設定があって
でその案件の部門長がこうやってきてこういうのやってるんだけどどうですかイエスノーで教えてくださいみたいな
これはイエスで次のまた案件がやってきてまたその部門長がいろいろ説明してそれはノーだな
こういうふうにやったらどうだみたいなことをアドバイスしてまたやってきてもらう
他のシーンで言うと今期の中期今期の売上目標はこれぐらいにしようというゴール設定をするとか
そういったことをやるんじゃないかなと社長は勝手に想像してるんですけど
それとこのエージェントループを回すということはほとんど同じかなというふうに思っていて
例えば今期10期の売上目標立てるみたいなのはさっき言ったゴールベースのループと同じですし
あとはその時間ベースのループで言うと毎日9時にそのスラックを見てみたいなやつ例で言いましたけど
それって例えば会議設定で毎週火曜日の10時からマーケティングチームとのミーティングがあるみたいなこれまさにスケジュールですよね
そこでミーティングをしてイエスの判断してじゃあまた1週間勝手にやってきてねって言ってまた次の週にやってきて
イエスの判断したり指示をしたりみたいなことをするみたいな
このまた来週って言ってる間って何も動いてないわけじゃなくてその部署の人がけんけんガクガクいろいろやってるわけですよね
でもそれでも会社が回っていて仕事が前に進んでいるっていうのはこのエージェントループと全く同じ話かなというふうに思っているので
このループっていうのを考え方イメージがちょっと難しいのであれば
自分が社長だとしてこれ大きい会社のすごい大企業の社長だとしてこの作業って自分でやる必要があるのかとか
部下に任せる部下っていうのはこのエージェントのことですけどもエージェントに任せるべきなんじゃないかということを
常に考えると自分がいかにボトルネックにならないで
でもとはいえ自分を全部排除しまったら自分の存在価値がなくなっちゃうので
社長もそうだと思うんですけれどもここぞっていう時は自分が介在してガッとやらないといけないわけですよね
ここぞっていう時に時間をとっておくために他の余計な作業をやってもらう
ここぞっていうのはどこかっていうのをちゃんと理解しておいて
そこはちゃんと介入してエージェントに指示するみたいなことを回すということが非常に大事なのかなというふうに改めて思いました
クロージング
ということで今回はながらAIのお伝えに行きましたよとかCラインパスとかいう話をしまして
最後にループエンジニアリングについて話をしてみました
参考になったら幸いでございます
ということで最後に番組の紹介をさせてください
この番組Devlog FMはYouTube Apple Podcast Spotifyなどで配信しております
ご感想リクエストなどもしございましたらハッシュタグDevlog FMでつぶやいていただくか
概要欄のフォームコメント欄よりいただけますと幸いです
またサブスクライブチャンネル登録もぜひよろしくお願いいたします
それでは次回の配信でお会いしましょう
ご視聴ありがとうございました
25:11

コメント

スクロール