AI 時代，昨日までの合理を選び直す

序

最近，会議やコードレビューで何度も使ってきた言葉が，前とは少し違って聞こえることがある．

採用しやすい技術を選ぶ．枯れたエコシステムに乗る．大規模な書き直しはできるだけ避ける．外部のよく知られた実装を信頼する．テストは費用対効果を考えて，重要なところに絞る．

どれも，これまでのソフトウェア開発の中で積み上げられてきた，良い知恵だった．多くの失敗を経て，ようやく手になじんだ道具のようなものでもある．今になって，すべて間違いだったと言いたいわけではない．

ただ，その知恵を支えていた前提を，AI はすでに変えた．

コードを書く時間．知らない技術を学ぶ時間．大きな変更を進める時間．テストを書き，保守する時間．他者のコードを読み，引き継ぐ時間．

エンジニアリングの考え方は，こうしたコストと無関係ではない．何に時間がかかり，何が難しかったかによって，私たちは何を避け，何を信頼し，何を大切にするかを決めてきた．

哲学というと，もう少し硬く，時間の外にあるもののように聞こえる．けれど，エンジニアリング哲学の大部分は，日々の制約の中から生まれてきたものである．

コストの形が変わった今，長く使ってきた道具を一度机の上に並べ，今も同じように必要なのか眺め直すべきである．

技術選定の基準は変わった

これまで技術選定では，チームの習熟度が大きな基準だった．

今いる人が書けるか．十分な学習資源があるか．困ったときに検索できるか．その技術を扱える人を採用できるか．

この基準は今も大切である．ただし，選定基準としてのベースラインは明らかに下がった．

AI を使えば，知らない言語のプロジェクトを読み，典型的な構成を調べ，小さな実装を作りながら学ぶところまでを，一気に進められる．一人のエンジニアが触れられるコードの範囲も広がった．

エコシステムへの習熟度は，もはや技術選定の絶対条件ではない．選んだあとに獲得できるものとして扱うべきである．

採用市場についても似たことが言える．その技術の経験者が市場に何人いるかは重要だが，それだけで選ぶ必要は薄くなった．

むしろ，そのシステムに長く責任を持つリードエンジニアやチーフエンジニアが，触っていて面白いと思えるかを重く見るべきである．

面白さは，単なる気分の話ではない．難しい問題が起きたときに深く調べたいと思えることや，長く触れる中で少しずつ良くしていこうと思えることは，保守の質にそのままつながる．

長く保守する技術は，毎日少しずつ触れる道具でもある．性能や採用可能性と同じくらい，その手触りを大切にするべきだ．

AI によって「書ける」の範囲が広がった今，人間は「書き続けたい」ものを以前より自由に選べる．

有名であることや，採用しやすいことだけではなく，責任を持つ人がその道具を好きでいられるか．そして，その好みに設計上の筋の良さが伴っているか．

そういう人間的な基準を，技術選定へ戻すべきである．

大きなマイグレーションは現実的になった

技術的負債が怖かった理由の一つは，返すための変更があまりにも大きかったことにある．

古いフレームワークを外す．数百の画面を移す．非推奨になった API を置き換える．言語やランタイムを更新する．

こうしたマイグレーションは，長い時間と多くの人を必要とした．そのため，最初の技術選定では，できるだけ長く使い続けられることが重視されてきた．

一度建てたものは簡単には動かせない．私たちは，その前提で将来を考えてきた．

しかし最近は，かなり大きなソフトウェアでも，実装言語そのものを移すような変更が現実に進んでいる．

Bun は，Zig から Rust への完全移行を終えた． Flow も，OCaml から Rust へ移行した． React Compiler の Rust port も，すでに main へマージされている．

これらは，いつか実現するかもしれない実験ではない．大規模な移行が実際に完了し，既存のプロジェクトへ統合された例である．

もちろん，これらは単に AI に任せて一晩で書き直した，という話ではない．長い時間をかけた設計，検証，性能評価，人間による判断がある．

それでも，AI が既存実装を読み，対応するコードを作り，差分を調べ，テストの不一致を一つずつ埋めることは，この規模の移行を進めるうえで大きな助けになる．実際，こうした移行の差分を AI agent と協働して作ることは，すでに珍しくない．

