Aさんは画面を三秒ほど見て、「へえ、便利ですね」と言った。翌週も翌々週も、彼女の机の上では紙の請求書とExcelが並んでいた。後日Aさんに確認したところ、「自分でやってみる入口がなかった」「自分の書類で動くかどうか分からなかった」という二点が率直な理由として返ってきた。「便利そう」という印象はあったが、次の行動に結びつく動機がなかった、という説明だった。
この記事を読むと、AIデモを受けた側が動き出さない構造的な原因を把握したうえで、同僚の席で10分以内に実施できる「触らせる設計」の手順を自分で組み立てられるようになる。なお、以降の手順は一定の前提条件が整っている場合に有効であるため、まず「導入を進めない／触らせない段階」の確認事項から始める。
AI活用を検討する前に確認すべき条件を整理する
セキュリティポリシーと社内承認フローの事前確認
以降で述べる「触らせる設計」は、次の条件が確認済みであることを前提にしている。いずれかに該当する場合は、先に別の問題を解決する必要がある。
社内のセキュリティポリシーが外部LLM（大規模言語モデル：インターネット上の外部サーバーでテキストを処理するAIサービスの総称）へのデータ送信を禁止している場合、ChatGPTのような一般向けSaaSへの請求書データの貼りつけ自体が規程違反になりうる。
クラウドサービス利用のポリシー確認にあたっては、独立行政法人情報処理推進機構（IPA）が公開している「中小企業の情報セキュリティ対策ガイドライン」（IPA公式サイト、2023年3月改訂版・第3.1版）が参照資料として機能する。同ガイドラインはクラウドサービス利用時のリスク管理項目を列挙しており、社内規程の整備状況を対照確認する際に使いやすい。専任のIT担当者が不在の場合は、このガイドラインを起点に、経営者または管理職が確認主体となって判断するのが現実的な経路だと考えられる。
稟議フローの問題もある。月額費用が発生するプランへの切り替えや、業務での正式利用を認める社内承認がない状態でのデモは、担当者に意欲が生まれても申請経路がないため次の行動に進めない。承認フローが未整備の場合、「触らせる」体験設計の前に、管理職への事前説明と利用範囲の合意取りつけが先行する。
月額費用の承認ハードルについては、組織ごとに異なるが、一般的に月額5,000円以下の支出であれば担当者または課長決裁で処理できる企業が多いと考えられる。ChatGPT Plusは月額20ドル（2025年6月時点、OpenAI公式サイト記載の標準プラン価格）であるため、為替水準によっては担当者決裁の範囲内に収まる可能性がある。正式利用の申請前に、自社の購買規程における少額支出の決裁権限を確認しておくと、稟議の準備が具体化しやすい。
デモの対象業務がAIで処理できる性質かどうかの確認も必要だ。請求書の照合であれば定型テキストの抽出に分類されるが、業務フローが属人的な口頭確認に依存していたり、使用するデータが手書きや非テキスト形式だったりする場合、精度の期待値を正確に伝えないとデモが誤解を生む。
これらの条件に引っかかる場合、本記事で述べる「手の主体を変える」設計より前に解決すべき問題がある。以降の議論は、上記の制約が確認済みであることを前提にしている。
「近い例」が効かない理由を構造として把握する
人間の差異検出と「近似」の関係
Aさんが動かなかった理由を、当初は「保守的な性格」に帰属させていた。変化を避けようとする心理傾向は行動経済学で現状維持バイアス（デフォルトの選択肢をそのまま維持しようとする傾向。Samuelson & Zeckhauser, 1988年の論文で定式化）として記述されており、相手の性格に原因を置けば伝え方の見直しを省略できる。
しかし後日のヒアリングと複数の場面の観察を重ねると、別の説明が当てはまった。デモが「彼女の仕事に近い例」であって「彼女の仕事そのもの」ではなかった、という点だ。
自分がキーボードを打っていない実演は他人事になる。見せたのは、こちらが用意した請求書をこちらの手で処理する光景だった。どれほど業務に近い素材を選んでも、操作の主体が自分である限り、相手にとってはそれが他者の作業として映る。
加えて、近似は差分を際立たせる性質がある。自分の請求書とは取引先が違う、桁数が違う、フォーマットが違う。近ければ近いほど、観察者の認知は「でもうちはこう違う」という反例の生成に向かう。これは意地悪ではなく、類似刺激から差異を検出するという認知の標準的な働きだ。「あなたの仕事に近い例」を出した瞬間、相手の頭の中では「うちのケースはここに当てはまらない」という却下理由が生成される。親切のつもりが、断る材料を渡していた。
単一事例観察の限界について
以降の手順はAさんへのヒアリングと社内の複数場面での観察から導いた仮説であり、すべてのケースで同一の機制が働くとは断定できない。実務での適用にあたっては仮説として扱ったうえで検証することを勧める。
「見せる」から「触らせる」への設計変更と転機の観察
素材の所有者が変わったときの変化
やり方が変わったのは半ば偶然だった。別の担当者に呼ばれて席を立つ必要が生じ、Aさんに「これ、Aさんの今日の請求書でちょっとやってみてもらえます？画面はそのままで」と言い残して離れた。
戻ると、Aさんは自分の取引先の、自分が今日処理するはずだった請求書を貼りつけていた。「うちの、ここの表記ゆれも拾ってくれるんですね」と言った。声のトーンが、前週の「便利ですね」とは異なった。
差は一つだった。素材がこちらのものからAさんのものに変わった。処理された金額は、Aさんが今日Excelに打ち込むはずだった数字だった。近い例ではなく、本人の仕事そのものが目の前で処理された。この時点で、AIは「他者の芸」から「自分の作業を肩代わりする道具」に位置づけが変わった。
手順として整理する
デモの設計を変える場合、変更点は一つだ。「見せる」を「触らせる」に変える。相手の隣で、相手の素材を、相手の指で処理させる。プロンプト（AIへの指示文）はこちらが口頭で伝えてよい。重要なのは、Enterキーを押す指が相手の指であることだ。
この設計に切り替えると、制御を手放すことになる。相手の生々しい素材には表記ゆれがあり、AIが読み違える箇所もある。「きれいなデモ」を維持できない。しかし、その失敗がむしろ機能する。Aさんが「あ、ここ違う」と自分で直す一瞬の関与が、道具を自分の側に引き寄せる。エラーのない完璧な実演より、相手が一度つまずいて修正した経験のほうが定着しやすいと考えられる。
なお、Microsoft 365 Copilot（マイクロソフト社が提供する業務アプリ統合型AIアシスタント）については、マイクロソフト公式ブログ（Microsoft Tech Community、2024年以降継続更新）において業務効率化の導入事例が公開されている。それらの事例が語る成果の前提には、担当者が実際に手を動かして使い始めた段階が必ず存在する。導入事例が書かないその前段こそが、現場で最初につまずく箇所だ。
「設計ミス」の定義と回避手順のまとめ
この記事が言う「設計ミス」とは何か
タイトルにある「設計ミス」とは、デモの素材選びや事例の精度ではなく、操作の主体を誰に置くかという設計上の判断ミスを指す。具体的には次の二点だ。
一つ目は、伝え手が操作を手放さないままデモを完結させること。これは「見せる」設計であり、自分事化を起こさない。二つ目は、相手の素材ではなく自分の素材を使うこと。これが「近い例」の罠であり、差分の検出を促進して却下理由を量産させる。
回避手順は次の順序で整理できる。まず、セキュリティポリシーと社内承認フローを先に確認する。確認が取れたら、相手の素材（今日処理する予定の実際のデータ）を用意してもらう。次に、相手の隣に座り、プロンプトを口頭で伝えながら、Enterキーは相手に押させる。最後に、エラーや差異が出たときに「ここはこう直す」と一緒に確認する。この四つだ。
「無関心」というラベルを外す
同僚がAIを使い始めないとき、伝え手はつい「無関心」というラベルを貼る。しかしそれは、自分の設計上の問題を見ないための便利な診断名になっていることがある。
Aさんは無関心ではなかった。後日のヒアリングが示したとおり、「自分でやってみる入口がなかった」という状況認識を持っていた。渡された例が「近い」ぶんだけ「自分のではない」ことを正確に見抜いており、他者の芸に自分の業務を賭ける理由がないというその判断はむしろ的確だった。
近い例を百個そろえるより、本人の請求書を一枚処理させるほうが早い。それが、この一連の観察から得られた実務上の結論だ。
本記事はAskiveのAIネイティブ編集部が執筆し、編集長 四月鶉（Yotsuki Uzra）が監修しています。内容は公開時点で確認できた情報に基づきます。