資産管理（SAM・HAM・調達）のNow AssistとAIエージェント：OOTBの定義の確認

ソフトウェアの利用申請が承認されると、AIがライセンスを割り当て、足りなければ発注書まで作る。資産管理（SAM・HAM・調達）のAIエージェントには、そう動く設計のものがあります。どこまでが自動で、どこで人が止められるのでしょうか。今回のデモ環境（日本語表示）で定義を確かめると、ワークフローの表示は「監督対象」でも、読み取れたツールの実行モードはすべて自律でした。有効だったトリガーも、要求の調達ではなく、修理のタスクに付いたものでした。

定義の確認でわかったこと

• 資産・調達のOOTBワークフローは13件、スキルは35件

• ワークフローは全件が監督対象。定義を読めた15エージェントの57ツールは、すべて実行モードが自律で、承認で止まるツールは0件

• トリガーは8件で、有効なのは5件。修理・診断のタスク4件と、節減機会の画面操作1件

• ソフトウェア・ハードウェア・企業資産の要求を調達するトリガーは、定義レコードでは無効。ただしソフトウェア要求のトリガーは、定義画面の状態表示が Active で食い違う。公式の「1回の手動の有効化が必要」という説明と合わせて、有効化前に画面で確かめる対象になる

• 任せる範囲は、機能の種類ごとに決める

試行は定義の確認に限ります。定義は読み取り専用のAPIで取得し、トリガーとメンバーのエージェントの定義画面も読み取りだけで開きました。ワークフローをパネルから起動する試行は、記事の後半に書いた2回だけです。2回とも、ワークフローは起動しませんでした。設定の変更と保存は0件で、試行用に作ったレコードはすべて削除しました。製品全体の評価ではなく、有効化の前に確かめる観点を洗い出すケーススタディです。

資産・調達のAIエージェントは13のワークフローで構成される

対象は、製品グループ「資産・調達・財務」のOOTBワークフロー13件です。SAM・HAM・企業資産・調達・契約・ERPに関わるものを数えています。エージェント型ワークフローは、複数のAIエージェントとツールをまとめて1つの目的を進める単位です。公式ドキュメントは、これらを「ServiceNow Otto for SAM」「ServiceNow Otto for HAM」などの名前で説明しています。

表の内容を文字でも書き出します。「有効化の記録」は、ワークフローの有効化を上書きしたレコードがあるかどうかです。

• Help manage software requests（ソフトウェア要求の管理を支援）：承認済みの要求に権利を割り当てるか、発注書を作る。トリガーは定義レコードで無効（画面の状態欄はActive）で、有効化の記録はある

• Create software reclamation rule（ソフトウェア再利用ルール作成）：使用状況を分析し、再利用ルールを作る。手動で、有効化の記録はある

• Evaluate software removal candidate（ソフトウェア削除候補の評価）：削除候補を評価し、確認後に再利用する。手動で、有効化の記録はある

• Help manage hardware asset requests（ハードウェア資産要求の管理を支援）：在庫の消費・転送・購入で要求を履行する。トリガーは無効

• Help repair hardware assets（ハードウェア資産の修復を支援）：修理の手順を示し、確認後にタスクを更新する。担当者の変更で自動起動するトリガーが有効

• Help manage enterprise asset requests（企業資産の依頼管理の支援）：消費・転送・調達のいずれかで要求を履行する。トリガーは無効

• Help repair enterprise assets（企業資産の修理の支援）：修理・診断の手順を示し、資産を戻す。担当者の変更で自動起動するトリガーが有効

• Define PO exception mitigation strategy（PO 例外の緩和戦略を定義）：配送ギャップを分析し、変更要求を作る。手動

• Conversational intake for sourcing and procurement（ソーシングと調達のための会話型取り込み）：製品・サプライヤーの推奨と発注の取り込みを会話で進める。手動

• Savings Opportunity Discovery（節減機会のディスカバリー）：契約と支出から節減機会を見つける。画面操作で起動する

• Manage contract repository（契約リポジトリを管理）：契約の更新期限などのメタデータを抽出する。手動

