■ 1. 本書の位置づけ
- 組み込むエンジニアリングの本:
- LLMの理論や使い方ではなく、LLMやAIエージェントをソフトウェアに組み込む方法を扱う
- そのための設計パターン・アーキテクチャを扱う
- 運用・改善のプラクティスを扱う
- 扱わないもの:
- プロンプト集やコツ
- 特定プロダクトの操作マニュアル
- モデルの学習理論や数式の解説
- サンプルコードの公開:
- PythonサンプルコードをGitHubで公開する
- CLAUDE.md/AGENT.mdも同梱し、コーディングエージェントで開発するときもそのまま使える
- 書誌情報:
- 翔泳社刊、2026年8月20日発売予定、ISBN 978-4-7981-9431-8
■ 2. 執筆の経緯
- 2022年11月の驚愕:
- ChatGPTの登場により、人間にしかできなかった知的作業を軽々とこなす技術が現れた
- 心血を注いだ前著『機械学習システム構築実践ガイド』の出版と同年同月であった
- 当時のAIチャットボット開発の難しさを解いたばかりだった
- 2年がかりの本が一瞬で過去のものに:
- 衝撃と同時に、これは新しい冒険の始まりだと直感した
- 転機はFunction Calling:
- 2023年6月に登場した関数呼び出しが転機となった
- 自然言語の応答はロジックに組み込めなかった
- 出力を構造化データとして扱えるようになり、検証・連携とプログラムへの統合が可能になった
- 執筆の決意:
- LLMはソフトウェアエンジニアリングに新たなパラダイムを生むと確信した
■ 3. LLM/AIエージェントの動向
- 本質はソフトウェア:
- LLM単体は重みパラメータの集合にすぎず、組み込んで初めて価値になる
- ソフトウェア工学の知見を適用・拡張する
- 用途の広がり:
- 情報収集はChatGPTに相談しながら調べる新しい情報の得方
- 文章・アイデアはNotion・Google Docsの生成/要約、企画支援
- ソフト開発はCursor / Claude Code / Copilot / Codex
- デザインはFigma・Canvaの画像生成・提案
- LLM自体の不確実性:
- 同じプロンプトでも出力が変わる
- 事実に基づかない生成であるハルシネーションが起きる
- HTTP 200が返っても中身が不安定
- エンジニアリングの不確実性:
- LLM/AIエージェントをどう設計、実装、テストすべきかが定まっていない
- 最適な組み込み方法は試行錯誤の段階
- 正しいか不明だが動いてはいるという曖昧さが残る
- 不確実性への対処の鉄則:
- 不確実な要素は、局所化して制限し、評価する
- 局所化は予測不可能な挙動を特定のレイヤーに閉じ込めること、例としてLLM出力を専用層で構造化する
- 制限は影響範囲をシステム全体に広げないこと
- 評価は出力直後の検証・テスト・運用モニタリングとHuman-in-the-Loop
■ 4. 本書の全体像
- 5章39手法の構成:
- 第2章の組み込みの基礎が12手法
- 第3章のAPI活用が5手法
- 第4章のパイプライン/エージェントが8手法
- 第5章のAIエージェント設計が7手法
- 第6章の応用プラクティスが7手法
- 基礎から応用まで段階的に積み上がる
- サンプルコードの方針:
- Python / uv / Dockerで再現可能
- 主要ライブラリはopenai・google-genai・anthropic・langgraph
- プロバイダに優劣はつけず、OpenAI/Anthropic/Googleを使って実装する
- 各ディレクトリにREADME、CLAUDE.md、AGENT.mdを置くAIコーディング前提の構成
- サンプルコード自体をAIコーディングエージェントで開発した
- 人間による開発だけでなく、エージェントによる開発でも活用できるよう設計した
■ 5. 第2章: LLM組み込みの基礎
- 章の狙い:
- LLMを安定的に活用するための技術的基盤を網羅する
- 収録する12手法:
- 出力の構造化、動的な構造化出力、非構造化データの構造化
- LLMOpsのための構造化ログ、非同期バッチ処理、ストリーミング
- LLM-as-a-Judge、プロンプトのテンプレート化、プロンプトのユニットテスト
- プロンプトのプロファイリング、関数呼び出し、スクリプト生成と実行
- 出力の構造化:
- LLMを会話するモデルから型付きインターフェースを持つ部品へ変える
- 不安定な出力をそのままロジックに流さない
- 境界でJSON Schema/Pydanticにより検証可能な構造へ変換する
- 境界が不確実性を局所化する地点となる
- パイプライン・ツール連携・評価・ログはすべて構造化データの上に乗る
- LLM-as-a-Judge:
- 生成LLMと評価LLMを分離し、確率的な出力の品質をスケーラブルに評価する
- 合格なら採用し、不合格ならプロンプト・温度を変えて再生成するループを回す
- 同期評価と非同期評価はユースケース次第で使い分ける
- 評価モデル・プロンプトを固定してブレを抑え、ドリフトを防止する
- 評価結果をテストや運用モニタリングに蓄積する
- プロンプトのテンプレート化とユニットテスト:
- プロンプトをコードとして記述・管理・テストする
- 品質を左右するテキストを変数入りの構造で記述する
- 期待出力をアサートして回帰を検出し、Gitでバージョン管理・レビューする
- プロファイラで品質・コスト・レイテンシを計測して可視化する
- LLM/AIエージェントに対するPredictive Test Selectionへつなげる
■ 6. 第3章: LLM APIの活用
- 章の狙い:
- 不安定な外部APIを、信頼できるサービスとして扱う
- 収録する5手法:
- Adapter/Factoryパターン、タイムアウト・フォールバック、適応的バックオフによるリトライ
- リクエスト量の制御であるレート制限・優先度、APIゲートウェイ設計
- AdapterとFactoryパターン:
- OpenAI GPT/Anthropic Claude/Google Geminiを1つのインターフェースで扱う
- アプリは共通インターフェースの型だけに依存し、SDKの差を隠す
- Factoryで生成を一元化し、設定でプロバイダを選択・差し替え可能にする
- 提供終了・更新・フォールバック/A/Bテストに対応でき、変化に強くなる
- 落ちる前提で設計する:
- タイムアウトで巨大推論ゆえの遅延・暴走を打ち切る
- フォールバックで代替モデル・経路へ切り替えて処理を継続する
- 429や5xxは適応的バックオフで待機を伸ばして再試行し、一時障害を吸収する
■ 7. 第4章: パイプラインとAIエージェントの設計
- 章の狙い:
- 大規模なLLMシステムを、保守性高く構築する設計原則を示す
- 収録する8手法:
- CQRS、サービスインターフェースの分離、機能単位の部品分離、LLMパイプライン
- ワークフローオーケストレーション、依存性注入、AIエージェントの抽象化設計、安定コアと柔軟な拡張の分離
- CQRSと部品分離:
- 状態を変える処理と読む処理を分け、機能を疎結合の部品にする
- LLMによる情報生成・登録はCommand側でQueueとWorkerを経て書き込みストアへ向かう
- LLMによるQ&AはQuery側でSearch APIを経て読み取りストアを参照する
- 書き込みの副作用が読み取りに漏れないよう影響範囲を制御する
- 機能単位の分離とインターフェース分離で保守性を確保する
- 3層の組み立て:
- パイプラインで複数のLLM呼び出しや外部連携を段階的に構成する
- オーケストレーターが分岐・再試行を含む複雑フローを管理する
- DIコンテナで依存を注入し、テスト容易性と差し替え可能性を確保する
- 安定コアと柔軟な拡張:
- 変えたくない部分と変え続ける部分を分ける
- LLM interface、AgentTool interface、Auth/Log/Securityを安定コアとし、むやみに変えない
- 実験的で変化の速い機能はプラグインとして着脱可能な拡張にする
- コアと拡張の接続はインターフェース経由とする
■ 8. 第5章: AIエージェント設計
- 章の狙い:
- ユースケースに応じたエージェント・アーキテクチャのカタログを提示する
- 収録する7手法:
- ReAct型、マルチAIエージェント、多層型AIエージェント、パイプライン型AIエージェント
- イベント駆動型AIエージェント、学習型AIエージェント、既存ソフトウェアへの組み込み
- ReAct型エージェント:
- 思考、行動、観察のループを回して複雑なタスクを解く
- 状況に応じて次の一手を推論し続ける
- 検索・計算・APIを行動として実行する
- ループ暴走、コスト、観察によるコンテキスト汚染に注意する
- 3つの協調型:
- マルチエージェントは複数エージェントが対等に協調して解く
- 多層型はスーパーバイザーがワーカーを統治する階層アーキテクチャ
- イベント駆動型はイベントバスで発行者と購読者を疎結合にし、スケーラブルにする
- 学習型と既存システムへの組み込み:
- 実行結果をメモリや経験ストアに保存して経験を蓄積する
- 次回以降に参照して継続的に賢くなる改善ループを回す
- エージェントを既存のAPI、DB、サービスへ接続し、運用資産とする
■ 9. 第6章: 応用プラクティス
- 章の狙い:
- 品質・コスト・UXをさらに引き上げる発展的手法を扱う
- 収録する7手法:
- LLMの自由度を下げて安定させる、LLM SDKの薄いラッパーライブラリ、複数推論と候補評価
- 不要な過去を忘れやり直す、関数呼び出しのエンジニアリング、関数呼び出しのTool Chain、AIエージェントのメモリ更新戦略
- Best-of-Nと薄いラッパー戦略:
- UIで選択肢を制限してLLMの自由度を下げ、出力を安定化させる
- N個を並列生成し、LLM-as-a-Judgeで評価して最良の候補を採用する
- 公式SDKを薄く包み、同じインターフェイスで独自の拡張機能を追加する
- 薄いラッパーにより開発工数を減らしつつ拡張する
- コンテキスト管理とメモリ更新戦略:
- 間違いで汚染された過去を捨て、やり直し、記憶を正しく更新する
- 汚染された履歴を切り戻し、健全な時点からやり直すロールバックを行う
- 複数セッションを並列に実行するパラレルワールドで探索する
- メモリストアは出所、TTL・減衰、忘却により記憶を健全に保つ
■ 10. 読者特典: Methodology EngineeringとLooped Harness Engineering
- 特典の前提:
- 本編は2025年末までの、人間が主体でコーディングエージェントは補助という前提に立つ
- 特典は2026年の、コーディングエージェントが主役となる時代を前提とする
- 便利は制御に先行する:
- 便利さは常に制御より先に来るため、制御を後から埋め込む
- ソフトウェアを作るインターフェースが自然言語になり、誰もがソフトウェアを作る時代になる
- 生産量は桁違いに増えるが、Shadow AIも増える
- 設計・セキュリティ・非機能・コストはブラックボックスのまま積み上がる
- 生産量の爆発が、そのまま運用負債の爆発になる
- ルール文書の限界:
- CLAUDE.md/AGENT.mdはプロジェクトの憲法だが、それだけでは足りない
- 指示はお願いにすぎず、確率的にしか従われない
- 文章で全場面を網羅できない
- Methodology Engineering:
- 方法論をエージェントが読み込んで実行できるソフトウェア資産にする
- 方法論はTDD・DDD・SOLID・デザインパターンのような共通認識でありコミュニケーションツール
- 「DIで作って」の一言で意図が伝わる
- エージェントは読み込んだ瞬間から実践するため、伝達コストがほぼゼロになる
- 人間が研修や経験で内面化してきたものが、即実行される
- 方法論がコンパイル可能・反証可能になる
- EvalでA/Bテスト・効果測定・回帰テストができる生きた資産になる
- Looped Harness Engineering:
- ハーネスはエージェントを取り囲む実行環境一式であり、コーディングエージェントのDevOpsにあたる
- 方法論を環境として強制・補助・検証・観測し、ループで育てる
- 制約はしてはいけないことを不可能にする
- 補助は正しいやり方を最も簡単な道にする
- 検証は結果の正しさを機械的に確認する
- 観測は記録して次の改善につなげる
- Fool Proofingとして、人間の注意力に頼らず間違えようのない治具を作る
- セッションは揮発するため、学びをMaster Harnessに外部化して組織学習にする
- 三層ループ:
- 決定論ファースト、LLMロングテールを方針とする
- インナーループはセッション内でエージェントが実装、検査、自己修正を行い、人間の介入なく最速で回る
- ミドルループは変更単位のPRでCIの決定論テストと選定Evalを行い、人間とレビューエージェントが承認する
- アウターループはチーム/組織でテレメトリ・障害・Evalの傾向を分析し、方法論とMaster Harness自体を改訂する
- 目標関数は信頼可能な変更量
- ルールで解けるならルールへ寄せる最小エージェンシーを取り、第1章の鉄則の組織スケール版とする
- 本編手法の翻訳:
- 開発・運用の実践主体が人間からエージェントへ移っても、作り方の原則やアーキテクチャは失効しない
- 構造化I/Oはスキーマ駆動とし、ルール文書とフック検査で強制する
- コンテキストとメモリはデータデザインカタログで設計を統治する
- ツールとMCPはSingle Tool Gatewayで認可・監査を一元化する
- EvalはPredictive Test Selectionで賢く選定実行する
■ 11. 執筆秘話
- 書けなかった生成AIエンジニアリング本:
- 2023年からの当初の構想は生成AI全般のエンジニアリング本だった
- 画像生成、動画生成、コーディングエージェント、LLM・AIエージェントを対象に想定していた
- 全方面で技術の変化が早く多岐にわたり、書き切れなかった
- 1年悩んだ末にLLMとAIエージェントのエンジニアリングへ焦点を絞り、ようやく前へ進んだ
- 後悔:
- 本書は数年前に書いた『機械学習システムデザインパターン』の書き方をLLM/AIエージェントに転換したものにとどまった
- 新しい技術を使うエンジニアリング方法集という枠を出られなかった
- 既知のコンフォートゾーンを出て、新しい境地に至るテーマと内容にならなかった
- 2つのいたちごっこ:
- 進化との競争では、執筆中に各社やOSSが同じ機能を提供し、内容が重複していった
- 論文やテックブログの公開により、内容が時に矛盾していった
- 自分との競争では、書くうちに新しいアイデアが次々湧き、盛り込みたい内容が増え続けた
- 唯一の対応策は、ある時点で区切りを付けて出版すること
- 初稿は2025年末で、2026年のHarness/Loop Engineeringや新モデルの変化は追いきれない
- 諦めなければ永遠に出せない
- AIと猫と共に執筆:
- 本書自体がAIを相棒に開発する実践の産物
- 知見整理にChatGPT・Gemini・Claude、実装にCursor・Copilot・Claude Codeを使った
- 編集者の宮腰さん、査読の恩田さん、矢野目さん、校正/検証協力者に感謝する
- 膝で寝ていた飼い猫マルグレーテと、猫缶を要求し続けた飼い猫ウィリアムと共に書いた
■ 12. エンジニアリングの将来
- 将来の論点:
- エンジニアの経済プレイヤー化と次の方法論を主題とする
- 抽象度が一段上がる:
- 機械語から高級言語へ、手作業構築からInfrastructure as Codeへと抽象度が上がってきた
- 手動リリースからCI/CDへと抽象度が上がってきた
- コードを書くことから、作り方の作り方を作ることへ移る
- エンジニアの仕事は、誰もが信頼できるソフトを作れる仕組みをエンジニアリングすることになる
- まだ実現されていないもの:
- ラリー・テスラーの「AIとは、まだ実現されていないもののことである」という言葉を引く
- 当たり前になった技術は道具と呼ばれる
- その先に新しいまだ実現されていないものが現れる
■ 13. まとめ
- 不確実性に対処し、方法論とハーネスを組織の資産にする
- 鉄則は、局所化して制限し、評価すること
- 手法は基礎からAPI、設計、エージェント、応用へと積み上がる
- 特典はMethodology EngineeringとLooped Harness Engineering
- サンプルコードはGitHubのllm-best-practice-book-programで公開する
- 特典は翔泳社サイトでSHOEISHA iD登録により入手できる