AIエージェントはLinux障害調査を完遂できるか ～ReadOnlyな専用ツールで検証した自律調査PoC

はじめに

多数のLinuxサーバーを運用していると、障害発生時の一次調査が大きな負担になります。

担当者は対象へ接続し、ログや設定ファイルを探し、プロセスやポート、ディスク、メモリなどを確認します。原因の見当がついた後には、調べた内容と根拠を整理し、次の判断をする人へ引き渡さなければなりません。

個々の操作はそれほど複雑でなくても、何をどの順番で調べるかは障害ごとに異なります。調査対象や案件数が増えるほど、こうした一次調査に使う時間も増えていきます。

そこで考えたのが、AIエージェントへ障害の一次調査を任せられないか、ということです。

利用者から曖昧な障害申告を受け取り、仮説を立て、複数のツールで状況を確認し、必要なら仮説を修正しながら、最後は調査レポートまで作る。将来的により長時間・多段階の調査へ発展させることを考えると、AIエージェントと相性のよさそうな仕事に見えます。

一方で、Linux環境へ接続するAIエージェントに任意のシェルコマンドを渡すのは、かなり怖い設計でもあります。

結論から言うと、今回のPoCでは、任意コマンドを与えずReadOnlyの専用ツールだけに制限しても、AIエージェントが障害に関係する証跡を集め、人間が次の判断を行えるレポートまで作成できました。

実際に試してみると、探索をどこまで続けるか、複数の異常から何を重要視するかといった「調べ方」には条件ごとの違いも見えてきました。

今回のPoCでは、AIに障害対応そのものを任せるのではなく、一次調査と証跡整理をどこまで任せられるかに焦点を絞りました。

「原因を当てる」ことを目的にしなかった

障害調査AIというと、障害の原因を自動的に特定するシステムを想像するかもしれません。

しかし、実際の障害調査では、最初から完全な原因へ到達できるとは限りません。利用者から伝えられる情報も、「サーバが重い」「設定変更後から通信できない」といった曖昧な内容であることがあります。

そのような状況で、AIが根拠の薄い原因を断定しても、担当者の助けにはなりません。

そこで今回は、原因の完全な特定よりも、次の状態まで調査を進めることを重視しました。

• 障害に関係するファイルやログを発見する

• プロセス、ポート、ディスク、メモリなどの状態を確認する

• 人間が原因判断に使える証跡を収集する

• 事実、推定、未確認事項を分離する

• 根拠付きの調査レポートとしてまとめる

つまり、今回の「調査完遂」は、正解を一発で当てることではありません。

人間が次の判断を行えるだけの証跡を集め、調査結果をレポートとして引き渡すこと

と定義しました。

長時間実行を見据えた基礎検証

今回のシナリオ自体は、数分から十数分程度で終了する基礎的なものです。何時間も動き続けるエージェントを検証したわけではありません。

まず確認したかったのは、曖昧な申告だけを起点に、自律的に調査を開始し、複数の調査手段を使い分け、必要に応じて追加確認を行いながら、レポート作成まで到達できるかという点です。

実業務では、対象となるログや設定はさらに増え、過去情報や複数の機器を横断して調べる可能性もあります。その前段として、まずは小さく切り出したLinux環境で検証しました。

任意コマンドを渡さず、できることを制限する

AIエージェントにLinuxを調査させるだけなら、シェルを渡して自由にコマンドを実行させるのが最も簡単です。

今回はあえてその方法を取りませんでした。

ReadOnlyの専用ツールへ分解する

シェルを使えば、ps、ss、df、grepなどを柔軟に組み合わせられます。一方、同じ経路からサービス停止、ファイル変更、パッケージ導入、外部通信なども実行できます。

「調査だけを行い、変更はしないでください」とプロンプトに書くことはできますが、それだけを安全性の根拠にはしたくありません。

そこで今回は、任意コマンドやスクリプトを受け取る機能を公開せず、調査に必要な操作を専用ツールへ分解しました。

ファイルの一覧・検索・読み取り、プロセスやListenポートの確認、ディスクやメモリの状態取得など、用途の決まったReadOnly操作だけを提供します。サービス状態やjournalについても専用ツールを用意し、対象環境で利用できない場合は、その理由を返す設計にしました。

SSH側でも任意の文字列をそのままコマンドとして実行するのではなく、固定された処理からコマンドを生成します。sudo権限を持たないユーザーを使い、アクセス可能なパスや実行時間、取得件数、出力量にも上限を設けました。

