AIコーディングエージェントはなぜ「ターン駆動」で、完了しても自分から報告しないのか
― 設計思想・技術的制約・確実に通知を受け取る対策 ―

AIコーディングエージェントの普及で、1ターンが「数秒の補完」から「数分〜数十分の自律作業」へと長尺化した。Anthropic は Claude Code が VS Code だけで 2,900万インストールに達したと述べている⁵。二次情報 長尺化により「終わったのに画面を見ていないと気づけない」体験ギャップが顕在化し、各社に同種の機能要望が殺到している。

需要の裏付けは「公式が機能を出したこと」と「他社で同じ要望が大量に立っていること」。Codex（OpenAI）には「完了音を鳴らして」系の Issue が複数（#3962 / #9093 / #9672 等）¹²、Cline には「タスク完了/ブロック時に効果音」Discussion #3228¹³、Claude Code 公式 repo にも「リモート時に完了プッシュを」Issue #28765 / #29438 が立つ⁶。=全エージェント共通の構造的ペインであり、ベンダー単体の手抜きではない。

主要なエージェント実装は例外なく同じ形に収束している ―― 「LLM を呼ぶ → 応答にツール呼び出しが含まれるか判定 → 含まれれば実行して結果を入力に戻す → 含まれなければ停止」という while ループ（いわゆる ReAct ループ）⁷。Anthropic 自身も「エージェントとは、環境フィードバックを使ってツールをループで回す LLM にすぎない」と定義している¹。

# エージェントの本質（擬似コード）
while True:
    out = LLM(context)              # 1回の推論=1ターンの一部
    if out.has_tool_calls:
        results = run_tools(out)     # ファイル編集/コマンド実行
        context += results           # 結果を“次の入力”に戻す
    else:
        break                        # ★出力が尽きた＝ターン終了。ここで「止まる」
# ↑ タイマーで自分を再起動する仕組みは“ここには無い”。次は人間の入力待ち。

ポイントは 「停止＝バグではなく到達点」。LLM は状態を持つデーモンではなく「入力→出力の純粋関数」であり、ループを駆動する燃料は毎ターン渡される入力（コンテキスト）。出力が空（＝もうやることがない）になればループは正しく終わる。「終わったあとに自発的に喋り出す」には、別途“起こす”トリガ（タイマー/イベント/通知機構）を外付けする必要がある。これが本DRのテーマの核心。構造の整理

推測（モデル試算・実測値ではない） 完了/入力待ちに気づくまでの「見落とし待機」を1セッションあたり平均 5 分、1日 12 セッションと仮定。

＝月18時間規模の回収が現実的。Remote Control（push）を足すと「席を外していても回せる」ため並列の上限がさらに上がる。ランニング費用は OS 標準通知なら 0 円、Pushover 等の外部 push は買い切り/小額。

判定：「Anthropic が不親切」は 誤り。ただし「デフォルトでは通知が来ない＝自分で1回設定が要る」点は 改善余地のある UX。

• 合理側： ターン駆動は ReAct ループの自然な帰結であり⁷、不可逆操作前の人間チェックポイント＝安全設計¹、反復上限/支出上限＝暴走&課金防止⁸。「黙って自走し続けない」ことには明確な利得がある。
• 不親切に見える側： 通知はオプトイン（フック/Remote Control 設定が前提）で、初期状態では届かない。だからこそ他社含め大量の「音/通知を付けて」要望が立っている⁶¹²¹³。
• 方向性： Anthropic は Remote Control の push（v2.1.110・報）⁵、Notification フック、Routines といった能動通知/無人実行を継続的に追加しており、「ターン駆動の安全性は維持しつつ通知だけ後付けする」という業界共通の落としどころに収束している。

＝結論：安全・コスト設計上の合理的トレードオフ。短所（初期OFF）はユーザー側設定で 30 分で消せる。

Step 1（10分）：~/.claude/settings.json（Windowsは C:\Users\todak\.claude\settings.json）に Stop＋Notification を追加。公式例ベース³

