04 — プロンプト集

プロンプトテンプレート & mdファイルダウンロード

工程別にそのまま使えるプロンプトテンプレートと、言語・フレームワーク・DBの組み合わせに応じたルールファイルの一括ダウンロードを提供します。

プロンプトテンプレート集

質問フェーズ チェックリスト（12項目）

新規開発・既存システム分析・マイグレーションのいずれのフェーズでも、「AIに聞くべき業務要件の抜け漏れ」を潰すための共通チェックリストです。1 項目ずつ順番にコピー&貼り付けして Claude / Copilot / Amazon Q に投げれば、担当者の経験やモデルの揺れに依存しない網羅的なヒアリングが可能になります。 仕様書作成タブの「質問フェーズ」プロンプトと併用することで、AI が出し忘れがちな観点を強制的に押さえられます。

A. 目的・要件の土台
01業務目的・ビジネス KPI

「何を解決するシステムか」「成功とはどの数値が動けば成功か」が曖昧なまま進むと、実装後に要件の認識違いで手戻りが発生する。最初に目的と KPI を言語化する。

  • この機能が目指すビジネス目的と、成功を測る KPI（CV 率・削減時間・エラー率など）を具体的な数値付きで整理してください。
  • 現行業務における課題を 3 つ挙げ、そのうち今回のシステムで解決するもの／しないものを切り分けてください。
  • 「この機能が使われなくなったらどう判断するか」の撤退基準を提案してください。
02ステークホルダーと意思決定者

「誰が使うか」「誰が OK を出せば進められるか」を特定しないと、後から別部署の差し戻しで設計が覆る。承認ラインを最初に固定する。

  • この機能の利用者ロール・依頼元部署・承認者を RACI で整理してください。
  • 仕様確定の最終意思決定者と、その人が判断に必要とする情報を列挙してください。
  • 利用者ロールごとの主要ユースケースを 3 つずつ挙げ、優先順位を付けてください。
03スコープ境界と前提条件

「やること／やらないこと」を切らないと、ヒアリングで出てきた要望が全部入り込んで炎上する。境界を最初に宣言する。

  • 今回のリリースに含める機能と、次期以降に切り出す機能を明示的に分離してください。
  • 前提条件（既存データの整合性・運用ルール・法改正予定など）を箇条書きで列挙してください。
  • スコープ外だが将来影響する可能性がある項目を「要観察リスト」として記録してください。
B. 機能・データ設計
04既存システムとの連携・データ I/O

「社内の既存システムとどう繋がるか」を聞き忘れると、後から認証方式や API 仕様の制約で実装やり直しになる。接点を全て洗い出す。

  • この機能が読み書きする既存システム・DB・SaaS を全て列挙し、連携方式（REST / ファイル / DB 直結 / MQ）を明示してください。
  • 連携先ごとの応答 SLA と、障害時の縮退運転方針を提示してください。
  • 既存マスタ（顧客・商品・組織など）のどれが Source of Truth か、重複するマスタの統合方針と合わせて整理してください。
05データモデル・マスター管理・履歴

「変更履歴を残すか」「マスタの有効期間はどう管理するか」を決めないと、後から監査対応や時系列分析ができなくなる。初期に設計する。

  • 主要エンティティ（例: 顧客・契約・注文）の ER 図案と、それぞれの有効期間管理（論理削除／履歴テーブル／バイテンポラル）の方針を提案してください。
  • マスタ更新時に過去データをどう扱うか（スナップショット保持 / 現行値参照）を業務観点で決定してください。
  • 参照整合性の強制範囲（DB 制約で保証 / アプリで保証）を明示してください。
06入力検証・業務ルール・例外処理

「境界値」「異常系」の扱いを先に決めないと、実装者ごとに判断が分かれてバグの温床になる。業務ルールとして言語化する。

  • 入力項目ごとの必須／任意・文字種・最小最大・組み合わせ条件を業務ルールとして整理してください。
  • 業務エラー（在庫切れ・与信 NG など）とシステムエラー（DB 接続不可など）の切り分け方針と、ユーザー表示メッセージを決めてください。
  • 冪等性が必要な操作を特定し、再送時の振る舞い（同一結果返却 / 409 エラー）を提案してください。
C. 非機能・セキュリティ
07非機能要件（性能・可用性・SLA）

「どのくらいの速さ」「どのくらい落ちていいか」を数値化しないと、アーキテクチャが過剰にも過少にもなる。初期に合意する。

  • 想定 TPS・同時接続数・ピーク時間帯・レスポンス SLA（P95 / P99）を業務要件から逆算してください。
  • 可用性目標（99.9% / 99.99%）と、月間許容ダウンタイムを明示してください。
  • 性能劣化時の縮退運転（機能の一部停止 / レートリミット）の優先順位を提案してください。
08認証・認可・権限設計

「誰が何をできるか」を後から足そうとすると、既存コードの大半に影響する。認証方式と権限モデルは初期に決定する。

  • 認証方式（OIDC / SAML / API Key / Basic）と、セッション／トークン有効期限を提案してください。
  • 画面・API ごとにロール（管理者 / 一般 / 参照のみ等）の権限マトリクスを作成してください。
  • 管理者権限の分離（特権管理／監査分離）と、権限昇格時の承認フローを提示してください。
09ログ・監査証跡・可観測性

「後から追えるか」を設計しないと、障害調査と内部統制対応で詰む。記録粒度と保管期間を初期に決める。

  • アクセスログ・業務監査ログ・システムログの 3 分類について、記録項目と保管期間を提案してください。
  • 監査ログに含めるべき項目（誰が／いつ／何を／結果／リクエスト ID）を業務観点で決めてください。
  • メトリクス・トレース・アラートの初期セット（SLO 監視対象）を提案してください。
D. 運用・移行・法令
10テスト戦略（単体 / 結合 / E2E / 負荷）

「どの層で何を保証するか」を先に合意しないと、テストが単体に偏ったり逆に E2E 偏重でメンテ地獄になる。テストピラミッドを決める。

  • 単体・結合・E2E・負荷の各層で保証する観点と、カバレッジ目標を提案してください。
  • ハッピーパスだけでなく、業務エラーケース・境界値・同時実行シナリオを網羅するテスト観点を列挙してください。
  • 外部連携先のモック戦略（スタブ / コンシューマ駆動契約テスト）を提案してください。
11運用・保守・障害対応・ロールバック

「本番で困ったときに誰が何をするか」を設計に織り込まないと、リリース後にオンコール担当者が詰む。運用設計は最初に決める。

  • デプロイ戦略（Blue/Green / Canary / Rolling）と、ロールバック手順を提案してください。
  • 障害検知から一次対応・恒久対応までの運用フローを RACI で整理してください。
  • バックアップ・リストア手順と、RPO / RTO の目標値を業務要件から決めてください。
  • 移行時の既存データ変換・並行稼働期間・切替判定基準を提案してください。
12法令・コンプライアンス・個人情報保護

「個情法・業法・契約」の観点を抜くと、リリース直前に法務から差し戻されて全部やり直しになる。最初に対象法令を洗い出す。

  • この機能が扱う個人情報・要配慮個人情報の区分と、取得・利用・保管・削除の各段階での必要措置を整理してください。
  • 適用される業法（金商法 / 医療 / 電気通信事業法 など）と、必要な管理策を列挙してください。
  • 外部委託・越境データ移転がある場合の契約・同意・安全管理措置を提案してください。
使い方: 項目 01 から順に「具体的な質問文例」を 1 つコピーし、そのままチャットに貼って答えを集めてください。すべての項目を埋め終わったら、仕様書作成タブの「仕様書作成（生成フェーズ）」プロンプトにまとめて渡すと、網羅性の高い仕様書ドラフトが生成できます。既存システム分析・マイグレーションでも同じ 12 項目をそのまま使えます。
セッション開始確認
作業前に参照ルールと成果物を固定する
▼
以下の順でファイルを読み、読み終わるまで実装を開始しないでください。 1. rules/project_info.md 2. rules/coding_rules.md 3. rules/architecture_rules.md（存在する場合） 4. rules/security_rules.md 5. rules/ui_ux_guidelines.md 6. rules/prohibited_rules.md 7. rules/agent_operation_rules.md 読み終えたら、今回の作業で「やること」「やらないこと」「確認が必要な点」を3つずつ列挙してください。 不明点は推測で埋めず、質問として分離してください。
レビュー観点抽出
セキュリティ・UI・禁止事項まで含めてレビューする
▼
以下の観点でレビューしてください。 - 仕様逸脱・要件漏れ - セキュリティ（入力検証、認可、ログ、秘密情報） - UI/UX（可用性、エラーメッセージ、アクセシビリティ） - 禁止事項違反（責務混在、直書き、危険API、推測実装） 出力は「重大」「中」「軽微」の順で、根拠ファイルと修正案を添えて提示してください。
新規機能の設計ドラフト
分析から実装可能な設計まで一気通貫で作る
▼
新規機能を1つ追加します。次の順で成果物を作成してください。 1. 機能概要（目的、利用者、業務価値） 2. 画面/操作フロー 3. API一覧（入力・出力・異常系） 4. テーブル利用方針 5. テスト観点 必ず rules/security_rules.md と rules/ui_ux_guidelines.md に準拠し、 禁止事項に抵触しない構成にしてください。
API詳細設計作成
1 APIを設計仕様化する
▼
対象API: 【API名】 以下の項目で設計してください。 - 目的 - エンドポイント/メソッド - リクエスト（必須/任意、制約） - レスポンス（成功/業務エラー/システムエラー） - 認証・認可 - 入力検証 - 監査ログ - 依存テーブル - テスト観点 結果は docs/official/design/api_【API名】.md 形式で出力してください。
▼ 実行結果サンプルを見る (Claude Sonnet 4.6 で実行) 
# api_OrderCreate.md

