粘り強い調査は Fable に任せる──対策が空振りしても、AIは引き下がらなかった

2026年7月30日 2026年7月28日

blueleaf

先日、仕事にならないレベルで困ったことがありました。取引先の社内ネットワークにVPNで接続すると、Claude（AI）が動かなくなるというものです。

しかも厄介なのが、いつも壊れるわけではない。同じVPNを繋いでいても、普通に動くときがある。動かないときもある。この「たまに動く」が曲者で、自分では何が違うのかまったく分かりませんでした。

この件は、Claude Code のモデルを Fable に切り替えて相談し、解決しました。原因の特定までは9分。ただ、本当に助かったのはそこではなく、一度出した対策が空振りしたあとでした。粘り強い調査が必要な場面で相手を選ぶと、こんなに違うのか、という話を書きます。

「たまに動く」が、いちばん厄介

不具合には2種類あります。「いつも壊れる」と「たまに壊れる」です。

前者は楽です。再現するので、原因を1つずつ潰していけばいい。困るのは後者で、こうなります。

直したつもりでも、動いたのがたまたまなのか、直ったのか区別がつかない
「さっきは動いたのに」と思って、原因のあたりを付け間違える
検索しても、症状がぼんやりしすぎて引っかからない

今回もまさにこれでした。VPNをオンにしている状態でAIが正常に動いた記憶があるので、「VPNが原因」という仮説すら自信を持てない。ネットワークまわりは自分の専門でもないので、調べ始めるにも取っかかりがありませんでした。

相談相手に Fable を選んだ

先に、モデルの話を少しだけ。

Claude Code は用途に応じてモデルを選べるようになっていて、Fable はその中でも、長く考えて筋道を追うのが得意なタイプです。日々の作業をテンポよく回すのとは別に、「答えが分からない状態から、実測して、外して、調べ直す」種類の仕事があります。今回はまさにそれだと思ったので、最初にモデルを切り替えてから相談を始めました。

結果的に、この判断がいちばん効きました。理由は後半に書きます。

AIに渡したのは、症状だけ

伝えたのは、困っている内容をそのまま話しただけです。専門用語で整理したりはしていません。

VPNを繋いでいると、AIのAPIが繋がらず失敗するようです。同じVPNをオンにしているときに問題なく繋がっているときもあって、その違いが分かりません。なんとか直したいので、原因を調査できますか。

ここで「たまに動くこともある」と正直に伝えたのが、あとから効きました。あいまいな情報は隠したくなりますが、切り分けの材料としては、あいまいな症状そのものが手がかりになります。

9分で、現行犯を押さえた

Fable がやったのは、推測ではなく実測でした。

まずパソコンのネットワークの状態を一通り採取します。VPNの接続状況、通信の経路、名前解決（ドメイン名をサーバーの住所に変換する仕組み）の設定、そして実際にAIのサーバーへ繋がるかどうか。それを1つずつ実行して、数字で記録していきました。

決定的だったのは、調査中にちょうどVPNが切断されたことです。接続ログの時刻を拾って、壊れている状態と直っている状態の両方を、同じテストで実測しました。

状態	実測結果
VPN接続中	AIのサーバーの住所が引けない（応答なし）
VPN切断後（同じテスト）	住所解決5ミリ秒、通信0.2秒で正常

ここまで9分。原因はこうでした。

取引先のVPNサーバーが、繋いだパソコンに対して「これから全部の通信をVPN経由にしろ」「住所の問い合わせ先は社内のサーバーを使え」と指示を出していた。ところが、その社内の問い合わせ先がこちらのMacからは応答しない。結果、新しく接続しようとするものは軒並み住所が分からず、AIも繋がらない、と。

そして「たまに動く」のカラクリも同時に説明がつきました。すでに繋がっている通信は、住所を引き直す必要がないので生き残るのです。だから、VPNを繋ぐ前から起動していたAIのセッションはそのまま動き続ける。新しく起動したときだけ失敗する。「タイミング次第で動いたり動かなかったり」に見えていた正体はこれでした。

自分ひとりでは、たどり着けなかったところです。

そして、対策が空振りした

原因が分かれば話は早い、と思いました。

