ブラウザの AWS Console は開けるのにだけ Agent Toolkit が止まります

ブラウザは拡張やシステムプロキシだけが効いて、boto3 やプラグインホスト側のランタイムは別コンテキストで動き、VPC 直下や異なる環境変数を見ていることがあります。まずプラグインログに出ている最終FQDNごとに Clash がどちらへ流したか突き合わせてください。

OpenAI 側の MCP とも併用したいです

同じ開発マシンで複数 SaaS に同時接続する場合、モデル提供者ごとのドメインを別 proxy-group にすると切り替えやすいです。AWS グループだけを select で固定すると Bedrock と STS の往復だけは出口がブレなくなりがちです。

AWS Agent Toolkit／Bedrock 分流

この記事でわかること

2026 年現在、IDE 側のAWS Agent Toolkitや Amazon Q に代表されるツールチェーンから Amazon Bedrock のモデル InvokeModel／Converse／Agents for Amazon Bedrock に届かないとき、画面にはたいてい「単なるネットワーク遅さ」でも「認証設定ミス」とも違う、妙に読み込みだけ止まる症状が現れます。典型は複数ホストへの通信が出口で分岐し、片方だけが不安定だったりレイテンシが跳ねて読み込みタイムアウトに見えるパターンです。

本稿は開発マシンの前にClash／Mihomo 系を置いた前提で、アカウント入口（STS や SSO のログインページ）、bedrock-runtime と bedrock-agent-runtime といったサービスごとのエンドポイント、アップロードやドキュメント取得に使う転送サイトまで、ログで実際に使われた FQDN を押さえ、分流規則で同じproxy-groupへ揃える考え方をまとめます。ルール順序や Fake-IP と DNS の話はYAML と Fake IP の分流解説を補助線にしてください。モデル一式の CDN 問題に近い切り口はOllama × Hugging Face の記事が近いです。

注意

企業アカウント、学校、公共機関のネットワークではプロキシや SaaS 利用に独自ポリシーがあります。本稿は一般向けのクライアント設定の整理であり、契約違反や不正アクセスを助長する意図はありません。疑う場合は社内 SecOps へ問い合わせてください。

なぜ「一部だけ断線」に見えるのか

AWS のクライアントは初回に認証トークンを取りに行き、そのあとリージョン付きの Bedrock エンドポイントへ再び HTTPS を張り直します。ここでブラウザはシステムプロキシだけ効いている一方、CLI や Node ランタイム上のプラグインは親プロセスの環境変数を見ていたり、boto3 が独自の証明書束や接続タイムアウトを別値にしていたりすると、両者の経路説明が食い違います。

とくに VPC Reachability を直接は使わない開発端末でも、SSO でブラウザに飛んだあと STS が返す短命クレデンシャルで runtime に切り替わるフローの途中で、「ログインウィンドウは成功した」「モデル一覧 API は通る」「Invoke が最初の数十秒だけ止まる」といった段階的なズレが出ます。その背後にあるのが、複数FQDN が異なるルール順位に刺さっていることばかりです。

押さえるべき代表ホスト

リージョンの差は読み替えつつも、開発で頻繁に並ぶ名前には次があります。sts.<region>.amazonaws.com、sso.<region>.amazonaws.com や SSO 開始 URL のドメイン、bedrock-runtime.<region>.amazonaws.com、エージェントやナレッジ連携があるならbedrock-agent-runtime.<region>.amazonaws.com。追加で S3 でアップロードするワークフローなら<bucket>.s3.<region>.amazonaws.com とその周辺サービスkms やsecretsmanager への呼び出しが混ざることもあります。

ツールチェーン側が CodeWhisperer や旧来のモデル統合でも、名前空間だけが増えtelemetry 系の送信先などが別グループへ流れるとログにエラーだけ残ることがあります。細部は自分のワークスペンスで露出した名前をソースとし、リストをコピペで増やすのが安全です。

ヒント

プラグインログにタイムスタンプつきHTTPSの宛先が並ぶ場合、その列をすべて Clash の接続一覧と突き合わせれば「MATCH 直行か」「RULE 命中か」が一気に揃います。最初から AWS すべてを広域マッチさせるより、実測セットを起点に増やしてください。

タイムアウトの決まり手

体感として現れやすいのは次です。チャットウィンドウのスピナーだけ回り続ける、モデルリストは出るが推論送信で固まる、環境によっては STS の AssumeRole だけ失敗ログが混ざる。ターミナルなら boto3 がConnectTimeoutError や読み込み系のタイムアウトをurllib3 レイヤから返すだけで済む一方、Electron 側の UI が「Loading tools…」などの文章で止まると原因の切り分けが後ろにずれます。

ひとつの見分けとして、問題がDPI だけによる遮断よりレイテンシとジッターに由来する際は、「短いモデル入力なら偶然通る」「長いコンテキストを送った瞬間に落ちる」といった揺らぎが出ます。その場合単純 DIRECT だけでは運に左右されやすく、複数経路があるノードセットを自動フォールバックまたは selectで束ね、「AWS_AI」に渡す出口をひとつのポリシーに収束させる効果があります。

クライアント側で先に済ませたい準備

上流で言うEnhanced Mode と近い構成が多い環境でも、開発端末だけ TUN、あるいはターミナルへ明示プロキシを足すときに二重プロキシがかかっていると結果が読めません。環境変数HTTP_PROXY を空にできるか確認しつつ、boto3 がboto_configs で独自タイムアウトを張っていれば Clash と足し算にならないかを頭に置きますAWS_CA_BUNDLE と社内証明書の競合でも TLS だけ落ちます。

