AIを業務で使うとき、本来であればプロジェクト単位の記憶、社内ドキュメント参照、状態管理、RAG、ワークフロー、権限管理などが整っているのが理想です。必要な情報だけが適切なタイミングでモデルに渡され、ユーザーは毎回長い前提を書かなくても済む状態です。
しかし、実際の現場では会社指定のAIチャットUIしか使えないことがあります。ファイル検索やプロジェクト機能があっても、どの情報がどのタイミングで参照されるかを利用者が細かく制御できない場合もあります。さらに、組織として「どの資料を正とするか」「どの情報をAIに渡してよいか」「出力を誰が確認するか」が決まっていないと、ツール側の機能だけでは回答品質を安定させにくくなります。
この記事では、そのような制約されたAIチャット環境で、プロンプトを単なる「呪文」ではなく、簡易的なコンテキストエンジニアリングとして扱う方法を説明します。API実装や本格的なRAG基盤の作り方ではなく、通常のチャット画面に貼り付けられるテンプレート、文脈カード、レビュー観点、判断ログの作り方に範囲を絞ります。
プロンプトを「入力文」ではなく「一時的な実行環境」として見る
この節では、この記事で扱うプロンプト設計の位置づけを整理します。まず、AI活用に関係する層を分けると、どこをプロンプトで補う必要があるのかが見えやすくなります。
AI活用には、大きく三つの層があります。
| 層 | 役割 | 例 |
|---|---|---|
| ツール側の機能 | AIが参照・実行できる仕組みを提供する | プロジェクト、ナレッジベース、ファイル検索、RAG、メモリ、エージェント、ワークフロー |
| 組織側の運用 | どの情報を使い、誰が確認するかを決める | 正本管理、権限管理、レビュー体制、ナレッジ更新、利用ルール |
| ユーザー側の入力設計 | このタスクで必要な情報をAIに伝える | 目的、背景、制約、評価基準、出力形式、不明点の扱い |
理想は、ツール側と組織側の層で多くを吸収することです。たとえば、正しい社内規程だけを検索対象にし、権限に応じて参照範囲を変え、回答には出典が付く、という状態です。
一方で、そのような仕組みがない場合、ユーザー側の入力設計の比重が上がります。つまり、プロンプトの中に「今回AIが使ってよい前提」「今回の判断基準」「出力の形」「不明点があるときの振る舞い」を明示する必要があります。
OpenAIのドキュメントでは、プロンプトエンジニアリングは、モデルが要件を満たす出力を一貫して生成するように有効な指示を書くプロセスとして説明されています。また、追加の文脈情報をプロンプトに含めることで、モデルが特定の資料や外部データを前提に回答できることも示されています。(OpenAI Platform)
ここで扱う「プロンプト芸」は、言い回しの工夫ではありません。プロジェクト機能、レビュー基準、ワークフロー定義、ナレッジ管理の一部を、ユーザーが一時的にプロンプト内で代替する行為です。
progressive disclosure 風に必要な文脈だけを渡す
この節では、AIに渡す文脈をどの粒度で選ぶかを説明します。重要なのは、手元にある資料を全部貼ることではなく、今回のタスクで必要な情報だけを切り出すことです。
progressive disclosure は、最初からすべての情報や機能を見せるのではなく、まず重要なものを提示し、必要に応じて詳細を段階的に見せる設計です。Nielsen Norman Groupは、progressive disclosureを、発展的または頻度の低い機能を二次的な画面に遅らせることで、アプリケーションを学びやすく、エラーを起こしにくくする考え方として説明しています。(Nielsen Norman Group)
AI利用に置き換えると、「過去の議事録を全部渡す」のではなく、「今回のレビューに必要な決定事項、未決事項、制約、評価軸だけを渡す」という考え方になります。
たとえば、企画書レビューで使う文脈は次のように切り出します。
# 今回使う文脈
## プロジェクト
B2B SaaS向けの既存プロダクトに、管理者向けレポート機能を追加する企画です。
## 事業上の目的
既存顧客のアップセル率を上げることを目的にしています。
新規顧客獲得よりも、既存顧客の利用拡大を優先します。
## 現在のフェーズ
社内稟議前の企画レビュー段階です。
まだ詳細なUI設計や実装見積もりは確定していません。
## 既に決まっていること
- 対象はエンタープライズプランの管理者です
- 初期リリースではCSV出力を必須にします
- グラフの種類は最小限にします
## 未決事項
- 料金プランに含めるか、オプション課金にするか
- 既存の分析画面と統合するか、別画面にするか
- 監査ログとの連携を初期リリースに含めるか
## 使ってよい資料
- この企画書本文
- 直近の顧客ヒアリング要約
- 既存プロダクトの機能一覧
## 使ってはいけない仮定
- 顧客が追加費用を必ず受け入れるという仮定
- 既存の分析基盤がそのまま流用できるという仮定
- 法務・セキュリティ確認が不要という仮定この文脈を先に作っておくと、AIは「企画書を一般論で褒める」のではなく、社内稟議に通すための不足情報やリスクを見つけやすくなります。
ここで確認すべき点は、文脈が多いか少ないかではありません。今回の作業に必要な判断材料が入っていて、不要な背景が混ざりすぎていないかです。
チャットに貼る最小プロンプトを組み立てる
この節では、通常のチャットUIに貼れる最小構成のプロンプトを作ります。構成を固定しておくと、毎回の依頼が属人的になりにくくなります。
プロンプトに最低限入れる項目は、次の六つです。
- 何を達成したいか
- どの立場・専門性で見てほしいか
- どの背景情報を前提にしてよいか
- 何を優先し、何を後回しにするか
- どの形式で出してほしいか
- 不明点がある場合にどう振る舞ってほしいか
これをチャットに貼る形にすると、次のようになります。
あなたは{役割}です。
以下の{対象物}について、{目的}のためにレビューしてください。
# 前提
{このタスクで使ってよい背景情報}
# 依頼内容
{AIに実行してほしい作業}
# 重視する観点
{評価基準や確認観点}
# 優先順位
{優先すること}
{後回しにすること}
# 出力形式
{見出し、表、箇条書き、JSONなどの形式}
# 不明点の扱い
作業に致命的な不足情報がある場合だけ、最初に最大3問まで質問してください。
軽微な不明点は合理的な仮定を置き、その仮定を明示して先に進めてください。
# 入力
{レビュー対象の本文や資料}OpenAIのドキュメントでは、Markdownの見出しやリスト、XMLタグを使うことで、プロンプトや文脈データの論理的な境界をモデルに伝えやすくなると説明されています。AnthropicのClaude向けドキュメントでも、指示、文脈、例、入力が混在する複雑なプロンプトでは、XMLタグが解釈の曖昧さを下げる方法として紹介されています。(OpenAI Platform)
通常のチャットUIでは、APIのようにsystem、developer、userといった役割を分けられない場合があります。その場合でも、見出しで情報の区切りを明示すると、どこが役割で、どこが前提で、どこが入力本文なのかをAIに伝えやすくなります。
企画書レビュー用のプロンプトを作る
この節では、実際に企画書レビューを依頼する例を見ます。まずは、文脈が不足している依頼と、文脈を明示した依頼を比較します。
文脈が不足している依頼は、次のような形です。
この企画書をレビューして。この依頼でも何らかのレビューは返ってきます。ただし、AIは「何のためのレビューか」「誰の観点で見るのか」「表現を直すべきか、事業判断の穴を見るべきか」を推測する必要があります。その結果、一般的なコメントや表現添削に寄りやすくなります。
次に、制約されたチャットUIでも品質を出しやすい依頼に書き換えます。
あなたはB2B SaaSの事業企画レビュー担当です。
以下の企画書について、社内稟議に通す観点でレビューしてください。
# 前提
この企画は、既存顧客向けの管理者レポート機能を追加するものです。
目的は、既存顧客のアップセル率を上げることです。
現在は社内稟議前の企画レビュー段階で、詳細なUI設計や実装見積もりは未確定です。
# 重視する観点
- 顧客課題の明確さ
- 既存プロダクトとの整合性
- 収益性
- 実装負荷
- セキュリティ・法務上のリスク
- 意思決定に必要な不足情報
# 優先順位
今回は表現の添削よりも、論理の穴と意思決定に必要な不足情報を優先してください。
細かい言い回しの修正は、致命的な誤解につながる場合だけ指摘してください。
# 出力形式
次の順番で出力してください。
1. 総評
2. 致命的な懸念
3. 修正すれば通りそうな点
4. 追加で確認すべき質問
5. 次に直すべき順番
# 不明点の扱い
作業に致命的な不足情報がある場合だけ、最初に最大3問まで質問してください。
軽微な不明点は合理的な仮定を置き、その仮定を明示して先に進めてください。
# 入力
ここに企画書本文を貼ります。このプロンプトで指定しているのは、特殊な言い回しではありません。役割、目的、前提、評価軸、優先順位、出力契約、不明点の扱いです。
期待する出力は、たとえば次のようになります。
# 1. 総評
社内稟議に出す前提として、顧客課題と収益性の説明が不足しています。
既存プロダクトとの整合性は一定ありますが、料金設計と実装負荷の見積もりがないため、現時点では意思決定材料として弱いです。
# 2. 致命的な懸念
## 顧客課題が機能要望としてしか書かれていない
「レポートがほしい」という要望は示されていますが、顧客がどの業務で困っているのか、現状どのような代替手段を使っているのかが不足しています。
## 収益性の仮説が未整理
アップセルを狙うと書かれていますが、対象顧客数、想定単価、導入率、既存プランとの関係が示されていません。
# 3. 修正すれば通りそうな点
既存の管理者機能と利用者が近いため、プロダクト上の導線は説明しやすいです。
ただし、既存画面に統合するのか、別画面にするのかを決める必要があります。
# 4. 追加で確認すべき質問
1. この機能を求めている顧客は何社あり、どのプランを利用していますか。
2. 顧客は現在、同じ目的をどのような手段で解決していますか。
3. 初期リリースでCSV出力以外に必須となる監査・権限要件はありますか。
# 5. 次に直すべき順番
1. 顧客課題を業務フローに沿って書き直す
2. 収益仮説を対象顧客数、単価、導入率に分解する
3. 実装範囲を初期リリースと将来対応に分けるこの出力から確認できるのは、AIが文章の表面ではなく、意思決定に必要な不足情報を中心に返していることです。つまり、プロンプトでレビューの目的と評価軸を明示したことで、出力の焦点が変わっています。
文脈カードを作って毎回の入力を短くする
この節では、毎回長いプロンプトを書く負担を減らす方法を説明します。ポイントは、即興の長文プロンプトを、再利用できる部品に分けることです。
たとえば、次のようなディレクトリを作り、用途ごとにMarkdownファイルを置きます。
ai-context/
├── project-card.md
├── request-template.md
├── review-criteria/
│ ├── planning.md
│ ├── legal.md
│ └── technical.md
└── decision-log.mdこの構成では、プロジェクト共通の前提、依頼テンプレート、レビュー観点、判断ログを分けています。会社指定のチャットUIしか使えない場合でも、必要なファイルの中身だけをコピーして貼り付ければ、毎回ゼロから説明し直す必要がありません。
プロジェクト概要カードは、次のように作ります。
# プロジェクト概要カード
## プロジェクト名
管理者向けレポート機能追加
## 目的
既存顧客のアップセル率を上げるため、管理者が利用状況を把握できるレポート機能を追加する。
## 対象ユーザー
エンタープライズプランを利用している管理者。
## 現在のフェーズ
社内稟議前の企画レビュー。
## 重要な制約
- 初期リリースでは既存の分析基盤を大きく改修しない
- 個人情報を含む出力には法務・セキュリティ確認が必要
- CSV出力は初期リリースに含める
- 詳細なグラフ機能は初期リリースでは必須にしない
## 最新の決定事項
- レポート対象は組織単位にする
- 個人単位の詳細分析は初期リリースから外す
- 料金設計は未決
## 最終更新日
2026-05-07このカードを使うと、プロンプト本体には「以下のプロジェクト概要カードを前提にしてください」と書けます。実行時には、カードの中身を貼ったあとに、今回の依頼だけを続けて書きます。
以下のプロジェクト概要カードを前提にしてください。
--- ここからプロジェクト概要カード ---
{project-card.md の内容}
--- ここまでプロジェクト概要カード ---
あなたはB2B SaaSの事業企画レビュー担当です。
以下の企画書について、社内稟議に通す観点でレビューしてください。
今回は、表現添削ではなく、意思決定に必要な不足情報とリスクの洗い出しを優先してください。
出力は次の順番にしてください。
1. 総評
2. 致命的な懸念
3. 修正すれば通りそうな点
4. 追加で確認すべき質問
5. 次に直すべき順番
--- ここから企画書 ---
{企画書本文}
--- ここまで企画書 ---ここで生成されるのは、単なる回答ではありません。プロジェクトの前提を反映したレビュー結果です。プロジェクト概要カードを更新すれば、次回以降のレビューにも同じ前提を反映できます。
レビュー観点リストで評価基準を固定する
この節では、AIのレビュー品質を安定させるために、評価基準を部品化します。レビュー観点を毎回プロンプトに書くのではなく、用途別にファイル化しておくと、属人性を下げられます。
企画レビュー用の観点リストは、次のように作ります。
# 企画レビュー観点
## 顧客課題
- 誰のどの業務課題を解くのか
- 顧客の発言や行動にもとづく根拠があるか
- 単なる機能要望ではなく、課題として説明されているか
## 事業性
- 収益へのつながりが説明されているか
- 対象顧客数、想定単価、導入率などの前提があるか
- 既存プランや営業戦略と矛盾しないか
## プロダクト整合性
- 既存機能との関係が明確か
- 既存のユーザーフローを壊さないか
- 初期リリースと将来拡張が分かれているか
## 実装負荷
- 必須要件と後回しにできる要件が分かれているか
- 既存基盤への影響が説明されているか
- 見積もりに必要な不明点が整理されているか
## リスク
- セキュリティ、法務、権限、監査の観点があるか
- 顧客に誤解されやすい表現がないか
- リリース後の運用負荷が見落とされていないかこのファイルをプロンプトに貼ると、AIは「良い企画かどうか」を曖昧に判断するのではなく、指定された観点に沿って確認できます。
実行時のプロンプトは次のようになります。
以下のレビュー観点に沿って、企画書をレビューしてください。
--- ここからレビュー観点 ---
{ai-context/review-criteria/planning.md の内容}
--- ここまでレビュー観点 ---
# 依頼
社内稟議に出す前に、企画書の論理の穴、不足情報、リスクを洗い出してください。
# 優先順位
1. 致命的な懸念
2. 意思決定に必要な不足情報
3. 修正すれば通りそうな点
4. 表現上の改善点
# 入力
{企画書本文}この形にすると、AIの出力を人間が確認するときにも基準が明確になります。レビュー結果が妥当かどうかを、プロンプトに含めた観点リストと照合できるためです。
判断ログで前提の古さを確認する
この節では、長いプロンプトの保守性を上げるために、判断ログを作ります。プロンプトが属人化する原因の一つは、過去の判断理由がプロンプト本文の中に埋もれることです。
判断ログは、次のように短く残します。
# 判断ログ
## 2026-05-07
### 決めたこと
初期リリースでは、個人単位の詳細分析を対象外にする。
### 理由
個人情報の扱いと権限設計の確認が必要であり、社内稟議前の段階ではリスクが大きいため。
### 却下した案
個人別の利用状況ランキングを初期リリースに含める案。
### 未決事項
組織単位のレポートを、既存分析画面に統合するか、別画面にするか。
### 次に確認すること
営業チームに、顧客が必要としている最小レポート項目を確認する。判断ログをプロンプトに含めるときは、すべてを貼る必要はありません。今回のタスクに関係する直近の判断だけを貼ります。
以下の判断ログを前提に、企画書の修正方針を提案してください。
--- ここから判断ログ ---
{今回の企画に関係する判断ログ}
--- ここまで判断ログ ---
# 依頼
企画書の「初期リリース範囲」セクションを修正するために、入れるべき内容と外すべき内容を整理してください。
# 出力形式
- 入れるべき内容
- 外すべき内容
- 追加で確認すべきこと
- その理由このプロンプトで確認できるのは、AIが最新の判断理由を踏まえて修正方針を出せているかです。過去の方針が変わった場合は、判断ログ側を更新すれば、プロンプト本文を毎回書き換える必要が減ります。
不明点がある場合の振る舞いを指定する
この節では、AIが勝手に補完しすぎる問題と、質問ばかりして進まない問題を抑える方法を扱います。多くの実務タスクでは、不明点がゼロになるまで待つと作業が進みません。一方で、重要な前提をAIが勝手に作ると、出力の信頼性が落ちます。
弱い指定は、次のようなものです。
不明点があれば質問してください。この指定では、AIが何を「質問すべき不明点」と見なすかが曖昧です。細かい点まで質問して止まる場合もあれば、重要な点を仮定で埋めてしまう場合もあります。
実務では、次のように振る舞いを分けると扱いやすくなります。
作業に致命的な不足情報がある場合だけ、最初に最大3問まで質問してください。
致命的な不足情報とは、回答の結論が大きく変わる情報です。
たとえば、対象顧客、意思決定の目的、法務・セキュリティ上の制約、使ってよい資料の範囲が不明な場合です。
軽微な不明点は、合理的な仮定を置いて作業を進めてください。
その場合は、出力の冒頭に「置いた仮定」として明示してください。この指定を入れると、AIの動きは次のどちらかになります。
- 致命的な不足情報がある場合は、最初に最大3問だけ質問する
- それ以外の場合は、仮定を明示したうえで作業を進める
出力例は次のようになります。
# 置いた仮定
- 対象顧客はエンタープライズプランの既存顧客と仮定します。
- 初期リリースでは、個人単位の詳細分析は含めないと仮定します。
- 収益性は、アップセルによる追加MRRを主な評価軸にすると仮定します。
# レビュー結果
...確認すべき点は、仮定が出力の冒頭に明示されているかです。仮定が見える状態であれば、人間がレビュー時に「この仮定は違う」と修正できます。
出力結果を確認する
この節では、プロンプトを実行したあとに見るべき確認ポイントを整理します。AIの出力は、そのまま採用するのではなく、プロンプトで指定した契約に沿って検査します。
確認ポイントは、次のように分けると実務で使いやすくなります。
| 確認項目 | 見る場所 | 確認内容 |
|---|---|---|
| 目的への一致 | 総評、結論 | 依頼した目的に沿った回答になっているか |
| 前提の利用 | 冒頭、理由説明 | 渡した文脈カードや判断ログが反映されているか |
| 評価軸の網羅 | 各セクション | 指定したレビュー観点が抜けていないか |
| 仮定の明示 | 冒頭、注記 | 不明点を勝手に断定していないか |
| 出力形式 | 見出し、表、順番 | 指定した形式で返っているか |
| 次の行動 | 最後のセクション | 人間が次に何を直すべきか分かるか |
たとえば、企画書レビューであれば、次のように確認します。
確認すること:
1. 顧客課題、収益性、実装負荷、リスクの観点がすべて出ているか
2. 表現添削ではなく、意思決定に必要な不足情報が中心になっているか
3. 「追加で確認すべき質問」が、実際に次の調査につながる内容になっているか
4. プロジェクト概要カードと矛盾する指摘がないか
5. AIが置いた仮定が明示されているかここで問題が見つかった場合は、プロンプトをその場で長くするのではなく、部品を直します。レビュー観点が不足していたなら review-criteria/planning.md を直し、前提が古かったなら project-card.md や decision-log.md を更新します。
この流れにすると、改善がチャット履歴の中に消えず、次回以降も使える形で残ります。
プロンプトをテンプレート化して再利用する
この節では、個人技としてのプロンプトを、再利用できる型に変える方法を説明します。目的は、うまい人だけが長文プロンプトを書ける状態から、誰でも一定品質で依頼できる状態に近づけることです。
まず、タスク依頼テンプレートを作ります。
# AIタスク依頼テンプレート
## 役割
あなたは{役割}です。
## 目的
{この作業で達成したいこと}
## 背景
{今回の作業に必要な背景情報}
## 入力
{AIに読ませる本文、資料、ログ、表など}
## 成果物
{AIに作ってほしいもの}
## 評価基準
{良い出力かどうかを判断する基準}
## 優先順位
{優先すること}
{後回しにすること}
## 出力形式
{見出し、表、箇条書き、JSONなど}
## 不明点の扱い
作業に致命的な不足情報がある場合だけ、最初に最大3問まで質問してください。
軽微な不明点は合理的な仮定を置き、その仮定を明示して先に進めてください。このテンプレートを使うと、依頼者は空欄を埋めるだけで、必要な情報を渡しやすくなります。レビュー担当者は、AIの回答だけでなく、依頼プロンプトも確認できます。
次に、用途別のテンプレートを作ります。
templates/
├── planning-review.txt
├── technical-review.txt
├── legal-risk-check.txt
├── sales-material-review.txt
└── meeting-summary.txt用途別テンプレートは、最初から大量に作る必要はありません。頻度が高く、出力品質の差が出やすい業務から作ります。たとえば、企画レビュー、議事録要約、営業資料レビュー、技術設計レビューなどです。
これにより、プロンプトは一回限りの文章ではなく、軽量な業務部品になります。
注意点：プロンプトで吸収しすぎない
この節では、プロンプトで頑張る運用の限界を整理します。制約された環境ではプロンプトが有効ですが、すべてをプロンプトに押し込むと別の問題が起きます。
まず、長すぎるプロンプトは保守しにくくなります。前提が古くなっても気づきにくく、どの指示が効いているのか分かりにくくなります。Anthropicは、コンテキストを有限の資源として扱い、望ましい結果につながる高信号の情報をできるだけ小さく保つことを、コンテキストエンジニアリングの指針として説明しています。(Anthropic)
次に、プロンプトは権限管理の代わりにはなりません。社外秘情報、個人情報、契約情報、未公開の財務情報などをAIに渡してよいかは、チャットに貼る前に組織のルールで確認する必要があります。
また、プロンプトは本格的なRAG基盤の完全な代替ではありません。RAGは、LLMが回答を生成する前に、外部の権威あるナレッジベースを参照することで出力を改善する考え方です。AWSの説明では、RAGはLLMの出力を最適化し、トレーニングデータ外の権威ある知識ベースを参照させるプロセスとして説明されています。(Amazon Web Services, Inc.)
つまり、プロンプトに文脈を貼る方法は、次のような場面で有効です。
- 会社指定のチャットUIしか使えない
- プロジェクト機能やファイル検索の挙動を細かく制御できない
- 組織のAI活用ルールがまだ未成熟
- ただし、今すぐ業務で一定品質の出力が必要
一方で、検索対象の制御、出典管理、権限管理、ログ管理、レビュー承認が必要な業務では、プロンプトだけに依存しない設計が必要です。
まとめ
制約されたAIチャット環境では、プロンプトは単なる入力文ではありません。プロジェクト機能、レビュー基準、ワークフロー定義、ナレッジ管理の不足を一時的に補う制御面になります。
ただし、毎回その場で長文プロンプトを書く運用は属人化しやすく、保守も難しくなります。そのため、プロンプトをそのまま職人芸として扱うのではなく、プロジェクト概要カード、タスク依頼テンプレート、レビュー観点リスト、判断ログに分解して再利用できる形にすることが重要です。
実務でまず作るべきものは、次の四つです。
- プロジェクト概要カード
- タスク依頼テンプレート
- 用途別レビュー観点リスト
- 判断ログ
これらを組み合わせると、会社指定のチャットUIしか使えない状況でも、AIに渡す前提、目的、制約、評価軸、出力形式を明示できます。
重要なのは、AIに「いい感じに理解してもらう」ことではありません。AIが迷わない入力環境を、人間側で作ることです。
参考
- OpenAI API Docs, “Prompt engineering” (OpenAI Platform)
- Anthropic, “Effective context engineering for AI agents” (Anthropic)
- Anthropic Claude Docs, “Prompting best practices” (Claude API Docs)
- Anthropic Claude Docs, “Increase output consistency” (Claude API Docs)
- Nielsen Norman Group, “Progressive Disclosure” (Nielsen Norman Group)
- AWS, “What is RAG? - Retrieval-Augmented Generation AI Explained” (Amazon Web Services, Inc.)