AI開発エージェント概要

<aside> 💡

TIPS : 利用頻度の高いプロンプトはドキュメント機能へ保存して、チャットで「◯◯ドキュメンとを参照して(等) 」呼び出し参照してご利用されてみてください。

ドキュメント活用方法はコチラドキュメント機能

</aside>

用途別プロンプト集

a. 改修が必要なファイルのリストと各ファイルの役割 b. 各ファイルで必要な変更の概要 c. 新規に作成が必要なファイル（もしあれば）とその目的 | | | | | | 2 | では、上記Step 1のコードを出力してください

• コード内に日本語でコメントを記載してください
• プレースホルダーコメントや疑似コードの使用を避けてください。コードは完全で、実行準備ができているものとします | | | 画面作成 | VSCode | Fullstack Dev Frontend Dev | 1 | 添付画面イメージを元にフロントエンド機能のコードを作成してください。
• コード内に日本語でコメントを記載してください
• プレースホルダーコメントや疑似コードの使用を避けてください。コードは完全で、実行準備ができているものとします - | 画面イメージを添付する | | テストコード | VSCode | Fullstack Dev Frontend Dev Backend Dev | １ | 今開いているコードのユニットテストのテストコードを作成し、日本語で説明してください。以下の要件を満たすようにしてください：

1. 明確で簡潔な日本語のコメントをコード内に記載
2. Junitのフレームワークを使用する
3. カバレッジ：C2（条件網羅）を満たすこと
4. 必要なインポート文、関数定義、メイン実行ブロックを含む、すべての必要なコードを含める
5. プレースホルダーコメントや疑似コードの使用を避け、完全で実行準備ができているコードを提供する
6. 以下のテストケースを含めること：

• 正常系：有効な入力での動作確認
• 異常系：無効な入力、境界値、エッジケースの処理
• モック/スタブの使用：外部依存がある場合 | VSC版の場合「選択した部分の」等の指定も可能 | | リファクタリング | VSCode | Fullstack Dev Frontend Dev Backend Dev | １ | 現在開いているファイルのコードをレビューし、 以下の観点から改善点を3つずつ挙げ日本語で説明してください：

1. パフォーマンス
2. 可読性
3. セキュリティ

各改善点について、具体的な修正案も提示してください。 | | | コードレビュー | Both | Fullstack Dev Frontend Dev Backend Dev | 1 | 以下のコードレビューを実施します。結果を日本語で解説してください。 /xxx/xxx/xx/xxxx.xx /xxx/xxx/xx/xxxx.xx

[レビュー観点] アクセストークンが失効直前の場合は、新しいトークンを取得しデータベースへの登録を実施しているかどうか | | | テスト結果(バグ分析) | Both | Project Manager Fullstack Dev | | 以下のテスト結果の原因を調査してください：

xxxページへの入力

日付：2024年7月3日 検索条件：在庫がない

期待される出力

在庫なしの商品を商品名の昇順で表示

テスト結果

在庫ありの商品が一部含まれている | | | 性能問題調査 | Both | Fullstack Dev Backend Dev | 1 | データベース更新クエリの格納されているフォルダを洗い出してください | | | | | | 2 | xxxx/xxxx フォルダ内でレイテンシーを引き起こす可能性のあるクエリを洗い出し、問題点を解説してください | | | テストカバレッジレポート | Both | Manager(β) | 1 | 「{プログラム名}のテストコードのカバレッジレポートを出力して 」 | | | 設計書生成 システム構成図 | Both | | 1 | 本システムの技術スタックやアーキテクチャ、使用しているライブラリやフレームワークについて日本語のMarkdownで纏めて | | | | | | ２ | 同様の内容をシステム構成図としてMermaidで作成して。

• 左から右へのフローとする
• ノードのラベルと説明は引用符で囲うこと
• 日本語テキストは引用符内に含めるなど適切にエスケープすること | | | 設計書生成 機能一覧 | Web | Product Owner | 1 | ビジネスロジックドキュメント｛対象のビジネスロジック名を列挙｝を業務カテゴリ毎に分類して | | | | | | | ビジネスロジックを機能一覧にしたいため、以下の様式でカンマ区切りで出力して。

<様式> カテゴリ, ビジネスロジック名, 機能サマリ, 入力, レスポンス

• ビジネスロジック名以外のカラムの言語は日本語とする
• 機能サマリについては300文字程度の記載とする
• 入力・レスポンスのカラム内ではカンマは用いず「・」を使用する

