AIコーディングエージェントを本格的に使うと、必ず問題になるのがAPIキーやデータベース接続情報などの「機密情報」です。OpenAIのCodexのようなエージェントは、コードを書くだけでなく、アプリを実行し、テストし、環境設定まで進められるようになっています。しかし、そのために必要な認証情報をプロンプトや.envファイル、リポジトリに置いてしまうと、漏えいリスクが一気に高まります。1Passwordはこの課題に対して、Codex向けのローカルMCP連携を発表しました。
Codexに「秘密そのもの」を渡さない設計
1Passwordは2026年5月20日、OpenAIのCodex向けに「1Password Environments MCP Server」を提供すると発表しました。ポイントは、CodexがAPIキーやシークレット値を直接読むのではなく、1Passwordを“信頼できるアクセス層”として使う点です。認証情報は1Password側でエンドツーエンド暗号化され、ユーザーやグループ、権限設定にもとづいて管理されます。
これまで開発現場では、.envファイル、シェル設定、MCP設定ファイル、サンプルスクリプトなどにAPIキーが残りがちでした。AIエージェントに作業を頼む場合、そのファイルを読み取られたり、モデルの文脈に入ったり、ログや出力に混ざったりする危険があります。1Passwordの今回の連携は、Codexが作業に必要な環境を扱いつつも、秘密の値そのものは見ない、という分離を狙ったものです。
ローカルMCPサーバーがCodexと1Passwordをつなぐ
今回の仕組みでは、1Passwordのパスワードマネージャーと開発者ツールに含まれるローカルMCPサーバーが、Codexと1Password Environmentsの橋渡しをします。CodexはローカルMCP接続を通じて、利用可能な操作を見つけ、環境の作成や変数名の管理などを行えます。一方で、MCP経由でシークレット値を読み取ったり、モデルのコンテキストに表示したり、ディスクへ書き出したりはしない設計です。
1Password公式の説明では、アクセスのたびに1Passwordデスクトップアプリ側でユーザー承認が必要になります。つまり、Codexが勝手に資格情報を使うのではなく、人間が承認した範囲で、必要な処理だけが進みます。アプリ実行時には、1Passwordが必要な環境変数を対象プロセスへ注入し、値はそのプロセスが必要とする間だけメモリ上で使われます。Codexは全体を指揮し、アプリが実行し、1Passwordが資格情報を発行する、という役割分担です。
AI開発の安全対策が「後始末」から「作業中の仕組み」へ変わる
この連携が実務で大きいのは、セキュリティ対策を開発後のチェックだけにしない点です。たとえばCodexに、新しいアプリの環境設定を作らせる、既存リポジトリ内の平文シークレットを探させる、見つかった値を1Passwordへ移し、コード側を参照形式に置き換えさせる、といった流れが想定されています。秘密情報の整理を、別作業ではなく日々の開発フローに組み込めるわけです。
中小企業や小規模チームでは、便利さを優先してAPIキーをローカルファイルに置いたままにしてしまうことがあります。AIエージェントを導入すると、そのリスクはさらに見えにくくなります。今回の1PasswordとCodexの連携は、「AIに任せる作業を増やすなら、AIに渡してよい情報の境界も設計する必要がある」というメッセージでもあります。
まとめ：AIエージェント時代の鍵は「任せ方」と「渡さない設計」
1PasswordとCodexの連携は、AIコーディングの実用化が次の段階に入ったことを示しています。Codexのようなエージェントが実行、テスト、環境構築まで担うなら、認証情報の扱いは避けて通れません。重要なのは、AIに何でも渡すことではなく、AIが仕事を進められるだけの権限を、必要な範囲で、承認つきで与えることです。これからのAI活用では、プロンプトの書き方だけでなく、秘密情報をモデルの外に置いたまま動かす設計が、実務の安心感を左右していきます。
