LLM APIの始め方：APIキー発行から予算上限、.envでのキー管理、Pythonでの初リクエストまで

先に知っておくべき3つのつまずきどころ

初めてLLM APIを使う人がつまずく場所は、ほぼ次の3つです。どれも後から直すと手間がかかるため、手順の前に確認しておきます。

1つ目はキーの誤コミットです。APIキーをコードに直接書いたり、.envファイルをGitに含めたりすると、GitHubなどへのpushでキーが公開されます。公開リポジトリのキーは短時間で第三者に見つかり、不正利用されることがあります。この記事では、キーを作る前に.gitignoreを用意する順番にしています。

2つ目は、環境変数が読み込まれない問題です。.envの置き場所が違う、ファイル名が.env.txtになっている、変数名がSDKの想定と違う、といった原因がほとんどです。手順4に確認用のスクリプトを載せています。

3つ目は課金設定の漏れです。多くのAPIは、支払い方法の登録やクレジットの購入が済むまでリクエストが失敗します。逆に、上限を決めずに使い始めると、ループの誤りなどで想定外の請求が発生します。手順2で、課金の有効化と上限設定を同時に済ませます。

前提：必要なものと環境

必要なものは、Python 3の実行環境、ターミナル(コマンドを打つ画面)、Git、そして使うAPIベンダーのアカウントと支払い方法です。この記事では、代表的な3社のAPIを並べて扱います。OpenAI、Anthropic(Claude)、Google(Gemini)です。手順の流れはどれも同じです。コードが違う箇所だけ、ベンダー別に示します。

画面の項目名、料金、モデル名は頻繁に変わります。この記事では、執筆時点(2026年9月)の一般的な流れを説明します。具体的な画面の場所や価格は、各社の公式ドキュメントで確認してください。

手順1：APIキーを発行する

APIキーは、プログラムからAPIを呼ぶときの身分証にあたる文字列です。このキーで利用者が識別され、課金もキーの持ち主に対して発生します。各社の開発者向けコンソールにログインし、API Keysのページで新しいキーを作成します。

• OpenAI：platform.openai.com
• Anthropic：console.anthropic.com
• Google Gemini：aistudio.google.com

キーには「my-first-test」のように用途がわかる名前を付けます。漏えいしたときに、どのキーを止めればよいかがすぐにわかります。作成直後に表示されるキーは、多くのサービスで二度と表示されません。この時点ではパスワードマネージャーなどに一時保存します。チャットやメモアプリには貼りません。表示を閉じてしまった場合は、そのキーを削除して作り直せば問題ありません。

手順2：課金を有効にし、利用上限と予算アラートを設定する

コンソールの Billing(請求)や Limits(上限)の画面で、支払い方法を登録します。サービスによっては、前払いのクレジット購入も必要です。登録が済むまで、手順5のリクエストは認証エラーや残高不足のエラーで失敗します。

続けて、月額の利用上限と、通知を受け取る金額(予算アラート)を設定します。ここで注意したいのは、ベンダーや設定項目によって「上限に達したら止まる」ものと「通知が来るだけ」のものがある点です。たとえばGoogle Cloudの予算アラートは通知が基本で、それだけでは利用は止まりません。自分が設定した項目がどちらなのかを、公式ドキュメントで確認してください。

前払い式のサービスでは、自動チャージ(残高が減ると自動で追加購入する機能)を学習中はオフにしておくと安全です。残高を使い切った時点で止まるため、金額の上限として働きます。最初の上限は、失っても困らない少額で十分です。

手順3：プロジェクトフォルダと.gitignoreを先に作る

キーを保存するファイルより先に、Gitに無視させる設定を作ります。順番を逆にすると、最初のコミットに.envが入る事故が起きやすくなります。

mkdir llm-first-step
cd llm-first-step
git init
python -m venv .venv

最後の行は仮想環境(プロジェクト専用のPython環境)を作るコマンドです。有効化するには、macOS/Linuxではsource .venv/bin/activate、Windowsでは.venv\Scripts\activateを実行します。次に、フォルダ直下に.gitignoreというファイルを作り、次の内容を書きます。

.env
.venv/
__pycache__/

設定が効いているかは、手順4で.envを作った後にgit statusで確認します。一覧に.envが出てこなければ正しく除外されています。

手順4：.envにキーを書き、読み込めるか確認する

フォルダ直下に.envを作り、使うベンダーの変数名でキーを書きます。変数名は、各社の公式SDKが自動で読みに行く名前に合わせます。

OPENAI_API_KEY=sk-...
ANTHROPIC_API_KEY=sk-ant-...
GEMINI_API_KEY=...

使うベンダーの行だけで構いません。次に、必要なライブラリを入れます。python-dotenvは、.envの内容を環境変数として読み込むライブラリです。

pip install python-dotenv openai anthropic google-genai

ここも使うSDKだけのインストールで足ります。本番のリクエストの前に、キーが読み込めるかだけを確認します。キーそのものは画面に表示しません。

# check_env.py
import os
from dotenv import load_dotenv