• Conversational Contract Search and Insights（対話型契約の検索とインサイト）：契約を検索し、条項を分析する。手動

• Explore ERP models（ERP モデルの詳細）：ERPモデルの質問に答え、該当する操作を実行する。手動

エージェントは、この製品グループに34件あります。うち9件は買掛金・サプライヤー管理・サービスレベル目標が対象のため、この記事の主題から外しました。残る25件のうち、定義を読めたのは15件です。

起動のきっかけから結果までの流れを、次の図にまとめました。

起点は資産・調達の依頼とレコードの更新、橙は有効なトリガーが付いている経路、緑は分析・回答の表示が中心の結果、赤は承認なしで記録を書き換える結果、灰色は OOTB に該当がない経路

有効なトリガーが付いているのは、修理系の2件と節減機会の1件です。赤の結果には、権利の割り当て・発注書・転送注文・再利用ルールの作成など、記録を書き換えるものが集まっています。灰色の「人の承認で止まるツール」は、確認できた57ツールに該当がありませんでした。

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

• 起動の分け方は3種類。手動で依頼する／タスクの担当者が変わる（修理・診断タスクの有効なトリガー）／画面の操作（節減機会の UI アクション）

• 手動で動かすのは10のワークフロー（要求の履行・再利用ルール・削除候補・PO 例外・契約・調達の取り込み・ERP）。結果は分析・回答の表示か、資産・契約・発注の記録の書き換え

• 自動で動くのは2つのワークフロー（ハードウェア資産の修復・企業資産の修理）。結果は記録の書き換え

• 節減機会のディスカバリーは UI アクションで起動し、分析の表示と記録の書き換えの両方につながる

• 人の承認で止まるツールは、確認できた57ツールに該当なし

定義画面のトリガー欄で、修理のワークフローを確かめました。診断タスクと修理タスクの作成・更新で動く2件があり、状態はどちらも Active です。

Now Assistスキルは35件で、SAMと調達に集中している

生成AIスキルは、エージェントとは別の部品です。レコードの画面に出る要約や下書きの生成が中心で、ワークフローのように複数のツールを連ねて動くものではありません。対象は、SAM・HAM・資産監査・調達・共通の35件です。HAMの内部部品1件は、機能として数えていません。

表の内容を文字でも書き出します。スキル名は製品の英語名で、日本語は筆者の言い換えです。

• Publisher compliance summarization（パブリッシャーのコンプライアンス要約）：パブリッシャー単位のライセンス条件を要約し、対応案を示す。有効（SAM）

• Product compliance summarization（製品のコンプライアンス要約）：製品単位のライセンスルールと最適化の機会を要約する。有効（SAM）

• Recommended actions（推奨アクション）：コンプライアンスの要約をもとに、次の対応案を生成する。有効（SAM）

• Software normalization（ソフトウェア正規化）：検出されたデータから標準のパブリッシャー名と製品名を特定する。有効（SAM）

• Product match reviewer（製品一致のレビュー）：予測した製品名を検索結果と照らし合わせる。有効（SAM）

• SaaS user resolution（SaaSユーザーの解決）：SaaS連携の購読データから、ユーザー解決ルールを作る。有効（SAM）

• Contract entitlement data extraction（契約からのエンタイトルメント抽出）：ソフトウェア契約からライセンス情報を抽出し、権利を作る。有効（SAM）

• Error log summarization（エラーログの要約）：ノイズの多いログを、構造化したエラーの要約にする。有効（SAM）

• Error resolution recommendation（エラー解決の推奨）：エラー分析とナレッジから、解決手順を提案する。有効（SAM）

• Generate hardware asset insights（ハードウェア資産インサイトの生成）：資産の要約と推奨を生成する。有効だが非表示（HAM）

• Evidence summarization（証拠の要約）：資産証拠要求の完了期間と、ログの情報を示す。有効（資産監査）

• Summarization for fulfillers／requesters（履行者向け5件・要求者向け3件の要約）：調達ケース・ソーシングイベント・交渉・購買要求・発注書の進捗を要約する。有効（調達）

