この記事の目次
Claude Codeを使い始めるとき、多くの人が最初につまずくのが「APIキーとサブスクリプション認証、どちらを使えばいいのか」という判断です。この記事では、Claude ConsoleでのAPIキー発行から設定方法、両方の認証方式を併用したときの扱い、安全な管理と漏洩時の対処までを、実際に手を動かせる順番で解説します。
Claude CodeのAPIキーとは何か？サブスクリプション認証と何が違うのか
APIキーは、Claude APIをプログラムから呼び出すための従量課金型の認証情報で、Claude Codeの/loginによるPro/Maxのサブスクリプション認証（アカウントに紐づくOAuthベースのログイン）とは、課金方式も認証の仕組みも別物です。
この2つは名前が似ているために混同されがちですが、判断軸はシンプルです。個人の対話利用が中心で、月あたりの支出を固定したいならサブスクリプション認証、CI/CDや自動化スクリプトから呼び出す用途があり、使った分だけ支払いたいならAPIキーが向いています。両方を使い分けたい場合は、あとの章で扱う優先順位の理解が必須になります。
| 比較軸 | APIキー認証 | サブスクリプション認証（/login） |
|---|---|---|
| 課金方式 | 従量課金（使用量に応じた請求） | 月額の定額プラン（Pro/Max） |
| 想定用途 | CI/CD、自動化スクリプト、複数プロジェクトでの個別管理 | 個人の対話利用、ターミナルでの日常的なコーディング |
| 認証の仕組み | Consoleで発行した文字列をそのまま渡す | アカウントへのログイン（OAuth） |
| 向いている読者 | 開発フローに組み込みたい人、支出を利用量で管理したい人 | 支出を毎月一定にしたい個人利用者 |
料金体系そのものの詳細な比較はClaude Codeの料金プラン比較記事に譲り、この記事ではAPIキー固有の発行・設定・管理に絞って進めます。Claude Code自体の全体像を先に押さえたい場合はClaude Codeの使い方ガイドも参考になります。
APIキーはどこで、どのように発行すればよいのか
APIキーはClaude Console（platform.claude.com）の管理画面から発行します。サインイン後にAPI keysの設定画面に進み、キーを新規作成する流れになっています。
Consoleでのキー作成手順
Consoleにサインインしたら、Settings内のAPI keysのページを開き、Create keyのボタンからキーを作成します。作成直後に画面へ表示される文字列は、その場でコピーしておくのが無難です。この画面をあとで再度開いてキーを再表示できるかどうかはUIの仕様次第で、コピーし忘れた場合の扱いも環境によって変わりうるため、詳細はAnthropic公式ドキュメントの「Claude APIキーを取得する」に該当するページに記載されています。
発行時に決めておくべき命名規則とローテーション運用
キーを作るときに用途がわかる名前をつけておくと、あとで「どのキーがどこで使われているか」を追いやすくなります。たとえば「用途-環境-発行日」のような命名パターン（例:blog-automation-prod-2026-08）を決めておき、プロジェクトやサービスごとに別のキーを発行する運用にすると、あるキーを失効させたときの影響範囲が把握しやすくなります。
ローテーション（一定期間ごとにキーを作り直し、古いものを失効させる運用）についても、発行の段階で「いつ・誰が・どの頻度で見直すか」を決めておくと、あとから運用ルールを後付けするより負担が小さく済みます。ここで決めるのは発行時の命名とローテーションの方針までで、設定ファイル上でどう使い分けるかは次の章で扱います。
取得したAPIキーをClaude Codeにどう設定するのか（3つの方法と選び方）
Claude CodeへのAPIキー設定は、初回起動時の対話入力・環境変数・設定ファイルの3通りがあり、検証目的なのか常用目的なのかで選ぶべき方法が変わります。
一時的に試すだけなら対話入力、日常的に使うなら環境変数への永続化、プロジェクトごとに切り替えたいなら設定ファイルという住み分けが基本です。それぞれの場面と手順を見ていきます。
| 設定方法 | 永続性 | 向いている場面 | 手軽さ |
|---|---|---|---|
| 初回起動時の対話入力 | セッションや設定の保存状況に依存 | とりあえず動作を試したいとき | 最も手軽 |
環境変数ANTHROPIC_API_KEY |
シェル設定に書けば恒久的 | 日常的に同じキーを使い続けるとき | 一度設定すれば手間なし |
| プロジェクトごとの設定ファイル | プロジェクト単位で保持 | 複数プロジェクトでキーを使い分けるとき | 初期設定にやや手間がかかる |
初回起動時の対話入力で設定する
Claude Codeを初めて起動すると、APIキーの入力を求められる場合があります。ここで発行済みのキーを貼り付ければすぐに使い始められるため、動作確認のような一時的な用途に向いています。恒久的に使うキーであっても、この方法だけに頼らず、あとで環境変数か設定ファイルに移しておくと管理がしやすくなります。
環境変数ANTHROPIC_API_KEYで設定する
macOSでzshを使っている場合、~/.zshrcに以下のような行を追加し、ターミナルを再起動するかシェルを再読み込みすることでキーを永続化できます。
export ANTHROPIC_API_KEY="ここに発行したキーを貼り付ける"追加後は、以下のコマンドで即座に反映できます。
source ~/.zshrc環境変数として設定しておけば、Claude Codeに限らず同じ変数を参照する他のツールからも同じキーを利用でき、ターミナルを開くたびに入力し直す手間がなくなります。反面、シェルの設定ファイルはGitリポジトリに含めるべきではないため、キーを書き込んだ.zshrc自体の管理には注意が必要です。
プロジェクトごとに設定ファイルで切り替える
複数のプロジェクトで別々のAPIキーを使い分けたい場合、プロジェクト単位の設定ファイルにキーを持たせる方法があります。ただし、Claude Codeが.envファイルをCLI自身で自動的に読み込むのか、それともシェルや別ツール（direnvなど）を経由させる必要があるのかは、公式ドキュメント上で明確な記載を見つけられていません。運用に組み込む前に、実際のプロジェクトで小さく試して挙動を確かめておくと安心です。設定ファイルの具体的な書式や記述例はsettings.jsonの書き方ガイドで解説しています。
複数プロジェクトでキーを使い分ける際の置き場所と優先順位
プロジェクトごとに別のキーを使う場合、環境変数と設定ファイルの両方に値が存在すると、どちらが優先されるのかという問題が出てきます。この優先順位を思い込みで決めてプロジェクトを跨いだ運用ルールに落とし込むと、意図しないキーで課金が発生するといった事故につながりかねません。OS別の設定差分についてはWindows環境でのClaude Code利用ガイドで扱っています。
APIキー認証とサブスクリプション認証を両方使う場合、どちらが優先されるのか
ANTHROPIC_API_KEYが環境変数として設定された状態で/loginによるサブスクリプション認証も行っている場合にどちらが優先されるかは、この記事の執筆時点で確証を持って断定できる情報がありません。
意図せず従量課金のAPIキー側で処理が実行され、想定外の請求が発生するようなケースを避けるには、実際に短いコマンドを一つ実行し、どちらの認証で応答が返っているかを自分の環境で確かめておくのが最も確実です。特にPro/Maxのサブスクリプションに加入している状態でAPIキーも設定している人は、意図した方の認証方式で動いているかを一度確認しておくとよいでしょう。プランごとの費用感は料金プラン比較記事で確認できます。
APIキーを安全に管理するには何をすればよいのか
APIキーの管理で最初に守るべきは「コードに直接書かない」「第三者と共有しない」「.gitignoreでリポジトリから除外する」という基本原則で、これらを徹底したうえで、複数プロジェクトでの分離設計と漏洩時の対処フローまで押さえておくと安心です。
基本原則の再確認
APIキーはソースコードへの直書きを避け、環境変数や設定ファイルなど、リポジトリの管理対象外に置く場所で扱います。設定ファイルを使う場合は.gitignoreに該当ファイルを追加し、誤ってコミットしないようにします。キーは第三者に共有せず、チームで使う場合もメンバーごとに別のキーを発行するのが基本です。
自動化・複数プロジェクト運用での分離設計
複数のプロジェクトや自動化処理でAPIキーを使い分けるときの考え方として、当メディア自身のブログ自動投稿エンジンでの設計が参考になります。このエンジンはClaude Codeを子プロセスとして起動する際、渡す環境変数からプロバイダーの認証情報や接続設定、Bedrock/Vertex/Foundryの切替設定、Discord通知の設定、GitHub認証の設定といった、その処理に不要な認証情報をあらかじめ取り除いています。
つまり、Claude Codeの子プロセスには「その処理で実際に使う権限だけ」を渡し、他のサービスの認証情報は最初から見えない状態にしているということです。この考え方は個人や小規模チームの運用にもそのまま当てはまります。複数プロジェクトで一つのキーを使い回すのではなく、プロジェクトごとに別のキーを発行し、そのプロジェクトが必要とする範囲だけに認証情報のスコープを絞っておくことで、あるプロジェクトでの問題が他のプロジェクトに波及するリスクを小さくできます。
誤って公開してしまった場合の対処フロー
APIキーをリポジトリや公開の場に誤って含めてしまった場合は、まずClaude Console上で該当のキーを速やかに失効させ、必要であれば新しいキーを発行して置き換えます。失効後は、そのキーが使われていた期間の使用量や請求状況をConsoleの画面で確認し、意図しない利用がなかったかを確認しておくと安心です。具体的な失効・再発行の操作画面は変更される可能性があるため、実行時点でConsole画面に表示される案内を優先してください。組織やチームでの運用ルールをより体系的に整えたい場合は、エンタープライズ向けセキュリティガイドやClaude Codeの運用ルールに関する記事を確認してください。
個人利用でAPIキーの従量課金はどれくらいかかるのか、Pro/Maxとどちらが得か
APIキーの従量課金がいくらになるかは利用量によって大きく変わり、具体的な金額をここで示すことはできません。まずはConsole上の使用量・請求ダッシュボードで自分の実際の利用量を確認するのが確実な方法です。
固定費で運用したいのか、変動費で細かく管理したいのかという軸で考えると判断しやすくなります。毎日一定量をコーディングに使う人は、支出が読みやすいサブスクリプション（Pro/Max）の方が管理の手間が少なく感じられることが多く、逆に利用が月によって大きく変動する場合や、CI/CDなど自動化処理での利用が中心の場合は、使った分だけ支払うAPIキーの方が合理的なケースもあります。プランごとの詳しい金額比較は料金プラン比較記事を参照してください。
まとめ
ここまでで、Claude ConsoleでのAPIキー発行、Claude Codeへの3つの設定方法、サブスクリプション認証との優先順位を確認する手順、そして漏洩時の対処までを一通り扱いました。自分のキーを発行し、意図した方法で設定できているか、一度立ち止まって確認してみてください。
単発の設定作業はこの記事で完結しますが、複数プロジェクトでの鍵の分離設計や、チームでの運用ルールをどう文書化するかといったテーマは、自己流のまま続けると事故につながりやすい領域でもあります。こうした運用の考え方を継続的に学べる場として、月額1,980円から参加できる学習コミュニティ「AI駆動ラボ」(lab.no-wave.jp)があります。CLAUDE.mdでの運用ルール化やセキュリティ設計を、自分の手で使えるようになるまで学び続けたい人は、覗いてみるとよいでしょう。
Claude Code自体の全体像から見直したい場合はClaude Codeとは何かを解説した記事もあわせてどうぞ。