HashiCorp Vaultとは｜シークレット管理の仕組み・基本操作・案件動向

HashiCorp Vaultとは

HashiCorp Vaultは、シークレット（機密情報）の保管・発行・失効・暗号化までを一元的に扱うためのオープンソースソフトウェアです。HashiCorp社が開発し、Terraform・Consul・Nomadと並ぶ主要製品として位置づけられています。

従来のシークレット管理で起きていた課題

シークレット管理の話を「何が問題だったか」から始めると理解が早いです。従来は、認証情報が次のように散在するケースが目立ちました。

• アプリケーションの設定ファイルに平文で書かれている

• CIサーバーの環境変数に手動で登録される

• 個人PCの.envファイルに残ってしまう

• SlackやNotionに送信してしまう

こうした状態では、権限管理・ローテーション・監査ログの取得が難しくなります。Vaultはこの問題を「サーバーに集めて、認証してから取り出させる」というシンプルな原則で解こうとするツールです。

Vaultが担う3つの役割

Vaultの機能は多いですが、大きく分けると3つに整理できます。

「保管するだけ」の理解にとどまると、Vault導入のうまみを半分見落とすことになります。動的発行と暗号化APIまで含めて考えると、アプリ側の実装をシンプルに保てる場面が増えます。

OSS版・Enterprise版・HCP Vaultの違い

VaultにはOSS版・Enterprise版に加え、HashiCorp社が提供するマネージド版（HCP Vault）があります。用途と規模で選び分けます。

利用可能な接続方式・対応リージョンはプランや時期で変わるため、採用検討時は公式の最新情報を確認してください。

自前運用ではUnseal（後述）とHA構成の設計に人手が要ります。要員に余裕がない場合はHCP Vaultも選択肢に入ります。

ミニFAQ：Vaultの立ち位置に関する疑問

Q. AWS Secrets Manager・GCP Secret Managerとの棲み分けは？

クラウドが1社に閉じるならクラウド標準のマネージドサービスで十分なケースは多いです。マルチクラウド・オンプレ混在・PKIまで扱いたい場合にVaultの優位が出やすくなります。

Q. Consulとセットで語られるのはなぜ？

Consulは同社のサービスディスカバリ製品で、以前はVaultのストレージバックエンドとして利用されてきた経緯があります。近年はVault内蔵のIntegrated Storage（Raft）が中心となり、新規案件でConsulをVaultのストレージ用途で採用するケースは少なくなっています。

シークレット管理の仕組み（アーキテクチャ）

Vaultの内部は「サーバー本体＋ストレージバックエンド＋認証プラグイン＋シークレットエンジン」で構成されます。アプリケーションはHTTP APIで叩く形が基本で、CLI・SDKもそのAPIをラップしたものです。

サーバーとストレージバックエンド

Vaultサーバーはメモリ上でシークレットを扱い、ディスクへは暗号化した状態でストレージバックエンドに書き出します。バックエンドは複数選べます。

• Integrated Storage（Raft）：Vault本体に組み込まれた分散ストレージ。現在は新規構築で中心的に選ばれる方式

• Consul：以前から使われてきた選択肢

• その他：S3等のクラウドストレージが選べるケースもあるが、利用可能な構成や推奨はVaultのバージョンで変わるため公式ドキュメントで確認する

Integrated Storageは追加コンポーネントが不要で、HA構成もVault内で完結する点が採用理由になりやすいです。

Sealed / Unsealed とマスターキー

Vaultの特徴的な概念に「シール」があります。起動直後のVaultはSealed（封印）状態で、暗号鍵にアクセスできないためAPIリクエストを処理できません。Unseal Keyを規定枚数入力するとUnsealed状態になり、動作を開始します。

Unseal Keyはインストール時の初期化コマンド（vault operator init）で分割生成されます。初期化時のオプションで枚数と復元閾値を指定でき、5分割・3枚で復元する構成が一例としてよく紹介されます。この鍵の紛失＝データ復元不能なので、実運用ではKMS等によるAuto-Unseal設定を組み合わせるのが現実的です。

認証（Auth Methods）と認可（Policies）

Vaultにアクセスするには、まず認証を通してトークンを得る必要があります。認証手段は複数プラグインとして提供され、環境に応じて選びます。

