マルチエージェントシステムを構築するほとんどのチームは、まずオブザーバビリティツールに手を伸ばす。ダッシュボードを配線し、アラートしきい値を設定し、ログアグリゲーターを構成する。そしてデプロイする。すると何かが静かに壊れ、どのエージェントが原因か、何をすべきだったか、誰が修正すべきかを誰も判断できない。
欠けているステップはより良い監視ではない。フリートインベントリだ。
フリートインベントリとは何か
フリートインベントリとは、システム内で稼働しているすべてのエージェントのマシン可読な記録だ。READMEでもNotionドキュメントでもない。インフラが読み取り、検証し、クエリできる構造化ファイル――JSON、YAML、TOML、どれでも構わない――だ。
各エントリは3つの質問に答える：
- このエージェントは何か？
- 正常であることをどう確認するか？
- 正常でない場合はどうなるか？
その記録がなければ、監視ツールは理解していないシステムを監視することになる。プロセスがダウンしていることは伝えられる。しかし、そのプロセスが稼働すべきだったか、何を担当していたか、どのダウンストリームエージェントが今入力を失っているかは伝えられない。
すべてのエントリに必須の3つのフィールド
1. アイデンティティ
アイデンティティは名前以上のものだ。有用なアイデンティティブロックには以下が含まれる：
- 正規名 ― ログ、アラート、ハンドオフで使用される正確な文字列
- ロール ― エージェントの機能とパイプライン内の位置を1文で説明したもの
- オーナー ― その動作に責任を持つチームまたは個人
- バージョン ― デプロイされたバージョン（リポジトリの最新タグではない）
正規名は聞こえる以上に重要だ。ログアグリゲーターがprospect-enricherと呼び、アラートがenrichment-agentで発火し、ランブックがlead-enrichment-workerを参照しているなら、1つのものに3つの名前が存在する。午前2時のインシデント中、その曖昧さは20分のロスになる。
2. ハートビートコントラクト
ハートビートコントラクトは、正常な状態を測定可能な形で定義する：
- 期待されるケイデンス ― エージェントが出力を生成すべき頻度（例：90秒ごとに少なくとも1レコード処理）
- レイテンシ上限 ― 入力受信から出力送信までの最大許容時間
- エラーレートしきい値 ― アラートをトリガーする障害の割合（通常のノイズとの区別）
これらの数値はステージングでの観測された動作から得るべきであり、推測からではない。現実的な負荷でエージェントを48時間実行する。p95レイテンシを記録する。その2倍の値を上限として設定する。これでモニターには漠然とした「遅い気がする」ではなく、強制すべきコントラクトができる。
3. 障害エスカレーションパス
このフィールドが答える問いは：ハートビートコントラクトが違反された場合、次に何が起きるか？
最小限のエスカレーションパスには3つのステップがある：
- 自動リトライポリシー ― エージェントが失敗とみなされるまでのリトライ回数とバックオフ
- フォールバック動作 ― パイプラインが一時停止するか、失敗したエージェントを迂回するか、劣化した出力を送出するか
- 人間へのエスカレーション先 ― アラートを受け取る人またはチャンネル、および対応に必要な情報
フォールバック動作はほとんどのチームが省略するフィールドだ。アラートは定義するが、対応は定義しない。そのためアラートが発火すると、オンコールエンジニアはドキュメント化されたガイダンスなしにプレッシャー下で判断を迫られる。フォールバック動作はシステムが落ち着いているときに書く。壊れてからではない。
最初のインシデント前にブートストラップする方法
初日に完璧なインベントリは必要ない。完全なインベントリが必要だ――一部のフィールドがプレースホルダーであっても、すべてのエージェントが記録されていること。
実践的なブートストラップ手順：
- 現在本番で稼働しているすべてのエージェントをリストアップする。 5分以内に記憶からリストアップできなければ、それが最初に解決すべき問題だ。
- 環境ごとに1つのインベントリファイルを作成する（本番、ステージング）。インフラコードと並べてバージョン管理に保存する。
- まずアイデンティティフィールドを埋める。 正規名、ロール、オーナー、バージョン。ほとんどのシステムで1時間もかからない。
- 観測データからハートビートコントラクトを計測する。 ステージングにデプロイし、48時間現実的なトラフィックを流し、数値を記録する。
- 次の機能を書く前に障害エスカレーションパスを書く。 これをバックログアイテムではなくブロッキングタスクとして扱う。
DK1.AIでは、構築するすべての本番システムで最初のエージェントが稼働する前にこのインベントリから始める。AI Brand Presenceのデプロイメントを構築する際、フリートインベントリは最後ではなく最初に生成するアーティファクトだ。監視の構造化方法、完了の定義方法、クライアントチームへの運用引き渡し方法を決定する。
インベントリは障害を防がない。障害を判読可能にする。判読可能な障害は診断に15分かかる。判読不能な障害は3時間とウォールームを要する。
実際のメリット
インベントリなしで8つのエージェントを運用するチームは、インシデントごとに何が壊れてなぜかを特定するだけで約2〜3時間費やす。最新のインベントリを持つ同じチームはそれを30分以内に短縮できる。四半期に4件のインシデントがあれば、6〜10時間が回収される――さらに、エンジニアが変更するシステムを信頼できるため、イテレーションが速くなる複利効果もある。
地味な勝利。リポジトリにチェックインされたYAMLファイルは、マッピングされていないシステムの上に構築された美しいオブザーバビリティダッシュボードに勝る。