AI SOCとは？AIシステムの異常監視を発注時に確認する7項目

ベンダーから届いた提案書に「AI SOC」という見慣れない言葉が並んでいます。一方で、AIシステムの開発を依頼した別のベンダーの見積書には「運用保守費」という一行があるだけで、中身の説明がありません。この2つは同じものなのか、それぞれ別のものを買うべきなのか。判断がつかないまま、上司から「今回作るAIも、その監視で見てくれるの？」と聞かれて答えに詰まる。こうした状況は、AI導入を進める情報システム部門で珍しくありません。

判断が難しいのには理由があります。「AI」と「監視」という2つの言葉が共通しているせいで、まったく層の違うものを比較させられているからです。AI SOC はセキュリティを守る側の運用体制をAIで強化する話であり、発注したAIシステムの異常監視は守る対象であるAI自身の振る舞いを見る話です。目的も監視対象も、契約相手すら異なります。ところが提案書の上では、どちらも「AIの監視」として並んで見えてしまいます。

この混同が放置されると、両者の間に監視の空白地帯が生まれます。セキュリティ監視サービスを契約したので安心していたら、社内AIの回答精度が数か月かけて静かに落ちていて誰も気づかなかった、というケースがあります。逆に開発ベンダーの運用保守に任せていたら、不正な利用の兆候は監視対象外だったというケースもあります。どちらも、発注の段階で範囲を言葉にしていなかったことが原因です。

さらに厄介なのは、監視要件を書ける人が社内にいないことです。サーバーの死活監視やリソース監視の経験はあっても、AIの精度劣化やトークン消費の監視を非機能要件として書き起こした経験がある担当者はまだ多くありません。そのためベンダーの提案をそのまま受け入れ、稼働後に「それは契約範囲外です」と言われるリスクを抱えたまま進んでしまいます。

本記事では、まず AI SOC という言葉の輪郭を SOC・MDR・SIEM・SOAR・XDR との関係から整理し、混同されがちな「AIシステムの異常監視」と明確に分離します。その上で、AIシステム特有の異常を5類型に分け、発注時にベンダーへ確認すべき7項目、見積書・契約書での読み解き方、そして監視体制の切り分け方までを解説します。読み終えたときに、次のベンダー打ち合わせに持ち込む確認項目が手元に残る構成にしています。

—Free Download / 資料ダウンロード

システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集

この資料でわかること

システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。

こんな方におすすめです

• 初めてシステム開発を外注する担当者
• 過去の発注で失敗を経験した方
• ベンダー選定の基準が分からない方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。

ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。

AI SOCとは？AIでセキュリティ監視を自動化する運用体制

AI SOC とは、企業のセキュリティ監視を担う SOC（Security Operation Center）の業務に AI を組み込み、アラートの選別・調査・初動対応の一部を自動化した運用体制を指します。「AI SOC とは何か」を一言でまとめるなら、守る側の運用をAIで効率化した監視体制です。

ここで押さえておきたいのは、AI SOC が監視しているのは「攻撃や侵害の痕跡」であるという点です。ネットワーク通信、認証ログ、端末の挙動といったデータから不審な動きを見つけ出すのが役割であり、自社が新しく開発するAIシステムの品質を見ているわけではありません。この前提は後ほど「混同しやすい2つの監視」で詳しく扱います。

そもそもSOCとは

SOC は、セキュリティに関するログやイベントを24時間365日体制で見張り、異常があれば分析して対処するチーム・組織を指します。担う機能は大きく4つに整理できます。

24時間体制が必要になるのは、攻撃が営業時間を選んでくれないからです。しかし人手でこれを回すと、アラート件数の増加に対して分析できる人数が追いつかず、確認が後回しになるアラートが積み上がります。この構造的な負荷を AI で緩和しようという発想が、AI SOC の出発点です。

なお、サーバーが生きているか・CPU使用率が高くないかを見る死活監視やリソース監視は、SOC の守備範囲とは別物です。同じ「監視」という言葉でも、見ている対象が「システムの健康状態」か「攻撃の痕跡」かで役割が分かれます。

AI SOCで自動化される範囲

