生成AI を業務で使ってもらうために、社内向けの Playbook を作りたい。でも「プロンプト集」と「業務手順書」の境界が分からず、Notion のページを立ち上げたはいいものの、中身が3ページで止まっている。あるいは、外部業者が作ってくれた PDF が本棚で埃を被っている。DX 推進担当のあなたは、Playbook を実務で回る道具にしたいのに、動線が見えていないのではないでしょうか。
Playbook が育つか腐るかは、初版の構成、更新サイクル、オーナー設計、の3点で決まります。実務で使える具体的なフォーマットまで、順に整理します。
Playbook が腐る3つの理由
よくある失敗パターンを先に共有します。この3つを避ける設計を初版に組み込みます。
| 理由 | 症状 | 原因 |
|---|---|---|
| PDF で配布 | 1回配って以後更新されない | 更新の仕組みがない、フィードバック経路がない |
| 汎用的すぎる | 「プロンプトは具体的に書きましょう」で終わる | 自社の業務プロセスに紐付いていない |
| オーナー不在 | 誰も見なくなり、質問しても返事がない | 更新責任者が決まっていない |
初版に必要な5つのセクション
Playbook の初版は、次の5つのセクションで構成します。分厚くする必要はなく、業務ドメインごとに10〜20プロンプトあれば十分です。
| セクション | 内容 | 初版の分量 |
|---|---|---|
| ① 使う前提 | 対象ツール（Copilot / ChatGPT / Claude 等）、権限、社内ルール、機密情報の扱い | 1〜2ページ |
| ② 業務別プロンプト集 | SOP の各段階で使うプロンプト、業務別に整理 | 業務ごとに 5〜10 プロンプト |
| ③ 失敗パターン集 | うまくいかなかったプロンプトと、その原因、代替案 | 10〜20 件 |
| ④ Q&A | よくある質問と一次回答 | 10〜15 件 |
| ⑤ 相談経路 | 困ったとき誰に聞くか、どこまで自分で試すか | 1ページ |
業務別プロンプトの整理フォーマット
プロンプトを羅列しても使いこなせません。次のフォーマットで整理すると、担当者が業務の流れの中で見つけやすくなります。
| 項目 | 内容 |
|---|---|
| 業務名 | 「商談前の会社調査」など、SOP と一致する業務名 |
| 使うタイミング | 業務の何の直前・直後で使うか |
| プロンプト本文 | コピペで使える完全な文。変数部分は【】で囲む |
| 期待される出力例 | 実際に流したときの出力の例（要約でOK） |
| チューニング余地 | 業界・案件・顧客ごとに変える箇所と、その変え方 |
| よくあるハマり | この用途でありがちな失敗と回避策 |
この形にしておくと、Playbook を見た担当者が「自分の業務のこの瞬間に、このプロンプトをこう変えて使う」まで自力で辿り着きます。汎用的なプロンプト集では、この最後の一歩が渡れません。
失敗パターン集の書き方
成功プロンプトだけでなく、失敗パターン集を持つのが Playbook が育つ秘訣です。担当者が試して「思ったより使えないな」と離脱する前に、Playbook で先回りしておきます。
| 項目 | 内容 |
|---|---|
| 失敗プロンプトの実例 | 実際に試して期待した回答が出なかったプロンプト |
| 何が期待外れだったか | 「精度が低い」「フォーマットが違う」「情報が古い」など具体的に |
| 原因の分析 | プロンプトの書き方 / データ側の問題 / モデルの限界 のどれか |
| 回避策 or 代替 | 書き方を変えれば解決するのか、別の手段が必要か |
Playbook のオーナー設計
Playbook が更新され続けるには、オーナーが明確である必要があります。オーナーは各セクション単位ではなく、業務ドメイン単位で持ちます。
| 業務ドメイン | オーナー候補 | 更新頻度 |
|---|---|---|
| 営業 | 営業部門の社内推進役 | 週1件は更新 |
| 経理 | 経理部門の社内推進役 | 月2件は更新 |
| 法務 | 法務部門の社内推進役 | 月1件は更新 |
| 共通（Q&A、失敗パターン） | AI推進担当 | 月2件は更新 |
更新サイクルの設計
更新は、次の3つの経路で起きるように動線を作ります。
| 経路 | 頻度 | 動線 |
|---|---|---|
| 成功事例の追加 | 週次 | 業務で試してうまくいったパターンを、担当者が Slack / Teams で共有 → 推進役が Playbook に転載 |
| 失敗パターンの追加 | 随時 | 「試したが期待外れ」の相談があるたびに、原因と回避策を Playbook 化 |
| 月次同期会での棚卸し | 月次 | 他部門の成功事例で自部門にも適用できるものを Playbook に追加 |
Playbook のフォーマットと置き場所
フォーマットは、単発の PDF を避けます。更新できる形が必須です。
| 候補 | 利点 | 注意点 |
|---|---|---|
| Notion | 階層構造、更新履歴、コメント機能が優秀 | 社内標準ツールが別なら選定不可 |
| Confluence | エンタープライズで一般的、権限管理も柔軟 | 検索性がやや弱い |
| SharePoint | M365 環境なら追加コストなし | 階層が深くなると迷子になりやすい |
| 社内 wiki（自前） | 完全に社内制御 | 運用工数が高い |
大事なのは、担当者が「業務の流れの中で3クリック以内に辿り着ける」場所に置くことです。深い階層に埋めると、実質的に使われません。
初版から本格運用への移行
Playbook 初版を作ってから、本格運用に載るまでは3〜6ヶ月かかります。焦らず段階を踏みます。
| 段階 | 目安 | 指標 |
|---|---|---|
| 初版 | 1〜2ヶ月 | 業務ドメイン3つで各10プロンプト、失敗パターン10件 |
| 週次更新の定着 | 3〜4ヶ月 | 週1件以上のペースで追加される |
| 業務の流れに埋め込まれる | 5〜6ヶ月 | 担当者が業務で自然に Playbook を開くようになる |
まとめ
プロンプト Playbook は、業務別・失敗パターン付き・オーナー明確・週次更新、の4条件で育ちます。PDF で配って終わり、汎用的な内容、オーナー不在、の3つを避けた初版が、その後の育つ Playbook を作ります。焦って厚くせず、3〜6ヶ月で本格運用に載せる時間軸で組みます。
「うちの場合はどこから手をつけるべきか」の見立てを掴みたい場合は、AI浸透支援 by DE-STKのAI浸透スコア診断（2週間・25万円）が入口として使えます。現状の利用実態、構造的な原因、次に打つべき手の候補まで、社内の投資判断に耐える粒度でお出しします。
あわせて読みたい
- 生成AI導入後の「使われない」を解消する：現場浸透の設計と実装
- 生成AIの社内推進役の設計：兼任1名で回らない構造をどう解体するか
- AI浸透スコア診断に含めるべき10項目：入る前に確認する優先順位
- Microsoft Copilotが営業部門で使われない典型3パターンと構造的原因
- ChatGPT Enterpriseが導入されたのに使われない：組織側の3つのボトルネック
よくある質問
Q. Playbook の初版を外部業者に作ってもらうのはどうですか？
A. 初版のスケルトンと業務別プロンプトのたたきまでは、外部業者と一緒に作る価値があります。しかし、更新サイクルに乗せるフェーズからは、社内推進役がオーナーで回さないと定着しません。「作ってもらって終わり」ではなく、「作りながら社内に技術移転する」設計にします。
Q. 失敗パターン集を作ると、AI に対するネガティブな印象が広がりませんか？
A. 逆です。失敗パターンを公開することで、担当者が「試して思ったより使えなかった」の経験を「よくあること」として受け入れられます。1度離脱すると再挑戦しない担当者を減らす効果が最も大きいのが、失敗パターン集です。
Q. プロンプトの機密性はどう扱いますか？
A. Playbook 内のプロンプト例には顧客名・案件名・金額を含めない設計にします。テンプレート化して、実業務で使うときに担当者が実データに置き換える、という運用で機密漏洩リスクを抑えられます。