AI活用した運用改善v01

OpenAIによる作成：
・実施結果のレポート作成
・AI,LLM活用した運用改善の概要
※障害検知をトリガーに自立したプラン作成・評価・検証・対応までの一連の実装対処にむけて
※一部、仮説箇所も含む

Transcript

1. 1 | SRE+DEVOPS×AI を用いた運用改善 実践設計書 LEGACY RAG から GOVERNED AGENTIC OPERATIONS / AI SRE へ 2026 年 3 月時点の公開情報と評価実装から 対象読者 本書の立場 AI 導入を礼賛するのではなく、少人数・兼務・外部委託 混在・レガシー残存の現場で、どう安全に運用改善へつ なげるかを扱う。 主題 Assist → Operate → Guarded Autonomy の 段階導入、Alert-to-Action の安全設計、 Knowledge Operations、AI SRE、 MCP/A2A/Skills/Digital Twin の役割分担。 読み方 自社導入、顧客提案、PoC 設計、運用受入、障害対応ル ール整備のいずれにも利用できるよう、概念整理だけ でなく設計判断と失敗例を記述した。 AI を組み込んだ運用改善を「賢いチャットを導入すること」とは定義しない。運用現場で本当に 問われるのは、観測、証跡、承認、切戻し、知識鮮度、権限境界、責任分界、そして停止・縮退の設 計である。2026 年時点で価値があるのは、派手な自律化ではなく、bounded autonomy を前提にした堅牢な運用系である。
2. 2 | 目次 • はじめに • 本書のエビデンス方針と読み分け • 第 0 章 実装射程と検証範囲 • 第 1 章 2024 年から 2026 年 2 月に何が変わったのか • 第 2 章 観測した範囲での中小・中堅企業と地域 SI/MSP の現実 • 第 3 章 段階導入モデル：Assist → Operate → Guarded Autonomy • 第 4 章 参照アーキテクチャと Alert-to-Action の設計 • 第 5 章 RAG を Knowledge Operations として再定義する • 第 6 章 AI SRE：AI 自体を運用対象として扱う • 第 7 章 MCP / A2A / Skills / Digital Twin の役割分担 • 補章 2026 年 3 月時点の推奨実装構成 • 第 8 章 PoC で露出する失敗パターンと組織課題 • 終章 2026 年時点の結論 • 別紙 1 導入チェックリスト • 別紙 2 公開参照資料 • 別紙 3 実戦シナリオ：アラートから限定復旧まで • 別紙 4 AI SRE 変更管理テンプレート • 別紙 5 運用 RACI 雛形 • 別紙 6 使い方 • 別紙 7 実装ディープダイブ：How • 別紙 8 図版集：PoC から商用展開への進化 • 別紙 9 2026 年 3 月時点の補足参照資料
3. 3 | はじめに 生成 AI は、要約や文案生成の道具としてはすでに一般化した。しかし、運用改善の文脈では、それだけで はほとんど価値にならない。多数の入力トリガーとなるアラートをどう扱うのか、商用環境の設定変更や 構成変更を含む AI 対応を容認するための社内ガバナンス整備、誰が承認するのか、承認が得られなかっ たときにどう止めて後続へ対応を引き続くのか、SoT と実機が食い違っていた場合にどちらを信じるの か、古い Runbook/手順書/チェックリストが混在していたときに何を根拠として扱うのか。こうした問い に答えられないまま AI を導入すると、便利さより先に事故が表面化する。 とくに、中小・中堅企業や地域 SI/MSP が向き合う現場は、大企業向けの導入モデルや参照モデルとは条件が 異なる。専任情シスが不在、ネットワーク・サーバ・SaaS・回線・委託先アカウントが分断、監視通知はメールや 個人チャットに散在、手順書は PDF と Excel とチャット履歴など情報が分かれ、緊急時は結局ベテラン・キー プレイヤーの判断に頼る。この環境で「AI が勝手に直す」ことを目指すのは順番が逆である。先に整えるべき は、観測の正規化、知識の失効管理、権限の分離、承認不能時の退避、そして社外向けや社内向けでの説明責 任を支える監査証跡の取得である。 本書は、AI 導入の流行をなぞるための本ではない。SRE と DevOps の原則を足場に、RAG、Agent、 MCP、A2A、Skills、Digital Twin をどこに置くべきかを整理し、Assist → Operate → Guarded Autonomy の段階導入でどう運用改善へつなげるかを示す。 本書のエビデンス方針と読み分け 本書では、仕様・公式ドキュメント・公的ガイドライン・公式ブログ・現場実装・評価実装の知見を同列には扱わな い。運用改善は実務である以上、「どこまでを確定情報として採用できるか」を判別できなければ、よい概念整 理でも導入判断を誤る。 読み分けの基本は三段階である。 第１段階 ： 仕様・公式ドキュメント・公的ガイドラインは、実装や統制の基準線として扱う。 第２段階 ： 公式ブログ・ロードマップ・プレビュー機能は、将来方向や設計ヒントとして扱う。 第３段階 ： 本書が述べる実装パターンや失敗談は、現場での再現性を重視した推奨であり、 普遍的 な標準とは区別して使う。 したがって、本文中で「有力」「実務的」「有効」と述べる箇所は、必ずしも「標準化済み」「広く本番で枯れている」 を意味しない。とくに Agentic Retrieval、A2A、OpenTelemetry の GenAI/MCP、Skills の扱いは、 2026 年 3 月時点でも成熟度差が大きく技術要素の移り変わりも大きい。設計へ取り込む際は、仕様の安定 性、実装の追随度、契約上の責任分界を分けて判断すべきである。 第 0 章 実装射程と検証範囲 本章は、本書が単なる概念整理ではなく、過去に実施した評価実装・PoC・運用改善の試行から何を抽象化し ているかを明示するための追補である。読み手が『現場で触った人の文書か』『2026 年 3 月時点でどこまで 本番前提で読めるか』を判断しやすくすることを目的とする。 ここで扱う具体構成は、特定案件の唯一解ではない。代表的には、ローカル LLM または閉域側モデル、 FastAPI などのオーケストレーション層、Redis/RQ 等のキュー、Qdrant / PostgreSQL などの知識・メ
4. 4 | タデータ基盤、Streamlit などの UI、NetBox/CMDB/チケット/Runbook を接続した PoC 群を踏まえ、 責務分離の再利用可能な骨格へ抽象化したものである。 重要なのは製品名そのものではなく、Queue・Knowledge・Policy・Execution・Audit を分け、障害時 に safe mode へ落とす経路を持つことである。同一ホストへ同居させる場合でも、実行停止と提案継続を分 離できる構成であれば、PoC から小規模商用まで十分に戦える。 図 10 現場 PoC で採った実装構成（責務分離の実例） 下図のように、入力受付、永続キュー、Knowledge Ops、SoT/Graph、Router/Policy、 Executor/HITL、Audit を分離しておくと、モデル差し替えや外部 API 障害が起きても全体停止を避けや すい。とくにネットワーク/インフラ運用では、設計情報・実機差分・障害票・暫定手順が混在するため、知識面を 独立させる価値が大きい。 観点 現場 PoC での代表例 設計上の狙い 本書での扱い 受付・耐障害 Webhook / Syslog / Trap / メールを Queue へ退避 重複・遅延・順序逆転に耐える 第 4 章・別紙 7 Knowledge Ops PyMuPDF / OCR、版管理、引用 可能な根拠保持 検索精度より鮮度・切戻し・証跡 を優先 第 5 章・別紙 7 SoT / Graph NetBox / CMDB / Ticket / IaC / 実機差分 planned / actual / suppressed を分離 第 5 章・第 7 章 推論・統制 risk class・機密区分・approve / execute 分離 bounded autonomy を成 立させる 第 4 章・第 6 章
5. 5 | UI / 評価 引用確認ペイン、Playwright E2E、replay eval 『賢さ』より再現性と退行検知 第 6 章・別紙 7 項目 成熟度上の注意 本書での扱い MCP 仕様は存在するが、実装差と運用 差が残る。roadmap は仕様その ものではない。 接続面の標準候補として扱う。互 換性の最終判断は実装検証で行 う。 A2A 相互運用の方向性は有望だが、実 装側では実験的要素が残る。 複数エージェント協調の設計指針 として扱う。全面標準前提では置 かない。 Skills ベンダ/フレームワーク依存の差が 大きく、オープン標準ではない。 再利用知識の外部化という設計 概念として扱い、接続標準とは切 り分ける。 Azure AI Search の agentic retrieval 2026 年 3 月時点で公開情報上 はプレビューの位置付けが残る。 複雑質問に対する retrieval 設 計の参考として扱い、本番基盤で は慎重に採否判断する。 OpenTelemetry GenAI/MCP 計装 意味論の整備は進んでいるが、発 展途上の項目がある。 内部計装の抽象レイヤを置き、契 約 SLO や監査帳票へ直結しな い。 第 1 章 2024 年から 2026 年 2 月に何が変わったのか 2024 年頃の生成 AI 活用では、社内文書検索、FAQ、議事録要約、報告文の下書きが中心だった。ここでの 主役は「検索付き回答」であり、RAG は文書をチャンク化してベクトル検索し、もっともらしい文章を返す仕組 みとして理解されていた。評価も、回答が自然か、引用が付いているか、利用者が便利だと感じるか、といった 観点に寄りがちだった。 2025 年後半から 2026 年 2 月時点にかけて、価値の中心は検索結果そのものから、検索結果を根拠として 状態遷移を制御し、必要なときだけツールを使い、必要に応じた承認を経て安全に実行し、その結果を検証・記 録・再利用する活用へ移った。すなわち、RAG は単独の検索機能ではなく、Agent Runtime・評価・承認・監 査と結び付いた運用基盤の一部になった。 この変化は技術進化だけで起きたわけではない。システムを理解し判断可能な人材確保が困難、SaaS とクラ ウドの増加、コンテナ・API 連携の複雑化、セキュリティ要求の増大、旧式システムの延命、委託体制の多層化 が、従来の属人的な人力運用を限界へ押し込んだからである。現場が欲しているのはデモ映えする自律化では なく、必要なときに必要な確認と実行と説明が安全にできる仕組みと仕組みづくりが可能な体制だ。 論点 2024 年頃の中心 2026 年時点の中心 現場への意味 RAG 検索して答える 鮮度・権限・評価を含む Knowledge Operations 文書検索 PoC から運用基 盤へ昇格 Agent tool calling のデモ state / checkpoint / HITL / audit 推論より状態遷移設計が重 要 MCP / A2A 接続の便利さ 接続面と相互運用の標準化 導入だけでは安全にならな い
6. 6 | 評価 主観評価・体感 offline eval / replay / canary / monitoring 変更管理が細粒度化 精度 ハルシネーション問題 は容認 ハルシネーション問題は用途 により容認不可 必要な情報をもとに判断す る制度を求める 要するに、変わっていないのは SRE/DevOps の目的であり、変わったのはその目的を達成するための実装 対象である。可用性、MTTR、変更失敗率、トイル削減、引継ぎ容易性を改善するという目標は不変であり、そ のためにモデル、埋め込み、Retrieval、Agent Runtime、承認フロー、知識失効管理、自動化まで運用対象 へ含める時代になった。 第 2 章 観測した範囲での中小・中堅企業と地域 SI/MSP の現実 中小・中堅企業向けの AI 導入論は、大企業向けの「専任組織があり、SoT が整備され、権限が定義済みで、運 用設計も標準化されている」という前提をそのまま流用してはならない。実際には、情シス/監視体制が不在ま たは少人数兼務、監視はあるが報告・通知先が散在、管理台帳や CMDB は不完全、手順書は分散、委託先は 複数/サポート関係が終了している、そして「全部任せたいが勝手に変えないでほしい」という相反要求が同時 に存在する場合もある。 地域 SI や MSP 側も同様である。顧客ごとに NAS、VPN ルータ、オンプレ AD、SaaS、クラウド、Excel 台 帳、イントラの共有情報陳腐化、過去の納品書が混在し、しかも契約ごとに権限範囲と責任分界が異なる。この 状況では、AI 導入以前に、対象範囲、承認経路、緊急連絡先、作業種別、外部送信可否、ログ保全方針を明確に しなければ、AI は知識の増幅器ではなく現場の混乱を引き起こす仕組みとなりえる。 したがって、この層では「高機能さ」よりも「少人数で回ること」「人へ戻せること」「委託先との責任分界を壊さ ないこと」「説明負荷を減らすこと」が優先される。現場の価値は、報告文の自動生成より、障害切り分けの初動 時間短縮、初動対応ミスの抑止、申請ミスの削減、過去障害票の再利用、担当不在時の引継ぎ容易化、コスト/ 稼働時間削減、利益増加、顧客からの評判の向上に現れやすい。 典型的な制約 読替え 情シスが少人数または兼 務 提案や設計は、運用品質を上げる一方で管理負荷を増やさないことが条件となる。 SoT が未整備または不一 致 AI 回答の根拠順位と、実機確認を優先すべき場面を明示する必要がある。 外部委託が多い read-only / approve / execute を契約境界に合わせて分離する必要があ る。 文書が分散している 検索精度より先に、失効・版管理・責任者・適用範囲の整理が必要である。 経営層は結果を求めるが 運用詳細を見ない KPI は AI 利用率ではなく、MTTR、問合せ一次解決率、報告作成工数、承認滞留 時間などで示すべきである。
7. 7 | この前提を無視して「Agent が自律復旧する世界」を先に語ると、PoC は見栄えがよくても商用導入で破綻 する。逆に、この前提を受け入れたうえで小さく始めると、AI は現場の暗黙知と監査要求の間をつなぐ実用技 術になる。 第 3 章 段階導入モデル：ASSIST → OPERATE → GUARDED AUTONOMY 本書では、中小・中堅企業および地域 SI/MSP 向けの現実的な成熟モデルとして、Assist、Operate、 Guarded Autonomy の三段階を採る。いきなり自律化へ進まない理由は明快である。自動実行の前に、何 を根拠とし、誰が承認し、どの範囲まで実行し、どの証跡を残し、異常時にどのように停止するかを定めなけれ ばならないからだ。 Assist は、検索・要約・申請補助・問い合わせ一次応答・手順提示・証跡整形を担う。ここでは実行権限を持た せない。最初の価値は、問い合わせの初動短縮、担当者の記憶や保有知識からの思い出しコスト削減、報告書や 申請書の品質平準化にある。 Operate は、監視アラートの要約、相関分析、NetBox/CMDB/台帳/チケット参照、承認付きコマンド実行、 結果の証跡化を担う。本命はここである。現場で本当に工数を削減し、品質も上げられるのは、提案だけでな く、限定された承認付き実行と再観測がつながったときである。 Guarded Autonomy は、被害半径が小さく、検証可能で、切戻しが定義済みの定型処理だけを自動化する 段階である。たとえばキャッシュクリア、サービス再起動、監視抑止の解除、問い合わせテンプレ返信、ジョブ再 投入などが候補になる。一方で、広範な設定変更、経路制御、権限変更、複数系統に跨る作業は、Digital Twin や事前検証なしに自動化すべきではない。 段階 目的 主な機能 避けるべきこと Assist 検索・要約・申請補 助 文書検索、一次応答、手順提示、報告文下 書き 古い文書と未承認メモ を同列に扱うこと Operate 承認付き運用支援 アラート要約、相関分析、SoT 参照、限定 実行、証跡生成 承認基準と再観測を定 義しないまま実行権限 を広げること Guarded Autonomy 限定自動化 allowlist 対象の自動実行、safe mode、rollback、再評価 kill switch なしで全対 象へ横展開すること 導入順を誤らないことが重要である。最初に成果が見えやすいのは、報告文作成ではなく、triage、 evidence gathering、手順案生成、申請補助である。最初に事故が起きやすいのは、承認・実行・外部 API 依存を曖昧なまま自動化したときである。 各段階へ進む条件も明文化すべきである。Assist から Operate へ進む前には、少なくとも参照対象の知識 源、承認者、対象システム、緊急連絡経路、証跡保管先が定義されていなければならない。Operate から Guarded Autonomy へ進む前には、対象処理が定型であること、失敗時の検知と切戻しが自動または即時 に実施できること、実行前後の再観測が可能であること、そして夜間や不在時に停止側へ倒せることを確認す べきである。成熟度とは機能数ではなく、止め方と戻し方を含めて制度化できている度合いで判断するべき だ。 第 4 章 参照アーキテクチャと ALERT-TO-ACTION の設計
8. 8 | 図 1 Guarded Operations Platform 参照アーキテクチャ 実装では、LLM/Agent 制御層を単一の巨大プロンプトで作るより、router、planner、policy engine、 tool executor を分離したモジュールとして扱う方が保守しやすい。router は入力種別と優先度を判定し、 planner は必要な根拠の収集順序を決め、policy engine は権限境界と allowlist を評価し、tool executor は実行と再観測だけに責務を限定する。 また、実行系は同期一発呼び出しに寄せず、必ず evidence ID、request ID、approval ID を付与したジ ョブとして扱うべきである。これにより、失敗時に「どの根拠と承認で何を実行したか」を追跡でき、再実行や切 戻しも deterministic に近づく。とくに MSP や委託混在環境では、この識別子設計が責任分界の土台にな る。 図 2 Alert-to-Action の安全設計 Alert-to-Action を実装するときは、入力経路ごとに triage を分離するのが有効である。監視起点、ユー ザ問い合わせ起点、申請起点、メール起点、電話一次受付起点を同じ prompt に混在させると、必要な根拠と
9. 9 | 承認条件が崩れる。入口を分け、risk class を入口側で先に付けるだけでも、誤作動率と承認負荷を大きく 下げられる。 運用改善の参照アーキテクチャは、単一製品へ閉じるよりも、寿命と変更速度の異なる部品を疎結合でつなぐ 構造がよい。最低限でも、①観測層、②SoT/業務連携層、③Knowledge Operations 層、④LLM/Agent 制御層、⑤Human-in-the-Loop と実行層、⑥Observability / Audit 層の六つに分けて考えるべきで ある。 観測層には、Zabbix、Grafana、クラウド監視、Syslog、APM、ログ基盤が入る。ここで重要なのは、AI へ渡 す前の正規化・重複排除・相関である。ノイズをそのまま投げると、賢いモデルでも誤った優先度判断をしやす い。 SoT/業務連携層には、NetBox、CMDB、資産台帳、チケット、変更管理、保守契約、連絡先台帳が入る。ただ し、SoT は「正解」ではなく「設計上の仮説」である。実機差分・変更履歴・最新の障害票と突合して初めて価値 がある。 LLM/Agent 制御層は、モデル選択、ツール選択、状態保持、ルーティング、ポリシー適用、承認依頼、応答整形 を担う。この層に権限境界を入れなければ、どのチャット経路からでも危険操作へ到達する構造になり、後戻り が難しくなる。 層 代表要素 設計上の要点 観測 監視、メトリクス、ログ、 Webhook AI へ渡す前に正規化、相関、重複排除を行う。 SoT / 業務連携 NetBox、CMDB、台帳、チケッ ト 設計値と実機差分を扱う。SoT 盲信を避ける。 Knowledge Ops RAG、版管理、失効、 tombstone 検索精度より鮮度・適用範囲・廃止管理が重要である。 LLM / Agent モデル、プロンプト、skills、ポリ シー 推論品質だけでなく状態遷移と権限境界を管理する。 HITL / Execution Slack/Teams、承認、ジョブ、 Runbook、IaC read-only / approve / execute を分離し、危険操 作を縮退させる。 Observability / Audit トレース、評価ログ、変更履歴、証 跡保存 モデル・ツール・承認・実行の因果を追跡可能にする。 この中で最も慎重に設計すべきなのが Alert-to-Action である。監視アラートを 例として Webhook で受 け、要約・相関・Runbook 検索・SoT 参照・Chat(Slack/Teams)承認を経て実行へ進む構成は魅力的に 見えるが、最も事故率が高い。誤検知、知識鮮度劣化、権限誤り、二重実行、承認遅延、実行後検証漏れ、証跡欠 落が同時に起こり得るからである。
10. 10 | したがって、Alert-to-Action では少なくとも以下を決める必要がある。 ①risk class、②approval gate、③allowlist、④manual takeover ⑤safe mode、⑥kill switch、⑦実行後 verification、⑧失敗時 rollback ⑨滞留時の扱い、⑩監査ログ保持、⑪大量受信時の扱い である。承認があるだけでは安全にならない。承認不能時にどう止めるかまで定義して初めて安全になる。 実戦的には、入口を一つに決めるだけでも事故率は下がる。たとえば、監視起点の triage は Zabbix やクラ ウド監視から受け、問い合わせ起点の triage は Web フォーム、メール、チャット、電話一次受付の要約に分 け、それぞれで使える Skill と参照先を変える構成がよい。監視起点では再観測と SoT 差分確認を先に行 い、問い合わせ起点では契約情報、過去対応履歴、FAQ、申請状態を先に見る。入口が違えば、必要な根拠、承 認者、実行可能な操作も変わるため、単一の Agent に全案件を押し込むより、ルーティング段階で業務フロー を分岐させる方が安全である。 イベントストーム、相関アラーム、LLM 遅延の設計論点 機器故障、設定ミス、回線断、冗長切替失敗のように通信影響が大きい障害では、ネットワーク機器のアラーム だけを見ても足りない。実際に商用利用中のサーバ、APM、クラウド監視、アプリ監視、受付チャネルから同時 に異常が上がるため、サービス、サーバ、VM/Container、ネットワーク機器、回線、ISP をつなぐ依存関係を 前提に triage しなければ、根本障害より派生アラームの処理が先に走り２次障害を連鎖的に引き起こしてし まう可能性がある。 図 7 イベントストーム時の triage / correlation / queue 制御 大量イベント発生時の第一原則は、入力受付を軽量化し、LLM を初動 ACK の直列経路に入れないことであ る。Webhook 受信、SNMP Trap 受信、Syslog 受信、メール/チャット受付は、まず永続キューへ書き込 み、request ID・event ID・idempotency key を付与して即時 ACK を返すべきである。ここで重い相 関や生成処理を同期実行すると、再送が再送を呼び、入力滞留が下流破綻へ連鎖する。
11. 11 | 次に必要なのは、個別アラームと関連アラームの分離である。たとえば上位ルータの停止や誤設定で拠点通信 が断たれた場合、下位スイッチ、監視エージェント、業務サーバ、APM、外形監視が短時間に連鎖して異常を上 げる。このとき重要なのは「何件アラームが来たか」ではなく、「どのサービスにどれだけの商用影響が出ている か」である。したがって、同一機器集約、親子アラーム分離、サービス影響推定、incident merge を先に行 い、P1 は件数ではなく被害半径で決める必要がある。LLM への処理に直接つなげなく数秒から１分間などで 受信したアラームの重複排除、直近のアラーム所法を含め相関分析後に後続処理へ流すなどの仕組みも必要と なる。 LLM はここで有効だが、使いどころを誤ってはならない。ルールベースや相関エンジンで止めるべき fast path と、根拠整理・要約・過去障害票照会・説明文生成を担う slow path を分け、LLM には時間予算と同 時実行上限を持たせるべきである。queue depth 超過、model timeout、tool timeout、token budget 超過時には、提案-only、テンプレ応答、retrieval-only、人手優先へ縮退し、承認依頼や実行要求 を無理に継続しない方が安全である。 また、SoT 側の制約も無視できない。サービス構成、監視タグ、回線情報、装置名、顧客名が揃っていなけれ ば、ネットワーク障害とサーバ障害の関係付けは不安定になる。時刻同期ずれ、監視名寄せ不一致、 Trap/Syslog の順序逆転、重複 Webhook、キューの poison message、特定顧客だけイベントが偏る hot partition も現実の失敗要因である。したがって、大量イベント試験では、平常系だけでなく burst、 replay、順序入れ替え、同一障害の多重通知、LLM 遅延注入まで含めて評価しなければならない。SoT とし て対象サービス、影響範囲、利用チームなどを保持すると評価時に重要な要素となるが、SoT のメンテナンス を行い最新に保てる環境を整備することは厳しくシステム更改や機能追加を行う際に情報更新を失念すること も起きる。個別カスタマイズ導入や例外的な設定、過去に実施した暫定設定(現在の必要性は分からなくなって いる)も含まれる可能性があり、過去に設定した経緯が断絶しているため追えない場合もある。 論点 破綻しやすい現象 設計上の対策 入力受付 Webhook/SNMP/Syslog を同期処 理し、受信側が再送嵐を起こす。 軽量 ACK、永続キュー、 idempotency key、受信と解析の 分離 相関制御 同一障害を個別インシデントとして大量 起票する。 同一機器集約、親子アラーム分離、 incident merge、抑止ウィンドウ 優先度判断 件数が多いノイズが P1 を占有し、本当 の根本障害を遅延させる。 サービス影響、顧客影響、被害半径、回 線/冗長状態を加味した priority policy LLM 遅延 要約や説明生成が詰まり、承認依頼や後 続実行が滞留する。 fast/slow path 分離、timeout、 bounded concurrency、 degraded mode SoT 不整合 装置・回線・サーバの依存関係がずれ、誤 った関連付けを行う。 名寄せ、時刻同期、依存関係グラフ更 新、replay 試験、運用レビュー 第 5 章 RAG を KNOWLEDGE OPERATIONS として再定義する
12. 12 | 図 3 Knowledge Operations ライフサイクル 技術的には、knowledge item に最低でも document_id、version、owner、scope、valid_from、 valid_to、supersedes、superseded_by、confidence、access_class を持たせたい。さらに、本文だ けでなく表、画像、添付、ログ断片にも同一の権限モデルを適用しなければ、引用プレビューがそのまま情報漏 えい経路になる。 検索パイプラインは、単純なベクトル近傍検索よりも、前処理で失効・権限・適用範囲を落とし込み、その後に lexical / vector / rerank を組み合わせる構造が実務向きであるが、全文検索を行う仕組みも検討が必要 となる。危険なのは「古いが似ている文書」が上位に来ることなので、freshness と superseded を first-class citizen として扱う必要がある。 また、OCR や PDF 取り込みでは、本文抽出だけでは不足する。実運用では表の注記、画像内の系統図、添付 ログ、チェック欄の状態が判断材料になる。したがって bbox 単位の citation preview、抽出失敗時の human review queue、再取り込みの差分管理まで含めて設計した方が、後から作り直さずに済む。
13. 13 | 図 5 RAG 取り込みパイプライン 取り込み系の設計では、抽出エンジンの性能よりも「危険なデータをそのまま公開しない」ことが優先である。し たがって、OCR 不良、表構造崩れ、版数曖昧、機密区分未確定といった条件は、最初から人手レビューへ戻す 分岐として設計しておくべきである。ここを省くと、検索精度向上で表面上は改善したように見えても、商用運 用では情報漏えいと誤案内の温床になる。 運用現場における RAG の失敗は、しばしば検索精度の問題として語られる。しかし真因は、知識が運用されて いないことにある。古い設計書、失効した暫定対処、保守切れ機器の例外運用、変更済みの手順、引き継がれて いないメモが同じ重みで検索対象に入っていれば、RAG は「もっともらしい誤答」を量産する。 2026 年 2 月の時点では、RAG は retrieval system ではなく Knowledge Operations として設計 すべきであると考える。必要なのは、文書本文の埋め込みだけではない。発行日、最終更新日、適用期間、失効 日、superseded_by、廃止理由、対象環境、責任者、承認状態、公開範囲、機密区分、引用可能範囲といった メタデータを整え、回答時の優先順位を SoT ＞ 公式 Runbook ＞ 最新障害票 ＞ 参考資料 ＞ 履歴資料 のように制御することである。 誤情報への対応も、単純削除では足りない。削除すると、なぜ使ってはいけないかが失われ、同じ誤りが別文書 から再出現する。したがって tombstone を残し、「何が、なぜ、いつ、誰によって廃止されたか」を検索系へ伝 播させる必要がある。 また、権限制御は文書単位では不十分である。運用現場では、本文は公開可能でも、表の一部、添付ログ、コマ ンド例、IP アドレス一覧、顧客名、障害連絡先が秘匿対象になる。チャンク、表、画像、添付ごとの権限制御を考 えなければ、RAG の根拠提示はそのまま情報漏えい面になる。 失敗要因 表面化する問題 必要な対策 失効資料の混在 古い対処が上位表示される superseded / effective date / tombstone を管理する
14. 14 | SoT との優先度未 定義 設計値と実機状態が混同される 回答時の根拠順位を固定し、実機確認が必要な条 件を明示する 権限が粗い 添付ログやコマンド例が漏れる チャンク・表・添付単位でアクセス制御する Parser 品質のばら つき 表や図の情報が欠落する parser 多層化、OCR、bbox 引用、根拠プレビュ ーを用意する 更新パイプラインが 弱い 古い埋め込みが残り続ける 取り込み SLA、再索引手順、前版切戻しを整備す る 運用改善で RAG を使うなら、回答の自然さよりも、鮮度、適用範囲、根拠提示、失効管理、取り込み遅延、前版 切戻しをまず見るべきである。検索ができるかではなく、「危険な知識を使わせない」ことが知識運用の中心に なる。 このため、Knowledge Operations には取り込み後の運用ループが要る。具体的には、一次登録、責任者 レビュー、適用範囲付与、失効期限設定、PoC 時の仮登録、商用反映時の正式化、障害後の暫定手順の昇格ま たは廃止、という流れを分けて管理するべきである。問い合わせメモやチャット断片をそのまま恒久知識へ昇 格させると、現場では便利でも、半年後にはもっとも危険なノイズ源になる。知識基盤は、集める仕組みより、 捨てる仕組みと昇格条件の方が重要である。 第 6 章 AI SRE：AI 自体を運用対象として扱う AI SRE を実装する際は、アプリ監視と同じ粒度では不足する。少なくとも input class、retrieval latency、retrieved_docs_count、groundedness score、tool_call_success_rate、 approval_wait_seconds、post_action_verification_result を 1 リクエスト単位で保持し、トレースと して横断できる必要がある。OpenTelemetry の span/event を活用すると、モデル呼び出し、検索、ツー ル実行、承認待ちを同一トレースで追いやすい。 ただし、OpenTelemetry の GenAI / MCP semantic conventions は、2026 年 3 月時点でも発展 途上の項目を含む。よって、属性名や span 名をそのまま社内の監査項目や外部委託契約の固定スキーマへ 埋め込むのではなく、内部では抽象化した観測モデルを持ち、collector か変換層で吸収できる形にしておく 方が安全である。 とくに大量アラーム系では、AI SRE の監視指標も通常の会話系より細かくなる。最低でも ingress ACK p95、queue depth、dedupe ratio、incident merge ratio、P1 first-summary latency、LLM timeout rate、tool timeout rate、suppressed event ratio、replay 再現率は観測したい。ここを 見ないまま「回答品質」だけを追うと、平常時はよく見えても、障害集中時に最も重要な初動制御が壊れている ことを見逃す。 評価は online と offline を分ける。online では成功率、遅延、fallback 発動率、承認滞留、想定外ツー ル要求などを見る。offline では golden set に対する replay、差分比較、失敗モード別の再現試験を回 す。特に prompt や tool description の変更は軽視されやすいが、実際にはモデル切替に近い挙動変化 を起こすため、変更票の対象に含めるべきである。 ローカル LLM と API 型 LLM を併用する場合は、役割分担も明示したい。たとえば機微データを含む要約や 引用確認は local、長文推論や一時的な解析は API、停止時は rule-based fallback へ落とすといった方 針である。重要なのは「どの系が落ちても提案-only では継続できる」状態を先に作ることだ。
15. 15 | AI を導入したからといって運用が楽になるわけではない。むしろ、AI/LLM 基盤そのものが新たな運用対象 になる。モデル障害、外部 API 停止、Embedding 更新失敗、Retrieval 劣化、Tool error、Approval 滞 留、評価漏れ、コスト急増、ログ欠落が、運用事故の新しい原因として表面化する。 このため、AI 機能をブラックボックスの便利機能として扱ってはならない。SRE の対象として、成功率、レイテ ンシ、groundedness、tool call 成功率、承認待ち時間、RAG 更新遅延、再観測実施率、fallback 発動 率、コスト、トークン消費を監視対象へ含める必要がある。 さらに重要なのは、変更管理である。モデル切替、埋め込みモデル更改、reranker 変更、parser 更新、プロ ンプト修正、tool description 修正、policy 更新、knowledge source 追加は、すべて挙動を変える変 更である。従来のアプリ変更よりも小さい粒度で評価と切戻しを回す必要がある。 AI SRE の現場では、canary、shadow、offline replay、データセット評価、degraded mode、 feature flag、kill switch が必須になる。評価を伴わないまま「前より賢そうだから」更新する運用は、本番 事故を内蔵しているのと同じである。 管理対象 最低限見るべき指標 事故時の対応例 Model API / local LLM 成功率、レイテンシ、context overflow、コスト degraded mode へ格下げ、代替モデル へ迂回 Embeddings / Retrieval 取り込み遅延、recall 低下、 citation 欠落 前バージョンへ切戻し、index 再構築 Agent Runtime tool error、retry 増加、 handoff 失敗 checkpoint から再開、該当 tool を停 止 Approval Flow 承認待ち時間、未処理件数、夜間滞 留 提案のみ運転へ変更、当番体制へ切替 Knowledge Governance 失効資料混入、権限逸脱、 superseded 検出 該当 source を隔離、tombstone 更新 Verification 再観測未実施、diff 未取得、SLO 確認漏れ 実行完了扱いを禁止し、証跡を再収集する AI SRE の本質は、モデルを監視することだけではない。AI を含む運用系全体の挙動を、再現可能に評価し、 縮退可能に設計し、変更を小さく切って安全に進めることである。AI 機能だけを PoC 化し、運用系を従来の ままに残すと、責任境界と証跡の空白が生まれる。 運用として定着させるには、週次または隔週の評価サイクルも必要になる。代表的なアラート、問い合わせ、申 請、変更依頼を golden set として保持し、モデル変更や prompt 変更のたびに replay で差分を見る。そ こで確認すべきなのは、回答の流暢さではなく、誤引用が増えていないか、承認文言が曖昧になっていないか、 危険な tool が選ばれやすくなっていないか、前版より再観測率や根拠提示率が落ちていないかである。AI SRE はモデル評価と運用評価を分離せず、同じ変更管理の中で扱うべきだ。 第 7 章 MCP / A2A / SKILLS / DIGITAL TWIN の役割分担
16. 16 | 図 4 MCP / A2A / Skills / Digital Twin の責務分離 たとえばネットワーク運用では、MCP で NetBox、Git、Ticket、監視 API、ログ検索基盤へ接続し、A2A で triage agent から policy/verification agent へ委譲し、Skills で「BGP flap 初動」「FW 変更前チェ ック」「監視抑止解除条件」といった手順・判定知識を外部化し、Digital Twin で想定経路や影響半径を検証 する構成が考えやすい。 このとき、実行の真正性は Twin ではなく実機証跡で確認し、Skills は接続権限を持たず、MCP は承認判断 を持たない、という線引きを崩さないことが重要である。責務が混ざると、便利さの代償として障害時の切り 分けと監査説明が極端に難しくなる。 2026 年時点では、MCP だけで AI 運用の全体像を語るのは不十分である。MCP は主としてモデルと外部 ツール・データを接続する標準であり、A2A は agent 間相互運用、Skills は再利用可能な作業知識や評価 ルールの外部化、Digital Twin は実行前検証と影響半径確認の安全装置として整理するのが実務的である。 ここで注意したいのは、MCP・A2A・Skills は同じ成熟度ではないことである。MCP は接続面の共通化とし て議論が進んでいる一方、A2A は実装・運用の広がりがこれからであり、Skills は製品や SDK 依存の色が 濃い。したがって、設計書では「標準」「実装依存」「実験的」のラベルを付け、提案書や契約書で同じ語を無造作 に使わない方がよい。 役割を混ぜると設計が崩れる。たとえば、MCP を認可や監査の代替として扱う、Skills を接続標準の代わり に使う、A2A を責務分離のないまま増やす、Digital Twin なしでネットワーク変更を自律実行する、といっ た設計は後で破綻しやすい。 ネットワーク/インフラ運用へ引き付けて言えば、NetBox、IaC、Ticket、過去障害票を SoT 候補として扱 い、実機との差分を Digital Twin や検証で埋める構造が望ましい。深い推論を agent に担わせても、最終 的な実行権限は狭い自動化系と承認系で制御する必要がある。NOC/SRE では、常時監視の AIOps 層と、 深い推論エージェント層を分ける方が安定しやすい。 要素 主な責務 向いている用途 誤用例
17. 17 | MCP ツール・データへの接続面 read-only 参照、function 呼び出し、標準化された接続 認可や監査を MCP だけで済 ませる A2A agent 間の依頼・結果連 携 責務境界が明確な複数 agent 協調 ワークフロー設計なしに agent を乱立させる Skills 再利用可能な作業知識・ 評価ルール 手順、判断パターン、定型調査、 CI/CD 連携 暗黙知のままテストなしで肥大 化させる Digital Twin 事前検証、差分確認、影響 半径確認 ネットワーク、IaC、複数系統変 更の安全確認 Twin なしで本番へ直接自律実 行する この章の要点は単純である。MCP は接続面であり、A2A は連携面であり、Skills は知識の再利用面であり、 Digital Twin は安全面である。どれか一つで全体を代替しようとすると、接続、統制、評価、安全のどこかが 抜け落ちる。 補章 2026 年 3 月時点の推奨実装構成 2026 年 3 月時点で実務的な推奨は、取得系を agentic にしても、実行系は bounded autonomy と human takeover を前提に残す構成である。取得・計画・実行・監査を一体化した『単一巨大 Agent』より も、責務分離と縮退制御を優先する方が、運用・監査・契約説明のすべてで有利である。 とくに MCP・A2A・Skills・Digital Twin は同一カテゴリとして扱わない方がよい。MCP は主として接続 面、A2A は agent 間連携面、Skills は知識や作業単位の再利用面、Digital Twin は事前検証と影響半径 確認の安全面として整理し、標準・実装依存・実験的のラベルを明示して採用判断する。 図 11 2026 年 3 月時点の推奨実装構成（Bounded Autonomy）
18. 18 | 採用判断は『流行語を全部入れる』ことではない。公開情報と実装成熟度を分け、どの層へ入れるかを先に決め ると設計が崩れにくい。 技術要素 2026 年 3 月時点の位置 付け 推奨スタン ス 設計メモ MCP 接続面の共通化として有力 ◎ 早めに採 用検討 接続仕様と認可/監査は別物として設 計 A2A 相互運用の伸びしろ大、ただ し実装差あり △ 段階導入 単独採用より責務分離された agent 増殖を抑制 Skills SDK / 製品依存が強い ◦ 局所採用 作業知識・評価規則・定型手順の外部 化に向く Agentic Retrieval RAG 高度化には有効、公開 プレビューも残る ◦ 検証採用 本番適用は fallback と品質計測を 同時に用意 OpenTelemetry GenAI / MCP 観測標準として重要だが発 展途上の面あり ◦ バージョ ン固定で採 用 属性名や stability opt-in を凍結し regression を取る 本補章の読み方は単純である。取得系は改善余地が大きいため攻めやすいが、実行系は権限境界・承認・切戻 し・監査が先である。エンジニア向け文書としては、この順序を明示した方が机上設計ではないことが伝わりや すい。
19. 19 | 第 8 章 POC で露出する失敗パターンと組織課題 PoC では「1 回うまく動いた」ことが重視されがちだが、商用化で必要なのは再現性である。代表シナリオを 10〜20 本程度に絞り、正常系だけでなく、誤検知、承認不在、SoT 不一致、外部 API 停止、OCR 抽出失 敗、tool timeout、model fallback を含む失敗系を先に試験項目へ入れるべきである。 図 6 PoC から本番移行の評価フロー 本番移行の判定では、会話の自然さやデモ映えを主指標にしてはならない。見るべきは、失敗系で止まれるか、 承認が詰まったときに提案-only へ落とせるか、切戻しと再観測が実運用の時間内に閉じるかである。PoC から本番へは、offline replay、shadow 運転、canary、guarded production を経て段階昇格させる 方が、結局は早い。 PoC の試験項目にも、イベントストーム系を必ず入れるべきである。たとえば「5 分間に数千件の Syslog と Trap が集中する」「同一障害に対して監視・APM・問い合わせが同時に起票される」「LLM 応答を意図的に遅 延させる」「SoT 側の依存関係が一部古い」という条件を与え、初動 ACK、集約、優先順位、縮退、承認依頼が 破綻しないかを確認する。商用運用で問題になるのは平常時の賢さより、障害集中時の壊れ方である。 組織面では、一次報告の粗さを責める文化と AI 導入は相性が悪い。初動では不完全な観測から仮説を作るし かない場面が多く、AI も同様に不確実な情報から候補を出す。したがって、途中報告・暫定判断・差し戻しを前 提にしたレビュー文化へ再設計しなければ、現場は根拠隠しと過剰防衛に流れやすい。 現場の PoC で露出する失敗は、モデル精度の不足だけではない。むしろ、観測の粗さ、SoT 過信、承認基準不 明、権限設計の曖昧さ、ローカル LLM の不安定さ、評価データ不在、責任分界未整備、レビュー文化の欠陥が、 技術問題として表面化することが多い。 代表例は、Zabbix→Webhook→Slack→実行の短絡構成である。誤検知時に誤作動しやすく、承認があっ ても誰が何を見て判断するかが曖昧で、夜間は承認そのものが滞る。NetBox や CMDB も、登録情報と現 実の構成差分が大きいと SoT として過信できない。RAG 取り込みでは、PDF・表・画像・OCR・bbox 引用 の品質差により、根拠の見え方が安定しない。
20. 20 | また、ローカル LLM 運用では、モデル更新、GPU/NPU/ドライバ、埋め込み API の不安定さが、運用改善基 盤そのものの不安定化につながる。したがって、local と API の役割分担、代替経路、モデル切替手順を明文 化しなければならない。 さらに見落とされやすいのが組織課題である。LLM を導入すれば自動的に改善するとみなす LLM 至上主 義、一次報告や途中報告の粗さだけを責める文化、現場証跡よりも外部ベンダの言葉を重く見る風土、PoC 担 当者にだけ知識が閉じる体制は、技術選定よりも強く失敗率を左右する。AI 導入の成否は、レビュー文化と責 任設計をどれだけ再設計できるかに依存する。 失敗パターン 表面化した問題 再設計方針 Zabbix→Webhook→Slack→ 実行 誤検知で誤作動しやすい。承認 はあるが判断材料が曖昧。 risk class、approval gate、 manual takeover、safe mode を 先に定義する。 NetBox / CMDB 活用 登録情報と現実の構成差分が大 きい。 SoT 階層を定義し、実機差分・変更履 歴・Ticket と突合する。 ローカル LLM 運用 モデル更新やドライバで基盤自 体が不安定化する。 local と API の役割分担、代替経路、 モデル切替手順を明文化する。 RAG 取り込み 表・画像・OCR の品質差で根拠 表示が揺れる。 parser 多層化、citation preview、 検索-only 運転を用意する。 承認フロー 夜間滞留、責任者不在、承認疲 れが起きる。 承認対象を絞り、営業時間外ルールと自 動縮退条件を定める。 組織文化 PoC 担当者の属人化、途中報 告が潰される。 RACI、レビュー基準、学習用ポストモー テムを制度化する。 技術 PoC を商用導入へつなげるには、技術要素だけでなく、責任分界、承認設計、評価設計、教育設計、引継 ぎ設計を一体として扱う必要がある。見栄えのよいデモができても、その仕組みを夜間障害、監査、担当交代、 委託先変更、顧客説明に耐えさせるには、地味な設計を積み上げるしかない。 終章 2026 年時点の結論 2026 年時点の結論は明確である。SRE/DevOps の原則は変わっていないが、運用改善の構成要素は大き く変わった。RAG は Knowledge Operations へ、Agent は stateful runtime へ、MCP は接続面標 準へ、A2A は agent 間連携へ、Skills は再利用可能な作業知識へ、Digital Twin は安全装置へと役割が 定まりつつある。 したがって、これからの運用改善は「AI を入れるか」ではなく、「AI を含む運用系をどう設計・監視・評価・切り 戻し・教育するか」が論点になる。成功するのは、bounded autonomy、human takeover、knowledge governance、evaluation、audit を最初から設計に組み込む組織である。逆に失敗するのは、デモの見栄 えに引かれて、SoT 不一致、権限境界、誤検知、承認滞留、教育不足、レガシー制約を後回しにする場合であ る。 他業務への展開可能性
21. 21 | もっとも、AI 業界の進化速度はきわめて速く、2026 年時点で妥当な概念整理や構成が、そのまま数年後ま で流用できるとは限らない。モデル、接続標準、ツール実行方式、評価手法、ガバナンス要件は今後も更新され るだろう。しかし、それでも再利用しやすい核は残る。すなわち、入力を受け、根拠を集め、状態を確認し、人ま たはポリシーに照会し、限定された処理を実行し、結果を再観測し、証跡として残す、というワークフローであ る。 この構造は、IT 運用だけに閉じない。顧客からの注文、問い合わせ、障害申告、見積依頼、調査依頼、契約変 更、情報整理、社内申請といった入力を、Web、メール、チャット、電話一次受付、フォーム送信などから受け、 LLM と RAG を組み合わせた Agentic AI が初動整理、関連情報の収集、回答案生成、担当振分け、必要書 類確認、進捗通知、記録整形を補助する構成へ展開できる。ここに RPA や業務システム連携を重ねれば、単純 な画面転記や定型通知、台帳更新、証憑収集まで含めた柔軟な業務フローへ拡張しやすい。 重要なのは、これを『全部自動化する話』として扱わないことである。業務代行やバックオフィス支援へ広げる場 合も、bounded autonomy、権限境界、承認、例外時の人手介入、記録の完全性という原則はそのまま使え る。したがって本書で整理した設計思想は、特定製品や一時的な実装流行を越えて、今後の AI 活用業務基盤 を考えるための足場として応用可能である。 AI 時代の運用改善は、派手な推論よりも、地味だが堅い設計で決まる。本書が目指したのは、そ の「地味だが堅い設計」を、導入責任者と現場担当者が同じ言葉で議論できる形にすることであ る。 将来、モデルや接続標準が更新されても、「入力を整える」「根拠を管理する」「承認と実行を分ける」「再観測で 閉じる」という骨格は他業務にも移植しやすい。受注処理、問い合わせ一次対応、保守調整、契約変更、調査整 理、RPA 連携による事務処理支援へ広げる場合も、同じ bounded autonomy の考え方がそのまま効く。 別紙 1 導入チェックリスト PoC 着手前または商用導入前に、最低限確認すべき項目を整理する。すべてを一度に満たす必要はないが、 環境への実装と合わせて検討は行うべきである。未整備項目を把握せずに業務の(一部・完全)自律化へ進んむ 問題が起きる可能性が高いと考える。 項目 確認内容 状態 対象範囲 どの監視系、どの顧客、どの作業種別を対象にするか定義済みか □ 権限分離 read-only / approve / execute が分離されているか □ 知識鮮度 Runbook・FAQ・障害票に失効管理と責任者があるか □ SoT 方針 NetBox / CMDB / 台帳 / 実機差分の優先順位が定義されているか □ 承認設計 risk class、夜間ルール、承認不能時の扱いがあるか □ 実行境界 allowlist、kill switch、rollback 手順があるか □ 評価 offline eval、replay、canary のどれを実施するか決めているか □
22. 22 | 縮退運転 外部 API 停止やモデル障害時に search-only / suggest-only へ落とせる か □ 証跡 誰が、何を見て、何を承認し、何を実行したかを追跡できるか □ 体制 PoC 担当者以外へ引き継げる RACI と運用手順があるか □ 別紙 2 公開参照資料 以下は、本書の構成を補強するために参照しやすい公開資料である。いずれも公開情報であり、特定案件の内 部資料を前提としない。 注記: 参照資料のうち、仕様・公的ガイドラインは基準線として使える。一方、ロードマップ、ブログ、プレビュー、 experimental 表記付き機能は、実装方向をつかむための一次情報として価値が高いが、そのまま本番標準 や契約前提にはしない。とくに Azure AI Search の agentic retrieval、ADK における A2A、 OpenTelemetry の GenAI/MCP 計装は、成熟度ラベルを併記して読むべきである。 • OpenAI API Docs: Migrate to the Responses API / Responses Overview / Agents SDK / Tools / Agents / Agent Builder / Skills Blog • Microsoft Learn: Azure AI Search の agentic retrieval overview / quickstart / knowledge base 関連資料 • Model Context Protocol: specification / roadmap / 2026 roadmap blog • Google Developers Blog / ADK Docs: Agent2Agent Protocol announcement / ADK with A2A • OpenTelemetry: semantic conventions for generative AI / generative AI events / MCP semantic conventions • NIST: AI RMF 1.0、NIST AI 600-1 GenAI Profile、SP 800-218A、Cyber AI Profile 関連 資料 • 経済産業省: 中堅・中小企業等向け DX 推進の手引き 2025、DX 関連施策 • 中小企業庁: 2025 年版 中小企業白書 • IPA: 中小企業の情報セキュリティ対策ガイドライン 主要 URL https://developers.openai.com/api/docs/guides/migrate-to-responses/ https://developers.openai.com/api/reference/responses/overview/ https://developers.openai.com/api/docs/guides/agents-sdk/ https://developers.openai.com/blog/skills-agents-sdk/ https://developers.openai.com/api/docs/guides/tools/ https://learn.microsoft.com/ja-jp/azure/search/agentic-retrieval-overview https://learn.microsoft.com/ja-jp/azure/search/search-get-started-agentic-retrieval https://modelcontextprotocol.io/specification/2025-11-25 https://modelcontextprotocol.io/development/roadmap https://blog.modelcontextprotocol.io/posts/2026-mcp-roadmap/ https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/ https://google.github.io/adk-docs/a2a/ https://opentelemetry.io/docs/specs/semconv/gen-ai/ https://opentelemetry.io/docs/specs/semconv/gen-ai/gen-ai-events/ https://opentelemetry.io/docs/specs/semconv/gen-ai/mcp/
23. 23 | https://www.nist.gov/itl/ai-risk-management-framework https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-218A.pdf https://nvlpubs.nist.gov/nistpubs/ir/2025/NIST.IR.8596.iprd.pdf https://www.meti.go.jp/policy/it_policy/investment/dx-chukenchushotebiki/dx- chukenchushotebiki_2025.pdf https://www.chusho.meti.go.jp/pamflet/hakusyo/2025/PDF/chusho/00Hakusyo_zentai.pdf https://www.ipa.go.jp/security/guide/sme/about.html
24. 24 | 別紙 3 実戦シナリオ：アラートから限定復旧まで ここでは、Bounded Autonomy を前提にした Alert-to-Action の代表シナリオを簡潔に示す。対象は、 営業時間外に発生した「特定業務システムの疎通断・応答遅延」である。AI が勝手に復旧した、ではなく、観測 から提案、承認、限定実行、再観測、証跡化までをどう設計するかを追う。 実運用で重要なのは、どの段階で人に戻すかを最初に決めることである。アラートの一次受付は自動でよい が、原因推定と実行候補の提示をそのまま実行へ接続してはならない。SoT と実機が不一致の可能性がある 場合、過去障害票が古い構成を前提としている場合、または同時多発障害で依存関係が広い場合は、提案のみ 運転へ落とすべきである。 段階 AI/自動化の役割 人の判断 残す証跡 1. 受付 監視アラート受信、重複排除、影 響サービス推定 一次対応当番の有無を確 認 受信時刻、原アラート、重複判定ログ 2. Triage 関連ログ、メトリクス、過去障害 票、SoT 候補を収集 障害チケット起票 重要度と業務影響を確認 参照した情報源、引用箇所、関連イベ ント 障害対応チケット化 3. 提案生成 原因候補、確認手順、実行候補 を提示 候補の妥当性と禁止操作 有無を確認 提案本文、risk class、禁止項目チェ ック 4. 承認要求 承認者へ短い要約と実行候補を 送る 承認/差戻し/手動移管を 判断 承認者、判断時刻、コメント 障害チケット更新 5. 限定実行 allowlist 対象の軽微処理のみ 実行 危険兆候があれば中断指 示 実行コマンド、対象、戻り値 障害チケット更新 6. 再観測 メトリクス・ログ・疎通を再収集 本当に回復したか確認 再観測結果、diff、SLO 影響 障害チケット更新 7. 切戻し/縮 退 失敗時は rollback か提案のみ 運転へ切替 追加対応体制を判断 切戻し内容、縮退理由 障害チケット更新 8. 事後化 障害票更新、Runbook、評価 データへ反映 恒久対策の要否を判断 更新履歴、学習対象化の可否 このシナリオでの要点は三つである。第一に、AI は「判断の材料を揃える」段階で大きく効く。第二に、実行は 被害半径が小さく、切戻し可能で、監査しやすい処理に限定すべきである。第三に、再観測と事後更新を省く と、AI が提案したことの成否を次回へ学習させられない。AI 導入の価値は、実行の自動化より、観測・証跡・改 善ループの接続にある。
25. 25 | 別紙 4 AI SRE 変更管理テンプレート AI を含む運用系では、「コード変更」だけが変更ではない。モデル、埋め込み、reranker、parser、prompt、 tool description、policy、knowledge source の変更がすべて挙動に影響する。したがって、変更管理 票には通常のアプリ変更に加えて、評価対象、比較対象、縮退条件、切戻し条件を明記する必要がある。 変更種別 確認項目 最低限の判定条件 Model 切替、更新 対象ユースケース、長文耐性、コスト、tool call 成功率 canary で主要シナリオの成功率 が現行比で悪化しない Embedding 更改 再索引範囲、再計算時間、citation 欠落 offline eval と replay で recall 劣化が許容範囲内 Parser/OCR 更新 表・画像・PDF の抽出精度、bbox 整合 根拠プレビューが壊れず、主要帳票 の抜けがない Prompt/Policy 修 正 禁止操作、承認文言、説明責任 危険操作の抑止と説明文の一貫性 が保たれる Tool 追加・変更 権限境界、idempotency、失敗時の停止 read-only / execute の境界を 越えない Knowledge Source 追加 機密区分、鮮度、失効ルール 公開範囲と superseded 管理が 定義済み 本番反映 degraded mode、rollback、当番通知 切戻し手順と監視項目が運用側へ 共有済み 評価を伴わない変更は避けるべきである。とくに運用系では、回答が少し不自然になるより、承認文言が曖昧 になった、引用が欠落した、誤って execute 可能な tool が選ばれた、といった挙動変化の方が危険である。 したがって、変更管理は「賢くなったか」より「危険になっていないか」を先に見る。
26. 26 | 別紙 5 運用 RACI 雛形 AI を含む運用改善では、技術構成以上に、誰が責任を持ち、誰が承認し、誰が実行し、誰へ説明するかが重要 である。以下は、顧客、提供側、委託先/ベンダが混在する場合の最小 RACI 例である。 業務 顧客 提供側 委託先/ベンダ 監視一次判定 A R C Runbook/知識更新 C R C 変更承認 A C I 限定自動実行 C R I 障害一次報告 A R C 証跡保管 A R I モデル/検索更改 C R C 緊急停止判断 A R I この RACI で注意すべき点は、承認責任を顧客側が持つとしても、説明可能な材料を提供側が揃えなければ 承認は機能しないことである。AI が提案する世界では、承認者の負荷を減らすために要約と根拠を短く提示す る工夫が必要になる。一方で、その短さが判断材料不足につながってはならない。 別紙 6 使い方 提案段階では第 2 章〜第 4 章を中心に、顧客の現状制約と段階導入モデルを説明する。PoC 段階では第 4 章〜第 6 章と別紙 1、別紙 4 を用いて、対象範囲、評価、縮退、切戻しを定義する。運用受入では第 6 章〜第 8 章と別紙 5 を用いて、責任分界、承認、証跡、教育を確認する。改善計画では第 3 章、第 8 章、別紙 3 を用 いて、どこまで bounded autonomy を広げるかを見直す。 • Assist / Operate / Guarded Autonomy の三段階を顧客の成熟度に合わせて削る。 • PoC 計画書へ転用する場合は、変更管理と縮退運転を先に書き、成功条件を会話品質ではなく運用 KPI で置く。 • 運用受入資料へ転用する場合は、RACI、承認ルール、日常・夜間ルール、証跡保管、引継ぎ手順を明文化 する。 • 実装チーム向けには、Knowledge Operations と AI SRE の章を中心に、評価・監視・前版切戻しの 実装項目へ落とし込む。 • 運用改善で整えた triage / evidence / approval / execution / audit の骨格は、問い合わせ対 応、受発注補助、契約事務、調査代行、RPA 連携型のバックオフィス自動化へ横展開しやすい。
27. 27 | 別紙 7 実装ディープダイブ：HOW ここでは、提案資料や概念整理で終わらせず、現場レベルでの「具体的にどう作るか、どう乗り越えるか」を検討 できるよう、実装レベルの論点を補う。2026 年 3 月時点の先進導入や PoC で有力なのは、巨大な単一 Agent に全責務を持たせるのではなく、イベント駆動、疎結合、評価付きリリース、限定実行を基本にする構成 である。 運用改善で AI を使うときの難所は、モデルの賢さそのものより、入力の汚さ、既存運用との境界、実行権限、 観測の粗さ、トイルの偏在である。したがって、How の章では、Alert-to-Action、Graph RAG、可観測性、 SecOps/FinOps、スキルシフトの五つに分けて整理する。 0. 最小実装構成と責務分離 最初から巨大な基盤を目指す必要はない。PoC や小規模商用化の初期段階では、(1) ingress/queue、 (2) knowledge/SoT、(3) router/policy、(4) executor/HITL、(5) observability/audit の五 系統に分けられれば十分である。重要なのは製品名より責務分離であり、同じホスト上に同居させても、障害時 に「どこを safe mode に落とすか」が明確なら運用できる。 実装例としては、ingress で Webhook・メール・フォーム入力を受け、queue で再送吸収と順序ずれ耐性 を持たせ、knowledge/SoT で NetBox・CMDB・Runbook・障害票を統合し、router/policy が risk class と機密区分で経路を決め、executor が read-only / approve / execute を分離する。最後に observability/audit で request_id 単位の追跡を行う。この分離ができていれば、LLM を差し替えても 運用は崩れにくい。 責務 最小実装の例 止め方 Ingress / Queue Webhook 受信、メール取り込 み、永続キュー、dedupe ACK は維持し、下流だけ停止す る Knowledge / SoT Runbook、障害票、 NetBox/CMDB、版管理 新規取り込み停止、参照-only へ 落とす Router / Policy risk class、機密区分、モデル選 択、allowlist 判定 提案-only へ切替える Executor / HITL 承認カード、ジョブ実行、再観測、 rollback execute を閉じ、承認済みでも 待機させる Observability / Audit trace、評価ログ、変更履歴、証跡 保管 取得継続を優先し、欠落時は実行 完了扱いを禁止する 1. ALERT-TO-ACTION 実装のディープダイブと冪等性
28. 28 | 図 8 Alert-to-Action 実装ディープダイブ Alert-to-Action を実装するとき、最初に設計すべきは「何を実行するか」ではなく、「何を何回受けても壊 れないか」である。Webhook、SNMP Trap、Syslog、メール、チャット通知は、重複、遅延、順序逆転、再送 を前提に扱うべきであり、受信直後に永続キューへ退避し、request_id、evidence_id、entity_id、 dedupe_key を発番する。初動 ACK を LLM に依存させる設計は避ける。 冪等性は実行系の最後で担保するのでは遅い。ジョブ投入時点で idempotency key を持ち、同一 entity に対して lease または lock を取得し、同じ remediation を短時間に再発火させない設計が要る。 Ansible であれば "state=started" や "creates" を用いた収束型記述、Terraform であれば plan/apply の分離と drift 検出、シェルスクリプトであれば前提条件確認、実行済みマーカー、後続再観測 の三点を最低限入れるべきである。 Kill Switch と Safe Mode も、概念だけでなく配線として実装する必要がある。実戦では、API Gateway、policy engine、tool executor のいずれか一箇所にスイッチを置くのではなく、少なくとも 「実行 API を閉じるスイッチ」と「LLM の応答を提案専用へ切り替えるスイッチ」を分ける。これにより、外部 API 障害、誤検知急増、評価結果悪化、承認待ち滞留が起きたときも、監視・要約・提案の価値を残しつつ execute だけを止められる。 HITL の UI/UX も重要である。Slack や Teams の承認カードは、長文説明よりも、対象、影響範囲、根拠、 候補操作、切戻し、観測結果、残留リスクを一画面で比較できる設計が望ましい。承認ボタンの前に、引用元リ ンク、SoT 差分、過去類似障害票、制約条件、予定自動タイムアウトを並べると、運用者は「何を根拠に承認すべ きか」を短時間で判断しやすい。 制御点 推奨実装パターン 抜けた場合の失敗モード 受信入口 永続キュー、request_id、重複排除、時 刻正規化 Webhook 再送で二重起票、順序逆 転で誤判定 実行制御 entity lock、lease、idempotency key、再観測必須 同一機器へ再起動が連打される、切 戻し不能
29. 29 | 縮退運転 proposal only、tool close、 timeout budget、manual takeover LLM 遅延や誤検知増大で execute まで到達 承認 UX 根拠・影響範囲・切戻し・過去事例を一画 面表示 承認者が要約だけ見て危険操作を通 す 2. GRAPH RAG とハイブリッド検索の実践 インフラ・ネットワーク運用では、単なるベクトル検索だけで根因へ到達するのは難しい。原因調査では、「どの 回線が、どの拠点ルータに収容され、その先のファイアウォール、LB、仮想基盤、業務サーバ、SaaS 接続へどう 依存しているか」という構造を辿る必要がある。これは意味の近さより、接続関係、依存関係、責任分界、工事 予定、監視抑止状態を持つグラフの方が表現に向く。 実装では、NetBox や CMDB の設計情報、実機から収集した LLDP/BGP/ARP/ルーティング/インタフェ ース状態、工事チケット、監視抑止設定、顧客別の保守契約を、graph store と vector index の両方へ流 す構成が扱いやすい。初段は graph query で影響半径と候補ノードを絞り、その後に vector / lexical / rerank で runbook、障害票、設計書、変更履歴を引く。Graph 側の主語が曖昧だとベクトル検索の質も落 ちるため、名称揺れ、環境名、装置別名、顧客コードの名寄せは必須である。 チャンク分割も、一般的な固定文字数では不十分である。Runbook は「前提条件」「確認コマンド」「実行コマン ド」「再観測」「切戻し」を一塊にし、障害票は「検知」「原因」「対処」「結果」「恒久対策」を単位化した方が後段の tool selection と相性がよい。Syslog や Trap は、時刻、装置、facility、severity、event code、関連 entity をメタデータとして持たせ、イベント群単位で束ねると incident merge がしやすい。 また、Graph RAG を運用へ入れるときは、机上構成と実レイヤ差分を隠さないことが重要である。工事中の 迂回構成、暫定抑止、顧客依頼による例外設定、既知不具合回避のための特殊 ACL などは、設計上はノイズで も運用上は主役になる。したがって、graph schema には「planned」「actual」「suppressed」 「maintenance」「contract-boundary」のような状態属性を持たせる方が実務に向く。 ログや設定ファイルを LLM へ渡す前には、IP アドレス、顧客名、メールアドレス、契約番号、パスワード、秘密 鍵断片、接続先 URL、個人名をローカルで検知し、マスキングまたは匿名化する前処理がいる。とくに API 型 LLM を併用する場合は、文書単位ではなくチャンク単位、表単位、添付単位で機密区分を持たせ、外部送信禁 止データは router が強制的に local path へ落とす設計が望ましい。 3. AI SRE のための可観測性と評価
30. 30 | 図 9 Offline Evals と LLM FinOps / Guardrail ルーティング AI SRE を実務へ落とすには、会話ログを保存するだけでは足りない。入力受付、検索、rerank、model inference、tool call、approval、execution、再観測を一つの trace として接続し、どこで遅れ、どこで 危険な分岐が起きたかを追えるようにする必要がある。実装では OpenTelemetry を基盤にし、 request_id / trace_id を ingress から executor まで引き回すと、障害解析とコスト分析を同時に行い やすい。 計装では、少なくとも input_class、queue_wait_ms、retrieval_ms、rerank_ms、 model_latency_ms、tokens_in/out、tool_call_name、tool_call_result、approval_wait_ms、 execution_ms、reobserve_ms、fallback_reason を span/metric として持たせたい。運用現場で は、回答の良し悪しより「初動が何秒遅れたか」「どの分岐で safe mode に落ちたか」「どの tool が失敗した か」の方が重要になる。 評価は、online と offline を分ける。online は SLI/SLO、承認滞留、引用欠落率、危険操作要求率、safe mode 発動率を見る。offline は、過去障害票や問い合わせチケットを golden set 化し、prompt・ model・parser・tool description を変えるたびに replay を実行して、回答妥当性、引用整合、危険操作 の抑止、ツール選択ミス、コスト増大を採点する。回帰試験がないまま prompt だけを都度直す運用は、中長 期で必ず破綻する。 実戦では、CI/CD パイプラインと評価パイプラインを接続する。モデル変更や parser 更新が push された ら、Replay Runner が黄金データセットを流し、基準を満たしたときだけ canary または shadow へ進め る。Fail した場合は自動で safe mode 維持、前版継続、または prompt rollback を返す。重要なのは「賢 くなったか」ではなく「危険になっていないか」を先に判定することである。 4. AI 運用特有のセキュリティとコスト管理 運用基盤に接続された Agent は、一般的なチャットボットより危険である。悪意あるユーザー、乗っ取られた 監視エージェント、汚染されたログ、外部メール本文が「至急すべて再起動せよ」「認証エラー回避のため秘密情 報を表示せよ」といった命令を紛れ込ませる可能性がある。したがって、入力テキストはそのまま model に信
31. 31 | 用させず、instruction と evidence を分離し、危険な命令句、外部 URL、秘密情報要求、権限昇格要求を 前段で検査する必要がある。 防御は一層では不十分である。推奨は、①入力サニタイズ、②tool allowlist、③policy engine、④危険操 作専用の二段階承認、⑤executor 側の権限最小化、⑥監査ログ、の多層防御である。たとえ model が欺か れても、tool executor が allowlist と引数検証で止め、さらに privileged action は別経路の承認が なければ到達しない構造にしておく。 FinOps の観点では、すべてを高価な API 型 LLM へ投げる設計は続かない。大量ノイズの一次分類、定型 問い合わせの下書き、短文の障害要約、機密ログの部分整形は local LLM へ寄せ、高度な比較推論、長文の 承認説明、複数候補の優先順位付けだけを商用 API へ送る方が実務に合う。router には、機密区分、SLA、 時間予算、予算上限、現在の API 利用状況を持たせ、強制的に path を切り替えられるようにする。商用 API へ情報を送るため AI での学習に使われないようにする環境をエンラープライズ契約やクラウド環境利用 し構築などが必要となる。 コストは月末集計では遅い。input class 別、顧客別、ワークフロー別に tokens、latency、cache hit、 fallback 率、外部 API 依存率を見える化し、「なぜこのチケット種別だけ高いのか」「local で処理できる案 件を API に流していないか」を定期的に見直すべきである。これは単なる節約ではなく、将来の商用単価設計 にも直結する。 観点 最低限の実装 運用監視指標 よくある落とし穴 Prompt Injection 入力サニタイズ、命令 /evidence 分離、危険文言 検査 危険入力検出率、遮断 率、誤遮断率 監視ログ本文をそのまま system 指示として扱う 権限分離 tool allowlist、引数検証、 特権操作の二段階承認 特権操作要求率、拒否 率、未承認実行ゼロ LLM 側だけで安全を担保しよ うとする FinOps local/API/rule の三系統ル ーティング token/件、API 依存 率、顧客別原価 すべてを高性能モデルへ送って しまう 5. 運用エンジニアのスキルシフトとトイルの再定義 AI を導入した運用現場では、「手順書どおりに実施する」だけでは価値が出にくくなる。代わりに重要になるの は、Runbook、設計意図、構成差分、制約条件、承認条件を、LLM が読める形で構造化する能力である。 Markdown、YAML、宣言的設定、タグ設計、命名規約、変更理由の記録、再観測条件の明文化は、今後のイン フラエンジニアの基礎体力になる。 スキルセットとしては、Python やシェルの自動化だけでなく、知識の版管理、評価データセットの整備、ログの 匿名化、OpenTelemetry の計装、LLM ルーティング設計、HITL UI の要件定義まで含まれる。要するに、 単純な「AI を使える人」ではなく、「AI を安全に運用へ入れられる人」が必要になる。 KPI も再設計すべきである。AI 導入の成果を自動化率だけで測ると、危険な自動実行を増やす方向へ歪みや すい。代わりに、MTTR 短縮、初動要約時間、エスカレーション率、再観測実施率、引用付き提案率、トイル削減 時間、承認差戻し率、問い合わせ一次解決率をダッシュボード化すると、運用品質と説明可能性を両立しやす い。 トイルの再定義も必要である。AI 時代のトイルは「人が画面を何回クリックしたか」だけではない。似た問い合 わせに毎回同じ説明をすること、深夜アラートの根拠を毎回手で集めること、承認者向けに同じ定型説明を作 ること、障害後に暫定手順を正式化しないことも、新しい意味でのトイルである。したがって、削減対象は単純 作業そのものだけでなく、知識が運用へ戻らない構造まで含めて捉えるべきである。 6. 実装着手前の最低限チェック
32. 32 | PoC や商用化の前に、以下の項目が未整備であれば、モデル選定より先にそこを埋める方が成功率は高い。実 装チーム、運用責任者、承認者、顧客窓口の四者で最低限すり合わせたい観点を簡潔に示す。 最低限チェックの狙いは、ツール選定を遅らせることではない。逆に、入力受付、知識管理、権限分離、再観測、 証跡化のどこが未整備かを先に可視化し、PoC で「何を実証し、何をまだ実証していないか」を明確にするた めである。ここが曖昧なままモデル比較へ進むと、最後に残るのは性能表ではなく責任の空白になる。 確認項目 最低条件 未整備時のリスク 入力受付 request_id、時刻同期、永続キ ュー、再送吸収 イベントストーム時に取りこぼし/二重処理 知識管理 owner、scope、valid_to、 tombstone、引用可能性 古い手順や危険情報を再利用 実行制御 allowlist、risk class、 rollback、safe mode 誤実行しても止められない 承認系 承認者、夜間連絡、承認タイムア ウト、差戻し導線 承認待ちが滞留し現場が bypass する 評価 golden set、replay、危険操 作判定、前版切戻し prompt 修正のたびに品質が揺れる 可観測性 trace_id、tool 結果、 latency、cost、fallback reason 問題が起きても原因が追えない 別紙 8 図版集：POC から商用展開への進化 本文の議論を読み手が頭の中で接続しやすいよう、実装・段階導入・統制難度を図で再整理する。提案説明、社 内レビュー、設計方針合わせに転用しやすいよう、文章の要点だけを引き抜いた構成にしている。 図 12 PoC から商用展開への進化ロードマップ
33. 33 | 運用改善では、Assist と Operate の品質を固めないまま Guarded Autonomy へ飛ばない方が成功率 が高い。読者へ『どこから始めるべきか』『どこで一度止めて統制を入れるべきか』を見せる用途を想定してい る。 別紙 9 2026 年 3 月時点の補足参照資料 本別紙は、本文の『2026 年 3 月時点』表現のうち、公開情報で裏取りしやすいものだけを抜き出した追補で ある。現場実装の所見とは分けて参照し、標準・プレビュー・実験的の混同を避けることを意図している。 • OpenAI API Changelog（developers.openai.com/api/docs/changelog/）— 2026 年 3 月の更新として、Responses API の tool search、built-in computer use、1M token context と compaction など長時間の agent workflow を意識した更新が記載されている。 • OpenAI Blog『Using skills to accelerate OSS maintenance』 （developers.openai.com/blog/skills-agents-sdk/）— 2026-03-09。Skills の実運用文脈 が確認できる。 • Azure AI Search『Agentic retrieval overview』 （learn.microsoft.com/azure/search/agentic-retrieval-overview）— agentic retrieval は複雑問い合わせ向け multi-query pipeline とされ、public preview 扱いの注意書きがある。 • Azure AI Search『What’s New』（learn.microsoft.com/azure/search/whats-new）— 2026 年 3 月更新項目を確認できる。 • Model Context Protocol『Specification / Key Changes』 （modelcontextprotocol.io/specification/2025-06-18, /2025-11-25/changelog）— MCP のベース仕様と 2025-11-25 時点の変更点を追える。 • Google Developers Blog『Announcing the Agent2Agent Protocol (A2A)』 （developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/）— A2A の狙いと位置付け。 • Google ADK Docs『ADK with Agent2Agent (A2A) Protocol』『Skills for ADK agents』 （google.github.io/adk-docs/...）— A2A / Skills は experimental 表記を含み、成熟度差の把 握に有用。 • OpenTelemetry『Semantic conventions for generative AI systems』『Semantic conventions for MCP』（opentelemetry.io/docs/specs/semconv/gen-ai/）— GenAI と MCP の semantic conventions は development / experimental 系の注意が残る。 • NIST AI 600-1『Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile』— 生成 AI のリスク管理の基準線として参照。 上記は 2026-03-24 時点で確認した公開情報である。本文の設計判断は、これらの公開情報に、現場 PoC・評価実装・運用設計の知見を重ねている。