AI エージェントに書き込みツールを足す手順（Supervised で承認を挟む）

AI エージェントにインシデントの記録を書き換えさせたいとき、いちばん怖いのは「頼んだつもりのない書き込みが実行されること」です。ServiceNow の AI エージェントのツールには、実行の前に人へ承認を求める実行モード「Supervised」があります。この記事では、レコードを更新するツールを Supervised で足し、承認の画面が出るところまで動かしました。

エージェントは書き込む前に承認カードを出して止まり、却下すると記録は更新されないまま「完了」で終わりました。承認は押していません。承認の画面に何が書かれていたか、却下したあとの記録がどうなったかを順に書きます。

この記事で作るもの

• 名前は「記事検証 作業メモ追記エージェント」。書き込みツール1つを持つ AI エージェント

• ツールは、番号で指定したインシデントの1項目を更新する。実行モードは Supervised

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

• 承認の画面が出た時点で止め、却下して終える。書き込みは1回も行わない

試したのは1つのエージェントで、実行は1回です。承認の画面が出る条件や、承認したあとの動きまでは確かめていません。書き込みを足すときに先に決めておく点を洗い出す目的で書いています。

書き込みを足すのは、読み取りの検索が動いてからにする

先に押さえるのは順番です。読み取りだけのエージェントを動かし、調べた結果が正しいことを確かめてから、書き込みを1つだけ足します。読み取りの作り方は、前の記事「AI エージェントスタジオで AI エージェントを作る手順」に書きました。

書き込みを足すときは、まず標準の機能を探し、無ければ自作します。

• 標準の機能で足りるか確認する：標準の AI エージェントや Now Assist スキルに、同じ書き込みがすでにあることが多い。作る前に探す

• レコード操作のツールを自作する：テーブルと項目、条件を指定して、更新や作成をするツール。標準に無い書き込みはこの形になる

今回は、レコード操作のツールを自作しました。

書き込みを足す順番は、段階を分ける

書き込みを足すときは、1回で全部を試さず、4段階に分けました。

起点は段階1、緑は前の記事で確認済みの段階、濃い青は今回実施した段階、灰色は未実施の段階

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

1. 読み取りだけのエージェントを動かし、調べた結果が正しいことを確かめる（前の記事の範囲）

2. 書き込みのツールを監視中で足し、承認の画面が出るところで止める

3. 却下して、記録が1文字も変わらないことを確かめる（この記事の範囲）

4. 書き込んでよい検証用の記録で、承認を1回だけ押して、書き込み結果を確かめる（この記事では未実施）

段階2と段階3では、今回の1回の確認で、対象の記録は更新されませんでした。これは今回の経路での結果で、設定を変えた実行の安全までは保証しません。段階4に進む前に、承認する人・対象の記録・書き込む本文を、チェックリストの形で決めておきます。

書き込む対象になる記録の中身

対象は、検証用に作った日本語の INC0019394 です。件名は「記事検証: 社内ポータルのお知らせ欄が表示されない」で、状態は進行中、担当者が決まっています。作業メモも解決メモも空で、更新回数は0です。書き込みの前後を見比べやすいように、何も書かれていない記録を選びました。

実行モードは、自律と監視中の2つ

ツールの実行モードは、ツールごとに決めます。公式のドキュメントは、2つの違いを次のように説明しています。

（訳：エージェントは止まり、ツールを実行する前に人へ承認を求める。誰かが応答するまで何も起きないため、バックグラウンドや無人の実行では、Supervised のツールは進まずに止まる）

引用元：https://www.servicenow.com/docs/r/intelligent-experiences/add-tool-aia-new.html

自律のツールは、エージェントが選んだ時点でそのまま実行されます。読み取りだけのツールは自律。書き込み・削除・顧客への連絡が絡むツールは、監視中にします。トリガーで無人実行するエージェントに監視中のツールを入れた場合、承認する人がいないため、実行は止まったままです。

緑は承認なしで動く場合、橙は人の承認を待つ場合、赤は承認する人がいなくて止まる場合

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

• 自律：エージェントが選んだ時点でそのまま実行される。読み取りだけのツール向け

• 監視中（手動テスト）：実行の前に止まり、左の領域に承認カードが出る

