10 チーム同時のハッカソンを支えた Kubernetes + Argo CD の GitOps プレビュー環境「3A」の紹介

Ai Workforce 事業部に Technical Product Manager として参画している @riywo です。10 年ほど前になりますがコンテナオーケストレーションのサービスを専門に扱っていた頃、運用のハードルの高さから、当時の私は Kubernetes をあまり薦めていませんでした。そんな私が先日、半日の事業部内ハッカソンのために Kubernetes + Argo CD の GitOps で 10 チーム分の独立した Ai Workforce 環境を立ち上げたのですが、自分では kubectl を使うことも YAML を書くこともほとんどなく 10 環境を準備できてしまい、コーディングエージェントとの相性の良さに感銘を受けました。

今回は、この 10 環境をあっという間に用意できたプレビュー環境の仕組みと、GitOps + Kubernetes とコーディングエージェントの相性の良さについてご紹介します。なお、この取り組みは SRE が整備した GitOps 基盤の上で、コーディングエージェントの出力は人間がレビューし、変更履歴が残る形で適用しています。

Ai Workforce 事業部ハッカソンを実施しました

Ai Workforce はエンタープライズ向けの AI エージェントを提供しています。ワークフローやツールなどを組み合わせることで様々なユースケースに対応できる柔軟なプラットフォームを目指していて、特にこの数ヶ月で多くの汎用的な機能が実装されたことでできることが爆発的に増えてきました。そこで、Ai Workforce 事業部の中で自分たちの業務を Ai Workforce を使って行うことで、自分たち自身がお客様となって Ai Workforce の価値を受け取りつつ、同時に一番先にフィードバックできるようになることでプロダクト自身をもっと進化させていきたいと思いました。

そこでまずはみんなでガッと集中して色々作ってみる時間を取ろうということで、半日使って事業部内ハッカソンを実施しました！合計で 10 チームが作られ各チームに様々な職種 (エンジニアだけでなく営業職やプロダクトマネージャー、HR も含めた全職種) の人が混ざるようにしたことで、普段交流の少ないメンバー間でも互いの課題感を共有して、Ai Workforce を使ってその課題を直接解決してみるという取り組みができました。「明日から業務で使いたい」という成果物もいくつか生まれ、業務への組み込み方についてすでに議論が始まっています。また、プロダクトに対する多くのフィードバックも得られました。

Ai Workforce にはいわゆる Dev 環境と呼ばれる main ブランチが常にデプロイされ続けていて雑多な用途で使える共有のインスタンスがあります。しかし、そこでハッカソンを 10 チーム同時に行うと、コード変更をしたいときに全チームに影響してしまうし衝突も起こってしまいます。また、ハッカソンで作成した一時的な検証データが共有環境に残り続けてしまいます。

そこで、今回はちょうど最近導入したプレビュー環境 (部内では通称 3A と呼ばれています。以下、3A) を利用することにしました。3A とは上の図のように、Kubernetes クラスタ上に Argo CD を用いた GitOps で Ai Workforce のインスタンスを自由に立ち上げられる仕組みです。Dev 環境を含め既存の Ai Workforce は Kubernetes を利用してはいないのですが、3A では GitOps で自由に上げ下げできるようにしたかったので Kubernetes + Argo CD を使って、データベースからドメインまでほぼフルスタックで起動できるようになっています (参考までに下の図が通常環境のアーキテクチャ図で、3A はこれをほぼ全て Kubernetes 上に立ち上げています)。管理 UI も提供しているので、そこから作成・削除等の各種操作も行えます (操作の結果は PR => merge されるだけなので、何が行われたかは GitHub から履歴で辿れます)。

この 3A の仕組み自体は、SRE が設計・検証・権限管理までを含めてごく短期間で作り上げたものです。SRE が Kubernetes で作ってみるという話を聞いてから完成までのスピードには本当に驚かされました。また、GitOps で拡張性高く制御できるので、一旦基礎ができるといろんなエンジニアがすぐに機能拡張をすることもできました (例: ブランチに自動追従、リソースや環境変数を細かく調整)。現在では、GitHub PR でプレビューしたい時に preview ラベルをつけるとそのブランチの環境が自動で立ち上がるようになっていたり、トピックブランチ等で大きめの開発 (特にフロントエンド周り) を行う時にそのブランチに追従する環境を持っておくことで、ブランチ並行開発の効率も上がっています。PoC をする際にもすぐに誰でも触れる環境が main ブランチにマージせずとも準備できるので、ここ最近の爆速開発を陰で支えてくれています。

今回のハッカソンではこの 3A 環境に 10 インスタンスを同時に立ち上げることで、各チームごとに隔離された環境があっという間に手に入りました。ブランチもチームごとに別のブランチにそれぞれ追従するようにしたので、DB マイグレーション含むコード変更が自分のチームのインスタンスにだけ適用可能となりました。立ち上げる作業自体は、コーディングエージェントに Argo CD 向けの PR を作ってもらってマージするだけであとは自動的に作成されるようにできたので、作り直しも容易でした。もちろん終わったあとのお片付けも簡単で、プレビュー環境と、それにひもづくデータベースなどのリソースをまとめて削除できました。kubectl を活用する skill (コーディングエージェント向けにまとめた調査手順・ツール定義) も配布したので、ハッカソン中のトラブルシューティングも各チームのエンジニアが独力で行うことができました。

ハッカソン用に注意したところ

環境の構築に当たって、いくつか注意して行ったポイントがあるので共有します。いずれもチーム環境ごとの CR (Kubernetes の Custom Resource。環境の構成を宣言的に記述するリソースです) に数行書き足すだけで実現できていて、CR のエッセンスを抜き出すと次のような形です (フィールド名や値は実際のものから置き換え・簡略化したイメージです)。

