1PasswordとCodexはすでに連携していた。APIキーをAIに見せず使う「Environments MCP」とは
1Password for Claudeの発表を調べていて、筆者は1PasswordとOpenAIのCodexがすでに連携していたことを知りました。発表は2026年5月20日。Claude版より約2カ月早く、「1Password Environments MCP Server for Codex」として公開されています。
どちらもAIへ秘密を直接見せないための連携ですが、担当する仕事はかなり違います。Claude版がWebサイトへのログインを助ける仕組みなら、Codex版はAPIキーやデータベースの認証情報を、コードやプロンプトへ書かずにアプリを動かすための仕組みです。
個人でAIを使ってアプリやWebサービスを作る人にとっても、これは企業だけの話ではありません。Codexへ「このAPIキーを使って動作確認して」と渡した経験があるなら、まさに関係する機能です。
Codex版は「開発中の秘密」を扱う
Codexはコードを書くだけでなく、作ったプログラムを実行し、APIへ接続し、データベースを操作し、公開前のテストまで進められます。そこで必要になるのが、APIキー、アクセストークン、データベースのパスワードといった「シークレット」です。
これまでは、こうした値を.envファイルへ保存したり、ターミナルで環境変数として設定したりする方法が一般的でした。.envはGitへ登録しない設定にしていても、パソコンの中には平文で残ります。Codexがプロジェクト全体を読める状態なら、作業に必要なファイルと一緒に秘密の値までコンテキストへ入る可能性があります。
1Password Environments MCP Server for Codexは、Codexを「秘密を保管する人」ではなく「許可された処理を実行する作業者」として扱います。Codexは変数名や環境の構成を扱えますが、元の値を受け取る必要はありません。
1Password for Claudeとの違い
両者は同じ金庫を使いながら、秘密を届ける先が異なります。
| 比較する点 | 1Password for Claude | 1PasswordとCodex |
|---|---|---|
| 主な目的 | Webサイトへログインする | アプリや開発ツールを動かす |
| 扱うもの | ユーザー名、パスワード、ワンタイムコード | APIキー、トークン、データベース認証情報など |
| 秘密の届け先 | ブラウザのログインフォーム | 許可された実行中のプロセス |
| 接続の中心 | Claudeアプリ、ブラウザ拡張、1Password | Codex、ローカルMCP、1Password Environments |
| 身近な例 | 予約サイトや管理画面へ入る | 外部APIを使うアプリを実行する |
Claude版は、金庫から取り出した秘密を1PasswordがWebページへ直接入力します。Codex版では、1Passwordが実行時に必要な変数をアプリのプロセスへ注入します。CodexのMCP経由で生の値を返したり、モデルのコンテキストへ載せたり、ディスクへ書き込んだりしない設計です。
実行時だけ秘密を渡す流れ
- 利用者がCodexへ、アプリの作成や動作確認を依頼する
- Codexがローカルで動く1PasswordのMCPサーバーへ、必要な環境操作を依頼する
- 1Passwordアプリが本人確認と権限を確認し、利用者がアクセスを承認する
- Codexが環境や変数名を管理し、実行するアプリを指定する
- 1Passwordが必要な値を、そのアプリのプロセスへ実行時だけ注入する
値が存在するのは、承認されたプロセスのメモリ上で必要な間だけです。Codexはアプリを動かせても、秘密の文字列そのものを読む必要がありません。公式説明では、1Passwordとの各操作に利用者の明示的な承認が必要とされています。
新規開発だけでなく、すでに置いた秘密の片付けにも使える
この連携でできるのは、最初から安全な環境を作ることだけではありません。1Passwordは、Codexにリポジトリを調べさせ、コードや設定ファイルへ平文で残ったシークレットを見つけ、1Passwordへ移し、参照へ置き換える使い方も案内しています。
.envファイルを配らずに、新しい開発環境を用意する- コードへ直接書かれたAPIキーを見つける
- 秘密の値を1Passwordへ移し、コード側は参照に置き換える
- 開発用の構成をもとに、検証環境や本番環境を分けて管理する
特に大きいのは、「セキュリティの片付け」を開発とは別の作業にしなくてよい点です。Codexへ修正を頼む流れの中で、秘密の置き場所まで整えられます。
まず確認したい3つの場所
この連携をすぐ導入しない場合でも、Codexを使っているプロジェクトでは次の3点を確認する価値があります。
- チャットや指示文：APIキーをそのまま貼っていないか
- コードと設定ファイル：キーやパスワードを直接書いていないか
.envとGit履歴：除外設定だけで安心し、過去のコミットへ秘密が残っていないか
一度でも公開リポジトリやAIの会話へ貼った秘密は、場所を移すだけでは十分ではありません。元のAPIキーやトークンを無効化し、新しいものへ交換する必要があります。最初から開発専用の権限が小さいキーを使い、本番用の秘密をいきなり渡さないことも大切です。
安全になるのは「秘密の受け渡し」であって、実行結果ではない
1Password連携を使えば、CodexがAPIキーを直接読むリスクは下げられます。ただし、承認されたアプリはその資格情報を使って外部サービスへ接続できます。間違ったコードがデータを削除したり、APIを大量に呼び出したりする可能性まで、1Passwordが防いでくれるわけではありません。
最初はテスト環境と読み取り専用の資格情報を使い、実行するコマンドと接続先を確認する。秘密を隠す仕組みと、AIへどこまで操作を許すかという判断は、分けて考える必要があります。
現時点ではMac向け。利用前に環境を確認
1Password Marketplaceでは、Codex向けMCP連携は2026年7月18日時点でmacOSのみ対応と案内されています。1PasswordとOpenAIの両方を利用し、1Password Password Managerと開発者向け機能へアクセスできることが前提です。
個人利用者は1Password Labsから機能を有効にします。1Password Enterprise Password Managerを使う組織では、管理者が「1Password Environments」のベータポリシーを有効にしたうえで、各利用者もオプトインする必要があります。提供条件や設定画面は変わる可能性があるため、導入時はMarketplaceの手順を確認してください。
Claudeはログイン、Codexは実行環境と覚える
1Password for ClaudeとCodex連携は競合する機能ではありません。Webサイトへ入って作業するClaudeにはログイン情報を安全に届け、コードを動かすCodexには実行時のシークレットを安全に届けます。
Codexで外部APIやデータベースを使っているなら、今日できる最初の一歩は、プロジェクト内の.envとハードコードされたキーを確認することです。秘密をAIへ覚えさせるのではなく、必要な処理にだけ短時間使わせる。Codex版の1Password連携は、その考え方を普段の開発へ持ち込む仕組みです。
参考：1Password「1Password is now a trusted access layer for OpenAI’s Codex」、1Password Press Release、1Password Marketplace「1Password Environments MCP Server for Codex」、窓の杜「『1Password』が『Codex』と連携」。提供状況・仕様は2026年7月18日時点の情報です。記事内の安全性に関する説明は1Passwordの公式資料に基づき、筆者は本連携を実環境では検証していません。
