どの企業の情報システム部門にも、「プロジェクトの墓場」が存在します。
そこには、2024年に経営会議を沸かせたデモ、選び抜かれた3つの質問でChatGPTを上回ったRAGプロトタイプ、サンドボックス環境で無敵に見えたAIコパイロットが眠っています。そして、誰かが本当に難しい質問を投げかけます — 4,000人の従業員の前に出せるのか? ERPと連携できるのか? 顧客データに対して、監査と個人情報保護法の要件を満たした上で運用できるのか? — その瞬間、プロジェクトは静かに「フェーズ2」へと送られます。
フェーズ2は始まりません。
業界レポートによれば、エンタープライズAI施策の失敗率は調査主体によって70%から85%の間とされています。私たちが10年以上にわたってサイバーセキュリティ、ERP、製造、ECの分野でアーキテクチャレビューとシステム統合を手がけてきた経験でも、数字はほぼ同じです — 救済を依頼されるパイロット案件のうち約5件に4件は、そもそも本番に到達する現実的な道筋を最初から持っていません。
本記事は、SOWに署名する前にあらゆるCTOに読んでおいてほしい現場ガイドです。
プロダクションギャップとは
プロダクションギャップとは、動くデモと、運用チームが日曜の午前3時に運用できるシステムとの間の距離です。これはモデルの問題であることはほとんどなく、ほぼ常にアーキテクチャ、データ、運用の問題です。
flowchart TD
A["デモ<br/>選定された入力、開発マシン"] --> B["POC<br/>単一データセット、単一ユーザー、SLAなし"]
B --> C["プロダクションギャップ<br/>多くのプロジェクトが停滞する地点"]
C --> D["パイロット<br/>実ユーザー、実データ、オンコール体制なし"]
D --> E["本番環境<br/>SLA、可観測性、監査証跡"]
E --> F["運用<br/>コスト管理、モデルドリフト、変更管理"]
C -.->|"多くはここで終わる"| G["プロジェクトの墓場"]
このギャップを越えるには、不愉快な7つの問いに答える必要があります。それぞれが、私たちが繰り返し目にしてきた失敗パターンに対応しています。
パターン1:「正しい」の定義を誰もしていない
ほとんどのAIパイロットは「何ができるか試してみよう」から始まります。半年後、経営層が精度の数値を求めても、誰も提示できません — ラベル付けされた評価セットなど存在せず、デモ用のプロンプトが数本あるだけだからです。
症状: モデルが「十分良い」かどうかを、チームが感覚で議論している。
対処: モデルより先に評価セットを作ることです。代表的な質問を200〜500件、期待される回答とともに整え、継続的にスコアリングします。これがなければ羅針盤なき航海です。あれば、モデルの差し替え、プロンプト変更、検索の調整は、宗教論争ではなく測定可能な工学的意思決定になります。
パターン2:検索(リトリーバル)を後回しにした
RAGシステムにおいて、LLMは安価なパーツです。検索品質こそがシステムそのものです。にもかかわらず、ほとんどのパイロットは予算の90%をプロンプトエンジニアリングに、10%をembedding・chunking・indexing戦略に投じてしまいます。
症状: ソース文書に明確に書かれている内容について、モデルがハルシネーションを起こす。
対処: 検索をファーストクラスのエンジニアリング問題として扱います。コーパスがそれを要求するなら、性能の高い多言語embeddingモデルを使うこと(日本語、中国語、タイ語混在のコーパスでは multilingual-e5-large を既定としています)。チャンク分割は意味的な構造 — 章節、表、見出し — に従って行うべきで、512トークン窓ではありません。検索のrecall@kはエンドツーエンドの回答品質とは別に計測してください。評価セットでrecall@5が90%を下回るなら、プロンプトをどう調整しても救えません。
パターン3:ID、権限、データ境界が「TBD」のまま
企業データは単一のコーパスではありません。それぞれ固有のACLを持ち、それぞれ異なる規程に支配される千ものコーパスの集合です。経理部長がHRの回答を得るべきではなく、業務委託先が役員会議事録を見るべきでもありません。個人情報保護法(APPI)、経済産業省「AI事業者ガイドライン」、そして輸出先によってはEU AI法への対応も、すべてここに関わってきます。
症状: 平坦化されたテストデータでは美しく動く。法務が本番設計を見てプロジェクトを止める。
対処: 行レベルアクセス制御を、アプリケーション層ではなく検索層に押し込むことです。取り込み時にすべてのチャンクに元データのACLでタグ付けし、LLMがデータを見る前に、ユーザーのIDを使ってクエリ時点でフィルタします。これは言うほど簡単ではありませんが、避けて通れません。
パターン4:可観測性なし、監査証跡なし
先週火曜日の14:30に「返金ポリシーは何ですか」という質問にシステムが何と答えたかを言えないのなら、それは本番システムではありません。負債です。
症状: ユーザーがAIから誤った情報を受け取ったと苦情を入れる。チームは再現も、調査も、その事例からの学習もできない。
対処: すべての検索、すべてのプロンプト、すべての出力、すべてのコストを、サービスをまたいで一貫したトレースIDとともに記録します。SOCチームがセキュリティイベントを扱うのと同じ流儀で — 改ざん不可、検索可能、コンプライアンス要件が定める期間だけ保存します。私たちは soc-integrator でSIEMへのingestionに使っているのと同じ可観測性パターンをここでも使います: 構造化ログ、OpenSearchインデックス、階層化された保存ポリシー。
パターン5:コストモデルが希望的観測
1日50クエリのパイロットならコストは無視できる水準です。しかし、4,000人の従業員が1人あたり平均30クエリを、リッチなコンテキスト検索付きで投げ始めた瞬間、月次LLM料金はそれを構築したチームの給与を超えます。
症状: ロールアウト開始から2ヶ月で財務が予算を引き上げる。
対処: 初日からトークン単価ではなく「有用なアクション当たりコスト」でモデリングします。積極的にキャッシュします。簡単な質問は小型・低価格モデルへ、フロンティアモデルは本当に難しい質問のために温存します。検索コンテキストを圧縮します — ほとんどのパイロットは、800トークンで答えられる質問に8,000トークンのコンテキストを送り込んでいます。測ってから最適化する。コストエンジニアリングは立派なエンジニアリングです。
パターン6:単一LLMプロバイダ前提で構築した
Q1のbake-offで勝ったモデルが、Q4に最安・最速で、かつ地域で利用可能とは限りません。プロバイダロックインは、複数年にわたるAI投資の静かな殺し屋です。
症状: 価格改定や地域提供の問題で、緊急の再プラットフォーム化を強いられる。
対処: 最初からモデル境界を抽象化します。安定したインターフェース、モデルルーティングルール、フォールバックチェーンを持つ薄い内部ゲートウェイ。決済プロバイダを1社決め打ちでチェックアウトに埋め込まないのと同じく、ナレッジ製品にLLMを1つ決め打ちで埋め込んではいけません。初期コストは小さく、オプション価値は大きい投資です。
パターン7:ローンチ後の運用責任者が決まっていない
パイロットはイノベーション部門の所有物です。本番システムには、オンコールローテーション、ランブック、そしてモデルドリフト、評価セット更新、四半期ごとの検索インデックス再構築のための予算を持つ責任者が必要です。
症状: ローンチから半年、ソース文書が更新されているのに誰も再インデックスしなかったため、精度が静かに劣化していく。
対処: 出荷前に、これを誰が運用するかを決めます。AIシステムには他の本番サービスと同じ運用規律 — SLO、変更管理、インシデント対応 — に加え、いくつかの新しい規律(評価セットの再実行、ドリフト監視、プロンプトのバージョン管理)が必要です。社内にこの能力がなければ、構築するか、外部に委ねるか。ないまま出荷してはいけません。
パターンの背後にあるパターン
このリストに載っていない項目に注目してください: モデル選定、ファインチューニング、ベクトルDBのブランド、エージェントフレームワークの選択。これらはチームが議論したがる問いです — 楽しいからです。しかし、投資が回収できるかを決めるのは、上記7つの問いです。地味で、運用的で、アーキテクチャ的な問いです。
これは、SOCプラットフォームを構築するなかで学んだ教訓(SIEMは安いパーツ — 検知エンジニアリングとチューニングがシステムそのもの)、ERP統合で学んだ教訓(コネクタは安いパーツ — データ契約と突合がシステムそのもの)とまったく同じです。新しい技術、同じ物理法則です。
もし私たちの問題だったら
パイロットから本番への現実的な90日プラン:
| 週数 | フォーカス |
|---|---|
| 1–2週 | アーキテクチャレビュー。ギャップの文書化。評価セット構築。 |
| 3–6週 | 検索の修正。ACL対応のindexing。初日からの可観測性とコストテレメトリ。 |
| 7–10週 | ハードニング: ID統合、フォールバックチェーン、ランブック、負荷試験。 |
| 11–12週 | 実ユーザー、実SLA、運用責任者を伴ったパイロット運用。 |
派手ではありません。しかし、効きます。
Simplicoが入れる場所
私たちは過去10年、タイ、日本、中国、そしてアジア太平洋地域全体のクライアントに本番システムを届けてきました — 重要インフラ向けSOCプラットフォーム、製造業向けERP統合、ECバックボーン、そして近年は同じ基準で構築されたRAGおよびエージェントシステム。
行き詰まったパイロットがある — あるいは、行き詰まるパイロットをそもそも作りたくない — であれば、喜んで拝見します。
弊社アーキテクトとの90分のコール。現状をマップし、プロダクションギャップを率直にお伝えし、1ページのロールアウトプランを残します。スライドウェアはありません。
Simplicoはバンコクに拠点を置くエンジニアリングスタジオで、AI/RAG、サイバーセキュリティ、ERP統合、EC、モバイル開発を専門としています。日本、タイ、中国、英語圏のエンタープライズチームと協働しています。
最新の記事
- Simplico エンジニアリングライブラリ:2026 年版 本番ソフトウェア・AI・セキュリティ実践フィールドガイド May 5, 2026
- Tier-1 SOC アナリスト Agent を本番環境で動かす:Wazuh + Claude + Shuffle 実装の現場知見 なぜ「AI for SOC」のほとんどは機能しないのか — そして何が実際に機能するのか May 2, 2026
- SCS評価制度がもたらす中小企業セキュリティ需要——日本のMSPが今、バックエンドを刷新すべき理由 April 28, 2026
- 2026年版 ローカルLLMのためのハードウェア選定ガイド:実用的なサイジング April 28, 2026
- オープンソースだけで本番運用できるSOCを構築した話 — Wazuh + DFIR-IRIS + 自社統合レイヤー April 25, 2026
- FarmScript:農業IoTのためにDSLをゼロから設計した話 April 22, 2026
