AI活用の成功事例を全社展開する｜部門ナレッジを再現する仕組み

成果だけが共有され、背景が共有されていない

社内共有でよくあるのは、「AIを使って議事録作成時間を短縮できました」「問い合わせ対応が早くなりました」という成果だけが伝えられるケースです。

もちろん成果は重要です。しかし、別部門の担当者が本当に知りたいのは、その数字そのものだけではありません。

知りたいのは、次のような具体的な情報です。

• どの業務にAIを使ったのか
• どのような課題があったのか
• 何を入力したのか
• どのようなプロンプトを使ったのか
• どこまでAIに任せ、どこから人が確認したのか
• どの条件なら再現できそうか
• 逆に、どの条件ではうまくいかなかったのか

成果だけでは、他部門は真似できません。背景、手順、判断基準まで共有されて初めて、ケーススタディ共有として意味を持ちます。

筆者の経験では、AI活用の横展開に苦戦する企業ほど、「結果の共有」は丁寧でも、「過程の共有」が弱い傾向があります。成果発表のスライドは整っています。しかし、実際に手を動かす人が知りたい泥臭い部分が抜けています。

どの入力データではうまくいかなかったのか。AIの出力をどこまで信じてよいと判断したのか。最初のプロンプトから何回修正したのか。そうした試行錯誤こそ、社内に残すべきナレッジです。

「担当者の工夫」で終わってしまう

AI活用は、最初のうちは個人の工夫として始まりやすいものです。

• この聞き方をしたら、いい出力が返ってきました
• この資料を先に読み込ませると精度が上がりました
• 議事録は、このフォーマットで頼むと使いやすいです

こうした現場の発見は、非常に価値があります。しかし、そのまま担当者の頭の中や個人チャットの履歴に残っているだけでは、組織の資産にはなりません。

担当者が異動したり、別の業務で忙しくなったりすると、せっかくの工夫が再利用されなくなります。AI活用を全社に広げるには、個人の工夫を社内ナレッジ共有の仕組みに載せ替える必要があります。

ここで重要なのは、個人の工夫を否定しないことです。むしろ、AI活用は最初に手を動かした人の工夫から始まります。筆者自身も、プロダクト開発や営業支援の現場で、最初の改善はいつも一人の担当者の「ちょっと試してみました」から生まれると感じています。

ただ、その工夫を個人の中に閉じ込めたままにしない。そこから先が、組織としてのAI活用です。

部門ごとの業務条件が違い、そのまま使えない

成功事例の横展開が難しいもう一つの理由は、部門ごとに業務条件が違うことです。

営業部でうまくいった商談メモ要約のプロンプトを、そのまま人事部の面談記録に使えるとは限りません。経理部の問い合わせ対応で使ったFAQ整理の方法を、マーケティング部のコンテンツ制作にそのまま流用できるわけでもありません。

つまり、AI成功事例の横展開で重要なのは、「同じものをコピーすること」ではありません。

重要なのは、成功事例の構造を抜き出し、自部門の業務に合わせて再設計できる状態にすることです。そのためには、単なる成功談ではなく、再現性のあるナレッジとして整理する必要があります。

筆者は、AI活用の横展開を「レシピ化」に近いものだと考えています。完成した料理の写真だけを見せられても、同じものは作れません。材料、分量、手順、火加減、失敗しやすいポイントが必要です。AI活用の成功事例も同じです。

何に困っていたのか

最初に整理すべきなのは、AIを使う前の課題です。

たとえば、次のように書きます。

• 議事録作成に時間がかかっていた
• 問い合わせ対応の品質が担当者によってばらついていた
• 提案書の初稿作成が属人化していた
• 社内研修の教材化に手間がかかっていた

ここで大切なのは、「AIを使ったこと」から説明しないことです。AI活用事例の主役はAIではなく、業務課題です。

どのような業務に、どのような非効率や品質のばらつきがあったのか。その課題を明確にすることで、別部門の担当者も「自分たちの業務にも似た問題がある」と気づきやすくなります。

筆者が現場でヒアリングするときも、最初から「どのAIを使いましたか」とは聞きません。まず聞くのは、「その前に、何が面倒でしたか」「誰が困っていましたか」「どの作業が後回しになっていましたか」という問いです。AIの話は、その後で十分です。

どの業務にAIを使ったのか

次に、対象業務を明確にします。

たとえば「問い合わせ対応にAIを使った」だけでは、範囲が広すぎます。より具体的には、次のように分解できます。

• 問い合わせ内容の分類
• 過去FAQからの回答案作成
• 回答文のトーン調整
• 担当部署へのエスカレーション判断
• 月次の問い合わせ傾向分析

