警報をAIが一次判定する自前運用の監視OSS「AiSOC」の仕組みと導入前の注意点

「警報が多すぎて、担当者が一件ずつ見切れない。AIに一次の切り分けを任せられないか」「でも、AIが勝手に端末を隔離したり利用者を止めたりしたら、誰が責任を取るのか」——社内のセキュリティ監視を少人数で回している情報システム部門から、AIの活用を考え始めた段階でよく聞かれる二つの声です。どちらも、AIの精度が上がれば片づく問題に見えます。しかし本当の論点は精度ではありません。AIにどこまで自動で動かせ、どこから先は人が承認するのかを、先に決めて仕組みに埋め込めるかが問題の芯です。この記事では、警報の統合からAIによる調査、判断の記録、人が承認する対応までを自社で動かすOSS「AiSOC」を取り上げ、その仕組みと、2026年9月から10月にかけて公開された16件のセキュリティ勧告から見える導入前の注意点を、一次情報に基づいて整理します。導入や設定の手順は扱いません。

AiSOCとは何か。2026年10月時点で確かめられる事実

AiSOCは、GitHubで公開されているOSSです。リポジトリの説明では、オープンソースのAIセキュリティ監視センターと位置づけられ、警報の統合、AIエージェントによる一次の切り分け、MITRE ATT&CK（攻撃者の手口を体系的にまとめた枠組み）に沿った調査、そしてエージェントの一歩ごとの判断を後から再生できる記録を備えるとされます。自社のサーバーで動かす前提で、外部のAIサービスの鍵がなくても動き、AIの道具をつなぐ取り決めであるMCPの窓口も同梱している、と説明されています。

配布の形も確かめておきます。ライセンスはMITで、商用でも使える一般的な条件です。リポジトリの作成は2026年5月2日、2026年10月16日時点でスターは約2,400、フォーク（派生）は271、最終更新は10月14日でした。リリースの記録では、10月1日の15.0.0から10月12日の19.0.0まで、12日間で大きな版番号が五つ進んでいます。開発がきわめて速く、仕様の変わり方も大きいプロジェクトだと読み取れます。

公開しているのは個人のアカウントで、作成は2016年5月です。保守担当者の一覧に載っている現役の保守担当は一人で、この人物が全体の責任者を兼ねています。READMEによると、開発の費用はセキュリティ企業のCybleが負担しており、同社だけが使える機能や外部への利用情報の送信はない、とされています。日本語での紹介記事は、2026年10月16日の検索では見つかりませんでした。

なぜ今、AIを使った監視センターのOSSが注目されるのか

企業のセキュリティ監視は、ログの集約、警報の確認、調査、対応という流れで回ります。このうち最も人手を食うのが、届いた警報が本物の攻撃か、ただの誤検知かを見分ける一次の切り分けです。警報の数は監視の対象を広げるほど増え、少人数の担当者では読み切れなくなります。見落としを恐れて警報を減らせば、今度は本物を取りこぼすおそれが出ます。

ここにAIを使う考え方自体は新しくありません。ただ、多くは有償の製品として提供され、AIがどんな根拠でその判定を出したのかが外から見えにくいという不満がありました。AiSOCが打ち出しているのは、AIの判断の過程をすべて記録し、自社の中で動かし、対応の前に人が承認するという三つの約束です。監視の中身を外部に出したくない企業や、AIの判定を監査で説明する必要がある企業にとって、この方向は関心を引きやすいと考えられます。

もう一つの背景は、AIエージェントそのものの使われ方の変化です。調べ物をするだけでなく、道具を呼び出して実際の操作まで行うエージェントが広がり、監視の現場でも「AIが端末を隔離する」「AIが利用者を止める」といった操作が現実の選択肢になりました。そうなると、AIの判定の正しさより、AIの操作をどこで止めるかが問われます。AiSOCは、その問いに対する一つの設計例として読むことができます。

仕組みの全体像：警報が集まってから対応の提案までの流れ

READMEによると、AiSOCの処理は次の順で進みます。まず、各種のセキュリティ製品から届いた記録を共通の形にそろえ、誰が・何を・どこで・どうしたかという要素を付けます。次に、手元に置いた検知の規則で照らし、当たったものを警報にします。関連する警報はまとめて一つの事案にし、その事案をAIエージェントが調べ、調査の理由を記録に書き込みます。最後に、必要な対応を提案し、外部の製品に何かを指示する前に、人が承認するという流れです。

