AI開発セキュリティ

1Passwordで.env管理
AI開発のAPIキー安全入門

この記事のゴール

1Password Developer Platformと op CLIを使い、Mac / Windows / WSLでAPIキーを平文保存しない開発環境を作ります。

op runとop readを軸に、Claude Code、Codex、OpenAI API、Supabase、Resend、Cloudflareで使える実務運用までまとめます。

1Password対応
op CLI対応
Mac対応
Windows / WSL対応
Claude Code / Codex向け
Next.js対応
エラー対処あり
FAQあり

APIキーを.envへ直書きしない。

AI開発の安全性は、ここからかなり変わります。

検索意図

この記事で分かること

AI開発を始めると、OpenAI、LINE、Threads、Slack、Cloudflare、Supabase、Vercel、GitHubなどのAPIキーを大量に扱うようになります。最初は.envに貼れば動きますが、プロジェクトが増えるほど管理がつらくなります。

この記事では、1Passwordに秘密情報を置き、プロジェクト側にはop://Private/OpenAI/api_keyのような参照だけを書く運用を解説します。

結論

最初に覚えるのは op run --env-file=.env -- npm run dev です。本物のAPIキーは1Passwordへ置き、.envにはsecret referenceだけを書きます。

この記事の内容

なぜ.env直書きが危ないのか
1Password Developer Platformとは
最初に送るプロンプト
最終構成
Macセットアップ
Windows + WSLセットアップ
Vault作成とAPIキー保存
.envをsecret reference化する
.envを使わずzsh exportで読む
op runで実行する
Claude Code / Codexとの使い方
チーム開発のVault設計
よくあるエラーと対処法
AIに聞くためのプロンプト集
FAQ

前提理解

なぜ.env直書きが危ないのか

.envは便利です。ローカル開発では、APIキーやURLをまとめて置けます。ただし、AI開発では扱う秘密情報が一気に増えます。

OPENAI_API_KEY
ANTHROPIC_API_KEY
LINE_CHANNEL_SECRET
LINE_CHANNEL_ACCESS_TOKEN
SNS_CLIENT_SECRET
SLACK_BOT_TOKEN
CLOUDFLARE_API_TOKEN
SUPABASE_SERVICE_ROLE_KEY
DATABASE_URL
VERCEL_TOKEN
GITHUB_TOKEN

よくある事故は、.envをGitHubに上げてしまう、AIエージェントに中身を読ませてしまう、Slackやチャットにキーを貼ってしまう、といったものです。

.gitignoreに書いていても、ローカルに平文で残っている以上、画面共有、バックアップ、誤操作、端末紛失のリスクは残ります。

基本理解

1Password Developer Platformとは

1Password Developer Platformは、開発で使う秘密情報を1Password上で管理し、CLIや連携機能から安全に使える仕組みです。

この記事で使う中心はopという1Password CLIです。1Password CLIを使うと、ターミナルからVault、Item、Field、secret referenceを扱えます。

.envに
本物のキーを書く

○

1Passwordに保管し
op runで展開する

初心者向けに整理すると、1PasswordはAPIキーの保管場所、Vaultは秘密情報を分ける箱、ItemはOpenAIやSupabaseなどの単位、Fieldはapi_keyやservice_role_keyの具体的な値です。

基本構成

一番よく使う構成

まず覚えるのは、この流れです。

1Password Vault
↓
op CLI
↓
.envにはsecret referenceだけを書く
↓
op runで実行時だけ展開
↓
Node.js / Next.js / Claude Code / Codexから環境変数として読む

実行コマンドはこれです。

op run --env-file=.env -- npm run dev

.envには本物の値ではなく参照を書きます。

OPENAI_API_KEY=op://Private/OpenAI/api_key
SUPABASE_URL=op://Production/Supabase/url
SUPABASE_SERVICE_ROLE_KEY=op://Production/Supabase/service_role_key
SLACK_BOT_TOKEN=op://Production/Slack/bot_token

アプリ側はいつも通りprocess.envで読みます。

