異なるプロンプト形式がLLMの文章生成に与える影響

プロンプト形式の種類と特徴

LLMへの指示文（プロンプト）は、内容だけでなく形式（フォーマット）によってもモデルの解釈や応答品質が変わり得ます[1]。本調査では以下の5つの形式に着目します。それぞれに例と特徴を示します。

• 箇条書き形式（Bullet Points）：指示を「-」や「1.」などで列挙した形式です。例：
• 要件を箇条書きで列挙する
• 各項目ごとに1つの条件や質問を書く

• 最後に出力の形式を指定する
  特徴：指示を個別の項目に分解し、モデルにとって消化しやすい単位で提示できます。各項目が短く明確なため、モデルが一点ずつ注意を向けやすい反面、文脈的なつながりが弱くなる可能性があります[2]。モデルが各項目を独立に処理しすぎると、全体としてまとまりのない応答になるリスクもあります[3]。
• 散文形式（自然文プロンプト）：人間が書くような文章の流れで指示を書く形式です。例：「あなたは旅行ガイドです。ユーザーの入力文を読み、丁寧な口調で3段落程度の観光地紹介文を書いてください。特に歴史的背景とおすすめスポットに触れてください。」
  特徴：プロンプト全体が一続きの文章として書かれ、文脈やニュアンスが伝わりやすい形式です[4]。モデルは通常のテキストと同様に解釈できるため流暢で一貫した応答を引き出しやすく、複数の条件間の関係性も把握しやすいとされます[4]。ただし、指示が長文に埋もれるとモデルが一部の要件を見落とすリスクもあります。
• Markdown形式（マークダウン）：見出し（# 見出し）、リスト、強調（**強調**）などMarkdown記法で構造化した形式です。例：
  
  
• ## 役割 
  あなたは熟練したライターです。 
  
  ## タスク 
  – 次のテキストを要約してください。 
  – 箇条書きで3点にまとめ、マークダウン形式で出力してください。
  
  ## テキスト 
  「・・・（本文）・・・」
• 特徴：文章に見出しやリストで明確な区切りを入れることで、モデルに入力構造を示します。LLMはWebデータ由来でMarkdown形式のテキスト（READMEやフォーラム投稿等）に数多く触れており、このような構文をよく理解できます[5]。Markdownで強調や階層を示すことで、重要部分に注意を向けさせたり、応答のフォーマットを整えさせたりしやすくなります[5]。OpenAIのGPT系モデルはMarkdownを好む傾向があると報告されており[6]、実際ChatGPTもデフォルトでMarkdown整形された回答を出します。一方、Markdown特有の構造にモデルが引きずられ、タスクによっては他形式より精度が下がるケースもあります（後述）。
• YAML形式：インデントと「キー: 値」のペアで構造を表すデータ記述形式です。例：
  
  
• role: “あなたは有能なアシスタントです。”
  task: |
    ユーザーから与えられた記事を要約し、重要なポイントを3つの箇条書きで示してください。
  style: “丁寧で簡潔な口調”
• 特徴：JSONに似た構造化形式ですが、可読性が高くコメントも記述できます。インデントや改行で階層を示すため記号（{}や”,”）が少なく、モデルにとっては構文ノイズが少ない形式です[7]。その結果、同じ情報でもJSONよりトークン数が減り、応答生成のコストや時間が削減できるとの報告があります[8][7]。例えば月名リスト生成の実験では、JSONに比べYAMLは約50%トークン削減となり、応答速度も向上しました[8]。またYAMLではコメント行（例: # この部分は説明）を含められるため、モデルにチェイン・オブ・シンキング(CoT)させつつ、出力は指定フォーマットを保つテクニックも可能です[9][10]。ただしインデントミス等でパースエラーを起こしやすく、厳密なフォーマット管理には注意が必要です[11]。
• JSON形式：波括弧と引用符でキーと値を持つ典型的なデータ構造形式です。例：
  
  
• {
    “role”: “assistant”,
    “instruction”: “以下の質問に3文以内で答えてください。”,
    “question”: “地球から月までの平均距離は？”,
    “format”: “JSON”
  }
