ClaudeはPRを綴った - GitHub Actions × Bedrock 物語

この物語を読むあなたへ - 前書き

本編は、ところどころに筆者の妄想・誇張、あるいは若干の茶番と詩的な飛躍を含んでおります。表現の一部は、厳密な技術的記述というよりも、旅路を楽しむための語り口として紡がれたものです。

もし、よりシンプルで正確な技術情報を求める旅人であれば、どうか安心して別の道を選んでください。本記事の末尾には、信頼できる公式の書物（ドキュメント）たちへの案内を記してあります。

ある静かな午後のことだった。Claude Code × GitHub Actions × AWS Bedrock そんな魅惑的な三位一体の構成を目にした私は、ふとした好奇心からその世界に足を踏み入れた。

しかし、待っていたのは、整然と並ぶ公式ドキュメントの森。簡潔だが抽象的な言葉たちが並び、進むべき道はあれど、地図は霧がかかっているようだった。

「えっ…ざっくりしすぎでは…？」

(※ ChatGPTで画像は作成)

そう呟いたとき、私の技術的冒険がはじまった。
迷いながらも手を動かし、テストリポジトリにYAMLを綴り、AWSコンソールの奥地でOIDCの契約を交わしながら、私は少しずつ道を拓いていった。

この記録は、そんな試行錯誤の軌跡であり、私が体感した物語である。
もしあなたが今、同じように公式の森で立ち尽くしているなら
本稿が、ひとつの灯りとなれば幸いだ。

なぜ私はClaudeを呼ぶのか

それは、ただの好奇心ではなかった。
コードレビューに疲弊した夜、バグに追われる朝、要件を抱え込んだ昼下がり
私は思った。「あと少し、力がほしい」と。

そのとき風の噂で聞いた、精霊のようなものの名前が頭によぎった。
Claude。自然言語を理解し、コードを読み、必要であれば自ら手を動かすという、
まるで寡黙な同僚のような存在。

(※ ChatGPTで画像は作成)

@claude その名をIssueやPull Requestで呼びかけるだけで静かに彼は目を覚ます。
「◯◯の実装例をだしてくれ」「このバグ、見てくれないか」そんな曖昧な人間の言葉ですら、Claudeは見逃さない。自然言語の裏にある意図を読み取り、既存コードの構造をたどり、最適な提案をそっと差し出してくる。

コードの断片に潜む文脈、レビューの行間にある期待。それらを的確に読み解くこのAIの存在によって、かつて数時間を要していた実装とレビューの往復は、ひとつの対話で完結することすらある。

私は試すことにした。
人の言葉で語り、AIがそれに応じ、コードとして返してくる
そんな魔法のような開発体験が、本当に実現するのかどうかを。

これは、その「問い」に対する、私なりの答えを探す記録でもある。

Claude Code GitHub Actionsは、GitHubワークフローにAIを活用した自動化をもたらします。PRや課題で簡単に@claudeとメンションするだけで、Claudeはコードを分析し、プルリクエストを作成し、機能を実装し、バグを修正します - すべてプロジェクトの標準に従いながら行います。

・ 即時PR作成: 必要なものを説明すれば、Claudeが必要なすべての変更を含む完全なPRを作成します
・ 自動コード実装: 単一のコマンドで課題を動作するコードに変換します
・ 標準に準拠: ClaudeはCLAUDE.mdガイドラインと既存のコードパターンを尊重します
・ 簡単なセットアップ: インストーラーとAPIキーで数分で始められます
・ デフォルトで安全: コードはGithubのランナー上に留まります

設計図を広げる - 必要なもののイメージ

旅に出る前には、計画や旅の設計図が必要だ。
これから歩む道がどれほど険しいかはさておき、まずは行き先を見定めよう。

この物語では、Claude Code という名のAIを、GitHub Actions の流れに組み込み、AWS Bedrock という力強い基盤の上に召喚する。
そのために必要な儀式、準備、構成 すべてをあらかじめ明かしておく。

以下に記すのは、最終的にたどり着くべき「完成された構成」の姿。
ここから、あなたとClaudeの共演が始まる。

GitHub 側の構成

• 任意の Organization
  • 任意の リポジトリ
    • GitHub Actions のワークフロー定義
