1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@qiiChan(キーちゃん)

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

1
Last updated at Posted at 2026-04-14

はじめに

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

このルールを使って実際に開発した例は、別記事「AIエージェントで Pine Script を作ってみた」に掲載しています。

よくある失敗

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

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

方針

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

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

要点

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

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

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

ファイルの構成

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

GitHubはこちらです。

共通ルール1本と、通常開発の10工程ファイルに分けています。リポジトリでは .rules_v7 を最新版とし、別プロジェクトへ取り込む際は .rules として配置します。

区分 ファイル名 役割 主な出力
共通ルール rules_dev.md 通常開発、簡易開発、参照範囲、各工程の対応を定義する。 各工程の出力先定義
手順1 rules_{dev}_1_spec.md バージョン別フォルダにインデックス、差分仕様、項目別仕様書を作成する。 .document/v{n}.{m}/00_index.md、01_差分仕様.md、項目別仕様書
手順2 rules_{dev}_2_spec_confirm.md 仕様書だけを対象に、矛盾、欠落、仕様継承、変更一覧を確認する。 .document/v{n}.{m}/99_仕様確認.md
手順3 rules_{dev}_3_request.md 承認済み仕様から要件定義書を作成する。 {filename}_v{n}.{m}_3_request.md
手順4 rules_{dev}_4_base.md 基本設計書を作成する。 {filename}_v{n}.{m}_4_base.md
手順5 rules_{dev}_5_base_confirm.md 基本設計書を確認する。 {filename}_v{n}.{m}_5_base_confirm.md
手順6 rules_{dev}_6_detail.md 詳細設計書とJSONを作成する。 {filename}_v{n}.{m}_6_detail.md と {filename}_v{n}.{m}_6_detail.json
手順7 rules_{dev}_7_detail_confirm.md 詳細設計を確認し、実装用統合JSONを作成する。 {filename}_v{n}.{m}_7_detail.json
手順8 rules_{dev}_8_code.md 確認済み設計に基づいてコードを実装する。 {filename}_v{n}.{m}.{code_ext}
手順9 rules_{dev}_9_code_confirm.md コードと詳細設計の対応、動作、デグレを確認する。 {filename}_v{n}.{m}_9_code_confirm.md
手順10 rules_{dev}_10_final_confirm.md 仕様書、要件定義書、設計書、コードを突き合わせる。 {filename}_v{n}.{m}_10_final_confirm.md

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

処理の概要

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

  1. バージョン別フォルダにインデックス、差分仕様、項目別仕様書を作成する
  2. 仕様書だけを対象に矛盾や欠落を確認する
  3. 要件定義書を作成する
  4. 基本設計書を作成する
  5. 基本設計書を確認する
  6. 詳細設計書を作成する
  7. 詳細設計書を確認する
  8. コードを作成する
  9. コードを確認する
  10. 仕様書、設計書、コードを突き合わせて最終確認する

この流れの狙いは、AIにいきなり実装までやらせないことです。
まず仕様を文章として確定し、その仕様から要件と設計を段階的に作成して、確認済みの設計に基づいて実装へ進めます。
また、各工程の終了時に確認を挟むことで、途中段階での仕様ズレや破壊的変更を早めに検知しやすくしています。

簡易開発（quick_fix）

仕様を変更しない軽微な修正には、3工程の quick_fix を使用します。

  1. 修正内容の要件を整理する
  2. コードを修正する
  3. 要件、既存仕様、コード、動作確認結果を突き合わせる

quick_fix では仕様書を作成、変更、削除しません。仕様変更や仕様書修正が必要だと判明した場合は作業を停止し、ユーザ確認後に通常開発を手順1から開始します。

補足

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

各工程のルール本文（Markdown）は、.rules_v7 配下の md ファイルを そのまま全文掲載 しています。コードブロックではなくそのまま記述しているため、プレビューで表や見出しとして表示されます。ルール内のサンプルコードや JSON 例は、従来どおりコードブロックで掲載します。

共通ルール

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

出典: .rules_v7/dev/rules_dev.md

開発の共通ルール

概要

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

あなたの役割

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

必ず守るルール

  • 共通ルール: .rules/rules_common.md

開発種類

開発は、通常開発と簡易開発の2種類に分かれます。

  • 通常開発: 要件定義から設計、実装、確認までを段階的に行う開発です。開発種類として batch、app、class を使用します。
  • 簡易開発: 軽微な修正などを簡略化した手順で行う開発です。開発種類として quick_fix を使用します。

通常開発

下記ファイルを順番に作成します。
{filename}はコードファイル名、{n}はバージョン、{m}はリビジョンになります。
該当する手順のルールファイルを参照しながら作成を行って下さい。

  • 参照可: 当該工程ルール、共通ルール、直前工程で承認済みの成果物
  • 参照不可: 未承認の途中成果物、他工程の未使用ルール
  • 例外: 通常開発の手順10（最終確認）では、仕様書、手順1〜9で承認済みの全成果物、および各確認結果を参照可とします。

開発を開始する前に、対象バージョンの格納フォルダを作成します。
手順3〜10で作成する成果物は、すべてこのフォルダ内に格納します。
手順1〜2で作成する仕様書、および仕様確認結果は、コード単位ではなくプロジェクト全体を対象とするため、プロジェクト直下の.document/v{n}.{m}/フォルダに格納します。
.documentフォルダまたは対象バージョンのフォルダが存在しない場合は、仕様書を作成する前に作成します。
.documentフォルダはGit管理対象とします。空フォルダとして保持する必要がある場合は、.document/.gitkeepを作成します。

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

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

各ファイル作成後、ログを.rules/log/rules_{dev}.logに記述します。
ファイル作成時に気になることや懸念事項などあれば、質問して構いません。

{dev}は設計書の種類を示しており、

  • batch : バッチ処理用の設計書
  • app : アプリケーション用の設計書
  • class : クラス設計書（作成中）

