この記事の要点
- 生成AIのPoCとは、本番開発の前に小さく試作して「自社業務で使えるか」を確かめる検証工程のことです。
- 従来の機械学習PoCが「学習データを集めて精度が出るか」の検証だったのに対し、生成AIでは「業務品質として許容できる出力か」「運用コストが見合うか」が検証の主戦場に移っています。
- 検証すべき生成AI特有の項目は、出力精度・ハルシネーション・推論コストの3軸。この3つをPoC開始前に数値目標にしておくことがGo/No-Go判断の前提になります。
- 外注時の費用目安は、小規模な単機能検証で50〜150万円、RAGを含む標準的なPoCで200〜500万円、既存システム連携を伴うもので500万円以上。期間は1〜3か月が一般的です。
- PoCが本番に進まない原因は「成功基準を数値で決めていない」「評価者が現場にいない」「本番規模の推論コストを試算していない」の3つにほぼ集約されます。
生成AIを少し触ってみて、手応えはあった。けれど本番導入の稟議に出せる材料がない。この段階で止まっている会社は、かなり多いはずです。原因はツールの性能ではなく、たいてい検証の設計にあります。この記事では、生成AI PoCで何を検証し、どう進め、いくらかかり、どこで撤退を判断するのかを順に整理します。読み終えたときに、社内稟議の骨子と外注先への相談内容が書ける状態になることをゴールにしています。
目次
生成AIのPoCとは？従来AIのPoCと何が違うのか
生成AIのPoC（Proof of Concept＝概念実証）とは、本番開発に進む前に小規模な試作で「生成AIが自社業務で使えるか」を確かめる工程です。従来の機械学習PoCが「学習データを集めて精度が出るか」を確かめる作業だったのに対し、生成AIでは高性能な基盤モデルがすでに存在します。そのため検証の焦点は「そもそも動くか」から「業務品質として許容できるか」「運用コストが見合うか」へ移りました。
この違いは、発注する側の見積もりの読み方にも直結します。データ収集とモデル学習に費やしていた工数が減る一方で、評価設計と業務適合性の検証に工数が寄る。ここを理解しないまま「PoCだから安いはず」と考えると、提示された見積もりの妥当性を判断できません。
生成AIのPoCで確かめる3つのこと（技術的実現性・業務適合性・費用対効果）
PoCの目的は、技術的実現性・業務適合性・費用対効果の3点を小さく確かめることです。それぞれ「そもそも狙った出力が出せるか」「現場の業務フローに載せられるか」「削減時間×人件費が推論コスト＋運用工数を上回るか」という問いに翻訳できます。
注意したいのは、3つを同時に完璧に検証しようとすると期間が延びる点です。技術的実現性はプロンプト検証で数日〜2週間あればおおよそ見えます。むしろ時間がかかるのは業務適合性の確認で、現場が実務の中で使ってみないと分かりません。PoCの重心をどこに置くかを最初に決めておくと、期間も費用も読めるようになります。
ちなみに、日本企業のDX・AI活用の取り組み状況はIPA「DX白書」で継続的に調査されており、検討段階と実運用段階の間に大きな隔たりがあることが繰り返し指摘されています※1。PoCで止まるのは自社だけの問題ではありません。
従来AI（機械学習）のPoCとの4つの違い
違いは、学習データ準備の重み・精度の測り方・コスト構造・スピードの4点です。従来は「データがなければ始まらない」PoCでしたが、生成AIはプロンプト設計とRAG（社内文書を参照させる仕組み）で代替できる場面が多く、着手までのハードルが下がっています。
| 観点 | 従来AI（機械学習）のPoC | 生成AIのPoC | 発注側が受ける影響 |
|---|---|---|---|
| 学習データ | 教師データの収集・ラベリングが必須 | 大量の学習データは不要。参照文書と評価用データで足りることが多い | データ整備費が減り、代わりに文書整理の工数が出る |
| 精度の測り方 | 正解率・再現率など単一指標で機械的に測れる | 正解が一意でなく、人手による品質評価が必要 | 「評価工数」が見積もりに入っているかを確認する必要がある |
| コスト構造 | 学習にかかる初期コストが中心 | 使うたびに発生する推論コストが中心 | 初期費用より月額運用費の試算が重要になる |
| スピード | データ準備を含め数か月単位 | 数週間で試作を触れる状態にできる | 短期間で判断できる分、成功基準の事前合意が不可欠 |
特に効いてくるのが3行目です。従来AIは「作ってしまえば安く回る」構造でしたが、生成AIは使えば使うほど費用が積み上がります。全社展開したときに月額いくらになるのか、PoCの段階で必ず試算しておく必要があります。
PoC・PoV・プロトタイプ・本番開発はどう違う？
PoCは「技術的に可能か」、PoV（Proof of Value）は「ビジネス価値が出るか」、プロトタイプは「使い勝手が実務に耐えるか」、本番開発は「全社運用に耐える実装」を指します。段階が上がるほど、求められる品質と費用は跳ね上がります。
生成AIでは技術的可能性の検証が軽くなった結果、世の中で「PoC」と呼ばれているものの中身は、実質PoV寄りになっています。つまり「動くかどうか」ではなく「効果が出るかどうか」を見る作業。だからこそ、外注先に見積もりを依頼するときは「この見積もりはどこまでを含むのか」を言語化して確認してください。試作の実装までなのか、現場での試用と評価まで含むのか、本番移行計画の作成まで入るのか。この範囲の違いだけで金額は倍近く変わります。
※1 IPA「DX白書」リンク
生成AIのPoCで検証すべき項目は？出力精度・ハルシネーション・推論コストの3軸
生成AI特有の検証項目は、出力精度（業務品質として許容できるか）・ハルシネーション（誤情報の発生率と業務影響）・推論コスト（本番運用時の月額）の3軸です。この3つをPoC開始前に数値目標として置いておくことが、後のGo/No-Go判断の前提になります。逆に言えば、目標を決めずに始めたPoCは、終わっても誰も合否を宣言できません。
出力精度をどう測る？正解が1つでないタスクの評価設計
生成AIの精度は正解率では測れません。実務データから30〜100件程度の評価データセットを作り、「そのまま使える／少し直せば使える／使えない」の3段階で人手評価するのが現実的です。件数は多いほど信頼できますが、評価工数とのバランスで100件前後が上限になることが多いでしょう。
評価観点は、事実の正確さ・必要情報の網羅・文体や体裁・指示の遵守の4つに分けると採点がぶれにくくなります。合格ラインの置き方は、たとえば「そのまま使える率70%以上、使えない率5%以下」といった形。用途によって軸は変わります。要約なら情報の欠落、分類ならラベルの一致率、社内検索なら出典の正しさが主指標です。
ここで大事なのは、合格ラインを「現状の人手作業」と比べて置くことです。人がやっても2割は手直しが入る業務に対して、AIに100%を求めても意味がありません。比較対象は理想ではなく現状。
ハルシネーションは許容できるか？発生率と業務影響で線を引く
ハルシネーション（もっともらしい誤りの生成）はゼロにできない前提で設計します。判断は「発生率」と「発生したときの業務影響の大きさ」の2軸。社内向けの下書き生成なら許容度は高く、顧客への回答や契約・医療・金融のように誤りが直接損害につながる用途では、人のレビューを必ず挟む設計にします。
PoCで併せて試しておきたい緩和策は次のとおりです。
- RAGを使い、回答に必ず参照元の文書名とページを表示させる
- 参照文書に根拠がない場合は「分かりません」と答えさせる閾値を設ける
- 数値・固有名詞・日付を含む出力には人の確認を必須にする運用ルールを置く
- 出力ログを残し、誤りが起きたパターンを後から分類できるようにする
- 社外公開用途では、いきなり自動応答にせず内部の下書き支援から始める
AIの利用にあたってのリスク管理の考え方は、経済産業省・総務省「AI事業者ガイドライン」でも、用途のリスクに応じた対応と人間の関与の重要性として整理されています※2。社内の判断基準を作るときの下敷きに使えます。
推論コストは本番規模でいくらになる？トークン単価からの月額試算
PoCでは必ず「1回あたりのトークン消費量 × 想定利用回数 × 月間業務量」で本番運用時の月額推論コストを試算してください。PoCは利用量が少ないので数千円〜数万円に収まりますが、全社展開すると桁が変わります。ここを出さないまま稟議に上げると、費用対効果を示せずに止まります。
試算の考え方はシンプルです。RAGを使う場合、参照文書を入力に載せるため入力トークンが膨らみます。仮に1リクエストで入力3,000トークン・出力500トークン、月間1万件の処理なら、月3,500万トークン。ここに各社が公表しているモデル別の単価を掛けます。単価は改定されるため、必ず利用予定サービスの最新の公表価格で計算してください。
コストを左右する変数は主に3つ。モデルのグレード（高性能モデルと軽量モデルで数倍から十数倍変わる）、参照文書の載せ方（全文か、検索で絞った一部か）、リトライや多段処理の回数です。PoCでは高性能モデルで実現可能性を確認し、本番想定では軽量モデルに置き換えて品質が保てるかを試す二段構えが、費用と品質の落としどころを見つけやすくなります。
評価者は誰にすべき？PoCの成否を分ける評価体制の作り方
出力品質を判定できるのは、その業務を実際にやっている現場の熟練者です。情シスや経営層だけで評価すると「なかなか良い」「いまいち」という感想で終わり、合否を宣言できません。評価者を確保できていないPoCは、始める前から結論が出ない設計になっています。
実務的な体制は、現場の評価者2〜3名を確保し、同じ評価基準シートで独立に採点する形です。1人だけだとその人の好みが基準になり、再現性がなくなります。評価にかかる工数も先に見込んでおきます。1件5分×100件で約8時間。2名なら16時間分の現場工数を、PoC期間中の業務調整として確保しておく必要があります。
経営層の役割は、採点そのものではなく「評価基準の承認」と「Go/No-Go判断」です。合格ラインを決めた人と判断する人が同じであれば、結果が出た後に基準が動くことを防げます。評価者不在のPoCが失敗する因果は単純で、誰も合否を言えないから結論が出ず、報告書だけが残るのです。
※2 経済産業省・総務省「AI事業者ガイドライン」リンク
生成AI PoCの進め方は？5ステップと期間の目安
生成AI PoCは、①ユースケース選定と成功基準の合意（約2週間）②データ・評価セット準備（2〜3週間）③試作実装（3〜4週間）④評価（2週間）⑤Go/No-Go判断と本番計画（1週間）の5ステップで進めます。全体で1〜3か月が目安です。最重要はステップ1で、ここで成功基準を数値合意しないと、後の工程がすべて宙に浮きます。
STEP1：ユースケース選定と成功基準の合意（最重要）
最初にやるのは、「業務量が多い×判断が定型的×失敗コストが低い」業務を1つに絞ることです。候補を4つの軸（発生頻度／1件あたりの削減見込み時間／誤りが出たときのリスクの低さ／必要なデータの入手可否）で3点満点のスコアリングにかけると、社内の議論が感覚論になりません。
成功基準は数値で書きます。書き方の例を3つ挙げます。
- 評価データ100件のうち「そのまま使える」が70%以上
- 1件あたりの処理時間が平均15分から5分以内に短縮
- 本番想定（月1万件）での推論コストが月10万円以内
複数のユースケースを同時に検証するのは避けてください。評価者の工数が分散し、どちらも中途半端な結果になります。1つ通してGoの型を作れば、2つ目以降は速く回ります。
STEP2：データと評価用データセットの準備
生成AIのPoCに大量の学習データは不要ですが、参照させる社内文書（RAG用）と、評価用の実務データ30〜100件は必ず必要です。この2つは自社側でしか用意できません。外注先に丸投げできない部分だと理解しておいてください。
前処理工数は文書の形式で大きく変わります。テキストのWordやMarkdownなら軽い。表が複雑なExcel、レイアウトが凝ったPDF、スキャンした紙資料の順に手間が増えます。「文書はあります」と回答したのに、実態は紙とPDFの混在だった、という食い違いは見積もりのズレに直結します。
あわせて、機密情報の取り扱いルールを先に決めます。社外のAIサービスに入力してよいデータの範囲、個人情報を含む場合の扱い、利用するサービスが入力内容を学習に使わない設定になっているかの確認です。個人データを扱う場合は、個人情報保護委員会が公開している個人情報保護法の解説で、外部サービス利用時の取扱いの考え方を確認しておくと安全です※3。
STEP3：試作を作る（プロンプト／RAG／ファインチューニングの選択）
実装はコストの安い順に試します。まずプロンプト設計だけで試し、社内固有の情報が必要ならRAGを追加し、それでも文体や出力形式が安定しないときだけファインチューニング（追加学習）を検討する。この順番を崩さないことが費用を抑える最大のコツです。
| 手法 | できること | 期間の目安 | 費用感 |
|---|---|---|---|
| プロンプト設計 | 指示の与え方と出力形式の制御 | 数日〜2週間 | 低（ツール利用料程度） |
| RAG | 社内文書を参照させ、根拠付きで回答させる | 3〜6週間 | 中（検索基盤の構築工数が主） |
| ファインチューニング | 特有の文体・形式の安定化 | 1〜2か月以上 | 高（データ整備と再学習が発生） |
実務で出てくる課題の多くは、プロンプトとRAGの組み合わせで足ります。PoC段階からファインチューニングを提案する見積もりが来たら、「プロンプトとRAGで届かない理由」を説明してもらってください。納得のいく説明があれば妥当ですし、なければ範囲を絞れる可能性があります。
STEP4：評価する（定量指標＋現場の定性評価）
評価は、評価データセットによる定量スコアと、現場担当者が実務で1〜2週間使ってみる定性評価の両輪で行います。定量だけだと「スコアは良いのに現場で使われない」が起き、定性だけだと再現性がなく、次回の改善につながりません。
記録しておく項目は、合格率（3段階評価の分布）、AI出力を修正するのにかかった時間、1件あたりの入出力トークン数、そして失敗パターンの分類です。特に失敗の類型化が効きます。「参照文書に情報がなかった」のか「情報はあったのに拾えなかった」のか「指示の解釈を誤った」のかで、改善の打ち手がまったく変わるためです。前者は文書整備、二番目は検索設計、三番目はプロンプト修正で改善余地があります。
STEP5：Go/No-Go判断と本番移行計画の作り方
判断は3点で行います。成功基準を満たしたか、満たさなかった場合その原因は改善可能か、本番規模の運用コストが効果を下回らないか。2つ目を見ずに「未達だから中止」と決めると、あと一歩の案件を捨てることになります。
| 判断 | 条件 | 次のアクション |
|---|---|---|
| Go | 成功基準を満たし、本番コストが効果の範囲内 | 本番開発の要件定義と見積もり取得へ |
| 条件付きGo | 基準は未達だが、失敗パターンが特定でき改善余地がある | 対象業務や文書範囲を絞って再検証 |
| No-Go | 原因が構造的（文書が存在しない・業務が非定型すぎる） | 前提条件の整備、または別ユースケースへ切り替え |
Goになった場合、本番では追加要素が必要になります。権限管理（見せてよい人にだけ社内文書を見せる制御）、ログと監査、障害時の運用担当、モデル更新への追随です。これらはPoCの見積もりには通常含まれません。本番開発の費用はPoCとは別に見積もる、と最初から想定しておいてください。
※3 個人情報保護委員会「個人情報保護法」リンク
生成AI PoCの費用はいくら？相場・内訳・内製と外注の分け方
外注する場合の生成AI PoC費用は、小規模な単機能検証で50〜150万円、RAGを含む標準的なPoCで200〜500万円、既存システム連携や複数部門を含む大規模なもので500万円以上が目安です（案件条件で幅があります）。期間は1〜3か月。費用の大半は人件費であり、API利用料はPoC段階では数千円〜数万円に収まることが多い点を先に押さえておくと、見積もりの見え方が変わります。
規模別の費用相場と期間の目安（早見表）
規模ごとの目安を表にまとめます。金額はあくまでレンジで、対象業務の複雑さ・文書量・連携先の数によって上下します。
| 規模 | 検証範囲 | 期間 | 費用レンジ | 向いているケース |
|---|---|---|---|---|
| 小規模 | プロンプト設計と少量データでの品質検証 | 2〜4週間 | 50〜150万円 | 文書作成・要約など、既存文書の整備が不要な用途 |
| 標準 | RAG構築＋評価データセットによる定量評価 | 1〜2か月 | 200〜500万円 | 社内文書検索、問い合わせ回答の下書き生成 |
| 大規模 | 基幹・業務システム連携、複数部門での試用 | 2〜3か月 | 500万円以上 | 既存システムのデータを参照する必要がある業務 |
システム開発の工数と費用の関係については、IPA「ソフトウェア開発分析データ集」で規模別の実績値が公開されています※4。見積もりの妥当性を人月換算で確認したいときの参照先になります。また、IT導入補助金などの制度が活用できる可能性もあります※5。ただし対象要件と補助率は年度ごとに変わるため、2026年時点の情報として捉え、必ず最新の公募要領で確認してください。
費用の内訳は？人件費・API利用料・環境構築費の3つ
内訳は、エンジニアやコンサルタントの人件費（全体の7〜8割）、生成AIのAPI利用料（PoC規模なら数千〜数万円）、環境構築とデータ前処理費の3つです。つまりPoCの費用は、ほぼ「誰が何日動くか」で決まります。金額の妥当性を見るなら、人月単価ではなく作業項目の粒度を見てください。
見積書で確認すべきポイントを挙げます。
- 評価工程（評価データセット作成・採点集計・分析）が工数に含まれているか
- 報告書と本番移行時のコスト試算が成果物に入っているか
- 社内文書の前処理（PDF整形・不要文書の除外）はどちらが担当するか
- プロンプトやRAG構成の設計資料を納品物として受け取れるか
- API利用料は実費精算か、見積もりに含む固定か
- PoC期間中の改善サイクルが何回想定されているか
- 現場ヒアリングと定性評価の同行が含まれるか
- 成功基準の合意プロセスに、どちらの誰が参加するのか
相場より極端に安い見積もりは、評価工程が抜けていることが少なくありません。試作を作って動かして終わり、では合否を判断できず、結局もう一度お金がかかります。安さの理由を必ず聞いてください。
内製と外注はどう切り分ける？判断基準と費用差
切り分けの原則はシンプルです。ユースケース選定・評価者の確保・成功基準の合意は必ず自社側。モデル選定・RAG実装・評価設計は外注が効率的です。前者は業務知識がないと決められず、後者は経験がないと時間だけが溶けます。
| 作業 | 推奨 | 理由 |
|---|---|---|
| ユースケース選定・成功基準の設定 | 自社 | 業務量と失敗コストを知っているのは現場だけ |
| 評価者のアサインと採点 | 自社 | 品質の合否は業務の熟練者しか判定できない |
| 参照文書の提供と機密ルール決定 | 自社 | 権限と社内規程に関わる判断 |
| モデル選定・RAG実装 | 外注 | 選択肢の比較検討に経験が要り、試行錯誤の時間が短縮できる |
| 評価設計・コスト試算 | 外注 | 評価軸の作り方と本番規模の見積もりに定石がある |
内製には見えにくいコストがあります。担当者の学習時間、他業務と兼務することで期間が2〜3倍に延びること、そして途中で担当者が異動すると何も残らないこと。現実的なのは、まず社内で市販ツールを触ってユースケースの可能性を確かめ、業務適合性の検証と評価設計から外注するハイブリッドです。この線引きなら、自社に判断軸が残りつつ、無駄な試行錯誤を減らせます。
見積もりの範囲が妥当か、一緒に確認します。hikeに相談する
※4 IPA「ソフトウェア開発分析データ集」リンク
※5 独立行政法人中小企業基盤整備機構「IT導入補助金」リンク
生成AI PoCの事例は？ユースケース別の検証内容とPoC倒れの原因
中小・中堅企業で成果につながりやすいPoCのユースケースは、社内文書検索（RAG）、問い合わせ対応の下書き生成、議事録や報告書の作成支援の3類型にほぼ集約されます。いずれも業務量が多く、判断が定型的で、失敗コストが低いという条件を満たすためです。ここでは類型ごとに「何を検証し、どの指標で合否を決めるか」を整理します。
社内文書検索・ナレッジ検索（RAG）のPoC
規程・マニュアル・過去案件資料を検索対象にし、「現場から集めた質問100件に対して、正しい出典付きで回答できた割合」を主指標に検証します。質問は実際に社内で聞かれているものを集めるのがポイント。想定質問を作文すると、都合の良い結果しか出ません。
この類型で判明しやすい論点は3つあります。参照文書が最新版でない（改訂前の規程が混在している）、PDFのレイアウトが複雑で文字の抽出精度が落ちる、閲覧権限のある文書だけを返す制御が必要になる。いずれも技術の問題というより文書管理の問題です。PoCの価値は、この「文書整備をしないと使えない」という事実が数字で可視化される点にもあります。
問い合わせ対応・カスタマーサポートのPoC
過去の問い合わせ履歴とFAQを参照させて回答案を下書きさせ、「オペレーターがそのまま送信できた率」と「1件あたりの対応時間」を指標にします。前者が品質、後者が効果。両方を取らないと費用対効果の計算ができません。
リスク管理の定石は、いきなり顧客に自動返信させないことです。まず内部の下書き支援から始め、品質が安定してから公開範囲を広げます。あわせて、参照情報に根拠がない質問には回答させず有人に転送する閾値を設ける。これを設計に入れておくと、ハルシネーションが顧客に届く経路を構造的に断てます。
議事録・報告書・提案資料などの文書作成PoC
作成時間の削減量が測りやすく、失敗コストも低いため、PoCの入口として最も扱いやすい領域です。指標は1本あたりの作成時間と修正回数。文書の種類ごとに測ると、どのフォーマットが向いているかが見えてきます。
注意点は、専門用語や社内固有名詞の誤変換と、フォーマット遵守のばらつきです。用語集を参照させる、出力テンプレートを固定する、といった対策の効果もPoCで一緒に確かめます。費用対効果は「削減時間 × 担当者の時間単価 × 月間作成本数」で計算します。1本30分削減、時間単価3,000円、月40本なら月6万円分。これに対して推論コストと運用工数が見合うかを判断する形です。
なぜPoC倒れになる？失敗する3つの型と回避策
PoCが本番に進まない原因は、成功基準を先に決めていない・評価者が現場にいない・本番規模のコストと運用体制を試算していない、の3型に集約されます。技術的に無理だったから止まる案件は、実は少数派です。
- 型1：成功基準がない／結果を見ても誰も合否を言えず、「もう少し検証しましょう」で終わります。回避策は、STEP1で数値の合格ラインを文書化し、経営層の承認印を取っておくこと。
- 型2：評価者が現場にいない／情シスだけで進めると「デモは良かった」で止まります。回避策は、現場の熟練者2〜3名を評価者として正式にアサインし、評価工数を業務時間として確保すること。
- 型3：本番コストを試算していない／効果は語れても月額運用費が示せず、稟議で止まります。回避策は、PoCの成果物に「本番想定の月額推論コストと運用工数の試算」を必ず含めること。
3つとも、発注前・着手前の設計で防げます。逆に言えば、着手してから気づいても取り返しがつきにくい。外注先を選ぶときは、この3点を最初の打ち合わせで話題にしてくるかどうかが、一つの見極めになります。
まとめ：生成AI PoCは「成功基準・評価者・推論コスト」を先に決めてから始める
生成AIのPoCは、従来AIのPoCとは検証の重心が違います。押さえるべき点を整理します。
- 検証の焦点は「精度が出るか」から「業務品質として許容できるか」「運用コストが合うか」へ移っている
- 生成AI特有の検証項目は、出力精度・ハルシネーション・推論コストの3軸
- 進め方は5ステップで1〜3か月。最重要はSTEP1の成功基準の数値合意
- 外注費用の目安は50〜150万円／200〜500万円／500万円以上の3レンジ。大半は人件費
- PoC倒れの原因は、成功基準なし・評価者不在・本番コスト未試算の3型
次にやることは3つです。対象業務を1つ選ぶ。成功基準を数値で書く。評価者を2名決める。この3つが埋まれば、外注先への相談内容はほぼ固まります。逆にここが空欄のまま見積もりを取ると、各社の提案がばらばらになり、比較すらできません。
評価設計や本番規模のコスト試算を自社だけで組み立てるのが難しい場合は、PoCの設計段階から外部に相談する選択肢もあります。実装を依頼する前に、検証範囲と判断基準の置き方だけを一緒に整理する、という関わり方でも十分に意味があります。
よくある質問
生成AI PoCの期間はどれくらいかかりますか？
1〜3か月が目安です。対象業務を1つに絞り、参照文書の整備が不要なプロンプト検証中心の内容なら、1か月程度で回せることもあります。RAG構築や既存システム連携が入ると2〜3か月。期間が延びる最大の要因は技術ではなく、社内文書の準備と評価者の工数確保です。
PoCをやらずに、いきなり本番導入してもよいですか？
用途によります。文書要約や翻訳のように定型的で失敗コストが低い業務は、市販の生成AIツールを試用期間で使ってみるだけで判断できることが多いでしょう。一方、社内データを参照させる、既存システムと連携する、顧客対応に使うといったケースでは、品質とコストの検証を挟むほうが結果的に早く済みます。
社内データを使うと、学習に使われてしまいませんか？
法人向けのAPIやビジネスプランでは、入力内容を学習に利用しない設定が一般的です。ただし提供形態やプランによって扱いは異なるため、利用規約と管理画面の設定を必ず確認してください。個人情報や機微な情報を含む場合は、外部サービスへの入力可否を社内ルールとして事前に決めておく必要があります。
PoCで使うモデルはどれを選べばよいですか？
PoCではまず高性能モデルで「そもそも実現できるか」を確認し、実現できたら軽量モデルに置き換えて品質が保てるかを試す二段構えが有効です。最初から安いモデルで試して結果が出ないと、モデルの限界なのか設計の問題なのか切り分けられません。本番のコストは、置き換え後の数値で試算します。
PoCの成果物として何を受け取るべきですか？
最低限、評価結果レポート（評価データセットと採点結果を含む）、プロンプトやRAG構成の設計資料、本番運用時のコスト試算、Go/No-Go判断の根拠の4点です。設計資料が納品されないと、別の会社に本番開発を依頼する際にゼロからやり直しになります。契約時に成果物を明記しておいてください。
No-Goになったら、PoCの費用は無駄になりますか？
無駄にはなりません。対象業務がAIに向かない理由、文書整備の課題、必要なコスト水準といった判断材料が残ります。次の投資判断がはるかに速くなるという意味で、No-GoもPoCの正当な成果です。ただしそれを言えるのは成果物が整理されている場合に限るため、契約時の成果物定義が重要になります。