claude codeとの格闘で学んだ有用なアプローチ
1. クラス設計を明確に指示する(重要:⭐️⭐️⭐️⭐️⭐️)
なぜ有効？
- AIにとって「クラス設計 = 要件の具体化」
- 人間なら避けがちな「クラス再設計」もAIは容易に実行
❌ 悪い例
requirements.txtの定義をもとにCSVモックデータを作成して
✅ 良い例
requirements.txtの定義をもとにCSVモックデータを作成して
下記のクラスを定義してからCSVモックデータを作成して
- 一つの接触に対応したクラス
- 一つのCVに対応したクラス（複数の接触を含む）
2. うまくいかない時はクラス構造を変える(重要:⭐️⭐️⭐️⭐️)
原理
- クラスが変われば → コードの流れも変わる → 目的に適した形になりやすい
❌ 悪い例（詳細指示で強引に修正）
時間の整合性を取るために、CV内では"初回"<"中間n-1"<"中間n<"最終"にして...（複雑な指示）
✅ 良い例（classを変更して解決）
Contactクラスのcontact_datetimeについてinitで設定せず後から設定できるようにして。
一通りのデータを作成してから時間の整合性を保った状態で設定して
3. 段階的アプローチを採用する(重要:⭐️⭐️)
フロー
- 基本構造の確立（クラス設計に集中）
- 機能追加（基本機能をベースに拡張）
- 制約追加（複雑な制約は段階的に）
- 設計変更（限界に達したら設計から見直し）
- 最終調整（ピンポイント修正）
❌ 悪い例（一度に全て要求）
requirements.txtの要件でCSVモックデータを作成して。データの整合性、時間の順序、関係性の制約、コマンドライン引数対応、全て含めて
✅ 良い例（段階的に）
Phase1: まずクラス設計だけ
Phase2: 基本的なデータ生成
Phase3: 時間制約の追加
Phase4: コマンドライン対応
4. コメント駆動修正でピンポイント調整(重要:⭐️)
手法
- 修正したい箇所にコメントを追加
- 「コメントの箇所を修正して」と指示
❌ 悪い例（曖昧な修正指示）
CVが0件の場合も対応して
✅ 良い例（コメント駆動）
# TODO: CVが0件の場合の処理を追加
if len(cvs) > 0:
# 既存の処理
→「コメントの箇所を修正して」
格闘の背景 (ここから格闘記)
- 自社BIシステムの開発で可視化できるデータを増やすにあたり、モックデータを作る必要があった
- データをグラフ化した時、しっかり可視化できる数のデータが必要(1000件)
- データができないとグラフが作れないので、なる早でデータが必要
→AIに頼ろう！
最初の試み：単純なアプローチ
プロンプト1(雑にお願いしてみる)
requirements.txtの要件のCSVモックデータを作成するためのpythonを作成して。
結果: データ型は正しく出力されていたが、データ間の整合性が全く取れていない状態。
プロンプト2(ちょっと詳しく)
requirements.txtの要件のCSVモックデータを作成するためのpythonを作成して。
まず、顧客の行動を定義してからそれをCSVに落とす形で作成して
結果: 多少改善されたが、まだ整合性の問題は解決していない。
転機：クラス設計の重要性に気づく
プロンプト3
"requirements.txt"の要件のCSVモックデータを作成するためのpythonを作成して
下記のクラスを定義して作成してからCSVモックデータを作成すること
- 一つの接触に対応したクラス
- 一つのCVに対応したクラス
結果: まだ完全ではないものの、明らかに改善傾向が見られた。
💡 重要な気づき: クラスを綺麗に定義させることが効果的だと判明した。
プロンプトの進化：詳細なクラス設計
プロンプト4（改良版）
requirements.txtの要件のCSVモックデータを作成するためのpythonを作成して
下記のクラスを定義して作成してからCSVモックデータを作成すること
- 一つの接触に対応したクラス
- 一つのCVに対応したクラス（複数の接触を含む）
- 一つの未CVに対応したクラス（複数の接触を含む）
- 一つの顧客複数購入に対応したクラス （複数のCVを含む）（単一の未CVを含む場合がある）
- 一つのプロジェクトidに対応したクラス （複数の顧客複数購入を持つ）
- 一人の顧客に対応したクラス （複数のプロジェクトidを持つ）
プロンプト5（最終的なクラス設計）
requirements.txt の要件のCSVモックデータを作成するためのpythonを作成して
## 下記のクラスを定義して作成すること
- 一つの接触に対応したクラス
- 一つのCVに対応したクラス （複数の接触を含む）
- 一つの未CVに対応したクラス（複数の接触を含む）
- 一つの顧客複数購入に対応したクラス （複数のCVを含む）（単一の未CVを含む場合がある）
- 一つのプロジェクトidに対応したクラス
- 一人の顧客に対応したクラス
- 一つのチャネルに対応したクラス （単一の広告urlを含む）
- 一つの広告urlグループに対応したクラス （複数の広告urlを含む）
## その他制約
- 顧客とプロジェクトidは多対多の関係
- 顧客と顧客複数購入は1対多の関係
- プロジェクトidと顧客複数購入は1対多の関係
- チャネルと接触は1対多の関係
- 先にクラスインスタンスを作成し、単一のCSVモックデータを作成すること
結果: 完全な整合性は取れていないものの、大幅に改善されました。
細かい調整フェーズ
この段階で作成されたコードをベースに、細かい修正をプロンプトで解決していく戦略に変更した。
機能追加
customerの数をコマンドラインから指定できるようにして
エッジケース対応
CVが0件の場合も存在しうる
最大の難関：時間の整合性
ここで最も困難な問題に直面した。時間の流れの整合性を取ることができない！
複雑な時間制約の指定
接触日時について、
- CV内では"初回"<"中間n-1"<"中間n<"最終"
- NonCV内では"初回"<"中間n-1"<"中間n"<"終端"
- CustomerMultiplePurchase内ではCV［n-1］のMAX（日時）<CV[n］のMIN（日時），CV[n］のMAX（日時）＜not_CVのMIN（日時）
どんなに詳細に書いても、AIは時間の整合性を正しく実装してくれなかった。
解決策：設計パターンの変更
問題の原因分析
- 現状: 全データを作成 → CSVに変換
- 問題: 時間制約が複雑すぎて一度に処理できない
新しいアプローチ
- 改善案: 時間関係が空欄の全データを作成 → 整合性が取れる形で時間部分を埋める → CSVに変換
クラス設計の変更
Contact.contact_datetime, CV.order_datetimeについてinitで設定せず後から設定できるようにして。
一通りのデータを作成してから時間の整合性を保った状態でContact.contact_datetime,CV.order_datetimeを設定して
結果: 時間の整合性は完全ではないものの、手直ししやすい形になった。
最終調整：コメント駆動修正
直して欲しい箇所にコメントを入れてから：
コメントの箇所を修正して
結果: ついに成功！整合性の取れたモックデータ生成コードが完成しました。
感想
人間が書いて捨てるコードを作る場合、クラスを避けて処理の流れそのものを直接描くアプローチをとる気がする。
しかし、AIを使ってコードを書く場合はいかにAIに対してやりたいことを伝えることが重要になって、全体のコード量は多くても問題ない。
だから、クラスの形を明確に伝えることが、自分のやりたいことの詳細を伝える最も効果的な手段だった。
また、「うまくいかない時はクラスの形を変える」というアプローチも同じ理由な気がする。
クラスが変われば必然的にコードの流れも変わるため、人間にとっては修正すべき箇所が増えて大変で避けがちなアプローチだが、AIにとっては容易に実行できるため、人間とAIの特性の違いを活かした戦略と言える。
Discussion