Argoワークフロー移行に挑んだ話

## はじめに こんにちは、University of British Columbia 学部4年の保井祐理です。 2026年4月3日から4月30日の1ヶ月間、CA Tech JOBに参加しました。 私は、バックエンドエンジニアとして極AIの開発チームに配属していただきました。 この記事では、インターンシップ期間中に私が取り組んだことと、その成果についてご紹介します。 ## 背景 ## 極AI開発チームについて 極予測AIというAIを使った広告クリエイティブに関するプロダクトがあります。 開発チームは、マルチメディアを取り扱う大規模なバッチ処理の開発・運用を行なっています。 ## 元々のワークフロー もともと、このパイプラインは以下のようなアーキテクチャでCloud Workflowsを使用して構成されていました。 ![image](https://developers.cyberagent.co.jp/blog/wp-content/uploads/2026/06/01.png) ## 課題 Cloud Run Jobs を呼び出すたびに、その時点の最新の Docker イメージ（:latest）を取得します。そのため、ループをしながら同じ処理を呼び出したいケースでは、ループの途中で新しいバージョンがデプロイされると、同じワークフローの中で前半と後半で異なるバージョンのコードが動いてしまいます。 ![image](https://developers.cyberagent.co.jp/blog/wp-content/uploads/2026/06/02-1024x329.png) またそれだけでなく、Cloud Workflows は失敗したステップからのリトライができないなど、ワークフローエンジンとしては機能が限られていました。パイプラインが大規模になってきたことで、より柔軟で機能豊富な Argo Workflows への移行を進めることになりました。 GKE（Google Kubernetes Engine）は Google が提供する Kubernetes のマネージドサービスです。Kubernetes とは、複数のコンテナをまとめて管理・実行するためのプラットフォームで、GKE を使うことで Kubernetes クラスターの構築・運用を Google に任せることができます。 Argo Workflows は Kubernetes 上で動作するワークフローエンジンです。各処理をコンテナとして定義し、それらの実行順序や依存関係を管理します。Cloud Workflows と比較して、失敗したステップからのリトライや、GUI（Graphical User Interface：グラフィカルユーザーインターフェース）での実行状況の視覚的な確認など、より豊富な機能を持っています。今回はこの GKE 上に Argo Workflows を構築し、移行先の実行基盤としました。 ## 取り組んだタスクについて こうした背景から、Cloud Workflows で管理されていたワークフローを Argo Workflows へ移行するというタスクに取り組みました。 ## 1. データ変換・集計を担うジョブを Argo Workflows に移行 最初に担当したのは、Cloud Workflows で管理されていたデータ変換・集計ジョブを Argo Workflows へ移行するタスクです。 システム上で BigQuery 上のデータを整形・集計するための dbt ジョブが複数動いており、それぞれ Cloud Workflows + Cloud Scheduler + Cloud Run Jobs で定期実行されていました。今回の移行では、これらのジョブを Argo の CronWorkflow（cron ワークフロー）として再実装しました。 Argo Workflows では、処理の単位を WorkflowTemplate として定義し、それを組み合わせて CronWorkflow を構成します。今回は dbt のビルドジョブを WorkflowTemplate として切り出し、スケジュール実行の設定を CronWorkflow に記述する形で実装しました。 実装後は Argo Workflows の GUI を使って実行状況を確認しました。各ステップが視覚的にノードとして表示され、チェックマークで正常完了していることをひと目で確認できます。 ![image](https://developers.cyberagent.co.jp/blog/wp-content/uploads/2026/06/03-1024x340.jpg) このタスクを通じて、WorkflowTemplate（ワークフローテンプレート）や CronWorkflow といった Argo の基本的な構成要素を一通り実務で習得しました。 ## 2. Slack 通知の Argo Workflow 実装 2 つ目のタスクは、Argo Workflows での共通 Slack 通知機能の実装です。 Cloud Workflows 時代は Log Router でログを検知し Pub/Sub 経由で Cloud Run Function を呼び出すという仕組みを取っていました。Argo への移行に伴い、Argo Workflows の exit hook（終了フック）を使い、全ワークフロー共通で完了・失敗時に Slack へ自動通知する仕組みを実装しました。 実装当初は Slack OAuth トークンを手動で設定する方法をとっていましたが、セキュリティと運用の観点から自動取得できる仕組みを検討しました。まず External Secrets Operator（ESO：外部シークレットオペレーター）を使う構成を検討しましたが、追加コンポーネントの管理コストが高いため採用を見送りました。 最終的には、プロジェクト内の別サービス Python プロセス内で Secret Manager から直接取得するシステムを採用しました。Secret Manager へのアクセスに必要なライブラリを、ワークフロー内でスクリプトを実行するためのコンテナイメージに追加し、Workload Identity の権限を使ってトークンを取得する実装で、既存の設計パターンとの一貫性を保ちながらシンプルに実現できました。 ## 3. Python ワークロードの Argo Workflow 実装 3 つ目のタスクは、広告クリエイティブの Python ワークロードのうちの一つの実行基盤を Argo Workflows へ移行することです。 実装中、Terraform の apply が失敗するという問題に直面しました。原因を調査した結果、デプロイの順序に依存関係があることが判明しました。今回の実装では、Argo Workflows 用に新たに GCP サービスアカウントと Kubernetes サービスアカウントを作成し、Workload Identity で紐付ける構成をとっています。GCP サービスアカウントと Workload Identity のバインディングは別モジュールで管理されており、後者は前者のサービスアカウントをメールアドレスの文字列として参照しています。そのため Terraform が依存関係を自動解決できず、サービスアカウントが存在しない状態で一括 apply するとエラーになります。解決策として、まずサービスアカウントの変更を先にリリースし、その後で Workload Identity バインディングを含む変更を適用するという順序を踏みました。インフラの変更はリソース間の依存関係を意識した上でリリース順序を設計することが重要だと学びました。 ![image](https://developers.cyberagent.co.jp/blog/wp-content/uploads/2026/06/04-1024x476.jpg) ## 学んだこと ## 1. Argo Workflows の実装、Terraform をゼロから習得 CronWorkflow / WorkflowTemplate / Kustomize による環境管理など、Kubernetes 周りの知識も含めて実務を通じて習得しました。 ## 2. Vibe Coding では「背景の言語化」が品質を左右する Python ワークロードの Argo 移行タスクを行っていた際、私は当初「既存の Cloud Workflows を CronWorkflow に変更してほしい」という内容のみで Claude に指示を出していました。しかし実際には、Cloud Workflows が呼び出しのたびに :latest イメージを取得するためバージョンが揃わないという課題を解決するための移行であり、その背景を伝えていませんでした。その結果、Docker イメージのバージョン管理まで考慮した実装にならず、気づかないまま PR を出してしまいました。移行の目的と背景を最初から指示に含めていれば、Claude がバージョン管理の必要性まで踏まえた設計を提案でき、手戻りを避けられたはずです。 要件だけでなく「なぜそうしたいか」「既存の制約は何か」を自分の中で整理してから渡すことが、Vibe Coding を効果的に使う上で重要だと気づきました。 ## 3. 問題の切り分けの大切さ インフラ実装では、エラーメッセージだけでは原因が掴みにくい問題に直面することがありました。 実際に実装した範囲をリリースした際、本番環境では正常に動作しているにもかかわらず、ステージング環境と開発環境では動かないという状況が発生しました。まずどの環境で・何が・どのステップで失敗しているのか」を整理するところから始めました。ステージング環境を調査すると、そもそも Cloud Build によるビルド自体が失敗しておりデプロイまで到達できていないことがわかりました。一方、開発環境では、ビルドは成功しているものの全く別の原因で失敗していることが判明し、環境ごとに原因が異なっていました。 この経験を通じて、エラーに直面したときはまずどの環境で再現するか、どのステップまで正常に進んでいるかを切り分けることが、原因特定への最短経路だと学びました。 ## まとめ 1 ヶ月のインターンシップを通じて、dbt の定期実行フローの移行、Slack 通知の共通化、Python ワークロードの Argo Workflows 移行という 3 つのタスクを完遂しました。 技術面では、Argo Workflows や Kubernetes 周りの知識をゼロから実務を通じて習得したことが大きな収穫でした。また、Vibe Coding を実務で活用する中で、「要件だけでなく背景を言語化してから渡す」という気づきは、AI との協働を今後さらに活かしていく上で自分の中に残る学びになりました。 短い期間ながら、トレーナーさん、メンターさんをはじめ、実際のプロダクト開発に深く関わらせていただいた極 AI チームの皆さんに感謝します。1 ヶ月間本当にありがとうございました！

Argoワークフロー移行に挑んだ話

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト