MENU

大規模言語モデルのパフォーマンスに対するプロンプトフォーマットの影響

画像クリックでインフォグラフィックサイトに遷移します

第1章 プロンプト構造のスペクトラム：自然言語からデータシリアライゼーションまで

大規模言語モデル（LLM）との対話におけるプロンプトの設計は、単なる指示の伝達にとどまらず、モデルの推論プロセスを形成し、出力の品質、一貫性、信頼性を決定づける極めて重要なエンジニアリングプロセスである。本章では、プロンプトの構成要素として用いられる5つの主要なフォーマット（散文、箇条書き、Markdown、YAML、JSON）を、その構造的厳密性と意図された用途に基づき分類・分析する。最も流動的な自然言語形式である散文から、最も制約の強いデータシリアライゼーション形式であるJSONへと移行するにつれて、表現の自由度とプログラム的な信頼性の間に存在する固有のトレードオフが明らかになる。この分析は、後続の章で詳述するパフォーマンスへの影響を理解するための基礎を築くものである。

1.1 ベースライン：非構造化散文と半構造化リスト

1.1.1 散文形式の分析

散文ベースのプロンプトは、人間同士の対話に最も近い、自由形式のテキストとして定義される。この形式は、創造的な文章生成、ブレインストーミング、あるいはモデルの事前学習済み知識が十分に対応可能な、単純で明確に定義されたタスクにおいて主たる有用性を発揮する 1。例えば、「OpenAIに関する短い感動的な詩を書いてください」といった指示は、散文形式で十分に機能する 3。

しかし、この形式の持つ非構造的な性質は、本質的なリスクを内包している。第一に、曖昧性の問題である。自然言語は多義的であり、「これを要約して」といった単純な指示でさえ、文脈、トーン、長さの指定が欠けているため、モデルが生成する結果は大きく変動しうる 1。この曖昧さは、モデルがユーザーの意図を正確に解釈するために余分な計算リソースを費やすことを強いる。モデルは、タスクを実行すること自体よりも、まず意図を解析することに注力しなければならない。

第二に、一貫性の欠如である。構造的なフレームワークが存在しないため、プロンプトの構成や意図が少し変わるだけで、出力にばらつきが生じやすい。これは、均一性と信頼性が不可欠な業務アプリケーションにおいて特に問題となる 4。

第三に、非効率性である。非構造的なプロンプトは、望ましい出力を得るために複数回の試行錯誤を必要とすることが多く、時間と計算リソースの両方を浪費する可能性がある 4。これらの課題は、プロンプトが複雑化するにつれて増大し、より構造化されたアプローチの必要性を示唆している。

1.1.2 箇条書き・番号付きリスト形式の分析

箇条書きや番号付きリストは、プロンプトに初歩的な構造を導入する手段として位置づけられる。この形式は、情報を個別の項目に分割することで、散文形式に比べて明確性を向上させる。例えば、複数の指示や一連のステップを列挙する場合に特に有効である 6。OpenAIのベストプラクティスでは、複雑なタスクをより単純なサブタスクに分割することが推奨されており、リスト形式はこのアプローチを具現化するのに役立つ 7。

しかし、リストは情報を分節化するものの、より高度なフォーマットが提供するような明示的な階層構造や意味的な文脈を欠いていることが多い。各項目間の関係性や、リスト全体がプロンプトの中で果たす役割（例えば、指示、文脈、例示など）は、依然としてモデルの解釈に委ねられる部分が大きい。その結果、リスト形式のプロンプトは、明確さをもたらす一方で、文脈のニュアンスを十分に伝えきれず、過度に硬直的あるいは単純な応答につながる可能性がある 6。したがって、リスト形式は単独で用いるよりも、他のプロンプト技術と組み合わせることでその真価を発揮すると言える。

1.2 明確性のためのマークアップ：Markdownの有効性

1.2.1 「共通言語」としてのMarkdown

Markdownは、人間にとっての可読性と、機械による解析可能性という二つの要件を見事に両立させる、理想的な中間地点に位置するフォーマットである 8。その軽量なマークアップ構文（見出しには

#、リストには-や*、太字には**、コードブロックには“`）は、開発者がプロンプトを容易に記述、読解、そして維持管理することを可能にする 10。

このフォーマットの持つ普遍性は、GitHubやNotionといったプラットフォームでの標準的な採用実績からも明らかであり、技術文書をLLMに提供する際のネイティブフォーマットとして機能することが多い 9。その結果、Markdownは、データ抽出からLLMへのコンテキスト提示まで、多様な用途において「共通言語（lingua franca）」としての役割を果たす 12。

1.2.2 意味的階層の付与

Markdownの真価は、その構文要素がコンテンツの構造と重要性に関する強力かつ曖昧さのないシグナルをLLMに提供する点にある。見出し（#, ##など）は明確なセクションを作成し、リストは項目を列挙し、コードブロックはリテラルなテキストを分離する。これにより、モデルの解釈プロセスが効果的にガイドされる 12。

この構造化は、モデルの「認知的負荷」を軽減する効果を持つ。モデルは、プロンプトのどの部分が指示であり、どれが文脈、例、あるいはユーザーの質問であるかをより容易に区別できるようになる 15。例えば、

### 指示と### 文脈といった見出しを用いることで、各テキストブロックの役割が明示され、モデルはそれぞれの情報を適切に処理できる。Y Combinatorをはじめとする多くの専門家が、「最高のプロンプト」はしばしばこのMarkdownスタイルの構造分割を活用していると指摘していることは、その有効性を裏付けている 8。このように、Markdownは単なる装飾ではなく、LLMの注意機構を導き、プロンプトの意図を正確に伝達するための強力なツールなのである。

1.3 高信頼性タスクのためのデータシリアライゼーションフォーマット：YAMLとJSON

1.3.1 YAML：設定と複雑なプロンプトのための構造化された可読性

