プロンプトライブラリの組織管理：Sheets×GAS 設計ガイド

ChatGPTやClaudeなどの生成AIを社内展開する企業が増加する中、プロンプトが個人のPCやSlackに散在して組織内で再利用できない状態が課題になっています。この記事では、Google SheetsをハブにしたプロンプトライブラリのGAS（Google Apps Script）による組織管理設計を、情シス担当者の視点で整理します。

この記事を読んだほうが良い人

• ChatGPT・Claude・Geminiなどの生成AIを社内展開済みで、プロンプトの散在・属人化に悩む情シス担当者
• Slackに流れた「うまくいくプロンプト」がその後誰にも再利用されない状況を変えたい方
• プロンプト管理の仕組みをゼロから設計したい方
• GASを使った月次自動集計の実装例を手元に置きたい方

プロンプト属人化チェックリスト：自社の現状を確認する

プロンプトライブラリの組織管理を始める前に、現在の状況を確認します。以下の5項目が目安です。

• 保存場所が人ごとにバラバラ: Slackのメモ・Notionの個人ページ・ローカルのテキストファイルなど、保存先が統一されていない
• 退職時にプロンプトが消える: 担当者の退職やPC交換に伴い、蓄積されたプロンプトが失われた経験がある
• 使い回しの仕組みがない: 「このプロンプト、Aさんが持っていそう」という属人的な問い合わせが発生している
• 品質のばらつきが大きい: 同じ業務でも人によって出力品質が異なり、AI活用の効果が部門ごとに偏っている
• 改善の痕跡が残らない: プロンプトをチューニングしたとき、改善前後の比較や変更理由が記録されていない

3項目以上当てはまる場合、何らかの組織的な仕組みが必要なフェーズに入っています。筆者の実務経験では「3項目」という閾値は絶対的なものではなく、「このままでいいのか」と感じはじめたタイミングと一致することが多いです。

「保存場所がバラバラ」の状態は、情報の分散だけでなく、同じ業務を担うAさんとBさんが互いに異なるプロンプトを使い続けるサイロ状態（部門間の情報共有が断絶した状態）を生みます。「退職時にプロンプトが消える」については、100名規模の企業でも年に数名の退職が発生し、その都度ナレッジが散逸するリスクがあります。1〜2項目の段階でも、仕組みを整えるコストは後になるほど大きくなるため、早めに動くほど損失が少なくて済みます。

プロンプトライブラリ組織管理のためのSheetsスキーマ設計

Google Sheetsでプロンプトライブラリを管理する場合、まず「どの情報を列として持つか」というスキーマ設計が肝心です。以下は100名規模の企業に向けた推奨スキーマです。

列名	型	説明
プロンプトID	テキスト	一意のID（例: PR-001）
タイトル	テキスト	何をするプロンプトか短く表す名前
プロンプト本文	テキスト	実際に入力するプロンプト全文
対応AIツール	テキスト	ChatGPT / Claude / Gemini など
部門	テキスト	作成または主な利用部門
作成者	テキスト	氏名またはメールアドレス
ステータス	テキスト	下書き / 承認済み / 廃止
月間利用数	数値	月に何回使われたか（自己申告）
最終更新日	日付	最後に内容を変更した日
備考	テキスト	使い方のコツ・注意事項など

設計時に特に重要なポイントが3点あります。

• ステータス列を必須にする: 下書き・承認済み・廃止の3値を持つだけで、現役プロンプトと非推奨プロンプトを分離できる。フィルタで「承認済み」だけ表示すれば実用的なプロンプト集として機能する
• 対応AIツール列を持つ理由: ChatGPTとClaudeでは同じプロンプトでも出力傾向が異なることがある。ツール依存を明示しておくと混乱を防ぎやすい
• 月間利用数は自己申告で十分: 厳密な計測より「大体何回使っているか」のオーダー感が分かれば、改善サイクルを回すデータとして十分機能する。最初の3ヶ月は情シスが部門ヒアリングで記入を補佐すると定着しやすい

シートは「プロンプトライブラリ」（本体）と「部門別集計」（GAS出力用）の2枚構成にするとシンプルに保てます。

入力摩擦を下げるデータ入力設計

スキーマが決まったら、Sheetsのデータ入力規則機能でドロップダウンを設定しておきます。ステータス列は「下書き」「承認済み」「廃止」の3値のみ選択可能にすると、「承認」「確認済み」「OK」といった表記ゆれを防げます。対応AIツール列も「ChatGPT」「Claude」「Gemini」「その他」の4択に限定しておくと、GASのフィルタリング処理が安定します。

Google Formsをプロンプト登録インターフェースとして活用する方法も有効です。Sheetsに直接入力する形式は、スプレッドシートに慣れていない社員には敷居が高いことがあります。Formsでプロンプト登録フォームを作成してSheetsに連携しておけば、各部門担当者がブラウザから気軽に登録でき、収集フェーズの負担が大きく下がります。Forms→Sheets連携はGoogleのネイティブ機能として動作するため、GASコードを追加しなくても実現できます。

