投稿者 投稿日: カテゴリー Claude
Claude CodeのGitLab連携とは、CIでMR対応を任せる機能です。
自社ECの受注連携バッチや、楽天RMS・Amazon SP-APIとつなぐスクリプトをGitLabで管理している開発チームなら、課題（Issue）に「@claude この不具合を直して」と書くだけで、Claudeが修正ブランチを作りマージリクエスト（MR）まで出す運用が組めるようになりました。Claude Codeの公式ドキュメントでは、この連携はベータ版で、GitLab社が保守していると明記されています。本記事は、EC支援19年・5,000社超の実績を持ち、AI導入支援は2023年から提供する株式会社オルセル（うるチカラ運営）の現場知見にもとづき、Claude CodeのGitLab CI/CD連携をEC開発に入れる5つのステップと、そのまま使えるプロンプト3本を解説します。
Claude CodeのGitLab連携で、EC開発の何が変わるのか
一番大きな変化は、AIの作業がすべてMRという「レビュー可能な単位」で上がってくる点です。Claude Code GitLab CI/CDの公式ドキュメント によると、Claudeは課題やMRのコメントで呼び出され、スレッドとリポジトリから文脈を集めてClaude Codeを実行し、結果をMRとして返します。変更は必ずMRを経由するため、レビュアーは差分を確認でき、既存の承認ルールもそのまま効きます。
できることとして公式に挙げられているのは5つです。課題の説明やコメントからMRを作成・更新する、性能の劣化を分析して改善案を出す、ブランチで機能を実装してMRを開く、テストやコメントで見つかった不具合を直す、追加のコメントに応じて修正を重ねる、の5つです。リポジトリ直下のCLAUDE.md（プロジェクトの規約をClaudeに伝えるファイル）を読んで、既存のコードの書き方に合わせる点も特徴です。
実行環境は自社のGitLab Runner（パイプラインのジョブを動かす実行機）です。各処理はネットワークとファイルシステムに厳しい制限をかけたコンテナで動き、書き込みは作業領域の範囲に絞られます。モデルの呼び出し先は、Claude API、Amazon Bedrock、Google Cloudの3つから選べるため、既存のクラウド契約やデータの保存地域の要件に合わせられます。
EC事業者の開発現場に当てはめると、効果が出やすいのは小さな改修の山です。送料計算の端数処理、在庫連携バッチのエラー処理、商品CSVの列追加、セール用のクーポン判定ロジックの修正など、仕様ははっきりしているのに手が回らない改修が、多くのチームの課題一覧に溜まっています。現場で繰り返し見るのは、こうした改修が繁忙期前に積み残され、年末商戦の直前に慌てて対応するパターンです。
Anthropic自身も、Claude Codeに日々のソフトウェア保守を任せ、388件のプルリクエストのうち46%がマージされたと報告しています。詳細は Claude Codeの日次保守388PRの論点 で整理しました。半分近くがそのまま採用され、残りは人間の判断で直すか見送る、という比率感は、EC開発に入れる際の期待値の目安になります。
ローカルでClaude Codeを使う場合との違いも押さえておきます。開発者が手元のパソコンで使う場合、作業の記録はその人の端末に残り、チームから見えにくくなります。GitLab連携では、誰が何を依頼し、Claudeが何を変更したかが課題とMRとパイプラインのログに残ります。開発を外部の制作会社と分担している店舗では、この「記録が残る」性質が、発注側の品質管理にも役立ちます。基本的な使い方は Claude CodeによるEC業務自動化の記事 でも整理しています。
Claude Code×GitLabを導入する5ステップ
導入は、APIキーの登録、ジョブの追加、権限の設定、呼び出し方法の決定、CLAUDE.mdの整備の5ステップで進めます。最初の2ステップだけなら、公式ドキュメントのクイックセットアップどおりに30分程度で試せます。
ステップ1：APIキーをマスク変数として登録する
GitLabのプロジェクトで「Settings」から「CI/CD」、「Variables」と進み、ANTHROPIC_API_KEY をマスク付きの変数として追加します。保護ブランチだけで使う場合は保護設定も付けます。公式ドキュメントは、APIキーやクラウドの認証情報をリポジトリにコミットしないよう強く注意しています。本番運用では、Amazon BedrockならGitLabをOIDC（短期トークンで認証する仕組み）のIDプロバイダとして設定し、Google CloudならWorkload Identity Federationを使うと、長期間有効な鍵を置かずに済みます。
ステップ2：.gitlab-ci.ymlにClaudeのジョブを追加する
.gitlab-ci.yml に、Claude Code専用のステージとジョブを1つ追加します。公式の例では、Node.jsのコンテナイメージにClaude Codeをインストールし、claude -p で指示を渡して実行します。実行時のオプションとして、編集を自動承認する --permission-mode acceptEdits と、使えるツールを絞る --allowedTools が指定されています。ジョブを動かす条件は、手動実行とMRのイベントから始めるのが無難です。
公式の例では、パイプラインの起動元が画面からの手動実行（web）か、MRのイベント（merge_request_event）のときだけジョブが動くように条件を書いています。最初からすべてのプッシュで動かすと、意図しない実行でRunnerの時間とAPI利用料を消費します。ジョブにはGitLabの timeout で30分などの上限を付け、claude コマンドには --max-turns でやり取りの上限を渡しておくと、想定外の長時間実行を防げます。動作確認は「CI/CD」の「Pipelines」から手動で1回動かし、ジョブのログでClaudeが何を読み、何を変更したかを確かめるところから始めます。
ステップ3：GitLab APIの権限を決める
ClaudeがMRを開いたりコメントを書いたりするには、GitLab APIへの書き込み権限が必要です。既定では CI_JOB_TOKEN を使い、足りない場合は api スコープのプロジェクトアクセストークンを作って GITLAB_ACCESS_TOKEN としてマスク登録します。権限は必要最小限に絞り、決済や顧客データを扱うリポジトリでは、Claude用のジョブを動かす対象ブランチを限定しておくのが定石です。
ステップ4：@claudeでの呼び出し方を決める
課題やMRのコメントに @claude と書いて呼び出したい場合は、プロジェクトのWebhookで「Comments（notes）」のイベントを受け取る仕組みを用意し、コメントに @claude が含まれていたらパイプラインのトリガーAPIを呼ぶ形にします。このとき指示内容を AI_FLOW_INPUT、文脈を AI_FLOW_CONTEXT という変数で渡します。公式のトラブルシューティングにあるとおり、/claude ではなく @claude と書く点を、チーム内で周知しておきます。
Webhookの受け口を用意するのが難しい小規模なチームは、最初は手動実行だけで運用しても十分です。パイプラインを手動で起動する画面で変数を指定できるため、AI_FLOW_INPUT に依頼内容を書いて実行すれば、コメント起動と同じように指示を渡せます。週に数回の利用であれば、この方法でも手間はほとんど変わりません。呼び出しの回数が増え、依頼者が開発者以外にも広がった段階で、コメント起動の仕組みを整えれば遅くありません。
ステップ5：CLAUDE.mdにEC固有のルールを書く
最後に、リポジトリ直下にCLAUDE.mdを置きます。ここに書いた規約は、ジョブ実行時にClaudeが読み込みます。EC開発では、金額計算の丸め方、消費税の扱い、在庫数を減らす処理の排他制御、個人情報をログに出さないルール、モールAPIの呼び出し回数制限への配慮などを明文化しておくと、レビューで指摘する回数が目に見えて減ります。CLAUDE.mdは長すぎると逆効果になるため、公式ドキュメントも簡潔に保つよう勧めています。
EC開発で使えるプロンプト3本
ここからは、導入後すぐに使えるプロンプトを3本紹介します。プロンプト1はChatGPT・Claude・GeminiのどれでCLAUDE.mdの下書きを作る用途、プロンプト2と3はGitLabのコメント欄で @claude に渡す指示文です。
プロンプト1は、EC開発向けのCLAUDE.mdを短時間で下書きするためのものです。リポジトリの概要を書き込んで、汎用チャットAIに投げてください。
プロンプト1：EC開発リポジトリ用CLAUDE.mdの下書き
あなたはEC企業の開発リーダーです。
以下のリポジトリ情報をもとに、Claude Codeが読むCLAUDE.mdの下書きを作成してください。
条件：
1. 全体で60行以内に収める
2. 「コーディング規約」「金額・税・在庫の扱い」「個人情報とログ」「外部API（楽天RMS・Amazon SP-API・Shopify）の呼び出しルール」「テストの書き方」「MRの説明文の書き方」の6見出しで構成する
3. 金額は整数（円）で扱い、端数処理の方法を明記する
4. 顧客の氏名・住所・電話番号・メールアドレスをログやテストデータに含めないルールを入れる
5. 判断がつかない仕様は実装せず、MRの説明に質問として残すよう指示する
リポジトリ情報：
- 言語・フレームワーク：{例 Python 3.12 / Django}
- 主な機能：{例 受注取り込み、在庫連携、送料計算}
- 連携先：{例 楽天RMS API、ネクストエンジン}
- テスト：{例 pytest、カバレッジ目標80%}
プロンプト2は、MRのレビューを頼むときのコメントです。汎用的な「レビューして」ではなく、EC特有の事故が起きやすい観点を指定すると、指摘の質が上がります。
プロンプト2：EC観点でのMRレビュー依頼（MRのコメント欄に投稿）
@claude このMRを、次の5観点でレビューしてください。
1. 金額計算：税込・税抜の混在、端数処理、送料無料条件の境界値（ちょうど{金額}円のとき）
2. 在庫：同時注文時に在庫がマイナスにならないか、在庫連携の失敗時に再試行されるか
3. 個人情報：顧客情報がログ、例外メッセージ、テストデータに出ていないか
4. 外部API：楽天RMSやAmazon SP-APIの呼び出し回数制限を超える処理がないか
5. 既存仕様との整合：CLAUDE.mdのルールに反する箇所がないか
問題が見つかった箇所は、該当行と修正案をコメントで示してください。修正が必要な場合は、このMRのブランチに修正コミットを追加してください。判断に迷う箇所は修正せず、質問として残してください。
プロンプト3は、課題（Issue）から実装を任せるときのコメントです。完了条件とテストを明示しておくと、手戻りが減ります。
プロンプト3：課題からの実装依頼（Issueのコメント欄に投稿）
@claude この課題の内容を実装して、MRを作成してください。
完了条件：
- {例 北海道・沖縄・離島への送料を、商品重量に応じて{金額}円加算する}
- 既存の送料計算のテストがすべて通ること
- 新しい条件の境界値（{例 重量2kgちょうど}）のテストを追加すること
制約：
- 変更は {例 shipping/} ディレクトリの中に限定する
- 新しいライブラリは追加しない
- MRの説明に、変更点、テスト結果、確認してほしい点を箇条書きで書く
3本とも、{ } の部分を自社の仕様に置き換えて使います。プロンプト2と3はGitLabのコメント欄にそのまま貼れる形にしてあります。よく使う依頼文は、GitLabの課題テンプレートやコメントの定型文として登録しておくと、担当者ごとの書き方のばらつきが減り、Claudeの出力も安定します。
失敗例と回避策
1つ目の失敗は、権限を広げすぎることです。動作確認を急ぐあまり、強い権限のトークンを全ブランチで使えるようにすると、意図しない変更が保護されていない場所に入るリスクが高まります。公式ドキュメントも、ジョブの権限とネットワークの外向き通信を制限するよう勧めています。うるチカラでは、Claude Codeが リポジトリに隠されたマルウェアを検証なしで実行した事例 も取り上げました。外部から取り込んだコードを含むリポジトリでは、Claudeのジョブを動かす範囲を慎重に決めてください。
2つ目は、ClaudeのMRを「AIが作ったから」と軽く通すことです。公式ドキュメントには、ClaudeのMRも他の開発者と同じようにレビューするよう明記されています。ある食品ジャンルの中規模店舗の事例では、送料計算の改修で境界値のテストが抜けたまま本番に出しかけ、レビューで差し戻したことがありました。金額や在庫に関わる変更は、人間のレビュアーを必ず1人以上つける運用にします。
3つ目は、費用の上限を決めずに動かすことです。公式ドキュメントは、GitLab Runnerの計算時間とAPIのトークン消費の両方に費用がかかると説明しています。回避策として、--max-turns でやり取りの回数を、ジョブの timeout で実行時間の上限を決め、同時実行数も絞ります。最初の1か月は呼び出し回数を記録し、実際の消費を見てから予算を固めるのが安全です。
4つ目は、CLAUDE.mdに何でも書き込みすぎることです。指摘を受けるたびにルールを足していくと、数百行に膨らみ、肝心の金額計算や個人情報のルールが埋もれます。楽天/Amazonの両方を回している店舗で観測されたのは、モールごとの細かな仕様までCLAUDE.mdに詰め込んだ結果、Claudeが関係のない規約を参照して不要な変更を加えるケースでした。全体のルールはCLAUDE.mdに短くまとめ、モール別の仕様はディレクトリごとの説明ファイルや課題の説明に分けて書くと整理しやすくなります。
KPI設計と費用・工数目安
KPIは「MRのリードタイム」「レビューの往復回数」「ClaudeのMRの採用率」の3つで追います。リードタイムは課題の作成からマージまでの日数で、導入前の数字を2〜4週間分記録しておくと比較できます。採用率は、Claudeが出したMRのうちマージされた割合です。Anthropicの社内保守で46%という数字が出ていることを踏まえると、最初は3〜5割を一つの目安にするのが現実的でしょう。
工数の目安は、クイックセットアップでの試行が30分〜1時間、権限設計とWebhookによる @claude 呼び出しの整備で1〜2日、CLAUDE.mdの作成と調整に半日程度です。直近の支援案件で観測したのは、CLAUDE.mdを書いた直後より、2〜3週間運用して指摘の多かった点を書き足した後のほうが、明らかにレビューの往復が減るという傾向でした。
費用は、GitLab側のRunnerの計算時間と、AnthropicのAPI利用料の2本立てです。Runnerの無料枠や単価はGitLabの契約プランによって異なり、API利用料はモデルと処理するコードの量で変わります（2026年11月時点、具体額は各社の料金ページで要確認）。Claude Codeを対話的に使う開発者個人の契約（Claude Proは月20ドルなど）と、CI/CDで使うAPIキーの課金は別になる点にも注意してください。
記録の方法はシンプルで構いません。ClaudeのMRには共通のラベルを付けるよう運用ルールを決めておけば、GitLabの画面でラベル絞り込みをするだけで件数、マージ数、クローズ数を数えられます。月末に、採用率、平均リードタイム、レビューで差し戻した理由の上位3つを振り返り、差し戻し理由をCLAUDE.mdや課題テンプレートの改善につなげます。このサイクルを3か月回すと、どの種類の改修を任せればよいかがチームの中で共有されます。
今後の展望と独自考察
Claude CodeのGitLab連携は、AIに開発を任せる単位が「チャットでの相談」から「パイプラインのジョブ」へ移る流れの一部です。ジョブとして動く以上、ログが残り、権限が管理され、承認フローに乗ります。EC事業者のように開発を外部パートナーと分担している企業ほど、この「記録と承認に乗るAI」の価値は大きくなります。
Anthropicの公式ブログでは楽天グループによるClaude Codeの開発活用も紹介されており、うるチカラでは 楽天のClaude Code活用事例 を紹介しました。大手ほど、セキュリティとガバナンスを満たした形でAIを開発プロセスに組み込む方向に進んでいます。中小のEC事業者にとっても、GitLabやGitHubのような既存の開発基盤に乗せられるかどうかが、AI開発ツールを選ぶ際の重要な判断軸になっていきます。
一方で、ベータ版である点は忘れないでください。機能や設定方法は今後変わる可能性があり、公式ドキュメントも利用するバージョンによってオプションが異なると注記しています。社内の手順書には参照したドキュメントの日付を残し、四半期に1回は見直す運用をおすすめします。複数の作業をまとめて社内に配る方法は Claude Codeのプラグインで業務を標準化する記事 も参考になります。
よくある質問
Claude CodeのGitLab連携は無料で使えますか？
いいえ、連携機能自体の設定に追加費用はありませんが、実行にはGitLab Runnerの計算時間とClaudeのAPI利用料がかかります。Runnerの無料枠はGitLabの契約プランによって異なります。最初は手動実行に限定して、1か月分の消費を確認してから本格運用に移るのが安全です。
GitHubではなくGitLabでも同じことができますか？
はい、GitLab CI/CD向けの連携が公式ドキュメントで案内されています。課題やMRのコメントで @claude と呼び出し、MRとして結果を受け取る流れは共通です。ただしGitLab版はベータ版で、GitLab社が保守している点が異なります。
セルフマネージド版のGitLabでも使えますか？
公式ドキュメントの設定例では、OIDCの対象として自社のGitLabインスタンスのURLを指定する形が示されており、自社運用のGitLabを想定した構成も読み取れます。ただし、ネットワーク構成やRunnerの設定によって必要な作業が変わるため、自社環境での動作確認は要確認です。
顧客データを含むリポジトリで使っても大丈夫ですか？
リポジトリに顧客データそのものを置かない運用が前提です。テストデータは架空の値にし、CLAUDE.mdで個人情報をログやテストに含めないルールを明記します。データの保存地域に要件がある場合は、Amazon BedrockやGoogle Cloudの地域指定で対応できるかを確認してください。
ClaudeのMRはそのままマージしてよいですか？
いいえ、人間のレビューを通してからマージしてください。公式ドキュメントも、ClaudeのMRを他の開発者と同じようにレビューするよう求めています。特に金額計算、在庫、決済に関わる変更は、必ず担当者が確認します。
どんな改修から任せるのがよいですか？
仕様がはっきりしていて、テストで正しさを確かめられる小さな改修から始めるのがおすすめです。送料計算の条件追加、CSVの列追加、エラーメッセージの修正などが向いています。仕様の判断が必要な改修は、Claudeに実装させる前に課題の説明を具体化しておきます。
テストがほとんど無いリポジトリでも使えますか？
はい、使えますが、最初の依頼は実装ではなくテストの追加にするのがおすすめです。テストが無い状態でClaudeに改修を任せると、変更が既存の動作を壊していないかをレビューだけで判断することになり、見落としが増えます。送料計算や税計算のように金額に関わる処理から先にテストを整えておくと、その後の改修を安心して任せられるようになります。
参考文献
- Claude Code公式ドキュメント：Claude Code GitLab CI/CD
- GitLab：Claude Code連携のサポートIssue
- Claude Code公式ドキュメント：Agent SDK overview
- Anthropic：Claude APIの料金
著者：齋藤竹紘（株式会社オルセル 編集長／5,000社以上のEC支援実績／書籍3冊）
※うるチカラでは、生成AIの導入支援から運用最適化まで、貴社のEC事業に合わせたカスタマイズ提案を行っています。無料相談（30分）も実施中ですので、お気軽にお問い合わせください。
https://uruchikara.jp/contact/
【監修】齋藤竹紘（株式会社オルセル代表 / 19年・5,000社のEC支援実績）
株式会社オルセル代表取締役 / うるチカラ編集長。19年・5,000社以上のEC支援実績を持ち、楽天市場・Amazon・Yahoo!ショッピング・Shopify・Shopee越境ECの実装ノウハウを保有。AI×ECに関する書籍を3冊執筆。「現場で使えるAI実装」を一次情報として発信しています。
この記事を読んだ人は、こんな記事も読んでいます
