シミュレータでの再現から検証までを Codex に一任

このユースケースでは、シミュレータでの作業を最初から最後まで Codex に任せると効果的です。Codex は適切なアプリターゲットを選び、シミュレータでアプリを起動します。現在の画面を確認して再現手順を実行し、ログとスクリーンショットを収集します。必要に応じてスタックトレースを調べ、コードを修正したうえで同じ操作を繰り返し、不具合が解消したことを確認します。

この一連の作業を Codex に自律的に進めてもらうには、Build iOS Apps プラグインを使います。プラグインの iOS デバッガーワークフローは XcodeBuildMCP を利用しているため、Codex は起動済みのシミュレータを操作し、通常は開発者が手作業で集めるログやスクリーンショットなどを収集できます。

XcodeBuildMCP でシミュレータ操作の自動化、UI 操作の自動化、デバッグ、ログ収集の各ワークフローを設定しておけば、不具合の再現からデバッグ、検証まで Codex に任せられます。プロジェクト、スキーム、シミュレータがまだ決まっていない場合は、まず Codex に候補を調べて選ぶよう依頼し、そのセッションでは同じ設定を使うよう伝えます。

XcodeBuildMCP の活用

Codex には、次の機能を使うよう依頼できます。

• プロジェクトとシミュレータの特定：使用するアプリターゲットとシミュレータを Codex がすでに把握しているか確認します。Xcode プロジェクトまたはワークスペースを探し、スキームを一覧にして、シミュレータを見つけるか起動します。以降のビルドと実行でも同じ設定を使います。
• ビルドと起動の制御：現在選択されているアプリターゲットをビルドし、シミュレータ用のビルドをインストールして起動します。必要に応じてログを記録しながらアプリを再起動します。アプリ固有の実行時ログを調べる場合は、アプリのバンドル ID を特定します。
• UI の確認と操作：画面のアクセシビリティ階層を読み取り、スクリーンショットを撮影します。コントロールのタップ、フィールドへの入力、リストのスクロールのほか、画面の端からのスワイプなどのジェスチャもシミュレータで実行できます。
• ログとデバッガーの状態：シミュレータのログをリアルタイムで取得し、実行中のアプリに LLDB をアタッチします。ブレークポイントを設定し、スタックフレームやローカル変数を確認できます。クラッシュやハングを詳しく調べる必要がある場合は、デバッガーのコマンドを実行します。

タップする前にビュー階層を確認するよう、毎回 Codex に指示します。XcodeBuildMCP からはアクセシビリティ階層と各要素の座標を取得できます。そのため、Codex は画面上の位置を推測せずに、安定したラベルや要素 ID を優先して操作対象を選べます。

曖昧な不具合報告から再現スクリプトへ

iOS デバッガースキルを効果的に使うには、プロンプトで具体的な不具合を 1 つ挙げ、期待する結果を 1 つ示します。そのうえで、アプリの操作と調査に必要な情報の収集を Codex に任せます。ログイン、ディープリンク、テストフィクスチャが必要なら、その条件を最初に一度伝えます。必要なものがなくて作業を続けられない場合に限り、一時停止するよう依頼します。

実践のヒント

修正内容とその根拠

使用したシミュレータとスキームを具体的に示し、不具合の説明に使ったスクリーンショット、ログの抜粋、スタックの詳細も提示するよう Codex に依頼します。「これで直ると思います」という説明だけの場合に比べて、最終的なパッチをレビューしやすくなります。

座標よりもアクセシビリティラベルを優先

コントロールに安定したラベルやアクセシビリティ識別子がなく、座標を指定してタップする必要がある場合は、その旨を報告するよう Codex に依頼します。こうしたケースでは、不具合の修正に合わせて UI にも少し手を加え、テストしやすくするとよいでしょう。

1 回の実行につき 1 つの不具合

シミュレータを使ったデバッグは強力ですが、1 つのプロンプトで扱う不具合のパターンを 1 つに絞ると、結果をより信頼できます。関連する問題に取りかかる前に、まず 1 つの不具合の再現、修正、検証を終えるよう Codex に依頼します。