「先月の広告費いくらだった？」「この取引先への支払い、去年はどうなってた？」——経理に飛んでくる問い合わせの多くは、freeeを見れば分かることです。ただし見方を知っている人しか見られないため、結局経理担当に集中します。
ここをAIで解こうとするとき、最初に区別すべきことがあります。
freeeの「AI」と、AIから freee を見る話は別物
| freee内蔵の自動化 | AIからfreeeのデータを見る | |
|---|---|---|
| やること | 明細から勘定科目を推測して仕訳を作る | 質問に会計データで答える |
| 使う人 | 経理担当 | 経理以外の社員 |
| 実現方法 | freeeの機能として提供済み | APIで取得して構築する |
経理の入力を楽にしたいなら前者で、freeeの機能を使えば済みます。この記事は後者——経理への問い合わせを減らす話です。
APIで何が取れるか
freeeの会計APIには、AI向けの専用エンドポイントはありません。「AIと連携する機能」を探しても見つからないので、通常のAPIでデータを取得して、AI側に渡す構成になります。
問い合わせ対応で実際に使うのは、次のあたりです。
| 取りたいもの | エンドポイント |
|---|---|
| 損益（試算表） | GET /api/1/reports/trial_pl |
| 部門別の損益 | GET /api/1/reports/trial_pl_sections |
| タグ・セグメント別の損益 | GET /api/1/reports/trial_pl_segment_1_tags |
| 貸借（試算表） | GET /api/1/reports/trial_bs |
| 個別の取引 | GET /api/1/deals |
| 勘定科目マスタ | GET /api/1/account_items |
| 取引先マスタ | GET /api/1/partners |
| 部門マスタ | GET /api/1/sections |
| 経費申請 | GET /api/1/expense_applications |
| ログインユーザーの権限 | GET /api/1/users/capabilities |
「先月の広告費」は取引一覧から数えてはいけない
実装でよくある間違いです。/deals（取引）を取ってきて合算すると、経理が入れた振替伝票や決算整理が漏れます。
金額を答えるなら試算表（trial_pl）を使ってください。freeeが計上ルールに従って集計した数字なので、経理が画面で見ている数字と一致します。個別の取引一覧は「内訳を見たい」と言われたときに出すものです。
trial_pl は会計期間や年月を指定して取得します。部門別が必要なら trial_pl_sections、タグ別なら trial_pl_segment_1_tags と、専用のエンドポイントが分かれています。「部門で絞る」を後から足そうとすると設計をやり直すことになるので、最初に決めてください。
最大の落とし穴：このAPIは書き込める
ここが一番重要です。freeeのAPIは参照専用ではありません。
会計APIのエンドポイントを実際に数えたところ、内訳はこうなっていました。
| 会計API | 本数 |
|---|---|
| 全エンドポイント | 96 |
| 参照のみ（GETだけ） | 43 |
| 書き込みを受ける | 53 |
| 削除できる | 20 |
| 承認アクション | 4系統 |
半分以上が書き込みを受けます。代表的なものを挙げると次のとおりです。
POST /api/1/deals——取引を作成できるPOST /api/1/manual_journals——振替伝票を作成できるPUT|DELETE /api/1/deals/{id}——取引を更新・削除できるPOST /api/1/deals/{id}/payments——支払いを記録できるGET|DELETE /api/1/wallet_txns/{id}——明細を削除できる
質問に答えるだけのつもりで作った仕組みが、技術的には仕訳を作れる・消せる・承認できる状態になっている——これは十分に起こります。
承認は1系統ではなく4系統ある
「承認だけ気をつければいい」と考えると足りません。承認アクションを受けるパスは4つあります。
POST /api/1/approval_requests/{id}/actions— 各種申請POST /api/1/expense_applications/{id}/actions— 経費申請POST /api/1/payment_requests/{id}/actions— 支払依頼POST /api/1/purchase_requests/{id}/actions— 発注
支払依頼と発注が承認できる状態は、金額が動く経路そのものです。
URLだけで参照専用にはできない
もうひとつ設計上の注意があります。同じURLがGETとPOSTの両方を受けるエンドポイントが18本あります。/api/1/deals がその代表で、取得も作成も同じパスです。
そのため「参照用のURLだけを許可する」というネットワーク側の制限では止まりません。止められるのは権限かHTTPメソッドのどちらかで、確実なのは前者です。
会計だけの話ではない
freeeは会計以外にもAPIを公開しています。人事労務APIは従業員情報・勤怠・年末調整を書き換えられます。「freeeと連携する」とだけ決めて権限を渡すと、想定していない範囲まで含まれることがあります。
どのサービスの、どの範囲かまで決めてから接続してください。
対策は難しくありませんが、明示的にやる必要があります。
- 接続に使うfreeeユーザーを、参照権限のみで作る——アプリ側の実装ではなく、freeeの権限設定で止める（共通アカウント型と権限引き継ぎ型の考え方）
- 実装側でもGET以外を発行しない——二重で止める
- 接続ユーザーの権限を
users/capabilitiesで確認する——想定より広くないか実際に見る
アプリ側だけで守る構成は、いつか破られる
1が本命です。実装を変えた誰かが、悪意なく書き込み系のAPIを呼びます。freeeの権限設定で止めておけば、実装が何をしようと書き込めません。
会計データは「聞き方」で答えが変わる
データが取れるようになった後の話です。同じ「先月の広告費」でも、条件で数字が変わります。
| 条件 | 数字が変わる理由 |
|---|---|
| 発生主義か現金主義か | 計上月と支払月がずれる |
| 税込か税抜か | 10%の差が出る |
| 締め処理の前か後か | 未計上の伝票がある |
| 部門を含めるか | 共通費の配賦有無 |
信頼は一度で失われる
AIが条件を明示せずに数字だけ返すと、受け取った側が違う前提で使います。会議で「広告費は先月300万でした」と言った数字が、経理の締め後の数字と合わない——こうなると、その後どれだけ精度を上げても使われません。
数字には必ず条件を添える
2026年7月の広告宣伝費：3,024,500円
（税抜・発生主義・締め処理済・全部門）
冗長に見えますが、この形でないと業務では使えません。条件が書かれていない数字は、経理担当が結局検算することになり、問い合わせは減りません。
勘定科目の使い方が組織によって違う
account_items で勘定科目マスタは取得できますが、取れるのは名前とコードであって、運用ルールではありません。
- 「消耗品費」と「事務用品費」の使い分けが担当者ごとに違う
- 過去に科目を変更していて、年度をまたぐと連続性がない
- 補助科目やタグ（
/tags）で実質的な分類をしている
AIは科目名から意味を推測しますが、その組織固有の運用は知りません。「広告費」と聞かれたときにどの科目を足すのかは、明示的に定義する必要があります。
定義を1枚作るところから
連携作業より先に、よく聞かれる費目の定義表を作ってください。「広告費＝広告宣伝費＋販売促進費（ただし展示会は除く）」といったものです。この1枚があるかないかで、回答の一貫性がまるで変わります。
誰に何を見せるかを先に決める
会計データは、社内でも見える範囲が明確に分かれています。ここを曖昧にしたまま全社に開けると、必ず問題になります。
- 役員報酬・人件費——ほぼ全社で機密。勘定科目単位で除外する
- 部門別損益——部門長までは開示、一般社員には非開示、という組織が多い
- 取引先ごとの単価——営業には見せたいが、他部署には見せられないことがある
freeeの権限が、そのまま効くわけではない
APIの接続ユーザーが1つだと、全員が同じ範囲を見ることになります。社員ごとに見える範囲を変えたいなら、AI側で制御する設計が別途必要です。ここを「freeeの権限で守られている」と誤解したまま全社に開けると、役員報酬が誰にでも見える状態になります。
実務的な出発点は「自部門の経費だけ」です。自分の部署がいくら使ったかを自分で確認できる。これだけで経理への問い合わせは目に見えて減ります。
締め前のデータをどう扱うか
月次締めが終わっていない期間のデータは、まだ動きます。ここをそのまま返すと、翌週には違う数字になります。
- 締め済みの月のみ回答する——最も安全。ただし「今月の状況」が見られない
- 締め前は「速報値」と明記して返す——実用的。多くの場合これで足りる
- 制限なし——誤解の元になりやすい
2番目を推奨します。「速報値（締め前・変動あり）」と併記されていれば、受け取る側が扱いを判断できます。
効果が出やすい問い合わせ
すべてを対象にする必要はありません。頻度が高く、定型で、機密性が低いものから始めると成果が早く出ます。
| 問い合わせ | 頻度 | 機密性 | 使うエンドポイント |
|---|---|---|---|
| 自部門の月次経費 | 高い | 低い | trial_pl_sections |
| 経費精算の申請状況 | 高い | 低い | expense_applications |
| 特定取引先への支払い履歴 | 中 | 中 | deals + partners |
接続先が本体と別条件になっていないか、確認した結果です
主要4サービスの契約条件をまとめた表です。OpenAI では Apps・MCP・Web検索がデータレジデンシーの対象外で、選んだリージョンの外に出ます。拡張機能まわりの別条件をサービスごとに書いています。
進め方
- 参照権限のみのfreeeユーザーを作る——ここを飛ばさない
- よく聞かれる費目の定義表を1枚作る
- 自部門の月次経費（
trial_pl_sections）だけで動かす - 回答に条件（税区分・締め状態・部門）を必ず併記する
- 問い合わせが減ったのを確認してから範囲を広げる
この記事について：エンドポイントの一覧と本数は、2026年8月時点で freee API に接続して取得した実際のパス一覧を数えたものです。公開されている全APIではなく、この環境から到達できた会計APIの範囲での集計です。freee は仕様の追加が続いているため、導入時にはご自身の環境で users/capabilities と実際のパス一覧を確認してください。「経理への問い合わせが集中する」といった記述は現場で観測した傾向であり、調査統計ではありません。
