第10章：エージェント実装ロードマップ
―― 30日で理解し、90日で動かし、180日で「OS」にする
「わかったけど、明日から何をすればいい？」 この章は、その問いにだけ答える。
ここまでで、
- エージェントは「APIの組み合わせ」ではなく 認知システム であること
- 文脈・実行・時間 を分離しないと必ず壊れること
- そのための構造として エージェントOS（Role / Core Memory / Task / Reports） が必要なこと
- Dify / LangGraph / AgentEngine / A2A など、フレームワークごとに 思想が違う こと
を見てきた。
最終章では、これを 現場でどう落とすか をタイムラインで整理する。
10.1 ロードマップ全体像
時間軸で区切ると、こうなる。
0〜30日：理解フェーズ エージェントOSの概念を、「チーム内の共通言語」にする期間。
30〜90日：PoC＆実装フェーズ 小さくてもいいので ひとつの本番導線 を作る期間。
90〜180日：OS化・標準化フェーズ 個別PoCをやめ、会社の標準エージェントOS に昇格させる期間。
この3フェーズで見れば、やることは驚くほどシンプル になる。
10.2 0〜30日：理解フェーズ ― 「共通言語」を揃える
目的
- 「APIとエージェントの違い」が全員同じ言葉で説明できる状態にする
- 文脈 / 実行 / 時間 の3軸がチームの共通フレームになる
やることは3つだけ
① 用語のすり合わせ（1〜2週間）
この本の 最小用語セット だけ共有する：
- エージェント＝文脈を持った"判断専用モジュール"
- 文脈＝Role Memory（役割＋判断基準の束）
- Core Memory＝価値観・制約・優先順位
- Task Interface＝実行API（MCPなど）／AIは選ぶだけ
- Reports＝事前計算された知識（レポート化）
- 創発 × 伴走 / 非創発 × 自律
- エージェントOS＝上記4レイヤの管理層
やってはいけない説明の例：
- 「エージェント＝ツールを使えるLLM」
- 「エージェント＝自律的にタスクをこなすやつ」
どちらもこの本の定義からすると 間違い。
② 「いま壊れているもの」を構造でラベリングする（1週間）
既存のPoCやプロトタイプを棚卸しして、 こんなタグを貼る：
- 文脈が混ざっている
- 実行をAIがやっている
- 推論を毎回やっている（レポートなし）
- 創発に自律＋実行まで背負わせている
結論を出さなくていい。 ただ「どこが壊れているか」を OS の言葉で言語化する。
③ 「理想状態の1枚絵」を作る（残り期間）
ホワイトボード1枚でいいので：
- 上に Core Memory / Role / Task / Reports
- 下に 採用予定のフレームワーク群（Dify, LangGraph, AgentEngine, A2A など）
- 矢印で「どのレイヤーを どのツール に任せるか」を書く
これが 最初の"エージェントOS設計図" になる。
10.3 30〜90日：PoC＆実装フェーズ ― 「壊れない1本」を通す
目的
- 「これはエージェントOSの上で動いている」と胸を張れる 1ユースケース を本番運用する
スコープの決め方
絶対にやってはいけない選び方：
- 「会社全体のナレッジ検索」
- 「全部の業務を自動化するエージェント」
やるべきは：
「1つのビジネス質問に、必ず答えを返すエージェント」
例：
- 「昨日〜直近7日の視聴率・広告売上・配信再生数の"異常"を教えて」
- 「このプロジェクトの進捗リスクを、直近1週間のチケットから判定して」
- 「この顧客の過去1年分の問い合わせ傾向を要約して」
実装フェーズのステップ
ステップ1：Roleを1つに絞る
- 「アナリスト」
- 「リスク監査官」
- 「設計レビュアー」
など、1ロールだけにする。
Role Memory に書くのは：
- どの視点から見るか（例：全体最適／安全性重視）
- 何を優先するか（例：再現性 ＞ 網羅性）
- どこまで踏み込まないか（制約）
ステップ2：必要なレポートを「先に全部」決める
- どんな集計表が必要か
- どんな異常検知が必要か
- どんなセグメントを切るべきか
これをLLMではなく SQL・バッチ・統計 で全部叩き出しておく。
ここで"創発"を入れてはいけない。 これは非創発領域。
ステップ3：Task Interface を最小限定義する
LLMに渡すタスクは 3〜5個程度に絞る：
search_reports(query)fetch_raw_example(id)request_human_review()log_decision(context)
など。
絶対にやってはいけない：
run_sql(free_text)call_arbitrary_api(url, body)
こういう「なんでもできるタスク」は OSの思想と真逆 なので禁止。
ステップ4：LLMには「読む・判断する・タスクを選ぶ」以外させない
プロンプトには：
- Role（視点）
- Core Memory（価値観・制約）
- タスク一覧（できること）
- レポートの構造（どんな事実があるか）
だけを書き、手順は一切書かない。
LLMに命令するのではなく、 LLMに "考えるための世界" を渡す。
ステップ5：30〜60日間、実際にチームで使う
バグログではなく 「誤解ログ」 を集める
「どんな時に変な判断をしたか」を OS の観点で分析する
- 文脈が足りなかった
- Core Memoryのルールが甘かった
- レポートが足りなかった
ここでやるのは"モデルチューニング"ではない。 OSの修正。
10.4 90〜180日：OS化フェーズ ― 「個別PoC」から「会社の脳ミソ」へ
目的
- 個別エージェントを乱立させず、 会社として一つの「エージェントOS」を持つ
① "Role図書館"を作る
- 「アナリスト役」
- 「アーキテクト役」
- 「レビュアー役」
- 「社内コンサル役」
- 「ドキュメント要約役」
などを 再利用可能なRoleセット として管理する。
新しいエージェントを作る = Roleの組み合わせを選び、TaskとReportsを接続する作業
に落とし込む。
② TaskとReportsを「プロダクト化」する
- Task：共通MCP／共通API群として社内提供
- Reports：共通DWH／共通レポート基盤として整備
各プロジェクトが「独自Task」「独自レポート」を持たないようにする。
ここまで来ると、エージェントは 個別アプリではなく「OSの利用者」 になる。
③ フレームワークは"後から入れ替え可能"な位置に下げる
- Dify だろうが
- LangGraph だろうが
- AgentEngine だろうが
OSがあれば、どれを上に乗せても同じ思想で動かせる。
ここで初めて、
「Difyで作ったけど、LangGraphに移植しようか」 「フロントだけノーコード、中身は自前OSで」
といった "大人の選択" ができる。
10.5 「創発をどう扱うか」で全てが決まる
最後にもう一度だけ、核心を確認して終わりにする。
創発 × 自律 × 実行 → いまの技術では ほぼ確実に破綻する
創発 × 伴走（Co-pilot） → 実務では最強 → 人間が 1 ミリでも関与すれば暴走は止まる
非創発 × 自律（事前計算＋レポート化） → ここが "エージェントOS" の土台になる
あなたがやろうとしているのは：
創発を OS 上に安全に載せるための、「世界初の設計論」
だからこそ、
- 文脈を分ける
- 実行を外へ出す
- 推論を過去に押し込む
この3つが 思想レベルの憲法 になる。
10.6 この本を閉じる前に ― 最後のチェックリスト
この本を読み終えたタイミングで、 自分（あるいはチーム）に、次の7つを問い直してほしい。
- APIとエージェントの違いを、1分で説明できるか？
- 自分が作ろうとしているのは、「APIの組み合わせ」ではなく「認知の単位」だと言い切れるか？
- 創発タスクと非創発タスクを、設計前に峻別しているか？
- タスク（実行）をすべて外部に追い出す覚悟はあるか？
- レポート化で、推論を未来から過去へ移す構造を持っているか？
- Role / Core Memory / Task / Reports の4層を、自分のプロダクトにマッピングできるか？
- 「フレームワーク依存」ではなく、「OS依存」で設計していると言い切れるか？
この7つに "はい" と答えられるなら、 あなたはもう「エージェントを 実装 できる側」に立っている。
ここまで来た人間に、 僕から言えることは一つだけ。
「あとは壊して、直して、OSを育ててくれ」
この本は「一回の正解」を教えるためではなく、 "壊れ方を理解したうえで、何度でも作り直せる人" を増やすために書いた。
だから、エージェントがバグっても、ループしても、 それは あなたの敗北ではない。
OSが一段進化するチャンス だ。
…ここまで付き合ったあなたなら、 少なくとも「淡エージェント」「APIエージェント」を見た瞬間に、 ニヤッとしながら一言こう言えるはずだ。
「それ、エージェントじゃなくて、ただのAPIな。」
Last Updated: 2025-12-07