社内プロンプト集の作り方｜属人化を解消し生成AI活用を現場に定着させる設計・運用ガイド

同じ業務なのに、プロンプトを作る人によって出力がまったく違います

これは、生成AIの社内活用を進める人事・DX推進担当者、各部門で周囲を支援する社内AI推進者、そして部門横断で業務標準化を見ている管理職層が、初期活用の段階で直面しやすい悩みです。

以前は、生成AIに詳しい一部の人が自分なりにプロンプトを作り、うまくいった指示文をチャット履歴や個人メモに残していました。ところが、別の担当者が同じ業務で使おうとすると、前提情報の入れ方、出力形式、確認ルールがそろっておらず、結果として「誰が使うか」で品質が変わってしまいます。

現在は、単に「うまくいったプロンプト」を共有するだけでなく、入力する情報、参照させる社内資料、出力形式、利用条件、人による確認方法まで含めて、業務テンプレートとして再利用する考え方が重要になっています。弊社が提供するKanataでも、プロジェクトライブラリの中にプロンプトライブラリがあり、よく使う指示文を登録して再利用できる構成になっています。

この記事では、社内プロンプト集をどの単位で設計し、テンプレートに何を入れ、誰がレビューして公開・更新するかを整理します。本記事では便宜上「社内プロンプト集」と呼びますが、実務では指示文そのものだけでなく、参照情報やレビュー基準を含む「AI業務テンプレート」として管理することが重要です。目指すのは、詳しい人に毎回聞かなくても、現場が必要なプロンプトを探し、使い、改善提案できる状態です。

ただし、プロンプト集を作るだけでAI活用が定着するわけではありません。教育、レビュー、情報管理、定期的な棚卸しと組み合わせて、はじめて現場で使い続けられる仕組みになります。自社でも「プロンプト共有が個人任せになっている」と感じる方は、現在の業務一覧を思い浮かべながら読み進めてください。

社内プロンプト集とは何か

社内プロンプト集とは、生成AIに対する指示文を、個人のメモではなく組織で再利用できる形に整理したものです。

ここでいうプロンプトとは、生成AIに「何を、どの条件で、どの形式で出力してほしいか」を伝える指示文を指します。社内プロンプト集は、単に便利な指示文を並べた一覧ではありません。誰が、どの業務で、どの情報を入力し、何を参照させ、どの形式で出力し、どこを人が確認するのかまで含めて設計することで、業務に使いやすいテンプレートになります。

たとえば、議事録作成のプロンプトであれば、次のような情報が必要です。

• どの会議に使うのか
• 入力する素材は音声、文字起こし、メモのどれか
• 参照する資料や情報源はあるか
• 出力は「決定事項」「TODO」「論点」「次回確認事項」のどの形式か
• 不明な内容は推測せず「要確認」と書かせるか
• 社外共有前に誰が確認するか

このように、社内プロンプト集は「指示文の置き場」ではなく、「業務の進め方をそろえる仕組み」と考えるほうが実務に合います。

なぜプロンプトの属人化が問題になるのか

生成AIの初期活用では、まず個人が試す段階があります。これは必要なプロセスです。最初から全社ルールを作ろうとすると、現場の実態に合わないテンプレートになりやすいためです。

一方で、個人利用の段階が長く続くと、次のような問題が起きます。

1. 同じ業務でも出力品質がばらつくこと。ある人は「対象読者」「目的」「出力形式」まで細かく指定している一方で、別の人は「いい感じにまとめて」とだけ入力している。この状態では、生成AIの性能差ではなく、指示の出し方の差で結果が変わってしまいます。
2. 良いプロンプトが共有されないこと。せっかくうまくいった指示文があっても、個人のチャット履歴やローカルメモに残っているだけでは、他の社員は使えません。結果として、社内のあちこちで似たようなプロンプトを作り直すことになります。
3. レビューされていないプロンプトが広がること。人事評価、契約確認、顧客対応、社外向け文書などは、出力内容に誤りがあると影響が大きい領域です。便利だからという理由だけで未確認のプロンプトが拡散すると、誤った判断や不適切な表現につながる可能性があります。