const openaiApiKey = process.env.OPENAI_API_KEY;

完成形

最終構成

この記事で作る最終構成は、Macでは1Passwordアプリ、1Password CLI、zsh、Claude Code / Codexを組み合わせる形です。

Mac
- 1Password アプリ
- 1Password CLI: op
- zsh
- Claude Code
- Codex
- OpenAI API / Supabase / Resend / Cloudflare

Windowsでは、Windows版1PasswordアプリとWSL Ubuntuを組み合わせます。開発作業はWSL側で行い、op CLIもWSL側へ入れます。

Windows + WSL
- 1Password Windows アプリ
- WSL Ubuntu
- 1Password CLI: op
- Claude Code
- Codex
- OpenAI API / Supabase / Resend / Cloudflare

理想の流れは、こうです。

1Password
↓
op CLI
↓
zsh export または op run
↓
Claude Code / Codex
↓
OpenAI / Supabase / AWS / Resend

AIに頼む

最初に送るプロンプト

Claude CodeやCodexに、今のプロジェクトを1Password対応へ整理させるなら、このプロンプトを使います。

このプロジェクトの環境変数管理を、1Password Developer Platform前提に整理してください。

目的:
- .envにAPIキーやトークンを平文で保存しない
- .envにはop://から始まるsecret referenceだけを書く
- .env.exampleにはキー名だけを残す
- op run --env-file=.env -- npm run dev で開発サーバーを起動できるようにする
- READMEにセットアップ手順を書く

確認してほしいこと:
1. 既存の.env.example、README、package.jsonを確認
2. 必要な環境変数名を一覧化
3. 秘密情報っぽい値がリポジトリに含まれていないか確認
4. .env.exampleには値を書かず、説明だけにする
5. READMEに1Password CLIのインストール、op signin、op runの実行例を追記
6. Next.js、Cloudflare Workers、Supabase、Slack、LINEなど用途別に変数を分類
7. 変更後に実行すべき確認コマンドを出す

安全ルール:
- .envの中身やAPIキーを表示しない
- 実在する秘密情報をログに出さない
- 破壊的なgit操作はしない
- 変更前後の差分を分かりやすく説明する

導入手順

Macで1Password CLIをセットアップする

Macでは、Homebrew、1Password CLI、1Password Macアプリ、CLI連携、ログイン確認の順で進めます。ポイントは、CLIを入れたあとにデスクトップアプリを入れ、アプリ側のCLI連携をONにしてからop signinすることです。

Homebrewを確認する

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

brew -v

MacならHomebrewで入れるのが分かりやすいです。

brew install 1password-cli

インストールできたか確認します。

op --version

CLIを入れたら、次に1Password Macアプリを入れます。ここを飛ばさないでください。この記事では、デスクトップアプリ側の認証とCLI連携を使ってログインさせる前提で進めます。

https://1password.com/downloads/mac/

Macアプリにログインしたら、1Passwordアプリ側でCLI連携をONにします。この設定をONにしてから、ターミナルでop signinします。

1Password → Settings → Developer
↓
Integrate with 1Password CLI

ここまで終わったら、CLI側でログインします。先にデスクトップアプリへログインし、CLI連携をONにしておくと、このop signinでアプリ側の認証を使いやすくなります。

op signin

ログインできているか確認したい場合は、Vault一覧を見ます。

op vault list

複数アカウントや手動セッションが必要な環境では、eval形式を使う場面もあります。

eval $(op signin)

Windows対応

Windows + WSLで1Password CLIをセットアップする

WindowsでClaude CodeやCodexを使うなら、WSL Ubuntu側に開発環境を寄せるのが扱いやすいです。Windowsでも、先にWSL側へCLIを入れたあと、Windows版1Passwordデスクトップアプリを入れてCLI連携をONにしてから、WSL側でop signinします。

WSLを入れる

wsl --install

Ubuntuを初期更新する

sudo apt update
sudo apt upgrade -y

WSLにHomebrewを入れる

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

brew -v

