コンテキスト エンジニアリングとループ エンジニアリング: コンテキストを最初に最適化するべきですか、それともループを最初に最適化するべきですか?

エージェントが常に質問に不正確に答え、再試行を繰り返し、コストが高騰する場合、問題は「ループが足りない」ことではなく、「モデルへのコンテキスト入力が足りない」ことが多いです。

一文の区別:

• コンテキスト エンジニアリング: 「このステップでモデルが正確に何を認識しているか」を解決します。
• ループ エンジニアリング: 「システムはモデルにさらにいくつかのステップを実行させ、自己チェックし、ツールを呼び出し、その後戻って続行させるべきでしょうか?」という問題を解決します。

ほとんどの開発者にとって、2 つのどちらかを選択するときに最初に行うことは コンテキスト エンジニアリング です。なぜなら、コンテキスト自体が間違っていたり、欠落していたり​​、汚れていたりすると、ループがどれほど巧妙であっても、エラーが増幅されるだけだからです。

コンセプトの説明

コンテキストエンジニアリングとは何ですか

コンテキスト エンジニアリングとは、モデルが無理をせずに各ステップで現在のタスクを完了するために必要な情報の取得を試みることができるように、モデルの入力コンテキストを中心としたシステム設計を指します。通常、次のものが含まれます。

• システムコマンドの書き方
• ユーザー入力の構造
• どの歴史的な対話が保存され、どの対話が削除されるのでしょうか?
• 検索結果、ツールの戻り値、コード スニペット、および状態変数を挿入する方法
• 複数ステップのタスクでは、どのようなコンテキストをさまざまなステップで公開する必要がありますか?

その目標は、「より多くの情報を詰め込む」ことではなく、コンテキストの関連性、完全性、順序、および利用可能性を向上させることです。

ループエンジニアリングとは何ですか?

ループ エンジニアリングとは、モデルが一度だけ応答するだけでなく、「思考/決定 -> ツールの調整 -> 結果の読み取り -> 修正 -> 継続」という反復プロセスに入るように、エージェントの実行ループに関する設計を指します。以下の場合によく見られます。

• ReAct スタイルのプロキシ
• ツール呼び出しによるプログラミングエージェント
• 自動再試行、反映、スコアリング、ロールバックのメカニズム
• マルチラウンド計画実行システム

その目標は、より美しい答えを 1 回で作成することではなく、システムが複数ステップの反復を通じて複雑なタスクを完了できるようにすることです。

二人の本当の関係

多くのチームはこの 2 つを相反するオプションと考えていますが、これは通常誤解です。

より正確な関係は次のとおりです。

• コンテキスト エンジニアリングは、各ラウンドで「何を見るか」を決定します。
• ループ エンジニアリングは、システム全体にかかるラウンド数と各ラウンドの接続方法を決定します。

つまり、入力層の最適化と制御フローの最適化に似ています。前者は単一ステップの品質に対応し、後者は複数ステップの完了に対応します。

実装原則

コンテキストエンジニアリングの仕組み

コンテキスト エンジニアリングは基本的にコンテキストの予算割り当てを行います。モデルが処理できる情報ウィンドウは限られています。ウィンドウが大きいとしても、すべての情報を入力する価値があるというわけではありません。実際に機能するのは通常、次のとおりです。

1. 現在のステップの目標を明確にします。
2. このステップに強く関連する情報のみを挿入します。
3. 乱雑な生データを、モデルが利用しやすい構造に整理します。
4. 優先度の高い制約が最初に来るように順序を制御します。
5. 長時間のタスク中にコンテキストを継続的に切り取り、要約し、更新します。

AI コーディングでは、これは通常次のようになります。

• まず、タスクの目標、制約、コードベースの境界を指定します。
• 次に、現在関係しているファイル、関数、エラー メッセージを示します。
• 必要に応じて検索結果やツールの出力を補足します
• ウェアハウス全体、ログ全体、無関係な履歴を詰め込まないようにする

このステップが正しく行われると、モデルが実行可能な結果を安定して生成することが容易になります。やり方を間違えると、「モデルは明らかに機能しているのに、答えは常に矛盾する」という問題が発生します。

ループエンジニアリングの仕組み

ループ エンジニアリングは基本的に状態の進歩とエラー修正を行います。 1 回の回答では不十分であると想定しているため、システムはループを通じて徐々に目標に近づいていきます。一般的なメカニズムには次のようなものがあります。

