🔥
今日のAIやらかし？Phaseまぜまぜ問題と8割できたら動かしたくなる人間
🧠 今日のAIやらかし？
と思ったら...
Phaseまぜまぜ問題と早く動かしてみたい人間の話
はじめに
AIエージェントや自動化プログラムを開発していると、
「8割完成してきたし、もうGitHub Actionsで毎日動かしてみようかな…？」
という誘惑にかられる瞬間、ありますよねー
でも、それが思わぬ“罠”だったりします。
この記事では、タスク管理の重要性について考えます。
「Phase混ぜ混ぜ問題」とは
タスクA（例：データ収集＆通知タスク）
Phase1: 元データ収集ロジック作成（済）
Phase2: DB 保存とテスト（済）
Phase3: エラーハンドリング / 本番対応（未対応）
「タスクAはもう動くレベルだし、そろそろ GitHub Actions で定期実行も実装してみよう」
という判断をして、定期実行部分のコードまで手を付け始める
→ ここがミスのキッカケ。
さらに続いて、タスクAが前提となるタスクB（定期実行）の開発も新しくスタートします。
🔥 トラブル発生：またAIのやらかしか
発生した問題
- タスクBのテスト進行中、タスクAの未対応例外が発覚
- AIがあ、Aの問題も直さなきゃ」と、Bへの対応中にもかかわらずAの追加対応を開始
- 人間もAの問題も修正してくれると助かるー、と黙認
- AIの報告にPhase3完了とあるが、その中にPhase1の問題対応完了と記載してあるなど、タスクAとBのどちらを対応しているのか不明瞭になりはじめる。人間側も把握しにくくなってくる。新たに発生した問題に対する計画もPhase分けする。
- タスクBの報告にタスクAの内容混在が本格的にはじまる。よくわからないPhaseが爆誕しまくる
- バグ対応修正がなかなか終わらず、最終的に謎なコードが生成される
- はい、コミット遡ってしてやりなおしね
一見すると「AIのせいで意図しない動きになった？」と思うかもしれません。
⚠️ 詳細：Phase 混在のメカニズム
A タスク
├ Phase2 → テスト完了 → まだ未テストの不具合が潜んでいた
└ 未計画の対応 -> この対応の計画内に新たなPhaseが発生。
B タスク
└ Phase3でAの結果に依存する例外を検知。
するとどうなるか？
- B開発中にAのエラーが混じってデバッグが両方向に迷走
- ログも報告も両タスク分が流れはじめ、管理が破綻
- 「Issue番号＋Phase番号でコメントする方針すれば混乱しなくなりそう」と思ったが
よく考えたら
根本原因は「Phaseとタスクの境界を意識せずに実装してしまった管理上の問題」かもと。
❎ 悪い対応例：「IssueNo + PhaseNo」で対応しても
一時期は「IssueNoとPhaseNoをテンプレにしてコメントしておけば整理できる」
という案も浮かびましたが……
同じことの発生は防げず、発生したときに早めに気づけるだけじゃないかなと考えた。
繰り返しますが、問題は「情報整理」の前に「タスクの分割」が曖昧なことにあったのです。
あるべき対応と設計観点
✅ 人間による正しい段取り
- B の対応中に A の未対応例外に気づいても：
- Bを明確に中断してから、Aの残タスクを新Issueに立てて対応
- 「Aの修正完了 → Close」してから Bを再開するのが正解
✅ AのPhaseによるタスク切り出し
タスクA
├ Phase1〜Phase2 完了 → Close
└ Phase3（未対応）は 新タスクC として切り分けて管理
こうすることで、
- タスクBとタスクAの実装タスク分離が明確になる
まとめ：教訓
「8割できたらとりあえず動かす」は良い選択である場合も多いが罠も潜んでいる。
定期実行や本番想定の実行は、フェーズに区切りをつけてから。
AIエージェントの活用も、設計と管理が整ってないと破綻しがち。
おわりに
今回の例は、
- AIが暴走した話ではなく
- 人間の“段取り” がボトルネックだったというオチ
みなさんのプロジェクトでも「あらかたできたら動かす」誘惑はありませんか？
AIが助けてくれる時代でも、人間が段取りを決める部分はなくなりません。
Discussion