データ処理パイプラインを別ドメインに横展開する：仕様書ベースのAI駆動開発パターン

ドメインAのデータ処理パイプラインを、ドメインBに横展開しました。処理パターン3種（長期・中期・短期）+ DB格納プログラムの合計4本を、1日で実装しています。仕様書とソースコードをAIに渡し、「これのドメインB版を作ってくれ」と依頼するワークフローです。

課題：ドメインAのパイプラインをドメインBに展開する

データ分析プロジェクトでは、ドメインAの処理パイプラインが先に完成していました。

1
_simDomainA_PatternA/main.py   # 処理パターンA（長期）
2
_simDomainA_PatternB/main.py   # 処理パターンB（中期）
3
_simDomainA_PatternC/main.py   # 処理パターンC（短期）
4
_putDomainATradeDatas/main.py  # 処理結果のDB格納

ドメインBでも同じ3パターンが必要でした。ロジックの骨格は同じですが、データ形式・取得先・パラメータが異なります。ゼロから書くのは非効率で、安易なコピペはドメイン固有の差異を見落とします。

仕様書ファースト：なぜ仕様書が横展開の鍵か

各プログラムにはSPECIFICATION.mdが存在し、ドメイン横断で共有するCOMMON_SPECIFICATION.mdもあります。

1
project/
2
  COMMON_SPECIFICATION.md       # ドメインA/B共通の仕様
3
  _simDomainA_PatternA/
4
    SPECIFICATION.md            # パターンA固有の仕様
5
    main.py

AIにソースコードだけを渡すと「何をしているか」はわかりますが、「なぜそうしているか」がわかりません。仕様書があると、入力データの形式、処理の定義、出力の要件、共通仕様と個別仕様の境界が明確になります。

ワークフロー：参照仕様 + ソースコード → AI実装

ステップ1：参照資料をAIに渡す

1
依頼:
2
以下のドメインAのシミュレーションプログラムを参考に、
3
ドメインB版を作成してください。
4

5
参照ファイル:
6
- COMMON_SPECIFICATION.md（共通仕様）
7
- _simDomainA_PatternA/SPECIFICATION.md（パターンA固有仕様）
8
- _simDomainA_PatternA/main.py（参照実装）

ステップ2：AIが質問を返す

AIに仕様書とソースコードを渡すと、ドメイン固有の差異について質問が返ってきます。実際に返ってきた質問の例を紹介します。

「ファイル名から識別コードを抽出する際のパターンは？」
「データの時間間隔はドメインAと同じですか？」
「DB格納時のテーブル構造はドメインAと共通ですか、それとも別テーブルですか？」

この質問フェーズが重要です。AIが何も聞かずに作り始めた場合、ドメイン固有の差異が無視されている可能性が高いです。

ステップ3：実装 → 通しテスト → リファクタリング → 仕様書更新

AIが実装した後、通しテストで検証し、命名規則の統一や不要なドメインA固有コードの除去をリファクタリングで行い、最後に新ドメインのSPECIFICATION.mdを作成します。仕様書更新を忘れると、次の横展開（ドメインC）で同じ苦労を繰り返すことになります。

設計判断：何が共通で、何がドメイン固有か

横展開の成否は「共通部分と固有部分の切り分け」にかかっています。

1
共通仕様（変更不要）          ドメイン固有（書き換え必須）
2
─────────────────────────    ─────────────────────────
3
全体フロー                   データ取得元・フォーマット
4
ログ形式                     識別コードのパースロジック
5
エラーハンドリング方針        パラメータ閾値
6
DB格納の共通スキーマ          テーブル名・カラム名

この境界がCOMMON_SPECIFICATION.mdで明文化されていたから、AIは「何を変えてよくて、何を変えてはいけないか」を正確に判断できました。

一括リファクタリング：横展開と同日にやる理由

ドメインBの実装と同じ日に、既存のドメインAプログラムの一括リファクタリングも実施しました。横展開時にドメインAのコードを精読するため、ハードコード値・共通化可能なユーティリティ関数・命名規則の不統一といった改善点が大量に見つかります。後回しにすると「AとBで同じ処理なのに書き方が違う」という負債が蓄積します。

学んだこと

1. 仕様書がないと横展開は「コピペ + 祈り」になる

SPECIFICATION.mdとCOMMON_SPECIFICATION.mdの2層構造があることで、AIが共通部分と固有部分を正しく切り分けられました。ソースコードだけでは「なぜこの実装なのか」が伝わりません。

2. AIの質問が出ないときは危険信号

AIが何も質問せずに実装を始めた場合、ドメイン固有の差異を見落としている可能性が高いです。具体的な質問が出ること自体が、AIがドメインの違いを認識している証拠です。

3. 横展開が効くのは「骨格が同じでパラメータが違う」場合

今回は3つの処理パターンの骨格がドメインA/Bで同一だったから成功しました。アーキテクチャが根本的に異なる場合は、横展開よりゼロベース設計のほうが速いです。

4. 横展開とリファクタリングはセットで行う

既存コードを精読する機会を活かし、ドメインA側のコード品質も同時に改善します。A/Bのコードスタイルが揃っていないと、次のメンテナンスコストが跳ね上がります。

まとめ

仕様書の2層構造: COMMON_SPECIFICATION.md + 個別SPECIFICATION.mdで、AIが「変えてよい部分」と「変えてはいけない部分」を判断できます
AIの質問フェーズを省略しない: 質問に丁寧に答えることで、ドメイン固有の差異が正しく反映されます
横展開 + リファクタリング同時実行: 既存コードを精読する機会を活かし、両ドメインのコードベースの一貫性を保ちます