HashiCorp Vault と Platform Engineering で目指す、使ってもらえるシークレット管理プラットフォーム / secrets-management-people-actually-want-to-use-hashicorp-vault-platform-engineering

IBM TechXChange Summit Japan 2026 Summer

Transcript

1. IBM TechXchange Summit Japan 2026 HashiCorp Vault と Platform Engineering で目指す、使ってもらえる シークレット管理プラットフォーム 株式会社エーピーコミュニケーションズ ACS 事業部 埜下 太一 © 2026 IBM Corporation
2. 自己紹介 株式会社エーピーコミュニケーションズ 埜下 太一 Taichi Nonoshita HashiCorp Ambassador 2024-2025 IBM Champion 2026 四国在住３児の父 ののし @nnstt1 2
3. 会社紹介 ※投票は終了しています 3
4. 会社紹介 4
5. 本日お話しすること HashiCorp Vault 導入支援に携わる中で辿り着いた考えについてお話しします。 01 02 03 意識していること つまずいたこと 今後の展望 HashiCorp Vault をシー プラットフォーム導入後 シークレット管理プラッ クレット管理プラットフ に新たに見えてきた課題 トフォームをどう広げる ォームとして構築・導入 べきか、HashiCorp するためのプラクティス Vault をどう活用するか 5
6. SECTION 01 背景 背景 意識していること つまずいたこと 今後の展望 まとめ 6
7. 背景 > シークレット管理が必要な理由 シークレットが漏洩することで情報資産が流出し、企業の信頼と存続を脅かす。 従来の課題 シークレット管理の価値 ハードコード問題 中央集権管理 コードやファイルに認証情報を直接記述し、Git リポジトリなどを 経由して漏洩するリスク すべての認証情報を暗号化されたストレージで一元管理 管理の複雑化 有効期間の短いシークレット 複数環境で異なる認証情報を手動管理。更新作業が煩雑でミスが発 生 必要なときに自動生成、使用後は自動失効して漏洩リスクを最小化 アクセス制御の欠如 詳細な監査ログ いつ誰がアクセスしたか追跡できない。権限管理が困難で内部脅威 に脆弱 すべてのシークレットへのアクセスを記録 ローテーション困難 自動ローテーション 認証情報の定期変更が手動作業。ローテーションできているか把握 できない 定期的な認証情報の自動更新 7
8. 背景 > シークレットの特性 管理されていないシークレットほどリスクが高い。 HashiCorp Vault でシークレットを一元管理して漏洩リスクを減らす。 8
9. 背景 > HashiCorp Vault とは シークレットを安全に一元管理・動的発行するためのプロダクト。 シークレット管理以外にもデータ暗号化や証明書管理もできる。 シークレット管理 データ暗号化 証明書管理 パスワードや API キーな アプリケーションデータ PKI 機能による証明書の どを安全に一元管理 の暗号化・復号を提供 発行・管理 9
10. 背景 > HashiCorp Vault の提供形態 無償版からマネージドまで、要件に応じて選べる。 COMMUNITY SELF-HOST Vault コミュニティ版 Vault Enterprise • 無償・セルフホスト • セルフホストの商用 Vault • 機能は限定的 • 高度な機能を利用可能 • シークレット管理/データ暗号 化/証明書管理は利用可能 MANAGED HCP Vault Dedicated • Vault Enterprise のマネージ ドサービス版 • クラスタ管理は HashiCorp (IBM) 10
11. 背景 > なぜ Vault を導入したのか 散らばったシークレット管理からの脱却を目指す。 BEFORE AFTER 不適切なシークレット管理 Vault による一元管理 • マルチクラウド前提のプラットフォームと して Vault を採用 • コミュニケーションツールの コード内にシークレットを記載して DM でシークレットを共有 バージョン管理システムに登録 トップダウンで導入プロジェクトが始動 11
12. 背景 > 体制 SRE チーム内に Enabling チームと Platform チームがある。 メイン担当はあるが SRE チームとしての作業に明確な境界線はない。 SRE チーム Enabling チーム Platform チーム システムの信頼性を高める手法 開発チームが共通して使う を開発チーム自身が実践できる プラットフォームを提供 ようにサポート 12
13. 背景 > Vault を使ったシークレット管理プラットフォーム HCP Vault Dedicated は Terraform で構成管理している。 開発者は Terraform を使って Vault にシークレットを登録・更新できる。 本番~開発環境のシステム 開発者 HCP Terraform 監視 ダッシュボード ドキュメント シークレット管理 プラットフォーム HCP Vault Dedicated 13
14. SECTION 02 Vault 導入で 意識していること 背景 意識していること つまずいたこと 今後の展望 まとめ 14
15. 意識していること > シークレット管理を現場での関心事にする 開発者自身が目的を理解し、開発生産性を維持したシークレット管理を実践する。 それをサポートするプラットフォームを提供することが我々のミッション。 トップダウンでルールを決める 開発者自身が納得して選び、使いこなす設計へ ! 開発フローに沿わずに開発生産性の低下に繋がる ! 形だけの遵守やシャドー IT に走り、リテラシー が育たず逆に脆弱になる 「押し付け」ではなく「使いたくなる選択肢」として プラットフォームを用意する Platform Engineering を活用 15
16. 意識していること > Platform Engineering 少ないリソースでレバレッジを効かせ、ビジネス価値の提供を早くするプラクティス。 プラットフォームチームとして取り組んでいく。 1 開発者体験 (DevEx) の向上 開発者の価値創出を遅くする「認知負荷」を下げる。 2 セルフサービス 開発者自身でプラットフォームを操作して環境構築・デプロイなどをでき る状態にする。ゴールデンパスや内部開発者プラットフォームを提供して 実現する。 3 Platform as a Product 開発者を「顧客」と見立てて、商品であるプラットフォームが選ばれるた めに、プロダクトマネジメントの視点でプラットフォームの改善を続ける。 16
17. 意識していること > 開発チームとプラットフォームチームの関係性 開発チームがプラットフォームを使えるように X-as-a-Service として提供していく。 初期段階は開発チームとコラボレーションしてプラットフォームの要件を見極める。 X-as-a-Service Enabling SRE ファシリテーション コラボレーション 開発チームA 開発チームB 開発チームC Platform 17
18. 意識していること > ① 開発者の気持ちに寄り添う 誰しもシークレット管理が必須で重要性もことはわかっている。 だけど、やりたくてやってるわけじゃないを理解することが大事。 • シークレット管理を始めとしたセキュリティ対策は情報システムの価値を守るための「守り」 • 開発者はシステムを作ってビジネス価値を提供する「攻め」に集中したい • 背景を理解した上で設計すると、認知負荷を下げるポイントが見えてくる • 開発者にとって「使う方が楽」な状態になるとプラットフォームが使われる 開発者の背景を理解してプラットフォームを提供することが 使われるプラットフォームに繋がる 18
19. 意識していること > ② 開発者の気持ちを想像しない 勝手に想像してプラットフォームを改良しても開発者体験が向上するかは分からない。 「使いやすいはず」という思い込みではなく、開発者からの情報が確かな判断材料。 プラットフォームチームの想像 開発者の「生の声」を聞く ✓ ✓ 「使いやすそう」 「この機能が欲しいのでは」 根拠がない＝使われない ？ フィードバックを得る仕組みを用意 対話の場（定例・1on1）で直接聞く 確かな判断材料になる ✓ 19
20. 意識していること > ③ 関係性の構築 開発チームとの信頼を積み上げ続けることがプラットフォームの改善に繋がる。 信頼関係構築のための行動 定例に顔を出す 相談を真摯に受け止める 信頼関係構築によるメリット 浮いたボールを拾う フィードバックを 双方の相談の 得やすくなる ハードルが下がる 協力を得やすくなる 同じ釜の飯を食う （身体の同調） 20
21. 意識していること > ④ 自分たちでプラットフォームを使う 担当者が自らプラットフォームを触っても無意識に情報を補完して穴に気づけない。 プラットフォームチームも普段からシークレットを Vault で管理、フィードバックする。 開発者 プラットフォームチーム フィードバック ドッグフーディング 改善 利用 HCP Vault Dedicated 21
22. そうは言っても うまくはいかない 22
23. 余談 「HashiCorp, an IBM company になって変わったなぁ」ってこ と コスト周りの見直し • HCP Vault Secrets のサービス終了 • HCP Vault Dedicated の最低料金値上げ • HCP Terraform のプラン変更 Vault 2.0 に関する話 • 大きな機能追加ではなく、IBM 買収後の方針 転換がメジャーバージョンとして表れている （個人の感想） • Vault のわかりにくさを改善する機能が追加 23
24. 閑話休題 24
25. SECTION 03 Vault 導入で つまずいたこと 背景 意識していること ① Vault の属人化 ② あいまいなセルフサービス境界 ③ 料金体系 つまずいたこと 今後の展望 まとめ 25
26. つまずいたこと > ① Vault の属人化 Vault の問い合わせが 1 人に集中し、プラットフォームの改善に手が回らなくなった。 プラットフォームチーム内で持続的に Vault を学習するための環境が必要。 なぜ属人化が起きたか 対策後も残る難しさ ! Vault 自体が難しく、相応の学習コストが必要 HCP Vault Dedicated でクラスタ管理はアウトソースで きるが、残る Vault 内部設計も十分に難しい ! Platform Engineering は認知負荷をプラット フォームチームへオフロード ＝プラットフォームチームは深く理解し続け る必要がある HCP Terraform は標準ツール化できているが、 HCP Vault Dedicated はドッグフーディングだけでは 理解が深まらない 26
27. つまずいたこと > ② あいまいなセルフサービス境界 トップダウンによる導入の勢いのままセルフサービスの境界を詰めきれなかった。 プロダクトごとに責任範囲がバラバラになり、個別チューニングが必要に。 自由度：大 自由度：小 開発チーム A 開発チーム B 開発チーム C 名前空間を作ったら あとは自由 シークレットエンジンは自由 ポリシーはプラットフォーム管理 シークレットエンジン・ ポリシーまでプラットフォーム管理 HCP Vault Dedicated 同じプラットフォームなのに境界の引き方はチームごとにバラバラ 27
28. つまずいたこと > ② あいまいなセルフサービス境界 開発チームから「暗号化サービスとしても Vault を使いたい」と相談がきた。 暗号化プラットフォームを見据えたセルフサービス境界を決めることがターゲット。 1 現在の境界 将来の境界候補 特定の開発チーム向けのみに提供中 暗号化プラットフォームを含む範囲を検討中 現在の提供範囲 現在は特定の開発チーム向けにのみ 機能を提供 2 最初のステップ まずは開発チームとプラットフォー ムチームでコラボレーション 3 備えておくこと 今後、他チームからも要望が来た 場合に備え、セルフサービスの境 界線を事前に検討 28
29. つまずいたこと > ③ 料金体系 HCP Vault Dedicated は利用者数に応じた料金体系になっている。 契約クライアント数に縛られて開発者に Vault 利用を推進しづらい状況。 HCP Vault Dedicated の料金 ＝ マシンサイズ ＋ クライアント数（利用者・サービス） Admin 名前空間 エンティティ 子名前空間 A 子名前空間 B エンティティ エンティティ ! 同じ開発者でも Vault の違う名前空間に アクセスするとそれぞれエンティティが 作られて、個別のクライアント数として カウントされてしまう 同利用者 エンティティ＝料金にカウントされるクライアント数 29
30. つまずいたこと > ③ 料金体系 現在は複雑さ・利便性と引き換えにクライアント数を抑えている。 開発チームごとに少人数の「シークレット管理担当」を選出してもらう案を検討中。 エンティティを Admin 名前空間に集約する設計 HCP Terraform 経由でシークレットを登録 エンティティ＝料金にカウントされるクライアント数 Admin 名前空間 ✓• HCP Vault Dedicated にはログイン ✓• 子名前空間へのエンティティ させずクライアント数を抑制 作成を抑制 エンティティ 子名前空間 A 子名前空間 B グループ グループ ! • Vault と Terraform の構成が複雑化 ! • 認証・認可の構成が複雑化 ! • 名前空間跨ぎの認証・認可に 対応していないライブラリ ! • 開発者がシークレット履歴を見られ HCP Terraform ない HCP Vault Dedicated ポリシー ポリシー 30
31. SECTION 04 今後の展望 ① ソフトウェア開発ライフサイクル全体のカバー ② チャットに平文を貼らないシークレットの受け渡し ③ AI エージェントとの協働 背景 意識していること つまずいたこと 今後の展望 まとめ 31
32. 今後の展望 > ① ソフトウェア開発ライフサイクル全体のカバー 現在は Vault で運用フェーズのシークレット管理のみカバーできている状態。 今後は Vault 以外の仕組みも使って SDLC 全体のシークレット管理に対応していく。 HCP Vault Dedicated GitHub Advanced Security • シークレット登録防止 • シークレット検出 • 各実行環境のシークレット管理 32
33. 今後の展望 > ② チャットに平文を貼らないシークレットの受け渡し Vault の Cubbyhole Response Wrapping でセキュアなシークレット受け渡し機能を提供。 コミュニケーションツールでのシークレット共有の撲滅を目指す。 Cubbyhole Response Wrapping ワンタイムトークン (1度使うと失効) TTL 超過で自動的にトークン破棄 傍受を検知可能 ③ ① ② HCP Vault Dedicated ④ 一時トークンでシークレット取得 ① シークレットを Cubbyhole に登録 ② Vault から一時トークンを取得 ③ 一時トークンを利用者に送信 33
34. 今後の展望 > ③ AI エージェントとの協働 今後は開発者だけでなく AI エージェントによるプラットフォーム利用が増加していく。 プラットフォームチームは AI エージェントとの関わり方に応じた準備を必要。 1 2 プラットフォーム側にも AI エージェントを用意する • プラットフォームチームが AI エージェントを用意し、Terraform コード編集など を Issue ベースで依頼できるセルフサービス窓口にする。 • 料金体系の制約で複雑化した Terraform 運用の負荷を AI の力で緩和する。 開発者側の AI エージェントを想定した準備をする • 開発者の AI エージェントが迷わずプラットフォームを操作できるよう、 Agent Skills や MCP、ドキュメントを整備する。 • 専門知識を人に貯めるだけでなく、AI エージェントに肩代わりさせる準備を することが属人化の緩和になる。 34
35. SECTION 05 まとめ 背景 意識していること つまずいたこと 今後の展望 まとめ 35
36. まとめ シークレット管理の目的はセキュリティ被害から情報資産や企業を守ること。 開発者自身が目的を理解し、開発生産性を維持したシークレット管理を実践する。 それをサポートするプラットフォームを提供することが重要。 シークレット管理は HashiCorp Vault を入れるだけではダメ 組織に合わせてプラットフォームを構築・導入することが大事 36