この記事の要点
- JSON Promptingは「万能スキル」ではありません。推進派の主張と一次ソースの反論を並べて地図にしました。
- Claudeの公式推奨はXMLタグ。OpenAIはAPIならStructured Outputs、非APIならXMLデリミタ。Geminiはresponse_mime_type指定。
- 「ハルシネーション60%減・企業の70%が導入」はMPG ONE記事の自己申告で一次調査の裏付けなし。
結論だけ先に書いておきます。
JSON Promptingは「ChatGPT・Claude・Geminiを一律に賢くする万能スキル」ではありません。
Anthropic公式はClaude向けにXMLタグを第一推奨していますし、
OpenAI DevelopersはXに「delimiters (xml tags) will help keep things clean for the model」と投稿しています。
そしてOpenAI Cookbook寄りの開発者 @techwraith は「JSON prompting isn't better than any other structured prompting approach」と真っ向から否定しているんですよね。
この記事では、
JSON Promptingを推す側と「やめてくれ」派の一次ソースを引用で並べつつ、
モデル別・用途別の使い分け地図を表にまとめます。
私は非エンジニアが業務プロンプトをテンプレ化するとき、
どの形式をどのモデルに当てれば良いのかが本筋だと思います。
JSON Promptingとは何を指しているのか
まず言葉の整理から入ります。
「JSON Prompting」という語は、
実は2つの違う文脈で使われているんですよね。
- (A) 人間がAIに渡す指示をJSON形式で書く（プロンプト構造化）
- (B) AIにJSON形式で出力させる（構造化アウトプット）
Xでバイラルになっている「The most underrated AI skill of 2025」系の投稿は、
ほぼ(A)の話です。
推進派のテンプレは task / input / output_format / constraints / examples / tone というキー構成で共通しています。
一方、
OpenAIのStructured OutputsやGeminiのresponse_mime_typeは(B)のAPI機能で、
話が別物。
この2つを混ぜると議論が噛み合わなくなると感じています。
ここが最初の分岐点。
推進派はJSON Promptingをどう語っているのか
バイラルの起点のひとつが @sukh_saroy のX投稿です。
JSON Prompting is the most underrated AI skill of 2025. Turn ChatGPT, Gemini, Claude into consistent, structured agents with no hallucinations and no mess.
続いて、
日本語記事でよく二次引用されるMPG ONEの解説（著者: Mohamed Ezz）では、
5ステップの雛形とともに次のような数字が並びます。
- ハルシネーション60%減
- 企業の70%が導入
- 一貫性が40%向上
- 精度95%
きれいに揃いすぎている数字。
MPG ONEの原文に当たると、
これらの数字には外部調査も論文も引かれていません。
著者自身の「testing in 2026」と「industry observations」という自己申告が唯一の根拠になっています。
Unite.AI系や国内ブログはここを経由して数字だけを独り歩きさせている印象ですね。
推進派の主張そのものを否定する必要はないと思います。
ただ、
私はこの数字をそのまま信じて社内でテンプレ共有するのは危ういと感じています。
あとで突っ込まれた時に根拠が出せなくなるんですよね。
慎重派・反対派の一次ソースはどう語っているのか
推進派の裏側で、実装寄りの開発者はかなり辛口です。
JSON prompting isn't better than any other structured prompting approach. It just forces prompters to think about each aspect of the output that they're looking for. The same outcome can be achieved with many fewer tokens with a well structured markdown prompt.
論点は2つ。
JSONが他の構造化より優れているわけではないこと、
そしてMarkdownなら同じ結果をもっと少ないトークンで出せるということです。
私はこの2点目がとくに実務に効いてくると思います。
トークン効率の話は別の開発者も追随しています。
JSON is token‑expensive for LLMs – just like @mattpocockuk frequently mentions.
出典: @jschopplich, X
私はこの「token‑expensive」という言い方が腑に落ちました。
プロンプトを長く書けば書くほど、
JSONの記号ぶんだけトークン消費が積み上がっていく構造なんですよね。
OpenAIコミュニティのtiktoken実測スレッドでは、
同内容をJSON・YAML・Markdownで書き分けた場合のトークン数が比較されています。
| 形式 | トークン数（同一内容） | JSON比 |
|---|---|---|
| JSON | 13,869 | 基準 |
| YAML | 12,333 | 約11%削減 |
| Markdown | 11,612 | 約16%削減 |
クォート・ブレース・カンマの構文記号がトークンを食う構造的な問題です。
私は数字で見ると想像以上に差が出ていると感じました。
さらにCharlie Guo（ignorance.ai）の「Stop begging for JSON」は、
プロンプトで「JSONで返して」と頼むこと自体の弱さを指摘しています。
Prompt engineering relies on carefully crafted instructions, hoping the model follows them effectively. Structural guarantees, however, build constraints directly into the system.
出典: ignorance.ai, Charlie Guo
私はこの「hoping the model follows them」の部分がいちばん刺さりました。
お願いベースなんですよね、
JSONを指定するプロンプトって。
モデルは「Here's the JSON output you requested:」と余計な前置きを付けてくることがあります。
Charlie Guoの結論は、
API機能のconstrained decoding（OpenAIのStructured Outputs等）かassistant prefillsで強制する方が確実、
というものです。
OpenAI寄りの開発者 @corbtt は、
OpenAI内部のツール定義がJSONスキーマではなくtoken-efficientなTypeScript形式を使っていると公にしています。
「super bloated JSON schema」を避けるためだそうです。
推進派が「最も過小評価されたスキル」と呼ぶものを、
API内部実装側は「bloated」と呼んでいる。
私はこの温度差こそ、
チーム共有前に押さえておくべき情報だと思います。
Claude・ChatGPT・Geminiでは公式推奨がそれぞれ違う
ここがこの記事の核です。
「JSONが正解」ではなく、
モデルごとに公式の推奨が違うんですよね。
| モデル | プロンプト構造化の公式推奨 | 構造化出力の公式機能 | 一次ソース |
|---|---|---|---|
| Claude (Anthropic) | XMLタグ（<instructions> <context> <example> 等） |
専用機能なし（プロンプトで指定） | 公式ドキュメント |
| ChatGPT (OpenAI) | XMLデリミタ推奨（非API）／o-seriesは「simple and direct」 | Structured Outputs（response_format: json_schema） |
公式発表 / OpenAI Devs公式X |
| Gemini (Google) | プロンプト構造化の明示的推奨なし | response_mime_type: "application/json" + response_json_schema |
公式ドキュメント |
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向け推奨はOpenAI Developers公式Xに出ています。
As some of you have noticed, avoid 'boomer prompts' with o-series models. Instead, be simple and direct, with specific guidelines. Delimiters (xml tags) will help keep things clean for the model.
出典: @OpenAIDevs, X
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 Devs公式推奨。トークン効率が良い |
| ChatGPTにAPI経由で厳密なJSONを返させる | Structured Outputs（response_format: json_schema） |
スキーマ遵守100%、プロンプト工夫より確実 |
| Geminiでデータ抽出・分類 | response_mime_type: "application/json"指定 |
MIME type指定で出力形式が確実に固定される |
| 推論・創造系タスク（アイデア出し・文章生成） | 自然言語 or Markdown | JSON強制は推論性能を下げる（下記引用） |
推論タスクへの悪影響についてはHannecke氏のフォーマット比較記事（Medium）が具体的でした。
Forcing JSON output during reasoning tasks reduces model performance by 10–15%.
出典: Michael Hannecke, Medium
推奨されている運用は「フリーフォームで推論させる → 後段で構造化フォーマットに整形する」の2ステップ構成です。
blog.promptlayer.comも同じ方向で具体例を出しています。
Ask for 'Write a love note and return it in JSON with key note' produces worse results than simply 'Write a love note'.
出典: PromptLayer blog
個人的には、
この2ステップ運用がいちばん実務に乗せやすいと感じます。
テンプレはMarkdownかXMLで持っておいて、
アウトプットを機械処理する段だけJSON化すれば、
トークンも節約できるし推論品質も落とさないんですよね。
「JSONテンプレをひとつ作って全業務で流用」は、
見た目はきれいでも最適解ではないと思います。
「60%減・70%導入」の数字はどう扱うべきか
日本語のJSON Prompting記事で最もよく見る数字がこれです。
- ハルシネーション60%減
- 企業の70%が導入
- 一貫性40%向上
- 精度95%
出所はすべてMPG ONEの記事（Mohamed Ezz著）です。
同記事内に外部調査・論文・第三者計測の引用はありません。
根拠は著者の「testing」と「industry observations」のみ。
参考までに、
JSON Prompting「特有」ではないですが近い数字として、
2025年のマルチモデル研究でプロンプトベースの緩和策がGPT-4oのハルシネーション率を53%→23%に下げた報告があります。
これは構造化プロンプト全般の効果で、
JSON形式に限定した結果ではないんですよね。
社内で共有する資料にこの数字を書く場合は、
「Mohamed Ezzが主張する値で一次調査の裏付けは公開されていない」と必ず注記するか、
数字ごと省略するのが安全だと思います。
数字の重みは根拠の強さで決まる。
JSON Prompting推進派の主張でも拾うべき部分
ここまで慎重寄りの話が多くなりました。
とはいえ、
推進派の指摘で実務的に正しい部分もあります。
Zennのmizchi氏の記事は、
非エンジニアがAIを操作するためにJSONという「データ構造の頻出パターン」を学ぶ意義を説明しています。
JSONで物事を考えることは、
ロジックではない眼の前のデータについてのみ考えることです。出典: Zenn, mizchi
PromptLayer blogの主張もバランスが取れていますね。
In production, consistency beats brilliance. A slightly less eloquent response that always follows your schema is worth more than genius-level insights you can't parse.
本番運用では「天才的な回答が時々出る」より「7割の品質で毎回同じ構造で返ってくる」方が価値が高い、
という指摘です。
私はこれは実務感覚として正しいと感じています。
まとめると、
JSON Promptingの本質は「AIが急に賢くなるスキル」ではなく、
「人間側が欲しい出力を明示的に定義する習慣」です。
後者の効用は否定されていないんですよね。
ただ、
その習慣を機能させる形式はモデルごとに違います。
Claudeでやるなら最初からXMLタグにした方が公式の訓練と噛み合うと思います。
チームでプロンプトをテンプレ化するときの実務的な指針
業務担当者がチーム共有用のプロンプト集を整備するなら、
形式選定は以下の順で考えるのが現実的だと読み取れます。
- 使うモデルを確定する：Claudeメインか、ChatGPTメインか、Geminiメインか。混在なら形式も分けます。
- API利用かチャットUIか：APIなら構造化出力機能（Structured Outputs / response_mime_type）を先に検討。チャットUIならプロンプト側で形式を指定。
- タスクが推論寄りか抽出寄りか：推論・創造系は自然言語＋Markdown。抽出・分類・定型出力は構造化フォーマットを積極活用。
- 項目の抜け漏れ防止が目的ならJSONキー羅列も有効：ただしMarkdown見出し（## task / ## input）で十分代替できます。
「何でもJSON」は避ける。
逆に「Markdownだけあれば十分」も極端だと思います。
私は、
使うモデルとタスクの種類で形式を切り替える方が実務に馴染むと整理しています。
OpenAI Developers公式が言っているのは「delimitersで構造を示せ」であって、
デリミタの種類は問題の本質ではないんですよね。
構造が読み取れれば良い。
FAQ
Q1. 結局JSON Promptingは使うべきですか？
使うべきかどうかはモデルとタスクで変わります。
ClaudeならXMLタグが公式推奨。
ChatGPTのAPIならStructured Outputsで強制した方が確実です。
Geminiならresponse_mime_typeで十分ですね。
非APIのチャットUIで繰り返し業務を定型化するなら、
JSON風キー羅列よりMarkdown見出し構造の方がトークン効率が良いです。
Q2. 「ハルシネーション60%減」という数字は信用できますか？
出典はMPG ONE（Mohamed Ezz著）の記事ひとつ。
同記事内に外部調査・論文の引用はなく、
著者自身の自己申告のみです。
日本語記事でよく見るのは二次・三次引用で、
一次調査は辿れません。
社内資料に使うなら「Mohamed Ezz主張の数字で一次調査は非公開」と注記すべきだと思います。
Q3. ClaudeにJSON形式でプロンプトを書くのはダメですか？
ダメとは言われていません。
ただAnthropic公式はXMLタグを第一推奨しており、
Claudeは訓練上XMLタグを強く認識します。
JSONでも動きますが、
冗長になりやすいですね。
同じ情報量なら<instructions>や<context>タグで書く方が公式方針に沿います。
Q4. JSON Promptingで推論タスクが下手になると聞きました
Michael Hannecke氏のMedium記事では「JSON出力を強制すると推論タスクの性能が10〜15%低下する」と報告されています。
解決策は「フリーフォームで推論 → 後段でJSON整形」の2ステップ運用です。
文章生成・アイデア出しを一発でJSON化しようとしない方が安全ですね。
Q5. MarkdownとJSONとXML、結局どれが最強ですか？
用途とモデルで変わるので「最強」という答えはありません。
トークン効率はMarkdown優位（JSONより約16%少）。
Claudeの公式親和性はXML。
API経由でスキーマ遵守を強制したいならJSON Schemaですね。
推進派と @techwraith の両方を読むと、
形式選定より「欲しい出力を明示する習慣」の方が本質だと感じます。
参考リンク
- Anthropic Claude公式: Use XML tags
- Anthropic Claude公式: Prompting best practices
- OpenAI: Introducing Structured Outputs in the API
- Google Gemini API: Structured output
- @OpenAIDevs: XMLデリミタ推奨
- @techwraith: JSON Prompting批判
- @jschopplich: JSONトークンコスト
- @corbtt: OpenAI内部のTypeScript形式
- @sukh_saroy: JSON Prompting推進バイラル元
- PromptLayer blog: Is JSON prompting a good strategy?
- Charlie Guo: Stop begging for JSON
- Michael Hannecke: Beyond JSON — picking the right format
- OpenAI Community: Markdown is 15% more token efficient than JSON
- Zenn mizchi: 非エンジニア向けJSON学習論
- MPG ONE: JSON Prompt Guide（推進派・数字出所）
※この記事の内容は執筆時点のものです。AIは進化が速い分野のため、最新の仕様は公式サイトでご確認ください。