• 特徴：厳密な構文ルールを持ち、キー項目ごとに指示内容を整理できます。モデルに期待する出力の項目をそのまま入力JSONの構造で示すことで、タスクを明確に定義できます[12]。OpenAI GPTはJSON構造の理解・生成が得意であり、内部APIでもメッセージをJSONでやり取りしています（関数呼び出しなど）[13]。そのためGPT系ではJSON形式のプロンプトに対し高い信頼性で構造化出力を返すことが多いです[13]。一方で、JSONは厳格なフォーマットゆえ表現の自由度が低く、創造的な文章生成には不向きです。また括弧や引用符が多いためトークン数が増え、応答速度やコスト面ではYAMLに劣る可能性があります[7]。

各LLMによる形式解釈の違い

LLMの種類（提供企業やモデルアーキテクチャ）によって、得意とするプロンプト形式に差があるとの指摘があります。モデルの事前学習コーパスやRLHFの方針によって、特定の書式への親和性が異なるためです。

• OpenAI GPT（GPT-3.5やGPT-4）：オープンAIのGPTシリーズは、MarkdownやJSON形式を好む傾向が報告されています[13]。これは、学習データにプログラミング文書やMarkdown形式のテキスト（例えばGitHubのREADME、フォーラム）が大量に含まれていたこと、またOpenAI自体が関数出力などでJSONを推奨していることが要因です。実際、「構造化された入力」を与える場合、GPTはMarkdownやJSONで書かれた指示に対し高い性能を示すことが確認されています[13]。箇条書きや通常の文章による指示ももちろん理解できますが、後述する実験ではタスクによってはJSON形式にしただけで大幅に精度が向上する例もあります[14]。GPT-4は特にフォーマット変化に対してロバストで、どんな形式でも安定した性能を発揮しやすいと報告されています[15]。
• Anthropic Claude：ClaudeはXML形式の構造化入力を好むという興味深い知見があります[13]。開発者の報告によれば、ClaudeにXMLタグ付きのプロンプトを与えると、タグ構造に沿った出力をさせやすく、場合によってはあらかじめ<response>タグで出力箇所を指定するといった細かな制御も可能とのことです[16]。例えば製品説明文から<name>や<price>等を抽出させる際、ClaudeにはXMLタグで項目を示すと効果的だったケースが報告されています[17][18]。一方、ClaudeはJSONやMarkdownも十分に解釈可能です。Anthropicは高度な対話データでチューニングしているため、箇条書きや散文形式で丁寧に書かれた指示にも高い追従性を示します。ただ、細かな制御が必要なタスクではXMLのような明示的な構造がより有効という傾向があります。
• Google Gemini（PaLM系モデル）：2025年時点で詳細な仕様は限定的ですが、Googleの次世代モデルGeminiも広範なウェブ・コードデータで訓練されていると考えられます。そのためJSONやMarkdown、箇条書きなど一般的な形式には幅広く対応できるでしょう。実際、Googleのプロンプト設計ガイドでは「入力形式や文体を工夫せよ」としてテーブル、箇条書き、JSONスキーマなどを試すことが推奨されています[19]。これは、Geminiを含むモデルが入力フォーマットによって注意を向ける箇所が変わるため、最適な形式を探るべきという示唆です。例えば、質問への回答を5つの選択肢から選ぶマルチタスクでは、選択肢を箇条書きにするとモデルのフォーカスが改善するケースがあり[20]、Googleもそうしたフォーマット最適化の重要性を認識しています。Gemini自身の公開デモ等では、Markdown形式で回答を整形したり、JSONで構造化データを返す例も見られ、OpenAI GPTと同様に多様な形式をそつなく扱えると推測されます。
• xAI Grok：xAIのGrokは比較的新しいモデルで、公式には構造化出力（Structured Outputs）機能を備えています[21]。これは、ユーザがあらかじめ定義したJSONスキーマに沿って出力を生成する機能で、Grokが厳密にその形式に従った回答を保証するものです[21][22]。このことから、JSON形式での入出力を特に重視してチューニングされていると考えられます。実際、Grok APIのドキュメントでは、関数呼び出し的にJSONレスポンスを得る例や、ChatGPT互換のメッセージフォーマット（JSONでroleとcontentを指定）に対応している旨が記載されています[23]。したがってGrokはJSONや箇条書きで明確に指示されたタスクを正確にこなす傾向が強いでしょう。Markdownや散文形式の自然な対話ももちろん可能ですが、GrokはxAI社の方針上、ユーザの細かなフォーマット指定に従う実用志向のチューニングがなされているようです（創造性より事実志向との噂もあります）。なおGrokのAPIではOpenAI互換エンドポイントも提供されており、システムメッセージに長い指示（ルール）をJSONで与える手法なども紹介されています[24]。
• Meta LLaMA（およびLlama 2チャット）：MetaのLLaMAはオープンソースモデルで、ChatGPTやClaudeとは異なり公開データで指示調整されています。Llama 2-Chatではシステムプロンプトとユーザープロンプトを専用の区切りトークンで与える形式（例えば <s>[INST] … [/INST]）を採用していますが、一般的な利用では自然文で指示を与える形になります。散文形式での対話は十分にこなせる一方、非常に厳密なフォーマット（JSON/YAML）の出力ではGPTほどの安定性はありません。オープンソースゆえに隠れたシステム指示が無く、その分ユーザが細かくルールを指示する必要があります[25][26]。例えば、GPT系ではユーザが明示しなくても暗黙に守られていたマナーや出力形式を、LLaMAに移行する際には箇条書きでルール一覧を与えるなど、より明示的な指示が推奨されています[25][26]。箇条書きやMarkdownで手順を示すこと自体はLLaMAも理解できますが、モデル規模が小さい場合（7Bや13B）には長いリストだと一部を無視したり誤解する可能性もあります。JSON出力に関しては、適度に温度（創造性）パラメータを下げるなど工夫すればかなり正確に生成できますが[27]、デフォルト設定では括弧漏れや余計なテキスト混じりが起こりやすいため、厳密なJSONを要求する際は検証・再試行が必要です。総じて、LLaMA系は散文形式での対話や創造的生成は得意ですが、構造化フォーマットへの厳密な従順性は大規模閉源モデルに一歩譲ると言えます。

