freee Developers Communityで経費API活用ガイド：OAuth2.1・Webhook・ノーコード

2026年7月17日

バックオフィス職での転職を考えている人

スポンサードリンク

その頑張り、評価されていますか？

バックオフィスの努力が"経営の要"として評価される会社、あります

業務効率化を調べる時間、電子帳簿保存法を勉強する時間、締め作業で残業する夜——バックオフィスを"経営の要"として評価する会社と、"コスト部門"扱いする会社は、驚くほど別世界です。今のあなたの努力は、正しく評価されていますか？

▷「業務改善を頑張るほど、なぜか報われない気がする」あなたへ

Backup Careerは事務職転職に特化した支援サービス。無料の"仕事適性診断"を受けると、今の職種の延長線だけでなく"経理→労務"や"総務→秘書"などの隣接領域を含めた自分の伸びしろが可視化されます。担当のキャリアアドバイザーはマンツーマンで、"大手エージェントで求人メールだけ送られた"経験のある方こそ、肩を張らないカジュアルな相談ができます。ブラック企業を紹介しない方針＋入社後の定着率93.5%で、「今度こそ長く続けられる会社」に出会えます。

Backup Career｜事務職転職に特化のオンライン支援・満足度4.3・定着率93.5%

Backup Careerで無料キャリア相談を予約する

今すぐ辞める必要はありません。まず"適性診断だけ"受けて自分の市場価値を測る場所として使えます。今日の10分が、来年の働き方を変えます。

Contents

1 freee Developers Community の概要と利用開始手順
2 アプリ登録方法
- 2.1 必要情報の入力例と注意点
3 OAuth 2.1（PKCE 推奨）認可フロー
4 Expense Claims API のエンドポイントと主要パラメータ
5 エラーハンドリングのベストプラクティス
- 5.1 Python での包括的リトライ例（tenacity ライブラリ使用）
6 Webhook によるリアルタイム同期
- 6.1 Webhook 登録手順と署名検証
  - 6.1.1 Python（Flask）での署名検証例
  - 6.1.2 Node.js（Express）での署名検証例
- 6.2 実装例：expense.created → Google Drive に領収書保存
7 ノーコード・ローコード連携例と実装サンプル
8 テスト環境（Sandbox）での検証から本番移行、セキュリティと ROI の測定
9 まとめと次のステップ

スポンサードリンク

freee Developers Community の概要と利用開始手順

freee の経費精算を自動化したい場合、まずは freee Developers Community にアカウントを作成し、API 利用のためのアプリ登録を行います。開発者ポータルでは OAuth 2 系列（2024 年以降は PKCE が推奨）による認可フローが標準化されており、サンドボックス環境で安全にテストできます。本セクションでは、アカウント作成から本番利用までの全体像を俯瞰します。

開発者ポータルへサインアップ
URL: https://developer.freee.co.jp/
企業メールアドレスで登録し、メール認証を完了させます。
「My Apps」から新規アプリを作成
後述の「アプリ登録方法」で必要項目を入力します。
サンドボックス環境で OAuth フローと API 呼び出しを検証
テスト用クライアント情報は本番とは別に管理し、環境変数経由でコードに組み込みます。

アプリ登録方法

このセクションでは、freee 開発者ポータル上で 実際にアプリを作成 する手順と、設定すべき項目のポイントを解説します。

必要情報の入力例と注意点

項目	推奨設定例・ポイント
アプリ名	社内で一意に分かる名称（例：`ExpenseAutomation-Prod`）
説明文	目的を簡潔に記載。例: 「社員の経費申請を自動化し、承認フローと領収書保存を連携」
リダイレクト URI	本番環境は `https://api.example.com/oauth/callback` 、テスト環境は `https://sandbox-api.example.com/oauth/callback` のように HTTPS を必ず使用し、環境ごとに別々に登録する
スコープ	必要最小限の権限だけを付与。経費操作の場合は `expenses.read expenses.write` が基本です
Webhook 設定（任意）	後述の「Webhook の登録手順」で別途設定可能

実運用向けヒント
- リダイレクト URI は本番とテストで完全に分離し、環境変数 FREEE_REDIRECT_URI で管理するとミスが減ります。
- クライアントシークレットは決してコードベースにハードコーディングせず、AWS Secrets Manager・Azure Key Vault 等の安全なストレージへ保存してください。

作成後に クライアント ID と クライアントシークレット が発行されます。これらは API 呼び出し時の認可フローで必須になるため、忘れずにメモしておきましょう。

OAuth 2.1（PKCE 推奨）認可フロー

