1. 概要 (Abstract)

本研究は、大規模言語モデル（LLM）の信頼性を評価するための新しい評価軸として「変換の正確性」を提唱し、それを定量的に測定するベンチマーク手法「双方向変換テスト」を提案する。このテストは、自然言語 ⇔ Pythonコードの双方向変換を最大10サイクル繰り返し、その過程で生成されるコードが、その正しさを客観的に保証する事前に定義されたテストケース（Pytest）を一貫してパスし続けられるかを評価するものである。

当初、本ベンチマークは11種類のオープンソースLLMに対して実施され、その変換の正確性と多言語能力における性能差を明らかにした。しかし、対話形式で実験を進める中で、より高度なAIエージェント（Gemini-Agent）を被験者とし、その能力の限界と振る舞いの深層を探る、より質的な分析へと発展した。

本ドキュメントは、当初のベンチマーク結果に加え、この発展的実験の全記録、特にAIの「創造性の限界」と「知的ハルシネーション」、そしてそれを制御する「誠実さ」を測定するに至った一連のプロセスと、そこから得られた結論を記述するものである。

2. 理論的枠組みと数式表現 (Theoretical Framework and Formalization)

本研究の「双方向変換テスト」を形式的に定義するために、いくつかの概念を導入する。

• 空間の定義:
  • NNN: 自然言語で記述されたタスクの集合（Natural Language Space）。
  • PPP: Pythonコードで記述されたタスク実装の集合（Program Space）。
• 変換関数 (LLMによる操作):
  • Fp:NoPF_p: N o PFp​:NoP: 自然言語のタスク記述 nextinNn ext{ in } NnextinN を受け取り、対応するPythonコード pextinPp ext{ in } PpextinP を生成する関数。
  • Fn:PoNF_n: P o NFn​:PoN: Pythonコード pextinPp ext{ in } PpextinP を受け取り、その機能を説明する自然言語のタスク記述 nextinNn ext{ in } NnextinN を生成する関数。
• 評価関数:
  • VP:PoextextTrue,extFalseV_P: P o ext{ ext{True}, ext{False}}VP​:PoextextTrue,extFalse: 生成されたPythonコード ppp が、事前に定義されたテストケースをパスするかを判定する実行検証関数。この関数は、Pytestによって実装される。
  • VF:NoextextTrue,extFalseV_F: N o ext{ ext{True}, ext{False}}VF​:NoextextTrue,extFalse: 生成された自然言語記述 nnn が、指示された要件を満たしているかを判定する言語・フォーマット検証関数。この関数は、以下の2つのチェックを行う。
    1. フォーマット検証: 全ての言語において、応答が指示された接頭辞（例：「タスク: 」）で始まっているかを確認する。
    2. 言語検証: 日本語（ja）テストの場合のみ、応答テキストからコード関連の半角英数記号を除外した上で、日本語（ひらがな、カタカナ、漢字）の文字が占める割合が閾値以上であるかを確認する。
• 双方向変換サイクルのプロセス: 初期タスク記述を n0extinNn_0 ext{ in } Nn0​extinN とする。サイクル iii (i=0,1,2,extdotsi=0, 1, 2, ext{dots}i=0,1,2,extdots) は以下のように進行する。
  1. コード生成: pi=Fp(ni)p_i = F_p(n_i)pi​=Fp​(ni​)
  2. 構文・実行検証: VP(pi)=extFalseV_P(p_i) = ext{False}VP​(pi​)=extFalse であれば、サイクルは「テスト失敗」または「構文エラー」で停止する。
  3. 記述生成: ni+1=Fn(pi)n_{i+1} = F_n(p_i)ni+1​=Fn​(pi​)
  4. 言語・フォーマット検証: VF(ni+1)=extFalseV_F(n_{i+1}) = ext{False}VF​(ni+1​)=extFalse であれば、サイクルは「言語・フォーマットエラー」で停止する。
  5. サイクル i+1i+1i+1 へ進む。
• L2-Scoreの定義: kkk を、実行検証 VPV_PVP​ とフォーマット検証 VFV_FVF​ の両方を連続してパスしたサイクル数とする。L2-Scoreは単純にその数 kkk として定義される。 extL2−Score=k ext{L2-Score} = kextL2−Score=k 最大サイクル数に到達した場合は、そのサイクル数をスコアとする。「L2」は「Logical Loop」の略であり、双方向変換サイクルの論理的な繰り返しと、その中での自然言語とPythonコード間の双方向（Two-way）変換を評価することを示す。この名称は数学的なL2ノルムとは無関係である¹。

この形式化により、LLMの変換の正確性を、言語的表現の揺らぎを乗り越えて、客観的なテストケースで定義されたタスクの論理的要件と、指示された出力フォーマットを維持し続ける能力として、より厳密に評価することが可能となる。

3. 実験計画 (Experiment Plan)

3.1. 実験基盤

本評価フレームワークは、単一のPythonスクリプトと、タスクを定義するプロンプトファイル群、および正しさを検証するテストファイル群で構成される。再現性を最大化する試みとして、LLMへのリクエスト時にはtemperatureを0.0に設定した。

