IDEの死？

• 開発者の作業の重心は、IDEでの行単位のコード編集からエージェントのオーケストレーションと監督のインターフェースへ移りつつあり、Cursor Glass、Claude Code Web、GitHub Copilot Agent などのさまざまなツールがこの転換を加速させている
• 新しい開発ループは**「意図の仕様化 → 委任 → 観察 → diff レビュー → マージ」**という形で、ファイルではなくエージェントが作業単位の中心になっている
• 並列エージェント実行のための作業分離（git worktree）、タスク状態管理、バックグラウンド非同期実行、アテンションルーティングなどのパターンがツール全体で収束しつつある
• エージェントが90%は正しいが微妙に間違う場合のレビュー疲れと、セキュリティ・ガバナンスのオーバーヘッドが新たなコストとして浮上
• IDEは消えるのではなく**脱中心化（de-centered）**されるのであり、精密な検査・デバッグ・高難度作業では依然として中核だが、もはやプログラミングが始まる唯一の場所ではない

---

ファイル編集からワークストリーム操縦へ

• 従来のIDEはファイルを開く → 編集 → ビルド → デバッグ → 反復というタイトな内部ループに最適化されていたが、エージェントがこのループの大半を自律的に実行できるようになり、もはや生産性の支配的な単位ではなくなっている
• 新しいループは**「意図の仕様化 → 委任 → 観察 → diff レビュー → マージ」**という形で、「チャットウィンドウ付きのオートコンプリート」と違うのは、ツール使用の自律性と、その自律性を制御可能にするインターフェースの結合にある
• Claude Code Web（または Desktop）と Codex は、隔離されたクラウド環境で実行されるエージェントに明確に定義された作業を渡し、進捗をブラウザで確認できる — ターミナルやローカル設定は不要
• GitHub Copilot Agentは、複数ファイルにまたがる変更を独立して計画・実装し、ブランチ作成、テスト実行、PR提出まで行い、開発者の主な役割は結果のレビューと反復になる
• Conductorは、複数の Claude Code エージェントを隔離されたワークスペースで同時実行しながら、ライブ進捗モニタリングを提供するデスクトップアプリ
• Google Julesは非同期のバックグラウンド作業処理を行う — 作業を割り当て、完了したら結果をレビューする
• これらのツールが共有するメンタルモデル: エージェントが作業単位であり、ファイルではない — 最適化すべきインターフェースは、より速くタイピングすることではなく、エージェントを指示・監視・レビューすること

形成されつつあるオーケストレーションレイヤー

• 作業分離（Work Isolation）が基本プリミティブとして定着: 並列エージェント同士が衝突してはならないため、ほぼすべての主要ツールがgit worktree（または類似方式）を採用 — Conductor は各エージェントセッションを隔離されたワークスペースにマッピングし、Vibe Kanban もカンバンベースのエージェントワークフローに同じ方式を適用している
• 計画とタスク状態が最上位UI: Vibe Kanban のようなツールは「タブとファイル」を**「タスクと状態」**に置き換える — タスクカード（ランディングページ、バックエンドサービス、メール連携など）を作成してそれぞれをエージェントとモデルに割り当て、軽量なプロジェクトボードのように全体を管理するが、「チーム」は自律的に実行する
• バックグラウンドエージェントと非同期優先設計: Cursor、Copilot、Antigravity などは、実行中にユーザー参加なしで動作するバックグラウンドエージェントをサポート — 意図を定義したら席を外し、完了時にレビューする。Jules も同じ方式で動作し、ユーザーの注意（attention）はプログレスバーを見守るには貴重すぎるという前提に立つ
• 並列エージェントのためのアテンション管理: 多数のエージェントを同時実行する際の真のボトルネックは、今すぐ介入が必要なエージェントを把握すること — Conductor はセッション間のライブ進捗を表示し、cmux はターミナルペインに通知リングと未読バッジを導入 — 「エージェントが注意を必要としている」が開発環境の**一級イベント（first-class event）**として浮上している
• ソフトウェアライフサイクルに組み込まれたエージェント: GitHub Copilot コーディングエージェントは非同期で、制御レイヤーによりセキュリティを確保し、GitHub Actions ベースで動作 — コードの書き方ではなく、実際のコードのデプロイ方法（Issue → PR → CI → マージ）に接続されている
• これらのツールはIDEが無用だと主張しているわけではなく、多くのツールがIDEと相互運用するが、繰り返し現れるパターン（並列ワークスペース、diff優先レビュー、タスク状態、バックグラウンド実行、ライフサイクル統合）こそが、**「IDEの死」**という主張が意味する重心移動そのもの