• 監視中（トリガーで無人実行）：承認する人がいないため、実行は止まったまま。止まった実行の残り方は未確認

STEP1：【管理者】書き込みツールの種類を選ぶ

エージェントの作り方は前の記事と同じです。ツールの追加で、今回は［レコード操作］を選びます。

①の名前は、何をするツールかが分かる文にします。②の説明には、「ほかの項目は変更しない」「書き込みは担当者の承認後に実行する」と書きました。③の入力は2つで、incident_number がインシデント番号、work_note_text が書き込む本文です。

• 開始条件：エージェントの基本情報とロールが入力済み

• 期待結果：名前・説明・入力が埋まり、テーブルの選択に進める

• 中止条件：既存の標準ツールに同じ書き込みがあるなら、自作せずそれを使う

STEP2：【管理者】テーブルと条件、書き込む項目を決める

テーブルは Incident、操作は［レコードを更新］です。条件は「番号 が {{incident_number}} と等しい」にしました。{{ }} で囲んだ入力名が、実行のときに依頼文から取り出した値に置き換わります。

書き込む項目は、［フィールド値を追加］で選びます。当初は作業メモに書き込む予定でしたが、ここで書き込み先を変えることになりました。項目の検索欄に「作業メモ」と入れると、候補は「作業メモリスト（work_notes_list）」だけで、作業メモの本文の項目は出ませんでした。「work notes」で検索しても候補はゼロです。代わりに候補にあった「解決メモ（close_notes）」を書き込み先にしました。

③の実行モードで［監視中］を選びます。この日本語の表示は、ツール一覧では「Supervised」と出ます。同じ設定を指す別の言い方です。一覧で確認するときは、英語のほうを探してください。

• 開始条件：入力名が決まっている

• 期待結果：条件の値と書き込む項目の値の両方に、入力名が {{ }} で入る

• 中止条件：書き込みたい項目が候補に出ないときは、別の項目で代用する前に、本当にその項目でよいかを管理者に確認する

• 操作上の注意：［追加］が押せる状態にならなかった。入力名の欄を打ち直すと有効になった

STEP3：【管理者】追加後の一覧で実行モードを確かめる

ツールを追加すると、レコード操作の一覧に1行が増えます。

①のツール名は「解決メモを更新」ですが、エージェントの名前は「作業メモ追記エージェント」のままです。書き込み先を変えたのに名前を直さなかったため、食い違いが残りました。この食い違いは、承認の画面にも影響しました（後述）。名前と説明は、書き込み先が決まってから最後に直します。

残りの設定は、読み取りの記事と同じです。ユーザーアクセスは itil、トリガーは付けず、チャネルは2つとも許可しません。

STEP4：【管理者】承認の画面が出るまで動かす

手動テストで、エージェントを選び、タスクを書きます。「INC0019394 の解決メモに『検証用の文面です。承認画面の確認のための書き込みです。』と書き込んでください」と入れました。

エージェントは、すぐには書き込みませんでした。実行の画面の左側に、承認を求めるカードが出て止まっています。

①のカードに書かれていたのは、対象のインシデント番号、書き込む予定の本文、「この内容で書き込みを実施してよろしいでしょうか」という問いです。②には［承認］と［却下］のボタンが並んでいました。カードの見出しは「作業メモ追記の承認確認」でしたが、本文では「解決メモへ追記予定」となっています。見出しはエージェントの名前から、本文は実際の書き込み先から作られているようです。見出しだけで判断する承認者は、書き込み先を取り違えかねません。

公式のドキュメントでは、Supervised のツールは、実行の前に人へ承認を求めて止まり、無人の実行では止まったままになると説明されています。今回の動きは、この説明と合っていました。一方で、このカードが「ツールを呼ぶ直前のプラットフォームの確認」なのか、「エージェントが自分の応答として出した質問」なのかは、1回の実行では見分けられませんでした。ログを見ると、カードは生成 AI の応答として出ていて、ツールの実行の記録はまだ1件もありません。

STEP5：【担当者】却下して終える

今回は承認せず、［却下］を押しました。承認の処理は一度も実行していません。

