AIがコードを書く時代の「理解」を、3か月追ってみる

他部門から、自分たちのシステムについて問い合わせを受ける。以前なら、関連しそうな処理やデータを思い浮かべて、その場である程度の見当をつけられた。ところが、すぐには答えられず、問い合わせの文章をAIへ渡し、コードベースを調査してもらう場面がある。そんな悩みを見聞きすることが増えたし、私自身もたまに「自分が担当してたはずの、ここってどうなってたっけ」と思い出せなくなるときがある。

AIを使うこと自体が問題なのではない。自分の中に仮説がなく、どこを調べればよいかも分からないまま、AIの報告を待っている状態は、果たして健全といえるのだろうか。 AIが詰まったとき、人間もどこから手を付ければよいか分からなければ、ソフトウェアエンジニアとして責任を取れない。

この違和感を、これから3か月かけて調べてみることにした。

システムのどこを、どの深さまで、人間が理解し続けるべきか。そしてAIによる変更速度が上がっても、その理解をどう維持するか。

現時点では、すべてのコードを説明できることより、異常時に調査範囲を狭められることが、開発者に必要な理解ではないかと考えている。この仮説を、実際の開発で確かめたい。

なぜこの問いに取り組むのか

きっかけは、お盆に友人と会ったことだった。新しい挑戦へ向けて動いている友人を見て、燻っている自分との差を感じた。話しているうちに、「自分が絶対に作れないものを作る」というテーマで、8月31日までに次の目標を決め、公表することになった。

AIを使えば、以前より短い時間で実装を動かせる。実際、仕事でも個人開発でも、その恩恵を受けている。一方で、AIに要件を渡し、localhost:3000で画面が表示されても、以前ほど自分で作った手応えを得られなくなった。

最初は、技術的にもっと難しいものを選べばよいと考えた。しかし、AIが実装できないほど難しい題材を探しても、モデルが賢くなれば境界は移動する。難しさを実装量だけに求める限り、同じことを繰り返しそうだった。

そこで、何を作るかを考える前に、自分が何を面白いと思ってきたのかを具体的なエピソードを起点に振り返った。

学生時代、ひとりで厳冬期の北海道を自転車で走ったときは、旅そのもの以上に、情報の少ない環境を調べ、装備を試し、現地で次の行動を決めることが楽しかった。小学生の頃に自作していたTRPGや今ハマっているランニングにも、自分で攻略法を考え、結果を見て修正する面白さがあった。一方、たまに勉強している数学の圏論には、分からない概念と格闘し、以前とは違う構造で対象を見られるようになることを求めていた。

ここから、自分を動かすものを二つに分けた。

攻略と実験：自分で目標と攻略法を考え、現実から返ってくる結果を見て、次の一手を決める
認識の拡張：分からない概念と格闘し、以前とは違う構造で対象を見られるようになる

AI時代のソフトウェア理解は、この二つが重なる。システムの構造を理解し直しながら、現場で仮説を試し、結果を受け取れるからだ。自分がすでに仕事で困っている一方、正解も解決方法も分からない。問い合わせや障害対応から、短い周期でフィードバックも得られる。

さらに、人間から理解や意思決定権を奪わないという、自分が技術に求める価値にもつながっている。この条件なら、3か月を使ってみたいと思えた。

実装過程が担っていた学習

AI以前にも、自分が理解・把握していないコードは存在した。私が違いを感じるのは、理解していないコードが増える速度である。

少なくとも私にとって、調べ、設計し、書き、デバッグする過程は、コードの場所や依存関係を覚える機会でもあった。実装作業は成果物を作るだけでなく、システムの索引を頭の中へ作っていた。

AIは、その過程をまとめて短縮できる。生産速度が上がる一方で、実装を通じて得ていた理解まで省略することがある。

ただし、速度だけを原因にすると見誤る。人間が設計を考えたあと、AIが短時間で実装しても、理解を保てる可能性はある。反対に、AIと長く対話していても「いい感じにやって」と任せ続ければ、成果物だけが増えていく。

問題はAIが速いことだけではない。人間が理解と意思決定の過程から外れたまま、変更だけが積み上がることではないか。

理解とは、探索範囲を狭められること

