2つのMCPサーバーがClaude CodeをiOSビルドシステムに変えた

Xcode MCPサーバーなしでiOSプロジェクトに向けられたClaude Codeセッションは、目隠し状態です。エージェントはSwiftファイルを読み書きし、Bashツール経由でxcodebuildを実行できますが、ビルドエラーが発生するたびに、構造化されていない出力を何千行も解析する必要があります。シミュレーター管理は生のxcrun simctlコマンドです。テスト結果は、エージェントが失敗箇所を探してスキャンしなければならない大量のテキストとして届きます。

Claude Codeに完全なXcode統合を提供するには、2つのMCPサーバーを追加します。XcodeBuildMCP（v2.3.2はビルド、テスト、シミュレーター、LLDBデバッグにわたる82のツールを謳っています）と、Xcode 26.3に同梱されるAppleのネイティブXcode MCP（ファイル操作、診断、SwiftUIプレビュー用の20ツール）です。 それぞれclaude mcp addコマンド1つで導入できます。両者を組み合わせることで、構造化されていないビルドログ解析を構造化されたJSONレスポンスに置き換え、エージェントに正確なエラー位置、メソッド単位のテスト結果、プログラム制御可能なシミュレーター操作を提供します。

これを2つのclaude mcp addコマンドで変えました。MCP（Model Context Protocol）はmodelcontextprotocol.ioで仕様が定められたオープンスタンダードであり、AIエージェントが構造化されたJSONリクエストとレスポンスを通じて外部システム上のツールを呼び出せるようにします。REST APIと同じ発想ですが、エージェントとツール間の通信のために設計されています。⁵

TL;DR

XcodeBuildMCP（オープンソース、v2.3.2ドキュメントによれば現在82個のMCPツール）は、Xcodeを起動することなくビルド、テスト、シミュレーター、実機デプロイ、LLDBデバッグを処理します。Appleのネイティブ Xcode MCP（20ツール、Xcode 26.3にxcrun mcpbridgeとして同梱）は、ファイル操作、リアルタイム診断、ドキュメント検索、Swift REPL、SwiftUIプレビューのために実行中のXcodeプロセスにブリッジします。両者を合わせると、Claude CodeにiOS開発ツールチェーンへの完全なプログラム制御アクセスを与えます。ログ解析の代わりに構造化されたJSON、シェルコマンドの代わりにツール呼び出しです。セットアップは2分以内で完了します。

ギャップ

Claude CodeはSwiftの読み書きにおいて卓越しています。SwiftUIパターン、SwiftDataの関係性、Swift 6の並行処理を理解しています。しかしビルドシステムには目隠し状態でした。

ビルドが失敗したとき、エージェントは次のことをしなければなりませんでした。

1. Bash経由でxcodebuildを実行
2. 構造化されていない何千行もの出力を解析
3. ノイズの中から実際のエラーを見つけられることを願う
4. どのファイルと行が失敗を引き起こしたかを推測

テストを実行したいとき、

1. エージェントがxcodebuild testコマンドを記憶から組み立てる
2. xcresultバンドル（あるいはより一般的には生のstdout）を解析する
3. どのテストが合格してどれが失敗したかを把握しようとする

このワークフローは、コンパイラ出力を鍵穴越しに読みながらコードを書くよう開発者に求めるのと同等でした。情報は技術的にはそこにあったのですが、インターフェースが間違っていたのです。

解決策：補完的な2つのMCPサーバー

XcodeBuildMCP（コミュニティ、オープンソース）

XcodeBuildMCPは、xcodebuildと関連ツールを構造化されたMCPツール（現在のv2.3.2カタログでは82個）でラップします。エージェントはbuild_simを呼び出し、3,000行のビルドログではなく、分類済みエラー、警告、ファイル位置を含むJSONを受け取ります。

主要ツール：

インストール：

claude mcp add XcodeBuildMCP \
  -s user \
  -e XCODEBUILDMCP_SENTRY_DISABLED=true \
  -- npx -y xcodebuildmcp@latest mcp

-s userフラグにより、プロジェクトごとの設定なしでどのプロジェクトでも利用可能なグローバル設定になります。env varはテレメトリーを無効化します（デフォルトではクラッシュレポートをSentryに送信。オプトアウトは1回限りの衛生対策です）。¹

