シミュレータでの全工程を Codex に一任

このユースケースは、適切なアプリターゲットの選択、シミュレータでのアプリ起動、現在の画面の確認、再現手順の実行、ログとスクリーンショットの収集、必要に応じたスタックトレースの確認、コードの修正、同じ手順の再実行によるバグ解消の実証まで、全工程を Codex に任せると最も効果的です。

このループをエージェント主導で維持したい場合は、Build iOS Apps プラグイン を使用してください。その iOS デバッガーワークフローは XcodeBuildMCP を中心に構築されているため、Codex は起動済みのシミュレータを操作し、人が通常は手作業で収集するものと同じ証拠を集められます。

XcodeBuildMCP にシミュレータ自動化、UI 自動化、デバッグ、ログ収集の各ワークフローが設定されていれば、Codex は再現・デバッグ・検証の全ループを担えます。Codex がまだプロジェクト、スキーム、シミュレータを選択していない場合は、まずそれらを特定し、残りのセッションでもその設定を再利用するよう依頼してください。

XcodeBuildMCP の機能活用

Codex に活用させたい実用的な機能グループは次のとおりです：

• プロジェクトとシミュレータの特定：使用するアプリターゲットとシミュレータを Codex がすでに把握しているか確認し、Xcode プロジェクトまたはワークスペースを特定してスキームを列挙し、使用可能なシミュレータを検索するか起動して、以降のビルド／実行手順でも同じ設定を維持します。
• ビルドと起動の制御：アクティブなアプリターゲットをビルドし、シミュレータ向けビルドをインストールして起動し、必要に応じてログ取得を有効にして再起動します。また、Codex がアプリ固有のランタイムログを調べる必要がある場合は、アプリのバンドル ID を特定します。
• UI の検査と操作：画面上のアクセシビリティ階層を読み取り、スクリーンショットを撮影し、コントロールをタップし、フィールドに入力し、リストをスクロールして、画面端からのスワイプなどのシミュレータジェスチャーを実行します。
• ログとデバッガーの状態：シミュレータのログをストリーミングし、実行中のアプリに LLDB をアタッチし、ブレークポイントを設定して、スタックフレームとローカル変数を調べます。クラッシュやハングを詳しく調査する必要がある場合は、デバッガーコマンドも実行します。

重要なのは、タップ前にビュー階層を確認するよう Codex に指示することです。XcodeBuildMCP ではアクセシビリティ階層と座標を取得できるため、Codex は画面上の位置を推測する代わりに、安定したラベルや要素 ID を優先できます。

曖昧なバグから再現可能なスクリプトへ

iOS デバッガースキルは、プロンプトで具体的なバグを 1 つと期待する結果を 1 つ提示し、その後は Codex にアプリの操作と証拠収集を自律的に任せると最も効果的です。ログイン、ディープリンク、テストフィクスチャが必要な場合は、その旨を一度だけ伝え、不足している情報が作業を妨げる場合に限って中断するよう Codex に指示してください。

実践的なヒント

修正に加えて証拠も要求

Codex がバグの説明に実際に使用したシミュレータ、スキーム、スクリーンショット、ログ抜粋、スタックの詳細を提示するよう求めてください。そうすれば、最終パッチは「これで直ると思います」という説明だけの場合よりも、はるかにレビューしやすくなります。

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

コントロールに安定したラベルやアクセシビリティ識別子がなく、Codex が座標を使ってタップせざるを得ない場合は、その点を明記するよう求めてください。これは多くの場合、バグ修正に UI のテスト容易性を少し高める変更も含めるべきだというサインです。

1 回の実行につき 1 件のバグ

シミュレータ主導のデバッグループは強力ですが、1 つのプロンプトで 1 つの障害モードだけを対象にすると、結果をより信頼しやすくなります。関連する問題に対象を広げる前に、再現・修正・検証のサイクルを 1 回完了するよう Codex に依頼してください。