Anecdotesで自社用に組むか既製か｜GRCエージェントの線引き

大手企業のGRC（ガバナンス・リスク・コンプライアンス）の担当チームは、仕事の時間の7割以上を、証跡の収集や評価の取りまとめといった作業に使っている——2026年8月、GRCの基盤を提供する Anecdotes が発表の中で引いた数字です。「規程と統制の点検をAIエージェントに回したいが、自社用に組むほどの体制はない」「証跡を Claude や ChatGPT に渡して監査の質問に答えさせてよいのか、誰も判断できない」という声も、情報システム部門や内部監査の周辺で聞かれます。問いの立て方を少し変える必要があります。選ぶのはエージェントの賢さではなく、エージェントに何を読ませ、何を書かせ、どの判断を人に残すかです。この記事では、Anecdotes の既製の機能で足りる場合と、自社用のエージェントを組む場合を比べ、外のAIに証跡を渡す範囲と、監査の証跡として使える条件を整理します。

Anecdotes は何をする製品か：証跡のデータ基盤にエージェントを載せる

Anecdotes は、イスラエルのテルアビブと米国カリフォルニア州パロアルトを拠点に、大手企業向けのGRCの製品を作る会社です。2025年4月にはシリーズBの追加調達を発表し、シリーズBの合計は5,500万ドル、累計の調達額は8,500万ドルになったと報じられました。製品の土台は、社内のクラウド、ID管理、開発基盤などから証跡を集めて整理するデータの層です。公式サイトは230以上の連携先と、1,000以上の証跡の取得元を挙げています。

この土台の上に、2026年1月14日の発表で三つの層が示されました。社内のシステムのデータを集めて統合する層、専門のAIエージェントが作業を実行する層、ガバナンス・リスク・コンプライアンスの各業務のアプリの層です。エージェントの層には、対話で分析や作業を進める ChatGRC と、プログラムを書かずに自社用のエージェントを組む Agent Studio があり、さらにMCPで社内のGRCのデータを Claude や ChatGPT などの外のAIアシスタントにつなげると説明しています。

特徴は、エージェントより先に証跡のデータがあることです。公式ブログは、完全で正確で、更新され続けるデータがなければAIの結果は信頼できない、という立場を繰り返し示しています。日本語で読める紹介はほとんどなく、以下は公式サイト、公式ブログ、公式の報道発表、同社の担当者が書いた記事で確かめられた範囲で書いています。

2026年の動き：1月のエージェント機能、6月の政府認証、8月の委託先評価

2025年10月16日の公式ブログで、同社はGRC向けのMCPサーバーを発表しました。AIアシスタントから自然な言葉でGRCのデータを問い合わせられるもので、監査人の質問への回答、取締役会向けの報告、未対応の課題の要約と是正の割り当てといった使い道が挙げられています。2026年1月14日には、ChatGRC、Agent Studio、データの取り込み経路を自社で組む機能、外のAIとつなぐMCPをまとめた、エージェント型のGRCの発表を出しました。

6月30日には、米国政府のクラウドの認証制度で、新しい審査方式による中程度の水準の認証を取得したと発表しています。8月12日には、委託先のリスク管理にエージェントの仕組みを広げ、取引先を社内の利用状況から見つけ、証跡を直接集め、自社の基準で採点し、決めた周期や新しい証跡で採点し直すと説明しました。重要な委託先には人の承認を必須にでき、エージェントの判断にはたどれる記録と確信度が付き、確認する人が中身を見て覆せるとしています。

• Agent Studio は、2026年6月26日に同社の担当者が書いた記事（同社の提供記事）で早期提供の段階と説明されています。一般提供の時期と契約条件は書面で確かめてください
• 「7割以上」という数字は同社の発表に含まれたもので、調査の方法は示されていません
• ここで挙げた機能の説明の多くは同社の発表で、外部の検証を経たものではありません

公式のお知らせのページに、終了や買収の告知は見当たりません。ただ、この1年で製品の範囲が大きく広がっており、契約する時点の機能を確かめることが前提になります。発表された構想と、自社の契約で今使える機能を分けて聞くのが、新しい製品を評価するときの基本です。

比べる前提：GRCのAIは「何を読み、何を書けるか」で選ぶ