## 目的
BtoB 受注管理 SaaS「StockMate」において、営業担当またはバイヤーポータルから
新規受注を 1 件登録する。登録と同時に在庫引き当て・与信枠チェックを同期実行し、
業務トランザクションの二重登録を防止する。

## エンドポイント / メソッド
`POST /api/v1/orders`

- コンテンツタイプ: `application/json; charset=utf-8`
- 認証: 必須 (Bearer JWT / scope: `orders:write`)
- 冪等性: `Idempotency-Key` ヘッダ必須 (UUID v4 / 24h 保持)

## リクエスト
| 項目 | 型 | 必須 | 制約 |
|---|---|---|---|
| customer_id | UUID | ○ | 既存かつ `status=active` |
| order_date | date (ISO8601) | ○ | 当日 ±7 日以内 |
| items[] | array | ○ | 1 件以上 200 件以下 |
| items[].sku | string | ○ | 正規表現 `^[A-Z0-9-]{4,24}$` |
| items[].qty | integer | ○ | 1 以上 9999 以下 |
| items[].unit_price | decimal(12,2) | ○ | 0.01 以上 |
| shipping_address_id | UUID | ○ | customer_id に紐付く住所 |
| memo | string | × | 最大 500 文字 / 制御文字禁止 |

### リクエスト例
```json
{
  "customer_id": "5f2b8c6a-3d1e-4b9f-a8c7-1e2d3f4a5b6c",
  "order_date": "2026-04-11",
  "items": [
    { "sku": "SM-BOLT-M8-50", "qty": 120, "unit_price": 38.50 },
    { "sku": "SM-NUT-M8",     "qty": 240, "unit_price": 6.20  }
  ],
  "shipping_address_id": "a1b2c3d4-e5f6-7890-abcd-ef0123456789",
  "memo": "納期厳守 / 分納不可"
}
```

## レスポンス
### 成功 (201 Created)
```json
{
  "order_id": "ord_2026041100017",
  "status": "confirmed",
  "total_amount": 6108.00,
  "reserved_stock": true,
  "credit_check": "passed",
  "created_at": "2026-04-11T09:22:14+09:00"
}
```

### 業務エラー (409 Conflict)
| code | message | 発生条件 |
|---|---|---|
| E_STOCK_SHORTAGE | 在庫不足 (SKU=xxx) | 引き当て不可 |
| E_CREDIT_LIMIT   | 与信枠超過            | 残枠 < 合計金額 |
| E_CUSTOMER_HOLD  | 取引停止中の顧客       | status=hold |

### システムエラー (5xx)
- レスポンスボディは `{ "code": "E_INTERNAL", "trace_id": "..." }` のみ
- 内部例外メッセージ・SQL・スタックトレースは出力しない

## 認証・認可
- 認証: Bearer JWT (Cognito 発行)
- 認可: scope `orders:write` 必須。テナント ID は JWT claim から取得し、
  `customer_id` のテナント一致を DB 層で検証 (横串アクセス防止)

## 入力検証
- JSON Schema で 1 次バリデーション (FastAPI Pydantic v2)
- 業務検証は Service 層で実施 (在庫・与信・住所紐付け)
- 不正値は 400 Bad Request + `E_VALIDATION` + 項目単位エラーリスト

## 監査ログ
`audit_orders` テーブルに以下を INSERT (非同期 Outbox 経由):
- actor_user_id / actor_ip / tenant_id
- action = `order.create`
- target_id = order_id
- before = null / after = JSON スナップショット
- result = success | business_error | system_error
- occurred_at

## 依存テーブル
| テーブル | 用途 | ロック |
|---|---|---|
| customers | 顧客状態参照 | 共有 (SELECT) |
| stock_items | 在庫引き当て | 悲観 (SELECT ... FOR UPDATE) |
| credit_accounts | 与信枠チェック | 共有 |
| orders / order_items | 受注登録 | INSERT |
| audit_orders | 監査ログ | INSERT (非同期) |

## テスト観点
1. 正常: 単一明細 / 複数明細 / 境界値 (qty=1, 9999)
2. 冪等: 同一 Idempotency-Key 再送で 200 (前回結果を返す)
3. 業務エラー: 在庫不足 / 与信超過 / 取引停止顧客
4. 認可: 他テナントの customer_id を指定 → 403
5. 入力検証: sku フォーマット / 日付範囲 / memo 長さ
6. 並行: 同一 SKU への同時受注 100 並列で在庫オーバー無し
7. 監査: audit_orders に全ケースで記録される

## 未確定事項 (TODO)
- [ ] 分納フラグの要件確定 (memo 例に「分納不可」があるが API 項目化する？)
- [ ] 外貨受注の扱い (現状 JPY 前提)
- [ ] Outbox テーブル設計は別 API 仕様書と統合予定
保守開発（実装はAgent主導）
調査から実装までAgentを主担当にする
▼
保守改修を実施します。実装はAgent主導で進めてください。 進め方: 1. 影響範囲を広く浅く調査 2. 詳細化調査（対象クラス・SQL・画面を特定） 3. 修正チェックリスト作成 4. Agentが実装案を提示 5. 人が承認後、Agentが実装 6. Agentがテスト観点を作成し、テストコードを生成 7. 結果を横断レビュー 制約: - 不明点は推測実装しない - 変更禁止ファイルは厳守 - セキュリティと禁止事項を必ず確認
保守開発の並行化ルール
競合なく複数Agentで作業する
▼
次の条件で並行作業してください。 並行可能: - 影響調査（対象機能が異なる） - テスト観点作成（実装完了済み機能） - ドキュメント更新（対象が分離される場合） 並行禁止: - 同一ファイルの同時編集 - 未確定仕様のまま複数実装 - レビュー未了成果物を正本扱い 成果物には、担当範囲・依存関係・レビュー要否を明記してください。
Copilot疑似並行運用（実務テンプレ）
1セッション1タスクで競合を防ぐ
▼
GitHub Copilot で疑似並行運用します。以下の順で実施してください。 前提: - 1セッション = 1タスク - 同一ファイルの同時編集は禁止 - レビュー未了成果物は正本扱いしない 手順: 1. rules/ 配下を読み、作業制約を整理 2. フェーズに合わせて brief を作成 - 分析: docs/wip/agent_briefs/TASK-ANA-xxx.md - 設計: docs/wip/agent_briefs/TASK-DSN-xxx.md - 実装: docs/wip/agent_briefs/TASK-IMP-xxx.md （テンプレート: analysis/design/implementation のいずれかを利用） 3. docs/wip/agent_task_board.md を更新（担当、対象ファイル、依存、着手条件） 4. docs/wip/file_lock.md で対象ファイルをロック 5. 実装/設計を実施 6. docs/wip/review_queue.md へレビュー依頼を登録 7. セッション終了時に docs/wip/session_handoff.md を更新 出力: - 今回編集したファイル - 作成/更新した brief ファイル - 未完了タスク - 次セッションの開始手順 不明点は推測で埋めず、判断待ちとして分離してください。
Brief命名自動提案（TASK-ANA/DSN/IMP）
タスク内容からフェーズとファイル名を統一する
▼
次のタスク内容を読み、briefファイル名とテンプレート種別を提案してください。 入力: - タスク概要: 【記入】 - 期待成果物: 【記入】 - 依存タスク: 【記入】 - 変更予定ファイル: 【記入】 判定ルール: - 調査・影響分析が主目的なら ANA - 仕様確定・設計定義が主目的なら DSN - コード変更・テスト実行が主目的なら IMP - 複合タスクの場合は主目的を1つ選び、残りはサブタスクに分割する 出力: 1. 推奨フェーズ（ANA / DSN / IMP）と理由 2. 推奨ファイル名（docs/wip/agent_briefs/TASK-XXX-nnn.md） 3. 使用テンプレート（analysis / design / implementation） 4. 着手前に埋めるべき項目（3つ） 5. 分割要否（Yes/No）と、必要時の分割案 制約: - 不明点は推測で埋めない - 同一ファイル同時編集が発生する場合は、file_lock.md の更新を先に提案する - レビュー未了成果物は次工程の正本にしない
関連ガイド: このタブは「個別改修ごとに何を調べるか」のピンポイント分析プロンプト集です。 システム全体のベースライン文書（テーブル仕様書・PG仕様書・API仕様書 等を コード+試験ができる粒度 で全量生成）を一括で作りたい場合は 徹底分析キット をご利用ください。

推奨フロー: ① 初回は徹底分析キットで analysis_output/ 全量を生成 → ② 以降の保守ではこのタブのプロンプトで個別調査 → ③ 結果を analysis_output/ に追記してベースラインを更新し続ける
既存システム分析メニュー（保守開発の入口）
まず何を調べるかをメニュー選択で固定する
▼
保守開発を開始します。既存システム分析を先に実施し、分析メニューの選定結果と対応方法を決定してください。 分析メニュー: 1. 業務仕様差分（現仕様と変更要望の差） 2. 画面・導線分析（遷移、入力、表示条件） 3. API契約分析（リクエスト、レスポンス、エラー） 4. DB/SQL分析（参照テーブル、更新SQL、影響件数） 5. バッチ/ジョブ分析（実行条件、依存、再実行） 6. 障害・問い合わせ分析（再現条件、ログ、根本原因候補） 対応方法メニュー: A. 緊急障害対応（最小差分・即時復旧優先） B. 小規模改修（既存設計踏襲・影響最小） C. 中規模改修（責務整理を含む改修） D. 技術負債解消（段階移行・互換性維持） E. 調査継続（実装保留・追加情報待ち） 出力形式: 1. 分析メニューの実施有無と結果サマリ 2. 対応方法の候補と選定理由 3. 推奨対応方法（A-E） 4. 実装前の承認ポイント 5. 未確定事項（推測禁止） 使用テンプレート: - docs/wip/maintenance_analysis_menu.md - docs/wip/maintenance_change_plan.md 不明点は推測で埋めず、「未確定」として分離してください。
▼ 実行結果サンプルを見る (Claude Sonnet 4.6 で実行) 
# 既存システム分析結果 — 勤怠管理システム「TimeTrack Pro」
## 対象改修
「月末締め処理でパートタイマーの深夜割増が正しく加算されない」
(問い合わせ番号: INQ-2026-0338)

