Q Developer CLIでシステム開発してみて分かった
プロンプトエンジニアリングのコツ
プロンプトエンジニアリングのコツ
こんにちは!クラウド活用推進担当の安田です。
最近、Amazon Q Developer CLIを使ってAWS料金管理システムを開発しました。
今回は、実際の開発で失敗を重ねながら学んだ「AIとの上手な付き合い方」を、具体例とともにお伝えします。
複数のAWSアカウントの料金を一元管理して、Excel形式でレポート出力するWebアプリケーションを開発しました。
・フロントエンド: HTML/CSS/JavaScript + Amplify
・API: API Gateway + Lambda
・データ処理: Athena + S3
・状態管理: DynamoDB
指示: 「Lambdaの処理がタイムアウトしてしまうので、非同期処理を追加してください。」
AIが機能を追加したが、検討し忘れている部分があり、「××も実装してください」という追加修正が必要になった。
実装前に不明点があれば質問してもらうよう指示を追加:
「実装のまえに、不明点があれば質問してください。」
Q Developerが以下の質問をしてきた:
→ Q Developerに質問させることで、考慮すべき点が明確に!
指示: 「以下のエラーコードが出ました。該当箇所を修正してください。」
AI応答: 「○○が原因です。修正しますか?」
私の返答: 「はい。修正してください。」
新たなエラーで動かない状況になってしまった。
・エラーの詳細情報が不足
・システム全体の状況が伝わっていない
・修正の影響範囲が考慮されていない
詳細なエラーコンテキストと影響分析を要求:
「該当箇所を修正して他部分に影響が無いか、入念にチェックしてください。」
Q Developerが以下の対応をしてくれた:
→ 詳細なコンテキスト提供により、影響範囲を考慮した適切な修正が実現!
上記の失敗談を含め、6週間の開発を通して得たプロンプトエンジニアリングのコツを4つ紹介します。これらは実際の失敗経験から学んだ実践的な手法です。
「Lambdaの処理がタイムアウトしてしまうので、非同期処理を追加してください。」
「Lambdaの処理がタイムアウトしてしまうので、非同期処理を追加してください。
実装のまえに、不明点があれば質問してください。」
・AIに質問を促すことで、考慮すべき点を明確化
・実装前の要件確認により、後戻りを防止
・対話的なアプローチで品質向上
結果の違い:
失敗時:「いきなり実装→後から大幅修正」
改善後:「事前質問→一発で適切な実装」
「以下のエラーコードが出ました。該当箇所を修正してください。」
「以下のエラーが発生しています:
[具体的なエラーメッセージ]
発生状況:
- 処理:CURデータの集計処理中
- タイミング:Lambda実行開始から約12分後
- 影響範囲:全アカウントの料金データ取得が停止
該当箇所を修正して他部分に影響が無いか、入念にチェックしてください。」
・エラーメッセージを具体的に記載
・発生状況を詳細に説明
・影響範囲の確認を明示的に要求
・修正時の注意点を指示
結果の違い:
失敗時:「表面的な修正→別の箇所でエラー」
改善後:「根本原因特定→安全で確実な修正」
「ログイン機能を作って」
「Lambda@Edgeでユーザー名・パスワード認証を実装してください。
必要な機能:
- ユーザー認証(ユーザー名・パスワード)
- セッション管理(24時間有効)
- エラーハンドリング(認証失敗、セッション切れ)
- ログ出力(認証成功・失敗の記録)
- セキュリティ対策(ブルートフォース攻撃対策)
技術要件:
- Lambda@Edge関数として実装
- DynamoDBでユーザー情報管理
- CloudWatchでログ管理」
・実装技術を明確に指定
・必要な機能を網羅的にリスト化
・技術要件を詳細に記述
・セキュリティ要件も含める
結果の違い:
失敗時:「曖昧な指示→想定と違う成果物」
改善後:「具体的な要件指定→期待通りの完璧な実装」
テスト用の一時ファイルが大量に作られ、プロジェクト構造が混乱
「開発・テスト用の一時ファイルを作成する場合は、
/tmpディレクトリを使用し、作業完了後に自動削除してください。
本番コードのみをプロジェクトルートに配置してください。
ファイル管理ルール:
- 本番コード:プロジェクトルート
- テストファイル:/tmp/test/
- 一時ファイル:/tmp/temp/
- 作業完了後:一時ファイルの自動削除」
・ファイル配置ルールを明確化
・一時ファイルの自動削除を指示
・プロジェクト構造の整合性を保持
結果の違い:
失敗時:「修正を繰り返す→ファイルが増えてディレクトリがごちゃごちゃ」
改善後:「ファイル管理ルール設定→常に整理された構造を維持」
実際の開発で学んだコツが、Anthropicの公式ベストプラクティスとどの程度一致しているかを検証しました。
実践したコツ | 対応するベストプラクティス | 一致度 | 備考・詳細 |
---|---|---|---|
問題の背景と原因を詳しく説明 | 「コンテキストを追加してパフォーマンスを向上させる」 | 一致 | 指示の背景や動機を提供することで目標理解が向上 |
求める成果物を具体的に指定 | 「指示を明示的に行う」 | 一致 | Claude 4は明確で明示的な指示に適切に応答する設計 |
エラー情報の詳細化 | 「例と詳細に注意する」 | 一致 | Claude 4は詳細と例に注意を払う特性がある |
ファイル管理ルールの事前設定 | 「エージェントコーディングでのファイル作成を減らす」 | 一致 | 一時ファイルの削除とクリーンアップの重要性 |
検証結果: 実際の開発で体験的に学んだ4つのコツが、すべてAnthropic公式ベストプラクティスと一致していることが確認できました。これは、実践的な開発経験とAIの理論的最適化手法が合致していることを示しています。
Amazon Qは起動する際に、下記のファイル(システムプロンプト)を自動的に読み込みます:
・AmazonQ.md
・amazonq/rules/*.md
この中にQ Developerへの指示を記述することで、動作をカスタマイズすることが出来ます。
参考までに、私が使っているQ Developer CLIの設定ファイルの一部を公開します:
## 基本設定
### 言語設定
・**回答言語**: 日本語を必ず使用してください
## AWS関連の設定
### アーキテクチャ設計
・**必須要件**: AWS Well-Architected Frameworkのベストプラクティスに必ず準拠してください
・**考慮すべき柱**:
- 運用上の優秀性
- セキュリティ
- 信頼性
- パフォーマンス効率
- コスト最適化
- 持続可能性
## ファイル管理
### 一時ファイルの取り扱い
・**作成時**: 反復処理やテスト用の一時ファイル、スクリプト、ヘルパーファイルを作成する場合があります
・**削除**: タスク完了後、これらの一時ファイルを必ず削除してクリーンアップしてください
・**目的**: プロジェクト構造の整合性を保持するため
## 注意事項
1. **言語の一貫性**: 回答とコメントは必ず日本語で統一
2. **ベストプラクティス遵守**: AWS設計時は必ずWell-Architectedに準拠
3. **ファイル管理**: 作業完了後の一時ファイル削除を徹底
今回の開発を通じて、AI支援開発は単なる効率化ツールではなく、開発手法そのものを変革する技術だと実感しました。
これらのコツは、実際の失敗経験から学んだものですが、Anthropicの公式ベストプラクティスと一致していることも確認できました。
AI支援開発の導入を検討されている方々の参考になれば幸いです。ここまで読んでいただきありがとうございました!