まだ .env で疲弊してませんか？私も同じでした、LiteLLMを導入するまでは。

.env ファイルにAPIキーを書く。プロジェクトが増えるたびに、それをコピーする。気づけば5つのディレクトリに同じキーが散乱していて、ローテーションのたびに「どのファイルを直したっけ」が始まる。

関連記事としては Blogその pip install、信用していい？未監査の LLM 圧縮ツールをゼロトラスト隔離で実測したトークン50〜90%削減を謳う未監査の OSS（Headroom）を、本番に晒さずゼロトラスト隔離で実測しました。静的監査・多層ハードニング・使い捨てキーの型と、削減0%だった理由、効果が別レイヤー（RTK）にあったどんでん返しまで一次情報で記録します。→ もあわせて読むと、今回の論点とのつながりを把握しやすくなります。

正直に言います。これは意志の問題ではありません。構造を変えなければ解決しない。

• APIキーが散乱していく恐怖
• LiteLLMを一言で言うと
• 仮想キーで「本物を隠す」
• 予算上限が「通知」ではなく「遮断」
• OpenAI互換エンドポイントで「接続先を意識しない」
• LiteLLMを使う前に知っておくこと
• よくある質問
• まとめ：管理の問題は構造で解く
• この記事を書いた人
• 関連記事

一人開発を続けていると、プロジェクトは増えます。

私の場合、並行して動かしている4つの個人プロジェクト——それぞれのディレクトリに、同じAPIキーが書いてある .env ファイルが存在していました。「全部コピーすれば済む」は最初だけ。キーをローテーションしたとき、どのプロジェクトのどのファイルを直したかを追うのがひと仕事になります。

そして「どこかのプロジェクトに古いキーが残ったままgitに乗っていないか？」という不安が消えない。技術の問題ではなく、心理の問題です。

OpenAI互換のプロキシサーバーです（GitHub / 公式ドキュメント）。自分のNASやサーバーに立てると、全プロバイダー（OpenAI・Anthropic・Gemini・Azure）への呼び出しを一本に集約できます。

本物のAPIキーはサーバーの1箇所にしか置かない。各プロジェクトには「仮想キー」——月$10上限の使い捨てトークン——だけを渡す。漏れたら仮想キーを無効化するだけで、本物のキーは安全なまま。

シンプルですが、この発想の転換は大きかった。

LiteLLM v1.82.3 の Swagger UI。/models や /chat/completions 等のエンドポイントがOpenAI互換形式で並んでいる

LiteLLMには仮想キーの発行機能があります。本物のAnthropicキーやOpenAIキーはQNAPの .env の中にだけ存在して、各プロジェクトの .env には以下の2行だけが書いてある状態です。

LITELLM_VIRTUAL_KEY=sk-virtual-xxxx
LITELLM_BASE_URL=http://192.168.11.101:4000

.env がGitHubに上がっても（実際には上げませんが）、仮想キーを無効化すれば終わります。本物のキーをローテーションする必要がない。

この「被害の局所化」が、一番価値のある部分です。以前のように「全プロジェクトの .env を順番に直す」作業は消えました。

クラウドAIの怖いところは、使いすぎたとき「お知らせ」だけで止まらないこと。

Azureには請求アラートがあります。OpenAIにもソフトリミットがある。でも「API呼び出しを物理的に強制停止する」機能は、どのプロバイダーも弱い。設定できても「スロットリング（速度制限）」どまりで、呼び出し自体は続いてしまいます。「通知が来てから対応する」では、気づいたときには数万円動いていたりします。

LiteLLMを挟むと、プロバイダー側に上限設定がなくても、ゲートウェイ側でハードに遮断できます。仮想キーに月額上限を設定するだけで、超えた瞬間に認証エラーが返り、どのプロジェクトからの呼び出しも通らなくなります。私は $10/月 に設定しています。

スクリプトのバグで無限ループに入ったとき、この上限が実際に火消しになりました。「通知を見てから止める」と「そもそも止まっている」は、深夜に気づく価値が全然違います。

LiteLLMを経由すると、どのAIプロバイダーも同じエンドポイント・同じ形式で呼べます。コードの中で openai.Client() を初期化しておけば、裏でGeminiが動いていようとClaudeが動いていようと関係ない。

実際に手元の複数プロジェクトはすべて OPENAI_BASE_URL を LiteLLM ゲートウェイに向けています。モデルを切り替えるときも、コードではなく config.yaml だけを変えればいい。