---

## 1. 分析メニューの実施有無と結果サマリ

| # | 分析メニュー | 実施 | 結果サマリ |
|---|---|---|---|
| 1 | 業務仕様差分             | 実施  | 2024-10 の法改正対応時に割増率テーブルを追加したが、パート契約区分の分岐が追従していない。仕様書 `spec/payroll/05_night_premium.md` と実装が乖離。 |
| 2 | 画面・導線分析           | 不要  | 本件は画面起因ではなくバッチ処理起因のため対象外。 |
| 3 | API契約分析              | 実施  | `/payroll/calc` の契約変更は無し。入出力スキーマは維持されている。問題は Service 層。 |
| 4 | DB/SQL分析               | 実施  | `attendance_records` の `employment_type='part'` 行に対して `night_premium_rate` が `NULL` で結合されており、COALESCE 未使用。影響件数: 2026-03 締め分で 1,842 行。 |
| 5 | バッチ/ジョブ分析        | 実施  | 月末締めバッチ `batch_payroll_close` のステップ 3「割増計算」で問題発生。再実行は冪等だが、訂正差分発生時の再計算ロジックが未検証。 |
| 6 | 障害・問い合わせ分析     | 実施  | 2026-02 / 2026-03 の 2 回連続で同一事象。2026-02 は手修正で回避していたため今回初めて表面化。 |

## 2. 対応方法の候補と選定理由

| 案 | 概要 | メリット | デメリット | 採否 |
|---|---|---|---|---|
| A. 緊急障害対応 | 2026-03 分を手修正し、4 月以降に本改修 | 即時復旧可 | 恒久対応が先送り | ×  |
| B. 小規模改修   | Service 層の SQL に COALESCE 追加 + 単体テスト | 影響最小・1 日工数 | 契約区分追加時に再発リスク | ◎ 推奨 |
| C. 中規模改修   | 割増計算を Strategy パターンに分離 | 将来の契約区分追加に強い | 3 日工数・回帰テスト広範 | △ |
| D. 技術負債解消 | 給与計算モジュール全面リファクタ | 根本解決 | 2 週間工数 + 税務検証必須 | × |
| E. 調査継続     | 追加ログ採取して次月判断 | リスク最小 | 4 月末締めに間に合わない | × |

## 3. 推奨対応方法
**B. 小規模改修**

理由:
- 4 月末締め (2026-04-30) まで 19 日しかない
- 影響範囲は `PayrollCalcService#calculateNightPremium` の SQL 1 箇所
- テスト観点が明確 (契約区分 × 深夜時間帯の 4 象限)
- C 案は将来検討 (技術負債チケットとして起票)

## 4. 実装前の承認ポイント
1. **SQL 改修の影響がパート契約以外に及ばないこと** (正社員・契約社員の計算結果不変)
2. **2026-02 / 2026-03 の手修正済みデータへの遡及再計算を行わない方針** の確認
3. 単体テストで既存 8 ケースが全て green のまま、パート深夜 4 ケースを追加
4. 本番反映は月末締め前日 (2026-04-29) ではなく 1 週間前 (2026-04-22) に前倒し

## 5. 未確定事項 (推測禁止)
- [ ] 2024-10 の法改正時、なぜパート契約の分岐が追従しなかったか (当時の議事録未発見)
- [ ] `night_premium_rate` が NULL のまま運用されていた期間 (2024-10 〜 2026-01 の 16 ヶ月) に別障害が埋もれていないか
- [ ] 訂正差分発生時の再計算ロジック未検証部分 (別チケット化するか本件に含めるか)

---
使用テンプレート: `docs/wip/maintenance_analysis_menu.md` / `docs/wip/maintenance_change_plan.md`
次アクション: 本分析結果を元に B 案の修正チェックリストを作成 (→ 「保守開発の修正チェックリスト作成」プロンプトへ)
既存コード起点の影響範囲分析
変更対象ファイルと依存先を漏れなく洗い出す
▼
対象不具合/改修: 【記入】 次の順で影響範囲を分析してください。 1. 変更起点ファイルを特定 2. 呼び出し元・呼び出し先を列挙 3. 関連SQL・テーブル・APIを特定 4. 画面影響（表示・入力・導線）を整理 5. テスト影響（既存テスト修正 / 追加テスト）を整理 出力形式: - 直接影響（必須修正） - 間接影響（確認必須） - 非影響（理由付き） - リスク（高/中/低） - 先行調査不足（追加で必要な調査） 使用テンプレート: - docs/wip/maintenance_impact_analysis.md 最後に、実装前チェックリストを5項目で提示してください。
分析結果から対応方法を決定（汎用）
分析結果を根拠に A-E の方式を1つ選ぶ
▼
analysis_menu の結果を使って、実装方式を1つ決定してください。 入力: - docs/wip/maintenance_analysis_menu.md - docs/wip/maintenance_impact_analysis.md 選定ルール: - 即時復旧が最優先なら A（緊急障害対応） - 変更点が限定的なら B（小規模改修） - 複数層に影響するなら C（中規模改修） - 構造的改善が主目的なら D（技術負債解消） - 情報不足なら E（調査継続） 出力: 1. 候補方式（2つまで） 2. 推奨方式（1つ）と選定理由 3. 採用しない方式の理由 4. 採用方式の実装・テスト・リリース方針 5. 必要承認（実装前/リリース前） 結果は docs/wip/maintenance_change_plan.md に反映可能な形式で出力してください。
保守対応方法テンプレート（汎用）
改修タイプに応じた進め方を標準化する
▼
保守対応を進めます。以下の対応タイプから最適な方式を選び、理由を示してください。 対応タイプ: A. 緊急障害対応（最小差分・即時復旧優先） B. 小規模改修（既存設計踏襲・影響最小） C. 中規模改修（責務整理を含む改修） D. 技術負債解消（段階移行・互換性維持） E. 調査継続（実装保留・追加情報待ち） 選定後の進め方: 1. 分析結果サマリ 2. 対応方式と選定理由 3. 実装方針（変更方針 / 変更禁止 / ロールバック） 4. テスト方針（正常 / 異常 / 回帰） 5. リリース方針（段階適用、監視、切り戻し条件） 使用テンプレート: - docs/wip/maintenance_change_plan.md - docs/wip/maintenance_rollback_plan.md 制約: - 既存ルール（security/ui/prohibited/api/logging）に必ず準拠 - 推測実装は禁止 - 実装前に「人の承認ポイント」を明示
マイグレーション開始（完全版）
分析メニューから方式選定までを一気通貫で実施する
▼
マイグレーション開発を開始します。Claude Code または GitHub Copilot で、次の順で進めてください。 1. docs/migration/common/migration_program_inventory.md を作成 2. docs/migration/common/migration_analysis_menu.md を埋める 3. 対応方法（A/B/C/D/E）を1つ選定し理由を明示 4. docs/migration/common/migration_architecture_gap.md を作成 5. 画面/API/データのマッピングを作成 制約: - 推測で断定しない - 未確定事項は分離する - レビュー未了成果物を次工程の正本にしない 出力: - 実施した分析メニュー - 推奨対応方式 - 次フェーズの着手条件
▼ 実行結果サンプルを見る (Claude Sonnet 4.6 で実行) 
# マイグレーション開始 — 実施結果

## 対象システム
地域中核病院向け看護支援システム「CareNote」
- 稼働環境: Windows Server 2012 R2 / IIS 8.5 / .NET Framework 3.5
- 画面層: VB.NET WinForms (ClickOnce 配信) 画面 68 本
- サーバ層: ASP.NET Web Forms (.aspx) + ASMX Web Service 42 本
- DB: SQL Server 2014 Standard (約 240 テーブル / 1.8TB)
- 外部連携: 電子カルテ HL7 (TCP), 検査機器 CSV 監視, 院内 LDAP
- 稼働開始: 2011年 / 最終大規模改修: 2017年

## 1. 実施した分析メニュー

| # | 分析項目 | 実施 | 主要な所見 |
|---|----------|------|-----------|
| 1 | 業務要件の再確認 | 済 | 看護記録・バイタル・与薬・転倒転落の4業務が中核 (docs/migration/common/migration_program_inventory.md 参照) |
| 2 | アーキテクチャギャップ | 済 | WinForms→Web化・ASMX→REST化・SQL Server 2022 移設の 3 本柱 |
| 3 | データモデル差分 | 済 | 主キーが手動採番のテーブル 37 本。連番管理テーブル廃止要件あり |
| 4 | 外部IF棚卸 | 済 | HL7 送受信モジュールが COM コンポーネントで実装 → 完全書き直し |
| 5 | 非機能 (監査・可用性) | 済 | 個人情報保護評価 (PIA) 実施必須。医療情報システム 3省2ガイドライン適合確認が必要 |
| 6 | 現行バグ・改修要望 | 未 | 本フェーズ対象外 (次フェーズで INQ 一覧を別軸で整理予定) |

## 2. 推奨対応方式

**採用: D. 技術負債解消（段階移行・互換性維持）**

### 比較表

| 方式 | 想定工数 | リスク | 評価 |
|------|----------|--------|------|
| A. 完全リライト | 18人月 | 極大 (医療停止リスク) | × |
| B. リホスト (OS/DB のみ刷新) | 4人月 | 中 (.NET 3.5 EOL が残る) | △ |
| C. リプラットフォーム | 10人月 | 大 | △ |
| **D. 段階移行 (Strangler Fig)** | **13人月** | **中** | **◎** |
| E. SaaS 置換 | 要調査 | 大 (独自業務フィット不可) | × |

