AI PoCの進め方｜5ステップ・費用の内訳・失敗の回避策

# AI PoCの進め方｜5ステップ・費用の内訳・失敗の回避策

AI PoCの進め方を5ステップで整理し、費用の内訳と失敗の回避策までまとめます。本題は、精度が出ても本番に行けない理由です。

AIのPoCは、多くの場合うまくいきます。精度は目標に届き、デモは動き、報告会の空気もよくなります。

にもかかわらず、そこから本番運用まで進む割合は高くありません。止まるのは精度が足りなかったからではなく、精度以外を確かめていなかったからです。

この記事では、AI PoCの進め方を工程として整理したうえで、PoCで確かめられることを3つに分けます。3つ目が本題です。

① AI PoCの進め方

AI PoCの基本をすでにご存じの方は、③ PoCで確かめられることは、3つに分かれるから読み進められます。

PoC（Proof of Concept／概念実証）は、本格的な開発に入る前に、小さく作って成立するかを確かめる工程です。AI開発で特に重視されるのは、やってみないと精度が分からないという性質があるためです。従来のシステム開発なら仕様どおりに作れば仕様どおりに動きますが、AIは学習データと実データの差で結果が変わります。

5つのステップ

#	ステップ	ここで決めること
1	目的・スコープ・評価指標の明確化	何ができたら成功か。数値で定義する
2	データのアセスメントと準備	使えるデータがあるか。量・質・権限を確認する
3	モデルの選定とプロトタイプ開発	既存モデルで足りるか、学習が要るか
4	検証と評価	指標に届いたか。届かない場合の原因はどこか
5	本格開発への移行判断	進む／やめる／条件付きで進む

最も飛ばされるのはステップ1です。「まずやってみましょう」で始めると、終わったときに成功だったか判断できません。評価指標を先に決めていないPoCは、報告会で「感触は良かった」という言葉に着地します。

どの業務を選ぶか——困りごとの言語化と、選ぶ3つの条件

ステップ1の前に、そもそもどの業務をPoCにするかで結果の大半が決まります。出発点は技術ではなく、現場の困りごとです。「この作業に時間がかかって人手が足りない」「点検の結果にムラがある」「データはあるのに使えていない」のように、現場の言葉で書き出します。この段階で「AIで何かできないか」から始めると、課題のほうが技術に合わせて歪みます。

書き出した困りごとから、PoCの対象に選ぶ条件は3つです。1つ目は、入力と出力が決まっていること。何を入れたら何が返れば正解か、を文章で書けない業務は評価指標も書けません。2つ目は、過去のデータが手元にあり、使う権限があること。データの収集から始めるPoCは、期間が読めなくなります。3つ目は、精度が出たあとに業務の流れを変える権限を、PoCの発注側が持っていること。精度が出ても業務を変えられない部署が持つPoCは、第1層で終わります。

競合の記事が同じ問いに「課題の言語化」や「競合動向の確認」を挙げるのに対し、この記事は3つ目の条件を加えています。本番に行けないPoCの多くは、課題の選び方の時点で「変える権限が無い業務」を選んでいます。

PoCに向く業務・向かない業務——用途の型で見る

AIの活用例は業種別に数十の分類で紹介されることが多いですが、PoCの進め方を考えるときは業種より「用途の型」で見たほうが判断に使えます。型によって、第1層で止まりやすいか、第2層・第3層で止まりやすいかが変わるためです。

用途の型	例	第1層（精度）	第2層（業務に乗るか）	第3層（運用が続くか）
文書の要約・下書き	議事録、問い合わせの回答案	出やすい	書式の揺れと機密の扱いで止まりやすい	利用者の使い方が変わると品質の基準も動く
分類・振り分け	問い合わせの仕分け、与信の一次判定	出やすい	例外の行き先を決めていないと止まる	分類の定義が業務の変更で古くなる
検知	外観検査、異常検知	データの偏りで出にくい	見逃しと誤検知の許容量を現場と決めないと止まる	設備や季節で入力の傾向が変わる
予測・最適化	需要予測、配送ルート	出ることもあるが評価が難しい	予測を誰がどう使うかが決まっていないと使われない	環境が変わると過去データが効かなくなる
対話・検索	社内情報の検索、FAQ応答	出やすい	正答が無い問いの扱いで止まる	情報源の更新が止まると回答が古くなる

