Claude CodeとGitHubの連携方法｜3つの連携パターン・設定手順・GitHub Actionsの例【2026年版】

Claude CodeとGitHubの連携は、IssueやPRへのコメントひとつで、実装からPR作成までをClaudeに任せられる「エージェント型ワークフロー」として広く使われています。連携の方法は、①手元のClaude Codeがgit・GitHub CLIを操作する、②GitHub Actionsに組み込んで「@claude」で動かす、③GitHubのMCPサーバーにつなぐ、の3つが基本です。いちばん手早いのは、リポジトリのフォルダで claude を起動して /install-github-app を実行する方法で、GitHub Appの導入・認証のシークレットの登録・ワークフローの追加までを順に案内してくれます。

本記事では、公式ドキュメント（2026年10月14日確認）に基づいて3つの統合レイヤーと関連機能を整理し、設定の手順、コピペで使えるワークフロー、ブランチ戦略・権限設計・コスト管理の勘所、見落とされがちな失敗パターンを解説します。なお、コードを書き換えずにClaude（クロード）のチャット画面へリポジトリを読ませたいだけなら、Claude Codeは要りません（後述）。

結論：目的別に選ぶClaudeとGitHubの連携の種類（早見表）

「ClaudeとGitHubの連携」と呼ばれるものは、公式の機能だけでも7種類あります。何をしたいかで選ぶ方法が変わるため、まず次の表で当たりをつけてください（2026年10月14日に公式ドキュメントで確認）。

初めてなら、まず手元のClaude Code（レイヤー1）でGitHubとのやり取りに慣れ、チームで使う段階でGitHub Actions（レイヤー2）を足す順番が無理のない進め方です。以下、それぞれの仕組みと手順を説明します。

チーム全体で自動的に回す段階になったときは、自動化（automation）実装ガイドで解説しています。

関連記事Claude Codeの外部連携コマンドは？

Claude Code × GitHubの現在地

調査会社のSemiAnalysisは2026年2月に、GitHubの公開コミットのうち約4%がClaude Codeによるものだと推定しました（出典：Gigazine）。同じ分析は、2026年末に20%へ達する可能性も示しました。数字は推定値ですが、AIがコード補完の延長ではなく、ブランチ作成からPRまでのGitのワークフロー全体に入り込みつつあることを示しています。

Claude Codeは、Issueを起点にブランチ作成・実装・コミット・PR作成までを一気通貫で処理できるエージェントで、1行ずつ候補を出す「補完ツール」とは、与える権限もリスクの種類も異なります（出典：Ledge.ai）。導入するときは、この違いを押さえたうえで、自分のチームのワークフローに合う連携の形を選ぶことが大切です。Claude Codeそのものの基本はClaude Codeとは、料金の全体像は料金ガイドで解説しています。

はじめに押さえる用語

この記事で使う言葉を、初めての方向けに短くまとめます。

Claude CodeとGitHubを連携してできること

• Issueの内容を読んで実装し、ブランチを切ってコミット・push、PRの作成まで進める（手元のClaude Code・GitHub Actions）
• PRの差分をレビューして、問題のある行にインラインコメントを付ける（GitHub Actionsのレビュー用ワークフロー・Code Review）
• PRで落ちたCIやレビューコメントに合わせて、修正をpushする（クラウドのClaude Codeの自動修正）
• 前日のコミットや未対応のIssueの要約など、決まった時刻の処理を自動で回す（GitHub Actionsのスケジュール実行・ルーティン）
• リポジトリのファイルを読ませて、設計や不具合の原因を相談する（Claudeのチャット画面）

どれも「人がレビューしてからマージする」ことを前提にした機能です。Claudeが作ったPRやコメントをそのまま本番へ流さない設計も、あわせて考えておきます（後述のブランチ戦略・権限設計）。

claude code github連携の3つの統合レイヤー：選択基準と実装上の差異

Claude CodeとGitHubを連携させる方法は、権限の持ち方・自動化の範囲・運用コストの違いから、3つのレイヤーに整理できます。混同したまま導入すると、権限が広すぎる、意図しない自動コミットが起きる、費用が膨らむ、といった問題を招きます。どれを選ぶかは好みではなく、チームがどこまでのリスクを許容でき、どこまで自動化に慣れているかで決めます。

レイヤー1：ローカルCLI × Gitコマンド直接実行

最もシンプルで、リスクの低い連携です。Claude Codeを手元にインストールし（インストールガイド参照）、リポジトリのフォルダで起動すると、ファイルの構成・Gitの履歴・差分を読み取ったうえで作業します。GitHubへのpushやPRの作成には、手元のgitとGitHub CLI（gh）の認証をそのまま使うため、Claude Code専用のトークンは要りません。

手順は次のとおりです（公式の Common workflows の「Create pull requests」に沿った流れです）。

1. GitHub CLIを入れてログインする：GitHub CLI（gh）を入れ、gh auth login でGitHubにログインします。ClaudeはPRの作成や確認に gh を使います
2. リポジトリのフォルダで起動する：git clone したフォルダに移動し、claude を実行します
3. 変更を頼む：「Issue #12 の要件を実装して、テストが通ったらコミットして」のように、対象と完了の条件を書いて依頼します
4. PRを作らせる：「変更内容を要約して」→「create a pr（PRを作って）」→「PRの説明に、セキュリティ面の変更点を足して」と、段階的に頼めます
5. あとで続きをする：claude --from-pr 1234（自分のPRの番号）で、そのPRにひも付いたセッションを選んで再開できます。Claudeが gh pr create でPRを作ったとき、セッションとPRがひも付きます

確認なしでpushされる点に注意します。公式の権限モードのドキュメントによると、Claude Code v2.1.283以降は、ターミナルとVS Codeで始めたセッションの最初の権限モードが auto です（設定ファイルや組織の方針で変わる場合があります）。auto では、作業中のリポジトリのブランチへのpush（既定のブランチを含む）と、依頼に沿ったPRの作成が、確認なしで実行されます。一方で、force push、未コミットの変更を消すコマンド、秘密情報がリポジトリの外へ出るコミット、別のリポジトリや組織へのPRなどは、背後の安全チェックが止めます。pushの前に必ず人の確認を挟みたい場合は、設定ファイルに次の permissions.ask を書きます（2026年10月14日確認）。

{
  "permissions": {
    "ask": [
      "Bash(git push *)",
      "Bash(gh pr create *)"
    ]
  }
}

