要件定義とAPI設計 - TRACERY Lab.（トレラボ）

シリーズ: 要件定義とはそもそも何か

TRACERYプロダクトマネージャーの haru です。

API（Application Programming Interface）は、アプリケーション同士が機能やデータをやり取りするための「インターフェース」です。

システム開発において、APIは部品やサービスを再利用可能な形で提供し、異なるシステムやプログラム間の連携を容易にします。

APIには主に以下のような種類があります。

種類	説明
Web API	インターネットや社内ネットワーク経由でアクセスするAPI。HTTP/HTTPSで提供
ライブラリAPI（言語API）	プログラミング言語の標準ライブラリやフレームワークが提供する関数群
OS API	Windows API、POSIX API*1など、OSの機能（ファイル操作、メモリ管理など）を利用するためのAPI

本記事では、この中でWeb APIを対象に要件定義と設計の関係を説明します。

APIの公開範囲による分類
機能要件とAPI設計
- API設計におけるクラス設計・DB設計との関係
非機能要件とAPI設計の連携
まとめ

APIの公開範囲による分類

Web APIは、外部サービスとの連携から社内システムの内部統合まで、幅広い領域のレイヤーでシステムをつなぐ中核技術です。

Web APIは、公開範囲によって下図のように分類できます。

各APIの概要を以下に示します。

名前	説明
外部公開API	企業や組織が自社の機能やデータをインターネット経由で外部に提供し、他社サービスやアプリケーションとの連携を可能にする。利用者は公開されたAPI仕様を基に開発を行うため、API提供者は仕様を公開することが不可欠。また、一度利用が広がると多数の外部サービスに依存されるため、仕様変更は利用者への影響が大きく、容易に行えない。そのため、互換性の維持やバージョニング、明確な変更ポリシーが求められる。既存サービスの価値を拡張し、新たな連携サービスやビジネスモデルを生み出す基盤となる。
システム内公開API	社内システムにおけるサブシステム間の機能やデータ連携を担う。特にマイクロサービスアーキテクチャでは、疎結合な通信を実現する基盤として機能する。
画面・端末用API	SPA（シングルページアプリケーション）やスマートフォンアプリ、IoTデバイス上のソフトウェアなど、多様なユーザーインターフェースや端末からサーバーサイドのデータを取得・更新するために設計されたAPI。画面描画や端末操作の応答を高速化し、ユーザー体験や機器連携の効率を高める。

これらのWeb APIの中から、この記事では外部公開APIを対象に説明します。

説明にあたっては、外部公開APIで最も広く利用されているRESTful API *2を対象として設計プロセスを解説します。

機能要件とAPI設計

API設計では、要件定義で作成された開発品目一覧でリストアップされたAPI（【例】商品情報API）を詳細化します。

以下は、商品情報APIの機能要件です。

開発品目機能要件

商品情報API - 商品詳細の取得：商品IDを指定して、名称・価格・在庫・説明文・画像URLなどの詳細情報を取得できること。
- 一覧取得とフィルタリング：商品一覧を取得でき、カテゴリ・ブランド・価格帯・在庫有無などでフィルタリング可能であること。
- ページング機能：大量の商品データを扱えるように、limit / offset または page / per_page といったパラメータで分割取得できること。
- ソート機能：価格順・新着順・更新日時順など、指定条件で並び替えて取得できること。
- 更新情報の取得：前回取得以降に更新された商品のみの差分取得が可能であること。

開発品目	機能要件
商品情報API	- 商品詳細の取得：商品IDを指定して、名称・価格・在庫・説明文・画像URLなどの詳細情報を取得できること。 - 一覧取得とフィルタリング：商品一覧を取得でき、カテゴリ・ブランド・価格帯・在庫有無などでフィルタリング可能であること。 - ページング機能：大量の商品データを扱えるように、`limit` / `offset` または `page` / `per_page` といったパラメータで分割取得できること。 - ソート機能：価格順・新着順・更新日時順など、指定条件で並び替えて取得できること。 - 更新情報の取得：前回取得以降に更新された商品のみの差分取得が可能であること。

このような機能要件から 入力（リクエストパラメータ）・処理内容（ビジネスロジックの流れ）・出力（レスポンススキーマ） を具体化します。

以下の表では、商品情報APIの機能要件を基に入力・処理・出力へと整理し、設計内容として具体化した例を示します。