1. 計画: 最初にステップを分割するか、To-Do を生成します。
2. 実行: ツールを呼び出し、ファイルを読み取り、コードを書き込み、チェックを実行します。
3. 観察: ツールの結果、テスト結果、および障害情報を読み取ります。
4. 判断: 続行するか、ロールバックするか、リトライするか、終了するかを決定します。
5. 制約: 最大ラウンド数、終了条件、失敗分岐を設定します。

エンジニアリングにおいて、ループ エンジニアリングの鍵は単に「複数のラウンド」ではなく、次のことにあります。

• 各ラウンドのステータスを追跡できるかどうか
• ツールの結果をコンテキストの次のラウンドに書き戻すことができるかどうか
• いつ停止し、いつ失敗を認識するか
• 無限ループと無効な再試行を回避する方法

多くのプロジェクトがループではなくコンテキストで最初に終了するのはなぜですか?

なぜなら、ほとんどのプロジェクトの開始時に問題となるのは、「複数のステップで推論できないこと」ではなく、次のようなことだからです。

• システムはターゲットという単語が不明瞭であることを示すプロンプトを表示します
• 工具の返品は構造化されていません
• 不正確な検索とリコール
• 歴史的背景がひどく汚染されている
• シングルラウンドタスクの境界があいまいです

この時点でループを追加し続けると、エージェントが間違った前提に基づいて動作し続けることがさらに頻繁になるだけです。通常、結果は次のようになります。

• トークンコストが大幅に増加
• ツール呼び出しの数が急増しました
• 出力はどんどん長くなりますが、正解率は上がらずに下がっていきます。
• デバッグの難易度が急激に上昇する

＃＃どうやって選ぶの？

最初に 1 つのレイヤーのみに投資できる場合、判断ロジックは非常に単純になります。

コンテキストエンジニアリングを優先する

問題が次のような場合は、コンテキスト エンジニアリングの実行を優先してください。

• モデルは要件を誤解することがよくあります
• 同じタスクの出力が大きく変動する
• データは明らかに十分ですが、モデルでは重要なポイントを把握できません。
• ツールが呼び出される前に、方向がすでに間違っています。
• 情報の氾濫、指示の衝突、歴史的汚染は長い文脈で発生します

このタイプの問題は、システムの中心的なボトルネックが次のとおりであることを示しています。 各ステップでモデルによって認識される情報の品質が十分に高くない。

ループエンジニアリングを優先する

問題が次のような場合は、ループ エンジニアリングを優先します。

• タスク自体を完了するには当然複数の手順が必要です
• 単一ラウンドの出力では閉ループを完了できないため、ツールの実行後に修正する必要があります。
• 計画、検証、再試行、ロールバックが必要 ・ファイルの操作、APIの呼び出し、コマンドの実行、結果の確認
• 単一の答えは基本的に正しいが、全体の処理が安定して実行できない

このタイプの問題は、システムの核となるボトルネックが次のとおりであることを示しています。 状態を進めることができる実行ループが必要です。

実践的な判断基準

まず最初に 2 つのことをお聞きします。

1. **モデルが 1 ラウンドのみ回答を許可されている場合、モデルは十分かつ正確な情報を取得していますか? **
2. **答えが十分でない場合、情報が不十分であるためですか、それともタスク自体に複数回のアクションが必要ですか? **

最初の質問に対する答えが「いいえ」の場合は、まずコンテキスト エンジニアリングを実行してください。 最初の質問が「はい」であるが、2 番目の質問でタスクが複数の手順を実行する必要があることが示されている場合は、ループ エンジニアリングに進みます。

適用可能な境界

コンテキストエンジニアリングが解決に適さないもの

コンテキスト エンジニアリングは万能薬ではありません。次の問題の場合、通常、コンテキストの最適化だけでは十分ではありません。

• タスク自体は外部の実行とフィードバックの閉ループを必要とします
• 結果を確認するには実際にツールを呼び出す必要があります
• 複数のステップにわたって長期的な状態を維持する必要がある
• 故障結果に基づいて繰り返し修理が必要

たとえば、自動修復テスト、バッチ コードの変更、およびファイル間の再構築は、ループと切り離せないことがよくあります。

ループエンジニアリングが解決に適さないもの

ループ エンジニアリングはコンテキスト デザインの代替品でもありません。次の問題の場合、ループを追加すると逆効果になることがよくあります。

