💡なぜエンジニアは『重さ』に慣れてしまったのか

IDEの肥大化と「引き算の美学」が示す開発環境の未来

私が社会人になった2007年、AIXのターミナルでviエディタを使いながらシステム開発をしていた頃、マウスを使えない環境に最初はストレスを感じていました。しかし、lsコマンドやgrepコマンドを駆使してキーボードだけで作業することに慣れてくると、その軽快さと集中力に驚かされました。

それから18年。開発環境は劇的に進化し、統合開発環境（IDE）は驚くほど高機能になりました。しかし同時に、私たちは「重さ」に慣れてしまい、本来の開発の本質を見失っているのではないでしょうか。

ここ2年近く、CursorやWindsurfといった最新のAIエディタを使い込み、様々な仕組みを作ってきました。正直、CLIベースのツールがこれらの高機能AIエディタを上回ることなど想像もしていませんでした。

しかし、Claude Codeを使ってみて、その考えは完全に覆されました。軽快さに加えて、AIエージェントとしての自立した能力の高さ、指示した内容に対するタスク生成から実行までの質の高さは見事としか言いようがありません。最近では社内PoCのためのツール開発でも大活躍しています。

この記事では、私の実体験を交えながら、開発環境の「重さ」がもたらす隠れたコストと、AIエージェント時代に本当に必要な開発環境の姿について深掘りしていきます。同じ悩みを抱えるエンジニアの皆さんに、新たな視点と実践的なヒントを提供できれば幸いです。

⚠️ IDEの肥大化の歴史：機能追加の罠

「全部入り」思想の誕生

2000年代初頭、Eclipseの登場は革新的でした。エディタ、デバッガ、ビルドツール、バージョン管理ツールが統合。開発者は複数のツールを行き来する手間が省けました。

これは素晴らしい進歩です。しかし、「IDEには全ての機能が入っているべき」という思想も同時に生まれました。

プラグイン地獄の始まり

「足りない機能はプラグインで追加すればいい」
「このプラグインも便利そうだから入れてみよう」
「あのプラグインも必要かもしれない」

気がつくと、IDEは何十ものプラグインで膨れ上がっていました。起動に30秒、時には1分以上。メモリ使用量は1GB、2GBと増え続け、それでも「これが現代の開発環境だ」と受け入れていました。

「重さ」を正当化する理由づくり

私たちは重いIDEを使い続けるため、様々な理由を作り出しました：

• 「高機能だから重いのは当然」
• 「一度起動すれば一日中使うから起動時間は問題ない」
• 「メモリは安くなったから8GB、16GBあれば大丈夫」
• 「複雑な開発には複雑なツールが必要」

本当にそうでしょうか？

📊 「多機能=良い」という思い込みの検証

実際に使っている機能は何％？

正直に考えてみてください。あなたが日常的に使っているIDEの機能は、全体の何％でしょうか？

私の経験では、日常的に使う機能は全体の20％程度です：

日常的に使う機能（80%の時間）

• ファイル編集
• ファイル検索・置換
• ターミナル実行
• 基本的なデバッグ
• Git操作

たまに使う機能（20%の時間）

• 高度なデバッグ機能
• リファクタリングツール
• プラグイン固有の機能
• 統合テストツール

ほとんど使わない機能（残り多数）

• 複雑なプロジェクト管理機能
• 高度なプロファイリング
• 統合されたドキュメント生成
• その他のプラグイン機能

パレートの法則と開発ツール

80対20の法則（パレートの法則）は開発ツールにも当てはまります。私たちの生産性の80％は、ツールの20％の機能から生まれています。

それなのに、なぜ私たちは残り80％の「使わない機能」のために、起動時間の延長やメモリ消費量の増加を受け入れているのでしょうか？

🔍 AIエディタ vs CLIツール：予想外の結果

2年間のAIエディタ体験

この2年間、私はCursorやWindsurfといった最新のAIエディタを積極的に使ってきました。AI支援によるコード生成や修正は驚くほど便利でした。

しかし、同時に課題も感じていました：

重さの問題

• 起動時間の長さ
• メモリ使用量の多さ
• 複数プロジェクトの同時作業の困難さ

複雑さの問題

• 多機能すぎて迷うことがある
• AIの提案が多すぎて選択に迷う
• 設定項目の多さ

