松本泰氏の講演から考える、AIエージェント時代のデジタルトラスト設計
ランサムウェア、なりすまし、偽サイト、フェイク画像・音声、偽情報。デジタル上で相手や情報を「本物だろう」と自然に信じられる前提は、すでに崩れている。
AIエージェントが普及すれば、この問題はさらに複雑になる。人間がAIへ仕事を依頼するだけではない。AIが文書を参照し、外部ツールを使い、別のAIや業務システムと連携し、一定の権限で処理を実行する。信頼の対象は、メールの送信者やWebサイトだけでなく、モデル、データ、ツール、実行環境、AIが出した判断へ広がる。
松本泰氏の講演が提起したのは、AIを「信じるべきか」という二者択一ではない。
誰が、何を根拠に、どの範囲まで信頼するのかを、検証可能な仕組みとして設計できるか。
これがデジタルトラストの問いである。
結論から言えば、AI時代のトラストは「私を信じて」という暗黙の前提では維持できない。技術、証跡、ルール、責任の所在を組み合わせ、「私を検証して」と言えるアーキテクチャへ移る必要がある。
トラストは「信頼すること」と「信頼に足ること」を分けて考える
トラストの議論では、似た言葉を混同しないことが重要である。
| 用語 | 意味 | 設計上の問い |
|---|---|---|
| Trustee | 信頼の対象となる人、組織、デバイス、システム | 何を評価するのか |
| Trustor / Truster | 信頼する側、依存・利用を判断する側 | 誰が判断するのか |
| Trustworthiness | 信頼に足る性質、能力、状態 | どの根拠で品質・安全性を示すのか |
| Trust | 根拠を踏まえて依存・利用を決める判断 | どの条件なら利用を許すのか |
たとえば、医師を利用する患者は、医師個人の診療能力を完全には確認できない。それでも国家資格、医療機関の認可、専門職としての規律、事故時の責任制度があるため、一定の判断を委ねられる。
このとき、資格や制度が「その医師は信頼に足る条件を満たしている」と示す仕組みであり、患者が治療を受ける判断がトラストである。
AIでも同じである。
モデルが高性能であることは、個別業務で利用してよいことを直接意味しない。参照データは正しいか、更新されたコードは承認済みか、ツール実行権限は妥当か、ログは残るか、事故時に止められるか。こうしたトラストワージネスを示す根拠と、実際に利用を許すトラスト判断を分けて設計する必要がある。
主観的な信頼だけでは、複雑なデジタル社会を支えられない
講演では、トラストを大きく二つの見方で整理していた。
一つは、個人の感覚や経験に基づく、心理学・行動経済学的な信頼である。「あの人は過去に約束を守った」「このサイトは見慣れているから大丈夫そうだ」といった、主観的で暗黙のトラストである。
もう一つは、資格、認可、契約、監査、責任分担といった、制度やルールによる社会学的なトラストである。社会の複雑さを減らし、個々の利用者がすべてを調べなくても取引やサービス利用を可能にする。
デジタル化が進むと、後者の重要性が増す。
クラウド上のAI、外部SaaS、API、IoT、サプライチェーンは、利用者から見えにくい。しかも相手は、人間だけではない。AIエージェントが別のAIやシステムを選び、データを取得し、処理を依頼することもある。
利用者の注意力やリテラシーだけに依存する設計では限界がある。人が「怪しいものを見分ける」ことを求めるのではなく、システムと制度の側で、検証、制限、説明、救済を組み込む必要がある。
活版印刷とAIに共通するのは、情報流通の前提を変えること
松本氏は、AIがもたらす変化を、活版印刷の登場になぞらえた。
活版印刷は知識の複製と流通を大きく広げた。一方で、情報が広がる速度と量が増え、既存の権威だけでは情報の正しさを保証できなくなった。社会は、誰が何を語るか、どの情報を根拠にするかという問題へ向き合うことになった。
生成AIも、文章、画像、音声、コードを大量かつ低コストで作れるようにする。便利さの裏側では、次の問いが強くなる。
- この文章や画像は、誰が作ったのか
- どの情報を根拠にしているのか
- 改ざんや編集を受けていないか
- AIがどのツールを使い、何を実行したのか
- 判断に誤りがあったとき、誰が説明し、是正するのか
AI時代に必要なのは、出力を見て「もっともらしいから信じる」ことではない。作成・利用・実行の過程を確認できるようにすることである。
ゼロトラストは「何も信じない」ことではない
ゼロトラストは、しばしば「誰も何も信じない仕組み」と説明される。しかし、その理解では不十分である。
NISTはゼロトラストを、ネットワーク上の位置や所有関係だけを理由に、ユーザーやデバイスへ暗黙の信頼を与えない考え方として定義している。守る対象はネットワーク境界ではなく、資産、サービス、ワークフロー、アカウントなどのリソースである。 NIST SP 800-207
つまり、ゼロトラストはトラストを捨てる思想ではない。
暗黙の信頼を減らし、認証、認可、状態確認、ポリシー、ログという明示的な根拠に基づいて、限定的な信頼を与える設計である。
AIエージェントに当てはめると、次のようになる。
| 悪い前提 | 検証可能な設計 |
|---|---|
| 社内ネットワークからのアクセスだから安全 | 利用者、エージェント、端末、処理目的を確認する |
| 承認済みAIだから何でも実行できる | ツールごと・操作ごとに最小権限を付与する |
| RAGに入れた文書は正しい | 正式性、版、更新日、所有者、参照権限を確認する |
| AIの提案は妥当だろう | 根拠、信頼度、影響、承認者を表示する |
| 一度審査したから運用中も安全 | モデル、データ、権限、実行ログを継続監視する |
「信じない」のではない。何を、どの範囲で、いつまで信頼するかを検証可能にするのである。
リモートアテステーションは「正しい状態か」を遠隔で確かめる技術
講演では、明示的なトラストを支える技術として、リモートアテステーションが紹介された。
リモートアテステーションは、遠隔にあるデバイス、ハードウェア、ソフトウェアが、期待された状態にあることを暗号技術で示し、第三者が評価する仕組みである。単に「この端末はこの名前です」と認証するだけではない。起動したソフトウェア、設定、実行環境などに関する証拠を取り、ポリシーと照合して、利用を許すかどうかを判断する。
IETFのRATSアーキテクチャでは、主に次の役割を分ける。 RFC 9334
Attester（証拠を生成する対象）
↓ Evidence
Verifier（証拠とポリシーを照合し評価する者）
↓ Attestation Result
Relying Party（結果を基に利用・接続・権限を判断する者）
IETFのEntity Attestation Token（EAT）は、デバイス、ハードウェア、ソフトウェアなどに関する主張を表すためのトークン形式である。証拠には鮮度を確かめる仕組みも必要で、過去に正しかった状態を再利用して現在の正しさを偽装できないようにする。 RFC 9711
ただし、アテステーションは「このシステムは完全に安全」と万能に証明する技術ではない。
示せるのは、あらかじめ定義した測定項目やポリシーに対して、対象がどの状態にあるかである。評価基準が不十分なら、技術的に正しい証拠があっても、業務として適切な信頼判断にはならない。
欧州の実証が示す、トラストは静的な認証では足りないという事実
講演では、複雑なシステム同士が連携する社会の例として、コネクテッドカーとコネクテッド医療デバイスが紹介された。
欧州のERATOSTHENESプロジェクトは、IoTデバイスのアイデンティティ、トラスト、セキュリティを、導入から廃棄までのライフサイクルで管理する枠組みを検証した。公開情報では、接続車両と路側機の連携、遠隔患者モニタリング、産業IoTという三つの実証が行われている。 European Commissionの紹介
コネクテッドカーでは、車両や信号機などの路側設備が、リアルタイムにデータを交換する。ある車両から届いた情報が改ざんされていたり、送信元が侵害されていたりすれば、単に通信を暗号化していても安全な制御にはつながらない。
遠隔患者モニタリングでも同じである。医療デバイスは、一度認証して終わりではない。ソフトウェア更新が適用されているか、脆弱性が放置されていないか、接続状態は適切かを、運用期間を通じて確認する必要がある。
プロジェクトの狙いは、デバイスをネットワークへ接続するときだけでなく、参加、更新、利用、離脱までを通じて、文脈に応じたトラストを評価することにある。 ERATOSTHENESプロジェクト
ここから分かるのは、トラストを「初回ログイン時の認証」だけで済ませてはいけないということである。状態は時間とともに変わる。AI、IoT、クラウド、外部APIが連携するほど、信頼性も継続的に評価する必要がある。
AIエージェントで確認すべき対象は、モデルだけではない
AIエージェントのトラスト設計では、モデルの安全性評価だけに注目すると不十分である。実際に業務上の影響を生むのは、モデルとその周辺の構成全体だからである。
| 対象 | 確認すべきこと | 代表的な証跡 |
|---|---|---|
| 利用者 | 誰が依頼し、何を許可されているか | 認証、役割、承認履歴 |
| AIエージェント | 所有者、目的、版、利用期間は明確か | エージェント台帳、設定差分 |
| モデル | どの提供者・版・リージョンを使ったか | モデル設定、利用記録 |
| ナレッジ | 正式情報か、権限外情報を含まないか | 出典、版、更新日、アクセス制御 |
| ツール | どのAPIをどの権限で使うか | スコープ、トークン、呼び出しログ |
| 実行環境 | 承認済みコード・設定で動いているか | ビルド証明、構成情報、アテステーション |
| 判断・実行 | なぜその処理を選び、何を変更したか | トレース、入力、出力、承認、結果 |
AIが「正しい答え」を出したかだけでは足りない。誰の権限で、どのデータを参照し、どのツールを実行し、何を変更したかを追跡できる必要がある。
特に書き込み操作や外部送信を伴うエージェントでは、モデルの推論品質よりも、権限設計と実行証跡が事故の影響を大きく左右する。
「検証できる」は、人間が毎回すべてを確認することではない
Verify meという考え方は、すべての利用者に高度なセキュリティ判断を求めることではない。
人間が毎回、モデルの挙動、署名、設定、ログを手作業で確認する運用は現実的ではない。検証は可能な限り自動化し、リスクが高い処理だけを人間が判断できる形にする必要がある。
たとえば、次のように分けられる。
| 処理 | 基本方針 |
|---|---|
| 社内文書の要約 | 権限付き検索、出典表示、ログ保存を自動化する |
| 顧客への回答案 | 根拠と適用条件を表示し、人間が最終送信する |
| CRMの更新案 | AIは下書きまで、人間の承認後に更新する |
| 低額・可逆な定型処理 | 条件、上限、対象を限定して自動実行する |
| 契約変更、高額発注、医療・安全に関わる処理 | 強い本人確認、複数承認、実行前検証を必須にする |
重要なのは、承認ボタンを置くだけではない。承認者に、AIが何をしようとしているか、根拠は何か、影響はどこまでか、元に戻せるかを示すことである。
IT部門が作るべきなのは、AIを信用する仕組みではなく、信用を限定できる仕組み
AI時代のIT部門は、「安全なモデルを一つ選ぶ」だけでは役割を果たせない。
必要なのは、複数のAI、データ、ツール、利用者が接続される環境で、信頼の範囲を制御できる共通基盤である。
利用者・業務イベント
↓
認証・役割・依頼目的の確認
↓
エージェントの目的・版・ポリシー確認
↓
権限付きデータ検索 ／ モデル推論
↓
ツール実行前の入力検証・最小権限・承認
↓
業務システムの読取り／更新
↓
トレース・証跡・異常検知・監査
↓
評価・権限見直し・停止・廃止
この構造で重要なのは、どの層にも「無条件に信じる」場所を作らないことだ。
- データは出典、鮮度、権限を確認する
- エージェントは所有者、目的、有効期限を持つ
- ツールは読み取りと書き込みを分離する
- 高リスク操作には人間承認や金額上限を置く
- すべての重要な判断と実行を追跡できるようにする
- 異常が起きたときは権限を止め、影響範囲を復元できるようにする
トラストは「全幅の信頼」を与えることではない。条件付きで利用を許し、根拠を確認し、必要なら直ちに縮小・停止できることにある。
デジタルトラスト導入の実装チェックリスト
| 観点 | 確認すること |
|---|---|
| 対象の特定 | 人、組織、AI、端末、データ、ツールのどれを信頼判断の対象にするか |
| 信頼目的 | 閲覧、送信、更新、発注、制御など、何を許可するための判断か |
| 根拠 | アイデンティティ、署名、構成、出典、評価結果、監査ログを取得できるか |
| 鮮度 | 過去の証明ではなく、現在の状態を確認できるか |
| ポリシー | どの状態なら許可・制限・拒否するかを定義したか |
| 最小権限 | AI、ツール、利用者それぞれの権限を必要最小限にできているか |
| 説明可能性 | 承認者・監査担当者が、判断と実行の根拠を確認できるか |
| 継続監視 | モデル、データ、ソフトウェア、権限の変更を検知できるか |
| 例外対応 | 誤判定、障害、侵害時に停止・復旧・通知できるか |
| 制度・責任 | 所有者、承認者、監査者、苦情・救済の窓口を決めているか |
まとめ：信頼は、主張ではなく検証と運用で作られる
AI時代には、人間とシステム、システムとシステムが、これまで以上に多くの判断を委ね合う。そのとき、相手が「安全です」「正しいです」と言うだけでは、安心して利用できない。
必要なのは、信頼する側と信頼される対象を分け、トラストワージネスを客観的に評価し、利用の範囲を条件付きで制御する仕組みである。
リモートアテステーション、アイデンティティ、電子署名、アクセス制御、監査ログ、継続監視は、それぞれ独立したセキュリティ機能ではない。AIやIoTが業務を実行する社会で、誰が、何を、どの根拠で信頼できるのかを示すための部品である。
AIエージェントの導入で最後に問われるのは、モデルの性能だけではない。
- どの状態なら実行を許すのか
- どのデータとツールへ接続させるのか
- 誰が判断に責任を持つのか
- 何が変わったら信頼を見直すのか
- 問題が起きたとき、どう止め、どう説明し、どう回復するのか
これらを技術と制度の両面から設計することが、AI社会におけるデジタルトラストの実装になる。
「Trust me」ではなく「Verify me」。
その転換は、AIを疑い続けるためのものではない。人間が過度な注意力や専門知識を毎回使わなくても、安心してAIとデジタルサービスを利用できる社会を作るための前提である。
作成日：2026年7月23日