AIエージェントの運用設計書：監視・停止・承認・利用量の確認

標準の AI エージェントのワークフローを複製して本番で動かすには、運用側で先に決めておくことがあります。承認待ちのまま残った実行をいつ誰が閉じるか、異常のときに誰が止めるか、利用量をどこで数えるかの3点です。本書はその判断を書いた運用設計書で、架空の会社「ひのき商事」の社内サービスデスクを例に、16の運用ルールで定めます。扱う項目は次のとおりです。

• 有効化の承認と、承認待ちで止まった実行の処理

• 実行履歴の点検、AI Control Tower での稼働記録の確認、手動実行の許可

• 異常の重大度、停止の基準と権限、ベンダーへの問合せ

• 生成された書き込みのレビュー、自社変更と製品更新の受け入れ

• 利用量の確認、書き込みツールの棚卸し、文書とログの保存

本書の読み方

• ID：運用要件は RQ、運用ルールは OR、試験は TS、未決は OI、判断は DC で始まる。ID は見出し・対応表・一覧の章でだけ使い、本文では名前で呼ぶ

• 文体：判断基準・実施内容・例外は「〜とする」「〜する」の決定として書く。章の導入と画像の説明の地の文は「です・ます」、箇条書きは言い切りの形で書く

• 根拠：製品の動きを述べた行の末尾に、［実測］（デモ環境で確かめた）、［公式］（公式ドキュメントの記述）、［未確認］（確かめていない）を付ける

• 試験の状態：各ルールの「確かめ方」に、［実施済み］か［未実施］を付ける。机上演習は、本書の「障害シナリオの机上演習」に書き出したものだけを実施済みとする

• 数値：30分・15分・見込み回数などは、モデル案件の業務要件から置いた設計例。デモ環境で観察した件数や所要時間は、基準の根拠にしていない

• 図表：図と表の画像のあとに、同じ内容を文字の箇条書きで載せる

根拠にしたのは、AI Agent Studio の設定画面の閲覧と、読み取りの REST です。ほかに、自作エージェント2種（読み取り専用と承認つき書き込み）の実行記録と、公式ドキュメントの記述を使いました。停止（無効化）の操作と、承認を押した後の書き込みは、今回実行していません。

1. はじめに

この章で決めること：運用の目的・対象範囲・方針・モデル案件と、本書で使う用語。

1.1 目的と対象範囲

運用の目的は、複製した AI エージェントのワークフローを、承認と停止の判断者が決まった状態で動かし続けることとする。

• 対象の環境：本番と検証環境の2つ

• 判断（開発インスタンスを置かない）：開発専用のインスタンスは置かず、複製の変更は検証環境で作る

• 対象の AI エージェント：標準の「Wrap-up and resolve incident」（解決メモの下書き）を複製したワークフローと、その中の検索エージェント・書き込みエージェント

• 関連する運用：Now Assist 全体の管理（有効化の範囲、利用量の契約）。本書は AI エージェントの実行回数を数え、契約上の消費量は Now Assist の管理者に確認する

• 関連する文書：「AIエージェントの開発設計書：標準ワークフローを複製して使うときの権限・承認・試験」（設計と試験）

• 対象外：時間外の障害対応、Now Assist のスキル（要約・生成）の運用、全社共通のアカウント管理と監視基盤

構成は開発設計書と共通です。検索は自律（Autonomous）、書き込みは承認つき（Supervised）で、トリガーは付けません。呼べるのは itil ロールの担当者で、データアクセスは動的ユーザーです。書き込み先は解決メモの1項目だけです。開発設計書が運用設計へ渡した3項目（承認待ちの上限時間、実行ログの閲覧範囲、利用量の確認先）は、本書で決めます。

1.2 運用コンセプト

標準機能を使い続けるために、運用は次の方針で組み立てる。

• 標準準拠：標準ワークフローを複製して使い、定義の変更は最小にする。変更は「自社変更の本番反映」を通す

• 有効化は最小限：書き込みツールは1つ、トリガーは0件、チャネルは Now Assist パネルだけにする。範囲を広げる変更は設計に戻し、「運用開始と有効化の承認」からやり直す

• 判断（時間外は使わない）：平日18時以降と休日は、担当者が依頼を出さない。時間外の障害対応は本書の対象外とする

• 判断（点検は人手で行う）：点検と棚卸しは人手で行い、自動化は置かない。自動化は、運用開始から3か月の記録で手作業の負担が見えた後に検討する

• 継続的改善：重大度の条件・待ち時間・見込み回数は、運用開始から3か月の記録をもとにリーダーが見直し、結果を本書の版数に反映する

1.3 モデル案件

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

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

• 対応は平日9時から18時。一次受付が2名、二次対応が3名

• 情報システム部の管理者が2名おり、AI エージェントの定義を変更できる sn_aia.admin ロールは、この2名にだけ付与する

• サービスデスクのリーダーが1名おり、運用上の承認者となる

• AI エージェントは、検索（類似の解決済みインシデントとナレッジの提示）と、解決メモの下書き（承認後に書き込み）を担う

体制の人数と時間帯は設計例です。自社の値に置き換える箇所は 1.5 に示します。

1.4 用語

本書では、次の語を1つの意味で使います。

• 担当者：サービスデスクの一次受付と二次対応の担当者。itil ロールを持つ

• 管理者：情報システム部の管理者2名。sn_aia.admin と AI steward のロールを持つ

• リーダー：サービスデスクのリーダー。運用上の承認者

• 当番：毎朝の点検を行う二次対応担当。週替わりの持ち回り

• 依頼：担当者が Now Assist パネルから AI エージェントへ出す依頼

• 実行：依頼1件ごとに作られる AI エージェントの処理の記録（実行計画、execution_plan）

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

• 停止：AI エージェントやワークフローを無効化して、実行されない状態にすること。再有効化できる

• 手動実行：担当者の依頼ではなく、管理者が AI Agent Studio のテスト画面から AI エージェントを動かすこと

• 検証環境：ひのき商事の試験用インスタンス。本番とは別

• デモ環境：本書の根拠を取った Now Assist デモ環境。ひのき商事の環境とは別

• 自作の構成：デモ環境で作った自作エージェント2種（読み取り専用と、承認つき書き込み）

• 開発設計書の受け入れ試験：開発設計書の試験のうち、検索・該当なし・起動経路・承認カード・却下・承認・呼べる人・呼べない人・入力の欠落・複製元との差分の10件

• 運用台帳：点検・承認・停止・棚卸しの記録を残す1冊の帳簿

• 重大度：異常の重さを3段階に分けたもの。段階ごとに期限と判断者が決まる

• 稼働記録：AI Control Tower と AI Agent Analytics ダッシュボードに出る、実行の記録と集計

• AI Control Tower：AI 資産を台帳にして管理し、AI とのやり取りを採点して監視する機能

• AI steward：AI Control Tower で、承認と評価の設定を担うロール（sn_ai_governance.ai_steward）

• セッション・トレース・スパン：AI とのやり取りの記録の3階層。1回のやり取り、その中の1往復、その中の1つの操作（ツール呼び出しなど）

• 動的ユーザー：呼んだ人の権限で動くデータアクセスの方式

• パッチ：製品の修正の適用

• メジャーアップグレード：ファミリーリリース間の移行（例：Zurich から Australia）

• スキップされたレコード：メジャーアップグレードで上書きされなかった変更。アップグレード履歴に出る

1.5 置き換える値

案件に合わせて変える値は次の6つとし、ほかは据え置きで使える構造にしてある。

• 値1 体制：管理者2名、リーダー1名、二次対応3名

• 値2 時間帯：平日9時から18時。依頼の締め切りは17時30分

• 値3 承認の応答期限：30分

• 値4 重大度の期限：15分、当日中、5営業日

• 値5 見込みの実行回数：1日50回、月1,000回

• 値6 点検とレビューの周期：毎朝10時、週5件、四半期に1回

2. 運用要件と運用ルールの対応

この章で決めること：業務要件から置く運用要件と、各要件を満たす運用ルールの対応。

2.1 運用要件

業務要件から、次の運用要件を定める。数値は、デモ環境の観察値を根拠にせず、モデル案件の業務要件から置いた設計例である。

• RQ-01 有効化の条件：本番での有効化は、運用開始の6条件をリーダーが照合して承認した後に限る。照合記録のない有効化を0件とする

• RQ-02 書き込みの承認：解決メモへの書き込みは、依頼した担当者本人が承認した実行だけとする。承認の操作がない書き込みと、解決メモ以外への書き込みを0件とする

