お問い合わせ
2026 / 08 / 03 セキュリティ

税理士・弁護士事務所の外部連携への依存は、他社の話ではない — 士業事務所のAI活用に潜む構造的リスク

Lead

会計クラウド事業者の不正アクセス事案を起点に、外部API・OAuth連携への依存リスクが RAG・AIエージェント・SSO統合の広がる税理士・弁護士・監査法人事務所でなぜ拡大するのかを構造から分析し、自事務所の依存関係を点検する入り口を整理します。

結論: 外部API・OAuth連携に依存するシステムであれば、それがどの組織であっても、連携先や認証情報にまつわる問題がそのまま自社の障害・情報漏えいにつながり得るという構造を避けられません。本稿では2026年に公表された会計クラウド事業者の事案を手がかりに、この構造が税理士事務所・弁護士事務所・監査法人を含む士業事務所のAI活用にもそのまま当てはまることを整理します。

2026年、会計クラウドサービスを提供するマネーフォワードにおいて、GitHubの認証情報が漏えいし、これを用いた不正アクセスによってリポジトリがコピーされたことが公表されました。ニュースとして目にした方も多いと思います。銀行口座との連携機能が一時的に止まったことで、実際に業務への影響を体感した方もいらっしゃるかもしれません。

本稿の目的は、この事案の是非を論じることではありません。外部のAPI連携・OAuth連携・クラウドサービスに業務を依存させているシステムであれば、規模や業種を問わず起こり得る構造的なリスクとして捉え、税理士事務所・弁護士事務所・監査法人といった士業事務所自身がAI活用を進めるうえで、どこに同じ構造があるのかを点検する材料にすることを目的としています。会計クラウドのような大規模なサービスを自前で開発・運用していない事務所であっても、外部のAIツールや会計・労務クラウドとAPIやOAuthで連携している時点で、根っこの部分は同じ構造を抱えています。順を追って見ていきます。

なお、対象となったマネーフォワードは、法人・個人向けの会計・請求書発行・法人カード・給与計算といったクラウドサービスを国内で広く提供している事業者です。多くの事業者が銀行口座やクレジットカードの明細を自動で取り込む機能を日常的に使っており、今回の事案でこの口座連携機能が一時停止された影響は、直接の被害を受けた顧客以外にも、間接的に業務上の不便として広がった面があります。この規模感自体が「他社の特殊な事情」ではなく「多くの利用者が日常的に依存している機能」であったことを示していると考えられます。

何が起きたか

まず、公表されている情報だけを、時系列で整理しておきます。憶測を交えず、各社の発表内容に沿って書きます。

  • 2026年5月1日: 第一報。GitHubの認証情報が漏えいし、これを用いた第三者による不正アクセスによってリポジトリがコピーされたことが公表されました。同日、金融機関との口座連携機能が一時停止され、マネーフォワードビジネスカード保有者370件についてカード名義・カード番号下4桁の流出可能性にも言及がありました。
  • 2026年5月11日: 第二報。本番の顧客データベースからの漏えいがないことが確認され、認証キー・パスワードの無効化と再発行が完了したことが報告されました。この報告では経緯について、「決済情報を扱うサービスの更新作業の過程で、個人情報を含むファイルが本来の管理手順から外れ、誤ってGitHub上に保管されていた」と説明されています。
  • 2026年6月5日: 一時停止していた全銀行連携が再開されました。停止期間はおよそ35日間でした。
  • 2026年6月23日: 第四報。影響範囲が確定し、顧客情報124名・取引先28名・従業員2,300名・管理用の固有識別子60,449名、合計で約62,901名分に影響があったことが公表されました。クレジットカード番号の全桁、および本番の顧客データベースからの流出は確認されていない、とされています。

事後対応として、業務端末のセキュリティ統制強化、認可されていない外部サイト・クラウドサービスへのアクセス遮断、開発環境における個人情報取り扱い体制の整備、開発環境のリアルタイム監視体制の構築が進められたことも公表されています。約1か月にわたって金融機関との連携機能を止めた対応や、複数回にわたって調査の進捗を公表し続けた対応は、影響範囲を確定させるまでのプロセスとして参考にできる部分もあります。

