【ITニュース解説】Migration Window, Morning One: My Scanner Caught One of My Own Repos Still on macos-14

ソフトウェア開発において、コードのテストやデプロイといった一連の作業を自動化する仕組みは「継続的インテグレーション（CI）」や「継続的デリバリー（CD）」と呼ばれ、多くの開発現場でその重要性が増している。GitHub Actionsは、このCI/CDをGitHub上で実現するための強力なツールの一つで、開発者が定義した「ワークフロー」を自動的に実行する。このワークフローが実際に動作する仮想環境は「ランナー」と呼ばれ、特定のオペレーティングシステム（OS）やソフトウェアがあらかじめインストールされている。

最近、このGitHub Actionsのランナー環境で重要な変更が二つあった。一つは、多くのプロジェクトで利用されてきたmacOS-14というバージョンのランナーが、2023年11月2日をもって完全にサポートを終了し、利用できなくなること。もう一つは、Linux系のランナーで使われるubuntu-latestというラベルが指すOSのバージョンが、段階的にUbuntu 26.04へ更新されることである。特にmacOS-14のサポート終了に関しては、本格的な廃止の前に「ブラウンアウト」と呼ばれる期間が設けられた。これは、特定の時間帯にランナーを意図的に停止させ、開発者が問題発生を事前に検知し、対応できるようにする試みで、今回の場合は10月19日の夜間に実施された。

このようなランナー環境の大規模な変更は、既存のプロジェクトに予期せぬ影響を与える可能性がある。もしプロジェクトのワークフローが古い環境に依存したままだったり、新しいバージョンとの互換性がなかったりすれば、突然ビルドが失敗したり、テストが実行できなくなったりする事態に陥りかねない。開発作業が滞ってしまうことを避けるためには、事前に影響を確認し、適切な対応を行うことが極めて重要となる。

今回のニュース記事の筆者は、これらの変更が発表された直後の10月19日の朝、自身の管理する五つのリポジトリにある六つのワークフローファイルに対して、自作の自動スキャンツール「RunnerDriftAudit」を実行した。通常、このような問題は実際にランナーが停止したり、新しいバージョンに切り替わったりするまで表面化しないことが多く、いざ問題が起きてから初めて気づくというケースが少なくないが、筆者はその前にリスクを把握しようとしたのだ。

スキャン結果は筆者自身も驚くもので、合計で11件の「HIGH（高優先度）」と評価される問題が検出された。これらの問題は主に「floating label（フローティングラベル）」または「retired label（廃止されるラベル）」の使用に関連するものだった。

特に重大な問題として特定されたのは、「photoveil-ios」というリポジトリのCI設定だった。このCIは、まだmacOS-14のランナーを使うように指定されていたのだ。もしスキャンを行っていなければ、その日の夜に始まったブラウンアウト期間中にこのワークフローは確実に失敗し、11月2日以降は完全に動作しなくなっていたはずだ。これは、ランナーの廃止によって引き起こされる具体的な問題の典型例と言える。筆者はこの問題を発見するとすぐに、ワークフロー内のmacos-14という記述をmacos-15に修正し、その日の朝のうちに新しい設定でCIを再実行したところ、32秒で無事に完了した。たった一行の変更で、将来発生しうる深刻な問題を未然に防ぐことができたわけだ。

この経験は、事前のスキャンと予防的な対応がいかに重要かを明確に示している。問題が発生してワークフローが赤くなる（失敗する）のを待つのではなく、事前に自動ツールで潜在的な問題を洗い出すことで、開発者は影響が出る前に対応を完了できる。これにより、予期せぬトラブルによる開発の停止や遅延を避けることが可能になるのだ。

スキャンで検出された他の「HIGH」な問題には、ubuntu-latestやwindows-latestのようなフローティングラベルの使用があった。フローティングラベルとは、常にその時点での最新バージョンを指すように設定されたラベルのことである。例えば、ubuntu-latestと指定すると、GitHub Actionsはその時に利用可能な最新のUbuntu環境でワークフローを実行する。これは通常、常に最新の環境でテストしたい場合に便利だが、今回のUbuntu 26.04への大規模な更新のように、ランナー環境が大きく変わる際には予期しない問題を引き起こす可能性もある。しかし、筆者は自身の「cn-ai-coding-workflow」リポジトリなどで行われている特定のテストの目的上、意図的にこれらのフローティングラベルを修正しなかった。そのテストは、まさに「最新のOS環境でスクリプトが正しく動作するか」を確認するためのものであり、ラベルを特定のバージョンに固定してしまうとそのテストの目的が失われてしまうからだ。もしロールアウト中に問題が発生すれば、それがまさにテストで検出したい「信号」となると、筆者は判断したのである。

また、「WARN（警告）」として検出された問題として、actions/checkout@v4のようにアクションのバージョンを特定の「タグ」で指定しているものがあった。GitHub Actionsでは、アクションのバージョンを指定する際に、v4のようなバージョンタグを使うこともできるが、より安全で再現性の高い方法は、そのアクションの特定のコミットのハッシュ（SHA）を直接指定することである。これは、タグが指す内容が将来変更される可能性があるのに対し、コミットハッシュは一度作成されたら変わらないため、ワークフローの実行環境をより安定させ、予期せぬ変更から守ることができる。筆者自身もこの警告は認識しているものの、まだ対応ができていないと正直に述べている。

今回の筆者の経験は、システムエンジニアを目指す皆さんにとって非常に示唆に富んでいる。ソフトウェア開発の環境は常に変化しており、それに対応するためには、自分のプロジェクトがその変化にどのように影響を受けるかを常に意識し、定期的に確認する習慣が重要である。GitHub Actionsのランナーのように、一見すると開発者が直接関わらない部分の変更であっても、それがワークフローの安定性に直結するケースは少なくない。自動化ツールを積極的に活用し、問題が表面化する前に予防的な対応を行うことの価値は計り知れない。

現在も、ubuntu-latestの移行は11月19日まで、macOS-14の廃止は11月2日までと、対応期間はまだ残されている。筆者が公開している「RunnerDriftAudit」のようなツールは無料で利用できるため、自分のGitHub Actionsワークフローが影響を受けないか、一度スキャンしてみることをお勧めする。開発環境の変化に先んじて対応することで、より安定した開発プロセスを維持できるようになるだろう。