生成AI活用の横展開ガイド2026｜1部署で成功した使い方が他部署で再現しない5つの理由

生成AIの社内利用では、特定の部署だけが先に成果を出すことがよくあります。営業がヒアリングメモの整理で効果を出した、管理部門が問い合わせ対応の下書きで時間を減らした、といった形です。次に出てくるのが「同じことを他の部署でもやってほしい」という話です。

ところが、うまくいった部署のやり方をそのまま渡しても、他部署ではほとんど使われないまま終わることがあります。手順書も配った、プロンプトも共有した、それでも定着しない。本記事では、なぜ横展開が止まるのかを整理し、部署をまたいで再現するための進め方をまとめます。

なぜ「同じやり方」が他部署では動かないのか

成功していたのは手順ではなく前提だった

先行した部署の成果は、プロンプトそのものよりも、その周りの条件に支えられていることが多いものです。入力する情報がすでに一か所にそろっている、成果物の型が決まっている、確認する人が決まっている。こうした前提が整っているから、AIの出力が実務に乗ります。

横展開で渡されるのは、たいてい目に見える部分だけです。プロンプト文と操作手順は移りますが、その裏にある前提は移りません。受け入れ側では入力する情報が個人のメールに散っていて、出力の型も人によって違う。同じ道具を使っても結果が変わるのは、このためです。

「困っていない業務」に道具だけが届く

もうひとつの理由は、課題の出どころのずれです。先行部署では、自分たちが困っていた業務に自分たちで手を当てました。横展開では、困りごとの発見を飛ばして、解決策だけが先に届きます。

受け取った側から見ると、頼んでいない道具が増えたことになります。ここで反発ではなく静かな無視が起きるため、推進側は理由に気づきにくくなります。導入時の反応の読み解き方は現場が乗ってこないときの向き合い方も参考になります。

移せる要素と移せない要素を切り分ける

移せるもの

部署をまたいでもそのまま使えるのは、汎用性の高い部分です。文章を整える、要点を抜き出す、長い文書を分類する、といった処理は業務内容に依存しません。出力の確認手順や、機密情報の扱いに関する社内ルールも共通で使えます。

プロンプトについては、そのままではなく骨格として渡すと移りやすくなります。目的、入力する材料、出力の形式、禁止事項という四つの枠だけを共有し、中身は受け入れ側に書いてもらう方法です。共有の仕組みそのものはプロンプトの社内管理の考え方と合わせて整えます。

移せないもの

一方で、業務の中身に密着した部分は移りません。専門用語の定義、顧客ごとの事情、判断の分かれ目、その部署だけの承認ルート。これらは先行部署の暗黙知として埋め込まれており、文書化されていないことがほとんどです。

横展開の設計では、この二つを分けて扱うことが出発点になります。移せる部分は配布し、移せない部分は受け入れ側で作ってもらう。この線引きを最初に共有しておくと、「配ったのに使われない」という行き違いが減ります。

横展開を進める5つのステップ

ステップ1｜先行部署の前提を書き出す

まず、うまくいっている業務について、AIに渡している情報の出どころと、出力を誰が確認しているかを書き出します。ここで前提が言語化されると、受け入れ側に何を用意してもらう必要があるかが見えてきます。

ステップ2｜受け入れ側の業務を先に聞く

次に、展開先の部署で時間がかかっている作業を聞きます。この段階では生成AIの話をしません。困りごとを先に出しておくと、後から示す使い方が自分たちの話として受け取られます。

ステップ3｜1業務だけで試す

展開先では対象を1業務に絞ります。複数を同時に始めると、うまくいかなかったときに原因が特定できません。期間も区切り、続けるかどうかを判断する日を先に決めておきます。

ステップ4｜受け入れ側の手順書に書き換える

試した結果は、先行部署の手順書を配るのではなく、展開先の言葉で書き直します。既存の業務手順の中に組み込む形にすると、新しい作業が増えた感覚になりません。手順書の書き換え方は業務マニュアルの生成AI対応改訂で整理しています。

ステップ5｜担当を先行部署から受け入れ側に移す

最後に、問い合わせ先を展開先の中の人に移します。推進部門や先行部署が窓口のままだと、その部署の業務として定着しません。誰が詳しいかが部署内で決まった時点で、横展開はひと区切りです。

受け入れ側にそろっているべき3条件

展開先を選ぶときは、意欲よりも次の3点を見ます。第一に、対象業務の入力情報がまとまっていること。第二に、出力を確認できる人が部署内にいること。第三に、その業務が繰り返し発生すること。

三つ目は見落とされがちです。年に数回しか起きない業務にAIを組み込んでも、次に使うころには手順を忘れています。頻度の低い業務は、横展開の初回対象には向きません。

横展開しないほうがよい場合

すべての成功例を広げる必要はありません。先行部署の特殊な事情に強く依存している場合、無理に移すと手間だけが増えます。展開先で確認の負担が作業時間を上回るなら、その業務は対象から外す判断が妥当です。

また、先行部署でもまだ運用が安定していない段階での展開は避けます。手順が変わり続けている使い方を広げると、部署ごとに違うやり方が並び、後からそろえる作業が発生します。試行から定着に移す進め方はPoCから本番運用への移行を参考にしてください。

広がったかどうかをどう確認するか

横展開の進み具合は、配布したプロンプトの数や説明会の回数では測れません。見るべきは、展開先の部署が自分たちで新しい使い方を追加したかどうかです。渡されたものを使うだけの段階から、自分たちで作る段階に移ったとき、その部署に定着したと判断できます。

あわせて、対象業務にかかっていた時間や手戻りの回数を、開始前と比べて記録しておきます。数値の置き方は生成AI導入のROI測定の考え方が使えます。

まとめ

横展開が止まるのは、道具ではなく前提が移っていないからです。先行部署の成果を支えていた条件を書き出し、移せる部分と移せない部分を切り分けたうえで、展開先には1業務ずつ試してもらいます。手順書は展開先の言葉に書き換え、最後に問い合わせ先をその部署の中へ移します。

展開先を選ぶときは、入力情報がまとまっていること、確認できる人がいること、業務が繰り返し起きることの3点を確認します。この3点がそろわない部署では、順番を待つほうが結果的に早く進みます。

本記事は一般的な実務の整理であり、個別の助言ではありません。部署をまたぐ情報の受け渡しは、社内の情報管理規程に関わる場合があります。実際の運用は社内規程および関係部門の確認を経てご判断ください。