そのため、社内プロンプト集では「便利かどうか」だけでなく、「誰が見ても安全に使えるか」「どの範囲なら使ってよいか」まで整理する必要があります。2026年8月時点で最新版の総務省・経済産業省のAI事業者ガイドライン（第1.2版）でも、AI活用における透明性、アカウンタビリティ、教育・リテラシーなどの重要性が示されています。

社内プロンプト集は業務単位で設計する

社内プロンプト集を作るときは、最初から部門別に細かく分けすぎないことが大切です。おすすめは、まず業務単位で整理する方法です。

部門単位で整理すると、「営業部のプロンプト」「人事部のプロンプト」のように管理しやすく見えます。しかし実際には、メール下書きや議事録作成のように、複数部門で共通して使えるものも多くあります。

まずは全社共通で利用頻度の高い業務から整備し、その後に部門固有のプロンプトへ広げるほうが、定着しやすくなります。

初期段階では、数を増やしすぎないことも重要です。想定例として、最初の1か月は10〜20本程度に絞り、利用頻度の高いものから公開します。数が多すぎると、現場は探せなくなり、結局「詳しい人に聞く」状態に戻ってしまいます。

プロンプトテンプレートに入れるべき項目

社内プロンプト集のテンプレートには、少なくとも次の項目を入れておくと運用しやすくなります。

テンプレート名

用途が一目で分かる名前にします。

「便利プロンプト」「文章作成用」のような名前では、何に使うのか分かりません。「議事録作成_定例会議用」「社外メール下書き_日程調整用」「提案書構成_BtoB商談用」のように、業務と用途が分かる名前にします。

想定利用者

誰が使うプロンプトかを明記します。

たとえば「全社員向け」「営業担当者向け」「人事担当者向け」「マネージャー向け」などです。利用者が明確になると、出力のトーンや前提情報も決めやすくなります。

利用シーン

どの業務の、どのタイミングで使うかを書きます。

たとえば、議事録作成であれば「会議終了後、文字起こしデータまたはメモをもとに社内共有用の議事録を作るとき」のように具体化します。

あわせて、必要に応じて利用するAI環境や機能も記録します。同じ指示文でも、利用するAIモデルや検索・ファイル参照などの機能によって結果が変わることがあるためです。

入力項目

利用者が差し替える情報を明示します。

# 入力情報
- 会議名：
- 日時：
- 参加者：
- 会議メモ：
- 共有先：

このように入力欄を決めておくと、使う人による情報の抜け漏れを減らせます。

AIに社内規程、FAQ、商品資料、過去の議事録などを参照させる場合は、参照元と更新日も管理します。「一般知識で回答してよいのか」「指定した資料だけを根拠にするのか」を決めておくと、回答のばらつきを抑えやすくなります。

出力形式

生成AIに何を、どの形で出してほしいのかを指定します。

「箇条書き」「表形式」「メール本文」「議事録フォーマット」「比較表」「FAQ形式」など、出力形式を固定すると、後工程で使いやすくなります。

Kanataの日常業務ベストプラクティスガイドでも、プロンプト設計では「役割」「目的」「対象読者」「前提情報」「出力形式」「制約」を整理する考え方が示されています。

制約条件

制約条件は、出力品質を安定させるために重要です。

• 300字以内でまとめる
• 専門用語には補足を入れる
• 不明な内容は推測せず「要確認」と書く
• 数値、日付、固有名詞は原文を優先する
• 社外向けに断定的な表現を避ける

特に業務利用では、「分からないことを無理に答えさせない」設計が重要です。生成AIに何でも答えさせるのではなく、不確かな情報は止めるルールを入れることで、レビューしやすくなります。

レビュー観点

最後に、人が確認すべき観点を明記します。

• 数字は原典と一致しているか
• 固有名詞に誤りはないか
• 社外秘情報が含まれていないか
• 表現が強すぎないか
• 読み手に誤解を与えないか
• 最終判断が必要な内容をAIが断定していないか

