Claude TagのカスタムコネクションでAWSに安全につなぐ：SigV4署名をプロキシに任せる構成

注意: 本記事は2026年7月18日時点のClaude Tag（パブリックベータ）に基づいています。仕様は変更される可能性があるため、最新情報は公式ドキュメントをご確認ください。

TL;DR

• SlackのAIアシスタントにAWSの状態を参照させたい。ただしAWSの認証情報をAIに直接持たせると、漏洩したときの被害が大きい
• Claude Tag のアクセスバンドルに 認証情報タイプ「AWS SigV4」 を登録すると、鍵はプロキシの内側に隠したまま、AIがAWS APIへ署名付きリクエストを送れるようになる
• 検証は最小権限のIAMユーザー＋アクセスキーで。STSの一時認証情報はこの機能では非推奨だった
• この構成で、営業からの仕様質問への一次回答と、Slackアラートの原因分析・Issue作成までをAIに任せられるようになった

はじめに

Slackに飛んでくるエラーアラートの原因を切り分けるには、CloudWatchのメトリクスやログ、該当するコードの変更履歴を横断して見る必要があります。この一次調査は担当エンジニアの手を止めますし、夜間ならオンコールで叩き起こされることになります。

営業メンバーからの「この画面の挙動ってどうなってましたっけ？」という質問も似ています。仕様を確認するにはコードやインフラの設定を見るのが確実ですが、非エンジニアがそこに踏み込むのは難しく、結局エンジニアに聞くしかありません。

こうした一次対応をSlack上のAIアシスタントに任せられれば、エンジニアの負担はかなり減ります。ただし、そのためにはAIにAWSの情報を見せる必要があり、ここで「AIにAWSの認証情報をどう渡すか」という問題にぶつかります。アクセスキーをそのままプロンプトやツール設定に書けば、当然ながら漏洩リスクを抱え込みます。

この記事では、Anthropicの Claude Tag を使い、AWSのアクセスキーをAIのサンドボックス外に隔離したまま、AIにAWSの情報を参照させる構成を解説します。実際にこの構成で、営業サポートとアラートの原因分析をAIに任せられるようにした経験をもとにしています。

Claudeを開発ワークフローに組み込む話としては、以前モノレポでの活用を紹介しました。あわせて読むと、AI活用の全体像をつかみやすくなります。

Claude Tag と「アクセスバンドル」

Claude Tag は、管理者がClaudeを外部サービスやAPIに接続するためのAnthropicのプラットフォームです（2026年7月時点でパブリックベータ）。認証情報とアクセス制御をまとめて管理できるのが特徴です。

その中核が アクセスバンドル（Access Bundle） です。これは接続と権限をまとめる「入れ物」で、管理者はバンドルを作り、その中に認証情報やプラグインを追加していきます。「どのサービスに」「どういう条件で」Claudeがアクセスできるかを、このバンドル単位で定義します。

プリセットのコネクターが無いサービスに対しては、カスタムコネクションを使います。カスタムコネクションには大きく2種類あります。

• HTTP API接続: サービス名・認証タイプ・許可するホスト・必要なカスタムヘッダーをフォームで指定する
• MCPサーバー: サーバーを宣言するプラグインと、そのホスト用の認証情報を組み合わせる

公式ドキュメントによると、認証情報タイプは複数サポートされています（Bearerトークン、Basic認証、AWS SigV4、GCP系、各種OAuthフロー、GitHub App連携など。詳細は公式ドキュメントを参照）。今回使うのは、このうちの AWS SigV4 です。

バンドルは関心事ごとに分割しておく

運用を始めてから効いてくるコツがひとつあります。それは、アクセスバンドルを 関心事の単位で細かく分割しておく ことです。たとえば github、aws、sre のように用途別のバンドルを用意しておきます。

Claude Tagでは、アクセスバンドルをチャンネルなどの適用先に紐づけて使います。このとき、1つの巨大なバンドルに何もかも詰め込んでしまうと、チャンネルごとに同じ内容を重複して書くはめになります。逆に、小さなバンドルに分けておけば、適用先ごとに必要なバンドルを組み合わせるだけ で済みます。

• 営業サポート用のチャンネル → github + aws + sales
• アラート対応のチャンネル → github + aws + sre

