ゼロから作る社内AIプロンプト集：命名規則・版管理・評価軸

ChatGPTやClaude、Geminiといった生成AIがビジネスの現場に浸透して数年が経ちました。皆さんのオフィスでは、AIを使いこなせていますか？

「人によってAIの出力クオリティに差がありすぎる」

「以前うまくいった指示文（プロンプト）が見当たらない」

「担当者が辞めたら、AI活用のノウハウも消えてしまった」

もし一つでも当てはまるなら、あなたの組織に必要なのは、高価なAIツールを新たに導入することではありません。今あるノウハウを形式知に変え、組織の資産として蓄積する**「社内プロンプト集」**の構築です。

プロンプトとは、AIに対する「指示書」のことです。優秀な社員が頭の中に持っている「AIを意のままに操るコツ」を可視化し、誰でも再現できるように管理する仕組み。これさえあれば、新入社員でもベテランと同じレベルのアウトプットを、AIを使って瞬時に出せるようになります。

本記事では、単なる「便利なフレーズ集」で終わらせないための、エンジニアリング視点を取り入れた本格的なプロンプト管理手法を解説します。具体的には、「ファイル名の付け方（命名規則）」「更新履歴の残し方（版管理）」「良し悪しの決め方（評価軸）」の3つのステップです。

非エンジニアの方にも分かりやすく、明日からExcelやNotionですぐに始められる実践的な内容に落とし込んでお届けします。

---

なぜ「プロンプト集」を作ると業務が変わるのか

具体的な作り方に入る前に、なぜこの手間をかける必要があるのか、そのメリットを明確にしておきましょう。これは社内のメンバーに協力を仰ぐ際の説得材料にもなります。

1. 業務品質の均一化（属人化の排除）

同じ「議事録作成」でも、Aさんは「要点を箇条書きにして、ネクストアクションを明確にして」と指示し、Bさんは単に「要約して」と指示しているかもしれません。これでは成果物の質に雲泥の差が出ます。

検証済みの「正解プロンプト」を共有することで、誰がボタンを押しても80点以上の合格ラインを超えられるようになります。

2. 時間コストの削減

「あの時、なんて指示したら上手くいったっけ？」と過去のチャット履歴を検索する時間は無駄です。また、ゼロから指示文を考える時間も削減できます。ライブラリからコピー＆ペーストし、必要な箇所だけ書き換える運用にすれば、作業時間は数分の一に短縮されます。

3. AIモデルのアップデート対策

生成AIは頻繁にアップデートされます（例：GPT-4からGPT-4oへ）。モデルが変わると、同じプロンプトでも回答のニュアンスが変わることがあります。プロンプトを管理していれば、「旧モデルではOKだったが、新モデルでは修正が必要」といった検証がスムーズに行え、業務停止のリスクを最小限に抑えられます。

---

ステップ1：検索性を高める「命名規則（ネーミングルール）」

プロンプト集を作り始めると、すぐに直面するのが「どれが最新で、どれが何のプロンプトか分からない」という問題です。「議事録要約_最新.txt」「議事録要約_改.txt」のようなファイル名が散乱するのは避けなければなりません。

エンジニアがプログラムコードを管理する際に行うルールを参考に、誰が見ても中身が想像できる命名規則を制定しましょう。

推奨フォーマット

ファイル名やタイトルは、以下の要素をアンダースコア（_）やスラッシュ（/）で繋いで構成することをおすすめします。

【業務カテゴリ】_【具体的なタスク】_【対象モデル】_【バージョン】

それぞれの要素を詳しく解説します。

1. 業務カテゴリ（大分類）

どの部署、あるいはどの業務領域で使うものかをアルファベット2〜3文字、または短い日本語で定義します。

• MKT（マーケティング）
• HR（人事）
• DEV（開発）
• SALES（営業）
• GEN（全般・General）

2. 具体的なタスク（中分類）

