LLMを組み込んだシステムを設計する前に読むソフトウェアアーキテクチャ書籍ガイド｜トレードオフ・分散データ・境界設計を段階順に固める4冊

LLMを使った機能の試作は、驚くほど早く動きます。APIキーを発行し、SDKを入れ、プロンプトを書けば、その日のうちにデモが見せられます。止まるのは既存システムに組み込む段階です。LLM呼び出しを同期処理の途中に置いたら画面が固まった、RAGのインデックスが元データと食い違ったまま気づかなかった、エージェントに任せた処理が途中で失敗して中途半端な状態が残った。原因を追うと、プロンプトでもモデルでもなく、アーキテクチャの判断に行き着きます。この記事では、その判断を固めるための実在の日本語書籍を4冊、段階順に紹介します。なお本記事は書籍紹介であり広告を含みます。価格・版・在庫・目次は変わるため、最新は各出版社の公式ページでご確認ください。

LLMを入れると、アーキテクチャの判断が前倒しでやってきます#

まず前提を揃えます。LLMのAPIをシステムの部品として見ると、従来の部品とはかなり性質が違います。

• 非決定的です。同じ入力でも出力が揺れ、出力の形式が期待どおりでないこともあります
• 遅いです。多くのLLM呼び出しは、社内DBへの問い合わせと比べて桁違いに時間がかかり、応答時間のばらつきも大きくなります
• 外部にあります。レート制限、障害、モデルの更新や提供終了といった、自分たちで制御できない変化を受けます
• 呼ぶたびに費用がかかります。呼び出し回数と入力の量が、そのままコストになります

どれも単独なら既知の問題です。外部APIも、遅い処理も、失敗する処理も、これまでのシステムにありました。LLMの厄介さは、この4つが1つの部品にまとめて乗っている点にあります。しかも多くの場合、その部品を業務の中心近くに置きたくなります。

エージェントになると、さらに判断が増えます。Anthropicのエンジニアリング記事「Building effective agents」は、LLMとツールをあらかじめ定義されたコードの経路で組み合わせるものをワークフロー、LLMが自分で処理の進め方とツールの使い方を動的に決めるものをエージェントと区別しています。同じ記事は、LLMを使うアプリケーションではできるだけ単純な解決策を探し、必要なときだけ複雑さを増やすことを勧め、エージェントの自律性は高いコストと誤りの累積の可能性を意味する、とも書いています。制御の経路をコードに持つか、LLMに持たせるか。これはプロンプトの話ではなく、アーキテクチャの話です。

LLM部品が持ち込む判断と、それに効く本#

判断の種類ごとに、どの本が効くかを先に示しておきます。4冊の目次を読み比べると、LLMを組み込むときに出てくる問いは、ほぼ次の4つに分かれます。

4段階で読む順番を決める#

アーキテクチャの本は同じ棚に並んでいても、扱う粒度が違います。システム全体の特性の話をしているのか、サービス間のつなぎ方の話をしているのか、データの話をしているのか、業務の切り分けの話をしているのかで、必要な本が変わります。

以下、この順で4冊を紹介します。守備範囲は重なりますが、通読前提の並びではありません。いま詰まっている判断から選ぶための対応表は、記事の後半に置いてあります。

1. 全体像と特性の語彙を揃える(ソフトウェアアーキテクチャの基礎 第2版)#

1冊目は、ソフトウェアアーキテクチャの全体像を扱う本です。Mark RichardsさんとNeal Fordさんの著書、島田浩二さんの訳で、オライリー・ジャパンから2026年3月6日に刊行されました。560ページ、原著は『Fundamentals of Software Architecture, 2nd Edition』です。公式の書誌ページでは、アーキテクチャの定義からアーキテクトの役割、モジュールや結合、アーキテクチャスタイルといった設計の基礎、チームやステークホルダーとのコラボレーションに必要なソフトスキルまでを扱う本と説明されています。

