目次
はじめに
初めまして、松尾です。 普段はPF開発チームで、EKSプラットフォームの開発と運用を行なっています。
本記事は、OPTiM TECH BLOG Advent Calendar 2025 Day 22 の記事です。
今回のテーマ
11月末に開催された有志参加のハッカソンで、自分のチームは「CI-Agent」と名付けてCI上で動くCoding Agentを実装しました。 テーマは「サービス運用の明文化と自動化」です。 発想としてはOpenAI CodexやAnthropicのClaude Code on the Webと似たものですが、社内のGitLab環境に適応しており、Codeのサマリーを取得したり、issueからコード修正を行なってMRを作成させることなどができます。 二日ででちあげた実装なので、まだまだ足りないところがありますが、これをベースにOPTiMに、日々進化していくサービスの運用に必要な工夫を非同期オペレーション化する流れを育てて行きたいと思っています。
詳細
システム構成
- GitLab Runner
- Claude Code
- Bedrock
AnthropicとGitLabの公式構成との違い
２日で凡庸性のあるCodingAgentを独自実装するのは現実的ではなかったのでClaude Codeを使用しています。 基本は以下のリファレンス実装を基準に構築しました。
Claude Code in GitLab CI/CDパイプライン
1点、このリファレンスで詰まったところがありました。
GitLabMCPが使えなかったことです。
GitLabMCPはGitLab ServerとGitLab Duoに統合されており開発を行なっていた時点で次の有料プランでしか使用できないため、OPTiM社内では利用できない状態でした。
プラン: Premium、Ultimate 提供形態: GitLab.com、GitLab Self-Managed
そのため、CI-Agentでは個別にProject Access Tokenを発行しglabを使用してissueへの返信などを実行しています。
定型作業のためのWorkflowsディレクトリ
issueやMRのコメントで作業の詳細を組み立てて投稿するのはかなりめんどくさいです。そこで事前に作業手順（Workflow）を文書化しておいて、CI-Agent側でユーザーコメントをプロンプトとしてマージできるようにしました。
/ci_agent:Workflow UserPrompt
このようなコマンドの形式でインスタンスにWorkflowファイル名の指定と、ユーザーのコメントを投稿できるようになっています。
Workflowファイルはデフォルトでリポジトリの直下に作成されているworkflows/を検索します。
Workflowファイルは次のような形式で記述されることを想定しています。
あなたは GitLab の CI 上で動作する優秀なコーディングアシスタントです。prompt に従い作業したのち、最終的な結果を出力してください。
{{user_prompt}}
<output_format>
- 日本語で結果を整理
- Markdown 形式 (複数行可)
- 図を扱う場合は Mermaid を優先し、`mermaid` コードブロックで囲うこと </output_format>
1. prompt に従い作業を実行 2. 結果を Markdown で出力
{{user_prompt}}の部分が置換されるようになっています。
これくらいの長さのプロンプトであればコンテキストエンジニアリングにおける「無関心の谷」の影響は小さいのでどこに{{user_prompt}}を配置しても問題ないと考えています。
「無関心の谷」はこの参考文献:LLMのプロンプトエンジニアリングーーGitHub Copilotを生んだ開発者が教える生成AIアプリケーション開発（著：John Berryman、Albert Ziegler 訳：服部 佑樹、佐藤 直生）で登場し、以下のように説明されています。
「コンテキスト内学習」（https:..arxiv.org/abs/2302.11042.pdf）
プロンプトの末尾に近い情報ほど、モデルに大きな影響を与えやすいという現象です。
「中間部の喪失」（Lost in th Middle）（https://arxive.org/pdf/2307.03172.pdf）
モデルはプロンプト冒頭と末尾の情報は比較的思い出しやすいのですが、中間に埋め込まれた情報は活用が難しくなるという傾向があります。
この2つの力学が、私たちが「無関心の谷（Valley of Meh）」と呼ぶものを生み出します。これはプロンプトの冒頭を過ぎたところから中盤にかけて形成されるゾーンで、その部分に置いたコンテキストは、冒頭や後半ほどにはうまく活用されないのです。
嬉しいことにClaude Codeは内部でTask Toolなどを使用して、コンテキストをハンドリングしてユーザーの要望をある程度正確に把握し続けます。そのため、Workflowファイルが長くなるとしても、安心です。
さらに、１ファイルで与えるコンテキストの整理を事前に行えるため、タスクの定義の精度はこれまでの開発手法で担保できます。これはコードベースにWorkflowを追加する利点だと思います。
OPTiM社内でコンテキストエンジニアリングに精通したエンジニアはまだまだ少ないと思うので、これらの技術はCI-Agentを普及させる上での課題であり、チャンスでもあると考えています。
Claude Codeを使っているなら/skillsやカスタムコマンドではダメなのか？
/skillsや/agents、カスタムスラッシュコマンドはClaude Codeが搭載している特定のドメイン知識や定型作業を実行させるための機能です。
機能的には、私たちの実装したWorkflowの完全上位互換です。（リソース管理の観点からもおそらく敵わないでしょう）
しかし、これらを採用した場合Claude Codeへの依存が強くなりすぎて、別のツールへの乗り換えが難しくなってしまいます。
それにせっかくAgentを育て始めたのに、ツールの高度な機能を使用したら、Agentを運用する知見が貯まらないかもしれないという思いもあります。
そんなわけで、CI-Agentでは、これらの機能を使っていません。
プロンプトの危険度評価
CI-Agentでは一応、入力されたプロンプトが認証情報などを外部に送信するコマンドが生成されないかなどをチェックする機構を導入しています。 そこまで難しい感じではないです。 grepなどでコマンドを実行する指示がないか静的に検査するなど、多段階の検証を実行しています。
まとめ
AIを業務に取り入れる機運が高まってやがて一年が経ちます。OPTiMでは業務へのAI導入に取り組み始めてから、主に「人が使って効率化」にフォーカスしてAI導入を進めてきました。その効果は開発工数の削減等という形で上がっています。
一方で自分は「一つ一つの業務はAIで少し楽になったかもしれないけど、その分仕事が増えている気がする。担当しているあらゆる業務が漸進的にエージェントで自動化できたらいいな」と考えていました。持論ですが、人間は暇がなければ新しく楽しい挑戦は難しいです。自分はOPTiMがもっと暇になるようにAI-Agentを駆使して暇を作っていこうと思います。OPTiM社内の仕事を一つ残らず自動化できれば、私たちはきっともっと素晴らしい挑戦ができると思います。
変化の早いAIの世界で、ずっとこのツールが生き残ることはないでしょう。しかしこのCI-Agentが礎になって、OPTiMがさらなる挑戦に踏み出せるようになることを期待しています。
このような挑戦的な開発に興味をお持ちの方、ぜひ私たちと一緒に未来のサービスを創りませんか？ OPTiMでは、AIを活用した開発に意欲的なエンジニアを積極的に募集しています。
採用情報はこちらから：www.optim.co.jp