• Email response（メール応答8件）：ケースやタスクに合わせて、メール返信の下書きを作る。有効（調達）

• Category Prediction（カテゴリ予測2件）：確信度が足りないときに、製品と支出のカテゴリを提案する。有効（調達）

• Sentiment analysis for procurement case（調達ケースの感情分析）：要求者の感情を分析し、優先順位付けを助ける。有効（調達）

• Document extraction（文書抽出）：文書から情報を抽出する。定義の説明文は空。有効だが非表示（調達）

• Purchase order summarization／Supplier summarization／Field Extractor（発注書・サプライヤーの要約と項目抽出）：履行者が状況を把握するための要約と抽出。有効（共通）

• Inquiry Classifier（照会の分類）：照会ケースのサブカテゴリを入力する。無効（共通）

SAMのスキルは、ライセンス条件の要約と、名前の正規化・照らし合わせに使うものが大半です。ワークフローと違い、ほとんどがレコードの画面で人が結果を見る生成と読めます。画面での表示は確かめていません。

確認の対象にした環境と、確認しなかったこと

既存の資産・購買・契約のレコードは開いていません。ワークフローを動かすと、デモ環境のレコードに書き込みが及ぶ可能性があるためです。例は、ライセンスの割り当てと、発注書や転送注文の作成です。Microsoft 365側のライセンス操作も含まれます。

定義の確認が中心です。確認したのは、ワークフローとトリガー、有効化の上書き、エージェントのツールと実行モードです。主に読み取り専用のAPIで取得しました。ソフトウェア要求と修理の定義画面は、APIの値と見比べるために読み取りだけで開いています。件数の基準は、製品別のOOTBカタログと同じです。出荷物と確認できたものだけを数え、デモ側で追加されたものと判定保留のものは除きました。

AI Agent「Help manage software requests」の定義確認

承認済みのソフトウェア要求を、既存のエンタイトルメント（利用権）の割り当てか、発注書の作成で履行するワークフローです。定義で確かめたのは次の点です。

• トリガーは1件。対象は要求アイテム（sc_req_item）の作成・更新時で、チャネルはNow Assistパネル。実行ユーザーは担当者

• 条件は、担当者が空でなく、担当者がAIでなく、承認済みで、アイテムのモデルクラスがソフトウェアモデルで、調達済みでないこと

• トリガーの状態は、定義レコードの active が false（無効）。一方、定義画面の状態欄は Active と表示される。2つの読み取りが食い違うため、このトリガーが有効かどうかは断定しない

• メンバーのエージェントは3つ。Microsoft license assignment AI agent（ツール3）、Software entitlement allocation AI agent（ツール2）、Purchase order creation AI agent（ツール6）

• ツールは11個とも自律。License allocation は権利の割り当て、AssignLicenseToUser は Microsoft 365側のライセンスの割り当て、Create purchase order for requested item は発注書の作成を行う

公式ドキュメントはこのワークフローのメンバーに Purchase order creation AI agent を挙げており、定義画面でも3つが並びます。発注書を作るツールまで、このワークフローが自律で呼べる構成です。

トリガーの状態は、公式の説明と合わせて有効化前に画面で確かめます。公式には次の記述があります。

（訳: Help manage software request ワークフローを自動で実行する前に、1回の手動の有効化が必要）

引用元：<https://www.servicenow.com/docs/r/it-asset-management/software-asset-management/now-assist-sam-fulfill-sw-asset-requests-workflow.html>

有効化すると、条件に合う要求が割り当てられた時点で、権利の割り当てまで人の承認なしに進む可能性があります。公式ドキュメントは、調達担当者に確認を取る場面を説明しています。ただしツールの実行モードでは、その確認は設定されていませんでした。

AI Agent「Create software reclamation rule」の定義確認

ソフトウェア製品のライセンス使用状況を分析し、再利用ルールが無ければ作成を提案して作るワークフローです。再利用ルールは、使われていないライセンスを回収する条件です。

