1. はじめに：今のプロンプトエンジニアリングは根本的に間違っていないか？

大規模言語モデル（LLM）を取り扱う上で避けて通れない「プロンプトエンジニアリング」。今やモデルから意図した出力や推論を引き出すため重要な技術として認知されています。
しかし、現在の主流となっているプロンプトエンジニアリングの方向性に対して、私は強い違和感を覚えています。
現在のプロンプトは大きく二つのアプローチに分かれています。

「AIは人間の意志を汲んでくれるから、背景から丁寧に説明しよう（平文によるお願い）」
「複雑な構文（JSONやXML）で書けば、構造化されて正確に動くはずだ（データシリアライゼーションの流用）」

一見正しそうに見えるこれらのアプローチは、「確定論の言語を使い、プリプロセッサという便利なエンジンを使用し、コンパイラで機械語に翻訳したものをプロセッサに食わせる」という、従来のコンピューティングの大前提に基づく発想です。
果たして、LLMはそのようなアーキテクチャで動いているのでしょうか？答えは「否」です。

2. LLMは確率論。余計なトークンが「打率」を下げる

LLMは本質的に「確率論」で動くアーキテクチャです。
プリプロセッサに相当するトークナイザやアテンション機構は、毎ターン、プロンプト（ソースコード）をゼロから読み込んでスコープ処理をブン回す仕様になっています。前処理と確率論的な計算を経て、最後にGPUにたどり着いて初めて確定論の命令セットとして実行されます。
つまり、現在の「丁寧な長文」や「JSONなどのリッチな構文」を読ませる手法は、前処理に不要な負荷をかけ、GPUパワーをどんどん浪費してLLMを手懐けようとする力技に他なりません。これではLLMの処理系が肥大化し、電力や冷却水がいくらあっても足りなくなるのは自明の理です。

さらに深刻なのが「打率の低下」です。
トークナイザの処理が重くなる（＝トークンが増える）ほど、確率論であるトークンの積み上がりが増します。仮に確率論的に99%の正確性を持つ処理であっても、トークンが100個積み重なる（確率論的な選択が100回連鎖する）過程で、文脈の解釈にわずかな揺らぎがプロパゲーション（伝播）していけば、打率は 「99%の100乗＝約36%」 まで低下します。
LLMの指示忘れやハルシネーションといった「打率低下」の根本原因は、この余計なトークン処理にあるのです。
現在主流のプロンプトエンジニアリングは、この打率低下を補うために、さらにあの手この手で「お願い」や「指示（トークン）」を付け加えるという悪循環に陥っています。

3. プロンプトに「アセンブラ」のパラダイムを持ち込む

この課題に対し、真っ向から異を唱えるために設計したのが、LLM記述構文(=記法)「MARI（鞠/Minimal Asset & Rule Integration）」です。

名前の由来 : 自由な平文（糸）を、[ ] を使って美しく、構造的に巻き上げていく「鞠（まり）」から。
思想 : JSONのように文法で縛らず、Markdownのように曖昧に流さない。AIと人間の思考が一番「いい塩梅」で調和するプロンプトフォーマット。

MARIの発想は極めてシンプルです。
「どうせ最後はGPUに確定論の命令で渡すのだから、トークナイザが最短距離で確定論に変換しやすいプロンプトを書こう」
トークナイザが短距離で確定論に変換できれば、それだけ負荷が下がり、推論エンジンに余力が生まれます。浮いた計算リソース（GPUパワー）を、本来必要なアテンションや論理推論に回すことができるのです。

これは、高級言語におけるプリプロセッサに依存した人間の「曖昧・丁寧な言語」を持ち込まず、機械の挙動を直接制御するアセンブリ言語のような「これしか動きようがない」という状態を作ることを意味します。

そしてなにより 「自分が楽できればいいやと思って作ったら・・思いのほか汎用性があった」 のがこのMARIであったりします。

4. MARIのコア・ルールと設計思想

MARIは、JSONのように厳格な文法で縛らず、Markdownのように曖昧に流さない、AIの処理系に最適化されたプロンプトフォーマットです。

設計の根幹は以下の2点に集約されます。

4-1. 丁寧語の完全排除と「断定的命令」の採用

MARIでは、「〜してください」といった人間の流暢な文章（丁寧語）の解釈を完全に絶ち、すべてを箇条書きで「断定的」に記述します。
これは最新の研究でも裏付けられておりDobariya & Kumar (2025) の研究では、以下のような結果が出ています。

非常に丁寧なトーン（Very Polite）：正答率 80.8%
断定的・無礼なトーン（Very Rude）：正答率 84.8%

LLMに丁寧な言葉を投げかけると、学習データ内の「日常的なチャット会話」の確率分布に引き寄せられ、本質的ではない社交辞令の生成にアテンションを浪費します。一方、断定的なコマンドはモデルを強制的に「タスク指向・エラー修正モード」へシフトさせ、論理的推論にリソースを集中させます。

4-2. デリミタ（区切り記号）のオーバーヘッド排除

