この記事の途中に、以下の記事の引用を含んでいます。
GitHub Actions Is Slowly Killing Your Engineering Team
CIの王者・GitHub Actionsに潜む落とし穴とは？
近年、ソフトウェア開発現場で標準となった継続的インテグレーション（CI）の世界。
Github Actionsは、その使いやすさとGitHubとの統合性によって開発プロジェクトのデファクト標準の一つとなっています。
しかし、その“便利さ”が知らず知らずのうちに開発者やチーム全体を疲弊させているかもしれません。
本記事では、CircleCIの初期社員でCIツールの鬼とも言える筆者が徹底的に現状批判しつつ、なぜGitHub Actionsは多くのエンジニアを消耗させてしまうのか、その本質について解説します。
また代替として挙げられたBuildkiteの哲学や具体的な機能面の違いも交え、「開発体験」を取り戻すヒントを考察していきます。
「でもみんな使ってる」──GitHub Actionsの現実
まず、筆者が最も強調しているのは、GitHub Actionsが技術的に優れているから選ばれているわけではないという事実です。
“GitHub Actions is not good. It’s not even fine. It has market share because it’s right there in your repo, and that’s about the nicest thing I can say about it.”
（GitHub Actionsは良くない。決して“普通”ですらない。リポジトリに最初から組み込まれているから使われている……これが唯一ほめられる点だ。）
この指摘は、GitHub Actionsの真の価値を見誤っている開発者が多いこと、その利用が“消極的な選択”であることを痛烈に表しています。
CIツールの採用理由が「とりあえずそこにあるから」なのか「本当に開発体験が優れているから」なのかを考え直す必要があると筆者は主張します。
体験の苛立ち──「ログビューア地獄」と「YAMLの罠」
ログビューアで消耗するエンジニアたち
筆者はまず、GitHub Actions最大のユーザー体験上の負担として「ログ閲覧体験」の悪さを挙げています。
“the GitHub Actions log viewer is the only one that has crashed my browser. Not once. Repeatedly. Reliably… the scrollbar is there, technically, but it’s decorative. It’s a suggestion. … So you download the raw log artifact and open it in a text editor like it’s 2003 and you’re reading Apache access logs…”
（[前略] GitHub Actionsのログビューアは唯一、何度も確実に私のブラウザをクラッシュさせた。他のCIシステムではそんなこと起きなかった。スクロールバーは一応あるけど、見かけだけの飾りだ。[中略] 結局、生ログをダウンロードしてエディタで開き、まるで2003年のApacheログでも読むかのようにデバッグする羽目になる。）
この不自由さは実に多くの開発者に心当たりがあるのではないでしょうか。
CIエラーの解析作業が、ちょっとした“BIOSの設定画面”のようになっているのです。
何度もクリックを余儀なくされ、ページは重く、直観的にエラー原因にたどり着けない。
本来「開発サイクルの高速化」のためにあるはずのCIが、逆に生産性の足かせと化す典型例です。
YAML肥大化と独自仕様の地獄
さらに筆者は、GitHub Actions特有のYAML記法と拡張表現についても苦言を呈します。
“GitHub Actions YAML is a special breed. It’s YAML with its own expression language bolted on, its own context object model, its own string interpolation rules, and a scattering of gotchas…”
（GitHub ActionsのYAMLは一種独特だ。独自の式言語、独自のオブジェクトモデル、逐次補完ルール、それらを取り巻く無数の罠が混在している……）
設定ファイルのちょっとした間違いを見つけるのに数分～数十分かかり、小さなtypoで何度も再実行を強いられるストレス。
多くの人が「${{ }}地獄」「コピペ文化」「試行錯誤あるのみ」状態になっている現状を見事に言い当てています。
本質はCI“体験”の差～Buildkiteとの比較から考える
なぜGitHub Actionsは「使われているのか」
筆者は、このような欠点にも関わらずGitHub Actionsが普及している背景として、デフォルトで無料枠が存在し、手間なく始められる利便性・参入障壁の低さを挙げています。
加えて、Marketplace形式で無数のアクションを組み合わせられることも人気の一因です。
しかし同時にそのMarketplaceには、“よく分からない第三者のコード”を不用意にリポジトリへ招き入れるリスクがあります。
“Every time you type uses: some-stranger/cool-action@v2, you’re handing a stranger access to your repo, your secrets, and your build environment.”
（知らない人のアクションを使うたびに、あなたは機密や環境への鍵をその人に渡している。）
実際、サプライチェーン攻撃の温床ともなりうるこの形態は、エンタープライズ利用やセキュリティ重視案件では致命的な欠陥となりえます。
便利さの裏に潜む制約とリスクを正しく認識しなければ“罠”に陥ります。
Buildkiteの哲学的アプローチ
筆者が理想形として推すのがBuildkiteです。
Buildkiteは「パイプラインはYAML、ロジックはスクリプト」という役割分担が明確です。
“Buildkite’s YAML is just describing a pipeline. Steps, commands, plugins. It’s a data structure, not a programming language cosplaying as a config format. When you need actual logic? You write a script. In a real language. That you can run locally. Like a human being with dignity and a will to live.”
（BuildkiteのYAMLはただパイプライン構造を定義するだけ。本当のロジックは普段の言語で書く。ローカルで実行し、理解やテストもしやすい。）
つまり、複雑なフローや動的なパイプラインを作りたい場合でも、YAMLの表現力に無理矢理ねじ込む必要がなく、テスト・再利用性・デバッグ性に圧倒的な優位があります。
CIの“型”を乱すことなく、開発者本来の言語スキルを活かせる点は実務的な価値が高いといえるでしょう。
計算資源・環境の所有権
CIパイプラインの実行環境も重要な論点です。
GitHub Actionsは「計算資源を貸し出す」形で自前サーバー運用の自由度が極端に低いのが難点。
一方、Buildkiteは「自分のマシン・クラウド資源をCIエージェントとして使える」というシンプルさ・高速さ・キャッシュ運用の容易さが魅力です。
引用文からも、その体験差は一目瞭然です。
“GitHub Actions will give you a mass-produced Ubuntu VM with the emotional warmth of a hospital waiting room.”
“The fastest CI is the one with a warm cache on a big machine that you control.”
（GitHub Actionsのランナーは、感情のない病院の待合スペースのごとく。最速のCIは、自分自身で巨大なマシンを持ちキャッシュがあたたかい環境だ。）
規模の大きな開発チーム、何百ものテスト、モノレポ（巨大な単一リポジトリ）などではこうしたハードウェアの自由度差が開発体験に直結します。
CI疲弊時代の処方箋——「体験」を再考せよ
なぜ多くのチームが「罠」に嵌まるのか？
筆者の批判は決して“GitHub Actionsを使うな”という単純な極論ではありません。
むしろ、ユースケースや規模によってはGitHub Actionsが適している場合も認めています。
“If you’re a small team with a simple app and straightforward tests, it’s probably fine. I’m not going to tell you to rip it out.”
（小さなチームでシンプルなアプリを作り、単純なテストだけなら問題ない。今すぐ乗り換えろとは言わない。）
問題は、その“合理的な範囲”を越えた先で多くの開発者・チームが「地獄のデバッグ待ち」「YAMLマジックへの依存」「不透明なパイプライン」「Marketplace依存」「セキュリティの穴」など、出口の見えない疲弊のサイクルに入り込んでしまうことです。
特に大規模なプロジェクトや商用サービス現場では、CIが日々の生産性やバグ検出速度、セキュリティ事故の可否を決定する最重要インフラとなっているため、「Good Enough（十分マシ）」が求められるレベルが跳ね上がります。
この現実認識が十分に広まっていないのが、エンジニア組織全体の大きな損失になりつつあるのではないでしょうか。
「CIを自作したくなる衝動」との向き合い方
筆者は「もういっそBashで全部書けば……」という誘惑にも言及しています。
“You have not escaped CI. You have built a CI system. It’s just worse than every other CI system, because it’s written in bash, and nobody can follow it…”
（あなたはCI（システム）から逃げたつもりが、新たな、しかも最悪なCIをBashで自作してしまっただけだ……）
CIに不満を感じてBashスクリプトで全自動化……だれしも一度は通る道ですが、「本質的な複雑さ」を素手で管理し始めても結局、構造化もテストも安全もない泥沼に陥るリスクが高い。
CI導入そのものの設計思想・役割分担を見直し、「どこまでをCIツールに任せ、どこからを通常ロジックに分離すべきか」を再定義する必要があるのです。
結論：自分とチームに最適な“CI体験”をもう一度問い直そう
この記事を通して最も重要な気づきは、「たくさんの人が使っており、デフォルトで便利」という理由だけでツールを選び、その見えないコスト（デバッグ時間、ストレス、事故のリスク）を許容し続けてしまう現代の開発現場の“仕組み疲れ”構造です。
GitHub Actionsは確かに、OSS～小規模プロジェクトには「とりあえず使える」「学習が楽」というメリットが絶大です。
しかし、成長したチームや複雑なワークフローや厳しい品質基準が求められる現場では、「本当に作業効率・安全・可視化性・カスタマイズ性を担保できているか？」を定期的に疑い直す必要があります。
選択肢は常に一つきりではありません。
Buildkiteのような「本来のCI体験を重視する」ツールも存在します。
また、Nixや自前CIへの回帰など、多様なソリューションが合ってしかるべきです。
今のCI体験に違和感やストレス、機能的限界を感じているのなら、“自分たちの開発体験”をもう一度問い直してみてはいかがでしょうか。
categories:[technology]
コメント