GRCのAIを比べるとき、答えの賢さや対話の自然さから入ると判断を誤ります。GRCのエージェントが読むのは、ID管理のアクセス権、クラウドの設定、開発基盤の権限といった、会社の守りそのものに関わるデータです。書くのは、課題の記録、是正の割り当て、場合によっては統制の評価の結果です。読める範囲と書ける範囲が、そのまま事故の範囲になるという前提で比べます。

もう一つの前提は、GRCの判断の多くが説明責任を伴うことです。統制が有効だと判定した、リスクを受け入れると決めた、という判断は、監査や取締役会で誰が決めたかを問われます。エージェントは判断の材料を集めて整えることはできても、責任を負う主体にはなれません。比べる観点は、エージェントが材料づくりにとどまっているか、判断の記録を人の署名につなげられるかです。

認証の取得準備や、取引先向けの公開ページの作り方は別の記事で扱っています。ここでは、すでにGRCの部門を持つ大手企業が、Anecdotes のAIをどの形で使うかに絞ります。

選択肢は三つ：既製の手順、Agent Studio、MCPで外のAIから

Anecdotes でAIを使う形は、大きく三つに分けられます。一つ目は既製の手順を使う形です。ChatGRC には、統制の不足の発見と是正、規程の見直しの取りまとめ、統制の評価の自動化といった、用意済みで調整できる手順があると公式は説明しています。製品が想定した作業の型に、自社の作業を合わせる形です。

二つ目は Agent Studio で自社用のエージェントを組む形です。起動のきっかけ、平易な言葉で書いた作業の指示、実行する操作の三つを決めて組みます。公式の例には、委託先のリスク評価、複数の関係者による規程の承認、部門をまたぐ統制の導入があります。三つ目は、MCPで社内のGRCのデータを Claude や ChatGPT から使う形です。エージェントの作り込みは外のAIアシスタントの側に任せ、Anecdotes はデータの供給元になります。

三つは排他ではありません。多くの会社では、既製の手順で始め、足りない部分だけ自社用に組み、経営層向けの報告の下書きなど一部の作業でMCPを使う、という組み合わせになるはずです。問題は、どの作業をどの形に置くかで、それを決める物差しが次の比較です。

三つの形を六つの観点で比べる

比べる観点は、向く作業、読むデータ、書ける範囲、実行の記録、保守の手間、監査で示しやすいか、の六つです。公式の説明で確かめられなかった点は「要確認」としています。

観点	既製の手順	Agent Studio で組む	MCPで外のAIから
向く作業	規格どおりの点検、不足の洗い出し	自社独自の統制、承認の流れ	報告の下書き、横断の問い合わせ
読むデータ	製品が想定した範囲	組む人が選んだ連携先	接続した人の権限の範囲（要確認）
書ける範囲	製品が決めた操作	組む人が許した操作	公式ページに明示なし（要確認）
実行の記録	製品の中に残る	実行ごとに記録が残ると説明	外のAIの側と二か所に分かれる
保守の手間	小さい	指示と基準の手入れが続く	外のAIの仕様変更に左右される
監査で示しやすいか	示しやすい	記録の残し方次第	示しにくい（会話の記録の管理が要る）

特にMCPについては、公式ページが読み取りと書き込みの範囲、認証の方式、記録の取り方を詳しく書いていません。確かめられないまま比較表の欄を埋めないことも、比べるときの規律です。

この表から読み取れるのは、自由度が上がるほど、監査で示しやすさが下がり、保守の手間が増えるという関係です。GRCの部門にとっての価値は自由度ではなく、後から説明できることにあります。自由度の高い形を選ぶなら、その分だけ記録と手入れの体制を厚くする、という釣り合いで考えます。

既製の手順で足りる部門の条件

既製の手順で足りるのは、点検の対象と基準が、ISO 27001 や SOC 2 などの規格の統制とほぼ一致している部門です。規格どおりの統制なら、製品があらかじめ用意した手順と、規格との対応づけがそのまま使えます。自社で指示を書かない分、指示の誤りで判定がずれる危険も小さくなります。

もう一つの条件は、GRCの部門に、エージェントの指示や基準を手入れし続ける人がいないことです。自社用のエージェントは組んで終わりではなく、システムの変更や規格の改訂のたびに指示と基準を直す必要があります。その担当を置けないなら、既製の手順を調整して使うほうが、結果として統制の質を保てます。

