PoCの期間と費用の考え方

「PoCはどのくらいの期間と費用でできますか」というご質問をよくいただきます。金額の目安をお答えする前に、順序を逆にすることをおすすめしています。期間と費用は、検証の中身から積み上げるのではなく、意思決定の都合から逆算するほうが、うまくいくからです。

期間は意思決定の周期から逆算する

PoCの結果は、誰かがそれを見て次を決めるために存在します。だとすれば、その「決める場」がいつあるかが、期間を決める最初の制約になります。

• 経営会議が月に一度なら、PoCは1か月以内に結論が出る形にします
• 四半期ごとの予算編成に乗せたいなら、その締め切りの2週間前には結論が要ります
• 決める場が特に決まっていないなら、まず日付を決めるところから始めます

多くの現場でPoCが長引くのは、この逆算をしていないからです。検証の中身から積み上げると、「あれも確かめたい、これも確かめたい」で3か月、半年と伸びます。そして伸びた先には、決める場がありません。

先に「この日のこの会議で結論を報告する」と決め、その日から逆算して検証の範囲を削る。これが期間設定の正しい順序です。範囲の削り方はPoCの範囲を最小にする切り方で扱ったとおりで、絞れば数週間で足ります。

長いPoCが失敗する4つの理由

期間が長くなると、検証の質が上がるどころか、成功しにくくなります。構造的な理由が4つあります。

1. 前提が変わる

半年あれば、業務の手順も、対象の事業も、担当者の顔ぶれも変わります。開始時に立てた問いが、終わるころには誰も気にしていない問いになっていることがあります。

2. 使うAIサービス自体が変わる

既製のAI APIは頻繁に更新されます。期間が長いと、検証の途中で新しいモデルが出て、「では新しいほうで試し直しますか」という議論が発生します。悪気なく検証は延び、結論は出ません。短く区切って、そのときの既製品で判断するほうが健全です。

3. 費用が本番化の判断を歪める

PoCに大きな費用をかけると、「ここまで使ったのだから本番化しないと」という力学が働きます。これは判断として有害です。PoCの費用は、やめる判断が普通にできる規模に抑えるべきものです。

4. 決める場を失う

長引いた案件は、報告のタイミングを何度も逃します。逃すたびに関心は薄れ、最後は誰も結論を求めなくなります。

想定例：ある企業が、社内の問い合わせ対応をAIで支援できないか検討したとします。当初は3か月の予定で、対象業務を広く取り、画面も作り、既存システムとの連携も試す計画でした。2か月目に主要な担当者が異動し、3か月目に対象業務の外部委託が決まりました。検証自体は技術的に進んでいましたが、報告する相手も、導入する先もなくなっていました。もし最初に「翌月の定例会議で報告する」と決めていれば、対象を一工程に絞った3週間の検証になり、異動の前に結論が出ていたはずです。

費用は3つに分けて見る

PoCの費用を「開発会社への支払い」だけで見ると、実態を見誤ります。次の3つに分けてください。

3つ目が抜けているPoCの見積もりは、実際の負担を映していません。評価は業務を分かっている方が行う必要があるので、その方の時間は確実に消費されます。PoCを始める前に、「誰が、週に何時間、これに使えるか」を確認しておいてください。ここが確保できないPoCは、期間だけ延びます。

API利用料は本番規模で見る

PoCそのもののAPI利用料は、数十件の処理であれば多くの場合わずかです。重要なのは、そこから1件あたりの単価を割り出し、本番の想定件数に掛け算することです。

• 月間の処理件数を想定し、単価を掛けて月額を出します
• 入力が長いケースでの単価も測り、上振れの幅を見ます
• 処理を1回で終えるのか、確認や再実行が入るのかで回数が変わります
• 想定より利用が増えたときの上限をどう設けるかも、この段階で考えます

この試算が、PoCの合格ラインを先に決めるで触れた「費用の上限」と突き合わせる材料になります。技術的に合格しても単価が合わなければ本番化しない、という判断を根拠を持って下せます。

費用の目安を持ちたい場合の考え方

具体的な金額は、検証する処理の複雑さ、用意するデータの状態、評価にかける工数によって案件ごとに大きく異なります。相場として一律の数字を挙げることはできません。

代わりに、社内で基準を持つ方法があります。「本番化して得られる効果の、何分の一までなら検証に払えるか」を先に決めることです。

1. この仕組みが本番で動いたとき、年間でどのくらいの手間や費用が減るかを粗く見積もります
2. その何分の一かを、検証にかけてよい上限とします
3. その上限に収まる範囲で、検証できることを設計します

粗い見積もりで構いません。桁が合っていれば判断には足ります。この順で考えると、「検証にいくらかかりますか」ではなく「この金額で何が確かめられますか」という問い方に変わり、範囲の交渉ができるようになります。開発費の見積もりの読み方そのものはMVP開発の費用相場の考え方が参考になります。

延長するかどうかも先に決めておく

期間を区切っても、終盤で「もう少しあれば」となることはあります。ここで無条件に延ばすと、最初に期間を区切った意味が失われます。延長の条件を先に決めておいてください。

• 延長は1回まで、期間は当初の半分まで
• 延長するのは、合格ラインに届きそうな見込みが具体的な数値で示せる場合に限る
• 延長の判断は、担当者ではなく意思決定者が行う

この3点を最初の合意に含めておくと、終盤の議論が短くなります。

決める日から逆算し、3つの費目で見る

PoCの期間は、検証の中身からではなく、結果を見て決める場の日付から逆算します。長いPoCは、前提が変わり、使うAIサービスが変わり、費用が判断を歪め、決める場を失います。費用は開発費・API利用料・自社の人件費の3つに分け、API利用料は本番規模に掛け算して見る。効果の何分の一までなら払えるかを先に決めれば、範囲の交渉ができます。

検証の中身を詰める前に期間と費用の枠を置きたい場合は、お問い合わせからご相談ください。オンラインで状況を伺い、その枠に収まる検証の形を一緒に考えます。ご相談・お見積りは無料です。