axiom-networking

ネットワーキング

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

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

ここで利用可能：skills/networking-auditor.md。

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

クイックリファレンス

症状／タスク	参照先
構造化並行処理を使用した URLSession	skills/networking-discipline.md を参照
Network.framework のアンチパターン	skills/networking-discipline.md を参照
非推奨 API の移行	skills/networking-discipline.md を参照
gRPC Swift — 型付き RPC、ストリーミング、.proto コード生成（WWDC 2026）	skills/networking-discipline.md を参照
負荷がかかる状況（到達可能性、ソケット）	skills/networking-discipline.md を参照
NetworkConnection（iOS 26 以降）API リファレンス	skills/network-framework-ref.md を参照
NWConnection（iOS 12〜18）API リファレンス	skills/network-framework-ref.md を参照
TLV フレーミング、Coder プロトコル	skills/network-framework-ref.md を参照
NetworkListener、NetworkBrowser、Wi-Fi Aware	skills/network-framework-ref.md を参照
接続タイムアウト、TLS の失敗	skills/networking-diag.md を参照
データが届かない、接続が切断される	skills/networking-diag.md を参照
ATS／HTTP／App Store の却下	skills/networking-diag.md を参照
本番環境での重大な問題の診断	skills/networking-diag.md を参照
NWConnection のパターン（iOS 12〜18）	skills/networking-legacy.md を参照
UDP バッチ、NWListener、NWBrowser	skills/networking-legacy.md を参照
BSD ソケットから NWConnection への移行	skills/networking-migration.md を参照
インターネットに接続できないネットワークでのプッシュ通知／通話（Local Push Connectivity、NEAppPushProvider）	axiom-integration を使用（skills/local-push-connectivity.md）
NWConnection から NetworkConnection への移行	skills/networking-migration.md を参照
URLSession StreamTask から NetworkConnection への移行	skills/networking-migration.md を参照

判断ツリー

digraph networking {
    start [label="Networking task" shape=ellipse];
    what [label="What do you need?" shape=diamond];

    start -> what;
    what -> "skills/networking-discipline.md" [label="implement patterns,\nanti-patterns,\npressure scenarios"];
    what -> "skills/network-framework-ref.md" [label="API reference\n(iOS 26+ or 12-18)"];
    what -> "skills/networking-diag.md" [label="debug connection\nfailures"];
    what -> "skills/networking-legacy.md" [label="iOS 12-18\nNWConnection patterns"];
    what -> "skills/networking-migration.md" [label="migrate from\nsockets/URLSession"];
}

1. 構造化並行処理を使用した URLSession ですか？ → skills/networking-discipline.md
2. Network.framework／NetworkConnection（iOS 26 以降）ですか？ → skills/network-framework-ref.md
3. NWConnection（iOS 12〜18）ですか？ → skills/networking-legacy.md
4. ソケット／URLSession からの移行ですか？ → skills/networking-migration.md
5. 接続の問題／デバッグですか？ → skills/networking-diag.md
6. 自分が管理するサービスに対する型付き RPC／ストリーミングですか？ → gRPC Swift（skills/networking-discipline.md）
7. ネットワーキングに関する ATS／HTTP／App Store の却下ですか？ → skills/networking-diag.md + networking-auditor
8. 証明書のピン留め、API リクエストへの署名、ペイロードの暗号化ですか？ → /skill axiom-security
9. UIWebView または非推奨 API による却下ですか？ → networking-auditor（エージェント）
10. 非推奨 API／アンチパターンのスキャンを行いますか？ → networking-auditor（エージェント）

プラットフォーム固有のネットワーキング

• watchOS の低レベルネットワーキングの制限（TN3135） → axiom-watchos を参照（skills/background-and-networking.md）

圧力に屈しない

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

埋没費用による圧力に屈してはいけません。正しい対応は次のとおりです。