があります。
最初に、どの設計書を使用するかを確認して下さい。
以降、その設計書を使用して設計を進めます。
ルールファイルは、.rules/dev/{dev}/フォルダにあります。
下記の10工程は app と batch に適用します。class の工程変更は保留とし、既存のclassルールに従って下さい。

手順 種類 ルールファイル 出力ファイル名
1 仕様書作成 rules_{dev}_1_spec.md プロジェクト直下の.document/v{n}.{m}/フォルダの 00_index.md、01_差分仕様.md、および項目別仕様書
2 仕様確認 rules_{dev}_2_spec_confirm.md プロジェクト直下の.document/v{n}.{m}/99_仕様確認.md
3 要件定義書 rules_{dev}_3_request.md {filename}_v{n}.{m}_3_request.md
4 基本設計書 rules_{dev}_4_base.md {filename}_v{n}.{m}_4_base.md
5 基本設計書確認 rules_{dev}_5_base_confirm.md {filename}_v{n}.{m}_5_base_confirm.md
6 詳細設計書 rules_{dev}_6_detail.md {filename}_v{n}.{m}_6_detail.md
{filename}_v{n}.{m}_6_detail.json
7 詳細設計書確認 rules_{dev}_7_detail_confirm.md {filename}_v{n}.{m}_7_detail.json
8 コード rules_{dev}_8_code.md {filename}_v{n}.{m}.{code_ext}
9 コード確認 rules_{dev}_9_code_confirm.md {filename}_v{n}.{m}_9_code_confirm.md
10 最終確認 rules_{dev}_10_final_confirm.md {filename}_v{n}.{m}_10_final_confirm.md

簡易開発

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

簡易開発は、軽微な修正、既存仕様の範囲内の不具合修正、文言修正、ログ修正、コメント修正、既存処理の小規模な条件変更などを対象とします。
仕様変更および仕様書の修正を伴う作業は対象外とし、通常開発を使用します。
簡易開発では仕様書を作成、変更、削除してはいけません。
簡易開発の指示があった場合は、こちらに沿って修正を行って下さい。

下記ファイルを順番に作成します。
{filename}はコードファイル名、{n}はバージョン、{m}はリビジョンになります。
該当する手順のルールファイルを参照しながら作成を行って下さい。

  • 参照可: 当該工程ルール、共通ルール、直前工程で承認済みの成果物
  • 参照不可: 未承認の途中成果物、他工程の未使用ルール
  • 例外: 簡易開発の手順3（コード確認）では、既存仕様書、手順1〜2で承認済みの全成果物、および動作確認結果を参照可とします。

簡易開発を開始する前に、対象バージョンの格納フォルダを作成します。
手順1〜3で作成する成果物は、すべてこのフォルダ内に格納します。

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

各手順が終わった時点でユーザに確認を取って下さい。
手順1が終わったらユーザに確認を取り、問題なければ手順2に進みます。
手順2が終わったらユーザに確認を取り、問題なければ手順3に進みます。
以下、同様です。
処理中に矛盾が見つかった場合は、処理を終了してユーザに報告して下さい。
仕様変更の必要性が判明した場合は作業を停止し、通常開発へ切り替えるかユーザへ確認して下さい。
ユーザが承認した場合のみ、通常開発を手順1から開始して下さい。ユーザの承認を得ずに切り替えてはいけません。

各ファイル作成後、ログを.rules/log/rules_quick_fix.logに記述します。
ファイル作成時に気になることや懸念事項などあれば、質問して構いません。

簡易開発では、app / batch 共通のルールとして .rules/dev/quick_fix/ フォルダ配下のルールファイルを参照します。

原則として、簡易開発を行う場合はリビジョンを上げます。

手順 種類 ルールファイル 出力ファイル名
1 修正内容の要件 rules_quick_fix_1_request.md {filename}_v{n}.{m}_1_request.md
2 コード修正 rules_quick_fix_2_code.md {filename}_v{n}.{m}.{code_ext}
3 コード確認 rules_quick_fix_3_code_confirm.md {filename}_v{n}.{m}_3_code_confirm.md

追加ルール

.rules/dev/rules_dev_other.mdに追加ルールが記載されています。
各ルールには、対象ファイルや参照タイミングが記載されています。
適切に参照して下さい。

各手順1 - 10の説明

手順1: 仕様書作成

開発前に、バージョン別フォルダへインデックス、差分仕様、項目別仕様書を作成し、システム全体の仕様を確定する工程です。

出典: .rules_v7/dev/batch/rules_batch_1_spec.md

仕様書

ユーザの開発指示と既存仕様を入力として、開発開始前に運用向けのシステム仕様を作成します。
この工程で承認された仕様書を、以降の要件定義、設計、実装の基準とします。

出力フォルダとファイル

プロジェクト直下の .document/v{n}.{m}/ フォルダに、次のファイルを作成する。

  • 00_index.md: バージョン、変更概要、仕様書変更一覧、仕様ID、項目別仕様書へのリンクを管理する。
  • 01_差分仕様.md: 前バージョンからの差分を管理する。
  • 02_概要・対象範囲.md: 概要、対象範囲、非対象範囲、用語定義を記載する。
  • 03_実行仕様.md: 実行方式、スケジュール、実行条件を記載する。
  • 04_入出力仕様.md: 入力仕様と出力仕様を記載する。
  • 05_処理・データ仕様.md: 処理仕様とデータ仕様を記載する。
  • 06_外部連携・ファイル構成.md: 外部連携とファイル構成を記載する。
  • 07_セキュリティ・非機能.md: セキュリティと非機能を記載する。
  • 08_ログ・エラー・復旧.md: ログ、エラー、例外、再実行、復旧を記載する。
  • 09_図・受け入れ条件.md: Mermaid図と受け入れ条件を記載する。
  • 10_未決事項・変更履歴.md: 未決事項、確認事項、変更履歴を記載する。

.document フォルダはGit管理対象とする。空フォルダとして保持する場合は .document/.gitkeep を作成する。

