--- title: "マネーフォワード APIとは：クラウド会計API v3の認証2方式と仕訳登録・取得をPythonで実装する手順" url: "https://www.issoh.co.jp/tech/details/19181/" published: 2026-11-02 updated: 2026-11-02 categories: ["業務システム"] publisher: "株式会社一創" --- # マネーフォワード 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）](https://developers.api-accounting.moneyforward.com/)に載っている操作は、大きく4つに分かれます。 | 区分 | リソース名 | 操作 | | ----- | --------------------- | ----------------------- | | 仕訳 | journals | 一覧・取得・作成・更新・削除 | | 明細・証憑 | transactions、vouchers | 明細の作成、明細からの仕訳作成、証憑の保存 | | 帳票 | reports | 残高試算表と推移表（BS・PL）の取得 | | マスタ | accounts、taxes ほか | 勘定科目・補助科目・税区分・部門・取引先の取得 | パスはいずれも`/api/v3/`の後ろにリソース名を続けます。2026年10月20日には自動仕訳ルールの取得・作成・更新・削除が加わりました。仕様書の`/v3/openapi.yaml`はダウンロードでき、型の生成やコード補完の入力に使えます。 ### 追加料金なしで使える条件と技術サポートが士業の公認メンバーに限られる点 [公式サポートの会計API案内](https://biz.moneyforward.com/support/account/guide/others/ot09.html)によると、クラウド会計・確定申告を利用開始していれば、会計APIは追加料金なしで使えます。ただし登録できる仕訳の件数などは、契約中の有償プランの制限と同じです。 見落としやすいのはサポートの範囲です。連携機能の実装は利用者自身が行う前提で、技術サポートの対象は有償の公認メンバーである士業事務所に限られています。一般の事業会社が自社開発する場合、仕様の不明点は仕様書とリリースノートを読んで自力で解く必要があります。 ### 認証用と会計API用で2つに分かれるホスト名の役割分担と呼び出し先 マネーフォワード クラウドのAPIは、認証と製品ごとのAPIでホストが分かれています。トークンの発行は[公式チュートリアル](https://developers.biz.moneyforward.com/docs/tutorials/getting-started-api-call-manually/step-2/)にあるとおり`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キー認証の解説](https://developers.biz.moneyforward.com/docs/common/api-keys/overview/)と会計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の仕組みと認可フローの解説](https://www.issoh.co.jp/tech/details/8369/)で扱っています。 ### アプリポータルの利用開始に要る全権管理権限とアプリ連携権限の付与 どちらの方式も、最初に「マネーフォワード クラウドのアプリポータル」の利用開始が要ります。利用開始には管理コンソールの「全権管理」権限が必要で、経理担当者だけでは進められない場合があります。開発の初日に、情報システム部門か全権管理者の時間を押さえておくのが近道です。 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`です。[トークンエンドポイントのリファレンス](https://developers.biz.moneyforward.com/docs/api/auth/create-token/)によると、クライアント認証はアプリの設定で`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に交換する手順](https://developers.biz.moneyforward.com/docs/tutorials/api-keys/step-2-exchange-for-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キー管理の解説](https://www.issoh.co.jp/tech/details/16300/)にまとめています。 ## 仕訳登録と取引データ取得の実装：事業者番号から仕訳作成までの手順 ### 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`は連携サービスID`connected_account_id`を指定して明細を登録するAPIで、1回に送れるのは1,000件までです。明細から仕訳を起こす`POST /api/v3/transactions/journalize`も用意されています。 使い分けの基準は「勘定科目を誰が決めるか」です。自社システム側で科目と税区分を確定できるなら、仕訳を直接作る。経理担当者が画面で確かめてから仕訳にしたい取引は、明細として送り、自動仕訳ルールに任せるほうが運用に合います。仕訳の起点をどこに置くかという整理は[経理システムと会計システムの違いの解説](https://www.issoh.co.jp/column/details/16461/)が参考になります。 ### URLエンコード済みIDを二重にエンコードして400になる失敗の防ぎ方 会計APIが返すIDは、`BowMhLnFvzZ1y9TeF5%2B3QQ%3D%3D`のように最初からURLエンコードされています。[仕様書の冒頭](https://developers.api-accounting.moneyforward.com/)には、この値をそのまま指定し、再びエンコードするとエラーになると明記されています。 問題になるのは、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のレート制限の説明](https://developers.api-accounting.moneyforward.com/rate%5Flimiter)では、アクセストークンを単位として、1秒間に実行できるリクエストを3回までとしています。上限を超えると429が返り、[API共通仕様](https://developers.biz.moneyforward.com/docs/common/api%5Fcommon%5Fspecifications/)のとおり本文のコードは`RATE_LIMIT_EXCEEDED`です。 月末に数万件の仕訳を送る処理なら、送信を順番待ちの列に入れて間隔を空ければ足ります。同じトークンを複数のワーカーで共有すると、合計で毎秒3回を超えて429が増えるので、並列化しても速くなりません。待ち時間を延ばしながら再試行する書き方は[リトライパターンと指数バックオフの解説](https://www.issoh.co.jp/tech/details/16185/)、429を前提にした設計は[APIレート制限の解説](https://www.issoh.co.jp/tech/details/16179/)を参照してください。 ### 再実行で同じ仕訳が2件できる問題を自社DBの対応表で防ぐ冪等化 仕訳作成のAPIには、重複を防ぐ冪等キーの仕組みがありません。タイムアウトで応答を受け取れなかった処理を単純に再送すると、同じ仕訳が2件できます。仕訳一覧の絞り込み条件も日付・勘定科目・明細IDなどに限られ、タグやメモでは検索できません。 防ぐ仕組みは呼び出し側で作ります。実務では、次の順で組めば十分です。 1. 自社DBに「元データのキー（受注番号など）と仕訳ID」の対応表を作り、送信前に状態を「送信中」で登録する 2. 201が返ったら仕訳IDを書き込み、状態を「完了」にする 3. 「送信中」のまま残った行は、取引日で仕訳一覧を取り、`memo`か`tags`に入れた元データのキーで照合してから再送するか決める この照合のために、メモかタグに元データのキーを必ず入れておきます。考え方の詳細は[冪等性と担保方法の解説](https://www.issoh.co.jp/tech/details/13382/)にまとめています。 ### APIキーは発行者、OAuthはシステムユーザーで残る操作履歴の違い [会計APIのリリースノート](https://developers.api-accounting.moneyforward.com/release-notes)によると、2026年10月13日から、APIキー認証による仕訳の登録・更新・削除と取引先の登録は、操作履歴にAPIキーの発行者が記録されるようになりました。OAuth 2.0は事業者単位の認可で個人を特定できないため、操作者はシステムユーザーと記録されます。 APIキーを個人のアカウントで発行すると、その人の退職時にキーと履歴の扱いが問題になります。連携専用のメンバーでキーを発行しておけば、人手の登録とシステムの登録を履歴で切り分けられます。 ## マネーフォワード API連携を自社開発すべき条件と見送るべき場面 ### 販売管理からの仕訳自動起票と複数事業者の横断集計なら自社開発 APIを使う開発に進む価値があるのは、次のどちらかが要件にある場合です。1つは、販売管理や受発注システムの確定データから、科目・税区分・取引先まで決めた仕訳を毎日自動で起票したい場合。もう1つは、会計事務所やグループ会社のように、複数の事業者の試算表や仕訳を1か所に集めて集計したい場合です。どちらも二重登録の防止、IDの対応表、毎秒3回の制御まで組み込む必要があり、コードで作るほうが確実です。会計事務所での使い方は[税理士が使う会計ソフトと連携方式の解説](https://www.issoh.co.jp/column/details/17057/)でも扱っています。 ### CSVインポートや既製の連携で足りる場面と受託開発へ相談する目安 月に数十件の仕訳を取り込むだけなら、APIを使う開発は過剰です。クラウド会計の仕訳インポートや既製の連携サービスで足り、保守の手間もかかりません。公式の案内にも、外部サービスを通じてノーコードで会計APIを使う選択肢が示されています。マネーフォワード クラウドを他社のバックオフィスSaaSと比べている段階なら、[バックオフィスSaaSの比較と連携の判断軸](https://www.issoh.co.jp/column/details/10661/)を先に読むと手戻りがありません。 一方、基幹システムとの双方向の連携、数万件規模の過去仕訳の移行、複数事業者をまたぐ集計のように、認証方式の選定から失敗時の再実行まで設計する必要がある場合は、要件定義の段階から開発会社に入ってもらうと安全です。一創の[API開発・システム連携サービス](https://www.issoh.co.jp/service/system/api/)では、会計SaaSと社内システムの連携を、要件整理から運用まで受託しています。REST APIの連携全般の実装手順は[API連携の実装方法の記事](https://www.issoh.co.jp/tech/details/15351/)も参考になります。 ## マネーフォワード APIの料金・個人利用・連携方式でよくある質問 マネーフォワード APIを使い始める実装者や担当者から出やすい質問に、公式ドキュメントの記載をもとに答えます。 ### マネーフォワード APIは無料で使えますか？ クラウド会計・確定申告を利用開始していれば、会計APIは追加料金なしで使えます。アプリポータルへのアプリ登録も無料です。ただし、APIで登録できる仕訳の件数などは、契約しているプランの制限がそのまま適用されます。クラウド会計を使っていない会社は、先にマネーフォワード クラウドの契約が必要です。 ### 個人でもマネーフォワードのAPIは使えますか？ 個人事業主がクラウド確定申告を使っている場合は、会計APIの対象です。事業者一覧の応答でも、個人事業主は`INDIVIDUAL`として返ります。一方、公式の会計API案内が対象としているのはクラウド会計・確定申告の利用者で、家計簿アプリのマネーフォワード MEは含まれていません。個人の家計データを自作のプログラムで取り出す用途は、この会計APIでは実現できないと考えてください。 ### 銀行口座の自動取得（データ連携）と会計APIは同じものですか？ 別のものです。データ連携は、マネーフォワード クラウドが銀行やカード会社から明細を取り込む機能を指します。会計APIは、自社のシステムが仕訳や明細を読み書きする仕組みです。銀行の明細が取り込めない、再連携を求められるといった症状は会計APIでは解決しないので、[マネーフォワードで連携できないときの対処法](https://www.issoh.co.jp/tech/details/12146/)を確認してください。 ### 登録した仕訳を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が示したコードのホスト名とパラメータは、仕様書の該当箇所と照らして確かめてください。 ## 関連記事 - [API連携の実装方法：REST・認証・エラー処理の手順をcurlとPythonのコード例で解説](https://www.issoh.co.jp/tech/details/15351/)：製品に依らないREST連携の基本手順 - [OAuthとは？OAuth 2.0の仕組み・認可フローと認証との違い、OAuth 2.1の変更点をわかりやすく解説](https://www.issoh.co.jp/tech/details/8369/)：認可コードフローとトークンの考え方 - [APIキー管理とは？発行・保管・失効とローテーションの実装を解説](https://www.issoh.co.jp/tech/details/16300/)：期限の無いAPIキーを安全に運用する方法 - [冪等性とは？読み方・意味からAPI・IaCでの担保方法まで実装者向けに解説](https://www.issoh.co.jp/tech/details/13382/)：仕訳の二重登録を防ぐ設計の土台 - [経理システムと会計システムの違い：業務範囲と仕訳の起点で分ける選定基準](https://www.issoh.co.jp/column/details/16461/)：どのシステムで仕訳を起こすかの整理 - [freee APIとは：会計APIの認可・事業所IDと取引登録をPythonで実装する手順と上限](https://www.issoh.co.jp/tech/details/19184/)：freee会計APIの事業所単位の認可・取引登録・1日上限との比較に --- 出典: [マネーフォワード APIとは：クラウド会計API v3の認証2方式と仕訳登録・取得をPythonで実装する手順]()（株式会社一創）