提案は「VPNに通す通信を、必要な社内の宛先だけに絞る」というもの。VPN設定ファイルに数行足すだけで、その場で修正版を作ってくれました。私はそれをアプリに読み込ませて、接続。

ところが。

あっなんか、APIエラーになったから、VPNを止めたよ。

直っていませんでした。設定ファイルには確かに書いてあるのに、まったく効いていない。

正直、ここで心が折れかけました。原因が分かって対策も打ったのに変わらない、というのがいちばん萎えるパターンです。

Fable が引かなかったところ

私はその一言を投げただけで、あとは別の作業に戻りました。その間に Fable がやっていたのが、「なぜ効かなかったのか」の裏取りです。

戻ってきた答えが、こうでした。

設定が無視されるのは、そのVPNアプリの既知の制限だった。私が使っていたアプリは、内部が別実装になっていて、この設定項目そのものに対応していない。設定ファイルに書けはするが、実行時には読み飛ばされる。開発元自身が公式フォーラムで「この設定を使いたいなら、フル機能版のクライアントを使ってください」と回答していた（出典URL付き）
なぜ他社のVPNでは同じ問題が起きないのかも、ついでに判明した。別の取引先のVPNを調べたところ、そちらはサーバー側で最初から「必要な通信だけ」に設定されていた。つまり、こちらが使っているアプリの良し悪しではなく、VPNサーバー側が何を指示してくるかの差だった

そのうえで、選択肢を3つ出してきました。

A：VPNアプリを、この設定が効く別のもの（無料）に乗り換える — 開発元が案内している方法と同じ路線
B：取引先の管理者に、サーバー側の設定変更を依頼する — 根本解決だが、他社インフラなので時間がかかる／通らない可能性もある
C：接続のたびに修正を手で当てる — 動くが毎回ひと手間

推しはAでした。私は「Aで進めましょう」と返しただけです。

ここが今回、いちばん良かったところだと思っています。「対策を打ったが効かなかった」で終わらず、効かない理由を仕様のレベルまで確認して、道具そのものを替える提案に切り替えた。しかも「他社では起きない理由」まで押さえているので、提案を信用して判断できました。

空振りしたあとに、その場しのぎの別案をすぐ出すのではなく、いったん仕様の確認に回る。ここが、モデルを選んだ効果がいちばん出た場面だったと感じています。

直ったあと、勝手に再発防止までやっていた

新しいアプリのインストールと接続は私がやり（VPNの導入は画面上の操作が必要なので、ここは人の仕事です）、「繋いでみた」と伝えると、検証を一式回して確認してくれました。

社内の共有フォルダに繋がるか
社内の業務画面に繋がるか
通常のインターネットとAIのAPIが、VPNの影響を受けていないか
秘密鍵の入った設定ファイルがデスクトップに置きっぱなしになっていないか（→削除済み）

全部OK。ここまでで私が打ったメッセージは、最初の相談から数えて7通でした。

そのうえで Fable は、この件を今後の自分のために書き残していました。

何が起きて、どう直したかの記録（原因・選んだ手段・VPNに通す宛先の内訳・してはいけない繋ぎ方とその理由）
プロジェクトの共通ルールに1行：「このVPNは新しいアプリの側から繋ぐこと」
関連する作業手順書3か所を書き換え：この取引先の月次作業や共有フォルダを開く手順に、「VPNに接続してください」とだけ書いてあった箇所を、「どのアプリのどの設定で繋ぐか」まで具体化

つまり、次に別のセッションのAIが同じ作業をするとき、間違ったアプリで繋いで同じ地雷を踏むことがなくなったわけです。直して終わりではなく、二度と起きないところまでが1セットになっていました。

ここは指示していません。人間だと、疲れて直った時点で満足してしまうところです。

人がやったこと／AIがやったこと

今回の役割分担を整理すると、こうなります。

	内容
人	症状を伝える（あいまいなまま）／VPNの用途を伝える／アプリのインストールと接続操作／「効かなかった」の報告／方針の決定
AI（Fable）	ネットワーク状態の実測／壊れた状態と直った状態の比較／原因の特定／対策の作成／効かない理由の仕様確認／代替案の提示／直ったことの検証／記録と手順書の更新