「同じ Claude なのに、なぜ二つ入れているのですか」と聞かれることが増えました。Xcode のサイドバーに常駐する Claude on Xcode と、ターミナルで動く Claude Code。どちらも同じモデルにつながっているのに、私の開発机では役割がはっきり分かれています。この 2 週間、壁紙・癒し系アプリの実務でどちらをどの場面に充てると一番手が止まらないのか、意識して記録を取ってみました。その振り分けの実感を、判断材料として残しておきます。
個人開発の一日は、派手な機能追加よりも地味な保守の積み重ねでできています。SDK の更新、ビルド警告の解消、App Store のレビューへの返信、複数アプリへの同じ修正の横展開。こうした作業は一つひとつが小さいので、「どのツールを開くか」を間違えると、本題に入る前の段取りだけで時間が溶けていきます。だからこそ、開く前の数秒の判断を言語化しておく価値があると感じました。
同じモデルでも、見えている世界が違う
最初に腑に落ちたのは、二つの違いは賢さではなく「文脈の窓」だということでした。
Claude on Xcode は、いま開いているプロジェクトのビルド設定、project.pbxproj、選択中のソース、ビルドエラーの行番号まで、Xcode の内側を見ています。一方の Claude Code は、リポジトリ全体をファイルとして横断し、git を打ち、テストを回し、複数ファイルにまたがる変更を一気に適用できます。
Claude on Xcode … Xcode 一つのプロジェクトの「中」が見える / GUI 操作と地続き
Claude Code … リポジトリ全体とシェルが見える / 横断的な一括変更が得意
賢さで選ぶのではなく、「いま欲しい視野はどちらか」で開くものを決める。この一文に気づいてから、二つを行き来する迷いがほとんど消えました。
2 週間の実例 — どちらに何を任せたか
ビルドエラーと格闘する朝は Claude on Xcode
Beautiful HD Wallpapers で Firebase を更新した翌朝、Crashlytics の Run Script フェーズで赤いエラーが出ていました。こういうとき、エラーの行をクリックした状態でそのまま聞けるのが Claude on Xcode の強みです。
このビルドエラーが出ている Run Script フェーズの内容と、
dSYM アップロードに必要な環境変数が揃っているかを確認して、
不足していれば修正案だけ先に提示してください。
エラーの実体（どのスクリプトの何行目か）を IDE 側から渡せるので、こちらが状況を説明する手間がほとんどありません。GUI で設定を直す前提の作業は、Xcode の中にいる Claude のほうが速いと感じます。
6 本のアプリに同じ修正を入れる午後は Claude Code
逆に、ATT（App Tracking Transparency）の説明文を 6 本のアプリで一斉に統一したときは、Claude Code の独壇場でした。
各リポジトリの Info.plist にある
NSUserTrackingUsageDescription を確認して、
表現が古いものを新しい統一文言に置き換える差分を作り、
変更したファイルだけを一覧で見せてください。
ファイルを横断して同じ修正を当て、git diff で確認し、問題なければそのままコミットまで進める。一つの Xcode プロジェクトに閉じない作業は、ターミナルで全体を見渡せる Claude Code のほうが圧倒的に向いています。
判断に迷う中間ケース — 「どちらでもできる」作業をどう割り振るか
実際に難しいのは、両方でこなせてしまう作業です。たとえば「1 行のバグ修正」は、Xcode で該当行を選んで直してもいいし、Claude Code に diff を作らせてもいい。ここで私が採っている基準は、バグの原因がコードの中にあるか、プロジェクトの構成の中にあるか です。
原因がロジック（条件分岐の取りこぼし、Optional の扱い）なら、周辺ファイルやテストごと見渡したいので Claude Code。原因がビルド設定や Signing、依存解決のように Xcode の GUI と地続きの場所にあるなら、設定画面とエラーを同時に見られる Claude on Xcode。同じ「1 行直す」でも、原因の住所がどちらの視野に入っているかで開くものが変わります。
もう一つの中間ケースが、見慣れないクラッシュスタックの解読です。スタックトレース自体はテキストなのでどちらにも貼れますが、私は最初の見立てを Claude Code に任せます。リポジトリ全体から同じシンボルが出てくる箇所を一緒に探させると、「このフレームは自分のコードか、ライブラリか」の切り分けが速いからです。当たりがついて、直す場所が特定の画面まで絞れてから Xcode 側に移ります。
ぶつかった壁 — 二つを同時に動かしたときのコンフリクト
正直に書くと、最初の数日は失敗もありました。Claude Code でファイルを書き換えている最中に、Xcode 側でも Claude on Xcode に同じファイルを触らせてしまい、Xcode のエディタが古い内容を保持したまま上書き保存して、せっかくの差分を潰したことがあります。
ここから得た運用ルールはシンプルです。一つのファイルは、同じ瞬間にどちらか一方からしか触らせない。 Claude Code に一括変更を任せている間は Xcode のそのファイルを閉じておき、作業が終わってから Xcode を前面に戻す。当たり前のようですが、二つの AI を机に並べると、人間側の交通整理が新しい仕事として増えます。
この交通整理を仕組みにするために、いまは「横断変更は Claude Code に寄せ、その間 Xcode は前面に出さない」という時間の区切りを設けています。私自身は午前を Xcode 主体の単機作業に充て、午後は Claude Code 主体で横展開、という具合に時間帯でモードを分けると、同じファイルを両側から触る事故はほぼ起きなくなりました。ツールの切り替えより、人間側のモード切り替えを先に決めるのが効いた、というのが実感です。
気づいたこと — 役割を決めるのは「次に自分が何をするか」
2 週間使って一番の収穫だったのは、ツールの優劣ではなく、自分の次の一手から逆算して選ぶ習慣がついたことでした。
次に自分がやるのが Xcode の GUI 操作（スキーム切り替え、ビルド、シミュレータ確認）なら Claude on Xcode。次にやるのが git やテスト、複数リポジトリの横断なら Claude Code。判断軸を「作業の続き先」に置くと、迷いが消えます。
道具を持ち替える基準が「対象に合わせる」ことだとすれば、AI の道具も同じなのだと思います。荒く削る面と薄く仕上げる面で刃物を替えるように、手を動かす対象に合わせて視野の広さを替える。賢さの優劣で比べていたうちは迷いが残りましたが、対象から逆算する習慣がつくと、開く前の数秒で手が決まるようになりました。
これから取り組むこと
次は、Claude Code 側で回したテストの結果を、Claude on Xcode の作業ログと突き合わせる流れを整えたいと考えています。いまは二つの記録が別々の場所に残るので、リリース前の振り返りで両方を見比べるのに少し手間がかかります。ここを地続きにできれば、個人開発の一日はもう一段静かになるはずです。
同じ課題で二つのツールの間を行き来している方の、判断の足場になれば幸いです。お読みいただきありがとうございました。