apiVersion: preview.example.com/v1alpha1
kind: PreviewEnvironment
metadata:
  name: hackathon-team01
  annotations:
    preview.example.com/auto-build: "true"
spec:
  name: hackathon-team01
  image:
    ref: hackathon/team01
  dataImport:
    source: <複製元の環境名>
  scheduling:
    onDemand: true
  env:
    api:
      API_WORKERS: "<worker 数>"
  resources:
    api:
      limits:
        memory: <メモリ上限>

スポットではなくオンデマンドインスタンスで安定稼働

普段 3A のプレビュー環境はスポットインスタンス上に立ち上げるようにしてコストを抑えています。しかし、今回はハッカソンの半日間、なるべく安定して稼働してほしかったので、オンデマンドインスタンスのプールを別途作成して、ハッカソンの環境だけはそのオンデマンドプールで起動できるように修正を加えました。正確にはオンデマンドに配置する設定を CR に書けるようにして、ハッカソン環境は全てそれを設定して作成しました。ステートフルなコンテナの配置には容量や配置条件の制約もあるため、メモリ・CPU の利用状況も含めてコーディングエージェントに評価してもらいながら、最適なインスタンスタイプを提案してもらいました。

ゴールデンイメージで設定作業を簡素化

通常 3A のプレビュー環境はデータがほぼ空の状態で作成されるのですが、ハッカソンを実施するに当たっていくつか事前に設定しておきたいデータがありました。10 環境分を手作業で実施するとミスをしそうなのと、構築作業中に何度か変更する必要もあったので、ゴールデンイメージ (複製元となる事前設定済みの環境) となる 3A 環境を準備しました。ゴールデンイメージとなる環境で作業を行って、ハッカソン環境は指定した環境からデータを複製して作成できるようにしました。設定をやり直すたびにハッカソン環境ごと作り直すことになりましたが、この仕組みのおかげで手間なく作り直せました。また、立ち上げ後は念の為 Ai Workforce の AI エージェントを API / CLI 経由で実行して問題なく設定できていることをコーディングエージェントで確認しました。

同時アクセスを見込んだ worker 数の引き上げ

また、通常のプレビュー環境は多人数で同時に触ることが少ないため worker 数などを最小限に絞っているのですが、今回は 1 チームあたり 6〜7 名が触ることに加えて複数のデータ処理を走らせたりもするので、そこそこの同時アクセスが見込まれました。そのため worker 数を可能な限り引き上げておいたので、当日それがボトルネックになって作業が進まないということは発生しませんでした。3A は Argo CD で簡単にカスタマイズできるようになっているので、こうした想定外のチューニングも、コーディングエージェントが短時間で変更案を作成してくれたおかげですぐに適用することができました。

GitOps + Kubernetes とコーディングエージェントの相性の良さ

冒頭に書いた通り、私は 10 年ほど前にコンテナのオーケストレーションサービスを専門に扱っていたのですが、その頃の Kubernetes は専門知識がないと運用のハードルが高く、一般にはあまり薦めていませんでした。しかし今回、久々に GitOps で管理された Kubernetes 環境をコーディングエージェントと一緒に触ってみて、圧倒的に扱いやすくなっていることに驚きました。Kubernetes の “YAML 地獄” と言われるような定型的な YAML の作成・変更はコーディングエージェントととても相性が良いですし、「なんだかアプリの挙動が変だ」と自然言語で伝えるだけで kubectl でログやリソースなどの情報を集めながら原因を切り分けてくれます。もちろん最終的な判断や確認はこちらで行いますが、調査の初速が段違いです。また Argo CD の GitOps のおかげで、今の状態に関係なく「こうしたい」という意図を GitHub 上でどんどん更新でき、宣言した状態へ継続的に収束させてくれる ── この性質もコーディングエージェントと非常に相性が良いです。

ひと昔前なら、kubectl の使い方から YAML の運用まで、人間がひととおり理解している必要がありました。コーディングエージェントは Kubernetes エコシステムの幅広い知識を元から持っているので、ツールと権限を適切に渡せば、運用作業の多くを任せられるようになってきています。もちろん人間側の理解や判断が不要になるわけではありませんが、これまで学習コストが高かった領域のハードルが大きく下がったと感じます。私自身も Argo CD は「GitOps ができるやつ」くらいの解像度しかありませんでしたが、SRE が用意した基盤と安全に変更できる GitOps の仕組みがあったことで、コーディングエージェントと一緒に機能追加を重ねながら、ハッカソン向けの環境設定を短期間で仕上げられました。今回、自分では kubectl をほとんど実行せず、PR 作成も含めほぼコーディングエージェントに書いてもらいました。チームのメンバーとも話しているのですが、コーディングエージェントによって Kubernetes の運用ハードルが下がり、採用しやすくなる場面がこれから増えていくのではないかと、個人的には感じています。

まとめ

今回は、Ai Workforce 事業部で行ったハッカソンと、それを支えた 3A というプレビュー環境、そしてコーディングエージェントと Kubernetes の相性について書いてみました。SRE が用意してくれた土台と、各エンジニアの機能拡張、そして AI の力が組み合わさることで、これだけの仕組みづくりをごく短期間で実現でき、ハッカソンからも多くの成果が生まれています。AI エージェントプラットフォーマーとして、これからも自分たち自身で自分たちのプラットフォームをどんどん使い倒していきたいと思います。

EVENT

AIカンファレンス「Bet AI Day 2026」開催概要

開催日時

2026年9月3日（木）12:00 開演

開催方法

オンライン配信

参加費用

無料（事前申込制）

connpass でお申し込み