そのプロンプトが「何をするものか」を動詞を含めて明確にします。

• BlogWriting（ブログ執筆）
• CodeReview（コードレビュー）
• EmailReply（メール返信）
• MeetingSummary（会議要約）

3. 対象モデル

AIモデルによって得意・不得意があります。「これはGPT-4用」「これはClaude 3.5 Sonnet用」と明記することが重要です。

• GPT4
• CL35（Claude 3.5）
• GemPro（Gemini Pro）

4. バージョン番号

必ずバージョン番号を末尾につけます。日付ではなく「v1.0」「v1.1」のような数字管理が推奨されます（詳細は後述の「版管理」で解説します）。

命名の実例

これらを組み合わせると、以下のような名前になります。

• MKT_メルマガ作成_GPT4_v2.0
• HR_採用面接質問案_Claude3_v1.0
• SALES_商談議事録要約_Gemini_v1.2

タグ付けによる管理（NotionやExcelの場合）

ファイル名ですべてを表現するのが難しい場合、管理ツール（NotionやAirtableなど）の「タグ」機能を活用します。以下の項目をタグとして設定しておくと、後からフィルタリングしやすくなります。

• InputType: テキスト、PDF、CSV、画像
• Tone: フォーマル、フレンドリー、箇条書きのみ
• Difficulty: 初級者向け、要編集（上級者向け）

---

ステップ2：品質を守る「版管理（バージョンコントロール）」

「版管理」とは、いつ、誰が、なぜ変更を加えたのかを記録し、いつでも過去の状態に戻せるようにしておく手法のことです。

AIのプロンプトは、一文字変えるだけで出力が劇的に変わる繊細なものです。「なんとなく修正したら、以前より悪くなってしまった」という事態を防ぐために、バージョン管理は必須です。

バージョン番号の付け方（セマンティックバージョニングの応用）

ソフトウェア開発で使われる考え方を応用し、以下のように番号を振ると管理しやすくなります。

vX.Y.Z （例：v1.2.0）

• X（メジャーバージョン）: プロンプトの構造を根本から変えた場合。
  • 例：命令文だけの構成から、Few-shot（入力例と出力例のセット）を加えた構成に大幅変更した。
• Y（マイナーバージョン）: 機能を少し追加・修正した場合。
  • 例：出力フォーマットに「英語訳」を追加した。トーンを「丁寧」から「親しみやすく」に変更した。
• Z（パッチバージョン）: 誤字脱字の修正や、微調整。
  • 例：言い回しを少し変えただけ。

変更履歴（チェンジログ）に残すべき3つの要素

バージョンを更新する際は、必ず以下の3点を記録します。これを怠ると、後で「なぜ変えたのか」が分からなくなります。

1. 変更内容: 具体的にどこを変えたか（例：「出力条件」に300文字以内という制約を追加）。
2. 変更理由: なぜ変える必要があったか（例：長文すぎて読むのが大変だというフィードバックがあったため）。
3. 検証結果: 変えた結果どうなったか（例：文字数は減ったが、重要な情報が抜け落ちていないことを確認済み）。

管理ツールの具体例

専用のツールを入れる必要はありません。まずは身近なツールから始めましょう。

Excel / Googleスプレッドシートの場合

1行を1つのプロンプトバージョンとして扱います。

• A列：ID（命名規則に従った名前）
• B列：バージョン
• C列：プロンプト本文（セル内で改行）
• D列：変数（ユーザーが入れるべき箇所。例：{会議録} {ターゲット}）
• E列：変更履歴・備考
• F列：作成者

Notionの場合

データベース機能を使います。プロンプトごとにページを作成し、そのページ内のプロパティでバージョンやステータス（Draft、Review、Approvedなど）を管理すると非常に見やすくなります。過去のバージョンはページ履歴機能で追うか、下部にアーカイブとしてテキストを残します。

Git / GitHub（エンジニア向け）

