Claude CodeとGitHubの連携完全ガイド:GitHub Actions・コードレビュー・git操作まで徹底解説【2026年最新】
前回はClaude Codeのスキル機能について解説しましたが、今回はClaude CodeとGitHubの連携に踏み込んでいきます。GitHub Actionsで@claudeと書くだけでAIがPRを作成してくれたり、コードレビューを自動化できたりと、開発ワークフローが大幅に変わる内容です。
室谷Claude CodeとGitHubの連携、これ正直まだ使いこなせていないエンジニアが多いと思うんですよね。「claude code github」「claude code git」で調べる人が急増してるんですが、実際に導入できているかというと・・・
テキトー教師受講生さんに聞くと、GitHub Actionsの設定がよくわからないとか、何ができるのかイメージしにくいという声がほんとに多いですね。セットアップ自体は実はかなり簡単なんですが、「何のためにやるか」が見えていないと踏み出せない。
室谷そうなんですよ。MYUUUのチームでも最初に導入したときは「これ本当に動くの?」って半信半疑だったんですが、@claudeってコメントしたらClaudeがPRを作ってきて、チーム全員が「え、これやばい」ってなりました(笑)
テキトー教師その体験が一番伝わりますよね。今回は実際に何ができるか、どうやってセットアップするか、セキュリティ上の注意点まで、順番に整理していきましょう。
Claude CodeのGitHub連携でできることを整理する
室谷まず「claude code github」で調べている人が知りたいのは、大きく分けると2つだと思います。1つはGitHub Actionsとの連携、もう1つは普段のgit操作をClaude Codeでどうやるかという話。
テキトー教師そうですね。GitHub ActionsはCI/CDの話で、日常のgit操作はローカルでの話。
ここを混同している受講生さんが多いです。大きく分けるとこういう構造になります。
ここを混同している受講生さんが多いです。大きく分けるとこういう構造になります。
| 機能 | 概要 | 実現場所 |
|---|---|---|
| Claude Code GitHub Actions | @claudeメンションでPR作成・実装・修正を自動化 | GitHub上(クラウド) |
| GitHub Code Review | PRを開くたびに自動コードレビュー | GitHub上(クラウド) |
| claude code git操作 | コミット・PR作成・差分確認をClaude Codeのターミナルから実行 | ローカル |

室谷GitHub Actions連携が一番インパクトが大きいですね。IssueのタイトルとURLを貼って「@claude 実装して」と書けば、Claudeが実際にコードを書いてPRを出してくれます。
テキトー教師それ、講座で実演すると毎回どよめきが起きます(笑)。ただ、実際のプロダクト開発に使うには、CLAUDE.mdでプロジェクトのコーディング規約を正確に書いておく必要があります。
室谷そこ大事ですよね。コーディング規約を渡していないと、Claudeが自己流で書いてきてレビューで全部修正するはめになる。
CLAUDE.mdを整備してから導入するのが正解だと思います。
CLAUDE.mdを整備してから導入するのが正解だと思います。
Claude Code GitHub Actionsのセットアップ方法

