業務システム

マネーフォワード APIとは：クラウド会計API v3の認証2方式と仕訳登録・取得をPythonで実装する手順

マネーフォワード APIとは：クラウド会計API v3の認証2方式と仕訳登録・取得をPythonで実装する手順

マネーフォワード APIは、マネーフォワード クラウドの会計・請求書・経費などのデータを、自社のシステムからHTTPで読み書きするためのAPI群です。この記事では、中心となるクラウド会計API（V3）を対象に、OAuth 2.0とAPIキーという2つの認証方式の選び方、トークンの取得、Pythonでの仕訳の登録と取得、毎秒3回のレート制限と二重登録への備えまでを、コード例付きで説明します。公式ドキュメントには書き分けられていない「実装で詰まる箇所」を中心に整理しました。仕様と数値は2026年11月時点の公式ドキュメントに基づきます。

まとめ：マネーフォワード APIで会計連携を作る前に決める認証方式と上限

販売管理や基幹システムから仕訳を自動で起票する連携なら、APIキー認証で作るのが基本形です。APIキーには期限がなく、書き込みの操作履歴には発行した担当者の名前が残ります。利用者が自分の事業者を画面から選んで接続するWebサービスを作る場合だけ、OAuth 2.0を選びます。

つまずく場所は決まっています。会計APIのホストは認証用のapi.biz.moneyforward.comとは別であること、APIキー認証では事業者番号office_codeが必須であること、勘定科目は名前ではなくIDで送ること、IDは最初からURLエンコード済みで二重にエンコードすると失敗すること。この4つを先に押さえれば、試行錯誤の大半は省けます。

運用面の上限は、アクセストークンごとに毎秒3回です。APIには冪等キーの仕組みが無いため、再実行で同じ仕訳が2件できない設計は呼び出し側で作ります。

マネーフォワード APIの全体像と会計APIの範囲・料金・ホスト構成

クラウド会計API v3で操作できる仕訳・明細・試算表・マスタの範囲

クラウド会計APIの仕様書（V3）に載っている操作は、大きく4つに分かれます。

区分 リソース名 操作
仕訳 journals 一覧・取得・作成・更新・削除
明細・証憑 transactions、vouchers 明細の作成、明細からの仕訳作成、証憑の保存
帳票 reports 残高試算表と推移表（BS・PL）の取得
マスタ accounts、taxes ほか 勘定科目・補助科目・税区分・部門・取引先の取得

パスはいずれも/api/v3/の後ろにリソース名を続けます。2026年10月20日には自動仕訳ルールの取得・作成・更新・削除が加わりました。仕様書の/v3/openapi.yamlはダウンロードでき、型の生成やコード補完の入力に使えます。

追加料金なしで使える条件と技術サポートが士業の公認メンバーに限られる点

公式サポートの会計API案内によると、クラウド会計・確定申告を利用開始していれば、会計APIは追加料金なしで使えます。ただし登録できる仕訳の件数などは、契約中の有償プランの制限と同じです。

見落としやすいのはサポートの範囲です。連携機能の実装は利用者自身が行う前提で、技術サポートの対象は有償の公認メンバーである士業事務所に限られています。一般の事業会社が自社開発する場合、仕様の不明点は仕様書とリリースノートを読んで自力で解く必要があります。

認証用と会計API用で2つに分かれるホスト名の役割分担と呼び出し先

マネーフォワード クラウドのAPIは、認証と製品ごとのAPIでホストが分かれています。トークンの発行は公式チュートリアルにあるとおりhttps://api.biz.moneyforward.comの/authorizeと/tokenで行います。一方、会計APIの本番環境はhttps://api-accounting.moneyforward.comです。

開発者サイトの共通説明にはapi.biz.moneyforward.com/{service}/api/v1/...という形式の例が出てきますが、会計APIのV3はこの形式ではありません。共通説明のURLに会計APIのパスを足しても動かないので、呼び出し先は会計APIの仕様書のservers欄で確かめてください。なお、旧版のV1とV2は2025年9月30日に提供を終えています。

認証方式をOAuth 2.0とAPIキーから選ぶ判断とアプリポータルの準備

OAuth 2.0とAPIキーを権限・事業者範囲・操作履歴で比べる早見表

2つの方式の違いを、APIキー認証の解説と会計APIの仕様書をもとに整理すると次のとおりです。

項目 OAuth 2.0 APIキー
何の権限で動くか アプリポータルで付けた権限 発行した人のクラウド会計の権限
事業者の指定 認可時に画面で1つ選ぶ 呼び出しごとにoffice_code
トークンの期限 アクセス1時間、リフレッシュ540日 キーは無期限、JWTは1時間
操作履歴の記録 システムユーザー APIキーの発行者
向いている用途 利用者が自分の事業者を接続するサービス 社内の自動連携、複数事業者の横断

会計APIは2026年9月24日から全エンドポイントでAPIキーに対応しました。複数の事業者を1つのキーで横断する使い方は、公式案内でもAPIキーを指定しています。顧問先やグループ会社のデータをまとめて扱う仕組みはAPIキーで作ってください。OAuth 2.0の認可フローそのものはOAuth 2.0の仕組みと認可フローの解説で扱っています。

アプリポータルの利用開始に要る全権管理権限とアプリ連携権限の付与

どちらの方式も、最初に「マネーフォワード クラウドのアプリポータル」の利用開始が要ります。利用開始には管理コンソールの「全権管理」権限が必要で、経理担当者だけでは進められない場合があります。開発の初日に、情報システム部門か全権管理者の時間を押さえておくのが近道です。

OAuth 2.0では、アプリポータルの「ユーザー」画面で、連携操作をする人に「アプリ連携権限」の「アプリ連携」と「クラウド会計・確定申告」を付けます。APIキーでは、新規登録画面の「利用可能サービス」で「事業者情報」と「クラウド会計・確定申告」の両方にチェックを入れます。キーを有効にする事業者は発行後も変えられるので、最初は検証用の事業者だけに絞って発行するのが無難です。

OAuth 2.0の認可コードからアクセストークンを得るcurlの手順

OAuth 2.0は認可コードフローです。ブラウザで認可エンドポイントを開き、ログインと事業者の選択、連携の許可を経て、リダイレクトURIにcodeが付いて戻ります。そのコードをトークンエンドポイントへ送ります。

# 1. ブラウザで開く（scope は使うAPIに合わせてスペース区切りで並べる）
https://api.biz.moneyforward.com/authorize?response_type=code&client_id=${CLIENT_ID}&scope=mfc/accounting/journal.read%20mfc/accounting/journal.write%20mfc/accounting/accounts.read&redirect_uri=${REDIRECT_URI}&state=${STATE}

# 2. リダイレクト先に付いた code をトークンに交換する（CLIENT_SECRET_BASIC の場合）
curl -s -X POST "https://api.biz.moneyforward.com/token" \
  -u "${CLIENT_ID}:${CLIENT_SECRET}" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=authorization_code" \
  -d "code=${AUTH_CODE}" \
  -d "redirect_uri=${REDIRECT_URI}"

スコープは会計APIの仕様書で各エンドポイントに書かれており、仕訳の読み取りがmfc/accounting/journal.read、書き込みがmfc/accounting/journal.writeです。トークンエンドポイントのリファレンスによると、クライアント認証はアプリの設定でCLIENT_SECRET_BASIC（Basic認証）かCLIENT_SECRET_POST（本文に入れる）のどちらかに決まります。設定と送り方が食い違うと401になるので、アプリ詳細画面で確認してから書いてください。

使い捨てで540日有効なリフレッシュトークンを保存し損ねる落とし穴

アクセストークンは1時間、リフレッシュトークンは540日有効で、どちらの期限も変えられません。注意点は、リフレッシュトークンが1回しか使えないことです。更新のたびに新しいリフレッシュトークンが返り、古いアクセストークンもその時点で使えなくなります。

