GitHub ActionsのmacOS OpenSSL 4変更前に何を確認する？2026年チェックリスト

opensslのバージョンを指定していないのに、macOS CIの実行結果が変わる可能性があります。
まずPATH経由の呼び出しを洗い出し、証明書・署名・TLSと依存ライブラリの代表的な処理を検証してください。

macOS CIのイメージとツールチェーンを管理するIT・プラットフォーム担当者は、影響範囲と変更の適用時期を先に確認してください。
証明書や署名のスクリプトを保守する方は、OpenSSLの既定値への依存を重点的に調べます。ネイティブライブラリをビルドするチームは、代表的なジョブで互換性と切り戻し手順を確認してください。

最終確認：2026年10月23日。GitHubの変更告知とrunner-imagesの更新情報を確認し、実際のチーム環境でもログと成果物を照合してください。告知には予定が変更される可能性も記載されています。(GitHubのOpenSSL既定バージョン変更告知)

変更対象はmacOS 26とXcode 27の一部runnerです

GitHubの告知では、2026年11月2日から8日にかけて、macOS 26のIntel・Arm64 runnerとXcode 27のArm64 runnerで、バージョンを指定しないopensslの既定をOpenSSL 4へ順次切り替える予定です。これは告知時点での計画であり、変更がすでに完了したという意味ではありません。予定日は互換性検証によって変わる可能性があります。(変更予定と対象イメージの告知)

この対象範囲を、すべてのmacOS runnerやLinux・Windows runnerへ広げて考えないでください。ジョブで指定しているrunnerラベルだけで実際のツール状態を決めつけず、該当イメージのソフトウェア一覧と実行ログを併せて確認します。(GitHub-hosted runnerの参照情報、runnerイメージのソフトウェア一覧の確認方法)

確認対象の差分は、まず次のように整理できます。

• 告知の対象に該当するジョブ：macOS 26のIntel・Arm64、またはXcode 27のArm64 runnerを利用しているかを確認します。
• 対象外のrunnerを使うジョブ：今回の告知だけを根拠に、一斉変更が必要だと判断しないでください。
• 利用イメージや実際のPATHが不明なジョブ：タグ名から推測せず、ジョブログでopensslの実行パスとバージョンを記録します。

PATH経由でのopenssl呼び出しを先に探します

GitHub ActionsのmacOS runnerがいつOpenSSL 4を既定にするかを把握したら、次はワークフローが実際にそのコマンドへ依存しているかを調べます。YAMLだけを見て終わらせず、呼び出し元のシェル、ビルドスクリプト、再利用するactionや社内スクリプトも対象にしてください。

ソース管理下のファイルを検索し、opensslの呼び出しごとに「バージョンを明示しているか」「PATH上の既定値を使うか」「結果をどこで消費するか」を記録します。ジョブに診断用の出力を加える場合は、実行ファイルの場所とopenssl versionの出力をログに残し、対象のrunnerイメージと一緒に保存します。GitHub Actionsでは、必要に応じてワークフローコマンドでPATHを設定できますが、設定後のジョブで選択された実行ファイルも確認してください。(PATHを追加するワークフローコマンド)

検索結果は、たとえば次の観点で分類すると、修正対象を決めやすくなります。

• バージョンを明示した呼び出し。指定した実行ファイルが、想定したジョブで実際に選択されているかを確認します。
• バージョンを指定しない呼び出し。既定バージョンの変更で影響を受ける可能性があるため、まず検証対象にします。
• 別スクリプトやactionを経由する呼び出し。呼び出し元だけで判断せず、実行ログや処理内容まで追います。

OpenSSL 3の前提が残るコマンドをどう固定するか

OpenSSL 3が必要なmacOS CIでは、既定値に任せず、対象バージョンを明示できるようにします。GitHubの告知ではOpenSSL 3も利用可能とされていますが、チームのジョブで使うパスやインストール状態は、実行環境で確認が必要です。Homebrewのopenssl@3情報と対象runnerのログを照らし合わせ、バージョン化された実行ファイルを使う設定が正しく働くかを確かめてください。(GitHubのOpenSSL 3利用に関する告知、Homebrewのopenssl@3情報)