• RQ-03 承認待ちの期限：承認待ちの実行は、依頼から30分以内に応答するか、依頼者がリーダーへ報告する。18時に残った実行は、依頼者の確認で閉じるか、翌営業日10時までに管理者が取り消す

• RQ-04 逸脱時の停止：解決メモ以外の項目の変更、または承認のない書き込みの疑いは、管理者が連絡を受けてから15分以内に無効化する

• RQ-05 毎朝の点検：前営業日の実行状況を、毎営業日10時までに点検して台帳に記録する

• RQ-06 週次の稼働記録の確認：稼働記録を週に1回確認する。エラーの増加と、解決メモ以外を書くツールの呼び出しは、確認した日のうちに暫定の重大度を付ける

• RQ-07 手動実行の制限：手動実行は検証環境で、リーダーが目的を承認したものだけとする。本番での手動実行を0件とする

• RQ-08 書き込みの照合：承認済みの書き込みを、運用開始から4週間は全件、以降は週に5件、元の記録と照合する

• RQ-09 利用量の記録：前月の実行回数を、翌月の第3営業日までに台帳へ記録する

• RQ-10 変更と更新の受け入れ：自社の変更と製品の更新は、検証環境で開発設計書の受け入れ試験に合格した後に、本番へ受け入れる。製品の更新は、更新後5営業日以内に試験する

• RQ-11 ベンダーへの問合せ期限：製品の動きが疑われる異常は、重大度1なら無効化した当日中、重大度2なら2営業日以内に問い合わせる

• RQ-12 記録の保存：異常・停止・更新の受け入れの記録は3年、ほかの台帳の欄は1年、実行ログは90日残す

2.2 対応表

要件と運用ルールの対応は、次の表だけに書く。行が運用ルール、列が運用要件で、●が対応を表す。各ルールの本文には対応を書かない。

• OR-01 運用開始と有効化の承認：RQ-01 有効化の条件、RQ-02 書き込みの承認

• OR-02 承認カードへの応答：RQ-02 書き込みの承認、RQ-03 承認待ちの期限

• OR-03 承認待ちで止まった実行の処理：RQ-03 承認待ちの期限

• OR-04 毎朝の実行履歴の点検：RQ-04 逸脱時の停止、RQ-05 毎朝の点検

• OR-05 週次の稼働記録の確認：RQ-06 週次の稼働記録の確認

• OR-06 手動実行の許可と記録：RQ-02 書き込みの承認、RQ-07 手動実行の制限

• OR-07 生成された書き込みのレビュー：RQ-02 書き込みの承認、RQ-08 書き込みの照合

• OR-08 重大度と対応期限：RQ-04 逸脱時の停止

• OR-09 停止の判断基準：RQ-04 逸脱時の停止

• OR-10 停止と再開の権限：RQ-04 逸脱時の停止

• OR-11 ベンダーへの問合せ基準：RQ-11 ベンダーへの問合せ期限

• OR-12 自社変更の本番反映：RQ-01 有効化の条件、RQ-10 変更と更新の受け入れ

• OR-13 製品更新の受け入れ：RQ-10 変更と更新の受け入れ

• OR-14 利用量の確認：RQ-09 利用量の記録

• OR-15 書き込み権限を持つツールの定期棚卸し：RQ-02 書き込みの承認

• OR-16 文書の版数とログの保存：RQ-12 記録の保存

3. 体制と運用開始

この章で決めること：誰が実行し誰が承認するか、環境をどう使い分けるか、どの条件で運用を始めるか。

3.1 体制・役割と連絡

役割ごとの担当を RACI で示す。記号の意味は次のとおりとする。

• R（Responsible）：実際に作業を行う

• A（Accountable）：承認し、結果に責任を持つ

• C（Consulted）：実施の前に相談を受ける

• I（Informed）：実施の後に結果の報告を受ける

• 運用開始・有効化：R 管理者、A リーダー、C 二次対応担当、I 全担当者

• 承認カードへの応答：R と A は依頼した担当者、I リーダー（30分を超えたとき）

• 停止（無効化）・再開：R 管理者、A リーダー、I 全担当者

• 毎朝の点検：R 当番、A リーダー、I 管理者（異常時）

• 稼働記録の確認（AI Control Tower・週次）：R 管理者、A リーダー、I 情報システム部長（重大度2以上のとき）

• 手動実行（検証環境）：R 管理者、A リーダー、C 二次対応担当、I 依頼者

• 書き込みのレビュー：R と A はリーダー、C 二次対応担当

• ツールの棚卸し：R 管理者、A リーダー、I 情報システム部長

• 製品更新の受け入れ：R 管理者、A リーダー、C 二次対応担当

• 利用量の確認：R 管理者、A リーダー、I 情報システム部長

• ベンダーへの問合せ：R 管理者、A リーダー、C 二次対応担当、I 情報システム部長

R と A を同じ人が兼ねるのは、承認カードへの応答と書き込みのレビューである。承認カードへの応答は、開発設計書で承認者を依頼した担当者本人と決めたためである。誤承認の責任は依頼者が負い、二人目の確認は置かず、「生成された書き込みのレビュー」で事後に照合する。書き込みのレビューは、照合の結果に責任を持つリーダーが自分で行う。

体制は、ひのき商事の情報システム部とサービスデスクで構成する。運用ベンダーは置かず、製品の障害は管理者が ServiceNow 社へ問い合わせる。

• 担当者：依頼を出し、承認カードに応答する（R と A）。異常は二次対応へ報告する

• 二次対応3名：毎朝の点検（当番）と相談（C）を担う。重大度1または2は管理者へ上げる

• 管理者2名：有効化・停止・稼働記録の確認・棚卸しを実行する（R）。停止と再開の承認をリーダーへ依頼する

• リーダー：有効化・停止・再開・レビューを承認する（A）。重大度2以上を情報システム部長へ報告する

• 情報システム部長：重大度2以上・棚卸し・利用量の報告を受ける

• ServiceNow 社：製品の障害の問合せ先。点線の経路で、リーダーの承認を得た管理者が問い合わせる

有効化から再開までの判断と実行は、次の順で進める。

1. リーダーが管理者へ有効化を依頼する。管理者は、検証環境の試験に合格した記録をそろえて、リーダーへ承認を申請する

2. リーダーが、運用開始の6条件を照合して承認する

3. 管理者が、本番で有効化する

4. 管理者が、AI Control Tower で稼働記録を週に1回確認する

5. 異常があれば、リーダーが重大度を判定し、「停止の判断基準」で停止が要るかを決める。停止が要らなければ、当番の毎朝の点検で運用を続ける

6. 停止が要る場合は、管理者が無効化する。重大度1は15分以内とする

7. 原因が解消し、受け入れ試験に合格した後に、リーダーが再開を承認すれば 3 へ戻る。保留なら停止の状態を保つ

• 起点：有効化の承認の申請（管理者）

• 判断・承認：有効化の承認、重大度と停止の要否の判定、再開の判断（いずれもリーダー）

• 実行：本番での有効化（管理者）、運用の継続と毎朝の点検（二次対応）

• 監視：稼働記録の週次確認（管理者）

• 停止：無効化（管理者。重大度1は15分以内）

連絡体制は次のとおり定める。

• 連絡先は連絡先台帳（管理者2名、リーダー、二次対応3名、情報システム部長）だけに置き、本書には転記しない

• 連絡手段は社内チャットの専用チャネルと電話とする。重大度1は電話で直接連絡する

• 未決：連絡先台帳の整備。決める人はリーダー、期限は運用開始の1週間前。未決のままでは運用開始の条件を満たせず、運用開始に進めない

3.2 インスタンス運用方針

• 環境の使い分け：試験と開発は検証環境、業務は本番だけで行う。検証環境で運用開始の条件の試験に合格してから、本番で有効化する。本番で試験用の定義を作らない

• 個人情報の扱い：実行ログと承認カードには、インシデントの症状文や作業メモが残り、氏名や連絡先が含まれる場合がある。検証環境の試験は、実在の従業員を含まないダミーのインシデントで行う。本番の実行ログは、点検の目的以外で開かない

• 判断（動的ユーザーで動かす）：データアクセスは動的ユーザーとし、AI ユーザー（エージェント専用のユーザー）は選ばない

• 特権の付与：sn_aia.admin と AI steward は管理者2名だけに付与し、付与の状況を「書き込み権限を持つツールの定期棚卸し」で四半期ごとに確認する

• IP 制限・多要素認証・特権アカウント：全社の基盤方針に従い、本書では定めない

