AWS MCP サーバ GA 後、コーディング Agent が AWS を呼ぶと総タイムアウト？API ゲートウェイと STS・リージョン API を Clash・mihomo で束ねる実測メモ（2026）

1. なぜ npm 版 MCP 記事とは別に「AWS IAM／API」を切り出すのか

Model Context Protocol 自体はツール説明や呼び出しの枠組みに過ぎず、サーバ実装によって背後が npm だけのものもあれば、クラウドの公式コントロールプレーンに直結するものもあります。AWS が提供する経路では、セットアップ手順によってはpip やコンテナ・イメージより先にAssumeRole と STS AssumeRole／GetCallerIdentity／SSO のトークン交換がボトルネックになり、ここが遅いノード・意図しない DIRECT・split horizon DNSに当たると、エディタ画面上は「モデル応答」と「クラウド操作」の二者で体験の温度差だけが残ります。そのためregistry と Git のホワイトリストだけを整備しても、サービス単位・リージョン単位のホスト追加が追いつかないケースが出ます。

とはいえ、IDE 側の HTTP 経路との二重統制は無視できません。Cursor と開発ドメインの分流で整えているマーケット・API モデル経路と、AWS MCP が叩く*.amazonaws.com またはリージョン付き STSを結果として同じ低遅延グループへ流すかどうかだけは、頭のなかで表を別にすると切り分けが速くなります。

2. Agent コンソールで典型的に見える失敗モードと証跡の取り方

体感として（A）リスト操作・参照 API は通るが、書き込み系だけタイムアウト、（B）コンソールのログインだけ早く MCP 側の認証だけ遅い、（C）TLS の Client Hello より先で固まる、の三パターンに大雑把に収束しがちです。（A）は別リージョンのコントロールプレーンかクロスリージョンの書き込み先が直結または遠い経路にばらけているときに起きやすく、コア側のログでサービスごとの FQDNをメモすることが第一歩です。（B）はawsapps.com や signin.aws.amazon.com と sts.*.amazonaws.com が異なるノードまたは DIRECTに落ちている典型で、ブラウザのネットワークタブだけ見ても MCP 側のプロセスと一致しないので、mihomo の接続テーブルを同一時刻軸で見る価値が高くなります。（C）は DNS 競合よりICMP より前のレイヤでのブロック／MTU／HTTP/3も疑いたくなりますが、開発者ワークステーション単体での切り分けでは、まず経路統一→DNS と fake-ip を揃える順が現実的です。

もし MCP 側のツールチェーン自体がコンテナまたは WSL 内で動いているなら、127.0.0.1 の指し先やゲートウェイがホスト側 Clash と食い違っていないかだけ先に確認してください。そうでなければ、ルール評価の話に時間をかけても効率が落ちます。

3. まず意識するホスト類：STS、コンソール、SSO、サービス別 endpoint

アカウントや組織の構成によって増減しますが、まず頭に置ける出発点の束としては次があります。sts.amazonaws.com（グローバル STS）とリージョナル STS、signin.aws.amazon.com／*.awsapps.comによるSSO とディレクトリ入口、開発者から見えやすいconsole.aws.amazon.com、サービス読み込みログに並ぶ{service}.{region}.amazonaws.comという形のホスト群、HTTP API 統合がある場合のexecute-api.*.amazonaws.comやカスタムドメイン経由ゲートウェイ、そしてまれにだけれどログに混入するCloudFront や S3 を介した署名付きオブジェクト参照です。ブラウザ向けコンテンツのうち CDN 側は Notion など別アプリでの AWS CDN 統合記事と問題意識が近いので、コンソール表示が固まって実 API は通っているように見えるときはCDN行が足りていないだけ、という単純なケースもありえます。

中国クラウドのパーティションやローカライズされた名前空間を使っている場合は、*.amazonaws.com.cnのように末尾が異なり、一つの広い RULE にまとめすぎると別アカウント環境への誤送出が起き得るため注意します。開発者ワークステーションの用途が AWS オンリーであれば敢えてシンプル化してよい反面、複数クラウドを混在させるときはログドリブンで絞り込んだほうが安全です。

4. mihomo ルール例：AWS_AGENT 策略へログドリブンで束ねる

