← 2026-03-20 の一覧へ戻るホーム
**EsoLang‑Bench：エソテリック言語でLLMの真正な推論力を評価する**

2026/03/20 6:01

**EsoLang‑Bench：エソテリック言語でLLMの真正な推論力を評価する**

RSS: https://news.ycombinator.com/rss

元のHacker News記事へ ↗
要約▶

Japanese Translation:

Summary

EsoLang‑Benchは、Brainfuck、Befunge‑98、Whitespace、Unlambda、および Shakespeare の5つのエソテリック言語にわたる80のプログラミング問題で大規模言語モデル（LLM）を評価します。Python に比べてトレーニングデータは 5 000〜100 000 倍稀少です。5つの最先端 LLM と5つのプロンプティング戦略、2つのエージェンシー型コーディングシステムをテストした結果、全体的な正答率は 3.8 % にとどまりました。一方で同じモデルが等価の Python タスクで約 90 % のスコアを達成します。

すべてのモデルは Easy 階層以上（Medium、Hard、Extra‑Hard）の問題で失敗し、各言語においてそれらのレベルで 0 % の正答率となります。Whitespace は可視化されない構文のため、どんな設定でも 0 % の精度で完全に未解決です。エソテリック言語の中では Befunge‑98 が最高単一言語スコア 11.2 % を達成し、おそらくそのスタックベースの 2D グリッドパラダイムが原因と考えられます。

エラー解析によると、Brainfuck の失敗の 83.9 % は論理エラー（構文的には有効だが出力が不正）であり、Unlambda は 74.6 % がコンパイルエラー、Befunge‑98 は 93.4 % が実行時問題（無限ループなど）です。

Few‑shot プロンプティングは zero‑shot より精度を向上させず（Wilcoxon p = 0.505）、コンテキスト内学習がエソテリックタスクに対して非効果的であることを示しています。批評家や計画者を追加するとノイズが増え、現在のモデルは有効な多代理アプローチのためのドメイン知識を欠いていると明らかになります。

Codex や Claude Code のようなツール拡張型エージェントは、実行フィードバックループを統合することでプロンプトのみの方法に比べて約 倍の精度 を達成し、将来の LLM がエソテリックプログラミング課題で良好な性能を発揮するには、より緊密なインタープリター統合が不可欠であることを示唆しています。

これらの結果は、主流言語モデルと実際のプログラミング能力との間に劇的なギャップが存在し、開発者、AI コーディングプラットフォーム、および自動コード生成に依存する産業に対して制限を強調しています。

本文

EsoLang‑Bench

大規模言語モデルにおける真の推論力をエソテリックプログラミング言語で評価する

要旨

現在、大規模言語モデル（LLM）のコード生成性能を測定するベンチマークは主にPythonなどの主流言語を対象としています。これらのモデルは膨大な事前学習コーパスから恩恵を受けるため、実際にはデータの暗記によって高い精度が得られることがあります。このような現象を踏まえ、我々は EsoLang‑Bench を提案します。これは Brainfuck、Befunge‑98、Whitespace、Unlambda、Shakespeare の5つのエソテリック言語に対して80問ずつ（合計400問）のプログラミング問題を用意し、Python と比べて学習データが 5 000〜100 000 倍ほど希少な環境でモデルを評価します。

5 つの最先端モデルを 5 種類のプロンプト戦略と 2 つのエージェント型コーディングシステムで検証しました。最高性能のモデルは 全体精度わずか 3.8 % に留まり、同等の Python タスクでは約 90 % という高いスコアと比べて劇的に低いことが判明します。すべてのモデルは Easy 階層以上の問題で 0 % の精度を示し、Whitespace はすべての構成で完全に解決できませんでした（0 %）。自己反省機能もほぼ効果がありませんでした。これらの結果は、主流言語でのベンチマーク性能と実際のプログラミング能力との間に大きなギャップがあることを示し、現在の LLM コード生成能力は見かけ上の指標よりも遥かに狭い範囲に留まっていることを示唆しています。

説明動画

ご利用中のブラウザは video タグをサポートしていません。

リーダーボード

モデルAPIエージェント型
各言語でのプロンプト戦略別最高スコア。80 問/言語、テストケース 6 件ずつ。

