Concepts — 設計思想の全体像

8つの章が描く「AIエージェントアーキテクチャの設計思想」を俯瞰する。

ドキュメントチェーン

章	ラベル	中心的な問い	リンク
01	WHY	AIになぜ指針が必要か？	01-vision
02	WHAT	何を参照先とするか？	02-reference-sources
03	HOW	どう構成するか？	03-architecture
04	WHICH	どのパターンをいつ選ぶか？	04-ai-design-patterns
05	REALITY	現実の制約にどう向き合うか？	05-solving-ai-limitations
06	EXTENSION	三層モデルは物理世界でも成り立つか？	06-physical-ai
07	DOCTRINE	AIは何を基準に判断し行動すべきか？	07-doctrine-and-intent
08	MEMORY	エージェントは何を記憶し、どう接続するか？	08-memory-and-knowledge
09	DECOMPOSITION	プロンプトは層へどう分解されるか？	09-prompt-decomposition

各章がどのレイヤーのどの関心事をカバーしているかを示す。

関心事	Agent 層	Skills 層	MCP 層	Memory 層	Doctrine 層
構造定義	03	03	03	08	07
設計パターン	04	04	04	—	—
制約と対策	05	05	05	08	05
エッジ拡張	06	06	06	—	06
判断基準	07	07	—	08	07
参照先の体系	—	02	02	08	—
プロンプト条件の分配	09	09	09	09	09
設計思想（WHY）	01	01	01	01	01

全章を通じて、以下のカラーコードでレイヤーを表現する。下の Mermaid 図は実際の塗り色のサンプル。

レイヤー	カラー名	Mermaid `fill`
Agent 層	水色	`#87CEEB`
Skills 層	薄緑	`#90EE90`
MCP 層	ピンク	`#FFB6C1`
Memory 層	薄紫 (Lavender)	`#E6E6FA`
Doctrine 層	薄橙	`#FFE4B5`

本サイトのドキュメントでは、RFC 2119 に準拠した規範キーワードを使用する。色は強度の階層を視覚的に表すもので、レイヤー色（淡色系）とは色域が重ならないよう、彩度を高めに設定している。

強度	キーワード	日本語	意味
必須	MUST / SHALL	しなければならない	絶対的な要件。違反は設計上の欠陥
禁止	MUST NOT / SHALL NOT	してはならない	絶対的な禁止事項
推奨	SHOULD	すべきである	正当な理由がある場合のみ逸脱可能
非推奨	SHOULD NOT	すべきでない	正当な理由がある場合のみ採用可能
任意	MAY	してもよい	完全に選択的

ドクトリン内の制約（07-doctrine-and-intent）や、仕様MCPから抽出される規範要件は、この強度ラダーに沿って解釈される。

Concepts セクションの理解が実装フェーズへ進むのに十分かを確認するためのチェックリスト。

[ ] Reference Sources の最小カタログ — プロジェクトが参照する権威ある情報源を特定し、MCP 化の優先順位を決定したか？（02 参照）
[ ] 三層分離の理解 — Agent / Skills / MCP の責務境界を説明でき、アンチパターン（層の混同）を認識しているか？（03 参照）
[ ] パターン選択の根拠 — RAG / MCP / Fine-tuning のどれを採用するか、その根拠を示せるか？（04 参照）
[ ] 制約の境界認識 — 技術で解決できる制約（知識制約）と、技術だけでは解決できない制約（制度的制約）を区別できるか？（05 参照）
[ ] ヒト介入点の合意 — エージェントの自律性レベルと、人間にエスカレーションする条件をチームで合意したか？（07 参照）
[ ] 証拠トレイルの最低要件 — AIの判断根拠を事後的に検証できる仕組み（検証ステータス、出典記録）を設計に含めているか？（05 参照）
[ ] Memory 層導入判断 — 現在のシナリオで scatter-gather のコストが許容範囲か評価し、必要に応じて Memory 層 (Stage 1〜2) の導入を計画したか？（08 参照）

→ 開発フェーズに進み、各フェーズでのMCP統合を実装する → スキル設計ガイドを参照し、ドメイン知識をSkillsとして形式化する

本サイトの概念体系は、AIエージェント研究の標準的な構造と以下のように対応する。