設計事務所のプロンプト管理｜使い方を共有する

良い指示文だけを保存しても再利用できない

同じプロンプトを使っても、入力資料、製品、モデル、設定、実行時期が違えば出力は変わります。指示文だけを「成功例」として共有すると、別担当が機密資料を入れたり、確認工程を飛ばしたりする原因になります。

管理する単位は、目的、対象外、入力条件、匿名化、指示文、出力形式、確認方法、停止条件、試験結果、版です。万能プロンプトを作るのではなく、議事録のタスク抽出、要望の矛盾候補整理など、一つの業務ごとに管理します。

登録票に必要な項目

Google Cloudの公式プロンプト設計資料は、目的と期待結果を定義し、制約、文脈、例、出力形式を使って反復的に試す考え方を示しています。Microsoftの公式資料も、明確な指示と根拠付け、回答の検証、情報がない場合の扱いを案内しています。製品固有の機能ではなく、試験と確認を含む管理方法として取り入れます。

入力テンプレートを先に作る

自由文を毎回貼ると、必要項目の欠落や不要情報の混入が起きます。たとえば要望整理なら、要望ID、原文、発言者区分、日時、対象室、確定状態、根拠位置の列を用意します。案件名や個人名は別の匿名IDへ置き換えます。

空欄、ゼロ、未確認を区別します。AIが空欄を推測しないよう、「空欄は未確認として残す」と登録票へ書きます。長い資料の場合は、分割単位と重複部分の扱いも決めます。

業務固有のプロンプト例

入力テンプレートにある設計要望を、要望IDを保ったまま、確定、提案、未確認、相反候補へ分類してください。原文にない部屋、寸法、法規、性能、費用、期限を追加しないでください。相反候補は両方の要望IDを示し、解決案を確定しないでください。出力列は要望ID、分類、原文要約、確認質問、根拠位置とします。根拠が不足する場合は「担当者確認」としてください。

この例には、入力制約、禁止事項、出力列、失敗時の扱いがあります。それでも結果を保証しません。利用者は要望IDの欠落、意味変更、入力外追加、相反要望の見落としを確認します。

試験セットで変更前後を比べる

プロンプトを直す前に、匿名の固定試験セットを作ります。正常な要望、空欄、否定文、相反要望、表記揺れ、対象外情報を含めます。期待結果は人が承認しておきます。

1. 現行版で試験セットを実行します。
2. 正答、誤追加、欠落、意味変更を記録します。
3. 一つの問題に対応する修正を加えます。
4. 同じ試験セットで再実行します。
5. 直した項目以外が悪化していないか確認します。
6. 製品、モデル、設定、実行日を保存します。
7. 承認者が結果を確認して新しい版を公開します。

一つの成功例だけで版を更新しません。プロンプトを長くするほど良いとも限らず、矛盾する指示が増えることがあります。

版番号と利用状態を管理する

版番号、更新日、変更理由、対象製品、試験結果、承認者を残します。利用状態は試験中、承認済み、停止、廃止などに分けます。共有フォルダのファイル名だけで最新版を示さず、一覧表から承認済み版へリンクします。

製品やモデルが更新された場合は、指示文が同じでも再試験します。Microsoftの公式資料は、システムメッセージで「事実だけを書く」「情報を作らない」と指示するだけでは、不正確な回答を十分に抑えられない場合があると説明しています。根拠の提示、出力構造、事実確認の手順を組み込み、固定試験で結果を評価します。

実行記録から改善する

利用者は、プロンプトIDと版、入力種別、結果、修正時間、発見した誤りを記録します。入力本文や機密情報を一覧へ転記する必要はありません。問題の種類と匿名の再現例を残します。

同じ誤りが続く場合は、指示文だけでなく入力テンプレートや対象業務を見直します。たとえば担当者の推測が止まらないなら、担当列が空欄の行を除外せず、明示的な試験例として加えます。図面や画像の細部読み取りが原因なら、その用途を外します。

共有時に伝える利用手順

利用者には、承認済み版を選ぶ、入力可否を確認する、匿名化する、試験対象の複製で実行する、確認表で照合する、外部共有前に承認を得る順を示します。「コピーして使う」だけの説明にしません。

プロンプト内に顧客名、住所、案件固有の寸法、秘密情報を固定で書かないよう確認します。権限は編集者と利用者を分け、変更提案はレビュー後に反映します。

廃止した版を誤って使わせない

旧版を削除するだけでは、個人のメモや過去案件から再利用されます。廃止理由、後継版、停止日を一覧へ残し、旧ファイルの先頭にも「利用停止」と記載します。たとえば版1.2が期限を推測する問題を起こしたなら、版1.3で未確認出力を追加した事実と試験結果を結びます。利用ログから旧版の実行がないか確認し、見つかった場合は結果を外部共有せず再レビューします。

後継版がない場合は、代替する手動手順と相談先を記載します。利用停止だけでは現場が旧版を使い続けるためです。案件途中で版を切り替えるときは、既に作成した出力を新しい版で再処理するか、旧版のレビューを追加するかを案件責任者が決めます。

失敗時の見直し

出力形式が崩れる場合は、列名と例を短く示します。入力外の内容を足す場合は、利用できる情報を入力IDに限定し、不明時の出力を決めます。長文で項目が落ちる場合は、分割単位と統合時の重複確認を設計します。

何度直しても重大な誤りが残る場合は、承認済み状態を解除し、対象を狭めるか利用を停止します。人のレビューで常に全面修正が必要なら、共有テンプレートとして維持する効果がありません。

よくある質問

長いプロンプトほど精度は上がりますか

保証されません。目的、入力、制約、出力、確認を明確にし、固定試験セットで比較します。

一つのプロンプトを全業務で使えますか

用途ごとに必要な入力と失敗条件が違います。業務単位で管理します。

モデルが変わっても同じ版でよいですか

再試験が必要です。製品、モデル、設定、実行日を結果と一緒に記録します。

成功した出力も保存しますか

機密を含まない匿名の試験結果を保存します。実案件の出力は案件の文書管理規則に従います。

誰でもプロンプトを更新できますか

変更提案は受け付けても、承認済み版の更新者と承認者を決め、試験結果を確認して公開します。

参考資料

• Google Cloud：Overview of prompting strategies
• Microsoft Learn：Prompt engineering techniques

関連記事

• 設計事務所のAI出力レビュー
• 設計事務所のAI試行
• 設計事務所のAI研修