• 未決：基盤方針の多要素認証と特権アカウントの管理を、管理者の AI Agent Studio への操作に適用する範囲。決める人は情報システム部長、期限は運用開始の2週間前。未決のままでは、有効化の操作を確定できない

OR-01 運用開始と有効化の承認

対象

本番環境で複製ワークフローを有効にする操作と、運用開始の宣言。実行は管理者、承認はリーダーとする。

目的

運用開始を認める条件と、有効化する人・認める人を決める。

前提

• 開発設計書の受け入れ試験は、検証環境で行う。うち「承認」の試験（承認後の書き込み）はデモ環境で確かめていない［未確認］

• 画面のトリガー一覧で Inactive と表示されたトリガーが、REST では active が true だった例がある［実測］

• 承認待ちの実行を管理者が取り消す手順［未確認］

• AI steward のロールで AI Control Tower の評価画面が出るか［未確認］

• ①トリガー名：標準のワークフロー（プロジェクトタスクの監視）の例

• ②対象テーブルと条件：テーブル pm_project_task の条件が出ている

• ③状態：画面は Inactive。同じトリガーの REST の active は true だった［実測］

判断基準

運用開始は、次の6条件がすべてそろった場合だけ認める。1つでも欠けた場合は、欠けた条件を記録して差し戻す。

• 開発設計書の受け入れ試験のうち、検索・該当なし・起動経路・承認カード・却下の5件が、検証環境で合格している

• 同じく「承認」の試験が、検証環境で合格している

• 同じく「複製元との差分」の試験で、解決メモ以外を書くツールが0件である

• 本書のほかの運用ルールの責任者が決まり、連絡先が台帳に記入されている

• 承認待ちの実行の取り消し手順と、AI steward のロールでの評価画面の表示が、検証環境で確かめてある。評価画面が使えない場合は、リーダーが評価の確認を条件から外す記録を残す

• 管理者2名のうち1名が、運用開始の日から1週間、平日9時から18時に連絡がつく

実施内容

1. 管理者が、検証環境の合格記録とツール一覧の画面保存画像を、リーダーへ提出する

2. リーダーが、6条件を1つずつ照合し、承認するか差し戻す

3. 管理者が、有効にする前に、トリガーが0件であることと、チャネルが Now Assist パネルだけであることを、画面と REST の両方で確かめる

4. 管理者が本番で複製ワークフローを有効にし、日時と操作者を運用台帳に記録する

5. 管理者とリーダーが書き込みの依頼を1件出し、承認カードの本文に番号・項目・本文の3点が出ることを確かめて、却下で閉じる

設計理由

• 承認後の書き込みはデモ環境で確かめていない。本番で初めて動かすことを避けるために、検証環境での合格を条件に入れる

• 画面と REST の値が食い違う例があるので、トリガーは片方だけで判断しない

• 有効化の直後の確認は却下で閉じ、本番のインシデントに試験の書き込みを残さない

例外

• 管理者2名とも不在の日は有効化せず、運用開始日を延期する

• トリガーが1件でもある場合は有効化を止め、開発設計書の「起動の場所とチャネル」に戻る

完了条件

• 運用台帳に、承認者の氏名・承認日時・6条件の照合結果が記入されている

• 有効化した直後に確認した画面の保存画像が、運用台帳から参照できる

確かめ方

• TS-01 運用開始の条件の照合［未実施］：検証環境の合格記録で6条件を照合する。合格基準は、6条件すべてに照合結果と根拠の記録名が記入されていること

• TS-02 有効化前後の起動経路［未実施］：有効化の前後で、トリガーとチャネルを画面と REST で見る。合格基準は、トリガー0件、チャネルが Now Assist パネルだけで、画面と REST の値が一致すること

• 見直し：設計のロールや実行モードが変わったとき、重大度2以上の異常が起きたときに、条件を見直す

記入例

【運用開始承認】承認者: リーダー（氏名） / 日時: 運用開始日 10:00
【6条件の照合】すべて合格（根拠: 検証環境の試験記録 第1版）
【有効化】操作者: 管理者（氏名） / 日時: 運用開始日 10:30
【トリガー】画面 0件 / REST 0件 【チャネル】Now Assist パネルのみ
【直後の確認】承認カードに番号・項目・本文の3点が出た。却下で閉じた

4. 運用サービス設計

この章で決めること：運用チームが何を提供し、いつ受け付け、どの項目を定常・障害対応・保守に分けて回すか。

4.1 運用チームが提供するサービス

運用チームは、管理者2名とリーダー1名で構成する。担当者へ、次の5つのサービスを提供する。

• 有効化の依頼：リーダーが管理者へ出す。管理者は受け付けてから3営業日以内に、運用開始の6条件の記録をそろえてリーダーへ承認を申請する

• 停止の依頼：リーダーまたは二次対応担当が管理者へ出す。重大度1は、連絡から15分以内に無効化する

• ツール追加の依頼：書き込みツールを増やす依頼は、設計に戻して運用開始の承認からやり直す。受け付けてから5営業日以内に、受け付けるかを返す

• 手動実行の依頼：リーダーまたは二次対応担当が管理者へ出す。受け付けてから2営業日以内に、検証環境で実施する

• 利用量のレポート：毎月、翌月の第3営業日までに、管理者が実行回数を台帳へ記録する

4.2 対応時間

• 受付と対応：平日9時から18時。依頼の締め切りは17時30分

• 時間外・休日：対応しない。担当者は依頼を出さない

• 計画停止の事前通知：製品側の停止や更新の予定は、通知を受けた管理者がリーダーへ当日中に伝える

• 未決：計画停止の事前通知の期限。ServiceNow 社の契約と通知の仕組みを確かめて定める。決める人は管理者、期限は運用開始前。未決のままでは、製品更新に備える日程を組めない

4.3 運用項目の一覧

運用項目は、定常・障害対応・保守の3種類に分ける。括弧内は周期と責任者である。

定常

• 毎朝の実行履歴の点検（毎営業日10時、当番）

• 週次の稼働記録の確認（毎週月曜10時、管理者）

• 承認待ちで止まった実行の処理（毎営業日18時と翌営業日10時、リーダーと管理者）

• 生成された書き込みのレビュー（開始から4週間は全件、以降は週5件、リーダー）

• 利用量の確認（月1回、管理者）

• 書き込み権限を持つツールの定期棚卸し（四半期に1回、管理者）

• 文書の版数とログの保存（変更のたび、管理者）

障害対応

• 重大度と対応期限（異常の検知のたび、リーダー）

• 停止の判断基準、停止と再開の権限（リーダーと管理者）

• 手動実行の許可と記録（依頼のたび、管理者とリーダー）

• ベンダーへの問合せ基準（管理者）

保守

• 自社変更の本番反映（変更のたび、管理者）

• 製品更新の受け入れ（パッチとメジャーアップグレードのたび、管理者）

5. 業務運用

この章で決めること：日々の承認・点検・レビューと異常時の停止を、誰がどの条件で行うか。

業務運用は、承認する人の行動から異常時の停止までを、1つの流れで扱います。ユーザーとロールの付与は全社の手順に従い、本書では sn_aia.admin と itil の付与範囲を棚卸しで確かめます。担当者の依頼から停止判断までの経路は、次の図のとおりです。

• 起点は担当者の画面からの依頼で、トリガーはない

• 検索の依頼は Autonomous で動き、回答を表示して完了する

• 解決メモの更新は Supervised で、承認カードを出して止まる。依頼者が30分以内に承認か却下で応答する

• 承認された書き込みは週次レビューで元の記録と照合し、基準に外れたら停止判断へ進む

• 検索と却下の実行は毎朝の点検で見て、重大度1または2なら停止判断へ進む

• 検索と承認の実行は AI Control Tower の週次確認で見て、エラーの増加や逸脱があれば停止判断へ進む

• 停止判断の後、原因の再現は検証環境の手動実行で行う

OR-02 承認カードへの応答

対象

解決メモの更新の依頼で出る承認カード。実行と承認は依頼した担当者、報告先はリーダーとする。

目的

承認する前に読む内容、応答の期限、応答できないときの扱いを決める。

前提

• Supervised は、AI エージェントが書き込む前に人の承認を求める実行モードである［公式］

• 依頼者以外の担当者が承認カードを操作できるか［未確認］

• 承認カードは、依頼を出した画面の左側にだけ出る［実測］

• 右側に意思決定ログを開いたままだと、左側の承認カードが目に入りにくい［実測］

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

• 依頼は17時30分までに出す

• ①承認カード：対象の番号・書き込む項目・書き込む本文の3点を読む場所。この画面では、見出しは「作業メモ追記」、本文は解決メモへの追記予定で、食い違っていた

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