要約や分類は第1層を通りやすく、PoCの成功体験になりやすい型です。その反面、第3層で品質の基準が動きやすい。検知や予測は第1層から難しいぶん、PoCの段階で現場と評価の基準を詰めざるを得ず、結果として本番に近い確認ができることもあります。自社の候補がどの型かを先に置くと、PoCで何を確かめるべきかが絞れます。

評価指標の立て方——精度の数字と、業務の数字を分ける

ステップ1の評価指標は、1種類では足りません。精度の数字（正解率、再現率など）は第1層の指標で、モデルが使えるかを判定します。これだけで成功を決めると、精度が出ても本番に行けないPoCになります。

業務の数字を別に置きます。処理1件あたりの時間、人が確認に戻す割合（差し戻し率）、例外として人に回る割合、現場担当者が「使い続けたい」と答えるかどうか。これらは第2層の指標で、実データを流さないと測れません。競合の記事に多い「作業時間を30%短縮」「ミスを半分に」といった目標は業務の数字ですが、PoCの期間内に測れる形に分解しておく必要があります。「月10時間の業務を自動化」なら、PoCでは「対象業務100件のうち、人の確認なしで完了した件数」のように置き換えます。

第3層の指標は、PoCでは測れません。その代わり、本番で何を監視するか（精度の推移、例外率の変化、入力データの傾向の変化）を、PoCの報告書に「本番で見る数字」として先に書きます。これがステップ5の移行判断の材料になります。

PoCの体制——4つの役割と、兼ねてよい役割

PoCの体制は、技術担当だけでは成立しません。揃える役割は4つです。業務の課題と投資判断を持つ業務責任者、モデルの設計と評価を行う技術担当、データの所在と権限を把握しているデータ担当、既存システムとの接続を見るIT担当。小さなPoCでは、データ担当とIT担当は1人が兼ねられます。

兼ねてはいけないのは、業務責任者と技術担当です。技術担当が業務の成功基準を決めると、測れる数字（精度）が成功基準になります。業務責任者が技術の判定を兼ねると、デモの印象で判定が決まります。PoCの責任者は業務側に置き、技術側は「何ができて何ができないか」を報告する立て方にすると、ステップ5の判断が業務の言葉で下されます。

実施計画に書くこと——体制・日程・予算・環境・終わり方

実施計画は、体制と日程と予算を並べるだけでは足りません。この記事が加えるのは「終わり方」です。計画に書く項目は次のとおりです。

1. 目的と、確かめる層（第1層だけか、第2層まで踏み込むか）

2. 評価指標と、合格の線（精度の数字と業務の数字の両方）

3. 使うデータの所在、件数、利用の権限、個人情報の有無

4. 体制（4つの役割と担当者名）

5. 日程（データ準備・構築・評価・報告の区切り）

6. 予算と、超えたときに誰が判断するか

7. 実施環境（自社環境か外部環境か、本番データを持ち出せるか）

8. 終わり方（進む・やめる・条件付きで進む、のそれぞれで次に何をするか）

8番目が無い計画は、報告会で「次をどうするか」の議論から始まります。合格の線を越えたら何をするか、越えなかったら何をするか、を先に書いておくと、PoCの結果がそのまま次の工程の起点になります。

機械学習・深層学習・生成AIの言葉は、最小限で足りる

PoCの進め方を調べると、機械学習や深層学習の解説から始まる記事が多くあります。この記事では用語の説明を最小限にとどめます。発注側が知っておくべき区別は2つで足ります。1つは、過去のデータから規則を学ばせる「機械学習」（深層学習はその一種で、データ量が多いときに向く）か、既に学習済みの大きなモデルを使う「生成AI」か。もう1つは、自社のデータで学習させるのか、学習済みのモデルに自社の文書を参照させるだけなのか。前者はデータの量と質がPoCの期間を決め、後者は参照させる文書の整備がPoCの期間を決めます。それ以上の技術の区別は、技術担当の仕事です。

期間と費用の目安

期間は、対象業務の範囲とデータの整備状況で決まります。データが整理済みで対象が絞られていれば数週間、データの収集や名寄せから始めるなら数ヶ月に伸びます。

