ループ・エンジニアリングとは？

ループ・エンジニアリングとは、エージェント型ワークフロー（ループ）を設計し、AIエージェントが最小限の人間の介入でユーザーが定義した目標を達成できるよう、反復的に導く手法です。エージェント・ループでは、各ステップで人間がプロンプトを与える必要はなく、エージェントが自律的に行動、観察、意思決定を繰り返し、タスクを完了できます。 

開発者にとってループ・エンジニアリングとは、AIエージェントにプロンプトを与えることから、エージェントにプロンプトを与え、チェックし、導く自動システムを設計することへと役割を再定義するものです。適切に設計されたループでは、エージェントは推論し、行動し、その結果をレビューしたうえで、それに応じて次の行動を調整できます。 

ループ・エンジニアリングは、IBM Bob、Claude Code、OpenAIのCodexなど、多くのAIコーディング・エージェントを支える新しいエージェント型エンジニアリングの実践手法です。ループ・エンジニアリングは実行システム全体を最適化し、エージェントが最小限の監督で複数のステップから成る複雑な問題を解決できるようにします。

プロンプト・エンジニアリングとは、AIモデルに対して最も効果的で最適化された単一の指示を作成する手法です。ループ・エンジニアリングでは、指定された目標を達成するまで、自らプロンプトを生成し、自身の成果を評価する自動システムを設計します。 

プロンプト・エンジニアリングでは、人間がプロンプトを作成し、その成果を評価し、各段階で後続のプロンプトを作成します。ループ・エンジニアリングでは、最適な成果を達成するために独自の内部プロンプトを改良する、大部分が自動化されたシステムを作成します。プロンプト・チェーンは固定的な構造に従いますが、ループは動的で柔軟です。

プロンプト・エンジニアリングは、1回限りのやり取りや個々のモデル呼び出しに適しています。ループ・エンジニアリングは、自律的なコード生成、ソフトウェア保守、多段階のタスク実行といったワークフローを処理する長時間稼働するエージェントにより適しています。

エージェント・ループは通常、次のような標準的なパターンに従います。 

1. 目標
   
   
2. 行動
   
   
3. 観察
   
   
4. 調整

再帰的な目標は、エージェント・ループの各反復で評価されるため、不要な反復を防ぎ、トークン・コストを抑えながら、エージェントがタスクから逸れないようにするのに役立ちます。再帰的な目標は、AIエージェントに具体的な目標と、明確かつ検証可能な停止条件を与えます。それらは具体的で、適切に範囲が設定され、可能な限りテスト可能なサブタスクに分割される必要があります。 

例えば、「Webサイトの読み込みを高速化する」は曖昧ですが、「コードがすべての単体テストに合格し、要件を満たした時点で反復を終了する」は、エージェントに測定可能な目標と明確な終了条件を与えます。

エージェントは、目標と現在の進捗状況を考慮し、目標にさらに近づくように行動します。行動の例としては、コードの生成、単体テストの実行、バグ修正などがあります。

エージェント型システムは、行動の結果を評価します。自動コード生成では、エージェントが 継続的統合（CI） テストを実行し、生成されたコードがテストに合格するかどうかを確認できます。

その観察に基づいて、システムはフィードバックを評価し、エージェント・ループを再開する前にアプローチに必要な変更を加えます。

適切に設計されたループは、効率性と信頼性を維持しながら、定められた範囲内で最小限の監督のもと動作できます。これらは、トークンコストを抑え、必要に応じて終了し、信頼できる結果につながる効率的なプロセスです。対照的に、構築品質の低いループは非効率的であり、繰り返しの失敗、不要な作業、誤った推論によってトークンを浪費します。 

良い結果をもたらすループを設計する際、開発者は通常、次の要素を組み込みます。

• 自動化またはスケジュール設定
  
  
• フック
  
  
• コンテキスト・エンジニアリング
  
  
• ツールへのアクセス
  
  
• ワークツリー
  
  
• スキル
  
  
• サブエージェント
  
  
• Spine

反復こそが、ループを一度限りのプロンプトと区別する要素です。使用するコーディング・アシスタントに応じて、ループは自動化機能またはスケジュール機能によって実行されます。どちらもループの実行サイクルを定め、何を実行するか、そしてどのくらいの頻度で実行するかを決めます。たとえば、開発者はエージェント・ループをスケジュールまたはトリガーするためにGitHub Actionsをよく使用します。 

LinuxやmacOSなどのUnixベースのシステムは、cronジョブと呼ばれる時間ベースのスケジューラーを使ってタスクを自動化します。

スケジュールされたオートメーションとは異なり、フックは、コードの生成、ファイルの編集、ツールの呼び出し、タスクの完了などのイベントによってトリガーされる命令です。フックは、関連するイベントの前後で実行できます。 

開発者は主に、ポリシーの適用、アウトプットの検証、ワークフローを自動的にトリガーするため、セキュリティーと品質のためにフックを使用しています。例えば、pre-commitフックは、変更をリポジトリーにコミットする前に、コードが標準に準拠しているかどうかを確認するために使用できます。 

フックにより、ガバナンスや品質チェックなどのタスクをループ内のエージェントから切り離せるため、トークン・コストとコンピューティング・リソースの使用量を削減できます。

ループの各サイクルでは、コンテキストと呼ばれるデータが生成され、それが後続のサイクルに渡されます。最新のAIエージェントや大規模言語モデル（LLM）は、大きなコンテキスト・ウィンドウを備えているため、ユーザーは一度に大量のデータを入力できます。ただし、過度のコンテキストを提供すると、関連性が低下し、コストが増加し、モデルが最も重要な情報を識別することが困難になる可能性があります。 

