ループエンジニアリングとは？　チャットとAIコーディングの往復から卒業する新しい開発スタイル：Deep Insider Brief ― 技術の“今”にひと言コメント

AI開発で人間がプロンプトを書く時代は終わるのか。ループを回してAIエージェントを動かし続ける新概念「ループエンジニアリング」の基本を、提唱者の記事に沿って解説。チャットAIとAIコーディングの往復から卒業したい筆者の考えも示す。

» 2026年06月23日 05時00分公開

[一色政彦，デジタルアドバンテージ]

この記事は会員限定です。会員登録（無料）すると全てご覧いただけます。

　最近、「Loop Engineering（ループエンジニアリング）」という新しい開発パラダイム（考え方の枠組み）が提唱されているのをご存じだろうか。この言葉は、GoogleでGoogle CloudとGeminiに携わるソフトウェアエンジニアのアディ・オスマニ（Addy Osmani）氏が、2026年6月7日に同名のブログ記事を公開したことで知られるようになった。

　ループエンジニアリングとは、開発者が手動でAIエージェントにプロンプト（指示文）を打つ代わりに、その役割そのものを仕組みに任せ、AIを動かし続けるシステムを設計する考え方だ。ここでいうループとは、人間が目的（ゴール）を1つ定義すれば、完了条件を満たすまでAIが何度も試行を繰り返すことを意味する（再帰的なゴールという考え方）。やり方を一手ずつ指示せず、目的だけを渡して結果まで任せるイメージだ。オスマニ氏はこれを、コーディングエージェントとの未来の働き方になり得るとみている。

ループエンジニアリングの筆者なりのイメージ図
中央の「記憶」を土台に、自動起動・並行作業・スキル・接続・検証という5つの要素が円環状につながり、AIエージェントがその中を自律的に巡回する。人間（ソフトウェアエンジニア）は外側からそれを見守る。オスマニ氏の記事で示された構成要素から着想し、筆者がイメージとして再構成したものである。

　実際に、製品の現場でもこの変化は始まっている。元記事では、2人の開発者の発言が引用されている。1人は、自律型エージェント環境「OpenClaw」の開発者として有名なピーター・シュタインバーガー（Peter Steinberger）氏である。

もはやコーディングエージェントにプロンプトを打つべきではない。エージェントにプロンプトを打つループを設計すべきだ。

　もう1人は、AnthropicでClaude Codeの開発責任者を務めるボリス・チャーニー（Boris Cherny）氏だ。

私はもうClaudeにプロンプトを打っていない。代わりに、Claudeにプロンプトを打って次に何をすべきかを判断してくれるループを走らせている。私の仕事はループを書くことだ。

　これまでの約2年間、コーディングエージェントから成果を引き出す方法は、良いプロンプトを書き、十分な文脈（コンテキスト）を渡すことだった。人間が一手ずつ道具を握り続けるやり方である。ループエンジニアリングは、この前提を覆そうとしている。作業を見つけ、割り振り、チェックし、何が終わったかを記録し、次に何をするかを決める小さな仕組みを作り、その仕組みによってエージェントを働かせるのだ。オスマニ氏はこれを、ハーネスエンジニアリング（AIエージェントを動かす実行レイヤーを設計する考え方）のさらに上位に位置付けている。

　興味深いのは、ループエンジニアリングが、もはや特定のツールだけの話ではなくなりつつある点だ。以前なら、このようなループを作るには、自分でスクリプトを書いて維持する必要があった。だが今は、OpenAIのCodexやClaude Codeにも、AIを定期的に動かしたり、複数のエージェントを同時に動かして安全に並行作業させたり、作業状況を外部に残したりするための機能が備わり始めている。とはいえ、オスマニ氏はまだ初期段階だとしており、特にトークン（AIが処理する文字の単位）コストには十分注意する必要があるとも述べている。

――この「ループエンジニアリング」について、『Deep Insider Brief』恒例の“ひと言コメント”を述べたい。その後で、オスマニ氏の記事に沿って、ループを構成する要素をできるだけ分かりやすく整理する。