ただし、Formsから連携されたシートは列の順序がフォームの設問順になります。「プロンプトライブラリ」シートとは別にFormsの回答シートを設け、IMPORTRANGE関数でデータを整理済みシートに引き込む2シート構成にすると、スキーマの一貫性を保てます。

GASで部門別プロンプト集計を自動化する

月次の改善サイクルを回すには、部門ごとのプロンプト数と利用状況をGASで集計する仕組みが有効です。以下のスクリプトは「プロンプトライブラリ」シートを読み取り、部門別の集計結果を「部門別集計」シートに書き出します。

本スクリプトはプロンプトライブラリ用スプレッドシートを開いた状態で、拡張機能 > Apps Script から作成・実行してください（コンテナバインド型）。 script.google.com から作成したスタンドアロン型スクリプトでは getActiveSpreadsheet() が null を返し、直後の getSheetByName() でエラーになります。

function summarizePromptsByDepartment() {
  const ss = SpreadsheetApp.getActiveSpreadsheet();
  const libSheet = ss.getSheetByName('プロンプトライブラリ');
  const summarySheet = ss.getSheetByName('部門別集計')
    || ss.insertSheet('部門別集計'); // 存在しなければ新規作成

  // ヘッダーを除いた全データを取得
  const data    = libSheet.getDataRange().getValues();
  const headers = data[0];
  const deptIdx   = headers.indexOf('部門');
  const statusIdx = headers.indexOf('ステータス');
  const usageIdx  = headers.indexOf('月間利用数');

  // 部門ごとに集計
  const deptMap = {};
  for (let i = 1; i < data.length; i++) {
    const row    = data[i];
    const dept   = row[deptIdx]   || '未分類';
    const status = row[statusIdx];
    const usage  = Number(row[usageIdx]) || 0;

    if (!deptMap[dept]) {
      deptMap[dept] = { approved: 0, draft: 0, totalUsage: 0 };
    }
    if (status === '承認済み') deptMap[dept].approved++;
    if (status === '下書き')   deptMap[dept].draft++;
    deptMap[dept].totalUsage += usage;
  }

  // 集計シートに書き出し
  summarySheet.clearContents();
  summarySheet.appendRow(['部門', '承認済み数', '下書き数', '月間利用合計']);
  for (const [dept, counts] of Object.entries(deptMap)) {
    summarySheet.appendRow([
      dept,
      counts.approved,
      counts.draft,
      counts.totalUsage
    ]);
  }
}

列名（「部門」「ステータス」「月間利用数」）はスキーマの列名と一致させれば動きます。列名を変更した場合は headers.indexOf('...') の引数を合わせて書き換えてください。

月次自動実行のトリガー設定

このスクリプトはGASの時間主導型トリガーで月1回自動実行するよう設定しておきます。GASエディタの「トリガー」メニューから関数 summarizePromptsByDepartment を選択し、イベントのソースを「時間主導型」、タイプを「月ベースのタイマー」、実行日を「月の1日」、実行時刻を6〜7時台に指定してください。月初の業務開始前に集計が完了している状態を作れます。

初回実行時にスプレッドシートへの読み書き権限の承認ダイアログが表示されます。情シス担当者のアカウントで承認しておくと、以降の自動実行は認証手続きなしで継続します。

月次改善サイクルの組み方

月次サイクルは「収集→集計→レビュー→周知」の4フェーズで回します。

フェーズ	タイミング	担当	内容
収集	月初1〜5日	各部門の代表者	新規プロンプトの追加・月間利用数の更新
集計	月初5日	GAS自動実行	部門別集計スクリプトの自動実行
レビュー	月中旬	情シス	下書きプロンプトの承認・廃止判断
周知	月末	情シス	全社向けSlack等で「今月の注目プロンプト」を発信

月末の「周知」を省略しがちですが、ここが最も重要なフェーズです。Sheetsに蓄積するだけでは組織の財産になりません。周知することで初めて「他部門でも再利用できる」という認識が広まります。

周知フェーズを形骸化させないために、Slack投稿のテンプレートをあらかじめ用意しておくことを勧めます。毎月コピーして数字とプロンプト名を差し替えるだけで完結する形式にするのがポイントです。

**💡 今月のプロンプト更新情報（X月分）**

新規承認：X件 ／ 廃止：X件

今月注目のプロンプト：「○○向け提案書要約」（○○部門・承認済み）

プロンプトライブラリで「承認済み」フィルタをかけて確認してください。

この周知を毎月続けることで、プロンプトライブラリの存在が社内に定着していきます。各部門からの自発的な登録が増えはじめると、情シスが能動的に動かなくても成長するナレッジベースになります。

承認フローを入れるかどうかの判断軸

承認フローの要否は、組織の規模と扱うプロンプトの機密度で判断します。