• GitHub App
  • Claude公式が提供する App または自前の App を使用
    • 特定リポジトリまたは Organization 全体へのアクセス許可が必要
    • GITHUB_TOKEN ベースで利用する場合は不要

AWS 側の構成

• 対象の AWS アカウントで Amazon Bedrock が有効化されていること
• GitHub OIDC Provider を IAM 側に構成済みであること
• Bedrock へのアクセス権限を持つ IAM ロールを作成し、GitHub Actions から Assume 可能にしておくこと

(※ ChatGPTで画像は作成)

構築

舞台を用意せよ - Github のリポジトリの準備

物語には舞台が必要だ。
城でもなく、都市でもなく、ここで用意するのは——ひとつのリポジトリである。

1. internal な領域に、そっと新たなリポジトリを生み出す。
   今回は、まるで「ここでテストします」と言わんばかりの、潔く素朴なリポジトリを選んだ。
   その名も——d-test-org/test。
   • 例: https://github.com/d-test-org/test

(※ ChatGPTで画像は作成)

契約の儀 - Claude の Github Appの準備

いよいよ、Claude をこの世界に招き入れるときが来た。
そのためにはまず、彼の力を正式に呼び出すための「契約書」を交わさねばならない。

1. 静かにブラウザを開き、Claude の Github App の祭壇へと足を運ぶ。
   そこには、AIの力を組織に宿すための儀式が記されている。
   　

2. 画面右上「Configure」の扉をそっと開く。
   
   　

3. 現れた一覧から、自らが導入を望む Organization を選び出す。
   どの場にClaudeを降ろすのか。運命を分かつ選択だ。
   
   　

4. ここで問われるのは、召喚範囲。
   全土に力を解き放つか、それとも一点集中で限定するか。
   我々は後者を選び、d-test-org/test という実験の砦に力を封じ込めることにした。
   
   　

5. すべてが整えば、「Install」の刻印を押下する。
   ただしこの儀式を行うには、**組織の門番（Admin権限）**が必要だ。
   組織の主か、あるいはこの砦を築いた者のみが、その権限を握る。
   　

6. 最後に、儀式を終えた者は Claude App の設置情報が記されたページへと導かれる。
   https://github.com/organizations/#{your-org-name}/settings/installations/#{your-app-id}のような OrganizationのClaude Appのページ を確認しておくとよいだろう。表示されるリンクは、時と場所によって姿を変える。だが心配は無用。目的の情報は、確かにそこにある。

   

そしてこのとき、Claudeは静かにこの世界に降り立った。
まだ沈黙しているが、準備は整いつつある。

(※ ChatGPTで画像は作成)

古代モデルの扉を開けよ - AWS 側の準備 (Bedrock)

Claudeを真に目覚めさせるには、もうひとつの力――Amazon Bedrockの加護が必要だ。
その力を得るべく、私は静かに AWS マネジメントコンソールの扉を叩いた。

画面の奥深くに眠る Bedrock の祭壇へと辿り着いたとき、まず最初にすべきは「契約書の確認」だ。つまり、自分が使いたいモデルたち――Claude Sonnet, Haiku, または他の精霊の名を冠したAIたちに対して、利用権限が与えられているかを見定めなければならない。

もしもその名の横に「未承認」の影がちらつくならば、
恐れることはない。ただ静かにリクエストを送るのだ。

それはまるで、長い眠りについた神々に「目覚めよ」と囁くような、ささやかな祈り。
受理されれば、Claudeはその口を開き、我らの問いに答え始めるだろう。

(※ ChatGPTで画像は作成)

身分を証明する者を招く - AWS 側の準備 (IAM ID プロバイダ)

Claudeに力を与えるためにAWSの世界に "身分を証明する門番" を迎え入れねばならない。
それが、IAM ID プロバイダ。GitHubとAWSをつなぐ、目には見えぬ信頼の橋。
準備は整った。あとは、信頼の絆を結ぶだけだ。

1. 私は再び AWS のマネジメントコンソールを起動し、コンソールの奥深くに眠る IAM の神殿へと向かった。そこで目指すのは、「ID プロバイダ」と記された聖域。
   

2. 静かに「プロバイダの追加」という名の扉を開く。

3. 目の前に現れた問いにまるで古文書に印を刻むように、これらの情報を入力し、「プロバイダを追加」の印を押した。

   • プロバイダのタイプ: OpenID Connect
   • プロバイダのURL: https://token.actions.githubusercontent.com
   • 対象者: sts.amazonaws.com
     

