プロンプトは「お願い」ではなく「コード」。論理式を応用した「公理系」プロンプトエンジニアリング

(この記事はスマホでAIに書かせました)

はじめに

ChatGPTをはじめとする大規模言語モデル（LLM）の進化が止まりません。まるで人間のように自然な対話ができるAIですが、その能力を最大限に引き出すためには、少し特殊な「話し方」のコツが必要です。

特に私たちエンジニアにとっては、AIを曖昧な対話相手としてではなく、仕様書通りに動くべきシステムとして捉える視点が重要になります。

この記事では、「なぜAIへの指示（プロンプト）に論理的な構造が有効なのか？」というテーマを、論理式 や 公理 といったキーワードを使いながら、誰にでも分かるように解説していきます。

「論理式」ってそもそも何だっけ？

難しく考える必要はありません。
論理式とは、一言でいえば最終的に『はい(Yes)』か『いいえ(No)』の答えが必ず出る、計算式のようなものです。

私たちは日常的に論理を使っています。
例えば、Webサイトの会員登録。

「利用規約に同意する」にチェックを入れ、かつ、
「メールアドレスが正しい形式である」

これが簡単な論理式です。
両方の条件がはい(真)にならないと、登録ボタンは押せませんよね。

この論理式は、主に3つの部品でできています。

1. 命題：「はい/いいえ」で答えられる主張。
   • 例：「利用規約に同意する」チェックボックスがオンになっている。
2. 論理演算子：命題をつなぎ合わせる接続詞。
   • AND (かつ)：両方「はい」なら「はい」。
   • OR (または)：どちらかが「はい」なら「はい」。
   • NOT (ではない)：「はい」と「いいえ」をひっくり返す。
3. 最終的な答え：式全体の結果として出る、ただ一つの「はい」か「いいえ」。

この曖昧さがなく、誰がどう見ても一つの結論にしかたどり着かないという性質が、AIへの指示において非常に重要になります。

プロンプトを「公理系」としてデザインする

では、この考え方を実際のプロンプトにどう活かすのでしょうか。
それは、プロンプトを単なる「お願い文」ではなく、数学や論理学の世界で使われる公理系=Axiomatic Systemとしてデザインするアプローチです。

難しそうに聞こえますが、要はルールブックを作るということです。

ゲームに例えてみましょう。

• 公理 (Axiom)：ゲームの基本ルール。証明不要で、全員が従う大前提。（例：「プレイヤーは交互にカードを1枚引く」）
• 定理 (Theorem)：基本ルールから導かれる必勝法やテクニック。（例：「このカードとあのカードを組み合わせると強い」）

プロンプトもこれと同じで、AIに守ってほしい証明不要の絶対的なルール=公理を最初に定義してあげることで、AIの思考を正しく導くことができます。

具体例：記事の要約プロンプト

以下は、「記事のテーマに応じて要約スタイルを変える」サンプルプロンプトの構造です。

要約タスクのプロンプト設計

# 前提 (Premise)
# ここでは、AIが処理する入力データを定義します。
- `a`: これから入力される記事データ

# 定義 (Definition)
# ここでは、プロンプト内で使う「言葉」や「操作」を定義します。
# 後から何度も同じ指示を書かなくて済むように、ここで変数のように定義しておくのがポイントです。
- `Summarize_Expert(a)`: 記事aを専門用語を含めて専門家向けに要約する操作
- `Summarize_Beginner(a)`: 記事aを平易な言葉で初心者向けに要約する操作

# 公理 (Axiom)
# ここで、AIが絶対に従うべき「ルール」を記述します。
# 「もし(IF)～ならば(THEN)～せよ」という形式で書くのが基本です。
- 1. もし`Theme(a)`が`"テクノロジー"`ならば、出力は`Summarize_Expert(a)`でなければならない。
- 2. もし`Theme(a)`が`"経済"`ならば、出力は`Summarize_Beginner(a)`でなければならない。

より精確な論理式化

要約タスクの論理式設計

# 前提 (Premise)
システム（AI）が受け取る、議論の出発点となる事実です。
 * 前提1: a は入力された記事である。
   * a \in A （aは記事の集合Aの要素である）
 * 前提2: 全ての記事 x は、ただ一つのテーマ Theme(x) を持つ。
   * \forall x \in A, \exists! t (Theme(x) = t)


