Slackのアラートを修正まで運ぶ。CarvanaのClaude Tag導入

米国の中古車ECであるCarvanaは、本番監視の警告が飛んでくるSlackのチャンネルに、AIエージェントを住まわせています。アラートが届いた時点でClaude Tagが調査を始め、壊れたコードを持っているチームを特定し、そのチームが決めた書式で原因の分析を投稿する。エンジニアが手を動かし始めるのは、そのあとです。公開されている導入事例には、リテールサイエンスのチャンネルでアラートが56%減ったこと、ホールセールプラットフォームのチームで回答までの時間が65%短くなったことが書かれています。

この記事で扱うのは、その事例ページと、Claude Tagの公式発表に書かれている範囲だけです。導入の費用、削減できた工数、測定した期間、アラートの母数は、どちらにも記載がありません。読みどころは数値そのものではなく、AIを「どこに置いたか」と「何を渡したか」の設計にあります。確認日は2026年9月9日です。

公表されているのは、提供元が出した2つのページだけ

先に出典の性質をはっきりさせます。この記事の一次情報は2件で、どちらもClaude Tagを提供している側が公開したものです。ひとつは導入事例のページ、もうひとつは製品そのものの発表ページです。Carvana自身がこの取り組みについて公表した文書は、今回の調査では確認できませんでした。

つまり56%と65%は、導入した企業が独自に検証して発表した値ではなく、提供元が導入事例として公開した値です。比較の対象がいつからいつまでなのか、何を1件と数えているのか、アラートの母数がどれだけあったのかは、いずれもページに書かれていません。同じ条件で再現できる形にはなっていない、ということです。

こう書くと否定的に見えますが、事例を読む価値が消えるわけではありません。数値を根拠として使うのは難しくても、何をどこに置き、何を渡し、何を渡さなかったかという設計の部分は、書かれているとおりに読めます。この記事では後者を中心に整理します。

自社で2回作ったものを、外の製品に置き換えた

Carvanaは、チーム全員が動きを見られてそのまま口を挟めるAIをSlackの中に置きたいと考え、それを自社で2回作っています。

1回目は自作のエージェントループでした。事例ページの説明では、いくつかのツールに配線したAPIの呼び出しで、必要なときは2周目に戻る作りです。2回目は、記事の時点でおよそ1年前にあたる時期に作られたもので、Claude Agent SDKをSlackアプリで包んだものでした。どちらも出荷され、どちらも役目は果たしていた、と書かれています。

問題は動くかどうかではありませんでした。少人数のチームが、本来の仕事の上にボットの世話を積み増していたという点です。エンジニアリングとアナリティクスを統括するAlex Devkar氏は、社内のツールは何ができるかを示したものの、それを維持するには事業を回すことへ向けたほうがよい時間と人手が必要だった、と述べています。

もうひとつ大きかったのが権限です。ほかのサービスへつなぎながらチームごとの権限を保とうとすると、そのたびに作り込みが要る。結果として、ホールセールプラットフォームのチームはこの社内ツールを採用しませんでした。いつまでサポートされるのか、また別の移行が来るのではないか、が分からなかったためだ、と書かれています。

ここは日本の社内ツールでもそのまま起きます。作れるかどうかより、誰が持ち続けるのかが決まっていないと、使う側が乗ってこない。社内で試作したAIツールが定着しない理由を、この事例は導入前の状態として先に書いています。

チームごとに「渡す範囲」を分ける

置き換えの決め手として挙げられているのは、機能の多さではなく渡し方です。

ひとつはバンドルと呼ばれるまとまりです。指示・ツール・アクセスを、ひとつのチームの用途に合わせて束ねたもので、それをSlackのひとつのチャンネルへ落とします。Devkar氏はこれをClaude Tagのもっとも価値のある機能のひとつだとし、各チームの働き方に合わせて指示とツールとアクセスを仕立てられると述べています。

もうひとつが、スコープを絞った識別子です。Claude Tagは自分の識別子で動けるため、Carvanaはクラウドのデータウェアハウスへの接続をひとつ用意したうえで、チームごとに別の識別子を作り、それぞれが自分の範囲だけを見られるようにしました。以前なら、この保護そのものを自分たちで作って維持する必要があった、というのがDevkar氏の説明です。

