「仕訳の入力を自動化したい」「請求書を読み込ませて、そのまま会計SaaSに登録したい」 という要望が、税理士・会計事務所で増えてきました。会計SaaSのAPIとAIを組み合わせて、入力作業を業務から外せないか、 という発想です。
技術的には、ある程度のところまで作れる領域です。国内の主要会計SaaS (freee会計、マネーフォワード クラウド会計など) は公式APIを公開していて、OAuthによる認可、勘定科目や仕訳の取得・登録、取引先マスタの操作などができる構成になっています。本稿は特定の製品の設定手順を扱うものではないため、以降は「会計SaaS」と一般化して進めます。ご利用中のサービスに読み替えてご覧ください。LLMと組み合わせれば、「メール本文から仕訳案を生成して、APIで会計SaaSに投入する」 ようなパイプラインも、設計としては考えられる範囲にあります。
判断が分かれるのは、技術的に動かせることと、業務として運用していけることの間にある、契約・規約・コンプラの設計の部分です。本稿では、国内の主要会計SaaSのAPIを士業事務所が業務に組み込む場面で、技術観点ではなく契約・コンプラ・セキュリティ観点で見ておきたいポイントをご紹介します。実装そのものは扱いません。実装よりも手前で、事務所として判断するための材料の整理を目的にしています。
実装に入る前に、自分の言葉で答えておきたい問い
実装を進める前に、いくつかの問いに自分の言葉で答えられるかを、事務所内で確認しておく事務所もあります。
- 連携するアカウントは、誰のデータを持っているか
- そのデータをAIに渡してよいと、契約上どこに書いてあるか
- 連携アプリの認可スコープは、業務上必要な範囲に絞れているか
- 障害時・退職時・契約解除時に、トークンとデータをどう扱うか
このどれかに即答できないまま実装に入ると、後工程でいったん止めて確認する場面が出てくることが多いようです。本稿の各セクションは、これらの問いに答えるための材料としてご紹介します。
国内の主要会計SaaS — API構造を見ておく
国内の主要会計SaaSは公式の開発者ドキュメントを公開しており、OAuth 2.0ベースの認可フローと、 アプリ単位のスコープ設計が中心となっています。仕訳・取引先・請求書・経費精算・人事労務など、対象データごとにAPIが分かれていて、上位プラン限定のAPIがある場合もあります。アプリストア公開・社内利用・顧問先提供で適用される規約や審査が異なる点も、事前に確認しておきたい部分です。
各SaaSとも、会計・請求書・給与・経費といったプロダクトごとにAPIが分かれていて、それぞれ独立した認可と料金プランの制約があります。OAuthトークンの寿命やリフレッシュ仕様、rate limitはプロダクト・プランによって異なるため、「会計SaaSのAPI」 と一括りにせず、対象プロダクト単位で公式ドキュメントを読んでおく必要があります。
主要会計SaaSのAPIは「OAuth + スコープ + rate limit + 規約同意」 という骨格は似ていますが、士業事務所として点検する観点では、いくつかの差分があります。
| 観点 | 主要会計SaaS一般 |
|---|---|
| 認可方式 | OAuth 2.0 |
| API単位 | プロダクト + データ種別ごと |
| プラン依存 | 一部APIが上位プラン前提の場合あり |
| rate limit | 公式ドキュメントで都度確認 |
| 公開アプリ | アプリストア審査あり |
| 規約 | 自社利用 / 顧客提供で扱いが分かれる |
各社のAPI仕様や規約は時期によって改訂されるため、本稿では具体的な数値や条項は書かない形にしています。代わりに、契約・実装前に公式ドキュメントと利用規約のどの章を読んでおきたいかを、後段でご紹介します。
認可スコープ — 「全部できる」 トークンが残る業務になっていないか
会計SaaSのAPIは、家計簿アプリのそれと違って、扱える操作の範囲が広いという特徴があります。特定の事業者の会計データに対して、
- 仕訳の閲覧
- 仕訳の登録・更新・削除
- 取引先マスタの登録
- 請求書の発行
- 給与・労務情報の参照
までを一つの連携アプリでまとめて要求することも、技術的にはできる場面があります。ただ、AI連携の文脈では、これは避けておきたい運用になりやすいです。理由は大きく二つあります。
一つは、LLMへの入出力をプロンプトインジェクションで汚染された場合に、影響範囲が広がりやすいことです。「請求書PDFを読み取って仕訳案を出す」 だけのつもりで、削除権限まで持つトークンをLLMワークフローに渡してしまうと、悪意あるPDFを1件処理しただけで仕訳の一括削除のような操作が走ってしまう経路が残ります (実際に動くかどうかは実装に依存しますが、 設計上の懸念としては現実的な範囲です)。
もう一つは、退職時・契約解除時の影響範囲が広がる場面です。スコープを広く取ったトークンを職員PCやワークフロー基盤に保管していた場合、退職対応・端末紛失時に「何にアクセスし得たか」 を顧問先に説明するコストが大きくなります。
実務上の方針として、次のような形を事務所内ルールに置いている事務所もあります。
- AIワークフローに渡すトークンは、読み取り専用または最小スコープに限定する
- 書き込みが必要な処理は、人間のレビューを挟む別経路 (管理者専用トークン) で実行する
- アプリ・トークンの一覧と用途を、台帳にして事務所内で見える状態にしておく
rate limitと再送設計 — AIのリトライが業務を止めることがあります
会計SaaSのAPIには、ほぼrate limit (一定時間あたりのリクエスト上限) が置かれています。具体的な数値は各社・各API・プランで異なるため、公式ドキュメントで最新値を確認する流れになります。
AIと組み合わせると、ここが想定外の挙動として出てくることが多いです。
- 月次の仕訳5,000件を一括取り込みしようとして429 (Too Many Requests) が連発する
- LLMが「失敗したらリトライ」 を素直に実装してしまい、 同じリクエストを秒間数十回投げる
- 結果として連携アプリ単位で一時的にロックされて、 繁忙期に業務が止まる
「AIが勝手にリトライした結果、 月初の業務が半日止まる」 は、 実装の場面で見かけるパターンです。対策の方向としては、次のような形が取られています。
- リトライは指数バックオフ + ジッタにする
- 一括処理は夜間バッチに分離して、対話的なAI経路とは別ルートにする
- 429が出た時点で、AIに「ここで止まる」 と指示できるツール設計にする
- 失敗ログを、 人間の目に入る場所 (業務通知系ツール等) に出しておく
技術選定の段階で「rate limit設計をどこに書いてあるか」 を答えられない実装担当の方には、 ここを抑えてから進めていただく流れがやりやすいです。
個人情報・本人特定情報の越境 — ここが守秘義務との接点になります
ここが、士業事務所にとって慎重に見ておきたい論点です。
会計SaaSに登録されているデータには、次のような情報が含まれてきます。
- 役員・従業員の氏名、住所、生年月日
- 給与・賞与・社会保険関連
- マイナンバー (取り扱う場合)
- 取引先の連絡先、銀行口座
- 売上・経費の明細 (顧客名が入る場合があります)
これらをLLMのAPIに投げる場面では、「外国にある第三者への個人データの提供」 に該当しないかを、事前に確認しておきたい部分です。個人情報保護委員会のガイドライン「外国にある第三者への提供編」 では、原則として本人の同意が必要で、同意取得時には移転先国名・当該国の制度・受取人の保護措置を本人に提供する義務がある、 という整理が示されています (実際の適用は事案ごとに法令解釈が必要なため、 本稿は概要のご紹介にとどめます)。
実務で論点になりやすい部分を並べておきます。
- 顧問先 (事業者) の従業員情報を、事務所がAIに渡してよい根拠が、契約上どこにあるか
- 顧問契約・委託契約に「AI / 外部LLM利用」 が明記されているか
- 明記されていない場合に、黙示の同意と整理できるか (整理が難しい場面が多いようです)
- LLMの提供事業者の所在地・データセンターの所在地はどこか
- 学習に使われない契約 (オプトアウト・エンタープライズ契約) になっているか
- ログ保持期間と、保持されたログへのアクセス権限はどうなっているか
「便利だから商用AIチャットツールに貼った」 「APIなら大丈夫だと思った」 という整理だけで止めておくと、顧問先からのご照会に答えるときの根拠が足りなくなりがちです。契約書ベースで説明できる状態にしておく流れが、技術選定そのものよりも先に置かれることが多いです。
利用規約の読み合わせ — どの規約を並べて読むか
会計SaaSのAPI利用規約は、自社向け利用と「顧客に対するサービス提供のための利用」 で扱いが分かれる場合があります。次のような観点で、公式規約の本文を読んでおきたい場面が出てきます (具体的な条項番号や禁止事項は時期によって改訂されるため、本稿では引用は控えています)。
- 自社の社内業務効率化のための利用が、許諾の範囲に入っているか
- 顧問先の代理としてAPIを叩く構成が、契約上どこに位置付けられているか
- API経由で取得したデータを、自社の別システム (DWH、AI学習基盤) に蓄積してよい範囲か
- API連携アプリを外部公開 (マーケットプレイス公開) する場合の、追加審査の有無
- 規約違反時のアカウント停止条項
「規約を読んでいない実装」 は、機能としては動いていても、事業継続の観点で気になる場面が出てきます。実装着手前に、顧問契約書・SaaS利用規約・API利用規約・LLM利用規約の4点セットを並べて読み合わせる工程を入れている事務所もあります。
セキュリティで譲りにくいライン
API連携を構築するということは、新しい攻撃面が増える、 ということでもあります。最低限、次の項目はチェックリストに置いておきたい論点です。
- アクセストークンの保管場所 (環境変数 / シークレットマネージャ / クラウドのKMS)
- トークンのローテーション運用 (誰が、どの頻度で更新するか)
- 監査ログの保存期間と、ログ自体へのアクセス権限
- 退職者・委託先解除時のトークン即時失効フロー
- 端末紛失時の対応手順
- LLM側のプロンプトログ・出力ログの扱い (学習されない契約か)
- インシデント発生時に、顧問先へ報告する手順とSLA
「全部 .envに書いてGitにpushしてしまった」 「退職者のPCからトークンが流出した」 は、現場で見かけるパターンです。会計データを扱う以上、最低限の鍵管理は譲りにくいラインになります。
連携前に通しておきたい点検項目
実装着手前に、次の項目を一度通している事務所もあります。
- 連携対象のSaaSのAPI利用規約 (最新版) を読み、社内で要約を共有した
- 顧問契約書に「AI / 外部システム連携」 に関する条項があるかを確認した
- 利用する認可スコープを最小化し、台帳に記録した
- アクセストークンの保管場所と権限を明文化した
- rate limitを確認し、リトライ戦略をドキュメント化した
- LLM提供事業者の「学習に使われない」 契約条件を確認した
- 個人情報の越境に該当するかを、法令ガイドラインに照らして確認した
- 退職者・委託解除時のトークン失効フローを定義した
- 障害時・誤投入時のロールバック手順を定義した
- 顧問先への説明資料 (AI利用範囲・データ取扱) を準備した
すべてに「はい」 と答えられる状態を作ってから、本番運用に入る流れを取っている事務所もあります。
実装より手前で揃えておきたいもの
会計SaaSのAPIとAIの組み合わせは、士業事務所の業務を軽くする方向で効いてくる場面があります。同時に、扱うデータの性質 (個人情報・本人特定情報・金額情報) と、提供する役務の性質 (守秘義務・善管注意義務) から、技術選定よりも手前で、契約・規約・コンプラの設計を先に揃えておく流れになりやすい領域でもあります。
動くものを作るところまでは、比較的早く到達できます。難しいのは、想定外の事象が起きたときに、顧問先と監督官庁に説明できる状態を維持していくことの方です。「動くもの」 よりも「規約上説明できるもの」 を先に固めておく順序の方が、結果として運用が軽くなる場面が多いようです。
参考
- 個人情報の保護に関する法律についてのガイドライン (外国にある第三者への提供編), 個人情報保護委員会, 平成31年1月23日初版・令和7年12月12日改正: https://www.ppc.go.jp/personalinfo/legal/guidelines_offshore/
- 個人情報保護法ガイドライン (通則編・第三者提供時の確認・記録義務編 含む), 個人情報保護委員会, 各最新改正: https://www.ppc.go.jp/personalinfo/legal/