Claude Media
Claude CodeのGitHub Actionsを組織全体に導入する手順
Claude Codeチュートリアル

Claude CodeのGitHub Actionsを組織全体に導入する手順

Claude Code GitHub Actionsを1リポジトリずつでなく組織全体へ展開する手順を、GitHub Appのインストールからシークレット共有、federationまで追います。

読了目安 約8分

組織展開ではじめに確認すること

クイックセットアップや手動セットアップは1リポジトリずつの設定です。数十のリポジトリを持つ組織でリポジトリごとにGitHub Appのインストールとシークレット登録を繰り返すのは非効率で、シークレットのローテーション漏れも起きやすくなります。組織展開では、GitHub Appのインストール単位・シークレットの共有単位・ワークフローファイルの配布単位という3つを、リポジトリ単位から組織単位に引き上げます。

前提として、GitHub組織のオーナー権限(GitHub Appのインストールと組織シークレットの追加ができる権限)が必要です。単一リポジトリでの動作確認がまだの場合は、先にClaude CodeをGitHub Actionsに組み込むでワークフロー自体の挙動を確認してから展開に進むと、あとで問題が起きたときの切り分けが楽になります。

ステップ1: Claude GitHub Appを組織レベルでインストールする

Claude GitHub Appを、リポジトリ単位ではなく組織のインストール画面から追加します。対象は「すべてのリポジトリ」か「選択したリポジトリの一覧」のどちらかを選べます。新しいリポジトリを自動的に対象へ含めたい場合は「すべてのリポジトリ」、対象を明示的に管理したい場合は一覧選択を使います。

インストール後にリポジトリが追加された場合でも、組織の設定画面からいつでも対象リポジトリを追加・削除できます。ワークフローファイル自体はリポジトリごとに置く必要があるため、このステップはあくまでGitHub Appの認証範囲を組織単位にそろえる作業です。

ステップ2: 認証シークレットを組織単位で共有する

シークレットを組織レベルのActionsシークレットとして1回だけ登録すれば、各リポジトリで個別にコピーする必要がなくなります。ここで注意する点が1つあります。

組織で共有するシークレットには、OAuthトークンではなくAPIキーを使います。claude setup-tokenで発行するOAuthトークンは、それを実行した個人のサブスクリプションに紐づくためです。複数リポジトリで同じOAuthトークンを共有すると、そのトークンを発行した個人のプラン枠を全社のジョブが食いつぶす形になります。Claude Consoleで発行したAPIキーを組織シークレットに登録すれば、この紐づきを避けられます。

ステップ3: ワークフローを配布する — 個別コピーか再利用可能なワークフローか

ワークフローファイル自体は組織シークレットのようには共有されません。配布方法は2通りあります。

  1. 各リポジトリに同じワークフローファイルをコピーする。単純ですが、設定を変更するたびに全リポジトリへの再配布が必要です
  2. 再利用可能なワークフロー(reusable workflow)として1箇所に定義し、各リポジトリから呼び出す。変更の反映が1箇所で済みます

再利用可能なワークフローにする場合、ジョブの定義を専用リポジトリに置き、呼び出し側は数行のuses:だけで済みます。

.github/workflows/claude.yml
name: Claude
on:
  issue_comment:
    types: [created]
 
jobs:
  claude:
    uses: your-org/shared-workflows/.github/workflows/claude-review.yml@main
    secrets:
      anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}

呼び出されるワークフロー側にanthropics/claude-code-actionのステップを書いておけば、各リポジトリのファイルはこの数行だけで済み、モデルやツール許可などの設定変更は共有ワークフロー側の1箇所を直せば全リポジトリに反映されます。

長期シークレットを避けるならfederationを使う

APIキーをシークレットとして保存すること自体を避けたい場合、claude-code-actionはワークフローのGitHub OIDCトークンをClaude APIアクセスに交換するworkload identity federation(WIF)に対応しています。設定する入力は次の4つです。

  • anthropic_federation_rule_id: Consoleで作成した連合ルールのID(fdrl_...)
  • anthropic_organization_id: AnthropicのOrganization ID
  • anthropic_service_account_id: サービスアカウントID(svac_...)。連合ルールが単一のサービスアカウントを対象にしていれば省略可
  • anthropic_workspace_id: ワークスペースID(wrkspc_...)。連合ルールが単一ワークスペースを対象にしていれば省略可