freee の認可エンドポイントは OAuth 2 系列 を採用しています。2024 年以降のガイドラインでは PKCE (Proof Key for Code Exchange) が「推奨」されており、特にサーバーレスやモバイルアプリでのセキュリティが大幅に向上します。本節ではフロー全体を図解しながら、Python と Bash の実装例を示します。

フロー概要（図）

クライアント側で Code Verifier と Code Challenge を生成
認可リクエスト (/oauth/authorize) に code_challenge を付与してユーザーへリダイレクト
ユーザーが同意 → リダイレクト URI に code が返る
トークンエンドポイント (/oauth/token) へ code_verifier と共に POST
アクセストークン取得 → API 呼び出し時の Bearer ヘッダーに設定

Code Verifier / Challenge の生成（Python）

import base64, hashlib, secrets

def generate_pkce_pair() -&gt; tuple[str, str]:
    verifier = secrets.token_urlsafe(64)                     # 43~128文字推奨
    challenge = (
        base64.urlsafe_b64encode(hashlib.sha256(verifier.encode()).digest())
        .rstrip(b'=').decode()
    )
    return verifier, challenge

verifier, challenge = generate_pkce_pair()
print(f&quot;Verifier: {verifier}\nChallenge: {challenge}&quot;)

import base64, hashlib, secrets

def generate_pkce_pair() -> tuple[str, str]:

verifier = secrets.token_urlsafe(64) # 43~128文字推奨

challenge = (

base64.urlsafe_b64encode(hashlib.sha256(verifier.encode()).digest())

.rstrip(b'=').decode()

)

return verifier, challenge

verifier, challenge = generate_pkce_pair()

print(f"Verifier: {verifier}\nChallenge: {challenge}")

ポイント
- verifier は 43〜128 文字の URL 安全な文字列で、サーバー側に送信しません。
- challenge を認可リクエストの code_challenge パラメータに使用します。

認可リクエスト URL（例）

https://accounts.freee.com/oauth/authorize?
  response_type=code&amp;
  client_id={CLIENT_ID}&amp;
  redirect_uri={REDIRECT_URI}&amp;
  scope=expenses.read%20expenses.write&amp;
  code_challenge={CHALLENGE}&amp;
  code_challenge_method=S256

https://accounts.freee.com/oauth/authorize?

response_type=code&

client_id={CLIENT_ID}&

redirect_uri={REDIRECT_URI}&

scope=expenses.read%20expenses.write&

code_challenge={CHALLENGE}&

code_challenge_method=S256

上記 URL はブラウザで開くか、フロントエンドから window.location.href に設定してください。

アクセストークン取得（cURL）

curl -X POST https://accounts.freee.com/oauth/token \
  -d &quot;grant_type=authorization_code&quot; \
  -d &quot;client_id=${FREEE_CLIENT_ID}&quot; \
  -d &quot;code=${AUTHORIZATION_CODE}&quot; \
  -d &quot;redirect_uri=${FREEE_REDIRECT_URI}&quot; \
  -d &quot;code_verifier=${PKCE_VERIFIER}&quot;

curl -X POST https://accounts.freee.com/oauth/token \

-d "grant_type=authorization_code" \

-d "client_id=${FREEE_CLIENT_ID}" \

-d "code=${AUTHORIZATION_CODE}" \

-d "redirect_uri=${FREEE_REDIRECT_URI}" \

-d "code_verifier=${PKCE_VERIFIER}"

取得した access_token は 30 分（デフォルト）有効です。期限が切れたら同様のフローで再取得してください。

Expense Claims API のエンドポイントと主要パラメータ

本章では、経費精算に関わる主要 API エンドポイントを 概要説明 → パラメータ表 → 実装サンプル の順に示します。各リクエストは必ず Authorization: Bearer {TOKEN} ヘッダーを付与してください。

エンドポイント一覧

メソッド	エンドポイント	主な機能
POST	`/api/v1/expenses`	経費申請の新規作成
GET	`/api/v1/expenses/{id}`	指定 ID の経費詳細取得
PATCH	`/api/v1/expenses/{id}/approve`	承認ステータス変更（承認・却下）
DELETE	`/api/v1/expenses/{id}`	申請の取り消し

リクエストパラメータ例（POST）

フィールド	型	必須	説明
`company_id`	integer	○	企業 ID（テナント）
`date`	string (ISO‑8601)	○	経費発生日
`amount`	integer	○	金額（円）
`description`	string	○	摘要
`receipt_file_key`	string	△	事前にアップロードした領収書ファイルのキー

