AI素人がGitLab Duo Self-hostedをAmazon Bedrockで構成する話

皆様こんにちは。SEの小池と申します。

2025年2月20日にリリースされたGitLab 17.9で、GitLab Duo Self-hosted がGAされました。
GitLab Duo Self-hostedとは、オンプレミス版のSelf-managed GitLabにてDuoを利用にする場合に、自前で用意したLLMを使う構成です。

今回は GitLab Duo Self-hosted を Amazon BedrockでデプロイしたClaude 3.5 Sonnetで構成 してみます。

なお、GitLab Duo Self-hostedをAzure OpenAIで構成する話は以前のブログ (こちら) に載せております。

本記事の対象の方
今回のブログのゴール
事前ご連絡事項
GitLab Duo Self-hosted って何だっけか？
必要なもの
このブログで実現する構成
Amazon Bedrockを使ってDuo Self-hostedを構成する
ちょっとだけ補足事項
GitLab Duo Code Suggestionsを使って動作確認
うまく動作しないときに確認するところ
最後に

本記事の対象の方

オンプレミス版であるSelf-managed版GitLabをお使いで、AI支援機能についてご興味がおありの方。
GitLab Duo Self-hostedの構成について情報収集なさっている方。
具体的にGitLab Duo Self-hostedの検証をなさりたいとお考えの方。

今回のブログのゴール

このブログのゴールはこちらです。

今回のゴール

Self-managed GitLabとAmazon Bedrockを用いて、Duo Self-hostedを構成する。
Self-managed GitLabのWeb IDEで、Code Suggestionsが使えることを確認する。

事前ご連絡事項

本記事はオンプレミス版である Self-managed GitLab Enterprise Edition v17.10.3-ee における仕様をベースに記載しております。それ以外のエディションやバージョンではこの記事に記載の通りではない可能性がございます。
本記事の操作説明と画面ショットはGitLabのローカライズを日本語にした状態で説明しております。それ以外の言語をご利用の方は適宜読み替えてください。
本記事は 2025年4月8日時点の情報をもとに記載しております。この日より後に発生した機能の更新や利用可能なプランの変更については言及しておりません。ご了承ください。
本記事に掲載されている情報は正確性・安全性を保証するものではありません。本記事の情報を利用することによって発生した損失や損害については、一切の責任を負いかねます。

GitLab Duo Self-hosted って何だっけか？

GitLab Duo Self-hostedとは、オンプレミス版Self-managed GitLabのDuoにおいて、GitLab社が用意している共用LLMとは異なる独自のLLMを利用できる構成 です。

GitLab Duo Self-hosted に関する概要は下のブログをご参照ください。
blogs.networld.co.jp

必要なもの

GitLab Duo Self-hosted を Amazon Bedrock で構成するときに必要なものは以下の表の通りです。
正直、GitLabのライセンスを準備するのが一番ハードル高いと思います・・・。

**表1. GitLab DuoSelf-hostedをAmazon Bedrockで構成する時に必要なもの**
必要なもの	要件
Self-managed GitLab	オンプレ or パブリッククラウド上を問わず。公的な認証局によって署名されたサーバー証明書が適用されていること。
Self-hosted AI Gateway	コンテナで起動。オンプレ or パブリッククラウド上を問わず。 GitLabのOSに同居可。
Amazon Bedrockで利用可能なLLM	Duo Self-hostedでサポートされるモデルであること。
AWS IAMユーザーのアクセスキー	Amazon Bedrockで利用するLLMにリクエストを送信可能な、アクセスキーとシークレットキーのセット。必要なポリシーについては後述の【補足②】をご参照ください。
ライセンス	下記の両方が必要。 GitLab本体のEnterprise Ultimate ライセンスアドオンのGitLab Duo Enterpriseライセンス

GitLabのシステム要件はこちらのGitLab Docsをご参照ください。
参考 : GitLab installation requirements | GitLab Docs

また、Duo Self-hostedでサポートされているLLMはこちらのGitLab Docsをご参照ください。
参考 : Supported GitLab Duo Self-Hosted models and hardware requirements - Supported models | GitLab Docs

このブログで実現する構成

このブログで実現する構成は以下の通りです。
Amazon Bedrockを使うということもあり、全体的にAWSのリージョンap-northeast-1にまとめました。

