
【Google Cloud Next Tokyo 2025】今日から始めるCI/CD Observability:講演レポート
Google Cloud Next Tokyo 2025とは?
Google Cloud Next は、Google Cloud が主催する大規模なオンサイトイベントです。2025年8月5(火)と6日(水)の2日間、東京ビッグサイトで開催され、オンラインでのライブ配信も行われます。
本イベントでは、最新のクラウド技術や生成 AI ソリューションが紹介され、業界リーダーによるセッション、革新的なデモ、ネットワーキングの機会を通じて、Google Cloud が実現する未来を体験可能です。
セッション情報
セッション名 | 今日から始める CI/CD Observability |
---|---|
セッション概要 | CI/CD パイプラインの可視性は、ソフトウェアデリバリーの信頼性と開発生産性を向上させるために不可欠です。 本セッションでは、Google Cloud と GitHub Actions を活用し、CI/CD パイプラインのオブザーバビリティを高める方法を解説します。 Workload Identity によるセキュアな認証を導入し、パフォーマンスのボトルネックやクリティカルパスの特定など、実践的なアプローチを紹介します。さらに、DatadogのCI/CD Visibility を用いたパイプラインの可視化手法もご紹介します。 |
はじめに
本記事では、Google Cloud Next Tokyo 2025のセッション「今日から始める CI/CD Observability」の内容を基に、ソフトウェアデリバリーの信頼性と開発生産性を向上させるための重要なコンセプトを解説します。講演では、CI/CDパイプラインに「オブザーバビリティ(可観測性)」を適用し、Google CloudとGitHub Actionsを活用してその価値を最大化する方法が語られました。
この記事を読むことで、CI/CDパイプラインが直面しがちな「安全性」と「可視性」の課題を、Workload IdentityやOpenTelemetryといった具体的な技術を用いてどのように解決できるのか、その実践的なヒントを得ることができます。