規則の数についても、READMEは具体的に書いています。規則の一覧には6,991本があり、そのうち実際に動く形にできたのは2,535本とされます。動く規則と一覧の総数を必ず並べて書くのは、一覧の数だけを見て「これだけの攻撃を見つけられる」と誤解させないためだ、と説明されています。さらに、動く規則であることは、その規則が攻撃を見つけられることまでは意味しない、とも断っています。規則の数と検知の力は別物だと開発元自身が書いている点は、評価の際に押さえておきたいところです。

つなぎ込みの面では、87種類の製品とのつなぎ口が用意され、主要なクラウドの記録を読む仕組みもあるとされます。新しい脅威の情報が届くと、すでに集めた過去の記録をさかのぼって調べ直す機能もあります。一方でREADMEは、つないでいない記録は見えない、ログの長期保管や法令対応の検索の代わりにはならない、とも書いています。今あるログの集約・分析基盤を置き換える道具ではなく、その上で調査と対応を助ける層だと捉えるのが妥当です。

AIエージェントによる一次切り分けと、攻撃手法の体系に沿った調査

AIエージェントが何をし、何をしないのかは、READMEに箇条書きで示されています。エージェントは、警報そのもの、関連する警報、関係する利用者や端末の情報、同じ種類の警報への過去の判定を読みます。そのうえで、あらかじめ型の決まった道具（記録の検索、関係の図のたどり、情報の補強など）を呼び出します。AIは道具を選んで引数を渡すだけで、データベースへの問い合わせ文そのものは書かないとされ、AIに自由な命令を書かせない設計になっています。

説明文書では、調査は複数の役割のエージェントで分担されるとされます。全体を指揮する役、偵察の役、痕跡を調べる役、対応を考える役、報告を書く役で、いずれもMITRE ATT&CKの手口の一覧を参照しながら動きます。ただし文書は、この一覧は参照用の索引で、調査で学んだことをエージェントが覚えておく仕組みではないと断っています。また、攻撃手法ごとの対応状況を示す表についても、規則に付けた印の数を数えたもので、検知の力を示すものではないと明記しています。

AIの中身にも注意が必要です。READMEによると、初期の構成では約2ギガバイトの小さなモデルを手元のサーバーで動かし、外部へは指示文を送りません。開発元の測定では、50件の警報のうち使える答えを返したのは、出力の形を固定する前で44件、固定した後で50件だったとされます。そのうえでREADMEは、このモデルは最先端のものではなく、外部の有償のAIサービスではまだ試していないとも書いています。判定の質は、どのモデルを使うかと、つないだ記録の量で大きく変わると考えるべきです。

判断の記録を残し、根拠を確かめる仕組み

AiSOCの特徴として最も強調されているのが、調査の記録です。READMEによると、エージェントに渡した指示文、呼び出した道具、引用した証拠、出した判定、使った費用の目安までが調査の台帳に書き込まれ、署名付きの証拠の束として書き出せるとされます。後から「AIはなぜこの警報を閉じたのか」を一つずつたどれる、という狙いです。

記録には、根拠の確認も組み合わされています。READMEは、証拠に含まれていない攻撃の痕跡を根拠に挙げた判定は、自動で閉じずに人の確認に回す、としています。また、AIとの対話の機能では、確かめられる主張には台帳の該当箇所を引用し、引用できないものは「引用なし」と明示するとされます。AIに根拠を書かせ、根拠のない判定を人の確認に回すという考え方は、AIを監視の現場で使ううえでの基本線と言えます。

一方で、裏返しの注意もあります。指示文や証拠まで残るということは、記録そのものに利用者名、端末名、通信先、実行された命令などの機微な情報が含まれるということです。READMEは、生の記録や秘密情報らしき値はAIへ送る前に拒むとしていますが、台帳と証拠の束の保管場所、見られる人、残す期間は、別に決めておく必要があります。後で見る勧告の一つは、この記録の正しさを支える仕組みに関わるものでした。

自動で動く範囲を五段階で決める仕組み

