ChatGPT Codex でガントチャート作成その３（段階的に機能追加）

ChatGPT Codex(GPT-5.3-Codex)のガントチャート作成で、機能を順次実装する手順を試してみました。
最初から多くの機能を実装するより、最小限の基本機能を実装後に機能追加していく方がよさそうです。

概要

まとめて機能を実装したChatGPT Codex でガントチャート作成その２の失敗を踏まえて、最小限の基本機能を実装後に機能追加していく方法を試してみました。

あらかじめ最小限の基本機能を実装後に機能追加していく方針を指示することにより、Codex が手順通りに進めてくれます。
途中のエラー対応や修正依頼後に、次のフェーズを指示することにより、順番に実装を進められます。

前回のタスクバーと依存線のズレ等も無く、基本動作を固めてから実装を進めていく方がいいですね。
各フェーズでは、随時修正を加えることもできます。
フェーズ完了後に次のフェーズへ進めることで、機能の実装が漏れることもありません。

コードを一度も書かずにガントチャートの土台ができるのは、不思議な感じです。

• Phase4 終了時の画面

各フェーズの画面遷移

Phase 1: 表示の土台（初期バージョン）

タスクを表示するだけ。タスク依存を示す線もついている。

依存線を曲線に変更

直線だと隠れてしまうので、曲線に変更

Phase 2: 基本編集

実装対象:

• タスク追加
• タスク追加 / 編集ダイアログ（保存 / キャンセル）
• バー移動、右端リサイズ、進捗変更ノブ
• 日付入力のカレンダー表示
• 色プリセット + 任意色選択

編集ダイアログ

進捗ノブの形状を変更

• タスクバーに合わせた進捗ノブ

• 操作例

Phase 3: 制約エンジン

実装対象:

• 依存制約: 後続開始日 >= 先行終了日の翌日
• 依存元終了日変更時の下流タスク自動補正
• 親タスク期間の自動ロールアップ（子タスク期間由来）
• 親タスク進捗の自動ロールアップ（子タスク進捗由来）

親子タスク機能追加

• 親タスクの区別がつかない

• タスク一覧の子タスクを右シフト

• 親タスクバーの形状変更。PARENT, CHILD を非表示

• タスク例を追加

• 親子孫タスク

操作例

Phase4: 拡張機能

実装対象:

• タスク行ドラッグ並び替え
• 子タスクは同一親配下でのみ並び替え可
• undo / redo（アイコンボタン + ショートカット）
• 3 か国語対応（日英中）
• プロジェクト追加
• 週末ハイライト、日付縦グリッドなど視認性改善

• タスク一覧横幅ドラッグ調整

• 画面マージン調整

開発方法

開発プロンプトの作成

指定された内容で、ガントチャート作成を行ったが、下記のような基本動作の問題が発生した。
https://qiita.com/rex0220/items/c0ed069a01393e4e9bf5

最初から機能を盛り込むのではなく、はじめはガントチャートの基本的なタスク表示、タスクバー、関連線の表示動作を固めてから、他の機能を追加した方が問題対策がやリスクなると思われる。
この進め方で実装する場合は、どのようなプロンプト・要件を定義すればよいか？

その進め方はかなり有効です。
「段階実装＋ゲート（合格条件）」を要件に入れるのがポイントです。
以下をそのまま使ってください。
...

他に実装方法がいくつか考えられる場合は、その特徴を提示して選択できるようにできるか？

できます。むしろその進め方が安全です。
プロンプトに「実装前に方式提案→承認後に着手」を入れればOKです。
そのまま使える追記文です。

実装開始前に、候補アプローチを3案提示してください。
各案について次を必ず示してください。
- 概要（1-2行）
- メリット
- デメリット / リスク
- 実装コスト（S/M/L）
- 想定スケジュール（Phase数）
- 今回要件との適合度（高/中/低）

提示後、私が案を選ぶまで実装を開始しないでください。
私が選んだ案のみ実装してください。

必要なら、候補案の型（例）も最初に固定できます。

候補案の型:
A. 描画優先（表示を先に完全固定）
B. データ制約優先（制約エンジン先行）
C. UI先行（操作体験先行）

以上のことを requirements.md に反映して

反映しました。
requirements.md に以下を追加済みです。
...

