生成AIの代表格である「ChatGPT」「Claude」「Gemini」だが、モデルごとに、公式が推奨しているプロンプトのスタイルが異なることをご存知だろうか?
たとえChatGPTでうまく動いたプロンプトであっても、そのままコピペしてしまうと、ClaudeやGeminiとの相性が悪く、意図した通りの結果が得られないかもしれない。
3つのAIモデルを使い分けるのが当たり前になってきた昨今、各モデルに「どう書けば最も伝わるか」を理解しておくことは重要だ。
本記事では、OpenAI、Google、Anthropicなどの公式ドキュメントを読み解き、各社が推奨するプロンプト・エンジニアリングの技法をまとめた。
ChatGPT=フォーマット契約、Claude=XMLタグ、Gemini=Few-shotという各モデルの「推奨プロンプト技法」を、公式ドキュメントの記述を根拠に解説していく。
同じプロンプトでも結果が変わる:Claude・ChatGPT・Geminiの主な違い
ChatGPT、Claude、Geminiのそれぞれについて、開発する各社が「自社モデルに特に有効」と公式に強調している技法は、ざっくり次のように整理できる。
| モデル | 公式推奨 | 概要 |
|---|---|---|
| Claude(Anthropic) | XMLタグによる構造化 | 指示・資料・例を <タグ> で区切る |
| ChatGPT(OpenAI) | Markdown起点の構造化指示 | 役割・手順・出力形式を「契約」として先に決める |
| Gemini(Google) | Few-shot(例示) | 望ましい出力を「例」で見せる |
ただし、3社とも共通している「構造化すること」や「例示すること」は、生成AIの出力の質を高める上で普遍的に有効な手段だ。
上記の表は、排他的な専用技ではなく、あくまで各社が重視・強調しているポイントや、推奨度合いの温度差をまとめたものだと理解してほしい。
ちなみに、そもそも、なぜモデルごとにこうした相性が生まれるのだろうか?
最大の要因は、各社が使用している学習データとポストトレーニング(公開後にモデルへ施す追加調整)の違いにある。
モデルは訓練中に大量に見てきた形式を「自然」と感じ、それに沿った入力をうまく処理する傾向がある。
例えば、Claude が XML を好む理由については、Anthropic の社員が「Claude は学習データに大量の XML を含めて訓練されたため」といった旨の発言をしている。
Claude の公式推奨プロンプト:XMLタグで区切る
Claudeについて、Anthropicが公式に推奨している技法は、プロンプトの各要素を XML タグで囲んで区切ることである。
XML タグとは、「開始タグ」と「終了タグ」を用いて、テキストの塊を囲う記法だ。終了タグにはバックスラッシュを含めることで、終点がどこかを明示できる。
<example>ここに例を記載する</example>Anthropic の公式のプロンプトエンジニアリングガイドでも、次のようにXMLタグの利点を明示している。
XMLタグは Claude が複雑なプロンプトを曖昧さなくパースするのに役立つ。特にプロンプトが指示・文脈・例・変数入力を混在させているときに有効だ。各種類のコンテンツを独自のタグ(例:
<instructions>、<context>、<input>)で包むと、誤解釈が減る。
Claudeをもっと賢くする「XMLタグ」の使い方
具体例で見てみよう。例えば、大量の製品レビューをClaudeに要約させたいとして、以下のようなプロンプトを書いたとする。
指示・対象・出力形式がすべて一文に詰め込まれており、Claude はどこからどこまでが「資料」でどこが「指示」なのか判断しづらい。
次のレビューを3点に要約して、最後に総合評価を5段階で付けてください。レビュー:このノートPCは軽くて持ち運びやすいが、バッテリーが半日しか持たず、ファンの音が大きい。価格は手頃だと思う。そこで、XMLタグを用いて、プロンプトを構造化する。
<instructions>レビューを読み、以下を出力してください。1. 良い点・悪い点を箇条書きで3点2. 総合評価を5段階で1つ</instructions>
<review>このノートPCは軽くて持ち運びやすいが、バッテリーが半日しか持たず、ファンの音が大きい。価格は手頃だと思う。</review>
<output_format>- 箇条書き3点- 総合評価: ★n/5</output_format>タグで役割を分けると、Claude は「何が資料で、何が指示で、どんな形式で返すべきか」を間違いにくくなる。
先の例のように、一文でベタ打ちにしてしまうと、Claude がレビューの一部を指示と取り違えたり、箇条書きで要約してほしいのに文章で返してしまったり、プロンプトを正しく追従できなくなるリスクがあるのだ。
XMLタグを使い慣れていない人のために、タグを作成する際のコツを紹介しておく。
- 一貫した分かりやすいタグ名を使う
<instructions>や<review>のように中身が想像できる名前にする
- 自然な階層がある場合はタグをネストする
- 例)複数の文書があるなら、
<documents>の中に個々の<document>を入れる - 例)
<document index="1">など番号を振ることも可能
- 例)複数の文書があるなら、
- サブタグを活用してさらに構造化する
- 例)文書ごとに、ファイル名を
<source>タグ、コンテンツを<content>に記載
- 例)文書ごとに、ファイル名を
例えば、2つのPDFファイルの中身をコピペしてClaudeに読ませたいとすると、以下のようにネストする。どこからどこまでが1つ目のファイルなのかの境界や、それぞれのファイルの名前が、Claudeに的確に伝わる。
<documents>
<document index="1"> <source>製品マニュアル.pdf</source> <document_content> (ここに長い本文) </document_content> </document>
<document index="2"> <source>保証書.pdf</source> <document_content> (ここに長い本文) </document_content> </document>
</documents>
上記の文書に基づき、保証期間について回答してください。資料は最上部に、指示は最下部に置くのが正解
また、人間の直感に反するであろうコツとして、Claudeに対する指示や質問は、プロンプトの最後の置くことが推奨されている。
Anthropicによれば、20kトークンを超えるような長い文書・データは、プロンプトの最初(クエリ・指示・例より上)に置く方が良いらしい。
そのうえで、クエリ(質問)を末尾に置くと、「複雑なマルチ文書入力で応答品質が最大30%向上することがテストで確認された」と明記しているのだ。
なおこのプロンプトの「配置」「順序」の話は、OpenAI、Anthropic、Googleの3社で微妙に異なるため、本記事の後半で横断的に対比する。
ChatGPTの公式推奨プロンプト:Markdownで形式誘導
ChatGPTの場合、OpenAI のプロンプトエンジニアリングガイドは、プロンプトを4つの標準セクションで組み立てることを推奨している。
以下の4つを、Markdownの見出しによって構造化して、必要に応じてXMLタグも使用しながら、冒頭に配置する。
- Identity: 目的・コミュニケーションスタイル・高レベルの目標
- Instructions: 何をすべきか、決してすべきでないか
- Examples: 入力例と望ましい出力例
- Context: 追加情報(プロンプト末尾近くが最適)
ChatGPTに本題を投げる前に、「あなたは何者で、何をすべきで、どんな形式で返すか」を構造化テキストで先に決めておくのだ。
ChatGPTの「4部構成」テクニックの使い方
実際のプロンプト例で、このフォーマットを適用してみよう。
多くの人が使いがちな、素朴な一文プロンプトは以下のようなものだろう。
カスタマーサポートの返信文を書いて。怒っているお客さんに、返金はできないけど代替案を出す感じで。これを、OpenAI公式の推奨フォーマットに落とし込むと、以下のようになる。
#記号は、Markdownにおける「見出し1」であり、文章の構造を的確にChatGPTに伝えることができる。
# Identityあなたは丁寧で冷静なカスタマーサポート担当である。顧客の不満を受け止めつつ、解決策を提示することが目的だ。
# Instructions- まず謝罪と共感を1文で示す- 返金はできない旨を、理由を添えて伝える- 代替案を2つ提示する- 攻撃的・防御的な表現は使わない
# Output Format- 200字以内- 敬体(です・ます調)
# Context顧客は注文した商品が遅延し、返金を要求している。社内ポリシー上、返金は不可だが、次回使えるクーポンと優先配送を提案できる。骨格を Markdown 見出しで明示するだけで、GPT は各セクションの役割を正しく理解できるようになる。
Markdownを優先使用し、長文ではXMLも使う
では区切り文字は何を使うべきか。出典は少し古いものだが、OpenAI の GPT-4.1 向けのガイドでは、明快な優先順位が示されていた。
Markdown: ここから始めることを推奨する。主要セクションとサブセクションには Markdown 見出しを使い、H4以降の深い階層まで活用する。 XML: これも良好に機能する。GPT-4.1 では XML 内の情報への追従が改善した。開始・終了の正確なラッピング、タグへのメタデータ付与、ネストに便利だ。
つまり優先順位は「まず Markdown、長文や多数文書では XML」となる。
最新のOpenAIのAPIドキュメントにあるプロンプトのフォーマットの項を見ても、同様にMarkdownとXMLの使用が推奨されている。
まずはMarkdownの使用が勧められているものの、「XMLタグ」はClaude専用の手段と言うわけではなく、ChatGPTでも通用する。
実際、GPT-5 向けガイドでも、Cursor開発チームの知見として「<[instruction]_spec> のような構造化 XML スペックを使うと指示追従が改善した」という例が紹介されている。
Geminiの公式推奨プロンプト:「Few-shot」が超大事
Gemini の代表的な技法は Few-shot、つまり望ましい入出力の「例」を、いくつかプロンプトに含めることである。
Google はこの技法を、3社の中でも最も強い表現で推奨している。Google のGemini API ガイドは、次のように述べている。
few-shot 例を常にプロンプトに含めることを推奨する。few-shot 例のないプロンプトは効果が低い可能性が高い。実際、例が十分にタスクを示しているなら、プロンプトから指示を削除することすらできる。
「常に入れよ」「例がないと効果が低い」という、かなり踏み込んだ表現だ。この温度感は、明確にChatGPTやClaudeのドキュメントよりも、Geminiの方が強い。
Googleが強く勧める「Few-shot」の使い方
Few-shot が特に効くのは、文体・分類基準・出力フォーマットなど「言葉で説明しづらい基準」を伝えたいときだ。
ルールを長々と書くより、望ましい出力を1〜2個見せたほうが速く正確に伝わる。
例えば、一切例を示さない(Zero-shot)、以下のようなプロンプトを使ったことのある人は多いのではないだろうか。
次の問い合わせを「請求」「技術」「その他」のどれかに分類してください。問い合わせ:アプリが起動後すぐ落ちます。このありふれたプロンプトを、「Few-shot」スタイルに直すと以下のようになる。
問い合わせを「請求」「技術」「その他」のどれかに分類してください。
入力:先月分が二重に引き落とされています。出力:請求
入力:ログインしようとするとエラー画面が出ます。出力:技術
入力:アプリが起動後すぐ落ちます。出力:最後の「出力:」まで書いて続きを補完させるのが、Google が「completion戦略」(モデルに応答の書き出しだけを与え、その先を続きとして埋めさせる手法)と呼ぶ書き方だ。
応答の冒頭をいくつか例として与えることで、形式を踏襲させやすくなる。
ちなみに、「例が十分なら指示を削れる」は公式の表現だが、実務では指示と例の両方を残すのが無難だ。
Google自らが、Vertex AI 版の公式ガイドで「few-shot 例には必ず明確な指示を併記せよ。指示がないと、モデルが意図しないパターンを拾うことがある」と注意を促しているので、指示は残しておいた方がいい。
XMLを使って一貫した「例」を示す
Few-shot で「回答例」を示す上で特に重要なのは、その例自体が一貫したフォーマットで完璧に整っていることだろう。Gemini API ガイドでも、次のように強調されている。
few-shot 例の構造と整形を全例で同一にせよ。望ましくないフォーマットを避けるためだ。特に XMLタグ・空白・改行・例の区切りに注意すること。
ここでも XMLタグへの言及がある通り、Gemini の few-shot は「XML的なマークアップ+一貫した整形」が公式の推奨スタイルだ。
同じくGoogle公式のVertex AI ガイドは、例を XMLライクなマークアップで囲む具体例を示している。
テキストから技術仕様を JSON 形式で抽出してください。
<EXAMPLE> INPUT: Google Nest Wifi, 通信速度最大1200Mbps, 2.4GHzと5GHz, WPA3対応 OUTPUT: { "product": "Google Nest Wifi", "speed": "1200Mbps", "frequencies": ["2.4GHz", "5GHz"], "protocol": "WPA3" }</EXAMPLE>
Google Pixel 7, 5G対応, 8GB RAM, Tensor G2, ストレージ128GBまた、「Few」といっても、いくつの例を示すのがベストなのか。Gemini は少数の例でパターンを掴めるが、例が多すぎると、与えた例の細部に過剰に引きずられてバイアスがかかり、本来の指示より例の体裁を優先した出力を返すことがある。実務では2〜3例から始め、結果を見て増減するのがよい。
また、Gemini を API から呼び出す場合は、文字量が増えることによるコストも意識したい。例を1つ追加するたびに入力トークンが増え、その分の従量課金額とレイテンシが増える。精度向上とコストのバランスを見て、必要十分な例数に絞り込みたい。
3大AIモデルまとめ:構造化・例示・小テスト
各社それぞれ微妙に温度差はあるものの、大きな方向性としては、(MarkdownやXMLで)構造化すること、指示と資料を分離すること、具体例を示すことなどで共通している。
3社の主な相違点を見ておくと、以下のようにまとめられるだろう。
- Claude : XMLタグを推奨。Markdownは補助使用可。Few-shotも推奨。
- ChatGPT : Markdownを推奨。XMLも併用。Few-shotは標準。
- Gemini : Few-shotを推奨。XML / Markdownはどちらかを一貫して使用することを推奨。
複数のAIモデルを使い分けるときには、XMLとMarkdownのどちらを使うか、例示をどこまで重視するか、各モデルの特徴を踏まえて吟味してみよう。
長文コンテキストの置き方は微妙に異なる
長文(資料・データ)と指示をどのような位置関係で配置するかは、3社で推奨が微妙に異なる。
| モデル | 公式が推奨する配置 |
|---|---|
| Claude | コンテキストを冒頭に置き、指示を末尾に置く。 |
| Gemini | コンテキストを冒頭に置き、指示を末尾に置く。 |
| ChatGPT | コンテキストは末尾に置く。 |
Claude と Gemini は「資料を先、質問を末尾に」が基本だ。
Claude は「クエリを末尾に置くと最大30%改善」とまで言っている。また、Google のガイドは、「上記の文書全体に基づき…」のような橋渡しのフレーズで指示を始めると、モデルの注意を資料側につなぎ留め(anchor)られると推奨している。
一方のChatGPTは、「プロンプトごとにコンテキストを差し替えるために便利だから末尾に置く方がいい」、という程度でサラッと書かれており、モデルの性能に影響するような記述は見られない。
資料(長文データ)と指示を1つの塊に混ぜず、明確に分離することは、少なくとも全社共通のルールだ。
小さな検証テストで自分の業務プロンプトを確かめる
公式のプロンプトエンジニアリングガイドから学べるコツは、多くのシーンに妥当する最大公約数的な知見であって、出発点に過ぎない。
最終的に効くのは、自分の用途で実際に実験を繰り返すことだ。
- 同じ種類の入力を5〜10件用意する(実際の業務データが望ましい)
- 3モデル用にそれぞれプロンプトを書く(Claude=XML、GPT=4部構成Markdown、Gemini=few-shot から始める)
- 各モデルの出力を、出力形式・正確性・再現性・修正の手間で採点する
- 何度か繰り返す
- 一番安定したプロンプトを、一番安定したモデルで使用する
3社とも公式ガイドで「反復・実験せよ」と繰り返し述べている。
公式を読むだけで終わらせず、この小さな検証テストを1回回すだけで、自分の業務に最適な書き方が見えてくる。
モデル別プロンプトテンプレート
最後に、本記事で整理したプロンプトのコツを、Claude、ChatGPT、Geminiそれぞれについて、コピペしてそのまま使えるテンプレートに落とし込んでみた。
Claude 用プロンプトテンプレート(XML重視)
<instructions>(ここにやってほしいこと。やるべきこと・やってはいけないことを明示)</instructions>
<context>(背景情報・前提)</context>
<input>(処理対象のデータ)</input>
<output_format>(出力形式の指定)</output_format>ChatGPT 用プロンプトテンプレート(Markdown重視)
# Identity(役割と目的)
# Instructions- (やるべきこと)- (やってはいけないこと)
# Examples(出力形式・例)
# Context(背景情報。末尾近くが最適)Gemini 用プロンプトテンプレート(few-shot)
(タスクの指示を1〜2文で)
<EXAMPLE>INPUT: (入力例1)OUTPUT: (望ましい出力例1)</EXAMPLE>
<EXAMPLE>INPUT: (入力例2)OUTPUT: (望ましい出力例2)</EXAMPLE>
INPUT: (実際の入力)OUTPUT: