外部サービス連携では、APIを一度呼べたことより、認証期限、利用上限、失敗時の再試行、提供元の変更へ耐えられることが重要です。
Discord、LINE、地図、Box、Zoomなどで製品は違っても、利用者の同意、秘密情報、通信失敗、非同期通知という設計課題は共通します。
最初に一つの操作を最後まで通し、成功だけでなく期限切れと上限超過を再現してください。
アプリ開発の目的に合う相談先は、外注と学習を目的別に分けた相談ガイドにまとめています。
| 連携方式 | 向く処理 | 主な注意点 |
|---|---|---|
| 同期API | 検索、登録、更新 | 待ち時間、タイムアウト、再試行 |
| ポーリング | 状態を定期確認 | 呼び出し回数、重複、遅延 |
| Webhook | 外部の更新通知 | 署名検証、重複配信、順序 |
| ブラウザー認証 | 利用者の同意とログイン | 戻り先、状態値、期限切れ |
| SDK | 地図や通話などの組込み | 版、権限、利用規約 |
連携方式ごとに失敗の形を比較する
同期APIは結果をすぐ使える一方、外部サービスが遅いとアプリの待ち時間へ直結します。
Webhookは待ち時間を減らせますが、同じ通知が複数回来ることや順番が前後することを前提にします。
| 方式 | 成功の確認 | 失敗時に残す情報 | 重複対策 |
|---|---|---|---|
| 同期API | HTTP結果と業務ID | 状態、応答、相関ID | 同じ要求を識別 |
| ポーリング | 最終取得時刻 | 回数、次回時刻 | 取得済みID |
| Webhook | 受領と業務処理 | 署名結果、通知ID | 通知IDの一意記録 |
| ブラウザー認証 | 戻り先と認可結果 | state、エラー、期限 | 一回限りのstate |
APIの利用上限は、固定値を記事から転記しません。
DiscordのRate Limitsのように、応答ヘッダーやルート別条件を公式資料で確認し、制限を無視する実装を避けます。
地図APIでは、キーを持てば安全というわけではありません。
Google Maps Platformのセキュリティ推奨事項に沿い、利用するAPI、アプリ、Webサイト、IPなどで資格情報を制限します。
認証から運用までを六段階で設計する
連携先のサンプルコードを貼る前に、利用者とシステムの責任を決めます。
- 利用者が開始する操作と外部へ渡すデータを決める
- 必要最小限の権限と同意画面を決める
- 認証情報を端末とサーバーのどちらで保持するか決める
- 成功、期限切れ、拒否、上限超過、通信断をテストする
- 再試行、重複防止、取り消し、ログ削除の手順を作る
- API版、規約、審査条件の変更を確認する担当者を置く
LINEではチャネルアクセストークンにも種類と期限があります。
LINE Developersのトークン資料で、短期、長期、期限付きなどの違いを確認し、更新と失効の手順を設計してください。
利用者が連携を解除した後は、アクセストークンを残したままにしません。
アプリ内のログアウト、外部側での権限取り消し、保存データの削除を別々の操作として扱います。
利用上限へ達する時刻を見積もる計算例
次の数字は、呼び出し計画を考えるための仮定であり、特定APIの現在の上限ではありません。
1分あたり60回まで呼べるAPIを、利用者200人が30秒ごとに一回更新するとします。
一人あたり1分に2回なので、全体では200人×2回で400回です。
仮の上限60回を340回上回るため、全員が直接ポーリングする構成は成立しません。
| 条件 | 計算 | 1分の回数 |
|---|---|---|
| 一人 | 60秒÷30秒 | 2回 |
| 200人 | 200人×2回 | 400回 |
| 仮の上限との差 | 400回－60回 | 340回超過 |
更新間隔を延ばすだけでなく、Webhook、サーバー側キャッシュ、変更がある利用者だけの更新を検討します。
実装時は公式レスポンスの上限情報を読み、固定秒数だけの再試行で混雑を増幅させないようにします。
APIキーとトークンを端末へ露出させない
アプリへ埋め込んだ秘密値は、配布後に解析される可能性があります。
外部サービスの仕様上サーバーで保持できる秘密鍵はサーバー側へ置き、端末には利用者固有で短い権限のトークンだけを渡します。
ただし、すべてのキーを同じ方法で隠せるわけではありません。
地図SDKのように配布アプリから利用するキーは、公式の制限方法を使ってアプリ識別子や利用APIを限定します。
入力値、外部応答、権限判定、秘密情報の保管は別々にレビューします。
OWASP ASVSはWebアプリとサービスの技術的セキュリティ制御を検証する要件集として利用できます。
ログにはトークンや個人情報をそのまま残しません。
調査に必要な相関ID、連携先、失敗種別、再試行回数を記録し、本文と秘密値を分けます。
審査と規約変更をリリース工程へ組み込む
外部ログインや決済、コンテンツ表示は、実装できてもストア審査や提供元規約と一致しなければ公開できません。
App Review Guidelinesを使い、ログイン、データ利用、外部購入、ユーザー生成コンテンツなど該当項目を実装前から確認します。
連携先ごとに、API版、利用規約確認日、権限一覧、トークン更新日、障害時の連絡先を台帳へ残します。
提供元の変更を見つけたときは、影響する画面とデータ処理を台帳から追える状態が必要です。
外部APIが止まっても、アプリ全体を真っ白にしない設計も重要です。
利用できない機能を明示し、再試行時刻、保存済みデータ、代替手段を利用者へ伝えます。
外部サービス連携アプリのよくある質問
APIキーをスマホアプリへ書いてもよいですか？
秘密として扱うキーは埋め込まず、サーバー側で保持するか、利用者単位の短い権限へ置き換えます。
配布アプリから使う地図キーなどはGoogleの公式推奨事項に沿ってアプリと利用APIを制限してください。
Discord APIは一定間隔なら必ず呼べますか？
ルートや状況によって制限が異なるため、固定間隔だけを根拠にしません。
Discord公式のRate Limitsを読み、応答ヘッダーと再試行指示へ従う実装にします。
LINEのアクセストークンは一度発行すれば使い続けられますか？
トークンには種類と有効期間があり、発行、更新、失効の扱いが異なります。
LINE Developersの公式資料で採用する種類を決め、期限切れと漏えい時の再発行を試してください。
成功以外の経路を再現できる連携だけを公開する
API連携の完成条件は、成功レスポンスを画面に出すことではありません。
期限切れ、利用上限、重複通知、通信断、利用者による解除を再現し、データと権限を整合させられる状態が必要です。
- 連携方式で異なる待ち時間、重複、順序、戻り先の失敗
- 認証情報を守る基本は最小権限、利用先制限、更新と失効
- 利用上限の計算に必要な利用者数、更新間隔、一人あたりの回数
- 継続運用の成果物はAPI版、規約確認日、権限、障害連絡先の台帳
連携先へ渡す情報が増える前に、アプリ開発の要件定義で決める項目へ戻り、利用者の同意と失敗時の業務を要件として固定してください。
