Claude TagのカスタムコネクションでAWSに安全につなぐ：SigV4署名をプロキシに任せる構成
Claude TagのアクセスバンドルにAWS SigV4認証を登録し、SlackのAIアシスタントからAWSの情報を安全に参照する構成を解説。営業からの仕様質問への回答と、アラートの一次調査・原因分析を自動化した実例を、最小権限IAMの落とし穴とあわせて紹介します。
代表取締役
作成日:
約8分で読めます
文章の下書きや調べ物にAIを使うのはもう当たり前になりました。その次に多くの会社がぶつかるのが、「AIに“社内のことを分かったうえで”答えてほしい」という一歩進んだ活用です。
営業が顧客から聞かれた仕様を、AIが社内のシステムを確認して答えてくれる。エラーの通知が来たら、AIが原因を調べてくれる。貼り付けた情報だけでなく、社内の状態そのものを見て動いてほしい、という段階です。
ところが、ここで壁にぶつかります。AIに社内の状態を見せるには、GitHubやAWSといったシステムへの接続情報（認証キー）をAIに渡す必要があります。この鍵を安易に渡すと、漏洩したときの被害が大きく、二の足を踏むことになります。
この記事では、Anthropicが提供する Claude Tag を使って、認証キーをAIに直接渡さないまま、SlackのAIに社内の情報を「見て答える」役割を任せる方法と、その際に大切な「任せていい業務」と「人が持つべき業務」の線引きを、非エンジニアの方にも分かるように整理します。
Claude Tag は、Claudeを社内の外部サービスやAPIに接続するためのAnthropicの仕組みです（2026年7月時点でパブリックベータ、公式ドキュメント）。
平たく言えば、Slack上の @Claude に、社内のシステムを見る「目」を持たせるものです。これまでのAIは、こちらが貼り付けた情報しか読めませんでした。Claude Tagを設定すると、AIが自分でGitHubのコードやAWSの状態を確認しにいき、その結果をもとに回答できるようになります。
大事なのは、どのサービスに・どこまでアクセスしてよいかを、管理者がまとめて制御できる点です。無制限に社内を見せるのではなく、「この用途にはこの範囲だけ」と絞って渡せます。
「Claude」には用途の違う使い方が複数あり、混同しやすいので整理しておきます。代表的なのが次の3つです。
| 名前 | 主な場所 | 使う人 | 向いていること |
|---|---|---|---|
| Claude Code | ターミナル・エディタ | 開発者（個人） | コードを書く・直す |
| Claude Cowork | 個人のPC | 個人 | PC上のファイルやブラウザ操作の代行 |
| Claude Tag | Slack | チーム全員 | チームの依頼を非同期で進める |
いちばんの違いは、「一人で使う」か「チームで使う」か です。Claude CodeとClaude Coworkは、基本的に個人が1対1で使うツールです。これに対しClaude Tagは、Slackチャンネルに常駐し、チーム全員が同じ @Claude に話しかける「マルチプレイヤー」型として設計されています（Anthropic公式）。誰がいつ何を頼んだかという文脈もチームで共有され、Anthropic自身はClaude Tagを「Claude Codeの進化形」と位置づけています。
つまり、開発の現場で使うのがClaude Code、個人のPC作業を任せるのがClaude Cowork、そしてチームのSlackで一次対応や調査を任せるのがClaude Tag、という住み分けです。この記事で扱うのは、いちばん最後のチーム業務での活用です。
抽象的な話だと分かりにくいので、実際に運用している2つの使い方を紹介します。どちらも「これまで人が毎回手を動かしていた定型作業」を、AIが巻き取る形です。
営業メンバーが顧客から「この画面の挙動はどうなっていますか？」「この機能はできますか？」と聞かれて困ったとき、Slackで @Claude にそのまま質問します。AIが社内のコードや設定を確認し、非エンジニアにも分かる言葉で 回答します。
不具合の報告も同じです。「こうしたらエラーが出た」と伝えれば、AIが状況を確認し、開発チーム向けの報告（GitHub Issue）の作成まで行います。これまで営業からエンジニアへ都度エスカレーションしていたやり取りが、かなり減ります。
システムから届くエラーやリソース不足の通知は、内容を読み解くだけでも手間がかかります。メモリ不足なのか、外部からの不正アクセス検知なのか。どのコードが関係しているのか。
Slackに通知が来た際、@Claude に調査を依頼すると、AIがログやコードを横断して確認し、原因の切り分け・分析・Issue作成まで進めます。担当者が最初の調査に時間を溶かす前に、「何が起きていて、どこが怪しいか」の当たりがついた状態になります。
ここが多くの会社が最も不安に感じる部分であり、Claude Tagの肝でもあります。
ポイントは、認証キーをAIに直接渡さない設計です。AWSとの接続では、AIは「仮の署名」を付けてリクエストを送るだけで、実際の署名（本物の鍵を使う処理）は境界にあるプロキシが代行します。本物の鍵はAIの手の届かない場所に保管され、AIがどう動こうと鍵そのものは表に出てきません。
さらに、AIに与える権限を 参照系（見るだけ）に絞る ことで、安全性を二重にできます。書き込みや削除の権限を渡さなければ、AIが社内のリソースを勝手に変更することはありません。万一キーが漏れても、被害は「見ることしかできない範囲」に閉じます。
なお、GitHubとの接続はGitHub Appを使った別の経路になりますが、「AIに渡す権限の範囲を絞る」という考え方は同じです。接続するサービスごとに、必要な分だけを渡すのが基本になります。
署名を代行するプロキシの設定や、AWSへの最小権限の与え方など、技術的な仕組みを詳しく見たい方は、エンジニア向けに解説した以下の記事をご確認ください。
Claude Tagの接続設定そのものは、管理画面から行えます。試しに触ってみるところまでは、専門知識がなくても進められるでしょう。
その前提として、まず「何をAIに任せ、何を人が持つか」を決めておくことが大切です。目安は次のとおりです。
一方で、業務に本格的に乗せる段階では、いくつか事故を招きやすい落とし穴があります。
これらは「動けばいい」で済ませると後で痛い目を見る部分で、まさに開発の専門家の出番です。私たちも、AIエージェントを業務に組み込む支援で、この安全な運用設計の部分を受託開発として担っています。実際に、ある支援先ではSlackのアラート対応と営業サポートをAIに一次対応させる仕組みを構築し、担当エンジニアの調査負担を目に見えて減らせました。
Claude Tagを使ったAI活用が効くのは、次のような会社です。
始め方としては、いきなり全社に広げるのではなく、一つのチャンネル・一つの用途から小さく試すのが安全です。たとえば「特定サービスのアラート調査だけ」から始め、うまくいったら営業サポートへ広げる、という進め方です。
その最初の一歩、とくに「どの権限をどう渡せば安全か」の設計でつまずきそうなら、外部の専門家に相談するのが結果的に早道になります。
生成AIを「業務に組み込む」ときの最大の壁は、社内システムへの認証情報をどうAIから守るかでした。Claude Tagは、鍵をAIに渡さずに社内の状態を見せる仕組みを提供し、SlackのAIに「見て答える」一次対応を安全に任せられるようにします。
大切なのは、AIに任せる範囲を「参照系の一次対応」に絞り、最終判断や本番リリースは人が持つという線引きです。この設計さえ押さえれば、これまで人手で回していた定型作業をAIに巻き取ってもらい、社内のリソースをより価値の高い仕事に振り向けられます。
「自社でもAIに一次対応を任せたいが、安全に始められるか不安」という段階からで構いません。権限設計や運用の勘所を含めて、私たちがご相談に乗ります。初回は30分ほどのオンライン相談から、無理な提案はいたしません。
※本文で紹介した活用例は、筆者の受託開発の現場経験にもとづくものです。具体的な支援先やシステムを特定できない形に一般化しています。
「こんなことできる？」「費用感を知りたい」「まだ漠然としているけど相談したい」
どんな段階でもお気軽にご相談ください。
クレインテックが一緒に考えます。
初回のご相談・お見積もりは無料です。
「こんなシステムは作れる？」「費用感を知りたい」「まだ漠然としている」など、どんな段階でもお気軽にどうぞ。
無料で相談する