プロンプト管理の方法。社内AIボットを引き継げる管理シートの6列

「あれ、この用途のGemはどっちが新しいほうだっけ？」と、自分で作ったボットの一覧を前に手が止まる場面は、AI活用が進んだ組織ほど増えていきます。

プロンプト管理は、スプレッドシート1枚に、ボット名・用途・呼び出し方・推奨モード・画像機能の要否・改善ログの6列を並べるところから始められます。
支援先の担当の方が実際に使っていた列で、この記事ではその表をもとに、名前とタグの付け方、版の残し方、正式版にするまでの承認、機密の扱いを順に見ていきます。
後半では、GeminiやCopilotの保存機能との分担と、増えすぎたときの整理の仕方も扱います。

社内のAIボットを作成から改善まで回す全体像は、社内AIボットを共通資産にする。作成・共有・改善のサイクルで扱っています。

プロンプトは、管理しないと作った人しか使えない

シートの中身に入る前に、管理しないまま数が増えると何が起きるのかを短く見ておきます。

カスタムAIやプロンプトが20個、30個と増えると、似た名前のボットが並び、作った本人でさえどれが最新なのか分からなくなります。
一覧に並んだ名前だけでは何ができるのかが伝わらないので、隣の席の人から「このボット、何に使うの？」と聞かれるたびに、作った本人が説明し直すことになります。

古い版が出回るのも、管理がないときに起きやすい事故です。
直す前のプロンプトをコピーした人が別のチームに配ってしまうと、どれが正しい版なのかを誰も言えなくなります。
管理シートは、探せること、同じ品質で使えること、担当が替わっても引き継げることを、1枚でそろえるための道具です。

プロンプト管理のシートは、6列と管理する側の3列で足りる

支援先で運用されていたのは、スプレッドシート1枚に、作った人が埋める6列を並べたシートでした。
まずはその6列と、組織で回すときに推進担当が足す3列を、1つの表にまとめておきます。

作った人が埋めるのは、上の6列だけです。
埋める負担が増えた瞬間にシートは更新されなくなるので、担当・状態・タグの3列は、月に1度の見直しのときに推進担当が埋める形にしておきます。

名前の付け方は、最初に決めておくと後が楽です。
「業務_何をするか」の順にそろえておくと、一覧を名前で並べ替えただけで同じ業務のものが隣り合います。
「最新」「改」「田中用」のような言葉は名前に入れず、版は改善ログのほうに書きます。

タグは自由に付けさせると、同じ意味の言葉が何通りも生まれます。
そのため、最初は部署と業務の名前で一覧を作り、多くても20個くらいまでに絞って、その中から選ぶ決まりにします。

Gemやスキルにしていない、文章だけのプロンプトも同じシートに載せます。
短いものは本文を用途の隣のセルに貼り、長いものはドキュメントに置いて、呼び出し方の列にリンクを入れておけば十分です。

改善ログに版と理由を残し、正式版は2人で確かめる

6列のうち、私がいちばん大事だと思っているのが最後の改善ログです。
ここでは、ログの書き方と版の付け方、正式版に上げるときの確かめ方を見ていきます。

カスタムAIは作って終わりにはならず、使っているうちに「ここが毎回ずれる」という点が見つかり、指示を少しずつ直していきます。
このとき変更の履歴が残っていないと、同じ失敗をもう一度踏みます。
「前にこの指示を足したら別の部分が崩れたので外した」という経緯を、3か月後の自分は覚えていません。

改善ログは、1回の変更を「版／日付／変えた人／変えた所／変えた理由」の1行で書きます。
言い回しを少し直しただけなら版を1.1、1.2と進め、入れる資料や出力の形が変わったときは2.0に上げる、と決めておけば十分です。
例えば「v1.2　出力が長すぎると言われたので、見出しを3つまでに制限した」と書いてあれば、次の担当者はその制限を勝手に外しません。

試作から正式に上げるときは、2人の目を通します。
業務をよく知る人は、出力がそのまま仕事に使えるかを見ます。
推進担当は、作った人以外が説明なしで使えるか、入れてはいけない情報が本文や見本に入っていないかを見ます。

