【入門編】GitHub Actionsのログをカスタマイズ！「Grouping」と「Ansi Color」でCI結果の視認性を劇的に向上させる方法 – バージョン管理・CI/CD活用バイブル

【GitHub Actions】ログの迷子よ、さらば！「Grouping」と「ANSI Color」でCI/CDの視認性を劇的に引き上げる極意

こんにちは！日々の開発、本当にお疲れ様です。

突然ですが、あなたは「CI/CDのビルドログ」をじっくり見たことがありますか？
バグが発生したとき、あるいはデプロイが失敗したとき、真っ黒な画面に何千行と出力される無機質なログの砂漠から、原因となる1行を探し出す……。これ、本当に骨が折れる作業ですよね。

「CI/CDは自動で動いてくれればそれでいい」

そう思っていませんか？
実は、「エラーが発生したときに、いかに早く原因に気づけるか」というログの視認性（ベロシティ）こそが、開発チーム全体の生産性を左右する極めて重要な鍵なのです。

この記事では、GitHub Actionsを触り始めたばかりのあなたに向けて、ログを劇的に美しく、そして一目で状況が理解できるようにカスタマイズする「Grouping（折りたたみ）」と「ANSI Color（色付け）」の技術を優しく、丁寧に伝授します。

これをマスターすれば、毎日のエラーチェックが劇的に楽になり、チームの仲間からも「このログ、めちゃくちゃ見やすい！」と感謝されること間違いなしです。さあ、一緒に一歩先のDevOpsの世界へ踏み出しましょう！

—

1. なぜログの「見た目」にこだわるべきなのか？

GitHub Actionsは非常に強力なツールですが、デフォルトのままだとすべての出力がフラットに、そして同じ色（基本は白か薄いグレー）で表示されます。

これには2つの大きな問題（ストレス）があります。

1. スクロール疲れ：インストールコマンド（`npm install`など）の何百行ものログがそのまま表示され、本当に見たいテスト結果が埋もれてしまう。
2. 認知負荷：エラーが発生しているのに、警告や正常なログと同じ色で表示されるため、どこで落ちたのか瞬時に判断できない。

これを解決するのが、GitHub Actionsに用意されている「ワークフローコマンド」と、ターミナルでおなじみの「ANSIカラーコード」です。

—

2. 視認性を劇的に変える「2つの魔法」

まずは、今回使用する2つの強力なテクニックの概要を理解しましょう。

① Grouping（ログの折りたたみ）

ログの特定の区間を、アコーディオンのようにクリックで開閉できる「グループ」にまとめる機能です。
不要なときは閉じておき、詳細を見たいときだけ展開できるようになります。

② ANSI Color（テキストの着色）

文字の色を赤（エラー）、黄（警告）、緑（成功）などに変更します。
心理的にも、直感的に「何が起きているか」を脳に伝えることができます。

—

3. 実践セットアップ！「ハロー・カラフル・ワールド」を作ろう

それでは、実際に動くGitHub Actionsのワークフローを作ってみましょう。今回は初心者の方でも迷わず進められるよう、リポジトリの作成から、最も美しく安全なコードの記述までステップバイステップで解説します。

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

GitHub上のあなたプロジェクト（または練習用の新規リポジトリ）のルートディレクトリに、以下のフォルダとファイルを作成してください。

  • フォルダパス: `.github/workflows/`
  • ファイル名: `beautiful-logs.yml`

ステップ2: コードの記述

作成した `beautiful-logs.yml` に、以下のコードをコピー＆ペーストしてください。初心者の方でも理解できるよう、詳細な解説コメントを添えています。

name: Beautiful Log Demo

手動実行、またはメインブランチへのプッシュで起動します
on:
push:
branches: [ “main” ]
workflow_dispatch:

jobs:
demonstrate-logs:
runs-on: ubuntu-latest
steps:

  • name: Checkout code

uses: actions/checkout@v4

# —————————————————-
# テクニック1: Grouping（ログの折りたたみ）
# —————————————————-

  • name: Grouping Demo

run: |
echo “::group::[準備] 依存関係のセットアップ（ここをクリックで開閉）”
echo “パッケージをインストールしています…”
echo “fetch package-a…”
echo “fetch package-b…”
echo “セットアップが完了しました。”
echo “::endgroup::”

echo “これはグループの外側のログです。常に表示されます。”

# —————————————————-
# テクニック2: ANSI Color（ログの色付け）
# —————————————————-

  • name: ANSI Color Demo

run: |
# プロのこだわりポイント：
# ‘echo -e’ は環境によって挙動が変わる（ポータビリティが低い）ため、
# 常に一貫して動作する ‘printf’ を使用するのがベストプラクティスです。
#
# \033[ はエスケープシーケンスの開始を示します。
# [31m = 赤, [32m = 緑, [33m = 黄, [36m = シアン, [0m = 色の変更をリセット