「どのプロジェクトがどのモデルを使っているか」の把握が一箇所でできるようになりました。Swagger UIを開けば、トークン消費もモデルごとにリアルタイムで見えます。

LiteLLM の Model Management 画面。azure-gpt・gemini-2.0-flash・claude-sonnet-4-6・gpt-5.4-mini など複数プロバイダーのモデルを一画面で管理できる

便利なツールですが、正直に言っておきます。

• NASが落ちたら全プロジェクトのAIが止まる: QNAP1台がSPOF（単一障害点）です。本番サービスで使う場合は冗長化を検討する必要があります
• LAN内のみアクセス可能: デフォルトは自宅ネットワーク内のみです。外部公開にはCloudflare TunnelやVPNが必要で、セキュリティ設計が別途必要になります
• config.yamlの管理コスト: モデルを追加するたびに設定ファイルを編集する必要があります。プロバイダーが増えると設定が複雑になります

個人開発の範囲では問題になりません。ただ「すべてをLiteLLM経由にする」という構成は、LiteLLMへの依存度が高まることを意味します。何かに依存するという選択は、常に意識的にするべきです。

セキュリティの文脈では、自宅ラボでのAPI管理以外にも気になることがあれば、BlogWazuhとClaude Codeを繋いだら、CVE調査と修正提案が自動化できた【自宅ラボ セキュリティ実録 #3】Wazuh REST APIでCVEリストを取得し、Claude Codeに渡したら調査と修正コマンド生成が自動化できた。93件のCriticalを手動で追っていた状態からの脱出実録。→も参考になります。

Q: LiteLLMは無料で使えますか？

本体はオープンソース（MITライセンス）で無料です。ただしAIプロバイダーのAPI料金は別途かかります。仮想キーの上限で管理するため、意図せず使いすぎることは防げます。

Q: 自宅LAN外からは使えませんか？

デフォルトはLAN内のみです。Cloudflare TunnelやWireGuard VPNで外部公開することは可能ですが、セキュリティ設計が別途必要になります。

Q: 仮想キーが漏洩した場合はどうなりますか？

LiteLLMの管理画面（Swagger UI）から該当キーを無効化するだけです。本物のAPIキーには影響しません。これが「被害の局所化」の核心です。

.env が散乱する問題は、「もっとちゃんとやろう」という意志では解けません。構造を変えるしかない。

LiteLLMの構築自体はDocker Composeで30分かかりませんでした。難しいのは config.yaml のプロバイダー設定くらいで、Swagger UIで動作確認しながら進めれば詰まることは少ない。

導入して数ヶ月経ちますが、「あのキー、どこに書いたっけ」という問いが頭の中から消えました。それだけで、導入した価値はあったと思っています。

道具を使う人間でいたいとは思う。でも「キー管理で消耗していた時間」を取り返す方法が、別のキー管理ツールではなくプロキシサーバーだったとは——20年やっていても、まだ気づいていないことはある。

技術的なセットアップ手順（docker-compose / config.yaml / 仮想キー発行コマンド）は Zennの記事 にまとめています。

動作確認環境: LiteLLM v1.82.3 / Docker Compose 構成 / 2026年3月確認

HW系エンジニアとして20年以上、10,000件を超える顧客訪問と2,000件を超える単独ソリューション実績。AIツールを使った個人開発やIoT農園など、Raspberry Piを使ったオートメーション化なども実践中です！エンジニア専門結婚相談所も運営中、ClaudeCodeで解決できない心の課題も解決いたします！

この記事は実運用環境での検証内容をもとに執筆しています。

• Blogその pip install、信用していい？未監査の LLM 圧縮ツールをゼロトラスト隔離で実測したトークン50〜90%削減を謳う未監査の OSS（Headroom）を、本番に晒さずゼロトラスト隔離で実測しました。静的監査・多層ハードニング・使い捨てキーの型と、削減0%だった理由、効果が別レイヤー（RTK）にあったどんでん返しまで一次情報で記録します。→
• BlogRasPi 5にWazuhを入れたら、Dockerが死んだ話——自宅セキュリティ監視の実録RasPi 5（ARM64）にWazuhをDocker Composeで構築しようとしたらIndexerが落ちて失敗。直接インストールに切り替えた実録。3台を監視したらCritical脆弱性が203件出てきた話。→
• Blog執事AIに薦められたツールが危なかった——Star数に騙されないための3層防御GitHub Star 2,100のツールの依存にSSH鍵を抜くマルウェアが。Claude Codeの3エージェント並列リサーチで発覚し、deny list + PreToolUse hookで3層防御を構築した実体験。→