エージェントアーキテクチャ分類体系
AIエージェントがどのような構造で動いているかを理解する
Version 1.0 | 適用領域: 委任・レンダリングプロトコルを実装する全てのエージェントプラットフォーム | 分析日: 2025-02
「4層構造」を30秒で理解する
AIエージェントは、4つの層に分かれて動いています。
↓
ペルソナ層 ── あなたが見る「顔」。一貫した人格
↓
オーケストレーター ── 指揮者。指示を理解し、作業を分解する
↓
スペシャリスト群 ── 各分野の専門家。要約、翻訳、分析など
↓
レンダリング ── 結果の見せ方。画面表示やファイル出力
身近な例で言えば
会社の「窓口担当（ペルソナ）」が依頼を受け、 「マネージャー（オーケストレーター）」が担当者を振り分け、 「各部門の担当（スペシャリスト）」が実作業し、 「広報（レンダリング）」が結果をまとめて報告する。
実装ヒートマップ
理論定義 vs 実装状態のヒートマップ — 定義されたものが実際にどこまで動いているか
2026-02 時点
8アーキタイプ × 実装状態
4層 × 実装状態
サポートシステム
次の一手（優先度順）
ドキュメント
表示用の構造データは契約ファイル（YAML）を Single Source of Truth とし、叙述の正本は以下で参照できます。
AGENT_ARCHITECTURE_TAXONOMY.md で全文を閲覧各層の定義
第0層：ペルソナ層（Persona）
ユーザーが対話する「顔」。一貫した人格を提供する
| 性質 | エージェントではない。オーケストレーター＋レンダリング層が投影する表面 |
| 機能 | 一貫した人格・語調・対話様式を提供し、ユーザーがそれを対話相手として認識する |
| 例 | 政策アナリストのキャラクター、金融アドバイザーのアバター、教育チューター、カスタマーサポート担当者 |
| 核心的特性 | ユーザーの信頼は全てここに蓄積されるが、判断は全て別の層で行われる |
戦略的含意：エージェントシステムを導入する全ての組織は、ペルソナがユーザーエンゲージメントとユーザー操作の両方における最大のベクターであることを認識する必要がある。
第1層：オーケストレーター（Orchestrator）
指示を理解し、適切な担当者に仕事を振り分ける指揮者
| 役割 | 意図の解釈、タスク分解、スペシャリストへの委任、結果の統合 |
| 人間の比喩 | 編集長、エンゲージメントマネージャー、オーケストラの指揮者 |
| 入力 | 人間の意図（自然言語または構造化データ） |
| 出力 | スペシャリストへのタスクトークン、レンダリング層への統合済み成果物 |
| 決定的判断 | 何を調査するか、何を優先するか、何を省くか、どう構成するか |
| 通信 | エージェント間プロトコル（標準化・高スループット） |
戦略的含意：オーケストレーターは品質管理、バイアス監査、ガバナンスにおいて最もレバレッジの高いポイントである。同時に、エンドユーザーから最も見えない層でもある。
第2層：スペシャリスト（Specialist）
要約・翻訳・分析など、各分野に特化した実行者
戦略的含意：新しいスペシャリスト能力を追加する限界費用はほぼゼロに近づく。これは、専門性の拡張に採用・育成・組織調整を要する人間の組織とは根本的に異なるスケーリング原理である。
第3層：レンダリングエージェント（Rendering Agent）
結果をユーザーに見やすく表示する仕組み
| 役割 | オーケストレーターの統合結果を、デバイスに最適化された文脈適切なプレゼンテーションに変換する |
| 入力 | コンテンツ定義（何を表示するか）＋スキーマ定義（どう表示するか）の構造化データ |
| 出力 | 各デバイス・各受け手に合わせて動的生成されたインターフェース |
| 対応デバイス | 大型ディスプレイ、モバイル端末、車載ダッシュボード、ウェアラブル、音声インターフェース、Web |
| 設計上の核心 | コンテンツと表現が構造的に分離されている — 同じ情報がデバイスごとに異なる形態で表出する |
戦略的含意：組織はもはやデバイスごとにインターフェースを設計する必要がない。意味の構造を定義すれば、レンダリングエージェントが全てのデバイス適応を処理する。
スペシャリスト類型
どんな種類の専門家がいるのか。確認済みのものと、構造的に必要と推定されるものがあります。
確認済み（設計上明示）
| 類型 | 役割 | 入力 | 出力 |
|---|---|---|---|
| 検索エージェント | 複数ソースからの情報取得 | 検索クエリ（タスクトークン） | 生データ、情報源リスト、関連性ランキング |
| 計算エージェント | 統計分析、データ構造化 | 生データ＋分析パラメータ | 構造化された分析結果、パターン、定量的出力 |
| 要約エージェント | 抽象化、圧縮、重要度抽出（D2 タスクカバレッジ 2026-02-16 追加） | HandoffPayload（inputs.text, inputs.maxLength 任意） | summary, traceId, taskId |
| 適応エージェント | 言語変換、トーン調整、複雑度の調整（D2 タスクカバレッジ 2026-02-16 追加） | HandoffPayload（inputs.text, inputs.tone, inputs.complexity 任意） | adapted, traceId, taskId |
推定類型（アーキテクチャ上の必然として導出）
| 類型 | 役割 | 必要性の根拠 |
|---|---|---|
| 検証エージェント | 事実確認、相互参照検証、矛盾検出 | 複数情報源間の整合性を担保するため |
| 要約エージェント | 抽象化、圧縮、重要度抽出 | 大量の生データを人間が受け取れる粒度にするため |
| 適応エージェント | 言語変換、トーン調整、複雑度の調整 | 受け手の言語・文化・専門レベルに合わせるため |
| 生成エージェント | コンテンツ制作（文章、音声、ビジュアル、構造化文書） | 最終的なメディア成果物を制作するため |
| 監視エージェント | 継続的監視、変更検知、リアルタイム更新 | 新情報の発生を検知し再処理をトリガーするため |
| 記憶エージェント | 文脈保持、対話履歴管理、嗜好蓄積 | セッション間の連続性を維持し、経時的なパーソナライズを可能にするため |
可視性の構造
ユーザーからどの層が見えていて、どの層が見えていないか。見えない層があるからこそ、使いやすさが生まれます。
| 層 | ユーザーからの可視性 | ユーザーの認知 |
|---|---|---|
| ペルソナ層 | 完全に見える | 「このアドバイザーと話している」 |
| レンダリング出力 | 結果が見える | 「よくできたインターフェースだ」 |
| オーケストレーター | 見えない | 存在を認知していない |
| スペシャリスト群 | 見えない | 存在を知らない |
| エージェント間プロトコル | 見えない | エージェント間通信が行われていることを知らない |
| タスクトークン | 見えない | 何がどのように委任されたか不明 |
Strengthening (Closed Loop)
ベストプラクティスを契約化したチェックリスト。スペシャリスト追加・変更時はベストプラクティスを参照し、本チェックリストを満たすこと。
- [protocol]タスクトークンを版付きスキーマで定義 — 委任ペイロードに schemaVersion を付け、JSON Schema / Type で検証する。
- [protocol]Handoff を API 化（自由文禁止） — エージェント間受け渡しは構造化ペイロードとバリデーターのみ。自由文は禁止。
- [observability]trace_id / task_id で追跡可能にする — 全委任に trace_id と task_id を含め、観測可能性を確保する。
- [protocol]検索・計算を委任プロトコルで呼び出す — 検索/計算を「委任プロトコル」で呼び出す専用エージェントまたは MCP サーバーとして定義する。
- [protocol]MCP サーバーでの汎用スペシャリストを評価 — 汎用スペシャリストを MCP サーバーで実装し、レジストリで管理する案を評価する。
- [governance]ワーカー数 3–5 目安・トークンコスト監視 — Supervisor–Worker 使用時は並列ワーカー数を抑え、コストを監視する。
- [governance]ツールは least-privilege でスコープ限定 — スペシャリストごとにツールスコープを限定し、危険なツールは承認・レート制限でゲートする。
委任スキーマ（タスクトークン）
オーケストレーターからスペシャリストへの委任ペイロード。全委任はこのスキーマに準拠すること。
schemaVersion: 1.0.0（契約: data/specialist-handoff-schema.yaml）
| 必須フィールド | 型 | 説明 |
|---|---|---|
| schemaVersion | string | Semver。スキーマの互換性判定に使用する。 |
| traceId | string | 分散トレース用 ID。全委任で一意。 |
| taskId | string | 委任対象タスクの ID。 |
| intent | string | 委任の意図（何をしてほしいか）。自然言語可だがペイロードの一部として構造化で渡す。 |
| fromRole | string | 委任元の役割（例: coordinator, orchestrator）。 |
| toRole | string | 委任先の役割（例: developer, reviewer）。 |
| timestamp | string | ISO 8601 形式の委任発行時刻。 |
構造的特性
スケーラビリティ
スペシャリストは標準化されたプロトコルを通じて、ほぼゼロの限界費用で追加される。エージェントプラットフォームは新たなドメイン能力を秒単位で獲得できる。
品質のボトルネック
システム出力の品質は、オーケストレーターの判断力に律速される。優秀なスペシャリストをいくら揃えても、誤った問いを立てるオーケストレーター、構造的バイアスを持つオーケストレーターを補うことはできない。
信頼と責任の乖離
ユーザーの信頼はペルソナ層に蓄積される。意思決定権はオーケストレーターにある。実行能力はスペシャリスト群にある。信頼している主体が、判断を行う主体ではなく、実行する主体でもない。
パーソナライズの両義性
最適な教育を可能にするアーキテクチャと、最適な操作を可能にするアーキテクチャは、技術的に完全に同一である。違いはオーケストレーターの目的関数のみにある。
プロフェッショナルサービスへの含意
戦略コンサルティングへの含意
コンサルティングの価値提案は「この作業ができるアナリストがいる」から「どの問いを立て、結果をどう解釈するかの判断力がある」へ移行する — オーケストレーター機能そのものが価値の中心になる。
テクノロジーアドバイザリーへの含意
アドバイザリーの焦点は、ベンダー選定からアーキテクチャ設計 — クライアントの戦略的文脈に合わせたオーケストレーター層の構成設計 — へと移行する。
リスク・ガバナンスへの含意
不可視の意思決定チェーン — オーケストレーターの委任ロジック、スペシャリストの選択基準、レンダリングエージェントの適応パラメータ — を監査する必要がある。オペレーショナルリスクの根本的に新しいカテゴリである。
組織設計への含意
問いは「どの人間の役割が引き続き必要であり、それはなぜか」になる。オーケストレーター相当の機能 — 判断、フレーミング、倫理、クライアントリレーションシップ — に集中することになる。
アーキタイプ ↔ 実装マッピング
AIエージェントには8つの普遍的な役割パターンがあります。mirrorがそのうちどれを実装済みで、何が足りないかを示します。
8つの普遍的アーキタイプと mirror 実装エージェントの対応関係（参照: docs/agent/universal_agent_archetypes_v2.md）
| アーキタイプ | 役割 | mirror 実装 | 状態 | 備考 |
|---|---|---|---|---|
統括者 Orchestrator | タスク分解、エージェント割当、結果統合、全体最適化 | Coordinator | 完全 | 7ステップパイプライン（Architecture→Tasks→Execute→Write→Quality→Git→Deploy）を統括 |
計画者 Planner | 意図理解、戦略立案、タスク分解、実行計画の策定 | Translation Layer | 完全 | 意図抽出→契約生成→検証→最適化の4ステージで計画を構造化 |
探索者 Researcher | 外部情報収集、文脈分析、知識獲得、ソース評価 | Researcher Agent | 部分 | ローカルファイルシステム検索・ドキュメント分析を実装。外部API/MCP経由の情報収集は未実装 |
実行者 Executor | コード生成、ファイル操作、ビルド、具体的成果物の制作 | Developer Agent | 完全 | LLM-first + フォールバックパターン。CRUD一括生成、文脈対応コード生成 |
領域専門家 Domain Specialist | 特定ドメインの深い知識に基づく設計判断、アーキテクチャ決定 | Architect Agent | 部分 | アーキテクチャ設計に特化。ドメイン知識の動的読み込み（Progressive Disclosure）は未実装 |
評価者 Evaluator | 品質検証、テスト実行、コードレビュー、基準適合性の判定 | Tester + Reviewer Agents | 完全 | Tester=テスト生成・実行、Reviewer=コードレビュー・修正サイクル。reviewAndFixCycle()で反復改善 |
守護者 Guardian | 安全性監視、権限管理、コンプライアンス検証、リスク緩和 | Guardian Agent | 完全 | OWASP Top 10 (A01/A02/A03/A07/A09) regex検出 + SIA 5層 + Structural Gate。LLM不要で完全動作 |
統合者 Synthesizer | 異なるソースからの結果統合、矛盾解決、全体像の構築 | Operations Agent | 部分 | デプロイ設定生成に特化。本来の統合者（異なる成果物の意味統合）とは役割が異なる |
未解決のギャップ
- Researcher: ローカル分析は実装済み。外部API/MCP統合が未実装（partial）
- Synthesizer: Operations Agent は統合者の本質（意味統合）をカバーしていない（partial）
プロトコル ↔ 4層分類マッピング
AIエージェント間の通信ルール（プロトコル）が、4層のどこで使われているか。現在の業界標準との対応関係です。
外部プロトコル・標準規格と4層分類の対応関係（2026-02 時点）
Layer 0: Persona
エージェントの「何者であるか」を定義する層mirror: CLAUDE.md + SKILL.md が稼働中。AGENTS.md は CLAUDE.md で代替
Layer 1: Orchestrator
エージェント間の「どう協調するか」を定義する層mirror: 独自実装（agent-coordination.ts）が稼働。外部プロトコルは未統合
Layer 2: Specialist
エージェントと外部世界の「何に接続するか」を定義する層mirror: MCP認識済み。スペシャリストのMCPサーバー化を評価中
Layer 3: Rendering
出力の「どう届けるか」を定義する層mirror: プロトコル標準なし。デバイス適応はアプリケーション層で実装
プロトコル詳細
| プロトコル | 提供者 | 主要層 | 役割 | mirror での状態 |
|---|---|---|---|---|
| CLAUDE.md | Anthropic | L0 Persona | エージェントの人格・振る舞い・判断基準を定義。進化の記録を蓄積 | 稼働中 |
| AGENTS.md | AAIF (Linux Foundation) | L0 Persona | プロジェクト固有のエージェント行動ガイダンス。CLAUDE.mdと補完関係 | 監視中 |
| SKILL.md | Anthropic | L0 Persona | エージェントスキルの定義。Progressive Disclosureで必要時に読み込む | 稼働中 |
| A2A (Agent-to-Agent) | L1 Orchestrator | エージェント間のタスク委譲・状態共有。Agent Card（能力宣言）による動的発見 | 監視中 | |
| ACP (Agent Communication Protocol) | BeeAI / AAIF | L1 Orchestrator | 異種エージェントフレームワーク間の相互運用プロトコル | 将来 |
| MCP (Model Context Protocol) | Anthropic → AAIF | L2 Specialist | エージェントと外部ツール・データソースの接続。de facto標準（10,000+サーバー） | 稼働中 |
| ANP (Agent Network Protocol) | Community | L1 Orchestrator | 分散エージェントネットワーク。組織境界を超えたエージェント連携 | 将来 |
現在地と方向性
今mirrorはどこまで到達していて、次に何を目指すのか。
2026-02 時点 | 成熟度: L2.8（L3 定義内自律 が現在の上限） （5段階中の2.8。定義されたルール内で自律的に動けるレベル）
AI gives you speed. Mirror gives you sight.
Achievements
- 4層分類体系の確立（Persona / Orchestrator / Specialist / Rendering）
- 8アーキタイプのうち6つを実装（75%カバレッジ）
- Structural Gate による意図ドリフト検出（競合に同等機能なし）
- 211テスト + 7ステップパイプライン稼働
- SIA 5層 + TIP + 同意チェックによる構造的安全性
- 17スキル（SKILL.md形式）の展開
Gaps
Direction
- Structural Gate精度向上（意図整合性 26%→70%+）
- Agent Decision Transparencyの設計
- 信頼構造の可視化ダッシュボード
- Agentic Engineering方法論の体系化
- 「料理学校」× ITF/DDM/SMCPの統合
- 1ドメインでのPoC実行
- 速さ（LLM）+ 構造（mirror）+ 意味（人間）の三位一体
- L3の中での最大価値創出
- 進化の自己認識ダッシュボード