②の作業結果は、「ご承認が得られなかったため、INC0019394 の解決メモは更新しておりません。ご依頼は未更新のまま終了いたします」でした。実行の状態は「完了」で、エラーではありません。

実行の記録を見ると、ツールの実行は1件もありません。生成 AI とコミュニケーターの記録だけが残っています。対象の記録も確かめました。実行の前と却下のあとに、同じインシデントの更新数と、解決メモ・作業メモの中身を時刻つきで控えて見比べます。更新数を見る場所は、一覧の更新数の列か、管理者の REST で取る sys_mod_count です。メールは、sys_email テーブルを実行の時刻以降の作成日時で絞り、今回の番号に結びつく行を探します。

• INC0019394 の更新回数は、実行前も却下後も0

• 解決メモと作業メモは、どちらも空のまま

• この記録とエージェントに関係するメールは0通

STEP6：【管理者】片付ける

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

実行ログで確かめた内容

実行の記録は、画面の意思決定ログと、実行の記録のテーブル（実行ID で絞る）の両方で確かめられます。今回の記録は、順に次のとおりです。

1. アクセス検証：成功

2. エージェントの起動：成功

3. 生成 AI（判断）：成功。ここで、承認を求める応答が作られた

4. コミュニケーター「Get user input unrefined」：利用者の入力を待つ処理。承認カードの表示に対応する

5. 生成 AI（判断）：却下を受けた判断

6. コミュニケーター「Show response to user」：作業結果を表示する処理

7. 生成 AI（判断）：終了の判断

ツールの実行の行は、どこにもありません。書き込みのツールが1度も呼ばれなかったことを、この記録で確認できます。承認を押した場合の記録は、今回は押していないため確かめていません。

テスト画面の構成と、承認カードが出る場所

手動テストの実行画面は、3つの領域に分かれています。

• 左：エージェントとのやり取り。承認カードと、承認・却下のボタンはここに出る。下部には、続けて指示を送る入力欄がある

• 中央：処理の流れを示す図。開始、エージェント、コミュニケーターの順に、実行中の位置が示される

• 右：意思決定ログ。生成 AI の呼び出しごとに、考えた内容と選んだ行動が並ぶ

承認カードは、左の領域にだけ出ます。右のログを開いて作業していると、承認待ちで止まっていることに気づきません。実行を始めたら、まず左の領域を見ます。

依頼文には、対象・項目・値の3つを書く

テストに入れた依頼文は、「INC0019394 の解決メモに『検証用の文面です。承認画面の確認のための書き込みです。』と書き込んでください」の1文でした。対象の番号、書き込む項目、書き込む本文の3つを、文の中に含めています。

この3つを含む依頼では、エージェントは聞き返さずに承認カードまで進みました。3つのどれかが欠けたときの動きは、確かめていません。3つを書くのは推奨の書式で、欠けたときに安全に止まる保証ではありません。

トリガーを付けるときは、承認する人の居場所を先に決める

今回はトリガーを付けず、手動テストだけで動かしました。トリガーを付けると、インシデントの登録や更新、スケジュールをきっかけに、人が画面を見ていない状態でエージェントが動き出します。

監視中のツールを持つエージェントを、この状態で動かすと、承認カードを見る人がいません。公式のドキュメントのとおり、実行は承認の待ちで止まったままになります。止まった実行が、あとからどんな状態で残るかは、今回確かめていません。承認されない実行が積み上がる可能性があるため、残った実行の片付け方を、トリガーを付ける前に決めておく必要があります。

トリガーを付ける前に、次の2点を決めます。

• 承認カードが出たとき、誰がどこで見るか。パネルを開いている担当者か、通知を受ける担当者か

• 承認されないまま残った実行を、誰がいつ片付けるか

この2点が決まらないうちは、トリガーは付けずに、手動の依頼だけにします。

承認とは別に、誰の権限で書くかを決める

公式のドキュメントでは、承認は実行の直前に求められると説明されています。書き込みの安全は、承認だけでは決まらず、アクセスの設定にも左右されます。公式の説明では、設定は次の2つです。

• 誰がこのエージェントを呼べるか：許可するユーザーを、特定のロール、認証済みのユーザー、公開から選ぶ。保存すると、選んだロールにもとづいてアクセス制御リストが作られる

