Lovable API Key の追加場所と安全な管理

Lovable では、Lovable API Key は Secrets に置きます。プロジェクトのツールバーで More → Settings → Secrets を開くか、プロジェクトのチャットに出る Add secret フォームを使います。バックエンドのコードがそこから読むので、キーがブラウザに届くことはありません。チャットのメッセージに貼ったり、フロントエンドのコードに書いたりすると、その場で見えてしまいます。

短い答え

• 自分のキー（GPT、Claude、Resend）：Secrets、またはコネクタが表示するフォーム。
• Lovable 自身のキー：LOVABLE_API_KEY は自動で生成されます。ワークスペースキー（lov_…）には Business か Enterprise が必要です。
• GPT・Claude・DeepSeek を自分のキーで：バックエンド関数を Lovable に作らせます。組み込みの AI コネクタは自分のキーを使えません。
• 漏れたとき：まず提供元で失効させ、そのあと Secrets の値を差し替えます。

どの Lovable API Key が必要か

Lovable API Key という言葉は、4 つの別のものを指します。

ワークスペースキーは Lovable API にだけ送るもので、Lovable-API-Key ヘッダーに入れます。値が表示されるのは一度だけです（API キーのドキュメント、2026年11月2日に確認）。これはプロジェクトの管理とデプロイに使い、AI モデルの呼び出しやアプリの生成は行いません（Lovable API）。プロジェクトの LOVABLE_API_KEY とは別物です（AI のドキュメント）。

ここから先は 1 行目、自分のキーの話です。

Lovable で API キーを追加する場所

1. Lovable から求められたとき。機能がキーを必要とすると、プロジェクトのチャットに Add secret フォームが出ます。値はフォームに入力します。チャットのメッセージとして送ると履歴に残りますが、フォームはプロジェクトの Secrets に直接保存します（Lovable のカスタム API ドキュメント、2026年11月2日に確認）。
2. 自分で追加するとき。プロジェクトのツールバーで More → Settings → Secrets を開き、Add secret を押して、名前と値の組を 1 つ以上入力します（Secrets のドキュメント）。

Lovable の 2026年8月26日の変更履歴では、この場所を More → Cloud → Secrets と書いています。メニューが違う場合はそちらを見てください（変更履歴）。

つまずきやすいルール：

• 書き込み専用。値は差し替えも削除もできますが、読み返せません。
• VITE_ で始まる名前は受け付けられません。ビルド時に組み込まれてブラウザから見える値なので、.env に置きます。
• SUPABASE_ と LOVABLE_ で始まる名前は予約済みで、自動で入力されます。
• Secrets はプロジェクトごとに独立しています。remix のあとは自分のキーを入れ直します。Lovable が生成したキーだけが作り直されます。

自分の Supabase プロジェクトでは、バックエンドの画面に Manage secrets ボタンがあり、Supabase のダッシュボードが開きます。保存先は Edge Function Secrets です（Supabase secrets、2026年11月2日に確認）。1 つの Supabase プロジェクトを 2 つの Lovable プロジェクトで共有すると、Secrets が上書きし合います。LOVABLE_API_KEY も同じです（Supabase 連携）。

Resend、Stripe、Google Maps のキーはどこに置くか

すべてのキーが Secrets に直接入るわけではありません。次のサービスにはコネクタのフォームがあります（Stripe、Resend、カスタム API、2026年11月2日に確認）。

Google Maps は例外です。ブラウザキーはもともと公開で、VITE_LOVABLE_CONNECTOR_GOOGLE_MAPS_BROWSER_KEY としてフロントエンドに届きます。ほかのサイトからの再利用はウェブサイト制限で防ぎます（Google Maps、2026年11月2日に確認）。サーバーキーは非公開のままです。コネクタの認証情報は暗号化して保存され、Lovable でも読み返せません（連携のセキュリティ）。

自分のキーで GPT・Claude・DeepSeek につなぐ

