AIを制御プローブとして使用し、アラートドキュメントをテストしました
AIが内部ドキュメントのみを使用してアラートを修正するよう制限した実験を行い、3つの重要なギャップを発見しました：アラートと証拠の不一致、ヒストリカルアラートにタイムウィンドウがない、ログから修正への架け橋がない。修正は豊富な証拠を表示し、ドキュメントを同期することでした。この方法はあらゆるインフラに再利用可能です。
私たちは、Glassmkrを実際のハードウェアの多様性に対して検証するために、少数のベアメタルサーバーを運用しています。7台のマシンが4ベンダー、3つのOSファミリーにわたり、2017年から2024年までの世代をカバーしています。時間とともに、これらのマシンはアラートを蓄積します。先週、ダッシュボードには35のアクティブアラートが発生していました。ほとんどはルーチンのドリフトで、小規模オペレーターなら午後に対処するようなものでした：カーネルアップデート保留中、セキュリティパッチ利用可能、自動更新未設定。ダッシュボードは数週間前から何をすべきか教えていましたが、私たちは何もしていませんでした。
私たちはバックログで何か役立つことをすることにしました。自分たちでアラートを修正する代わりに、実験を行いました：コーディングエージェントにすべてのアラートを修正させるが、重要な制約を1つ課すというものです。
制約
エージェントは以下を使用できます：各アラートルールの/docs/alertsページのセクション、アラートのエビデンスJSONのfix_commandsフィールド、自社ドキュメントからリンクされたテキスト、アラートが指すジャーナル出力。使用できないもの：トレーニングデータからの一般的なLinux管理知識、リンクしていないベンダードキュメントのウェブ検索、私たちが提案しない常識的な運用操作。
制約のポイントは、モデルの能力ではなく、ドキュメントをテストすることです。制約がなければ、エージェントはトレーニングデータに頼ってすべてを解決し、ドキュメントについて何も学べません。制約があれば、ガイダンスのギャップがすべて可視化されます。
9台のマシンで35のアクティブアラートに対してこれを実行しました。ルールタイプで重複を排除すると、10の異なるルールタイプになりました：カーネルアップデート、ファイアウォール設定、SSH強化、セキュリティパッチ、自動更新、systemdサービス障害、IPMI SELイベント、インターフェースエラー、SMART障害、カーネル脆弱性。
発見したこと
ほとんどのルールは問題ありませんでした。エージェントはリスクの高い3つのタイプ（修正適用に実際の結果があるもの）に対して解決を試み、他のものはガイダンスの品質をレビューしました。10のルールタイプのうち4つに実用的なギャップはありませんでした。3つはForgeの文書化されたコマンドで簡単に解決できました。残りの3つには、エビデンスの形状またはドキュメントに特定の修正可能なギャップがありました。
これら3つは、それぞれ異なる障害モードを表しているため、詳細に説明する価値があります。
パターン1：アラートとエビデンスの不一致
あるマシンで、smart_failingが重要度クリティカルで発火しました。エージェントがエビデンスを読むと、health: "PASSED"とありました。顧客から見ると、アラートはドライブが故障していると言い、エビデンスはヘルスチェックが合格したと言っています。矛盾を説明する3番目のフィールドはありませんでした。このルールは実際には複数の独立したSMARTしきい値で発火します：再割り当てセクター数がベンダーしきい値を超える、保留セクター数の増加、オフライン修復不能カウント。これらのいずれかがルールを発火させます。エビデンス形状はどの条件が発火したかを単に命名していませんでした。
修正は1行の評価者変更でした：発火したすべての条件を明示的に名前付けするtriggering_signals配列を出力する。修正後、同じマシンでアラートが明確に表示されました："triggering_signals": [{ "attribute": "reallocated_sectors", "observed": 1, "expected": 0 }]。Crucial MX300で1セクターが再マッピングされました。実際の信号、低重要度、即座に判読可能。
パターン2：アラートが履歴で発火
本番services-1ホストで、ipmi_sel_criticalが2024年11月の電源ACイベントで発火しました。イベントはAsserted/Deassertedのペアで、BMCが電源の低下と回復を観測したことを意味します。2026年5月までに、電源は15ヶ月間安定して動作していました。アラートはずっと発火していました。ルールには時間ウィンドウメカニズムがありませんでした。一度クリティカルイベントがシステムイベントログに入ると、ルールは永久に発火し、1年前の一過性イベントでもそうでした。エビデンスはイベントのタイムスタンプを公開していなかったため、ダッシュボードを見ている顧客は、シェルに落ちない限り、インシデントが現在のものか古いものかを知る方法がありませんでした。
修正は2つありました。critical_events[]エビデンス配列の各イベントにタイムスタンプを追加。ルール自体に設定可能な時間ウィンドウ（デフォルト30日、ノイズの多いホストにはサーバーごとのオーバーライドあり）を追加。修正が出荷された後、services-1アラートは次の取り込みサイクルで自動解決しました：1年前のイベントは新しいウィンドウ外になりました。顧客の操作は不要でした。
パターン3：アラートは問題を指すが修正を指さない
3台目のマシンで、systemd_service_failedがfail2banで発火しました。エージェントは私たちの4ステップガイダンスに従いました：ステータス確認、ジャーナル読み取り、再起動試行、再度ステータス確認。最初の3ステップは機能しました。ジャーナルは実際の問題を示しました：Have not found any log file for sshd jail。4番目のステップ（再起動）は、根本的な設定問題が変わっていないため失敗しました。私たちのドキュメントは「設定と依存関係を確認する」という提案で終わっていました。まさにそこが顧客セルフサービスの限界です。ジャーナルは真実を語っていました。私たちはジャーナル出力から修正への橋渡しをする必要がありました。
修正は運用上のもので、ドキュメント上のものではありません：Crucibleを変更し、失敗したユニットの最後の数行のジャーナルをアラートエビデンスに直接含めるようにしました。顧客はSSHしなくても何が失敗したかを見られます。そのマシンのアラートエビデンスは、Have not found any log file for sshd jailエラーをそのまま表示します。修正への橋渡しが短くなりました。
横断的発見
3つのギャップは異なって見えますが、共通の形状を共有しています：それぞれの場合で、ルールがすでにアクセスできるエビデンスは、顧客が見たエビデンスよりも豊富でした。3つのケースすべての修正は、すでに知っていることをより多く表面化することでした。
これが一貫したギャップパターンです。/docs/alertsページは顧客に一般的な用語でアラートの意味を伝えます。エビデンスJSONは、ルールが観測したことを具体的に伝えます。この2つが乖離していました。当社ダッシュボードでアラートエビデンスを読む顧客は、docsページを読む顧客よりも良いガイダンスを得ていました。
また、エージェントがアラートを正常に解決したルールでも、同じパターンのソフトバージョンに気づきました。interface_errorsでは、fix_commandsフィールドにファイアウォールとNICの曖昧さ除去チェックが含まれていますが、/docs/alertsページには記載されていません。ssh_root_passwordでは、fix_commandsフィールドにキーアクセス検証プローブが含まれていますが、docsページには記載されていません。より豊富なガイダンスはアラートペイロード自体に隠れていました。
出荷したもの
同じ週内に、3つの評価者変更とドキュメント監査を出荷しました。エビデンス形状の改善が先に着地しました。なぜなら、レバレッジが高いからです：すべての顧客がアラートを読むときにすぐに利益を得られます。ドキュメント監査パスは後で着地し、/docs/alertsとfix_commandsのパリティギャップを埋めました。各ルールに「アクション可能なステップ」セクションを追加しませんでした。なぜなら、fix_commandsがすでにその目的を果たしているからです。バグは/docs/alertsがそれを反映していなかったことです。
方法論、別途
この実験を成功させた制約は、取り出して強調する価値があります。制約がなければ、実験はLLMの一般的なLinux能力を測定することになり、それは「ほとんどのことで十分高い」という答えになるため興味深くありません。制約があれば、実験は私たち自身のガイダンスがセルフサービスに十分完全かどうかを測定し、それは顧客にとって重要なまさにその質問です。
自分のインフラで同様の演習を実行する人は誰でも同じ制約を採用すべきです。エージェントがそのドメインのトレーニングデータを使用することを禁止します。製品の文書化されたガイダンスのみを使用するよう強制します。各失敗点は、実際の顧客も直面するギャップです。AIを通じて実行する利点はスピードです：実験は約1時間の壁時計時間を要しました。自社製品を使用する利点は正直さです：表面化されたすべてのギャップは現実のものです。
ツールに関する注意：この実験には外部コーディングエージェント（Claude Code）を使用しました。なぜなら、トレーニングデータの使用禁止を外部エージェントに対して強制する方が、自社の本番デプロイメントに対してよりも簡単だからです。実験は検証クラスターで実行され、顧客インフラではありません。Glassmkrアカウントからの顧客テレメトリーは、アムステルダムの専用L4 GPUで実行されるGemma 4 26Bによって引き続き分析され、Glassmkrスタックを離れることはありません。
私たちは1ヶ月後に再びこれを行います。残っている作業リストは空になっていません。