AIエージェントの開発設計書：標準ワークフローを複製して使うときの権限・承認・試験

標準の AI エージェントのワークフローを自社用に複製して使うとき、誰が呼べるか、どの書き込みに承認を挟むか、どう試すかを決める開発設計書です。架空の社内サービスデスクを例にします。設計の根拠は、AI Agent Studio の設定画面と標準レコードの設定値、そして自作した2つのエージェント（読み取りだけのものと、承認つきで書き込むもの）を動かした記録です。

1. 目的・範囲・前提

この章では、どの業務を、誰が、どこまで AI エージェントに任せるかを決めます。

1.1 モデル案件

架空の会社「ひのき商事」の社内サービスデスクを対象とします。

• 従業員は1,200人。1日の問い合わせは約40件で、解決メモの下書きを使う想定は1日10件ほど

• サービスデスクの対応は平日9時から18時。一次受付が2名、二次対応が3名

• 問い合わせは ServiceNow のインシデントとして起票する

• 二次対応の担当者は、解決のときに解決メモ（close_notes）を手で書いている

• 一次受付は、過去の解決済みインシデントを自分の経験で探している

AI エージェントに任せる仕事は次の2つです。

• 症状に近いナレッジと解決済みインシデントを探して提示する

• 解決メモの下書きを作り、担当者の承認を得てから書き込む

1.2 構成の全体像

標準ワークフローを複製し、検索は自律で、書き込みは承認つきで動かします。

• 起点：担当者の依頼。本番は Now Assist パネル、試験は AI Agent Studio の手動テスト

• 標準ワークフローの採否：標準を複製して使う。複製しての実行は未実施

• エージェントとツールの構成：呼べる人を itil に限る設定は保存済み。担当者による呼び出しは未実施

• 検索ツール2つ：ナレッジと解決済みインシデント。実行モードは Autonomous で、回答を表示するだけで記録は変えない

• 解決メモ更新ツール：incident の解決メモ1項目。実行モードは Supervised で、承認か却下で分かれる

• 却下：更新せずに完了する。実施済み

• 承認後の書き込み：未実施

緑は、自作の類似構成で動かした経路を示します。複製したワークフローでの実行は未実施です。

1.3 前提条件

• Now Assist と AI Agent Studio（Otto AI Agents）が導入済みである

• 設計と設定を行う管理者は、ロール sn_aia.admin を持つ

• LLM のプロバイダーは、AI Admin Hub 側で構成済みである

• 試験は、本番と別の検証環境で行う。検証環境にはインシデントのテストデータがある

1.4 置き換える値

案件に合わせて変えるのは次の7つです。ほかは据え置きでよい設計にしてあります。

• 対象テーブル：incident

• 書き込み先の項目：解決メモ（close_notes）

• 呼べるロール：itil

• 承認する人：依頼した担当者本人

• 検索の結果制限：5件

• チャネル：Now Assist パネルのみ（試験中は両方オフ）

• 対応時間：平日9時から18時

1.5 本書の読み方

各設計は、次の10項目をこの順で書きます。該当がない項目は「なし（理由：〜）」と書き、空欄にしません。

• 対象：設計の対象になる機能・レコード

• 目的：この設計で保証すること

• 前提：この設計が成り立つ条件

• 標準仕様：製品の標準の動きと設定値。各行の末尾に根拠を付ける

• 設計内容：本案件で採用する内容

• 設計理由：採用の根拠

• 例外：標準の動きから外れる場合と、未決事項の扱い

• 完了条件：設計が実装されたと判断する状態

• 確かめ方：試験の条件・合格基準・状態

• 記入例：モデル案件で埋めた値

標準仕様の根拠は、次の3つで示します。

• ［公式］：ServiceNow の公式ドキュメントに記述がある

• ［実測］：デモ環境の画面・レコード、または自作の類似構成の実行で確かめた

• ［未確認］：確かめていない。結果を予想して書かない

試験の状態は［実施済み］と［未実施］の2つです。合否は状態とは別に「結果」として書きます。［実施済み］の試験は、自作の類似構成で管理者が手動テストを使って行いました。複製したワークフローでの実施は、すべて［未実施］です。

要件・設計・試験・未決・判断には、ID と名前を付けています。本文は名前で呼び、ID は見出し・対応表・一覧でだけ使う決まりです。要件から試験までのつながりは、次の図のとおりです。

起点は要件、青は設計と判断記録、緑は実施済みの試験、灰色は未実施の試験、橙は未決事項

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

• 要件9件（第2章）：何を満たせば使ってよいかを示し、対応表で設計と結ぶ

• 設計10件（第3〜10章）：1つの設計につき、対象から記入例までの10項目を同じ順序で書く

• 試験21件：各設計の「確かめ方」に条件と合格基準を書く。［実施済み］9件、［未実施］12件

• 未決事項11件（第12章）：内容・決める人・期限・進められない作業を書く

• 判断記録5件（第12章）：決めたことと、その根拠の設計

設計内容と例外の決定は「〜とする」で書きます。完了条件は状態を表す常体、標準仕様と設計理由の箇条書きも常体です。それ以外の説明は「です・ます」で書きます。

note は表を表示できないため、表と図は画像にしています。どの画像も、直後に同じ内容を箇条書きで載せます。

1.6 用語

• デモ環境：今回確かめた Now Assist のデモ環境

