AIエージェント(指示を受けて自律的に作業を進めるAI)に、開発や運用の作業を任せる場面が急速に増えています。コードを書かせる、サーバーの設定を確認させる、外部サービスと連携する処理を組ませる。人間の何倍もの速さで作業が進むため、一度使い始めた現場は手放せなくなります。

そこで必ず問題になるのが、パスワードやAPIキー(外部サービスを利用するための認証用の鍵)といった「秘密そのもの」の扱いです。AIに作業を任せるには、AIが外部サービスに接続できなければならない。しかし接続に必要な鍵をAIにそのまま渡してしまえば、会社の資産への入口を第三者のシステムに預けるのと同じことになります。この距離感をどう設計するかが、今回のテーマです。

会話に貼ったものは、手元を離れる

まず押さえるべき基本は、AIへの入力は、処理のために外部のサーバーへ送られるという事実です。チャット型のAIに質問を打ち込むとき、その文章は自社のパソコンの中で完結して処理されているわけではありません。AIを提供する事業者のサーバーに送られ、そこで処理されて答えが返ってきます。

2023年には、韓国サムスン電子の従業員が社内のソースコードをChatGPTに貼り付けていた問題が報じられ、同社が社内利用を制限する事態になりました。ソースコードですらこれだけの騒ぎになるのですから、パスワードやAPIキーを会話に貼り付けることの意味は言うまでもありません。会話に貼った瞬間、その秘密は自社の管理外に出ます。相手が悪用するかどうかとは別の問題として、「どこに保存され、誰がアクセスできるのか、自社では確認も削除もできない場所」に秘密のコピーが生まれるのです。

もうひとつ根深いのが、認証情報をプログラムのコードに直接書き込む習慣です。開発の現場では昔から「動けばよい」の勢いで、コードの中に鍵を直書きしてしまう例が絶えませんでした。AI時代にはこれが二重に危険になります。AIにコードを読ませて修正させる働き方が当たり前になると、コードに書かれた鍵はそのままAIへの入力として外部に送られるからです。人間が意図して貼り付けなくても、コードの中に埋まっている秘密は、AIに作業を頼んだ時点で一緒に運ばれていきます。

「使わせるが、見せない」という設計思想

では、AIには一切外部サービスを触らせないのが正解かというと、それでは生産性の恩恵を捨てることになります。目指すべきは禁止ではなく、「鍵を使った作業はさせるが、鍵そのものは見せない」という設計です。

これを実現する仕組みが、シークレット管理(秘密情報を暗号化された保管庫で一元管理する仕組み)です。考え方は単純で、パスワードやAPIキーをコードや設定ファイルに書かず、専用の保管庫に集約します。プログラムが外部サービスに接続する必要が生じたとき、実行のその瞬間にだけ、保管庫から鍵がプログラムへ渡されます。鍵はファイルとして残らず、会話にも登場しません。

この構成にすると、AIとの関係が変わります。AIは「この処理を実行して、結果を教えて」という形で作業を進め、扱うのは鍵を使った作業の結果だけになります。接続そのものは保管庫と連携したプログラムが行うため、AIの目の前に鍵の文字列が現れる場面がなくなるのです。人間にたとえるなら、金庫の中身を新しく来た作業者に見せるのではなく、「金庫係が必要な書類だけをその場で取り出して手渡す」運用に切り替えるようなものです。作業は滞りなく進み、金庫の番号は誰にも知られません。

重要なのは、これが特別な大企業向けの話ではないことです。シークレット管理の道具は商用・無償を含めて広く提供されており、開発チームが数人の会社でも導入できます。必要なのは高額な投資ではなく、「秘密は保管庫に集約し、実行時にだけ渡す」という方針を経営として明確にすることです。

人間側の運用も、一段上げる

仕組みを入れれば終わり、ではありません。よくある落とし穴が、保管庫を開けるための鍵(アクセストークン)を、平文(暗号化されていないそのままの文字列)でパソコンに置いてしまうことです。金庫を買ったのに、金庫の鍵を玄関マットの下に隠しているようなもので、これでは保管庫の意味がありません。

秘密情報の管理は鎖のようなもので、強度は一番弱い輪で決まります。保管庫がどれほど堅牢でも、保管庫にアクセスするための認証が甘ければ、攻撃者はそこを狙います。経営として確認すべきは「立派な保管庫があるか」ではなく、「秘密の連鎖をたどっていったとき、一番弱い場所はどこか」です。保管庫のアクセストークンは誰が持っているのか、退職者の分は無効化されているのか、万一漏れた場合に鍵を素早く交換できる手順はあるのか。この問いに開発部門が具体的に答えられるなら、運用は健全といえます。あわせて、鍵の定期的な交換(ローテーション)と、どの鍵がいつ誰に使われたかの記録を残すことまで習慣化できれば、万一の漏えい時にも被害の範囲を素早く特定できます。

経営視点での意味 ― 生産性とセキュリティは二者択一ではない

この論点を経営の言葉に置き換えると、こうなります。AIエージェントの活用は開発現場の生産性を大きく引き上げる。一方で、認証情報の漏えいは外部サービスの乗っ取りや情報流出に直結する。だからといって「AIの利用を止める」か「リスクに目をつぶる」かの二択で考える必要はありません。秘密の置き場所と渡し方を仕組みで設計すれば、両方を取れるのです。

むしろ危険なのは、方針がないまま現場任せにすることです。仕組みがなければ、善意の従業員でも締め切りに追われれば鍵をコードに直書きし、AIに貼り付けます。ルールで縛るのではなく、安全な方法が一番楽な方法になるように環境を整えることが、経営の仕事です。実際にどのような道具を選び、どう移行したのかという実践の詳細は、番外編の.envファイルは悪くない ― Bitwarden Secrets Manager導入記で具体的に紹介しています。

経営としての初動 ― 開発部門への二つの質問

最後に、明日そのまま使える初動を示します。開発部門の責任者に、次の二つを聞いてください。

  • AIエージェントに、認証情報が見える状態で作業をさせていないか。コードや設定ファイルに鍵が直書きされたまま、AIに読ませていないか。
  • シークレット管理の仕組みはあるか。あるなら、保管庫自体へのアクセスはどう守られているか。ないなら、導入に何が必要か。

この質問に淀みなく答えが返ってくれば、現場の意識はすでに高い状態です。答えに詰まるようであれば、それは現場の怠慢ではなく、方針を示してこなかった経営側の宿題だと捉えて、仕組みづくりを指示するところから始めてください。大がかりな体制は不要です。「秘密は保管庫へ、AIには結果だけ」という原則を言葉にして伝えることが、最初の一歩になります。

なお、鍵を見せない設計にしても、AIへの攻撃がなくなるわけではありません。次回は、AIに与える指示そのものをすり替える新しい攻撃、プロンプトインジェクションを取り上げます。

DSB Consultingでは、AIエージェント活用を前提とした認証情報の管理設計や、開発現場のセキュリティ運用の整備を支援しています。自社の秘密情報とAIの距離感に不安がある方は、お気軽に無料相談をご利用ください。