授業の4人チーム開発を実務に近づけたくて、CodeRabbitとCI・ADR・PRルールを整えた話

こんにちは、わかとです！

今回は、学校の授業で取り組んでいる4人チーム開発で、AIコードレビューツール「CodeRabbit」を導入した話です。

導入した理由は、単にAIにバグを発見してもらいたかったからではありません。

せっかくチームで開発するなら、できるだけ実務に近い開発プロセスを経験したかったからです。

普段の個人開発では、自分で実装して、そのまま変更を反映することもあります。

しかし、チーム開発では、自分以外の人もコードを読み、変更し、必要に応じて設計判断を共有する必要があります。

そこで、GitHub Issues、Pull Request、GitHub Actions、ADR、CodeRabbitなどを組み合わせ、開発の進め方から整備してみました。

実際にCodeRabbitから指摘を受けて修正した例や、運用を見直して気づいたことも紹介します。

1. 開発しているもの

今回の対象は、「じょぶはん」というWindowsデスクトップアプリです。

面接・面談の練習や振り返りを支援するアプリで、本人の発話を記録・整理し、何を話したのか、どのように話したのかを後から振り返れることを目指しています。

初期版はElectron・React・TypeScriptを中心に構成しています。

• GitHubリポジトリ

授業の4人チームで開発するプロジェクトです。

ただし、現在のリポジトリに実装されているのは、主にElectronの起動やReactの表示、テストなどの開発基盤です。音声認識やログ保存、AIによる振り返りなどは、今後実装する機能です。

2. なぜCodeRabbitを導入したのか

今回やりたかったのは、CodeRabbitだけを導入することではありません。

実務の開発では、コードを書くこと以外にも、さまざまな作業があります。

例えば、取り組む課題をIssueとして管理したり、変更をPull Requestとして共有したり、テストやレビューを通して問題を確認したりします。

また、設計の判断を後から振り返れる状態にしておくことも重要です。

そこで、次のような流れを目指しました。

Issueを作成
    ↓
Branchを作成
    ↓
実装・修正
    ↓
lint / test / build
    ↓
Pull Requestを作成
    ↓
CodeRabbitによるレビュー
    ↓
人間による確認・必要な修正
    ↓
Merge

もちろん、これをチーム全員が毎回完全に実行できているかというと、まだ検証・整備している段階です。

しかし、最初から開発のルールを考えることで、単に作品を完成させるだけではなく、チームでコードを継続的に変更する経験も得たいと考えました。

3. CodeRabbitの前に、開発の土台を整える

実際のGitHub履歴を見ると、2026年9月22日に開発基盤に関するPRをまとめて作成しています。

例えば、以下のPRです。

PR	内容
#39	CodeRabbitのレビュー方針
#40	チーム開発用ドキュメント・テンプレート
#41	GitHub Actionsの品質ゲート
#45	ADRの導入
#47	CodeRabbitのレビュー言語を日本語化
#51	Codex用の変更仕上げSkill

この中で大事にしたかったのが、各ツールの責務を分けることです。

Issue：何をするのか

Issueには、作業の目的や背景、完了条件などを記録します。

原則として、1つのIssueは1つの責務を表すようにしています。

ただし、IssueとPRを必ず1対1にする必要はありません。

ADR：なぜその判断をしたのか

ADRはArchitecture Decision Recordの略で、重要な設計判断と、その理由を残すためのものです。

技術選定では、「何を採用したか」だけでなく、「なぜそれを採用したか」「ほかにどのような選択肢があったか」を残すことを意識しました。

GitHub Actions：実行結果で検証する

lint、test、typecheck、buildなどの再現可能な検証を行います。

ここはAIの感想ではなく、実際のチェック結果を重視します。

CodeRabbit：設計や変更内容をレビューする

CodeRabbitには、テストだけでは発見しにくい潜在的な問題や、ドキュメントと実装の不一致などを確認してもらいます。

ただし、指摘を採用するかどうかは人間が決めます。

このように、それぞれの役割を分けて考えました。

4. PRを細かく分けることを目的にしない

開発ルールを整える際、途中で方針を変更した部分もあります。

最初はPRの単位や変更範囲を、もう少し厳密に管理することを考えていました。

しかし、4人のチームで必要以上にPRを分割すると、かえって作業が増える可能性があります。

そこで、PR #43とPR #44で、ルールを簡素化しました。

現在のCONTRIBUTING.mdでは、次のような方針にしています。