大規模なマイグレーションのハードルが下がった以上，技術的負債との付き合い方も変えなければならない．

負債は消えない．データ移行，意味論の差，運用中の状態，組織の理解，ユーザーとの契約は，コードを生成するだけでは動かせない．

ただ，「一度選んだら十年は変えられない」という前提は，もう崩れ始めている．以前なら遠すぎて見えなかった移行先が，現実的な距離に入ってきた．

これからの技術選定では，長く使えることだけでなく，必要になったときに移りやすいことも大切になる．境界が明確であること．振る舞いがテストで残っていること．データ形式が開かれていること．一部分ずつ置き換えられること．

良い技術とは，ずっと捨てなくてよい技術だけではなく，いつか無理なく手放せる技術でもある．

仕様は，実行できる形でも残す

自然言語の仕様書は必要である．

なぜ作るのか．誰のどの問題を解くのか．何をしてはいけないのか．複数の価値がぶつかったとき，どちらを優先するのか．

このような意図は，人間の言葉で残す必要がある．

ただ，「この入力に対して，このシステムはどう振る舞うべきか」という部分まで，自然言語だけに預けるのは難しい．

同じ文章を読んでも，人によって想像する境界条件は違う．実装が変わっても，文章の方は古いまま残ることがある． AI もまた，曖昧な言葉を毎回まったく同じように解釈するとは限らない．

文章は，読む人の頭の中で一度だけ実行される．テストは，同じ問いを何度でも実行できる．

そのため，仕様は実行できる形でも残さなければならない．

テスト，型，schema，契約，状態機械，property，lint rule．形式は対象によって異なるが，機械が読み，実行し，違いを検出できることには大きな意味がある．

TypeScript は長いあいだ，「完全な言語仕様がなく，実装とテストが事実上の仕様になっている」と批判されてきた．その批判には理由があるし，人間が設計を理解するための文書が不要になったわけではない．

一方で，AI が実装を大量に生成し，別の実装への移植まで行う世界では，実行可能な振る舞いの集合が以前より重要になる．文章として整った仕様だけでなく，変更のたびに走り，違いを示すテストがあることで，実装は同じ場所へ戻ってこられる．

Test262 は，その最も良い例の一つである． ECMAScript には精密な自然言語仕様があるが，複数の実装が同じ観測可能な振る舞いを持つか確かめるために，膨大な適合テストも用意されている．

仕様書とテストは，どちらか一方を選ぶものではない．人間が意図を理解できる言葉と，機械が繰り返し確かめられる表現の両方が必要である．

テストの価値はむしろ上がる

これまでテストコードには，それ自体のメンテナンスコストがあると考えられてきた．

実装を変えるたびにテストも直さなければならない．壊れやすいテストは開発を遅くする．すべてをテストしようとすると，テストそのものが大きなシステムになる．

これは今も正しい．

ただ，テストを書くこと，既存のテストを移行すること，重複を整理すること，失敗から意図を読み取って修正することは，AI によってかなり容易になった．

一方で，AI によって作られるコードの量は増えている．生成量だけが増え，検証量が増えなければ，システムの中に不確実なものが積み上がっていく．

AI は実装のコストを下げるが，検証を不要にはしない．むしろ，検証の必要は大きくなる．

だから，テストできる振る舞いは，すべてテストとして書き起こすべきである．正常系だけでなく，境界値，失敗，競合，移行前の奇妙な互換性，過去に一度だけ起きた事故まで，機械がもう一度確かめられる形にしておく．

テストにできるものを，すべてテストにした者が勝つ．

テストは，品質保証のためだけのものではない．チームが経験したことを，人の記憶の外へ置くためのものでもある．いわば，外部化された記憶である．

人が辞めても残る．チャットが流れても残る．使う AI が変わっても，同じ振る舞いを求め続けられる．

テストのメンテナンスコストが下がった今，書くか迷っていた領域にも手を伸ばすべきである．

OSS の継続性を引き継ぎやすさから考える

大規模な OSS では，メンテナが単一障害点になることが長く語られてきた．

