JSON Promptingは「ChatGPT・Claude・Geminiを一律に賢くする万能スキル」ではありません。
Anthropic公式はClaude向けにXMLタグを第一推奨、OpenAIはAPIならStructured Outputs・非APIならXMLデリミタ、Geminiはresponse_mime_type指定が公式の答えです。
「ハルシネーション60%減・企業の70%が導入」系の数字は一次調査の裏付けがなく、社内資料への転載は要注意です。
この記事はChatGPT・Claude・Geminiで業務プロンプトをチーム共有したい担当者向け（プログラミング知識は不要、JSONとMarkdownの違いがなんとなく分かれば読めます）。
そもそもJSON Promptingって何を指している言葉？
言葉の整理から入ります。
「JSON Prompting」という語は2つの違う文脈で使われています。
- (A) 人間がAIに渡す指示をJSON形式で書く（プロンプト構造化）
- (B) AIにJSON形式で出力させる（構造化アウトプット）
SNSでバイラルになっている「最も過小評価されたAIスキル」系の投稿は、ほぼ(A)の話です。
推進派のテンプレは task / input / output_format / constraints / examples / tone というキー構成で共通しています。
一方、OpenAIのStructured OutputsやGeminiのresponse_mime_typeは(B)のAPI機能で、話が別物。
この2つを混ぜると議論が噛み合わなくなります。
ここが最初の分岐点。
推進派はJSON Promptingをどう語っているのか
SNS発のバイラル投稿では「JSON PromptingはChatGPT・Gemini・Claudeを一貫した構造化エージェントに変える、最も過小評価されたAIスキル」という主張が広がりました。
日本語ブログでもこの論調をなぞった解説が多数出ています。
推進派の解説でよく並ぶ数字はこの4つです。
- ハルシネーション60%減
- 企業の70%が導入
- 一貫性が40%向上
- 精度95%
きれいに揃いすぎている数字。
出所をたどると、海外の個人ブログ1本に行き着きます。
そのブログ内には外部調査も論文も引かれておらず、著者の自己テストと業界観察という自己申告だけが根拠です。
日本語の二次紹介記事はここを経由して数字だけを独り歩きさせています。
私はこの数字をそのまま信じて社内でテンプレ共有するのは危ういと感じます。
あとで突っ込まれた時に根拠が出せなくなる構造になっているからです。
慎重派・反対派の一次ソースはどう語っているのか
推進派の裏側で、実装寄りの開発者の意見はかなり辛口です。
実装側で広く共有されている批判の核は次の2点です。
- JSONが他の構造化フォーマットより優れているわけではない
- Markdownなら同じ結果をもっと少ないトークンで出せる
私はこの2点目がとくに実務に効いてくると思います。
トークン効率の差は、OpenAIの公式コミュニティフォーラムにある実測スレッドで具体的な数字になっています。
同じ内容をJSON・YAML・Markdownで書き分けてOpenAI公式のtiktokenでカウントした結果です。
| 形式 | トークン数（同一内容） | JSON比 |
|---|---|---|
| JSON | 13,869 | 基準 |
| YAML | 12,333 | 約11%削減 |
| Markdown | 11,612 | 約16%削減 |
クォート・ブレース・カンマの構文記号がトークンを食う構造的な問題です。
私は数字で見ると想像以上に差が出ていると感じました。
月100万トークン使うチームなら約16%差は請求額にそのまま乗ります。
さらに、構造化出力を扱う実装者向けの解説では「JSONで返してとプロンプトで頼むこと自体が弱い」という指摘も出ています。
モデルは「Here's the JSON output you requested:」のような余計な前置きを付けてくることがあり、プロンプトでお願いするだけでは形式が崩れます。
OpenAI公式の構造化出力解説でも、プロンプトで頼むだけでは形式遵守は保証されず、API側で構造的に強制する方が確実だという方向性が示されています。
API機能（OpenAIのStructured OutputsやGeminiのresponse_mime_type）で強制する方が、プロンプトで頼むより外しません。
推進派が「最も過小評価されたスキル」と呼ぶものを、実装側は「無駄に膨らんだ構造」と捉えている。
私はこの温度差こそ、チーム共有前に押さえておくべき情報だと思います。
Claude・ChatGPT・Geminiでは公式推奨がそれぞれ違う
ここがこの記事の核です。
「JSONが正解」ではなく、モデルごとに公式の推奨が違います。
| モデル | プロンプト構造化の公式推奨 | 構造化出力の公式機能 | 一次ソース |
|---|---|---|---|
| Claude (Anthropic) | XMLタグ（<instructions> <context> <example> 等） |
専用機能なし（プロンプトで指定） | Anthropic公式ドキュメント |
| ChatGPT (OpenAI) | XMLデリミタ推奨（非API）／o-seriesは「simple and direct」 | Structured Outputs（response_format: json_schema） |
OpenAI公式発表 |
| Gemini (Google) | プロンプト構造化の明示的推奨なし | response_mime_type: "application/json" + response_json_schema |
Google公式ドキュメント |
Anthropic公式の表現はこうです。
XML tags help Claude parse complex prompts unambiguously. ... there are no canonical 'best' XML tags that Claude has been trained with in particular, although we recommend that your tag names make sense with the information they surround.
ClaudeはXMLタグを含む訓練データで学習しているため、構造的マーカーとして強く認識します。
公式ドキュメントの中に「JSON形式でプロンプトを構造化する」という節は存在しません。
OpenAIの非API向け推奨は、推論モデル（o-series）の公式プロンプトガイドでも明示されています。
Use delimiters like markdown, XML tags, and section titles to clearly indicate distinct parts of the input, helping the model interpret different sections appropriately. ... Some prompt engineering techniques, like instructing the model to "think step by step," may not enhance performance.
API経由でChatGPTを呼ぶ実装なら、プロンプトで「JSONで返して」と頼むよりStructured Outputsでスキーマ遵守を強制した方が確実です。
OpenAI公式はgpt-4o-2024-08-06でのスキーマ遵守率を100%と計測しており、旧gpt-4-0613（40%未満）から大幅に改善したと発表しています。
Geminiはresponse_mime_typeとresponse_json_schemaの指定で出力形式を固定できます。
プロンプト本文の構造化フォーマットは任意です。
公式ドキュメントには制限も明記されています。
The API may reject very large or deeply nested schemas. ... The model ignores unsupported properties.
3モデル横断で共通する事実はひとつ。
どのモデルも「プロンプトをJSONで書くと劇的に賢くなる」とは公式に主張していません。
非エンジニアの業務テンプレではどの形式を選ぶべきか
ここから使い分けの地図です。
ChatGPT・Claudeを毎日回している業務担当者が、チームでプロンプトを共有するときに何を選べば良いのかを整理しました。
| 用途 | 推奨フォーマット | 理由 |
|---|---|---|
| Claudeに長文の分析・ライティング指示 | XMLタグ（<instructions> <context>） |
Anthropic公式推奨。訓練上の親和性 |
| ChatGPTで繰り返し業務（要約・分類・メール作成） | Markdown構造＋見出し／または XMLデリミタ | OpenAI公式推奨。トークン効率が良い |
| ChatGPTにAPI経由で厳密なJSONを返させる | Structured Outputs（response_format: json_schema） |
スキーマ遵守100%、プロンプト工夫より確実 |
| Geminiでデータ抽出・分類 | response_mime_type: "application/json"指定 |
MIME type指定で出力形式が確実に固定される |
| 推論・創造系タスク（アイデア出し・文章生成） | 自然言語 or Markdown | JSON強制は推論性能を下げるという報告あり |
推論タスクへの悪影響については、複数のLLMフォーマット比較ブログで「JSON出力を強制すると推論タスクの性能が10〜15%落ちる」という観測が共通して報告されています。
一次の公式数字ではないものの、複数の独立した実装ブログで似た傾向が指摘されているので、実務で参考にする価値はあります。
推奨されている運用は「フリーフォームで推論させる → 後段で構造化フォーマットに整形する」の2ステップ構成です。
プロンプト解説系のブログでも同じ方向の具体例が出ています。
例として「ラブレターを書いてキーnoteのJSONで返して」とお願いするより、まず「ラブレターを書いて」だけで生成させた方が文章の質が上がる、というものです。
私の見方では、この2ステップ運用がいちばん実務に乗せやすいです。
テンプレはMarkdownかXMLで持っておいて、アウトプットを機械処理する段だけJSON化すれば、トークンも節約できるし推論品質も落ちにくいです。
「JSONテンプレをひとつ作って全業務で流用」は、見た目はきれいでも最適解ではありません。
私なら少なくとも「Claude用」「ChatGPT非API用」「API強制出力用」の3系統に分けて持ちます。
「60%減・70%導入」の数字はどう扱うべきか
日本語のJSON Prompting記事で最もよく見る数字がこれです。
- ハルシネーション60%減
- 企業の70%が導入
- 一貫性40%向上
- 精度95%
出所をたどると全て同じ海外個人ブログ1本に集約されます。
同記事内に外部調査・論文・第三者計測の引用はありません。
根拠は著者の自己テストと業界観察だけです。
参考までに、JSON Prompting「特有」ではないですが近い数字として、2025年のマルチモデル研究でプロンプトベースの緩和策がGPT-4oのハルシネーション率を53%→23%に下げた報告があります。
これは構造化プロンプト全般の効果で、JSON形式に限定した結果ではありません。
社内で共有する資料にこの数字を書く場合、私は「出所は個人ブログの自己申告で一次調査の裏付けは公開されていない」と必ず注記するか、数字ごと省略する運用が安全だと感じます。
提案資料に根拠不明の95%を書いて上司に1回でも突っ込まれたら、その後の信用が3割は削れます。
数字の重みは根拠の強さで決まる。
JSON Prompting推進派の主張でも拾うべき部分
ここまで慎重寄りの話が多くなりました。
とはいえ、推進派の指摘で実務的に正しい部分もあります。
非エンジニア向けのJSON学習論として国内でも紹介されているのは、「JSONで物事を考えることは、ロジックではない目の前のデータについてのみ考えること」という整理です。
プログラミングを覚えずに「データ構造の頻出パターン」を扱えるようになる、という意義はそのとおりだと感じます。
プロンプト解説系のブログでも、本番運用については一貫した整理があります。
「天才的な回答が時々出る」より「7割の品質で毎回同じ構造で返ってくる」方が価値が高い、という指摘です。
私はこれは実務感覚として正しいと思います。
月100件処理する業務で1件だけ天才アウトプットが出ても、残り99件が形式バラバラなら結局人間が後処理する羽目になります。
まとめると、JSON Promptingの本質は「AIが急に賢くなるスキル」ではなく、「人間側が欲しい出力を明示的に定義する習慣」です。
後者の効用は否定されていません。
ただ、その習慣を機能させる形式はモデルごとに違います。
Claudeでやるなら最初からXMLタグにした方が公式の訓練と噛み合います。
チームでプロンプトをテンプレ化するときの実務的な指針
業務担当者がチーム共有用のプロンプト集を整備するなら、形式選定は以下の順で考えるのが現実的です。
各ステップで何を決め、どこで詰まりやすいかも添えます。
STEP1. 使うモデルを確定する
Claudeメインか、ChatGPTメインか、Geminiメインか、混在か。
これを最初に決めます。
期待結果: チームの主力モデルが1つに絞れたら、その公式ドキュメントの推奨形式に揃える方針が立ちます。
混在ならモデル別にテンプレを分けます。
詰まりどころ: 「全社でChatGPT契約してるけど自分はClaude派」という状況が一番多いです。
私の判断では、共有テンプレは契約モデル優先、個人作業のテンプレは別フォルダで管理が現実的です。
STEP2. API経由かチャットUIかを切り分ける
APIから呼ぶ実装ならStructured Outputs（OpenAI）やresponse_mime_type（Gemini）で出力形式を強制できます。
チャットUIならプロンプト側で形式を指定する以外に手はありません。
期待結果: APIなら「構造化出力はAPI機能に任せる、プロンプト本文は素直に書く」という方針に変わります。
プロンプトをJSON化する必要はほぼ消えます。
詰まりどころ: 非エンジニアの業務担当者は基本チャットUI側です。
API機能の話は実装担当に投げ、自分はチャットUI向けテンプレに集中するのが時間効率は良いです。
STEP3. タスクが推論寄りか抽出寄りかを判定する
推論・創造系（アイデア出し、文章生成、企画提案）は自然言語+Markdownが向きます。
抽出・分類・定型出力（メールテンプレ、表形式の出力、タグ付け）は構造化フォーマットを積極活用します。
期待結果: 1つのテンプレで全タスクを賄おうとせず、タスク種別ごとにフォーマットを切り替える発想に変わります。
詰まりどころ: 「アイデア出し→構造化整形」を1プロンプトで強引にやろうとして品質が落ちるパターンが多いです。
2ステップ運用（フリーフォームで生成→次のターンで整形）に分けると安定します。
STEP4. 項目の抜け漏れ防止が目的ならMarkdown見出しで十分
JSONキーで「task / input / output_format / constraints」と並べる代わりに、Markdown見出し（## task / ## input / ## output_format）で同じ項目を並べれば抜け漏れ防止には機能します。
トークンも少なくて済みます。
期待結果: 「JSONキー羅列」と「Markdown見出し羅列」の効果の差はほぼなく、トークン消費だけが約16%変わる、という整理に着地します。
詰まりどころ: 推進派のテンプレを丸ごとコピペすると、自然とJSON波カッコまみれの長文になります。
私はテンプレを採用する前に、必ずMarkdown版に書き換えて両方の長さを比較するのを勧めます。
「何でもJSON」は避ける。
逆に「Markdownだけあれば十分」も極端です。
私は、使うモデルとタスクの種類で形式を切り替える方が実務に馴染むと整理しています。
OpenAIが公式に言っているのは「デリミタで構造を示せ」であって、デリミタの種類は問題の本質ではありません。
構造が読み取れれば良い。
FAQ
Q1. 結局JSON Promptingは使うべきですか？
使うべきかどうかはモデルとタスクで変わります。
ClaudeならXMLタグが公式推奨。
ChatGPTのAPIならStructured Outputsで強制した方が確実です。
Geminiならresponse_mime_typeで十分です。
非APIのチャットUIで繰り返し業務を定型化するなら、JSON風キー羅列よりMarkdown見出し構造の方がトークン効率が良いです。
Q2. 「ハルシネーション60%減」という数字は信用できますか？
出所は海外の個人ブログ1本に集約され、同記事内に外部調査・論文の引用はなく、著者の自己申告だけが根拠です。
日本語記事でよく見るのは二次・三次引用で、一次調査は辿れません。
社内資料に使うなら「出所は個人ブログの自己申告で一次調査は非公開」と注記すべきです。
Q3. ClaudeにJSON形式でプロンプトを書くのはダメですか？
ダメとは言われていません。
ただAnthropic公式はXMLタグを第一推奨しており、Claudeは訓練上XMLタグを強く認識します。
JSONでも動きますが、ムダに長くなりやすいです。
同じ情報量なら<instructions>や<context>タグで書く方が公式方針に沿います。
Q4. JSON Promptingで推論タスクが下手になると聞きました
複数のLLMフォーマット比較ブログで「JSON出力を強制すると推論タスクの性能が10〜15%落ちる」という観測が報告されています。
解決策は「フリーフォームで推論 → 後段でJSON整形」の2ステップ運用です。
文章生成・アイデア出しを一発でJSON化しようとしない方が安全です。
Q5. MarkdownとJSONとXML、結局どれが最強ですか？
用途とモデルで変わるので「最強」という答えはありません。
トークン効率はMarkdown優位（JSONより約16%少）。
Claudeの公式親和性はXML。
API経由でスキーマ遵守を強制したいならJSON Schemaです。
形式選定より「欲しい出力を明示する習慣」の方が本質だと感じます。
このページに出てきた言葉
- プロンプト
- AIに渡す指示文。文章、表、JSONなどどんな形式でも書ける
- ハルシネーション
- AIが事実でないことをそれっぽく言い切ってしまう現象。日本語では「幻覚」とも呼ばれる
- トークン
- AIが文章を扱う最小単位。料金もこの数で決まる。日本語1文字≒1トークン、英単語1個≒1〜2トークン
- tiktoken
- OpenAI公式のトークン数カウントツール。プロンプトが何トークンになるか事前に測れる
- XMLタグ
<instructions>...</instructions>のように山カッコで囲んで内容を区切る書き方。HTMLと同じ形- デリミタ
- 区切り記号のこと。XMLタグや三連バッククォートなど、AIに「ここから〜ここまで」を伝える仕切り
- Structured Outputs
- OpenAIのAPI機能。返答を必ず指定したJSON構造で返すよう強制できる
- response_mime_type
- Gemini APIの設定項目。「application/json」を指定すると必ずJSONで返ってくる
- スキーマ
- データの型や項目の決まりごと。「nameは文字列、ageは数値」のような構造定義
- o-series
- OpenAIの推論特化モデル（o1、o3、o4-mini 等）の総称
- LLM
- 大規模言語モデルの略。ChatGPT・Claude・Geminiの中身にあたるAI本体
- フリーフォーム
- 形式の制約を付けず、AIに自由な文章で答えさせること
参考リンク
- Anthropic Claude公式: Use XML tags
- Anthropic Claude公式: Prompt engineering overview
- OpenAI: Introducing Structured Outputs in the API
- OpenAI Platform: Structured Outputs guide
- OpenAI Platform: Reasoning best practices（o-series向け推奨）
- Google Gemini API: Structured output
- OpenAI Community: Markdown is 15% more token efficient than JSON
※この記事の内容は執筆時点のものです。AIは進化が速い分野のため、最新の仕様は公式サイトでご確認ください。