開発チームであれば、プロンプトをテキストファイル（.txtや.json）としてリポジトリで管理するのが最適です。差分（Diff）が明確に分かるため、プロンプトエンジニアリングには最強のツールとなります。

---

ステップ3：良し悪しを判断する「評価軸（エバリュエーション）」

プロンプトを作っていて一番悩むのが、「これで完成でいいのか？」「もっと良くなるのではないか？」という終わりなき問いです。これを解決するのが「評価軸」の設定です。

料理に例えるなら、「美味しい」という曖昧な評価ではなく、「塩分濃度」「焼き加減」「盛り付け」といった具体的なチェック項目設けるイメージです。

定量評価と定性評価

AIの出力を評価するには、大きく分けて2つの視点があります。

1. 定量評価（数値で測れるもの）

これらは客観的に判定できるため、◯×チェックリスト形式で管理できます。

• フォーマット遵守率: 指定したJSON形式やCSV形式で出力されているか。
• 文字数制限: 指定した文字数（例：200文字以内）に収まっているか。
• 禁止ワード: 使ってはいけない言葉が含まれていないか。
• 応答速度: 業務に支障のない速度で返ってくるか。

2. 定性評価（人の感覚で測るもの）

こちらは主観が入るため、1〜5段階のスコアで評価することが一般的です。

• 正確性（Accuracy）: 嘘（ハルシネーション）が含まれていないか。事実に基づいているか。
• 有用性（Usefulness）: ユーザーの意図を汲み取っているか。実務でそのまま使えるレベルか。
• 安全性（Safety）: 差別的表現やバイアス、攻撃的な内容が含まれていないか。
• トーン＆マナー: 自社のブランドイメージや、相手との関係性に適した口調か。

評価プロセスの実践：LLM-as-a-Judge

毎回人間がすべてチェックするのは大変です。そこで最近注目されているのが、**「AIにAIを評価させる（LLM-as-a-Judge）」**という手法です。

例えば、以下のような評価用プロンプトを作成し、AI（GPT-4など高性能なモデル）に審査員役をやらせます。

あなたは厳格な編集者です。以下の【入力テキスト】をもとに生成された【AIの回答】を評価してください。

評価基準は以下の通りです。

1. 事実と異なる内容が含まれていないか
2. 日本語として自然か
3. 指定されたフォーマット（箇条書き）を守っているか

100点満点で採点し、減点理由を簡潔に述べてください。

このように、作成したプロンプトのテストを自動化・半自動化することで、品質担保のサイクルを高速に回せるようになります。

---

実践編：ゼロから作るための導入ロードマップ

ここまで解説した要素を組み合わせて、実際に社内プロンプト集を立ち上げる手順を整理します。

Phase 1：現状把握と「野良プロンプト」の収集（1週間〜）

まずは社内に散らばっているプロンプトを集めることから始めます。

• SlackやTeamsで「普段使っている便利なプロンプトを教えてください」と呼びかける。
• 個人がメモ帳に保存しているものを提出してもらう。
• この段階では命名規則などは気にせず、とにかく「数」と「ユースケース」を集めることに集中します。

Phase 2：標準化とドキュメント化（2週間〜）

集まったプロンプトを整理します。

1. 選別: 本当に効果があるもの、汎用性が高いものをピックアップします。
2. リファクタリング: 前述の「命名規則」に従って名前を付け直し、プロンプト本文も分かりやすく書き直します。特に、「変えるべき場所」を明確にするのがコツです。
   • 悪い例：以下の文章を要約して。昨日の会議は……
   • 良い例：以下の ###会議ログ を要約してください。変数：{会議ログ}
3. カタログ化: Notionやスプレッドシートに入力し、全社員がアクセスできる場所に配置します。

Phase 3：運用とフィードバック（継続）

プロンプト集は作って終わりではありません。使ってもらい、磨き上げることが重要です。

