AI エージェントスタジオで AI エージェントを作る手順（読み取り専用の検索エージェント）

自分の ServiceNow に AI の機能を足したいとき、最初に迷うのは「何を作ればよいのか」です。標準の Now Assist スキルで足りない動きは、AI エージェントとして作れます。この記事では、インシデントの症状から関連ナレッジと解決済みの類似インシデントを探すエージェントを、AI エージェントスタジオで作りました。

症状の文章を渡すと、エージェントは2つの検索を続けて呼び、類似インシデント2件を返しました。番号だけを渡した1回目は、検索せずに聞き返して止まっています。トリガーもチャネルも付けず、スタジオのテスト画面だけで動かしました。作成から実行、後片付けまでの操作と、途中で止まった箇所を順に書きます。

この記事で作るもの

• 名前は「記事検証 関連情報の検索エージェント」。読み取りだけを行う AI エージェント1つ

• ツールは2つ。ナレッジ記事の検索と、解決済みインシデントの検索

• 動かす場所はスタジオの手動テスト。トリガーとチャネルは付けない

• 自作すると何が変わるかを、標準の機能と比べて判断する材料にする

試したのは1つのエージェント、実行は2回です。OOTB の機能全体を評価する記事ではなく、作る手順と詰まりやすい箇所を残す目的で書いています。

自作が必要になるのは、標準の機能で足りないときだけ

先に決めるのは、そもそも作る必要があるかどうかです。ServiceNow には、作る前に確認できる標準の選択肢が3つあります。

起点は標準の AI エージェント、青は作る前に確認する標準の選択肢、濃い青は今回選んだ自作

図の内容を文字でも書き出します。

• 標準の AI エージェント（OOTB）：インシデントの調査や要約など、あらかじめ用意された動きをそのまま使う。設定の変更だけで足りることが多い

• Now Assist スキル：要約や文面生成のように、入力を渡して1回の生成結果を受け取る機能。複数の検索や判断を組み合わせない用途に向く

• AI エージェント：複数のツールを使い分けて調べ、結果をまとめる。標準にない組み合わせが必要なときの作り方

今回の依頼は「関連ナレッジと類似インシデントを探して、理由つきで並べる」です。検索を2種類まとめて頼むため、エージェントとして作りました。1種類の検索だけなら、標準のスキルや標準のエージェントが先に候補になります。

作る前に、標準の機能にないかを確かめる

作る前の確認は、スタジオの画面だけで終わります。

1. AI エージェントスタジオの［作成と管理］を開き、［エージェント型ワークフロー］タブの一覧で、やりたいことに近い名前と説明のワークフローを探す。この環境では188件が並んでいた

2. 近いものがあれば、説明の文章を読み、入力と出力が足りているかを見る

3. 足りない部分が小さければ、複製して直す。複製したワークフローは、トリガーが非アクティブの状態で作られる

4. 足りない部分が大きいか、組み合わせが標準にないときに、新規作成に進む

3の複製は、公式のドキュメントにも載っている手順です。新規作成のあとで標準の機能が見つかると、同じ役割のエージェントが2つ残り、LLM が選び間違えます。保存のときに出る重複確認の画面は、この選び間違いの手前で気づける最後の機会です。

検索の元になった相談の中身

試す前に、元になるインシデントを説明します。検証用に作った日本語の INC0019384 は、経費精算システムで申請を送信すると、送信時に「E-5031」のエラーが出る相談です。経理部の社員が起票し、別端末でも同じ症状が出ています。作業メモには、ブラウザのキャッシュ削除が効かなかったこと、承認者マスタに異動前の承認者が残っていたことが書かれています。

検索の相手になる解決済みインシデントは2件用意しています。人事部の社員から届いた出張費申請の E-5031 エラーと、組織変更の翌日から同じエラーが出た事例です。どちらも原因は承認者マスタでした。公開済みのナレッジ記事は、「E-5031」でも「経費精算」でも検索して0件でした。つまり正しい答えは、「ナレッジは該当なし、類似インシデントは2件」です。

STEP1：【管理者】ワークフローの名前と説明を決める

AI エージェントは、エージェント型ワークフローの中に入れて使います。「AI エージェントスタジオ」を開き、［作成と管理］の［エージェント型ワークフロー］タブで［新規］を押すと、ガイド付きセットアップが始まります。