WSL側に1Password CLIを入れる

brew install 1password-cli
op --version

Windows版1Passwordデスクトップアプリを入れる

WSL側にCLIを入れたら、次にWindows版1Passwordデスクトップアプリを入れてログインします。WSL側のopを、Windowsアプリの認証と連携させるためです。

https://1password.com/downloads/windows/

デスクトップアプリ側でCLI連携をONにする

Windowsアプリ側でも、Developer設定からCLI連携をONにします。この設定をONにしてから、WSL側でop signinします。

1Password → Settings → Developer
↓
Integrate with 1Password CLI

デスクトップアプリ連携でWSL側ログインを確認する

Windows版1Passwordアプリへログイン済み、かつCLI連携がONになっている状態で、WSLのUbuntuターミナルから確認します。

op signin
op vault list

うまくいかない場合は、Windows版1Passwordアプリにログイン済みか、アプリが起動しているか、CLI連携がONかを確認してください。

保存設計

Vault作成とAPIキー保存

まず開発用Vaultを作るなら、CLIから作成できます。

op vault create Dev
op vault list

OpenAIのキーなら、次のような構成にします。

Vault: Private
Item: OpenAI
Field: api_key

最初に試すなら、Dev VaultにOPENAI_API_KEYというItemを作り、passwordフィールドへAPIキーを保存する形が分かりやすいです。

op item create \
  --category=password \
  --vault=Dev \
  --title="OPENAI_API_KEY" \
  password="sk-xxxxx"

保存後、参照できるか確認します。ただし、このコマンドは本物の値を画面に出すため、画面共有中やログが残る環境では使わないでください。

op read "op://Dev/OPENAI_API_KEY/password"

Supabaseなら、URL、anon key、service role keyを分けます。

Vault: Production
Item: Supabase
Field: url
Field: anon_key
Field: service_role_key

LINE Botなら、Channel SecretとChannel Access Tokenを分けます。名前は、自分とチームが後から見て分かるものにしてください。

最初に登録しておくと便利な対象は、OpenAI、Claude、Resend、Supabase、Cloudflare、AWS、GitHub Token、SNS連携キー（XやThreadsなどのClient Secret）、LINE Channel Secret、Google Maps API、Vercel、Railwayあたりです。

.env設計

.envをsecret reference化する

1Passwordに値を入れたら、.envには本物の値ではなくsecret referenceを書きます。

OPENAI_API_KEY=op://Private/OpenAI/api_key

複数サービスを使うなら、こうです。

OPENAI_API_KEY=op://Private/OpenAI/api_key
LINE_CHANNEL_SECRET=op://LINE/LINE Messaging API/channel_secret
LINE_CHANNEL_ACCESS_TOKEN=op://LINE/LINE Messaging API/channel_access_token
SNS_CLIENT_SECRET=op://Production/SNS/client_secret
SLACK_BOT_TOKEN=op://Production/Slack/bot_token
SUPABASE_URL=op://Production/Supabase/url
SUPABASE_ANON_KEY=op://Production/Supabase/anon_key
SUPABASE_SERVICE_ROLE_KEY=op://Production/Supabase/service_role_key
CLOUDFLARE_API_TOKEN=op://Production/Cloudflare/api_token

.env.exampleには値を書かず、変数名だけを残します。

OPENAI_API_KEY=
LINE_CHANNEL_SECRET=
LINE_CHANNEL_ACCESS_TOKEN=
SNS_CLIENT_SECRET=
SLACK_BOT_TOKEN=
SUPABASE_URL=
SUPABASE_ANON_KEY=
SUPABASE_SERVICE_ROLE_KEY=
CLOUDFLARE_API_TOKEN=

.envなし運用

.envを使わずzsh exportで読む

より強く「そもそも.envファイルに保存しない」運用にするなら、op readで値を読み、環境変数としてexportします。

export OPENAI_API_KEY=$(op read "op://Dev/OPENAI_API_KEY/password")

確認はできますが、本物のキーが画面に出るため注意してください。

