GitHubは2026年2月26日、macOS 26 runnerの一般提供を発表し、arm64とx64に関連するラベルを案内しています。 したがって、GitHub Actions macOS 26のビルド失敗は、最初にrunnerのラベルと失敗した工程を固定し、アーキテクチャ、ツールチェーン、依存関係、テスト、成果物の順に切り分けてください。目の前の失敗をすぐmacOS 26との非互換と決めつけず、対象のMac環境で安定して再現する場合にだけ、ワークフローや実行環境を変更します。
macOS向けの研究アプリや、複数OS対応の研究ソフトウェアを保守している開発者向けです。
Homebrewやネイティブ拡張に依存する研究生・研究開発者が、環境とコードの問題を分ける際にも役立ちます。
研究室のCIやリリースを管理する担当者には、再検証できる故障記録の作り方も紹介します。
最終更新：2026年10月1日。 macOS 26 runnerの提供状況はGitHubの公式発表、イメージ情報は公式runner-imagesリポジトリを確認しています。イメージ内のソフトウェアは更新されるため、個々の実行についてはワークフローログも照合してください。
失敗の種類を分ける
赤いジョブが示すのは、ワークフロー内のどこかで処理が失敗したということです。コンパイルエラー、テストの失敗、成果物の実行不可では、確認すべき証拠も次の操作も異なります。まず、失敗したステップ名と、その直前に実行されたコマンドを記録してください。
| 症状 | 先に確認する証拠 | 最初の対応 | 評価 |
|---|---|---|---|
| 依存パッケージの取得に失敗 | runnerのアーキテクチャ、依存の配布元、キャッシュ復元 | クリーンな条件で依存解決を再実行 | 環境差を優先 |
| コンパイルで失敗 | コンパイラ、SDK、対象アーキテクチャ、最初のエラー | 実際のツールチェーンとプロジェクト設定を照合 | 比較的切り分けやすい |
| ビルド後のテストで失敗 | テスト名、必要な画面・外部機器、入力データ | 最小サンプルで再実行 | テスト条件を要確認 |
| 成果物を実行できない | 成果物の形式、実行対象、署名や実行時依存 | 保存した成果物を対象Macで検証 | CI成功だけでは不十分 |
「評価」は実測性能や成功率ではなく、診断時に何を優先して調べるかを示しています。runnerのラベルが意図と違う場合は、コードの修正より先にワークフロー設定と実行ログをそろえます。
runnerとアーキテクチャの食い違い
ワークフローに書いた指定と、実行時に選ばれた環境が同じとは限りません。macOS 26のラベルとイメージに含まれる情報は、GitHubのmacOS 26イメージ一覧で確認し、単発の実行についてはログに記録されたrunner情報を基準にしてください。
Apple Silicon向けの依存が見つからない場合は、依存パッケージに対象アーキテクチャ向けの配布物があるか、ビルド設定がその構成を選択しているかを確認します。arm64向けの処理にx64向けライブラリやキャッシュが混ざっていれば、依存取得からコンパイルまでの記録を分け、別条件のジョブとして検証します。
コンパイラとSDKの差
macOS科研ソフトのビルドでは、コードが同じでも、コンパイラやSDKの選択が異なれば失敗箇所が変わることがあります。ログに残ったXcode、SDK、コマンドラインツール、コンパイラの情報をイメージ一覧と照合し、プロジェクトが想定する構成との差を記録します。正確な名称や利用可能なバージョンは更新されるため、固定的な一覧として扱わず、該当する実行の記録で確認してください。
失敗の見分け方は次のとおりです。
- ソースコードの問題が疑われる場合： 同じツールチェーンと依存関係で、対象Macでも同じエラーが出るか確かめます。
- イメージ変更が疑われる場合： 以前の成功ログと現在のログを比べ、ツールチェーンや実行環境の差が失敗箇所に関係するか調べます。
- 既定値の選択が疑われる場合： ワークフローが明示的な指定なしにツールを選んでいないか確認し、プロジェクトの基準が定まっている場合に限り、使う版を明示します。
runnerのイメージ情報は環境確認の手掛かりですが、特定の実行で使われたツールの証拠は、その実行のログです。両者が食い違う場合は、ログを保存してから再実行し、イメージの更新を含めて比較してください。
Homebrewとネイティブ依存の検査
依存関係の取得エラーでは、インストール元、アーキテクチャ、環境変数、キャッシュの復元履歴をまとめて確認します。Homebrewの公式FAQで対象パッケージの前提を確認し、プロジェクトの公式インストール手順に記載された対応範囲と突き合わせてください。特定のパッケージが対応していると推測だけで決めないことが重要です。
GitHub Actionsの依存キャッシュ仕様を確認し、復元されたキャッシュが現在の依存ロックファイルや環境に対応しているか調べます。問題を再現する間は、依存を一括更新したり、権限を広げたり、キャッシュを無差別に削除したりせず、変更を一つずつ行って結果を記録します。
ビルド後のテストと成果物
ビルドが通っても、研究ワークフローの受け入れが完了したとは限りません。ユニットテスト、画面表示や外部機器に依存するテスト、数値結果の検証、成果物の署名や実行可否は、別々の合否として扱います。数値出力を確認するときは、期待値と許容範囲をプロジェクト側で明示し、ログだけで判断しないようにします。
研究データや認証情報を含めない最小サンプルで再試験し、実行ログ、期待結果、生成物を対応づけて保存してください。成果物はGitHubのworkflow artifactsに関する説明を参考に保管し、対象のMacで実際に起動・実行できることを確認します。トークン、内部URL、個人情報を含むログやサンプルは、共有前に必ず伏せてください。
再現性を上げるチェック項目
次の項目を埋めると、担当者が変わっても同じ条件で診断をやり直せます。ログに秘密情報が含まれる可能性がある場合は、共有前にマスキングしてください。詳細な記録が必要な場合は、GitHubのデバッグログ有効化手順も参照できます。
- [ ] 失敗したステップ名、コマンド、最初に出たエラーを保存する
- [ ] runnerのラベル、ログ上の環境情報、対象アーキテクチャを照合する
- [ ] コンパイラ、SDK、関連ツールの記録を保存し、プロジェクトの基準と比較する
- [ ] 依存ロックファイル、取得元、実際の解決結果、キャッシュの復元状況を記録する
- [ ] データや秘密情報を含まない最小入力で、失敗箇所だけを再実行する
- [ ] 生成物を保存し、想定するMac環境での起動・実行を確かめる
依存関係が解決できない、またはrunner情報を特定できない状態なら、原因を確定したと扱わず調査を続けます。対象Macでも同じ失敗が再現し、必要な依存に対応版がなく、あるいはプロジェクトが特定のmacOSツールチェーンを必要とする場合は、runner変更の影響を隔離した並行検証へ進みます。大学の情報管理規則に従い、研究データや認証情報を外部環境へ持ち出さないでください。
FAQ：macOS 26のCIで迷いやすい点
arm64の依存が見つからない場合
runnerの実際のアーキテクチャと、依存の配布元が提供する対象形式を照合してください。キャッシュの復元条件も確認し、クリーンな依存解決で再現するまでは権限変更や一括削除を避けます。
Apple Silicon runnerでコンパイルできない場合
ログに残ったコンパイラ、SDK、依存のアーキテクチャを確認します。x64用の依存が混ざっていないかを調べ、最小のビルド手順でも再現するかを切り分けてください。
手元のMacとrunnerで結果が異なる場合
両方の環境のアーキテクチャ、ツールチェーン、依存解決結果を記録し、差分を一つずつそろえます。違いが残る場合は、ローカル固有の設定を除いた条件でも再試験します。
テスト成功後に成果物が動かない場合
テスト合格とは分けて、成果物の形式、対象アーキテクチャ、署名の要否、実行時依存を確認します。保存した成果物を対象のMacで起動し、研究データを含まない最小サンプルで動作を確かめてください。
現在のrunnerはイメージやツールの更新に影響され、手元のMacも個別設定との差が残ることがあります。一方、LinuxだけではmacOS固有の動作を直接確かめられません。実機での再現が必要でも、長期にわたる高負荷利用や物理機器との接続が前提なら、レンタルより自前の設備が適する場合があります。接続方法や利用上の注意を確認したい場合は、SSHMacのヘルプセンターも参照し、利用期間や接続要件がプロジェクトに合うか判断してください。短期間だけ隔離したmacOS環境で再検証したい場合は、SSHMacのMacレンタルプランを確認してください。