feature-spec

技術仕様書

概要

アーキテクチャ上の意思決定、システム契約、技術設計を順を追って検討し、実装の詳細に深入りせず、簡潔な技術仕様書の作成を支援する構造化コマンドです。

確立された機能開発プロセスに従って、技術仕様書を作成します。以下のコンテキストを利用できます。

必読資料：

• 機能開発ガイド：@~/.local/share/dotfiles/ai/guides/feature-development-process.md
• ビジョン文書：@vision.md
• 要件文書：@requirements.md

注：プロジェクト内にガイドのコピーが @project/guides/feature-development-process.md にある場合は、プロジェクト固有の変更を反映したそのガイドを参照してもかまいません。

利用可能な追加コンテキスト：

• コードベース全体：backend/ と frontend/ ディレクトリにある既存のパターンを調査します
• 実装ガイド：backend/docs/guides/ と frontend/docs/guides/ を確認し、確立されたパターンを把握します
• 設計コンテキスト：関連する場合は、利用可能な MCP 接続を使用してデザインシステムにアクセスします

アプローチ：利用可能なすべてのコンテキストを技術的な意思決定に活用します。基本的な質問をするのではなく、既存のコードベースを分析して、実装パターンやアーキテクチャ上の意思決定の大部分を導き出してください。

重要：まず、仕様書作成の各フェーズを追跡する TODO リストを作成してください（通常は 3 フェーズです。機能に UI/UX 上の複雑さがある場合は、オプションの Phase 4（デザインブリーフ）を追加してください）。最初のフェーズを "in_progress"、その他のフェーズを "pending" に設定してください。

技術仕様書の構成

重要：仕様書では、実装ではなく、アーキテクチャとシステム契約を定義します。コードの書き方ではなく、対象と理由に焦点を当て、簡潔にまとめてください（5〜10 ページ）。

仕様書に含める内容：

• アーキテクチャの概要：中核となる意思決定とシステム構造
• システムコンポーネント：存在する要素と、それぞれの役割や契約
• データ契約：型定義（言語に応じたフロントエンド／バックエンド）、データベーススキーマ、API 契約
• 構成アーキテクチャ：システムの構成方法（詳細な例は含めません）
• 統合パターン：既存のシステムとの連携方法
• 品質特性：パフォーマンス、信頼性、保守性の要件

仕様書に含めない内容：

• ❌ 実装コードの例（計画書に記載します）
• ❌ 手順を追った実装の詳細
• ❌ 同じ概念の繰り返しの説明

プロセス：以下の 3 つのフェーズを順番に進めます

Phase 1：コンテキスト分析とスコープの確認

まず、利用可能なコンテキストを分析して、機能のスコープを把握します。

コンテキスト分析：

1. ビジョン文書と要件文書を確認し、機能のスコープを把握します
2. コードベースを調査して、既存のパターンとアーキテクチャのアプローチを特定します
3. backend/docs/guides/ と frontend/docs/guides/ にある実装ガイドを確認し、関連するパターンを把握します
4. 確立されたパターンに従うため、類似する既存機能を特定します

スコープの確認 — 必要に応じてのみ確認の質問をします：

• 要件に基づくと、これは [フルスタック／バックエンドのみ／フロントエンドのみ／バックグラウンド処理] のどれに当たるようです。こちらで正しいですか？
• 要件に記載されていない、特定の実装上の制約や希望はありますか？
• これは機能全体の実装ですか、それとも特定のフェーズ（例：「Phase 1：バックエンド基盤」）ですか？
• 文書に記載されているもの以外に、既存システムとの統合要件はありますか？

目標：技術的なスコープを確認し、準拠すべき関連する既存パターンを特定します。

一度に質問は 1 つだけ — 回答を待ってから先に進んでください。

フェーズ 2：既存のパターンを活用した実装設計

コードベースの分析とスコープの確認に基づき、確立されたパターンに従って実装を設計します。

設計方針：

1. 既存のパターンに従う：コードベース内の類似機能をテンプレートとして使用します
2. 確立された規約を適用する：実装ガイドに記載されたパターンに従います
3. 既存のシステムを活用する：確立された RBAC、マルチテナンシーなどと統合します
4. 具体的な質問をする：既存のパターンでカバーされていない固有の事項のみを質問します

バックエンド／データベースの作業の場合：