同じ問い合わせ対応でも、AIを使えるポイントは複数あります。どの作業にAIを使ったのかを明確にすることで、他部門は自分たちの業務フローに当てはめやすくなります。

「問い合わせ対応にAIを使う」と言われると、大きな変化に見えます。しかし、実際には「問い合わせを5分類する」「過去のFAQをもとに一次回答案を作る」「文面を丁寧に整える」といった小さな作業単位に分解できます。この粒度まで落とすことが、横展開の第一歩です。

何を入力したのか

AI活用の成果は、入力する情報に大きく左右されます。同じプロンプトを使っても、入力する資料や前提情報が違えば、出力の品質は変わります。

そのため、事例共有では、次のような入力情報も必ず記録します。

• 会議メモ
• 音声文字起こし
• 社内マニュアル
• FAQ
• 過去の提案書
• 顧客ヒアリングメモ
• 研修動画
• 業務ルール
• 社内規程

利用ツールを問わず、「AIチャットに直接入力したのか」「要約機能にファイルを入れたのか」「社内ナレッジや学習データを参照したのか」まで整理しておくと、再現しやすくなります。

Kanataのように、業務で繰り返し使うプロンプトや参照資料をプロジェクト単位で管理できるツールを使う場合は、議事録テンプレート、問い合わせ回答のルール、過去の提案書、社内FAQなどを整理しておくと、毎回ゼロから入力する手間を減らせます。

筆者は、AIの精度を上げるうえで「よいプロンプト」と同じくらい「よい入力データ」が重要だと考えています。どれだけ巧みに指示を書いても、前提情報が足りなければ、出力は一般論になりやすいからです。

どのプロンプトを使ったのか

AI活用の再現性を高めるうえで、プロンプトは重要なナレッジです。プロンプトとは、AIに対して与える指示文のことです。

ただし、プロンプトだけを共有しても十分ではありません。同じプロンプトでも、前提情報、入力データ、出力の確認方法がそろっていなければ、同じ成果は出にくいからです。

そのため、プロンプトは単体で保存するのではなく、次の情報とセットで共有します。

• 使った場面
• 入力した情報
• 期待した出力形式
• 実際に得られた出力
• 人が修正した箇所
• 注意すべき表現
• 他部門で使う場合の変更ポイント

プロンプト管理機能やナレッジ管理ツールに保存する場合も、単に指示文だけを置くのではなく、「どの業務で使うものか」「どの資料と一緒に使うものか」を説明文に残しておくと、後から使いやすくなります。

プロンプトは、単なる文章ではありません。業務の考え方が圧縮されたものです。だからこそ、使い方の文脈まで残す必要があります。

どの成果指標を見たのか

AI活用の成功事例では、できるだけ成果指標を明確にします。

指標には、たとえば次のようなものがあります。

• 作業時間
• 処理件数
• 初回回答までの時間
• 手戻り件数
• レビュー回数
• 担当者の負荷感
• 社内問い合わせ数
• 研修コンテンツ作成数
• 利用者アンケートの評価

数値を出す場合は、期間、対象件数、比較条件をセットにします。

たとえば、「議事録作成が早くなった」ではなく、「2026年1月から3月までの営業定例12回を対象に比較したところ、議事録作成にかかる平均時間が1回あたり45分から15分に短縮された」と書きます。[要確認]

数値が取れない場合は、定性的な変化でも構いません。

たとえば、「会議後に議事録作成の担当者を決める必要がなくなった」「新人が過去事例を探す時間が減った」「社内勉強会で他部門から質問が出るようになった」といった行動変化も、重要な成果です。

筆者は、AI活用の初期段階では、定量指標と定性変化の両方を見るようにしています。なぜなら、初期の変化は数字に出る前に、会話や行動に現れることが多いからです。

どこで失敗したのか

成功事例を横展開するとき、意外に重要なのが失敗情報です。

うまくいった部分だけを共有すると、別部門が同じ落とし穴にはまる可能性があります。

たとえば、次のような情報です。

• 入力データが古く、回答が現状と合わなかった
• プロンプトが抽象的で、出力が一般論になった
• 機密情報の扱いに不安があり、利用範囲を限定した
• AIの出力をそのまま使い、後から修正が必要になった
• 部門独自の用語が多く、事前に用語集が必要だった

こうした失敗点は、AI活用の価値を下げるものではありません。むしろ、再現性を高めるための重要なナレッジです。

ベストプラクティス AIをつくるには、「成功した方法」だけでなく、「成功しなかった条件」も一緒に残す必要があります。

事例名

まず、事例名を具体的にします。

避けたい例は、「営業部のAI活用事例」です。これでは何に使ったのか分かりません。

