AI開発セキュリティ

1Password CLI設定
Mac/WSL完全手順

この記事のゴール

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設計
よくあるエラーと対処法

前提理解

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

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

OPENAI_API_KEY
ANTHROPIC_API_KEY
LINE_CHANNEL_SECRET
LINE_CHANNEL_ACCESS_TOKEN
THREADS_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、Threads OAuth、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
THREADS_CLIENT_SECRET=op://Production/Threads/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=
THREADS_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
BuzzTweet
Clients

個人の実験キーはPersonal、開発環境はDevelopment、本番キーはProduction、クライアント案件は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

1Password CLIが入っていません。MacならHomebrewで入れます。

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

WSLへHomebrewを入れた直後は、HomebrewのPATHが通っていないことがあります。インストール完了時に表示されるbrew shellenv系の案内をzshやbashの設定へ反映してください。

You are not currently signed in

CLIでログインできていません。

op signin
op vault list

No accounts configured

1Passwordアプリ側にログインできていない可能性があります。アプリにログインし、Developer設定のCLI連携を確認してください。

Settings → Developer → Integrate with 1Password CLI

WSLの場合は、Windows版1Passwordアプリを起動したまま、WSL側でop signinをやり直します。

op signin

secret referenceが解決されない

Vault名、Item名、Field名のどれかが違う可能性があります。

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

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

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

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

そのうえで、WSL側でwhich op、op --version、op signinを確認します。

which op
op --version
op signin
op vault list

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

指示を変えて、.env.exampleとREADMEだけを見てもらいます。

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

実務運用

実務での使い方

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

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

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

1Passwordに置く:
- OPENAI_API_KEY
- LINE_CHANNEL_SECRET
- THREADS_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を使うのが一般的です。

次にやること

うまくいかない場合は公式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 CLI設定Mac/WSL完全手順