• 既存のエンティティパターンとリレーションシップに従ってデータをモデル化します
• 使用する言語に適した型定義を使ってサービスコントラクトを定義します
• 確立された REST 規約とレスポンス形式に従って API エンドポイントを設計します
• 型定義を使って API のリクエスト／レスポンスのコントラクトとデータ構造を記述します
• 標準的な認可権限とバリデーションのパターンを適用します
• 検索の統合：検索範囲とインデックス作成方針を決定します
  • 検索対象はエンティティ自身のフィールドのみですか、それとも関連エンティティのデータも含みますか？
  • 検索設定の方針を記録します
• ソートパラメーター：ソート可能な列とデフォルトのソート動作を記録します
  • ソート可能な列を具体的に列挙します
  • デフォルトのソート順を指定します
• 複数コンテキストに関する考慮事項：複数のアプリケーションコンテキスト（内部／外部、管理者／ユーザーなど）にまたがる機能の場合
  • コンテキストごとに必要なデータが異なる場合は、個別のレスポンス構造を作成します
  • 例：外部向けでは、管理者コンテキストで必要な内部フィールドを除外する場合があります
  • 現在は同一であっても、セキュリティ分離のために必ず明示的に分離します
• 許可するパラメーター：各コンテキストで許可するパラメーターを記録します
  • 作成／更新できるフィールドを列挙します
  • 除外されるフィールド（生成、計算、または制限されたフィールド）を記載します
• 複数コンテキストの認可：複数のコンテキストがある機能では、それぞれの権限を定義します
  • 内部コンテキスト：完全な CRUD 権限
  • 外部コンテキスト：限定された権限（多くの場合は読み取り専用）
  • パブリック API：異なる認証方式（API キーとセッション認証など）を使用する場合があります
  • 同じ権限名が複数のコンテキストに存在し、それぞれ異なるスコープを持つ場合があります
• 質問：類似機能では見られない、固有のビジネスロジック、制約、またはデータリレーションシップはありますか？

フロントエンド／UI の作業の場合：

• 既存の UI コンポーネントアーキテクチャとデータコントラクトのパターンに従います
• 確立されたレスポンシブ対応とナビゲーション統合の方法を使用します
• 標準のデザインシステムとコンポーネントライブラリの使用方法を適用します
• 型の整理：型をコンテキスト固有にするか、共有するかを決定します
  • コンテキスト固有の型：アプリケーションの異なる部分で異なるデータ構造が必要な場合
  • 共有／コアの型：すべてのコンテキストで真に共有される型に限ります
  • リクエストペイロードの型：使用するコードと同じ場所に配置します
• 質問：異なるコンテキストで同じデータ構造が必要ですか、それとも異なるデータのサブセットが必要ですか？
• 質問：固有の UI 操作や統合要件はありますか？

バックグラウンド処理の場合：

• 既存のジョブ処理とスケジューリングのパターンに従います
• 標準的なエラー処理とモニタリングの方法を適用します
• 質問：固有の処理要件や時間的制約はありますか？

目標：既存のコードベースのパターンを活用し、実装に固有の事項のみを質問します。

フェーズ 3：仕様書の作成

目標：システム設計とコントラクトに焦点を当てた、簡潔な（5～10 ページの）アーキテクチャ仕様書を作成します。

推奨するセクションの流れ：

各分野の担当者が連続して読めるよう、基盤となるデータからバックエンド、フロントエンドへと自然に流れる構成にします。

1. 概要 - 共通のコンテキスト（全員が読む）
2. アーキテクチャ概要 - 中核となる設計上の決定事項（全員が読む）
3. データアーキテクチャ - データベーススキーマ、モデル、バリデーション（ここからバックエンド担当者が読む）
4. API アーキテクチャ - エンドポイント、リクエスト／レスポンスの契約（バックエンド担当者が読み進める）
5. 認可アーキテクチャ - 権限、ポリシー（バックエンド担当者が読み進める）
6. 統合アーキテクチャ - 検索、監査、ドキュメント、外部システム（バックエンド担当者が読み進める）
7. フロントエンドアーキテクチャ - 型、コンポーネント、ページ（フロントエンド担当者が読み、必要に応じて API セクションを参照）
8. デザインと UX の要件 - デザインブリーフの参照情報と開発者向け概要（デザイナーとフロントエンド担当者）
9. 設定アーキテクチャ - 設定、機能フラグ（補助的な事項）
10. ファイル構成 - ファイルの配置場所（補助的な事項）
11. 品質特性 - パフォーマンス、セキュリティ、信頼性（補助的な事項）