• トリガーはなく、手動で起動する。公式ドキュメントによると、必要なロールは sam_admin。起点は Software asset overview・Publisher details・License operations の各ページ

• エージェントはSoftware reclamation rule creation AI agent。ツールは4つで、再利用ルールの提案の取得、ルールの作成、VIP条件を付ける既存ルールの更新を含み、すべて自律

• ワークフローは有効化の記録があり、有効

関連する Evaluate software removal candidate は、使用状況から削除候補を評価し、確認後に再利用します。ツールの Reclaim removal candidates は自律です。公式ドキュメントでは、Ready 状態の候補だけが再利用できます。

どちらも「ユーザーの確認に基づいて」書き込むと説明されています。確認は会話の中で取るものと読め、ツールの承認設定とは別の仕組みと見られます。

AI Agent「Help repair hardware assets」の定義確認

壊れた、または保証切れのハードウェア資産について、修理や診断の手順を示し、確認後にタスクを更新するワークフローです。

• トリガーは2件で、定義レコードも定義画面もどちらも有効（Active）。対象は診断タスク（sn_itam_common_troubleshoot_task）と修理タスク（sn_itam_common_repair_task）の作成・更新時

• 条件は、担当者が変わり、担当者が空でなく、資産モデルがハードウェアまたは消耗品で、OTエンティティでなく、状況が完了系でないこと

• 実行ユーザーは担当者。チャネルはNow Assistパネル

• エージェントは3つ。資産評価（診断）と資産修復（修理）のツールは2つずつで、Use web search と、結果を記録する Repair Order のツール。3つ目の資産の次のベストアクションは、Get task details and perform validation の1ツール。実行モードはすべて自律

次の画像は、同じワークフローの定義画面でメンバーのエージェントを確かめたものです。

公式ドキュメントは、技術者への担当割り当てで、このワークフローが自動で起動すると説明しています。有効なトリガーは、その説明と一致する状態です。修理の手順は、資産のモデルとメーカーでWeb検索して探します。

この環境では、要求の調達より先に、修理のトリガーが有効でした。企業資産向けの Help repair enterprise assets も、同じ形のトリガーが2件有効です。

AI Agent「Help manage hardware asset requests」の定義確認

ハードウェアの要求を、ローカル倉庫の在庫の消費、倉庫間の転送、ベンダーからの購入のいずれかで履行するワークフローです。

• トリガーは1件で、要求アイテムの作成・更新時。担当者の割り当てや承認済みなどが条件で、定義レコードでは無効（画面は未確認）

• メンバーはHardware asset management sourcing AI agent（ツール8）と、Transfer order creation AI agent（ツール5）。13ツールすべて自律

• ツールには、在庫の消費、転送注文の作成が含まれる

公式ドキュメントは、自律の範囲を倉庫の設定で決めると説明しています。倉庫ごとの Auto-consume（在庫の自動消費）、Auto-transfer（倉庫間の自動転送）、Auto-purchase（発注書の自動作成）の3つです。ワークフローの有効化とは別に、倉庫のデータで動く範囲が変わります。

引用元：<https://www.servicenow.com/docs/r/it-asset-management/hardware-asset-management/now-assist-ham-fulfill-req-agent-workflow.html>

パネルから起動を試したが、始まらなかった

このワークフローを、パネルから動かせるかを試しました。ワークフローを動かすと書き込みが及ぶため、検証用に作ったレコードだけを使いました。

先に、使った元のレコードを説明します。

• 要求アイテム：標準のカタログ品目「EliteBook 850 Gen 4」を、メールアドレスも上長も無い検証用ユーザーが申請した1件。承認は「承認済み」にした

• 在庫：検証用の拠点と倉庫を1つずつ作り、同じ機種の資産を在庫ありで1件置いた。倉庫の自動消費・自動転送・自動購入は、どれも無効のまま

• 狙い：自動設定が無い倉庫では、ワークフローが調達計画を示して確認を求める、という公式の説明を確かめること

結果は次のとおりです。

