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

私はClaude Codeで11のiOSアプリを開発しています。Gitの安全性を守るフック、コード品質を強制するルール、チームのパターンを体系化したエージェント定義があります。しかし昨日まで、ビルドエラーが発生するたびにターミナル出力をコピーし、それを貼り付けて、エージェントがコンテキストを理解してくれることを祈るしかありませんでした。シミュレータ管理は生のxcrun simctlコマンドでした。テスト結果は構造化されていないテキストの壁として返ってきました。

2つのclaude mcp addコマンドで、それが変わりました。

TL;DR

XcodeBuildMCP（76ツール、オープンソース）は、ビルド、テスト、シミュレータ、実機デプロイ、LLDBデバッグを処理します——すべてXcodeを起動せずに。AppleネイティブのXcode MCP（20ツール、Xcode 26.3に同梱）は、実行中のXcodeプロセスにブリッジし、ファイル操作、リアルタイム診断、ドキュメント検索、Swift REPL、SwiftUIプレビューを提供します。この2つを組み合わせることで、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と関連ツールを76の構造化されたMCPツールにラップします。エージェントがxcode_buildを呼び出すと、3,000行のビルドログではなく、カテゴリ分けされたエラー、警告、ファイル位置を含むJSONが返されます。

主要ツール：

インストール：

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

-s userフラグはグローバルに設定します——プロジェクトごとの設定なしに、すべてのプロジェクトで利用可能になります。環境変数はテレメトリを無効にします（デフォルトではクラッシュレポートがSentryに送信されますが、私はオプトアウトを好みます）。¹

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

AppleはXcode 26.3でxcrun mcpbridgeを通じて独自のMCPサーバーを出荷しました。XPC経由でXcodeのプロセスに直接ブリッジする20のツールを公開しています：

インストール：

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

Xcode 26.3以降が必要です（現在リリース候補、間もなく出荷予定）。

なぜ両方必要なのか？

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

• XcodeBuildMCPはxcodebuild CLI経由でスタンドアロンで動作します——Xcodeプロセスは不要です。シミュレータ、実機、LLDBデバッグ、UIオートメーション、プロジェクトスキャフォールディングをカバーする76のツールを追加します。ヘッドレスワークフローやCI隣接の開発に最適です。
• Apple Xcode MCPは実行中のXcodeインスタンスが必要で、XPC経由で通信します。Xcodeプロジェクトコンテキスト内でのファイル操作、リアルタイムのコード診断（ビルド出力だけでなく）、WWDCセッションを含むネイティブドキュメント検索を提供します。

私は両方を使っています：XcodeBuildMCPはビルド-テスト-デバッグサイクルに（Xcodeを開かずに動作します）、AppleのMCPはドキュメント検索、Swift REPLでの検証、SwiftUIプレビューのレンダリングが必要な場合に使います。

実際のテスト

私の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を使用しました。エージェントはiOS 26ランタイムにiPhone 16 Proが存在しないことを発見し（廃止されていたため）、自動的に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

構造化された出力のおかげで、これらはログに埋もれることなく、正確なファイル:行参照付きのカテゴリ分けされた警告として返されました。

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

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

結果テーブル

ヘルスチェック全体が自律的に実行されました。Xcodeを開くことも、エラーメッセージをコピーすることも、xcodebuildコマンドを構築することもありませんでした。

エージェントへの教示

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のドキュメントを検索したりすることがあります。エージェント定義がそのギャップを埋めます。²

実際に何が変わるのか

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を通じて自身を公開する開発ツールです。³

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

iOSプロジェクトでClaude Codeを使っている方へ：

1. XcodeBuildMCPをインストール（Xcode 26.3以降が必要）： 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ビルドシステムへの完全なアクセスが得られます。

FAQ

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エージェントがコード-ビルド-テストサイクル中に構造化されたフィードバックを必要とするインタラクティブな開発ループに特化しています。