• 取得されたコンテンツは本質的に無関係です
• システムのプロンプトの単語に矛盾する制約があります
• ツールの出力が汚すぎるため、モデルはそれを理解できません。
• コンテキストが長いが、優先順位の管理がない
• ユーザーの目標自体が正しく構成されていない

この場合、ループによってシステムがミスをしやすくなるだけです。

両方が失敗するシナリオ

次のシナリオでは、両方の効果が限定的である可能性があり、別の戦略が必要となる場合があります。

• ミッションの目的は非常に曖昧であり、成功基準を明確に説明できる人さえいません。
• 外部の知識は頻繁に変化しますが、システムには信頼できる更新ソースがありません
• ツールの機能が不十分です。モデルは何をすべきかを知っていますが、実行できません。
• コストや遅延の予算が厳しすぎて、複数回の試行錯誤ができない
• 強力な決定論的な出力が必要ですが、基礎となるリンクは依然として確率モデルです

現時点では、より合理的な代替案は次のとおりです。

• タスクの範囲を狭める
• リスクの高いステップを手動確認に変更します
• モデルを担当する主要なノードをルール/スクリプトで置き換えます
• エージェントを完全自動エージェントではなく半自動ワークフローに変更します。

事例と実践上のポイント

ケース 1: コードベースの Q&A コパイロット

シナリオ: 開発者は、「このプロジェクトの認証ロジックはどこにあり、どのように接続されていますか?」と尋ねます。

優先すべきは コンテキスト エンジニアリング です。

理由は簡単です。

• このタイプのタスクは、まず正しいファイルを呼び出すことに依存します。
• 関連する関数、呼び出しチェーン、構成アイテムを順番にモデルに提供する必要があります。
• 文脈が間違っている場合、何度も質問を繰り返すと、間違った説明がますます真実になるだけです。

実践的なポイント:

• リポジトリ全体ではなく、最も関連性の高いファイルのフラグメントのみを挿入します
• ファイルパス、関数名、呼び出し関係を指定します。
• 検索結果を「エントリ→中間層→検証ロジック→構成ソース」に整理します。
• 古い履歴をトリミングして、以前の誤った推論がその後の回答を汚染するのを防ぎます。

ケース 2: テストに失敗したコーディング エージェントを自動的に修復する

シナリオ: エージェントは失敗ログを読み取り、コードを変更し、合格または終了するまでテストを再実行します。

優先すべきは ループ エンジニアリング ですが、コンテキスト エンジニアリングも悪くはないという前提があります。

その理由は次のとおりです。

• これは当然ながら複数のステップからなるタスクです
• 各ラウンドではテスト結果を読み取り、それに応じて調整する必要があります ・実行ループがないと、「修正して再テスト」という閉ループが形成できません。

実践的なポイント:

• リトライ回数の上限を明確化
• 回復可能なエラーと回復不可能なエラーを区別する
• 各ラウンドでは、コンテキストの爆発を避けるために、このラウンドの関連ログ概要のみが保持されます。
• エージェントがウェアハウス全体を歩き回るのを防ぐために、コードを記述する前にターゲット ファイル範囲を修正します。
• 失敗が発生した場合、無期限に継続するのではなく、「現在の仮説、試行されたアクション、次のステップの提案」を出力します。

ケース 3: MCP ツールを使用したビルド エージェント ワークフロー

シナリオ: エージェントはドキュメントをクエリし、プロジェクト ファイルを読み取り、外部ツールを呼び出して、結果を生成する必要があります。

通常、これは 2 つの間の選択ではなく、最初にコンテキスト、次にループ です。

理由:

• MCP またはその他のツールを接続した後、実際の問題は「いつどのツールを呼び出し、どのような結果をモデルに送り返すか」になることがよくあります。
• ツールが増えれば増えるほど、より状況に応じたオーケストレーションが必要になります。そうしないと、モデルはツールのリターンによって圧倒されてしまいます。
• シングルラウンド コンテキスト リンクが安定したら、ループを再設計することで問題を特定しやすくなります。

実践的なポイント:

• 各ツールから返される必要最小限のフィールドを定義することから始めます。
• ツールの結果を生の長いテキストではなく構造化されたスニペットに変換します
• 「取得/変更/検証済み」など、実行の各ラウンドのステータス ラベルを保持します。
• 明確な終了条件を設定して、ツール呼び出しチェーンの無限の拡張を回避します。