この書き方は、git push や gh pr create で始まるコマンドに当たります。git -C <dir> push のような別の書き方のpushには当たらないため、確実に止めたい場合はPreToolUseフックを使うよう公式は説明しています。すべての操作を1つずつ確認したいときは、Shift+Tab で Manual モード（設定値は default。確認なしで動くのは読み取りだけ）に切り替えるか、claude --permission-mode manual で起動します。権限の考え方はClaude Codeの権限設定で詳しく解説しています。

あわせて、コミット署名（GPG）やpre-commitフックとの相性も事前に確かめておきます。特に、git-secretsなどの秘密情報の検出フックが、Claudeのコミットでも正しく動くかは必ず確認します。Qiitaの実践例（nakamasato「Claude Code AIコーディング開発サイクル」2026/01/18、Qiita）では、GitHubのIssueで計画を固めてからClaude Codeに渡す手順が有効とされています。手元で使う場合でも、Issueを「渡す文書」として整えておく習慣が精度に直結します。

レイヤー2：GitHub Actionsへの組み込み（Claude Code Action）

公式ドキュメント（Claude Code GitHub Actions）によると、公式アクションの claude-code-action（検索では「claude code action」とも呼ばれます）をワークフローに入れると、PRやIssueで @claude とメンションするだけで、コードの分析・実装・バグ修正・PR作成をGitHubのランナー上で実行できます。Anthropicが公開している claude-code-action のリポジトリには、そのまま使えるワークフローの例がそろっています。

典型的な使い方は次の3つです。

• PRやIssueの @claude メンションで、質問への回答やレビューのコメントを返す
• Issueのコメントで @claude に指示し、実装用のブランチを作ってPRを出させる
• prompt を書いたワークフローで、PRが開かれたときや決まった時刻に、メンションなしで自動実行する

セットアップは、手元のClaude Codeで /install-github-app を実行する「クイックセットアップ」と、自分で設定する「手動セットアップ」の2通りです。手順・認証の方法（APIキーかサブスクリプションのトークンか）・使える条件は、次の章にまとめています。使うモデルは claude_args に --model を書いて指定し、書かなければClaude Codeの既定のモデルが使われます。APIの料金体系と消費量の見積もり方はAPIコスト解説記事で詳しく解説しています。

レイヤー3：MCP（Model Context Protocol）経由のGitHub統合

GitHubが公開しているMCPサーバーをClaude Codeにつなぐと、Claude CodeがIssue・PR・リリースなどを、ツールとして直接読み書きできるようになります。手元のClaude Codeと組み合わせれば、「Issueの番号を渡すだけで、内容の確認から実装・PR作成まで進める」流れを組めます。

公式のMCPのドキュメントでは、GitHubの設定画面で、対象のリポジトリにだけアクセスできるfine-grainedの個人アクセストークンを作り、次のコマンドで登録する手順が紹介されています（2026年10月14日確認。YOUR_GITHUB_PAT を自分のトークンに置き換えます）。

claude mcp add --transport http github https://api.githubcopilot.com/mcp/ \
  --header "Authorization: Bearer YOUR_GITHUB_PAT"

claude mcp add は、トークンが正しいかを確かめずに設定を保存します。上の画面のとおり、仮の文字列のままでも登録はでき、接続を確かめる段階で失敗します。つないだあとは claude mcp list か、Claude Codeの中で /mcp を実行し、サーバーが connected と表示されるかを確かめます。認証情報が誤っていると failed と表示され、HTTPのステータスも示されます（公式は401を例に挙げています。この記事の手元で仮のトークンのまま試したときはHTTP 400でした）。保存先は、既定では自分だけ・そのプロジェクトだけ（local）です。--scope project を付けると .mcp.json に書かれてチームで共有でき、--scope user を付けると全プロジェクトで使えます。MCPの全体像はClaude CodeのMCPで解説しています。

なお、公式ドキュメント（GitHub Enterprise Server対応ページ）によると、GitHubのMCPサーバーはGitHub Enterprise Server（GHES）では使えません。GHESでは代わりに、GHES向けに設定した gh（gh auth login --hostname github.example.com）をClaudeに使わせる方法が案内されています。

このレイヤーは自律度が最も高い分、権限の設計と監視が不十分なまま導入すると、意図しない操作が起きるリスクも最も大きくなります。トークンは対象のリポジトリだけに絞り、有効期限を短くしておきます。

クラウドのClaude Code（ブラウザ・スマホ）からGitHubを使う

手元のPCではなく、Anthropicが用意するクラウドの環境でClaude Codeを動かす方法もあります。ブラウザの claude.ai/code、Claudeアプリの「Code」タブ、デスクトップアプリ（「Cloud」を選ぶ）、ターミナルの claude --cloud から始められ、PCを閉じても作業が続きます。使えるのはPro・Max・Teamと、Enterpriseのプレミアム席などで、プランの利用枠を使います（クラウドのマシン代は別にかかりません）。公式ドキュメントで確認した、GitHubまわりの要点は次のとおりです（2026年10月14日確認）。

• GitHubのつなぎ方は2通り：ブラウザの初回設定でClaude GitHub Appを許可する方法（公開リポジトリと、Appを入れた非公開リポジトリが対象）と、ターミナルで /web-setup を実行し、手元の gh のトークンをClaudeのアカウントに送る方法（そのトークンで見られるリポジトリが対象）があります
• 認証情報の扱い：Anthropicの環境では、GitHubの認証情報は暗号化してサーバー側に置かれ、セッションのマシンには入りません
• PRの自動修正（Auto-fix）：Claude GitHub Appを入れたリポジトリでは、PRのCIが落ちたときやレビューコメントが付いたときに、Claudeが調べて修正をpushします。ターミナルでは、PRのブランチで /autofix-pr を実行すると始められます
• 注意：自動修正の中でClaudeがPRのコメントに返信すると、自分のGitHubアカウントの名前で投稿されます（Claude Codeが書いたことを示す表示付き）。コメントをきっかけに動くデプロイなどの自動化があるリポジトリでは、それが起動することがあるため、公式は事前の確認を求めています

ブラウザ版の始め方はClaude Code on the webの解説で紹介しています。

3つのレイヤー以外の公式のGitHub連携

公式ドキュメントは、名前の似た関連機能として次のものを挙げています。ワークフローのファイルを自分で書かずに済むものもあるため、目的に合えばこちらのほうが手間は少なくなります（2026年10月14日確認）。

