Claude Code Github Actions x LiteLLM Gateway x BedrockでCICDにAIを組み込んだ話

この記事はHTアドベントカレンダー24日目の記事です。

はじめに

こんにちは、博報堂テクノロジーズの森田です。
私の担当するプロジェクトではクラウドにAWSを採用しており、コーディングにはClaude Codeを取り入れています。サブスクリプションとBedrockを組み合わせて採用しているのですが、Bedrockの方は青天井に使われてしまうのは怖く、リアルタイムにトークン使用量を確認したいのとユーザやクライアント毎にトークン利用上限を設けたいという要件があり、LLM Gatewayの導入に至りました。

本記事では、Claude Code GitHub ActionsとLiteLLM Proxy、Bedrockを組み合わせてCI/CDにAIを組み込んだ構成と、その過程で得た知見を共有します。

尚、この記事はClaude:人が2:8くらいで書いています。

LLM Gatewayの選定

LLM Gatewayの候補としてはLiteLLM Proxy、Portkeyなどがありましたが、最もメジャーかつClaudeの公式ドキュメントにも記載があることからLiteLLM Proxyを採用しました。

今回はワークロード向けではなく開発用途であるため、高い信頼性は必要なく、ある程度ストレスなくClaude Codeから使えれば十分でした。プロジェクトの人数的にも使う可能性があるのは5名ほどでした。そのため、エンタープライズ版ではなくOSS版を採用し、コストを抑えるためにEC2(サイズはt3.medium)上にDocker Composeでホストする構成としました。

アーキテクチャ概要

ネットワーク構成

プロジェクト内の開発者からのアクセスについては自社のIPアドレスに限定できるので、LiteLLM Proxyの前段にあるSecurity Groupで制限できます。しかし、GitHub ActionsのGitHub Hosted Runnerからも利用できるようにする必要がありました。

選択肢として以下を検討しました：

• Self Hosted RunnerからアクセスさせてIPアドレス制限に加える
• HTTPヘッダーに独自の認証用の値をもたせる

今回はすぐに利用したかったので、設定が簡易に済む後者を選択しました。AWS WAFを使って「IPアドレスの条件を満たしている」または「特定の認証ヘッダーが付与されている」場合にアクセスを許可する設定をしました。

LiteLLM Proxyの設定

モデルの登録

各モデルはLiteLLM Proxy GUI上から設定しています。下記画面イメージです。

運用を始めてからHaiku 4.5やOpus 4.5などが出てきましたが、再起動なくあとから追加できるようになっています。Bedrock上ではglobal.anthropic.claude-sonnet-4-5-20250929-v1:0といったモデル名ですが、Claude Codeからはclaude-sonnet-4-5-20250929 といったモデル名でリクエストすることになるので、このLitellm Proxy上で変換して上げる必要があります。なお、モデル名の指定はクライアント側の環境変数(ANTHROPIC_DEFAULT_SONNET_MODELなど)で変換する方法もあるみたいです。

Prometheusへのメトリクス連携

誰がどれくらい使っているかをGrafanaダッシュボードで可視化したかったので、公式ドキュメントに従ってセットアップしてみました。しかし、実際に取得できるメトリクスを確認したところ、目当てのものは取得できず下記のようなメッセージが出力されていました。

# HELP litellm_not_a_premium_user_metric_total 🚨🚨🚨 Prometheus Metrics is on LiteLLM Enterprise. 🚨 You must be a LiteLLM Enterprise user to use this feature. If you have a license please set `LITELLM_LICENSE` in your env. Get a 7 day trial key here: https://www.litellm.ai/enterprise#trial. \nPricing: https://www.litellm.ai/#pricing

とりあえず、LiteLLM Proxy上のダッシュボードでも確認はできるので、深追いはせずGrafanaでの可視化は諦めました。

GitHub Actionsの設定

claude-code-actionの導入

claude-code-actionはClaude Codeのスラッシュコマンド/install-github-appから導入しました。v1になる前に導入していたのですが、v1で大幅に変わったのでメジャーバージョンになった際に入れ直しました。

環境変数の設定

公式ドキュメントを参考に、以下の環境変数をGitHub ActionのVariablesとSecretsに設定します：