項目	内容
入力（リクエストパラメータ）	商品詳細の取得 `GET /products/{id}` において `id` を必須パラメータとする。一覧取得とフィルタリング `GET /products` において `category`（カテゴリ）、`brand`（ブランド）、`price_min`（価格最小）、`price_max`（価格最大）、`in_stock`（在庫有無）などのクエリパラメータを設ける。ページング機能 `limit` / `offset` または `page` をクエリパラメータとして設ける。ソート機能 `sort` パラメータを用意し、価格順・更新日時順などを指定可能にする。更新情報の取得 `updated_since` パラメータを設け、指定日時以降に更新された商品のみを返せるようにする。
処理内容（ビジネスロジック）	商品詳細の取得 DBからIDに対応する商品を検索し、カテゴリやブランド情報も結合して返す。一覧取得とフィルタリング指定された条件に基づき、SQLのWHERE句などを利用してフィルタリング。ページング機能指定件数で取得し、総件数もカウントして返す。ソート機能 ORDER BYを利用し、指定条件で並び替えを実行。更新情報の取得 `updated_at` が `updated_since` 以降のレコードを抽出。
出力（レスポンススキーマ）	商品詳細の取得 id, 名前、価格、商品説明文、在庫数、画像URLなどを返却。一覧取得とフィルタリング商品配列に加え、`total_count`（商品数）を含める。ページング機能 `page`（ページ数）をレスポンスに含める。

API設計におけるクラス設計・DB設計との関係

さらに、クラス設計で整理されたドメインモデルや、DB設計で確定したエンティティやスキーマ設計もAPI設計の入力として参照します。

これにより、「APIでどの情報を受け渡すべきか」「APIの処理内容とデータ永続化をどう関連づけるか」が明確になります。

また、API設計ではクラス設計やDB設計との間で整合性を確認しながら相互に調整を行うことが重要です。

たとえば、APIレスポンスに必要な情報がDB設計に不足していればスキーマを見直す、といったフィードバックをすることで、設計全体の整合性を確保します。

非機能要件とAPI設計の連携

非機能要件は下図に示す要素で構成されます。

API設計では、これらの非機能要件のうち、主に利用品質の有効性、効率性、リスク緩和、プロダクト品質の性能効率、互換性、信頼性、セキュリティ に着目します。

有効性

有効性*3は、ユーザーや関係者が目標や成果を達成できる度合いです。

たとえば、商品データを外部サイトに提供するAPIで、クライアントとなる価格比較サイトのシステムが目的の商品情報を検索・取得し、在庫や価格を正確に反映できる場合、そのAPIは有効性が高いといえます。

設計観点	内容
リソースと機能の発見容易性	エンドポイント構造や命名が一貫しており、外部開発者が目的のリソースを迷わず利用できる。【例】 - 役割が直感的に理解できるURL設計。たとえば、`/products`（一覧）、`/products/{id}`（詳細）、`/categories`、`/brands` など。
入力・取得条件の適切性	クエリパラメータやリクエスト形式が明確で、誤入力や意図しないデータ取得を防ぐ。【例】 - 統一形式（エラーコード＋フィールド＋理由）でエラー情報を返す。
整合性と再現性の確保	同じ条件で同じ結果を返し、データ更新のタイミングや仕様が明確。【例】 - 時点指定のスナップショット取得を提供する。たとえば、クライアントがクエリパラメータで`as_of=2025-08-01T00:00:00Z` を指定し、「特定時点の状態を固定して取得する」と API に明示することで、一覧・集計の一貫性を担保できるようにする。

効率性

効率性*4は、ユーザーが操作にかける時間に対して、どの程度の成果が得られるかを示す度合いです。

たとえば、APIのクライアントとなる価格比較サイトが商品一覧を取得して差分同期し、在庫や価格を即時に反映でき、しかも少ないリクエスト回数・短い転送時間で済む場合、効率性が高いといえます。

設計観点	内容
データ転送の最小化	クライアントからの指定により返すデータ量を必要最小限に抑える。【例】 - フィールド選択：クライアント側で`fields=id,name,price,thumbnail_url`など取得するフィールドを指定する。 - 軽量シリアライズ*5のために、JSONでは不要な情報を省いて最適化し、必要に応じてProtocol BuffersやMessagePackなどのバイナリフォーマットを用いることで、通信量を削減し処理効率を高める。
往復回数の削減（N+1回避）	必要情報を一度で取得できる形にする。【例】 - 一括取得/バッチ：`GET /products?ids=SKU-1,SKU-2,...`、必要なら `POST /products/batch`
同期効率（差分・条件付き要求）	毎回の全データ取得を避ける。データの更新がなければデータ本体を返さず効率化する仕組みを活用する。【例】 - 条件付きGET：クライアントに`ETag`*6を保存し、次回リクエスト時に`If-None-Match`ヘッダとして送信。サーバーは ETag を比較し、変更がなければ HTTPステータスコード`304 Not Modified` を返す。

