Atsushi Nakatsugawa
March 13, 2026
|1 min read
What devs will still read when they stop reading codeの意訳です。
コードは決して「読まれるため」に存在していたわけではありません。私たちには単に他に選択肢がなかっただけです。
現実世界の例を考えてみましょう。本番環境の決済サービスには、多層的なリトライロジック、冪等性キー、サーキットブレーカー、フィーチャーフラグ、そしてミドルウェアを通じて織り込まれたコンプライアンスチェックがあります。制御フローは技術的にクリーンで完全にテストされているかもしれませんが、意図は条件分岐、デコレータ、ユーティリティの抽象化全体に分散しています。単一の返金処理パスが、5つのファイルと3層の間接参照にまたがることもあります。
機械は決定論的な実行グラフを見ます。人間は散在する分岐と暗黙的な制約を見て、どの失敗モードが許容可能と考えられたのか、どれがビジネスクリティカルだったのか、どれが偶発的な副作用だったのかを再構築しなければなりません。
何年もの間、私たちはコードをソフトウェアにおける最高の真実の形として扱ってきました。システムが何をするのか知りたければ、コードを読みました。何が構築されたか検証したければ、コードを検査しました。この前提は、人が主要な作成者である場合には理にかなっています。しかし、AIエージェントが作成作業の多くを引き受けるようになると（最初はフロンティアチームで、間もなくより広範に）、その前提は崩れ始めます。
私たちは、エージェントがソフトウェアを書く世界に向かっているわけではありません。私たちはすでにその中で生きているのです。エージェントがコードを書き、差分をレビューし、人間が見る前にバグを見つけます。
CodeRabbitでは、毎月数百万のプルリクエストをレビューしており、フロンティア企業において人間が書くコードとAIが書くコードの比率が逆転しているのを目の当たりにしています。今年初めの調査で470のオープンソースGitHubプルリクエストをサンプリングしたところ、320がAI共同作成のPR、150が人間のみのPRでした。
このエージェントAIの利用増加により、バックログに滞留していた機能がプロンプトによって実体化するようになります。数週間かかっていたマイグレーションが一晩で完了します。優先順位を下げられていたリファクタリングが、実際に実行可能になります。
しかし、加速だけでは埋められない、明白なギャップが開きました。
エージェントが生成したコードが最初にコードベースに入り込んだとき、それは魔法のように感じます。20番目のPRになると、システムは不透明に感じ始めます。50番目のPRになると、チームは誰も完全には理解していないが、全員が拡張することを期待される成果物を保守していることになります。生成されたコードは堆積物のように機能します。各層では妥当に見えますが、時間の経過とともに推論が困難になります。「コードを読めばいい」というアドバイスは真剣な助言ではなくなります。それは、より良い記録システムが存在しないために繰り返される儀式になります。
問題はコードの品質ではありません。エージェントはクリーンで、テストされた、局所的に正しいコードを書きます。問題は意図です。コードが特にうまく答えられなかった「人間の」質問がいくつかあります。
なぜこのパターンが選ばれたのか？
どの制約が重要だったのか？
エージェントは明示的に何をしないことに決めたのか？
何をもって完了とするのか？
エージェントは今、このコードの限界を無視できないものにしています。
有用な類似点があります。1950年代、プログラマーはアセンブリを書いていました。レジスタ、メモリアドレス、命令サイクル、つまり完全な仕組みを理解する必要がありました。その後、抽象化レイヤーが登場しました。今日、現役のプログラマーでアセンブリを書く人はほとんどいません。それはすべての下で動作していますが、もはや人間のインターフェースではありません。
コードは新しいアセンブリレベルの言語です。
それはまだ重要です。本番環境はそれで動作しており、マシンはそれを必要としています。しかし人間にとって、コードはほとんどの思考が行われる場所としては低レベルすぎるようになっています。その役割は変化しています。コードはマシンが実行するものになります。人間が理解するものは別のものになります。
その別のものとは、**プラン（Plan）**です。
良いプランは、なぜがどのようにに消える前にそれを捕捉します。前提が見えなくなる前に記録します。トレードオフを読みやすくします。制約を、チーム内の暗黙知ではなく共有されたコンテキストに変換します。人間がレビュー、議論、洗練、承認し、そして戻ることができるものを提供します…数千行の生成されたコードから意図をリバースエンジニアリングすることなく。
この区別は、ソフトウェア作業が本当に困難になる場面で最も重要です。
決済マイグレーションの例を取り上げましょう。シニアエンジニア、PM、またはセキュリティリーダーにとって最も重要な成果物は、最終的な差分ではありません。それは意図です。何を壊してはいけないのか、どのエッジケースがビジネスクリティカルなのか、失敗をどう処理すべきか、どのトレードオフが意識的に受け入れられたのか。計画を立てることで、影響範囲が現実化する前にこうした点を検証可能になります。
またはインシデント修復を考えてみましょう。システム停止後、意図を再構築するのに最悪のタイミングは、プレッシャー下で書かれたコードから行うことです。記録としての明確なプランは、当時何が信じられていたのか、どの緩和策が優先されたのか、何が延期されたのか、「完了」が実際に何を意味していたのかを示します。
またはオンボーディングのようなものを考えてみましょう。過去1年間にエージェントを使って大量に構築されたコードベースに参加する新しいエンジニアは、単に「リポジトリを読め」と言われても困ります。しかし、プランの順序（何が最適化されたか、どこでショートカットが取られたか、どの制約が顧客から来たか、どの前提がまだ未解決か）を見せれば、混乱は理解に変わります。
誤解のコストが高い場所では、プランは実装の詳細だけよりも価値があります。なぜなら、真の作業はコードを生成することではないからです。意味を保存することです。
未来はプロンプトに属するのでも、コードだけに属するのでもありません。プロンプトは短命すぎます。コードは間もなく低レベルすぎるものになります。その間の永続的なレイヤー、人間が実際に推論できるものは、プランです。
プランは、センスが生きる場所です。判断、説明責任、コラボレーションが生きる場所です。
コードは今までより多く書かれるでしょう。しかし、そのコードの多くは、私たちより速く、私たちより安く、自分自身を説明することにあまり興味のないシステムによって生産されるでしょう。ソフトウェア開発を読みやすく、統制可能で、協調的なものに保ちたいなら、人間が保持するためのより良い成果物が必要です。
それが、私たちがCodeRabbit Issue Plannerで構築しているものです。CodeRabbit Issue Plannerは、AIエージェントを使用するチームが、コードが書かれる前に協力的に計画し、意図を調整するのを助けるツールです。曖昧な課題を共有可能でレビュー可能なプランに変換し、コードベースから直接コンテキストを含む編集可能なプロンプトを生成します。しかし、それは、あなたが行った選択と構築しようとしたシステムのアーカイブとして機能する新しい真実のソースでもあります。
これは、より良いプロンプトボックスやコード生成のための単なる薄いラッパーではありません。エージェントの時代における意図のための真の記録システムです。
詩人が自分の詩を構築したものの成果物として見るように、シェフが自分の料理を見るように。同じように、開発者は以前、コードやPRを構築した成果物として見ていました。
しかし、この新しい世界では、それはコードではありません。それはプランになります。開発者が「これが私たちが構築したものです」と指し示す成果物。彼らがチームメイトと共有して自分の成果を示すもの。彼らが評価されるもの。
プランは、今後の開発作業の中心になります。それは、マシンが引き継ぐ前の最後の人間のタッチポイントとして世に出るものです。
Issue PlannerはCodeRabbitのAI駆動開発ツールスイートの一部です。 今すぐ試してください →
