はじめに

転職して環境が変わりました。コードベースもチーム文化も前職とは別物で、キャッチアップしながら普通に成果を出すというプレッシャーがそこそこしんどい。

前職では会社支給のCursorを「なんとなくAIエージェントにお願いする」くらいの使い方で、他に配布されていたAIツールもほぼ触らずに放置していました。AIなしでもそれなりに書けていたので、わざわざ使い方を覚える動機がなかった。

今回はそうも言っていられなくて、「AIをフル活用してでもチームのスピードに追いつく」ことを最初から目標にしました。最初は Cursor(実装)+ Claude Code(レビュー・修正) の併用で始めたのですが、運用しながら少しずつ構成を疑い、削り、置き換えていって、最終的に Claude Code 一本(+ サブで Gemini CLI) に着地しました。

その変遷の記録です。

AIの使い方はチーム・プロダクトによって適切なかたちが変わります。この記事はあくまで個人の環境と経験にもとづく話なので、そのままコピペでは機能しないはずです。考え方のひとつとして読んでもらえると。

Before: Copilot単独で起きていた「修正↔レビュー」無限ループ

転職直後は、会社から支給されたCopilotだけで開発していました。自動補完は快適、エージェントもそれなりに動く。ただPRを出すとCopilotレビューが指摘を返してくる。その指摘をCopilotエージェントに直させてpushすると、今度は別の箇所が指摘される。で、また直させる。すると最初に直した箇所に関連するまた別の何かを指摘される。

同じツールなのに、書く側とレビューする側で「それっぽい正しさ」の判断が揺れていて、終わらない。1つのPRで何周もこのループに入って、小さい変更にも時間を吸われていました。

複数ファイルにまたがる実装を頼むと、ファイル間の整合性が崩れて結局自分で直すことも多く、「AIに任せているはずが一番時間を食っている」みたいな状態。

Step 1: Cursor + Claude Code 併用で始めた

開発環境をAIで改善しようと考えたとき、一番試したかったのは Claude Code でした。「レビュー → 修正 → テスト」を問題が解決するまでループで回せるという話に惹かれていて、Copilotレビューの指摘で延々消耗していた自分にはこれ以上ないソリューションに見えた。

ただ、いきなり全振りするのは怖かった。

仕事でフルに使うと ProプランのリミットはすぐKOしそう
かといって、Claude Code を触ったこともないのにいきなりMaxプランを契約するのはさすがに怖い
GUIエージェントとペアで開発するスタイルは前職の Cursor で慣れていて、操作感としてはCursorのほうが信頼できる

このあたりを天秤にかけた結果、Claude Pro + Cursor Pro の併用に落ち着きました。Claude Max 単体より月額が安く、かつ作業を2ツールに分散させればそれぞれのリミットにも到達しにくくなるという算段。

組んだフローはこう。

Cursor のエージェントに実装させる(複数ファイル含む、MCPでタスク管理ツールも連携)
Claude Code にレビューと修正をさせる(push前に)

書き手とレビュアーを別ツールにすることで、Copilot単独時の「自作自演ループ」からは明確に抜けられました。push前にClaude Codeで一段噛ませるだけで、PR後のレビュー差し戻しが目に見えて減った。

Step 2: Claude Code の使用量、想定よりずっと余裕がある

この構成で数日運用していて、Claude Code の使用量が30%程度までしかいかないことに気づきました。リミットに到達する懸念で妥協して Cursor をメインにしたのに、Claude Code 側はかなり余裕がある。

じゃあ、と思って MCPの連携も Claude Code 側に寄せて、実装〜レビュー〜修正を全部 Claude Code でやる構成に切り替えてみました。Cursor は完全に使わない運用。

結果、2週間ほど仕事で使って、5時間ごとのリミットに達したのは1回だけ。

正直、想定外でした。「Claude Code は重いから節約しないと」と勝手に思い込んでいたのが、実際にはぜんぜん足りる。とはいえ無策で投げているわけではなく、ある程度は使用量を意識した工夫をしています。いまやっているのはこのあたり。

スキルをサブエージェント化する:Skill内でサブエージェントを呼び出して処理を分離。サブエージェント側のコンテキストはタスク完了後に破棄されるので、メインのコンテキストを長く保てる。レビュー系スキルはこの構成にしている
MCPから渡す情報を最低限にしてコンテキスト削減:タスク管理ツールから取ってくる情報をチケット本文と必要なフィールドに絞る、関連リンクは明示的に指定したものだけ追う、など。MCPは便利だが何も考えずに連携すると一発で大量にトークンを食う
基本的にSonnetモデルを使う(一部Haiku):Opusは使いどころを絞って、普段の実装・レビュー・修正は Sonnet。コミットメッセージ生成のような軽い定型処理は Haiku に寄せる

