投稿者 投稿日: カテゴリー AIニュース
AIオンコールとは、システム障害の一次対応をAIが担う運用体制のことです。
Anthropicが2026年8月18日、自社の継続的インテグレーション（CI／CD、コードを自動でテストして配信する仕組み）で発生する障害の一次対応を、AIに任せている運用の中身を公開しました。障害チャンネルが開いてから中央値14分で証拠にもとづく初期分析を投稿し、最速では4分で原因を名指ししたと明かしています。受注連携エラーや在庫同期の失敗といったアラートに追われるEC運用の現場にとっても、AIオンコールという発想はそのまま応用できる話です。本記事は、EC支援19年・5,000社超の実績を持ち、AI導入支援は2023年から提供する株式会社オルセル（うるチカラ運営）が解説します。
何が起きたか：夜10時の障害を、AIが3分で検証まで回した
結論として、AnthropicのCIチームは数か月前から、障害対応の第一報を人ではなくAIが書く体制に移しています。Claude by Anthropicの技術記事によると、記事を書いたSachin Malhotraは夜10時に「新サービスで約44件のテストが起動していない」と同僚から連絡を受け、従来なら1時間かけて調査していた作業を、AIへの問い合わせに置き換えたといいます。AIはその朝に有効化された機能フラグが原因だと特定し、切り戻しても安全だと判断材料を示し、切り戻しの3分後には「スキップ設定が消えてエラー率がベースラインに戻った」ことを検証して報告してきたそうです。
仕組みの中核にあるのは、Slack上で動く@Claudeです。障害チャンネルの会話を記憶として保持し、GrafanaやPagerDuty、GitHub、Kubernetesといった監視・実行系の情報源にMCP経由で接続します。オーケストレーション役のエージェントが調査役の子エージェントを並列に立ち上げ、依存関係ごとに原因を追い、結果を1本の状況報告としてまとめる構成です。判断基準は「エラー率が2%を超えた状態が5分以上続き、かつ想定内のデプロイ時間帯でなければ担当者を呼び出す」といったルールとしてマークダウンのファイルに書かれ、GitHubでコードと同じように改訂されていきます。
調査の精度を支えているのは、バグの種類ごとに書かれた手順書でした。同記事では、特定のバグ分類について617行の調査手順をマークダウンで用意し、著者が実際の障害対応をAIと一緒に進めながら書き起こしたと説明されています。加えて、過去の障害を書き溜めた学習ログも武器になっていました。同記事には、著者自身の失敗から生まれた「まずデータを問い合わせ、それから仮説を立てる」という戒めが記録されているとあります。Anthropicは同じ構成を再現できるoncall-kitをGitHubで公開しており、自社の障害履歴をトリアージ手順書に変換する使い方を想定しています。
日本のEC事業者にとっての論点は3つ
第一の論点は、EC運用にも「オンコール」が存在するという認識です。楽天市場のRMSやAmazonのSP-API、Shopifyのアプリ連携は、受注取り込みの失敗、在庫の二重引き当て、価格改定の反映漏れといった形で日常的に異常を出します。多くの店舗では、この一次対応が特定の担当者の勘と経験に依存しています。AIに任せられるのは修理そのものではなく、まず「何が起きていて、どこを見れば分かるか」を最初にまとめる部分です。ここが14分で出てくるだけでも、店長が朝礼前に判断できる情報量は変わります。
第二の論点は、AIが読める形で運用知識を書き出しておく必要があるという点です。Anthropicの事例で効いているのは高性能なモデルというより、判断基準とバグ分類ごとの調査手順、そして過去の障害ログがテキストで整備されていることでした。EC運用に置き換えると、受注CSVの取り込みエラーの原因別対処、在庫連携が止まったときの確認順序、モール側の障害告知の見に行き方などを、人に聞かないと分からない状態から文書に出す作業です。これはAI導入以前の話ですが、AI活用の前提条件でもあります。エージェントに権限をどこまで渡すかの設計は、AIエージェント導入の安全設計に関する記事も参考になります。
第三の論点は、権限の線引きです。Anthropicも修正の適用は人の承認を前提にしており、AIが単独で本番を書き換える運用にはしていません。ECの現場でも、在庫数や価格の更新をAIが自動実行する設計は事故が高くつきます。読み取り専用で調査と報告だけを任せ、変更は人が承認する形から始めるのが現実的です。
初動として何から着手するか
まず、直近3か月に起きた運用トラブルを10件だけ書き出すことをおすすめします。日時、症状、原因、対処、再発防止の5項目で足ります。この10件が、AIに渡すトリアージ手順書の元データになります。
次に、通知の宛先を1か所に集めます。モールからのメール、受注管理システムのエラー通知、決済のアラートがそれぞれ別の受信箱に散っている状態では、AIに渡す前段が成立しません。ChatworkでもSlackでも、まず人が全部見る場所を1本化するのが先です。
そのうえで、既存のAIツールに「このトラブル記録を読んで、症状から原因候補と確認手順を出す」という使い方を試します。Anthropicの構成はTeamまたはEnterpriseプランと管理者の設定を前提としており、日本の中小EC事業者がそのまま同じ体制を組むには準備が必要です。一方で、記録を整えてAIに読ませる部分は、今日から無料の範囲でも検証できます。
なお、AIエージェントによる自動対応をモールの店舗運営に組み込む場合、楽天市場では店舗ページやR-Mailから楽天外部への誘導が規約上できません。AI経由の顧客対応を設計する際は、モールごとの規約を先に確認する必要があります。
まとめ
AIオンコールの本質は、モデルの賢さではなく、判断基準と過去の失敗をテキストで持っているかどうかです。Anthropicは中央値14分の初期分析という実測値を出しましたが、その裏側にあるのは617行の調査手順書と、書き溜められた学習ログでした。日本のEC事業者がとるべき一歩は、まず自社のトラブル10件を文書化することです。ツールの導入判断は、そのあとで十分間に合います。
参考文献
- Claude by Anthropic「Claude on call: How Claude Tag serves as Anthropic’s first responder for CI/CD failures」
- anthropics/oncall-kit（GitHub）
- Anthropic Institute「Recursive self-improvement」
- Claude Tag 製品ページ（Anthropic公式）
※うるチカラでは、生成AIの導入支援から運用最適化まで、貴社のEC事業に合わせたカスタマイズ提案を行っています。無料相談（30分）も実施中ですので、お気軽にお問い合わせください。
https://uruchikara.jp/contact/
引用元: Claude by Anthropic
【監修】齋藤竹紘（株式会社オルセル代表 / 19年・5,000社のEC支援実績）
株式会社オルセル代表取締役 / うるチカラ編集長。19年・5,000社以上のEC支援実績を持ち、楽天市場・Amazon・Yahoo!ショッピング・Shopify・Shopee越境ECの実装ノウハウを保有。AI×ECに関する書籍を3冊執筆。「現場で使えるAI実装」を一次情報として発信しています。
この記事を読んだ人は、こんな記事も読んでいます