出力品質（正確性・一貫性・流暢性・創造性）への影響

プロンプト形式は出力の質的側面に様々な影響を及ぼします。研究や実験から得られた知見を、正確性・一貫性・流暢性・創造性の観点で整理します。

• 正確性への影響：指示をより明確・厳密に伝えられる形式ほど、モデルの解答正確性が向上する傾向があります。マイクロソフトの研究[1]では、OpenAI GPT-3.5に同一の内容を異なるフォーマットで与え、6種のベンチマークで性能比較しました。その結果、JSONやYAMLのように構造化されたプロンプトが、知識質問やコード変換タスクで高精度をもたらすケースが確認されています。例えば、国際法に関するMMLU（大学レベル試験）問題では、プロンプトをMarkdownからJSONに変えただけで正答率が42%も向上しました[14]。これはJSON形式にすることでモデルが選択肢を明確に認識・評価できたためと考えられます。逆に、平文のまま曖昧に質問するとモデルが誤解しやすく、精度が下がります[1]。ただし、一概に「JSONが常に最高」という訳ではなく、タスク内容によって最適な形式は異なるとされています[15]。例えば翻訳タスクでは平文のほうが文脈を崩さずに訳せる場合もあります。一貫して言えるのは、モデルが理解しやすいよう情報を構造化・強調して与えると誤解が減るという点です[28]。箇条書きで重要ポイントを列挙したり、Markdownで強調した単語はモデルにとっても目立つため、聞き漏らし・勘違いを減らせる効果があります[28]。
• 一貫性への影響：出力の一貫性（論理的つながりや整合性）は、プロンプト内の文脈提示とモデルの思考プロセスに左右されます。散文形式のプロンプトは文脈を滑らかに伝えるため、モデルの回答も全体的にまとまったものになりやすいです[4]。一方、箇条書き形式はモデルが各点に集中しすぎて全体のつながりが弱くなる場合があります[3]。例えば物語生成でプロットを箇条書きにすると、各プロットは詳しく描写されてもストーリーとしての流れがぎこちなくなる可能性があります。この場合、一度散文で「〇〇という設定で、起承転結の物語を…」と促したほうが、一貫したナラティブを得やすいでしょう。一貫性確保にはモデル側の推論も重要です。Chain-of-Thought（内面的な思考展開）を促すと整合性が増すことがありますが、JSON出力ではそれができません。しかしYAMLならコメントにCoTを埋め込めるため、内部で推論させつつ最終回答だけキーにまとめる、といった高度な手法も可能です[10]。実験では、GPT-3.5に難問計算をJSON形式で直接答えさせた場合は誤答しましたが、YAML形式プロンプトで途中計算をコメントに書かせ最終値のみキー出力させると正答を得られた例があります[10]。このように形式次第でモデルの思考プロセスを引き出しやすくでき、それが結果の一貫性・正確性向上に繋がります。
• 流暢性への影響：流暢性（文章の自然さ、読みやすさ）は、モデルの文章生成能力とプロンプトのスタイル両方の影響を受けます。一般に散文形式で「～について詳しく説明してください」と促すと、モデルは長文で滑らかな説明を返します。一方、「箇条書きで答えよ」と指定すれば簡潔にまとまりますが、全体としては電文調で単調な印象になることもあります。Markdownで見出しや強調付きの応答を求めると、モデルは整然としたドキュメント風の出力をしますが、これはフォーマットに引っ張られるぶん平易な文章からは離れる可能性があります。ただ、GPT-4クラスのモデルになるといずれの形式でも高い流暢性を維持できます[15]。一方、小規模モデルでは複雑なフォーマット指定に気を取られると文そのものの質が下がるケースもあり得ます。例えばLLaMA-13Bに無理にJSONで詰問すると、文法的につたない説明が値に入ったりするかもしれません。創造系タスクではあえてフォーマットの縛りを弱め、多少散文寄りにした方がモデルがのびのび書けて流暢さが増す、といった工夫も考えられます。
• 創造性への影響：プロンプト形式はモデルの創造的な応答にも影響を与えます。厳密な形式（JSON/YAML）で求めると、モデルは事実列挙や定型的な表現に終始しやすく、独創的な表現やユーモアが抑制されます。これは形式違反を恐れて保守的になるためです。例えば物語をJSONのフィールドに沿って書かせても、味気ないプロット要約になりがちです。一方、自由形式（散文）で「創造的に～して」と促せば、モデルは比喩や物語性のある表現を織り交ぜるでしょう。しかし自由度が高すぎるとテーマから逸脱する危険もあります。Markdown箇条書きでアイデアを列挙させるのは創造的ブレインストーミングには有効です。各箇条に別のアイデアを書くよう指示すれば、モデルは複数の創造的選択肢を提案してくれます。ただし個々のアイデアの掘り下げは浅くなるため、後続プロンプトで肉付けさせる必要があります。要するに、創造性と構造化はトレードオフの関係にあり、自由な発想が欲しい場合は形式の制約を弱めに、きちんと形にする段では形式を整える、と段階を分けるのが有効です。

