序章：実装概論への導入
—「壊れるように作っている」から壊れるだけだ
エージェント開発の世界には、ひとつの前提がある。ほとんどの開発者は気づいていないが、それがすべての破綻の原因だ。
エージェントは"壊れやすい技術"なのではない。あなたが"壊れる構造"で作っているだけだ。
- プロンプトに手順を書きすぎる
- ツールを命令として埋め込む
- 文脈と実行を混ぜる
- 計算をリアルタイムに背負わせる
- 自律と創発をごちゃ混ぜにする
これらは、すべて構造的な失敗だ。知能の問題ではなく、設計思想と実装思想の破綻である。
私はこれまで、Dify、LangGraph、AutoGen、AgentEngine、A2A、RAG、ワークフロー型……さまざまな構造のエージェントと格闘してきた。
そして結論はひとつだ。
どのフレームワークを使っても、"構造"を理解しない開発者が作るエージェントは必ず壊れる。
壊れ方は決まっている
- 意図を理解しない
- 場違いな質問を繰り返す
- ループする
- 間違いを閉じたまま増幅する
- 無限に探索する
- 自分で作った誤解を自分で正そうとして壊す
これは、LLMの限界ではない。 エージェントを "APIの集合" と誤解したまま作るからこうなる。
AIは、あなたが書いた手順では動かない。 AIは「文脈」を読み、そこから独自に手順を生成する。
つまり、文脈（役割・価値観・判断軸） が汚れていれば、どれだけ手順を整えてもエージェントは動かない。
逆に言えば、文脈さえ正しく作れば、どのフレームワークでもエージェントは動く。
実装編の目的
理論編（設計編）は、エージェントの"あるべき姿"を定義した。
実装編の役割は違う。
設計思想を、壊れないコードに落とすための"翻訳レイヤー"を作ることだ。
扱う内容：
- 価値観・役割・判断基準をどう実装に落とすか
- 文脈をどう保持し、どう切り替えるか
- どこにタスクを置き、どこから手を引くか
- MCPやAPIをどう抽象化すれば暴走しないか
- 事前計算（レポート化）をどう組み込めばコストがゼロになるか
- LangGraph / AgentEngine / Dify をどこに配置するのが正しいか
- Sub-Agent をどう扱えば壊れないか
こうした「実装上の思考プロトコル」を、言語化し、体系化し、誰が読んでも同じ理解に到達できるようにする。
つまり本書は、
"フレームワークに縛られず、破綻しないエージェントを作れるエンジニア"を生み出すためのOS である。
読者へ
この序章でひとつだけ断言する。
エージェントは難しくない。ただし、構造を知らない人間には一生できない。
あなたがこれから学ぶのは、単なるテクニックではない。
AIに仕事を任せるための "設計の哲学 × 実装のプロトコル" だ。
この本を読み終えるころには、あなたの周囲のエージェントはすべて不十分に見えるだろう。そして、あなた自身が作るエージェントは"壊れない構造" を持ち始める。
Last Updated: 2025-12-07