生成AIにパスワードを打ち込む前に｜安全な管理はmacOSキーチェーンで

生成AIに面倒な作業をまるごと任せたいのに、パスワードの扱いが怖くて手前で止まっていませんか。

実は私も、「毎回チャットで渡せばファイルに保存されないから安全だろう」と思い込んでいた時期がありました。

この記事では、チャット欄に打ち込んだ文字列が実際にはどこに残るのかを、経路ごとに分解して整理します。そのうえで、macOSに最初から入っているキーチェーンにパスワードを預け、生成AIには一度も見せないまま自動化を回す方法を、実際に検証した手順で紹介します。

しかも今回は、AIが自分の出した助言を検証して撤回するという場面まで起きました。生成AI講師として登壇してきた現役教員が、自分の環境で確かめた記録をもとに解説します。最後まで読んで、明日から安全な預け方に切り替えていきましょう。

この記事を読めば、生成AIにパスワードを渡さずに自動化する仕組みが作れて、「安全のために便利さを諦める」という二択から抜け出せます。

この記事では、次の流れで解説します。

それでは、順番に説明していきましょう。

注意
この記事の内容は読者の皆さんで検証が必要です。必ずこれが正確とは思わないでください
この記事に書いてあることはセキュリティ関係のことです。筆者はその専門家ではありません。Claude Codeと対話して「現在自分の環境なら安全」といわれたことをやっているだけです。
以上のことを踏まえて読んでください。

---

生成AIのチャットに打ったパスワードはどこに残るのか

「ファイルに保存しなければ安全」という前提そのものが、実は誤りです。会話は消えているのではなく、別の形のファイルとして残り続けています。この節では次の3点を説明します。

まずは、パスワードがどの経路をたどるのかを分解して見ていきましょう。

チャットの会話はローカルにファイル保存されている

チャット欄に打ち込んだ文字列は、会話ログのファイルに平文で残ります。過去のセッションを後から再開できるということは、その会話がどこかに保存されているということだからです。

実際、Claude Codeの場合は~/.claude/projects/配下に、プロジェクトごとのJSONLファイルとして会話が蓄積されていきます。画面をスクロールして見えなくなることと、記録から消えることは、まったく別の話なのです。

打ち込んだパスワードはAPIにも送信されている

さらに、チャットに書いた時点で、その文字列は会話の一部としてサーバーへ送信されています。生成AIは会話全体を読み直して応答を組み立てる仕組みなので、「この一行だけは送らない」という選択肢がそもそも存在しないためです。

これはClaude Code固有の話ではありません。ChatGPTでもGeminiでも、履歴が残る仕組みである以上、同じ構造になります。チャット欄はメモ帳ではない、という一般則として覚えておくのが安全です。

「ファイルに書かない」と「会話に出さない」は別物

守るべき対象は「保存先」ではなく「経路」です。通り道をふさがない限り、パスワードは形を変えて別のファイルに残り続けるからです。

私が最初にAIへ出した指示は「パスワードはそのたびに私から受け取る。プロジェクトに保存しない」というものでしたが、これは安全策どころか、最も避けるべきやり方でした。安全設計の第一歩は、値が通る道をすべて数え上げることなのです。

---

生成AIにパスワードを渡さない安全な仕組み｜macOSキーチェーン

経路をふさぐ方法はひとつです。パスワードを、生成AIの目が届かない場所に置いてしまうこと。Macを使っているなら、その保管庫は最初から入っています。この節では次の3点を説明します。

仕組みを順番に見ていきましょう。

キーチェーンはmacOS標準の暗号化された金庫

パスワードの保管は、OSに任せるのがいちばん安全で手間もかかりません。macOSが暗号化して管理し、どのプログラムに読み出しを許すかまで制御してくれるからです。

実際にこれは、Safariがパスワードを覚えておいてくれるのと同じ仕組みで、それをコマンドラインから使うだけの話です。新しいツールを契約したり、追加でインストールしたりする必要は一切ありません。

パスワードはスクリプトだけが読み出す

生成AIには「スクリプトを呼ぶ」役割だけを与え、値そのものには触れさせません。値がAIの文脈に一度でも入れば、そのまま会話ログに戻ってしまうからです。