認証を通ったユーザー・ワークロードにはポリシー（Policy）が紐付き、どのパスに対してどの操作（read/write/list/delete等）を許可するかが決まります。ポリシーはHCLで書く点がTerraformユーザーには馴染みやすいところです。

シークレットエンジン

シークレットエンジンは「実際に何を保管・発行するか」を担うプラグインです。パスにマウントして使う設計で、複数バージョンを並行運用できます。

• KV v2：一般的なKey-Value保存。バージョン履歴あり

• Database：DB接続情報を都度発行し、TTL経過で自動失効

• PKI：内部CAとして証明書発行

• Transit：Encryption as a Service（鍵を持たずに暗号化APIを呼ぶ）

• AWS/GCP/Azure：クラウドIAMの一時クレデンシャル発行

• SSH：SSH署名鍵の発行

「KVしか使っていない」現場も多いですが、動的シークレット（DatabaseやAWSエンジン）まで踏み込むとVault導入の投資対効果が跳ね上がるケースが目立ちます。

Vaultの主要機能・シークレットエンジンの実像

Vaultで最初に理解すべきは「静的シークレット」と「動的シークレット」の区別です。運用設計の分岐点になります。

KV（Key-Value）シークレットエンジン

もっとも基本的なエンジンで、任意のキー・バリューを保存します。KV v2はバージョン管理と論理削除に対応しており、誤書き換え時のロールバックが容易です。

想定用途はサードパーティAPIキー、社内システムの管理者パスワード、暗号化に使う共通鍵など、値そのものをVaultで守りたい静的な情報です。

Databaseシークレットエンジン（動的シークレット）

Databaseエンジンは接続先DB（PostgreSQL・MySQL・MongoDB等）とVault自身の管理者権限を紐付け、リクエスト時にユーザーを都度発行します。発行されたユーザーはTTL経過で自動的にDROPされます。

「アプリのDBパスワードを固定にしない」という発想の実装で、以下のような効果があります。

• 認証情報の漏洩リスクを局所化できる

• ローテーション自動化を人手で設計しなくてよい

• 監査ログに「誰がいつ発行したか」が残る

一方で、DB側の権限設計・接続プール仕様との噛み合わせが必要で、初回設計の難度は上がります。

PKI・Transit・クラウド系エンジン

PKIエンジンは内部CAとして機能し、内部通信用の証明書発行を自動化します。Kubernetes環境で相互TLSを組む際の候補です。

Transitは「鍵はVaultが管理し、暗号化・復号だけAPIで受け付ける」という設計で、アプリケーション側に鍵を持たせずに済みます。ログの暗号化・DBに保存する機密フィールドの暗号化などに使われるケースが多いです。

AWS/GCP/Azureエンジンは、クラウドの一時IAMクレデンシャルを発行できます。運用担当者に固定のIAMユーザーを配らずに済むため、権限設計をVault側に寄せられます。

基本操作の流れ（開発モードで動かす）

まずは開発モード（vault server -dev）で立ち上げ、認証・書き込み・読み取り・ポリシー適用までを一周させると全体像がつかめます。開発モードは本番利用不可（メモリ上でしか動作しない）ですが、学習には最短です。

開発モード起動と初期確認

インストール後、開発モードで起動すると、Root Token・アドレスが標準出力されます。

• サーバー起動：vault server -dev

• 別ターミナルで VAULT_ADDR と VAULT_TOKEN を設定

• 動作確認：vault status

出力にあるUnseal Keyは開発モード限定で、本番モードでは初期化コマンド（vault operator init）から取得します。

シークレットの保存・取得

KV v2エンジンは開発モードで初期マウント済みです。

• 書き込み：vault kv put secret/app/db password=changeme

• 読み取り：vault kv get secret/app/db

• 一覧表示：vault kv list secret/

「値が返るか」だけでなく、format=json オプションでメタデータ（バージョン・作成時刻）を確認する癖をつけると本番運用時にも慌てません。

ポリシー作成とトークン発行

権限を絞ったポリシーを作り、そこから子トークンを発行するのが基本の流れです。

1. HCLでポリシーファイルを書く（例：secret/app/ 配下へのreadのみ許可）

2. vault policy write コマンドで登録

3. vault token create コマンドでポリシーを紐付けたトークンを発行