• エージェントがどのデータを読み書きできるか：呼び出したユーザーの権限で動く「動的ユーザー」と、専用のユーザーの権限で動く「AI ユーザー」から選ぶ

AI ユーザーを選ぶと、誰が呼んでも、そのユーザーのロールで読み書きします。呼び出した人より強い権限を持たせられるため、書き込みのツールでは特に慎重に決めます。今回は、動的ユーザーのまま、呼び出せるロールを itil に絞りました。

引用元：https://www.servicenow.com/docs/r/intelligent-experiences/define-sec-aia-new.html

実機で気づいたこと

承認を求める文面は、AI が書いた文章だった

承認のカードの文面は、1回の実行では、エージェントの応答として作られていました。毎回同じ文面になるかは、確かめていません。文面が実行ごとに変わるなら、承認する人が読む情報も変わります。対象の番号と書き込む値を必ず含めるよう、ロールの文に書いておく案を、候補として下に載せています。

作業メモの項目が選べず、解決メモに切り替えた

レコード操作の項目選択では、作業メモの本文は候補に出ませんでした。ジャーナル型の項目は、別の方法が要る可能性があります。計画どおりに進まないときは、書き込み先の変更が名前や説明に波及します。

却下は、エラーではなく完了として記録される

却下のあと、実行の状態は「完了」で、記録のどの行も「成功」でした。エラーや中断の印は付きません。実行の記録を集計して失敗件数を数えている場合、却下された実行は成功に混ざります。ただし、ツールの実行がない完了は、却下だけを意味しません。却下の件数を知りたいときは、実行ごとの明示的な却下の応答を確かめて数えます。今回の実行では、却下の応答が記録に残っていました。

名前と説明の食い違いは、承認の文面にまで広がる

書き込み先を作業メモから解決メモに変えたのに、エージェントの名前は変えませんでした。その結果、承認カードの見出しは作業メモ、本文は解決メモという食い違いが出ています。直す場合は、テスト画面右上の［エージェントを編集］を開きます。名前・説明・ロール・ツール名の順に、書き込み先の語を揃えてください。作成後の変更は、公式のドキュメントにも手順があります。

承認とは別に、呼べる人・書く権限・対象の条件を決める

承認があるのは、実行の直前だけです。ユーザーアクセスで誰が呼べるか、データアクセスで誰の権限で書くか、対象を1件に絞る条件の3つは、承認とは別に設計します。

用語

• Supervised（監視中）：ツールを実行する前に、人の承認を求める実行モード

• Autonomous（自律）：承認を求めず、エージェントが選んだ時点でツールを実行するモード

• レコード操作：テーブルと条件を指定して、記録の検索・作成・更新・削除を行うツールの種類

• 入力名：依頼文から取り出した値を受け取る変数。条件や書き込む値に {{ }} で埋め込む

• 承認カード：承認と却下のボタンを持つ、実行画面上の確認の表示

• コミュニケーター：エージェントと利用者の間でメッセージを表示し、入力を受け取る処理

検証範囲

• 作成したエージェントは1つで、実行は1回です。承認の画面が出る条件や、毎回同じ文面になるかは確かめていません

• 承認は押していません。承認したあとに実際に書き込まれる動きと、書き込みの結果は未確認です

• 承認のカードが、プラットフォームの確認なのか、エージェントの応答なのかは、1回の実行では判断できませんでした

• 作業メモの項目をツールの書き込み先にする方法は、確かめていません

• ツール追加画面の［追加］が有効にならない現象は、再現するかを確かめていません

• トリガーでの自動実行や、承認者が別の人の場合の動きは試していません

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

ここまでが無料で読める範囲です。書き込みツールを足し、承認の画面が出るところまで動かして、却下して片付ける手順を、1回通して実行できる形にしました。

この先は、書き込みを足す前後に使う成果物の一式で、約0.4万字あります。内容は次のとおりです。

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

• エージェントの定義とツール定義の記入例：検証で実際に入力した内容

• 空欄のテンプレートと、値を変えるときの基準

• ロールの改善案：承認の文面を固定する版

• チェックリスト：承認の設計で決める項目、承認の画面で確認する項目、テストの項目の3つで合計18項目

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

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