Vize
AI のための静的解析
AI のコーディングツールが広まるにつれて、よく聞く反応があります。静的解析は、もうそれほど重要ではないのではないか、というものです。
アシスタントがコードを生成し、エラーを説明し、修正を提案し、テストまで実行できるなら、なぜリンター、型チェッカー、コンパイラの診断、エディターの解析にこだわるのでしょうか。
私は、その逆だと考えています。
AI の時代は、静的解析の必要性を減らすのではなく、増やします。それも、どんな静的解析でもよいわけではありません。決定論的で、速い静的解析 です。
AI は強力だが、確率的なもの
大規模言語モデルは非常に役に立ちます。しかし、確率的なシステムであることに変わりはありません。
ありそうな続きを予測しますが、不変条件を保証するわけではありません。
そのため AI は、次のようなことがとても得意です。
- コードの下書きを作る
- アーキテクチャを提案する
- 意図を実装に落とし込む
- 失敗の原因として考えられるものを説明する
しかし AI だけでは、プログラムが構造的に正しいか、型安全か、内部で矛盾していないかを判断する、信頼できる基準にはなりません。
その基準は、別のところから得る必要があります。
決定性が釣り合いを取る
AI の確率的な振る舞いを補うのが、静的解析です。
コンパイラがバインディングが存在しないと言うとき、その結果がプロンプトの言い回しに左右されてはなりません。
型チェッカーが props の契約が破られていると言うとき、その結果がモデルの temperature によって変わってはなりません。
リンターが安全でない v-html を指摘するとき、それがベストエフォートの推測であってはなりません。
決定論的なツールは、次のことを保証してくれます。
- 同じ入力からは、同じ出力が得られる
- 診断を、構文と意味に基づいて説明できる
- 失敗を、エディター、CI、自動化のどこでも再現できる
- 信頼が、モデルの性格に左右されない
言い換えれば、静的解析は、システムの中で「いいえ、これは間違っています」と言い続けられる部分です。
周囲のシステムで生成的な部分が増えるほど、これは重要になります。
速いフィードバックは、もはや必須
かつて速さは、開発体験のための贅沢品でした。
AI の時代には、それがインフラになります。
AI に支援された開発では、フィードバックを得る機会がずっと多くなるからです。
- コードが生成されている間も、エディターは継続的に診断を要求する
- エージェントがパッチを提案し、ツールにその検証を頼む
- CLI のワークフローが、変更のたびにチェックを実行する
- 人が目にする前に、CI が機械の生成した多数の差分を評価することもある
静的解析が遅いと、その周りのすべてが無駄になります。
- エージェントが、検証を待って止まる
- エディターの通知が煩わしく、動作ももたつく
- 自動修正のループが、より多くの時間とトークンを消費する
- 開発者がツールチェーンを信頼しなくなり、チェックを無効にする
速い静的解析は、人を満足させるためだけのものではありません。人と AI を組み合わせたシステム全体を、経済的に成り立たせるためのものです。
AI には、機械が読み取れるガードレールが必要
ここには、ツールの設計の問題もあります。
よい静的解析は、人向けの赤い文字を出力するだけではありません。機械が読み取れる、構造化された制約を出力します。
- 正確な位置
- 安定したルールの識別子
- 対応につながる分類
- 修正の候補
- 型の情報
- プログラムの各部分の、記号的な関係
これはまさに、AI のシステムがうまく活用できる種類の情報です。
LLM は、あいまいな失敗の報告ではなく、決定論的な構造化情報を利用できるとき、ずっと役に立ちます。「テンプレートのどこかがおかしいようです」よりも、「この位置に vize/vue/require-v-for-key のエラーがあります」のほうが、自動修正の土台としてはるかに優れています。
つまり、未来は静的解析の 代わりに AI を使うことではありません。 静的解析の 上で AI を使うことです。
AI が書くコードが増えるほど、素早い却下が必要になる
AI がコードを書くようになると、目立たないけれど重要な変化がひとつあります。却下しなければならないコードの量が、劇的に増えうることです。
人の開発者がタイプする速度は、比較的ゆっくりです。モデルは、大きな差分を数秒で提案できます。
これで、検証の経済性が変わります。
人がひとつのアイデアを打ち込むより前に、間違ったアイデアが 10 個生成されうるなら、ツールチェーンは悪いアイデアを同じくらい素早く却下しなければなりません。そうでなければ、選別が追いつかない速さで無効なコードを生み出すことに長けたシステムができあがってしまいます。
だからこそ、素早い否定的なフィードバックがとても重要なのです。
静的解析は、よいコードを承認するためだけにあるのではありません。悪い道筋を早い段階で断ち切るためにもあります。
- ありえない参照
- 無効なテンプレートの構文
- 破られた props の契約
- 安全でない書き方
- フォーマットやスタイルのずれ
- API の誤用
この素早い却下の層がなければ、AI はノイズを増幅します。
この層があれば、AI は探求を増幅します。
Vue でこれがとくに重要な理由
Vue は、TypeScript に HTML を足しただけのものではありません。
.vue ファイルには、次のような要素にまたがる構造があります。
- テンプレートのセマンティクス
- ディレクティブの構文
- コンポーネントの props と emits
- SFC のブロックの境界
- スタイルのスコープ
- フレームワークの規約
汎用的な JavaScript のツールは、この形を完全には理解していません。
だからこそ、Oxlint のような優れた JS/TS のツールや、Vite+ のような汎用的なワークフローのツールがすでにあっても、Vue 固有の静的解析には意味があります。
たとえば、AI が生成した Vue のコードには、次のような問題が簡単に入り込みます。
v-forでのkeyの付け忘れ- 安全でない
v-html - 無効なテンプレートの式
- props と emits の食い違い
- 重複した属性
- SFC の文脈でしか意味をなさない、コンポーネントの誤用
これらは、めったに起きないケースではありません。フレームワーク固有の境界を素早くまたいで作業するとき、生成的なツールがまさに犯しやすい種類の間違いです。
静的解析は信頼の境界
これらすべてが重要な、より深い理由は、信頼です。
AI に支援された開発では、確信があいまいになりうる場面がたくさんあります。
- モデルが確信を持っているように聞こえる
- パッチがもっともらしく見える
- 説明が筋の通ったものに感じられる
- 差分が大きく、人が流し読みしてしまう
静的解析は、「もっともらしい」と「実際に正しい」の間に、信頼の境界を作ります。
この境界は、完璧でなくても役に立ちます。ただし、次の条件は満たしている必要があります。
- 決定論的であること
- 速いこと
- フレームワークを理解していること
- コードが流れるすべての場所で使えること
つまり、エディター、CLI、CI、機械同士のワークフローのすべてが、同じ根拠に基づく結果を利用できる必要があります。
これが Vize を作る理由のひとつ
これが、私が Vize の方向性を大切にしている理由のひとつです。
私が Vize に関心を持っているのは、Rust が速いからだけではありません。 Vue を理解する統合されたツールチェーンなら、次の領域にまたがって、より強固な決定論的な基盤を提供できるからです。
- コンパイル
- lint
- フォーマット
- 型チェック
- 言語ツール
- AI 向けの連携
これらがパーサー、ファイルのモデル、Vue のセマンティクスについての共通の理解を共有すれば、フィードバックはより一貫したものになります。その出力を AI のシステムも利用するなら、この一貫性はさらに重要になります。
目的は、静的解析で AI を置き換えることではありません。 AI が、より確かな土台の上で動けるようにすることです。
未来はハイブリッド
勝ち残るのが、次のどちらかのモデルだとは思いません。
- 「モデルを信じればよい」
- 「AI を無視して、従来のやり方だけを続ける」
未来はハイブリッドです。
- 合成、探索、加速、修正には AI を
- 不変条件、制約、却下、信頼には静的解析を
AI によって、ソフトウェアの作り方はより生成的になります。 だからこそ、決定論的な検証の価値は下がるのではなく、上がります。
AI がプログラミングのより大きな部分を占めるようになると考えるなら、よりよい静的解析も求めるべきでしょう。
そして、誰もが迷わずに使えるほど、速いものであってほしいと願うべきです。