確認対象はバージョン番号だけではありません。スクリプト内のバージョン判定、コマンドオプション、既定値、出力文字列の解析を調べます。OpenSSL 4のコマンド形式に関する変更点は公式文書で確認できますが、記載された差異は調査の手掛かりであり、特定のプロジェクトで失敗する証明ではありません。(OpenSSL 4のコマンド形式オプション)

証明書・署名・TLSの検証では成果物まで追います

OpenSSLのバージョンを確認しただけでは、リリース工程の安全性は判断できません。証明書生成、秘密鍵の処理、署名、TLS接続など、ワークフロー内で実際にopensslを使うタスクを列挙し、生成物と下流処理がチームの期待どおりかを検証します。

特にコード署名では、処理が成功したという終了コードだけで合格にしないでください。署名された成果物が既存の検証手順を通り、後続の配布・受け入れ工程でも問題なく扱われるかを確認します。証明書の役割と署名済みコードの作成手順は、Appleの技術文書も参照してください。(コード署名証明書の解説、macOS配布用署名済みコードの作成手順)

チームの既存テスト、監査記録、署名・TLSの検証結果を証拠として残します。一般的なコマンド例を実行しただけでは、実際の証明書やリリース成果物が互換であることの証明にはなりません。

ネイティブ依存と選択肢を比較します

依存ライブラリのインストールスクリプトやコンパイルログを調べ、OpenSSLのバージョン、ヘッダー、ライブラリのパスを明示しているかを確認します。リンク時の問題が疑われる場合は、影響する依存だけを隔離したビルドで試してください。公開リポジトリでの修正例は調査の参考にはなりますが、別のチームでも同じ障害が起きる根拠にはなりません。

これは環境の優劣を示す点数ではなく、検証状況を整理するための判定表です。優先度・高はバージョン未指定の呼び出しがリリースや署名に関わる状態、中は影響範囲が限定されるものの、出力や依存関係の確認が残る状態、低は呼び出し元とバージョンを特定でき、代表ジョブの検証記録も揃っている状態です。低判定でも、実際のrunnerで確かめた記録がなければ変更許可とはみなさないでください。

本番変更の前に代表ジョブで検証します

手順は、実行中のワークフローから証拠を集め、未確認の影響を小さくする順で進めます。

• 対象runnerのラベル、イメージ情報、実際のopensslのパスとバージョンをログに残します。
• YAML、シェル、ビルドスクリプト、再利用actionから呼び出しを探し、バージョン指定の有無と利用目的を記録します。
• 証明書、鍵、署名、TLS、ネイティブ依存の各タスクを、チームのリリース工程との関係で分類します。
• 代表的なワークフローを対象環境で実行し、ビルド結果だけでなく署名済み成果物、検証結果、下流の受け入れ結果も比較します。
• OpenSSL 3を必要とするタスクは明示的なバージョン指定を検証し、失敗した場合に対象ジョブを分離して従来の手順へ戻せるか確認します。
• ログ、イメージ情報、検証結果、変更判断をまとめ、告知やイメージ内容に更新があれば再確認します。

検証に失敗したら、未確認のまま対象runnerを一斉に切り替えるのではなく、影響するタスクを切り分け、チーム既定の回退手順を使います。ビルドが通ったという一つの結果だけで、証明書や署名を含むすべての処理が問題ないと判断しないことが重要です。

一時的な検証用runnerを用意する目的で現在のCI環境を増やす方法には、既存の本番ジョブとの分離が不十分になりやすいこと、空き容量や保守作業を自社で抱えること、実機の調達に時間がかかることがあります。隔離した試行環境が必要で、手元の機材を増やしたくない場合は、期間や要件を確認したうえで、zshmacのMacレンタルも比較対象にできます。ただし、長期間にわたる安定した高負荷運用や、物理インターフェースへの接続が必須なら、自社保有機材なども含めて検討してください。条件を整理する際は、Mac環境の選択肢を比較するページと、東京のMac mini環境を確認し、必要な接続方法や利用期間に合うかを照らし合わせられます。