Slack × Notionカスタムエージェントで、情シスの問い合わせ窓口に一次回答を任せてみた

こんにちは、運用支援チームのkeitaです。

社内の問い合わせ対応は、同じ質問が別の人から何度も届き、そのたびに担当者が過去のやり取りを探し直すという構造になりがちです。今回は、SlackとNotionカスタムエージェントを組み合わせて、この窓口に「一次回答」を任せる仕組みを作ってみました。

この記事では、設定、エージェントへの指示文、クレジット消費の3点について触れています。手順そのものは公式ヘルプでも追えますが、指示文の設計とコスト感は実際に作らないと見えてこない部分です。

作ってみて感じたのは、Notionカスタムエージェントは問い合わせ対応を完全自動化するものではなく、問い合わせを記録し、たまったナレッジを次の一次回答に活かすための仕組みとして使うのが現実的だということです。

難しかったのは機能を作ることよりも、対応内容をあとで使える社内ナレッジとしてどう残すかを決めることでした。

---

作ったもの

作ったものは2つです。

• カスタムエージェント：Slackの投稿を受け取り、記録と一次回答を行う
• 問い合わせDB：問い合わせの内容と対応履歴をためるNotionのデータベース

Slackは既存環境の設定だけで、新しく作るものはありません。

Slackの問い合わせチャンネルでスタンプを1つ押すか、エージェントをメンションすると、カスタムエージェントが次の3つを行います。

1. 問い合わせ内容をNotionの問い合わせDBにページとして記録する
2. 過去の解決済み事例とWebの公式情報を確認し、一次回答案をスレッドに返信する
3. 解決スタンプが押されたら、対応内容と結果を同じページに書き戻す

問い合わせ者はSlackから離れることなく確認ができ、担当者は、AIの一次回答で足りないものだけを引き取る対応だけになります。

処理の流れは次のとおりです。

1. Slackに質問を投稿し、一次回答用スタンプを押すか、エージェントをメンションする
2. カスタムエージェントが問い合わせDBへ内容を記録する
3. 過去の解決済み事例とWebの公式情報を確認する
4. 一次回答案をSlackのスレッドへ返信する
5. 解決用スタンプが押されたら、対応内容と解決結果を問い合わせDBへ書き戻す

起動のしかたとスタンプの役割

処理内容に差はなく、DBへの記録と一次回答の流れは同じです。

• スタンプ：すでに投稿されている質問にリアクションし、あとから一次回答を依頼する
• メンション：質問を投稿する時点でメンションを付け、その場で一次回答を受け取る

違いは事前設定だけです。

スタンプは用途ごとに2種類用意しました。

どの絵文字をそれぞれに割り当てるかは自由ですが、押す人が迷わないように、用途に沿った絵文字を使用するのがおすすめです。

ここから先の1から4で、この2つをどう作ったかを書きます。まずはカスタムエージェントからです。

---

1. カスタムエージェントを設定する

前提として必要なもの

管理者作業が前提になる項目があるため、検証を始める前に依頼しておくとつまずきません。

設定でやったこと

エージェントが持つSlack関連の能力は3種類

• トリガー：チャンネルへの新規メッセージ／メッセージへの絵文字リアクション／エージェントへのメンション
• 絞り込み：キーワードやフレーズの指定、スレッド返信を文脈に含める設定
• 出力：指定したチャンネルに限定したメッセージ・返信・更新の投稿

出典：Slack integration（Notion）、Notion and Slack Integration（Slack Marketplace）

今回はリアクショントリガーとメンショントリガーの2つを設定し、どちらでも同じ処理が動くことを実機で確認しました。スタンプを押しても、メンションで質問を投げても、DBへの記録と一次回答が返ってきます。使っていないのは新規メッセージトリガーだけで、これは雑談まで拾ってしまうためです。

起点ごとの違いは次のとおりです。

なお、リアクションは「トリガー」としてのみ提供されています。エージェント側からメッセージにスタンプを付ける動作は、公式ヘルプに記載がありません。

