AWS Agent Toolkit が IDE でタイムアウト？IAM・STS とツール API を Clash で分流する実測手順（2026）

なぜ IDE だけ「AWS 技能」が遅いのか

2026 年 5 月、AWS は AI コーディングエージェント向けの AWS Agent Toolkit を本格展開し、Visual Studio Code や Cursor などの IDE からクラウド側のリソース操作・調査・デプロイ補助をまとめて触れる導線が増えました。一方で「ブラウザの AWS Management Console は特に問題ないのに、エディタ内の AWS 技能や関連拡張だけが ETIMEDOUT や認証まわりの失敗に見える」「IAM や STS への到達が不安定でセッションが毎回切れる」といった報告も同時に増えています。原因の多くは単一ノードの品質だけではなく、IDE プロキシ配下で名前解決と出口の経路、そして Clash の分流（ホストごとに出口を変えるルール設計）の整合が崩れているときに起こりやすいです。

本稿は、すでに公開している AWS MCP Server と IDE 向けの AWS API 分流と役割を分けます。そちらが「MCP 経由で叩く管理系 API」に寄せた整理なら、こちらは Agent Toolkit が IDE 内で連鎖する認証フロー（IAM／STS、サインイン骨格）とツール実行側のリージョン APIを、接続ログからドメイン単位で書き分けることにフォーカスします。Cursor IDE 向けの汎用分流と併せると、拡張マーケットやモデル API と AWS 系ホストの優先順位調整がしやすくなります。

症状：タイムアウト・トークン失敗・片側だけ詰まる

AI コーディングエージェントのワークフローは、短い HTTP を束ねるだけではなく、長めの TLS セッションやストリーミング、SDK が内部的に叩くリージョン固有の *.amazonaws.com が連続しやすい構造です。IAM でポリシーやロール情報を読み、続けて STS 系で一時クレデンシャルを扱い、その先で Amazon Bedrock や他サービスの runtime に向く——この技能チェーンはホストが途中で切り替わるため、DOMAIN-SUFFIX,amazonaws.com を一括で雑に置いただけでは「どのサブドメインが律速か」が見えにくくなります。

さらに IDE はブラウザより環境変数（HTTPS_PROXY など）や、GUI クライアントの TUN 対象外プロセスという経路の不一致が出やすい典型です。Clash Verge でシステムプロキシを有効にしていても、言語ランタイムや拡張ホストだけ別出口に落ちると、コンソールでは通るのに ツール API だけ失敗に見えます。切り分けの第一歩は、失敗時にどのホスト名がログに出ているかをメモし、どのプロキシグループに載ったかをダッシュボードで一致させることです。

注意：リージョン名・エンドポイント・プレビュー機能のホストは更新され得ます。本稿のドメイン例は設計の出発点であり、実際の宛先は利用中の SDK 版と IDE 拡張のリリースノート、接続ログで必ず確認してください。料金・アカウント権限・コンプライアンスはご自身の契約に従って判断してください。

コピー用：IAM・STS・コンソール骨格のたたき台

実務では次の DOMAIN-SUFFIX をベースに、Clash の rules: へ並べます。Agent Toolkit が内部的に増やすホストがあるため、タイムアウト時は接続一覧で追記を洗い出してください。

  • 認証・トークン周辺：iam.amazonaws.com、sts.amazonaws.com、およびリージョン付きの sts.*.amazonaws.com（ログに出たリージョン名に合わせる）
  • マネジメントコンソールの骨格：console.aws.amazon.com、aws.amazon.com、SSO 利用時は signin.aws.amazon.com や awsapps.com などが混ざることがある
  • ツール／runtime 一般：amazonaws.com 配下のサービス固有ホスト（例：Bedrock runtime、エージェント実行に伴うリージョン URL）。実際のホスト名はクライアントログで確認するのが確実です。
  • テレメトリやヘルプ：コンソール体験の計測用ホストが増える場合がある。IDE 側で詰まるときは開発者ツールの Network 相当のログが取れる拡張設定も活用する

広すぎる DOMAIN-KEYWORD,aws は無関係サイトまで同じ出口へ載せる恐れがあるため、まず DOMAIN-SUFFIX で狭く始め、漏れをログで足す運用が安全です。ルールの共通課題は ルール分岐の詳解にまとめています。

認証用とツール API 用でプロキシグループを分ける

単一の select に海外向けを全部流すと、一般ブラウジングと同じノードへ 長時間の STS／Bedrock セッションが載り、律速や切断の影響を受けやすくなります。AWS_AUTH_PROXY（IAM／STS／サインイン骨格向け）と AWS_TOOL_API_PROXY（リージョン ツール API 向け）のような独立プロキシグループを切り、認証はレイテンシの良い出口、runtime は切断が少ない出口へ寄せると成功率が上がりやすいです。

Clash Verge ではプロファイルを開き、グループ名が rules: と一致しているか確認してから再読み込みします。運用中に「認証だけ別ノードにしたい」とき、AWS_AUTH_PROXY だけを切り替えて再試行できるのが利点です。

評価順：DOMAIN 行を GEOIP より上へ

Mihomo 系はルールを上から順に評価し、最初の一致で打ち切ります。DOMAIN-SUFFIX,iam.amazonaws.com を追記したつもりが、上段の GEOIP や巨大な RULE-SET に先に吸われている——これが「YAML は正しいのに効かない」典型です。より具体的な行を、大雑把な締めより上へ置き、保存後に順序を目視してください。