**表2. このブログで実現する構成の概要**
構成要素	概要
Self-managed GitLab	AWSのEC2にインストールする。マシンサイズは t3.xlarge (4 vcpu 数、16 GiB メモリ) 。リージョンは ap-northeast-1。 OSは Ubuntu 24.04.2 LTS。 GitLabのバージョンは v17.10.3-ee。 Let's Encryptで発行した証明書を適用。
Self-hosted AI Gateway	GitLabをインストールしたEC2にDocker Engineをインストールし、コンテナで起動する。バージョンは self-hosted-v17.10.3-ee。
Amazon Bedrock	リージョンは ap-northeast-1。 Claude 3.5 Sonnet を利用する。
AWS IAMユーザーのアクセスキー	IAMユーザーのポリシー内容は後述の【補足②】参照。
ライセンス	下記の両方を事前に用意した。 GitLab本体のEnterprise Ultimate ライセンスアドオンのGitLab Duo Enterpriseライセンス

構成概要図に関する諸注意
上の構成概要図ではAI GatewayとBedrock間の通信がリージョン内に収まっておりますが、これは今回利用したモデルがBedrockのクロスリージョン推論の対象外だったためです。クロスリージョン推論が有効になっているモデルの場合は、通信がリージョン外に出る可能性があります。
また、上の構成概要図ではGitLabとAI Gateway間の通信がインターネットに出ていますが、これは筆者の検証環境の設定によるものであり、実際の構成ではこれらの通信はインターネットに出る必要はありません。
(筆者の検証環境では、GitLabとAI Gateway間の通信でグローバルIPアドレスを使ったためインターネットに出ます。)

Amazon Bedrockを使ってDuo Self-hostedを構成する

ここからは具体的な構成手順を紹介してまいります。
構成の流れは大まかに以下の通りです。

Self-managed版 GitLabを用意する
Self-managed版 GitLabでDuoを有効にする
Amazon Bedrockで特定のLLMを利用可能にする
Self-hosted AI Gatewayを用意する
AI Gatewayに関するパラメーターをGitLabに設定する
Amazon BedrockのLLMをGitLabに登録する

ブログの尺の都合で、GitLabのインストールなどの手順は割愛致します。
割愛した箇所はGitLab Docsの参照先リンクを都度載せておりますので、そちらをご参照ください。

Step1. Self-manage版 GitLabを用意する

まずはSelf-managed版GitLabを用意します。

前述の通り、このブログでは以下の要領で用意いたしました。

OSはUbuntu 24.04.2 LTS 。
GitLabはパッケージ版の v17.10.3-ee 。
Let’s Encryptで発行したサーバー証明書を適用。

いきなりで申し訳ありませんが、Self-managed版GitLabの詳細なインストール手順は、本ブログでは割愛致します。今回検証用に新規でご用意なさる方は、パッケージ版を用いた簡易インストール手順 (こちら) をご参照の上、環境をご用意いただければと存じます。
参考 : Download and install GitLab | GitLab

また、このブログではDuo Self-hostedを構成することが目的のため、Self-managed版 GitLabに対してroot以外のユーザーの追加や設定変更は致しておりません。

Step2. Self-managed版 GitLabでDuoを有効にする

Step1で用意したGitLabにライセンスを適用し、Duoを使えるようにします。 GitLab Enterprise 及び Duo Enterpriseのアクティベーションコードを用意出来次第、適用していきましょう。

まずは管理者アカウントでGitLabのGUIからサインインし、画面左下の方にある [管理者] をクリックします。

左側のメニューから [サブスクリプション] を開きます。

[サブスクリプションを有効化] のテキストボックスに用意したアクティベーションコードを入力し、利用規約に関するチェックボックスを有効にし、[アクティブ化] をクリックします。

正常に適用されると、「サブスクリプションが有効になりました。以下の詳細を確認できます。」と表示されます。これでSelf-managed版GitLabにEnterpriseライセンスが適用されました。

続けて、Duoを有効にしていきます。
まず、ブラウザを一度更新します。すると、左側のメニューにDuoに関する項目が増えるので、[GitLab Duo] をクリックします。

[シートをアサイン] をクリックします。

GitLab環境に存在するユーザー一覧が表示されます。
今回Duo Self-hostedをお試しなさる方に対して、[GitLab Duo Enterprise] 列のトグルを有効にします。

この時点のGitLab Duoの設定に関する補足
この時点でGitLab Duoはデフォルトの設定、つまりGitLab社が公開しているAI GatewayとLLMを利用する設定となっています。なので、実はこの時点でGitLab Duo自体は使える状態となっています。
(このブログではDuo Self-hosted をAmazon Bedrcokで構成することを目的としているため、このままDuo Self-hostedの構成に必要な設定を施します。)