第2版の変更点も同じページに書かれています。各アーキテクチャスタイルがクラウド活用やデータ、チームトポロジー、統制といった共通の観点から整理し直され、イベント駆動アーキテクチャとマイクロサービスアーキテクチャの解説が大幅に拡充され、モジュラーモノリスの解説が新たに追加されたとあります。さらに、アーキテクチャパターンを整理した新章と、LLMを含む新しい技術潮流をどのように設計に組み込むかといったトピックが加筆された、とも説明されています。

構成は3部27章と付録です。第I部「基礎」がアーキテクチャ思考、モジュール性、アーキテクチャ特性とその測定・統制・スコープ、コンポーネントベース思考。第II部「アーキテクチャスタイル」がレイヤード、モジュラーモノリス、パイプライン、マイクロカーネル、サービスベース、イベント駆動、スペースベース、オーケストレーション駆動サービス指向、マイクロサービスの各スタイルと、スタイルの選び方、アーキテクチャパターン。第III部「テクニックとソフトスキル」がアーキテクチャ決定、リスク分析、図解、チーム、交渉とリーダーシップ、アーキテクチャと交わるもの、そして法則の再考です。

LLMシステムのどの判断に効くか#

いちばん効くのは第4章から第7章の「アーキテクチャ特性」の一連です。LLMを組み込む議論が空転するとき、原因の多くは「何を優先するのか」が合意されていないことにあります。応答の速さを取るのか、回答の正確さを取るのか、コストの上限を守るのか、可用性を落とさないのか。4.3「トレードオフと最も現実的なアーキテクチャ」と5.5「アーキテクチャ特性の制限と優先順位付け」は、この議論を「全部大事」で終わらせないための節です。

第7章「アーキテクチャ特性のスコープ」の7.1「アーキテクチャ量子と粒度」と7.2「同期通信」も、LLM部品の置き場所を決めるときに効きます。特性はシステム全体に一律ではなく、同期的につながった範囲ごとに決まる、という考え方です。遅くて揺れるLLM呼び出しを受付処理と同期的につなぐと、受付処理の応答時間と可用性がLLM側に引きずられます。非同期に切り離すと、その代わりに結果の通知や失敗時の扱いを設計する必要が出ます。どちらが正しいかは本には書いていませんが、どちらを選ぶと何を背負うかは読み取れます。

第9章の9.4「モノリシックアーキテクチャと分散アーキテクチャ」には、分散コンピューティングの誤信が並びます。ネットワークは信頼できる、レイテンシーがゼロ、帯域幅は無限、転送コストはゼロ。外部のLLM APIを呼ぶ構成は、この誤信をすべて踏みうる構成です。とくに「転送コストはゼロ」は、入力の量がそのまま費用になるLLM呼び出しでは別の意味を持ちます。

第15章「イベント駆動アーキテクチャ」は、15.2.8「エラー処理」、15.2.9「データロスの防止」、15.2.10「リクエスト・リプライ処理」、15.8.1「リクエストベースモデルとイベントベースモデルの選択」を含みます。LLM呼び出しをキューの向こうに置く設計を検討しているなら、先に読んでおきたい章です。

生成AIを直接扱う節は2か所あります。21.3「アーキテクチャデシジョンレコード」の中の21.3.7「アーキテクチャ決定における生成AIとLLMの活用」と、26.9「アーキテクチャと生成AI」(26.9.1「生成AIをアーキテクチャに組み込む」、26.9.2「生成AIをアシスタントとして活用する」)です。前者はLLMを設計の補助に使う話、後者はシステムの部品として組み込む話と、アシスタントとして使う話に分かれています。ただし全27章のうちの一部であり、この本を「LLMアプリケーション設計の本」として買うと期待とずれます。価値の中心は、LLMを入れる前から必要だった特性とトレードオフの語彙のほうです。

ADRそのもの(21.3)も、LLM導入では実務的に効きます。どのモデルを使うか、呼び出しを同期にするか非同期にするか、どこまでをエージェントに任せるか。LLM周辺の決定は、モデルの更新や料金改定のたびに見直しの圧力がかかります。決定の理由と前提が残っていないと、見直すたびに同じ議論を最初からやり直すことになります。