このfederationはOIDCトークン交換という点で、Claude APIを直接呼ぶワークフローで使うWIFをGitHub Actionsと連携するの仕組みと同じ土台を使っています。claude-code-action経由では上記4つの入力を渡すだけで済み、トークン交換のAPI呼び出し自体を自分のワークフローに書く必要はありません。ただしgithub_tokenを自前で指定している場合でも、ワークフローにpermissions: id-token: writeを付けないとfederationの交換に失敗します。Console側でのサービスアカウント・連合ルール作成手順はClaude Console側の設定画面が対象です。

GitHub Appの権限とアンインストール手順

Claude GitHub AppはClaude Code GitHub Actionsだけでなく、Code Review機能やClaude Code on the webのauto-fixとも共通です。インストール時に付与される権限は次のとおりです。

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

権限セットは機能追加に合わせて変わることがあり、新しい権限が要求されるとGitHubが組織オーナーに承認を求めます。承認するまでは古い権限のまま動き続けます。たとえばActions権限がRead限定からRead/Writeに変わった場合、承認前はワークフロー実行の閲覧しかできず、承認後にはじめて実行の再トリガーができるようになります。Claude Codeコードレビューを使っていない、最小権限だけで十分という場合は、Contents・Issues・Pull requestsの3権限に絞ったカスタムGitHub Appを自作する選択肢もあります。ただしカスタムAppではCode Reviewとweb上のauto-fixは動きません。

組み込みをやめる場合は、次の順で外します。

  1. .github/workflows/からclaude-code-actionを使うワークフローファイルを削除する
  2. リポジトリまたは組織のActionsシークレットから認証情報を削除する。シークレットを削除してもAPIキー自体は有効なまま残るため、キーを完全に失効させたい場合はClaude Console側でも削除する
  3. Code ReviewやWeb版auto-fixで使っていなければ、GitHub Appを組織またはリポジトリの設定からアンインストールする
  4. GitHub Actions Bedrock連携などクラウドプロバイダー経由で動かしていた場合は、AWS_ROLE_TO_ASSUMEやGCP_* / AZURE_*のプロバイダー側シークレットも合わせて削除し、専用に作ったカスタムGitHub AppがあればAPP_ID / APP_PRIVATE_KEYごとアンインストールする

企業のセキュリティレビューでデータの取り扱いや保持期間を確認する場合は、Anthropicのデータ利用とセキュリティのドキュメントが一次情報になります。federationを含む認証方式の選定はここまでの手順で完結しますが、社内のレビュー資料としてはこれらのリンク先も合わせて提示しておくと話が早くなります。

組織展開でよくあるつまずき

最初のつまずきは、OAuthトークンを組織シークレットに登録してしまうことです。発行した個人が退職・異動すると全社のジョブが認証エラーになります。ステップ2のとおりAPIキーで統一します。

federationを使う場合にid-token: write権限を忘れるのも典型的な失敗です。github_tokenを自前で指定していても、federationのトークン交換にはこの権限が別途必要なため見落としやすく、付け忘れると交換エラーが出ます。

シークレットを削除しただけでAPIキーが失効したと思い込むのも起きやすい誤解です。シークレットの削除はワークフローからの参照を切るだけで、キー自体はClaude Console側で明示的に取り消すまで有効です。退職者が発行したAPIキーを組織で使い続けている状態に気づかず放置するのも同じ根の問題なので、キーのローテーションは定期的に見直します。

まとめ

  • GitHub Appは組織レベルでインストールし、対象リポジトリを一覧か全体で管理する
  • 認証シークレットはOAuthトークンでなくAPIキーを組織単位で共有する
  • ワークフローの配布は個別コピーか再利用可能なワークフローのどちらかを選ぶ
  • 長期シークレットを避けるならfederationの4つの入力を設定し、id-token: writeを忘れない
  • アンインストール時はワークフロー削除・シークレット削除・GitHub Appアンインストールの順で、シークレット削除だけではキーは失効しない点に注意する

1リポジトリでの動作確認が済んでいれば、組織展開そのものは設定の置き場所を変える作業が中心です。認証周りだけ手順どおりに進めれば、あとは各リポジトリへの適用範囲を、必要なタイミングで広げていくだけです。

この記事を共有:XはてブLinkedIn

関連する記事

Claude Code をもっと見る →