Atsushi Nakatsugawa
April 23, 2026
1 min read
April 23, 2026
1 min read
共有
The IDE Is No Longer the Center of Software Developmentの意訳です。
数十年にわたり、ソフトウェア開発の中心にはIDE（統合開発環境）がありました。IDEはエンジニアリングが行われる場所であり、コードが書かれ、デバッグされ、洗練されてから世に送り出される場所でした。それはコックピットでした。それ以外はすべて二の次でした。
しかし、エンジニアリング作業が始まる場所と完了する場所の間のギャップは、何年も前から広がり続けています。今日では、単一のツールがカバーするように設計された範囲を超えて、より多くのシステム、より多くのチーム、より多くのタイムゾーンにまたがっています。
シニアエンジニアが典型的な一日で実際に何をしているかを考えてみてください。仕事はSlackスレッド、バグレポート、アーキテクチャの議論、顧客のエスカレーションから始まります。それがチケットに反映されます。そして誰かのターミナルに到達します。開発者が本当の作業を始める頃には、誰も見つけられないPRDから、3つのスレッドの奥に埋もれた決定事項、一人が書いて共有されなかったランブックまで、コンテキストを手動で再構築するのに20分を失っています。
IDEが関与するのは、そのワークフローのおそらく一つのフェーズだけです。残りはGit、CI/CDパイプライン、モニタリングツール、分析プラットフォーム、インシデント管理システム、そしてチームが使っているメッセージングツール全体にわたって展開されます。
IDEを開く頃には、本当の作業のほとんどはすでに別の場所で行われています。
AIがこの状況に何をもたらすか
高性能なAI、特に構造化されたインターフェースを通じて外部システムとやり取りできるAIの登場は、異なる可能性をもたらします。
十数個のツールを行き来して全体像をつなぎ合わせる代わりに、エンジニアが単一の会話型インターフェースを通じてオペレーショナルエコシステム全体とやり取りすることが可能になっています。質問をすれば、システム全体から統合されたコンテキストが得られます。インシデントを調査すれば、モニタリング、デプロイ履歴、コードから相関するシグナルを一つのスレッドで取得できます。修正を準備し、その影響をレビューし、調査を開始した環境を離れることなく対応を調整できます。
これは新しいIDEではありません。まったく異なるインタラクションモデルです。
これは、オペレーショナルインターフェースに近いものです。コードを、すべてが組織化される中心的なオブジェクトとしてではなく、より大きなシステムの中の多くの成果物の一つとして扱うものです。本質的に、AIはコードを安価にし、コンテキストをより高価にしています。
ここが、現在のAIコーディングツールの波が部分的には正しいものの、そこで止まってしまうポイントです。
今日のほとんどのコーディングエージェントは、個々の開発者のターミナルをすべての中心として扱っています。典型的なシーケンスは次のようになります：
チームの残りのメンバーには、何が起きたのか、なぜ起きたのか、途中でどのような決定がなされたのかが見えません。ただ作業は完了し、知識は失われます。
一部のツールは、チームが手動で管理する永続的なナレッジファイルでこれに対処しようとしています。しかし、すでにコンテキストを失いつつあるチームでは、ナレッジファイルを最新の状態に保つのが困難であり、そもそもの解決策ではありません。それは同じ問題の別のバージョンでしかありません。重要なチームコンテキスト、つまり火曜日のインシデントスレッドで下された決定や前のスプリントで議論されたアーキテクチャのトレードオフは、Markdownファイルには入りません。散在するか、失われるかのどちらかです。
一つのセッションに存在する知識はスケールしません。退職し、チームを変わり、あるいは単純に忘れられ、組織はそのコストを静かに蓄積します。再構築されたコンテキスト一つずつです。
非同期のディスパッチモデルはこれを悪化させます。タスクを送って待ちます。何かが返ってきます。正しいかもしれません。正しくないかもしれません。いずれにしても、あなたはコントロール能力を失っています。イテレーションループは遅く、フィードバックサイクルは壊れており、チームの残りのメンバーはPRが現れるまで何が起きているか分かりません。
ターミナル中心のモデルは二つの方向で失敗しています。作業はチームから見えないままで、セッション途中での制御は手の届かないところにあります。軌道修正はできず、返ってくるのを待つしかありません。
ソフトウェア開発の実際の作業がSlackスレッド、チケット、インシデント、オブザーバビリティダッシュボード、コード全体にまたがっているのであれば、正しいインターフェースはエンジニアが切り替えなければならないもう一つのツールではありません。それはエンジニアがすでに活動している環境です。
これが新しくリリースされたCodeRabbit Agent for Slackの前提です。CodeRabbitはすでに15,000以上のエンジニアリングチームに対して毎週200万以上のプルリクエストをレビューしています。CodeRabbitは業界で最も高性能なコンテキストエンジンの一つを構築してきました。その肝は、本番環境のスケールで、高品質なコード判断のために適切なコンテキストをどのように組み立てるかを学習してきたエンジンです。Slack Agentはその同じエンジンを、エンジニアリングチームがすでに働いている場所に持ち込みます。
メンタルモデルはコーディングCLIですが、共有され、永続的で、ガバナンスが効いています。スレッドでタスクを開始します。チームがそれを見ることができます。誰かが途中で軌道修正します。作業は可視化され、決定は記録され、知識はあらゆるレベルで持続します。スレッドの中、チャンネルの中、そしてエージェントがあなたのコードベース、チーム、システムについて蓄積していく理解の中にあり続けます。
「開発作業」の意味の変化
これはエンジニアリング組織が開発者の生産性やツール戦略をどのように考えるべきかについて、重要な示唆を持っています。
コードを書くことがワークフローそのものではなく、より大きなワークフローの中の一つのアクションである場合、最も重要なツールは必ずしもテキスト編集に最適化されたものではありません。エンジニアにシステムの状態を理解し、それに対してアクションを取るための最も明確で最速のパスを提供するものです。
これにより、いくつかのカテゴリの作業に関する判断基準が変わります：
調査とデバッグ。 シニアエンジニアの時間の大部分は、新しいコードを書くことではなく、既存のシステムがなぜ予期しない動作をするのかを理解することに費やされています。ログ、トレース、最近のコミット、過去のインシデントを横断的に推論できるインターフェースは、より良いコードエディタより潜在的に大きな価値を持ちます。
メンテナンスと運用作業。 エンジニアリングタスクのロングテール、つまり設定のドリフトの修正、顧客から報告されたバグへの対応、既知の脆弱性を持つ依存関係の更新は、コードの執筆よりもはるかに多くのコンテキスト取得を伴います。ファイルではなくシステムを中心としたインターフェースは、この作業の効率を変えます。
小さな修正とターゲットを絞った変更。 すべてのコード変更が深いローカル開発を必要とするわけではありません。多くの場合、何をなぜ変更するかを理解し、適切な場所を特定し、外科的な編集を行うことが求められます。その調査と実装が、バグが報告されたのと同じSlackスレッドで行えるとき、ワークフローは大幅に圧縮されます。
エンジニアリングリーダーにとっての意味
エグゼクティブやCTOにとって、実践的な示唆は次のとおりです。優れたエンジニアは、常にツールに依存しない存在でした。エディタは重要ではありませんでした。今後数年間で高パフォーマンスのエンジニアリング組織を差別化するものは、オペレーション環境がどれだけうまく接続されているか、そしてその共有レイヤーの上にどれだけの推論能力が存在するかです。
ガバナンスの問題も同様に重要です。ほとんどのコーディングエージェントは、支出とアクセスを個々のユーザーに委ねています。これはスケールにおいてカオスを生みます。基本的な質問に誰も答えられません：
これらの質問にチーム、チャンネル、ワークスペース単位で答えられないなら、ガバナンスはありません。あるのはシャドーAIインフラです。
CodeRabbitのモデルはエージェントのアイデンティティをGitHubに紐づけ、チャンネルごとにツールとメモリのスコープを設定し、チャンネルおよびワークスペースレベルでコストを帰属させます。インシデントチャンネルはオブザーバビリティスタックと運用手順書にアクセスできます。HRチャンネルはエンジニアリングログにアクセスできません。これはメモリとツールを単なるプロダクト機能ではなく、パーミッションとして扱うものであり、AIエージェントの利用を本番環境の他のシステムと同じように管理する必要があるエンジニアリング組織にとって唯一機能するモデルです。
自社の環境を評価する際に、検討すべきいくつかの質問があります：
開発者ツールを主にIDEの問題として扱っている組織は、エンジニアリングの速度をますます左右するインフラレイヤーへの投資が不足している可能性が高いです。
技術的な観点から、この変化を可能にしたのは二つのことが合わさった結果です。異なる種類のコンテキストを横断的に推論できるAIモデルと、AIシステムが外部ツールに構造化された構成可能な方法で接続できる標準化されたインターフェース、MCPおよび類似のプロトコルの登場です。
その結果、かつて各チームがオーダーメイドのスクリプトやカスタムツールを通じて手動で組み立てていた統合レイヤーは、AIがエンジニアに代わってナビゲートできる接続されたオペレーショナルグラフとしてますます表現できるようになっています。
これはエンジニアが自分のシステムを深く理解する必要性をなくすものではありません。むしろ、インターフェースが優れた判断力と誤った前提の両方を増幅するため、要求水準は上がります。システムを理解しているエンジニアは、この種のインターフェースを使ってより速く動けるようになります。理解していないエンジニアは、間違った答えに向かってより速く動くでしょう。
今取り組む価値のある技術的な作業は、接続基盤への投資です。具体的には、システム間のクリーンなAPI、モニタリングとオブザーバビリティにおける構造化されたデータ、そして意味のある履歴を持つ整理されたリポジトリです。エージェントインターフェースは、接続先のシステムの品質に依存します。
IDEは、ソフトウェア開発が主にローカルな活動であった時代、コードが多かれ少なかれシステムそのものであり、開発者の主な仕事がそれを書くことであった時代には、正当な重心たる存在でした。
その時代は完全に終わったわけではありません。しかし、後退しつつあります。
今日のソフトウェアシステムは大規模で、分散的で、深く相互接続されています。それらを運用する作業は、新しい命令を書くことと同じくらい、生きたシステムを理解し対応することでもあります。そしてその作業を可能にするチームコンテキスト、つまり決定事項、インシデント履歴、アーキテクチャの根拠は、常に個々のターミナルではなく、共有のコミュニケーションチャンネルに存在してきました。
その現実に適合する開発者インターフェースは、非同期ではなく同期的であるべきです。個人のものではなく共有されるべきです。制御なしではなくガバナンスが効いているべきです。そして、セッションごとに消えるのではなく、時間とともに蓄積されるコンテキストの上に構築されるべきです。
これはツールの小さな変更ではありません。開発環境が何を意味するかの変化です。この変化を早期に認識し、それを支える接続されたオペレーショナルインフラを構築する組織は、時間とともに複利で増大するエンジニアリング速度の構造的な優位性を持つことになります。
新しいCodeRabbit Agent for Slackを今すぐお試しください！
