はじめに——「あの営業部の成功を全部門でやれ」という第10の壁
本連載ではここまで、企業AI導入で多くの組織がつまずく壁を順に越えてきました。第1回の「使われずに終わる（定着）」に始まり、第7回の「データレディネス」、第8回の「人材・ツール乱立」、そして第9回では、個別施策の成果を全社KPIと接続し、経営がAIポートフォリオに投資判断できる状態をつくりました。
経営ダッシュボードが機能し始めると、経営は必ずこう言います。「あの営業部の成功を、全部門でやれ」。ここで第10の壁が現れます。成功部門のやり方をそのままコピーして他部門に配ったのに、どこも成果が出ない——「あの部署だからできた」という言葉とともに、横展開が軒並み失敗するのです。
原因は、コピーの仕方にあります。1部門の成功は、その部門の暗黙知・データ事情・熱量あるキーパーソンという「見えない前提」の上に成り立っており、目に見えるプロンプトやツール設定だけを複製しても再現されません。かといって、全社標準を厳格に定めて押し付ければ、今度は現場最適が死に、第1回で扱った「使われない」問題が各部門で再発します。
第10回は、この「標準化しすぎず・現場最適を殺さず、成功をN部門目へ複製する」スケールアウト設計を扱います。連載①が「1部門で使われるようになる」を扱ったのに対し、本回の主題は「2部門目、3部門目、そしてグループ会社への複製」です。第9回の「投資判断」を「投資の回収スケール」で受ける、連載の第3サイクル「複製と拡大」の起点となる回です。
想定読者は、1部門でのAI活用成功を全社・グループ会社へ広げるミッションを負ったDX推進部門・情シス・経営企画の方々です。
前提——なぜ「単純コピー」は失敗するのか
横展開の失敗パターンは驚くほど似通っています。まず、成功が何に依存していたかを分解するところから始めます。1部門の成功は、典型的には次の3つの「見えない資産」に支えられています。
依存1：暗黙知——ドキュメントにない「使いこなしの文脈」
成功部門では、「どの業務のどの場面でAIを使うと効くか」「AIの出力をどこまで信じてどこから人が直すか」という判断基準が、日々の試行錯誤を通じてメンバーの頭の中に蓄積されています。プロンプト集を配っても、この判断基準（いつ・何に・どこまで使うか）は移動しません。受け取った部門は「プロンプトはあるが、自分の業務のどこで使えばいいか分からない」状態に置かれます。
依存2：データ事情——その部門「だけ」が持っていた良質なデータ
連載⑦で扱った通り、AIの精度はデータレディネスに強く依存します。成功部門は、たまたま整備されたSFAデータや、過去数年分の構造化された報告書を持っていたのかもしれません。同じ仕組みをデータが未整備の部門に持ち込めば、精度は再現されず、「うちでは使えない」という評価だけが残ります。
依存3：キーパーソン——熱量で摩擦を突破した「あの人」
初期の成功には、業務とAIの両方を理解し、周囲の懐疑を熱量で突破するキーパーソンがほぼ必ず存在します。横展開先にその人はいません。連載⑧で扱った「AI担当者1人依存」が、部門単位で再演される構図です。
つまり横展開の失敗とは、「見える成果物」だけをコピーし、「見えない前提」を複製しなかったことの帰結です。ここを設計で解くのが本回のテーマです。
第1ステップ：成功を「移植可能」と「再構築が必要」に切り分ける
スケールアウト設計の出発点は、成功部門の勝ちパターンを棚卸しし、そのまま持ち運べる要素と、展開先で作り直すしかない要素に切り分けることです。この切り分けをせずに「全部パッケージにして配る」から失敗します。
| 分類 | 要素の例 | 展開時の扱い |
|---|---|---|
| 移植可能 （コピーできる） | 業務プロセスの型（どの工程にAIを挟むか） | 手順書化してそのまま配布 |
| プロンプトテンプレート・出力フォーマット | 変数部分を明示してテンプレート化 | |
| 評価基準・チェックリスト（出力をどう検証するか） | 共通ルールとして標準化 | |
| 失敗事例集（何をやってダメだったか） | そのまま共有——最も価値が高い資産の一つ | |
| 再構築が必要 （コピーできない） | データ（品質・粒度・鮮度・所在） | 展開先のデータレディネス診断から始める（連載⑦の再適用） |
| 権限・アクセス制御（誰が何を見られるか） | 展開先の組織構造に合わせて再設計 | |
| 業務文脈（用語・商流・顧客特性） | 展開先の現場メンバーと共同でローカライズ | |
| 推進体制・キーパーソン | 展開先で育成する（後述の展開支援チームが伴走） |
ポイントは、移植可能な要素は徹底的に標準化し、再構築が必要な要素は最初から「作り直す前提」で工数とスケジュールを見積もることです。横展開の見積もりが甘くなるのは、後者を「コピーで済む」と誤認するからです。経験則として、N部門目への展開は「ゼロから作る場合の5〜7割」の工数が掛かると見込むのが現実的です。「コピーだから1割で済む」という前提の計画は、ほぼ確実に破綻します。
第2ステップ：「勝ちパターン」を再現レシピに変換する
切り分けができたら、成功部門の実践を「再現レシピ」の形式に変換します。ここで重要なのは、レシピを「操作手順書」ではなく「判断基準書」として書くことです。
操作手順（このボタンを押す、このプロンプトを貼る）は業務が少し違えば使えなくなりますが、判断基準は業務が違っても転用できます。レシピに最低限含めるべき項目は次の通りです。
- 適用条件：この勝ちパターンが効くのは、どんな業務特性・データ条件・チーム規模のときか。逆に「効かない条件」も明記する。
- プロセスの型：業務フローのどこにAIを挟み、人がどこで検証・修正するか。
- 前提データの要件：どんなデータが、どの品質・鮮度で必要か（展開先が自己診断できるチェックリスト形式で）。
- 立ち上げの摩擦と対処：成功部門が初期に直面した抵抗・失敗と、それをどう乗り越えたか。
- 効果の測り方：連載⑨で設計したKPI接続に沿って、何をいつ測れば「効いている」と判断できるか。
特に「効かない条件」と「失敗事例」の明記は、展開先の信頼を得るうえで決定的に効きます。成功だけを語るレシピは「うちとは事情が違う」と一蹴されますが、失敗と限界を語るレシピは「正直な道具」として受け入れられます。
第3ステップ：パイロット部門を「展開支援チーム」に転換する
レシピだけを配って「あとはよろしく」では、依存3（キーパーソン不在）が解決しません。ここで効くのが、成功部門のメンバーを展開の支援側に回す体制転換です。
連載⑧で扱ったスキルの組織内移転を、部門単位に拡張した形です。設計のポイントは3つあります。
1. 「教える側」を公式な役割にする
成功部門のキーパーソンに、業務時間の一定割合（例：2〜3割）を展開支援に充てる役割を公式に与えます。「本業の片手間で相談に乗る」形は、本業が忙しくなった瞬間に消滅します。評価制度上も、展開先の立ち上がり（後述のマイルストーン到達）を支援者の成果として認めることが不可欠です。
2. 支援は「代行」ではなく「伴走」に限定する
展開支援チームが展開先の構築を代行してしまうと、展開先にキーパーソンが育たず、支援チームが撤収した瞬間に形骸化します。支援チームの役割は、レシピの読み合わせ、データレディネス診断の支援、初期のつまずきの相談対応までとし、手を動かす主体は必ず展開先に置きます。
3. 展開のたびにレシピを更新する
2部門目、3部門目の展開で見つかった「レシピの穴」（この業種では前提が違った、この規模では体制が重すぎた）を、支援チームがレシピに還流します。これにより、展開を重ねるほどレシピの汎用性が上がり、N部門目の立ち上げコストが逓減していきます。横展開とは、レシピという資産を展開のたびに磨き込む反復プロセスだと捉えるのが正しい理解です。
第4ステップ：「標準化の層」を分けて現場最適を守る
横展開でもう一つ陥りやすいのが、標準化の全域適用です。ガバナンスの名の下にプロンプトの文言から運用ルールまで全社統一すると、各部門の業務実態と乖離し、現場は「使いにくい公式ツール」を迂回してシャドーAIに流れます（連載⑧で扱ったツール乱立の再来です）。
解決は、標準化する層と現場に委ねる層を明示的に分けることです。
| 層 | 扱い | 対象の例 |
|---|---|---|
| 全社で固定 （変更不可） | ガバナンスとして統一 | セキュリティ基準、データ取り扱い区分、禁止用途、監査ログ、ベンダー契約の枠組み |
| 全社で推奨 （理由があれば変更可） | デフォルトを提供し、逸脱は申請ベースで許容 | プロセスの型、評価基準、プロンプトテンプレート、KPIの測定方法 |
| 現場で自由 （部門裁量） | 一切縛らない | プロンプトの文言調整、業務用語のローカライズ、利用頻度・場面の選択 |
この3層の線引きを最初に宣言しておくと、「標準化しすぎて使われない」と「自由すぎて統制できない」の両方を避けられます。判断に迷う要素が出たら、「これが部門ごとにバラバラだと、セキュリティ・コンプライアンス・全社KPI測定のどれかが壊れるか？」と問い、壊れないなら下の層に置く——これが基本則です。
グループ会社・多拠点への展開——「同じ会社」ではない前提で設計する
展開先が同一法人内の部門からグループ会社・海外拠点に広がると、難易度が一段上がります。部門間展開では暗黙に共有されていた前提が、法人をまたぐと成立しなくなるからです。
- ガバナンスの差異：グループ会社ごとに情報セキュリティ規程・データ取り扱い基準・決裁プロセスが異なります。親会社の「全社で固定」層をそのまま強制できるとは限らず、各社の規程との突き合わせ（ギャップ分析）が展開前の必須工程になります。
- 契約・ライセンスの壁：親会社が締結したAIツールの利用契約が、子会社の従業員をカバーしているかは契約次第です。展開計画の初期に法務・購買を巻き込み、グループ利用の可否とコスト按分を確定させます。
- データの越境：海外拠点への展開では、個人データの越境移転規制（GDPR等）や国ごとのAI規制が絡みます。「どのデータはどの国で処理してよいか」のマッピングを、展開レシピのデータ要件に追加します。
- 推進体制の非対称：子会社には親会社のようなDX推進部門がないことが多く、展開支援チームの伴走比重を部門間展開より重く設計する必要があります。一方で、子会社側に「押し付けられた」という受け止めが生まれると定着しないため、子会社の経営層を早期に巻き込み、「自社の課題を解く道具」として位置づけ直すプロセスを省略しないことが重要です。
グループ展開は「部門展開の延長」ではなく、「ガバナンスの異なる組織への移植」として、レシピにグループ展開用の追加チェック項目を持たせるのが実務的です。
スケールアウト設計チェックリスト
| フェーズ | チェック項目 |
|---|---|
| 棚卸し | 成功部門の勝ちパターンを「移植可能」と「再構築が必要」に切り分けたか |
| 成功が依存していた暗黙知・データ事情・キーパーソンを言語化したか | |
| 「効かない条件」と失敗事例をレシピに含めたか | |
| レシピ化 | 操作手順ではなく判断基準として記述したか |
| 展開先が自己診断できるデータ要件チェックリストを付けたか | |
| 体制 | 成功部門のキーパーソンに展開支援の公式な役割と評価を与えたか |
| 支援は伴走に限定し、手を動かす主体を展開先に置いたか | |
| 展開のたびにレシピへ学びを還流する仕組みがあるか | |
| 標準化 | 「固定・推奨・自由」の3層を宣言したか |
| 逸脱申請の窓口とルールを用意したか | |
| グループ展開 | 各社規程とのギャップ分析を展開前に実施したか |
| 契約・ライセンスのグループ利用可否とコスト按分を確定したか | |
| データ越境の可否マッピングをレシピに追加したか | |
| 測定 | 展開先ごとの立ち上がりマイルストーン（連載⑨のKPI接続）を定義したか |
| N部門目の立ち上げコストが逓減しているかを追跡しているか |
よくある質問（Q&A）
Q1. 成功部門のツールとプロンプトをそのまま配布すれば横展開になりませんか？
なりません。1部門の成功は、暗黙知（いつ・何に・どこまで使うかの判断基準）、その部門固有のデータ事情、熱量あるキーパーソンという「見えない前提」に依存しています。見える成果物だけをコピーしても前提は複製されず、「うちでは使えない」という評価だけが残ります。移植可能な要素と再構築が必要な要素の切り分けが出発点です。
Q2. 横展開のコストはどの程度見込むべきですか？
「コピーだから安く済む」という前提は危険です。データ・権限・業務文脈の再構築が必要なため、経験則としてN部門目の展開にはゼロから作る場合の5〜7割の工数を見込むのが現実的です。ただし、展開のたびにレシピを磨き込む仕組みがあれば、この比率は展開を重ねるごとに下がっていきます。
Q3. 全社標準を作ると現場から「使いにくい」と反発されます。どこまで統一すべきですか？
「固定・推奨・自由」の3層に分けてください。セキュリティ・データ取り扱い・禁止用途など、バラバラだと統制が壊れるものだけを固定層に置き、プロセスの型やテンプレートは「理由があれば変更可」の推奨層に、プロンプトの文言や利用場面は現場の自由に委ねます。判断基準は「部門ごとに異なるとセキュリティ・コンプライアンス・全社KPI測定のどれかが壊れるか」です。
Q4. 展開支援チームを作りたいのですが、成功部門は「本業が忙しい」と難色を示します。
公式な役割化と評価接続がない限り、支援は必ず本業に押し戻されます。業務時間の2〜3割を支援に充てる役割を部門長合意のうえで公式に設定し、展開先の立ち上がりを支援者の評価に反映してください。逆に言えば、それだけの投資に値するリターン（展開先での成果再現）があるという試算を、連載⑨のインパクト測定の枠組みで経営に示すことが前提になります。
Q5. グループ会社への展開で最初にやるべきことは何ですか？
各社の情報セキュリティ規程・データ取り扱い基準と、自社の「固定層」ルールとのギャップ分析です。あわせて、AIツールの利用契約が子会社従業員をカバーしているかを法務・購買と確認します。この2つを飛ばして現場レベルで展開を始めると、後からガバナンスと契約の問題で全面停止するリスクがあります。また、子会社経営層の早期巻き込みを省略すると「親会社からの押し付け」と受け止められ、定着しません。
まとめ——横展開とは「コピー」ではなく「レシピの反復的な移植」である
第10回の要点は3つです。
1. 成功の「見えない前提」を直視する。1部門の成功は、暗黙知・データ事情・キーパーソンに依存しています。見える成果物のコピーでは再現されません。移植可能な要素（プロセス・テンプレート・評価基準・失敗事例）と、再構築が必要な要素（データ・権限・業務文脈・体制）を切り分けることが出発点です。
2. レシピと伴走で「人依存」を「仕組み依存」に変える。勝ちパターンを判断基準ベースの再現レシピに変換し、成功部門を展開支援チームに転換して伴走させます。支援は代行ではなく伴走に限定し、展開のたびにレシピへ学びを還流することで、N部門目の立ち上げコストを逓減させます。
3. 標準化は3層で設計し、現場最適を殺さない。統制が壊れるものだけを固定し、それ以外はデフォルト提供と現場裁量に委ねます。グループ会社への展開では、ガバナンス差異のギャップ分析・契約確認・データ越境マッピングを「部門展開とは別物」として設計に織り込みます。
連載①から⑨で「1部門で成功させ、経営が投資判断できる状態」まで来ました。第10回のスケールアウト設計により、その投資を回収する「複製と拡大」のサイクルが回り始めます。次回以降は、この第3サイクルを深掘りし、拡大に伴って現れる新たな壁を扱っていく予定です。
免責事項：本記事は2026年7月時点の一般的な情報提供であり、特定の組織における導入効果を保証するものではありません。また、法的助言ではありません。グループ会社間のデータ共有・契約・越境移転などの実務は、自社の規程・契約内容・関連法令に照らして検討し、必要に応じて法務部門や専門家にご相談ください。
コメント