2月に個人でClaude Code Maxを契約し、これまでメインのエディタ+コーディングエージェントとして利用していたCursorから、VSCode + Claude Codeという環境に移しました。引き続き楽しくプライベートの開発を行っていますが、そこで感じたことと、AIエージェントの普及について考えたことを書きます。
CursorからClaude Codeへ
2025年は私にとってVibe Coding元年でした。Cursorを1年間使い倒し、このサイトを構築したり、Subagentでニュースレター機能を開発したりと、かなり仲良くなれました。
そのうえで2月、Claude Code Maxを契約しました。理由は後述しますが、まずはその体験について書いておきたいと思います。
Agent Teamで世界が壊れた
Claude CodeにはAgent Teamという機能があります。複数のエージェントを並列に動かして開発タスクを進められる仕組みです。
最初に使ったときの印象は「コスパが悪い」でした。普通にサブエージェントを複数用意してワークフローをつなぐのと大差がない割に、トークン消費が重い。まだプラクティスを掴みきれていませんでした。
ところが数日後、真面目に運用してみたら世界が壊れました。
- まず今後開発していくプロダクトに対して、必要なIssueを全部書き出させる。40個くらい出てきた。
- Issue間の依存関係をタグに打たせる。
- WAVEを分けてAgent Teamで可能な限り並列にせよとプランニングする。
- 競合するファイルはworktreeで環境を隔離する。依存ツリーを書いたうえで、WAVEごとに5体、6体と並列で動かすプランが出てくる。
出てきたプランについては、とりあえずやってみなはれ、と投げました。
5体が並列で動き出す。ものすごい量の承認依頼が飛んできますが、ノールックでポチります。1時間するとPRが5個できています。もはや1体ずつ面倒を見ていたときとは違って、何をしているかすらほぼ把握できません。しかしアウトプットは出ています。CIパスしてれば適切な順序でマージしてくれと伝えます。
ふと思います。あれ、これ俺いる？
並列の限界は人間のチーム開発と同じ
ただし、直列で5回Issue開発させるより5倍早いかというと、そうでもありません。体感で20-50%くらいは早くなりますが、5倍にはなりません。
5本のPRができても、Conflict解消に同じくらいの時間を使うこともあります。そしてこれは人間のチーム開発でも同じだなと思います。
人数をスケールしても、扱うファイルやリポジトリが同じだと、Conflictの処理や、別のPRでの変更を考慮して自身の作業を変えるというタスクが必ず発生します。
オーケストレーションを担当するエージェントが一定の指針を持ってマネジメントしてくれる雰囲気はあります。しかし実際のPRを見ると、マネージできていないことも多いです。これも人間のチームと同じです。
結局、一番効率が高いのは、直列に仕事を潰せて、その精度と速度が高い人やチームが、完全に独立したプロジェクトを担当しているとき。
干渉の対象をいかに狭めるかというゲームなのだと思います。
なぜClaude Codeに移ったのか
Cursorは優れたプロダクトだと思います。
GUIベースのエディタとして、AIとの対話をコーディング体験にシームレスに統合しています。AIコーディングの入り口として、これほど間口の広いツールは他にありません。
しかし私の場合、コーディング作業の大半はターミナルで完結します。gitもnpmもデバッグも全部ターミナルです。Claude Codeはターミナルに住むエージェントなので、既にいる場所から離れなくていいです。エディタを選ばない点はかなり気に入っています。
以前の記事にも書きましたが、道具は使い込まないと手に馴染みません。
Cursorを1年使い続けたことで「こう伝えればうまくいく」「ここは自分で判断すべき」という感覚が身につきました。
Claude Codeでも同じ学習曲線をゼロから登っている最中ですが、Opus4.6というモデルが秀逸なため、これに全部を任せられます。
CursorはマルチモデルをRate Limitに応じて切り替える必要があり、途端に品質が下がることもままありましたが、Claude codeではこれはありません。
コーディングにおける「場所」
また機能の優劣以上に、「場所」の違いはより大きいように思います。
Cursorは新しいエディタという居場所を提案しています。これは場所に対する大きな制約でもあります。
一方でClaude Codeはエディタを選びません。開発者が既にいる場所を強化します。新しい場所に移動させるのではなく、今いる場所をアップグレードします。
これまで慣れ親しんだ同じ場所でタスクを完結できるかどうか。
これは「人間がツールを選択する」という生殺与奪権を持つ以上、最も大きなポイントでもあります。
AIエージェントは「場所」の勝負になっている
この構造は、コーディングに限った話ではありません。
ビジネスパーソンの「場所」はSlack、Notion、Salesforce、会計ソフトといったデファクトのシステムです。日常業務の大半はこれらの中で完結しています。
ここにAIエージェントが入ってくるとき、新しいツールを覚えて使ってもらうのは非常にハードルが高いです。ただでさえ忙しい人たちに、新しいUIの学習コストを負わせるのは現実的ではありません。
特に日本人という新しいものへの適応が遅いビジネス習慣においては、マスへの普及という点では相当不利かと思います。
だからAIエージェントは、既にユーザーがいる場所に入り込む形で普及していくと展望しています。
- MS OfficeにAIが住む
- Google WorkspaceにAIが住む
- SlackにAIが住む
- NotionにAIが住む
- SalesforceにAIが住む
AIエージェントはやはり「デファクトのシステムをさらに強固にする」性質を持っています。
強いシステムはAIによってさらに強くなり、弱いシステムは相対的にさらに弱くなります。AIネイティブを謳う新興ツールがデファクトを崩すのは、こと日本においては思ったより難しい気がしています。
Notionはさらに成長する
最後に、私見を一つ。この文脈で言うと、Notionの成長はまだ続くと思っています。
PLGでユーザーを獲得し、SLGへ転換してエンタープライズに拡大し、今や多様な規模の組織に浸透しています。特に直近では、慶応義塾大学全学への導入など、これから世に出ていくビジネスパーソンが、より若いタイミングで触るOSになりつつあります。
こうした学生にとっては、Notionが初めてのAIタッチポイントになり得ます。
実際、2月末から自分もNotionのカスタムエージェントを使い始めました。毎週チームの活動成果を自動レポートさせる仕組みを作ってみましたが、セットアップは驚くほど簡単でした。既に情報がNotionにあるから、新たにデータを接続する手間がほぼない。これが「場所」の力です。
創業者のIvan氏は単なるプロダクトビルダーではなく、先程のGTMの変遷など大きなChangeを生み出せる人だと思っています。
AI時代においてMoatがさらに広がる可能性を感じています。ドキュメント、データベース、プロジェクト管理が一体化した場所にAIが入る。情報が既にそこにあるからこそ、エージェントは即座に価値を発揮できます。
さいごに: 人間がやることは変わらない
つらつらとAIエージェントの話を書いてきましたが、たくさんのエージェントを使うようになった今でも、結局のところ「必要は発明の母」というのが自分のスタンスです。
AIによって発明のハードルは下がっても、それを超える人は元々超えたかった少数の人だけ。
そしてその中でも本当の「必要」を握れている人は少ないです。相対的に、「必要なもの」を正しく定義し、握れる人が強くなります。
以前の記事でも触れましたが、要件の明確化、アーキテクチャの判断、品質基準の設定は人間の大事な役割として残っています。
AIがどれだけ賢くなっても、何を、どのくらい高度に作るべきかを決め、それが十分かどうかを判断するのは人間です。
むしろAIが普及するほど、その構造は強まっていく気がしています。