以上のように、形式によって求められるモデル能力や注意の向け方が変化するため、出力の正確さ・まとまり・自然さ・独創性がそれぞれに影響を受けます。特に顕著なのは正確性で、フォーマット変更だけで性能が大きく揺れ動ぶことも確認されています[1]。しかし最新モデル（GPT-4など）は形式の違いに比較的寛容で、大崩れしにくい傾向があります[15]。

タスク種類別：どの形式が有利か

文章生成と一口に言っても、要約、説明文作成、創作ストーリー、Q&A、要点抽出など様々なタスクがあります。それぞれのタスクにおいて適したプロンプト形式がある程度見えてきています。

• 要約・箇条書き的な出力が欲しいタスク：会議記録からのアクションアイテム抽出や記事の要点要約など、箇条書きの結果を望む場合、箇条書き形式のプロンプトが有利です。指示自体を bullet で「- 会議の主要な決定事項を抽出」「- 各決定事項について担当者も記載」などと列挙すると、モデルは各箇条に対応する形で情報を探し出し、リスト構造で回答しやすくなります[29]。実際、ある企業の検証では会議記録要約を一つの長いプロンプトでさせるより、「決定事項を抽出」「整合性チェック」「要約生成」の3段階にプロンプトを分割した方がパフォーマンスが向上したといいます[30][31]。このように複雑タスクは箇条書きでサブタスク化すると精度と管理性が上がります。
• 長文の説明・創作が必要なタスク：技術記事の執筆や物語創作のように、まとまった文章を生成させたい場合は、散文形式またはMarkdown形式が適しています。散文形式で文脈や口調を丁寧に指定すれば、モデルはより人間らしい文章を紡ぎます[4]。例えば「あなたは物語の語り部。以下のプロットに沿って情感豊かに物語を執筆せよ。」のように書くと良いでしょう。Markdown形式も、プロンプト内で「## 背景」「## 登場人物」「## 展開」などセクションを用意し、それぞれ数行の説明を書くことで、モデルに物語の構成要素を明示できます。この場合、モデルの出力も各セクションに対応した段落構成になる可能性が高く、流れのある長文を得やすくなります。創作ではあまりJSONなど厳密形式は用いません。フォーマットが厳しすぎると創造性が損なわれるためです。
• 質問応答や知識検索のタスク：ユーザの質問に正確に答えるQ&Aでは、散文形式のシンプルな質問が基本ですが、質問の仕方を箇条書き等に変える実験もあります。例えば「What are the causes of climate change?」と一文で聞く代わりに、「- 気候変動の主な原因を列挙せよ\n- 各原因の説明を加えよ」のように聞くケースです。研究によれば、モデルによって結果が異なり、GPT-3.5ではMarkdown形式にした途端に不要な推論を書き出す癖が出た一方、JSON形式だと正確に答えただとか[32]、逆のケースもありました。選択肢問題では、選択肢を箇条書きにすることが特に有効で、モデルが一つ一つ評価できるため正答率が上がると報告されています[20]。一方オープンな知識質問では文章で聞いた方がニュアンスを伝えやすく、高品質な回答を得やすいです。従って、Q&Aでは質問の種類に応じて形式を使い分けると良いでしょう。定義や列挙を求めるなら bullet、理由説明を求めるなら文章、といった具合です。
• データ抽出・構造化が必要なタスク：文章から特定フィールドを抜き出す、表を作る、JSONでデータ生成するといった情報抽出・整理タスクでは、プロンプト自体をJSONやYAMLなど構造化形式にすると効果的です[12]。例えば商品説明文から値段・色を抜くタスクでは、プロンプトをXML/JSONで「<price>を抽出せよ」のように書き、出力も同じタグ付きで返すよう求めるとモデルはフォーマットに沿った抽出を行います[17][18]。Anthropic ClaudeはXMLタグ付きプロンプトでこの種のタスク精度が高かった例があり[16]、GPTも関数呼び出し機能を使えばJSONで確実に構造化データを吐き出せます。YAMLは前述の通りコメントで補助情報を書ける利点から、中間思考をさせつつ抽出結果だけ出力させるテクニックが有効です[33][34]。一方、自由記述のまま「～を抜き出して下さい」と頼むとモデルは形式を統一せず回答することが多く、後処理が大変になります。従ってこの種のタスクでは最初から構造を規定できる形式（JSON/YAML/XML）が有利と言えます。
• 条件付き指示・マルチステップ推論タスク：ユーザの要求が複雑で、「もしXならYし、そうでなければZすること」といった条件分岐や複数段階のロジックが必要な場合、プロンプト形式の工夫が重要です。自然言語で長々と条件を書くとモデルが混乱する恐れがありますが、箇条書きで条件を列挙したり、擬似コード風に箇条書きすることでモデルに論理を理解させやすくできます。例えば:
  
  
• タスク:
  1. ユーザーの入力文をチェック:
     – 入力に禁止語が含まれる場合 -> 「禁止された内容です」と応答。
     – 含まれない場合 -> 2へ進む。
  2. 入力文の要約を作成しなさい。