より具体的には、「商談メモから次回アクションを整理するAI要約の活用」のようにします。どの業務で、何を改善したのかが伝わります。

事例名には、できるだけ対象業務と成果の方向性を入れます。

筆者は、事例名をつけるときに「部署名」ではなく「業務の変化」が見える名前にすることを勧めています。なぜなら、他部門の人は「営業部の話」と書かれた瞬間に、自分には関係ないと思ってしまうことがあるからです。

「商談メモの要約」ではなく、「会話記録から次回アクションを抽出する」と書けば、カスタマーサクセス、人事、開発部門の人も自分の業務に置き換えやすくなります。

対象部門と関係者

次に、対象部門と関係者を整理します。

誰が使った事例なのか、誰がレビューしたのか、どの部門が関わったのかを書きます。

たとえば、営業担当者だけでなく、営業企画、マネージャー、CRM管理者が関わっていた場合は、その関係性も残します。

AI活用は、単独の作業に見えても、実際には複数の関係者に影響することが多いです。関係者を明記しておくことで、他部門が展開計画を作るときの参考になります。

特に、承認者やレビュー担当者を明確にしておくことは重要です。AIの出力を誰が確認したのかが曖昧だと、横展開したときに品質や責任の所在が不明確になります。

導入前の課題

導入前の課題は、できるだけ現場の言葉で書きます。

「効率が悪かった」だけではなく、「商談後にメモをCRMへ転記するまで平均2営業日かかり、次回提案の準備が遅れていた」のように、業務上の困りごととして書くことが大切です。[要確認]

可能であれば、現場の発言も入れます。

商談が終わった直後は覚えているのに、翌日になると細かいニュアンスを忘れてしまう

こうした言葉があると、別部門の読者も状況を想像しやすくなります。

筆者は、AI活用の事例を作るとき、現場の一言を拾うようにしています。数字は説得力を持ちますが、言葉は読者を引き込みます。社内ナレッジであっても、読む人は人間です。現場の声があるだけで、事例は立体的になります。

使用したAI機能

どのAI機能を使ったのかを明記します。

たとえば、次のように整理できます。

どの機能を、どの順番で使ったのかまで書いておくと、他部門が実践しやすくなります。

たとえば、会議録音をAI要約に入れ、その要約結果をAIチャットで「部門別のアクション」に分解し、確定したプロンプトを共有ライブラリに保存する。こうした流れまで見えると、単なるツール紹介ではなく、業務プロセスとして再現しやすくなります。

入力データとプロンプト

AIに何を渡したのか、どのような指示を出したのかを残します。

ただし、顧客情報や個人情報、機密情報が含まれる場合は、必ずマスキングします。AIの業務利用では、情報の入力範囲、出力の確認、責任所在を明確にすることが重要です。日本でも、事業者向けのAIガイドラインでは、AIの安全安心な活用に向けた体制整備やリスク管理の重要性が整理されています。

事例共有用には、実際のプロンプトをそのまま載せるのではなく、再利用できる汎用版に整えるとよいです。

あなたは営業マネージャーを支援するアシスタントです。
以下の商談メモをもとに、次回アクションを整理してください。

# 出力形式
1. 商談サマリー
2. 顧客の課題
3. 次回までに自社が準備すること
4. 顧客に確認すべき質問
5. CRM登録用の120字要約

# 注意点
- 不明な情報は推測せず「要確認」と書く
- 顧客の発言と自社の解釈を分ける

このように残しておくと、他部門は自分たちの業務に合わせて修正できます。

Kanataのように、プロンプトをチーム内で再利用できる形で保存できるツールを使う場合は、「商談メモ要約_v1」「顧客定例サマリー_v2」のように名前をつけておくと、どのプロンプトが最新なのかも分かりやすくなります。

導入後の変化

導入後の変化は、数値と行動の両方で整理します。

数値だけでは、現場の実感が伝わりにくいことがあります。一方で、感想だけでは、経営層や他部門が効果を判断しにくくなります。

そのため、次のように組み合わせます。

• 作業時間がどう変わったか
• 処理件数がどう変わったか
• 手戻りがどう変わったか
• 担当者の行動がどう変わったか
• 関係者の会話がどう変わったか

たとえば、「議事録作成時間が短縮された」だけでなく、「会議後の15分を次回アクションの確認に使えるようになった」と書くと、業務上の意味が伝わりやすくなります。

筆者は、数字を見るときに「それで何ができるようになったのか」まで確認します。10分短縮されたこと自体より、その10分でマネージャーが部下と話せるようになったのか、顧客への返信が早くなったのか、次の提案準備に回せたのか。その変化まで書くと、事例の価値が伝わります。

