GitHub Actionsとは？Claude Codeハーネスとの関係をわかりやすく解説【2026年版】

GitHub Actionsは、GitHubが提供するCI/CD（継続的インテグレーション／継続的デプロイ）の自動化プラットフォームです。 コードのプッシュやプルリクエストをトリガーに、テスト・ビルド・デプロイなどを自動実行できます。一方、Claude CodeのHooksは、Claude Codeのライフサイクルに応じてローカル開発環境でコマンドやスクリプトを自動実行する仕組みです。両者は自動化という目的は共通していますが、Claude Code Hooksは開発中の作業を支援し、GitHub Actionsはコミットやプルリクエスト後のCI/CDを担うという違いがあります。

Claude Codeを使い始めた開発者から「これ、GitHubのCIでも動かせないの？」という疑問はよく聞かれます。実は、その感覚は理にかなっています。Claude Code HooksとGitHub Actionsはどちらも自動化の仕組みですが、適用されるタイミングや役割が異なります。

この記事では、GitHub Actionsの基礎からClaude Code Hooksとの違い、さらに両者を組み合わせた実践的な開発ワークフローまで解説します。

---

GitHub Actionsとは何か

GitHub Actionsは、GitHubリポジトリに標準で統合されたCI/CDプラットフォームです。2019年にGitHubが正式リリースし、いまや 1.8億人以上の開発者 が集まるGitHub上で最も普及した自動化基盤の一つになっています。2025年にはパブリックリポジトリだけで年間115億分（前年比35%増）のワークフローが実行されました（Octoverse 2025: A new developer joins GitHub every second）。

GitHub Actionsの基本的な仕組み

GitHub Actionsでは「ワークフロー」という単位で自動化を定義します。ワークフローは.github/workflows/ディレクトリに置いたYAMLファイルで記述します。

ワークフローの基本構造は3つの要素で成り立っています。

1. トリガー（on）: どのイベントで実行するか（push、pull_request、scheduleなど）
2. ジョブ（jobs）: 何をするか。並列または順次実行できる処理のまとまり
3. ステップ（steps）: ジョブ内の個々の処理。コマンド実行やアクション呼び出し

シンプルな例を見てみましょう。

.github/workflows/test.yml を作成する:

name: テスト自動実行
on:
  push:
    branches: [main]
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Pythonセットアップ
        uses: actions/setup-python@v5
        with:
          python-version: '3.12'
      - name: テスト実行
        run: pytest tests/

このファイルをリポジトリに置くだけで、mainへのpushやプルリクエスト作成時に自動でテストが走ります。設定ファイルはコードとして管理できるため、チーム全員が同じ自動化ルールを共有できます。

GitHub Actionsでできること

GitHub Actionsは単なるテスト自動化ツールではありません。

コード品質の自動チェック

• lintツール（ESLint、flake8、RuboCopなど）の実行
• 型チェック（mypy、TypeScriptコンパイラ）
• セキュリティスキャン（CodeQLなど）

ビルドとデプロイ

• Dockerイメージのビルドとレジストリへのプッシュ
• クラウドサービス（AWS、GCP、Azure）へのデプロイ
• GitHub Pagesへの静的サイト公開

ワークフロー自動化

• IssueやPRへの自動ラベル付け
• リリースノートの自動生成
• Slackなどへの通知送信

DORA（DevOps Research and Assessment）の2021年版State of DevOpsレポートによると、ソフトウェアデリバリーが最も優れた「エリート」パフォーマーは、最も低い「ロー」パフォーマーと比べて 973倍の頻度でデプロイ しています（2021 State of DevOps Report（PDF））。DORAはGoogleが支援する、ソフトウェアデリバリーのパフォーマンスを定量調査する研究機関です。GitHub Actionsはその実現を後押しするインフラです。

GitHub Actionsの使い方をさらに詳しく知りたい方は、GitHub公式ドキュメントのクイックスタートを参照してください。

---

Claude Codeのハーネスとhooks

