［開発者向け］Claude TagでCI障害の初動を14分に——Anthropicのオンコール運用

2026-08-19

はじめに

　Anthropicは 2026年8月18日、CI/CD障害の一次対応を担う「Claude Tag」の運用方法を公開しました。Slack、監視、GitHub、Kubernetesなどを横断し、人間が判断できる証拠を集める仕組みです。本稿では構成、実績、安全策を整理します。

参考記事

タイトル: Claude on call: How Claude Tag serves as Anthropic’s first responder for CI/CD failures
著者: Sachin Malhotra
発行元: Claude
発行日: 2026年8月18日
URL: https://claude.com/blog/ai-ci-cd-on-call

要点

Claude TagはSlackのインシデントチャンネルを作業場所とし、監視・コード・インフラの情報をMCPコネクタで参照する
初回の証拠付き分析の中央値は14分、最速の原因特定は4分と報告されている
定型アラートとAIによる調査を分け、約617行の調査スキルや過去の教訓をMarkdownで管理する
AIは復旧案や修正PRを提示できるが、すべてのPRに人間の責任者と承認を求め、通常のCIゲートを通す
数値はAnthropic社内の運用結果であり、再現には監視データの品質、権限設計、技能の継続更新が必要である

詳細解説

障害対応の中心をSlackに置く

　Claude Tagはサービスアカウントとして動作し、Slackのインシデントチャンネルに参加します。Datadog、Grafana、GitHub、Kubernetes、PagerDuty、SlackをMCPコネクタでつなぎ、アラート、変更履歴、実行状況を同じ文脈で調べます。会話の履歴が残るため、担当者が交代しても調査の根拠をたどれます。

　Anthropicによると、基本設定は数日ではなく数時間で、短いデモは約10分で行えました。ただし、これはコネクタをつないだ時間の話です。実運用で役立つまでには、社内固有のサービス名、正常値、デプロイ手順、判断基準をスキルとして記述する必要があります。

定型検知とAI調査を分離する

　障害の検知までAIへ任せるのではなく、例えば「既知のデプロイ時間外にエラー率が2％を超えた状態が5分続く」といった決定論的なルールで起動します。その後、Claude Tagがログ、メトリクス、最近の変更を横断し、仮説と証拠をまとめます。初回の状況報告は通常15分以内で、社内集計では最初の証拠付き分析が中央値14分、最速の原因特定が4分でした。

　記事では約44件のテストが欠落した障害で、Claude Tagが機能フラグを原因として見つけ、3分後に回復を確認した例が紹介されています。重要なのは速度だけでなく、どのダッシュボード、ログ、commitを根拠にしたかを人間が確認できることです。

スキルを運用資産として育てる

　調査手順はMarkdown形式のスキルとしてGitHubへ保存され、例示された調査スキルは617行ありました。障害後の学びはlessons.mdへ追記され、次回の調査で参照されます。自然言語で日次・週次のルーティンも設定でき、CIの状態や未解決事項を引き継ぎます。

　この方式は、暗黙知をAIに丸投げするものではありません。熟練者が普段どの順序で確認し、どの状態を異常と判断し、いつ人間へ上げるかを文書化する作業です。スキルをコードレビューの対象にし、変更履歴と責任者を持たせると、AIの振る舞いを改善しやすくなります。

修復は人間の承認を残す

　Claude Tagはカナリアトラフィック、機能フラグ、Kubernetesのcordonやdrain、スケーリングなどの復旧案を提示し、修正PRを作成できます。一方で、すべてのPRに人間の所有者を割り当て、承認後に通常と同じCIゲートを通します。調査権限と変更権限を分け、AIが状況を誤認しても即座に本番変更へつながらない設計です。

　導入時は読み取り専用から始め、アクセスできるサービス、秘密情報、外部通信、変更操作を明示的に制限する必要があります。障害時には正常系の安全装置まで外したくなりますが、急いでいる場面ほど承認経路と監査ログが重要です。