Claude Code で freee・マネーフォワードの記帳を自動化する前に、AIへ渡す情報を設計する

経理の記帳や月次の消込を Claude Code に任せると、実際に作業は速くなります。仕訳の下書き、明細の分類、freee や マネーフォワード の API を叩くスクリプトの生成——これまで手で回していた部分が、対話しながら片付いていきます。

ただ、動かし始めるときの「いちばん自然な配線」が、そのまま会計データを外へ流す経路になっていることがあります。APIトークンを設定ファイルに置く。口座明細の CSV をディレクトリに置いて「これを分類して」と頼む。どれもごく普通の操作ですが、この瞬間に何がどこへ送られているのかは、意外と意識されていません。会計データは、速く処理できることと同じくらい、「誰の何をどう扱ったか」を後から説明できることが品質を左右します。だから最初に、AIへ渡す情報の止め方を決めておく価値があります。

まず、何が実際にAIに送られているのか

Claude Code は、ローカルのファイルを勝手に全部読み込んでクラウドへ送る——わけではありません。送られるのは、Claude がそのセッションで実際に読んだ内容です。逆に言えば、Claude に読ませたものは、応答を生成するために Anthropic のモデルへ渡ります。口座明細の CSV を開かせれば、その中身はコンテキストに載ります。シンプルですが、ここが出発点です。

分けて考える必要があるのが MCP（Model Context Protocol）サーバです。freee や マネーフォワード と連携する MCP サーバを噛ませると、データはその第三者のサーバを経由します。これは Anthropic ではなく、MCP サーバの提供元へ向かう経路です。つまり、Anthropic との間の取り決め（後述する ZDR など）の外側で、信頼境界がもう一段ずれます。便利な連携を足すほど、この境界が静かに増えていく、と捉えておくと判断を誤りません。freee 公式の MCP サーバ「freee-mcp」を実際に繋ぐ前提での権限の絞り方は、別記事にまとめました。

freee／マネーフォワードのトークンは「広い鍵」

freee の API は OAuth 2.0 で、発行されるアクセストークンの有効期限は6時間、リフレッシュトークンは90日です。リフレッシュトークンはローテーション方式で、更新のたびに新しいものが発行され、古いものは無効になります。短命に見えますが、問題は期限ではなく範囲のほうです。1つのトークンが持つアクセス権は「アプリの権限 × ユーザーの権限」で決まり、その範囲の会計データへ広くアクセスできます。経理の生データを握る、いわば広い鍵です。

この鍵が、Claude の読めるファイルに平文で置いてあると——たとえば .env や、うっかりコミットした設定ファイル、あるいはシェル履歴を表示させた拍子に——コンテキストに載り得ます。2024年1月から電子取引データの電子保存が完全義務化され、取引の生データはこうしたシステムへ集まるようになりました。鍵が広く、守る対象も増えている。だからこそ「AIに何を読ませるか」を、運用を始める前に決めておきたいところです。トークンそのものの保管・自動更新といった運用面は、こちらで詳しく扱います。

「.claudeignore を置けばいい」は誤り

ここでよくある誤解を一つ。「機密ファイルは .claudeignore に書いておけば Claude は読まない」と説明する記事が出回っていますが、Claude Code に .claudeignore という公式の仕組みはありません。コミュニティで共有されている同名の回避策も期待どおりには効かず、この点は The Register が2026年1月に報じています。これを信じて .env を .claudeignore に並べても、実際には何も守られていない、という状態が起こり得ます。