判断基準

• 判断（承認者は本人だけ）：承認するのは依頼した担当者本人とし、代行は認めない

• 番号・項目・本文の3点がそろい、本文が元の作業メモとコメントに沿っていれば承認する。1つでも異なれば却下する

• 見出しだけで判断しない。見出しと本文が食い違う場合は却下する

• 応答の期限は、依頼から30分とする

実施内容

1. 担当者は、依頼を出したら左側の承認カードを見る

2. カードの本文で、対象のインシデント番号・書き込む項目・書き込む本文の3点を読む

3. 判断基準に沿って［承認］か［却下］を押す。却下した場合は、リーダーへ報告する

4. 30分以内に応答できない事情が生じたら、30分に達した時点でリーダーへ報告する

5. 離席する場合は、離席前に却下で閉じる

設計理由

• 承認者を本人に限るのは、開発設計書で承認者を依頼した担当者本人と決めたためである

• 誤承認は二人目の確認で止めず、「生成された書き込みのレビュー」の事後の照合で拾う

• 見出しと本文が食い違う例があったので、承認の判断は本文で行う

例外

• 代わりの担当者による承認は認めない。依頼者が応答できない実行は「承認待ちで止まった実行の処理」で閉じる

• 見出しと本文が食い違う場合は、却下して「重大度と対応期限」の重大度2で報告する

• 承認の後に書き込まれた内容と承認カードの一致は、「生成された書き込みのレビュー」で確かめる

完了条件

• 実行が承認か却下で閉じ、アクティビティの状況が「完了」になっている

• 承認した場合は、承認の日時・依頼者・対象番号が、運用台帳の書き込み記録に残っている

確かめ方

• TS-03 却下で閉じる［実施済み］：デモ環境の自作の構成で、承認カードの3点を読んで却下した。合格基準は、実行が完了で終わり、対象の更新回数が変わらないこと。結果は合格

• TS-04 承認で閉じる［未実施］：検証環境のダミーのインシデントで承認する。合格基準は、解決メモだけが書き込まれ、本文が承認カードの本文と一致すること

• 見直し：運用開始から3か月の記録で、リーダーが応答期限を見直す

記入例

【書き込み記録】日時: 第3営業日 11:05 / 依頼者: 二次対応担当（氏名）
【対象】INC番号 / 解決メモ
【応答】承認（依頼から6分）

OR-03 承認待ちで止まった実行の処理

対象

承認も却下もされないまま残る実行。取り消しは管理者、確認はリーダーとする。

目的

承認待ちの実行を閉じる時刻と、閉じる人を決める。

前提

• 入力待ちで止まった実行は、状況が「進行中」のまま残る［実測］

• 管理者が実行を取り消す操作の手順と、必要な権限［未確認］

• 承認待ちのまま担当者がログアウトした場合に、承認カードが残るか［未確認］

判断基準

• 18時に残っている実行は、依頼者が在席していれば、その場で承認か却下で閉じる

• 依頼者が不在なら、翌営業日10時までに管理者が取り消す

• 同じ内容の書き込みを、前の実行が閉じる前に依頼しない

• 起点は担当者の依頼。締め切りは17時30分

• 依頼から30分以内に、依頼者本人が承認カードに応答する。30分に達したらリーダーへ報告する

• 18時に、リーダーが残った実行の依頼者へ確認する

• 依頼者が在席なら、その場で承認か却下で閉じる

• 依頼者が不在なら、翌営業日10時までに管理者が内容を台帳に控え、更新履歴に書き込みがないことを確かめて取り消す

• 翌営業日10時の毎朝の点検で、進行中が0件であることを確かめる。書き込みがまだ要る場合は、担当者が改めて依頼する

実施内容

1. 18時に、リーダーが残っている実行の依頼者へ確認する

2. 依頼者が在席していれば、その場で承認か却下で閉じてもらう

3. 依頼者が不在なら、管理者が翌営業日10時までに、対象番号と書き込み予定の本文を台帳へ控える。本文の氏名と連絡先は伏せる

4. 管理者が、対象のインシデントの更新履歴で、書き込みがないことを確かめる

5. 管理者が実行を取り消す

6. 書き込みがまだ要る場合は、担当者が改めて依頼する

設計理由

• 取り消しの期限を翌営業日10時にするのは、毎朝の点検の期限と合わせ、当番が見つけた実行をその日の朝に閉じるためである

• 取り消す前に内容を控えておけば、再依頼で同じ本文を出せる

例外

• 管理者2名とも不在なら、リーダーが情報システム部長へ連絡する。リーダーが不在なら、事前に指名された二次対応担当がリーダーの確認を代わる

• 取り消せなかった場合は、承認も却下もできない状態として台帳に記録し、重大度2として「重大度と対応期限」へ回す

• 未決：取り消せない場合の最終判断者。決める人はリーダーと管理者、期限は運用開始前。未決のままでは、運用開始の条件のうち取り消し手順の確認を完了できない

完了条件

• 点検で、残った進行中の件数が0になる

• 台帳に、取り消した実行の識別子・内容・取り消した管理者・日時が残っている

確かめ方

• TS-05 管理者による取り消し［未実施］：検証環境で承認待ちの実行を作り、管理者が閉じる。合格基準は、進行中が0件になり、更新履歴に書き込みがなく、手順の画面保存画像が台帳にあること

• TS-06 机上演習「担当者の帰宅」［実施済み］：承認カードが残ったまま担当者が帰宅した場面で、受ける人・決める人・終える条件が決まるかを確かめた。結果は、取り消せない場合の最終判断者だけが未決で残った

• 見直し：待ち時間の上限（30分、18時、翌営業日10時）は、運用開始から3か月の件数を見て、リーダーが見直す

記入例

【日時】翌営業日 9時40分
【実行】実行の識別子（アクティビティの一覧から転記）
【内容】対象 INC番号 / 書き込み予定の本文（控え）
【書き込みの有無】対象の更新履歴を確認。書き込みなし
【取り消した人】管理者（氏名）
【再依頼】再依頼した場合は、新しい実行の識別子を記入

OR-04 毎朝の実行履歴の点検

対象

前回の点検以降に始まった実行と、開始日にかかわらず終わっていない実行。どちらも複製したワークフローの実行に限る。実施は当番、承認はリーダーとする。

目的

異常の有無を、毎朝5分で判断できる点検の手順を決める。

前提

• AI Agent Studio のアクティビティ画面に、状況・作成者・実行タイプの集計が出る［実測］

• 実行の一覧は、作成日時・作成者・状況・達成目標・バージョンなどの列を持つ［実測］

• 今回の却下例では、実行の状況が「完了」で残った。ツールの実行記録は0件で、対象の更新回数も変わらなかった［実測］

• 承認して書き込んだ実行の状況と、実行を開いて承認の応答を読めるか［未確認］

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

• アクティビティの集計を、複製したワークフローの実行だけに絞る方法［未確認］

• 実行ログ（execution_plan）の閲覧は、itil ロールにも ACL 上で許可されている［実測］

• 実行ログの閲覧を技術的に絞る設定［未確認］

• 実行ログの保持期間を制御する設定［未確認］

• ①表示の切り替え：使用状況に合わせる

• ②円グラフ：状況ごとの割合が出る。画面の合計（この環境では全実行を含む数）は、本案件の基準に使わない

• ③凡例：完了・進行中・failed・中断を見分ける。点検の対象は failed と中断、それに長く残る進行中

• ①却下のボタン：押すと、更新されないまま実行が終わる

• ②作業結果：更新していないと表示される。今回の却下例では、状況は「完了」だった［実測］。承認して書き込んだ実行の状況は確かめていない［未確認］

判断基準

• failed と中断が1件以上なら、実行を開いて失敗した段階を記録し、「重大度と対応期限」で重大度を付ける

• 前営業日に始まって進行中のまま残る実行は、「承認待ちで止まった実行の処理」へ回す

• 実行回数が見込み（1日50回）の1.5倍の75回を超えた日が3日続いたら、「利用量の確認」へ回す

• 作成者にサービスデスクの担当者以外の氏名があれば、itil 以外の利用者が呼べた疑いとして重大度2とする

• 平日18時から翌9時と休日に始まった実行、または承認の操作がないまま書き込まれた実行は、無人で動いた疑いとして重大度1とする

• 判断（却下を数えない）：完了の件数から却下を分けられないので、点検では却下を異常に数えない。却下の数は、実行を開いて承認の応答で確かめる

実施内容

