NTTドコモR&Dの技術ブログです。

トップ > クラウド > 開発チームにVibe Coding環境を。LiteLLMとGoogle Cloudで実現したコスト管理基盤の構築事例

開発チームにVibe Coding環境を。LiteLLMとGoogle Cloudで実現したコスト管理基盤の構築事例

クラウド アドベントカレンダー2025 生成AI

はじめに

NTTドコモデータプラットフォーム部（以下DP部）黒須です。 2025年12月現在、社内データ活用プラットフォームPochiの運用開始から2年以上経過し、130名を超える開発者がアプリの開発をしています。 現在プラットフォーム運営チームでは、生産性・品質向上のために、開発者に向けてVibe Coding環境を展開しています。 展開を進めるにあたり、コスト管理の観点から「誰が」「どれくらい」利用したのかを把握できる環境の構築が課題となりました。 本記事では、LiteLLMを用いてコスト管理基盤を実現した事例をご紹介します。 以降の詳細部分については、NTTデータの業務委託先メンバーである兼子さん・松苗さんに執筆協力いただきました。

writer: NTTデータ テクノロジーコンサルティング事業部 兼子・松苗

社内データ活用プラットフォームPochi※1とは

私たちDP部は社内のデータ民主化を目指し、StreamlitとGoogle Cloudで圧倒的に使いやすいデータ活用プラットフォームを開発・推進しています。このプラットフォームは、24年度は30万時間もの業務効率化を実現し、直近では5,000人以上の社員に利用が拡大しています。

ASCII.jp：NTTドコモ、Streamlit利用の“ポチポチ分析アプリ”開発で社内データ活用を促進 (1/3)

※1: Pochiは社内の開発コードネームです

想定する読者

  • 開発チームにVibe Coding環境を提供したい方
  • Google Cloud環境でのVibe Codingコスト管理に興味がある方

1. 背景

1.1 Vibe Codingとは

Vibe Codingとは、LLMを活用したAI開発支援ツールを用いて、自然言語でのプロンプト入力を通じてコーディングを行う開発手法です。 従来のIDEが提供してきたコード補完等の開発支援範囲を超えて、コード生成、リファクタリング、バグ修正、テスト作成など、開発プロセス全般をAIが支援します。

「初心者がVibe Codingでアプリを作ってみた」といった記事も多く見かけるようになり、AI開発支援ツールは開発者にとってなくてはならない存在となった、と言えるでしょう。

1.2 全アプリ開発者へのVibe Coding環境展開

アプリ開発者の開発効率と品質の向上を目的として、運営チームや数名の開発者の間では、VSCode拡張機能であるClineの試験的な導入が既に進んでいました。 Clineは、自然言語でのプロンプト入力により、コード生成やリファクタリング、バグ修正などを支援してくれる強力なAI開発支援ツールです。

この試験導入で得られた好評なフィードバックを受け、全開発者への展開を進めていくことになりました。 その際、展開を推進するチームとは別に、我々プラットフォーム運営チームは、セキュリティやコスト管理といった部分を主に検討していました。

1.3 コスト管理の課題

Clineの展開検討を進める中で、コスト管理の課題に直面しました。

Vibe Codingツールは高度な開発支援を提供する反面、その性質上、大量のトークンを消費します。 これは、ユーザーが入力するプロンプトだけでなく、以下のような情報もリクエストに含まれるためです：

  • 対象ファイルの内容: 編集対象のファイルや、ユーザーが明示的に指定したファイルの内容
  • 関連ファイルの内容: Clineが自動的に判断した関連ファイルの内容（インポート先のモジュール、参照されているクラス定義など）
  • 会話履歴: 同一セッション内での過去のやり取り

例えば、「この関数をリファクタリングして」という短いプロンプトにもかかわらず、数万トークンを消費することも実際には珍しくありません。 このような特性から、「特定の開発者がトークンを使いすぎて、いつのまにかコストが肥大化していた……」といったことが起こりうるため、開発者単位での適切なコスト管理が求められます。