向かない読者#

アーキテクチャという言葉に馴染みがなく、いまは単一のアプリケーションを実装している段階の方には、560ページは重すぎます。逆に、第1版をすでに読み込んでいる方にとっては、第2版の差分(スタイルの再整理、モジュラーモノリス、パターンの新章、生成AIの節)に価値を感じるかどうかで判断が分かれます。また、LLMのプロンプト設計、RAGの検索精度、評価の手法といったLLM固有の技術は範囲外です。

ソフトウェアアーキテクチャの基礎 第2版 ―エンジニアリングに基づく体系的アプローチ(オライリー・ジャパン)

広告

著者: Mark Richards、Neal Ford / 訳: 島田浩二 / 出版社: オライリー・ジャパン / 2026年3月刊 / 560ページ。原著は『Fundamentals of Software Architecture, 2nd Edition』。アーキテクチャ特性とトレードオフ、主要なアーキテクチャスタイル、ADR、リスク分析を3部27章で扱います。第2版でモジュラーモノリスの解説、アーキテクチャパターンの章、生成AIの節が加わりました。LLM固有の技術(プロンプト設計、検索精度、評価)は扱っていません。

Amazonで見る楽天で見るYahoo!ショッピングで見る

※価格・在庫は変動します。最新の情報は各販売サイトでご確認ください。

2. 分散のトレードオフを分析する(ソフトウェアアーキテクチャ・ハードパーツ)#

2冊目は、分散アーキテクチャで答えの出にくい判断を、トレードオフ分析として扱う本です。Neal Fordさん、Mark Richardsさん、Pramod Sadalageさん、Zhamak Dehghaniさんの著書、島田浩二さんの訳で、オライリー・ジャパンから2022年10月27日に刊行されました。472ページ、原著は『Software Architecture: The Hard Parts』です。公式の書誌ページでは、サービスの粒度やデータの所有権、コードの再利用やワークフローの調整、可用性や信頼性の実現といった難題とそれに対するアプローチやパターンを紹介し、トレードオフについてモノリスを分解してマイクロサービスアーキテクチャに再構築する例を通して説明する本とされています。1冊目と著者が重なり、同ページでも『ソフトウェアアーキテクチャの基礎』の著者らによる本と紹介されています。

構成は2部15章と付録3本です。第I部「分解する」が結合の見分け方、モジュール化、分解、コンポーネントベース分解パターン、業務データの分解、サービスの粒度。第II部「つなぎ合わせる」が再利用パターン、データの所有権と分散トランザクション、分散データアクセス、分散ワークフローの管理、トランザクショナルサーガ、コントラクト、分析データの管理、独自のトレードオフ分析の構築です。多くの章に、架空のチーム「Sysops Squad」の議論を描く「Sysops Squadサーガ」の節が置かれています。

LLMシステムのどの判断に効くか#

エージェントがツールを順に呼んで業務を進める構成は、分散ワークフローそのものです。第11章「分散ワークフローの管理」は、オーケストレーションとコレオグラフィの2つの通信スタイルを比べ、11.3.1「状態の所有者と結合」でワークフローの状態を誰が持つかを扱います。エージェントの文脈に置き換えると、処理の進捗をエージェントの会話履歴の中だけに持つのか、外部の状態管理に持つのか、という問いになります。会話履歴の中だけに持つ構成は、エージェントが途中で落ちたときに、どこまで進んだかを誰も知らない状態を作ります。

第12章「トランザクショナルサーガ」は、8つのサーガパターンに名前を付けて比較し、12.2「結果整合性を備えた状態管理」でサーガ状態マシンを扱います。エージェントが「在庫を引き当て、伝票を起こし、顧客に通知する」処理の2つ目で失敗したとき、1つ目をどう戻すか。補償トランザクションの設計はエージェント固有の発明ではなく、分散トランザクションの問題として整理されています。12.4のサーガの見出しにある「アトミックトランザクションと補償トランザクション」の対比は、エージェントに書き込みを任せる前に一度考えておくべき論点です。