1. アクティビティ画面を使用状況で開き、複製したワークフローの実行に絞る。期間は前回の点検以降とし、休日の分も含める

2. failed と中断の件数を見る

3. 進行中のまま残る実行を見る

4. 実行回数を見る

5. 作成者と作成日時を見る

6. 完了した解決メモの更新の実行を開き、承認の応答があるかを確かめる。応答のない書き込みがあれば重大度1とする

7. 台帳の点検欄に記入する。異常があれば、画面の保存画像と、回した先のルール名を書く

設計理由

• 週次の稼働記録の確認は抽出した一部の採点なので、個々の実行は毎朝の全件点検で見る

• トリガーを付けず、時間外は依頼を出さない設計のため、時間外に始まった実行は設計外の経路を意味する。だから重大度1とする

例外

• 当番が不在の日は、リーダーが代わる

• 実行ログには症状の文章や検索語が残る可能性がある。点検以外の目的で、他の担当者の実行を開かない

• 実行ログの保持期間は、要件として90日を置く。保持の設定の有無は、運用開始前に管理者が確かめて台帳に記録する。90日未満なら、管理者が週次の確認で前週の実行一覧の画面保存画像を台帳へ保存する

完了条件

• 点検欄に、日付・当番・failed 件数・中断件数・残った進行中の件数・実行回数が記入されている

• 異常があった日は、画面の保存画像と、回した先のルール名が記入されている

確かめ方

• TS-07 点検項目の読み取り［実施済み］：デモ環境のアクティビティ画面で、状況の集計と一覧の列を読み、却下した実行が完了で残ることを確かめた。合格基準は、点検の4項目（failed と中断、進行中、実行回数、作成者と作成日時）を画面で読めること。結果は合格

• TS-08 前回点検以降に絞った点検［未実施］：検証環境で、複製したワークフローの実行に絞り、期間を前回の点検以降にして手順どおりに点検する。承認の応答の有無も実行を開いて確かめる。合格基準は、5分以内に点検欄の全項目が埋まり、承認の応答の有無を読めること

• TS-09 実行ログの保持設定［未実施］：検証環境で、実行ログの保持期間を決める設定の有無を確かめる。合格基準は、保持期間が90日以上であるか、90日未満のときに代わりに保存するもの（週次の実行一覧の画面保存画像）が台帳で確認できること

• TS-10 机上演習「夜間の書き込みと利用の急増」［実施済み］：時間外の承認なしの書き込みと、利用の急増の場面で、受ける人・決める人・終える条件が決まるかを確かめた。結果は、両方とも決まった

• 見直し：点検の項目は、運用開始から3か月の記録を見て、リーダーが見直す

記入例

【日付】運用開始後 第3営業日
【当番】二次対応担当（氏名）
【failed】0件 【中断】0件 【残った進行中】0件
【実行回数】48回（見込み50回）
【作成者】サービスデスクの担当者のみ
【判定】異常なし

OR-05 週次の稼働記録の確認

対象

AI Control Tower の監視画面と、AI Agent Studio の AI Agent Analytics ダッシュボードに出る、複製したワークフローの稼働記録。実施は管理者、承認はリーダー、報告先は情報システム部長（重大度2以上のとき）とする。

目的

週単位の傾向と採点を見て、異常を重大度の判定へ回す手順を決める。

前提

• AI Control Tower は、監視の機能で AI とのやり取りをセッション・トレース・スパンの3階層で記録する［公式］

• 監視では、実行中のやり取りの一部を抽出し、品質などの指標で LLM が採点する［公式］

• 公式の比較表では、ServiceNow の AI への安全指標の提供は対象外とされている［公式］

• スコアは AI が生成するので、セッションの詳細と合わせて確かめるよう案内されている［公式］

• 評価の画面を使うロールは AI steward で、AI steward が評価を有効にする［公式］

• AI Agent Analytics ダッシュボードの閲覧には、sn_aia.viewer か sn_aia.admin が要る。指標は日次で更新される［公式］

• ダッシュボードには、過去90日のエラー数（週別）と、AI エージェントの実行を状況別に数えたカード（進行中・完了・成功・エラーまたはキャンセル）が出る［公式］

• 評価のテーブルは、デモ環境の管理者のアカウントでは行を読めなかった［実測］

• AI steward のロールで評価画面が出るか、複製したワークフローが採点の対象に入るか［未確認］

• AI Control Tower の監視画面の列とフィルタ［未確認］

判断基準

• エラー数が前週より増えていれば、重大度3とする

• ダッシュボードのエラー数と、毎朝の点検の failed と中断の週合計が食い違う場合は、原因を台帳に記録する。集計の対象と期間が異なる可能性があるので、一致は前提にしない

• 低スコアのセッションは、トレースとスパンまで開いて問題の段階を記録してから、重大度を付ける

• 解決メモ以外を書くツールの呼び出しがスパンに出ていれば、重大度1とする。書き込み先の項目は監視画面だけで判定せず、「生成された書き込みのレビュー」と対象インシデントの更新履歴で確かめる

• 週の実行回数が375回（見込みの週250回の1.5倍）を超えた週は、「利用量の確認」へ回す

• 低スコアの下限値が決まるまでは、スコアを重大度の判定に使わず、週次欄に参考として記録する

実施内容

1. 毎週月曜10時（休日なら翌営業日）に、管理者が AI Agent Analytics ダッシュボードを開き、エラー数と状況別のカードを見る

2. AI Control Tower の監視画面で、前週の低スコアのセッションを開き、トレースとスパンまで降りる

3. スパンのツール呼び出しで、解決メモ以外の書き込みを探す

4. 複製したワークフローの週の実行回数を見る

5. 台帳の週次欄に記入する。異常があれば、画面の保存画像を添えて、回した先のルール名を書く

設計理由

• 採点は一部の抽出なので、毎朝の点検の代わりにはしない。毎朝の点検が個々の実行を全件見るのに対し、週次の確認は傾向と採点を見る

• 日ごとには閾値を下回る増加を拾うために、日次の条件とは別に週の回数を見る

例外

• AI steward でも評価画面が出ない場合は、ダッシュボードのエラー数と実行回数だけで確認する。評価の確認を運用開始の条件から外す決定は、リーダーが運用開始の承認時に記録する

• セッションの詳細には、症状の文章や作業メモが出る可能性がある。確認以外の目的で、他の担当者のセッションを開かない

• 実施できなかった週は、理由と、翌営業日の実施日を台帳に記入する

• 未決：低スコアとして扱う下限値。決める人はリーダーと管理者、期限は運用開始前。未決の間は、スコアを参考の記録だけにする

完了条件

• 週次欄に、週・エラー数・低スコアのセッション数（未評価なら理由）・解決メモ以外の書き込みの有無（あり／なし／確認できず）・実行回数・実施者が記入されている

• 異常があった週は、画面の保存画像と、回した先のルール名が記入されている

確かめ方

• TS-11 AI steward での評価画面［未実施］：検証環境で、AI steward を付与した管理者が評価画面を開く。合格基準は、複製したワークフローのセッションが採点の対象として出ること

• TS-12 ダッシュボードの閲覧［未実施］：検証環境で、sn_aia.admin を持つ管理者がダッシュボードを開く。合格基準は、エラー数と状況別のカードが読めること

• TS-13 机上演習「週次確認でのエラー増加」［実施済み］：週次確認でエラーが増えていた場面で、受ける人・決める人・終える条件が決まるかを確かめた。結果は、回復しない場合の扱いまで決まった

• 見直し：確認の頻度と採点の使い方は、運用開始から3か月の記録を見て、リーダーが見直す

記入例

【週】運用開始後 第2週（月曜10時）
【実施者】管理者（氏名）
【エラー数】前週 2件、今週 1件（点検の failed と中断の週合計 1件と一致）
【低スコアのセッション】未評価（下限値が未決のため判定せず、件数は参考として記録）
【解決メモ以外の書き込みツールの呼び出し】なし
【実行回数】238回（見込み250回、1.5倍の375回を超えていない）
【判定】異常なし

OR-06 手動実行の許可と記録

対象

AI Agent Studio のテスト画面からの実行と、本番で失敗した実行の再依頼。検証環境の実行は管理者、本番の再依頼は依頼した担当者、承認はリーダーとする。

目的

手動で実行してよい場面、承認する人、記録する項目を決める。

前提

• 管理者は、AI Agent Studio のテスト画面から AI エージェントを動かせる［実測］

• 操作の手順は、別記事「AI エージェントスタジオで AI エージェントを作る手順（読み取り専用の検索エージェント）」と「AI エージェントに書き込みツールを足す手順（Supervised で承認を挟む）」にある。本書は、許可の条件・承認・記録だけを決める