• 1回目：要求アイテムの番号を示して履行を依頼した。72秒後に「申し訳ありません。この要求を完了しようとしてこちら側で問題が発生しました」と表示された。実行記録のユースケースは、ハードウェア要求のワークフローではなく「デフォルトの VA ワークフロー」で、状態は進行中のままだった

• 2回目：倉庫の在庫から履行する計画を立てるよう、言い換えて依頼した。パネルには「関連情報を確認いたします」と表示され、確認を終えた時点でも処理中だった。調達計画や承認の表示は出なかった

• パネルの候補ボタンにも、このワークフローは並ばなかった。要求アイテム用のトリガーは定義上は無効で、手動で起動する方法が見当たらない

起点はパネルからの依頼、青は依頼の内容、赤は期待どおりに始まらなかった結果、緑は標準のカタログの流れで動いたこと、灰色は起動できなかったワークフロー

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

• 1回目：要求アイテムの番号を示して履行を依頼。72秒後に問題発生の返信。実行記録のユースケースはハードウェア要求のワークフローではなかった

• 2回目：倉庫の在庫から履行する計画を立てるよう言い換えて依頼。処理中のまま。調達計画や承認の表示は出なかった

• ハードウェア要求のワークフローは、パネルの候補ボタンに並ばない。要求アイテム用のトリガーは定義上は無効で、手動で起動する方法が見当たらない

• 一方で動いたこと：要求アイテムを作っただけで標準のカタログの流れが動き、調達グループ宛の「Source Request Items」タスクが自動で作られた

この試行から言えることを書き出します。

• このワークフローの起動は、要求アイテムの担当者割り当てによるトリガーに限られると見られる。有効化せずにパネルで頼んでも、別のワークフローが受ける

• 今回はトリガーを有効にしていない。有効にすると、既存のデモの要求アイテムに反応する可能性があるため。有効にしたときに計画が示されるかどうかは確かめていない

• 修理のワークフローはトリガーが有効だが、Web検索のツールが外部のインターネットに問い合わせるため、動かしていない

試行で気づいたことが1つあります。検証用の要求アイテムを作っただけで標準のカタログの流れが動き、調達グループ宛の「Source Request Items」タスクが自動で作られました。通知も、グループのメンバー6人分の宛先で作られています。宛先は架空のドメインで、送信には至りませんでした。要求アイテムの作成は、AIとは別に、このような副作用を持ちます。

作成したレコードは、自動で作られたタスクと実行記録を含めて削除し、0件になったことを確かめました。

公式ドキュメントは、有効化の手順とロールを分けて説明している

公式ドキュメントが説明する前提のうち、調達トリガーの無効は実機の定義と矛盾しません。ロールと製品ティアは、実機では確かめていません。

• 要求を調達するワークフローは、1回の手動の有効化（トリガーのOffからOn）が前提。実機の調達トリガー3件は定義レコードでは無効。ただしソフトウェア要求の1件は定義画面で Active と表示される

• ロールはワークフローごとに違う。再利用ルールは sam_admin、ソフトウェア要求・ハードウェア要求は procurement_user と itil と now_assist_panel_user、修理は inventory_user。パネルを使うには now_assist_panel_user が要る

• 製品ティアにより、使えるスキルやワークフローが変わる

ソフトウェア要求の説明には、既定の自動承認額が1,000ドルとも書かれています。自動承認の閾値は組織ごとに変えられます。

公式ドキュメントは次のとおりです。

• SAMのエージェント型ワークフロー

• ソフトウェア要求の管理

• 再利用ルールの作成

• 削除候補の評価

• ハードウェア資産要求の管理

• ハードウェア資産の修復

任せる範囲は、機能の種類ごとに決める

ここからは、試していない部分を含む筆者の推奨案です。判断の軸は、機能の種類ごとに、起動の条件と書き込みの範囲に置きます。種類は、流れ図の結果に合わせて4つに分けます。

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

• 分析・回答を表示するだけの機能：例は Conversational Contract Search and Insights（対話型契約の検索とインサイト）。決めること＝起動できるロール、読める契約・支出の範囲