プロンプト集は、AIに任せるためのものではなく、人が確認しやすくするためのものでもあります。

社内プロンプト集のテンプレート例

ここでは、複数部門で使いやすいテンプレート例を紹介します。自社で利用する際は、社内ルール、情報管理方針、利用するAIツールの仕様に合わせて調整してください。

議事録作成プロンプト

あなたは社内会議の議事録作成を支援するアシスタントです。
以下の会議メモをもとに、社内共有用の議事録を作成してください。


# 入力情報
- 会議名：
- 日時：
- 参加者：
- 会議メモ：


# 出力形式

## 会議概要

## 決定事項

## TODO
| 担当 | 内容 | 期限 |

## 議論された論点

## 次回確認事項


# 制約
- 不明な内容は推測せず「要確認」と書く
- 決定事項と意見を混同しない
- TODOには担当者と期限を入れる
- 期限が不明な場合は「期限：要確認」と書く

社外メール下書きプロンプト

あなたはBtoBビジネスメールの下書きを支援するアシスタントです。
以下の条件をもとに、社外向けメール文を作成してください。

# 送り先
- 会社名：
- 相手の役職：
- 相手との関係性：

# 目的
- 依頼／報告／日程調整／お礼／お詫び など：

# 伝えたい要点
- 
- 
- 

# 出力形式
- 件名案を3つ
- メール本文を1案
- 送信前の確認ポイントを3つ

# 制約
- 500字以内
- 丁寧だが堅すぎない文体
- 過度な謝罪や断定表現を避ける
- 事実関係が不明な点は「要確認」とする

提案書構成プロンプト

あなたはBtoB提案書の構成を支援するアシスタントです。
以下の情報をもとに、提案書の構成案を作成してください。

# 顧客情報
- 業界：
- 企業規模：
- 想定課題：
- 提案するサービス：

# 出力形式
1. 表紙タイトル案
2. 顧客課題の整理
3. 課題の背景
4. 提案内容
5. 導入ステップ
6. 想定効果
7. リスクと対策
8. 次のアクション

# 制約
- 想定効果の数値は実績ではなく「想定例」と明記する
- 顧客固有の情報が不足している場合は仮説として書く
- 誇大な表現を避ける

社内問い合わせ回答プロンプト

あなたは社内問い合わせ対応を支援するアシスタントです。
以下の質問に対し、社内向けの回答案を作成してください。

# 社員からの質問
{質問文}

# 参照情報
{規程・FAQ・マニュアルの該当箇所}

# 出力形式
- 回答
- 根拠となる情報
- 追加で確認すべき事項
- 担当部署に確認が必要な場合の案内文

# 制約
- 参照情報にない内容は推測しない
- 規程上の根拠がない場合は「担当部署に確認」と書く
- 社員に伝わる平易な表現にする

レビュー・公開フローを決める

社内プロンプト集は、作成者が自由に登録できるだけでは品質を保てません。最低限のレビュー・公開フローを決めておく必要があります。

下書き

現場担当者やAIチャンピオンが、実際に使って効果があったプロンプトを下書きします。

この段階では完璧でなくても構いません。現場で使われた実例をもとにすることで、実務に合ったテンプレートになりやすくなります。

セルフチェック

作成者が、次の観点で確認します。

• 入力項目は分かりやすいか
• 出力形式は業務で使いやすいか
• 不明点を推測させないルールがあるか
• 機密情報や個人情報の扱いに問題がないか
• 利用範囲が明確か

あわせて、実際の業務に近い複数の入力例でプロンプトを試します。一度期待どおりの回答が出ただけで「良いプロンプト」と判断せず、入力内容を変えても必要な項目が出力されるか、不明な情報を勝手に補完しないか、レビューしやすい形式になっているかを確認します。

業務レビュー

その業務に詳しい担当者または部門責任者が、内容の妥当性を確認します。

たとえば、営業プロンプトであれば営業責任者、人事プロンプトであれば人事担当者、問い合わせ対応であれば所管部門が確認します。