• Issueは原則として1つの責務で分ける
• PRは複数のIssueやレイヤーを横断してもよい
• PRはレビュー可能な範囲でまとめる
• 分割が必要な場合は、レビューの難しさや競合、ロールバックなどを理由に判断する
• ルールを守ること自体が作業になったら見直す

個人的に、ここは大切だと思っています。

実務に近い開発を目指すことと、厳しいルールを大量に作ることは同じではありません。

プロセスは開発を進めるための手段であって、プロセスそのものが目的にならないようにしたいと考えました。

• CONTRIBUTING.md

5. CodeRabbitのレビュー方針をカスタマイズする

CodeRabbitは導入するだけでもレビューしてくれます。

ただ、今回はプロジェクトの技術構成に合わせて、どのような観点でレビューしてほしいかを設定しました。

リポジトリ直下の.coderabbit.yamlを利用しています。

まず、レビュー言語を日本語にしています。

language: "ja-JP"
reviews:
  auto_review:
    enabled: true
    drafts: false

次に、ディレクトリごとのレビュー方針を設定しています。

例えばElectron側のレビューでは、以下のような観点を指定しています。

path_instructions:
  - path: "apps/desktop/**"
    instructions: |
      - Electronのmain / preload / rendererの責務境界を確認してください。
      - contextIsolation、sandbox、nodeIntegration、IPCの公開範囲が安全な設定になっているか確認してください。
      - rendererへNode.jsのfilesystem、任意のIPC、秘密情報を直接公開していないか確認してください。

※実際の設定の一部を抜粋しています。

ほかにも、将来のバックエンド、WebSocket、Supabase、ADR、CIなどについて、それぞれ確認してほしい内容を設定しています。

ここで注意したいのが、レビューの指示を書いたことと、その対象の実装が存在していることは別という点です。

現在の設定には将来構成を想定したディレクトリも含まれています。

そのため、実際のディレクトリ構成が変わった場合は、CodeRabbitの設定も更新する必要があります。

• 実際の.coderabbit.yaml

6. CodeRabbitが実際に発見した問題

ここからは、実際のPRレビューを紹介します。

対象はPR #65：Node.js / Electronの開発環境を追加です。

このPRでは、Electron・React・TypeScriptの最小構成を追加しました。

CodeRabbitからは2件の修正可能な指摘が投稿されました。

6.1 CSPがReact Refreshを妨げる問題

最初の指摘は、Content Security Policy（CSP）に関するものでした。

Electronでは、Rendererで実行できるスクリプトを制限するためにCSPを設定しています。

今回の初期実装では、インラインJavaScriptの実行を禁止していました。

しかし、開発時に利用するViteのReactプラグインは、React Refreshのためにインラインのpreambleを追加します。

そのため、CSPによって開発時の動作が妨げられる可能性がありました。

CodeRabbitは、この問題をMajorとして指摘しました。

そこで、ViteのHTML変換処理を利用し、開発サーバーが存在する場合だけCSPを変更するようにしました。

const developmentCsp: Plugin = {
  name: "jobuhan-development-csp",
  transformIndexHtml: {
    order: "post",
    handler(html, context) {
      if (!context.server) {
        return html;
      }
      const scriptPolicy =
        "script-src 'self' http://127.0.0.1:5173;";
      if (!html.includes(scriptPolicy)) {
        throw new Error(
          "開発用Content Security Policyが見つかりません。"
        );
      }
      return html.replace(
        scriptPolicy,
        "script-src 'self' http://127.0.0.1:5173 'unsafe-inline';",
      );
    },
  },
};

これによって、開発時のみインラインスクリプトを許可し、本番ビルドでは禁止を維持しています。

修正後には、Vite変換テスト、開発版ElectronのDOM表示、本番HTMLのCSPを確認した記録が残っています。

CodeRabbitも修正差分を確認し、レビュースレッドを解決しました。

ただし、CodeRabbit自身が実機テストを再実行したわけではありません。

実際の動作検証は、開発者側で行う必要があります。

6.2 GitHub Actionsの認証情報に関する問題

2件目はGitHub Actionsのセキュリティに関する指摘でした。

初期状態では、actions/checkout@v5で取得した認証情報を、後続のステップから利用できる設定になっていました。

しかし、後続のnpm ciでは、依存パッケージのインストールスクリプトが実行される場合があります。

そこでCodeRabbitは、不要な認証情報を保持しないためにpersist-credentials: falseを指定するよう提案しました。

修正後の設定は以下です。

