減らない分岐は、指示ではなく型のせいだった

AIエージェントが生成したコードを見ると、妙に分岐が多い。if (!data) とあるけど、そこは本当に起こる状態なのか、それとも型が null を許しているせいだけなのか——人間が呼び出し元をたどって確認しなければわからない。LinearB の 2026 年ベンチマークでは、AI 支援の PR は 408 行と、無支援の 157 行に対して 2.6 倍に膨張。さらにレビュー着手までの待ち時間は 5 倍以上に延びている。その時間の大部分は「ほぼ正しいが微妙に違う」コードの検証と、不要に見える分岐が本当に不要なのかの確認に消えている。

型の話は退屈に聞こえるが、ここが生成の高速化が招いた本当の問題だ。従来型の state = {isLoading, employees, error} という定義では、isLoading が true なのに error も入っているといった「意味を持たない組み合わせ」が型として許可される。すると AI は律儀にそれを処理する分岐を書く。指示を「不要な分岐を書くな」と厳しくしても、型が許した状態だから正しい仕事をしているだけ。変えるべきなのは指示ではなく、型の側だ。判別共用体（discriminated union）で状態を再定義すれば、実際に起こる 4 つの状態だけを表現でき、あり得ない組み合わせはコンパイラが拒否する。状態を新しく足したときも、コンパイラが修正箇所を自動列挙するから、それが そのままエージェントへの作業指示になる。

エンジニアリングの現場では「AIに何を指示するか」に目が行きがちだが、本当に大事なのは「システムの設計にどう型を仕込むか」だ。型が表現できなくした状態については、レビューで確かめる作業そのものが発生しない。それは人間の読む時間を直結に削減する。中小企業の開発でも、生成の速さに飲まれて設計をスキップすれば、後の保守が地獄になる。「きちんと型を決める」は地味だが、AI 時代の開発速度を本気で高める鍵になる。