エージェント参照アーキテクチャと「クローズドな評価ループ」— 各社事例で束ねる¶
作成日: 2026-06-16 出典 / きっかけ: AI Engineering Summit Tokyo 2026 Summer の Findy Tools セッション「Building GenAI Systems that Scale」（Databricks 登壇）で示された "Agentic System Reference Architecture"。GitHub issue「評価ループの検索」のスライド3枚が起点。原本写真は
03_engineering/_assets/aies2026-genai-scale/（ローカル保存・公開サイトには出さない）と当該 issue に保全。 関連: findy_ai_engineering_summit_2026_summer（イベント全体まとめ。本ノートは 2-7 Databricks 講演の深掘り版） / ai_agent_9社_本番運用アーキテクチャ / ai_agent_identity_標準化2026 / llm_product_clean_architecture_設計 / context_engineering_ast活用 / llmops_データ基盤からの転用_整理（評価ループのデータ供給を分析基盤の medallion／dataset 駆動／Iceberg 版管理に対応づけた整理）
0. 要点（3行）¶
- エージェント本番システムは Governed Context →(RAG/データ) Agentic Core(plan/reason/act) →(MCP/ツール) 実行 →(HITL) 人間の介入 の4ブロックに、閉じた評価・改善ループを巻いた1枚の参照アーキに収束する。Anthropic / OpenAI / Google / AWS / Microsoft の言葉は違うが、ほぼ同じ骨格を指している。
- 最も差がつくのは評価ループ＝ Golden Dataset → Evaluation（golden と照合: 正確性・忠実性・安全性・コスト/レイテンシ・回帰）→ Quality Improvement（回帰トリアージ・prompt/tool 改善・policy 更新・再実行と昇格）→ deployed refinements。「スコアを鵜呑みにせず誰かがトランスクリプトを読む」「1〜5点ではなく binary + 批評」が一次資料の共通結論。
- この1枚は自分の学習リポジトリ（
lectures/）全体を束ねる地図になる: 評価ループ=eval_basics、改善ループ=loop_basics、HITL/承認=guardrails_basics、Governed Context/RAG=rag_*、MCP=claude_agent_sdk、Agentic Core=multi_agent/langgraph_basics、観測=langfuse_basics。
1. このノートの位置づけ¶
findy_ai_engineering_summit_2026_summer の「2-7 Databricks ×2 — Reference Architecture と本番化の現実」を、他社の一次資料で横に広げて検証した深掘り版。スライドは行動変容・社内ツーリング・参照アーキの3枚で、本ノートは3枚目（参照アーキ＋評価ループ）を軸に据える。
スライドの主張（文字起こし）:
- AI 普及は「行動変容」の問題 — ユーザーは AI 懐疑的（ツールを配っても古いやり方を黙って続け、信頼を勝ち取れていない）/ プロダクトとして設計（CUJ・UX・ロールアウト計画）/ 期待値を揃える（品質改善・信頼度スコアを見せる）。
- 最もレバレッジが効く AI は自組織向け — governed data + shared tooling を中心に、App engineers / Data science / Analytics / Platform / Customer-facing / Operations が接続。要点: 共通技術パターンの再利用 / まず社内で正しく作る / governed data と agent sharing / discoverability が鍵 / 社内生産性ツールを侮らない。
- Agentic System Reference Architecture（本命、下記）。
2. Agentic System Reference Architecture（スライド3の構造）¶
flowchart TD
HITL["3. Human-in-the-Loop<br>意図framing・承認ゲート・review/feedback・override/escalate"]
Core["Agentic Core (plan・reason・act)<br>Planner/Orchestrator・Reasoning LLM・Tool Invocation・Memory & State"]
MCP["MCP / API 層<br>Retrieval & search・Enterprise SaaS・社内API"]
GC["1. Governed Enterprise Context<br>アクセス制御・lineage/audit・semantic層・curated knowledge & RAG源"]
Golden[("Golden Dataset<br>期待出力・labeled cases & rubric・versioned ground truth")]
Eval["Evaluation Loop<br>accuracy/faithfulness・safety/policy・cost/latency/回帰"]
Improve["Quality Improvement Loop<br>回帰トリアージ・prompt/tool改善・policy更新・re-run & promote"]
HITL -->|tasks| Core
Core -->|tools| MCP
MCP -->|data| GC
Core -->|traces / outputs| Eval
Golden --> Eval
Eval -->|scores| Improve
Improve -->|deployed refinements| Core5つのブロック:
- Governed Enterprise Context — アクセス制御・ポリシー / lineage & audit / semantic 層・メトリクス / curated knowledge & RAG 源。「何を根拠に答えるか」を統治する土台。
- Agentic Core (plan・reason・act) — Planner/Orchestrator（計画）、Reasoning LLM（推論）、Tool Invocation（実行）、Memory & State（状態）。エージェントの背骨。
- MCP / API 層 — Retrieval & search、Enterprise apps & SaaS、社内 tools & API。Core が外界に触る標準化された口。
- Human-in-the-Loop — 意図・タスク framing、承認ゲート、review & feedback、override & escalate。確率的システムに人間の制御点を差し込む。
- Continuous Quality Improvement（評価ループ） — 本ノートの中核。§4。
3. 5ブロックを各社実装にマッピング¶
「言葉は違うが同じ骨格」を一次資料で確認した対応表（✅=明示/命名, 〜=部分/含意, —=非言及）。
| 出典（一次資料） | (1)Governed Context | (2)Agentic Core | (3)MCP/ツール層 | (4)HITL | (5)評価ループ |
|---|---|---|---|---|---|
| Anthropic "Building Effective Agents"（2024-12） | 〜 guardrails | ✅ Augmented LLM＋5パターン | 〜 tools as augmentation | ✅ checkpoints/blockers | ✅ evaluator-optimizer |
| OpenAI "A Practical Guide to Building Agents"（2025） | 〜 guardrails-as-governance | ✅ model+tools+instructions, manager/decentralized | ✅ data/action tools | ✅ failure閾値・high-risk | 〜 runtime guardrails |
| Google A2A＋ADK（2025-04） | ✅ tool governance/Apigee | ✅ ADK orchestration | ✅ MCP＋A2A(agent↔agent) | 〜 | ✅ ADK evaluate |
| AWS Bedrock AgentCore（GA 2025-10） | ✅ Identity＋Observability/CloudTrail | ✅ Runtime＋Memory | ✅ Gateway(MCPネイティブ)＋Code Interp/Browser | 〜 | ✅ Observability/OTEL |
| Microsoft Agent Framework＋Foundry（2025-10） | ✅ Entra Agent ID＋Purview＋Control Plane | ✅ 5 orchestrationパターン＋durability | ✅ MCP＋A2A＋OpenAPI | ✅ named HITL approvals | ✅ Foundry obs.＋OTEL |
| MCP spec（2024-11 / spec 2025-06-18） | 〜 Resources | — | ✅ この層を定義(tools/resources/prompts) | 〜 Elicitation | — |
読み筋: - MCP がブロック(3)を標準化し（Hosts/Clients/Servers、JSON-RPC、Language Server Protocol を下敷き）、AWS/Google/Microsoft/OpenAI が軒並み採用。A2A（Google 発、Linux Foundation 寄贈）はその上のエージェント↔エージェント層で、MCP と相補的。 - 5ブロックを最も律儀に名前付きで揃えているのは AWS AgentCore（Runtime/Memory/Gateway/Identity/Observability）と Microsoft（Entra Agent ID＋Purview＋HITL approvals）。クラウド3社は「統治・認証・観測」を一級市民にしている＝スライドの (1)(4)(5) を製品化している。 - Anthropic/OpenAI は作り方の原則（パターン・guardrails）寄りで、統治層は薄め。設計思想は Anthropic、運用統治はクラウド3社、と読むと整理しやすい。
詳細な各社の構成要素・URL は §参考リンク。日本企業9社の本番事例は ai_agent_9社_本番運用アーキテクチャ、エージェント認証（AIdentity / Entra Agent ID）は ai_agent_identity_標準化2026 に分けてある。
4. 中核＝クローズドな評価・改善ループ（深掘り）¶
スライドが一番言いたいのはここ。issue タイトル「評価ループの検索」もこれを指す。
4-1. 3段の流れ（スライド）¶
Golden Dataset Evaluation Loop Quality Improvement Loop
───────────────── ──────────────────── ──────────────────────────
curated expected outputs scored vs golden: triage regressions
labeled cases & rubrics → ・accuracy / faithfulness → refine prompts / tools
versioned ground truth ・safety / policy compliance update policies
・cost / latency / regressions re-run & promote
│ │
└──────── deployed refinements ─┘（→ Core に戻る）
4-2. 方法論: Hamel Husain の "Critique Shadowing"（一次資料で最も実装的）¶
findy_ai_engineering_summit_2026_summer でも頻出する Hamel の eval 論。LLM-as-a-Judge を業務成果に効かせる7手順（出典: hamel.dev）:
- Principal Domain Expert を1人決める（リーダーや engineer で代替しない）。
- 多様なデータセットを Features × Scenarios × Personas で作る。まず約30件、新しい失敗モードが出なくなるまで増やす。
- 専門家が binary Pass/Fail ＋ 文章批評でレビュー。「1〜5点でスコアするのは間違い」と明言 — binary が「望む成果を達成したか？」の一問に強制する。
- 明白なエラーを先に潰す。
- judge を反復構築 — 専門家の批評から few-shot を作り、毎回 judge と専門家の一致率（precision/recall を別々に）を測る。
- Error analysis — Feature/Scenario/Persona 別に失敗率を出し、根本原因を分類して高インパクト順に潰す。
- 必要なら専門 judge を分ける。
実数: Honeycomb Query Assistant 事例で 3反復で judge–専門家 一致 >90%。Nurture Boss 事例では 3つの問題が失敗の60%（"A Field Guide to Rapidly Improving AI Products", hamel.dev, 2025）。核心は「judge が価値を生むのではなく、データを直視させるプロセスが価値」。
4-3. judge のバイアス（必読の原典）¶
"Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena"（Zheng et al., arXiv:2306.05685, NeurIPS 2023）が、judge の3バイアスを命名:
- position bias（順序で判定が変わる）/ verbosity bias（長い方を不当に好む）/ self-enhancement bias（自分の出力を贔屓）。
- それでも強い judge（GPT-4）は人間選好と >80% 一致（＝人間同士の一致と同水準）。3K の専門家投票・30K 会話を公開。
- 対策: 順序入替で position bias を検出・平均化、few-shot / reference-guided。
→ 自分の lectures/eval_basics/ex04_judge_bias.py（swap consistency で position bias、同内容・長さ違いで verbosity bias を実測）は、この原典の追試そのもの。
4-4. エージェント特有の eval（Anthropic "Demystifying evals for AI agents"）¶
- transcript（過程）より outcome（最終状態）を採点 — 「予約した」と言ったかではなく、DB に行が在るか。創造的な別解を罰しないため。
- 3種の grader: code-based（速い・脆い）/ model-based（柔軟・要キャリブレーション）/ human（gold standard・遅い）。
- tool-call 検証（使ったツールと引数）は code grader にできるが、手順を過剰指定しない（agent は設計者が想定しない有効解を見つける）。
- 20〜50 件の実失敗由来タスクから始める。class-imbalance を避ける。「人間が解けるか？」で解決可能性を確認。
- 非決定性メトリクス: pass@k（k回中1回成功）/ pass^k（k回全成功）。例: 試行成功率75% → 3回全成功は (0.75)³ ≈ 42%。
- 参照ベンチ: SWE-bench Verified, Terminal-Bench, τ2-Bench, WebArena, OSWorld。鉄則「誰かがトランスクリプトを読むまでスコアを額面で信じない」。
4-5. オフライン vs オンライン eval ＋ 回帰ゲート¶
学術アンカー: "Evaluation-Driven Development and Operations of LLM Agents"（Xia et al., arXiv:2411.13768, CSIRO Data61）。EDD＝評価をライフサイクルに常駐させる。オフライン eval（デプロイ前・固定データセット）とオンライン eval（本番ライブ監視）が連続的な評価・改善ループを成す。構成要素に runtime guardrails・safety cases・observability・多層 eval。
実務語彙（ベンダー解説、慣用）: オフライン eval を CI/CD ゲート（GitHub Actions 等）に載せて「出荷前に回帰を止める」。→ 自分の lectures/eval_basics/ex06_regression_gate.py（baseline vs candidate のケース単位勝敗、デグレで exit 1）がまさにこれ。
5. 評価ループを実装するツール（一次ドキュメント比較）¶
「dataset → オフライン eval → オンライン eval（本番トレース）→ トレース観測 → CI 回帰ゲート」を1ツールで閉じられるか。
| ツール | Golden Dataset(版管理) | オフライン eval(LLM-judge含) | 本番トレースのオンライン eval | トレース観測 | CI回帰ゲート | OSS/セルフホスト |
|---|---|---|---|---|---|---|
| Langfuse | ✅ Datasets / Dataset Runs | ✅ run_experiment()＋LLM-judge/code |
✅ Live Observations に evaluator | ✅ Trace⊃Observation, Sessions | ✅ run_experiment()をCIで assert |
✅ MIT（EEは一部gated） |
| LangSmith | ✅ Datasets/Examples/Splits/版 | ✅ evaluate()/Pairwise/Experiments |
✅ online evaluators(Automations+sampling) | ✅ runs/threads/annotation | ✅ pytest plugin | ✗ 専有（self-host=Enterprise） |
| Braintrust | ✅ initDataset()/snapshot |
✅ Eval()＋OSS autoevals |
✅ Online scoring(span.end) | ✅ logs/traces/spans | ✅ eval-action GH Action |
〜 専有(self-host可)/autoevalsはOSS |
| Arize Phoenix(OSS) | ✅ create_dataset/run_experiment |
✅ phoenix.evals(Hallucination/QA/…) |
✗(OSSは export span のみ) | ✅ OpenInference/OTEL | ✅ pytest/GH Actions | ✅ ELv2, Docker/Helm |
| Arize AX(SaaS) | ✅ ＋自動回帰dataset | ✅ ＋Agent Trajectory Eval | ✅ Online Evals→Tasks | ✅ OpenInference/OTEL | ✅ GH Action recipe | ✗ 商用SaaS |
| OpenAI Evals | ✅ Eval＋Runs(JSONL/stored) | ✅ 6 grader(score_model等) |
〜 stored completions のみ | 〜 logs(トレース型なし) | 〜 非公式(API/cookbook) | 〜 API専有/legacy repoはMIT |
| Ragas | 〜(渡すdataset) | ✅ Faithfulness/Context P・R 等 | ✗(連携前提) | — | ✅ pytest in_ci=True |
✅ Apache-2.0 |
| DeepEval | ✅ EvaluationDataset |
✅ G-Eval/DAG/RAG系 | 〜(Confident AIで) | —(libは無し) | ✅ deepeval test run |
✅ lib Apache-2.0 |
読み筋:
- 1ツールで閉ループ: Langfuse / LangSmith / Braintrust / Arize AX。Phoenix(OSS) はオンライン eval だけ AX 側。
- 本番トレースのオンライン eval ◯: Langfuse / LangSmith / Braintrust / Arize AX。OSS で本命は Langfuse（MIT・セルフホスト） — 自分は既に lectures/langfuse_basics で触っており、MNTSQ のセルフホスト実装記（findy_ai_engineering_summit_2026_summer 2-8）とも噛み合う。
- CI 回帰ゲートの一級実装: Braintrust(eval-action)・LangSmith(pytest plugin)・DeepEval(deepeval test run)。Langfuse/Phoenix/Ragas は pytest 内 assert で代用。
6. スライド1・2（人間・組織）も侮らない¶
評価ループ（技術）だけ作っても、スライド1の通り AI 普及は行動変容の問題。Greptile の「AI生成PRの品質を実測」やカカクコム DODAI の段階導入（findy_ai_engineering_summit_2026_summer 2-1/2-2）が示すのは、信頼度スコアの提示・期待値合わせ・CUJ 設計という人間側の設計が採用率を決めるということ。スライド2の 「最大レバレッジは自組織向け AI」＋ discoverability は、社内ツール・governed data・共通パターン再利用が ROI の源泉、という主張。技術の評価ループと、人間の信頼ループは別物として両方回す。
7. この1枚が学習リポジトリ全体を束ねる地図¶
~/ai-engineering-study/lectures/ の写経群が、参照アーキの各ブロックにそのまま対応する。つまりこのスライドは自分の学習ロードマップの「全体図」として使える。
| 参照アーキのブロック | 対応する lecture | agent-design ロードマップ STEP |
|---|---|---|
| Agentic Core（plan/reason/act） | multi_agent / langgraph_basics / claude_agent_sdk |
STEP 1-2（最小ループ・harness 逆引き） |
| MCP / ツール層 | claude_agent_sdk（in-process MCP） |
STEP 2 |
| Governed Context / RAG | rag_basics / rag_vector_basics / rag_graph_basics |
（RAG 基盤） |
| 評価ループ（Golden→Eval→改善） | eval_basics（ex01 決定論→ex02 golden→ex03 judge→ex04 bias→ex05 hybrid→ex06 回帰ゲート） |
STEP 3-5 |
| HITL / 承認ゲート / ガードレール | guardrails_basics |
STEP 7 |
| 改善ループ・トリガー設計 | loop_basics |
STEP 8 |
| 観測（トレース/オンライン eval） | langfuse_basics |
STEP 5（オンライン評価で接続） |
| コンテキスト管理 | context_basics |
（Core の Memory & State） |
eval_basics/README と agent-design/STUDY_NOTES.md の STEP 0 が既に Anthropic "Building Effective Agents"（§3 の1行目）を起点に据えている。本ノートはその STEP 0 の「概念整理」を各社横断で裏取りした拡張版として使える。
8. 自分に活かすアクション¶
- digest（
ai-engineering-digest）の Phase 2 分類を eval ループに載せる — agent-design STEP 6 の通り、過去 digest から正解30件の golden を作り、harness.yamlの基準を変えると precision/recall がどう動くかをeval_basics/ex06方式の回帰ゲートで可視化。v0.6 の DSPy optimizer 導入の土台。＋ オンライン eval は Langfuse(MIT) で本番トレースに judge を貼るのが OSS 最短。 - 修論 / DKG（知識グラフ） — Governed Context = curated knowledge & RAG 源の話は、ai_agent_9社_本番運用アーキテクチャ の RAG 基盤や DKG のトリプル品質評価に転用できる。golden dataset = versioned ground truth の考えを知識グラフの正解集合に適用。
research-orchestrator（3リポ横断） — HITL の承認ゲートと lethal trifecta 点検（STEP 7）を、Microsoft の "sensitive tools require human authorization" / OpenAI の high-risk トリガーの粒度で見直す。- digest feeds 拡充候補（§参考リンクの一次ブログ）— hamel.dev / Anthropic Engineering / Simon Willison は既に巡回済み。Braintrust / Arize / Langfuse(復活時) は eval ループの一次情報源として候補（RSS 実在は要確認のうえ追加判断、digest 側は別途）。
9. まとめ — 状況 → 見るもの早見表¶
| 知りたいこと | 見る / 使うもの |
|---|---|
| エージェントの全体骨格 | 本ノート §2 の図 ＋ Anthropic "Building Effective Agents" |
| クラウドで統治・認証・観測まで欲しい | AWS AgentCore / Microsoft Agent Framework（§3） |
| ツール接続の標準 | MCP（層3）＋ A2A（エージェント間） |
| 評価系を「設計」する | Hamel "Critique Shadowing"（§4-2）＋ lectures/eval_basics |
| judge のバイアスを実測 | arXiv:2306.05685 ＋ eval_basics/ex04 |
| エージェントの非決定性を測る | pass@k / pass^k（§4-4, Anthropic demystifying-evals） |
| 評価ループを実装するツール | §5 の表（OSS本命=Langfuse, CI=Braintrust/DeepEval） |
| 本番の人間側（採用率） | スライド1・2（§6）＝行動変容・社内ツーリング |
参考リンク¶
参照アーキ / ベンダー: - Anthropic「Building Effective Agents」 https://www.anthropic.com/engineering/building-effective-agents - OpenAI「A Practical Guide to Building Agents」 https://cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf - Google「A2A: a new era of agent interoperability」 https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/ - Google「Agent Development Kit (ADK)」 https://developers.googleblog.com/en/agent-development-kit-easy-to-build-multi-agent-applications/ - AWS「Amazon Bedrock AgentCore Gateway」 https://aws.amazon.com/blogs/machine-learning/introducing-amazon-bedrock-agentcore-gateway-transforming-enterprise-ai-agent-tool-development/ - Microsoft「Microsoft Agent Framework」 https://devblogs.microsoft.com/foundry/introducing-microsoft-agent-framework-the-open-source-engine-for-agentic-ai-apps/ - MCP 公式 https://www.anthropic.com/news/model-context-protocol ／ spec https://modelcontextprotocol.io/specification/2025-06-18
評価ループ（方法論・原典）: - Hamel Husain「Your AI Product Needs Evals」 https://hamel.dev/blog/posts/evals/ - Hamel Husain「Creating a LLM-as-a-Judge That Drives Business Results」 https://hamel.dev/blog/posts/llm-judge/ - Hamel Husain「A Field Guide to Rapidly Improving AI Products」 https://hamel.dev/blog/posts/field-guide/ - Zheng et al.「Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena」 https://arxiv.org/abs/2306.05685 - Anthropic「Demystifying evals for AI agents」 https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents - Xia et al.「Evaluation-Driven Development and Operations of LLM Agents」 https://arxiv.org/abs/2411.13768 - Simon Willison（Hamel judge 注釈） https://simonwillison.net/2024/Oct/30/llm-as-a-judge/
評価ループ（ツール docs）: - Langfuse https://langfuse.com/docs ／ LangSmith https://docs.smith.langchain.com ／ Braintrust https://www.braintrust.dev/docs - Arize Phoenix https://arize.com/docs ／ OpenAI Evals https://platform.openai.com/docs/guides/evals - Ragas https://docs.ragas.io ／ DeepEval https://www.deepeval.com
未確認の注記: OpenAI のガイドPDFは画像主体で本文抽出不可（構成要素名は二次資料で照合）。各社の発表月・一部機能は各ページ表記に依拠。Hamel「批評入りで一致率+15〜20%」は本人主張で独立再現は未確認。Google の Vertex→「Gemini Enterprise Agent Platform」改称は二次情報。
作成: 2026-06-16 ／ 最終更新: 2026-06-27