axiom-build

ビルドと環境

アプリケーションコードのデバッグに取りかかる前に、ビルド、環境、または Xcode 関連の問題には必ずこのスキルを使用してください。

Claude Code にバンドルされているツールの場合： command -v <tool> で何も見つからない場合（フックが無効、または --bare の場合）は、裸の名前の代わりに <plugin-root>/tools/<tool> を使用してください。<plugin-root> は、このスキルの Base directory for this skill: パスから 2 つ上の階層にあります。

Axiom エージェントを起動できませんか？ このルーターからエージェントに案内された場合は、その手順をインラインで実行してください。MCP 経由では axiom_get_agent がそのエージェントを返します。それ以外の場合は、以下にあるファイルを読み取ってください。必要なのはファイルの検索と読み取りだけです。

ここで利用可能：skills/modernization-helper.md。 別のスイートにあります：axiom-security/skills/security-privacy-scanner.md。

それ以外のエージェントも、MCP 経由では axiom_get_agent が返します。そのエージェントの xclog、xcsym、xcprof の手順を、それぞれ axiom_xclog_*、axiom_xcsym_*、axiom_xcprof_* ツールで実行してください。それ以外の場合は、Axiom のスキルから skills/<agent>.md を検索してください。見つからなければ、このスイートのスキルを使って自分で作業し、PATH 上にある Axiom ツールを使用してください。

ビルドとテストの診断情報を取得する

次に必要となるビルドまたはテストを実行する前に、Claude Code では実際に読み込まれているパッケージ内の tools/axbuild（command -v axbuild。見つからない場合は、読み込まれた Axiom スキルの Base directory for this skill: のパスから2階層上にある tools/axbuild）、Codex では <plugin-root>/tools/ 内の tools/axbuild を特定するか、Pi では PATH 上の実行可能ファイルを探してください。実行権限を確認し、その絶対パスに --help を付けて実行してください。確認したパスを AXBUILD に割り当てます。例からインストール先のパスを推測してはいけません。

Cursor および MCP の配布物には axbuild が同梱されておらず、axbuild MCP ラッパーもありません。確認済みのシェルヘルパーを利用できない場合は、以下の保存ログによる代替手順を使用してください。

Xcode を起動するたびに、起動前に pgrep -lx xcodebuild; echo "pgrep exit=$?" を実行してください。終了コードが1の場合は実行中のプロセスはありません。0の場合はプロセスが表示されます。それ以外の終了コードは、プロセス一覧の取得に失敗したことを示します。既存のビルドを調査してください。プロセス数や経過時間だけでゾンビ状態とは判断できません。無関係なプロセスを終了させてはいけません。中断またはタイムアウトした場合、axbuild は、クリーンアップ開始時および各クリーンアップ処理で親子関係をたどって検出した、Xcode によって別のプロセスグループへ移動されたビルドスクリプトや、ビルドから派生したその他のプロセスも停止します。停止または状態を確認できなかった派生プロセス（他のユーザーのもの、読み取り不可のもの、デバッグ中のもの）がある場合は、cleanup-incomplete を報告します。デーモンや launchd が起動したツールなど、すでにビルドのプロセスツリーから外れていたジョブは停止も報告もされません。axbuild が一覧に表示したものを停止する前に、所有者を確認してください。実行前に実際のスキームと実行先を特定してください。

"$AXBUILD" xcodebuild -scheme "$SCHEME" -destination "$DESTINATION" build
"$AXBUILD" swift test --package-path "$PACKAGE"

呼び出し元のフラグ、作業ディレクトリ、環境、テストの選択、カバレッジ、明示的に指定された成果物のパスを保持してください。ラッパーは、指定されていない診断用の既定値を追加します。キャッシュのクリーンアップや自動再ビルドは行いません。ビルドを別のコマンドにパイプしてはいけません。

command（ネイティブの実行結果）と collection（証拠の収集状況）は分けて確認してください。ネイティブ実行が成功していても、収集が不完全な場合があります。既定の JSON は UTF-8 で8,000バイトに制限されています。omissions を確認し、完全な記録と評価済みの値は、絶対パスの artifacts.run ディレクトリを基準に artifacts.report を読み取って確認してください。起動時の stderr JSON には、処理完了前に実行ディレクトリが記録されます。出力を再表示するためにビルドをやり直すのではなく、診断箇所と値を使用してください。

