設定ファイルをAIに貼ろうとして、その手前でいったん手を止めて中身を見直している開発者
AIコーディング約17分

AIに設定ファイルを生成させる｜秘密情報の混入を防ぐ手順

「あの環境の docker-compose.yml、ちょっと書いておいて」。頼まれたのが夕方で、書式をうろ覚えのまま検索し直すより、AIに聞いたほうが早い——そう判断した日は、たぶん今日もどこかにあります。

手元の設定ファイルをまるごと貼って「これを本番用に直して」と伝えると、インデントの合ったきれいな YAML が返ってきます。コメントまで付いている。ありがたく受け取って、コミットする。

そのあとで、ふと引っかかります。いま貼ったファイルの中に、本物のパスワードやAPIキーは入っていなかっただろうか。

これは、注意力が足りないから起きることではありません。設定ファイルは、そもそも「構造」と「秘密の値」が同じ場所に同居している作りです。コードなら秘密はコードの外にありますが、設定ファイルは値そのものを書く場所。だから、丸ごと渡すと丸ごと渡ります。この記事では、そこをどう切り分けるかを整理します。

結論：AIに設定ファイル（YAML・env・Terraform など）を書かせるときの要点は3つです。①渡す前に、値を伏せる——キー名と構造は渡して大丈夫です。危ないのは値のほうだけです。②「実際の値は書かないで。キー名と、そこに何を入れるかの説明だけ」と頼む。AIは形（雛形）を書くのは得意ですが、あなたの本物の値は知らないので、放っておくとそれらしいダミー値で埋めます。③コミット前は、機械に見張らせる。目視は必ずどこかで抜けます。.gitignore と秘密検出ツールを一度入れれば、あとは毎回勝手に見てくれます。

そして、もし本物の鍵が一度でも外に出てしまったときは、消すより先に作り直す（失効させて再発行する）。ここだけは順番を間違えないでください。

3つ全部を今日やる必要はありません。まずは①の「貼る前に値を伏せる」だけで十分です。

何が起きているのか——AIは「動く設定」を書く。何が秘密かは知らない

値に付箋を貼って伏せる場面、キー名だけの雛形を書かせる場面、本物の値は金庫に入れてサーバへ渡す場面を並べた図
構造（キー名）と秘密の値を切り離す。形だけAIに書かせて、本物は金庫から読み込ませます

まず、なぜ設定ファイルだけ勝手が違うのかを共有させてください。理由は3つあります。

1つ目は、構造と値が同居していること。図の左です。DATABASE_URL というキー名は、渡しても何も起きません。困るのは、その右側に書いてある本物の接続文字列のほうです。ところが設定ファイルは、その2つが1行の中に並んでいます。「参考に見せる」と「秘密を渡す」の境目が、ファイルの中に引かれていない——これが、うっかりの起きやすさの正体です。

2つ目は、AIは値を知らないので、埋めてしまうこと。図の中央のように空欄のまま返してくれれば安全ですが、何も言わないと password: changeme や、それらしい形をしたサンプルキーで埋まった状態で返ってきます。これは親切のつもりの埋め合わせであって、嘘をついているわけではありません。ただ、埋まっているものはコピーされて、そのまま本番まで行くことがあります。弱い既定値が残ったまま動いてしまう、というのがここでのしんどさです。

3つ目は、設定ファイルの差分がレビューで飛ばされやすいこと。.yml、.env、.tf、values.yaml。ロジックの変更に比べると、設定は「動いているならいいか」で通されやすい。しかも1行が長いので、レビュー画面では折り返しの先が見えません。複数ファイルにまたがる変更を見失わない工夫はAIに複数ファイルの変更を任せる｜差分を見失わない追い方にまとめてあります。

この3つが重なると、「誰も手を抜いていないのに、鍵だけがリポジトリに残る」という状態が生まれます。逆に言えば、値と構造を切り離すという一手だけで、大半は起きなくなるということでもあります。

具体例——設定ファイルまわりで起きやすいこと

現場で見かけやすいのは、次のような形です。どれも「AIが悪い」わけではなく、渡し方と受け取り方に一手足りなかったというだけの話です。

並べてみると、外し方のほとんどが「値」「権限の広さ」「版の違い」の3か所に集まっています。裏を返せば、見る場所は決まっている、ということです。

影響——鍵は「消しても、消えたことにならない」

設定ファイルの事故が少し特殊なのは、気づいてから消しても終わらないところです。

ここで強調しておきたいのは、これは誰かの不注意の問題ではないということです。設定ファイルは、秘密と構造が同居する形式として最初から設計されています。だから、気をつけるのではなく仕組みで防ぐ——それが、この件でいちばん効く考え方です。

そしてもうひとつ。一度きちんと組んでおけば、この対策はチーム全員にずっと効きます。今日入れる .gitignore の1行と検出ツールは、半年後に入ってくる人のうっかりも一緒に受け止めてくれます。

明日からやること（3ステップ）

大きな仕組みは要りません。この順番で、今日から小さく始められます。

1. AIに渡す前に、値を伏せる

貼る前に、値だけを置き換えます。図の左です。置き換え先は、人が見て明らかに本物でないと分かる書き方にします。

# 貼る前（そのまま渡さない）
DATABASE_URL=postgres://app_user:8Kd93hsQ@db.example-internal.jp:5432/orders
STRIPE_SECRET=（実際のキー）