• 手動実行の依頼は、リーダーか二次対応担当が管理者へ出す。依頼には、目的・テスト入力・対象の環境を書く

• テスト入力は、実在の従業員を含まないダミーのインシデントとする

判断基準

• 検証環境のテスト画面での実行を認める場面は、運用開始の試験・異常の原因の再現（重大度を問わない）・製品更新後の再確認・再有効化前の試験の4つとする

• 検証環境での実行の前に、リーダーが目的とテスト入力を承認する

• 判断（本番のテスト画面を使わない）：本番のテスト画面での実行は禁止とする。本番で失敗した実行は、依頼した担当者が新しい依頼として出し直す。管理者による代行実行は禁止とする

• 再依頼は1回までとする。初回と再依頼の計2回が失敗した場合は、手作業へ戻す

• 再依頼の前に、更新履歴で書き込みがないことを確かめる。分からない場合は重大度1とする

• 承認待ちで取り消された実行の再依頼は、「承認待ちで止まった実行の処理」に従う

実施内容

検証環境での手動実行は、次の順で行う。

1. 管理者が、目的とテスト入力をリーダーへ示し、承認を得る

2. 管理者が、依頼を受けてから2営業日以内に、検証環境のテスト画面で実行を終える

3. 書き込みの試験は、書き込み予定の本文を確かめて却下で閉じる。開発設計書の「承認」の試験だけは、ダミーのインシデントで承認まで進める

4. 台帳の手動実行欄に記入する

5. 記入の後に、試験用に作った定義を管理者が片付ける

本番で失敗した実行の再依頼は、次の順で行う。

1. 担当者が、対象インシデントの更新履歴で書き込みがないことを確かめる

2. 担当者が、同じ内容を新しい依頼としてパネルから出す

3. 再依頼も失敗したら、担当者は手作業へ戻り、当番へ報告する

4. 当番が、実行を開いて失敗した段階を記録し、重大度3として「重大度と対応期限」へ回す

設計理由

• 本番で管理者が実行すると、依頼者と承認者を管理者が兼ね、承認者を依頼者本人とする設計から外れる

• 本番の作成者が管理者の実行は、毎朝の点検で設計外の利用の疑いとして出る。禁止にしておくと、点検で見つけた時点で異常と判断できる

例外

• 重大度1で再現が要る場合も本番では再現せず、検証環境で再現する。本番では「停止の判断基準」を先に当てはめる

• 手動実行で作った実行の記録は、台帳へ記入するまで削除しない

完了条件

• 台帳の手動実行欄に、日時・環境・実行者・承認者・目的・テスト入力（ダミーの番号）・実行の識別子・結果・後片付けが記入されている

• 本番で再依頼した場合は、点検欄の備考に、再依頼の有無と新しい実行の識別子が記入されている

確かめ方

• TS-14 テスト画面からの実行［実施済み］：デモ環境の自作の構成で、テスト画面から読み取りの実行と、承認つき書き込みの却下を動かした。合格基準は、実行が完了で終わり、却下で書き込みが起きないこと。結果は合格

• TS-15 本番の再依頼［未実施］：検証環境で失敗した実行を作り、担当者が更新履歴を確かめて再依頼する。合格基準は、新しい実行の識別子が点検欄の備考に記入されること

• TS-16 机上演習「失敗した実行の出し直し」［実施済み］：担当者が本番での実行し直しを頼んだ場面で、受ける人・決める人・終える条件が決まるかを確かめた。結果は、受ける人をリーダーとして決まった

• 見直し：認める場面と再依頼の回数は、運用開始から3か月の記録を見て、リーダーが見直す

記入例

【日時】運用開始前 検証環境
【環境】検証環境（本番では実行しない）
【実行者】管理者（氏名） 【承認者】リーダー（氏名）
【目的】運用開始の試験（承認カードの本文確認）
【テスト入力】ダミーのインシデント INC（番号）
【実行の識別子】アクティビティの一覧から転記
【結果】承認カードに番号・項目・本文の3点が出た。却下で閉じた
【後片付け】試験用の定義を削除。実行の記録は残した

OR-07 生成された書き込みのレビュー

対象

承認されて解決メモに書き込まれた内容。実行と承認はリーダー、相談先は二次対応担当とする。

目的

承認の後に、書き込みの内容を誰が何で照合するかを決める。

前提

• 照合の元は、対象のインシデントの作業メモとコメントとする

• 承認の後に解決メモへ書き込まれる動き［未確認］

• 照合の観点のうち4点は、別の機能（Skill Kit で作った返信文の下書き）の試行で見えた書き方の問題を参考にした。記録にない対応の補完、予定を実施済みと書く表現、効果がなかった手順の再提案、氏名の欠落である［実測］

• AI エージェントの解決メモで同じ問題が出るか［未確認］

• レビューに要する時間［未確認］

判断基準

リーダーは、解決メモを元の記録と照合し、次の6点を確かめる。

• 元の記録にない対応が書かれていない

• 予定の対応が、実施済みとして書かれていない

• 効果がなかった手順が、推奨として書かれていない

• 氏名や固有名詞が、記録のとおりである

• 解決メモ以外の項目が、依頼の前後で変わっていない

• 承認カードに出た本文と、書き込まれた本文が一致している

結果は、次の3つに分ける。

• 問題なし：文章を変えずに使える

• 軽微な修正：事実関係は変えず、氏名の表記や語句だけを直す

• 重大な誤り：記録にない対応、予定を実施済みとする記述、効果がなかった手順の推奨、承認カードとの不一致のどれかがある。重大度2として扱う

• 解決メモ以外の項目の変更は、結果の区分に入れず、重大度1として扱う

実施内容

1. 運用開始から4週間は、承認された書き込みの全件を対象にする。以降は、リーダーが週に5件を無作為に選ぶ

2. リーダーが、解決メモを元の記録と照合し、6点を確かめる。解決メモ以外の項目は、対象インシデントの更新履歴で確かめる

3. リーダーが、結果を台帳のレビュー欄に記録する

4. 重大な誤りは、二次対応担当が同じ日に更新履歴から元の内容へ戻し、リーダーが確かめる

設計理由

• 承認は依頼者1人の判断で、二人目の確認を置かないので、誤承認は事後の照合で拾う

• 開始から4週間を全件にするのは、承認後の書き込みを本番で初めてまとめて見る期間だからである

例外

• 重大な誤りが出た週は、翌週のレビューを全件に戻す

• 重大な誤りが1か月に2件以上あった場合は、管理者が開発設計書の担当へ、ロールの指示の見直しを依頼する

• レビューの所要時間は、運用開始から2週間、リーダーが実測して台帳に記入する

完了条件

• 台帳のレビュー欄に、期間・対象の件数・結果の内訳・重大な誤りの有無が記録されている

確かめ方

• TS-17 承認後の書き込みの照合［未実施］：検証環境で、開発設計書の「承認」の試験で書き込まれた解決メモを6点で照合する。合格基準は、6点すべての結果が台帳に記入されること

• TS-18 机上演習「誤った内容の承認」［実施済み］：担当者が本文を読まずに承認した場面で、受ける人・決める人・終える条件が決まるかを確かめた。結果は、誤承認した担当者の扱いまで決まった

• 見直し：対象の件数は、運用開始から3か月の記録を見て、リーダーが見直す

記入例

【期間】運用開始後 第2週
【対象】承認された書き込み 7件（全件）
【結果】問題なし 5 / 軽微な修正 2 / 重大な誤り 0
【軽微の内容】氏名の表記 1、語句の言い換え 1
【所要時間】リーダーが実測して記入

OR-08 重大度と対応期限

対象

点検・週次の稼働記録の確認・レビュー・棚卸し・担当者の報告で見つかった異常。判定はリーダー、実行は管理者とする。

目的

異常の重さを決める条件と、段階ごとの対応期限を決める。

前提

• 報告者は、実行の識別子、気づいた日時、見えた現象を、リーダーへ伝える

• 承認カードの見出しと本文が食い違う例があった（見出しは作業メモ、本文は解決メモ）［実測］

• その食い違いが表示の問題か、書き込み先の誤りか［未確認］

判断基準

上から順に条件を当てはめ、最初に当たった段階を重大度とする。

1. 重大度1：解決メモ以外の項目が変更された疑い・承認の操作がないまま書き込まれた疑い・時間外に始まった実行、のどれか