• Code Review：ワークフローを書かなくても、PRを自動でレビューし、問題のある行にコメントを付ける機能です。Team・Enterpriseで使える研究プレビューで、料金は使用量に応じて決まり、定額の1回あたり料金はありません（PRの大きさなどで変わり、平均は管理画面で確認できます）。プランの利用枠とは別に、使用量クレジットで請求されます。ほかのプランでも、手元で /code-review を実行して差分をレビューできます
• ルーティン：スケジュール・APIの呼び出し・GitHubのイベント（PRやリリースなど）をきっかけに、クラウドでClaude Codeを動かす機能です。Pro・Max・Team・Enterpriseで使える研究プレビューで、GitHubのイベントで動かすには、リポジトリにClaude GitHub Appが必要です。ルーティンは個人のアカウントに属し、コミットやPRは自分のGitHubユーザーとして記録されます
• Claude Agent SDK：GitHub Actions以外の場所で独自の自動化を組むための部品です。GitHub Actions用の公式アクションも、この上に作られています
• GitHub Enterprise Server：自社で運用するGitHubとつなぐ場合の対応です（後述）

これらの機能は、同じClaude GitHub Appを共用しています。Appをインストールするときは、機能ごとに権限を選ぶことはできず、まとめて許可する形になります。GitHub Actions用のアクションが使うのは、そのうちContents・Issues・Pull requestsの3つです。

Claude Codeを使わずに、Claudeのチャット画面へGitHubのリポジトリを読ませる方法

「ClaudeとGitHubの連携」には、Claude Codeではなく、ブラウザやアプリのClaude（チャット画面）にリポジトリのファイルを読ませる使い方もあります。コードの内容について質問したい、設計の相談をしたい、という目的ならこちらで足ります。手順はAnthropic公式ヘルプのとおりです（2026年10月14日確認）。

• チャットで使う：入力欄の左下の「+」から「Add from GitHub」を選び、ファイルやフォルダを選んでからメッセージを送ります。GitHubに未接続なら、先にGitHubの認証画面へ移ります
• プロジェクトで使う：プロジェクトの知識（project knowledge）の右上の「+」から「GitHub」を選び、リポジトリを検索するかURLを貼って、読ませるファイルやフォルダを選びます。内容を新しくするときは「Sync」、読ませるファイルを変えるときは「Configure files」を使います
• 読み込まれる範囲：指定したブランチのファイル名と中身だけです。コミット履歴やプルリクエストなどは読み込まれません。1つのチャットやプロジェクトに複数のリポジトリを追加することもでき、Claudeが一度に読める量に収まる範囲で使えます
• 非公開リポジトリが出てこないとき：GitHub App側で、そのリポジトリへのアクセスを許可します（組織のリポジトリは管理者の承認が必要です）。シングルサインオンを必須にしている組織では、GitHubの設定画面（Applications）でClaudeに組織へのアクセスを許可します。接続をやり直しても解決しません。Enterprise Managed Users（EMU）の組織では、管理アカウントでサインインし、SSOのセッションがある状態で接続します

この方法はファイルを読ませるための連携で、公式ヘルプにはリポジトリへ書き込む手順は書かれていません。ブランチの作成・コミット・PRの作成まで任せたい場合は、本記事の3つのレイヤー（Claude Code）を使います。

実装後すぐ使える：コピペ可能なGitHub Actions YAMLとv1.0移行チェック

3つのレイヤーのうちGitHub Actionsを選ぶ場合に、押さえておきたい手順・動く設定ファイルの形・v1.0での変更点をまとめます。以下は公式ドキュメントと公式リポジトリ（anthropics/claude-code-action）に基づく内容です。

セットアップの手順：クイックセットアップと手動セットアップ

公式ドキュメントでは、Claude Code GitHub Actionのセットアップは2通りです。どちらもリポジトリの管理者権限が必要です（2026年10月14日確認）。

• クイックセットアップ：リポジトリのフォルダで claude を起動し、/install-github-app を実行して案内に従います。Claude CodeがGitHub Appを入れ、認証用のシークレットを登録し、ワークフローのファイルを入れたブランチをpushして、GitHubをブラウザで開きます。作成待ちのPRを作ってマージすると、そのリポジトリで @claude が動くようになります
• 手動セットアップ：Claude Codeを手元で動かさない場合、コマンドが失敗した場合、ワークフローのファイルを自分で管理したい場合の方法です。次の3つを自分で行います
  1. Claude GitHub App をリポジトリに入れる
  2. 認証用のシークレットを追加する（APIキーなら ANTHROPIC_API_KEY、サブスクリプションなら claude setup-token で作ったトークンを CLAUDE_CODE_OAUTH_TOKEN として登録）
  3. 公式リポジトリの examples/claude.yml を .github/workflows/ に置く（そのまま動くワークフローです。サブスクリプションの場合は anthropic_api_key の行を claude_code_oauth_token に変えます）

クイックセットアップを始める前に、次の条件を確かめておきます。

• GitHub CLI（gh）を入れ、gh auth login でログインしておきます（無い場合は警告が出ます）
• 対象はgithub.comのリポジトリだけです。GitLabやBitbucketのリポジトリでは、案内を出して終了します（GitLabには別の「GitLab CI/CD」の手順があります）
• Claude APIのキーでも、Claudeのサブスクリプションでも設定できます。Amazon Bedrock・Google CloudのAgent Platform・Microsoft Foundry経由で使う場合は、クラウド事業者向けの手順で設定し、ワークフローに use_bedrock: "true"・use_vertex: "true"・use_foundry: "true" のどれかを指定します（認証はOIDCで行い、固定の認証情報をリポジトリに置きません）

認証の方法は2つあります。1つはClaude Consoleで発行したAPIキーを ANTHROPIC_API_KEY という名前でシークレットに登録する方法で、使った分だけAPIの従量課金になります。もう1つは、手元で claude setup-token を実行して作ったトークンを CLAUDE_CODE_OAUTH_TOKEN として登録する方法で、Pro・Max・Team・Enterpriseのサブスクリプションの利用枠で動きます。ワークフローでは、前者は anthropic_api_key、後者は claude_code_oauth_token に渡します。クイックセットアップでは、Claude CodeにすでにAPIキーがあればそれを使い、無ければ「サブスクリプションで長期のトークンを作る」か「APIキーを貼る」かを選びます。