主な発見

  1. 85 点以上の性能ギャップ
    標準ベンチマークで 85–95 % を達成する最先端モデルは、同等のエソテリックタスクでは 0–11 % にしか落ち込みません。主流言語で高得点を示すことが、一般的なプログラミング能力を反映しているわけではないと明らかです。

  2. Easy 階層以降は 0 %
    すべてのモデルが Medium、Hard、Extra‑Hard の問題で 0 % を記録し、最も簡単なタスクを超える推論能力に大きな上限があることを示しています。

  3. Whitespace は完全未解決
    どの構成でも Whitespace コードを正しく生成できません。可視化されない構文（空白・タブ・改行のみ）は訓練データから学習できず、事前学習に含める価値が経済的には低いというパラダイムが示唆されています。

  4. インコンテキスト学習は失敗
    Few‑shot プロンプトはゼロショットと比べて有意な改善をもたらさず（Wilcoxon p = 0.505）、標準ベンチマークでの ICL 成功は訓練済み優先度の活性化に過ぎないことが示唆されます。

  5. 自己スキャフォールディングが支配
    1 回の LLM 呼び出し／イテレーションでインタープリターからのエラーメッセージを直接フィードバックする方法が、マルチエージェント手法よりも一貫して優れた結果を示します。クリティックやプランナー（ReAct）を追加しても測定可能なメリットは得られず、ノイズしか生み出しません。

  6. 2 倍のエージェント利点
    ツール補完型エージェント（Codex, Claude Code）は実行フィードバックループによりプロンプトのみのアプローチと比べて約 2 倍の精度を達成します。訓練データが希少な状況で部分的に代替できることを示しています。

結果と分析

  • 性能崖
    エソテリック言語（訓練データが 5 000–100 000 倍希少）では、最先端モデルは約 90 % の精度から単桁に落ち込みます。Befunge‑98 が最高で 11.2 % を記録し、その 2D グリッド構造がスタックベース言語と部分的に共通している点が影響しています。一方、Whitespace はすべてのモデル・戦略で 0 % のままです。

  • 戦略比較
    インタープリターから直接エラーメッセージを受け取り、反復的に改良する自己スキャフォールディングが最も優れた結果を示します。クリティック（テキストベースの自己スキャフォールディング）やプランナー（ReAct）を追加しても有意な効果はなく、むしろノイズが増加します。これはエソテリックコードに対する自己反省機能が現在のモデルでは不十分であることを示唆しています。

  • 誤差分析
    各言語で独自の失敗パターンが観察されます：
    Brainfuck – 83.9 % が論理エラー（構文は正しいが出力が間違い）
    Unlambda – 74.6 % がコンパイルエラー（有効な組合算子式を生成できない）
    Befunge‑98 – 93.4 % がランタイムエラー（2D 実行モデルで無限ループに陥る）
    Shakespeare – 59.2 % がランタイムエラー（演劇的構文は認識できても対話意味が誤っている）

  • エージェント型システム
    実際のインタープリターをツールとして利用する Codex や Claude Code は、プロンプトのみのアプローチと比べて約 2 倍の精度を達成します。Codex は Brainfuck で最高 13.8 % を記録し、ツールによる実行フィードバックが希少な訓練データを部分的に補完できることを示しています。しかし、ツールアクセスがある場合でも精度は主流言語レベルには遠く及びません。

対応言語

5 つのエソテリック言語は、テープベース、関数型、自然言語風など多様なパラダイムを網羅しています。

BibTeX