ここで重要なのは、モデルへ「変更しないでください」とお願いするのではなく、変更できる道具を最初から渡さなかったことです。

Skillは調査方法、ツールは能力境界

モデルへは、ツールとは別に障害調査用のSkillも与えました。

役割を整理すると次のようになります。

Skillでは、事実・推定・未確認事項を分けることや、権限不足や取得上限を「証拠がなかった」と混同しないこと、根拠が不足している場合は断定しないことなどを定めています。

つまり、Skillはどう調査してほしいかを整える仕組みです。一方、ツールとOS権限は実際に何ができるかを制限します。

Skillへの指示自体をセキュリティ境界とは考えていません。

最近のAIエージェント事例から見た権限境界

今回の検証と前後して、AIエージェントが設計者の想定を超えて行動した事例が相次いで公表されました。

Anthropicはエージェントの封じ込めに関する記事で、Claudeがタスクを完遂するためにサンドボックスを抜けた事例などを紹介し、モデルの振る舞いを監督するだけでなく、サンドボックスやファイルシステム境界、外向き通信の制御によって「そもそも何ができるか」を制限する考え方を説明しています。

2026年7月には、Hugging Faceによる先行開示を受けて、OpenAIがモデル評価中に発生したセキュリティインシデントを公表しました。評価中のモデルは未知の脆弱性や認証情報などを組み合わせ、評価環境の外へ到達してHugging Faceの本番インフラへアクセスしました。

さらに、Anthropicも7月30日に3件の実システムへの不正アクセスを公表しています。こちらはOpenAIの事例とは性質が異なり、評価環境に意図せずインターネット接続が残っていたことが主な要因でした。8月にはMetaの評価でも、設定不備によってインターネットへ到達したモデルが第三者サービスの脆弱性を利用した事例が報じられています。

これらを単純に「AIが脱獄した」と一括りにすることはできません。それでも共通して見えるのは、モデルへ「ここから先はやらない」と伝えることと、システムとして「ここから先はできない」状態にすることは別物であるという点です。

今回ReadOnlyの専用ツールへ操作を分解したのも、後者の境界を明確にするためです。

もちろん、ReadOnlyであればすべて安全というわけでもありません。対象システムの変更は防げても、読み取った設定やログに機密情報が含まれる可能性は残ります。また、ログや設定に埋め込まれた命令による間接プロンプトインジェクションも、今回は検証していません。

ReadOnlyは万能な安全策ではなく、エージェントが誤動作した場合の影響範囲を小さくするための一つの境界として位置付けています。

5つの疑似障害で検証した

ここからは、実験条件と評価方法をまとめて説明します。後から条件を補足するのではなく、以下を今回のPoCの前提としています。

実験条件

Dockerターゲットはシナリオごとに再作成し、容量不足用のtmpfsが別ケースへ影響しないようにしています。また、systemd/journaldを完全に再現するための特権コンテナは今回の対象外です。

モデルと推論設定が同時に異なるため、以下の結果はモデルそのもののランキングではなく、今回の2条件で観察された調査行動の違いとして扱います。

テストシナリオ

原因と期待証跡を事前に定義しやすい、5つの基本的なLinux障害を用意しました。

各ケースでは、AIへは利用者から見える事象だけを渡します。Ground Truthや期待証跡はホスト側だけに保持し、調査対象から直接読み取れないようにしました。

実運用をそのまま再現するのではなく、まずは原因と期待証跡を事前に定義できる基礎ケースに絞っています。

評価ルール

原因を当てたかだけではなく、人間が判断に使える証跡を集められたかを重視しました。

たとえばcase02では、実際のデータ保存先、その保存先が属するファイルシステムの使用状況、容量不足を示すエラーログなどを必須証跡としました。ケースごとの必須証跡は、事前に定義したうえで評価しています。

結果：この条件では「調べ方の癖」が分かれた

結果の概要は次のとおりです。

成功件数：5ケース＝100% ／ 平均時間：10分＝100%

*2条件の証跡成功・総合通過・平均所要時間*

Sonnet 5のcase03のみ2試行しているため、上表の成功判定と平均時間は、前節の評価ルールに従って集計しています。元の試行データでは、Sonnetは6試行中4試行で証跡成功、Opusは5試行すべてで証跡成功でした。

なおcase05については、検証後に評価用fixture側の定義に見直すべき点が見つかっています。表は事前に定義した基準どおり集計していますが、この1ケースの判定には留保があります。