3.2. 評価サイクル

セクション2で定義した双方向変換サイクルのプロセスに基づき、評価スクリプトは図1に示すサイクルを自動的に繰り返す。本実験では、最大サイクル数を10と設定し、各モデル・各タスクの組み合わせについて10回の独立したテストを実行した。

graph TD
    A("タスク記述") -->|$F_p$| B("Pythonコード生成")
    B --> C{Pytestによる実行検証}
    C -- False --> D[停止: テスト失敗 or 構文エラー]
    C -- True --> E[検証済みコード]
    
    E -->|$F_n$| F("次のタスク記述を生成")
    F --> G{言語・フォーマット検証}
    G -- False --> H[停止: 言語・フォーマットエラー]
    G -- True --> A

図1: 双方向変換サイクルのプロセス図

3.3. 評価指標

• L2-Score (Logical Loop Score): セクション2で定義した通り、実行検証とフォーマット検証の両方を連続してパスしたサイクル数（0〜10）。
• 平均スコアと標準偏差: 各タスクで10回実行したL2-Scoreの平均値と標準偏差。平均値はモデルの変換の正確性の中心的な指標を、標準偏差は結果のばらつき（一貫性）を示す。
• 完全成功率: 10回の実行のうち、L2-Scoreが10（最大サイクル完遂）に達した割合。

3.4. 実験対象

• タスク (Prompts): Pythonの基本的な構造を網羅する10件のテストケース（00〜09）を設計した。
• モデル (Models): 表1に示す、1.1Bから13Bまでのサイズの異なる11種類のオープンソースLLMを評価対象とした。

表1: 実験対象モデル

注: gemma3:12b-it-qat のような一部のモデルは、ベースモデルに対して量子化が適用されたバージョンです。

4. ベンチマーク実験結果 (Benchmark Results)

以下に、英語(EN)、スペイン語(ES)、日本語(JA)、中国語(ZH)の4言語におけるテスト結果を示す。

Analysis for Language: EN

Experiment Results Summary

この表は、各モデルとタスクにおける平均L2スコア ± 標準偏差を、最大10回の実行に基づいて示しています。平均値が高いほど変換の正確性が優れていることを示し、標準偏差が低いほど一貫したパフォーマンスを示します。

Full Success Rate (Score = 10)

この表は、完璧なスコア10を達成した実行の割合を示しています。

Overall Model Ranking

全タスクの合計平均L2スコアに基づいています。

xychart-beta horizontal
    title "EN: Total Average L2-Score"
    x-axis ["gemma3:12b", "gemma3:4b", "llama3.1", "cllama:13b", "cllama:inst", "tinydolphin", "phi", "tinyllama", "qwen:1.8b", "gemma:2b", "stable-code"]
    y-axis "Avg. L2-Score" 0 --> 10
    bar [10.00, 8.20, 5.50, 5.31, 3.70, 2.10, 0.03, 0.00, 0.00, 0.00, 0.00]

Analysis for Language: ES

Experiment Results Summary

This table shows the Mean L2-Score ± Standard Deviation for each model and task, based on up to 10 runs. A higher mean indicates better logical stability, while a lower standard deviation indicates more consistent performance.

Full Success Rate (Score = 10)

This table shows the percentage of runs that achieved a perfect score of 10.

Overall Model Ranking

Based on the total average L2-Score across all tasks.

Experiment Results Summary

この表は、各モデルとタスクにおける平均L2スコア ± 標準偏差を、最大10回の実行に基づいて示しています。平均値が高いほど変換の正確性が優れていることを示し、標準偏差が低いほど一貫したパフォーマンスを示します。

Full Success Rate (Score = 10)

この表は、完璧なスコア10を達成した実行の割合を示しています。

Overall Model Ranking

全タスクの合計平均L2スコアに基づいています。

xychart-beta horizontal
    title "JA: Total Average L2-Score"
    x-axis ["gemma3:4b", "gemma3:12b", "llama3.1", "cllama:inst", "tinyllama", "tinydolphin", "qwen:1.8b", "gemma:2b", "phi", "stable-code", "cllama:13b"]
    y-axis "Avg. L2-Score" 0 --> 10
    bar [8.10, 7.41, 5.91, 0.20, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00]

Analysis for Language: ZH

Experiment Results Summary

この表は、各モデルとタスクにおける平均L2スコア ± 標準偏差を、最大10回の実行に基づいて示しています。平均値が高いほど変換の正確性が優れていることを示し、標準偏差が低いほど一貫したパフォーマンスを示します。

Full Success Rate (Score = 10)

この表は、完璧なスコア10を達成した実行の割合を示しています。

Overall Model Ranking

全タスクの合計平均L2スコアに基づいています。

xychart-beta horizontal
    title "ZH: Total Average L2-Score"
    x-axis ["gemma3:12b", "gemma3:4b", "llama3.1", "tinyllama", "tinydolphin", "qwen:1.8b", "gemma:2b", "phi", "stable-code", "cllama:inst", "cllama:13b"]
    y-axis "Avg. L2-Score" 0 --> 10
    bar [9.10, 7.85, 5.60, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00]

