AWS CodeBuildとは？Jenkins・GitHub Enterpriseとの連携までわかりやすく図解【初心者向け】

この記事でできること

• AWS CodeBuildが「そもそも何をするサービスなのか」を、前提知識なしで説明できるようになる
• なぜCodeBuildが「便利」とされるのか、その本質的な理由がわかる
• Jenkins、GitHub Enterprise（GHE）など既存のツールとどう連携するかを、図で整理できる
• 業務でCodeBuildに触れるときに、最低限押さえておくべき実務ポイントがわかる

結論：CodeBuildは「使い捨てのビルド専用マシンを、必要な瞬間だけ借りるサービス」

まず「ビルド」という言葉から整理します。ビルドとは、書いたソースコードを、コンパイル・テスト実行・パッケージ化して「実際に動かせる状態」にする一連の作業のことです。

このビルド作業には、実行するための「マシン」が必要です。従来のJenkinsであれば、ビルドを実際に処理する専用サーバー（これをビルドノードまたはビルドエージェントと呼びます）を、自分たちで用意し続ける必要がありました。Jenkins本体は「いつ・何を・どの順番でビルドするか」を管理する司令塔で、実際に手を動かしてビルドを実行するのは、この裏方のビルドノードです。

CodeBuildは、このビルドノードの部分を「使うときだけ借りて、使い終わったら消す」形でAWSが肩代わりしてくれるサービスです。Jenkinsそのものの置き換えではなく、「重い実行作業を担当するマシン」だけをAWS側に持たせる、というのが位置づけです。

本質：なぜ「毎回ゼロから作り直す」ことが重要なのか

CodeBuildの一番の特徴であり、実は最も本質的な価値がここにあります。

自分たちでビルドノードを長期間動かし続けていると、次のような問題が起きがちです。

• 誰かが手動でツールをインストールした
• 前回のビルドのキャッシュファイルが残っていた
• 環境変数の設定を誰かが変えていた

こうした「そのサーバー固有の、記録に残らない変化」が積み重なった結果、「Aさんのビルドノードでは動くのに、Bさんのビルドノードでは失敗する」という原因不明の不具合が起きます。これは一般にスノーフレークサーバー問題（雪の結晶のように、1つ1つ形が違ってしまったサーバー、という意味）と呼ばれています。

CodeBuildは、ビルドを実行するたびに、あらかじめ決められた設計図（イメージ）からまったく新しいコンテナを起動し、指定した手順だけを実行し、終わったら跡形もなく破棄します。次にビルドするときは、また同じ設計図から新品の状態で始まります。

つまり「サーバーを保守する」のではなく「毎回、同じ条件の使い捨ての箱を借りてくる」という発想です。これにより「誰が・いつ実行しても、同じ手順なら同じ結果になる」という再現性が生まれます。これがCodeBuildの本質的な価値であり、単なる「サーバー管理が楽」以上の意味を持っています。

黄色（オレンジ枠）が「毎回作り直される使い捨ての部分」、水色（青枠）が「既存の仕組みのまま変わらない部分」です。

そもそも何をしてくれるのか

CodeBuildの処理は、大きく次の流れです。

1. GitHubなどのソースリポジトリからコードを取得する
2. buildspec.yml という設定ファイルに書いた手順どおりにコマンドを実行する
3. テスト結果や成果物（アーティファクト：ビルドの結果として出来上がるファイル一式。jarファイルやDockerイメージなど）を出力する

buildspec.yml の中身は4つのフェーズ（段階）に分かれています。

version: 0.2
phases:
  install:
    commands:
      - echo "実行環境のセットアップ（言語ランタイムのインストールなど）"
  pre_build:
    commands:
      - echo "依存パッケージのインストールなど、ビルド前の準備"
  build:
    commands:
      - echo "テスト実行やコンパイルなど、ビルド本体"
  post_build:
    commands:
      - echo "Dockerイメージのpushなど、ビルド後の後処理"
artifacts:
  files:
    - '**/*'