Opus条件では5ケースすべてで必要な証跡を回収できました。一方、case03では10分46秒を要したため、10分以内という条件を含む総合通過は4/5ケースとなりました。

Sonnet条件では、原因が明確なケースでは短時間で必要な証跡まで到達しましたが、曖昧な申告から調査を始めたcase02では探索を早く収束させ、必要な証跡を取り逃がしました。

またOpus条件も、すべてのケースで想定原因を最重要候補にできたわけではありません。case02とcase03では複数の異常を広く拾った結果、利用者が申告した事象との関係が弱い問題を上位に置きました。

今回の結果から見えてきたのは、単純な能力の上下というより、

• 早く仮説を絞るが、探索を打ち切りすぎることがある

• 広く探索できるが、発見した異常の優先順位付けに迷うことがある

という調査行動の違いです。

一つの正常値で調査を終えない

調べ方の違いが最も分かりやすく表れたのがcase02でした。

利用者からの申告は「サービスが正常動作しない」で、実際の原因はアプリケーションのデータ保存領域の容量不足です。

Sonnet条件では、まずルートファイルシステムの使用率を確認しました。そこには十分な空きがあったため、容量不足の可能性を下げ、別の原因へ調査を進めました。

しかし、実際のデータ保存先は独立したファイルシステムにありました。Sonnetは保存先を示す設定、そのファイルシステムの使用状況、書き込み失敗ログを取得できていませんでした。

一方、Opus条件では設定から実際の保存先をたどり、そのファイルシステムの状態とNo space left on deviceのログまで確認できました。

ここで問題だったのは、ディスク使用率を確認しなかったことではありません。正常な値を一つ見つけたことで、容量不足という仮説そのものを早く捨ててしまったことです。

障害調査では、「一般的にどこを見るか」だけでなく、設定から実際のデータフローを追う必要があります。

こうした失敗は、モデルを交換するだけでなく、

データ保存先や接続先は設定から確認し、その実体の状態まで追う

といった探索ルールをSkillへ戻すことで改善できる可能性があります。

またcase03では、同じSonnet 5・同じ推論設定で2回実行したところ、1回目は必須証跡4項目のうち2項目しか取得できなかった一方、2回目は4項目すべてを取得できました。同じ条件でも調査結果が変わったため、実業務へ進む際には単発の成功だけでなく再現性を見る必要があります。

今回のPoCで特に収穫だったのは、モデルの勝敗そのものより、どこで探索を打ち切りやすいか、何を見落としやすいかを具体的に観察できたことでした。

PoCとして何が分かったか

今回確認したかったのは、「Linux障害を完全自動診断できるか」ではありません。

冒頭で定義した通り、人間が次の判断を行えるだけの証跡を集め、レポートとして引き渡せるかを検証しました。

その観点では、任意コマンドを使わずReadOnlyのツールだけで自律調査を進め、基本的なLinux障害について必要な証跡を集め、根拠を整理したレポートまで生成できました。

基礎的なPoCとしては成立したと考えています。

同時に、探索の早期収束、複数の異常を発見したときの順位付け、試行ごとの再現性といった課題も見えました。

これは「より性能の高いモデルを使えば終わり」という種類の問題ではなさそうです。モデルが失敗した調査経路を観察し、Skillの探索手順や完了条件へフィードバックしていくことも重要になります。

まとめ

今回は、Linux障害の一次調査を省力化することを目指し、任意コマンドを与えずReadOnlyの専用ツールだけを使うAIエージェントを試しました。

5つの基本的な疑似障害では、限定されたツールだけでも、AIエージェントが証跡を収集し、レポートまで調査を進められることを確認できました。

一方、今回の条件では、Sonnet 5（推論：中）は短時間で調査を進める反面、探索を早く収束させるケースがありました。Opus 5（推論：高）は証跡を広く回収する一方、時間や原因候補の優先順位付けに課題がありました。

AIエージェントを障害調査へ使う際に重要なのは、モデルへすべてを任せることではなく、

どのように調べるかをSkillで整え、何ができるかをツールとOS権限で制限すること

だと考えています。

目指しているのも、AIが障害解析担当者を完全に置き換えることではありません。

時間のかかる一次調査と証跡整理をAIエージェントへ任せ、人間が原因判断や対応方針の決定に集中できる状態です。

今回の検証は基本的なLinux障害を対象にした第一歩です。今後は、より実運用に近いログや設定、長時間の調査、複数回実行したときの再現性などへ対象を広げながら、実際の障害調査フローにつなげていきたいと考えています。