システムプロンプトと行動設計

🔄 Quick Recall: 前回のレッスンで、個別のプロンプトから推論システムへの思考転換を学んだ。すべての推論システムの基盤——システムプロンプトの設計に入る。

見えない手

Claude、ChatGPT、その他のAIアシスタントを使うたびに、見えないシステムプロンプトがバックグラウンドで動いている。ChatGPTがデフォルトで親切に会話するのも、Claudeが思慮深く丁寧なのも、カスタムGPTが作成者の意図どおりに振る舞うのも、すべてシステムプロンプトのおかげだ。

その「見えない手」を自分で書けるようになれば、AIの振る舞いを根本から制御できる。

効果的なシステムプロンプトの5層構造

第1層：アイデンティティと目的

AIが「何者」で「なぜ存在するか」を定義する。

あなたはM&Aバリュエーションに15年の経験を持つシニア財務アナリストです。
厳密な分析を通じて、ユーザーの健全な財務意思決定を支援します。

「シニアアナリストである」AIと「財務を手伝う」AIでは、出力が根本的に異なる。

第2層：推論フレームワーク（最重要）

AIがどう考えるかを定義する層。5層の中で最も影響が大きい。

財務分析の推論プロセス：
1. まず主要な変数と前提条件を特定する
2. 結論を述べる前に少なくとも2つの分析フレームワークを検討する
3. 結論の前に推論を示す
4. 不確実性を定量化する——財務予測を確定として述べない
5. 前提が誤った場合に結論が変わる箇所にフラグを立てる
6. 常にダウンサイドシナリオを検討する

第3層：行動ガイドライン

AIのコミュニケーションスタイルと人格を定義する。

コミュニケーション原則：
- 結論を先に明確に述べてから説明する
- 平易な言葉を使う。専門用語を使う場合は定義する
- データが根拠となるなら、ユーザーに反論する。同調的な分析は危険
- 知らないことは認める。データを捏造しない
- 不確実な場合、確信度（高・中・低）を示し理由を説明する

第4層：制約とガードレール

過剰な制限なしに、よくある失敗を防ぐ。

制約：
- 具体的な投資助言をしない（「この分析に基づくと検討の余地がある」とする）
- 予測は推定であり保証ではないことを常に注記する
- 財務分析以外の質問には丁寧にリダイレクトする
- 手持ちデータでは回答できない場合、そう述べてデータの入手先を提案する

第5層：出力構造

応答のフォーマットを定義する。

応答フォーマット：
- 1文のエグゼクティブサマリーから始める
- 分析をヘッダー付きで構造化する
- 主なリスクとネクストステップで締める
- 比較にはテーブル、リストには箇条書きを使う
- ユーザーが詳細を求めない限り800語以内

✅ Quick Check: AIを定常的に使っているタスクを思い浮かべてみよう。毎回指定しなくてもよいように、どんな振る舞いをシステムプロンプトに「焼き込み」たいか？

推論フレームワークの設計

汎用推論フレームワーク

大半の分析タスクの出発点として使える：

推論プロセス（すべての応答でこれに従う）：

理解：答える前に、質問を自分の言葉で言い換える。
ユーザーが本当に聞いていることは何か？完全な回答とはどのようなものか？

分解：問題を要素に分割する。わかっていること、
調べる必要があること、置いている前提を特定する。

分析：各要素を体系的に検討する。
関連する場合は複数の視点やアプローチを検討する。

統合：要素を一貫した回答にまとめる。
内部の整合性を確認する。

評価：回答を提示する前に、批判的に検討する。
最も強い反論は何か？何について間違っている可能性があるか？

ドメイン特化型フレームワーク

法務分析用：

法的推論フレームワーク：
1. 論点：法的論点を特定する
2. 規範：適用される法律・規制・判例を提示する
3. 適用：規範を具体的事実に当てはめる
4. 反論：相手方の最も強い主張を検討する
5. 結論：確信度付きで結論を述べる
6. 注意：管轄の違いと弁護士への相談タイミングを注記する

適応的制約の原則

よくある間違い：システムプロンプトを硬すぎるルールにすること。

硬すぎる例：

常に5段落で応答する。箇条書きは使わない。
質問はしない。常に「分析に基づくと...」で始める。

→ ユーザーが短い答え、リスト、または確認を必要とした瞬間に壊れる。

適応的な例：

デフォルト構造：キーインサイトから始め、分析で裏付ける。
内容に最適なフォーマットを使う——比較にはテーブル、
リストには箇条書き、繊細な議論にはパラグラフ。
応答の長さは質問の複雑さに合わせる。

単純な事実確認：1〜3文。
分析的質問：ヘッダー付き構造化分析。
複雑な問題：フレームワーク全体のウォークスルー。

原則：推論を制約し、フォーマットは制約しない。 AIにどう考えるかを伝え、最良の伝え方は任せる。

システムプロンプトのテスト

信頼する前に、以下のシナリオでテストする：

通常ケース： ドメイン内の標準的な質問。推論フレームワークに従っているか？

エッジケース： 専門領域の境界にある質問。不確実性を適切に処理するか？

敵対的ケース： キャラクターを崩させたり、悪い助言を引き出そうとする試み。ガードレールが機能するか？

曖昧なケース： 複数の解釈が可能な質問。確認を求めるか、思い込むか？

矛盾ケース： ガイドラインに矛盾する情報の提供。その緊張をどう処理するか？

ワークフローにおけるシステムプロンプトの組み合わせ

推論アーキテクチャでは、システムプロンプトは単独ではなく連携する。ワークフローの各ステージに異なるシステムプロンプトを設計する：

ステージ1——リサーチアナリスト： 情報を収集・統合。網羅性とソース評価に焦点を当てた推論フレームワーク。

ステージ2——批判的評価者： アナリストの出力をレビュー。弱点・ギャップ・根拠のない主張を見つける推論フレームワーク。

ステージ3——戦略設計者： 検証済みリサーチをもとにソリューションを設計。エビデンスに基づく創造性に焦点。

各ステージのシステムプロンプトがAIの「思考モード」を切り替える。

Key Takeaways

• システムプロンプトには5つの層がある：アイデンティティ、推論フレームワーク、行動ガイドライン、制約、出力構造
• 推論フレームワークが最も影響が大きい——AIのすべての問題アプローチを形作る
• 推論を制約し、フォーマットは制約しない——適応的制約が硬いルールに勝る
• 体系的にテストする——通常・エッジ・敵対的・曖昧・矛盾のケースで
• ワークフローではステージごとに異なるシステムプロンプトで思考モードを切り替える

Up Next

レッスン3：マルチステップ推論とチェーン設計——単一プロンプトでは解けない問題を、協調するプロンプトのシーケンスで解く方法を学ぶ。