AIコーディングワークフローのプッシュ通知：信頼性の高い配信を実現する

Claude Codeは複雑なタスクの処理に数分から数時間かかることがあります。通知がなければ、ターミナルを見続けるか、定期的に戻ってきて重要なことを見逃していないか確認するしかありません。どちらのアプローチもあなたの時間を尊重していません。

プッシュ通知はTactic Remoteを単なるリモートビューアではなく、ワークフローツールにするものです。この記事では、通知システムの構築方法、Claude Code hookとの統合、配信の信頼性エンジニアリング、そして実際の開発者から観察された使用パターンについて説明します。

核心的な知見

Tactic Remoteにおけるプッシュ通知の価値は「スマートフォンが振動する」ことではありません。通知がAIコーディングエージェントとのインタラクションのタイミングと方法を変えることにあります。同期的なターミナル監視の代わりに、非同期のタスク管理が可能になります：

1. Mac（またはiPhoneアプリ）からClaude Codeタスクを開始する。
2. 席を離れる。コーヒーを淹れる。会議に参加する。帰宅する。
3. タスクが完了したとき、エラーが発生したとき、または承認が必要なときにスマートフォンが通知する。
4. 数秒でレビューして応答し、元の作業に戻る。

私たちはこれを「デスクではなくスマートフォンを確認する」ワークフローと呼んでいます。CI/CD通知と同じメンタルモデルです。ビルドパイプラインを見続けるのではなく、結果を教えてくれるのを待つのです。

Claude Code Hookの統合

通知システムはClaude Codeのhookメカニズムによって駆動されています。Hookはユーザーが設定可能なスクリプトで、Claude Codeが定義されたライフサイクルポイントで実行します。Tactic RemoteのMacコンパニオンアプリは3つのイベントタイプに対してhookを登録します：

タスク完了 — Claude Codeがリクエストの処理を完了したときに発火します。Hookは終了ステータス、変更内容の要約、ターミナル出力の最後の数行をキャプチャします。

承認が必要 — Claude Codeが人間の確認を必要とする操作に遭遇したときに発火します（プロジェクトディレクトリ外へのファイル書き込み、シェルコマンド、ネットワークリクエストなど）。Hookは保留中の操作の説明と一意の承認IDをキャプチャします。

エラー — Claude Codeが致命的なエラー、ツールの障害、またはAPIタイムアウトに遭遇したときに発火します。Hookはエラーメッセージと関連するコンテキストをキャプチャします。

各hookの呼び出しは構造化されたpayloadをMacコンパニオンサーバーに送信し、サーバーが通知のルーティングを決定し、APNs（Apple Push Notification service）payloadを構築して、通知リレーを通じて配信します。

通知タイプの実際の使用

各通知タイプは特定のインタラクションパターン向けに設計されています：

タスク完了通知 にはタスクの要約とステータスインジケーター（成功または部分完了）が含まれます。通知をタップすると、Tactic Remoteアプリが完了したセッションのターミナルビューに直接開き、出力を確認できます。

承認通知 は最優先です。操作の説明（「Claudeがプロジェクトディレクトリで rm -rf build/ を実行しようとしています」）が含まれ、通知バナー上に直接「承認/拒否」アクションが表示されます。iPhoneでは、アプリを開かずに承認に応答できます。通知を長押しするとインラインアクションが表示されます。テレメトリデータによると、承認の62%がアプリを完全に開くことなく通知アクションで処理されています。

エラー通知 にはエラーカテゴリと切り詰められたメッセージが含まれます。これらはアクション可能で、タップするとセッションビューが開き、完全なエラーコンテキストを確認してタスクの再起動や修正を判断できます。

配信の信頼性

APNsはプッシュ通知の配信を保証しません。Appleのドキュメントには通知は「ベストエフォート」であり、デバイスの電力管理、ネットワーク状況、またはレート制限により失われる可能性があると記載されています。承認通知の見逃しがタスクの停滞を意味する開発者ツールにおいて、「ベストエフォート」では不十分です。

APNsの上にいくつかの信頼性メカニズムを重ねています：

