Claude Codeでマネーフォワード クラウドのAPIから請求書・見積書を発行する——認証の分かれ道と再現手順

私はクライアントのWeb制作にAIを組み込みながら、自社の業務基盤にも同じ道具を使っている。今回の狙いは「請求書と見積書の発行を、Claude Codeから直接やる」ことだ。自社のAIワークフロー基盤MIMIRではAPIでの見積書自動発行を実装済みだったので、公式のMCP連携ならもっと簡単に繋がるだろう——着手前はそう踏んでいた。

正直、これまでの請求書発行は地味に負担だった。Web画面を開き、ログインし、取引先を選び、品目と金額を打ち込む。一件あたり数分だが、その「ブラウザを開いて手を動かす」感覚が積もると重い。今は「ABC株式会社の請求書、Webサイト制作費、●●円を税抜きで」とClaude Codeに伝えるだけで下書きが出てくる。経理担当に「これ、やっておいて」と頼む感覚に近い。

最初の誤解——「MCPをつなげば請求書も出せる」は間違いだ

マネーフォワード クラウドは、AIエージェントから会計を操作できる公式のMCPサーバー（MCP＝AIエージェントとツールをつなぐ標準規格）を提供している。接続設定だけで仕訳や帳簿を参照できる、便利な入り口だ。私も最初は「これを繋げば請求書も見積書も同じ流れで出せる」と考えていた。

だが、ここが最初の落とし穴だった。公式MCPが対応するのは「クラウド会計」だけ。請求書・見積書・経費は対象外で、REST API（Web標準のHTTP通信でサービスを操作する仕組み）から叩く必要がある。ひとつの連携に見えて、実際は機能ごとに扉が分かれていた。

この「機能ごとに入り口が割れる」設計に、エンジニアとしては正直あまり合理性を感じない。OAuth認証があり、ユーザーごとに使える機能とスコープ（権限の範囲）を決められれば足りるはずだ。会計はMCP、請求書はREST、経費はさらに別のOAuth——では、繋ぐ側は単純に分かりにくい。おそらくサービスごとに開発時期や経緯が異なり、もともとはAIではなく自社開発アプリからの連携を前提に個別へ育ったのだろう。繋ぐ側にできるのは、この分かれ道を正しく地図にしておくことだけだ。

認証も機能ごとに別物——請求書APIはアプリ登録から始まる

手段だけでなく、認証も機能ごとに別物だった。会計は、発行したキーを短命なトークンに交換して使う手軽な方式が用意されている。私は当初、この会計用の認証情報でそのまま請求書APIも叩けると思い込んでいた。結果は認可の段階できっぱり拒否。会計用トークンには「会計の権限」しか乗っておらず、請求書の扉は開かなかった。

請求書APIの正しい入り口は、OAuth 2.0の認可コードフロー（利用者の許可を得てアクセス権を受け取る標準的な認証の流れ）だ。しかもその前提として、開発者ポータルでのアプリ登録が要る。会計用のキーを使い回そうとしたのが、遠回りの正体だった。

請求書APIのセットアップ：アプリ登録とループバックリダイレクトURI

土台づくりでやることは、アプリ登録・リダイレクトURIの設定・認証情報の保管の3つだ。

1. アプリを登録する。

開発者ポータルでアプリを作成する。入力はアプリ名称・リダイレクトURI・クライアント認証方式・利用規約への同意で、作成すると client_id と client_secret が発行される。

2. リダイレクトURIは「ループバック」に向ける。

