第4章：エージェントOS実装 ― 文脈制御の具体化

— 推論を安定させるのは「コード」ではなく「文脈OS」である

前章までで、エージェントが5層構造でしか動かないことを整理した。

ここからはその中心である Layer3：文脈制御（Context & Role Memory） を"どう実装するか" を徹底的に解説する。

結論から言うと：

エージェントの安定性は「文脈の純度」で決まるそして文脈の純度を守るのが「エージェントOS」である。

4.1 なぜ文脈が最重要なのか？

LLMは「1つの文脈を前提に推論する」構造で動く。つまり、

文脈（役割・価値観・制約）が混ざる → AIは迷子になる → 出力が揺れ、暴走する

逆に言うと：

役割を固定できれば、エージェントは壊れない。

ここが 従来のソフトウェア＝還元論 と エージェント＝全体論 の決定的な違い。

文脈はモジュール化できない。"1つの人格"として存在させるしかない。

4.2 エージェントOSは「4つの原子」だけで構成される

LLMに渡す文脈（Context）は、以下の4つだけに分解できる。

Role（役割）
Values（価値観）
Rules（判断ルール）
Scope（守備範囲の境界）

これを外部化し、LLMにとって 常にクリーンな文脈領域 を提供するのがOSである。

4.3 Role（役割）の実装 ― "視点"を固定する

悪い例：

「設計者として考えて、その後エンジニアとして書いてください」

→ LLMには「切り替えスイッチ」が存在しない
→ 文脈が混ざり人格が壊れる

良い例：

ArchitectAgent
AnalystAgent
ReviewAgent

というように 役割を物理的に分離する。

実装レベル

json

{
  "role": "Architect",
  "goal": "全体構造の一貫性確保",
  "values": ["安全性 > 拡張性 > 速度"],
  "rules": ["不明点に踏み込まない", "構造を最優先する"]
}

この「文脈JSON」はそのまま OSメモリ になる。

4.4 Values（価値観）― 判断を揺らさないための"芯"

価値観は、エージェントの"判断の軸"である。

例：

安全性＞構造の単純性＞開発速度
推測しない
全体最適を優先する

なぜ価値観を書くと安定するのか？

手順は状況で揺れる
価値観は揺れない
→ 文脈が安定し、判断精度が爆上がりする

価値観の記述こそが、プロンプトを薄くして強くする鍵。

4.5 Rules（判断ルール）― "やらないこと" を固定する

創発の暴走を止めるのは「禁止事項」だ。

例：

文脈外の質問に踏み込まない
不確実な仮説を断定しない
タスク実行はしない（選択だけ）
感情表現を混ぜない

特に重要なのは：

タスクは実行しない＝ LLMは "実行の文脈" を扱わない

これにより、推論純度は劇的に上がる。

4.6 Scope（守備範囲の境界）― 破綻防止の最後の砦

Scope を明確にすることで：

暴走
過剰探索
役割逸脱

を完全に封じる。

例：ArchitectAgent の場合

APIの詳細は扱わない
実行手順は書かない
設計に必要な情報確認だけ行う
実行フェーズに踏み込まない

スコープを1ミリでも逸脱すると、エージェントは壊れる。

4.7 文脈メモリ（Context Memory）の正しい持ち方

エージェントOSの実装は、極めてシンプルだ。

Context = {
  Role,
  Values,
  Rules,
  Scope,
}

これを 毎ターン LLMに渡す。 LangGraphでもAgentEngineでもDifyでも、実装方法は同じ。

重要なのは：

文脈を永続化（ステート）に混ぜてはいけない。必ず OS側で保持し、LLMは参照するだけ。

4.8 プロンプトは「文脈JSON」だけで成立する

入門者が最も驚くポイントはこれ。

エージェントに手順を書いてはならない。書くのは価値観と禁止事項だけ。

手順はタスク層（Layer4）に追い出す。 LLMには "判断しかしない世界" を与える。

その結果：

一貫性
安定性
文脈純度
デバッグ可能性

すべてが揃う。

4.9 この章のまとめ

✔ 文脈は「役割・価値観・ルール・境界」の4つ
✔ 文脈の混濁が暴走・破綻の主原因
✔ 文脈を外部化し、OSが管理する
✔ LLMは文脈を読むだけ、実行は絶対にしない
✔ 手順の記載は禁止。判断のみを与える
✔ これこそが「判断OSとしてのエージェント」

次章（第5章）：タスクOS ― MCPで実行を外に追放する

ここから Layer4（タスク実行） を詳細解剖する。

なぜLLMに実行させてはいけないのか
MCP / Tools / API の正しい設計思想
「汎用エージェント」の限界線
タスクテンプレート設計の具体例

ここができると、エージェントが"壊れなくなる"。

Last Updated: 2025-12-07

第4章：エージェントOS実装 ― 文脈制御の具体化 ​

— 推論を安定させるのは「コード」ではなく「文脈OS」である ​

4.1 なぜ文脈が最重要なのか？ ​

4.2 エージェントOSは「4つの原子」だけで構成される ​

4.3 Role（役割）の実装 ― "視点"を固定する ​

悪い例： ​

良い例： ​

実装レベル ​

4.4 Values（価値観）― 判断を揺らさないための"芯" ​

例： ​

なぜ価値観を書くと安定するのか？ ​

4.5 Rules（判断ルール）― "やらないこと" を固定する ​