新しいリフレッシュトークンを保存する前に処理が落ちると、次回の更新ができず、利用者に認可をやり直してもらうしかありません。更新処理は「トークン取得」と「保存」を1つのトランザクションに入れ、複数のプロセスが同時に更新しないよう排他をかけます。トークンエンドポイントにもレート制限があるため、APIを呼ぶたびにトークンを取り直す書き方は避け、401が返ったときだけ更新します。

APIキーをauth/exchangeでJWTに交換し1時間使い回すPythonの書き方

APIキーはそのままでは会計APIに送れません。APIキーをJWTに交換する手順のとおり、POST https://api.biz.moneyforward.com/auth/exchangeにキーを送ると、1時間有効なJWTが返ります。交換エンドポイントの上限はAPIキーごとに毎分100回です。

# pip install requests
import os
import time

import requests

AUTH_URL = "https://api.biz.moneyforward.com/auth/exchange"
BASE = "https://api-accounting.moneyforward.com/api/v3"
_cache = {"token": None, "exp": 0.0}


def get_jwt() -> str:
    # 期限の60秒前までは同じJWTを使い回す（交換は毎分100回まで）
    if _cache["token"] and time.time() < _cache["exp"] - 60:
        return _cache["token"]
    r = requests.post(
        AUTH_URL,
        headers={"Authorization": f"Bearer {os.environ['MF_API_KEY']}"},
        timeout=10,
    )
    r.raise_for_status()  # 401 は INVALID_API_KEY（無効化・入力ミス）
    body = r.json()
    _cache.update(token=body["access_token"], exp=time.time() + body["expires_in"])
    return _cache["token"]


def call(method: str, path: str, **kw):
    for _ in range(5):
        r = requests.request(
            method, BASE + path,
            headers={"Authorization": f"Bearer {get_jwt()}"},
            timeout=30, **kw,
        )
        if r.status_code != 429:
            r.raise_for_status()
            return r.json()
        time.sleep(1)  # 毎秒3回の上限。1秒空けて再試行する
    raise RuntimeError("429 が続いたため中断")


# APIキーで操作できる事業者の一覧（ここだけ office_code が不要）
for office in call("GET", "/accessible_offices")["accessible_offices"]:
    print(office["code"], office["name"], office["type"])

APIキーは発行時に一度しか表示されず、期限もありません。漏れた場合の被害が長く続くため、環境変数かシークレット管理サービスに置き、コードやリポジトリに残さないでください。保管と失効の手順はAPIキー管理の解説にまとめています。

仕訳登録と取引データ取得の実装：事業者番号から仕訳作成までの手順

APIキー認証で必須になる事業者番号office_codeの取得と指定

APIキー認証では、GET /api/v3/accessible_offices以外のすべての呼び出しで、クエリのoffice_codeに事業者番号（1234-5678の形式）を付けます。付け忘れると、どの事業者のデータかが決まらずエラーになります。OAuth 2.0では認可時に事業者を選んでいるため、このパラメータは無視される仕様です。

事業者一覧の応答にはtype（法人はCORPORATE、個人事業主はINDIVIDUAL）と会計年度も入っています。複数事業者のキーでは、意図しない事業者へ書き込む事故を防ぐため、処理対象の事業者番号を設定ファイルで固定し、一覧の結果をそのまま全件ループに回さない作りにしておきます。

勘定科目を名前でなくIDで送る仕訳作成のJSONと貸借300行の上限

仕訳の作成はPOST /api/v3/journalsです。仕様書の定義では、必須項目は取引日transaction_date、仕訳種別journal_type（通常はjournal_entry、決算整理はadjusting_entry）、行の配列branchesの3つで、行は1件の仕訳あたり最大300行まで。各行の借方debitorと貸方creditorには、金額と勘定科目IDを必ず入れます。