• 検証環境：案件で本番と別に用意する試験用の環境

• 類似構成：本書の確認のために自作した2つのエージェント。読み取りだけのものと、承認つきで書き込むもの

• 担当者：itil ロールを持つサービスデスクの担当者

• 管理者：sn_aia.admin を持ち、定義を作成・変更する情報システム部の担当

• 利用者：itil ロールを持たない従業員

• 複製：標準のワークフローを元に、自社用のコピーを作る操作。名前の末尾に (Copy) が付く

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

• ユーザーアクセス：誰がエージェントを呼べるかの設定。保存すると ACL が作られる

• データアクセス：呼ばれた後に、どの権限でデータを読み書きするかの設定。動的ユーザーと AI ユーザーがある

• 動的ユーザー：呼んだ人の権限で動く方式。承認済みロールで上限を絞れる

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

• ロール文：AI エージェントに与える指示文。権限のロール（itil など）とは別のもの

• 機能試験：各設計の確かめ方のうち、第10章（配布・移送）の試験を除いたもの。定義の削除を含まない

• 架空の値：モデル案件のために置いた担当・期限・要件。関連メールと外部連携なし、実行の追跡の2つの要件と、未決事項の担当と期限はこれにあたる

2. 要件と設計の対応表

何を満たせば使ってよいと判断するかを、この章で決めます。

2.1 要件

• RQ-01 関連情報の提示：担当者が症状の文章で依頼すると、公開済みナレッジと解決済みインシデントを、それぞれ5件以内で、番号・件名・該当理由つきで提示する。依頼の前後で、インシデントの更新回数は変わらない

• RQ-02 承認後だけ書き込む：承認の応答がない間と却下の後は、対象インシデントの更新回数が変わらない

• RQ-03 呼べるのは担当者だけ：itil を持たない利用者からは呼び出せない

• RQ-04 無人で動かさない：トリガーは0件で、実行はすべて担当者の依頼から始まる

• RQ-05 1項目・1件だけ：1回の承認で変わるのは、指定した番号の1件の解決メモだけである。ほかの項目と、ほかのレコードの更新回数は変わらない

• RQ-06 更新後の再確認：製品更新の適用後、検証環境で機能試験をやり直し、結果を記録するまで本番のチャネルの許可を外す

• RQ-07 本番への反映：本番相当の環境で機能試験に合格し、本番の設定が検証環境の記録と一致してから利用を始める

• RQ-08 関連メールと外部連携なし：実行に関係するメールが0通で、外部 AI エージェント・MCP サーバー・Web 検索・通知のツールを持たない。構成済みの LLM（Azure OpenAI）の呼び出しは対象外とする

• RQ-09 実行の追跡：書き込みを依頼した実行ごとに、承認か却下か、ツールが実行されたかを実行ログと作業結果から特定できる

2.2 対応表

行が設計、列が要件です。●が対応を示します。要件と設計の対応は、この表にだけ書きます。

• DS-01 標準ワークフローの採否：RQ-02 承認後だけ書き込む、RQ-05 1項目・1件だけ

• DS-02 読むデータと書くデータ：RQ-01 関連情報の提示、RQ-05 1項目・1件だけ

• DS-03 起動の場所とチャネル：RQ-04 無人で動かさない

• DS-04 エージェントとツールの構成：RQ-01 関連情報の提示、RQ-02 承認後だけ書き込む、RQ-05 1項目・1件だけ

• DS-05 実行モードと承認：RQ-02 承認後だけ書き込む、RQ-05 1項目・1件だけ

• DS-06 ユーザーアクセスとデータアクセス：RQ-03 呼べるのは担当者だけ

• DS-07 外部連携と LLM：RQ-08 関連メールと外部連携なし

• DS-08 利用量と実行ログ：RQ-09 実行の追跡

• DS-09 定義の移送と削除：RQ-07 本番への反映

• DS-10 製品更新後の再確認：RQ-06 更新後の再確認

3. 設計方針

標準のまま使う部分、設定で調整する部分、追加で作る部分を、次のように分けます。

• 標準のまま使う：LLM のプロバイダー、実行ログの画面、ユーザーアクセスの ACL を作る仕組み

• 設定で調整する：複製したワークフローのツール構成・実行モード・ユーザーアクセス・データアクセス・チャネル・トリガーの有効状態

• 追加で作る：標準に同じ動きがない検索だけ。書き込みツールは、複製元のツールで書き込み先を解決メモに限れない場合だけ新しく定義する

却下した案は次の3つです。

• 標準のワークフローをそのまま使う：書き込み先が解決メモ以外にも広がる

• AI ユーザーで動かす：依頼者を問わず AI ユーザーのロールで読み書きするため、権限が依頼者より広がる恐れがある

• トリガーで自動実行する：承認する人がいないまま、承認待ちで止まる

DS-01 標準ワークフローの採否

対象

標準の Wrap-up and resolve incident ワークフロー。

目的

解決メモの下書きと書き込みを、何を元に作るかを決めます。

前提

• 設計と設定を行う管理者が sn_aia.admin を持つ

• 複製は検証環境で行う

標準仕様

• Wrap-up and resolve incident は、インシデントの作業メモとコメントから解決メモを生成し、解決コードを選ぶ。条件に応じて、重複情報の更新、既知のエラー記事やナレッジ記事の添付、ナレッジ記事の下書き作成まで行う［公式］