YAML（Yet Another Markup Language）は、プロンプトエンジニアリングの領域において、特に複雑な複数パートからなるプロンプトの構成と管理にその価値を発揮する。YAMLの最大の特徴は、人間中心の構文にある。インデントベースの階層表現と、括弧や引用符といった句読点を最小限に抑えた記述法は、JSONと比較して高い可読性と保守性を提供する 17。これは、プロンプトテンプレートを設定ファイルとしてバージョン管理システム（Gitなど）で管理する際に、特に大きな利点となる 18。

研究によれば、YAMLは可読性と効率性のバランスが取れたフォーマットであると評価されている。JSONに比べてトークン効率が良い場合があり、人間が直接編集するシナリオに適している。ただし、その柔軟な構文ゆえに、厳密なデータ抽出タスクにおいては、JSONに比べてわずかながらフォーマットの不整合が生じ、精度に影響を与える可能性も指摘されている 17。したがって、YAMLはプロンプトの「設定」レイヤーや、人間によるメンテナンスが頻繁に発生する複雑なテンプレートの定義に適した選択肢と言える。

1.3.2 JSON：プログラム的対話とスキーマ強制の標準

JSON（JavaScript Object Notation）は、LLMアプリケーションのプログラム的レイヤーにおいて、機械間のコミュニケーションにおける事実上の標準となっている。その厳格で曖昧さのない構文は、高い信頼性が要求されるシステム連携に不可欠である。プロンプトエンジニアリングにおけるJSONの主要な用途は、二つに大別される。

第一に、「Function Calling（関数呼び出し）」である。LLMは、事前定義された関数スキーマに準拠したJSONオブジェクトを生成するようにファインチューニングされている。これにより、モデルは自然言語によるユーザーの要求を解釈し、外部のAPIやツールを呼び出すための具体的な引数を含んだJSONを生成できる。これは、LLMを単なるテキスト生成器から、外部システムと連携して実世界のアクションを実行できるエージェントへと昇華させる強力な機能である 21。

第二に、「Structured Outputs（構造化出力）」である。OpenAIのjson_modeや、より高度な構造化出力機能を用いてJSONスキーマを指定することで、モデルの応答を予測可能で型安全なフォーマットに強制することができる。これにより、データ抽出や分類といったタスクにおいて、脆弱な手動パーシングロジックを排除し、システムの信頼性を劇的に向上させることが可能になる 25。JSONは、非決定論的なLLMと決定論的なソフトウェアシステムとの間に、明確で検証可能なインターフェースを提供するのである。

これらのフォーマットの選択は、単に構造を追加するという表面的な行為ではない。それは、プロンプトの各レベルで曖昧さを体系的に排除していくプロセスと捉えることができる。散文形式のプロンプトは、曖昧さが最も高い状態にある。LLMは、本質的に不正確な自然言語から、ユーザーの意図、望ましいフォーマット、そして重要な制約を推測しなければならない 4。箇条書きは情報を分節化することで曖昧さを一部軽減するが、セグメント間の関係性は定義しない。Markdownは、

## 指示のような見出しを用いることで、各テキストブロックの「役割」に関する曖昧さを排除する 13。そしてYAMLとJSONは、キーと値のペアやデータ型といったスキーマ上の制約を導入することで、情報自体の「構造」と「型」に関する曖昧さを取り除く 17。したがって、フォーマットの選択とは、本質的に、どの程度の曖昧さを事前に排除し、どの程度をモデルの解釈に委ねるかという決定であり、この決定がシステムの信頼性と予測可能性に直接的な影響を与えるのである。

表1：プロンプトフォーマットの比較分析

特性散文 (Prose)箇条書き (Bulleted Lists)MarkdownYAMLJSON
構造的厳密性なし（非構造化）低い（順序または非順序のリスト）中程度（階層、セマンティクス）高い（キーと値、インデント）非常に高い（厳格な構文、型）
人間による可読性・保守性非常に高い高い非常に高い高い中程度（冗長な構文）
トークン効率タスクによる比較的高い非常に高い（軽量な構文）高い（JSONより軽量）低い（構文オーバーヘッド）
主要なユースケース創造的な生成、単純な質問応答、ブレインストーミング指示の列挙、ステップバイステップのガイド、単純なリスト作成複雑なプロンプトの構造化、技術文書の要約、明確な指示と文脈の分離プロンプトテンプレートの設定管理、複雑なプロンプトのバージョン管理Function Calling、構造化データ抽出、APIとのプログラム的連携
主な制約曖昧さ、一貫性の欠如、非効率性 4階層や意味的文脈の欠如、硬直的な応答のリスク 6厳密なスキーマ強制は不可、モデルの解釈に依存する部分が残る厳密なデータ抽出タスクで軽微な不整合の可能性 20人間による可読性の低さ、冗長なトークン消費 17

第2章 フォーマット駆動のパフォーマンス変動に関する実証的分析

プロンプトフォーマットの選択が、単なるスタイルの問題ではなく、LLMのパフォーマンスに直接的かつ測定可能な影響を与えることは、近年の研究によってますます明らかになっている。本章では、学術研究やベンチマークから得られた定量的データを統合し、フォーマットの選択が精度、一貫性、コスト（トークン効率）、そしてモデルの挙動といった具体的な指標にどのように影響するかを実証的に分析する。この分析を通じて、フォーマット設計が理論的な概念から、具体的なエンジニアリング上の決定事項へと移行する様を明らかにする。

2.1 精度、一貫性、ファクチュアルグラウンディングへの影響

2.1.1 パフォーマンス差の定量化