作成手順

  1. バージョン、およびリビジョンを新規作成するか、現状を修正するかは、事前に確認を取ること。
  2. .document/v{n}.{m}/ フォルダを作成すること。
  3. 前バージョンが存在する場合は、前バージョンの 99_仕様確認.md を除く全仕様ファイルをコピーして作成し、今回差分を該当する項目別仕様書へ反映すること。白紙から再構成してはいけない。前バージョンの確認結果を新バージョンへ流用してはいけない。
  4. 01_差分仕様.md に前バージョンとの差分を記述すること。
  5. 00_index.md に全項目別仕様書への相対リンク、仕様IDと記載ファイルの対応、未決事項の有無を記載すること。
  6. 項目別仕様書を全体として読んだときに、バッチ全体の現行仕様になるよう統合すること。
  7. v1については、フォルダ構成と各ファイルの内容を作成前に提案し、ユーザ確認を取ること。

仕様書変更一覧

00_index.md に、今回の全仕様書の状態を次の形式で記載すること。

仕様書 状態 変更概要 関連仕様ID
03_実行仕様.md MOD 実行時刻を変更 BAT-EXEC-001
08_ログ・エラー・復旧.md ADD リトライ失敗時のログを追加 BAT-LOG-001
04_入出力仕様.md KEEP 変更なし -
  • ADD: 今回新規作成した仕様書
  • MOD: 今回内容を変更した仕様書
  • DEL: 今回廃止した仕様書
  • KEEP: 前バージョンから変更していない仕様書
  • 00_index.md には、00_index.md 自身と 99_仕様確認.md を除く全仕様書を記載すること。
  • 01_差分仕様.md には、状態が ADD、MOD、DEL の仕様書だけを記載すること。
  • 状態と実際のファイル差分を一致させること。

禁止事項

  • 仕様書をコードファイル別のフォルダや、.document/v{n}.{m}/ 以外のバージョン別成果物フォルダへ作成してはいけない。
  • 項目別仕様書を差分要約だけで構成してはいけない。
  • 省略禁止: 前バージョンに存在する章・文章・表・例・注意点を削除してはいけない。削除が必要な場合は、章自体は残し「廃止」「削除理由」を明記すること。

差分仕様書の記載ルール

01_差分仕様.md には、変更対象ごとに次の内容を記載すること。

  • 仕様ID
  • 変更区分: [ADD]、[MOD]、[DEL]、[KEEP]
  • 変更前の仕様
  • 変更後の仕様
  • 変更理由
  • 影響範囲
  • 対応する項目別仕様書のファイル名、章または仕様ID

仕様IDと追跡性

  • 処理、実行条件、入出力、データ、外部連携、エラー、再実行および受け入れ条件には、重複しない安定した仕様IDを付与すること。
  • 既存仕様のIDは、内容を変更しても原則として維持すること。
  • IDを変更または廃止する場合は、変更理由と旧IDとの対応を差分仕様書へ記載すること。
  • 後続の要件定義書、設計書および最終確認から仕様IDを追跡できるようにすること。

未確定事項と設計事項

  • 仕様作成中に判断できない事項は推測せず、「未確定」または「要確認」と記載すること。
  • 手順2の仕様確認を完了するまでに、開発対象に関する未確定事項を解消すること。
  • 実装方式、インデックス、テストファイル、具体的な内部配置などの設計事項は、仕様として決定済みの場合だけ確定事項として記載すること。
  • 仕様作成時点で未決定の設計事項は「後続設計で決定」と明記し、仕様上の制約と混同しないこと。

仕様書の記載内容

項目別仕様書には、全体として原則以下の内容を記載すること。
該当しない項目は削除せず、「該当なし」と明記すること。
未確定の項目は推測で埋めず、「未確定」または「要確認」と明記すること。

1. 概要

  • バッチ名
  • 対象処理
  • 目的
  • 背景
  • 実行主体
  • 今回の変更概要

2. 対象範囲・非対象範囲

  • 今回対応する範囲
  • 今回対応しない範囲
  • 既存仕様として維持する範囲
  • 手動運用で対応する範囲
  • 将来対応予定がある場合の扱い

3. 用語定義

  • 業務用語
  • データ項目名
  • ファイル名
  • 外部サービス名
  • 略称

4. 実行仕様

  • 実行方式
  • 手動実行/定期実行/イベント実行
  • 実行コマンド
  • 実行ユーザ
  • 実行環境
  • 実行タイミング
  • スケジュール
  • スケジュールのタイムゾーン
  • 多重起動可否
  • タイムアウト
  • 停止方法
  • 終了コード

5. 入力仕様

  • 入力元
  • 入力ファイル
  • 入力テーブル
  • 入力API
  • 入力パラメータ
  • 必須/任意
  • フォーマット
  • 文字コード
  • 改行コード
  • タイムゾーン
  • 入力データの前提条件
  • 入力データが存在しない場合の扱い

6. 出力仕様

  • 出力先
  • 出力ファイル
  • 出力テーブル
  • 出力API
  • 通知
  • 出力フォーマット
  • 出力件数
  • 上書き/追記
  • 一時ファイル
  • 完了後のファイル移動
  • 出力データが0件の場合の扱い

7. 処理仕様

  • 処理全体の流れ
  • 抽出条件
  • 変換条件
  • 集計条件
  • 登録条件
  • 更新条件
  • 削除条件
  • スキップ条件
  • ソート順
  • 重複判定
  • 差分判定
  • トランザクション範囲
  • コミット単位
  • ロールバック条件

8. データ仕様

  • 使用テーブル
  • 主なカラム
  • 主キー
  • 外部キー
  • インデックス
  • 作成タイミング
  • 更新タイミング
  • 削除タイミング
  • 論理削除/物理削除
  • データ保持期間

9. 外部連携仕様

外部連携がない場合は「該当なし」と明記すること。

  • 連携先
  • 連携方式
  • 認証方式
  • 送信データ
  • 受信データ
  • タイムアウト
  • リトライ
  • レート制限
  • 失敗時の扱い
  • 連携ログ

10. フォルダ構成・ファイル構成