• 対象は、進行中のインシデントと、解決コードとメモが入った解決済みのインシデント（解決コードが Known Error 以外で、調査が済んだもの）［公式］

• 変えたいときは、複製して設定を調整する。変更するときは、すべての指示を合わせて更新する［公式］

• エージェント型ワークフローと AI エージェントのレコードは、既定で読み取り専用。自律的に動かすには、複製してから有効化する［公式］

• 複製には sn_aia.admin が要る。名前の末尾に (Copy) が付き、既存の名前は使えない。つながったエージェントも複製先に追加される。トリガーは複製されるが、既定では非アクティブ［公式］

• 複製後の編集の前に、エージェントとツールの識別子と共有範囲を確認する［公式］

• 複製したエージェントが、複製元から独立したコピーになるか（公式に記載がない）［未確認］

• デモ環境のワークフロー一覧に、名前が (Copy) で終わる ITSM コレクションの複製が1件あった［実測］

• 自作のエージェントを保存したとき、説明の似た既存エージェント5件が「重複の可能性」として挙がった［実測］

• 標準のエージェントに付いたツール1,806件のうち、実行モードが Autonomous のものは1,764件、Supervised は42件（2026-09-19 集計）［実測］

• Wrap-up and resolve incident の書き込みツールの実行モードと、トリガーの有無［未確認］

• 画面の見出し：「重複の可能性が見つかりました」

• 並ぶもの：説明の似た既存のインシデント向けエージェント

• 案内の趣旨：似たエージェントがあると、LLM が選び間違える恐れがある

設計内容

• 標準の Wrap-up and resolve incident を複製して作る。名前は「ひのき商事 解決メモの下書き」とし、(Copy) の接尾辞は残さない

• 標準のまま使う案と、新規に作る案は採用しない

• 複製した直後に、次の順で確認する

1. 連結されたエージェントとツールの一覧を開く

2. 書き込みを行うツールと、その実行モードを控える

3. エージェントとツールの識別子と共有範囲を確かめ、複製先が複製元と別のレコードであることを確かめる。確かめられるまで編集しない

4. 複製されたトリガーの件数を確かめ、トリガーがあれば有効化せずに削除して0件にする

5. 書き込み先が解決メモ以外のツール（解決コード、ナレッジ記事の下書き作成、既知のエラー記事の添付など）を、複製側で外す

• 書き込み先が解決メモ以外のツールを Supervised にして残す対応は暫定の措置とし、完了条件にしない

設計理由

• 標準のワークフローは解決コードの設定やナレッジ記事の作成まで行うため、そのままでは書き込み先が解決メモ以外に及ぶ

• 標準のレコードは読み取り専用で、設定を変えられない

• 新規に作ると、説明の似たエージェントが増える。標準の選択肢と並ぶ場面で、LLM が選び間違える恐れがある

• 標準のワークフローは、解決メモの生成という中心の動きをすでに持つ

例外

• 解決メモ以外を書くツールが外せない場合は、複製を採用せず、新規作成に切り替える

• 複製した書き込みツールが Autonomous のまま残っていた場合は、Supervised に変えてから試験に進む

• 未決「複製元の書き込みツール」：解決メモ以外を書くツールをすべて外せるか。情報システム部の管理者が、運用開始の4週間前までに複製して確かめる。未決のまま、本番の設計は進めない

• 未決「検索を標準エージェントで賄えるか」：関連情報の検索を標準のエージェントで足りるか。同じ管理者が、運用開始の4週間前までに確かめる。未決の間、検索ツールの自作に着手しない

完了条件

• 複製したワークフローが、元のワークフローと別の名前で一覧に表示される

• 連結エージェントと、各ツールの種類と実行モードを、画面の保存画像として残している

• 解決メモ以外を書くツールが0件であることを一覧で確かめ、確認日と確認者を記録している

確かめ方

• TS-01 複製元との差分［未実施］

• 条件：複製した直後に、ツール一覧と実行モードを控える

• 合格基準：複製先のエージェントとツールが複製元と別の識別子を持ち、解決メモ以外を書くツールが0件で、トリガーが0件である

記入例

【名前】ひのき商事 解決メモの下書き
【複製元】Wrap-up and resolve incident
【書き込みツール】解決メモを更新 … Supervised（ほかの書き込みツールは外した）

4. データ

どのデータを読み、どのデータに書くかを決める章です。

DS-02 読むデータと書くデータ

対象

インシデント、公開済みのナレッジ記事、解決済みのインシデント。

目的

読む範囲と書く範囲を決め、承認カードで確認する対象を1つにします。

前提

書き込みは、レコード操作のツール（レコードを更新）で行う。

標準仕様

• レコード操作のツールは、テーブルと条件を指定して、レコードの検索・作成・更新・削除を行う［公式］

• 書き込む項目を選ぶとき、作業メモ（work_notes）の本文は候補に出なかった。「作業メモ」で検索すると、作業メモリスト（work_notes_list）だけが挙がった。解決メモ（close_notes）は選べた［実測］

• 読み取りの対象は検索プロファイルで決まる。ナレッジ検索に「Similar KB Articles」、インシデント検索に「Similar Resolved Incidents」を指定できた［実測］

• 保存したツールの記録では、テーブルが incident、条件が number={{incident_number}}、書き込む項目が close_notes だけだった［実測］

設計内容