- name: リポジトリを取得
  uses: actions/checkout@v5
  with:
    persist-credentials: false

もともとGitHub Actionsの権限は以下のように制限していました。

permissions:
  contents: read

しかし、権限を読み取り専用にしていても、後続の処理に認証情報を渡す必要があるかは別の問題です。

この指摘は、普段当たり前のように使っているCIの設定を見直すきっかけになりました。

修正後にはCodeRabbitからも確認の返信があり、スレッドが解決されています。

• PR #65のレビュー履歴

7. AIレビューを受けた後、どうやって品質を確認するか

このPRでは、CodeRabbitの指摘を修正した後、人間側で再レビューを記録しています。

確認した内容は次のようなものです。

• CSPの修正によって開発時の画面表示が維持されること
• 本番ビルドのCSPが意図せず緩和されないこと
• CIの認証情報保持が無効になっていること
• lint・test・typecheck・buildが成功すること
• Windows上のGitHub Actionsが成功すること

重要なのは、CodeRabbitから「問題なし」と言われたことだけを根拠にしないということです。

例えばCSPの問題であれば、修正したコードを読むことと、実際に開発環境が動くことを確認するのは別です。

CodeRabbitは修正差分の妥当性をレビューできますが、すべての実行環境での動作を保証するわけではありません。

そこで、GitHub Actionsなどによる再現可能な検証と組み合わせています。

また、CodeRabbitのレビューが完了しない場合でも、必ず開発を停止する運用にはしていません。

CodeRabbitは補助レビュアーであり、最終的なマージ判断は人間が行う方針です。

8. CodeRabbitはドキュメントの矛盾も指摘してくれた

もうひとつ面白かったのが、設計資料に対するレビューです。

PR #68では、技術構成に関するSkillを追加しました。

その中で、Electron・React・TypeScript・SQLiteという構成を記載していました。

しかし、実際にはSQLiteへのログ保存はまだ実装されていません。

CodeRabbitは、SQLiteを採用する方針と、実装が完了しているという状態を混同しないように指摘しました。

これは、型チェックやlintでは検出できない問題です。

実装と資料を照らし合わせて初めて分かる、意味的な不一致です。

ほかにもPR #55では、ADRと設計書の矛盾、MVPの範囲、技術構成の説明などについて複数の指摘がありました。

こうしたレビューを通して、CodeRabbitにはコードの問題だけでなく、設計・ドキュメントのレビューも期待できることが分かりました。

ただし、すべての矛盾を検出できるとは限りません。

実際、現在のリポジトリにも、古いADRと新しいREADMEの方針が一致していない部分が残っています。

9. AIレビューの指摘を必ず修正するべきなのか

ここは今回、特に考えた部分です。

個人的には、AIの指摘をすべて採用する必要はないと思っています。

レビューは、変更内容に問題がないかを考えるための材料です。

例えば、アプリケーションの要件を理解していない状態で提示された指摘や、将来の機能まで想定した過剰な提案は、必ずしも採用する必要がありません。

しかし、採用しない場合でも、なぜ採用しないのかを判断する必要があります。

ここは、自分たちの運用でも改善できる部分です。

実際、PR #68では、CodeRabbitによるSQLiteの指摘と、人間によるCanva編集リンクの公開範囲に関する指摘が、GitHub上で未解決の状態のままマージされています。

このことだけでマージ判断が誤りだったとは断定できません。

しかし、後から確認する人にとっては、指摘を確認して許容したのか、修正を別Issueへ移したのか、それとも見落としたのかが分かりません。

そのため、今後は指摘を採用しない場合も、短く理由を残す運用を考えています。

例えば、次のような判断です。

• 指摘が妥当なので、今回のPRで修正する
• 指摘は妥当だが今回の変更範囲外なので、Issueに切り出す
• 現在の要件では問題がないため、理由を記録して対応しない
• 指摘内容に誤りがあるため、検証結果を示して対応しない

大切なのは、AIの指摘を機械的に受け入れることではなく、指摘を検証し、その判断に責任を持つことだと思います。

10. レビュー枠の制限も考える必要があった

CodeRabbitを運用していると、レビュー枠の制限にも遭遇しました。

2026年10月20日のGitHub通知では、公開OSSの無料レビュー枠を使い切り、次の利用可能枠まで30分待つ必要があるという通知がありました。

また、10月9日にはAdvancedトライアルの終了に伴い、非公開リポジトリのレビューが停止されたというメールも届いています。

