投稿日
更新日
GitLab環境でGitリポジトリをハブとしたAI駆動開発
もくじ
はじめに
こんにちは。生成AI活用促進チームの長岡です。
近年、AI技術の急速な発展により、ソフトウェア開発の現場でもAIを活用した開発効率化への関心が高まっています。特に、コード生成や設計書作成といった作業において、AIの支援を受けることで開発者の生産性向上が期待されています。
我々のチームでは、話題となっているClaude Code Actionを参考にして、GitLab環境でGitリポジトリをハブとしたAI駆動開発を試験的に作成し、デモを行いました。
本記事では、作成したデモ用のGitLab AI駆動開発環境と気づきを紹介します。
想定読者
- AI活用による開発効率化に興味がある方
なぜGitLabなのか
GitリポジトリをハブとしたAI駆動開発
今回注目したのは、AIによる各種タスクをGitHubのプルリクエストやIssueを中心とした開発プロセスに組み込むことができる点です。
注目した理由
- プロンプトを共有したい
個々のタスクごとに特化したプロンプトや入力情報を共有したい。 - 実行環境を提供したい
AIエージェントを使うためにローカル環境を構築するのが煩雑なため、Claude Codeまたはそれ以外のAIエージェントアプリケーションを動かせる環境を簡単に提供したい - 実行しやすいインタフェースを提供したい。
作成したAIエージェントアプリケーションの実行方法を覚えないといけないのが煩雑なため、Claude Codeまたはそれ以外のAIエージェントアプリケーションを簡単に実行させたい。 - チームとしてAIへの指示書の改善ができない
Claude CodeなどのAIエージェントとやり取りした記録がローカルにしか残らない。そのため、エージェントにどのような修正作業をさせたのか他者からは見えず、チームとしてAIへの指示書の改善活動につながらない。
- プロンプトを共有したい
プロンプトの組み立てをワークフロー内に組み込むことができる。プロンプトテンプレートを用意しておき、Issueに記載された内容をテンプレートに当てはめてAIに渡すという運用が可能。エージェントの利用者はIssueに必要な事柄だけを書けばよく、プロンプトエンジニアリングの知識がいらない。 - 実行環境を提供したい
GitLab Runnerの環境にPythonを用いて作成したAIエージェントをインストールしておくことで実行環境を提供できる。 - 実行しやすいインタフェースを提供したい
Issueを作成する、マージリクエストのコメントを書くだけでAIエージェントを起動することができる。 - チームとしてAIへの指示書の改善ができない
AIエージェントへの指示が全てGitリポジトリのコメント上に保存されるため、GitLab APIを用いて収集することができる。収集したコメントを分析し、インストラクションファイルの改善へ活用できる。
Gitのワークフロー例
- 詳細設計書を作成するAIエージェント
詳細設計書作成に特化したプロンプトやインストラクションファイルをClaude Codeに渡して実現 - 詳細設計書をレビューするAIエージェント
Pythonを用いて作成したAIエージェントアプリケーション
それぞれのエージェントをGitリポジトリのコメントに「@設計書作成エージェント」「@設計書レビューエージェント」と記載することで起動できます。

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

パイプラインのトリガー設定
- 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
- パイプライントリガートークンの作成
リポジトリ設定画面のCI/CDタブを開き、パイプラインのトリガーからトリガーを追加します。 - 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. 環境セットアップ |
|
必要なソフトウェアはDockerコンテナに含まれているため、インストール作業は不要 |
| 2. 準備 |
|
|
| 3. Claude Code実行 |
|
|
| 4. 結果の処理 |
|
|
プロンプトファイル
パイプラインでは以下で紹介するプロンプトテンプレートに、GitLabから収集した情報を組み込んでプロンプトファイルを作成しています。
Claude Code Actionでは汎用的なタスクを行えるようチューニングされていますが、今回は設計書作成エージェントを作りたかったため機能設計書の作成に特化したプロンプトを作成しました。
設計書を作成するエージェントのプロンプトテンプレート
あなたはこれから設計書を作成する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>
設計書を修正するエージェントのプロンプトテンプレート
マージリクエストのコメント作成時に起動したエージェントに与えるプロンプトのテンプレートです。
あなたはこれから設計書を作成する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>
デモ
作成したAIエージェントの実行結果をGitLabのスクリーンショットと共にご紹介します。
- Issueを作成するとエージェントが起動します。
作成したIssue

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

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

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

デモを通じてわかったこと
良い点
- AIへの指示のしやすさ
GitLabの画面上からAIへ指示ができるため、ローカル環境のセットアップ無しに利用が始められます。また、修正指示についても「<ファイルパス>の〇行目の~を直して」と指示していたところを、GitLab画面で該当部分に「~を直して」とコメントを付ければいいので修正指示も楽になったと感じました。修正結果の確認も、コメント一つずつ確認して、修正できたかをチェックしていけるので便利です。 - タスクを並行しやすい
Issueを複数作成するだけで、AIエージェントが複数起動できます。また、細かくAIと対話する必要がないためAIへ指示を出した後は人間は別のタスクに集中できます。ローカル環境でAIエージェントを使用している時よりも、タスクを並行しやすいと感じました。
課題
- 会話型ではないことの難しさ
GitリポジトリをハブとしたAI駆動開発では、細かくAIと会話しながらタスクを完了していく使い方は向いていません。AIに自走させてタスクを完了させることで真価を発揮します。しかしそのためには適切なインプットや指示が必要になるため、エージェントを提供できるようになるまでのチューニングの難易度が上がります。また生産性向上のためには、AIが自律的に考え行動した結果を人間が効率的にレビューする対策が必要です。例えば、今回のデモでは人間の指示漏れに対してAIが独自で判断したことを出力させるようにしました。それによって人間がレビューするポイントを絞ることができます。 - .gitlab-ci.ymlファイルの複雑化
GitLabではパイプラインのフローを.gitlab-ci.ymlという1つのファイルで管理します。今回のデモのように各タスクに特化したエージェントを複数作るとなると、.gitlab-ci.ymlが複雑化しますので、管理には工夫が必要です。 - Claude Code実行環境の分離
今回のデモではGitLab Runnerコンテナ上でClaude Codeを実行しました。しかし、ジョブごとにクリーンで再現性のある環境を提供するためには、GitLab RunnerコンテナとClaude Codeを実行するコンテナは分離するべきです。
今後の可能性
1. 開発者体験の向上
2. チームごとのエージェント開発の活性化
会社としての姿勢
AI技術への取り組み
- 積極的な技術検証: 新しいAI技術を積極的に検証し、実用性を評価
- 社内での知識共有: 検証結果を社内で共有し、組織全体のAIリテラシー向上に貢献
- 段階的な導入: 検証環境での十分な検証を経て、段階的に本番環境への適用を検討
今後の展開
- 他のAI技術の検証: Claude Code以外のAI技術についても積極的に検証
- 実プロジェクトでの適用: 検証結果を基に実際のプロジェクトでの適用を検討
- ベストプラクティスの確立: AI活用における組織的なベストプラクティスを確立
まとめ
また、TISでは今後もAI技術の検証・活用を積極的に進めていく予定です。新しい技術にチャレンジし続けることで、より良いソフトウェア開発環境の実現を目指していきます。
