freee API・マネーフォワード APIで請求書自動化【2026年】

freee APIやマネーフォワードのAPIを使えば、請求書の作成・明細の差し替え・入金ステータスの更新までは自動化できます。ただしどちらもメール送付のAPIはありません。経理担当のいない僕の会社では、Claude CodeからAPIを叩いて下書きを作り、送付と金額の最終確認だけを人がやる形で、2026年8月稼働分の請求書20枚を送り切りました。

freee APIやマネーフォワード APIで、請求書のどこまでを自動化できるのか？

作成・更新・取消・入金ステータスの更新はAPIで完結します。できないのはメール送付で、freeeもマネーフォワードも送付用のエンドポイントがありません。僕の会社の実際の分担は、AIがAPIで下書きを作り、人が金額を見てGOを出し、送付は画面の「一括メール送信」で行う、という3段です。

請求書APIとは、会計・請求書サービスの請求書データを、画面を開かずにプログラムから作成・取得・更新するための窓口です。株式会社ウラカタはマーケティング支援の会社で、社員は少なく、経理担当がいません。2026年8月末で業務委託の経理を解約し、今は僕とAI（Claude Code）で請求から入金確認までを回しています。

Claude Codeとは、Anthropicが提供する、ファイルの読み書きやコマンドの実行まで含めてClaudeに作業を任せられるツールです。僕はコードを書けませんが、「この請求書を先月と同じ明細で今月分を作って」と頼めば、Claude CodeがAPIのドキュメントを読み、リクエストを組み、結果を確かめるところまでやってくれます。業務での使い方の全体像は Claude Codeの業務活用事例 にまとめています。

まず、2026年10月時点で公式ドキュメントから確認できた「APIでできること・できないこと」を表にします。

freeeの請求書作成は「freee請求書API」の担当です。freee会計APIにもかつて請求書の作成がありましたが、インボイス制度に合わせて2023年10月にfreee請求書APIへ移されました。今の会計APIに残る請求書系は取得（GET）だけです。古いブログ記事の手順をそのまま試すとここでつまずくので、エンドポイントの所属は最初に確かめてください。

なぜ経理担当がいないのに、請求書をAPIで回そうと思ったのか？

理由は、手が足りないことより「月末に思い出す」運用が限界だったからです。請求漏れも、金額の取り違えも、原因はほぼ記憶に頼っていたことでした。APIで下書きを先に作り、人は差分だけを見る形にすれば、ドラフトに載っていない＝請求漏れ、と機械的に気づけます。

僕の会社は2026年8月18日に、会計と請求書の基盤をfreeeからマネーフォワード クラウドへ移すと決めました。比べたのは請求書の作り方だけではありません。外注先から受け取る請求書のOCR、支払の承認、振込データの出力まで含めて、支払側の機能が厚いほうを選びました。請求書の作成APIはどちらにもあります。

運用の設計で一番効いたのは、役割を反転させたことです。以前は僕が「今月はこれを請求して」と思い出して指示を出していました。今はAIが全取引先分の下書きを先に出し、僕は「ここは今月なし」「この案件は金額が変わった」と差分だけを返します。思い出すより、目の前のリストを見て違和感に気づくほうがずっと楽です。

マスタと差分の2階建てにしたのも同じ理由です。請求マスタとは、取引先ごとの品目・単価・税区分・件名の型・送付方法・支払サイトを1回だけ書いておく台帳のことです。月ごとの変化は「今月から運用費が増える」のような自然文1行でClaude Codeに投げるだけにしました。表計算シートに入力列を足す案もありましたが、既存のシートで管理番号の列が空欄のまま放置されていたので、入力の手間を増やす設計は続かないと判断して捨てました。

摘要は「案件名｜対象月稼働分」で型を固定し、追加の作業は摘要に混ぜずに必ず別の明細行にしています。継続の請求とスポットの請求を、後から機械が見分けられるようにするためです。

マネーフォワード APIで実際にハマった仕様は何か？

一番大きかったのは、請求書の更新APIに明細を入れても、成功が返るのに明細が変わらないことです。2026年9月15日の実測で、PUT /billings/{id} に items を入れると200が返り、明細はそのままでした。明細を直したいときは、新しい行を追加してから古い行を消すしかありません。