コンテキスト・エンジニアリングとは、AIモデルが必要とするデータを提供しつつ、不要なコンテキストを最小限に抑えるシステムを設計する手法です。例えば、コンテキストを圧縮するために過去のループ反復を要約したり、マークダウンを用いてコンテキストを整理したりする方法があります。

ループ・エンジニアは一般的に、MCP（モデル・コンテキスト・プロトコル）サーバーを他のAPIや統合機能と組み合わせて使用し、エージェントがコネクターやツールを使って自律的に操作できるようにします。ツールへのアクセスがなければ、エージェントは外部システムに対して実際に操作を行うことはできず、何を実行するかを説明することしかできません。

コーディング・エージェントは、ツールを使ってコードを実行し、ファイル・システムにアクセスし、ターミナルやシェルでコマンドを実行し、データベースにクエリーを実行したり、テストを実行したりします。エージェント・ハーネス・エンジニアリングは、エージェントを中心とした完全な実行環境を設計し、永続的で自己修正可能なシステムを作成する新たな手法です。

ワークツリーによって分岐が可能になるため、複数のエージェントはお互いの作業に影響を与えることなく、並行して作業を進めることができます。Gitワークツリーを使用すると、複数の作業ディレクトリーが単一のリポジトリーを共有できるため、リポジトリーの履歴を重複させることなく、並行したブランチが可能になります。エージェントは、コードがテストまたは人間によってレビューされるまで、またはユーザーが決定した別の基準が満たされるまで、ブランチをマージしません。

スキルには、単一の繰り返しワークフローに対するタスク固有のプロジェクト知識が含まれています。エージェントは、関連するタスクを実行する際に、スキル・ファイルを参照します。一部のコーディング・アシスタントでは、命令やメタデータを含むskill.mdファイルを格納したフォルダーとしてスキルを管理します。一方、agents.mdなどのプロジェクト・レベルの命令ファイルは、リポジトリー全体を対象とします。

スキルがない場合、ユーザーはセッションごとにプロジェクトのコンテキストを含めるか、エージェントに何をすべきかを推測させる必要があり、その結果、誤った推測をしてしまうリスクがあります。スキルはプロジェクトやリポジトリ間でプラグインとして共有できます。

プライマリー・エージェントは、サブエージェントと呼ばれる専門エージェントに委任し、研究、探索、実装、検証など、特定の役割を果たすことができます。優れたループ・エンジニアリングでは、コード品質を高めるために、あるエージェントが別のエージェントのコードを検証するメーカー／チェッカー構造を採用します。

サブエージェントはトークンの使用を増やしますが、独自の指示を持つ別の検証サブエージェントは通常、コーディング・エージェントが独自のコードをチェックするよりも高い品質保証を提供します。一部のコードプラットフォームでは、個別のサブエージェントを使用してタスクの進行状況を監視し、終了条件が満たされたかどうかを判断します。

ループには、Spineと呼ばれる要素があります。これは、プロジェクトの進捗を追跡し、同じエラーの繰り返しを防ぐための永続的な状態またはメモリーです。サイクルごとに、エージェントは行動の結果を、永続的な状態、メモリー・ストア、またはマークダウン・ファイルやLinearボードなどのプロジェクト・トラッカーに追加します。Spineは状態とコンテキストを維持し、その情報を以降の反復に反映します。

どれほど堅牢でレジリエントなループであっても、人間の関与は欠かせません。組織は、AIでソフトウェア・デリバリーを加速しつつ、品質、セキュリティー、ビジネス成果については人間が担うことで、AIから最大の価値を引き出せます。 

ヒューマン・イン・ザ・ループ・アプローチは、未検証のコード、理解負債、意図負債、認知的降伏など、自動コード生成に伴う最も危険な落とし穴を回避するのに役立ちます。

チェッカー・エージェントは依然として単なるエージェントであり、人間の開発者が出荷されたすべてのコードの最終的な責任を負います。効果的なAIガバナンスには、コードが正しく動作することだけでなく、機密データを漏えいさせていないことや、関連する規制に違反していないことを人間が監督・確認することが求められます。

システム内のコードの総量と人間が理解できる程度とのギャップは、理解負債と呼ばれます。エージェントがより多くのコードを記述し、人間がそれを確認する機会が減るにつれて、理解負債は増加します。 

従来の技術的負債は意図的な近道によって生じるのに対し、理解負債は受動的に蓄積されます。理解負債は、エージェントがコードを生成する速度により急速に蓄積され、多くの場合はコードが自動テストに合格するため、気付かれないままに蓄積されます。これに対処しないままでいると、開発者が本番環境の障害をデバッグしたり、大規模な変更を実装したり、インシデントに対応したりする段階になって初めて、組織は深刻な理解負債に気付くことが少なくありません。

意図負債とは、システムの背後にある根拠を説明する具体的な説明が失われることです。agents.mdやskill.mdなどのファイルに明示的に記述されていない限り、エージェントが開発者の意図を正確に推測することは困難です。これがなければ、エージェントは間違った戦略目標に向けて行動を最適化し、技術的には健全でもプロジェクトの目標に反するコード変更を行ってしまう可能性があります。

人間がAIへの依存を強めるにつれて、認知的降伏（cognitive surrender）、つまりクリティカルな思考をAIに委ねてしまう状態に陥りやすくなります。認知オフロードは、人間が生成されたアウトプットを確認・検証することを前提としますが、認知的降伏は、そのような人間による統制を完全に失った状態を指します。 

開発者がループのアウトプットを無批判に受け入れるようになると、理解負債は急速に増加します。