カスタムエージェントを改善するためのベストプラクティス

エージェントのパフォーマンスは、「ベースとなるモデル」「トリガーと適用範囲の設定」「指示の出し方」の3つで決まります。どれか1つを見直すだけでも、エラーが減って出力のムラもなくなり、コストパフォーマンスも良くなります。

本ガイドでは、以下のような設定・調整のコツを順に解説していきます。

• タスクに応じたモデルの選択

• エージェントのトリガーと適用範囲の制御

• エージェントを活用したデバッグと最適化

「Product Scout」は、社内のプロダクトに関する質問に答えるカスタムエージェントです。彼の仕事は、ドキュメントや過去のやり取りからサクッと情報を探し出し、「機能Xって一括エクスポートできる？」といった質問にすぐさま正確に答え、チームを助けることです。

現在の設定では、Slackチャンネル内のすべてのメッセージをトリガーに作動し、ワークスペース全体を検索範囲とし、最もパワフルなスペックのモデルで稼働しています。動作自体に問題はありませんが、3つの課題が見えてきました。「回答にムラがある」「必要以上に頻繁に実行されている」「コストをもっと抑えられる」という点です。本ガイドでは、このエージェントを具体例として使いながら、各設定を調整することで実際の動作がどのように変わるかを実証していきます。

Notionではカスタムエージェントのベースモデルを自由に選択できます。そして、どのモデルを選ぶかが、コストを大きく左右する大きな要因の一つとなります。とにかく一番パワフルなモデルを選べばいいというわけではなく、自分が求めるクオリティの成果をブレずに毎回出してくれる、ちょうどいいモデルを見つけることが大切です。

モデルを選択する際は、モデルピッカー内の各オプションにカーソルを合わせることで、処理スピード、賢さ、コストを比較できます。

モデル選びの基準は以下のとおりです。

• 自動を選択すると、Notionがリクエストに応じて最適なモデルを自動で選択します。これは、ほとんどのエージェントのデフォルト設定として推奨されています。

• 軽量モデルは、日常的なドラフト作成、届いた案件の簡単な自動振り分けや優先順位付け、構造化されたコンテンツの生成など、繰り返し発生する重要度の低いワークフローで真価を発揮します。複雑な推論よりも、処理速度、一貫性、コスト効率が重視される場合に最適です。

• 強力なモデル（Opusなど）は、ニュアンス豊かな文章作成、複雑な推論、あるいは高い正確性が求められるタスクに最適です。ただし、その分1回の実行に消費されるクレジットポイントは多くなります。

まずは複数のモデルを実際に動かしてみて、どれが求める品質基準を安定してクリアできるか見極めてください。もしタスクが複雑になって、回答の質が落ちてきたと感じたら、いつでもよりパワフルなモデルに切り替えることができます。

サンプルエージェントの「Product Scout」も、最初は一番パワフルなモデルで稼働していました。しかし、「関係のある資料を見つけてきてまとめる」という彼の基本業務には、そこまで高度な思考力は必要ありませんでした。それで軽量モデルに切り替えたことで、回答のクオリティはそのままに、運用コストだけを抑えることができました。

エージェントのトリガーと適用範囲は連動しています。トリガーはいつ実行されるかを制御し、適用範囲は何を読み取るかを制御します。どちらの設定も広すぎると、関係のない的外れな回答が増え、無駄にクレジットポイントがどんどん消費されてしまいます。

「実用的な頻度で、なおかつ必要なときにだけピンポイントで起動する」という絶妙な絞り込みが、理想的なトリガーの条件です。エージェントは起動するたびに、何のアクションも行われなかったとしても、毎回クレジットポイントを消費します。そのため、実際にエージェントの手を借りたいタイミングだけに的を絞ることが大切です。

サンプルの「Product Scout」は、#product-questionsチャンネル内の返信やリアクション、「ありがとう」といった単なる挨拶を含むすべての発言に対してトリガーする設定になっていました。つまり、有益な回答を出さない空振りの実行にクレジットポイントを無駄遣いしている状態でした。

まずは、エージェントの出番を定義することから始めましょう。

• このエージェントはどのような質問に答えるべきですか？対象とする質問の種類をあらかじめ狭く絞り込んでおき、具体例をいくつか書き出しておくのがコツです。

• どんなメッセージをスルーすべきですか？絵文字のリアクション、「ありがとう」などの挨拶、雑談、本題からズレたメッセージなどは、トリガーの対象外にする必要があります。

こうした線引きが決まれば、それに合わせてトリガーの条件をチューニングします。例えば、@メンションされたときだけに限定したり、キーワードでフィルターしたり、すべての編集に反応させたりするのではなく、特定のプロパティが変更されたときだけ起動するように制限します。

「Product Scout」の場合で言うと、トリガーを@mentions限定に変更すると、質問を投げかけた時にだけ実行されるようになります。

エージェントは、アクセス権を与えられたすべてのコンテンツを読み込みます。その範囲が広すぎると、大量の無関係な情報を選別する羽目になり、出力の質が低下してしまいます。

「Product Scout」は、ワークスペース全体だけでなく、繋がっているすべてのツール（マーケティングページ、人事書類、過去のミーティングのメモ、無関係なチャンネル内の数か月分に及ぶSlack履歴など）をすべて検索していました。プロダクトに関する答えが見つかるはずもないのに、エージェントは律儀にすべてを読み込んでいたのです。その結果、無駄な情報がまじり、回答にムラが出ていました。