開発者がなおIDEを求める理由

• 「IDEは死んだ」への最も強力な反論: IDEは精密なナビゲーション、ローカルな推論、インタラクティブなデバッグ、直接操作を通じたシステム理解という難しい問題を、ひとつの高忠実度フィードバックループに圧縮している
• 最も野心的なオーケストレーションツールでさえ手動編集への逃げ道を残している — スレッド内での diff レビュー、変更へのコメントの後にエディタで手動調整するワークフローが意図された設計
• エージェントツール自体が限界を露呈する領域: 大規模リポジトリの複数ファイルにまたがるリファクタリングは、ソフトウェアエンジニアリングエージェントにとって依然として最も難しい挑戦のひとつ — エージェントがコンテキストだけでは完全に再構成できない、システムのメンタルモデルが必要になる場面
• 開発者をIDEレベルの検査に引き戻す失敗モード: エージェントが90%は正しいが微妙に間違っている場合 — 問題を見つけるコストが自分で直接書くコストを上回ることが頻繁にあり、高リスクな変更ではIDEは依然として精密検査のための最適なツール

新たなコスト: レビュー疲れとガバナンスのオーバーヘッド

• 開発が「多数のエージェントを並列実行すること」になると、ワークフローはテキスト編集ではなく分散システム管理の問題を受け継ぐ — 観測可能性（observability）、権限、分離、ガバナンス
• エージェントワークフローは労働を反転させる: コード記述の代わりにレビューが中心となり、1日の終わりに12個の並列エージェントによる12個の diff と向き合うレビュー疲れが現実的な問題になる — 最も慎重なツールがアテンションルーティング、構造化された計画、レビュー優先ゲートに注力する理由
• エージェントがWebブラウジング、データベースクエリ、ファイルシステム書き込み、デプロイトリガーなど、より多くのツールにアクセスするにつれてセキュリティの攻撃面が拡大 — エージェントが何をできるかと同じくらい、何をできるように許可されているかが重要
• 観測可能性と制御の面では、IDE統合エージェントモードはすでに明示的なツールログと承認ゲートの方向へ進化している — エージェントが非同期に動作し、CIパイプラインに触れた瞬間、ガバナンスは選択ではなく必須になる

何が生き残るのか: IDE、コントロールプレーン、それとも両方か

• 「IDEの死」は重心の方向としては正しいが、文字どおりの予測としては誤り
• この主張の最も強いバージョン: IDEは主作業空間の座を退き、複数の下位ツールのひとつになる — 精密検査、デバッグ、最終編集に使われ、計画・オーケストレーション・レビュー・エージェント管理はダッシュボード、Issueトラッカー、観測可能性ターミナル、クラウドコントロールプレーンへ移る
• **「より大きなIDE」**というフレーミングにも同等の根拠がある: 新しい「IDE」は、マルチエージェントオーケストレーション、隔離されたワークスペース、権限と監査ログ、diff優先レビュー、安定したツール接続性、アテンションルーティングを提供するシステム — ファイルエディタは依然として存在するが、もはや正面玄関（front door）ではない
• IDEは死ぬのではなく**脱中心化（de-centered）**される — 作業はオーケストレーションの表層へ移り、人間は意図の定義、並列エージェントランタイムへの委任、監督・レビュー・ガバナンスにより多くの時間を使う
• IDEは正確性、理解、エージェントがなお苦手とする高難度問題において依然として中核だが、もはやプログラミングが行われる唯一の場所ではなく、ますます多くの開発者にとって最初に向かう場所でもなくなっている