Secret Manager
読み: シークレット・マネージャー
シークレット管理とは鍵の安全運用
Secret ManagerはAI開発やシステム連携において、APIキーやデータベースのパスワードなどの機密情報をソースコードから分離し、安全な環境で一元管理するインフラ技術。
かんたんに言うと
厳格な金庫番である。社員全員に金庫の鍵を渡すのではなく、必要な時に権限を持ったシステムだけが金庫番から中身を一時的に受け取る仕組みを想像してほしい。
ソースコードにAPIキーを直書きする危険とSecret Managerの防御
OpenAI APIを使って法務部門の契約書レビューAIを構築したとする。開発を急ぐあまり、APIキーをソースコードに直書き（ハードコード）していないか。
これは本当に恐ろしい。
パブリックリポジトリに誤ってプッシュした瞬間、世界中のボットがそのキーを検知して不正利用を始める。数時間で数百万円の請求が来ることも珍しくない。Secret Managerはこうした悲劇を防ぐための防波堤である。機密情報をコードから切り離し、呼び出し権限を持つシステムだけがアクセスできるようにする。
権限と暗号化が織りなす防御網
仕組み自体はシンプルである。AWS IAMなどの認証基盤と連携し、誰がどの情報にアクセスできるかを厳密に制御する。
保存されるデータは専用の暗号化キーで守られる。
経理部門の給与データにアクセスするためのデータベースパスワードを考えてみよう。パスワードを定期的に変更するシークレットローテーション機能を使えば、人間が手動で更新する手間とミスを省ける。ただ、このローテーション設定が意外と曲者である。データベース側の仕様変更でローテーションが失敗し、深夜にシステムが停止する。現場ではよくある落とし穴である。導入すれば全て安心というわけではなく、運用設計の難易度は少し判断が分かれる。
インフラ環境に合わせたツールの選択
自社の環境に合わせて適切なツールを選ぶ必要がある。AWS環境ならAWS Secrets Managerが第一候補になるだろう。Google Cloudを使っているならGoogle Cloud Secret Managerである。
マルチクラウド環境やオンプレミスとの混在環境ならどうするか。
HashiCorp Vaultの出番である。柔軟性が高く強力だが、構築と運用の学習コストは跳ね上がる。Azure Key Vaultも含め、各社が提供するマネージドサービスはSLAが設定されているものの、クラウドベンダーの障害時には道連れになる。単一障害点になるリスクをどう評価するかは、インフラ設計者の腕の見せ所である。
セキュリティと可用性の天秤
機密情報を一元管理することで、監査対応は劇的に楽になる。誰がいつAPIキーにアクセスしたか、ログが全て残るからである。
だが、良いことばかりではない。
Secret Manager自体がダウンしたらどうなるか。AIシステムはAPIキーを取得できず、すべての処理が停止する。可用性を高めるためにキャッシュを挟むか、それともセキュリティを最優先して毎回取得しにいくか。このあたりの設計は本当に悩ましい。ゼロトラストの概念をどこまで厳格に適用するか、ガバナンスの要件とシステムのレスポンス速度のバランスをどう取るか。現場のエンジニアは常にこのジレンマと戦っている。
当社の見解
当社は機密情報のマスキング処理を全てローカルAIで行っている。これにより機密情報を外部に送信せずにAI処理できるようになった。だが、AIが嘘をつくハルシネーションの問題は依然としてある。確認していないのに「確認しました」と言う。当社はこの前提で運用を設計している。事実と推測の強制分離、ファクトチェック機能、3つのAIと人間の同士の三重検証を行っている。どこまでいっても、AIは完璧ではない。理論上100%安全設計をしていても、AIも人間も想定しないことは起こるものだ。その万が一に備えておくことが、AIを使う上では前提になっている。だろうではなく、かもしれない運用がAIを使う上での安全基盤となっている。
同じ失敗を二度としないAIエージェント
今のAIは、聞けば何でも答えてくれます。
でも、セッションが切れた瞬間に前回の失敗を忘れます。
当社が開発しているAIは、過去の経緯を念頭に置いて、
聞かれる前に「それは前回うまくいきませんでした」と声をかけます。
人間にも同じ失敗をさせず、AI自身も繰り返しません。
古参の社員が横にいるように、黙っていても気づいてくれる。
それが、当社が考える本当のAI社員です。