既製の手順でも、調整の内容は記録に残します。どの手順の、どの閾値を、誰が、なぜ変えたかです。既製だから説明が要らない、ということにはならない点は押さえておきます。製品の更新で既製の手順の中身が変わることもあるため、更新の告知を読んで判定への影響を確かめる担当も決めておきます。

Agent Studio で自社用に組むべき場面

自社用に組む価値があるのは、規格の言葉では表せない自社独自の統制がある場合です。たとえば、特定の事業部だけに適用する取引先の基準、海外子会社ごとに違う承認の流れ、業界の規制に合わせた独自の点検項目などです。既製の手順に無理に合わせると、点検の結果を読む人が毎回頭の中で読み替えることになり、かえって誤りが増えます。

同社の担当者による記事では、ISO 27001 の多要素認証に関わる統制を例に、組み方が説明されています。新しく作られた管理者のグループに多要素認証の方針が付いていないことを、Okta や Entra などのID管理の設定から見つけ、課題を起票し、証跡を添えて統制に結び付け、是正を割り当てる、という流れです。きっかけは定期実行より、証跡が古くなったなどの出来事を起点にするほうがよいとも書いています。

組むかどうかの判断材料として、指示を手入れする担当を置けるかを最初に確かめてください。置けないなら、組む範囲を一つか二つの統制に絞って始めるのが現実的です。

組むときの権限：読むのは評価対象、書くのはGRCの記録だけ

同社の担当者の記事は、最小権限の考え方として、エージェントには評価する対象のシステムを読む権限だけを与え、書き込みは課題や是正の作業といったGRCの記録に限ることを勧めています。これは製品の制約ではなく、組む側が守る規律です。点検するエージェントが、点検される設定を書き換えられる状態は避けるべきです。

権限を広げたくなる場面はあります。たとえば、多要素認証の設定漏れを見つけたら、その場で直してほしい、という要望です。しかし、自動で直す操作は、業務の停止や新たな設定の誤りを生むおそれがあり、変更管理の手続きも飛ばしてしまいます。是正は、エージェントが起票と割り当てまでを行い、直す操作はシステムの持ち主が通常の変更手続きで行う、という分担にします。

2025年4月の調達の発表で、同社は審査を手がける企業や Google Cloud、ServiceNow との提携を強めるとしていました。社内の変更管理を ServiceNow で回している会社なら、エージェントが起票した是正を、既存の変更の手続きにそのまま流せるかを確かめておく価値があります。流せないと、是正の記録がGRCの側と変更管理の側で二重になり、どちらが正なのかが分からなくなります。

• 管理者の権限でつなぐ：組む人の権限をそのまま使うと、エージェントが読める範囲が必要以上に広がる
• 是正まで自動にする：変更管理を飛ばし、点検する側が設定を変える状態になる
• 指示の変更を記録しない：判定が変わった理由を、監査で説明できなくなる
• 誤検知を黙って閉じる：閉じた理由が残らず、本当の不備と区別できなくなる

連携先ごとに、読ませる項目を絞れるかも確かめます。ID管理の製品なら、グループと方針の設定だけで足り、個人の利用履歴までは要らない、といった具合です。読ませる項目が少ないほど、エージェントの判定の根拠も追いやすくなります。

MCPで Claude・ChatGPT に証跡を渡してよい範囲

MCPで社内のGRCのデータを Claude や ChatGPT につなぐと、統制の状態やリスクの一覧を、ふだん使うAIアシスタントから問い合わせられます。公式ブログの例には、重大と高のリスクとそれを抑える統制を要約し、90日で許容範囲に収める計画を作る、という使い方があります。便利な一方で、証跡の中身が社外のAIサービスの会話に入ることになります。

証跡には、アクセス権の一覧、クラウドの設定、監査の指摘事項といった、攻撃者にとって価値の高い情報が含まれます。渡してよい範囲は、少なくとも三つに分けて決めます。統制の達成状況やリスクの件数のような集計は渡してよい。個々の設定の中身や、未是正の弱点の詳細は渡さない。個人の情報を含む記録は渡さない。未是正の弱点の一覧は、外のAIに出さないという線は、どの会社でも最初に引いておくべきものです。

