【ITニュース解説】Dear GitHub: no YAML anchors, please

Redditのプログラミング関連フォーラムに投稿された「Dear GitHub: no YAML anchors, please」（GitHub様、YAMLアンカーは不要です）という議論は、ソフトウェア開発において設定ファイルの書き方がいかに重要であるかを示すものだ。この投稿では、GitHub Actionsで使われるYAML形式の設定ファイルにおいて、「アンカー」という特定の機能を使うことの是非が問われている。システムエンジニアを目指す上で、設定ファイルを適切に理解し、利用することは必須のスキルと言える。

まず、YAMLとは何かを理解する必要がある。YAML（YAML Ain't Markup Language）は、設定ファイルやデータ交換に使われる、人間が読み書きしやすいように設計されたシンプルなデータ形式だ。プログラミング言語のような複雑な文法はなく、主に「キーと値のペア」でデータを表現し、データの階層構造を「インデント」（字下げ）で示すことが特徴だ。例えば、name: value のように記述し、関連する設定はインデントを深くしてグループ化する。これは、複雑なシステムの設定を一貫性のある形式で記述するために広く使われている。

次に、GitHub Actionsについて説明する。GitHub Actionsは、GitHub上でソフトウェア開発のワークフローを自動化するための機能だ。ここでいう「ワークフロー」とは、コードをリポジトリにプッシュした際に自動でテストを実行したり、ソフトウェアをビルドしたり、本番環境にデプロイしたりといった一連の作業を指す。このような自動化の仕組みを、IT業界では「CI/CD（継続的インテグレーション/継続的デリバリー）」と呼ぶ。GitHub Actionsでは、これらの自動化処理の手順をYAML形式の設定ファイルで記述する。このファイルは.github/workflowsディレクトリ内に配置され、特定のイベント（例えば、コードのプッシュやプルリクエストの作成）をトリガーにして、定義されたジョブ（タスクの集まり）を実行する。これにより、開発者は手作業を減らし、品質を向上させ、開発速度を上げることができる。

そして、この議論の中心となっているYAMLアンカーについてだ。YAMLアンカーは、設定ファイル内で共通する部分を一度だけ定義し、それを複数箇所で再利用するための機能である。これはプログラミングにおける「DRY原則（Don't Repeat Yourself）」、つまり同じコードを何度も書かないという考え方に通じる。アンカーを使うと、例えば複数のジョブで同じ環境変数のセットや同じ実行ステップのシーケンスを使う場合に、それを一つにまとめて定義できる。具体的には、&記号を使って共通部分を定義し、それに続く名前で識別する。そして、その共通部分を使いたい場所では*記号とアンカー名を使って参照する。さらに、<<: *アンカー名という形式で、参照先のマッピング（キーと値のペアの集まり）を現在のマッピングに「マージ」することも可能だ。これにより、共通部分を一度修正するだけで、それを参照している全ての箇所にその変更が反映されるため、設定の保守性が向上すると考えられている。

しかし、Redditの投稿は、このYAMLアンカーの利用がGitHub ActionsのようなCI/CD設定において、かえって問題を引き起こす可能性があると指摘している。投稿の主な懸念は以下の点だ。

第一に、「可読性の低下と理解の困難さ」である。アンカーが多用されたYAMLファイルは、一見するとシンプルに見えるかもしれないが、実際にその設定が何を意味しているのかを理解するためには、アンカーの定義元と参照元を行ったり来たりする必要がある。特に、多くのアンカーがネスト（入れ子）になっていたり、複雑なマージが行われていたりすると、初心者だけでなく経験豊富なエンジニアにとっても、ワークフローの実際の動作を把握するのが難しくなる。設定ファイルは、それ自体がドキュメントとしての役割も果たすべきだが、アンカーによってその役割が損なわれる可能性があるのだ。

第二に、「デバッグの複雑化」が挙げられる。ワークフローの実行中にエラーが発生した場合、その原因を特定する「デバッグ」作業が難しくなる。アンカーによって抽象化された部分に問題があった場合、どこでどのように定義された内容が実際に使われているのかを追跡するのが困難になるためだ。これは、特にCI/CDパイプラインにおいて、迅速な問題解決が求められる状況で大きな障害となりうる。

第三に、「予期せぬ変更と影響範囲の拡大」というリスクがある。アンカーは共通部分を再利用するため、その定義を変更すると、それを参照している全ての箇所に影響が及ぶ。これは一見メリットのように思えるが、意図しない副作用やバグを引き起こすリスクもはらんでいる。ある変更が、他の無関係なワークフローやステップにまで影響を与えてしまい、予期せぬ動作を招くことがある。特に大規模なプロジェクトで複数のチームが同じリポジトリを共有している場合、特定のアンカーへの変更が広範囲に影響し、調整が難しくなる。

最後に、投稿者は「YAMLの本来の意図との乖離」を指摘している。YAMLはもともと「人間が読み書きしやすいシンプルな設定言語」として設計された。しかし、アンカー機能を多用することで、YAMLファイルがまるでプログラミング言語のような複雑なロジックを持つようになり、本来のシンプルさや可読性という利点が失われる、と主張している。設定ファイルは、コードとは異なり、条件分岐やループのような複雑なロジックを極力持たずに、宣言的に何をすべきかを記述するべきだという考え方だ。

これらの問題に対処するためには、アンカーを避けるか、非常に慎重に使うことが推奨される。例えば、冗長性を排除したい場合は、共通の処理をより小さなワークフローとして定義し、他のワークフローから呼び出す、あるいは、複雑なYAML構造を別のプログラミング言語で生成し、最終的なYAMLファイルをシンプルに保つといった方法が考えられる。これらの方法は、YAMLファイル自体の可読性を保ちつつ、冗長性を排除し、保守性を高めることを目指している。

Redditの投稿は、YAMLアンカーという機能が持つ「諸刃の剣」のような側面を浮き彫りにしている。確かにコードの重複を避け、保守性を高めるという利点はあるが、GitHub ActionsのようなCI/CDワークフローの設定においては、その過度な使用が可読性、デバッグのしやすさ、そして予期せぬ変更のリスクを高める可能性がある。システムエンジニアを目指す者として、ツールの持つ機能だけでなく、それがプロジェクトの全体像やチームの開発プロセスにどのような影響を与えるかを常に考慮し、最適な使い方を選択する洞察力が求められる。設定ファイルのシンプルさと明確さを保つことは、長期的なプロジェクトの成功にとって不可欠な要素と言えるだろう。