運用としては「モデル」「npm／GH」「AWS コントロールプレーン」の三つだけでも策略名を分けずに束ねられるならそれで構いませんが、問題が出たときの切り分け速度ではAWS_AGENTのような名前を独立した選択型グループとして切り出すとやりやすいです。ルール優先順位の原則どおりMATCH より上に具体的なホストルールを置き、広い GEOIP が先に評価されてしまう構成になっていないか GUI で並びを必ず確認してください。

構造ベースの例を示します。プロキシ名は自分の構成に差し替え、コメントは英語のみとします。

# proxy-groups: dedicated select for MCP / boto3 hitting AWS endpoints
proxy-groups:
  - name: AWS_AGENT
    type: select
    proxies:
      - TOKYO_LOWLAT
      - GLOBAL_STABLE
      - DIRECT

# rules — keep before MATCH / GEOIP
rules:
  - DOMAIN-SUFFIX,signin.aws.amazon.com,AWS_AGENT
  - DOMAIN-SUFFIX,awsapps.com,AWS_AGENT
  - DOMAIN-SUFFIX,console.aws.amazon.com,AWS_AGENT
  - DOMAIN-SUFFIX,sts.amazonaws.com,AWS_AGENT
  - DOMAIN-KEYWORD,amazonaws.com,AWS_AGENT
  - DOMAIN-SUFFIX,{service}.{region}.amazonaws.com,AWS_AGENT  # add from logs
  - MATCH,MATCH_TAIL

DOMAIN-KEYWORD amazonaws.com は他の AWS アプリトラフィックも同じグループへ載せやすく、普段ブラウザで見ているダッシュボードと挙動を揃えたいときは便利です。逆に社内のみ Direct にしたい S3やローカルの LocalStack を誤認しないよう、名前の衝突がなければ良いだけで、問題が続くときはログにキーワードよりもサフィックス行を足してください。TUN モードでの取り込み漏れがある場合は TUN とシステム代理の順序説明と合わせ、トラフィックがコアに乗っているかを先に合わせます。

5. DNS（fake-ip）と TLS／SNI：ルール評価をズラさない

mihomo 系でfake-ipを使うとき、開発者ワークステーションで最も時間を溶かすのは名前解決の実体と実際のアウトバウンド先の評価が食い違うパターンです。HTTPS であればSNI を復元して DOMAIN 評価に載せる構成が効く場面がありますが、サービス側の構成やクライアント実装により握り続けられるコネクションになると体感は TLS フェーズだけ固まっているように見えます。共通の読み替えガイドは DNS fake-ip と redir-host を比べた記事に譲り、実務には接続ビューのホスト名とルール評価列を同時に並べて見るだけでも半分ほど収束することが多いです。

さらに、ブラウザの Secure DNS と OS のリゾルバと Clash の dns: 設定が競合すると、コンソールは通ってターミナルの boto3 だけ異なる名前解決になります。シェル側とブラウザ側で診断ログを並べないまま広い RULE を増やしても収束しないので、そのときは名前解決の一本化から入ってください。

6. boto3・環境変数・VPC エンドポイント：プロキシ二重も疑う

IAM コンテキストの切り替え自体はAssumeRole とプロファイルチェーンの正当性や期限で失敗することが多く、その場合プロキシ以前に STS が 403 や明示的な署名エラーになります。「応答があるが遅い」「途中で張りつく」のようにエンドポイントまでは名前が通るのに転送だけ怪しいときには、環境側を疑います。HTTP_PROXY／HTTPS_PROXY と NO_PROXY が MCP とは別プロセスだけに残っている残骸、アカウント側で強制されているVPC エンドポイントや Privatelink に向いた DNSがローカルの Clash と二重になり期待したグローバル STSに届かない、といった順で除外していくと手戻りが減ります。

AWS_ENDPOINT_URL で強制的に異なる検証環境へ向ける運用とも衝突し得るので、開発者ワークステーションの /.aws/config とシェルのエイリアスだけIDE とは別ソースになっていないかを一度棚卸しすると安全です。サービスクォータ／レートリミットで遅く見えるときはログの HTTP コードが規則正しく出ているはずであり、その場合出口ノード単位での改善だけでは頭打ちになる点も忘れずにください。

