イベント駆動型エージェントがスコープ、コスト、意思決定の分散を減らす理由
ほとんどのエージェントシステムは、自分たちのコストを制御できていません。というのも、モデルが推論によって境界を見つけるためにトークンを費やしてしまうからであり、建築（アーキテクチャ）が事前に定義すべき境界が開いたままになっています。
タスクが到着する。汎用目的のエージェントは、大きなコンテキストウィンドウ、使えるツールが多すぎる状況、混ざり合った過去のシグナル、そして曖昧に定義された目的を受け取ります。そこからモデルは、何が重要で何が重要でないか、どのツールが妥当か、どの制約が適用されるか、そして成功はどのように測定されるべきかを推定しなければなりません。
これは高価です。
トークンだけでなく、不要な探索、レイテンシ、失敗したツール呼び出し、ポリシー拒否、そして無関係な可能性空間に対する回避できる推論によってもコストが増えます。
ここで強調したい核心は次のことです。多くのエージェントシステムは、推論が始まる前の段階でモデルに開いた意思決定が多すぎるために高コストになるのです。
私は、イベント駆動型エージェントは、そのように開いた意思決定を減らす最もきれいな方法の一つだと思っています。
適切に定義されたイベントは、単に作業を起動する以上の役割を持ちます。問題の境界を定義し、エージェントが作業するための初期コンテキストになります。イベントの設計が良いほど、エージェントはより精密になります。
そのイベントは、専門家エージェントにルーティングされます。つまり、何をすべきかを考え出さなければならない汎用エージェントではなく、すでに自分が扱う問題のタイプを知っているエージェントです。
一般性の本当のコスト
多くのエージェントシステムにおけるデフォルトのパターンは、いまだに広く暗黙的です。
- モデルに大量のコンテキストを与える
- 広いアクション面（アクションの選択肢）を公開する
- 汎用的な指示を提供する
- 推論の時点でモデルが正しい境界を見つけることに期待する
これはスケールしません。
システムが成長するにつれて、エージェントは次のように考えることを強いられます。
- 異種の履歴
- 複数のサブシステム
- 弱く関連したシグナル
- 大量の候補ツール
- 重複する目的
この時点で、問題はもはや単にコンテキストサイズの問題ではありません。
意思決定の分散です。つまり、もっともらしい解釈が多すぎる、候補アクションが多すぎる、そして注意を奪い合う無関係なコンテキストが多すぎる状態です。
広いエージェントでも成功することはありますが、システムが毎サイクルごとに問題分解を何度も解かせてしまっています。さらにシステムが大きくなるほど、モデルが失敗したり、切り抜けるために近道を使ったりする可能性は高まります。
それはアーキテクチャ上の無駄です。
イベントは単なるトリガーではない
適切に設計されたイベント駆動型システムでは、イベントは単なる輸送（トランスポート）のプリミティブではありません。
それはセマンティックな境界です。
よく定義されたイベントは、次のことについて強いシグナルをすでに含んでいます。
- どのクラスの状況が発生したか
- どの専門家としての能力が関連しているか
- どのコンテキストを具現化すべきか
- どのツールを検討する価値があるか
- どのポリシーが応答を支配すべきか
- 結果はどのように評価されるべきか
これにより、システムの出発点が変わります。
「次のこと」を問う代わりに：
この環境全体で、エージェントは何をすべきか？
システムは次のように問うことができます：
これらの制約の下で、このクラスの状況に対して、この専門家はどう扱うべきか？
それははるかに健全な問いです。
要点：推論の前に絞り込む
イベント駆動型エージェントのアーキテクチャ上の価値は、単に疎結合にすることだけではありません。制御です。
よく定義されたイベントにより、モデルが推論を始める前に、システムは次の4つを絞り込めます。
1. 問題スコープ
イベントは運用上の境界を定義します。
2. コンテキストスコープ
関連する知識だけを具現化すべきです。
3. アクションスコープ
関連するツールと権限だけを公開すべきです。
4. 評価スコープ
成功基準はより局所化され、観測しやすくなります。
このため、イベント駆動型システムは同時に安くなり、より信頼性も高くなり得ます。
4つのアーキテクチャ層をまたいだ絞り込み
真面目なイベント駆動型エージェントシステムは、4つの層にまたがって問題を絞り込むべきです。
1. イベントルーティング — 問題面を絞り込む
最初の絞り込みステップは、イベントの分類とルーティングです。
例えば次のような、よく定義されたイベント：
ThermalDriftDetectedPolicyViolationDetectedExecutionFailureObservedIncidentSeverityRaised
は、すでにシステムに「すべての能力が同じように関連しているわけではない」ことを伝えています。
ルーティングは、その問題クラスに適した専門家能力、または専門家の集合を選択すべきです。
モデルは、そのイベントがすでに教えてくれている内容を探し出すためにトークンを消費すべきではありません。
2. コンテキストの具現化 — 知識面を絞り込む
イベントの境界が分かったら、コンテキストをフラットなプロンプトの束として組み立てるべきではありません。
明示的かつ狭く具現化されるべきです。
- 関連するエンティティだけ
- 有用な場合に限って因果関係だけ
- 事前の緩和策と結果
- 前回の意思決定からの根拠
- イベントクラスに結び付いた制約
ここで、多くのシステムは勝つか負けます。
絞り込まれたコンテキストが自動的に良いコンテキストとは限りません。目的は単にトークンを削ることではありません。目的は 関連性密度を高めることです。
そのため、コンテキストの品質は観測可能であるべきです。
ここで役立つ指標には、例えば次のものがあります。
raw_equivalent_tokenscompression_ratiocausal_densitynoise_ratiodetail_coverage
これらの指標によって、「どれだけのコンテキストを渡したか？」よりもはるかに良い問いを立てられるようになります。
より良い問いは次です。
専門家が本当に必要としているものを失わずに、どれだけの不要なコンテキストを捨てられたか？
3. ガバナンスされた実行 — アクション面を絞り込む
正しいコンテキストがあっても、エージェントは制限のないアクション面で動作すべきではありません。
実行は管理されるべきです。
ランタイム層は次によって実行を絞り込めます。
- 候補ツール集合を制限する
- 呼び出し前に、起こりそうなアクションを順位付けする
- 実行前にポリシー検査を適用する
- 実行環境を隔離する
- テレメトリ、ログ、トレースを取得する
システムのコストは、プロンプトに費やすものだけではありません。ツールのファンアウト、拒否されたアクション、そして不要な探索に費やすものでもあります。
そのため、実行品質にも指標が必要です。
ここで役立つ指標には、例えば次のものがあります。
workspace_tool_calls_per_taskworkspace_success_on_first_tool_rateworkspace_recommendation_acceptance_rateworkspace_policy_denial_rate_bad_recommendationinvocation_latency_histograms
4. 観測可能性とフィードバック — エビデンスによる絞り込み
最後の層は観測可能性です。
観測可能性がなければ、「イベント駆動型エージェントはコストを下げる」というのは信念のままです。
観測可能性があれば、それは検証可能になります。
よく計装されたシステムは次を示せます。
- コンテキストが密になっているのか、単に小さくなっているだけなのか
- 専門家が広いエージェントよりも少ないツールを使っているか
- ルーティングが最初のアクションの成功率を改善しているか
- ポリシー境界が役に立っているのか、それともチurn（手戻りや反復）を生んでいるだけなのか
- スコープを狭めることで結果の品質が向上しているか
ここから、アーキテクチャは単なる意見ではなく、運用上の仮説になります。
具体例：アラート駆動によるリメディエーション
これを考えるための役に立つ見方は、実運用のクラスタにおける「運用リメディエーションのループ」です。
観測（オブザーバビリティ）のスタックから、サブシステムが重要なしきい値を超えたというアラートが届いたと想像してください。
幅広いエージェントの設計だと、たとえば次のようなことをするかもしれません：
- 最近のログを集める
- 幅広いシステム履歴を集める
- 多くのツールを公開する
- 汎用のエージェントに状況の安定化を依頼する
このアプローチは、分解作業をモデルにやらせすぎてしまいます。
イベント駆動の設計は、別の仕組みで動きます。
ステップ1 — 明確に定義されたイベントがシステムに入る
そのアラートは、IncidentSeverityRaised や ExecutionFailureObserved のような、明確に定義されたイベントになります。
ステップ2 — イベントが専門家向けの経路を選択する
システムは、その種類の問題を扱う専門的な機能（スペシャリスト能力）へイベントをルーティングします。
ステップ3 — コンテキストが狭く具体化される
コンテキスト層は、そのインシデント種別に関連するものだけを組み立てます：
- 影響を受けたサブシステム
- 最近の関連する失敗
- 以前の緩和（ミティゲーション）
- 現在の運用上の制約
- 既知の因果的な依存関係
ステップ4 — 実行は統制される
ランタイムは利用可能なアクション空間を狭めます：
- 関連するツールだけが見える
- 提案されたアクションが順位付けされる
- ポリシーチェックで、実行前に危険なアクションを拒否できる
- テレメトリが全サイクルに付与される
ステップ5 — 結果がエビデンスになる
緩和の結果は、新しいイベントと新しい計測ポイントになります。
その時点で、システムはインシデントが対処されたかどうかだけでなく、その経路がどれだけコストのかかるものだったかも観測できます：
- どれくらいのコンテキストが必要だったか
- どれくらいのツールが検討されたか
- 最初に推奨されたアクションが成功したか
- ポリシーが経路を狭めたのか、ブロックしたのか
- サイクルが全体としてどれくらいの時間だったか
これがパターンの本当の強みです。
イベントは、作業のための単なるトリガーではありません。推論が始まる前に、問題スコープ・知識スコープ・アクションスコープをシステム全体が絞り込めるようにする境界（バウンダリ）です。
1行で表すと、このアーキテクチャ
役に立つ考え方はこれです：
各ステージは、無関係な可能性を取り除くべきです。
もしシステムが取り除くのではなく、オプションを追加し続けているなら、おそらく間違った方向へ進んでいます。
どうやってコストを下げるのか
コスト削減は、同時に複数の要因から生まれます：
- 入力トークンが減る
- コンテキストがより密になる
- 候補ツールが減る
- 結果のない実行が減る
- 危険なアクションが実行に到達するのが減る
- 曖昧な推論が原因でリトライが減る
- 有用な最初のアクションまでのサイクルが短くなる
幅広いエージェントは、これらのコストを暗黙に支払います。
イベント駆動の専門家システムは、構造的にそれらを避けます。
どうやって意思決定の分散を抑えるのか
意思決定の分散は、システムが同時に開いたままにしすぎる経路によって起こります。
コンテキストが多すぎる。
ツールが多すぎる。
もっともらしい解釈が多すぎる。
弱く境界づけられたゴールが多すぎる。
明確に定義されたイベントは、その流れを断ち切ります。
不確実性をなくすわけではありませんが、拡散した推論の問題を、よりローカルな問題へと変換します。
システムは、もはや世界全体のグローバルな解釈を求めません。境界付けられた状況の「ある範囲」に対する、境界付けられた応答を求めます。
それが、品質とコストの両方に役立つような絞り込みです。
実運用システムで測るべきもの
このアーキテクチャが説得力を持つには、測定可能でなければなりません。
強力な実運用デモでは、同じ種類のインシデントに対して、より幅広い経路の方法と、イベント駆動の専門家経路の方法を比較すべきです。
コンテキスト層については、有用な計測として次が挙げられます：
raw_equivalent_tokenscompression_ratiocausal_densitynoise_ratiodetail_coveragecontext_bytes_saved
実行層については、有用な計測として次が挙げられます：
workspace_tool_calls_per_taskworkspace_success_on_first_tool_rateworkspace_recommendation_acceptance_rateworkspace_policy_denial_rate_bad_recommendationinvocation_latency_histogramstrace_span_durations
重要なのは、すべてのイベント駆動設計が自動的に優れていると主張することではありません。
重要なのは、この設計によって「本当に絞り込みが起きているか」そして「それが効果を生んでいるか」を検証するための、筋の通った方法が得られることです。
これで解決できないこと
イベント駆動のエージェントは、すべてを解決するわけではありません。
次の場合には、ひどく失敗する可能性があります：
- イベントが不適切に設計されている
- 専門家の境界が不明確である
- コンテキストの具体化（マテリアライズ）が弱い
- ランタイムが誤ったツールを公開する
- ポリシーが緩すぎる、または厳しすぎる
- オブザーバビリティが不完全である
ノイズの多いイベントの分類体系は、明確さではなくノイズを作ります。
悪い専門家の境界は、混乱をプロンプトからルーティング層へ移すだけです。
狭いシステムは、絞り込みが意味論的に健全である場合にのみ良くなります。
最終的なアイデア
コストを下げ、焦点を改善し、分散をなくすことは、同じ原則の結果です：推論の前に絞り込む。これを、具体化されたコンテキスト、統制された実行、そして実際のオブザーバビリティと組み合わせると、システムはプロンプトのパイプラインではなく、運用のための基盤になります。
スケールするのは、より大きなモデルを、より多くのコンテキストとより多くのツールにさらすシステムではありません。
モデルが考え始める前に、世界をどう絞り込むかを学ぶシステムが、そうなります。
— Tirso Garcia · 2026年4月
これらのアイデアをオープンに構築する：
rehydration-kernel · underpass-runtime
同様の問題に取り組んでいるなら、ぜひあなたの話を聞かせてください。