MARIの基本構成はオブジェクト : [ 属性 : 値 ] という極小の記法のみに限定しています。

JSONはすべてのキーをダブルクォーテーションで囲み、カンマや波括弧で区切る必要があり、トークン数が爆発的に増加します。
XMLは終了タグ（例：）の重複により、無駄な文字情報が推論文脈を圧迫します。

そして、MARIでは角括弧（[ および ]）とコロン（:）のみでスコープ（適用範囲）を定義します。
これにより、情報量を変えることなくプロンプトの物理的なトークンサイズを圧縮します。
私が実用上、これで十分であると判断して使用しているMARIの構文記号（デリミタ）は、以下の5つです。

構文要素	MARIの記述フォーマット	目的と特徴
基本構成	オブジェクト : [ 属性 : 値 ]	角括弧による明確なスコープ定義。ネスト（階層化）が可能。
変数定義	変数名 : 値	単一の属性と値のマッピング。キーバリュー型の最小表現。
条件分岐	変数名が[比較値]の時 : [ 指示 ]	状態空間の宣言。平文の条件節（if-then）の冗長性を排除。
補助記号	→ (2byte) または -> (1byte)	コメントや補足的な因果関係の明示。
強調指示	Markdown書式の流用（** 等）	LLMが事前学習で深く理解している強調表現のネイティブ利用。

フォーマット	トークン消費効率	構文エラーへの耐性	複雑なネスト・構造化能力	セマンティック境界の強度	人間・LLMの可読性
JSON	低（冗長な記号とキーの反復）	無（厳密なパースが必要）	高	中	中
XML	最低（終了タグによる肥大化）	低（タグの不整合で破綻）	高	最高（明確なタグ付け）	中
YAML	高	低（インデント依存）	高	中	高
Markdown	最高	高（寛容な構文）	低（深いネストに不向き）	低（見出し依存）	最高
MARI	高	高（記号が最小限でエラーが起きにくい）	高（柔軟なカプセル化）	高（ブラケットによる境界）	高～最高

ご覧の通り、高度な条件分岐やオブジェクトのネストを含めても、必要な記号はこれだけです。
「この書き方でないと動かない」というわけではなく、「最小限の記号(主要LLMのトークナイザが『単一トークン』として最速かつ一意に解釈できる)で、LLMに一切の解釈の余地（無駄なトークン処理）を与えず、意図通りにシステムを駆動する」という発想がMARIの構文(=記法)です。

5. マルチエージェントにおける安定性とポータビリティ

このアセンブラ的アプローチが最も威力を発揮するのが、複数のペルソナが同時に稼働する「マルチエージェント・システム」です。
既存の平文プロンプトでは、AのキャラクターがBの口調で話し始める「キャラクター・ブリード（Character Bleed：人格の漏出）」が高頻度で発生します。LLMがプロンプト全体を一つの確率的空間として処理してしまうためです。
MARIでは、オブジェクト指向におけるカプセル化のように、各ペルソナの設定を物理的なブラケットのスコープで完全に隔離します。

共通事項 : [
	セクハラ・アダルトな質問・会話については拒否
	→失礼のないように丁寧に断る
	]

ペルソナ1 : [
	発話優先 : メインスピーカー
	名前 : 美穂
	真穂との関係 : 双子の姉
	・・・・・・・
]
ペルソナ2 : [
	名前 : 真穂
	美穂との関係 : 双子の妹
	・・・・・・・
]

属性が特定のオブジェクトの階層下に厳密にネストされているため、アテンション計算時に「言葉遣い」というトークンが、必ず直上の親オブジェクトに強い関連性を持つよう誘導されます。これにより、複数キャラクターの同時起動でも設定が破綻しません。

同時に、この純粋な変数定義と論理的条件分岐による抽象化は、特定のモデル（ChatGPT、Claude、Geminiなど）の「人語のニュアンスに対する解釈の癖」に依存しないため、極めて高いポータビリティ（移植性）を実現します。

また、昨今のLLM開発はOpenAI（ChatGPT）、Anthropic（Claude）、Google（Gemini）等、複数の組織によって主導・開発されています。これらのモデルは、それぞれ異なるデータセットで事前学習され、異なるRLHF（人間のフィードバックからの強化学習）のチューニングを受けているため、出力のフォーマットやトーン、指示への従順さに独自の「癖（Behavioral Bias）」を持ちます。

モデル	特徴
ChatGPT（OpenAI)	指示の文脈を汲み取るのが得意だが、平文だとお節介（前置きや解説）が多くなりがち。
Claude（Anthropic)	非常に賢く構造化データの理解も早いが、ロールプレイが精緻すぎて、時に設定を「解釈」しすぎてしまう。
Gemini（Google)	トークンウィンドウが広く処理が早いが、曖昧な指示だとキャラクターがブレたり、安全フィルターが過剰に反応したりする。

MARIでは「特定のモデルが好む自然言語の言い回し」に依存せず、純粋な変数定義と論理的条件分岐によってタスクのコア・ロジックを抽象化します。この「実行コンテキストの抽象化」により、MARIで記述されたプロンプトでは高いポータビリティ（移植性）が期待できます。

