こんにちは、てつです！
前回の第2回記事「GitHub Actionsを自宅で動かす！Self-hosted Runner構築ガイド」では、自宅サーバーにSelf-hosted Runner（セルフホステッド・ランナー：GitHubからの命令を自宅サーバー内で受け取って実行する仕組み）を導入し、クラウドと自宅の拠点を安全に繋ぐ土台を完成させました。
「これで自宅サーバーを自動化する準備はバッチリだ！」とワクワクしている方も多いのではないでしょうか。
しかし、いざ自動化を進めるにあたって、避けて通れない「巨大な壁」があります。それが設定ファイルの書き間違い（構文エラー）です。
今回は、プロの現場では絶対に欠かせない「ミスを仕組みで防ぐ防衛網」を自宅サーバーに構築していきましょう！
１．なぜ自宅サーバーの自動化に「CI（自動チェック）」が必要なのか？
「よし、自宅サーバーの設定を変えよう！」と、docker-compose.yml などの設定ファイルを書き換えてサーバーに反映させた際、画面にエラーが吐き出されてサーバーが起動しなくなった経験はありませんか？
「原因を調べてみたら、インデント（文字の前のスペース）が1マスずれていただけだった……」なんていうのは、インフラエンジニアの“あるある”です。
YAML（ヤムル：docker-compose.ymlなどの設定ファイルを読みやすく書くためのデータ形式）というフォーマットは、スペースの数が意味を持つため、タイポ（打ち間違い）に対して非常にデリケートです。
手動でのチェックには限界があります。
特に、深夜の作業や、仕事終わりの限られた時間での作業では、人間の注意力はどうしても落ちてしまいます。
プロは「人間の注意力」を信用しない
プロのインフラエンジニアの現場では、「人間は必ずミスをする」という前提でシステムを組みます。どれだけ熟練したエンジニアであっても、「気をつけます」という精神論でミスを防ぐことはしません。
そこで登場するのが、今回のテーマである CI（Continuous Integration：継続的インテグレーション） です。
簡単に言うと、「コードを修正してGitHubにアップロード（push）した瞬間に、ロボットが自動で文法チェックをしてくれる仕組み」のこと。
[Image: コードをPush ➔ ロボットが構文チェック ➔ OKなら緑、ダメなら赤で通知するパイプラインのイメージ]
この「自動チェックというガードレール」を1本敷くだけで、お粗末な構文ミスのせいで自宅サーバーが突然止まるリスクを物理的にゼロにできます。
趣味のホームラボとはいえ、やってることは「プロの開発現場と全く同じ仕様」です。最高にワクワクしてきませんか？
２．自宅サーバー×GitHub Actionsの環境構成と前提条件
この記事を進めるにあたって、必要な環境を整理します。
- 前提条件（前回の振り返り）：
- 第2回の「Self-hosted Runner構築ガイド」を完了しており、GitHub Actionsが自宅サーバー上で動かせる状態になっていること。
- 自宅サーバーのOSがLinux（Ubuntuなど）で、Docker環境があること。
- 今回導入するツール：
- Yamllint（ヤムル・リント）：YAMLファイルの文字のズレや、不要なスペース、書き方のルール違反を瞬時に見つけ出す「校正ロボット」のようなツールです。
３．ステップ解説：YAMLの自動構文チェック（CI）環境を作ろう
手順はシンプルに3つのステップです。黒い画面（コマンドライン）での作業は最小限ですので、ステップ・バイ・ステップで進めていきましょう。
作業1：GitHubリポジトリにワークフローファイル（指示書）を作成
GitHub Actionsを動かすためには、リポジトリの中に「こういう順番で自動化してね」という指示書（ワークフローファイル）を置いておく必要があります。
まずは、ご自身のPCの作業ディレクトリ（またはGitHubのウェブ画面）で、以下の通りフォルダとファイルを作成してください。
- プロジェクトの1番上の階層（ルートディレクトリ）に、
.githubというフォルダを作ります。 - その中に、さらに
workflowsというフォルダを作ります。 - 最後に、その中に
yaml-check.ymlという名前のファイルを作成します。
全体の配置イメージはこうなります： （あなたのプロジェクト）/.github/workflows/yaml-check.yml
作業2：自動構文チェックを実行するYAMLコードの記述と解説
作成した yaml-check.yml に、以下のコードをそのまま貼り付けて保存してください。
プログラミングやインフラの学習中の方に向けて、1行ずつ何をしているのか解説を入れました。変数や設定の意味をセットで掴んでみてください。
# 1行目：この自動化処理（ワークフロー）の名前です。GitHubの画面に表示されます。
---
name: YAML Syntax Check
# 3行目：どういう「タイミング（イベント）」でこの自動化を起動するかを設定します。
"on":
# 5行目：リポジトリにコードが「push（変更のアップロード）」されたときをトリガーにします。
push:
# 7行目：対象とするブランチ（デフォルトのメインブランチ）を指定しています。
branches: ["main"]
# 9行目：具体的に実行する処理（ジョブ）の中身をここにまとめて書いていきます。
jobs:
# 11行目：今回行う「構文チェック（lint）」というタスクに名前をつけています。
lint:
# 13行目：重要！前回構築した、自宅サーバー内の「Self-hosted Runner」の上で処理を動かす指定です。
runs-on: self-hosted
# 15行目：実行する具体的なステップ（手順）を上から順番に並べます。
steps:
# 17行目：GitHub上にあるあなたの最新コードを、自宅サーバー内の実行環境にコピー（チェックアウト）します。
- name: Checkout code
uses: actions/checkout@v4
# 20行目：YAMLファイルの書き方を厳しくチェックするツールを実行します。
- name: Run YAML Lint
# 世界中のエンジニアが使っている高品質なチェック用テンプレート（ibiqlik/action-yamllint）を呼び出しています。
uses: ibiqlik/action-yamllint@v3
with:
# チェックの対象として、リポジトリ内にあるすべてのyaml / ymlファイルを指定（. はすべてという意味）しています。
file_or_dir: '.'
作業3：あえてミスを発生させて自動チェックの動作確認
仕組みができたら、本当にロボットが機能しているか「テスト」をしてみましょう。インフラの世界では、「あえて失敗させてみて、想定通りにエラーを検知できるか」を確認するまでがセットです。
１．テストとして、リポジトリ内にある適当なYAMLファイル（docker-compose.yml など）のインデントをあえて1マスだけずらして保存します。
２．コマンドで、いつも通りGitHubへ変更を送信します。
git add .
git commit -m "test: add intentional error"
git push origin main３．GitHubのブラウザ画面を開き、「Actions」タブをクリックしてください。
上の画像のように、ワークフローが赤色（Fail：失敗）で停止していれば大成功です！ エラーの詳細を開くと、「○行目のスペースの数がおかしいよ」とロボットが英語で的確に指摘してくれているはずです。
確認できたら、ファイルのインデントを正しい状態に戻し、再度 git push してみましょう。今度は緑色のチェックマーク（Success：成功）に変わるはずです。
この瞬間、あなたの自宅サーバー環境に最強の「盾」が備わりました！
４．現役インフラエンジニアが解説する「プロ仕様」の設計思想
今回構築した環境は、企業の数百万〜数千万円規模の本番システムで採用されている構成と、本質的には全く同じです。
実務における最大のメリットは、「不完全な設定ファイルが本番環境（自宅サバ）に適用されるのを物理的にブロックできる」という点にあります。
もしこのCI（自動チェック）を挟まずに、直接サーバー上でファイルを書き換えていたら、修正が終わるまでコンテナが落ち続け、サービスが停止してしまいます。
また、前回の「Self-hosted Runner」を引き継いで使っているため、コードの検証はすべて「自宅サーバーの内部」で完結します。
クラウド側のマシンパワーを消費しないため、GitHub Actionsの無料枠（実行時間制限）を一切気にせず、24時間いつでも、何回でもプッシュしてテストできるのもホームラボならではの特権であり、プロ仕様の設計思想です。
５．トラブルシューティング：よくある詰まりポイントとエラー対処法
補足①：GitHub側で処理が「Waiting（待機中）」のまま動かない場合
エラーメッセージのどこに注目すべきか：GitHub Actions画面のステータスランプ（黄色いグルグルがずっと回っている）
原因と解決策：前回設定した自宅サーバー側の「Runnerサービス」が眠っている（停止している）可能性が高いです。自宅サーバーにログインし、次のコマンドで生存確認をしてください。
sudo systemctl status actions-runner.serviceもし inactive (dead) と表示されていたら、 sudo systemctl start actions-runner.service で起こしてあげましょう。
補足②：yamllintのチェックが厳しすぎてエラーになる場合
エラーメッセージのどこに注目すべきか：ログ内の [error] line length...（1行が長すぎる）や [error] trailing spaces（行の最後に無駄なスペースがある）
原因と解決策：このチェックツールはデフォルトだとかなり「潔癖症」です。実用的なバランスにするために、ルールを少し緩めてあげましょう。 プロジェクトの一番上の階層に .yamllint という名前のファイルを作り、以下の設定を書き込むことで、1行の長さ制限などを無視させることができます。
extends: default
rules:
line-length: disable
document-start: disable６．まとめと次回予告：次はSSHログインからの卒業（GitOps編）
お疲れ様でした！ これで設定ファイルの「構文ミス」を全自動で検知する、自宅DevOpsの強力なCI環境が完成しました。もう、タイポひとつでサーバーを壊す恐怖に怯える必要はありません。
安全な「盾」を手に入れたら、次に欲しくなるのは「圧倒的な楽（スピード）」ですよね。
次回・第4回は、「git pushで即反映！自宅サバをGitOps（ギットオプス）化してSSHログインを卒業する方法」をお届けします。
もう、設定を変えるたびに毎回黒い画面（SSH）でサーバーにログインし、手動で docker compose restart を叩く面倒な運用からは卒業です。コードをプッシュした瞬間に、自宅のコンテナがシュッと最新化される快感を、ぜひ一緒に体験しましょう！
「手元の環境で動いた！」「こんなエラーで詰まった」などがあれば、ぜひコメントや note の「スキ」で教えてもらえると励みになります！
また、今回の連載で構築する「自宅自動化環境」のより高度なエラーハンドリング集や、ワンクリックで環境を爆速構築できる「自動化シェルスクリプトの完成版テンプレート」は、将来的にnoteにて販売も予定しています。
気になる方は今のうちにブログのブックマークとnoteのフォローをお願いします！
それでは、また次回の記事でお会いしましょう！
コメント