費用も同じ要因で動きます。各社が公表している金額は前提の書き方がばらついており、ひとつの相場としてまとめると比較に使えません。見積もりを取るときは、金額より先に「データの整備をどちらが持つか」を確認したほうが実態に合います。

見積もりの内訳——金額の前に、何に工数がかかるかを見る

相場で比較できないなら、見積もりの内訳で比較します。PoCの見積もりに並ぶ項目は、おおむね次の5つです。要件の整理（何を確かめるかを決める打ち合わせ）、データの整備（収集・名寄せ・ラベル付け）、モデルの構築（既存モデルの選定か、学習か）、評価（指標で測り、原因を分析する）、報告（結果と次の判断材料をまとめる）。

複数の見積もりを並べたとき、金額が大きく違う理由はほぼデータの整備にあります。ある会社は「整備済みのデータを受け取る前提」で、別の会社は「生データから整備する前提」で出している、ということが珍しくありません。内訳にデータの整備が無い見積もりは、その工数を発注側が持つ前提になっています。費用の相場を調べる時間を、内訳の前提をそろえる時間に回したほうが、比較の精度は上がります。

投資対効果の出し方——PoCの段階で出せる数字と、出せない数字

投資対効果（ROI。かけた費用に対して、どれだけの効果が返るか）は、PoCの段階では半分しか出せません。出せるのは費用の側と、第1層・第2層の効果の見込みです。精度が出て、実データで差し戻し率が分かれば、「対象業務の何割を人の手から外せるか」が見積もれ、人件費に換算できます。

出せないのは、第3層の費用です。本番の監視、精度が落ちたときの再学習、例外が増えたときの人の対応。これらはPoCの期間内に発生しないため、見積もりに現れません。PoCの報告で投資対効果を示すときは、「本番の運用費を含まない数字」と明記し、運用費は本番の体制を決めてから足します。PoCの投資対効果だけで本開発の予算を決めると、第3層の費用が後から出てきて計画が崩れます。

外注先の選び方——納品型と伴走型、RFPに書くこと

外注する場合、PoCの支援会社は大きく2つの型に分かれます。決めた範囲を作って納める「納品型」と、発注側の中に入って一緒に進める「伴走型」です。納品型は範囲と金額が明確で、第1層の確認には向きます。伴走型は、業務の切り出しや評価指標の設計から関わるため、第2層まで踏み込むPoCに向きます。失敗したときの扱いも違い、納品型は追加費用になりやすく、伴走型は途中で方向を変えやすい。どちらが良いかではなく、確かめる層で選びます。

RFP（提案依頼書。発注側が候補の会社に渡す、依頼内容をまとめた文書）に書くことは、背景と課題、対象業務、使えるデータの状況、評価指標と合格の線、期間と予算の上限、そして「PoCのあと、本番は誰が作るか」です。最後の項目が無いRFPには、PoCの成功だけを目的にした提案が集まります。本番まで見据えた提案を集めるには、PoCの先の工程をRFPに書きます。候補は複数から絞り、提案書で「本番移行で何が要るか」に触れている会社を残します。

よくある失敗

評価指標を決めずに始める — 終わっても判断できない
データが揃う前にモデルの議論を始める — 手戻りが最も大きい
デモ用の入力だけで検証する — 例外が入っていない
PoCの成功をそのまま本番の成功と読む — 本記事の主題

失敗の回避策——社内の連携と、外注への頼りすぎ

上の4つに加えて、競合の記事が共通して挙げる失敗が2つあります。1つは社内の連携が取れていないこと。技術部門だけでPoCを進め、業務部門が結果を初めて見るのが報告会、という形です。回避策は体制の節で述べたとおり、業務責任者をPoCの責任者に置くことです。もう1つは外注に頼りすぎること。支援会社に丸ごと任せると、PoCで分かったこと（どのデータが使えなかったか、どの例外が多かったか）が社内に残りません。回避策は、評価の工程に自社の担当者を必ず入れ、報告書を自社の言葉で書き直すことです。

どの失敗も、技術の失敗ではありません。進め方の失敗で、PoCを始める前に防げます。

② PoC・実証実験・MVPは、確かめるものが違う

