前回のDay 25では、急な仕様変更や機能リリース順序の入れ替えにスマートに対応する「チェリーピック（git cherry-pick）」の実践テクニックを学びました。
本日のDay 26は、第5部「開発フェーズ別・現場ケーススタディ」の集大成として、現代のソフトウェア開発を根底から変革しつつある最先端テーマ——【AIエージェントを活用したケーススタディ自動実行（Issue-to-PR）】を徹底解説します！
いま、ソフトウェア開発の現場では Google Antigravity や Claude Code といった自律型AIコーディングエージェントの導入が急速に進んでいます。
かつてエンジニアが手作業で行っていた「チケット確認・ブランチ作成・ソース調査・コード修正・単体テスト実行・プルリクエスト作成」という一連の定型業務は、いまや『Issue #101 のバグ修正用ブランチを切り、修正してPRを作って』とプロンプトで一括指示するだけで、AIがターミナルとGitを操作して自律的に完走できるようになりました。
「AIにコードを書かせたら、思わぬバグが混入したりブランチが壊れたりしないのか？」「Gitのブランチ戦略やテスト自動化とどう組み合わせれば安全なのか？」と疑問に思う方も多いでしょう。
本日は、C#現場で頻発する
NullReferenceException の障害Issueを題材に、AIエージェントによる「自律ブランチ作成からプルリク起票まで」の完全シミュレーションをお見せします！さらに、AIが90%の定型作業を高速代行する時代において、人間のエンジニアが担うべき『最終コードレビューとマージ承認の絶対原則』まで、実践的なプロの技術を分かりやすくお伝えします！
① 導入・本日の達成目標
AIコーディングアシスタントは、「コードの自動補完」から「自律的な課題解決（Agentic Workflow）」の段階へ進化しました。
GitHub Issueの障害チケットを読み込み、専用ブランチをチェックアウトし、プロジェクト全体を検索して原因コードを特定し、C#コードを修正して dotnet test で検証し、GitHub CLI (gh) でプルリクエスト（PR）を自動起票する——この「Issue-to-PR」の流れを理解し、手足のように使いこなすことが次世代エンジニアの必須スキルです。
- 従来の手作業による定型開発と、AIエージェント（Antigravity / Claude Code）による自律代行の違いを理解する
- 「Issue解析 → ブランチ自律作成 → コード修正・テスト → PR自動起票」の3ステップワークフローを習得する
- C#プロジェクトにおいて、障害チケット（NullReferenceException）をAIに自律修正させ、
dotnet testで品質担保する実戦手順を把握する - GitHub CLI（
gh pr create）とAIエージェントの連携による高品質なPR説明文自動生成の仕組みを理解する - AI生成コードに対する「人間の3大レビュー観点（設計意図・セキュリティ・業務要件）」とマージ承認の絶対原則を身につける
② 【図解】従来の手動作業 vs AIエージェント自律開発：定型タスクからの劇的解放
まず、エンジニアがこれまで日常的に行ってきた「バグ修正の手順」と、AIエージェント導入後の手順を比較してみましょう。
Subversion (SVN) の時代や初期のGit運用では、バグ修正ひとつ対応するにも多くの手作業が存在していました。
チケット管理システム（Redmine、Jira、GitHub Issues）を開いて内容を確認し、ターミナルで命名規則に従ってブランチを切り、エディタで関連ファイルを探し出し、修正を加え、ローカルビルドとテストを回し、ブラウザでPR作成画面を開いてチケット番号や変更理由を手打ちする……。
これらの一連の作業は、1回あたり30分〜1時間以上の時間を奪い、チケット番号の入力ミスやテスト忘れといったヒューマンエラーの原因にもなっていました。
- コンテキストスイッチの消耗: チケット確認、IDE、ターミナル、ブラウザの間を何度も往復し、集中力が途切れる。
- テスト実行の見落とし: 「たった1行のnullチェック修正だから」と油断してテストを省略し、別の箇所で副作用デグレが発生する。
- PR説明文の形骸化: 修正作業で力尽き、PRの説明に「修正しました」と1行しか書かれず、後からのレビュアーの負担が増大する。
これに対し、最新のAIエージェント（Antigravity / Claude Code）は、ターミナル実行権限とファイル編集能力を持っています。
エンジニアが「Issue #101 のバグを調査して修正し、テストを実行してPRを作成して」と1行指示するだけで、チケット情報の取得からブランチ作成、コード修正、自動テスト実行、そしてConventional Commitsに準拠したコミットとPR起票までを完全自律（Autonomous）で駆け抜けます！
③ 【図解】AIによる「Issue-to-PR」自律実行の3ステップ完全手順
AIエージェントが内部でどのようにGitと連携し、プルリクエストまでたどり着くのか、その3ステップを可視化しました。
ステップ1: Issueの自動解析と専用ブランチの自律作成
AIエージェントはGitHub CLI（gh issue view 101）やリポジトリ内のドキュメントから障害内容を読み取り、適切な命名規則（例: fix/issue-101-null-check）で自動的にトピックブランチを作成します。
git switch main
git pull origin main
git switch -c fix/issue-101-null-customer-address
ステップ2: C#コードのピンポイント修正とdotnet test自動検証
スタックトレースやエラーログから原因箇所を特定し、最小限かつ安全な修正を実施します。修正後、必ず dotnet test を実行して既存テストが破損していないことを検証します。
dotnet test --logger "console;verbosity=normal"
合格! - 失敗: 0、合格: 28、スキップ: 0、合計: 28、期間: 1.2s
ステップ3: コミットとGitHub CLIによるPR自動起票
テスト合格を確認したAIは、変更差分をステージングしてコミットメッセージを作成し、リモートへプッシュしてGitHub PRを起票します。
git commit -m "fix(payment): prevent NullReferenceException when customer address is null (fixes #101)"
git push -u origin fix/issue-101-null-customer-address
gh pr create --title "fix: 顧客住所未登録時の決済エラー修正 (#101)" --body "## 概要 Issue #101 のNullReferenceExceptionを修正しました。 ## 変更点 - Customer.AddressのNull条件演算子チェックを追加 - 単体テストケースを追加"
④ 【実戦C#編】Issue #101「NullReferenceException」のAI自律解決シミュレーション
それでは、実際のC# Web APIプロジェクトにおける具体的な障害対応シミュレーションを見てみましょう。
障害チケットの内容（Issue #101）
再現手順: 住所登録をスキップしたゲストユーザーが決済API（POST /api/payments）を呼び出す。
スタックトレース:
System.NullReferenceException: Object reference not set to an instance of an object.
at MyApp.Services.PaymentProcessor.CalculateTax(Customer customer) in PaymentProcessor.cs:line 42
AIエージェントへの指示プロンプト（プロの実践例）
「GitHub Issue #101 を確認してください。ゲスト購入時に PaymentProcessor.cs で NullReferenceException が発生している問題です。
1.
fix/issue-101-null-address ブランチを新設してください。2. 原因箇所をC#のNull許容参照型およびNull条件演算子を用いて安全に修正してください。
3. 再現テストケースを
PaymentProcessorTests.cs に追加し、dotnet test で全件パスすることを確認してください。4. テスト合格後、コミットしてGitHub CLIでPRを作成してください。」
AIが自動生成した修正C#コード
- decimal taxRate = GetTaxRateByZipCode(customer.Address.ZipCode);
// 修正後: C# 8.0+ Null条件演算子とNull合体演算子で安全にフォールバック
+ string? zipCode = customer?.Address?.ZipCode;
+ decimal taxRate = string.IsNullOrWhiteSpace(zipCode)
+ ? DefaultStandardTaxRate
+ : GetTaxRateByZipCode(zipCode);
AIは既存のビジネスロジックを破壊することなく、住所が未登録の場合は標準税率（DefaultStandardTaxRate）へ安全にフォールバックするコードを実装しました。
さらに、PaymentProcessorTests.cs に CalculateTax_WhenAddressIsNull_ReturnsDefaultTaxRate() という単体テストを自動追加し、dotnet test で100%成功を確認してPRを立ち上げました。
⑤ 【図解】人間とAIの役割分担：AIが下準備（90%）、人間が意思決定（10%）
「AIがPRまで作ってくれるなら、人間のエンジニアの役割はどうなるのか？」
答えは明確です。「人間は、より高次元な意思決定・設計判断・セキュリティレビューに専念する」のです。
- 業務仕様（ドメインルール）との整合性:
「そもそも住所が未登録の状態で決済に進めること自体が仕様として正しいのか？ フロントエンドのバリデーション漏れではないか？」といったビジネス文脈の判断は、AIにはできません。 - アーキテクチャ・設計思想の遵守:
プロジェクトで定めたクリーンアーキテクチャの境界線や命名規則、不要な外部ライブラリへの依存が追加されていないかを厳密にチェックします。 - セキュリティと境界値（エッジケース）:
SQLインジェクション、機密情報（APIキーや個人情報）の不要なログ出力、悪意のある入力値に対する耐性を人間が最終担保します。
AIエージェントは非常に優秀ですが、コードの意図を100%理解して責任を取ることはできません。
「テストが通っているからOK」と確認なしにマージボタンを押すのは厳禁です。
『AIが完璧な下書きを用意し、人間が責任を持って最終承認する』——この健全な役割分担こそが、AI時代の最高峰の開発プラクティスです。
📌 本日の講義まとめと実践チェックリスト
Day 26では、AIエージェントとGit/GitHubを融合させた新世代のケーススタディ自動実行（Issue-to-PR）を学びました。
第1弾のテーマは【Day 27：git worktree で再ビルドなしの超高速ブランチ並行開発】です！
巨大なC#ソリューションでブランチを切り替えるたびに発生する「Visual Studioの再ビルド待ち」や「NuGetパッケージ復元待ち」を完全にゼロにする、Gitの神機能
git worktree を徹底解説します！複数画面で本番調査と機能開発をストレスなく同時進行するプロの秘技を、どうぞお楽しみに！
コメント
コメントを投稿