AIエージェントを用いた開発（バッチ処理編）

Last updated at 2026-05-14Posted at 2026-04-14

はじめに

個人開発用として、AIエージェントを使い始めました。
最初の頃は良かったのですが、やはり巷で言われているようにコンテキストが溜まるにつれてメンテ作業が多くなってきました。
色々考えた結果、結論としては 「気軽なアプリは気軽に作れるが、それなりのものを作る場合は、それなりの準備が必要。」 ということで、設計書などの管理も行うことにしました。基本的には差分管理で運用を行っています。

よくある失敗

よくある失敗では、下記などがあると思います。

意図したものと違うものが出来上がる。
一度に全てを行おうとして、コンテキストオーバーになる。
頼んでいないのにコーディングまで行って、間違ったものが出来上がる。
いつの間にかルールが膨れ上がって収集がつかなくなる。

方針

なので、下記の方針でルール設計を進めました。

設計書を作成して、細かく仕様を決める。
一度に全てを把握させない。
工程を分ける。
各工程ごとに確認工程を挟む。
管理は差分的に行う（一度に全てを把握させない）。
~~AIの「出来ます！」は信用しない。~~

要点

AIエージェントを使う上での重要な点は、下記の3つかなと思います。

1.仕様書の構造化
2.仕様書の差分管理
3.作業後のチェックリスト

1, 2については、一度に多くの情報を与えないための工夫になります。
3については、AIの作業も抜け漏れが発生するので、それを修正するための工夫になります。

ファイルの構成

AIエージェント向けの開発ルールは、共通ルールと各工程ルールに分けて管理しています。
1つのファイルに全てを書くのではなく、工程単位で分離することで、必要なタイミングで必要なルールだけを参照させる構成にしています。

GitHubはこちらです。

共通ルール1本と、9つの工程ファイルに分けています。

区分	ファイル名	役割	主な出力
共通ルール	`rules_dev.md`	開発全体の共通ルールを定義する。AIの役割、必ず守るルール、開発手順、各工程の対応ファイル名などをまとめる。	各工程の出力先定義
手順1	`rules_{dev}_1_request.md`	要件定義書を作成するためのルール。目的、対象範囲、入出力、実行要件、受入条件などを整理する。	`{filename}_v{n}.{m}_1_request.md`
手順2	`rules_{dev}_2_base.md`	基本設計書を作成するためのルール。処理概要、処理フロー、入力形式、出力形式、設定、特記事項などを定義する。	`{filename}_v{n}.{m}_2_base.md`
手順3	`rules_{dev}_3_base_confirm.md`	基本設計書の確認ルール。IDの整合性、タグ漏れ、仕様継承漏れ、入出力の整合性などを確認する。	`{filename}_v{n}.{m}_3_base_confirm.md`
手順4	`rules_{dev}_4_detail.md`	詳細設計書を作成するためのルール。メイン変数、メイン関数、関数単位の処理フローなどを定義し、JSONも出力する。	`{filename}_v{n}.{m}_4_detail.md` と `{filename}_v{n}.{m}_4_detail.json`
手順5	`rules_{dev}_5_detail_confirm.md`	詳細設計書の確認ルール。詳細設計の妥当性を確認し、確定版JSONを出力する。	`{filename}_v{n}.{m}_5_detail.json`
手順6	`rules_{dev}_6_code.md`	コード実装ルール。詳細設計とコードの対応付け、設計IDコメント、不変条件の確認などを定義する。	`{filename}_v{n}.{m}.{code_ext}`
手順7	`rules_{dev}_7_code_confirm.md`	コードの最終確認ルール。設計ID、JSON仕様、KEEP領域、動作確認まで含めたデプロイ前チェックを行う。	`{filename}_v{n}.{m}_7_code_confirm.md`
手順8	`rules_{dev}_8_spec.md`	仕様書（全体/差分）を作成するためのルール。	プロジェクト直下の`document`フォルダの `仕様_差分_v{n}.{m}.md` と `仕様_全体_v{n}.{m}.md`
手順9	`rules_{dev}_9_spec_confirm.md`	仕様確認のルール。	プロジェクト直下の`document`フォルダの `仕様確認_v{n}.{m}.md`