SOC運用の自動化において、AI が受け持つのは主に「分析」とその前段の整理です。調査会社 Gartner は2025年10月のレポート「Innovation Insight: AI SOC Agents」で AI SOC エージェントを、アラートのトリアージ（優先度付け）、アラートのエンリッチメント（脅威情報や資産情報との突き合わせ）、ガイド付き調査、タイムラインの再構成、攻撃経路のマッピング、経営・監査向けのインシデント要約といった一般的なSOC業務の実行をアナリストが行うのを支援するAIソフトウェアと定義しています（出典: Innovation Insight: AI SOC Agents、Gartner、2025年10月。日本語での解説はAIエージェントSOCの時代――アナリストを「置き換える」のではなく「増強する」を参照）。

注目したいのは、この定義が最初から「アナリストを支援する」と書かれていることです。AI が単独で判断を完結させる設計ではなく、人の作業を速くする位置づけが前提になっています。

国内でもサービスとしての提供が始まっています。NTTドコモビジネスは2026年5月20日に「AI SOC」の提供を開始し、ログの横断的な相関分析を担う「AI Advisor」と、検知後の対処を自動実行する「マネージドSOAR」を組み合わせる構成を採っています（AIを駆使してサイバー攻撃の脅威を分析・自動対処する「AI SOC」の提供を開始）。同社の発表では、従来は熟練アナリストが1〜2時間かけていた相関分析を約10分に短縮し、アラートへの対応の約95%を自動化するとされています（NTTドコモビジネス、サイバー攻撃の脅威を自動検知・自動対処するSOCサービス、IT Leaders）。

ただしこれらの数値はサービス提供事業者の発表値であり、自社のログ量・システム構成・運用ルールが異なれば同じ結果になるとは限りません。提案書で同様の数値を提示された場合は、その数値が何を母数にした割合なのか、自社環境で再現する前提条件は何かを必ず確認してください。発注判断の根拠にするには、数値そのものよりも「その効果が出る条件」の方が重要です。

「完全自動」ではない：封じ込めなど重要アクションは人の承認が標準

AI SOC を検討するときに最も誤解されやすいのが、自動化の到達点です。業界の標準的な立場は「完全自律のSOC」ではなく、人が要所で関与する Human-in-the-loop 型です。

セキュリティ自動化ベンダーの Swimlane は、AI SOC の目標を「完全に自律的なSOCではなく、人間による制御が機能する、より効率的なSOC」と明言しています（AI 駆動型セキュリティオペレーションセンター: AI SOC の説明）。Elastic も、確度の高い既知の脅威は自律的に処理させ、新規性の高い事象や判断が曖昧な事象は人の関与を残すハイブリッドモデルを推奨しています（2026年がエージェント型AI SOCへのアップグレードの年である理由）。

発注者にとってこの前提が意味することは、はっきりしています。端末の隔離・アカウントの停止・サービスの一時停止といった業務影響の大きいアクションは、最終的に自社の誰かが承認するということです。つまり AI SOC を契約しても、承認できる人と連絡が取れる時間帯を社内で決めておかなければ、自動化の効果は止まってしまいます。この「誰が承認するのか」は、後ほど確認項目として改めて扱います。

AI SOCとSOC・MDR・SIEM・SOAR・XDRの違い

提案書や見積書には、SOC・MDR・SIEM・SOAR・XDR といった略語が並びます。これらは互いに置き換え可能な選択肢ではなく、レイヤの違うものです。組織の話・製品の話・サービス提供形態の話が混在しているため、横並びで比較すると判断を誤ります。

「SOC と MDR の違い」が分かりにくいのも、SOC が組織・体制を指す言葉で、MDR がサービスの提供形態を指す言葉だからです。同じ軸で比べられるものではありません。

用語の関係を1枚で整理する

なお、IT運用の障害検知や原因分析を AI で効率化する考え方は AIOps と呼ばれ、AI SOC とは対象ドメインが異なります。AIOps はシステムが正常に動いているかを扱い、AI SOC は攻撃されていないかを扱います。両者を混同すると「運用監視の自動化を導入したのでセキュリティ監視も足りている」という誤った整理につながるため、提案書で AIOps 的な機能が含まれている場合は守備範囲を切り分けて確認してください。

提案書・見積書ではどの名前で現れるか

用語のレイヤを把握すると、見積書を2つの観点で読めるようになります。

観点1: 同じものを二重に買っていないか。 たとえば「XDRライセンス」と「SIEMライセンス」が別項目で並び、さらに「マネージドセキュリティサービス」が計上されている場合、ログの集約機能が重複している可能性があります。どの製品がどのログを持ち、相関分析をどこで行うのかを1枚の図にしてもらうと重複が見えます。