CI/CDパイプラインの課題を解決する、オブザーバビリティという新たな視点
CI/CDにおけるオブザーバビリティは、システムの動作をリアルタイムで監視・分析し、問題を迅速に特定・解決するために重要です。
具体的には、パイプラインの実行状況、ビルドやデプロイの失敗、性能低下を可視化することで、開発者はボトルネックやエラーの原因を即座に把握可能。また、ログ、メトリクス、トレースを活用してパフォーマンスを最適化し、信頼性の高いデプロイを実現。継続的な改善を支え、開発速度と品質を両立させる基盤となります。これにより、障害の予防や迅速な対応が可能となり、ユーザー体験の向上にも寄与します。
本セッションで紹介された、Google CloudのWorkload Identity Federationによるセキュアな認証と、OpenTelemetryを活用したパイプラインの可視化は、開発の生産性と信頼性を向上させるための重要なアプローチです。
オブザーバビリティは運用フェーズだけのものか?
一般的に「オブザーバビリティ」はシステムの運用フェーズで使われる言葉というイメージが強いかもしれません。しかし、その考え方はシステム開発ライフサイクルのあらゆるフェーズで活用できる、というのが近年の潮流です。CNCF(Cloud Native Computing Foundation)が発行したホワイトペーパーでも、オブザーバビリティが開発ライフサイクル全体で価値を持つことが述べられています。
この「オブザーバビリティのシフトレフト」という考え方は、セキュリティ分野で言われる「シフトレフト」と同様に、問題が起こる前の開発段階から品質や生産性を高めるためのアプローチです。
開発フェーズからCI/CDパイプラインのオブザーバビリティを意識することで、より生産的で可視性の高いパイプラインを構築できます。この動きは業界全体で注目されており、継続的な改善のためにCI/CDオブザーバビリティが重要であるという認識が広まっています。
さらに、OpenTelemetryのコミュニティでは「SIG CI/CD Observability」というワーキンググループが発足し、この分野の標準化に向けた議論が進められるなど、CI/CDとオブザーバビリティの組み合わせは今、非常に注目されているトピックです。
CI/CDが直面する、安全性と可視性の課題
現在のCI/CDプロセスには、主に「安全性」と「可視性」という二つの側面で課題が存在します。
一つ目の課題は安全性です。一般的なCI/CDパイプラインでは、テスト、ビルド、デプロイといった一連の処理を実行するために、すべての権限がCI環境に集中しがちです。Google Cloudを利用する場合、リソースへの変更権限を持つサービスアカウントキーをCI環境に設定することが多く、このキーが漏洩した場合のセキュリティリスクは無視できません。
二つ目の課題は可視性です。アプリケーションの規模が大きくなったり、マイクロサービスアーキテクチャを採用したりすると、パイプラインは複雑化します。その結果、CIの実行時間が長くなり、どこで時間がかかっているのか、あるいはエラーが発生した際にどこが根本原因なのかを特定することが難しくなります。CIの実行を何十分も待つような状況は、エンジニアの生産性を著しく低下させる要因となり得ます。
Google CloudとOSSで実現する、セキュアで可視性の高いパイプライン
これらの安全性と可視性の課題を解決するために、セッションでは具体的なソリューションが紹介されました。
Workload Identity Federationでサービスアカウントキーを不要に
安全性の課題を解決するのが、Google CloudのWorkload Identity Federationです。これは、OIDC(OpenID Connect)の仕組みを利用して、サービスアカウントキーのような長期的な認証情報を使わずに、外部のワークロードに対してGoogle Cloudリソースへの短期的なアクセス権を付与する機能です。
従来のサービスアカウントキーが抱えていた漏洩リスクや管理の煩雑さという課題は、この機能によって根本から解決されます。必要な時だけ一時的な認証情報を発行するため、CI/CDパイプラインのセキュリティが格段に向上します。
特にGitHub ActionsのようなCI/CD環境では、「google-github-actions/auth」という公式のアクションが提供されています。このアクションをワークフローに数行追加するだけで、Workload Identity Federationを簡単に利用でき、サービスアカウントキーを使わないセキュアな認証・認可の仕組みを構築できます。
OpenTelemetryでパイプラインのボトルネックを特定する
可視性の課題は、OpenTelemetryを活用することで解決に導かれます。OpenTelemetryは、トレース、メトリクス、ログといったテレメトリデータを収集し、エクスポートするための標準規格です。各CIツールが提供するログや実行時間だけでは、複雑化したパイプライン全体のどこにパフォーマンスのボトルネックがあるのかを特定するのは困難でした。
そこで、「github-actions-opentelemetry」や「otel-cicd-action」といったオープンソースのGitHub Actionsを利用します。これらは、ワークフローの各ジョブやステップの実行結果をトレースやメトリクスとして収集し、Cloud TraceのようなOTLP(OpenTelemetry Protocol)に対応したバックエンドに送信する機能を提供します。
これにより、パイプラインのどのステップが全体の遅延を引き起こしているかを正確に可視化し、継続的な改善に繋げることが可能になります。同様の機能はDatadogのCI/CD Visibilityといったサービスでも提供されており、より詳細な分析を行うこともできます。
まとめ
今回のセッションでは、CI/CDプロセスにオブザーバビリティの考え方を適用する「シフトレフト」の重要性が語られました。
紹介された具体的な手法として、Workload Identity Federationを利用することでサービスアカウントキーへの依存から脱却し、CI/CDの安全性を高めることができます。また、OpenTelemetryに対応したOSSや各種サービスを活用してパイプラインのテレメトリを収集し、パフォーマンスを可視化することで、継続的な改善サイクルを回すことが可能になります。
まずは、お使いのGitHub ActionsのワークフローにWorkload Identity Federationを導入し、サービスアカウントキーを廃止することから始めてみてはいかがでしょうか。その上で、OSSのアクションを利用してパイプラインのトレースを取得し、パフォーマンスのボトルネック特定に着手することをお勧めします。これらの実践を通じて、より安全で生産性の高いソフトウェアデリバリーを実現してください。