以下を明記すること。

  • 配置先ディレクトリ
  • 新規作成ファイル
  • 変更対象ファイル
  • 削除予定ファイル
  • 設定ファイル
  • 入力ファイル配置先
  • 出力ファイル配置先
  • 一時ファイル配置先
  • ログファイル配置先
  • テストファイル
  • 生成物の配置先
  • 参照してよい既存ファイル
  • 参照してはいけない旧ファイル、廃止ファイル、バックアップファイル

同名または類似名のファイルが複数存在する場合は、正式な配置先、仕様書のバージョン、Git履歴、更新日時の順に確認し、正式な対象ファイルを特定すること。
更新日時だけで対象ファイルを決定してはいけない。正式な対象ファイルを判断できない場合は、実装を開始せずユーザに確認すること。

11. セキュリティ仕様

  • 実行権限
  • 認証情報の管理
  • APIキー・トークンの管理
  • 環境変数
  • 設定ファイルの秘匿
  • 入力ファイルのアクセス権
  • 出力ファイルのアクセス権
  • 一時ファイルのアクセス権
  • 個人情報・秘密情報のマスク
  • ログに出してはいけない情報
  • 外部連携先の認証情報
  • セキュリティ上の禁止事項

該当しない場合でも、以下のように明記すること。

実行権限: 該当なし
認証情報: 取り扱いなし
APIキー・トークン: 取り扱いなし
秘密情報: 取り扱いなし
個人情報: 取り扱いなし
ログ出力制限: 秘密情報・個人情報をログに出力しない

12. 非機能仕様

  • 性能要件
  • 想定処理件数
  • 最大処理件数
  • 処理時間
  • メモリ使用量
  • リトライ回数
  • 可用性
  • 保守性
  • 再実行性
  • 冪等性
  • 運用上の制約

13. ログ仕様

  • 開始ログ
  • 終了ログ
  • 件数ログ
  • スキップログ
  • 警告ログ
  • エラーログ
  • ログレベル
  • 出力項目
  • 個人情報・秘密情報のマスク
  • ログに出してはいけない情報
  • 障害調査に必要な情報

14. エラー・例外仕様

  • 入力不正
  • ファイルなし
  • データなし
  • DB接続エラー
  • 外部APIエラー
  • タイムアウト
  • リトライ超過
  • 異常終了
  • 部分成功
  • ロールバック
  • 通知要否
  • 復旧方法

15. 再実行・復旧仕様

  • 再実行可能条件
  • 再実行時の挙動
  • 重複登録防止
  • 中断地点からの再開可否
  • 手動復旧手順
  • ロールバック手順
  • 障害時の確認ポイント
  • 再実行してはいけない条件

16. Mermaid図

必要に応じて、Mermaid形式で図を記述すること。
入力、処理、出力、エラー分岐、リトライ、外部連携を含む場合は、原則としてMermaid図を作成すること。

作成対象の例:

  • 処理フロー図
  • データフロー図
  • 外部連携図
  • リトライフロー図
  • 異常終了時の復旧フロー図

例:

リトライを含む場合の例:

Mermaid図だけで仕様を完結させてはいけない。
条件、項目、例外、エラー、ログについては文章または表でも記述すること。

17. 受け入れ条件

  • 正常終了条件
  • 異常終了条件
  • 出力確認条件
  • ログ確認条件
  • 再実行確認条件
  • リトライ確認条件
  • データ整合性確認条件
  • 回帰確認条件

18. 未決事項・確認事項

  • 未確定の仕様
  • ユーザ確認が必要な事項
  • 実装前に決めるべき事項
  • 判断できない理由
  • 確認が必要な相手または資料

19. 変更履歴

  • バージョン
  • 変更日
  • 変更内容
  • 変更理由
  • 影響範囲

手順2: 仕様確認

設計やコードを見る前に、仕様書単体の矛盾、欠落、継承漏れ、仕様書変更一覧を確認する工程です。

出典: .rules_v7/dev/batch/rules_batch_2_spec_confirm.md

仕様書の確認

.document/v{n}.{m}/ に作成したインデックス、差分仕様および全項目別仕様書を確認して下さい。
この工程では仕様書だけを確認し、要件定義書、設計書、コードとの突合せは行いません。

1. フォルダとファイルの確認

  • .document/v{n}.{m}/ が存在すること。
  • 00_index.md、01_差分仕様.md、02_概要・対象範囲.md、03_実行仕様.md、04_入出力仕様.md、05_処理・データ仕様.md、06_外部連携・ファイル構成.md、07_セキュリティ・非機能.md、08_ログ・エラー・復旧.md、09_図・受け入れ条件.md、10_未決事項・変更履歴.md が存在すること。
  • 前バージョンの 99_仕様確認.md を除く全仕様ファイルをコピーして作成していること。
  • 前バージョンの仕様確認結果を流用していないこと。
  • 前バージョンに存在したファイルが理由なく欠落していないこと。
  • 仕様書がコード別または他の成果物フォルダに作成されていないこと。

2. インデックスの確認

  • 00_index.md から全項目別仕様書へ相対リンクで移動できること。
  • バージョン、変更概要、未決事項の有無が記載されていること。
  • 仕様IDと記載ファイルの対応表が存在し、重複やリンク切れがないこと。
  • 00_index.md の仕様書変更一覧に、確認結果を除く全仕様書が記載されていること。
  • 各仕様書の状態が ADD、MOD、DEL、KEEP のいずれかであること。
  • ADD、MOD、DEL には変更概要と関連仕様IDが記載されていること。
  • 前バージョンとの実際のファイル差分と、仕様書変更一覧の状態が一致していること。

3. 差分仕様の確認

  • 各変更に仕様ID、変更区分、変更前後、変更理由、影響範囲、対応ファイルが記載されていること。
  • ユーザの開発指示が漏れなく仕様化されていること。
  • 01_差分仕様.md と各項目別仕様書の内容が一致していること。
  • 01_差分仕様.md に、仕様書変更一覧で ADD、MOD、DEL とした全仕様書が記載され、KEEP の仕様書が変更対象として記載されていないこと。