この流れが有効な理由：

• 連続して読める：バックエンド開発者はセクション 1〜6、フロントエンド開発者は 1〜2 と 7〜8 を読みます
• 自然な進行：データ層 → バックエンド → プレゼンテーション → 補助的な事項
• あちこち移動する必要がない：各担当分野の内容がひとまとまりになっています
• 共通の土台：全員が概要とアーキテクチャのコンテキストから読み始めます

柔軟性：機能に関係のないセクションは省略できます（例：バックエンドのみの機能では、フロントエンド／デザインのセクションを省略します）。

---

含めるべき主なセクション（各セクションの詳細）：

• API アーキテクチャ（バックエンド／API の作業がある場合）：

  • エンドポイント定義（ルート、パラメーター、クエリパラメーター、ソート可能な列）
  • リクエスト／レスポンスの契約（バックエンドのみ - 構造と形式）
    • リストレスポンスのテンプレート／シリアライザーファイルを記載（アーキテクチャ）
    • コンテキストごとにエンティティの構造を提示（契約）
    • レスポンスラッパーを提示（コレクション／単一エンティティのパターン）
    • リクエストペイロードの例を提示
    • 許可される属性を文書化
    • 実装コードは含めない - それは計画書に記載します
    • バックエンドの契約とフロントエンドの型を分けて記載

• 認可アーキテクチャ（認可が必要な場合）：

  • 権限定義（コンテキストごとに分ける）
    • 内部コンテキストの権限（フルアクセスのカテゴリ）
    • 外部コンテキストの権限（限定アクセスのカテゴリ）
    • 公開 API で異なる認証方式を使用する場合は明記
  • 認可ポリシーの契約（コンテキストごとの型定義）
    • コンテキストごとにポリシーを命名：「内部ポリシー」、「外部ポリシー」
    • 公開 API：ロールベース認証ではなく、API キー認証を使用する場合があります
    • 権限を重複して記載せず、権限セクションを参照する認可に関する注記を追加

• フロントエンドアーキテクチャ（UI の作業がある場合）：

  • 型定義（フロントエンド言語の型システムを使用）
    • エンティティインターフェース（異なる場合はコンテキストごとに 1 つ）
    • レスポンスラッパーの型
    • リクエストペイロードの型（使用箇所の近くに配置）
    • コンテキスト固有の型と共有型の選択
  • コンポーネント、モジュール、ページ（コンテキストごとに整理）
    • 各コンテキストのセクションは「ファイル概要」（ルート、ページ、モジュール、型、コンポーネント）から始める
    • 続けて実装の詳細を「詳細な内訳」として記載する
    • ファイル概要は開発者向けのクイックリファレンスになります 仕様書の内容に関するガイドライン:

• 目次を含め、Markdown の標準に従って体系的なセクション番号（1.1、1.2、2.1、2.2 など）を付けます

• アーキテクチャの概要：中核となる決定事項、技術の選択、システム構造

• システムコンポーネント：使用言語に適した型定義を使って、コンポーネントの役割と契約を定義します

• データアーキテクチャ：データベーススキーマ、API 契約、イベント構造を記載します。実装ではなく、データの形状や契約を示します

• 構成アーキテクチャ：コンポーネントの設定方法（環境変数、構成ファイル）を記載します。詳細な例は不要です

• ファイル構成：コンポーネントの配置場所とその理由

• 品質特性：パフォーマンス、信頼性、保守性に関する考慮事項

• 統合パターン：既存のシステムとの接続方法

• 要件との相互参照：要件を参照するときは、要件 ID を使用します （例：「REQ-2.1.1 を実装する」「US-1.1.2 に対応する」「SC-3 を満たす」）

バックエンド API レスポンスの設計（リクエスト／レスポンス契約）:

