症状：MCP Fetchの更新後、localhostや開発用URLへの取得が拒否されます。
最短の切り分け：MCP Fetch 2026更新後の拒否は、まず最終的な解決先IPを確認します。公開アドレス以外を指している場合は、既定の安全制限に該当する可能性が高く、信頼できる隔離テストで本当に必要な場合だけ、私有IPを許可する起動オプションを使います。
【向いている方】AI AgentからローカルのWebアプリを確認する開発者や、MCP Serverの実行環境を管理するプラットフォームエンジニア向けです。
拒否された要求が想定内の保護なのか、アプリや名前解決の不具合なのかを見分け、ローカルで調査するか隔離環境へ移すか判断できます。
MCP Fetch 2026更新後のlocalhost拒否は、IPの種類から見分けます
公式のリリース記録では、MCP Servers v1.0.0にFetch 2026.10.10の更新が含まれ、非公開アドレス、ループバックアドレス、メタデータ用アドレスを既定で拒否する動作が示されています。したがって、更新直後に特定の宛先だけ失敗する場合、まずサービスの停止ではなく、対象ホストの名前解決結果が拒否対象に当たるかを確認します。根拠は公式v1.0.0リリース記録とFetchの更新内容です。
localhostはホスト名であり、それ自体が接続先IPを示すわけではありません。ループバック、LAN内のアドレス、公開アドレスでは意味が異なるため、ホスト名だけで判断せず、端末上の名前解決結果とFetchの要求記録を突き合わせます。
| 宛先の種類 | 解決先の例・目安 | 拒否されたときの見方 |
|---|---|---|
| ループバック | localhost、127.0.0.1など |
本機向けの接続です。既定で拒否される対象か確認します。 |
| 私有ネットワーク | 組織内LANや開発用ネットワークのアドレス | 公開サイトではなく、ローカルまたは組織内サービスに向かう要求です。 |
| 公開アドレス | インターネット上で到達可能な公開アドレス | これだけで成功が保証されるわけではありません。転送先や別の制限も調べます。 |
| メタデータ用アドレス | クラウド環境などで管理情報に使われる宛先 | 意図しないアクセスを避けるための拒否対象に含まれます。 |
IPv4の特殊用途範囲はIANAのアドレス登録情報、IPv6の範囲はIPv6特殊用途アドレスの登録情報で確認できます。私有IPv4アドレスの定義にはRFC 1918も参照できます。アドレス範囲を独自に決めつけず、公式実装がどのように判定しているかも確認してください。
直接localhostへ接続できないときは、名前と待受状態を分けます
まず、対象が本機のサービスなのか、同じLAN内の別端末なのかを明確にします。localhostは要求を実行する環境自身を指すため、AgentやFetchが別のコンテナ、仮想環境、リモートホスト上で動いているなら、開発者の端末にあるサーバーとは別の場所を指します。
次に、Fetchのエラーだけでサーバー故障と断定せず、同じ実行環境から通常のHTTP要求を行い、接続先と応答を記録します。併せて開発サーバーの待受アドレスを確認してください。サービスが127.0.0.1だけで待ち受けている場合、別の実行環境からは到達できないことがありますが、待受範囲を広げるとアクセス可能な範囲まで広がるため、安易な変更は避けます。
| 確認項目 | 記録する内容 | 次の判断 |
|---|---|---|
| 実行場所 | FetchとAgentが動作するホスト、コンテナ、仮想環境 | 開発者端末と同じ名前空間かを確認します。 |
| 解決先 | 要求時のホスト名と解決されたIP | ループバックや私有IPなら、拒否が意図された動作かを確認します。 |
| 待受状態 | 開発サーバーの稼働状態と待受先 | 接続不能とFetchの安全制限を混同しないようにします。 |
| 応答記録 | 実行環境からの要求結果とエラー | Agentが生成したURLだけを根拠にせず、実際の通信を照合します。 |
公開URLの取得失敗は、リダイレクトの各段階を追います
公開サイトへの要求が拒否された場合も、最初のURLが公開アドレスであることだけでは判断できません。応答後に別ホストへ転送され、その転送先がループバック、私有ネットワーク、メタデータ用アドレスに解決されると、転送後の要求が拒否される可能性があります。Fetchの説明と実装は公式READMEおよびアドレス検証を含むソースコードで確認できます。
| 要求段階 | 記録する情報 | 拒否原因の見つけ方 |
|---|---|---|
| 最初の要求 | 入力URL、ホスト名、解決先 | ここで拒否されたのかを分けます。 |
| 転送応答 | 応答元と転送先URL | 転送先ホストが変わっていないか確認します。 |
| 転送後の要求 | 転送先の解決結果とエラー | 制限対象のアドレスへ移っていないか特定します。 |
転送の記録が取れない場合は、公開URLへのアクセス自体が安全だと仮定せず、転送先を個別に確認します。MCP reference servers 1.0の更新内容を調べる際も、バージョン名だけでなくFetchの変更記録とREADMEを合わせて参照すると、既定の挙動と起動オプションを混同しにくくなります。
同じドメインで結果が変わる場合は、DNSとプロキシを疑います
ドメイン名が同じでも、実行環境や時刻によって解決結果が異なることがあります。ある要求では公開IP、別の要求では私有IPが返るなら、DNS応答と拒否された要求の時刻をセットで記録してください。名前解決をプロキシ側で行う構成では、Fetchを動かすホストで見た結果と、実際に接続する側の結果が一致しない可能性があります。
公式資料が説明する制限は、DNS再バインディングやプロキシ側の名前解決に由来するリスクをすべて解消するという保証ではありません。許可された宛先に見えることだけをもって、ネットワーク全体が安全と判断しないでください。MCPの公式セキュリティ推奨事項も併せて確認し、実行環境の分離や外向き通信の制御を検討します。
例外設定は、必要なテストだけに限定します
公式READMEでオプション名と動作範囲を確認したうえで、本機サービスへのアクセスが必要な、信頼できるテスト環境に限り--allow-private-ipを指定します。このオプションは拒否制限を緩めるためのもので、接続先を安全と判定したり、ネットワーク全体の危険を取り除いたりするものではありません。実際の起動方法は、利用中のパッケージと公式READMEの記載に合わせます。
私有IP許可を常時有効にするのではなく、対象のテスト用プロセスにだけ設定し、完了後はオプションを外して通常設定で起動し直します。
設定範囲を迷ったら、次の項目を実行前後に確認します。
- [ ] Fetchが動作するホストまたは隔離環境を確認します。
- [ ] 要求先が自分たちの管理下にあるテスト用サービスか確認します。
- [ ] オプション名と作用範囲を公式READMEで確認します。
- [ ] 起動設定を対象のテスト用プロセスに限定し、常用設定へ混ぜません。
- [ ] 要求先、名前解決結果、転送先を記録して、許可が必要な通信だけを検証します。
- [ ] テスト完了後に許可オプションを外し、通常設定で再起動したことを確認します。
評価： 既定の拒否を保つ方法は安全性を優先する運用に適しています。例外設定はローカル検証を可能にしますが、許可範囲と残るリスクを管理できる場合に限る選択肢です。開発サーバーを一時的に公開アドレスへ移す方法もありますが、公開範囲や認証の設定を別途管理する必要があります。
2026年10月13日時点で、MCP Servers v1.0.0の公開記録、Fetch更新項目、READMEおよびアドレス検証の実装を照合しています。後続の変更で既定動作やオプションが更新される可能性があるため、利用環境へ適用する際は公式資料の現行記載も確認してください。
よくある判断
メタデータ用アドレスへの要求が止まる場合も、まずは拒否された事実を異常とみなさず、要求の発生元と目的を確認します。AI Agent向けMCP Serverのアクセス範囲を広げる前に、ローカル検証だけで必要な通信を再現できるかを切り分けてください。
一時的な開発環境を用意する場合、ローカル端末の設定変更だけで済ませる方法には、環境差が残ること、内部ネットワークへの接続範囲を把握しづらいこと、検証後に例外設定を戻し忘れることがあります。長期の常時稼働や物理インターフェースが必要なら自前のMac環境が適しますが、隔離した一時環境で再現性を重視するなら、zekmacのMacレンタルも比較対象になります。利用可能な環境はコンソールの案内で確認し、接続や利用上の疑問はヘルプを参照してください。
MCP Serverのネットワーク分離を実装できる環境を用意し、そこでローカルWebアプリの確認を行うと、開発端末の例外設定を常用せずに済みます。短期の検証に限らず、継続的に同じテストを回す場合は、自前の実行基盤とレンタル環境の運用条件を比べ、必要な分離と管理方法に合う選択肢を決めてください。
よくある質問
MCP Fetchの更新後、localhostへの取得が拒否されるのはなぜですか？
更新後は、取得先がlocalhostという名前かどうかだけでなく、名前解決後のアドレスが回 loopバックや私有アドレスなどに当たるかも検査されます。したがって拒否は、開発サーバーの停止を意味するとは限りません。まず実際の解決先とFetchのエラー記録を照合し、公開アドレス以外なら意図された制限かを確認してください。
ローカル開発サーバーをMCP Fetchから確認するにはどうすればよいですか？
本番相当の通常設定では拒否される宛先でも、隔離された信頼できるテスト環境なら、公式READMEでオプション名と対象範囲を確認したうえで、起動時に私有IP許可を明示できます。対象サーバー、起動プロセス、テスト内容を限定し、確認が終わったら許可を外して通常設定で再起動してください。
公開ページが社内アドレスへ転送された場合も取得は止まりますか？
止まる場合があります。最初のURLが公開サイトでも、転送先のホスト名がループバック、私有IP、メタデータ用アドレスなどに解決されれば、転送後の要求が拒否対象になり得ます。最初のURLだけを調べず、転送の各段階でホスト名と名前解決結果を記録してください。
私有IPへのアクセスを許可すると、どのような危険が残りますか？
AI Agentが意図せず内部サービスや管理用エンドポイントへ要求を送る経路が広がります。また、公式の説明はDNS再バインディングや、プロキシ側で名前解決する構成を含むすべての攻撃を防ぐ保証ではありません。信頼できる試験に限定し、外向き通信の制御や実行環境の分離も併用してください。
関連記事
zekmac M4 リモートノード
接続検証用のMac環境を、zekmacで用意しませんか
MCP Fetchの接続確認を手元の環境だけに頼らず進めたい方は、zekmacの物理Mac miniを開発・検証用にご活用いただけます。