似た言葉が並ぶため、まず切り分けます。

	確かめる対象	出口
PoC	技術的に成立するか	動く／動かないの判定
実証実験	現場の環境で成立するか	業務に置いたときの挙動
MVP（必要最小限の製品）	顧客が使うか、対価を払うか	市場の反応
本開発	継続して運用できるか	事業として回る状態

PoCとMVPは別物です。PoCは技術の問いに答え、MVPは市場の問いに答えます。PoCで精度が出たことは、使われることを保証しません。この2つを1つの工程で兼ねようとすると、どちらも中途半端になります。

プロトタイプ（試作品）との違い

PoCとプロトタイプも混同されます。プロトタイプは「形にして触れるもの」で、見た目や操作を確かめるための試作品です。PoCは「成立するかの証明」で、形は問いません。表計算のマクロでも、ノートブック上のコードでも、精度が確かめられればPoCとして成立します。逆に、精巧な画面があっても精度を確かめていなければPoCにはなりません。AI開発でプロトタイプが必要になるのは、第2層（業務に乗るか）を確かめる段階で、現場の担当者に触ってもらうときです。

PoCの目的は3つある——技術の確認・社内の合意・投資判断の材料

PoCの目的は技術の確認だけではありません。実務では3つの目的が重なります。1つ目は技術の確認（第1層）。2つ目は社内の合意で、動くものを見せることで業務部門や経営層の理解が進みます。3つ目は投資判断の材料で、本開発に進むかどうかを数字で判断するための根拠です。

目的を分けておく理由は、評価の仕方が変わるからです。社内の合意が目的なら、見せる相手に伝わるデモが要ります。投資判断の材料が目的なら、デモより評価指標の数字と、本番で要るものの一覧が要ります。「とりあえずやってみる」で始めたPoCは、3つの目的のどれにも届かないまま終わります。

③ PoCで確かめられることは、3つに分かれる

ここが本題の入口です。PoCという同じ名前の工程で、実際には性質の違う3つのことを確かめられます。

層	問い	確かめ方	多くのPoCで
第1層：技術が動くか	目標精度に届くか	手元のデータでモデルを回す	確かめている
第2層：業務に乗るか	現場の入力と例外に耐えるか	実データ・実業務で流す	一部だけ
第3層：運用が続くか	数ヶ月後も同じ品質か	—	確かめていない

第1層は、道具立てが揃っている

精度の検証には確立された方法があります。評価指標を決め、テストデータで測り、目標との差を見る。ここは工程として成熟しています。

第2層は、実データを流せば見える

現場の入力には、デモに出てこないものが混ざります。過去の経緯がついた問い合わせ、書式の揺れ、想定外の値。実データを流せば見えるので、確かめようと思えば確かめられます。

第2層を確かめるときは、現場の担当者を評価に入れます。技術担当が精度を測るだけでは、「正解だが現場では使えない出力」（長すぎる、言い回しが業務に合わない、確認に時間がかかる）が見えません。実データを流した結果を担当者に見せ、そのまま使えるか、直せば使えるか、使えないかの3つに分けてもらいます。この分類が、本番で例外をどこに逃がすかの設計の材料になります。

第3層は、PoCの期間内には見えない

運用が続くかどうかは、時間が経たないと分かりません。データの傾向が変わる、業務フローが変わる、担当者が変わる。数週間から数ヶ月のPoCでは、原理的に観測できない層です。

第3層が実際にどう顔を出すかは、PoC止まりの正体｜99.9%の精度で本番が止まった実録に、本番に載せたあとに残った0.1%の記録として書いています。

④ この記事では、第3層を扱う

第1層と第2層は、やり方が公開されています。第3層だけは「本番運用に進む前にセキュリティと可用性とガバナンスを設計しましょう」という一般論で終わっていることがほとんどで、実際に本番へ出した後に何が起きるのかの実数が出てきません。

以降は、PoCから本番までの距離を、開発の記録から出します。

⑤ PoCは有効。ただし、確かめているのは3分の1

先に立場をはっきりさせると、PoCは有効な工程です。いきなり本開発に入って数千万円を投じた後に「そもそも精度が出ない」と分かる事態は、PoCで確実に防げます。投資判断の材料としても、既存データの棚卸しとしても機能します。やらない理由はありません。

