メインコンテンツへスキップ
仕様書・設計 中級 全ツール共通

API設計プロンプト

REST / GraphQL APIのエンドポイント設計をAIと共同で行うプロンプト。OpenAPI仕様書も出力可能。

プロンプト 

以下の要件でAPIを設計してください。

## サービス概要
- サービス名: [名前]
- 目的: [このAPIで何を実現するか]
- 利用者: [フロントエンド / モバイルアプリ / 外部サービス 等]

## 設計するリソース
- [リソース1: 例）ユーザー（User）]
- [リソース2: 例）記事（Article）]
- [リソース3]

## 各リソースに必要な操作
| リソース | 操作 | 備考 |
|---------|------|------|
| [User]  | 一覧取得・詳細取得・作成・更新・削除 | — |
| [Article] | 一覧取得・詳細取得・作成 | 削除は論理削除 |

## 非機能要件
- 認証方式: [JWT / APIキー / OAuth 2.0 等]
- レスポンス形式: [JSON]
- ページネーション: [カーソルベース / オフセットベース]

## 出力形式
- REST API のエンドポイント一覧（メソッド・パス・説明）
- 主要なリクエスト/レスポンスのスキーマ
- OpenAPI（Swagger）YAML（必要であれば）
#API #設計 #REST #仕様書

REST vs GraphQL の選び方

RESTGraphQL
向いているケースリソースが明確・クライアントが多様フロント主導・データ取得が複雑
バイブコーディングでの主流✅ 多い△ 学習コストが高め

迷ったら REST を選びましょう。AIが生成しやすく、デバッグも簡単です。

命名規則

AI に渡す前に決めておくと設計の一貫性が保てます：

  • リソース名: 複数形の名詞（/users, /articles）
  • アクション: HTTP メソッドで表現（GET, POST, PUT, DELETE）
  • ネスト: 2階層まで（/users/{id}/posts）

OpenAPI 出力後の活用

生成された YAML を使って：

  • Swagger UI でドキュメントを可視化
  • AI に「この OpenAPI からサーバー実装を作って」と続けて依頼
  • AI に「この OpenAPI から TypeScript の型定義を生成して」と依頼
プロンプト集に戻る