toriR blog
LLM-codingの暴走を「物理的な規律」で飼いならす —— UNIX/KISS 静的監査の設計思想
LLMコーディングによるコード爆発を防ぐため、物理的な「収束条件」としての静的監査を提案します。エントロピー増大を抑え、20年先も保守可能なシステムを維持するための設計思想について整理しようと考えます。
本記事は なぜLLMコーディングは修正の反復で爆発するのか （Qiita）に対する実装思想編です。まだ発展途上にありますが、どなたかの考えの一助になりましたら幸いです。
1. qiita記事の振り返り
まず、前回の要点を短く再確認します。
- 現象: 修正を繰り返すほどコードが肥大化し、シンプルさが失われる「コード爆発」が起きる。
- 原因: 人間の「加算的指示」とLLMの「局所整合バイアス」が結合し、自己増幅ループになる。
- 結論: AIには「広げる力」はあるが「収束させる力」は弱い。そのため、物理的な収束条件が必要になる。
ここで重要なのは、爆発を単なるモデルの性能不足として片づけないことではないでしょうか。構造として起きる問題である以上、構造として止める必要があると私は考えます。
2. なぜ今「監査（Audit）」が重要なのか
AIをより高い知能で制御し続ける運用は、長期的には非効率になる可能性があるかもしれません。必要なのは、判断の巧拙に依存しない「規律の自動化」ではないでしょうか。
2.1 知能 vs 規律
LLMは、もっともらしい改善を高速に提案できます。 しかしその「もっともらしさ」は、結果としてシステム寿命を縮める場合もあるかもしれません。そのため、知能を積み上げるよりも、壊せない規律を先に置く方が安定するのではないかと考えます。
2.2 20年運用という時間軸
今日の最適化よりも、20年後の可読性と保守性を守る視点が重要になるかもしれません。「未来の自分が読めるか」を保証するための不変のバリデータとして、監査の役割が見えてくるように感じます。
2.3 監査の定義変容
監査は従来「間違い探し」として扱われてきました。しかしここでは、システムの純度を維持するための「排熱（Entropy Control）」として捉えるべきではないかと考えます。
3. 静的監査コードの設計思想: 3つの柱
ここで扱うのは具体的な実装手順ではなく、「何を測るか」という思想です。
3.1 「情報量」で測る（無秩序の検知）
Kolmogorov複雑度の近似やAST密度の計測。これらにより、「読みにくさ」という主観ではなく、情報としての不自然さを定量的に検出することを狙いたいと考えます。
3.2 「境界」を監視する（不可侵領域の死守）
状態漏洩の検知や、層間の物理的断絶の維持。境界は設計思想として語るだけでなく、監査対象として固定されるべきものだと考えます。
3.3 「加点」ではなく「即時却下」
機能的に優れていても、規律違反があれば負債とみなします。監査は改善の提案ではなく、却下判定（Hard Fail）として機能させる必要があるかもしれません。
4. 収束のダイナミズム: 探索と淘汰のサイクル
AIエージェント運用では、「広げる（LLM）」と「狭める（監査）」を分離することが重要だと考えます。この反復の中で残るべきものは、機能を維持しつつエントロピーが最も低い「最小構造」ではないでしょうか。
5. 転換: 設計思想から収束条件へ
UNIX/KISSは、美しいコードを書くための思想として語られてきました。しかしここでは、発散を止めるための「停止条件」として再解釈できるのではないかと考えます。
6. UNIX/KISSの再定義
- UNIX = 境界固定: 境界が固定されなければ、生成コードは全体へ浸透し続け、結果として収束が難しくなる可能性があります。
- KISS = 削除と単一路: KISSは短く書く技術というよりも、広がる力に対する「制約」として機能するのではないでしょうか。
7. なぜ監査が必要になるのか
人は削除を徹底しにくく、LLMは削除を選びにくい。両者が「拡張方向」に偏るという構造を前提にすると、狭める力を外部化することが必要になると考えます。
8. DX劣化の本質 ― エントロピー増大としてのコード社会
人の「やりたいこと」とLLMの実装能力が結びつくことで、コード生成の摩擦が消失しつつあります。その結果、小さな要求がそのまま実装され、削除されない機能が蓄積していく可能性があります。
これは、システムの「状態空間」が拡張し続けるエントロピー増大現象として捉えられるかもしれません。DXは生産性向上であると同時に、複雑性を加速する側面も持つのではないかと私は考えます。
9. 監査の本質：エントロピー制御
問題の本質がエントロピーの増加であるならば、監査は「排熱装置」として再定義できるのではないでしょうか。バグの有無を確認するだけでなく、構造の無秩序化を抑制し、収束方向へ導く仕組みだと考えます。
10. 静的監査の役割
動的テストが振る舞いを守るのに対し、静的監査は「構造の純度」を守る役割を担うと考えます。
- 構造を早期に観測し、発散の兆候を検知する
- 生成ループの外側から制約を与え、エントロピー増加を未然に抑える
11. 監査が担う3つの機能
- Reject（拒否）: エントロピーの急増点を遮断する
- Compression（圧縮）: 重複や冗長を排除し、エントロピーを低減する
- Stop（停止）: 収束を判定し、反復を終了させる
12. 批判への補足
監査は一見すると開発速度を下げるように見えるかもしれません。しかし、長期的には無秩序が生む摩擦の方が大きくなる可能性があります。短期の生成速度と、長期の変更可能性は、切り離して考える必要があると感じます。
13. 抽象化
この「生成と監査」の構造は、進化における「変異と選択」、あるいは熱力学における「エントロピーと排熱」といった枠組みと対応しているように見えます。
14. 結論
LLMはコード生成の摩擦を低減し、エントロピーを増大させます。この流れ自体は自然なものかもしれませんが、制御は可能だと考えます。UNIX/KISSを「収束条件」とし、監査をそれを実行系に固定する「仕組み」とすることで、持続可能なシステムを維持できるのではないでしょうか。
15. 結び
これからのエンジニアは、コードを書くこと以上に、流れを設計し、純度を維持し、エントロピーを管理する役割を担うのではないかと考えます。コード爆発は単なる不具合ではなく、私たちの時代の構造的な現象の一つかもしれません。
補足：実践に向けた「初期閾値」の目安
具体的にどのような数値を設定すべきか、私が現在、自身のプロジェクトで試行している目安を共有します。これらは絶対的な正解ではなく、あくまで「エントロピーの増大を検知するためのアラート」として提案するものです。
- AST密度 (\(Density_{AST}\)):
\(\frac{\text{Nodes}_{AST}}{\text{LOC}}\)
- 目安：5.0 以下
- 1行あたりの論理的な重みです。これを超える場合、1行に複雑な処理を詰め込みすぎているか、LLM特有の過剰な三項演算子などが使われている可能性があるかもしれません。
- 圧縮率 (\(Ratio_{comp}\)):
\(\frac{\text{Size}(\text{Gzip}(\text{Code}))}{\text{Size}(\text{Raw}(\text{Code}))}\)
- 目安：0.2 〜 0.5
- コードの「情報の密度」を測ります。0.2を下回る場合はボイラープレートのような冗長な記述が多く、0.5を超える場合は構造が断片化しすぎて無秩序（ランダム）に近い状態になっているサインだと捉えています。
- 物理的制約（KISSの基本）
- 関数長：15論理行以内
- ネスト深度：3階層まで
- 依存インポート数：1ファイルにつき3〜5個程度まで