以上でStep2は完了です。

Step3. Amazon Bedrockで特定のLLMを利用可能にする

Amazon Bedrockにおいて、GitLab Duo Self-hostedで使うLLMを利用できるように設定します。

AWSのコンソールにアクセスし、検索ボックスからbedrockと入力し、候補に表示された [Amazon Bedrock] をクリックします。

Amazon Bedrockの画面に遷移します。
画面右上のリージョン選択のプルダウンをクリックし、今回GitLab Duo Self-hostedで使うLLMのリージョンを指定します。このブログではap-northeast-1を選択しました。

左側のメニューから [Bedrock configurations] > [モデルアクセス] をクリックします。

このリージョンで利用することができるモデルの一覧が表示されます。
GitLab Duo Self-hostedで使うLLMの行を探し、[リクエスト可能] > [モデルアクセスをリクエスト] をクリックします。このブログではClaude 3.5 Sonnetを使います。

モデルへのアクセスをリクエストする画面に遷移します。
今回利用したいLLMにチェックが入っていることを確認し、[次へ] をクリックします。

[送信] をクリックします。

「モデルアクセスの更新が送信されました」と表示されることを確認します。

数分後に画面を更新すると、リクエストを送信したモデルのステータスが [アクセスが付与されました] になります。

以上でStep3は完了です。

Step4. Self-hosted AI Gatewayを用意する

次に、Self-hosted AI Gatewayを用意します。
2025年4月8日現在、Self-hosted AI Gatewayはコンテナイメージでしか提供されていません。
今回はAWSのEC2にDocker Engineをインストールし、コンテナでSelf-hosted AI Gatewayを起動させます。

本章の作業の流れは以下の通りです。

対象のEC2インスタンスにDocker Engineをインストールします。
Self-hosted AI gatewayをコンテナとして起動させます。
Docker Engineのホストマシンで、ポート5052を空けます。

まず、Self-hosted AI Gatewayのコンテナを起動するEC2にSSHで接続し、Docker Engineをインストールしてください。
申し訳ないのですが具体的なDocker Engineのインストール手順は割愛致します。Dockerの公式ドキュメント (こちら) をご参照の上、Docker Engineをインストールなさってください。
参考 : Install | Docker Docs

Docker Engineのインストールが終わったら、さっそくSelf-hosted AI Gatewayをコンテナで起動しましょう。コマンド書式は以下の通りです。

docker run -d -p 5052:5052 \
 -e AIGW_GITLAB_URL=https://<GitLabのFQDNまたはIPアドレス>/ \
 -e AIGW_GITLAB_API_URL=https://<GitLabのFQDNまたはIPアドレス>/api/v4/ \
 -e AWS_ACCESS_KEY_ID=<Amazon BedrockのLLMにアクセス可能なアクセスキー> \
 -e AWS_SECRET_ACCESS_KEY=<Amazon BedrockのLLMにアクセス可能なシークレットキー> \
 -e AWS_REGION_NAME=<利用するAmazon Bedrockのリージョン> \
 registry.gitlab.com/gitlab-org/modelops/applied-ml/code-suggestions/ai-assist/model-gateway:self-hosted-<GitLabと同バージョン文字列>

例えば、Step1で用意したGitLabのバージョンがv17.10.3-eeで、URLがhttps://gitlab-instance.sample.com、利用するBedrockのリージョンがap-northeast-1なら以下のようなコマンドとなります。

docker run -d -p 5052:5052 \
 -e AIGW_GITLAB_URL=https://gitlab-instance.sample.com/ \
 -e AIGW_GITLAB_API_URL=https://gitlab-instance.sample.com/api/v4/ \
 -e AWS_ACCESS_KEY_ID=ABCDEFGHIJKLMNOPQRST \
 -e AWS_SECRET_ACCESS_KEY=ABCDEFGHIJKLMN123456789abcdefghijklmnopq \
 -e AWS_REGION_NAME=ap-northeast-1 \
 registry.gitlab.com/gitlab-org/modelops/applied-ml/code-suggestions/ai-assist/model-gateway:self-hosted-v17.10.3-ee

コマンドdocker psを実行し、AI Gatewayのコンテナが起動していることと、AI Gatewayコンテナのポート5052がホストOSのポート5052とマッピングされていることを確認してください。以下は出力例です。

最後に、GitLabからAI Gatewayコンテナのポート5052に対する通信を許可します。適宜AWSのセキュリティグループのインバウンドルールを変更してください。