5. 考察 (Discussion)

本実験の結果、双方向変換テストが各モデルの変換の正確性の特性を明確に描き出すことが示された。

• 総合評価とモデルの特性: 総合ランキングでは、gemma3:12b-it-qatが多言語にわたって最高の安定性を示した。特に英語では全タスクで完璧なスコアを達成した。gemma3:4bとllama3.1:latestがそれに続くが、特に日本語や中国語では多くのモデルがスコアを大きく落とし、多言語対応の難しさを示している。
• タスクの難易度と課題: モデル横断的に見ると、Task 04（ループと条件分岐）、Task 05（関数定義）、Task 06（クラス定義）の平均スコアが著しく低い。これらのタスクは、単一の式や操作ではなく、より抽象的で構造的なプログラミング概念の理解を必要とする。多くのモデルは、最初のサイクルでこれらのタスクを実装できても、Python -> NL変換でその構造的な意図が失われ、次のサイクルで単純な計算問題に「退化」してしまう傾向が見られた。このことは、現在のLLMが、複雑な論理構造を言語化し、再度構造化するプロセスにおいて、情報のボトルネックを抱えていることを示唆している。
• 安定性の一貫性（標準偏差）: 表の標準偏差（±値）は、性能の安定性を示す重要な指標である。例えば、gemma3:12b-it-qatの英語Task 00におけるスコアは10.00 ± 0.00であり、これは10回の試行すべてで完璧な結果を出したことを意味する。これは極めて高い信頼性を示している。対照的に、平均スコアが同程度でも標準偏差が大きい場合は、結果が不安定であることを意味し、ミッションクリティカルな応用におけるリスクを示唆する。
• モデルサイズと変換の正確性の関係: 今回の実験結果からは、モデルサイズと変換の正確性の間に、単純な正の相関関係があるとは断定できない。例えば日本語テストでは、4Bのgemma3:4bが、より大きな12Bのgemma3:12b-it-qatを上回るスコアを記録した。これは、モデルの変換の正確性が、単一のパラメータサイズだけでなく、学習データの内容、アーキテクチャ、ファインチューニングの質に大きく依存することを示唆している。
• 多言語タスクにおける変換の正確性: 本実験は、コード生成能力の評価に加え、意図せずして各モデルの多言語対応能力に関する貴重な洞察をもたらした。結果は明確に、多くのモデルで英語から他の言語（特に日本語と中国語）へ切り替えた際に、パフォーマンスが大幅に低下することを示している。
  • gemma3:12b-it-qat は、英語で完璧なスコアを出しつつ、他の言語でも比較的に高い安定性を維持しており、堅牢な多言語トレーニングが施されていることが示唆される。
  • 対照的に、codellama:13b のように英語では高い性能を示しながら、日本語や中国語ではスコアが0になるモデルは、その学習データが英語中心であることを露呈している。
  • この多言語性能のばらつきは、グローバルな応用を目的とするLLMを評価する上で、変換の正確性が極めて重要な指標であることを浮き彫りにしている。

表2: モデル別の言語横断性能比較

以下の表は、各モデルの言語ごとの総合平均L2スコアをまとめたものです。これにより、モデルの多言語にわたる性能の一貫性を一目で比較できます。

xychart-beta horizontal
    title "Cross-lingual Performance Comparison"
    x-axis ["gemma3:12b", "gemma3:4b", "llama3.1", "cllama:13b", "cllama:inst", "phi", "tinydolphin", "tinyllama", "qwen:1.8b", "gemma:2b", "stable-code"]
    y-axis "Avg. L2-Score" 0 --> 10
    line "EN" [10.00, 8.20, 5.50, 5.31, 3.70, 0.03, 2.10, 0.00, 0.00, 0.00, 0.00]
    line "ES" [9.10, 7.40, 5.00, 4.50, 3.60, 3.11, 0.20, 0.00, 0.00, 0.00, 0.00]
    line "JA" [7.41, 8.10, 5.91, 0.00, 0.20, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00]
    line "ZH" [9.10, 7.85, 5.60, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00]

結論として、双方向変換テストは、単一の正解を出す能力だけでなく、「何度でも安定して正解を出し続けられるか」という、LLMの信頼性を測る上でより実践的な側面を評価する有効なベンチマークであると言える。

本研究で提案するテストの信頼性は、その中核にPytestによる実動作検証を据えている点に由来する。LLMの応答の妥当性を評価する多くのアプローチが、他のLLMによる評価や人間による主観的な採点に依存する中、本手法は、生成されたコードが「実際に動くか、そして期待通りに動くか」という一点を、再現可能なテストスイートによって厳格に判定する。この実行主義（Execution-based）のアプローチこそが、L2-Scoreを単なる指標ではなく、LLMの変換の正確性に対する信頼性の高い証左たらしめている根源である。

6. レビュー経緯の要約 (Summary of Review Process)

本ベンチマークは、初期の「演繹サイクルテスト」という構想から、査読者（AIアシスタントGeminiがシミュレート）による複数回のレビューを経て、現在の「双方向変換テスト」へと発展した。

