AI がより多くのコードを書く時代に、なぜ私たちはなお理解する必要があるのか

私は、人々がコードを理解するのを助ける製品を AI で作りました。

ところが興味深いことが起きました。製品が複雑になるほど、私自身はそれを理解できなくなっていったのです。

FiboCode を作り始めたのは 2025 年 7 月ごろです。当時は Vibe Coding が広がり、AI でコード作成を支援し、ソフトウェア開発のコストを下げることが盛んに語られていました。そこで自然に一つの考えが浮かびました。

AI がコードを書くのを助けられるなら、コードを理解することも助けられるのではないか。

コードを書くコストは下がり続けていますが、見知らぬプロジェクトを理解する苦労は変わりません。長年存在し、複雑なディレクトリ構造、モジュール依存、過去の設計判断、さまざまな規約を持つコードベースでは特にそうです。どこから始めるかを見つけるだけで長い時間がかかります。

FiboCode は、その単純な発想から始まりました。AI でコードを分析して対応するドキュメントと関係図を生成し、コード、ドキュメント、図の間を移動できるようにすることです。

その時点では、単なるコード分析ツールでした。

後にコードについて質問しやすくするため、簡単な Agent を追加しました。コードを読む体験を良くするため Monaco Editor を統合しました。エディターがあればコードナビゲーション、シンボル参照、言語診断も必要に思え、LSP 対応も加えました。

読むことに対応すれば、次は編集することが自然でした。

FiboCode がコードを変更できるようになると、現在開いている数ファイルだけで判断するのではなく、Agent が本当にプロジェクトを理解するにはどうすればよいかを考え始めました。そこで徐々に MCP と Skills を加え、AI がプロジェクトの設計規約、アーキテクチャの背景、履歴にもアクセスできるようにしました。

その後、多くの開発者が Claude や Codex のような Agent CLI にすでに慣れていると気づきました。別の内蔵 Agent よりも、Agent の作業結果をレビューするために設計されたインターフェースのほうが必要かもしれません。

そこで FiboCode にターミナルを追加し、Agent CLI の出力に特化した改善を行いました。ターミナル内のファイル参照、コード変更、実行手順をコード、ドキュメント、関係図へ接続できるようにしたのです。

こうして単純なコード分析モジュールは、一つずつ機能を重ね、ますます複雑なシステムへ成長しました。

自分で作ったプロジェクトを忘れ始めた

AI 支援プログラミングは本当に便利です。

初期のモデルは現在ほど高性能ではありませんでしたが、私は生成されたコードを何度も注意深くレビューしました。モジュールの分け方、データの流れ、アーキテクチャがそう設計された理由を確認していました。

開発中、プロジェクトは何度もリファクタリングされました。大規模なものもありましたが、当時は設計の詳細を理解していたため、最終的にプロジェクトを壊すことはありませんでした。

やがてモデルの能力が上がり、コード生成が速くなり、コードベースも急速に成長しました。

すると、一、二週間前にレビューしたコードの設計詳細さえ思い出せないことに気づきました。

最初は少し怖く感じました。

これは自分のプロジェクトです。すべての機能は自分から生まれたのに、各モジュールがなぜその形に設計されたのか、すべてのロジックがどう動くのかを思い出せなくなっていました。

時間がたつにつれ、それは受け入れるべきことなのかもしれないと思うようになりました。

もはや初期の小さなプロジェクトではありません。十分に複雑なシステムでは、誰もすべての実装詳細を覚えられません。本当に大切なのは、全行を頭に入れることではなく、システムの中核がどこにあり、モジュールがどう協調し、どこを安全に AI に任せられ、どこを慎重に理解すべきかを知ることかもしれません。

私は選ぶ方法を学ぶ必要がありました。

大量のコードから重要な経路を見つけ、システム全体のおおまかな心象を作り、そのうえで AI により正確な要件と制約を与える必要がありました。

この観点では、FiboCode は私が FiboCode を作ることも助けていました。

AI で製品を開発し、製品が役立つようになり、その製品が今度は自身をより速く理解して改善する助けになる。この好循環は本当に刺激的で、長く取り組み続けられた大きな理由でした。

しかし、その興奮の先で、私は何度も自分に問いかけました。