この題材の中心になるのが、AIに自動で動かす範囲の線引きです。説明文書によると、AiSOCは自動化の度合いをL0からL4までの五段階で定め、利用する組織（テナント）ごとに設定します。あわせて、対応の操作一つひとつに影響の大きさを五段階で割り当て、設定した段階で許された大きさまでだけを自動で実行し、それ以外は承認待ちの列に回します。新しく使い始めた組織の初期値は、何も自動で実行しないL0とされています。

段階ごとの中身は次のとおりです。L0は観察で、AIは提案だけを行います。L1は通知で、連絡や起票など情報を動かすだけの操作を自動にします。L2は封じ込めで、ファイルの隔離や不審な痕跡の遮断一覧への追加など、元に戻せる小さな操作までを自動にします。L3は修復で、通信先の遮断やプロセスの停止、パスワードの再設定まで広がります。L4は、端末の隔離や利用者の停止など影響の大きい操作を、あらかじめ人が許可した操作と対象の組み合わせに限って自動にします。最も影響の大きい区分の操作は、どの段階でも承認待ちです。

さらに、段階が許していても、操作ごとの取り決めで承認を必須にできる仕組みがあります。たとえば証拠の取得は、何をどこまで集めるかに限りがなく、対象を誤ると取り返せないため、段階に関係なく人の承認が要るとされます。承認する人は必要な権限を持ち、しかも依頼した本人であってはならない、ともREADMEは書いています。説明文書は、本番で使う組織の多くはL2で運用しているとし、それより高い自動化をうたう宣伝は、狭い実演か、提案を操作と数えているかのどちらかだ、とまで述べています。

ログに紛れ込む命令への備えと、その限界

監視のAIには、ふつうの業務のAIにはない難しさがあります。AIが読む材料が、攻撃者の手の届くところから来ることです。脅威の分析の文書は、命令の文字列、通信先の名前、ファイル名、メールの本文などのログの項目を、攻撃者が中身を左右できる入力として扱っています。攻撃者がログに文章を紛れ込ませ、AIに「これは誤検知だ」と判定させようとする手口、いわゆるプロンプトインジェクション（外部の文章に紛れ込ませた命令でAIを操る攻撃）が想定されているわけです。

文書によると、AiSOCはこれに対し、証拠を毎回変わる区切りで囲んでデータとして扱わせる、紛れ込んだ命令の型を見張る、AIの出力を決まった形に当てはめて確かめる、といった対策を重ねています。見張りが重大な兆候を見つけたときは、その事案の自動化の段階をL0、つまり人の確認に落とすとされます。AIが対応の道具を呼ぶときは、指定した対象が事案の証拠に実際に含まれているかを実行前に確かめる、とも書かれています。

それでも文書は、残る危険として「指示文は確かな信頼の境界ではない」とはっきり認めています。対策は乗っ取りの手間を増やし、目立たせるものであって、新しい手口がAIの文章に影響を与える余地は残る、という立場です。実際、後で触れる勧告の一つは、この見張りが一部の書き方の文章を見逃し、警報の自動での打ち切りを止められなかったというものでした。AIへの対策は、破られる前提で人の確認と組み合わせる必要があります。

従来の手段との違い

AiSOCの位置づけを、企業がすでに使っている手段と比べてみます。下の表は、一次情報で確かめた説明に基づく一般的な目安で、製品ごとの優劣を示すものではありません。

手段	主な役割	AIの判定の根拠	対応の実行
ログの集約・分析基盤	記録の保管と検索、規則による検知	AIを使わないか、製品による	多くは人が行う
対応の自動化の製品	決めた手順での対応の自動化	手順に沿って動く	手順に従って自動
有償のAI監視サービス	AIによる一次の切り分け	外から見えにくいことがある	提供元の設計による
AiSOC	統合・切り分け・調査・記録・対応の提案	台帳に指示文と証拠を記録	初期は人の承認。段階に応じて一部を自動

表のとおり、AiSOCの強みは、調査から対応までを一つにまとめつつ、AIの判断の過程を自社の手元に残せる点にあります。とはいえ、ログの長期保管や既存の監視製品を置き換えるものではないと開発元自身が書いています。既存の仕組みの上に重ねる前提で考えるのが現実的です。

また、記事で挙げた数値の多くは開発元が自ら測ったものです。開発元の監査の文書には、以前の手順書どおりに入れると実際の処理は動かず、用意された見本の事案が並ぶだけだった時期があった、という率直な記載もあります。現在は改められたとされますが、画面に並ぶものが本物の処理の結果かどうかを、自社の検証で確かめる姿勢が欠かせません。