• ✅ レスポンスの構造に焦点を当てる：レスポンスの作成方法ではなく、レスポンスの形式を示します
• ✅ ファイルアーキテクチャ：ロジックの配置場所を示すため、レスポンステンプレート／シリアライザーのファイルを列挙します
• ✅ レスポンスの例：コンテキストごとに具体例を提示します
• ✅ バックエンドのみに焦点を当てる：フロントエンドの型はバックエンドの契約と分けます
• ✅ コンテキストごとに分離する：複数のコンテキストを持つ機能では、契約を分けて示します
  • 例：内部 API のエンティティ（内部フィールドを含むすべてのデータ）
  • 例：外部 API のエンティティ（公開フィールドのみを含む限定的なデータ）
  • 例：公開 API のエンティティ（外部 API と異なる場合）
• ✅ ラッパーパターン：エンティティのラップ方法（例：data とメタデータのキー）を示します
• ✅ 標準的なパターン：個々のフィールドをすべて列挙せずに、標準的なページネーション／フィルタリングのパターンを参照します
• ❌ 実装コードは含めない：実装の詳細は計画に記載します
• ❌ 重複する例は含めない：契約を複製せず、先に示した契約を参照します

フロントエンドの型定義:

• ✅ コンテキストごとの型：データ構造が異なる場合は、コンテキストごとに型を整理します
  • 内部コンテキストでは、すべてのフィールドを含む完全なエンティティが必要な場合があります
  • 外部コンテキストでは、フィールドを限定した簡略化されたエンティティが必要な場合があります
• ✅ 共有型：すべてのコンテキストで共通する型に限り、共有型／コア型を使用します
• ✅ リクエストペイロードの型：個別の型ファイルではなく、使用するコードと同じ場所に配置します
  • フレームワークに適した命名規則に従います
• ✅ バックエンド構造との一致：フロントエンドの型は、バックエンドのレスポンスと正確に一致させます
• ✅ インポートを含める：共有型に対する適切なインポート文を示します

執筆ガイドライン:

• ✅ 簡潔にする：各概念は一度だけ説明し、繰り返しを避けます
• ✅ 契約に焦点を当てる：型定義、データベーススキーマ、API 構造を扱います
• ✅ アーキテクチャ上の決定事項を示す：実装するものとその理由（WHAT と WHY）を記載し、コーディング方法（HOW）は扱いません
• ✅ 明確な構成にする：概要 → コンポーネント → 統合の順に論理的に進めます
• ✅ バックエンドとフロントエンドを分ける：API セクションはバックエンドのみ（レスポンス構造）、フロントエンドセクションはフロントエンドのみ（型）にします
• ❌ 実装コードは含めない：詳細なコード例は記載しません（実装計画に記載します）
• ❌ 重複する例は含めない：パターンを一度示したら、繰り返し示しません
• ❌ レイヤーを分ける：API 契約とフロントエンドの型を分けます

フェーズ 4：デザインブリーフの作成（任意）

作成する場合：デザイナーとの連携が必要な UI/UX コンポーネントを含む機能。

省略する場合：

• バックエンドのみの機能
• 確立されたパターンに従うシンプルな UI 更新
• 要件にすでに十分なデザインの詳細が含まれている機能

目標：デザインに関係する情報を独立したドキュメントにまとめ、デザイナーが要件や仕様を詳しく確認しなくても済むようにします。

デザインブリーフの内容（design-brief.md）：

• ページ一覧：デザインが必要なページ／画面
• コンポーネント要件：必要なコンポーネントと表示するデータ（平易な言葉で記述し、コードは使用しない）
• インタラクションパターン：主要な操作のユーザーフロー
• フォームフィールド：フィールド、ラベル、検証ルール、ヘルプテキスト
• レスポンシブ対応に関する考慮事項：モバイルファースト、ブレークポイント、アクセシビリティ
• デザイン成果物：デザイナーから開発者に提供するもの

記述ガイドライン：

• ✅ 平易な言葉：コードや技術用語を使わない
• ✅ データ要件：「タイトル、日付、場所を表示するコンポーネント」のように記述し、実装方法には触れない
• ✅ 単独で理解できること：デザイナーが要件を参照しなくても済むようにする
• ✅ 実行可能な内容：各セクションがデザイナーの意思決定に役立つ
• ❌ 色を指定しない：ビジュアル面の選択はデザイナーに任せる
• ❌ バックエンドの詳細を含めない：ユーザーに見えるもの、ユーザーが行うことに焦点を当てる

仕様への統合：spec.md に簡潔なセクションを追加し、完全なデザインブリーフを参照するとともに、開発者向けの概要を記載します。