Apple Xcode MCP（ネイティブ、Xcode 26.3に同梱）

Appleは独自のMCPサーバーをXcode 26.3でxcrun mcpbridge経由で提供しました。20個のツールを公開しており、XPC経由でXcodeのプロセスに直接ブリッジします。重要な注意点： Appleは2026年5月現在、MCPサーバーのスタンドアロンドキュメントを公開していません。以下のツール一覧は著者のテストとRudrank Riyam氏の初期分析に基づいています。ツール名と機能は将来のXcodeリリースで変更される可能性があります。

インストール：

claude mcp add --transport stdio xcode -s user -- xcrun mcpbridge

Xcode 26.3以降が必要です。

なぜ両方なのか？

ビルドとテストでは重複しますが、アーキテクチャが異なります。

• XcodeBuildMCP はxcodebuild CLI経由でスタンドアロンで動作し、Xcodeプロセスの起動を必要としません。カタログは幅広く（v2.3.2時点で82のMCPツール）、シミュレーター、実機、LLDBデバッグ、UI自動化、プロジェクトのスキャフォールディングをカバーします。スタンドアロンアーキテクチャが重要なのは、ヘッドレスワークフローを可能にするからです。エージェントはXcodeを開かずにビルドとテストができ、これは高速でシステムメモリの消費も少なくなります。
• Apple Xcode MCP は実行中のXcodeインスタンスを必要とし、XPC（Appleのプロセス間通信フレームワーク）を介して通信します。Xcodeプロジェクトコンテキスト内のファイル操作、リアルタイムのコード診断（ビルド出力だけではない）、WWDCセッションを含むネイティブのドキュメント検索を提供します。XPCブリッジが重要なのは、CLIツールではアクセスできないXcodeの内部状態（ライブ診断、解決済みシンボル、プレビューレンダリング）を公開するからです。

私は両方を使っています。XcodeBuildMCPはビルド・テスト・デバッグサイクル用（Xcodeを開かずに動作）、Apple’s MCPはドキュメント参照、Swift REPL検証、SwiftUIプレビューレンダリングが必要なときに使います。

AIエージェントがBash経由でxcodebuildを実行すると、構造化されていないテキストのストリームを受け取り、エラーがどこで始まり終わるかを推測し、部分一致からファイルパスを推論し、フォーマットが変わっていないことを願いながらヒューリスティックに解析しなければなりません。同じエージェントがMCP経由でbuild_simを呼び出すと、予測可能なフィールドに分類されたエラー、警告、ファイルパス、行番号を含むJSONレスポンスを受け取ります。エージェントのタスクは解析から推論へとシフトします。違いはLLMベースのエージェントにとってより重要です。構造化されていないビルド出力の文字一つひとつがコンテキストウィンドウのトークンを消費するため、3,000行のビルドログは、エージェントが本当に重要な1つのエラーを見つける前にワーキングメモリを使い果たしてしまう可能性があります。構造化されたJSONレスポンスは、エージェントがエラーを探す代わりに直接読めるようにします。MCPはエージェントを賢くするわけではありません。エージェントが受け取る情報を読みやすくするのです。

実環境でのテスト

このプロンプトを使い、Waterアプリ（SwiftUI + Metal流体シミュレーション + HealthKit）でフルヘルスチェックを実行しました。

Use the XcodeBuildMCP and Apple Xcode MCP tools to do a full
health check of this project:

1. List available simulators and boot an iPhone 16 Pro
2. Build the project for that simulator
3. Run existing tests and report pass/fail results
4. Search Apple docs for "HealthKit water intake"
5. Use the Swift REPL to verify HKQuantityType(.dietaryWater)

何が起きたか

シミュレーターのセットアップはlist_sims、session_set_defaults、boot_simを使いました。エージェントはiPhone 16 ProがiOS 26ランタイムに存在しないこと（廃止済み）を発見し、自動的にiPhone 17 Proに切り替えました。この自動フォールバックは、ハードコードされたxcodebuildコマンドでは壊れる類の適応的な振る舞いです。