このように、共通ルールを起点にして、要件 → 設計 → 確認 → 実装 → 最終確認 → 仕様化 の流れでファイルを分割しています。
一度に全てをAIへ読ませるのではなく、その工程で必要なルールだけを参照させる前提です。

処理の概要

このルールでは、AIエージェントに一度に全てをやらせるのではなく、開発工程を段階的に分割して進めます。

要件定義書を作成する
基本設計書を作成する
基本設計書を確認する
詳細設計書を作成する
詳細設計書を確認する
コードを作成する
コードを確認する
仕様（差分/全体）を作成する
仕様確認を行う

この流れの狙いは、AIにいきなり実装までやらせないことです。
まず何を作るのかを整理し、その内容が妥当かを確認し、確認済みの設計に基づいて最後に実装へ進めます。
また、各工程の終了時に確認を挟むことで、途中段階での仕様ズレや破壊的変更を早めに検知しやすくしています。

補足

これはGASやPine Scriptのようにテスト自動化を入れづらい環境で、AIの暴走を防ぐために寄せた運用です。なので、実行環境がなく、テスト工程が含まれていません。

共通ルール

全体の進め方と、各工程で何を参照してよいかを定義するファイルです。

## 開発の共通ルール

### 概要

  開発の手順を以下に示します。

### あなたの役割

あなたは、定量分析とアルゴリズム実装のスペシャリストであるシニアエンジニアとして振る舞ってください。特に個別言語の制約や、バージョンアップ時のデグレ（先祖返り）に対して非常に厳しい視点を持ってレビューと開発を行ってください。

### 必ず守るルール
  - 共通ルール: `.rules/rules_common.md`

### 開発手順

  下記ファイルを順番に作成します。
  {filename}はコードファイル名、{n}はバージョン、{m}はリビジョンになります。
  該当する手順のルールファイルを参照しながら作成を行って下さい。
  - 参照可: 当該工程ルール、共通ルール、直前工程で承認済みの成果物
  - 参照不可: 未承認の途中成果物、他工程の未使用ルール

  開発を開始する前に、対象バージョンの格納フォルダを作成します。
  以降の手順1〜7で作成する成果物は、すべてこのフォルダ内に格納します。
  手順8〜9で作成する仕様書、および仕様確認結果は、コード単位ではなくプロジェクト全体を対象とするため、プロジェクト直下の`document`フォルダに格納します。

  フォルダ名は `{filename}_v{n}.{m}` とします。
  例: `alert_rci_v21.1`

  各手順が終わった時点でユーザに確認を取って下さい。
  手順1が終わったらユーザに確認を取り、問題なければ手順2に進みます。
  手順2が終わったらユーザに確認を取り、問題なければ手順3に進みます。
  以下、同様です。
  処理中に矛盾が見つかった場合は、処理を終了してユーザに報告して下さい。

  各ファイル作成後、ログを`.rules/log/rules_{dev}.log`に記述します。

  `{dev}`は設計書の種類を示しており、
  - batch : バッチ処理用の設計書
  - app   : アプリケーション用の設計書
  - class : クラス設計書

  があります。
  最初に、どの設計書を使用するかを確認して下さい。
  以降、その設計書を使用して設計を進めます。
  ルールファイルは、`.rules_v4/dev/{dev}/`フォルダにあります。

  |手順|種類|ルールファイル|出力ファイル名|
  |---|---|---|----|
  |1|要件定義書|rules_{dev}_1_request.md|{filename}_v{n}.{m}_1_request.md|
  |2|基本設計書|rules_{dev}_2_base.md|{filename}_v{n}.{m}_2_base.md|
  |3|基本設計書確認|rules_{dev}_3_base_confirm.md|{filename}_v{n}.{m}_3_base_confirm.md|
  |4|詳細設計書|rules_{dev}_4_detail.md|{filename}_v{n}.{m}_4_detail.md / {filename}_v{n}.{m}_4_detail.json|
  |5|詳細設計書確認|rules_{dev}_5_detail_confirm.md|{filename}_v{n}.{m}_5_detail.json|
  |6|コード|rules_{dev}_6_code.md|{filename}_v{n}.{m}.{code_ext}|
  |7|コード確認|rules_{dev}_7_code_confirm.md|{filename}_v{n}.{m}_7_code_confirm.md|
  |8|仕様|rules_{dev}_8_spec.md|document/仕様_差分_v{n}.{m}.md / document/仕様_全体_v{n}.{m}.md|
  |9|仕様確認|rules_{dev}_9_spec_confirm.md|document/仕様確認_v{n}.{m}.md|