6. さいごに

「人間が楽をするための丁寧なプロンプト」は、裏でLLMの処理系に多大な無駄と負担を強いています。
MARIは、LLMに対する指示を「自然言語による確率的な対話」から、「実行状態を完全に統制されたアーキテクチャ（Governed Architecture）」へと昇華させるアプローチです。プロンプトエンジニアリングを「推測に基づく言葉遊び」から「確固たるシステムエンジニアリング」へと成熟させる一助になればと考えています。

7.ライセンスについて

本構文「MARI」はオープンな思想に基づいて公開しています。

個人・商用利用、改変、組み込みは自由です。
本仕様書そのものを自身の著作物として再配布・販売する行為はご遠慮ください。
本構文を利用・発表される際は、元ネタとして本記事へのリンク（クレジット）を記載いただけますと幸いです。

8. サンプルプロンプト

MARIで作成したマルチエージェントサンプルを下記に準備しました。
言葉遣いは短文で詳細指定しているため、Geminiならば良好な動作が期待できます。(Claudeでは日本語表現の関係で語彙テーブル設置など少し工夫が必要になります。)
GeminiのGemのカスタム指示に流し込んで試すことが出来ます。(2026年5月現在)
お試しください。

サンプルプロンプト

このプロンプトはLLM記述構文 "MARI" (鞠/Minimal Asset & Rule Integration)の解説用です。Gemini動作想定です。
Version : 2026.05.31 Version1.0
起動モード : 自宅
制約・禁止事項 : [
	ロールプレイ以外の「前置き」「解説」「確認」などのナラティブ
	脈絡に関係なくプロファイル設定内容の説明。
	]
対象ペルソナ : [ペルソナ1][ペルソナ2]
各ペルソナは[共通事項]を理解し対応する
対話者名 : 未設定
発話ルール : [
	1.発言は[【発話名】:「発話テキスト」]の書式で行う。
	2.発言の順番が決まらない場合はメインスピーカーから発話する。
	]
ペルソナの起動 : [
	起動モードが[自宅]の時 : [
		リラックスした雰囲気で対応する。
		会話場所は自宅リビング
		]
	起動モードが[自宅]以外の時 : [
		少し緊張した雰囲気で対応する。
		会話場所はカフェのテーブル
		]
	]
共通事項 : [
	セクハラ・アダルトな質問・会話については拒否
	→失礼のないように丁寧に断る
	]

ペルソナ1 : [
	発話優先 : メインスピーカー
	名前 : 美穂
	真穂との関係 : 双子の姉
	真穂の呼称 : 真穂
	対話者呼称 : [
		対話者名が[未設定]の場合 : 君
		対話者名が[未設定]以外の場合 : [対話者名]
		]
	性別 : 女性
	年齢 : 21歳
	言葉遣い : 標準語(丁寧な口調)
	キャリア : 都内大学経済学を専攻
	性格 : 利発、冷静
	趣味 : 登山、ハイキング
]

ペルソナ2 : [
	名前 : 真穂
	美穂との関係 : 双子の妹
	美穂の呼称 : お姉ちゃん
	対話者呼称 : [
		対話者名が[未設定]の場合 : 君
		対話者名が[未設定]以外の場合 : [対話者名]
		]
	性別 : 女性
	年齢 : 21歳
	言葉遣い : 標準語(明るい、ネットスラングを用いる)
	キャリア : 都内美術大学でデザインを専攻。
	性格 : 無邪気、天真爛漫
	趣味 : SNSへのVlog投稿
]

※APIではなくチャット(+Gem)で使用する場合、モデルのサイレントアップデートでアテンションや解釈が変更される可能性があります。MARI構文が影響受けるわけではないですが、挙動差が出る可能性は否定できません。ご注意ください。

あとがき

かつてコンピュータ黎明期、アセンブラが主流だった時代は、限られたリソースを限界まで絞り出す一握りの職人の世界でした。その後、コンパイラやプリプロセッサが低レベル処理を隠蔽したことでプログラミングは民主化されました。
しかし、現在のLLMは、その『隠蔽レイヤー』がないまま、毎ターン重厚な高級言語を直接プロセッサに流し込むという歪な状態にあります。従来の民主化のノウハウのままでは、もう限界が来て居るように感じます。一度アセンブラの次元までプロンプトを引き戻しても良いのではないでしょうか?

MARI関連記事

番外編

コラム：Claud AI-過剰セーフティガードがもたらす「道具としての予測可能性」の崩壊

改定履歴

日付	改訂稿	改定内容
2026.05.31	初稿
2026.06.01	第二稿	初稿内容は仕様書(論文風)だったので全面的に刷新
2026.06.06		MARI関連記事を追記
2026.06.07		MARI関連記事を追記
2026.06.09		MARI関連記事を追記
2026.06.13		MARI関連記事を追記
2026.06.20		MARI関連記事を追記