ECCに見るtool use設計

description: ECCはClaude CodeやCodexなど複数のAIコーディングエージェントに対して、スキル・本能・メモリ・セキュリティを統合したハーネス最適化レイヤーを提供するOSSです。tool use設計とMCPとの接続を中心に、実装上の論点を整理します。

meta description: affaan-m/ECCのアーキテクチャを読み解き、AIエージェントのtool use設計・MCP連携・セキュリティ制御の実装判断材料をまとめました。

---

何が出たのか

2026年5月20日、GitHubリポジトリ affaan-m/ECC（Enhanced Coding Companion、以下ECC）が最終プッシュを迎えた時点で、その設計思想が開発者コミュニティの間で注目を集めています。ECCは「agent harness performance optimization system」と自称しており、Claude Code・Codex・Opencode・Cursorといった複数のAIコーディングエージェントに対して、共通の最適化レイヤーを被せる構造を持っています。

具体的には、以下の5つの概念を軸に設計されています。

• Skillsエージェントが呼び出せるツール群の定義と管理
• Instincts事前に埋め込まれたルールベースの行動制約
• Memoryセッションをまたいだコンテキスト保持
• Securityツール呼び出しに対する権限制御と監査
• Research-first development実装前にドキュメントや仕様を参照させるワークフロー

Hacker NewsやRedditのLLMエージェント関連スレッドでは、2026年5月時点でMCP（Model Context Protocol）対応エージェントの「ツール爆発問題」が繰り返し議題に上がっています。ECCはその問題に対して、ハーネス層でツールの可視性と呼び出し順序を制御するアプローチを取っており、この点が差別化として語られています。

---

技術的に面白い点

ECCの設計で最も注目すべきは、tool useをエージェント本体から切り離してハーネス層で管理するという構造です。

通常のLLMエージェント実装では、ツール定義（関数名・引数スキーマ・説明文）をシステムプロンプトやAPIリクエストのtoolsフィールドに直接渡します。ツール数が増えると、モデルのコンテキストウィンドウを圧迫し、どのツールを呼ぶべきかの判断精度が落ちる傾向があります。これが「ツール爆発問題」です。

ECCはこれに対して、以下のような設計で対処しています。

Skillsレイヤーによる動的ツール注入

全ツールを一括でモデルに渡すのではなく、タスクのフェーズや直前の会話コンテキストに応じて、関連性の高いツールサブセットだけを注入します。これはRAG（検索拡張生成）のツール版と考えると分かりやすく、ツール定義をベクトル検索で絞り込んでからAPIに渡す実装に近い思想です。

Instinctsによる事前制約

「ファイルを削除する前に必ずdiffを確認する」「外部APIを呼ぶ前にレート制限を確認する」といったルールを、プロンプトインジェクションではなくコード側のガード層として実装しています。モデルの判断に依存せず、ハーネスが強制的に介入するため、プロンプトが書き換えられても制約が維持されます。

Memoryの設計

セッション間のコンテキスト保持には、短期・長期の2層構造を採用しています。短期メモリは現在のタスクスコープ内の変数や中間成果物を保持し、長期メモリはプロジェクト固有の慣習やユーザーの好みを蓄積します。実装上はJSONまたはSQLiteベースのローカルストアが想定されており、外部サービスへの依存を最小化しています。

SecurityレイヤーとMCP連携

MCPはAnthropicが策定したエージェントとツールサーバー間の通信プロトコルです。ECCはMCPサーバーへの接続をラップし、ツール呼び出しのたびに権限チェックと呼び出しログを挟む構造を持ちます。これにより、どのエージェントがいつどのツールを呼んだかをハーネス側で一元的に記録できます。

---

既存の流れとの違い

2025年後半から2026年にかけて、LangChain・LlamaIndex・AutoGenといったエージェントフレームワークは、それぞれtool use周りの抽象化を強化してきました。ただし、これらは主に「どうツールを定義・登録するか」に注力しており、「ツールの可視性をランタイムで動的に制御する」機能は後付けになっているケースが多いです。

ECCが異なるのは、ハーネスという概念を最初から設計の中心に置いている点です。エージェント本体（Claude CodeやCodexなど）は交換可能なバックエンドとして扱い、ハーネスがスキル・制約・メモリ・セキュリティを一元管理します。これはCI/CDパイプラインにおけるランナーとジョブの関係に近く、エージェントを「実行エンジン」として抽象化する発想です。

また、Research-first developmentというワークフローは、エージェントが実装を始める前にドキュメント参照ツールを強制的に呼ばせるフェーズを設けるものです。これはHugging Faceのモデルカードや公式APIドキュメントを先に読ませてから実装させる、という使い方を想定しており、ハルシネーション（事実と異なる出力）を減らす実用的な手法として評価されています。

既存フレームワークとの比較を整理すると以下のようになります。

---

エージェント実装で詰まりやすい点

ECCのアーキテクチャを参考に実装を進める場合、いくつかの論点で判断が必要になります。

動的ツール注入のレイテンシ

