5月19日にベルリンで開催されたEuropean Identity and Cloud Conference 2026 (EIC 2026)でのキーノートスピーチのトランスクリプションの日本語訳を以下に掲載します。スライドは文末にPDFを掲載しておきます。
ソフトウェアが単なる道具でなくなる時代
みなさん、こんにちは。
私たちはいま、ソフトウェアが単なる道具ではなくなる時代に入りつつあります。
長いあいだ、ソフトウェアは命令を実行するものでした。帳票を処理し、レコードを動かし、計算を行い、ワークフローを強制し、システムとシステムをつないできました。
しかしいま、ソフトウェアは職員のようにふるまい始めています。
人間の職員ではありません。法人でもありません。人間的な意味での同僚でもありません。
職員のようにふるまうデジタルな行為者です。
私たちは彼らにミッション・任務を与え、権限を与え、ツールを提供します。そして、彼らが実社会において、調整を行い、意思決定をし、上層部への報告を行い、権限を委譲し、成果を生み出すことを期待しています。
ソフトウェアがそこまでできるようになると、ガバナンスの問題は姿を変えます。
問いはもはや、「モデルは正しく答えられるか」だけではありません。
「アプリケーションは安全にAPIを呼べるか」だけでもありません。
問うべきは：
- この作業を誰が承認したのか？
- 誰の意図が反映されているのか？
- どのような権限が委譲されたのか？
- 実行の過程で何が変更されたのか？
- 誰がこれを止められるのか？
- そして、結果が生じた際、誰が責任を負うのか？
- ということです。
ソフトウェア as 職員とアイデンティティ
検討に当たり、私はまず、あるシンプルな命題から始めたいと思います：
ソフトウェアが職員になるとき、アイデンティティがガバナンスの柱となる。
エージェンティックAIが提起するのは、モデルの安全性だけの問題ではありません。アプリケーション・セキュリティだけの問題でもありません。その中心にあるのは、委任された権限の問題です。
権限の委任には、常にアイデンティティ、オーナシップ、管理、証拠、責任、そして信頼といった問題が伴います。
従来のアプリケーションは、通常、定義されたインターフェースの範囲内で動作しました。アプリケーションは指示を受け取り、関数を実行し、結果を返します。
しかし、エージェントは違います。
エージェントは、大まかな目標を与えられ、その達成方法を自ら決定します。ツールを選択したり、APIを呼び出したり、サブタスクを作成したり、他のエージェントと連携したり、状況に応じて適応したり、組織の枠を超えて行動したりすることもあります。
だからこそ、「デジタル職員」という言葉は有用なのです。
もちろん、エージェントが人間だからというわけではありません。
大まかな目標を与えられ、その達成方法を自ら決定し実行していくというのは、従来職員に期待してきたことだからです。
私たちは彼らに仕事を割り当て、権限を付与し、成果を期待します。そして最終的には、彼らの行動に対して誰かが責任を負わなければなりません。彼らがあたかも部下であるかのように。
このパターンは人間とエージェントの間だけに限ったことではありません。エージェントからエージェントに対してでも現れはじめています。依頼を受けるエージェントが、自分に何ができるのか、どこで到達できるのか、どんなスキルを持つのか、どんな認証が必要なのかを表明し、依頼者側はそれを見て仕事を依頼する——そうしたパターンが生まれつつあります。
こうした依頼先のメタデータを発見する機能のことをディスカバリ機能といいます。この場合にもディスカバリ機能は有用です。
しかし、メタデータの発信者が管理管轄を超えた瞬間、「それって信用できるの」という問題が生じ始めます。
そのエージェントが言っていることが正しいかということも、そのエージェントの後ろに誰がいるかということもにわかには不明なわけです。
ひょっとしたらテロ支援国家が背後にいるかも知れない。
いや、それ以前に、昨日話をしたエージェントと、今接続しているエージェントは同一人物なの？という問題が出ます。
エージェントアイデンティの連続性・一貫性
ここから、最初の難問に入ります。
エージェントが「同じエージェント」であるとは、どういうことか？
人間の職員であれば、アイデンティティには連続性・一貫性（斉一性）があります。人は学び、役割を変え、経験を積んでもなお、責任という観点からは同じ人物であり続けます。
しかし、AIエージェントの場合、その連続性・一貫性はそれほど明白ではありません。
モデルが変わったら、それは同じエージェントでしょうか。
システムプロンプトが変わったら、同じエージェントでしょうか。
メモリがリセットされ、統合され、あるいは共有されたら、同じエージェントでしょうか。
ツールチェーンが変わったら。プロバイダがポリシーを変えたら。ランタイムが変わったら。サブエージェントが差し替えられたら。ミッションがある実行者から別の実行者へ引き継がれたら——私たちが信頼している「それ」とは、いったい何なのでしょうか。
そして、その行いに責任を負う「オーナー」は、誰なのでしょうか。
そこで、次の疑問が浮かびます。
エージェントのオーナー・実質的支配者は誰か？
権限を持って行動するすべてのエージェントには、責任を負うオーナーが必要です。
私はこれを「アルティメット・ボット・オーナー（UBO）」と呼んでいます。
UBO。
この表現は意図的なものです。マネロン規制では実質的支配者という概念が重要です。Ultimate Business Owner, UBO といいます。ここで私が言うUBOはこのUBOにかけていますUBOが重要なのは、アカウンタビリティを名目だけの法人で途切れさせてはならないからです。仕事を依頼する前に、それが何であるかを把握しておく必要があります。
そうしなければ、展開しているエージェントネットワーク全体が許容できないリスクにさらされることになります。 これは、サプライチェーンのリスクを抑制するために必要です。
Mission
この講演でご紹介したいもう一つの側面は、「ミッション」です。
これは「プロンプト」とは異なります。「プロンプト」とは指示のことです。
セッションとも違います。セッションとは、エージェントが作業を継続できる場です。ミッションはそれとも異なります。
ミッションとは、ある目的を達成するために人やグループに与えられた管理された委任です。エージェントが働き続けることを許されている理由です。これには、目標、制約、権限、リソース、期間、適用される方針、証拠要件、および1人または複数の主体が行動する上での説明責任の枠組みが含まれます。
ミッション、エージェント、セッションは互いに独立した概念であり、混同してはなりません。 ミッションはエージェントよりも長く存続する場合もあれば、エージェントが終了する前に終了する場合もあります。 ミッションが終了した時点でセッションがまだ進行中の場合、その場合はセッションも終了させることが適切である場合があります。
エージェントのアクションとセッションは、ミッションによって制約されます。エージェントは、ミッションを達成するためにのみ活動しなければなりません。
ミッションには明確な範囲が定められていなければ、検証可能でなければ、一時停止が可能でなければ、そして、その任務には根拠が伴っていなければなりません。
そうでなければ、エージェント型システムは単にタスクを実行するにとどまらず、その権限がどこから来たのかという信頼できる記録なしに、権限を移し替えてしまうことになります。
人間がエージェントにミッションを与えます。
エージェントは委任された実行裁量の中でタスクを形成し、行動を決定します。
エージェントはほとんどの場合、責任を負うことができないため、承認を得るために人間をプロセスに巻き込む必要がしばしば生じます。
人間の監督は重要です。
影響の大きい行動、法的措置、規制対象となる決定、資金の送金、対外的なコミュニケーション、あるいは取り返しのつかない情報開示などにおいては、人間の判断が不可欠となる場合があります。
規模の問題
しかし、すべてこれでやろうとすると、私たちは規模の問題に直面することになるでしょう。
一人の働き手が、数十、数百のエージェントを抱えるかもしれません。一つの組織なら、数千。
人間が、そのすべてのステップを意味のある形で承認することはできません。そもそも、一つのエージェントだけを相手にしていても、１タスクあたり３回目からの確認は名目化してしまうという論文も出ているくらいです。
これが一人100名のエージェントから次々に承認を求められたら惰性による承認にならざるを得ないでしょう。
このスケールでは、監督を人間のレビューだけに委ねることはできないのです。「ヒューマン・イン・ザ・ループ」は、必ずしも有意義なガバナンスとは限らない。
時間的プレッシャーにさらされ、不完全な情報のもとで行われる承認行為は、真の意味での意思決定ではありません。この状況を評してClaude Codeが言ったことがあります。
それは、人間の判断を装った「自動処理」です。
私たちには、AIエージェントの助けが必要です。プリンシパルである委任者側に立つ監督エージェントです。
このエージェントは、証拠やリスクの兆候を評価し、不要な情報を排除した上で、必要に応じて関連情報を委任者に報告します。 そしてそれは、もともと仕事を委任した人や組織の側に立っていなければなりません。タスクを完遂しようとするシステムにではなく、委任者に忠実でなければならないのです。
実行エージェントは、何かを実行する「意図」を形成した際、および実行時に、構造化されたレポートを監視エージェントに送信すべきです。例外。変更。結果。
Shared Signals 型のイベンティングは、この神経系の一部になり得ます。しかし、そうした構造化レポーティングを実装するための具体的な標準を、私たちは持っているでしょうか。
ありません。
そして、シグナルはキル・スイッチではありません。
それはシグナリング層の一部にすぎません。私たちにはコントロール・プレーンもまた必要です。
コントロール・プレーンは、介入できなければなりません。ミッションを一時停止し、権限を絞り、ツールを無効化し、委譲をブロックし、クレデンシャルを失効させ、メモリを隔離し、人間にエスカレーションし、あるいはミッションそのものを終了させる。
これらのための標準プロトコルはあるでしょうか。ありません。
Agentic AIシステムは分散トランザクションシステムである
エージェンティック・システムには、もうひとつの捉え方があります。
それは分散オブジェクト・システムと、分散トランザクション・システムとしての捉え方です。
ミッションが始まる。エージェントがツールを呼ぶ。APIを呼ぶ。サブエージェントに委譲する。状態を書き換える。メッセージを送る。そして外部に結果を生じさせるかもしれない。
従来の分散システムにおいて、長期にわたるトランザクションの処理は困難であることは、かねてより知られています。Sagaモデルでは、長期にわたるトランザクションを、単一の単位として実行されつつも、サブトランザクションに分割可能なものとして捉えています。
エージェンティックAIにも同じ問題がありますが、こちらはさらに困難です。
コーディネーターは部分的に非決定的であるかもしれません。実行者はモデルに依存するかもしれません。次のステップはコンテキストに左右されるかもしれません。
ですから、サブエージェントのタスクも、ツールも、スキルも、すべて自らの帰結のセマンティクスを宣言しなければなりません。
取り消せるのか。補償できるのか。前進復旧できるのか。それとも、不可逆なのか。
社内向けの下書きを送ることは、取り消せるかもしれません。予約のキャンセルは、補償できるかもしれません。ワークフローの修復は、前進復旧できるかもしれません。しかし機密データの開示は、不可逆です。
どの部分がまだ巻き戻せるのかを知らないまま、ミッションを統治することはできません。
エージェンティックAIは、分散トランザクションを分散した判断へと変えてしまうのです。
そしてその判断は、境界づけられ、観測でき、割り込めるものでなければなりません。
エージェントカードによるメタデータ広告
ここで、エージェントカードにスポットライトが当たります。
エージェントカードとは、エージェントの名前、プロバイダ、エンドポイント、能力、スキル、認証方式、対話の要件についての自己記述です。そしていつの日か、巻き戻せるかどうかといったトランザクション特性まで表現できるようになるかもしれません。
これらは、検出、機能宣言、エンドポイントの検出、およびプロトコルの選択において重要です。しかし、それらが何を解決し、何を解決しないのかについては、正確に把握しておく必要があります。
エージェント・カードは、そのエージェントが何をできると主張しているかを教えてくれるかもしれません。 しかしそれ自体は、そのエージェントが
- このミッションにふさわしいということを証明しません。
- ランタイムが信頼できることも証明しません。
- モデル、プロンプト、メモリ、ポリシーのバージョンも証明しません。
- Ultimate-Bot-Owner も証明しません。そして、
- リライング・パーティがこの取引においてこのエージェントを信頼してよいということも証明しません。
自己宣言のAgent Cardは、ガバナンス面で不十分です。
署名付きのAgent Cardでさえ、一歩前へ進むだけです。署名が教えてくれるのは、ある鍵が何かに署名したということだけです。
検証者はなお、その署名者、その鍵、その発行者、そのトラストフレームワークを、この目的に受け入れられるか判断しなければなりません。
- 識別は信頼ではない。
- ディスカバリーは権限ではない。
- メタデータはアカウンタビリティを置き換えない。
SPIFFE/SPIREパターン
こうしたことを考える際に、SPIFFEとSPIREのパターンは、参考になります。
SPIFFEとSPIREは、エージェントガバナンスの標準規格ではありません。しかし、これらには私たちが学ぶべきパターンが示されています。
ワークロードは、単に自分が何者であるかを宣言するだけではいけません。認証を経てから、その身元を付与されるべきです。
しかし、Agentic AIにとって、Workload Identity は出発点に過ぎません。
アテステーションは、「何が実行されているのか？」という問いへの答えとなる助けにはなります。
しかし、アテステーションでは以下の問いには答えられません。
- 誰のミッションが実行されているのか？
- どのような権限が委譲されたのか？
- どのモデルやプロンプトが使用されたのか？
- どのポリシーが適用されたのか？
- そのアクションに対して補償は可能か？
- 最終受益者（UBO）は誰か？
したがって、ワークロードの証明に加え、ミッションの証明、権限の証拠、トランザクションのセマンティクス、および監視レポートが必要となります。
フェデレーションによる信頼の枠組み形成
ここで「フェデレーション」が登場します。
エージェントカードは、何が主張されているかを示します。
アテステーションは、何が実行されているかについて情報を提供します。
フェデレーションは、どの主張やアテステーションを信頼すべきかを判断するのに役立ちます。
OpenIDフェデレーションは、相互に連携しようとするエンティティが、「トラストアンカー」と呼ばれる信頼できる第三者を通じて信頼関係を確立する方法を定義しています。これは複数の階層のオーソリティをサポートしており、1つのエンティティが複数のフェデレーションに所属することも可能です。また、動的かつ分散型の信頼ネットワークを構築するための技術的な信頼インフラの構成要素を提供します。
フェデレーションにより、その署名鍵が、私たちが承認する信頼フレームワーク内のエンティティに属しているかどうか、有効な信頼チェーンが存在するかどうか、メタデータポリシーが適用されているかどうか、そして信頼マークがこの依存当事者にとって意味のあるものかどうかを確認することができます。
エージェントのガバナンスにおいて、これは極めて重要です。
すべての当事者が、すべてのエージェント、プロバイダ、レジストリ、アテステーション発行者、UBOについて、ひとつひとつ手作業で受け入れ可否を判断する——そんな世界は望ましくありません。
トラスト・チェーンとメタデータ・ポリシーが必要です。権限が行使される前に、誰の主張を受け入れるのかを決める仕組みが必要なのです。そのためにフェデレーションの仕組みはとても有用なのです。
標準の利用の重要性
こうしたことを実現するために有用なコンポーネントはすでに多数存在します。OpenID関連の仕様群だけでも、ここにあげたようなものがあります。
- OpenID Connect
- OpenID4VCI/VP
- AuthZEN
- OpenID Federation
- OpenID Shared Signals and Events Framework
- etc.
その多くは、セキュリティの観点から数学的に形式的に検証されています。
もちろんこれらだけでは足りません。しかし、再利用可能なものは再利用し、本当に必要なものだけを構築すべきです。
Liabilityと保険数理上の課題
最後に、ガバナンスが最後にかならずたどり着く問いを上げます。
損失を負うのは、誰か。
エージェントがデータを漏らし、支払いを誤送し、ワークフローを操作し、誤った指示を送り、あるいは有害な連鎖を引き起こしたとき、責任は最終的にどこに落ち着くのか。
この観点でも、Ultimate-Bot-Owner は重要になります。
そして、証跡が重要になります。証跡がなければ、アカウンタビリティは弱まります。責任の所在は推測の域を出なくなり、保険は当て推量に過ぎなくなります。
現状では、Agentic AIのリスクに関する保険数理的な根拠は、依然として未熟な段階にあります。だからといって、待つ理由にはなりません。今こそ測定インフラを構築すべきです。
保険はスローガンだけで成り立つものではない。リスクの露出度、発生頻度、被害の深刻度、管理の有効性、因果関係、そして損害データが必要です。
ソフトウェアは職員になりつつあります。
これらに対するガバナンスが必要になってきています。
活用できる標準規格は存在します。
しかし、ガバナンスの効くエージェント・インフラを構築するだけでは不十分です。埋めるべきギャップは数多く存在します。
Identeratiの皆さん、信頼できるエージェント・エコシステムを構築する旅は、まだ始まったばかりです。
皆で力を合わせて、今すぐ作り始めましょう。