　Deep Insider編集長の一色です。こんにちは。

　私自身も、普段の開発ではChatGPTやClaudeのようなチャット型AIにいろいろ相談しながら、全体的な実装プランや個別のタスクの方向性を一緒に議論しています。そこで方針が固まったら、それを基にClaude CodeやOpenAI Codexに投げるプロンプトをAI自身に作ってもらって実行させる、という進め方をよくしています。相談から始めると自然にそうなってしまうんですよね……。

　ところが開発が進んでくると、Claude Codeが出した結果をチャットAIに貼って相談し、返ってきた新しいプロンプトをまたClaude Codeに入れる、という「仲介作業」がどんどん増えてくるんですね。やりながら「この仲介作業、なくしたいなぁ。これ、絶対に自動化できるはずだよね」とずっと感じていました。

　では、その「自動化」はどうすれば実現できるのか。MCP（Model Context Protocol：AIと外部ツールをつなぐ共通規格）を使えば、AIツールと外部ツールの間の受け渡しはかなり自動化しやすくなります。さらに、Claude CodeからCodexのような別のコーディングツールを呼び出す構成も考えられます。これにより、一方に実装を任せ、もう一方に検証させるような役割分担も可能になります。

　もっとも、私がやっている2つのAIの往復は、それ自体がループエンジニアリングそのものというわけではありません。それだけではまだ、ループエンジニアリングの入り口の段階です。

　ループエンジニアリングが見据えているのは、その先にある「AIを動かし続ける仕組み」だと思います。指示を出し、その結果を仕様と突き合わせ、次の一手を決める。この「仕組み」そのものを設計して、ずれたときの軌道修正まで含めて自律的に回せる環境を作る。それができて初めて、私が手作業で肩代わりしていたループが、本当の意味で自動化されるのだと思います。

　ただし、これは人間が開発から離れて、AIの作業をただ眺めるという話ではありません。オスマニ氏が述べているように、ループを作っても、エンジニアであり続けることが重要です。大きなゴールを与えた後も、人間は結果を確認し、必要なところで判断し、責任を持つ。むしろ開発者の役割は、AIに一手ずつ指示することから、AIが動く仕組みを設計し、そのループを監督することへ移っていくのかもしれませんね。

　ここからは、オスマニ氏がループの構成要素として挙げたものを、一つずつ具体的に見ていこう。

ループを構成する「5つの構成要素」と「1つの外部メモリ」

　オスマニ氏の解説によると、ループを成り立たせるには5つの構成要素と、1つの外部メモリ（記憶）が必要になる。これらに対応する機能は現在、CodexアプリやClaude Codeといった最新のツールで利用できるようになってきている。元記事に示されたそれぞれの役割は以下の通りだ。

1. ハートビート（Automations：自動化）

　スケジュールに基づいて作動し、自律的に問題の発見やトリアージ（優先度付け）を行う仕組み。CI（継続的インテグレーション：自動テストやビルドを行う仕組み）の失敗の要約や、バグの探索などを定常的に実行する。

　オスマニ氏は、この自動化こそがループを一度きりで終わらせず回し続ける「鼓動（ハートビート）」だと表現している。Claude Codeには、一定間隔で再実行する/loopコマンドや、指定した条件を満たすまで現在のセッションを続ける/goalコマンドがある。Claude Codeの/goalでは、毎ターンの後に別の評価器が条件達成を判定する。一方、Codexの/goalも、検証可能な停止条件に向けて複数ターンにわたり作業を続けるための機能として提供されている。

2. 並行作業（Worktrees：ワークツリーによる環境隔離）

　複数のAIエージェントが並行して動く際、同じファイルを同時に書き換えて衝突（コンフリクト）するのを防ぐ仕組み。git worktree（1つのリポジトリで複数の作業ディレクトリを同時に持つ機能）を利用し、それぞれのエージェントに独立したクリーンな作業環境を割り当てる。

　ただしオスマニ氏は、ファイルの衝突は防げても、最終的なレビューを行う人間の処理能力が全体の上限を決める、と指摘している。