私の環境では、WordPressへの入稿スクリプトの内部だけがキーチェーンを読みに行く構成にしました。この形にすると、パスワードは一度もチャットに登場しないまま、自動化だけが回り続けます。

ChatGPT・Geminiでも考え方は同じ

この発想は、特定のAIツールに限った話ではありません。履歴が残る仕組みである以上、どのサービスを使っても同じ経路が生まれるからです。

WindowsやLinuxにも、資格情報マネージャーやシークレット管理の仕組みが用意されています。ツールが変わっても、「値を会話に出さない」という原則そのものは変わりません。

---

パスワードを安全に登録する3ステップ

ここからは、実際に私がWordPressの自動入稿用パスワードを登録した手順を、そのままの形で紹介します。他のサービスでも読み替えて使える内容です。この節では次の3点を説明します。

順番に進めていきましょう。

ステップ1　サービス側で専用パスワードを発行する

自動化に使うのは、普段ログインに使っているパスワードではなく、用途別に発行した専用のパスワードにします。万が一漏れたときに、その用途だけを失効させれば被害を止められるからです。

WordPressの場合は、管理画面の「ユーザー」→「プロフィール」を開き、ページ下部の「アプリケーションパスワード」まで進んで、用途がわかる名前を付けて発行します。発行すると24文字の文字列が表示されますが、この画面を離れると二度と表示されないので、その場でコピーしてください。

なお、この画面を記事やSNSのスクリーンショットに載せる場合は、ユーザー名も必ずマスクしてください。管理画面のユーザー名は、それ自体が攻撃の足がかりになります。

ステップ2　ターミナルでキーチェーンに登録する

登録作業は、生成AIのセッション内ではなく、必ず通常の「ターミナル」アプリで行います。理由は次の章で詳しく説明しますが、AIの画面から実行すると、キーチェーンを使う意味そのものが消えてしまうためです。

ターミナルを開いて、次のコマンドを実行します。

security add-generic-password -a あなたのユーザー名 -s myblog-wp -T /usr/bin/security -w

実行すると、パスワードの入力を2回求められます。ここで先ほどコピーした文字列を貼り付けてください。

password data for new item:        ← パスワードを貼り付けて Enter
retype password for new item:      ← もう一度貼り付けて Enter

入力中は画面に何も表示されません。伏せ字すら出ないので不安になりますが、これが正常な動作です。何も表示されないままプロンプトが戻ってくれば、登録は成功しています。

それぞれのオプションの意味は次のとおりです。

部分	意味
-a あなたのユーザー名	アカウント名。対象サービスのログインユーザー名を書く
-s myblog-wp	サービス名。この保管庫につける名前。スクリプトはこの名前で探す
-T /usr/bin/security	読み出しのたびに確認ダイアログを出さないようにする
-w（末尾・値なし）	パスワードをその場で対話入力する

ステップ3　登録できたかを存在確認だけで確かめる

登録できたかどうかは、中身を見ずに「あるかないか」だけを確認します。値を画面に表示させた時点で、ターミナルの表示にもスクロールバックにも残る可能性が生まれるからです。

次のコマンドは、検索結果を捨てて成否だけを判定するので、パスワードは一切表示されません。

security find-generic-password -s myblog-wp >/dev/null 2>&1 && echo "登録済み" || echo "未登録"

「登録済み」と表示されれば完了です。確認の場面でも値を出さない癖をここでつけておくと、後々の事故が確実に減ります。

---

生成AIのパスワード管理でやってはいけない3つのこと

ここが今回、いちばん学びの大きかった部分です。手順どおりに進めたつもりでも、この3つを踏むと、キーチェーンを使う意味が失われます。この節では次の3点を説明します。

ひとつずつ、実際にやりかけた失敗として説明します。

AIのセッション内で登録コマンドを実行する

キーチェーンへの登録操作を、生成AIの画面から実行してはいけません。securityコマンドはパスワードを標準入力から読み込むため、AIのセッション内で実行すると、入力した値がそのセッションに取り込まれる可能性があるからです。

そして、この点はAI自身も最初は間違えていました。Claude Codeは当初、「!を付ければこのセッションから実行できます」と案内してきたのです。ところがその後、自分で挙動を検証したうえで、こう前言を撤回しました。