当初、ClineからVertex AIのLLMモデルエンドポイントを直接利用する構成を検討していました。 しかし、Clineはリクエストヘッダーを自由にカスタマイズできない仕様となっており、利用者を識別する情報をリクエストに含めることができません。 そのため、この構成では「プロジェクト単位でのコスト確認は可能だが、個別の開発者を識別できない」という制約があります。

こうして、開発者単位でコストを確認できる仕組みの構築が、Vibe Coding環境提供に向けた課題となりました。

2. LiteLLMの導入による開発者単位のコスト管理

2.1 LiteLLMの導入

この課題を解決するために注目したサービスがLiteLLMです。 LiteLLMは、LLM推論エンドポイントまでのプロキシとして配置できるOSSで、以下のような特徴があります：

  • ログ管理: リクエストごとにログを記録
  • コスト把握: トークン使用量とコストをユーザ・APIキー別に確認可能
  • 予算制限: 予算上限を設定し、超過時には自動的にリクエストを拒否

こういった機能により、開発者ごとに発行したAPIキーを通じて、開発者個別の利用状況とコストを正確に把握できると判断しました。 また、LiteLLMはClineから公式にサポートされており連携が容易です。

これらの理由から、Vibe Codingコスト管理のためのサービスにLiteLLMを選定しました。

2.2 全体構成

構築した環境は以下の通りです。

この環境は、以下の要素で構成されています：

  • Cloud Workstations: 開発者が利用する統合開発環境
  • Cline (VSCode拡張機能): 開発者が利用するAI開発支援ツール
  • LiteLLM (Cloud Run): LLMリクエストの中継とコスト管理を担うゲートウェイ
  • Cloud SQL (PostgreSQL): LiteLLMの利用ログ、コスト情報、APIキー管理などのデータを管理
  • Vertex AI: Google CloudのAI開発プラットフォーム
  • Load Balancer: IAP認証により、LiteLLM Web UIへの安全なアクセスを提供

この構成の核となるのは、ClineとVertex AIの間に配置したLiteLLMです。 LiteLLMをプロキシとして挟むことで、ClineからVertexAIへのリクエストを中継し、その過程でコスト情報やログを記録することができました。

今回の構成では、インフラ管理の手間を最小限に抑えるため、Cloud RunとCloud SQLをリソースとして選定しています。

Cloud Runはサーバレスなコンテナベースコンピューティングサービスであり、スケーリングは自動で行われ、利用量に応じた課金であるため、コストを最適化することができます。 さらに、Dockerベースで簡単にセルフホスト可能なLiteLLMとの相性が優れています。 （参考：LiteLLM AI Gateway - Setup & Deployment）

Cloud SQLはGoogleマネージドなデータベースサービスであり、バックアップ・パッチ適用などが自動なため、運用負荷を抑えることが可能です。

また、Cloud RunからはサーバレスVPCコネクトで、Cloud SQLからはプライベートサービスアクセスで自社プロジェクト管理のVPCに接続しています。 これにより外部IPアドレスを必要とせず、内部IPアドレス用いた安全な通信を実現しました。

2.3 Clineからの処理フロー

開発者がClineを利用する際の処理フローは以下となります。

  1. 開発者がClineの設定画面にAPIキーを設定し、プロンプトを入力（ex. ○○関数を実装して）

  2. ClineからLiteLLMへリクエスト送信

  3. LiteLLMからVertex AIへリクエスト転送

  4. Vertex AIからLiteLLMへレスポンス返却

  5. LiteLLMからClineへレスポンス転送

この一連の流れにより、LiteLLMではリクエスト単位でログ・コストが記録されます。 つまり、開発者目線では通常のCline利用とほぼ変わらない使い勝手を保ちながら、APIキー・開発者単位でのコスト管理を実現することができます。