リスク緩和

リスク緩和*7は、システムや製品の利用によって生じる、健康、安全、財産、環境、情報セキュリティなどへの潜在的なリスクを回避または低減できる度合いを指します。

たとえば、ユーザーが大量のAPIリクエストを意図せず実行して料金が過大に発生してしまう場合、利用者にとって大きな経済的負担となり、サービスへの安心感が損なわれる可能性があります。

これらを未然に防ぐ設計が、リスク緩和性の高いAPIです。

設計観点	具体策 / 実装例
レート制限とクォータ	利用量の上限を制御し、過剰な呼び出しによる課金増加を防ぐ。【例】 - クライアント/トークン単位で上限（秒/分/日/月単位）を設定（トークンバケット等）
ソフト/ハードの利用上限（支出上限）	利用量や課金額に応じて段階的な制御を行い、想定外の請求を回避する。【例】 - ソフトリミット8到達で警告、ハードリミット*9到達で自動停止or要確認（管理画面/メール/Slack通知） - 契約ごとに月額上限金額やクレジット残高*を設定する。

性能効率

性能効率*10は、指定された条件下でシステムが必要な性能をどれだけ効率的に提供できるかを表します。

性能効率は、「時間効率性」「資源使用効率性」「容量」など3つのサブ特性に分類されます。

API設計において、前述の利用品質における「効率性」はAPIクライアント側の非機能要件であるのに対し、「性能効率」はAPI（サーバーサイド）側の非機能要件に該当します。

APIの性能効率は、ユーザーがどれだけアクセスしても安定して使えることにつながります。

たとえば、大量のリクエストやデータ処理が同時に行われても、サーバー側の設計がしっかりしていれば遅延や停止を防ぐことができます。こうした工夫により、利用者は快適にサービスを使え、同時に運営側も無駄なコストを抑えられます。

以下の表は、性能効率のサブ特性をAPI設計に落とし込む際の設計観点をまとめたものです。

サブ特性	設計観点
時間効率性（Time behavior）*11	API の応答時間や処理遅延を最小限に抑え、SLA12 に沿ったレスポンスタイムを保証する。【例】 - ネットワークの配信効率を向上させる（送信データの圧縮、HTTP/2/3の使用、CDNキャッシュ13の利用。 - サーバ処理効率を向上させる。（インデックス最適化14、N+115クエリ防止）
資源利用性（Resource utilization）*16	CPU、メモリ、ネットワーク帯域などの利用効率を最適化し、過剰な負荷やスパイク時の性能劣化を防ぐ。【例】 - サーバ資源節約効果の高い実装を採用する（結果キャッシュ17、プリフェッチ18）
容量（Capacity）*19	想定される最大同時リクエスト数や最大データ量に対応できるようにする。【例】トラフィックや処理量を制御・分散する仕組みを活用する。（レート制限20、スロットリング21、非同期化*22 ）

互換性

互換性*23は、システムやソフトウェアが他の製品、コンポーネント、または環境と競合せずに共存し、相互に情報を交換・活用できる度合いを示します。互換性は異なるシステム間でのスムーズな動作やデータ連携を保証することを目的とし、「共存性」と「相互運用性」の2つのサブ特性に分類されます。

互換性を意識したAPI設計は、異なるシステムやプラットフォーム間での連携を円滑にし、導入や運用コストの削減にもつながります。

さらに、外部サービスとの連携や将来の拡張性を担保するうえでも欠かせない要素であり、ビジネスの成長を支える基盤となります。

以下の表は、互換性のサブ特性をAPI設計に落とし込む際の具体策をまとめたものです。

サブ特性設計観点

共存性（Co-existence）*24 API が同一環境内の他の API やソフトウェアとリソース（ポート・CPU・メモリ・ストレージ等）や設定を奪い合わず、干渉や性能低下を起こさないようにする。
【例】
- タイムアウト/リトライ設計：負荷をコントロールし、同居サービスへの輻輳拡大を回避する。
- リソース上限：ページング上限・レスポンスサイズ上限・同時接続上限を公開し、基盤資源の取り合いを防ぐ。
- 名前空間の衝突回避：ヘッダ/クッキー/クエリのプレフィックス運用（【例】X-Client-*、x-拡張）や予約語の明示で値が意図せず上書きされるなどの他のサービスやミドルウェアとの干渉を防止。
- キャッシュ健全性：レスポンスヘッダーのCache-Control*25、Vary*26、ETag 等の設計を適切化し、プロキシや別サービスのキャッシュを汚染しない。