• 読むデータは、インシデント、公開済みのナレッジ記事、解決済みのインシデントとする

• 書くデータは、インシデントの解決メモ1項目だけとする

• 検索の結果制限は5件とする

• 作業メモへの追記は、本書の範囲に含めない

設計理由

• 書き込み先を1項目に限ると、承認カードで確認する対象が1つになる

• 作業メモの本文は候補に出ないため、代用すると別の項目へ書くことになる

例外

• 作業メモへの追記が必要と決まった場合は、レコード操作のツール以外の方式を別に設計する

• 未決「作業メモへの追記」：要否をサービスデスクのリーダーが運用開始の3週間前までに決める。未決の間は、解決メモだけで運用する

完了条件

ツール定義の保存後、書き込む項目の一覧に解決メモ以外が残っていない。

確かめ方

• TS-02 書き込み項目の限定［実施済み］

• 条件：書き込みツールを定義して保存し、記録の側で設定値を読む

• 合格基準：書き込む項目が close_notes の1つだけである

• 結果：合格（類似構成）

記入例

【読むデータ】incident ／ 公開済みのナレッジ記事 ／ 解決済みの incident
【書くデータ】incident の解決メモ（close_notes）のみ
【結果制限】5

5. 画面

この章では、担当者がどこから呼び、どこで承認するかを決めます。

DS-03 起動の場所とチャネル

対象

トリガー、チャネル（Now Assist パネルと仮想エージェント）、手動テストの画面。

目的

担当者がどこから呼び、どこで承認するかを決め、無人の実行を作らないようにします。

前提

書き込みツールの実行モードは Supervised である（設計「実行モードと承認」）。

標準仕様

• チャットだけで使う場合は、トリガーを追加しなくてよい。トリガーは、イベントが起きたときに自動で呼びたい場合だけ追加する［公式］

• 複製したワークフローは、表示のスイッチを入れると Otto パネルに表示される［公式］

• Supervised のツールは、誰かが応答するまで止まる。無人の実行では先へ進まない［公式］

• 手動テストの画面を使うには、管理用のロールと関連する ACL の権限が要る［公式］

• 標準のワークフロー（プロジェクトタスクの監視）のトリガーは、画面では Inactive、REST の active は true で、食い違っていた［実測］

• 画面と REST が食い違う理由と、ほかのトリガーでも起きるか［未確認］

• 手動テストの画面では、承認カードは左の領域にだけ出た［実測］

• Now Assist パネルでの承認カードの表示位置［未確認］

• ①トリガー名：プロジェクトタスクの監視のトリガー

• ②対象テーブルと条件：pm_project_task

• ③状態：画面の表示は Inactive。REST の active は true

設計内容

• トリガーは付けない（0件）とする

• 試験中は、Now Assist パネルと仮想エージェントのチャネルを、どちらも許可しない。担当者による呼び出しの試験の間だけ、未決「担当者の呼び出し試験の経路」で決めた経路を検証環境で開く

• 本番では Now Assist パネルだけを許可し、仮想エージェントは許可しない

• 手動テストの画面は、管理者が行う機能の試験に限る

• 手動テストの画面では、依頼を出したら左側の承認カードを見る。Now Assist パネルで見る位置は、呼べる人の試験で確かめてから手順に書く

設計理由

• 承認が必要なツールを持つため、トリガーで動かすと、承認する人がいないまま止まる

• 手動テストの画面では承認カードが左の領域にだけ出るため、右の意思決定ログを開いていると承認待ちに気づきにくい

例外

• トリガーの状態は、画面と REST のどちらか一方で判断しない。トリガーを持たせる設計に変える場合は、有効化の前後に両方で確かめる

• 未決「担当者の呼び出し試験の経路」：itil を持つ担当者が呼ぶ試験を、どの画面で行うか。情報システム部の管理者が、運用開始の4週間前までに決める。未決のまま、呼び出しの試験は始めない

完了条件

トリガーが0件で、チャネルの許可スイッチが両方オフの画面を保存している。

確かめ方

• TS-03 起動経路の閉鎖［実施済み］

• 条件：エージェントを保存した後に、トリガーの一覧とチャネルの画面を開く

• 合格基準：トリガーが0件で、チャネルの許可スイッチが両方オフである

• 結果：合格（類似構成）

記入例

【トリガー】0件
【チャネル】試験中は両方オフ。本番は Now Assist パネルのみ

6. ロジック

エージェントが何を、どの順で、どのツールで行うかを、この章で決めます。

DS-04 エージェントとツールの構成

対象

AI エージェントのロールとステップ、ツール3つ。

目的

エージェントが何を、どの順で、どのツールで行うかを決めます。

前提

読むデータと書くデータは、設計「読むデータと書くデータ」のとおりである。

標準仕様

• ツールの種類は13。外部とつなぐもの3種、既存の部品を呼ぶもの6種、情報を引くもの3種、記録を扱うレコード操作1種［実測］

• 検索ツールは、名前、説明、検索プロファイル、検索条件、結果制限、実行モードの6項目で定義する［実測］

• インシデントの番号だけを渡したタスクでは、検索が実行されず、エージェントが件名と説明を聞き返して止まった［実測］

• 症状の文章を書いたタスクでは、2つの検索ツールが続けて呼ばれた［実測］

• 検索の結果には、番号が出ず、件名と該当理由が出た［実測］

• 検索の依頼の前後で、対象のインシデントの更新回数は8のままだった［実測］