<対象> {ビジネスロジックをword形式でダウンロードしたものからビジネスロジック名をコピーして貼り付ける} | | | 設計書作成 画面一覧 | Both | Fullstack Dev Frontend Dev | 1 | 本システムのフロントエンド画面のパスを洗い出してください | Pageファイル一覧などでの質問でも可 | | | | | 2 | 上記パスを元に画面一覧をカンマ区切りで出力してください。項目はカテゴリ, 画面名, パス, 処理のサマリとします。

カテゴリ毎にソートしてください 処理のサマリについては300文字程度の記載とする | 画面遷移図作成と同じ会話上で実施も効率的 | | 設計書作成 画面遷移 | Both | Fullstack Dev Frontend Dev | 1 | 本システムのフロントエンド画面のパスを洗い出してください | Pageファイル一覧などでの質問でも可 | | | | | 2 | 各画面からの遷移関係を洗い出してください。１つ１つファイルを確認し、すべての階層を対象としてください。 | | | | | | 3 | 本システムの画面遷移図を作成して日本語で説明して

• 形式はMermaidとする。左から右へのフローとする。
• 遷移元となるボタン名などがあれば記載する | | | 設計書作成 画面入出力仕様書 | Both | Fullstack Dev Frontend Dev | 1 | 〇〇〇画面の入出力について以下の項目を整理して 識別ID,表示用のラベル,部品の種類,有効,入力,表示桁数,入力桁数,データ型,文字種,入力制約,初期表示,出力仕様,必須,補足 Step1：ページファイルを分析し上記内容を整理 Step2：分析して結果をカンマ区切りで出力 内容は極力日本語とすること。またture/falseは〇などで表現すること

結果はCSVのコードブロックで出力して。 | | | 設計書作成 イベント仕様書 | Both | Fullstack Dev Frontend Dev | 1 | 〇〇画面の処理フローを、以下の形式で網羅的にまとめ日本語で説明してください：

1. イベント一覧 形式：番号,トリガー,アクション,連携先,連携項目

• コードを分析しイベントを漏れなく洗い出すこと
• 初期表示などもトリガーとして扱うこと
• 連携項目は入出力パラメータをスラッシュ区切りで記載
• csvのコードブロックで出力

2. 各イベントの詳細フロー

• mdのコードブロックでイベント番号ごとに分けて出力

【イベント番号-イベント名】

1. 入力値の取得

• 取得するパラメータ
• パラメータのバリデーション
• エラー時の処理内容

2. 画面の状態変更

• 更新する状態項目
• 状態変更に伴うUI変更
• エラー時の処理内容

3. 外部連携処理

• 呼び出すAPI/処理
• リクエストパラメータ
• レスポンス処理
• エラー時の処理内容

4. 完了処理

• 画面遷移

• メッセージ表示

• その他の後処理 | | | 設計書作成 DFD(データフロー図) | Both | Fullstack Dev Backend Dev | 1 | 〇〇や□□に関わるDFDをMermaidで作成してください。 • Step1：〇〇、□□に関わるモジュールを洗い出す • Step2：上記コードを分析しアクセスしているエンティティと処理内容(CRUD)を分析する • Step3 ：MermaidでDFDを作成する

  ◦ 処理名はコードに記載のモジュール名、その他の項目は日本語としてください ◦ フローは左から右としてください ◦ 例えば複数の処理が同一のエンティティにアクセスしている場合など関係性を表現してください ◦ 処理からエンティティへの関係性の説明文冒頭には「C」「R」「U」「D」のいずれかを先頭に付与し、日本語の説明文を続けてください ◦ ユーザーは[]、エンティティは[()]、処理は(())としてください | | | 設計書作成 CRUD図 | Both | Fullstack Dev Backend Dev | １ | 本システムのエンティティ一覧を洗い出して | | | | | Fullstack Dev Frontend Dev | 2 | 本システムの画面一覧を洗い出し、処理内容を分析の上、機能名を付与して | Back→Frontにエージェントを変更 | | | | Fullstack Dev Frontend Dev | 3 | ヘッダーも含めたカンマ区切りデータでCRUD図を出力する

• 縦軸を機能名、横軸をエンティティ名とする

• CRUDは「C」「R」「U」「D」で表現する | | | 設計書生成 シーケンス図 | Both | Fullstack Dev Frontend Dev Backend Dev Project Manager | 1 | 本システムのログイン処理について、日本語のMermaidのシーケンス図フローで表現してください。

