AIに​鍵を​渡す ──1Passwordの​新しい​仕組みで​「.envに​手打ち」を​やめる

AIに仕事を任せる話をしていると、最後に必ず同じ問いが残る。「そのAIに、うちのパスワードやAPIキーを渡して大丈夫なのか」。

答えは長いあいだ「渡すしかない」だった。開発の現場では、鍵を書いたファイルをパソコンに置き、同じ値をクラウドの管理画面にも手で入力する。平文のまま、あちこちに。パスワード管理のサービスに毎月お金を払っていても、そこだけ手作業が残っていた。

その前提を変える仕組みが出ている。AIには鍵の「名前」だけを見せ、値そのものは見せないという作りだ。この記事では4つを扱う。①何をする仕組みなのか ②何が新しいのか ③実際に繋いでみてどうだったか ④使う前に知っておくこと。③には、書いておきたい失敗がひとつある。「これは使えない」と結論して、3日間ずっと手作業を続けていた。

01 何を​する​仕組みなのか──値を​見せずに​鍵を​渡す

1Password が「Environments（環境）」という機能を出している。プロジェクトごとに使う環境変数——APIキーや接続情報——を、1Passwordの中にまとめて置くものだ^[1]。

ここまでなら、よくある金庫の話に聞こえる。効いてくるのは、そこにAIエージェント用の窓口（MCPサーバー）が付いていることだ。AIがその窓口を叩くと、変数の一覧は返ってくるが、返るのは名前だけで値は返らない。値は、プログラムが実際に動く瞬間にだけ実行環境へ渡る。

もうひとつ、公式ドキュメントに「平文の秘密をディスクに書かずに、ローカル開発中に環境変数を使えるようにする」と書かれた機能がある^[1]。鍵を書いたファイルが、パソコンから消えるということだ。正確には、ファイルは存在するが中身を持たない形に変わる。

02 何が​新しいのか──AI特有の​漏れ道が​塞がる

鍵の管理そのものは新しい話ではない。新しいのは漏れ方のほうだ。

AIエージェントは、作業環境の文脈を読み取り、推論し、コマンドを出す。つまり読んだものが指示文に入り、出したものが出力に残り、その両方が記録として保存されうる。従来の鍵管理の仕組みが設計された時代には、この経路は存在しなかった。

1Passwordのブログにも、AI支援の開発環境で「モデルの文脈に秘密を入れないまま」認証情報を注入するという言い方が出てくる^[2]。「AIに値を返さない」ことが、機能ではなく仕様として要る——そこが今回の新しさになる。

そして実際に繋いで確かめたところ、これは運用上の心がけではなく作りとして担保されていた。AI用の窓口が持っている道具は8つで、そのなかに値を読み出す道具が無い。一覧を求める道具が返すのは変数の名前だけだった^[3]。渡さないよう気をつけるのではなく、渡す口が存在しないという形になっている。

ここが、これまでのやり方との分かれ目でもある。同じ1Passwordを使う方法として、コマンドで値を取り出して環境変数として渡すやり方が以前からあり、日本語の解説記事もその形が主流だ。ただしその場合、値はコマンドの出力にいったん現れる。AIがそのコマンドを動かす前提だと、出力も記録も経路に入る。今回の作りは、そこを構造から外している。

03 繋いでみた​──「使えない」と​3日間書いていた

ここからは実際にやってみた話になる。結論から言うと繋がったが、その前に3日間の遠回りがあった。

日付	起きたこと
8月27日	1Passwordのコマンドを試したら動いた。作業メモに「これは不要」と書いた
8月29日	別の作業で同じことを試したら、無反応のまま止まった
8月30日	もう一度試しても、やはり止まる

原因は、探し回るまでもなく設定画面に書いてあった。1Passwordには「新しいものごとに承認を求める」という設定があり、その対象に「ターミナルセッション」が含まれている。新しいターミナルから使うたびに、指紋認証などの承認を求める、という意味だ。

ここでAIが絡むと厄介なことになる。AIがコマンドを動かす窓口は、毎回「新しいターミナルセッション」として扱われる。だから毎回、承認を求める。人が画面を見ていないので、誰も押さない。エラーも出ないまま、静かに止まる。