再利用時の注意点

横展開では、注意点が重要です。

成功事例をそのまま別部門に持ち込むと、前提条件の違いでうまくいかないことがあります。

たとえば、営業部の商談メモ要約を人事部の面談記録に応用する場合、次のような違いがあります。

• 扱う情報の機微性
• 発言者の立場
• 記録の保存ルール
• 本人確認や同意の必要性
• 出力を誰が閲覧できるか

こうした注意点を事例フォーマットに含めておくことで、単なるコピーではなく、安全で現実的な横展開につながります。

AI活用では、「便利だから広げる」だけでは不十分です。便利なものほど、使い方を間違えたときの影響も広がります。筆者は、横展開の前に必ず「この事例を別部門で使うときに、何が危ないか」を確認するようにしています。

次に展開できそうな部門

最後に、次に展開できそうな部門や業務を記録します。

たとえば、営業部の商談メモ要約は、カスタマーサクセスの顧客定例、人事の面談記録、開発部門の仕様検討メモにも応用できるかもしれません。

この「次に使えそうな場所」を書いておくことで、成功事例が次の展開計画につながりやすくなります。

AI事例の横展開は、偶然に任せるものではありません。事例の最後に「次に試すならどこか」を書いておくだけで、社内の会話が次のアクションに向かいやすくなります。

発表者は成果よりプロセスを話す

発表者には、成果だけでなく、プロセスを話してもらいます。

たとえば、次のような流れです。

1. 導入前に困っていたこと
2. 最初に試したこと
3. うまくいかなかったこと
4. プロンプトや入力データをどう変えたか
5. 人が確認するルールをどう決めたか
6. 現在の運用に落ち着いた理由
7. 他部門が真似するなら注意すべきこと

この流れで話すと、聞き手は自分の業務に置き換えやすくなります。

特に重要なのは、うまくいかなかったことです。成功までの試行錯誤が共有されることで、別部門は同じ失敗を避けられます。

最初はAIの出力をそのまま議事録に貼ろうとしていました。でも、発言者名の誤りが何度かあったので、今は決定事項とTODOだけをAIに整理させ、人が最後に確認しています

こうした話は、派手ではありません。しかし、横展開には役立ちます。現場の人が本当に知りたいのは、こういう運用の落としどころです。

聞き手は「自部門ならどう使うか」を考える

共有会では、聞くだけで終わらせないことが大切です。

発表後に、部門ごとの小さなワークを入れると効果的です。

たとえば、次のような問いを用意します。

• 自部門で似た業務はどれか
• 同じプロンプトを使えそうな場面はあるか
• 追加で必要な社内資料は何か
• 展開する場合、誰の確認が必要か
• 1か月以内に小さく試せる業務は何か

この問いを使うと、ケーススタディ共有が単なる情報共有ではなく、展開計画の入口になります。

筆者が支援したプロジェクトでも、共有会の最後に「明日試すなら何をしますか」と聞くと、参加者のメモの取り方が変わりました。聞き手ではなく、次の実践者になるからです。

共有会の内容は必ずナレッジ化する

社内勉強会でよい発言が出ても、その場限りで消えてしまうと意味がありません。

共有会の内容は、必ず後から見返せる形にします。

たとえば、社内勉強会の録音やメモをAI要約で整理し、次のような形式で保存します。

• 発表事例の要約
• 参加者から出た質問
• 他部門への応用アイデア
• 展開時の注意点
• 次回までのアクション

さらに、確定したプロンプトや事例フォーマットは、社内の共有ライブラリやナレッジ管理ツールに保存します。

これにより、社内勉強会が一度きりのイベントではなく、社内ナレッジ共有の蓄積になります。

社内イベントは、開催しただけでは資産になりません。記録され、整理され、検索でき、再利用されて初めて資産になります。ここを仕組みにできるかどうかで、AI活用の定着度は大きく変わります。

SlackやTeamsに共有チャンネルを作る

まずは、SlackやTeamsなどにAI活用専用のチャンネルを作ります。

チャンネル名は、分かりやすくすることが大切です。

たとえば、次のような名前です。

• #ai活用共有
• #生成aiナレッジ
• #ai事例共有
• #kanata活用コミュニティ

このチャンネルでは、完璧な成功事例だけを投稿対象にしないことが重要です。むしろ、次のような小さな投稿を歓迎します。

• 今日使って便利だったプロンプト
• うまくいかなかったAI出力
• 他部門に聞きたいこと
• 共有したい注意点
• 共有ライブラリに登録したプロンプト
• 社内勉強会で扱ってほしいテーマ

