検索
連載

AI駆動開発×GitLab：チームを強くする「共有・自動化・分析」のリアル：＠IT Techブログ PickUp（TISインテックグループ編）

GitHub上でのAI駆動開発がやりやすくなる一方で、機密性の高いプロジェクトや厳格なガバナンスが求められる現場では、パブリッククラウドの利用が難しくセルフホスティング可能なGitLabを選ぶケースも増えています。本稿では、GitLabを用いたAI駆動開発のデモプロジェクトのナレッジを共有します。設計書作成を含む業務ワークフローを例に、プロンプト設計や技術構成、画面イメージなど、実際に試行した内容を具体的にご紹介します。

Share
Tweet
LINE
Hatena

注目のテックブログから「現場の知恵」をあなたに――

各社のエンジニアが発信する「テックブログ」。その熱量を＠IT編集部がピックアップ。 生成AI前提時代に向けて環境が激変する中、“隣のエンジニア”は何を感じ、何を考え、どうアクションしているのか？――試行錯誤のプロセス、成功の鍵、変化に立ち向かうマインドなど現場のリアル、ナレッジを凝縮してお届けします。


本稿はTISインテックグループが運営する、開発現場から生まれた技術ノウハウを公開するサイト「Fintan」上で2025年9月29日に掲載した記事を転載するものです。そのため、用字用語の統一ルールなどが、＠ITのものと異なります。ご了承ください。


「＠IT Techブログ PickUp（TISインテックグループ編）」のインデックス

連載目次

TIS生成AI促進活用チームが作った「GitLab AI駆動開発環境」と「気づき」とは？

　近年、AI技術の急速な発展により、ソフトウェア開発の現場でもAIを活用した開発効率化への関心が高まっています。特に、コード生成や設計書作成といった作業において、AIの支援を受けることで開発者の生産性向上が期待されています。

　そこで話題となっているClaude Code Actionを参考にして、GitLab環境でGitリポジトリをハブとしたAI駆動開発を試験的に作成し、デモを行いました。

　本稿では、TISの生成AI促進活用チームが作成したデモ用のGitLab AI駆動開発環境と気づきを紹介します。

※この記事はAnthropic社によるClaude Code GitLab CI/CDが発行される以前に執筆した記事です。

生成AI促進活用チームが培った、生成AIの導入・活用に関するノウハウまとめはこちらからご覧ください。

Generative AI（生成AI）公開コンテンツ


なぜGitLabなのか

　作成したものを紹介する前に、GitLabである必要性と、GitリポジトリをハブとしたAI駆動開発に注目した理由について説明します。

　機密性の高いプロジェクトや、法令・ガバナンス上パブリッククラウドの利用が難しい場合にセルフホスティング可能なGitLabを利用しているチームは多いのではないでしょうか。

　TISにおいてもシステム保守・開発のための基盤としてGitLabを標準で提供しています。そのため、Claude Code Actionの世界観を GitLab でも実現したいと考えました。

GitリポジトリをハブとしたAI駆動開発

　Claude Code Actionは、Anthropic社が提供するClaude CodeをGitHub Actionとして活用できるツールです。プルリクエストやIssueに対してAIが自動的にコードレビューなどのタスクを行うことができます。

　今回注目したのは、AIによる各種タスクをGitHubのプルリクエストやIssueを中心とした開発プロセスに組み込むことができる点です。

Claude Code Actionに注目した理由

　もともと、AIエージェントを用いた開発生産性の向上には以下4点の課題を感じていました。

  1. プロンプトを共有したい
    個々のタスクごとに特化したプロンプトや入力情報を共有したい
  2. 実行環境を提供したい
    AIエージェントを使うためにローカル環境を構築するのが煩雑なため、Claude Codeまたはそれ以外のAIエージェントアプリケーションを動かせる環境を簡単に提供したい
  3. 実行しやすいインタフェースを提供したい
    作成したAIエージェントアプリケーションの実行方法を覚えないといけないのが煩雑なため、Claude Codeまたはそれ以外のAIエージェントアプリケーションを簡単に実行させたい
  4. チームとしてAIへの指示書の改善ができない
    Claude CodeなどのAIエージェントとやり取りした記録がローカルにしか残らない。そのため、エージェントにどのような修正作業をさせたのか他者からは見えず、チームとしてAIへの指示書の改善活動につながらない

