はじめに
この記事は、生成AI（LLMなど）を「研修で教える題材」としてではなく、普及活動そのものを動かす推進エンジンとして使うことを提言します。
この記事の内容は私個人の経験・見解であり所属する企業・団体・組織を代表するものではありません。
筆者自身が社内AI普及に関わる中で得た経験、反省、思いを公開されている先行事例・研究を組み合わせて構成した提言です。
勤務先の社内AI普及活動に技術アドバイザーとして関わらせていただき、最初の全社向けトレーニングを担当させていただきました。このトレーニングはとても多くの社員の皆様にご参加いただき大盛況となり、私が社内で実施したトレーニングの中で過去最高の参加者数を記録しました。社員の皆さんのAI活用への関心と期待の高さを表していると思います。ただ、あらゆる部門のあらゆる職種の皆さんに共通のトレーニングを提供するということで、社内AIツールの機能紹介、典型的な利用方法のご紹介といった内容となってしまいました。参加者の皆様からは役立つ内容とご評価いただいたのですが、参加者各自の業務にどう役立てられるかという点では、課題が残るものでした。
本記事は、ChatGPT、Claude、Geminiなどの生成AIツール、あるいは社内向けAIチャットボットがすでに導入されている、または導入が決まっている組織を前提としています。「どのツールを選ぶか」「予算をどう確保するか」といった導入以前の話題は扱いません。ツールは手元にあるのに現場で使われない、という状況をどう動かすかが本記事のテーマです。
皆様の会社や組織では、こんなことは起きていませんか？
偉い人）社内でAI活用を普及させよう！
AIに詳しい人）そのためには、使ってもらうのが一番！
現場のリーダー）何に使ったらいいだろう？みんなアイデアある？
現場の人）チャッピーはジブリには詳しいけど、業務でって言われるとピンとこないです！
偉い人）何でもできるって聞いてるぞ！
ブランクキャンバス問題
「何でもできるが、どこから始めればいいか分からない」 という状態を ブランクキャンバス問題 というそうです。
大きなキャンバスを前に何を描いたらいいのかわからなくて途方に暮れている人の姿が目に浮かびますね（美術の授業のときの高校生の私です。青空だけ描いて怒られました）。
AI駆動AI普及活動～AAAP（トリプルA P）～とは
「何でもできるが、どこから始めればいいか分からない」というブランクキャンバス問題 で思ったようにAIの活用が進まない、そんなときのスタートラインとなるのが、AI駆動AI普及活動です。英語名は、AI-Driven AI Adoption Programで、略称は、AAAP（トリプルA P）です。
この手法自体は、既に実践されている企業・団体もあることかと思いますが、「AI駆動AI普及活動」という名称自体は、私がこの記事のタイトルを考えていて名付けたものです。もしかすると、もっと一般的な名前があるのかもしれませんが、とても名が体を表しているネーミングではないかと思っています。
AI駆動AI普及活動は、繰り返しになりますが生成AI（LLMなど）を「研修の題材・ターゲット」ではなく、普及（adoption）そのものを前に進める推進エンジンとして活用するアプローチです。
社員に"使い方を教える"よりも、実務の中でAIを使う体験を設計して、体験してもらいながら部門としてのユースケースと障壁（ポリシー・データ・心理的抵抗など）を収集・整理して、次の打ち手につなげます。
さらに、この過程で集まる業務プロセスの情報は、今注目が高まっているAIエージェント（業務を自律的に実行するAI）の導入検討にも活用できます。チャット型AIの普及を主軸にしながら、将来のエージェント化への布石も同時に打てるという点にも Appendix で触れています。
このアプローチは Human-in-the-loop（人間が主体となる前提）で運用します。AIは対話の進行、整理、統合を担い、意思決定と最終判断は人間が担います。
なお、本記事で述べるアプローチは、筆者自身が社内AI普及に関わる中で得た経験と、公開されている先行事例・研究を組み合わせて構成した提言です。特定の組織でこのフレームワークを一気通貫で実施した実績に基づくものではありません。「こうやってうまくいった」という成功談ではなく、「こう組み立てれば機能するのではないか」という設計図として読んでいただければ幸いです。
1. コンセプトは、AIで"普及活動"を駆動すること
生成AIの活用が定着しない、本当の理由
生成AIの社内展開がうまくいかないとき、「操作方法、プロンプトの書き方を知らない」「研修が足りない」といったことが原因として語られがちです。しかし、実際には使い方の知識不足よりも「業務文脈の欠落」と「不確実性」が大きなボトルネックになっていることが多いのではないでしょうか。
たとえば、「何をどう指示したら良いか分からない」という最初の摩擦。これがまさにブランクキャンバス問題です。Gemini や Claude などの主要AIプロダクトも、初回利用時にテンプレートやサンプルプロンプトを並べることでこの問題に対処しています。プロダクト側がこれだけ工夫しているのは、この「最初の一歩」を超えられるかどうかが定着を左右するからですね。多くのAIプロダクトがテンプレート駆動型でこの最初の壁を乗り越えようとしているわけです。
次に、「自分の業務にどう当てはめれば良いか分からない」という翻訳の壁があります。生成AIは汎用ツールであるがゆえに、具体的な業務への適用イメージは自分で考える必要があります。しかし、日々の業務に追われている現場の社員にとって、それは想像以上に難しい作業です。
さらに、「使って良いデータと悪いデータがあいまい」というポリシーの不安や、「なんとなく怖い、失敗しそう、責任が不明」という心理的障壁も、社員がAIを避ける大きな理由です。Prosci社のAI採用に関する調査（AI Adoption: Driving Change With a People-First Approach）でも、全体的な理解不足、AIの効果的な使い方への不安（自分に使いこなせるのかという不安）、未知のリスクへの恐れなどが、普及を妨げる要因として挙げられています。
「教える」のではなく「使いながら障壁を溶かす」
AI駆動AI普及活動では、これらの障壁を研修で「教えて」解消するのではなく、AIをファシリテーターやインタビュアーとして活用することで、使う体験そのものを通じて障壁を溶かしていきます。
ここで、「溶かす」という表現に違和感を覚えるかもしれません。これは、「これを入れればすべて一気に解決」という銀の弾丸ではなく、人とAIがいっしょに、徐々に障壁を明らかにして取り除いていくことを表現しています。
具体的には、社員がAIと対話する中で、自分の業務の繰り返し作業やボトルネックを 言語化 し、AIがそれを整理してユースケース案に変換します。この過程で、社員は自然とAIの使い方を学びますし、何に使えそうか、何が障壁になっているかの情報も同時に明らかになります。そして、それを部門単位で集約して次のアクションへつなげていくものです。
つまり、普及活動のために行うことそのものが、社員のAIへの最初のAI体験であり、ユースケースの発掘であり、障壁の可視化でもある。一石三鳥、あるいはそれ以上の効果が同時に得られるわけです。
2. プロセスの全体像
この手法は、AI体験 → 発見の共有 → チームの気づき という3つのステップで構成されます。各ステップで使うものの名称は、AI体験ガイド・発見共有ノート・チーム気づきレポート です。順を追って説明します。
活動の進め方としては、部門内の有志や推薦された社員が チャンピオン（アンバサダー） として旗を振り、参加者を巻き込む方式を基本としています。上意下達よりも「同じ業務をしている仲間の声」が届きやすく、自発的な参加が生まれやすいためです。組織文化によってはマネージャーが主導するトップダウン型が適することもあります。詳しくは第6章を参照してください。
2.1 AI体験
AI体験ガイドは、社員がAIにそのままコピー＆ペーストして使うプロンプトです。ここで重要なのは、このプロンプトは社員への説明文ではなく、AIへの指示書だという点です。
社員の操作は「コピペして貼り付ける」だけ。あとはAIが質問をしながら対話を進め、業務の状況を引き出し、具体的な活用案とアウトプットまで導いてくれます。
さらに、AI体験ガイドに取り組む前に、まずAIの便利さを体感してもらうステップを設けることも有効です。メールの下書き作成、チャットの履歴の要約、議事録の要約、FAQ草案の作成など、誰でも使う機会がありそうな便利プロンプトのテンプレートを数種類用意し、先に試してもらいます。AI体験ガイドの対話の中では、その体験を踏まえて「実際に使ってみてどう感じたか」「自分の業務で他にも使えそうだと思った場面はあるか」を聞くようにします。こうすることで、AI体験ガイド自体の複雑化を避けながら、AIの実利を先に体験した状態で業務の振り返りに入れるため、対話の具体性と社員の前向きさの両方が高まります。
パナソニックコネクトが社内向け生成AIツール「ConnectAI」を導入した際には、よくある日常業務15件のプロンプトサンプルをトップ画面に用意し、すぐに使える状態で社員に渡していたそうです（パナソニックコネクト プレスリリース）。このように「編集させない」「考えさせない」「コピペ一発で始まる」設計にすることが、最初の摩擦を大きく下げるのではないかと考えています。
私の勤務先でも、AIの社内普及の初期段階にすぐに使えるプロンプトの共有が行われたことが普及を一気に加速したような気がします。スラッシュコマンド一つで登録済みのプロンプトをさっと呼び出して使える体験が、ブランクキャンバス問題を乗り越えたようです。
2.2 発見の共有
AIとの対話が終わったら、社員はその気づきを発見共有ノートとして仲間やチャンピオン（アンバサダー）と共有します。
発見共有ノートの内容は、たとえば「自分の業務で試してみたいユースケース案を2つ」「来週実際に試すこと」「そのために必要なデータや権限」「やるにあたっての注意点やリスク」といった内容です。AIとの対話の中でこれらの情報はほぼ出揃っているので、社員はそれを確認・整形するだけで済みます。
「上司への提出」ではなく「仲間への共有」という形にするだけで、同じ情報が集まるのに社員の体験は大きく変わります。SlackやTeamsへの投稿、共有会での口頭共有といった形でも構いません。
ただし、ここでHuman-in-the-loopの原則が重要になります。AIが出力した内容をそのまま共有するのではなく、本人が必ずレビューし、内容の妥当性、機密情報の有無、正確性を確認した上で共有します。AIはあくまで下書きの作成者であり、発見共有ノートのオーナーは社員自身です。
2.3 チームの気づき
個人単位のAI体験で得られた情報は、そのままでは「あの人はこう言ってた、この人はこう考えてる」というバラバラな点の集まりにすぎません。これを組織の打ち手に変換するのがチーム気づきレポートの役割です。
チャンピオン（アンバサダー）またはマネージャーが複数名の発見共有ノートをまとめてAIに渡し、チームや部門の視点で情報を統合します。AIは、共通して出てくるテーマ（効きどころ）、ロールごとのユースケースの傾向、優先度の高い取り組みと次のアクションといった観点で整理し、アダプション計画（AI活用を部門に定着させるための行動計画）のたたき台を作ります。なお、経営層への報告や他部門との調整といった場面では、「チームアクションプラン」として提示するとより伝わりやすくなります。
チーム気づきレポートには、以下の項目を含めることを推奨します。
| 項目 | 内容 |
|---|---|
| 今サイクルの概要 | 参加者数・発見共有ノートの収集数 |
| ユースケース候補トップ3 | ロール別・優先度付き。「すぐ試せる」「中期的に検討」などの段階分けがあると実行計画に落とし込みやすい |
| 障壁トップ3 | タイプ（ポリシー／アクセス権／心理的抵抗／リーダーシップ）を添える。タイプが分かると担当部門が明確になる |
| 推奨アクションと担当部門案 | 「誰が何をするか」のたたき台。確定ではなく議論の出発点として提示する |
| 次サイクルへの反映提案 | 未解決の障壁、次に招待すべきロール、AI体験ガイドの改訂ポイント |
この構成でAIに生成させることで、チャンピオン（アンバサダー）やマネージャーが「読んで優先度とオーナーを書き込む」だけで次の打ち手に進める状態を作ることができます。
McKinseyは自社での生成AI普及にあたり、セグメンテーション分析でユーザーをタイプ別に分類し、グループごとにトレーニングをカスタマイズしたと報告しています（Reconfiguring work: Change management in the age of gen AI）。チーム気づきレポートはこれと似た「ユーザーの状況を分類して、タイプに応じた打ち手を考える」という効果を、プロンプト一つで簡易的に実現する仕組みと言えます。
ただし、このたたき台はゴールではなく起点です。たたき台を実際の打ち手に変換するプロセスと、次サイクルへの反映ルールについては第6章で詳しく述べます。
3. 一度で得られる4つの効果
この手法のユニークな点は、一度のサイクルで複数の効果が同時に得られることです。
最初のAI体験
まずAIに触れる体験そのものが、社員にとってのAI活用開始になります。「いつかやろう」「研修を受けてから」という先延ばしを排除し、実務の文脈でAIを使った最初の一歩が自然に踏み出されます。
発見（ユースケース発掘）
AIとの対話による言語化を通じて、社員自身の業務文脈から具体的なユースケース候補が見つかります。トップダウンで「こういう使い方をしなさい」と渡されたユースケースよりも、自分で見つけたものの方が定着しやすいのは、心理学研究で知られる「IKEA効果」で説明できるかもしれません。これはHarvard Business Schoolの研究（The IKEA Effect: When Labor Leads to Love）で検証された概念で、人は自分が作成に関わったものに高い価値を感じる傾向があるというものです。Asanaの記事（5 Innovative Ways to Encourage AI Adoption in Your Org）でも、社員自身にAIユースケースを選ばせることで「自分で作ったものへの愛着」が生まれ、普及を後押しすると述べられています。
障壁の可視化
「そのデータを使って良いか分からない」「ツールへのアクセス権限がない」「失敗したときの責任が不安」といった、普及を止めている要因がAIとの対話を通じて自然に表面化します。これらの障壁は、社員に直接聞いてもなかなか出てこないことが多いですが、AIとの1対1の対話では心理的安全性が高いため、率直な声が拾いやすくなります。
チームの気づき（組織レベルの統合）
個人の学びをそのままにせず、チーム気づきレポートを通じて部門の打ち手（優先度、ガードレール、フォローアップの設計）に集約します。McKinseyのGlobal Survey on AI（2024年版）によれば、生成AIを活用している企業の回答者の8割以上が、全社的なEBIT（Earnings Before Interest and Taxes、利払い・税引き前利益。本業の稼ぐ力を示す指標）への目に見えるインパクトを報告できていないとのことです。なお、翌年の2025年版調査でもEBITインパクトを報告できたのは回答者の39%にとどまっており、改善傾向はあるものの大多数が全社的な財務効果を実感できていない状況は続いています。個人の活用が組織の成果につながらない要因の一つは、この「統合」のステップが欠けていることにあるのではないでしょうか。
4. AI体験ガイドの設計ポイント
AI体験ガイドは、このフレームワークの中心にあるパーツです。設計時に押さえておきたい要素を順に説明します。
前提コンテキスト
最初に、部門の目的、使用するAIツール、今回のゴールを簡潔に記載します。「なぜこれをやるのか」が明確でないと、社員は「またよく分からないタスクが降ってきた」と感じてしまいます。
AIの役割定義
プロンプト内で、AIの振る舞いを明確に指定します。たとえば「あなたは業務改善の相談相手として、社員にインタビューして活用案を具体化してください」のように、AIが何者として対話するのかを定義します。これにより、AIが一方的に提案を並べるのではなく、社員から情報を引き出す対話が生まれます。
対話の手順
AIに聞かせたい項目を順序立てて指示します。日々の業務内容、繰り返し発生する作業、主な成果物、関わる関係者、困りごと、制約といった項目を順に聞くことで、網羅的に業務文脈を把握できます。
ポリシーと安全ルール
入力してよい情報と避けるべき情報、守るべきルールをプロンプト内に明記します。社内のガイドラインページへのリンクを含めるのも有効です。「何を入力して良いか分からない」という不安はAI活用の大きな障壁なので、ここを曖昧にしないことが大切です。
AI体験ガイドを社員に配布する前に、セキュリティ・コンプライアンス部門のレビューを通しておくと良いでしょう。プロンプト内のデータ入力ルールが社内ポリシーと整合しているか、利用するAIツールのデータ取り扱い条件（学習への利用有無、データの保存先など）が自社の基準を満たしているかを事前に確認しておけば、展開後に「待った」がかかるリスクを避けられます。具体的なプロンプトという成果物を見せながら相談できるため、抽象的な「AIを使いたい」という依頼よりも、セキュリティ部門にとっても判断しやすいはずです。
アウトプットの形式指定
最後に、AIが対話の結果としてどのような形式でまとめるかを指定します。ユースケース案（2つ程度）、次週試すToDo、必要なデータや権限や前提条件、リスクと注意点を箇条書きや表でまとめさせるようにすると、発見共有ノートの品質が安定します。
5. Human-in-the-loop（役割分担を明確にする）
このフレームワークでは、AIと人間の役割分担を曖昧にしないことが成功の鍵です。
AI出力のオーナーは人間
AIが作成した発見共有ノートは、共有前に必ず本人がレビューします。内容の妥当性、機密情報が含まれていないか、事実関係は正確かを確認し、問題があれば修正してから共有する。この手順を省略してAI出力をそのまま共有する運用を許容すると、品質の低下だけでなく、「AIのせいだから自分は責任を取らない」という意識が生まれかねません。
一方で、このルールには社員にとってのメリットもあります。「AIの出力をそのまま使うわけではなく、自分がレビューして直してから出す」という前提が明確であれば、「AIが間違ったことを言ったらどうしよう」「信用していいのか分からないから怖い」という躊躇が和らぎます。最終判断は自分にあるのだから、AIの出力が完璧である必要はないし、下書きとして使って自分の目で確かめて直せばいい。そして、レビューに時間をかけることは正当な業務プロセスだと位置づけることもできます。この認識が広がると、「信頼できないから使わない」という慎重派の社員も最初の一歩を踏み出しやすくなるのではないでしょうか。
意思決定は人間が行う
チーム気づきレポートで作られるアダプション計画のたたき台は、あくまで出発点です。どのユースケースを採用するか、どの順番で試すか、どんなルールを設けるかといった意思決定はマネージャーが行います。AIは加速役であって、判断者ではありません。
なぜ役割分担を明示するのか
Prosci社の調査（AI Adoption: Driving Change With a People-First Approach）では、AI出力の信頼性への懸念がAI普及を妨げる要因の一つとして指摘されています。社員がAIの正確性やバイアスに疑問を抱くと利用を躊躇しますが、逆に「人間が最終チェックする」という前提が明確であれば、安心して使い始めることができます。Human-in-the-loopの明示は、社員の心理的障壁を下げる効果もあるのではないかと考えています。
6. 運用のポイント
成功条件
開始を限りなく簡単にする
繰り返しになりますが、コピペ一発で始まることが最重要です。「まずこのドキュメントを読んで、自分の業務に合わせてプロンプトを編集して…」と言った瞬間に、多くの社員は離脱します。
共有の場を用意する
SlackやTeams、Discordなどに専用チャンネルを設け、Q&Aや学びを集約する場所を作ります。AIHRの研究（Frontline AI Adoption in HR）でも、ボトムアップ型のAI普及を成功させるには、先行して使い始めた社員を身近な相談役やお手本として位置づけ、実践知を共有する場を作ることが推奨されています。McKinseyでも社内AI「Lilli」の普及にあたり、積極的な利用者で構成される「Lilli Clubs」を組織し、活用のヒントやツール改善の提案を集めることで普及を加速させたと報告しています（Reconfiguring work: Change management in the age of gen AI）。
スーパーユーザーを意図的に設定する
AI体験ガイドを最初に試すアーリーアダプター層をあらかじめ選定しておくと効果的です。選定の基準は年齢や役職よりも、自分の業務プロセスを言語化できること、新しいツールを試すことへの抵抗が低いこと、そして周囲に対する非公式な影響力を持っていることです。McKinseyの記事でも、生成AIの普及は熱心な初期利用者を起点に広がることが示されており、こうした層に最初の成功体験を作ってもらい、事例を共有することで組織全体への波及が期待できます。
スーパーユーザーの候補者はどのようにして見つけたらよいでしょうか？
既存のツール利用データを見る
社内にSaaS や社内アプリケーションの利用状況を可視化する仕組みがあれば、新しいツールの初期利用者が誰かはデータで分かります。たとえばSlackの新機能をいち早く使っている人、社内wikiを積極的に編集している人、既にAIツールのアカウントを持っている人などは、候補になりやすいです。
マネージャーに「誰が詳しいか」ではなく「誰に周りが聞きに行くか」を尋ねる
技術的に詳しい人とスーパーユーザーに向いている人は必ずしも一致しません。「ExcelやPowerPointで困ったときにみんなが頼る人は誰ですか」という聞き方をすると、業務の解像度と周囲への影響力を兼ね備えた人が浮かび上がることが多いです。
手を挙げてもらう
シンプルですが、「AIの社内活用に興味がある人、先行して試してみたい人はいませんか」と募集をかけると、試すことへの抵抗が低い人が自然に集まります。自発的に手を挙げた人はモチベーションの維持コストも低いという利点があります。
既存のコミュニティから探す
社内に勉強会、改善提案制度、ハッカソンなどの仕組みがあれば、そこに参加している人はスーパーユーザーの素養を持っている可能性が高いです。
実際には、これらを組み合わせて5〜10名程度を選定し、小さく始めるのが現実的だと思います。完璧な人選を目指すよりも、まず動き始めることの方が大切で、最初のサイクルを回す中で「この人が実はハブになっている」という発見が後から出てくることも多いです。
組織文化に合わせて「誰が旗を振るか」を選ぶ
チャンピオン（アンバサダー）と参加者方式
ほとんどの企業・組織において推奨される方式です。部門ごとにチャンピオン（アンバサダー）を置き、仲間を巻き込む形で活動を進めるモデルです。チャンピオン（アンバサダー）は、前述のスーパーユーザーの中から選定することもできます。
チャンピオン（アンバサダー）モデルには、いくつかの利点があります。まず、同じ業務をしている同僚からの「これ、こう使ったら楽だった」という声は、マネージャーからの「活用しなさい」という指示よりも実感を伴いやすく、ユースケースの翻訳コストが低くなります。また、マネージャーへの「報告」ではなく、チャンピオン（アンバサダー）がファシリテートする共有会や振り返りとして設計すれば、同じ情報収集でも社員の体験はまったく異なります。チーム気づきレポートに必要な情報は、共有会の記録から集めることも可能です。McKinseyの「Lilli Clubs」も、積極的な利用者がハブとなって周囲に広げていくという点で、このチャンピオン（アンバサダー）モデルに近い構造と言えます。
私の勤務先でも各部門から自薦他薦で選出されたアンバサダーが、社内AI普及活動の中核を担いました。
先に述べたIKEA効果（自分で見つけたものへの愛着）が普及の鍵になるならば、やらされ感はその対極に位置するものです。「誰が旗を振るか」だけでなく「何を必須にし、何を任意にするか」の設計も重要です。たとえば、AI体験ガイドを試すところまでは全員に体験してもらい、発見共有ノートは任意とする方法があります。その場合、チームの気づきに必要な情報は、チームの共有会での口頭共有やSlackへのメモから収集します。
ただし、チャンピオン（アンバサダー）に過度な負荷が集中しないよう、役割の範囲を明確にすることが重要です（後述の「ヘルプデスク化を避ける」と同じ考え方です）。参加者の疑問点、困りごとは、前述の「共有の場」での解決を推奨することも有効です。また、チャンピオン（アンバサダー）自身のモチベーション維持のために、活動の可視化、経営層からの認知、評価への反映といった仕組みも併せて設計しておくとよいでしょう。
理想的な分業としては、マネージャー（部門の管理職）は活動を承認し、時間とリソースを確保する役割に徹し、チャンピオン（アンバサダー）が仲間を巻き込み、実践を促す役割を担うという形が、多くの組織文化にフィットしやすいのではないかと思います。
トップダウン型（マネージャーとスタッフ方式）について
フラットな組織文化を重視する企業や、「上から降ってきたタスク」に対する心理的反発が強い現場ではチャンピオン方式が特に有効ですが、一方でコンプライアンス要件が強い業界や、全員参加が必要な制度変更を伴う場合など、マネージャー（部門の管理職）が主導するトップダウン型が適している組織もあります。その場合も「上司への提出」ではなく「チームへの共有」として位置づけることで、やらされ感を和らげることができます。
"ヘルプデスク化"を避ける
推進担当者にツール操作の質問が集中すると、普及活動が停滞します。操作に関する疑問は「まずAIに聞いてみてください」というルールを最初から設けて、自己解決の回路を作りましょう。また、参加者同士で助け合う「共有の場」も重要となります。
低リスク業務から始める
最初のユースケースは、要約、メールのドラフト作成、会議アジェンダの作成、FAQ草案の作成など、失敗しても影響の小さい業務から始めます。これにより心理的ハードルが下がり、成功体験が得られやすくなります。
落とし穴
チームの気づきの結果を「確定ロードマップ」と誤認する
チーム気づきレポートの出力はあくまで出発点であり、そのまま実行計画として使うものではありません。実際の定着には、共有会の開催、ベストプラクティスの展開、障壁の除去といったフォローアップが不可欠です。
たたき台を実行計画に変換するには、次の3ステップが有効です。
① 優先度とオーナーを書き込む
チャンピオン（アンバサダー）またはマネージャーがレポートを読み、各アクション候補に「優先度（高・中・低）」と「担当部門または担当者案」を書き込みます。これだけで「誰が何をするか」が明確になり、たたき台が動き出せる状態になります。
② 参加者に「声が活きた」とフィードバックする（次の共有会で）
チームの気づきから出てきたアクションを参加者にフィードバックし、「あなたの声がこういう形で活きました」と明示します。このフィードバックが次サイクルへの参加動機を生みます。情報を出しても何も変わらないと感じると、発見共有ノートの質は急速に下がります。
③ 自力では解決できない障壁をエスカレーションする
チーム内では解決できない障壁（ポリシー整備、ツールのアクセス権限、システム連携など）は、IT部門・法務・経営層へのエスカレーション議題として切り出します。このとき、チーム気づきレポートの「障壁トップ3」を添えるだけで、抽象的な「AIが使いにくい」という訴えよりも格段に意思決定者が動きやすくなります。
障壁のタイプによって、動くべき人と打ち手は異なります。以下の対応表が目安になります。
| 障壁タイプ | 主な担当 | 次のアクション例 |
|---|---|---|
| ポリシー・ルールが不明確 | 推進事務局・法務 | FAQ整備、社内ガイドライン更新 |
| ツール・データへのアクセス権がない | IT部門 | 権限申請フローの整備、申請先の明示 |
| 心理的抵抗（失敗・責任への不安） | チャンピオン・マネージャー | 成功事例の共有、Human-in-the-loop原則の再周知 |
| ユースケースが見えない | 推進担当者 | AI体験ガイドの具体化・ロール別改訂 |
| リーダーシップ・意思決定の不作為 | 経営層 | 経営議題へのエスカレーション、優先度の明示的な承認 |
最後の「リーダーシップ・意思決定の不作為」は見落とされがちですが、McKinseyの2025年調査では、AI普及の最大の障壁は現場社員の抵抗ではなく、リーダーシップの惰性（戦略・投資・リスク管理への経営層のコミットメント不足）であることが示されています。現場から「ポリシーが決まらない」「承認が降りない」という声が繰り返し出るようであれば、それは経営層が動くべきシグナルです。チーム気づきレポートはこれを可視化し、経営議題に乗せるための根拠資料としても機能します。
1回で終わらせてしまう
AI体験 → 発見の共有 → チームの気づきを一度やって「完了」としてしまうケースも落とし穴です。AIHRが推奨するボトムアップ型のAI普及アプローチは、柔軟で継続的な反復サイクルを前提としています（Frontline AI Adoption in HR）。チームの気づきの結果から見えた課題や新たな業務領域を次のAI体験ガイドに反映し、サイクルを回し続けることで、普及の幅と深さが段階的に広がっていきます。
ただし、繰り返せばよいというものではありません。前サイクルの学びを組み込まない繰り返しは、参加者にとって「また同じことをやらされる」という印象になります。BCGの調査によれば、企業全体で74%がAI施策から具体的な価値を得られていない原因の一つに、パイロットが単発で終わり組織知識として蓄積されないことが挙げられています。「継続」ではなく「進化するサイクル」を設計することが重要です。
次サイクルへの反映として、最低限この3点を実施することを推奨します。
- 未解決の障壁を次の質問に組み込む。 2周目のAI体験ガイドの冒頭に「前回、AIを使う上で困ったことはその後どうなりましたか？」を追加します。これにより障壁の解消状況を確認しながら次の対話に入れます。
- 有望ユースケースを「先行事例」として紹介する。 1周目で見つかった上位1〜2件のユースケースを次サイクルの参加者に共有します。「すでに試した人がいる」という事実が、ブランクキャンバス問題を解消する最も手軽な手段です。IKEA効果は連鎖します。先行事例を見た参加者は「自分版」を探す意欲が高まります。
- 参加率が低かったロールを優先招待する。 前サイクルで発見共有ノートが集まりにくかった職種や部署を、次サイクルではそのロール向けに調整したAI体験ガイドと合わせて優先招待します。「全員に同じものを配る」から「届いていない人に届ける」へと活動の精度が上がります。
7. 成果指標の段階設計
効果を測定し、活動を持続させるためには、段階的なKPIの設定が有効です。
第1段階：採用率を見る
まずは「使い始めたかどうか」を確認します。AI体験ガイドの実行者数、発見共有ノートの共有率、AIツールの週間アクティブユーザー数などが指標になります。ただし、これらの指標は運営事務局が次のアクションを判断するための診断材料として使うものであり、現場のマネージャーやチャンピオン（アンバサダー）に数値目標として課すと、体験の質を犠牲にした「形だけの参加」を招くリスクがあります。
これらの指標は、専用のダッシュボードを構築しなくても、AI体験のサイクルを繰り返す中である程度把握できます。2周目以降のAI体験ガイドに「前回以降、実際にAIを業務で使ったか」「使った場合はどんな場面で使ったか」「使わなかった場合は何が障壁だったか」といった振り返りの質問を加えれば、サイクル間の利用状況を定性的に確認できます。AIツール自体の利用ログが取得できる環境であればそれも活用しますが、ログがなくても活動を止める必要はありません。
第2段階：行動変容を見る
次に、AIが実際の業務フローに組み込まれているかを確認します。ワークフローの中にAIを使うステップが含まれている割合や、繰り返し利用の頻度が指標になります。
第2段階についても同様に、サイクルの中で確認できます。「AIを使うことが習慣になっている作業はあるか」「一度試したが元のやり方に戻したものはあるか、その理由は何か」といった質問を加えることで、定着の度合いと定着しなかった要因の両方が見えてきます。
第3段階（任意）：成果を見る
活動が成熟してきた段階では、業務のサイクルタイム削減、成果物の品質向上、社員のeNPS（Employee Net Promoter Score。自社の職場環境を他者に薦めたいかを数値化した従業員エンゲージメント指標）といったビジネスインパクトの指標で効果を測ることも考えられます。ただし、AI活用単独の貢献度を他の要因から切り分けるのは容易ではなく、厳密な測定には相応のコストがかかります。まずは第1段階と第2段階をサイクルの中で確認しながら活動を回し、第3段階の測定は組織の準備が整った時点で検討するという順序が良いのではないでしょうか。
また、いきなり第3段階の成果を求めると、「まだ効果が出ていない」「やめよう」という判断になりがちです。段階を踏んで「まず使い始めた人が増えている」「次に行動が変わり始めている」と確認できれば、成果が出るまでの間も活動を継続する根拠とモチベーションになります。
8. 導入時に用意するもの
テンプレ3点セット
このフレームワークを始めるために最低限必要なのは、以下の3つです。
1つ目は 参加者への案内メール です。目的、進め方、発見共有ノートの形式、ポリシーリンク、Q&Aチャンネルの案内を含めます。チャンピオン（アンバサダー）から仲間への呼びかけという形にすると、やらされ感が薄れ参加率が上がりやすくなります。
2つ目は AI体験ガイド そのものです。社員がAIにそのまま貼り付けるプロンプトで、本記事の第4章で述べた設計ポイントに沿って作成します。
3つ目は チーム気づきレポート生成プロンプト です。チャンピオン（アンバサダー）またはマネージャーが発見共有ノートをまとめてAIに渡し、部門レベルのアクションプランを生成するためのプロンプトです。
併せて明記しておくべきこと
テンプレ3点セットに加えて、入力データのルール（機密情報や個人情報の取り扱い基準）と、確認義務（AI出力をそのまま共有しないこと）を短く明記しておくと、運用が安定します。
長々とした利用ガイドを用意する必要はありません。むしろ、短く明確なルールの方が読まれますし、守られます。
9. インセンティブとの連携
ここまでの仕組みをさらに効果的にするには、評価制度との連携も検討に値します。
Wharton Business Schoolの記事（How Can Companies Incentivize AI Adoption?）では、AI関連の行動を評価や報酬に紐づけることの効果が指摘されています。たとえば、WalmartやPfizerはAI関連KPIに連動したボーナス係数を導入し、AmazonやJP Morganは昇進機会をAI活用実績に連動させているとのことです。
すべての企業がここまで踏み込む必要があるというわけではありません。少なくとも「AI体験ガイドに取り組んだこと」「発見共有ノートを仲間と共有したこと」を目標設定や1on1の話題として組み込むだけでも、参加率に大きな差が出るでしょう。
マネージャーの「関心」そのものがインセンティブになる
金銭・評価制度と並んで、見落とされがちながら実は強力なインセンティブが、マネージャーが部下のAI活用の取り組みに関心を持つことそのものです。
チャンピオン（アンバサダー）方式を採用する場合でも、マネージャーがAI活用やスタッフの貢献に無関心であれば参加者の意欲が長続きしないことは明らかですね。
この点は、1920年代から1930年代にかけてElton Mayoらが行ったホーソン工場での一連の研究から導かれた「ホーソン効果（Hawthorne Effect）」からも説明することができます。これは、「従業員が“注目され、期待されている”と感じると、意欲や生産性が高まりやすい心理効果」と理解されているものです。
この知見はAI普及活動にもそのまま応用できます。マネージャーが「どんなAI活用を試してみたの？」「使ってみてどうだった？」と1on1や日常の会話の中で問いかけるだけでも、社員は自分の取り組みがきちんと見られ、評価の対象になっていると感じやすくなり、次の一歩への意欲が高まるのではないでしょうか。
また、Herzbergの二要因理論（Two-Factor Theory）でも、「承認（recognition）」は給与などとは区別された動機づけ要因（motivator）の1つとして位置づけられています。承認は、「仕事が認められている」「貢献がきちんと評価されている」という感覚を通じて、仕事満足や内発的動機を高める要因だとされています。
これは、承認が本人だけでなく、周囲の人にも波及する「スピルオーバー効果」を持ちうることを示唆しており、マネージャーがスタッフのAI活用に関心を示す行動が、チーム全体の参加意欲にも良い影響を与える可能性を裏づけるものです。
おわりに
AI駆動AI普及活動 with Human-in-the-loopは、「AIの使い方を教える」のではなく「AIで普及活動そのものを駆動する」アプローチです。
AI体験ガイドでまず触ってもらい、発見共有ノートでユースケースと障壁を言語化し、チーム気づきレポートで組織の打ち手に統合する。このシンプルな3ステップで、最初のAI体験、ユースケース発掘、障壁の可視化、組織レベルの計画策定が一度に動き始めます。チャンピオン（アンバサダー）が仲間を巻き込む形で進めることで、やらされ感ではなく自発的な参加の文化が育ちやすくなります。
もちろん、1回のサイクルですべてが解決するわけではありません。しかし、「研修を企画して、講師を手配して、日程を調整して、参加者を集めて…」という従来の普及アプローチに比べれば、はるかに低コストで、はるかに実務に根ざした形で、最初の一歩を踏み出せるはずです。
まずはAI体験ガイドを1つ作って、チーム内の数名に試してもらうところから始めてみてはいかがでしょうか。
本記事は提言の段階ですが、実際に試された方がいればぜひフィードバックをいただけると嬉しいです。
また、活動を重ねる中で、チームの気づきの使い方が「何分節約できたか」の集計から、「どの業務プロセスそのものを変えられるか」という問いへと自然に発展していく組織もあるかもしれません。PwC Japanの2025年の調査では、成果を上げている企業に共通するのは、AIを効率化ツールとしてではなく業務構造の変革手段として位置づけている点だと報告されています。本フレームワークがそこまでを直接の目的としているわけではありませんが、サイクルを回す中で「次はこの業務フロー自体を見直せないか」という問いが現場から出てくるようになれば、それはこの活動が一段深まったサインと言えるでしょう。
なお、この仕組みで得られるインサイトはチャット活用にとどまらず、将来のAIエージェント導入の検討材料としても活用できます。この発展的な展望については、Appendix をご参照ください。
Appendix
ここからはAIエージェントという少し技術的なテーマに踏み込みます。「まずはチャット活用の普及から」という段階の方は、本編だけで十分ですので、読み飛ばしていただけます。
チャットの先にあるAIエージェントへつなげるには
ここまで述べてきたAI駆動AI普及活動は、ChatGPTやClaudeのようなチャット型AIを社員に使い始めてもらうことを主眼に設計しています。しかし、この仕組みで得られるアウトプットは、チャット活用の普及だけにとどまらない可能性を持っています。それが、業務の自動化を担う AIエージェント への接続です。
ここで区別すべきことがあります。エージェントの 開発・導入 をチャット普及と同時に走らせるのは、現場の混乱やガバナンスの不備を招くリスクがあり、慎重であるべきです。一方で、将来のエージェント化に向けた インサイトの収集 は、チャット普及活動と並行して行うべきです。後から同じヒアリングをやり直すのは非効率ですし、チャット活用のAI体験という文脈があるからこそ、社員から自然に業務プロセスの情報を引き出せるからです。本章では、この「収集の並行」を最小限の変更で実現する方法について述べます。
チャットとエージェントは何が違うのか
チャット型AIの本質は「相談」です。人間が問いかけ、AIが応答し、人間がその出力を見て判断する。主導権は常に人間の側にあります。一方、AIエージェントの本質は「実行」です。何らかのトリガー（メール受信、チケット起票、定期スケジュールなど）に応じてAIが自律的に処理を行い、システムにデータを書き戻す。主導権の一部がAIに移るという点で、チャットとは質的に異なります。
この違いは、ユースケースを収集する際に「何を聞くか」にも影響します。チャット向けのAI体験ガイドでは「どんな業務で困っていますか」「どんな成果物を作っていますか」といった質問で十分ですが、エージェントの可能性を探るには、もう少し踏み込んだ情報が必要になります。
発見共有ノートとチームの気づきは、エージェントのユースケース収集にも転用できる
本記事でご紹介した「発見の共有 → チームの気づき」の構造は、エージェントのユースケース候補を集め、分類し、優先順位をつけるための器としても機能します。
具体的には、AI体験ガイドに以下のような質問を2〜3個追加するだけで、チャット向けの情報収集とエージェント向けの情報収集を同時に行うことができます。
- 「この作業はどのシステム（ツール）で始まり、どこで完了しますか？」
- 「最終的に何かを登録・更新・送信する作業は含まれていますか？」
- 「途中で人の判断や承認が必要なポイントはどこですか？」
これらの質問は、システム設計の専門用語を使わずに、エージェント化に必要な最小限の情報（入力元、出力先、判断ポイント）を引き出すことを意図しています。ただし、現場の社員にとっては「トリガー」や「入出力」といった概念に馴染みがない場合も多いため、質問の言い回しは平易に保つ必要があります。
チーム気づきレポートの生成プロンプトの側にも、ユースケースの分類軸を一つ追加します。たとえば、「(A) チャット支援向き」「(B) ワークフロー自動化向き」「(C) エージェント化有望（要承認フロー）」「(D) 不適（リスク高）」の4区分で整理するだけでも、IT部門が次のアクションを判断するための十分な材料になります。
こうすることで、普及活動のアウトプットが「啓発の記録」にとどまらず、エージェント開発のバックログ（候補リスト） として機能するようになります。
IT部門がテンプレートを作り、現場が差分を埋める分業モデル
収集されたユースケースをエージェントとして実装する段階では、現場の社員にゼロから開発させるのは現実的ではありません。認証・権限管理、接続先システムのコネクタ設定、監査ログの取得、個人情報の取り扱い、エラー時のフォールバック処理など、安全に動かすための基盤部分はIT部門やCoE（Center of Excellence）が整備し、現場のパワーユーザーが業務固有の差分（文言、分類ルール、参照するナレッジ、承認フロー、通知先など）を埋めるという分業が望ましい形です。
この「安全な土台をITが提供し、現場が最後の部分を埋める」という構図は、本記事の「コピペ一発で始まる」思想と通じるものがあります。AI体験ガイドが「編集させない、考えさせない」設計であったように、エージェントのテンプレートも「基盤は触らせない、業務ロジックだけ入れてもらう」設計にすることで、開始の摩擦を下げられます。
ただし、ここにはとても重要な留意点があります。 現時点では、この「差分を埋めるだけで動く」体験を本当に実現できるかどうかは、エージェント開発プラットフォームの成熟度に大きく依存します。主要なエージェントプラットフォームはいずれもこの方向を目指していると思いますが、プラットフォーム自体がまだ発展途上にあるのが実情です。ノーコードで業務差分だけ入れれば動く環境が整っていれば理想的ですが、結局コネクタの設定やエラーハンドリングでIT部門の継続的な支援が必要になる場合も多いのが現実です。「現場が最後の部分を埋める」と言ったとき、その部分の難易度は採用するプラットフォームの現在の能力によって大きく変わります。一方で、次の節で触れますがエージェント固有のリスクに備える＝ガバナンスが極めて重要です。
したがって、エージェントのテンプレート化を計画する際には、自社が採用するプラットフォームの現在の能力を冷静に評価し、「現場に渡せる段階にあるか」「まだIT主導で作り込む段階か」を見極めることが重要です。プラットフォームの進化は速いため、半年後には状況が変わっている可能性もありますが、「いずれ簡単になるはずだ」という期待で先走るのは避けたほうがよいでしょう。
エージェント固有のリスクに備える
エージェントはチャットよりもリスクが高い。この点は明確に認識しておく必要があります。チャットでは人間が出力を見て判断しますが、エージェントはシステムに対して書き込み・送信・更新といったアクションを実行します。誤動作の影響が「間違った文章を読んだ」ではなく「間違ったデータが顧客に送信された」「誤った金額で処理が走った」になり得るという点で、リスクの質が異なります。
そのため、エージェント化を進める際には、以下の観点を運用設計に組み込む必要があります。
第一に、段階的な自動化 です。いきなり完全自動化を目指すのではなく、「まずAIがドラフトを作り人間が確認して実行する」段階から始め、十分な実績が蓄積された後に「人間は例外時のみ介入する」段階に移行するという設計が有効です。これは本記事で述べたHuman-in-the-loopの思想をエージェント領域に延長したものと言えます。
第二に、権限設計 です。エージェントが「誰の権限で」アクションを実行するのかを明確にする必要があります。代理実行の範囲、職務分掌との整合性、監査証跡の確保など、チャット活用では不要だったガバナンスの論点が加わります。
第三に、多層防御によるデータ保護 です。エージェントがデータを読み書きする以上、AIモデルへの入出力に対するガードレール（不適切なコンテンツの検出、プロンプトインジェクションの防御、個人情報の自動検出と除去など）はもちろん必要ですが、それだけでは十分ではありません。「誰が・どのデータに・どこまでアクセスできるか」を複数のレイヤーで制御する必要があります。アプリケーション層でのアクセス制御（エージェントに与える権限の範囲、API経由で許可する操作の種類、金額や件数に応じた承認フローの挿入など）、そして見落とされがちなのが データベース層での保護 です。縦深防御（defense in depth）の考え方に立てば、データベースは防御の最後の砦です。仮にアプリケーション層のアクセス制御をエージェントが迂回し、AIモデルへの入出力に対するガードレールも突破したとしても、データベース側で行レベル・列レベルのアクセス制御、機密データの動的マスキング、監査ログの自動取得が実装されていれば、被害を最小限に食い止めることができます。エージェントの普及が進むほど、データにアクセスする経路は多様化します。だからこそ、個々のアプリケーションやエージェントの実装に依存しない、データそのものに近い場所での保護が重要になるのです。
第四に、評価指標の拡張 です。チャット活用では利用率や行動変容を見れば十分ですが、エージェントではそれに加えて、エラー率、手戻りの発生頻度、例外処理に要する時間、監査指摘の有無といった指標も必要になります。本記事の第7章で述べた段階的KPI設計の考え方はエージェントにおいても有効ですが、第3段階（成果を見る）の中身がより具体的かつシビアになるということです。
AIエージェントへ向けてのインサイト収集は今から
エージェントの実装・展開は、チャット活用が一定程度定着し、社員がAIとの協働に慣れた段階で進めることが多いでしょう。しかし、その日が来たときに「何から手をつければいいか分からない」という、ブランクキャンバス問題の再来を起こす必要はありません。
本記事が提案するAI駆動AI普及活動は、まずチャット型AIで最初の一歩を踏み出させ、ユースケースと障壁を可視化するところに価値があります。その過程で、AI体験ガイドに数問を加え、チームの気づきに分類軸を一つ足すだけで、将来のエージェント化に向けた情報も同時に蓄積できる。この「チャット普及を主軸にしながら、最小変更で将来への布石を打つ」という考え方が、現時点で最も現実的なアプローチではないでしょうか。
チャットの普及で得られた信頼と実績の上に、段階的にエージェントの領域を広げていく。その最初の種は、AI体験ガイドの中にすでに蒔くことができるのです。