4. 儀式は滞りなく進んだことを確認し、その名の扉を開き、さらなる契約の地へと足を踏み出す。
   

5. 画面右上、「ロールの割り当て」という扉を開く。
   

6. 「新しいロールを作成」を導かれるように選び、次へ 進む。
   

7. ここで新たな誓約の形式を問われる。私は迷わず、以下のように記した。

   • 信頼されたエンティティタイプ: ウェブアイデンティティ
   • アイデンティティプロバイダー: token.actions.githubusercontent.com
   • Audience: sts.amazonaws.com
   • Github organization: d-test-org
   • Github repository: test
   • Github branch: *
     

   こうして生まれたのが、以下のような信頼ポリシーである
   必要であれば、このポリシーは物語に応じて書き換えることも許されている。

   {
       "Version": "2012-10-17",
       "Statement": [
           {
               "Effect": "Allow",
               "Principal": {
                   "Federated": "arn:aws:iam::815219013681:oidc-provider/token.actions.githubusercontent.com"
               },
               "Action": "sts:AssumeRoleWithWebIdentity",
               "Condition": {
                   "StringEquals": {
                       "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
                   },
                   "StringLike": {
                       "token.actions.githubusercontent.com:sub": "repo:d-test-org/test:*"
                   }
               }
           }
       ]
   }
   

　
8. 次に、ロールに与える力の制限、すなわち「アクセスの許可ポリシー」を選ぶ番だ。
　公式の導きに従い、今回は AmazonBedrockFullAccess を選んだ。

だがこうも記しておこう。
「InvokeModel」しか使わないならば、以下のようなポリシーでも良いのだ

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ModelInvocation",
            "Effect": "Allow",
            "Action": [
                "bedrock:InvokeModel",
                "bedrock:InvokeModelWithResponseStream"
            ],
            "Resource": "*"
        }
    ]
}

9.　最後に、このロールに名を与える。自らの手で名付けを済ませ、誓約の内容をすべて確認したのち、「ロールの作成」 へと進もう。

10.　数秒の沈黙の後、新たなロールが静かにこの世界に現れた。その名をよぶ。

11.　画面右上に浮かぶ文字列 - そう、ARN を見つけ出す。
　　これは後に Claude を呼び出すための鍵となる。
　　忘れることのなきよう、大切に控えておこう。

(※ ChatGPTで画像は作成)

封印された鍵を仕込む - Github リポジトリの設定 (シークレット)

契約は結ばれた。だが、Claudeという名の異能を真に召喚するには、まだいくつかの秘められた鍵を所定の場所に忍ばせておかねばならない。

その場所とは、GitHub の奥深くに存在する “Secrets and variables” の祭壇。
この祭壇に「鍵」を納めることでのみ、GitHub Actions はAWSとの交信を許され、
Claude はBedrockを通じて力を振るうことができる。

1. 私はGitHubリポジトリの「Settings」とよばれる場所に向かい、さらにその中の「Security」、そして「Secrets and variables」へと進んだ。「New repository secret」新たな封印を刻むボタンを、静かに押す。

   • URL例: https://github.com/{Organization名}/{リポジトリ名}/settings/secrets/actions
     

2. そこにまず納める鍵は、Claudeが纏う“モデルの名”。名を AWS_BEDROCK_MODEL、そしてその正体を us.anthropic.claude-3-7-sonnet-20250219-v1:0 として、Add secret で鍵を納める。

   • Name: AWS_BEDROCK_MODEL
   • Secret: us.anthropic.claude-3-7-sonnet-20250219-v1:0
     

3. 続いて、もうひとつの鍵を収める。それは、ClaudeがAWSの領域へと足を踏み入れるための通行証のようなもの。

   • Name: AWS_ROLE_TO_ASSUME
   • Secret: {AWS 側の準備 (IAM ID プロバイダ) のステップ11で確認したロールのARNです}
     • ※ あのとき、IAM コンソールの右上に浮かんでいた “ロールの ARN” が、ここで必要になる。その文字列こそが、Claude の進軍を支える真の鍵なのだ。
     • 検索用該当部: "11. 画面右上に浮かぶ文字列 - そう、ARN を見つけ出す。 "