2.4 管理UIによるコスト可視化

LiteLLMは管理用のWeb UIを提供しており、今回の構成ではロードバランサを通してアクセスすることができます。 このWeb UIを通じて、運営チームだけでなく開発者自身も利用状況やコストの確認が可能です。（下図）

/figcaption>

画像引用元：LiteLLM AI Gateway - Admin UI

2.4.1 開発者自身による確認

各開発者は、後述するセルフサービスアプリケーション（3章）を通じて、LiteLLM上に自身のアカウントを作成します。 作成したアカウントでLiteLLMのUIにログインすることで、自身の利用状況に関する以下の機能を利用できます：

  • 日別のリクエスト数・トークン数・コスト可視化
  • リクエスト単位でのログ確認

開発者自身が自身の利用状況を把握できることで、コスト意識を持ちながらツールを活用してもらうことができます。

2.4.2 運営チームによる全体管理

運営チームは、管理者アカウントでログインすることで、以下をはじめとする管理機能を利用できます：

  • 開発者全体でのトークン数・コスト可視化
  • 開発者別のコスト確認
  • 全体/開発者別の予算上限設定

これによりコストを定常的に把握しつつ、予想外に増加した場合も原因を迅速に特定し、適切な対応策を講じることができます。

3. APIキー払い出しのセルフサービス化

LiteLLMを導入するにあたり、もう一つ考慮すべき点がありました。 それは、各開発者にAPIキーを個別に払い出す運用負荷です。

通常の払い出し方法では、開発者からの依頼を受けて運営担当者がユーザーとAPIキーを作成し、通知するという手順が必要でした。 今後100人以上の開発者に展開していくことを考えると、この手作業は大きな運用負荷となります。

この課題を解決するため、開発者が自分自身でAPIキーを取得できるAPIキー払い出しアプリをStreamlitで作成し、Cloud Run上にデプロイしました。 構成図を以下に示します。

LiteLLMでは、Web UIでの操作だけでなく管理APIを用いた操作が可能です。 このアプリケーションでは、LiteLLMの管理APIを使用して、以下の流れでAPIキーを払い出します：

1.ユーザ情報取得：IAP認証情報から、アクセスユーザのメールアドレスを取得（参照：署名済みヘッダーによるアプリの保護） 2.ユーザ・APIキー作成：アクセスしたユーザのメールアドレスをもとに、LiteLLM上にユーザアカウントとAPIキーを作成

# ユーザとユーザに紐づくAPIキーを作成する
def create_user(email,role="internal_user_viewer",teams=None):
    user_id = None
    key = None
    data = {
        "user_email": email,
        "user_role": role,
        "key_alias": email
    }
    if teams:
        data["teams"] = teams

    try:
        res = requests.post(
            f"{PROXY_BASE_URL}/user/new",
            json=data,
            headers={
                "Content-Type": "application/json",
                "Authorization": f"Bearer {PROXY_MASTER_KEY}"
            }
        )
        res.raise_for_status()

        print(f"user: {email} が作成されました")
        user_id = json.loads(res.text)["user_id"]
        key = json.loads(res.text)["key"]
    except requests.exceptions.HTTPError as e:
        print(f'user: {email} のユーザ作成に失敗しました。: {e}')

    return user_id, key

3.招待URL発行：Web UIアクセス用パスワードを設定するための招待URLを発行

# 招待URLを発行する
def create_invitation_url(user_id):
    invitation_url = None
    try:
        res = requests.post(
            f"{PROXY_BASE_URL}/invitation/new",
            json={"user_id": user_id},
            headers={
                "Content-Type": "application/json",
                "Authorization": f"Bearer {PROXY_MASTER_KEY}"
            }
        )
        res.raise_for_status()

        print(f"user: {user_id} の招待URLが作成されました")
        invitation_id = json.loads(res.text)["id"]
        invitation_url = f"{LITELLM_UI_URL}/ui?invitation_id={invitation_id}&action=reset_password"
    except requests.exceptions.HTTPError as e:
        print(f'user: {user_id} の招待URLの作成に失敗しました。: {e}')

    return invitation_url