観点2: 対応が誰にも割り当たっていないか。 より深刻なのはこちらです。SIEM や XDR は製品であり、アラートを出すところまでが役割です。誰がそのアラートを見て、誰が対処するのかは製品の外側の話です。見積書に製品ライセンスだけが並び、運用の人員や対応の役務が計上されていない場合、アラートは出るが誰も見ない状態になります。

確認の仕方はシンプルです。見積書の各項目について「これはログを集める話ですか、アラートを出す話ですか、アラートを見る話ですか、対処する話ですか」と聞いてください。4つのうち埋まっていない役割が、そのまま空白地帯になります。

混同しやすい2つの監視：AI SOCと「AIシステムの異常監視」

ここが本記事の中心です。AI SOC を検討している発注者が最も取りこぼしやすいのは、自社が今つくろうとしているAIシステムそのものの異常は、AI SOC の監視対象ではないという事実です。

この2つを分けて考えられるようになると、「上司の質問に答えられなかった」状態から抜け出せます。

AI SOC は「守る側」がAIを使う

AI SOC は、防御する側の運用に AI を持ち込む取り組みです。監視対象は攻撃者の痕跡であり、判断すべきは「これは侵害か、誤検知か」です。AIセキュリティ監視体制として AI SOC を導入する目的は、アラートの山を捌く速度を上げ、見落としを減らすことにあります。

重要なのは、AI SOC にとって自社のAIシステムは「守るべき資産の一つ」に過ぎないという点です。そのAIシステムに対する不正アクセスや認証の異常は監視対象になり得ますが、AIの回答が業務上おかしくなっているかどうかは、セキュリティ監視の判断基準の外にあります。

AIシステムの異常監視は「守る対象」がAIになる

一方、自社が発注したAIシステムの異常監視は、AI自身の入力と出力、そして振る舞いを見る取り組みです。見るべきものは攻撃の痕跡ではなく、精度・出力品質・リソース消費といった品質指標です。

公的なガイドラインでもAIシステムの挙動を見続ける必要性は明示されています。内閣府と内閣サイバーセキュリティセンターが共同署名に加わって公表したセキュアAIシステム開発ガイドラインでは、システムの挙動を監視し、潜在的な侵入や侵害を検知できるようにする必要があると規定されています。ただしガイドラインは「必要である」と示すもので、発注者がベンダーに何をどう確認すればよいかという手順までは示していません。その翻訳作業が、発注者側に残されています。

2つの間に空白地帯が生まれる仕組み

2つの監視を観点別に並べると、重なっていない部分がはっきりします。

空白地帯は、この表の「どちらの列にも書かれていないもの」ではなく、両者が互いに相手の仕事だと思っているものとして生まれます。典型的な抜け落ちを3つ挙げます。

抜け落ち1: 精度劣化が誰の担当でもない。 セキュリティ監視事業者は「AIの回答品質は我々の範囲外」と考え、開発ベンダーは「精度は納品時に基準を満たしていた」と考えます。結果として、稼働後に精度が下がっていく過程を誰も見ていません。

抜け落ち2: 夜間の一次対応者が決まっていない。 セキュリティ監視は24時間体制でも、開発ベンダーの運用保守は平日日中のみという組み合わせは珍しくありません。夜間にAIシステム側の異常が起きた場合、アラートは飛ぶが受け手がいない状態になります。

抜け落ち3: 利用量とコストの急増に誰も気づかない。 生成AIを使うシステムでは、利用が想定を超えると請求が跳ねます。セキュリティ監視は攻撃を見ており、開発ベンダーは稼働を見ています。請求額を見ているのは、月次で経理から回ってくる明細を確認する自社の担当者だけ、という構図になりがちです。

つまり空白地帯は技術的な難しさから生まれるのではなく、誰の仕事かを決めていないことから生まれます。だからこそ、発注の段階で言葉にしておけば潰せます。

AIシステム特有の「異常」とは何か（従来の監視では捕まらない5類型）

空白地帯に落ちる異常の中身を具体化します。AIの異常検知・監視で厄介なのは、サーバーは正常に動いていて、エラーログも出ていないのに、AIだけが壊れている状態があるという点です。死活監視・リソース監視・エラー率監視をすべて緑にしても検知できない類型を5つに整理します。

ここで列挙する5類型が、次の章の確認項目の材料になります。各類型では「どの指標で見るか」と「気づかないと業務上どうなるか」をあわせて示しますので、自社の業務に当てはめながら読み進めてください。

