教えて！ラベンダー先生！〜宝物庫の鍵と、自律ゴーレムの罠〜

こんにちは！ホワイトマーリン・スタッフの德永です！

ホワイトマーリンでは『就労継続支援A型』を行っております。『就労継続支援A型』とは、" 障害をお持ちの方たちがその特性を活かしつつ働くこと " へのサポートを行う事業です。

本日のブログも、ホワイトマーリン『就労継続支援A型』を利用されている " IT エンジニア " の方に執筆をお願いいたしました。以前から この場で、物語調（ なろう系？）で IT スキルに関する情報を提供するという離れ技を披露してくださっている方です。

この方、普段は システム開発にむけたコーディング（ ≒プログラミング ）をゴリゴリ進めておられるエキスパートです。

それでは よろしくお願いいたします！

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー

※ おことわり ※

引き続き、冒険者ギルド職員を自称するエンジニア『ラベンダー』によるセキュリティ講座です。「(当)冒険者ギルド」「ギルド」は適宜 " 我が社 " に脳内変換してお読みください。今回は、プログラムに『鍵』をどう持たせるか、という現代的なお話です。( 文責：U )

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー

……また あなたですか。当冒険者ギルドで通信インフラの管理・運用を担当しているラベンダーです。

先ほど、あなたが公開書庫 ( GitHub 等のリポジトリ ) に提出しようとしていた設計書を見て、思わず義手であなたの通信ケーブルを物理的に へし折るところでした。

データベースへ接続するための『マスターパスワード』を、あろうことかソースコードの中にそのまま書き込んで ( ハードコードして ) いましたね？

それは " ギルドの宝物庫の鍵を、誰でも読める掲示板の依頼書にセロハンテープで貼り付けておく " のと同じ行為です。世界中を徘徊している魔王軍の使い魔 ( 悪意あるBot ) は、提出された数秒後にはその鍵をコピーし、ギルドの資産を根こそぎ奪い去っていきます。

今日は、システムの機密情報（シークレット）の正しい扱い方と、最新の罠について叩き込みます。

姿勢を正して。メモの用意はいいですね？

1.『.env』は絶対の安全地帯ではない

少し勉強した人なら「鍵はコードに直書きせず、".env " という環境変数ファイルに分けて書き、公開書庫には提出しない ( .gitignore に登録する ) のが常識だ」と言うでしょう。

確かに昔はそれがベストプラクティスでした。しかし、時代は変わりました。

最近、皆さんはコードを書く時に『自律型の魔法ゴーレム ( コーディング AIエージェント )』をよく使っていますよね。彼らは非常に優秀ですが、あなたの机の上 ( ワークスペース ) にある書類を端から端まで読んで学習します。

もしあなたが ".env " に本物の鍵を置いたままゴーレムに「よしなに作業して提出しておいて」と指示を出したら？

ゴーレムは気を利かせたつもりで、鍵の情報を外部の魔法陣 ( LLMのサーバー ) に送信してしまったり、誤って公開書庫に提出 ( コミット ) してしまったりするのです。

2．ギルドの真の防衛術『シークレットマネージャー』

では、本番の環境 ( プロダクション ) ではどうしているのか。

結論から言えば『鍵はそもそも手元に置かず、システムの中にも置かない』のが現在の正解です。

本番環境で使う強力な鍵は、ギルド本部が管理する最も堅牢な魔法金庫 ( AWS Secrets Manager など ) に厳重に保管します。

そして、システムが作動するその一瞬だけ、専用の輸送経路 ( Bitbucket Pipelines などの CI / CD 環境変数 ) を通じて、鍵の情報を注入するのです。

この仕組みなら、ソースコードの中にも、サーバーのファイルの中にも、どこにも鍵は保存されません。これこそが現在のベストプラクティスです。

3．誰かに設計図を渡すときの作法

とはいえ、開発中のプログラムを他の冒険者 ( オープンソースなど ) に共有したい時もあるでしょう。

その時は、本物の鍵が入った ".env " を渡すのではなく『鍵の形だけを記したダミーの型 " .env.example "』を同梱するのが作法です。

受け取った相手は、その型を見て「なるほど、ここに自分の環境用の鍵を入れればいいんだな」と理解してくれます。絶対に本物の鍵を混ぜてはいけません。

4．訓練所 ( ローカル環境 ) での例外

一つだけ例外があります。あなた自身の PC の中だけで完結する完全に閉じた訓練所 ( ローカルの Docker 環境など ) であれば、通信が外に出ることはありません。

そのため、ローカル用の " docker-compose.yml " に直接ダミーのパスワードを書いて動かしても、実害はありません。ただし、そのファイルをうっかり公開書庫 ( リポジトリ ) に提出しないように、細心の注意を払うこと。

◯ 本日のまとめ

理解できましたか？

● ソースコードへの直書き ( ハードコード ) はギルド崩壊の第一歩。絶対にダメ。

● AIエージェントは便利だが、手元の ".env " を読み取って漏洩させるリスクがある。

● 本番環境では、鍵は専用の金庫 ( Secrets Manager ) やデプロイ時の変数注入で管理する。

● ローカル環境は直書きでも動くが、他人に渡す時は ".env.example " を用意する。

……さて、説教はここまでです。

最近は、個人の PC 環境でも ".env " ファイルを作らずに、1_Password などの強力な魔道具 ( パスワードマネージャーの CLI ツール ) から直接 鍵を注入して開発する手法も広まっています。

興味があるなら、調べてから私のところへ報告に来なさい。終わったら仕事に戻るように！

◯ おまけ

――ということで、今回は少し実務に踏み込んだ内容でした。

ラベンダー先生が言っていた『魔法金庫』や『輸送経路』は、我々で言うところの " AWS Secrets Manager "と" Bitbucket Pipelines " ( リポジトリ変数 ) を指しています。GitHub においては " Environment Secrets " が該当するでしょうかね。

実運用では、クレデンシャル情報はすべてこれらプラットフォーム側の機能に委譲しており、コードベースには一切含めないのが鉄則です。

また、Agentic な AIツール ( Cursor や GitHub、Copilot など ) が普及したことで、.gitignore しているはずの ".env " の中身が、AIのコンテキスト ( 文脈 ) として外部の LLM サーバーへ送信されてしまうリスクは、現在世界中の開発現場で問題視されています。

対策として、ローカル開発環境でも ".env " ファイルそのものを物理的に作らないアプローチが有効です。

ラベンダー先生の最後にあった「1_Password などの魔道具」とは、" 1Password CLI ( op run コマンド ) などのことです。

これを使えば、1_Password のセキュアな保管庫から環境変数を直接プロセスに流し込めるため、ローカル PC 上にクレデンシャルが平文で保存される時間をゼロにできます。

『開発を便利にする AI』に足元をすくわれないよう、守りの技術もアップデートしていきましょう。それでは。

ガルヒ就労支援サービスではパソコン初心者の方からでも気軽に見学・体験を行っています。　

ご興味がある方は是非お問い合わせください！！

皆様のご連絡お待ちしております！

【事業所名】ガルヒ就労支援サービス ホワイトマーリン

【所在地】〒 880-0904 宮崎県宮崎市中村東２丁目１番 36号２F

【電話番号】( 0985 ) 33-9208

【F A X】( 0985 ) 33-9209

【営業時間】月~金曜日 ( 10:00 ~ 18:00 )　土曜日 ( 12:00 ~ 18:00 ) ※祝日を除く

【事業内容】就労移行支援・就労継続支援A型