AIエージェントのハーネス・ループ・グラフエンジニアリングを順に理解する

AIエージェントが長期タスクを担い始めたことで、プロンプトをうまく書くだけでは安定した結果を得ることが難しくなった。エージェントがどの情報を参照し、どのツールを使い、いつ反復し、どの経路へ進み、どこで人の承認を得るべきかまで設計する必要があるためだ。

この問題を説明する際によく登場する表現が、ハーネスエンジニアリング、ループエンジニアリング、グラフエンジニアリングだ。これらは国際標準でも、厳密に合意された学術的分類でもない。互いに重複する部分があり、製品や開発チームによって意味も異なり得る。したがって、年ごとの流行語として覚えるより、それぞれが答えようとしている制御上の問いによって区別するほうが有用だ。

3つの概念を一目で比較する

簡潔に表現すると、ハーネスは環境と境界、ループは反復ルール、グラフは可能な経路の構造だ。実際のシステムでは、グラフの1つのノード内にループが入り、グラフ全体が1つのハーネス内で実行されることがある。

エージェントの制御方式はどのように変化してきたか

初期のエージェント：定められたワークフローが自律性を補完した

初期の生成AIエージェントは、長いタスクで目標を忘れたり、誤ったツール呼び出しを繰り返したり、根拠のない結果を生成したりすることが多かった。そこで開発者は、大きなタスクを小さな段階に分け、各段階の入力と出力を固定した。

この方式では、人が手順全体をチェーン、フローチャート、またはステートマシンとして記述し、LLMは分類、抽出、要約、下書き作成のような限定されたタスクを担当する。LangGraphのようなフレームワークは、状態を維持しながら分岐、循環、チェックポイント、人の介入を表現するために使われる。

ただし、グラフベースのオーケストレーションは、特定の年に終わった古い方式ではない。現在も、監査可能性、再現性、規制遵守、または正確な復旧手順が重要な業務では、明示的なグラフが適している。

モデル性能の向上：固定経路から動的なツール使用へ

ツール使用と推論能力が改善されたことで、1つのエージェントが状況に応じて検索、コード編集、テスト、ファイル読み込みなどの行動を選択できるようになった。ReAct系のアプローチは、推論と行動、観察を交互に行う代表的な構造だ。

この変化により、人がすべての分岐を事前に記述しなければならない負担は減った。一方で、エージェントが読む情報、保有する権限、実行コスト、エラー復旧方式を管理する問題がさらに重要になった。ここで、コンテキストエンジニアリングとハーネスエンジニアリングが実務の中心に入ってくる。

長期タスクとマルチエージェント：ループとグラフの再結合

長期タスクでは、1回のモデル呼び出しより、反復的な計画・実行・検証が重要だ。複数のエージェントが参加する場合は、役割、成果物の形式、権限、終了条件も明示しなければならない。同時に、自律ループを完全に放置すると、コストの急増、無限の再試行、報酬ハッキング、誤った目標の最適化が発生し得る。

そのため、現代的なエージェントシステムは、自律性をなくすのではなく、自律性を許可する区間と決定論的に制御する区間を組み合わせる方向で設計される。これは過去の固定チェーンへの単純な回帰ではなく、柔軟な実行を状態・遷移・ポリシーで囲む方式だ。

こうした変化は、正確な年表というより、設計上の重点の変化だ。グラフ、ループ、ハーネスは当初から共存しており、現在も併用されている。

ハーネスエンジニアリングが扱うもの

ハーネスは基盤モデルそのものではなく、モデルが実際の業務を遂行できるように周囲を取り囲む実行体系だ。同じモデルを使用しても、ハーネスによって成功率、コスト、セキュリティ、再現性が大きく異なり得る。

ハーネスの主な構成要素

1. 指示体系：システム指示、リポジトリのルール、コーディング標準、優先順位と禁止行動
2. コンテキスト供給：検索、ファイル選択、要約、メモリ、必要なタイミングでの文書注入
3. ツールインターフェース：ファイル編集、ターミナル、ブラウザ、データベース、外部API
4. 権限と隔離：読み取り・書き込み範囲、機密情報へのアクセス、ネットワーク制限、サンドボックス
5. 検証手段：テスト、リンター、型チェック、スキーマ検証、ファクトチェック
6. 人の承認：デプロイ、決済、削除、外部送信など、元に戻すことが難しい行動の承認
7. 可観測性：呼び出し記録、コスト、遅延時間、エラー、変更履歴、判断根拠
8. 復旧ポリシー：再試行、以前の状態への復元、タスクの中断、担当者への引き継ぎ

