「PoCはうまく終わったのですが、その先がないんですよ」。先月、ソウルのある製造業の役員会議の懇親会で聞いた言葉です。会議室のホワイトボードにはパイロット指標がグリーンで残っており、担当のチームリーダーは笑ってはいたものの、目は少し疲れていました。デモまで8週間、そしてその後5ヶ月経った今も誰もそのツールを使っていない、とのことでした。
本シリーズを始めた時に話した問題に、再び戻ってきた形です。前回取り上げた失敗の5大パターンが、なぜ繰り返されるのか。多くの場合、技術が不足しているからではなく、どの地点でどのような成果物を残すべきかについての合意がないからです。8編にわたって取り上げてきた話に、今こそ結びをつけます。概念・タイプから始まり、ROI・スタック・コスト・セキュリティ・失敗パターンまで見てきたなら、最後に残る問いは一つです。「では、月曜日から何をどう始めるのか」。
なぜ87%はプロダクションに到達できないのか
Gartnerは2024年の調査で、AIプロジェクトの87%がプロダクションに到達しないと報告しました。S&P Globalの2025年のデータによれば、プロトタイプからプロダクションまで平均8ヶ月かかり、最終的に到達する割合は48%程度です。87%という数字は恐ろしく聞こえますが、裏を返せばこう読めます。本当に難しい区間は、モデルを組み込む8週間ではなく、その後の5〜6ヶ月なのだと。
同時期にGartnerは、少し違う角度の数字も出しています。生成AIプロジェクトの30%がPoC以降に廃棄され、主な理由はガバナンスの不在と不明確なROIです。逆に、構造化されたパイロット手順を踏んだ組織は、12ヶ月以内にROIを報告する確率が2.5倍高いという観察もあります。結局、成否は「モデルをどれだけうまくチューニングしたか」ではなく「段階をどれだけうまく設計したか」で分かれるのです。
正直に言うと、最初にこの市場に入った時は、その逆だと考えていました。良いモデルと良いデータさえあれば、残りは自然に付いてくるものだと。実際には、その「自然に付いてくる」という部分がプロジェクト予算の半分を食います。
ステップ0 — 始める前に決めておく3つのこと
業界では最近、この区間を「Phase 0」と呼びます。PoCを始める前に3つのことを文書で固めておくチームが、pilot purgatoryを抜け出すという観察です。評価基準、デプロイパイプライン、ガバナンス承認ライン。逆に「まずは一番かっこいいデモから作り、ハードニングは後で」を選んだチームは、大半が5ヶ月目で止まります。
実務的には、半日のワークショップ1回で十分です。このツールが成功したと判断する定量指標は何か。プロダクションに乗せる時、どのパイプラインを通過する必要があるのか。個人情報・機密文書に触れる時、誰が最終承認するのか。この3つに答えがなければ、まだPoCを始める準備ができていないということです。第3回で取り上げたROI・KPI設計と第6回のセキュリティ・ガバナンスが、ここで合流します。
ステップ1 — 診断(2〜3週間)
診断は会議室から始まりますが、答えは常に現場にあります。私たちがクライアントと行う診断は、3つのトラックで並行して進めます。業務トラックでは、チーム別に1日の時間がどこにどれだけ溶けているか、繰り返し作業が何件あるかを観察します。データトラックでは、社内文書・チケット・マニュアルがどこにどのフォーマットで散在しているか、地図を描きます。システムトラックでは、アクセス権限体系と監査ログが現時点でどこまで整っているかを確認します。
この段階の成果物は、たった2つで十分です。1つは候補ユースケース3〜5個それぞれに、想定削減時間とリスクを添えた表。もう1つは、最初のパイロット対象1つについての成功定義を1段落。30件におよぶ文書成果物は、むしろ危険信号です。何が重要かを決めきれていない、という意味だからです。
ステップ2 — PoC(6〜8週間)
業界のコンセンサスとして、うまく組まれた社内向けツールは8〜12週間でプロダクション準備まで到達できます。このうち前半の6〜8週間がPoC区間です。第2回で比較したRAG・ファインチューニング・プロンプトのうち、どの組み合わせで進むかは、診断の段階ですでに決まっているべきです。この段階で新たにアーキテクチャをひっくり返すチームは、たいていプロダクションに到達できません。
PoCの終了条件はデモの成功ではなく、3つの答えです。一つ目、診断で定義したKPIを、実ユーザー20〜30名が2週間回した時にどれだけ動いたか。二つ目、その過程で出た誤答・ハルシネーション・権限イシューを、どうロギングし、分類したか。三つ目、次のステップに進むために必要な予算・人員・ガバナンス承認が確保できたか。この3つに答えがなければ、PoCを延長するよりも、いったん終了して再設計する方が賢明です。
ステップ3 — 本構築(2〜3ヶ月)
本構築で最もよく崩れるのは、驚くことにモデルではなく接点です。社内SSO、文書ストレージ、チケットシステム、監査ログサーバー、通知チャネル。この5ヶ所のうち1つでも抜け落ちると、デプロイ後3週間以内にユーザー離脱が始まります。Hellotが2026年に観察した国内事例でも、「PoCは成功したのに、なぜ誰も使わないのか」の答えは、大半がこの5つの接点のどれかにありました。
この区間の成果物は3つです。プロダクションパイプライン(モデルデプロイ・ロールバック・A/B)、運用ダッシュボード(応答品質・コスト・使用量・拒否率)、ユーザーオンボーディング資料(2ページ以内のガイドと30分のセッション)。3つ目を軽く見て失敗したチームを、いくつも見てきました。良いツールも、最初の30分でつまずけば二度と開かれません。
ステップ4 — 運用・追加開発(継続)
Presenc AIの2026年6月レポートによれば、大企業の85〜90%がすでに少なくとも1つのプロダクションLLMを回しています。1年前の65%から一気に跳ね上がりました。この数字が意味することは明確です。「導入するかどうか」の議論はすでに終わり、これから3年の競争は「運用をどれだけうまく回すか」で分かれます。
運用段階は大きく3つのリズムで回ります。週次のリズムでは、使用量・拒否率・品質スコアを見ます。月次のリズムでは、第5回で取り上げたコスト構造を実際の請求書と突き合わせ、プロンプト・検索インデックス・文書の鮮度を点検します。四半期のリズムでは、ユースケースを再評価し、新たに追加する部署・業務を決定します。このリズムをチーム内部に移植できないまま、パートナーだけに任せておくと、6ヶ月以内にツールは化石になります。
パートナーを選ぶ時に問うべき5つの質問
診断から運用まで全区間を共に歩むパートナーを選ぶ時、実務者が問うべき質問は5つです。この5つに具体的に答えられなければ、デモがどれほど素晴らしくても再考する必要があります。
- 運用6ヶ月目のSLAと対応手順を、契約書にどう明記するか
- モデルアップデート・プロンプト変更・文書鮮度管理の責任分担はどうなるのか
- 内部人員へ運用を移管するロードマップと、その成果文書は何か
- 失敗した時のロールバック・データ削除・監査ログ保存の手順はどうなるのか
- 次のユースケースへ拡張する時に再利用可能な資産(パイプライン・評価セット・ガバナンス文書)が残るのか
5つ目の質問が特に重要です。良いパートナーはプロジェクトが終わっても、組織の中に筋肉を残します。悪いパートナーは、自分がいなければ何も回らないように仕立ててしまいます。
結び — 8編の物語を1枚に
ここまでで8編でした。第1回で取り上げた自社データLLMの概念とタイプから始まり、方式・ROI・スタック・コスト・セキュリティ・失敗パターンを経て、本日の実行プランに到達しました。8編を追ってこられた方なら、今や一つのことが明確になっているはずです。自社LLMは「技術導入プロジェクト」ではなく、「組織の新しい筋肉を作る仕事」だという事実。
30%がPoCで廃棄され、87%がプロダクションに到達できない市場で、反対側の少数派に立つための条件は、華やかなモデルではなく、診断・PoC・本構築・運用の4段階を退屈なほど誠実に踏むことです。8週間でデモが終わったことに祝杯を挙げるのではなく、そのデモが6ヶ月後も毎日開かれているかを問うべきなのです。
私たち5years+は、日本・韓国の中堅・中小企業を対象に、診断から運用まで全区間を共に走ってきたチームです。自社に合った導入ロードマップが必要でしたら、無料相談はこちらから現状をお気軽にお聞かせください。シリーズはここで一区切りですが、実際の実行はここからが本番です。