これまでのエージェントは、人が質問や指示をしてから動き出す「待つ」存在として使われることが多くありました。一方、チケットの作成、文書の更新、メールの到着といった業務上の出来事をきっかけにすれば、必要な情報を集め、整理し、次の対応につなげるエージェントを設計できます。

Gleanのエージェントでは、この仕事の始まりとなる出来事を「トリガー」として設定できます。

トリガーとは、エージェントをいつ動かすか、最初にどの情報を渡すかを決める仕組みです。Gleanでは、ユーザーがメッセージを送る、フォームに必要事項を入力する、接続先のコンテンツが更新される、といった始め方が推奨されています。

本記事では、イベントをきっかけに動く「反応する」エージェントの考え方を、サポートチケット、サポートメールを例にご紹介します。イベントトリガーの設計、Gleanでの構築方法、段階的な自動化の進め方に加え、権限管理や人による確認といった、安全に運用するためのポイントも取り上げます。

トリガーイベントとは何か

エージェントは、指示、参照する情報、利用できるツールを組み合わせて仕事を進める仕組みです。
ただし、どれだけよい指示を書いても、いつ動かすかが決まっていなければ、必要な場面で使いにくくなります。

そこで役立つのがトリガーです。トリガーは、言い換えると「エージェントの開始ベル」です。
開始ベルをユーザー自身が鳴らすのか、決まった時刻に鳴らすのか、接続しているツールで何かが起きたときに鳴らすのかを選びます。

トリガーを設定しない場合は、必要な人がエージェントを開き、手動で実行します。一方、トリガーを設定すると、条件に合うタイミングで自動実行する設計ができます。
Gleanでは、トリガーは実行のタイミングを定義するものであり、手動開始、予定時刻、外部コンテンツやシステムの更新が起点になり得るとされています。

ここで大切なのは、トリガーは「何をするか」ではなく「いつ始めるか」を決めるものだという点です。
たとえば「問い合わせを要約する」はエージェントにさせたい処理です。「新しい問い合わせが登録されたら」はトリガーです。この二つを分けて考えると、設計が整理しやすくなります。

コンテンツトリガーは何をきっかけにできるのか

この記事では、手動実行やスケジュール実行ではなく、接続先の情報が変化したときに動く「コンテンツトリガー」に焦点を当てます。

起点となったコンテンツは、エージェントに入力として渡されます。この仕組みを「接続しているツールで何かが起きたら、自動で処理する」という考え方で説明していきます。

利用例の多いイベント

主なイベントは次のとおりです。利用可否は、接続状況や管理者設定によって異なるため、ご利用の環境で要確認です。

上記のイベントと、プロジェクト、優先度、担当者、送信者、ラベルなどの条件を組み合わせることで、対象を絞れます。たとえばJiraでは、チケットの種類、プロジェクト、ステータス、優先度などを条件にできます。

「作成」「更新」「条件一致」の違い

同じチケットを扱う場合でも、いつ動かすかで結果が変わります。

「新規作成」は、チケットが作られた時点で実行します。
「更新」は、選んだ項目が変わるたびに実行します。
「条件一致」は、優先度やステータスなどが指定の状態になった時点で実行します。

たとえば、担当者や優先度が後から設定される運用なら、新規作成を起点にすると必要な情報がそろわない場合があります。そのときは、「優先度が高い状態になったら」のように条件一致を使う選択肢があります。

サポートチケットで考える、コンテンツトリガーのユースケース

サポートチケットは、内容の確認、類似事例の参照、担当者への引き継ぎなど、複数の確認作業が発生しやすい対象です。ここでは、チケットの作成や条件一致をきっかけにする場合を例に、段階的な使い方を考えます。

重要なのは、最初からすべてを自動化しないことです。

第1段階では、人が確認できる要約を作るだけにし、期待どおりの情報が渡るかを見ます。次に、検索結果や下書きの品質を確認しながら、対象や出力形式を整えます。通知や更新のように影響が広がる処理は、運用ルールと権限を確認してから追加します。

コンテンツトリガーは「条件」を絞ることが出発点

コンテンツトリガーを考えるときは、「何か更新されたら全部動かす」ではなく、「どんな時にだけ動かすか」を決めることが重要です。対象が広すぎると、意図しない実行が増えたり、確認すべき結果が多くなったりします。

トリガーには、少なくとも一つのフィルターを設定することが推奨されています。