相互運用性（Interoperability） *27 他のシステムやコンポーネントと正しくデータやサービスを利用できるようにする。
【例】
- 後方互換の維持：非互換変更はバージョン分離（/v2 など）とdepreciation告知。
- データ/メディア型の標準化：application/json（UTF-8）、application/problem+json（エラー）、ファイルはmultipart/form-data等を明示。日時は ISO 8601 UTCを使用、ID/通貨/単位はISOに準拠する。
- スキーマ共有：OpenAPI、JSON Schema を公開、サンプル・コード生成を提供する。
- セマンティクスの合意：列挙値・状態遷移・エラーコード辞書を一元管理し、意味の齟齬を防止する。

サブ特性	設計観点
共存性（Co-existence）*24	API が同一環境内の他の API やソフトウェアとリソース（ポート・CPU・メモリ・ストレージ等）や設定を奪い合わず、干渉や性能低下を起こさないようにする。【例】 - タイムアウト/リトライ設計：負荷をコントロールし、同居サービスへの輻輳拡大を回避する。 - リソース上限：ページング上限・レスポンスサイズ上限・同時接続上限を公開し、基盤資源の取り合いを防ぐ。 - 名前空間の衝突回避：ヘッダ/クッキー/クエリのプレフィックス運用（【例】`X-Client-`、`x-`拡張）や予約語の明示で値が意図せず上書きされるなどの他のサービスやミドルウェアとの干渉を防止。 - キャッシュ健全性：レスポンスヘッダーの`Cache-Control`25、`Vary`*26、`ETag` 等の設計を適切化し、プロキシや別サービスのキャッシュを汚染しない。
相互運用性（Interoperability） *27	他のシステムやコンポーネントと正しくデータやサービスを利用できるようにする。【例】 - 後方互換の維持：非互換変更はバージョン分離（`/v2` など）とdepreciation告知。 - データ/メディア型の標準化：`application/json`（UTF-8）、`application/problem+json`（エラー）、ファイルは`multipart/form-data`等を明示。日時は ISO 8601 UTCを使用、ID/通貨/単位はISOに準拠する。 - スキーマ共有：OpenAPI、JSON Schema を公開、サンプル・コード生成を提供する。 - セマンティクスの合意：列挙値・状態遷移・エラーコード辞書を一元管理し、意味の齟齬を防止する。

信頼性

信頼性*28は、「成熟性」「可用性」「障害耐性」「復旧性」の4つのサブ特性に分類されています。

信頼性を備えたAPIは、単なる機能提供にとどまらず、長期的にサービスを支える柱となり、継続的な価値を利用者へ届けます。

そのためには、障害に強く安定稼働を維持できる堅牢な設計が不可欠であり、利用者は安心してサービスを使い続けることができます。

以下の表は、信頼性のサブ特性をAPI設計に落とし込む際の具体策をまとめたものです。

サブ特性	設計観点
成熟性（Maturity）*29	APIが通常の運用条件下で安定動作し、バグや故障の発生率を低く抑えられるようにする。【例】 - 観測性を高め、障害や異常を「見える化」して早期に検知する仕組みを作る。　- 構造化ログ：JSON形式など解析しやすい形式で出力し、ログ収集基盤で検索・集計できるようにする　- メトリクス：レスポンスタイム、エラー率の継続的測定　- トレース（相関ID）：各リクエストに一意の相関IDを付与し、複数のサービスをまたぐ処理をトレースできるようにし、問題がどの部分で発生しているか特定しやすくする。
可用性（Availability） *30	障害やメンテナンス時でも可能な限りAPIが利用可能であるようにする。【例】 - 冗長化：マルチAZ/マルチリージョン、ステートレス化と水平スケール - 計画停止の扱い：メンテ時はHTTPステータスコード`503 Service Unavailable`を返し、レスポンスヘッダ `Retry-After` でリトライ推奨時間を返す。 - デプロイ戦略：ブルー/グリーンデプロイ、即時ロールバック手順の確立。
障害耐性（Fault Tolerance） *31	ネットワーク障害や一部コンポーネントの故障時でも、APIの使用を可能にする。【例】 - タイムアウト/リトライ：　- 外部呼び出しは短めのタイムアウトを設定し、応答がなければすぐに制御を戻す。　- リトライ時間のアルゴリズムに、指数バックオフ32とジッタ33を併用する：複数のクライアントが同時に失敗して一斉に再試行してしまうことで発生する「スロースタート問題34」や「スパイク負荷35」を避ける。　- 冪等性（idempotency）36前提とした設計*：書き込み系は冪等性を前提に設計し、リトライしても「二重注文」や「二重決済」などの副作用を生じないようにする。
回復性（Recoverability） *37	障害発生後に迅速かつ正確にAPIサービスを復旧できるようにする。【例】 - イベント再処理：障害時に失われたイベントやメッセージを再処理できるようにする。 - データ復旧：データ破損や消失があっても短時間で復元できるようにする。スナップショット/トランザクションログの組み合わせで復旧 - バージョン巻き戻し：スキーマ/コードの安全なロールバック手順の確立