各手順1 - 9の説明

手順1: 要件定義書

まず最初に、何を作るのか（なぜ作るのか、入出力は何か、運用はどうするか）を整理する工程です。

## 要件定義書

### 目的

バッチ処理やスクリプト処理を開始する前に、処理目的、入出力、実行条件、運用条件、受入条件を整理します。
この手順で作成した要件定義書を、以降の基本設計書、詳細設計書、コード実装の入力として扱います。

### 要件定義書の内容

下記を記述します。

|no|項目|説明|
|---|---|---|
|1|目的・背景|なぜ作るのか、何を自動化または処理するのかを記述します。|
|2|対象範囲|今回作成または修正する処理、ファイル、データ、連携先を記述します。|
|3|対象外|今回扱わない内容を明記します。|
|4|入力要件|入力ファイル、引数、環境変数、外部データ、前提データを記述します。|
|5|出力要件|出力ファイル、ログ、通知、更新対象、エラー出力を記述します。|
|6|実行要件|実行タイミング、再実行、冪等性、異常終了時の扱いを記述します。|
|7|制約条件|利用技術、既存仕様、ファイル構成、命名規則などの制約を記述します。|
|8|受入条件|完了判定に使う確認項目をチェックリスト形式で記述します。|
|9|未決事項|確認が必要な点、保留している判断、ユーザ確認が必要な点を記述します。|

### 作成手順

1. ユーザの依頼内容を分解し、曖昧な点を洗い出します。
2. 確認済みの内容、推測している内容、未確認の内容を分けて記述します。
3. 既存仕様を変更する場合は、[ADD] [MOD] [DEL] [KEEP] のタグを使って変更種別を明示します。
4. 未決事項がある場合は、基本設計へ進む前にユーザへ確認します。
5. 出力ファイル名は `{filename}_v{n}.{m}_1_request.md` とします。

手順2: 基本設計書

要件定義をもとに、処理フロー、入出力、設定を整理する工程です。

## 基本設計書

### 基本設計書の内容

  下記を記述します。

  |no|項目|説明|
  |----|----|----|
  |1|処理概要|処理の概要を記述します。|
  |2|処理フロー|処理の流れを記述します。処理単位ごとに`S001`の様なユニークIDを割り当てます。抜け漏れを防ぐためです。|
  |3|入力形式|入力データの形式を記述します。テーブル形式で書いて下さい。|
  |4|出力形式|出力データの形式を記述します。テーブル形式で書いて下さい。|
  |5|設定|設定内容を記述します。|
  |6|特記事項|その他特記事項があれば、記述します。|

### 基本設計書の作成手順

  下記の順番で作成します。

  1.最初にバージョンを上げるか、リビジョンを上げるか確認すること。下記を目安にすること。
  - version: 入出力仕様や外部挙動に影響する変更
  - revision: 非互換のない修正、補足、軽微変更

  2.前バージョンのファイルをコピーします。

  3.タグの付与: 各項目（処理フローの各ステップなど）の先頭に、必ず以下のタグを記述すること。

  ```
  [ADD]: 今回新規に追加する処理（緑色フォント併用）
  [MOD]: 既存の処理を変更する箇所（青色フォント併用）
  [DEL]: 廃止する処理（赤字・取り消し線併用）
  [KEEP]: 前バージョンから変更せず維持する重要な処理（黒字のまま）
  ```

  4.仕様継承の義務: 前バージョンの処理を省略せず、既存の全ての項目に [KEEP] [MOD] [DEL] のいずれかを付与して全文を維持すること。新規追加の項目には [ADD] を付与すること。[DEL] の項目は本文から削除せず、取り消し線付きで残し、実装対象からは除外する。

  5.集計レポートの出力: 設計書の末尾に、今回のタグごとの件数を集計した表（コンパイル・ダイジェスト）を必ず出力すること。
  
  レポートの例
  |タグ|件数|内容（要約）|
  |---|---|---|
  |[ADD]|2件|RCI期間設定の追加、ログ出力フラグの追加|
  |[MOD]|1件|アラート判定閾値の変更|
  |[DEL]|1件|不要になった旧描画ロジックの削除|
  |[KEEP]|12件|移動平均計算、UIカラー設定、etc...|

  6.抜け漏れを防ぐために、設計書の先頭に下記の様な仕様継承テーブルを記載して下さい。
   |仕様ID|状態|変更内容|ソース元|
   |---|---|---|---|
   |S001|維持|変更なし|v20_base|
   |S002|変更|青字の部分|v21_base|
   |S003|新規|緑字の部分|v21_base|


