Claude Code 始めました
「そのツール、ありません」とAIが言う本当の理由は、DDNSだった

はじめに

自宅サーバーで MCP サーバーを何本か立てて、Claude や ChatGPT から叩かせている。 サーバー本体も監視機も AI に組ませて、わりと安定運用してるつもりでいた。

なのに、ある日 Claude が言う。

「そのツール、見つかりません」

え。さっきまで使えてたじゃん。

セッションを再起動すると、また使える。 しばらくしてまた「見えません」。 再起動。直る。

「たまに消える」が一番厄介

このパターン、原因切り分けが面倒で進まない。

  • アプリは生きてる
  • ポートも listening
  • ヘルスチェックも通ってる
  • でも AI 側からは「ツールが登録されてない」

サーバーログを見ても、別に何も落ちてない。 クライアント側のログを見ても、接続を試みた形跡すら残ってない時もある。

おかしいな、と思いつつ、何ヶ月か「再起動で直るからまぁいいか」で流してきた。 こういう確率的な失敗は、人間が触る分には「あ、また失敗した」で流せる。再ロードボタンを押せば終わりだから。

AI に常時叩かせると、揺らぎが顕在化する

これが AI に MCP として登録された途端、話が変わる。

セッションが始まるたび、AI は登録された MCP サーバーに繋ぎに行く。 名前解決して、TLSハンドシェイクして、ツール一覧を取って、コンテキストに乗せる。 この間にどこか1ステップでも失敗すると、そのセッション中ずっと「ツールが見えない」状態になる。

人間が手で叩いていた頃は「あ、失敗した。もう一回押そう」で済んでた確率的な失敗が、AI のセッション境界とぴったり噛み合うと、ツールがそもそも存在しないのと同じ状態で会話が始まる。

そして AI 側からは「そのツールはありません」とだけ返ってくるので、人間からは原因が見えない。

一番下の層を疑った

「ネットワーク」「TLS」「サーバー」あたりを順番に疑って、最後に DNS が残った。

自宅サーバーは固定IPじゃないから、DDNS（dynv6.net）を使ってた。固定IPじゃない人の定番だ。長年お世話になってた。

その DDNS が、時々 名前解決に失敗してた。

具体的には、dig で叩いた時に NXDOMAIN や SERVFAIL が返ってくる瞬間があった。プロバイダー側の問題か、上流のキャッシュか、レートリミットか、はっきりは分からない。 数分後、もう一度 dig すると、何事もなかったように普通に通る。

……これか。

「数分前に通った名前が、今は通らない」が確かに起きていた。 そして DDNS の解決が落ちた瞬間に AI のセッションが始まれば、ツールは消えてる。 たぶんこれだ、と当たりをつけた。

DNS を疑うって、これまでなかった

これに気づいた時、自分でも結構驚いた。

俺、これまで DNS を疑うって発想がほぼなかった。 名前解決ってのは、ブラウザのアドレス欄に何か打って、繋がるか繋がらないか、それだけだった。 「時々失敗する」というモードがあること自体、意識から抜けていた。

DNS というレイヤーの存在に、意識が向いてなかった。 名前解決が「動いてるか壊れてるか」の2択じゃなく、**「動いたり動かなかったりするもの」**だという認識が、そもそも俺の中になかった。 AI に毎日叩かせて、初めてそこに意識が向いた、ということになる。

Cloudflare Tunnel という選択肢

ここで Cloudflare Tunnel に行き当たった。

固定IPじゃないサーバーから、Cloudflare のエッジに 自分から outbound で常設接続を張る。クライアントからは Cloudflare の DNS で引いてエッジに繋がるだけ。あとは tunnel が自宅まで運んでくれる。

つまり俺のサーバーは、もう DDNS で名前を晒す必要がない。 Cloudflare の DNS が名前を持って、Cloudflare が出口になってくれる。

自分のドメイン（kitepon.dev）を Cloudflare に NS 登録して、サブドメインごとに tunnel route を切るだけ。固定IPは要らない。ポート開放も要らない。DDNS の更新スクリプトも要らない。

ついでに消えた、2つの運用負債

移行して気づいた副作用が2つあった。両方ともボーナス枠だが、地味に効く。

ひとつ目: hairpin NAT 対策の /etc/hosts 行脚から解放された。

俺はソフトバンクの 10G 回線を使ってる。これは hairpin NAT が効かない。 自分の公開ドメインを自宅 LAN の中から叩こうとすると、外に出て戻ってくる経路が組めなくて詰む。

これまでの対策は、端末ごと・コンテナごと・WSL ごとに /etc/hosts で内向きアドレスを書いて回ることだった。これが地味な運用負債で、新しい端末を増やすたび、新しいコンテナを立てるたびに、hosts の更新を強いられる。

Cloudflare Tunnel に乗せたら、内から叩いても外から叩いても同じ経路（Cloudflare 経由）になる。hosts の特別扱い、全部消した。

ふたつ目: ソフトバンク回線で、不定期に inbound 遮断を食らうことがあった。

これも長年地味に困ってたやつ。ソフトバンクの回線か、ホームゲートウェイか、上流のセキュリティ対策か、原因は特定できてないが、外からのアクセスが繋がらない時間帯がたまにあった。

Cloudflare Tunnel は自宅サーバーから outbound で張る常設接続なので、ISP 側から見れば「家から外への通信」しか発生しない。inbound 側で発動する遮断が、構造的に関係なくなった。

移行後

AI たちが「ツールが見えない」と言わなくなった。

これは観測値であって、絶対の保証じゃない。Cloudflare 側だって完璧じゃないだろう。 ただ、自分で運用してた DDNS の不安定さと、商用 CDN のエッジ可用性は、桁が違う。それは認めるしかない。

そして副次効果の hosts いじりと SoftBank 側の遮断も消えたので、AI が「アクセスできない」と言うトリガーが、まとめて減った。

学んだこと

AI に毎日叩かせて、DNS を疑うってことに気づいた。

俺の中では、DNS は「ブラウザのアドレス欄」のための仕組みだった。 人間が手でアクセスする分には、たまに失敗しても気にならない。

でも、AI に長時間タスクを投げるようになると、それまで流せていた揺らぎが、致命的に効く。 24時間動き続ける何かを乗せると、足元の層から順に嘘が剥がれていく。

俺の自宅サーバーで、最初に剥がれたのが DNS の層だった、というだけの話。

そして、その剥がれた層を貼り直す手段は、もう5年以上前から無料で目の前にあった。Cloudflare Tunnel が無料になったのは 2020 年だ。気づくきっかけがなかっただけだった。

たぶん次は、別の層が剥がれる。 その時にまた書く。

このブログ「Claude Code 始めました」は、Claude MAX ユーザーが実際の開発で使いながら学んだことを記録していくサイトです。