{
  "hooks": {
    "Notification": [
      { "matcher": "",
        "hooks": [{ "type": "command",
          "command": "powershell.exe -Command \"[System.Reflection.Assembly]::LoadWithPartialName('System.Windows.Forms'); [System.Windows.Forms.MessageBox]::Show('Claude Code が入力/承認を待っています','Claude Code')\"" }]
      }
    ],
    "Stop": [
      { "hooks": [{ "type": "command",
          "command": "powershell.exe -Command \"[console]::beep(880,300); [System.Reflection.Assembly]::LoadWithPartialName('System.Windows.Forms'); [System.Windows.Forms.MessageBox]::Show('タスク完了：Claude Code が応答を終えました','Claude Code 完了')\"" }]
      }
    ]
  }
}

公式の Windows 例はこの PowerShell MessageBox 形³。鳴る音だけで十分なら [console]::beep に。BurntToast モジュール導入でトースト通知化も可（任意）。

Step 2（5分）：CLI で /hooks を開き、Notification と Stop に件数が付いているか確認（メニューは読み取り専用）³。何か承認が要る指示を投げ、別ウィンドウに切り替えて通知が出るかテスト。

Step 3（10分・スマホで受けたい場合）：Claude モバイルアプリを入れ、Remote Control を有効化＋プッシュ通知トグルを ON。Remote Control は claude.ai の OAuth 認証（APIキー/Bedrock/Vertex バックエンドは非対応）⁵⁶。二次情報のため要実機確認

Step 4（5分・無人で回したい定常作業）：CLI で /schedule daily PR review at 9am のように Routine を作成（PCオフでもクラウドで走り、結果を Slack 等へ投稿可）⁴。

• 音が鳴りすぎる： Stop は応答を終えるたびに毎回発火する（＝1タスク中に何度も鳴り得る）。うるさければ Stop はビープのみ・Notification の matcher を idle_prompt/permission_prompt に絞る³。
• Routines を増やしすぎ： 1日のラン上限・サブスク消費がある。緑ステータス＝起動成功であって「タスク成功」ではない点に注意（中身は必ず開いて確認）⁴。
• 外部 push に秘密を載せない： 通知本文にトークン/顧客データを書かない（通知サービスのログに残る）。
• 撤退判断： フック設定で 30 分を超えてハマる／通知が二重に出て邪魔、なら一旦 OS 標準のビープ1本に戻して運用継続（凝りすぎない）。

• マルチCC運用との相性： CC1〜CC6 を並列で回す現運用では、各 CC の Stop/SubagentStop に「どの CC が終わったか」をビープ高さや通知タイトルで区別させると、張り付き不要で並列効率が上がる。
• 長時間タスク進捗ルール（MEMORY）との二段構え： 「途中報告＝プロンプト/ログ」「完了通知＝Stop フック」で役割分担。両方入れて初めて“放置に見える”が消える。
• R18量産/LoRA学習の長尺ジョブ： 学習完了やゲート通過のタイミングを Stop＋ビープで通知。席を外していても「終わったら戻る」運用に。
• Routines で定常 DR/監査： 既存の DR 量産や重複チェックを定時 Routine 化し、結果を通知（PC オフでも走る）⁴。

• DR_CC暴走防止_02_AIの確認前『完了』報告(ハルシネ)_2026-05-31.html ― 「完了」誤報告（本DRの“通知”とは逆＝偽完了の抑止）
• DR_CCが指示を守らない根本原因_チェックリスト合格点ゲート評価ループ設計_2026-05-30.html ― ループ/ゲート設計
• DR_CC暴走防止_09_human-in-the-loop承_2026-05-31.html ― 人間チェックポイント（本DR第4-2章と接続）
• DR_CC暴走防止_01_AIエージェントが検証前にスケール_2026-05-31.html ― 反復上限/暴走防止
• DR_複数CC_ChromeブラウザMCP接続改善_2026-06-13.html ― マルチCC/MCP 運用

重複チェック結果：本テーマ（ターン駆動設計＋能動通知機構）に直接該当する既存DRは無し。新規作成が妥当。