📝 （ポエム）コードの理解を、どこまで手放すか

最近、AIに実装を任せる場面がかなり増えました。

以前なら数時間かかっていたコードが、今では数分で出てきます。テストも書いてくれるし、UIのチェックまでしてくれる。

めっちゃ便利なんですが、ずっと引っかかっていることがあります。

AIが生成したコードは読める。けれど、読んだだけでは、そのコードに対するメンタルモデルが自分の中に形成されない。

この感覚をうまく言語化していたのが、次の記事でした。

AIにコードを書かせると、なぜ理解が頭に残らないのか

この記事では、自分でソースコードを書くと、その過程で対象コードへの「メンタルモデル」が形成されやすい一方、AIにコードを書かせると形成されにくい。その理由が説明されていました。

ここでいうメンタルモデルとは、単にコードの中身を覚えていることではありません。システムがどう動き、なぜその設計になっていて、どこを変えると何に影響するのかという、頭の中の地図のようなものです。

この記事に着想を得て、こんな疑問を持ちました。

AIにコードを書かせると、メンタルモデルが形成されにくいというのは分かった。

そもそも今、僕のようなソフトウェアエンジニアは、どこまで詳細なメンタルモデルを持つべきなのか？

そう、「べき」という、頭と性格の悪そうな軸で自分なりに考えてみます。

先に結論を書くと、答えはめっちゃありきたりです。

現時点では、メンタルモデルを形成し、保つ意味は結構ある

なお、ここで想定しているのは、会社に雇用されていたり、フリーランスや派遣などで開発チームに参加しているソフトウェア開発者です。

一人でプロダクトを運営し、そのリスクを自分でとれる場合は、前提がかなり異なるので対象から外します。そこはもう、自分の責任で好きにやってください。

コーディングの自動化レベル

「開発者がどこまでコードベースへのメンタルモデルを持つ必要があるのか」を考えるには、まず、その現場でコーディングがどこまで自動化されているのかによって変わると思います。

いろいろ調べていると、The Five Levels: from Spicy Autocomplete to the Dark Factoryという記事では、AIによるコーディングの自動化を、自動運転になぞらえてレベル0から5に分けていました。

レベル	運転の自動化	コーディングの自動化
0	人間がすべて運転する	人間がすべてコードを書く
1	車線維持やクルーズコントロールなど、限定された操作だけを車に任せる	テストの作成など、限定された作業だけをAIに任せる
2	高速道路などで自動運転を使いながら、人間も運転に関わる	AIとペアで実装する
3	AIが運転し、人間が安全運転者として監視する	AIが実装し、人間がコードをレビューする
4	行き先を伝えてロボタクシーに任せ、人間は別のことをする	仕様を与えてAIに任せ、あとから結果を確認する
5	運転のプロセスに人間が介在しない	仕様をソフトウェアへ変換するプロセスに、人間が介在しない

※ ちなみに、これは先ほどAIに紹介してもらった記事です。堂々と持ち出すのは少し気が引けますが、時代に免じて許してください。

この区分で境目になるのが、レベル3と4です。レベル3では人間が安全運転者としてコードをレビューしますが、レベル4になると、人間は実装中のAIから離れ、あとで結果を確認します。そしてレベル5では、開発プロセスそのものが、仕様をソフトウェアへ変換するブラックボックスになります。

記事の著者は、このような開発をしている5人未満の小規模チームをいくつか知っており、おそらくこれが将来の姿になると書いています。

They’re small teams, less than five people. [...] it will likely be our future.

レベル5に近い公開事例として、StrongDM AIは、人間がコードを書かず、レビューもしない開発方式「Software Factory」を公表しています。

従来のように人間がAIへ細かく指示してコードを確認するのではなく、人間は「何を実現したいか」と「満たすべき利用シナリオ」を定義し、AIエージェントが実装・検証・修正を繰り返す。そうした「ソフトウェア工場」を作った、という話です。

その仕組みでは

• コードベースとは別に、検証シナリオ（テスト・評価シナリオ）を用意する
• シナリオをどの程度満たしたかという「満足度」で評価する
• 外部サービスの振る舞いを再現するDigital Twin（デジタルツイン）を使ってテストする

といった工夫がされています。

ここで重要なのは、単に人間のレビューをやめたわけではないことです。人間のメンタルモデルにもとづいていた確認を、シナリオや自動検証の仕組みへ移しています。

こうした仕組みが一般化すれば、人間がコードを逐一読まなくても、ソフトウェアの振る舞いを検証できるようになるかもしれません。

レベル2・3におけるコードレビューの必要性

みなさんの開発現場は、コーディングの自動化レベルでいうと、どこにあたるでしょうか？

僕が参加している現場は、レベル2か3に近い状態だと思います。
多くの現場が、同じような状態なのではないでしょうか。

ちなみに、レベル2と3の境界は曖昧です。その境界をめぐって誇ったり、落ち込んだり、罵り合ったり、泣いたり叫んだりしても、あまり意味はないと思います。

当然、AIエージェントにテストコードを書かせ、単体テストやUI操作を含むテストを実行させることもできます。

ただし、テストの条件自体を実装者が綿密に設計していないのであれば、そのテストが通っていたとしても、分かるのは「そのテストに書かれた条件を満たした」ということだけです。