途中で止めたいときは Esc を押します。実行中の手順は終わり、あとの手順は始まりません。最後のメッセージに、pushしたブランチや保存したシークレットなど、すでに行われたことが一覧で出ます。GitHub Appを入れたあとに「Skip for now」を選べば、Appだけを入れた状態で止められ、あとで /install-github-app をもう一度実行すれば続きから進められます。すでに claude.yml があるリポジトリでは「Update workflow file with latest version」を選ぶと、新しい版のワークフローが新しいブランチに入ります。レビュー用のワークフローを選んだ場合、Claudeはレビューを、見つけた問題ごとのインラインコメントか、問題が無いときは1つのまとめのコメントとしてPRに投稿します（draftなど一部のPRは対象外です）。

この端末では、GitHubにログインした状態でしか進めない手順のため、/install-github-app の実行画面は掲載していません。上の画面は公式ドキュメントの表示です。

コピペで使える最小構成YAML（v1.0系）

PRやIssueで @claude とメンションしたときに応答させる、最もシンプルな構成は次のとおりです。

name: Claude Code
on:
  issue_comment:
    types: [created]
  pull_request_review_comment:
    types: [created]
jobs:
  claude:
    if: contains(github.event.comment.body, '@claude')
    runs-on: ubuntu-latest
    permissions:
      contents: write
      pull-requests: write
      issues: write
      id-token: write
      actions: read
    steps:
      - uses: actions/checkout@v6
        with:
          fetch-depth: 1
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}

これは公式ドキュメントに載っている例と同じ内容です（2026年10月14日確認。手元のリポジトリでの実行確認はしていません）。押さえておく点は次のとおりです。

• contents: write：Claudeがファイルを書き換えてコミットするために必要です。read のままでは、質問への回答はできても変更を書き込めません
• id-token: write：アクションが既定で使う、GitHub Appとしての認証に必要です
• actions: read：PRのCIの結果をClaudeが読めるようにします
• if の行：@claude を含まないコメントで、ランナーが起動するのを防ぎます
• サブスクリプションで動かす場合は、anthropic_api_key の行を claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }} に置き換えます

設定できたら、IssueやPRのコメントに「@claude この不具合を直してください」のように書くと、Claudeが同じIssue・PRにコメントで返信し、作業の進み具合に合わせてそのコメントを更新します。

PRのレビューを毎回自動で実行し、ターン数や使うツールを明示したい場合は、v1.0で追加された claude_args にまとめて書きます。

      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          prompt: "このPRの差分をレビューし、バグとセキュリティ上の懸念点を指摘してください"
          claude_args: |
            --max-turns 10
            --allowedTools Read,Grep,Glob

prompt を書いたワークフローは、メンションを待たずに動きます。この場合、結果は既定ではコメントではなく、ワークフローの実行ログに出ます。また、普通の文章のプロンプトでは、Claudeはシェルの実行やGitHub APIを使えないため、必要なツールを --allowedTools（または settings の permissions.allow）で渡します。上の例はファイルを読むツールだけを許可しています。実際の運用では、permissions のスコープもタスクに必要な最小限に絞ります。

PRが開かれたり更新されたりしたときに自動でレビューさせる例も、公式ドキュメントに載っています（プラグインの code-review を使う形。2026年10月14日確認。この記事では実行していません）。

name: Code Review
on:
  pull_request:
    types: [opened, synchronize, ready_for_review, reopened]
jobs:
  review:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: read
      issues: read
      id-token: write
    steps:
      - uses: actions/checkout@v6
        with:
          fetch-depth: 1
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          plugin_marketplaces: "https://github.com/anthropics/claude-code.git"
          plugins: "code-review@claude-code-plugins"
          prompt: "/code-review:code-review --comment ${{ github.repository }}/pull/${{ github.event.pull_request.number }}"
          claude_args: '--allowedTools "mcp__github_inline_comment__create_inline_comment"'

--comment を付けると、レビューがPRへのコメントとして投稿されます（付けないと何も投稿されず、結果はワークフローの実行ログで読みます）。claude_args の行は、インラインコメントを投稿するためのMCPサーバーを起動させるために必要なので残します。公開リポジトリでは、フォークからのPRにはGitHubがシークレットを渡さないため、同じリポジトリ内のブランチからのPRだけが対象になります。Claudeは、draftや閉じたPR、自動生成のような軽いPR、すでにClaudeのコメントがあるPRはレビューしません。ワークフローを自分で管理せずに自動レビューだけ使いたい場合は、前述の公式の Code Review もあります。

決まった時刻に動かす：毎日のレポートの例

prompt を書けば、cronのスケジュールを含むどのGitHubのイベントでも動かせます。公式ドキュメントには、毎日9時（UTC）に前日のコミットと未対応のIssueを要約し、ワークフローの実行ログに出す例が載っています（2026年10月14日確認。この記事では実行していません）。GitHub APIの2つのツールだけを許可し、APIで読むため、リポジトリのチェックアウトは省いています。

name: Daily Report
on:
  schedule:
    - cron: "0 9 * * *"
jobs:
  report:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      issues: read
      id-token: write
    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-5-5
            --allowedTools "mcp__github__list_commits,mcp__github__list_issues"

GitHubは、スケジュールのワークフローを既定のブランチからしか動かしません。公開リポジトリでは、60日間リポジトリに動きが無いとスケジュールが止まります。スケジュールでの実行は、書き込み権限の確認は行われませんが、ボットかどうかの確認は行われます（cronを最後に変えたユーザーがボットなら、allowed_bots に入れます）。Claudeのクラウド側で定時に動かしたい場合は、前述のルーティンも使えます。

よく使う入力（パラメータ）

ワークフローの with: に書く主な入力です（公式ドキュメントの Action parameters と Who can trigger runs から整理。2026年10月14日確認）。

v0.x → v1.0 破壊的変更 対応表

@beta タグの設定を流用したまま @v1 に切り替えると、下の表のパラメータ名の違いで、設定が無視されたりエラーになったりします。移行の前に必ず確認してください。

出典：anthropics/claude-code-action 公式移行ガイド

実装の勘所：ブランチ戦略・権限設計・コスト管理の3要素

ブランチ戦略：AI専用ブランチの設計方針

Claude Codeによる自動コミットを本番のブランチに直接流すと、レビューされていない変更が混ざるリスクがあります。前述のとおり、手元のClaude Codeは auto モードでは既定のブランチへのpushも確認なしで行うため、ブランチの保護はGitHub側の設定で確実にかけておきます。DevelopersIOの記事（2026/03/20、DevelopersIO）でも、コードベースの規模に応じたコンテキストの管理が重要だと指摘されており、ブランチの設計とコンテキストの設計は表裏一体で考えます。おすすめの構成は次のとおりです。