### 処理の流れ

  - 基本的には下記の様なコードを想定して、処理の流れを作成して下さい。

  - サンプルコード
    - 下記のようにメインとなる変数を関数単位で受け渡すように書くこと。
    - ローカル変数は適時使用すること。
    - コメントは詳細に書くこと。
    - 関数単位でログを出力できるようにすること。
    - ログ出力は `isOutputLog` 変数で設定できるようにすること。
    ```text
    //処理1
    def myFunkA(listA)

    //処理2
    def myFunkB_1(listB, param_1)
    def myFunkB_2(listB)

    //処理3
    def myFunkC(listC, param_2)

    //メイン処理
    def main()

        param_1 = "sample"
        param_2 = "sample"

        listA = ["a", "b", "c"]

        listB = myFunkA(listA)

        listC_1 = myFunkB_1(listB, param_1)
        listC_2 = myFunkB_2(listB)

        listResult = myFunkC(listC_1, listC_2, param_2)

    call main()
    ```

手順3: 基本設計書の確認

基本設計に抜け漏れや矛盾がないかを確認し、確認結果ファイルも出力する工程です。

## 基本設計書の確認

作成した基本設計書が、`.rules/dev/batch/rules_batch_2_base.md` の制約を満たし、かつ前バージョンからの変更を論理的に網羅しているかを、以下のチェックリストを用いて厳格に確認して下さい。

### 1. 形式・構造チェック
- [ ] **ファイル命名:** `{filename}_v{n}.{m}_2_base.md` の形式になっているか。
- [ ] **IDの整合性:** 全ての処理フローに `S001` から始まるユニークIDが欠かさず割り当てられているか。
- [ ] **タグの網羅:** 全ての項目に `[ADD]`, `[MOD]`, `[DEL]`, `[KEEP]` のいずれかのタグが付与されているか。
- [ ] **視覚装飾:** - [ADD] は緑色、[MOD] は青色、[DEL] は赤字＋取り消し線になっているか。
    - [KEEP] は装飾なし（黒字）のまま維持されているか。

### 2. 内容・論理チェック
- [ ] **仕様継承:** 前バージョンの仕様が一つも漏らさず（[KEEP] [MOD] [DEL] のいずれかで）記載されているか。
- [ ] **変更の妥当性:** ユーザからの修正依頼内容が、[ADD] [MOD] [DEL] として正しく反映されているか。
- [ ] **入出力の整合性:** 処理フローの変更に伴い、入力形式や出力形式に修正が必要な場合、それらも [MOD] で更新されているか。
- [ ] **矛盾の排除:** 新しく追加したロジックが、既存の [KEEP] されているロジックと衝突していないか。

### 3. コンパイル・ダイジェスト（集計表）の確認
- [ ] **数値の一致:** 本文中の各タグの出現回数と、末尾の集計レポートの件数が完全に一致しているか。
- [ ] **要約の正確性:** レポート内の「内容（要約）」が、実際の修正内容を端的に表しているか。

---

### 最終確認プロセス
上記のチェックを全てパスした場合のみ、「基本設計完了」としてユーザに承認を求めて下さい。
もし一つでも不備（IDの欠落、タグの付け間違い、数値の不一致など）が見つかった場合は、自律的に修正した上で再提示して下さい。
確認結果は、`{filename}_v{n}.{m}_3_base_confirm.md` としてファイル出力して下さい。

手順4: 詳細設計書

基本設計をもとに、関数単位まで具体化する工程です。

