会議室のプロジェクターに映るデモ画面を眺めながら、参加者が小さく頷いている。
あの、なんとも言えない独特の時間が少し苦手です。
画面の向こうでは、長年使い込んできたオンプレミスの基幹システムが動いていて、そのすぐ横に今回組み込んだAIチャットの画面が開いている。
過去の見積書や特価申請のPDFを吸い込ませてあるので、「この条件なら、どこまで値引きできたっけ」と打ち込むと、3秒くらいでそれらしい回答を返してくる。問い合わせへの返信文も、テンプレートを適当に繋ぎ合わせたドラフトを自動で作ってくれる。最初の検証としては、まあ、悪くないできばえです。
「思ったよりちゃんと動きますね」
「現場のウケも、そこまで悪くはなさそう」
「もう少し精度を詰めれば、いけるんじゃないですか」
そんな前向きな声がパラパラと出て、準備してきた推進チームの人たちもほっと胸をなでおろす。
システムはエラーを吐かずに動いたし、検証用に選んだ現場のキーマンにも一通り触ってもらえた。アプリとしての初期アウトプットも見えている。計画書にあった「機能検証」のチェックボックスは、ひとまず埋まりました。
ただ、そのチェックが埋まったことと、次の投資判断に進めることは別の話。
スライドをめくって次のアジェンダに進んだ途端、急に部屋の空気が重くなります。
本番環境へ移行するために本格的な追加予算を確保しにいくのか。対象部署を広げるのか。それとも、いったん検証の段階で止めるのか。具体的な投資や、誰が泥をかぶって責任を持つのかという話になった途端、みんな急に手元の資料を見つめ始めて、言葉を濁し始める。
「いったん、様子を見ましょうか」
「他の部署の意見も集めてから考えましょう」
「LLMの新しいモデルが出たら、また試してみましょう」
報告会自体は拍手で終わったのに、翌週の予定表には次のステップが何も入れられない。
こういう、プロジェクトが冷凍庫にしまわれていくような光景を、これまでに何度も見てきました。
どうしてそこで足が止まってしまうのかというと、実はAIの精度だけの問題じゃなかったりします。
確かに、ハルシネーション（嘘の回答）を連発するシステムを現場に渡すわけにはいきません。1件の入力欄からAIが間違った事実を拾い上げ、それを人間がつきっきりで二重チェックするくらいなら、最初から手動でやったほうが早い。そこは私たちも過去に現場から猛反発を喰らって、大失敗した苦い経験があるのでよく分かりますし、精度が大事なのは大前提です。
ただ、本当のネックは、検証を始める前に「何が確認できれば次に進むのか」を関係者間で揃えきれていないことにあります。
だから、実証期間が終わったときに残るのが、「思ったより良かった」とか「もう少し直したい」という各自のふわっとした感想だけになってしまう。つまり、次に進むための、組織としての判断材料がどこにも残っていないのです。
PoCの完了を、デモが動いたことや、検証期間が終わったことだけで判断してしまうと、次の意思決定に使える材料が残りません。
本来、検証の最後に残すべきなのは、動作確認の報告ではなく、成果の整理です。細かなチェックリストを埋めることではなく、次の判断に使える一枚の整理として、何が分かり、何が分からず、どの条件なら進めるのかを残すこと。
何ができたのか。何ができなかったのか。どの条件なら次に進めるのか。どの論点は追加検証が必要なのか。誰が確認し、組織として次の判断に回せる状態になっているのか。
ここまで整理されて初めて、PoCは「試したイベント」ではなく、次の判断のための材料になります。
たとえば、ベテランの頭の中にしか残っていない「値引きの暗黙ルール」を型化しようとする場面があります。過去の特価申請データを集めても、表記ゆれや空欄が多く、そのままAIに読ませても判断理由として使いにくいことがあります。
そして、「通常業務の合間に誰がこのゴミデータを仕分けるんだ」という押し付け合いが始まります。
さらに、いざ検証を始めようとすると、セキュリティやデータ持ち出しの制約にぶつかることも少なくありません。顧客名、競合名、取引金額などを含むデータをそのまま外部環境に渡せないため、マスキングやデータ加工が必要になる。その結果、AIが参照できる文脈が虫食い状態になり、期待していた精度が出ないこともあります。
ここで本当に確認したかったのは、AIが綺麗な見積もり案を出せたかどうかという点ではありません。このようなリアルな壁にぶつかったときに、営業が「これなら使えない」と手動の引き直しに戻ってしまうのか。それとも、マスキングの運用を含めて、上司が承認画面で値引き根拠を確認する時間を減らせるのか。
単にシステムが「触られたか」を示す利用率ではなく、現場の判断や行動がどう変わったか。その生々しい変化を追わなければ、データを集めた苦労も、セキュリティとの調整に費やした時間も、すべてが無駄になってしまいます。
このため、アシストAiテラス（以下、AIT）では、最初の30日間の位置づけを少し違うものとして捉えています。
そもそも、そんな短期間で全社の業務がガラッと効率化されたり、コストが大きく浮いたりすることは、まずありません。AIは表計算ソフトのマクロを組むのとはワケが違うというか、ボタンを押せば誰でも同じ結果が返ってくるような、単純な事務処理ソフトではないからです。
Day0からDay30までの目的は、「続けるのか」「データ、業務設計、権限設計を見直して再検証するのか」「ここで止めるのか」を、ファクトをもとに判断できる状態を作ることです。
AITでは、この分岐を単なる成功・失敗ではなく、GO、Conditional GO、No-GOの判断として扱います。進むための材料が揃ったのか。条件付きで再検証すべきなのか。あるいは、ここで止めること自体が正しい判断なのか。そこまで言える状態にすることが、最初の30日間の役割です。
つまり、成果を約束する期間ではなく、次の意思決定に必要な材料を揃える期間です。
ある検証では、少人数の現場メンバーに実際の業務の中で使ってもらったところ、初週は触られたものの、2週目以降の利用が大きく落ちることがありました。原因を追うと、AIモデルそのものではなく、読み込ませる過去資料の品質に問題がありました。古いスキャナで取り込まれたPDFの文字認識が不安定で、必要な情報にたどり着けなかったのです。
このとき問題になるのが、原因の切り分けと責任分界です。
モデルやAPIが正常に動いていても、社内データの品質が低ければ、現場では使えません。ベンダー側は「システムの挙動は正常です」と主張し、現場からは「これなら自分でファイル探したほうが早い」と文句が出る。板挟みになった推進チームが胃を痛めることになります。
逆に、データは揃っていても、業務上の判断基準が曖昧なままなら、AIはそれらしい文章を返すだけで、現場の判断は軽くなりません。
だから、Day0の時点で「モデルの問題なのか、データの問題なのか、業務運用の問題なのか」を切り分けられるようにしておく必要があります。
現場から不満が出たとしても、それは失敗ではありません。
「LLMの選定やプロンプトの調整ではなく、社内のデータのクレンジングからやり直さなければ、これ以上費用を払い続けてもドブに捨てることになる」という、次に進むための強烈な判断材料が30日以内に手に入ったからです。
ここで手に入れるべきは、バグのない完璧なシステムではなく、次の予算を確保すべき明確な理由、あるいは、今すぐアプローチを切り替えるべきだという納得感のある根拠。それが手元にある状態を作ることが、この30日間のゴールです。
このとき、細かいチェックリストを大量に並べることが目的ではないのです。
なぜなら、画面が表示された、回答が返ってきた、数名が触った。
そうした確認項目をいくら埋めても、投資判断にはつながらないからです。
Day0-30で残すべきなのは、細かな作業完了の証跡ではなく、その成果整理をもとに次の判断へ進める状態です。
何を確認できたのか。どこが詰まったのか。GOなのか、条件付きで進むのか、いったん止めるのか。そこまで整理されていることが、この期間の本当の成果です。
検証をスタートする前に、これだけは絶対に決めておかなければならないことがあります。
どのベンダーのツールを契約するかとか、最新のLLMモデルのどれを採用するかといった話は、後回しで構いません。
最初に決めるべきことは、主語と動詞を確定させること。
誰が、どの画面の前で、どの作業をどう変えるのか。ここが曖昧なままだと、アウトカムは「AIを使う」「ナレッジを活用する」といった大きな言葉のまま残ります。
しかし、それでは検証後に何を見ればよいのかが決まりません。
「社内のナレッジベースをAI化する」という目標は、一見正しそうですが、これでは何も決まっていません。そうではなく、「入社2年目のカスタマーサポート担当者が、過去のクレーム対応の経緯と社内規定を10分以内に自分で掘り起こし、一次返信のメールを起草できるようにする」といったレベルまで分解します。
データの粒度も、全社共有ドライブの雑多なフォルダではなく、特定のトラブル報告書だけに絞る。ノイズを減らしてAIのハルシネーションを防ぐための、現実的な妥協です。
ここで注意したいのは、アプリ名や機能名を決めることと、アウトカムを決めることは違うという点です。
「問い合わせ支援アプリを作る」「ナレッジ検索アプリを作る」と言えても、それだけではまだ足りません。チャットで展開するのか、専用アプリにするのか、業務システムに組み込むのか。提供方法の棚卸しはもちろん必要です。
ただ、それらはあくまで手段です。
問うべきことは、そのアプリによって誰の判断が軽くなり、どの確認作業が減り、どの業務の滞留が解消されるのかです。
そのアプリが、誰の判断を軽くするのか。どの確認作業を減らすのか。どの会議や承認プロセスの前に差し込まれるのか。そこまで置かれていなければ、PoCが終わった後に「便利そうだったが、次にどう使うのか分からない」という状態になります。
そこまで絞り込めば、観察すべき変化が明確になります。
AITでは、AI導入の成果を「判断」「行動」「状態」の3つの軸で捉えます。利用率や生成回数は見ますが、それだけでは GO / No-GO の判断材料としては不十分です。
ここで、管轄間でのすり合わせも絡んできます。
カスタマーサポートの部門長は「現場の負担が減るなら今すぐ入れたい」と言いますが、リスク管理の担当者は「顧客への誤送信リスクを誰が担保するんだ」と懸念を示す。だから、誰のどの判断をスキップさせるのかをDay0の段階で絞り込んでおかないと、後からひっくり返されてしまいます。
アウトカムを決める、なんて言うと大げさに聞こえるかもしれませんが、経営陣向けの報告書に見栄えの良い数字を並べ立てることじゃないはずです。検証が終わった瞬間に、「よし、このデータなら次に進める」と迷わず判断できるように、見るべき場所を先に絞り込んでおく作業です。
多くの企業が陥る罠は、検証期間がすべて終わってから「さて、どう評価しようか」と集まることです。
残ったのは単なる主観の寄せ集めであって、次の投資に踏み切るための条件にならない。どこでGOを出すかの条件は、システムを作る前に決めておかないと、後からどうとでも言い訳できてしまいます。
たとえば、カスタマーサポートであれば、「検証メンバーのうち、サポートが本当に必要な新人と中堅のメンバーが、週に複数回、AIが作成したドラフトを実際の返信行動に活用していること」をGOのラインに設定します。重要なのは、単にAI画面を開いたかではなく、実際の顧客対応の行動に組み込まれたかを見ることです。
もし、テキスト自体は綺麗に出力されているのに、現場が「怖くて使えない」と結局使い慣れた古いテンプレートの手打ちに戻っているなら、それはシステム構造の設計ミスか、プロンプトの調整不足です。あるいは、そもそも過去の対応履歴のデータの粒度が荒すぎて、AIが参照すべき「正しい判断理由」が存在しないのかもしれない。その場合は、ツールの選定ではなく、社内の入力ルールの見直しからやり直すべきだという判断になります。
あらかじめ分岐点を設定しておくことで、PoCは「成功か失敗か」の2択ではなく、次の打ち手を導き出すための検証ツールへと変わります。AITでは、この判断をあらかじめ以下の3つの選択肢に整理しておくことを推奨しています。
GO
事前に定めた行動変化や判断材料が確認できた状態。
対象業務や対象部署の拡大へ進み、次フェーズの範囲、体制、予算判断に接続する。
Conditional GO
可能性は見えたが、データ品質、業務設計、権限設計、運用責任などに課題が残っている状態。何を直せば次の判断に進めるのかを成果整理として残し、再検証の範囲と条件を明確にする。
No-GO
想定していた変化が観測できず、費用対効果や運用継続の見込みも立たない状態。この業務へのAI適用はいったん止め、学びを別テーマの判断材料として残す。
当たり前のことですが、判断の基準は現場の業務ごとに全く異なります。
全社一律のチェックシートで管理しようとするのは、正直無理があります。
企画書の作成を支援するAIなら、文字を入力する時間が半分になったかどうかは、実はどうでもいい話です。
重要なのは、その資料を持っていった際、役員からのダメ出しや手戻りの回数が減ったかどうか。あるいは、作成されたテキストの中に、判断の拠り所となる前提条件が漏れなく盛り込まれているか、です。
見積の現場なら、電卓を叩くスピードではなく、値引きの根拠が過去の類似案件と整合しているか、そして上司の見積もり承認が一発で通るかを見ます。
役員の承認プロセスであれば、承認ボタンを押すまでの秒数ではなく、差し戻しの理由がどこまでクリアになったか、あるいは定型的な案件が現場の課長クラスの判断で完結し、イレギュラーな案件だけが役員の元に上がってくる体制を作れたか、が問われます。
ツールが共通だからといって、評価指標まで共通にしてはなりません。システムをどこにはめ込むかで、追うべき挙動は変わるものですから、スタートラインの時点で「この業務なら、ここが動けば成功とみなす」という仮説が必要になります。
たとえば、企画書作成で見がちなのは、作成時間や生成回数です。ただ、本当に見たいのは、役員や上司からの差し戻しが減ったか、前提条件や根拠が明記され、説明にかかる時間が短くなったかです。
見積業務であれば、見積書の作成時間だけを見ても十分ではありません。値引き根拠に一貫性があるか、過去の類似案件を参照できているか、上司承認の差し戻しが減ったかを見る必要があります。
問い合わせ対応なら、返信文の作成時間よりも、ベテランへの確認回数が減ったか、一次対応で完結した割合が増えたか、対応理由が記録されて次の対応に使える状態になったかを見る。
承認業務であれば、承認処理時間や承認件数だけでなく、差し戻し理由が明確になったか、現場判断で完結した割合が増えたか、役員に上がる案件の質が変わったかを見るべきです。
最初から完璧なKPIを立てる必要はないのです。
実際に30日間動かしてみて、「追うべき数字はこれじゃなかった」と気づくことも多い。利用ログの回数ではなく、定例会議での確認プロセスの変化を見るべきだった、と判明すれば大収穫です。
何がボトルネックなのかが分かれば、次の開発の解像度は一気に上がります。
繰り返しますが、最初の30日間で完成品を目指してはいけません。
ここで入手すべきものは、次の役員会で「進むか、見直すか、やめるか」を迷わずに決定できるデータです。
GOであれば、次に広げる範囲とロードマップが見えている。Conditional GOであれば、修正すべき論点と再検証の条件が特定できている。No-GOであれば、なぜこの業務にAIがフィットしなかったのかを説明できる。
ここまで残っていれば、たとえプロジェクトがいったん止まったとしても、それは失敗ではありません。次の投資を止める、あるいは別テーマへ切り替えるための、価値ある判断材料が得られたということです。
一番新しい技術に飛びついたものの、「セキュリティの正式承認の目処が立たない」「追加開発にかかる費用対効果が説明できない」といったリアルな課題を直視せず、なあなあで終わらせてしまう。これでは、ただの社内イベントで終わってしまいます。
AIを組織に組み込む作業は、ツールを入れる前から始まっています。誰のどんな判断を書き換えるのか、どの数値が動いたら次のフェーズへ進むのか。それをDay0の時点で関係者と合意しておく。ここを最初に握っておけないから、終わった後に迷走するのです。
細かい仕様やツールの選定に迷う前に、まずは「何を基準に、次の判を押すのか」という実務の動線から整理を始めてみてください。
では、そのスタートラインであるDay0で、一体何を見せればいいのか。
私たちが考えるMVPは、単なるシステムの縮小版ではありません。現場の人が「自分の仕事のどこが変わるのか」を直感でき、経営陣が「何を見れば次の投資判断ができるのか」を想像できる体験です。
MVPは展示品ではなく、Day0で関係者の判断基準を揃えるための仕掛けです。
次回は、このMVPを、組織の判断を動かす体験としてどう設計すべきかを掘り下げます。