• ANTHROPIC_BASE_URL: LiteLLM ProxyのエンドポイントURL
• ANTHROPIC_API_KEY: LiteLLM Proxyで発行したAPIキー
• ANTHROPIC_CUSTOM_HEADERS: AWS WAFで検証するカスタム認証ヘッダー

MCPの活用

私の担当は主にインフラ関連になりますので、便利なawslabsのMCPをいくつか導入しています。

• aws-pricing-mcp-server: AWSの料金情報を参照
• terraform-mcp-server: Terraformのプラクティス参照やセキュリティチェックなど
• aws-knowledge: AWSドキュメントの参照

Github Actions上で使うためにclaude_args: --allowedToolsで必要なツールを個別に指定していきます。

# オプション指定サンプル
claude_args: "--allowedTool 'smcp__aws-terraform__SearchUserProvidedModule,mcp__aws-terraform__SearchAwsProviderDocs'"

モデルの使い分け

デフォルトの@claude以外に、@claude-haiku、@claude-opusといったメンションに反応して対応するモデルで動作するようにカスタムしています。

• Haiku: 簡単な修正など
• Opus: コードレビューなど品質が求められる場面

運用してみての所感

PRレビューについて

AIによるレビューは任意のタイミングで発動させたかったのでPRの自動レビューはフローから外しました。

代わりにカスタムコマンドを用意して、ユーザからのメンションに反応してレビューさせる方式に切り替えました。イメージとしては @claude /code-review という感じです。

現在抱えている課題

IssueやPR上からClaude Codeを使うのは2025年9-10月あたりはある程度安定して動作していたのですが、11月くらいから徐々にエラー（Process completed with exit code 1.）が発生するようになりました。

発生条件は特定できていないのですが、状況的に類似のIssueを発見し、まだ解決に至っていません。同じ指示でリトライしたり、指示を具体的にしたりすると通ることもありますが、条件は不明です。どうしても通らない場合はローカルのClaude Codeで対応しています。

コストについて

トークン使用量だけでいうと月額数十ドル程度で済んでいます。EC2やALBなどの料金は別途かかっています。
ちょっとした変更やドキュメントの整備などライトな作業はClaude Code Github Actionsだけで完結することもありますが、基本変更量の大きいものはClaude Codeのサブスクリプションプランの方で対応することが多いので、こちら側にはあまりお金がかかっていない感じになっています。

LiteLLM Proxy上のグラフ。直近1ヶ月は$30くらいでした。

運用の手間

運用的には新しいモデルが追加されるたびにLiteLLM Proxy上で登録をするくらいなのですが、導入したばかりのころは接続がうまく行かないなどトラブルシュート対応が必要だったりしました。導入当初はLiteLLMの公式ドキュメント上の情報だけでは解決せず、Github上のソースを調べたりと時間を要することが多かったです。また、問題が発生した時にクライアント側、LiteLLM Proxy、Bedrockのどこの問題なのかを判断するところから始めなければならずこの部分も時間を要したポイントです。

ローカルとClaude Code Github Actionsをどのように使い分けているか

Security Groupのちょっとした変更とか、スケール調整とかすごく簡単な依頼と変更の総合的なレビューをClaude Code Github Actionsに委ねています。上記の通り、処理失敗することもあったり、そもそもタスクが完了するまでの時間もちょっとかかったりで、それがストレスになることもあるのである程度の大きさ、あるいは複雑なタスクはローカルのClaude Codeで対応することが最近多いです（エラーが出るようになってからは最初からローカルを使う比率が増えて来た気がします）。このあたりはGithub Actions周りの環境を改善 + Claude Code Github Actionsがもっと成熟してくると変わる気がしています。

まとめ

Claude Code GitHub Actions × LiteLLM Proxy × Bedrockの構成でCI/CDにAIを組み込むことができました。青天井利用の恐怖からは脱出できたので導入して良かったと思いました。

CI/CDにAIを組み込むことでIssue対応やドキュメント生成などの開発作業を効率化できるので非常にオススメです。LiteLLM Proxyはいきなり大規模に導入するにはちょっと辛いなというイメージではありますが、今回くらいの規模であれば特に問題なく運用できると思いました。Bedrock側にユーザ毎のトークン上限設定機能が来てくれればお役御免になるのですが、それまでは運用を続けようと思います。
同様の構成を検討している方の参考になれば幸いです。