コードより先に、証拠を移行せよ

Chapter 01

二つの実験結果が矛盾する朝

この本は、AIが書いたコードをどう信じるか、という問いから始まる。書く速度と、正しいと確認する速度は同じではない。

生成速度と検証速度を分ける

GitHub Copilotの実験では、単発のJavaScript HTTPサーバ実装タスクでAI支援群が速く完了した。一方、METRの実験では、経験豊富なOSS開発者が自分のリポジトリで作業したとき、AI利用で時間が長くなったと報告された。

この二つは単純な矛盾ではない。前者は「何を作るか」が狭く、正解判定も比較的はっきりしている。後者は文脈が深く、レビュー、修正、既存設計との整合が重い。AIが速くするのは主に生成であり、検証まで自動的に安くするわけではない。

ここでいう検証とは、コンパイルが通るかだけではない。既存仕様を壊していないか、性能が落ちていないか、運用上の癖を踏んでいないかまで含む。AI時代の開発では、この検証側が新しいボトルネックになる。

ただし、これらの数字はAI一般の永遠の評価ではない。METR自身も後続更新で測定設計を見直している。本書では数字を予言ではなく、生成と検証を分けるための観察窓として扱う。

この本の中心仮説

本書では、コードが正しいと判断するための材料を「証拠」と呼ぶ。型、テスト、仕様、ベンチマーク、静的解析、運用ログ。これらはすべて、AIが出したコードを受け入れるか棄却するための判断材料になる。

AIが安くしたのは、コードを書くことだ。まだ安くしていないのは、コードが正しいと知ることだ。だから、これから価値が上がるのは「書ける人」よりも、「正しさの証拠を設計できる人」である。

Chapter 02

言語価値スタック

言語の価値は一枚岩ではない。AIで安くなった層と、逆に値上がりした層を分ける。

4層で見る

第一層は構文とAPIの再生だ。for文の書き方、標準ライブラリの関数名、定型的な使い方。この層はAIが最も得意で、価値が下がりやすい。

第二層はエコシステムだ。ライブラリ、サンプル、トラブルシュート記事、既存事例。AIはこの層を学習し、参照し、再利用する。厚いエコシステムはAIの出力品質も支える。

第三層は検証可能性だ。型、所有権、コンパイラ診断、静的解析。AIが間違った候補を出したとき、機械的に弾けるかがここで決まる。

第四層は証拠だ。特定のコードベースに蓄積されたテスト、仕様、ベンチ、運用知識。これは組織固有の資産で、AIに最も渡しにくく、だからこそ価値が高い。

PythonとRustを同じ物差しで比べない

Pythonは第二層、エコシステムで強い。Rustは第三層、検証可能性で強い。だから「Pythonは遅い」「Rustは難しい」という単純比較では、何を買っているのかが見えない。

AI時代の言語選定は、どの層に投資するかの問題になる。構文暗記が安くなるほど、上の層、特に検証可能性と証拠の価値が上がる。

Chapter 03

証拠生成という職能

答えはコードだけではない。人間が作るべきものは、コードを信じるための証拠である。

証拠の種類

型は、コンパイル時に確認できる証拠だ。テストは、実行時に期待動作を確認する証拠だ。仕様は、何を満たすべきかを記述する証拠だ。ベンチマークは、性能が落ちていないことを示す証拠だ。

これらは人間の安心材料であると同時に、AIの制御材料でもある。AIがコードを出し、型やテストやベンチがそれを弾く。この構図では、証拠はエージェントを動かすためのレールになる。

証拠はコードより長生きする

実装をPythonからRustへ移しても、「この関数は負の残高を返してはいけない」という性質は残る。コードは言語に縛られるが、性質やベンチの意図は言語を越えて持ち運べる。

だから移行プロジェクトで最初に移すべきものはコードではない。まず移すべきなのは、何を守るべきかを示す証拠である。

証拠が薄いとAIは遅くなる

AIが出した候補を、人間が毎回頭の中で検証するなら、AIは単なる作業割り込みになる。逆に、証拠がCIや型やテストに入っていれば、人間に届く前に多くの候補を機械が棄却できる。

同じAIを使っても、証拠の厚いチームと薄いチームでは実効性能が変わる。AI導入の差は、モデルの差だけではなく、証拠基盤の差でもある。

Chapter 04

Verifier-in-the-Loop

AIを賢くするだけでは足りない。AIの隣に、強い検証器を置く必要がある。

生成器と検証器を分ける

LLMは候補を出す生成器である。検証器は、その候補が仕様を満たすかを判定する。候補が落ちたら、検証器は反例や診断を返し、生成器はそれをもとに修正する。

このループを本書では verifier-in-the-loop と呼ぶ。重要なのは、生成器の賢さだけではなく、検証器の強さ、速さ、診断の具体性がループ全体の性能を決めることだ。

人間は最後の検証器

構文チェック、型チェック、lint、ユニットテスト、プロパティベーステスト、ベンチマーク。これらを通した後に、人間レビューが来る。人間は最も高価で、最も文脈を読める検証器だ。