• ユーザーがログインページにアクセスしてからログイン完了までの全ステップが対象

• フロー図は詳細かつ包括的なものとし、各ステップに簡潔な説明を加えてください

• APIのエンドポイントやバリデーションなどを主に処理を行うファイル名を併記してください

• ノードのラベルと説明は引用符で囲うこと

• 日本語テキストは引用符内に含めるなど適切にエスケープすること | | | 設計書生成 バッチ処理設計書 | WEB | Manager(β) | 1 | 本システムのバッチ処理一覧を表形式で出力して。項目はバッチ処理ID、バッチ処理名とする。バッチ処理IDはファイル名などから抽出し、バッチ処理名は日本語とする。 | | | | | Manager(β) | 2 | 以下のようなプロンプトを同じスレッドで連続して実施し、結果を統合することで作成可能です。 ①〇〇処理のの処理内容を日本語のマークダウンで作成してください 処理開始やパラメーターチェックなどから、処理の終了までを1, 1-1などのように採番しながらStep by Stepで表現してください

②上記文書の項番および枝番を用いて入出力について以下のヘッダーの表形式で整理してください。 項番, 枝版, I/O, Type, 名称 I/OはIまたはO TypeはDB, FILE, MEMORY 該当する入力・出力がない場合はカンマのみ出力

③各処理の流れやインプットアウトプットについてMermaidのシーケンス図で表現してください。 ノードのラベルと説明は引用符で囲うこと 日本語テキストは引用符内に含めるなど適切にエスケープすること | | | 帳票設計書 帳票一覧 | Both | Manager(β) | 1 | 「本システムの帳票出力機能を分析し、帳票一覧を表形式で作成してください。 帳票名、帳票ID、形式、帳票概要 形式はPDF、その他のファイル形式、印刷出力のいずれかを設定してください」 | | | 外部インターフェース定義書 | Web | Manager(β) | 1 | 「以下の形式で日本語のファイル仕様書を作成してください・ファイル形式・拡張子 ・ファイル名・セパレーター・くくり文字・文字コード/改行コード|項目名 | 型桁| 編集内容」 | | | API実装におけるセキュリティ対策 | Both | Fullstack Dev Frontend Dev Backend Dev | 1 | APIに関して、関連するソースコードを分析し、サニタイジングなどのセキュリティ設計について日本語のmdで出力して | | | リスク診断/セキュリティ診断 | Both | Fullstack Dev Frontend Dev Backend Dev | 1 | コードをいくつかのブロックに分けてリスク診断を行いたいです。適切なブロック分けを提案し、各カテゴリに対応するディレクトリを示してください。 | | | | | | 2 | 上記の「xxxxx」カテゴリのコードについて、Top10のリスク（セキュリティやパフォーマンス）を洗い出し、 評価スコアと★〜★★★★★で重み付けしてください。 出力は評価スコアの高い順に行ってください。 また、リスクの該当箇所のみコードを引用してください。

<形式>

順位（1位〜10位）

評価☆☆☆☆★～★★★★★

評価スコア（脅威 x 影響 x 発生可能性）

リスクサマリ

観点（以下のaからhのいずれか）

対象ファイル

該当部分のみのコード引用

詳細説明

推奨リスク対応戦略（受容/回避/軽減/移転）

<観点> a. 認証とアクセス制御の脆弱性： 不適切な認証メカニズム、アクセス制御の不備、権限昇格 b. インジェクションの欠陥： SQLインジェクション、コマンドインジェクション、LDAPインジェクション c. クロスサイトスクリプティング（XSS）と他のクライアントサイドの脆弱性： 反射型XSS、格納型XSS、DOM-based XSS d. 安全でないデシリアライゼーションとAPI脆弱性： ユーザー提供データの安全でないデシリアライゼーション、APIセキュリティの設定ミス e. セキュリティの設定ミスと古いコンポーネント： サーバーの設定ミス、既知の脆弱性を持つコンポーネントの使用 f. 機密データの露出と暗号化の失敗： 不適切な暗号化、弱い暗号化アルゴリズム、データ漏洩 g. サーバーサイドリクエストフォージェリ（SSRF）とリモートコード実行（RCE）： 安全でないリソースフェッチング、コードインジェクションの脆弱性 h. ソフトウェアとデータの整合性の問題： 安全でないCI/CDパイプライン、署名されていないコードやデータ、侵害された依存関係

