AIエージェント 業務のオブザーバビリティとは、回答が返ったかだけでなく、業務要求を受けてから、どのモデル・データ・ツール・承認を通り、どの業務結果に到達したかを、運用担当者が再構成できる状態です。製造業では、会話ログだけでは足りません。設備、品番、ロット、指図、シフト、工場時刻、ツール実行、作業者の修正、コストまでを一つの相関IDで結び、異常検知、原因切り分け、SLA確認、改善判断に使える証拠へ変える必要があります。本稿ではタイの工場を含む多拠点運用を想定し、テレメトリ設計、RFP、90日導入、受入までを実務単位で整理します。
先に結論：監視対象はモデルではなく「業務セッション全体」
LLMのAPI応答時間だけを見ても、AIエージェントの業務品質は分かりません。エージェントは検索、計画、ツール選択、ERPやMESへの照会、承認待ち、再試行、引き継ぎを組み合わせます。最終回答が正しく見えても、禁止データを読んだ、誤った設備を照会した、同じ依頼を二重実行した、作業者が毎回修正している、といった問題が隠れ得ます。
したがって、観測の最小単位は一回のモデル呼出しではなく、業務目的を持つセッションです。その下に一つ以上のトレースを置き、さらにモデル生成、検索、ツール呼出し、承認、ガードレール、外部API、手動介入をスパンとしてつなぎます。OpenAI Agents SDKの公式資料も、トレースを一つのエンドツーエンド・ワークフロー、その構成要素を開始・終了時刻と親子関係を持つスパンとして説明しています。これは有用な実装例ですが、特定製品の形式をそのまま社内標準にする必要はありません。
本稿の対象はテレメトリと運用測定です。AIエージェント API運用は基盤/APIの運用、AIエージェント 継続評価・監査は評価と再承認、AIエージェント インシデント対応は事故後の封じ込めと復旧を中心に扱います。オブザーバビリティは、それらへ時系列の証拠を供給する横断層です。
AIエージェント トレーシングの基本モデル
セッション：業務目的と利用者の文脈
セッションは単なるチャット画面の滞在時間ではありません。「Line 3の停止要因を確認し、保全依頼案を作る」「不足部品を特定し、購買申請を承認待ちへ置く」といった業務目的の単位です。セッションには、business_case_id、site_id、user_role、開始・終了時刻、結果、関連する工場日、データ分類、使用ポリシー版を持たせます。
会話が翌日に継続しても同じ案件なら、画面上のconversation IDとは別に業務IDで結びます。逆に同じ会話画面で複数の指図を処理したなら、指図ごとに別トレースを持たせます。画面の都合と業務証跡の単位を混同しないことが、後の原価・品質・責任追跡に効きます。
トレース：一つの結果までの実行経路
トレースは「一つの業務要求が結果へ進む経路」です。trace_id、session_id、開始主体、エージェント版、モデル設定、開始・終了、status、最終結果、関連する外部transaction_idを持ちます。複数エージェントへ引き継いだ場合も、親トレースまたはリンクで全体を追えるようにします。
重要なのは、トレースをモデルの思考過程そのものと表現しないことです。観測できるのは、許可された入力・出力、検索先、ツール要求、ポリシー判定、承認、外部応答、時刻、使用量などです。内部推論を完全に説明できると誤認すると、監査で説明可能な事実と推測が混ざります。
スパン：遅延・失敗・責任を切り分ける操作単位
スパンはモデル生成、RAG検索、データ変換、ツール呼出し、approval wait、human overrideなど、一つの開始と終了を持つ処理です。最低限、span_id、parent_span_id、operation_name、start/end、status、error_type、attempt、service、site、tool、model、input/output referenceを持たせます。
全処理を細かく分ければよいわけではありません。スパンが細かすぎると費用と調査時間が増え、粗すぎると原因が分かりません。分割基準は「担当サービスが変わる」「失敗時の復旧方法が変わる」「課金単位が変わる」「承認または外部副作用が発生する」です。
工場コンテキストを証拠へ結ぶ
汎用チャット監視と工場のAIエージェント監視の差は、物理工程の文脈です。同じ「異常」という出力でも、設備ID、品番、ロット、レシピ、設備モード、シフト、センサー鮮度、保全状態が違えば意味が変わります。トレースへ次の参照を追加します。
- site_id、area_id、line_id、asset_id
- work_order_id、batch_id、lot_id、product_code
- shift_id、工場ローカル時刻とUTC、タイムゾーン
- recipe/version、PLC/MES/ERPのtransaction_id
- sensor_snapshot_id、取得時刻、品質フラグ、欠測状態
- model、prompt、policy、tool、connector、knowledge_baseの各version
- operator_idまたは仮名化ID、role、approval_id
- 最終業務結果と、後日確認できる品質・停止・納期の参照先
ただし、全センサーデータや文書本文をトレースへ複製してはいけません。証拠保管庫にスナップショットを置き、トレースには改ざん検知用ハッシュ、時刻、保管先参照、スキーマ版を残す設計が現実的です。これによりテレメトリ基盤を新たな機密データレイクにせず、必要時に権限付きで再構成できます。
工場の時計ずれも見逃せません。クラウド、端末、MES、PLC、カメラの時刻がずれると、一つの事象が逆順に見えます。同期状態とtimestamp sourceを記録し、UTCを共通軸に、現場表示はICTなどのローカル時刻を併記します。時刻品質が低いデータを無理に一列へ並べるより、不確実性を明示した方が調査に強い証拠になります。
LLM observabilityのメトリクスを五つの層で設計する
1. 利用量：誰が何のために使っているか
session数、active user、業務種類、拠点、シフト、エージェント版、完了状態を集計します。多いこと自体を成功としません。利用量は、品質・時間・人手・業務成果と組み合わせて初めて意味を持ちます。利用が急増した時は、価値が出た場合だけでなく、再試行ループやUI不具合も疑います。
2. 信頼性：完了・エラー・再試行・重複
成功率だけでなく、error rate、timeout、retry、partial completion、duplicate side effect、dead-letter、tool denial、fallback、abstentionを分けます。エージェントが「分からない」と安全に棄権した場合は、システムエラーと分離します。棄権率の増加は、データ欠損や範囲外要求を早く示すことがあります。
3. 応答性：人が待った時間を分解する
end-to-end latency、time to first response、model latency、retrieval latency、tool latency、approval wait、queue waitを分けます。平均だけではピーク時の停止を隠すため、percentileと分布を使います。ただし、数値目標は用途別に決めます。品質調査の支援と、ライン停止中の初動では許容時間が異なります。
4. 人との協働：override、承認、引き継ぎ
approval request、approve/reject、human handoff、operator edit、override reason、再入力回数、未処理時間を記録します。overrideが多いエージェントは、モデル品質だけでなく、マスター不備、権限不足、画面の確認しづらさ、現場用語のずれが原因かもしれません。修正内容を自由文だけでなく、reason codeと差分で残します。
5. 価値とコスト：モデル課金を業務結果へ結ぶ
入力・出力token、モデル呼出し、検索、外部API、ログ保管、評価処理、人的レビュー時間をbusiness_case_idへ配賦します。cost per sessionだけでなく、cost per completed case、cost per approved action、cost per avoided manual minuteなどを社内の提案指標として設計できます。ただし「回避できた」とする基準とbaselineは先に合意し、推定値と実績を分けます。
OpenTelemetryのGenAI semantic conventionsには、モデル、操作、token、response ID、finish reason、time to first chunk、retrieval、tool callなどの属性が用意されています。相互運用の出発点になりますが、仕様は版管理され、属性の移動や非推奨化も起こります。RFPではsemantic convention versionを固定し、社内カノニカル項目とのmapping tableを納品物にします。
AIエージェント SLAは三層に分ける
「99.9%稼働」だけでは、エージェントが業務を完了したか分かりません。SLA/SLOは次の三層に分けると契約しやすくなります。
- 技術サービス水準：API可用性、トレース取込、ツール接続、キュー処理、監視遅延
- エージェント実行水準：session完了、end-to-end latency、エラー、棄権、重複副作用、承認待ち
- 業務成果水準：正しい指図への紐付け、人の修正、処理時間、期限内完了、品質結果
以下は設計例であり、一般基準ではありません。
| 指標 | 提案例 | 測定上の注意 |
|---|---|---|
| 重要業務のtrace capture | 99.5%以上 | 何を重要業務とするか、欠落時に止めるかを定義 |
| p95 end-to-end latency | 30秒以内 | approval waitを含む値と除く値を併記 |
| 禁止された重複書込 | 0件 | idempotency keyと外部transactionで照合 |
| セッション失敗率 | 2%未満 | abstention、拒否、ユーザー中断を別分類 |
| コスト異常 | baseline比+30%で警告 | baseline期間・季節性・業務mixを固定 |
| override率 | 20%超でレビュー | 良い介入と品質不良を理由コードで分離 |
数字は工場の損失構造、処理件数、許容待ち時間、監督体制から置き換えます。少量業務で百分率だけを使うと一件の影響が大きいため、件数と率を併記します。NIST AI 600-1も、文脈と限界を理解せず定量指標へ過度に依存することをリスクとして扱っています。ダッシュボードは判断の入口であり、結論そのものではありません。
ツール呼出しを「副作用の台帳」として見る
AIエージェントの重大な証拠は、何を答えたかより何を実行したかです。各tool callに、tool_name/version、caller、target、operation、argument reference、policy decision、approval、idempotency key、request/response status、external transaction、retry、compensationを残します。
ツール引数には仕入先、価格、設備、個人情報、tokenなどが含まれ得ます。生の引数を無制限に保存せず、項目ごとにallow、mask、hash、drop、secure-referenceを決めます。たとえばasset_idは平文で検索可能、自由文コメントは機密分類後に別保管、secretは記録禁止、購買金額は閲覧ロールを限定する、といった規則です。
承認は独立したスパンにし、提案時のpayload hashと実行時のpayload hashを照合します。承認後に対象、数量、設備状態が変わったら、同じapproval IDで実行させません。人が拒否した時も、理由、待ち時間、代替処理を残すと、権限設計とUI改善の材料になります。
エラー、棄権、overrideを一つに混ぜない
運用現場では次の状態を分けます。
- system error：サービス、ネットワーク、認証、schemaなどの技術障害
- task failure：業務を完了できなかった
- policy denial：意図どおりポリシーが拒否した
- abstention：根拠不足や範囲外を検知し回答・実行を控えた
- human override：人が候補を修正または取消した
- user abandonment：利用者が待機中に離脱した
- partial completion：一部は完了したが残作業がある
これらをすべて「失敗」にすると、安全な拒否が悪いKPIになり、チームが拒否を減らす方向へ最適化してしまいます。逆に、棄権を常に安全と見なすと、エージェントが仕事をしないことを隠せます。用途別に期待範囲を決め、理由コードとサンプルレビューを組み合わせます。
レダクション、最小化、保持を先に決める
OpenAI Agents SDKの資料は、generation spanがモデル入出力、function spanがツール入出力を保持し得るため、sensitive data captureを無効化できると説明しています。Microsoft Foundryの資料も、入力、出力、ツール引数・結果が機密情報を含み得るとして、秘密情報を入れないこと、個人・機密情報を事前にredact/minimizeすること、通常の本番ログ同様のアクセス制御と保持方針を適用することを勧めています。
実務では、収集前、取込時、保存後、表示時の四段階で制御します。
- 収集前：プロンプトやツールへsecretを渡さない。必要ならbrokerで注入する。
- 取込時：email、電話、氏名、顧客名、価格、資格情報パターンを検出し、dropまたはtoken化する。
- 保存後：暗号化、tenant/site分離、role-based access、監査ログ、保持期限を適用する。
- 表示時：一般運用者には要約、security/quality担当には申請付きで詳細を表示する。
「全部保存して後で考える」は避けます。保持期間は、調査、契約、品質、個人情報、保管費、学習利用の有無から項目別に決めます。たとえば通常spanは30日、集計値は13か月、重大案件の証拠は個別保全、という値は一つの提案例にすぎません。現地法務、顧客契約、社内規程と整合させて確定します。
なお、OpenAIの公式資料ではZero Data Retentionポリシーを利用する組織でbuilt-in tracingが利用できないとされています。契約、API構成、exporterを実環境で確認し、利用できない場合は自社のOpenTelemetry collectorや業務イベント台帳など代替経路を設けます。「画面で見えたから保存されるはず」という前提を置きません。
サンプリングは危険度と証拠価値で変える
全スパンを同じ割合で保存すると、低価値な成功ログが容量を占め、重要な失敗が落ちます。次の多段サンプリングを提案できます。
- 禁止操作、write tool、承認、override、error、policy denial、重大assetは100%保持
- 新版リリース直後、初めての拠点、夜勤などは一定期間100%に引き上げ
- 通常のread-only成功セッションは例として10〜20%を詳細保持し、集計metricは全件
- tail-based samplingで遅延、token、cost、span数が閾値を超えたtraceを後から保持
- 低率でも各業務種類・言語・拠点・シフトの代表性を確保
これらの割合は提案例です。サンプル外でも、case ID、結果、主要metric、外部transaction参照を最低限残すと、業務台帳と照合できます。サンプリング規則自体もversion管理し、事故後に「その時なぜ記録が無いか」を説明できるようにします。
ベンダー非依存の観測アーキテクチャ
推奨構成は、エージェント実行基盤からOTel形式などでtelemetry collectorへ送り、そこでschema normalization、redaction、sampling、routingを行い、trace store、metric store、log/evidence storeへ分配するものです。業務DB、MES、ERP、quality systemとはtransaction IDとcase IDで結びます。運用画面は一つでも、証拠の原本と集計値を分離します。
AWS AgentCoreはmetrics、spans、logsをCloudWatchへ格納し、trace可視化、custom span metrics、error breakdownを提供する実装例です。Microsoft Foundryはtraceをspan単位で確認し、Application Insightsへ送る例を示します。これらは製品選定の保証ではありません。RFPでは、export format、schema、保管場所、リージョン、暗号化、検索性能、cost、停止時の挙動、乗換え時の持出しを中立要件にします。
collector停止時の設計も必要です。重要なwrite operationで証拠が取れない場合に実行を止めるのか、local bufferへ置くのか、degraded modeで継続するのかを用途別に決めます。buffer満杯、ネットワーク断、再送、重複取込、時刻ずれを試験し、業務の副作用とtelemetryの再送を混同しないよう別のidempotency keyを使います。
AIエージェント 業務のオブザーバビリティRFP
データモデルと相関
- session、trace、span、business case、外部transactionをどう関連付けるか。
- multi-agent handoff、parallel tool、retry、long-running jobをどう表現するか。
- site/line/asset/work order/lot/shiftをどこまで標準属性にできるか。
- schemaとsemantic conventionのversionをどう固定・移行するか。
収集範囲と機密保護
- model/toolの入出力を既定で保存するか。項目単位で除外できるか。
- redactionは送信前か保存後か。失敗時の既定動作は何か。
- data residency、暗号化、管理鍵、閲覧権限、保持、legal holdをどう扱うか。
- debug目的で機密取得を一時的に増やす時、誰が承認し自動終了するか。
性能・費用・可用性
- telemetry追加によるlatency/CPU/network影響をどう測るか。
- peak時の取込、buffer、backpressure、drop policyは何か。
- token、tool、storage、query、egressをcase単位で配賦できるか。
- observability基盤障害時にwrite actionを止められるか。
運用と証拠
- alertからtrace、tool、外部transactionへ何手で到達できるか。
- raw export、API、schema、dashboard、runbook、trainingを納品するか。
- alert rule、redaction、sampling、dashboard変更を監査できるか。
- 契約終了時に証拠と設定を標準形式で持ち出せるか。
回答は「対応」のチェックではなく、画面、export例、失敗試験、検索時間、責任分界で評価します。AIエージェント 受入テストのゲートへ、本稿のtelemetry欠落、相関、redaction、sampling、cost再現の試験を組み込むと、調達と運用が同じ証拠を使えます。OTへ書き込む用途では、産業AIエージェント セキュリティの権限・実行仲介・安全層も別に満たします。
提案する90日導入ロードマップ
以下は提案スケジュールであり、全社標準ではありません。
0〜15日：業務IDと質問を決める
対象を一業務・一拠点に絞り、運用者が答えたい質問を先に書きます。「なぜ遅かったか」「どのツールで失敗したか」「誰が修正したか」「一件いくらか」「実行結果はERPへ入ったか」です。現行ログ、データ分類、時計、transaction ID、責任者を棚卸しし、session/trace/spanの最小schemaを決めます。
この段階でdashboardを作り込みません。case IDが画面、agent、tool、外部システムでつながらなければ、美しいグラフも調査に使えないためです。
16〜30日：計測・redaction・時刻を実装する
model、retrieval、tool、approval、handoffへspanを追加し、collectorで社内schemaに正規化します。secret、個人情報、顧客・価格情報のfield policyを実装します。UTCと現地時刻、clock sourceを確認し、開発・検証・本番でservice/environmentを分けます。
31〜45日：metricとalertを業務結果へ接続する
latency、error、retry、abstention、override、approval、token、tool costを集計し、ERP/MESの完了状態と照合します。最初のalert閾値は提案値として置き、二週間のbaselineで調整します。alertごとにowner、runbook、severity、acknowledge期限、close条件を付けます。
46〜60日：失敗注入と証拠再構成を試す
tool timeout、認証切れ、schema不一致、collector断、buffer満杯、approval期限切れ、重複retry、時計ずれを注入します。任意のbusiness caseから関連trace、span、外部transaction、operator actionまで再構成できるか確認します。秘密情報が検索やexportへ漏れないこともnegative testで確認します。
61〜75日：SLO、sampling、costを調整する
用途別のp95、error budget、override review、cost anomalyを提案し、実測値と損失影響で承認します。高リスクtraceを100%保持し、低リスク成功をsampleする規則を試します。保存・検索費、ネットワーク、担当者のalert負荷を見て、観測の費用対効果を調整します。
76〜90日：受入、runbook、引継ぎ
FAT/SAT相当の証拠をそろえ、day/night shift、タイ語・英語・日本語入力、現地ネットワーク、担当交代を試します。運用担当がベンダーなしで検索、原因仮説、redaction確認、alert close、exportを行えることを確認します。未達はowner、期限、暫定策、再試験条件を持つconditional acceptanceにするか、重要証拠が欠ける場合はproductionを止めます。
受入基準を再現可能な証拠にする
受入時は次のケースを最低限含めます。
- 一件の業務要求をsessionから外部transactionまで追える。
- parallel tool、handoff、retryの親子・link関係が崩れない。
- model/tool version、policy、knowledge snapshotを特定できる。
- latencyをqueue/model/retrieval/tool/approvalへ分解できる。
- error、abstention、denial、override、abandonmentを分類できる。
- write toolのargument、approval、idempotency、resultを照合できる。
- secretと指定機密項目がtrace、log、dashboard、exportに現れない。
- collector断と再接続で重複や欠落を検知できる。
- sampling対象外でも最低限のcase/result参照が残る。
- 一件当たりcostを根拠付きで再計算できる。
- 工場時刻とUTC、設備・指図・lotが正しく結び付く。
- 担当者がrunbookでalertを判定し、close理由を残せる。
各ケースはrequirement ID、test ID、trace ID、期待結果、実結果、証拠URL、評価者、defect、retestを結びます。スクリーンショットだけでなく、機械可読exportとqueryを残します。ダッシュボード変更後にも同じケースを再実行できることが重要です。
タイ拠点で確認したい運用差
ETDAのGenerative AI Governance Guidelineは、ドメイン文脈、情報の鮮度、説明可能性、出力の一貫性などの限界を示し、人の関与と技術更新への追随を勧めています。また組織の関与をadopter、customizer、makerとして整理しています。つまり、市販SaaSを使う工場と、自社RAG・ツールを組む工場、モデルまで作る組織では、必要なテレメトリ所有範囲が異なります。
タイ拠点では、中央の日本語policyだけでなく、タイ語の設備名、略語、交代勤務、現地の承認者、ICT時刻、ネットワーク品質を測定へ入れます。言語ごとのabstention/overrideを比較しても、利用件数や業務難度が違えば単純比較できません。代表ケースを人が確認し、翻訳、マスター、UI、権限のどこに原因があるか分類します。
本社と拠点で閲覧権限も分けます。本社は集計と複数拠点比較、現地責任者は自拠点の詳細、securityは機密traceへの申請アクセス、ベンダーは仮名化された必要範囲、といった設計が考えられます。これは提案例であり、契約・個人情報・労務上の要件を確認して決めます。
よくある失敗
会話全文を保存して「監視済み」とする
会話だけではツール、副作用、承認、外部結果を追えません。一方で機密情報は増えます。構造化されたIDとeventを中心にし、本文は必要最小限にします。
モデルAPIの平均latencyだけを見る
利用者が待つのはqueue、検索、tool、approvalを含む全時間です。平均はpeakとlong tailを隠します。end-to-endと各spanのpercentileを併記します。
ダッシュボードはあるが行動が決まっていない
赤いグラフだけでは改善されません。metricごとにowner、threshold、runbook、期限、close条件を決めます。alert疲れが起きたらルールを削る判断も運用に含めます。
全件保存か全件sampleの二択にする
危険なwriteと平常read-onlyを同じ扱いにすると、費用か証拠のどちらかを失います。risk-based、tail-based、release-basedを組み合わせます。
ベンダー画面だけを証拠にする
契約終了、障害、製品変更で見られなくなる恐れがあります。raw export、schema、query、setting、retentionと移行手順を契約します。
FAQ：AIエージェント 監視とSLA
AIエージェント 業務の監視は通常監視と何が違う？
CPU、memory、API availabilityだけでなく、session、モデル生成、retrieval、tool、approval、人の修正、業務結果とcostを一つの経路として扱う点です。通常のAPMを捨てるのではなく、その上へエージェント固有と工場文脈を足します。
AIエージェント トレーシングで思考過程が分かりますか？
完全な内部推論が分かるとは限りません。追えるのは、設計上収集した入力・出力、イベント、検索、ツール、承認、ポリシー、時刻、versionなどです。観測事実と原因仮説を分けて調査します。
何を100%記録すべきですか？
万能な答えはありません。高リスクwrite、承認、禁止操作、error、override、重大assetは100%保持する設計が候補です。本文を100%保存する意味ではなく、必要な構造化証拠を欠かさないという意味です。
AIエージェント SLAの数値はどう決めますか？
業務の損失、件数、許容待ち時間、人のfallback、データ品質から決めます。外部ベンチマークをそのまま使わず、baseline期間を取り、技術・実行・業務成果の三層で置きます。
ログ費用が高い時、最初に何を減らしますか？
重複本文、低価値な成功span、長すぎる保持を見直します。重要eventのmetricと相関IDを残し、risk-based sampling、圧縮、tiered storageを検討します。機密保護も費用削減も、収集前の最小化が最も効きます。
オブザーバビリティだけで安全になりますか？
なりません。観測は問題を発見・再構成・改善する能力です。権限、決定論的制約、承認、安全PLC、インシデント対応、継続評価などは別に必要です。観測できることと制御できることを混同しないでください。
まとめ：一件の業務を証拠とコストまで追える設計にする
AIエージェント 業務のオブザーバビリティで重要なのは、ログを増やすことではありません。session、trace、spanを業務ID、設備、指図、lot、tool、approval、人の介入、外部transaction、costへ結び、運用者が一件を再構成できることです。error、abstention、overrideを分け、latencyを分解し、機密を収集前から最小化し、危険度に応じてsamplingします。RFPではschema、export、redaction、retention、障害時動作、移行性を証拠で回答させ、90日で相関、失敗注入、SLO、引継ぎまで確認します。
TOMAS TECHでは、まだ製品選定前の段階でも、タイ工場の設備・業務ID・権限・既存ログを整理し、AIエージェント監視のRFP、90日計画、受入ケースへ落とし込めます。特定製品の導入を決める前に、まず「どの業務を、どの証拠で、誰が運用するか」を確認したい場合は、TOMAS TECHへお問い合わせください。
参考資料
- OpenAI Agents SDK, Tracing: https://openai.github.io/openai-agents-python/tracing/
- OpenTelemetry, GenAI semantic conventions attribute registry: https://opentelemetry.io/docs/specs/semconv/registry/attributes/gen-ai/
- AWS, Amazon Bedrock AgentCore Observability: https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/observability.html
- Microsoft, Set Up Tracing for AI Agents in Microsoft Foundry: https://learn.microsoft.com/en-us/azure/foundry/observability/how-to/trace-agent-setup
- NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, AI 600-1: https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf
- ETDA, Generative AI Governance Guideline for Organizations v2.0: https://www.etda.or.th/getattachment/6050a4b7-defd-4dba-8cbc-ff6a444a3d08/20241125-Generative-AI-Guideline_V2-0.pdf.aspx