• フィードバックボタン: 「このプロンプトは役に立った」「使いにくかった」を簡単に報告できる仕組みを作ります（Googleフォームへのリンクなど）。
• 定期レビュー会: 月に一度、管理者（プロンプトエンジニア的な役割の人）が集まり、新しいモデルへの対応や、評価の低いプロンプトの削除・修正を行います。

---

プロンプト集の構成テンプレート（コピペ用）

社内Wikiやドキュメントツールに記載する際の、推奨テンプレートを記載します。これをコピーして使い始めてください。

---

プロンプト定義書テンプレート

基本情報

• プロンプト名: GEN_メール返信_謝罪用_GPT4_v1.0
• 作成者/管理者: 山田太郎（総務部）
• 最終更新日: 202X年X月X日
• 対象モデル: GPT-4 / Claude 3 Opus
• 推奨パラメータ: Temperature 0.7（創造性高め）

概要

クレームのメールを受信した際、一次返信として当たり障りのない、かつ誠意ある文面を作成するためのプロンプトです。事象の詳細確認は含めず、まずは「受け取ったこと」と「調査すること」を伝えます。

入力変数（Variables）

ユーザーは以下の部分を書き換えて使用してください。

• {顧客名} : 相手の名前
• {クレーム内容} : メールの本文、または要約
• {担当者名} : 自分の名前

プロンプト本文（コピー用）

Plaintext

あなたはベテランのカスタマーサポート担当者です。
以下の {クレーム内容} をもとに、顧客である {顧客名} 様へ送る、謝罪と受領確認のメールを作成してください。

# 制約条件
- 平身低頭になりすぎず、プロフェッショナルなトーンで。
- 原因は調査中であるとし、具体的な解決策は提示しない（24時間以内に再度連絡すると伝える）。
- 文章量は300文字程度。

# 入力情報
顧客名: {顧客名}
クレーム内容: {クレーム内容}
署名: {担当者名}

出力例（Few-shot）

（ここに期待される出力結果のサンプルを貼り付けます。ユーザーが成功イメージを持つために重要です。）

改訂履歴

• v1.0: 新規作成
• v0.9: テスト版。トーンが硬すぎたため修正。

---

運用上の注意点とよくある失敗

最後に、運用を成功させるための注意点をお伝えします。

1. 完璧を求めすぎない

最初から100点のプロンプト集を作ろうとすると挫折します。「まずは3つだけ」で構いません。小さく始めて、徐々に育てていく「アジャイル」な発想が大切です。

2. 「変数は何か」を明確にする

初心者が一番つまずくのが、「プロンプトのどこを書き換えればいいのか分からない」という点です。テンプレートでは、書き換えるべき場所を { } や [ ] で囲ったり、プレースホルダーとして明示したりする工夫が必須です。

3. 機密情報の取り扱い（セキュリティ）

プロンプト集に、実際の顧客名や社外秘のデータを含めたまま保存してはいけません。必ずダミーデータや「{会社名}」といった変数に置き換えてから共有してください。また、利用するAIツールが学習データとして利用されない設定（オプトアウトやAPI利用）になっているかどうかも、併せて周知する必要があります。

---

まとめ：プロンプトは「組織の知的資産」である

たかがテキスト、されどテキスト。

優れたプロンプトは、優秀な社員の思考プロセスそのものです。それを可視化し、共有可能な形にまとめた「社内プロンプト集」は、これからのAI時代における最強の「組織の知的資産」となります。

命名規則で検索性を高め、版管理で品質を維持し、評価軸で改善を続ける。

このエンジニアリング的なアプローチを取り入れることで、あなたの会社のAI活用レベルは、個人の趣味レベルから組織の武器へと進化します。

まずは手元のメモ帳にある「お気に入りのプロンプト」を1つ、今回紹介したテンプレートに当てはめてみることから始めてみませんか？その小さな一歩が、組織全体の生産性を劇的に変えるきっかけになるはずです。