Column
「このAIエージェント、どこまで審査すべき?」を毎回ゼロから議論するのをやめる——12次元スコアリングで社内エージェントをリスク階層化する
社内で内製されるAIエージェントが増えるほど、「これは軽い審査でいいのか、役員決裁レベルなのか」の線引きが属人化していきます。TrustX Agent Risk Classification Framework（ARC）は、7種類のエージェントを12次元でスコアリングし、5段階の自律性と組み合わせて3段階のガバナンス出力を返す枠組みです。リスク管理・法務・IT統制の現場でどう試せるかを、部署とKPIまで含めて考えます。
こんにちは。Affectosphere Group の三浦です。
社内でAIエージェントを作っている会社の方なら、この会話に覚えがあるかもしれません。
「営業チームが作った議事録エージェント、審査いる?」「経理の請求書処理エージェントは? あれ、勝手にシステム更新するらしいけど」「コーディング支援ツールって、そもそもAIガバナンスの対象なの?」——。
気づけば社内のあちこちでエージェントが生えていて、どれを厳しく見て、どれを軽く通すのかの線引きが、担当者の勘に依存している。しかも判断の根拠が残らないので、次に似た案件が来ても、また同じ議論をゼロからやり直す。
arXiv に公開された研究（Liu, Saxena & Asthana, arXiv:2607.09586）は、まさにこの「エージェントのリスク階層化」を仕組みにしにいっています。提案されているのは TrustX Agent Risk Classification Framework、略して ARC。
今日はビジネス応用の視点から、この枠組みを自社の審査プロセスにどう組み込めるかを考えてみます。
今日の3点
- エンタープライズや公共セクターでエージェンティックAIが急増した結果、汎用のAIリスクフレームワークでは分類もガバナンスも追いつかなくなっている。ARCはそこを埋めにいく専用ツールとして提案された。
- ARCは7種類のエージェンティックAIシステムに適用できる構造化・反復可能な評価ツール。12次元のスコアリングルーブリックでリスクを定量化し、GPAとIATという分類モデル、5段階の自律性フレームワークを組み合わせて、コントロール推奨付きの3段階ガバナンス出力を返す。
- 「どのエージェントに、どのレベルの審査と監督を課すか」を標準化する土台になる。リスク管理・法務・IT統制の審査フローに、開発前アセスメントとして差し込める芽がある。
① なぜ、汎用のAIリスクフレームワークではエージェントを裁けないのか
まず、なぜ既存の枠組みでは足りないのかを整理します。
これまでのAIリスク評価は、ざっくり言えば「モデルが何を出力するか」を見てきました。予測が偏らないか、誤分類の影響は何か、といった話です。
でもエージェントは、出力するだけでは終わりません。ツールを呼び、APIを叩き、他システムの状態を書き換える。人間の確認を挟まずに、次の行動を自分で決めることもある。
つまりリスクの本体が「何を言うか」から「何をするか」へ移っています。同じ言葉を返すエージェントでも、それを社内Wikiに書くだけなのか、本番DBを更新するのかで、必要な監督の重さはまるで違う。
この研究が問題視しているのは、そうした急増するエージェントに対して、汎用フレームワークの分類・ガバナンス能力が追いついていない点です。だから「エージェント専用の、構造化された、反復可能な」評価ツールが要る、という組み立てになっています。
反復可能、というところが地味に大事だと思っています。担当者が変わっても同じ結論が出る。それが仕組み化の最低条件ですよね。
② ARCは何をするのか:7カテゴリ × 12次元 × 5段階自律性
ARCの構成を、論文の記述に沿って追ってみます。
まず対象。7種類のエージェンティックAIシステムに適用できるように設計されています。社内のエージェントをまず「どのタイプか」に置く、という入口です。
次に評価。12次元のスコアリングルーブリックでリスクを定量化します。感覚で「これは危なそう」と言うのではなく、決まった軸に沿って点を付ける。ここが属人性を殺しにいくパートです。
そこに、GPAとIATと呼ばれる分類モデルと、5段階の自律性フレームワークが重なります。自律性を段階で捉えるのは、私はかなり実務的な発想だと感じました。人間が毎回承認するのか、事後確認だけなのか、完全に任せるのか——同じ機能でも、この段階が上がるほど怖さは跳ね上がるからです。
そして出力。ARCが返すのは、3段階のガバナンス出力と、それに紐づくコントロール推奨です。「このエージェントは中リスク層。したがって、これらの統制を適用してください」という形で、判定と打ち手がセットで出てくる。
判定だけ出して「あとは現場で考えてね」だと、結局止まります。マッピングされたコントロール推奨まで返すという設計は、実装する側としてありがたい。
ちなみに Coding Assistant への特化拡張も含まれています。社内で最初に増えるエージェントがコーディング支援であることを考えると、ここに個別対応があるのは現実を見ている感じがします。
③ 現場でどう試すか:部署とKPIの具体案
では、これを自社でどう試すか。私なりの導入シナリオを書きます。
狙いは、ARCを「開発前リスクアセスメントの必須ゲート」として制度に埋め込むことです。社内でAIエージェントを内製・導入しようとするチームは、着手前にARCの評価シートを通す。7カテゴリのどれか、12次元のスコアはいくつ、自律性は何段階目か。その結果として3段階のどのリスク層に落ちるかが決まり、必要な審査と統制が自動的にひもづく。
低リスク層ならチーム内レビューで通す。中リスク層ならリスク管理部門のレビューを挟む。高リスク層なら法務・情報セキュリティ・AI推進室の合同審査に上げる——このくらい機械的に決まると、審査が速くなります。
想定する部署はこうです。まずリスク管理部門。ARCの評価と階層定義のオーナーになり、社内基準として運用します。次に法務・コンプライアンス部門。EU AI Actをはじめとする規制への対応で、「どのシステムをどう扱ったか」の説明責任を果たす材料になります。ここは補足しておくと、この論文がEU AI Actへの適合を実証したという話ではありません。あくまで、社内の分類結果を規制対応の土台として使えそうだ、という私の見立てです。
そしてIT統制・情報セキュリティ部門。高リスク層に振られたエージェントに、どの技術統制を実際に適用するかを担います。最後にAI推進室。エージェント内製を推進する側として、審査を通しやすい設計パターンを現場に配る役です。
測定KPIは、導入効果を数字で語れるように次を提案します。
第一に、AIインシデントの発生件数。エージェント起因の事故が、階層化の導入前後でどう変わったか。第二に、規制監査のパス率と指摘件数。分類の記録が残っていることで、監査対応がどれだけ軽くなったか。第三に、AIリスク審査のリードタイム。「審査に何日かかるか」は、現場がガバナンスを迂回するかどうかを左右する、地味に一番大事な指標です。第四に、コンプライアンスコスト対比の効率。審査工数あたり、何件のエージェントを裁けるようになったか。
進め方は、いきなり全社必須にしないことをおすすめします。まずはコーディング支援エージェントだけを対象に、ARCの拡張部分を使って回す。判定が現場の納得感と合っているかを見る。ズレていたらルーブリックの重みを社内向けに調整する。そこで信頼が積み上がってから、対象カテゴリを広げていく。
ガバナンスの仕組みは、現場が「これは公平だ」と思わないと、静かに迂回されます。最初の一巡目で納得を作れるかが勝負だと思います。
「速く通すため」のガバナンスへ
この論文を読んで面白かったのは、リスク階層化が、実は開発を止めるためではなく速く通すための仕組みだ、という点です。
全部を同じ重さで審査すると、審査部門が詰まり、現場は待たされ、待たされた現場はやがて審査を避けるようになる。それが一番危ない。
でも「これは低リスク層だから2日で通る」と最初から分かっていれば、現場は素直にゲートをくぐります。そして本当に危ないエージェント——本番システムを自律的に書き換えるようなもの——に、審査のリソースを集中できる。
エージェントの数がこれから増えることは、ほぼ確実です。だとすれば、一件ずつ議論する方式はどこかで必ず破綻します。今のうちに、分類と階層の言語を社内に持っておく。ARCはその叩き台として、かなり実用的な形をしていると感じました。
では!
参考論文
- Liu, Hannah M., Saxena, Rhea, & Asthana, Shiv (2026). TrustX Agent Risk Classification Framework (ARC): Risk-Tiering Internally Created Agentic AI Systems. arXiv preprint. https://arxiv.org/abs/2607.09586
※ 本記事は一部 AI により執筆されており、間違った情報が含まれる恐れがあります。