室谷セットアップは公式が「Quick setup」と「Manual setup」の2パターンを用意しているんですが、Quick setupの方が圧倒的に楽です。
テキトー教師ターミナルでClaude Codeを開いて、
/install-github-appというコマンドを実行するだけですよね。これ、受講生さんに試してもらったら10分かからずに終わってびっくりしてました。
室谷ただし注意点があって、リポジトリのAdminアクセスが必要です。あとQuick setupは直接AnthropicのAPIキーを使っている人向けで、AWS BedrockやGoogle Vertex AI経由の場合は手動セットアップになります。
Quick setupの手順
テキトー教師Quick setupの流れを整理するとこうなります。
- ターミナルでClaude Codeを開く
/install-github-appを実行- 指示に従ってGitHub Appをインストール
- リポジトリシークレットに
ANTHROPIC_API_KEYを追加 .github/workflows/にワークフローファイルを配置
室谷ワークフローファイルはGitHubが用意しているサンプルを参考にするのが一番手っ取り早いですね。基本的なものはこんな感じです。
name: Claude Code
on:
issue_comment:
types: [created]
pull_request_review_comment:
types: [created]
jobs:
claude:
runs-on: ubuntu-latest
steps:
- uses: anthropics/claude-code-action@v1
with:
anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
テキトー教師これで、IssueやPRのコメントで@claudeとメンションすると、Claudeが反応して動き始めます。デフォルトのトリガーフレーズは
@claudeですが、trigger_phraseパラメータで変更できます。
室谷v1.0がリリースされてから、設定がすっきりしましたよね。ベータ版を使っていた人は注意が必要で、いくつか破壊的変更があります。
ベータ版からv1.0への移行ポイント
テキトー教師旧ベータ版から移行する場合は、主に4つの変更点があります。
| 旧ベータ版 | v1.0 |
|---|---|
mode: "tag" / mode: "agent" | 不要(自動検出) |
direct_prompt | prompt |
custom_instructions | claude_args: --append-system-prompt |
max_turns | claude_args: --max-turns |
室谷設定がシンプルになった代わりに、
claude_argsに集約されましたね。--max-turnsや--modelもここで指定します。
テキトー教師モデルも指定できるのが地味に大事で、デフォルトはSonnetですが、より高性能なOpus 4.6を使いたい場合は
claude_args: "--model claude-opus-4-6"で切り替えられます。Manual setupの手順(Bedrock/Vertex AI対応)
室谷AWSやGCPを使っている企業だと、セキュリティポリシーの関係でAPIキーを直接GitHubに渡したくないというケースがありますよね。そういう場合はManual setupでBedrockやVertex AI経由にする。
テキトー教師手順としては、GitHub Appをまずインストールして、その後クラウドプロバイダー側でOIDC認証を設定する流れになります。AWSの場合はこんなイメージです。
- GitHub Appを
https://github.com/apps/claudeからインストール - AWSでGitHub用のOIDCプロバイダーを設定(URL:
https://token.actions.githubusercontent.com) - IAMロールを作成してAmazon Bedrock権限を付与
- ロールのARNをGitHubシークレット
AWS_ROLE_TO_ASSUMEに設定 - ワークフローファイルに
use_bedrock: "true"を追加
室谷OIDCを使うと、固定のアクセスキーが不要になるのでセキュリティ的に優秀ですね。GCPのWorkload Identity Federationも同じ思想です。
MYUUUでもAPIキーを直接渡すのは嫌なのでこっちを使っています。
MYUUUでもAPIキーを直接渡すのは嫌なのでこっちを使っています。
Claude CodeがGitHubでできること:実践的なユースケース
室谷セットアップができたとして、実際に何をやらせるかというのが肝心です。「@claude」って呼び出せる状態になったとして、どう使うか。
テキトー教師講座でよく紹介するのは3つのパターンです。IssueからのPR作成、PRのコードレビュー、バグ修正の依頼。
この3つが現場での実用性が高いと思いますよ。
この3つが現場での実用性が高いと思いますよ。
室谷IssueからPRを作らせるのは本当に便利で、「@claude implement this feature based on the issue description」って書くだけでClaudeがリポジトリのコードを読んで、仕様に合った実装をしてPRを出してくれます。
テキトー教師ただ「実装して」だけだとコーディング規約に合わないコードを書いてくることがある。CLAUDE.mdにプロジェクト固有のルールを書いておくのと、コメントで具体的に指示するのが重要です。
@claudeで使えるコマンド例
室谷実際にどんなコメントを書くか、よく使うパターンをまとめてみました。
| 用途 | コメント例 |
|---|---|
| 機能実装 | @claude implement this feature based on the issue description |
| バグ修正 | @claude fix the TypeError in the user dashboard component |
| コードレビュー | @claude review this PR for security vulnerabilities |
| リファクタリング | @claude refactor this function to improve readability |
| テスト追加 | @claude add unit tests for the auth module |
| ドキュメント生成 | @claude document all exported functions in this file |
テキトー教師日本語でも通じますよ、というのは受講生さんにいつも伝えています。「@claude このPRにセキュリティの問題がないかレビューして」でも動きます。
英語の方が精度が安定している印象はありますが、実用上は日本語で十分です。
英語の方が精度が安定している印象はありますが、実用上は日本語で十分です。
室谷あと地味に便利なのが「@claude how should I implement user authentication for this endpoint?」みたいな質問ができること。コードを書かせるだけじゃなくて、実装の相談相手としても使えます。
テキトー教師技術的な意思決定をGitHub Issueのコメントで記録できるのがいいですよね。「この設計にした理由」がスレッドに残る。
自動化ワークフローの設計
室谷GitHub Actionsの醍醐味は、スケジュール実行やPR作成時の自動トリガーができることですよね。毎朝9時に昨日のコミットサマリーを作らせるとか。
name: Daily Report
on:
schedule:
- cron: "0 9 * * *"
jobs:
report:
runs-on: ubuntu-latest
steps:
- uses: anthropics/claude-code-action@v1
with:
anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
prompt: "Generate a summary of yesterday's commits and open issues"
claude_args: "--model claude-opus-4-6"
テキトー教師PRが開かれたら自動でコードレビューをするのもよく使われるパターンですね。
on: pull_request: types: [opened, synchronize]をトリガーに設定して、promptでレビュー観点を指定する。
室谷ただし、このアプローチには費用が掛かることを念頭に置いておく必要があります。GitHub Actionsの実行コスト+AnthropicのAPIコストの両方が発生するので、頻繁なPushのあるリポジトリで全push時にトリガーすると費用がかなり膨らむ可能性があります。
テキトー教師費用最適化の観点では、
--max-turnsでClaude Codeの最大ターン数を制限すること、concurrency設定で並列実行を制御すること、この2つが重要ですね。claude_args: "--max-turns 5"みたいに設定しておくと暴走しにくいです。GitHub Code Reviewとは:自動コードレビューの仕組み

