ループエンジニアリング入門

数ヶ月前、開発者の夜は次のようなものでした。コーディングエージェントを開き、指示を入力し、待ち、返ってきた内容を読み、エラーをチャットに貼り付け、再び待ち、少し方向を変えて繰り返す――機能が実際に動くか、寝る時間になるまで。エージェントは確かに作業をしていましたが、人間は常に付き添い、あたかも3秒ごとにハンドルを操作しなければならない車を運転するかのようでした。

今や多くのエンジニアの夜は変わりました。彼らは一つの指示を書き、ラップトップを閉じ、翌朝戻るとプルリクエストの下書き、トリアージされた課題リスト、またはグリーンCIビルド、そしてエージェントが何を試みたか、その理由の読みやすい記録が残っています。誰も隣に立って次のプロンプトを入力していません。変わったのはモデルではなく、モデルの周りに構築されたシステムでした。

この変化の名前がループエンジニアリングであり、2026年6月の1週間でニッチな用語からあらゆるタイムラインで議論されるものになりました。この記事では、用語の起源、その基盤となる研究、ループの構成要素、そして小さなループを自分で構築する方法について説明します。

ループエンジニアリングの実際の意味

ループエンジニアリングとは、人間が手動でターンごとにすべてを行う代わりに、AIエージェントに対してプロンプトを送信し、チェックし、記憶し、再実行するシステム全体を設計する実践です。作業単位は単一のプロンプトや単一の会話ではなく、ループ、すなわちモデルがアクションを起こし、環境からフィードバックを得て、そのフィードバックに基づいて次に何をするかを決定し、実際のチェック可能な条件が満たされるまで繰り返すサイクルになります。

これはそれが置き換えるものと対比すると理解しやすいです。チェーンは固定順序で実行されます。ステップAからB、Cへと進み、それで終わりです。ループは動的です。エージェントはAからBに進み、Bがうまくいかなかったことを発見し、アプローチを修正してからCに進むかもしれませんし、完全にAに戻ることもあります。MindStudioの解説によれば、ループはタスクが真に完了するか、停止条件がトリガーされるか、エージェントがこれ以上進めないと判断するまで続きます。これは「一度質問し、回答を得て、それをコピーする」という作業形態とは根本的に異なります。

もう一つの考慮すべき枠組みは「再帰的目標」の概念です。次のステップを毎回入力する代わりに、「テストスイートを通す」や「すべてのオープンな課題をトリアージし、単純なものには修正案を作成する」といった目的を定義し、エージェントがその目的に向けて自己反復します。コードを検査し、変更を加え、チェックを実行し、結果を読み、次の動きを決定します。スキルは優れた一文を書くことから、信頼して離れられるサイクルを設計することへと移行します。

この用語がほぼ一夜にして定着した経緯

タイムラインは物語の一部です。2026年6月7日、OpenClawエージェントプロジェクトで知られる開発者Peter Steinbergerは、X（旧Twitter）で「もはやコーディングエージェントにプロンプトを送るべきではない。代わりに、プロンプトを送るループを設計すべきだ」と投稿しました。この投稿は数日で650万ビューを超え、翌週のエージェント関連の議論を支配しました。

その翌日、Googleエンジニアで著者のAddy Osmaniは「ループエンジニアリング」と題するエッセイを発表し、Steinbergerの主張に具体的な構造を与えました。オートメーション、ワークツリー、スキル、コネクタ、サブエージェント、そしてその下にある6番目の要素である外部メモリです。このエッセイはバイラルな意見を、他の人が構築し議論できる語彙に変えました。

外部の主張だけではありません。AnthropicでClaude Codeを率いるBoris Chernyは、Osmaniの引用として「私はもうClaudeにプロンプトを送っていません。Claudeにプロンプトを送り、何をすべきかを判断するループを実行しています。私の仕事はループを書くことです」と述べています。最も使われているコーディングエージェントの開発者が直接プロンプトを送るのをやめたと言うとき、そのアイデアはもはや周辺的な意見ではありません。