①の名前は「記事検証 関連情報の検索」にしました。②の説明は、どんな依頼のときにこのワークフローを使うかを書く欄です。「読み取りだけで提示する」「更新や通知は行わない」と明記しました。この文は、LLM が複数のワークフローから選ぶときの手がかりになります。

• 開始条件：ロール sn_aia.admin を持つ管理者であること

• 期待結果：名前と説明の入力が済み、［保存して続行］が押せる

• 中止条件：既存のワークフローと名前が重なるときは、名前を変える

STEP2：【管理者】AI エージェントの新規作成を開く

ステップのリストを書いたあと、［AI エージェントを追加］の横にある［More Actions］から［AI エージェントの新規作成］を選びます。名前・説明・ロール・ステップを入力し、［保存して続行］を押すと、「重複の可能性が見つかりました」という画面が出ます。

既存のインシデント向けエージェント5件が候補に挙がりました。説明が似ていて構成が違うと、LLM が選び間違える恐れがあるという案内です。今回は読み取り専用で検索を2つ持つ構成にしたため、違いを確認して［無視して続行］を押しました。

• 開始条件：エージェントの名前と説明が入力済み

• 期待結果：ツールを追加する画面に進む

• 中止条件：既存エージェントと役割が同じなら、作らずに既存の設定変更を検討する

STEP3：【管理者】ツールを2つ足す

エージェントにできることは、持たせるツールで決まります。［ツールを追加］を開くと、13種類の選択肢が出ました。

13種類は、役割で次のように分けられます。

• 外部とつなぐもの：MCP サーバーツール、Web 検索、デスクトップアクション

• ServiceNow の既存部品を呼ぶもの：Now Assist スキル、サブフロー、フローアクション、スクリプト、カタログアイテム、会話のトピック

• 情報を引くもの：ナレッジグラフ、検索取得、ファイルのアップロード

• 記録を扱うもの：レコード操作

今回は③の［検索取得］を選びました。②のレコード操作は、書き込みにも使える種類です。書き込みを足す手順は別の記事に書いています。

検索取得のツールで入れる項目は、名前・説明・検索プロファイル・検索条件・結果制限・実行モードの6つです。

①の検索条件は、今回はキーワードにしました。結果制限は5です。②の実行モードは、読み取りだけのツールなので［自律］にしました。承認を挟む［監視中］は、書き込むツール向けの設定です。

• 1つ目：名前「関連ナレッジ記事を検索」。検索プロファイルは「Similar KB Articles」

• 2つ目：名前「解決済みの類似インシデントを検索」。検索プロファイルは「Similar Resolved Incidents」

• 開始条件：検索プロファイルが、対象のテーブルを検索できる状態

• 期待結果：ツールが2行並び、実行モードの列に Autonomous と表示される

• 中止条件：検索プロファイルの選択肢に目的のものが無いときは、検索設定を持つ管理者に確認する

STEP4：【管理者】アクセスを決め、トリガーとチャネルは付けない

次に、誰がこのエージェントを呼べるかを決めます。ユーザーアクセスは「特定のロールを持つユーザー」で itil を選びました。データアクセスは、呼び出したユーザーの権限で動く「動的ユーザー」です。

トリガーは付けません。トリガーを付けると、インシデントの登録や更新のたびに動き出します。共用のデモ環境で試すため、［トリガーを追加しない］まま進めました。チャネルも、Now Assist パネルと仮想エージェントの両方を許可していません。

• 開始条件：ツールの追加が済んでいる

• 期待結果：エージェントとワークフローの両方で、ユーザーアクセス・データアクセス・トリガー・チャネルの画面を通過し、［保存してテスト］が出る

• 中止条件：トリガーやチャネルを許可する操作は行わない。許可すると、他の利用者の画面や定期処理に影響する

STEP5：【管理者】スタジオのテストで動かす

［保存してテスト］を押すと、手動テストの画面が開きます。テストの種類は「AI エージェントまたはワークフロー」です。

最初の実行では、タスクを「INC0019384 の件名と説明をもとに探してください」としました。エージェントは検索に進まず、「件名・説明・状態をご提供ください」と入力を求めて止まりました。インシデントを番号で取得するツールを持たせていないため、番号だけでは症状が分かりません。2回目は、タスクに症状の文章を直接書きました。

実行ログを見ると、エージェントは検索語を「経費精算システム 申請送信 E-5031 エラー」に組み立て、2つのツールを続けて呼んでいます。

