Claude Tagで本番アラートに対応する — 医療系3社の運用事例
Insight Healthは重要アラートの97%をエンジニアの介入なしで完了。TennrとMedallionの運用も含め、Claude Tagのアクセス分離とチャンネル設計を読み解きます。
Insight Healthは、Slackの重要アラートチャンネルで、エンジニアが介入せずに閉じたアラートが97%に達したと報告しています。実現した構成の核は、Claude Tag(ベータ)と、自社でAgent SDKを使って作った別のエージェントに、あえて違うアクセス権を持たせたことです。
この記事では、医療系3社(Insight Health・Tennr・Medallion)の運用から、本番アラート対応と社内ツール保守の設計を取り出します。
本番アラートの97%を閉じたInsight Healthの二エージェント構成
Insight Healthは、専門診療所向けのAI紹介コーディネーター「MagicDocs」を作っています。FAXや紹介状、事前承認依頼、検査結果といった患者関連の書類を読み、臨床情報を抜き出して患者に紐づけ、構造化データとしてEHR(電子カルテ)へ書き込む製品です。顧客は56診療科・1,100以上の診療所に及びます。
顧客が増えるにつれ、少人数のエンジニアチームの時間を本番アラートの一次対応が食い始めました。そこで3か月前から、PHI(患者の医療情報)を含まないエンジニアリングとサポートのチャンネルでClaude Tagを動かしています。アラートの調査、チケットの起票と重複排除、PRのレビュー、スレッドをまたぐ文脈の引き継ぎが仕事です。
件数の多い本番アラートのチャンネルでは、Claude Tagに加えて、Insight Health自身がAgent SDKで作った「Zeus」というエージェントを並べています。この二つは意図的にアクセス範囲が違います。
二つのエージェントのアクセス範囲
Claude Tag
コードベースとLinearが見えます。コードのパターンと過去のチケット履歴を知っている側です。
Zeus(自社製)
BAA(業務提携契約)の対象になっているClaude API組織上で動き、本番データを照会できます。Slackに出る前にPHIをマスクします。
アラートが来ると、二つが分担して調べます。本番データの照会、コードや直近のデプロイとの突き合わせ、過去チケットとの比較です。進捗はすべてSlackのスレッドに流れます。根本原因を特定するとドラフトPRを開き、テストを見届け、最後にエンジニアがレビューしてマージします。人が最後に判断する形は変わっていません。
チャンネルメモリが効く場面
Claude Tagはチャンネルごとの記憶を持ちます。新しい問い合わせを「修正待ちの既知の問題」と見抜く、数週間前の調査を思い出す、指示されなくても常設の指示に従う、といった動きがこの記憶に支えられています。
共同創業者でCTOのSaran Siva氏は、両エージェントの推論と分担が全員に見えることが信頼を生み、チームがエージェントの使いこなし方を学ぶ助けにもなると語っています。
本番データを持たせないという分離の意味
この事例で読み取れる設計判断は、「賢い一体型のエージェント」を作らなかったことです。PHIに触れる権限は、BAAの範囲にあるZeus側に閉じ込めています。Claude Tag側はPHIを含まないチャンネルとコネクタに限られます。
Claude TagはAnthropicのBAAの対象外で、記事も、PHIに一切触れないチャンネルとコネクタの範囲で使っている組織があると説明しています。本番データを扱う部分は、この前提の外側にある別のエージェントが受け持つ形です。
Insight Healthは、アラート以外にも採用、ベンダー交渉の準備、契約書のレビュー(通話の文字起こしと条件の照合)、日常の業務運用にClaude Tagを使っています。
Tennrが社内ツールの保守を非エンジニアに開いた方法
Tennrは、患者の受け入れ、書類作成、事前承認、予約調整を自動化する患者オーケストレーション基盤です。
社内ツールは作るそばから放置されて死にます。保守する人手がないからです。2026年7月、Tennrは別の方法を取りました。採用候補者向けのオファー提示ポータル(recruiting.tennr.com)をClaude Codeで作り、保守役をClaude Tagに任せたのです。専用のSlackチャンネルで、採用担当、People部門、採用マネージャー、RevOpsが平易な英語で@Claudeに頼むと、Claudeがコードを直し、デプロイし、結果を報告します。
約1か月で15件以上のチケットがこの方法で出荷されました。
- アップロードしたPDFの1枚資料から作る福利厚生の詳細セクション
- Dropbox Signへ誘導する「Sign your offer here」バナー
- 目標ボーナスの入力欄
- 管理者向けのセルフサービス操作
同日対応と、頼まれなくても出る周知
運用中の出来事も具体的です。公開状態のコピーAPIが指摘されたとき、Claudeは同じ日に塞ぎました。AshbyからのインポートのバグでライブのオファーのEquityが書き換わり続けたときは、バグを直したうえで、正しい値を反映し直しています。別のバグで候補者に変動報酬が一時的に誤って表示された件では、依頼されていないのに、影響した期間と是正内容をチャンネル全体に通知しました。オンボーディング文書の作成と、ツールの権限管理も担当しています。
運用規約をチャンネルで教える
チームはClaudeに自分たちの運用規約を、チャンネル内で教えています。絵文字のステータス凡例や、チケット番号・依頼者・コミットのリンク・スクリーンショット・動作確認用リンクを揃えた書式です。Claudeはそれ以降、この形式を守るようになりました。採用担当者が自然文で、ときにはスクリーンショット1枚だけで出したエンジニアリングのチケットが、1時間以内に本番の変更として返ってくる運用です。
VP of Business Operations and StrategyのAbe Griffiths氏は、ツールの管理役をSlackチャンネル上のClaudeに任せることで、使う人自身が改善でき、エンジニアを製品開発から引き離さずに済むと述べています。
チャンネル別の自律度
Tennrが導入を決めやすかった理由は、チャンネル単位で権限の範囲を切れる点でした。PHIを許す場所が限られた非公開チャンネルだけだったので、Claude Tagを広げても新しいデータ上の問題は生まれませんでした。
オファーツールのチャンネルでは、Claudeに先回りして問題を直し、コードを変更し、PRレビューを省いて出荷させます。一方でProductやEngのチャンネルでは、Claudeの役割は情報収集や整理に近く、同じ姿勢は不適切です。「低リスクの場所でだけ本物の自律を与えられる」ことが、この線引きの価値です。
Medallionが専門家の知識をチャンネルに蓄積した仕組み
Medallionは、医療機関向けにプロバイダーのクレデンシャリング、免許、保険者への登録申請を自動化しています。仕事の多くは文書化されていない規則に依存します。たとえば、グループが登録する前に最低限必要な認定済みプロバイダー数を求める保険者はどこか、州ごとの規制はどうか、といった問いです。これまで答えは少数の社内ドメイン専門家に集まり、製品開発の判断が人に詰まっていました。
エンジニアが保険者の規則をSlackで尋ねると、Claude Tagが過去の専門家の回答、履歴データ、非構造化の社内資料から答えます。自信がないときは適切な専門家を呼び出し、その回答が関連する将来の回答の土台になります。CTOのArmaan Sarkar氏が挙げる導入の安心材料は三つです。
- PHIを含まない業務を選んだこと(問いの対象は保険者の規則やプロセスで、個々の患者や提供者ではない)
- 専門家が監督と訂正を行うこと(Claudeは単独で答えず、全やり取りが社内の誰でも監査できるチャンネルに残る)
- 出力が下流で検証されること(これらの方針を使う自社システムの動作が、別途監査・検証される)
3社に共通する設計: アクセス範囲を先に決めてから任せる
三つの事例を並べると、成果より前に、アクセスの設計が揃っています。
3社が共通して先に決めたこと
PHIのない場所から始める
エンジニアリング、プロダクト、運用、採用のチャンネルで、コネクタは1〜2個に絞って始めています。
DMでなくオープンなスレッドで
チーム全員が経過を見て、文脈を引き継げるようにするためです。
権限と自律度をチャンネルごとに切る
低リスクのチャンネルほど自律度を上げ、それ以外は情報収集や整理に留めます。
設定に落とすと何をすることになるか
管理者向けの医療機関向けページによると、Claude Tagを医療組織で使う流れは次のとおりです。これはAnthropicのBAAの対象外であるという前提を踏まえた手順で、法的助言ではなく、導入前に法務・コンプライアンスと確認するよう明記されています。
PHIをClaudeの届く範囲に入れない設定
- 1
既定でオフにする
管理画面で「Respond in all channels」のスイッチを切ります。
- 2
承認済みチャンネルだけでオンにする
チャンネルごとの「Enable Claude Tag in this channel」を有効化します。過去の試験運用でワークスペースやチャンネルに個別設定が残っていると、そちらが優先されるので、「Use inherited setting」で継承に戻します。
- 3
DMを無効にする
「Allow direct messages」をオフにすると、Claudeはチャンネルでしか呼べなくなります。
- 4
PHIを示す名前のチャンネルをブロックする
Advancedタブの「Blocked channel patterns」に、臨床や患者のチャンネル名の命名規則を入れます。
ブロックパターンの例は次の形です(ドキュメントに載っている例)。
*-patient-*一致するチャンネルでは、誰かがClaudeを招待しても、読み取りも返信も行われません。
見落としやすい前提条件
導入前に確認しておきたい条件が三つあります。
- Enterpriseプランが必要: チャンネル単位でオン・オフを切る設定は、Enterpriseプランにあります。
- 一部の組織では使えない: ゼロデータ保持(ZDR)、顧客管理の暗号鍵、Claude Code(ローカルモード)とCowork(ローカルモード)へのHIPAA構成のいずれかがある組織では、Claude Tagは使えません。
- 公開チャンネルのキーワード検索は止められない: Claudeは、追加されていない公開チャンネルも含め、すべての公開チャンネルをキーワード検索できます。管理設定でこの検索を切ることはできず、検索対象を「Claudeが参加しているチャンネル」に絞ることになります。
つまり、PHIを出さない範囲は、Claudeがいるチャンネルだけでは足りません。接続したワークスペースの公開チャンネル全体と、Claudeを招待した非公開チャンネルまで広がります。
PHIが混入したときの手順
設定は、人がPHIを入力してしまうことまでは防げません。Slackでメッセージを消しても、すでにトランスクリプトに入った分は消えないためです。手順は、プライバシー責任者への報告、Slackでの削除、所有者によるチャンネルのスコープ削除(トランスクリプトとメモリの削除)、公開チャンネルならワークスペースのメモリの確認と削除、そしてprivacy@anthropic.comへの削除依頼です。承認済みチャンネルにはDLP(情報漏えい防止)ツールを動かし、全員に周知しておく運用が前提になります。
自社の本番アラート対応に当てはめるなら
Insight Healthの構成を他社が真似するとき、そのまま持ち込めるのは「アクセス範囲の違う複数エージェントを同じスレッドに並べる」という骨格です。
- コードと課題管理だけを見るClaude Tagと、本番データを別の統制のもとで扱うエージェントに役割を分ける
- 進捗をスレッドに出して、人が推論を追えるようにする
- 修正はドラフトPRまでで、マージは人が行う
はじめ方としては、記事は「アラートまたはサポートエンジニアリングのチャンネルでClaude Tagを有効にし、GitHubをつないで、許可リストを広げる前に2週間チームで使う」ことを挙げています。コネクタの追加は、バンドル単位で、必要な承認済みチャンネルにだけ紐づける形が医療機関向けページの推奨です。
PHIを扱わない通常のSaaSでも、本番データの権限を別エージェントや別組織に切り出す考え方は使えます。監視ツールとの連携設計はClaudeによる監視ツール連携の障害対応ワークフローで、Slack上でのClaude TagとClaude Codeの違いはClaude TagとClaude CodeのSlack連携の比較で整理しています。チャンネル別のアクセスと支出上限の設定手順はClaude Tag管理者設定にあります。
クレジットとメンバー個人のコネクタ
EnterpriseでClaude Tagを有効にしてGitHubにつないだ組織には25,000ドル、10席以上のTeam組織には2,500ドルのClaude Tagクレジットが付与されました。ただし期限は2026年10月1日で、すでに過ぎています。
メンバー個人のコネクタは、承認すればチャンネルでも本人の依頼に使えます。この機能を組織設定で完全に無効にする方法はありません。Enterpriseでは「Require human review of every message」で、投稿前に人が結果を確認させられます。詳しくはチャンネルでの個人コネクタ対応を参照してください。
医療業界全般のClaude活用はヘルスケア業界のClaude活用ガイドにまとめています。
まとめ
3社の事例が示すのは、Claudeに権限を足す順番です。まず見せてよい範囲をチャンネルとコネクタで決め、本番データのような重い権限は別のエージェントと別の統制に切り出し、そのうえで低リスクの場所から自律度を上げています。
Insight Healthの97%という数字は、この分離と、人が最後にマージする体制がセットで成り立っています。社内ツール保守のTennrでは、「誰がチケットを書くか」が変わりました。