どのエンジニアリング組織にも、複雑で反復的かつ時間がかかるが、確実にこなさなければならないタスクが存在します。確立されたGitOpsデプロイワークフローへの新しいマイクロサービスのオンボーディングは、まさにその典型例です。専用マニフェストの生成、デリバリーパイプラインの更新、イメージオートメーションの設定、そして各コンポーネントが正しいネームスペース・ポート・ホスト名を参照していることの確認——ひとつでも見落とすとデプロイは失敗します。手作業で行えば、毎回同じパターンの作業に何時間も、場合によっては丸一日費やすことになります。
これこそ、AIエージェントが本領を発揮する種類の作業です。GitLab Duo Agent Platformを使えば、特定のアプリケーション・GitOpsワークフロー・組織の規約を理解し、複雑なオンボーディングを代わりに実行するカスタムエージェントを作成できます。さらに、エージェント自体と、エージェントが生成するすべての成果物には、GitLab上でバージョン管理・運用管理・ガバナンスが適用されます。自動化のスピードを得ながら、エンタープライズコントロールを犠牲にする必要はありません。
このチュートリアルでは、カスタムエージェントをゼロから構築する方法を解説します。システムプロンプトの生成から、新しいマイクロサービスがKubernetesクラスター上で稼働するまでの全工程を追っていきます。以下の動画もあわせてご覧ください。
ユースケース：TanukiBankへのマイクロサービスのオンボーディング
具体的なシナリオとして、架空の銀行「TanukiBank」を題材にします。同行のWebアプリケーションは、当座預金・普通預金・住宅ローン・不動産担保ローンおよび自動車ローンシミュレーター、そして「支払いと送金」ページを提供しています。「支払いと送金」ページには「クイック送金」パネルがあり、ユーザーが口座間で送金できる機能を目指していますが、現時点では未実装のため「送金」ボタンを押しても何も起きません。基盤となるマイクロサービスが存在しないためです。今回の目的は、そのマイクロサービスを構築し、カスタムエージェントを使ってTanukiBankの既存のGitOpsワークフローにオンボーディングすることです。
アプリケーションとGitOpsプロセス
TanukiBankのコードはGitLabグループ上で管理されており、各マイクロサービス（住宅ローンシミュレーター、自動車ローンシミュレーターなど）を格納するservicesサブグループと、Kubernetesクラスターへのデプロイを担う2つのトップレベルプロジェクト（Tanuki Bank - DeliveryとFlux Config）で構成されています。
GitOpsワークフローは次のように機能します。各マイクロサービスにはコンテナイメージをビルドして組み込みのコンテナレジストリにプッシュするパイプラインがあります。Kubernetesクラスター上で動作するFlux Image Automation Controllerは、これらのレジストリの変更を監視し、変更を検知するとTanuki Bank - Deliveryプロジェクト内の対応するマニフェストを更新します。これによりデリバリーパイプラインがトリガーされ、新しいコンテナイメージのビルドと署名が行われ、デリバリープロジェクトのレジストリに格納されます。最後に、Flux CD Controllerが各環境においてKubernetesクラスターの実行中のポッドをデリバリープロジェクトのコンテナレジストリと同期させます。すべてのFluxマニフェストはFlux Configプロジェクトに存在します。
このワークフローは整理されていますが、新しいマイクロサービスをオンボーディングするたびに、これらの構成要素すべてを正確な順序で操作する必要があります。カスタムエージェントにオンボーディングを任せることができれば、大幅に作業が楽になります。
システムプロンプトの生成
カスタムエージェントの品質はシステムプロンプトに左右されます。そこで、ゼロから手書きするのではなく、GitLab Duoに重要な部分を任せます。tanukibankグループからGitLab Agentic Chatを開き、グループ・サブグループ・その内容を調査して、新しいマイクロサービスをオンボーディングできるエージェント向けのシステムプロンプトを作成するよう依頼します。つまり、このアプリケーションの確立されたGitOpsワークフローをDuoに徹底的に理解・学習させるわけです。これにより、Duoは新しいマイクロサービスのオンボーディングを自動化するのに十分な情報を備えたシステムプロンプトを生成できます。
GitLab Duoはファイルを取り込み、マニフェストや設定ファイルを読み込み、Dockerfileを検査し、依存関係をマッピングした上で、レポート指示・守るべきルール・有効化すべき推奨ツールを含む詳細なシステムプロンプトを生成します。この出力を次のステップに向けて保存します。
重要なのは、GitLab Duoが生成するシステムプロンプトが、そのアプリケーションのGitOpsワークフローの現時点での状態に基づいているという点です。将来このアプリケーションのGitOpsワークフローが変更された場合は、このステップを再実行してシステムプロンプトを再生成する必要があります。
カスタムエージェントの作成
次に、application-agentsという名前の新しい空白プロジェクトを作成します。このプロジェクトでカスタムエージェントを管理し、管理者権限の付与や実行場所を制御します。以下の手順で進めます。
AI > AgentsからManagedタブを選択します。New agentボタンをクリックし、TanukiBank Microservice Onboarderという名前で新しいエージェントを作成し、短い説明を追加して公開設定にします。- GitLab Duoが推奨するツールを選択します。
- 生成したシステムプロンプトを貼り付けます。
- エージェントを作成します。
エージェントを作成したら、GitOpsワークフローを担う両プロジェクト（Tanuki Bank - DeliveryとFlux Config）でエージェントを有効化します。各プロジェクトでAgentic Chatパネルを開き、エージェントのドロップダウンにTanukiBank Microservice Onboarderが表示されることを確認してセットアップを検証します。
Developerフローを使った新規マイクロサービスの作成
エージェントをテストする前に、オンボーディング対象の実際のマイクロサービスが必要です。servicesグループに移動し、intra-account-transfersという新しいプロジェクトを作成して、GitLab Duo Agent PlatformのDeveloper基本フローを活用します。
プロジェクトで新しいイシューを開き、説明欄にマイクロサービスの仕様を記述します。次にGenerate MR with DuoボタンをクリックしてDeveloperフローを起動します。エージェントは仕様を読み込み、マイクロサービスを実装し、ブランチとマージリクエストを作成して、MRをイシューにリンクします。簡単なcurlコマンドでローカルでの動作を確認した後、MRをマージします。パイプラインが実行され、新しいコンテナイメージがプロジェクトのレジストリにプッシュされます。
この時点では、新しいマイクロサービスは存在しますが、GitOpsワークフロー全体はその存在をまだ認識していません。Tanuki Bank - Deliveryプロジェクトのmanifests/devディレクトリにはintra-account-transfersに関するものが何もなく、デリバリーパイプラインも参照しておらず、Flux Configプロジェクトのimage-update-automation.yamlファイルにも新しいマイクロサービスのエントリがありません。
カスタムエージェントの利用
新たに作成したintra-account-transfersプロジェクトでTanukiBank Microservice Onboarderを有効化した後、Tanuki Bank - Deliveryに移動し、Agentic Chatパネルを開いてエージェントのドロップダウンからカスタムエージェントを選択し、サービス名とホスト名を指定して新しいサービスのオンボーディングを依頼します。
エージェントが動き始めます。新しいマイクロサービスのDockerfileを見つけて読み込み、ポートを特定してから適切なマニフェストを生成し、関連するパイプラインを更新します。その過程で、コミットとマージリクエストの作成前に承認を求めて来るので、承認を与えます。
エージェントは最終的に、Tanuki Bank - DeliveryとFlux Configの2つのMRを作成し、実行内容のサマリーを提示します。サマリーにはMRへのリンク、サービスの詳細、作成・変更されたファイル、推奨される次のステップが含まれています。
結果
両MRの変更内容を確認し、Fluxコンポーネントを更新するためにFlux ConfigのMRを先にマージし、次にTanuki Bank - DeliveryのMRをマージします。デプロイを検証するため、GitLabでintra-account-transfers-devという名前の新しい環境を作成してKubernetesクラスターに接続し、適切なネームスペースとFluxリソースを選択して保存します。
環境ビューには起動したばかりのポッドが表示され、ターミナルでkubectlを実行すると3つの新しいポッドが稼働していることを確認できます。公開ホスト名itransfers2.ocpgitlab.comに対して最後にcurlを実行すると、正しいレスポンスが返ってきます。マイクロサービスは稼働状態となり、手間をかけて人が作業した場合には何時間もかかる可能性のあるオンボーディングが数分で完了しました。
メリット
GitLab Duo Agent Platformの上にカスタムエージェントを構築することで、複数の観点から価値が生まれます。まず、複雑な複数プロジェクトにまたがるセットアップ作業を数分に圧縮し、エンジニアがより高付加価値な問題に集中できるようになります。次に、組織固有のGitOps規約・命名パターン・パイプライン構造といった知識とコンテキストを、権限を持つチームメンバーであれば誰でも呼び出せる再利用可能な資産として蓄積できます。
エージェントはマネージドプロジェクトで定義されるため、そのアクセス権・可視性・スコープは他のGitLabリソースと同じ方法で制御されます。プラットフォームチームも安心して利用できます。エージェントが生成するすべての成果物（マニフェスト、コミット、MR）はGitLab上で完全にバージョン管理され、監査可能な状態で保存されます。AIによる自動化のスピードを享受しながら、エンタープライズが必要とするガバナンスとトレーサビリティを犠牲にする必要はありません。
カスタムエージェントを今すぐ構築する
成熟したGitOpsワークフローへの新しいサービスのオンボーディングは、細心の注意が求められる複雑さを持ちながら、エンジニアリングの時間を消費させる反復的なタスクの典型例です。GitLab Duo Agent Platformで構築したカスタムエージェントはその方程式を変えます。アプリケーションと組織のコンテキストを理解し、規約に従い、一貫性のあるレビュー可能な変更を、すべてGitLab内でバージョン管理・ガバナンス・セキュリティが維持された状態で生成します。
GitLab Duo Agent PlatformはGitLab Ultimateの無料トライアルの一環としてお試しいただけます。すでにGitLab Duo Agent Platformをご利用の方は、スタートガイドで詳細をご確認ください。
