コーディングが速くなった話は、氷山の一角だ ── 水面下で起きているのは、保守フェーズそのものの構造変化である。
1-01で、AI が最強の SIer になった ── コードを書くだけでなく、文脈を理解して設計までする ── という事実を据えた。ここから最初に派生する帰結は、よく語られる「コーディングが速くなる」ではない。保守の構造が組み替わることだ。本章はその組み替えを見る。
ソフトウェアの一生で、コーディングは最初の数ヶ月にすぎない。残りの 7 年〜15 年は保守だ。エンタープライズシステムでは TCO の 6〜8 割が保守フェーズに落ちる ── 半世紀知られている事実である。
まず、いまの保守を見る ── すべてがコードの周りで回る
AI の話題でよく取り上げられるのは「コードが速く書ける」だ。これは事実だが、氷山の一角でしかない。ソフトウェア開発の支配的コストは、 書くことではなく書いた後にある ── Brooks の『人月の神話』以来、 50 年知られてきた。水面下に隠れている本体は、これだ:
- レガシーコード読解 ── 普通は半日〜数日
- 既存の挙動を壊さずに直す ── 数日
- テストの追従 ── 後回しになる
- ドキュメントの追従 ── 通常は乖離したまま
- 仕様の暗黙化 ── 関係者がいなくなったら復元不能
- 技術的負債の蓄積 ── 毎年ゆっくり、確実に
旧来、保守の 単位 はコードだった。バグが出る → コードを読む → コードを直す → テストを書く → ドキュメントを直す。すべてがコードの周りで回る。中でも最大の単一コストは、既存コードの読解だ。20 万行の業務システムを、退職した前任者の意図ごと読み解く ── 新任者が数週間かかり、しかも 100% は復元できない。レガシーを「触れない」ことが、システム全体の延命を強いてきた ── 書き換えコストの大半が、読解コストだったからだ。
そもそも、なぜすべてがコードの周りで回るのか。設計書が、現実に追いつけなかったからだ。顧客は、細かい要望を言葉で SIer に伝えきれない ── 動くものを見て初めて「ここはこうしたい」と気づく。SIer の側も、変更のたびに設計書を直すのは手間なので、設計書ではなくコードを直す。こうして設計書は更新されないまま取り残され、現実に追いついている資料はコードだけになる。「コードを読むのが一次資料」という常識は、ここから生まれた。
そして、この常識が「vibe coding」を生む。コードが一次資料なら、 コードさえ書ければいいという発想になる ── 動けばいい、出力さえ出れば正解だ、と。だが、これではまるで意味がない。設計も仕様も文脈も持たないコードは、たとえ動いても、何のために何をしているのかが、書いた本人にも、次に読む者にも分からない。積み上がるのは、読めず・直せず・信頼できないコードの山だけだ ── コードが書けること自体には、ほとんど価値がない。
「コーディングが速くなった」は、AI 化の入口の話だ。出口の話は、保守フェーズの構造そのものが変わることだ。
AI は文脈を理解する ── だから、コードでの保守は要らなくなる
ここで1-01の一点が効いてくる。設計の核心は 文脈の理解であり、AI はそこに達した。AI は、システム全体の文脈 ── 構造・意図・経緯 ── を読み解ける。
そして、理解した文脈を、AI は 二つの形に書き起こせる ── 人間用のマニュアル(どう使い、どう運用するか)と、機械用の設計書(構造・仕様 ── AI 自身がコードを生成する拠り所)だ。かつて、人間が面倒がって更新せず死なせた設計書を、AI が文脈から自動で書き、保つ。人間はマニュアルを読み、機械(AI)は設計書を読んでコードを生成・再生成する。
ここから、大きな帰結が一つ出る。マニュアルを理解でき、それを現実に合わせられる人なら、開発も保守もできる。コードを読む必要も、書く必要もない。難しいことを決める必要もない ── マニュアルを読んで、自分の現実にあわせるだけだ。コーディングの経験は、前提ではなくなる(1-05で「顧客自身が作る」として展開する)。
チェックの側も同じだ。設計書のレビューも、コードのセキュリティ監査も、 Mythos/Fable クラスの AI ができる ── 攻撃の構造を組み立てられる力 (1-01)は、裏返せば、弱点を見つけて塞ぐ力でもある。そしてその水準は、 大手の SIer を上回る。レビューやセキュリティチェックを外注する理由は、もうない(委託そのものが成り立たなくなる構造は、転換編で扱う)。
(放置・暗黙化)"] OC["コード
(人間が一行ずつ相手にする)"] OT["テスト・ドキュメント
(必ず遅れる)"] OD -.-> OC ==> OT end subgraph New["AIネイティブな保守 ── 文脈が主戦場"] direction TB ND["設計・仕様・文脈
(やりたいことを AI に伝える
── SIer に頼むのと同じ)"] NC["コード
(AIが文脈から生成)"] NT["テスト・ドキュメント
(AIが設計から同期)"] ND ==> NC ==> NT end classDef good fill:#e8f5e9,stroke:#7a9a6d,color:#3a4d34 classDef bad fill:#fef3e7,stroke:#c89559,color:#5a3f1a class New good class Old bad
旧来の保守は、コードを相手にする作業だった。いまは、保守も開発も、AI と対話する作業に変わる ── やりたいことを伝えれば、コードもテストもドキュメントも、AI が作り直す。
次の章へ
コードでの保守が要らなくなり、現場で保守ができる。この変化は、二つの問いを突きつける ── 個人としては、「コードを書くこと自体を仕事の中心に置く役割(コーダー)」はどうなるのか。組織としては、開発を請け負ってきた SIer は、まだ要るのか。次の章では前者 ── コーダーという役割そのもの ── を扱う。後者、SIer が不要になる構造は、転換編で扱う。