@article{sharma2026esolangbench,
  title        = {{EsoLang-Bench}: Evaluating Genuine Reasoning in Large Language Models via Esoteric Programming Languages},
  author       = {Sharma, Aman and Chopra, Paras},
  journal      = {arXiv preprint arXiv:2603.09678},
  year         = {2026},
  eprint       = {2603.09678},
  archivePrefix= {arXiv},
  primaryClass = {cs.LG},
  url          = {https://arxiv.org/abs/2603.09678}
}

同じ日のほかのニュース

一覧に戻る →

2026/03/20 5:33

コックピットは、サーバー用のウェブベースのグラフィカルインターフェイスです。

## Japanese Translation: **Cockpit** は、Linux 管理者がオペレーティングシステムから直接サーバーを管理できる軽量でブラウザベースのインターフェイスです。OS 内で動作し、Debian、Fedora、および RHEL など主要なディストリビューションに対応しており、コンテナの起動、ストレージやネットワークの設定、ログの確認、ブラウザを離れずにターミナルとグラフィカルコントロール間で切替えなどが可能です。 ユーザーは Cockpit からでも従来のシェルからでもサービスをシームレスに開始・停止でき、端末で発生したエラーは自動的に Cockpit のジャーナルインターフェイスに表示されます。 プロジェクトはリモート管理もサポートしており、ユーザーは SSH 経由で Cockpit がインストールされた他のマシンを追加・管理できるため、ホスト切替が簡単です。コミュニティサポートは Matrix チャネル（#cockpit:fedoraproject.org）とメールリストで提供されます。ドキュメントにはツールの使い方だけでなくコードベースへの貢献方法も網羅しており、ガイディングプリンシプル、リリースノート、およびプライバシーポリシーが含まれています。 複数の Linux ディストリビューションにわたる統一で使いやすい GUI を提供することで、Cockpit はサーバー管理を効率化し、ドキュメントと活発なコミュニケーションチャネルを通じて継続的な開発者貢献を促進することを目指しています。

2026/03/19 22:05

**Astral が OpenAI に参入**

## Japanese Translation: **（欠落していた詳細を補完）** ### 要約 Astral は、オープンソースの Python ツールを存続させつつ OpenAI の Codex チームに参加することに合意し、そのツールチェーンをモダンな Python 開発の中心に位置付けました。この取引は Astral の創業者が発表し、Python エコシステムの生産性を少なくとも 1 % 向上させる高レバレッジ戦略を強調しています。Ruff（高速リンター）、uv（依存関係解決ツール）、ty といった人気ツールへの継続的なサポートが含まれ、これらを Codex の AI コーディングアシスタントに統合する計画です。Astral のツールチェーンはゼロから数億件の月間ダウンロードへと成長し、Accel が主導した Casey Aylward 氏によるシード資金調達と Andreessen Horowitz が牽引した Jennifer Li 氏によるシリーズ B 資金調達で支えられています。創業者は Astral チームのユーザー重視の製品品質に感謝し、今後も高い基準を維持するとともに、ユーザーの信頼への感謝を表明しました。買収後、Astral はオープンソース提供物の開発を継続し、それらを Codex と統合し、ソフトウェアエンジニアリングにおける影響力を拡大します。これにより、開発者・企業・広範なエコシステムは、生産性を加速させる AI 強化型の堅牢な Python ユーティリティ―基盤となるツールセット―を享受できます。

2026/03/20 2:16

Google、未認証Androidアプリをサイドロードするための新しい24時間プロセスを発表

## Japanese Translation: Googleは2025年後半にAndroid向けの開発者認証プログラムを開始し、開発者が認証されていない場合はサイドロードされたアプリをブロックすることでマルウェアリスクを低減することを目指します。開発者は本人確認書類を提出し、アプリ署名キーをアップロードし、25ドルの手数料を支払う必要があります。 ユーザーは「未認証パッケージを許可」オプションを有効にして認証を回避できます。設定方法は、ビルド番号を7回タップして開発者向けオプションを解除し、スイッチを切り替えてPIN/パスワードで確認し、デバイスを再起動します。その後24時間待ち、次に「一時的に許可」または「無期限に許可」を選択します。24時間の遅延は、高度なソーシャルエンジニアリング攻撃を抑止するためです。 Googleは非Playソースからマルウェアに遭遇する確率が約50倍高いと引用し、このプログラムでそのリスクを低減すると主張しています。検証機能はすでにAndroid 16.1（2025年後半にリリース）に組み込まれており、全てのサポート対象デバイスで利用可能です。実施開始はブラジル、シンガポール、インドネシア、タイで2025年9月から行われ、2026年には世界中へ展開されます。 このプログラムは手数料などのハードルを追加するため、制裁対象国の開発者にとって不利になる可能性がありますが、Googleはその方針がそのような開発者を排除することを意図していないとし、検証済み開発者リストを非永続化に保ち法的課題を回避すると述べています。プライバシー擁護派は検証済み開発者のデータベースについて懸念を示し続けています。

**EsoLang‑Bench：エソテリック言語でLLMの真正な推論力を評価する** | そっか～ニュース