だから人間を最初の検証器にしてはいけない。人間の前に機械の漏斗を置く。これがAI時代のレビュー設計になる。

検証器にも穴がある

テストを通すことだけを目標にすると、AIはテストに過適合した退化解を出すかもしれない。ベンチだけを見れば、正しいが危険なコードを通すかもしれない。

対策は、証拠を一種類にしないことだ。型、テスト、プロパティ、ベンチ、運用観測を重ねる。単独の検証器に頼らず、複数の証拠で面を作る。

Chapter 05

Pythonはなぜ死なないか

Pythonの強さは、言語仕様だけでは説明できない。資産と実験速度が、Pythonの重力を作っている。

エコシステム重力

Pythonには、PyPI、NumPy、pandas、PyTorch、Jupyterなどの巨大な資産がある。これは単なる便利ツールの集まりではない。他人が何度も使い、壊し、直してきた振る舞いの蓄積である。

AIはこの蓄積から学ぶ。既存のサンプルが多く、失敗例も多く、解説も多い言語では、AIも補完しやすい。つまり、エコシステムの厚さは人間だけでなくAIにも効く。

実験速度という証拠生成

Pythonは静的検証を犠牲にする代わりに、実行して確かめる速度を高めた。ノートブックで仮説を書き、実行し、出力を見る。機械学習のように正しさが実験で決まる領域では、この速度が非常に強い。

これは「Pythonは検証が弱い」という話だけではない。Pythonは、実行という形の証拠を素早く作る言語でもある。

mypyは建て替えではなく補強

型ヒントとmypyは、Python資産を捨てずに検証層を後付けする方法である。Dropboxの大規模なPython型付け事例は、既存資産に証拠を重ねる発想の実例として読める。

ここで大事なのは、全面移行ではないことだ。既存の動く資産を壊さず、型という機械可読な部分仕様を上に積む。これは、後で見る移行戦略の原型でもある。

Chapter 06

Rustという賭け

Rustのコンパイラは、ただコードを拒否するだけではない。反例と修正の方向を返す検証器として読める。

コンパイラを検証器として雇う

Rustの所有権と借用検査は、use-after-freeやデータ競合のような問題を実行前に弾く。これは、テストで見つけにくい種類のバグをコンパイル時に前倒しで検出する仕組みである。

AIが書いたRustコードがコンパイラに怒られる。これは失敗ではなく、検証器が反例を出したということだ。診断が具体的なら、AIはそのエラーを読んで修正できる。

借用検査器は診断オラクル

オラクルとは、テストで正解を判定する装置のことだ。Rustの借用検査器は、値がどこで移動し、どこで借用され、どこで使えなくなったかを示す。

人間には学習コストになるこの厳しさが、AIにとってはフィードバック信号になる。Rustの難しさは、AI時代には検証ループの強さとして再評価できる。

unsafeは穴ではなく台帳

Rustにもunsafeはある。だから完全ではない。しかしunsafeは、検証器が証明できない場所を明示する。つまり、人間が監査すべき場所を台帳化する。

安全性を完全に機械に任せるのではなく、機械が見られる場所と人間が見る場所を分ける。この境界が見えること自体が、証拠の品質を上げる。

Chapter 07

Androidの実証

Androidの事例は、全面書き換えではなく新規コードの言語転換が効く、という重要なヒントをくれる。

メモリ安全性の数字

Googleは、Androidでメモリ安全性に関わる脆弱性の比率が、2019年の76%から2024年の24%へ下がったと報告している。これは、RustやKotlinなどのメモリ安全な言語を新規コードに使う戦略と結びつけて説明されている。

この数字は、単にRustが好きという話ではない。言語選定が、セキュリティ上の失敗の流入経路に影響しうるという実運用の証拠である。

古いコードを全部書き換えない

Androidの戦略で面白いのは、既存C/C++を全面的に書き換えるのではなく、新しく書くコードから変えた点である。古いコードには長年の運用によるエビデンスが溜まっている。全面書き換えは、そのエビデンスを捨てる行為にもなる。

危険なのは、まだ運用で叩かれていない新しいコードだ。そこにメモリ安全な言語を使うと、脆弱性の流入を抑えられる。これは漸進的移行の強い根拠になる。

一般化の限界

ただしAndroidは巨大なセキュリティ投資を持つ特殊な組織であり、同じ数字がすべての現場に当てはまるわけではない。Webアプリや業務システムでは、ボトルネックがメモリ安全ではないことも多い。

それでも、「新規コードから変える」「古いコードの運用実績を尊重する」という発想は、ほかの移行にも応用できる。

Chapter 08

「AI専用言語」の誘惑と罠

発想は魅力的だ。だが、新言語にはコーパスと検証器のコールドスタートがある。

AI専用言語の魅力

AIが主な書き手になるなら、構文は人間の覚えやすさではなく、機械の生成しやすさや検証しやすさに合わせればよい。正準形、効果システム、契約、性能予算を言語の中心に置けば、AIが間違いにくい言語を作れるかもしれない。

この考えは軽く扱うべきではない。AI時代の言語設計として、意味論の濃度を上げる方向は本物の論点である。