保持されたログが主要なコンパイラ情報源です。テスト結果と検証済みの Swift Testing イベントは、それを補完します。失敗したテストの件数が null の場合、0件ではなく不明であることを意味します。添付ファイルのエクスポート、カバレッジ、コンソールログ、詳細な調査のために、結果バンドルを保持してください。ネイティブの情報表示コマンドは、出力をそのまま通します。

保存ログによる代替手順： 必要なネイティブコマンドの標準出力と標準エラーを一意のファイルにリダイレクトし、処理の完了を待って、終了ステータスを記録し、保存したファイルを確認してください。xcresult のビルド概要は、コンパイラログと同等ではありません。別のビルドを検討する前に、既存のログを読んでください。ビルド出力が切り詰めを示すマーカーで終わっている場合、または xcodebuild の終端行 ** BUILD … ** か ** TEST … ** が出力される前に終わっている場合は、再ビルドするのではなく、保存ログまたはレポートを読んでください。

使用する場面

次のような状況に遭遇した場合は、このルーターを使用してください。

• ビルドの失敗（BUILD FAILED、コンパイルエラー、リンカーエラー）
• テストのクラッシュまたはハング
• シミュレーターの問題（起動しない、デバイスエラー）
• Xcode の不具合（古いビルド、ゾンビプロセス）
• 依存関係の競合（CocoaPods、SPM）
• ビルドのパフォーマンスの問題（コンパイルが遅い）
• コードのデバッグ前に発生する環境の問題

ルーティングのロジック

このルーターは、具体的な問題に応じて専用のスキルを呼び出します。

1. 環境に起因する問題 → xcode-debugging

該当するケース：

• 明らかなコード上の原因がないのに BUILD FAILED が発生する
• クリーンなプロジェクトでテストがクラッシュする
• シミュレーターがハングする、または起動しない
• SPM の変更後に「No such module」が発生する
• ゾンビ状態の xcodebuild プロセスがある
• ビルドが古い（古いコードがまだ実行されている）
• クリーンビルドとインクリメンタルビルドの結果が異なる
• Xcode 27（OS27）で Device Hub／予測と実際のビルドの不一致に関する問題がある
• シミュレーターでデバイス固有のバグを再現する（Device Hub）（OS27）

最初に xcode-debugging を使う理由：不可解な問題の90％は、コードではなく環境に起因します。コードのデバッグを始める前に確認してください。

実行方法：skills/xcode-debugging.md

---

2. ビルドが遅い → build-performance

該当するケース：

• コンパイルに時間がかかりすぎる
• 型チェックがボトルネックになっている
• ビルド時間を最適化したい
• Build Timeline で時間のかかるフェーズが表示される

実行方法：skills/build-performance.md

---

3. SPM の依存関係の競合 → spm-conflict-resolver（エージェント）

該当するケース：

• SPM の解決に失敗する
• パッケージ追加後に「No such module」が発生する
• シンボルの重複によるリンカーエラーが発生する
• パッケージ間でバージョンの競合がある
• Swift 6 パッケージの互換性に問題がある
• Package.swift／Package.resolved の競合がある

spm-conflict-resolver を使う理由：Package.swift と Package.resolved を分析し、Swift Package Manager の競合を診断して解決する専門エージェントです。

実行方法：spm-conflict-resolver エージェントを起動します

---

4. セキュリティとプライバシーの監査 → security-privacy-scanner（エージェント）

該当するケース：

• App Store 提出の準備
• プライバシーマニフェストの要件（iOS 17 以降）
• コードに認証情報がハードコードされている
• 機密データの保存に懸念がある
• ATS 違反
• Required Reason API の宣言

security-privacy-scanner を使う理由：セキュリティの脆弱性とプライバシーコンプライアンス上の問題をスキャンする専門エージェントです。

実行方法：security-privacy-scanner エージェントまたは /axiom:audit security を実行します

---

5. iOS 17→18 のモダナイゼーション → modernization-helper（エージェント）

該当するケース：

• ObservableObject から @Observable に移行する
• @StateObject を @State に更新する
• 最新の SwiftUI パターンを採用する
• 非推奨 API を整理する
• iOS 17 以降への移行

modernization-helper を使う理由：従来のパターンをスキャンし、コード例とともに移行方法を提示する専門エージェントです。