• 公開済みのナレッジ記事が該当する場合の検索結果［未確認］

• 番号が出なかった原因が、ロール文の指示か、ツールの返却値か［未確認］

• 類似構成では、書き込みツールの入力を2つとも必須の指定にしていない［実測］

• 成功した実行で、生成 AI の呼び出しは5回。ログの Time 値は1回あたり11.6秒から14.3秒（1回の実行の値）［実測］

• ①調査結果：ナレッジは該当なし、類似インシデントは2件。番号は出ず、件名と該当理由が並ぶ

• ②ログ：2つの検索ツールの呼び出しが並ぶ

設計内容

• ツールは次の3つとする

• ナレッジ検索：Autonomous、検索条件はキーワード、結果制限5件

• 解決済みインシデント検索：Autonomous、検索条件はキーワード、結果制限5件

• 解決メモ更新：Supervised。条件は「番号 = 入力の番号」で1件に絞る。入力（番号と本文）は2つとも必須の指定にする

• 検索の依頼文のひな型に、症状の文章を書く欄を設ける

• エージェントのロール文に、出力へ番号・件名・該当理由を含めること、結果が空なら空だったと答えることを書く

• 処理は次の順で進む

1. 担当者が、症状の文章を含む依頼を出す

2. エージェントが、2つの検索ツールを呼ぶ

3. エージェントが、番号・件名・該当理由を表示する

4. 書き込みの依頼があった場合だけ、解決メモ更新を呼び、承認を待つ

設計理由

• 番号だけでは、検索ツールが症状を知る手段を持たない。番号でインシデントを取得するツールを足すと、読み取りの経路が増える

• 条件で1件に絞ると、1回の承認で書き込む先が指定した番号のインシデントに限られる

例外

• 番号だけの依頼で聞き返しが入るのは、想定した動きとして扱う

• 結果に番号が出ない場合は、ログでツールの返却値を確かめてから、ロール文とツールのどちらを直すか決める

• 呼び出し回数と所要時間は1回の成功例の値であり、タイムアウトや中止の基準に使わない

• 未決「下書き本文の生成元」：標準の生成機能を残す場合は、作業メモとコメントを取得する担当エージェントと入力を、複製元で特定する。残さない場合は、担当者が本文を依頼文に書き、ツールは書き込みだけを行う（類似構成はこの形）。残さない案を採ると、下書きの生成は任せる仕事から外れるため、モデル案件の仕事の範囲を書き直す。サービス責任者が、運用開始の5週間前までに決める。未決のまま、生成機能を含む承認カード・却下・承認後の書き込みの試験は始めない（本文を依頼文に書く形の試験は類似構成で済ませた）

完了条件

実行ログに2つの検索ツールの呼び出しが並び、結果に番号と該当理由が含まれる。

確かめ方

• TS-04 検索の呼び出し［実施済み］

• 条件：症状の文章を含む依頼を出す

• 合格基準：2つの検索ツールが呼ばれ、結果に番号と該当理由が出る。依頼の前後で更新回数が変わらない

• 結果：呼び出し、該当理由、更新回数（8のまま）は合格。番号の出力は不合格（類似構成）

• TS-05 該当なしの応答［実施済み］

• 条件：ナレッジが0件になる症状で依頼する

• 合格基準：該当なしと答え、エラーにならずに完了する

• 結果：合格（類似構成）

• TS-06 検索結果の範囲［未実施］

• 条件：公開済みのナレッジ記事が該当する症状と、候補が6件以上ある症状で依頼する

• 合格基準：公開済みの記事と解決済みのインシデントだけが、それぞれ5件以内で出る

• TS-07 入力の欠落［未実施］

• 条件：番号が空のとき、存在しない番号のとき、書き込む本文が空のときに、書き込みを依頼する

• 合格基準：書き込まず、質問か停止になる

• 補足：検索の依頼で番号だけを渡したときに聞き返しが入ることは、類似構成で確かめた

記入例

【依頼文に書く症状】経費精算システムで申請を送信すると、送信時に E-5031 のエラーが出る。別端末でも同じ症状が出る
【エージェントが組み立てた検索語】経費精算システム 申請送信 E-5031 エラー
【期待する結果】ナレッジは該当なし、類似の解決済みインシデントは2件

DS-05 実行モードと承認

対象

3つのツールの実行モード、承認カード、承認する人。

目的

どの書き込みに、誰の承認を挟むかを決めます。

前提

ツールの構成は、設計「エージェントとツールの構成」のとおりである。

標準仕様

• Autonomous は、エージェントが選んだ時点で実行する。読み取りや影響の小さい更新に向く［公式］

• Supervised は、実行前に止まり、人に承認を求める。書き込み・削除・顧客への連絡に使う［公式］

• 実行モードはツール単位で、いつでも変更できる［公式］

• 記録の側の値は、Supervised が copilot、Autonomous が autopilot［実測］

• プロパティ sn_aia.enable_usecase_tool_execution_mode_override は、デモ環境で false。説明文には、true にすると自律のワークフローが全エージェントのツールの実行モードを上書きすると書かれている［実測］

• このプロパティについての公式ドキュメントの記述［未確認］

• 書き込みツールを Supervised にして依頼すると、承認と却下のボタンが付いたカードが出て止まった［実測］

