API キーとは何か — 渡すと相手に何ができるか、失効させると何が止まるか
API を呼ぶときの認証方式には、OAuth（受付が発行する入館証）のほかに API キーがあります。こちらは注意が要ります。
渡した後に何ができるか — 範囲も期限もない
API キーは、扉の鍵の複製、つまり「合鍵」に近い性質です。1 つの文字列（キー）を持っていれば呼び出せるので、範囲も期限も基本的にありません。そして無効にするには「錠を替える」＝キーを再発行するしかなく、その鍵を使っている連携が全部止まります。 だから配り方と保管が問題になります。
| 方式 | 渡した後にできること |
|---|---|
| OAuth（入館証） | 入れる範囲と期限が決まっている。受付で即失効でき、相手にパスワードは渡らない |
| API キー（合鍵） | 範囲も期限も基本的にない。無効にするにはキーの再発行が要り、その鍵を使っている連携が全部止まる |
API キーが悪いわけではありません。社内の 1 つの連携ツールだけに渡す、といった用途なら十分に実用的です。困るのは「誰に何本渡したか分からなくなる」ことと、「1 本を止めたいのに全部止まる」ことの 2 つです。
配り方・保管・失効 — 確かめる 3 点
| 確かめること | API キーで起きること | 見る場所・聞くこと |
|---|---|---|
| 配り方 | アカウントに 1 本のことが多い。複数の連携に同じ 1 本を渡すと、後で切り分けられない | 「キーは何本発行できますか」「キーごとに権限を分けられますか」 |
| 保管 | 文字列そのものが鍵。設定ファイルやメールに残れば、それだけで複製が増える | 連携ツール側の「資格情報の保管方法」（暗号化して保管しているか） |
| 失効 | 再発行すると、同じキーを使う連携は同時に止まる | 「再発行したとき、ほかの連携はどうなりますか」 |
システムによっては、この弱点を設計で補っています。board は 2 方式の併用が必須で、① API キー（アカウントで 1 つ発行）＋ ② API トークン（複数発行でき、トークンごとに利用できるエンドポイントを指定できる）という設計です。OAuth はありませんが、トークン単位で範囲を絞れるようにしてあります。こうした違いは各システムの「認証」欄に出ます（RenkeiMap の調査記録）。
調査記録で確かめる
例として経理・会計のカテゴリで見ます。認証の方式と、選べる手段の 2 列です。
比較項目:
| システム | 業務ワークフロー円滑度 |
|---|---|
| API の認証方式 | |
| バクラク | ○API認証情報発行第三者認証ID／認証キー 会社が発行する API 認証情報を使う ベンダー公表 API を使う相手を認証するための情報は、会社の側から発行される。その情報は自分の費用と責任で厳重に管理するものとされ、第三者に使わせたり貸したり譲ったりすることはできない。ただし、社内やその業務関係者に個別サービスを使わせる目的の範囲でなら、使わせてよいとしている。発行された認証情報を使った利用は、本人による利用とみなされる。方式の名前（OAuth なのか鍵ひとつなのか）は規約には書かれていない。 |
| board | ○APIキーAPIトークン 2方式の併用が必須: ①APIキー（x-api-key ヘッダー・アカウントで1つ発行）＋②APIトークン（Authorization: Bearer・複数発行可でトークンごとに利用可能エンドポイントを指定可）。OAuthなし ベンダー公表board APIドキュメン…()ほか 1 件
採取元: board APIドキュメント（認証・認可）・board APIドキュメント（APIキー）・board APIドキュメント（APIトークン）
調査日 |
| e-Tax | ○APIキーメールでの発行申請利用規約への同意OAuth なし API はAPIキー（API認証情報）方式で、専用アドレスへのメールでの発行申請と利用規約への同意が要る。セルフサービスで即時発行される OAuth なしの方式。利用者側の認証はマイナンバーカード等の電子証明書と利用者識別番号。 ベンダー公表国税電子申告・納税システムA…()
国税電子申告・納税システムAPI（ご利用に当たって） ベンダー公表 ℹ️発行申請書・変更届出書は Word 形式で配布され、メール件名の書式まで指定されている。開発者ポータルやコンソールで自動発行する仕組みは公開されていない。
採取元: API認証情報（APIキー）・同上・同上（利用規約）
調査日 |
| eLTAX / PCdesk | ○利用者ID暗証番号マイナンバーカード電子証明書 利用者IDと暗証番号、またはマイナンバーカードで本人確認する。送信する申告データには電子証明書による電子署名を付ける。マイナンバーカードでのログインは利用申請が要る。 |
| freee会計 | ◎OAuthスコープ OAuth2（authorization_code）。 |
| freee申告 | ログイン試行回数の制限リスクベース認証 サービスへのログインは freee アカウント。ログイン試行回数の制限に加え、リスクベース認証（普段と異なる環境からのログインはアカウントロック）を実施。 |
| invox | ◎OAuth2.0アクセストークンクライアントID OAuth 2.0。認可を経て発行したアクセストークンで呼ぶ。クライアント ID はベンダーが発行する（自己登録ではない）。 |
| ジョブカン会計 | ○アクセストークン Bearer トークン認証 編集部確認 仕様書が宣言する方式は Bearer トークンのみ（HTTP Authorization ヘッダー）。加えて会社を特定する Jbc-Api-Client-Id、年度データを特定する X-Api-Data-Key といった独自ヘッダーが必須。 編集部確認ジョブカン会計API 仕様書…()
ジョブカン会計API 仕様書（認証） 編集部確認 ℹ️保存済みドキュメントに埋め込まれた OpenAPI 定義の securitySchemes は Bearer（type: http, scheme: bearer）1件のみ（編集部が機械的に確認）。申請フォームには「OAuth 2.0 認証による自社サービス・アプリとの連携」という選択肢と Callback URL の入力欄があり、OAuth を使う経路は個別申請の中で案内される模様だが、公開仕様書には OAuth の定義は無い。
採取元: ジョブカン会計API 仕様書（認証）
調査日 |
| Misoca | ◎OAuth2readwrite OAuth2.0。スコープは read と write の 2 つ（write があれば読み込みもできる）。トークンの有効期間は 1 日で、必要に応じてリフレッシュする。 |
| マネーフォワード クラウド会計 | ◎OAuthAPIキー |
| マネーフォワード クラウド経費 | ◎OAuthアクセストークン OAuth 2.0（Authorization Code Grant）。securityDefinitions は `mf_expense_oauth`（authorizationUrl /oauth/authorize、tokenUrl /oauth/token）。 ／ スコープ6種：office_setting:write（事業者の設定から事業者の従業員の設定まで管理）／user_setting:write（ユーザー自身の設定）／transaction:write（明細の読み書き）／report:write（申請の読み書き）／account:write（連携サービスの管理）／public_resource:read（公開リソースの読み込み）。 ベンダー公表Swagger 定義（sec…()ほか 1 件
moneyforward/expense-api-doc README（2026-08-02 取得） 編集部確認 ℹ️アクセストークンには有効期限があり、リフレッシュトークンによる更新、即時無効化（revoke）、有効性確認のエンドポイントが用意されている。
採取元: moneyforward/expense-api-doc README・Swagger 定義（securityDefinitions.mf_expense_oauth.scopes）・moneyforward/expense-api-doc README（トークン操作）
調査日 |
| マネーフォワード クラウド請求書 | ◎OAuthAPIキー 認可は OAuth 2.0。マネーフォワード クラウド共通では OAuth 2.0 による認可と API キーによる認証の 2 方式がある。 |
| 楽楽精算 | ―IPアドレス制限SSLクライアント認証 API 自体の認証方式（トークン／OAuth 等）は公開されていない。公開されているのはアクセス制限側の話で、「IPアドレス制限オプション」「SSLクライアント認証オプション」を契約している場合、API 連携の実行プログラムが到達できるよう、前者はアクセス元サーバーの IP を登録、後者はアクセス元サーバーに SSL クライアント証明書をインストールする必要があると明記されている。 編集部まとめ出典()
|
| TKC FX2クラウド | ― つなぐときにどうやって身元を確かめるのかを書いた記載は、開いた範囲には無い。銀行やクレジットカードのデータを受け取る機能については、インターネットバンキングの契約や明細照会サービスの登録が要ること、提携先の利用規約への同意が要ることが案内されているが、これは相手側の手続きの話で、つなぎ方の認証方式ではない。 ベンダー公表会計ソフト FXクラウドシリ…()ほか 1 件
|
| TOKIUM | ◎SAMLメールアドレス権限 メールアドレスとパスワード、SAML ベンダー公表 画面にログインする方法として、メールアドレスとパスワードによる認証と SAML による認証が提供されている。SAML があるということは、会社の ID 基盤に寄せた運用ができる。管理者権限と承認者権限は利用ユーザーごとに設定でき、管理者によるユーザーの追加と凍結、利用者自身によるパスワードの再設定の機能がある。管理者権限を持つユーザーは、申込書に書かれたメールアドレス宛に発行される。なお、これは画面にログインするための話で、API を呼ぶときの認証方式は公開されていない。 ベンダー公表セキュリティホワイトペーパー…()
採取元: セキュリティホワイトペーパー（8.2 特権的アクセス権）・セキュリティホワイトペーパー（5.18 アクセス権）・セキュリティホワイトペーパー（5.16）
調査日 |
| 弥生（会計/青色申告 オンライン/Next） | ― 第三者が叩ける公開 Web API が無いため認証方式も無い 調査日 |
◎ 条件なしで当てはまる ○ 条件つき・一部 △ 限定・要申請・無いと明記 × 当てはまらないと明記 ？ 編集部がまだ確認していません ― 提供元が公開していない（編集部が調べた） — 記号は編集部の札から機械で付けています。物差しは項目ごとに違い、列の見出しがその項目の意味です。札の意味と根拠は各セルの要約を押すと出ます。
材料の調査日（最新）: 2026-09-03