AIアーキテクチャ・パターン集

AIアーキテクチャは、Single-agentかMulti-agentかという一問だけでは決まらない。制御を誰が握るか、状態と知識をどこに置くか、外部ツールをどの境界から呼ぶか、同期・非同期・batchのどの実行形態を使うか、人間承認と復旧をどこに置くかを分けて設計する。

RAG、MCP、human-in-the-loop、batchはagent数とは別の層であり、同じsystem内で組み合わせられる。複雑な構成ほど高度とは限らず、追加したcoordination boundaryごとに状態喪失、権限、停止条件、検証、復旧の責任も増える。

このtaxonomyは PROPOSAL。一列の成熟度taxonomyではなく、以下の組合せとして扱う。

• CONTROL TOPOLOGY
• deterministic workflow
• single-agent loop
• planner-executor
• manager / orchestrator-workers
• decentralized multi-agent
• evaluator-optimizer

• STATE & KNOWLEDGE
• ephemeral context
• explicit checkpoint-state
• RAG
• blackboard / shared state
• external source of truth

• INTEGRATION BOUNDARY
• direct API/tool
• MCP host/gateway/server
• queue/event bus
• sandbox

• EXECUTION MODE
• synchronous interactive
• asynchronous task
• batch
• scheduled/event-driven

• OVERSIGHT & RECOVERY
• HITL approval
• policy gate
• verifier
• checkpoint/resume
• retry/idempotency
• trace/audit

同一systemは各層から一つ以上を組み合わせ得る。single-agent + RAG + MCP + HITL + async task は矛盾しない。

各pattern cardには以下を固定欄として持たせる。

• USE WHEN
• DO NOT USE WHEN
• STATE OWNER
• ACTION AUTHORITY
• TERMINATION
• RECOVERY
• OBSERVABILITY
• COST SHAPE

• OpenAI, A practical guide to building agents — single/multi-agent orchestration guidance。provider guidanceであり普遍標準ではない。PRODUCT_VOLATILE。
• Anthropic, Building Effective AI Agents — workflow/single-agent/multi-agent/sequential/parallel/evaluator-optimizerのarchitecture guidance。provider guidanceであり普遍標準ではない。
• Yao et al., ReAct: Synergizing Reasoning and Acting in Language Models — reasoningとexternal actionをinterleaveするagent-loop研究。benchmarkをenterprise production reliabilityへ外挿しない。
• Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks — retriever + generator / non-parametric memoryの研究根拠。authorization/freshness/provenanceは別評価。
• H. Penny Nii, The Blackboard Model of Problem Solving and the Evolution of Blackboard Architectures — classical blackboard architecture。LLM shared-state mappingは INFERENCE。
• Model Context Protocol 2026-07-28 Specification — current interoperability surfaceとして採用。PRODUCT_VOLATILE、publication-time recheck必須。
• LangGraph Persistence / overview — checkpoint、HITL、resume、fault-tolerant executionのauthor-maintained implementation example。唯一方式とは扱わない。PRODUCT_VOLATILE。
• Cemri et al., Why Do Multi-Agent LLM Systems Fail? — multi-agent coordination failureのcounterevidence。single-agentが常に優れる証明とは扱わない。

architecture比較では同一task fixtureを用い、agent数自体を品質指標にしない。

• task completion / correctness
• tool/action success and side-effect correctness
• total model/tool calls
• token/API cost
• wall-clock latency
• retry/replan/handoff count
• state loss / duplicated work / stale-plan incidence
• termination correctness
• evidence/citation fidelity for RAG
• human interventions / approval latency
• recoverability after injected interruption
• trace completeness / provenance

single-agent vs multi-agentは可能な範囲で同一model能力、tool set、task familyを揃える。

Security: action-capable patternはleast privilege、tool allowlist、sandbox、approval gate、identity propagationを設計する。MCP gatewayはcurrent protocol revisionに沿ったauthorization等をpublication時に再確認する。

Privacy: RAG corpus、shared state、blackboard、checkpoint、batch filesは会話contextとは別のretention/data residency/access-control surfaceを持つ。

Audit: planner decision、handoff、retrieval evidence、tool call、approval、state version、batch job/resultを相関可能なIDで追跡する。

Cost: multi-agent/evaluator loopsはcall数を増やし得る。batch/parallelismは単価またはthroughputを改善し得るが、latency/coordination costを含めTCOで評価する。

Operability: checkpoint/resume、idempotent external write、timeout、cancellation、dead-letter/reconciliation、versioned state schemaを長時間・非同期patternの運用条件にする。

• Core pattern自体はprovider plan非依存。
• 実装可能性はtool calling、structured output、async job、state store、human approval surface等に依存。
• Provider agent implementationはAPI/SDK release、model support、organization policy、tool authorizationに依存。
• MCPはclient/host/serverのprotocol revision/extension compatibilityに依存。
• LangGraph等のstateful implementationはpackage/runtime/version、checkpointer backend、deployment modeに依存。
• Batchはendpoint/model support、usage tier、rate limits、retention policy、latency toleranceに依存。

• provider architecture guideをEnterprise AI Coreの必須仕様へ昇格しない。
• ReAct/RAG/MAS研究benchmarkを特定企業tenant、current closed model、全業務へ外挿しない。
• multi-agent superiorityを推論しない。
• blackboard古典研究と2026 LLM shared-state implementationの同一性を主張しない。
• LangGraphをcheckpoint/HITLの唯一方式としない。
• MCPの旧session architectureをcurrent恒久仕様として固定しない。
• context長増加だけでexternal state/persistence不要とは断定しない。
• batch価格、対象model、retention、rate limitは PRODUCT_VOLATILE。

• current productionにおけるblackboard/shared-state LLM architectureの独立case/failure evidence
• planner-executorとsingle-loop ReAct型のenterprise同条件比較
• MCP current revisionへの主要client/server migration・compatibility evidence
• model能力差を統制したcurrent multi-agent task boundary
• provider横断batch comparison

これらは推測で閉じない。

最小構成 → 観測されたfailure/constraint → 必要なlayerだけ追加 → eval → rollback可能性確認 を基本線とする。