会議室のプロジェクターに映るデモ画面を眺めながら、参加者が小さく頷いている。
プロジェクターが映す画面に、生成AIが生成した回答文が数秒で表示されます。
デモを操作する担当者がマウスをカチカチと動かして、「このように、問い合わせのドラフトがすぐ作れます」と説明する。
参加者の何人かが画面を見ながら「へえ、なかなか自然ですね」と頷いている。
ここまではだいたい問題なく進みますが、問題はその10分後です。
画面共有を閉じたあと、「これ、来月から業務で使いますか」と聞くと、急に歯切れが悪くなります。
「もう少し見たい」「複雑な案件は怖い」「で、いくら効果が出るのか」。だいたいこのあたりの話が出ます。
誰も反対しているわけではないのですが、誰も「やる」とも「やめる」とも言えずに、PoCの後がここで止まることは珍しくありません。
技術が未完成なわけではありませんし、回答もそれなりに自然です。
それでも決まらないのは、PoCを始める前に、「現場の仕事や判断がどう変わったらGOなのか」を決めていなかったからです。
PoCは何かを試すこと自体が目的でしょうか。
次に進むのか、止めるのか、条件を変えてもう一度試すのか。その判断をするためにあるのです。
PoCを走らせれば、いろいろな数字が残ります。
ログインした人数、5段階評価のアンケート、生成された文章の件数。
こうした記録はもちろん必要ですが、それをきれいに並べても、「では本番化を進めましょう」という判断には、なかなかつながりません。
ある問い合わせ対応の案件では、AIは回答案を作れるようになったし、利用者アンケートにも「思ったより使える」という声が並んだ。
一見すると成功ですが、実際に業務へ組み入れるかどうかを考えると、知りたいことはもう少し別のところにあります。
担当者は、AIが生成した文章を、どの程度そのまま利用できるのか。
以前なら、判断に迷うたびに有識者の席まで行って、「これ、どう答えればいいですか」と聞いていたが、その確認する回数は本当に減ったのか。
過去にトラブルになったような難しい問い合わせが来たとき、AIの回答がおかしいことに人が気づける運用になっているのか。
このあたりまで確認しなければ、本番で使えるかどうかは分かりません。
「AIが回答を作れました」
「利用者から好評でした」
これは、PoCで起きたことです。
でも、経営が知りたいのはその先で、「この種類の問い合わせなら、担当者がほぼそのまま返信できる」
あるいは、「このパターンだけは、人が確認しないと危ない」
そこまで判明すれば、ようやく次の話に進めます。
PoCの報告会では、GOなら成功、No-GOなら失敗、という空気が生まれやすいものです。
そうなると、少しずつ言葉が曖昧になります。
運用上かなり無理があるのに、「課題は残るものの、概ね順調です」と書く。
現場の確認作業がむしろ増えそうなのに、「一定の手応えがありました」とまとめる。
誰も止めないが、誰も責任を持って進めない。
その状態のまま、PoCだけが何ヶ月も続いていくことがあります。
実際にアシストAIテラス（AIT）でも、PoCに進めない方がよいと整理した案件があります。
相談を受けた以上、何か作った方がよいように見えることもありますが、AIを入れても効果が薄い。誰が最終判断するのかも決まっていない。そういう状態なら、無理にPoCへ進めないことがあります。
これは、その取り組みとしてはNo-GOかもしれませんが、組織としては重要な前進です。
進めるべきではない条件が分かったからです。
判断を曖昧にしたまま本番化して、結局ほとんど使われないシステムに毎月保守費用を払い続ける。
そのほうが、ずっと大きな失敗です。
すべての案件をGOにする必要はありません。
AITとしては、「この条件なら進めない」と早めに分かることも、PoCの重要な成果だと考えています。
AITがAI導入プロジェクトに入るとき、先に確認するのは現場の仕事です。
誰が、どの場面で判断を止めていて、AIを入れたら、今ある確認作業のどれが減るのか。
逆に、どこに人の確認を残さなければいけないのか。
そして、何が起きたら「次へ進める」と言えるのか。
ここを先に決めます。
しかし、AITはお客様の業務そのものの専門家ではありません。
営業の見積判断も、問い合わせ対応の例外処理も、レポートを使う会議での判断も、日々扱っているのは現場の方々です。
だから、画面を作るよりも、なりよりも先に、現場の有識者にヒアリングをします。
「どこで一度手が止まりますか」
「上司に差し戻されるとき、何が足りないと言われますか」
「AIが回答の初稿を作ったとき、どこまでそのまま使えますか」
「どこから先は、人が見ないと怖いですか」
こうして伺っていくと、最初は感覚的に話されていた業務が、少しづつ整理されていきます。
なんとなく不安だったところが、「顧客の前提条件が抜けると差し戻される」になる。
「上司の確認がが必要」だったものが、「この金額以上、この条件付き、この納期リスクがある場合は、承認が必要」になる。
有識者に教えてもらっているうちに、有識者自身も、自分たちの判断を説明するために整理していく。
PoC後に判断できるかどうかは、この時点でどこまで整理できているかにかなり左右されます。
以前相談を受けた営業部門の案件でも、作成時間が30分短くなったかは確認しましたが、本当に困っていたのは上司からの差し戻しでした。
「顧客の前提条件が抜けている」と突き返される回数は減ったのか。
過去の商談で残した情報が、ちゃんと初稿に入るようになったのか。
作る時間は短くなったけれど、修正に倍の時間がかかるようになっていないか。
実務では、このあたりが効いてきます。
何を見るかを先に決めておけば、PoC後の会話も変わります。
「使ってみてどうでした？」という感想戦ではなく、「上司のチェックに耐える初稿になりましたか」
を事実で確認できるようになります。
便利だった。思ったより自然だった。もう少し調整すればいけそうだった。
これでは判は押されないものです。
対象にする業務。
そこで止まっている判断。
AIに任せてよい範囲。
人が確認を残すべき範囲。
そして、30日後にGO/No-GOを判断するための材料。
ここが曖昧なままだと、PoC後の会議は「便利でした」「もう少し見たいです」で終わってしまいます。
AITがPoC前に整理するのは、この部分です。
検証期間を長くすれば、判断材料が増えるように思えますが、実際には必ずしもそうなりません。
時間が経つにつれて、
「せっかくだから他部署でも使えないか」
「画面をもう少しきれいにしたい」
「このシステムとも連携できないか」
と、確認したいことが増えていきます。
気づくと、最初に何を知りたくてPoCを始めたのかがぼやけている。
だから、最初のアクションは30日程度に区切ります。
30日ですべての不安をなくす必要はありませんし、全社の運用ルールを完成させる期間でもありません。むしろ、全部を確かめようとするとPoCは長引きます。
AITが30日で確認することは、「このまま続ける理由があるか」です。
足りないものが分かったなら、それも十分な結果です。
問い合わせ対応なら、生成された文章の滑らかさを延々と評価するより、「有識者への確認が実際に減ったか」を確認します。
レポート作成なら、作業時間が何分減ったかだけではなく、そのレポートを使う会議で判断が早くなったかを確認します。
これは、1ヶ月後の会議で、
「で、PoCやってみてどうでした？」
から話を始めないためです。
30日後の会議で必要なのは、感想ではなく「続ける理由は確認できたか」を話せる状態にしておくことです。
実際のPoCは、きれいなGOとNo-GOに分かれることのほうが少ないと思います。
技術としては問題ないし、定型的な問い合わせでは現場でも問題なく使えたけれども、
少し複雑な案件になると回答が不安定になる。
こういう結果は、PoCではよくあることです。
ただ、使える範囲が見えてきたので、むしろ前進です。
そこで使うのが、Conditional GO、つまり条件付きGOです。
たとえば、最初は問い合わせ全般を対象にしていたものを、定型的な質問だけに絞る。少し判断が必要なものは、人の確認に戻す。それだけで運用できるケースもあります。
つまり、「ここを変えれば進める」という条件を明確にして次へ進みます。
GOかNo-GOかの二択しか持っていないと、少しでも不安が残った瞬間に、
「念のため、あと1ヶ月だけ様子を見ましょう」
という話になりがちで、その1ヶ月後にまた同じ話をする。
Conditional GOは、その状態を避けるための考え方でもあります。
条件付きで進めるときに、決めるべきことが複数あります。
対象業務を狭めるのか。
最初に使う部門を絞るのか。
確認者を置くのか。
運用ルールを軽くするのか。
データの持ち方を見直すのか。
どの条件を変えれば、現場で使える形に近づくのか。そこまで決めて初めて、Conditional GOは次の設計になります。
検証が終わると、たいてい立派な報告書ができます。
実施内容や参加人数、利用回数、アンケート結果。それにグラフや画面キャプチャまで、資料としてはきれいにまとまっていますし、報告会でも「良い取り組みでした」と言ってもらえる。
それでも、そのあと誰も追加予算を取りにいかず、誰も業務フローを変えず、システムもそのまま止まっている。
そういうPoCはあります。
報告書を作ることと、事業を前に進めることは、やはり別の話なのです。
会議が終わったあとに、予算を取りにいくのか、今回は止めるのか。少なくとも、次に何をするかが一つ決まっていることが重要で、そこまでいって、初めて検証が仕事になります。
もちろん、AITでも実際に触れるものは作ります。
画面がなければ、現場も経営も具体的にイメージできないからです。
ただ、プロトタイプは「すごいですね」と言ってもらうために作るわけではなく、その画面を使って、現場の仕事が本当に変わるのかを確かめるためです。
PoCが止まっているとき、必要なのは「もう一度検証すること」でしょうか。
むしろ、対象業務、変えたい判断、観測すべき事実、GO/No-GOの条件を整理し直すことが先かもしれません。
AITが支援するのは、対象にする業務を絞り、そこで変えたい判断を明確にし、何を観測すればGOと言えるのか、どの条件ならNo-GOなのか、何を直せばConditional GOにできるのかを整理することです。
つまり、PoCの結果を「次に進む」「止める」「条件を変えて進める」という判断につなげるための支援をしています。