安全性の評価：注意付きとした根拠

このラインでは、紹介するOSSを、公開されている事実だけを基に精査しています。OSSをダウンロードしたり動かしたりはしていません。AiSOCの判定は「注意付き」です。最大の理由は、2026年9月29日から10月7日にかけて、重大3件・高11件・中2件、計16件のセキュリティ勧告が公開されていることです。勧告はいずれも修正版が示されていますが、件数が多く、内容も認証や権限の根幹に関わるものが目立ちます。

二つ目の理由は、配布の形です。リポジトリには、取り込んだ時点で自動的に動く処理が設定されており、導入用の手順ファイルもあります。READMEによると、初回の起動では約2ギガバイトのモデルを取得し、十五個の秘密の値と管理者の合言葉を自動で作ります。これら自体は珍しくありませんが、導入の時点で多くの処理が自動で走るため、検証用の環境で中身を確かめてから扱うべき種類のソフトウェアです。

前向きな事実もあります。公開元は2016年作成の実名のアカウントで、保守担当者の一覧と運営の方針、セキュリティの方針の文書がそろっています。勧告は非公開の窓口で受け付けられ、修正版とともに公開されています。なお、精査で大きな問題が見つからない項目があったとしても、それは安全の保証ではありません。このラインの精査は公開情報の範囲に限られ、コードの中身を検証したものではないからです。導入するかどうかは、自社の確認の手順に沿って判断してください。

公開された16件の勧告の中身と修正版

勧告の中身を、悪用の手順に踏み込まない範囲で、修正版ごとにまとめます。勧告のページで影響を受ける版と修正版を確かめた結果で、2026年10月16日時点で共通番号（CVE）はどれにも付いていません。

修正版	件数と重大度	勧告の概要
12.0.0	8件（重大2・高5・中1）	固定の認証情報、認証のない重要な窓口と危ない初期設定、基本ソフトへの命令の注入、権限の確かめ漏れ、閲覧だけの役割で事案を書き換えられる問題、別の組織の調査結果を読める問題、紛れ込んだ命令の見張りの見逃し
12.1.0	1件（高）	対応用の部品で、特定の製品のファイアウォールに送る要求に細工を混ぜられ、遮断の規則を操作されうる問題
12.3.1	2件（重大1・高1）	端末への問い合わせの許可一覧の組み立てでのSQL注入。認証済みの誰でも自動対応の段階の設定を書き換えられる問題
14.0.0	1件（高）	組織の管理者が、全体の管理者の権限を持つ利用者を作れる問題
16.0.1	1件（高）	権限の付与の確かめを、実際の権限ではなく固定の役割で行っていた問題
17.0.0	2件（高1・中1）	外部の認証基盤から届く未確認のメールアドレスで利用者を結び付けた問題。一部の画面の更新で、取り消したはずの利用者の接続を止めていなかった問題
17.1.0	1件（高）	監査記録の鎖に、検証していない認証の札の中身を書き込んでいた問題

重大の3件は、基本ソフトへの命令の注入、認証のない重要な窓口と危ない初期設定の組み合わせ、管理下の端末からのデータの持ち出しにつながるSQL注入です。12.0.0で直った8件は、いずれも11.2.0以前の版を対象としています。表のとおり、最も新しい修正は17.1.0で、2026年10月12日公開の19.0.0が最新です。使うなら少なくとも17.1.0以降、実際には最新版に限ることが条件になります。

勧告のうち11件は9月29日に、残りは9月30日、10月4日、10月5日、10月7日に公開されました。各修正版でどこまで直ったかのコードの検証は、本記事では行っていません。勧告に書かれているのは弱点とそのおそれであり、実際に攻撃に使われた例があるかどうかは、2026年10月16日時点で一次情報からは確認できませんでした。

勧告から読み取れる注意点：権限の線引きと運営体制

16件を並べると、偏りがはっきり見えます。大半が、誰が何をしてよいかを確かめる仕組みの不備です。閲覧だけの役割で事案を書き換えられる、組織の管理者が全体の管理者を作れる、認証済みなら誰でも自動対応の段階を変えられる、別の組織の調査結果を読める。いずれも、AIの賢さとは関係のない、権限管理の基本に関わる問題です。