ただ、PoCが答えているのは第1層の問いです。「動くか」に答えたことを、「使い続けられるか」に答えたと読むと、本番移行で止まります。

止まるのは技術の問題ではなく、確かめる範囲の問題です。

⑥ PoCから本番までの距離

発信元（ARCHECO）が2026年2月から7月に開発した、ホテル向けゲストサービス基盤の記録から実数を出します。iOS/Androidアプリ、管理Webアプリ、バックエンド、決済、物流連携、AI機能を含む構成です。

指標	実測値
コミット総数	2,126（2026-02-16〜07-21）
機能追加（feat）	808
修正（fix）	728
DBスキーマの変更	188本
サーバレス関数	45本
テストファイル	64

読むべきはfeatとfixの比です。機能を808件足すあいだに、728件直しています。PoCで「動いた」機能を本番に持っていく過程で、ほぼ同量の修正が発生している。

データベース構造の変更が188本というのも同じ話です。データベースの構造は「何を扱うか」の定義そのもので、これを5ヶ月で188回変えている。PoCの段階で決めた定義が、そのまま本番まで残った例のほうが少なかった、ということです。

数字は再現できます。git rev-list --count HEAD と ls supabase/migrations/*.sql | wc -l で出ます。

⑦ 初受注の翌日に、決済が止まった

時系列で見ると、第3層がどこで顔を出すかが分かります。

2026-06中旬〜下旬 — App Store・Google Play 両ストアの審査を通過、一般公開
2026-07-05 — 一般ユーザーからの商用注文を初受注
2026-07-06 — 本番の決済障害を検知し、同日中に修正を適用

審査を通り、公開し、初めてお金を受け取った翌日に決済が止まりました。5ヶ月かけて作り、テストも書き、ストア審査という第三者のチェックも通った後の話です。

障害の内容は3Dセキュアに起因するもので、検知から同日中に本番へ修正を適用して収束しています。重要なのは、これがPoCでも、テストでも、審査でも出なかったことです。実際のユーザーが実際のカードで決済したときに初めて現れました。

第3層——運用が続くか——は、この地点から始まります。PoCの成功と本番の安定のあいだには、これだけの距離があります。

⑧ 本番移行で要るもの

PoCから本番へ進むときに、PoCでは省略されていて本番では必須になるものを整理します。

セキュリティ設計

PoCは限られた人が触ります。本番は権限の異なる利用者が触ります。行レベルでのアクセス制御、役割ごとの権限体系（管理者／スタッフ／利用者）が必要になります。PoCの段階では全員が全部見えていても成立するため、ここは丸ごと後回しになりがちです。

可用性の担保

PoCは止まっても誰も困りません。本番は止まると業務が止まります。監視、障害の検知、復旧の手順。初受注の翌日に障害が出るという前提で体制を組む必要があります。

ガバナンス体制

誰がモデルの更新を判断するか、AIの出力に問題があったとき誰が止めるか。PoCでは開発者が兼ねている役割を、本番では組織に配置し直します。

AIが自信を持てないときの逃がし先

PoCでは「精度80%」で成功と判定できますが、本番では残り20%の行き先を決めないと運用が回りません。人に渡すのか、保留にするのか。これは技術ではなく業務の決定で、決めるのは発注側です。

生成AI特有の注意

出力が毎回同じにならないため、テストの考え方が変わります。「正解と一致するか」ではなく「許容範囲に収まるか」で判定する必要があり、PoCの評価設計をそのまま持ち込めません。PoC→MVP→本番の3段階で、確かめる対象を切り替えていくのが現実的です。

誰が運用するか——内製・外注・段階的な移行

第3層は運用の話なので、誰が運用するかを決めないと設計できません。内製は、業務の変化に合わせてモデルや例外の扱いを直せる反面、人を確保し育てる時間がかかります。外注は、立ち上げが速い反面、PoCで分かったことが社内に残りにくく、変更のたびに費用が発生します。現実的なのは段階的な移行で、PoCと最初の本番は外部と組み、評価と例外の扱いを自社の担当者が持ち、運用が安定してから監視と再学習を内製に寄せます。移行の順番を決めずに「いずれ内製化」とだけ書いた計画は、外注が続きます。