
Claude Codeで5時間のセッション制限を、1時間で使い果たしてどうしようかなという顔をしています。
今回はSINIS for Instagramの開発にClaude Code GitHub Actionsを導入してレビューを自動化した話を、会社制度の紹介も交えてまとめようと思います。
はじめに
SINIS for Instagramの開発チームでは、コードレビューの効率化を目指してClaude Code GitHub Actionsを導入しました。 本記事では、導入の背景から実装、社内制度「AWSジム」を活用した運用、そしてレビュープロンプトの改善過程について紹介します。
Claude Code GitHub Actionsとは
Claude Code GitHub Actionsは、Anthropicが提供するエージェント型AIツール「Claude Code」を、GitHubのワークフロー(CI/CD)に統合するための仕組みです。
コメントで @claude とメンションすることで、GitHub上のIssueやPR内でClaudeを直接操作できます。コードレビューをはじめとしたタスクの自動化が可能になります。
公式ドキュメント:
Claude Code GitHub Actions - Claude Code Docs
導入背景
昨今、AIエージェントなどの利用に伴って開発スピードが向上し、その分PR数も増大しています。 一方で、中数精鋭を掲げるテテマーチはエンジニアの人数も限られており、レビュアー不在時にリリースが滞るなど、レビューがボトルネックになり始めていました。 また、AI活用も進める中でエンジニアがより本質的な設計や機能実装に集中できる環境の構築もしたい、といった意思決定のもとAIレビューの導入に至りました。
実装
ワークフロー設定
以下が実際に使用しているワークフロー設定です。
name: Claude PR Action permissions: contents: write pull-requests: write issues: write id-token: write on: issue_comment: types: [created] pull_request_review_comment: types: [created] issues: types: [opened, assigned] jobs: claude-pr: if: | (github.event_name == 'issue_comment' && contains(github.event.comment.body, '@claude')) || (github.event_name == 'pull_request_review_comment' && contains(github.event.comment.body, '@claude')) || (github.event_name == 'issues' && contains(github.event.issue.body, '@claude')) runs-on: ubuntu-latest timeout-minutes: 15 env: AWS_REGION: ap-northeast-1 steps: - name: Checkout repository uses: actions/checkout@v6 - name: Generate GitHub App token id: app-token uses: actions/create-github-app-token@v2 with: app-id: ${{ secrets.APP_ID }} private-key: ${{ secrets.APP_PRIVATE_KEY }} - name: Configure AWS Credentials (OIDC) uses: aws-actions/configure-aws-credentials@v5 with: role-to-assume: ${{ secrets.AWS_ROLE_TO_ASSUME }} aws-region: ap-northeast-1 - uses: anthropics/claude-code-action@v1 with: github_token: ${{ steps.app-token.outputs.token }} use_bedrock: "true" claude_args: | --model jp.anthropic.claude-sonnet-4-5-20250929-v1:0 --max-turns 20 --append-system-prompt "日本語でレビューすること。プロフェッショナルなエンジニアとして、ベストプラクティスとプロジェクトの規約に基づいて違反がないかレビューすること。" show_full_output: "true"
ポイント解説
1. GitHub App Token
デフォルトの GITHUB_TOKEN ではなくGitHub Appトークンを使用しています。GITHUB_TOKEN で作成されたコミットやコメントはワークフロー実行者の名義になり、他のワークフローのトリガーにもならないなど制約があります。GitHub Appを使うことで、Botとして適切な権限と名義でアクションを実行できます。
2. Amazon Bedrock経由での利用
社内のAWSジム制度(月額上限$100のAWS費用補助)の枠内で検証コストを賄うため、Anthropic APIの直接利用ではなくAmazon Bedrock経由を選択しました。AWS OIDCによる認証を行い、APIキーの管理を不要にしています。
3. 日本語対応
--append-system-prompt でカスタムプロンプトを追加し、日本語でのレビューを指示しています。
AWSジム制度の活用
AWSジム制度とは
テテマーチでは「AWSジム制度」というエンジニア向けの学習支援制度があります。エンジニアが業務で使う技術の習得だけでなく、新しい技術を自由に試したりスキルを高めたりできるよう、会社がAWSのサーバー費用を月額上限100ドルまで負担する制度です。
参考: 【エンジニア向け制度紹介】社員の希望を元にボトムアップで制度化した学習支援の『AWSジム制度』とは?
本導入での活用
Claude Code GitHub ActionsをAmazon Bedrock経由で利用することで、AWSジム制度の枠内で技術検証を行うことができました。
- 本番導入前の検証をAWSジム環境で実施
- Bedrockの料金体系や使用量の把握
この制度があることで、新しい技術を業務に導入する前にリスクを抑えながら十分な検証ができます。ありがたいですね。
レビュープロンプトの改善
初期プロンプトの問題
前述のワークフロー設定に記載した通り、導入当初のプロンプトは「プロフェッショナルなエンジニアとして、ベストプラクティスとプロジェクトの規約に基づいて違反がないかレビューすること」というシンプルなものでした。
指示の方向性としては間違っていないのですが、「プロフェッショナルなエンジニアとして」という曖昧な指示とフォーマットを指定しないプロンプトが、そのまま曖昧なレビューに繋がりました。
発生した課題
実際に運用してみると、AIレビューの指摘を読むこと自体がコストになるという本末転倒な状態に陥りました。
具体的にはこんな問題です。
- PRの差分と無関係な既存コードへのリファクタリング提案が大量に出る
- 「この実装は良いですね」といった褒めコメントがノイズになる
- 「改善の余地があります」のような、具体性を欠く指摘が混在する
- 問題がないファイルに対しても冗長なコメントが付く
レビューの効率化を目的に導入したにもかかわらず、AIの出力を精査する作業が新たなボトルネックになっていました。