代わりに Anthropic が案内しているのは、設定ファイルの permissions です。.claude/settings.json（プロジェクト共有）、~/.claude/settings.json（ユーザー全体）、.claude/settings.local.json（gitignore 対象の個人用）に deny と allow を書き、deny を allow に優先させます（deny-first）。最小構成はこの程度です。

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Read(~/.ssh/**)",
      "Bash(cat .env)"
    ]
  }
}

ただし、これも万能ではありません。permissions.deny が版によっては期待どおりに効かず、deny 指定したはずのファイルを読み書きできてしまう・メモリへの読み込みまでは止められない、という不具合報告が複数上がっています。加えて、deny の Read で .env を塞いでも、Bash の実行が許可されていれば cat .env のようなコマンド経由で中身が読めてしまう。許可された任意のサブプロセスがファイルにアクセスできるからです。

つまり設定での遮断は「やっておくべき多層防御の一枚」であって、そこだけを信頼の置きどころにはできません。確実なのは、機密を Claude のプロセスが触れる場所にそもそも置かないこと——トークンや認証情報はファイルではなく環境変数で渡し、リポジトリには git-secrets のようなツールでコミット前検知をかける。そのうえで、AIに渡すデータ自体を必要最小限へ絞る。守りの重心は、設定フラグではなく、データの置き場所と渡し方の設計に置きます。

現場で効く、最小限の渡し方

設定の話を超えて、設計の話をします。permissions は事故（うっかり読ませる）を減らしますが、「AIに渡すデータの設計」そのものはしてくれません。守りの本体は、AIに渡す情報を必要最小限まで絞ることです。具体的には、次の順で固めていきます。

• トークンや認証情報はファイルではなく環境変数で扱う。リポジトリには git-secrets でコミット前検知をかける。
• 多層防御の一枚として、.claude/settings.json の deny で .env・secrets・鍵ディレクトリを塞ぐ。Bash 経由の読み出しも想定し、cat 系も deny に含める（ただし deny は過信しない）。
• 口座明細そのものを丸ごと渡さない。AIに必要なのは「仕訳ルールを書くための構造やサンプル」であって、顧客の実取引行そのものではないことが多い。マスクした最小サンプルで足りないか、まず疑う。
• 商用利用なら ZDR（ゼロデータ保持）の適用範囲を確認する。Anthropic の商用APIのデータは同意なくモデル学習に使われませんが、ZDR は対象や契約形態が決まっているので、自社が含まれるかを確かめておく。
• MCP サーバを挟むなら、それが新しい信頼境界になることを前提に提供元を精査する。freee データに触れる連携ほど慎重に。

ありがちな失敗と、その直し方

たとえば、ある受託の会計支援チームでは、顧客ごとの freee トークンと口座明細を作業ディレクトリにまとめ、「この顧客の今月分を分類して」とそのまま渡す運用をしていました。速くはなったものの、複数顧客のトークンと明細が同じコンテキストに載り、誰の何がどこまでモデルや連携先へ渡ったのかを後から説明できない状態になっていました。会計データは、顧客に対して扱いを説明できることまでが品質です。説明できない時点で、速さの価値は目減りします。顧問先を多く抱える税理士事務所・記帳代行での設計は、別記事で掘り下げています。

私たち自身も、社内で記帳の自動化を試した初期に同じ轍を踏みかけました。そこで切り替えたのは、AIに「実データ」ではなく「ルールと最小サンプル」だけを渡す形です。トークンは環境変数に隔離し、明細はマスクした数行だけを見せて分類ロジックを作らせ、確定した処理は実データ側で回す。AIが触れる情報を物理的に減らすと、設定ファイル一枚の抜けで全部が漏れる、という構造そのものが消えていきます。

「渡す情報を減らす」を仕組みにする

ここまでを手作業の規律だけで守り続けるのは、正直しんどいところがあります。担当者が増え、顧客が増えるほど、設定の抜け一つが命取りになる。だからこの「AIに渡す情報を最小化する」という発想を、運用の規律ではなく仕組みへ落とし込んだのが、私たちが提供する RuleHub です。freee／マネーフォワード の記帳自動化を、セキュリティを起点に設計した基盤で、AIに渡すのは記帳に必要な最小限の情報だけ。APIトークン・口座・明細は統制下に置いたまま、記帳ルールを蓄積して再現します。Claude Code で記帳を速くしたい、でも会計データの扱いは説明できる状態に保ちたい——その両立を考えているなら、一度見てもらえればと思います。

動かす前のチェック

• APIトークンはファイルに置かず、環境変数で渡しているか
• .claudeignore に頼らず、.claude/settings.json の deny・環境変数・データ最小化を多層で組んでいるか
• Bash 経由の読み出し（cat 等）も deny に含めているか
• 口座明細は丸ごとでなく、マスクした最小サンプルを渡しているか
• 商用利用の ZDR 適用範囲を確認したか
• MCP サーバを挟む場合、その提供元（=新しい信頼境界）を精査したか

会計データを Claude Code で速く扱うことと、安全に扱うことは両立します。順番だけが大事で、速くしてから守るのではなく、渡す情報を決めてから速くする。それだけで、後からじわじわ効いてきます。