はじめに

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 に混ざり、優先順位が崩れていました。

そこで、

Ver1.x = Ver1.0 では導入しない

というラベルを追加しました。

これによって、

• 「将来やる」
• 「今はやらない」

を分離できるようになりました。

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 エージェントへの依存の仕方を誤ると、

• Issue
• レビュー
• 改善案
• リファクタ提案

などが肥大化してしまうことにも気づくことができました。

最近は、

AI にどれだけ作らせるか

より、
どこで止めるか

の方が重要だと感じています。

個人的には、

• ロードマップを描く
• Issue を理解する
• 人間側でも整理する
• レビューに参加する

この 4 つは、

AI 時代でもかなり重要だと感じています。