• といったYAML風・手順書風のプロンプトは、モデルに手順を踏ませる効果があります（もっとも、実際にはLLMは条件分岐を内部でシミュレートするだけで、本当のif文のような動きはできませんが、筋道の指示として理解はします）。このような複雑指示では、各条件やステップを明示できるリスト形式や構造化形式が有利です[35]。モデルは順序だった処理が求められていると認識し、手順を飛ばしにくくなります。一方、平文で「～して。ただしXのときはY、それ以外はZ。」と書くと、一度で大量の情報を保持しながら生成しなければならず、抜け漏れが生じやすくなります。

以上を整理すると、タスクの目的に合った形式選択が重要です。単に「モデルが何でも理解できるから」と漫然と自然文で書くのではなく、出力してほしい形に近い形式で入力を整えることで、モデルの注意を誘導しやすくなります[19]。特に構造化データや箇条書きがゴールの場合、その形式で指示するのが近道ですし、創造的文章がゴールならフォーマットに縛りすぎない方がモデルの持ち味を引き出せます。

複雑な指示・条件付きプロンプトにおける形式の影響

プロンプトが長大化し様々な条件や要件が盛り込まれるほど、形式選択の影響は大きくなります。複雑なプロンプトでは以下の点を考慮すると良いでしょう。