最も陥りやすい罠

1. より多くのコンテキストをより良いコンテキストと誤解する

通常、本当の問題は、情報が足りないことではなく、関連情報が適切な場所にないことです。過剰なコンテキストは重要な制約を圧倒し、遅延とコストを増加させる可能性があります。

2. 単一ホイールの質量が安定する前にループが時期尚早に重ね合わされる。

モデルが最初の答えから逸脱することが多い場合、反省、再試行、自己評価は通常、より複雑なエラーの軌跡を作成するだけです。

3. 状態境界がないため、ループが制御不能になります。

ループ エンジニアリングの失敗の多くは、モデルがそれを実行できないためではなく、次のことが原因です。

• 最大ラウンド数なし
• 終了条件なし
• 障害分類なし
• 中間状態の圧縮なし

その結果、「一生懸命働いている」ように見えるシステムが、実際には低価値の重複に入ってしまいます。

4. ツールの出力はモデルに直接供給されます。

元のログ、元の JSON、および長いドキュメントが整理されていない場合、モデルは重要なポイントを簡単に見逃してしまいます。コンテキスト エンジニアリングの鍵の 1 つは、生の信号を処理して、モデルが利用できる作業コンテキストにすることです。

失敗した場合のフォールバック計画

コンテキスト エンジニアリングまたはループ エンジニアリングが失敗した場合でも、デフォルトで複雑さを追加し続けることはしないでください。通常、より安全な代替手段は次のとおりです。

代替案 1: シングルステップのワークフローに戻す

複雑なエージェントを「1 ラウンド分析 + 手動確認 + 1 ラウンド実行」に戻します。

以下に適しています:

• リスクの高いコード変更
• 結果の解釈可能性に対する高い要件
• 失敗のコストは効率の向上よりも高くなります

代替案 2: タスクをより小さな決定的なステップに分割する

エージェントに要件の理解、ファイルの検索、コードの変更、テストの実行、概要の作成をすべて同時に行わせないでください。これらを分解すると、Context と Loop の両方を安定させるのが容易になります。

代替案 3: ルール レイヤーを使用して隠蔽する

高度な決定性の部分は、スクリプト、lint、テスト、ルーティング ルール、およびホワイトリスト制約に任せます。モデルにはあいまいな判断部分のみを担当させます。こうすることで、たとえループがおかしくなっても、臨界境界を突破することはありません。

代替案 4: より強力な機能を最初に行うのではなく、可観測性を最初に実行する

各ラウンドで何が入力されたか、どのツールが呼び出されたか、次のラウンドに進む理由がまだ明確にわからない場合は、まずログ、ステータス レコード、およびプロンプト Word のバージョン管理を追加します。いわゆる「モデルの不安定性」の多くは、実際にはエンジニアリングでは観察できません。

簡潔な結論

エージェントがまだ初期段階にある場合は、通常、最初に複雑なループ エンジニアリングを行うよりも、コンテキスト エンジニアリングを正しく行う方が価値があります。

なぜなら:

• コンテキストによって単一ラウンドの品質の下限が決まります
• ループは現在のシステムの長所または短所を増幅するだけです
• クリーンなコンテキストのないループ、通常は高価なノイズアンプ

しかし、AI コーディング、自動修復、ツール オーケストレーションなど、タスク自体が「実行 -> 観察 -> 修正」のクローズド ループを経由する必要がある場合、最終的には コンテキスト + ループ の組み合わせ設計に移行する必要があります。

重要なのは、どの単語を更新するかを選択することではなく、まず現在のボトルネックが情報整理なのか地位向上なのかを特定することです。

次のステップ

普通の開発者から、エージェントのワークフローを真に構築できるエンジニアリングの役割に移行したい場合は、用語を比較するだけでは十分ではありません。追加する価値のある次のステップは次のとおりです。

• エージェント用の安定したコンテキスト入力レイヤーを設計する方法
• ツール呼び出し、MCP アクセス、実行ループの間に明確なステート マシンを確立する方法
• 単一ラウンドのエージェントをいつ使用するか、いつマルチラウンドのエージェントを使用するかを判断する方法
• AI コーディング ワークフローをデバッグ可能、再利用可能、成果物可能なエンジニアリング システムにする方法

このタイプのコンテンツは、単なる概念的な理解ではなく、エージェント エンジニアリングの実践に近いものです。