第9章「データの所有権と分散トランザクション」は、単独所有、全体共有、共同所有のシナリオと、9.8「結果整合性パターン」としてバックグラウンド同期、リクエストベースのオーケストレーション、イベントベースの3つを並べます。RAGのインデックスは誰のデータか、という問いにこの章の枠組みが使えます。元データの所有者はインデックスの存在を知っているのか、インデックス側が元データを勝手に読みに行くのか。所有者が曖昧なまま作ったインデックスは、元データの削除が反映されないという形で後から問題になります。

第13章「コントラクト」の13.2「スタンプ結合」も見落とせません。スタンプ結合は、必要な一部だけでなく大きなデータ構造を丸ごと渡してしまう結合で、13.2.2の見出しは「帯域幅」です。LLMに渡すコンテキストでは、これが帯域幅だけでなくトークン数と費用の問題になります。「念のため全部渡す」設計は、LLM部品に対しては高くつきます。

第15章「独自のトレードオフ分析を構築する」は、15.2.3「『コンテキスト外』の罠」や15.2.6「過度な売り込みやエバンジェリズムを避ける」といった節を含み、判断の手順そのものを扱います。新しいフレームワークやエージェント基盤の採用を議論するとき、その道具が自分たちの文脈で何を解決し何を背負わせるのかを言語化するための章です。

向かない読者#

この本の前提は分散アーキテクチャです。単一のアプリケーションとデータベースで足りていて、LLM呼び出しも1か所に閉じている段階なら、まだ読む必要はありません。また、1冊目で扱うアーキテクチャ特性や結合の語彙は前提として使われるため、アーキテクチャの本が初めての方がいきなり読むと、トレードオフの議論の手前で止まりやすくなります。LLMやエージェントを直接扱う章はありません。

ソフトウェアアーキテクチャ・ハードパーツ ―分散アーキテクチャのためのトレードオフ分析(オライリー・ジャパン)

広告

著者: Neal Ford、Mark Richards、Pramod Sadalage、Zhamak Dehghani / 訳: 島田浩二 / 出版社: オライリー・ジャパン / 2022年10月刊 / 472ページ。原著は『Software Architecture: The Hard Parts』。サービスの粒度、データの所有権、分散トランザクションと結果整合性、ワークフローのオーケストレーションとコレオグラフィ、サーガ、コントラクトを2部15章で扱います。単一アプリケーションで足りている段階には早く、LLM・エージェントを直接扱う章はありません。

Amazonで見る楽天で見るYahoo!ショッピングで見る

※価格・在庫は変動します。最新の情報は各販売サイトでご確認ください。

3. データの原理を押さえる(データ指向アプリケーションデザイン)#

3冊目は、分散システムでデータを扱うための原理を扱う本です。Martin Kleppmannさんの著書、斉藤太郎さんの監訳、玉川竜司さんの訳で、オライリー・ジャパンから2019年7月18日に刊行されました。660ページ、原著は『Designing Data-Intensive Applications』です。公式の書誌ページでは、データの量や複雑さ、変化が課題となるアプリケーションを「データ指向」と名づけ、その設計を支える基本概念を解説し、レプリケーション、パーティション、トランザクションなど分散データベースについて扱い、さらにバッチ処理、ストリーム処理などを解説する本と説明されています。

構成は3部12章と用語集です。第I部「データシステムの基礎」が信頼性・スケーラビリティ・メンテナンス性、データモデルとクエリ言語、ストレージと抽出、エンコーディングと進化。第II部「分散データ」がレプリケーション、パーティショニング、トランザクション、分散システムの問題、一貫性と合意。第III部「導出データ」がバッチ処理、ストリーム処理、データシステムの将来です。

LLMシステムのどの判断に効くか#

