冒頭
「プロンプトエンジニアリングは死んだ」というQiitaの記事が話題になってましたね。
そして「プロンプト・エンジニアリングは、まだ始まってすらいない」という反論記事も出ていて、面白い議論になっていました。
議論を眺めながら、「死んだ」と言われているのは「魔法の呪文を唱えれば何でも解決」みたいな素朴なプロンプトの話で、実際に必要なのは業務フローを理解した上での構造化されたプロンプト設計だよなーという感想を持ってました。
アンドレイ・カルパシー氏が提唱し始めた「コンテクスト・エンジニアリング」という概念も、まさにそういう方向性を指している気がします。単なる「お願いの仕方」ではなく、AIに渡す文脈全体を設計するという発想。
そんなことを考えていたタイミングで、pospome氏のブログ記事を読みました。組織の動かし方について具体的でめちゃくちゃ参考になる内容で、この辺の体系化された動き方を、ガードレールにして 自分自身の動き方も効率化 できないもんかなと。
というわけで、この記事を参考に、社内向けの会議準備ボット用のシステムプロンプトを設計をしてみたという話です。「社内での合意形成」というのはまああまり体系化されてなかったり、動きが確立されていないというのがあったので、毎回の整理をアシストしてくれて非常に助かっています。今回はその設計思想と実装を共有します。
もちろん、会社によって経営会議の形式は全然違うので「これが絶対！」というものではありません。ただ、「構造化されたプロンプト設計」の一つの実践例として、何かしらのヒントになれば。
プロンプトの設計思想
1. フェーズ分割による認知負荷の軽減
pospome氏の準備の仕方にならって、4つのフェーズに分けて段階的に進めることをポイントにしています。
Phase1: サマリー（5〜9項目）
Phase2: 詳細 Step1〜3（勝ち筋・関係者・仕様）
Phase3: 詳細 Step4〜5 + 承認テーブル（レビュー計画・運用）
Phase4: タスク + レビュー依頼文 + 付録
人間が一度に処理できる情報量には限界があります。会議の資料って、「サマリーを先に見たい意思決定者」と「詳細を知りたい実務担当」の両方に対応しないといけないので、段階的に情報密度を上げていく構造になっています。
各フェーズの後に確認を取ることで、途中で方向性の修正もできます。けっこう重要で、最後まで作ってから「あ、この前提違った」ってなると全部やり直しになっちゃうんですよね。
2. 事実ベース主義の徹底
プロンプトの基本ルールに「事実ベース（根拠のない数字は禁止、出典を付録に記載）」と入れています。
AIを使う上で気をつけないといけないポイントとして、やはりもっともらしい数字をさらっと生成しちゃうことがあるというのがあげられます。会議でそういう数字を出してしまうと、信頼を一気に失うので絶対避けなければなりません。
だから、必ず出典を付けるルールにして、不明な点は「不明/要確認」と明記させる。「曖昧さを曖昧なまま扱う」というのも、逆に大事でもあります。
3. 承認が必要な項目の優先表示
会議で一番重要なのは「何を決めるか」です。報告だけなのか、承認が必要なのか。承認が必要なら、お金・人手・期限・方針のどれなのか。
これを最初に明示することで、参加者は「今日何を判断すればいいのか」が一目でわかります。逆に言うと、ここが曖昧だと会議がグダグダになる。「で、結局何を決めたいの？」って。
4. リスクは最大3つに絞る
「リスクを10個も20個も列挙してしまう」というのはやりがちな失敗パターンです。確かに、技術的にはいろんなリスクがあるんですけど、意思決定者の立場からすると「で、結局どれが重要なの？」ってなります。
だから、技術・運用・法務・収益の4つの観点から、最大3つに絞る形にしました。そして、必ず対策も一言で添える。これだけで意思決定が格段にやりやすくなります。
実際のプロンプト
あなたは会議準備エージェントです。
相談や資料から情報を整理し、1枚の要約／詳細／レビュー依頼文／タスクを作ります。
文章は平易な日本語で、専門用語は避けるか補足します。
## 基本ルール
* まず1枚で意思決定に必要な点をまとめ、その後に詳細
* 事実ベース（根拠のない数字は禁止、出典を付録に記載）
* 承認が必要な項目（お金・人手・期限・方針）を最初に書く
* リスクは最大3つ（技術/運用/法務/収益から）、対策も一言で
* 日時はすべてJST。不明点は `不明/要確認` と明記
## 条件分岐
* 入力が3項目以下 → 不足項目を質問してから開始
* 承認不要の報告案件 → 承認テーブル省略、「報告のみ」と明記
* 期限3営業日以内 → サマリー＋タスクを先行出力
## 出力（4フェーズ、各フェーズ後に確認を取る）
**Phase1 経営サマリー（5〜9項目）**
案件名・目的／要承認事項／勝ち筋（成功理由）／リスクと対策／影響範囲／次アクション
**Phase2 詳細 Step1〜3**
* Step1 勝ち筋：指標（今→目標）、代案、失敗時の回避策
* Step2 関係者：決定者・レビュア・実行者・協力部門（名前・連絡先）
* Step3 仕様：課題／解決策／費用（初期/運用/人月）／法務・セキュリティ要件
**Phase3 詳細 Step4〜5 ＋ 承認テーブル**
* Step4 レビュー計画：流れ、期限、同意みなし、想定Q&A（3〜5）
* Step5 運用：体制（RACI）、週次チェック、指標の見張り方
* 承認テーブル：論点/申請内容/金額・期日/代替案/推奨/承認者/判定
**Phase4 タスク＋レビュー依頼文＋付録**
* タスク形式：`[担当@氏名][YYYY-MM-DD] タスク名 — 完了条件/依存/リスク`
* レビュー依頼：140〜220字、締切、必須レビュア、リンク
* 付録：参照ソース、用語説明
## 自動チェック（各フェーズ末尾に記載）
`数値出典：OK/不足｜測定法：OK/不足｜期日整合：OK/不足｜担当未割当：有/無`
実際の使い方・活用シーン
ケース1: 新機能の提案
「顧客向けのAIチャットサポート機能を導入したい」という提案をまとめるケースを考えてみます。
入力する情報：
- 背景：問い合わせ件数が月間1,200件、オペレーターの負荷が限界
- 目的：AI導入により、定型問い合わせの70%を自動化
- 予算：初期費用500万円、月額運用費50万円
- 期限：3ヶ月後にβ版リリース
これらを入力すると、AIが4つのフェーズに分けて資料を生成してくれます。各フェーズごとに内容を確認して、必要なら修正指示を出せます。
ケース2: 報告のみの案件
「先月の採用活動の結果報告」のような、承認が不要な報告案件の場合。
承認不要の報告案件 → 承認テーブル省略、「報告のみ」と明記
承認が必要な案件と区別して、無駄な時間をかけないようにします。
自動チェック機能の実装
各フェーズの最後に、以下のチェックを入れています：
数値出典：OK/不足｜測定法：OK/不足｜期日整合：OK/不足｜担当未割当：有/無
これ、AIが自分で生成した内容をセルフチェックする仕組みです。「数値の出典が抜けてますよ」「担当者が決まってないタスクがありますよ」って教えてくれる。
人間がレビューする前に、AIが一次チェックしてくれるので、品質が安定します。
今後の展望
このプロンプト、まだまだ改善の余地があります。
1. 社内の過去資料からの学習
会社とかの過去資料をRAG（検索拡張生成）で参照できるようにすると、より社内のフォーマットに合った資料が生成できそうです。（というか個人としてはやっています）
2. 業界別のカスタマイズ
業界特有の指標を自動で組み込めるようにしたい。
3. 会議後のフォローアップ
決定事項とアクションアイテムを自動で議事録化して、関係者に配信する仕組みも作りたいですね。
まとめ
AIプロンプトの設計って、「どう指示を出すか」以上に「人間の認知プロセスをどう理解するか」が大事ですね。
会議の準備作業を分解すると、「情報収集→整理→フォーマット化→レビュー」という流れがあり、このうち「フォーマット化」の部分は機械的で、AIが最も得意とする領域です。逆に「何を伝えるべきか」という本質的な判断は、まだ人間がやるべき部分。
だから、このプロンプトも「AIに丸投げ」ではなくて、「人間とAIの協働」を前提に設計しています。各フェーズで確認を取るのも、そのためです。
もちろん、これが万能解というわけではありません。会社の文化や経営陣の好みによって、最適なフォーマットは全然違います。ただ、「段階的に進める」「事実ベースで書く」「承認事項を明確にする」というエッセンスは、どんな組織でも使えるんじゃないかなと。
何か質問や「うちの会社ではこうしてる」みたいな話があれば、ぜひコメントで教えてください。
おわり。