ここでいう理解は、すべてのコードを逐行説明できることではない。

不具合や問い合わせが起きたとき、関連する業務、処理、データ、依存関係を思い浮かべ、調査する範囲を自分で狭められることを指す。そのうえでAIへ「この処理の流れと条件を確認してほしい」と頼めるなら、細部を覚えていなくてもシステムへ介入できる。

人間の頭に必要なのは、コードベースのコピーではない。今のところ、次のような索引と粗い因果関係ではないかと考えている。

主要な業務概念
顧客が目的を達成するまでの重要な流れ
システムの境界と依存関係
重要な設計判断と、その理由
変更したときに影響が及びそうな範囲
詳細が必要になったとき、どこへ行けば取得できるか

ドキュメント、テスト、設計記録が十分にあれば、人間は理解しなくてもよいという考えには、まだ納得できていない。膨大な情報が外部に残っていても、異常時にどこから読めばよいか分からなければ、制御を取り戻すまでに時間がかかる。

もちろん、すべてを個人の記憶へ入れることもできない。外部へ残した情報と、人間が持つ索引をどう組み合わせ、変更に合わせて更新するかが問題になる。

この必要なときに制御を取り戻せる能力を、ひとまず介入可能性と呼ぶ。

理解の範囲をどう決めるか

人間の理解を守ろうとして、生成されたコードをすべて読み直すなら、AIによる生産性向上と衝突する。理解の濃さは、システム全体で同じでなくてよいはずだ。

競争力に直結しない定型的なデータ処理や補助機能は、相対的にAIへ委譲しやすい。一方、事業の中核となる業務ルールや、顧客の目的達成を左右する処理、不具合が大きな損失へつながる箇所は、人間が厚く理解したほうがよい。

この区分も、まだ仮説にすぎない。どの領域が中核かは事業ごとに異なり、技術的に単純な処理が運用上の急所になることもある。

さらに、必要なのは担当者一人が全体を理解することとも限らない。大きなシステムでは、誰か一人が全体を把握する前提を置けない。

個人のメンタルモデル、チーム内の知識分散、設計記録、テスト、ログやメトリクス、担当範囲、AIが参照する文脈を組み合わせ、組織として介入可能性を維持できればよいのかもしれない。

自分で掌握したいという私個人の好みと、責任ある開発に本当に必要な条件は分けて考える必要がある。この境界も、3か月で確かめたい。

これから3か月で試すこと

最初の2週間から3週間は、解決策を作らず、理解が置いていかれた瞬間を集める。仕事やOSS開発の中で、何が起きたか、自分はどこまで予測できたか、AIへ何を調べさせたか、どこで介入できなくなったかを注視する。

次にそれらを「理解できている」を観察可能な能力へ分ける。問い合わせへ回答できる、変更の影響範囲を予測できる、障害時に仮説を立てられる、AIの提案をレビューできるといった行為で測れる形にしたい。

そのうえで、システムの重要度と、人間が保持する理解の深さを対応させる。中核の業務、顧客にとって重要な処理の流れ、それ以外の領域で、何を頭に残し、何を外部化し、何をAIへ任せられるかを比較する。

最後に、理解を維持する仕組みを実際の開発へ入れて試す。設計記録、テスト、ログやメトリクス、担当範囲、AIへ渡す文脈などが候補になるが、どれを作るかはまだ決めない。調べたことは、必ず仕事かOSSの現実へぶつける。

結果として、ツールやOSSを作るかもしれない。開発チームの運用方法や、設計の考え方に落ち着くかもしれない。そもそもの問題設定が間違っていたと分かる可能性もある。

11月30日になったら、この文章と実際にやったことを照らし合わせる。何を作ったかだけでなく、介入可能性を観察できるようになったか、自分やチームの理解を維持する方法が見つかったかを振り返りたい。

「自分が絶対に作れないものを作る」という宿題に、まだ成果物の名前では答えられていない。それでも、自分がすでに困っていて、答えも進み方も分からず、現実からフィードバックを得られる問いは見つかった。

この文章は、2026年8月31日時点のスナップショットである。たぶん、いくつも間違っている。 3か月後の自分が遠慮なく修正できるように、今の考えをここへ置いておく。