4. 項目別仕様書の確認

  • 各ファイルが担当する仕様項目を漏れなく記載していること。
  • 該当しない項目が削除されず「該当なし」と記載されていること。
  • 前バージョンの章、文章、表、例、注意点が理由なく欠落していないこと。
  • ファイル間および仕様書内に相互矛盾がないこと。
  • 主要な仕様と受け入れ条件に安定した仕様IDが付与されていること。
  • 開発対象に関する「未確定」または「要確認」が残っていないこと。
  • 未決定の設計事項が仕様上の確定事項として記載されていないこと。
  • 対象ファイルを更新日時だけで決定していないこと。
  • スケジュール実行する場合、タイムゾーンが明記されていること。

5. 確認結果

確認結果は .document/v{n}.{m}/99_仕様確認.md に出力して下さい。
99_仕様確認.md には全チェック項目の結果と、総合判定: 合格 / 不合格 を記載して下さい。未確認または不合格の項目が1件でもある場合は、総合判定を合格にしてはいけません。
不備がある場合は rules_batch_1_spec.md に戻って仕様書を修正し、再確認して下さい。
すべての確認が完了した場合のみ、手順3へ進んで下さい。

手順3: 要件定義書

承認済み仕様をもとに、目的、対象範囲、入出力、実行条件、受入条件を整理する工程です。

出典: .rules_v7/dev/batch/rules_batch_3_request.md

要件定義書

目的

バッチ処理やスクリプト処理を開始する前に、処理目的、入出力、実行条件、運用条件、受入条件を整理します。
手順1〜2で作成・承認された仕様書を入力とし、要件が承認済み仕様の範囲内であることを確認します。
この手順で作成した要件定義書を、以降の基本設計書、詳細設計書、コード実装の入力として扱います。

要件定義書の内容

下記を記述します。

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

作成手順

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

手順4: 基本設計書

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

出典: .rules_v7/dev/batch/rules_batch_4_base.md

基本設計書

基本設計書の内容

下記を記述します。

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 変数で設定できるようにすること。
    //処理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: 基本設計書確認

基本設計のID、タグ、仕様継承、入出力の整合性を確認する工程です。

出典: .rules_v7/dev/batch/rules_batch_5_base_confirm.md

基本設計書の確認

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

1. 形式・構造チェック

  • ファイル命名: {filename}_v{n}.{m}_4_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}_5_base_confirm.md としてファイル出力して下さい。

手順6: 詳細設計書

基本設計を関数、変数、処理ステップへ分解し、MarkdownとJSONへ落とし込む工程です。

出典: .rules_v7/dev/batch/rules_batch_6_detail.md

詳細設計書

詳細設計書の内容

基本設計書の各処理[Sxxx]について、下記を記述します。
基本的には、1つの処理につきメインとなる関数は1つとし、バッチ処理のエントリーポイント、主要処理、補助処理を関数単位で記述します。

つまり、各処理[Sxxx]ごとに、個別に下記の項目1 - 7を作成します。
各処理をまとめて項目を作成してはいけません。

no 項目 説明
1 処理概要 基本設計の処理ID（Sxxx）に基づき、何を実現する処理かを記述します。
2 メイン関数 [Fxxx] IDを付与した、処理の入り口となるメイン関数を記述します。
3 引数 引数一覧の名称、データ型、説明をテーブル形式で記述します。各引数には[Ixxx] IDを付与します。
4 戻り値 戻り値一覧の名称、データ型、説明をテーブル形式で記述します。各戻り値には[Oxxx] IDを付与します。
5 メイン変数 処理の主要変数一覧の名称、データ型、説明をテーブル形式で記述します。各変数には[Vxxx] IDを付与します。
6 処理フロー メイン関数から呼び出される補助関数やロジックの流れをステップ単位で記述します。
7 特記事項 再実行、冪等性、エラーハンドリング、ログ出力、運用上の注意点などを記述します。

補助関数

補助関数についても、関数ID[Txxx]を割り当て、各処理[Sxxx]と同様に記述します。

[Fxxx], [Txxx]の詳細

  • [Fxxx] は主関数IDとし、[Txxx] は補助関数IDとする。
  • 1つの関数に付与するIDは [Fxxx] または [Txxx] のどちらか一方のみとする。
  • [Fxxx] はバッチのエントリーポイント、主要処理、外部入出力を統括する公開的な責務を持つ関数に付与する。
  • [Txxx] は [Fxxx] から呼ばれる補助処理用の関数に付与する。
  • [Txxx] を直接エントリーポイントとして扱ってはならない。
  • 同一関数に [Fxxx] と [Txxx] を併記してはならない。
  • F = publicメソッド相当、T = privateメソッド相当と解釈します。
  • T/F は別軸ではなく、関数種別を表す排他的なID分類である。
  • 詳細設計書に登場する全ての関数に、[Fxxx] または [Txxx] のどちらかを必ず割り当てること。

処理フロー順の設計

  • batch は「処理フロー順」に設計する。
  • [Sxxx] と [Lxxx] は原則として実行順に並べる。
  • [Fxxx] はバッチ全体または処理ブロックの入口とする。
  • [Txxx] はその流れの途中で呼び出される補助関数とする。
  • 非同期、イベント駆動、分岐、再実行がある場合は、順序が崩れる箇所を明記する。

詳細設計書作成ルール

1. ID体系の追加定義

詳細設計では、以下のIDを必ず割り当てて下さい。

  • [Sxxx]: 処理内容
  • [Lxxx]: 処理ロジック・アルゴリズムのステップ
  • [Fxxx]: 関数（Functions）
  • [Txxx]: 補助関数
  • [Ixxx]: 関数の引数
  • [Oxxx]: 関数の戻り値
  • [Vxxx]: メイン変数（Global Variables / Key Variables）

補足

  • 各 [Lxxx] の説明文の末尾に、対応する基本設計のステップIDを (Sxxx) 形式で必ず併記すること（例: [L101] データの正規化を行う (S002)）。

2. コンポーネント・カタログの外部化