セキュリティ

セキュリティ*38は、「機密性」「完全性」「否認防止」「責任追跡性」「真正性」の5つのサブ特性に分類されています。

APIは外部と情報をやり取りするインターフェースであるため、不正アクセスやデータ改ざんのリスクに常にさらされています。セキュリティを十分に考慮しなければ、利用者の信頼を失い、サービス全体の継続性にも影響を及ぼします。

安全性を確保したAPIは、ユーザーに安心して利用してもらえるだけでなく、開発・運用側のリスク低減にも直結します。

以下の表は、セキュリティのサブ特性をAPI設計に落とし込む際の具体策をまとめたものです。

サブ特性	設計観点
機密性（Confidentiality） *39	許可されていない利用者が情報にアクセスできないようにする。【例】 - 通信の秘匿：TLS1.2以上必須40、HSTS41、最新暗号スイートの利用42、前方秘匿性の確保43。個人情報のマスキング44/トークナイゼーション45 - 認可の粒度：OAuth246/OpenID Connect47の使用により、スコープ/ロールでフィールド・操作を制御 - CORS（Cross-Origin Resource Sharing）48の最小化：許可ドメインを限定する、資格情報49の扱いを厳格化し、APIキーやトークンをクライアント側に安易に保持させないように設計する*50。
完全性（Integrity） *51	リクエストやレスポンスの通信途中の第三者による改ざんを防ぐ。【例】 - 改ざん検知：リクエスト署名52やWebhook署名53の検証。
否認防止（Non-repudiation） *54	送信者や受信者が後から関与を否定できないようにする。【例】 - 不可否認の証跡：署名付きリクエスト/応答（JWS55, mTLS クライアント証明書56）、時刻印（`X-Timestamp`）*57 等の使用
責任追跡性（Accountability） *58	監査やトラブルシューティング時に追跡可能にする。【例】 - 相関ID：HTTPヘッダの`traceparent`59や`X-Request-Id`60 を全経路で伝搬（分散トレース含む） - 監査ログ：呼出元ID/スコープ/対象リソース/パラメータ要約/結果/レイテンシ61等を構造化*して記録。
真正性（Authenticity） *62	やり取りする情報や利用者が正しいものであることを保証する。【例】 - 相互認証：　- OAuth2/Open ID Connect：アクセストークンやIDトークンを利用し、利用者の権限や本人性を保証する。JWT*63の検証により（発行者、利用者、有効期限、使用可能開始時刻等）を確認する。

まとめ

本記事では、要件定義とAPI設計の関係を整理し、両者をどのように結び付けるかを解説しました。

要件定義で明確にした機能要件は、API設計において「どの情報を受け渡すのか」「どのような操作を提供するのか」といった具体的なインターフェースへと落とし込まれます。

要件を入力・処理・出力の観点から設計へ反映する流れを示し、さらにクラス設計やDB設計と整合性を取りながら相互に調整を行うことで、システム全体としての一貫性を確保できることを説明しました。

また、機能面に加え、性能効率やセキュリティ、利用品質といった非機能要件も、要件定義で検討した内容をAPI設計に反映させることが欠かせません。これらを適切に取り込むことで、利用者やビジネスにとって価値あるAPIを実現できます。

この記事を書いた人

haru

佐藤治夫。株式会社ビープラウド代表取締役社長。TRACERYのプロダクトマネージャー。エンジニアとして活動を始めて以来、モデリングを中心としたソフトウェアエンジニアリングを実践している。Xアカウント: https://x.com/haru860

