Portfolioこのトピックについて
月末の集計作業など、数百件のデータを扱う場面でも快適に動作する仕組みを実装しました。請求書サービスのAPI制限を意識しながら、効率的にデータを処理する設計です。
API制限との付き合い方
多くのクラウドサービスには、API呼び出しの制限があります。請求書サービスも例外ではなく、「1回の取得で100件まで」という制限があります。
| 制限 | 内容 | 影響 |
|---|---|---|
| 件数制限 | 1回のリクエストで100件まで | 大量データは複数回に分けて取得が必要 |
| レート制限 | 1分間に一定回数まで | 連続アクセスでエラーになる可能性 |
| タイムアウト | 1リクエストに30秒程度 | 重い処理は途中で切断される |
自動ページング
「500件ください」とGASから指示するだけで、アプリ側で自動的に5回のやり取りを処理します。
「500件取得してください」
offset=0, limit=100 → 100件取得
レート制限対策
同様に100件ずつ取得（各間に2秒待機）
合計500件をGASに返却
なぜ2秒待機するのか
API呼び出しの間に適度な待ち時間を挟むことで、サービス側に負荷をかけすぎない設計にしています。「アクセスが多すぎます」というエラーを未然に防ぎます。
待ち時間は設定で調整可能です。サービスの負荷状況に応じて、1秒〜5秒の間で設定できます。
必要な分だけ取得（2段階取得）
大量の伝票があっても、最初は「一覧だけ」を高速に取得し、詳細が必要なものだけ追加取得する方式を採用しています。
skip_details: true で明細をスキップ。ID・番号・取引先・日付のみ取得
取引先名や日付で絞り込み。1000件→50件に削減
絞り込んだ50件のみ明細を取得
効果の比較
| 方式 | 1000件の場合 | 所要時間の目安 |
|---|---|---|
| 一括取得 | 全件の明細を取得 | 2〜3分以上 |
| 2段階取得 | 絞り込み後50件だけ詳細取得 | 30秒程度 |
同時実行制御
複数のAPI呼び出しを効率的に行うため、同時実行数を制御する仕組みを導入しました。
10件の詳細取得リクエストをキューに追加
最大2件を並列で処理
1件完了するたびに次のタスクを開始
10件すべての結果をまとめて返却
なぜ2件同時なのか
並列数を増やしすぎると、サービス側のレート制限に引っかかるリスクが高まります。2件同時は、速度と安定性のバランスが取れた設定です。
| 並列数 | 速度 | 安定性 | 評価 |
|---|---|---|---|
| 1件 | 遅い | 非常に高い | 安全だが効率が悪い |
| 2件 | 適度に速い | 高い | バランスが良い |
| 5件以上 | 速い | 低い | レート制限のリスク大 |
最大件数の制限
ユーザーが「10000件取得」と指定しても、アプリ側で最大500件に制限しています。
極端に大きなリクエストは、タイムアウトやメモリ不足の原因になります。適切な上限を設けることで、システムの安定性を確保しています。
大量データが必要な場合
500件を超えるデータが必要な場合は、期間を分割して取得することをお勧めします。
| アプローチ | 例 | メリット |
|---|---|---|
| 期間分割 | 1ヶ月ごとに取得 | 安定して取得可能 |
| 取引先分割 | 取引先ごとに取得 | 分析しやすいデータに |
| 種類分割 | 請求書と納品書を分けて取得 | 処理が軽くなる |
ページング終了の判定
データ取得を繰り返すとき、「もう取得するデータがない」ことを正しく判定する必要があります。
100件リクエスト
取得件数をチェック
この設計で実現できること
運営側にとって
- 安定した大量処理: API制限を意識した設計
- 効率的なリソース利用: 必要な分だけ取得
- タイムアウトの回避: 適切な件数制限
現場担当者にとって
- ストレスのない操作: 大量データでも待ち時間が短い
- 一度の操作で完結: ページングを意識する必要なし
- 確実な結果取得: 途中で止まることがない