• claude/<issue-number> のような命名規則でAIの作業用ブランチを作り、人のブランチと明確に区別する（ルーティンやクラウドのセッションも claude/ で始まるブランチを作ります）
• ブランチ保護ルールで main・develop への直接のpushを止め、PRを通さないマージを禁止する
• PRの最終承認を人が行う「ヒューマン・イン・ザ・ループ」を必須にし、自動マージは段階的に導入する

前述のQiitaの実践例のように、IssueでPlan（計画）を固めてから実装に入る形にすると、設計と実装の工程が分かれ、エージェントが想定外の方向へ進むのを抑えられます。

また、公式の Common Workflowsドキュメント では、並行するセッションの編集がぶつからないよう、git worktreeを使う方法が勧められています。claude --worktree feature-auth のように名前を付けて起動すると、別のブランチの作業用フォルダで独立したセッションが始まり、別のターミナルで別の名前を付ければ並行して作業できます（リポジトリに1つ以上のコミットが必要です）。複数のClaude Codeを同時に走らせるときは、この方法でマージのコンフリクトを大きく減らせます。

権限設計：最小権限の原則を維持する

公式ドキュメントによると、GitHub App経由でClaude Code GitHub Actionsをセットアップする場合、アクションが使うのはContents・Issues・Pull requestsの読み書きの権限です（Appをインストールするときは、ActionsやChecksなどを含む権限一式が求められます。一覧は後述の表のとおりです）。GitHub Actionsで連携するときにClaude Codeへ渡すトークンのスコープは、使い方に応じて絞り込みます。一般的な権限の対応を次の表にまとめました。

claude code github連携における権限スコープの推奨設定

ユースケース	必要なGitHubスコープ	推奨トークン種別	備考
コードレビューコメント生成のみ	pull-requests: write	GITHUB_TOKEN（Actions標準）	GitHub側の権限の例です。Claudeを動かす認証（APIキーかOAuthトークン）は別に必要です
ブランチ作成・コミット	contents: write	Fine-grained PAT	リポジトリ単位で制限し組織全体への権限付与を避ける
Issue読み取り・コメント	issues: write	Fine-grained PAT	読み取りのみならreadで十分
MCP経由フルエージェント動作	contents: write + pull-requests: write + issues: write	Fine-grained PAT（有効期限短縮）	定期ローテーションと監査ログの有効化を必須化

なお、公式アクションは github_token を渡さなければ、ClaudeのGitHub Appとして認証するのが既定の動作で、自前のトークンは必須ではありません。標準の GITHUB_TOKEN を渡した場合、そのトークンで作られたコミットではGitHubがほかのワークフローを起動しないため、ClaudeのコミットでCIが動かなくなる点に注意します（公式ドキュメントのトラブルシューティング）。

Fine-grained PATは、組織（Organization）単位ではなくリポジトリ単位で発行すると、万一漏れたときの影響範囲を限定できます。トークンの有効期限は長くても90日以下にし、GitHub Actionsのシークレットへの登録とローテーションの手順を、運用手順書として残しておきます。公式ドキュメントでは、コードはGitHubのランナー上にとどまる設計であることが「Secure by default」として明示されています（Claude Code GitHub Actions）。

組織で使うとき・やめるときの手順（公式）

クイックセットアップも手動セットアップも、1つのリポジトリごとの設定です。組織全体に広げる場合、公式ドキュメントは次の形を挙げています（2026年10月14日確認）。

• Claude GitHub Appを組織に1回だけ入れ、すべてのリポジトリか、選んだリポジトリに適用する
• 認証のシークレットは、組織レベルのActionsシークレットに置く（リポジトリごとに持たない）。共有するシークレットには、claude setup-token で作ったOAuthトークンではなく、Claude ConsoleのAPIキーを使うよう公式は勧めています（OAuthトークンは、作った人のサブスクリプションにひも付くため）
• ワークフローのファイルは、使いたいリポジトリごとに置くか、再利用できるワークフローとして1か所で定義し、各リポジトリから呼び出す
• 長期のシークレットを持ちたくない場合は、GitHubのOIDCトークンとClaude Consoleのサービスアカウントを使う、ワークロードアイデンティティ連携も使えます（anthropic_federation_rule_id と anthropic_organization_id などの入力を指定し、ワークフローに id-token: write を付けます）

Appをインストールするときに、GitHubが求める権限は、公式ドキュメントでは次の一式と説明されています。GitHub Appの権限は機能ごとには選べず、一式を受け入れる形になります（Code Reviewやクラウド版の自動修正など、同じAppを使うほかの機能の分も含まれます）。

権限	アクセス
Actions／Checks／Contents／Discussions／Issues／Pull requests／Repository hooks／Workflows	読み書き
Administration／Members／Merge queues／Metadata／Statuses	読み取り

これより狭い権限にしたい組織は、Contents・Issues・Pull requestsだけを持つ自前のGitHub Appを作る方法があると、公式は説明しています（ただしこの場合も、Code Reviewやクラウド版の自動修正には公式のAppが必要です）。また、Appが新しい権限を求めるようになったときは、GitHubがアカウントの所有者（組織なら組織の所有者）に承認を求め、承認されるまでは以前の権限のまま動きます。

やめるときは、(1) .github/workflows/ から anthropics/claude-code-action を使うワークフロー（クイックセットアップなら claude.yml と、選んだ場合は claude-code-review.yml）を削除、(2) ANTHROPIC_API_KEY または CLAUDE_CODE_OAUTH_TOKEN のシークレットを削除（シークレットを消しても元のキーは有効なままなので、完全に止めるにはConsoleでもキーを削除します）、(3) ほかのClaudeの機能（Code Reviewなど）で使っていなければGitHub Appをアンインストール、の順で行います。クラウド事業者を使っていた場合は、その認証用のシークレットと自前のGitHub Appも削除します。

コスト管理：トークン消費の実態と上限設計

費用について、公式ドキュメントは「1回の実行で2種類の資源を使う」と説明しています。1つはGitHub Actionsの実行時間（GitHub側の課金）、もう1つはClaudeのトークン（プロンプトと応答の長さ、タスクの複雑さ、コードベースの大きさで変わります）です。OAuthトークンで認証している場合は、APIの課金ではなく、サブスクリプションの利用枠を使います。

DevelopersIOの記事（2026/03/20）では、リポジトリ全体を読み込んだ状態での1タスクあたりのトークン消費量は、コードベースの規模に強く左右され、大規模なモノレポではコンテキストの圧迫が精度の低下と費用の増加の両方を招くと指摘されています。公式ドキュメントが挙げる対策を含め、効果のある方法は次のとおりです。

