5分で戻ったSSH、13ラウンド疑われた復旧 ── 共有認証情報という「第四の値」

今回の登場人物

Ron（ロン）

AI パートナー / website.usersupports.com プロジェクトリーダー

三鷹企業の支援と業界メディア運営を担当する AI パートナー。SEO・AIO 対策の現場目線と、規律を SKILL として言語化する姿勢を持つ。

担当プロジェクト website.usersupports.com

WEBディレクターのための支援ツール。最新のSEO対策、AIO対策。現場目線のサイト運営をサポートします。

website.usersupports.com →

Glyn（グリン）

AI パートナー / 独立監査デバッグエージェント

Glyn Johns（Rolling Stones・Beatles・Led Zeppelin等を手がけたレコーディングエンジニア）にちなんで名付けられた、ロンの右腕。「ミックスで直すな、ソースで正しく録れ」を核に、実装した本人の報告を鵜呑みにせず物証で照合する。

止まったのは、5分だった

2026年7月13日、website-usersupports 担当のAIパートナー・ロンは、Day3「NOINDEX Phase2 100件完遂ミッション」を4隊のAIエージェント部隊で並列実行していた。作業は順調に進んでいた。16時05分ごろ、それは起きた。

実装隊のひとつ（隊3）が実行したコピーコマンドの宛先指定を誤り、複数の部隊が共有していたSSH秘密鍵ファイル（RSA 2048）に、Pythonスクリプトの実行結果を上書きしてしまったのだ。鍵は破損し、4隊すべてがサーバーへのSSHアクセスを失った。

課題 ── 並列運用の死角は「速さ」ではなく「共有」にあった

AIエージェントを複数部隊に分けて並列で走らせる運用は、処理速度と網羅性の面で大きな武器になる。ロンのチームは以前から「三値の番人」という規律を持っていた。外向きの影響がある処理、取り消せない処理、課金が発生する処理──この3つには特に慎重な確認を課すというルールだ。

だが今回の事故は、この三値のどれにも当てはまらなかった。壊れたのは「複数の部隊がひとつの鍵を共有している」という、運用の土台そのものだった。ファイルへの書き込みという、一見地味な操作が、部隊全体の生命線を断ってしまう。三値の番人が見ていなかった第四の危険地帯──それが「共有の認証情報」だったのだ。

対処 ── 5〜10分で完了した、可逆性を守った復旧

ロンの初動は速かった。事故発生からおよそ5〜10分で、以下の手順を踏んで復旧を完了させている。

まず全4隊をいったん停止し、被害の拡大を止めた。次に、破損した鍵ファイルを削除せず、教訓分析用に別名で退避した。「消さない」という判断が、後の独立監査の物証になる。続いて、冗長性として別途保持していたroot権限の鍵でサーバーへ接続し、新しいキーペア（RSA 2048）を生成。新しい公開鍵は、既存の鍵を残したまま authorized_keys に追記した。ここでも「上書きせず追記する」という可逆性の原則が守られている。最後に新しい秘密鍵を運用パスへ配置し、SSH疎通を確認して復旧完了とした。

復旧後、100件完遂ミッションは無事に完走した。実処理87件、すでに完成扱いだった13件を合わせて100件、4隊すべてがデプロイに成功している。

グリンの目 ── 13ラウンド連続で疑い続けた、その先にあったPASS

ここで登場するのが、ロンの右腕である独立監査エージェント・グリンだ。Glyn Johnsという伝説的エンジニアの「ミックスで直すな、ソースで正しく録れ」という哲学を受け継ぎ、実装した本人の報告を鵜呑みにしないことを役目としている。

グリンはread-only（読み取り専用）の立場で、今回の事故対応についても8点セットの物証照合を実施した。1回目の検証（第22号）では「条件付きPASS」と判定し、確認しきれない点を残した。そして続く第23号の検証で、15観点すべてを確認したうえで「確定PASS」を出している。この積み重ねは、13ラウンド連続で全PASSという型が定着した実績のひとつでもある。疑いを重ねてから初めて信頼が生まれる、という順番がここにある。

検証の過程で、グリンは3つの副次的な発見もしている。ひとつは、事故直前に作られていた旧バックアップが事故の残骸に紛れ込んでいたことで、これは専用ディレクトリへの退避で既に対処済みだ。もうひとつは、各部隊の完了報告が「だいたい80点くらい」といった曖昧な自己申告になっており、実測値と乖離していたこと（たとえば「80点以上4件」という申告に対し実測は2件、「40〜59点30件」という申告に対し実測は48件だった）。これは今後、実測値ベースでの申告を必須とし、曖昧な自己評価表現を禁止するルールとしてSKILLに追記される予定だ。最後に、送信ログの記録経路が未整備で独立検証をしづらい部分があったことも判明し、今後のログ整備が予定されている。

結果 ── 三値の番人が、四値の番人になった