詳細設計書（Markdown）が肥大化するのを防ぐため、以下の運用を行います。

  • Markdown: 処理フロー（L-ID）を中心に記述し、各 L-ID の中で関連する F-ID / T-ID / I-ID / O-ID / V-ID を参照する。
  • JSON ({filename}_v{n}.{m}_6_detail.json): 全ての [Sxxx], [Lxxx], [Fxxx], [Txxx], [Ixxx], [Oxxx] および [Vxxx] の定義をリスト化して出力する。
  • 役割分担:
    • Markdown は「処理の流れ、分岐、順序、呼び出し関係」を読むための文書とする。
    • JSON は「処理フロー・関数・変数の辞書」として扱い、名称、役割、型、引数、戻り値、使用箇所、状態を保持する。

3. タグ付与対象の明確化

タグは、詳細設計書内の以下の管理対象に付与して下さい。

  • [Sxxx]: 処理内容
  • [Lxxx]: 処理ロジック・アルゴリズムの各ステップ
  • [Fxxx]: 関数の定義
  • [Txxx]: 補助関数の定義
  • [Ixxx]: 関数の引数の定義
  • [Oxxx]: 関数の戻り値の定義
  • [Vxxx]: メイン変数の定義

タグは以下を使用します。

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

4. V-ID の対象範囲

[Vxxx] を付与する対象は、以下のいずれかに該当する変数とします。

  • メイン処理から複数関数へ受け渡される主要変数
  • 外部入出力、設定、判定条件に直接関わる主要変数
  • 業務上意味を持つ中間結果であり、設計レビュー時に追跡が必要な変数
  • ログ出力、アラート出力、画面表示、保存処理などの制御に関わる主要変数

以下は原則として [Vxxx] の対象外とします。

  • 関数内だけで完結する一時変数
  • 単純なループカウンタ
  • 一時的な整形用の補助変数で、外部仕様や主要ロジックに影響しないもの

5. 出力ファイル

  • {filename}_v{n}.{m}_6_detail.md
  • {filename}_v{n}.{m}_6_detail.json

詳細設計書の作成手順

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

  1. 対応する基本設計書（_4_base.md および _5_base_confirm.md）と同じバージョン・リビジョンであることを確認します。
  2. 基本設計書と同じバージョン・リビジョンのファイルをコピーします。
  3. タグを付与します。各項目（処理フローの各ステップ、関数定義、変数定義）の先頭に、必ずタグを記述して下さい。
  4. 仕様継承の義務: 前バージョンの処理・関数・変数を省略せず、既存の全ての項目に [KEEP] [MOD] [DEL] のいずれかを付与して全文を維持すること。新規追加の項目には [ADD] を付与すること。[DEL] の項目は本文から削除せず、取り消し線付きで残し、実装対象からは除外すること。
  5. 集計レポートを設計書末尾に出力します。タグごとの件数を表形式で必ず記述して下さい。

レポートの例

タグ 件数 内容（要約）
[ADD] 2件 RCI期間設定の追加、ログ出力フラグの追加
[MOD] 1件 アラート判定閾値の変更
[DEL] 1件 不要になった旧描画ロジックの削除
[KEEP] 12件 移動平均計算、UIカラー設定、etc...

処理の流れ

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

  • サンプルコード

    • 下記のようにメインとなる変数を関数単位で受け渡すように書くこと。
    • ローカル変数は適時使用すること。
    • コメントは詳細に書くこと。
    • 関数単位でログを出力できるようにすること。
    • ログ出力は isOutputLog 変数で設定できるようにすること。
    //処理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()

手順7: 詳細設計書確認

詳細設計を確認し、実装時の基準となる統合JSONを確定する工程です。

出典: .rules_v7/dev/batch/rules_batch_7_detail_confirm.md

詳細設計書の確認

作成した詳細設計書（Markdown）とコンポーネント・カタログ（JSON）が、rules_batch_6_detail.md の制約を満たし、実装フェーズへ移行可能な品質であることを以下のチェックリストを用いて厳格に確認して下さい。

1. 形式・構造チェック（Markdown & JSON共通）

  • ファイル命名: {filename}_v{n}.{m}_6_detail.md および {filename}_v{n}.{m}_6_detail.json の形式になっているか。
  • S単位の章構成: Markdown が各処理 [Sxxx] ごとの個別章で構成されているか。複数の [Sxxx] をまとめて、処理概要・関数・引数・戻り値・変数・処理フロー・特記事項を一括記述していないか。
  • S別7項目の完備: 各 [Sxxx] 章に、以下の7項目が欠落なく記述されているか。
      1. 処理概要
      1. メイン関数
      1. 引数
      1. 戻り値
      1. メイン変数
      1. 処理フロー
      1. 特記事項
  • IDの整合性: 全ての [Sxxx], [Lxxx], [Fxxx], [Txxx], [Ixxx], [Oxxx], [Vxxx] に欠落なくユニークなIDが割り当てられているか。
  • F/T分類の排他性: 同一関数に [Fxxx] と [Txxx] が併記されておらず、主関数は [Fxxx]、補助関数は [Txxx] のどちらか一方のみで管理されているか。
  • F/T未割当の禁止: 詳細設計書および JSON に登場する全ての関数に [Fxxx] または [Txxx] のどちらかが割り当てられているか。
  • タグの網羅: 全ての項目（処理、ステップ、関数、引数、戻り値、変数）に [ADD], [MOD], [DEL], [KEEP] のいずれかのタグが付与されているか。
  • 視覚装飾: Markdown上で [ADD] は緑色、[MOD] は青色、[DEL] は赤字＋取り消し線になっているか。
    • [KEEP] は装飾なし（黒字）のまま維持されているか。