実行方法：modernization-helper エージェントまたは /axiom:audit modernization を実行します

---

6. ビルド失敗の自動修正 → build-fixer（エージェント）

該当するケース：

• 明確なエラーの詳細がないのに BUILD FAILED が発生する
• ビルドが成功したり失敗したりする
• アプリはビルドされるが、古いコードが実行される
• 「Unable to boot simulator」エラーが発生する
• 環境を優先した診断を自動化したい

build-fixer を使う理由：コードを調査する前に、ゾンビプロセス、Derived Data、SPM キャッシュ、シミュレーターの状態を確認する自律型エージェントです。環境の問題にかかる時間を30分以上短縮できます。

実行方法：build-fixer エージェントまたは /axiom:fix-build を実行します

---

7. ビルドの遅さを最適化 → build-optimizer（エージェント）

該当するケース：

• ビルドに時間がかかりすぎる
• 時間のかかる型チェックを特定したい
• ビルドフェーズのスクリプトにコストがかかっている
• ビルド設定が最適ではない
• 並列化の機会を探したい

build-optimizer を使う理由：Xcode プロジェクトをスキャンして、時間のかかる型チェック、コストのかかるスクリプト、最適でない設定など、ビルドパフォーマンスを最適化できる箇所を特定し、ビルド時間を30〜50％短縮します。

実行方法：build-optimizer エージェントまたは /axiom:optimize-build を実行します

---

8. 一般的な依存関係の問題 → build-debugging

該当するケース：

• CocoaPods の解決に失敗する
• 「Multiple commands produce」エラーが発生する
• フレームワークのバージョンが一致しない
• SPM 以外の依存関係グラフで競合がある

実行方法：skills/build-debugging.md

---

9. TestFlight のクラッシュトリアージ → testflight-triage

トリガー：

• ベータテスターからクラッシュの報告があった
• Xcode Organizer にクラッシュレポートがある
• クラッシュログがシンボリケートされていない
• スクリーンショット付きの TestFlight フィードバックがある
• アプリが終了されたが、クラッシュレポートがない

testflight-triage を使う理由：TestFlight のクラッシュ調査とベータフィードバックの確認を体系的に進めるワークフローです。シンボリケーション、クラッシュの解釈、よくあるパターン、Claude による分析を網羅しています。

呼び出し方法：axiom-shipping（skills/testflight-triage.md）を参照してください

---

10. App Store Connect ナビゲーション → app-store-connect-ref

トリガー：

• App Store Connect でクラッシュを見つける方法を知りたい
• ASC のメトリクスダッシュボードの操作方法を知りたい
• クラッシュのないユーザーの割合を理解したい
• バージョン間でクラッシュ率を比較したい
• ASC からクラッシュデータをエクスポートしたい
• クラッシュデータ用の App Store Connect API を使いたい

app-store-connect-ref を使う理由：ASC のクラッシュ分析、メトリクスダッシュボード、データエクスポートのワークフローを操作するためのリファレンスです。

呼び出し方法：axiom-shipping（skills/app-store-connect-ref.md）を参照してください

---

11. クラッシュログ分析 → crash-analyzer（エージェント）

トリガー：

• 分析する .ips または .crash ファイルがある
• クラッシュレポートのテキストが貼り付けられた
• クラッシュログをプログラムで解析したい
• 例外の種類からクラッシュのパターンを特定したい
• シンボリケーションの状態を確認したい

crash-analyzer を使う理由：クラッシュレポートを解析し、パターン（null ポインター、Swift ランタイム、ウォッチドッグ、jetsam）を特定して、実行可能な分析結果を生成する自律型エージェントです。

呼び出し方法：crash-analyzer エージェントまたは /axiom:analyze-crash を起動してください

---

12. MetricKit API リファレンス → metrickit-ref

トリガー：

• MetricKit のセットアップとサブスクリプション
• MXMetricPayload の解析（CPU、メモリ、起動、ヒッチ）
• MXDiagnosticPayload の解析（クラッシュ、ハング、ディスク書き込み）
• MXCallStackTree のデコードとシンボリケーション
• フィールドでのクラッシュ／ハング収集
• バックグラウンド終了のメトリクス

metrickit-ref を使う理由：セットアップパターン、ペイロードの解析、クラッシュレポートシステムとの統合を含む、MetricKit API の完全なリファレンスです。