まずキーが必要かを確認します。組み込みの AI コネクタにキーは要りません。Lovable はプロジェクトごとに LOVABLE_API_KEY を生成し、既定では GPT-6 Astra を動かします。Claude のチャットモデルは、2026年5月13日以降に作った新しい TanStack Start アプリでのみ使えます（AI のドキュメント、AI chat、2026年11月2日に確認）。

このコネクタは自分のキーを使えません。常に Lovable 経由で動き、ワークスペースのクレジットを消費します。2026年11月2日時点の Lovable のドキュメントに DeepSeek の記載はありません。自分のキーを使うなら、バックエンド関数から提供元を呼ぶように Lovable に頼み、キーは Secrets に置きます。

関数を作るボタンはありません。プロジェクトのチャットで関数の内容を説明すると、Lovable が書いてデプロイします（Edge functions）。2026年5月13日以降に作った TanStack Start アプリ（Enterprise は 6月22日以降）では server function になり、それより前の React + Vite アプリでは Edge Function になります。どちらもサーバーで動くコードです。

下のコードは OmniaKey の OpenAI 互換 API を使います。1 つのキーで GPT-6.1 Terra、Claude Sonnet 5.5、DeepSeek を呼べます。

1. 提供元でキーを作ります。OmniaKey なら omniakey.com で登録し、Dashboard → tokens を開きます（クイックスタート）。

2. 次のプロンプトをプロジェクトのチャットに貼ります：

   text

   Add an AI chat feature that uses my own API key, not the built-in AI connector.
   Create a backend function named "chat". It reads OMNIAKEY_API_KEY from Secrets and calls
   POST https://api.omniakey.com/v1/chat/completions with the model and messages the frontend sends.
   Only allow these models: gpt-6.1-terra, claude-sonnet-5-5, deepseek-flash.
   Require a signed-in user. Never put the key in frontend code.
   Ask me for the key with the Add secret form.
   

3. Add secret フォームにキーを入力し、名前を OMNIAKEY_API_KEY にします。

私たちには Lovable のアカウントがないため、このプロンプトは Lovable では実行していません。Lovable の手順は公式ドキュメントによるものです。関数は次のようになります。このコードは自分のマシンで動かしたものです。

// supabase/functions/chat/index.ts
// ブラウザは { model, messages } を送り、この関数がサーバー側で API キーを付けます。
const corsHeaders = {
  "Access-Control-Allow-Origin": "*",
  "Access-Control-Allow-Headers": "authorization, x-client-info, apikey, content-type",
};

const ALLOWED_MODELS = ["gpt-6.1-terra", "claude-sonnet-5-5", "deepseek-flash"];

function json(body: unknown, status = 200) {
  return new Response(JSON.stringify(body), {
    status,
    headers: { ...corsHeaders, "Content-Type": "application/json" },
  });
}