設定時に気をつけた点

• 特定のチャンネル内でのみ機能するようにする
• Bot自身の投稿には反応させない
• トリガー内の「その他の設定」を確認し、必要な機能が有効になっていることを確認する

  

  それぞれの役割は次のとおりです。

  • スレッド内のフォローアップメッセージを監視できるようにする：親投稿だけでなく、スレッド内の投稿にも反応させる
  • 絵文字のリアクションごとに複数回トリガーできるようにする：同じメッセージに対して、2回目以降のリアクションでも起動させる

---

2. カスタムエージェントの指示文を設計する

今回の機能構築を行う中で、一番時間をかけたのはここです。設定は公式ヘルプの範囲で終わりますが、回答の質と事故の起きにくさは指示文で決まります。

ここで出てくるプロパティ名は、次章の「問い合わせDBを設計する」で設計したものです。

過去事例の使わせ方

参照していい過去事例を2条件で絞る

問い合わせDBの中身は、正しい情報と、途中で放置された情報が混ざります。そのままAIに読ませると、解決していない対応を根拠として提示してしまいます。参照対象は次の2条件を満たすものだけに限定しました。

1. ステータスが「解決」
2. 人手確認済みがオン

加えて、「一次回答訂正あり」のプロパティを設けておくことで、この項目がオンのレコードは、訂正後の内容だけを根拠にさせます。

回答の表現も指定しています。過去事例は正式ルールではなく、過去に解決した1つのケースです。そのため回答では「過去にはこの対応で解決したようです」と書かせ、今回も解決すると断定させません。

類似事例の件数で参照先を切り替える

運用初期は、参照できる過去事例がほぼありません。「該当事例が見つかりませんでした」だけを返すエージェントでは、使われなくなるため類似する過去事例の件数による分岐を入れました。

Web確認では公式ヘルプ、公式ドキュメント、ベンダー公開情報を優先させています。

過去事例が3件未満のときは、Slackの返信内に「過去事例が少ないためWeb確認も併用しています」と明記させることで、事例が溜まるまでの期間もエージェントが役に立つように設計しました。

答えさせない領域を先に決める

情シスの問い合わせには、AIが答えると事故になる領域があります。指示文では最初にここを閉じるようにしています。

• アカウントの発行・停止・削除
• 権限付与・剥奪・管理者権限
• 請求、契約、料金、ライセンス数の判断
• 人事、労務、評価、個人情報を含む内容
• セキュリティインシデントの判断や封じ込め指示
• 過去事例だけでは根拠が弱い内容

これらは断定回答させず、参考情報の提示までに留めて担当者へエスカレーションさせます。

出力と記録のルール

返信フォーマットを固定する

自由に書かせると、長さと構成が毎回変わり、読み手が判断できません。返信は6項目の順序で固定しました。

1. 結論
2. 参照した過去問い合わせ
3. Webで確認した対応方法
4. 推奨する一次対応
5. 不足情報または確認事項
6. 担当者確認が必要な場合の注意

根拠リンクは必須です。Notionの参照元ページ、またはWeb確認で使った公式情報のURLを必ず添えさせます。

記録は逐語で残す

元のSlackメッセージは要約させず、逐語でDBに残します。要約はタイトルと回答案の補助にだけ使います。要約した記録は、後から読み返したときに判断材料が足りなくなります。

問い合わせページを作る条件と更新する条件を分ける

Slackの投稿を問い合わせとしてDBに新規記録する処理と、解決用スタンプが押されたスレッドに紐づく既存の問い合わせページを更新する処理は、明確に分けて指示しました。

ここが曖昧だと、解決時に新しいページが作られたり、別の問い合わせページを更新したりして、DBが汚れる原因になります。

検証例

今回検証したものの中で、どういう出力結果から指示文を変更するに至ったかの実例を挙げていきます。

