カスタムエージェントを改善するためのベストプラクティス
エージェントのモデル、トリガー、適用範囲、そして指示を最適化することで、優れた成果と高いコストパフォーマンスを両立させる方法をご紹介します。

エージェントのパフォーマンスは、「ベースとなるモデル」「トリガーと適用範囲の設定」「指示の出し方」の3つで決まります。どれか1つを見直すだけでも、エラーが減って出力のムラもなくなり、コストパフォーマンスも良くなります。
本ガイドでは、以下のような設定・調整のコツを順に解説していきます。
タスクに応じたモデルの選択
エージェントのトリガーと適用範囲の制御
エージェントを活用したデバッグと最適化

カスタムエージェントの作成が初めての方へ
本ガイドは、すでに稼働中のエージェントを対象としています。1台も作成したことがない方は、最初に「初めてのカスタムエージェントを作成する」をご覧いただくことをおすすめします。
「Product Scout」は、社内のプロダクトに関する質問に答えるカスタムエージェントです。彼の仕事は、ドキュメントや過去のやり取りからサクッと情報を探し出し、「機能Xって一括エクスポートできる?」といった質問にすぐさま正確に答え、チームを助けることです。

現在の設定では、Slackチャンネル内のすべてのメッセージをトリガーに作動し、ワークスペース全体を検索範囲とし、最もパワフルなスペックのモデルで稼働しています。動作自体に問題はありませんが、3つの課題が見えてきました。「回答にムラがある」「必要以上に頻繁に実行されている」「コストをもっと抑えられる」という点です。本ガイドでは、このエージェントを具体例として使いながら、各設定を調整することで実際の動作がどのように変わるかを実証していきます。
Notionではカスタムエージェントのベースモデルを自由に選択できます。そして、どのモデルを選ぶかが、コストを大きく左右する大きな要因の一つとなります。とにかく一番パワフルなモデルを選べばいいというわけではなく、自分が求めるクオリティの成果をブレずに毎回出してくれる、ちょうどいいモデルを見つけることが大切です。
モデルを選択する際は、モデルピッカー内の各オプションにカーソルを合わせることで、処理スピード、賢さ、コストを比較できます。
モデル選びの基準は以下のとおりです。
「Auto」を選択すると、Notionがリクエストに応じて最適なモデルを自動で選択します。ほとんどのエージェントのデフォルト設定として推奨されています。
「Lightweight」モデルは、定型文の下書き、届いた案件の簡単な自動振り分けや優先順位付け、構造化されたコンテンツの生成など、繰り返し発生する重要度の低いワークフローで真価を発揮します。複雑な推論よりも、処理速度、一貫性、コスト効率が重視される場合に最適です。
「Powerful」モデル(Opusなど)は、ニュアンス豊かな文章作成、複雑な推論、あるいは高い正確性が求められるタスクに最適です。ただし、その分1回の実行に消費されるクレジットポイントは多くなります。
まずは複数のモデルを実際に動かしてみて、どれが求める品質基準を安定してクリアできるか見極めてください。もしタスクが複雑になって、回答の質が落ちてきたと感じたら、いつでもよりパワフルなモデルに切り替えることができます。
サンプルエージェントの「Product Scout」も、最初は一番パワフルなモデルで稼働していました。ですが、「関係のある資料を見つけてきてまとめる」という彼の基本業務には、そこまで高度な思考力は必要ありませんでした。そのため、「Lightweight」モデルに切り替えた結果、回答のクオリティはそのままに、運用コストだけを抑えることができました。
エージェントのトリガーと適用範囲は連動しています。トリガーが起動するタイミングを決め、適用範囲が読み込むデータを決める仕組みです。どちらの設定も広すぎると、関係のない的外れな回答が増え、無駄にクレジットポイントがどんどん消費されてしまいます。
起動するタイミングを絞り込む
「実用的な頻度で、なおかつ必要な時にだけピンポイントで起動する」という絶妙な絞り込みが、理想的なトリガーの条件です。エージェントは起動するたびに、何の処理も行われなかったとしても、毎回クレジットポイントを消費します。そのため、実際にエージェントの手を借りたいタイミングだけに的を絞ることが大切です。
サンプルの「Product Scout」は、#product-questionsチャンネル内の返信やリアクション、「ありがとう!」といった単なる挨拶を含むすべての発言に対して起動する設定になっていました。つまり、有益な回答を出さない空振りの実行にクレジットポイントを無駄遣いしている状態でした。
まずは、エージェントの出番を定義することから始めましょう。
どんな質問に対して回答させるのか?対象とする質問の種類をあらかじめ狭く絞り込んでおき、具体例をいくつか書き出しておくのがコツです。
どんなメッセージをスルーすべきか?絵文字のリアクション、「ありがとう」などの挨拶、雑談、本題からズレたメッセージなどは、起動の対象外にする必要があります。
こうした線引きが決まれば、それに合わせてトリガーの条件をチューニングします。例えば、@mentionされたときだけに限定したり、キーワードでフィルタリングしたり、すべての編集に反応させたりするのではなく、特定のプロパティが変更されたときだけ起動するように制限します。
「Product Scout」の場合で言うと、トリガーを@mentions限定に変更すると、質問を投げかけた時にだけ実行されるようになります。
読み込む情報を絞り込む
エージェントは、アクセス権を与えられたすべてのコンテンツを読み込みます。その範囲が広すぎると、大量の無関係な情報を選別する羽目になり、出力の質が低下してしまいます。
「Product Scout」は、ワークスペース全体だけでなく、繋がっているすべてのツール(マーケティングページ、人事書類、過去の議事録、無関係なチャンネル内の数か月分に及ぶSlack履歴など)をすべて検索していました。プロダクトに関する答えが見つかるはずもないのに、エージェントは律儀にすべてを読み込んでいたのです。その結果、無駄な情報がまじり、回答にムラが出ていました。
エージェントの「読み込み範囲」をどう決めるべきか、その考え方のコツをまとめました。
まずは、求める答えが「どこにあるのか」を特定することから始めます。プロダクトに関する質問に答えるエージェントなら、プロダクトの仕様書や関連するSlackチャンネルのみに接続し、ワークスペース全体や各連携ツールにまでアクセスさせる必要はありません。
「念のため」という理由で参照データを追加するのは避けましょう。余計なページ、データベース、あるいはチャンネルを追加するたびに、エージェントが仕分ける情報の幅が広がってしまいます。普段からあまり役に立つ答えが載っていないリソースは、思い切って対象から外してください。
エージェントの読み込み範囲に関連性のないトピックが多く含まれていると感じる場合は、いっそ2台に分けてしまいましょう。「プロダクトに関する質問」と「請求に関する問い合わせ」の両方を1台のエージェントでこなそうとするのは二足の草鞋を履かせるようなものです。読みとり範囲を狭く絞ったエージェントを2台用意した方が、それぞれからより優れた成果を得ることができます。
「Product Scout」の読み取り範囲を、製品ローンチ用データベースとSlackの#product-questionsチャンネル内の履歴だけに限定したことで、エージェントが情報を探しに行く場所をはっきりさせることができました。これにより、余計な情報の仕分けが減り、毎回ブレずに一貫した回答を出してくれるようになったのです。
最初から完璧な指示を出せなくても問題ありません。指示の出し方を改善する一番の近道は、カスタムエージェントに「良くない」出力の例をいくつか見せて、どう書き直せばいいかアドバイスを求めることです。