ビルドは最初失敗しました。新しいXcodeインストールでMetal Toolchainがダウンロードされていなかったのです。エージェントは構造化エラー出力からこれを検出し、xcodebuild -downloadComponent MetalToolchainを実行して修正しました。その後、3つの警告とともにビルドは成功しました。

HomeView.swift:132    UIScreen.main deprecated in iOS 26.0
LogWaterIntent.swift:61   Result of try? is unused

構造化出力により、これらは正確なfile:line参照を持つ分類済み警告として返ってきました。ログに埋もれることはありません。

テストは失敗しましたが、その失敗には情報がありました。構造化出力は、5つのテストメソッドがinjectTapRipple(atNormalizedX:)を参照していることを示しました。これは以前のコミットで削除したメソッドです。エージェントは正確なコミット（7657068, "remove tap ripple interaction entirely"）を特定し、更新が必要なテストをリストアップしました。曖昧さはゼロです。

ドキュメント検索とSwift REPLは、HKQuantityType(.dietaryWater)が有効であることを確認し、識別子HKQuantityTypeIdentifierDietaryWaterを返しました。

結果テーブル

ヘルスチェック全体は、シミュレーター起動時間を含めて約90秒で自律的に実行されました。Xcodeを開かず、エラーメッセージをコピーせず、xcodebuildコマンドも組み立てませんでした。MCP以前は、同じ5ステップのヘルスチェックには約8〜10分の能動的な人間の関与が必要でした。xcodebuildコマンドの記述、出力の解析、ドキュメント検索のためのXcodeへの切り替え、REPL検証のためのSwift Playgroundsの起動などです。時間短縮はビルドが速くなったから（ビルドにかかる時間は同じ）ではなく、各段階間の人間が介在する解析ステップを排除したことから生まれます。

構造化 vs 非構造化：エージェントが実際に見るもの

違いは具体的です。同じビルドエラーを両方のインターフェースで見てみましょう。

Bash経由（xcodebuildの生出力）、1つのエラーを取り囲む47行のノイズ：

CompileSwift normal arm64 /Users/.../HomeView.swift
...
/Users/blake/Projects/Water/Water/Views/HomeView.swift:132:9:
warning: 'main' is deprecated: Use UIScreen.main in iOS 16.0+
         ^~~~~~~~
** BUILD FAILED **
The following build commands failed:
  CompileSwift normal arm64 .../FluidRenderer.swift
...

エージェントは何千行もを解析し、エラーの開始と終了を推測し、部分一致からファイルパスを推論しなければならず、ノイズの行ごとにコンテキストウィンドウのトークンを消費します。

MCP経由（build_simの構造化レスポンス）、予測可能なフィールドに正確なエラー（説明用に簡略化。実際のレスポンスにはビルド時間やスキームなど追加フィールドが含まれます）：

{
  "status": "failed",
  "errors": [{
    "file": "FluidRenderer.swift",
    "line": 89,
    "message": "Cannot find 'MTLPixelFormat' in scope",
    "severity": "error"
  }],
  "warnings": [{
    "file": "HomeView.swift",
    "line": 132,
    "message": "'main' is deprecated in iOS 26.0",
    "severity": "warning"
  }]
}

エージェントはエラーを直接読み、ファイルと行を特定し、修正の検討を開始します。解析も、推測も、無駄なトークンもありません。コンテキストウィンドウのコストは数千トークンから数十トークンへと下がります。

エージェントへの教育

MCPサーバーをインストールするだけでは不十分です。エージェントはツールが存在することと、生のシェルコマンドよりもそれらを優先すべきタイミングを知る必要があります。私はios-developerエージェント定義を更新して、明示的なガイダンスを含めました。

## Build & Test Tools (XcodeBuildMCP)

Prefer MCP tools over raw xcodebuild commands:

- **Build**: Use `build_sim` / `build_device` for structured errors
- **Test**: Use `test_sim` / `test_device` for pass/fail results
- **Simulators**: Use `list_sims`, `boot_sim`, `open_sim`
- **Debug**: Use `debug_attach_sim`, `debug_stack`, `debug_variables`

## Apple Xcode MCP (mcpbridge)

