API Gatewayでコストカットと実装の敷居を下げた話

「API実装は一手間」という思い込みを、API Gatewayが打開した話

執筆日: 2026-07-15
ステータス: 下書き（構成案）

---

📌 はじめに

勤怠管理システムのAWS移行プロジェクトで、「別チームが管理するDBに直接クエリを投げて同期する」という、旧システム時代からの連携方式をどう置き換えるかという課題に直面しました。

正直に言うと、最初は「DB直接接続をAPI経由に置き換える」という選択肢自体、あまり本気で検討していませんでした。理由は単純で、「APIを1本作るのは一手間かかる」という思い込みがあったからです。認証をどう実装するか、HTTPSをどう終端するか、スロットリングやログはどう用意するか——考えるだけで腰が重くなる作業に思えていました。

しかし実際にAPI Gatewayを使って手を動かしてみると、その「一手間」の大部分がマネージドサービス側で最初から用意されていることに気づき、想定より遥かに軽い実装で済みました。この記事では、その気づきと、コストカットの視点から見たAPI Gatewayの価値について、実績データを交えて共有します。

---

🎯 きっかけ：DB直接接続をどう見直すか

移行対象の勤怠管理システムには、旧システム時代から「別チームが管理するマスタDB（校舎・スタッフ等の基幹データ）」に、Jenkins + ETLツールで直接クエリを投げて同期する仕組みがありました。

AWS移行にあたり、この仕組み自体を見直すべきかを検討しました。選択肢は主に2つです。

• VPCピアリングでDB直接接続を継続: 開発リソースが逼迫しており、ネットワーク設計・承認のリードタイムが長い。クロスアカウントピアリングの前例もなく、追加コストが読めない
• 相手アカウント内にAPIレイヤーを構築: 「APIを1本作る」一手間はあるが、ネットワークレベルの調整は不要になる

この時点では「API化の方が筋は良さそうだが、実装コストが心配」という感覚でした。

---

💭 「API実装は一手間」の正体

改めて言語化すると、身構えていたのは以下のような作業でした。

• HTTPSエンドポイントの用意（証明書取得・更新の運用）
• 認証機構の自作（APIキー発行・検証ロジック）
• リクエスト数の制御（スロットリング・レート制限）
• アクセスログの整備
• サーバー（EC2等）のプロビジョニングとOSパッチ運用

従来、簡易的なAPIを1本立てるだけでも、Nginx＋アプリケーションサーバーを構築し、これらを一つひとつ自前で用意する必要がある、という感覚が染みついていました。

---

🔨 構築フェーズ：API Gatewayで実際にやったこと

そもそもの着手についても、大掛かりではありません。AWSマネジメントコンソールから「API Gateway」を選択し、ウィザードに沿ってREST APIを新規作成するだけで、エンドポイントの骨格は数分で用意できます。今回はAWS CLIにて構築しましたが、コンソールから進めても数クリックでAPIキー・使用量プランまで設定が完結する手軽さがあります。

実際に手を動かしてみると、上記のほとんどがAPI Gatewayの標準機能として最初から用意されていることに気づきました。

従来の思い込み（自作が必要）	API Gatewayでは
HTTPS証明書の取得・更新	REGIONALエンドポイントで自動的にHTTPS化、証明書管理不要
認証機構の自作	APIキー + 使用量プランを数行の設定で有効化
スロットリング・レート制限	使用量プランに組み込み済み、コード不要
アクセスログの整備	CloudWatch Logsに標準連携
サーバー運用（OSパッチ等）	Lambdaに処理を書くだけ、サーバー管理そのものが不要

構成要素は非常にシンプルです。

要素	内容
IAMロール	Lambda実行ロール（VPCアクセス + Secrets Manager読み取りのみ）
セキュリティグループ	必要最小限のegressのみ
Lambda	Python 3.12、DBへの接続処理のみを実装
API Gateway	REGIONALエンドポイント、APIキー + 使用量プランで認証

自分で実装したのは実質「Lambdaの中でDBに接続してデータを返す」というビジネスロジックの数十行だけで、それ以外の「一手間」だと思っていた部分はほぼ設定作業に還元されました。

なお、別アカウントのリソースを自チームのTerraform stateで持つことには違和感があったため、今回は構築自体はAWS CLI（一部コンソール）による手動構築としています。相手アカウントのリソースは相手アカウントの流儀で管理してもらう、という判断です。

---

💻 API実装フェーズ：呼び出し側のコードはどう変わったか

一番わかりやすい変化は、データを取得する側の実装です。

Before: DB直接接続時代

旧システムでは、JenkinsからキックされるETLツールが接続情報一式を保持し、直接SQLを発行してデータを取得していました。イメージとしては次のような形です。

mysql -h <DB_HOST> -u <DB_USER> -p<DB_PASSWORD> <DB_NAME> \
  -e "SELECT id, name, code, mail_address FROM schoolhouses"

呼び出し側は、DBホスト・認証情報・スキーマ構造をすべて把握しておく必要があり、DB側のテーブル定義が変われば呼び出し側の実装も追従が必要でした。

After: API Gateway経由

curl -H "x-api-key: <API_KEY>" \
  "https://<API_ENDPOINT>/schoolhouses"

呼び出し側が知っておく必要があるのは「エンドポイントURL」と「APIキー」だけになりました。DBのホスト名・認証情報・テーブル構造はAPI提供側の内部に隠蔽され、呼び出し側はJSONレスポンスを受け取るだけです。