①の結果は、先に説明した正解と一致しました。ナレッジは「該当なし」で、類似インシデントは人事部の出張費申請と、組織変更後の事例の2件です。ただし、タスクで頼んだ番号は結果に出ず、件名だけが並びました。番号まで必要な場合は、ロールのステップに「番号を必ず書く」と入れる、結果の項目に番号を含めるなどの調整が要ります。

• 開始条件：タスクに、検索に使える症状の文章が含まれている

• 期待結果：ログに2つのツール呼び出しが並び、結果に該当なしか候補が出る

• 中止条件：入力を求めて止まったら、足りない情報をタスクに足して実行し直す

• 実行時間：生成の各ステップは、ログの Time 値で約12〜14秒だった

STEP6：【管理者】記録が動いていないことを確かめて片付ける

確認する項目と方法は、次のとおりです。

• インシデントの更新回数：対象のインシデント INC0019384 を一覧で開き、更新数の列を実行の前後で見比べる。管理者の権限なら、REST で incident テーブルの sys_mod_count を番号で絞って取得してもよい。今回は8のまま不変だった

• 作業メモとコメント：フォームのアクティビティに、実行の時刻以降の追記がないこと

• メール：sys_email テーブルを、実行の時刻以降の作成日時で絞り、対象の番号や今回の作成物に結びつく行がないこと。今回は0件

最初の1回は、入力待ちのまま止まっていました。この実行も含めて、今回作ったワークフロー・エージェント・実行の記録を、証跡の画面を保存したあとに削除します。削除は管理者の権限で、一覧の画面か REST の DELETE で行いました。確認は「今回作成したレコードの sys_id で絞った残りの件数が0」です。共用の環境では、テーブル全体の件数を0にする必要はなく、してはいけません。

ロールとステップには、入力の取り方と出力の形を書く

エージェントの動きを決めるのは、ロールとステップのリストに書いた文章です。今回の結果から、次の内容を書いておく必要があると分かりました。

• 何を入力として受け取るか。今回の1回目は、ステップ1に「件名・説明・状態を取得する」と書いたのに、取得するツールがありませんでした。2回目の実行では、タスクの文章に症状を書いて動かしました

• 何を何回探すか。ナレッジと類似インシデントを、それぞれ1回ずつ探す

• 出力にどの項目を含めるか。ロールには「番号・件名・該当理由」と書きましたが、結果に出たのは件名と理由だけでした

番号が出なかった原因は、特定できていません。ロールの指示が足りなかったのか、検索ツールの返却値に番号が含まれていなかったのかを、ログの生の出力で切り分ける必要があります。ツールの返却値に番号があるのに出力に出ていないなら、ロールの出力指示を直します。番号が返却値に無ければ、検索プロファイルが返す項目の側の問題です。

ステップの文章は、「探す」「確認する」「提示する」のような動詞で始めると、実行ログのどのステップに対応するかが追いやすくなります。

実行ログの読み方

テスト画面は3つの領域に分かれます。左がエージェントとのやり取り、中央が処理の流れを示す図、右が意思決定ログです。2回目の実行では、ログに次の順で並びました。

起点はアクセス検証、橙は生成 AI の呼び出しが並ぶ手順、青は権限の確認と結果の表示

図の内容を文字でも書き出します。

1. アクセス検証：実行するユーザーに、ワークフローとエージェント、ツールを使う権限があるかの確認

2. オーケストレーター：どのエージェントに任せるかを決める生成 AI の呼び出し

3. 検索エージェント：生成 AI の呼び出しに続いて、2つのツールの呼び出しが並ぶ

4. コミュニケーター：結果を利用者に表示する

5. オーケストレーター：残りの作業がないことを確認して、実行を終える

生成 AI の呼び出しの行には、「高レイテンシ」の印が付いていました。このログでは、11〜14秒台のステップにこの印が付いていました。画面の遅さではなく、生成の待ち時間を示す表示と読み取れます。ログからは、検索語やツールに渡した入力も確認できるため、結果がおかしいときは最初にここを開きます。

実機で気づいたこと

番号だけを渡すと、エージェントは調べずに質問に戻る

INC0019384 の番号だけを書いたタスクでは、検索が1回も実行されませんでした。エージェントは「件名・説明・状態を教えてください」と聞き返しています。検索ツールは、渡された語で探すだけで、インシデントの中身は取りにいけません。番号だけで動かしたい場合は、インシデントを取得するツールを別に足します。

重複確認の画面で、既存のエージェントが5件見つかる

