はじめに
KiroのSpec開発では下記のように順にLLMが仕様設計を進めていきます。
1. 要件定義（requirements）
2. 設計（design）
3. 実装タスク化（tasks）
こうしてKiroによる新規プロジェクトを作成する際に、個人的に見逃しやすい観点をこちらにまとめつつ、よく使う修正プロンプト群として記載していきたいと思います。
1. 達成したいことを具体的に
LLMはゴールを明確に示すことで、そこまでの過程のベストプラクティスを選びやすくなります。
1. 商品分析を少ない手順で簡単に行えるようにしたい
2. 対応デバイス、ディスプレイ、OSを具体的に
レスポンシブ対応がされていなかったり、
Safari非対応のCSSを記載してしまうなど、そういったことが指定することで減ります。
1. モバイルファーストかつ、レスポンシブにしてください
2. Chrome, Safari両方に対応させてください
3. 収益・ビジネスモデル（キャッシュポイントの策定）
エンジニアとしては忘れがちですが、PMとしては押さえておかないといけないポイントです。
1. APIリクエストによるトークン消費数ごとにStripeによる従量課金にしてください
2. 有料のバナー広告枠を販売することができるようにしてください
4. 運用時に必要なSLA・サポート体制、運用フロー
こちらはKiroにはほとんどない視点です。
プロジェクトマネジメント上必要だと思われることも記載していきましょう。
1. 耐障害性を考慮してください
2. SLA定義書を作成してください
3. 障害時の報告フローをmermaidにて作成してください
5. 法規制・セキュリティ・プライバシー対応
商取引法に基づく表記ページやプライバシーポリシー、Pricingのページなども見逃されやすいため記載しましょう。
1. LPにて景品表示法の違反がないようにしてください
2. プライバシーポリシーのページを作成してください
1. 具体的な画面構成
画面構成の比率などを伝えないと、意図しない画面になる可能性が高くなります。
デザインのイメージなどがある場合はなるべく詳細に伝えておきましょう。
1. 画面左側（30%）はサイドバー、残り右側（70%）はメニューごとのコンテンツ表示としてください
2. ログ設計
こちらも非常に忘れやすいです。
目的に応じてSlackなどへの通知も追加すると良いです。
1. あとからエラー時の解析がしやすいようにログ設計を追加してください
1. ログのカラー設定や集計しやすいようにカスタムフォーマットを適用してください
3. アナリティクス設計
ログ設計と似ていますが、アナリティクスプラットフォームによって異なるため、
どのアナリティクスを使用するのかも記載しましょう。
1. Google Analytics 4 によるアクセス解析を可能にしてください
4. 具体的なキャッシュ戦略やパフォーマンス要件
エンジニアが忘れがちなポイントになります。
どのようなビジネスモデルでキャッシュポイントはどこなのか、設定するとよりLLMが設定に合う構成で設計しやすくなります。
1. Stripe Connectを使用して手数料をプラットフォーム側で取りつつ、コンテンツ配信者へ収益を分配するようにしてください
2. レコメンドエンジンは精度とともにパフォーマンスも重視して設計してください
5. SEO、GEO、LLMO、OGP設定
時々、sitemapを作成してください。だけだと、ビルド時にSitemap自動生成を組んでしまったり、Admin画面をインデックスしてしまったりするので注意です。
1. 一般的なSEO対策を行なってください
2. 各ページにOGPを設定してください。共通化できる場所は共通化してください。
2. sitemapを作成してください
6. 可用性・障害復旧・SLA準拠
こちらは運用フロー、保守などについても策定できると良しです。
1. SLAをドキュメントとして作成してください
7. 具体的な採用技術・ライブラリ
意外とこちらも記載が必要になってきます。
Webフレームワークや使用するライブラリはなるべく詳細に記載することで、その後の実装時にブレが少なく済みます。
1. Next.js, TailwindCSS, Typescriptの構成で作成してください
2. DBへの接続はDrizzleで行い、DBはPostgreSQLにしてください
8. 環境ごとの設定について
ローカル環境、開発環境、ステージング環境、本番環境など環境ごとの差分も見逃されがちです。
必要な場合はKiroの設計に組み込みましょう。
1. ローカル環境、開発環境、ステージング環境、本番環境ごとにDBの接続先を切り替えられるようにしてください
9. 複雑な仕様やプロジェクト構成についての追記
例えば、『CloudRun上でBasic認証をかけたいけれども、ログイン認証にユーザーも管理者もいてそれぞれ別認証かつ同じNextAuthで定義する』という複雑な仕様の場合LLMが混乱します。
そういった混乱しやすい仕様やプロジェクト構成についても、あらかじめ渡しておきましょう。
1. ユーザーと管理者のログイン認証にはNextAuthを使用しますが、Basic認証については.httaccessで対応します。
2. DB定義は/db/drizzle.config.tsに記載しています。ルートディレクトリにあるdrizzle.config.tsではありません。
10. 運用・保守のコスト
こちらも非常に見逃されがちです。
特にベンダーロックやライブラリのメンテナンス性において問題が起きがちです。
1. 記載していないインフラ構成やライブラリ選定において運用・保守コストが高くなる可能性のあるものを選択しないようにしてください
2. 指定していない使用ライブラリについては、なるべくメジャーかつメンテナンスが頻繁に行われているものを使用してください
1. ドキュメント作成
指定しないとDB設計書やOpenAPIドキュメントが作られないことが多いです
1. DB設計書、API設計書、I/F定義書をそれぞれに適したフォーマットで作成してください
2. CI/CD、デプロイのためのスクリプト
DockerfileやmakefileなどCI/CD周りは用意してくれないことが多いため、指示が必要です
1. CloudRunにデプロイするためのDockerfileを作成してください
2. 環境構築のためのTerraformを作成してください
3. 難しいタスクについての詳細化
たまに大きなタスクが１項目として記載されてしまい、LLMによる実装が難しくなる場合があるため、タスクのブレークダウンが必要な場合があります。
1. 〜のタスクは実装範囲が大きいため、細かいタスクにブレークダウンして記載してください
まとめ
Kiroを使って仕様を作成するときには、いろいろやってくれてしまうため、
意外とサービスを始める時には重要な点が入っていないまま気が付かず設計フェーズを終えてしまいます。
そのため上記のリストを参考に、Kiroに追加のプロンプトを指示して網羅的に設計できるようにしていただけたら幸いです。
もしKiroでこのプロンプトもおすすめだよ！というものがあればぜひ教えてください。