「プロンプトに書いてはいけないことは何か」と聞かれることがありますが、答えは社内のAI利用ルールのほうにあります。
管理シートでは、顧客名や個人情報、社外秘の数字をプロンプトの本文や見本に書かず、「｛顧客名｝」のような差し込みの印に置き換えておくのが基本です。
用途の列に「入れてよい情報」を一言添えておくと、使う人が迷いません。

シートを編集できる人も限っておきます。
Googleスプレッドシートでは、メニューの「データ」→「シートと範囲を保護」から、編集できる人を自分やカスタムで選んだ人に絞れます。
ただ、2026年10月時点のGoogleのヘルプでは、保護はセキュリティ対策ではなく、閲覧できる人はコピーや書き出しができると書かれています。
そのため、シートそのものに機密を書かないことが前提になります。

スプレッドシートでもNotionでも、作る手順は同じ

道具が変わっても、管理シートを立ち上げる手順はほとんど変わりません。
まず手順を並べ、そのあとでスプレッドシートとNotionそれぞれの違いを見ます。

1. 今あるボットとプロンプトを、作った本人に聞いて書き出す
2. 作った人が6列を埋める
3. 推進担当が名前とタグをそろえ、担当・状態の列を埋める
4. 正式版だけを全社に案内し、試作は作った人のチームの中で使う
5. 新しいボットを作ったら、その場で1行足すルールにする

スプレッドシートなら、1行に1件で並べ、見出しの行にフィルタを付けるだけで始められます。
Googleスプレッドシートには版の履歴があり、画面右上の「変更履歴」のアイコンから開けます。
名前付きの版は1つのファイルに15個まで付けられると、2026年10月時点のヘルプに書かれています。
ただし以前の版を見られるのは編集権限のある人だけなので、使う人が経緯を読むためにも、改善ログの列は残しておきます。

Notionなら、データベースを1つ作り、ボット名をタイトル、状態をステータス、タグをマルチセレクト、担当をユーザーのプロパティにします。
プロンプトの本文と改善ログは、各ページの中に書くと読みやすくなります。
共有の権限は「閲覧可能」「コメント権限」のほか、データベースでは構造を変えずにページの中身だけを編集できる「コンテンツ編集権限」も選べます。

気をつけたいのは、Notionのページ履歴が残る期間です。
2026年10月時点のNotionのヘルプでは、フリープランで7日間、プラスプランで30日間、ビジネスプランで90日間、エンタープライズプランで無期限とされています。
また、データベースを復元しても各ページの本文は戻らないと書かれているので、ここでも改善ログを自分たちで残しておく意味があります。

どちらを選ぶかは、社内でふだん使っている側に合わせるのが自然です。
ブラウザ拡張や専用サービスまで含めた選び方は、プロンプト管理ツールの選び方。個人用・チーム用・組織用の違いで比べています。

続けるためには、シート自体をAIの参照先にしておくのも手です。
シートを読ませて「こういう業務をしたいけど、使えそうなボットはある？」と聞ける状態にしておくと、一覧が探すための道具になり、更新する動機も自然に生まれます。

GeminiやCopilotに保存したプロンプトも、シートに1行載せる

AIの側にも、プロンプトを保存しておく機能があります。
管理シートとどう分担するかを、GeminiとCopilotで見ておきます。

Geminiでプロンプトを保存する方法は、2026年10月23日時点では主に2つあります。
1つはGemで、指示とファイルをまとめて保存し、ほかの人に共有できます。
共有された人のうち、閲覧者は指示とファイルを見て使えるだけですが、編集者は指示の変更やほかの人への共有、削除までできます。

もう1つが、Gemの後継として出てきた「スキル」です。
Googleのヘルプでは、繰り返し使うプロンプトを保存しておき、チャットの中で「/」から呼び出せる、再利用できる指示と説明されています（呼び出しの記号は近く「@」に変わる予定とも書かれています）。