ここでつまずく人が多い。手元のCLIツールにはWebサーバーのような公開URLが無い。そこで使うのがローカルループバック方式だ。リダイレクトURIに http://127.0.0.1:8080/callback を登録し、認証のときだけ自分のPC上の 127.0.0.1:8080 （ループバック）に小さな受信サーバーを一時的に立てる。ブラウザで承認すると認可コードがループバックに返るので、それを手元で受け取る。請求書側の認可サーバーはhttp のループバックを許可するので、証明書も要らない。ここでlocalhostではなくリテラルの127.0.0.1（IPv6なら[::1]）を使うのは、RFC 8252 §7.3 の推奨に沿ったものだ。localhost は端末の名前解決に依存し、意図せずループバック以外のインターフェイスで待ち受ける恐れがあるためである。なお、登録するリダイレクトURIと、ツールが実際に待ち受ける値は必ず一致させること（片方がlocalhost・片方が127.0.0.1 だと弾かれる）。

3. 認証情報はバージョン管理に含めない。

client_id／client_secret／リダイレクトURI／スコープ（読み取り用と書き込み用）を設定ファイルにまとめる。要点は、client_secret を含むこのファイルをGitの追跡から外すことだ。secretは「アプリになりすます合鍵」で、公開リポジトリに紛れれば第三者が自分の名義でAPIを叩ける。.gitignore にファイル名を書いて追跡から外し、値は直書きせず設定ファイルから読む。万が一露出させてしまったらポータルでsecretを再発行し、古い鍵を無効化する。

つないでみる：OAuthログインから疎通確認まで

土台ができたらログインだ。この節のとおり頼めば、同じ結果に辿り着けるはずだ。Claude Codeに「請求書APIにOAuthでログインして」と伝えると、エージェントが次の順で動く。

1. 認可URLを組み立ててブラウザで開く。
2. マネーフォワードの画面で「許可」を押す。
3. ブラウザが 127.0.0.1:8080 に認可コードを返す。
4. エージェントがそのコードをトークンのエンドポイントに渡し、access_token（APIを叩く鍵）と refresh_token（鍵の再発行に使う控え）を受け取って保存する。

ブラウザに「認証が完了しました」、ターミナルに「トークンを保存しました」と出れば成功だ。access_token は短命なので、切れても refresh_token で自動更新するようにしておく。

繋がったかは、書き込みを伴わない疎通確認で確かめる。自社情報を返すエンドポイントを叩き、正常応答（200）と会社名が返れば扉は開いている。

GET https://invoice.moneyforward.com/api/v3/office
→ 200 OK  { "office": { "name": "（あなたの会社名）", ... } }

弾かれるなら、原因はスコープ不足かトークン未取得のどちらかだ。ログインからやり直す。

ループバックのhttpは危なくないのか——公衆WiFiでの注意

http://127.0.0.1:8080/callback の「http（暗号化なし）」を見て、公衆WiFiで危険ではないかと感じる人もいるだろう。結論から言えば、この部分は設計上安全だ。127.0.0.1（ループバック）宛ての通信は自分のPCの中だけで完結し、WiFiやネットワークには一切流れない。だからカフェやホテルの回線を盗聴されても、ここに認可コードが漏れることはない。OAuthのネイティブアプリ向け標準（RFC 8252）がループバックに限ってhttpを許すのは、このためだ。実際のやり取りの本体——マネーフォワードへのログイン、コードとトークンの交換、その後のAPI通信——はすべてHTTPSで暗号化されている。

とはいえ、公衆WiFiで作業するなら守るべき点はある。

• ブラウザの証明書警告は無視しない。 「この接続は保護されていません」が出たら中断する。HTTPSを破ろうとする攻撃はここで弾ける。
• 受信サーバーは自分のPC（127.0.0.1）だけで待ち受ける。 全インターフェイスで開くと、同じWiFiの別端末から触れる余地が出る。
• 共用PC・ネットカフェの端末では認証しない。 ループバックが安全なのは「自分だけが使うPC」が前提だ。
• 本当に守るべきは、保存されたトークンだ。 access／refreshトークンはAPIを叩ける鍵そのものなので、保存先の権限管理に気を配り、共有フォルダには置かない。

不安なら、初回の認証だけは信頼できる回線（自宅・オフィス）で済ませておけばよい。一度トークンを取得すれば、以後は自動更新で回る。

請求書・見積書を発行する：取引先ID・税区分・支払期限・ドライラン

