エージェンティックAI時代に求められるKYA（Know Your Agent）

KYAとは、顧客IDによる入口の確認だけに頼らず、ログイン後の取引を、どのAIエージェントの行為として扱うのかを見直すための考え方です。
従来のKYCやpKYC（perpetual Know Your Customer）が「この人は誰か」「この人の状態や行動は今どうか」という、顧客本人に焦点を当てた枠組みだったのに対して、KYAは「この操作を実際に行ったのは誰か（どのエージェントか）」まで含めて説明できるようにすることを目的とします。
そのイメージを整理したのが、次の表です。

表: KYC・pKYC・KYAの枠組み比較

まず「管理対象」を見ると、KYCとpKYCが顧客本人（人・法人）の状態や行動を対象にしているのに対し、KYAは顧客の代理で動くAIエージェントそのものを対象にしています。
「確認内容」も、KYCが「この人は誰か」、pKYCが「今この人は安全か」という顧客本人への問いであるのに対し、KYAでは「この操作は誰（何）の行為か」へと変わります。操作の主体がどこにあるかを問う点が、従来の枠組みとの大きな違いです。
「確認のタイミング」については、KYCが取引開始時・口座開設時、pKYCが取引中・継続的に確認を行うのに対し、KYAはログイン後・実行時、つまり実際に操作が行われる瞬間を捉えます。
「管理単位」では、KYCが顧客・口座、pKYCが顧客×取引という単位で管理するのに対し、KYAは顧客×チャネル／エージェント×ワークフローという単位まで細かく分解します。
そして「可能になること」として、KYCは本人確認と入口の信頼確保、pKYCは異常検知と取引中の行動に応じたリスク判断の見直しを担うのに対し、KYAはAIが正規の代理として動いているのか、なりすましなのかを判別することを可能にします。

KYAの肝は、ログイン後の取引を“顧客IDだけ”で一括管理しない点にあります。取引を『顧客×操作経路（画面・API）×操作主体（人・社内自動化・外部AI）×業務（振込・照会など）』に分解し、単位ごとにルールを変えます。例えば同じ顧客でも、本人がアプリで振り込む場合と、外部AIがAPIで振込を試みる場合では、想定すべき不正リスクも、許容できる上限も異なります。そのため、KYAを通じ“誰が何をしたか”を先に識別・記録し、その結果に応じて上限、追加認証、意図確認を出し分けることになります。

生活者は、どの金融アプリを開くか、どの手段で支払うかといった判断を次第にAIに委ね始めています。利用者が意識するのは、どの金融機関を使ったかではなく、意図どおりに動いたかどうかです。金融機関や決済手段は、画面の前面からは姿を消し、AIエージェントの背後で動く基盤として扱われる場面が増えていきます。
企業側の接点も変わります。これまでの窓口やアプリといった人の操作を前提とした接点に加え、外部のAIエージェントやボット、社内の自動化（RPAや社内AIなど）がAPIを通じて直接アクセスしてくる構図が当たり前になっていきます。外から見れば同じAPIリクエストに見えても、その中身は一様ではありません。正規の代理として動く主体もあれば、正規の主体に見せかけた不正アクセスも混在し得ます。
問題は、これらを区別しない限り、正当な代理行為と不正行為が同じ前提で処理されやすい点にあります。チャネルが人からAIやAPIへ移ることで、取引の実行主体が見えにくくなります。「この操作は誰の代理として行われたものか」という問いを避けたままでは、リスクを適切に管理しにくくなります。KYAは、この見えにくくなった実行主体を整理し、AI経由の取引を前提とした管理へ移行するための軸になります。
本稿では、KYAの実装を「自社内で土台を作る段階」と「外部も含めて信用を再利用する段階」の二段階で整理します。

第一段階は、自社の範囲の中でKYAを実装し、ログイン後の操作について「誰の手によるものか」を分解して記録し、ルートごとに実行権限を出し分ける取り組みです。これはpKYCやAML、不正対策と同じく、リスク管理の延長として進められます。どの操作を、どの条件で委任するかを明確にし、その範囲外はブロックや追加確認の対象にする設計が必要です。
要点は「ルート分類→権限→ログ→制限」の順で最小構成を作ることです。
　・ 要点：顧客IDだけではなく、実行主体と処理単位を分解して扱います。
　・ 具体：人の画面操作、社内RPAの定期処理、外部エージェントのAPIリクエストなどを切り分け、主体ごとに識別子・設定・権限スコープ・行動履歴を持たせます。
　　　・人の操作：従来どおりの上限や追加認証で処理します。
　　　・社内自動化：金融機関内部で動くRPAや社内AIなどを指し、社内だから無条件に信頼するのではなく、権限スコープと監査可能性を前提に、一定範囲で自動処理を許容します。
　・外部AIエージェント：金額・回数制限を強め、意図確認や多要素認証を厚めにかけます。
　・注意点（前提/限界）：分類粒度は最初から完璧を狙わず、高リスク取引や影響範囲の大きいワークフローから始める選択肢もあります。追加認証をどこにかけるかは顧客体験にも直結するため、追加認証や確認をどのタイミングで求めるか所を意図して設計する必要があります。
この段階で目指すのは、主体ごとの「通常パターン」を持ち、そこからの崩れを検知できる状態を作ることです。まったく新しい発想というより、ログイン後の世界にも継続トラストを拡張するアップデートとして捉えると導入しやすくなります。