公式のAPI仕様（OpenAPI定義）を見ると理由が分かります。請求書の更新リクエストに載っている項目は、件名・メモ・日付・請求書番号・備考・タグなどで、明細（items）は最初から含まれていません。存在しない項目は黙って無視されるので、エラーにならずに成功だけが返ってきます。

明細単体の更新も同じです。/billings/{id}/items/{item_id} に用意されているのは取得（GET）と削除（DELETE）だけで、更新（PUT）はありません。実際にPUTを送ると404でした。1行の金額だけを直したいときも、行を作り直すことになります。

僕たちが落ち着いた手順はこうです。

1. 作業前に GET /billings/{id} の結果をJSONファイルで保存する（元に戻すため）
2. 新しい明細を POST /billings/{id}/items で上から順に追加する
3. 古い明細を DELETE /billings/{id}/items/{item_id} で消す
4. もう一度GETして、行の並びと合計を確かめる

追加を先にするのは、明細が0行になる瞬間を作らないためと、並び順を崩さないためです。注意点として、明細の追加（POST）は201が返るものの本文が空で、新しい行のIDは返ってきません。消したい古い行のIDは、事前に保存したJSONから拾います。

同じ「成功が返るのに変わらない」は、ほかにも2か所ありました。1つは請求書の送付元住所のブロックで、請求書の更新APIで書き換えても値は変わりません。送付元は事業者情報の側で持っていて、画面か事業者情報の更新API（PUT /office）で直すものでした。もう1つは消費税の端数処理で、請求書の更新APIに入れても据え置かれ、僕たちは請求書の編集画面の詳細設定タブで直しました。端数処理の既定は切り捨てなので、税抜の小計によっては税込合計が1円少なくなります。

レート制限にも気をつけています。レート制限とは、一定時間内に送れるAPIリクエストの回数の上限のことです。マネーフォワードの会計APIは1つのアクセストークンあたり1秒3回まで、請求書APIも特定のエンドポイントで1秒3回までと公式に書かれています。20枚前後を一気に作るときは、Claude Codeに間隔を空けて送らせています。

freee APIとマネーフォワード APIは、認証やプラン条件がどう違うのか？

大きな違いはトークンの寿命です。freeeはアクセストークン6時間・リフレッシュトークン90日、マネーフォワードはアクセストークン1時間・リフレッシュトークン540日です。どちらもOAuth2.0で、レート制限と帳票の上限はプランや窓口ごとに条件が違います。

OAuth2.0とは、パスワードを渡さずに、アプリへ期限付きの「合鍵（トークン）」を発行して操作を許す仕組みです。リフレッシュトークンとは、期限が切れたアクセストークンを取り直すための、長持ちする鍵のことです。2026年10月時点の公式ドキュメントの記載を表にします。

表の「—」は、今回確認した公式ページで記載を見つけられなかった項目です。推測では埋めていません。

運用で効いてくるのはリフレッシュトークンの扱いです。freeeは公式に「1つのリフレッシュトークンで2度アクセストークンを取得することはできない」と書かれていて、取り直すたびに新しいリフレッシュトークンを保存し直す必要があります。保存に失敗したり、2つの処理が同時に取り直したりすると、もう一度ブラウザで認可をやり直すことになります。僕の会社ではトークンをmacOSのキーチェーンに置いていますが、同じ名前の項目が2つできてしまい、片方だけ更新される事故が一度ありました。それ以降は両方に書き込むようにしています。

プランの話も1つ。マネーフォワードの一括メール送信は、法人ではビジネスプランだけの機能です。僕の会社は2026年9月7日にビジネスプランの年払い（月6,480円）を契約しました。月に20枚前後を発行するので、下位プランではAPIで作れる請求書が100件までという上限とあわせて、ビジネスプランが事実上の前提でした。

なお、AIからAPIを呼ぶ窓口として、MCPという標準規格もあります。MCPとは、AIと外部のツールやデータをつなぐための共通の接続規格です。仕組みは MCPとは何か で解説しています。僕の会社の請求書まわりは、MCPではなくClaude Codeが直接APIを叩く形で動かしています。

メール送信APIが無いのに、請求書の送付はどうしているのか？