製品側の発表ページにも、対応する記述があります。管理者がチャンネル単位でツールとデータへのアクセスを決められること、用途ごとにClaudeの識別子を分けられること、組織単位とチャンネル単位でトークンの上限を置けること、そしてすべての活動と依頼者が監査ログに残ることです。導入事例の側で語られている運用は、この設計の上に乗っています。

なお、社内での検証はPathfindersと呼ばれるグループが担っていて、Sonnet 3.5の頃からコーディングや多段の作業でClaudeのモデルを試してきた、と書かれています。Claude Tagの既定はOpus 5で、社内ではOpus・Sonnet・Haikuを作業の必要に応じて使い分けているとされています。

アラートが修正まで進む道すじ

リテールサイエンス、カスタマー検証、ホールセールプラットフォームの3チームは、いずれも最初の通知をSlackで受け取ります。Claude Tagは本番監視の警告が出るチャンネルを見張り、自動で調査を始めます。

リテールサイエンスのチームでは、常設のプロンプトと、根本原因の書き起こしに使う固定の書式の上でこれが動いています。アラートは調査済みの状態で並ぶ、という書き方です。壊れたコードの持ち主を割り出してタグ付けし、チームが求めたとおりの形で分析を並べる。その書式は一度のプロンプトで覚えたきり守られているとされ、エンジニアは分析からそのままプルリクエストを開かせているため、バグの修正が同じスレッドの中のもう1通のメッセージになっています。

カスタマー検証のチームは、ソフトウェアのリリースとエラーがもともと集まっていたSlackチャンネルにClaude Tagをつなぎました。すべてのリリースが、出荷される1時間前を基準として、エラー・警告・ログ量の観点から自動で突き合わされます。誰かが依頼しなくても動く形です。比較のロジックはチーム自身のリポジトリにスキルとして置かれ、runbookや各アラートの注記の隣に並んでいます。一部の上級エンジニアの中にあった知識がバージョン管理へ移り、深夜3時でも正午と同じように適用される、というのがこの節の要点です。ある週末には、既存のログでは説明できない配備が来たとき、Claude Tagが諦めずに、ログを充実させるプルリクエストを出したと書かれています。監視していた仕組みそのものを改善した例です。

すべての問題がその場でエンジニアを呼び止める必要はない、という整理もあります。一部のチームは1時間ごとにパイプラインとフィーチャーフラグを点検させ、見つかった問題から次の手順を始めさせています。常時監視より費用が低く抑えられるとされています。

3つのチームが、それぞれ違う使い方をしている

いちばん厳しい試し方をしたのがホールセールプラットフォームのチームです。社内ツールを採用しなかったチームでもあります。受け口とアラートのチャンネルで2週間、オンコールのエンジニアがふだん見るのと同じ資料、つまり作業チケット、ビルドの履歴、コードへの読み取り専用のアクセスだけを渡して走らせました。

5件の事例で、最初の報告から原因まで辿り、症状を言い直すのではなく該当するコードを指し示した、と書かれています。断続的にレポートが欠ける事象では、疑われていた側ではなく下流のサービスに原因があると判断した例が挙げられています。ほかにも、機能の要望を具体的な変更の範囲まで絞り込む、依頼した側が見落としていた設計上の落とし穴を拾う、ビルドの失敗を切り分けたうえで再試行の結果を受けて自分の最初の結論を撤回する、といった動きが並びます。あるアラートについてインフラ障害が原因らしいと伝えられたときは引き下がり、まずいものが通り抜けていないかだけ確認して、障害が明けたあとの追跡を残しました。

5件はいずれも、チケットの起票、プルリクエストの提示、あるいはあえて直さないという判断のいずれかで終わっています。Devkar氏はこの状態を、チームがTagを同僚として扱っている、と表現しています。

公表されている結果

事例ページに書かれている結果は4つです。