LLM性能向上がもたらした新たな課題

• LLMの能力向上により、任せられる作業のボリュームが増加
• 一つの作業に対する生成時間が長くなり、待ち時間が増加
• IDEでは基本的に1プロジェクト＝1LLMのため、じっと出力を眺める時間が増えた

Claude Code：AIエージェントとしての質的違い

Claude Codeを使って最も驚いたのは、AIエージェントとしての自立能力の高さでした。

Cursor/Windsurfの場合

• 開発者がコードを書く際の「補助」役
• 提案されたコードを選択・修正する必要
• 細かい指示が必要

Claude Codeの場合

• 指示を理解し、タスクを分解して自動実行
• 最初から最後まで一貫した作業を自立して完了
• 社内PoCレベルのツール開発も任せられる

実際の社内PoC開発での体験

最近、社内のPoC（概念実証）ツール開発でClaude Codeを活用していますが、その能力には驚かされます：

従来のAIエディタでの開発

1. 要件を整理
2. ファイル構成を考える
3. 一つずつファイルを作成しながらAIに相談
4. エラーが出たら修正を依頼
5. 統合テストで問題発見→修正

Claude Codeでの開発

1. 「○○の機能を持つツールを作って」と指示
2. 自動でタスク分解とファイル構成を決定
3. 一気に実装完了
4. 動作確認も含めて完了

この違いは革命的です。AIが「補助」から「エージェント」に進化したことを実感します。

LLM性能向上時代の新しい課題：「待ち時間問題」

しかし、LLMの性能が向上し、任せられる作業のボリュームが増えてきたことで、新たな課題が浮上していました。

従来のAIエディタでの制約

• 1つのプロジェクト = 1つのLLMインスタンス
• 大きなタスクの実行中は他の作業ができない
• コード生成を「じっと眺めている」時間の増加
• 複数プロジェクトの並行開発が困難

この「待ち時間問題」は、LLMが優秀になればなるほど深刻化します。以前は簡単なコード補完だった作業が、今では数分かかる大規模な実装になっているからです。

Claude Code：並列実行による革命的解決策

Claude Codeで最も衝撃的だったのは、この問題を根本から解決していることでした：

同一プロジェクトでの並列作業

• フロントエンド開発用のClaude Code
• バックエンド開発用のClaude Code
• テストコード作成用のClaude Code
• ドキュメント作成用のClaude Code

複数プロジェクトの同時進行

• プロジェクトAの実装をClaude Codeに任せつつ
• プロジェクトBの設計を別のClaude Codeで相談
• プロジェクトCのデバッグを3つ目のClaude Codeで実行

これにより、「待ち時間」という概念そのものが消失しました。一つのタスクの実行を待つ間に、他のタスクを進められるからです。

💡 Claude Codeが示す「引き算の美学」

軽さがもたらす4つの価値

最近Claude Codeを使い始めて、改めて「軽さ」の価値を実感しています：

1. セットアップが簡単
複雑な設定ファイルも、プラグインの互換性チェックも不要。すぐに開発を始められます。

2. 軽い
起動時間は数秒。メモリ使用量も最小限。マシンのリソースを他の作業に使えます。

3. 複数の同時起動が可能
異なるプロジェクトを同時に開いても、システムが重くなりません。さらに重要なのは、同じプロジェクトに対しても複数のClaude Codeインスタンスを起動し、並列でタスクを実行できることです。これにより、LLMの長い実行時間中の「待ち時間」が解消されます。

4. SSH接続が便利
リモートサーバーでの開発も、ローカルと同じ感覚で行えます。

「引き算の美学」とは

Claude Codeの設計思想は、「引き算の美学」を体現しています：

• 必要最小限の機能に絞る
• 一つ一つの機能を確実に動作させる
• 軽量性を最優先に設計する
• AIとの連携に特化する

これは、日本の茶道や禅の思想に通じるものがあります。無駄を削ぎ落とし、本質だけを残す。その結果として、美しさと機能性を両立させます。

AIと軽量ツールの相性：エージェント時代の到来

生成AI時代において、開発ツールに求められる役割も根本的に変化しています：

従来のIDE中心の開発