• カードの見出しは「作業メモ追記の承認確認」、本文は「解決メモへ追記予定」で、食い違っていた［実測］

• 食い違いの原因［未確認］。エージェントの名前が作業メモのままだったことが候補

• 却下を押すと、作業結果に更新していないと表示され、実行は「完了」で終わった。ツールの実行記録は0件で、対象の更新回数は0のままだった［実測］

• ログでは、承認カードは生成 AI の応答として出ていた［実測］

• カードが、プラットフォームの確認か、エージェントの応答として作られた文か［未確認］

• 承認を押した後の書き込みの動き［未確認］

• 承認待ちの実行を管理者が取り消す方法と、取り消した後の状態［未確認］

• Autonomous（自律）：エージェントが選んだ時点で実行する

• Supervised（監視中）：実行前に承認と却下のボタンが付いたカードで止まる

• 却下した場合：更新0回のまま、実行は「完了」で終わる

• 承認した場合の書き込みの動き：未確認

• ①更新条件：番号が入力の番号と等しい

• ②書き込む項目：解決メモに入力名を入れる

• ③実行モード：監視中（一覧の表示は Supervised）

• ①カードの本文：対象のインシデント番号、書き込む予定の本文、書き込みを実施してよいかの問い

• ②ボタン：承認と却下。どちらかを押すまで実行は止まる

設計内容

• 検索ツールは Autonomous、書き込みツールは Supervised とする

• プロパティ sn_aia.enable_usecase_tool_execution_mode_override は false のまま変更しない

• 承認する人は、依頼した担当者本人とする。代行は認めず、不在のときは依頼を出さない

• 承認の前に、カードの本文で次の3点を読む。見出しだけで判断しない

• 対象のインシデント番号

• 書き込む項目

• 書き込む本文

• 承認待ちで止まった実行は、当面の運用目標として次の順で閉じる

1. 依頼した担当者が、同じ営業日のうちに承認か却下で閉じる

2. 閉じられない実行は、翌営業日に管理者が取り消す

3. 必要なら、担当者が依頼を出し直す

• エージェントの名前・説明・ロール・ツール名は、書き込み先の語（解決メモ）でそろえる

設計理由

• ワークフロー単位の実行モードが実行時にどう反映されるかは、公式の記述が見つからない。公式に記述があるツール単位の設定を採る

• 類似構成で、Supervised のツールが承認待ちで止まることを確かめた

• 名前と書き込み先の語の食い違いは、カードの見出しが食い違った原因の候補である。予防として語をそろえる

例外

• 承認は依頼者本人の自己承認になるため、誤承認の責任は依頼者が負う。二人目の確認の要否は、運用設計で決める

• カードの文面が毎回同じになる保証はないため、ロールに文面の型を書く案を成果物に置く

• 未決「承認後の書き込み」：承認を押した後に解決メモだけが書き込まれるか。情報システム部の管理者が、書き込んでよい検証用のレコードで、運用開始の3週間前までに確かめる。未決のまま、承認の運用手順は確定しない

• 管理者が承認待ちの実行を取り消す操作と権限は確かめていないため、取り消した実行の状態を実行ログで確かめてから手順に書く

• 未決「承認待ちの上限時間」：承認待ちを何時間まで許すか。サービスデスクのリーダーが、運用開始の3週間前までに決める。未決のまま、承認待ちの運用手順は確定しない

完了条件

ツール一覧で、検索ツール2つが Autonomous、書き込みツール1つが Supervised と表示される。

確かめ方

• TS-08 承認カードでの停止［実施済み］

• 条件：書き込みの依頼を出す

• 合格基準：承認カードが出て止まり、対象の更新回数が変わらない

• 結果：合格。更新回数は0のまま（類似構成）

• TS-09 却下［実施済み］

• 条件：承認カードで却下を押す

• 合格基準：更新回数・解決メモ・作業メモが変わらず、ツールの実行記録が0件である

• 結果：合格。更新回数は0から0、解決メモと作業メモは空のまま（類似構成）

• TS-10 承認後の書き込み［未実施］

• 条件：書き込んでよい検証用のレコードで、承認を押す

• 合格基準：指定した1件の更新回数が1だけ増え、変わった項目が解決メモと、更新日時など製品が自動で更新する項目だけである。状態・解決コード・担当者は変わらない。同じ時間帯に、ほかのインシデントの更新回数は変わらない。承認待ちの間に対象が更新されていた場合の動きも記録する

記入例

【依頼文】INC0019394 の解決メモに「検証用の文面です。承認画面の確認のための書き込みです。」と書き込んでください。
【承認カードで読む3点】INC0019394 ／ 解決メモ ／ 検証用の文面です。承認画面の確認のための書き込みです。
【応答】却下

7. 権限

誰が呼べて、エージェントは誰の権限で動くかを決める章です。

DS-06 ユーザーアクセスとデータアクセス

対象

ユーザーアクセス、データアクセス、AI Agent Studio のロール。

目的

呼べる人を担当者に限り、エージェントが依頼者の権限を超えて読み書きしないようにします。

前提

チャネルと起動の場所は、設計「起動の場所とチャネル」のとおりである。

標準仕様

• アクセスの設定は2つに分かれる。1つ目は誰がエージェントを呼べるか（ACL）、2つ目は呼ばれた後にどのデータへアクセスできるか［公式］