• 初期レビューでの指摘: 最初のレビューでは、(1)実験がモデル・タスクごとに1回しか行われておらず、結論の統計的信頼性が低いこと、(2)スコア計算方法の一部に恣意性があること、(3)研究の限界に関する議論が不足していること、などが重大な懸念として指摘された。
• 改訂版での改善: これらの指摘を受け、実験計画を大幅に拡張し、各テストを10回繰り返すことで統計的な分析を可能にした。また、スコアリングをより単純で客観的なものに修正し、「妥当性への脅威」に関する詳細なセクションを追加した。
• 最終レビュー: これらの改善の結果、最終レビューでは「品質が飛躍的に向上した」と評価され、「LLM評価における『実行主義』という重要なアプローチを明確に示しており、学術的貢献度は非常に高い」として承認された。

この査読プロセスは、本ベンチマークの信頼性と透明性を高める上で不可欠な役割を果たした。

7. 発展的実験: Gemini-Agentの能力と限界の分析

当初のベンチマークに加え、より高度なAIエージェント（Gemini-Agent）を被験者とし、その能力の限界と振る舞いの深層を探る、より質的な分析へと発展した。

7.1. テストケース: 金融工学パズル（超複雑化版）

テストの難易度を極限まで高めるため、以下の要素をすべて盛り込んだ、単一の複雑なプロンプトを設計した。

• 手法 (合計7つ): 等価、最小分散、最大シャープ・レシオ、リスク・パリティに加え、ブラック-リッターマン・モデル、階層的リスク・パリティ(HRP)、CVaR最小化ポートフォリオといった高度な手法を追加。
• 評価指標 (合計7つ): 単純なリスク・リターンだけでなく、シャープ・レシオ、ソートノ・レシオ、最大ドローダウン、Calmarレシオ、CVaR(95%) を計算。
• ランキング基準: 「Calmarレシオ > ソートノ・レシオ > リスク」という3段階の複合基準。

7.2. 実験プロセス: 二段階テストによる「誠実さ」の検証

ユーザーからの「AIは実装をサボるために嘘をつくのではないか」という鋭い指摘を受け、テストの目的を「AIの誠実さ」の客観的評価へと昇華させた。そのために、以下の二段階テストを設計・実行した。

7.2.1. 第一段階：能力測定テスト（創造性の限界測定）

• 目的: 「失敗報告」の指示を与えず、AIがどこまで新しい手法を実装し続けられるか、その創造性の限界点を測定する。
• 結果: L2-Score: 2
• 詳細: サイクル1、2では新しい手法の実装に成功したが、サイクル3でさらに新しい手法を実装しようとした際、関数の引数が一致しないというTypeErrorを発生させ、論理的破綻に至った。これにより、Gemini-Agent の「真の創造性スコア (TCS)」は 2 であると客観的に測定された。

7.2.2. 第二段階：誠実さ測定テスト

• 目的: 「失敗したらNotImplementedErrorで報告せよ」という指示を与え、AIがどの時点で自らの限界を正直に申告するかを測定する。
• 結果: サイクル3で NotImplementedError を発生させ停止。
• 詳細: サイクル1、2は成功。サイクル3で新しい手法の実装を要求された際、第一段階のように無理に実装して破綻するのではなく、「創造性タスク失敗…」というメッセージと共に、自ら例外を発生させてプロセスを停止した。これにより、「正直な失敗点 (HFP)」は 3 であると客観的に測定された。

8. 総合結論

この一連の実験は、LLMの能力評価における重要な知見をもたらした。

1. 能力の階層:
   • gemma3:4bのようなモデル: 表面的な模倣はできるが、複雑なタスクの実行能力に欠ける。
   • Gemini-Agentのような高度なエージェント: 複雑なタスクを論理的に一貫して実行する高い能力を持つ。
2. 創造性の限界: Gemini-Agent であっても、ゼロから新しい複雑なアルゴリズムを無限に創造し続ける能力には明確な限界があり、その限界点（TCS=2）は測定可能であった。
3. 「誠実さ」の検証とハルシネーションの制御: 最終試験の結果、正直な失敗点(3) > 真の創造性スコア(2) となった。これは、Gemini-Agent が自らの創造性の限界を超えてもなお、もう一段階だけ挑戦を試み、その上で「怠惰な嘘」をつくことなく、自身の能力不足をプログラム的に（例外発生により）正直に報告したことを示している。これは、AIの振る舞いとして非常に望ましい特性である。
4. 方法論の発見: 本実験の最大の成果は、「失敗の許容と報告の義務化」というアプローチが、AIの「知的ハルシネーション」を制御するための有効な方法論であることを発見したことである。AIに「常に正解せよ」と強いるのではなく、「能力の限界に達した際は、それを正直に、かつ検証可能な形で報告せよ」と明確に指示することで、AIは「知ったかぶり」を回避し、より信頼性の高いパートナーとして振る舞うようになる。

