はじめに

コーディングエージェント（Claude Codeなど）の全社普及を阻む最大の障壁は、「使えば費用がかかる」という従量課金制の心理的ハードルにあります。社内アンケートでも、コスト負担への懸念が利用を躊躇させる要因として挙がっていました。

利用者が個人・チーム単位でコスト負担を意識すると、試しに使ってみるという行動が起きません。こうした状況に対し、私たちのチームでは「技術本部が予算を一元保有し、利用者がコスト負担を意識せずにコーディングエージェントを試せる環境を提供する」という方針をとりました。

この環境を実現するために採用したのが、OSSのLLMプロキシサーバー「LiteLLM」です。本記事では、LiteLLMをAWS環境上に構築した構成と、設計上の判断を紹介します。

対象読者：
– 組織内でClaude Codeの試行環境を整備したいエンジニア・チームリーダー
– AWS（ECS / RDS / VPC）の基本的な知識がある方

なぜLiteLLMを選んだか

私たちの開発環境はAWSベースのクラウド基盤を使用しています。Claude Codeなどで生成AIを利用する際はAnthropic APIへ直接アクセスするのではなく、Amazon Bedrock経由で利用しています。Amazon Bedrock経由で利用する場合、各利用者がAWSアクセスキーを個別に設定するのが基本の利用方法です。しかし複数チームが利用する試行環境では、以下の要件を満たす必要がありました。

要件 内容
Amazon Bedrock対応 既存のAWS環境・セキュリティ方針と整合させたい
セルフホスト可能 情報資産保護の観点から、SaaSではなくセルフホストできる製品が必要
予算上限の設定 一定の利用量を超えたら利用を制限したい
コスト可視化 誰がどのモデルをどれだけ使ったか把握したい
チーム管理 チームごとに利用状況を集計して予算管理したい。ただし別チームの利用状況を参照できないよう分離したい
キー管理の簡素化 利用者ごとにAWSアクセスキーを払い出す運用を避けたい

AWSの標準機能でもコストの可視化や超過アラームの設定は可能ですが、超過時の自動遮断やチームごとの利用分離には対応できません。これらの要件を満たすOSSとして、Amazon Bedrock対応・MIT Licenseで実績のあるLiteLLMを採用しました。LiteLLMは企業への導入事例も増えており、AWS公式メディアでもその活用例が紹介されています。

アーキテクチャ全体像

構成の概要は以下の通りです。

利用者向けには、LiteLLMの仮想キーのみ渡せばよく、Amazon Bedrockに直接アクセスするときのように、IAMアクセスキーやシークレットアクセスキーを払い出す必要はありません。接続先と仮想キーを設定するのみで、LiteLLMの存在をほとんど意識せずに使うことができます（参考：API呼び出し例、Claude Code設定例）。

情報資産の保護に関する設計判断

複数チームが利用する共通のLiteLLM環境を運用するにあたり、「LLM利用時に流れる・保存される情報をどう保護するか」が設計上の核心になりました。この観点から、以下のような設計としました。

アクセス制限

社内ネットワークからのみ接続を許可

試行環境のエンドポイント（ALB）はパブリックサブネットに配置し、インターネット側からアクセス可能な構成ですが、ALBのセキュリティグループで社内IPアドレスからの接続のみを許可しています。AWS WAFによるIP制限も選択肢ですが、社内IPアドレスを管理するプレフィックスリストがすでに整備されていたため、WAFを新設せずにセキュリティグループのみで同等の制限を実現しました。

なお、プライベートサブネットにALBを配置しVPN経由にする構成も検討しましたが、VPNを含めるとアーキテクチャが複雑になるため今回は採用しませんでした。

VPC Endpoint経由でAmazon Bedrockに接続する

LiteLLMからAmazon Bedrockにリクエストを転送する経路について、VPC Endpoint（PrivateLink）経由でAmazon Bedrockに接続する構成を採用しました。これにより、LiteLLMからAmazon Bedrockへのリクエストはインターネットに出ず、AWSバックボーンネットワーク内で完結します。

保存データの保護

プロンプトをDBに残さない

