知られざる Agent：原理、アーキテクチャとエンジニアリング実践

## 0. 要約 「あなたも知らないClaude Code：アーキテクチャ、ガバナンス、エンジニアリングの実践」を書き終えた後、Agentの基盤に対する理解がまだ不十分であることに気づきました。さらに、チームがAgentの分野で多くのビジネス導入経験を持っているものの、体系的な整理が欠けていたため、資料、オープンソースの実装、そして自身で書いたコードを再度見直し、最終的にこの記事としてまとめました。 本記事では、Agentアーキテクチャの中でエンジニアリングの成果に最も影響を与えるいくつかの要素、具体的にはコントロールフロー、コンテキストエンジニアリング、ツール設計、記憶、マルチエージェントの組織化、評価、追跡、セキュリティについて解説し、最後にOpenClawの実装を通じてこれらの設計原則がどのように結びついているかを確認します。 整理を進める中で、当初考えていたのとは異なるいくつかの見解が得られました。より高価なモデルの性能向上は、多くの場合、想像ほど大きくないこと、むしろハーネス（Harness）と検証テストの品質が成功率により大きな影響を与えること。Agentの挙動をデバッグする際には、ツール定義を優先的に確認すべきであること。なぜなら、ツールの選択ミスはほとんどの場合、記述の不正確さに起因するからです。さらに、評価システム自体の問題は、Agentの問題よりも発見が難しいことが多々あり、もしAgentのコードを繰り返し調整し続けても、効果はあまり期待できないかもしれません。この記事を読み終える頃には、これらの問題に対するいくつかの答えが見つかるはずです。 ## 1. Agentループの基本的な動作方式 Agentループの核となる実装ロジックは、抽象化すると実際には20行に満たないコードです。 [図：Agent Loopの核心ロジックを示す擬似コード] それに対応するコントロールフローは以下の通りです。感知 -> 意思決定 -> 行動 -> フィードバックの4つのフェーズが、モデルが純粋なテキストを返すまで繰り返されます。 [図：Agentのコントロールフロー] 多くのAgent実装や公式SDKを見てきましたが、構造はほぼ同じです。ループ自体は非常に安定しており、最小限の実装から、子Agent、コンテキスト圧縮、スキル（Skills）のロードをサポートするまで拡張されても、メインループは基本的に変更されていません。新しい機能は通常、ループの内部を変更するのではなく、外部に重ね合わせる形で追加されます。 新しい能力は基本的に以下の3つの方法でのみ組み込まれます。ツールセットとハンドラーの拡張、システムプロンプト構造の調整、そして状態をファイルやデータベースに外部化することです。ループ本体が巨大なステートマシンになるべきではありません。モデルは推論を担当し、外部システムは状態と境界を担当します。この分担が確立されれば、コアとなるループロジックが頻繁に調整されることはほとんどなくなります。 ### WorkflowとAgentの違い Anthropicは、これら2種類のシステムについて明確な区別を設けています。実行パスがコードによって事前に固定されているのがWorkflowであり、LLMによって次のステップが動的に決定されるのがAgentです。核心的な違いは、制御権が誰にあるかです。現実には、Agentと銘打たれた製品の多くが、深く掘り下げるとWorkflowに近い場合があります。しかし、両者に優劣はなく、本当に重要なのは、タスクに最適なソリューションを見つけることです。 一枚の図にまとめると、より直感的になります。 [図：WorkflowとAgentの違いを示す図] ### 5つの一般的な制御パターン ほとんどのAIシステムを分解して見ると、実際にはこれら5つのパターンの組み合わせです。多くのシナリオでは、Agentの完全な自律性は必要なく、いくつかのパターンを組み合わせるだけで十分です。肝心なのは、タスク自体にどの設計が適しているかを見極めることです。 **プロンプトチェイニング (Prompt Chaining)**: タスクを順次実行されるステップに分割し、各ステップでLLMが前のステップの出力を処理します。途中にコードによるチェックポイントを追加することも可能です。生成後の翻訳や、まず概要を作成してから本文を執筆するような線形プロセスに適しています。 **ルーティング (Routing)**: 入力を分類し、対応する専用の処理フローに振り分けます。簡単な問題は軽量モデルへ、複雑な問題は強力なモデルへ。技術的な問い合わせと請求に関する問い合わせでは異なるロジックを使用する、といった具合です。 **並列化 (Parallelization)**: 2つのバリエーションがあります。タスクを独立したサブタスクに分割して並行して実行する「セグメンテーション法」と、同じタスクを複数回実行して合意を得る「投票法」です。高リスクな意思決定や、複数の視点が必要なシナリオに適しています。 **オーケストレーター-ワーカー (Orchestrator-Workers)**: 中央のLLMがタスクを動的に分解し、ワーカーLLMに委任して結果を統合します。nanobotのspawnツールやlearn-claude-codeのサブAgentモードは、いずれもこの原型です。 **エバリュエーター-オプティマイザー (Evaluator-Optimizer)**: ジェネレーターが生成し、エバリュエーターがフィードバックを与え、基準に達するまで繰り返します。翻訳やクリエイティブライティングなど、品質基準をコードで正確に定義するのが難しいタスクに適しています。