プランや制限は変更される可能性があるため、ここでは実際に受け取った通知に基づく話として紹介します。

もしCodeRabbitのレビュー完了を必須条件にすると、利用枠の制限によって開発が止まる可能性があります。

そこで、現状ではCodeRabbitを必須のマージゲートにはしていません。

自動テストで確認できる部分はGitHub Actionsに任せ、CodeRabbitはレビューを補助する役割としています。

ツールを導入するときには、その機能だけでなく、利用できない場合にどう開発を続けるかも考える必要があると感じました。

11. 今の運用にも改善点がある

今回、改めてリポジトリ全体を確認すると、まだ整備途中の部分もありました。

mainブランチの保護

GitHub Actionsで品質チェックを実行していますが、mainブランチの保護ルールはまだ完了していません。

Issue #17で、直接pushの制限や必須チェック、レビュー人数などを管理しています。

CIが存在することと、CIに失敗した変更をマージできないことは別です。

レビュー担当の明確化

4人チームの主担当・副担当・レビュー範囲の確定も進行中です。

Issue #6では、重要な領域を特定の1人しか理解できない状態にしないことを目標にしています。

また、CODEOWNERSについても、実際の担当とディレクトリ構成が固まってから追加する方針です。

古い開発構成の残存

初期段階ではGoを用いたバックエンドを検討していましたが、現在はElectron・React・TypeScriptが中心です。

しかし、Codexの変更仕上げSkillに含まれる検証スクリプトには、Goのgo.modを前提にした処理が残っています。

また、Dependabotの設定もGo ModulesやDockerを中心としたものが残っています。

このため、現行のNode.js構成と開発支援ツールの設定をそろえる必要があります。

ADRとREADMEの整合性

さらに、過去のSupabaseを採用するADRがAcceptedのまま残っている一方、現在のREADMEでは初期版にSQLiteを採用する方針になっています。

設計判断を変えること自体は問題ありません。

むしろ、プロダクトの要件が変化したときに技術構成を見直すことは自然です。

ただし、その変更理由をADRとして残し、古い判断との関係を整理する必要があります。

ここは、CodeRabbitを導入したからこそ、今後さらに改善したい部分です。

12. CodeRabbitを使って感じたこと

今回CodeRabbitを導入して感じたのは、AIコードレビューの価値は、単純にバグを発見することだけではないということです。

レビューを通して、自分が普段意識していない観点に気づくことができます。

CSPの指摘では、開発体験とセキュリティの両立を考えることになりました。

GitHub Actionsの指摘では、CIで利用する認証情報の扱いを確認することになりました。

ドキュメントレビューでは、採用予定の技術と実装済みの技術を明確に区別する必要があると分かりました。

一方で、CodeRabbitだけで品質を保証できるわけではありません。

実際のコードや変更差分を確認し、テストを実行し、プロダクトの要件を踏まえて判断することは、引き続き人間の役割です。

また、CodeRabbitによる指摘を扱うルールそのものも、チームに合わせて調整する必要があります。

おわりに

今回は、授業の4人チーム開発を実務に近づけるために、CodeRabbitやGitHub Actions、ADR、PRルールなどを整備した話を紹介しました。

CodeRabbitを導入したこと自体よりも、レビューを開発プロセスのどこに置き、何を任せ、何を任せないかを考えたことが、今回の大きな学びだったと思います。

また、最初は多くのルールを整備することを考えていましたが、途中でPRのルールを簡素化したり、CodeRabbitを必須のマージゲートにしなかったりと、開発を止めないための判断も行いました。

実務に近づけるというのは、単にツールを増やすことではないのだと思います。

チームの人数や開発するプロダクトに合わせて、必要なプロセスを選択することが重要です。

現在はまだ開発基盤を整えている段階で、チーム全員がこの運用をどの程度活用できるかについても、これから検証していく必要があります。

それでも、コードを書くことだけでなく、レビュー・テスト・設計判断・変更履歴まで含めて開発する経験を積みたいと思っています。

AIにコードを書いてもらえる時代だからこそ、そのコードをどう検証し、チームとして責任を持つかを考えていきたいです。

ここまで読んでいただきありがとうございました！

---

参考資料

• じょぶはん GitHubリポジトリ
• CodeRabbitのレビュー設定
• CodeRabbitの運用方針
• チーム開発のルール
• PR #65：Electronの開発環境とCodeRabbitの修正
• PR #68：技術構成に関するレビュー
• CodeRabbit公式サイト