2026年上半期に観察される SaaS 連携の動き
ノーコード連携ツールの導入は、中小規模の士業事務所でも目に見えて広がっています。各種の連携プラットフォームや SaaS のネイティブ統合機能を使って、会計SaaSとメール、チャットツールをつなぐような連携は、数年前であれば外部に依頼していた領域です。一方で、同じ時期に「連携経由で顧問先 A 宛の請求書が顧問先 B に送られてしまった」「退職した職員のトークンが半年経っても連携先で生きていた」という事象が、周辺で断片的に報告されるようになっています。
連携が「繋がる」ことと、業務として「安全に使える」ことのあいだには、想像より大きな距離があります。本稿では、AI ツールと会計SaaSや業務SaaSを連携させたい士業事務所向けに、見落としやすい論点を整理します。
連携トラブルの 4 類型
公開情報や周辺の事例から見える限り、SaaS 連携トラブルは大きく次の 4 類型に分けられます。
- 誤送信・誤連携：顧客マスタの紐付けキーがずれており、A 社の請求書が B 社に届くケースです
- 権限の過剰付与：「とりあえず動かすために」管理者権限のトークンで連携し、API 経由で全データが事実上閲覧可能な状態になっているケースです
- 退職者・元委託先のアクセス残存：個人アカウントで発行したトークンが、退職後も連携先システムで有効なまま残っているケースです
- 障害時の沈黙的失敗：連携が止まっていても気づかず、数日後に「請求書が届いていない」と顧問先から連絡が来るケースです
これらは独立した事故ではなく、運用設計が未整理なときに複合的に発生する傾向があります。SaaS 連携は、コードを書かなくても繋がるからこそ、全体を見る役割が決まっていないと論点が分散しやすい領域です。
3 つの層で分けて設計する
SaaS 連携を安全に運用するには、最低でも次の 3 層を別々に設計する必要があります。
権限の層 「どのトークンで」「どのスコープで」「どのリソースに」アクセスするかという観点です。API セキュリティの公開ガイドラインでも、オブジェクト単位や機能単位の認可不備が依然として上位に挙げられており、外部から見れば「正しく認証された API コール」であっても、本来アクセスすべきでないオブジェクトを取得できてしまうケースが指摘されています。ノーコード連携ツールでは、この権限境界がツール側の抽象化に隠れてしまい、利用者が把握しづらいことがあります。
データの層 連携で「何が」「どこに」「どの頻度で」流れているかという観点です。請求書の PDF がメールに送られているのか、本文に金額が記載されているのか。AI に渡しているプロンプトに、顧問先の決算情報が含まれていないか。データフローは図に書き起こさないと、関係者の頭の中だけでは整合性が取りにくくなります。
例外処理の層 「正常に動かなかったとき、誰がどう気づくか」という観点です。多くのノーコードツールはエラー時に通知を出しますが、その通知が「事務所の誰かのメールボックス」に届くだけで放置されていれば、検知体制がないのと同じ状態になります。API セキュリティのガイドラインでは、第三者 API から返ってきたデータを過信することの危険性も指摘されています。
認可とトークン管理
主要な業務 SaaS は、API 連携に OAuth 2.0 ベースの認可フローを採用しているケースが一般的です。運用設計が未整理な状態で起きがちな問題は次のとおりです。
- 個人アカウントで連携トークンを発行する：その人が退職すると、連携が突然止まります。または、退職者のアカウントから引き続きアクセスできてしまう恐れがあります
- API キー・シークレットを社内ツールに平文で保存する：共有設定の事故で外部漏洩しうる状態になります
- リフレッシュトークンのローテーション設計がない：トークン漏洩時に止める手順が決まっていない状態になります
- スコープを絞らない：「全権限」のトークンで連携を組んでしまい、本来不要な顧客情報まで連携ツール側にキャッシュされてしまいます
API セキュリティのガイドラインでも、認証メカニズムの不適切な実装によりトークンが悪用されるリスクが取り上げられており、トークン管理は「動けば OK」では済まない領域です。
最低限、次の運用ルールはチーム内で文書化しておきたいところです。
- 連携用トークンは「個人」ではなく「事務所の連携用アカウント」で発行します
- スコープは原則として読み取り専用から始め、必要に応じて段階的に書き込みを許可します
- トークン・API キーは平文で残さず、シークレット管理ツール (パスワードマネージャの組織機能、Vault 系サービス等) を利用します
- 退職・委託終了時のトークン棚卸ルールを決めます
DPA と顧問先データの取扱い
SaaS 連携は技術論だけで完結しません。士業の場合、顧問先のデータを取り扱う以上、第三者提供・委託契約の論点が必ず付随します。
公的機関からは、生成AIサービスに業務データを入力する行為について、個人情報保護法上の論点が整理された注意喚起が公表されています。SaaS 連携を経由して AI に顧客データが渡る経路がある場合、この論点は会計事務所・社労士事務所・行政書士事務所いずれにも該当しうるものです。詳細は公式情報を確認のことをおすすめします。
連携を組む前に、最低限次は書面で確認しておきたいところです。
- 連携先 SaaS の データ処理の場所 (リージョン) と 保管期間
- 連携先 SaaS 事業者との 委託契約 / DPA の有無と内容
- 連携を経由して AI に渡るデータが 学習に利用されない ことの明示
- 障害・漏洩時の 通知義務 と 連絡経路
「規約に同意したから大丈夫」ではなく、規約のどこに何が書いてあるかを読み解く作業が必要になります。ここで読み落とすと、後段の事故が顧問先への説明可能性として効いてきます。
経路全体でセキュリティを見る
SaaS 連携のセキュリティは、単体 SaaS のセキュリティの和ではなく、「連携経路全体」で見る必要があります。
- データの境界：連携ツールのサーバを経由する場合、そのリージョン・暗号化方式・ログ保管期間を把握しているかという観点です
- ログ：誰が・いつ・どのデータを・どこに・転送したかを後から追えるかという観点です
- 異常検知：通常と異なる量・時間帯のデータ転送が発生したとき検知できるかという観点です
- 業務継続：連携先 SaaS が停止したとき、業務が止まるのか、手動運用に戻せるのかという観点です
士業の守秘義務は職業倫理の根幹に位置づけられており、「連携ツール側の障害だった」という説明だけでは顧問先への説明が成立しにくいところがあります。連携経路を組む段階で、最悪のケースを誰が引き受けるかを整理しておくことが望ましいです。
抜けやすい点
実務上、設計時に見落とされやすい点を 4 つ挙げて締めます。
1. 「連携を止める手順」を最初に書いていない 連携を組む手順はベンダーのドキュメントに沿って進みますが、「止める手順」を意図的に文書化している事務所は多くありません。トークン失効・連携停止・データ削除依頼といった項目をドキュメント化しておかないと、退職・契約解除の場面でアカウントが残り続けてしまいます。連携設計の最後に「停止手順」のセクションを必ず置く運用にしたいところです。
2. ノーコード連携ツール自体のセキュリティ仕様を確認していない 連携ハブそのもののリージョン・データ保持期間・暗号化方式は、連携先 SaaS とは別に確認が必要です。連携先 SaaS の DPA を確認しても、連携ハブのほうを見ていなければ経路が抜けてしまいます。
3. 連携経路を 1 枚の図にしていない 頭の中の整理だけでは、関係者間の認識ずれが残ります。単純なフローでも、図に落とすと「実は連携ハブの中で内容が条件分岐していた」のような発見が出てくることがあります。
4. 退職者のトークン棚卸ルールを期日付きで決めていない 「退職時に対応する」という運用ルールは形骸化しやすいものです。退職と無関係に「四半期ごとにトークン一覧を棚卸する」期日を入れておくほうが、結果として漏れが減ります。
連携が「繋がる」段階ではなく、「トークンが漏れた・退職者が残った・連携が止まった」場面で初めて設計の良し悪しが問われます。設計段階でこれらを織り込んでおくことが、後段のコストを下げる近道になります。
参考
- OWASP API Security Top 10 (2023年版)：https://owasp.org/API-Security/editions/2023/en/0x11-t10/
- 個人情報保護委員会「生成AIサービスの利用に関する注意喚起等について」 (2023年6月2日)：https://www.ppc.go.jp/news/careful_information/230602_AI_utilize_alert/
- 経済産業省・総務省「AI事業者ガイドライン」：https://www.meti.go.jp/shingikai/mono_info_service/ai_shakai_jisso/