承認フロー不要（情シスが月1回確認するだけで十分）

• 社員数100名未満でプロンプト数が50件以下
• 扱うプロンプトが要約・翻訳・メール文章など一般的な業務効率化が中心
• AIツールの利用ガイドラインが浸透していて逸脱事例がほとんどない

部門長の承認を設ける

• 社員数100〜300名でプロンプト数が50〜200件程度
• 営業・人事・法務などの部門固有プロンプトが増えてきた
• 機密情報を扱う可能性があるプロンプトが出始めた

情報セキュリティ委員会の関与が必要

• 社員数300名超、またはコンプライアンス要件が厳格な業界
• 顧客情報や契約情報を扱うプロンプトが存在する
• 外部APIへの連携を含むプロンプトを管理している

100名規模の企業であれば、最初は承認フローなしで「情シスが月1回レビューする」形から始めるのが現実的です。プロンプト数が50件を超えたタイミングで、部門長承認の導入を改めて検討する流れが無理のない進め方です。

部門長承認を導入する場合、承認の対象を「全プロンプト」にするのは避けます。「機密情報を含む可能性があるプロンプト」や「全社展開を想定したプロンプト」に限定することで、承認フローの負担を下げながら品質管理を両立できます。「下書きのまま社内で使って良い。承認済みは情シスが品質保証した、より広い用途で使えるプロンプト」という位置付けにすると、承認待ちの間もライブラリが活用され続ける環境を維持できます。

運用で詰まりやすい3つのポイント

組織でプロンプトライブラリを動かし始めると、次の3点で詰まるケースが多いです。早めに対処方針を決めておくことで、形骸化を防ぎやすくなります。

入力が続かない（スキーマが複雑すぎる）

最初から10列以上のスキーマを設計すると、「1件登録するのに時間がかかる」という理由で入力されなくなります。最初は必須列を「プロンプトID / タイトル / プロンプト本文 / 部門 / ステータス」の5列に絞り、運用を続けながら追加していく方法が現実的です。「月間利用数」のような入力負担が高い列は、立ち上げから3ヶ月後に追加するくらいのペースでも機能します。

下書きが承認されず溜まる

部門長の承認を必須にすると、下書きが数週間放置されることがあります。前述の通り「下書きのまま使って良い、承認済みは情シスが品質保証したもの」という位置付けにすると、プロンプトライブラリ自体の利用率を維持しやすくなります。承認がないと使えない仕組みにすると、結果としてライブラリ全体が使われなくなるリスクがあります。

最終更新日が更新されない

最終更新日列を設けても、更新者が手動で書き換えを忘れると機能しません。スプレッドシートにバインドされた Apps Script（コンテナバインド型）であれば、GASの onEdit 関数を活用してプロンプト本文列が編集されたタイミングで最終更新日列を自動更新できます。以下の実装例では、C列（プロンプト本文）が変更されるとI列（最終更新日）に現在日時を自動記入します。

function onEdit(e) {
  const sheet = e.source.getActiveSheet();
  if (sheet.getName() !== 'プロンプトライブラリ') return;

  const range = e.range;
  const promptBodyCol = 3;   // C列: プロンプト本文

  if (range.getColumn() === promptBodyCol) {
    const lastModifiedCol = 9; // I列: 最終更新日
    sheet.getRange(range.getRow(), lastModifiedCol)
         .setValue(new Date());
  }
}

列番号（promptBodyCol と lastModifiedCol）はスキーマの実際の列順に合わせて変更してください。コンテナバインド型の Apps Script であれば、onEdit はGASエディタで明示的なトリガー設定をしなくても、関数名を onEdit にするだけでシンプルトリガーとして自動動作します（権限承認なしで実行可能）。

プロンプトを「個人の記憶」から「組織の財産」に変える

SheetsとGASによるプロンプトライブラリの組織管理は、初期構築に多少の工数がかかります。しかし一度スキーマとGASを設定してしまえば、その後の運用コストはほぼ「月に1回、各部門が入力する時間」だけです。

大切なのは「完璧に設計してから始める」ではなく、「最小限のスキーマで始めて、月次改善サイクルの中でスキーマ自体もアップデートしていく」姿勢です。列を後から追加するのはSheetsでは容易なため、まず5〜10列程度で動かし始めることを勧めます。

プロンプトが組織に蓄積されると、AI活用のレベルが部門間で均等化していきます。属人化が解消されるほど、新入社員や異動した社員が組織のAIノウハウにすぐアクセスできる状態になります。この「ナレッジの民主化」こそが、プロンプトライブラリを仕組みとして運用する本質的な価値です。

コーポレートITのご相談はお気軽に

この記事で書いたような業務改善・自動化の設計から実装まで、DRASENASではコーポレートITの現場に寄り添った支援を行っています。 「まず相談だけ」でも大歓迎です。DRASENAS 公式サイトからお気軽にどうぞ。