requirements.mdに従って、一から作成を指示するプロンプトは？

開発プロンプト

Codex に作成してもらった、プロンプトとrequirements.mdです。

requirements.md を唯一の要件ソースとして、ガントチャートをゼロから実装してください。

厳守事項:
1. requirements.md の「実装方式の選択（着手前）」に従い、実装前に候補アプローチを3案提示すること
2. 私が案を選ぶまで実装を開始しないこと
3. 私が選択後、requirements.md のフェーズ要件（Phase 1→4）を順番に実装すること
4. 各フェーズ完了時に、受け入れ条件の pass/fail を明示して停止し、次フェーズへ進む許可を待つこと
5. 不具合再発防止の実装規約（座標共通化、操作責務分離、before/after整合、制約ロジック一元化）を必ず守ること

実装後の報告（各フェーズごと）:
- 変更ファイル一覧
- 要件対応表（要件 -> 実装箇所）
- 受け入れ条件の検証結果（pass/fail）
- 実行した確認コマンド結果（最低 `npm run build`）
- 合理的な前提を置いた場合は前提を明記

まずは requirements.md を読み、候補アプローチ3案を提示してください。

requirements.md

## 概要

タスクを管理するガントチャートを作成する

### ガントチャートの機能
タスク名
開始日
終了日
進捗
担当
色分け
日/週/月切替
詳細画面遷移
タスクのドラッグ移動
進捗のドラッグ変更
依存関係設定
　親子タスク
　タスクの依存関係
マイルストーン表示
今日ライン表示
折りたたみ / 展開
複数プロジェクト切替

## 開発環境
VSCode
Framework: Vite 6+ (Next.jsよりも軽量で、Tailwind v4との親和性が非常に高い)
Language: JavaScript
Styling: Tailwind CSS v4 (新エンジン「Oxide」により設定ファイルが不要になり、CSS内で完結)
State Management: Zustand (Reduxより軽量で、タスクのドラッグ＆ドロップ等の頻繁な更新に適しています)
Date Handling: date-fns (軽量かつ直感的)

## 開発のヒント：Tailwind v4 の新機能を活かす
@starting-style: タスクバーが新しく追加された際のフェードインアニメーションを CSS だけで完結させ、パフォーマンスを向上させます。
Dynamic Utility Values: h-100 や grid-cols-15 など、これまでブラケットが必要だった動的数値がそのまま書けるようになっています。

## 実装方針（必須）
機能を一括で実装せず、段階的に実装すること。各フェーズで受け入れ条件を満たした場合のみ次フェーズへ進む。

### 実装方式の選択（着手前）
実装開始前に、以下を満たす候補アプローチを 3 案提示すること。
- 概要（1-2 行）
- メリット
- デメリット / リスク
- 実装コスト（S/M/L）
- 想定スケジュール（フェーズ数）
- 本要件との適合度（高/中/低）

ユーザーが案を選択するまで実装を開始しないこと。

## フェーズ実装要件
### Phase 1: 表示の土台
実装対象:
- タスク一覧表示
- タイムライン表示
- タスクバー表示
- 依存線表示（読み取り専用）
- 日 / 週 / 月切替（表示のみ）

禁止:
- 追加 / 編集 / ドラッグ更新 / 制約補正 / undo / redo / 多言語など更新系機能

受け入れ条件:
- 依存線の始点が先行バー右端、終点が後続バー左端に一致
- 日 / 週 / 月切替後も依存線がズレない
- マイルストーンでも座標ズレがない

### Phase 2: 基本編集
実装対象:
- タスク追加
- タスク追加 / 編集ダイアログ（保存 / キャンセル）
- バー移動、右端リサイズ、進捗変更ノブ
- 日付入力のカレンダー表示
- 色プリセット + 任意色選択

受け入れ条件:
- 右端ドラッグで期間のみ変更される
- 進捗ノブで進捗のみ変更される
- 保存時のみ反映、キャンセル時は破棄

### Phase 3: 制約エンジン
実装対象:
- 依存制約: 後続開始日 >= 先行終了日の翌日
- 依存元終了日変更時の下流タスク自動補正
- 親タスク期間の自動ロールアップ（子タスク期間由来）
- 親タスク進捗の自動ロールアップ（子タスク進捗由来）