では8月27日はなぜ動いたのか。そのとき本人が画面の前にいて、承認を押していただけだった。1Passwordは承認をしばらく覚えているので、その日はずっと通る。アプリを再起動すれば忘れる。

問題は、その1日の結果を「使えない」と記録に書いてしまったことだ。作業メモの先頭に「不要」の1行が3日間残り、その間ずっと、クラウドの管理画面と設定ファイルに手で値を入力し続けていた。正しい道は最初からあったのに、間違った記録がそれを塞いでいた。

AIに任せるときにいちばん危ないのは、間違った記録が正しい道を塞ぐことだ。1回動いたことを「使える」と書き、1回止まったことを「使えない」と書く——どちらも、次に読む人（自分を含む）にとっては確定した事実として働く。

04 何が​変わるのか──ファイルから​中身が​消える

設定を直したあと、AIの窓口（MCPサーバー）経由で最後まで通した。手順としては、認証する → 環境を作る → 変数を入れる → プロジェクトにローカル用のファイルを作るという並びになる。

できあがったファイルを確認すると、大きさは0バイトだった。通常のファイルではなく、読まれた瞬間にだけ値が流れる形式（名前付きパイプ）で作られている。つまり平文の鍵がディスク上に存在しない。公式ドキュメントの「平文の秘密をディスクに書かずに」という説明^[1]は、文字どおりの意味だった。

項目	これまで	これから
鍵の置き場	パソコンのファイルに平文で	1Passwordの中だけ
AIが見るもの	ファイルを読めば値そのもの	名前だけ
同じ値を入れる回数	手元のファイル＋クラウドの管理画面	1Passwordに1回 （本番側は後述）
ファイルの中身	平文の文字列	0バイト（読まれた時だけ値が流れる）

経営の言葉に直すと、「鍵の管理場所が1つになり、AIに渡すのは名前だけで済むようになった」ということになる。今まで払っていたパスワード管理の費用が、ようやく開発の現場まで届く形になった、とも言える。

05 使う​前に​知っておく​こと​──4つの​前提と、​まだ​通していない​1段

• 本番環境の設定は別のまま。 この仕組みは開発中のパソコン向けで、クラウド側（本番）の環境変数を入れる作業は残る。「1回入力すれば全部済む」ではない。
• 人がいない時間に動く自動処理には使えない。 承認を押す人がいないためだ。定時実行のような無人の処理には、サービスアカウント方式など別の手段が要る。
• ベータ提供である。 公式ブログでも、この読み取り機能は「ベータ」と書かれている^[2]。仕様は変わりうる前提で使う。
• 最初に鍵を登録するのは人。 値を扱う一番はじめの一手は人間に残る。そこは無くならないし、無くさないほうがいい。
• デスクトップアプリが前提。 変数を扱うにはアプリを起動してロックを解除しておく必要がある^[1]。「サーバーだけで完結」はしない。

そして、正直に書いておきたいことがひとつ。作ったファイルを実際にアプリケーションが読んで起動するところは、まだ通していない。名前付きパイプは「一度読んだら閉じる」性質があるため、設定を何度も読み直すプログラムでは詰まる可能性がある。ここは次に確かめる予定で、確かめる前に「使える」と書かないことにした。3日間の遠回りが教えてくれたのは、まさにその順番だった。

06 まとめ──渡し方が​変わると、​置き場所が​減る

問い	いまの答え
AIに鍵を渡して大丈夫か	値を渡さない渡し方ができた。AIが受け取るのは名前だけ
手元のファイルはどうなるか	中身が0バイトになり、読まれた瞬間にだけ値が流れる
手入力は無くなるか	減るが無くならない。本番側の設定と、最初の登録は残る
無人の自動処理に使えるか	使えない。承認する人がいないため別方式が要る

私たちも自分たちの開発環境で実際に通した。詰まった箇所と設定の勘所は上に書いたとおりで、いちばん時間を取られたのは技術ではなく、自分で書いた1行の記録だった。

AIに任せる範囲を広げるほど、「どこまで渡すか」を仕組みで決めておく価値が上がる。鍵の渡し方は、その最初の一段になる。

関連記事 ｜ 渡したあとの話社員のAI利用を、会社はどこまで見られるか ──8月26日に重なった3つの統制機能と、放置したときに倒れる向き →