AIのPoCで合意を取る手順｜小さく試して見せて決める
「AIで本当に使えるの？」「いや、やってみないと分かりません」—— この押し問答、会議のたびに繰り返していませんか。上は「早く成果を」と急ぎ、現場は「試さないと約束できない」と踏ん張る。言葉だけでは、期待と現実の距離がなかなか縮まりません。
そんなとき効くのが、小さなPoC（お試し）を作って、実物で見せてから決めるやり方です。全部作り込む必要はありません。確かめたい一点だけを、小さく試して、結果を並べて見せる。それだけで「使える/使えない」の話が、感情論から事実の話に変わります。この記事では、そのPoCで合意を取るまでの手順を、明日から一歩ずつ進められる形で一緒に整理します。
結論：AI導入の合意は、議論で勝ち取るより小さなPoCで見せて取るほうが早くて角が立ちません。順番は、①確かめたい問いを1つに絞る → ②合格ライン（使える/使えないの基準）を先に決める → ③実データに近い小さな例で試す → ④結果を見える形にする → ⑤「進む/やめる/条件つき」を一緒に決める。作り込みではなく「判断材料を最短で出す」のがPoCの役割です。最後のチェックリストを、次の打ち合わせに持っていってください。
「やってみないと分からない」は逃げではありません。むしろ、分からないことを一番小さく確かめる段取りを組める人が、その場で一番頼りになる人です。
「使えるか使えないか」を、言葉で決めようとするとこじれる
AIが「使えるかどうか」は、やってみるまで誰にも分かりません。 にもかかわらず言葉だけで決めようとすると、期待の大きい人が「できるはず」と押し、慎重な人が「難しいと思う」と引く、という綱引きになりがちです。どちらも実物を見ていないので、話は平行線のまま、現場のあなたに「で、どうなの？」の視線だけが集まります。
ここで、いきなり本番相当のものを作り込むのも危険です。 まだ使えると決まっていないものに何週間もかけると、うまくいかなかったときに「あれだけ時間をかけて」という空気になり、次の一歩が踏み出しづらくなります。
やることは、「使える/使えない」を最短で見分けるための、いちばん小さい実験を組むことです。 PoCは完成品ではなく、判断材料です。きれいさや網羅性より、「知りたいことが分かるか」を優先します。次の5つの順で進めます。
手順1：確かめたい問いを、1つに絞る
最初にやるのは、コードでもツール選びでもなく、「このPoCで何を確かめたいのか」を一文にすることです。
- このAIで解けるか不安な、一番の山場はどこか（精度？ 速度？ 費用？ 運用の手間？）
- 「なんとなく全部」ではなく、失敗したらプロジェクトが止まる急所はどれか
- その問いは、小さな例でも確かめられる形になっているか
問いが2つ3つ混ざると、PoCはふくらみ、結果もぼやけます。 たとえば「社内文書の要約に使えるか」なら、まず「要約の精度が実務で許せる範囲に入るか」の一点に絞る。速度や費用は、精度が合格してから次のPoCで確かめれば十分です。
聞き方の例：「今回のお試しでは、まず『精度が実用に足りるか』だけを見る、という理解で合ってますか？」 この一文が決まると、作る範囲も、見せる結果も、自然と定まります。
手順2：合格ライン（使える/使えないの基準）を、先に決める
PoCで一番もめるのは、実は作った後です。 結果を見てから「これは使える」「いや不十分だ」と、人によって合格ラインが違うことが露呈するからです。だから基準は、試す前にそろえておきます。
- 「どうなったら使える」と言えるのか、具体的な線を先に言葉にする
- できれば数や例で決める（例：「10件試して、手直しなしで使えるのが7件以上なら合格」）
- 100点ではなく「実務で許せる最低ライン」を置く（AIは一発満点の道具ではありません）
合格ラインを先に握るのは、後出しの評価を防ぐためです。 「事前にこの線で合意しましたよね」と言える状態にしておくと、結果の解釈で消耗せずにすみます。相手が基準を決めたがらないときは、こちらから仮の線を置いて「これでよければ進めます」と一言添える。丸投げ気味の相手でも、線が見えていれば後から揉めにくくなります。
手順3：実データに近い、小さな例で試す
基準が決まったら、いよいよ試します。ここでのコツは「小さく、でも本物に近く」です。
- 件数は少なくていい（5〜10件でも傾向は見えます）
- ただし、実際の業務で出てくる例に近いものを使う（きれいすぎるサンプルは当てにならない）
- うまくいく例だけでなく、手強そうな例・変な入力もわざと混ぜる
きれいなお手本だけで試すと「できた！」となりがちですが、本番は例外だらけです。 だからこそ、現場で実際に困りそうな例を数件まぜておくと、「どこで崩れるか」まで見えて、判断の精度が上がります。
このとき、機密情報や個人情報を外部のAIに入れてよいかは必ず先に確認します。 PoCだからと油断して社内データをそのまま流すのは避け、ダミーに置き換えるか、入力してよい区分かを確かめてから進めてください。→ 詳しくは社内データをAIに渡すときの線引きもあわせてどうぞ。
手順4：結果を「見せる」形にする
PoCの価値は、結果の伝わり方で決まります。 口頭で「だいたいいけました」と言うより、そのまま見てもらえる形にするほうが、合意はずっと早く進みます。
- 入力と出力を並べて、そのまま見られる一覧にする（表やスプレッドシートで十分）
- 手順2で決めた合格ラインに照らして、「合格◯件／不合格◯件」を素直に出す
- うまくいった例と、崩れた例の両方を見せる（良い所だけ見せると、後で信頼を失います）
大事なのは、盛らないことです。 できたことも、できなかったことも、同じ温度で並べる。「7件は使えて、3件は手直しが必要でした」と正直に見せるほうが、相手は現実的な判断ができますし、あなた自身も後で「話が違う」と言われずにすみます。誠実な結果は、次の一歩の土台になります。
手順5：「進む/やめる/条件つき」を、一緒に決める
結果を見せたら、その場で次の判断まで持っていきます。PoCは、やりっぱなしにすると「で、結局どうするの？」が宙に浮きます。選択肢はだいたい3つです。
- 進む：合格ラインを満たした。次は速度・費用・運用を確かめる次のPoCへ、または小さく本番導入へ
- やめる：現時点では実務に足りない。撤退も立派な成果（早く分かったぶん、損失が小さい）
- 条件つきで進む：AI単独では足りないが、人の確認を挟めば使える（この形が現場では一番多い）
「やめる」も失敗ではありません。 使えないと早く分かったこと自体が、PoCの立派な成果です。数週間かけて本番を作ってから気づくより、はるかに安く済んでいます。
そして現実にいちばん多いのが「条件つき」です。 AIにたたき台を作らせ、最後は人が確認して仕上げる——この人の確認を挟む形（ヒューマン・イン・ザ・ループ）なら、多くの業務で無理なく使えます。→ 組み方は人の確認を挟むAIワークフローの設計にまとめています。
明日やること・チェックリスト
一度に全部そろえなくて大丈夫です。まずは「確かめたい問いを1つ書く」ところからで十分です。
- このPoCで確かめたい問いを、1つに絞って一文で書いた
- 「どうなったら使える」の合格ラインを、試す前に（できれば数で）決めた
- 合格ラインを、上司・依頼者と（仮置きでもよいので）握った
- 実業務に近い例を5〜10件用意した（手強い例・変な入力もまぜた）
- 機密・個人情報を外部AIに入れてよいか確認した（ダメならダミーに置換）
- 入力と出力を並べて、そのまま見られる形にした
- うまくいった例と崩れた例の両方を、盛らずに見せた
- 合格ラインに照らして「合格◯件／不合格◯件」を出した
- 「進む/やめる/条件つき」の次の判断を、相手と一緒に決めた
- 「条件つき」なら、人が確認する箇所を具体的に決めた
最後に
「使えるかどうか、やってみないと分からない」——それは、あなたが答えを出せないからではありません。 分からないことを、一番小さく確かめる段取りを組めるというのは、現場でとても頼りになる力です。言葉で期待を押し返すより、小さな実物を見せるほうが、角が立たずに現実へ着地します。
今日はまず、確かめたい問いを一文にするところから。 そこから、小さく試して、見せて、一緒に決める。この順番があれば、「AIで使えるの？」の押し問答から、少しずつ抜け出していけます。一歩ずつで大丈夫です。
よければ、こちらも
- 「AIで何とかしろ」と言われたら｜まず確認する6つ——PoCを始める前に、目的や期待値をそろえたいときに。
- AI APIの料金・レート制限を見積もる——「進む」となった後、費用面を確かめたいときに。
- AI生成コードのレビュー・検証チェックリスト——実際にコードを書かせて使う段になったら。