CodeXとClaude Codeの使い分けを決めようとして、結局どちらも常時起動している。9月以降のアップデートで両者の役割が重なり始めた今、AzRunの開発現場で起きている併用の実態と、まだ整理しきれていない判断軸を記録する。

CodeXの補完精度が上がった9月

「これ、前より賢くなってる」。Notion APIのWebhook処理を書いていたとき、CodeXが`properties`の構造を正しく補完した。以前なら古いv1の`title`プロパティを提案していたはずが、`rich_text`配列から本文を取得する実装を一発で出してきた。

9月中旬のアップデート以降、CodeXの文脈理解が明らかに変わった。プロジェクト全体のファイル構造を読む精度が上がり、同じリポジトリ内の命名規則やエラーハンドリングのパターンを踏襲するようになっている。特に、既存コードの「書き方の癖」を拾ってくれるのが大きい。私たちのコードベースでは`async/await`を多用しているが、それを前提にした提案が自然に出てくる。

ただ、複雑なロジックの組み立てや、複数ファイルにまたがるリファクタリングでは、Claude Codeの方が意図を汲む。ここで最初の迷いが生まれた。

Claude Codeは対話設計の精度で選ばれる

同じ9月、Claude Codeも3.5 Sonnetへの移行と同時に、マルチファイル編集の安定性が上がった。以前は2ファイル以上の同時編集で差分が壊れることがあったが、今は5ファイル程度なら問題なく処理できる。

私たちがClaude Codeを起動するのは、「このロジック、どう分割すべきか」という構造の判断が必要なときだ。先月、Slackボットのステータス通知機能を追加した際、最初は1ファイルに全て書いていた。それをClaude Codeに「通知条件の判定」「メッセージ生成」「送信処理」の3層に分けてもらった。提案されたファイル分割の粒度が、そのまま採用できるレベルだった。

もう一つ、Claude Codeを選ぶのはエラーの原因特定。スタックトレースを貼ると、該当箇所だけでなく「なぜそのエラーが出たか」の推論まで返してくる。CodeXは修正案を出すが、理由の説明は薄い。この差は、レビュー時の判断材料として効いている。

実際の開発フローでは両方開いている

結局、使い分けを決めていない。今の開発環境では、エディタでCodeXを有効にしたまま、ターミナルでClaude Codeも起動している。

典型的な流れはこうだ。新機能の実装を始めるとき、まずClaude Codeでファイル構成と大まかなロジックを相談する。「この機能、どのディレクトリに置くべきか」「既存の認証処理を使い回せるか」といった判断を先に固める。その後、実際のコーディングに入るとCodeXの補完に任せる。関数名を途中まで打つと、引数の型まで含めて提案してくれる速度が速い。

ただ、この併用にはコストがある。Claude CodeはAPI経由のため、1リクエストあたりの料金が発生する。9月の利用実績で、月間約40ドル。CodeXはGitHub Copilotの契約に含まれるため追加コストなし。この差を考えると、「全てClaude Codeでいいのでは」とはならない。補完の応答速度も、CodeXの方が体感で0.5秒ほど速い。

まだ整理できていない判断軸

「どちらを使うべきか」という問いに、明確な答えを出せていない。開発メンバーに聞いても、人によって選ぶタイミングが違う。

あるメンバーは「複雑な条件分岐はClaude Code、単純なCRUDはCodeX」と言う。別のメンバーは「最初から最後までClaude Codeで通す方が、文脈が途切れなくて楽」と話す。私自身も、その日の気分やタスクの性質で選び方が変わっている。

試したが機能しなかったのは、「このタスクはこちら」とルール化すること。ルールを決めた翌日には例外が出て、結局その場の判断に戻った。もう一つ、Claude Codeの履歴を後から見返す習慣も定着していない。対話ログは残るが、「あのとき何を聞いたか」を探すのに時間がかかり、結局新しいセッションで聞き直している。

ツールの性能が上がるほど、選択肢が増え、判断に迷う時間が生まれる。この状況をどう整理するか、まだ答えは出ていない。ただ、両方使える環境があることで、少なくとも「どちらかに固定して不便を我慢する」状態は避けられている。

あなたの開発環境で、CodeXやClaude Codeをどう位置付けるか。もし導入や運用で迷っていることがあれば、お問い合わせからお聞かせください。