Python サンプルコード（requests）

import os, json, requests
from typing import Dict

BASE_URL = &quot;https://api.freee.co.jp/api/v1&quot;
TOKEN    = os.getenv(&quot;FREEE_ACCESS_TOKEN&quot;)
HEADERS  = {
    &quot;Authorization&quot;: f&quot;Bearer {TOKEN}&quot;,
    &quot;Content-Type&quot;: &quot;application/json&quot;,
}

def _request(method: str, path: str, json_body: Dict | None = None):
    &quot;&quot;&quot;共通リクエストラッパー：ステータスコードと例外処理を統一&quot;&quot;&quot;
    url = f&quot;{BASE_URL}{path}&quot;
    resp = requests.request(method, url, headers=HEADERS, json=json_body, timeout=10)

    # 2xx 系はそのまま JSON を返す
    if resp.ok:
        return resp.json()

    # エラーハンドリング（500系含む）を一元化
    try:
        err = resp.json()
    except ValueError:
        err = {&quot;message&quot;: resp.text}

    raise RuntimeError(
        f&quot;[{resp.status_code}] {err.get('error', 'API Error')}: {err.get('message')}&quot;
    )

# ---- 具体的操作例 -------------------------------------------------
def create_expense():
    payload = {
        &quot;company_id&quot;: 123,
        &quot;date&quot;: &quot;2026-07-01&quot;,
        &quot;amount&quot;: 5000,
        &quot;description&quot;: &quot;交通費&quot;,
        &quot;receipt_file_key&quot;: &quot;abc123&quot;
    }
    return _request(&quot;POST&quot;, &quot;/expenses&quot;, payload)

def get_expense(expense_id: int):
    return _request(&quot;GET&quot;, f&quot;/expenses/{expense_id}&quot;)

def approve_expense(expense_id: int, approver_id: int = 45):
    payload = {&quot;status&quot;: &quot;approved&quot;, &quot;approver_id&quot;: approver_id}
    return _request(&quot;PATCH&quot;, f&quot;/expenses/{expense_id}/approve&quot;, payload)

def delete_expense(expense_id: int):
    return _request(&quot;DELETE&quot;, f&quot;/expenses/{expense_id}&quot;)

# 使用例（例外は呼び出し側で捕捉）
if __name__ == &quot;__main__&quot;:
    try:
        new = create_expense()
        print(&quot;Created:&quot;, json.dumps(new, ensure_ascii=False, indent=2))
        fetched = get_expense(new[&quot;id&quot;])
        print(&quot;Fetched:&quot;, fetched)
        approved = approve_expense(new[&quot;id&quot;])
        print(&quot;Approved:&quot;, approved)
    except RuntimeError as e:
        print(&quot;API error:&quot;, e)

import os, json, requests

from typing import Dict

BASE_URL = "https://api.freee.co.jp/api/v1"

TOKEN = os.getenv("FREEE_ACCESS_TOKEN")

HEADERS = {

"Authorization": f"Bearer {TOKEN}",

"Content-Type": "application/json",

}

def _request(method: str, path: str, json_body: Dict | None = None):

"""共通リクエストラッパー：ステータスコードと例外処理を統一"""

url = f"{BASE_URL}{path}"

resp = requests.request(method, url, headers=HEADERS, json=json_body, timeout=10)

# 2xx 系はそのまま JSON を返す

if resp.ok:

return resp.json()

# エラーハンドリング（500系含む）を一元化

try:

err = resp.json()

except ValueError:

err = {"message": resp.text}

raise RuntimeError(

f"[{resp.status_code}] {err.get('error', 'API Error')}: {err.get('message')}"

)

# ---- 具体的操作例 -------------------------------------------------

def create_expense():

payload = {

"company_id": 123,

"date": "2026-07-01",

"amount": 5000,

"description": "交通費",

"receipt_file_key": "abc123"

}

return _request("POST", "/expenses", payload)

def get_expense(expense_id: int):

return _request("GET", f"/expenses/{expense_id}")

def approve_expense(expense_id: int, approver_id: int = 45):

payload = {"status": "approved", "approver_id": approver_id}

return _request("PATCH", f"/expenses/{expense_id}/approve", payload)

def delete_expense(expense_id: int):

return _request("DELETE", f"/expenses/{expense_id}")

# 使用例（例外は呼び出し側で捕捉）

if __name__ == "__main__":

try:

new = create_expense()

print("Created:", json.dumps(new, ensure_ascii=False, indent=2))

fetched = get_expense(new["id"])

