Secret Managerとは
Secret Managerとは、AI開発やシステム連携において
読み: シークレット・マネージャー
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の安全運用のために多層防御を設計・実装している（2026年4月現在）。この仕組みにより、AIが誤って機密情報を外部に送信するリスクを構造的に排除した。加えて、万が一インシデントが発生しても即座に復旧できるバックアップ体制を構築している。実際にAIが暴走して本番環境を停止させた経験があり、その際も緊急復旧スクリプトとデプロイ前の自動ロールバック機構で数分以内に復旧した。2026年4月にはAIによるファイルの無断変更を追跡するため、5つのリポジトリにgit自動追跡を導入し、全変更をコミット単位で記録・復元可能にした。安全性は「失敗を防ぐ」だけでなく「失敗しても戻せる」「誰が変えたか追跡できる」設計が本質だ。
同じ失敗を二度としないAIエージェント
今のAIは、聞けば何でも答えてくれます。
でも、セッションが切れた瞬間に前回の失敗を忘れます。
当社が開発しているAIは、過去の経緯を念頭に置いて、
聞かれる前に「それは前回うまくいきませんでした」と声をかけます。
人間にも同じ失敗をさせず、AI自身も繰り返しません。
古参の社員が横にいるように、黙っていても気づいてくれる。
それが、当社が考える本当のAI社員です。