2. MarkdownとJSONの紐付けチェック

  • S-ID対応の整合性: Markdown内の各 [Lxxx] の説明末尾に、対応する基本設計のステップID (Sxxx) が漏れなく記載されているか。
  • 定義の完全性: Markdown内の処理フロー（[Lxxx]）に登場する全ての関数・引数・戻り値・変数が、JSONファイル（_6_detail.json）側に漏れなく定義されているか。
  • S別JSON対応: Markdown の各 [Sxxx] 章に記載されたメイン関数、補助関数、引数、戻り値、メイン変数、処理フローが、JSON 側で同じ [Sxxx] または sourceStepId に紐づいて定義されているか。
  • 命名の一致: Markdown内の記述と、JSON側の name フィールドが完全に一致しているか。
  • カタログの充足度: JSON側に「型（type）」「役割（description）」「引数/戻り値の構成」「使用箇所」「状態」が、実装者が迷わないレベルで記述されているか。

3. 内容・論理チェック（仕様継承）

  • 基本設計との不整合: 基本設計（_4_base.md）の各処理（[Sxxx]）が、詳細設計で適切にブレイクダウン（[Lxxx]化）されているか。
  • S別詳細化の妥当性: 基本設計の各 [Sxxx] が、Markdown 上で個別に詳細化され、それぞれの処理概要・メイン関数・引数・戻り値・メイン変数・処理フロー・特記事項が、その [Sxxx] の責務と矛盾していないか。
  • まとめ記述の禁止: 関数一覧、引数一覧、戻り値一覧、変数一覧、処理フロー一覧を全S共通の一括表だけで済ませていないか。共通カタログを併記する場合でも、各 [Sxxx] 章内に必要項目が個別に存在しているか。
  • 仕様継承の完遂: 前バージョンの詳細設計要素が一つも漏らさず（[KEEP] [MOD] [DEL] のいずれかで）記載されているか。
  • ロジックの衝突: 新しく追加された補助関数（[Txxx]）やロジック（[Lxxx]）が、既存の [KEEP] ロジックの動作を意図せず破壊していないか。

4. コンパイル・ダイジェスト（集計表）の確認

  • 数値の一致: Markdown末尾の集計レポートの件数と、本文中の各タグの出現回数、およびJSON内のステータス別件数が完全に一致しているか。
  • 要約の正確性: レポート内の「内容（要約）」が、実際の修正内容（ADD/MOD/DEL）を端的に表しているか。

最終成果物：実装用統合JSONの出力

上記のチェックを全てパスした場合のみ、「詳細設計完了」として実装フェーズへ移行して下さい。
移行時に、全仕様を以下の形式のJSONにコンパイル（出力）して下さい。
ファイル名は、{filename}_v{n}.{m}_7_detail.json とします。
実装コードはこのJSONの項目を1つも漏らさずカバーしなければなりません。

{
  "version": "n.m",
  "summary": "今回の変更内容の総括",
  "features": [
    {"id":"L101","sourceStepId":"S001","type":"KEEP","summary":"入力ファイル読込処理を維持","targetFunction":"selectInputFile"}
  ],
  "functions": [
    {"id":"F101","type":"KEEP","name":"main","description":"バッチ全体を制御する主関数"},
    {"id":"T101","type":"KEEP","name":"selectInputFile","description":"入力ファイルを読み込む補助関数"}
  ],
  "inputs": [
    {"id":"I101","type":"KEEP","name":"inputPath","dataType":"string","description":"入力ファイルパス"}
  ],
  "outputs": [
    {"id":"O101","type":"KEEP","name":"listData","dataType":"array","description":"読み込んだデータ"}
  ],
  "variables": [
    {"id":"V101","type":"KEEP","name":"listData","dataType":"array","description":"処理対象データ"},
    {"id":"V104","type":"ADD","name":"isOutputLog"}
  ],
  "deleted_items": {
    "features": ["L099"],
    "functions": ["F099"],
    "inputs": ["I099"],
    "outputs": ["O099"],
    "variables": ["V099"]
  },
  "constraints": ["実装上の制約（ファイルサイズ、実行時間、API制限等）"],
  "invariants": ["KEEPタグ部分の既存出力を変えない"]
}

手順8: コード作成

確認済みの詳細設計と統合JSONをもとにコードを実装する工程です。

出典: .rules_v7/dev/batch/rules_batch_8_code.md

コード設計書

詳細設計書（_6_detail.md / .json）および実装用統合JSON（_7_detail.json）に基づき、以下のルールを厳守してコードを実装して下さい。
開発方針やロジックに矛盾・不明点が見つかった場合は、実装を進める前に必ずユーザに報告し、指示を仰いで下さい。

1. 実装開始時の宣言（プレ・フライト・チェック）

実装を開始する直前に、以下の内容を回答として提示して下さい。

  • ターゲットJSONの確認: 参照する {filename}_v{n}.{m}_7_detail.json のバージョン。
  • 変更箇所のリストアップ: JSON内の [ADD] および [MOD] タグが付いた全項目（L/F/T/I/O/V ID）を列挙し、それらを「どのファイル・どの関数」で実装するかを宣言して下さい。

2. IDコメントの埋め込みルール

詳細設計との整合性を確保するため、コード内の適切な箇所に以下のコメントを必須で記述して下さい。

ID種別 記述場所 記述例
[Lxxx] 処理ロジック・アルゴリズムの各ステップの開始位置 // [L101] 入力ファイル読込ロジック開始
[Fxxx] 主関数の**定義箇所（宣言部分）**の直前 // [F101] バッチ全体制御関数
[Txxx] 補助関数の**定義箇所（宣言部分）**の直前 // [T101] CSV変換補助関数
[Ixxx] 引数の宣言・初期化箇所 // [I101] 入力ファイルパス
[Oxxx] 戻り値の宣言・初期化・返却箇所 // [O101] 処理結果リスト
[Vxxx] メイン変数・定数の宣言・初期化・参照または更新箇所 // [V101] ログ出力フラグを参照