echo $OPENAI_API_KEY

毎回入力するのが面倒なら、zshに永続化できます。

echo 'export OPENAI_API_KEY=$(op read "op://Dev/OPENAI_API_KEY/password")' >> ~/.zshrc
source ~/.zshrc

この状態なら、Claude CodeやCodexを起動するだけで、環境変数が入った状態になります。

claude

codex

ただし、.zshrcに大量のop readを書くと、ターミナル起動が遅くなることがあります。日常的に使うキーだけzshに入れ、それ以外はop runで必要なときだけ読み込む運用が現実的です。

実行方法

op runで実行する

開発サーバーを起動するときは、通常のnpm run devではなく、op runで包みます。

op run --env-file=.env -- npm run dev

ビルドや本番起動も同じ考え方です。

op run --env-file=.env -- npm run build

op run --env-file=.env -- npm start

一時的に参照が正しいか確認したい場合はop readも使えます。ただし値が画面に出るため、日常運用ではop runを優先します。

op read "op://Private/OpenAI/api_key"

AIエージェント運用

Claude Code / Codexとの使い方

Claude CodeやCodexを使う人は、起動前にop runで環境変数を注入できます。

op run --env-file=.env -- claude

op run --env-file=.env -- codex

ただし、AIエージェントに秘密情報そのものを見せる必要はありません。必要な環境変数名だけ確認させ、中身は表示させない運用にします。

.envの値は表示しないでください。
必要な環境変数名だけ確認してください。
APIキー、トークン、Secret、Cookie、秘密鍵の中身はログにも回答にも出さないでください。

本番環境

Next.js / Vercel / Cloudflareでの考え方

ローカル開発と本番環境では、秘密情報の扱いを分けます。ローカルでは1Passwordとop runを使い、本番ではVercel、Cloudflare、Supabaseなど各プラットフォームのSecretsやEnvironment Variablesに登録します。

Supabaseはanon_keyとservice_role_keyの扱いを分けてください。特にservice_role_keyは強い権限を持つため、フロントエンドに出してはいけません。

チーム運用

チーム開発のVault設計

チームで使うなら、Vault分けが重要です。最初はこれくらいで十分です。

Personal
Development
Production
LINE
MyProject
Clients

個人の実験キーはPersonal、開発環境はDevelopment、本番キーはProduction、自社プロダクトはMyProjectのようなプロダクト名、クライアント案件はClientsに分けると、共有範囲を決めやすくなります。

DATABASE_URL=op://Production/Supabase/database_url
OPENAI_API_KEY=op://Development/OpenAI/api_key
LINE_CHANNEL_SECRET=op://LINE/LINE Messaging API/channel_secret

上級運用

direnvと組み合わせる

慣れてきたら、特定のディレクトリに入ったときだけ環境変数を読み込むdirenvと組み合わせる方法もあります。

ただし、初心者はまずop run --env-file=.env -- npm run devからで十分です。自動読み込みは便利ですが、どのタイミングで環境変数が入ったか分かりにくくなる場合があります。

エラー対処

よくあるエラーと対処法

op: command not found

症状: op --versionやop signinを実行すると「op: command not found」と表示され、先へ進めません。

原因: 1Password CLIがまだ入っていないか、CLIは入っているのにPATHが通っていない状態です。特にWSLへHomebrewを入れた直後に起きやすいです。

確認: which opで場所が出るか、brew -vでHomebrew自体が動くかを見ます。

対処: MacやWSLならHomebrewで入れて、確認します。

brew install 1password-cli
op --version
which op

それでも見つからない場合は、インストール完了時に表示されるbrew shellenv系の案内をzshやbashの設定へ反映し、ターミナルを開き直してください。

You are not currently signed in

症状: op vault listやop runを実行すると「You are not currently signed in」と表示されます。

原因: CLIのログインセッションが切れているか、1Passwordアプリが起動していない・CLI連携がOFFになっている状態です。