# 貼るとき（値だけ伏せる）
DATABASE_URL=<本番DBの接続文字列。ユーザー名とパスワードを含む>
STRIPE_SECRET=<決済のシークレットキー>

伏せる対象は、迷ったらこの範囲で見てください。

APIキー・アクセストークン／パスワード／接続文字列（DSN・URLに認証情報が埋まっているもの）／秘密鍵・証明書の中身／Webhook のURL／社内のホスト名・IPアドレス・サブドメイン／実在する顧客名・メールアドレス

とくに見落としやすいのが、接続文字列と Webhook URL です。どちらも「ただのURL」に見えますが、中に認証情報が入っていたり、URLを知っているだけで投稿できてしまったりします。

もっと簡単な方法もあります。そもそもファイルを貼らない——「PostgreSQL と Redis に接続する Docker Compose の設定を書きたい」と、必要なものを言葉で伝えるだけで、雛形は十分に返ってきます。前提の渡し方そのものはAIにコードを書かせる前に渡す前提と制約｜伝え方の型と同じ考え方です。

なお、どのAIツールに業務のファイルを貼ってよいかは、個人の判断で決めきれない部分でもあります。まだ会社として決まっていないなら、AI利用の社内ガイドラインの作り方｜使ってよい範囲の決め方を叩き台にしてみてください。

2. 「実際の値は書かないで、形だけ」と頼む

渡し方を整えたら、次は返し方を指定します。ここを言葉にしておくだけで、返ってくるものが変わります。

そのまま使える頼み方の例：

次の用途の設定ファイルの雛形を書いてください。条件は次のとおりです。

1. 実際の値は一切書かないでください。 すべて <説明> の形のプレースホルダにしてください（例：<本番DBのホスト名>）。それらしいダミー値やサンプルキーも入れないでください。
2. 各キーについて、何を入れるか／秘密情報にあたるか／省略できるかを1行コメントで添えてください。
3. 秘密情報にあたるキーは、ファイルに直接書かず、環境変数（またはシークレット管理の仕組み）から読む形にしてください。その読み込み方も示してください。
4. 使っている版は（例：Docker Compose ◯／Kubernetes ◯／Terraform ◯）です。その版に実在するキーだけを使い、確信が持てないキーには「要確認」と書いてください。
5. 権限や公開範囲に関わる設定は、動くことより狭いほうを既定にしてください。広げる必要がある場合は、その理由を書いてください。

用途：（何を動かす設定か）
必要な接続先：（DB・キャッシュ・外部APIなど）

条件を1つずつ足す理由は、こうです。

1を言わないと、必ず埋まります。しかもダミーは「それらしく」書かれるので、レビューで本物と見分けがつきません。空欄で返させるほうが、あとが楽です。

3が入ると、設計そのものが変わります。「動く設定」ではなく「秘密を外に置く設定」を最初から書かせる、という指定です。図の右——本物は金庫から読む形にしておけば、ファイルが多少出回っても事故になりません。

5が効くのは、AIが動くほうに寄るからです。権限で詰まる設定より、通る設定のほうが役に立つように見える。だから狭いほうを既定と明示する必要があります。広げるのは、詰まってからで間に合います。

返ってきた雛形は、.env.example や config.example.yml のような例のファイルとしてコミットし、本物の値を入れたファイルは次のステップで除外します。これで、新しく参加した人が「何を設定すればいいか」を見られる状態と、秘密が入らない状態が両立します。

3. コミットする前に、機械に見張らせる

最後は、目視をあてにしないことです。忙しい日ほど抜けるので、そこは機械に任せます。

①その鍵を失効させ、新しい鍵を発行する（最優先）
②新しい鍵を、動いている環境へ配り直す
③リポジトリの履歴から削除する（git filter-repo などの専用ツールを使う。全員の手元に影響するので、作業前にチームへ声をかける）
④いつからいつまで、どこに出ていたかを記録する

順番が大事です。③から始めたくなりますが、消しても、すでに複製された分は消えません。まず鍵を無効にすれば、その時点で価値はなくなります。

3つとも今日やる必要はありません。ステップ1の「貼る前に値を伏せる」だけでも、いちばん起きやすい入口はふさげます。

設定ファイルのチェックリスト

全部に○が要るわけではありません。気になった行だけで十分です。

① AIに渡す前に

② 返ってきた設定を見るとき

③ コミットする前に

この記事のまとめ

AIは、設定ファイルの雛形を驚くほど速く整えてくれます。得意なのは形を書くことと、キーの意味を説明すること。知らないのは、あなたの環境の本物の値と、そのうちどれが外に出てはいけないものかです。だから、そこだけこちらで決めて渡します。

やることは3つだけです。①渡す前に値を伏せる／②「実際の値は書かないで、形だけ」と頼む／③コミット前は機械に見張らせる。この3つがあると、設定ファイルは「うっかりが怖いファイル」から、「安心してAIに任せられるファイル」に近づきます。

設定ファイルの確認を終えて、安心してコミットできた開発者

貼る直前に「この中に本物の値、入っていないかな」と一度手が止まったなら、それはもう、いちばん危ない入口をふさげています。全部を今日そろえなくて大丈夫です。値をひとつ伏せることから始めれば、あとの仕組みはあとから足せます。

よければ、こちらも

関連用語