axiom-ios-networking

iOS ネットワーキングルーター

HTTP リクエスト、WebSocket、TCP 接続、ネットワークのデバッグなど、ネットワークに関する作業では必ずこのスキルを使用してください。

使用する場面

次のような場合に、このルーターを使用します。

• ネットワークリクエスト（URLSession）を実装する場合
• Network.framework または NetworkConnection を使用する場合
• 接続障害をデバッグする場合
• 非推奨のネットワーキング API から移行する場合
• ネットワークのパフォーマンスに問題がある場合

プレッシャーへの対処

ユーザーがカスタム実装に多くの時間を費やしている場合：

サンクコストによるプレッシャーに屈してはいけません。正しい対応は次のとおりです。

1. まず診断する — 変更を勧める前に、実際に何が失敗しているのかを把握します
2. 正しい提案をする — 標準 API（URLSession、Network.framework）で問題を解決できるなら、専門的な姿勢でそう伝えます
3. 努力を尊重しつつ、誤った方向に導かない — 相手の作業を認めながら、技術的に正直な指針を示します

プレッシャーがかかる状況の例：

「カスタムネットワーキングに2日かけました。修正を手伝ってください。URLSession を使えとは言わないでください。」

適切な回答：

「まず、モバイル通信での失敗を診断させてください。[診断後] 問題は [X] です。URLSession なら [Y] によってこれを自動的に処理できます。該当するコードパスの移行をお勧めします。デバッグを続けるより、30分で済みます。[Z] に関する既存の作業はそのまま活用できます。」

重要な理由： 移行したほうがデバッグを続けるより速いことに、ユーザー自身では気づけない場合がよくあります。根拠のない安心感を与えるより、正直な指針を示すほうがユーザーのためになります。

振り分けロジック

ネットワークの実装

ネットワーキングのパターン → /skill axiom-networking

• 構造化並行処理を使った URLSession
• Network.framework への移行
• 最新のネットワーキングパターン
• 非推奨 API からの移行

Network.framework のリファレンス → /skill axiom-network-framework-ref iOS 12-25 のレガシーパターン → /skill axiom-networking-legacy 移行ガイド → /skill axiom-networking-migration

• NWConnection（iOS 12-25）
• NetworkConnection（iOS 26+）
• TCP 接続
• TLV フレーミング
• Wi-Fi Aware

App Store 準拠

ATS / HTTP セキュリティ → /skill axiom-networking-diag

• App Transport Security（ATS）の設定
• HTTP → HTTPS への移行
• 安全でない接続による App Store のリジェクト
• NSAllowsArbitraryLoads の例外

非推奨 API によるリジェクト → networking-auditor エージェントを起動

• UIWebView → WKWebView への移行
• SCNetworkReachability → NWPathMonitor
• CFSocket → Network.framework

ネットワークのデバッグ

接続の問題 → /skill axiom-networking-diag

• 接続のタイムアウト
• TLS ハンドシェイクの失敗
• データが届かない
• 接続の切断
• VPN／プロキシの問題

自動スキャン

ネットワーキングの監査 → networking-auditor エージェントを起動するか、/axiom:audit networking を実行（SCNetworkReachability、CFSocket、NSStream などの非推奨 API、および到達可能性チェック、ハードコードされた IP、エラーハンドリングの不足などのアンチパターンを検出します）

判断ツリー

1. 構造化並行処理を使った URLSession？ → networking
2. Network.framework / NetworkConnection（iOS 26+）？ → network-framework-ref
3. NWConnection（iOS 12-25）？ → networking-legacy
4. ソケット／URLSession からの移行？ → networking-migration
5. 接続の問題／デバッグ？ → networking-diag
6. ネットワーキングに関する ATS／HTTP／App Store のリジェクト？ → networking-diag + networking-auditor
7. UIWebView または非推奨 API によるリジェクト？ → networking-auditor（エージェント）
8. 非推奨 API／アンチパターンのスキャン？ → networking-auditor（エージェント）

正当化への対処

考え	実際のところ
「URLSession は簡単だから、スキルは必要ない」	構造化並行処理を使った URLSession には、非同期処理やキャンセルのパターンがあります。networking スキルで説明しています。
「接続タイムアウトは自分でデバッグする」	接続障害には8つの原因があります（DNS、TLS、プロキシ、モバイル通信など）。networking-diag では体系的に診断できます。
「基本的な HTTP リクエストだけ必要」	基本的なリクエストにも、エラーハンドリング、再試行、キャンセルのパターンが必要です。networking スキルで説明しています。
「カスタムネットワーキング層は問題なく動いている」	カスタム層ではモバイル通信やプロキシに関する例外を見落とします。標準 API なら自動的に処理できます。

重要なパターン

ネットワーキング（networking）：

• 構造化並行処理での URLSession
• Socket を Network.framework に移行
• 非推奨 API の置き換え

Network Framework リファレンス（network-framework-ref）：

• iOS 12～25 向けの NWConnection
• iOS 26 以降向けの NetworkConnection
• 接続ライフサイクルの管理

ネットワーキングの診断（networking-diag）：

• 接続タイムアウトの診断
• TLS のデバッグ
• ネットワークスタックの調査

呼び出し例

ユーザー：「API リクエストがタイムアウトで失敗します」 → 呼び出し：/skill axiom-networking-diag

ユーザー：「async/await で URLSession を使うにはどうすればよいですか？」 → 呼び出し：/skill axiom-networking

ユーザー：「TCP 接続を実装する必要があります」 → 呼び出し：/skill axiom-network-framework-ref

ユーザー：「NWConnection と NetworkConnection のどちらを使うべきですか？」 → 呼び出し：/skill axiom-network-framework-ref

ユーザー：「HTTP 接続を使用していたため、アプリが却下されました」 → 呼び出し：/skill axiom-networking-diag（ATS 準拠）

ユーザー：「App Store に UIWebView を使用していると表示されます」 → networking-auditor エージェントを呼び出し（非推奨 API のスキャン）

ユーザー：「ネットワーキングコードに非推奨 API がないか確認してください」 → networking-auditor エージェントを呼び出し