料金面の特徴もあわせて押さえておきます。

• 従量課金：実際に使ったビルド時間（分単位）に対してのみ課金される。build.general1.small には月100分の無料枠がある（12ヶ月間の期間制限なし）
• フルマネージド：先ほど説明した「使い捨てコンテナ」の起動・破棄・スケーリングをAWSが自動で行うため、こちらでサーバーの台数管理やOSのパッチ適用を行う必要がない

何と連携できるのか

ソースの取得元：GitHub / GitHub Enterprise（GHE）など

CodeBuildは、CodeCommit・GitHub・GitHub Enterprise Server・Bitbucket・S3などをソースとして直接指定できます。

GitHubやGHEをソースにした場合、Webhook（リポジトリ側で起きた出来事、例えば「pushされた」を、あらかじめ登録しておいた別のサービスへ自動で知らせる仕組み）を設定しておけば、「mainブランチにpushされたら自動でビルドを実行する」といったトリガーが組めます。

以前のGHE（GitHub Enterprise Server）では、このWebhookを利用者側が手動で作成・管理する必要がありました。2025年2月以降はCodeBuild側がWebhookの作成・管理まで面倒を見てくれる「マネージドWebhook」に対応しています。オンプレミスのGHEを使っている組織では、この設定の手間が減った点は覚えておく価値があります。

実行元：Jenkinsとの組み合わせ方

先ほど触れたとおり、Jenkinsには「司令塔（Jenkins本体）」と「実行役（ビルドノード）」という2つの役割があります。この構成のまま、実行役の部分だけをCodeBuildに任せることができます。これを実現するのが AWS CodeBuild Plugin for Jenkins です。

赤枠は「ずっと稼働し続け、状態が蓄積していくノード」、緑枠は「毎回作り直される使い捨てのコンテナ」です。Jenkins本体（司令塔）はそのまま残り、実行役だけが交代しているのがポイントです。

設定パターンは主に2つです。

• Use Project source：CodeBuildプロジェクト側で設定したソース（GitHubなど）をそのまま使う
• Use Jenkins source：Jenkins側の「ソースコード管理」で取得したコードをCodeBuildに渡してビルドさせる

Jenkins側にはCodeBuildを操作するためのIAMユーザー（AWS上で「誰が・何をしてよいか」を管理する権限の仕組みにおける、操作の主体）が必要で、最低限 codebuild:StartBuild / codebuild:BatchGetBuilds / codebuild:BatchGetProjects と、ログ取得用の logs:GetLogEvents の権限を付与します。

つまり「Jenkinsを捨ててCodeBuildに乗り換える」のではなく、「ジョブの順序管理や承認フローはこれまでどおりJenkinsが担当し、重いビルド実行の部分だけCodeBuildの使い捨てコンテナに肩代わりしてもらう」という使い方です。すでにJenkinsで複雑な運用を組んでいるチームほど、全部を作り直さずに済むこの移行の仕方が現実的です。

パイプライン全体：CodePipeline

CodeBuild単体は「ビルドを1回実行する」機能しか持っていません。ビルド→デプロイまでの一連の流れを組みたい場合は、CodePipelineというサービスの中の「ビルド/テストアクション」としてCodeBuildを組み込みます。

そのほかの連携

• Amazon ECR：ビルドの中でDockerイメージを作成し、そのままECRにpushする構成が一般的
• Amazon S3：ビルドキャッシュの保存先、成果物の出力先として利用
• AWS Chatbot：ビルドの成功・失敗をSlackに通知する構成が組める
• AWS Systems Manager（Session Manager）：codebuild-breakpoint を使うと、ビルド実行中のコンテナに一時的に入り、対話的に中身を確認できる

実務でよくある使いどころ：UTの自動実行とAIコードレビュー

CodeBuildが「何をするか」に加えて「実際どんな場面で使われるか」を見ると、イメージがつかみやすくなります。代表的な2つの例を挙げます。

例1：pushのたびにUT（単体テスト）を自動実行する