送付は人が画面で行っています。APIで宛先まで整えておき、マネーフォワードの請求書一覧で対象をまとめて選び、「一括メール送信」を押す形です。2026年9月12日には、この手順で12枚を1回で送りました。案件ごとに一文を足したい請求書だけは、1枚ずつ送っています。

送付を回すには、取引先マスタにメールアドレスが入っていることが前提です。ところが2026年9月5日に取引先75社を調べると、送付先メールが入っている会社は1社もありませんでした。前の運用では、メールを手で打っていたからです。翌日、回収できた宛先をAPIの取引先部門の更新（PUT /partners/{id}/departments/{dep_id}）でまとめて登録し、GETで取り直して登録内容と一致することを確かめました。

一括メール送信には、公式ヘルプに書かれた制約がいくつかあります。

• 一度に選べる帳票は最大100件
• 宛先（TO）は1件だけ、CCは半角カンマ区切りで最大10件
• TOとCCに同じアドレスは入れられない
• メール定型文の件名と本文は、帳票ごとに編集できない

本文が編集できないので、「この1通は運用費、もう1通は機材の購入分です」のような説明が要る請求書だけは、単発のメール送信に回しています。単発送信の本文には、請求書のダウンロード用URLが入る目印の文があります。公式ヘルプには、この文を編集したり削除したりするとメールが送信できないと書かれているので、本文を差し替えるときも必ずそのまま残しています。

送付が終わったら、APIの GET /sent_histories と請求書の email_status で、全通が送られたかを確かめます。email_status は未送信・送付済み・受領済みなどの値をとり、相手がダウンロードしたかどうかまで分かります。8月稼働分の20枚は、9月6日に6枚を単発送信で、9月12日に残り14枚を一括12枚と単発2枚に分けて送り、この確認で全通の送付を確かめました。

送付の「送信する」ボタンは、AIのブラウザ操作で押すこともできます。ただ対外発信なので、押す前に必ず僕が金額と宛先を見てGOを出すルールにしています。Claude Codeの操作を規則で縛る方法は Claude Codeのフック の記事にも書きました。

入金消込はAPIでどこまで自動化できるのか？

照合の材料集めと、結果の書き込みは自動化できます。照合そのものは自前のルールで、金額・振込名義・時期の3点を見ています。2026年9月30日には、この手順で16枚を入金済みにしました。金額が一致しただけでは消し込まないのが、一番大事なルールです。

入金消込とは、口座に入ってきたお金を、どの請求書の支払いかと突き合わせて「入金済み」にする作業です。マネーフォワードには消込専用のAPIが無いので、僕たちは次の順で回しています。

1. マネーフォワード クラウド会計の画面で、口座の「一括再取得」を押し、最終取得日時が今の時刻付近に更新されるのを待つ
2. 会計APIの GET /api/v3/transactions で入金明細を取る
3. 請求書APIの GET /billings で未入金の請求書を取る
4. 金額・振込名義（カナ）・時期の3点で照合する。複数枚の合算も見る
5. 確定したものだけ PUT /billings/{id}/payment_status で入金済みにし、GETで取り直して確かめる

1番目の再取得は、失敗から生まれたルールです。2026年9月10日、再取得前のデータで照合して、ある取引先の入金を「まだ入っていない」と報告しました。実際は同じ日に入金されていて、口座データの取り込みが遅れていただけでした。会計APIには再取得のエンドポイントも、最終取得日時を返す項目も無いので、APIだけ見ていると古さに気づけません。それ以来、再取得はAIがブラウザで押し、「正常」に戻るまで見届けてから照合しています。

5番目にも小さな罠がありました。payment_status に送る値は、日本語の「入金済み」ではなく数字の文字列です。公式仕様では "0" が未設定、"1" が未入金、"2" が入金済みで、日本語を送ったら422エラーが返りました。

金額だけで照合してはいけない理由は、実例で説明できます。ある取引先から、今月の請求と同じ金額の入金がありました。金額だけ見れば今月分ですが、中身は前の月の請求の支払いでした。今月分は2枚まとめて月末に払う、と先方から連絡をもらっていたので気づけました。ほかにも、2〜3枚の請求書を合算して振り込む取引先や、会社名と違う個人名で振り込む取引先があります。僕たちはこの癖を取引先ごとの表にして、照合のたびにAIに読ませています。