ツールサブセットをベクトル検索で絞り込む場合、検索自体のレイテンシが加算されます。ローカルのFAISSやChromaを使えば数十ミリ秒程度に抑えられますが、外部ベクトルDBを使う場合はネットワークレイテンシが乗ります。ツール数が50以下であれば、単純なキーワードマッチやタグベースのフィルタリングで十分なケースも多く、過剰な設計を避ける判断が重要です。

Instinctsのメンテナンスコスト

ルールをコードで書くということは、ルールの追加・変更もコード変更になります。プロンプトで書けば非エンジニアでも変更できますが、ECCのアプローチではエンジニアが関与し続ける必要があります。プロダクト要件が頻繁に変わる初期フェーズでは、この硬さがボトルネックになる可能性があります。

Memoryのスコープ管理

長期メモリに蓄積された情報が古くなった場合の更新・削除ポリシーが必要です。特にプロジェクト固有の慣習が変わった場合、古い情報がエージェントの判断を誤らせるリスクがあります。TTL（有効期限）の設定や、明示的な無効化APIの設計を最初から考えておく必要があります。

MCPサーバーの権限設計

ECCのSecurityレイヤーはMCP呼び出しをラップしますが、MCPサーバー側の権限設定が甘いと、ハーネスのログには記録されても実際の操作は通ってしまいます。ハーネス側の制御とMCPサーバー側のアクセス制御を二重に設計する必要があり、どちらか一方に依存する設計は避けるべきです。

複数エージェントの評価とfallback

Claude CodeとCodexを並列で動かす場合、どちらの出力を採用するかの評価ロジックが必要です。ECCのリポジトリにはベンチマーク用のスクリプトが含まれていますが、プロダクト固有のタスクに対する評価基準は自前で定義する必要があります。また、一方のエージェントがタイムアウトした場合のfallbackフローも、ハーネス層で明示的に実装する必要があります。

ログの設計と監視

ツール呼び出しのログをハーネスで取ることはできますが、そのログをどこに送り、どう可視化するかは別途設計が必要です。OpenTelemetryのトレーシングと組み合わせることで、エージェントの実行フローをスパン単位で追跡できるようになります。特に本番環境では、ツール呼び出しの失敗率・レイテンシ・コスト（トークン数）を継続的に監視する仕組みが不可欠です。

---

Spectralの見解

1. 技術的な読み

ECCが提示するハーネスアーキテクチャは、エージェントを「交換可能なバックエンド」として扱う設計思想として整合性があります。特にtool useの動的制御とInstinctsによるコードレベルの制約は、プロンプトエンジニアリングだけに依存した実装の脆弱性を補う実用的なアプローチです。MCP対応エージェントが増えている2026年5月時点では、ツール管理の複雑さが実装上の主要な課題になっており、ECCのアプローチはその課題に対して一定の解答を示しています。ただし、OSSとしての成熟度や本番実績はまだ限定的であり、設計思想を参考にしながら自前実装に落とし込む使い方が現実的です。

2. PoCで確認すべき点

PoCでは、動的ツール注入のレイテンシがユーザー体験に影響しないかを最初に計測することを推奨します。ツール数・検索方式・エージェントの応答時間を組み合わせたエンドツーエンドのレイテンシを測定し、許容範囲内に収まるかを確認してください。また、Instinctsのルール定義がチームのワークフローに合うかどうか、ルール変更のサイクルタイムも検証ポイントになります。

3. 業務・プロダクト実装に移す時のリスク

最大のリスクは、ハーネス層がブラックボックス化することです。エージェントの挙動がおかしい場合に、問題がモデル側にあるのかハーネス側にあるのかを切り分けられるよう、ログとトレーシングを最初から設計に組み込む必要があります。また、複数エージェントを横断する設計はコスト管理が複雑になるため、トークン消費量のモニタリングと上限設定を運用ルールとして定めておくことが重要です。中小規模のプロダクトであれば、ECCの全機能を採用するよりも、Skillsの動的注入とSecurityログの2点に絞って導入するほうがリスクを抑えられます。

---

まとめ

ECCは、AIコーディングエージェントのtool use設計における実装上の課題——ツール爆発・制約の脆弱性・セッション間メモリ・セキュリティログ——に対して、ハーネスという概念で一括して対処しようとするOSSです。

設計思想として参考になる点は多く、特に「ツールをランタイムで動的に絞り込む」「制約をプロンプトではなくコードで実装する」「MCP呼び出しをハーネスでラップしてログを取る」の3点は、既存のエージェント実装を見直す際の具体的な改善軸になります。

一方で、ルール管理のメンテナンスコスト・メモリの鮮度管理・複数エージェントのfallback設計といった運用上の課題は、ECCを参考にしながらも自前で設計する必要があります。2026年5月時点でMCPエコシステムが急速に拡張している状況を踏まえると、ハーネス層の設計をどこまで汎用化するかは、プロダクトの規模と変化速度に応じて判断することが重要です。

関連論点として ECC: AIエージェント実装の詰まりどころ もあわせて読むと、この技術動向の背景を追いやすくなります。

Spectralでは、技術調査からPoC設計、プロダクト実装まで支援しています。実現性の確認や事業活用の相談は サービス詳細 と お問い合わせ をご覧ください。