もっとも多い使い方は、コードがpushされるたびにテストを自動実行することです。build フェーズでテストコマンドを実行するだけで組み込めます。

version: 0.2
phases:
  install:
    commands:
      - npm install
  build:
    commands:
      - npm test
reports:
  jest_reports:
    files:
      - junit.xml
    file-format: JUNITXML
    base-directory: reports

reports セクションでテスト結果をJUnit形式で出力すると、CodeBuildのコンソール上でテスト結果やカバレッジを確認できます。テストが1件でも失敗すればビルド全体が失敗として扱われるため、「テストが通らないコードはそもそもマージできない」という運用を作りやすくなります。

例2：AIによるコードレビューを自動化する

AWSには、機械学習でコードの品質問題やセキュリティリスクを検出する Amazon CodeGuru Reviewer というサービスがあります。これをbuildspec.ymlの中からAWS CLIで呼び出すことで、「pushのたびにAIレビューを走らせる」という構成をCodeBuildの上に作れます。

build:
  commands:
    - aws codeguru-reviewer create-code-review --name "$CODEBUILD_BUILD_ID" --repository-association-arn "$ASSOCIATION_ARN" --type '{"RepositoryAnalysis":{"RepositoryHead":{"BranchName":"main"}}}'
    - aws codeguru-reviewer wait code-review-completed --code-review-arn "$REVIEW_ARN"
    - aws codeguru-reviewer describe-code-review --code-review-arn "$REVIEW_ARN"

create-code-review でレビューを開始し、wait code-review-completed で完了を待ち、describe-code-review で結果を取得する、という3ステップです。CodeBuildは「AWS CLIが実行できる使い捨てのマシン」でもあるため、こうした外部サービスの呼び出しをビルド手順の一部として自然に組み込めます。

業務で知っておくべきこと（着手前チェックリスト）

• キャッシュを設定したか：CodeBuildの実行環境は毎回まっさらな状態で起動する。依存パッケージのダウンロードなどをS3キャッシュやローカルキャッシュで持ち回らないと、ビルド時間が伸びやすい。
• VPC内リソースへのアクセス設定は済んでいるか：VPCとは、AWS上に作る「社内ネットワークのような、外部から隔離された範囲」のこと。社内DBなど、VPC内のプライベートリソースにビルド中からアクセスしたい場合は、CodeBuildプロジェクトをそのVPCに接続する設定が別途必要（デフォルトでは届かない）。
• IAM権限を必要な範囲に絞ったか：CodeBuildプロジェクトに付与する権限は、ビルドが実際に必要とする範囲（特定のS3バケット、特定のECRリポジトリなど）に絞る。Jenkinsから呼び出す構成の場合は、Jenkins側の権限も同様に絞る。
• 料金の見積もりはビルドの並列数まで含めて計算したか：料金は「ビルド時間×コンピューティングタイプの単価」で決まる。並列実行数やインスタンスサイズを上げるほど単価も上がる。
• Jenkinsとの併用方針は「置き換え」ではなく「実行役の交代」で合意できているか：承認フローや複雑なジョブ依存関係をすでにJenkinsで組んでいるなら、それを壊してCodeBuildに全部移すのではなく、実行役だけを交代させる方が移行コストが低い。

まとめ

AWS CodeBuildの本質は、「サーバーを管理すること」から「毎回ゼロから作り直される使い捨ての実行環境を、必要なときだけ呼び出すこと」への発想の転換にあります。この「使い捨てだから、いつ実行しても同じ結果になる」という再現性こそが、単なる料金体系やマネージド化以上の価値です。

GitHub / GitHub Enterprise からは直接ソース連携とWebhookトリガーで、Jenkinsからはプラグイン経由で「実行役だけ交代させる」形で、それぞれ既存の仕組みを大きく変えずに組み込めます。UTの自動実行やAIコードレビューのように、既存のツールをビルド手順に呼び込む使い方も定番です。実務では、キャッシュ・VPC接続・IAM権限の3点を最初に設計しておくと、後からのハマりどころを減らせます。