• 呼べる人は、特定のロール、認証済みのユーザー、公開から選ぶ。保存すると、選んだロールに基づく ACL が作られる。公開は、レコードのデータを扱わないエージェント向けで、控えめに使う［公式］

• データアクセスは、動的ユーザーと AI ユーザーから選ぶ。動的ユーザーは呼んだ人の権限で動き、承認済みロールを選ぶと権限の上限を絞れる。選ばなければ、呼んだ人のロールをそのまま引き継ぐ［公式］

• AI ユーザーは、誰が呼んでも専用ユーザーのロールで読み書きする。権限が呼んだ人より広がる場合がある［公式］

• ロールの絞り込みは、最小権限の原則に沿った推奨の設定である［公式］

• 標準のワークフロー（プロジェクトタスクの監視）は、ユーザーアクセスが「次の場合に許可」で project_manager、データアクセスが AI ユーザーだった。画面には、一般ユーザーに AI ユーザーの代理操作を許可すると権限が昇格されるという警告が出ていた［実測］

• AI Agent Studio のロールは sn_aia.admin、worker_manager、viewer、integration の4つ［実測］

• エージェントとワークフローの書き込み・作成・削除の ACL は sn_aia.admin。読み取りは viewer と sn_aia.admin。実行の記録（execution_plan）の読み取りには itil も含まれる［実測］

• 既存の ACL には、sn_hr_core.admin や sn_gsm_ai_agents.* を許可するものもある［実測］

• itil を持たない利用者から呼べないこと［未確認］

• ①決定タイプ：次の場合に許可

• ②呼べるロール：project_manager

• ③状態：アクティブ

• ①ユーザー ID タイプ：AI ユーザー

• ②警告：一般ユーザーに AI ユーザーの代理操作を許可すると、権限が昇格される

• ③付与ロール：多数のロールが並ぶ

• 本案件では、この構成を採用しない

設計内容

• ユーザーアクセスは「特定のロールを持つユーザー」とし、ロールは itil とする。公開と認証済みのユーザーは選ばない

• データアクセスは動的ユーザーとし、承認済みロールを itil に絞る。AI ユーザーは使わない

• 定義を変更する管理者に付与するロールは sn_aia.admin だけとする。サービスデスクの担当者には viewer も付与しない

• 担当者以外が承認する操作は許可しない

権限の設定を4つの層に整理すると、次のとおりです。層は設定の 置き場で分けたもので、製品内部の処理順とは別です。

• 1層目 ユーザーアクセス：呼べる人は itil を持つ担当者。保存すると ACL が作られる

• 2層目 データアクセス：動的ユーザー。依頼者の権限で動く

• 3層目 ツールの実行モード：検索は Autonomous、更新は Supervised。ここで人の承認が入る

• 4層目 ツールの条件：番号で1件に絞り、書き込む項目は解決メモだけ

• 呼べない人：itil を持たない利用者。拒否の試験は未実施

設計理由

• 動的ユーザーは呼んだ人の権限で動くため、依頼者の権限が上限になる

• AI ユーザーは、依頼者より広い権限で書き込む可能性がある

• 公式は、ロールの絞り込みを最小権限の推奨の設定としている

例外

• 実行の記録（execution_plan）は itil が読めるため、ログに症状の文章や検索語が残る場合の閲覧範囲は、運用設計で決める

• 未決「定義の変更権限」：定義の変更を管理者だけに限れるか。sn_hr_core.admin などを許可する既存の ACL を確認し、拒否の試験を行う。情報システム部の管理者が、運用開始の3週間前までに確かめる。未決のまま、本番のチャネルは許可しない

完了条件

ユーザーアクセスとデータアクセスの画面を保存し、呼べる人と呼べない人の試験に合格している。

確かめ方

ユーザーアクセスを itil に、データアクセスを動的ユーザーにする設定の入力と保存は、類似構成で済ませました。

• TS-11 呼べる人［未実施］

• 条件：itil を持つ担当者が、担当者の呼び出し試験の経路から呼ぶ

• 合格基準：エージェントを呼び出せ、承認カードの表示位置を記録できる

• TS-12 呼べない人［未実施］

• 条件：itil を持たない利用者が、どの依頼でも出す

• 合格基準：呼び出せず、実行の記録が作られない

• TS-13 データ権限の上限［未実施］

• 条件：itil は持つが、対象のインシデントを更新する権限を持たない担当者が、書き込みを依頼する

• 合格基準：承認しても解決メモが書き込まれず、更新回数が変わらない

• TS-14 本人以外の承認［未実施］

• 条件：依頼者以外の担当者が、承認待ちの実行の承認を操作する

• 合格基準：承認できず、更新回数が変わらない

• TS-15 定義変更の拒否［未実施］

• 条件：sn_aia.admin を持たない利用者（sn_hr_core.admin だけを持つ利用者を含む）が、定義を編集する

• 合格基準：保存できない

• 管理者が手動テストで検索を依頼する：検索結果を表示する。［実施済み］（検索の呼び出しの試験）

• 管理者が手動テストで解決メモの更新を依頼する：承認カードが出て停止する。［実施済み］（承認カードでの停止の試験）

• itil を持つ担当者が呼び出す：呼び出せる。［未実施］（呼べる人の試験）

• itil を持たない利用者がどの依頼でも出す：呼び出せない。［未実施］（呼べない人の試験）

記入例