プロンプトのテンプレートやフォーマットを変更するだけで、モデルのパフォーマンスが劇的に変動することが、複数の研究で示されている。特に注目すべきは、GPT-3.5-turboのような比較的小規模なモデルが、フォーマットの変更に対して顕著な感度を示すことである。ある研究では、コード翻訳タスクにおいて、使用するプロンプトテンプレート（プレーンテキスト、Markdown、JSON、YAML）によって、GPT-3.5-turboのパフォーマンスが最大で40%も変動したことが報告されている 28。同研究では、特定のタスクにおいてJSONフォーマットがMarkdownに比べて42%高い精度を達成したという具体的なデータも示されている 28。

この現象は特定のモデルやタスクに限ったものではない。他のベンチマーク研究では、Mistralモデル群が適切なフォーマットを適用することで最大500%のパフォーマンス向上を示した例や、LLaMAモデル群で360%の改善が見られた例も報告されている 31。これらの数値は、プロンプトフォーマットが単なる補助的な要素ではなく、モデルの性能を最大限に引き出すための根幹的な要素であることを明確に示している。

表2：プロンプトフォーマットに関する実証的パフォーマンス所見の要約

研究/出典テスト対象モデルタスク比較対象フォーマット主要な発見
arXiv:2411.10541 28GPT-3.5-turbo, GPT-4コード翻訳プレーンテキスト, Markdown, JSON, YAMLGPT-3.5-turboで最大40%のパフォーマンス変動を観測。特定のタスクでJSONがMarkdownより42%高い精度を達成。
M. Gupta (2025) 31LLaMA, Mistral, IBM Granite命令追従 (IFEval)フォーマットなし vs. 適切なフォーマットMistralモデルで最大500%のパフォーマンス向上。LLaMAモデルで360%の向上。モデルサイズが常に性能を決定するわけではないことを示唆。
Reddit/PromptEngineering 6(非特定)要約、説明、書き換え命令ベース, Q&A, リスト, ロールベース命令ベースのプロンプトが最も一貫した出力を提供。Q&A形式はハルシネーションを減少させる傾向があった。

2.1.2 一貫性の向上とハルシネーションの抑制

構造化されたフォーマットは、単に精度を向上させるだけでなく、モデルの出力の信頼性と一貫性を高める上でも重要な役割を果たす。明確なスキーマやフォーマットを提供することで、プロンプトはモデルの広大な出力空間に制約を課す。これにより、モデルの応答はより予測可能になり、「創造的」な逸脱、すなわちハルシネーション（事実に基づかない情報の生成）を起こしにくくなる 1。

特に、出力をJSONスキーマに強制する機能は、モデルが必要なフィールドのみを、指定されたデータ型で返すことを保証するための強力な技術である 26。これにより、後続のシステムが応答をプログラム的に処理する際の安定性が大幅に向上する。同様に、Q&A形式でプロンプトを構成すると、モデルが関連情報に集中しやすくなり、ハルシネーションが減少する傾向があることも報告されている 6。構造化は、モデルの自由な連想を抑制し、タスクの要求に沿った、より事実に基づいた（grounded）応答を生成させるためのガードレールとして機能するのである。

2.2 トークンレベルの経済性分析

2.2.1 トークン化の基礎

LLMの運用において、トークンは計算とコストの基本単位である 33。テキストはモデルに処理される前に、トークンと呼ばれる共通の文字シーケンスに分割される。このプロセスをトークン化と呼ぶ。例えば、OpenAIのGPT-4などのモデルで広く使用されている

cl100k_baseエンコーディングは、約10万種類のトークンを用いてテキストを数値の配列に変換する 35。

一般的な英語のテキストでは、1トークンがおおよそ4文字、または単語の約4分の3に相当するという経験則がある 33。しかし、この比率は言語や文脈によって大きく変動するため、正確なトークン数を把握するには、専用のトークナイザーツールを使用することが不可欠である 38。APIの利用料金はトークン単位で課金され、各モデルにはコンテキストウィンドウ（一度に処理できるトークンの最大長）の制限があるため、トークン効率はシステム設計における重要な経済的・技術的制約となる 34。

2.2.2 フォーマットの冗長性とコストへの影響

プロンプトフォーマットの選択は、トークン効率に直接的な影響を及ぼす。JSONやXMLのようなフォーマットは、その構文的なオーバーヘッド（括弧{}、引用符””、カンマ,、タグ<>など）により、同じ意味内容を表現する場合でも、より軽量なMarkdownやYAMLに比べて多くのトークンを消費する傾向がある 9。

例えば、ある情報を表現するのに、Markdownでは数文字の記号で済むところが、JSONでは多くの追加的な構文トークンが必要になる。この差は、プロンプトが長大になるほど、またAPI呼び出しが頻繁になるほど、無視できないコストの差として現れる。トークン効率の高いフォーマットを選択することは、APIコストを削減し、限られたコンテキストウィンドウ内でより多くの実質的な情報（指示、文脈、例）をモデルに提供することを可能にする、重要な最適化戦略なのである 9。

2.2.3 非英語言語における不均衡なコスト

トークン化の非効率性は、特に非ラテン文字圏の言語、とりわけ日本語、中国語、韓国語（CJK言語）において顕著な問題となる。cl100k_baseのような一般的なエンコーディングは、主に英語のテキストデータに基づいて最適化されているため、CJK言語の文字は効率的にトークン化されない。多くの場合、漢字一文字が2つあるいは3つのトークンに分割されてしまう 35。

具体的なデータとして、日本語のテキストは、同じ意味内容を持つ英語のテキストに比べて、平均して約2.12倍のトークンを消費することが示されている 35。中国語（北京語）では1.76倍、韓国語では2.36倍という報告もある 35。これは、多言語アプリケーションを開発する際に、プロンプトの設計とフォーマットの選択が、コストとコンテキスト長の観点から極めて重要になることを意味する。冗長なフォーマットを避け、可能な限り簡潔な表現を用いることは、非英語圏のユーザー向けのサービスにおいて、経済的な実行可能性を左右するほどのインパクトを持つ可能性がある 41。

2.3 モデル固有の堅牢性とフォーマット感度