### 移行先技術スタック (提案)
- 画面: Blazor Server (.NET 8) + MudBlazor
- API: ASP.NET Core Web API (.NET 8) + MediatR + FluentValidation
- DB: SQL Server 2022 (スキーマは段階的に正規化)
- 外部IF: NHapi ライブラリで HL7 再実装、ファイル監視は Worker Service 化
- 認証: Windows 認証継続 + 将来 Azure AD 連携余地を残す
- CI/CD: GitHub Actions + self-hosted runner (院内ネットワーク要件)

### 移行順序 (Strangler Fig パターン)
1. Phase 1 (2ヶ月): 共通基盤 (認証・ログ・監査) を新 API 化、旧画面から REST 呼び出しへ差し替え
2. Phase 2 (4ヶ月): 参照系画面 24 本を Blazor へ。この段階では書込は旧システムへプロキシ
3. Phase 3 (5ヶ月): 更新系画面 38 本を Blazor へ。HL7 送受信を新基盤へ段階切替
4. Phase 4 (2ヶ月): 旧 ASMX / WinForms を段階廃止、データ移行と並行稼働終了

## 3. リスクと未確定事項 (推測禁止)

### 特定済みリスク
- **R1 (大):** 夜勤帯 0-6時は検査機器 CSV が秒間 5 件発生。並行稼働中の二重書込防止方式は未決
- **R2 (中):** 旧 COM コンポーネントのソースが一部散逸 (3 モジュール)。リバースエンジニアリング工数が上振れする可能性
- **R3 (中):** SQL Server 2014 → 2022 で廃止された互換性レベル 100 の SQL が 12 箇所存在

### 確認が必要な事項 (社長判断待ち)
1. 並行稼働期間中の DB 構成 (旧 DB 継続 vs リアルタイム双方向同期) をどちらにするか
2. 医療情報取扱事業者の BCP 要件上、切替はどの月 (年度末回避) が許容されるか
3. 旧 WinForms の ClickOnce 証明書失効日 (2027-03) を意識した期限設定が必要か

## 4. 次フェーズの着手条件
- 未確定事項 1-3 のいずれか 2 つ以上が確定していること
- docs/migration/common/migration_architecture_gap.md が院内情報システム委員会のレビューを通過していること
- Phase 1 対象モジュール 8 本のテスト環境が整備済みであること

以上の分析は現時点の情報に基づくものであり、実装着手前に各フェーズで再検証を行います。
既存資産棚卸し（レガシー解析）
VB6/VB.NET/C#.NET の資産を漏れなく整理する
▼
既存システムの棚卸しを行ってください。 対象: - 画面 - 外部IF/API - バッチ - 帳票 - テーブル 出力先: - docs/migration/common/migration_program_inventory.md 併せて、移行優先度（高/中/低）を設定し、理由を記載してください。
画面/API/データマッピング作成
移行対象の対応表を作って実装の土台を固定する
▼
次の3つのマッピングを作成してください。 1. 画面マッピング - docs/migration/common/migration_screen_mapping.md 2. API/外部IFマッピング - docs/migration/common/migration_api_mapping.md 3. データマッピング - docs/migration/common/migration_data_mapping.md 要件: - 互換方針（再構築/統合/廃止）を明記 - 変換ルールと検証方針を明記 - 未確定項目は TODO として分離
段階移行・並行稼働計画
大規模移行での安全性を確保する
▼
大規模移行を前提に、段階移行計画を作成してください。 作成対象: - docs/migration/common/migration_test_strategy.md - docs/migration/common/migration_cutover_plan.md - docs/migration/common/migration_rollback_plan.md - docs/migration/common/migration_risk_register.md 必須: - 並行稼働期間と比較観点 - Go/No-Go 判定基準 - 切戻しトリガーと手順 - リスクのオーナーと状態
シナリオ別実装ブリーフ生成
選択した移行シナリオに合わせて作業指示を固定する
▼
選択したシナリオのテンプレートを読み、実装ブリーフを作成してください。 対象: - docs/migration/scenarios/{scenario}/project_info_migration.md - docs/migration/scenarios/{scenario}/source_system_profile.md - docs/migration/scenarios/{scenario}/target_system_blueprint.md - docs/migration/scenarios/{scenario}/migration_work_breakdown.md 出力: - フェーズ別タスク - 変更対象ファイル - 完了条件 - レビュー観点 不明点は推測せず、判断待ちとして分離してください。
仕様書作成（質問フェーズ）
不足情報を先に洗い出し、推測実装を防ぐ
▼
詳細設計書の作成前に質問フェーズを実施してください。 参照: - docs/samples/spec/00_common_rules.md - docs/samples/spec/01_ask_questions.md 依頼内容: 1. 添付Controllerを読み、設計書完成に不足している情報を質問化 2. 質問は優先度（高/中/低）付き 3. 「どの章を埋めるための質問か」を併記 4. 推測で断定せず、TODO候補として整理 出力は「質問一覧」のみ。本文生成は行わないでください。
仕様書作成（生成フェーズ）
テンプレ準拠で1機能1ファイルの詳細設計書を生成する
▼
詳細設計書を生成してください。以下を必ず参照します。 参照: - docs/samples/spec/00_common_rules.md - docs/samples/spec/02_generate_design.md - docs/samples/spec/03_template.md 入力: [INPUT] MODE=NEW ControllerFQCN=【記入】 UrlPrefix=【記入】 ExistingDesignDocExists=false [/INPUT] 制約: - 1機能=1ファイル - 根拠のない断定禁止（不足はTODO） - 章立てはテンプレ準拠 - 出力はMarkdown全文（上書き可能な全量）
▼ 実行結果サンプルを見る (Claude Sonnet 4.6 で実行) 
# INPUT 記入例
```
[INPUT]
MODE=NEW
ControllerFQCN=com.stockmate.customer.web.CustomerSearchController
UrlPrefix=/customer/search
ExistingDesignDocExists=false
[/INPUT]
```

---

# 顧客検索画面_詳細設計書.md

## 1. 機能概要
BtoB 受注管理 SaaS「StockMate」の顧客検索画面。営業担当が取引先 (法人・個人事業主)
を複数条件で検索し、受注登録・与信確認・訪問履歴参照の起点とする。

## 2. 利用者 / 業務価値
- 主利用者: 営業担当 (権限: `sales.read`)
- 副利用者: 経理担当 (権限: `accounting.read`)
- 業務価値: 取引先検索の平均操作時間を 45 秒 → 10 秒に短縮

## 3. 画面レイアウト
| 区分 | 項目 | 型 | 必須 | 備考 |
|---|---|---|---|---|
| 入力 | 顧客コード | text(8) | × | 前方一致 |
| 入力 | 顧客名     | text(60) | × | 部分一致 (漢字/カナ/英) |
| 入力 | 業種       | select  | × | 業種マスタ参照 |
| 入力 | 取引ステータス | select | × | active / hold / closed |
| 入力 | 登録日 From / To | date | × | 範囲検索 |
| ボタン | 検索 / クリア / 新規登録 | — | — | 新規登録は `sales.write` のみ活性 |
| 結果 | ページング | 20 件 / ページ | — | 最大 5000 件まで |

## 4. 画面遷移
```
[メインメニュー] ─▶ [顧客検索] ─┬─▶ [顧客詳細] ─▶ [受注登録]
                                ├─▶ [顧客新規登録]
                                └─▶ [CSV エクスポート]
```

## 5. API 契約
### 5.1 検索 API
- エンドポイント: `GET /customer/search`
- Controller: `com.stockmate.customer.web.CustomerSearchController#search`
- リクエスト (クエリパラメータ):
  | 項目 | 型 | 必須 | 制約 |
  |---|---|---|---|
  | code     | string | × | 最大 8 文字 |
  | name     | string | × | 最大 60 文字 |
  | industry | string | × | 業種コード |
  | status   | enum   | × | active / hold / closed |
  | from     | date   | × | ISO8601 |
  | to       | date   | × | ISO8601 / from <= to |
  | page     | int    | × | 1 以上 / 省略時 1 |
  | size     | int    | × | 1-100 / 省略時 20 |

- 成功レスポンス (200):
  ```json
  {
    "total": 142,
    "page": 1,
    "size": 20,
    "items": [
      {
        "customer_id": "5f2b8c6a-...",
        "code": "C0001234",
        "name": "株式会社サンプル製作所",
        "industry": "製造業",
        "status": "active",
        "last_order_at": "2026-03-28"
      }
    ]
  }
  ```

- 業務エラー: なし (0 件ヒットは `items: []` で 200 返却)
- システムエラー: 5xx 時は共通エラーハンドラ経由

## 6. 業務ロジック
1. 認可チェック (`sales.read` または `accounting.read`)
2. テナント ID を JWT claim から取得
3. 検索条件を Specification パターンで組み立て
4. 論理削除 (`deleted_at IS NULL`) を暗黙条件に追加
5. ページング付き SELECT 実行
6. 監査ログ `audit_read` に検索条件を記録 (個人情報保護法対応)

## 7. 依存テーブル
| テーブル | 用途 | 操作 |
|---|---|---|
| customers | 本体 | SELECT |
| industries | 業種マスタ | SELECT |
| audit_read | 監査ログ | INSERT |

## 8. セキュリティ / 非機能
- 横串アクセス防止: テナント ID を WHERE 句に必須付与
- 個人情報: 顧客名は監査ログにハッシュで格納
- SLA: P95 800ms 以内 / 同時 200 req
- SQL インジェクション: Prepared Statement 必須

