「まず小さく試してみましょう」で始まった AI の検証が、半年後には誰も触らなくなっている。受託開発の現場では珍しくない光景です。PoC（Proof of Concept／概念実証。本格開発の前に、技術的に実現可能かを小規模に確かめる工程）が本番運用に至らないという指摘は各所でされていますが、「何割が失敗する」といった数値は調査主体や定義によって大きく異なるため、ここでは数字の話はしません。代わりに、受託側から見たときに本番に乗った案件と止まった案件で何が違ったのかを、止まった側も同じ重さで書きます。結論を先に言えば、分かれ目はモデルの精度ではなく、着手前に決めたことの中身です。
止まる理由は「精度が足りなかった」ではないことが多い
止まった案件の報告書に「精度が実用水準に届かなかった」と書かれることはあります。ただ、受注側から経緯を追い直すと、その手前に別の原因があることが多いというのが実感です。
- 何点なら合格かを誰も決めていない — 精度 80% が良いのか悪いのかは、人間が今どれだけ間違えているかと比べないと判断できません。比較対象がないまま数字だけ出ると、評価は「なんとなく不安」に収束します。
- PoC の予算しか確保していない — 本番化には、運用監視・権限管理・ログ保全・利用者教育といった、PoC に含まれない費用が必ず発生します。ここが予算化されていないと、結果が良くても次の稟議が立ちません。
- 使う人が検証に入っていない — 情報システム部門だけで回した PoC は、現場が「そもそも今のやり方で困っていない」と言った瞬間に止まります。
つまり、技術ではなく意思決定の設計の問題であることが大半です。
本番に乗った案件に共通する、着手前の 3 つの決めごと
進んだ案件を振り返ると、キックオフの時点で次の 3 点が文書になっていました。
| 決めごと | 具体的に何を書くか | これがないとどうなるか |
|---|---|---|
| 合格ライン | 対象業務／評価データの件数／許容できる誤り率／誤った場合の影響度 | 結果が出ても「もう少し様子を見よう」で終わる |
| 業務の置き換え範囲 | AI が担う工程、人が確認する工程、例外時の差し戻し先 | 全自動を期待されて落胆される |
| 本番化の判断者と予算枠 | 誰が GO を出すか、概算でいくらまでなら出せるか | 評価が良くても次フェーズの発注が立ち上がらない |
特に 3 点目は受託側から切り出しにくい話ですが、ここを曖昧にしたまま始めた案件は、成果物の出来にかかわらず止まりやすい、というのが率直なところです。
止まった案件側の条件も、同じだけ具体的に
成功要因だけを並べると実態を誤らせるので、止まる側の典型も書きます。以下は仮の例として読んでください。たとえば次のような場面です。
- 社内の問い合わせ対応を AI で、という依頼。ところが参照させるべき社内規程が複数世代混在し、どれが現行かを判断できる人が社内に一人しかいない。PoC 中はその一人が都度教えてくれるため動くが、本番では回らない。
- 見積書の自動作成。過去データを渡してもらったが、価格の決め方が担当者の裁量で、ルール化されていない。AI は「過去の平均」を出すことしかできず、現場からは「それなら使わない」と言われる。
- 経営層の号令で始まったが、現場の評価指標（KPI）には AI 活用が一切入っていない。現場は協力するほど自分の数字が下がるため、静かに距離を置く。
いずれも共通するのは、AI の問題ではなく、業務が言語化されていないことが露出したという構造です。PoC は多くの場合、業務整理の診断装置として機能します。止まったこと自体は失敗ではなく、「今 AI を入れても定着しない」と分かったこと自体に価値があります。ただし、それを成果として扱える発注契約になっているかは別問題で、ここは契約時に握っておくべき点です。
技術選定で実際に詰まる箇所
技術面では、生成 AI を使う案件の場合、次の順で検討するのが現実的です。
- まずプロンプト設計だけで足りるか — 汎用モデルに指示文を工夫して渡すだけで要件を満たせるなら、保守コストが最も低く済みます。
- 次に RAG — RAG（Retrieval-Augmented Generation／検索拡張生成）は、社内文書を検索して見つけた内容をモデルに渡し、それを根拠に回答させる方式です。社内固有の知識を扱うなら第一候補になります。詰まるのはモデル側ではなく、文書の前処理です。PDF の表組み、スキャン画像、更新されていない旧版ファイル。ここに工数の大半が吸われます。
- 最後にファインチューニング — モデル自体を自社データで追加学習させる方法です。出力形式を固定したい場合などに効きますが、学習データの整備と再学習の運用が必要で、中小規模の案件では割に合わないことが多いというのが現状の感触です。
もう一つ詰まるのが評価です。従来システムのテストと違い、生成 AI は同じ入力でも出力が揺れます。合否判定用のテストケースを人手で作り、変更のたびに回す仕組み（いわゆる評価セット）を最初に用意しておかないと、改善したのか悪化したのかが誰にも分からなくなります。これは後から足そうとすると非常に高くつきます。
法令・ガイドラインとして最低限押さえる点
中小企業でも確認しておきたい枠組みを挙げます。詳細は原文の確認が必要で、ここでは所在を示すにとどめます。
| 名称（公表年） | 関係する場面 |
|---|---|
| AI 事業者ガイドライン（総務省・経済産業省、2024 年） | AI を開発・提供・利用する立場ごとの留意事項。社内方針を作る際の下敷きになる |
| 個人情報保護法（2020 年改正、2022 年全面施行） | 顧客情報や従業員情報を外部 AI サービスに送る際の取り扱い、委託先管理 |
| 著作権法 第 30 条の 4（2018 年改正で新設） | 学習目的での著作物利用の扱い。生成物の利用可否とは論点が別である点に注意 |
実務上は、外部 API を使う場合に入力データが提供元の学習に使われない設定になっているかを契約・設定の両面で確認することが出発点になります。
まとめ
PoC が本番に乗るかどうかは、モデルの選定や精度よりも、着手前に「合格ラインを決めたか」「人と AI の分担を決めたか」「本番化の判断者と予算枠を決めたか」で大きく変わります。逆に、業務がルール化されていない、現場の評価指標に組み込まれていない、参照する文書が整理されていない、という条件が重なっている場合は、PoC は止まる可能性が高いと考えたほうが現実的です。
その場合でも、止まった理由を「業務のどこが言語化されていないか」という形で残せれば、次の投資判断の材料になります。受託側としては、動くものを作ることと同じくらい、止めるべきときに止める判断材料を出すことが仕事だと考えています。まずは一つの業務に絞り、合格ラインを文章にするところから始めてみてください。