デプロイ直後に不具合の報告が来たのに、本番で動いているのがどのコミットなのか分からず、ログとCIの履歴を交互ににらめっこした経験はありませんか。/actuator/info は標準では空っぽですが、build-infoプラグインとgit-commit-id-pluginを組み合わせれば、ビルド時にバージョンとコミットハッシュを自動的に埋め込めます。
この記事では management.info.* の設定からMaven/Gradleでのbuild-info・git.properties生成、CI/CDでの検証スクリプトまでをSpring Boot 3.x世代を前提にまとめます。Actuatorの入門記事 でhealth/infoを有効化済みの方が対象で、InfoContributor全般のカスタマイズやヘルスチェックは扱いません。
/actuator/infoが空っぽになる理由
Actuatorの info エンドポイントは、BuildInfoContributor と GitInfoContributor が META-INF/build-info.properties と git.properties をクラスパスから探して値を組み立てる仕組みです。info が空になる本当の原因は、たいていこの2つのファイルが生成されていないことにあります。
management.info.build.enabled と management.info.git.enabled はSpring Boot 3.xではデフォルトで true です。省略しても動きますが、下記のように明示しておくと設定ファイルを見ただけで有効化されていることが分かるので、チームで運用する際はおすすめです。
management:
info:
build:
enabled: true
git:
enabled: true
mode: simple
management.info.build.enabled=true
management.info.git.enabled=true
management.info.git.mode=simple
mode: simple(デフォルト)はブランチ名と短縮コミットハッシュを文字列で返します。mode: full にすると git.commit.id が {full: ..., abbrev: ...} のようなオブジェクトになり、コミッターやコミット日時なども詳細に含まれます。後述の検証スクリプトはjqで文字列として git.commit.id を読むので、本記事では simple を使います。
Mavenでbuild-infoとgit.propertiesを生成する
spring-boot-maven-pluginに build-info ゴール、git-commit-id-maven-plugin に revision ゴールを設定します。
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<executions>
<execution>
<goals><goal>build-info</goal></goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>io.github.git-commit-id</groupId>
<artifactId>git-commit-id-maven-plugin</artifactId>
<version>9.0.1</version>
<executions>
<execution>
<goals><goal>revision</goal></goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
spring-boot-maven-pluginは spring-boot-starter-parent を継承していれば <version> を省略でき、pluginManagementの値が自動的に使われます。一方git-commit-id-maven-pluginはSpring公式のpluginManagementに含まれていないため、<version> を省略すると mvn package の実行時にプラグイン解決エラーでビルドが失敗します。上の例のように必ずバージョンを明記し、最新版はMaven Centralで確認してください。
mvn package を実行すると target/classes/META-INF/build-info.properties と target/classes/git.properties が書き出され、Spring Bootが起動時に自動で読み込みます。出力先を変えたい場合は generateGitPropertiesFilename で git.properties のパスを指定できますが、特別な事情がなければデフォルトのままで問題ありません。
Gradleでbuild-infoとgit.propertiesを生成する
Gradleは springBoot.buildInfo() でbuild情報を生成します。git情報については、git-commit-id-pluginは元々Maven向けに作られたプラグインで、Gradle版は別実装のサードパーティプラグインとして提供されています。Gradleエコシステムでは同じ目的で gradle-git-properties が広く使われているため、本記事でもこちらを使います。
plugins {
id("com.gorylenko.gradle-git-properties") version "4.0.1"
}
springBoot {
buildInfo()
}
Mavenでは <executions> でgoalを明示的に指定する必要がありましたが、Gradleではプラグインを適用するだけで generateGitProperties タスクが自動的に build/bootJar にフックされ、追加設定なしでgit.propertiesが生成されます。bootBuildInfo タスクも同様に build/bootJar に依存するため、個別実行は不要です。
Gradle側にはMavenのpluginManagementのような仕組みがないため、バージョン指定は必須です。最新版はGradle Plugin Portalで確認しましょう。
/actuator/infoの出力を確認する
アプリを起動してcurlで叩いてみましょう。
curl -s localhost:8080/actuator/info | jq
{
"build": {
"artifact": "myapp",
"version": "1.4.0",
"time": "2026-10-01T03:12:45Z"
},
"git": {
"branch": "main",
"commit": {
"id": "3f2a9c1",
"time": "2026-09-30T21:05:00Z"
}
}
}
ローカルの値はあくまで確認用です。本番で知りたいのはCI/CD経由でビルドされた値なので、最終確認はパイプライン上で行いましょう。
CI/CDでデプロイ後のバージョンを検証する
設定が揃ったら、デプロイ直後に /actuator/info を叩いて期待コミットと比較する検証をパイプラインに足しましょう。CI側が持っている GITHUB_SHA などのコミットハッシュと、本番から返ってきた git.commit.id を比較し、不一致ならデプロイを失敗扱いにすることで、古いバージョンの残存を早期に検知できます。
ただしこの検証を組んだ直後は、思ったように値が反映されずにハマることがあります。多いのはGitHub Actionsのデフォルト設定(fetch-depth: 1 のshallow clone)でgit履歴が足りず git.properties の中身が不完全になるケース、Dockerのマルチステージビルドで古いレイヤーがキャッシュされたままbuild-info/git.propertiesだけ更新されないケース、そして application-prod.yml など環境別の設定ファイルで management.info.* を上書きしてしまい本番だけ info が空になるケースです。検証スクリプトを書く前に、一度本番相当の環境で /actuator/info を直接叩いて中身を確認しておくと安心です。
検証スクリプトの実装例
#!/bin/bash
set -euo pipefail
EXPECTED_COMMIT="${GITHUB_SHA:0:7}"
RESPONSE=$(curl -sf https://example.com/actuator/info) || {
echo "failed to reach /actuator/info"
exit 1
}
ACTUAL_COMMIT=$(echo "$RESPONSE" | jq -r '.git.commit.id // empty')
if [ -z "$ACTUAL_COMMIT" ]; then
echo "git.commit.id not found in response: $RESPONSE"
exit 1
fi
if [ "$ACTUAL_COMMIT" != "$EXPECTED_COMMIT" ]; then
echo "commit mismatch: expected=$EXPECTED_COMMIT actual=$ACTUAL_COMMIT"
exit 1
fi
echo "deployed commit verified: $ACTUAL_COMMIT"
curl -f で通信エラーを、jq で値欠落を検知し異常終了させます。デプロイジョブの最後に挟めば、古いコンテナが残る事故に早く気づけます。
まとめ
build-infoプラグインとgit-commit-id-pluginを組み合わせるだけで、/actuator/info は「今動いているバージョンとコミット」を答える実用的なエンドポイントになります。CI/CDのデプロイ後にこの値を検証すれば、ロールバック判断の時間もぐっと短縮できます。
ヘルスチェックまで含めてActuatorを拡張したい場合は カスタムHealthIndicatorの記事 を、コンテナ化の基本を見直したい場合は Dockerコンテナ化の記事 もあわせて参考にしてください。