discussion-summary.md を更新する

仕様ドキュメントの生成後、ディスカッションの概要を更新します。

• 機能ディレクトリに discussion-summary.md が存在するか確認します
• 存在する場合：「Spec Phase」セクションを追加し、以下を記載します。
  • アーキテクチャ上の決定事項とその根拠
  • 検討・選定した技術
  • 仕様フェーズで実施した技術調査
  • 仕様に関する決定事項を追加し、Key Decisions Log の番号を継続する
  • 新たに参照したファイルを Technical Context に追加する
• 存在しない場合：前段階のプレースホルダーを含む完全な構成で作成します

参考にするコードベースのパターン

技術的な決定を行う前に、必ず既存のコードを確認してください。

バックエンドのパターン：

• API レスポンス：複数フィールドを持つエンティティの例として、既存のレスポンステンプレート／シリアライザーを確認します
• レスポンスラッパー：エンティティがどのようにラップされているか（データとメタデータのパターン）を確認します
• 検索パターン：検索機能がどのように実装されているかを確認します
• コンテキストの分離：コンテキストごとに異なるレスポンスが必要な場合の既存パターンを探します

フロントエンドのパターン：

• 型の整理：既存の型ファイルを確認し、エンティティとレスポンスの型のパターンを把握します
• データの変更：作成／更新操作に関する既存のパターンを確認します
• コンテキスト固有の型：コンテキスト固有の型と共有型を使い分けている既存の機能を確認します
• レスポンスの構造：フロントエンドの型がバックエンドのレスポンスをどのように反映しているかを確認します

認可のパターン：

• 権限の整理：コンテキストごとに権限がどのように整理されているかを確認します
• コンテキスト固有の権限：異なるコンテキストに、スコープの異なる同名の権限が存在する場合があります
• ポリシーの構造：既存の認可ポリシーのパターンを確認します
• パブリック API：パブリック API で異なる認証方式（API キーとセッション）が使われているかを確認します

実装ガイド

プロジェクトに実装ガイドがある場合は、仕様に実装コードを含めるのではなく、そのガイドを参照してください。仕様では、実装する必要がある内容（WHAT）を記載し、実装方法（HOW）については適切なガイドを参照してください。

検討すべき一般的なガイドのトピック:

• 検索機能のパターン
• ファイルのアップロードと添付のパターン
• 監査証跡／変更追跡
• マルチテナンシーのアプローチ
• ロールベースの認可
• ステートマシンのパターン
• テストのパターンと規約
• 認証戦略
• データベース移行のベストプラクティス

仕様でガイドを参照する方法（プロジェクトにガイドがある場合）:

• ✅ 「検索設定の詳細については、実装ガイドを参照してください」
• ✅ 「ファイル添付の処理には、確立されたパターンに従ってください」
• ✅ 「権限の構成については、認可ガイドを参照してください」
• ❌ 仕様に実装コードを含めない
• ❌ ガイドの内容を仕様に重複して記載しない

マルチコンテキストアーキテクチャのパターン

機能が複数のアプリケーションコンテキスト（内部、外部、公開）にまたがる場合は、以下のパターンに従ってください。

完全分離の原則:

• ハンドラー／コントローラー: コンテキストごとにリクエストハンドラーを分ける
• レスポンステンプレート: 現時点で同一であっても、コンテキストごとにレスポンス構造を分ける
• 認可: コンテキストごとに認可ポリシーを分ける。公開 API では異なる認証方式を使用する場合がある
• 権限: 適切なスコープを設定して、コンテキストごとに権限を定義する
• 型: データ構造が異なる場合は、コンテキスト固有の型を定義する
• ルート: コンテキストごとに異なるルート名前空間またはプレフィックスを使用する

完全に分離する理由:

• セキュリティ: コンテキスト間での意図しないデータ漏えいを防止します
• 柔軟性: 各コンテキストを独立して発展させられます
• 明確性: 境界を明確にすることで意図が明らかになります
• 保守性: あるコンテキストへの変更がほかのコンテキストに影響しません

一般的なコンテキストのパターン:

• 内部／管理コンテキスト: 管理用フィールドと監査フィールドを含む、完全な CRUD
• 外部／ユーザーコンテキスト: 操作を制限し、内部フィールドを除外
• 公開 API: 制限が最も厳しいことが多く、異なる認証方式（セッションではなく API キーなど）を使用する場合がある