*1:UNIX系OS間でアプリケーションの移植性を高めるためにIEEEが策定した標準規格「POSIX」で定義されているC言語の関数群のこと

*2:Webサービスを設計・実装する際に広く採用されているアーキテクチャスタイル。REST（Representational State Transfer）の原則に従い、システム内のデータや機能を「リソース」として捉え、それらに対して標準的なHTTPメソッド（GET、POST、PUT、DELETEなど）を用いて操作を行う。各リソースは一意のURIで表現され、クライアントはそのURIを介してリソースの状態を取得したり変更したりする。レスポンスは通常JSONやXMLといったフォーマットで返され、ステートレスな通信を前提とするため、各リクエストが独立して完結するのが特徴。この仕組みにより、シンプルかつ拡張性の高いAPI設計が可能となり、異なるシステムやプラットフォーム間での相互運用性が確保される。

*3:ISO/IEC 25010:2011に定義されている。

*4:ISO/IEC 25010:2011に定義されている。

*5:データをクライアントとサーバーの間でやり取りする際に、できるだけコンパクトかつ効率的に表現すること。

*6:Entity Tagの略。リソースのバージョンを識別するトークン（【例】ハッシュ値）。MDN ETagを参照のこと。

*7:ISO/IEC 25010:2011に定義されている。

*8:あらかじめ設定された上限に「到達したことを検知」するためのしきい値。到達した場合でも処理は止まらないが、警告を出したり、通知を送ったりして利用者に注意を促す。

*9:あらかじめ設定された絶対的な上限で、それを超える利用を強制的に遮断するしきい値。

*10:ISO/IEC 25010:2023に定義されている。

*11:指定された条件下での応答時間、処理時間、スループットなど、システムやコンポーネントの応答が、性能要求やユーザーの期待に対して適切か

*12:Service Level Agreement（サービスレベルアグリーメント）の略で、サービス提供者と利用者の間で、提供するサービスの品質やレベルを定めた契約のこと。

*13: Contents Delivery Network。Webサイトのコンテンツを高速かつ安定して配信するための仕組み。世界中に分散配置されたサーバー群（キャッシュサーバー）を利用して、ユーザーの地理的な位置に近いサーバーからコンテンツを配信することで、表示速度の向上やサーバーへの負荷軽減を実現する。

*14:データベース（DB）の検索やデータ取得を効率化するために、テーブルの列に適切なインデックスを設計・設定し、クエリの実行速度やリソース利用効率を改善すること。

*15:データベースにアクセスする際に、本来なら 1回のクエリでまとめて取得できるデータを、繰り返し多数のクエリで取得してしまう設計上の非効率のこと。多くの場合、「一覧取得後に関連データを1件ずつ問い合わせる」ことで発生する。

*16:指定された条件下で、システムやコンポーネントがどれだけ効率的にハードウェアやソフトウェアの資源（CPU、メモリ、ネットワークなど）を利用するか。

*17:あるリクエスト（【例】商品一覧の取得、集計結果の計算）に対してサーバーが生成したレスポンスを保存し、同じ条件で再度リクエストが来たときに、保存済みの結果をそのまま返す仕組み

*18:将来必要になることが予想されるデータを、事前にまとめて取得しておく手法

*19:システムが、パフォーマンスを保ちながら処理できる最大ユーザー数、データ量、トランザクション数などの上限が要求を満たしているか、または想定された負荷に耐えられるか

*20:一定時間内にクライアントが送信できるリクエスト数を制御する仕組み。

*21:APIやシステムへのリクエストの処理速度を意図的に制御する仕組み。遅延応答、優先度制御など。

*22:処理を即時に完了させず、バックグラウンドや別のプロセスに任せて並行的に進める仕組み。ジョブキュー / メッセージキューを使用し、「処理依頼を受け付けた」ことだけをクライアントに返す。処理結果は、「ジョブ完了状態」を後から確認するポーリングや、完了時にサーバーが通知するWebhookでAPIクライアント側システムが受け取る。

*23:ISO/IEC 25010:2023に定義されている。

*24:他のシステムやアプリケーションと同じ環境（OS、ネットワーク、デバイス）上で動作する際に、競合を起こさず正常に機能できるか