先に訂正させてください。検証したところ、securityコマンドはパスワードを標準入力から読み込みます。つまりClaude Code内で実行すると、入力したパスワードがセッションに取り込まれる可能性があり、キーチェーンを使う意味そのものが失われます。

金庫を買ってきて、泥棒の目の前で暗証番号を設定するようなものです。守りたい相手の前で、守るための操作をしてはいけません。

コマンドにパスワードを直接書く

-wオプションの後ろにパスワードを書いてしまうと、シェルの履歴ファイルに平文で残ります。~/.zsh_historyには、打ち込んだコマンドがそのままの形で記録されていくからです。

# ダメな例：コマンド履歴に平文で残る
security add-generic-password -a user -s myblog-wp -w 'abcd EFGH ijkl MNOP'

# 良い例：その場で聞かれるので履歴に残らない
security add-generic-password -a user -s myblog-wp -w

「ファイルに書かないようにしていたのに、別のファイルに残っていた」という点で、これは記事の冒頭で見た落とし穴とまったく同じ構造です。値は、通り道のどこかで必ず記録されようとします。

オプションの意味を確かめずにコピペする

-T /usr/bin/securityは、便利さと安全のつまみを動かすオプションです。これを付けずに登録すると、スクリプトが読み出そうとするたびに、macOSが「securityがキーチェーンの情報にアクセスしようとしています」という確認ダイアログを出します。自動化したはずなのに、毎回クリックが必要になるわけです。

私の環境でダミーの値を使って検証したところ、-T /usr/bin/securityを付けた場合はダイアログなしで読み出せ、付けない場合は読み出しのたびに確認を求められました。ただし裏を返せば、付けるということは「そのMacのターミナルを使える人なら誰でも読める」状態にするということです。

自分専用のMacなら自動化を優先して付ける、共用の端末ならあえて付けないという判断になります。ネットで拾ったコマンドは、意味を自分の言葉で説明できるようになるまで実行しないでください。

---

登録したパスワードを確認・削除する方法

登録しっぱなしにせず、確認と削除まで含めて運用します。失敗しても消してやり直せると分かっていれば、安心して試せるからです。この節では次の2点を説明します。

順番に押さえておきましょう。

登録内容を確認する2つの方法

確認には、存在だけを見る方法と、中身まで見る方法の2種類があります。生成AIに任せてよい範囲と、自分の手で行う範囲を分けるためです。存在確認は前章のコマンドで十分で、ここまでならAIに実行させても値は表に出ません。

中身まで確認したいときは、次のコマンドを自分の手でターミナルから実行します。

security find-generic-password -a あなたのユーザー名 -s myblog-wp -w

コマンドが苦手なら、アプリケーションの「ユーティリティ」にある「キーチェーンアクセス」を開き、サービス名で検索しても確認できます。いずれにせよ、値を表示させる操作だけは、AIに任せず自分で行ってください。

削除してやり直す

パスワードを再発行したときや、登録をやり直したいときは、次のコマンドで削除できます。

security delete-generic-password -s myblog-wp

古い値が残ったままだと、新しいパスワードを発行しても認証に失敗し続けます。おすすめは、本番の値を入れる前に、捨ててよいダミーの値で「登録→存在確認→削除」を一周してみることです。

私もこの一周をやってから本番の値を入れました。手順を体で覚えてしまえば、本番で慌てることがなくなります。

---

生成AIに与える権限を安全に線引きする方法

仕組みを作っても、運用のルールがなければ守られません。生成AIに何を許し、何を許さないのかを、文章として残しておく必要があります。この節では次の3点を説明します。

線引きの実例を見ていきましょう。

AIは「存在確認まで」と決める

値の取り出しはスクリプトの内部だけに限り、生成AIができるのは存在確認までとします。この一線をあいまいにしておくと、AIは善意で「確認しておきますね」と値を読みに行ってしまうからです。

私はプロジェクトのルールに、「値を取り出すコマンドを実行してはならない」とコマンド名まで書いて明記しました。禁止事項は、抽象的な心構えではなく、具体的な操作名まで特定して書くのが効きます。

ルールを指示書に明文化する

このルールは、口頭の約束ではなくプロジェクトの指示書ファイルに書きます。会話は流れていきますが、指示書は毎回読み込まれるからです。