消込でつまずいた話や、AI導入で起きがちな失敗のパターンは AI導入の失敗事例 にも整理しています。

請求書のPDF保管はどうしているのか？

発行した請求書のPDFは、Googleドライブの共有ドライブに月別・発行月基準で保管しています。freeeから移行するときは、過去分のPDFを画面から取得してドライブに入れました。2026年8月21日に、6月分19通と7月分16通、計35通を格納しています。

フォルダの構造は「年 ＞ ◯月分 ＞ 請求分（自社発行）／支払分（受け取った請求書）」です。月の判定は件名ではなく請求日（発行日）で揃えています。件名が「5月分費用」でも6月に発行したなら6月分に入れる、というルールにしておくと、あとで探すときに迷いません。ファイル名は「宛先＋敬称＿件名＿請求書＿請求書番号」の型に統一しています。

一つ注意があります。今回確認したfreee請求書APIの公式スキーマには、PDFを取得するエンドポイントがありません。そのため、移行時のPDFは画面から取得しました。APIでPDFまで自動で保管する仕組みを考えている場合は、この点を先に確かめておくと設計で迷いません。

ドライブへのアップロードにも小さな罠がありました。ブラウザのドライブ画面からアップロードすると、フォルダを開いていても共有ドライブの一番上に置かれてしまうことがありました。今はアップロード用のスクリプトで、フォルダを指定して直接入れています。

AIに任せても、人が必ず確認する工程はどこか？

送付・金額・銀行操作の3つは、必ず人が見ます。AIが作るのは下書きまでで、対外に出る瞬間と、お金が動く瞬間には人の判断を挟みます。間違えたときに取り返しがつかないか、相手の信頼を損ねる工程だけを人に残し、それ以外は任せる、という線引きです。

具体的な分担を表にします。

金額の確認で、実際に人の目が効いた例があります。交通費などの立替実費を請求書に載せるとき、領収書の金額は税込です。それを税抜の単価欄にそのまま入れて外税10%を乗せると、消費税を二重に請求してしまいます。2026年9月28日、取引先の経理担当の方からこの指摘を受けました。今は「税込の実額 ÷ 1.1」で税抜に割り戻し、明細の補足に「領収書実額 税込◯円」と書いています。たとえば税込11,000円のタクシー代なら、単価は10,000円です。検算は、税込合計が領収書の合計とぴったり合うかで見ています。

0円の明細行を消さないのも、人が決めたルールです。0円でも、その月に何を納品したかを示す記録になるからです。AIは合計に影響しない行を「整理」しがちなので、元のデータにある行は0円でもすべて残すように指示しています。

銀行の操作は、AIの担当範囲から完全に外しています。ログイン、振込データの取り込み、承認はすべて人です。さらに、振込の依頼と承認を同じ人に持たせないようにしました。依頼する人と承認する人を二人に分けておけば、片方が見落としても、もう片方が気づけます。

課題もまだ残っています。委託経理を解約してから、請求・送付・消込は回るようになりましたが、帳簿づけ（仕訳）は追いついていません。空いたのは手よりも「期日と整合性を見張る目」だと分かり、支払期日のアラートを週次の経理チェックに組み込んだところです。

まとめ

• freee APIもマネーフォワード APIも、請求書の作成・更新・取得はできるが、メール送付のAPIは無い（2026年10月時点の公式仕様）
• マネーフォワードの請求書更新APIは明細を受け付けないので、明細は「追加してから古い行を削除」で作り直す
• 入金消込は専用APIが無く、口座の再取得をしてから、金額・振込名義・時期の3点で照合する
• 経理担当がいなくても、AIが下書きと照合を担い、人が送付・金額・銀行操作だけを見る分担で、8月稼働分20枚を送り切り、9月30日の照合では16枚を入金済みにできた
• APIの仕様は「成功が返るのに反映されない」ものがあるので、書き込んだら必ずGETで取り直して確かめる

Claude Codeを毎日こうした実務で回すときの費用感は、Claude Codeの料金と上限の実録 にまとめています。定期実行の仕組みに興味がある方は Claude Codeのヘッドレス実行 もあわせてどうぞ。同じ仕組みを自社の経理に入れたい、という相談は ウラカタのサービス一覧 から受けています。