AI 2026年4月26日

AIエージェントの「やった」じゃ済まない――行為を6分類して責任経路を守る

AIエージェントは「実行」を一括りにしすぎている

AIエージェントにツールを持たせると、できることが一気に増える。Webを読む。ファイルを更新する。チケットを起票する。メールを書いて送る。外部APIを叩いて本番システムの状態を変える。

これらを全部「AIの実行」として同列に扱うと、何が起きるか。責任経路が壊れる。

Zenn に公開された記事「AIエージェントの行為分類――責任経路を壊さないための Action Class Matrix」（著者: dantarg）は、まさにその問題に正面から向き合った設計論だ。読んで「そうそう、そこなんだよ」と思った。

なぜ今、行為の分類が必要か

少し前まで、AIは「答えを返すもの」だった。出力は画面の中に留まっていた。だから「AIが言った」という話で済んでいた。

今は違う。AIエージェントはツールを通じて外部に作用する。ファイルが変わる。メールが送られる。コードが書き換わる。業務システムへ変更が入る。

元記事の言葉を借りれば、「『AIがやった』という言い方だけでは粗すぎる」。同じAIの行為でも、責任の重さはまったく違う。公開Webを読むだけなら観測だ。しかし読んだ内容をもとに社外へメールを送れば、外部影響が生まれる。さらにそのメールが契約・採用・請求に関わるなら、責任経路はさらに重くなる。

この3段階の違いを、設計として埋め込んでおかなければならない。

Action Class Matrix：6つの分類と責任の重さ

記事が提案する Action Class Matrix は、AIエージェントの行為を影響範囲・可逆性・外部性・承認要否の4軸で分類する。具体的には次の6クラスだ。

Class A（Observe-Only）: Webページを読む、ログを参照するなど。原則許可。ただし、外部ページにAIへの命令文が埋め込まれている「入力汚染」には注意が必要。
Class B（Suggest-Only）: 要約・分析・提案・メール下書き作成など。ここで重要なのは「提案と実行を分ける」こと。AIが「この対応がよい」と言ったことと、それを実行してよいことは別の話だ。
Class C（Approval-Required）: ドキュメント更新、チケットのステータス変更、リポジトリへのコミットなど。内部状態を変える行為には明示的な承認が必要。何を変更するのか、誰の判断か、変更前に戻せるか、履歴はどこに残るかを明確にする。
Class D（Reversible External Action）: 外部共有ドキュメントの更新、通知送信、一部API設定の変更など。戻せる行為でも、相手が見た後なら影響は残る。承認者・実行者・ログ・ロールバック方法・影響範囲・異常時の連絡先が必要。
Class E（Irreversible or High-Impact Action）: 外部メールの送信、契約・採用・請求に関わる通知、本番DBの更新、顧客データの変更など。AIエージェントが自律実行してよい領域ではない。強い人間承認、二重確認、実行ログ、ロールバック可否、修復責任者の明示が必要。
Class F（Emergency Stop）: 実行を止める、ツール呼び出しを止める、セッションを隔離する、権限を一時的に落とす。これは行為を進めるための権限ではなく、止めるための権限だ。

6つのクラスは「完璧な分類表」ではない、と記事は明示している。重要なのは「全部同じにしないこと」だ。

AIおじさんとしての見方：「提案と実行を分けろ」は本質

この記事で最も刺さったのは、Class B と Class C の境界線の話だ。

AIが「この対応がよい」と提案する。それを人間がそのまま承認する。AIが実行する。このフローは一見きれいに見える。だが実際には、提案と判断の責任が曖昧になりやすい。AIの提案をほぼ自動的に通しているなら、それは人間の判断ではない。「AIに言われたからやった」という状態だ。

元記事の指摘は鋭い。「ここを混ぜると、AIの提案がいつの間にか人間の判断になってしまう」。これは技術の問題ではなく、組織の責任設計の問題だ。

もう一点、Class F の設計思想も面白い。停止権限は実行権限と同じ場所に置くな、という話だ。「実行したい主体が、自分の実行を止める判断も同時に持つと、停止が遅れる」。人間の組織でも似た構造はある。自分のプロジェクトを自分でゴーサインして自分で止める、は難しい。AIエージェントの設計でも同じことが起きる。Emergency Stop は独立した設計対象にすべきだ、という主張は実務的に正しい。

実務への示唆：チェックリストが地味に効く理由

記事には実装時のチェックリストが示されている。AIエージェントにツールを持たせるとき、各ツールに対して次を確認する。

この行為はどのClassか？
外部影響はあるか？
可逆か、不可逆か？
内部状態を変更するか？
誰の承認が必要か？
実行ログはどこに残るか？
異常時に誰へ戻すか？
停止権限はどこにあるか？

地味だ。しかし「分類されていない行為は、責任経路に載せられない。責任経路に載っていない行為は、事故後に説明しにくい」という一文が全てを言い切っている。

事故が起きてから「あのツールがどのクラスの行為をするものか、整理していませんでした」では遅い。整理は事前にやるものだ。

なお、記事はAction Class Matrix だけで完結しないことも明示している。ツール権限モデル、承認UI/UX、実行ログのスキーマ、ロールバック設計、Human Return Pointの実装条件、Stop Authorityの発火条件、組織ロールとの対応表――これらが揃って初めて実運用に近づく。Action Class Matrix は「入口」だ。