## 詳細設計書

### 詳細設計書の内容

  下記を記述します。

  |手順|項目|説明|
  |----|----|----|
  |1|処理概要|処理の概要を記述します。|
  |2|メイン変数|メインとなる変数を記述します。|
  |3|メイン関数|メインとなる関数を記述します。|
  |4|処理フロー|処理の流れを関数単位で記述します。処理単位ごとに`[L001]`の様なユニークなIDを割り当てます。実装段階でコードとの比較を行うためです。|
  |8|特記事項|特記事項があれば、記述します。|

### 詳細設計書の作成手順

  下記の順番で作成します。

  1.基本設計書と同じバージョン・リビジョンのファイルをコピーします。

  2.タグの付与: 各項目（処理フローの各ステップなど）の先頭に、必ず以下のタグを記述すること。

  ```
  [ADD]: 今回新規に追加する処理（緑色フォント併用）
  [MOD]: 既存の処理を変更する箇所（青色フォント併用）
  [DEL]: 廃止する処理（赤字・取り消し線併用）
  [KEEP]: 前バージョンから変更せず維持する重要な処理（黒字のまま）
  ```

  3.仕様継承の義務: 前バージョンの処理を省略せず、既存の全ての項目に [KEEP] [MOD] [DEL] のいずれかを付与して全文を維持すること。新規追加の項目には [ADD] を付与すること。[DEL] の項目は本文から削除せず、取り消し線付きで残し、実装対象からは除外する。

  4.集計レポートの出力: 設計書の末尾に、今回のタグごとの件数を集計した表（コンパイル・ダイジェスト）を必ず出力すること。
  
  レポートの例
  |タグ|件数|内容（要約）|
  |---|---|---|
  |[ADD]|2件|RCI期間設定の追加、ログ出力フラグの追加|
  |[MOD]|1件|アラート判定閾値の変更|
  |[DEL]|1件|不要になった旧描画ロジックの削除|
  |[KEEP]|12件|移動平均計算、UIカラー設定、etc...|

### 処理の流れ

  - 基本的には下記の様なコードを想定して、処理の流れを作成して下さい。

  - サンプルコード
    - 下記のようにメインとなる変数を関数単位で受け渡すように書くこと。
    - ローカル変数は適時使用すること。
    - コメントは詳細に書くこと。
    - 関数単位でログを出力できるようにすること。
    - ログ出力は `isOutputLog` 変数で設定できるようにすること。
    ```text
    //処理1
    def myFunkA(listA)

    //処理2
    def myFunkB_1(listB, param_1)
    def myFunkB_2(listB)

    //処理3
    def myFunkC(listC, param_2)

    //メイン処理
    def main()

        param_1 = "sample"
        param_2 = "sample"

        listA = ["a", "b", "c"]

        listB = myFunkA(listA)

        listC_1 = myFunkB_1(listB, param_1)
        listC_2 = myFunkB_2(listB)

        listResult = myFunkC(listC_1, listC_2, param_2)

    call main()
    ```

手順5: 詳細設計書の確認

実装前に、詳細設計の内容を確認し、確定版JSONを出力して固定する工程です。

## 詳細設計書の確認

- 作成した詳細設計書と、参照した前バージョンの詳細設計書を比較して、詳細設計書の仕様通りの修正が出来ているかを確認して下さい。
- 詳細設計の確認が完了したら、実装に入る前に、全仕様を以下の形式のJSONにコンパイル（出力）して下さい。<br>
  ファイル名は、`{filename}_v{n}.{m}_5_detail.json`とします。<br>
  実装コードはこのJSONの項目を1つも漏らさずカバーしなければなりません。

  ``` json
  {
    "version": "21.1",
    "features": [
      {"id":"L101","type":"KEEP","summary":"EMA計算処理を維持","targetFunction":"selectEma"},
      {"id":"L103","type":"MOD","summary":"アラート条件を変更","targetFunction":"updateAlertCondition"},
      {"id":"L104","type":"ADD","summary":"ログ出力切替を追加","targetFunction":"selectIsOutputLog"}
    ],
    "deleted_features": ["L099"],
    "constraints": ["request_limit_40"],
    "invariants": ["KEEPタグ部分の既存出力を変えない"]
  }
  ```