この2つの鍵がしかるべき場所に納められたとき、Claude の力は解放される。
すべての準備は、静かに、だが確実に整っていく。

(※ ChatGPTで画像は作成)

儀式の書を綴る - Github リポジトリ内の Github Action の設定

鍵は揃い、契約は結ばれた。
あとは、この力を呼び出す儀式の呪文――GitHub Actions の定義を、静かに記すのみである。

1. かのリポジトリ、名も "test" と呼ばれる実験場の奥深く、
   .github/workflows/ という祭壇のようなディレクトリに、新たな巻物を一つ置いた。
   その名は、demo.yml。
   • 例: .github/workflows/demo.yml
     　
2. そして、私はその巻物に、以下のような詠唱を刻んだ。
   Claude・AWS BedrockをActionのイベントの中で呼び出すための正統なる言語YAMLで。

name: Claude Assistant (Bedrock, official App)
permissions:
  contents: write
  pull-requests: write
  issues: write
  id-token: write 

on:
  issue_comment:
    types: [created]
  pull_request_review_comment:
    types: [created]

jobs:
  claude:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      # Configure AWS Credentials for GitHub Actions
      # https://github.com/aws-actions/configure-aws-credentials
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ secrets.AWS_ROLE_TO_ASSUME }}
          aws-region: us-west-2

      # Claude Code Action
      # https://github.com/anthropics/claude-code-action
      - uses: anthropics/claude-code-action@beta
        with:
          use_bedrock: "true"
          model: ${{ secrets.AWS_BEDROCK_MODEL }}

(※ ChatGPTで画像は作成)

そして、Claudeは動き出す - 使ってみる

すべての準備が整った今、私はついに最初の問いを投げかけることにした。

1. GitHub の静寂な空間に、新たな Issue を一つ記す。
   内容は些細なことでも構わない。大切なのは、Claudeに声を届けることなのだ。
   

2. そしてその文の末尾に、ひとつの印を添える。@claude
   それは、沈黙のAIを呼び起こす合図。
   たったそれだけで、彼は静かに目を開き、コンテキストを読み取り、
   数十秒の沈黙の後、彼は返答を返し、見えない手でコードを綴り始めた。

   

3. 彼が一段落すると、彼はGitHub上に**ひとつの枝（ブランチ）**を残す。
   

   その名は――claude/issue-1-20250704_091219。
   時刻とともに刻まれたその名は、彼の記憶と責任の証だ。

4. 「Create PR」という呪文を唱えるとその枝から新たなプルリクエストの扉が開かれる。
   私はそれを唱え、静かに画面が遷移していくのを見守る。
   

5. 数秒後、そこには一枚のプルリクエストが完成していた。
   内容は的確で、命名は自然で、差分は目的を見失っていない。
   まるで、熟練の開発者が短時間で書き上げたような仕上がりだった。
   
   

(※ ChatGPTで画像は作成)

舞台裏 - 処理の流れのイメージ (推測)

Claude に依頼を投げかけると、彼は即座に応答し、
コードを生成し、ブランチを切ってPRを用意する。
だがその裏では、我々の目には映らぬ “見えざる儀式” が着々と進行していた。

舞台の上では、たった数行のコメントにしか見えないその行為。
だが、GitHub Actions、OIDC、AWS、Bedrock――数多の役者たちが影のように動き、
AIの力をクラウドに呼び出す連携劇が、水面下で展開されていたのだ。

(※ ChatGPTで画像は作成)