- **Documentation**: Use `DocumentationSearch` for Apple docs
- **Swift REPL**: Use `ExecuteSnippet` for API verification
- **Previews**: Use `RenderPreview` for headless SwiftUI rendering

Prefer these over WebSearch for Apple API questions
and over Bash `swift` for REPL tasks.

これがないと、エージェントは時々Bash経由のxcodebuildにフォールバックしたり、ネイティブ検索ではなくWebSearchをApple ドキュメントに使ったりします。エージェント定義はそのギャップを埋めます。² フック、スキル、ルールと組み合わせたエージェント定義の構造化についてのより広い視点については、Claude Codeガイドが完全な設定階層をカバーしています。

実践で何が変わるか

MCP以前、Claude CodeでのiOSワークフローは次のようなものでした。

1. Claudeでコードを書く
2. Xcodeで手動ビルド（またはターミナルでxcodebuild経由）
3. エラーをClaudeにコピーバック
4. 繰り返し

MCP以後：

1. やりたいことを記述する
2. Claudeがコードを書き、ビルドし、エラーを読み、修正し、テストを実行し、APIの振る舞いを検証する
3. 私が最終結果をレビューする

私の能動的な関与を必要としていたビルド・エラー・修正ループは、いまや自律的に行われます。エージェントは生のテキストから何が間違っていたかを推測しているのではなく、何がどこでなぜ失敗したかを正確に教えてくれる構造化データを読んでいるのです。

ブレイクスルーはAIをより賢くすることではなく、開発者がすでに使っているツールへの構造化アクセスをAIに与えることです。 MCPはそれを可能にするプロトコルです。ちょうどフックがClaude Codeに決定論的なガードレールを与えた（実装の詳細はフックチュートリアルを参照）のと同じように、MCPは決定論的なツールインターフェースを与えます。XcodeはMCPを介して自身を公開する最初の開発ツールでもなければ、最後でもないでしょう。³

他の開発者もMCPベースのビルドシステムで同様の結果を報告しています。Rudrank Riyam氏のApple Xcode MCPツールに関する詳細なウォークスルーは、ここで述べたドキュメント検索とSwift REPL機能を確認し、同じXPC依存性の制約に言及しています。⁶ 広範なMCPエコシステムにはいまやDocker、PostgreSQL、GitHub、Kubernetes向けのサーバーが含まれており、いずれもCLIツールを構造化されたJSONインターフェースでラップする同じパターンに従っています。⁷ Appleの「Meet agentic coding in Xcode」Tech Talk（Xcode 26.3のエージェント機能を扱う）は、AI支援開発へのAppleのより広い投資の一部としてこの機能を紹介し、MCPをニッチなプロトコルではなく、AIエージェントと開発ツール間の標準インターフェースとして位置づけました。⁸

構造化インターフェースによる効率向上は、AIツール使用に関するより広範な研究と一致しています。Jimenezら（2024年）のSWE-benchは、構造化ツーリング（ファイル単位の編集ツール、構造化出力を持つテストランナー）にアクセスできるエージェントが、構造化されていない出力のbashコマンドに限定されたエージェントよりも有意に多くのGitHub問題を解決したことを発見しました。⁹ このパターンはXcode固有ではありません。構造化されたツールアクセスは、エージェントのタスクを解析から推論へとシフトさせるため、ドメインを越えてエージェントのパフォーマンスを向上させるのです。

制限事項と現状のギャップ

MCPは万能の解決策ではありません。何ができないかについて率直に説明します。

ビジュアルデバッグはできません。 MCPはビルドエラーやテスト結果について構造化データを返しますが、アプリのビジュアル状態を見せることはできません。ビューが10ピクセルずれてレンダリングされるレイアウトバグはビルドエラーを生まず、すべてのロジックテストにも合格します。XcodeBuildMCPのscreenshotとsnapshot_uiツールは画面をキャプチャしますが、視覚的な正しさの解釈にはやはり人間のレビュー（または別のビジョンモデル）が必要です。エージェントはビルド、実行、テストはできますが、見ることはできません。

