結論：Claude Code は「デプロイ・リリース作業そのものを丸ごと自動化するツール」ではなく、既存のワークフロー（CI/CD設定）を読んで理解し、修正案を出し、失敗の原因を切り分ける相棒として使うのが安全で実用的です。生成された設定は必ず人がレビューしてから本番に流します。
- 要点1：まず既存の
.github/workflows/*.ymlを Claude Code に読ませて「何をしているワークフローか」を日本語で説明させると、引き継ぎや改修の入口になる。 - 要点2：CI が落ちたらログを貼って原因を切り分けさせる。テスト・lint・ビルドの失敗箇所の特定に強い。
- 要点3：Secrets（APIキー等）は GitHub の Secrets 機能で管理し、
${{ secrets.NAME }}で参照する。生成された YAML に鍵を直書きさせない。
対象読者：GitHub Actions を使っている／これから使う開発者・PM・SRE。CI/CD は一応動いているが、設定の意味が分からず触るのが怖いという人。
今日やること：手元のリポジトリで .github/workflows/ の中身を1ファイル Claude Code に読ませ、「このワークフローを箇条書きで説明して」と頼んでみる。
「CI/CD は前任者が組んだまま動いてるけど、誰も中身を分かってない」。チームの規模を問わず、これは本当によく聞く話です。GitHub Actions の YAML は、トリガー・ジョブ・ステップが入れ子になっていて、慣れていないと「どこを触ると何が壊れるか」が読めません。正直に言うと、私自身も久しぶりに他人のワークフローを開くと、毎回ひるみます。
そこで役立つのが Claude Code です。この記事では、CI/CD・自動化まわりで Claude Code を「安全に」使う実践的な進め方を、GitHub Actions の公式仕様で裏取りしながら、YAML 例つきで解説します（2026年6月時点）。なお、Claude Code 公式には GitHub と連携する anthropics/claude-code-action という仕組みもあり、後半で公式ドキュメントを根拠に触れます。
そもそも GitHub Actions のワークフローとは（最低限の地図）
Claude Code に設定を読ませる前に、用語の地図だけ持っておくと話が早いです。GitHub Actions の公式ドキュメントによると、ワークフローは .github/workflows ディレクトリに置く YAML ファイルで、「1つ以上のイベント」「1つ以上のジョブ」「ジョブ内の1つ以上のステップ」で構成されます（GitHub Docs「About workflows」2026年6月時点）。
ざっくり対応させると、こうなります。
on：いつ動かすか（トリガー）。push、pull_request、手動実行のworkflow_dispatch、定期実行のscheduleなど。jobs：実行する仕事のまとまり。各ジョブはランナー（仮想マシン）上で動く。runs-on：どのランナーで動かすか（例：ubuntu-latest）。steps：ジョブ内の手順。usesで既存のアクションを呼ぶか、runでシェルコマンドを実行する。
最小構成の例はこんなイメージです。
name: CI
on:
push:
branches: [main]
pull_request:
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Run tests
run: npm ci && npm test
この程度の地図があれば、あとは「中身を読む・直す・落ちた原因を調べる」を Claude Code に手伝ってもらえます。「全部覚えてから使う」のではなく、「Claude Code に説明させながら覚える」順番で十分です。
① 既存のワークフロー設定を読ませて理解する
最初の使いどころは、新規作成ではなく「読解」です。引き継いだリポジトリで、まず既存の YAML を Claude Code に読ませて意味を言語化させます。
プロンプト例：
.github/workflows/ 配下のワークフローファイルをすべて読んで、
それぞれについて以下を箇条書きで説明してください。
- いつ動くか（トリガー）
- 何をするか（テスト/lint/ビルド/デプロイ等）
- 外部依存（使っているアクション、Secrets、外部サービス）
- 気になる点（古いアクションのバージョン、権限の広さなど）
不明な点や、設定ファイルだけでは判断できない点は「仮定」と明記してください。
ポイントは、最後の一文です。「設定ファイルだけでは判断できない点は仮定と明記して」と添えると、Claude Code が憶測を事実のように書くのを抑えられます。CI/CD はインフラに直結するので、断定とのあいだに線を引かせるのは効きます。
実際にこの読解をやると、「このジョブ、main への push でしか動いてなくて PR では走ってない」「checkout が古い」といった、人が見落としがちな点が箇条書きで返ってきます。引き継ぎ初日の一歩目として、かなり現実的です。コードベース全体の把握を急ぐなら、Claude Code 実践テクニック完全ガイドの読み解き手順と組み合わせると効率が上がります。
② ワークフローの新規作成・修正（テスト・lint・ビルドの自動化）
意味が分かったら、次は修正・追加です。たとえば「PR のときもテストと lint を走らせたい」という改修を頼みます。
プロンプト例：
このリポジトリは Node.js プロジェクトです（package.json 参照）。
pull_request のときに、以下を自動実行する GitHub Actions ワークフローを
.github/workflows/ci.yml として作ってください。
- 依存インストール（npm ci）
- lint（npm run lint）
- テスト（npm test）
- ビルド（npm run build）
注意：
- actions/checkout は最新の安定版を使う
- Secrets は必要な場合のみ ${{ secrets.NAME }} で参照し、鍵は直書きしない
- 各コマンドが存在するか不明なら、その旨をコメントで明記する
生成されるのは、こんな形のファイルです（あくまで叩き台。最終形は自分のプロジェクトに合わせて調整します）。
name: CI
on:
pull_request:
jobs:
build-and-test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: "20"
cache: "npm"
- run: npm ci
- run: npm run lint
- run: npm test
- run: npm run build
ここで大事なのは、これは「テスト・lint・ビルドの自動化」までの設定であって、「本番デプロイ」とは段階が別だという点です。いきなりデプロイまで自動化させようとせず、まずは「PR で品質チェックが回る」状態を作るのが安全です。テスト整備そのものを Claude Code に任せたいときは、Claude Code で QA・テスト自動化を加速する実践ガイドも参照してください。
③ 失敗の原因調査（CI ログを読ませて切り分ける）
CI/CD で一番時間を溶かすのが「赤くなったけど原因が分からない」状態です。ここは Claude Code がかなり強い領域です。落ちたジョブのログをコピーして貼り、設定ファイルと突き合わせて切り分けさせます。
プロンプト例：
GitHub Actions の test ジョブが失敗しました。
以下はログの該当部分です（貼り付け）。
このワークフローファイル（.github/workflows/ci.yml）も踏まえて、
1. 失敗の直接原因として考えられること（複数あれば優先度順に）
2. それぞれの確認方法
3. 修正案（YAML またはコードの差分）
を出してください。
ログだけで断定できない場合は、追加で確認すべきログ行を指定してください。
たとえば「依存のバージョン不整合」「環境変数の未設定」「ランナーに無いツールを run で呼んでいる」といった原因を、ログの文面から拾って候補を並べてくれます。「断定できないなら確認すべきログ行を指定して」と頼むのがコツで、これで一発回答の精度に依存せず、調査の段取りまで任せられます。
ただし、ここでも最終判断は人です。ログには Secrets の値や内部のパスが混じることがあるので、外部に貼る前に機微情報をマスクするのを忘れないでください。
④ 秘密情報（Secrets）の安全な扱いの考え方
CI/CD で AI を使ううえで、一番神経を使うのが Secrets です。GitHub Actions の公式ドキュメント「Using secrets in GitHub Actions」（2026年6月時点）の内容をもとに、最低限おさえる点を整理します。
- Secrets は GitHub の機能で保管する。リポジトリの Settings → Secrets and variables → Actions から「New repository secret」で登録します。環境（Environment）単位、組織（Organization）単位でも作れます。
- ワークフローからは
${{ secrets.NAME }}で参照する。公式の構文どおり、with:やenv:に渡して使います。 - Secrets は
if:条件式の中では直接参照できない（公式記載）。条件分岐に使いたいときは一度env等を経由します。 - フォークからのワークフローには Secrets が渡らない（
GITHUB_TOKENを除く、公式記載）。外部 PR で機密が漏れない設計になっています。 - GitHub の Secret 以外の機微情報は
::add-mask::VALUEでマスクする（公式の推奨）。 - コマンドラインで Secrets を引き回さない。公式は「可能な限り、コマンドラインのプロセス間で Secrets を受け渡さない」よう推奨しています（他ユーザーから見える可能性があるため）。
YAML での参照はこの形です。
steps:
- name: Deploy
env:
DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}
run: ./scripts/deploy.sh
Claude Code に設定を書かせるときは、プロンプトに必ず「鍵は直書きせず ${{ secrets.NAME }} で参照する」と明記してください。逆に言えば、生成された YAML に API_KEY: "sk-..." のような直書きが混じっていたら、その時点で破棄します。生成 → 人がレビュー → マージ、の順は崩さないのが鉄則です。Claude Code 自体の権限・許可ツールの設定を見直したいときは、Claude Code settings.json 設定完全ガイドもあわせて確認すると安全です。
⑤ 段階的に導入するロードマップ
「明日から全部 Claude Code で CI/CD を回す」は、おすすめしません。壊れたときの影響が大きいので、効果が見えやすく事故りにくい順に広げます。以下は導入の進め方の想定モデル（一般的な段取り）です。
Phase 1（読解・調査だけ）：既存ワークフローの説明と、CI 失敗時のログ調査だけに使う。本番への書き込みは発生しないので、いちばん安全に始められる。
Phase 2（PR チェックの整備）：テスト・lint・ビルドを pull_request で回すワークフローを Claude Code に下書きさせ、人がレビューしてマージ。ここまでは「品質チェック」の範囲で、デプロイには触れない。
Phase 3（デプロイ・リリースへ慎重に拡張）：ステージング環境へのデプロイから着手し、本番は手動承認（workflow_dispatch による手動実行や Environment の承認）を挟む。GitHub Docs によると workflow_dispatch でワークフローを手動実行でき、「Run workflow」から起動できます（2026年6月時点）。いきなり main への push で本番自動デプロイ、にはしない。
この順番なら、各段階で「人がレビューする」工程を必ず通れます。AI に丸投げではなく、AI が下書きして人が承認する、という協業の形です。
Claude Code 公式の GitHub Actions 連携（claude-code-action）
ここまでは「ローカルの Claude Code に設定を読ませる・直させる」使い方でしたが、Claude Code には GitHub 上で動く公式の連携もあります。公式ドキュメント（Claude Code GitHub Actions、2026年6月時点）によると、PR や Issue で @claude とメンションすると、コードの分析・PR 作成・実装・バグ修正などを実行できる、と説明されています。
セットアップは、ターミナルで Claude Code を開いて /install-github-app を実行するのが最も簡単な方法、とされています（リポジトリ管理者権限が必要）。手動セットアップの場合は、(1) Claude GitHub アプリをリポジトリにインストール、(2) リポジトリの Secrets に ANTHROPIC_API_KEY を追加、(3) ワークフローファイルを .github/workflows/ にコピー、という手順が公式に示されています。
基本的なワークフローの形は、公式の例ではこうなっています。
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 }}
# コメント内の @claude メンションに反応する
ここでも、API キーは ${{ secrets.ANTHROPIC_API_KEY }} で参照し、ワークフローに直書きしないのが公式の指示です（「API キーをリポジトリに直接コミットしない」と明記）。また、公式の v1 では uses のバージョンを @v1 にし、max_turns や model といった旧 beta の入力は claude_args に移す、という変更点も案内されています（公式の Breaking Changes 一覧）。Anthropic アプリをインストールすると、Contents・Issues・Pull requests の Read & write 権限を要求する点も公式に記載があります。
なお、Amazon Bedrock や Google Vertex AI 経由で使う企業向けの構成も公式に用意されていますが、その場合は /install-github-app のクイックセットアップは対象外で、OIDC や Workload Identity Federation を使った認証設定が別途必要になります（公式ドキュメント記載）。導入を検討する場合は、必ず公式の最新ドキュメントで権限とコスト（GitHub Actions の実行分と API トークン消費）を確認してください。
【要注意】よくある失敗パターンと回避策
CI/CD まわりで Claude Code を使うとき、特に踏みやすい落とし穴です。
失敗1：生成された設定をそのまま本番に流す
❌「動くワークフローを書いて」と頼んで、出てきた YAML をレビューせずに main へ push。
⭕ 生成物は必ず叩き台として扱い、トリガー・権限・Secrets 参照を人が1行ずつ確認してからマージする。CI/CD は壊れると全員が止まるので、コードレビューは省略しない。レビュー自体を効率化したいなら Claude Code でコードレビューを効率化する実践ガイドが参考になります。
失敗2：権限と Secrets を広げすぎる
❌ とりあえず permissions: write-all にして、Secrets も全部読めるようにして動かす。
⭕ 必要最小限の権限・Secrets だけに絞る。公式も「アクションの権限は必要なものだけに限定する」と推奨しています。Secrets はログに出さない（必要なら ::add-mask:: でマスク）。
失敗3：AI の原因切り分けを鵜呑みにする
❌ CI ログを貼って返ってきた「これが原因です」を、確認せずにそのまま修正してまた CI を回す。
⭕ 候補は候補として受け取り、「確認方法」をセットで出させて、自分で1つずつ潰す。特にインフラ・本番に関わる変更は、ステージングで検証してから本番へ。
よくある質問（FAQ）
Q1. Claude Code はデプロイを完全自動化してくれますか？
「設定を書く・直す・落ちた原因を調べる」までを強力に手伝いますが、本番デプロイを人のレビューなしで丸ごと任せる使い方は推奨しません。生成された設定は人が承認してから流すのが安全です。
Q2. API キーはどこに置けばいいですか？
GitHub のリポジトリ Secrets（または環境・組織の Secrets）に登録し、ワークフローでは ${{ secrets.NAME }} で参照します。YAML に直書きしないでください（GitHub・Claude Code 双方の公式が直書きを禁止しています）。
Q3. @claude でメンションしても反応しません。
公式のトラブルシューティングでは、GitHub アプリが正しくインストールされているか、ワークフローが有効か、Secrets に API キーが設定されているか、コメントが /claude ではなく @claude になっているか、を確認するよう案内されています。
Q4. フォークからの PR で Secrets は漏れませんか？
GitHub の仕様上、GITHUB_TOKEN を除き、フォークから起動されたワークフローには Secrets が渡されません。外部コントリビューターの PR で機密が露出しない設計になっています。
Q5. Bedrock や Vertex AI でも使えますか？
使えますが、クイックセットアップ（/install-github-app）の対象外です。OIDC や Workload Identity Federation による認証設定が別途必要になるため、公式ドキュメントの手順に沿って構成してください。
まとめ：今日から始める3ステップ
CI/CD・自動化で Claude Code を安全に使う最短ルートはこうです。
- 読解から始める：手元の
.github/workflows/を1ファイル読ませ、何をしているか日本語で説明させる。 - PR チェックを整える：テスト・lint・ビルドを
pull_requestで回すワークフローを下書きさせ、人がレビューしてマージ。 - デプロイは段階的に：ステージング→手動承認つき本番、の順で広げる。生成設定は必ず人が確認してから流す。
「AI に丸投げ」ではなく「AI が下書きして人が承認する」。この線さえ守れば、CI/CD という壊れたら困る領域でも、Claude Code は十分に頼れる相棒になります。まずは1ファイル読ませるところから、気軽に試してみてください。
著者プロフィール
佐藤傑（さとう・すぐる）。株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。100社以上の企業向けAI研修・導入支援を展開。著書『AIエージェント仕事術』（SBクリエイティブ）。SoftBank IT連載7回執筆。