特に重いのは、自動対応の段階の設定を、本来その権限のない利用者が書き換えられたという勧告です。前の章で見たとおり、AiSOCの安全の設計は、L0からL4の段階で「AIに何を自動でさせるか」を人が決めることに支えられています。その設定が権限のない人に変えられるなら、人が引いた線が、人の知らないうちに引き直されるおそれがあります。同じく、紛れ込んだ命令の見張りの見逃しと、監査記録の鎖に未検証の情報を書き込んでいた問題も、AIの線引きと記録という、このOSSの中心の約束に関わるものでした。

運営体制にも目を向けておきます。セキュリティの方針の文書では、最新の版は公開から90日間、重大な修正を受け、それより古い版は対応が努力目標にとどまるとされます。開発が速く、大きな版が数日おきに進むため、最新版を追い続けられる体制がないと、修正の恩恵を受けられないことになります。また同じ文書には、以前は非公開の報告窓口が閉じていて、重大な弱点を見つけた報告者が届け出る経路がなかったことも記されています。今は改められていますが、現役の保守担当が一人である点とあわせ、運営の厚みは導入前に確かめたい項目です。

悪用されうるリスク：監視の中枢が狙われると何が起きるか

AiSOCのような監視の中枢は、守りの道具であると同時に、攻撃者にとって価値の高い標的です。多くの製品とつながり、その認証情報を預かり、端末の隔離や利用者の停止を指示できるからです。ここからは、一次情報にある事実を踏まえた推測であることを断ったうえで、考えられるリスクを挙げます。

一つ目は、監視の目をふさがれるリスクです。警報の自動での打ち切りをAIに誤らせることができれば、攻撃の痕跡が人の目に届く前に閉じられる可能性があります。勧告にあった見張りの見逃しは、この方向の危険を示しています。二つ目は、対応の機能を逆手に取られるリスクです。自動化の段階を引き上げられたり、遮断の規則を書き換えられたりすれば、守りのための操作が、業務を止める操作に変わるおそれがあります。

三つ目は、集めた記録そのものの漏えいです。別の組織の調査結果を読める弱点や、端末からのデータの持ち出しにつながる弱点が報告されたことは、監視の中枢に集まる情報の重さを物語っています。なお説明文書によると、AiSOCには攻撃を模した演習の機能も含まれるとされます。こうした機能を本番の監視と同じ環境に置く場合、誰がいつ使ってよいかを社内の決まりで縛る必要がある、と考えられます。

導入を検討するときに確かめること

AiSOCを検討するとき、機能の多さより先に確かめたい点があります。下の手順は、OSSを動かす前の段階で、資料と社内の取り決めで確かめられることに絞っています。

この手順の要は、道具を入れる前に、人が決めることを決めておくことです。監視の仕組みは、いったん動き始めると止めにくくなります。自動化の段階や承認の決まりを後から詰めようとすると、すでに現場の運用が道具の初期値に合わせて固まってしまい、見直しが難しくなります。

企業が取るべき対策

AiSOCを導入するかどうかにかかわらず、AIを使った監視を検討する企業が決めておきたい対策を挙げます。一つ目は、監視の道具そのものを、守る対象の一覧に入れることです。監視の中枢は多くの製品の認証情報を持つため、ふつうの業務システム以上に厳しく、更新、権限、通信の範囲を管理します。

二つ目は、自動化の段階の設定と、権限の設定の変更を見張ることです。誰がいつ段階を変えたかが記録に残り、変更のたびに責任者へ知らせが届く運用にしておけば、権限の不備があっても早く気づけます。三つ目は、AIが自動で閉じた警報を、一定の割合で人が抜き取って確かめることです。AIの判定を誤らせる手口は、閉じられた警報の中にしか痕跡を残しません。

四つ目は、記録の扱いです。調査の台帳と証拠の束は、個人情報や秘密情報を含みうるものとして、保管場所、見られる人、残す期間を決めます。五つ目は調達の段階での確認です。保守の体制、勧告への対応の速さ、古い版の扱いを、導入前に確かめておきます。これらは特定のOSSに限らず、AIに操作の権限を渡す仕組み全般に通じる対策です。

AIが自動で対応する範囲と、人が承認する範囲の線引き

