先日、自社の経理まわりを眺めていて、ふと手が止まった。
毎月、決まったタイミングで決済システムにログインし、取引明細を書き出す。そのファイルをAIに読ませて、分類させたり、集計させたり、気になる支出に目を通したりする。地味だが、月次で必ず発生する作業だ。これを、なぜ人間がやっているのだろう、と思った。
だったら、AIエージェントに決済システムへログインしてもらい、必要な月の明細を取得して、そのまま作業まで任せればいい。そう考えて——そしてもう一度、手が止まった。エージェントに、自分のアカウントを、まるごと使わせる。そのことに、はっきりと抵抗を感じたからだ。
この「便利そうだが、なんとなく怖い」という感覚は、これからAIエージェントに業務を任せようとするすべての会社が、遅かれ早かれ突き当たる。今日はこの抵抗感の正体を分解し、では何が正しい設計なのかを、自社の現物と、つい先日この国で起きた事故を手がかりに考えてみたい。
先に、この記事の結論を書いておく。エージェントに「自分の代わりにログインさせる」のは、やめたほうがいい。代わりに、何を・どこまでやってよいかを絞って「委ねる」。自分のログインを丸ごと預ける（合鍵を渡す）のと、用件を限った許可を一枚だけ渡す（委任状を書く）のとでは、似ているようで、起きることがまるで違う。これは単に便利かどうかではなく、「会社の鍵束を、誰に、どう預けるか」という、組織のリスク設計の話だ。
「ログインさせる」は、いちばん危ない一手だった
素朴に考えれば、答えは単純だ。エージェントに決済システムの画面を開かせ、IDとパスワードでログインさせ、明細をダウンロードさせればいい。人間がやっていることを、そのまま代わりにやってもらう。
だが、これは数ある選択肢のなかで、おそらく最も危ない一手だ。
いま「エージェントにブラウザを操作させる」タイプのツールが各社から出ている。これらは、あなたがログイン済みのブラウザを、そのまま運転する。便利な反面、エージェントはあなたが開いているすべてのサイトの権限を、まるごと引き継ぐ。明細を取るだけのつもりでも、同じブラウザにログインしている銀行も、メールも、社内システムも、原理上は同じ手が届く範囲に入る。そして、いったんセッションがログイン済みになってしまえば、本来強力な防御である二段階認証も、多くの場合、もう関所として働かない。すでに通り抜けたあとだからだ。
さらに厄介なのは、この種のエージェントに根本的な弱点が残っていることだ。Webページやメールのなかに「こう動け」という指示を仕込んでおくと、エージェントがそれを本物の指示と取り違えて従ってしまう——プロンプトインジェクションと呼ばれるこの問題は、ツールを出している当のAI企業自身が、当面なくならないと認めている。広い権限を持ったエージェントが、信頼できない外部からの指示を読んで実行してしまう。従来のセキュリティが想定してきた「悪意あるコードを締め出す」とは、向きが逆の脅威だ。
つまり「エージェントに管理画面でログインさせる」とは、自分の鍵束をまるごと手渡し、しかもその相手が、外から囁かれた声に従ってしまうかもしれない、という状態を作ることだ。私が感じた抵抗は、気のせいではなかった。むしろ、正しい警戒だった。
正しい問いは「どう委任し、どう紐づくか」
ここで問いを立て直す。「エージェントにどうログインさせるか」ではない。「エージェントに、どこまでの権限を、どう委ねるか。そしてその権限は、人間である自分と、どう結びつくのか」だ。なりすまし（impersonation）から、委任（delegation）へ。視点を切り替える。
図：合鍵モデルと委任状モデル。左の「合鍵モデル」は、エージェントに自分のログインをそのまま渡す方式で、明細を取るだけのつもりでも銀行・メール・社内システムまで同じ手が届き、取り消すにはすべての鍵を変えるしかない。右の「委任状モデル」は、エージェントに会計データの読み取りだけを許す一枚の許可証を渡す方式で、扉は一つに限られ、許可はいつでもその一枚だけを取り消せる。後ろには、許可を出し、いつでも引き取れる人間が立っている。
二つのモデルの違いは、突き詰めると「秘密（ログイン情報）を誰が持つか」と「権限をいつでも取り消せるか」に尽きる。合鍵モデルでは、エージェントがあなたの生のログインを握り、すべての扉が開き、取り消すには全部のパスワードを変えるしかない。委任状モデルでは、エージェントは生のログインを持たず、絞られた一枚の許可証だけを持ち、その許可証はいつでも、その一枚だけを取り消せる。後ろには、許可を出した人間が立っている。
では、その「許可証」は、どうやって「私のもの」として発行され、私と結びつくのか。ここが、いまの業界がまだ一本化できていない部分で、現状大きく三つの結びつけ方が並走している。
| 結びつけ方 | どう紐づくか | 秘密（資格情報）を持つのは | いまの代表例 |
|---|---|---|---|
| A：委任トークン | エージェントは口座を持たず、本人から派生した短命・スコープ限定のトークンを持つ。紐づきはトークンの中にある | 誰も生資格を持たない（トークンは短命） | ID-JAG／OAuthの代理権限、MCPの企業向け認可 |
| B：エージェント専用アカウント | エージェントが自前の資格を持ち、「本人に許可された」という関係が別途記録される | エージェントが自分の資格を持つ（人間の生資格は渡さない） | auth.md（WorkOS）の登録、Non-Human Identity |
| C：仲介者経由 | 信頼する仲介者が対象との接続を保持し、エージェントは仲介者とだけ話す。紐づきは仲介者が持つ | 仲介者が接続を持つ（理想は生PWでなくトークン） | 会計SaaS・口座連携（電子決済等代行業）、Token Vault |
簡単に補足する。Aは、エージェントに常設の「口座」を作らず、あなたの本人性から派生した短命の許可証だけを渡す方式だ。紐づきは許可証そのものの中にあり、取り消しは発行元で一度切れば済む。Bは、エージェントに自前のアカウントを持たせ、「これは○○さんに許可されたエージェントだ」という関係を別に記録する方式で、冒頭で私がイメージした「エージェント専用に発行するアカウント」はこれにあたる。auth.md のようなプロトコルは、サービス側がこのB型の委任口を標準手順で発行できるようにする試みだ。Cは、信頼する仲介者に対象との接続を預け、エージェントは仲介者とだけ話す方式。日本の金融分野では、これがすでに「口座連携」として実装済みになっている。
この三つを踏まえると、冒頭の私の発想——「決済システムにログインさせる」——の何がずれていたかが見える。私は紐づけの相手を「決済システム」そのものに置いていた。だが、消費者向けの決済システムが、エージェント専用の委任口（B）を自前で用意している例は、いまのところほとんどない。それを待つなら「今はできない」になってしまう。正しい相手は、すでに決済システムと繋がっている「仲介者」——会計SaaS（C）だ。主語が、決済システムから仲介者へ移る。そしてこの仲介者が、自分の側でエージェント用の委任口（実質B）を開けているなら、話は一気に現実になる。
現実解は「会計SaaSのMCP」 — freeeとマネーフォワード
抽象論を、いま手が届く道具に落とす。
クラウド会計の二大サービスは、すでにエージェント向けの口を開けている。freeeは2026年3月に、AIエージェントから自社APIを操作できるMCPサーバーをオープンソースで公開し、OAuthベースのセキュアな認証フローを備えている。マネーフォワードも、2025年10月のβを経て、2026年3月26日にクラウド会計のリモートMCPサーバーを全プランで公開した。マネーフォワードのものはリモート型で、Claude DesktopやClaude Code、Cursorといった主要なAIツールから接続設定だけで使える（freeeのものは、自前の環境に立てて使うオープンソース型だ）。マネーフォワードはさらに、Claudeの技術基盤を組み込んだ自律実行サービス「AI Cowork」を2026年7月に提供する予定だと公表している。
図にすると、つなぎは二本あって、性質が違う。①決済システムと会計SaaSのあいだは、あなたが画面で一度「連携を承認する」だけだ。その先は会計SaaSが——多くは生のログインIDやパスワードを保存しない形で——明細を取り込む。②会計SaaSとエージェントのあいだは、会計SaaSが発行するスコープ付きの資格（OAuth／MCP）で繋ぐ。そして後ろには人間が立ち、承認も、設定も、取り消しも握っている。
この構成のいいところは、危ない一手を完全に避けられる点にある。エージェントが認証付きで叩くのは、決済システムではなく会計SaaSのAPIだ。エージェントは決済システムの管理画面にログインしないし、生の資格情報にも触れない。冒頭の私の抵抗感は、この構成では、そもそも発生しない。しかも、エージェントに渡す権限は「読むだけ」に絞れる。参照系の操作だけを許し、データを書き換える操作は外しておけば、エージェントは明細を読んで作業に使うが、勝手に帳簿を書き換えることはできない。権限は、必要な分だけ、縮める方向で。
誠実な但し書きを一つ。現時点でのMCPの守備範囲は、仕訳の参照・登録や、残高試算表・推移表の参照といった「会計データ」が中心で、生の取引明細そのものの操作や、部門別集計表のようなレポートの拡張は、まだこれから順次という段階だ（マネーフォワードは、認証の有効期限の延長や再認証の自動化も進めるとしている）。だから「特定の月の明細CSVを丸ごと落とす」という素朴なイメージそのままではなく、「取り込まれ整理されたデータを、構造化された形で読む」になる。目的——明細を自動で取得して作業に回す——は果たせるが、入口の形は少し変わる。ここは発行時点の対応状況を確かめてから設計したい。
だが、集約には別の罠がある — マネーフォワードGitHub事件
ここまで読むと、「では会計SaaSに繋げばいい」で話が終わりそうになる。だが、そう単純ではないことを、つい先日この国で起きた事故が教えてくれた。
マネーフォワードは2026年5月1日、ソースコード管理サービスGitHubへの不正アクセスが起きたと公表した。同社の説明によれば、個人情報を含むファイルが本来の管理手順から外れて誤ってGitHub上に置かれていたところに、認証情報の漏えいを突いた第三者がアクセスし、リポジトリがコピーされた。流出した可能性があるのは、同社のビジネスカードに関する370件分の、カード名義（アルファベット）とカード番号の下4桁。そして同社は、全社的な安全対策として、銀行口座との連携機能をいったん停止した。連携していたサービスは一斉に止まり、5月中旬から金融機関ごとに順次再開されているが、公表から1ヶ月あまりが経った本稿執筆時点でも、すべての連携が元どおりに戻ったという告知には至っていない。
この事故から何を学ぶかが、実は今日のいちばん大事なところだ。一見すると「便利な集約サービスに頼ると、まとめて巻き添えを食う」という教訓に見える。それも一面では正しい。だが、もう少し丁寧に分解したい。
| 割れたもの（流出の可能性が公表された） | 守られたもの（流出は確認されていない、と公表） |
|---|---|
| GitHubの認証情報 | カード番号の全桁 |
| ソースコード | 有効期限・セキュリティコード（CVV） |
| ビジネスカード370件（氏名のアルファベットと下4桁） | 金融機関等との連携に使うログイン情報 |
表の右側——とくに最後の一行に注目してほしい。今回、カード番号の全桁も、有効期限も、セキュリティコードも、そして金融機関等との連携に使うログイン情報も、流出は確認されていないと公表されている。つまり、最も守るべき「連携の鍵束」は、割れなかった。理由は、突き詰めれば「置き場所」と「持ち方」の二つだ。破られたのはGitHub——ソースコードの置き場——であり、公表を素直に読む限り、連携の鍵束はそこには置かれていなかった。秘密をコードの置き場に持ち込まない分離が、まず被害の上限を画した。そしてもう一段深い構えとして、銀行口座とのAPI連携のようにトークンで繋ぐ方式では、そもそも事業者が利用者の生のパスワードを預からない。持っていないものは、どこが破られても漏れようがない。前節の「生の資格情報を渡さない」という原則を、預かる側から言い直せば「生の資格情報を持たない」——それが、連携の鍵束を守る構えとして、ここで効いている。
そう見ると、今回の事故は二つの別々の問題に分かれる。一つは、秘密（個人情報を含むファイル）を、置いてはいけない場所に置いてしまったという人為的なミス。これは集約か分散かと関係なく、自前で運用していても、誰の手元でも起こりうる失敗だ。むしろここで効くのは「そもそも生の秘密を持たない設計」のほうだ。もう一つは、一箇所が止まると、繋がっていた全員が同時に止まるという、集約の構造的な弱点だ。
ここで、「だったら分散したほうが安全では」という直感に向き合いたい。その直感の核は正しい。ただし、その手段を一つ間違えると、逆効果になる。「分散」を「個人個人が管理画面にエージェントでログインして、自分の環境で作業する」と読んでしまうと、最初の節で見たセッション継承とプロンプトインジェクションのリスクが、今度は各個人の端末に分散して増殖する。集約点の事故は派手で目立つが、分散した個人運用の事故は、見えないだけで、総量はむしろ増えうる。分散すれば安全、ではないのだ。
正しい分散は、もっと地味な三つだ。ひとつ、信頼を一箇所に集めきらず、複数の経路とフォールバックを持つこと。ふたつ、取り込んだ明細を自分の手元にも退避しておき、ベンダーが止まっても作業を続けられるようにすること。みっつ、そして何より、たとえ集約点が破られても連携の鍵が守られるよう、生の秘密を持たない委任で繋ぐこと。マネーフォワードの一件は、置き場所の分離が人為ミスで破れうることと、それでも「持たない」設計なら漏れる物自体が存在しないことを、同時に教えてくれた。
企業が、いまから準備すべきこと — 「使われる側」と「使う側」
ここまでは自社の話だったが、私たちのようにコミュニケーションをデザインする立場は、これを顧客企業に翻訳して伝える役目を負っている。クライアントが時代の変化から取り残されないように。クライアントと話すとき、私は立場を二つに分けて整理することにしている。
| 立場 | 準備すべきこと（要点） |
|---|---|
| 「使われる側」 （自社のサービス・データを持つ） |
構造化データで機械にも読める状態に整える エージェント用の委任口を用意する（いまはOAuth・MCP、将来は auth.md・ID-JAG のような標準） 最小権限・取り消し・監査を備える |
| 「使う側」 （エージェントに業務を任せる） |
特定ベンダーへの集中リスクを評価する 生の秘密を持たない設計を選ぶ 障害ドメインを分け、取り込んだデータは自前にも退避 データを書き換える操作には人間の承認を挟む |
ひとつは、「エージェントに使われる側」としての準備だ。自社のサービスやデータを、人間が見る画面だけでなく、エージェントが安全に読める・操作できる状態に整えておく。これは、私がかねて構造化データの連載で書いてきた話の延長線上にある。まず構造化データで機械可読にし、エージェント用の委任口を用意し、最小権限・取り消し・監査を備える。当社のAIエージェント互換性診断も、突き詰めればこの「使われる側の準備が、いま何点に見えているか」を測る道具だ。
もうひとつは、「エージェントを使う側」としての準備だ。今回のマネーフォワードの一件が、そのままの教材になる。便利だから繋ぐ、の前に、止まったらどうなるか、破られたら鍵束は守られるかを問う。特定のベンダーに集中しすぎていないかを評価し、生の秘密を持たない設計を選び、障害ドメインを分け、取り込んだデータは自前にも退避し、データを書き換える操作には必ず人間の承認を挟む。
この二つを貫く一本の背骨は、結局「自分たちが何者で、何を、誰にどこまで渡すのかを、曖昧さなく差し出す」ことだ。それは、私がかねて書いてきた「伝える」という仕事の、認証と委任という側面での現れにすぎない。新しい技術の話に見えて、やっていることはそれほど新しくない。
「ログインさせる」から「委任する」へ — 主権は、人間に
最後に、視点を一段引いて、この先どこへ向かうのかを書いておく。正直に言えば、何が最終的なベストの形かは、まだ誰にも断言できない。だが、方向は見えている。
当面の現実解は、いま見たように、会計SaaSのような「足場の良い仲介者」のMCPに繋ぐこと（C）だ。その先、各サービスが自前でエージェント用の委任口を発行する世界（B）が、標準の固まった領域から、まだらに広がっていく。表面では auth.md だ ID-JAG だと旗印が乱立して見えるが、その下の信頼の根は、少しずつ共通の標準へ収束しつつある。
そして、私がこの先の設計でいちばん大事にしたいのは、こういう形だ。
信頼の根は共通の標準に預け、実行と保持は、自分の手元に置く。
エージェントにどれだけ業務を委ねても、最終的な主権——何を許し、何を取り消し、どこで止めるか——は、人間の側に残す。これは、集約の単一障害点も、分散の増殖リスクも、両方を避けるための中間解であり、同時に、私がもう一つの場所で考え続けている「人間の自律的な意思決定を手放さない」という主題と、技術のレイヤーで静かに響き合っている。
技術の話をしてきたつもりが、最後はまた、伝えることと、主権の話になった。自分たちが何者で、何を、誰にどこまで委ねるのかを、曖昧さなく差し出し、いつでも引き取れるようにしておく。合鍵を渡すのではなく、委任状を書く——そしてその委任状は、いつでも自分の手で破れる場所に置いておく。AIエージェントに業務を任せるとは、本来そういうことなのだと思う。
参照情報
auth.md（WorkOS） — AIエージェントによるユーザー登録を標準化する、提案段階の新しいオープンプロトコル。本稿のB型（エージェント専用アカウントの発行）の説明の出典。
Cross App Access (XAA)（Auth0 Docs） — ID-JAG（Identity Assertion JWT Authorization Grant）を使い、企業IdPを介してアプリ間の権限を委任する仕組みの解説。本稿のA型（委任トークン）の代表例の出典。
freee-mcp（freee公式・GitHub） — freee APIをAIエージェントから操作するMCPサーバー（OSS）。OAuthベースの認証フローを備える。
『マネーフォワード クラウド会計』、AIエージェントと連携可能な「MCPサーバー」β版を提供開始（2025-10-03）
マネーフォワード クラウド会計・確定申告でAPIとMCPサーバーの提供を開始しました（公式サポート・2026-03-26）
『GitHub』への不正アクセスに関する調査進捗および銀行口座連携再開に向けた経過のご報告（第二報・2026-05-11）
『GitHub』への不正アクセス発生および銀行口座連携機能の一時停止に関するお知らせ（『マネーフォワード ME』サポート・2026-06-09更新）
関連（unType）：エージェンティックWebの完全スタック — MCP・WebMCP・NLWeb・llms.txtの統合戦略
この記事をシェアする
