Atsushi Nakatsugawa
April 22, 2026
2 min read
Your AI Agent Has Amnesia | CodeRabbitの意訳です。
> スケジュールの破綻やシステムのバグは、左手が右手のやっていることを知らないために起こる - フレッド・ブルックスが『人月の神話』で、IBM OS/360プロジェクトを沈没寸前に追い込んだ調整の失敗について述べた言葉です。
『人月の神話』は、エンジニアリングマネジメントにおいて最も人気のある書籍の一つであり、リーダーの本棚の定番であり続けています。
SDLCの50年にわたる進化は、その失敗モードに対する長い反論でした。アジャイルは開発者をプロダクトと同じ部屋に置きました。DevOpsは開発と運用の間の壁を取り除きました。Gitとプルリクエストは、何が変わり、なぜ変わったかの共有記録をチームに提供しました。CIはビルドを全員の問題にしました。プラットフォームチームは、部内知識を新しいメンバーが毎回再獲得しなくて済むように、整備された道を構築しました。あらゆる主要な変革は、個人の英雄的行為に対する共通理解への賭けでした。
そして、コーディングエージェントが登場し、私たちは後退しました。
すべてのエンジニアがプライベートなエージェントを、自分のマシン上で、誰にも見えないセッションの中で実行しています。エージェントは毎朝何も知らない状態から始まります。昨日組み立てた推論も、検討した代替案も、読み込んだコンテキストも、朝会で決めたことも、すべて消えています。プロセスは崩壊し始め、「これまで以上に速くデリバリーしている！」という誤った等価性を生み出します。
ブルックスが説明していたのは、数週間かけてバラバラになっていく人間のチームでした。私たちは今、1日の作業日の中でバラバラになるAIチームメイトを追加し、それを高い生産性と呼んでいます。
新入社員でさえ、昨日学んだことは覚えています。
最近、あるシニアエンジニアがコーディングエージェントに1行のコードを書かせる前に、11分間コンテキストのセットアップに費やすのを見ました。彼はアーキテクチャを説明し、なぜPostgresやその他のものを使っているかを解説しました。最終的に、3つのファイル、Linearのチケット、そしてあるサービスが廃止予定であるというテックリードからのSlackメッセージのコンテキストを貼り付けました。
エージェントはコードを書きました。実際、かなり良いコードでした。
そのシニアエンジニアは最終的に、翌朝新しいセッションを開いて、別のコンテキストのためにおそらくまた一からやり直すだろうと述べました。エージェントにはチームレベルの洞察が欠けているのです。
これが2026年のAI支援開発です。
エージェントが作業を始める前に何を知っているかについて、誰も語っていません。
問題の正しいフレーミングは、平凡な思考者を優秀な思考者のように機能させます。少なくとも人間においては。AIエージェントの場合、そのギャップはより大きくなります。同じモデルが同じプロンプトを与えられても、作業対象のシステムを理解しているかどうかで、大きく異なるコードを生成します。
コンテキストなしでコードベースをエージェントに渡すと、もっともらしく見えるが、チームが2年かけて確立したすべての規約を無視したコードが得られます。同じエージェントに、コードベースに加えてアーキテクチャ上の決定、チケット履歴、オンコール対応手順書、旧認証サービスの廃止を決めたSlackスレッドを渡すと、チームメイトが書いたようなコードが得られます。
現在、開発者はセッションごとにそのコンテキストを手動で組み立てており、自分のエンジニアリング組織と、すでに知っているべきツールとの間の通訳として機能しています。
コンテキストの問題は最も目に見える症状ですが、病気はより全身に渡っています。現世代のエージェントが忘れてしまう方法は少なくとも5つあります。
すべてのセッションは、システムや選択に関するコンテキストなしにコールドスタートします。エージェントがファイルを開いても、なぜチームがキューにRedisではなくPostgresを選んだのか、どの認証サービスが廃止予定なのか、前四半期にエラーをラップせず、そのままエスカレーションさせると決めたことも知りません。しかし、そのコンテキストは、誰も読まないPRDの中、3月のSlackスレッドの中、シニアエンジニアの頭の中に存在しています。開発者が毎朝最初にすることは、それをプロンプトに変換することです。
繰り返しますが、開発者は会社の他の場所にすでに存在する情報を再構築し、個人セッションに限定されたコンテキストウィンドウに追加しているのです。
昨日教えたエージェントは、今日使っているエージェントではありません。課金モジュールについてエージェントに説明しました。間違っているように見えるが実は正しいリトライロジック、StripeのWebhookでidempotencyキーを信頼できない理由、そして警告としてgit履歴に残っている去年の夏に失敗したリファクタリングについてです。良いコードが生成されました。
タブを閉じました。残っているのはコミットだけです。そこに至った推論（実際に残しておきたい部分）はセッションとともに消えました。翌週同じファイルを開けば、また同じことを繰り返すことになります。
追記：そう、agents.mdや他の永続的なナレッジベースに保存・共有していることでしょう。しかし、それはチームの日常業務で簡単にメンテナンスできるほど、重要なチームコンテキストを収集するために継続的に更新されていますか？
コーディングエージェントはシングルプレイヤーです。一人の開発者、一つのセッション、一台のマシン。その作業はチームの他の誰にも見えません。何かを引き継ぐ必要がある場合、チームメイトはゼロから始めます。なぜなら、引き継ぐ先がないからです。
私たちは10年かけて開発をコラボレーティブにしてきました。Git、プルリクエスト、共有CI、そして誰でも開けるダッシュボード。そして私たちは、開発をサイロ化するAI開発ツールを構築してしまったのです！
エージェントがコードを書き、PRになり、コードレビューを通過します。次のスプリントで、誰かがそのコードの半分を書き直し、1ヶ月後にはそのコードにバグが発生し、本番環境を断続的にダウンさせます。エンジニアはSlackやGitHub上で協力してリグレッションを修正します。
あなたのエージェントは、これらすべての決定のループから外れています。
エンジニアはコードをデリバリーし、レビューされ、デプロイされ、壊れ、修正されることで成長します。各段階で、チームと個人にとっての集合的な学びがあります。エージェントをそのループから外すと、「もっともらしい」コードのどの形式が実際に本番環境との接触に耐えるかを学ぶことなく、もっともらしいコードを無期限に生成し続けるエージェントが残るだけです。
わかりました！CLI、IDE、または他の新しいフォームファクター（ADE？！）を問わず、すべての開発者がローカルAIコーディングエージェントを実行することを止めることはできません。しかし、エンジニアリング組織には、チーム全体でエージェントが何をどのように実行しているかの共有ビューがありません。どのシステムに触れているのか？どれだけのコストを使っているのか？
経済性がすぐにその問題を突きつけるでしょう。Uberの CTOは今年、The Informationに対して、チームが2026年のAIコーディング予算全体をすでに使い果たしたと語りました。
エージェントの記憶喪失は、本質的に経済性の問題になりつつあります。各エンジニアにもうけたトークン消費が毎日複利で積み重なることは、エンジニアリングチームにとって解決が困難な問題です。なぜなら、ここまでの生産性向上から離れることができないからです。
あなたにとっては、個人的には、あなたのマシン上では、そうでしょう。
ターミナルエージェントが機能しないとは言っていません。明らかに機能しています。Claude Code、Codex、素晴らしいツールです。そして、私たちはそれらを置き換えようとしているわけではありません。
実際、ステアリングコントロール、サブエージェントフレームワーク、フック、プラグインなどの機能は、開発者にとって非常に有用であり、これまで以上に多くのコードを生成する助けとなっています！
明確にしておくと、これらのツールにはメモリがあります。Claude CodeはプロジェクトレベルのCLAUDE.md、ユーザーレベルのものを読み込み、セッション間で保持されるローカルメモリディレクトリにメモを保存します。
失われているのは、ローカルのエージェンティックコーディングセッションにおける永続的なチームナレッジです。シニアエンジニアが苦労して得た課金モジュールの理解は、その人のMarkdownファイルの中、その人のノートPCの中に存在しています。異なる地域の同僚が最初のセッションを開いたとき、そのいずれも引き継がれず、永続化されません。
エドガー・W・ダイクストラはこう書きました。有能なプログラマーは、自分の頭蓋骨のサイズが厳密に有限であることを十分に認識している、と。エージェントには頭蓋骨がありません。忘れる必要がないのです。私たちがエージェントを忘れるようにしてしまったのは、チームが実際に作業する永続的な環境ではなく、一時的なターミナルセッションをモデルにしたからです。
記憶喪失を所与のものとして扱うのをやめたとき、次世代はこのようになります。
ナレッジは複利で増えるべきです。 一人の開発者のマシン上に残るコンテキストファイルではなく、すべてのコードレビュー、解決されたチケット、アーキテクチャ上の議論が、エージェントを今日よりも来月さらに有用にするレイヤーに供給されるべきです。これは、チーム、プロジェクト、ドメインごとにスコープされた共有ナレッジレイヤーです。新しいエンジニアが参加したとき、エージェントはすでに、おそらく数人のシニアエンジニアの頭の中にだけ存在していた組織的記憶を持っています。
作業は永続的で、再開可能であるべきです。 Slackスレッドでタスクを開始します。中断されます。チームメイトに引き継ぎます。2日後に戻ると、作業はまだそこにあります。可視的で、コメント可能で、適切なアクセス権を持つ誰でも再開できます。一人の開発者のラップトップ上のブラウザタブに閉じ込められていません。
エージェントは、本番環境にアクセスする他のシステムと同様にガバナンスされるべきです。 今日のほとんどのコーディングエージェントは、シートごとに価格設定され、ユーザーごとにスコープされています。支出は開発者が消費したものでしかありません。アクセス制御はツールのデフォルトに依存しており、通常は「すべて可能」です。組織全体でエージェントが実際に何をしているかの可視性は、ほぼゼロです。すべてのエンジニアに本番環境へのroot権限を与えることはしないでしょう。AIエージェントに組織全体のコンテキストへの全アクセス権を与える理由もありません。
コンテキストは手動で貼り付けるのではなく、あらゆる場所から自動的に組み立てられるべきです。 エージェントはコードベース、チケット、ドキュメント、オブザーバビリティスタック、クラウドインフラ、そしてチームが時間をかけて構築したナレッジから情報を引き出すべきです。開発者の仕事はエージェントを指揮することであり、リサーチアシスタントになることではありません。
コーディングエージェントに対する不満の第1位は、使い捨てのコードを生成することです。手戻りが多すぎて、実際にマージできるようになるまで何度もやり直しが必要になる。しかし、最初のパスでより良いコンテキストがあれば、最初のパスでより良いコードが得られます。
本日、CodeRabbit Agent for Slackを発表します。
まずは重要なループから始めます。プランニング、コード生成、レビュー、調査、そしてナレッジ強化型開発です。ソフトウェア開発ライフサイクル全体のための一つのエージェント。すべてがSlack内で、同期的に、ガードレールを備えて動作します。
しかし、将来的なビジョンはSlack上のコーディングエージェントよりも大きなものです。
私たちが目指しているのは、SDLC全体にわたるエージェンティックレイヤーです。システムを理解し、ツールを接続し、チームのナレッジを保持し、エンジニアリングワークフローをE2Eで実行するレイヤーです。
エージェントはリーチできるコンテキストと実行できるアクションによってのみ有用であると私たちは信じています。
最終目標は、スタックを接続し、チームがすでに働いている場所からプログラマブルにするレイヤーです。
AIを採用しているすべてのエンジニアリングチームで、個人の生産性は向上しています。チームレベルの生産性はまだ停滞しており、それはモデルの品質とは無関係の3つの理由で停滞しています。エージェントが実際に何をしたかの説明可能な記録がないこと、チームの組織に合ったコスト配分がないこと、そしてエージェントがエンジニアリングが実際に行われる場所に存在しないことです。これらを解決すれば、チームの生産性は個人の生産性がすでにそうであるように、複利で増え始めます。
勝利するエージェントは、最高のモデルを持つエージェントではありません。開くときにすでにあなたのシステムを知っているエージェントです。規約、廃止予定のもの、ドキュメントに載らなかった決定。それが永続的なチームナレッジであり、今日公開されているすべてのツールに欠けているものです。
これが開発者を置き換えるとは言いません。本番コードをリリースしたことがあるなら、エンジニアリングの難しい部分はタイピングではないことをご存知でしょう。それは判断力です。システムを理解することです。何を構築すべきで、何を構築すべきでないかを知ることです。
これは、CodeRabbitで何年も賭けてきたことです。独立した専用のコンテキストエンジン、週に200万件のコードレビューを実行し、優れたエンジニアリングチームが実際に行っていることをエンコードしてきました。CodeRabbit Agentはそのエンジンを、チーム独自の決定とパターンを載せてSlackに拡張します。作業はオープンな場で行われ、チームメイトが見て、参加し、誰かが中断した場所から引き継ぐことができます。コンテキストはセッションの終わりに消えるのではなく、複利で増えていきます。
エージェントの記憶喪失を解決したものが勝ちます。記憶喪失のエージェントでより速く構築し続けることは、間違ったものをより速く構築しているだけです。
出典：
図1：出典：Becker, J., Rush, N., Barnes, E., & Rein, D. Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. METR, July 10, 2025; Xu, F., Medappa, P. K., Tunc, M. M., Vroegindeweij, M., & Fransoo, J. C. AI-assisted Programming May Decrease the Productivity of Experienced Developers by Increasing Maintenance Burden. arXiv:2510.10165, 2025.