*25:HTTPレスポンスやリクエストにおいてキャッシュの挙動を制御するための主要な指示ヘッダー。レスポンスに付与することで、ブラウザやCDNなどの中間キャッシュがどの程度の期間データを保存できるか、また再利用時に再検証が必要かどうかを指定できます。代表的なディレクティブには、キャッシュ可能時間を秒数で示す max-age、キャッシュを完全に禁止する no-store、常に再検証を求める no-cache、共有キャッシュ向けに適用する public／個人用キャッシュに限定する private などがある。これにより、配信効率の向上と最新性のバランスを柔軟に調整できる。

*26:キャッシュがレスポンスを利用できる条件を示すためのHTTPレスポンスヘッダー。レスポンス内容が特定のリクエストヘッダーに依存する場合、そのヘッダー名を Vary に列挙する。これにより、CDNやブラウザキャッシュはリクエスト条件ごとにレスポンスを区別して保存し、適切に返却できる。たとえば Vary: Accept-Encoding とすれば、圧縮方式の違いに応じてキャッシュを分け、gzip非対応クライアントに誤った圧縮データを返すことを防ぐ。同様に Vary: Accept-Language は、言語設定に応じて異なる翻訳ページを正しくキャッシュさせる用途で用いられる。適切に指定しないと、ユーザーに不正確なレスポンスが返る原因となるため、国際化対応や圧縮配信などでは特に重要。

*27:他のシステム、製品、コンポーネントと情報を交換し、相互に利用できる度合い。データ形式や通信プロトコルの互換性、APIの標準準拠が適切か

*28:ISO/IEC 25010:2023に定義されている。

*29:ソフトウェア製品またはシステムが、欠陥の発生頻度や障害の発生確率が低く、安定して期待されるサービスを提供できる度合い

*30:必要なときにサービスや機能を利用できる度合い

*31:ハードウェアやソフトウェアの障害、または操作ミスが発生しても、許容できる性能レベルで動作を継続できる度合い

*32:エラーや一時的な失敗が発生したときに、リトライ間隔を徐々に長くしていくアルゴリズム。【例】1秒 → 2秒 → 4秒 → 8秒 → 16秒。リトライ秒数をレスポンスヘッダのRetry-Afterで指定する。

*33:待機時間や遅延にランダム性を加えること。

*34:ネットワークやAPI通信で新しい接続を開始する際に、データ送信速度（スループット）が最大まで使えず、徐々にしか上がらない現象。

*35:普段よりも急激にリクエスト数や処理量が増加し、システムやAPIに一時的に大きな負荷がかかる現象を指します。「スパイク」は突発的・瞬間的な山のような負荷の立ち上がりを意味する。

*36:同じリクエストを何度繰り返しても、最終的な結果が変わらない性質。

*37:障害や停止が発生した後、必要なデータを復旧し、望ましい運用状態を一定時間内に回復できる度合い

*38:ISO/IEC 25010:2023に定義されている。

*39:権限を持つユーザーのみが情報にアクセスできるように制御し、データが不正に閲覧・漏洩されないことを保証するか

*40:TLS1.2 以上を必須とすることで、既知の脆弱性が多い古いバージョン（SSL, TLS1.0/1.1）を排除できる。

*41:HTTP Strict Transport Security。ドメインに常に HTTPS でアクセスすることを強制する仕組み。中間者攻撃（HTTP ダウングレード攻撃や Cookie 盗聴）を防げる。

*42:TLSで使用される暗号スイートは、鍵交換方式・暗号アルゴリズム・ハッシュ関数の組み合わせ。最新の強力なスイートを使用することで、盗聴や改ざんのリスクを減らす。

*43:セッションで使った暗号鍵が漏れても、過去の通信内容は解読できないことを保証する性質です。これにより、サーバー秘密鍵が将来漏洩しても過去のAPI通信が守られる。TLS1.3 では必ず前方秘匿性が保証される。

*44:個人情報など（氏名、住所、電話番号、クレジットカード番号など）の一部または全部を置き換えて、本物の値を隠す処理。基本的に不可逆（戻せない）

*45:個人情報などを、一意なトークン（代替ID）に置き換える仕組み。変換元とトークンの対応関係は専用の安全なトークンサービスが管理し、値を元に戻せる（可逆性がある）。PCI DSS対応（クレジットカード業界のセキュリティ基準）で広く使われる。

*46:認可（Authorization）のためのフレームワーク。ユーザーが自分の認証情報（ID/パスワード）を第三者アプリに渡さなくても、APIやサービスへのアクセス権を委譲できる仕組みを提供する。