• 「神プロンプト」より分割と構造化：一つのプロンプトにあれもこれも詰め込むと、モデルが処理しきれず性能が低下する恐れがあります[30]。GoDaddy社の報告では、欲張りな1件プロンプトより細分化した複数プロンプトのほうが結果的に品質が上がったとされています[30]。箇条書きや段落でプロンプトを論理的に区切ることで、モデルは各部分に順番に取り組みやすくなります。Markdownの見出しでセクション分けするのも有効です。「前提」「目的」「出力形式」「手順」といった見出しを付け、内容を整理すれば、モデルも各セクションの意味を酌み取りやすくなります。
• 隠れたシステム指示の再現：商用LLM（GPTやClaude等）は内部でシステムプロンプトを使い事前にルールを課していることがあります[26]。オープンモデル(LLaMA等)に移行する際は、その役割をユーザが担わねばなりません[25]。例えば「法的助言禁止」「丁寧な口調で答える」といったルールは、箇条書きやJSONで明示的に提示するとモデルが忘れにくくなります。Claudeなどは憲法AI的な内部原則がありますが、ユーザープロンプトでも<rule>…</rule>のように書けばそれに従うことがあります。複雑な制約条件は、一つ一つを箇条書きで列挙して与えるのが定石です[36]。その際、否定形で「するな」というより肯定形で「～せよ」と書く方がモデルは従いやすいとも言われます[37]。形式とは少し逸れますが、制約の提示にもフォーマットの工夫（箇条書き化、セクション化）は効果的です。
• モデル毎の隠れた好みを利用：前述の通りClaudeはXMLタグ付き指示で応答フォーマットを強制しやすい性質があります[16]。このようにモデル固有のプロンプト解釈のクセを把握しておくと、複雑プロンプトで望む挙動をさせやすくなります。OpenAI GPTはJSONを与えると関数の引数だと解釈して厳密な返答をしようとしますし、Markdownだと文章として読みやすくしようとします[38]。Anthropic Claudeは「○○について考えて…」と促すと内部で長めの推論を展開する傾向があり、逆に制御したいときはXMLで応答部分のみ指定するといった使い分けが可能です。複雑な指示では、モデルの好みに合った形式で書くことで余計な誤解を防ぎ、指示意図を最大限伝えられるのです[38]。
• エラー耐性とフォーマット：条件付きプロンプトでは、どの条件にも合致しないケースや想定外入力など例外処理も念頭に置く必要があります。JSONやYAMLでフォーマットを固定していると、モデルはその枠外の想定外ケースに遭遇すると対応を迷うことがあります。例えば「該当なしの場合nullを返せ」とJSONスキーマで指示し忘れた場合、モデルは長々説明を書き出してJSONを崩すかもしれません。このようにガチガチの形式指定は逸脱時に脆い面もあります。箇条書きやMarkdown程度の柔軟な形式なら、モデルも多少のアレンジで切り抜ける余地があります。したがって、非常に複雑で網羅困難な指示では、ある程度フォーマットに遊びを持たせる（柔軟なリスト形式にする等）ことも一考に値します。

以上を踏まえ、プロンプトが複雑になるほど形式設計がプロンプトエンジニアリングの鍵となります[35]。形式は単なる見た目ではなく、モデルへの思考アルゴリズムの提示でもあります。条件や段取りをどう書けばモデルが理解しやすいか、フォーマットという視点から最適化していくことが、複雑なプロンプトを成功させるポイントです。

各モデル×形式の総合比較

最後に、各プロンプト形式が各LLMに与える影響をまとめた比較表を示します。◎は高い適性・好相性、○は問題なく扱える、△はやや注意・工夫が必要な組み合わせを示します（主に報告事例と推測に基づく）。モデルの学習背景や設計思想がフォーマット適性に表れるため、プロンプト作成時の参考になります。