2.3.1 モデルのスケールとアーキテクチャの役割

プロンプトフォーマットに対する感度は、すべてのLLMで一様ではない。一般的に、GPT-4やその後継モデルのような、より大規模で高度なモデルは、GPT-3.5-turboのような比較的小規模または旧世代のモデルに比べて、プロンプトフォーマットの多様性に対してより堅牢（robust）であることが研究で示されている 28。

この現象は、モデルの能力向上の一環として、より構造化されていない入力からでもユーザーの意図を正確に推測する能力が高まっていることを示唆している。大規模モデルは、より多くのパラメータとより広範な学習データを通じて、多様な表現形式に対する一般化能力を獲得していると考えられる。したがって、小規模なモデルを使用する際には、パフォーマンスを安定させるために、より厳密で明確なプロンプトフォーマットを用いることが特に重要となる。

2.3.2 モデルファミリー固有の学習

異なるモデルファミリー（例えば、MetaのLLaMA、Mistral AIのMistralなど）は、それぞれ固有のプロンプトフォーマットや命令スタイルで学習・ファインチューニングされている 31。例えば、Mistralモデルは、ユーザーの指示を

とという特殊なタグで囲むことを期待している 42。同様に、LLaMAモデル群も特定のテンプレート構造を持つ 43。

これらのモデル固有のフォーマットに従わない場合、パフォーマンスが劇的に低下する可能性があることが報告されている 31。これは、モデルが学習データ内で繰り返し見た特定の構造的パターンを、命令の開始や役割の区別を認識するための強力なシグナルとして利用しているためである。したがって、特定のモデルの能力を最大限に引き出すためには、そのモデルの公式ドキュメントを参照し、推奨されるプロンプトフォーマットを遵守することが不可欠である。

2.3.3 普遍的な「最良」フォーマットの不存在

これまでの分析を総合すると、あらゆるタスクとモデルに対して普遍的に「最良」とされる単一のプロンプトフォーマットは存在しないという結論に至る。ある研究では、GPT-3.5-turboのコード翻訳タスクでJSONが優れた性能を示したが、これが他のタスクやモデルにも当てはまるとは限らない 28。

最適なフォーマットの選択は、常に特定の文脈に依存する。考慮すべき要因は、使用するモデルの特性（スケール、学習フォーマット）、タスクの性質（創造的か分析的か）、そして最適化しようとしている性能指標（精度、速度、コスト）である 28。プロンプトエンジニアリングにおける重要な教訓は、固定的なテンプレートに固執するのではなく、タスクの要件に応じてフォーマットを柔軟に選択し、実験を通じて最適なアプローチを特定することの重要性である。

このパフォーマンスの変動は、単なる明確性の問題だけでなく、プロンプトの構造がタスクに要求される「認知的アーキテクチャ」とどれだけ整合しているかという、より深いレベルの問題に起因すると考えられる。異なるフォーマットは、モデルを異なる推論モードへと誘導する。例えば、あるフォーラムのユーザーは、「本当の違いは、特定のタスクタイプに対して、そのフォーマットがモデルの推論プロセスをどれだけうまく導くかにある」と洞察に満ちた指摘をしている 6。タスクは、分析的、創造的、手続き的といった異なる推論パターンを要求する 6。厳格なキーと値の構造を持つJSONのようなフォーマットは、データ抽出のような分析的タスクと完全に整合し、モデルがエンティティと属性の観点から「思考」するよう促す。番号付きリストを持つMarkdownフォーマットは、手続き的なタスクと整合し、ステップバイステップの、いわゆる「思考の連鎖（Chain-of-Thought）」的なプロセスを奨励する 4。一方で、自由形式の散文プロンプトは、創造的なタスクと整合し、モデルに最大限の連想の自由を与える。したがって、最も効果的なプロンプトエンジニアは、単にフォーマットを選ぶのではなく、望ましい推論プロセスの「形状」を反映するフォーマットを選択する。これにより、モデルが意図された論理的経路をたどることが容易になり、パフォーマンスが向上するのである。

第3章 フォーマット感度のアーキテクチャ的基盤

第2章で実証されたフォーマットによるパフォーマンスの変動は、なぜ生じるのか。その答えは、LLMの根幹をなすTransformerアーキテクチャ、特にトークン化と自己注意（self-attention）機構の動作原理に深く関わっている。本章では、観測された現象の背後にある機械的な説明を提供し、プロンプトの構造的要素がモデルの内部処理にどのように影響を与えるかを解明する。これにより、プロンプトエンジニアリングが単なる経験則の集積ではなく、モデルのアーキテクチャに基づいた科学的なアプローチであることが明らかになる。

3.1 構造的トークンによる自己注意機構の誘導

3.1.1 自己注意機構の概要

自己注意機構は、Transformerアーキテクチャの中核をなすメカニズムであり、入力シーケンス内の各トークンが、シーケンス内の他のすべてのトークンに対してどれだけの「注意」を払うべきかを動的に計算する 46。これにより、モデルは単語間の長距離の依存関係を捉え、文脈に応じた豊かな単語表現を生成することができる。例えば、「The animal didn’t cross the street because it was too tired.」という文において、自己注意機構は「it」が「animal」を指していることを特定するために、「it」と「animal」の間の関連性を強く重み付けすることができる。この機構は、クエリ（Query）、キー（Key）、バリュー（Value）という3つのベクトルを用いて、各トークンの重要度スコアを計算することで機能する 46。

3.1.2 構造的アンカー

プロンプトフォーマットが自己注意機構に与える影響を理解する上で中心的な概念が、「構造的アンカー」である。Markdownの#や-、JSONの{や”:”、XMLの<や>といった構造を表す文字や記号は、トークン化プロセスにおいて一意のトークンに変換される 33。LLMは、ウェブ上の膨大なテキストデータ（コード、文書、設定ファイルなど）を学習する過程で、これらの「構造的トークン」が文脈の転換、階層関係、あるいはデータの境界を示す強力な予測子であることを統計的に学習する。