実際、ルールを書いて以降、AIは認証の確認をするときも自分で値の取り出しコマンドを叩かず、スクリプト経由で確認していました。ルールは、書けば守られます。書かなければ、存在しないのと同じです。

なお、生成AIの会話履歴がどこまで残るのかについては、Claude Codeのセッション管理を検証した記事でも詳しく扱っています。あわせて読むと、なぜここまで線引きにこだわるのかが立体的に見えてくるはずです。

投稿せず認証だけを確かめる仕組みを持つ

登録が終わっても、それだけでは本当に認証が通るかどうかは分かりません。そこで私は、本番の投稿を一切せず、ログインの可否だけを確認する機能をスクリプトに足しました。

WordPressの場合、REST APIの/wp-json/wp/v2/users/meを叩くだけで、ログイン名と権限が返ってきます。

認証OK
  サイト  : https://example.com
  ログイン: （ユーザー名） (id=1)
  権限    : administrator
  投稿作成: 可
  画像投稿: 可

ちなみに最初の実行では、権限の欄が「不明」と表示されました。調べてみると、WordPressのREST APIは既定のcontext=viewでは権限情報を返さない仕様で、?context=editを付けたところ正しく表示されるようになりました。

「動いたけれど表示が変」を放置せずに調べると、こうした仕様の理解が一段深まります。

---

まとめ｜生成AIにパスワードを安全に預ける前にやるべきこと

まずやるべきなのは、自分が使っている生成AIの会話ログがどこに保存されているかを確認することです。保存場所を知らないまま「消えたつもり」で運用しているのが、いちばん危ない状態です。

チャット欄に打ち込んだ文字列は、画面から消えても会話ログというファイルに残り、同時にサーバーへも送信されているからです。

一度、ご自分の環境で保存先のフォルダを開いてみてください。想像より多くの記録が残っていることに驚くはずです。

もう一つ大切なのは、パスワードを保管する場所と、それを使う仕組みを分けて設計することです。値をキーチェーンに預け、読み出しはスクリプトの内部だけに限れば、生成AIは最後まで中身を見ないまま作業を完了できます。

安全と便利は、どちらかを捨てるものではなく、経路を設計することで両立できるものだからです。

判断の基準はひとつ、「その値は、会話に登場したか」です。

自動化に取りかかる前に、まずAIに許す操作の上限を、コマンド名まで書き出しておく。

そうしておけば、AIが善意で気を利かせても、守りたい値が会話に漏れ出す心配もありません。

macOSキーチェーンは、あなたの生成AI活用を安心して前に進めるための、確実な土台になるのです。

生成AIに校務の情報をどこまで入力してよいかを整理した記事も、ブログ内で公開しています。あわせてチェックしてみてください。

検証の記録はX（旧Twitter）やnoteでも発信していますので、ぜひフォロー・ブックマークしてお待ちください。

---

よくある質問

Windowsを使っています。同じことはできますか？

できます。Windowsには資格情報マネージャー、Linuxにはsecret-toolなど同等の仕組みがあります。「値を会話に出さず、プログラムだけが読み出す」という原則は共通なので、保管庫を置き換えて考えてください。

すでにチャットにパスワードを打ち込んでしまいました。どうすればいいですか？

まず、そのパスワードをサービス側で失効させて再発行してください。会話ログの削除より、値そのものを無効にするほうが確実です。そのうえで、新しい値をキーチェーンに登録し直します。

キーチェーンに入れれば、絶対に漏れませんか？

絶対ではありません。-T /usr/bin/securityを付けると、そのMacのターミナルを使える人は読み出せます。端末自体のログインパスワードとファイルヴォルトによる暗号化を、あわせて有効にしておいてください。

AIに「パスワードを確認して」と頼むのは危険ですか？

存在確認だけなら問題ありません。危険なのは値を表示させる操作です。結果を捨てて成否だけを判定するコマンドを使えば、AIに実行させても値は画面にもログにも残りません。

アプリケーションパスワードと通常のパスワードは何が違いますか？

アプリケーションパスワードは、外部プログラムからの接続専用に発行する使い捨ての鍵です。漏れてもその1本を失効させれば済み、本体のログインパスワードは無事に保てます。