Deno.serve(async (req) => {
  if (req.method === "OPTIONS") {
    return new Response("ok", { headers: corsHeaders });
  }

  const apiKey = Deno.env.get("OMNIAKEY_API_KEY");
  if (!apiKey) {
    return json({ error: "OMNIAKEY_API_KEY is not set" }, 500);
  }

  const { model, messages } = await req.json();
  if (!ALLOWED_MODELS.includes(model)) {
    return json({ error: `model must be one of: ${ALLOWED_MODELS.join(", ")}` }, 400);
  }

  const upstream = await fetch("https://api.omniakey.com/v1/chat/completions", {
    method: "POST",
    headers: {
      Authorization: `Bearer ${apiKey}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({ model, messages, max_tokens: 800 }),
  });

  const data = await upstream.json();
  if (!upstream.ok) {
    return json({ error: data.error?.message ?? "upstream error" }, upstream.status);
  }
  return json({ reply: data.choices[0].message.content, model: data.model, usage: data.usage });
});

テスト用のコードはスクリプトから呼べるようにログイン確認を省いています。上のプロンプトでは Lovable に追加を頼んでいます。Lovable のセキュリティのベストプラクティスは、認証の判断をサーバー側で行うことを求めています（best practices）。

ブラウザからは次のように呼びます（supabase-js）：

const { data, error } = await supabase.functions.invoke("chat", {
  body: { model: "deepseek-flash", messages: [{ role: "user", content: "Say hello in five words." }] },
});

別の提供元を使うときは、URL とモデル ID をそのドキュメントの値に変えます。OmniaKey のキーは Cline のカスタム API キー や Factory Droid のカスタムモデル でも使えます。

実際に動かした結果

2026年11月2日、Deno 2.9.8 で自分のマシン上でこの関数を動かしました。呼び方はブラウザと同じで、Origin ヘッダーを付け、CORS のプリフライトも通しています。

モデルごとに 1 回だけ呼んだので、それぞれ 1 サンプルです。deepseek-flash の応答では、モデル名が deepseek-v4-1-flash-261017 と返りました。

「non-2xx status code」しか出ない理由

エラーのとき、supabase.functions.invoke が返すのは Edge Function returned a non-2xx status code だけで、data は null です。関数の本当のメッセージは await error.context.json() にあります：

if (error) {
  const details = await error.context.json();
  console.error(details.error);
}

• 401：キーが違います。私たちの環境では Invalid token (request id: …) でした。
• 500 と OMNIAKEY_API_KEY is not set：シークレットがないか、名前が違います。
• 400：モデルが許可リストにありません。

キーが露出していないか確認する

フロントエンドのコードにあるキーは利用者から見えるので、漏れたものとして扱います（best practices、2026年11月2日に確認）。

• Quick security scan は公開のたびに自動で動きます。
• Deep security scan は自動では動きません。プロジェクトの Security view から開始します（Security view）。
• Leaked secrets & credentials のグループを見ます。
• どちらのスキャンも無料です。一括修正だけが無料の 10 回を使い、そのあとはクレジットを消費します（security scans）。

手作業で確認するなら、Chrome で公開済みアプリの開発者ツールを開き、Mac は Command+Option+F、Windows と Linux は Control+Shift+F を押して、読み込まれたファイルからキーの先頭数文字を検索します。VITE_ で始まる値に秘密鍵が入っていたら対応が必要です。その値はブラウザ向けにビルドされるためです（DevTools search）。検索がきれいでも、そのページが読み込んだファイルしか見ていません。スキャンも実行してください。

キーを隠しても、他人が関数を呼ぶことは止まりません。ログイン確認のない関数は誰でも呼べ、そのたびにあなたのキーを消費します。Lovable のドキュメントはサーバー側でのログイン確認を求めています。私たちの許可リストと max_tokens: 800 は 1 回の呼び出しを制限します。OmniaKey のドキュメントは、環境ごとに別のキーを作り、上限額を設定することを勧めています（OmniaKey の API ドキュメント）。

キーが漏れたときの手順

1. 発行元で失効させ、新しいキーを作ります。Lovable のドキュメントが Rotate を用意しているのは Lovable 自身のキーだけです（Secrets のドキュメント）。
2. Secrets、コネクタのフォーム、Supabase のいずれかで値を差し替えます。Supabase では再デプロイなしで新しいシークレットを読みます（Supabase secrets）。Lovable の組み込みバックエンド Cloud が同じ動きをするかはドキュメントに書かれていないので、関数を 1 回呼んで確認します。
3. キーをフロントエンドのコードや .env から外し、Deep security scan をもう一度実行します。
4. 提供元の利用状況ページで、自分が送っていない呼び出しを確認します。

Lovable 自身のキーは扱いが違います。LOVABLE_API_KEY には Rotate があり、editor 以上が使えます。新しいキーを発行し、Edge Function の環境を更新します。GitHub の secret scanning が報告したワークスペースキー（lov_…）は自動で失効します。それ以外の場所では自分で失効させてください（API キーのドキュメント）。

料金の考え方

Lovable の請求と提供元の請求は別です。自分のキーなら、モデルの利用は提供元が請求し、アプリは関数を動かすために Cloud を使うだけです（AI のドキュメント、Cloud、2026年11月2日に確認）。

組み込みの AI コネクタはワークスペースのクレジットを消費します。Free、Pro、Business には毎月 4-credit の AI 枠があり、使い切ると 402、レート制限を超えると 429 が返ります。Free プランは 1 日 5 build credits、月に最大 30、加えて 20 Cloud credits が付きます（料金ページ）。Lovable のプラン表では、Pro は月 $25 で 100 credits です（サブスクリプションのプラン、2026年11月2日に確認）。

OmniaKey の現在の料金は GPT-6.1 Terra、Claude Sonnet 5.5、DeepSeek のページで確認できます。

よくある質問

Lovable API キーはどこにありますか？

どれを指すかで変わります。LOVABLE_API_KEY はプロジェクトごとに生成され、そのプロジェクトの Secrets にあります。Rotate はできますが、値は読み返せません。ワークスペースキーは Workspace settings → API keys & OAuth → Workspace access tokens で発行し、表示は一度だけです。

無料の Lovable API Key はありますか？

一番近いのは LOVABLE_API_KEY です。組み込みの AI コネクタがプロジェクトごとに生成し、Free、Pro、Business のワークスペースには毎月 4-credit の AI 枠があります。ワークスペースキーには Business か Enterprise が必要です。

自分の OpenAI キーを Lovable AI で使えますか？

組み込みの AI コネクタでは使えません。常に Lovable 経由で動き、ワークスペースのクレジットを消費します。自分のキーを使うなら、提供元を直接呼ぶバックエンド関数を Lovable に作らせ、キーは Secrets に置きます。

API キーは Secrets と .env のどちらに置きますか？

秘密のキーをバックエンドのコードが読むなら Secrets です。.env は VITE_ で始まる値の置き場所で、アプリに組み込まれ、ブラウザから見えます。

Lovable が GPT・Claude・DeepSeek につながらないのはなぜですか？

まず関数のメッセージを読みます。原因が書かれています：

• 500 と OMNIAKEY_API_KEY is not set：シークレットがないか、別の名前で保存されています。
• 401：キーが違うか、失効しています。
• 400：モデル ID が許可リストにありません。
• 404：ベース URL が違います。私たちの URL は /v1/chat/completions で終わります。設定ミスの多くはプロトコルの接尾辞の誤りです（OmniaKey のエラードキュメント）。

ブラウザには Edge Function returned a non-2xx status code しか出ません。上のコードのように error.context を出力すると、どれかが分かります。

確認した資料

• Lovable の Secrets ドキュメント、2026年11月2日に確認
• Lovable の API キー、2026年11月2日に確認
• Lovable API、2026年11月2日に確認
• Lovable MCP サーバー、2026年11月2日に確認
• Build with URL、2026年11月2日に確認
• Lovable の AI 機能、2026年11月2日に確認
• Lovable AI チャット、2026年11月2日に確認
• Lovable Edge functions、2026年11月2日に確認
• Lovable Cloud、2026年11月2日に確認
• カスタム API とコネクタ、2026年11月2日に確認
• Stripe 連携、2026年11月2日に確認
• Resend 連携、2026年11月2日に確認
• Google Maps 連携、2026年11月2日に確認
• 連携のセキュリティ、2026年11月2日に確認
• Supabase 連携、2026年11月2日に確認
• Lovable のセキュリティ、2026年11月2日に確認
• Lovable Security view、2026年11月2日に確認
• Lovable のセキュリティのベストプラクティス、2026年11月2日に確認
• Lovable のプラン、2026年11月2日に確認
• Lovable の変更履歴、2026年11月2日に確認
• Lovable の料金ページ、2026年11月2日に確認
• Supabase Edge Function secrets、2026年11月2日に確認
• Supabase functions.invoke、2026年11月2日に確認
• Chrome DevTools の検索、2026年11月2日に確認

OmniaKey 自身のドキュメント（2026年11月2日に確認）：クイックスタート、OpenAI 互換 API、認証、エラー。