OFFICE = "1234-5678"  # accessible_offices で得た code

# 勘定科目は名前ではなくIDで指定する。先に名前→IDの対応表を作る
accounts = call("GET", "/accounts", params={"office_code": OFFICE, "available": "true"})["accounts"]
acc = {a["name"]: a["id"] for a in accounts}

payload = {
    "journal": {
        "transaction_date": "2026-11-02",
        "journal_type": "journal_entry",
        "memo": "販売管理 受注番号 SO-2026-0042",  # 200字まで
        "tags": ["SO-2026-0042"],                 # 1タグ20字まで
        "branches": [{
            "debitor": {"account_id": acc["売掛金"], "value": 110000},
            "creditor": {"account_id": acc["売上高"], "value": 110000},
            "remark": "11月分 保守料",
        }],
    }
}
created = call("POST", "/journals", params={"office_code": OFFICE}, json=payload)
print(created["journal"]["id"])  # 更新・削除で使うID。自社DBに保存しておく

税区分はGET /api/v3/taxesで取ったIDを各行のtax_idに、取引先はtrade_partner_codeに入れます。インボイスの区分はinvoice_kindで、適格請求書はINVOICE_KIND_QUALIFIED、経過措置の8割控除はINVOICE_KIND_UNQUALIFIED_80のように指定します。勘定科目名は事業者ごとに変えられるため、名前の対応表はハードコードせず、起動時にAPIから取り直すほうが安全です。

仕訳一覧の取得は開始日か終了日の指定が必須で1ページ最大1万件まで

GET /api/v3/journalsは、start_dateとend_dateのどちらかを指定しないと呼べません。返るのは指定日を含む会計期間の仕訳に限られるため、期をまたいで集めるときは会計期間ごとに分けて呼び出します。1ページの件数per_pageは既定10件、最大10,000件で、応答のmetadata.total_pagesを見てpageを進めます。

page, rows = 1, []
while True:
    res = call("GET", "/journals", params={
        "office_code": OFFICE,
        "start_date": "2026-04-01", "end_date": "2026-11-30",
        "per_page": 1000, "page": page,
    })
    rows += res["journals"]
    if page >= res["metadata"]["total_pages"]:
        break
    page += 1
print(len(rows), "件")

既定の10件のまま回すと、1万件の仕訳で1,000回の呼び出しになり、毎秒3回の上限で5分以上かかります。月次の取り込みならper_pageを1,000前後まで上げ、呼び出し回数を減らしてください。

明細の一括作成は1回1000件まで、明細からの仕訳作成との使い分け

仕訳を直接作る方法とは別に、明細を作って画面上で仕訳に変える経路もあります。POST /api/v3/transactionsは連携サービスIDconnected_account_idを指定して明細を登録するAPIで、1回に送れるのは1,000件までです。明細から仕訳を起こすPOST /api/v3/transactions/journalizeも用意されています。

使い分けの基準は「勘定科目を誰が決めるか」です。自社システム側で科目と税区分を確定できるなら、仕訳を直接作る。経理担当者が画面で確かめてから仕訳にしたい取引は、明細として送り、自動仕訳ルールに任せるほうが運用に合います。仕訳の起点をどこに置くかという整理は経理システムと会計システムの違いの解説が参考になります。

URLエンコード済みIDを二重にエンコードして400になる失敗の防ぎ方

会計APIが返すIDは、BowMhLnFvzZ1y9TeF5%2B3QQ%3D%3Dのように最初からURLエンコードされています。仕様書の冒頭には、この値をそのまま指定し、再びエンコードするとエラーになると明記されています。

問題になるのは、HTTPクライアントが自動でエンコードする場合です。Pythonのrequestsはparamsに渡した値をエンコードするため、%2Bが%252Bに変わります（requests 2.34系で確認できる挙動）。勘定科目IDで仕訳を絞り込むaccount_idや、仕訳IDを含むパス/journals/{id}では、IDを文字列のままURLに連結し、paramsに入れないでください。逆に、JSON本文に入れるaccount_idは文字列として送られるので、返ってきた値をそのまま入れて問題ありません。