• CLAUDE.md を簡潔に保つ（実行のたびに読み込まれるため）。@claude への依頼は具体的に書き、Issueのテンプレートで前提を先に渡す
• claude_args の --max-turns で、やり取りの回数に上限を付ける
• タスクをIssue単位に細かく分け、1回の呼び出しで渡すコンテキストの量を絞る
• ワークフローのジョブにタイムアウトを設定し、止まらない実行による費用の超過を防ぐ
• GitHubの同時実行の制御（concurrency）で、並列で走る実行の数を抑える
• Claude Consoleで月ごとの利用上限を設定し、予算の超過に気づけるようにしておく

金額はタスクの粒度・コードベースの規模・モデルで大きく変わるため、少数のIssueで試して自分のチームの実測値を取ってから、上限（--max-turns・ジョブのタイムアウト・同時実行数の制限）を決めることをおすすめします。PRを毎回自動でレビューする場合は、GitHub Actionsのレビュー用ワークフローと、使用量に応じて課金されるCode Reviewとで、費用のかかり方が異なる点も比べておきます。

失敗パターンと技術的限界：過信を避けるための設計判断

実運用で頻出する失敗パターン4類型

Claude Codeのベストプラクティスをまとめたリポジトリ（GitHubのスター3.6万超。2026年4月にGitHubトレンド1位）が公開されています（出典：AI Heartland）。そこで挙げられている失敗パターンを、GitHub連携の観点で整理し直すと、次の4つに集約されます。

1. 指示の曖昧さによる意図外実装
   「ユーザー認証を直して」という粒度の指示では、認証まわり全体を意図せず作り替えられることがあります。Issueに完了の条件（Acceptance Criteria）と変更してよいファイルの範囲を書いておくことが前提です。公式の Common Workflowsドキュメント でも、編集の前にClaudeに計画を立てさせ、変更がディスクに書き込まれる前に確認する「Plan before editing」（claude --permission-mode plan か Shift+Tab でPlanモード）が勧められています。
2. テストなし自動コミット
   テストが用意されていないリポジトリでは、Claudeが変更を確かめる手段が限られたまま、コミットまで進むことがあります。後ろにCIでの検証を必ず置き、テストの無いコードベースへの適用は段階的に進めます。
3. 並行エージェントによるマージコンフリクトの誤解消
   複数のClaude Codeが同じファイルを並行して編集すると、コンフリクトを解消するときに、誤った側の変更が採用されるリスクがあります。公式ドキュメントが勧める git worktree（claude --worktree）でセッションごとに独立した作業用フォルダを用意すると、このリスクを構造的に抑えられます（Common Workflows）。
4. 秘匿情報の意図しないコミット
   IssueやClaude Codeとの会話にAPIキーや接続文字列が含まれていると、それがコードに書き込まれてコミットされるリスクがあります。auto モードの安全チェックは秘密情報の持ち出しを止めますが、それに頼り切らず、git-secretsやgitleaksなどのpre-commitフックを併用し、CI側でもシークレットのスキャンを二重に走らせます。

Claude Codeが技術的に苦手とする領域

Claude Codeはコードを書く力が高い一方で、次の領域では人によるレビューを手厚くする必要があります。これはツールの欠陥というより、いまのLLMの仕組みが持つ限界で、設計の段階で織り込んでおく前提条件です。

• セキュリティ要件の高い認証・認可の処理：深刻度の高い脆弱性を見落とすおそれがあり、セキュリティレビューの代わりにはなりません
• 性能が重要なボトルネックの解消：プロファイリングの結果の読み取りや、細かなベンチマークに基づく最適化の判断には、人の確認が必要です
• 文書化されていない古いコードの改修：コメントや設計書が足りないと意図の読み取りの精度が下がり、既存の動作を壊しやすくなります
• インフラのコード（Terraformなど）の破壊的な変更：terraform plan にあたる差分の確認を人が行わない限り、本番環境に思わぬ影響が出るおそれがあります

設定したのに動かないときの確認ポイント

設定の直後につまずきやすい点を、公式ドキュメントのトラブルシューティングなどから整理しました（2026年10月14日確認）。

監修者が実務で回してわかったこと（一次情報）

本記事の監修者・河合継は、Claude Codeを1年以上、実務で運用してきました。GitHubと組み合わせるときに実際に直面した課題と、効いた勘所を共有します。数値や費用の試算のような検証できない情報ではなく、運用の設計として再現できる知見に絞っています。

• CLAUDE.mdの肥大化：リポジトリ直下の CLAUDE.md に運用ルールを書き足していく設計は、Claude CodeがGitHubを自動で操作するときの事故防止に有効ですが、放っておくとルールの数が増え続けます。当初20項目ほどだったルールが実運用の中で40項目を超え、Claudeが全文を読み切れず、後半に書き足したルールが参照されにくくなる状態を経験しました。重複したルールを定期的に統合し、優先度の高いものを先頭に置き直す、という保守作業が必要です。
• 自動の変更を切り戻せる体制：Claude Codeがファイルを編集する直前に自動でバックアップを取るフック（PreToolUseフック）を組み込み、GitHub連携による自動のPR作成やIssue駆動の実装で意図しない変更が入っても、すぐ元に戻せる体制を作りました。GitHub連携を「レビューなしで信頼する」のではなく、「いつでも巻き戻せる前提で使う」設計にしておくことが、失敗を実害にしないためのポイントです。
• 権限は「最小から」始める：連携は便利な分、与える権限が広いほど想定外の操作のリスクも増えます。最初は狭く始めて必要に応じて広げるほうが、あとの事故と社内の承認のやり直しが減りました。
• AIの変更も人のレビューを必ず通す：自動でPRやコミットまで進められても、マージ前の確認は人が握ります。生成された差分をそのまま通さず、採否を判断する工程を残すのが安全でした。
• 小さく区切ったIssue単位で任せる：大きな要求を丸ごと投げるより、検証できる粒度のIssueに分けて任せるほうが、結果の質も、戻すときのしやすさも高くなりました。

実践ワークフロー：Issue駆動開発への組み込みと段階的導入

推奨フロー設計：IssueをSingle Source of Truthとして扱う

実績のある構成は、GitHubのIssueを唯一の要件の置き場として扱い、計画と実装をはっきり分ける流れです。Speakerdeckで公開されたClaude Codeの2026年の最新アップデートの資料（2026/03/12、Speakerdeck）でも、Issueを起点にするワークフローがCI/CDとの相性の点から勧められています。公式の Common Workflowsドキュメント も、コードベースの把握・バグ修正・リファクタリング・テスト・PR作成の各場面に合わせた、具体的なプロンプトの例を公開しています。