• そもそもの一次回答のフォーマット
  • 今回こういうことをやりたいというプロンプトをAIに生成させ、そのまま使用してカスタムエージェントを作成した際、以下のような出力形式でした。

    

  • 使えはしますが、すべて同じフォントで読みにくいと感じました
• スタンプを押した場合と、メンションをした場合での出力の差分
  • 問い合わせの対応が完了した際に、メンションで「クローズして」と送った際に新規問い合わせの時の同じフォーマットでメッセージが送られました。

  

  • クローズするだけでここまでの分量のメッセージは不要です

これら以外にもDBとの兼ね合いからや、Slackへの出力結果などから指示文を複数回訂正しましたが、検証や修正も含めて1日かからず目的の機能を構築できました。

最終的な出力

• 一次回答

• クローズ

---

3. 問い合わせDBを設計する

次に、問い合わせを蓄積させるためのDBの用意です。

冒頭で書いた「一次回答に活かすための仕組み」を成立させるには、カスタムエージェントの指示文と同じぐらい、DBの設計は重要です。名前やカテゴリは後から直せますが、最初から埋めておかないと後で数字が出せない列が2つありました。

いつ埋めるのか

プロパティは、問い合わせのライフサイクルのどこで埋まるかで整理すると見通しが良くなります。図は左端の①から右へ、①→②→③→④の順に読みます。

問い合わせページの情報は、一度にすべて登録するのではなく、問い合わせの進行に合わせて更新します。

1. 起票時：問い合わせ内容、問い合わせ元URL、問い合わせ者などを記録
2. 一次回答時：一次回答案、不足情報、Next Actionを記録
3. 担当者の対応時：ステータスや一次回答の訂正有無を更新
4. 解決時：最終回答、対応内容、解決結果、人手確認済みを記録
5. 解決後：条件を満たしたページを、次の問い合わせにおける過去事例として参照

点線が示すとおり、解決したページはそのまま次の問い合わせの参照元になります。この循環が成立するかどうかが、プロパティ設計のすべてです。

押さえておきたいプロパティ

全部を並べても参考にならないので、設計の意図が入っている列だけを抜き出します。本文や回答を残す列は、後の「記録の粒度を分ける」で扱います。

最初の1件目から用意しておきたい2つ

• ステータス更新日：ステータスは現在の値しか持たないので、いつ動いたかが残らない
• 一次回答訂正あり：訂正したという事実は、その場で記録しないと残らない

どちらも途中から埋め始めることはできます。ただし過去分は戻せず、滞留日数と誤答率が測れません。最初から埋める前提で作っておくのが安全です。

設計で迷ったところ

ステータスは5段階に分けた

受付、一次回答済、対応中、待機中、解決の5段です。「一次回答済」と「対応中」を分けているのがポイントで、AIが返しただけの状態と、人が引き取った状態を区別できるようにしています。「一次回答済」から「対応中」または「待機中」への変更は、担当者が手で行います。この2つは、担当者が問い合わせを確認したかどうかを表すステータスだからです。

「わからない」を残す設計にする

• 不足情報：回答に必要だが足りていない情報。質問を返すときの根拠になる
• Next Action：担当者または質問者が次に取る行動。放置を防ぐ
• 緊急度の「未判定」：AIが判断できなかったことを積極的に残す選択肢

緊急度に「未判定」を用意するかどうかは、小さい差に見えて大きいです。選択肢が高・中・低だけだと、AIは判断できないケースでもどれかを選んでしまいます。空欄と「判断できなかった」は意味が違います。

記録の粒度を分ける

一次回答案と最終回答を別の列にしているのは、両方を比べることが目的です。同じ列に上書きすると、AIが最初に何と答えたのかが消えます。

さらに、スレッドを特定するために問い合わせ元URLを必須にしています。解決スタンプが押されたとき、エージェントはこのURLを突合して既存ページを探します。タイトルや本文の類似度で探すと、別の問い合わせを更新してしまうリスクがあります。

プロパティ設計で注意した点