これらのトークンは、自己注意機構にとっての「アンカー（錨）」として機能するという仮説が立てられる。モデルがプロンプトを処理する際、注意ヘッド（attention heads）は、例えば### 指示という見出しや<context>タグの後に続くテキストに対して、より多くの「注意」を払うように学習することができる。これにより、プロンプトの異なる部分が効果的に分離され、優先順位が付けられる 12。その結果、モデルの処理は、単なるフラットなテキストの読解から、人間が適切にフォーマットされた文書を解釈するような、より構造化された解析へと変化する。この構造化された解析こそが、指示の正確な理解と実行につながるのである。

3.2 構造と意味を強制するトークン化の役割

3.2.1 構文のトークン化

第2.2節で触れたトークン化のプロセスは、フォーマットの構文をモデルがどのように「見る」かを理解する上で不可欠である。例えば、{“key”: “value”}という文字列は、モデルにとっては単一の文字列ではなく、{“、key、”:”、”、value、”}といったトークンのシーケンスとして認識される。このレベルで、フォーマットの構造はモデルへの入力として明示的にエンコードされる。

このトークン化された構文は、モデルの振る舞いを制約する上で決定的な役割を果たす。特に、構造化出力を要求する場合、このメカニズムが重要となる。

3.2.2 学習された構文パターン

LLMは単なる自然言語モデルではなく、ウェブ上の膨大なコードや構造化データを学習した、強力なパターンマッチングエンジンでもある。その学習過程で、JSON、Markdown、YAMLといったフォーマットの統計的な規則性、すなわち構文パターンを深く学習している。モデルは、どのトークンがどのトークンの後に続く確率が高いかという、巨大な確率分布を内部に保持している。

3.2.3 予測可能な出力の強制