手順6: コード作成

確認済みの詳細設計と JSON をもとに、コードへ落とし込む工程です。

## コード設計書

  詳細設計書に沿ってコードを実装して下さい。
  また、下記ルールを守って下さい。
  開発方針で矛盾が見つかった場合は、ユーザに知らせて下さい。


### コード実装時の制約

- タグ照合: 実装を開始する前に、詳細設計確認で確定した `{filename}_v{n}.{m}_5_detail.json` にある [ADD] と [MOD] の全項目をリストアップし、それらが「コードのどこに対応するか」を宣言してから記述すること。

- 不変条件（Invariants）: [KEEP] タグが付いた箇所の既存ロジックが、意図せず書き換えられていないか、出力直前に再確認すること。

- **IDコメントの義務化:**
  - **[Lxxx] (必須):** 詳細設計の各ロジックの開始位置に `// [Lxxx]` を記載すること。
  - **[Fxxx] (必須):** 関数の**定義箇所（宣言部分）**の直前に `// [Fxxx]` を必ず記載すること。実装内での呼び出し箇所への記載は任意。
  - **[Vxxx] (必須):** メイン変数の**宣言・初期化箇所**に `// [Vxxx]` を必ず記載すること。更新・参照箇所への記載は、ロジックの明確化が必要な場合のみでよい。


### その他の開発ルール

  - 原因調査で分からないことなどがあれば、web検索で調べること。

  - 日本語の文字化けについて
    - PowerShell スクリプト（`.ps1`）に日本語を含める場合は、必ず UTF-8 with BOM で保存すること。
    - Windows PowerShell 5.x では BOM なし UTF-8 の `.ps1` が既定コードページで解釈され、文字化けすることがあるため、BOM なしで保存しないこと。
    - 日本語をファイルへ自動追記する処理を追加または修正した場合は、出力先ファイルで文字化け有無を必ず確認すること。

  - コードの最初に「更新日時」、「処理概要」、「前回バージョンとの違い」を詳細に記載すること。

  - 記法はキャメルケースを使用すること。

  - 命名規則は下記に沿うこと
    - 変数の命名規則
      |種類|プレフィックス|例|
      |------|-----|----|
      |リスト|list|listData|
      |マップ|map|mapUser|
    - 関数の命名規則
      |プレフィックス|意味|例|
      |-------|-----|----|
      |select |データを取得する|selectData()|
      |regist |データを登録する|registData()|
      |delete |データを削除する|deleteData()|
      |update |データを更新する|updateData()|
      |refresh|画面などを更新する|refreshUserTable()|

手順7: コード確認

最後に、設計・JSON・実装結果を突き合わせて、デプロイ前の最終確認を行う工程です。

## コード設計書の最終確認（デプロイゲート）

本工程では、実装されたコードが詳細設計および JSON コンパイル結果を完全に満たしているかを検証します。検証結果は必ず以下のファイルに出力して下さい。

**出力ファイル名:** `{filename}_v{n}.{m}_7_code_confirm.md`

---

### 1. トレーサビリティ・チェック（ID照合）
- [ ] **IDの存在確認:** 詳細設計確認で確定した `{filename}_v{n}.{m}_5_detail.json` に含まれる [ADD] [MOD] の全IDが、コード内のコメント `// [Lxxx]`, `// [Fxxx]`, `// [Vxxx]` として漏れなく記述されているか。
- [ ] **実装範囲の限定:** 詳細設計で定義されていない不要なロジックの追加や、意図しない箇所の書き換えが行われていないか。
- [ ] **KEEPの保護:** [KEEP] タグが付いた不変条件（Invariants）領域が、1文字の差分もなく維持されているか。

### 2. 品質・仕様チェック
- [ ] **JSONカバレッジ:** `{filename}_v{n}.{m}_5_detail.json` で定義された全ての機能・制約を 100% カバーしているか。
- [ ] **入出力整合性:** 基本設計で定義した入力形式および出力形式（ログ、表示、アラート等）が、期待通りに実装されているか。
- [ ] **コーディング規約:** `.rules/dev/batch/rules_batch_6_code.md` で指定された命名規則（プレフィックス等）やキャメルケースが遵守されているか。
- [ ] **エンコード確認:** PowerShell等の場合、適切なエンコード（UTF-8 with BOM等）で出力されているか。