「ハーネス」とは、AIモデルそのもの以外の環境全体 ― 何を見せ、どんなツールを使わせ、出力をどうチェックし、問題が起きたらどう直すか ― を指す言葉です。この記事で扱う hooks は、そのハーネスを構成する仕組みの一つで、Claude Codeが特定のアクション（ツール呼び出し）を行う前後に、任意のシェルコマンドを自動実行できます。設定は.claude/settings.json（プロジェクト共有用）または~/.claude/settings.json（個人用グローバル設定）で行います。

hooksの基本と設定方法

「ハーネス」という言葉はもともと馬具を意味します。AIのアクションに「手綱」をつけて制御するイメージで、hooksはその手綱を握る具体的な仕掛けにあたります。ハーネス全体の考え方をより深く理解したい方は、ハーネスエンジニアリングとは？AIエージェント時代の環境設計入門もあわせてご覧ください。

設定ファイルの基本構造はこのようになります。

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit",
        "hooks": [
          {
            "type": "command",
            "command": "npm run lint"
          }
        ]
      }
    ],
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "echo 'コマンド実行前チェック中...'"
          }
        ]
      }
    ]
  }
}

代表的なhookのタイミングとして以下の4種類を紹介します。詳細はClaude Code公式ドキュメント「Hooks」を参照してください。

hooksが解決する問題

Claude Codeで多数のファイルを編集する際、コードのフォーマット忘れが積み重なり、PR提出前に大量のlintエラーが一気に発生するケースがあります。

PostToolUseにPrettierやlintコマンドを設定しておくと、Claude Codeがファイルを編集するたびに自動でフォーマットが走ります。これにより、PR提出前の手作業lint実行が不要になり、コードレビューでのフォーマット指摘をゼロに近づけられます。

このように、hooksは 個人の開発ループを高速化 するためのツールです。

---

GitHub ActionsとClaude Codeハーネスの根本的な違い

この2つのツールは、似ているようで動作する場所・タイミング・目的が大きく異なります。

ローカル自動化とクラウド自動化の違い

最も重要な違いは 実行環境 です。

Claude Code hooksはローカルマシンで動く

• ローカル環境で即座に実行される
• Claude Codeセッション中にリアルタイムフィードバックが得られる
• インターネット接続不要（ローカルコマンドの場合）
• 個人のワークフローを改善する

GitHub Actionsはクラウド（GitHub側）で動く

• コードをリポジトリにpushしたあとに実行される
• チーム全員に適用されるルールを強制できる
• 実行環境はGitHubが管理するランナー（ジョブを実行する仮想マシン）
• チーム全体のワークフローを統一する

比較表：ハーネス vs GitHub Actions

この表を見ると、2つが競合ではなく 補完関係 にあることがわかります。hooksで開発中にすばやくフィードバックを得て、GitHub Actionsでチーム全体の品質基準を担保する。この二層構造が理想的なワークフローです。

---

GitHub Actions × Claude Codeの連携パターン

2つのツールを組み合わせると、より強力な自動化が実現できます。代表的な3つのパターンを紹介します。

パターン1: ローカルhooks + GitHub Actionsの二重チェック

最もシンプルで効果的なパターンです。

ローカル（hooks）: 編集直後にlintとフォーマットを自動実行
GitHub Actions: プッシュ後にフルテストスイート（全テストの一括実行）を実行

.claude/settings.json に設定する:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit",
        "hooks": [
          {
            "type": "command",
            "command": "python3 -m flake8 --max-line-length=100"
          }
        ]
      }
    ]
  }
}

.github/workflows/ci.yml を作成する:

name: CI
on: [push, pull_request]
jobs:
  full-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: フルテスト実行
        run: pytest tests/ --cov=. --cov-report=xml

ローカルで細かいミスを早期に発見し、GitHub ActionsではCI全体を実行する役割分担により、開発フローが効率化されます。

パターン2: GitHub Actions内でClaude APIを使う

