気づけば承認されていた
ある朝、経理担当者が会計システムを開くと、昨夜のうちに支払処理がいくつも進んでいた。
仕入先の与信調査が終わり、金額の検算が済み、承認まで通っていた。
誰かが残業したわけではない。
AIエージェントが、イベントをきっかけに一連の処理を走らせただけだ。
処理そのものは正しい。
問題は別のところにある。
「これは誰が決めたのか」と聞かれたとき、はっきり答えられないのだ。
ログには実行者としてエージェントの名前が残っている。
だが、それは「誰が判断したか」の答えにはなっていない。
私たちはこれまで、システム上のあらゆる操作は最終的に人間のログインにたどり着く、と暗黙に信じてきた。
その前提が、静かに崩れはじめている。
ニュースの要約
2026年7月2日、Microsoft Dynamics のパートナー系メディア ERPSoftwareBlog に、Dynamics コンサルティングを手がける DAX Software Solutions による記事が掲載された。
主張はシンプルだ。
自律的に動くAIエージェントが、ERP(基幹業務システム)の中核業務に、ガバナンスの整備が追いつかない速さで入り込んでいる、というものである。
記事によれば、Dynamics 365 のようなプラットフォーム上のエージェントは、いまや口座調査、買掛金処理、在庫管理、サービス案件の振り分けまでを、人間のログインではなくイベントを起点に実行できる。
だからこそ、監査ログや承認の閾値、権限の範囲、監視、ロールバックといった仕組みを、導入後に後付けするのではなく、導入前に設計しておくべきだと説く。
放置すれば、レビューされることを前提に作られていない判断が、レビュー不能なまま積み上がっていくと警告している。
一つ補足しておきたい。
この記事は独立した報道でも、標準化団体の文書でもない。
ガバナンス支援サービスを提供するベンダーが書いた実務記事である。
その点は差し引いて読む必要があるが、指摘している構図そのものは、多くの現場に当てはまる。
この記事が本当に言っていること
表向き、この記事は「監査ログを設計せよ」「承認フローを整えよ」というチェックリストだ。
実際、挙げられている項目は具体的で役に立つ。
結果だけでなく判断に至った経緯まで残す監査ログ。
金額の大きさと取り消しやすさに応じた承認のしきい値。
エージェントごとに絞った権限。
導入後のふるまいの変化を見張る監視。
そして、連鎖した処理を巻き戻すロールバック。
だが、この5つを並べて眺めると、あることに気づく。
どれも「判断が行われた後」をどう扱うかの話なのだ。
記録する、止める、巻き戻す。
いずれも、判断そのものはすでに終わっている。
ここに、言葉にしづらい違和感が残る。
責任、監査、承認、権限。
これらをどれだけ丁寧に整えても、埋まらない隙間があるように感じる。
その隙間が何なのかは、まだ名前を持っていない。
なぜERPだけの話ではないのか
同じ構図は、ERPの外にいくらでもある。
顧客対応のエージェントが、返金の可否をその場で決める。
購買のエージェントが、在庫を見て発注をかける。
セキュリティのエージェントが、疑わしい通信を検知して遮断する。
人事の評価支援ツールが、候補者を絞り込む。
どれも、イベントを起点に、人間のログインを経ずに判断が進む。
そして、いずれの現場でも問われるのは同じ問いだ。
「これは誰が決めたのか」。
この問いが世界的にも重く受け止められはじめている。
政府は、自律的に動くAIエージェントに対して、誤作動やプライバシー侵害のリスクを念頭に、人間の判断を必須とする仕組みづくりを開発企業などに求めている。
総務省と経済産業省がまとめたAI事業者ガイドライン1.2版にも、その考え方が示されている。
海外に目を向ければ、EUのAI法は高リスクシステムへの義務を2026年に本格適用し、シンガポールはエージェント型AIに向けたガバナンス枠組みで、エージェントごとの識別子と監査可能性を求めている。
方向は一致している。
人間の判断は、どこかに残さなければならない。
だが問題は、その判断を業務のどこに置くかだ。
人間が介在する場所そのものを、設計しなければならない。
その線を「どこに」引くのかは、まだ誰も明確に答えていない。
では、本当に設計すべきものは何なのか
ここで立ち止まって考えたい。
監査ログは、判断の記録を残す。
承認フローは、判断にゲートを設ける。
権限設定は、判断できる範囲を絞る。
どれも判断の「周り」を固める仕組みだ。
しかし、周りをいくら固めても、中心にある問いは残ったままになる。
そもそも、この判断は人間が下すべきものなのか、エージェントに任せてよいものなのか。
その線を、誰が、どういう根拠で引いているのか。
多くの現場で、この線は設計されていない。
たまたまツールが対応していたから任せた。
たまたま人手が足りなかったから自動化した。
線は引かれているのではなく、なりゆきで引かれてしまっている。
設計すべきなのは、記録でも承認でも権限でもない。
その判断を、誰が持つのか。
判断の配置そのものではないか。
この記事の後半では、なぜGovernance(統制)だけでは足りないのかを整理する。
そのうえで、Decision Boundary(判断の境界)とは何かを定義し、Decision Designがどの問題を解決しようとしているのかを、具体的な実装例とともに説明する。
ここから先に置いておく地図
Decision Design™︎ は、判断の配置そのものを設計対象とする考え方である。
その中心にあるのが Decision Boundary™︎ という概念だ。
誰が決めるのか。
どこまでを任せ、どこからを引き受けるのか。
その線を、無自覚のまま放置せず、意図的に設計すること。
それがDecision Designである。
監査ログも承認フローも権限設定も、この境界が引かれて初めて意味を持つ。
逆に言えば、境界を設計しないまま統制の道具だけを増やしても、冒頭の「気づけば承認されていた」は繰り返される。
後半では、この考え方を分解する。
Governance、DX、Automation、AI Ethics。
どれもAIエージェント時代に必要な視点だ。
だが、そのどれもが単独では足りない。
それらを横断したところに、Decision Designという設計概念が立ち現れる。
詳細版について
本稿は、公開範囲を基に構成したInsynergyの日本語サイト版です。詳細な議論と実装上の考察はnoteの詳細版で解説しています。