クラウド会計公式API・OAuth認証の試行錯誤ログ

APIキーを手に入れてターミナルで叩いた瞬間、services: ["conac"]の文字列が返ってきて手が止まった。連結会計のスコープしかない。ここから半日かけて、MCPのトークン流用、自前OAuthアプリ登録と、認証手段を3回乗り換えることになった記録。

第1段階: APIキーで挑む（失敗）

会計サービスのAPIキー（key_KF547uA6）を取得し、キー交換でJWTトークンを取得した。トークン自体は問題なく返ってくる。

{
  "services": ["conac"]
}

連結会計（conac）のスコープしか付与されていない。会計APIには一切アクセスできない。クラウド会計サービスの確定申告機能には公開APIが存在しないことがここで判明した。

APIキーでできることはここまで。別のルートを探す必要がある。

第2段階: 公式MCPを発見（突破口）

調べていく中で、会計サービス公式のMCPサーバー（mfc_ca）を発見した。リモートMCPサーバーとして接続設定を行い、OAuth認証フローを通して接続に成功。

ここで一つ気づいた。MCPのOAuthトークンを使って、直接REST APIを叩ける。

# MCPが内部で使っているAPIと同じエンドポイント
curl -H "Authorization: Bearer ${ACCESS_TOKEN}" \
  https://api-accounting.example.com/api/v3/journals

MCPは薄いラッパーに過ぎず、トークンは共通。仕訳の取得・登録・削除、全て直接APIで動いた。

MCPトークンの限界

アクセストークンの有効期限は1時間。MCPのトークンストアにはrefresh_tokenが含まれていない。1時間ごとに再認証が必要で、自動化には使えない。

第3段階: 自前OAuthアプリ登録（最終解）

会計サービスのアプリポータルで自前のOAuthアプリケーションを登録した。

1. アプリポータルでアプリ作成
2. redirect_uriを追加（ローカルのコールバックURL）
3. oauth_flow.pyで認可コード取得→トークン交換

# oauth_flow.py のトークン交換部分
# 認可コードをrefresh_tokenに交換
response = requests.post(token_url, data={
    "grant_type": "authorization_code",
    "code": auth_code,
    "redirect_uri": redirect_uri,
    "client_id": client_id,
    "client_secret": client_secret,
})
# refresh_token: 有効期限540日

refresh_tokenの有効期限は540日。これで自動化の土台が整った。自前OAuthアプリ経由で仕訳登録・削除にも成功。

ハマりポイント: Windowsコマンドライン長制限

JSONの仕訳データ94件をGoogle スプレッドシートに書き込む処理で、Windowsのコマンドライン長制限（約8,191文字）に引っかかった。94件分のJSONを1コマンドで渡そうとして、コマンドが途中で切れる。

バッチ分割（10〜20件ずつ）で解決。Windows環境でJSON大量データを扱うときの定番の罠だった。

結論: Chrome拡張とAPIの使い分け

半日触って見えてきた速度感の比較。

エクスポートはChrome拡張を維持、インポート・削除・更新はAPIに移行が最適解という結論に落ち着いた。

認証手段の変遷まとめ

APIキー(conacのみ) → MCP経由OAuth(1時間制限) → 自前OAuthアプリ(540日)

最初からOAuthアプリを登録していれば30分で終わった話だが、MCPの内部構造を覗けたのは収穫だった。「MCPは薄いラッパー」という理解は、今後別のMCPサーバーを評価するときにも効いてくる。

学んだこと

• クラウド会計サービスの確定申告機能には公開APIがない。APIキーで取れるスコープは連結会計のみ
• MCP経由のOAuthトークンとREST API直叩きのトークンは同一。MCPを介さず直接APIを叩ける
• 自前OAuthアプリのrefresh_tokenは540日有効。自動化にはこのルートが必須
• WindowsでJSON大量データをCLIに渡すときは、コマンドライン長制限を常に頭に入れておく