発行に要る材料は多くない。請求書の必須項目は取引先（部門ID）・請求日・支払期限、見積書は取引先・見積日・有効期限。品目は明細としてまとめて渡す。用語を補足しておく。

• 部門ID（department_id）：宛先を指定するID。取引先の下に「部門」がぶら下がる構造なので、宛名は会社名ではなくこのIDで指定する。取引先一覧から名前で引いておく。
• 税区分（excise）：品目にかかる消費税の区分。10%・軽減8%・非課税・対象外などが決まった文字列で用意されている。
• ドライラン：実際には送らず「これから送る中身」だけを表示する空撃ち。

いちばん大事にしたのが、このドライランを既定にすることだった。書き込み操作はデフォルトで送信せず、送る予定の内容だけを表示する。金額と宛先を確認し、承認して初めて発行に進む。この流れで、本番の請求書サービスに対し、送付しない下書きとして請求書を1件作成した。税込金額も支払期限の自動設定も狙いどおりに動いた。

支払期限は迷いどころなので式にする。私の会社は「月末締め・翌月末払い」なので、支払期限は「納品日の翌月末」で自動計算する。発行が月初にずれ込んでも同じ結果に着地する。

下書き後の「送信」は、あえて自動化していない。作成した請求書はUIの「送信する」ボタンか、PDFのメール添付で送る。ここが、金額と宛先をもう一度人の目で確かめる二段目のゲートになる。請求書のように会社の信用へ直結し、間違えれば相手に迷惑をかける業務は、たとえ送信までAPIでできても人の最終確認を外すべきではない。仮に将来それが可能になっても、この承認ゲートだけは残す。

領収書だけはAPIに無い——UIで請求書から変換する

2026年7月現在、請求書API v3に領収書のエンドポイントが無い。APIで扱えるのは事業所・取引先・品目・請求・見積・送付履歴だけで、領収書という入り口はどこにも無かった。運用で割り切り、領収書はUIの「請求書から領収書へ変換」で作る。請求書PDFで代替する手もある。「できないこと」を早く確定させるのも、地図を描く大事な作業だ。

PDFはリンクで共有できない——トークン必須のAPIとして扱う

発行した請求書のPDFは、APIが /api/v3/billings/{請求ID}.pdf というURLを返す。私は最初これをブラウザで開こうとして、また一度つまずいた。開けない。理由は、これが「共有リンク」ではなく認証トークン必須のAPI URLだからだ。ブラウザで開いても認証が付かず弾かれる。だからPDFは、Claude Codeにトークン付きで取得させ、手元に保存する「データ」として扱う。取得したPDFは請求書番号入りのファイル名（例：請求書_（請求書番号）.pdf）で、請求日の年月フォルダに自動保存する。番号と月で一発でたどり着ける。

発行したあとに直す——更新リクエストでは明細が変わらない

見積書は、出したら終わりではない。「件名を変えたい」「この項目は要らない」「もう少し詰めたい」——相手に渡す前の調整は、むしろ必ず入る。実際にここでいちばん時間を取られたので、結論から書く。

更新リクエスト（PUT＝既存データの書き換え）で明細を送っても、明細は更新されない。

私は改訂した中身をまとめて PUT /api/v3/quotes/{見積ID} に投げた。応答は 200（正常）。件名もちゃんと新しくなっている。ところが読み直すと、明細が1行も変わっていなかった。消したはずの項目が残り、値引きしたはずの単価も元のまま。当然、合計金額も動いていない。

PUT /api/v3/quotes/{見積ID}   ← 件名と明細をまとめて送る
→ 200 OK
   件名：新しい件名に変わっている
   明細：1行も変わっていない（消したはずの項目が残っている）
   小計：変わっていない

理由は、明細が見積書本体とは別のリソースとして管理されているからだ。/api/v3/quotes/{見積ID}/items という明細専用の入り口があり、見積書本体の更新リクエストに明細を混ぜても黙って捨てられる。エラーにならないのがいちばん怖い。 成功の応答が返ってくるので、確認しなければ「直したつもりの、古い金額の見積書」がそのまま残る。