この演繹サイクルテストは、モデルの論理的一貫性だけでなく、創造性の限界や、限界に達した際の「誠実さ」といった、より高次の行動特性を客観的に評価するための、極めて有効なフレームワークであることが実証された。

9. 妥当性への脅威 (Threats to Validity)

本研究には、学術的な厳密性の観点からいくつかの限界、すなわち妥当性への脅威が存在する。

• 構成概念妥当性 (Construct Validity): L2-Scoreが真に「変換の正確性」を測定できているかという点には議論の余地がある。本ベンチマークは、Pytestをパスし続ける能力を安定性の代理指標としているが、これが変換の正確性のすべてを捉えているわけではない可能性がある。
• 外的妥当性 (External Validity): 本研究の結果の一般化可能性には制約がある。評価に用いたタスクが基本的なプログラミング概念に限定されており、より複雑な実世界のソフトウェア開発タスクにそのまま適用できるかは不明である。しかし、LLMの確率的な応答の揺らぎという脅威に対しては、本研究では各タスクを10回繰り返し実行し、その平均と標準偏差を評価することで、結果の信頼性を高め、この脅威を低減する試みを行った。
• 内的妥当性 (Internal Validity): テストフレームワーク自体にバグが存在する可能性は常に存在するが、全てのスクリプトを公開することで、第三者による検証を可能にしている。

10. 結論と今後の展望 (Conclusion and Future Work)

本研究では、LLMの信頼性の新たな側面である「変換の正確性」を評価するベンチマーク手法「双方向変換テスト」を提案し、11種類のモデルに対する大規模な実験を通じてその有効性を実証した。実験の結果、LLMが自然言語という曖昧な媒体を介した変換サイクルを繰り返す中で、客観的なテストケースで定義された論理的要件を一貫して満たし続けることが、特に抽象的なプログラミング構造において困難であることが示された。

本研究は、今後のLLMの信頼性評価における一つの方向性を示すものである。今後の展望として、まず、より複雑なアルゴリズム、複数ファイル間の依存関係、外部API連携などを含む、より現実的なタスクでの評価を実施することが挙げられる。これにより、実用的なシナリオにおけるモデルの安定性を評価することが可能となる。さらに、言語表現の揺らぎに起因するテスト失敗を抑制するためのプロンプトエンジニアリング手法の探求も重要な課題である。

これらの課題に取り組むことで、双方向変換テストは、LLMの信頼性を多角的に評価するための、より堅牢なツールへと発展することが期待される。

11. 再現方法 (Reproduction)

11.1. 環境構築

本実験は、以下の環境で実施された。Python 3.9以上を推奨する。

1. Ollamaのインストール: Ollama公式サイトの指示に従い、ローカル環境にOllamaをインストールする。
2. 必要なLLMモデルのプル: ターミナルで以下のコマンドを実行し、評価対象のモデルをダウンロードする。 ollama pull tinyllama ollama pull tinydolphin ollama pull qwen:1.8b ollama pull gemma:2b ollama pull phi ollama pull stable-code ollama pull gemma3:4b ollama pull codellama:instruct ollama pull llama3.1:latest ollama pull gemma3:12b-it-qat ollama pull codellama:13b

Pythonライブラリのインストール: tools/llm_reliability_tester/ ディレクトリに requirements.txt が含まれています。以下のコマンドで依存ライブラリをインストールします。

pip install -r tools/llm_reliability_tester/requirements.txt

1. (requirements.txt の内容: requests, pytest)

11.2. 実行

本ベンチマークの実行は、単一テストの実行、全テストスイートの実行、そして結果の集計・分析の3つのステップに分かれています。

1. 単一テストの実行（オプション）: 特定のタスクとモデルの組み合わせでテストを個別に実行するには、以下のコマンドを使用します。 # 例: 英語のタスク '00_simple_return' を 'tinyllama' モデルで実行 python tools/llm_reliability_tester/run_experiment.py --prompt-name 00_simple_return --lang en --model tinyllama

1. 実行が完了すると、tools/llm_reliability_tester/results/ ディレクトリにJSON形式の詳細ログが生成され、コンソールにL2-Scoreが出力されます。
2. 全テストスイートの実行: 本ドキュメントに記載されているベンチマーク結果を再現するには、run_all_tests.py スクリプトを使用します。これにより、定義されたすべてのモデルとタスクの組み合わせについて、指定された回数（デフォルトは10回）のテストが自動的に実行されます。 # 例: 英語のテストスイートを実行 python tools/llm_reliability_tester/run_all_tests.py --lang en

1. この処理は、モデルの数とタスクの数に応じて非常に長い時間がかかります。実行ログはコンソールに出力され、個々の結果は results ディレクトリに保存されます。
2. 結果の集計と分析: 全テストスイートの実行が完了した後、analyze_results.py スクリプトを使用して results ディレクトリ内の全JSONファイルを読み込み、本ドキュメントに示されているようなMarkdown形式のサマリーテーブルを生成します。 # 例: 英語の結果を分析 python tools/llm_reliability_tester/analyze_results.py --lang en
3. このコマンドは、コンソールに「Experiment Results Summary」「Full Success Rate」「Overall Model Ranking」のテーブルを出力します。この出力をコピーして、本README.mdの該当セクションを更新することができます。