サーバーサイドの状態追跡。 Macコンパニオンサーバーはすべての通知の配信台帳を維持します。各通知には一意のID、タイムスタンプ、配信状態（保留中、送信済み、確認済み、期限切れ）があります。

クライアントサイドの確認応答。 iPhoneアプリが通知を受信して表示すると、Macコンパニオンサーバーに確認応答を送信します。30秒以内に確認応答がない場合、サーバーは再送信します。

指数バックオフによる再送信。 未確認の通知は30秒、60秒、120秒の間隔でリトライされます。3回失敗すると、通知は配信不能の可能性ありとマークされ、MacコンパニオンのステータスUIでフラグが立てられます。

アプリ内同期。 iPhoneアプリが開かれたとき（またはバックグラウンドから復帰したとき）、Macコンパニオンに未確認の通知を問い合わせ、通知センターに表示します。これにより、APNsが完全にドロップした通知もキャッチできます。

重複排除。 再送信には重複配信のリスクが伴います。すべての通知は一意のIDを持ち、iPhoneクライアントが追跡します。重複はサイレントに破棄されます。同じ承認リクエストが2回表示されることはありません。

実際の運用では、ベータユーザーベース全体で配信成功率（通知送信から通知確認まで）は10秒以内で97.3%、60秒以内で99.6%です。

通知の重複排除の詳細

重複排除はユーザーの信頼に影響するため、特に注意が必要です。開発者が同じ「ファイル書き込みを承認」通知を2回見た場合、すでに承認したかどうか疑問に思います。すでに承認した操作の承認通知を見た場合、自分の承認が受信されたかどうか疑問に思います。

重複排除は2つのレベルで機能します：

トランスポートレベル。 各通知には再送信を通じて保持されるUUIDがあります。iPhoneクライアントは最近確認した500個のUUIDのローリングウィンドウを維持します。以前に確認されたUUIDを持つ通知は、表示前に破棄されます。

セマンティックレベル。 特に承認通知について、クライアントは承認IDがすでにアクションされているかどうかを確認します。最初の通知配信で操作を承認し、再送信が到着した場合、そのトランスポートUUIDが異なっていても（サーバーがリトライ用に新しいpushのpayloadを生成した場合に発生する可能性あり）、再送信は抑制されます。

開発者の実際の使用パターン

4か月のベータデータを経て、明確なパターンが浮かび上がりました：

通知のピーク時間帯 はユーザーのローカルタイムゾーンで午前9-11時と午後2-4時で、コーディングセッションの開始と昼食後の生産性の高い時間帯に対応しています。

承認通知への平均応答時間 は12秒です。P95は47秒です。つまり、テールレイテンシでも人間によるループ内承認がタスク実行に追加する時間は1分未満であり、安全性の保証に対する小さな代償です。

最も一般的な通知駆動ワークフロー：マルチステップのリファクタリングタスクを開始し、会議のためにデスクを離れ、会議中に通知アクションで2-3件のファイル操作を承認し、戻るとタスクが完了している。

通知量：アクティブユーザーの中央値は1日8件の通知を受信します。ヘビーユーザー（P95）は約30件です。調査では通知疲れは見られません。おそらく各通知がステータス更新ではなくアクション可能なイベントを表しているためです。

ミュートパターン：15%のユーザーが特定の時間帯に非承認通知をバッチ処理する「集中モード」ルールを設定しています。承認通知は集中モードに関係なく常に即座に配信されます。承認の停滞はタスク全体をブロックするためです。

今後の予定

通知に関するいくつかの改善を進めています：

• コードプレビュー付きリッチ通知 — 通知上に直接diffプレビューを表示する承認通知。アプリを開かずに情報に基づいた承認/拒否の判断ができます。
• 通知のグループ化 — 連続する素早いタスク完了通知（マルチセッションワークフローで一般的）を1つのサマリー通知にバッチ処理します。
• カスタム通知サウンド — 完了、承認、エラーに対して異なる音声キューを設定し、スマートフォンを見ずに音でトリアージできるようにします。

通知の設定オプションについては、通知設定ガイドを参照してください。このシステムを駆動するClaude Code hookのリファレンスについては、Hook統合を参照してください。