改善のアプローチ
これらの課題に対し、プロンプトを段階的に改善していきました。
1. レビュースコープの明示
差分と、差分が影響を与える既存コードのみをレビュー対象として明示し、スコープ外の改善提案を禁止しました。これだけでPRに関係のないリファクタリング提案がかなり減ります。
2. チェック観点の構造化
「プロフェッショナルとしてレビューせよ」という曖昧な指示を廃止し、設計・コード品質・セキュリティ・プロジェクト規約の4軸でチェック観点を具体的に定義しました。CLAUDE.mdに記載しているプロジェクト固有の規約(BEM命名規則、MUIのsx prop禁止、any型の使用禁止など)も明示的に含めています。
3. 出力フォーマットの厳密化
問題がない場合は「レビュー完了。指摘事項なし。」とだけ出力するよう指示し、冗長なコメントを排除しました。問題がある場合も、重要度を🔴 must(マージブロッキング)と🟡 suggestion(推奨)の2段階に限定し、レビュアーが優先度を即座に判断できるフォーマットにしています。
4. 禁止事項の明示
褒めコメント、総合評価スコア、コード品質マトリクスなど、レビューの本質と無関係な出力を明示的に禁止しました。
出力フォーマットを厳密に定義するだけでも大部分のノイズは消えますが、それでも漏れてくるものがあります。LLMは指示がなければ「丁寧で網羅的な」出力を志向するので、禁止事項で明示的に潰す必要がありました。望ましい振る舞いを定義した上で、それでも出てくる不要な出力を禁止事項で補完する、という順序が効果的でした。
改善後のプロンプト
現在フロントエンドのリポジトリで運用しているプロンプトの全文です。初期プロンプトと見比べると、だいぶ構造化されたのがわかると思います。
日本語でレビューすること。Next.js, React, TypeScript, Sassのプロフェッショナルとして、PRの差分および差分が影響を与える既存コードをレビュー対象とする。 # レビュースコープ - PRの差分、および差分が影響を与える既存コードをレビュー対象とする - ただし、差分と無関係な既存コードのリファクタリング提案はしない - PRのスコープ外の改善提案はしない # チェック観点(内部チェックリスト) 以下の観点で差分をチェックし、問題がある場合のみ指摘する。問題がない観点については言及不要。 ## 設計 - アーキテクチャへの適合性 - オーバーエンジニアリング ## コード品質 - 命名の適切さ、可読性 - ループ・ロジックの単純さ、早期リターン、ネストの深さ - マジックナンバー、未使用変数 ## セキュリティ・堅牢性 - 入力値検証(SQLi/XSS) - 認可チェック - 機密情報のハードコーディング - 例外処理漏れ、エッジケース ## プロジェクト規約(CLAUDE.md準拠) - BEM命名規則、CSS Modules - Typography共通コンポーネントの使用 - MUIのsx prop禁止 - GraphQL generated.tsxの手動編集禁止 - any型の使用禁止 # 出力ルール - 問題がない場合: 「レビュー完了。指摘事項なし。」とだけ出力する - 問題がある場合: 以下のフォーマットで出力する ## 出力フォーマット(問題がある場合のみ) ### 指摘事項 指摘のみを箇条書きで記載する。各指摘は以下の形式: - **[重要度]** ファイルパス:行番号 — 指摘内容 重要度は以下の2段階: - 🔴 must: マージ前に修正が必要 - 🟡 suggestion: 修正を推奨するが、ブロッキングではない ### 確認済み 問題がなかった観点をチェックリストで示す: - [x] 設計 - [x] コード品質 - [x] セキュリティ - [x] プロジェクト規約 # 禁止事項 - 良い点・褒める記述は書かない - 総合評価・スコア・点数は書かない - コード品質の表やマトリクスは作らない - 差分と無関係なリファクタリング提案はしない - 「改善の余地がある」程度の曖昧な指摘はしない(具体的な問題のみ指摘)
導入効果
- セキュリティ・堅牢性の指摘精度: 人間が見落としがちなセキュリティ観点や例外ハンドリングの抜け漏れに対して、一貫して指摘が入るようになった
- レビュー品質の平準化: レビュアー個人のスキルや経験に依存していた気づきの差が縮まり、一定の品質を保ちやすくなった
- レビュー依頼前の品質担保: 人間のレビューに出す前にAIレビュアーとやり取りすることで、実装者自身がセルフ修正を済ませた状態でレビュー依頼できるようになった
まとめ
Claude Code GitHub Actionsの導入により、コードレビューの効率化を実現しました。Amazon Bedrock経由での利用とAWSジム制度の活用で、セキュリティを担保しつつ新しい技術を検証できる環境が整っています。
一方で、AIレビューは導入して終わりではなく、プロンプトの継続的な改善が不可欠です。初期の汎用的なプロンプトではノイズが多く逆効果になりましたが、レビュースコープの制限・チェック観点の構造化・出力フォーマットの厳密化・禁止事項の明示を段階的に行うことで、実用的なレビュー品質に到達しました。
導入を検討されている方の参考になれば幸いです。
テテマーチでは、一緒にサービスを作り上げてくれる仲間を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください! herp.careers エンジニアチームガイドはこちら! https://tetemarche01.notion.site/30bdd1fbde384fcfbb641775956ba4c2tetemarche01.notion.site