はじめに
ここ十数年の開発現場を眺めていると、ある一貫した流れが見えてきます。
- データベースの変更は、手作業のSQLからマイグレーションファイル（Flyway / Liquibase / Rails migration）へ
- インフラは、コンソールのポチポチから IaC（Infrastructure as Code：Terraform / CDK）へ
- アプリの設定も、パイプラインも、監視のルールも、ドキュメントすらも、次々とコードになった
- そして極めつけに、図（アーキテクチャ図・シーケンス図） すら、Mermaid や PlantUML で"テキスト"になった
いわゆる Everything as Code への収束です。そしてこの流れを、Gitによる履歴管理とCI/CDが下支えしてきました。「diffが取れる」「レビューできる」「テストできる」「機械が正確に再現する」——このあたりが積み上がって、いまの開発体験がある。
ここに来て、AIによるコーディング、そしてコードを読んでシステムを把握・調査するという営みまでAIがこなすようになりました。
これはもう、Everything as Code の完全な終着点が来たのではないか？
……と、最初は思ったんです。でも、少し立ち止まって考えるほど、「終着点」という言葉が怪しくなってきました。この記事はその思考の記録です。判断は読んでくださった皆さんに委ねたいと思います。
「ゴールが来た」と思った理由
素直に整理すると、こう見えます。
すべてがコードという機械可読なテキストとして表現されるようになった。だからこそ、そのテキストを大規模に読み書きできるAIが、この世界の「最後のピース」としてはまった——。
特に効くのが「コードを読んでの把握・調査」の部分です。
- Terraformで書かれたインフラは、人間もAIも読める
- コンソールでポチポチ作ったインフラは、人間もAIも追えない
システムが source of truth としてコードに集約されているからこそ、AIがそれを解読できる。この噛み合い方は、確かに「ゴールに到達した」と感じさせるだけの説得力があります。
でも、ここから2つの角度で揺さぶってみます。
角度①：AIは、これまでの流れと「逆向き」の性質を持ち込んでいる
Everything as Code が追い求めてきた本質的な価値は何だったか。
決定性・再現性・レビュー可能性です。
コードを共通言語にしたのは、diffが取れて、テストでき、機械が正確に実行できるから。要するにこれは「曖昧さと手作業を排除する」運動でした。同じ入力からは同じ結果が出る、という約束の上に成り立っている。
ところが、自然言語のプロンプトからコードを生成するという行為は、同じ入力から違う出力が出うる非決定的な層を、その上に乗せる行為です。
つまりAIコーディングは、方向性としてはこれまでの「曖昧さを削る」流れと、ある部分では真逆の性質を持ち込んでいる。だから「これまでの流れの純粋な終着点」と一枚岩で捉えてしまうと、この摩擦を見落とします。同じ矢印の先端ではないのです。
角度②：因果が逆かもしれない——AIは「ゴール」ではなく「基盤の上の利用者」
ここがいちばん面白いところだと思っています。
Everything as Code は、別にAIを目指して進んできたわけではありません。でも結果的に、AIが動くための最良の基盤（substrate）を用意してしまった、という見方ができます。
システムが機械可読なテキストとして表現されていればいるほど、AIはそれを大規模に読み解ける。裏を返せば、GUI操作で作られた「コードになっていない現実」は、AIにとってもほとんど手が出せない。
つまり、
- as code と AI は、頂点と底辺の関係ではなく、相補的な関係
- AIは「流れの頂点に立った王様」ではなく、「as codeが敷いたレールの上を走る、新しい種類の利用者」
このほうが、実態に近い気がします。
補強：図すら「コード」になっていたことの意味
冒頭でさらっと触れた「図が Mermaid / PlantUML でテキストになった」は、この角度②の話をきれいに補強します。
かつてアーキテクチャ図といえば、Visio やパワポで描くバイナリの成果物でした。diffは取れない、レビューは「見た目を目視で比較」、そして何より——機械には中身が読めない。
それがいまや、こう書けます。
この図は、レンダリングすれば人間が読める図であると同時に、そのままテキスト＝コードです。Gitでdiffが取れ、PRでレビューでき、そしてAIが読み書きできる。
つまり「図をコード化する」という一見ニッチな進化は、単なる利便性ではなく、"人間だけが解釈できた最後の領域のひとつ"を機械可読な source of truth の側へ引き込んだ出来事でした。Everything as Code の "Everything" が、また一歩ぶん広がった——そしてそのぶん、AIが噛める面積も広がった、というわけです。
「完全」と言い切れない残余
「終着点」を疑うべき理由を、もう少し具体的に並べます。
1. 検証への依存は、むしろ増す
AIは"それらしい"コードを出します。問題は、それが本当に正しいか。そして、それを捕まえる装置こそが——テスト・型・CI・レビュー・履歴、すなわち Everything as Code が積み上げてきた規律そのものなんです。
だからAI時代において、この規律の価値は下がるどころか、上がる。ここはかなり確信を持って言えます。
2. ボトルネックは「書く」から「レビューする」へ移った
そして、これは現場で今まさに起きている、生々しい話です。
AIによってコードを書くコストは劇的に下がりました。しかし、そのレビューコストは、ほとんど下がっていない。むしろ増えています。
結果として何が起きるか。
- 生成量が増える → PRの数と粒度が膨れ上がる
- レビュアーの人数と時間は、そう簡単には増えない
- レビューが新たなボトルネックになり、マージ待ちのPRが積み上がる
しかも厄介なのは、AI生成コードのレビューが質的にも重くなる点です。人間が書いたコードなら「この人はここを分かって書いている」という前提が効きますが、AI生成コードは"それらしく動いてしまう"ぶん、レビュアーが本当に意図通りか・落とし穴がないかを、より深く疑ってかからねばならない。「一見きれいなのに、要件を微妙に外している」を見抜く負荷は、決して軽くありません。
これは肌感覚ではなく、データが出ている
当初この節は「現場の肌感覚」として書いていたのですが、裏を取ったられっきとした調査結果でした。
まず Google の DORA レポート（2024） の有名な知見。AI活用が25%増えるごとに、デリバリのスループットは推定約1.5%低下、システムの安定性は推定約7.2%低下する、というものです。回答者の約4割が「AI生成コードをほとんど／まったく信頼していない」とも答えています。個人の生産性は上がっているのに、システム全体では改善しない——この一見矛盾した結果の一因が、下流に溜まるレビュー・テスト・デプロイの詰まりです。
そして DORA 2025 はここをさらに踏み込み、DORAの研究者自身が「コードレビューは長年ボトルネックであり続けている。AIで書く量が10倍・100倍になっても、レビューする能力は上がらないので、レビューはむしろさらに厳しい制約になる」という趣旨の指摘をしています。DORAは対策として、小さいバッチ（＝小さなPR） と強固なバージョン管理を繰り返し推奨しています。
定量的な裏付けとしては、Faros AI が2025年に1,000超のチーム・1万人超の開発者を分析した調査が分かりやすいです。AI活用度の高いチームは、タスク完了は21%増・マージされたPRは98%増と生産性が上がった一方で、PRのレビュー時間は約91%増、平均PRサイズは約154%増、バグは約9%増。しかも組織レベルのDORA指標には目立った改善が見られなかった、という結果でした（出典：Faros AI, 2025）。
※数値の出典は、DORAの割合値は Google Cloud / dora.dev の2024年公式発表、PR関連の定量値は Faros AI の2025年テレメトリ調査です。DORA自身が「レビュー時間◯%増」と数値を出しているわけではない点だけ、正確を期して補足しておきます。
つまり——AIは開発の律速段階を、書く工程からレビュー工程へ移動させただけとも言えます。全体のスループットを上げたければ、次に効くのは「いかに速く大量に書くか」ではなく、「いかにレビューを速く・確実に回すか」。ここでも効いてくるのは、テスト・型・CI・小さなPR分割・レビュー観点の明文化といった、Everything as Code の規律です。
これはまさに、AIが「ゴール」ではなく「新しいボトルネックを生む始まり」だったことの、いちばん分かりやすい証拠だと思います。
3. 「なぜ」はコード化されていない
コードに写るのは what と how です。しかし why——要件の背景、意思決定のトレードオフ、なぜこの設計"ではない"案を捨てたのか——は、多くの場合どこにも書かれていません。
AIはコードから why を"読める"わけではない。組織の暗黙知は、依然としてコードの外側にあります。
4. コードの外の領域は、しっかり残る
- データそのもの：スキーマはコード化できても、中身は別物
- 実行時の状態
- セキュリティの敵対的境界
- インシデント時の判断
- 組織のプロセスや政治
5. 歴史は「各時代がゴールに見えた」の連続
VCSも、IaCも、CI/CDも、登場した瞬間は「これで開発は完成だ」に見えました。「完全なゴール」という finality（最終性） の感覚は、経験則としてはむしろ疑ってかかるべきサインなのかもしれません。
提案するメンタルモデル
というわけで、「ゴールに到達した」ではなく、こう置き換えるのが正確だと考えています。
コードが
source of truthである地位はそのままに、その"著者"が、人間から AI＋人間 へと移り変わる局面
こう捉えると、角度①の摩擦も、残された残余も、無理なく収まります。
そして、ここから先に本当の論点があります。
コードという層は、このまま残るのか？
それとも、自然言語で書かれた「意図（spec）」が真のsource of truthになり、コードはアセンブラのように"もはやレビューしない生成物"へと退いていくのか？
ここはまだ、まったく決着していません。もし後者に振れたなら、それは Everything as Code の終着点ではなく、上書きということになります。
ちなみに、さきほどの「レビューがボトルネックになる」問題は、この論点と地続きです。生成されたコードを人間が一行ずつ追い切れなくなったとき、私たちは何をレビューの source of truth にするのか。コードそのものか、それを縛るテストと型か、あるいは意図（spec）か——ボトルネックの置き場所を決めることが、そのまま「何を真実の源とみなすか」の選択になっていくのだと思います。
だから、こう言いたい。
AIコーディングはゴールではなく、始まりだった。
Everything as Code が用意した機械可読な世界の上で、ようやく次のゲームが始まったところなんだと思います。
おまけ：とはいえ、まだコード化が難しいものたち
「Everything」as Code と言いつつ、正直まだコードに落とし込めていない（あるいは、落とし込みにくい）ものを、備忘録的に挙げておきます。異論・追加、大歓迎です。
| 領域 | なぜ難しいか |
|---|---|
| 意思決定の "why" | ADR（Architecture Decision Record）で頑張っても、捨てた案・力学・空気までは残らない |
| データの中身 | スキーマは書けても、本番データの実態・偏り・汚れはコードの外 |
| 運用時の"勘" | 「このアラートは無視していい」的な現場知は、Runbook化してもこぼれる |
| 組織・人間関係 | 承認フロー、責任分界、政治。図には描けても再現はできない |
| セキュリティの敵対性 | 守る側はコード化できるが、攻める側の創造性はこちらの想定の外から来る |
| 審美・UX判断 | 「なんかダサい」を満たすテストは、まだ書けない |
コードにできる領域が広がるほど、コードにできない領域の輪郭がくっきり見えてくる——というのが、個人的にいちばん腑に落ちている感覚です。Everything as Code の "Everything" は、たぶんこれからも完全には埋まらない。でも、埋まらない部分がどこかを知っていること自体が、この時代のエンジニアリングなのかもしれません。
おわりに
「AIコーディングは、これまでの技術の流れの終着点なのか？」
私の暫定的な答えは、**「終着点に見えるが、実は次の始まりだ」**です。とはいえ、これはあくまで一つの見方にすぎません。同じ流れを眺めても、「やはりゴールに近い」と感じる方もいれば、「そもそも前提が違う」と考える方もいるはずで、いろんな考え方があっていいテーマだと思っています。
ここまでお付き合いいただき、ありがとうございました。この記事が、皆さんがご自身の立ち位置を考えるための、ちょっとした叩き台になれば嬉しいです。