公式に説明されている「決済情報を扱うサービスの更新作業の過程で、個人情報を含むファイルが本来の管理手順から外れ、誤ってGitHub上に保管されていた」という経緯についても、ここで補足しておきます。これは、開発・更新作業を進める過程で、本来は別の管理下に置くべきファイルが、作業用のコード管理環境に紛れ込んでしまった、という趣旨の説明です。開発環境やコード管理サービスに、意図せず個人情報や機微な情報を含むファイルが置かれてしまう状況は、規模の大小を問わず、システム開発の現場で起こり得る事象として知られています。この部分は各社が公式に説明している経緯であり、本稿ではこれ以上の推測は加えません。あくまで、GitHubの認証情報自体がどのように第三者の手に渡ったかという侵入経路だけが、非公表のまま残っている、という位置づけです。

ここで、本稿の立場をはっきりさせておきます。GitHubの認証情報自体がどのような経路で第三者の手に渡ったのか、という侵入経路については、これまでのところ公式には特定・公表されておらず、「回答を差し控える」とされています。フィッシングだったのか、内部の管理ミスだったのか、別の経路だったのかは分かっていません。本稿はこの部分を一切推測せず、公表されている事実のみを扱います。原因の特定・公表は事案の当事者と関係当局の領域であり、外部の第三者が推測で埋めてよい空白ではないと考えるためです。読み進める前提として、これ以降の内容も「侵入経路がこうだったに違いない」という前提には一切立っていないことをご了承ください。

これは特殊な事故ではなく、外部連携に依存するアーキテクチャの構造的リスクである

この事案を読んだとき、つい「その会社の管理体制の問題」として受け止めたくなります。個別の会社の対応を評価すること自体は本稿の役割ではありませんが、起きたことの構造だけを取り出すと、もう少し一般的な話が見えてきます。

現代のクラウドサービスは、単独のシステムだけで完結していることの方がまれです。開発・運用にはGitHubのようなコード管理サービスを使い、認証にはOAuthやAPIキーを使い、外部の金融機関・決済事業者・インフラ事業者とAPIで連携します。この構成そのものが、便利さと引き換えに、ひとつの前提を持ち込みます。それは、「どこか一箇所の認証情報が漏れたときに、そこから到達できる範囲がそのまま被害の範囲になる」という前提です。

今回の事案でも、影響が及んだ範囲は「GitHub」という一箇所の認証情報が到達できた範囲、つまりコードやそこに紛れ込んでいたファイルに紐づく情報でした。金融機関との口座連携機能が一時停止されたのも、連携先の安全を確認できるまでは接続を止める、という対応でした。これは、外部と連携している機能ほど、何か問題が起きたときに真っ先に止まる対象になる、という構造をそのまま表しています。逆に言えば、外部と連携していない、事業者の内側だけで完結する機能は、今回のような形で止まる理由がありません。連携している範囲の広さと、影響を受け得る範囲の広さは、多くの場合そのまま対応関係にあります。

もうひとつ言えるのは、この構造は特定の会社や特定の業界に固有のものではないということです。航空会社の予約システムが外部の決済代行会社と連携していれば、決済代行会社側の障害がそのまま自社の予約受付停止につながります。病院の電子カルテがクラウドバックアップサービスと連携していれば、バックアップ先の障害がそのまま診療記録の参照障害につながります。小売業のECサイトが外部の物流管理APIと連携していれば、物流会社側のシステム障害がそのまま自社の出荷遅延として顧客に届きます。外部のAPIやOAuth連携に依存して業務システムを組んでいる組織であれば、規模の大小を問わず、連携先や認証情報のどこかに問題が生じた瞬間に、自社のサービスが止まったり、意図しない情報が外部に渡ったりする可能性を、常に抱えています。士業事務所も例外ではありません。

この構造をもう少し分解すると、「外部に依存する範囲」と「自社が直接コントロールできる範囲」の境界線をどこに引くか、という設計判断に行き着きます。境界線を広く取れば取るほど、自社では制御しきれない要因が業務に影響する可能性が増えます。逆に、すべてを自前で抱え込もうとすれば、コストと専門性の負担が跳ね上がります。多くの組織は、この二つの間のどこかに現実的な落としどころを見つけて運用しています。今回の事案は、その落としどころの選び方そのものを否定するものではなく、「外部に依存している部分がある限り、そこにリスクも同居している」という当たり前の事実を、改めて可視化した出来事として読むことができます。

税理士・弁護士事務所のAI活用は、この構造と無関係だろうか

