製品

小規模なエージェントは対象範囲が厳密で、何年にもわたって実行されます

構築されてから 1 年経ってもまだ実行されているエージェントが野心的なものであることはほとんどありません。それらは狭く、実行することは 1 つで、その境界は最初の行が書かれる前に決定されています。

Yaju チーム · 2026 年 7 月 8 日

最初のエージェント プロジェクトから 12 か月が経過した現在も組織内で何が実行されているかを見ると、あるパターンが見えてきます。ワークフロー全体を処理する予定だった印象的なエージェントがいなくなりました。毎週火曜日の朝にレポートを再フォーマットする小規模なものはまだ存在しますが、それについて何ヶ月も誰も考えていませんでした。

それは野心の失敗ではありません。それがスコープの役割です。

なぜブロードエージェントは衰退するのか

広範なエージェントにはさまざまな間違いがあり、それぞれが個別に信頼を損ないます。 8 番目の状況はうまく処理され、9 番目の状況はうまく処理されません。どの状況が 9 番目であるかを誰も予測できないため、すべての出力が慎重にレビューされます。

すべての出力を注意深く確認しても、エージェントは時間を節約できません。実行から確認へと移行しましたが、なじみのない作業を確認する方が、慣れた作業を行うよりも明らかに速いわけではありません。

広範なエージェントも評価に抵抗します。 「顧客からの問い合わせに対応する」という基準を作成するのは非常に難しいため、通常は作成されません。つまり、品質が採点されることはなく、品質の低下が認識されることもありません。

ナローエージェントが生き残る理由

狭いエージェントは文で記述することができ、文で記述できるものはすべて評価できます。適切な出力がどのようなものであるかを書き留め、それに対する実行ごとにスコアを付け、チェックが失敗した場合にはエージェントを停止することができます。

自然な所有者もいます。 「レポート再作成者は誰の所有者か」には明らかな答えがあります。 「顧客問い合わせエージェントの所有者は誰か」ということはなく、所有者のいないエージェントは孤立してしまいます。

そしてそのコストは判読可能です。狭いエージェントに起因する支出は、これだけの実行数、実行ごとにこれだけの金額、この結果というように解釈できます。広範なエージェントに起因する支出は、誰も行動に移すことができない数字です。

維持する境界を設定する方法

「および」を使用せずにエージェントを 1 つの文で説明します。接続詞が必要な場合は、エージェントが 2 人必要になります。

何を行うかを決定する前に、何が禁止されているかを決定し、プロンプトではなくアクションの時点でそれを強制します。アクションが発生する場所でポリシーが適用される場合、本番環境に決して書き込むべきではないエージェントを本番環境に議論することはできません。

構築する前に評価基準を書きます。優れた出力とはどのようなものかを明確にできない場合、その範囲はまだ曖昧であり、構築してもそれが明確になりません。

誰かに頼まれたときではなく、初日に名前付きの所有者を付けてください。

構成が幅広さに勝る

野心の有用なバージョンは、1 人のエージェントが 10 のことを行うことではありません。それは 10 人のエージェントがそれぞれ 1 つのことを行っており、構成されており、それぞれが個別に評価可能であり、個別に置き換え可能です。

これはエージェントを共有可能にする理由でもあります。明確な境界を持つエージェントは、エージェント ハブに公開したり、別のチームによってフォークされたり、改善されたり、ロールバックされたりすることができます。広大なものは、それを生成したコンテキストに固有のものであり、他の誰にも役に立ちません。

不快な部分

厳密にスコープを設定するということは、エージェントが興味深いエッジケースを処理しないが、それでも担当者が処理することを受け入れることを意味します。これを受け入れたチームは、長く続くものを作ります。最後の 10 パーセントを獲得するために境界を広げ続けたチームは、通常、最初の 90 パーセントは誰も信頼できないエージェントを担当することになります。

次へ

エージェント ハブのページでは、チーム間でのエージェントの公開、フォーク、バージョン管理について説明します。エージェント オーケストレーション システムのページでは、境界を意図したものではなく実際のものにする所有権、ポリシー、評価について説明します。