投稿のハードルを下げることで、現場のナレッジが集まりやすくなります。

「完璧な事例だけ投稿してください」と言うと、ほとんどの人は黙ってしまいます。逆に、「ちょっと便利だった使い方でも歓迎です」と伝えると、共有が始まります。AI活用コミュニティでは、この心理的なハードルを下げることが大切です。

投稿テンプレートを用意する

コミュニティを活性化するには、投稿テンプレートが有効です。

テンプレートがないと、何を書けばよいか分からず、投稿が止まりやすくなります。

たとえば、次のようなテンプレートを用意します。

【使った業務】
例：営業定例の議事録作成

【困っていたこと】
例：会議後の議事録作成に毎回30分以上かかっていた

【使ったAI機能】
例：AI要約

【入力したもの】
例：会議メモ、録音の文字起こし

【使ったプロンプト】
例：決定事項、TODO、論点を分けて整理してください

【よかった点】
例：TODOの担当者と期限を表にできた

【注意点】
例：発言者名は一部誤っていたため、人が確認した

このように、短くても構造化された投稿が増えると、後から検索しやすくなります。

筆者は、このようなテンプレートをあえて短くすることを勧めています。長すぎると、投稿する前に疲れてしまうからです。最初は粗くても構いません。必要に応じて、DX推進担当者が後から事例フォーマットに整えればよいのです。

管理者は投稿を拾い、事例化する

コミュニティに投稿された小さな工夫は、そのままでは流れていきます。

そこで、DX推進担当や部門横断リーダーが、定期的に投稿を拾い上げます。

たとえば、月に1回、次のように整理します。

• 今月よく使われたプロンプト
• 反応が多かった投稿
• 他部門でも使えそうな事例
• 注意喚起が必要な失敗例
• 次回の社内勉強会で扱うテーマ

この整理を通じて、コミュニティの投稿が正式な社内ナレッジに変わっていきます。

AI活用コミュニティは、単なる雑談の場ではありません。現場の小さな知恵を、組織のベストプラクティス AIへ育てる入口です。

ここで大切なのは、コミュニティを放置しないことです。投稿を拾う人、整理する人、次の勉強会につなげる人がいなければ、チャンネルはすぐに静かになります。場を作るだけではなく、場を育てる役割が必要です。

展開先の候補を選ぶ

まず、成功事例と相性がよさそうな部門を選びます。

選定の観点は、次の通りです。

• 似た業務フローがあるか
• 入力データが整っているか
• 現場に課題感があるか
• 管理者が協力的か
• 成果を測定しやすいか
• 情報管理上のリスクが高すぎないか

たとえば、営業部で商談メモ要約がうまくいった場合、次の展開先としてはカスタマーサクセス部門が候補になります。どちらも顧客との会話を記録し、次回アクションにつなげる業務だからです。

一方で、人事面談や法務相談など、機微な情報を扱う業務に展開する場合は、慎重に設計する必要があります。

横展開の候補を選ぶときは、「似ている業務」だけでなく、「安全に試せる業務」かどうかも見ます。AI活用では、扱う情報の種類によってリスクが大きく変わるためです。

パイロット運用を行う

展開先が決まったら、まずはパイロット運用を行います。

期間は、1か月から3か月程度が現実的です。対象者も、最初は数名から十数名程度に絞ります。

パイロット運用では、次の項目を決めておきます。

• 対象業務
• 利用者
• 利用するAI機能
• 使用するプロンプト
• 入力してよい情報
• 出力の確認者
• 成果指標
• 振り返りのタイミング

この時点で重要なのは、成功を急がないことです。

パイロット運用の目的は、完璧な成果を出すことではありません。自部門の業務条件に合わせて、どこを変えるべきかを見つけることです。

筆者の経験上、最初のパイロットで価値があるのは「使えるかどうか」だけでなく、「どこで詰まるか」が見えることです。入力データが揃っていない。プロンプトが長すぎる。レビュー担当者が忙しい。出力の形式が現場の帳票と合わない。こうした詰まりを見つけることが、次の改善につながります。

成果指標を決める

展開計画では、成果指標を事前に決めます。

指標がないと、利用者の感想だけで判断することになります。もちろん感想も大切ですが、全社展開の判断材料としては不十分です。

たとえば、次のような指標を設定できます。

• 1件あたりの作業時間
• 月間の処理件数
• 上長レビューでの修正回数
• 問い合わせの一次回答率
• 利用者の継続率
• 社内勉強会での再利用事例数
• プロンプトライブラリへの登録数
• 他部門からの相談件数

数値化が難しい場合は、定性的な評価も組み合わせます。