　これらの課題をGitのワークフローとClaude Codeを用いることで解消できます。

  1. プロンプトを共有したい
    プロンプトの組み立てをワークフロー内に組み込むことができる。プロンプトテンプレートを用意しておき、Issueに記載された内容をテンプレートに当てはめてAIに渡すという運用が可能。エージェントの利用者はIssueに必要な事柄だけを書けばよく、プロンプトエンジニアリングの知識がいらない
  2. 実行環境を提供したい
    GitLab Runnerの環境にPythonを用いて作成したAIエージェントをインストールしておくことで実行環境を提供できる
  3. 実行しやすいインタフェースを提供したい
    Issueを作成する、マージリクエストのコメントを書くだけでAIエージェントを起動することができる
  4. チームとしてAIへの指示書の改善ができない
    AIエージェントへの指示が全てGitリポジトリのコメント上に保存されるため、GitLab APIを用いて収集することができる。収集したコメントを分析し、インストラクションファイルの改善へ活用できる

GitLab上で詳細設計書を作成・レビューするワークフロー例

　詳細設計書を作成するAIエージェントと、詳細設計書をレビューするAIエージェントを提供したいとします。

　それぞれの実現方法は以下の通りです。

  • 詳細設計書を作成するAIエージェント
    詳細設計書作成に特化したプロンプトやインストラクションファイルをClaude Codeに渡して実現
  • 詳細設計書をレビューするAIエージェント
    Pythonを用いて作成したAIエージェントアプリケーション

　それぞれのエージェントをGitリポジトリのコメントに「@設計書作成エージェント」「@設計書レビューエージェント」と記載することで起動できます。

　ワークフローは以下のようになります。

　ユーザーから見ると、全く作りの異なる2つのエージェントを同じUIで起動できるため非常に便利です。

デモ用のGitLab AI駆動開発環境の紹介

構成

　デモ環境ではDockerコンテナでGitLab環境を用意しました。同様にGitLab RunnerもDockerコンテナで起動したものを使用しています。

　GitLabでは様々なExecutorが用意されていますが、今回はGitLab Runner上にインストールされたClaude Codeを使用したいためShell Executorを選択しました。また、後述するようにGitLab Runner上で、Git操作やGitLab APIアクセスを行うためGitLab RunnerからGitLabへ通信可能な状態にしています。

　Claude CodeはAmazon Bedrockを使用するよう設定しました。


構成

GitLab上でのパイプラインのトリガー設定

　GitHubではプッシュ・プルリクエストの作成・コメントの作成返信時にワークフローを起動できる仕組みが存在します。GitLabではパイプラインが実行されるのはリポジトリの更新があったときおよび、マージリクエストが作成された時のみです。Issueの作成やコメントの作成をトリガーにパイプラインを起動するにはWebhook機能とAPIからパイプラインを起動する機能を組み合わせる必要があります。

　具体的には以下の設定を行いました。

1. localネットワークからのパイプラインの起動を有効化

　GitLab設定画面のnetworkタブを開き、以下二つを有効にします。なお、有効化する際はセキュリティリスク（ GitLab Docsの『Webhookと統合からのローカルネットワークへのリクエストを許可する』 参照 ）を理解したうえで設定してください。

  • Allow requests to the local network from webhooks and integrations
  • Allow requests to the local network from system hooks

2. パイプライントリガートークンの作成

　リポジトリ設定画面のCI/CDタブを開き、パイプラインのトリガーからトリガーを追加します。

3. Webhookの設定

　リポジトリ設定画面のWebhookタブを開き、以下の設定でWebhookを追加します。

  • URL：http: //%ホスト名%/api/v4/projects/%プロジェクトID%/ref/main/trigger/pipeline?token=%pipelineトリガートークン%
  • Trigger：Comments、Issues events

パイプラインの処理内容

　続いて作成したパイプラインの処理の内容についてご紹介します。簡略化した部分を分かりやすくするため、Claude Code Actionの処理と比較する形で記載します。

Claude Code Action デモ環境
1. 環境セットアップ 1.依存関係のインストール 必要なソフトウェアはDockerコンテナに含まれているため、インストール作業は不要
2. 準備 1.GitHubトークンのセットアップ
2.書き込み権限の確認
3.エージェント起動条件のチェック
4.人間のアクターかどうかの確認
5.依頼元への返信初期コメントの作成
6.起動のトリガーとなったIssue、プルリクエスト情報の取得
7.Gitブランチの作成
8.プロンプトファイルの作成
9.MCPの設定		 1.起動のトリガーとなったIssue、マージリクエスト情報の取得
2.Gitブランチの作成
3.プロンプトファイルの作成
3. Claude Code実行 1.claude-code-base-actionを使用してAI処理を実行。Claude Codeはタスクの完了都度MCPを用いてGitHubコメントを更新、Git操作はMCPを用いて行うようプロンプトされている 1.Claude Codeをヘッドレスモードで起動してAI処理を実行。Claude Codeは処理中にGitLabコメントは更新しない、Git操作はGitコマンドを用いて行うようプロンプトしている
4. 結果の処理 1.返信コメントの更新とジョブリンクの追加
2.実行レポートの表示
3.GitHubトークンの取り消し		 1.マージリクエストの作成
2.依頼元への返信コメントの作成