# 定義 (Definition)
操作や概念を明確に定めます。
 * 定義1: Summarize_Expert(x) とは、記事 x を専門用語を含めて専門家向けに要約する操作（関数）である。
 * 定義2: Summarize_Beginner(x) とは、記事 x を平易な言葉で初心者向けに要約する操作（関数）である。
 * 定義3: Output(x) とは、記事 x に対して最終的に生成されるべき成果物（要約）である。


# 公理 (Axiom)
このシステム内で絶対的な真実として扱われる、議論の余地のないルール（AIへの指示の核）です。
 * 公理1: もし記事 a のテーマが「テクノロジー」であるならば、最終的な成果物は「専門家向けの要約」でなければならない。
   * 論理式:
       Theme(a) = \text{「テクノロジー」} \rightarrow Output(a) = \text{Summarize\_Expert}(a)
     
 * 公理2: もし記事 a のテーマが「経済」であるならば、最終的な成果物は「初心者向けの要約」でなければならない。
   * 論理式:
       Theme(a) = \text{「経済」} \rightarrow Output(a) = \text{Summarize\_Beginner}(a)

このプロンプトを受け取ったAIは、次のように思考します。

• なるほど、入力は記事aだな。（前提の認識）
• Summarize_ExpertとSummarize_Beginnerという2つの操作が定義されているな。（定義の認識）
• 与えられた記事のテーマを判定しよう。もしテクノロジーならルール1、経済ならルール2に従えばいいんだな。（公理の認識）

このように、AIは曖昧な「気持ち」を汲み取るのではなく、与えられたルールブックに従って機械的に処理を進めることができます。これにより、出力の精度と安定性が劇的に向上します。

書けるかこんなもん

ご安心下さい。
AIは翻訳が得意です。
普通のプロンプトを以下のように論理式に翻訳させてください。

以下のプロンプトを、包括的網羅的構造的に、かつ簡潔に、前提/定義/公理の形式で論理式化せよ。

プロンプト:

一度別の言語体系に翻訳させる事で、機械がどのように自分の自然文リクエストを解釈し、どういった部分に強くフォーカスしているのか、論理的に検証出来るといった、デバッグ作業の意図も含んでいます。

このアプローチがもたらす3つの大きなメリット

プロンプトをこのように論理的に構造化すると、特にシステム開発の現場で嬉しいメリットが3つあります。

メンテナンス性と再利用性の確保

プロンプトが「前提」「定義」「公理」のように部品（モジュール）化されているため、仕様変更に非常に強いです。

• メンテナンス性：もし「経済記事の要約を、もっと詳しくしてほしい」という変更があっても、# 定義セクションのSummarize_Beginner(a)の部分を修正するだけで済みます。プロンプト全体を読み解く必要はありません。
• 再利用性：「専門家向けの要約」というSummarize_Expert(a)の定義は、他のプロンプトでも使い回しができます。まるで関数をインポートするような感覚です。

出力トーンが引きずられない

LLMは、プロンプト全体の文体に影響されやすい性質があります。しかし、この構造では指示のロジックを記述する部分=公理などと出力のスタイルを定義する部分=定義が分離されています。
これにより、指示自体は機械的で無味乾燥な記述をしつつ、出力は「フレンドリーに」「専門的に」といった指定通りのトーンを維持でき、意図しないトーンの混入を防ぎます。

結果的にトークンを節約できる

一見、構造化するとプロンプトが長くなるように見えます。しかし、長い目で見るとトークンの節約につながります。

• 「一発OK」の確率が上がる：曖昧な指示で何度も修正のやり取りを重ねるより、厳密な指示で一回で望む出力を得た方が、合計トークンは少なくなります。
• 冗長性の排除：「専門家向けに、専門用語を使い、詳細に要約して…」のような説明を毎回書く必要がありません。Summarize_Expert(a)と定義を一度参照するだけで済みます。

注意点:「定理」をプロンプトに書くな

書いてはいけません。
書くな。
何故かというとゴミになるからです

おさらいです

• 公理 (Axiom)：ゲームの基本ルール。証明不要で、全員が従う大前提。（例：「プレイヤーは交互にカードを1枚引く」）
• 定理 (Theorem)：基本ルールから導かれる必勝法やテクニック。（例：「このカードとあのカードを組み合わせると強い」）

