目次

APIファースト設計

周辺資料: 学習インデックス · AWSサービス一覧（2026） · サービス別メモ（services/） · ユースケース（usecases/）

概要

APIファースト設計 を実務で使えるレベルまで理解するための要点整理。

この資料で身につくこと

  • 基本概念と設計判断の基準
  • 実装時に迷いやすいポイント
  • 運用フェーズでの注意事項

主要ポイント

  1. 要件を機能/非機能に分けて整理する
  2. サービス選定は運用負荷まで含めて比較する
  3. 監視・コスト・セキュリティを設計初期に組み込む

実務チェックリスト

  • 目的に対して過不足ないサービス構成になっているか
  • 障害時の挙動（再試行/フォールバック）を定義したか
  • コストドライバー上位3つを説明できるか
  • 監査対応に必要な証跡を取得しているか

ハンズオン課題

  • 小規模構成でPoCを作り、メトリクスを取得する
  • 負荷条件を変えてボトルネックを観測する
  • 改善案を3つ出してトレードオフを比較する

関連サービス

  • 設計対象の主要AWSサービス（2〜5個）を選び、採用理由を記録する

参考にすべき観点

  • 可用性: SLO/SLA、単一障害点
  • 性能: p95レイテンシ、スループット
  • コスト: 月額見積もり、伸び方
  • セキュリティ: 最小権限、暗号化、監査

追加詳細 1: 具体例シナリオ

シナリオA（小規模チーム）

  • 前提: APIファースト設計 を2〜5名で短期間に導入
  • 目標: まず動く構成を作り、運用負荷を最小化
  • 設計方針: マネージドサービス優先、手動運用ポイントを明文化

シナリオB（中規模プロダクト）

  • 前提: 複数開発チーム、継続リリースあり
  • 目標: 変更容易性と可観測性を両立
  • 設計方針: 非同期化、監視基盤、権限境界の分離

シナリオC（ミッションクリティカル）

  • 前提: 監査要件と高可用性が必須
  • 目標: 障害時でも業務継続できる設計
  • 設計方針: 冗長化、証跡保全、自動復旧手順の標準化

追加詳細 2: 判断フレーム（比較表）

観点 小規模導入 中規模運用 大規模運用
優先事項 速度・簡易性 安定運用・拡張性 可用性・統制
実行基盤 サーバーレス中心 コンテナ+サーバーレス 要件に応じたハイブリッド
データ設計 シンプル優先 読み書き分離検討 監査/再処理前提
監視運用 最低限のアラート SLOベース運用 自動復旧・当番運用
コスト管理 予算上限管理 ドライバー分析 単価最適化と予測

追加詳細 3: Mermaidで流れを可視化

flowchart LR
    R[要件整理] --> S[サービス候補比較]
    S --> P[PoC]
    P --> D[設計確定]
    D --> I[実装・デプロイ]
    I --> M[監視運用]
    M --> K[改善サイクル]

sequenceDiagram
    participant Dev as 開発
    participant IaC as IaC/CI
    participant AWS as AWS環境
    participant Ops as 運用

    Dev->>IaC: 変更をコミット
    IaC->>AWS: 検証環境へデプロイ
    AWS-->>Ops: メトリクス/ログ出力
    Ops->>Dev: 改善フィードバック
    Dev->>IaC: 設計を更新

追加詳細 4: 失敗パターンと改善例

失敗パターン 起きる問題 改善アクション
要件未整理で選定 後で作り直し 要件を機能/非機能で分離
監視を後付け 障害検知が遅延 初期設計に監視項目を組み込む
権限設計が粗い 監査NG・事故リスク 最小権限 + 定期棚卸し
コスト把握不足 予算超過 月次見積もりとアラート運用

追加詳細 5: 実践課題（ハンズオン）

  1. APIファースト設計 をテーマに最小構成を設計し、採用理由を3行で説明する
  2. 可用性を1段階上げる変更案を2つ作る
  3. コストドライバー上位3つを特定し、削減案を1つずつ出す
  4. 障害シナリオを2つ作り、検知->初動->復旧の手順を書く

追加詳細 6: レビュー観点（提出テンプレ）

  • 要件整合: 設計が目的に直結しているか
  • 運用可能性: 監視・手順・責任分界が明確か
  • 拡張性: 変更時の影響範囲を小さくできるか
  • 統制: セキュリティ・監査要件を満たすか
  • 費用対効果: 期待効果に対して運用コストが妥当か