この記事は 食べログアドベントカレンダー2025 の9日目の記事です🎅🎄
1. はじめに
こんにちは。飲食店プロダクト開発部アワード予約チームに所属している @aaknsk です。
カカクコムでは、AIモデルを搭載したコードエディタ「Cursor」を全社的に導入しています。
この記事では、音声入力とCursorを組み合わせることで、設計を効率化する方法について紹介します。
音声入力で思考プロセスそのものを記録し、タイピングをほとんど行わずに設計と設計資料を作成する方法について実際のプロンプト例も交えながら、すぐに実践できるようお伝えしていきます。
2. 音声入力を使おうと思ったきっかけ
資料作成が全然追いつかない...。
複数のチームが関与する案件では、要件定義〜設計の間に多くの関係者と調整をする必要があり、頻繁に打ち合わせを行う必要がありました。
早く資料を完成させて仕様や設計を固めていきたいのですが、なかなか追いつきません。打ち合わせ、設計、打ち合わせ、割り込みのコードレビュー、設計、次の会議…と、合間の30分や1時間で仕様や設計を考え、資料にまとめていました。
その中で特に困っていたのが、打ち合わせや割り込み対応から戻ってきた時に、頭の中だけで考えていたことを忘れてしまうことでした。「あれ、どこまで考えてたっけ？」「なんでこの方向で考えてたんだっけ？」と思い出すことから再開することもあり、効率がとても悪くなっていました。
この非効率さを防ぐためにタイピングして記録を残すようにしましたが、記録を残す作業自体も面倒で、もっと考えることに時間を使いたいのになと思っていました。
また、生成AIツールを利用してできることはどんどん効率化もしているのですが、プロンプト作成作業自体も手間に感じていました。何度も似たような情報や指示を入力したり、プロンプトを調整したりすることも積み上がれば結構な時間を使っています。
もっと早く情報を入力できないかな...と考えていたときに、Cursorに音声入力のアイコンがあることを発見しました。文字をタイピングするよりも、音声で入力できた方が楽になるのではと思い、試してみることにしました。
3. 音声入力を利用するメリット
メリット①：タイピングよりも素早く情報を入力できる
（個人差はあると思いますが）私の体感的には、音声入力を利用するとタイピングより2倍程度早く入力できていると感じます。
例えば1回のプロンプト作成にタイピングで5分程度かかるとします。1日10回プロンプトを作成すれば約50分です。音声入力を利用すれば半分の約25分になり、1日25分・1週間で125分の節約ができます。
タイピングで高速に入力しようとすると意識的な操作が必要ですが、音声入力の場合はただ話すだけでいいので、特に何かを意識的にする必要もなく楽に素早く情報を入力できます。
メリット②：考えているプロセスごと記録できる上に、その情報を利用して即資料化・タスク化できる
この点が音声入力を利用する最大のメリットだと考えています。
何かを考える時に最初から音声入力をONにして、考えていることを全部声に出して記録していきます。そうすると、一通り考える作業が終わった時点で全ての情報が入力完了しています。割り込み対応が終わってからすぐに再開できるよう、記録したり資料にまとめ直す必要がありません。
また、入力した情報に対して要約作成・TODO作成・図にするなど、情報を加工するプロンプトを即実行できます。
面倒な作業を省略し、考えることに集中して時間を利用できるようになります。
4. 音声入力 + Cursor を利用した設計のやり方
ここからは、音声入力 + Cursor でどのように設計を進めているかを紹介します。
最終的に出来上がるもの
・指定したフォーマットで情報をまとめた設計書
要件定義、仕様、システム構成図、APIのIFやDBのテーブル定義などが整理されたMarkdownファイルが出来上がります。
事前に準備するもの
1.案件情報: 概要・目的・要件など、現時点で揃っている情報でOK。
2.設計書のフォーマット: 設計者が作りたいドキュメントの構成案。図も含める。
3.プロンプト:
A: 設計書作成: 音声入力した内容を 2.設計書のフォーマット 形式でまとめる。
B: 調査計画生成: タスク内容を元に具体的な調査計画を立てる。
C: 他の観点がないか指摘: 設計者・Cursorが出した設計に対して他に考えるべき観点はないかコメントしてもらう。
2.設計書のフォーマットには、テキスト情報とMermaid形式の図を含めます。図を一緒に作成することで、文字を読まずにどんな構成で考えていたかをパッと思い出しやすくなります。また、他の人に相談するときにも図があれば情報のインプットがスムーズになります。
プロンプトを何度もコピペして入力することが手間なので、 3.プロンプト をCursorのコマンドに登録しておきます。各プロンプト内容とコマンド名を紹介します。
▼プロンプトA: 設計書作成（make_summary コマンドとして登録）
## 依頼 - 今音声入力した内容を使って設計をしたいので、以下の形式でまとめてください。 - `summary.md` というファイル名のファイルを作成し、このまとめた内容を記入してください。 - `音声入力した内容のまとめ`部分を充実させ、`設計書として残す部分`部分には決まったことを記入してください。 ---- ## 設計書として残す部分 ### 要件・仕様 ### システム設計 システム全体の構成図を記入する APIの開発があれば、`APIのIF`セクションを追加。以下の要素を記入 - URL - リクエストパラメータ - レスポンスパラメータ ## 音声入力した内容のまとめ ### サマリ 簡潔な文章で、要点をまとめてください。 ### タスク TODOとして上がった点をカテゴリ毎に分類し、記載してください。 - カテゴリ - [ ] task A(いつまでに、誰に、何を) ### 未確定事項・不明点 未確定な内容や、これから詳細を詰める必要がある情報はこちらにまとめてください。 ### 情報の詳細 話した内容を分類し、見出しと詳細の内容を記載してください。 見出しは**太文字**でOKです ### 図の作成 音声入力した内容をもとに、システム構成図やフローチャートをMermaid記法で作成してください。 あなたが一番理解しやすい形を提案し、その形でまとめてください。
▼プロンプトB: 調査計画生成（make_search_plan コマンドとして登録）
選択した範囲のタスク/メモについて、調査用のプロンプトを作成してください。 ## 実行内容 1. **内容の整理** - 選択範囲から実際のタスクや課題を抽出 - 曖昧な表現や音声入力の誤変換を補正 - タスクの目的や背景を推測 2. **調査プロンプトの生成** - このタスクを調査するための具体的なプロンプトを作成 - 調査すべきポイント(ファイル、コード、仕様等)を明記 - 調査の優先順位や範囲を指定 ## 出力形式 ### タスク概要 [抽出・整理されたタスク内容] ### 生成された調査プロンプト
▼プロンプトC: 他の観点がないか指摘（check_other_point コマンドとして登録）
今整理されている情報に対して、ソフトウェアの設計上、他に考えるべき観点はありませんか？ 幅広い観点から考え、フィードバックをして欲しいです。
設計の進め方
大きく3つのステップで進めていきます。
STEP 1：設計書の叩き台を作成する
設計者が現時点で思いつく設計を完了させるために必要な材料を出し、Cursorに設計書の叩き台を作成してもらいます。サービス・システムの仕様について今わかっていること・これから考える必要があること、今時点のシステム構成案を記入したら、次のステップに進みます。
大きく二つの作業を行います。
- 設計の素案作成:
- 音声入力を開始し 1.案件情報 の読み上げと設計のアイデアや懸念点、タスクをつぶやく。
- 音声入力したテキストに対して プロンプトA: 設計書作成プロンプト（make_summary コマンド）を実行する
- Cursorにツッコミさせて素案を修正:
- 作成された設計書に対し プロンプトC: 他の観点がないか指摘（check_other_point コマンド）を実行し、設計者が気づいていない観点を出す。
- 音声入力を開始し、追加で何を考える必要があるかをつぶやき、Cursorに設計書を更新させる。
STEP 2：設計をブラッシュアップする
ここでは二つの作業を組み合わせて、設計をブラッシュアップします。設計が終わるまで作業を繰り返します。設計資料の調整は最後にまとめて行います。
- 設計者が考えたことを音声入力し、Cursorで設計書を更新する
- 決まった仕様・システム構成、追加タスクなどをつぶやき、Cursorに設計書を更新させる。
- Cursorに調査計画の作成・調査を行わせ、判断に必要な情報を集める
- 設計書内のタスクを元に プロンプトB: 調査計画生成（make_search_plan コマンド）を実行する。
- 調査結果に対して考えたことを音声入力で指示し、追加調査・設計書への追記・図解化などを行う。
適宜、プロンプトC: 他の観点がないか指摘（check_other_point コマンド）を実行して設計者が考えた内容・Cursorが生成した調査結果に対してツッコミを行い、見落としている観点がないか確認します。
STEP 3：設計書の仕上げ
Cursorで設計書を更新していくと、不要な部分が追加されること、伝わりにくい表現が含まれていることがあります。そのため最後に設計資料を手動もしくはCursorに指示を出して調整し、資料を完成させます。
5. 実際に試してみた
ここからはサンプル案件を例に音声入力を使った設計を試してみます。
サンプル案件：
食べログノートの分析機能開発。予約が入ってから来店するまでの日数（リードタイム）を分析できるようにする。リードタイム = 予約の来店日 - 予約の作成日。ユーザーが予約してから来店までの期間のこと
※食べログノートの分析機能については、以前「生成AIを使ったらAPIの開発が捗った話」という記事で紹介しています。詳しくはこちらをご覧ください。
STEP 1：設計書の叩き台を作成する
設計の素案作成
まずは音声入力を開始し案件情報の読み上げと設計で考えたことをつぶやきます。
▼音声入力した内容
これから音声入力を始めていきます 開発するのは食べログノートの分析機能です リードタイムの分析ができるようにしたいです リードタイムは 予約が入ってから来店するまでの日数です リードタイム = 予約の来店日-予約の作成日 です 仕様で気になるのが 1月分を出しますが 最長 何年分くらいまで出せるようにしたいか 各月で集計をする形で問題ないか あと リードタイムは 1ヶ月以上先となった場合 細かく見たいかどうか 気になりました 1から10日間くらいの間は それぞれ出してもいいと思います 30日以上の場合例えば 20日から25日までと 日数が伸びた時に ある程度の範囲を持たせてこのくらいの間のリードタイムと集計した方が見やすくなるかと思いました どれくらい細かく リードタイムを出す必要があるかが気になりました 今回の対応は 分析用のAPIを一つ 追加が必要です すでに 集計しているデータを使えば 新規でデータ作成する必要はなく 分析できる のでデータベースに変更は不要です 既存のテーブル 分析… サマリーテーブル使えば 大丈夫で リアルタイムで計算する場合は予約のデータの 作成日と来店日をもとに算出ができる URLの名前は既存の分析の命名 を元に考えたら良さそうであと 分析結果を出力することとCSVで出力することも必要になりそうです
この入力値に対して プロンプトA: 設計書作成プロンプト（make_summary コマンド） を実行します。
▼プロンプトA: 設計書作成プロンプト（make_summary コマンド） を実行後のチャット
指定したフォーマットで設計書の素案が作成されました。
Cursorにツッコミさせて素案を修正
作成された設計書に対し プロンプトC: 他の観点がないか指摘（check_other_point コマンド） を実行し、現時点で設計者が言及していない観点がないか確認します。
▼プロンプトC: 他の観点がないか指摘（check_other_point コマンド） 実行後に出力された内容
現在の設計内容を確認して、幅広い観点から追加で考慮すべき点をフィードバックしますね！😊 ## 📋 追加で考慮すべき設計観点 ### 1️⃣ **パフォーマンス・スケーラビリティ** 🚀 #### 考慮すべき点 - **大量データの取り扱い** - 数年分のデータを取得する場合のクエリパフォーマンス - ページネーションの必要性（一度に全期間のデータを返すのか、分割するのか） - インデックスの設計（予約作成日、来店日にインデックスは張られているか） - **レスポンスタイムの目標値** - APIのタイムアウト設定（例：30秒以内） - 重い処理の場合、非同期処理やバックグラウンドジョブの検討 - **キャッシュ戦略** - 集計結果のキャッシュ（Redis、Memcached等） - キャッシュの有効期限設定 - リアルタイム性とパフォーマンスのトレードオフ ### 2️⃣ **セキュリティ・認証認可** 🔐 #### 考慮すべき点 - **認証・認可** - 店舗オーナーが自店舗のデータのみアクセス可能にする制御 - 管理者権限での全店舗データアクセス - APIトークンやセッション管理 - **データアクセス制御** - 複数店舗を持つオーナーの場合の店舗切り替え - 権限レベルに応じたデータフィルタリング - **APIのレート制限** - 過度なリクエストを防ぐための制限 - DDoS対策 ### 3️⃣ **エラーハンドリング・バリデーション** ⚠️ #### 考慮すべき点 - **入力値のバリデーション** - 日付の妥当性チェック（start_date ≤ end_date） - 期間の上限制限（例：最大5年まで） - 不正なformatパラメータの処理 - **エラーレスポンスの設計** - **例外ケースの処理** - データが存在しない期間のリクエスト - システムエラー時のフォールバック ### 4️⃣ **データ整合性・ビジネスロジック** 📊 #### 考慮すべき点 - **予約ステータスの扱い** - キャンセルされた予約をリードタイムに含めるか？ - ノーショー（来店なし）の扱い - 予約変更があった場合の計算方法（最初の作成日 vs 最終更新日） - **日付境界の扱い** - タイムゾーンの考慮（JST固定？UTC？） - 0日（当日予約）の扱い - 負の値（来店日より後に予約データが作成される異常データ）の扱い - **データの欠損** - 作成日や来店日がNULLの場合の処理 - 過去データの移行で情報が不完全な場合 ### 5️⃣ **運用・監視・ロギング** 📈 ....この記述が 🔟 まで続く ## 📝 次のアクションアイテム これらの観点を踏まえて、以下を追加で整理することをおすすめします： 1. **非機能要件の明確化**（パフォーマンス目標、セキュリティ要件等） 2. **エラー仕様書の作成**（エラーコード一覧、エラーメッセージ） 3. **テスト計画書の作成**（テストケース、テストデータ） 4. **運用設計書の作成**（監視項目、アラート設定） いかがでしょうか？これらの観点で追加で検討したい項目があれば、一緒に深掘りしていきましょう！✨😊
全部で10個出力された観点のうち、1️⃣パフォーマンス・スケーラビリティ、4️⃣データ整合性・ビジネスロジックを考えていきたいので、設計書の一番下に記入するようCursorに指示を出します。
▼音声入力した内容
▼設計書の更新指示を実行した後のチャット
期待通り設計書が更新されたことを確認しました。設計書の中に不要な情報も含まれているので、一度整理しておきます。不要な図・仮置きのAPIのIF・見なくていい観点を手動で削除しました。
▼ここまでの作業で生成された設計書の叩き台（summary.md ファイル）
# 食べログ リードタイム分析機能 - 設計まとめ ## 設計書として残す部分 ### 要件・仕様 **開発対象** - 食べログノートに新しく追加するリードタイム分析機能 **リードタイムの定義** - リードタイム（日数） = 予約の来店日 - 予約の作成日 - 予約が入ってから来店するまでの日数を表す指標 **集計方法** - 月次単位での集計を実施 - 既存の分析サマリーテーブルを活用 - リアルタイム計算も可能（予約データの作成日と来店日から算出） **CSV出力** - 分析結果をCSV形式でエクスポート可能 ### システム設計 **システム全体の構成図** <!-- Mermaid形式の記述が長いので画像を添付します --> ## 音声入力した内容のまとめ ### サマリ 食べログノートに新しくリードタイム分析機能を開発する。リードタイムとは「予約作成日から来店日までの日数」を指し、月次単位で集計する。 既存の分析サマリーテーブルを活用することでデータベース変更なしに実装可能。新規APIを1つ追加し、CSV出力機能も実装する。 リードタイムの表示粒度については、短期（1〜10日）は日単位、中長期は範囲でのグルーピングを提案。最大何年分のデータを表示するかなど、いくつかの仕様詳細は今後確定する必要がある。 ### タスク #### 仕様確認 - [ ] リードタイム集計の粒度をステークホルダーに確認する（いつまでに：実装開始前、誰に：PO/企画担当者、何を：1〜10日は日単位、それ以降の範囲の決定） - [ ] データ保持期間を確認する（いつまでに：実装開始前、誰に：PO/企画担当者、何を：月次集計で最長何年分まで表示可能にするか） - [ ] 月次集計で問題ないか確認する（いつまでに：実装開始前、誰に：PO/企画担当者、何を：週次や日次での分析ニーズの有無） #### 開発準備 - [ ] 既存の分析APIの命名規則を調査する（いつまでに：API設計前、誰が：開発者、何を：新規APIのURL設計の参考にする） - [ ] 既存の分析サマリーテーブルの詳細を確認する（いつまでに：実装開始前、誰が：開発者、何を：使用可能なテーブル名とカラム構成） #### 実装タスク - [ ] リードタイム分析用APIの設計と実装（いつまでに：開発スプリント内、誰が：開発者、何を：API実装） - [ ] CSV出力機能の実装（いつまでに：開発スプリント内、誰が：開発者、何を：CSV出力機能） ### 未確定事項・不明点 **データ表示期間** - 月次集計で最長何年分まで遡って表示できるようにするか？ - システム負荷やデータ量を考慮した適切な期間の決定が必要 **リードタイムの集計粒度** - 短期（1〜10日程度）：1日単位での集計で良いか？ - 中期（11〜30日程度）：どのような範囲での集計が見やすいか？（例：5日刻み、10日刻みなど） - 長期（30日以上）：範囲を持たせた集計が必要か？どのような区切りが適切か？ - ユースケースに応じた最適な粒度の検討が必要 **集計単位** - 月次集計で問題ないか？ - より細かい単位（週次、日次）での分析ニーズはあるか？ **集計方法の詳細** - 月毎の集計で問題ないか？（核付き集計の意味の明確化が必要） **実装スコープ** - 分析用APIを1つ追加 - 既存の分析機能の命名規則に従ったURL設計 - CSV出力機能の実装 - フロントエンドでの表示（詳細は別途検討） **CSV出力の必要性** - 分析結果をExcelなどで二次利用できるようにする - 店舗オーナーが独自に加工・分析できるようにする ### 🔍 ソフトウェア設計上の追加検討ポイント #### **パフォーマンス・スケーラビリティ** 🚀 ##### 考慮すべき点 - **大量データの取り扱い** - 数年分のデータを取得する場合のクエリパフォーマンス - ページネーションの必要性（一度に全期間のデータを返すのか、分割するのか） - インデックスの設計（予約作成日、来店日にインデックスは張られているか） - **レスポンスタイムの目標値** - APIのタイムアウト設定（例：30秒以内） - 重い処理の場合、非同期処理やバックグラウンドジョブの検討 - **キャッシュ戦略** - 集計結果のキャッシュ（Redis、Memcached等） - キャッシュの有効期限設定 - リアルタイム性とパフォーマンスのトレードオフ #### **データ整合性・ビジネスロジック** 📊 ##### 考慮すべき点 - **予約ステータスの扱い** - キャンセルされた予約をリードタイムに含めるか？ - ノーショー（来店なし）の扱い - 予約変更があった場合の計算方法（最初の作成日 vs 最終更新日） - **日付境界の扱い** - タイムゾーンの考慮（JST固定？UTC？） - 0日（当日予約）の扱い - 負の値（来店日より後に予約データが作成される異常データ）の扱い - **データの欠損** - 作成日や来店日がNULLの場合の処理 - 過去データの移行で情報が不完全な場合
▼設計書の叩き台に記載されていた図（summary.md ファイル）
私が入力した情報に対して意図していない記述もなく、フォーマットからもずれていないので体裁はOKと判断しました。今ある情報とタスクの整理が終わったので、次に進みます。これで割り込み対応があってもすぐに再開できる状態になりました。
STEP 2：設計内容をブラッシュアップする
設計者が考えたことを音声入力し、Cursorで設計書を更新する
仕様を調整して確定させたので、音声入力で設計書を更新するように指示を出します。
▼音声入力した内容
▼設計書の更新指示を実行した後のチャット
Cursorによって設計書の内容が更新されました。記述に対して違和感はなかったのでこのまま進めます。
Cursorに調査計画の作成・調査を行わせ、判断に必要な情報を集める
生成した設計書（summary.md ファイル）の中から、調査したい部分を選択してチャットに追加し、調査計画生成プロンプト（make_search_plan コマンド）を実行します。
※選択した箇所 - [ ] 既存の分析APIの命名規則を調査する（いつまでに：API設計前、誰が：開発者、何を：新規APIのURL設計の参考にする）
▼生成された調査計画(※サンプル値に差し替えています)
## 目的 リードタイム分析APIを新規追加するにあたり、既存の分析APIの命名規則を調査し、一貫性のあるURL設計を行う。 ## 調査内容 ### 1. 既存の分析APIエンドポイント一覧の取得 **調査対象** - app/controllers/api/v1/analytics 配下のコントローラー - 分析系のエンドポイントを定義しているルーティング設定 **確認事項** - [ ] 既存の分析APIのURL一覧を抽出 - [ ] 各APIの機能概要を把握 - [ ] 月次分析系と単月分析系の命名パターンの違いを確認 ### 2. URL命名規則の分析 **確認ポイント** - ベースパス（例：/api/v1/） - 動詞の使用パターン（get, fetch, retrieve等） - リソース名の命名規則 - 単数形 or 複数形 - スネークケース or キャメルケース - 月次集計系APIの命名パターン - 例：〜_by_month のような接尾辞の有無 - 期間指定系のパターン ### 3. リクエストパラメータの命名規則 **確認ポイント** - 期間指定のパラメータ名 - yearMonth, year_month, from, to等 - 単月指定と範囲指定の使い分け - その他共通パラメータの命名 ## 調査手順 1. ルーティング定義ファイルを確認 2. 既存のコントローラーを確認 - app/controllers/api/v1/analytics/ 配下 - 分析系のコントローラークラス 3. 既存のサービス層を確認（あれば） 4. パターンの抽出と整理 - URL一覧表の作成 - 命名規則の共通パターンの抽出 - リードタイム分析APIへの適用案の作成 ## 期待する成果物 **1. 既存分析API一覧表** | URL | HTTPメソッド | 機能概要 | 主要パラメータ | |-----|-------------|---------|--------------| | /api/v1/analytics/cancellation_rate_by_month | GET | キャンセル率分析 | yearMonthFrom, yearMonthTo | | /api/v1/analytics/booking_summary | GET | 予約サマリー | yearMonth | | ... | ... | ... | ... | **2. 命名規則のまとめドキュメント** - URL構造のパターン - パラメータ命名規則 - レスポンス形式の標準 **3. リードタイム分析APIのURL設計案（理由付き）**
調査計画の調査手順・期待する成果物を見て、この内容で欲しい情報は十分と判断しました。音声入力で調査を進めて欲しいと指示を出し、調査を実行していきます。
▼調査して出力された結果(※サンプル値に差し替えています)
# 既存の分析API命名規則 - 調査結果
## 1. 既存分析API一覧表
調査の結果、以下の分析系APIが既に実装されていることが確認できました。
| URL | 主要パラメータ |
|-----|--------------|
| GET `/api/v1/analytics/cancellation_rate_by_month` | yearMonthFrom, yearMonthTo |
| GET `/api/v1/analytics/repeat_rate_by_month` | yearMonthFrom, yearMonthTo |
| GET `/api/v1/analytics/booking_channel_summary` | yearMonth |
| GET `/api/v1/analytics/dashboard` | yearMonth |
## 2. URL命名規則の分析
### ベースパス
GET /api/v1/analytics/{エンドポイント名}
### 命名規則の特徴
1. **リソース名**
- スネークケース (`snake_case`) を使用
- 例: `repeat_rate`, `booking_channel`
2. **接尾辞の使い分け**
- 月次範囲: `_by_month`
## 3. リクエストパラメータの命名規則
### 単月分析のパラメータ
GET /api/v1/analytics/get_analysis?yearMonth=2024-01
**特徴:**
- キャメルケース (`camelCase`)
- YYYY-MM形式の文字列
- クエリパラメータとして送信
### 月次範囲分析のパラメータ
GET /api/v1/analytics/get_cancellation_rate_by_month?yearMonthFrom=2024-01&yearMonthTo=2024-12
**特徴:**
- キャメルケース (`camelCase`)
- YYYY-MM形式の文字列
- `From` / `To` の接尾辞で範囲を表現
- クエリパラメータとして送信
## 4. リードタイム分析APIへの適用
### 推奨URL設計
調査結果を踏まえ、以下のURL設計を推奨します：
GET /api/v1/analytics/lead_time_by_month
### 推奨理由
1. **既存パターンとの一貫性**
- 月次範囲分析として `_by_month` 接尾辞を使用
- 他の月次範囲分析API（キャンセル率、予約流入元など）と統一
2. **拡張性**
- 将来的に単月版が必要になった場合
- `get_lead_time_analysis` として追加可能
既存URLの命名規則に沿った形で今回追加するAPIのURL名が提案されていました。命名に違和感はなく、この形でOKと判断したので、設計資料を更新するよう指示を出します。また、レスポンス形式についても提案して欲しいと依頼します。
▼音声入力した内容
▼設計書の更新とレスポンスのアイディア出しを依頼した後のチャット
設計書の更新とレスポンスのアイディア出しを依頼した結果に対しても音声入力をONにしてCursorに指示を出します。設計を進める中で考えたこと・決めたことを音声入力し、Cursorに作業指示を出すことを繰り返し、設計を終わらせます。
そして最後に、STEP 3 で設計資料から余分な部分を削除・表現の調整を行うことで設計書を完成させます。
このように進めることで、打ち合わせやコードレビューなど割り込み対応の合間30分や1時間といった短い時間を考えることに最大限利用でき、設計を効率的に進めることができます。
6. おわりに
この記事では、音声入力とCursorを組み合わせることで、設計を効率的に進める方法について紹介しました。
音声入力を活用することで、考えることに集中し、面倒な作業を省略することで効率的に設計を進めることができます。
今回のお試し時には出ませんでしたが、具体的なクラス名やデータベースのテーブル名を音声入力すると誤字が多くなる傾向があり、うまく指示が通らないこともあります。辞書化やコンテキストの指定をして改善できないか、今後試してみようと思います。
明日は @ikeddd さんの「AIを「メンター」にしたQAチームの変革：セルフレビューの質を劇的に向上させたContext Engineering」です。お楽しみに！
食べログでは、20年の歴史を未来へ繋いでいく仲間を募集しています！
ご興味のある方は、ぜひこちらもチェックしてみてください。
