「プロンプトを書ける人だけが得をする」状態を解消するには、研修だけでなく、良い使い方を社内資産として配る仕組みが必要だ。社内プロンプトライブラリは、個人の工夫を全社の再現可能な型に変える場所である。この記事では、情シス・HR寄りのDX推進室が、現場の判断力を残しながら、設計・収集・配布・更新を回す方法を整理する。研修後に「結局、各自で工夫して」と戻さないための、最小限の運用設計である。
1. なぜ社内プロンプトライブラリが必要か
生成AIの全社展開で最初に起きるのは、使う人と使わない人の二極化だ。30代の研修講師やDX推進担当が勉強会を開いても、翌月には「営業のAさんだけ資料作成が速い」「経理はまだ検索に使う程度」という差が残りやすい。差の正体は能力ではなく、良い依頼文に触れる機会の差である。
150名規模のSaaS企業D社では、経理が請求差異の確認文、営業が商談後メール、カスタマーサクセスが解約兆候の要約プロンプトを個別に溜めていた。便利な一方、表現や確認項目が人ごとに違い、上長レビューで差し戻しが増えた。ライブラリ化後は、対象業務のAI下書き時間が1人月20時間から10時間前後に下がり、品質ブレも見つけやすくなった。研修担当者にとっても、個別質問に毎回答えるより、良い例を更新して配るほうが負荷を抑えやすい。
2. ライブラリの4階層設計
プロンプトライブラリは、すべてを同じ棚に入れると使われなくなる。おすすめは4階層だ。第一に全社共通。議事録、社内FAQ、稟議の要約など、部門をまたいで使う型を置く。第二に部門固有。経理の月次チェック、営業の提案準備、CSの問い合わせ分類のように、専門語や判断基準があるものだ。
第三にチーム個別。エンタープライズ営業やオンボーディング担当など、業務粒度が細かい単位で管理する。第四に個人ドラフト。未検証のアイデアを置き、良いものだけ上位階層へ昇格させる。Claude Projectsは、関連資料と会話を案件単位でまとめる作業部屋のような機能。Claude Skillsは、決まった手順を再利用しやすくする業務レシピのような機能。RAGは、社内文書を検索して根拠としてAIに渡す仕組みである。これらを使う場合も、置き場所と責任者を先に決める。階層を分ける目的は統制だけではない。現場が「これは全社で守る型」「これは自分の実験」と迷わず判断できるようにするためである。
3. 収集→審査→公開→更新の運用フロー
運用は「収集、審査、公開、更新」を月次で回す。収集は各部門のAI推進リーダーが担当し、Slackの専用チャンネルやフォームで、用途、入力例、出力例、注意点を集める。審査はDX推進室と業務オーナーが行い、機密情報、誤解を招く表現、法務・労務・会計判断の越権がないかを見る。公開先はNotion、Confluence、Googleドライブなど、既存のナレッジ基盤に寄せるのが現実的だ。
D社では3ヶ月で約120本を登録し、月次レビューは30本前後に絞った。経理は請求書照合、営業は業界別ヒアリング、CSは問い合わせ一次分類を中心に蓄積した。各プロンプトには、オーナー、最終更新日、使ってよいデータ、期待する出力、失敗例を付けた。個別最適のほうが速い場面もあるため、公開審査中でも個人ドラフトは使える。ただし、全社共有するものだけはレビュー済みに限定するのが線引きになる。更新依頼は週次で受け付け、公開日は月1回にまとめると、現場の速度と管理側の確認工数を両立しやすい。
4. 失敗例と回避策
失敗の一つ目は、テンプレ集を作って終わることだ。プロンプトは業務手順とセットでないと、現場はどこを変えてよいか分からない。二つ目は更新されず化石化すること。料金表、商品名、社内規程が変わる会社では、古いテンプレのほうが危ない場合もある。D社は四半期ごとに棚卸しし、利用ゼロのもの、差し戻しが多いもの、参照資料が古いものを停止候補にした。
三つ目は機密情報の混入だ。顧客名、未公開の価格、個人情報を例文に入れると、研修資料として配っただけでもリスクになる。例文は匿名化し、社外秘データを使うプロンプトには「入力前に顧客名を削る」などの確認文を入れる。テンプレ化しすぎると現場の判断力が落ちる、という懸念も妥当だ。だからこそ、固定するのは目的、制約、確認観点までにし、結論や提案内容は利用者が判断する余白を残す。
社内プロンプトライブラリは、AIに詳しい数名を増やす施策ではなく、全社員が安全に試せる土台を作る施策である。最初から完璧な棚を目指すより、30本程度から始め、レビューで育てるほうが定着しやすい。コアネストはClaude研修と運用伴走を通じて、初回研修、部門別ワークショップ、月次レビュー会の設計まで、現場の業務に合うライブラリ設計を支援している。自社で何から整えるべきか迷う場合は、まず無料診断で現状を棚卸ししてほしい。