精度が静かに落ちる：データドリフトとコンセプトドリフト

AIモデルの精度は、稼働後に少しずつ低下していくことがあります。データドリフト検知の文脈では、この現象は2つに分類されます。

• データドリフト: 入力データの統計的な分布が学習時から変化する現象
• コンセプトドリフト: 入力と出力の関係性そのものが変化する現象

コンセプトドリフトの分かりやすい例として、パンデミック期に消費者行動が急変し、それまでの需要予測モデルが機能しなくなったケースが挙げられます（AIモデルのドリフト検知とは？）。社内向けの問い合わせ対応AIであれば、組織改編で部署名が変わった、新しい社内規程が増えた、といった業務側の変化がドリフトの引き金になります。

定量的に検知する指標としては PSI（Population Stability Index）や KL ダイバージェンスが使われ、Evidently AI・Arize・WhyLogs といった監視ツールが用いられます（同上）。発注者として指標の計算方法まで理解する必要はありませんが、何をドリフトの兆候とみなし、どの頻度で確認し、閾値を超えたら何をするのかが決まっているかは確認が必要です。

気づかないと何が起きるか。精度劣化は段階的に進むため、ある日突然システムが止まるわけではありません。利用者が「最近この AI は使えない」と感じて静かに使うのをやめ、数か月後に利用率の低さだけが問題として浮上します。そのときには、どの時点から劣化が始まったのかを追跡できるログが残っていないことが多くあります。

出力品質の異常：ハルシネーション・回答拒否・フォーマット崩れ

生成AIを使うシステムでは、精度指標では捉えにくい出力の異常が起こります。

OWASP が公開している生成AIアプリケーションのリスク一覧では、誤情報（Misinformation）が LLM09 として独立した項目に挙げられています（OWASP Top 10 for LLM Applications 2025）。つまりハルシネーションは「たまに起こる不具合」ではなく、設計段階から対策と監視の対象として扱うべきリスクに位置づけられています。

このうちフォーマット崩れは後続処理のエラーとして検知できる可能性がありますが、ハルシネーションと回答拒否の増加は、出力内容を評価する仕組みがなければ数値になりません。誰がどうやって評価するのかは、発注時に決めておく必要があります。

AI固有の攻撃を監視する：プロンプトインジェクションと不正利用

プロンプトインジェクション対策を検討するうえで前提になるのは、この攻撃が生成AIアプリケーション固有のリスクの第一位に挙げられているという事実です。OWASP の生成AIアプリケーション向けリスク一覧では、プロンプトインジェクションが LLM01 として2版連続で最上位に位置づけられています（LLM01:2025 プロンプトインジェクション、非公式日本語訳）。

同じ一覧には、機密情報の漏えい（LLM02: Sensitive Information Disclosure）、システムプロンプトの漏えい（LLM07: System Prompt Leakage）、無制限な消費（LLM10: Unbounded Consumption）も含まれています。これらはいずれも、ネットワーク層の不審通信を見る従来型の監視では検知しにくい類型です。攻撃はAIへの入力という正規の経路を通って届くためです。

発注者として押さえるべき論点は3つです。第一に、入力を検査する仕組みがあるか。第二に、疑わしい入力や出力を記録し、後から追跡できるか。第三に、検知したときに遮断するのか、記録だけして通すのかという方針が決まっているか。とくに三番目は運用への影響が大きく、遮断の判断を誰がするのかまで決めておかないと、検知しても止められません。

推論コストの異常増加（トークン消費の急増を誰が見るか）

生成AIを使うシステムは、利用量がそのままコストに直結します。従来のシステムでは、利用が増えてもサーバー費用が階段状に上がる程度でした。ところがモデルAPIを従量課金で使う構成では、利用の急増が即座に請求額の急増になります。

急増の原因は悪意のある攻撃だけではありません。社内で便利だと評判になって利用が想定の何倍かに伸びた、処理の不具合で同じリクエストが繰り返し送られている、長い文書をまるごと投げる使い方が定着した、といった正常な経路での増加も起こります。

問題は、この増加を監視している人が誰もいないことです。セキュリティ監視は攻撃を見ており、開発ベンダーの運用保守はシステムの稼働を見ています。トークン消費量の推移を日次で見て、想定を超えたら知らせるという役割は、明示的に割り当てなければ空席のままになります。

外部モデルAPIの仕様変更・サイレント更新による挙動変化