ここまで読んで、「うちは会計クラウド事業者のような大規模システムを作っていないから関係ない」と考えるのは、少し早いかもしれません。士業事務所がAIやクラウドサービスを業務に組み込むとき、実は同じ構造の依存関係を、すでにいくつも抱えていることが多いからです。

たとえば、次のような連携は多くの事務所で日常的に使われています。

  • 会計ソフト・労務クラウドとのAPI連携で、顧問先の仕訳データや給与データ、社会保険関連の情報をOAuth経由で取得・登録している
  • ChatGPTやClaude、Copilotなどの法人向けAIツールを、SSO(シングルサインオン)で全職員がひとつのIDプロバイダ経由で使っている
  • 議事録AIやRAG(検索拡張生成)基盤が、Google DriveやSharePoint上の顧問先資料・契約書・相談履歴に読み取り権限を持って接続している
  • 記帳代行やIT保守、給与計算代行を委託している外部ベンダーに、管理画面やクラウドストレージへのアクセス権限を渡している

これらはどれも、業務を効率化するために意図的に組んだ連携です。士業ごとに、その先にある情報の性質は変わってきます。

税理士事務所であれば、顧問先の仕訳データ・売上明細・給与情報が、会計クラウドとAIツールの連携の先に存在します。仕訳の自動取り込みや、AIによる経費精査を効率化するほど、その連携が扱えるデータの範囲は広がっていきます。社会保険労務士事務所であれば、マイナンバー・給与・社会保険加入状況といった、機微度の高い個人情報が労務クラウドに集約されており、そこにAIの議事録要約や相談履歴の検索機能を接続する場面が増えています。弁護士事務所であれば、係属中の案件資料・依頼者との相談記録・証拠資料が、AIリサーチツールやクラウドストレージとの連携の先に置かれることになります。行政書士・司法書士の事務所でも、本人確認書類や申請書類をクラウドで管理し、AIに下書きを作らせる場面が増えてきています。

どの士業であっても共通しているのは、「その認証情報やアクセス権限が及ぶ範囲」がそのまま、何か問題が起きたときの影響範囲になる、という構造です。扱う情報の性質が違っても、依存関係の形そのものは変わりません。

ひとつ、仮想的な例で考えてみます。ある事務所で、労務クラウドとAI議事録ツールをAPIで連携させ、開発・保守を委託先エンジニアのアカウントに任せていたとします。このアカウントの認証情報が何らかの形で外部に渡ってしまった場合、労務クラウド側のデータが閲覧・取得される可能性が生まれます。これは特定の事務所の実話ではなく、典型的な仮想ケースとして提示しているものですが、構造としては今回の事案とほとんど同じです。「連携している外部サービス」「認証情報を扱う担当者」「その認証情報が到達できる範囲」という3つの要素が揃えば、規模の大小に関わらず同種の事象は起こり得ます。

つまり、この事案を「他社で起きた特別な出来事」として消費してしまうと、自分たちがすでに抱えている同種の依存関係を点検する機会を逃してしまいます。読むべきは「何が悪かったか」ではなく、「自分たちの事務所にも同じ構造があるかどうか」ではないでしょうか。

規模の小さい個人事務所であっても、この構造から自由になれるわけではありません。むしろ、専任のIT担当者を置けない小規模な事務所ほど、クラウドサービスの初期設定のまま、必要以上に広い権限を許可してしまっていたり、認証情報の管理を代表者一人に集中させてしまっていたりする場面が見られます。大規模な事業者であれば、専門のセキュリティ部門が監視・対応にあたりますが、小規模な事務所では、そもそも「どの連携がどこまでの権限を持っているか」を把握している人が一人もいない、という状態になりがちです。事務所の規模が小さいほど関係ない、のではなく、規模が小さいほど点検の担い手を確保しにくい、という別の課題が存在すると捉えた方が実態に近いかもしれません。

完全に防ぐことはできない、という前提から設計を始める

外部連携に依存するシステムである以上、認証情報の漏えいや不正アクセスを技術的にゼロにすることは、現実的には難しい前提として扱われることが多いです。ここでは、その前提に立ったうえで、被害の範囲や影響を小さくするために有効とされている設計の観点を整理します。特定の対応を批評する意図はなく、自事務所の設計を見直す材料としてご覧ください。