たとえば、「業務のどの場面で使いやすかったか」「どの出力は使えなかったか」「人が確認すべき箇所はどこか」といった振り返りです。

成果指標は、現場を追い詰めるためのものではありません。改善の方向を見失わないためのものです。AI活用は、使った回数だけを追っても意味がありません。業務がどう変わったかを見なければ、定着にはつながりません。

展開後に事例フォーマットを更新する

横展開で得られた学びは、元の事例フォーマットに反映します。

たとえば、営業部の事例をカスタマーサクセス部門に展開した結果、次のような違いが分かったとします。

• 商談メモよりも定例会議メモの方が長い
• 顧客の要望と自社の宿題を分ける必要がある
• 継続課題の履歴を参照した方が精度が上がる
• 月次報告書への転記を前提にした出力形式が必要だった

こうした学びを追記することで、事例はより強いナレッジになります。

ベストプラクティスは、最初から完成しているものではありません。展開するたびに更新されるものです。

筆者は、AI活用のナレッジを「静的なマニュアル」ではなく「育つ資産」として扱うべきだと考えています。最初に作ったものを正解にするのではなく、使われるたびに磨く。その前提に立つと、社内ナレッジの運用は現実的になります。

成果数値だけが独り歩きする

「作業時間が半分になった」「対応件数が増えた」といった成果数値は、社内で注目されやすい情報です。

しかし、数字だけが独り歩きすると、現場に誤解が生まれます。

たとえば、ある部門で議事録作成時間が短縮されたとしても、それは会議の形式、入力データの質、レビュー体制、使用したプロンプトがそろっていたからかもしれません。別部門で同じ成果が出るとは限りません。

数値を共有するときは、必ず期間、対象、条件、前提をセットにします。誇大な印象を与えないことが、信頼されるAI事例 社内展開につながります。

筆者は、AI活用の成果を語るときほど、少し抑制的であるべきだと考えています。派手な数字は注目を集めますが、前提が抜けている数字は現場の信頼を失います。

事例が抽象的すぎて現場が使えない

「AIで業務効率化しました」「ナレッジ共有が進みました」「プロンプトを工夫しました」

こうした表現だけでは、現場は動けません。

現場が知りたいのは、より具体的な手順です。

• どの画面で
• 何を入力し
• どのような出力を得て
• 誰が確認し
• どの業務に反映したのか

ここまで分かると、初めて自分たちの業務に置き換えられます。

抽象的な事例は、共感は生んでも行動にはつながりにくいです。社内展開を目的にするなら、実行手順まで落とし込みます。

成功部門のやり方を押し付ける

横展開で避けたいのは、成功部門のやり方をそのまま押し付けることです。

ある部門でうまくいった方法が、別部門でもそのまま機能するとは限りません。

部門ごとに、業務プロセス、情報管理ルール、顧客との関係性、成果指標は違います。

成功事例は、あくまで参考材料です。展開先の部門が、自分たちの業務に合わせて編集できる余地を残す必要があります。

そのため、事例共有の場では「この通りにやってください」ではなく、「この構造を自部門に置き換えるなら、どこを変える必要がありますか」と問いかけることが大切です。

筆者は、横展開という言葉を使うときにも注意しています。横に「コピー」するのではなく、横に「翻訳」する。部門ごとの言葉、業務、制約に合わせて翻訳することが、実務上は欠かせません。

セキュリティや情報管理の前提を共有しない

AI活用では、情報管理の前提が非常に重要です。

顧客情報、個人情報、契約情報、未公開情報などを扱う場合、どこまでAIに入力してよいのかを明確にする必要があります。

成功事例を共有するときも、便利さだけを伝えるのではなく、情報管理上の注意点を必ず含めます。

たとえば、次のような内容です。

• 顧客名はマスキングした
• 個人情報は入力しなかった
• 社内専用の環境で扱った
• 出力は必ず担当者が確認した
• 機密性の高い内容は対象外にした

便利な事例ほど、他部門が安易に真似してしまう可能性があります。だからこそ、注意点もセットで共有する必要があります。

Kanataのように、プロジェクト単位でメンバーや利用するデータを整理できるツールを使う場合は、関係者が同じ情報を見てよい範囲でプロジェクトを分けることが重要です。営業部、人事部、経理部など、扱う情報の種類が違う場合は、無理に同じ場所へまとめず、情報の閲覧範囲に合わせて設計します。

AI活用の社内展開は、便利さと安全性を両立して初めて続きます。どちらか一方だけでは、組織には根づきません。NISTのAIリスクマネジメントフレームワークでも、生成AI特有のリスクを識別し、組織の目的や優先度に合わせて管理する考え方が示されています。

ナレッジが更新されなくなる