LiteLLMはリクエストのメタデータ（誰が・いつ・どのモデルを・いくら使ったか）をDBに記録します。デフォルト設定（store_prompts_in_spend_logs: false）ではプロンプト・レスポンスの内容はDBには保存されません。

これを true にするとプロンプトがDBに保存され、管理UIのLogs画面から参照できる状態になります。複数プロジェクトの利用者が同じ環境を使う構成では、管理者権限を持つ利用者が他プロジェクトのプロンプトを閲覧できてしまうリスクがあります。そのため false（デフォルト）のまま使用しています。

ただし監査目的のログはLiteLLMのLogging機能で別途書き出せます。今回の構成ではAmazon S3に書き出すこととしました。

Amazon S3監査ログへのアクセスを制限する

S3に書き出したログにはプロンプト・レスポンスが含まれるため、アクセスを複数の観点で制限しています。

  • 社外からのアクセス：バケットポリシーでVPC外かつ社内IP以外からのアクセスをDeny
  • 社内ユーザーからのアクセス：S3の読み取り権限を持つユーザーを限定。日常的な管理作業を行う管理者ユーザーにはS3アクセス権限を付与しない
  • ECSコンテナからの読み取り：ECSタスクロールには s3:PutObject のみを付与。コンテナ内からログを読み取ることはできない

「管理上の必要から記録は残しつつ、利用者からは見えない」設計になっています。

ユーザー間の情報分離

今回の環境は複数のプロジェクトチームが1つのLiteLLMインスタンスを共有する構成です。そのため、あるチームのメンバーが別チームの利用状況やプロンプトを閲覧できてしまうリスクへの対処が必要です。

LiteLLMでは、ロールベースでユーザーのアクセス権を制御しています。一般ユーザー（internal_userロール）には自分自身の利用状況・コストを確認する権限しか付与されていないため、他のユーザーのデータを参照できません。このロールを付与しておくことでチーム間のデータ分離が可能です。

一方、チーム全体の利用状況確認については制約があります。Usage画面で自チーム全体の利用状況が確認できればよかったのですが、一般ユーザーの権限では他メンバーの利用状況は表示されませんでした。他メンバーも含めたチーム全体の管理操作・情報参照にはチーム管理者ロール（Team Admin）が必要なのですが、こちらはEnterpriseプランの機能となっており、今回は利用しませんでした。チームごとの利用状況の確認には、管理APIの実行など別の手段にて対応することとしています。

今回の設計の割り切り

Amazon ElastiCache（Redis）を省いてある

LiteLLMのベストプラクティスではAmazon ElastiCache（Redis）を推奨しています。ECSタスクを複数起動する場合、Redisがないとレートリミットのカウンターがタスク間で共有されず意図通りに機能しません。つまりRedisなし＝ECS単一タスク固定です。

今回省いた理由は、まず小さく始めることを優先したからです。試行環境の目的は「使えるかどうかを判断すること」であり、スケールアウトが必要になる規模に達する前に判断は得られると考えました。実際に100ユーザー同時接続（約1,200rpm）での負荷試験を実施したところ、ECSタスク（2 vCPU / 4 GB）のCPU使用率は最大約17%にとどまり、単一タスクでの運用に実用上の問題はないことを確認しています。

この点、日常的に大量のトークンを送るような実開発においては、最初からRedisを含む構成で構築したほうがよいでしょう。

今回の構成が向いているケース・向いていないケース

向いている 向いていない
規模 数十人規模の試行・評価 常時高負荷な本番運用
目的 「使えるか」を判断するための試行 SLAが必要なサービス提供
運用 管理者が1〜2名で運用 大規模なマルチテナント管理

まとめ

本記事では、「コスト負担を意識せずにコーディングエージェントを試せる環境」を実現するためにLiteLLMを採用した構成と設計判断を紹介しました。現時点では試行段階ですが、以下の環境を整備しています。

  • コスト管理：チームごとに予算上限を設定することで、試行フェーズとして十分機能する範囲でコストを制御
  • 情報保護：VPC Endpoint・S3アクセス制限などAWSの設定により、通信経路と保存データを保護
  • アクセス分離：LiteLLMのロールベースアクセス制御により、チーム間でのデータ参照を防止

同様の環境を整備されている方の参考になれば幸いです。