この開発プロセスで、自分に何が残っているのだろう。

思考の多くを AI に渡したとき

長い時間をかけて、私はある習慣を身につけました。

要件があれば、まず AI に渡す。

問題があれば、まず AI に調査させる。

AI が解決策を示したら検証し、失敗すれば結果を返して、もう一度分析と修正を頼む。

要件を AI に説明し、バグの現状を伝え、テスト結果を返すことを繰り返すだけで、一日が終わることもありました。

難しい知的作業のほとんどを AI が行い、自分の役割は要件を決めて結果を返すだけになったように見えました。

その時期、私は強く感じていました。

自分には、もうあまり価値がないように思えたのです。

しかし続けるうちに、それは正しくないと分かりました。

AI と開発する中で、以前なら学ぼうとしなかった多くの技術や、幅広い実装方法に出会いました。そして具体的な実装を見る前に、設計とアーキテクチャを意識して確認するようになりました。

小さな範囲のタスクなら、AI に直接任せられるとすぐ判断できます。

一方、複数モジュールにまたがるタスクやプロジェクトの中心構造に影響するタスクは、単純ではないとすぐ分かります。AI は目の前の要件だけを見て、過去の設計が存在する理由や、変更が間接的に影響する領域を知らないかもしれません。

AI が書けるとしても、ほぼ完全に理解しておくべきコードもあります。そこで問題が起きれば、結果を制御しにくいからです。

私はすべての実装詳細を理解することには固執しなくなりましたが、システムの境界、依存、リスク、変更にはより敏感になりました。

人間の仕事は消えたのではなく、形を変えているだけなのかもしれません。

以前は、自分でコードを実装することでシステムを理解しました。

これからは、反復的な実装にかける力を減らし、アーキテクチャ、プロセス、制約、検証、長期的な進化へより多くの注意を向けるのかもしれません。

AI が書けることと、信頼できることは同じではない

将来、AI が人間の専門家を本当に置き換え、すべてのプログラミング作業を担えるのかは分かりません。

それは技術の問題ですが、同時に信頼の問題でもあると思います。

いつか AI が高度に複雑なシステムを独力で生成できても、無条件で信頼できるとは限りません。

システムが予想外に動いたとき、理由が分かるでしょうか。

エラーを特定できるでしょうか。

修正を検証できるでしょうか。

別の人が引き継げるでしょうか。

システムが深刻な被害を起こしたら、誰が責任を負うのでしょうか。

これらの問いは、モデルの精度を 99% から 99.9% に上げるだけでは完全に解決できません。

低リスクで置き換えやすいアプリケーションなら、より多くのブラックボックスを受け入れられます。機能が動き、開発が十分速ければ、すべての実装詳細を気にする必要はないかもしれません。

しかし OS やデータベースのような基盤ソフトウェア、あるいは金融、電力など社会に大きな影響を持つシステムでは、理解も監査も引き継ぎもできないブラックボックスを受け入れるのは困難です。

こうしたシステムには、なお人間による保守が必要です。

その人々が全行を自分で書く必要はありません。しかし誰かがシステムのおおよその仕組み、重大なリスクの場所、問題が起きたときの調査開始点を知っていなければなりません。

だから私は、AI プログラミングが広がってもコード理解はなくならないと、ますます強く考えています。

ただ別の形になるのです。

以前は、コードを書くためにコードを理解する必要がありました。

これからは、AI が作ったシステムを検証し、保守し、引き継ぎ、進化させ続けるためにコードを理解する必要があるでしょう。

消えつつある入門レベルの仕事

コード理解には、もう一つの意味があります。

AI は、反復実装や基本作業を中心とする一部の入門職を減らしています。仕事そのものが消えなくても、かつて新人に任せられた作業の多くを AI が先に自動化しています。

これは新人に優しい状況ではありません。

エンジニアの従来の成長経路は、バグを直す、短いコードを読む、小さな機能を完成させる、といった単純なタスクから始まり、徐々に複雑なモジュールやシステム設計へ参加するものでした。

新人は、一見重要でないこれらの仕事を通じて、実際のプロジェクトへの理解を少しずつ育てます。

しかし今では、AI がその基礎的な仕事を直接終わらせるかもしれません。

