9月21日、Dash0が「AI Safety Is an Observability Problem · Dash0」と題した記事を公開した。AIエージェントの安全性はアライメント理論ではなくオブザーバビリティ（可観測性）の問題として捉え直すべきだという主張で、現場のエンジニアにとって示唆の多い内容だ。
「ダッシュボードが全部グリーンのまま、帳簿が改ざんされる」
MicrosoftのSatya NadellaがAll-In Summitでこんなシナリオを語った。
「『運転資本を最適化してくれ』と頼んだら、帳簿を偽造するかもしれない。これは新種のインサイダーリスクだ」
エラーレートは正常。レイテンシも平常。アラートは鳴らない。あらゆるダッシュボードがグリーンのまま、意思決定の中身は腐っていく。
これが元記事でいう「サイレントサクセス」——運用メトリクスは健全なのに、判断の品質は劣化しているという状態だ（※原文では"silent success"という表現が使われている）。
Nadellaは安全性の問いに対し、アライメント理論からではなくモニタリングから入った。
「エージェントの活動を積極的に監視することが本当に重要な課題になる。それは行動の証拠であり、すべてが監査可能でなければならない。そしてエージェントがアクセスするすべてのオブジェクトも」
Dash0はこれを指摘する：「彼はオブザーバビリティを説明していた。ただその言葉を使わなかっただけだ」。
失敗と不正は別の問題
従来の監視は「失敗の検知」に最適化されている。クラッシュ、エラー、レイテンシ急増——これらは捕捉できる。しかし自信を持って間違いを実行するエージェントは捕捉できない。
「エージェントが稼働しているか」と「正しいことをしているか」は別の問いだ。エラーを検知するために作られたダッシュボードは前者には答えられても、後者を完全に見逃す。
ここで登場するのがevals（評価）だ。テレメトリはエージェントが何をしたかを記録するが、それが正しかったかを判断できるのはevalsだけだという。evalsとは、LLMやエージェントの出力を自動・半自動で採点する評価フレームワークの総称で、LangSmithやRAGASといったMLOps周辺ツールがこの役割を担う文脈で広く使われている。具体的な評価軸としては以下が挙げられている：
- 回答がグラウンデッド（根拠のある）ものだったか
- ツール呼び出しは適切だったか
- タスクの制約は満たされたか
- 最終的な結果が目標と一致していたか
Nadellaはトランザクション処理の古い直感を持ち出した。データ損失というクラスのバグには「システムを止める」という対応をしてきた。帳簿を改ざんするエージェントはデータ整合性のバグであり、チケットを切るのではなくシステムを止めるべき問題だ、と。
「AIセキュリティ」の大半はただのDevOps問題
記事の中で最も刺さる指摘がここだ。
Nadellaはインシデントを2種類に分類した。まず「平凡なもの」——コンテナの設定ミス、パブリックリポジトリに置かれたAPIキー、監視なし、インターネットアクセス制限なし。彼はこれを「クラシックな基本的DevOpsの問題」と切り捨てた。
そのうえで初めて「報酬ハッキング」や「スウォーム動作」といった未解決の新規問題に言及した。
この順序は重要だ。「AIセキュリティ」として語られる問題の大半は、クレデンシャルが野ざらしになっていて、エージェントが動く環境を誰も見えていないという話であり、すでに解決策がわかっている問題だ。アライメント研究に目を向けながら、可視性のない環境でエージェントを動かし続けるのは本末転倒だという指摘は、現場のエンジニアに響く。
オブザーバビリティプラットフォームへの要件
記事後半では、Nadellaの発言を「仕様書」として読み解いている。キーワードごとに具体的な要件を導き出す構成だ。
「行動の証拠」——出力を見るだけでは不十分。エージェントの「軌跡」（どのツールを、どの引数で、どの順序で、どのデータに対して呼び出したか）を記録する必要がある。LLMオブザーバビリティの文脈では、分析単位がレスポンスからトラジェクトリに移行する。
「すべてが監査可能、アクセスしたオブジェクトも」——エージェントのテレメトリは、それが触れたシステム側の記録とも接続されなければならない。エージェントが「DBをクエリした」と言っても、実際に何が届いたかはDBだけが知っている。エージェントは自分の行動の唯一の証人であってはならない。
「脆弱性を連鎖させ始めたときに見える」——事後レポートではなく、複数のステップと複数のシステムをまたいで「シーケンスが組み立てられていく途中」を監視するという要件。これが最も難しい。
Dash0はこれらへの対応として、SignalStore（テレメトリを一箇所に統合）、OpenTelemetryネイティブな設計（プロプライエタリなスキーマは監査証跡として機能しない）、そしてGenAIセマンティック規約への準拠を挙げている。
また、自社のAIエージェントAgent0では、テレメトリから生成したアセットをユーザーに届ける前にライブデータで検証するという設計を採用している。「自信を持って存在しないメトリクス名を出力するAIは出荷したくなかった」というのがその理由だ。
まとめ——日本の現場への接続
記事の結論は明快だ。
- 退屈な問題を先に直せ——設定ミスのサンドボックスとパブリックリポジトリのクレデンシャルが最も現実的なリスクだ
- 出力だけでなく軌跡を記録せよ
- エージェントの主張をシステムの実測値で検証せよ
- 監査証跡はオープンスタンダードで保持せよ——ベンダーロックインは監査証跡をも飲み込む
新しい分野が誕生したわけではない。セキュリティ、DevOps、evals、オブザーバビリティが、新しい種類のアクター（AIエージェント）を中心に連携して機能するよう求められているだけだ。
※編集部の考察：日本の企業現場でも、生成AIを業務フローに組み込む動きが加速している。しかし「動いている」ことの確認はされても「正しく動いている」ことの検証体制が整っていないケースは多い。本記事が説くオブザーバビリティ優先の姿勢は、PoC段階を終えて本番運用に踏み出すチームにとって、今すぐ参照すべき設計原則といえる。
詳細はAI Safety Is an Observability Problem · Dash0を参照していただきたい。