print("Fetched:", fetched)

approved = approve_expense(new["id"])

print("Approved:", approved)

except RuntimeError as e:

print("API error:", e)

主要ポイント

タイムアウト（10 秒）を設定し、ネットワーク障害時にハングしないようにしています。
共通ラッパー _request でステータスコード別の例外処理を一本化。500 系エラーでも JSON が返らなければプレーンテキストを取得します。

Node.js（axios）サンプル

const axios = require('axios');
require('dotenv').config();

const BASE_URL = 'https://api.freee.co.jp/api/v1';
const TOKEN    = process.env.FREEE_ACCESS_TOKEN;
const HEADERS  = { Authorization: `Bearer ${TOKEN}` };

/**
 * 共通リクエスト関数：成功時は data、失敗時は例外を投げる
 */
async function request(method, path, body = null) {
  try {
    const cfg = { method, url: `${BASE_URL}${path}`, headers: HEADERS };
    if (body) cfg.data = body;
    const res = await axios(cfg);
    return res.data;
  } catch (err) {
    // Axios は error.response が undefined のケース（ネットワーク障害）もある
    if (!err.response) throw new Error(`Network error: ${err.message}`);
    const { status, data } = err.response;
    throw new Error(`[${status}] ${data.error || 'API error'}: ${data.message || ''}`);
  }
}

// ---- 具体的操作 -------------------------------------------------
async function createExpense() {
  const payload = {
    company_id: 123,
    date: '2026-07-01',
    amount: 5000,
    description: '交通費',
    receipt_file_key: 'abc123'
  };
  return request('post', '/expenses', payload);
}

async function getExpense(id) {
  return request('get', `/expenses/${id}`);
}

async function approveExpense(id, approverId = 45) {
  const payload = { status: 'approved', approver_id: approverId };
  return request('patch', `/expenses/${id}/approve`, payload);
}

// 実行例
(async () =&gt; {
  try {
    const created = await createExpense();
    console.log('Created:', created);
    const detail = await getExpense(created.id);
    console.log('Detail:', detail);
    const approved = await approveExpense(created.id);
    console.log('Approved:', approved);
  } catch (e) {
    console.error(e.message);
  }
})();

const axios = require('axios');

require('dotenv').config();

const BASE_URL = 'https://api.freee.co.jp/api/v1';

const TOKEN = process.env.FREEE_ACCESS_TOKEN;

const HEADERS = { Authorization: `Bearer ${TOKEN}` };

