生成AIを「動くデモ」にするのは、いまや簡単です。しかし、**顧客の入力に晒され、業務を動かし、規制と請求書とインシデントに耐える『本番の信頼できるシステム』**にするのは、まったく別の仕事です。そしてその成否は——何度でも繰り返しますが——モデルの賢さではなく、その周りのエンジニアリングで決まります。
本番のLLMアプリを支えるのは、次の6本の柱です。
- セキュリティ — 攻撃（プロンプトインジェクション等）から守る。
- MCP／ツール接続 — AIを外部ツール・データに安全に繋ぐ。
- 評価・テスト — 品質と回帰を守る。
- プライバシー・コンプライアンス — 顧客データ・PIIを守る。
- 信頼性・回復性 — 障害・レート制限・コスト暴走で止めない。
- キャッシュ・性能 — 速く・安く動かす。
この記事は、各柱の深掘り記事への地図（ハブ）であり、それらを貫く1つの設計原則と導入の順序、そして6本柱を1つのリクエストフローに合成した統合コードを示します。まず、6本柱を貫く原則を先に述べます——
LLMを「確率的で信頼できない部品」として扱い、その周りを「決定的なアーキテクチャ」で囲う。
6本柱はすべて、この原則の具体化です。
なぜ「本番AI」は難しいのか
従来のWeb開発は、「信頼できない入力（ユーザー）」と「信頼できるコード（自分たち）」の境界で検証すれば成立しました。LLMアプリでは、この前提が崩れます。
- 非決定的 — 同じ入力でも出力が揺れる。「1回動いた」は保証にならない。
- 出力が自由文で、実質ユーザーが操作しうる — LLMの出力を無検証で下流に流すのは、ユーザー入力を無検証でSQLに渡すのと同じ。
- 外部依存で、失敗する — プロバイダの障害・レート制限・レイテンシスパイクは「いつ起きるか」の問題。
- 信頼境界が曖昧 — RAG・ツール・エージェントが、外部データを次々とプロンプトに流し込む。
- 規制がかかる — PII、越境移転、データ保持。設計の初期に織り込まないと後で止まる。
だから、賢いプロンプトを書くのではなく、決定的な制御をLLMの外側に置く。これが6本柱の共通言語です。
6本の柱：早見表
| # | 柱 | 核心の問い | 最重要の判断 |
|---|---|---|---|
| 1 | セキュリティ | LLMを攻撃からどう守る？ | 出力ゼロトラスト検証＋ツール最小権限＋人間承認 |
| 2 | MCP／ツール接続 | AIを外部ツールにどう安全に繋ぐ？ | ツール＝任意コード実行。最小権限・OAuth2.1・token passthrough禁止 |
| 3 | 評価・テスト | 品質と回帰をどう守る？ | データセット＋自動採点＋CIゲート |
| 4 | プライバシー | 顧客データ/PIIをどう守る？ | PII最小化・ZDR・越境（APPI28条/GDPR28条）を設計に |
| 5 | 信頼性・回復性 | 障害でどう止めない？ | 一時障害限定リトライ・サーキットブレーカ・多プロバイダ・冪等性 |
| 6 | キャッシュ・性能 | どう速く・安く？ | プロンプト＋セマンティックキャッシュ・偽ヒット対策 |
以下、各柱の核心と、深掘り記事へのリンクです。
柱1. セキュリティ：出力を信頼しない
プロンプトインジェクションは、入力フィルタでは原理的に防げません（OWASP LLM01）。防御は入力ではなく、LLM出力をゼロトラストで検証し、ツールを最小権限にし、高影響アクションは人間が承認するアーキテクチャに置きます。詳細は LLMアプリのセキュリティ（OWASP LLM Top 10）。
柱2. MCP／ツール接続：任意コード実行として扱う
AIを外部ツールに繋ぐ標準が MCP。要点は「ツール＝任意コード実行」という前提で、最小権限・提案/実行の分離・OAuth 2.1のトークン検証（token passthrough禁止）。詳細は MCP本番サーバー実装ガイド。
柱3. 評価・テスト：品質を目視で守らない
非決定的な出力の品質は、目視では守れません。データセット＋自動採点（決定的＋LLM-as-judge）＋CIゲートで、回帰をパイプラインが検知します。詳細は LLMアプリの評価・テスト。
柱4. プライバシー・コンプライアンス：送らない設計
API層は既定で学習に使わない——ただし例外あり。PIIを送る前に最小化・マスクし、**ZDR・リージョン固定・越境（APPI第28条/GDPR第28条のDPA）**を設計に織り込みます。詳細は LLMアプリのデータプライバシー＆コンプライアンス。
柱5. 信頼性・回復性：失敗する前提で
LLMは失敗する外部依存です。一時障害限定のリトライ（バックオフ＋ジッター）・サーキットブレーカ・多プロバイダ・フォールバック・冪等性で被害を封じます。詳細は LLMアプリの信頼性・回復性設計。
柱6. キャッシュ・性能：速く・安く
同じ/似た入力を毎回モデルに投げるのは無駄。**プロンプトキャッシュ（静的コンテンツを前に）＋セマンティックキャッシュ（偽ヒット対策付き）**でコストとレイテンシを削減します。詳細は LLMアプリのキャッシュ戦略。
導入の順序（実装ロードマップ）
6本柱は同時にではなく、順序立てて入れます。土台から最適化へ。
- 脅威モデリング — 信頼境界を可視化する（何を守るか）。
- 出力検証＋ツール最小権限（柱1・柱2） — まず被害の爆発半径を小さくする。
- 評価ゲート（柱3） — 壊れたものを出さない仕組みを、機能を増やす前に。
- プライバシー設計（柱4） — 扱うデータが決まったら、送らない/残さない設計を。
- 信頼性（柱5） — トラフィックが乗る前に、止まらない構成に。
- キャッシュ最適化（柱6） — 動いてから、速く・安くする。
統合コード：6本柱を1つのフローに合成する
6本柱は独立した知識ではなく、1つのリクエストフローに合成できます。以下は「信頼できるLLM呼び出し」の骨格で、各ステップが対応する柱（と深掘り記事のコード）に対応します。
// 6本柱を1つのフローに合成した「信頼できるLLM呼び出し」。
async function trustworthyGenerate(input: UserInput, ctx: RequestContext): Promise<Answer> {
// 柱4 プライバシー：送る前に PII を最小化・マスクする
const safe = await redactPii(minimizeFields(input));
// 柱6 キャッシュ：意味的に似た質問は LLM を呼ばずに返す（scope でパーソナライズを隔離）
const cached = await semanticCache.get(safe, ctx.scope);
if (cached) return cached;
// 柱5 信頼性：多プロバイダ・フォールバック＋一時障害限定リトライ＋タイムアウト
// 柱1 セキュリティ：出力は Zod スキーマで検証（ゼロトラスト）
// 柱2 MCP：ツールは最小権限、破壊的操作は「提案」のみ（実行は承認後）
const raw = await generateResilient(safe, {
schema: AnswerSchema,
tools: leastPrivilegeTools,
idempotencyKey: ctx.requestId, // 冪等：リトライで二重実行しない
});
// 柱1 セキュリティ：スキーマ検証を通っても、業務ルールは決定的コードで再確認する
const answer = assertBusinessPolicy(raw, ctx);
await semanticCache.put(safe, ctx.scope, answer);
sampleForOnlineEval(ctx, safe, answer); // 柱3 評価：本番トラフィックを継続評価
return answer;
}
このフローには、6本柱すべてが現れます——PII最小化（4）→ キャッシュ（6）→ フォールバック＆リトライ（5）＋ 出力検証（1）＋ ツール最小権限＆冪等（2）→ 業務ルール再確認（1）→ オンライン評価（3）。どのステップも「確率的なLLMを、決定的なコードで囲う」という同じ原則の現れです。
統合チェックリスト（各柱1項目）
- セキュリティ — LLM出力をスキーマで検証し、業務ルールを決定的コードで再確認しているか。
- MCP／ツール — ツールは最小権限で、破壊的操作は人間承認＋冪等キー経由か。
- 評価 — 固定データセットの合格率でデプロイをゲートしているか。
- プライバシー — PIIを最小化・マスクし、越境（APPI28/GDPR28）を設計に織り込んだか。
- 信頼性 — 一時障害限定リトライ・サーキットブレーカ・多プロバイダ・冪等性があるか。
- キャッシュ — プロンプトキャッシュを土台に、セマンティックキャッシュは高閾値＋TTL＋評価で管理しているか。
まとめ
本番のLLMアプリは、6本の柱で立ちます——セキュリティ・MCP・評価・プライバシー・信頼性・キャッシュ。そしてそのすべてが、たった1つの原則に還元されます。
LLMを確率的で信頼できない部品として扱い、決定的なアーキテクチャで囲う。
出力を検証し、権限を絞り、人間が承認し、品質をゲートし、規制を設計に織り込み、失敗を吸収し、無駄を省く——これらをLLMの外側の決定的なコードで行う。そうすれば、生成AIは「速く作れて、安全で、壊れず、信頼でき、止まらず、そして安い」本番システムになります。作る速さと、守り切る堅さは、正しく設計すれば両立します。
各柱の実装は、上記の深掘り記事へ。この6本を1つずつ設計に落とすことが、デモを本番に変える最短路です。