より高度なパターンです。GitHub Actions内でAnthropicのAPIを呼び出し、PRの内容をAIがレビューします。

.github/workflows/ai-review.yml を作成する:

name: AI PRレビュー
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  ai-review:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write   # PRにコメントを書くために必要
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: 差分を取得
        run: git diff origin/main...HEAD > diff.txt
      - name: Claude APIでレビュー
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
        run: |
          python3 scripts/claude_review.py diff.txt
          # ※ scripts/claude_review.py は別途作成が必要です。
          # Anthropic SDKでdiff.txtを読み込み、Claude APIへ送信して結果をreview_result.txtに書き出す実装を行います。
      - name: レビュー結果をPRコメントに投稿
        uses: actions/github-script@v7
        with:
          script: |
            const fs = require('fs');
            const review = fs.readFileSync('review_result.txt', 'utf8');
            await github.rest.issues.createComment({
              issue_number: context.issue.number,
              owner: context.repo.owner,
              repo: context.repo.repo,
              body: review
            });

このパターンでは、PRを作成するたびにClaude APIがコードの問題点を自動でコメントします。チームのレビュー負荷を下げながら、品質を一定以上に保てます。ここでpermissionsにpull-requests: writeを付けているのは、ワークフローからPRへコメントを書き込むために必要だからです（デフォルトの権限は読み取りのみのため、これがないとコメント投稿が失敗します）。

なお、スクリプトを自作せずに済ませたい場合は、Anthropic公式のclaude-code-actionを使う方法もあります。ワークフローにアクションを1つ追加するだけで、PR上でClaudeにレビューや修正を依頼できます。

パターン3: コンテンツ制作ワークフローでの活用例

コンテンツ制作やドキュメント管理においても同じ構造が使えます。Claude Codeで記事やドキュメントを執筆しながら、hooksでコンテンツ品質チェックを自動実行し、その後GitHub Actionsでデプロイパイプラインを動かすという流れです。

.claude/settings.json に設定する:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write",
        "hooks": [
          {
            "type": "command",
            "command": "python3 scripts/content_scorer.py"
          }
        ]
      }
    ]
  }
}

ファイルを保存するたびにスコアが自動計算され、基準を下回る場合はその場でフィードバックを受けて修正できます。

CI/CDのパフォーマンス指標を深く学びたい方は、DORA Researchも参照してください。

---

GitHub Actionsの始め方：最小構成ガイド

GitHub Actionsを使ったことがない方向けに、最小構成で始める手順を説明します。ターミナルを使う方法とブラウザ上で完結する方法の2通りを紹介します。

ステップ1: ワークフローファイルを作成する

ターミナルを使う場合:

Mac（ターミナル）:

mkdir -p .github/workflows
touch .github/workflows/hello.yml

Windows（コマンドプロンプト）:

mkdir .github\workflows
type nul > .github\workflows\hello.yml

ブラウザ上で作成する場合:

GitHubのリポジトリページを開き、「Add file」→「Create new file」をクリックします。

「Add file」ボタンからファイルを直接作成できる

ファイル名の入力欄に .github/workflows/hello.yml と入力します。スラッシュを入力するたびに自動でディレクトリが作成されます。

ステップ2: 最小ワークフローを書く

エディタに以下の内容を貼り付けます。

name: はじめてのワークフロー
on: push

jobs:
  hello:
    runs-on: ubuntu-latest
    steps:
      - name: あいさつ
        run: echo "GitHub Actionsが動きました！"

ステップ3: GitHubにプッシュして確認する

ターミナルの場合はコミットしてプッシュします。ブラウザの場合は画面右上の「Commit changes」をクリックしてmainブランチに直接コミットします。

右上の「Commit changes」をクリックしてmainブランチに直接commitする

コミットするとGitHub Actionsが自動で起動します。リポジトリの「Actions」タブを開くと実行結果が確認できます。

commitをトリガーにActionsが自動実行され、Successと表示される