• IDEが全ての機能を提供する
• 開発者がツールを操作する
• ツール依存の開発スタイル

AIエディタ時代の開発

• AIが開発を補助する
• 開発者とAIが協調する
• AI補助型の開発スタイル

AIエージェント時代の開発（Claude Code）

• AIが自立してタスクを実行する
• 開発者は指示と判断に集中する
• AI主導型の開発スタイル
• 複数のAIエージェントによる並列実行が可能

Claude Codeは、まさに第三段階の「AIエージェント時代」を体現しています。軽量なCLIインターフェースでありながら、AI自身が高度な判断と実行を行い、さらに複数のエージェントが並列で動作することで、従来の「待ち時間」という制約から完全に解放されます。これにより、開発者は本来の創造的な作業に集中できるようになります。

⚠️ 重いツールがもたらす隠れたコスト

時間コスト

起動時間のコスト

• 重いIDE：起動30秒×1日10回 = 1日5分
• 軽いツール：起動3秒×1日10回 = 1日30秒
• 差：1日4.5分 → 年間約27時間の差

コンテキストスイッチのコスト
重いツールは複数起動が困難なため、プロジェクト間の切り替えに時間がかかります。

集中力コスト

起動を待つ30秒間に、私たちの集中力は散漫になります。「ちょっとメールをチェックしよう」「Slackを見てみよう」こうして、本来の作業から離れてしまいます。

リソースコスト

重いIDEはマシンリソースを大量に消費します。その結果：

• 他のアプリケーションが遅くなる
• バッテリー消費が増える
• より高性能なマシンが必要になる

🎯 軽量ツール選択の指針

選択基準の提案

開発ツールを選ぶ際の新しい基準を提案します：

1. 必要最小限原則
本当に必要な機能だけを提供しているか？

2. 起動速度原則
5秒以内に使い始められるか？

3. リソース効率原則
同時に複数起動しても問題ないか？

4. 拡張性原則
必要に応じて機能を追加できるか？（ただし、デフォルトは軽量）

実践的アプローチ

1. 現在のツールの棚卸し

• 実際に使っている機能をリストアップ
• 使用頻度の低い機能を特定

1. 軽量化の実験

• 一週間、軽量ツールだけで開発してみる
• 生産性の変化を測定

1. 段階的移行

• 新しいプロジェクトから軽量ツールを導入
• チーム全体での段階的移行

📊 まとめ：開発環境のパラダイムシフト

18年前、AIXの軽量なCLI環境で感じた軽快さ。2年間のCursorやWindsurfでのAIエディタ体験。そして今、Claude Codeでの衝撃的な体験。

これらの経験を通じて見えてきたのは、開発環境における3つの時代の変遷です：

第1世代：重厚なIDE時代

• 「全部入り」の思想
• 重さを機能の証とする価値観

第2世代：AI補助時代

• AIがコード生成を支援
• しかし依然として重厚なエディタベース

第3世代：AIエージェント時代

• AIが自立してタスクを実行
• 軽量なインターフェースで最大の結果

Claude Codeは私たちに重要な問いを投げかけています：

「本当に必要なものは何か？」
「重いツールに慣れることで、私たちは何を失ったか？」
「AIエージェント時代の開発環境はどうあるべきか？」

2年間最新のAIエディタを使い込んできた私でさえ、「CLIベースのツールがこれほど優秀だとは想像もしていませんでした」。特に、LLMの性能向上により生まれた「待ち時間問題」を、複数のAIエージェントの並列実行で解決するアプローチには驚かされました。

答えは明確です。私たちは「引き算の美学」に立ち返る時が来ました。軽量で、素早く、AIが自立して動き、さらに並列で動作する環境。それこそが、創造性と生産性を最大化する次世代の開発環境なのです。

重いツールに慣れてしまった私たちエンジニアにとって、軽量ツールへの回帰は単なる選択肢ではありません。それは、AIエージェント時代の開発パラダイムを受け入れるための必然的な進化なのです。

---

この記事は、18年の開発経験と最新のAI開発ツールの実使用体験に基づいて執筆されています。あなたの開発環境選択の参考になれば幸いです。

あなたの開発環境に対する考えや、軽量ツールへの移行経験があれば、ぜひコメントで教えてください。共に学び、より良い開発環境を追求していきましょう！