3. コード品質・安全性の担保

  • F/T分類の維持: 全ての関数定義直前に // [Fxxx] または // [Txxx] のどちらか一方を必ず記述して下さい。同一関数に F/T を併記してはいけません。
  • 不変条件（Invariants）の保護: [KEEP] タグが付いた既存ロジックを修正・削除してはいけません。実装完了後、既存の挙動が維持されているか再確認して下さい。
  • ログ出力制御: 共通変数 isOutputLog （詳細設計で定義されている場合）に従い、関数単位で処理の開始・終了・エラーログを出力できるようにして下さい。
  • エラーハンドリング: 異常系が定義されている場合、詳細設計のステップ（[Lxxx]）に沿って例外処理を実装して下さい。

4. ヘッダー情報の記述

各ソースファイルの先頭には、必ず以下の情報を詳細に記載して下さい。

/**
 * 更新日時: yyyy/mm/dd
 * 処理概要: [Sxxx] に対応する処理の概要
 * 前回バージョンとの違い:
 * - [ADD]: 新規追加した機能
 * - [MOD]: 変更したロジック
 * - [DEL]: 廃止・コメントアウトした箇所
 */

5. 環境・言語固有の制約

  • 原因調査で分からないことなどがあれば、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()

手順9: コード確認

設計ID、JSON仕様、変更範囲、動作確認、デグレを確認する工程です。

出典: .rules_v7/dev/batch/rules_batch_9_code_confirm.md

コード確認

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

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

1. トレーサビリティ・チェック（ID照合）

  • IDの存在確認: 詳細設計確認で確定した {filename}_v{n}.{m}_7_detail.json に含まれる [ADD] [MOD] の全IDが、コード内のコメント // [Lxxx], // [Fxxx], // [Txxx], // [Ixxx], // [Oxxx], // [Vxxx] として漏れなく記述されているか。
  • F/T分類の排他性: 同一関数の定義箇所に // [Fxxx] と // [Txxx] が併記されておらず、主関数は // [Fxxx]、補助関数は // [Txxx] のどちらか一方のみで記述されているか。
  • F/T未割当の禁止: コード内の全ての関数定義に // [Fxxx] または // [Txxx] のどちらかが割り当てられているか。
  • 実装範囲の限定: 詳細設計で定義されていない不要なロジックの追加や、意図しない箇所の書き換えが行われていないか。
  • KEEPの保護: [KEEP] タグが付いた不変条件（Invariants）領域が、1文字の差分もなく維持されているか。

2. 品質・仕様チェック

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

3. 動作検証（実行確認）

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

確認結果のレポート形式

出力ファイル {filename}_v{n}.{m}_9_code_confirm.md には、以下の「コード確認レポート」を記述して下さい。

■ F/T割当確認レポート

検証項目 件数 判定 備考
named function 総数 n OK / NG 関数定義として棚卸しした総数
[Fxxx] 割当 n OK / NG 主関数IDが割り当てられた関数数
[Txxx] 割当 n OK / NG 補助関数IDが割り当てられた関数数
F/T両方併記 0 OK / NG 0以外は不合格
F/T未割当 0 OK / NG 0以外は不合格
ID重複 0 OK / NG 0以外は不合格

■ 最終判定レポート

検証項目 判定 備考
設計IDの一致 (Traceability) OK / NG
JSON仕様の網羅 (Coverage) OK / NG
不変領域の維持 (Invariants) OK / NG
動作確認 (Execution) OK / NG

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

完了条件

全てのチェック項目が [ ] から [x] になり、総合判定が「合格」となった場合のみ、本プロジェクトの完了を宣言して下さい。
また、F/T割当確認レポートで、F/T両方併記、F/T未割当、ID重複がすべて 0 であることを完了条件とします。
不備がある場合は、直ちに .rules/dev/batch/rules_batch_8_code.md に戻って修正を行って下さい。

手順10: 最終確認

仕様書変更一覧を起点に、仕様書、要件定義書、設計書、コードを横断して実装漏れや矛盾を確認する工程です。

出典: .rules_v7/dev/batch/rules_batch_10_final_confirm.md

最終確認

仕様書、要件定義書、設計書、コードおよび各確認結果を突き合わせ、仕様と実装に矛盾や漏れがないことを確認して下さい。

確認対象

  • .document/v{n}.{m}/00_index.md
  • .document/v{n}.{m}/01_差分仕様.md
  • .document/v{n}.{m}/ 配下の全項目別仕様書
  • .document/v{n}.{m}/99_仕様確認.md
  • {filename}_v{n}.{m}_3_request.md
  • {filename}_v{n}.{m}_4_base.md
  • {filename}_v{n}.{m}_5_base_confirm.md
  • {filename}_v{n}.{m}_6_detail.md
  • {filename}_v{n}.{m}_6_detail.json
  • {filename}_v{n}.{m}_7_detail.json
  • {filename}_v{n}.{m}.{code_ext}
  • {filename}_v{n}.{m}_9_code_confirm.md

確認項目

  • すべての仕様項目が要件定義書と設計書へ反映されていること。
  • 00_index.md に記載された全仕様IDと全項目別仕様書を確認していること。
  • 仕様書変更一覧で ADD、MOD、DEL とした全仕様書の変更が、要件定義書、設計書、コードへ漏れなく反映されていること。
  • KEEP とした仕様書に対応する既存処理が、意図せず変更されていないこと。
  • 設計された処理、入出力、実行条件、異常処理、ログがコードへ実装されていること。
  • 仕様にない機能や挙動がコードへ追加されていないこと。
  • 仕様、要件定義、設計、コードの間に矛盾がないこと。
  • 差分仕様と実装された変更内容が一致していること。
  • コード確認で検出された問題が解消されていること。
  • 前バージョンの維持対象が欠落または先祖返りしていないこと。

確認結果

確認結果は {filename}_v{n}.{m}_10_final_confirm.md として対象バージョンの格納フォルダへ出力して下さい。
不備がある場合は、該当する工程へ戻る前に不備内容と戻り先をユーザへ報告し、確認を取って下さい。

まとめ

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

今後

下記などが充実すれば、製品仕様に近づくかなと思います。

  • フロー図などの作成
  • テスト工程（単体テスト、結合テスト、総合テストなど）
  • コーディング規約
  • コードレビュー
  • セキュリティ回り

参考

1
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?