7. Cursor・GitHub エージェントでは IDE 側 HTTP 経路も揃える

Cursor で複数ウィンドウを開いているとき、並列 Agentsが別プロセスになり HTTP 経路が分岐しやすいのと同種の問題が MCP にも転がります。GitHub が提供するエージェント実行環境側では自分のワークステーション上の Clash はそもそも見えませんが、その場合でもローカルで再現すべき名前空間だけをこの稿の観点に落とせば、コンテナまたはセルフホスト MCP を同じ AWS 開発アカウントへ向けるときのチェックリストになります。オーケストレーションをローカルに置く構成では、モデル側とツール側の二重の TLS 検査がないかも視野にいれます。

Clash がオフの状態で一度 AWS CLI だけ成功するか確認し、そのうえでプロキシを段階的に戻していく二分探索は地味ですが最も情報量が増えます。ここでの目的は規約順守より再現ログの質を上げることです。

8. url-test とログで運用するときのコツ

ノード自動選択だけに頼るとサービス単位ごとに最適とは限らない出口が混ざり、体感 RTT と TLS がブレやすくなります。url-test／fallback と手動 selectのバランスを AWS_AGENT グループに対してだけ固定寄りへ寄せておく運用でも、開発者ワークステーション向けには十分効きます。ログは接続イベントとルール評価列を中心にスクショまたはテキストで残しておくとチームでの横展開も早く、MCP が GA として普及するにつれてサードパーティ実装側のユーザー定義ゲートウェイが増えれば、そのたびログに載っただけを足していく運用に慣れるのが最短です。

開発者ワークステーションの用途が広いほどルール数は肥大化しますが、名前付けとコメントだけ整えれば Git で差分レビューしやすいのがコード中心 YAML の利点です。GUI 側で並び順が崩れたままになる事故だけは定期的にチェックしましょう。

9. よくある質問

AssumeRoleWithWebIdentity だけ遅く感じます。

IdP と STS の往復および OIDC メタデータ取得が増えている可能性があります。openid-configuration 系のホストがログに出ていないか、別策略にばらけていないかを確認してください。認証の期限切れと混同しないよう HTTP コードも併記します。

API Gateway をカスタムドメインで公開しています。

amazonaws.com と無関係な独自ドメインに TLS が終端している場合があります。ACM 証明書と CloudFront が絡んでいれば、ブラウザ用の名前空間を別グループへ流す運用とも整合が必要です。実名は必ずログとブラウザの開発者ツールから拾ってください。

Organizations 配下のアカウントでも同様ですか？

SCP とコントロールタワー関連の名前空間がログに増えやすく、組織横断ビューを開くときはコンソール用と API 用のホストが一気に混ざります。名前の束ね方は共通ですが、出口を企業側で固定したいポリシーがある場合は AWS_AGENT が必ずしも許可されません。

10. まとめ

AWS MCP が一般提供に入り、モデルとは別レイヤのSTS とリージョン分散したサービスホスト束がエージェントの応答体感に直結した場面では、npm／GitHub 取得だけ整えていても足りません。ログに載ったamazonaws と SSO 関連を開発者固定の選択型グループへ送り、fake-ip と SNI と環境変数の三者を同じ物語へ揃えるだけでタイムアウトに見える事象は大きく減りやすくなります。IAM とクォータの話はレイヤが違うため、ログのコードと並べて読みましょう。

開発者ワークステーション向けソフトウェアにおいて、「とりあえず全体をグローバルプロキシにするだけ」のラッパーは最初は楽でも、サービス単位ログが薄く柔軟な DOMAIN 並べ替えがしづらい製品ほど、この手の MCP＋複数ホスト問題で再現しないトラブルに時間が溶けることがあります。規則的なログと細かなルールの優先順位をユーザーが握れる mihomo 系では、前述の名前空間をその日ログに載った順にYAMLへ足すだけでチーム開発でも回していけます。

仕事用の構成を一度まとめるなら、クライアント種別ごとの差ではなく運用耐性を優先して選ぶのが楽です。 → 公式サイトから無料で Clash をダウンロードし、mihomo 分流とログを試す