エージェントの「読み込み範囲」をどう決めるべきか、その考え方のコツをまとめました。

• まずは、求める答えが「どこにあるのか」を特定することから始める：プロダクトに関する質問に答えるエージェントなら、プロダクトの仕様書や関連するSlackチャンネルのみに接続し、ワークスペース全体や各連携ツールにまでアクセスさせる必要はありません。

• 「念のため」という理由で参照データを追加するのは避ける：余計なページ、データベース、あるいはチャンネルを追加するたびに、エージェントが仕分ける情報の幅が広がってしまいます。普段からあまり役に立つ答えが載っていないリソースは、思い切って対象から外してください。

• エージェントの読み込み範囲に関連性のないトピックが多く含まれていると感じる場合は、焦点を絞った2つのエージェントに分割する：「プロダクトに関する質問」と「請求に関する問い合わせ」の両方を1台のエージェントでこなそうとするのは二足の草鞋を履かせるようなものです。読みとり範囲を狭く絞ったエージェントを2台用意した方が、それぞれからより優れた成果を得ることができます。

「Product Scout」の読み取り範囲を、製品ローンチ用データベースとSlackの#product-questionsチャンネル内の履歴だけに限定したことで、エージェントが情報を探しに行く場所をはっきりさせることができました。これにより、余計な情報の仕分けが減り、毎回ブレずに一貫した回答を出してくれるようになりました。

最初から完璧な指示を出せなくても問題ありません。指示の出し方を改善する一番の近道は、カスタムエージェントに「良くない」出力の例をいくつか見せて、どう書き直せばいいかアドバイスを求めることです。

シンプルなワークフローはこちら。

• 「長すぎる」「的外れ」「間違っているのに自信満々」といった、実際の良くない例を3〜5個集めます。

• エージェントに「何が原因でそうなったのか」と問いかける：参照範囲が広すぎたのか、回答するタイミングのルールが曖昧だったのか、など。

• 範囲内とする質問の種類、「これには答えない」というルール、あるいは回答テンプレートなどを盛り込んだ、指示文の改善案をエージェントに提案させます。

• 先ほどの同じ例でこの新しい指示文を検証し、問題を解決できる「最小限の修正」を採用します。

例えば、「Product Scout」が関係のない人事書類から情報を引っ張ってきてしまった場合は、その回答を貼り付けて、次のように尋ねます：「この回答は製品ローンチ外のページを参照しています。このミスを防ぐには、指示文をどのように更新すべきですか？」するとエージェントは、「製品ローンチ用データベース内のページのみを参照する」といった線引きルールを追加するよう提案してくるかもしれません。

このフィードバックを繰り返すごとに足りないものが浮き彫りになり、指示の精度がどんどん洗練されていきます。

「Product Scout」の初期の指示文は大雑把なものでした：「ワークスペース内のコンテンツを使って、プロダクトに関する質問に答えてください」。何度かテストとフィードバックを重ねた結果、その指示文はここまで具体的になりました：「製品の仕様書とSlackの履歴を使って回答してください。ドキュメント内に回答が見つからなければ、そう言ってください。回答は3段落以内にまとめてください」。

エージェントをチーム全体で実装する前に、設定ページの上部にあるエージェントを実行をクリックして、まずはその動作を自分でテストしましょう。チームのメンバーが実際に聞きそうな質問を投げかけてみて、どのような回答が返ってくるかを確認します。

インサイト機能を使用すると、カスタムエージェントの作成者や管理者は、エージェントごとのコスト、パフォーマンス、利用状況を正確に把握できます。最もコストがかかっている実行内容を特定したり、加えた変更が効果を発揮しているかを確認したり、どの失敗を優先的に修正すべきかを判断したりできます。

インサイトダッシュボードには2つのビューがあります。

• 「チャート」では、コスト、パフォーマンス、導入状況の経時的な推移を確認できます。

• 「すべてのチャット」では、エージェントのアクティビティを詳細に確認できます。これには、ステータス、トリガー、クレジットポイント使用量、実行回数、使用モデルなどが含まれます。

インサイトを活用する方法をご紹介します。

• 反復しながらコストとパフォーマンスを測定する：実行ごとのクレジットポイント消費量を確認し、指示、モデル、トリガーのいずれかを調整してから、結果を時系列で比較します。このフィードバックループを強化することで、変更が実際に効果をもたらしたかどうかを判断できます。

• 利用コストの高いエージェントを最適化する：クレジットダッシュボードから利用コストが最も高いエージェントを特定します。次に「すべてのチャット」ビューを使用して、コストがかかっている実行内容や、繰り返し発生しているパターンを明らかにします。主な改善策としては、対象範囲を絞り込むことや、タスクにより適したモデルを選択することが挙げられます。

• 失敗した実行のトラブルシューティングを迅速化する：実行が失敗した場合、インサイトは特定のツール呼び出しや権限／権限管理の不足といった原因を即座に特定します。根本的な原因を一度修正しておけば、同じ失敗が再発するのを防ぐことができます。

別のエージェントを使用した場合のイメージを確認したいという方は、こちらの実演動画をご視聴ください。

優れたカスタムエージェントは、時間をかけて育てていくものです。ちょっとした微調整を重ねていくだけで、やがてエラーが減り、出力のムラもなくなり、コストパフォーマンスの良いエージェントへと仕上がっていきます。