確かめることも残っています。公式のMCPのページは、読み取りだけか書き込みもできるか、認証の方式、記録の取り方を書いていません。つなぐAIアシスタントは会社として契約したものに限り、会話の保存と学習への利用の設定を管理できることを条件にします。接続した人のGRCの権限がそのまま引き継がれるかも、導入前に確認します。

使い方の線も引きます。外のAIに任せてよいのは、集計の読み解きや報告の文案づくりまでです。外のAIが作った報告の数字は、Anecdotes の画面の数字と照らし合わせてから取締役会に出します。90日の計画のような案も、期限や担当の割り当てはリスクの持ち主が決め直します。外のAIは社内の事情や優先順位を知らないまま、もっともらしい計画を作るからです。

エージェントの判定を監査の証跡として使えるか

同社の担当者の記事によると、Agent Studio では実行ごとに日時つきの記録が残ります。中身は、きっかけ、読んだ入力、比べた基準、判断とその理由、行った操作、触れた証跡です。記事は、たどれる操作は元に戻せる、と書き、モデルの賢さより記録のほうが重要だと述べています。委託先の評価の仕組みでも、判断ごとのたどれる記録と確信度が付くと公表されています。

ただし、監査で証跡として受け入れるかを決めるのは、監査人です。エージェントの記録は、いつ、何を読み、どう判定したかを示す材料にはなりますが、統制が有効であることの証明そのものにはなりません。監査人が見たいのは、元のデータが正しく取れているか、基準が承認されたものか、判定を人が確かめたか、の三点です。

そこで、記録を証跡として使うなら、指示と基準の版、承認した人、実行記録、人の確認の記録をひとまとめにして残します。指示を変えたら版を上げ、変更の前後でどの判定が変わったかを追えるようにします。記録が残ることと、記録で説明できることは別なので、年に一度は監査人に記録の形を見てもらい、足りない項目を聞いておくと安心です。

人が署名する判断：リスクの受容と統制の有効判定

同社の担当者の記事は、検知と課題の起票は人がいなくても進めてよいが、リスクを閉じる、統制を有効と判定する、といった操作は人の承認に回すべきだと書いています。委託先の評価でも、重要な委託先には人の承認を必須にできると説明されています。人に残す判断を、製品の設定として固定しておくことが要点です。

人に残す判断は、少なくとも次の四つです。リスクを受け入れる判断、統制が有効だという判定、例外を認める判断、委託先との取引を続けるかの判断です。どれも会社として責任を負う判断で、エージェントの確信度が高くても、署名は持ち主が行います。エージェントには、判断の材料を揃え、根拠を書かせ、反対の材料も並べさせます。

承認の負担が増えすぎると、中身を見ずに承認する習慣が生まれます。これを防ぐには、承認に回す件数そのものを管理します。確信度が低いもの、重要な統制や委託先に関わるもの、前回の判定から変わったものを優先して回し、それ以外はまとめて定期的に確かめる、といった分け方です。

委託先の評価のエージェントは、自己申告の質問票を標準の流れから外し、証跡を直接集めると説明されています。質問票の往復は減りますが、委託先から集めた監査報告書やデータ処理の契約書の扱いは、委託先との契約で許された範囲に限られます。集めた証跡を外のAIに渡せるかは、委託先との秘密保持の約束を確かめてから決めます。

社内AIの台帳につなぐ：AI規制と ISO 42001

GRCの部門には、もう一つの仕事が増えています。社内で使うAIそのものの管理です。2025年に成立した日本のAI推進法は、事業者に罰則つきの義務を課すものではなく、国の施策への協力を努力義務として求める内容です。一方で、総務省と経済産業省のAI事業者ガイドラインは、AIを使う事業者にリスクの把握と管理の体制づくりを求めており、欧州で事業をする会社はEUのAI法への対応も必要になります。

こうした管理の土台になるのが、社内で使うAIの台帳です。どの部門が、どのAIを、どのデータで、どの目的に使っているかを一覧にし、持ち主とリスクの評価を付けます。Anecdotes 自身は、AIの管理の国際規格である ISO 42001 の認証を公式サイトに掲げています。GRCのエージェントそのものも、この台帳に載せる対象です。読むデータ、書ける操作、持ち主、指示の版を台帳に記録しておけば、エージェントの管理が、ほかのAIの管理と同じ枠組みで回ります。