VS Code と派生環境では、拡張のホストとターミナルがコンテナに分離されているケースもあり、そのときはコンテナ側の/etc/environment にプロキシが無いだけでブラウザと食い違います。この差を埋める運用より、開発マシンのルーター直上で TUN が安定していればプラグインホストも自動追従しやすいです。

分流ルールを書くときの優先順位イメージ

購読の既定ルールセットに頼ったままでもだいたいamazonaws.com がまとめて拾われることはありますが、まれにGFW リストと GEOSITE の優先競合で STS だけ別列に並ぶ構成もありえます。そのため STS／SSO 起点のホストだけを名前で先頭に並べひとつの select グループへ流すYAMLの骨格があると読みやすいです。GAME や広告リストより前に並べます。

proxy-groups:
  - name: "AWS_AI"
    type: select
    proxies:
      - NODE-A
      - NODE-B

rules:
  # Pin login & token exchange endpoints first
  - DOMAIN-SUFFIX,single-sign-on.amazonaws.com,AWS_AI
  - DOMAIN-SUFFIX,signin.aws.amazon.com,AWS_AI
  - DOMAIN-SUFFIX,sso.amazonaws.com,AWS_AI
  - DOMAIN-KEYWORD,sts.,AWS_AI
  - DOMAIN-KEYWORD,s3.,AWS_AI
  # Bedrock Invoke / Agent runtime endpoints (region-qualified)
  - DOMAIN-KEYWORD,bedrock-runtime,AWS_AI
  - DOMAIN-KEYWORD,bedrock-agent-runtime,AWS_AI
  - DOMAIN-KEYWORD,amazonaws.com,AWS_AI

上記はkeywordベースで説明優先です。細かい名前は実ログにあわせてDOMAIN やRULE-SET へ昇格してください。mihomo なら GEOIP との矛盾を見たうえで、誤ヒットしない幅を選びます。dialer-timeout や DNS の Fake-IP 設定はワークロード側の並列ダウンロードで気にかかりますので、まずは上流の名前解決ログと Clash を同タイムウィンドウで眺めると早いです。

OpenAI と併せて IDE で使うとき

同じワークスペースで OpenAI と Bedrock に同時接続するとき、モデル提供者ごとにグループを分けると運用が簡単です。OpenAI はDOMAIN-SUFFIX,openai.com や MCP 側の転送サイトをひとつのvendor-openaiに、Bedrock と STS は本文のAWS_AI に固定します。この区切りだけでも「AWS 側の Invoke が止まっているのにモデル一覧の別APIは別ホストだった」ような切り分けがログ上で並びやすくなります。

ログで検証する実務順序

プラグインログで失敗レスポンスより先に、どのタイミングで何秒待ったかだけが残るときは、その直前までに引かれた STS のFQDN と runtime のFQDNのペアが揃っているか確認します。boto3 がリトライするとき複数FQDN が交互に並ぶため、Clash で片方だけゼロ往復になるとログは途切れたように読めます。Invoke を同一入力で複数リージョン試すときも、名前空間はリージョン接尾辞だけが変わるのでルール増殖を避けられるはずです。

モデルコンテキストを大きく送るテストだけでタイムアウトが増えるときは、アップロードに使っている S3 と KMS の往復だけが増えている可能性があります。開発者コンソールのネットワークタブとは別視点になりますが、アップロードに使っているバケット名が複数だったら一覧化してグループ側に名前を増やしてください。

よくある質問

Q. SSO のブラウザは成功したのにすぐプラグインが止まります。
Temporary credentials が取得できなかったか、プラグインホストのランタイムが別の ~/.aws/ プロファイルしか見ていない可能性があります。また STS のFQDN だけ異なるポートやプロキシ設定を読んでいたり、コンテナ側にAWS_PROFILE が渡っていないケースがあります。両者の環境変数を同一ターミナルからprintenv AWS で突き合わせてください。

Q. 「購読の AWS 自動ルール」を信じてしまってよいですか。
購読が賢いときは大丈夫ですが、ワークロードは常に増えているので自分のプラグインログに出ない名前が誤ヒットしないかは一度検証しましょう。SSO と runtime を明示行に並べれば差分が読みやすくなります。

Q. IPv6 と IPv4 の両方があると不安定になります。
DUAL-STACK がデフォルトの環境では、片系だけ上流で塞がれると体感がフラつきます。tun stack や OS 側のアドレス選択を単純化し、上流で希望する単一経路だけを明示してから再チェックすると切り分けが早くなります。

まとめ

AWS Agent Toolkit を介したワークフローで Amazon Bedrock の API が読み込みだけ止まるとき、ひとつのエンドポイント遮断だけでなく複数FQDN が出口でぶれるケースがあります。Clash の分流規則とログの突き合わせで STS・runtime・アップロード先をひとつの出口に収束させると、`API タイムアウト`に見える揺らぎが収まりやすいです。YAML の優先順位と DNS の関係まで踏み込みたければ関連記事へ橋渡しできます。

設定がブラウザ専用拡張に寄るとモデル開発と日常ブラウズでルールセットが二度手間になりドリフトしやすいのに対して、ログと名前で追えるプロキシ層があるとワークスペース全体の検証も速くなります。クライアントの入手と更新一覧はダウンロードページへまとまっています。長いモデルワークフローでも出口を細かく揃えたい方は、ぜひ無料で Clash をダウンロードしてから本稿の手順へ当てはめてみてください。