AIツールに関しては少し保守的なほうでした。CursorがもてはやされていたときもAIにプロジェクト全体へのアクセスを与えることに慎重で、試していませんでした。基本的にはAppleのよりプライバシー重視のソリューションを待っていたのです。しかし、それが結局ChatGPT（や他のモデル）だったとわかり、それならサードパーティのツールも試してみようと思いました。そこでWWDC以降、Xcode 26（ベータ5）をCursorとClaude Codeの両方と比較テストしてきました。
AppleがローカルオンリーではなくサーバーベースのLLMに方針転換したことは、正直嬉しく思います。コンテキストエンジニアリングを適切に行えばClaude Codeがどれほど素晴らしいかを知った今、ローカルオンリーのソリューションでは実用的な品質に達するまで何年もかかったでしょう。当初のSwift Assistのアイデアから方針転換したのは正しい判断でしたが、初回リリースに向けて完全なソリューションを構築する時間が明らかに足りなかったようです。開発においてAppleエコシステムに忠実な者として、素晴らしいツールになり得るものにこれほど明白なギャップがあるのはもどかしいです。そのため14年の開発者キャリアで初めて、Xcodeを日常的なメインツールとして使わなくなりました。
コンテキストエンジニアリングにより、Claude Code in Cursorが自身の持つコンテキストを要約している様子。
最終的に、Cursorのターミナル内でClaude Codeを実行するというスタイルに落ち着きました。Cursorのエディタ認識能力とClaude Codeの優れたツール群（ウェブ検索、プランニングモード、ゆとりある5時間の使用ウインドウ）を両方活用できます。チャットインターフェースを全面的に採用し、拡張コンテキストエンジニアリング（ガイドライン、リファレンスドキュメント）を通じてAIに良いコードの書き方を教えようとしています。一方、XcodeのAI統合は、ネイティブIDEとしてのポジションによる可能性はあるものの、このようなAI駆動開発を生産的にするための基本的な機能が欠けています。
Xcodeに戻れない理由をお伝えしましょう。
Xcode AIに足りない7つの機能
1. リクエストのキューイングは、Xcodeですぐに気づいた最初の制限です。開発中は、考えや質問が次々と浮かびます。毎回レスポンスを待たなければならないのは、リズムを完全に崩します。待っている間に先のことを考えるのは、AIで作業する際の最大の時短テクニックの一つです。CursorもClaude Codeもシームレスにリクエストをキューに入れられ、フローを維持できます。Xcodeは入力を完全にブロックします。
Xcode 26は前のリクエストを処理中、新しいチャット入力をブロックする。
2. コンテキストエンジニアリングのサポートは、Xcodeが完全に不足している部分です。.cursorrulesやCLAUDE.mdのようなコンテキストファイルのサポートがありません。自動的なコンテキスト読み込みがなければ、コーディング標準、アーキテクチャパターン、エラーハンドリング方針などをAIに教えるために私が行ってきたコンテキストエンジニアリングのすべての作業がXcodeでは不可能です。会話のたびにガイドラインを繰り返し説明しなければなりません。Claude CodeとCursorはどちらもリードガイドラインを自動的に読み込み、どのタイミングでどの詳細なガイドラインを読むべきかを理解します。これにより、AIは汎用的なコード生成器から実際に役立つアシスタントに変わります。Xcodeではそれができません。
Coding Assistantが、プロジェクトやガイドラインについて教える方法がないと告げている。
3. ビルドの検証を見ると、XcodeがAI駆動開発用に設計されていないことがわかります。AIが自分のコード変更をビルドして検証することも、私がビルドを実行した際のビルド出力にアクセスすることもできません。明示的に求めてもコンソールログすら読めません。確かに、ビルド後にエラーを選択してAIに修正を依頼することはできますが、それは別のワークフロー向けに設計されたものです。手動でコードを書いてミスをしたときには有用ですが、そんなことはめったに起きません。AIがコードを書く場合はどうでしょう？ビルドエラーは頻繁に発生します。自分でビルドして手動でエラーの修正ボタンを押すのは非常に煩わしいです。AIがビルドを実行してエラーを自分で確認できるべきです。Claude Codeでは、xcodebuildを実行させるだけでAIはすべてのエラーを即座に確認できます。許可は求められますが、許可すれば反復・修正・再ビルドをすべてがコンパイルされるまで自動で行います。手動介入は不要です。
Coding Assistantがコンソール出力を読めないと告げている。
4. Git統合が完全に欠落しています。履歴の検索、バージョンの比較、ガイドラインに従った自動コミットのいずれもできません。最近の変更に基づいてドキュメントファイルを更新するために現在のコードと以前のバージョンを比較することも、以前のコミットから動作していたコードを復元することもできません。Claude Codeはgit履歴を検索し、以前のコミットから動作するコードを復元し、実際の変更を分析してコミットガイドラインに従った適切なメッセージで正しくフォーマットされたコミットを作成できます。最後のバージョンからの変更点を比較してドキュメントの更新を支援することもできます。
Coding Assistantがgit履歴にアクセスできないと告げている。
5. ターミナルとCLIアクセスが最大のギャップです。コマンドラインにアクセスできないということは、swift-formatもカスタムスクリプトも自動化もできないということです。複数の責任を同時にこなすインディー開発者にとって、これは深刻な制限です。コミット前にコードフォーマッターを実行するよう教えることも、テストスイートを実行させることも、開発プロセスを効率化するカスタムスクリプトを走らせることもできません。Claude Codeは必要なターミナルコマンドを何でも実行します。コミット前のコード整形、テストスイートの実行、デプロイメントスクリプトの実行、依存関係の管理、自動化ワークフロー全体の処理が可能です。ターミナルツール一つで、git、xcodebuild、パッケージマネージャーなど、すべてにアクセスできます。最近のAIはこういうことが得意なんです！
❇️ Appleがターミナルアクセスだけでも追加すれば、上記のポイント3と4も同時に解決します！もちろんフルコマンドラインアクセスを与えることにはリスクがあります。しかしClaude Codeは、初回に許可を求め、シンプルな設定ファイルで許可リストと拒否リストをサポートすることで、これをうまく解決しています。
6. プロジェクトファイルの制限は、Xcodeが現代のAIコンテキストエンジニアリングワークフロー向けに設計されていないことを示しています。多くのプロジェクトは複数のリポジトリにまたがっています。例えばTranslateKitにはアプリ、サーバー、オープンソースパッケージのコンポーネントがあります。私のコンテキストエンジニアリングガイドラインはXcodeプロジェクトを含まない親フォルダにありますが、すべてのコンポーネントからAIにアクセスさせる必要があります。フォルダをXcodeにドラッグしてエディタで開こうとすると、エラーが表示されるだけです。Xcodeは単一のテキストファイル、Xcodeプロジェクト、またはSwift Packageマニフェストファイルしか開けず、任意のフォルダは開けません。また、隠しファイルも表示されないため、GitHub Actionsのワークフローなどを確認・編集できません。一方、Cursorはどんなフォルダでも開き、隠しファイルも表示し、マルチリポ開発環境全体で動作します。Xcodeもこれに対応すべきです！
Xcodeで任意のフォルダを開こうとしたときのエラーダイアログ。
7. ウェブ検索とドキュメントアクセスも完全に欠如しています。AIはXcode自身のダウンロード済みドキュメントファイル内すら検索できません。最新情報やAPIリファレンスが必要なときは、自力で探すしかありません。Claude Codeにはウェブ検索機能が内蔵されています。最新のSwift Evolutionプロポーザルや WWDC25で発表された新しいAPIについて質問すれば、答えを見つけてくれます。Xcode 26ではそれができません。
2025年にAppleが導入した新しいフレームワークについて聞くと、100%ハルシネーションする。
これら7つの制限が積み重なることで、根本的な問題になっています。XcodeのAIは生産性ツールというよりテックデモのように感じられます。欠けている要素の一つ一つが、Claude Codeなら シームレスに処理できる手動ワークフローに戻ることを強いています。
Appleへの提案：5段階のリリースロードマップ
Appleがこれらのギャップに対処し、私をXcodeに呼び戻すためのロードマップを提案します：
Xcode 26.1（2025年10月）：
リクエストのキューイングとコンテキストファイルサポート（例：Xcode.md）の追加。これらの機能は実装が容易で、不必要な副作用のリスクもないはずです。
Xcode 26.2（2025年12月）：
git、xcodebuild、swift-formatの専用ツール統合。これらはすべてXcodeに内蔵されているかAppleの技術なので、Appleのエンジニアが既存の経験を活かして安全で保守的なアクションとしてAIにこれらのツールを提供できると思います。
Xcode 26.3（2026年3月）： ウェブ検索、最新ドキュメント統合、隠しファイルアクセスを伴う任意フォルダの開放。これらの統合はすべて低リスクですが、正しく実装するには時間がかかります。
Xcode 26.4（2026年5月）： コマンド別の許可/拒否リスト付きフルターミナルアクセス。
Appleのセキュリティ上の懸念は理解できますが、開発者はその責任を扱えます。Appleよ、必要なツールを信頼して提供してください！
Xcode 27（2026年9月、WWDC 26で発表）： 「Appleにしかできない」機能。例えば、深いSimulator統合（AIがアプリ内をナビゲートして変更が期待通りに動作するかテストするところを想像してください）やSwiftUI Previewアクセス（AIが自分のUIコードがどう見えるか確認できるように）。さらには、SwiftUIを二次的な成果物にする「アプリビルダー」モードで、アプリ開発をまったく新しい層のユーザーに開放することも。ここがAppleが予想もしなかったもので驚かせてくれる場所です。単なる「追いつき」ではなく、本当に競合を超える何かを。
結論
Xcodeをずっと愛用してきましたし、再びXcodeだけを使いたいと心から思っています。Appleには競合他社にはない独自の優位性があります。シームレスなIDE統合、Simulator制御、SwiftUI Preview機能。しかし現時点では、Claude Codeのほうが圧倒的に高性能で、生産性に5倍の差があります。Xcodeで数時間かかるタスクがClaude Codeでは数分で完了します。主な理由は、「ビルド」ボタンを押すような簡単なタスクで私に依存しないからです。
Appleは迅速に動く必要があります。時間が経つほど、より多くの開発者が他のツールで深いワークフローを確立していきます。各ポイントリリースを楽しみに見守っていますし、XcodeのAIが競争力を持った瞬間、真っ先に戻るでしょう。それまでは、ターミナルでClaude Codeを開き続けながら、Xcodeが再び衝撃を与え、AI-first IDEへの転換を遂げる日を夢見ています。
Xcode AIの統合についてのあなたの経験はいかがですか？これらの制限に対する回避策を見つけましたか？それとも同じく代替ツールを使っていますか？