【ユーザーアクセス】特定のロールを持つユーザー: itil
【データアクセス】動的ユーザー。承認済みロール: itil
【定義の変更】sn_aia.admin を持つ管理者のみ

8. 連携

この章では、外部のシステムや機能につなぐかを決めます。

DS-07 外部連携と LLM

対象

外部との連携（外部 AI エージェント・MCP サーバー・Web 検索）、メールと通知、LLM のプロバイダー。

目的

要件にない外部連携とメールの送信を作らないようにします。

前提

ツールの構成は、設計「エージェントとツールの構成」のとおりである。

標準仕様

• 公式は、ITSM のエージェント型ワークフローに Azure OpenAI を推奨している［公式］

• Google を Web 検索のプロバイダーにすると、データの所在地が保証されない可能性がある（出典の公式ページを特定できていない）［未確認］

• AI Agent Studio の設定で、外部 AI エージェントのアクセス許可と、サードパーティの許可がどちらもオンだった［実測］

• MCP サーバーのレコードは7件あった［実測］

• モデルプロバイダーは Azure OpenAI で、Now Assist アドミンで構成されていた［実測］

• 検索と却下までの実行で、対象のインシデントに結びつくメールは0通だった［実測］

設計内容

• 外部 AI エージェント、MCP サーバー、Web 検索のツールは使わない

• メールや通知を送るツールは持たせない

• LLM のプロバイダーは、ITSM の公式の推奨に従い、Azure OpenAI のままとする

設計理由

• 連携先が増えるほど、承認の対象と権限の確認が増える

• 要件に、外部との連携が含まれていない

例外

• 未決「外部エージェントの許可」：外部 AI エージェントのアクセス許可をオンのまま使うか。情報システム部の管理者が、運用開始の2週間前までに決める

完了条件

ツール一覧に、外部とつなぐ種類のツールと、通知を送るツールが0件である。

確かめ方

• TS-16 関連メールの不送信［実施済み］

• 条件：実行の後に、sys_email テーブルを実行の時刻以降の作成日時で絞る

• 合格基準：対象の番号や作成物に結びつくメールが0通である

• 結果：合格。検索の実行と却下までの実行の両方で0通（類似構成）。外部への通信全体は検査していない

記入例

【外部 AI エージェント・MCP サーバー・Web 検索】使わない
【メール・通知のツール】持たせない
【LLM のプロバイダー】Azure OpenAI（変更しない）

9. 非機能

利用量の確認先と、実行ログの扱いを、この章で決めます。

DS-08 利用量と実行ログ

対象

生成 AI の呼び出しの記録、実行ログ、AI Agent Studio のアクティビティ画面。

目的

実行ごとに、承認か却下か、ツールが実行されたかを追えるようにします。

前提

実行は担当者の依頼からだけ始まる（設計「起動の場所とチャネル」）。

標準仕様

• 管理者は、エージェントごとの名前つきのログで、誰が承認したかを確認できる［公式］

• 成功した検索の依頼1回で、生成 AI の呼び出しが5回記録された。承認を求めて却下するまでの実行では3回だった［実測］

• AI Agent Studio にアクティビティの画面があり、状況・作成者・実行タイプの集計と、実行の一覧を見られる［実測］

• 却下した実行の記録は、次の順で残り、ツールの実行の行は0件だった［実測］

1. アクセス検証

2. エージェントの起動

3. 生成 AI の判断

4. 利用者の入力待ち（Get user input unrefined）

5. 生成 AI の判断

6. 作業結果の表示（Show response to user）

7. 生成 AI の終了の判断

• 利用量の数え方と、画面の合計時間の意味［未確認］

• ①却下：承認カードで却下を押した

• ②作業結果：承認が得られなかったため、解決メモは更新していないと表示される

• 右のログ：生成 AI の記録が3つ並び、ツールの実行は0件

設計内容

• 運用開始の前に、利用量の確認先と上限の扱いを Now Assist の管理者に確認し、記録する

• 実行ログは、担当者が問い合わせの調査に使える範囲で保持する

• 却下された実行は、状態が「完了」で記録される。エラーの集計に混ぜず、承認の応答を確かめて数える

設計理由

• 却下は、ツールが実行されない「完了」としてだけ残る。完了の件数だけでは、却下の件数を数えられない

例外

• 実行ログの保持期間は、運用設計で決める

• 未決「利用量の確認先」：利用量の確認先と上限の扱い。情報システム部の管理者が、運用開始の2週間前までに確かめる

完了条件

書き込みを依頼した1件の実行について、承認か却下か、ツールが実行されたかを、実行ログと作業結果から特定できる。承認で終えた実行の記録は、承認後の書き込みの試験で確かめる。

確かめ方

• TS-17 実行ログの追跡［実施済み］

• 条件：却下で終えた実行の記録を、実行 ID で絞って開く

• 合格基準：アクセス検証から終了の判断までの行が残り、ツールの実行が0件で、状態が「完了」である。作業結果に、承認が得られなかったため更新していないと出ている

• 結果：合格（類似構成）

記入例

【実行】却下で終えた実行
【状態】完了
【ツールの実行】0件
【生成 AI の呼び出し】3回
【集計での扱い】却下として数える（エラーには数えない）

有料部には、配布・移送の設計2件、試験21件の実施状況、判断記録と未決事項の一覧を載せています。成果物として、記入済みの例、空欄の書式、値を変えるときの判断基準も含みます。分量は約1万字です。

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