避けるべき一般的な仕様上の落とし穴

バックエンド／API セクションの落とし穴

❌ 実装コードを示す - 構築方法ではなく、レスポンス構造を示す
❌ レイヤーを混在させる - API セクションはバックエンドのみにし、フロントエンドの型は分ける
❌ 検索を過剰に設計する - 複雑な検索を追加するのは、本当に必要な場合に限る
❌ 不要なフィールド - 監査フィールドやタイムスタンプフィールドを API レスポンスに含めるべきか検討する
❌ 標準的なパターンを詳述する - 詳細を繰り返さず、標準的なパターンを参照する
❌ パラメーターの記載場所を誤る - 許可される属性は認可レイヤーに記載する
❌ コンテキスト間で構造を再利用する - セキュリティのため、常に個別の構造を作成する
❌ コンテキストごとの認可が欠けている - すべてのコンテキストの権限を定義する
❌ 「すべての項目をソート可能」といった一般的な記載 - ソート可能な列を具体的に列挙する
❌ 認証に一貫性がない - コンテキストごとに異なる認証方式を記載する

フロントエンド／型セクションの落とし穴

❌ コンテキスト固有のデータに共有型を使う - コンテキストごとに異なる型構造が必要になることが多い
❌ リクエスト型を一元化する - 使用箇所の近くに配置する
❌ 型定義を繰り返す - API セクションとフロントエンドセクションの両方で型を重複させない
❌ インポートの不足 - 型定義には適切なインポート文が必要
❌ 未使用のインポート - 実際に使用する型のみをインポートする
❌ ファイル概要セクションがない - 各コンテキストの冒頭に、すぐに参照できる要点を記載する

仕様全般の落とし穴

❌ 実装コードが多すぎる - 仕様では契約を定義し、計画では実装を定義する
❌ 例の繰り返し - パターンは一度だけ示し、ほかの箇所では参照する
❌ アーキテクチャに関する注記がない - 分離する理由（セキュリティ、隔離）を説明する
❌ 権限を繰り返し記載する - 重複させず、「権限定義」セクションを参照する

ガイドライン

• コンテキスト優先：質問する前に、既存のコードベースのパターンと実装ガイドを必ず分析します
• 的確な質問：既存のパターンでカバーされていない独自の側面についてのみ質問します
• パターンに従う：技術的な判断は、確立されたコードベースの規約に基づいて行います
• アーキテクチャを重視：実装手順ではなく、システムの構造と契約を定義します
• 簡潔なコミュニケーション：各概念を一度だけ明確に説明し、繰り返しを避けます
• やり取りを最小限に：包括的なコンテキストを活用し、質問の往復を減らします
• 各フェーズの完了時に TODO リストを更新します
• フェーズ 1：基本的な情報収集ではなく、コンテキストを分析してスコープを確認します
• フェーズ 2：既存のパターンを使って設計し、独自の側面についてのみ質問します
• フェーズ 3：システムの契約と決定事項を示すアーキテクチャ仕様を作成します
• フェーズ 4（任意）：UI/UX が複雑な機能について、デザイナー向けの独立したドキュメントとしてデザインブリーフを作成します
• ビジネスコンテキスト：追跡可能性のためではなく、理解のためにビジョンと要件を参照します
• 実用性を重視：実証済みのパターンを用いて、すぐに構築できるソリューションを設計します
• バックエンドとフロントエンドの分離：バックエンドの契約とフロントエンドの型を分離しておきます

開始手順

1. すぐに TODO リストを作成します（3 フェーズ、デザインブリーフが必要な場合は 4 フェーズ）
2. ユーザーに質問します：「作業対象の機能ディレクトリはどこですか？フルパスを指定してください（例：project/features/FT033-feature-name）」
3. ユーザーに質問します：「ビジョンドキュメントに @vision.md、要件ドキュメントに @requirements.md のタグを付けてください」
4. ディレクトリが存在することを確認し、spec.md の作成場所を確認します
5. ビジョンドキュメントと要件ドキュメントを確認し、機能のコンテキストを把握します
6. 最初の技術的な確認質問をして、フェーズ 1 を開始します
7. 質問は焦点を絞り、次の質問に進む前に回答を待ちます