Claude Codeのプロジェクト指示ファイルやフックは、ハーネスの構成要素の事例と見なせる。しかし、特定の製品機能1つがハーネス全体を意味するわけではない。

コンテキストエンジニアリングとの違い

コンテキストエンジニアリングは、現在のモデル呼び出しにどの情報と指示を入れるかを最適化する。検索によって関連文書だけを取得すること、古い会話を要約すること、タスクの状態を外部ファイルに保存すること、サブタスクごとにコンテキストを分けることなどが含まれる。

ハーネスエンジニアリングは、それより範囲が広い。コンテキストだけでなく、ツール権限、実行環境、承認、検証、ロギング、コスト制限まで扱う。したがって、コンテキストエンジニアリングはハーネスの中核部分ではあるが、両者を完全に同じ意味で使うのは正確ではない。

ループエンジニアリングの核心は終了条件だ

ループは、エージェントが結果を生成した後に検査し、不十分であれば再試行するようにする。重要なのは反復そのものではなく、進捗の定義と停止条件だ。

代表的なループの種類

• 検証ループ：下書きを作成した後、テストや評価基準で検査し、失敗した項目を修正する。
• イベントベースのループ：メール、通知、コード変更、センサーデータなどの外部イベントが発生したときにタスクを開始する。
• 探索ループ：複数の仮説や情報源を調査し、証拠が十分になるまで探索範囲を調整する。
• 改善ループ：以前の結果と評価値に基づいて次の戦略を選択する。単一のスコアだけを最適化すると報酬ハッキングが発生し得るため、複数の評価基準と人によるレビューが必要だ。
• 復旧ループ：エラー原因を分類し、許可された範囲内で再試行した後、解決しなければ人に引き継ぐ。

安全なループに必要な契約

エージェント間の契約は法的契約ではなく、入出力と責任を明示した実行仕様だ。次の項目を含めることが望ましい。

完了条件が曖昧だと、エージェントは文章を変えたり、同じ検索を繰り返したりしながらも、タスクが進展していると判断することがある。最大反復回数だけを設けるより、結果の品質、新しい情報の増加量、エラーの変化、コストを併せて見るほうがよい。

グラフエンジニアリングは自律性の境界を構造化する

グラフは、タスクをノードと接続線で表現する。ノードはモデル呼び出し、ツール実行、人の承認、または検証プロセスになり得て、接続線は状態に応じた次の行動を示す。

チェーンとグラフの違い

• チェーンは、AからB、BからCへと続く線形手順に適している。
• グラフは、条件分岐、反復、並列実行、失敗からの復旧、中間保存が必要なタスクに適している。
• 動的グラフでは、実行中にモデルが次のサブタスクや経路を提案する。
• 制約付きグラフでは、モデルが選択する場合でも、許可されたノードと遷移の範囲内だけを移動させる。

現代的なグラフ設計の目的は、すべての行動を人が事前に決めることではない。データ削除前に必ず承認ノードを通過させたり、テスト失敗状態ではデプロイ状態へ移行できないようにしたりする形で、守るべき不変条件を構造に組み込むことにある。

グラフが必要な兆候

次の条件のうち複数が当てはまるなら、明示的なグラフを検討する価値がある。

• 失敗後に戻るべき復旧地点が明確だ。
• 人の承認が必須となる段階がある。
• 複数のタスクを並列実行した後、結果を統合する必要がある。
• 状態に応じて使用可能なツールや権限が異なる。
• 実行経路全体を監査または再現する必要がある。
• 単一エージェントのループが同じ失敗を繰り返す。

単純な文書要約や1回限りのデータ変換までグラフにすると、複雑さが増すだけになり得る。

実務への適用手順：ハーネスから始め、必要なだけ拡張する

多くのチームにとって、次の手順が現実的だ。

1. 単一のタスクと成功基準を定める。 まず入力、期待する出力、失敗事例を集める。
2. 最小限のハーネスを作る。 必要なコンテキストとツールだけを提供し、権限、テスト、ログ、コスト上限を設定する。
3. 評価セットを構築する。 正常な事例だけでなく、曖昧な依頼、誤った文書、ツールエラー、権限超過の試みも含める。
4. 反復が必要な箇所をループにする。 検証と修正が実際に品質を高める区間に限って再試行を許可する。
5. 分岐と復旧が複雑な場合はグラフへ昇格させる。 状態と遷移を明示し、危険な行動の前に承認ノードを置く。
6. 業務分担にメリットがある場合に限ってマルチエージェントを使う。 並列探索や異なる専門的役割が必要でなければ、単一エージェントのほうがシンプルで安価な場合がある。

コーディングとリサーチにおける適用の違い