ひとつめが、リテールサイエンスのチャンネルでアラートの量が56%減ったことです。同じアラートを繰り返し消すのではなく、繰り返している原因のほうへ手を入れた結果だと説明されています。ふたつめが、ホールセールプラットフォームのチームで回答に至るまでの時間が65%短くなったことです。以前はエンジニアが手作業で探していたチケット、ビルドの履歴、コードを、Claude Tag自身が確認するようになったためだとされています。

みっつめが、古いボットからの移行そのものをClaude Tagが担ったことです。Pathfindersの一人が、退役するチャットボットを指して「そのチャットボットの答えをすべて見て、置き換えるために必要なものを拾ってこい」という趣旨の指示をひとつ出した。1〜2週間かけて旧ボットの出力を追い、まもなく切り替わったと書かれています。

よっつめが数値になっていない変化です。Tagの導入前から起票はされていたが、いまははるかに多く上がってくる。Claude Tagが1件ずつ拾って修正まで運ぶと分かっているからだ、という説明です。起票が増えることは、指標としては悪化に見えることもあります。それでも良い変化として書かれている点は、読むときに押さえておく価値があります。

公表されていないこと

確認できなかったことを残します。導入や運用にかかっている費用は書かれていません。削減された工数、関わっている人数、対象になったチームの規模も同様です。56%と65%についても、比較した期間、アラートやチケットの母数、集計の方法の記載がありません。

社内テストの節に出てくるモデルの使い分けについても、効果を示す数値はありません。Fableがエンジニアリング以外の一部の利用者にも開かれていること、大量の取引文書を扱う社内の弁護士が使っていることは書かれていますが、そこにも件数や時間の記載はありません。

そして冒頭に書いたとおり、Carvana自身が公開した資料は確認できていません。この事例を社内で共有するときは、出典が提供元のページであることを一緒に伝えるのが誠実です。数値の裏づけとしてではなく、設計の参考として扱うのが妥当な段階だと考えます。

日本の実務者が参考にできる点

ひとつめは、置き場所です。この事例でAIが置かれているのは、専用の管理画面ではなくすでにアラートが集まっているSlackのチャンネルです。人が見に行く場所を増やさない、という判断が先にあります。新しいツールを入れたのに誰も開かない、という失敗はこの1点で起きます。自社に置き換えるなら、AIを置く前に「その仕事の連絡がいまどこに集まっているか」を確かめるところからです。

ふたつめは、権限の設計を先に済ませることです。この事例で採用の分かれ目になったのは機能ではなく、チームごとに見える範囲を分けられるかどうかでした。データウェアハウスに全社の情報が入っている以上、全部見えるAIは、全部見えて困る部署が使えません。導入の検討で最初に詰めるべきは、接続先の一覧ではなく、誰にどこまで見せるかの表です。

みっつめは、測り方です。この事例が最初に挙げているのは、AIが出した回答の量ではなく鳴らなくなったアラートの割合です。生成した本数や回答した件数を成果として並べると、増えているのに現場が楽になっていない状態を見逃します。減ってほしいものが減ったかどうかを、導入の前に決めておくほうが健全です。マーケティングの現場でも同じで、施策の効果測定をどう置くかはGoogle広告のコンバージョン設定のような測定の設計と地続きです。

よっつめは、維持する人を決めてから作ることです。Carvanaは2回作って2回とも動かしたうえで、維持のコストを理由に外の製品へ移りました。作れることと持ち続けられることは別だという判断です。社内で試作する前に、半年後に誰が面倒を見るのかを決めておくと、使う側が乗るかどうかの見通しが変わります。

出典と注記

この記事は、Claude（Anthropic）の導入事例「Carvana turns Slack alerts into production fixes with Claude Tag」と、Anthropicの発表「Introducing Claude Tag」を出典としています。いずれも製品を提供している側が公開した一次情報であり、導入した企業自身の発表ではありません。本文の数値は原文の表記のまま記載し、単位や通貨の換算、記載のない項目の補完はしていません。確認日は2026年9月9日です。仕様と数値は改定されるため、判断に使う前に各ページの現在の記載を確認してください。成果を保証する記述は含みません。ほかの事例は海外AI活用事例に、権限を絞った展開の例はPictetの事例にまとめています。