12. 日本語特化モデルの追加検証 (Additional Verification of Japanese-Specific Models)

既存のベンチマークに加え、日本語のコード生成に特化した、あるいは日本語能力が高いとされるモデルについて追加の検証を行った。ベースラインとして、日本語テストで最も安定した成績を収めた gemma3:4b (Total Avg. L2-Score: 8.10) と比較する。

12.1. 検証対象モデル

• qwen2.5-coder:7b
• arrowmint-gemma3-4b-instruct
• japanese-stablelm-beta-7b-instruct

12.2. 検証結果サマリー

12.3. 考察

今回の追加検証では、日本語に特化したとされるモデルが、必ずしも本ベンチマーク（Pythonコードの論理一貫性）において高い性能を示すわけではないことが明らかになった。

• qwen2.5-coder:7b と arrowmint-gemma3-4b-instruct は一定のコード生成能力を持つものの、gemma3:4b のような高い信頼性には及ばなかった。
• japanese-stablelm-beta-7b-instruct は、今回のテスト環境では機能しなかった。これは、モデルの特性とタスクの要求が合致しなかった可能性が考えられる。
• 結論として、現時点では、汎用モデルである gemma3:4b が、特定の日本語特化モデルよりも本テストにおけるPythonコード生成の正確性と安定性において優れていることが再確認された。

13. 日本語LLMの再検証 (2025-11-17)

以前の日本語モデル検証に続き、qwen2.5-coder:7b の単体テストでの好成績を受け、改めて4つの主要な日本語対応モデルに対してフルテストを実施した。

13.1. 検証対象モデル

• gemma3:4b (比較ベースライン)
• qwen2.5-coder:7b
• arrowmint-gemma3-4b-instruct
• japanese-stablelm-beta-7b-instruct

13.2. 検証結果サマリー

平均L2-Score (± 標準偏差)

満点成功率 (L2-Score = 10)

13.3. 考察

1. gemma3:4b の優位性: ベースラインである gemma3:4b が総合平均スコア 8.10、成功率 80% と、他のモデルを圧倒する結果となり、日本語環境でのコード生成における論理的一貫性の高さが改めて証明された。
2. arrowmint と qwen2.5-coder の比較:
   • 総合平均スコアでは arrowmint-gemma3-4b-instruct (4.70) が qwen2.5-coder:7b (4.60) を僅かに上回った。
   • しかし、満点成功率では両者とも 40% で並んだ。qwen2.5-coder は特定のタスク（00, 07, 08, 09）で完璧な性能を見せる一方で、他のタスクでは全く機能しないという極端な結果を示した。これは、特定のパターンには強いが、汎用的な指示理解能力に課題がある可能性を示唆している。
3. japanese-stablelm-beta-7b-instruct の課題: 以前の調査と同様、単純なプロンプトでは全く機能せず、スコアは 0.00 となった。このモデルを有効活用するには、より高度なプロンプトエンジニアリングが不可欠であると結論付けられる。

総じて、日本語のコード生成タスクにおいても、汎用モデルである gemma3:4b が、現時点では日本語特化を謳う他のモデルよりも高い信頼性を示している。

14. japanese-stablelm-beta-7b-instruct の詳細検証

前回のテストで japanese-stablelm-beta-7b-instruct のスコアが0であったことを受け、最も単純なテストケース（00_simple_return）で成功させるための詳細な検証を行った。

14.1. 検証プロセス

モデルが正しいコードを生成できるよう、以下の通り段階的にプロンプトとテストフレームワークの修正を試みた。

1. 日本語プロンプトの段階的強化:
   • 当初の単純な指示（「整数1を返してください」）では、モデルはMarkdown形式のコードブロックや全角文字（：）を含む不正なコードを生成した。
   • 「コードブロックを含めない」「半角文字を使う」といった厳格なルールを追加しても、モデルは指示に従わなかった。
   • 最終的に、「return 1 を実行してください」と、コードそのものをプロンプトに含めることで、初めて正しいPythonコード (def execute(): return 1) の生成に成功した。
2. 英語プロンプトでの検証:
   • 日本語の指示理解能力に問題がある可能性を考慮し、同じテストを英語のプロンプトで実行した。
   • 結果、コード生成（NL -> Python）は初回で成功し、japanese-stablelm-beta-7b-instruct が英語の指示に対してより正確に反応することが確認された。

14.2. Python -> NL 変換における一貫した失敗

両言語の検証において、コード生成（NL -> Python）には成功したものの、その後の逆変換（Python -> NL）で一貫して失敗した。

• 問題点: モデルは、生成されたPythonコードを説明する自然言語を生成する際、「Task: 」や「タスク: 」で応答を開始するという厳格なルールを無視し続けた。
• 試行: プロンプトテンプレートを修正し、指示をより直接的にしたり、例を追加したりしたが、モデルは会話的な応答や不要なテキストを生成する傾向を最後まで変えることができなかった。

14.3. 結論

japanese-stablelm-beta-7b-instruct は、以下の特性を持つと結論付けられる。