ひとつめは、最小権限と認証情報の管理です。連携に渡す権限を業務上必要な範囲(読み取りのみ、特定のデータ種別のみ等)に絞る設計と、APIキー・トークンを専用の仕組み(シークレットマネージャ等)で管理してローテーションする運用は、SaaS連携を安全に始める前に確認すべきことで、権限スコープの段階設計・トークン管理・退職者アクセスの棚卸まで含めた実務手順として整理しています。本稿の文脈で強調したいのは構造側の効きです。仮に認証情報が漏れても、到達できる範囲を最初から狭くしておけば、被害の上限そのものを下げられます。

ふたつめは、検知の仕組みです。何か異常なアクセスが起きたときに、それを早期に見つけられる監査ログやアラートの体制です。今回の事案でも、公表後の対応として開発環境のリアルタイム監視体制の構築が挙げられていました。問題が起きること自体をゼロにはできなくても、起きたことに早く気づける体制があるかどうかで、被害の広がり方は大きく変わってきます。事後対応として体制を強化する、という流れ自体は、多くの組織にとって現実的な学びになります。

みっつめは、起きたときの対応体制です。誰が一次対応をするか、顧問先にどう説明するか、監督官庁への報告が必要な場合の手順はどうなっているか。これらをインシデントが起きてから決めるのではなく、平時のうちに一度整理しておく事務所もあります。今回の事案でも、調査の進捗を複数回に分けて段階的に公表するという対応が取られました。影響範囲が確定するまで一定の時間がかかること自体は珍しくないため、「いつ・何を・どこまで公表するか」を事前に決めておくことは、規模の大小を問わず参考にできる観点です。

よっつめは、契約・規約の確認です。AIツールやSaaSの利用規約・DPA(データ処理契約)には、事故が起きた際の通知義務や賠償の範囲、データの取扱いに関する条項が定められています。技術的な対策と同じくらい、「契約上どこまで守られているか」「連携先で何かが起きたとき、自事務所にどのタイミングで連絡が来る取り決めになっているか」を事前に把握しておくことも、備えの一部になります。この点は、後述する関連記事でも詳しく扱っています。

AI時代に依存関係が増える構造的な理由

もうひとつ触れておきたいのは、AI活用を進めれば進めるほど、この種の依存関係がむしろ増えていく、という構造上の理由です。

RAG(検索拡張生成)のようにAIに社内文書を参照させる仕組みは、性質上、複数のフォルダ・複数のシステムにまたがる読み取り権限をAI側に与える形になりやすいです。ひとつの文書だけを見せるより、契約書・議事録・過去のやり取りを横断的に見せた方がAIの回答の質は上がりますが、それは同時に、ひとつのアクセス権限が到達できる範囲を広げることでもあります。個別の文書ごとに細かく権限を分けるより、まとめて見せた方が構築が簡単になるため、範囲を広めに設定してしまう場面は少なくありません。

AIエージェントに複数の外部システムを操作させる構成(会計ソフトへの登録、メール送信、カレンダー予定の作成など)も同様です。人間が手作業でやっていたときは、ひとつずつ別のログインで作業していた工程を、AIエージェント用のひとつの認証情報にまとめて持たせる設計は、利便性は高い一方で、その認証情報ひとつが持つ影響範囲を広げます。ひとつのAIエージェントが、会計・労務・顧客管理といった複数のシステムに横断的にアクセスできる構成は、便利であるほど、影響範囲も広くなる関係にあります。

さらに、SSO(シングルサインオン)の導入自体も同じ方向に働きます。職員ごとにバラバラだったログインをひとつのIDプロバイダに統合すると、管理の手間は減りますが、そのIDプロバイダの認証情報ひとつが、より多くのシステムへの入り口になります。ひとつのIDが突破されたときに到達できる範囲は、統合前より確実に広くなります。

加えて、AIとさまざまな外部ツールを標準的な方法で接続するための仕組み(MCPのようなプロトコル)も広がりつつあります。これは、AIが多くのシステムと連携しやすくなる、という点では歓迎すべき進歩ですが、同時に「ひとつのAIの設定ミス・認証情報の管理不備が、接続されている複数のシステムに一気に波及し得る」という設計上の前提を伴います。便利に接続できることと、接続された結果として影響範囲がどこまで広がるかは、別の問題として意識しておく必要があります。