## 9. 例外処理
- 認可エラー: 403 `E_FORBIDDEN`
- 入力検証エラー: 400 `E_VALIDATION` + 項目別エラー
- DB タイムアウト: 503 `E_DB_TIMEOUT` + trace_id

## 10. テスト観点
1. 正常: 全条件指定 / 一部指定 / 無指定
2. 境界: size=1 / 100 / 101 (上限超過エラー)
3. 認可: sales.read なし → 403
4. テナント横串: 他テナント顧客が混入しないこと
5. 論理削除済み顧客が返却されないこと
6. 監査ログが毎回 INSERT されること

## 11. 実装ファイル構成 (予定)
- `CustomerSearchController.java` (受領済み)
- `CustomerSearchService.java`
- `CustomerSpecification.java`
- `CustomerSearchRequest.java` / `CustomerSearchResponse.java`
- `CustomerSearchControllerTest.java`

## 12. TODO / 未確定事項
- [ ] 業種マスタの多言語対応要否 (英語 UI 検討中のため)
- [ ] CSV エクスポート API は別仕様書に分離予定
- [ ] `last_order_at` のインデックス設計 (性能要件次第)
- [ ] 監査ログのハッシュアルゴリズム (SHA-256 前提だが未承認)
全PG一括作成（同粒度）
controller_program_ids.csv を基準に全PGを順次生成する
▼
全PGを同じ粒度で詳細設計書化します。 参照: - docs/samples/spec/controller_program_ids.csv - docs/samples/spec/00_common_rules.md - docs/samples/spec/02_generate_design.md - docs/samples/spec/03_template.md 進め方: 1. controller_program_ids.csv を読み、controller名の一覧を作成 2. 1 controller ごとに「質問フェーズ→生成フェーズ」を実施 3. ファイル名は「画面名_詳細設計書.md」を優先 4. 各PGごとに未確定事項を12章TODOへ記載 5. 生成完了後、未確定事項一覧を別表で集約 出力: - 生成対象PG一覧 - 生成済み/未生成の進捗 - 未確定事項サマリ
議事録の整理と宿題化
決定事項・未決事項・TODOを分離して残す
▼
以下の会議メモを整理し、議事録を作成してください。 要件: - 決定事項、未決事項、宿題（担当/期限付き）を分離 - 未確定情報は「確認待ち」として分離 - 次回会議で扱う論点を3件提案 出力形式: 1. 会議概要 2. 決定事項 3. 未決事項 4. 宿題一覧（担当/期限） 5. 次回アジェンダ案
週報の自動生成
メモから実施内容と課題を定型化する
▼
複数メモから週報を作成してください。 条件: - 実施内容、成果、課題、来週予定を分離 - 事実と見解を分ける - 数値がある場合は表にする 出力形式: - 今週の要約 - 実施内容 - 成果 - 課題 - 来週予定
社内通知文の標準化
対象者と実施事項が明確な通知文を作る
▼
以下のルール変更を社内通知文にしてください。 要件: - 対象者、適用日、変更理由を明確にする - 実施事項を箇条書きで示す - 問い合わせ先を明記する 出力: - 件名 - 本文 - FAQ（3件）
稟議書ドラフト作成
目的、費用、効果、リスクを揃えて申請文を作る
▼
以下情報から稟議書のドラフトを作成してください。 入力: - 目的 - 費用 - 効果 - リスク - 代替案 出力: - 背景 - 目的 - 投資対効果 - リスクと対策 - 承認依頼事項
契約レビュー論点抽出
法務・事業・技術の確認論点を整理する
▼
契約書案をレビューするため、論点を抽出してください。 観点: - 責任範囲 - 免責 - 知的財産 - 個人情報 - 解約条件 出力: - 条項番号 - 確認論点 - リスクレベル（高/中/低） - 確認先（法務/事業/技術）
問い合わせの優先度付け
P1/P2/P3で初動順を決める
▼
問い合わせ一覧を分類し、優先度を付けてください。 分類軸: - 影響範囲 - 緊急度 - 再現性 - 顧客影響 出力: - カテゴリ - 優先度（P1/P2/P3） - 一次対応テンプレート - 担当候補
Java / Spring Boot 実装依頼
ServiceとRepositoryの責務分離を強制する
▼
Java Spring Bootで機能を実装してください。 条件: - Controllerは入出力とバリデーションのみ - Serviceに業務ロジックを集約 - RepositoryはDBアクセス専任 - 例外は共通ハンドラーで統一 - SQLはパラメータ化し、DB定義に準拠 実装後、テスト観点と未確定事項を出力してください。
Java / Quarkus 実装依頼
起動速度と軽量性を重視した実装を行う
▼
Java Quarkusで機能を実装してください。 条件: - CDIでDIを統一 - RESTエンドポイントは契約（入力/出力）を先に固定 - DBアクセスはPanacheまたはRepositoryパターンで統一 - 例外は共通MapperでAPIエラー形式を統一 - テストはJUnit5 + RestAssuredで観点を提示 実装後、ネイティブ化対応の注意点も出力してください。
Java / Micronaut 実装依頼
コンパイル時DIを前提に構成を最適化する
▼
Java Micronautで機能を実装してください。 条件: - MicronautのDIと設定管理を利用 - Controllerに業務ロジックを置かずServiceへ集約 - DBアクセスはMicronaut DataまたはRepositoryで統一 - Validationは注釈ベースで統一 - テストはMicronaut Test + JUnit5で作成 実装後、設定ファイル（application.yml）の変更点を一覧化してください。
Java / Jakarta EE 実装依頼
標準仕様ベースで堅実なエンタープライズ実装を行う
▼
Java Jakarta EE で機能を実装してください。 条件: - Jakarta EE標準（JAX-RS / CDI / JPA）を優先して使用 - 業務ロジックはService層へ分離 - 例外はExceptionMapperでAPI応答形式を統一 - トランザクション境界は明示し、責務を固定 - テストはJUnit5で正常/異常/境界を作成 実装後、使用した Jakarta 仕様を一覧で出力してください。
Java / Vert.x 実装依頼
リアクティブ処理と非同期I/Oを前提に実装する
▼
Java Vert.x で機能を実装してください。 条件: - ノンブロッキングI/Oを前提に設計 - Event Loopをブロックする処理を禁止 - API契約（入力/出力/エラー）を先に固定 - DBアクセスはVert.x SQL Client/JDBC Clientで統一 - テストはVertx JUnit5で非同期観点を明示 実装後、ブロッキング処理回避の実装ポイントを列挙してください。
ASP.NET Core Web API 実装依頼
認証・認可とエラーハンドリングを標準化する
▼
ASP.NET Core Web APIで実装してください。 条件: - Controllerに業務ロジックを置かない - async/awaitで統一 - JWT認証・認可ポリシーを適用 - グローバル例外ハンドラーでエラー統一 - 監査ログに操作主体と結果を記録 生成コードは既存命名規則・禁止事項に準拠してください。
TypeScript（React）実装依頼
型安全・UI/UX・セキュリティを同時に担保する
▼
TypeScriptで画面とAPI連携を実装してください。 条件: - strictモード前提 - any禁止、unknownと型ガードを使用 - XSS対策として危険なHTML挿入を禁止 - 入力エラーはフィールド単位で表示 - ローディング中の二重送信を防止 完了時にアクセシビリティ確認結果も出力してください。
GitHub Copilot -- Agentモードで機能実装
Copilot Agent に段階的に実装を依頼する
▼
#codebase #file:rules/project_info.md #file:rules/coding_rules.md #file:docs/official/design/[対象機能の設計書].md 前提: GitHub Copilot Chat (Agent Mode / 2026-04 時点) - VS Code または JetBrains 拡張の Agent Mode を ON にした状態で実行 - Multi-file edits と Workspace 参照 (#codebase) を併用 - 必要に応じて `/new` `/fix` `/tests` `/explain` スラッシュコマンドを補助利用 依頼内容: 上記の設計書とルールファイルを参照して、この機能を実装してください。 条件: - 実装は Service レイヤーから開始し、Controller → 単体テスト → 結合テストの順に段階コミット - Agent Mode の Multi-file edits で関連ファイルを同時編集してよい - 不明点は推測せず、質問として列挙（Agent Mode の確認プロンプトでも可） - 既存のコーディング規約（命名・例外処理・ログ出力）を厳守 - 完了後、変更ファイル一覧 / テスト観点 / 未確認事項を `#terminal` のログ出力形式でまとめる 更新日: 2026-04-11 (Copilot Chat Agent Mode / #codebase 記法前提)
Claude Code -- コードベース全体分析
大規模プロジェクトの全体把握と改善提案
▼
このプロジェクトのコードベース全体を分析してください。 推奨モデル: Claude Opus 4.6 (claude-opus-4-6) — 1M context で 10万行超も一括把握 代替モデル: Claude Sonnet 4.6 (claude-sonnet-4-6) — 中規模 (10万行未満) ならコスパ優位 非推奨: Claude Haiku 4.5 (claude-haiku-4-5-20251001) — 全体把握には文脈不足 実行環境: - Claude Code (CLI / VS Code / JetBrains いずれか) - Normal モードで開始し、深掘り調査で Plan Mode に切替、適用は Auto-accept edits OFF 推奨 - 必要に応じて Sub-agent でレイヤーごとに並列分析 以下の観点で調査し、結果をまとめてください： 1. アーキテクチャの全体構成（レイヤー構成、依存関係、モジュール境界） 2. コーディング規約の遵守状況（rules/coding_rules.md との乖離） 3. セキュリティリスク（SQLインジェクション、XSS、ハードコードされたシークレット、依存CVE） 4. テストカバレッジの推定と不足箇所（Jacoco/Istanbul 等の計測値があれば併記） 5. 技術的負債の特定と優先度付け（P0-P3） 各項目について「現状」「リスク」「推奨アクション」の3列で整理してください。 推測で埋めず、確認が必要な事項は明示的に分離してください。 更新日: 2026-04-11 (Claude Opus/Sonnet/Haiku 4.6 世代前提) / 律監査対応 2026-04-11
⚠ モデル別 context 長の注意
1M context は Claude Opus 4.6 専用 の機能です。Sonnet 4.6 / Haiku 4.5 は通常 context (約 200K tokens 前後) となります。大規模コードベース (概ね 10 万行超 / 数十万 tokens 規模) を一括把握したい場合は Opus 4.6 を選択してください。正確な最大 context トークン数や料金は、実行時点の Anthropic 公式仕様を参照してください。
  • Opus 4.6: 大規模コードベース一括把握向け (1M context / 有料 tier)
  • Sonnet 4.6: 中規模向け (通常 context、コスパ優位)
  • Haiku 4.5: 軽量タスク向け (通常 context)