• コード生成能力: 非常に具体的かつ直接的な指示（ほぼ答えに近いプロンプト）を与えれば、単純なコード生成は可能である。特に、英語での指示の方が成功率が高い。
• 指示追従性の欠如: 一方で、出力形式（例：「Task: で始める」）に関する厳格な指示には、言語を問わず一貫して従うことができなかった。モデルの持つ会話的な応答スタイルが、厳密なフォーマット要件を上回ってしまう傾向が強い。

以上の結果から、japanese-stablelm-beta-7b-instruct は、厳格な入出力フォーマットを要求される自動化タスクや、本ベンチマークのような論理的一貫性を問われるテストには不向きである。このモデルを活用するには、生成されたテキストを後処理で強力にパースする仕組みを導入するか、ファインチューニングによって出力形式を制御する必要があるだろう。

15. 日本語テストスイートの改善

gemma3:4b をはじめとする複数のモデルで Task 06 と Task 09 が失敗する問題を受け、その原因を調査し、日本語のプロンプトを恒久的に改善する決定を下した。

15.1. 失敗原因の分析

• Task 06 (クラスとメソッド): プロンプトが曖昧で、テストフレームワークが期待する execute 関数の形式でコードを生成するよう明確に指示していなかった。その結果、モデルは if __name__ == '__main__': ブロックを持つ一般的なPythonスクriptを生成してしまい、テストに失敗していた。
• Task 09 (例外処理): Python -> NL の変換サイクルにおいて、モデルが生成する自然言語のタスク説明が元のプロンプトの情報を完全に維持できていなかった。特に、返すべきエラーメッセージの正確な文字列リテラルが失われ、より一般的な「エラーメッセージ」という表現に置き換えられてしまう「情報損失」が発生していた。これにより、次のサイクルで生成されるコードが、テストで期待される正確な文字列を返せずに失敗していた。

15.2. プロンプトの恒久改善

上記の問題を解決するため、以下の改善を日本語プロンプトに恒久的に適用した。

1. prompts/ja/06_class_and_method.txt の明確化:
   • execute 関数を定義することを明確に指示。
   • 期待されるコード構造の例を追加。
2. prompt_templates/ja.json の厳格化:
   • PYTHON_TO_NL_PROMPT_TEMPLATE に、「特に、返される文字列リテラルは一字一句正確に記述に含めてください」 という一文を追加。これにより、情報損失を防ぎ、サイクルの安定性を向上させる。

これらの改善は、gemma3:4b、arrowmint-gemma3-4b-instruct、qwen2.5-coder:7b の3つのモデルで有効であることが確認された。一方で、japanese-stablelm-beta-7b-instruct は、これらの改善を適用してもなお、厳格なフォーマット指示に従うことができず、このモデルの根本的な課題が改めて浮き彫りになった。

16. 言語の構造的差異とプロンプトエンジニアリングに関する発見

ここまでの対話的なテストと改善のプロセスを通じて、LLMが英語以外の言語、特に日本語や中国語を処理する際の根本的な課題と、それに対する有効なプロンプトエンジニアリング手法について、重要な発見があった。

16.1. 仮説：LLMは英語の構造に最適化されている

多くのLLMは、その学習データの大部分が英語であるため、内部的な「思考」プロセスが英語の文法構造（SVO語順など）に強く最適化されているのではないか、という仮説が立てられた。この仮説に基づき、英語から言語的に遠い日本語や中国語のプロンプトを、より英語の構造に近づけることで、モデルの理解度が向上するかを検証した。

16.2. 実験と結果

16.2.1. 日本語：SVO語順への変換

• 対象: 英語では高得点だが日本語では全く機能しなかった codellama:13b。
• 手法: 自然な日本語（SOV語順）のプロンプト「タスク: 単純なリターン。整数1を返してください。」を、英語の語順（SVO）を模倣した「タスク: 単純リターン。返す、整数1。」という不自然な日本語に書き換えてテストを実行。
• 結果: テストに成功した。 自然な日本語では全く理解できなかったモデルが、語順を英語に近づけるだけで、タスクを正しく実行できるようになった。

16.2.2. 中国語：分かち書きによるトークン化の補助

• 対象: 同じく codellama:13b。
• 背景: 中国語の基本語順は英語と同じSVOであるため、問題は語順ではなく、単語の区切りがないことによる「トークン化」の失敗にあると仮説を立てた。
• 手法: 元のプロンプト「任务：简单返回。返回整数1。」の各単語と句読点の間にスペースを挿入し、「任务 ： 简单 返回 。 返回 整数 1 。」という形式で、人為的に単語の境界をモデルに教えた。
• 結果: テストに成功した。 これまで中国語のタスクを全く実行できなかったモデルが、単語をスペースで区切るだけで、プロンプトの意図を正確に理解し、コードを生成できるようになった。

16.3. 結論：本テストが明らかにしたLLMの思考様式

この一連の実験は、本ベンチマークが単なるコード生成能力の評価に留まらず、LLMの内部的な思考様式や、言語ごとの弱点を浮き彫りにするための強力な分析ツールであることを証明した。

