こんにちは！開発環境アーキテクトの先輩です。
C言語での開発、進んでいますか？
「自分の手元のPC（ローカル環境）ではビルドが成功するのに、別の人のPCや本番サーバーでコンパイルエラーになる……」
C言語を書き始めたばかりの頃、誰もが一度はこの不可解な現象に頭を抱えたことがあるはずです。コンパイラのバージョン違いや、OS特有のヘッダーファイルの差異が原因ですね。
これを綺麗に解決してくれるのが、CI/CD（継続的インテグレーション／継続的デリバリー）という仕組みです。
今回は、世界中の開発者が使っている「GitHub Actions」という強力な自動化ツールを使い、コードをプッシュするだけで、GCCとClangという主要な2大コンパイラで自動ビルドとテストを走らせる方法を、一緒に一歩ずつ紐解いていきましょう。
これをマスターすれば、あなたの書いたC言語コードは常に「どの環境でも正しく動く」というお墨付きをもらった状態になり、毎日のコーディングが劇的に楽になりますよ。
—
1. なぜC言語プロジェクトにGitHub Actionsが必要なのか？
C言語は、ハードウェアの近くで動く非常にパワフルな言語である反面、「プラットフォーム依存性」が高い言語です。
例えば、LinuxのGCCで書いたコードが、macOSのClang（LLVM）では警告やエラーが出ることは日常茶飯事です。
ローカル環境だけでテストしていると、うっかりOS依存のコードを書いてしまい、後から大慌てで修正する羽目になります。
そこで、GitHub Actionsの出番です。GitHubのクラウドサーバー上で、「プッシュした瞬間に、LinuxやmacOS、さらには異なるコンパイラを使って、自動でビルドとテストを回してくれる仕組み」を作ります。
人間の手で毎回確認するのではなく、機械に「おかしなところがないか？」を監視してもらう。これが、モダンでプロフェッショナルな開発の第一歩です。
—
2. プロジェクトのディレクトリ構造を整えよう
まずは、自動化の土台となるプロジェクトのフォルダ構造を決めましょう。
今回は、非常にシンプルかつスケーラブルな構成を採用します。
my_c_project/
├── .github/
│ └── workflows/
│ └── ci.yml # GitHub Actionsの設定ファイル
├── src/
│ └── main.c # 今回の主役：精度の高いHello World
├── include/
│ └── greet.h # ヘッダーファイル
└── Makefile # ビルド自動化のレシピ
この「ソースコード」「ヘッダー」「ビルド手順（Makefile）」という分離が、C言語プロジェクトを美しく保つ秘訣です。
—
3. 動作確認用の「HelloWorld」を書く
ただ文字を表示するだけのHelloWorldではなく、ヘッダーファイルを分け、コンパイルの仕組みをきちんとテストできる「少しだけ実用的な」コードを用意しましょう。
ヘッダーファイル：`include/greet.h`
ifndef GREET_H
define GREET_H
// 挨拶のメッセージを表示する関数の宣言
void print_greeting(const char name);
endif
ソースコード：`src/main.c`
include
include “greet.h”
// 挨拶メッセージを出力する関数の実体
void print_greeting(const char name) {
printf(“こんにちは、%sさん！GitHub Actionsからの自動ビルド成功です。\n”, name);
}
int main(void) {
// 動作確認用に関数を呼び出す
print_greeting(“開発者”);
return 0; // 正常終了
}
ビルドの自動化ツール：`Makefile`
コンパイル時のコマンドを毎回手で打つのは大変なので、`make`コマンドで一発ビルドできるようにします。ここがポイントで、後ほどGitHub Actions側からコンパイラを指定できるように変数化（`CC`）しておきます。
コンパイラを変数化（外部からGCCやClangに差し替え可能にする）
CC ?= gcc
CFLAGS = -Wall -Wextra -Iinclude
ターゲット（生成物）の名前
TARGET = app
ソースファイル
SRC = src/main.c
all: $(TARGET)
$(TARGET): $(SRC)
# 指定されたコンパイラとフラグでビルドを実行
$(CC) $(CFLAGS) $(SRC) -o $(TARGET)
clean:
# 生成されたバイナリを削除するクリーンアップ
rm -f $(TARGET)
test: all
# ビルドが成功したら実際に実行して動作確認
./$(TARGET)
ローカル環境（LinuxやmacOS）でターミナルを開き、以下のコマンドを打ってみてください。
make test
これで「こんにちは、開発者さん！…」と表示されれば、ローカルでの準備は完璧です。
—
4. 核心：マルチコンパイラ対応GitHub Actionsワークフローの構築
いよいよ本丸です。`.github/workflows/ci.yml` というファイルを作成し、以下のコードを記述してください。
この設定ファイルこそが、GitHubのサーバー上であなた専属の優秀なレビューアーを動かす呪文になります。
設定ファイル：`.github/workflows/ci.yml`
ワークフローの名前（GitHub上のActionsタブに表示されます）
name: C Project CI/CD
どのタイミングでこのワークフローを動かすか
on:
push:
branches: [ “main”, “master” ] # mainまたはmasterブランチにプッシュされた時
pull_request:
branches: [ “main”, “master” ] # プルリクエストが作成・更新された時
jobs:
build-and-test:
# 実行する仮想マシンのOS（今回は最新のUbuntu環境を指定）
runs-on: ubuntu-latest
# マトリクスビルド：複数のコンパイラで同時にテストを行うための魔法の設定
strategy:
matrix:
compiler: [gcc, clang]
steps:
# 1. GitHubのリポジトリからコードを仮想マシンにチェックアウトする
- name: Checkout repository
uses: actions/checkout@v4
# 2. 指定したコンパイラ（gcc または clang）をインストールする
- name: Install Compiler
run: |
sudo apt-get update
if [ “${{ matrix.compiler }}” = “clang” ]; then
sudo apt-get install -y clang
else
sudo apt-get install -y gcc
fi
# 3. コンパイルとテストの実行（Makefileにコンパイラを渡す）
- name: Build and Test
run: |
# マトリクスで選択されたコンパイラをCC変数に代入してmakeを実行
make CC=${{ matrix.compiler }} test
この設定の何が凄いのか？（アーキテクトの解説）
1. `strategy.matrix` によるマルチコンパイラ検証
この数行を書くだけで、GitHubは「GCCでビルドするジョブ」と「Clangでビルドするジョブ」の2つを同時に（並列で）自動実行してくれます。どちらか片方でもエラーが出れば、そのプルリクエストは赤信号（ビルド失敗）になり、バグの混入を未然に防げます。
2. `CC=${{ matrix.compiler }}` による柔軟性
Makefile側でコンパイラを固定せず、外部から上書きできるように設計していたため、たったこれだけの記述でコンパイラを切り替えてテストが成立します。
—
5. 自動化の恩恵を体感しよう！
ここまで準備できたら、ファイルをすべてGitでコミットし、GitHubのリポジトリにプッシュしてみましょう。
git add .
git commit -m “feat: GitHub ActionsによるマルチコンパイラCIの導入”
git push origin main
ブラウザでご自身のGitHubリポジトリを開き、「Actions」タブをクリックしてみてください。
そこには、あなたが書いたコードが、GCC環境とClang環境の両方でモリモリと自動ビルドされ、テストをパスしていく様子がリアルタイムで表示されています。
緑色のチェックマーク（`✓`）が並んだ瞬間、心地よい達成感に包まれるはずです。
—
おわりに
お疲れ様でした！
今回構築したCI環境は、今後あなたがどれだけコードを書き進め、ファイルが増えていっても、常に後ろから「今のコード、バグってない？」と見守り続けてくれる頼もしい相棒になります。
「コードを書く ⇒ プッシュする ⇒ 自動で安心を買う」
このサイクルを一度知ってしまうと、もう手動での確認には戻れなくなるはずです。ぜひ、あなたのC言語プロジェクトにも導入して、快適な開発ライフを満喫してくださいね！