事例フォーマットやプロンプトライブラリを作っても、更新されなければすぐに古くなります。

AI活用の方法は、業務の変化、社内ルールの変更、利用者の習熟度によって変わります。古いプロンプトや古い情報が残り続けると、かえって混乱を招きます。

そのため、社内ナレッジには必ず管理者と更新サイクルを設定します。

たとえば、次のような運用です。

• 月1回、よく使われたプロンプトを確認する
• 四半期に1回、事例フォーマットを見直す
• 利用されていないナレッジを統合・削除する
• 情報管理ルールの変更があれば、関連事例を更新する
• 新しい成功事例を社内勉強会で追加する

ナレッジ共有は、作って終わりではありません。更新され続けることで、組織の学習資産になります。

筆者は、ここを「庭の手入れ」に近いと感じています。種をまくだけでは、よい庭にはなりません。伸びた枝を整え、古いものを入れ替え、新しい芽を見つける。その手間をかけるから、ナレッジは生きた状態を保てます。

AIチャットで事例ヒアリング項目を整理する

まず、AIチャットを使って、成功事例をヒアリングするための質問項目を作ります。

たとえば、DX推進担当者が現場担当者にインタビューする前に、次のように依頼します。

あなたは社内のAI活用事例を整理するDX推進担当です。
現場担当者にヒアリングするための質問項目を作成してください。

# 目的
AI活用の成功事例を、他部門でも再現できるケーススタディとして整理すること

# 聞きたい観点
- 導入前の課題
- 対象業務
- 使用したAI機能
- 入力データ
- プロンプト
- 成果
- 失敗点
- 他部門展開の注意点

# 出力形式
ヒアリングシート形式で、質問と回答欄を作成してください。

このように、ヒアリング項目を標準化しておくと、事例ごとの情報のばらつきが減ります。

筆者は、ヒアリングシートの標準化を重視しています。担当者によって聞く内容が違うと、後から事例を比較できなくなるからです。最初に質問の型を作っておくことで、社内ナレッジとしての品質がそろいやすくなります。

AI要約で勉強会の内容をケーススタディ化する

社内勉強会や共有会を開いた後は、その内容をAI要約で整理します。

録音、議事メモ、チャットログなどをもとに、次のような出力形式でまとめます。

• 共有された事例
• 発表者の課題意識
• 使用したAI機能
• 参加者からの質問
• 他部門への応用可能性
• 展開時の懸念
• 次回までのアクション

勉強会の内容をそのまま流してしまうのではなく、ケーススタディとして整えることで、後から参加していない人も理解しやすくなります。

AI要約を使う場合は、単に「要約してください」と依頼するのではなく、「事例概要」「再現手順」「参加者の質問」「次回アクション」に分けて整理するよう指定すると、社内ナレッジとして活用しやすくなります。

共有ライブラリに事例とプロンプトを保存する

確定した事例やプロンプトは、共有ライブラリに保存します。

保存するときは、検索しやすい名前を付けます。

たとえば、次のような命名です。

• 営業_商談メモ要約_成功事例_2026-05
• 経理_問い合わせ一次回答_プロンプト_v1
• 人事_研修動画要約_ケーススタディ_2026-05
• 全社_議事録テンプレート_標準版_v2

名前に部門、用途、種類、日付やバージョンを入れると、後から探しやすくなります。

また、ライブラリに登録するときは、説明文に「どの業務で使うか」「誰が確認したか」「利用時の注意点」を書いておくと、再利用しやすくなります。

Kanataを使う場合は、プロンプトや学習データをプロジェクト単位で整理できます。部署別、業務別、用途別にプロジェクトを分けることで、関係者が必要な情報にアクセスしやすくなります。すでに別のナレッジ管理ツールを使っている企業では、既存ツールと役割分担を決め、AIで使うプロンプトや参照データだけをKanata側に整理する方法もあります。

筆者は、プロンプトや事例を保存するとき、名前の付け方を軽視しないように伝えています。名前が曖昧だと、使われなくなるからです。ナレッジは、見つけられなければ存在しないのと同じです。

AIチャットで過去事例を検索しやすくする

事例が増えると、今度は探すことが課題になります。

「過去に似た事例があった気がする」「営業部で使っていたプロンプトを見たい」「人事部の研修動画要約のやり方を知りたい」

こうした場面で、AIチャットを社内ナレッジ検索の入口にできます。

共有ライブラリに事例、プロンプト、勉強会要約を蓄積しておけば、担当者は対話形式で必要な情報を探せます。

たとえば、次のように質問できます。