国内向けを誤って海外ノードへ載せないためにも、GEOIP,CN,DIRECT や社内向けサフィックスなど直結を守る行が、意図せず後ろに押し出されていないかを確認します。国内向け DIRECT の優先度を併読すると、順序の詰めが素早くなります。

YAML の骨格例（概念サンプル）

インデントやキー名は利用中のコアに合わせてください。ここでは認証系と汎用 API を分けた最小イメージだけ示します。

proxy-groups:
  - name: AWS_AUTH_PROXY
    type: select
    proxies:
      - 🇯🇵 低遅延
      - 🇺🇸 安定
      - DIRECT

  - name: AWS_TOOL_API_PROXY
    type: select
    proxies:
      - 🇺🇸 長接続向け
      - 🇯🇵 バックアップ
      - 🌐 自動選択

rules:
  - DOMAIN-SUFFIX,iam.amazonaws.com,AWS_AUTH_PROXY
  - DOMAIN-SUFFIX,sts.amazonaws.com,AWS_AUTH_PROXY
  - DOMAIN-SUFFIX,console.aws.amazon.com,AWS_AUTH_PROXY
  - DOMAIN-SUFFIX,amazonaws.com,AWS_TOOL_API_PROXY
  - DOMAIN-SUFFIX,aws.amazon.com,AWS_AUTH_PROXY
  - GEOIP,CN,DIRECT

実ログで sts.ap-northeast-1.amazonaws.com などが律速なら、その行を明示しても構いません。MATCH の直前までに細かい行を寄せ、名前の衝突がないよう既存グループと調整してください。

DNS・TUN：タイムアウトに見える別要因

ルールが正しくても、名前解決の経路が割れていると実接続は別出口へ落ちます。典型例は次のとおりです。

  • ブラウザや OS の Secure DNS が Clash 外で先に解決する
  • Fake-IP と一部プロセスだけが使うシステム DNS が混在し、ログと体感がずれる
  • 不安定なノードが長い TLS を切り、クライアントでは タイムアウトに見える

対策の方向性は、解決経路をできるだけ一本化し、TUN で IDE 子プロセスを透過させるか、TUN モードの設定と DNS ハイジャックの前提を揃えてルールを読むことです。

検証手順（そのまま試せる順序）

  1. 失敗している操作（スキル起動、クロスアカウント参照、モデル呼び出し）ごとに、ホスト名をメモする。Clash Verge の接続ビューが速い
  2. 該当ホストが AWS_AUTH_PROXY／AWS_TOOL_API_PROXY のどちらに載っているか確認し、意図しない GEOIP へ落ちていないか見る
  3. 同じプロファイルのまま、ツール API 側グループのノードだけを切り替え、失敗の再現性が変わるか比較する
  4. ブラウザだけ成功するときは、HTTPS_PROXY と TUN の対象、拡張ホストのプロセス親子を揃えて再試行する
  5. 診断の間だけ該当グループを DIRECT にし、ルール誤りとノード品質を切り分ける（常時直結は非推奨な場合がある）

Mihomo コアと Clash Verge の運用メモ

外部 RULE-SET を重ねるプロファイルでは、追記した明示ルールが下に埋もれやすい点に注意してください。Clash Verge のテキスト編集と接続ログを並べると、Agent Toolkit が新たに触ったホストの発見が速くなります。IDE プロキシまわりはクライアントのアップデートで挙動が変わり得るため、月次でログを一度棚卸しするのも有効です。

よくある質問

MCP 向け記事とルールが被りませんか

IAM／STS のサフィックスは重なり得ます。被った場合は優先順位とグループの役割（認証と runtime）を文章で固定し、チーム内で同名グループの意味を揃えてください。呼び出し経路が異なる場合は MCP 向け分流のドメイン一覧と突き合わせます。

国内 CDN やミラーまでプロキシに乗ります

amazonaws.com 一括ルールの後ろに続く明示ルールで、国内向けサフィックスを DIRECT に逃がします。広すぎるキーワード一致は避け、ログで実ホストから足します。

STS のリージョン URL が複数出ます

SDK とツールの設定で向き先が変わります。ログに出た sts.*.amazonaws.com をそのまま DOMAIN-SUFFIX では足りないこともあるため、必要なら DOMAIN 行でホスト完全一致にします。

まとめ

AWS Agent Toolkit の普及に伴い、IDE 内の AI コーディングエージェントが触る IAM／STS とリージョン ツール APIが同時にボトルネックになる場面が増えています。症状の多くは単一ノードのスコアだけでなく、ドメインごとの出口とルール評価順、DNS の噛み合わせで説明できます。DOMAIN-SUFFIX で認証系と runtime 系を切り出し、Clash のログと突き合わせながら調整すると、再現性のある改善がしやすくなります。

一方で、GUI を寄せ集めただけの汎用ツールは、プロファイルのバージョン管理やIDE プロキシと AWS ホストの対応説明が薄く、チーム運用では行き詰まりやすいものもあります。ClashSource はダウンロード導線とチュートリアルを一箇所に揃え、記事どおりにルールへ落とし込みやすいよう整理しています。利用規約や更新サイクルも踏まえ、自分の環境に合うクライアントを選びたい場合は、説明の揃った配布元から入れるのが安全です。無料ダウンロードから OS 別ビルドを選び、本稿の分流をそのまま試せます。基礎手順は ドキュメント一覧、AWS 開発者ツール全般の経路整理は AWS MCP Server 向け記事と併読すると一本化しやすいでしょう。