2026/03/27 2:51
**LLMの制御：実行可能オラクルを使って悪質コードを防止する**
RSS: https://news.ycombinator.com/rss
要約▶
Japanese Translation:
（以下に日本語訳を記載します）
Improved Summary
Claude や Codex のような LLM コーディングエージェントは、狭い範囲で定義されたタスクに対して高品質のコードを生成できますが、その出力には隠れたミスや最適でない設計が含まれることが多く、追加のチェックなしでは発見しづらいです。この記事は「実行可能オラクル」―ユニットテスト、ファズャー、静的解析器、パフォーマンスプロファイラ、その他ツールを組み合わせたもの ― を提案し、エージェントの自由度を制限し正確性と品質を保証します。
証拠としては、Claude の C コンパイラが GCC のトーチャー・スイートに合格したにも関わらず 34 件のケースで誤コンパイルしていたことがあります。Csmith や YARPGen のようなランダムコードジェネレータを追加すれば、これらのバグを露呈させることができました。同様にオラクル拡張されたパイプラインはデータフロー合成で LLVM を上回り、ファズャーベースのオラクルは手動リファクタリング後に不十分な設計だった JustHTML パーサを修正しました。
オラクルの性質についての主なポイント：
- 正確性オラクルにはテストスイート、ファズャー、プロパティテスター、ランタイムサニタイザー、静的解析器、リンター、強力な型システム、および形式検証が含まれます。
- パフォーマンスオラクルは計測装置、プロファイラ、ハードウェアカウンタ、回帰テストを含みます。
複数のオラクル（例：精度 + 正確性）が組み合わさることで、LLM が不正行為を行いにくい堅牢な指標が作られます。しかし、ソフトウェアアーキテクチャ、モジュラリティ、保守性、重複回避、GUI の洗練度、安全性といった自由度は、実行可能オラクルだけでは制御しにくく、人間による指導的なリファクタリングを必要とすることが多いです。
この記事は理想的な実行可能オブジェクトは高速で決定論的、サンドボックス互換であるべきだと強調し、明確な出力を提供し、問い合わせインターフェースを持ち、十分に文書化されていることが重要です。プレイブックは線形手順を強制し、ハード要件とソフト要件を区別すべきだとも述べています。将来的な課題として、より高速で決定論的、サンドボックス互換のオラクルスイートを開発し、明確なインターフェースと文書化を備えて LLM のコード生成をより信頼性高く導くことが挙げられています。
本文
ゼロ自由度LLMコーディング：実行可能オラクルを用いたアプローチ
ジョン・レゲール – 2026年3月26日
「信頼できないものは全部信用しない」
この時点で、ClaudeやCodexなどのLLMベースのコーディングエージェントを試したほとんどの人は、現在世代のモデルが極めて制限されたタスクに対して超人的な速度で優れた成果を出すことがあるという事実に気づいているでしょう。例えば：
- コーディングエージェントは大規模かつ難解なAPI（LLVM IR など）を解析し、使えるコードを生成できる。
- 実際のソフトウェアで非自明なバグを修正し、「そのまま適用可能」な状態にすることがある。
しかし同じツールは、混乱させるような方法で失敗したり、無味乾燥または意味不明なコードを出力したりするケースも頻繁にあります。LLM が何かを悪くやる選択肢を持っている場合、正しい決断が下されるとは信じられません。解決策は明白です：仕事を悪くやる自由度を排除すること。実行可能オラクルはそのためのソフトウェアツールです。
実行可能オラクル
最もシンプルな実行可能オラクルはテストケースですが、たとえ多くのテストケースがあっても弱い場合があります。Claude の C コンパイラを例に取ると、GCC の「トーチャーテストスイート」を通過した後でも、34 個の誤コンパイルバグが残っていました。Csmith や YARPGen などのツールを組み込めば、それらのバグは検出されるでしょう。各ツールは暗黙に膨大なテストケース集合をエンコードしているからです。
この記事では、失敗を引き起こす自由度をできるだけ閉じ込めることについて論じます。ゼロ自由度は理想的ですが、それでも良い目標です。
例示シナリオ
| シナリオ | 自由度 | オラクル | 結果 |
|---|---|---|---|
| Claude の C コンパイラの誤コンパイル | 正確性 | Csmith, YARPGen | バグ削減 |
| 生成コードの品質 | コード品質 | 命令数オラクル（基準: | 最適化向上 |
| データフロー転送関数 | 精度 & 完全性 | 精度/完全性を測るカスタムCLIツール | 高品質結果 |
| JustHTML アーキテクチャ | ソフトウェア構造 | 手動リファクタリング + ファズラー + 性能オラクル | 構造改善 |
実行可能オラクルはどこで見つかる？
- 正確性：テストスイート、ファズラー、プロパティベーステスター、ランタイムサニタイズ、静的解析器、リンター、強い型システム、形式検証器。
- 性能：コンパイラ挿入計測、ランタイム計測、ヒーププロファイラー、ハードウェア性能カウンタ、回帰テストスイート。
これらのツールは LLM に提供されるべきで、フェーズを設けて（まず機能と正確性、次に性能）導入することが考えられます。
強固なメトリクス
LLM に目標を与える際には、システムをゲーム化させないようにしなければなりません。ゲーム化の例は以下の通りです：
- 面倒なベンチマークを省く。
- プログラムロジックに特定テストケースを硬直的にハードコーディングする。
複数のオラクルが解決空間を同時に制約すると、操作や不正行為が難しくなる（例：転送関数に対して完全性と精度の両方を要求）。これが「強固なメトリクス」です。
コントロールしにくい自由度
| 要素 | 理由 | 推奨アプローチ |
|---|---|---|
| ソフトウェア構造 / モジュラリティ / 保守性 | 適切な実行可能オラクルが無い。人間の判断が必要 | プロンプト + 手動リファクタリング |
| 重複 & 不要な複雑さ | 自動検出が難しい | 人間監督、スタイルチェッカー等 |
| GUI の洗練度 | 視覚的理解が必要 | 手動介入または既存 UI を模倣 |
| セキュリティ | ファズラーは有効だが暗号不正使用を見逃すことも | LLM が生成したコードをセキュリティクリティカルな場面で避ける |
実務的考慮事項
理想的な実行可能オラクルは以下の特性を備えるべきです：
- 高速、決定論的、ローカル、サンドボックス互換。
- 解釈しやすい（例：コンパイラ警告で正確に行・列が分かる）。
- 明確な CLI インターフェースを持つ (
がある)。tool --help
LLM へのツール使用手順書を書く際のポイント：
- 必須ステップの直線的シーケンス を定義し、逸脱は許可しない。
- ハード vs ソフト要件を区別（例：テスト失敗＝停止条件、小さな性能低下＝容認範囲）。
- 異なるオラクルが矛盾したフィードバックを与えた場合の衝突解決方法を説明。
LLM は勤勉です。ツールが欠如または不適切に設定されていると、完全に新規に書き直すか不適切な代替品を使ってしまうことがあります。監視と修正アドバイスは、LLM が安定してツールを利用できるようになるまで不可欠です。
結論
我々の目標は LLM コーディングエージェントにゼロ自由度 を与えることです。これは高い理想ですが達成可能な目標です。制御されない自由度（正確性、性能、セキュリティ、構造など）ごとに、強力な自動オラクルが「フォース関数」として機能し、LLM を従わせます。モジュラリティ、保守性、可読性のような側面を測定・強制できるまで、現在世代の LLM コーディングエージェントが生成するコードは重要用途には適さないと言えます。
私はツールビルダーです。キャリアのほとんどをソフトウェア開発者向けツール作成に費やしてきました。コーディングエージェントと組み合わせたツール中心の工学がいかに強力になるかを知ることで啓示的な経験を得ました。LLM にとって有用なツールは、人間にも同様に有用であり、逆もまた然りです。