まだ相手に送っていないなら、作り直すのが確実だった。いったん削除して、新しい内容で作成する。ただし副作用がある。

• 見積番号が採番し直される。 削除した番号は欠番になる。番号を保ちたいなら、APIではなくUIで直す。
• 送付済みのものは削除しない。 相手が受け取った書類の番号が消えるのは事故だ。調整が要るならUIで直すか、新しい番号で出し直して前のものを取り消す。電子帳簿保存の観点でも、最終合意に至ったものだけでなく、交渉過程で相手に送付したものも残しておく必要がある。

金額は「書き込みの応答」ではなく「読み直し」で確かめる

前節の落とし穴は、書き込みの応答を信じたことが原因だった。金額を扱うAPIで最後に頼りにすべきは、応答ではなく読み直しだ。発行・更新・削除のあとに、もう一度その書類を取得して、最低この2点を確認する。

• 明細の金額を足した数が、小計と一致するか。 ズレていたら、意図しない行が残っているか、消したはずの行が消えていない。
• 値引きの行が、マイナスの数字で入っているか。

2つ目については、過去に出した見積書を点検していて、値引き行が1件だけプラスの数字になっているものを見つけた。10%の値引きのはずが、引かれるどころか加算されていた。幸いそのまま請求書に変換する形では使用されていなかったが、一瞬ヒヤリとした。符号の間違いは、人の目では驚くほど見落とす。だから機械で検算する。

そのほか、細かいがつまずいた点も残しておく。

• PDFを取るときは「書類の種類」を間違えない。 請求書と見積書でURLが別なので、見積書のIDを請求書として取ろうとすると 404（見つからない）が返る。IDは正しいのに「そんなIDは無い」と言われるので気をつける。
• 見積番号は自分で決めなくていい。 発行するとサービス側が採番する。リクエストに番号を書く必要はない。
• トークンが切れていても、まず読み取りを1回叩く。 「期限切れ」と表示されても、控えの鍵で自動更新が走る。慌てて再ログインしなくてよい。

そして、この調整作業もドライランと同じ考え方で守る。更新も削除も、既定では実行せず「これから何をするか」だけを表示させ、承認してから初めて実行する。 発行だけを慎重にしても、後から入る修正が素通しなら、事故の入り口は残ったままだ。とくに削除は取り消せないので、送付済みかどうかを先に確かめる一手を挟んでおく。

マネーフォワード クラウドAPIの地図——請求書・見積書はここから

今回の“入り口”の地図をまとめておく。

つまずいた場所は、どれも「公式ドキュメントを一枚に束ねれば避けられた」ものばかりだった。だからこの地図を残す。

経理や請求まわりの手作業を減らしたい経営者・個人事業主で、技術の細部はよく分からないという人へ。難しく考える必要はない。この記事のURLをそのままClaude Codeに渡し、ステップバイステップで進めるのが近道だ。参照すべきリファレンスのURLさえ渡せば、Opusモデルで十分に実装まで辿り着けるはずだ。

この記事で紹介したサービス

マネーフォワードクラウド

4,480円／月（スモールビジネスプラン）

会計・経費精算・請求書・電子契約・社保・給与・債務支払など、法人運営に必要なサービスが全部入り。会計だけ、請求書だけ、といったシングルユースだと割高だけど、複数サービスをまとめて利用するなら非常にコスパが良い。Claude CodeやCodexから操作が可能なMCPやAPIも用意されているので、with AI時代のマイクロ法人運営に最適。

参考ドキュメント

• マネーフォワード クラウド 開発者サイト
• MCPサーバー（会計）
• クラウド会計 MCPサーバーについて
• 認可サーバーAPI（認可・トークン）
• クラウド請求書 APIについて
• クラウド請求書 API v3 リファレンス
• クラウド経費 APIドキュメント