室谷GitHub Actionsとは別に、「GitHub Code Review」という機能があって、これはAnthropicのインフラで動くマネージドなサービスなんですよね。
テキトー教師GitHub Actionsは自分でワークフローを組む必要があるのに対して、Code Reviewはオンにするだけで動いてくれる。管理者が設定すれば、チームの全員がすぐ使えます。
室谷ただし、対象はTeamプランとEnterpriseプランのみで、Zeroデータ保持を有効にしている組織は使えません。個人の開発者よりも企業での利用が前提ですね。
Code Reviewがどのように動くか
テキトー教師仕組みを整理すると、PRが開かれると複数の専門エージェントが並列でコードを分析します。各エージェントが異なる種類の問題(バグ、セキュリティ脆弱性、エッジケース等)を探して、最後に誤検知を除去する検証ステップが入る。
室谷その結果が、差分の該当行にインラインコメントとして付く。しかも深刻度別に色分けされているのが実用的で、赤がマージ前に直すべきバグ、黄色がnit(微妙な問題)、紫が既存のバグ(このPRで導入したものではない)。
テキトー教師深刻度ラベルが自動で付くので、レビュアーがどこから見ればいいか一目でわかりますよね。「赤が0件なら一旦マージOK」みたいな判断基準を作りやすい。
室谷平均で1回のレビューにかかる費用が$15-25と公式に書かれています。PR規模やコードベースの複雑さによって変わるので、大きなリポジトリでは高くなる可能性があります。
Code Reviewのトリガー設定
テキトー教師トリガーは3種類から選べます。
| トリガー | タイミング | 費用への影響 |
|---|---|---|
| Once after PR creation | PR作成時に1回 | 最も安い |
| After every push | 全pushで実行 | Pushの回数分かかる |
| Manual | @claude reviewコメント時のみ | 必要なときだけ |
室谷Manualモードが費用管理しやすいですよね。「完成したと思ったらレビューを依頼する」という自然なフローにも合っています。
@claude review onceというコメントなら1回だけ、@claude reviewなら以降のpushでも自動実行されます。
テキトー教師この使い分けが重要で、開発中は
@claude review onceで確認して、最終確認は@claude reviewを使うと、コスト管理しながら品質を担保できます。ローカルでのclaude code git操作:コミット・PR・差分確認
室谷GitHub Actionsやマネージドのコードレビューとは別に、ローカルでClaude Codeを使ったgit操作の話もしておきたいんですよね。「claude code git」で調べている人はこっちのニーズが多いと思います。
テキトー教師ローカルでClaude Codeを使うと、コミットメッセージを自動生成してくれたり、PRの説明文を書いてくれたり、差分を解説してくれたりします。ここが地味に便利で、受講生さんがいちばん「あ、これ使える」ってなる部分ですね。
PRの作成をClaude Codeに任せる
室谷ローカルでPRを作る場合は、
gh pr createコマンドと組み合わせながら使うのがよくあるパターンです。「自分が変更した内容をサマリーして」と頼んでから、「PRを作って」と指示する。
テキトー教師公式ドキュメントでもこの流れが紹介されていて、「summarize the changes I've made to the authentication module」→「create a pr」という2ステップで完結します。しかも
gh pr createでPRを作ると、そのセッションがPRに自動でリンクされて、後からclaude --from-pr <number>でそのコンテキストに戻れる。
室谷これが本当に便利で・・・PRを作ったあと「あ、ここ修正しよう」ってなったときに、PRのコンテキストをそのまま引き継いで作業できる。セッションの連続性が保てるのがいいですね。
コミットメッセージの自動生成
テキトー教師コミットメッセージを自動生成させるのも、地味に使い勝手が良いです。差分を見てもらって「このコミットに適切なメッセージを書いて」と頼むと、Conventional Commitsのフォーマットに沿った形で生成してくれます。
室谷MYUUUでもConventional Commitsをルールにしているんですが、忙しいときにfeat: とかfix: とか考えながら書くのがしんどくて。Claude Codeに任せると「feat(auth): add token refresh mechanism」みたいにちゃんとした形で出してくれるのでラクです。
テキトー教師ただ、そのままコピーするのではなく、Claudeが出したメッセージを確認して自分で微調整する習慣を持つといいですよね。Claudeはコードを見て判断しているので、背景情報が足りないと的外れなメッセージになることもあります。
差分確認とコードの解説
室谷「これどういう変更?」というのをClaude Codeに聞くのも便利なんですよね。大規模なPRをレビューするとき、「この差分を3行で要約して」と頼むと、変更の意図をわかりやすく説明してくれます。
テキトー教師講座でもよく使うのが、初めて触るリポジトリのコードを理解するシーンです。「このリポジトリの構造を説明して」「このファイルが何をしているか教えて」と聞くと、かなり的確に解説してくれますよ。
CLAUDE.mdの役割:GitHub連携を最大化する設定ファイル
室谷GitHub Actions連携を導入したときに一番重要なのが、実はCLAUDE.mdなんですよね。Claudeがリポジトリのコーディング規約を知らない状態でPRを作ると、後で全部修正するはめになる。
テキトー教師この室谷さんのツイートで紹介されているアプローチが正解で、CLAUDE.mdは「Repo Memory」として短く保つのがポイントです。長すぎると重要なコンテキストを見落とすし、トークン消費も増える。
室谷CLAUDE.md自体は毎ターンシステムプロンプトとして再注入されるんですよね。ということは、長くなればなるほど毎回のコスト増につながる。
必要なことだけ書く、という意識が大事です。
必要なことだけ書く、という意識が大事です。
CLAUDE.mdに書くべき内容
テキトー教師GitHub Actions連携での実用的なCLAUDE.mdはこんな内容が基本です。
# Project Memory
## Architecture
- TypeScript + React (frontend)
- Node.js + Express (backend)
- PostgreSQL (database)
## Coding Standards
- Use async/await instead of .then()
- Prefer early returns over nested conditionals
- All API routes must have error handling middleware
## Naming Conventions
- Components: PascalCase
- Functions: camelCase
- Constants: UPPER_SNAKE_CASE
## PR Guidelines
- Tests required for all new functions
- Max 400 lines per PR
室谷プロジェクトの構造、コーディング規約、PRのガイドラインを書いておくと、Claudeが書くコードの品質が格段に上がります。「テストを書いて」と言わなくても、自動でテストが付いてくるようになる。
テキトー教師GitHub ActionsでCode Reviewを使っている場合は、REVIEW.mdというファイルも別途作れます。「必ずフラグを立てること」「スキップしていいこと」をレビュー専用に書けるので、CLAUDE.mdとうまく使い分けられます。
REVIEW.mdの使い方
室谷REVIEW.mdはCode Review専用の設定ファイルなんですが、これが実は地味に便利で・・・「生成コード配下のファイルにはコメントするな」とか「ロックファイルのフォーマットはスキップ」みたいな細かい制御ができます。
テキトー教師「新しいAPIルートには必ずインテグレーションテストを要求する」とか「データベースマイグレーションが後方互換性を持っているか確認する」みたいなプロジェクト固有のチェックを追加できるので、コードレビューの質が上がりますよ。
GitHub Enterprise ServerでのClaude Code利用
室谷大企業だとgithub.comではなく、オンプレのGitHub Enterprise Server(GHES)を使っているケースがありますよね。GHESでもClaude Codeは使えるのかという話。
テキトー教師使えます。TeamプランとEnterpriseプランであれば、GHES向けの接続設定があります。
管理者がGHESインスタンスをClaude Codeに接続すれば、開発者はそのまま使えるようになる。
管理者がGHESインスタンスをClaude Codeに接続すれば、開発者はそのまま使えるようになる。
室谷Claude Code on the webもCode Reviewも、Teleportセッション(ウェブとターミナルをセッションを移動させる機能)も対応しているんですが、一点注意があって、GitHub MCP serverはGHESでは使えません。
テキトー教師/install-github-appコマンドもGHES環境では使えないので、Manual setupが必要になります。大企業の導入担当者はここを押さえておく必要がありますね。GHESのセットアップの流れ
室谷GHESのセットアップは管理者が一回やれば、その後は開発者が個別に設定しなくても使えるのが助かるポイントですよね。
テキトー教師流れとしては、管理者が
claude.ai/admin-settings/claude-codeからGHESのセクションに行って、ホスト名を入力してGitHub Appを作成する。プライベート証明書を使っているGHESなら、CA証明書も貼り付けられます。
室谷一度つながれば、開発者は
claude --remoteやclaude.ai/codeをそのまま使えるので、github.comとの使い勝手の差がほぼない。エンタープライズの導入障壁がだいぶ下がりましたよね。セキュリティのベストプラクティス
室谷最後にセキュリティの話をしておきたいですよね。APIキーの管理とかPermissionの設計をしっかりしないと、意図しないコード変更が起きる可能性がある。
テキトー教師一番大事なのはAPIキーをワークフローファイルにハードコードしないことです。必ずGitHub Secretsを使う。
${{ secrets.ANTHROPIC_API_KEY }}という形で参照するのが基本ですね。
室谷GitHub Appのパーミッションも、必要最小限に絞るのが重要です。公式のClaudeアプリは「Contents」「Issues」「Pull requests」の3つのread/writeが必要で、それ以上は要らない。
テキトー教師あと、ClaudeがPRを作ったとしても、最終的にマージするのは人間がレビューしてからというルールは絶対に持った方がいいです。Claudeの提案は概して良質ですが、100%信頼してauto-mergeにするのはリスクがある。
室谷そうですね。「Claudeが書いたコードは必ずチームメンバーが1人以上レビューする」というルールを設けておくと、品質を保ちながら自動化の恩恵を受けられます。
MYUUUではそのルールにしています。
MYUUUではそのルールにしています。
セキュリティチェックリスト
テキトー教師GitHub Actions連携を本番で使う前のチェックリストをまとめておきます。
- APIキーはGitHub Secretsに格納して、ワークフローファイルに直接書かない
- Claude GitHub Appのパーミッションを最小限に設定する
--max-turnsでエージェントの実行上限を設ける- Claudeのコミットには必ずレビューを通す(auto-mergeにしない)
concurrency設定で並列実行を制御してコスト暴走を防ぐ- Adminアクセスを持つ人だけがGitHub Appをインストールできるようにする
室谷あと、ワークフローのタイムアウト設定も大事ですね。
timeout-minutesを設定しておくと、何かのループで暴走したときに止まってくれます。Claude CodeとGitHubを最大限に活用するための考え方
室谷ここまで機能を解説してきましたが、「何をどう使うか」という戦略の話もしておきたいんですよね。全部使えばいいというわけじゃない。
テキトー教師そうですね。GitHub Actions連携は「どのタスクをClaudeに任せるか」を明確にしてから導入するのが大事だと思います。
何でもかんでもClaudeに投げると、意図しない変更が増えて混乱する。
何でもかんでもClaudeに投げると、意図しない変更が増えて混乱する。
室谷MYUUUでやっているのは、「定型的なタスク」と「判断が必要なタスク」を分けること。バグ修正の実装とかドキュメント生成とかテスト追加は定型的なので積極的にClaudeに任せる。
アーキテクチャの設計とか新機能の仕様決めは人間が主導する。
アーキテクチャの設計とか新機能の仕様決めは人間が主導する。
テキトー教師そのラインの引き方が上手いチームと下手なチームで、導入後の満足度が全然変わってきます。「Claudeが書いたコードのレビューで逆に時間がかかった」という話を聞くことがありますが、それはタスクの切り分けが曖昧なことが多い。
室谷.AI(ドットエーアイ)コミュニティでも「Claude Codeの導入で開発速度が上がった」という声と「思ったほど効果がなかった」という声の両方があって、差がどこから来るかというと、まさにそこだと思います。
テキトー教師最初は小さく始めることをおすすめしています。まずは1つのリポジトリだけに入れて、「バグ修正のみ」に限定して使ってみる。
2週間使って効果を感じたら範囲を広げていく、というステップアップの仕方が結果的に一番うまくいくパターンです。
2週間使って効果を感じたら範囲を広げていく、というステップアップの仕方が結果的に一番うまくいくパターンです。
よくある質問(FAQ)
室谷最後に、コミュニティでよく出る質問をまとめておきましょう。
テキトー教師受講生さんからよく来る質問と、私の回答です。
Q. Claude Code GitHub ActionsはどのGitHubプランで使えますか?
テキトー教師GitHub Actionsが使えるプランであれば基本的に使えます。GitHub Freeでも使えます。
ただし、GitHub Code Review(マネージドのコードレビュー)はClaudeのTeam・Enterpriseプランが必要です。
ただし、GitHub Code Review(マネージドのコードレビュー)はClaudeのTeam・Enterpriseプランが必要です。
室谷つまりGitHub Actionsは個人開発者でも使えるけど、Code Reviewは法人・チーム向けということですね。
Q. 日本語のIssueやコメントでも@claudeは動きますか?
室谷動きます。「@claude このIssueを実装したPRを作って」みたいな日本語指示でも問題なく動作します。
ただ、英語の方がClaudeの精度は安定している印象です。
ただ、英語の方がClaudeの精度は安定している印象です。
テキトー教師プロジェクトが英語ベースなら英語で、日本語ベースなら日本語でというのが自然かなと思います。コードはどの言語でも問題なく読んでくれますよ。
Q. Claudeがコミットを過剰に行って、想定外の変更をすることはありますか?
テキトー教師--max-turnsを設定していないと、複数ファイルにまたがって変更を続けることがあります。最初は--max-turns 5程度に設定して様子を見るのがおすすめです。
室谷あと、変更できるファイルを
--allowedToolsで制限するのも有効ですね。「この範囲内だけ変更していい」という制約を与えると安心感があります。Q. GitHub Enterprise Serverでも使えますか?
室谷使えます。TeamプランかEnterpriseプランのClaude組織があれば、管理者がGHESインスタンスを接続することで使えるようになります。
ただし、GitHub MCP serverはGHESでは現状使えません。
ただし、GitHub MCP serverはGHESでは現状使えません。
テキトー教師GHESのセットアップは管理者が一回やれば、あとは開発者が個別に設定する必要はありません。エンタープライズ導入のハードルが低いのがいいですよね。
Q. GitHubのマーケットプレイスでClaude Codeは検索できますか?
テキトー教師「github claude code」と検索すると、GitHub MarketplaceでClaude Code Actionが見つかります。
anthropics/claude-code-actionとして公開されていて、そこからワークフローのサンプルも確認できます。
室谷リポジトリはで公開されているので、詳しい設定オプションやサンプルワークフローはここで確認するのが一番早いですよ。
Q. Claude Code GitHub ActionsとGitHub Copilotを比較するとどうですか?
室谷調べてみると、GitHub CopilotはコードサジェストとチャットがメインなのでIDEの中での補完寄り。Claude Code GitHub ActionsはPRの作成・実装・修正をGitHub上で完結させることが中心という違いがありますよね。
テキトー教師Copilotと競合するというよりも、用途が違う印象です。「IDEで書くときはCopilot、PRの自動化はClaude Code Actions」という組み合わせで使っている人もいますね。
まとめ:Claude CodeとGitHubの連携で変わること
室谷今回の内容を整理するとこうなります。
| 機能 | できること | 必要なプラン |
|---|---|---|
| GitHub Actions(@claude) | PR作成・実装・修正・レビュー | Claude API + GitHub Actions対応プラン |
| GitHub Code Review | 自動PRレビュー(インライン) | Claude Team/Enterprise |
| ローカルのgit操作 | コミット・PR作成の支援 | Claude Codeが使えるプランなら可 |
| GitHub Enterprise Server | GHESでのClaude Code利用 | Claude Team/Enterprise |
テキトー教師一番最初にやるべきことは、Quick setupで
/install-github-appを実行して、1つのリポジトリに基本的なワークフローを入れてみること。まず動かしてみないと実感が湧かないので、10分で試せるこのステップが大事です。
室谷CLAUDE.mdをしっかり整備してから本格運用に入る、というのも忘れないでほしいですね。コーディング規約をClaudeに教えておくことで、出てくるコードの質が全然変わります。
テキトー教師段階的に使い慣れていくことが重要です。小さく始めて、効果を確認しながら広げる。
.AI(ドットエーアイ)コミュニティで先行事例を聞きながら進めると、失敗しにくいと思います。
.AI(ドットエーアイ)コミュニティで先行事例を聞きながら進めると、失敗しにくいと思います。
