テストを自分のPCで終わらせない。GitHub ActionsでCIを置く最初の一歩と、skipされたジョブの扱い

📌 あわせて読みたい: そもそもテストで何を決めるのかはテストは何のために書くのか。AIが書いたコードほど「期待値」を先に決めるへ。この記事はその次、書いたテストを自分のPCではなくGitHub上で動かし、プルリクエストで結果を見るところだけを扱います(テストの書き方そのものは扱いません)。

テストをGitHub上で動かす仕組みがCI(継続的インテグレーション)です。この記事は、GitHub公式ドキュメントの説明にそって、CIとは何を指すのか、GitHub Actionsでどこまでが自動になるのか、マージ前の必須チェックはどう扱われるのかを順に整理します。

結論:CIは「コミットのたびにビルド・テストする」実践のこと

• GitHubはCIを、共有リポジトリへ頻繁にコードをコミットすることを求めるソフトウェアの実践として説明しています。
• GitHub Actionsでは、イベントをきっかけにワークフローが動き、各テストの結果がプルリクエストに出ます。
• 保護ブランチでstatus checksをrequiredにした場合、そのチェックはプルリクエストをマージする前に通過する必要があります。
• ただし、skipされたジョブは「Success」として報告され、required checkであってもマージを妨げません。

CIとローカルのテストの位置づけ

GitHubは、CIを「頻繁に共有リポジトリへコミットする実践」と説明し、そのテストに含められるものとして、スタイルの書式を確認するコードリンター、セキュリティチェック、コードカバレッジ、機能テスト、その他のカスタムチェックを挙げています。

ローカルで実行するテストと内容が同じであっても、実行される場所と、結果が誰から見えるかが変わります。CIでは、結果がプルリクエスト上に出ます。

ステップ1:何をきっかけに動かすかを決める

GitHub ActionsのCIワークフローは、GitHubでイベントが発生したとき(たとえばリポジトリへ新しいコードがプッシュされたとき)、決まったスケジュール、またはrepository dispatch webhookを使って外部のイベントが発生したときに実行するよう設定できます。

「プッシュのたび」なのか「毎晩」なのかで、結果が返ってくるタイミングが変わります。最初に決めるのはここです。

ステップ2:ビルドとテストの結果をプルリクエストで読む

GitHubは、CIテストを実行し、各テストの結果をプルリクエストで提供すると案内しています。ブランチの変更がエラーを持ち込んでいないかを、プルリクエストの画面上で確認できる形です。

ここまでは「結果が見える」段階で、マージできるかどうかの制御はまだ入っていません。

ステップ3:required status checksでマージ前の条件にする

GitHubは、保護ブランチでstatus checksがrequiredに設定されている場合、プルリクエストをマージする前にそれらが通過している必要があると説明しています。ここで初めて、チェックの結果がマージの条件になります。

skipされたジョブは「Success」として報告されます

GitHubは、skipされたジョブはそのステータスを「Success」として報告し、required checkであってもプルリクエストのマージを妨げないと明記しています。

そのため、条件付きでジョブを実行している場合は、そのジョブが実際に走ったのかを、必須チェックの設定と合わせて確認する必要があります。

整理:置く順番

この5行の順序は、公式の機能を初めて触る人向けに並べた本記事の整理です。すべてのリポジトリに同じ設定を勧めるものではありません。

🔗 次に読む

• AIに書かせたコードを受け取った直後の確認点はAIに実装を任せた後、「動いた」以外に確認する4つのことへ。
• GitとGitHubの役割分担から確認したい方はGitとGitHubは何が違う?へ。
• 全体像は生成AIの業務活用 完全ガイド(2026年版)へ。

※本記事は2026年7月24日に確認したGitHub公式ドキュメント(継続的インテグレーション、status checks)の説明に基づく整理です。CIやrequired checkを置くことで不具合や誤ったマージがなくなることを示すものではありません。実際の設定は公式ドキュメントでご確認ください。