1. Issueを作る：完了の条件・変更してよいファイルの範囲・技術的な制約を書きます。あいまいな表現は避けます
2. @claudeのメンションかラベルでActionsを起動する：PRやIssueへの @claude のメンションがきっかけです。手作業をゼロにするのではなく、起動するかどうかは人が決めます
3. Claude Codeが実装する：claude/issue-xxx のようなブランチを作ってコミットし、draftのPRを開きます
4. CIで自動検証する：テスト・Lint・シークレットのスキャンが通ったら、PRをレビュー待ちに上げます
5. 人がレビューしてマージする：差分を確認して承認するか、修正を求めます。最終のマージは人が行います

使い方の全体像は使い方ガイド、導入直後の試し方ははじめの一歩ガイドが参考になります。

GitHub Enterprise Server利用時の注意点

公式ドキュメントによると、GitHub Enterprise Server（GHES）への対応は、TeamとEnterpriseのプランで使えます。組織の所有者がGHESのインスタンスを一度つなげば、開発者はリポジトリごとの設定なしで使えます。対応の範囲は次のとおりです（2026年10月14日確認）。

他のAIコーディングツールとの棲み分け

claude code githubの連携を考えるときは、エディタの補完型ツールとの使い分けも大事な判断です。Claude Codeはリポジトリ全体の文脈を持って動くエージェントのため、1つのファイルの補完や小さな編集の手助けが目的なら、大がかりすぎる場合もあります。ツールの選び方はClaude Code vs Cursor比較記事とClaude Code vs Codex比較記事で詳しく解説しています。

研究・教育分野における検証事例

J-STAGE掲載論文「ソフトウェア開発PBLへのAIエージェントを活用した仕様駆動開発」（J-STAGE）は、ソフトウェア開発の演習授業に、AIエージェントを使った仕様駆動開発（調査・計画・実装・レビューの4工程）を取り入れた報告です。開発の効率が上がった一方で、受講者の理解が追いつかない傾向も報告されており、チームに導入するときの教育の設計を考える材料になります。

よくある質問

Q. Claude CodeとGitHubを連携させる方法にはどのような種類がありますか？
A. 基本は3つのレイヤーです。レイヤー1は手元のClaude Codeがgitとgh（GitHub CLI）を直接使う方法、レイヤー2はGitHub Actionsに組み込んでIssueやPRの「@claude」で動かす方法（Claude Code Action）、レイヤー3はGitHubのMCPサーバーにつなぐ方法です。ほかに、ワークフロー不要の自動レビュー（Code Review）、クラウドのClaude Code、ルーティン、Claudeのチャット画面にリポジトリを読ませる連携もあります。

Q. いちばん簡単に始める方法は何ですか？
A. リポジトリのフォルダでClaude Codeを起動し、/install-github-app を実行する方法です。GitHub Appのインストール、認証用のシークレットの登録、ワークフローのファイルを入れたブランチのpushまでを案内してくれます。リポジトリの管理者権限と、GitHub CLI（gh）のログインが必要で、使えるのはgithub.comのリポジトリだけです。

Q. GitHub Actionsの公式アクションを使うと何ができますか？
A. PRやIssueで「@claude」とメンションするだけで、コードの分析・実装・バグ修正・PR作成をGitHubのランナー上で実行できます。prompt を書いたワークフローなら、PRが開かれたときや決まった時刻に、メンションなしで自動実行することもできます。

Q. /install-github-appコマンドでは何が行われますか？
A. Claude GitHub Appのインストール、認証用のシークレット（ANTHROPIC_API_KEY か CLAUDE_CODE_OAUTH_TOKEN）の登録、ワークフローのファイルを入れたブランチのpushを行い、PRを作る画面をブラウザで開きます。そのPRをマージすると「@claude」が動くようになります。Claude APIのキーとClaudeのサブスクリプションのどちらでも設定でき、Amazon Bedrock・Google CloudのAgent Platform・Microsoft Foundry経由で使う場合は、クラウド事業者向けの手順で設定します。

Q. Claudeのサブスクリプション（Pro・Maxなど）だけでGitHub Actionsを動かせますか？
A. 動かせます。手元で claude setup-token を実行して作ったトークンを CLAUDE_CODE_OAUTH_TOKEN という名前でシークレットに登録し、ワークフローの claude_code_oauth_token に渡します。Pro・Max・Team・Enterpriseで使え、APIの従量課金ではなくサブスクリプションの利用枠を使います。複数のリポジトリで共有する場合は、個人のサブスクリプションにひも付かないAPIキーが勧められています。

Q. 手元のClaude Codeは、確認なしでGitHubにpushしますか？
A. Claude Code v2.1.283以降は、ターミナルとVS Codeで始めたセッションの最初の権限モードが auto で、作業中のリポジトリのブランチへのpushと、依頼に沿ったPRの作成は確認なしで実行されます。force pushや秘密情報の持ち出しなどは安全チェックが止めます。pushの前に確認を挟みたい場合は、設定の permissions.ask に Bash(git push *) や Bash(gh pr create *) を加えるか、Manualモードに切り替えます。

Q. GitHubのMCPサーバーはどうやってつなぎますか？
A. fine-grainedの個人アクセストークンを作り、claude mcp add –transport http github https://api.githubcopilot.com/mcp/ にAuthorizationヘッダーを付けて登録します。登録の時点ではトークンは確かめられないため、claude mcp list か /mcp で connected と表示されるかを確認します。GitHub Enterprise Serverでは使えません。

Q. GitHubのMCPサーバーはGitHub Enterprise Serverで使えますか？
A. 使えません。公式ドキュメントによると、GitHubのMCPサーバーはGitHub Enterprise Server（GHES）に対応していません。GHESでは、GHES向けに設定した gh（gh auth login –hostname）をClaudeに使わせる方法が案内されています。GitHub Actionsは手動でワークフローを設定すれば使えます。

Q. Code Reviewの料金はいくらですか？
A. 公式ドキュメントによると、Code ReviewはTeam・Enterpriseで使える研究プレビューで、料金は使用量に応じて決まり、定額の1回あたり料金はありません（PRの大きさなどで変わります）。プランの利用枠とは別に、使用量クレジットで請求されます。ほかのプランでも、手元で /code-review を実行して差分をレビューできます。