3. スキル（Skills：プロジェクト知識のコード化）

　セッションが変わるたびに、プロジェクト固有のルールやビルド手順をAIに何度も説明し直す手間をなくす仕組み。SKILL.mdなどのMarkdownファイルに、プロジェクト固有のルールや手順を記述して配置しておくことで、AIは毎回ゼロから推測することなく、決められた進め方に沿って作業する。なお、スキルはそのまま共有して再利用できるが、複数のスキルやコネクタをまとめて扱いたい場合は、プラグインとしてまとめる方法もある。

4. 接続（プラグイン《Plugins》／コネクタ《Connectors》：ツール連携）

　AIエージェントがファイルシステムだけでなく、外部ツールにアクセスするための仕組み。コネクタはMCPをベースに構築されており、課題管理ツールのLinearのチケットを読み込んだり、データベースに問い合わせたり、Slackにメッセージを投稿したりして、実際の開発環境の中で行動できるようにする。プラグインは、スキルやコネクタをまとめて配布する仕組みである。

5. 検証（サブエージェント《Sub-agents》：実装役と検証役の分離）

　コードを実装するAIと、それをテストや仕様と照らし合わせて検証するAIを、別々の指示や異なるモデル（推論能力の高いモデルなど）で明確に分ける仕組み。

　オスマニ氏によれば、コードを書いたモデルは自分の成果を甘く採点しがちだという。そこで、1つのAIエージェントに実装も検証もまとめて任せるのではなく、別の指示や別モデルを持つサブエージェントに検証役を担わせる。ループは人間が常に見ていない間にも動くため、こうした役割分担によって、自己評価に頼るよりも信頼性を高めやすくなる。

6. 記憶（Memory／State：状態の外部保存）

　長期間にわたってループを回し続けるためのバックボーン（背骨）となる要素。大規模言語モデル（LLM）は、実行と実行の間で前回の状態を自動的には保持しないため、何を試したか、何が成功したかといった「状態」を、モデルの内部ではなく、外部のMarkdownファイルやLinearのボード（タスクを状態別に管理するカンバンボードのような画面）など、会話の外に保存して管理する。

　オスマニ氏は「AIは忘れても、リポジトリは忘れない」とこの仕組みの重要性を強調している。

ループでも肩代わりできない、人間の役割

　ループエンジニアリングはエンジニアの働き方を大きく変えるが、人間の役割を完全に消し去るわけではない。ループエンジニアリングで人間が介在する場面を、筆者なりに元記事から整理し直すと、以下のようになる。

設計時： ループ全体をあらかじめ設計する（最大の関与）
運用中： ループが受信箱（トリアージ）に積んだ「処理できなかったもの・判断が要るもの」を確認し、指示したり承認したりする
成果物に対して： ループ内の検証を経た後も、最終的に「動くと確認したコードを出す」責任は人間が負う

　オスマニ氏は、自動化が進むからこそ、以下の3つの問題がむしろ生じやすくなると警鐘を鳴らしている。

検証の責任（Verification）： ループが自律的に「完了した」と主張しても、それは証明ではない。最終的にコードが正しく動作することを確認し、出荷する責任は、依然として人間に残る
理解負債（Comprehension debt）： AIが書いたコードを人間が読まないまま高速に量産されると、自分のコードベースに対する理解に深刻なギャップ（理解負債）が生まれる。滑らかに回るループほど、この差を速く広げてしまう
認知的降伏（Cognitive surrender）： システムが自動で回るが故に、人間が自分の意見を持つのをやめ、AIが提示したものをそのまま受け入れてしまう危険な状態

　オスマニ氏は、同じループを構築しても、「深く理解しているタスクを加速させるために使う人」と「理解することを避けるために使う人」とでは、全く逆の結果をもたらすと述べている。これからのエンジニアに求められているのは、単に自動化の起動ボタンを押すことではない。AIが自律的に成果を上げるための仕組みを設計し、それを適切に監督する判断力を持つことなのである。