設計の意図を知っている人が一人しかいない．リリースできる人が少ない． issue の優先順位も，互換性の線引きも，特定の人の経験に支えられている．

その人が疲れたり，生活が変わったりすれば，プロジェクトの継続は難しくなる．

AI は，この問題を自動的に解決するものではない． OSS メンテナの仕事はコードを書くことだけでなく，価値判断をし，変更を断り，説明し，人間同士の摩擦を引き受けることでもあるからだ．

ただ，OSS メンテナ自身も AI のユーザーである． issue の分類，原因の調査，再現コードやテストの追加，互換性確認，リリースノート，移行支援といった作業は軽くできる．

また，メンテナの考え方や日々の振る舞いを，リポジトリの中へ以前より多く残せるようになる．

設計原則を文章にする．受け入れる変更と受け入れない変更を例で示す．互換性をテストにする．リリースを自動化する．判断の履歴を残す．同じ検証環境を誰でも再現できるようにする．

こうしたものが揃っていれば，別の人がフォークしてメンテナンスを続けるハードルはかなり下がる．フォークがコードの複製だけではなく，考え方と手入れの仕方を受け継ぐことに近づいていく．

作者がずっと支え続けることだけを，サステナビリティと呼ぶべきではない．作者が離れたあとも，他者が考え方と検証方法を引き継げること．必要なら枝分かれし，別の共同体として続けられること．

OSS の継続性は，一人のメンテナが残り続けることではなく，他者が引き継げることを中心に設計すべきである． AI は，その引き継ぎを現実的にする．

Vize では，すでにそうしている

これは，未来の OSS についての想像だけで書いている話ではない．私はすでに Vize で，この形を実践している．

Vize は 50 万行規模のソースコードを持つ．私はその大部分を一人でメンテナンスしていて，最近では，その仕事のほとんどを AI によってオートメーションしている．

もちろん，AI に好き勝手コードを書かせているわけではない．

ubugeeei Redundancy Guide には，Vize が何を目指すのか，何を優先するのか，どのように issue を見つけ，報告し，修正し，レビューし，リリースするのかを書いている．

これは単なるコントリビューションガイドではない．私がいなくなっても Vize を前へ進められるように，私の価値観，判断基準，レビュー基準，開発のリズムを外部化した文書である．

私は AI にこの文書を読ませ，「この通りにしろ」と指示する．すると AI は，問題を探し，最小再現を作り，issue にし，回帰テストを書き，修正し，CI を通し，次の問題を探す，という私のワークフローをかなりの精度で再現する．

AI に判断を丸投げしているのではない．判断基準をリポジトリへ移し，その基準に沿った労働を AI に任せている．

Vize のテストケースは，もうすぐ 1 万件に達する．問題が起きるたびに回帰テストを残し，名前を付けられる edge case はすべて書き，実プロジェクトを使って end-to-end に検証する．

AI がテストのメンテナンスコストを下げたのなら，正しい反応はテストを減らすことではない．書けるだけ書くことである．

50 万行を一人で所有し，1 万件近いテストで振る舞いを固定し，自分の仕事の仕方まで文書化して AI に再現させる．これは特殊な武勇伝ではなく，AI 時代の OSS メンテナンスの一つの形である．

人間を不要にするのではない．「私しか知らない」を不要にする．

私自身をプロジェクトの唯一の実行環境にしないことが，Vize におけるサステナビリティである．

採用は人数ではなく密度を見る

80 点のエンジニアを人数でスケールする時代は終わった．

これまでは，安定して 80 点のパフォーマンスを出せるエンジニアを増やし，人数で開発量をスケールさせる考え方が強かった．

しかし，人数が増えれば，コミュニケーション，認識合わせ，レビュー，責任分担のコストも増える．人数を二倍にしても，開発速度がそのまま二倍になるわけではない．

AI が一人の扱える範囲を広げた今，100 点のパフォーマンスを出せるエンジニアが一人で深く所有する方が強い．一方で，これまで 50 点のパフォーマンスしか出せなかった人も，AI と良い検証環境によって，従来の 80 点に届く．

ここでいう点数は，人間の価値ではない．ある仕事，ある時点におけるパフォーマンスを，かなり単純化して表したものである．