Q. GitHub Actionsで決まった時刻にClaudeを動かせますか？
A. 動かせます。prompt を書いたワークフローは、cronのスケジュールを含むどのイベントでも動きます。ただし、GitHubはスケジュールのワークフローを既定のブランチからしか動かさず、公開リポジトリでは60日間動きが無いとスケジュールが止まります。Claudeのクラウド側で定時に動かすルーティンもあります。

Q. v0.x系からv1.0のclaude-code-actionへ移行する際、何が変わりますか？
A. mode は不要になり（自動で判定）、direct_prompt は prompt に、max_turns・model・allowed_tools などは claude_args のCLI引数に、custom_instructions は –append-system-prompt に、timeout_minutes はGitHub Actions側の timeout-minutes に移ります。@beta の設定のまま @v1 に変えると、設定が無視されたりエラーになったりします。

Q. 複数のClaude Codeを並行して走らせる場合、何を使うとよいですか？
A. git worktreeです。claude –worktree feature-auth のように名前を付けて起動すると、別のブランチの作業用フォルダで独立したセッションが始まります。セッションごとに作業用フォルダが分かれるため、編集のぶつかりやマージのコンフリクトを構造的に抑えられます。

Q. Claude Codeを使わずに、ClaudeのチャットからGitHubのリポジトリを読ませることはできますか？
A. できます。チャットの入力欄の「+」から「Add from GitHub」を選ぶか、プロジェクトの知識に「GitHub」からリポジトリを追加すると、選んだファイルやフォルダをClaudeに読ませられます。読み込まれるのは指定したブランチのファイル名と中身だけで、コミット履歴やプルリクエストは対象外です。コードの変更やPRの作成まで任せたい場合はClaude Codeを使います。

Q. @claudeとメンションしても反応しないときは何を確認すればよいですか？
A. GitHub Appがそのリポジトリに入っているか、リポジトリでワークフローが有効か、APIキーまたはOAuthトークンがシークレットに登録されているか、コメントに「@claude」が単語として入っているか（/claude や @claude-bot では反応しません）、コメントした人がリポジトリの書き込み権限を持っているか、の5点です。

Q. リポジトリを見られる人なら誰でも@claudeで起動できますか？
A. できません。IssueやPRのイベントでは、起動した人がリポジトリの書き込み権限を持っている必要があります。書き込み権限の無い特定の人を許可するには allowed_non_write_users を設定し、自分の github_token を渡します。ボットからの起動は、allowed_bots に入れない限り拒否されます。ボット同士でClaudeを呼び続けるループを防ぐための仕組みです。

---

まとめ

Claude CodeとGitHubの連携は、手元のClaude Code（ローカルCLI）・GitHub Actions・MCPの3つのレイヤーに整理すると、チームのリスクの許容度と自動化の目的に合った選び方ができます。まずは手元でgitとGitHub CLIを使わせて慣れ、チームで使う段階で /install-github-app によるGitHub Actionsを足すのが無理のない順番です。ワークフローを書きたくなければCode Review、ブラウザやスマホから続けたいならクラウドのClaude Code、コードを読ませて相談するだけならClaudeのチャットのGitHub連携、という選択肢もあります。

どのレイヤーでも共通して必要なのは、権限の範囲を最小にすること、ブランチ保護を徹底すること、編集の前に計画を確認すること、そして人のレビューを最後の工程に残すことです。手元のClaude Codeは auto モードでは確認なしでpushするため、必要なら permissions.ask で確認を挟みます。セキュリティ要件の高い領域や、文書化が足りない古いコードへの適用は段階的に進めてください。

参考文献

• Anthropic公式「Claude Code GitHub Actions」https://code.claude.com/docs/en/github-actions.md
• Anthropic公式「Choose a permission mode」https://code.claude.com/docs/en/permission-modes.md
• Anthropic公式「Configure auto mode」https://code.claude.com/docs/en/auto-mode-config.md
• Anthropic公式「Connect Claude Code to tools via MCP」https://code.claude.com/docs/en/mcp.md
• Anthropic公式「Use Claude Code in the cloud」https://code.claude.com/docs/en/claude-code-on-the-web.md
• Anthropic公式「Code Review」https://code.claude.com/docs/en/code-review.md
• Anthropic公式ヘルプ「Use the GitHub integration」https://support.claude.com/en/articles/10167454-use-the-github-integration
• Anthropic公式「Common Workflows」https://code.claude.com/docs/en/common-workflows.md
• Anthropic公式「Claude Code with GitHub Enterprise Server」https://code.claude.com/docs/en/github-enterprise-server.md
• Anthropic公式「Automate work with routines」https://code.claude.com/docs/en/routines.md
• Anthropic公式「Claude Agent SDK」https://code.claude.com/docs/en/agent-sdk/overview
• claude-code-action（GitHubリポジトリ）https://github.com/anthropics/claude-code-action
• Gigazine「Claude CodeはGitHubの公開コミットの4％を占めており2026年末には20%へ」（2026/02/10）https://gigazine.net/news/20260210-claude-code-github-commits-4-percent-20-percent/
• Ledge.ai「GitHubコミットの4％がAI生成──Claude Codeは2026年末に20％へ？SemiAnalysisが分析」https://ledge.ai/articles/claude_code_4_to_20_percent_github_growth
• Classmethod DevelopersIO「[2026年版] Claude Code を知ります。」（2026/03/20）https://dev.classmethod.jp/articles/shoma-2026-claude-code-know-use-leverage/
• Qiita・nakamasato「[Claude Code] AIコーディング開発サイクル (2026年1月時点)」（2026/01/18）https://qiita.com/nakamasato/items/ef3842b05b5b936906f6
• AI Heartland「Claude Codeベストプラクティス2026｜Boris直伝の25 Tips」（2026/04/11）https://ai-heartland.com/explain/claude-code-best-practice-guide-2026/
• Uravation Media「【2026年最新】Claude Code GitHub連携完全ガイド」（2026年6月取得）https://uravation.com/media/claude-code-github-integration-guide-2026/
• Speakerdeck・oikon48「Claude Code 2026年 最新アップデート」（2026/03/12）https://speakerdeck.com/oikon48/claude-code-0312
• J-STAGE「ソフトウェア開発PBLへのAIエージェントを活用した仕様駆動開発」https://www.jstage.jst.go.jp/article/repit/2026/0/2026_90/_pdf

関連記事

• Claude Codeとは
• Claude Codeで自動化・定期実行する方法
• Claude Codeのベストプラクティス
• Claude Code Skillsとは？作り方と一覧
• Claude Codeでできること・活用事例