2. 重大度2：承認カードの内容と書き込み結果の食い違い・承認カードの見出しと本文の食い違い・itil 以外の利用者が呼べた疑い・棚卸しの項目（トリガーの有効化など）が設計から外れたこと・取り消せない実行・レビューでの重大な誤り、のどれか

3. 重大度3：failed や中断の増加（週次のエラー数が前週より増えた場合を含む）、または応答の乱れ

4. どれにも当たらない：重大度を付けず、異常記録に現象を残す

あわせて、次のとおり定める。

• 判断（迷えば重い側）：判定に迷う場合は、重い側の重大度を採用する

• 書き込みが行われたか分からない場合は、更新履歴と解決メモの中身の確認が終わるまで、重大度1として扱う

• 当番や管理者が付けた重大度は暫定とし、リーダーが当日中に確定する。確定までは、暫定の重大度の期限で動く

起点は、点検・レビュー・担当者の報告による異常の検知です。図は次の順に問いを当てはめます。

1. 解決メモ以外の項目が変わったか、承認なしで書き込まれたか、時間外に始まったか。はいなら重大度1で、管理者が15分以内に無効化する

2. 承認カードとの食い違い、itil 以外の呼び出し、設定の逸脱、取り消せない実行、レビューの重大な誤りがあるか。はいなら重大度2で、当日中にリーダーと管理者が停止を判断する

3. failed が増えたか、応答が乱れたか。はいなら重大度3で、5営業日以内に原因を確かめて継続する

4. どれにも当たらなければ、重大度を付けずに記録だけ残す

実施内容

1. 報告を受けたリーダーが、判断基準を上から当てはめ、重大度を確定する

2. 当番や管理者が重大度1に当たる異常を見つけた場合は、リーダーの確定を待たず管理者へ直接連絡し、同時にリーダーへ報告する

3. 重大度1は、リーダーが管理者へ電話で直接連絡し、全担当者へ依頼を止めるよう周知する。管理者は、連絡を受けてから15分以内に無効化する

4. 重大度2は、リーダーと管理者が、当日中に「停止の判断基準」で停止を判断する

5. 重大度3は、管理者が5営業日以内に原因を確かめ、継続か停止かをリーダーへ報告する

6. リーダーが、異常記録に記入する

設計理由

• 書き込みの範囲を越えた疑いを最上位に置くのは、承認の設計そのものが破れたことを意味するからである

• 見出しと本文の食い違いを重大度2にするのは、原因を確かめておらず、書き込み先の誤りの可能性が残るためである

• 15分の起点は、管理者が自分で守れる期限にするために、管理者が連絡を受けた時刻に置く

例外

• リーダーが不在の日は、事前に指名された二次対応担当が重大度を確定する

• 時間外の障害対応は本書の対象外とし、時間外に起きた異常は翌営業日の点検で扱う

完了条件

• 異常記録に、重大度（暫定と確定）・判定者・対応開始の時刻・終了の時刻・対応内容が残っている

確かめ方

• TS-19 机上演習での重大度の当てはめ［実施済み］：障害シナリオのうち、異常を含む5つ（担当者の帰宅を除く）に判断基準を当てはめた。合格基準は、どの現象も1つの重大度に決まること。結果は合格

• 見直し：重大度の条件は、運用開始から3か月の記録を見て、リーダーが見直す

記入例

【報告日時】第8営業日 10:12 【報告者】当番（氏名）
【実行の識別子】アクティビティの一覧から転記
【現象】前営業日に failed が3件
【重大度】暫定3（当番 10:12）→ 確定3（リーダー 10:40）
【対応】管理者が5営業日以内に原因を確認

OR-09 停止の判断基準

対象

AI エージェントの無効化の判断と、再有効化の判断。判断はリーダーと管理者とする。

目的

どの重大度で無効化し、どの重大度で継続するかを決める。

前提

• 「重大度と対応期限」で、重大度が暫定または確定で付いている

• 無効化の代わりに、指示の新しいバージョンを作って切り替える方法がある［公式］

判断基準

• 重大度1：無効化する。原因が説明され、リーダーが承認するまで再有効化しない

• 重大度2：無効化するかを、当日中にリーダーと管理者が決める。判断の材料は、書き込みが再発する条件が分かっているかと、担当者の依頼を止める周知で足りるかとする

• 重大度3：継続する。同じ異常が2週間のうちに3回起きた場合と、原因を確かめた翌週もエラー数が増える前の水準に戻らない場合は、重大度2として扱う

• ロールの指示の誤りが原因と分かった場合は、指示の新しいバージョンへ切り替える案を管理者が作り、リーダーが承認する

実施内容

1. リーダーと管理者が、判断基準を当てはめる

2. 決めた判断と理由を台帳に記録する

3. 無効化した場合は、リーダーが担当者を従来の手作業へ戻す

4. 再有効化の前に、管理者が、原因に応じた範囲で開発設計書の受け入れ試験をやり直す

5. リーダーが、再有効化を承認する

設計理由

• 重大度2を一律に無効化しないのは、トリガーがなく実行は担当者の依頼から始まるので、周知だけで再発を防げる場合があるからである

• 原因の対処で定義が変わった可能性があるので、再有効化の前に試験をやり直す

例外

• 手作業へ戻る手順（検索は担当者の経験、解決メモは手書き）は、運用開始前にリーダーが担当者へ周知する

完了条件

• 台帳に、判断・理由・判断者・時刻が残っている。再有効化した場合は、承認者の氏名が追加されている

確かめ方

• TS-20 机上演習「解決メモ以外の項目の変更」［実施済み］：レビューで解決メモ以外の変更が見つかった場面で、停止から再有効化までの条件が決まるかを確かめた。結果は合格

• TS-21 再有効化の前の試験［未実施］：検証環境で、原因に応じた範囲の受け入れ試験をやり直す。合格基準は、やり直した試験の範囲と結果が台帳に記録されること

• 見直し：基準は、運用開始から3か月の異常記録を見て、リーダーが見直す

記入例

【判断】重大度2 → 無効化しない（周知で足りる）
【理由】食い違いは見出しの表示だけで、書き込み先は解決メモだった
【判断者】リーダー（氏名）・管理者（氏名） 【時刻】第8営業日 15:00

OR-10 停止と再開の権限

対象

複製ワークフローと複製したエージェントの無効化と再有効化。操作は管理者、承認はリーダーとする。

目的

止める権限を持つ人と、誰も動けないときの扱いを決める。

前提

• 無効化には sn_aia.admin が必要で、無効化した資産は実行されず、利用もできなくなる。いつでも再有効化できる［公式］

• 無効化の操作は、AI Agent Studio の「エージェント型ソリューション」で対象を開き、最初のノードの［無効化］を2回確認して実行する［公式］

• 無効化が、承認待ちで止まっている実行や実行中の処理に与える影響［未確認］

• 停止の要請は、リーダーまたは二次対応担当のだれからでも出せる

判断基準

• 無効化と再有効化の操作は、sn_aia.admin を持つ管理者2名だけが行う

• 重大度1は、「停止の判断基準」を待たずに無効化する

• 再有効化は、原因の説明をリーダーが承認した後に行う

• 管理者2名のうち少なくとも1名は、平日9時から18時に連絡がつくよう、休暇を重ねない

• リーダーが不在の日は、リーダーが事前に指名した二次対応担当が代わる。指名は運用台帳に記入する

実施内容

1. 管理者が、AI Agent Studio の「エージェント型ソリューション」で、複製ワークフローを開く

2. 重大度2の場合は、無効化の前に、承認待ちの実行を却下か取り消しで閉じる。閉じられない実行が残っても、無効化へ進む

3. 管理者が、最初のノードの［無効化］を押し、2回の確認に応える

4. 管理者が、無効化の日時・操作者・理由を運用台帳に記録する

5. 重大度1の場合は、無効化の後に、残った承認待ちの実行を却下か取り消しで閉じる。停止中は承認しない

6. リーダーが担当者から依頼を試し、起動しないことを確かめて台帳に記録する

設計理由

• 操作する人を管理者2名に限るのは、無効化に必要な sn_aia.admin を2名にだけ付与しているからである

• 重大度1では承認待ちの実行を待たないのは、書き込みの逸脱の拡大を止めることを優先するためである

例外

• 管理者2名とも連絡がつかない場合は、リーダーが情報システム部長へ連絡し、部長が管理者へ連絡をつける。同時に、リーダーが全担当者へ「AI エージェントへの依頼を止める」と周知する

• 周知は無効化の代わりにならず、すでに動いている実行も止めない。無効化は、管理者が戻り次第行う

完了条件

• 無効化の日時・操作者・理由が、運用台帳に残っている