共通して使う github や aws の設定は一度書けば使い回せるので、適用時の重複が減り、権限の見通しも良くなります。認証情報を追加する前に、「これはどの関心事のバンドルに入れるべきか」を一度考えておくと、後々の運用が楽になります。

ちなみに aws バンドルは、基本的にすべて 参照系（読み取り専用） で統一しています。AIに勝手にリソースを変更されると困るので、書き込み系の権限はここに入れません。この方針なら、どのチャンネルに aws バンドルを組み合わせても「AWSは見るだけ」が保証され、安心して使い回せます。

なぜ「AWS SigV4」を選ぶのか

AWSのAPIは、リクエストごとに 署名バージョン4（Signature Version 4、通称SigV4） で署名することを求めます（AWS General Reference）。この署名にはシークレットアクセスキーが必要です。つまり素朴に実装すると、リクエストを組み立てる側（＝AI側）に鍵を持たせることになります。

Claude Tagの「AWS SigV4」認証情報タイプは、ここを分離してくれます。公式ドキュメントの説明では、次のように動きます。

Agent Proxyがホスト名から署名リージョンとAWSサービスを読み取り、境界で各アウトバウンドリクエストに保存された認証情報で署名する。

ポイントは、実際のAWSキーがサンドボックスの外に留まることです。Claude自身は仮の（プレースホルダーの）署名を付けてリクエストを投げるだけで、プロキシがそれを剥がして本物の認証情報で署名し直してからAWSへ届けます。AIがどう振る舞おうと、鍵そのものはAIの手の届く範囲に出てきません。

登録画面では、値は「書き込み専用」で、保存後は表示されなくなります。これも鍵をAI側やUI側に露出させないための設計です。

実際の設定手順

アクセスバンドルに認証情報を1つ追加するだけです。設定画面（「アプリを接続」ダイアログ）で入力する項目は次の通りです。

項目	設定値の例	補足
追加先	対象のアクセスバンドル	どのバンドルに紐づけるか
名前	my-service aws など	認証情報の識別名
認証情報タイプ	AWS SigV4	ここが肝
許可ウェブサイト	*.ap-northeast-1.amazonaws.com	このホストにのみキーを送る
アクセスキーID	AKIA...	IAMユーザーのアクセスキー
シークレットアクセスキー	（書き込み専用）	保存後は非表示
セッショントークン	（オプション）	一時認証情報を使う場合のみ

「許可ウェブサイト」は重要です。ドキュメントにあるとおり、Claudeは認証情報を ここで指定したホストにのみ 送信します。リージョンを絞ったワイルドカード（例: *.ap-northeast-1.amazonaws.com）にしておくことで、キーが意図しない宛先に飛ぶことを防げます。

設定後は、プロキシが実際に動作していることをAI側に伝えるための手順プロンプトを添えて、AIがAWSのAPIエンドポイントに対して署名リクエストを投げられるか動作確認します。筆者の環境では、この構成でAWSへ正しく接続できることを確認できました。

「AWS Proxyが動作している」ことをプロンプトで伝える

一点、実運用でのコツがあります。AIはデフォルトでは「自分でSigV4署名を計算しなければ」と考えがちですが、この構成では署名はプロキシが肩代わりします。そのため、手順プロンプトの中で「署名はAgent Proxyが行うので、リクエストはプレースホルダー署名のまま送ってよい」旨を明示しておくと、余計な自前署名の試みで詰まらずに済みます。

落とし穴：認証情報の準備でつまずく

ここが実務で一番ハマりやすいところです。

検証はアクセスキー方式で

最初、STSの一時認証情報（AssumeRoleで発行するセッショントークン付きの鍵）を使おうとしましたが、この機能では 非推奨 でした。プロキシが保存済みの認証情報で継続的に署名する性質上、短命なSTSトークンとは相性が悪いのだと考えられます（公式に理由の明記は確認できませんでしたが、挙動としてそう振る舞いました）。

そこで検証段階では、最小権限を付与したIAMユーザーを手動で作成し、そのアクセスキー／シークレットキー で動作確認するのが現実的でした。まず接続が成立することを確かめる、という目的にはこれで十分です。

ただし権限は必要最小限に絞る

検証で動いたからといって、広い権限のまま進めてはいけません。AWSのベストプラクティスは一貫して「最小権限の付与（grant least privilege）」を掲げています（IAM security best practices）。AIが実際に叩くAPI（例: ログ参照、メトリクス取得）だけに絞り、書き込み系や広範な権限は与えないようにします。

