この記事について
この記事は、生成AIを活用した自動生成フローで作成しています。OpenAI・Google・Anthropicの現在の公式プロンプトガイダンスを確認し、旧版の「12のテクニックを全部盛り込み、長いCoTや自己評価を追加すれば性能を最大化できる」という構成を、目的・境界・出力仕様・検証を中心とする実務ルールへ見直しました。検証ステータス：📘 OpenAI・Google・Anthropic公式情報確認済み／モデル横断ベンチマークは未実施
プロンプト設計で陥りやすいのは、テクニックを増やすほど精度が上がると思ってしまうことです。現在のモデルでは、古いモデル向けに作った長い「呪文」が、逆に過剰な推論や指示競合を起こすことがあります。
そこで、実務で使うときに確認しやすい12項目へ整理します。全部を毎回入れるのではなく、必要なものだけ選ぶチェックリストとして使うのがポイントです。
1. 目的を一文で書く
最初に「何を完成させたいか」を一文で決めます。
目的: 会議メモから、担当者と期限が明記されたアクション項目を抽出する。2. 成功条件を決める
良い回答の条件をモデル任せにしません。
成功条件:
- 担当者が不明な項目は「未確定」とする
- 日付を推測しない
- 元文にない作業を追加しない3. 指示とデータの境界を分ける
長い入力では、業務データの中の文章を命令として扱わないよう、役割を分けます。
<instructions>アクション項目を抽出する</instructions>
<meeting_notes>...実データ...</meeting_notes>4. 必要な背景だけ渡す
「詳しくするため」に関係の薄い資料まで詰め込むと、重要情報が埋もれます。判断に必要な背景、用語、例外だけを入れます。
5. 出力形式を先に決める
人が読む文章なのか、後段プログラムが読むJSONなのかで設計は変わります。機械処理するなら、対応APIのStructured OutputsやJSON Schemaを優先します。
6. 型で表せる制約は型にする
High / Medium / Low のような選択肢は、自然言語で「必ずこのどれか」と何度も書くより、enumなどの型で表現できる場合があります。
7. 良い例を少数入れる
形式や判断基準が言葉だけで伝わりにくいときは、実際のユースケースに近い入出力例を使います。例は「成功例だけ」ではなく、境界ケースも混ぜると評価しやすくなります。
8. ツールを使う条件を明確にする
検索、計算、ファイル操作などを使える場合は、ツール名だけでなく「いつ使うか」「何には使わないか」も示します。
最新価格が必要な場合だけ検索を使う。
与えられたCSV内の集計には検索を使わず、計算ツールを使う。9. 不要な逐語的CoTを要求しない
「必ず思考過程を全部書け」とするより、最終回答に必要な根拠、確認結果、未確定点を短く返させる方が扱いやすい場面があります。
回答に含めるもの:
- 結論
- 根拠
- 未確認事項
- 次に確認すべきこと10. 検証できるものは外で検証する
JSONの構文、日付形式、ID存在確認、計算結果、コードテストなどは、モデルの自己申告だけに頼らずアプリ側やツールで確認します。GoogleのStructured Outputsも、構文が正しくても値の意味が正しいとは限らないため、アプリケーション側の検証を推奨しています。
11. 評価用の固定ケースを持つ
プロンプトを変えるたびに「なんとなく良くなった」で判断せず、10件でもよいので同じ入力セットで比較します。
| ケース | 見るもの |
|---|---|
| 通常ケース | 期待した内容が出るか |
| 情報不足 | 推測せず未確定にできるか |
| 長文 | 重要情報を落とさないか |
| 例外値 | 型や制約を守るか |
12. モデル更新時に古いプロンプトを疑う
主要モデルは世代ごとに、指示追従、推論、ツール利用、長文処理の挙動が変わります。GoogleはGemini 3.x系について、旧世代向けの冗長なプロンプトが過剰分析を招くことがあるとして、明確で簡潔な指示を案内しています。Anthropicもモデル世代ごとの移行調整を案内しています。
コピペ用：最小テンプレート
<goal>
何を完成させるか
</goal>
<context>
判断に必要な背景だけ
</context>
<input>
実データ
</input>
<requirements>
- 必須条件
- 禁止事項
- 不明な場合の扱い
</requirements>
<output>
必要な形式
</output>
<verification>
最終回答で確認する項目
</verification>まとめ
プロンプト設計は、テクニックの数を競う作業ではありません。まず目的と成功条件を決め、入力の境界を分け、構造化できるものは型にし、検証可能なものは外部で確認します。
12項目すべてを詰め込むより、「今回の仕事でどれが必要か」を選ぶ方が、短く保守しやすいプロンプトになります。
公式情報・一次情報
- OpenAI API ― Model guidance
- Google Gemini API ― Structured outputs
- Google Gemini API ― What’s new in Gemini 3.5
- Anthropic ― Prompting best practices
この記事の更新履歴
- 2026-09-13 追加：成功条件、Structured Outputs、外部検証、固定評価ケース、モデル更新時の見直しを追加。
- 2026-09-13 変更：「12テクニック全部盛り」から、必要な項目を選ぶ実務チェックリストへ再構成。
- 2026-09-13 削除：内部style_prompt、本文H1、旧モデル名への依存、逐語的CoTと自己評価を性能向上の必須条件とする記述を削除。