タイミングは、その下で何が変わったかを考えると理にかなっています。2026年半ばまでに、コーディングエージェントは長時間無人で実行し、自分自身の誤りから回復できるほどに成熟しました。単一のエージェント実行が1時間続き、数十のファイルに触れることが可能になると、ボトルネックはプロンプトの鋭さではなく、その時間全体（誰も見ていない部分を含む）にわたってエージェントを生産的に保ち、チェックし、正しい目標に向け続けるサイクルを構築したかどうかです。

位置づけ：プロンプト、コンテキスト、ハーネス、ループ

ループエンジニアリングは突然現れたわけではありません。プロンプトエンジニアリングから始まり、コンテキストエンジニアリング、ハーネスエンジニアリングへと進み、それぞれが前の層を包み込み、置き換えるのではなく拡張する形で発展してきました。

プロンプトエンジニアリングは最初に登場し、約2022～2024年、言葉遣いに焦点を当てました。モデルに役割を与え、タスクをステップに分解し、例を提供し、段階的に推論するよう求めました。表現を最適化するものでしたが、上限がありました。

コンテキストエンジニアリングは2025年に登場し、焦点は言葉そのものから、モデルが応答する瞬間に実際に見るすべてのもの（会話履歴、検索されたドキュメント、ツール出力など）に移りました。ShopifyのTobi Lütkeは2025年半ばに「タスクがモデルによって解決可能であるために必要なすべてのコンテキストを提供すること」という定義を示しました。Anthropicは2025年9月にこれを形式化し、推論中に最適なトークンセットをキュレーションし維持することとしました。プロンプトエンジニアリングはコンテキストエンジニアリング内の一要素となりました。

ハーネスエンジニアリングは2026年初頭に登場し、エージェントが実際の本番環境でより長く、自律的で、多段階の作業を行うようになるにつれて重要になりました。ハーネスとは、エージェントを取り巻く完全な環境（足場、与えられたツール、制約、誤りを捉えるフィードバックループ）です。エージェントを単に有能にするだけでなく、信頼できるものにします。ハーネスはコンテキストを含み、コンテキストはプロンプトを含みます。

ループエンジニアリングはこれらすべての上に位置します。ハーネスエンジニアリングがエージェントに必要な環境を問うのに対し、ループエンジニアリングはより狭く運用上の問いを立てます。どのサイクルがエージェントを目標に向かって働かせ続け、そのサイクルは正確にいつ停止するのか？これらの層はどれも前の層を置き換えません。プロンプトを書き、コンテキストをキュレーションし、ハーネスを構築する必要は依然としてあります。ループエンジニアリングは、それらすべてを動かし、リズムを与える部分です。

流行語の背後にある研究

ループエンジニアリングは2026年6月の1週間で発明されたかのように思われがちですが、その仕組みは約5年前に遡り、その系譜を知ることが、考えを真に理解することとトレンド記事を繰り返すことの違いを生みます。

直接の祖先はReActパターン（Reason + Act）で、2022年にYaoらによってプリンストン大学とGoogleの共同研究として導入されました。核となるアイデアは、推論ステップと行動ステップを交互に行うことです。モデルは何をすべきか考え、行動し、実際に何が起こったかを観察し、その観察に基づいて再び考え、再び行動します。この交互作用（推論、行動、観察、繰り返し）は、今日のほとんどすべての現代的なコーディングエージェントが依然として実行している基本的なループです。

1年後、2023年にShinnらによるReflexionは、ReActにはなかった記憶と自己批判を追加しました。Reflexionスタイルのエージェントは、作業を行うActor、結果を評価するEvaluator、そして「パッチが失敗した理由はインポートパスが間違っていた」といった実際の口頭での教訓をエピソード記憶に書き込むSelf-Reflectionステップの3つの異なる役割を実行します。これは、誰も基礎モデルを再トレーニングすることなく、単一セッション内でループが目に見えて改善するメカニズムです。