RAGを運用するチームに最も効くのは第III部です。冒頭のIII.1「記録のシステム(Systems of Record)と導出データ」は、正となる元データと、そこから加工して作られる導出データを区別する考え方を置いています。RAGのベクトルインデックスは、この枠組みでは典型的な導出データです。検索用に元データを分割し、埋め込みに変換し、別のストアに持つ。導出データである以上、元データとの同期は設計しなければ起きません。

第11章「ストリーム処理」の11.2「データベースとストリーム」は、11.2.1「システムの同期の保持」、11.2.2「変更データのキャプチャ」、11.2.3「イベントソーシング」を並べます。元データの変更をどう捕まえてインデックスに伝えるか、という問いに対して、定期的な全件再構築、変更データのキャプチャ、イベントとして変更を流す方式といった選択肢を、仕組みとして理解するための章です。第12章の12.2.3「導出された状態の監視」と12.3.4「信頼しつつも検証を」も、インデックスが元データと食い違っていないかを確かめる運用に直結します。

第4章「エンコーディングと進化」は、スキーマの変化と互換性を扱います。RAGの文脈では、チャンクのメタデータ形式を変える、埋め込みモデルを入れ替える、といった変更が「古い形式のデータと新しい形式のデータが共存する期間」を生みます。本書は埋め込みモデルを扱っていませんが、形式が変わるデータをどう移行するかという問いの立て方はそのまま使えます。

第8章「分散システムの問題」の8.2.3「タイムアウトと限度のない遅延」は、LLM呼び出しのタイムアウト設計に効きます。応答が返らないとき、それが処理中なのか失敗なのかを呼び出し側は区別できない、という分散システムの基本的な困難は、遅くて揺れるLLM APIでより強く表に出ます。第7章「トランザクション」は、エージェントが複数のレコードを更新するときに、どの分離レベルで何が起きうるかを理解する土台になります。

刊行時期と原著第2版について#

日本語版は2019年の刊行で、原著第1版の翻訳です。ベクトルデータベースや埋め込み検索、LLMは扱っていません。原著については、著者のKleppmannさんの公式サイトで、Chris Riccominiさんとの共著による第2版が2026年3月にO'Reilly Mediaから刊行されたと案内されています。一方、日本語版の第2版は、本記事の執筆時点でオライリー・ジャパンの書籍一覧では確認できませんでした。原則を学ぶ目的なら日本語版の第1版でも十分に機能しますが、英語で読める方は原著第2版も選択肢になります。

向かない読者#

660ページの原理の本で、すぐ使える手順書ではありません。RAGを今週中に動かしたい方が最初に読む本ではなく、特定のベクトルデータベースやフレームワークの使い方も載っていません。また、データの規模が小さく、元データの更新も少ないシステムであれば、この本の多くの章は過剰です。効くのは、インデックスと元データの食い違い、更新の取りこぼし、複数ストア間の整合性で実際に困っている段階です。

データ指向アプリケーションデザイン ―信頼性、拡張性、保守性の高い分散システム設計の原理(オライリー・ジャパン)

広告

著者: Martin Kleppmann / 監訳: 斉藤太郎 / 訳: 玉川竜司 / 出版社: オライリー・ジャパン / 2019年7月刊 / 660ページ。原著は『Designing Data-Intensive Applications』(第1版)。データモデル、ストレージ、エンコーディング、レプリケーション、パーティショニング、トランザクション、分散システムの問題、バッチ処理とストリーム処理を3部12章で扱います。ベクトルデータベース、埋め込み検索、LLMは扱っていません。

Amazonで見る楽天で見るYahoo!ショッピングで見る

※価格・在庫は変動します。最新の情報は各販売サイトでご確認ください。

4. 業務の境界を切る(ドメイン駆動設計をはじめよう)#

4冊目は、ドメイン駆動設計の入門書です。Vlad Khononovさんの著書、増田亨さんと綿引琢磨さんの訳で、オライリー・ジャパンから2024年7月20日に刊行されました。408ページ、原著は『Learning Domain-Driven Design』です。公式の書誌ページでは、ドメイン駆動設計はエリック・エヴァンスにより提唱されたソフトウェア設計の手法で、対象とする事業活動(ドメイン)とその課題の観点から、より良いソフトウェアを構築するために関係者が協力する方法を提供する、と説明されています。

