LLMアーキテクチャ：プロダクションAIのためのシステム設計
モデルの実行はインフラストラクチャの問題です。モデルから価値を引き出すことはアーキテクチャの問題です。
インフラストラクチャ層（ランタイム、ハードウェア、APIエンドポイント）は、何が可能かを決定します。アーキテクチャ層は、リクエストに対して実際に何が起こるかを決定します。どのモデルが処理するか、コストはいくらになるか、何が検証するか、そして障害がどのように捕捉されるかです。
ほとんどのシステムは、1つのモデルと、アーキテクチャなしで開始します。これはプロトタイピングには正しいアプローチです。しかし、本番環境では負債となります。
LLMアーキテクチャは、「呼び出せるモデル」を「依存できるシステム」に変えるための設計決定をカバーします。
LLMアーキテクチャがスタックの中で占める位置
LLMアーキテクチャは、3層モデルの中間に位置します：
| レイヤー | 対象範囲 | 関連領域 |
|---|---|---|
| モデル | ランタイム、サービング、GPU設定 | LLMホスティング · LLMパフォーマンス |
| アーキテクチャ | ルーティング、コスト、ガードレール、オーケストレーション | ここにあります |
| アプリケーション | AIアシスタント、RAGパイプライン、エージェント | AIシステム · RAG |
アーキテクチャ層は初期段階でしばしば省略されます。しかし、複数のモデル、複数のタスクタイプ、または複数のユーザーを抱えるようになった際には、不可欠なものとなります。このクラスターのすべてのアーキテクチャパターンは、「すべての用途に1つのモデル」というアプローチが機能しなくなったために存在します。
クラスターマップ
このクラスターの5つのトピックは互いに構築されています。最も論理的なパスのために、以下の順序で読んでください：
- ここにあります — この柱：LLMアーキテクチャとは何か、各要素がどのように組み合わされるか
- プロンプト — LLM向けの効果的なプロンプトの書き方 — 基礎：モデルが受け取るものを形作る
- ルーティング — モデルルーティング戦略 — ディスパッチャー：どのモデルが何を処理するか
- コスト — LLMシステムのコスト最適化 — トークン予算管理、キャッシング、ローカル対APIの経済性
- 安全性 — 実践的なLLMガードレール — 入力検証、出力フィルタリング、コンプライアンス
- オーケストレーション — マルチモデルシステム設計 — 逐次、並列、階層、アンサンブルパターン
1つだけ読む時間がある場合は、ルーティングから始めましょう。それはアーキテクチャが開始する意思決定のポイントです。
プロンプトエンジニアリング
プロンプトエンジニアリングはモデルに最も近いレイヤーです。ルーティングも、キャッシングも、ガードレールも、すべてプロンプトがあります。モデルに送信するものが、受け取るものを決定します。
実務的に重要なテクニック：
- 明確さと構造 — 明確な指示が巧妙なフレーミングよりも優れています
- 具体的な例 — 少数ショット（few-shot）の例がモデルの振る舞いを固定します
- 役割の割り当て — 役割ベースのプロンプトがトーンと制約をシャープにします
- 多様なアプローチ — 異なるフォーマットが、モデルが何に反応するかを明らかにします
- コンテキスト管理 — 含めるものが、モデルが何を重視するかを形作ります
プロンプトエンジニアリングは一度きりのタスクではありません。それは、タスクの要件とモデルの振る舞いの間の継続的な調整です。
詳細：
- LLM向けの効果的なプロンプトの書き方 — 言語モデルのパフォーマンスのための実用的なテクニック
モデルルーティング
ルーティング層は、どのリクエストをどのモデルが処理するかを決定します。それなしでは、すべてのリクエストが同じモデルに送られます。それは単純なタスクには大きすぎ、複雑なタスクには小さすぎるモデルです。
4つのルーティング戦略は、ほとんどの本番環境のケースをカバーします：
| 戦略 | 最適化対象 | 最適な状況 |
|---|---|---|
| 能力ベース | タスクの質 | 複雑さが混在したワークロード |
| コスト意識型 | トークン支出 | 予算が制約されたシステム |
| レイテンシ意識型 | レスポンス時間 | インタラクティブなツールとリアルタイムチャット |
| ハイブリッド | すべて | 現実の制約がある本番システム |
フォールバックチェーンは障害を処理します。モデルを最良から最も信頼できる順に並べ、APIの障害によりレート制限されたりシャットダウンされたりしないローカルモデルで終了します。
詳細：
- モデルルーティング戦略：ローカル対API、コスト意識型、レイテンシ意識型 — 能力ベース、コスト意識型、レイテンシ意識型のルーティングとPythonコード
コスト最適化
LLMのコストは使用量に線形に比例します。実際に請求額を削減する戦略：
トークン予算管理は、セッションごと、タスクごと、または適応的な制限を設定します。適応的予算は実際の使用を追跡し、時間とともに配分を厳しくします。
ローカル推論はコスト構造を完全に改变します。ハードウェアの償却後、ローカルモデルは電気代で実行されます。適度な使用でのGPUは、数ヶ月で元を取ります。
キャッシングは最も過小評価されている最適化です。完全一致キャッシングは繰り返されるプロンプトを捕捉します。セマンティックキャッシングは同じ意味を持つプロンプトを捕捉します。高トラフィックシステムでは、セマンティックキャッシングは発生する前にAPI呼び出しの大部分を排除します。
フォールバックチェーンはリクエストあたりの平均コストを削減します：予算が許す場合は高価なモデルを優先し、セッションが進むにつれて安価またはローカルのものにフォールバックします。
詳細：
- LLMシステムのコスト最適化：トークン予算管理、フォールバックモデル、キャッシング — 実際のハードウェア数値、損分点テーブル、そして動作するPythonパターン
ガードレール
LLMはデフォルトで予測不可能です。ガードレールは、モデルの能力を損なうことなく、入力と出力を制約します。
実務的に重要な3つのガードレールレイヤー：
入力検証は、問題がモデルに到達する前にそれを止めます。プロンプトのサニタイズはインジェクション試行を捕捉します。長さの制限はトークンの浪費を防ぎます。コンテンツフィルタは、推論が何らかのコストを発生させる前にポリシー違反をブロックします。
出力フィルタリングは、生成後の問題を捕捉します。構造化検証は期待されるレスポンスの形状を保証します。コンテンツチェックは有害な出力をブロックします。事実チェック（重要なドメイン向け）は、知識ベースに対して主張を検証します。
安全メカニズムはシステムを長期的に保護します：レート制限は不正利用を防ぎ、トークン予算はリクエストごとのコストを上限に設定し、コンテキストウィンドウ管理はオーバーフローとターンの間のデータ漏洩を防ぎます。
コンプライアンスが重視されるシステム（GDPR、HIPAA、SOC 2）では、構造化された追記専用エントリとデータレジデンシ制御を持つ監査ログを追加します。
ガードレールはモデルの会話を処理しますが、エージェントがツールを呼び出し、他のエージェントに作業を委譲するようになったら、2番目のセキュリティ層が必要になります。誰が、誰の代わりに、どのような監査証跡で行動できるか。それはモデルのI/Oフィルタリングではなく、プロトコルセキュリティです。
詳細：
- 実践的なLLMガードレール：入力検証、出力フィルタリング、安全性 — 実用的なガードレールパターンとコンプライアンスに関する注記
- A2AとMCPエージェントセキュリティ：アイデンティティ、委譲、監査証跡 — プロンプト安全性を超えたエージェントプロトコルセキュリティ：アイデンティティ、認可、ゲートウェイ、そして委譲制御
マルチモデルシステム設計
単一のモデルでは不十分な場合、アーキテクチャの問いは：複雑さを節約するよりもコストがかかることなく、どのように複数のモデルをオーケストレートするかです。
5つのパターンがその領域をカバーします：
| パターン | レイテンシ | コスト | 質 | 使用状況 |
|---|---|---|---|---|
| 単一モデル | 最低 | 最低 | 変動あり | プロトタイピング、一様なワークロード |
| 逐次（パイプライン） | 高 | 中 | 高 | 専門分野を持つマルチステップワークフロー |
| 並列（ファンアウト） | 低 | 高 | 高 | 独立したタスク、A/Bテスト |
| 階層的（プランナー-エグゼキュータ） | 高 | 高 | 最高 | 専門家の実行を伴う複雑な推論 |
| アンサンブル | 中 | 最高 | 最高 | 合意を必要とする重要な決定 |
経験則：実際の制約を処理できる最も単純なパターンから始めます。ほとんどの本番システムは、能力ベースのルーティングだけでは不十分になった後に、並列または階層的なパターンに到達します。
詳細：
- マルチモデルシステム設計：どのモデルをいつ使用し、なぜか — 動作するPythonコードとトレードオフテーブルを含む5つのパターンすべて
アーキテクチャ意思決定フレームワーク
何を追加し、いつ追加するかを迅速に分類するためにこれを使用します：
| 問題 | 解決策 | 追加すべきタイミング |
|---|---|---|
| 請求額が高すぎる | コスト意識型ルーティング、キャッシング、ローカル推論 | APIコストが実際の予算項目になったとき |
| レイテンシが高すぎる | レイテンシ意識型ルーティング、より小さなモデル | ユーザーが遅さに気づいたとき |
| 質が安定しない | 能力ベースルーティング、フォールバックチェーン | 単純なタスクが高価なモデルを受けたり、複雑なタスクが安価なモデルを受けたりしたとき |
| ユーザーがシステムを悪用している | 入力検証、レート制限 | 信頼できるチーム以外のアクセスを開いたとき |
| レスポンスが安全でない、またはポリシー違反 | 出力フィルタリング、コンテンツガードレール | 一般ユーザーをサーブするとき |
| 1つのモデルがすべてを処理している | マルチモデル設計 | ワークロードが複雑さを正当化するほど分岐したとき |
| プロンプトが機能しない | プロンプトエンジニアリングの反復 | 常に — プロンプトはタスクが進化につれて調整が必要です |
アーキテクチャはボトムアップで構築します。プロンプトエンジニアリングは常に範囲内です。コスト/質のトレードオフが現実的になったときにルーティングを追加します。外部ユーザーをサーブするときにガードレールを追加します。最後にマルチモデルオーケストレーションを追加します。
LLMアーキテクチャと他のトピックとの関係
LLMアーキテクチャは、いくつかの関連するクラスターの交差点にあります：
インフラストラクチャ（このレイヤーの下）：
- 2026年のLLMホスティング：ローカル、セルフホスト、クラウドインフラストラクチャの比較 — ランタイム（Ollama、llama.cpp、vLLM）、ハードウェア、サービングの決定。アーキテクチャパターンは利用可能なインフラストラクチャに依存します。コスト意識型ルーティングは、ローカルとAPIの両方のモデルを実行している場合にのみ意味があります。
- 2026年のLLMパフォーマンス：ベンチマーク、ボトルネック、最適化 — レイテンシ数値、VRAMの制限、スループットの測定。これらはルーティングとモデル選択の決定に対する実証的な入力です。
アプリケーションレイヤー（このレイヤーの上）：
- AIシステム：セルフホストアシスタント、RAG、ローカルインフラストラクチャ — ルーティング、ガードレール、オーケストレーションの決定を消費するシステム。マルチモデルアーキテクチャは、本番環境のAIアシスタントの前提条件です。
- 検索拡張生成（RAG）チュートリアル — RAG自体がアーキテクチャパターンです：LLMにコンテキストを供給する検索パイプライン。このクラスターからのルーティング、コスト、ガードレールのパターンは、RAGパイプライン内でも適用されます。
運用レイヤー：
- 可観測性：モニタリング、メトリクス、Prometheus、Grafanaガイド — 本番LLMアーキテクチャには可観測性が必要です。コスト追跡、レイテンシモニタリング、ガードレール違反メトリクスはすべて、インフラストラクチャ層だけでなく、アーキテクチャ層での計装を必要とします。
