目次
  1. はじめに：納品前夜、VPNが落ちた
  2. 当社の「デジタル従業員」体制
  3. 手元のDEがやったこと：PC側の切り分け
  4. 社内のDEがやったこと：ルータ側の調査
  5. 原因：切れた接続の「幽霊」が席を塞いでいた
  6. 復旧と再発防止
  7. 学び：任せてよかったこと、人が判断したこと
  8. よくある質問（FAQ）
  9. まとめ
本記事について

本記事は、当社の代表が出張中に遭遇した社内VPN障害を、社内のAIエージェント（デジタル従業員）だけで復旧した実際の記録です。時刻・エラーコード・コマンドは実際のものですが、ネットワークアドレスや機器の識別情報は伏せ、納品先の案件名も記載していません。

はじめに：納品前夜、VPNが落ちた

関東への出張中、翌日の納品に向けて社内サーバーへ遠隔で作業するつもりでした。ところが夜、ホテルからWindows標準のVPN（L2TP/IPsec）に接続するとエラー789。数分前までは繋がっていたのに、再試行しても65秒待たされて同じエラーです。社内には誰もいません。VPNが復旧しなければ、納品物の最終確認とデプロイができず、納品そのものが翌日に間に合わない状況でした。

同じ症状は3日前にも起きていて、そのときはPC側のネットワークスタックを再起動して直りました。今回も同じだろうと思って手元のAIエージェントに「また前と同じでVPNに繋がらない」とだけ伝えたのですが、結果的に原因はまったく別の場所にありました。ここからの約2時間半、人間がやったのは判断と承認だけです。調査・切り分け・社内側の操作・記録は、すべて2体のデジタル従業員が行いました。

当社の「デジタル従業員」体制

当社では、人の指示を受けてツールを自分で操作し、結果を読んで次の手を決めるAIエージェントをデジタル従業員（DE）と呼んでいます。今回動いたのは次の2体です。

デジタル従業員どこで動くか今回の役割
手元のDE（Claude Code）出張先のノートPCPC側の切り分け、パケット観測、回線を変えた再現試験、社内DEへの依頼文の作成、作業ログの記録
社内のDE（OpenClaw）社内サーバーに常駐。Slackから指示を受ける社内ルータへログインし、状態の参照、ログの照合、承認後のセッション削除と設定変更

ポイントは、手元のDEは社内ルータに触れないことです。ルータの認証情報は社内側にしか置いておらず、手元のDEがそれを取りに行こうとした操作は、実行環境のセキュリティポリシーで自動的に止まりました。代わりに手元のDEは「社内のDEに何を調べてもらうか」を文章にまとめ、人がそれをSlackに貼る、という運用になりました。人が伝書鳩になるのは少し不格好ですが、権限の境界がそのまま安全装置として働いた形です。

手元のDEがやったこと：PC側の切り分け

ロボットが虫眼鏡で、ノートPCからルータへ流れる光の粒を観察しているが、ルータからは何も返ってこないイメージイラスト

手元のDEはまず、自分のメモ（Obsidianの作業ログ）から3日前の障害記録を読み、そのときの復旧手順——ネットワークアダプタの再起動とIPsecサービスの再起動——をそのまま再現しました。管理者権限が必要な操作はUAC（昇格）のダイアログを出してこちらの承認を待つ形です。しかし結果は変わらず789。ここで「前と同じ」という思い込みを捨てて、切り分けに入りました。

  • パケットが出ているかを見る——Windows標準の pktmon でUDP 500番（IKE）をキャプチャ。PCはIKEの最初のパケットを28回送出していて、ルータからの応答は0でした。3日前は「1パケットも出ていない」PC側障害だったので、今回は明確に別物です。
  • 回線を変えて再現する——ホテルのWi‑Fi、PC内蔵のLTE、そして接続実績のあるiPhoneのテザリングの3回線で試し、すべて同じ結果。「特定回線の制限」ではないと判断できました。
  • 相手が生きているかを見る——VPNサーバーのアドレスにpingとTCP接続は通り、社内のRedmineも外から表示できる。つまり社内のインターネット回線とルータ本体は正常で、IKEにだけ応答がない状態です。

正直に書くと、ここで手元のDEは一度誤診しています。社内NASに外から入れたので、そのNASのVPNサーバー機能が止まっているのを見つけ、「これが原因」と報告してきました。実際にはVPNを終端しているのはルータで、NASの機能は使っていません。人がひと言「VPNはNASではなくルータ」と訂正すると、DEは記録を訂正し、以後の調査対象をルータに切り替えました。AIの結論をそのまま信じない、でも訂正すれば即座に方向転換する——このやり取りが今回の復旧の分岐点でした。