情報管理レビュー

必要に応じて、情報システム、法務、総務、人事などが確認します。

特に、個人情報、契約、評価、顧客情報、未公開情報に関わるプロンプトは、業務レビューだけでは不十分です。入力してよい情報、入力してはいけない情報を明記してから公開します。

公開

公開時には、テンプレート名、カテゴリ、対象利用者、最終更新日、管理者をそろえます。

ツール上でプロンプトを登録・検索できる仕組みがある場合は、カテゴリ名や命名規則を統一しておくと、利用者が探しやすくなります。Kanataを利用する場合は、プロジェクトライブラリからプロンプトライブラリを開き、よく使う指示文を登録して、プロジェクト内で再利用する運用が考えられます。

改訂・廃止

公開後も、使われていないプロンプトや古くなったプロンプトは見直します。

想定例として、月1回30分、各部門のAIチャンピオンが集まり、次の観点で棚卸しを行います。

• よく使われているプロンプトはどれか
• 出力品質に課題があるものはどれか
• 重複しているプロンプトはないか
• 古い業務ルールのままになっていないか
• 利用するAIやモデルの変更後も、想定どおり動作しているか
• 新しく追加すべき業務はあるか

生成AIサービスやモデルは更新されるため、一度調整したプロンプトが将来も同じ結果を出すとは限りません。モデルや利用機能を変更した際には、重要なテンプレートを再テストします。

プロンプト集は「作って終わり」ではなく、使いながら育てるものです。

運用体制をどう作るか

社内プロンプト集の運用では、役割分担が重要です。

全体オーナー

人事部門、DX推進部門、情報システム部門などが担うことが多い役割です。

主な仕事は、全体ルールの策定、カテゴリ設計、公開基準、棚卸しの運用です。個別プロンプトの中身をすべて作る必要はありません。

ライブラリ管理者

プロンプトの登録、命名、カテゴリ整理、重複確認を行います。

Kanataのようにプロジェクト単位でライブラリを管理する場合は、プロジェクトごとに管理者を置くと運用しやすくなります。Kanataの資料では、プロジェクトは業務単位で人・データ・アプリをまとめる入れ物として説明されています。

業務レビュアー

各部門の業務責任者や実務に詳しい担当者が担います。

プロンプトの出力が、実際の業務フローや社内ルールに合っているかを確認します。

利用者

現場社員です。

利用者には、プロンプト集をただ使ってもらうだけでなく、「使いにくかった点」「追加してほしいテンプレート」「出力がずれたケース」をフィードバックしてもらう導線を用意します。

AIチャンピオン

各部門で生成AI活用を支援する人です。

現場の困りごとを拾い、使えるプロンプトに変換し、改善提案を出す役割を担います。人事やDX推進だけでは拾いきれない現場の実務を、プロンプト集に反映する存在です。

社内共有時に必ず入れる注意事項

社内プロンプト集には、便利な使い方だけでなく、注意事項もセットで入れる必要があります。

個人情報・機密情報は、社内ルールと利用するAIサービスの条件に従って扱う

氏名、住所、連絡先、社員番号、顧客の個人情報、未公開の財務情報などを入力できるかどうかは、利用するサービスの契約、データの取り扱い、社内規程によって異なります。会社が定めた利用範囲を確認し、入力が認められていない情報は入力しないか、必要に応じてマスキングします。

プロンプトテンプレートには、入力例として実名や実データを入れないようにします。必要な場合は、次のように置き換えます。

氏名

{担当者A}

会社名

{顧客企業}

金額

{契約金額}

日付

{提出期限}

部署名

{対象部署}

出力をそのまま社外提出しない

生成AIの出力は、下書きとして扱います。

Kanataの日常業務ベストプラクティスガイドでも、AI出力は必ず人がレビューしてから外に出すこと、数字や引用は裏取りすることが基本原則として示されています。

特に、社外メール、提案書、契約関連文書、プレスリリース、顧客向け回答は、必ず人が確認します。NISTの生成AI向けリスク管理プロファイルでも、生成AIには虚偽・不正確な情報、情報セキュリティ、プライバシーなど複数のリスクがあることが整理されています。