定理をプロンプトに書くと、AIは「その道ばっかり選ぶ」ようになります。
どんなゲームでもボタン連打でクリアしようとするような馬鹿になります。
というか書くシーンないと思うんで書かない方がいいっす
公理が合ってるかのデバッグもまともに出来なくなります

おわりに

AIへの指示、プロンプトエンジニアリングは、単なる「言葉遊び」や「魔法の呪文探し」ではありません。それは、AIという対話システムに対して、いかにして曖昧さのない仕様を伝え、意図通りに動かすかというシステム設計の一種です。

そして、例え相手が意思を持たない機械であろうとも、言語というツールを使って意思伝達を行う以上、相手がどのように理解しているのかという行間を読む行為こそが、目的達成=相互理解の基本中の基本である事は疑いようがありません。

今回紹介した「論理式」や「公理系」という考え方は、そのための強力な武器になります。
ぜひ皆さんの開発現場でも、「AIにルールブックを渡す」という感覚でプロンプトを設計してみてください。きっと、AIの出力がより安定し、信頼性の高いものになるはずです。

参考論文

1. 論文名: "Dissecting Logical Reasoning in LLMs: A Fine-Grained Evaluation and Supervision Study"

• 論文URL: https://arxiv.org/html/2506.04810v1
• 公開日: 2025年6月
  この論文は、LLMの論理的な推論プロセスを詳細に評価する研究です。特に重要なのは、プロンプトのスタイルが推論の質にどう影響するかを分析している点です。
  論文の調査結果（Findings）セクションでは、以下のように述べられています。

"natural language supervision yields strong generalization [...] while symbolic reasoning styles promote more structurally sound and atomic inference chains."
（自然言語による指示は強力な汎化性能をもたらす一方、記号的な推論スタイル（symbolic reasoning styles）は、より構造的に健全で、原子的な（＝最小単位の）推論の連鎖を促進する）

これは、プロンプトに記号（シンボル）を用いたり、論理式のように形式的なスタイルを取り入れたりすることが、LLMの推論ステップをより論理的で堅牢にすることを直接的に示す強力なエビデンスです。曖昧な自然言語よりも、構造化された指示の方が推論の「質」を高めることを意味します。

1. 論文名: "Structure Guided Prompt: Instructing Large Language Model in Multi-Step Reasoning by Exploring Graph Structure of the Text"

• 論文URL: https://arxiv.org/html/2402.13415v1
• 公開日: 2024年2月
  この研究は、複雑な多段階の推論を行わせるために、「構造化誘導プロンプト（Structure Guided Prompt）」という新しいフレームワークを提案しています。これは、非構造のテキスト（通常の文章）を、LLM自身に**グラフ構造（Graph Structure）**へと変換させ、その構造に沿って推論を進めさせる手法です。
  グラフはノードとエッジで関係性を表現する形式的な論理構造であり、まさに論理式が持つ関係性の明示化と同じ考え方です。論文では、この手法により、

"it enables LLMs to provide more accurate and context-aware responses."
（LLMがより正確で、文脈を認識した応答を提供できるようになった）

と結論付けています。これは、プロンプトを通じてタスクに明確な論理構造（この場合はグラフ構造）を課すことが、LLMの精度を向上させることを直接的に示しています。

1. 論文名: "The STROT Framework: Structured Prompting and Feedback-Guided Reasoning with LLMs for Data Interpretation"

• 論文URL: https://arxiv.org/html/2505.01636v1
• 公開日: 2025年5月
  この論文は、特にデータ分析などのタスクにおいて、LLMの信頼性を向上させるための「構造化プロンプティング（Structured Prompting）」フレームワークを提案しています。
  この研究の重要な点は、「ゴール指向のプロンプト足場（Goal-Aligned Prompt Scaffolding）」という概念です。これは、分析のゴールやデータのスキーマ（構造）に基づいてプロンプトを動的に構築するアプローチです。論文では、

"This ensures that the model's reasoning is grounded in the structural and statistical profile of the input, aligning generated logic with user intent."
（これにより、モデルの推論が入力の構造的・統計的なプロファイルに根差したものとなり、生成されたロジックがユーザーの意図と一致することが保証される）

と述べています。つまり、プロンプトを場当たり的な自然言語で記述するのではなく、データが持つ本来の論理構造に合わせて設計することで、LLMの推論がユーザーの意図とずれにくくなることを示しています。