クイズの説明
Step 3で学んだ内容の理解度をチェックします。
- 全8問
- 合格ライン: 80%（7問正解）
- 不合格の場合は復習してから再挑戦してください
問題
Q1. OpenAPI Specificationの主な目的はどれですか？
- A) APIのパフォーマンスを向上させる
- B) APIの仕様を機械可読な形式で定義し、ドキュメントやコードの自動生成を可能にする
- C) APIのセキュリティを強化する
- D) APIのデータベース設計を定義する
答えを見る
正解: B
OpenAPI Specificationは、APIの仕様をYAMLまたはJSON形式で記述する標準規格です。機械可読な形式のため、ドキュメント自動生成（Swagger UI）、クライアントコード生成、バリデーション、テスト生成などが可能になります。
Q2. OpenAPIで $ref を使う主な理由はどれですか？
- A) 外部APIを参照するため
- B) スキーマやレスポンスの定義を再利用し、重複を排除するため
- C) 認証トークンを参照するため
- D) データベースのテーブルを参照するため
答えを見る
正解: B
$ref はJSON Referenceの構文で、componentsに定義したスキーマやレスポンスを他の箇所から参照するために使います。これにより、同じ定義を何度も書く必要がなくなり、仕様書のメンテナンス性が向上します。
例: $ref: "#/components/schemas/User"
Q3. OpenAPIの allOf の機能として正しいのはどれですか？
- A) 複数のスキーマのうち1つだけに合致する
- B) 複数のスキーマのすべてを結合する
- C) 複数のスキーマのうち1つ以上に合致する
- D) スキーマの配列を定義する
答えを見る
正解: B
allOf: 複数のスキーマをすべて結合する（AND）— スキーマの継承・拡張に使うoneOf: 複数のスキーマのうち厳密に1つだけに合致する（XOR）anyOf: 複数のスキーマのうち1つ以上に合致する（OR）
allOfは基底スキーマを拡張する際によく使われます。
Q4. 「仕様ファースト」開発のメリットとして最も適切なのはどれですか？
- A) バックエンドの実装が速くなる
- B) フロントエンドとバックエンドが仕様合意後に並行して開発できる
- C) テストが不要になる
- D) データベース設計が自動化される
答えを見る
正解: B
仕様ファースト開発では、OpenAPI仕様書を先に作成・合意してから実装に入ります。フロントエンドはモックサーバー（Prism等）を使って即座に開発を開始でき、バックエンドも仕様に従って実装を進められるため、並行開発が可能になります。
Q5. OpenAPIのスキーマで format: email を指定した場合、何が起きますか？
- A) フィールドの値がメールアドレス形式であることを示すヒントになる
- B) 自動的にメールが送信される
- C) フィールドが暗号化される
- D) データベースのカラム型が設定される
答えを見る
正解: A
format はデータ型のヒントを提供するキーワードです。バリデーションツール（express-openapi-validator等）がこのヒントを使って形式チェックを行います。format: email の場合、メールアドレスの形式であることが期待されますが、バリデーションの厳密さはツールによって異なります。
Q6. Swagger UIの主な機能はどれですか？
- A) APIのソースコードを編集する
- B) OpenAPI仕様書からインタラクティブなAPIドキュメントを生成する
- C) データベースのテーブルを管理する
- D) APIのデプロイを自動化する
答えを見る
正解: B
Swagger UIは、OpenAPI仕様書を読み込んで、インタラクティブなAPIドキュメントを自動生成するツールです。各エンドポイントの詳細表示に加え、画面上からAPIを直接テスト実行することもできます。
Q7. モックサーバー（Prism等）の役割として正しいのはどれですか？
- A) 本番環境のAPIサーバーを置き換える
- B) OpenAPI仕様書のexampleデータに基づいてレスポンスを返す
- C) データベースにテストデータを投入する
- D) APIの負荷テストを実行する
答えを見る
正解: B
モックサーバー（Prism等）は、OpenAPI仕様書に定義されたexampleデータに基づいてレスポンスを返します。バックエンドの実装がなくても、フロントエンド開発者はモックサーバーに対してAPI呼び出しを行い、開発を進めることができます。
Q8. express-openapi-validator の validateResponses: true を本番環境で有効にすべきでない理由はどれですか？
- A) バリデーションがセキュリティリスクになるため
- B) レスポンスのバリデーションはパフォーマンスに影響し、仕様違反時にエラーを返す可能性があるため
- C) 本番環境ではOpenAPI仕様書が利用できないため
- D) 認証が無効になるため
答えを見る
正解: B
レスポンスバリデーションは開発・テスト環境では有用ですが、本番環境では以下のリスクがあります：
- バリデーション処理によるレイテンシの増加
- 仕様と実装の微細な差異でエラーレスポンスが返される可能性
- 開発時に発見すべき問題であり、本番環境で防ぐべきではない
開発環境で validateResponses: true にして仕様との整合性を確認し、本番ではリクエストバリデーションのみ有効にするのがベストプラクティスです。
結果
7問以上正解の場合
合格です。おめでとうございます。
Step 3「OpenAPIで契約を定義しよう」を完了しました。 次は Step 4「GraphQLの可能性を探ろう」に進みましょう。
6問以下の場合
もう少し復習しましょう。
| 問題 | 復習セクション |
|---|---|
| Q1, Q2, Q3 | step3_1 OpenAPI仕様の基礎 / step3_2 スキーマ定義 |
| Q4 | step3_4 API仕様ファーストの開発フロー |
| Q5 | step3_2 スキーマ定義とバリデーション |
| Q6, Q7, Q8 | step3_3 コード生成とドキュメント自動化 |
推定所要時間: 30分