注: 同じ観点が複数回使用されても構いません。

<評価基準> 脅威（1-5）: リスクの潜在的な危険度 影響（1-5）: リスクが顕在化した場合のビジネスへの影響度 発生可能性（1-5）: リスクが実際に発生する確率

評価スコア = 脅威 x 影響 x 発生可能性

最後に、サマリとして5つのネクストアクション計画を提供してください。各アクションには優先度（高/中/低）を付けてください。

<形式> アクションNo.（1〜5） 優先度 対象ファイル アクション説明 | | | | | | 3 | では、アクションNo.1のコードを生成してください | | | ユースケースの作成(要件から) | web | Product Owner | 1 | 本システムは従業員が勤怠を記録するシステムです。新たに承認者が勤怠承認を実施するユースケースを作成してください。以下の項目に沿って、具体的かつ詳細に記述してください。

ユースケース名: 簡潔で分かりやすい名前をつけてください。

アクター: 主要アクターと副次的アクターを明確に区別してください。

事前条件: システムの状態や必要なデータなど、ユースケース開始前に満たすべき条件を列挙してください。

事後条件: ユースケース完了後のシステムの状態や結果を具体的に記述してください。

メインフロー: 正常系の処理を順序立てて記述してください。 各ステップでの入力データと出力結果を明確にしてください。

代替フロー: メインフローから分岐する可能性のある処理を記述してください。 どの時点で代替フローに移行するかを明確にしてください。

エラーハンドリング: 想定されるエラーとその対処方法を具体的に記述してください。 ユーザーへのエラーメッセージの内容も含めてください。

バリデーション: 入力データに対する検証ルールを具体的に記述してください。 各バリデーションチェックの目的も明記してください。

関連ユースケース: 本ユースケースと関連する他のユースケースがあれば言及してください。 | | | ユースケースの作成(コードから) | web | Fullstack Dev Frontend Dev | 1 | RegisterNewCustomerのページの機能を元にユースケースをマークダウンで作成してください。

ユースケース名: 簡潔で分かりやすい名前をつけてください。

アクター: 主要アクターと副次的アクターを明確に区別してください。

事前条件: システムの状態や必要なデータなど、ユースケース開始前に満たすべき条件を列挙してください。

事後条件: ユースケース完了後のシステムの状態や結果を具体的に記述してください。

メインフロー: 正常系の処理を順序立てて記述してください。 各ステップでの入力データと出力結果を明確にしてください。

代替フロー: メインフローから分岐する可能性のある処理を記述してください。 どの時点で代替フローに移行するかを明確にしてください。

エラーハンドリング: 想定されるエラーとその対処方法を具体的に記述してください。 ユーザーへのエラーメッセージの内容も含めてください。

バリデーション: 入力データに対する検証ルールを具体的に記述してください。 各バリデーションチェックの目的も明記してください。

関連ユースケース: 本ユースケースと関連する他のユースケースがあれば言及してください。 | | | E2Eテストケースの作成 | | | 1 | xxxxxx(ユースケースタイトル)のユースケースドキュメントを慎重に分析し、以下の要素を特定してください：

主要な機能 ユーザーの行動 システムの応答 ビジネスルールと制約 想定されるエラーケース

各ユースケースに対して、以下の要素を含む詳細なe2eテストケースを作成してください：

テストケース ID（一意の識別子） テストケースの説明（目的と範囲を明確に） 前提条件（詳細かつ具体的に） テストデータ（具体的な値や条件） テストステップ（番号付きの具体的な操作手順） 期待される結果（各ステップごとに詳細に） 実際の結果（テスト実行時に記入） テストステータス（Pass/Fail/Blocked等） 備考（追加情報や注意点）

テストケースは、以下の基準を満たすようにしてください： 明確で再現可能であること ユーザーの視点から書かれていること エッジケースやエラー条件を網羅的に考慮すること 自動化を念頭に置いた記述であること テスト結果の検証方法が明確であること

以下のシナリオタイプを必ず含めてください：

正常系（Happy path）: 最も一般的で期待される使用パターン 代替フロー: ユーザーが別の方法で目的を達成するケース 例外系: エラーや異常な入力に対する動作 エッジケース: 境界値や極端な条件での動作 負荷テスト: システムの性能限界を検証するケース

テストデータについて、以下の点を詳細に考慮してください：