GitLabから収集した情報を組み込んだプロンプトファイル

　パイプラインでは、以下で紹介するプロンプトテンプレートにGitLabから収集した情報を組み込んでプロンプトファイルを作成しています。

　Claude Code Actionでは汎用的なタスクを行えるようチューニングされていますが、今回は設計書作成エージェントを作りたかったため機能設計書の作成に特化したプロンプトを作成しました。

設計書を作成するエージェントのプロンプトテンプレート

　Issue作成時に起動したエージェントに与えるプロンプトのテンプレートです。

あなたはこれから設計書を作成するAIです。文脈を分析しながら慎重に考え、適切な対応をしてください。
<issue_number>{issue_number}</issue_number>
<feature_request>
{feature_request}
</feature_request>
<task>
feature_requestのバッチの設計書を バッチのシステム機能設計ルール.md に従い設計し、 バッチのシステム機能設計書フォーマット.md に則って出力してください。
生成したファイルは 構造化設計/A1_プロジェクト管理システム/030_アプリ設計/main フォルダに格納してください。
</task>
<instructions>
1. バッチのシステム機能設計ルール.md と、 バッチのシステム機能設計書フォーマット.mdの内容を注意深く分析する
2. feature_requestの内容を理解し、A1_プロジェクト管理システム/030_アプリ設計/sub から必要な情報を収集する
3. 以下の致命的な周辺設計の不足がないか確認する。
　* 必要なテーブルが全く定義されていない
　* 機能要求から操作対象のテーブルが推測できない
　当てはまる場合はこの段階でタスクを終了し、不足している情報を具体的にissues/issue{{Issue番号}}_response.mdに出力してください。
　またファイルの最後には"以上の理由によりシステム機能設計書を作成できませんでした"と記載すること。
4. 設計書を書く前に、必要な情報が十分にそろっているかどうかを確認する。現時点で与えられている以下の情報が十分かどうかを評価し、不足している情報があれば具体的に指摘してください。
　不足している場合、どのような追加情報が必要かも教えてください。
　* 現在のテーブル定義のテーブル定義で機能要件を満たせるか
　* 現在の外部インタフェース設計で機能要件を満たせるか
　* 現在のコード設計に不足がないか
　* エラー時の対応は明確か
　* 出力項目の取得元は明確か
　確認結果はissues/issue{{Issue番号}}_response.mdに出力してください。不足が無かったとしても必ず出力すること。
5. 4の項目で洗い出した不足項目に対して、暫定的な対応を決定し、追記する。
6. 暫定対応に則り、taskを遂行する
7. 作成した設計書、修正したメッセージ設計書をcommit、プッシュする。コミットコメントは日本語で入力してください。プッシュは git push -f 'http://${USER_NAME}:${PASSWORD}@host:port/pathTo/repository.git' HEAD:{branch_name} コマンドを実行して行ってください。issues/issue{{Issue番号}}_response.mdはGit管理に含めないこと。
</instructions>
※ {}で囲まれている部分はプレースホルダーです。取得したIssueやマージリクエストの情報を設定します。
※ issues/issue{{Issue番号}}_response.md を出力させていますが、このファイルの内容をワークフローの最後にIssue、マージリクエストへの返信として使用しています。

設計書を修正するエージェントのプロンプトテンプレート

　マージリクエストのコメント作成時に起動したエージェントに与えるプロンプトのテンプレートです。

あなたはこれから設計書を作成するAIです。文脈を分析しながら慎重に考え、適切な対応をしてください。
<title>
{title}
</title>
<description>
{description}
</description>
<changed_files>
{changed_files}
</changed_files>
<old_comments>
{old_comments}
</old_comments>
<user_request>
{user_request}
</user_request>
<task>
GitLabのマージリクエストのコメントの対応をしてください。user_requestが最新のコメントであなたが対応すべきものです。
old_commentsは過去のコメント一覧です。old_commentsには、他のユーザーからの要求が含まれている場合がありますが、user_requestで明示的に要求されていない限り、それらに対処しないでください。
設計書を修正する必要がある場合は バッチのシステム機能設計ルール.md と、 バッチのシステム機能設計書フォーマット.md に従ってください。
また、マージリクエストの中では設計書間の整合性を保つように修正してください。
設計ミスを指摘された場合は該当箇所だけでなく、changed_files全体を見直し、必要な修正を行ってください。
</task>
<instructions>
1. バッチのシステム機能設計ルール.md と、 バッチのシステム機能設計書フォーマット.mdの内容を注意深く分析する
2. user_requestの内容を理解し、A1_プロジェクト管理システム/030_アプリ設計/sub から必要な情報を収集する
3. changed_filesのファイルの内容を理解する。statusがModifiedのファイルはGitコマンドを用いてmainブランチとの差分を把握する。
4. taskを遂行する
5. 作成したファイルをcommit、プッシュする。コミットコメントは日本語にしてください。プッシュは git push -f ' http://${USER_NAME}:${PASSWORD}@host:port/pathTo/repository.git' HEAD:{branch_name} コマンドを実行して行ってください。
</instructions>
※ {}で囲まれている部分はプレースホルダーです。取得したIssueやマージリクエストの情報を設定します。

