こんにちは、コアシス開発グループのfjtです!
今回は、コードレビューの「nitsコメント」をAIエージェント「Devin」で自動対応する仕組みを作った話をご紹介します。
1. はじめに
なぜこの仕組みを作ったのか
私たちのチームでは、コードレビューにおいてコメントの意図を明確にするためにタグを付ける文化があります。
[nits]: 軽微な指摘(コードスタイルなど)[imo]: 意見・提案[ask]: 質問・確認[must]: 必須の修正
このうち[nits]は、軽微ながらもコードの品質を保つために重要な指摘です。
[nits] ここのコメント削除して [nits] use文でインポートしてください [nits] 型宣言を追加してください
これらのnitsコメントは、コードの品質を保つために重要ですが、対応自体は機械的で時間がかかります。特に以下の課題がありました。
- サイクルタイムへの影響: 軽微な修正でもPR作成者の対応待ちが発生
- コンテキストスイッチ: 軽微な修正とはいえ別の作業中にレビューコメントが来ると、集中が途切れる
- 定型的な作業: nitsの多くは機械的に対応可能なもの
そこで、nitsコメントが投稿されたら自動でAIが修正してくれる仕組みを作りました。
実際にどんなnitsが多いのか?
2025年上半期のPRレビューコメントを分析したところ、タグ付きコメントの内訳でnitsは約16% を占めていました。
仮にnits1件の対応に5分かかるとすると、コンテキストスイッチの時間も含めて実質10〜15分のロスになります。これが積み重なると、チーム全体で月に数時間の作業時間が軽微な修正に費やされている計算になります。
nitsの内訳を見ると、以下のようなパターンが頻出していました。
| 種類 | 例 | 頻度 |
|---|---|---|
| use文の使用 | FQCNではなくuse文でインポートする | 高 |
| 型宣言の追加 | 引数・戻り値に型を明示 | 高 |
| Docコメントの整理 | 型宣言で自明な情報は省略 | 中 |
これらは明確なルールに基づいており、AIでの自動対応に適していると判断しました。
2. 仕組みの全体像
処理フロー

実際の動作イメージ
レビュアーがnitsコメントを投稿すると、自動で以下のような流れになります:
- コメント検知:
[nits]またはnitsで始まるコメントを検知 - Devin起動通知: 「Devinに修正を依頼しました。しばらくお待ちください...」
- セッション開始通知: 「Devinが修正作業を開始しました」+ セッションURL
- 修正完了通知: 「Devinが修正を完了しました!」+ コミットリンク

PR作成者は何もしなくても、数分後には修正が完了しています。
3. 技術実装
使用技術
- GitHub Actions: ワークフローの実行基盤
- Devin API: AIエージェントのセッション作成
- GitHub API: PRコメントへの返信
ワークフロー構成
2つのワークフローで構成しています:
- review-nits-auto-fix.yml: nitsコメント検知 → Devinセッション作成
- review-nits-auto-fix-complete-notify.yml: 修正完了の通知
nitsコメントの検知
- name: Check if comment starts with "nits", "[nits", or ")にも対応しています。
Devin APIの呼び出し
- name: Create Devin session for nits fix id: devin env: DEVIN_API_KEY: ${{ シークレット }} # ... 各種環境変数 run: | PROMPT=$(cat <<EOF !fix_nits_comment ## PR情報 - リポジトリ: ${REPO_FULL_NAME} - PR URL: ${PR_URL} - ブランチ: ${PR_HEAD_REF} ## レビューコメント - ファイル: ${COMMENT_PATH} - 行番号: ${COMMENT_LINE} - コメント内容: ${COMMENT_BODY} ## 該当箇所のコード(diff hunk): \`\`\` ${COMMENT_DIFF_HUNK} \`\`\` ## コメントID ${COMMENT_ID} EOF )
diff hunkにより該当箇所のコードコンテキストを渡すことで、Devinが正確に修正箇所を特定できるようにしています。
修正完了の検知
Devinがコミットする際のメッセージ形式を規定し、それを検知して通知します:
- name: Check if commit is from Devin nits fix id: check env: COMMIT_MESSAGE: ${{ github.event.head_commit.message }} run: | # コミットメッセージから comment-id を抽出 # 形式: nits: {修正内容} [comment-id:12345] if echo "$COMMIT_MESSAGE" | grep -qE '^nits:.*\[comment-id:[0-9]+\]'; then COMMENT_ID=$(echo "$COMMIT_MESSAGE" | grep -oE '\[comment-id:[0-9]+\]' | grep -oE '[0-9]+') echo "matched=true" >> $GITHUB_OUTPUT echo "comment_id=$COMMENT_ID" >> $GITHUB_OUTPUT fi
コミットメッセージに[comment-id:XXX]を埋め込むことで、どのコメントへの対応なのかを追跡可能にしています。
4. 今後の展望
効果測定
導入してまだ間もないため定量的な効果測定はこれからですが、以下の指標を計測予定していければと考えています。
- nitsコメントから修正完了までの時間
- Devinの修正成功率
- PR作成者の作業時間削減効果
根本的な仕組み改善へ
今回紹介した仕組みは、nitsコメントが投稿された後に自動修正する対症療法的なアプローチです。
より根本的な解決として、nitsコメントをコード規約に落とし込み、PR実装時に自動で準拠させる仕組みを検討しています。
具体的には
- nitsパターンの蓄積・分析: レビューで頻出するnitsを収集
- コード規約への反映: CLAUDE.mdなどのAI向け指示書に明文化
- 実装時の自動準拠: AIエージェントがPR作成時点で規約に従ったコードを生成
そもそもnitsコメントが発生しない状態を目指します。
ただ規約化が追いついていないnitsコメントを拾って規約化の対象として抽出できるため仕組み自体は残しておく価値があると考えています。
5. まとめ
コードレビューのnitsコメントをDevinで自動対応する仕組みを紹介しました。
この仕組みにより、レビュアーは「nitsコメントを書くだけ」で修正が完了するようになりました。今後もAI活用で開発サイクルをさらに改善していきたいと思います。
さいごに
ホワイトプラスでは、ビジョンやバリューに共感していただけるエンジニアを募集しています!
ネットクリーニングの「リネット」など「生活領域×テクノロジー」で事業を展開している会社です。
どんな会社か気になった方は、オウンドメディア「ホワプラSTYLE」をぜひご覧ください。
エンジニアの方向けのエントランスブック「WHITEPLUS Entrance Book for Engineer」もございます。
オンラインでカジュアル面談もできますので、ぜひお気軽にお問い合わせください!