受け入れ条件:
- 保存後に依存制約違反が残らない
- 連鎖依存（A->B->C）でも破綻しない
- 親子で期間・進捗の矛盾が残らない

### Phase 4: 拡張機能
実装対象:
- タスク行ドラッグ並び替え
- 子タスクは同一親配下でのみ並び替え可
- undo / redo（アイコンボタン + ショートカット）
- 3 か国語対応（日英中）
- プロジェクト追加
- 週末ハイライト、日付縦グリッドなど視認性改善

受け入れ条件:
- ドロップ線位置と実際の挿入位置が一致
- undo / redo が主要操作で機能
- 言語切替で主要 UI 文言が切替

## 不具合再発防止の実装規約
### 1. 依存線ズレ防止
- バー描画と依存線描画で共通座標関数（例: `getTaskGeometry`）を必須化
- 依存線の始点 / 終点は共通座標関数の返値のみ使用
- マイルストーンも同座標系で扱う

### 2. 操作の責務分離
- バー本体ドラッグ: 移動専用
- 右端ハンドル: 期間変更専用
- 進捗ノブ: 進捗変更専用

### 3. 並び替え整合性
- ドロップ判定は before / after を行中央で分岐
- 表示インジケータ線と挿入ロジックを同一判定で実装
- ドラッグ中は対象行のみを明確に表示

### 4. 制約ロジック一元化
- 制約判断は store に集約し、UI に分散しない
- add / update / move / resize / reorder の全操作後に同一制約パイプラインを適用

## 完了条件（Definition of Done）
- 各フェーズの受け入れ条件を満たす
- `npm run build` が成功する
- 変更ファイル一覧を提示する
- 要件対応表（要件 -> 実装箇所）を提示する
- 合理的な前提を置いた場合は前提を明示する

開発実行

用意したプロンプトとrequirements.mdで進めます。
Codex の回答にある開発案を選択して実行。

Codex 回答１

以下、requirements.md の「実装方式の選択（着手前）」に沿った 候補 3 案です。
この時点ではまだ実装を開始しません。

案1: 単一アプリ内で段階拡張（推奨）

• 概要（1-2行）: Vite + React + Tailwind v4 + Zustand で1つの画面を作り、Phase 1→4で機能を順次拡張。座標計算・制約処理を早期に共通モジュール化する。
• メリット:
  • 要件との整合が高く、段階実装しやすい
  • getTaskGeometry と制約パイプラインを初期から固定でき、再発防止規約を守りやすい
  • 学習コスト/実装コストのバランスが良い
• デメリット / リスク:
  • 初期設計が弱いと後半（undo/redo・多言語・並び替え）で再整理が必要
  • コンポーネント分割方針を誤ると DnD 周辺が複雑化
• 実装コスト: M
• 想定スケジュール（フェーズ数）: 4フェーズ（要件どおり）
• 本要件との適合度: 高

案2: 描画エンジン先行（座標/線/グリッドを先に抽象化）

• 概要（1-2行）: ガント描画を「幾何計算層 + 表示層」に明確分離し、バー・依存線・マイルストーン・ズーム切替を同一座標エンジンで管理してから編集機能を載せる。
• メリット:
  • Phase 1受け入れ条件（依存線ズレ防止）を最も堅く満たしやすい
  • 将来の表示改善（週末ハイライト・縦グリッド）を拡張しやすい
  • 不具合再発防止の「座標共通化」に最適
• デメリット / リスク:
  • 初期の抽象化コストが高い
  • UI完成が遅く見えやすい
• 実装コスト: L
• 想定スケジュール（フェーズ数）: 4フェーズ（前半重め）
• 本要件との適合度: 高

案3: データ/制約エンジン先行（Store中心設計）

• 概要（1-2行）: Zustand の store を中心に、add/update/move/resize/reorder 後に必ず同一制約パイプラインを通す設計を先に確立し、UIはそれを呼び出す薄い層にする。
• メリット:
  • Phase 3要件（依存連鎖・親子ロールアップ）に強い
  • 再発防止規約「制約ロジック一元化」「操作責務分離」を徹底しやすい
  • undo/redo の実装を履歴管理として組み込みやすい
• デメリット / リスク:
  • Phase 1時点では表示の作り込みがやや遅い
  • 初見でコードの見通しが難しくなる可能性