Anthropic自身の2024年12月のガイド「Building Effective Agents」では、さらに2つのパターンが紹介されています。Evaluator-Optimizerパターンは、一方のモデルが候補解を生成し、他方のモデルが明示的な基準に照らしてチェックしてフィードバックを返し、評価が合格するまで循環します。Orchestrator-Workersパターンは、中央モデルが大規模タスクを動的に小さな部分に分割し、各部分を独自のコンテキストウィンドウを持つワーカーに割り当て、結果を統合します。Osmaniの「サブエージェント」と「ワークツリー」が聞き覚えがあるなら、これがその正式版です。

これら4つの研究をすべて辿る目的は些末なことではありません。「ループエンジニアリング」は、2022年から静かに成果を蓄積してきた研究の方向性に対する製品名であり、結集のスローガンです。2026年6月の瞬間はループを発明したのではなく、研究者だけでなく一般の開発者に、意図的にループを構築し始める理由と語彙を与えたのです。

ループの解剖学

ブランドを取り除けば、実際に信頼性の高いループ（単に空回りしたり永久に実行されたりしないもの）は、どのツールやチームが構築したかにかかわらず、同じ少数のコンポーネントを持つ傾向があります。

テスト可能な終了条件を持つ目標が必要です。「アプリをより良くする」ではエージェントがチェックするものがなく、永久に実行されるか、推測に基づいて恣意的に停止します。「認証モジュールのすべてのテストを通す」は文字通り機械的にチェック可能であり、この違いがすべてを左右します。

実際の環境に触れるツールセットが必要です。コード実行（何かが動作するか確認）、ファイルシステムアクセス（読み書き）、ターミナル（コマンド実行）、テストランナーとリンター（正直なフィードバック生成）など。ループのフィードバックは、それを生成するツールと同じだけ信頼できます。優れた推論ができても自分のコードを実行できないエージェントは、余計なステップで推測しているに過ぎません。

コンテキスト管理が必要です。ループの反復ごとに記録（書かれたコード、遭遇したエラー、途中での決定）が増え、コンテキストウィンドウは固定サイズです。管理しなければ、長いループはウィンドウをオーバーフローするか、より陰湿な問題として、記録が増えるにつれて本当に重要なことに注意を払わなくなる「コンテキスト腐敗」が発生します。

明示的な終了とエスカレーションのロジックが必要です。真の成功条件、真の失敗条件（最大反復回数、トークンまたは時間予算、進展のない同一エラーの繰り返し）、および定義されたパス。

ループエンジニアリングの3大難題

コンテキスト管理：ループは定義、目標、初期の事実を適切な場所に保持しつつ、古くなった情報をフィルタリングする必要があります。よくある失敗は、コンテキストが成長してエージェントが無関係な詳細に注意を向け、本当に重要なことを見逃すことです。一般的な解決策は、各反復後に最も関連性の高い情報を圧縮する要約ステップです。

終了：ループはいつ停止するか？多くのループは終了条件があいまいなため永久に実行されるか、過度に保守的で早期停止します。唯一信頼できる方法は、明確なチェック可能条件です。ループが成功できない場合、エスカレーションと責任の移譲が必要です。

検証：エージェントが完了したと考えることと実際の状況の間にはギャップがあります。最も効果的な検証は、テストの実際の実行、構文チェック、ファイル状態の確認など、道具立てされたものです。人間によるレビューは重要な時点で依然として重要ですが、可能な限り自動化・チェック化し、依存性を最小限に抑えるべきです。

最初のループを構築する

本記事では単純な擬似コードの例で締めくくられています（省略）。ループエンジニアリングを理解することは、「一度質問する」マインドセットからループを設計するマインドセットへの移行を意味します。スキルはプロンプトを書くことから、信頼できるループを設計することへと変わり、それはまったく異なるスキルです。