Anthropic、Claude をオンコールに：夜中のアラートを先に調査
人手の調査には1時間以上かかることもありました。現在はClaude TagがSlackに24時間365日常駐し、最初の証拠分析を中央値14分で届けます。
- Claude TagはCI/CDのアラート発生後の継続的な証拠収集と初動報告を担当し、人間は本番環境の変更管理を引き続き行います。
従来のオンコールと Claude の違い
Anthropicのエンジニア、Sachin Malhotra氏が、同社で数ヶ月にわたって運用してきたCI/CDのオンコール体制を公開しました。Claude TagをSlackのオンコールチャンネルとアラートチャンネルに常駐させ、24時間365日の第一応答者として動かす仕組みです。
違いは速さだけではなく、誰が最初の調査を継続して行うか
方式を選んでフォーカス；デフォルトは並列表示。
- 受動的な割り込み夜中にページャーで起こされ、即座に文脈を切り替えなければならない。
- システムを一つずつ確認モニタリング、ログ、コード、デプロイ記録、障害チャンネルを手動で開く。
- しきい値のジレンマ敏感すぎるとアラート疲れを起こし、緩すぎると障害を見逃す可能性がある。
- 24時間365日常駐Slackのオンコールチャンネルやアラートチャンネルに常駐し、最初のシグナルを自動で受け取る。
- 並列証拠収集複数のエージェントが同時にモニタリング、ログ、コード、クラスタ、過去の障害を確認。
- 証拠付きで引き渡しタイムライン、根本原因の仮説、提案を出力し、エンジニアの判断に委ねる。
Anthropicの報告によると、Claudeが最初のエビデンスに基づく分析レポートを提出するまでの中央値は14分です。最も速いケースでは、4分以内に初回レポートで根本原因を指摘できたといいます。なお、これはあくまで一次調査結果の話であり、インシデントの完全な復旧までの時間を指すものではありません。
実際の事例は夜の10時に発生しました。新しいサービスでは約44件のテストが実行されていませんでした。Claudeは問題をその日起動されたread-modeフィーチャーフラグに特定し、担当者がロールバックを実行しました。その3分後、Claudeは再チェックを実施し、ルールが復旧してエラーレートがベースラインに戻ったことを確認しています。
Botではなく、当直システムそのもの
Claudeが継続的な当直をこなせるのは、万能なプロンプトが存在するからではありません。チャンネルのコンテキスト、Gitの知識、ツール連携、そしてマルチエージェントによる調査が連携して機能しているからです。
記憶でき、検索でき、戻ってきて、ルールに従って行動する
当直チャンネルの文脈を保持し、障害や人間の指示にリアルタイム応答。
モニタリング、ログ、ページャー、コード、クラスタ、障害チャンネルを読み取る。
イベントやスケジュールで再実行。例：月曜日にハンドオフ生成。
調査、エスカレーション、ルーティング、経験をGitレビューに載せる。
調査方法やインシデントの知見はすべてGitに保存されています。lessons.mdには、各インシデントの根本原因、修正内容、教訓が記録されており、障害の種類ごとに専用の調査マニュアルも用意されています。特にshadow divergence障害には、なんと617行に及ぶ調査スキルが存在します。
実際に参考にすべきなのは「617行」という数字そのものではなく、その生成プロセスです。エンジニアは実インシデントの対応中にClaudeと段階的に原因を絞り込み、その過程を後からスキルとして整理します。一度きりの教訓は最初にlessons.mdへ記録し、同じパターンが繰り返し発生してから正式なマニュアルへ格上げするという流れです。ここで最も重要な原則は、理論で推測する前に、まずデータを確認することです。設定情報はどこに問題があり得るかを示すだけで、実際に何が起きているかを示すのはメトリクスだからです。
インシデント発生時、Claudeはどう動くか
まずトリアージ、次に証拠収集；修復を支援し、最後に検証と学習
4つの段階をクリックして、何を読み、何を実行し、何を納品するか確認できます。
アラートチャンネル、人の報告、社内インシデントページ、新サービスのトラフィックとアラートデータ。
決定論的モニタリングがシグナルをトリガー；ClaudeはONCALL.mdと現場の文脈から重大度とエスカレーションパスを判断。
すぐに人間をページングするか、モーニングログに記録して昼間に対応。
lessons.md、障害プレイブック、Grafana、ログ、PagerDuty、GitHub、Kubernetes、Slack。
実行エージェントがそれぞれソース・オブ・トゥルースを読み取り；データを先に調べてから推測。人間はいつでも反例や追加の仮説を出せる。
証拠リンク付きのSITREP：何が起きたか、推定される根本原因、次のステップ。
検証済みの根本原因仮説、フィーチャーフラグ、クラスタ状態、コードや設定の差分。
社内の高権限エージェントがカナリアを昇格・降格；Claudeはdrain/cordon、スケールアウト、修復PRの生成も提案。
レビュー可能な操作計画またはPR；当直エンジニアが本番の重要な変更を担当。
修復後の一連のモニタリング、ログ、テスト結果、障害スレッド。
メトリクスがベースラインに戻ったか確認し、根本原因と修復を記録。繰り返しパターンはプレイブックに昇格。
検証結果、lessons.mdの更新、日次・週次ハンドオフ、ci-weatherの公開ステータス。
ここには重要な境界線が二つあります。第一に、監視アラートは引き続き決定論的な仕組みであり、エージェントはコンテキストに基づいてエスカレーションの要否を判断します。第二に、Claudeの初回判断が常に正しいとは限りません。人間はいつでも反例を示したり仮説を追加したりして、データに基づく検証へ戻せます。
対応プロセスは四つの段階で完全なループを形成します。まずアラートのフィルタリングとエスカレーションを行い、次にエビデンスの並行調査を実施します。その後、修復作業を支援し、最後にメトリクスの回復を確認して知見をシステムへ書き戻します。さらにci-weatherが、複数のインシデント、ビルド指標、マージキュー、デプロイ遅延を統合した共通のステータスレポートを生成するため、他のエンジニアがCIの状況を繰り返し問い合わせる手間が省けます。
ただし、ステータスレポートは一度生成すれば終わりというものではありません。Anthropicのチームはレポートの形式を繰り返し調整してきました。レポートが読みやすいかどうかは、チーム自身のコミュニケーション習慣に左右されるからです。これは技術的なパイプラインの問題ではなく、人間同士のコミュニケーションの問題です。さらにClaudeは日次・週次の引き継ぎレポートも生成し、次の当番者がスムーズに対応を引き継げるようにしています。
権限の境界についても明確にしておく必要があります。Anthropic内部にはエンジニア権限を持つClaude Code Agentが別途存在し、フィーチャーフラグのカナリアトラフィックを自動で増減できます。一方、公開されているoncall-kitはデフォルトで読み取り専用であり、本番環境への変更は引き続き人間が実行します。
他チームが導入するには
Anthropicによると、この基本構成のセットアップには数日ではなく数時間しかかかりませんでした。最短の導入経路はわずか四段階です。
- Claude TeamまたはEnterpriseを開設し、Claude TagをSlackの当直グループに追加する。
- 監視、ログ、PagerDuty、GitHub、KubernetesなどのConnectorsを接続し、Claude Code Remoteを設定する。
- 自チームの過去のインシデントから
lessons.md、調査マニュアル、エスカレーションルールを生成する。 - まずClaudeに読み取り専用で調査・診断出力させ、人間が信頼性を確認してから権限の追加を検討する。
公式のセットアップキットには、約10分で実施できる模擬インシデントの演習も用意されています。本番システムに直接接続しなくても、まずは一連の流れを理解することが可能です。
この仕組みが最終的にエンジニアの負担を減らすのは、単に手作業の調査を省くだけではありません。機械的な調査、夜間の中断、繰り返し発生するインシデント対応のコミュニケーションから人を解放し、中長期的なアーキテクチャ設計や信頼性向上の取り組みに時間を振り向けられるようにする点にあります。
夜中のシステムアラート、Claudeが先に調べる
AnthropicはClaude TagをCI/CDのオンコール用Slackに常駐させ、アラート選別、並行調査、最初の証拠レポートを任せています。本番変更は人間が管理。初回分析は中央値14分、最速4分で根本原因を指摘しました。
人を起こす前に、Claudeが証拠を集める
従来の当番夜中にエンジニアを起こし、複数システムを順番に確認。調査は1時間を超えることもあります。
Claudeの初期対応Slackに常駐し、複数のエージェントが並行調査。最初の証拠分析は中央値14分です。
最速のケース最速ケースは4分で根本原因を指摘。ただし完全復旧までの時間ではありません。
Claudeが機械的な調査を担い、本番判断は人間が引き継ぎます。
ボットではなく、4層のオンコール体制
ClaudeSITREP
チャンネルコンテキストSlackがアラート、議論、人間からの反例を届けます。
証拠ソースとの接続Grafana、Datadog、Kubernetes、PagerDuty、GitHubが実データを提供。
Gitナレッジ層一度きりの教訓はlessons.mdへ。反復パターンは調査スキルへ昇格。
並行調査複数エージェントが指標、ログ、変更を並行調査し、SITREPに集約。
原則は、まず指標データ、その後で設定や仮説。
検知、調査、修正、検証、学習の循環
11 検知ルールベース監視がアラートを出し、Claudeが即時呼び出しか朝のログかを判断。
22 調査最近の教訓を読み、指標、ログ、コード、変更を並行確認。
33 修正Claudeが修正案やPRを用意し、本番変更は人間が承認・実行。
44 検証と学習指標を再確認し、根本原因と教訓をlessons.mdへ。
Claudeが誤れば、人間が反例を加え、データから再検証させます。
44件が未実行：Claudeが特定、人間が戻し、Claudeが再確認
22:00 アラート新サービスで約44件のテストが未実行。
根本原因の特定その日に有効化したread-modeフラグを原因と特定。
人間による実行エンジニアがフラグを戻す。公開キットは本番を変更しません。
3分後Claudeがルール、テスト、エラー率の基準復帰を確認。
まず調査をコピー。本番権限は後から
今すぐできることSlackと読み取り専用ツールを接続し、事故履歴から教訓、手順書、昇格ルールを作る。
まずは読み取り専用Claudeが診断し、人間が精度を確認。公式キットには約10分の演習も。
権限は段階的に内部エージェントはcanaryを調整可能。公開キットは読み取り専用で、本番変更は人間が実行。
移植できるのは、ルールベース監視、文脈調査、人間の本番判断、次回へつなぐ事故学習です。
夜中のアラート、先に調べるのは誰？
アラート新しいサービスで44件のテストが未実行です！
Claudeまず証拠を確認します。
以前はまず人を起こしていました。今はClaudeが先に調べます。
複数のエージェントが並行して証拠を探し、メインエージェントがSITREPにまとめます。
Claudeこれは最初の証拠分析であり、修復完了ではありません。
エンジニアこの反例も調べてください。
Claudeは先に報告できますが、誤ることもあります。人間はいつでもデータから再検証させられます。
Claude証拠は今日有効になったread-modeフラグを示しています。ロールバックを提案します。
エンジニア本番環境の変更は私が実行します。
Claudeは特定と提案を行い、人間が本番環境の決定を下します。
修復後も指標を再確認して、初めて完了です。
Claude一度の教訓は記録し、繰り返し発生したらマニュアルに昇格させます。
エンジニアまず読み取り専用で調査し、信頼性が確認できたら権限委譲を検討します。
再現できるのは自動で本番環境を変更することではなく、証拠の調査、人間によるゲート、経験の記録です。