社内のDEがやったこと：ルータ側の調査

ホテルのノートPCの前のロボットと、オフィスのルータの横に立つロボットが、光の橋の上で手紙を受け渡しているイメージイラスト

社内のDEは、Slackで依頼を受けるとルータにログインし、参照コマンドだけで状態を報告してきます。最初の報告は「ルータは稼働中、別拠点の常時接続は正常、直近ログに認証失敗なし、設定変更なし。接続元端末側を疑う」というものでした。これは間違いではありませんが、手元のDEの観測（IKEは送っているのに無応答）と噛み合いません。

そこで手元のDEが依頼文を組み立て直しました。「接続を試した正確な時刻と接続元アドレスを渡すので、その時刻のログを見てほしい」「IPsec SAの一覧を貼ってほしい」「設定上のトンネル数と、切断検知（DPD）の有無を確認してほしい」。社内のDEはこれに番号付きで答え、途中で自分の前の結論を「断定できないため訂正します」と撤回しました。決定打になったのは次の3つの報告です。

  • 接続の実績が残っていた——障害の直前、出張先のPCはいったん接続に成功し、2分後に「L2TPキープアライブ失敗」で切れていた。PC側のログも同時刻に「リンク断」を記録しており、内蔵LTEのアドレスが変わったタイミングと一致しました。
  • 古いSAが2つ残っていた——IPsec SAの一覧に、切れた接続のアドレス（今日のPCの古いLTEアドレス2つ）を相手とするISAKMP SAだけが残っていた。残り寿命の値から逆算すると、生成時刻は切れた接続そのものでした。
  • 切断検知が無効だった——ルータのIKEキープアライブ（DPD）は全ポリシーで無効。相手が消えてもSAが寿命（8時間）まで残る設定でした。

原因：切れた接続の「幽霊」が席を塞いでいた

3つの扉があるルータの建物で、2つの扉を半透明の幽霊が塞ぎ、1つを小さな機器が使っていて、新しく来たロボットが外で待たされているイメージイラスト

当社のルータ（ヤマハRTXシリーズ）は、接続元を限定しない匿名のL2TP/IPsec接続を、IKEポリシー単位で受け付けています。この方式では1つのポリシーが同時に相手にできるのは1接続です。ポリシーは4つありますが、1つはL2TPを持たないIPsec専用のため、リモート接続に使えるのは実質3つでした。

IKEポリシー障害時の状態相手
1IPsec専用（L2TPなし）リモート接続には使えない
2ISAKMP SAのみ残留切れた接続A（出張先PCの古いアドレス）
3正常に接続中別拠点の常時接続機器
4ISAKMP SAのみ残留切れた接続B（出張先PCの古いアドレス）

つまり、出張先のPC自身が過去2回の接続で残した「幽霊」が、使える3席のうち2席を塞いでいたのです。残る1席は別拠点の機器が正しく使っています。この状態で新しいアドレスから接続に来ると、ルータには空き席がないため応答せず、しかもログにも残りません。手元のDEが観測した「送っているのに無応答」と、社内のDEが観測した「記録がない」は、どちらも正しい観測でした。

3日前の障害でPC側の再起動が効いたように見えたのも、今にして思えば、SAの寿命が切れたタイミングと重なっただけだった可能性があります。症状が同じでも原因が同じとは限らない——書けば当たり前ですが、深夜に納品を控えていると人はこの当たり前を飛ばしがちです。今回は、飛ばさなかったのがDEでした。

復旧と再発防止

原因が確定した時点で、手元のDEは「残留している2つのSAを削除する。別拠点のSAには触らない。これは本番ルータの状態を変える操作なので承認がほしい」と報告してきました。承認して社内のDEに依頼し、管理者モードでipsec sa deleteを2回。直後の一覧に残り寿命3秒のSAが一瞬見えて「再生成された」と社内DEが報告しましたが、手元のDEが「消えかけの表示」と判断して再接続を試み、IKEとIPsecが2秒で成立。その後、保存済みの資格情報で接続し、社内のルータ・NAS・検証サーバーへのpingが通ることを確認しました。障害発生が19:18、復旧が21:46です。