LLM / プロンプト形式	箇条書き (リスト)	散文 (自然文)	Markdown (見出し等)	YAML (構造データ)	JSON (構造データ)
GPT-4/3.5 (OpenAI)	◎（順序立てた指示も忠実）[13]	◎（通常会話で高性能）	◎（学習データに頻出）[5]	○（タスク次第では有効）	◎（構造化出力に最適）[13][14]
Claude 2 (Anthropic)	◎（ルール列挙に有効）	◎（丁寧な文章指示を好む）	○（Markdownも理解）	○（扱えるがXML推奨）	○（JSON出力も可能）
Gemini (Google)	◎（リストで注意喚起）	◎（自然文理解が基本）	◎（ドキュメント指示〇）	○（データ構造理解〇）	◎（構造スキーマ対応）
Grok (xAI)	○（十分対応）	◎（対話ベースで学習）	○（対応可）	○（対応可）	◎（JSONスキーマを重視）[21]
LLaMA2-chat (Meta)	○（明示すれば対応）	◎（対話チューニング済）	○（若干の工夫要）	△（エラー時要リカバリ）	△（低温度設定で慎重に）

表: 各LLMにおけるプロンプト形式適性のまとめ[13][5][21]

上記は絶対的な評価ではなく、既知の知見に基づく傾向の整理です。実際の性能はプロンプト内容やモデルのバージョンによっても変わりますが、「この組み合わせはモデルが得意/不得意かも」という指針になります。例えばOpenAI GPTはMarkdownやJSON指示で安定した結果を出しやすい一方、LLaMAはJSON生成で崩れがちなので温度パラメータを下げる等の対策が有効、といった具合です[27]。ClaudeはXMLが得意というユニークさがありますが、表では扱っていないためJSON/YAMLは○止まりにしています。

まとめ

プロンプトの書き方（形式）は、文章生成AIの応答品質にとって無視できない要素です。箇条書き、散文、Markdown、YAML、JSONの各形式にはそれぞれ利点と注意点があり、モデルごとにも得意不得意があります。総括すると：

• 箇条書き：複数要件や手順を明確に伝えられ、抜け漏れ防止に有効。モデルの注意をフォーカスさせやすい半面、応答が断片的になる恐れもある[3]。マルチステップ指示や要点抽出、リスト生成タスクに適する。
• 散文（自然文）：最もナチュラルで文脈を伝えやすく、流暢で統一感のある回答を引き出すのに適する[4]。創造的な文章や詳細な説明タスクに有利。ただし長文指示ではモデルが一部要件を見落とす可能性がある。
• Markdown：構造や強調を付けられるため、モデルに入力の論点構造を掴ませやすい[5]。GPTなどMarkdownに慣れたモデルでは高い効果を発揮しうる[6]。ドキュメント生成やセクション分けが必要なタスク、モデルに整形出力させたい場合に有用。
• YAML：構造化しつつ可読性が高いフォーマット。JSONに比べトークン効率が良く、応答コスト削減や処理速度向上につながる[8][7]。コメントを活かした高度なプロンプト（内部思考埋め込みなど）も可能[10]。ただ厳密なインデント管理が必要で、モデルによっては認知負荷になる場合も。データ抽出や定型レポート生成に適する。
• JSON：厳格なフォーマット指定により、モデルから構造化データやフォーマット保証された出力を得るのに最適[12]。GPTはJSON指示で高い精度を示すことが多い[14]。一方で創造性は抑制され、出力が事務的・定型的になりやすい。フォーマット逸脱には弱いのでスキーマ設計とモデル制御（温度調整等）が重要。情報抽出・コード生成・定型応答タスクに適する。

近年の研究は、こうしたプロンプトフォーマットの違いがモデル性能に与える影響を定量的に測定し始めています[1]。その結果、モデル評価やベンチマーク時にも単一の固定フォーマットでは不十分で、様々なフォーマットで試して総合的に評価すべきという提言も出ています[39][15]。またモデルの大型化に伴い、フォーマットへの過敏さは緩和される傾向も見られますが（GPT-4は3.5より頑健[15]）、ユーザー側で最適な指示形式を模索する余地は依然大きいです。