営業部で使われたAI活用事例のうち、他部門でも再利用しやすいものを3つ教えてください。
それぞれ、対象業務、使ったプロンプト、展開時の注意点を整理してください。

このように、検索ではなく対話でナレッジを探せるようになると、社内ナレッジ共有のハードルが下がります。

社内ナレッジは、蓄積するだけでは足りません。使う人が、必要なタイミングで取り出せることが重要です。

成功事例を教材化する

横展開したい事例は、社内勉強会だけでなく、教材化する方法もあります。

特に、全社で共通して使ってほしいプロンプトや、情報管理上の注意点がある場合は、動画や教材として残すと効果的です。

たとえば、次のような教材が考えられます。

• AI議事録作成の基本手順
• 商談メモ要約プロンプトの使い方
• 社内ナレッジ登録ルール
• AI出力をレビューするチェックポイント
• 入力してはいけない情報の判断基準
• 成功事例から学ぶ部門別活用パターン

Kanataのeラーニング機能のように、動画や研修コンテンツを登録し、受講者が必要に応じて学べる仕組みを使えば、成功事例を一度の発表で終わらせず、新入社員や異動者にも継続的に共有できます。

筆者は、AI活用の教育を一回の研修で完結させるのは難しいと考えています。人は、必要になったときに学び直せる環境があって初めて、実務で使えるようになります。成功事例の教材化は、そのための有効な手段です。

事例の登録責任者を決める

まず、事例を登録する責任者を決めます。

現場担当者だけに任せると、日常業務に追われて更新が止まりやすくなります。一方で、DX推進部門だけで整理すると、現場のリアルな工夫が抜け落ちることがあります。

おすすめは、現場担当者とDX推進担当者の共同管理です。

このように役割を分けることで、現場感と再利用性の両方を保てます。

筆者が支援する場合も、現場の言葉をそのまま残す部分と、横展開しやすいように整理する部分を分けます。現場の言葉を削りすぎると、事例はきれいになりますが、迫力がなくなります。一方で、整理しなければ再利用しにくい。両方のバランスが大切です。

事例の公開基準を決める

次に、どの事例を社内公開するかの基準を決めます。

すべての試行錯誤を全社公開すると、情報量が多くなりすぎます。一方で、完璧な成功事例だけを公開すると、学びが少なくなります。

公開基準としては、次のような観点が考えられます。

• 他部門でも似た課題がありそうか
• 使用手順が説明できるか
• 情報管理上の問題がないか
• 成果または学びが明確か
• プロンプトや入力データの再利用性があるか
• 失敗点も含めて共有できるか

公開基準を決めておくと、ナレッジの質を保ちやすくなります。

ただし、基準を厳しくしすぎると、誰も投稿しなくなります。最初は「小さくても学びがあるもの」を歓迎し、正式な事例化はDX推進担当者がサポートする形が現実的です。

月次で棚卸しを行う

社内ナレッジは、定期的に棚卸しします。

たとえば、月に1回、30分から60分程度で次の項目を確認します。

• 新しく登録された事例
• よく閲覧された事例
• 他部門で再利用された事例
• 更新が必要なプロンプト
• 削除または統合した方がよいナレッジ
• 次回の社内勉強会で扱うテーマ

棚卸しを行うことで、ナレッジが古くなることを防げます。

また、「どの事例が実際に使われているか」を把握できるため、次の展開計画にもつなげやすくなります。

Kanataを使う場合は、プロジェクトごとにプロンプトや学習データを整理できるため、部門別、業務別、用途別にナレッジを管理しやすくなります。棚卸しの際には、使われていないプロンプト、重複している資料、古くなった事例を確認し、必要に応じて更新します。

筆者は、月次棚卸しを「ナレッジの掃除」と呼んでいます。散らかったままの部屋では、必要なものを取り出せません。社内ナレッジも同じです。

成功事例を評価や称賛と結びつける

AI活用の横展開を進めるには、現場が事例を共有したくなる動機も必要です。

担当者にとって、事例共有は追加の手間です。共有しても評価されない状態では、投稿や登録が続きにくくなります。

そこで、次のような工夫が考えられます。

• 月次の社内勉強会で好事例を紹介する
• 他部門に展開された事例を称賛する
• プロンプトライブラリへの登録数を可視化する
• 部門横断の改善貢献として評価する
• 経営会議で代表事例を取り上げる

大げさな表彰である必要はありません。

「この事例が別部門でも使われました」と見えるだけでも、現場の共有意欲は高まります。

筆者は、AI活用を根づかせるには、使った人だけでなく、共有した人を評価することが大切だと考えています。自分の業務だけを効率化した人よりも、その方法を他部門に使える形で残した人の方が、組織全体への貢献は大きいからです。