はじめに
Codex (GPT-5.5) と Claude Code (Ops4.6 / Sonnet4.6) を併用している中で、
Issue を解決しても、新たに積み上がり、延々と Issue の量が減らない状況に直面したため、
備忘録として記載します。
AI エージェントを活用するようになってから、
FE+Backend+Infra 周りを一気通貫で開発することにトライアルしやすくなりました。
一方で、自分自身でメイン開発していた頃よりも、Issue の量が増えたように感じます。
私自身がなかなか辿り着けないような課題にも、アプローチできるようになった点は大きいです。
しかし、自身で判断していた頃と比較すると**これは本当に必要な実装だったのか？**と思うようなケースも増えてしまいました。
目の前の積み上がった Issue を、一定の優先度で消化しても、再び
- 改善案
- リファクタ提案
- 不整合
- 命名規則の揺れ
- 保守課題
が大量に Issue 化され、気づくと Issue が積み上がり続ける状態になります。
今回は、AI エージェント開発で Issueが増え続ける中、実際に意識するようになったことを書きます。
AI は「永遠に改善案を出せる」
AI を使っていて感じるのは、
改善候補が無限に出てくる
ことです。
例えば、
- hooks 化できます
- 共通化できます
- 命名規則を統一できます
- 型定義を整理できます
- 古い処理を削除できます
- この設計の方が綺麗です
など、かなり自然に提案してきます。
しかし、AI の提案をやみくもに採用し続けていると、
- 堂々巡りのような Issue が生まれる
- 当初の想定から逸れる、外れる
- 自身の手に負えない判断が加わっていく
など、課題の解決になかなか辿り着けなくなってしまうケースが多々あります。
また、個人開発では「完成させる」ことも重要です。
個人開発では特に、
改善
と、
前進
を分けて考える必要があると感じました。
Issue を「成り行きの AI 任せ」にしない
最初に強く感じたのはこれでした。
AI は Issue を大量に発見します。
しかし、
「今、何を優先するか」
までは決めてくれません。
放置すると、
が大量に積み上がり、
ロードマップが崩れ始めます。
そのため最近は、
- v1.0 としてここまでをゴールとする
- 以降は後回しにする
- やらないこと
を先に決めるようになりました。
「Issue 駆動」
ではなく、
「ロードマップ駆動」
に寄せました。
ロードマップ自体も、AI エージェントより提案いただくことは可能ですが、
最終的な意思決定や判断は、やはり自身でやること、自身でできることが重要になると思いました。
ラベル管理をかなり重視するようになった
途中から、
Issue 管理でかなり重要になったのがラベルでした。
AI は Issue を大量生成できます。
そのため、
「どの種類の Issue のか」を整理しないと、
すぐに管理不能になります。
実際には、
以下のようにラベルを分類しています。
（下記は、ブラウザゲームを制作したときの Issue の例となります。）
area:backend API・サーバー処理
area:db データベース・SQL
area:frontend フロントエンド・UI
...
「優先度を数値化する」より、「ラベルで分類する」方が、
GitHub 運用ではかなり見通しが良くなりました。
特に、
prio:*
area:*
Ver1.x
の 3 軸はかなり重要でした。
Issue を AI に任せきりにしない
AI は Issue 整理もかなり上手いです。
ただ、
丸投げすると危険でした。
理由は単純で、
「Issue の背景理解」が抜け落ちる
からです。
例えば、
- なぜこの Issue が必要なのか
- 本当にユーザー影響があるのか
- 運営コストに見合うのか
- 今やる価値があるのか
を理解しないまま、
Issue だけ増えていきます。
すると、
「Issue は大量にあるが、何が重要かわからない」
状態になります。
そのため最近は、
- Issue 作成
- ラベル整理
- スコープ定義
- close 判断
には、
必ず自分も関与するようにしています。
実際に増えやすかった Issue 例
- 命名規則の統一
- hooks 化
- 型整理
- API レスポンスの統一
- 共通関数化
- import 順の統一
- 未使用コードの削除
どれも正論ですが、
全部対応すると終わりません。
人間側でも定期的に Issue 整理をする
AI にコード上の課題を尋ねると、
「改善可能箇所」
が永遠にあるかのように提案することがあります。
そのため、定期的に人間側で、
- 本当に必要か
- 今やるべきか
- 将来やる可能性があるか
- そもそも捨てるべきか
を整理しないと、Issue が雪だるま式に増えていくケースに遭遇することがあります。
そのため、自分自身で、
定期的に Issue を見直し整理する、消す
ことが重要だと感じるようになりました。
Issue を発見することは、開発の品質を高める上では重要な作業です。
しかし、「どこまでのゴールとするか」がしっかりと定まっていないと、
Issue を消化するフェーズから抜け出すことが困難となります。
Ver1.x ラベルを作った
AI と開発していると、
という Issue が大量に発生します。
以前はそれらが全部通常 Issue に混ざり、優先順位が崩れていました。
そこで、
というラベルを追加しました。
これによって、
を分離できるようになりました。
AI 開発では、「今やらない」を明示することがかなり重要でした。
レビューを AI 任せにしない
AI リビューはかなり便利です。
など、人間より強い部分も多いです。
ただ、最終的に感じたのは、
レビュー責任は人間側に残る
ということでした。
AI は高速にコードを書きます。しかし、
- 本当に安全か
- 運営できるか
- 将来壊れないか
- DB 影響はないか
を最終判断するのは人間です。
特に AI は、
ついでの変更
をかなり行います。
例えば、
- 命名規則の統一
- リファクタ
- 未使用コード削除
- 共通化
を混ぜ込みやすいです。
結果として、レビュー負荷が急激に増えます。
そのため最近は、
- AI リビューは活用するが、自分でもコードを読む
- 小さい PR を維持する
をかなり意識しています。
「AI がレビュー OK だったから Merge する」ことがあまりにも当たり前になってしまうと、自身のゴールの方向性まで見失ってしまうことがあるため、改めて、自身でレビューすることが大事であると思いました。
「小さい PR」の価値が急激に上がった
AI は広範囲変更が得意です。
しかし、巨大 PR はレビュー不能になります。
例えば、
- UI 変更
- API 変更
- DB migration
- ドキュメント更新
を同時に実施すると、差分確認だけでかなり消耗します。
そのため最近は、
- 機能修正 PR
- リファクタ PR
- migration PR
を分離するようになりました。
rules:
- keep_pr_small: true
- separate_migration: true
...
人間開発では昔から言われていたことですが、
AI 時代になると重要度が一段上がった感覚があります。
AI 時代、「実装」より「交通整理」が重要になる
AI エージェントにおいて、
- 優先順位整理
- スコープ管理
- Issue 取捨選択
- PR 分割
- レビュー判断
- やらない判断
が重要であることを改めて認識しました。
構想検討や要件定義が重要であるのは、
自分自身で開発を実装する時も変わらない部分ですが、
AI エージェントによる開発においては、より一層、
コードを書く能力
だけではなく、
一連の開発プロセスをしっかりと言語化する能力
が必要であるように感じました。
おわりに
AI エージェント開発が台頭してから、
個人開発のハードルが下がり、色々なことが形にしやすくなりました。
しかし、AI エージェントへの依存の仕方を誤ると、
などが肥大化してしまうことにも気づくことができました。
最近は、
AI にどれだけ作らせるか
より、
どこで止めるか
の方が重要だと感じています。
個人的には、
- ロードマップを描く
- Issue を理解する
- 人間側でも整理する
- レビューに参加する
この 4 つは、
AI 時代でもかなり重要だと感じています。