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によってさらに強くなり、弱いシステムは相対的にさらに弱くなる。AIネイティブを謳う新興ツールがデファクトを崩すのは、こと日本においては思ったより難しい気がしている。

Notionはさらに成長する

最後に、私見を一つ。この文脈で言うと、Notionの成長はまだ続くと思っている。

PLGでユーザーを獲得し、SLGへ転換してエンタープライズに拡大し、今や多様な規模の組織に浸透している。特に直近では、慶応義塾大学全学への導入など、これから世に出ていくビジネスパーソンが、より若いタイミングで触るOSになりつつある。

こうした学生にとっては、Notionが初めてのAIタッチポイントになり得る。

実際、2月末から自分もNotionのカスタムエージェントを使い始めた。毎週チームの活動成果を自動レポートさせる仕組みを作ってみたが、セットアップは驚くほど簡単だった。既に情報がNotionにあるから、新たにデータを接続する手間がほぼない。これが「場所」の力だ。

創業者のIvan氏は単なるプロダクトビルダーではなく、先程のGTMの変遷など大きなChangeを生み出せる人だと思っている。

AI時代においてMoatがさらに広がる可能性を感じている。ドキュメント、データベース、プロジェクト管理が一体化した場所にAIが入る。情報が既にそこにあるからこそ、エージェントは即座に価値を発揮できる。

さいごに: 人間がやることは変わらない

つらつらとAIエージェントの話を書いてきたが、たくさんのエージェントを使うようになった今でも、結局のところ「必要は発明の母」というのが自分のスタンスだ。

AIによって発明のハードルは下がっても、それを超える人は元々超えたかった少数の人だけ。

そしてその中でも本当の「必要」を握れている人は少ない。相対的に、「必要なもの」を正しく定義し、握れる人が強くなる。

以前の記事でも触れたが、要件の明確化、アーキテクチャの判断、品質基準の設定は人間の大事な役割として残っている。

AIがどれだけ賢くなっても、何を、どのくらい高度に作るべきかを決め、それが十分かどうかを判断するのは人間だ。

むしろAIが普及するほど、その構造は強まっていく気がしている。