外部の生成AIサービスをAPI経由で使う構成では、自社が何も変更していないのにAIの挙動が変わることがあります。提供側でモデルが更新された、利用していたモデルのバージョンが非推奨になった、応答の傾向が変わった、といった理由です。

自社のコードは1行も変わっていないため、リリース履歴を追っても原因は見つかりません。しかし利用者からは「先週までと回答が違う」という指摘が上がります。

この類型への備えとして、発注時に確認したいのは次の3点です。使用するモデルのバージョンを固定しているか。提供側の変更告知を誰が追跡し、影響を評価するのか。挙動の変化を検知するための基準となる入出力のセット（回帰テスト用のサンプル）を用意し、定期的に実行する運用になっているか。いずれも技術的には難しくありませんが、やる人を決めなければ実行されない種類の作業です。

—Free Download / 資料ダウンロード

システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集

この資料でわかること

システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。

こんな方におすすめです

• 初めてシステム開発を外注する担当者
• 過去の発注で失敗を経験した方
• ベンダー選定の基準が分からない方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。

ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。

発注時に確認するAI異常監視の7項目

ここまでで整理した5類型を、ベンダーに投げる質問の形に変換します。監視要件を自分で書き起こす必要はありません。質問として持ち込めば、回答を集めることが実質的な要件定義になります。

各項目は「聞くこと」「合格ラインの回答」「曖昧な回答だったときの追い質問」の3点セットで示します。次の打ち合わせの議題としてそのまま使える粒度にしています。

①監視対象メトリクスの定義

聞くこと: 「このAIシステムについて、稼働後に監視する指標を一覧で示してください。それぞれ、誰がどの頻度で確認しますか」

合格ラインの回答: 指標が一覧として提示され、各指標に確認主体と頻度が紐づいている状態です。たとえば「応答時間とエラー率は自動監視で常時、回答品質のサンプル評価は月次でベンダー側、トークン消費量は日次で自動集計しダッシュボードで自社が確認」のように、指標・主体・頻度の3点がそろっていることが条件です。

曖昧だったときの追い質問: 「稼働監視をします」「ログを取得します」という粒度の回答が返ってきた場合は、対象を具体化します。「サーバーが正常でエラーも出ていないが、AIの回答内容がおかしい状態は、どの指標で気づけますか」と聞くと、品質監視が含まれているかどうかがはっきりします。

監視項目をどう設計するかという技術的な観点は、AIエージェントのオブザーバビリティとは？監視の勘所6選で整理しています。ベンダーの提示する一覧と照らし合わせると、抜けている観点が見つけやすくなります。

②異常判定のしきい値と再学習・モデル更新のトリガー

聞くこと: 「各指標について、どの値を超えたら異常と判断しますか。精度が落ちてきた場合、再学習やモデル更新はどの条件で実施し、費用は誰が負担しますか」

合格ラインの回答: 指標ごとに具体的な数値の基準があり、基準を超えたときのアクションが決まっている状態です。加えて、モデルの再学習やプロンプトの調整が契約の範囲内なのか、追加費用が発生するのかが明記されていることが重要です。精度劣化への対処が全て別見積になる契約では、劣化を検知しても対処が進みません。

曖昧だったときの追い質問: 「状況に応じて判断します」という回答の場合は、判断の主体と期間を確定させます。「判断するのはどちらですか。判断のための材料は誰がいつ提供しますか。判断から対処着手までの目安はどれくらいですか」と聞いてください。

③アラート通知先と一次対応者（夜間・休日の扱い）

聞くこと: 「異常を検知したとき、誰にどの手段で通知されますか。営業時間内と夜間・休日で、一次対応するのは誰ですか」

合格ラインの回答: 時間帯ごとに一次対応者が明記され、通知手段（メール・チャット・電話）と自社側の受け手が決まっている状態です。先ほど触れたように、AI SOC を含むセキュリティ監視でも業務影響の大きい措置は人の承認が前提になります。承認できる人と、その人に連絡が取れる時間帯を社内側でも決めておく必要があります。

曖昧だったときの追い質問: 「検知後にご連絡します」という回答では、連絡の速さと自社の負担が見えません。「連絡までの目安時間は何分・何時間ですか」「夜間に検知した場合、翌営業日の連絡になりますか」「連絡を受けた自社側が判断できない場合、判断を支援してもらえますか」の3つを重ねて聞くと、実際の運用像が見えます。

