こんにちは！開発現場で日々コードと向き合っていると、「おっ、このオープンソースのライブラリ、自分のプロジェクトでも使いたいな」と思う瞬間がありますよね。
でも、Windows環境でC/C++のライブラリを導入しようとした途端、「依存関係の地獄（DLL Hell）」や「謎のエラーメッセージの連続」に直面して、丸一日溶かしてしまった……なんて苦い経験はありませんか？
特にWindowsでネイティブな開発をする際、多くの人が頼るのがMSYS2です。Linuxのパッケージマネージャー（`apt`や`pacman`のようなもの）がWindows上で動くため、数千ものオープンソースライブラリをコマンド一つでインストールできます。
しかし、開発を進めていくと、こんな壁にぶぶつかります。
「使いたいライブラリのバージョンが公式リポジトリにない！」
「特定のパッチを当てたり、最適化フラグを変更してビルドし直したい！」
ここで適当にソースコードをクローンしてきて、手動で `cmake` や `make` を叩いてしまうと……あら不思議、MSYS2の綺麗なパッケージ管理システムがぐちゃぐちゃに汚され、数ヶ月後の環境移行時に泣きを見る羽目になります。
今回は、MSYS2の公式パッケージリポジトリの恩恵を最大限に受けつつ、どうしても足りないライブラリを「美しく、環境を汚さずに自前ビルドする（makepkg）」ための実践的なノウハウを、優しく丁寧に解説していきます。
これをマスターすれば、Windows環境でのC/C++ライブラリ管理に怯えることはもうなくなりますよ。一緒に見ていきましょう！
—
1. なぜMSYS2なのか？ ツールが果たす役割の本質
そもそも、なぜWindowsで素直にVisual Studio（MSVC）を使わず、MSYS2を使うのでしょうか？
それは、世の中にある多くの優れたオープンソースソフトウェア（OSS）が、もともとLinuxやUnixの環境（GCCやAutotools、Make、Bashなど）を前提として書かれているからです。MSYS2は、Windows上でPOSIX互換レイヤーと強力なパッケージ管理システム（`pacman`）を提供し、「Linux向けに書かれたソースコードを、最小限の修正でWindowsネイティブ（MinGW-w64）向けにコンパイル・実行できる環境」を作ってくれます。
MSYS2の心臓部：3つのシェル環境の使い分け
MSYS2をインストールすると、スタートメニューにいくつかアイコンが並びます。初心者が一番最初に迷うポイントがここです。現場では以下の原則を覚えておいてください。
- MSYS2 MSYS: システム管理やパッケージのビルド（後述する `makepkg`）を行うための環境。Windowsから見ると仮想的なLinux空間です。
- MSYS2 MINGW64: ここが本丸です。ここでコンパイルされたバイナリは、MSYS2の仮想空間に依存せず、純粋なWindowsのネイティブアプリ（64bit）として動作します。普段の開発やビルドは主にここを使います。
—
2. 基礎セットアップ：環境の初期化とコンパイラの導入
まずは、汚れていないクリーンなMSYS2環境を整えましょう。
公式サイトからインストーラーを落としてインストールしたら、「MSYS2 MINGW64」のショートカットではなく、「MSYS2 MSYS」を最初に起動してください（ここ重要です！）。
ステップ1：パッケージデータベースとコアシステムの更新
起動したら、まずはパッケージマネージャー（`pacman`）自体のアップデートを行います。以下のコマンドを叩いてください。
-S は Sync（パッケージの同期・インストール）、u は Upgrade（更新）を意味します
pacman -Syu
途中で「コアシステムを更新したので、一度ウィンドウを閉じろ」という旨のメッセージが出たら、言われた通りに一度ターミナルウィンドウを閉じ、再度「MSYS2 MSYS」を立ち上げて同じコマンド（`pacman -Syu`）をもう一度実行します。これで基盤が最新化されます。
ステップ2：開発ツールの基本セットアップ
次に、C/C++のコンパイラやビルドツール群をまとめてインストールします。MINGW64環境用のツールチェーンを一撃で導入しましょう。
MINGW-w64のGCCツールチェーン、Make、CMake、Gitなどを一括インストール
pacman -S –needed base-devel mingw-w64-x86_64-toolchain mingw-w64-x86_64-cmake
※ `–needed` オプションをつけておくと、すでにインストールされている最新のツールはスキップしてくれるので安全です。
—
3. 動作確認：すべてが正しく噛み合っているかテストする
環境が整ったところで、正しくコンパイルと実行ができるか、簡単なC++のプログラム（お馴染みのHelloWorld）で動作確認をしましょう。
ここからは、純粋なWindowsネイティブアプリを作るために、「MSYS2 MINGW64」のショートカットからターミナルを起動してください。
作業用のディレクトリを作って、ソースコードを書きます。
作業用フォルダを作成して移動
mkdir -p ~/projects/hello_test
cd ~/projects/hello_test
ヒアドキュメントを使って、簡単な main.cpp を作成
cat << 'EOF' > main.cpp
include
include
int main() {
std::vector
“こんにちは、MSYS2の世界へようこそ！”,
“ビルド環境は完璧に動作しています。”
};
for (const auto& msg : messages) {
std::cout << msg << std::endl;
}
return 0;
}
EOF
作成したソースコードを、インストールしたGCC（`g++`）でコンパイルします。
g++ でコンパイル実行 (-std=c++17 を指定し、生成されるexeの名前を hello.exe にする)
g++ -std=c++17 main.cpp -o hello.exe
実行してみる
./hello.exe
コンソールに日本語のメッセージが綺麗に出力されたでしょうか？
これで、あなたのPCには世界最高峰の軽量C++開発環境が構築されました。
---
4. 現場の知見：公式リポジトリにないライブラリを「makepkg」で美しく料理する
さて、ここからが本記事の核心です。
開発を進めていると、「どうしても `libfoo` というマイナーなライブラリが必要になった。でも `pacman -S mingw-w64-x86_64-libfoo` と打っても『そんなパッケージねえよ』と言われる……」という事態に必ず直面します。
ここでやってはいけないアンチパターン：
- GitHubからソースコードを落としてきて、手動で `cmake .. && make && make install` を実行する。
- これを行うと、「どのファイルがどこにインストールされたか」をMSYS2が把握できなくなるため、後でアンインストールしたくなったり、バージョンを上げたりするときに環境が破壊されます。
救世主 `makepkg-mingw` の登場
MSYS2には、Arch Linuxの血を受け継ぐ`makepkg`という最強のビルド自動化ツールがあります。これを使うと、「ソースコードの取得から、パッチ当て、コンパイル、そして綺麗なパッケージ（.pkg.tar.zst）の作成」までを自動化し、`pacman`管理下に置くことができます。
ここでは例として、公式リポジトリにはない（あるいは最新版に追従したい）仮のライブラリを想定し、MSYS2公式が提供しているビルドレシピ集（`MINGW-packages`）の仕組みを使ったスマートなビルド手順を解説します。
手順1：公式のビルドレシピ（PKGBUILD）を取得する
MSYS2プロジェクトは、数千に及ぶパッケージの「レシピ（PKGBUILDファイル）」をGitHubで公開しています。まずはこれを参考にするのが最も安全です。
今回は、MSYS2上でビルドスクリプトを実行するための環境である「MSYS2 MSYS」のシェルを開き、作業用ディレクトリにPKGBUILDのテンプレート（あるいは既存のレシピ）を用意します。
作業用ディレクトリへ移動
cd ~
mkdir -p custom_builds && cd custom_builds
例として、公式のMINGW-packagesリポジトリから特定のライブラリのレシピをクローン（または自作）する
※ここでは自作のPKGBUILDを書くケースを想定して進めます
手順2：魔法の設計図「PKGBUILD」を書く
`makepkg` の頭脳となるのが `PKGBUILD` というファイルです。ここに、ソースのありか、依存関係、ビルド手順を記述します。
試しに、簡単なC++ライブラリをビルドするための `PKGBUILD` の骨組みを見てみましょう。
PKGBUILD ファイルを作成
cat << 'EOF' > PKGBUILD
Maintainer: あなたの名前
どのMinGW-w64ツールチェーン用かを示すプレフィックス
_realname=example-lib
pkgname=mingw-w64-x86_64-$_realname
pkgver=1.0.0
pkgrel=1
pkgdesc=”環境を汚さない自前ビルドのサンプルライブラリ”
arch=(‘any’)
license=(‘MIT’)
依存するパッケージ（ビルド時および実行時）
depends=(‘mingw-w64-x86_64-gcc’)
makedepends=(‘mingw-w64-x86_64-cmake’)
options=(‘staticlibs’ ‘strip’)
ソースコードの取得先（GitHubのリリースtarballなど）
source=(“https://github.com/example/example-lib/archive/refs/tags/v${pkgver}.tar.gz”)
sha256sums=(‘SKIP’) # セキュリティハッシュ（実際は正しいSHA256を入れる）
ビルドディレクトリの準備
prepare() {
cd “$_realname-$pkgver”
mkdir -p build
}
コンパイル・ビルドのプロセス
build() {
cd “$_realname-$pkgver/build”
# MinGW環境用の環境変数（CC, CXX, CMAKE_PREFIX_PATHなど）が自動適用される
# MSYS2が提供する mingw32/mingw64 用の CMake ラッパーを使用するのがコツ
../mingw-w64-cmake.sh .. \
-DCMAKE_BUILD_TYPE=Release
make
}
インストール（パッケージングのステージへ出力）
package() {
cd “$_realname-$pkgver/build”
make DESTDIR=”$pkgdir” install
}
EOF
手順3：ビルドの実行（パッケージの生成）
レシピができたら、あとは `makepkg` に魔法をかけてもらうだけです。必ず「MSYS2 MSYS」環境で以下のコマンドを実行します。
MINGW64用のパッケージとしてビルドを実行するフラグを指定
MINGW_INSTALL_JSM=x86_64 makepkg-mingw -s
- `-s` （`–syncdeps`）：PKGBUILDに書かれている `makedepends`（ビルドに必要な依存パッケージ）が足りていなければ、自動で `pacman`経由でインストールしてくれます。
ビルドが成功すると、同じディレクトリに `mingw-w64-x86_64-example-lib-1.0.0-1-any.pkg.tar.zst` という見慣れない拡張子のファイルが生成されます。これが、MSYS2の誇る「美しくパッケージングされた成果物」です。
手順4：pacman 管理下にインストールする
生成されたパッケージを、システムの `pacman` データベースに登録します。これにより、OSは「このファイル群はどのパッケージによって管理されているか」を完全に把握できるようになります。
ローカルに生成されたパッケージを pacman でインストール
pacman -U mingw-w64-x86_64-example-lib-1.0.0-1-any.pkg.tar.zst
おめでとうございます！これで、手動でファイルをコピー散らかすことなく、公式リポジトリと同じクリーンな管理体制で自前ビルドのライブラリをシステムに組み込むことができました。
万が一、そのライブラリが不要になったり、バージョンを下げたくなったりしたときは、いつでも以下のコマンド一発で綺麗にクリーンアップできます。
環境を汚さず、完璧にアンインストールできる
pacman -R mingw-w64-x86_64-example-lib
—
まとめ：管理ポリシーを持つことで、開発は劇的に楽になる
今回は、MSYS2における公式リポジトリとカスタムビルド（`makepkg`）の使い分けについて、現場のアーキテクチャ視点から深く解説しました。
1. 基本は公式の `pacman` で賄う（無駄な苦労をしない）
2. どうしても必要なものは手動ビルドせず、`makepkg` で「パッケージ化」する
3. パッケージ管理下に置くことで、環境の破壊やDLL Hellを完全に防ぐ
このポリシーをチームや自分自身に課すだけで、Windows環境特有の「あれ、昨日まで動いてたビルドが動かなくなったぞ？」という不毛なトラブルから解放されます。
これをマスターしたあなたなら、もうどんなマイナーなC/C++ライブラリがプロジェクトに要求されても怖くないはずです。
明日からのコーディング、そして環境構築が劇的に快適になりますように。最高の開発ライフを楽しみましょう！