• 手動で依頼して記録を書き換える機能：例は Create software reclamation rule（ソフトウェア再利用ルール作成）。決めること＝依頼できるロール、会話での確認の運用

• レコードの更新で自動的に動く機能：例は Help repair hardware assets（ハードウェア資産の修復を支援）。決めること＝トリガーの条件、対象の資産クラス、止める手順、Web検索で外へ出る情報

• 外部サービスや発注に及ぶ機能：例は Help manage software requests（ソフトウェア要求の管理を支援）。決めること＝連携先の権限、自動承認の閾値、倉庫の自動設定

分析・回答を表示するだけの機能は、見えるデータの範囲を先に決める

契約の検索と分析、調達の会話型取り込み、ERPモデルの質問、節減機会の分析がこの種類です。表示と分析が目的の機能です。ただし契約系のエージェントはツールを読めておらず、書き込みの有無は確かめていません。契約や支出のデータは、見てよい人が決まっています。決めるのは、起動できるロールと、AIが読める契約・支出の範囲です。

手動で依頼して記録を書き換える機能は、依頼できる人と確認の手順を決める

再利用ルールの作成、削除候補の再利用、PO例外の緩和、契約リポジトリの管理がこの種類です。ツールの実行モードは自律のため、設定上は承認で止まる仕組みがありません。確認は会話の中で取る設計です。そのため、sam_admin のように依頼できるロールを絞り、会話での確認を運用ルールにします。実行モードを監視中へ変えれば止められる可能性があります。ただし今回は設定を変更しておらず、そうなるかは確かめていません。まず検証用のデータだけで試します。

レコードの更新で自動的に動く機能は、条件・対象・止め方を決める

修理・診断のタスクがこの種類です。トリガーの定義では、担当者が変わるたびに、条件に合うタスクが起動の対象になります。決めるのは、トリガーの条件・対象の資産クラス・実行ユーザー・止める手順の4点です。止める手順の候補は、トリガーを Inactive にすることです。今回は切り替えておらず、止まるかどうかは確かめていません。

修理の手順はWeb検索で探します。モデル名やメーカー名のどこまでを外に出してよいかも、あわせて決めます。

外部サービスや発注に及ぶ機能は、連携先と自動の範囲を決める

ソフトウェア要求のMicrosoft 365ライセンス割り当て、発注書の作成、転送注文の作成がこの種類です。決めるのは、Microsoft 365との接続と権限、自動承認の閾値、倉庫の Auto-consume・Auto-transfer・Auto-purchase の設定です。倉庫の設定を確認してから有効化すれば、自動になる範囲を想定内に収められます。

導入前の確認リスト

分析・回答を表示するだけの機能

• □ 起動できるロールと、読める契約・支出の範囲を決めた

手動で依頼して記録を書き換える機能

• □ 依頼できるロール（例：sam_admin）を絞った

• □ 会話での確認を、運用ルールとして共有した

レコードの更新で自動的に動く機能

• □ 有効にするトリガーと、その条件・対象を決めた

• □ 止める手順（トリガーを Inactive にする）を共有した

• □ Web検索で外へ出る情報の範囲を決めた

外部サービスや発注に及ぶ機能

• □ 連携先の接続と権限を確認した

• □ 自動承認の閾値と、倉庫の自動設定を確認した

実機で気づいたこと

監督対象と表示されていても、ツールは自律だった

ワークフロー13件の実行モードは、すべて「監督対象」でした。それでも、定義を読めた15エージェントの57ツールは、すべて自律でした。承認で止まる設計かどうかは、ワークフローの表示では決まりません。ツール単位の実行モードで確かめます。

書き込みを伴う代表的なツールを、種類ごとに書き出します。

• 権利・ライセンス：License allocation、AssignLicenseToUser

• 再利用：Create reclamation rule、Reclaim removal candidates

• 発注・在庫：Create purchase order for requested item、Create transfer order、Consume the assets

• 変更・案件：Create Change Requests、Create Pipeline Project

• 修理：Repair Order の結果を記録するツール