呼び出し方法：axiom-performance（skills/metrickit-ref.md）を参照してください

---

13. ハング診断 → hang-diagnostics

トリガー：

• アプリがハングまたはフリーズする
• メインスレッドが1秒を超えてブロックされる
• UI がタッチに反応しない
• Xcode Organizer にハング診断が表示される
• MetricKit から MXHangDiagnostic が届いた
• ウォッチドッグによる終了（起動中／バックグラウンドへの遷移中にアプリが終了される）

hang-diagnostics を使う理由：ビジー状態とブロック状態のメインスレッドを判別する決定木、ツールの選択（Time Profiler、System Trace）、修正方法付きのよくある8つのハングパターンを使って、ハングを体系的に診断します。

呼び出し方法：axiom-performance（skills/hang-diagnostics.md）を参照してください

---

14. ライブデバッグ → lldb

トリガー：

• クラッシュを対話的に再現したい
• ブレークポイントを設定して状態を確認したい
• クラッシュレポートの分析が終わり、次はライブで調査したい
• 実行中のアプリにデバッガーをアタッチしたい

lldb を使う理由：クラッシュレポートからは何がクラッシュしたかがわかります。LLDB を使えば、その理由がわかります。

呼び出し方法：skills/lldb.md

---

16. ランタイムコンソールのキャプチャ → xclog-ref

トリガー：

• アプリがランタイムに何をログ出力しているか確認したい
• アプリがクラッシュしたがクラッシュレポートがない（コンソール出力を確認したい）
• UI にフィードバックがないサイレントな障害（ネットワーク、データ、認証）がある
• シミュレーターから print()/os_log() の出力をキャプチャしたい
• 分析用に構造化されたログ出力が必要
• 「アプリは何を出力していますか？」

xclog-ref を使う理由：Xcode のデバッグコンソールには外部からアクセスできません。xclog は simctl の stdout/stderr と log stream の JSON を組み合わせ、print()、NSLog()、os_log()、Logger のすべての出力をキャプチャします。自動分析に使える構造化フィールド（レベル、サブシステム、カテゴリ）も含まれます。

呼び出し方法：/axiom:console

---

15. コード署名の問題 → code-signing

該当するケース：

• 「No signing certificate found」
• 「Provisioning profile doesn't include signing certificate」
• CI での errSecInternalComponent
• アップロード時の ITMS-90035 Invalid Signature
• ID が曖昧／複数の証明書がある
• エンタイトルメントの不一致、または必要な機能の不足
• CI/CD のコード署名の設定（GitHub Actions、fastlane match）
• 証明書の期限切れ、または失効

code-signing を使う理由：コード署名のエラーは、コードのバグでは決してありません。100％設定（証明書、プロファイル、エンタイトルメント、キーチェーン）が原因です。CLI ツールを使えば、推測に何時間も費やす代わりに、5 分で原因を診断できます。

呼び出し方法：ワークフローには axiom-security（skills/code-signing.md）を、トラブルシューティングには axiom-security（skills/code-signing-diag.md）を参照してください。

---

判断ツリー

1. 原因不明・断続的な問題、またはクリーンビルドの失敗ですか？ → xcode-debugging（環境を優先）
2. SPM の依存関係の競合ですか？ → spm-conflict-resolver（エージェント）
3. CocoaPods／その他の依存関係の競合ですか？ → build-debugging
4. ビルド時間が遅いですか？ → build-performance
5. セキュリティ／プライバシー／App Store の準備ですか？ → security-privacy-scanner（エージェント）
6. ビルドの自動修正（環境を優先した診断）が必要ですか？ → build-fixer（エージェント）
7. ビルド時間の最適化スキャンが必要ですか？ → build-optimizer（エージェント）
8. モダナイゼーション／非推奨 API への対応ですか？ → modernization-helper（エージェント）
9. TestFlight のクラッシュ／フィードバックですか？ → testflight-triage
10. App Store Connect の操作方法を知りたいですか？ → app-store-connect-ref
11. クラッシュログ（.ips／.crash）がありますか？ → crash-analyzer（エージェント）
12. MetricKit のセットアップ／解析ですか？ → metrickit-ref
13. アプリのハング／フリーズ／ウォッチドッグの問題ですか？ → hang-diagnostics
14. クラッシュを対話的に再現する／ランタイム状態を調べる必要がありますか？ → lldb
15. コード署名のエラー（証明書、プロファイル、エンタイトルメント、Keychain）ですか？ → code-signing / code-signing-diag
16. ランタイムのコンソール出力（print/os_log）を確認する必要がありますか？ → xclog-ref または /axiom:console