以上でStep4は完了です。

Step5. AI Gatewayに関するパラメーターをGitLabに設定する

Step1で用意したGitLabがStep4で起動したAI Gatewayを利用するように設定します。

本章の作業の流れは以下の通りです。

GitLabの設定ファイルgitlab.rbを編集し、その内容をGitLabに反映させます。
GUIの管理画面から、Self-hosted AI Gatewayを参照させる設定をします。

まず、GitLabをインストールしたEC2にSSHで接続し、GitLabの設定ファイル/etc/gitlab/gitlab.rbを編集します。(任意でバックアップを取得なさってください。)
任意の場所に以下の3行を追記します。

gitlab_rails['env'] = {
    'AI_GATEWAY_URL' => 'http://<AI Gatewayのコンテナを起動したEC2のFQDNかIPアドレス>:5052'
}

本ブログの構成の場合、GitLabとAI Gatewayコンテナは同じOS上にあるため、AI Gatewayのコンテナを起動したホストOSのFQDNは、GitLabがインストールされた仮想マシンのFQDN (例えばgitlab-instance.sample.comなど) と同じとなります。
本ブログと構成と異なる場合は適切な値を設定して下さい。

gitlab_rails['env'] = {
    'AI_GATEWAY_URL' => 'http://gitlab-instance.sample.com:5052'
}

ファイル/etc/gitlab/gitlab.rbに追記が完了したら、コマンドgitlab-ctl reconfigureを実行し、GitLabを再構成します。GUIでログインできるようになるまで結構時間がかかることがありますが、気長にお待ちください。

GitLabの再構成が終わったら、GitLabのGUIに管理者権限を有するユーザーでサインインし、画面左下の [管理者] をクリックします。

左のメニューから [GitLab Duo] を開き、[設定の変更] をクリックします。

[ローカルAIゲートウェイURL] のテキストボックスに、http://<Self-hosted AI Gatewayコンテナを起動したホストOSのFQDN or IP>:5052と入力します。

任意で [Self-hosted beta models and features] > [Use beta models and features in GitLab Duo Self-Hosted] のチェックボックスを有効にします。この項目を有効にすると、GitLab Duo Self-hostedのGAされていないベータ版機能を利用することができます。
このブログでは例として有効にしています。

[変更を保存] をクリックします。

「アプリケーション設定は正常に保存されました。」と表示されます。
なお、この時点でヘルスチェックが失敗していても、気にせず次のステップへ進んでください。

以上でStep5が完了です。

Step6. Amazon Bedrockで利用可能なLLMをGitLabに登録する

Step3でデプロイしたLLMをGitLabに登録します。

まずは管理者アカウントでGitLabのGUIからサインインし、画面右下の方にある [管理者] をクリックします。

左側のメニューから [GitLab Duoセルフホスト] を開き、画面右上の [セルフホストモデルの追加] をクリックします。

以下の表の通り設定します。

**表3. セルフホストモデルの設定**
設定項目	設定値
デプロイ名	任意の文字列を指定します。このブログでは`Amazon Bedrock Claude 3.5 Sonnet`と設定します。
プラットフォーム	プルダウンから`Amazon Bedrock`を選択します。
モデルファミリー	Amazon Bedrockで利用可能にしたLLMのファミリーを選択します。このブログでは`Claude 3`を選択します。
モデルの識別子	"bedrock/利用可能にしたモデルのID"の形式で設定します。モデルのIDについてはAWSのDocs (こちら) の一覧表に掲載されています。このブログでは`bedrock/anthropic.claude-3-5-sonnet-20240620-v1:0`と設定します。

参考 : Supported foundation models in Amazon Bedrock - Amazon Bedrock

[接続をテスト] をクリックします。
接続がうまく行くと画面上部に「セルフホストモデルへの接続に成功しました。」と表示されます。

接続が成功することを確認後、[セルフホストモデルの作成] をクリックします。

続けて、[AI搭載機能] タブを開きます。

AI支援を利用できる機能一覧が表示されます。
各機能の行の右側にプルダウンがあります。このプルダウンで登録済のセルフホストLLMを指定することができます。このブログでは例として、表示されているすべての機能について先ほど登録したセルフホストLLMを指定します。

続けて左のメニューの [GitLab Duo] を開きます。

[ヘルスチェックを実行する] をクリックし、すべての項目に緑のチェックが表示されていることを確認します。