確認: 1Passwordデスクトップアプリが起動していてロック解除済みか、Settings → DeveloperのCLI連携がONかを見ます。

対処: ログインし直して、Vault一覧が見えるか確認します。直らない場合は、アプリを再起動してロックを解除してからやり直してください。

op signin
op vault list

No accounts configured

症状: op signinしても「No accounts configured」と表示され、ログイン先のアカウントが見つかりません。

原因: 1Passwordデスクトップアプリ側にアカウントでログインできていないか、アプリのCLI連携がOFFのままです。

確認: アプリを開いてアカウントにログインできているか、Developer設定のCLI連携がONかを見ます。

Settings → Developer → Integrate with 1Password CLI

対処: 先にアプリへログインし、CLI連携をONにします。WSLの場合は、Windows版1Passwordアプリを起動したまま、WSL側でop signinをやり直します。

op signin

secret referenceが解決されない

症状: op runで起動してもアプリ側の環境変数が空になる、または参照を解決できないというエラーが出ます。

原因: Vault名、Item名、Field名のどれかが実際の1Password側と違うか、そのVaultへのアクセス権限がない、別アカウントでログインしている、のいずれかが多いです。

確認: 1Passwordアプリで実際のVault名・Item名・Field名を見て、.envの参照と1文字ずつ照合します。Item名にスペースが入っている場合は、そのままの表記かも見ます。

対処: まず参照が単体で読めるか確認し、読めるようになってからop runをやり直します。

op read "op://Private/OpenAI/api_key"

npm run devでは動くのにop runだと動かない

症状: 普通のnpm run devでは起動するのに、op runで包むと起動しない、または環境変数が読み込まれません。

原因: コマンドの書き方が基本形とズレている（--の位置など）、.envのsecret referenceに書き間違いがある、CLIのログインが切れている、のいずれかが多いです。

確認: --より後ろに実行したいコマンドがあるか、.envの各行が変数名=op://...の形かを見ます。

対処: まず基本形に戻し、ログイン状態を確認します。読み込まれない変数が残る場合は、その行の参照だけをop readで単体確認します。

op run --env-file=.env -- npm run dev

WSLで1Password連携がうまくいかない

症状: WSLのUbuntuターミナルでop signinしても認証が通らない、またはアプリ連携が効きません。

原因: Windows版1Passwordアプリが起動していない・未ログイン、WindowsアプリのCLI連携がOFF、WSL側のCLIが正しく入っていない、のいずれかが多いです。

確認: Windows版1Passwordアプリが起動していてログイン済みか、CLI連携がONかを見ます。

1Password → Settings → Developer
↓
Integrate with 1Password CLI

対処: Windowsアプリ側を整えたうえで、WSL側でCLIの状態を順に確認します。WSLはWindows側アプリとLinux側CLIの組み合わせになるため、Macよりも環境差が出ます。詰まったら、1Password公式ドキュメントのWindows / Linux / CLI連携手順を確認してください。

which op
op --version
op signin
op vault list

AIエージェントが.envを読もうとする

症状: Claude CodeやCodexが、作業の途中で.envの中身を開こうとします。

原因: 指示に「読んではいけないファイル」が書かれておらず、エージェントが環境変数の値まで確認しようとしている状態です。

確認: プロジェクトの指示ファイルやプロンプトに、秘密情報の扱いルールがあるかを見ます。

対処: 指示を変えて、読ませるファイルを明確に制限します。秘密情報を扱うプロジェクトでは、AIに読ませるファイルの範囲を最初にルール化しておきます。

.envの値は読まないでください。
.env.exampleとREADMEだけ確認してください。
必要な環境変数名だけ整理してください。

AIプロンプト

AIに聞くための
プロンプト集

エラーが出た時は、画面の文章をそのまま検索するより、状況を整理してChatGPT、Claude、Claude Code、Codexなどに聞く方が早いです。

エラー文はそのまま貼って大丈夫です。ただし、APIキーなど秘密のキーの中身、ワンタイムコード、1Passwordのマスターパスワードは絶対に貼らないでください。