不合理な思い込みへの対処

考え	実際のところ
「このリンカーエラーの直し方は分かっています」	リンカーエラーには 4 つ以上の根本原因があります。xcode-debugging なら 2 分で原因を診断できます。
「とりあえずビルドフォルダをクリーンにします」	クリーンビルドでは、本当の問題が隠れてしまいます。xcode-debugging なら根本原因が分かります。
「これは単なる SPM の問題だから、Package.swift を直せばいいです」	SPM の競合は連鎖します。spm-conflict-resolver は依存関係グラフ全体を分析します。
「今日はシミュレーターが遅いだけです」	シミュレーターの問題は、環境の破損を示しています。xcode-debugging は体系的に確認します。
「ローカルではコンパイルできるので、環境チェックは省略します」	環境を優先すれば、毎回 30 分以上を節約できます。
「クラッシュを再現するより、クラッシュレポートをもっと注意深く読みます」	クラッシュレポートで分かるのは、何がクラッシュしたかであり、なぜクラッシュしたかではありません。LLDB でブレークポイントを設定して再現すれば、実際の状態を確認できます。skills/lldb.md にワークフローがあります。
「証明書は問題ないはずなので、コードを確認します」	コード署名のエラーは、コードのバグでは決してありません。100％設定が原因です。code-signing は CLI を使って 5 分で診断します。
「Xcode がないと、アプリのログを確認できません」	xclog は、シミュレーターから print() と os_log を取得します。レベル、サブシステム、カテゴリを含む構造化 JSON 出力が得られます。/axiom:console。

使用しないケース（競合の解決）

以下には axiom-build を使わず、適切なルーターを使ってください：

エラーの種類	適切なルーター	axiom-build を使わない理由
Swift 6 の並行処理エラー	/skill axiom-concurrency	コードエラーであり、環境の問題ではありません
SwiftData のマイグレーションエラー	/skill axiom-data	スキーマの問題であり、ビルド環境の問題ではありません
「Sending 'self' risks data race」	/skill axiom-concurrency	言語のエラーであり、Xcode の問題ではありません
型の不一致／コンパイルエラー	コードを修正	これらはコードのバグです

axiom-build は環境に関する原因不明の問題に使うものであり、コードエラーには使いません：

• ✅ コードに問題がないのに「No such module」と表示される
• ✅ シミュレーターが起動しない
• ✅ クリーンビルドは失敗するが、インクリメンタルビルドは成功する
• ✅ ゾンビ化した xcodebuild プロセス
• ❌ Swift の並行処理に関する警告／エラー
• ❌ データベースのマイグレーション失敗
• ❌ 有効なコードでの型チェックエラー

呼び出し例

ユーザー: 「リンカーエラーでビルドが失敗しました」 → 起動: skills/xcode-debugging.md (環境を最優先した診断)

ユーザー: 「ビルドに10分かかっています」 → 起動: skills/build-performance.md

ユーザー: 「SPM が依存関係を解決できません」 → 起動: spm-conflict-resolver エージェント

ユーザー: 「2つのパッケージが同じ依存関係の異なるバージョンを要求しています」 → 起動: spm-conflict-resolver エージェント

ユーザー: 「シンボル重複のリンカーエラー」 → 起動: spm-conflict-resolver エージェント

ユーザー: 「App Store のセキュリティレビューに向けた準備が必要です」 → 起動: security-privacy-scanner エージェント

ユーザー: 「Privacy Manifest は必要ですか？」 → 起動: security-privacy-scanner エージェント

ユーザー: 「コード内にハードコードされた認証情報はありますか？」 → 起動: security-privacy-scanner エージェント

ユーザー: 「ObservableObject から @Observable へはどう移行すればよいですか？」 → 起動: modernization-helper エージェント

ユーザー: 「モダンな SwiftUI パターンを使うようにコードを更新してください」 → 起動: modernization-helper エージェント

ユーザー: 「今でも @StateObject を使うべきですか？」 → 起動: modernization-helper エージェント

