会計freeeをAIエージェントに安全に連携する｜権限・承認・監査の設計

会計freeeをAIエージェントにつなぐと、月次の試算表を読ませて要約させたり、取引データを集計させたりが一気に自動化できます。便利な一方で、freeeのAPIは参照だけでなく仕訳登録・取引先作成・取引更新といった「戻せない書き込み」まで届きます。 AIエージェントやMCPクライアントに会計freeeを連携するなら、つなぐ前に権限設計を決めておくべきです。

freee連携でまず起きる3つの問題

会計freeeをそのままAIエージェントに渡すと、典型的に次の問題が起きます。

APIキー・トークンの散在：プロンプトやローカルのMCP設定に置いた認証情報は、漏れたときにfreeeの全操作が露出します。
読み取りと書き込みが同じ扱い：試算表の参照も、仕訳の登録も、エージェントから見れば同じ「ツール呼び出し」です。区別されていなければ、AIは同じ気軽さで書き込みます。
事業所（会社）の取り違え：複数の事業所を扱うと、正しい仕訳を誤った会社に登録する事故が起こり得ます。

読み取りは自由に、書き込みは承認制に

実務的な原則はシンプルです。参照系は自由に、更新系は人間の承認を経てから。 freeeの操作をこの2種類に仕分けます。

自由に実行してよい（読み取り）：試算表（PL・BS）の取得、取引一覧の参照、取引先一覧・勘定科目の参照。分析や要約はここで完結します。
承認を挟む（書き込み）：取引（仕訳）の登録、取引先の作成、取引の更新。これらは実行前に人間が内容を確認し、承認してから通します。

こうしておけば、AIエージェントは月次レポートの下書きや異常値の検出まで一人で走り切り、帳簿を変える操作の直前だけ担当者が確認する、という運用になります。

生のAPIキーをエージェントに渡さない

もう一つの要点は認証情報の置き場所です。freeeのアクセストークンやリフレッシュトークンをエージェントのランタイムやプロンプトに置くのは避けます。認証情報はサーバー側に暗号化して保管し、エージェントにはスコープ付きの権限トークンを1つだけ渡す。こうすれば、あるワーカーのトークンが漏れても、失効はそのワーカーの範囲に限定でき、 freee本体の認証情報を作り直す必要はありません。

正しい事業所へ、毎回ルーティングする

会計事務所や複数法人を扱う運用では、「操作を間違えること」より「正しい操作を間違った会社にやること」の方が怖い問題です。ロールとスコープで接続先の事業所を固定し、ワーカーごとに触れる会社を限定します。どの会社に対する呼び出しだったかは、後述の監査ログにも残ります。

すべての試行を監査ログに残す

会計データを扱う以上、「誰が・どのワーカーで・どの会社に・何をしたか」を後から追えることは必須です。承認された操作もブロックされた操作も、ワーカー・ロール・ツール・接続・リクエスト・結果まで記録しておけば、月次の締めや監査対応のときに証跡がそのまま使えます。

Grantryでの実現方法

Grantryは、AIエージェントと業務ツールの間に入る権限レイヤーです。 freeeを含むMCP対応のサービスに対して、ワーカーごとにスコープ付きトークンを1つ発行し、読み取りは自由に、仕訳登録などの書き込みは承認ゲート越しに、そして全コールを監査ログに残します。 Claude CodeやCodexなどのMCPクライアントを、ワーカートークン付きでGrantryのエンドポイントに向けるだけで、エージェント側のコード変更なしに始められます。

よくある質問

AIエージェントにfreeeのAPIキーやアクセストークンを直接渡しても大丈夫ですか？

推奨しません。プロンプトやローカルのMCP設定に置いた認証情報は、そのトークンでできる操作すべてを許す常時オファーになります。認証情報はサーバー側に暗号化して保管し、エージェントにはスコープ付きの権限トークンを1つだけ渡す設計が安全です。

freeeの仕訳登録や取引先作成をAIに自動でやらせても問題ないですか？

登録・作成・更新は「戻せない書き込み」です。試算表や取引の参照といった読み取りは自由に実行させ、仕訳登録・取引先作成・取引更新などは人間の承認を経てから実行する承認ゲートを挟むのが実務的です。

複数の会社（事業所）をAIエージェントで扱う場合、取り違えを防げますか？

ロールとスコープで接続先の事業所を固定すれば、正しい操作を誤った会社に対して実行する事故を防げます。どの会社に対する呼び出しかは監査ログにも残ります。