この学習済みパターンが、構造化出力機能の基盤となる。プロンプトがJSON形式での出力を要求すると、モデルの生成プロセスは、有効なJSONトークンシーケンスに関する学習済みの確率分布によってガイドされる。json_modeのような機能が有効化されると、このプロセスはさらに強化される。モデルの次のトークン予測は、有効なJSONオブジェクトを形成し続けるトークンのみに制約される。例えば、モデルが{“key”:というシーケンスを生成した場合、次のトークンとして許容されるのは、文字列を開始する”や数値、あるいは別のオブジェクトを開始する{などに限定され、JSONの構文に反するトークンは選択肢から除外される。

このように、構造化出力の強制は、最も基本的なレベル、すなわちトークン予測の段階で実行される。これにより、モデルは単に「JSONらしく見せる」のではなく、構文的に完全に有効なJSONを生成することが保証されるのである 24。これは、プロンプトフォーマットがモデルの内部的な生成メカニズムに直接介入し、その出力を決定論的なシステムの要求に合致させる強力な例と言える。

この高度に構造化されたフォーマット、特にJSONの利用は、私たちがLLMと対話する方法における根本的な変化を示唆している。初期のプロンプトエンジニアリングは、より良い自然言語の応答を得ることに焦点を当てていた 3。しかし、アプリケーションにおける信頼性の要求が高まるにつれ、構造化出力の必要性が生まれた 26。Function Callingは、この抽象化をさらに一歩進め、LLMを、ユーザーの意図を形式的なAPI呼び出し（JSONオブジェクト）に変換する自然言語パーサーとして扱う 21。このJSONオブジェクトは、機械が読み取り可能な「契約」である。そのスキーマは厳格であり、その出力は予測可能である。アプリケーションコードは、LLMが何を意図したかを推測する必要がなく、構造化されたコマンドを受け取る。したがって、この文脈におけるプロンプトフォーマット（具体的にはJSONスキーマ）は、もはやモデルへの単なるヒントではなく、ソフトウェアインターフェースそのものの定義となる。これは、AIアプリケーションにおけるシステム設計、テスト、信頼性工学に重大な影響を及ぼす。プロンプトエンジニアは、今やAPI設計者の役割も担うようになったのである。

第4章 プロンプトフォーマット選択のための戦略的フレームワーク

これまでの分析で、プロンプトフォーマットがLLMのパフォーマンス、コスト、信頼性に多大な影響を与えること、そしてその背後にはアーキテクチャレベルのメカニズムが存在することを明らかにしてきた。本章では、これらの知見を統合し、実践的かつ実行可能なフレームワークを提示する。このフレームワークは、特定のタスク要件に基づいて最適なフォーマットを選択するための明確な指針を提供し、さらに複雑なシナリオに対応するための高度なハイブリッド戦略を探求する。

4.1 タスクとフォーマットのマッピングおよび決定基準

4.1.1 決定マトリクス

プロンプトフォーマットの選択は、場当たり的な決定ではなく、複数の要因を考慮した体系的なプロセスであるべきだ。最適なフォーマットを決定するための主要な基準は以下の通りである。

  • タスクの種類: 実行しようとしているタスクの性質は何か。創造的なテキスト生成、技術文書の要約、非構造化テキストからのデータ抽出、外部ツールの利用など、タスクによって最適なフォーマットは異なる。
  • 出力の信頼性要件: 出力にどの程度の厳密性が求められるか。低い信頼性（例：ブレインストーミング）から、中程度（例：要約）、高い信頼性（例：データ抽出）、そしてプログラム的に保証された信頼性（例：API呼び出し）まで、要求レベルに応じてフォーマットの厳格さを調整する必要がある。
  • 人間による可読性と保守性: プロンプトは誰が管理するのか。開発者がコード内で直接管理するのか、それとも非技術的なユーザーが容易に編集できる必要があるのか。この点は、YAMLのような可読性の高いフォーマットと、JSONのような機械指向のフォーマットとの間の選択に影響を与える。
  • システム連携: LLMの出力は、後続の自動化システムに直接入力されるか。その場合、出力は厳密に定義され、容易に解析可能である必要があるため、JSONのような構造化フォーマットが必須となる 1。

4.1.2 推奨事項

これらの基準に基づき、以下のような具体的な推奨事項を導き出すことができる。

  • 創造的な文章作成／ブレインストーミング: 散文形式から始めるのが最も自然である。必要に応じて、思考を整理するために軽いMarkdown（見出しやリスト）を追加すると良い。
  • 技術的な要約／レポート生成: Markdownを使用することで、元の文書の階層構造（見出し、リストなど）を維持し、明確で構造化された要約を生成させることができる。
  • 複数フィールドのデータ抽出: 最大限の信頼性を確保するため、OpenAIの構造化出力機能などを用いてJSONスキーマを指定することが強く推奨される。これにより、型安全で一貫した出力が得られる 26。
  • 外部ツール／APIのトリガー: Function Calling機能を利用し、JSONフォーマットで関数名と引数を生成させるのが標準的なアプローチである。これにより、LLMと外部システム間の信頼性の高い連携が実現する 21。
  • 複雑なプロンプト設定の管理: 複数のパートから構成される複雑なプロンプトテンプレートを管理・バージョン管理する場合、その可読性と構造化能力からYAMLが適している 18。

表3：タスク対フォーマット決定マトリクス

タスクの種類要求される信頼性保守性出力タイプ推奨される主要フォーマット副次的/ハイブリッド戦略
創造的な文章作成低高非構造化テキスト散文 (Prose)思考整理のための軽いMarkdown利用
コード生成中〜高高構造化テキスト（コード）Markdownコードブロック（“`）でコードを明示。Few-shot例を提示。
技術文書の要約中高半構造化テキストMarkdown元の文書の階層を維持するために見出しやリストを活用。
データ抽出非常に高い中〜高構造化データJSON (Structured Outputs)Markdownプロンプト内に抽出対象のJSONスキーマを記述。
API/ツール連携プログラム的に保証中構造化データ（APIコール）JSON (Function Calling)ユーザーの自然言語要求を解釈し、対応するJSONを生成。
プロンプトテンプレート管理N/A非常に高いテキストテンプレートYAMLGitでバージョン管理し、変数置換で動的にプロンプトを生成 18。
分類タスク高高単一ラベルまたはJSON散文/MarkdownFew-shot例を用いて出力形式（例：感情: ポジティブ）を明示。

4.2 高度な戦略：ハイブリッドプロンプトとフォーマットの組み合わせ

4.2.1 制御を強化するためのフォーマットの組み合わせ

最も洗練されたプロンプトエンジニアリングの実践では、単一のフォーマットに固執するのではなく、複数のフォーマットの長所を一つのプロンプト内で組み合わせるハイブリッドアプローチが採用される。これにより、より精密な制御が可能となる。

  • MarkdownとJSONの組み合わせ: Markdownで記述されたプロンプト内に、抽出したいデータのJSONスキーマを明記し、モデルにそのスキーマに従って情報を抽出するよう指示する。このアプローチは、人間にとっての可読性（Markdown）と、機械による処理の信頼性（JSON）を両立させる 1。
  • XMLタグの活用: Anthropic社がClaudeモデルに対して推奨するように、散文形式のプロンプト内で<document>、<instructions>、<examples>といったXMLタグを使用して、情報の種類を明確に区別する 50。これは、散文の自然さとマークアップ言語の曖昧さのない分節化能力を組み合わせた強力な手法である。構造タグは、モデルの注意機構に対して、各セクションの役割を明確に伝えるアンカーとして機能する。

4.2.2 プロンプトの連鎖と分解

非常に複雑なタスクに直面した場合、単一の巨大なプロンプトで全てを解決しようとすると、モデルが混乱し、指示の一部を無視するリスクが高まる 1。このような場合、タスクをより単純な一連のサブプロンプトに分解し、それらを連鎖させる（chaining）アプローチが有効である 51。

このワークフローでは、あるプロンプトの出力（しばしばJSONのような構造化フォーマットで生成される）が、次のプロンプトの入力として使用される。例えば、最初のプロンプトで非構造化テキストからキー情報をJSON形式で抽出し、次のプロンプトでそのJSONを入力として受け取り、要約レポートを生成させるといった多段階の処理が可能になる。このモジュール化されたアプローチは、各ステップの信頼性を高め、デバッグを容易にし、より堅牢で管理しやすいワークフローの構築を可能にする。

高度なプロンプト設計は、単一の「魔法の」フォーマットを見つけることではなく、中心的な要求の周りに「指示の足場（instructional scaffolding）」の層を構築することに他ならない。各フォーマットタイプは、この足場を構築するための異なるツールである。単純な要求は、骨組みのない構造のようなもので、LLMはそれを正しく構築することもあれば、崩壊させてしまうこともある。Markdownの見出しやリストは、この足場の主要な梁や支柱として機能し、要求される出力の全体的な形状を概説する 10。Markdown内でフォーマットされたFew-shotの例は、青写真や治具のように機能し、完成したコンポーネントがどのように見えるべきかをモデルに正確に示す 1。そして、JSONスキーマや明示的な型定義は、細かなコネクタや留め具として機能し、すべての部品がプログラム的な精度で組み合わされることを保証する 25。したがって、熟練したプロンプトエンジニアは建築家のように振る舞い、これらのフォーマットツールを選択・組み合わせて堅牢な足場を構築し、LLMがエラーを起こす余地を可能な限り少なくし、望ましい結果へと決定論的に導くのである。

結論

本分析は、プロンプトフォーマットが大規模言語モデル（LLM）のパフォーマンスに与える影響が、単なる表面的なスタイルの問題ではなく、精度、信頼性、コスト効率を左右する根幹的なエンジニアリング上の決定事項であることを明らかにした。散文、箇条書き、Markdown、YAML、JSONという5つの主要なフォーマットの特性と影響を体系的に検証した結果、以下の結論が導き出される。

  1. フォーマットはパフォーマンスに決定的影響を与える: 実証的データは、プロンプトフォーマットの選択がモデルのパフォーマンスに最大40%から500%もの変動をもたらしうることを示している 28。構造化されたフォーマットは、モデルの出力空間に制約を課すことで、一貫性を向上させ、ハルシネーションを抑制する。この影響は、特にGPT-3.5-turboのような比較的小規模なモデルで顕著である。
  2. フォーマット選択はトレードオフの最適化である: 普遍的に「最良」のフォーマットは存在しない。選択は常に、タスクの性質、要求される信頼性、人間による保守性、そしてシステム連携の要件といった複数の要因間のトレードオフを考慮して行われるべきである。Markdownは人間と機械の間の「共通言語」として優れたバランスを提供する一方、JSONはプログラム的な信頼性が最優先される場面で不可欠となる。
  3. 影響の根源はアーキテクチャにある: フォーマットへの感度は、LLMの根幹をなす自己注意機構とトークン化プロセスに起因する。Markdownの#やJSONの{}といった構造的トークンは、モデルの注意機構にとっての「アンカー」として機能し、プロンプト内の情報の階層と役割を伝え、処理を誘導する。構造化出力の強制は、トークン予測のレベルで構文的妥当性を保証するメカニズムである。
  4. プロンプトエンジニアリングからインターフェース設計へ: 特にFunction CallingやStructured OutputsにおけるJSONの利用は、プロンプトエンジニアリングが単なる「指示の記述」から、非決定論的なAIと決定論的なソフトウェアシステム間の厳密な「インターフェース設計」へと進化していることを示している。プロンプトエンジニアは、今やシステムのAPI設計者としての役割も担う。

最終的な推奨事項:

LLMを活用する開発者およびエンジニアは、フォーマット選択に対して、より意識的かつ戦略的なアプローチを取るべきである。

  • 原則に基づいた選択: 場当たり的な選択を避け、本レポートで提示した決定マトリクスのようなフレームワークを用いて、タスク要件に最適なフォーマットを体系的に選定すること。
  • モデル固有性の認識: 使用するモデルファミリー（GPT、Claude、LLaMA、Mistralなど）の公式ドキュメントを参照し、推奨されるプロンプトフォーマットを遵守すること。
  • ハイブリッドアプローチの採用: 複雑なタスクに対しては、単一のフォーマットに固執せず、Markdown、JSONスキーマ、XMLタグなどを組み合わせるハイブリッド戦略や、プロンプトを連鎖させるモジュール化アプローチを積極的に検討すること。
  • 継続的な実験と評価: 最適なフォーマットは文脈に依存するため、A/Bテストなどを通じて、異なるフォーマットがパフォーマンスに与える影響を定量的に評価し、継続的にプロンプトを改善するプロセスを確立すること。

プロンプトフォーマットは、LLMの能力を最大限に引き出し、信頼性が高く、効率的で、保守可能なAIアプリケーションを構築するための、最も強力かつ直接的なレバーの一つである。そのアーキテクチャ的基盤を理解し、戦略的に活用することこそが、次世代のプロンプトエンジニアリングに求められる中核的な能力と言えるだろう。

引用文献

  1. The Ultimate Guide to Prompt Engineering in 2025 | Lakera – Protecting AI teams that disrupt the world. https://www.lakera.ai/blog/prompt-engineering-guide
  2. Examples of Prompts | Prompt Engineering Guide https://www.promptingguide.ai/introduction/examples
  3. Best practices for prompt engineering with the OpenAI API | OpenAI … https://help.openai.com/en/articles/6654000-best-practices-for-prompt-engineering-with-the-openai-api
  4. A beginner’s guide to different prompt engineering techniques – Transmedia https://www.transmedia.co.uk/article/a-beginners-guide-to-different-prompt-engineering-techniques
  5. Conversational vs Structured Prompting – The Prompt Engineering Institute https://promptengineering.org/a-guide-to-conversational-and-structured-prompting/
  6. We tested 5 LLM prompt formats across core tasks & here’s what actually worked – Reddit https://www.reddit.com/r/PromptEngineering/comments/1lcpnqd/we_tested_5_llm_prompt_formats_across_core_tasks/
  7. Best Prompt Techniques for Best LLM Responses | by Jules S. Damji | The Modern Scientist https://medium.com/the-modern-scientist/best-prompt-techniques-for-best-llm-responses-24d2ff4f6bca
  8. YC says the best prompts use Markdown : r/LLMDevs – Reddit https://www.reddit.com/r/LLMDevs/comments/1ljdul6/yc_says_the_best_prompts_use_markdown/
  9. Why Markdown is the best format for LLMs | by Wetrocloud – The AI Stack for Automations https://medium.com/@wetrocloud/why-markdown-is-the-best-format-for-llms-aa0514a409a7
  10. Effective Prompt Engineering with the Markdown Prompts Framework | CodeSignal Learn https://codesignal.com/learn/courses/understanding-llms-and-basic-prompting-techniques-1/lessons/effective-prompt-engineering-with-the-markdown-prompts-framework
  11. Basic Syntax – Markdown Guide https://www.markdownguide.org/basic-syntax/
  12. Rustdoc Markdown: Empower Your LLMs with Precise Context | by Carlo C. – Medium https://autognosi.medium.com/rustdoc-markdown-empower-your-llms-with-precise-context-528411405e18
  13. Boosting AI Performance: The Power of LLM-Friendly Content in Markdown https://developer.webex.com/blog/boosting-ai-performance-the-power-of-llm-friendly-content-in-markdown
  14. How LLMs Interpret Content: How To Structure Information For AI Search https://www.searchenginejournal.com/how-llms-interpret-content-structure-information-for-ai-search/544308/
  15. Prompt Engineering: Best Practices for 2025 | BridgeMind Blog https://www.bridgemind.ai/blog/prompt-engineering-best-practices
  16. Prompt engineering tricks for LLMs – Blog by Grzegorz Kossakowski https://gkk.dev/posts/prompt-engineering-tricks-for-llms/
  17. Enhancing structured data generation with GPT-4o evaluating prompt efficiency across prompt styles – PMC – PubMed Central https://pmc.ncbi.nlm.nih.gov/articles/PMC11979239/
  18. Storing LLM prompts in YAML files inside a Git repository : r/PromptEngineering – Reddit https://www.reddit.com/r/PromptEngineering/comments/1hxoh6y/storing_llm_prompts_in_yaml_files_inside_a_git/
  19. YAML schema reference for Semantic Kernel prompts – Microsoft Learn https://learn.microsoft.com/en-us/semantic-kernel/concepts/prompts/yaml-schema
  20. Enhancing structured data generation with GPT-4o evaluating prompt efficiency across prompt styles – Frontiers https://www.frontiersin.org/journals/artificial-intelligence/articles/10.3389/frai.2025.1558938/full
  21. Function Calling with LLMs – Prompt Engineering Guide https://www.promptingguide.ai/applications/function_calling
  22. Function calling with the Gemini API | Google AI for Developers https://ai.google.dev/gemini-api/docs/function-calling
  23. Function calling – OpenAI API https://platform.openai.com/docs/guides/function-calling
  24. Announcing function calling and JSON mode – Together AI https://www.together.ai/blog/function-calling-json-mode
  25. [Feature Request] Function Calling – Easily enforcing valid JSON schema following – API https://community.openai.com/t/feature-request-function-calling-easily-enforcing-valid-json-schema-following/263515
  26. When should I use function calling, structured outputs or JSON mode? – Vellum AI https://www.vellum.ai/blog/when-should-i-use-function-calling-structured-outputs-or-json-mode
  27. Structured model outputs – OpenAI API https://platform.openai.com/docs/guides/structured-outputs
  28. Does Prompt Formatting Have Any Impact on LLM Performance? – arXiv https://arxiv.org/html/2411.10541v1
  29. Prompt structure affects LLM performance by up to 40%, challenging fixed templates. https://app.daily.dev/posts/prompt-structure-affects-llm-performance-by-up-to-40-challenging-fixed-templates–tgry2perm
  30. [2411.10541] Does Prompt Formatting Have Any Impact on LLM Performance? – arXiv https://arxiv.org/abs/2411.10541
  31. Prompt Formatting on LLM Performance: A Benchmark Study | by Manav Gupta | Medium https://medium.com/@manavg/prompt-formatting-on-llm-performance-a-benchmark-study-36ced6fb6f86
  32. Does Prompt Formatting Have Any Impact on LLM Performance? | alphaXiv https://www.alphaxiv.org/overview/2411.10541
  33. What are tokens and how to count them? – OpenAI Help Center https://help.openai.com/en/articles/4936856-what-are-tokens-and-how-to-count-them
  34. OpenAI Token Calculator – QuizRise.com https://www.quizrise.com/token-counter
  35. Working with Chinese, Japanese, and Korean text in Generative AI pipelines https://tonybaloney.github.io/posts/cjk-chinese-japanese-korean-llm-ai-best-practices.html
  36. OpenAI GPT-3 API: How does it count tokens for different languages? – Stack Overflow https://stackoverflow.com/questions/75454722/openai-gpt-3-api-how-does-it-count-tokens-for-different-languages
  37. Tokenizer – OpenAI API https://platform.openai.com/tokenizer
  38. Tokenizer and token counter (GPT, Claude, Gemini, Grok) – GPT for Work https://gptforwork.com/tools/tokenizer
  39. Token Calculator – AI Token Tools https://token-calculator.net/
  40. Tokenizer https://tokencounter.vercel.app/
  41. Hindi 8 times more expensive than English: the token price of text in different languages https://www.reddit.com/r/OpenAI/comments/124v2oi/hindi_8_times_more_expensive_than_english_the/
  42. mistral:instruct/template – Ollama https://ollama.com/library/mistral:instruct/blobs/1ff5b64b61b9
  43. Prompt Templates – LlamaIndex v0.10.17 https://docs.llamaindex.ai/en/v0.10.17/api_reference/prompts.html
  44. Prompting Guide for Code Llama https://www.promptingguide.ai/models/code-llama
  45. XML vs Markdown for high performance tasks – Prompting – OpenAI Developer Community https://community.openai.com/t/xml-vs-markdown-for-high-performance-tasks/1260014
  46. History of Attention Mechanism & an Introduction to Self-Attention with Visuals & code— Explained | by Shravan Kumar | Medium https://medium.com/@shravankoninti/history-of-attention-mechanism-an-introduction-to-self-attention-with-visuals-code-explained-a1529c79923e
  47. Prompt Injection Attacks on LLMs – HiddenLayer https://hiddenlayer.com/innovation-hub/prompt-injection-attacks-on-llms/
  48. Prompts with Markdown format are better? : r/ChatGPT – Reddit https://www.reddit.com/r/ChatGPT/comments/1gfgvhc/prompts_with_markdown_format_are_better/
  49. Prompt Engineering for AI Guide | Google Cloud https://cloud.google.com/discover/what-is-prompt-engineering
  50. Prompt engineering overview – Anthropic https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview
  51. Prompt Engineering of LLM Prompt Engineering : r/PromptEngineering – Reddit https://www.reddit.com/r/PromptEngineering/comments/1hv1ni9/prompt_engineering_of_llm_prompt_engineering/
  52. The Impact of Prompt Bloat on LLM Output Quality – MLOps Community https://mlops.community/the-impact-of-prompt-bloat-on-llm-output-quality/
レポート