4.ユーザへの表示：APIキーと招待URLを画面上に表示

また、APIキーやパスワードを忘れてしまったユーザのために、再払い出しの仕組みも整備しました。 既存ユーザがアクセスした際には以下の画面が表示されます。

これらの仕組みにより、運営チームのAPIキー発行作業がゼロになり、運用負荷が大幅に削減されました。

4. まとめ

本記事では、LiteLLMを活用した、コスト管理可能なVibe Coding環境の構築について紹介しました。

4.1 実現できたこと

今回の取り組みにより、以下を実現することができました：

  • 透明性のあるコスト管理

    • 従来は「プロジェクト全体でいくら使ったか」しか分からなかったのが、「誰が・どのように・どれだけ使ったか」まで、整備されたUI上で確認できるようになりました。
    • 開発者も自身の利用状況を確認できるようになり、コストを意識したVibe Codingが可能になりました。

  • 運用負荷を抑えた体制

    • GoogleマネージドなリソースやOSSを用いることにより、環境維持・改善にかかる負荷を抑えました。
    • APIキー発行作業をセルフサービス化することにより、運営チームのAPIキー発行稼働をゼロにし、スケーラブルな運用体制を取ることができました。

これらの実現により、コスト管理面での課題が解消され、Vibe Coding環境を全開発者に向けて展開できるようになりました。

4.2 現在の状況と今後の展開

開発者へのVibe Coding環境の展開は段階的に実施しており、2025年12月現在、約50名の開発者が利用しています。利用者からは、開発効率・品質の向上に関するポジティブなフィードバックを得ています。

今後は残りの開発者への展開を進めるとともに、コスト管理体制の整備を行っていきます。 具体的には、LiteLLMの予算設定機能を用いて、より強いガバナンスを効かせていく予定です。 LiteLLMを導入していることで現状の利用状況を詳細に把握することができ、過度に制限的でなく、かつコスト超過も防げる、適切な予算を設定することができます。 また、利用者の増加に伴いリソースへの負荷も増加するため、Cloud RunやCloud SQLのスペックを適宜見直していきます。

さらに、LiteLLMが複数のAI開発支援ツールに対応可能という利点を活かし、技術トレンドに合わせてClaude Codeなど他のツールの提供も検討していく予定です。

最後に

LLMを活用した開発支援ツールは、今後ますます重要性を増していくでしょう。 しかし、その恩恵を最大限に引き出すためには、単にツールを提供するだけでなく、適切なコスト管理とガバナンスが不可欠です。 LiteLLMのようなOSSとセルフサービス化の仕組みは、そのための強力な土台となります。 適切なガードレールを設けつつ、利用状況を透明化することで、開発者は安心して新しい技術を試すことができ、運営側はスケーラブルな運用を実現できます。 本記事が、同様の課題に直面している方々の一助となれば幸いです。

付録：LiteLLMで日本語のリクエストを扱う際の注意点

LiteLLMをProxyとして導入する際、一点注意が必要な事象がありました。 それは日本語などのマルチバイト文字の扱いです。

LiteLLMの内部処理では、リクエストデータをJSON形式に変換する際、マルチバイト文字がUnicodeエスケープシーケンスに変換されます。 例えば「こんにちは」は\u3053\u3093\u306b\u3061\u306fという形式になります。 そのため、Vertex AIのログをBigQuery等に出力している場合、エスケープシーケンス形式で保存されているため可読性が低下してしまいます。

当初はこの仕様が問題になるのではないかと懸念していました。 しかし、実際にはLLMモデル側で正しく日本語として認識され、レスポンスも通常の日本語テキストとして返ってくるため、結論として実用上の問題はありませんでした。