でも、学習データはどこにあるのか

新言語には学習コーパスがない。GitHub上の実例も少なく、失敗例も少なく、Stack Overflowの回答も少ない。LLMは過去のコードと解説から学ぶため、新言語はAIにとっても苦手な言語として始まる。

さらに、新言語には成熟したコンパイラや標準ライブラリ、デバッガ、プロファイラ、検証ツールもない。検証器を信じるための信頼計算基盤 TCB も、ゼロから育てる必要がある。

勝ち筋は構文ではなく意味論

だから最初に作るべきものは、まったく新しい構文ではない。既存言語の上に、正準フォーマット、契約、効果の注釈、性能ベンチゲートを重ねる方が現実的だ。

AI専用言語の本体は、実は新しい見た目ではなく、機械が検証できる意味論である。そこは既存言語の上にも積める。

Chapter 09

仕様マイニング

答えは、動いているシステムの振る舞いである。仕様は書類だけでなく、本番の入出力やログの中にもある。

仕様は地層である

仕様には三つの層がある。入力に対する出力を決める機能仕様。常に成り立つべき不変条件を表す性質仕様。レイテンシ、エラー率、バッチ完了時刻のような運用仕様。

移行で壊れやすいのは、しばしば運用仕様だ。機能的には同じでも、p99レイテンシが悪化すれば本番では失敗である。

旧実装をオラクルにする

絶対の正解がわからなくても、新旧実装の差分は検出できる。差分テストは、同じ入力を旧実装と新実装に投げ、出力の違いを調べる。

旧実装が完全に正しいとは限らない。それでも、既存ユーザーが依存している振る舞いを守るという意味では、旧実装は重要なオラクルになる。

本番入出力を扱うときは、個人情報、規制、季節性の偏り、書き込み副作用を無視してはいけない。仕様マイニングはログを乱暴に集める話ではなく、観測できる振る舞いを安全に証拠化する設計である。

PBT、シャドートラフィック、翻訳検証

プロパティベーステストは、少数の例ではなく法則を書く。シャドートラフィックは、本番リクエストを新実装にも流し、応答差分だけを見る。翻訳検証は、変換前後の意味が保たれているかを可能な範囲で機械確認する。

どれか一つで完全になるわけではない。強いが狭い証拠、広いが粗い証拠、本番分布に強い証拠を積み重ねる。

Chapter 10

漸進的移行の設計

問題はコードを書く速度ではない。移行中に検証フィードバックを得られる構造を作れるかである。

FFI境界は無料ではない

PythonからRustを呼ぶ、C++からRustを呼ぶ、Goから別サービスへ切り出す。こうした境界にはコストがある。データ変換、エラー表現、文字列、null/None/Option、認知負荷。境界は少なく、粗く、計測可能にする必要がある。

細かい関数をたくさん移すと、言語境界の通過コストが本体より重くなることがある。移行単位は、コールグラフやデータ境界を見て切る。

移行エンジンの五段階

第一に仕様採掘。第二にAIによる変換。第三に型、テスト、ベンチ、差分テストによる検証。第四にシャドー配備。第五に切替と旧コードの退役。

この流れは一回だけのプロジェクトではなく、繰り返し使うパイプラインにする。失敗したら反証例を前段に戻す。そうすると、移行エンジンは経験を蓄積する。

人間が決めるレーン

AIに任せてよい領域と、人間が決める領域を分ける必要がある。未定義動作への依存、並行性の意味論差、浮動小数点の再現性、外部観測可能なタイミングは、保存すべき意味が一意でないことがある。

ここはAIの能力不足ではなく、そもそも決めるべき仕様が曖昧な領域だ。だから人間レーンに送る。AIに流す前に、分水嶺を設計する。

Chapter 11

コードより先に証拠を移行せよ

この本の結論は、どの言語が勝つかではない。何を言語の壁を越えて持ち運ぶべきかである。

コードはキャッシュだ

コードは、ある時点の実行環境に合わせて証拠を具現化したものだ。実装言語が変わればコードは変わる。しかし「何を守るべきか」を示す証拠は残せる。

レガシー問題の正体は、コードが古いことではない。コードしか残っていないことだ。仕様、性質、ベンチ、差分履歴が残っていれば、コードは再生成できる。

未来の言語は発見される

未来の言語は、机上の設計図だけから発明されるのではない。証拠生成コストが低く、AI生成と検証ループが濃く回る場所へ、コードと知識と人が集まる。

その集中がコーパスを厚くし、AI性能を上げ、さらに集中を呼ぶ。言語の勝者は、構文の美しさだけではなく、証拠の重力によって発見される。

月曜日にやること

自分のコードベースで、まず証拠を棚卸しする。型はどこまであるか。テストは何を守っているか。ベンチはあるか。本番のログから仕様を掘れるか。AIを導入する前に、AIを受け止める証拠を作る。

次に、移行対象を探す。性能や安全性のコストが高く、境界が切りやすく、検証しやすい場所から始める。コードを移す前に、証拠を移す。これが本書の行動指針である。