AIに渡す認証情報は、「AIが暴走しても、あるいは万一漏れても、被害がその権限の範囲に閉じる」ように設計するのが鉄則です。読み取り中心の一次調査用途なら、付与するのは参照系の権限だけで足りるはずです。

この構成で何ができるようになったか

鍵の隔離という土台ができると、SlackのAIアシスタントに実務を任せられるようになります。実際に運用したのは次の2つのユースケースです。

1. 営業向けサポート

営業メンバーがSlackで @Claude にメンションすると、仕様確認・バグ報告・軽微な実装依頼に対応できるようにしました。AIがGitHubのコードとAWS上の設定・状態を確認し、非エンジニアにも分かりやすい言葉で 回答を返します。

• 「この画面の〇〇はどういう動きですか？」→ コードや設定を確認して回答
• 「〇〇したらエラーが出た」→ 状況を確認し、不具合の可能性があればGitHub Issueの作成まで
• 軽微な修正で対応できると判断した場合は、PR作成まで（最終確認・レビュー・リリースは必ずエンジニアが実施）

非エンジニアが「お客様に聞かれて困ったこと」をそのまま投げれば、一次回答が返ってくる。エンジニアへのエスカレーション量を減らせます。

2. アラートの一次調査・原因分析

各サービスの通知チャンネルにアラートが投稿された際、AIがGitHubとAWSの情報を収集し、一次調査・原因分析・Issue作成・軽微な実装 まで対応できるようにしました。オンコールのエンジニアが叩き起こされる前に、「何が起きていて、どのコードが怪しいか」の当たりがついた状態になります。

筆者が特に効果を感じたのはここです。CloudWatchなどから飛んでくるモニタリング通知（メモリ不足、WAFの検知など）は、内容を読み解くだけでもそれなりに手間でした。それが、Slackで通知に対して @Claude に調査を依頼するだけで、原因の切り分け・Issue作成・簡単な実装まで進めてくれるようになり、体感の負担がかなり軽くなりました。「通知が来た → まず自分でメトリクスとログを追う」という定型作業を、そのままAIに巻き取ってもらえる形です。

運用上のガードレール

AIに任せる以上、線引きは明示しておくのが誠実です。実際のアナウンスでは次のように伝えました。

• AIの回答には 確信度（高・中・低） を表示する。低い回答は開発チームへ確認する
• ログインできないなどの 緊急性・重大性の高い障害 は、AIに頼らず従来どおり開発チームへ直接連絡する
• PRのレビュー・リリースは 必ずエンジニアが実施 する

AIは「一次対応と定型調査を巻き取る係」であって、最終判断を委ねる相手ではありません。この役割分担を明文化しておくと、現場が安心して使えます。

まとめ

SlackのAIアシスタントにAWSを参照させたいとき、最大の障壁は「認証情報をどうAIから隔離するか」でした。Claude Tagのアクセスバンドルに AWS SigV4 の認証情報を登録する構成は、署名を境界のプロキシに肩代わりさせることで、鍵をサンドボックス外に置いたまま接続する、という解をきれいに与えてくれます。実践のポイントは次の3点です。

• 鍵はプロキシに隠す: AWS SigV4認証情報タイプを使い、許可ホストをリージョン単位で絞る
• アクセスキー方式で、権限は最小限に: STS一時認証情報は非推奨。IAMユーザーに渡す権限は参照系だけに絞り、書き込み系や広範な権限は与えない
• AIの役割はガードレール付きで明文化する: 確信度表示、重大障害は人間へ、レビュー・リリースは人間が実施

同じパターンは、AWS以外のデータストアやAPIにも横展開できます。鍵の隔離という土台を一度作ってしまえば、「AIに社内の状態を見せて一次対応させる」範囲を、安全に広げていけるはずです。

---

弊社では、こうしたAIエージェントの業務組み込みや、認証・権限まわりを含めた安全な運用設計の支援を受託開発として行っています。「SlackのアラートやサポートをAIに一次対応させたい」「AI活用の勘所を相談したい」といったご相談があれば、お問い合わせからお気軽にご連絡ください。

参考文献

• Claude Tag: Custom connections（Claude Docs）
• Signing AWS API requests (AWS Signature Version 4)：AWS General Reference
• IAM security best practices（AWS IAM User Guide）