これで、GitLab Duo Self-hosted を Amazon Bedrockで構成する全ての手順が完了しました。

ちょっとだけ補足事項

動作確認の前に補足事項を3つお伝えいたします。必要に応じてお読みください。

【補足①】GitLab Duoのヘルスチェックでエラーが出る

設定や構成次第では、GitLab Duoのヘルスチェックの2番目の項目で以下のエラーが表示されるケースがあります。

xxxxxxxの接続に失敗しました: URL is blocked: Requests to the local network are not allowed. ファイアウォールまたはプロキシサーバーを使用する場合は、このホストへのトラフィックを許可する必要があります。

ただ、このエラーが出た状態であってもGitLab Duo Self-hostedを問題なく使える状況になっているケースがあります。もし、設定が正しいにもかかわらずこのエラーが出ている場合は、いったん無視してDuoの各種機能が使えるかを確認いただければと存じます。

【補足②】IAMポリシーとIAMユーザーの用意

2025年4月8日現在、Self-hosted AI GatewayからAmazon BedrockにアクセスするにはAWSのアクセスキーとシークレットキーが必要です。この時に必要なポリシーについては、AWSのDocs (こちら) を参考になさってください。
参考 : Identity-based policy examples for Amazon Bedrock - Amazon Bedrock

参考までに、筆者がこの検証で利用したポリシーは以下の通りです。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "bedrock:InvokeModel",
                "bedrock:InvokeModelWithResponseStream"
            ],
            "Resource": "arn:aws:bedrock:ap-northeast-1::foundation-model/anthropic.claude-3-5-sonnet-20240620-v1:0"
        }
    ]
}

【補足③】Amazon Bedrockのモデル呼び出しのログ記録

Amazon Bedrockはモデルの呼び出しログを記録する設定が可能です。
AWSコンソールのAmazon Bedrockのページにて [Bedrock configurations] > [設定] を開き、[モデル呼び出しのログ記録] を有効にすると、S3やCloudWatch Logsにログを出力できます。

GitLab Duo Code Suggestionsを使って動作確認

実際にGitLab Duoを使って動作確認してみましょう。
動作確認はStep6でAmazon Bedrockを利用する設定にした機能にて実施してください。
このブログでは検証用のプロジェクト (リポジトリはREADMEのみ) を用意し、Web IDEでCode Suggestionsが使えることを確認します。

下準備としてまず、Self-hosted AI Gatewayのログを表示するようにします。
Self-hosted AI Gatewayコンテナが実行されているEC2上で、コマンドdocker logs --follow <AI gatewayのコンテナID>を実行します。これでSelf-hosted AI Gatewayコンテナのログ出力をフォローし続けます。
この画面はそのままにして、次の手順を進めてください。

GitLabのGUIにDuoのシートが割り当てられているユーザーでログインし、検証用のプロジェクトに移動します。このブログでは検証用としてプロジェクト "PRJ" を作成しました。
プロジェクトページの [編集] > [Web IDE] をクリックします。

別タブでWeb IDEが表示されるので、適当にファイルを作成してCode Suggestionsをお試しください。
ここでは例としてファイルtest.javaを作成し、コメントを入力してコードが提案されるかを確認しました。詳細は下のGIFをご覧ください。

コマンドdocker logs --follow <AI gatewayのコンテナID>を実行したターミナル画面を表示してください。
先ほどのチャットがSelf-hosted AI Gatewayを経由していれば、ログが出力されているはずです。以下の画像は出力例です。

また、もし前述【補足③】で紹介したAmazon Bedrockのモデル呼び出しログを有効にしている場合は、ログが出力されていることを確認してください。
下図はS3へのログ出力を有効にしていた場合に生成されたオブジェクトです。

うまく動作しないときに確認するところ

うまく動作しない場合、以下の点をご確認いただき切り分けていただければと存じます。

AI Gatewayコンテナの確認ポイント

AI Gatewayのコンテナが起動しているか。
AI GatewayのコンテナイメージのバージョンはGitLabと同じか。
5052でホストOSとポートマッピングされているか。
起動時の変数AIGW_GITLAB_URL, AIGW_GITLAB_API_URL, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_REGION_NAMEの設定値が正しいか。
AI Gatewayコンテナが起動するホストOSのポート5052に対して通信可能か。
コマンドcurl http://<AI GatewayコンテナのホストOSのFQDN or IP>:5052を実行したときに {"error":"No authorization header presented"} と表示されるか。
GitLab Duo機能を利用した時、コンテナのログに出力があるか。