こんにちは、TVerでiOSエンジニアを担当している福島（@mantaroufire）です。
今回は、ある大規模プロジェクトにおいて、前提知識がほぼない状態から途中参画し、AIを活用してバグ修正を効率的に進めた経験についてご紹介します。
大規模プロジェクトへの途中参画
TVerでは、ボリュームの大きな機能の開発プロジェクトが進行していました。私が参画したのは、一通りの実装が完了し、不具合解消フェーズに入ったタイミングでした。
つまり、プロジェクト固有の要件・仕様や、細かい実装アプローチをほとんど把握していない状態からのスタートです。
通常であれば、まずコードを読み込んでキャッチアップに時間をかけるところですが、リリースまでの時間は限られています。そこで活用したのが、Claude Codeのスキルでした。
Claude Codeのスキルとは
Claude Codeには、特定のタスクに特化した「スキル」を自作できる機能があります。プロジェクト固有の作業手順をスキルとして定義しておくことで、誰でも同じ品質・同じ手順で作業を進められるようになります。
今回のプロジェクトでは、以下の3つのスキルを順番に使うワークフローが活躍しました。
/analyze-and-create-issues → /implement-issue → /create-pr
不具合の分析からPR作成まで、一連の流れをスキルで標準化しています。
TVerでは不具合管理にGitHub Issueを活用しています。Claude Codeはターミナル操作も自律的に行えるため、GitHub Issueを中心としたワークフローとの相性が良く、ghコマンド（GitHub CLI）を使ったIssue作成・PR作成や、他リポジトリの探索も実行してくれます。これにより、調査から実装・PR作成までをシームレスに進められます。もちろん実行前に承認を求めてくれるので、内容を確認しながら対話的に進められます。
各スキルの紹介
1. /analyze-and-create-issues - 不具合の分析とIssue作成
QAチームから報告された不具合Issueをインプットとして、以下を自動で行います。
実行内容
- 不具合Issueの内容を読み取り、問題を分析
- 現在のソースコードを調査し、原因を特定
- 調査結果と修正方針をまとめたIssueを作成
対話例
👤:
/analyze-and-create-issues
🤖:
案件分析を開始します。まず、インプット情報を収集させてください。
issueのURLまたは番号を教えてください
👤:
QAから報告されたこのIssueを見て（不具合IssueのURLを共有）
🤖:
不具合Issueを確認しました。特集画面で一部エリアのレイアウトが崩れている問題ですね。
調査の参考になる補足情報があれば教えてください。（任意・スキップ可）
例：実装対象のファイルパス、参考にすべき既存実装、その他の補足情報など
👤:
Androidではどう実装されているか確認してほしい
🤖:
承知しました。Androidリポジトリも含めて調査します。（ソースコード・Androidリポジトリを調査）
調査が完了しました。XXXXXViewでアイコンの表示条件に問題がありそうです。
Android側と比較したところ、iOS側のフィルタリング条件が仕様と異なっていました。Android実装に合わせる形で修正するのが良さそうです。
以下のIssue分割案で進めてよろしいですか？
👤:
OK、Android比較の結果もIssueに含めて作成して
🤖:
承知しました。Android実装との比較を含めたIssueを作成します。（Issueを作成）
Issue #7017 を作成しました。
作成されるIssueの例:
Issueには、概要・背景・調査結果・影響範囲・参考コード・関連リンクなどが詳細に記載されます。
このように、スキルが対話形式で情報を収集してくれるので、途中で「Androidの実装を確認して」といった追加の依頼を挟みながら、より精度の高いアウトプットを得ることができます。
2. /implement-issue - Issueに基づく実装
前のスキルで作成したIssueをインプットとして、実装を行います。
実行内容
- Issueの調査結果や方針を読み取り、具体的な実装方針を策定
- 採用アーキテクチャに沿った設計で実装
- ビルド確認
- コミット作成
対話例
👤:
/implement-issue #7017
🤖:
Issue #7017 の内容を確認し、実装を進めます。
（実装を進める）
実装が完了しました。ビルドも通っています。
Issueに「影響範囲」「参考コード」が詳細に記載されているため、AIはそれをもとに実装方針を固めて進められます。実装後はセルフレビューを行い、違和感があれば対話で修正します。
3. /create-pr - PR作成
実装が完了したら、PRを作成します。
実行内容
- 変更内容の分析
- Android実装との比較表の作成
- Before/Afterの整理
- PR本文の生成
対話例
👤:
/create-pr
🤖:
PRを作成します。Android実装との比較表も含めます。（PRを作成）
PR #7021 を作成しました。
作成されるPRの例:
このように、レビュワーが「なぜこの修正が正しいのか」を判断できる情報がPRに詰め込まれています。特にAndroid実装との比較表があることで、修正の妥当性を客観的に確認できます。
バグ修正とAIの相性の良さ
今回の経験を通じて、バグ修正はAI活用と非常に相性が良いと感じました。その理由は以下の通りです。
1. 期待値が明確
新機能開発と異なり、バグ修正には「正しい動作」という明確なゴールがあります。仕様書、Android実装など、参照できる情報源が多いため、AIが判断に迷う余地が少ないです。
2. スコープが限定的
バグ修正は影響範囲が比較的小さく、1つのPRで完結することが多いです。AIにとって扱いやすいタスクサイズです。
3. 調査の自動化
人間が複数のリポジトリやドキュメントを行き来して調査するのは時間がかかりますが、AIなら高速に横断的な調査ができます。
プロンプトの工夫
スキルを作成する際に工夫した点をいくつかご紹介します。
1. 対話形式での情報収集
必要な情報を一度に全て聞くのではなく、1つずつ質問して回答を得てから次へ進む設計にしました。これにより、ユーザーが何を入力すればいいか迷わずに済みます。また、やりとりの粒度を小さくすることで、AIが情報を見落としにくくなる効果もあります。
2. 段階的なアプローチ
Issue分割案を提示する際は、まず概要を提示して承認を得てから詳細を出力するようにしました。これにより、方向性の確認が早い段階でできるため、手戻りを防止できます。
3. 補足情報の任意収集
ファイルパスや用語説明など、調査を効率化するための補足情報を任意で収集するステップを設けました。人間側が持っている情報をAIに渡すことで、調査精度が上がります。
まとめ
私と同様に途中からプロジェクトに参画したメンバーにも、これらのスキルを使ってもらいました。
前提知識がない状態でプロジェクトに途中参画するのは不安なものですが、スキルで作業手順を標準化しておくことで、キャッチアップの時間を大幅に短縮できました。「どこまで調査すればいいか」「PRにはどんな情報を含めるべきか」といった属人的なノウハウがスキルに集約されているため、プロジェクトの背景を知らなくても一定品質のアウトプットを出せます。
結果として、無事にプロジェクトのリリースを迎えることができました。
さいごに
TVerでは一緒に働く仲間を募集しています。AIを活用した開発や、大規模プロジェクトへの対応など、チャレンジングな環境で一緒に働きませんか？
カジュアル面談も受け付けていますので、少しでも気になった方はお気軽にご連絡ください！
