CONTENTS12 sections
「導入したのに使われない」を超える
Copilot を全社配布したのに利用率 10%。導入研修は 1 回開いて終わり、勝ち事例は個人の Notion に埋もれて再利用されない。これは社員のスキル問題ではなく、組織の「自然普及ループ」が設計されていないから。
「AIチャンピオン制度 × 月 1 LT × ハッカソン × KPI 連動」で自然普及ループを再現する方法を、導入する側（情シス・DX 推進・現場リーダー）と 提供する側（AI プロダクトプロバイダー）の両視点で整理した。
「導入したのに使われない」は社員のスキル問題ではなく、組織側の自然普及ループ設計の問題。AIチャンピオン × 月1 LT × ハッカソン × KPI 連動でクローズド環境にもループを再現できる。
- 「導入したのに使われない」は組織側の設計問題。社員スキルの問題ではない。
- Claude Code / Codex が SNS で広がった鍵は ①個人が試せる ②発信する場 ③発信者が評価される の 3 要素。
- クローズド環境で再現する道具立て：AIチャンピオン制度 / 月1 LT / ハッカソン / KPI 連動。
- 強制と自発性のバランス設計が成否を分ける。軽い KPI 連動 + 表彰、評価はチーム単位で。
「あるある」と問題の正体
>1-1失敗あるある
- Copilot 全社配布したが利用率 10%：ライセンスは配ったが、誰も触らない
- キックオフ研修だけで終わる：説明会だけ盛り上がり、3 ヶ月後にツールを開いた人は 1 割。現場の業務文脈に落ちない
- AI 推進担当者と現場が分断：推進側のロードマップが現場のリアルな業務課題と噛み合わない
- 勝ち事例が再利用されない：個人の Notion・Slack に良いプロンプトが散らばり、半年後には誰も再現できない
>1-2問題の正体
これは個別社員のスキル不足ではなく、組織側の設計問題：
- 「使う理由」と「使うと評価される仕組み」が欠落
- 学習コストを払う心理的余裕がない（評価軸が古いまま）
- 失敗が許される心理的安全性が低い
→ プロダクトの押し付けではなく、自然普及ループの設計が解。
なぜ Claude Code / Codex は「勝手に」広がったのか
社内 AI 普及を解く前に、社外で起きている自然普及を観察する。Codex / Claude Code / Cursor が爆発的に広がったのは、Fig.0 の 5 ステップループが回ったから。そしてそのループが回り続ける前提条件は 3 つに集約できる。
加えて、Codex / Claude Code は CLI / Agent Layer を OSS 化した。これは単なる透明性ではなく「AI agent をどう動かすか／どう安全にツール実行するか／どうプロンプト設計するか」という 運用知の無料配布。Dify や n8n も同じ構造。
① 個人が使える（試せるハードルの低さ）
② 発信できる場所がある（SNS / OSS / コミュニティ）
③ 発信者が評価される（フォロワー / 採用オファー / 副業）
→ 社内ではこの 3 つが揃っていない。だから広がらない。
社内に AI を流通させる側のアプローチ
情シス / DX 推進 / 中間管理職 / AI チャンピオン候補 向け
「Claude 現象」を社内で再現する 3 つの仕掛け
>3-1AIチャンピオン制度（基盤）
- 各部門で AI 得意な社員を 公式チャンピオン に任命（自発的手挙げ制が必須）
- 役割：月 1 回 30 分の勉強会開催 / Slack 専用 ch（
#ai-use-cases）でプロンプト共有 / 同僚メンタリング - インセンティブ：表彰・社内ポイント・予算優先・役員前プレゼン機会・「社内スター」化される実感
成功事例：住友商事「Copilot Champion」 → 年間 12 億円コスト削減、業務時間 1 万時間/月削減
最小構成：2〜3 名から開始 → 3 ヶ月後に本格展開
>3-2月 1 ユースケース共有会（LT）
一番即効性が高い仕掛け。
- 形式：ライトニングトーク 5〜10 分／人、月 1 開催
- 発表テンプレート必須：
課題 → プロンプト → 結果 → 時間削減効果 - 非エンジニアも参加 OK（むしろ営業・経理・人事の事例が刺さる）
- 連鎖効果：発表者が「勝ち事例」として全社ニュースに載ると、次回応募者が倍増
- 事例：スマートニュース Knowledge Share（196 名参加実績）／千株式会社では マーケ担当が主催で運用 — 情シス主導でなくてもよい
>3-3ハッカソン（ユースケース生成器）
勉強会＝知識共有、ハッカソン＝ユースケース生成、の二段構えで運用する。
| 論点 | 推奨 |
|---|---|
| 形式 | 半日〜1 日で「自分の業務課題を AI で解決」のプロトタイプ作成 → 成果発表 |
| 頻度 | 半年に 1 回（月 1 では負荷高い、年 1 では薄い） |
| 開催日 | 業務時間化が望ましい。土曜開催だと参加層が偏る（独身・若手のみに） |
| インセンティブ | 優勝チームに開発予算・リソース付与、上位事例は本番化検討 |
| 評価連動 | 成果発表を半期評価のシートに紐づける（強制でなく加点要素） |
効果は 3 つ：①早期採用者が自然発生、②部門横断のチーム編成で社内ネットワーク形成、③OSS 化できない自社プロダクトでも「市場側がユースケースを発見するループ」が回る。
★ 強制と自発性のバランス設計
ここが社内 AI 普及の最大の論点。経営層は KPI で締めたがる、現場は自発性で動きたい、の緊張をどう解くか。
❌ 完全強制型：「全員月 1 ユースケース投稿が必須」 → 質の低い投稿が大量発生、雰囲気悪化
❌ 完全任意型：「興味ある人が自由に」 → 既存ファンしか動かない、組織全体に広がらない
>4-1住友商事方式（推奨）
- 課長評価に「チームで 1 つ以上の事例共有」を入れる（個人ではなくチーム単位）
- KSF（チャンピオン・LT・ハッカソン）は 強制ではなく「後押し」 として運用
- 義務でなく「機会創出」── 発表したい人にステージを用意
- 評価は加点（できなかったら減点ではない）
>4-2設計のポイント
- KPI 達成プレッシャーをチーム単位に分散することで個人を追い込まない
- 表彰・予算優先などのポジティブインセンティブを主、KPI 連動は補助
- All Hands で経営層が「実験 OK、失敗 OK」を明言し、心理的安全性を確保
計測：KGI - KSF - KPI の階層化
>5-1具体 KPI とレンジの目安
| 指標 | 目安レンジ | 算出例 |
|---|---|---|
| 議事録作成時間削減 | △2-5 時間/月/人 | 100 人 × △3h × 12ヶ月 = △3,600 時間/年 |
| ミーティング時間削減 | △10-20% | 残業代換算で年数千万円 |
| 問い合わせ初動対応時間 | △30-40% | カスタマーサポート |
| 製造・テスト工程時間 | 業種ごとに △ x % | 業種別に測定方法を設計 |
| 発信ユースケース数 | 月 x 件 | Slack 投稿 + LT 発表合算 |
| ユースケース業務適用数 | 四半期 x 件 | 本番運用に乗ったもの（PoC 止まり除外） |
すべてを数字化しようとするとスプレッドシート病にかかる。「測れないが価値あるもの」（部門間の心理的距離が縮まる、若手の発信意欲が高まる、など）も意識的に拾う。
ユースケース集約 → 「第二の脳」化
LT・ハッカソン・Slack で出た雑多なメモは、最初は雑多に集める。最初から綺麗なドキュメントを目指さない。
cookbook（業務別レシピ）／プロンプト集／ワークフローテンプレート／失敗集／導入チェックリスト ── 雑多メモ（Slack / Notion / Obsidian 等）から Codex / Claude Code 等で抽出・構造化していく素材たち。
これは Karpathy が提唱する LLM Wiki の組織版とも言える。
→ 詳しくは Obsidian → LLM Wiki → HTML → AI Deploy で別途解説している。
>6-1重複・矛盾が出たときの捌き方
集約を続けると必ず起きる：同じ業務で複数チームから違うプロンプトが投稿される、片方は「絶対これ」と言い、片方は「いや別案がいい」と言う、同じプロンプトでもチームによって結果が違う。「正解を選んで片方を消す」のではなく「コンテキスト付きで並列保持」が原則。
| 状況 | やりがちな失敗 | 推奨アプローチ |
|---|---|---|
| 重複（複数チームから同じ事例） | 古い方を削除して上書き | 両方残してクロスリンク。Champion が四半期ごとに統合判断 |
| アプローチが異なる | 勝者を即決して片方を消す | 「ケース A / ケース B」と コンテキスト付きで並列掲載（部署・データ規模・制約条件） |
| 同じプロンプトで結果が違う | 「動かない」で報告終わり | 「Known variations」として記録。むしろ最も価値ある情報になる |
組織のユースケースはコンテキスト依存。営業部の使い方とエンジニアの使い方は、同じツールでも別物として正解になりうる。一方を「ベストプラクティス」と決め打ちすると、もう一方を排除して発信意欲を削ぐ。判断材料を全部見せ、決めるのは利用者 ── これは個人 Wiki でも組織 Wiki でも共通の原則。
さらに踏み込めば、同じ人でも状況によって使い方は変わる。だから Wiki の仕事は「正しい分類を作る」ことより、素材として全部積んでおき、各自が自分の現場で意味付けることに近い。意味付けは書く時ではなく 読む時 に起きる ── Champion のキュレーションも、整理より「見つけられる状態に保つ」のが本質。
>6-2運用メカニズム
分類は軽く、検索性は重く、が方針。
- Champion の役割は整理より「索引性」：見つけられる状態を保つだけ。タクソノミーを完璧に整えようとしない
- 四半期 Wiki Day：完全に死んだ事例だけアーカイブ。「正解」を選んで他を消す作業はやらない
- タグは分類でなくヒント：
context:営業/context:エンジニア等は「この事例はこの状況で書かれた」というメモであって、読み手の判断は読み手に委ねる - 日付・モデル名を必須に：半年でモデルが進化し、同じプロンプトの結果が変わる前提で運用
- 議論はスレッドへ、本文は凍結：本文の編集合戦は荒れる。議論は紐付く Slack スレッドや comment 欄で行う
- LLM 検索を前提にする：分類に頼らず「自然文で問い合わせると関連事例が出てくる」状態を作る方が、現場判断に強い
AI プロダクトを提供する側のアプローチ
SaaS ベンダー / AI プロダクトプロバイダー / CSM / ソリューションエンジニア 向け
プロダクト売り＝ KPI コンサル売り
クライアント企業の AI 普及が失敗するとき、原因は実装ではなく導入要件の設計にある場合が多い。プロバイダー側は単にプロダクトを売るのでなく、KPI コンサルを売る必要がある：
月々 ◯ 万円の支払いで、人件費が どれくらい削減 されるか、生産性が どれくらい上がる か
この問いに答えるのがプロバイダーの仕事。これが言語化されないと、
- 要件が決まらない
- 実装が始まらない
- 稟議が通らない（コスト vs 効果が示せない）
の三重苦に陥る。
>7-1クライアントの KGI / OKR を共設計する
プロバイダー側 KGI（GMV 増加）の構造を、3 因子の積に分解する。
つまり提供側の打ち手は「ユースケース密度の最大化」に収束する。ライセンス数を売り込むのではなく、1 社あたりの活用深度を上げることが GMV の伸び代。だからこそ Part 1 で扱った Champion / LT / ハッカソンを、プロバイダー側もサービスとして組み込む：
- 導入時に Champion 制度設計を提案
- 月 1 LT 開催のテンプレート（タイムテーブル・発表フォーマット・評価軸）を配布
- 半年後のハッカソン開催を CSM がリード
これらは契約サービスの一部として組み込める。
OSS 化できない場合の代替アプローチ
OSS の Claude Code / Codex は「運用知の無料配布」で広がった。自社プロダクトを OSS 化できない場合、代替手段が必要：
| 手段 | 機能 |
|---|---|
| テンプレート公開 | cookbook / プロンプト集 / ワークフローテンプレート（運用知の配布） |
| デモ・動画 | 「使い方が見える / 成果が見える」 |
| ケーススタディ | 「再現できる」導入事例 |
| API / SDK 解放 | 外部統合パターンを学べる |
| コミュニティ運営 | ユーザー会・Discord（横の繋がりで発信文化を作る） |
| ★ ハッカソン主催 | 市場側がユースケースを発見するループ |
特に ハッカソンは「ユーザーが自分でユースケースを発見する」場所として強力。社内コミュニティ × 外部ハッカソン両方を回せる。
明日から動くために
導入する側 / 提供する側 共通の実行ガイド
役割別 First Action
何を読んだかではなく、何をやるかが本質。今日中／今週中に動けるレベルまで降ろす：
3 ヶ月 + α ロードマップ
失敗パターン 5 つ
まず、これまで議論してきた 3 つの対立軸を 1 枚に整理しておく。失敗パターンの多くは、この軸のどちらか片側に振り切ったときに発生する。
| 対立軸 | 左：振り切ると失敗 | 右：振り切ると失敗 | 正解 |
|---|---|---|---|
| 強制 vs 自走 | KPI で締め上げ → 自発性が死ぬ | 全部自由 → 何も起きない | 軽い KPI 連動 + 評価インセンティブ |
| KPI vs アグリゲーション | 数字だけ追う → スプレッドシート病 | 集めるだけ → 効果が経営に届かない | KPI で見せ、知識として蓄積 |
| SaaS vs OSS | SaaS だけ → ロックイン / コスト膨張 | OSS だけ → 運用負荷 / 知識属人化 | ユースケース密度で勝負（道具は手段） |
避けるべき典型：
- KSF の「強制」運用：KPI 連動で厳しく回す → 自発性が死ぬ
- 発信文化なし：発表しても評価されない → 発表されない の悪循環
- 経営層が「実験 OK」を明言しない：心理的安全性ゼロ、誰も試さない
- ユースケースが集約されない：イベントは盛り上がるが、Slack や個人の Notion に良いプロンプトが散らばって組織知にならない
- プロバイダー側の KPI 提示不在：導入コストと効果が紐付かず、稟議で詰まる
自然普及ループを組織側／プロバイダー側の双方で設計する
社内 AI 普及の本質は、プロダクトの押し付けではなく自然普及ループの設計にある。揃えるべき 4 要素：
- 発信できる場所（Slack ch / LT / Wiki）
- 発信者が評価される文化（Champion 制度 / 役員プレゼン）
- 小さく試せる仕組み（PoC / ハッカソン / 非機密データから）
- KPI で効果を見える化（時間削減・コスト削減を経営層へ）
加えて、
- 強制と自発性のバランス（軽い KPI 連動 + ポジティブインセンティブ）
- KPI とアグリゲーションを両輪で回す（数字で見せ、知識として蓄積）
- SaaS / OSS の選択ではなく、ユースケース密度で勝負（道具は手段）
「AI を使え」と命令するのではなく、使うと評価され、楽しく、明日の仕事が楽になる設計を、組織側／プロバイダー側の双方が用意する。これが 2026 年以降の社内 AI 普及の核になる。