*47:OAuth2 を拡張した「認証（Authentication）のための仕様。OAuth2 はあくまで「誰がどの範囲でアクセスできるか」を管理する仕組みであるが、OpenID Connect を組み合わせることで「そのユーザーが誰なのか」を安全に識別できる。

*48:ブラウザが持つ同一オリジンポリシー（Same-Origin Policy）によって、異なるドメインからのリクエストは基本的にブロックされる。ただし、APIを外部から使えるようにする場合は、CORSヘッダ（Access-Control-Allow-Origin）を設定し、許可するオリジン（ドメイン）を明示する必要がある。

*49:APIを利用する際にリクエストと一緒に送られる「認証・認可関連の情報」。WebブラウザがクロスオリジンでAPIを呼び出す際に、「資格情報（credentials）」として付与されるのは、Cookie（セッションIDやログイントークンなど）、認証ヘッダ（Authorization: Bearer のようなAPIキー・アクセストークン。）、TLSクライアント証明書（（mTLS利用時に）クライアントが提示する証明書。）など。

*50:Access-Control-Allow-Credentialsヘッダで、Cookieや認証ヘッダを含めるかを制御する

*51:情報や処理が不正に改ざんされないように保護し、正確で一貫性のある状態を維持できるか

*52:APIリクエストの本文やヘッダに対して、秘密鍵を用いて HMAC-SHA256 などのハッシュを計算し、署名を付与する仕組み。サーバーは同じ秘密鍵を使ってハッシュを再計算し、送信された署名と一致するかを検証する。

*53:Webhook で外部サービスからイベント通知を受け取る場合、通知が攻撃者から偽造されていないことを保証する仕組み。送信元サービスはイベントデータに署名を付与し、受信側はその署名を検証する。代表例として、Stripe や GitHub の Webhook では HMAC-SHA256 による署名検証が必須になっている。

*54:ユーザーまたはシステムが実行した行為について、後から否認できないよう証拠を保持し、責任を明確にできるか

*55:JSON Web Signature。JSONデータに電子署名を施して改ざん検知や送信者の正当性を保証する仕組み。JWT（JSON Web Token）の署名部分などにも利用されている。

*56:相互TLS認証（mutual TLS, mTLS）で利用される証明書のこと。通常のTLS通信では「サーバー証明書」を使ってクライアントがサーバーの正当性を検証するが、mTLSではサーバーとクライアントの双方が証明書を提示し合い、お互いを認証する。

*57:APIのリクエストやレスポンスに付与される「時刻印（タイムスタンプ）」を示すHTTPヘッダ。主にセキュリティや信頼性を高める目的で利用される。攻撃者が過去のリクエストを盗聴して再送（リプレイ）するのを防いだり、サーバーが受け取った X-Timestamp と現在時刻を比較して、許容範囲（【例】±5分以内）に収まっているか確認したりする。

*58:ユーザーやシステムの操作を特定の主体に関連付けられるよう記録し、必要に応じて追跡できるか

*59:W3Cが策定した Trace Context 仕様で定義されているHTTPヘッダ。分散システム間でリクエストのトレース情報（トレースIDやスパンIDなど）を伝達するために利用される。これにより、システムやソフトウェア間の呼び出しを一貫して追跡でき、ログやメトリクスを結びつけて可観測性を高めることができる。OpenTelemetry, Jaeger, Zipkin, Datadog, AWS X-Ray などの APM / 分散トレーシングツールで広く採用されている。新規システムや分散トレーシング対応のサービスでは、X-Request-Idよりも、ほぼ traceparent が主流。

*60:X-Request-Id は、リクエストを一意に識別するために用いられる非標準のHTTPヘッダ。各サービスやフレームワークが独自に生成・利用する。ログやレスポンスに含めることで、リクエスト単位での追跡や問い合わせ対応が容易になる。レガシー環境やシンプルなリクエスト追跡では、依然として traceparentよりも、X-Request-Id が使われている。

*61:latency：処理や通信にかかる「待ち時間」や「遅延時間」のこと。

*62:ユーザー、デバイス、システム、通信が真正であることを確認し、なりすましを防止できるか

*63:JSON Web Token。JSON形式のデータを使って「誰が・何をしたか」を安全に表現し、署名付きでやり取りできるトークン規格。主に認証や認可の仕組みで利用され、OAuth2やOpenID Connectでも広く使われている。JWTはコンパクトでURLセーフな文字列として表現され、WebやAPIの通信で利用しやすいのが特徴。