それでも正直、自分はまだ Claude Code の経験が浅くて、使用量を抑える工夫はまだまだ甘い自覚があります。/compact でのコンテキスト圧縮タイミングの最適化、Skill側の指示の絞り込み、サブエージェントの粒度設計、このあたりは試行錯誤中。これらをもっと煮詰めていけば、Pro プランでも実用上ほぼ困らないんじゃないか、というのが今の感触です。

Step 3: サブとして Gemini CLI を入れた

会社支給の Google アカウントで Gemini が使えることに気づいたので、Gemini CLI をインストールしてみました。

設定の共有はシンボリックリンクで済ませる方針。

CLAUDE.md を GEMINI.md としてシンボリックリンク
.claude/skills を .gemini/ 側にも見えるようにシンボリックリンク

これで Claude Code 用に整備したルールやスキルがそのまま Gemini CLI でも動きます。

精度は Claude Code には及ばないものの、Copilotよりは明確に上。Claude Code がリミットに到達したときのサブとしてはちょうどいいポジションでした。会社のアカウントでタダで使えるのも大きい。

結果: Cursor は解約予定、Claude Code 一本(+ サブ Gemini CLI)に

整理するとこうなりました。

メイン:Claude Code(実装、レビュー、修正、定型ワークフロー、MCP連携すべて)
サブ:Gemini CLI(Claude Code リミット時のフォールバック)
解約予定:Cursor

念のため書いておくと、Cursor が悪いわけではまったくない。コスパは良いし、前職でも使っていて十分信頼しているし、GUIでdiffを見ながら編集する体験は優秀です。ただ自分には Claude Code のほうが合っていた、というだけの話。

合っていた理由は次の通り。

なぜ自分には Claude Code(CLI)が合っていたのか

CLIが性に合っている

そもそも自分は元 Vimmer で、Git も普段から GUI を使いません。実装はAIに任せ、必要なら一部Vimで直し、git diff で差分を確認して git commit / git push、という流れがすべてターミナルで完結するのが快適。

Cursor を使っていた頃は、Cursor内のターミナルで Claude Code を開くこともできるとはいえ、Cursor のエディタペインと Claude Code のCLI を行ったり来たりする瞬間がどうしても発生していました。一本化してからは、その「行ったり来たり」が消えた。

Skillと相性がいい

Claude Code のSkill機能で、よく使う一連の流れを1コマンドにまとめています。いまあるのはこのあたり。

ローカルレビュースキル:現在のブランチの差分をpush前にレビュー
PRレビュースキル:リモートPRに対してレビューコメントを返す
PR修正スキル:PRレビューの指摘を反映
コミットメッセージ作成スキル:差分から Conventional Commits 風に生成
チケット読み込み&実行計画スキル:チケットIDを渡すと内容を読み込んで実装プランまで作る

レビュー系スキル(ローカルレビュー / PRレビュー / PR修正)は、内部で共通の core-review スキルを呼び出してレビュー処理を行わせる構成にしています。core-review を1箇所修正するだけで、全レビュープロセスが一律で改善される。運用しながら改善していく前提のスキル管理では、この共通化の有無でかなり楽さが変わりました。

設定が `.claude/` に集約される

Cursor 併用時は、Cursor 側の Rules と Claude Code 側の .claude/ を足並み揃えてメンテする必要がありました。片方だけ更新して挙動が食い違う、みたいなプチ事故もあった。

一本化すると管理対象が .claude/settings.json と skills だけになる。シンプルさは正義。

Warpと組み合わせるとIDEを開かなくなる

ターミナルエミュレータをMac純正からWarpに変えました。AI機能はあまり使っていませんが、

変更差分がターミナル上で見やすく表示される
tmuxのような分割画面操作が標準で楽

のおかげで、画面を分割して Claude Code を動かしつつ、別ペインで git diff / git commit / git push が全部ターミナル内で完結する。IDEを開かなくてよくなったので、ウィンドウの切り替えコストもほぼゼロ。

環境まわりでやっておいてよかったこと

CLAUDE.md / AGENTS.md でプロジェクトのお作法を教え込む