• 問い合わせ者をユーザー型にする場合、Slackの投稿者とNotionユーザーを紐づける必要がある。特定できないケースの逃げ先を決めておく
• カテゴリに汎用分類とSaaS名を混在させると、同じ問い合わせが回によって違う分類に入る
• チェックボックスは未チェックと未入力を区別できない。参照対象の判定に使う列は、未チェックを「参照不可」として扱う前提を揃えておく

---

4. クレジットはどれくらい消費するのか

どれくらいかかるのか

前提

• カスタムエージェントの実行はクレジット消費の対象。単価は1,000クレジットあたり10米ドル（1クレジット＝0.01米ドル）
• 月次リセットで繰り越しなし。ワークスペース全体で1つのプールを共有する
• 円換算は1米ドル150円で計算

出典：Buy and track Notion credits for Custom Agents

目安

今回の一次回答は「1件読む → 問い合わせDBを検索する → スレッドに返信する」という流れです。一次回答だけで解決した10件程度を計測したところ、起票からクローズまでで1件あたりおよそ25クレジットでした。過去事例の検索、Web確認、DBへのページ作成、Slackへの返信と、1回で使うツールが多いことが理由だと考えられます。やり取りが続けば消費は増えるため、この25クレジットが最小の目安です。以下は、この値を前提にした規模感です。

月100件の問い合わせをすべてこの流れで処理すると、およそ3,800円。問い合わせ窓口の自動化として、コスト面が導入の障害になる規模ではないと感じました。

なお、これは一次回答だけで解決した場合の数字です。担当者とのやり取りが続いてスレッド内で何度もエージェントが動くと、1件あたりの消費はこれより増えます。

見落としやすいのは運用ではなく開発中の消費

想定より効いてくるのは、指示文を直すたびに評価セットを流し直す作業です。

30件の評価セットを10回の改訂で流すと、1件25クレジットで換算して7,500クレジット、約11,300円になります。月100件で運用する場合の3か月分に相当します。

対策はシンプルです。初期の反復は10件程度のサンプルで回し、30件のフル評価は改訂が落ち着いてから2〜3回だけ実施します。

消費を抑える設計

1. 参照範囲を解決済み・人手確認済みの事例に限定する
2. 「1エージェント1仕事」に分ける
3. モデルとEffortを上げすぎない
4. エージェント単位のクレジット上限を設定する

エージェント単位の上限は、1つのエージェントの使いすぎを防ぐための設定です。これとは別に、ワークスペース全体のクレジット使用量が80%と100%に達した時点で、管理者へ通知が届きます。クレジットが不足すると、エージェントは次の月次サービス日に自動停止します。

再開には管理者によるクレジットの購入とエージェントの再有効化が必要なため、停止に気づける仕組みを別途用意しておくことをおすすめします。

---

作ってみて感じたこと

向いている使い方

• 過去に解決したケースを根拠にした「一次回答案」の作成
• 記録がNotionに集まっている前提での、対応履歴の自動蓄積
• 質問者をSlackから離れさせない導線

向いていない使い方

• 正式ルールとしての断定回答
• 権限や請求など、判断責任を伴う回答
• 匿名での相談（Slack起点のため発言者が必ず特定される）

---

まとめ

• 設定は公式ヘルプの範囲で終わる。難所は指示文とDBの設計にある
• スタンプとメンションのどちらでも同じ処理が動く。違いは事前設定だけ
• 参照条件を2つに絞り、類似件数で参照先を切り替えると、事例が少ない立ち上げ期でも使える
• 過去分を戻せない列を最初に作っておくと、あとで数値で語れる
• 答えさせない領域を最初に決めることが、情シス用途では最優先
• クレジットは一次回答だけで解決した1件で約25クレジットを消費する。月100件なら約3,800円で、効いてくるのは開発中の評価ループ

導入を検討する場合は、本体を作り込む前に起動とスレッド返信が期待どおり動くかだけを先に確認することをおすすめします。ここが動けば、残りは指示文の改善に時間を使えます。