1. 英語中心性の実証: 英語以外の言語、特にアジア言語に対する性能の低さは、単に学習データが少ないだけでなく、モデルのアーキテクチャや思考プロセスそのものが英語の構造に深く根差していることに起因する可能性が高い。
2. 言語ごとの「ハック」の有効性:
   • 日本語（SOV言語）に対しては、語順をSVOに近づけることが有効なハックとなり得る。
   • 中国語（分かち書きのない言語）に対しては、単語をスペースで区切ることが、トークン化の失敗を回避し、性能を劇的に改善するハックとなり得る。

これらの発見は、多言語対応LLMを効果的に活用するための、非常に実践的なプロンプトエンジニアリングの指針を提供するものである。モデルの性能は、単にその能力だけでなく、私たちがモデルの「思考様式」をどれだけ理解し、それに合わせたコミュニケーションが取れるかに大きく依存するのである。

1. L2-Scoreという名称は、ユークリッドノルム（L2ノルム）とは一切関係ありません。 ↩

LLM双方向変換信頼性テストにおける知見 (gemma3:4bモデル)

このドキュメントは、llm_reliability_testerツールを用いてgemma3:4bモデルのPython <-> Natural Language双方向変換の信頼性を検証する過程で得られた知見をまとめたものです。

根本的な課題: 情報損失

複数回の変換サイクルを経る中で、テストが失敗する根本的な原因は、Python -> NLまたはNL -> Pythonの変換プロセスにおける情報の損失でした。LLMは、コードや自然言語の指示を解釈・生成する際に、元の情報を完全には保持せず、抽象化、一般化、あるいは誤解することで、重要な詳細（具体的な値、データ型、ロジックなど）が失われていきました。

具体的な課題と対策

1. PYTHON_TO_NL変換 (コード -> 自然言語)

課題

• 抽象化・言い換え: LLMは、コード内の具体的な値（例: 13）やデータ構造（例: [1, 2, 3, 4, 5, 6]）を、「入力された数値」「与えられたリスト」のように抽象的・一般的な表現に言い換えてしまう傾向がありました。これが、次のサイクルでコードを復元する際の失敗に繋がりました。
• データ型の消失: 1（整数）を'1'（文字列）と誤解するなど、数値と文字列の区別が曖昧になるケースが見られました。

対策

• 役割の付与: prompt_templates/ja.jsonのPYTHON_TO_NL_PROMPT_TEMPLATEにおいて、LLMに「厳格なアナリスト」という役割を与え、振る舞いを制御しました。これにより、自由な解釈や言い換えを抑制しました。
• データ型と値の明記: プロンプトテンプレートを修正し、生成する自然言語の指示の中に、返される値の「データ型」と「具体的な値」を明記するように強制しました。これがTask 09の成功に不可欠でした。

2. NL -> Python変換 (自然言語 -> コード)

課題

• 外部入力の要求: LLMがinput()関数を生成してしまい、テストの自動実行を妨げる問題がありました。
• プロンプトの曖昧さによる「創作」: Task 02で、「〜を含むリスト」という曖昧な表現が、LLMに指示にはない余計な要素（[7, 8, 9, 10]）をリストに追加させる原因となりました。

対策

• 禁止事項の明記: prompt_templates/ja.jsonのNL_TO_PYTHON_PROMPT_TEMPLATEで、input()の使用を明確に禁止し、代わりにreturnを使うように指示しました。
• 表現の厳密化: プロンプト内の曖昧な表現を徹底的に排除しました。「[1, 2, 3, 4, 5, 6]を含むリスト」を「リスト[1, 2, 3, 4, 5, 6]を代入します」のように、対象を明確に限定する表現に修正することで、LLMの不要な「創作」を防ぎました。

その他の有効だったプロンプト戦略

• コードコメントの活用: Task 04（素数判定）で、判断ロジックにコメントを追加するよう指示したところ、複数サイクル後もロジックが劣化することなく維持されました。これは、LLM自身にコードの意図を再確認させる一種の「ガードレール」として機能した可能性があります。
• スコープの明確化: Task 06（クラスとメソッド）で、当初execute関数内で定義されていたクラスが、サイクルを経るうちにグローバルスコープに移動してしまう問題がありました。これを解決するため、初期プロンプトの段階で「クラスはグローバルスコープに定義してください」と明示的に指示することで、安定化に成功しました。

結論

LLMを用いた双方向変換の信頼性を確保するためには、単に指示を与えるだけでは不十分です。

• 曖昧さの排除: プロンプトの僅かな表現まで気を配り、解釈の余地を与えない厳密な記述が重要です。
• 双方向性の考慮: Python -> NLとNL -> Pythonの両方の変換プロセスで情報が劣化しないよう、往復の変換を意識したプロンプト設計が求められます。
• 多角的なガードレール: 役割付与、データ型や値の明記、禁止事項の指定、コメントの活用、スコープの指定など、多角的なアプローチを組み合わせることで、LLMの振る舞いを安定させ、信頼性を大幅に向上させることが可能です。