エンタープライズのエージェント統制をめぐる議論は、この一年で急速に成熟した。承認ゲート、RBAC、非人間ID、MCPゲートウェイ——「エージェントを止める・縛る力」の設計は、homula も繰り返し扱ってきたテーマだ。だが、その議論には静かに前提が置かれている。「エージェントが実際に何をしたかを、後から正確に再構成できる」という前提だ。この下地がなければ、承認も監査も宙に浮く。止める力の前に、まず見る力——可観測性（オブザーバビリティ）がいる。
2026年、このエージェント可観測性が、従来のアプリ監視や単発のLLMログとは別の独立した規律として立ち上がった。本稿では、なぜ「統制の議論が進んだ今こそ可観測性なのか」を整理し、日本企業が統制と価値実証の下地としてどこに投資すべきかを示す。
統制と可観測性は別物——「止める力」の前に「見る力」がいる
まず区別を明確にしたい。統制（ガバナンス）は「させない／承認させる」力であり、可観測性は「起きたことを見て、説明できる」力だ。この二つは補完関係にあるが、同じものではない。
エージェントの失敗は、単発のAPI呼び出しでは起きない。複数ターン・複数ツールにまたがる連鎖の中で起きる。ステップ10で返ってきた誤答の根因が、ステップ3のツール呼び出しの引数ミスや、ステップ1のコンテキスト取得の取りこぼしにある——こうした構造だ。「入力と最終出力」だけを記録していても、この因果の鎖はたどれない。
「承認ボタンを押した／押さなかった」という統制ログは残っても、エージェントがその判断に至るまでに何を読み、どのツールをどう呼び、なぜその結論を出したかが再構成できなければ、事故の根因究明も、成果の説明も、改善もできない。統制は、可観測性という下地の上でしか機能しない。
homula がこの1年扱ってきた「94%が統制に安心しても3社に1社しか実行できない」というガードレール遅れの問題（別稿）も、突き詰めれば「見えていないものは統べられない」という同じ壁に行き着く。
2026年、可観測性が『規律』になった——実行を"ツリー"として捉える
では、エージェントの「見る力」は具体的にどう標準化されつつあるのか。中心にあるのが OpenTelemetry（OTel）の GenAI セマンティック規約だ。これは、AIのテレメトリをベンダー中立で記述するための共通語彙で、2026年に急速に事実上の基盤になりつつある。
その設計思想が象徴的だ。従来の「1回のLLM呼び出しのログ」ではなく、エージェントの実行全体を"スパンのツリー"として捉える（Greptime）。
invoke_agent：エージェントの実行（走行）そのものchat：その中での各モデル呼び出しexecute_tool：各ツールの実行
この階層で記録すれば、「ステップ10の誤答→ステップ3のツール→ステップ1の取得」という因果の鎖を、木構造としてたどれる。VS Code Copilot・OpenAI Codex・Claude Code（ベータ）といったコーディングエージェントは、すでに OTel の GenAI トレースを出力し始めている。
ただし冷静な注釈も要る。この GenAI 規約は2026年半ば時点でまだ「Development（旧experimental）」ステータスで、正式に安定版（Stable）にはなっていない（DEV Community）。標準は動いている最中だ。だからこそ企業は「特定ベンダーの独自ログ形式に固く縛られない」設計——中立な規約に寄せておく設計——を今のうちに選んでおく価値がある。
「見る」の三層——トレース・本番評価・コスト帰属
エージェント可観測性は、単なる「ログを取る」ではない。実務では次の三層で捉えると設計しやすい。
| 層 | 問い | 実装の要点 |
|---|---|---|
| 実行トレース | 何を・どの順で・どう呼んだか | 実行ツリー（invoke_agent → chat → execute_tool）を全ステップ記録 |
| 本番評価 | その出力は「良かった」か | デプロイ後も継続的に品質を採点（LLM-as-judge等）し、評価ループに戻す |
| コスト帰属 | 誰の・どの処理が幾らか | トークン／実行単位でコストを分解し、FinOpsにつなぐ |
とりわけ2026年の勘所は、評価を「リリース前のテスト」で終わらせず、本番で走り続けるエージェントを継続的に採点する方向に移ったことだ（Braintrust）。非決定的で毎回経路が変わるエージェントは、一度通ったテストが翌日も通る保証がない。「見る」を本番に常駐させ、劣化を検知して評価に戻す——この循環がないと、AI活用の"価値の谷"——現場の生産性は広く実感されても、利益貢献を数字で説明できる企業はごく一部にとどまるという断絶——を越えられない。成果を数字で語れないのは、多くの場合、成果が出ていないのではなく、成果を"見て測る"下地がないからだ。
監査ログは義務、可観測性は経営
可観測性は、コンプライアンス面でも「あれば良い」から「なければ違反」へと近づいている。EU AI Act は、高リスクAIシステムに対し、稼働期間を通じたイベントの自動記録（ログ）を技術的に可能にすることを求める（Article 12）。ここでの「自動」は重い意味を持つ。手作業のドキュメントや事後の再構成では満たせず、システムが自ら・全インタラクションについてログを生成する"アーキテクチャ上の義務"とされる。加えて、自動生成ログは最低6か月の保持が求められる（Article 19）。
ここで押さえたいのは、監査ログ（義務としての記録保持）と、可観測性（診断・評価のための"見る力"）は重なるが同じではないという点だ。前者はコンプライアンスの最低ライン、後者は事故を防ぎ品質と成果を上げる経営の道具だ。両者を分断して別々に作ると、二重投資と説明不能が生まれる。同じ実行トレースを土台に、監査要件も診断も評価もコストも賄う——この一体設計が、これからの標準になる。
homulaの観点——記録の受け皿を持ち、"見る力"を統制と地続きに
homula はエンタープライズ向けの AIエージェント・インテグレーターとして、戦略策定 → PoC（最短5日）→ 実装 → 運用 → 内製化を一気通貫で支援している。可観測性の観点から、取るべき順序は明確だ。
第一に、記録の受け皿を先に持つ。homula の Agens Control は、承認フロー・DLP・RBAC に加え、5年分の監査ログを提供する。EU AI Act が求める「最低6か月」を大きく上回るこの記録層は、コンプライアンスの受け皿であると同時に、事故の根因究明と成果説明の土台になる。統制（止める力）と記録（見る力）を、別々の製品に分断せず地続きで持てることに意味がある。
第二に、中立な規約に寄せてつなぐ。統合基盤 Agens は MCP を活用して200以上のツールと構築ゼロで接続するが、接続点はそのまま「エージェントが何を呼んだか」を捉える観測点でもある。特定ベンダー独自形式に固く縛られず、OTel のような中立規約と親和的に設計しておくことが、標準が固まりきる前のいまの堅い選択だ。
第三に、測る設計を初日から入れる。何を成功とみなし、どの指標で本番評価するか——これを PoC の段階で決めておく。homula の AIエージェント・ブートキャンプ は、業務棚卸し・プロトタイプ構築・ROI試算を3〜5日で回すが、そこに「どう見て・どう測るか」を組み込むことで、後から成果を説明できる状態を最初から作る。既存業務で処理時間を93%削減した実績も、測る下地があってこそ数字として示せる。
まとめ
エージェント統制の議論が成熟した今、次の主戦場は「止める力」の手前にある「見る力」——可観測性だ。2026年、それは OpenTelemetry の GenAI 規約（まだ Development ステータス）を軸に独立した規律となり、EU AI Act の自動ログ義務によってコンプライアンス要件にもなった。だが本質は義務対応ではない。エージェントが何をしたかを実行ツリーとして再構成し、本番で品質を測り続け、コストを分解する——この下地があって初めて、統制は機能し、価値は数字で説明でき、改善の循環が回り出す。
見えないものは、統べられないし、良くもできない。承認ボタンの設計に投資したなら、次はその判断の"手前"、エージェントの一挙手一投足を再構成できる観測点に投資する番だ。監査ログを義務の最低ラインで止めず、診断と評価と経営に使える"見る力"へと引き上げること。ここが、次の一年で成果に差をつける。
自社のエージェントは「何をしたか」を後から再構成できる状態にあるか。監査ログの受け皿から本番評価の設計まで、統制と地続きの可観測性を、homula がご一緒します。