最初の数週間、社内のコーディング規約を無視した実装や、ブランチ命名が規約と合わないPRをAIに量産させてしまって、レビューのたびに差し戻しを食らっていました。

CLAUDE.md と AGENTS.md をリポジトリ直下に置いて、以下をまとめています。

ブランチ命名規則(feature/チケットID-... みたいな形式)
命名規約(ファイル・変数・コンポーネント)
スタイルのハードコード禁止、デザイントークンを使う
テストの置き場所とパターン
PR本文のテンプレート

これだけでAIが社内ルールに沿って動くようになって、レビューでの「そこじゃない」コメントがぐっと減りました。「最初にルールを書いてあるかどうか」で出力の質が劇的に変わるのは、想像以上だった。

MCP連携で「プロンプト作成の儀式」をなくした

環境を整える前の自分のタスク着手手順はだいたいこれ。

タスク管理ツールでチケット開いて内容読む
ドキュメント管理ツールの関連ドキュメントを確認
デザインツールの画面をスクショして貼り付け
さらに細かいスタイル(色、余白、フォントサイズ)をデザインツールから拾ってコピペでプロンプトに足す
ようやく「実装して」と言える

これ、実装前の前処理だけで15〜30分持っていかれる。しかも貼り忘れや取り違えで後から手戻りが発生する。

タスク管理ツール / ドキュメント管理ツール / デザインツールをそれぞれMCPで連携してからは、

チケットID XXX-1234 の内容を確認して実装プランを立てて

と投げるだけで、チケット本文や関連ドキュメントを読み込んで実装プランを出してくれるようになりました。チケットIDを指定するだけでプロンプトを書く作業がほぼ不要になったのが一番の変化。デザインツールについてはいまのところ連携してデータを取れるようにしたところまでで、実装に組み込むのはこれから試していく予定です。

AIに任せる/自分でやるの線引き

いまの線引きはシンプルで、実装はAIに任せて、自分は確認だけ。

もっと言うと「自分がやることをなるべく減らして、その時間で別のタスクに取りかかる」を意識しています。で、ここで効いてきたのが git worktree での並行作業。

1タスク目を Claude Code に実装させている間に、別のworktreeで2タスク目の設計を別インスタンスの Claude Code と詰める。1タスク目のレビューが返ってきたら切り替えて対応、みたいな。タスクを倍以上こなせるようになったのはこれのおかげが大きい。

もちろん「任せる」といっても無条件ではなくて、

仕様の解釈を伴う判断(曖昧な要件をどう倒すか)は自分で決める
実装そのものはAIに任せて自分はレビュアーに徹する
最終的にPRに自分の名前で出す以上、全diffに目を通す

の3つは外さないようにしています。

これから試したいこと

使用量を抑える工夫の本格化:/compact の使いどころ、サブエージェントの粒度、MCPから渡す情報のさらなる絞り込みなど、まだまだチューニング余地がある
Skillのさらなる増殖:定型化できる作業はまだまだある
Claude Max への昇格判断:Pro でも今のところ困っていないので、しばらく様子見

まとめ

転職して環境を改善するために Cursor + Claude Code の併用で始めたら、Claude Code の素晴らしさに気づいて Claude Code 一本化に至った、という話でした。

Copilot単独の「修正↔レビュー無限ループ」は、書き手とレビュアーを分けることで抜けられる
ただし、同じモデルを使う限りツールを分けても精度は上がらない。効いたのは Claude Code 内でコーディング用とレビュー用のスキルを分けることのほう
想定よりずっと Claude Code の使用量に余裕があった(2週間で5時間リミット到達は1回)ので、節約のための併用は不要だった
Gemini CLI はサブとして優秀(Copilotよりは上、Claude Code には及ばず)。シンボリックリンクで設定とスキルを共有できる
CLI完結のワークフロー(Vim + git CLI + Warp分割ペイン + Claude Code)が自分には一番しっくり来た

繰り返しになりますが、Cursor が悪いわけではない。前職から信頼しているし、コスパも操作感も良いツールです。ただ自分には Claude Code のほうが合っていた、というそれだけの話。

AI開発環境はまだ正解が定まっていないので、最初に組んだ構成を疑って素早く組み替えること自体が大事なスキルだと感じています。誰かの最適解と自分の最適解は違うはずなので、まず1ヶ月試して、合わなければ捨てて別の構成にする。それくらいの軽さで触ったほうが、結果的に速く自分に合う環境にたどり着ける気がしています。