このトークンをアプリ側に渡す運用は最小構成ですが、実務ではAppRoleやKubernetes認証で置き換えるのが定石です。Root Tokenを直接使う運用は避けます。

ミニFAQ：基本操作でつまずきがちなポイント

Q. 本番でRoot Tokenをそのまま使うのはNG？

本番運用ではRoot Tokenはインストール直後に破棄するか、厳重に保管して緊急時のみ使う運用が基本です。定常運用はAdmin相当のポリシーを持つ通常トークンで行います。

Q. KV v1とv2はどちらを使うべき？

新規はKV v2が基本です。バージョン管理・論理削除・メタデータの点で運用しやすく、公式もv2を推奨する記述が中心になっています。

Kubernetes・クラウドとの連携

Vaultが実務で本領を発揮するのはKubernetes連携とクラウド認証との組み合わせです。「Podの中に環境変数として渡す」から一歩進めて、動的にシークレットを注入できます。

Vault Agent Injector・CSI Driver

Kubernetes環境では、Vault Agent Sidecar InjectorとSecrets Store CSI Driverが代表的な連携方式です。

Vault Agent Injectorは既存アプリの改修を抑えやすく、導入初期の選択肢として検討されやすい方式です。

AWS・GCPのIAM統合とTerraform連携

VaultのAWS認証を使うと、EC2インスタンスやEKSのService Accountから、事前配布された鍵なしでVaultにログインできます。GCP・Azureも同様の仕組みです。

構築フェーズでは、TerraformのTerraform Provider for Vaultで初期設定をコード化するのが定番です。Auth Methodの有効化・ポリシー登録・シークレットエンジンのマウントまでTerraformで管理できます。

CI/CDパイプラインでの利用

GitHub ActionsやJenkinsといったCI/CDから利用する場合は、OIDC連携やAppRoleでの認証が現実的です。GitHub ActionsはOIDCトークンをそのままVaultに渡せるため、静的なシークレットをリポジトリに置かずに済みます。

CI経由での動的シークレット取得は、ローテーション設計と権限最小化の両方に効くため、DevOps文脈で実務上よく検討される構成です。

案件動向と単価（フリーランスエンジニア視点）

Vaultは「Vaultだけの案件」より、DevOps・SRE・クラウドインフラ案件の要件の一部として登場するケースが目立ちます。単価はVaultスキル単独で決まるものではなく、Kubernetes・Terraform・クラウド全体の実務力とセットで評価される傾向があります。

案件で求められるVaultスキルレベル

大まかに3層に分けて考えると、求人票の読み方が見えてきます。

案件募集ではLevel 2以上を求める内容が多く、Kubernetes・Terraform経験が前提として書かれるパターンが目立ちます。

単価の目安と根拠

2026年6〜7月時点で、主要フリーランスエージェントの公開案件（首都圏中心・週4〜5日・業務委託・DevOps/SRE/クラウドインフラ職）でVault利用が要件・歓迎スキルに含まれる募集をピックアップした範囲では、次の傾向が見られました。件数は数十件レベルで、非公開案件の実勢と一致するとは限りません。

• Vault利用経験＋クラウドインフラ実務3年以上：月額70〜100万円のレンジで募集されるケースが目立つ（AWS/GCPの運用経験があり、KVからのシークレット取得やAgent Injector経由の設定を担える人材が中心）

• Vault運用経験＋Kubernetes運用経験がセット：月額80〜120万円レンジも見られる（ポリシー設計や動的シークレット導入まで踏み込め、SREとして障害対応もこなせる人材が想定される）

• Enterprise Vault・マルチリージョン設計まで対応：月額100〜140万円クラスの募集も稀に登場する（金融・大規模基盤で、HA設計・監査要件対応・マルチクラスタ運用まで担える人材が中心）

数字はあくまで公開案件から見た傾向として捉えてください。参画時期・スキル組み合わせ・稼働日数で幅が出やすい領域です。

案件を獲得しやすい業界と周辺スキル

Vault導入に踏み切る組織は、機密情報の管理要件が強い業種に集中しやすいです。

• 金融・保険・証券系のプラットフォーム開発

• 認証基盤・決済基盤を持つSaaSプロダクト

• 官公庁向け・エンタープライズ向けの受託案件

• コンプライアンス要件が厳しいスタートアップ

