REST APIの認証方式の違いでつまずいた話と対処法をまとめる

REST APIとは何か、最小限の前提知識

REST APIとは、GET(取得)・POST(送信)・PATCH(更新)といった命令を使って、別々のシステム同士がインターネット経由でデータをやり取りするための取り決めです。

難しく聞こえますが、仕組みとしては「決まった住所(エンドポイント)に、決まった形式(ヘッダーとデータ)でリクエストを送ると、決まった形式(JSONなど)で返事が返ってくる」というだけのものです。概念や仕様の詳しい解説はGoogle Cloudの解説やプライムナンバーの解説記事、ASTERIA Warpの解説に譲り、この記事では実際に複数サービスを繋いだときにどこで詰まるかに絞って書きます。概念を読んだだけでは分からない部分が、実際に手を動かすと必ず出てくるからです。

gpirot.comで実際に使っている4種類のREST API

私が運用しているサイトでは、Supabase・WordPress・生成AI(Claude/OpenAI)・LINEという4種類のREST APIを組み合わせて自動化を回しています。それぞれ役割も認証方式も違うので、具体例で見ていきます。

Supabaseのtasksテーブルには、定時タスクの実行結果がログとして溜まっていきます。

Supabaseへのリクエストは、実際にはこのような形になります。

curl -X GET "https://xxxxx.supabase.co/rest/v1/tasks?select=*&status=eq.done" \
  -H "apikey: {SUPABASE_ANON_KEY}" \
  -H "Authorization: Bearer {SUPABASE_ANON_KEY}" \
  -H "Prefer: count=exact"

WordPressへの記事投稿は、アプリケーションパスワードをBasic認証の形で使います。

curl -X POST "https://example.com/wp-json/wp/v2/posts" \
  -u "wp_user:xxxxxxxxxxxxxxxxxxxx" \
  -H "Content-Type: application/json" \
  -d '{"title":"記事タイトル","content":"本文","status":"draft"}'

LINEへの通知は、チャネルアクセストークンをBearerとして渡す形式です。

curl -X POST "https://api.line.me/v2/bot/message/push" \
  -H "Authorization: Bearer {CHANNEL_ACCESS_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{"to":"{USER_ID}","messages":[{"type":"text","text":"承認待ちの案件があります"}]}'

この4種類を組み合わせて、案件の収集から応募文や記事の下書きまでの定時処理を回しています。

つまずきやすい場所と対処：認証方式の違い

複数のAPIを繋ぐときに最初に詰まるのは、サービスごとに認証方式がまったく違うという点です。知識として知っていても、実際にヘッダーを組み立てる段階で必ず一度は間違えます。

実際に私が詰まったのは、Supabaseでapikeyだけをセットしてauthorizationヘッダーを付け忘れたケースです。返ってくるのは401 Unauthorizedというメッセージだけで、どこが間違っているかは教えてくれません。この状態になったときの確認手順は次のとおりです。

1. エラーコードが401か403かをまず確認する。401は認証情報そのものが足りない、403は認証は通っているが権限がない、という違いがあります。
2. リクエストに付けているヘッダーを1行ずつ書き出し、サービスのドキュメントに書かれている必須ヘッダーと見比べる。
3. apikeyとAuthorization: Bearerの値が同じ文字列を指しているか、コピー時に改行や空白が混ざっていないかを確認する。
4. WordPressの場合は、通常のログインパスワードではなく、管理画面で発行したアプリケーションパスワードを使っているかを確認する。
5. ここまでで直らなければ、該当サービスのAPIキーを一度無効化して再発行し、新しい値で試す。

認証方式の違いは一覧で覚えるよりも、一度401エラーに当たって上記の手順を踏んだほうが身につきます。

つまずきやすい場所と対処：エラーハンドリングと運用の仕組み

外部APIは通信エラーや一時的な障害が起きる前提で設計したほうが、結果的に運用の手間が減ります。gpirot.comでは、入力→処理→出力→確認という4つの段階を分けて、Cloudflare Pages Functions上で処理を切り分けています。段階を分けておくと、どこで処理が止まったかをあとから特定しやすくなります。

定時で動くタスクは現在複数本あり、ローカルPC+Windowsタスクスケジューラ+PythonでSupabase・LINE・Cloudflare Workerと連携させて動かしています。クラウドの定時実行サービスを使わずにローカルPCで回している理由は、まず小さく試して動作を確認してから、必要なものだけクラウド側に移す、という順番で進めているためです。

エラーが起きたときの記録先はSupabaseのtasksテーブルです。処理が失敗した場合は、失敗した時刻・エラーメッセージ・どの段階で止まったかをこのテーブルに書き込むようにしています。

複数のサービスを組み合わせていても、呼び出し回数と1回あたりのデータ量を絞れば、個人の副業レベルの運用コストに収まります。これから始める方が不安に感じやすい「API連携は費用がかさむのでは」という点は、呼び出し回数と1回の長さを絞っておけば、個人の副業の範囲で続けられる額に収まります。始める順番は次のとおりです。

1. まず1つのタスクだけをローカルPCで手動実行し、正常に終わるかを確認する。
2. 正常に終わったら、同じタスクをWindowsタスクスケジューラに登録して、決まった時間に自動で動くか確認する。
3. 失敗したときにエラー内容が分かるよう、ログを1行でもいいのでファイルかデータベースに残す処理を先に入れる。
4. 本番で動かす前に、API側の利用制限(レート制限)の値をドキュメントで確認し、呼び出し頻度がそれを超えないようにする。

今すぐ自分で試せる：公開中のAPI連携ツール

説明を読むだけでは実感が湧きにくいと思うので、実際に公開しているAPI連携のツールを2つ紹介します。どちらも無料で試せます。

• AI転記ツール:PDFや写真をアップロードすると、OCRと生成AIのAPIを組み合わせてCSVやTSVの表に変換します。紙の帳票をデータ化したいときの最初の一歩として使えます。
• 問い合わせ自動返答(管理画面つき):登録した拠点・営業時間・よくある質問を生成AIのAPIに渡し、その範囲だけで答えます。判断が要る質問は担当者へ引き継ぎ、登録内容は管理画面から書き換えられます。

どちらも、この記事で触れたSupabase・生成AI・通知系のAPIを組み合わせて動いています。読者の方が次にやることとしては、まず自分の業務の中で「入力(PDFや問い合わせ文)」と「出力(表や返信文)」がはっきりしている作業を1つ選び、上記のどちらかのツールで試してみることをすすめます。自分の業務にAPI連携が使える手応えが掴みやすいはずです。

1. 自分の業務の中で、人が転記しているだけの作業、または毎回似た文面を返している作業を1つ書き出す。
2. その作業の入力元(紙・PDF・メール文面)と、出力先(表・返信文)をそれぞれ確認する。
3. 該当するツールに実際のデータ(個人情報を含まないもの)を1件だけ入れて、結果の精度を確認する。
4. 結果が実用レベルであれば、残りの作業も同じ流れで処理できないか検討する。

まとめ：複数サービスを繋いだ先にある自動化の規模感

ここまでの構成は、最初から狙って作ったものではなく、1つずつAPIを繋いで、詰まったら直すというやり取りを複数の定時タスクまで積み重ねた結果です。読者の方がまず取り組むべきことは、自分の業務の中でAPI連携が役に立ちそうな箇所を1つ特定し、上で紹介したツールのどちらかに実際のデータを入れてみることです。