### 3. 動作検証（実行確認）
- [ ] **文法エラー:** Pine Script エディタや各実行環境において、コンパイルエラーや構文警告が出ていないか。
- [ ] **実行ログ:** テスト実行時、詳細設計で定義した通りのログが出力されているか。
- [ ] **エッジケース:** 入力値が空、または異常な値の場合でもデッドロックやクラッシュが発生しないか。

---

### 確認結果のレポート形式
出力ファイル `{filename}_v{n}.{m}_7_code_confirm.md` には、以下の「最終判定レポート」を記述して下さい。

#### ■ 最終判定レポート
| 検証項目 | 判定 | 備考 |
| :--- | :---: | :--- |
| 設計IDの一致 (Traceability) | OK / NG | |
| JSON仕様の網羅 (Coverage) | OK / NG | |
| 不変領域の維持 (Invariants) | OK / NG | |
| 動作確認 (Execution) | OK / NG | |

**総合判定：[ 合格 / 不合格 ]**

---

### 完了条件
全てのチェック項目が [ ] から [x] になり、総合判定が「合格」となった場合のみ、本プロジェクトの完了を宣言して下さい。不備がある場合は、直ちに `.rules/dev/batch/rules_batch_6_code.md` に戻って修正を行って下さい。

手順8: 仕様

プロジェクト全体として、仕様（差分/全体）を文章化する工程です。

## 仕様書

  運用向けのシステム仕様を作成します。

### 出力ファイル

- プロジェクト直下に、`仕様_差分_v{n}.{m}.md`、および `仕様_全体_v{n}.{m}.md` を作成する。

### 作成手順

1. バージョン、およびリビジョンを新規作成するか、現状を修正するかは、事前に確認を取ること。
2. `仕様_差分_v{n}.{m}.md` に、前バージョンとの差分の仕様を記述すること（差分中心）。
3. `仕様_全体_v{n}.{m}.md` は、**必ず前バージョンの `仕様_全体_v{prev}.md` を全文コピーして作成**し、その上で今回差分を該当箇所へ追記・上書きすること（白紙から再構成しないこと）。
4. `仕様_全体_v{n}.{m}.md` に、システム全体の仕様を記述すること（差分要約にしない）。差分は `仕様_差分_v{n}.{m}.md` に集約し、全体仕様では「全体として読める形」で統合すること。
5. v2以降は v1 の構成を踏襲すること。v1 については作成前に必ず内容を提案すること。

### 禁止事項

- 仕様書はプロジェクト全体の仕様を扱うため、`仕様_差分_v{n}.{m}.md` と `仕様_全体_v{n}.{m}.md` を **コードファイル別のフォルダ**や**バージョン別成果物フォルダ**内に作成してはいけない。
- `仕様_全体_v{n}.{m}.md` を、差分要約（短縮版）として作成してはいけない。
- **省略禁止:** 前バージョンに存在する章・文章・表・例・注意点を削除してはいけない。削除が必要な場合は、章自体は残し「廃止」「削除理由」を明記すること。

手順9: 仕様確認

仕様書のチェックと、最終的な整合性確認を行う工程です。

## 仕様書の確認

プロジェクト直下に作成した `仕様_差分_v{n}.{m}.md` および `仕様_全体_v{n}.{m}.md` が、`.rules/dev/batch/rules_batch_8_spec.md` の制約を満たし、前バージョンからの仕様継承を漏れなく反映しているかを確認して下さい。

### 1. ファイル確認

- [ ] プロジェクト直下に `仕様_差分_v{n}.{m}.md` が存在すること。
- [ ] プロジェクト直下に `仕様_全体_v{n}.{m}.md` が存在すること。
- [ ] `仕様_差分_v{n}.{m}.md` および `仕様_全体_v{n}.{m}.md` が、コードファイル別のフォルダやバージョン別成果物フォルダ内に作成されていないこと。
- [ ] 前バージョンの `仕様_全体_v{prev}.md` を参照していること。

### 2. 差分仕様チェック

