freee・マネーフォワードの API トークンを、AI 記帳でどう守るか

AI に記帳をやらせるなら、どこかで必ず freee や マネーフォワード の OAuth トークンが要ります。明細を読む、仕訳を書き戻す——その入り口の鍵がトークンです。問題は、この鍵をどこに置き、どう更新し、誰が触れる状態にするか。記帳の自動化でいちばん地味に、いちばん事故が起きやすいのが、このトークンの運用です。トークンに限らず「AI に渡す情報をどこで絞るか」の全体像は、こちらの記事にまとめています。

トークンは「短命だが、広い」

freee の OAuth トークンは、アクセストークンの有効期限が6時間、リフレッシュトークンが90日です。リフレッシュトークンはローテーション方式で、更新のたびに新しいものが発行され、古いものは無効になります。「6時間で切れるなら安全」と思いたくなりますが、そこは本質ではありません。リフレッシュで回り続けますし、何より1本のトークンが、その権限の範囲の会計データへ広くアクセスできます。守るべきは「期限」ではなく、「範囲」と「置き場所」です。

いちばん危ないのは「トークンの散らばり」

顧問先や事業所が増えれば、その数だけ認可とトークンが増えます。これが各担当の PC、チャットの履歴、スクリプトの中、.env ファイルに散らばると、その一つひとつが漏洩点になります。とくに AI に読ませるディレクトリの中にトークンを置けば、何かの拍子に AI のコンテキストにも載り得ます。鍵の本数が増えるほど、置き場所の管理が破綻していく——これがトークン運用の現実です。

だから「サーバー側で一元管理」

素直な対策は、トークンをファイルではなくサーバー側で保管し、リフレッシュもアプリが自動で回すことです。画面にも、担当者の手元にも、トークンの実体を出さない。そして AI には渡さない。AI がやるのは判定で、会計サービスへの読み書きは、トークンを抱えたサーバー側が代行する。こうすると、漏洩点は「散らばった鍵」から「一元管理された一か所」に縮みます。

リフレッシュの落とし穴

90日でローテーションするということは、更新のたびに発行される新しいリフレッシュトークンを確実に保存し続けないと、いずれ認可からやり直しになります。これを顧問先ごとに、担当者が手で管理するのは現実的ではありません。トークンのライフサイクル——取得・保管・自動更新・失効時の再認可——を仕組みとして持っておくことが、結局いちばん安全で、いちばん手間が少なくなります。

実際にやったこと

私たちが社内で記帳の自動化を整えたときも、最初に決めたのはトークンの置き場所でした。トークンはファイルに一切置かず、サーバー側で保管・自動更新する。AI には渡さず、判定だけをさせる。これだけで、「どのファイルに鍵があったか」を心配する必要がなくなりました。RuleHub でも同じ設計を採っていて、freee / MoneyForward のトークンはサーバー側で保管・自動リフレッシュし、画面にも手作業にも露出させません。AI 判定はサーバー内で完結し、確定した結果だけを会計サービスへ戻します。

運用前のチェック

• トークンをファイル（.env 等）に置かず、サーバー側で保管しているか
• リフレッシュ（90日ローテーション）を自動で回す仕組みがあるか
• トークンを AI に渡していないか（AI は判定だけにできているか）
• 顧問先・事業所ごとにトークンを分離・管理できているか
• 画面や担当者の手元に、トークンの実体が出ていないか

トークンは、記帳自動化のいちばん奥にある鍵です。短命さに安心せず、置き場所と更新と権限の範囲を先に設計しておく。鍵をひとところに集めて自動で回す形にできれば、AI の速さは、認証情報の不安と切り離せます。