現実的かつ多様なテストデータを使用すること 境界値、無効な入力、特殊文字を含むデータを準備すること データのプライバシーとセキュリティを考慮し、必要に応じてマスキングを行うこと データの組み合わせを考慮し、様々なシナリオをカバーすること

テストの優先順位を設定し、以下の基準で分類してください：

クリティカル: システムの主要機能に関わるテスト 高: 重要な機能や頻繁に使用される機能のテスト 中: 一般的な機能のテスト 低: エッジケースや稀に使用される機能のテスト

テストケース間の依存関係を明確に示し、実行順序を指定してください。 | | | | | | 2 | 以下の列構造でCSVにしてください テストケースID,説明,優先度,前提条件,テストデータ,ステップ番号,アクション,期待される結果,実際の結果,ステータス,備考 | | | アプリ仕様概要の可視化(コードから) | web | Fullstack Dev Frontend Dev Manager Agent | 1 | 本システムの◯◯◯機能関連ファイル一覧を洗い出して | | | | | | 2 | -◯◯◯周辺機能について以下の質問

▶︎ソースコード分析用プロンプト: 以下の手順でソースコードを分析し、要求された情報を抽出してください： -コードベース全体を横断的に分析 -各画面/コンポーネントについて以下の情報を抽出: -画面名実装されている機能のリスト各機能の詳細説明関連するAPIエンドポイント（GET/POST）関連するデータベーステーブルや操作

▶︎抽出した情報を以下の形式のCSVで出力: -画面名,画面対象ファイル名,機能,機能詳細,機能処理ファイル名,関連API,関連API名,関連データベース

▶︎注意点: -コメントや命名規則から情報を推測 -フレームワークの構造を考慮機密情報は除外可読性と正確性を重視

▶︎推奨する分析ステップ: -ディレクトリ構造の確認 -ルーティング定義の確認コンポーネント/ページの詳細分析 -APIコントローラーの確認 -データアクセス層の調査

▶︎重要: 【最終的なアウトプットは必ずCSVで出力してください。】 【処理が記述されているファイル名は**.拡張子のみフルパスでは出力しないで。】 【内容は極力日本語とすること。】 | | | ユニットテスト生成指示 | Both | Fullstack Dev Frontend Dev Backend Dev Manager(β) | 1 | -◯◯◯コードを分析し、以下のテスト要件に基づいて、ソースコードを分析し包括的なユニットテストを生成してください。 テスト要件 ▶︎ データ取得テスト -サーバーサイドデータのモック実装 -データ存在/不在の両シナリオのテスト -データ取得失敗時のエラーハンドリング検証 -期待値と実際の表示データの厳密な比較 ▶︎ データ更新テスト -正常更新フローの検証 -更新後の状態確認メカニズム -サーバー応答に基づく状態変化の検証 ▶︎ テストカバレッジ向上 -境界値分析とテスト実装 -エッジケース（空データ、最大値など）の網羅 -非同期処理の適切なハンドリング -分岐・条件網羅率100%を目指したテスト設計 ▶︎ セキュリティテスト -入力検証（不正/悪意ある入力パターン） -SQLインジェクション対策検証 -XSS対策の確認 -認証・認可フローの検証 -機密データ処理の安全性確認 -リソースリーク検証 ▶︎ 例外処理の網羅的テスト -すべての例外パスの検証 -予期しない例外の適切な処理確認 -エラー状態からの回復メカニズムの検証 ▶︎ コンポーネント間の依存関係テスト -依存コンポーネントの適切な隔離とモック -コンポーネント間インタフェースの検証 -依存注入の正確性確認 ▶︎ 状態管理のテスト -複雑な状態遷移の網羅的検証 -状態の永続化と復元のテスト -複数の状態変更シナリオの検証 ▶︎ 出力形式 -コード分析サマリー -テスト戦略の詳細説明 -生成テストコード（完全版） -カバレッジ分析結果 -セキュリティ分析レポート -改善提案（オプション） ▶︎ 実装ガイドライン -既存ユニットテストフレームワークに準拠したコード形式 -明確な命名規則と説明コメントの徹底 -モック/スタブの適切な実装 -最新のテストフレームワーク機能活用 -保守性と可読性の高いコード構造 -非決定的要素への対処方法の明確化 -テストデータ生成の効率的な戦略 -テスト実行の高速化とリソース最適化 最終的には、完全なユニットテストコード、説明コメント、実装例、および必要な設定を日本語でコメント付与し生成して | |