④入出力ログの保存範囲・保持期間と機密情報の取り扱い

聞くこと: 「監視のために、AIへの入力と出力をどこまで保存しますか。保存先はどこで、保持期間は何日ですか。機密情報や個人情報が含まれた場合の取り扱いはどうなりますか」

合格ラインの回答: 保存する項目（入力全文かメタデータのみか）、保存先（自社環境かベンダー環境か、リージョンはどこか）、保持期間、アクセスできる人の範囲、個人情報が含まれた場合のマスキング方針が具体的に示されている状態です。個人情報保護委員会は、生成AIサービスに個人情報を含むプロンプトを入力する場合、その入力が利用目的の達成に必要な範囲内であることを確認する必要があると注意喚起しています（生成AIサービスの利用に関する注意喚起等について、2023年6月2日）。監視のためのログ保存も、同じ考え方で範囲を絞る必要があります。

曖昧だったときの追い質問: 「必要な範囲で保存します」という回答の場合は、二者択一の形で確認します。「入力の全文を保存しますか、それともメタデータだけですか」「保存先は自社テナント内ですか、ベンダー側の環境ですか」。ここが曖昧なまま稼働すると、社内の情報管理規程との不整合が後から発覚します。

なお、監視の精度と情報保護はトレードオフの関係にあります。入出力を保存しなければ品質評価もドリフト検知もできません。どこまで保存するかを決めるのは自社の判断であり、ベンダーに丸投げできない論点です。

⑤AI固有攻撃の監視有無と検知時の手順

聞くこと: 「プロンプトインジェクションや機密情報の引き出しを狙う入力は、監視の対象に含まれますか。検知した場合、遮断しますか、記録だけして処理を続けますか」

合格ラインの回答: 入力検査の仕組みの有無、検知したイベントの記録方法、検知時の動作（遮断か記録か）、そして遮断する場合の判断主体が示されている状態です。加えて、この監視が開発ベンダーの範囲なのか、セキュリティ監視サービス側の範囲なのかが明確になっていることが重要です。両者が相手の仕事だと思っている典型的な項目です。

曖昧だったときの追い質問: 「一般的なセキュリティ対策は実施しています」という回答は、この類型に答えていません。「AIへの入力文そのものを検査する仕組みはありますか」と具体化してください。含まれていない場合は、追加で実装するのか、そのリスクを受け入れるのかを発注者として決める必要があります。

⑥推論コストの監視と上限設定

聞くこと: 「トークン消費量や API 利用料は誰が監視しますか。上限を設定できますか。想定を超えたとき、どのタイミングで誰に通知されますか」

合格ラインの回答: 消費量の可視化手段（ダッシュボードか定期レポートか）、確認の頻度、上限やアラート閾値の設定、超過時の通知先が決まっている状態です。理想的には、月次の請求が届く前に日次や週次で気づける仕組みになっていることです。OWASP の一覧でも無制限な消費は独立したリスク項目として挙げられており、コスト管理はセキュリティ設計の一部として扱われています。

曖昧だったときの追い質問: 「利用量に応じたご請求になります」という回答は、監視の話に答えていません。「請求書が届く前に消費量の急増に気づく方法はありますか」「上限に達したときサービスを止めますか、止めずに超過分を請求しますか」と聞いて、動作を確定させてください。

⑦責任分界点と報告フォーマット

聞くこと: 「監視・検知・一次対応・復旧のそれぞれについて、どこまでが御社の責任で、どこからが自社の責任ですか。月次の報告には何が載りますか」

合格ラインの回答: 4つのフェーズ（監視・検知・一次対応・復旧）が表になっており、各フェーズの担当が明記されている状態です。報告についても、含まれる内容（検知件数・対応内容・傾向分析・改善提案の有無）と頻度が決まっていることが望ましいです。報告フォーマットのサンプルを事前に見せてもらえれば、実際に何が分かるのかを判断できます。

曖昧だったときの追い質問: 「協力して対応します」という回答は責任分界点を定義していません。「アラートが出た直後、最初に手を動かすのはどちらですか」という一点に絞って聞くと、分界点が見えます。そこから遡って、各フェーズの担当を埋めていってください。

見積書・契約書で監視範囲を読み解くポイント

ここまでの確認項目で聞き出した内容は、書面に落とさなければ意味がありません。口頭の説明は担当者が変わると引き継がれず、「そんな話は聞いていない」という状態に戻ってしまいます。

「運用保守費」を3段階に分解する