本番運用で詰まる上限：毎秒3回のレート制限と二重登録・操作履歴

アクセストークン単位で毎秒3回の制限と429を受けたときの待ち方

会計APIのレート制限の説明では、アクセストークンを単位として、1秒間に実行できるリクエストを3回までとしています。上限を超えると429が返り、API共通仕様のとおり本文のコードはRATE_LIMIT_EXCEEDEDです。

月末に数万件の仕訳を送る処理なら、送信を順番待ちの列に入れて間隔を空ければ足ります。同じトークンを複数のワーカーで共有すると、合計で毎秒3回を超えて429が増えるので、並列化しても速くなりません。待ち時間を延ばしながら再試行する書き方はリトライパターンと指数バックオフの解説、429を前提にした設計はAPIレート制限の解説を参照してください。

再実行で同じ仕訳が2件できる問題を自社DBの対応表で防ぐ冪等化

仕訳作成のAPIには、重複を防ぐ冪等キーの仕組みがありません。タイムアウトで応答を受け取れなかった処理を単純に再送すると、同じ仕訳が2件できます。仕訳一覧の絞り込み条件も日付・勘定科目・明細IDなどに限られ、タグやメモでは検索できません。

防ぐ仕組みは呼び出し側で作ります。実務では、次の順で組めば十分です。

  1. 自社DBに「元データのキー（受注番号など）と仕訳ID」の対応表を作り、送信前に状態を「送信中」で登録する
  2. 201が返ったら仕訳IDを書き込み、状態を「完了」にする
  3. 「送信中」のまま残った行は、取引日で仕訳一覧を取り、memoかtagsに入れた元データのキーで照合してから再送するか決める

この照合のために、メモかタグに元データのキーを必ず入れておきます。考え方の詳細は冪等性と担保方法の解説にまとめています。

APIキーは発行者、OAuthはシステムユーザーで残る操作履歴の違い

会計APIのリリースノートによると、2026年10月13日から、APIキー認証による仕訳の登録・更新・削除と取引先の登録は、操作履歴にAPIキーの発行者が記録されるようになりました。OAuth 2.0は事業者単位の認可で個人を特定できないため、操作者はシステムユーザーと記録されます。

APIキーを個人のアカウントで発行すると、その人の退職時にキーと履歴の扱いが問題になります。連携専用のメンバーでキーを発行しておけば、人手の登録とシステムの登録を履歴で切り分けられます。

マネーフォワード API連携を自社開発すべき条件と見送るべき場面

販売管理からの仕訳自動起票と複数事業者の横断集計なら自社開発

APIを使う開発に進む価値があるのは、次のどちらかが要件にある場合です。1つは、販売管理や受発注システムの確定データから、科目・税区分・取引先まで決めた仕訳を毎日自動で起票したい場合。もう1つは、会計事務所やグループ会社のように、複数の事業者の試算表や仕訳を1か所に集めて集計したい場合です。どちらも二重登録の防止、IDの対応表、毎秒3回の制御まで組み込む必要があり、コードで作るほうが確実です。会計事務所での使い方は税理士が使う会計ソフトと連携方式の解説でも扱っています。

CSVインポートや既製の連携で足りる場面と受託開発へ相談する目安

月に数十件の仕訳を取り込むだけなら、APIを使う開発は過剰です。クラウド会計の仕訳インポートや既製の連携サービスで足り、保守の手間もかかりません。公式の案内にも、外部サービスを通じてノーコードで会計APIを使う選択肢が示されています。マネーフォワード クラウドを他社のバックオフィスSaaSと比べている段階なら、バックオフィスSaaSの比較と連携の判断軸を先に読むと手戻りがありません。