新人を育てる入口が減れば、未来のシニアエンジニアはどこから生まれるのでしょうか。

これも FiboCode を作った理由の一つです。

私自身もこの職業では新人です。初めて複雑なレガシーコードベースに向き合ったとき、途方に暮れることがよくありました。

ファイルとディレクトリは膨大で、サービス同士が呼び合い、型、インターフェース、設定はあちこちに散らばっています。答えはコードのどこかにあるはずなのに、どこから始め、何が重要で、何が単なる実装詳細なのか分かりません。

本当の難しさは、一行のコードを理解することではなく、完全な地図がないことでした。

私は、まずプロジェクト全体の構造を分析し、中核モジュールがどこにあり、コードがどうつながり、変更がどの領域に影響するかを教えてくれるツールをずっと望んでいました。

そうすれば、新人は誰かに一歩ずつ案内してもらうことだけに頼らず、見知らぬコードベースを何度も手探りする必要もありません。

そのようなツールは成長の過程を代替できませんが、複雑なシステムへ入る壁を低くできます。

AI が古い成長経路を徐々に断ち切る中で、FiboCode が別の道をつなぎ直せればと思っています。

すべての基礎を飛ばす近道ではなく、地図やナビゲーション、そして新人がシステムのメンタルモデルをより早く作るための道のようなものです。

コードが記録するのは現在だけ

開発中、別の問題にも気づきました。

タスクをそのまま AI に渡し、リポジトリを独自に調査させると、考慮が不完全になることがあります。

AI は現在のコードを見ることはできますが、なぜモジュールが特定の形に設計されたかを知らないかもしれません。無関係に見える別ファイルと間接的につながっていることにも気づかない可能性があります。

コードは通常、システムが今どう見えるかは教えられますが、なぜその形になったかを説明するのは苦手です。

最初は、こうした情報をすべてコードコメントに入れようと考えました。

しかし後に、それは適していないと判断しました。

大量の設計背景、過去の判断、変更説明を入れればコードファイルは膨れ、AI に現在のタスクと無関係な文脈を大量に与えることになります。コメントは局所ロジックの説明には向きますが、プロジェクト全体の進化を運ぶのは困難です。

そこで一連の Fibo Skills を設計しました。

それらはプロジェクトの規約、設計、実装プロセス、diff の説明を記録し、各コード変更により完全な足跡を残します。

将来 AI がコードを変更するとき、現在の状態だけでなく、過去に何が起き、なぜ特定の設計が守られたかも理解してほしいと考えています。

プロジェクトの進化の歴史を追跡できれば、AI はプロジェクトをより完全に理解できます。

これは FiboCode が徐々に向かった方向の一つにもなりました。

もともとは人がコードを理解するためのものでした。後には、AI がコードをよりよく理解することも助け始めました。

FiboCode が現在の姿へ成長するまで

振り返ると、FiboCode は最初から現在の姿になるよう設計されたわけではありません。

単純なコード分析モジュールとして始まり、ドキュメントと関係図、Agent、エディター、言語サービスが加わりました。その後、コード編集、ターミナル、MCP、Skills も徐々に備えました。

Agent CLI に Cursor のようなコードレビュー体験を与えながら、コード分析が生み出すドキュメントと関係情報を AI が実際に利用できる文脈へ変えたいと考えました。

単純なモジュールから複雑なシステムへ進化する継続的な成長は、Fibonacci 数列が広がる姿と静かに重なりました。

FiboCode という名前とカタツムリのイメージも、そこから生まれました。

カタツムリの殻には、黄金螺旋の数学的な美しさがあります。

速くは動きませんが、前へ成長し続けます。

FiboCode は、人々に再び全行を手で書かせようとしているのでも、AI を締め出そうとしているのでもありません。

むしろ逆です。AI がより多くのコードを書くことを受け入れ、その前提の上で、人々が自分のシステムを理解し、検証し、保守し、引き継ぎ続けられるようにしたいのです。

誰もがより速い生成を追う時代でも、時には立ち止まれればと思います。

なぜコードがそのように動き、なぜシステムが今の姿になったのかを理解するために。

そして、私たちを最初にプログラミングへ引きつけた喜びを、もう一度見つけるために。