.envを1Passwordと連携して複数端末で同じ認証環境を構築する

  • URLをコピーしました!

開発では、APIキーやパスワードといった認証情報を.envファイルに書くことが多い。このファイルは機密情報の塊だから、Gitにプッシュしてはいけない。一方で、自宅PCと会社PC、あるいは複数マシンで同じプロジェクトを触る場合、.envを手動でコピーしたり中身を貼り直したりする手間が発生する。私は1Passwordと連携することで、1Passwordが入っている環境ならどこでも同じ「.envの参照」から認証情報を取得できるようにした。1Password CLIの導入と、.envに書く参照形式さえ整えれば、生体認証(Touch IDやApple Watchなど)でサインインするだけで、どの端末でも同じ開発環境が再現できる。さらに、Claude CodeやCursor、Codex、Anti-Gravityなど、普段使っているAIコーディングツールに「.envを1Passwordから取得するようにしてほしい」と依頼するだけで、誰でも同じ仕組みを用意できる。この記事では、.envと1Passwordを連携させる手順と、複数端末・AIツールでも同じ認証環境を実現する方法をまとめる。

目次

.envは機密情報だからGitに含めない

.envファイルには、データベースの接続情報、APIキー、アプリケーション用パスワードなど、漏らしてはいけない値が並ぶ。これをリポジトリにコミットすると、履歴に残り続け、クローンした誰もが同じ機密にアクセスできてしまう。そのため、.envは.gitignoreに含め、リポジトリには載せないのが鉄則だ。

ただし、開発する端末が複数あると「どのマシンにも同じ.envを用意する」必要が出てくる。USBでコピーしたり、チャットで自分に送ったり、手動で値を打ち直したりするのは手間で、打ち間違いやバージョンずれも起きやすい。ここを解消するのが、1Passwordとの連携である。

1Password連携の考え方:.envには「参照」だけ書く

1Passwordには、パスワードやメモを「アイテム」として保存する機能がある。ここに、開発で使う環境変数名と値をカスタムフィールドとして登録しておく。.envファイルには、実際の値ではなく「op://ボルト名/アイテム名/フィールド名」という形式の参照だけを書く。実行時に1Password CLIがこの参照を解決し、実際の値に置き換えてくれる。

こうすると、.envファイルの中身は機密ではなくなる。参照の並びだけなので、Gitにコミットしても問題ない。代わりに、各端末では1Passwordにサインインしておけば、同じ.envから同じ認証情報が得られる。.envファイルを手で移し替える必要はなくなる。

1Password CLIのインストールと.envの参照形式

まず、1Password CLIを入れる。macOSならHomebrewで次のようにする。

brew install --cask 1password-cli

インストール後、ターミナルでop signinを実行すると、ブラウザまたは1Passwordアプリが開き、Touch IDやマスターパスワードで認証できる。Apple Watchを着用していれば、Watch側で承認するだけでサインインできる。一度サインインすると、一定時間はキャッシュされるので、その間は都度認証しなくてよい。

次に、1Password側で「開発用」のアイテムを作成し、必要な環境変数名と値をカスタムフィールドとして登録する。例として、WordPressの認証用なら「WP_URL」「WP_AUTH」といった名前でフィールドを追加する。

.envには、実際の値の代わりに次のように参照を書く。

WP_URL="op://Private/remomaga WordPress/WP_URL"
WP_AUTH="op://Private/remomaga WordPress/WP_AUTH"

Privateはボルト名、remomaga WordPressはアイテムのタイトル、その後のWP_URLやWP_AUTHはフィールド名である。引用符で囲むのを忘れないこと。

スクリプトや開発サーバーを動かすときは、op runで.envを読み込んでからコマンドを実行する。

op run --env-file=.env -- pnpm run publish:remomaga

こうすると、.env内の1Password参照がその場で実際の値に置き換えられ、コマンドには安全に渡される。

AIコーディングツールで「1Passwordから.envを読む」ように依頼する

Claude Code、Cursor、Codex、Anti-Gravityなど、普段使っているAIコーディングツールに、次のような依頼をするとよい。「このプロジェクトでは.envに1Passwordの参照(op://…)を書いている。スクリプト実行時や開発サーバー起動時は、op run –env-file=.env を使ってほしい」と伝えれば、ツールがpackage.jsonのスクリプトを書き換えたり、実行コマンドをop run付きで提案したりしてくれる。

私の場合は、各ツールのルールやプロンプトに「環境変数は1Password参照の.envから取得する」と明記し、スクリプト例としてop runの使い方を書いておいた。そうすると、AIがターミナルコマンドやnpmスクリプトを書くときに、自然とop runを挟んだ形で提案してくれる。自分で毎回op runを打つ必要も、ツールごとに手順を覚える必要もなくなる。

複数端末でも同じ手順で揃う

新しいPCや別のマシンで同じプロジェクトを始めるときは、その環境に1Password CLIを入れ、op signinでサインインするだけだ。リポジトリをクローンすれば、.env(参照だけが書かれたファイル)はすでに含まれているか、あるいはテンプレートとして共有されている。あとはop run付きでコマンドを実行すれば、その端末でも同じ認証情報が使える。生体認証やApple Watchで認証できるため、パスワードを毎回打ち直す手間も少ない。

まとめ

.envには認証情報を直書きせず、1Passwordへの参照(op://…)だけを書く。1Password CLIを入れ、op signinでサインインし、実行時はop run –env-file=.envでコマンドを動かす。これで、.envを手動で移し替えずに、1Passwordが入っているどの端末でも同じ認証環境を再現できる。さらに、使っているAIコーディングツールに「.envは1Password参照なので、op runで実行してほしい」と一度依頼しておけば、誰でも同じやり方で環境を揃えられる。複数端末での開発が増えているなら、.envと1Passwordの連携を試してみる価値は十分にある。

この記事が気に入ったら

  • URLをコピーしました!
  • URLをコピーしました!
目次