結論として、LLMを使いこなすにはプロンプト形式という観点での最適化が重要です。各形式のメリットを理解し、タスクやモデルに応じて使い分け・組み合わせることで、より正確で一貫性があり、しかも創造的な応答を引き出すことができます[19]。プロンプトエンジニアリングのベストプラクティスとして、「形式をデザインする」という発想を持つことが、これからますます重要になるでしょう[35]。

References:

【3】 Zenn.dev (翻訳記事) – Eugene Yan他 “What We’ve Learned From a Year of Building with LLMs”（2024年6月24日）[6][16]

【8】 Zenn.dev (同上) – 構造化入力と各モデルの好みに関する言及[16][17]

【10】 He et al., “Does Prompt Formatting Have Any Impact on LLM Performance?” arXiv:2411.10541 (2024) – フォーマット変更によるGPT性能変化[1][14]

【14】 Gergely Rabb, “Prompting for everyone — examples and best practices” Medium (2025) – 複雑なクエリには見出し・リスト・JSON/YAMLなどで構造化せよ[35]

【17】 Syncfusion Blog, “10 Essential Prompt Engineering Criteria” (2023) – フォーマットの重要性と箇条書き活用[28]

【23】 Reddit r/PromptEngineering – “Prompt structure and bullet points” スレッド (2023) – LLM訓練データとMarkdown/XMLの親和性、箇条書きvs全文の利点[38][2][5]

【27】 Reddit r/PromptEngineering – “Google 68-page prompt engineering guide highlights” (2023) – 箇条書きやJSONなど形式を工夫せよとのガイド抜粋[19]

【28】 Elya Livshitz, “YAML vs. JSON: Which Is More Efficient for LMs?” BetterProgramming (2023) – YAMLによるトークン削減と品質向上の考察[8][7]

【31】 同記事 – YAMLコメントにCoTを埋め込むテクニックとJSON比較[10]

【20】 GroqDocs “Model Migration Guide: Closed to Open Models” (2023) – OpenAI/Claude→LLaMA移行時の明示的プロンプトの必要性[25][26][27]

【30】 xAI Docs “Structured Outputs” (2024) – Grokモデルの構造化出力機能とJSONスキーマ対応[21]

---

[1] [14] [15] [32] [39] Does Prompt Formatting Have Any Impact on LLM Performance?

https://arxiv.org/html/2411.10541v1

[2] [3] [4] [5] [38] Prompt structure and bullet points : r/PromptEngineering

Prompt structure and bullet points
byu/Few-Initial-7218 inPromptEngineering

[6] [12] [13] [16] [17] [18] [29] [30] [31] [翻訳]LLMで1年間開発して学んだこと〜LLMプロダクト開発を成功に導くための実践的ガイド〜

https://zenn.dev/seya/articles/12c67b5d80670a

[7] [8] [9] [10] [33] [34] YAML vs. JSON: Which Is More Efficient for Language Models? | by Elya Livshitz | Better Programming

https://medium.com/better-programming/yaml-vs-json-which-is-more-efficient-for-language-models-5bc11dd0f6df

[11] プロンプトを管理するフォーマットは何が良いのか？

https://zenn.dev/kun432/scraps/0a826cce8f6428

[19] [36] [37] Google dropped a 68-page prompt engineering guide, here’s what’s most interesting : r/PromptEngineering

Google dropped a 68-page prompt engineering guide, here's what's most interesting
byu/dancleary544 inPromptEngineering

[20] Effect of Selection Format on LLM Performance – arXiv

https://arxiv.org/html/2503.06926v2

[21] [22] Structured Outputs – Guides | xAI Docs

https://docs.x.ai/docs/guides/structured-outputs

[23] xAI (Grok) Provider – Promptfoo

https://www.promptfoo.dev/docs/providers/xai

[24] ben on X: “full system prompt:https://t.co/41sFvJlkuq” / X

full system prompt:https://t.co/41sFvJlkuq

— ben (@benhylak) February 21, 2025

[25] [26] [27] Model Migration Guide: Moving from Closed to Open Models – GroqDocs

https://console.groq.com/docs/prompting/model-migration

[28] 10 Essential Prompt Engineering Criteria to Kickstart Your Success

https://www.syncfusion.com/blogs/post/10-prompt-engineering-criteria

[35] PROmpting for everyone — examples and best practices | by Gergely Rabb | Medium

https://medium.com/@rbbgrgly/prompting-for-everyone-examples-and-best-practices-d6189411ee32