構成は4部16章と付録2本です。第I部「設計の基本方針」が事業活動の分析、業務知識の発見、区切られた文脈、文脈どうしの連係。第II部「実装方法の選択」がトランザクションスクリプト、アクティブレコード、ドメインモデル、イベントソーシング、技術方式、通信。第III部「ドメイン駆動設計の実践」が設計の経験則、設計の進化、イベントストーミング、現実世界での適用。第IV部「他の方法論や設計技法との関係」がマイクロサービス、イベント駆動型アーキテクチャ、データメッシュです。各章に演習問題が付きます。

用語について1点補足します。この訳書では、ドメイン駆動設計の用語に日本語の訳語が当てられています。一般に「境界づけられたコンテキスト」と呼ばれる概念は、目次では「区切られた文脈」と表記されています。他の本や記事と読み合わせるときは、対応を意識しておくと混乱しにくくなります。

LLMシステムのどの判断に効くか#

エージェントに業務を任せるとき、最初に決めるべきは「どの業務を任せるか」と「どこまでを1つのエージェントの担当にするか」です。第1章「事業活動を分析する」の1.2.1「業務領域を分類する」は、業務領域を分類して比較する考え方を扱います。第11章の見出しにも「中核から一般へ」「補完から中核へ」といった形で、中核・一般・補完という3つの区分が現れます。原著『Learning Domain-Driven Design』の紹介で広く説明されている整理では、中核は事業の競争力の源泉になる業務、一般はどの会社でも似たやり方で回り既存の解決策で足りる業務、補完は自社固有の事情はあるものの競争力には直結しない業務です。3つを同じ扱いにしない、という発想です。ここから先は本書の主張ではなく編集部の見立てですが、LLMやエージェントに任せやすいのは一般や補完の業務で、中核の業務を任せるなら、なぜそれでよいのかを説明できる必要があると考えます。

第3章「事業活動の複雑さに立ち向かう」は区切られた文脈を扱い、3.2.3「区切られた文脈の大きさをどうするか」と3.4.2「所有権の境界」を含みます。エージェントの担当範囲を決めるとき、この枠組みがそのまま使えます。1つのエージェントに複数の文脈をまたがせると、同じ言葉が文脈ごとに違う意味を持つ問題に直面します。「顧客」「契約」「完了」のような言葉は、部署ごとに意味が違うことが珍しくありません。人間の担当者はその違いを暗黙に使い分けますが、エージェントは説明文に書かれていない違いを使い分けません。

第4章「区切られた文脈どうしの連係」の4.2.2「モデル変換装置」は、外部のモデルが自分たちのモデルを汚さないよう、境界で変換する仕組みを扱います。LLMの出力は、まさに「外部から来る、形式が揺れうるモデル」です。LLMの出力をそのまま業務のデータ構造に流し込まず、境界で検証して変換する層を置く。この発想の元になる考え方がここにあります。

第9章「通信」の9.2「集約どうしの連係」は、送信箱、サーガ、プロセスマネージャーを並べます。2冊目のサーガと同じ主題を、業務ロジックの実装の側から扱う節です。第12章「イベントストーミング」は、業務の流れをイベント、コマンド、ポリシー、読み取りモデル、外部システムで洗い出す手法で、12.4.8「外部システムを追加する」の段階でLLMやエージェントをどこに置くかを業務の人と一緒に議論する場として使えます。

向かない読者#

業務が単純で、画面とデータベースの間でデータを受け渡すだけのシステムであれば、本書の第5章が扱うトランザクションスクリプトやアクティブレコードで足りる、という判断になる可能性が高く、ドメイン駆動設計を持ち込む必要は薄いはずです。また、本書は設計手法の本で、エージェントのフレームワークやツール定義の書き方は扱っていません。業務の人と話す機会がなく、仕様を受け取って実装するだけの立場だと、第I部と第III部の手法を試す場がないかもしれません。

