IBMが到達した地点と、その先に残る問い
AIエージェントをめぐる議論のなかで、いま最も鋭いところまで踏み込んでいる文章のひとつが、IBMのBob Slocumが書いた「The accountability gap in autonomous AI: How governance turns risk into an advantage」だ。
この記事は、多くの「AIガバナンス入門」とは水準が違う。
なぜIBMなのかを、先に押さえておきたい。IBMは、企業のIdentityとアクセス管理（IAM）を数十年にわたって担ってきた、この領域の世界最大級のプレイヤーである。いわば「誰が何にアクセスできるか」を設計し続けてきた当事者だ。そのIBM自身が、この記事で「Identityでは足りない」と言い始めている。鍵を作ってきた側が、鍵だけでは守れないと認めた。この一点だけでも、記事の重さは変わってくる。
生成AIブームの初期に量産された記事は、たいてい「AIにも権限管理が要る」という一般論で止まっていた。Slocumの記事はそこを通り過ぎる。Autonomous AI、つまり自律的に動くAIエージェント（Agentic AI）を相手にしたとき、従来のIdentity Access Management（IAM）がどこで壊れるのか。それを、具体的な失敗の形まで分解して見せている。
読み終えたとき、多くの人は納得する。そして同時に、ひとつの問いが残る。
その問いは、記事の中には書かれていない。書かれていないからこそ、この記事が到達した地点がわかる。まず、記事が何を成し遂げたのかを整理しておきたい。
IBMの記事は、何を積み上げたのか
Slocumの議論は、いくつかの概念を階段のように積み上げていく。要約ではなく、その構造を取り出してみる。
Identity（誰であるか）
従来のIAMは、人間か、あるいは固定的なマシンにIDを割り当てる前提で作られていた。しかしエージェントは、特定のワークフローや、極端な場合はたった一回の取引のためだけに生成され、実行後すぐに消える。IDが、安定した人間のアカウントではなくなる。だから記事は、すべてのエージェントに検証可能な固有のIdentityを与えよ、と説く。
Authorization（何を、いつまで許すか）
認証（Authentication）が済めばセッション中は自由、という粗い許可では足りない。すべての権限はスコープを絞り、時間で区切り、いつでも取り消せる状態に置く。Authorizationを、事後に証明できる一級の対象として扱う。
Runtime Governance（実行時の統制）
ポリシーが文書として存在しても、実際の行動、つまりAPI呼び出しやデータアクセスや設定変更の瞬間に制御が効かなければ意味がない。監査人がいま求めているのも、静的なライフサイクル管理ではなく、実行時のプロセス評価だと記事は指摘する。
Accountability（誰の権限で起きたか）
事故が起きたあとに、何が、なぜ、誰の権限で実行されたのかを再構成できること。
Audit Trail（監査証跡）
取引の端から端までを、人間とマシンをまたいで一本の線でつなぐ記録。
この積み上げの上で、記事は核心を一言で言い切る。必要なのはaccess control（アクセスの制御）からAuthority Control（権限の制御） への移行だ、と。IAMを「入口の鍵」として設計してきた発想から、権限そのものを行動のたびに検証し続ける発想への転換である。
ここまでの整理は、率直に見事だと思う。Identity Access Managementの限界を、Authority Controlという次の地平まで押し上げた。この一点だけでも、この記事は読む価値がある。
しかし、一つの問いが残る
Authorityを制御する。
取り消せるようにする。
証明できるようにする。
記事が語っているのは、突き詰めれば「与えられた権限を、いかに正しく扱うか」である。誰が、どのエージェントに、どこまでの権限を持たせるか。その線がすでに引かれていることを前提に、その線を監視し、記録し、必要なら剥奪する。Runtime GovernanceもAccountabilityも、この前提の上に立っている。
では、その線そのものは、誰が引いたのか。
Authorityを制御する仕組みは精緻になった。しかし、そのAuthorityを最初に「どこまで」と定めた設計は、誰の手によるものなのか。この契約レビューはエージェントに任せ、この与信判断は人間が引き受ける。その配分を決めた瞬間は、どこにあったのか。
記事はここには踏み込まない。踏み込まないのは、欠陥だからではない。IBMの記事はAuthority Controlという到達点までを正確に描いた。その一歩先、Authorityそのものを設計するという問いは、Governanceという枠組みの外側にあるからだ。
日本政府も同じ方向へ動き始めている
同じ地殻変動は、制度の側からも起きている。
日本政府は、自律的に動くAIエージェントに対して、誤作動やプライバシー侵害のリスクを念頭に、人間の判断を必須とする仕組みづくりを開発企業などに求めている。総務省と経済産業省が2026年3月31日に公表した「AI事業者ガイドライン（第1.2版）」にも、その考え方は盛り込まれている。同ガイドラインは、AI活用の促進を前提としながらも、出力が公平性や安全性を欠くおそれのある場面では、人間の判断を適切に介在させるべきだという立場を示している。
注意して読むと、ここで問われているのは「人間が判断すること」そのものではない。どの場面で人が介在するのか。ただ人を置くのではなく、自動化バイアスをどう防ぐのか。納得ある理由が要る場面で、人の説明はなぜ重くなるのか。ガイドラインが整理しているのは、判断を人に戻す境目の設計である。
社会は、Human-in-the-Loopという言葉が指してきた「人を残す」段階から、「人が判断する場所を、意図して決める」段階へと動き始めている。IBMが技術の側から到達した地点と、日本の制度が求め始めている方向は、驚くほど近いところで交差している。
Governanceだけでは答えられない
ここで立ち止まっておきたい。
IBMの記事が最後に残した問い、Authorityそのものを誰が設計するのかという問いは、AI Governanceの語彙では答えられない。Governanceは、決められた権限を運用し、監視し、証明する技術だからだ。線がすでに引かれていることを前提にしている以上、その線をどう引くかは、Governanceの管轄の外にある。
一文で対比するならこうなる。
Governanceは、設計されたAuthorityを統治する。
Decision Designは、Authorityそのものを設計する。
統治と設計は担当する層が違う。
Authorityを制御する仕組みの手前には、Authorityを配分するという行為がある。この行為が、これまで誰の設計対象にもなってこなかった。
ここに名前を与える。Decision Design™︎（判断の設計） である。
Decision Designは、判断という行為そのものを設計対象とする思想だ。その中心にあるのが、Decision Boundary™︎（判断の境界） という概念である。
誰が決めるのか。 どこまでを任せ、 どこからを引き受けるのか。
その線を、無自覚のまま放置せず、意図的に設計すること。それがDecision Designである。
IBMの記事が「線をどう扱うか」を語ったとすれば、ここから先は「線をどう引くか」の話になる。有料部分では、Decision Designとは何か、その中心にあるDecision Boundaryとは何か、そしてなぜAI GovernanceやRuntime Governanceだけでは足りないのかを、順に書く。IBMがAuthority Controlで止まった、まさにその一歩先である。
詳細版について
本稿は、公開範囲を基に構成したInsynergyの日本語サイト版です。詳細な議論と実装上の考察はnoteの詳細版で解説しています。