ユーザー: 「ベータテスターがアプリがクラッシュしたと言っています」 → 起動: axiom-shipping を参照 (skills/testflight-triage.md)

ユーザー: 「App Store Connect でクラッシュが表示されますが、調査方法がわかりません」 → 起動: axiom-shipping を参照 (skills/testflight-triage.md)

ユーザー: 「クラッシュログがシンボリケートされていません」 → 起動: axiom-shipping を参照 (skills/testflight-triage.md)

ユーザー: 「TestFlight のフィードバックを確認する必要があります」 → 起動: axiom-shipping を参照 (skills/testflight-triage.md)

ユーザー: 「App Store Connect でクラッシュを見つけるにはどうすればよいですか？」 → 起動: axiom-shipping を参照 (skills/app-store-connect-ref.md)

ユーザー: 「ASC のクラッシュフリーユーザー指標はどこにありますか？」 → 起動: axiom-shipping を参照 (skills/app-store-connect-ref.md)

ユーザー: 「App Store Connect からクラッシュデータをエクスポートするにはどうすればよいですか？」 → 起動: axiom-shipping を参照 (skills/app-store-connect-ref.md)

ユーザー: 「このクラッシュログを分析してください」[.ips の内容を貼り付け] → 起動: crash-analyzer エージェントまたは /axiom:analyze-crash

ユーザー: 「この .ips ファイルを解析してください: ~/Library/Logs/DiagnosticReports/MyApp.ips」 → 起動: crash-analyzer エージェントまたは /axiom:analyze-crash

ユーザー: 「なぜアプリがクラッシュしたのですか？レポートはこちらです...」 → 起動: crash-analyzer エージェントまたは /axiom:analyze-crash

ユーザー: 「クラッシュデータを収集するために MetricKit を設定するにはどうすればよいですか？」 → 起動: axiom-performance を参照 (skills/metrickit-ref.md)

ユーザー: 「MXDiagnosticPayload を解析するにはどうすればよいですか？」 → 起動: axiom-performance を参照 (skills/metrickit-ref.md)

ユーザー: 「MXCallStackTree には何が含まれていて、どうデコードすればよいですか？」 → 起動: axiom-performance を参照 (skills/metrickit-ref.md)

ユーザー: 「アプリが時々ハングします」 → 起動: axiom-performance を参照 (skills/hang-diagnostics.md)

ユーザー: 「メインスレッドがブロックされて UI が応答しません」 → 起動: axiom-performance を参照 (skills/hang-diagnostics.md)

ユーザー: 「Xcode Organizer にアプリのハング診断が表示されます」 → 起動: axiom-performance を参照 (skills/hang-diagnostics.md)

ユーザー: 「アプリが起動中に watchdog によって強制終了されました」 → 起動: axiom-performance を参照 (skills/hang-diagnostics.md)

ユーザー: 「クラッシュレポートがあり、デバッガーで再現する必要があります」 → 起動: skills/lldb.md

ユーザー: 「このクラッシュを捕捉するためにブレークポイントを設定するにはどうすればよいですか？」 → 起動: skills/lldb.md

ユーザー: 「BUILD FAILED でビルドが失敗しますが、エラーの詳細がありません」 → 起動: build-fixer エージェントまたは /axiom:fix-build

ユーザー: 「ビルドが成功したり失敗したりします」 → 起動: build-fixer エージェントまたは /axiom:fix-build

ユーザー: 「Xcode のビルド時間を短縮するにはどうすればよいですか？」 → 起動: build-optimizer エージェントまたは /axiom:optimize-build

ユーザー: 「ビルドしようとすると署名証明書が見つかりません」 → 起動: axiom-security を参照 (skills/code-signing-diag.md)

ユーザー: 「GitHub Actions CI での errSecInternalComponent」 → 起動: axiom-security を参照 (skills/code-signing-diag.md)

ユーザー: 「GitHub Actions のコード署名を設定するにはどうすればよいですか？」 → 起動: axiom-security を参照 (skills/code-signing.md)

ユーザー: 「アプリはコンソールに何を出力していますか？」 → 起動: /axiom:console

ユーザー: 「シミュレータのコンソール出力を確認する必要があります」 → 起動: /axiom:console ユーザー：「アプリが無言で失敗し、UI にエラーが表示されません」 → 呼び出し：/axiom:console