ただ、会社のGoogle Workspaceのアカウントで使えるかどうかは、案内によって書き方が違います。
2026年10月13日のGoogle Workspace Updatesでは、この日から順に提供されて11月中旬に行き渡る見込みとされていますが、Geminiアプリのヘルプでは仕事用のアカウントは「まもなく」という書き方です。
スキルをほかの人と共有する機能も「今後数週間のうちに」使えるようになる予定の段階なので、会社でチームに配るものは、当面はGemで共有することになります。

Gemは提供が終わり、自動でスキルに移される予定です。
Googleのヘルプでは、個人のアカウントは2026年11月、Workspaceのビジネスとエンタープライズは2027年3月とされています。
その前にも、2026年11月17日にGemがGeminiアプリの「設定」の中に移ると、Workspaceの管理者向けヘルプで案内されています。
どちらも開く場所や呼び出し方が変わるので、管理シートの「呼び出し方」の列を直す作業が出てきます。

Microsoft 365 Copilotでは、うまくいったプロンプトにカーソルを合わせ、ブックマークのアイコンから「プロンプトの保存」を選ぶと、プロンプト ギャラリーの「プロンプト」タブに入ります。
保存したプロンプトは自分にだけ表示され、ほかの人に渡すときは、Teamsのチームに共有するか、リンクをコピーしてチャットなどに貼ります。
Microsoftのヘルプも、共有するときは「何を達成しようとしたか」「どう役立ったか」「さらに良くする考え」を添えると役立つとしていて、これは改善ログに書く中身とほぼ重なります。

つまり、AIの側の保存機能は、すぐに呼び出すための置き場所です。
誰が直す担当で、どの版が正式で、なぜそう変えたのかを書いておく欄は、ここまでに見た保存機能には見当たりません。
そのため、Gemやスキル、Copilotに保存したものも、管理シートに1行ずつ載せておきます。

直す担当が決まらないまま古い版が残ることは、プロンプトが社内で共有されない原因の1つにも数えています。

担当者が異動するときの引き継ぎ全体の設計は、担当が変わってもAI業務が止まらない。引き継ぎパッケージの設計で詳しく書いています。

増えすぎたら、使われているかを見て3つに分ける

管理シートが育つと、今度は行が増えすぎて探しにくくなります。
ここでは、使われているかの測り方と、残すものの決め方を見ます。

使われているかどうかは、手に入る範囲の手がかりを組み合わせて見ます。
ツールの利用回数が取れるならその数字を、取れないなら担当に来た質問や直してほしいという声の数を見ます。
四半期に1度、チームで「この3か月で使ったもの」に印を付けてもらうだけでも、使われていない行ははっきりします。

そのうえで、行を「残す」「まとめる」「引退させる」の3つに分けます。
同じ業務で似たものが並んでいたら、いちばん使われているものに寄せて、ほかは引退にします。
引退させた行も消さずに状態の列を「引退」にしておくと、改善ログが後から役に立ちます。

残すものと消すものの決め方は、社員がAIで作ったツールが増えすぎたときの整理法。残すものと消すものの決め方にまとめています。
チームの一覧が育ってきたら、利用者が探すためのカタログへ広げていきます。
その考え方は共有したのに使われない。社内AI資産をカタログ化するにまとめています。

部署をまたいだら、ツールの一覧と使われた回数は同じ場所で見る

チームの1枚がうまく回り始めると、次は部署をまたいでツールを探せて、使われ方も見える場所が必要になります。

私たちの組織のAIポータル「AI Portalize」では、社内で作ったGemやGemini Notebookなどを登録すると、名前や説明、タグで全社から探せて、ツールごとに使われた回数と使っている人が見えます。
プロンプトの版を管理する機能ではないので、改善ログは管理シートに残し、探す場所と使われ方を見る場所として組み合わせて使う形になります。

管理シートがあれば、担当が替わっても同じ品質で使える

プロンプトやボットの管理は、数が増えてから考えるより、増え始めたところで型を決めておくほうが楽です。
Gemがスキルに移るなど、AIの側の保存先が動いても、シートに改善ログが残っていれば、なぜその指示にしたのかを追いながら作り直せます。

手始めに、自分が作ったボットを一覧にして、用途と推奨モードの2列だけでも書き出してみてください。