AIの導入を検討すると、早い段階で「まずPoCから」と言われる。PoCは概念実証のことで、AIで目的の業務が実現できるかを小さく試す工程だ。ところが、何を試せば終わりなのか、どのくらいの期間と費用をかけるのか、結果を見て次に進むかをどう決めるのか、が決まらないまま始まることが多い。
以下、AIのPoCとは何を確かめる工程かを、経済産業省の契約ガイドラインの段階の分け方をもとに整理し、期間と費用の考え方、次に進むかの決め方を、発注する側の目線で書く。PoCが終わったあとに止まってしまう原因と抜け出し方はAIのPoC止まりを抜け出すに、PoCの前に決める項目はAI開発の要件定義に分けてある。
AIのPoCとは何を確かめる工程か
PoCはProof of Conceptの略だ。AIの場合は、限られたデータと期間で、モデルが目的の業務に使える水準で動くかを確かめる。
AIの開発をどう段階に分けるかは、経済産業省が2018年6月に公表した「AI・データの利用に関する契約ガイドライン」が参考になる。ガイドラインは、学習済みモデルの内容や性能が契約の時点で特定できない場合が多いことを理由に、開発を段階に分けて、段階ごとに次に進むかを確かめながら進める「探索的段階型」を提唱した。段階はアセスメント段階、PoC段階、開発段階、追加学習段階の4つだ。
ガイドラインの解説によると、段階ごとの中身は次のように想定されている。
| 段階 | 結ぶ契約 | やること | 成果 |
|---|---|---|---|
| アセスメント | 秘密保持契約書 | 限定的なサンプルデータで、短期間でAI技術の導入可否を検証する | 検証結果を書いた簡易なレポート |
| PoC | 導入検証契約書（準委任型） | 一定のサンプルデータで学習済みモデルを作り、精度を上げる作業をして、開発の可否や妥当性を検証する | 検証結果をまとめたレポート |
| 開発 | ソフトウェア開発契約書（準委任型） | PoCを経て開発の可能性があると判断したモデルを、提供されたデータで作って渡す | 学習済みモデル |
ここで押さえておきたいのは、PoCの成果がレポートだという点だ。PoCの段階では、動くシステムを納めることは想定されていない。モデル契約には、ベンダは成果物の完成義務や性能の保証を行わない案も示されている。
このガイドラインは機械学習を念頭に置いて書かれており、今の生成AIのように、学習済みのモデルをAPIで呼んで使う形とは前提が違う。それでも私の見方では、「段階を分け、段階の終わりに次に進むかを決める」という骨組みは、生成AIのPoCにもそのまま使える。生成AIでは、モデルを作る代わりに、指示文や参照する社内文書、ほかのシステムとのつなぎ方を試すことになる。
PoCで確かめることを3つに絞る
PoCで何を確かめるかが広いと、終わりが来ない。私の見方では、確かめることは次の3つに絞るとよい。
| 確かめること | 問い | 例 |
|---|---|---|
| できるか | AIがその業務の入力を、使える水準で処理できるか | 問い合わせのメール100件に、担当者が直さずに送れる下書きが何件できるか |
| つなげるか | 業務で使うデータとシステムに、AIをつなげるか | 社内の文書の保管場所から、権限を守ったまま必要な文書を取り出せるか |
| 使うか | 現場の人が実際の仕事の中で使うか | 担当者が、2週間のうち何日AIの下書きを開いたか |
1つ目だけを確かめるPoCが多い。精度の数字は出るが、2つ目と3つ目が残るので、次の段階でつまずく。3つ目は数字にしにくいが、現場の担当者を1人か2人、PoCの最初から入れておくだけで、使われるかどうかの見当はつく。
確かめる業務も1つに絞る。複数の業務を同時に試すと、どの業務で何が分かったかが混ざる。最初の1つは、件数が多く、結果の良し悪しを担当者がすぐ判断できる業務がよい。
期間の決め方：先に終わりの日を決める
AIのPoCの期間に決まった相場はない。私の見方では、生成AIを使うPoCは4〜8週間で区切り、途中に確認日を2回置くのがよい。
期間を先に決める理由は、PoCには終わる理由がないからだ。精度は手を入れるほど少しずつ上がる。あと少しで上がりそうに見えるので、作業が続き、次に進むかの判断が先送りになる。終わりの日を先に決めておけば、その日までに分かったことで判断することになる。
| 時期 | やること | 決めること |
|---|---|---|
| 始める前 | 試す業務、使うデータ、合格の基準を決める | 誰が最後に判断するか |
| 1回目の確認日 | 実際の業務のデータで最初の結果を見る | 範囲を狭めるか、このまま進めるか |
| 2回目の確認日 | 現場の担当者に使ってもらった結果を見る | 残りの期間で何を試すか |
| 終わりの日 | 基準に照らして結果を報告する | 次の段階に進むか、やめるか |
1回目の確認日で、実際の業務のデータが手に入らない、権限の手続きが進まない、と分かることも多い。その場合は期間を延ばすより、範囲を狭めて試せるところだけを確かめる方が、判断の材料が早くそろう。
費用の考え方：人の時間とAPIの利用料に分ける
AIのPoCの費用は、外に払う人の費用、APIなどの利用料、社内の人の時間、の3つに分けて見積もる。
1つ目の外に払う人の費用が、多くの場合いちばん大きい。先のガイドラインのモデル契約は、PoC段階も開発段階も準委任型にしている。準委任は仕事の完成ではなく作業そのものに払う形なので、費用はおおむね、関わる人数と期間と単価を掛けたものになる。見積もりを比べるときは、合計の金額より、誰が何週間、どの作業をするかを確かめる方が比べやすい。
2つ目の利用料は、件数が少ないPoCの段階では小さいことが多い。たとえばAnthropicの価格表では、Claude Sonnet 5.5のAPIは100万トークンあたり入力2ドル、出力10ドルだ（2026年10月時点）。PoCで試す件数が数百件なら、利用料は人の費用に比べてずっと小さい。ただし本番で件数が増えたときの利用料は、PoCの結果から計算しておく。1件あたりの入力と出力のトークン数はPoCで測れるので、そこに本番の件数を掛ければよい。計算の仕方はAI導入の費用の内訳に書いた。
3つ目の社内の人の時間は見積書に載らないので、抜けやすい。データを集めて渡す、結果が正しいかを判断する、現場で試しに使う、のどれも社員の時間を使う。私の見方では、現場の担当者が週に数時間を使えるかどうかを、PoCを始める前に上長と決めておくべきだ。ここが決まっていないと、PoCは外の人だけで進み、3つ目の「使うか」が確かめられない。
次に進むかを決める基準
PoCの結果を見てから基準を考えると、どんな結果でも「もう少し試せば使えそうだ」という結論になりやすい。基準は始める前に書いておく。私の見方では、次の4つを見る。
| 基準 | 確かめる問い |
|---|---|
| 業務の数字 | 目標を業務の数字で書いたか。その数字に届いたか（例：担当者が直さずに送れる下書きの割合） |
| データ | 本番と同じ種類のデータで試したか。きれいに整えたサンプルだけで試していないか |
| 間違えたとき | AIが間違えたときに誰が気づき、どう直すかが決まっているか |
| 運用する人 | 本番で使い続けるときに、面倒を見る人と予算の見込みがあるか |
4つがそろえば、開発の段階に進む材料はそろっている。そろわなくても、PoCが失敗したわけではない。届かなかった理由が分かれば、範囲を変えてやり直すか、やめるかを決められる。やめると決めて終えたPoCは、次の検討で同じことを試さずに済むので、それ自体が成果になる。
本番に進む判断をしたあとに何が起きやすいかはAIのPoC止まりを抜け出すにまとめた。PoCで測った効果と費用を経営の判断の材料にする方法はAI投資のROIの出し方に書いた。
PoCを外に頼むときに確かめること
PoCを外の会社に頼むときは、次のことを最初の打ち合わせで聞いておくと、結果の使い道がはっきりする。
| 確かめること | 質問の例 |
|---|---|
| 成果の形 | PoCの最後に何を受け取れるか。レポートか、試作のコードか、両方か |
| 担当する人 | PoCを担当する人は、次の段階にも入るか |
| データの扱い | 渡したデータを、PoCのあとにどう扱うか。消すのか、残すのか |
| 判断の材料 | 次に進むかを決めるために、どの数字を出してくれるか |
2つ目は見落とされやすい。PoCと開発で担当者が替わると、PoCで分かったことの一部が次に伝わらない。データの扱いは、経済産業省の「AIの利用・開発に関する契約チェックリスト」も、利用者が契約のときに確かめる点として挙げている。
FDE（Forward Deployed Engineer）は、PoCから本番の運用までを同じ人が現場に入って担う職種だ。どんな仕事かはFDEとはに書いた。私たちの支援の中身と料金はサービスページにまとめてある。