はじめに
タップルでエンジニアをしている伊藤です。
2026 年 2 月、Apple が Xcode 26.3 をリリースしました。このアップデートにより、iOS 開発における AI コーディングツールの活用が大きく前進しています。
この記事では、Xcode 26.3 で何が変わったのかを「以前との差分」をもとに説明し、具体的にできることと制約を整理した上で、タップルではどういう方針で導入しようとしているかを紹介します。
目次
Xcode 26.3 で何が嬉しくなったのか
まず、Xcode 26.3 が出る前にどんな課題があったのかを振り返り、このアップデートで何が解消されたのかを整理します。
Xcode 26.3 が出る前の課題
Coding Agent との連携が大変だった
Claude Code や Cursor などの外部 Coding Agent に iOS アプリのコードを書かせること自体はできていました。しかし、ビルドやテストの結果をフィードバックして自律的に修正させるのが難しい状態でした。
連携手段は xcodebuild か xcodebuildmcp（サードパーティ）の二択で、それぞれに課題がありました。
xcodebuildを直接使う場合: ビルドログが膨大で、そのまま AI に食わせるとコンテキストを圧迫してしまいます。ログをフィルタリング・整形する仕組みを自前で作る必要がありましたxcodebuildmcpを使う場合: サードパーティのツールなので、Apple 公式の MCP サーバーが出ることを待っていた、というのが正直なところです
Xcode 上での AI 利用にも限界があった
Xcode 26.0 の時点でも、Claude や GPT を使ったコード補完・生成は可能でした。ただし、ビルドなど特定のタスクを実行させ、その結果をもとに自律的に修正を繰り返す、といった Agentic なワークフローはできませんでした。AI は「聞かれたことに答える」存在であり、「自分で試して直す」ことはできなかったのです。
Xcode 26.3 で変わったこと
Xcode MCP の登場
Apple 公式の MCP サーバーが公開されました。xcrun mcpbridge を起動するだけで、任意の Coding Agent から Xcode のビルド・テスト・Preview などの機能を利用できます。
特徴的なのは Xcode の UI と連動する点です。MCP 経由でビルドをかけると、Xcode 上の UI にもビルド中の状態やビルドログがリアルタイムに反映されます。ターミナルで AI が何をやっているか分からない、ということがありません。
さらに、RenderPreview というツールが追加されました。従来、AI が生成した UI を確認するには Snapshot Test を書いてその結果画像を渡す、といった手間が必要でした。Xcode MCP なら、SwiftUI の #Preview さえ書いていれば Preview 画像を取得して Coding Agent に見せることができます。
Xcode 内で Coding Agent が利用可能に
Xcode 26.3 では、Xcode の中から直接 Claude Agent や OpenAI Codex を呼び出せるようになりました。プロジェクト全体の構成を把握させた上で横断的なタスクをこなしたり、ビルド・テストの結果をもとに修正を繰り返す自律的なワークフローが可能になっています。
また、Coding Agent ごとに設定ファイル（.claude.json 等）を書くことができ、MCP サーバーやスキルなどのカスタマイズも可能です。
Xcode 26.3 でできることの詳細
ここからは、Xcode MCP と In-Xcode（Xcode 内蔵の Coding Agent）それぞれについて、できることと制約を整理していきます。
Xcode MCP
MCP ツールの全体像
xcrun mcpbridge が公開する MCP サーバーからは、4 カテゴリ・全 20 個のツールが利用できます。
| カテゴリ | ツール数 | 主なツール |
|---|---|---|
| ファイル操作 | 9 | XcodeWrite, XcodeRead, XcodeGlob, XcodeGrep など |
| ビルド・テスト | 5 | BuildProject, RunAllTests, RunSomeTests など |
| 診断・分析 | 3 | XcodeListNavigatorIssues, XcodeListWindows など |
| 特殊機能 | 3 | RenderPreview, ExecuteSnippet, DocumentationSearch |
この中から、特に注目すべきツールを 3 つ紹介します。
1. XcodeWrite ── ファイルのプロジェクト自動追加
Xcode プロジェクトに新しいファイルを追加するとき、XcodeWrite を使うとファイル作成と同時に .pbxproj へも自動追加されます。Claude Code 標準の Write コマンドだとファイルは作られますがプロジェクトには追加されないため、ビルド対象になりません。
| プロジェクト形式 | XcodeWrite | Write（Claude Code 標準） |
|---|---|---|
| objectVersion 77（Xcode 26 の新形式） | ビルド対象になる | ビルド対象になる |
| objectVersion 76 以前（従来形式） | ビルド対象になる | ビルド対象にならない |
objectVersion 77 ではファイルシステムとプロジェクト構造が自動同期されるため Write でも動きますが、旧形式のプロジェクトでは XcodeWrite を使わないとビルド対象になりません。
2. BuildProject ── 正確なエラー情報
ビルドエラーにはファイルパス・行番号・メッセージが正確に含まれます。xcodebuild のように膨大なログをフィルタリングする必要がなく、AI が修正→再ビルドのサイクルを効率的に回せます。
// BuildProject のエラーレスポンス例
errors: [
{
"classification": "error",
"file": "WeatherApp/Views/ContentView.swift",
"line": 42,
"message": "Cannot convert value of type 'String' to expected argument type 'Int'"
}
]GetBuildLog を併用すれば、どの Build Phase で失敗したかまで確認できます。
3. RenderPreview ── SwiftUI Preview のスナップショット
SwiftUI の #Preview を画像として取得できます。AI に UI の見た目を確認させて、意図通りかどうかを判断させることが可能になりました。
ただし注意点として、RenderPreview は初期レンダリング直後のスナップショットしか撮れません。.task で非同期にデータを取ってくる画面だと、ローディング中の状態しかキャプチャできません。ロード完了後の UI を確認したい場合は、サンプルデータを注入した専用の #Preview を用意する必要があります。
#Preview("Loaded") {
let viewModel = {
let vm = WeatherViewModel()
vm.weatherList = WeatherViewModel.sampleData
return vm
}()
ContentView(viewModel: viewModel)
}Xcode MCP の制約
Scheme が選べない ── 最大の制約
Xcode MCP の最大の制約です。tabIdentifier でどのプロジェクトかは指定できますが、そのプロジェクト内の Scheme やビルド先（iOS / macOS / シミュレータ）を選択する機能がありません。
マルチプラットフォームのプロジェクトだと、意図しないデスティネーションが勝手に選ばれてしまいます。実際に Point-Free の isowords（iOS 専用・270 以上のテスト）で試したところ、macOS 向けにビルドしようとして以下のようなエラーになりました。
'UIKit' is unavailable in macOS
'AVAudioSession' is unavailable in macOS| 影響を受けるツール | 影響 |
|---|---|
| BuildProject | 間違ったデスティネーションでビルドエラーになる |
| RunSomeTests / RunAllTests | ビルドが通らないのでテストも動かない |
| ファイル操作・診断系 | Scheme に関係ないので影響なし |
現状の回避策は、Xcode UI で事前に正しい Scheme を選んでおくか、単一ターゲットのシンプルなプロジェクトを使うことです。
その他の制約
| 制約 | 詳細 |
|---|---|
| プロジェクト作成機能がない | .xcodeproj を手動で生成して open で読み込む必要がある |
| RenderPreview が不安定 | MCP 経由で呼ぶと応答が返ってこないことがある。Xcode の再起動で復旧する |
| ランタイムデバッグ不可 | コンパイルエラーしか検出できない。実行時のバグは検出不可能 |
In-Xcode（Xcode 内蔵の Coding Agent）
どんな挙動になるか
Xcode の中から Claude Agent や OpenAI Codex を直接呼び出して使います。開発者が指示を出すと、Xcode がプロジェクトのファイルツリー、開いているファイルの内容、Import 先の SDK シンボル情報、Git の状態などを 毎ターン自動的に AI に注入してくれます。
ビルドや修正のループも Xcode が自動で回してくれるので、体感としては「Xcode に頼んだら勝手にやってくれる」に近いです。
CLI（Claude Code / Cursor）で使った場合との違い
| 観点 | In-Xcode | CLI（Claude Code 等） |
|---|---|---|
| プロジェクト情報 | Xcode が毎ターン自動注入 | AI がツールで都度取得 |
| ビルド・修正ループ | Xcode が自動で回す | AI が明示的にツールを呼んで実行 |
| 操作感 | 指示を出したら待つだけ | AI の動きをターミナルで見守る |
| 大規模プロジェクト | 毎回全情報を送るのでトークン消費が大きい | 必要な分だけ読むので効率的 |
| 設定共有 | Xcode 内に閉じるため工夫が必要 | CLAUDE.md 等をリポジトリに入れるだけ |
| 他ツールとの連携 | .claude.json で MCP 追加可能 |
GitHub MCP・Firebase MCP 等と自由に組み合わせ |
CLI ベースの方が「必要な情報だけ取りに行く」ことができるため、大きなプロジェクトではコンテキスト効率が良くなります。一方、In-Xcode はセットアップ不要で手軽に始められるのが利点です。
チームで統一的に導入する場合は、設定をコードとして管理できる CLI ベース（CLAUDE.md + .claude/settings.json + .mcp.json をリポジトリに含める）の方が向いています。
In-Xcode の制約
| 制約 | 詳細 |
|---|---|
| シェル環境が継承されない | .zshrc や PATH が効かないため、Homebrew 等のツールにアクセスできない場合がある |
| ネットアクセス許可が Codex だけ | 「インターネットアクセスツールを許可」の設定が Codex にのみ適用される。Claude Agent は個別にコマンドを許可する必要がある |
| プライバシー保護ディレクトリの問題 | Desktop 等のプロジェクトへのアクセスを拒否すると復旧が面倒。プロジェクトを別の場所に置くのが無難 |
タップルでの活用
ここからは、タップルでこれまでどのように AI コーディングの検証・導入を進めてきたか、そして Xcode 26.3 を受けてこれからどうしていくかを紹介します。
今まで検証・導入をしていたこと
Xcode 26.3 が出る前から、AI の書いたコードを検証して修正させるループを作る取り組みを進めていました。
xcodebuildmcp / xcodebuild を使ったビルド検証ループ
AI にコードを書かせた後、ビルドを回してエラーがあれば修正させる、というサイクルを回す仕組みです。前述のとおり、xcodebuild のビルドログが膨大でコンテキストを圧迫する課題や、xcodebuildmcp がサードパーティである点が気になっていました。
Visual Regression Test を利用した UI 検証
AI が生成した UI が意図通りかを確認するために、Visual Regression Test（スナップショットテスト）の結果画像を AI に見せて判断させる仕組みも検討していました。ただ、スナップショットテスト自体を書く・メンテナンスするコストが発生する点が課題でした。
これから
Xcode 26.3 の登場により、以下の 3 つの方針で活用を進めていきます。
1. RenderPreview を活用した UI 検証
Visual Regression Test の代わりに、Xcode MCP の RenderPreview を使った UI 検証に移行していきます。SwiftUI の #Preview さえ書いていれば、AI にビルド→プレビュー取得→確認→修正のサイクルを回させることができます。Snapshot Test を書く手間が省け、より軽量に UI の検証が可能になります。
2. Xcode MCP のビルド・テストを利用する（利用可能な箇所で）
xcodebuild や xcodebuildmcp の代わりに、Xcode MCP の BuildProject / RunSomeTests / RunAllTests を活用します。ビルドエラーのファイルパス・行番号が正確に返ってくるため、修正サイクルの精度が上がります。
ただし、現状の Xcode MCP は tabIdentifier しか指定できず、Scheme を指定したビルド・テストができません。タップルのプロジェクトのように複数の Scheme を持つ場合、ユーザーが Xcode 上で事前に正しい Scheme を選択しておく必要があります。この制約があるため、利用可能な箇所から段階的に導入していく方針です。
3. AI Agent からのファイル追加・削除に Xcode MCP を利用する
AI がファイルを追加・削除する際に、Claude Code 標準の Write ではなく Xcode MCP の XcodeWrite / XcodeRM を使うようにします。これにより、ファイルが自動的に Xcode プロジェクトに追加され、ビルド対象として認識されます。特に objectVersion 76 以前の旧形式プロジェクトでは、この違いが大きく効いてきます。
まとめ
Xcode 26.3 で何が変わり、タップルでどう活用していくかを紹介しました。要点を 3 つにまとめます。
- Xcode MCP により、AI とビルドシステムの連携が公式にサポートされた: Apple 公式の MCP サーバーが出たことで、サードパーティツールに頼らず、任意の Coding Agent から Xcode のビルド・テスト・Preview を利用できるようになりました
- In-Xcode の Coding Agent で、Xcode 内での自律的なコーディングが可能になった: プロジェクト情報の自動注入やビルドループの自動化など、「指示を出したら待つだけ」の体験が実現しています
- Scheme が選べないなど制約は残るが、段階的に導入する価値がある: RenderPreview を活用した UI 検証や、XcodeWrite によるプロジェクト統合など、現時点でも実用的な活用ポイントがあります
Xcode 26.3 はまだ完璧ではありませんが、iOS 開発の AI 活用を一段階引き上げてくれるアップデートだと感じています。今後のアップデートで Scheme 選択や RenderPreview の安定性が改善されれば、さらに活用の幅が広がるはずです。