導入するか迷った時

1Passwordで.env管理を始めるべきか、どこから手を付けるか迷った時に使います。

1Passwordで.envのAPIキー管理を始めるか迷っています。

今の管理方法: （例: .envに直書き）
プロジェクトの数:
チームの人数:
使っているPC: （Mac / Windows）
不安なこと:

初心者向けに、導入した方がいいかの判断基準と、最初の一歩を教えてください。

op runがエラーになった時

op runで包むと動かない時に使います。

op run でエラーが出ています。

使っているPC:
実行したコマンド:
表示されたエラー文: （そのまま貼ってOK。キーの中身は貼らない）
op --version の結果: （分かればでOK）
op vault list が動くか:

原因の候補を3つに絞って、確認する順番に教えてください。

WSLで動かない時

WindowsアプリとWSLの連携で詰まった時に使います。

WindowsのWSLで1Password CLIが動きません。

Windows版1Passwordアプリにログイン済みか:
アプリのCLI連携（Integrate with 1Password CLI）はONか:
WSLで op --version が動くか:
op signin で表示されたエラー文: （そのまま貼ってOK。ワンタイムコードは貼らない）

WindowsアプリとWSLの連携で確認する場所を、順番に教えてください。

既存の.envから移行したい時

今の.envを1Password管理へ移す段取りを整理したい時に使います。

今ある.envを1Password管理に移行したいです。

プロジェクトの内容:
.envに入っている変数名の一覧: （変数名だけ。値は絶対に貼らない）
使っているサービス: （例: OpenAI、Supabase、LINE）

VaultとItemの分け方の案と、secret referenceへ書き換える手順を教えてください。

secret referenceの書き方を確認したい時

参照が解決されない時、どこが食い違っているか整理したい時に使います。

secret referenceの書き方が合っているか確認したいです。

.envに書いた参照: （例: OPENAI_API_KEY=op://Dev/OpenAI/api_key）
1Password側のVault名 / Item名 / Field名:
op read で出たエラー文: （本物の値が表示された場合、その値は貼らない）

どこが食い違っているか、確認する順番を教えてください。

チーム共有の設計を相談したい時

Vaultの分け方と共有範囲を決めたい時に使います。

チームで使う1PasswordのVault設計を相談したいです。

チームの人数と役割:
扱っているサービス: （例: OpenAI、Supabase、LINE、Cloudflare）
外部パートナーやクライアントの有無:
今困っていること:

Vaultの分け方、共有範囲の決め方、本番キーの守り方を初心者向けに提案してください。

AIエージェントに安全に使わせたい時

Claude CodeやCodexに秘密のキーを見せない運用を決めたい時に使います。

Claude CodeやCodexに、秘密のキーを見せずに開発を進めたいです。

使っているAIツール:
プロジェクトの内容:
今の起動方法: （例: op run --env-file=.env -- claude）
心配なこと:

AIに読ませないファイルの決め方と、AIへ渡す安全な指示文の例を出してください。

キーが漏れていないか点検したい時

設定が終わったあとの最終チェックに使います。

APIキーが漏れていないか点検したいです。

GitHubへpushしたことがあるか:
.gitignoreに.envが入っているか:
チャットやSlackにキーを貼った記憶があるか:
使っているサービス:

漏れていた場合にやるべきこと（無効化と再発行）も含めて、点検の順番を教えてください。

実務運用

実務での使い方

実務では、Git管理するもの、Git管理しないもの、1Passwordに置くものを分けます。

Git管理する:
- .env.example
- README
- 必要な環境変数名の説明

Git管理しない:
- .env
- 本物のAPIキー
- 秘密鍵
- クライアント固有のトークン

1Passwordに置く:
- OPENAI_API_KEY
- LINE_CHANNEL_SECRET
- SNS_CLIENT_SECRET
- SLACK_BOT_TOKEN
- SUPABASE_SERVICE_ROLE_KEY
- CLOUDFLARE_API_TOKEN