エージェントを保存する時点で、類似する既存エージェントが5件並びました。自作を足すと、LLM が選ぶ候補が増えます。説明の書き方で選ばれ方が変わるため、名前と説明は最後の確認項目として読み直します。

ナレッジの検索結果が空でも、エラーにはならない

ナレッジ検索は「No information found」を返し、エージェントはそれを「該当なし」と報告しました。結果が空でも、実行は成功として終わります。「なぜ見つからないのか」まで知りたいときは、検索プロファイルの対象が公開済みの記事に限られているかを確認します。

1回の依頼で、生成 AI は5回呼ばれた

成功した2回目の実行のログを数えると、生成 AI の呼び出しは5回ありました。オーケストレーターが2回、検索エージェントが3回です。ログの Time 値は、1回あたり11.6〜14.3秒でした。

画面に結果が出るまでの合計時間は、今回は計っていません。構成を変えたときに呼び出し回数がどう増減するかも、未検証です。この値をタイムアウトや中止の判断基準に使わないでください。1回ごとの利用量がどう数えられるかも確かめていないため、共用の環境で何度も試す前に、利用量の確認先を管理者に聞いておきます。

つまずいたときの切り分け

今回の2回の実行で出会った症状を、確認する順に並べます。

• 質問に戻って止まる：実行ログで、最後の応答が「入力をご提供ください」になっていないかを見る。なっていれば、検索に必要な文章がタスクに入っていない。症状の文章をタスクに足して、実行し直す

• 結果が「該当なし」になる：ログの検索語が、タスクの症状から組み立てられているかを見る。語が合っているのに0件なら、検索対象の側を確認する。今回は、公開済みナレッジを「E-5031」「経費精算」で検索して0件だったことだけを確かめた。検索プロファイルの対象外だったかどうかは、確かめていない

• ツールが呼ばれない：ログのツール呼び出しの行が空なら、ツールの名前と説明、ロールの文章を見直す候補になる。今回の1回目に限れば、原因はツールの選択ではなく、入力が足りなかったことだった

• 保存の時点で重複の確認が出る：既存のエージェントとの違いを、説明に1文で書く

どの症状でも、最初に開くのは実行ログです。止まった場所は、ログの最後の行にそのまま出ます。ログを見ずに説明やロールを書き直すと、原因が違う場合に何度も実行し直すことになり、そのたびに、1回に十数秒かかる生成 AI の呼び出しを待つことになります。

用語

• エージェント型ワークフロー：複数の AI エージェントをまとめて、1つの依頼に対応させる単位。スタジオ上では「ワークフロー」と略して呼ぶ

• AI エージェント：ロールとステップ、ツールを持ち、与えられたタスクを自分で組み立てて実行する部品

• ツール：エージェントが呼べる機能。検索取得、レコード操作、スクリプトなど13種類がある

• 実行モード：ツールを呼ぶときに、人の承認を挟むかの設定。自律と監視中がある

• 検索プロファイル：検索取得のツールが、どのテーブルのどの項目を検索するかを定めた設定

• 意思決定ログ：エージェントが選んだツールと入力、結果を、実行の順に並べた記録

検証範囲

• 作成したエージェントは1つで、実行は2回です。品質を統計的に評価した結果ではありません

• 検索結果の正しさは、用意した2件の解決済みインシデントと、公開済みナレッジを指定語で検索して0件だったという前提で確認しました

• ナレッジ記事が実在するときの検索結果は、今回は確かめていません

• トリガーでの自動実行、チャネルからの利用、他のユーザーの権限での実行は試していません

• 書き込むツールの追加と、承認の画面の確認は別の記事で扱います

• 作った記録は、確認のあとにすべて削除しています

ここまでが無料で読める範囲です。エージェントを1つ作って動かし、つまずいたときに実行ログから切り分けるところまでを、手順どおりに実行できる形にしました。

この先は、エージェントの定義をそのまま使える形で渡す一式で、約0.4万字あります。内容は次のとおりです。

• ツールの設定値：画面の入力が、どの値として保存されたかの対応

• 記入済みの定義：成功したタスクの全文と、ワークフローの説明・ロール・ステップのリスト

• 空欄のテンプレート：コピーして使う書式

• 値を変えるときの基準：変える4か所と、変え方

• ロールの改善案：番号を必ず出す版

• テストのチェックリスト：15項目

• 公式ドキュメントのURL：10件

💰 ここから先は有料エリア