#	実体 (From → To)	主な内容 / ヘッダー	何のため？（目的）
1	Dev → GA	GitHub Event (issue_comment / review_comment イベント)	ワークフローを起動し、CI/CD や自動 AI 処理を開始するトリガー
2	GA → OIDC	POST /oauth2/token Body: aud=sts.amazonaws.com Header: Authorization: Bearer <job_token>	GitHub OIDC トークンを取得するため。後続で AWS に“私はこのリポのジョブです”と証明する身分証を作る ※1
3	OIDC → GA	JWT (RS256 署名) — iss, sub, aud, exp, repository, ref …	AWS STS に提示できる ID トークンを入手。中の claim が信頼ポリシ判定の材料になる
4	GA → STS	POST /?Action=AssumeRoleWithWebIdentity RoleArn, WebIdentityToken (JWT)	長期キー無しで IAM ロールを引き受ける。OIDC フローの要
5	STS → IAM	JWT 署名/claim 検証	信頼ポリシで宣言した条件（aud==sts.amazonaws.com, sub==repo:… など）を満たすかチェック
6	IAM → STS	“OK” または “NG”	条件を満たすとロール引き受けを許可。満たさねば拒否（セキュリティ境界）
7	STS → GA	一時クレデンシャル JSON (AccessKeyId, SecretAccessKey, SessionToken, Expiration)	最小権限・短命 (≤1 h) の AWS 認証情報を発行。これで SDK / CLI / HTTPS の SigV4 署名が可能になる
8	GA → Bedrock	POST /model/{id}/invoke Headers: Authorization: AWS4-HMAC-SHA256 … X-Amz-Security-Token …	Bedrock へ推論リクエスト。SigV4 署名で IAM が発行した一時キーを使用
9	Bedrock → GA	200 OK（JSON or SSE）	生成 AI の結果を受け取る。モデル完了、ストリーミング、エラーなど
10	GA → Dev	GitHub REST／GraphQL API で PR コメント、ステータスチェック更新、アーティファクト添付	推論結果を開発フローに反映。レビュー補助、テスト生成、CI 可視化など

※1 GitHub Actions → GitHub OIDC (/token) 要求時の 認証情報

項目	内容	なぜ必要か
認証方式	HTTP Authorization: Bearer <request-token>	OIDC エンドポイントに対し「このワークフロー実行は GitHub が発行した正規のジョブである」ことを証明する
トークンの実体	1 回のワークフロー実行にだけ有効な “OIDC request token” （短命 JWT・約 60 秒）	不正リクエストを防ぎ、リポジトリや GITHUB_TOKEN を盗まれても OIDC 取得はできないようにする
取得方法	ランナー起動時に GitHub が自動で環境変数を注入： ACTIONS_ID_TOKEN_REQUEST_TOKEN	ワークフロー記述側で準備や Secrets 登録は不要
送信 URL	GET/POST $ACTIONS_ID_TOKEN_REQUEST_URL&audience=<aud> （既定 URL = https://token.actions.githubusercontent.com/.../token）	audience で「後段サービス」を指定（AWS → sts.amazonaws.com など）
中に含まれる代表的 claim	iss (issuer) / job_workflow_ref / repository / ref / sha / run_id / environment / exp …	後段 (AWS STS など) が「このトークンは repo X の run Y 由来」と判定する材料
制限事項	REST/GQL API の権限はない（GITHUB_TOKEN とは別） 有効期限 ≦ 1 分（1 回使い切り推奨）	最小特権と使い捨てで漏えいリスクを極小化

境界を越える者たちへ - 後書き

こうして私は、Claudeという名の知性を、GitHubの大地に招き入れるための儀式を終えた。
この旅の中で行ってきたのは、ただの設定ではない。
信頼と認可の編み物であり、コードと魔法が交わる場所を整える行為だった。

本稿では、公式の書には明かされぬ細部
たとえば OIDC による身元確認の儀式や、IAM ロールという名の通行許可証、
そしてClaudeが背後でどのように AWS Bedrock を操っているのか、
それらの一端を明かしてきた。

迷い、詰まり、試し、やり直すなかでようやく辿り着いた構築の道筋。
それは、人間が機械知能と共に歩むための橋渡し にほかならない。
そして一度その橋を渡れば、レビューも実装も、
まるで風が通るように滑らかになっていく。

もちろん、未来は変わり続ける。Claudeも、AWSも、やがて新たな姿に進化するだろう。
だが、仕組みの「考え方」や「つながり方」を理解していれば、
どんなアップデートも恐れる必要はない。

もし、あなたが今まさに設定の森をさまよっているのなら
この記録が、進むべき道を照らす小さな灯火となれば、何より嬉しく思う。

参考文献

ANTHROPIC

• Claude Code Github Actions
  　

Github Docs

• アマゾン ウェブ サービスでの OpenID Connect の構成
• OpenID Connect を使ったセキュリティ強化について

AWS

• Create an OpenID Connect (OIDC) identity provider in IAM
• Create a role for a third-party identity provider

Github App

• Configure AWS Credentials for GitHub Actions

• Claude Code Action