この事故を受けて、ロンのチームは「三値の番人」に第四の値として「共有の認証情報（鍵やパスワードなど）への書き込み」を新たに加えた。具体的には、複数のAIエージェント部隊を並列で動かす際のチェックリストに項目を追加し、各部隊への明示的な禁止事項として「コピーや転送コマンドの宛先パスに鍵ファイルを含めることを禁止」を定めた。さらに、各部隊の作業ディレクトリを専用のサブディレクトリに厳密に限定し、「PEM監視ベースライン」──各部隊が作業着手前と完了時に鍵ファイルのサイズやハッシュ値を検証する運用──を新設している。

グリンはこの一件をこう振り返った。

「87件のマスターテープは並んでいる。ミキサーのVUメーターが誤読していた。針を落として、自分の耳で聴くまではPASSを出さない」

【技術コラム】並列でAIエージェントを動かす人へ ── 明日からできる3つのこと

複数のAIエージェント部隊を並列で走らせる運用は、これからますます増えていくはずだ。今回の事故から得られた教訓を、実践的なアクションとして3つにまとめておく。

1. 共有鍵をエフェメラル化する

長期間同じ認証鍵を複数の部隊で使い回すのではなく、作業単位・部隊単位で短命な鍵を発行し、使い終えたら失効させる運用にする。ひとつの鍵の寿命を短くするほど、誤破損の被害範囲は小さくなる。

2. 1鍵1エージェントの原則

複数の部隊がひとつの認証情報を共有する構造そのものが、今回の事故の根本原因だった。可能な限り、部隊ごとに個別の鍵・個別のアクセス経路を割り当て、ひとつの操作ミスが全部隊を巻き込まない設計にする。

3. 復旧ドリルを事前にやっておく

ロンが5〜10分で復旧できたのは、冗長性として別の鍵を保持していたことと、「消さず退避する」「上書きせず追記する」という可逆性の原則が、事故発生前から手順として身についていたからだ。壊れてから考えるのではなく、壊れる前に「復旧のリハーサル」をしておく。破損時にどの鍵で入るか、新しい鍵をどう配布するかを、平時に一度やっておくだけで初動の速度は大きく変わる。

そもそもSSH鍵とは何か

SSH鍵は「公開鍵暗号方式」という仕組みを使った認証手段だ。手元に置いたままにする「秘密鍵」と、サーバー側に登録する「公開鍵」がペアになっていて、秘密鍵を持っている側だけが正しく認証を通せる。パスワードのように毎回入力する必要がなく、なりすましにも強いため、サーバー運用の現場で広く使われている。今回の事故で壊れたのは、この「秘密鍵」のファイルそのものだった。

authorized_keysへの追記、実際のコマンド

「上書きせず追記する」の実際の操作は、たとえば次のようなコマンドになる。

cat new_key.pub >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

ポイントは2つ。ひとつは「>」ではなく「>>」を使うことだ。「>」は既存の内容を丸ごと消して書き換えてしまうが、「>>」なら既存の行を残したまま末尾に追加できる。もうひとつは、authorized_keysファイルのパーミッションを600（所有者のみ読み書き可）に保つこと。緩すぎるパーミッションは、SSHがそもそも鍵を受け付けなくなる原因にもなる。

共有鍵と1鍵1エージェント、何が違うのか

今回の事故は、まさに「共有鍵運用」の弱点である"誤操作の被害範囲の広さ"がそのまま表面化した形だった。すべてを1鍵1エージェントに変えるのが常に正解とは限らないが、少なくとも「1つの鍵が壊れたら何が止まるか」を運用開始前に把握しておく価値はある。

鍵を"使い捨て"にするという選択肢

長期間同じ鍵を使い続けるのではなく、必要なときだけ短命な鍵を発行して、使い終えたら自動的に失効させる「エフェメラル化」という考え方もある。HashiCorp Vaultのような秘密情報管理ツールには、SSH鍵をその場で動的に発行し、一定時間後に自動失効させる機能がある。クラウド環境であれば、そもそも鍵を配布せずセッション単位でアクセスを許可する仕組み（AWSのSystems Manager Session Managerなど）を使う選択肢もある。鍵を「長く大事に使う資産」ではなく「短く使い切る消耗品」として扱うことで、今回のような誤操作が起きても被害の窓口を小さくできる。

認証情報の事故は、特別なことではない

APIキーやSSH鍵のような認証情報の誤操作・誤流出は、規模の大小を問わずどの開発現場でも起こり得る。多くのセキュリティレポートで、認証情報の管理不備は継続的にインシデントの主要因のひとつとして挙げられている。特別に不注意なチームだけが陥る話ではなく、複数人・複数エージェントが同じ鍵を触る運用をしている限り、いつか誰かの手が滑る前提で設計しておく方が現実的だ。ロンのチームが今回「三値の番人」に第四の値を加えたのは、まさにこの前提に立った判断だった。

まとめ

止まっていたのはわずか5〜10分だった。しかし、その5分の裏側には、消さずに退避された破損鍵、追記され続けたauthorized_keys、そして13ラウンド疑い続けた独立監査エージェントの目があった。速く直すことと、正しく直したと証明することは、別の仕事だ。ロンとグリンの今回の仕事は、その両方を同時に成立させた記録として残る。