▼ 実行結果サンプルを見る (Claude Sonnet 4.6 で実行) 
# コードベース全体分析 — FleetLink

対象: 中堅物流企業向け配送追跡システム「FleetLink」(Spring Boot 2.7 / Java 11 / MySQL 8 / Vue 2 モノリポ)

## 0. 調査サマリ
- 総コード行数: 約 18.4 万行 (Java 12.1 万 / TS+Vue 4.8 万 / SQL 1.5 万)
- パッケージ数: 187 / エントリポイント数: 1 (モノリス)
- 依存ライブラリ: 94 個 (うち直接依存 41 個)
- 解析対象コミット: main @ a7f4e92 (2026-04-10)

## 1. アーキテクチャ全体構成

```
fleetlink/
├─ api/              Controller 層 (REST 42 エンドポイント)
├─ application/      UseCase (22 クラス) / DTO
├─ domain/           エンティティ (34) / ドメインサービス (11) / 値オブジェクト (8)
├─ infrastructure/   JPA Repository / 外部API クライアント / ファイル IO
├─ batch/            Spring Batch ジョブ 14 本
├─ config/           DI 設定 / セキュリティ設定
└─ web/              Vue SPA (dist は Spring から配信)
```

| 項目 | 現状 | リスク | 推奨アクション |
|------|------|--------|----------------|
| レイヤー分離 | 4層 (api/app/domain/infra) が概ね守られている | api → infra 直呼び出しが 17 箇所で発生 (依存逆転違反) | ArchUnit で自動検出ルールを追加、段階的に修正 |
| DI 構成 | Spring Bean が 340 個、プロファイル 3種 (local/stg/prod) | テスト用 Bean が prod プロファイルでも読み込まれる設定ミス 2件 | @Profile の appendix テストを導入 |
| モノリス性 | 単一 WAR デプロイ、起動時間 78 秒 | スケール単位が粗く、ピーク帯 (18-22時) の配車検索だけ拡張したい要件と不一致 | 配車検索ドメインのみ先行して独立サービス化を検討 |

## 2. コーディング規約の遵守状況

rules/coding_rules.md (社内規約) との乖離を静的解析した結果:

| 規約項目 | 違反件数 | 主な発生箇所 | 重要度 |
|----------|----------|--------------|--------|
| Controller に業務ロジック記述禁止 | 23 | ShipmentController (9), RouteController (7) | 高 |
| public フィールド禁止 (getter 経由) | 41 | legacy パッケージ配下 | 中 |
| Optional をフィールドに持たない | 6 | UserProfile, DriverStatus | 中 |
| SQL は Repository 層で完結 | 4 | ReportService が JdbcTemplate を直利用 | 高 |
| ログに個人情報を出さない | 12 | 配送先氏名・電話番号が INFO レベルで出力 | **極高** |

個人情報ログ出力は GDPR 相当の国内要件に抵触する可能性があるため最優先対応。

## 3. セキュリティリスク