周辺スキルとしては、Kubernetes・Docker・SRE・DevOpsエンジニアとしての実務経験がセットで求められることが多く、AWS認定資格などクラウド認定の有無も参加判断に効いてきます。

導入判断と失敗パターン

Vault導入は「入れる／入れない」の二択ではなく、規模・要件・運用体制で判断するテーマです。現場で発生しがちな失敗を先に知っておくと、判断精度が上がります。

ケース別の導入判断

シーンごとに、導入の判断軸を整理します。

「まだ数十シークレット程度」の段階なら、クラウド標準のマネージドサービスでも実務上支障が出にくいケースが多いです。導入コストが運用効果を上回るかは規模と体制次第です。

よくある失敗パターン

• Unseal Keyの管理を軽視する：紙・PDFで配布したままメンテナンスされない状態は、実質的な単一障害点になります。Auto-Unsealと鍵の保管ルールをセットで設計するのが安全です

• ポリシーが常時Root相当になっている：導入初期に「とりあえずroot policy」で運用し始め、そのまま塩漬けになるパターンが定番の落とし穴です

• 動的シークレットの導入設計が抜ける：Vaultを入れたのにKV止まりで運用され、期待した投資対効果が得られないケースがあります

• 監査ログの保存先が壊れているのに検知されない：監査デバイスの設定によっては、監査ログの書き込み失敗がリクエスト処理に影響することがあります。保存先の監視を最初から入れておく必要があります

• バージョンアップ計画が組まれていない：VaultはOSSでも活発に更新され、破壊的変更が入るリリースもあります。半期に一度は追従計画を立てる運用が安全です

実務Tips：導入時にまず整えたい観点

• 誰がRoot Tokenを保管するかの合意

• ポリシー命名規則（サービス名＋操作範囲）

• シークレットのパス命名規則（環境×サービス×用途）

• Vault側で監査ログをどこに出すか（Syslog・ファイル・Socket）

• 障害訓練（Unseal訓練を含む）を年何回やるかの合意

学習ステップと参考リソース

「Vaultを使えるようになりたい」場合、いきなりKubernetes連携を目指すより、開発モードでの基本操作→ポリシー→動的シークレットの順で積み上げる方が定着しやすいです。

学習ステップのモデルケースを1つ提示します。

1. 公式チュートリアルのGetting Startedをひととおり試す

2. 開発モードでKV v2・ポリシー・トークン発行を手を動かして確認

3. Docker Composeで本番モード相当を起動し、Auto-Unsealと初期化まで通す

4. TerraformでVaultの構成をコード化してみる

5. Kubernetes上でVault Agent Injectorを使ったサンプルアプリを動かす

6. Databaseシークレットエンジンで動的発行を体験する

参考リソース

• HashiCorp公式：Vault Documentation

• HashiCorp Developer：Vault Tutorials

• GitHub：hashicorp/vault

なお、公式ドキュメントは執筆時点のバージョンで内容が変わるため、CLIオプションや推奨構成はリリースノートで最新の状態を確認する運用が安全です。

まとめ

HashiCorp Vaultは、シークレット管理・動的発行・暗号化APIを一元化するプラットフォームで、Kubernetes・マルチクラウド前提の現場ほど導入効果が出やすいツールです。

要点を整理すると次のとおりです。

• Vaultは「認証 → 認可 → シークレットエンジン」の3層構造で、静的シークレットだけでなく動的シークレット・暗号化APIまで扱える

• OSS版・Enterprise版・HCP Vaultの違いは、要件と運用体制で選び分ける

• Kubernetes連携（Vault Agent Injector・CSI Driver）とTerraformでの構成管理が実務の定番セット

• 案件は「DevOps・SREの要件の一部」として登場するケースが多く、Kubernetes・Terraform・クラウド運用と合わせて評価される

• 導入時はUnseal運用・ポリシー最小化・監査ログ・バージョンアップ計画を最初に決めておくと事故が減る

次のステップとしては、まず開発モードで一周動かし、TerraformでVaultの構成をコード化してみる流れが実務に近く、案件参画後の立ち上がりが早くなります。フリーランスとしては、SRE・DevOpsエンジニアとしての実務力とセットで示せると、参画案件の選択肢が広がりやすい領域です。

参照元・一次情報

• HashiCorp Developer：Vault Documentation

• HashiCorp Developer：Vault Tutorials

• GitHub：hashicorp/vault