AIは「作って配る」だけでは使われない ― 橋渡しという仕事
【BizDev公開日誌 #10 】
ツールは作った。アカウントも配った。なのに、現場で使われない。社内AIツールを「導入した」ことと「使われている」ことは、まったく別物でした。今回は、配ったAIツールが定着しない“試行と定着の壁”について、私たちのチームで議論した内容を書きます。
結論から言うと、うまくいかなかった原因は、ツールでも現場でもありませんでした。足りなかったのは、その間をつなぐ「橋渡し」
——配ったツールを、現場の一人ひとりが実際に使って成果を出せるところまで持っていく設計でした。どう試してもらい、どう日々の業務に組み込み、どう品質を担保するか。考えるほどに、ここを担うことこそ、これからのBizDevの役割ではないか、と思うようになりました。
「導入した」と「使われている」は、別物。
現場で起きていた「4つの症状」
私たちは、広告クリエイティブをAIで生成する社内ツールを内製し、現場に提供しました。ところが、起きたのはこんな現実でした。
配って終わり：アカウントは配ったのに、起動すらされていない
試して落胆：触ってはみたものの、「思ったのと違う」「自分でやった方が早い」と離れてしまう
使うのは結局できる人：使い続けるのは、もともとAIがなくても成果を出せるメンバーだけ
事例が共有されない：うまくいった例があっても、社内に流れてこない
チームで議論してたどり着いた最大の反省は、「どうしたらみんなが使ってくれるか、という想像力が足りていなかった」ということでした。
最初は「ツールの完成度が足りないのだろう」と考えました。プロダクトの品質を上げれば、使われるはずだ、と。でも、磨いても実際に使われるイメージが湧きませんでした。
同じツールを渡しても、使いこなす人と離脱する人に分かれます。ツールそのものが原因なら、ここまで差はつかないはずです。差を生んでいたのは、ツールと現場の「あいだ」でした。どう試してもらい、どう業務に組み込み、どう品質を担保するか——冒頭で挙げた「橋渡し」が抜け落ちていました。
橋が切れるのは、最後に使う個人の中
では、その橋はどこで切れていたのか。どんな仕組みでも、最後に使うのはひとりの個人です。そして壁も、個人の中に2つ現れました。「試そうと思えない」壁と、「試しても続かない」壁です。
一つめは、試そうと思えない。これはスキル不足というより、心理的なハードルです。どう使えば、どんなアウトプットが、どのくらいの速さで返ってくるのか——使う前には、その見通しが立たない。やってみるまで分からない“ガチャ”のような状態では、忙しいなか、わざわざ手をつける気になれません。そもそも、何を聞けばいいのか、どこまで聞いていいのかもわからない——そんな悩みすらあります。この見通しのなさが、試す前の壁の正体です。
二つめは、試しても続かない。ここを左右するのは、アウトプットの品質です。一度使っても、出てきたものがいまひとつなら「やっぱり自分でやった方が早い」と離れてしまったりする。そして、その品質を決めるのが、やりたいことを分解してAIに渡すディレクション力でした。この品質が、試した後の壁の正体です。
壁は、試す前の「見通しのなさ」と、試した後の「品質」。
プロダクトを磨いても、埋まらない差がある
アウトプットの品質を上げる手は、大きく2つあります。一つはプロダクト側を磨くこと。裏側のプロンプトや入力欄を作り込めば、誰が使っても“そこそこの品質”までは出せるようになります。これは作る側だけで完結します。
でも、それだけでは埋まらない差が残ります。どれだけ裏側を作り込んでも、最後に使う人のディレクションがあいまいなら、いい出力は出ません。“結局、自分でやった方が早い”の多くは、ここから来ていました。もう一つ、そもそも試してもらえるかも、プロダクトを磨くだけでは変わりません。使い方も出力も読めない“ガチャ感”が残るかぎり、人は手をつけないからです。
残るこの2つ——出力を左右するディレクション力と、試す前の心理的ハードル——は、プロダクトの中ではなく、人とプロセスの側にあります。橋渡しとして設計しきれていなかったのは、まさにここでした。
プロダクトは“そこそこ”まで連れていける。その先は、人の仕事。
いま、私たちが打とうとしている手
私たちがいま検討している打ち手を、さきほどの2つの壁——「試そうと思えない」と「品質が出ない」——に当てて整理してみます。
試すハードルを下げる（見通しを持たせる）
実案件ハンズオン：実際の案件のお題で1時間まるごと回し、「こう使えば、これがこの速さで出る」を体で覚える
利用状況の可視化：使っていない人・1回で離脱した人を特定し、ヒアリングして次の一手へつなげる
品質を上げる（プロダクト側）
入り口を設計する：用途を選ぶと必要な入力欄が出て、プロンプトが生成される。自由度をあえて下げ、ディレクションが苦手でも一定の品質が出るようにする
現場の声を返すサイクルをつくる：要望や詰まりを吸い上げてプロダクト改善に反映し、「言ったら良くなった」が見える状態にする
品質を上げる（人側＝ディレクション）
ロールモデル伴走：成果を出している人の「指示の型」を、全員が盗めるように吸い上げる
事例共有の場づくり：「いい出力」の基準が見えるよう、プロンプトと成功例を社内に流通させる
共通するのは、配って任せるのではなく、現場と作る側を往復しながら、使われるまで設計しきること。ツールを渡す側の仕事は、配った時点では終わっていませんでした。
配って終わり、ではない。現場と往復して、使われるまで設計する。
まとめ
壁は「導入」ではなく「試行→定着」の間にある。そして、最後に使うのは結局ひとりの個人
詰まりは個人の中の2つ。「試そうと思えない（使い方も出力も読めない“ガチャ感”）」と「試しても品質が出ない（ディレクション力）」
プロダクトの作り込みで“そこそこの品質”までは出せる。でも、その先——使われるまで設計しきる「橋渡し」——が、私たちの答えだった
配れば現場は変わる——その前提が、そもそも間違っていました。プロダクトを作って配るところまでが仕事だと思っていた。でも、本当の仕事はその先にありました。
作ったものが、最後に使う一人ひとりにちゃんと届き、いい出力が出せるところまで。現場と作る側を往復しながら、使われるまで設計しきる。この「橋渡し」が、今回たどり着いた答えです。そしてこれは、プロダクトを作ることと並ぶ、AI時代のBizDevの役割になっていくはずです。
あなたの現場でAIツールが使われないとき、足りないのは「試す前の見通し」でしょうか、それとも「いい出力を出す力」でしょうか。
作って配って、終わりじゃない。使われるまでが、BizDevの仕事。
次に読む
“定着の手前”を今回は書きました。いざ使われ始めると、今度は「作る速さに、確認する速さが追いつかない」という次の壁が現れます。それを設計の問題として扱ったのが前回です。