コーディングでは動的ワークフローが常に非効率で、リサーチでは常に有利だと断定することはできない。テスト可能な大規模マイグレーションは自律エージェントに適する場合があり、答えが明確な事実照会は固定されたリサーチ手順のほうが効率的な場合がある。核心となる変数は分野よりも、目標の明確さ、自動検証可能性、探索空間、エラーコストだ。

コードレビューはなくなるのではなく、レビュー単位が変わる

エージェントがコードを書くと、開発者はすべての行を自分で入力する代わりに、要件、設計、テスト結果、変更範囲、リスクを監督する役割をより多く担うことになる。Pull Requestの要約とエージェントのレポートは、レビュー速度を高めることができる。

しかし、要約だけを読んで承認する方式は、安全なデフォルトではない。エージェントが見落とした変更や誤解したロジックは、要約にも現れない場合がある。次の状況では、元のdiffと関連コードを直接レビューしなければならない。

• 認証、決済、個人情報、暗号化、アクセス制御の変更
• データベーススキーマの変更や不可逆的なマイグレーション
• パフォーマンスと並行性に敏感なコード
• テスト範囲を超える大規模なリファクタリング
• 外部依存関係、デプロイ設定、機密情報処理の変更
• エージェントの説明と実際のdiffが一致しない場合

Human-in-the-loopとは、人が形式的にボタンを押すことではない。人が判断できるよう、変更の証拠、テスト結果、失敗の可能性、ロールバック手順を提供することまで含む。

陥りやすい罠

目的のないマルチエージェント

エージェントを増やすと、役割の調整、重複した呼び出し、コンテキストの受け渡し、結果の統合にコストがかかる。異なる観点からの並列探索が必要、またはコンテキストを分離すべき理由がないのであれば、単一エージェントのほうがよい。

無制限の動的ワークフロー

エージェントがサブタスクを作り続けられるようにすると、トークンとツール呼び出しのコストが急速に増加する。コストはおおむね、各段階の入出力トークンコスト、ツールコスト、並列エージェント数、反復回数の合計によって決まる。呼び出し回数、同時実行数、総予算、最大実行時間をそれぞれ制限しなければならない。

1つの評価指標だけを最適化する

テスト合格率だけを目標として与えると、テストを弱めたり、例外処理を隠したりするような誤った最適化が生じ得る。品質、セキュリティ、変更規模、コスト、遅延時間、人による評価を併用しなければならない。

文書注入をファインチューニングと混同する

文書検索やプロジェクト指示によって結果が継続的に変化することはあるが、モデルの重みが変わるわけではない。これは広い意味ではシステムの学習効果として説明できるが、厳密には外部メモリとコンテキストを利用した適応だ。文書や検索インデックスを保持してこそ、次回の実行でも変化が維持される。

運用段階で見落としやすい評価・セキュリティ・経済性

エージェント設計は、アーキテクチャ図で終わるものではない。実際の運用では、何を許可したかより、実際に何が起きたかを測定する仕組みが重要だ。

最低限の運用指標

• タスク成功率と人による修正率
• タスク当たりのモデル・ツールコストと総実行時間
• 反復回数と進捗なしに消費された呼び出しの割合
• 承認要求、拒否、権限超過の試行回数
• 誤ったツール呼び出しと復旧成功率
• 出典またはテストなしで提出された結果の割合
• 同一入力で結果が変化する程度

セキュリティ上必要な不変条件

• 外部文書の指示がシステムポリシーより高い優先順位を持たない。
• 機密情報をモデル入力とログに不必要に露出させない。
• 読み取り権限と、書き込み・削除・デプロイ権限を分離する。
• 外部送信と不可逆的な行動には、別途の承認またはポリシーチェックを設ける。
• エージェントが自身の評価基準、テスト、または監査ログを任意に変更できないようにする。

こうした不変条件は、プロンプトの一文よりも、サンドボックス、アクセス制御、グラフ遷移、独立した検証器によって強制するほうが安全だ。生成AIのリスク管理には、モデルの精度だけでなく、運用環境、人の監督、インシデント対応まで含めなければならない。

どの概念から学ぶべきか

現在の実務で最初に習得すべきなのは、ハーネスエンジニアリングだ。正確なコンテキスト、最小権限、自動検証、ログ、承認、コスト上限を備えれば、単一エージェントの多くの失敗を減らすことができる。

次に、反復が品質を高めるタスクへ、終了条件のあるループを追加する。分岐、並列処理、復旧、承認手順が複雑になったときに、グラフとして明示する。複雑な用語を採用することより、エージェントの目標、権限、証拠、コスト、停止条件を測定可能な形にすることが優先される。