ワークフロー図内の「hello」ジョブのボックスをクリックするか、左サイドバーのジョブ名をクリックすると、ログの詳細が確認できます。

「あいさつ」ステップのログに実行結果が表示される

ステップ4: 実用的なワークフローに拡張する

基本が動いたら、テストやlintのステップを追加していきます。GitHub Actionsには マーケットプレイス に何千もの公式・サードパーティアクションがあります。actions/setup-python、actions/setup-nodeなどのセットアップ用アクションを使えば、環境構築をほぼゼロから書かずに済みます。

---

よくある質問（FAQ）

GitHub Actionsは無料で使えますか？

GitHubのパブリックリポジトリでは 完全無料 で使えます。プライベートリポジトリの場合、Freeプランで月2,000分のランナー時間が無料です。多くの個人プロジェクトはこの範囲に収まります。

Claude Code hooksはチームで共有できますか？

.claude/settings.jsonをリポジトリにコミットすることでチームで共有できます。ただし、実行はあくまで各自のローカル環境です。チーム全員に同じルールを強制適用したい場合はGitHub Actionsの方が適しています。

GitHub Actionsはローカルでテストできますか？

actというオープンソースツールを使うと、ローカル環境でGitHub Actionsのワークフローをテスト実行できます。Dockerが必要ですが、毎回GitHubにプッシュせずに動作確認できて便利です。

Claude Code hooksとGitHub Actionsで同じコマンドを実行すべきですか？

同じlintコマンドを両方で実行するのはよいプラクティスです。ローカル（hooks）で即時フィードバックを得て、GitHub Actions（CI）でチーム全体に同じ基準を強制する。二重チェックにより、問題が本番環境に到達するリスクを大幅に下げられます。

GitHub Actionsのワークフローファイルはどこに置きますか？

リポジトリのルートにある.github/workflows/ディレクトリに、.ymlまたは.yaml拡張子のファイルを置きます。ファイル名は自由ですが、ci.yml、deploy.ymlのように目的がわかる名前にするのがベストプラクティスです。

hooksのコマンドが失敗するとどうなりますか？

hooksコマンドの終了コードによって動作が変わります（Claude Code公式ドキュメント「Hooks」）。

• 終了コード2（ブロッキングエラー）: stderrの内容がClaudeにフィードバックされます。PreToolUseなど事前フックの場合はツール実行もブロックされ、Claudeは次のターンでそのエラー内容を受け取って修正を試みます。PostToolUseはツール実行後のフックのためブロッキングはできませんが、同様にstderrの内容をClaudeに渡せます。
• それ以外の非ゼロ終了コード（1など）: 非ブロッキングエラーとして処理され、ターミナルに警告が出るだけでClaudeには伝わりません。

---

まとめ

GitHub Actionsは「クラウドで動くチームの自動化」、Claude Codeのハーネスは「ローカルで動く個人の自動化」です。この2つは競合するツールではなく、開発ワークフローの異なるレイヤーを担う補完的な存在です。

今日から始められる3つのアクション

1. まずhooksを設定する: .claude/settings.jsonにPostToolUseでlintコマンドを追加する。作業中のフィードバックが即座に得られるようになります。
2. シンプルなActionsから始める: .github/workflows/ci.ymlにテスト自動実行を1つだけ設定する。完璧を目指さず小さく始めることが継続のコツです。
3. 段階的に組み合わせる: ローカルhooksで細かいチェック、GitHub ActionsでフルCI/CD。この二層構造が整ったとき、開発速度と品質が同時に向上します。

両方のツールを適切に使い分けることで、Claude Codeによるコーディング作業の品質をローカルからクラウドまで一貫して担保できます。

---

出典一覧

1. GitHub Blog「Octoverse 2025: A new developer joins GitHub every second」
2. DORA「2021 State of DevOps Report（PDF）」
3. Claude Code公式ドキュメント「Hooks」
4. GitHub公式ドキュメント「GitHub Actionsの課金について」
5. GitHub Actions クイックスタート
6. DORA Research（DevOps調査レポート）