たとえば、チケットであればプロジェクトや優先度、メールであれば送信者やラベルといった条件で対象を絞る考え方です。対象を絞らないトリガーは実行回数の上限に達しやすく、不要な結果を生みやすいことが案内されています。

条件を決めるときは、次の三つを順に考えると整理しやすくなります。

たとえば「チケットが作成されたら要約する」という案を考えてみましょう。

このままでは対象が広すぎるかもしれません。そこで「特定のプロジェクトで」「優先度が高い場合に」「担当チーム向けの確認メモを作る」と分けて考えると、対象と出力が明確になります。

一方で、作成時点では必要な項目がまだ入っていないこともあります。この場合、新規作成を起点にするより、必要な条件を満たした時点を起点にする方が合う場合があります。

公式の説明でも、新規作成時には条件をすべて満たしている必要があり、後から項目が更新される可能性がある場合は「条件を満たしたとき」のイベントを検討するよう案内されています。

ユースケース：メールの件名を起点に、社内情報を検索して返信文の下書きを作る

メールの新着をトリガーにし、件名に特定の文字列が含まれている場合だけエージェントを実行します。

受信メールの件名・本文・送信者などをもとに、社内文書、過去の対応履歴、FAQ、手順書を検索し、検索結果を参考に返信文の下書きを作成します。メールの送信は自動化せず、担当者が内容と参照情報を確認してから送信する設計です。

トリガーを設計するときの、無理のない進め方

トリガーを活用したエージェントは、いきなり広い業務に適用するより、小さな範囲で試す方が設計しやすくなります。次の流れを一つの目安にしてください。

1．繰り返している「開始の合図」を探す

まず、日常業務の中から「これが起きたら、いつも同じ確認をしている」という場面を探します。新しい問い合わせの到着、チケットの状態変更、会議の開始前などが候補です。

ここでは、作業量の大きさだけで選ぶ必要はありません。何をきっかけに、誰が、どの情報を確認しているかを言葉にできる仕事の方が、最初のテーマとして扱いやすいからです。

2．出力を一つに絞る

次に、エージェントに最初に出してほしい結果を一つ決めます。「要約」「確認項目の一覧」「返信文の下書き」のように、利用者が確認しやすい形にします。

最初から検索、分析、更新、通知までを一度に設計すると、想定外の動きがあったときに原因を追いにくくなります。まずは、トリガーで渡された情報を使って、確認可能な成果物を作るところまでにすると、試行しやすくなります。

3．条件を少なく、具体的にする

条件は、最初から複雑にしすぎないことが大切です。対象のプロジェクトを一つにする、特定のラベルを付けたものにするなど、実際に確認できる条件から始めます。

条件が多すぎると、なぜ実行されなかったのか判断しにくくなります。反対に、条件が少なすぎると不要な実行が増えます。まずは少量の実例で動きを確認し、必要に応じて条件を追加する方法が現実的です。

4．サンプルで試し、人が結果を確認する

公開前には、想定したイベントを使って試します。Gleanでは、保存・公開前にサンプルイベントでトリガーの種類や条件を確認し、起点となった情報が期待どおりに渡るかをテストできます。

この段階で見るのは、文章の自然さだけではありません。「必要なときだけ動いたか」「渡された情報は期待どおりか」「出力を次の担当者が判断に使えるか」も確認します。実際の業務で起こり得る例をいくつか用意しておくと、確認しやすくなります。

まとめ

トリガーは「仕事を始める条件」を整える仕組み

Gleanのエージェントにおけるトリガーイベントは、エージェントを便利にするための特別な設定ではなく、「この仕事は、いつ始めるべきか」を明確にするための仕組です。

手動実行、フォーム、コンテンツ更新、スケジュールには、それぞれ向いている場面があります。まずは、人が判断しながら進めたい仕事なのか、必要事項をそろえて始めたい仕事なのか、何かの更新に合わせたい仕事なのかを考えてみてください。

コンテンツトリガーを使う場合は、対象を絞ることが重要です。どの情報を見張り、どの条件で、どんな出力を作るのかを小さく決め、サンプルで動きを確認します。そのうえで、出力の内容や実行範囲を少しずつ見直していくと、業務に合わせた使い方を検討しやすくなります。

「何を自動化するか」から考え始めるのではなく、「いつ、何が起きたら、この確認が必要になるか」から始める。トリガーは、その問いを具体的な仕組みに変える入口です。