以前から、GitHub ProjectsとIssuesを使って月初にスプリント計画を立て、開発タスクを管理してきました。
人が手でコードを書いていた頃は、登録するイシューの数も限られていました。手作業で起票し、優先度をつけて進める運用でも回っていました。
しかし、AIを開発に本格的に使うようになり、状況が一変しました。
AIへ実装を頼むようになると、作業を細かく分けて登録する速さに、手作業の起票が追いつかなくなりました。
あまりの手間に耐えかねて、関連タスクを「まあ1個に雑にまとめておけばええやろ」と大雑把に登録するようになり、イシューの中身も記録もどんどん甘くなっていました。
この手作業の限界を感じて、8月中旬からイシューの切り出しから登録、さらには実装の依頼までをAIに任せる運用へ切り替えました。
結果として、イシューには背景や対象、確認したいことまで書けるようになりました。しかし同時に、私自身が感じたことのない二つの壁にぶつかっています。
一つは、「プログラミング感がほとんどなくなった」こと。
そしてもう一つは、AIが上げた実装に対して、「検証作業で自分の確認がボトルネックになり、消耗している」ことです。
以前の運用：AIでコードが増えると、手動イシュー登録は破綻する
以前は、月初にスプリント計画を立てて「今月はこの機能をここまで進めよう」とイシューを作っていました。
人間が実装する前提なら、ブラウザでGitHubを開き、タイトルと簡単な要件を書いて登録していく作業でも、それほど苦にはなりませんでした。
ところが、AI駆動開発を取り入れると、タスクを切り出して実装へ渡す速さに、イシュー登録が追いつかなくなりました。
私がAIに任せる時は、タスクを小さく、具体的に分けたほうが、指示のズレを減らしやすいと感じています。必要な粒度は案件によりますが、関連する作業を大きくまとめたイシューでは、何を直すかを追加で確認することが増えました。
タイトルを考え、説明文を書き、ラベルを貼る作業は、細かく分けるほど積み上がります。
結果として起きていたのが、私の手抜きでした。
自分でメンバーのタスク管理をしつつ、自分のタスクも割り振っているので、最低限進めたい仕事量を意識するあまり、イシューの内容で手を抜くことがありました。
「面倒だから、この関連タスクは全部まとめて1個のイシューにしておこう」
「細かい仕様はイシューに書かなくても、自分が頭の中で分かっていればええやろ」
そんな雑なカテゴライズが増え、イシューの内容は大雑把になり、後から振り返った時の計測や作業記録も甘くなっていました。タスクを管理するためのイシュー管理が、かなり形骸化していたと感じています。
現在の運用：設計書と調査結果から、必要な粒度でイシューを切らせる
この破綻を解消するために、8月中旬から運用を変えました。イシューの起票自体をAIに任せるアプローチです。
具体的には、次のような手順で進めています。
- 新機能の設計書をAIと壁打ちしながら作る
まずは実装に入らず、エディタ上でAIと壁打ちしながら機能の設計書や処理フローをテキストで作ります。以前書いたMarkdown設計書をAIでSVG化した話のように、重要なフローはこの段階で固めておきます。 - 要望や不具合は、AIに現状調査と対応案を出させてから見る
改善要望や不具合では、いきなり登録せずに「現状で要望は妥当か」「すぐ直したほうがよい点はあるか」を調べさせます。私は修正案を見て、ひどければ再調査と再検討を頼み、問題なければイシュー化へ進めます。 - 設計書や調査結果を基に、適切な粒度でイシュー登録を依頼する
AIには、概要・背景・目的・修正案・対象画面・テスト・受け入れ条件をテンプレートとして埋めてもらいます。完成した設計書や確認済みの調査結果を渡し、実装に必要なタスクへ分けてGitHub Issuesへ登録させます。 - ストーリーポイントの見積もりと、優先度決め
人が対応した場合を想定したストーリーポイント（見積もり）は、AIの案も参考にします。最終的にどれから手をつけるかは、私が決めます。 - 人間が起票内容と優先度を確認する
登録されたイシュー一覧を見て、内容に抜けや違和感がないかを確認し、「どれから手をつけるか」の優先度順に並び替えます。
この運用にしてから、イシューの内容が驚くほど具体的になりました。
AIが作る下書きには、「どのファイルのどの関数を修正するか」「新規作成するファイルは何か」まで書かれています。私は内容を確認してから起票するので、実装前に気になる点を聞き返しやすくなりました。
実例：妥当なイシューでも、再現できなければ検証が止まる
最近、「ノートPCでは一覧やグリッドビューが小さい。最大化できるようにしてほしい」という要望がありました。
私はAIに、現状の画面からこの要望が妥当かを調べ、対応案とすぐ直したほうがよい点をまとめたうえで、適切な粒度のイシューへ登録するよう依頼しました。AIが作った案には、画面最大化だけでなく、ラベルの表記と画面分岐が不自然に見える点も含まれていました。内容を確認し、この一つの要望から3件のイシューを登録しました。
この時点では、まだ実装には入っていません。起票した内容を実装に回せるか確かめるため、現行画面で要望の状態を再現しようとしました。ところが、表示が変わるまでの操作が多く、どの状態から始めれば同じ表示になるのかを、自分でたどり直す必要がありました。
イシューにはテストや受け入れ条件を書いていても、再現に必要な画面の状態や操作順が十分に分からなければ、目視確認だけで時間がかかります。しかも今回見たいのは「エラーが消えたか」だけではありません。一覧の見た目、大きさ、列の順番、分かりやすさを画面で見て判断する必要があります。
この時に必要だったのは、「どんな初期状態で、どの操作をすると、どの画面になるか」という再現手順でした。これが分かれば、修正後に同じ操作をして、ラベルや画面分岐だけでなく、一覧の幅、列順、見やすさを要望と比べられます。
今回のイシューには、そこまでの再現手順が書かれていませんでした。実装に回す前提を確認できなかったことが、この時点で残った判断です。次からは、再現できた不具合は手順と一緒に実装へ回し、まだ再現できていないものは「調査中」と分けて残すつもりです。
完了条件や発生条件には、対象画面の画像やスクリーンショットも付けられるようにしたいです。文章だけでは伝わりにくい一覧の幅、列順、ラベルの位置を残しておけば、実装後に何を見比べるのかが分かりやすくなります。
さらに、イシューを起票させる段階で対象画面を自動撮影し、イシュー本文からリンクできるようにしたいです。「現状」「背景」「現象」「こうなっていてほしい画面」をそれぞれスクリーンショットと結び付けて残せれば、文章だけでは伝わりにくい状態をAIと共有しやすくなります。まだ自動化できていない課題ですが、検証時に「どの画面と比べればよいか」を減らすために取り組みたいところです。
その後、実装へ進めました。最大化ボタンの追加と、押した時の動き自体はすぐにできました。ただ、最大化する範囲がタブ内なのか、タブを超えた全画面なのかで、結果が変わります。タブ内だけを広げると、最大化しても一覧は小さいままです。私は全画面を求めていたので、何ターンか修正を依頼しました。
複数画面への対応では、20画面のうち18画面は意図した表示になりました。残り2画面にはグリッドビューが2つ以上あり、意図していないグリッドが最大化されました。そこで「この画面ではこちらのグリッドを最大化してほしい」と対象を指定して、再度修正を依頼しました。最後に全画面を確認し、すべて受け入れました。
この一件では、要望から3件のイシューが生まれました。別の不具合では、ユーザーから受けた10件の指摘を10件のイシューとして登録しています。Aシステムの画面にBシステムの情報を表示する新機能では、API連携、セキュリティ、トークンまでを設計して6件に分けました。
この記事で使う件数の範囲
私が管理している3つのシステムを1つのGitHub Projectにまとめ、2026年8月中旬から9月中旬に、そのProjectへ新規登録したIssueを確認しました。Issueは起票後に「未実施」「実施」「済み」などの状態でバックログ管理しています。本文の3件、10件、6件は、それぞれの要望・指摘・新機能から新規登録したIssue数です。完了件数、実装時間、開発効率を比べた数字ではありません。
午前はAIが実装、午後は人間が検証で詰まるタイムスケジュール
イシューが綺麗に並んだ後の、日々の開発ルーティンも大きく変わりました。
今は、午前と午後で役割が分かれる日が増えました。
午前中：AIへの実装丸投げと、並列での設計構想
出社したら、GitHub Projectsのイシュー一覧を開きます。
VS Codeやターミナルで、GitHub CLI（gh）経由で利用しているAIエージェントにイシューを参照させます。
「優先度の一番高いこのイシューをやって」
「可能なら、この2件を並列で進めて」
指示を出したら、実装はAIに任せます。AIがコードを書いている間、私自身はエディタを離れ、並列で別の新機能の構想を練ったり、次の設計書を作ったりしています。
指示したイシューについて、AIエージェントは変更内容をコミットメッセージやPRの概要欄に残します。私はその内容と差分を、後の動作確認で見ます。午前中に複数のプルリクエストが積み上がると、午後に確認する対象も増えます。
午後：人間による過酷な検証と不具合修正
問題は午後です。
午前中にAIが仕上げた変更を、午後は私が検証（動作確認、テスト、挙動の確認）します。動かしてみておかしな点があれば改善指示を出し、不具合を修正してもらいます。
ここで痛感するのが、「自分の確認がボトルネックになっている」ことです。
AIエージェントが変更を出す間隔よりも、それが本当に意図通りの挙動をしているか、画面が崩れていないか、壊してはいけない既存機能に影響がないかを確認する時間のほうが長くなります。そこは私が引き受ける判断です。
午前中のタスク消化感が爽快であればあるほど、午後の検証作業は重くのしかかってきます。次々と上がってくるPRをテスト環境で動かしてチェックし続けるのは、想像以上に頭を使い、消耗します。
8月中旬から9月中旬の受け入れを振り返ると、私の体感では、6割ほどはそのまま受け入れ、3割ほどは細かな修正、残り1割ほどは設計から見直したり、何ターンも修正したりする重い案件でした。正確な集計ではありませんが、検証で時間を使うのは、最後の重い案件です。
変わったことと、今も残る違和感
8月中旬から9月中旬までこのスタイルを続ける中で、良かった点と、割り切るべき現実が見えてきました。
良かった点
- タスク消化感がある: やるべきことが明確になり、迷う時間が減ったと感じる。
- 実装前に確認しやすくなった: イシューの内容が具体的になり、実装へ回す前に気になる点を確認しやすくなった。
- 必要な粒度で記録を残せるようになった: 手間を理由に関連タスクをまとめていた悪癖が減り、要望や不具合ごとの経緯を追いやすくなった。
残っている違和感と懸念
- プログラミング感がほとんどない:
コードを自分の手でガリガリ書く時間は限られるようになりました。やっていることは「仕様の壁打ち」「優先順位付け」「動作確認」です。開発が前に進んでいる実感は強いものの、いわゆるプログラミングをしている感覚はあまりありません。 - 人間の検証がボトルネックで根詰まりする:
私の環境では、AIが変更を出す速度に対して、私が確認する速度が追いつきません。午後は検証作業だけで息切れしそうになります。 - 見積もり直感が鈍るかもしれない:
現在、ストーリーポイントもAIに算出させていますが、これに慣れすぎると自分自身の見積もり勘が鈍る気がしています。ここは近いうちに自分の手で見積もる形へ戻すかもしれません。
まとめ
イシューを細かく、具体的に書いたほうがよいと分かっていても、私には手作業で続けるのが難しいところがありました。
しかし、人間が手作業でやるには面倒で、どうしても「ええやろ精神」で雑になっていました。その入力作業をAIに肩代わりさせたことで、自分が必要だと感じる粒度でタスクを管理しやすくなりました。
一方で、コードを書くまでの待ち時間が減った先に待っていたのは、「自分が確認に使える時間の限り」でした。
以前書いたトランクベース開発への移行でもマージの滞留に悩まされましたが、開発スタイルがどれだけ進化しても、どこかしらに新しい詰まりどころが生まれます。
今はまだ午後の検証作業に消耗していますが、「何をやればいいか分からず手が止まる時間」や「雑なイシューを見直す時間」は減ったと感じています。プログラミング感が消えた寂しさは少しありつつも、しばらくはこのスタイルで回してみようと思っています。
確認した公式情報
- GitHub Issuesでは、作業内容に合うイシューを作成でき、リポジトリに用意したテンプレートも使えることを、GitHub Docs: Creating an issueで確認した（確認日: 2026-09-21）。本文の運用手順、件数、検証の負荷は私自身の経験と記録である。
コメント