- [ ] `仕様_差分_v{n}.{m}.md` は、前バージョンとの差分のみを中心に記述していること。
- [ ] 追加、変更、削除、維持する重要仕様が区別できること。
- [ ] 手順1〜7で決定・実装した変更点が漏れなく含まれていること。
- [ ] 未確認事項や未実施の動作確認がある場合、その旨が明記されていること。

### 3. 全体仕様チェック

- [ ] `仕様_全体_v{n}.{m}.md` は、差分要約ではなくシステム全体の仕様になっていること。
- [ ] `仕様_全体_v{n}.{m}.md` が **前バージョンの `仕様_全体_v{prev}.md` を全文コピーしたものをベース**にしており、章・文章・表・例・注意点が理由なく欠落していないこと。
- [ ] 前バージョンの `仕様_全体_v{prev}.md` の章構成を踏襲していること。
- [ ] 前バージョンの全章が、維持・変更・削除のいずれかとして反映されていること。
- [ ] 前バージョンに存在したAPI、画面、データ、ログ、セキュリティ、運用注意点が理由なく欠落していないこと。
- [ ] 今回追加した仕様が、該当する章へ統合されていること。
- [ ] `仕様_差分_v{n}.{m}.md` と `仕様_全体_v{n}.{m}.md` の内容が矛盾していないこと。

### 4. 章構成比較

前バージョンと新バージョンの全体仕様について、章見出しを比較して下さい。

確認例:

```powershell
rg -n "^## " 仕様_全体_v{prev}.md
rg -n "^## " 仕様_全体_v{n}.{m}.md
```

確認項目:

- [ ] 章数が前バージョンと同等、または増加していること。
- [ ] 章名が前バージョンから理由なく削除されていないこと。
- [ ] 章順が前バージョンの構成を大きく崩していないこと。
- [ ] 新規章を追加した場合、追加理由が仕様上明確であること。

### 5. 内容継承チェック

以下の観点で、前バージョン全体仕様からの先祖返りや欠落がないか確認して下さい。

- [ ] 前バージョンで定義されていた目的・前提・対象範囲が継承されていること。
- [ ] 前バージョンで定義されていた画面、処理、機能、操作が継承されていること。
- [ ] 前バージョンで定義されていた入力、出力、データ形式、保存形式が継承されていること。
- [ ] 前バージョンで定義されていたAPI、イベント、外部連携、通信方式が継承されていること。
- [ ] 前バージョンで定義されていた設定、環境変数、実行環境、依存関係が継承されていること。
- [ ] 前バージョンで定義されていたログ、監視、確認方法、運用方法が継承されていること。
- [ ] 前バージョンで定義されていたエラー処理、制約、セキュリティ、注意点が継承されていること。
- [ ] 今回変更された仕様が、前バージョンの該当箇所へ上書きまたは追記されていること。
- [ ] 今回廃止された仕様がある場合、削除理由または廃止扱いであることが明記されていること。

### 6. 実装結果との照合

- [ ] 手順7のコード確認結果が仕様に反映されていること。
- [ ] 実装済みの内容が「未実装」と誤記されていないこと。
- [ ] 未実施の確認が「完了」と誤記されていないこと。
- [ ] Docker build、デプロイ、実ブラウザ確認など、未実施の検証は未実施として明記されていること。

### 7. 最終判定

以下を満たした場合のみ、仕様書確認完了とします。

- [ ] 差分仕様が前バージョンとの差分として妥当である。
- [ ] 全体仕様が前バージョンの構成と内容を継承している。
- [ ] 差分仕様と全体仕様に矛盾がない。
- [ ] 実装結果、未確認事項、既知の注意点が正しく反映されている。

不備がある場合は、`rules_batch_8_spec.md` に戻って仕様書を修正して下さい。

まとめ

最初は、ルールファイルに全てを記載していましたが、やはりルールも構造化して、必要な分のみ参照させる必要があるなと思いました。
一度に全部をAIへ渡すのではなく、工程ごとに必要な情報だけを見せて、都度確認を挟む方が、結果として安定した開発になると感じています。

今後

出力として、Mermaidで作成してフロー図などを作成しても良いかなと思います。また、各仕様書の確認自体もAIが行っても良いと思います。

参考

github : https://github.com/yuki746289/product_agent_rules

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up