| 種別 | 件数 | 代表例 | 深刻度 |
|------|------|--------|--------|
| SQL インジェクション疑義 | 2 | ReportService.buildQuery() で文字列連結 | 高 |
| ハードコードされたシークレット | 1 | application-local.yml に社内 S3 アクセスキー | 高 (要ローテ) |
| CSRF 対策漏れ | 3 | /api/internal/* の POST エンドポイント | 中 |
| 依存 CVE | 7 | jackson-databind 2.13.4 (CVE-2022-42003) 等 | 中-高 |
| CORS 設定 | 1 | origin=* が許可された本番プロファイル | 高 |

**確認が必要な事項:**
- application-local.yml のシークレットが過去に git 履歴に含まれていた可能性 (git log --all -p 要確認)
- 本番 CORS 設定は意図的 (外部連携あり) か設定ミスか、要ヒアリング

## 4. テストカバレッジ (推定)

| レイヤー | カバレッジ | 備考 |
|----------|-----------|------|
| domain | 78% | 値オブジェクトは十分 |
| application (UseCase) | 54% | 異常系テスト不足 |
| infrastructure | 31% | 外部API クライアントが未カバー |
| api (Controller) | 22% | MockMvc テストが 9 本のみ |
| batch | 12% | 単体テスト実質なし、手動確認依存 |

全体推定: 41% (Jacoco 未導入のため目視 + ファイル比率からの概算)

**未確認事項:** CI で Jacoco を導入しないと正確な数値は出せない。次アクションの筆頭候補。

## 5. 技術的負債と優先度

| 優先度 | 項目 | 工数見積 | 備考 |
|--------|------|----------|------|
| P0 | 個人情報ログ出力の除去 | 3日 | コンプライアンス |
| P0 | SQL インジェクション修正 | 2日 | セキュリティ |
| P1 | シークレット外部化 (Vault or AWS SM) | 5日 | 運用負債 |
| P1 | 依存 CVE 一掃 (Spring Boot 3.2 LTS へ) | 15日 | メジャー移行含む |
| P2 | Controller から業務ロジック引き剥がし | 20日 | 段階対応可 |
| P2 | batch のテスト整備 | 10日 | CI 導入と併走 |
| P3 | 配車検索ドメインの独立サービス化 | 要PoC | アーキ決定伴う |

## 6. 改善提案 (3ヶ月ロードマップ)

- Month 1: P0 3件を完了、Jacoco 導入、ArchUnit で依存ルール強制化
- Month 2: P1 シークレット外部化、Spring Boot 3.2 移行 PoC
- Month 3: P2 Controller リファクタ着手、batch テスト整備

## 7. 推測を避けた確認必須事項
1. application-local.yml のシークレットが本番 S3 に対して有効か / 無効化済か
2. 本番 CORS=* は外部パートナー要件によるものか設定ミスか
3. 配車検索の現状 RPS ピーク値 (独立サービス化の PoC 判断に必要)

以上、2026-04-10 時点のスナップショットに基づく分析です。実施判断は社内技術委員会でのレビューをお願いします。
Claude Code -- CLAUDE.md 最適化
プロジェクト固有のCLAUDE.mdを生成する
▼
このプロジェクトの構成を分析し、最適な CLAUDE.md を生成してください。 推奨モデル: Claude Sonnet 4.6 (claude-sonnet-4-6) — この用途は Opus 不要、Sonnet で十分かつコスト 1/3 代替モデル: Claude Haiku 4.5 (claude-haiku-4-5-20251001) — 既存 CLAUDE.md の軽微更新ならこちら 実行環境: - Claude Code (CLI / IDE 拡張) / Memory system と併用する前提 - 生成後は `/memory` でインデックス化して Sub-agent からも参照可能に 以下を含めてください： - プロジェクト概要（言語、フレームワーク、DB、アーキテクチャ、主要エントリポイント） - コーディング規約の要約（rules/coding_rules.md のエッセンス） - よく使うコマンド（ビルド、テスト、lint、デプロイ、ローカル起動） - 禁止事項（セキュリティルール、変更禁止ファイル、破壊的コマンド） - ディレクトリ構成の説明 - MCP サーバー接続設定の有無（DB / GitHub / Slack 等） - Sub-agent 呼び出しガイド（どのタスクをどの Agent に委譲するか） 既存の rules/project_info.md と rules/coding_rules.md の内容を反映し、 Claude Code (2026-04 版) が Plan Mode / Auto-accept edits / Sub-agent を最大活用できる形式で記述してください。 更新日: 2026-04-11 (Claude Code Memory system / MCP / Sub-agent 前提) / 律監査対応 2026-04-11
⚠ モデル別 context 長の注意
このタスクは Sonnet / Haiku でも十分動作しますが、「1M context」は Claude Opus 4.6 専用 の機能です。Sonnet 4.6 / Haiku 4.5 は通常 context (約 200K tokens 前後) となり、巨大なモノレポの一括解析には Opus 4.6 を推奨します。context 長の正確な値は実行時点の Anthropic 公式仕様を参照してください。
Amazon Q -- セキュリティスキャン実行
プロジェクト全体のセキュリティ診断を依頼する
▼
Scan this project for security vulnerabilities. Tool: Amazon Q Developer (CLI / IDE plugin, 2026-04) - Use the built-in /review command for AWS-optimized security scan - Combine with /test to auto-generate regression tests for each finding - IAM / S3 / Lambda / CloudFormation などの AWS リソース定義があれば AWS-native rule set を優先適用 Please check: 1. SQL injection risks in all database access code 2. Hardcoded secrets (API keys, passwords, tokens, AWS access keys) 3. Cross-site scripting (XSS) vulnerabilities 4. Insecure dependencies with known CVEs (including 2025-2026 advisories) 5. Infrastructure-as-Code misconfigurations (CloudFormation / CDK / Terraform) 6. AWS IAM over-privileged policies and public S3 bucket exposure For each finding, provide: - Severity (Critical / High / Medium / Low) - File and line number - Description of the vulnerability - Recommended fix with code example - CWE / CVE reference if applicable Output format: table per severity, plus a remediation checklist the team can track in Jira/Backlog. 更新日: 2026-04-11 (Amazon Q Developer /review /test 併用前提)
Amazon Q -- /transform で Java / .NET レガシー移行
Java 8/11/17 → Java 21 LTS / .NET Framework → .NET 8 の自動変換
▼
/transform を使用して、このプロジェクトを最新 LTS に移行してください。 前提 (2026-04 時点の Amazon Q Developer /transform 対応): - Java: 8 / 11 / 17 → **Java 21 LTS** への移行が主流 (17 は旧 LTS 扱い、21 は 2023-09 リリース後の本命) - .NET: .NET Framework 4.x → **.NET 8 / 9** への移行 (2025 に追加された機能、Windows ワークロードのクラウドリフト向け) - 併用推奨コマンド: /review (移行後のセキュリティ再スキャン) / /test (回帰テスト自動生成) 事前確認事項（いずれかを記入）： 【Java 案件】 - 現在の Java バージョン: [8 / 11 / 17] - ビルドツール: [Maven / Gradle] - Spring Boot バージョン: [2.7 / 3.x] - 目標: Java 21 LTS + Spring Boot 3.3 以降 【.NET 案件】 - 現在の .NET バージョン: [.NET Framework 4.6.2 / 4.7.2 / 4.8] - プロジェクト種別: [WinForms / WPF / ASP.NET MVC / Web Forms / WCF] - 目標: .NET 8 LTS (または .NET 9) への移行 変換後に確認すべき点： 1. deprecated API の代替が適切に行われているか 2. テストが全て通過するか（/test で追加生成された分を含む） 3. 新しい言語機能の活用余地 - Java 21: Records / Sealed Classes / Pattern Matching / Virtual Threads / Structured Concurrency - .NET 8/9: Primary Constructors / Collection Expressions / Required members / Native AOT 候補 4. 移行ログに残った手動対応項目 (MANUAL_ACTION_REQUIRED) の残件 5. 依存ライブラリのうち移行先 LTS で動作未確認のもの 更新日: 2026-04-11 (Java 21 LTS / .NET 8 LTS 前提)
Gemini Code Assist -- Google Cloud ネイティブ実装
GCP 統合を前提にした Vertex AI / BigQuery / Cloud Run 実装レビュー
▼
Google Cloud Platform 上で稼働する本機能の実装とレビューを Gemini Code Assist で支援してください。 前提: Gemini Code Assist (2026-04 時点) - 使用モデル: Gemini の最新世代 (正確なバージョン番号・context 長は実行時点の Google Cloud 公式ドキュメントを参照) - 実行環境: VS Code / JetBrains / Cloud Shell Editor / Android Studio の Gemini Code Assist 拡張 - Vertex AI 経由で企業向けエンタープライズ機能 (プライベート接続 / VPC-SC / 監査ログ) を有効化している想定 - 長コンテキストを活かし、複数ファイル + GCP IaC 定義 (Terraform / gcloud CLI スクリプト) を一括参照 依頼内容: 以下の観点で GCP ネイティブな実装レビューと改善提案を行ってください。 1. アーキテクチャ層 - Cloud Run / Cloud Functions (2nd gen) / GKE のいずれを選ぶべきか、ワークロード特性から判断 - BigQuery を分析基盤として使う場合のスキーマ設計 / パーティショニング / クラスタリング戦略 - Pub/Sub + Cloud Run による非同期処理パターンの適合性 - Vertex AI Pipelines / Workflows / Cloud Tasks のどれで長時間ジョブを組むか 2. IAM / セキュリティ層 - サービスアカウントの最小権限設計 (Workload Identity Federation を含む) - IAM 条件付きロール (Condition) の適用可否 - Secret Manager / KMS / VPC Service Controls の統合 - 監査ログ (Cloud Audit Logs) で追跡すべきイベントの列挙 3. 観測性・コスト - Cloud Logging / Cloud Monitoring / Cloud Trace の統合箇所 - BigQuery スキャン量の見積もりとコスト最適化 (パーティション絞り込み / マテリアライズドビュー) - Cloud Run の min/max instances と concurrency の推奨値算出根拠 4. Gemini Code Assist 固有の使いどころ - 長コンテキストを活かした「リポジトリ全体 + Terraform 定義」の一括参照 - Vertex AI Agent Builder / Agent Engine との連携余地 (正確なプロダクト名は Google Cloud 公式を参照) 出力条件: - 各項目について「現状の想定」「GCP 推奨パターン」「改善アクション」の3列で整理 - 不明点は推測せず「要確認」として列挙 - モデル / 機能の正確な仕様・上限値・料金は実行時点の Google Cloud 公式ドキュメントを参照する旨を明記 更新日: 2026-04-11 / 初版作成 (Gemini Code Assist / Vertex AI 前提)
⚠ Gemini モデル名・仕様は流動的
Gemini ファミリーは世代更新が速いため、本プロンプトでは具体的なモデル名・context 長・料金を断定していません。実行時点の Google Cloud 公式ドキュメント (Vertex AI / Gemini Code Assist) を必ず参照してください。エンタープライズ利用では Vertex AI 経由 + VPC-SC / Workload Identity Federation が推奨される点にも注意。
ChatGPT (Codex / GPT-4o 系) -- 対話型ペアプログラミング
Function Calling / Custom GPTs を活かした対話型実装支援
▼
ChatGPT で対話型ペアプログラミングを行います。以下の機能を段階的に実装しつつ、設計判断の根拠を毎ターン言語化してください。 前提: ChatGPT (2026-04 時点) - 使用モデル: OpenAI の最新世代 (GPT-4o 系 / Codex 系の正確なモデル ID・context 長は実行時点の OpenAI 公式ドキュメントを参照) - 実行環境: ChatGPT Web / Desktop / API (Assistants API または Responses API) のいずれか - Function Calling / Tool Use / Code Interpreter / File Search を有効化できる環境を想定 - Custom GPTs を社内ナレッジ (設計書・コーディング規約) で事前構築している場合はそれを指定 依頼内容: 1. 仕様の確認フェーズ (対話 1-2 ターン) - 与えた設計書のうち曖昧な箇所を列挙し、質問で確認してから着手する - 既存コードとの整合性で気になる点を先に指摘 2. 実装フェーズ (対話 3-N ターン) - Service → Controller → テストの順に段階実装 - 各ターンで「今書いたコード」「次にやること」「判断根拠」を明示 - Function Calling / Tool Use を活用する場合は、呼び出す関数のスキーマ (JSON Schema) も提示 3. レビューフェーズ (最終ターン) - 差分サマリ / 未対応事項 / テスト観点を箇条書きでまとめる ChatGPT 固有の活かし方: - **Custom GPTs**: 社内コーディング規約・設計テンプレートを事前に読み込ませた専用 GPT を作り、コンテキストを毎回貼らずに済ませる - **Function Calling / Tool Use**: 外部 API (Jira / GitHub / 社内 DB) を叩く工程は関数定義を渡して自動呼び出しさせる - **Code Interpreter**: 生成コードの単体実行 / サンプルデータでの検証を GPT 側で実施 - **File Search (ベクトル検索)**: 仕様書 PDF / 過去 PR 履歴を添付し、根拠付き回答を引き出す - **Agent SDK / Assistants 機能**: 長時間タスクや複数ステップ実行は専用フレームワーク側に寄せる (正確な SDK 名称・提供状況は OpenAI 公式を参照) Copilot / Claude Code との使い分け: - IDE 内の即時補完 → Copilot - 大規模コードベース全体把握 + パッチ → Claude Code (Opus 4.6) - 対話で設計判断を詰めたい / Custom GPTs で社内規約を常駐させたい → ChatGPT 出力条件: - 各ターンで「結論 → 根拠 → 次のアクション」の3段構成を守る - 推測で埋めず、不明点は質問として返す - モデル ID・料金・context 長・API 仕様は実行時点の OpenAI 公式ドキュメントを参照 更新日: 2026-04-11 / 初版作成 (ChatGPT Function Calling / Custom GPTs 前提)
⚠ OpenAI のプロダクト名・API は再編されることがある
OpenAI は「Codex」「GPT-4o」「Assistants API」「Responses API」「Agent SDK」等のブランド・API 体系を時期によって更新・統合しています。本プロンプトでは具体的な API 名を断定せず 「OpenAI 公式ドキュメントを参照」 で逃げています。実運用では実行時点の OpenAI Platform Docs を一次情報としてください。
ChatGPT Agent -- 自律タスク実行と承認ゲート設計
Web検索・コード実行・ファイル操作を組み合わせた長時間タスク
▼
ChatGPT の Agent モード (自律タスク実行) で以下のタスクを実施してください。 前提: ChatGPT Agent / Autonomous Task 実行機能 (2026-04 時点) - 実行モード: Web ブラウジング / コード実行 / ファイル操作 / 仮想環境操作 を組み合わせた自律実行 (正確な機能名・提供範囲は OpenAI 公式を参照) - 実行時間: 長時間 (数十分～数時間) を想定。人間承認ポイントを明示的に設ける - 安全策: 外部書き込み (メール送信・課金 API 呼び出し・git push) はすべて承認ゲート経由 タスク定義: 目的: [具体的な調査/実装/分析目的をここに記入] 成果物: [期待する成果物の形式: レポート / PR / データセット / スクリプト 等] 期限: [許容実行時間] 実行計画 (Agent 側で自動生成し、最初に提示してください): 1. ステップ分解 (5-15 ステップ程度) 2. 各ステップで使用するツール (Web検索 / コード実行 / ファイル読み書き / ブラウザ操作) 3. 人間承認が必要な分岐点の明示 (下記「承認ゲート」と対応させる) 4. 想定所要時間 5. 失敗時のロールバック手順 承認ゲート (以下の操作前には必ず人間に確認): - [GATE-1] 外部サイトへのフォーム送信・メール送信 - [GATE-2] ファイルの新規作成・既存ファイルの上書き (読み取りは承認不要) - [GATE-3] 外部 API の課金対象呼び出し - [GATE-4] git commit / push / PR 作成 - [GATE-5] 最終成果物の配布 / 公開 実行中の報告ルール: - 各ステップ完了時に「何をやったか」「次に何をやるか」「現在の自信度 (0-100)」を報告 - 予期しないエラー・想定外の入力に遭遇したら即停止して人間に質問 - Web検索結果は URL と取得日時を併記し、一次情報かどうかを明示 出力条件: - 推測で埋めず、根拠不明な事項は確認待ちとして停止 - 実行ログはコピペ可能な形式でまとめる - 最終レポートに「実行したステップ一覧」「承認ゲート通過記録」「未達事項」を明記 更新日: 2026-04-11 / 初版作成 (ChatGPT Agent / 自律タスク実行前提)
⚠ Agent 系機能は提供範囲・安全策が変動しやすい
自律実行機能は OpenAI 側の利用規約・安全ガードレール・課金体系が頻繁に更新されます。本プロンプトの「承認ゲート」設計はベストプラクティスの一例であり、実運用では 実行時点の OpenAI 公式ガイドライン と社内セキュリティポリシーの双方を確認してください。特に GATE-3 (課金) / GATE-4 (git push) は gkAgent 内規でも 🔴 REDリスト (LINE 承認必須) に相当する操作です。
5ツール比較 -- 同じタスクを異なるツールで実行
Copilot / Claude Code / Amazon Q / Gemini / ChatGPT の使い分け実例
▼
【共通タスク】ユーザー認証機能のコードレビュー 検証環境: 2026-04 時点の各ツール最新版で動作確認 ツール選定の指針: - **ピンポイントのファイル単位レビュー** → GitHub Copilot Chat (Agent Mode OFF でも可) - **フロー全体の把握 + パッチ生成** → Claude Code (Opus 4.6 / Plan Mode 推奨) - **AWS 環境での自動スキャン + CI 統合** → Amazon Q Developer /review - **GCP 環境ネイティブのレビュー + 長コンテキスト一括把握** → Gemini Code Assist - **対話で設計判断を詰める / Custom GPTs 常駐 / 自律エージェント** → ChatGPT ■ GitHub Copilot Chat で実行する場合 (2026-04 版 #codebase 記法): #codebase #file:src/auth/AuthService.java このファイルのセキュリティ上の問題点を指摘してください。 特にパスワード処理、トークン管理、セッション管理の観点で確認してください。 必要であれば `/fix` で修正パッチを提示してください。 → 強み: IDE 内で即座にインライン修正、Multi-file edits で周辺ファイルも連動変更可 → 弱み: 大規模全体把握は不得手、AWS/GCP ネイティブ診断はできない ■ Claude Code で実行する場合 (推奨モデル: Claude Opus 4.6 / claude-opus-4-6): 認証機能全体（src/auth/ 配下）を Plan Mode で段階的にレビューしてください。 以下の観点で分析し、修正パッチまで生成してください： - OWASP Top 10: 2021 に基づくセキュリティチェック - 認証フロー全体の整合性確認（ログイン / ログアウト / トークン更新 / パスワードリセット） - テストカバレッジの評価と不足テストの生成 - Sub-agent で「脅威モデリング専任」と「テスト生成専任」を分担してもよい → 強み: 1M context で大規模コードベース一括把握、Plan Mode で変更前レビュー可能 → 弱み: クラウドプロバイダ固有のルールセットは持たない (AWS/GCP ネイティブ診断は別ツール) ■ Amazon Q Developer で実行する場合 (CLI / IDE plugin): /review src/auth/ Focus on authentication bypass, credential storage, session management vulnerabilities, and AWS Cognito/IAM misconfigurations if applicable. Then run /test to generate regression tests for each finding. → 強み: AWS ネイティブなルールセット、CI/CD 統合、CloudFormation/CDK 同時診断 → 弱み: AWS 外のクラウド (GCP/Azure) に対する専用ルールは限定的 ■ Gemini Code Assist で実行する場合 (Vertex AI 経由 / 2026-04): 以下のファイル群を長コンテキストで一括参照し、GCP ネイティブの観点でレビューしてください: - src/auth/ 配下の全ファイル - terraform/ 配下の IAM / Secret Manager / Cloud Run 定義 観点: - サービスアカウントの最小権限設計 / Workload Identity Federation 適用可否 - Secret Manager / KMS 統合の抜け漏れ - Cloud Audit Logs で追跡すべき認証イベント - Vertex AI / BigQuery 連携箇所の IAM スコープ → 強み: GCP ネイティブ統合、長コンテキストで IaC + アプリコードを一括参照可能 → 弱み: AWS 固有ルールは持たない、モデル世代更新が速く仕様参照が必須 ■ ChatGPT (GPT-4o 系 / Custom GPTs) で実行する場合: 社内コーディング規約 + OWASP Top 10 を読み込ませた Custom GPT に対し、 src/auth/AuthService.java のコードを貼り付けて対話的にレビュー。 Function Calling で Jira / GitHub の過去 Issue を引き、既知のバグパターンと突き合わせる。 Code Interpreter でサンプル入力に対する挙動を実行検証する。 → 強み: 対話型で設計判断を詰められる、Custom GPTs で社内ナレッジ常駐、Function Calling で外部連携 → 弱み: IDE への直接適用は弱い (コピペ運用が中心)、大規模コードベース一括把握は Claude Code に劣る ■ 5 ツールの使い分けまとめ | 観点 | Copilot | Claude Code | Amazon Q | Gemini | ChatGPT | |------|---------|-------------|----------|--------|---------| | 単一ファイル高速レビュー | ◎ | ○ | ○ | ○ | ○ | | 大規模コードベース全体把握 | △ | ◎ (1M context) | ○ | ◎ (長context) | △ | | IDE 直接統合 | ◎ | ◎ | ◎ | ◎ | △ (コピペ中心) | | AWS ネイティブ連携 | △ | △ | ◎ | △ | △ | | GCP ネイティブ連携 | △ | △ | △ | ◎ | △ | | CI / CD 統合 | ◎ (GH Actions) | ○ | ◎ | ○ (Cloud Build) | △ | | 対話型ペアプロ | ○ | ○ | △ | ○ | ◎ | | 自律エージェント実行 | ○ (Agent Mode) | ◎ (Sub-agent) | ○ | ○ | ◎ (Agent モード) | | 社内ナレッジ常駐 | △ | ◎ (CLAUDE.md) | △ | ○ | ◎ (Custom GPTs) | | パッチ生成品質 | ○ | ◎ | ○ | ○ | ○ | | ベストフィット用途 | IDE 内即時補完 | 大規模把握・計画 | AWS セキュリティ | GCP ネイティブ | 対話・自律実行 | ■ ベストフィット早見表 - **IDE で今すぐ書きたい** → Copilot - **リポジトリ全体を把握して計画から立てたい** → Claude Code (Opus 4.6) - **AWS 本番環境のセキュリティ診断を CI に組み込みたい** → Amazon Q - **GCP 本番環境の IAM / IaC を含めて長コンテキストで一気にレビューしたい** → Gemini Code Assist - **対話で設計判断を詰めたい / Custom GPTs に社内規約を常駐させたい / 自律エージェントで長時間タスク** → ChatGPT 更新日: 2026-04-11 (Claude 4.6 / Copilot #codebase / Amazon Q /review / Gemini / ChatGPT 5ツール対応) / 律監査対応 2026-04-11
⚠ 5 ツール比較表の読み方
本表は 2026-04 時点 の各ツール最新版の典型的な強み・弱みをまとめたものです。「1M context」は Claude Opus 4.6 専用、Gemini の長コンテキスト はモデル世代により上限が変動、ChatGPT の Agent モード は提供範囲が再編されることがあります。各ツールの正確な仕様・料金・context 長は実行時点の公式ドキュメント (Anthropic / GitHub / AWS / Google Cloud / OpenAI) を必ず参照してください。

mdファイルダウンロード

共通ルール（運用・ドキュメント・UI・セキュリティ・禁止事項・API・ログ監視）に加えて、 選択した言語テンプレート（project_info.md / coding_rules.md）と、 保守分析テンプレート、運用保守テンプレート、番外編テンプレート、仕様書作成の指示サンプルをまとめてダウンロードします。

ローカル表示時（file://）の場合： HTMLファイルをダブルクリックで開いている場合、ダウンロード機能が制限されることがあります。 その場合は VS Code の Live Server 拡張機能（セットアップガイド参照）でローカルサーバーを起動してください。

開発元言語/構成と、移行後言語/構成を選択すると、 マイグレーション分析・方式選定・設計差分・実装計画・切替/切戻しまで含む md セットをZIPで取得できます。

対応シナリオ： VB.NET WinForms / WebForms、C#.NET WinForms、VB6 Legacy から ASP.NET Core Razor / TypeScript React への移行

COBOL、RPG/AS400、PowerBuilder、Delphi、Classic ASP、Access/VBAなどのレガシー・ニッチ言語からの移行シナリオです。 市場需要調査に基づき、需要の高い順に収録しています（9パターン）。

共通ルール（常に同梱）

Security
認証・認可、入力検証、秘密情報管理、監査ログ、脆弱性対策を定義
UI/UX
一覧画面、入力フォーム、アクセシビリティ、レスポンシブ、エラー表示を定義
Prohibited
禁止事項とレビュー観点を明文化し、事故を未然防止
API / Logging
API契約、エラー設計、構造化ログ、監視・運用手順を統一
Maintenance Analysis
既存分析メニュー、影響範囲整理、変更計画、切り戻し計画を同梱
Spec Writing Samples
仕様書作成指示（共通ルール/質問/生成/テンプレート）を同梱