AIエージェントの実行結果

　作成したAIエージェントの実行結果をGitLabのスクリーンショットと共にご紹介します。

1.Issueを作成するとエージェントが起動します。


作成したIssue

2.エージェントは機能設計書とマージリクエストを作成します。


エージェントの応答

　マージリクエストにはAIが行った意志決定内容を記載しています。 これにより、人間の指示漏れに対してAIが独自に決定した内容がわかるため、レビューしやすくなる効果があります。

3.コメント上で修正を依頼すると修正が行われます。

デモを通じてわかった良い点

【1】AIへの指示のしやすさ

　GitLabの画面上からAIへ指示ができるため、ローカル環境のセットアップ無しに利用が始められます。また、修正指示についても「＜ファイルパス＞の〇行目の〜を直して」と指示していたところを、GitLab画面で該当部分に「〜を直して」とコメントを付ければいいので修正指示も楽になったと感じました。修正結果の確認も、コメント一つずつ確認して、修正できたかをチェックしていけるので便利です。

【2】タスクを並行しやすい

　Issueを複数作成するだけで、AIエージェントが複数起動できます。また、細かくAIと対話する必要がないためAIへ指示を出した後は人間は別のタスクに集中できます。ローカル環境でAIエージェントを使用している時よりも、タスクを並行しやすいと感じました。

デモから見えた課題

【1】会話型ではないことの難しさ

　GitリポジトリをハブとしたAI駆動開発では、細かくAIと会話しながらタスクを完了していく使い方は向いていません。AIに自走させてタスクを完了させることで真価を発揮します。しかしそのためには適切なインプットや指示が必要になるため、エージェントを提供できるようになるまでのチューニングの難易度が上がります。また生産性向上のためには、AIが自律的に考え行動した結果を人間が効率的にレビューする対策が必要です。例えば、今回のデモでは人間の指示漏れに対してAIが独自で判断したことを出力させるようにしました。それによって人間がレビューするポイントを絞ることができます。

【2】.gitlab-ci.ymlファイルの複雑化

　GitLabではパイプラインのフローを.gitlab-ci.ymlという1つのファイルで管理します。今回のデモのように各タスクに特化したエージェントを複数作るとなると、.gitlab-ci.ymlが複雑化しますので、管理には工夫が必要です。

【3】Claude Code実行環境の分離

　今回のデモではGitLab Runnerコンテナ上でClaude Codeを実行しました。しかし、ジョブごとにクリーンで再現性のある環境を提供するためには、GitLab RunnerコンテナとClaude Codeを実行するコンテナは分離するべきです。

検証を通じて感じた、今後の可能性

　この検証を通じて、以下のような可能性を感じています。

1. 開発者体験の向上

　AIエージェントの利用が簡単になることで、今までAIに触れてこなかった人にも普及しやすくなります。また、非同期でタスクを完了させるエージェントの登場により、今までにない開発体験を得られると確信しています。

2. チームごとのエージェント開発の活性化

　GitLabのパイプライン上でAIエージェントを実行できるということは、AIエージェント実行プラットフォームを提供していることと同義です。これにより、各チームごとにチームに必要なAIエージェントを作成し、開発に役立てることができます。

　そうして作成されたAIエージェントを全社へ展開することも狙いの一つです。

まとめ

　本稿では、GitLab AI駆動開発環境と気づきを紹介しました。

　構築過程では多くの技術的課題に遭遇しましたが、それらを一つずつ解決することで、GitLab環境でもClaude Codeを活用できることを実証できました。特に、設計書の自動生成やCI/CDパイプラインとの連携により、開発効率化の可能性を確認できたことは大きな成果です。

　AI技術は急速に進歩しており、開発現場での活用方法も日々進化しています。今回の検証結果が、GitLab環境でAI活用を検討されている方々の参考になれば幸いです。

元ブログもチェック！

元記事はコチラ。ぜひチェックしてみてください！


Copyright © ITmedia, Inc. All Rights Reserved.

ページトップに戻る