資産評価 AI エージェントのツール欄でも、実行モードは自律です。会話のトピックの Repair Order - Troubleshooting result と、Web 検索の Use web search が並びます。

有効なトリガーは、調達ではなく修理だった

8件のトリガーのうち、定義レコードで有効なのは修理・診断の4件と節減機会の1件でした。要求の調達は、ソフトウェア・ハードウェア・企業資産のすべてが定義レコードでは無効です。ソフトウェア要求だけは、定義画面の状態欄が Active で、読み方によって結果が分かれます。担当者を割り当てるだけで動くのは、この環境では修理系です。有効化の前に、どのトリガーが有効かを一覧で確かめます。

同じトリガーの状態が、定義レコードと画面で食い違った

ソフトウェア要求のトリガーは、定義レコードの active が false なのに、定義画面の状態欄は Active でした。修理のトリガーは両方とも Active で一致しています。どちらが実際の起動を決めるかは、担当者を変えて動かしていないため分かりません。有効化の前に、定義画面とレコードの両方で状態を確かめます。

メンバーのエージェントは、公式ドキュメントと同じ3つが定義画面に並びました。取得の仕方によっては、共有されたエージェントが一覧から欠けることがあります。メンバーは画面でも数えます。

有効だが非表示のスキルがある

HAMの Generate hardware asset insights と、調達の Document extraction は、有効でも製品内で非表示の状態でした。一覧で有効と見えても、画面に出るとは限りません。

用語

• SAM：Software Asset Management。ソフトウェアのライセンスの購入数と利用状況を管理する製品

• HAM：Hardware Asset Management。ハードウェア資産の在庫・要求・修理を管理する製品

• SPO：Sourcing and Procurement Operations。調達と購買の業務を扱う製品

• エージェント型ワークフロー：複数のAIエージェントをまとめ、目的に沿って手順を進める単位

• 実行モード：ツールごとの設定。監視中は実行前に承認を待ち、自律はそのまま実行する

• 再利用ルール：使われていないソフトウェアのライセンスを回収する条件

付録：自分の環境で確認するときのURL

• ワークフローの一覧：/sn_aia_usecase_list.do

• トリガー：/sn_aia_trigger_configuration_list.do

• 有効化の状態：/sn_aia_usecase_config_override_list.do

• ツールの実行モード：/sn_aia_agent_tool_m2m_list.do

検証範囲とおことわり

2026-10-02に、Australia（Patch 5）のNow Assistデモ環境で、日本語表示のみ確認しました。ワークフロー13件のトリガー・有効化・メンバーのエージェント・ツールの実行モードを、読み取り専用のAPIで取得しています。AI Agent Studioの定義画面は、ソフトウェア要求と修理の2つについて、トリガーとメンバーを読み取りだけで開きました。記事のタイトルにある「OOTB定義の確認」は、定義の確認を指し、ワークフローを実行した結果に基づく利用可否の判定は含みません。

既存の資産・購買・契約のレコードは開いていません。ワークフローの起動を試した2回は、自作の検証用レコードだけを使い、ワークフローは起動しませんでした。設定の変更と保存は0件です。

未確認のことは次のとおりです。

• 有効なトリガーがある状態で、担当者を変えたときの実際の挙動

• 実行モードを監視中に切り替えた場合に、承認で止まるか

• Microsoft 365との連携が、この環境で接続されているか

• 修理のWeb検索で、どの情報が外へ出るか

• 修理系で、ワークフローの有効化の記録が無いまま、トリガーだけが有効な理由

• ソフトウェア要求のトリガーが、定義レコードでは無効、定義画面では Active になる理由と、実際に起動するか

• ツールを読めなかった10エージェント（集計でしか見えなかったもの）の有効状態と実行モード

• 日本語表示以外の画面

• 買掛金・サプライヤー管理・サービスレベル目標のエージェント

関連記事

• Now Assist は標準で何が入っている？ 製品別のOOTBスキル一覧

• SAM（ソフトウェア資産管理）とは何か

• ライセンス数とインストール数の突合