AiSOCの設計は、AIを万能の判定者として扱っていません。AIは調べて提案し、根拠を台帳に書き、根拠のない判定は人の確認に回されます。この考え方を自社の運用に置き換えると、AIに判断させない範囲を先に決め、AIには根拠を書かせ、人が確認する範囲を文書にしておくことになります。段階の仕組みは、その決めごとを守らせる道具にすぎません。

線引きの目安として、説明文書の考え方は参考になります。情報を動かすだけの操作、元に戻せる小さな操作、業務に影響する操作、取り返しのつかない操作と、影響の大きさで分け、上に行くほど人の承認を厚くする。そのうえで、利用者の停止や端末の隔離のような操作は、自動にするとしても対象と期限を絞った許可に限ります。一律に「自動化する・しない」を決めるのではなく、操作の種類ごとに信頼を積み上げるという発想です。やってはいけない向き合い方も挙げておきます。

• 使い始めからAIに広い自動対応を許し、初期値のL0で様子を見る期間を設けない
• AIが自動で閉じた警報を誰も見返さず、AIの判定の誤りに気づく機会をなくす
• 自動化の段階や権限の設定を誰が変えられるかを決めず、変更の記録も見ない
• AIの判定を、台帳の根拠を確かめないまま最終判断として報告に使う
• 承認する人と依頼する人を同じにして、承認が形だけになる
• 勧告が出ても古い版を使い続け、修正の対象から外れたまま運用する

裏を返せば、人が決める範囲ははっきりしています。どの操作を自動にするか、誰が承認するか、設定の変更を誰が確かめるか、記録をどう守るか。この四つはAIにも道具にも委ねず、人が決めます。AIに任せてよいのは、人が決めた線の内側で、警報を速く広く調べ、根拠を添えて提案する部分です。

よくある質問：AiSOCを入れれば監視の人手は要らなくなるのか

最も多いと思われる問いに答えておきます。答えは「人手は要らなくならない」です。AiSOCの初期値は人の承認を前提にしており、開発元自身が、初期の構成は自律的に動くものではないと書いています。AIが一次の切り分けを手伝うことで、担当者が読む警報の順番を整えたり、調査の下ごしらえを速めたりする効果は期待できますが、最後に判断し、責任を持つのは人です。

もう一つ、「これだけ勧告が出たOSSを使ってよいのか」という問いもありそうです。弱点が見つかること自体は多くのソフトウェアで起きます。見るべきは、報告が受け付けられ、修正版が出て、勧告として公開されたかという対応の流れで、AiSOCではその流れが確認できます。そのうえで、短い期間に16件が集中したこと、開発の速さ、保守担当の少なさを踏まえ、最新版を保てる体制と、検証を回せる人手が自社にあるかどうかが、使ってよいかの分かれ目になります。

• AiSOCの機能・版・ライセンスの情報は、GitHubのリポジトリ、README、説明文書、リリースの記録を2026年10月16日に確かめた範囲に基づきます。更新が非常に速いため、内容は変わる可能性があります
• セキュリティ勧告の内容と修正版は、2026年10月16日に勧告のページで確かめた記載に基づきます。修正版でどこまで直ったかのコードの検証や、実際の悪用の有無の確認は行っていません
• 判定の精度や規則の数などの数値は、開発元が自ら測ったものです。第三者による検証は確認できていません
• この記事は防御と評価の目線で書いています。導入・設定・起動の手順や、勧告の再現の方法は扱いません

まとめ

AiSOCは、警報の統合、AIエージェントによる一次の切り分け、攻撃手法の体系に沿った調査、判断の記録、人が承認する対応までを、自社の環境で動かすOSSです。AIの判断の過程を台帳に残し、根拠のない判定を人の確認に回し、自動化の範囲を五段階で決められる設計は、AIを監視に使ううえでの筋の良い考え方を示しています。一方で、道具を入れるだけでAIが安全に監視してくれるわけではない点を押さえておく必要があります。

そして2026年9月から10月に公開された16件の勧告は、権限の確かめ漏れが中心で、その中には自動化の段階の設定を書き換えられる弱点もありました。使うなら少なくとも17.1.0以降、実際には最新版に限ります。AIに判断させない範囲と人が承認する範囲を先に決め、AIには根拠を書かせ、その線を守る設定の変更まで人が見張る。この順番を守ったうえで道具を使うことが、AIを監視の現場に入れる企業の守りの基本です。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。