printf “\033[36m[INFO]\033[0m アプリケーションのビルドを開始します…\n”

printf “\033[32m[SUCCESS]\033[0m ビルドが正常に完了しました！\n”

printf “\033[33m[WARNING]\033[0m 推奨されていない古いAPIが使用されています。\n”

printf “\033[31m[ERROR]\033[0m テストが失敗しました。詳細を確認してください。\n”

# —————————————————-
# 応用編: 実践的な組み合わせ
# —————————————————-

  • name: Advanced Combined Demo

run: |
echo “::group::\033[35m[詳細ログ] データベース移行処理の実行\033[0m”
printf “マイグレーションファイル: 20231024_init.sql を実行中…\n”
printf “テーブル ‘users’ を作成しました。\n”
printf “\033[32m✓ データベースの移行に成功しました。\033[0m\n”
echo “::endgroup::”

【解説】ここで使われている魔法の正体

1. `::group::` と `::endgroup::`

GitHub Actionsのランナーは、標準出力（`echo`や`printf`）に特定のフォーマットで文字列が書き出されると、それを「システムへの命令」として解釈します。これがワークフローコマンドです。

  • `echo “::group::グループ名”` でグループを開始します。
  • `echo “::endgroup::”` でグループを閉じます。

2. `3[32m` などの謎の記号

これはANSIエスケープシーケンスと呼ばれる、端末画面の文字色を制御するための特殊なコードです。

  • `\033[` または `\x1b[`：色を切り替える合図。
  • `31m`：赤色（Red）
  • `32m`：緑色（Green）
  • `33m`：黄色（Yellow）
  • `36m`：シアン（Cyan）
  • `0m`：超重要！ 色を元（デフォルトの白）に戻す合図（リセット）。これを忘れると、それ以降のすべてのログがずーーーっと同じ色になってしまいます。

—

4. 感動の動作確認！ログを見てみよう

ファイルを保存し、GitHubにプッシュ（または手動実行）してみましょう。
GitHubリポジトリの「Actions」タブを開き、実行されたワークフローを選択してください。

そこには、これまでに見たことのないような美しく整理されたログが広がっているはずです！

▼ [準備] 依存関係のセットアップ（ここをクリックで開閉） <-- クリックで開閉できる！ パッケージをインストールしています... fetch package-a... fetch package-b... セットアップが完了しました。 これはグループの外側のログです。常に表示されます。 [INFO] アプリケーションのビルドを開始します... <-- シアン（水色）で表示！ [SUCCESS] ビルドが正常に完了しました！ <-- 鮮やかな緑色で表示！ [WARNING] 推奨されていない古いAPIが使用されています。 <-- 注意を促す黄色で表示！ [ERROR] テストが失敗しました。詳細を確認してください。 <-- 危険を示す赤色で表示！ ▼ [詳細ログ] データベース移行処理の実行 <-- 紫色のタイトルで折りたたまれている！ マイグレーションファイル: 20231024_init.sql を実行中... テーブル 'users' を作成しました。 ✓ データベースの移行に成功しました。 <-- 中身も緑色で分かりやすい！ いかがでしょうか？ どこが重要で、どこが正常に終わったのかが、画面をスクロールした瞬間に網膜に飛び込んできますよね。 ---

5. 現場で震えるほど役立つ、プロの「もう一工夫」

この技術をさらに実務で活かすための、先輩からのワンポイントアドバイスです。

1. `echo -e` ではなく `printf` を使う理由

多くの古い記事では `echo -e “\e[32mSUCCESS\e[0m”` のような書き方が紹介されています。しかし、GitHub Actionsが動作する環境（Ubuntu、macOS、Windows）や、使用するシェル（bash, sh, zsh）によっては、`echo` の `-e` オプションがそのまま「`-e`」という文字として出力されてしまうバグが頻発します。
どんな環境でも100%意図通りに色を出すためには、移植性の高い `printf` を使うのがプロの鉄則です。

2. GitHub公式の「アノテーション」と組み合わせる

GitHub Actionsには、ログを装飾するだけでなく、コミット画面やPR（プルリクエスト）の画面に直接エラーメッセージをピン留めする機能があります。

  • `::error::`：エラーをPRに表示
  • `::warning::`：警告をPRに表示

printf “::error file=app.js,line=10::構文エラーが発生しました。\n”

これを使うと、ログ画面を開く気にさえならなくても、GitHubのファイル差分画面（Files changed）に直接赤いエラーマークが表示されるようになります。今回のカラー出力と組み合わせることで、デバッグ速度はさらに数倍跳ね上がります。

—

まとめ：ログは未来の自分とチームへの「思いやり」

CI/CDパイプラインは、一度作ってしまえば「動いて当たり前」のものになりがちです。しかし、本当に価値を発揮するのは「壊れたとき」です。

壊れたときに、
「うわ、またログの山から原因探しツールを動かさなきゃいけないのか……」
とため息をつくか、
「よし、赤色のエラー部分とグループ化された詳細ログを見て、3秒で原因がわかった！」
と笑顔になるか。

この小さな差が、毎日の開発の楽しさと、リリーススピードを大きく変えていきます。
今回学んだ「Grouping」と「ANSI Color」を、ぜひあなたのプロジェクトの `yml` ファイルにも忍ばせてみてください。チームのメンバーが「おっ、これ見やすいね！」と驚く顔が楽しみですね。

何か分からないことがあれば、いつでも聞いてくださいね。あなたのCI/CDライフがもっと快適になることを応援しています！

スポンサーリンク
タイトルとURLをコピーしました