READMEには、実行方法を書きます。新しいメンバーは、1Passwordの権限をもらい、.envにsecret referenceを書き、op runで起動します。

まとめ

AI開発では、秘密情報の管理がかなり重要です。Claude CodeやCodexを使うと開発スピードは上がりますが、OpenAI、Claude、Resend、Supabase、LINE、Slack、Cloudflare、Vercel、GitHubなど、扱うキーも増えます。

まずは、MacまたはWSLでこの流れを作れば十分です。

brew install 1password-cli
op signin
op run --env-file=.env -- npm run dev

.envを使うなら、本物の値ではなくsecret referenceを書きます。

OPENAI_API_KEY=op://Private/OpenAI/api_key

.envを極力使わないなら、zsh側で必要な値だけ読み込みます。

export OPENAI_API_KEY=$(op read "op://Dev/OPENAI_API_KEY/password")

FAQ

.envは完全に不要になりますか？

完全に不要にすることもできますが、最初は.envにsecret referenceを書く運用が分かりやすいです。本物の値ではなくop://...だけを書くのがポイントです。

.env.exampleには何を書けばいいですか？

変数名だけを書きます。説明を加えるのはOKですが、本物のAPIキーやsecret referenceは書かない方が安全です。

Claude CodeやCodexに.envを読ませてもいいですか？

基本的には読ませない方が安全です。.env.example、README、設定ファイルだけを見てもらい、必要な環境変数名を整理してもらう運用にします。

本番環境でも1Passwordを使いますか？

ローカル開発では1Passwordとop runが便利です。本番環境では、Vercel、Cloudflare、Supabaseなど各サービスのEnvironment VariablesやSecretsを使うのが一般的です。

op readとop runはどちらを使えばいいですか？

日常開発ではop runがおすすめです。op readは値を画面に出しやすいため、確認用途に絞る方が安全です。

1Passwordは無料で使えますか？

1Passwordは有料のパスワード管理サービスで、個人向けは月数ドルのプランから使えます。まずは14日間の無料トライアルで、この記事のCLI運用まで試せます。最新の料金とプランは公式サイトで確認してください。

APIキーを間違えてGitHubに上げてしまったらどうすればいいですか？

そのAPIキーはすぐに各サービスの管理画面で無効化し、新しいキーを再発行してください。GitHubの履歴から消すだけでは安全になりません。一度公開されたキーは漏れた前提で扱い、再発行後に1Passwordへ登録し直します。

更新履歴

2026-07-02: タイトルと説明文を見直し。AIに聞くためのプロンプト集、用語集、FAQ2問を追加。エラー対処を症状・原因・確認・対処の形に増強し、コード例を汎用的な名前に整理
2026-05-22: 記事公開

次にやること

うまくいかない場合は公式LINEへ

AIエージェントを仕事で使うなら、プロンプトだけでなく、秘密情報の扱いも整えておく必要があります。

まずは自分のプロジェクトで.env.exampleを見直し、1Passwordに移せるAPIキーを1つだけ移してみてください。最初の1つができれば、他のキーも同じ流れで整理できます。

ただし、ここで詰まったまま適当に進めるのはおすすめしません。APIキー、Cloudflare Token、Supabaseのservice role key、OpenAI APIキー、AWSキーあたりは、置き場所や権限を間違えるとかなり危ないです。

GitHubに漏れたり、本番キーを誤って使ったり、無制限に近い権限のキーをAIエージェントに読ませたりすると、最悪の場合、数十万から数百万円単位の請求や復旧対応につながることもありえます。

「CLI連携がうまくいかない」「WSLでop signinできない」「どのキーを1Passwordに入れればいいか分からない」「.envを消していいか判断できない」という人は、公式LINEから連絡してください。

30分の無料面談で、今のMac / Windows / WSL環境を見ながら、1Password CLI、Claude Code、Codex、OpenAI API、Supabaseまわりの安全な始め方を一緒に整理できます。

公式LINEで相談する AI診断を受ける

1Passwordで.env管理AI開発のAPIキー安全入門