• 実装コスト: M〜L
• 想定スケジュール（フェーズ数）: 4フェーズ（中盤以降が安定）
• 本要件との適合度: 高

選択してください（案1 / 案2 / 案3）。
選択後、要件どおり Phase 1から順番に 実装し、各フェーズ完了ごとに pass/fail を明示して停止します。

お勧めは？

おすすめは 案1 です。

理由は、今回の要件で重要な

• 段階実装（Phase 1→4）
• 依存線ズレ防止の座標共通化
• 操作責務分離
• 制約ロジック一元化

を、過剰設計になりすぎず現実的な速度で進められるからです。
案2 は堅牢ですが重く、案3 は中後半に強い一方で序盤の見える成果が遅れやすいです。

進める場合は 案1で開始 します。

案1で開始

Phase1 完了報告

Phase 1 完了報告（停止中）

実装は Phase 1 のみ完了し、次フェーズには進んでいません。
要件どおりここで停止します。

変更ファイル一覧

• package.json
• vite.config.js
• index.html
• src/main.jsx
• src/index.css
• src/App.jsx
• src/components/GanttChart.jsx
• src/store/ganttStore.js
• src/lib/timeScale.js
• src/lib/geometry.js
• src/data/seed.js

要件対応表（要件 -> 実装箇所）

• タスク一覧表示 -> src/components/GanttChart.jsx（TaskList）
• タイムライン表示 -> src/components/GanttChart.jsx, src/lib/timeScale.js
• タスクバー表示 -> src/components/GanttChart.jsx, src/lib/geometry.js
• 依存線表示（読み取り専用） -> src/components/GanttChart.jsx, src/lib/geometry.js
• 日/週/月切替（表示のみ） -> src/App.jsx, src/lib/timeScale.js
• 不具合再発防止: 座標共通化 -> src/lib/geometry.js（getTaskGeometry をバー/依存線で共通利用）
• 不具合再発防止: 制約ロジック一元化の土台 -> src/store/ganttStore.js（applyConstraintPipeline の集約ポイントを先置き）
• Phase 1 禁止事項（更新系未実装） -> 追加/編集/ドラッグ更新/undo/redo等は未実装（UI/Storeともに非搭載）

受け入れ条件の検証結果（Phase 1）

• 依存線の始点が先行バー右端、終点が後続バー左端に一致: pass
  buildDependencySegments が getTaskGeometry の right/left のみ参照。
• 日/週/月切替後も依存線がズレない: pass
  バーと依存線で同一 viewMode・同一 timelineStart・同一 getTaskGeometry を利用。
• マイルストーンでも座標ズレがない: pass
  マイルストーンを同一座標系で width=0 として扱い、依存線も同座標参照。

実行した確認コマンド結果

• npm install: 成功（80 packages 追加、脆弱性 0）
• npm run build: 成功（vite build 完了、dist 出力）

合理的な前提

• Phase 1 の「依存線読み取り専用」は、依存関係の編集 UI を持たない実装で満たす前提。
• 「複数プロジェクト切替」は Phase 1 必須ではないが、表示機能として先行実装。
• 受け入れ条件はコード上の整合性とビルド成功で判定（ブラウザ手動目視確認は未実施）。

Phase 2（基本編集）へ進めてよければ、実装を開始します。

依存線が直線なので線が戻っているが、わかりにくい
依存線を曲線でつなぐことはできるか？

可能です。依存線を曲線に変更しました。

• 変更点:

  • src/lib/geometry.js
    • 依存線の定義を折れ線ポイントからベジェ曲線 path d 生成へ変更
    • 始点=先行バー右端、終点=後続バー左端 は維持
  • src/components/GanttChart.jsx
    • SVG描画を polyline から path に変更

• 検証:

  • npm run build: 成功

これで「線が戻って見える」印象はかなり軽減されるはずです。必要なら曲がりの強さ（現在は距離に応じて自動）も微調整できます。

OK
Phase 2（基本編集）へ

...

修正依頼

途中で随時、修正依頼画家のです。

Phase 3（制約エンジン）へ

Phase 2 の確認後、Phase 3（制約エンジン）を実行します。

Phase 4 完了へ

いろいろ直して完了です。