【知っておきたい】GitLab最新ブログのご紹介 Part14

GitLab公式ブログで紹介された最新アップデート「パイプライン入力（pipeline inputs / CI/CD inputs）」について、従来のパイプライン変数からの移行がなぜ求められるのか、どのようなメリットがあるのかをわかりやすくまとめます。また、移行手順や注意点、セキュリティ・運用面の観点についても詳しく解説します。

なぜ「パイプライン変数」から「パイプライン入力」への移行が必要なのか

これまで多くのプロジェクトで、GitLab CI/CD の設定時に「パイプライン変数（pipeline variables）」が用いられてきました。これにより、パイプライン実行時の動的なカスタマイズや環境パラメータの指定が可能でしたが、近年の DevSecOps の進化により、いくつかの課題が明らかになっています。

• パイプライン変数は型（type）の保証がなく、すべて文字列として扱われるため、boolean や数値、配列などの値を扱う際に誤った型や値が渡されるリスクがある。
• 変数の上書き（override）がトリガー権限のあるユーザーによって自由に行えるため、意図しない値や悪意ある値が渡される「変数インジェクション（variable injection）」の危険性がある。
• どの変数が使われているか事前に明示されておらず、設定のブラックボックス化やメンテナンス性・可視性の低下につながる。

こうした背景から、GitLabは新しい方法として「パイプライン入力（pipeline inputs）」の利用を強く推奨しています。

パイプライン入力（inputs）とは？― 変数との違い

パイプライン入力（inputs）は、.gitlab-ci.ymlファイル内で事前に「どの入力（パラメータ）を受け付けるか」を宣言する仕組みです。これにより、以下の利点が得られます。

• 明示的な宣言：使用する入力が設定ファイルに明記されるため、ドキュメントとしても機能し、可視化される。
• 型安全性（type safety）：文字列（string）、真偽値（boolean）、数値（number）、配列（array）など、入力の型を指定できる。想定外の型や値の混入を防げる。
• 入力値のバリデーション：オプションリスト、正規表現（regex）、デフォルト値（default）などを設定でき、受け付ける値の制限や検証が可能。
• セキュリティと安全性の向上：宣言された入力のみが受け付けられ、外部から任意の変数を注入されるリスク（variable injection）を防ぐことができる。
• 可読性・メンテナンス性の向上：必要なパラメータが明確化され、パイプライン全体の挙動把握や管理が容易になる。

また、inputsを使うことで、同じCI/CDテンプレート（job定義）を複数の環境や条件で再利用しやすくなり、冗長なYAML記述や設定ミスの削減にも寄与します。

移行ガイド概要：パイプライン変数からinputsへの切り替え方法

1. 変数の使用を制限する
2. プロジェクトやグループの設定で「パイプライン変数を使える最小ロール（Minimum role to use pipeline variables）」を設定します。最も安全なのは「誰も変数を使えない（no_one_allowed）」にすることで、変数の上書きを防ぎ、inputsへの移行を促します。
3. 既存変数をinputsに変換する
4. 各パイプライン変数に対応するinputsを、.gitlab-ci.ymlのspec: inputs:セクションで定義します。必要に応じて型（string / boolean / number / array）やオプション、デフォルト値、正規表現などを指定し、ジョブ内では$[[ inputs.入力名 ]]の形式で参照します。
5. トリガージョブ（trigger jobs）の見直し
6. 他プロジェクトをトリガーする場合、job-levelのvariablesを使うと、その変数が暗黙的にdownstreamに渡ってしまう可能性があります。こうしたトリガー時にはinputsを使うように構成変更するのが望ましいです。
7. 段階的かつ安全に移行
8. 全プロジェクトを一度に変更する必要はありません。まず変数の使用制限設定を行い、使われていないプロジェクトの変数無効化、主要なパイプラインを順次inputs化するなど、段階的な移行が安全です。GitLabには「未使用変数の無効化（Start migration）」機能が用意されています。

なぜ今この移行を検討すべきか ― セキュリティ／運用面のメリット

• 変数インジェクションや想定外の値投入によるセキュリティリスクを大きく低減できる。特に、CI/CDを複数人で運用したり、外部からパイプラインをトリガー可能な構成の場合は防御策として有効。
• パイプラインがどのような入力を必要とするかが明確になるため、後から別のメンバーが引き継ぐ場合も理解しやすく、保守性が高まる。
• 型安全性とバリデーションにより、設定ミスやヒューマンエラーの減少、本番環境への誤デプロイなどの事故防止につながる。
• CI/CDの再利用性・可読性が高まり、DRY（Don't Repeat Yourself）な構成やテンプレート利用が進む。特に複数環境・複数サービスを持つ大規模プロジェクトで効果が大きい。
• 長期的にはパイプラインの信頼性、セキュリティ、メンテナンス性、チーム管理の全ての面で改善が見込める。初期の移行コスト以上の価値が期待できる。

まとめ

CI/CDパイプラインはソフトウェア開発・デリバリの根幹であり、設定ミスやセキュリティホールがあると取り返しがつかなくなることがあります。「変数でなんとなく動いているから」と放置するのは将来的なリスクを抱えることになります。パイプライン入力（inputs）を採用することで、誰がいつ何を渡してパイプラインを走らせるかが明示され、ミスや悪意の排除、再利用性・保守性の向上につながります。

特に、多人数チーム、複数環境（ステージング／本番など）、複数サービスの運用、セキュリティやコンプライアンスが求められる現場では、今このタイミングでの移行をおすすめします。安全性・保守性・効率の向上を目指し、ぜひ検討してみてください。

【参考】
パイプライン変数からパイプライン入力への移行でセキュリティを強化

関連リンク