シンプルなワークフローはこちら。
「長すぎる」「的外れ」「間違っているのに自信満々」といった、実際の良くない例を3〜5個集めます。
エージェントに「何が原因でそうなったのか」と問いかけます(参照範囲が広すぎたのか、回答するタイミングのルールが曖昧だったのか、など)。
範囲内とする質問の種類、「これには答えない」というルール、あるいは回答テンプレートなどを盛り込んだ、指示文の改善案をエージェントに提案させます。
先ほどの同じ例でこの新しい指示文を検証し、問題を解決できる「最小限の修正」を採用します。
例えば、「Product Scout」が関係のない人事書類から情報を引っ張ってきてしまった場合は、その回答を貼り付けて、「この回答は製品ローンチ外のページを参照しています。このミスを防ぐには、指示文をどのように更新すべきですか?」と問いかけてみてください。するとエージェントは、「製品ローンチ用データベース内のページのみを参照してください」といった線引きルールを追加するよう提案してくるでしょう。
このラリーを繰り返すごとに足りないものが浮き彫りになり、指示の精度がどんどん洗練されていきます。
「Product Scout」の初期の指示文は、「ワークスペース内のコンテンツを使って、プロダクトに関する質問に答えてください」という大雑把なものでした。何度かテストとフィードバックを重ねた結果、その指示文はここまで具体的になりました:「製品の仕様書とSlackの履歴を使って回答してください。ドキュメント内に回答が見つからなければ、そう言ってください。回答は3段落以内にまとめてください」
エージェントをチーム全体で実装する前に、設定ページの上部にあるエージェントを実行(Run agent)をクリックして、まずはその動作をご自身でテストしてみてください。チームのメンバーが実際に聞きそうな質問を投げかけてみて、どのような回答が返ってくるかを確認します。
別のエージェントを使用した場合のイメージを確認したいという方は、こちらの実演動画をご視聴ください。
優れたカスタムエージェントは、時間をかけて育てていくものです。ちょっとした微調整を重ねていくだけで、やがてエラーが減り、出力のムラもなくなり、コストパフォーマンスの良いエージェントへと仕上がっていきます。

関連情報
カスタムエージェントの概要と設定方法について学ぶ
クレジットポイントの仕組みと1回の実行にかかるコストについて把握する
管理者向けガイドを活用して、エージェントのアクセス権と実装を管理する
何か他にご質問はありますか?