アプリケーション（Laravel）側の実装も、この変化に合わせてシンプルになりました。

$response = Http::withHeaders(['x-api-key' => $apiKey])
    ->timeout(30)
    ->get("{$baseUrl}/schoolhouses");

$rows = $response->json();

DBドライバへの直接依存がなくなり、汎用的なHTTPクライアントで完結する形になっています。
認証・接続情報・スキーマ知識をAPI提供側に閉じ込められる点は、疎結合という意味で大きな設計上の差になります。

---

📊 実績ベースで見るコストカット

「一手間だと思っていたら実は数十行で済んだ」という体験は、複数の軸でのコストカットとして整理できます。特に金銭・処理効率の面では、今回のマスタデータ同期の実績値がわかりやすい例になりました。

処理効率：エンドポイント設計による集約

今回のAPIでは、校舎・スタッフ・所属校舎・ユーザーの4種類のマスタデータを、テーブル単位で一括取得する4本のGETエンドポイントとして設計しました。実績として、1回の同期バッチで取得している件数は以下の通りです。

データ種別	件数
校舎情報	273件
スタッフ情報	2,179件
所属校舎（校舎×スタッフ）	804件
ユーザー情報	2,179件
合計	5,435件

もし1レコードずつ個別にAPIリクエストする設計にしていたら、日次バッチだけで5,435回のリクエストが発生する計算になります。テーブル単位でまとめて取得する4本のエンドポイントに集約したことで、日次のAPI呼び出しはわずか4回で完結しています。

実装コスト

サーバー構築・HTTPS終端・認証・ロギングという「毎回同じことをゼロから作る」作業がなくなり、書くべきコードが必要ロジックだけに縮小しました。

リードタイム

VPCピアリング案では相手チームのバックログ待ちで長期化する見込みでしたが、API化では相手チーム側の作業が「Lambda + API Gatewayを立てる」という小さいタスクに収まり、着手から稼働まで実質1日で完了しました。

運用コスト

サーバーレス構成のため、OSパッチ・ミドルウェアの脆弱性対応・スケーリング設計といった運用作業自体が発生しません。

金銭コスト：「もし個別クエリ方式だったら」の試算

もし日次で約5,435件のレコードを1件ずつ個別にAPIリクエストし、その都度Lambda関数を起動してDBへ反映する設計にしていたら、という前提で試算してみます。

	個別クエリ方式（仮定）	実際の実装（4本のバッチAPI）
年間リクエスト数	約198万回（5,435件 × 365日）	約1,460回（4回 × 365日）

リクエスト数にして約1,360分の1まで圧縮されています。

参考までに金額換算すると（Lambda: $0.20/100万リクエスト、API Gateway REST API: $3.50/100万リクエストで試算）、今回の規模ではAPI Gateway側で年間1,000円程度の差に留まり、Lambdaは双方とも無料利用枠に収まります。絶対額としてのインパクトは小さいものの、これは今回のデータ量がまだ小さいためです。
マスタデータが今後10倍・100倍と増えていった場合、この1,360分の1という圧縮率がそのままコスト・レイテンシの差として効いてきます。
常時起動するサーバーやネットワーク機器が不要な点も、規模が大きくなるほど効いてくる要素です。

時間短縮：実測ベースで見る処理時間

CloudWatch Logsで実際のLambda実行時間（Duration）を確認したところ、1回のAPIコールあたり数十ms〜600ms程度でした（データ量やコールドスタートの有無によって変動、直近30回のサンプル平均は約213ms）。4本のエンドポイントを合計しても、1回の同期バッチは概ね1秒前後で完了しています。

もし個別クエリ方式で5,435回のリクエストを投げていたら、単純計算でも「1回あたり数十〜数百msのオーバーヘッド × 5,435回」分の時間がかかる計算になり、バッチ全体の完了までに数分〜十数分規模の時間を要していた可能性があります。テーブル単位で一括取得する設計にしたことで、同期処理は体感できないレベルの短時間で完結しています。

---

📝 まとめ：大量のクエリを投げている現状を見直すきっかけになればと思っています。

「APIを1本立てるのは一手間」という感覚は、恐らく多くのインフラ・バックエンドエンジニアに共通するハードルだと思います。しかし、その「一手間」の中身を分解してみると、認証・HTTPS・スロットリング・ロギングといった定型的な部分は、API Gatewayのようなマネージドサービスがとうに肩代わりしてくれます。

さらに、テーブル単位でまとめて取得するようなシンプルなエンドポイント設計にすることで、日次5,000件を超えるデータでも4回のリクエストで完結させられますので、「一手間」どころか、個別にクエリを投げ続けるよりも効率的な選択肢になり得ます。

もし社内に「DBへの直接接続」「サーバー間の裏口連携」のような、見直しが億劫で放置されている連携が残っているなら、一度「実装コストを理由に避けている選択肢」を疑ってみる価値があるかもしれません。実際に手を動かしてみると、思っていたより遥かに手軽に実現できることがあります。

---

🚀 今後の展開

• 同様のクロスアカウント連携が今後発生した際、まず「API Gatewayでの薄いレイヤー構築」を選択肢の筆頭として検討する
• 今回構築したAPIの利用実績を踏まえ、他の直接DB接続が残っている箇所への横展開を検討する

---