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