これらはどれも、AI活用や業務効率化を進める過程で自然に選ばれる設計です。「AIを入れたから危なくなった」という単純な話ではなく、複数のシステムを連携させ、便利にしていく過程そのものが、ひとつの認証情報や権限が持つ影響範囲を広げていく、という構造上の理由によるものです。士業事務所がAI活用を進める場面でも、この構造からは逃れられません。便利さを追求する判断と、影響範囲を管理する判断は、本来セットで検討する必要があります。導入を決める会議で「何ができるようになるか」だけでなく「何と何が繋がることになるか」を合わせて確認する運用にしている事務所は、この構造をある程度意識できていると言えそうです。

今すぐ自分の事務所で確認できること

ここまでの整理を踏まえて、自分の事務所ですぐに確認できる項目を並べておきます。専門的な知識がなくても、まずは現状を洗い出すところから始められます。特別なツールや予算がなくても、担当者が使っているクラウドサービス・AIツールを一枚の表に書き出すだけで、着手はできます。

  • 現在使っている会計・労務クラウドとAIツールの連携を、一覧にして洗い出せているか
  • 各連携が持つアクセス権限(スコープ)が、業務上必要な範囲に絞られているか
  • APIキーやトークンの保管場所と、それを閲覧できる人が明確になっているか
  • 委託先・退職者のアクセス権限を、契約終了・退職のタイミングで確実に失効させる手順があるか
  • 連携先で何らかの障害・セキュリティ事案が起きたとき、自事務所への影響を確認する連絡先・手順を把握しているか
  • 顧問先に対して、AI・外部クラウドの利用範囲をどこまで説明できる状態になっているか

各項目の具体的な進め方(権限スコープの絞り方・トークンの保管とローテーション・棚卸の期日設計)は、SaaS連携を安全に始める前に確認すべきことが実務手順として扱っているので、洗い出しの次の一歩はそちらに接続できます。

すべてに即答できる必要はありません。実際、多くの事務所では、こうした連携を導入した担当者が異動・退職していて、「なぜこの権限になっているのか」を答えられる人がいない、という状況も珍しくないようです。ただ、今回のような事案が公表されるたびに「他社の話」として読み流すのではなく、この機会に一つでも自事務所の連携表を作ってみる、認証情報の保管場所を確認してみる、というところから始めても遅くはないはずです。洗い出しの過程で「これは誰のための連携なのか」「本当に今の権限の広さが必要なのか」を問い直すだけでも、次に同じような事案がニュースになったときの受け止め方が変わってきます。

士業事務所がこの事案から何を持ち帰るか

外部API・OAuth連携に依存するシステムを運用している以上、連携先や認証情報にまつわる問題を完全にゼロにすることはできません。これは会計クラウド事業者に限った話ではなく、AIツールや外部SaaSと連携しながら業務を組み立てているすべての組織、士業事務所も含めて当てはまる構造です。

今回公表された事案から持ち帰るべきは、「どこかの会社が対応を誤った」という評価ではなく、「自分たちの事務所にも、同じ構造の依存関係がすでにある」という認識ではないかと思います。完全に防ぐことができない前提に立ったうえで、権限を絞り、秘密情報を管理し、異常を検知できる仕組みを整え、起きたときの対応手順を平時に決めておく。この積み重ねが、AI活用を進める事務所にとっての、現実的な備えになります。

外部連携もAI活用も、業務を軽くしてくれる有力な手段であることに変わりはありません。便利さを手放す必要はなく、また手放したところで依存関係そのものがなくなるわけでもありません。だからこそ、便利さの裏側にある依存関係を、時々棚卸ししておく習慣が、事務所の規模に関わらず役に立つはずです。

今回のような事案の報道に接したとき、「自分たちには関係ない話」として読み終えるか、「自分たちの連携表を一度見直してみよう」と考えるかで、次に同じ種類のニュースを目にしたときの備えは変わってきます。完璧な対策を一度に作ろうとする必要はありません。まずは自事務所がどの外部サービスに、どこまでの権限を渡しているかを知ることから、備えは始められます。

認可スコープや契約面からの点検項目については、外部SaaSを業務に組み込む前に、契約条件を確認しておくで契約条項の読み方を扱っています。会計SaaSとAI連携で見るべき契約条件は別途扱う予定です。

参考

(本稿の事実関係は2026年7月22日時点で各社が公表している情報に基づきます。侵入経路など公式に非公表とされている事項については、本稿では推測を行っていません。)

Author · 著者

士業AI

Tags · タグ
ブログ一覧
Related · 関連記事

この記事を読んだ方は、次の記事も読まれています