テストが要件を正しく表現しているとは限りません。AIがコードとテストの両方で、同じ勘違いをしている可能性もあります。既存の設計や、テストには現れていない前提と矛盾しているかもしれません。

実際、2026年7月末の段階でも、そうしたことは日常茶飯事だ、というのが僕の肌感覚です。

「いやいや、うちはテストコードを体系的に整備している」という現場もあると思います。

ただ、そのテストが要件や設計を正しく表しているかは、結局、ケースバイケースで人間が確認し、調整する必要があるのではないでしょうか。

だから少なくともレベル2や3では、AIが加えた変更を既存システムのメンタルモデルと照らし合わせ、要件や設計に対して適切なのかをレビューする必要があるのではないでしょうか。

レベル4や5の仕組みを持たないまま、人間の確認だけをなくすことはできません。

なぜ、メンタルモデルの形成・維持にコストをかけるのか

メンタルモデルを形成し、更新するために使う時間は、プロダクト開発におけるコストです。そのコストを払うだけの価値があるのかは、考える必要があります。

多くのソフトウェアエンジニアには、プロダクトを要件に沿って開発し、安定して運用し、必要なときに安全に変更できることが求められます。

「儲かっていれば、作ったものが要件と違っていても、バグろうが、障害で1年中システムが止まろうがどうでもいい」という現場があれば、この記事の想定外です。とはいえ、そんな現場はまれでしょう。

AIがコードの差分を出したとき、エンジニアは、それがコードベースのどこを変更し、どの要件を満たすためのものなのかを確認します。

そのうえで、自分が持っているコードベースのメンタルモデルをもとに、要件に照らして適切か、保守できる水準にあるか、他の機能にどのような影響を与えるかを判断しなければなりません。

障害が起きたときも、疑う場所の見当がつかなければ、調査を全面的にAIへ頼ることになります。AIに調査を任せること自体が問題なのではありません。問題は、出てきた仮説や実行コマンドが妥当なのかを判断する基準を、人間側が持っていないことです。

つまり、メンタルモデルを持つこと自体が目的なのではありません。実装や運用の場面で、適切な判断をするための手段です。

その判断をまだ人間が担っている。だからレベル2や3では、メンタルモデルの形成と維持にコストをかける必要があるのだと思います。

メンタルモデルに含めるのは、判断に必要な範囲だけ

一方で、

AIが生成したコードも、すべて一行ずつ読むべき

という意見も、ネット記事や書籍で見かけます。しかし、AIが大量に生成するコードを一行ずつ注意深く読み、その細部まですべてメンタルモデルに含め続けることは、現実的ではないと感じます。

だから、重要なポイントを押さえてメンタルモデルを作ることが、現実的な落としどころになると思います。

僕が残しておくべきだと考えているのは、コードベースや重要機能の「メンタルモデル」です。

例えば、DBへデータをどう保存し、どこでキャッシュし、どう取り出し、フロントエンドではどう保持して更新するのか。こうした処理のつながりが分かっていれば、変更時に確認すべき場所や、問題が起きたときに最初に調べる場所を考えられます。

一方で、周辺との依存関係を確認したうえで、変更範囲が閉じており、失敗を容易に検知して切り戻せるのであれば、内部実装の細部まではメンタルモデルに含めなくてもよいと思います。期待する入出力やUIの振る舞いをテストで確認できるなら、定型的な処理まで逐一頭に入れておく必要はありません。

メンタルモデルから外してよいのは、影響を判断するために必要な情報ではなく、その判断をしたあとに残る局所的な実装の詳細です。

あえてゆるくまとめるなら、「いま開発している機能と、その土台となるシステムがどう動いているかを、だいたい説明できる」と言える状態です。

メンタルモデルを保つために、AIと小さくペアプロする

レベル2や3の段階で人間がメンタルモデルまで手放せば、それまで人間が担っていた確認が、別の仕組みに置き換わらないまま消えてしまいます。

そこで僕は、冒頭で紹介した記事の著者と同じように、実装を細かい単位に区切り、小さな差分ごとにレビューしてから次へ進むようにしています。

大きな実装を一度に受け取ると、完成したコードは読めても、どの要件に対して、なぜその変更が加わったのかを追いにくくなります。小さな単位で確認すれば、自分のメンタルモデルと実装がずれた時点で立ち止まれます。

もちろん、この方法は、大きな実装を一度に任せるより時間がかかります。それでも、人間が安全運転者であり、人間のメンタルモデルに代わる検証の仕組みもない今は、少なくとも僕にとって必要なコストだと考えています。

まとめ

コーディングの自動化がレベル4や5へ進めば、人間がコードをレビューする機会そのものが減っていきます。その段階では、仕様や検証シナリオを整えたり、AIが自律的に実装と検証を繰り返すワークフローを作ったりすることが、これまで以上に重要になるはずです。

そのため、現時点では次の二つを並行していくのがよいのではないかと考えています。

• 日常業務では、レベル2や3の環境でシステム全体のメンタルモデルを保ち、重要な変更をそこへ反映する。一方で、影響の小さい局所的な実装の詳細はメンタルモデルに含めない
• 個人開発では、レベル4や5に近い「Software Factory」のような開発を試し、人間によるレビューを減らした環境での勘所をつかむ

これが、現時点での自分なりの整理です。

僕の与太話にお付き合いいただき、ありがとうございました。