/**

* 共通リクエスト関数：成功時は data、失敗時は例外を投げる

async function request(method, path, body = null) {

try {

const cfg = { method, url: `${BASE_URL}${path}`, headers: HEADERS };

if (body) cfg.data = body;

const res = await axios(cfg);

return res.data;

} catch (err) {

// Axios は error.response が undefined のケース（ネットワーク障害）もある

if (!err.response) throw new Error(`Network error: ${err.message}`);

const { status, data } = err.response;

throw new Error(`[${status}] ${data.error || 'API error'}: ${data.message || ''}`);

}

// ---- 具体的操作 -------------------------------------------------

async function createExpense() {

const payload = {

company_id: 123,

date: '2026-07-01',

amount: 5000,

description: '交通費',

receipt_file_key: 'abc123'

};

return request('post', '/expenses', payload);

}

async function getExpense(id) {

return request('get', `/expenses/${id}`);

}

async function approveExpense(id, approverId = 45) {

const payload = { status: 'approved', approver_id: approverId };

return request('patch', `/expenses/${id}/approve`, payload);

}

// 実行例

(async () => {

try {

const created = await createExpense();

console.log('Created:', created);

const detail = await getExpense(created.id);

console.log('Detail:', detail);

const approved = await approveExpense(created.id);

console.log('Approved:', approved);

} catch (e) {

console.error(e.message);

}

})();

エラーハンドリングのベストプラクティス

API 呼び出しは ステータスコード と レスポンスボディ の組み合わせでエラー原因を特定します。以下に代表的なケースと対策例をまとめました。

ステータス	主なシナリオ	推奨対策
`401 Unauthorized`	アクセストークンの有効期限切れ、またはスコープ不足	リフレッシュトークンがある場合は再取得。無い場合は認可フローを最初から実行し直す
`403 Forbidden`	IP ホワイトリスト外、もしくはシークレットキー不一致	API 呼び出し元の IP を管理画面で許可リストに追加、シークレットが正しいか再確認
`404 Not Found`	指定 ID が存在しない、またはエンドポイントミス	リクエストパラメータをロギングして検証。URL のタイポはないかチェック
`422 Unprocessable Entity`	バリデーションエラー（必須項目欠如・形式不正）	エラーメッセージに含まれるフィールド名で入力チェックを強化
`429 Too Many Requests`	レートリミット超過	指数バックオフ（例: 1 s → 2 s → 4 s …）で再試行、またはプランアップグレード
`500–504 Server Error`	freee 側の一時障害、ネットワークタイムアウト	リトライロジックを実装しつつ、障害発生時は監視ツール（Datadog, CloudWatch 等）へ通知
ネットワークエラー（接続失敗・DNS エラー等）	クラウド環境の一過性トラブル	タイムアウト設定とリトライを併用し、一定回数超えたらアラート送信

Python での包括的リトライ例（tenacity ライブラリ使用）

from tenacity import retry, stop_after_attempt, wait_exponential, retry_if_exception_type
import requests

class ApiError(RuntimeError):
    pass

@retry(
    reraise=True,
    stop=stop_after_attempt(5),
    wait=wait_exponential(multiplier=1, min=2, max=30),
    retry=retry_if_exception_type((requests.ConnectionError, requests.Timeout, ApiError))
)
def call_api(method: str, url: str, **kwargs):
    resp = requests.request(method, url, timeout=10, **kwargs)

    if resp.status_code &gt;= 500:
        raise ApiError(f&quot;Server error {resp.status_code}&quot;)
    elif not resp.ok:
        # 4xx 系は呼び出し側でハンドリングさせる
        raise RuntimeError(f&quot;[{resp.status_code}] {resp.text}&quot;)

    return resp.json()

from tenacity import retry, stop_after_attempt, wait_exponential, retry_if_exception_type

import requests

class ApiError(RuntimeError):

pass

@retry(

reraise=True,

stop=stop_after_attempt(5),

wait=wait_exponential(multiplier=1, min=2, max=30),

retry=retry_if_exception_type((requests.ConnectionError, requests.Timeout, ApiError))

)

def call_api(method: str, url: str, **kwargs):

resp = requests.request(method, url, timeout=10, **kwargs)

if resp.status_code >= 500:

raise ApiError(f"Server error {resp.status_code}")

elif not resp.ok:

# 4xx 系は呼び出し側でハンドリングさせる

raise RuntimeError(f"[{resp.status_code}] {resp.text}")

return resp.json()

このように リトライポリシー と 例外クラスの分離 を行うことで、コードが読みやすくなると同時に障害耐性が向上します。

Webhook によるリアルタイム同期

freee が提供する Webhook は、経費ステータスが変化した瞬間に外部システムへ通知できる仕組みです。2025 年に追加された expense.created と expense.approved のイベントは、承認フローの自動化で特に有用です。

Webhook 登録手順と署名検証

Webhook 設定画面へアクセス（Developers → Webhooks）。
「新規登録」ボタンをクリックし、以下情報を入力。
Endpoint URL：例 https://api.example.com/webhook/freee （必ず HTTPS）
Signing Secret：ランダムな 32 バイト以上の文字列。保存は安全に（環境変数推奨）。
受信サーバーで署名検証を実装し、正当性が確認できたら JSON ペイロードを処理する。

Python（Flask）での署名検証例

import os, hmac, hashlib, json
from flask import Flask, request, abort

app = Flask(__name__)
SIGNING_SECRET = os.getenv(&quot;FREEE_WEBHOOK_SECRET&quot;)

def verify_signature(payload: bytes, signature: str) -&gt; bool:
    expected = hmac.new(
        SIGNING_SECRET.encode(), payload, hashlib.sha256
    ).hexdigest()
    return hmac.compare_digest(expected, signature)

@app.route(&quot;/webhook/freee&quot;, methods=[&quot;POST&quot;])
def freee_webhook():
    sig = request.headers.get(&quot;X-Freee-Signature&quot;)
    if not sig or not verify_signature(request.data, sig):
        abort(400, &quot;Invalid signature&quot;)

    event = json.loads(request.data)
    # ここで event[&quot;type&quot;] に応じたロジックを呼び出す
    handle_event(event)
    return &quot;&quot;, 204

def handle_event(event: dict):
    etype = event.get(&quot;type&quot;)
    if etype == &quot;expense.created&quot;:
        process_created(event[&quot;data&quot;])
    elif etype == &quot;expense.approved&quot;:
        process_approved(event[&quot;data&quot;])

import os, hmac, hashlib, json

from flask import Flask, request, abort

app = Flask(__name__)

SIGNING_SECRET = os.getenv("FREEE_WEBHOOK_SECRET")

def verify_signature(payload: bytes, signature: str) -> bool:

expected = hmac.new(

SIGNING_SECRET.encode(), payload, hashlib.sha256

).hexdigest()

return hmac.compare_digest(expected, signature)

@app.route("/webhook/freee", methods=["POST"])

def freee_webhook():

sig = request.headers.get("X-Freee-Signature")

if not sig or not verify_signature(request.data, sig):

abort(400, "Invalid signature")

event = json.loads(request.data)

# ここで event["type"] に応じたロジックを呼び出す

handle_event(event)

return "", 204

def handle_event(event: dict):

etype = event.get("type")

if etype == "expense.created":

process_created(event["data"])

elif etype == "expense.approved":

process_approved(event["data"])

Node.js（Express）での署名検証例

const crypto = require('crypto');
const express = require('express');
require('dotenv').config();

const app = express();
app.use(express.raw({ type: 'application/json' })); // raw body が必要

const SECRET = process.env.FREEE_WEBHOOK_SECRET;

function verifySignature(rawBody, signature) {
  const expected = crypto.createHmac('sha256', SECRET).update(rawBody).digest('hex');
  return crypto.timingSafeEqual(Buffer.from(expected), Buffer.from(signature));
}

app.post('/webhook/freee', (req, res) =&gt; {
  const sig = req.header('X-Freee-Signature');
  if (!sig || !verifySignature(req.body, sig)) {
    return res.status(400).send('Invalid signature');
  }

  const event = JSON.parse(req.body);
  switch (event.type) {
    case 'expense.created':
      // 任意の処理
      break;
    case 'expense.approved':
      // 任意の処理
      break;
  }
  res.status(204).end();
});

const crypto = require('crypto');

const express = require('express');

require('dotenv').config();

const app = express();

app.use(express.raw({ type: 'application/json' })); // raw body が必要

const SECRET = process.env.FREEE_WEBHOOK_SECRET;

function verifySignature(rawBody, signature) {

const expected = crypto.createHmac('sha256', SECRET).update(rawBody).digest('hex');

return crypto.timingSafeEqual(Buffer.from(expected), Buffer.from(signature));

}

app.post('/webhook/freee', (req, res) => {

const sig = req.header('X-Freee-Signature');

if (!sig || !verifySignature(req.body, sig)) {

return res.status(400).send('Invalid signature');

}

const event = JSON.parse(req.body);

switch (event.type) {

case 'expense.created':

// 任意の処理

break;

case 'expense.approved':

// 任意の処理

break;

}

res.status(204).end();

});

実装例：`expense.created` → Google Drive に領収書保存

def process_created(data):
    file_key = data[&quot;receipt_file_key&quot;]
    # 1. freee のファイル取得 API (GET /files/{file_key})
    file_resp = call_api(&quot;GET&quot;, f&quot;/files/{file_key}&quot;)
    # 2. Google Drive SDK でアップロード（省略）
    upload_to_drive(file_resp[&quot;content&quot;], filename=f&quot;{data['id']}.pdf&quot;)

def process_created(data):

file_key = data["receipt_file_key"]

# 1. freee のファイル取得 API (GET /files/{file_key})

file_resp = call_api("GET", f"/files/{file_key}")

# 2. Google Drive SDK でアップロード（省略）

upload_to_drive(file_resp["content"], filename=f"{data['id']}.pdf")

ノーコード・ローコード連携例と実装サンプル

プログラミングに不慣れな担当者でも、Zapier や Make (Integromat) を活用すれば freee の経費データを他サービスへ自動同期 できます。ここでは代表的な 3 パターンと、設定時のポイントを解説します。

パターン 1：Zapier → Google Drive ＆ kintone

手順	内容
Trigger	`New Expense (freee)` – 新規経費が作成されたら発火
Action 1	`Upload File (Google Drive)` – `receipt_file_key` を使って領収書バイナリを取得し、`expenses/{year}/{month}` に保存
Action 2	`Create Record (kintone)` – 金額・日付・説明を kintone の経費管理アプリに登録

ポイント
- Zapier の「File」フィールドは Base64 エンコードされたバイナリ が必要です。Get File アクションで取得した content を直接渡すと OK。
- フィールドマッピングは「金額 → 金額（数値）」のように型を合わせておくとエラーが減ります。

パターン 2：Make (Integromat) → Slack ＆ Outlook

Webhook モジュールで freee の expense.approved を受信。
HTTP リクエストモジュールで /expenses/{id} を取得し、詳細情報を取得。
Slack メッセージ送信 – 承認完了通知を担当者チャンネルへ。
Outlook カレンダー作成 – 「経費承認」イベントを自動登録。

ポイント
- Make の「Retry on failure」を有効にすると、API が 429 や 500 系で失敗した場合に自動リトライが走ります。
- 各モジュールの エラーハンドリングブランチ を作成し、失敗時は別途メールで管理者へ通知させると運用が楽です。

パターン 3：Power Automate（Microsoft） → Teams ＆ SharePoint

手順	内容
Trigger	`When an HTTP request is received` – freee の Webhook URL を設定
Condition	イベントタイプが `expense.created` か判定
Action (Teams)	`Post a message` – 「新規経費申請が届きました」メッセージを送信
Action (SharePoint)	`Create file` – 領収書 PDF を SharePoint ライブラリに保存

ポイント
- Power Automate の「HTTP with Azure AD」コネクタは、Bearer トークン取得ロジックが組み込み済みなので、別途スクリプトを書く必要がありません。

テスト環境（Sandbox）での検証から本番移行、セキュリティと ROI の測定

実装後は必ず sandbox 環境 で動作確認し、本番切替時のリスクを最小化します。本章では手順・チェックリスト・セキュリティベストプラクティス、そして導入効果の定量的評価方法を示します。

Sandbox でのエンドポイント検証フロー

サンドボックス用アカウント作成（開発者ポータルの「Sandbox」タブ）。
リダイレクト URI にテスト用ドメイン（例：https://sandbox-api.example.com/oauth/callback）を登録。
PKCE フローでアクセストークン取得し、以下シナリオを順に実行:
POST /expenses で 架空の申請（金額 10,000 円）
GET /expenses/{id} で作成結果確認
PATCH /expenses/{id}/approve で承認シミュレーション
DELETE /expenses/{id} で削除
エラーレスポンス（422, 429, 500）を意図的に発生させ、ハンドリングロジックが期待通り動くか確認。

本番移行チェックリスト

項目	確認ポイント
クライアント情報	本番用 Client ID/Secret が環境変数に正しく設定されているか
リダイレクト URI	本番 URL が Developer Console に登録済みで、HTTPS が有効か
スコープ	必要最小限の権限だけが付与されているか（過剰権限はセキュリティリスク）
Webhook エンドポイント	公開 HTTPS、TLS 1.2 以上、署名検証ロジックが本番環境でも動作するか
テストカバレッジ	作成・取得・承認・削除の全シナリオを自動テストで網羅しているか
ログ & モニタリング	API 失敗時に CloudWatch/Datadog にアラートが届く設定になっているか
IP ホワイトリスト（利用可能なら）	社内固定 IP のみ許可し、外部からの不正アクセスを防止できているか

トークン管理・IP 制限などのベストプラクティス

アクセストークンは暗号化保存：AWS KMS で暗号化した上で Secrets Manager に格納。
リフレッシュトークンは短命に：取得後 30 日以内に再認可させ、長期保存は避ける。
IP ホワイトリスト：freee の管理画面から API 呼び出し元 IP を限定できる場合は必ず設定。
PCI DSS 配慮：領収書画像にカード情報が含まれる可能性があるなら、保存先（Google Drive, SharePoint 等）で暗号化・アクセス権最小化を徹底。

ROI（投資対効果）の測定例

指標	現行プロセス（手作業）	API 連携後	改善率
平均処理時間	12 分/件	3 分/件	75 % 短縮
ヒューマンエラー件数	8 件/月	1 件/月	87.5 % 減少
月間作業工数	40 人時	10 人時	75 % 削減

シミュレーション（中小企業・従業員 20 名の場合）

年間削減工数：30 時間 × 12 = 360 人時
平均給与：¥3,000/時間 → 年間コスト削減 ¥1,080,000
初期導入費用（開発・ツールライセンス）：¥500,000
回収期間＝初期投資 ÷ 年間節約額 ≈ 0.5 年

このように、API とノーコードツールの組み合わせだけで半年以内に投資を回収できるケースが多く見込めます。

まとめと次のステップ

開発者ポータルでアプリ登録し、PKCE 推奨フローでアクセストークン取得。
Expense Claims API を使って経費作成・承認・削除を自動化。エラーハンドリングは 4xx と 5xx 両方に対応することが重要です。
Webhook によりリアルタイム通知を取得し、Google Drive や Slack などの外部サービスと連携。署名検証は必須です。
サンドボックスでテスト → 本番環境へ安全に移行。IP 制限・トークン暗号化などのセキュリティ対策を忘れずに実装。
ノーコードツール（Zapier、Make、Power Automate）で非エンジニアでも拡張可能なフローを構築し、ROI を定量的に評価。

最後に：freee の API は頻繁にバージョンアップが行われます。実装前後は必ず公式リファレンス（https://developer.freee.co.jp/）と「変更通知」メールをチェックし、仕様変更に備えてコードのモジュール化・テスト自動化を推奨します。

参考リンク

freee Developers – OAuth 2.1 ドキュメント: https://developer.freee.co.jp/docs/oauth
API リファレンス（Expense Claims）: https://developer.freee.co.jp/api-docs/expenses
Webhook 署名検証ガイド: https://developer.freee.co.jp/docs/webhooks
PKCE 公式仕様（RFC 7636）: https://www.rfc-editor.org/rfc/rfc7636.html

以上が、freee Developers Community を活用した経費精算自動化の包括的ガイドです。ぜひ本手順を参考に、業務効率化とコスト削減を実現してください。

スポンサードリンク

バックオフィス職での転職を考えている人

スポンサードリンク

その頑張り、評価されていますか？

バックオフィスの努力が"経営の要"として評価される会社、あります

▷「業務改善を頑張るほど、なぜか報われない気がする」あなたへ

Backup Careerで無料キャリア相談を予約する

今すぐ辞める必要はありません。まず"適性診断だけ"受けて自分の市場価値を測る場所として使えます。今日の10分が、来年の働き方を変えます。

-freee

comment コメントをキャンセル

: freee

Freee API連携ガイド: 業務自動化の手順とメリット

Freee APIを活用した業務自動化の実現方法を解説。取引データや請求書処理の自動化、OAuth2認証フロー、ノーコードツール利用例などを詳しく紹介。

: freee

freee 経費精算機能とプラン概要・設定手順ガイド

freee の経費精算はスマホ撮影でOCR自動仕訳、柔軟な承認フローとレポート機能を備え、無料体験からStandard・Premiumまで利用できる設定方法も紹介します。

: freee

freee振込の無料キャンペーンと実務対応ガイド

freee振込のキャンペーン適用条件、導入手順、承認フロー、仕訳例、手数料発生時の対応と確認ポイントを実務視点で整理。公式確認を推奨。

: freee

2026年版 freee人事労務の料金・機能比較と導入ポイント

freee人事労務は2024・2025年改正に即対応し、API連携や24時間チャットサポートで中小企業の実務を支援します。

: freee

freee人事労務のログイン・初期設定と勤怠プラン比較

本記事では、freee人事労務のログイン方法、初期設定項目、StandardとPlusプランの違い、従業員登録・勤怠入力手順、そして自動給与連携とエラー対処法を詳しく紹介します。

エアトリ初心者ガイド：基本操作と利用フロー完全解説

企業向けKeycloak MFA導入ガイド | セキュリティ強化

freee Developers Communityで経費API活用ガイド：OAuth2.1・Webhook・ノーコード

freee Developers Community の概要と利用開始手順

アプリ登録方法

必要情報の入力例と注意点

OAuth 2.1（PKCE 推奨）認可フロー

フロー概要（図）

Code Verifier / Challenge の生成（Python）

認可リクエスト URL（例）

アクセストークン取得（cURL）

Expense Claims API のエンドポイントと主要パラメータ

エンドポイント一覧

リクエストパラメータ例（POST）

Python サンプルコード（requests）

主要ポイント

Node.js（axios）サンプル

エラーハンドリングのベストプラクティス

Python での包括的リトライ例（tenacity ライブラリ使用）

Webhook によるリアルタイム同期

Webhook 登録手順と署名検証

Python（Flask）での署名検証例

Node.js（Express）での署名検証例

実装例：expense.created → Google Drive に領収書保存

ノーコード・ローコード連携例と実装サンプル

パターン 1：Zapier → Google Drive ＆ kintone

パターン 2：Make (Integromat) → Slack ＆ Outlook

パターン 3：Power Automate（Microsoft） → Teams ＆ SharePoint

テスト環境（Sandbox）での検証から本番移行、セキュリティと ROI の測定

Sandbox でのエンドポイント検証フロー

本番移行チェックリスト

トークン管理・IP 制限などのベストプラクティス

ROI（投資対効果）の測定例

シミュレーション（中小企業・従業員 20 名の場合）

まとめと次のステップ

OAuth 2.1（PKCE 推奨）認可フロー

実装例：`expense.created` → Google Drive に領収書保存