大切なのは，少数精鋭という言葉へ戻ることでも，経験の浅い人を不要とみなすことでもない．

AI によって一人ひとりの能力の出方が変わった以上，採用を人数の足し算だけで考えるべきではない．

良い問いを作れること．出てきた答えを疑えること．局所的には正しいコードが，全体を壊す可能性を想像できること．失敗をテストへ変え，次の実装者に渡せること．

コードを書く速さだけでなく，判断力，所有感，学習速度，検証する力が，これまで以上に大切になる．

信頼と内製コストの関係も変わる

私たちは長いあいだ，ある程度の信頼を前提に外部のコードを使ってきた．

Microsoft が作っているから，おそらく大丈夫だろう．有名な OSS だから，突然なくなることはないだろう．利用者が多いから，問題は誰かが先に見つけるだろう．

これは怠慢ではなく，合理的なコスト計算だった．

すべてを自分たちで書き，理解し，監査し，保守することはできない．だから，不完全な信頼を受け入れることで，内製とメンテナンスのコストを減らしてきた．

もちろん，有名な実装にも事故は起こる．企業の戦略は変わり，プロジェクトは終了し，ライセンスが変わり，メンテナは去る．

それでも外部を信頼してきたのは，多くの場合，内製するコストの方が高かったからである．

AI は，この関係を根本から変える．

小さな依存なら，自分たちで置き換えられる．重要な境界だけを薄く内製できる．外部実装を読み，必要な振る舞いを自分たちのテストへ移し，事故が起きたときに離れられる．

だからといって，何でも内製すればよいわけではない．暗号，認証，データベース，分散システムのように，コード量よりも長いあいだ蓄積された知見の方が重要な領域はある． AI がコードを書けることと，過去の失敗をすべて理解していることは違う．

これから問うべきなのは，単純な build or buy ではない．

どこまで信頼し，どこから自分たちで所有するか．事故が起きたとき，読めるか．直せるか．捨てられるか．フォークできるか．必要な振る舞いを，自分たちのテストで確かめられるか．

外部への信頼をやめるのではなく，必要になったときに離れられる形で信頼する．名前の大きさにすべてを預けるのではなく，自分たちで戻ってこられる道を残しておく．その選択肢は，AI によって現実的になった．

もう一度考え直す

AI によって，ソフトウェア開発の難しさがすべて消えるわけではない．

コードは壊れる．仕様は曖昧である．人は疲れ，組織は忘れ，依存先では事故が起こる．生成された大量のコードが，理解されないまま積み上がる危険もある．

それでも，いくつかのコストは確かに下がっている．

知らない技術に入るコスト．マイグレーションを進めるコスト．テストを書き，保守するコスト．他者のコードを読み，メンテナンスを引き継ぐコスト．必要な部分を小さく内製するコスト．

コストが変わった以上，以前と同じ理由で同じ選択を続けるべきではない．

採用市場に合わせるだけでなく，責任を持つ人が面白いと思える技術を選ぶ．長く使えることだけでなく，移りやすいことも考える．自然言語の仕様と一緒に，実行できる仕様を残す．テストできるものは，すべてテストへ書く． OSS の継続性を，一人の献身だけでなく，引き継ぎやすさから考える．人数だけでなく，判断と所有の密度を見る．外部の名前を信じ切るのではなく，離れられる形で信頼する．

これは，昔のエンジニアリングを否定する話ではない．これまでの考え方は，そのときの制約の中で生き延びるために得た知恵だった．

ただ，同じ地図を持って歩いているうちに，足元の地形が変わっていることはある．

AI が書き換えたのは，コードだけではない．私たちが何を難しいと思い，何を諦め，何を信頼するかも，すでに変わっている．

だから今，一度立ち止まって，長く使ってきた言葉をもう一度手に取ってみたい．

これまで大切にしてきたもののうち，今も大切なものは何か．前提が変わったことで，選び直せるようになったものは何か．

すぐに新しい答えを出せなくても，昨日までの正しさを，今日のコストの上でもう一度確かめなければならない．

その問いを持ち続け，選び直し続けることこそ，AI 時代のエンジニアリング哲学である．

序