見積書に「運用保守費」という一行だけが計上されている場合、その中身は少なくとも3段階に分解できます。

多くの見積書は「監視のみ」または「監視＋一次対応の一部」で構成されており、実際の修正作業は別途見積になります。この構成そのものが問題なのではなく、どこまでが月額に含まれ、どこから追加費用になるのかが書面で読み取れないことが問題です。

確認の手順は次のとおりです。まず「運用保守費」の内訳を工数の根拠つきで出してもらいます。次に、内訳の各項目が上表のどの段階に当たるかを確認します。最後に、含まれていない段階について、発生した場合の費用の算定方法（時間単価と想定工数）を明示してもらいます。

保守契約における監視の位置づけをより一般的に整理したい場合は、オブザーバビリティとは？監視との違いと保守契約への組み込み方で契約への組み込み方を扱っています。本記事ではAI固有の論点に絞っているため、契約の一般的な考え方はそちらを参照してください。

SLA・SLOの対象を確認する（稼働率かAIの出力品質か）

AI監視のSLOを検討するときに最初に確認すべきなのは、その指標が何を測っているのかです。提案書に「稼働率99.9%」と書かれていても、それはシステムが応答を返すかどうかの指標であり、返ってきた回答の内容が正しいかどうかは対象外です。

つまり、AIが毎回もっともらしい誤答を返している状態でも、稼働率のSLAは満たされます。発注者が期待している「ちゃんと動いている」と、SLAが保証している「動いている」が一致していないケースです。

確認すべきは次の2点です。第一に、SLA・SLOの対象が稼働率だけなのか、応答時間やエラー率も含むのか。第二に、AIの出力品質に関する目標値が設定されているか、されていない場合はどう扱うのか。出力品質を契約上の保証対象にするのは現実的に難しい場合が多いため、保証ではなく「月次でサンプル評価を実施し報告する」という運用上の約束として書面化する現実的な落とし方もあります。

なお、実際に障害が起きた後の対応フローやSLAの運用については、AIシステムの本番障害対応マニュアル｜発注者が知るべきSLAと初動5ステップで扱っています。本記事は発注時点、つまり障害が起きる前の確認に焦点を置いているため、稼働後の運用はそちらと合わせて確認してください。

準委任と請負で変わる保証範囲、書面に落とす5項目

契約形態によって、結果に対する考え方が変わります。

• 請負契約: 成果物の完成に対して責任を負う形態です。納品時点の要件充足が判断基準になるため、稼働後の精度劣化は原則として別の話になります。監視や改善を期待する場合は、保守契約として別途定める必要があります。
• 準委任契約: 業務の遂行に対して責任を負う形態です。監視業務そのものを委託する形に向いていますが、成果（精度が維持されること）は保証対象になりません。何をどの頻度で実施するかを具体的に定めることが実効性を左右します。

どちらの形態でも、監視に関して書面へ落としておきたい項目は共通です。

1. 監視対象一覧: 監視する指標の名称と定義（先ほどの確認項目①の回答をそのまま転記する）
2. 通知先と通知手段: 時間帯別の通知先・手段・連絡までの目安時間
3. 一次対応者と承認権限者: 各フェーズの担当と、業務影響のある措置を承認する人
4. エスカレーション経路: 一次対応で解決しない場合の連絡先と、判断が必要な事項
5. 報告の内容と頻度: 月次レポートに含まれる項目と提出時期

この5項目を別紙として契約書に添付する形にしておくと、担当者の交代があっても範囲が維持されます。分量としては1〜2ページに収まるもので、作成の負担は大きくありません。

監視は内製するか外部に委託するか（体制の切り分け）

確認項目が固まったら、次は実行体制の判断です。ここでの問いは「外注か内製か」ではなく、どの作業をどちらが持つかです。

外部に任せられる範囲と自社に残る範囲

セキュリティ監視の外注を含めて整理すると、作業は次のように分かれます。

外部に任せやすい作業は、判断の基準が技術的に定まっているものです。一方、自社に残る作業は、業務の文脈がないと判断できないものです。「この機能を止めたら誰の業務が止まるのか」は、外部の監視事業者には分かりません。

先ほど触れた Human-in-the-loop の考え方は、ここで具体的な形になります。AI SOC を契約しても自社に残る作業がゼロにはならない、というのが実務上の結論です。

専任がいない組織での現実的な配分

セキュリティ専任もAI専任もいない情報システム部門では、次の配分が現実的です。