再発防止として、同じタイミングでルータのIKEキープアライブ（DPD）をL2TPを持つ3ポリシーで有効にし、保存しました。これで相手が消えたSAはルータが自動的に検知して削除するので、内蔵LTEのアドレスが変わっても8時間待つ必要はなくなります。こちらも設定変更のため、承認後に社内のDEが実行しました。

  • 即時対処——自分の古いアドレスのISAKMP SAだけを削除。他拠点の接続には触らない
  • 恒久対策——ipsec ike keepalive use N on dpd を有効化して保存
  • 運用上の学び——同じ症状が出たら、PC側の再起動より先にパケット観測とルータ側のSA一覧を見る。手順は社内ナレッジに記録済み

学び：任せてよかったこと、人が判断したこと

今回、人が行ったのは「VPNが繋がらない」と伝えること、誤診を1回訂正すること、2体のDEの報告をSlackとPCの間で貼り合うこと、そして本番機器の変更を承認することだけです。その間、2体のDEが担った作業は次のとおりです。

  • 過去の記録を自分で読む——3日前の障害記録を作業ログから探し、同じ手順を再現した。人が「前回どうやったっけ」と思い出す時間がゼロ
  • 観測して仮説を捨てる——パケットキャプチャ、3回線の再現試験、到達性確認を自分で組み立て、「回線側」「PC側」「NAS側」の仮説を順に潰した
  • 相手のDEへの依頼文を書く——「何時何分にどのアドレスから試したか」を添えて依頼したことで、社内側の調査が一発で当たった
  • 境界を越えない——ルータの認証情報を取りに行く操作はポリシーで止まり、状態を変える操作は承認を待った
  • 記録を残す——作業ログ、トラブルシューティング集、自分用のメモまで、復旧と同時に更新されている

一方で限界もはっきりしました。手元のDEは一度NASを疑って誤診しましたし、社内のDEも最初は「端末側の問題」と結論づけました。どちらのDEも単独では正解に辿り着いていません。正解に辿り着いたのは、観測が噛み合わないときに片方がもう片方へ具体的な追加質問を投げ、人がその往復を仲介したからです。AIに任せる範囲を広げるほど、人の仕事は「手を動かすこと」から「観測の矛盾に気づいて問い直すこと」へ移る、というのが今回の実感です。

よくある質問（FAQ）

Q. デジタル従業員（DE）とは何ですか？
A. 人の指示を受けて、ツールやシステムを自分で操作しながら調査・作業を進めるAIエージェントを、当社ではデジタル従業員と呼んでいます。今回は、出張先のPCで動くClaude Codeと、社内サーバーに常駐してSlackから指示を受けるOpenClawの2体が役割分担しました。チャットで答えるだけでなく、コマンドを実行し、結果を読んで次の手を決める点が従来のチャットボットとの違いです。
Q. AIにネットワーク機器の操作を任せて安全なのですか？
A. 当社では、参照コマンドは自律実行、状態を変える操作は人の承認後という線引きをしています。今回もルータ上のセッション削除と設定変更は、原因と影響範囲を報告したうえで承認を得てから実行しました。さらに、AIが認証情報を探索しようとした操作は実行環境のポリシーで自動的に止まり、代わりに社内側の別エージェントへ依頼する形に切り替わりました。
Q. 同じ障害は自社のVPNでも起こりますか？
A. 接続元を限定しない匿名L2TP/IPsecを受け付けるルータで、切断検知（DPD）が無効になっていれば起こりえます。直前まで接続できていたのに突然エラー789になり、回線を変えても同じ、というのが典型的な症状です。ルータ側でIPsec SAの一覧を見て、自分の古いIPアドレスのISAKMP SAが残っていれば、この記事と同じ原因です。

まとめ

出張先で発生した社内VPNの障害を、手元のClaude Codeと社内常駐のOpenClawという2体のデジタル従業員だけで、発生から約2時間半で復旧しました。原因はPCでも回線でもなく、切れた接続がルータに残した2つのISAKMP SAが匿名接続の枠を塞いでいたことで、削除とDPD有効化で解決しています。人が手を動かした作業はゼロ、判断と承認が4回です。翌日の納品は予定どおり完了しました。

持ち帰っていただきたいのは、AIエージェントの価値が「自動でやってくれる」ことではなく、観測に基づいて仮説を捨て続けられること、そして権限の境界を守ったまま別のエージェントへ仕事を渡せることにある、という点です。当社は、こうした社内運用で磨いたデジタル従業員の設計を、お客様の業務システムやインフラ運用にも展開しています。「まず社内のこの作業を任せられないか」という段階のご相談も歓迎です。