1. まず診断する — 変更を勧める前に、実際に何が問題なのかを把握してください
2. 適切に提案する — 標準 API（URLSession、Network.framework）で問題を解決できるなら、専門的な姿勢でその旨を伝えてください
3. 敬意を払いながら、誤った方向に進ませない — 相手の取り組みを認めつつ、率直で技術的に正確な指針を示してください

重要なパターン

ネットワーキング（skills/networking-discipline.md）：

• 構造化並行処理を使った URLSession
• 8 つの重大なアンチパターン（SCNetworkReachability、ブロッキングソケット、ハードコードされた IP アドレス）
• TCP／UDP／TLS のパターンを選ぶための判断ツリー
• NetworkConnection のパターン（iOS 26 以降）：TLS、UDP、TLV フレーミング、Coder プロトコル
• プロフェッショナルな反論テンプレートを含む 3 つのプレッシャーシナリオ
• 出荷前チェックリスト

Network Framework リファレンス（skills/network-framework-ref.md）：

• NetworkConnection（iOS 26 以降）：WWDC 2025 の全 12 個の例
• NWConnection（iOS 12〜18）：例を含む完全な API
• TLV フレーミング、Coder プロトコル、NetworkListener、NetworkBrowser
• モビリティ：可用性、より良い経路、Multipath TCP、NWPathMonitor
• セキュリティ：TLS、証明書ピンニング、暗号スイート
• パフォーマンス：ユーザー空間ネットワーキング、ECN、サービスクラス、TCP Fast Open

診断（skills/networking-diag.md）：

• あらゆる接続失敗の種類に対応する体系的な判断ツリー
• DNS の失敗、TLS 証明書の検証、メッセージフレーミング
• TCP の輻輳、IPv6 のみのモバイル通信、VPN の干渉、ATS
• プロフェッショナルなコミュニケーションテンプレートを含む本番環境の危機シナリオ

レガシー（skills/networking-legacy.md）：

• TLS を使った NWConnection（完了ハンドラー）
• UDP バッチ処理（CPU を 30％ 削減）
• NWListener、NWBrowser（Bonjour ディスカバリー）

自動スキャン

ネットワーキング監査 → networking-auditor エージェントまたは /axiom:audit networking を起動します（非推奨 API、アンチパターン、不足箇所を監査します。対象は状態遷移への対応、TLS の適用範囲、接続のクリーンアップ、フレームワークの選択です）

もっともらしい理由付けを防ぐ

考え方	実際のところ
「URLSession はシンプルなので、スキルは必要ありません」	構造化並行処理を使う URLSession には、非同期処理やキャンセルのパターンがあります。skills/networking-discipline.md で解説しています。
「接続のタイムアウトは自分でデバッグします」	接続の失敗には 8 つの原因（DNS、TLS、プロキシ、モバイル通信）があります。skills/networking-diag.md で体系的に診断できます。
「基本的な HTTP リクエストが必要なだけです」	基本的なリクエストにも、エラー処理、リトライ、キャンセルのパターンが必要です。
「独自のネットワーキング層は問題なく動作しています」	独自の層では、モバイル通信やプロキシに関するエッジケースを見落とします。標準 API なら自動的に処理できます。

呼び出し例

ユーザー：「API リクエストがタイムアウトして失敗します」 → 読む：skills/networking-diag.md

ユーザー：「URLSession を async/await と一緒に使う方法を教えてください」 → 読む：skills/networking-discipline.md

ユーザー：「TCP 接続を実装する必要があります」 → 読む：skills/network-framework-ref.md

ユーザー：「NWConnection と NetworkConnection のどちらを使うべきですか？」 → 読む：skills/network-framework-ref.md

ユーザー：「HTTP 接続を使ったため、アプリがリジェクトされました」 → 読む：skills/networking-diag.md（ATS 準拠）

ユーザー：「App Store から UIWebView を使っていると言われました」 → 起動：networking-auditor エージェント（非推奨 API のスキャン）

ユーザー：「ネットワーキングコードで非推奨 API が使われていないか確認してください」 → 起動：networking-auditor エージェント