数値・日付・固有名詞は原典確認する

生成AIは、もっともらしい文章を作る一方で、数字や日付、固有名詞を誤ることがあります。

そのため、プロンプト側に次のような制約を入れておくと安全です。

数値、日付、固有名詞は入力情報を優先してください。
入力情報にない場合は推測せず「要確認」と書いてください。

法務・人事・評価・契約に関わる内容は専門部署が確認する

社内プロンプト集に、人事評価コメント、契約書レビュー、規程回答などを入れる場合は、必ず専門部署の確認を通します。

生成AIは判断を補助できますが、最終判断者にはなれません。ここを曖昧にすると、便利さよりもリスクが大きくなる可能性があります。

Kanataで社内プロンプト集を運用する場合の考え方

社内プロンプト集は、スプレッドシート、社内Wiki、ナレッジ管理ツール、AI活用基盤など、さまざまな方法で管理できます。重要なのは、社員が必要なプロンプトを探しやすく、更新履歴や管理者が分かる状態にすることです。

Kanataを使う場合は、プロジェクト単位で整理すると考えやすくなります。

Kanataでは、スペース、プロジェクト、アプリ、ライブラリという概念があり、プロジェクトごとに利用者・データ・アプリを整理できます。プロジェクトライブラリには、AIライブラリ、プロンプトライブラリ、学習データライブラリがあり、プロンプトライブラリにはよく使う指示文を登録できます。

たとえば、次のような整理が考えられます。

また、学習データライブラリと組み合わせる場合は、参照させる資料の更新日や正確性にも注意が必要です。古い規程や過去の提案書を参照したまま回答すると、現在の運用とずれる可能性があります。

そのため、プロンプトだけでなく、参照データも含めて棚卸しすることが大切です。

社内プロンプト集を定着させるチェックリスト

社内プロンプト集を公開する前に、次の項目を確認します。

設計チェック

• 業務単位でカテゴリ分けされているか
• 利用頻度の高い業務から整備しているか
• テンプレート名だけで用途が分かるか
• 想定利用者が明記されているか
• 入力項目が具体的に書かれているか
• 参照情報や情報源が必要な場合、その範囲が明記されているか
• 出力形式が指定されているか
• 制約条件が明確か

安全性チェック

• 個人情報や機密情報の入力ルールがあるか
• 不明な情報を推測させない指示があるか
• 数字・日付・固有名詞の確認ルールがあるか
• 社外提出前の人によるレビューが明記されているか
• 法務・人事・契約関連の確認フローがあるか

運用チェック

• 管理者が決まっているか
• レビュアーが決まっているか
• 最終更新日が分かるか
• 改善提案の出し方があるか
• 月次または四半期で棚卸しする予定があるか
• AIやモデルの変更時に重要なプロンプトを再テストできるか
• 使われていないプロンプトを削除・統合できるか

まとめ：プロンプト集は「作る」より「使われ続ける」ことが重要

社内プロンプト集は、生成AI活用を個人の工夫から組織の仕組みに変えるための土台です。

ただし、最初から完璧なプロンプト集を作る必要はありません。まずは、議事録、メール、要約、提案書、問い合わせ対応など、利用頻度が高く、効果を確認しやすい業務から始めることが現実的です。

大切なのは、次の3点です。

1. 業務単位で設計すること
2. テンプレートに入力項目、参照情報、出力形式、制約、レビュー観点を入れること
3. 公開後も棚卸し、再テスト、改善、廃止を続けること

プロンプト集は、生成AIを「一部の詳しい人だけが使うもの」から、「現場が探して使える業務基盤」へ変えるための仕組みです。

まずは、社内でよく使われているプロンプトを10本集めるところから始めてみてください。その10本を、業務名、利用者、入力項目、出力形式、確認ルールつきで整理するだけでも、プロンプト共有の第一歩になります。

Q&A：社内プロンプト集づくりでよくある質問