Apple MCPのXcodeプロセス依存。 Appleのxcrun mcpbridgeは実行中のXcodeインスタンスを必要とします。Xcodeがクラッシュしたり閉じたりすると、そのサーバー経由のMCP呼び出しは成功しなくなります（ブリッジはXcodeのプロセスに依存しているため）。XcodeBuildMCPはxcodebuildを直接使用することでこれを回避していますが、XcodeのXPCインターフェースにブリッジするツールはどれもXcodeのプロセスライフサイクルを継承します。実用的な含意は、ドキュメント検索やSwiftUIプレビューを使用するセッション中はXcodeを開いたままにすることです。

インクリメンタルビルドの認識がありません。 build_simツールはフルビルドを実行します。前回のビルドが成功し、1つのファイルだけが変更されたかどうかを知りません。エージェントは呼び出しごとに最初から再ビルドします。大規模なプロジェクトでは、これがインクリメンタルビルドをサポートするxcodebuildと比較してビルドサイクルごとに目立つ秒数を追加します。構造化出力のためにオーバーヘッドは許容できますが、これは実コストです。

Apple MCPツールの不安定性。 接続するすべてのMCPサーバーは、信頼の境界を拡張するものであり、セキュリティへの影響は現実です。MCP攻撃面分析は、エコシステム全体にわたる50の脆弱性を文書化しています。AppleはXcode 26.3で公開ドキュメントなしにMCPサーバーを出荷しました。ツール名、パラメータフォーマット、レスポンス構造は、非推奨警告なしに将来のXcodeリリースで変更される可能性があります。特定のApple MCPツールシグネチャに依存するコードは暫定的なものとして扱うべきです。XcodeBuildMCPはオープンソースでコミュニティが保守しているため、セマンティックバージョニングと変更履歴を伴う、より安定したインターフェースを提供します。⁴

コード署名の診断がありません。 プロビジョニングプロファイルエラー、証明書の不一致、エンタイトルメントの競合は、iOS開発で最も不透明なビルド失敗の一部を生み出します。どちらのMCPサーバーも、生のエラーメッセージを超えるコード署名問題の構造化された診断を提供しません。エージェントは「Code signing failed」とファイルパスを受け取りますが、「あなたのプロビジョニングプロファイルは2月15日に期限切れになりました」や「このエンタイトルメントには特定のApp ID プレフィックスが必要です」とは受け取りません。コード署名は手動デバッグの領域のままです。

セットアップチェックリスト

iOSプロジェクトでClaude Codeを使う方向け：

1. XcodeBuildMCPをインストール（Xcode 16+、macOS 14.5+が必要）： bash claude mcp add XcodeBuildMCP -s user \ -e XCODEBUILDMCP_SENTRY_DISABLED=true \ -- npx -y xcodebuildmcp@latest mcp

2. Apple Xcode MCPをインストール（Xcode 26.3+が必要）： bash claude mcp add --transport stdio xcode \ -s user -- xcrun mcpbridge

3. 両方が接続されていることを確認： bash claude mcp list # XcodeBuildMCP: ... - Connected # xcode: xcrun mcpbridge - Connected

4. エージェント定義を更新して新しいツールを参照させる（さもなくばエージェントは時々シェルコマンドにフォールバックします）。

5. 新しいClaude Codeセッションを開始。セッション中に登録されたMCPツールは、再起動するまでツール検索に表示されません。

これだけです。2つのコマンドで、iOSビルドシステムへのフルアクセスが手に入ります。

セットアップ後にこれを試してみてください： Claude Codeに「このプロジェクトをシミュレーター向けにビルドして、エラーを報告してください」と頼んでみましょう。Bash経由でxcodebuild -scheme YourScheme -sdk iphonesimulator buildを実行した結果と比較してみてください。MCPレスポンスはエラーをファイルと深刻度ごとに構造化されたフィールドで分類します。生のxcodebuild出力は、同じ情報を何千行ものコンパイラ出力に埋もれさせます。違いは最初のビルドエラーで即座に見えます。

主要なポイント

AIエージェントを使うiOS開発者向け：