調べた範囲では、Anecdotes がAIの台帳を専用の機能として持つかどうかは、公式の説明から確かめられませんでした。台帳を別の仕組みで持つなら、エージェントの記録と台帳の項目をどうつなぐかを、導入の設計に含めておきます。欧州のAI法の対象かどうかの判定は、専門の製品や法務の判断で扱う領域で、GRCのエージェントに任せる作業ではありません。

誤検知と見落としをどう扱うか

同社の担当者の記事も、モデルが間違えることはあると認め、誤検知は起こる前提で、記録を見て指示を直すよう勧めています。GRCの点検では、誤検知と見落としのどちらが重いかを先に決めておくことが大切です。誤検知が多いと確認の手間が増え、やがて通知が読まれなくなります。見落としは、気づかないまま監査の指摘や事故につながります。

見落としを減らすには、エージェントだけに頼らないことです。規則で判定できる点検は、規則のまま残します。記事も、作業の大半は決まった手順で判定できるようにしておくべきだと書いています。AIの判断が要るのは、文書の読み取りや、複数の証跡を突き合わせる部分に限ると、誤りの起こる場所が絞れます。

指示を直すときは、直す前の判定と直した後の判定を、過去の記録で比べてから本番に入れます。ある統制の指示を直したら、別の統制の判定が変わった、ということは起こりえます。四半期ごとに、誤検知の件数、見落としが後で見つかった件数、承認に回った件数を集計し、指示の手入れの優先順位を決めます。

社内に入れてよいか：費用・止め方・やめ方

公式サイトは価格を公開しておらず、問い合わせとデモの申し込みが窓口です。費用が増える要因として考えておくのは、対象にする規格と統制の数、連携先の数、エージェントの数と実行の頻度、委託先の評価の対象数です。MCPで外のAIを使えば、そのAIアシスタントの費用も別にかかります。エージェントを増やすたびに、確認する人の時間も増えることを費用に含めて考えます。

止め方は、エージェントごと、連携先ごと、MCPの接続ごとに決めておきます。誤判定が続いたエージェントを止めたとき、その統制の点検を人の手でどう続けるかも決めておきます。止めたら点検が空白になる、という状態は避けます。

やめ方として、証跡、統制との対応づけ、課題と是正の履歴、エージェントの実行記録を、どの形式で取り出せるかを確かめます。監査の証跡は数年単位で保存が求められることがあるため、契約を終えた後も記録を示せるようにしておく必要があります。

選ぶ前に確かめる10項目

比較の結論を出す前に、次の項目を社内で確かめておきます。製品の担当者に聞く項目と、社内で決める項目が混ざっているので、聞く相手を分けて進めます。

• Agent Studio と MCP が、自社の契約で今使える状態か（早期提供か一般提供か）
• MCPが読み取りだけか、書き込みもできるか。認証の方式と記録の取り方
• 接続した人のGRCの権限が、MCP経由でもそのまま引き継がれるか
• 連携先ごとに、エージェントに読ませる項目を絞れるか
• エージェントの書き込みを、課題と是正の記録だけに限れるか
• 人が署名する判断の一覧（リスクの受容、統制の有効判定、例外、委託先の継続）
• 指示と基準を手入れする担当と、見直しの周期
• 外のAIに渡さない情報の線（未是正の弱点、個々の設定、個人の情報）
• 実行記録の形を監査人に見せ、証跡として足りるかを聞いたか
• 契約を終えるときに、証跡と記録をどの形式で取り出せるか

このうち、指示を手入れする担当と、人が署名する判断の一覧が決まらないうちは、Agent Studio で組む段階には進まず、既製の手順の範囲で始めるのが安全です。組む段階に進んだ後も、この10項目は年に一度見直します。

まとめ

Anecdotes は、証跡のデータ基盤の上に、既製の手順、自社用のエージェントを組む Agent Studio、外のAIとつなぐMCPを用意しています。規格どおりの点検なら既製の手順で足り、自社独自の統制や承認の流れがあり、指示を手入れする担当を置けるなら組む価値があります。どの形でも、エージェントは評価する対象を読むだけ、書くのはGRCの記録だけに絞り、未是正の弱点は外のAIに出さず、リスクの受容と統制の有効判定は人が署名する。この線を先に引いておけば、エージェントの実行記録は、監査で説明できる材料になります。

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