ドメイン駆動設計をはじめよう ―ソフトウェアの実装と事業戦略を結びつける実践技法(オライリー・ジャパン)

広告

著者: Vlad Khononov / 訳: 増田亨、綿引琢磨 / 出版社: オライリー・ジャパン / 2024年7月刊 / 408ページ。原著は『Learning Domain-Driven Design』。業務領域の分類、区切られた文脈と連係、業務ロジックの実装方法、技術方式、イベントストーミング、マイクロサービスやイベント駆動型アーキテクチャとの関係を4部16章で扱い、各章に演習問題が付きます。エージェントのフレームワークやツール定義の書き方は扱っていません。

Amazonで見る楽天で見るYahoo!ショッピングで見る

※価格・在庫は変動します。最新の情報は各販売サイトでご確認ください。

4冊の使い分け#

役割と症状から選ぶための対応表です。刊行時期は、概念そのものより周辺技術の前提がどれくらいずれるかの目安です。

最初の1冊は、議論の土台が無いなら1冊目、RAGの同期で困っているなら3冊目になるチームが多いはずです。2冊目は処理が複数のサービスやステップに分かれてから、4冊目はエージェントに任せる業務の範囲を決める段階で効きます。

書籍だけでは埋まらない、LLM固有の部分#

4冊を読んでも、LLM部品の性質そのものに由来する次の3つは、自分たちで設計する部分として残ります。

非決定的な部品の品質をどう確かめるか#

従来のテストは、同じ入力には同じ出力が返ることを前提にしています。LLM部品にはこの前提が成り立たないため、評価用のデータセットと評価の手順を別に持つ必要があります。4冊のいずれも、この評価の仕組みは扱っていません。1冊目の第6章が扱う適応度関数の考え方は近いところにありますが、LLMの出力の良し悪しを測る具体的な方法は別の資料で補う必要があります。

モデルとプロンプトの変更をどう管理するか#

LLM部品は、自分たちがコードを変えなくても、提供元のモデル更新で振る舞いが変わりえます。プロンプトの変更も、コードの変更と同じくらい挙動に影響します。これをどう版管理し、どう切り替え、どう戻すかは、書籍ではなく運用の設計です。1冊目のADRは「なぜそのモデルを選んだか」を残す器にはなりますが、切り替えの仕組みそのものではありません。

費用をアーキテクチャの特性として扱うか#

呼び出し回数と入力の量がそのまま費用になる部品は、従来のアーキテクチャ特性の一覧では扱いにくい存在です。キャッシュ、バッチ化、小さなモデルへの振り分けといった手段はありますが、どれを採るかは費用の上限と応答品質のトレードオフで、LLMの料金体系と自社の利用量に依存します。

明日からできる最初の一歩#

本を読み終えてから設計を見直そうとすると、たいてい着手できません。いま組み込もうとしている機能に、小さく順番に問いを当てていくほうが現実的です。

この順序は、4冊が扱う内容をLLM導入の文脈に置き換えたものです。1と2は1冊目、3は3冊目と2冊目の第9章、4は2冊目の第11章と第12章、5と6は4冊目に対応します。どの手順で手が止まったかで、読むべき本が決まります。

よくある質問#

まとめ#

LLMを既存システムに組み込む作業は、新しい技術の導入であると同時に、これまで先送りできていたアーキテクチャの判断の前倒しでもあります。遅い外部呼び出しをどこに置くか、派生データをどう同期するか、途中で失敗した処理をどう戻すか、業務のどこで境界を切るか。どれもLLM以前から存在した問いですが、LLM部品はそれを一度にまとめて突きつけてきます。

今回紹介した4冊は守備範囲が違います。特性とトレードオフの語彙を揃える本、分散のトレードオフを分析する本、データの原理を押さえる本、業務の境界を切る本。生成AIを正面から扱うのは1冊目の一部だけですが、だからこそモデルが何世代変わっても使えます。まずはいま詰まっている判断に対応する1冊を選び、組み込もうとしている機能のADRを1枚書くところから始めてみてください。