• 構造化されたツールアクセスはエージェントにできることを変えます。 「エージェントがコードを書き、あなたがビルドすることを願う」と「エージェントがコードを書き、ビルドし、エラーを読み、修正する」のギャップは、テキスト補完ツールと開発パートナーの間のギャップです。MCPは、構造化されていないビルドログの代わりに構造化されたJSONをエージェントに与えることで、そのギャップを埋めます。

• 2つのMCPサーバーが補完的なニーズをカバーします。 XcodeBuildMCPはXcodeを開かずに動作します（ヘッドレスビルド、シミュレーター、デバッグ）。Apple’s Xcode MCPは実行中のXcodeプロセスにブリッジします（診断、ドキュメント、SwiftUIプレビュー）。iOS開発ワークフローを完全にカバーするには両方を使ってください。

他のツールチェーン向けにMCPを評価しているエンジニア向け：

• このパターンはXcodeを越えて一般化されます。 構造化されていないテキストを出力する開発ツール（コンパイラ、リンタ、テストランナー、パッケージマネージャ）はどれも、構造化されたMCPインターフェースでラップされたときにAIエージェントにとってより有用になります。プロトコルそのものよりも重要なのは洞察です。エージェントは、可変フォーマットのログではなく予測可能なフィールドで情報が届くときに、より良く推論します。

• エージェント定義はラストマイルのギャップを埋めます。 MCPサーバーをインストールするのは必要ですが十分ではありません。エージェント定義における明示的なガイダンス（「xcodebuildよりbuild_simを優先する」）は、構造化された代替手段が存在するときにエージェントがシェルコマンドにフォールバックするのを防ぎます。

完全なApple Ecosystemクラスター：表面間のルーティング問題についてはApp Intents vs MCP、アプリ内サーバーパターンについてはiOSアプリと並ぶMCPサーバー、アプリ内 vs ツーリングLLM分割についてはFoundation Modelsエージェントワークフロー、より広いiOSアプリ表面モデルについては3つの表面。ハブはApple Ecosystem Seriesにあります。iOS Agent Development ガイドは、シミュレーター管理とテスト駆動パターンを含む、MCP駆動の完全なワークフローをより詳しくカバーしています。

FAQ

MCPをClaude Codeで使うのに、まだXcodeのインストールは必要ですか？

はい。両方のMCPサーバーはXcodeのツールチェーン（xcodebuild、xcrun、simctl）のラッパーです。Xcodeはインストールされ、設定されている必要があります。MCPサーバーはClaude Codeにこれらのツールへの構造化アクセスを与えるものであり、置き換えるものではありません。

XcodeBuildMCPはSwiftPM専用プロジェクトで動作しますか？

はい。XcodeBuildMCPは.xcodeproj/.xcworkspaceとSwift Package Managerプロジェクトの両方をサポートします。discover_projsを使って利用可能なプロジェクトタイプを見つけ、適切なスキームでbuild_simまたはbuild_deviceを実行してください。

CI/CDパイプラインについてはどうですか？

MCPサーバーはローカルでClaude Codeとともに動作します。CI/CDの場合は、引き続きxcodebuildを直接使うか、Fastlaneのようなツールを使うことになります。MCPアプローチは、AIエージェントがコード・ビルド・テストサイクル中に構造化されたフィードバックを必要とするインタラクティブな開発ループに特化しています。

MCPとは何で、AI開発ツールにとってなぜ重要なのですか？

Model Context Protocol（MCP）は、AIエージェントが構造化されたJSONリクエストとレスポンスを通じて外部ツールと通信する方法を定義するオープンスタンダードです。MCP以前、エージェントはシェルコマンドを実行し、その構造化されていないテキスト出力を解析することで開発ツールと対話していました。これは出力フォーマットが変わると壊れる脆弱なアプローチで、ノイズにコンテキストウィンドウのトークンを浪費します。MCPはインターフェースを標準化します。エージェントは構造化されたリクエスト（パラメータ付きのbuild_sim）を送信し、ツールは構造化されたレスポンス（分類済みエラー、ファイルパス、行番号を含むJSON）を返します。エージェントのタスクは解析から推論へとシフトします。MCPはAIエージェントツーリングにとって、RESTがWeb APIsにとってそうであったのと同じ存在です。任意のツールが任意のエージェントに構造化された機能を公開できる共有プロトコルなのです。