一方、基幹システムとの双方向の連携、数万件規模の過去仕訳の移行、複数事業者をまたぐ集計のように、認証方式の選定から失敗時の再実行まで設計する必要がある場合は、要件定義の段階から開発会社に入ってもらうと安全です。一創のAPI開発・システム連携サービスでは、会計SaaSと社内システムの連携を、要件整理から運用まで受託しています。REST APIの連携全般の実装手順はAPI連携の実装方法の記事も参考になります。

マネーフォワード APIの料金・個人利用・連携方式でよくある質問

マネーフォワード APIを使い始める実装者や担当者から出やすい質問に、公式ドキュメントの記載をもとに答えます。

マネーフォワード APIは無料で使えますか？

クラウド会計・確定申告を利用開始していれば、会計APIは追加料金なしで使えます。アプリポータルへのアプリ登録も無料です。ただし、APIで登録できる仕訳の件数などは、契約しているプランの制限がそのまま適用されます。クラウド会計を使っていない会社は、先にマネーフォワード クラウドの契約が必要です。

個人でもマネーフォワードのAPIは使えますか？

個人事業主がクラウド確定申告を使っている場合は、会計APIの対象です。事業者一覧の応答でも、個人事業主はINDIVIDUALとして返ります。一方、公式の会計API案内が対象としているのはクラウド会計・確定申告の利用者で、家計簿アプリのマネーフォワード MEは含まれていません。個人の家計データを自作のプログラムで取り出す用途は、この会計APIでは実現できないと考えてください。

銀行口座の自動取得（データ連携）と会計APIは同じものですか？

別のものです。データ連携は、マネーフォワード クラウドが銀行やカード会社から明細を取り込む機能を指します。会計APIは、自社のシステムが仕訳や明細を読み書きする仕組みです。銀行の明細が取り込めない、再連携を求められるといった症状は会計APIでは解決しないので、マネーフォワードで連携できないときの対処法を確認してください。

登録した仕訳をAPIで修正・削除できますか？

できます。PUT /api/v3/journals/{id}で更新、DELETE /api/v3/journals/{id}で削除という分担です。どちらも仕訳作成と同じmfc/accounting/journal.writeのスコープ、APIキーでは仕訳の編集権限が要ります。{id}には作成時の応答で返った仕訳IDを使うので、作成直後に自社DBへ保存しておくと後の特定が楽です。

API仕様書を生成AIに読ませて実装を進めることはできますか？

公式が想定している使い方です。会計APIの仕様書ページから、OpenAPI形式のopenapi.yamlをダウンロードでき、サポートページでも生成AIへ取り込んで不明点の解消に使うよう案内されています。各エンドポイントの必須項目やスコープ、エラーの定義はこのファイルに入っています。ただし、AIが示したコードのホスト名とパラメータは、仕様書の該当箇所と照らして確かめてください。

関連記事

お気に入りに入れた記事の一覧

一創の公式 SNS

X では毎朝の新着記事と IT ニュースの速報を、YouTube・TikTok・Instagram・LinkedIn・Facebook では記事の解説動画を配信しています。

この記事に関連するサービス

資料請求

今日のトレンド記事 直近 24 時間で、いつもより多く読まれている記事

  1. 2026.10.29　テックブログ ソニー生命の不正アクセス：38.5万件の対象確認と窓口、停止中の手続き
  2. 2026.10.31　テックブログ osinaの情報漏洩：約23万人の対象確認とSNS連携の解除、分析ツールへ渡すデータの絞り方
  3. 2026.10.31　テックブログ 松屋の不正アクセス：237万件の対象確認と窓口、漏れたパスワードの守り方
  4. 2026.11.01　テックブログ RAGTAGの情報漏洩：延べ約120万件の対象項目と会員の備え、侵入から検知まで11日の意味
  5. 2026.05.18　テックブログ マネーフォワードで連携できない・失敗するときの対処法｜エラー別の原因と再連携のやり方

RELATED POSTS 関連記事

一覧へ戻る

目次