2026/02/26 7:17
確定的プログラミングとLLM（大規模言語モデル）
RSS: https://news.ycombinator.com/rss
要約▶
Japanese Translation:
改訂サマリー：
主要メッセージは、大規模言語モデル（LLM）が決定論的な本番コードを書くために頼られるべきではないということです。LLMの確率的な出力は幻覚を起こし、セキュリティやコンプライアンスを損なう可能性があるからです。代わりに、LLMは決定論的な実施ツール（リンター、型システムルール、単体テストなど）を生成するために最適であり、これらのツールは継続的インテグレーションパイプラインに統合できます。これらのツールは誰がコードを書いてもポリシーを強制し、再現可能で安全なデプロイメントを保証します。
証拠として、AI が証明（例：エルドホース問題）を起草したケースや、人間による検証が必要だった事例、および現在のコーディングエージェントがジュニア開発者のように振舞う例があります。自動デプロイメントスクリプトはすでに手作業よりも優れており、入力サニタイズや命名規則など繰り返し行われるタスクでは決定論性が必要であることを強調しています。一度きりのタスク（データ移行、チャート生成）は決定論的な実施を必要としません。
推奨事項は、ポリシーをすべてに適用する必要がある場合には LLM を使って実施プログラムを構築し、単一使用コードについては LLM にドラフトさせた後、人間でレビューするというものです。これらの決定論的チェックを CI パイプラインに埋め込み、LLM がそれらの作成を支援することで、組織は一貫したコンプライアンスを実現しつつ、AI の迅速なプロトタイピング機能から恩恵を受けることができます。
本文
序章
プログラミング系のブログを定期的に読んでいるなら（読まないのであれば、きっとこの記事も読まないでしょう）、業界が劇的な変化の真っ只中にあることはご存知だと思います。現在投稿されているブログ記事の半分以上が、大規模言語モデル（LLM）がコードを書けるようになった今、どのように最適に対応すべきかを議論しています。
本稿では、LLM を「決定的」に活用する方法について考察し、貢献したいと思います。これは唯一のアプローチではありませんが、検討すべき有効な手段の一つです。
数学と LLM の関係
まず自分の業界に入る前に、AI に影響を受けた別の分野―数学―を見てみました。2024年9月にテレンス・タオは、「LLM を監督することは、完全には無能ではない（ただし平均的な）大学院生（静的シミュレーション）の指導に似ている」と述べています。このような学生を人間が模倣できるケースは少なく、LLM は過去一年半で大幅に改善しました。
LLM は数学的証明のようなテキストを生成できますが、幻覚（hallucination）も生じます。証明は微妙な詳細に依存するため、LLM の提示した証明をそのまま正しいと受け入れることは危険です。実際、数学者でも誤りに気付かないことがあります。その結果、多くの数学者が Lean などのコンピュータベースツールを使い、厳密でステップ・バイ‑ステップの証明を生成しています―ただし Lean で書くこと自体は依然として難しいです。
2026年1月にあるチームは、Paul Erdős の問題リストから難題の一つ（実際には誤って記録された文言）について、LLM が証明を生成できるようにしました。プロセスは次の通りでした。
- アウトライン – ChatGPT が大まかな構成案を作成（欠陥が含まれていた）。
- パッチ – Aristotle が論理を修正し、Lean で検証できる形に書き直した。
- 公開 – ChatGPT が Lean の証明を正式な論文へと翻訳し、既存の文献を引用した。
ソフトウェア開発における決定的ツール
次にソフトウェア開発へ戻ります。Claude Code や Gemini Code Assist といったエージェントは、ある程度複雑なアプリを「vibecode」でき、ほぼ中途半端なジュニア開発者と同等の作業が少ない監督で行えます。このようなツールは、ポスト‑エージェント開発を想定した当社業界を再構築しています。
自動デプロイスクリプトは手動よりも高速かつ信頼性が高いだけでなく、決定的に動作する点が優れています。入力が同じなら出力も毎回同一です。一方、人間の手作業ではエラーを起こすリスクがあります。
LLM は人間と決定的プログラムの中間に位置します。退屈したり疲れたりはしませんが、呼び出すたびに完全に同じ結果を返すわけでもありません。学習済み重みに基づく確率分布からサンプリングするため、僅かなばらつきがあります。
デプロイ作業で LLM を使うと、スクリプトを書くより簡単になりますが、信頼性は低下します。たとえば 99 % の成功率でも、時折失敗する可能性があります。
決定性が必要なケース
一回限りのタスク（データ移行やチャート生成など）では決定性は必須ではありません。しかし、多くのコードは「一度書いて何度も実行される」ものです。たとえば、すべての顧客が利用するログインサービスを想像してください。このようなコードは決定的である必要がありますが、その作成自体は必ずしも決定的である必要はありません。
コードベース全体に標準を維持することは本当に繰り返しの多いタスクです。ユーザー入力のエスケープによるインジェクション対策、命名規則の遵守、ログにスタックトレースを残す、ファイルを正しく閉じるなど、経験豊富な開発者でも見落としがちです。LLM は確率的であるため 100 % のコンプライアンスを保証できません。リマインダーやサンプルコードだけでは不十分です。
解決策：検証用コードの生成
以下のようなプログラムを使って、ポリシー違反を検出し決定的に動作させることができます。
- 型システムによる強制 –
とUserString
を定義し、コンパイラで適切なサニタイズを保証する。SanitizedString - リンター – 命名規則や好ましいロギングフレームワークの使用を強制する。
- ユニットテスト – 使ってはいけないライブラリがコード中に含まれていないか検査する。
これらのチェックはビルド時に毎回実行され、人間や LLM の監視ミスを排除します。こうしたツールを作るには労力が必要ですが、エージェント型 LLM は生成に長けています。何度も「規則を守れ」と指示する代わりに、LLM に実装コードを書いてもらい、ビルドチェーンに組み込むと良いでしょう。
この提案は、ポリシーがコードベース全体で一貫して適用される必要がある場合に有効です。単発作業（ログイン画面の作成や新しいリンターの開発など）については、LLM に書かせても構いません。その後の人間による検証レベルはチームの慣行次第です。
まとめ
LLM は完全に決定的ではありません。標準的な実践やポリシーを全コードベースで一貫して適用する必要がある場合は、リンター・テスト・コンパイラチェックといった決定的プログラムを使って遵守状況を検証してください。エージェント型 LLM はこうした検証ツールの構築やワークフローへの統合に役立ちます。