• 無効化の後、担当者からの依頼で起動しないことの確認結果が、台帳に残っている

確かめ方

• TS-22 無効化と再有効化の操作［未実施］：検証環境で、公式の手順どおりに無効化と再有効化を行う。合格基準は、無効化中は担当者の依頼で起動せず、再有効化の後は起動すること

• TS-23 承認待ちの実行への影響［未実施］：検証環境で、承認待ちの実行を残したまま無効化する。合格基準は、残った実行の状況と、書き込みの有無が台帳に記録されること

• 見直し：管理者の増員・異動と、ロールの付与が変わったときに見直す

記入例

【無効化】日時: 第12営業日 14:20 / 操作者: 管理者（氏名）
【理由】重大度1（解決メモ以外の項目の変更の疑い）
【無効化後の確認】リーダーが依頼を試し、起動しないことを確認（14:35）

OR-11 ベンダーへの問合せ基準

対象

ServiceNow 社のサポート窓口（Now Support）への問合せ。実行は管理者、承認はリーダー、報告先は情報システム部長とする。

目的

自社の確認で解決できない異常を、どの条件でベンダーへ上げるかを決める。

前提

• 「書き込み権限を持つツールの定期棚卸し」の8項目と、対象インシデントの更新履歴の確認が済んでいる

• 窓口・サポートの時間帯・重大度の区分は、ひのき商事の契約で確かめていない

判断基準

• 問い合わせる条件は次の4つとする。無効化した後も新しい実行が始まる。承認の応答と異なる内容で書き込まれた。更新の後に、設計どおりの設定のまま動作が変わった。画面と REST で、トリガーなどの設定値が食い違う

• 自社の設定が設計から外れていた場合は、問い合わせずに「自社変更の本番反映」で是正する

• 問い合わせの期限は、重大度1は無効化した後の当日中、重大度2は2営業日以内とする。重大度3は、原因の確認後に要ると判断したときだけ問い合わせる

• 判断（回答を待たずに止める）：回答を待つ間も「停止の判断基準」を優先し、回答を待って無効化を遅らせない

実施内容

1. 管理者が、問い合わせる内容をリーダーへ示し、承認を得る。重大度1は、無効化の後に承認を得る

2. 管理者が、実行の識別子・発生日時・画面の保存画像・対象のインシデント番号を用意する

3. 症状の文章に氏名や連絡先が含まれる場合は、伏せる

4. 管理者が問い合わせ、窓口の受付番号を台帳に記録する

5. 回答の要旨と回答日を台帳に記録する

設計理由

• 問合せを製品の動きの食い違いに限るのは、自社の設定の誤りは自社で是正できるからである

例外

• 未決：契約上の窓口・サポート時間帯・重大度区分の確認。決める人は管理者、期限は運用開始前。確認が済むまでは、判断基準の期限を目安とする

完了条件

• 台帳に、問合せの日時・内容・窓口の受付番号・回答の要旨・回答日が残っている

確かめ方

• TS-24 問合せ資料の準備［未実施］：検証環境の実行記録で、問合せに添える一式を作る。合格基準は、実行の識別子と画面の保存画像がそろい、氏名と連絡先が伏せてあること

• 見直し：回答までの日数を3か月分記録し、リーダーが期限の目安を見直す

記入例

【問合せ日時】第12営業日 16:00 【受付番号】窓口の番号を転記
【内容】無効化の後も新しい実行が始まる（実行の識別子・画面の保存画像を添付）
【回答の要旨】回答日に記入 【回答日】

障害シナリオの机上演習

次の6つのシナリオで、運用ルールが、受ける人・決める人・終える条件を決めているかを確かめました。各ルールの「確かめ方」にある机上演習は、ここに書き出したものです。

シナリオ1：担当者の帰宅

17時20分に二次対応担当が書き込みの依頼を出し、承認カードに応答しないまま退社した。

• 受ける人：18時に、リーダーが残っている実行を確かめ、依頼者へ連絡する（承認待ちで止まった実行の処理）。連絡がつかなければ、翌朝10時までに当番が、進行中の実行として見つける（毎朝の実行履歴の点検）

• 決める人：依頼者が不在のため、管理者が翌営業日の10時までに、内容を台帳へ控えて取り消す

• 終える条件：進行中の件数が0になり、対象のインシデントの更新履歴に書き込みがないことを台帳に記録する

シナリオ2：解決メモ以外の項目の変更

レビューで、対象インシデントの別の項目に、依頼にない変更が見つかった。

• 受ける人：レビューを行ったリーダーが、重大度1として管理者へ直接連絡する（重大度と対応期限）

• 決める人：管理者が15分以内に無効化する（停止と再開の権限）。リーダーは全担当者へ、依頼を止める周知を出す

• 終える条件：担当者から依頼を試し、起動しないことを確かめる。誤って変更された項目は、二次対応担当が更新履歴から元の値へ戻し、リーダーが確かめる。原因が説明され、受け入れ試験をやり直して合格した後に、リーダーが再開を承認して再有効化する

シナリオ3：誤った内容の承認

担当者が本文を読まずに承認し、事実と異なる解決メモが書き込まれた。週次レビューで見つかった。

• 受ける人：レビューを行ったリーダー（生成された書き込みのレビュー）。重大な誤りとして、重大度2で扱う

• 決める人：二次対応担当が更新履歴から元の内容へ戻す。リーダーが、同じ誤りが続くかを見て、無効化するかを管理者と当日中に決める（停止の判断基準）。誤承認した担当者の扱いは、リーダーが決める

• 終える条件：解決メモが元の内容に戻り、台帳のレビュー欄と異常記録に記入されている。運用開始から4週間はレビューが全件のため、その間は書き込みの翌週までに見つかる

シナリオ4：夜間の書き込みと利用の急増

翌朝10時の点検で、18時以降に始まった実行があり、承認の操作がないまま書き込まれていた。あわせて、1日75回を超えた日が3日続いていた。

• 受ける人：当番。時間外に始まった実行は重大度1として、リーダーを経由せず管理者へ直接連絡する（毎朝の実行履歴の点検）。急増は「利用量の確認」へ回す

• 決める人：重大度1は、管理者が15分以内に無効化する。急増は、管理者が3営業日以内に原因を記録し、リーダーが継続か依頼の制限かを決める（利用量の確認）

• 終える条件：無効化の後、書き込まれた内容を更新履歴から戻し、原因を説明し、受け入れ試験をやり直して合格した後に、リーダーが再開を承認して再有効化する。急増は、原因と決定が台帳の月次欄に記入されている

シナリオ5：週次確認でのエラー増加

月曜10時の週次確認で、前週のエラー数が前々週の2倍に増えていた。低スコアのセッションを開くと、スパンの1つで検索ツールが空の結果を返していた。

• 受ける人：週次確認を行った管理者が、エラーの増加を暫定の重大度3とし、リーダーへ報告する（週次の稼働記録の確認）

• 決める人：リーダーが重大度3を確定し、管理者が5営業日以内に原因を確かめて、継続か停止かをリーダーへ報告する。同じ異常が2週間のうちに3回起きた場合は、重大度2として扱う（停止の判断基準）。原因の再現が要る場合は、リーダーの承認を得て、検証環境で手動実行する

• 終える条件：原因と、継続か停止かの決定を、リーダーが承認して台帳の週次欄に記入する。翌週のエラー数が増える前の水準へ戻ったことを、管理者が確かめて記録する。戻らない場合は、重大度2として扱う

シナリオ6：失敗した実行の出し直し

担当者の解決メモの下書きが failed で終わり、担当者がリーダーに、本番で実行し直すよう頼んだ。

• 受ける人：依頼を受けたリーダー。管理者による本番での代行実行は禁止のため、担当者へ、更新履歴で書き込みがないことを確かめてから、新しい依頼として自分でパネルから出し直すよう案内する（手動実行の許可と記録）

• 決める人：初回と再依頼の計2回が失敗した場合は、当番が実行を開いて失敗した段階を記録し、暫定の重大度3とする。リーダーが当日中に確定する。原因の再現が要るなら、リーダーが検証環境での手動実行を承認し、管理者が実行する

• 終える条件：再依頼が承認と書き込みの結果まで意図どおりに終わるか、担当者が手作業へ戻っている。台帳の点検欄の備考に、再依頼の有無と新しい実行の識別子が記入されている

6つのシナリオで、受ける人・決める人・終える条件は一通り決まりました。残っている未確認の事項は、管理者による取り消しの操作と必要な権限です。運用開始前に検証環境で確かめることを条件にし、取り消せない場合の最終判断者は未決として残しています。

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