第二段階は、第一段階で得た「このエージェントは信用できる／できない」という見立てを、自社の外でも参照できる形に広げる取り組みです。金融取引は事業者や決済レールをまたいで成立するため、個社の中だけで最適化してもどこかで限界が生じやすくなります。その限界が表面化するのは、取引の入口がアプリや画面から、エージェントや外部のプロトコルへ移るタイミングです。入口が分散すると、ある事業者が持つログや判定だけでは、取引全体として「誰が・どの権限で・何を実行したか」を揃えて説明しにくくなります。だからこそ、事業者をまたいでも参照できる検証の仕組み、言い換えれば“共通レイヤー”が必要になります。
その兆候として、小売領域ではGoogleが、AIエージェントを介した購買を事業者横断で成立させるための共通枠組みとして「Universal Commerce Protocol（UCP）」を発表しています。ここで重要なのは、個々の事業者が個別に最適化するのではなく、事業者をまたいだ接続・検証を前提にした設計が議論の中心に上がってきた点です。この仕組みの要点は「回避行動への強さ」です。ある事業者では不審と判断された主体が、別の事業者では「初めて見る相手」として高い限度で受け入れられてしまう、といったズレが起き得ます。個社最適の延長だけでは、このズレを埋めにくいのが第二段階の出発点です。

　・要点：検証に必要な最小限の情報を共有できるようにし、事業者間のギャップを減らします。
　・具体：主体ごとにトークンやパスポートのような検証手段を用意し、必要に応じて検証情報を照会できる仕組みを整えるイメージです。照会の対象は、IDそのものではなく、リスク評価のシグナルや必要最小限の属性・評価結果に寄せます。これが機能すれば、クリーンな履歴を積み重ねた主体は別の事業者でも一定の信用として扱いやすくなり、逆に不審と判断された主体は早い段階から注意対象として認識されやすくなります。
加えて、UCPのように事業者横断の接続が前提になるほど、「どの主体が、どの権限で、どの取引を実行したのか」を横断で確かめる必要が高まります。結果として、検証情報を必要最小限で参照できる仕組みが、取引インフラ側の要件として前に出てきます。
　・注意点（前提/限界）：共有は個人情報を事業者間で広く共有する話ではありません。検証に必要な最小限の情報に絞ることが前提です。また、「誰が責任を持って説明するか」」、「誤った判定を受けた場合にどう申し立てるか」、「システムが止まらないようにどう設計するか」、といったルールや体制が整っていなければ、仕組みとして機能しません。まずは情報を受け取る側として参加し、第一段階で整えた分類とログを土台にしながら、段階的に関与を深める選択肢もあります。

ここまで見てきたように、KYAは一つの機能というより、取引と信用の捉え方を見直す取り組みと言えます。そのため、実装に進むにあたり、少なくとも次の三つの問いに答える必要があります。

　・ 取引をどこまで細かい単位で管理するか
顧客単位のリスク管理を中心に据えるのか、顧客×チャネル／エージェント×ワークフロー単位でログとルールを持つのかを決めます。後者は運用負荷が増えますが、ルート別の制御が可能になります。
　・外部とどのレイヤーで接続する前提で設計するか
第二段階で外部と連携することを見据えるなら、自社のデータや記録をどう整理しておくかが問われます。特定のプラットフォームやクラウドの仕組みに合わせて設計を固めてしまうと、後から別の仕組みへ切り替えようとした際にコストがかかります。どこまでを自社で持ち、どこから外部に接続するかを、早い段階で大まかに決めておくことが重要です。
　・ネットワークの中でどの立ち位置を取るか
事業者をまたいだ仕組みの中で、自社はどう関わるかを整理する必要があります。他社が発行した検証情報を「受け取る側」として活用するだけなのか、自社が判断した評価を「提供する側」として外部にも共有するのかで、関与の深さが変わります。受け取る側にとどまる場合、他社が積み上げた判断を自社の審査に活かせるため、不正の早期察知や審査の効率化といった実務上のメリットが得やすくなります。一方、提供する側として関わる場合は、業界全体の信用の仕組みそのものを形作る立場に踏み込むことになります。

KYAはチェック項目を増やす話ではありません。信用の単位を人から代理主体を含むものへ広げ、どこまでを委ねるのかを整理する設計の話です。まず自社内で「どの主体に、どの業務を、どこまで任せるか」を決め、次にその見立てを自社の中に閉じるのか、外部とも参照できる形へ進めるのかを選びます。
次の一手は三つです。
　・取引ルートとワークフローの分類を整理（人操作／社内自動化／外部APIを起点に、主要処理を棚卸しします）。
　・ルート別の制御方針を仮決め（上限・追加認証・回数制限・意図確認を、操作の主体ごとに暫定的な基準を設けます）。
　・監査可能性の最小要件を定義（主体の識別、権限スコープ、実行した処理単位、異常発生時の追跡方法を合意します）。
この三点を押さえることで、KYAは将来の理想論ではなく、今日の取引を前提にした現実の取り組みとして動き始めます。AIの進化は、私たちの想定を超えるスピードで進んでいます。その波に備えるためにも、できるところから一歩を踏み出すことが求められています。