print('.env found:', load_dotenv())
key = os.getenv('OPENAI_API_KEY')
print('loaded' if key else 'missing', len(key or ''))

.env found: Falseと出る場合は、.envの置き場所かファイル名が原因です。Windowsのエクスプローラーでは拡張子が隠れて.env.txtになっていることがあるので、dirやls -aで実際の名前を確かめます。missingと出る場合は、変数名の綴りを見直します。もう一つ見落としやすい点があります。load_dotenv()は、同じ名前の環境変数がOSに既に設定されていると、初期設定ではそちらを優先します。古いキーがOS側に残っているとそれが使われるため、キーを更新したのに認証エラーが続く場合は、OS側の環境変数も確認してください。

手順5：Pythonで最初のリクエストを送る

コード中のmodelには、各社の公式ドキュメントのモデル一覧に載っているモデルIDをそのまま入れます。モデル名は短い周期で入れ替わるため、この記事では具体名を固定しません。料金の安い小型モデルを選ぶと、試行錯誤のコストを抑えられます。どのSDKも、キーを引数で渡さなくても環境変数から自動で読み込みます。

OpenAIの場合

from dotenv import load_dotenv
from openai import OpenAI

load_dotenv()
client = OpenAI()
response = client.responses.create(
    model='公式ドキュメントのモデルID',
    input='LLM APIとは何かを1文で説明してください。',
    max_output_tokens=200,
)
print(response.output_text)
print(response.usage)

Anthropic(Claude)の場合

from dotenv import load_dotenv
import anthropic

load_dotenv()
client = anthropic.Anthropic()
message = client.messages.create(
    model='公式ドキュメントのモデルID',
    max_tokens=200,
    messages=[{'role': 'user', 'content': 'LLM APIとは何かを1文で説明してください。'}],
)
print(message.content[0].text)
print(message.usage)

Google Geminiの場合

from dotenv import load_dotenv
from google import genai

load_dotenv()
client = genai.Client()
response = client.models.generate_content(
    model='公式ドキュメントのモデルID',
    contents='LLM APIとは何かを1文で説明してください。',
)
print(response.text)
print(response.usage_metadata)

出力の長さの上限(max_output_tokensやmax_tokens)は、1回あたりの費用の上限として働きます。試すときは小さめの値にしておきます。エラーが出たときは、メッセージの種類で原因を切り分けます。401などの認証エラーはキーの誤りか読み込み失敗です。残高や請求に関するエラーは手順2の設定漏れです。モデルが見つからないというエラーは、モデルIDの綴りか、そのモデルがアカウントで使えないことが原因です。

手順6：応答とトークン使用量を確認する

成功すると、1行目にモデルの回答、2行目に使用量が表示されます。使用量は入力トークンと出力トークンに分かれています。トークンは、モデルが文章を処理するときの分割単位です。日本語では、おおよそ1文字から数文字が1トークンになります。料金はこの入力・出力それぞれのトークン数に単価を掛けて計算され、多くのモデルでは出力の単価の方が高く設定されています。

表示された数値をコンソールの Usage(使用量)画面と見比べると、1回のリクエストがどれだけの費用になるかを実感できます。管理画面への反映には時間差があることが多いので、すぐに表示されなくても慌てる必要はありません。プロンプトを長くしたときに入力トークンがどう増えるかを見ておくと、後で費用を見積もるときに役立ちます。

キーが漏れたときの失効と再発行

キーを公開リポジトリにpushした、画面共有で映した、チャットに貼った。こうした場合は、キーが漏れたものとして扱います。最初にやるべきことは、コミット履歴の削除ではなくキーの失効です。

1. コンソールのAPI Keys画面で該当キーを削除(Revoke)する。ここで不正利用が止まる。
2. 新しいキーを発行し、.envの値を書き換える。
3. 手順4の確認スクリプトと手順5のコードを実行し、新しいキーで動くことを確かめる。
4. Usage画面で、身に覚えのない利用がないかを確認する。不審な請求があれば、ベンダーのサポートに連絡する。

失効させた後に、Git側の後始末をします。まだpushしていないコミットなら、git rm --cached .envでGitの管理から外し、.gitignoreに追記してからコミットし直せば済みます。push済みの場合は履歴の書き換えも必要ですが、既に誰かがコピーしている可能性は消せません。キーの失効を省略してよい理由にはならない点に注意してください。

次に進む前の判断基準

次の4点がそろっていれば、この手順は完了です。git statusに.envが表示されないこと。予算の上限か残高が少額に抑えられていること。確認スクリプトでloadedと表示されること。リクエストの応答とトークン使用量が表示され、Usage画面の数値と一致することです。

そろったら、同じ質問を複数のモデルに投げ、応答の質と使用トークン数を比べてみてください。自分の用途に対して、どのモデルが費用に見合うかを判断する材料になります。チームで使う場合や本番環境に載せる場合は、キーを個人ごと・用途ごとに分けます。そのうえで、ベンダーが提供するシークレット管理やプロジェクト単位の上限機能を公式ドキュメントで確認してください。