シグナルが赤になったとき：Agentのトラブルシューティング能力

前述の4つのセクションで多層的なフィードバックシステムを構築した：静的解析がミリ秒で型の問題を食い止め、CIが分単位でビルドとテスト結果を報告し、Observabilityが時間～日単位でランタイムの振る舞いを追跡し、IaCがこれらのフィードバックシグナルの信頼性を担保する。しかしフィードバックは「何かがおかしい」と教えてくれるだけで、「なぜおかしいのか」は教えてくれない。

トラブルシューティングはフィードバックシステムの最後のリンクだ。いずれかの層でシグナルが赤になったとき、Agentは根本原因を特定できる必要がある。この能力の品質が、フィードバックシステム全体が真にclosed-loop controlを実現できるかどうかを決定する。

Agentのトラブルシューティング能力はこの1年で実質的な進歩を遂げた。実践者からの報告では、バグが5つのサブシステム --- データベース、キャッシュ、フロントエンド、バックエンドAPI、オブジェクトストレージ --- にまたがるシナリオで、Agentが自律的に診断スクリプトを書き、各システムから実際のデータを取得し、期待値と比較し、徐々にスコープを絞り込み、30分以内に根本原因を特定したケースがある。これはプロジェクトに精通した中堅エンジニアとほぼ同等だ。

しかしトラブルシューティング能力の天井は、Agentが何を「見る」ことができるかに依存する。ここで前述のインフラ層がその価値を証明する。ログが構造化され、メトリクスが細粒度で、トレースが完全であれば、Agentは推論に十分な情報を持つ。ログが散在するテキストで、監視が粗いダッシュボードのみで、トレースがなければ、Agentはほぼ診断不可能なブラックボックスに直面する。

トラブルシューティング能力はプラットフォームアーキテクチャにも要求を出す。示唆に富むケースの一つ：リモートプロトコルを通じてUIとレンダリング層を分離すると、UI状態の機械可読なスナップショットが生成される。このアーキテクチャ上の決定は元々別の理由でなされたが、結果としてAgentが複雑なUI状態を「見る」ことを可能にし、デバッガスキルと組み合わせて、以前は人間しか調査できなかったビジュアルバグの診断を可能にした。プラットフォームがどの情報を機械可読な形で公開するかが、Agentのトラブルシューティングの天井を直接決定する。

もう一つ注目すべきシフトがある。ワークフローが人間がコードを書くことからAgentがコードを書くことへ移行するにつれ、デバッグの対象も変わる。以前はコードをデバッグしていた：ブレークポイントを設定し、変数を検査し、実行パスを追跡する。今では、指示をデバッグすることに時間が費やされるようになっている：プロンプトを修正し、制約を調整し、コンテキスト構造を最適化し、Agentの出力が一発で受入基準を通過して直接マージされるようにする。抽象化のレイヤーは上がったが、フィードバックループの核 --- 仮説を立て、テストし、検証し、修正する --- は根本的に変わっていない。

これはplatform engineeringの拡張も示唆している：Agentのコード出力だけでなく、人間の指示出力に対してもフィードバックシステムを構築すること。特定の指示が繰り返しAgentから低品質なコードを引き出すなら、プラットフォームはこのパターンを検知し、人間にシグナルを送るべきだ：「この指示は見直しが必要かもしれません」。フィードバックは環境からAgentへ流れるだけでなく、Agentの行動パターンからAgentを操作する人間へもフィードバックされる必要がある。