一次切り分けまでを外部に、業務影響の判断を自社に。 夜間・休日も含めた監視と一次切り分けは外部に任せ、自社側は「業務に影響があるか」「止めてよいか」の判断に専念します。この配分であれば、自社側に必要なのは技術的な分析力ではなく、業務への影響を判断する権限と社内調整の力です。担当者2〜3名の部門でも回せる形になります。

ただし、これを成立させるために社内側で最低限決めておく必要があるものが2つあります。窓口と承認権限者です。

窓口は、外部からの連絡を受ける人です。24時間体制の監視を契約しても、夜間に連絡を受ける人が決まっていなければ意味がありません。全員が電話番をする必要はなく、「夜間は翌営業日の対応とする。ただし影響度が最高のものは指定の連絡先に電話する」といった取り決めで足ります。重要なのは、その取り決めを外部と共有しておくことです。

承認権限者は、サービス停止などの措置を承認できる人です。この人が不在のときに誰が代行するのかも決めておいてください。承認待ちで対応が止まる事態は、監視の空白地帯と同じくらい実害があります。

PoC段階と本番稼働段階で監視要件を段階設計する

監視の要求水準は、システムの段階によって変わります。PoC段階で本番並みの監視を要求すると、コストが見合わずPoC自体が進まなくなります。

段階設計の利点は2つあります。一つは、初期のコストを抑えられることです。もう一つは、PoCの期間中に「どの指標を見るべきか」が実データで分かることです。稼働前に完璧な監視要件を書き上げようとするより、PoC段階で指標の候補を試し、本番契約時に確定させる方が精度の高い要件になります。

契約上は、PoCの契約と本番の保守契約を分け、本番契約時に監視要件の別紙を更新する形にしておくと柔軟に対応できます。この段階設計をベンダーに提案する際は、「PoC終了時に監視要件をすり合わせる打ち合わせを設定したい」と伝えると、話が具体的になります。

まとめ：AIシステムを発注する前に決めておく3点

AI SOC は、セキュリティ監視の運用を AI で効率化する体制です。一方、自社が発注するAIシステムの異常監視は、AI自身の精度・出力品質・コストを見る取り組みです。この2つを分けて考えると、提案書と見積書の間に生まれていた空白地帯が見えるようになります。

次のベンダー打ち合わせまでに、次の3点を決めておいてください。これは記事の要約ではなく、発注者として答えを出す必要がある宿題です。

1. 2つの監視のどちらを、誰に、どこまで頼むのかの線引き。 セキュリティ監視（攻撃の検知）と、AIシステムの異常監視（品質とコスト）を、それぞれどの契約に含めるかを決めます。両方を1社に任せるのか、分けるのか。分ける場合、境界で漏れる作業がないかを本記事の確認項目で照らし合わせてください。

2. 5類型のうち、自社業務にとって致命的な異常はどれか。 精度劣化・出力品質の異常・AI固有の攻撃・コストの急増・外部API側の変更のうち、自社の業務で最も困るものから優先順位をつけます。すべてを同じ水準で監視すると、コストが見合いません。社内の問い合わせ対応AIなら出力品質、顧客向けの機能なら AI 固有の攻撃、といった判断です。

3. 異常を検知した後の一次対応者と承認権限者を社内の誰にするか。 業務影響の大きい措置は、外部に委託していても最終的に自社の誰かが承認します。その人を決め、不在時の代行者を決め、時間帯ごとの連絡ルールを決めてください。ここが空席のままでは、どれだけ高度な監視を契約しても対応が止まります。

この3点に自分の言葉で答えられる状態になれば、「その監視は今回作るAIも見てくれるのか」という問いにも、根拠をもって答えられるようになります。

発注時の確認項目をより広く押さえたい方には、保守・運用の引き継ぎで確認すべき項目を整理した失敗しないためのシステム保守の引継ぎチェックリストをご用意しています。本記事の監視要件と合わせてご活用いただけます。

AIシステムの監視要件をどう定義すべきか、ベンダーの提案をどう評価すべきかでお悩みの場合は、お問い合わせフォームからご相談ください。要件の整理段階からのご相談も承っています。

—Free Download / 資料ダウンロード

システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集

この資料でわかること

システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。

こんな方におすすめです

• 初めてシステム開発を外注する担当者
• 過去の発注で失敗を経験した方
• ベンダー選定の基準が分からない方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。

ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。