Infisical 完全ガイド 2026｜オープンソースのシークレット管理を AI 開発で活用する

AI Beat（エーアイビート）編集部です。

AI 開発の現場で、API キーの取り扱いが今まで以上に重い課題になっています。OpenAI、Anthropic、各種 MCP server、ベクター DB、画像生成 API。エージェント開発を進めるほど扱うシークレットは増え、漏えい時の被害範囲も拡大します。Vercel が 2026 年 4 月に公表した Context AI 経由の OAuth 奪取は、その典型例でした。

そこで注目を集めているのが、オープンソースのシークレット管理プラットフォーム Infisical です。HashiCorp Vault や AWS Secrets Manager より軽量に始められ、セルフホストの柔軟性も持つ。編集部でも Claude Code と MCP server の認証情報管理に試験導入し、手応えを確かめました。

本記事では、Infisical のコア機能、HashiCorp Vault / AWS Secrets Manager / Doppler との比較、AI 開発特有の課題、5 つのベストプラクティスを 2026 年 4 月時点の最新情報で整理します。読み終えると、自社の AI 開発体制に Infisical を組み込むべきかが判断できるようになります。

Table of contents

Infisical とは｜オープンソース・セルフホスト可のシークレット管理プラットフォーム
1. Infisical が解決する 3 つの課題
2. 競合との位置づけ
Infisical のコア機能｜Secret Management・Identity・PKI の 3 本柱
Infisical vs HashiCorp Vault｜詳細比較表で見る使い分け
1. 機能対比表
2. 選び方のガイドライン
Infisical vs AWS Secrets Manager / Doppler｜マネージド系競合との比較
AI 開発で発生するシークレット管理の課題｜API キー・Claude Code・MCP server
AI 開発でのシークレット管理ベストプラクティス 5 つ
Infisical の導入ステップ｜セルフホストとマネージド SaaS の選択
AI Beat 編集部の見解｜Infisical を AI 開発の標準装備にすべき理由
よくある質問（FAQ）
まとめ｜AI 開発における Infisical の位置づけ

Infisical とは｜オープンソース・セルフホスト可のシークレット管理プラットフォーム

Infisical とは、API キー・データベース認証情報・証明書などのシークレットを一元管理できるオープンソースのプラットフォームで、セルフホストとマネージド SaaS の両方に対応します。

2022 年に米国でローンチされ、2024 年に Y Combinator を経由したシリーズ A 調達で本格的に成長フェーズに入りました。Infisical 公式サイトによれば、2026 年 4 月時点で 15,000 を超える組織で利用されており、GitHub スター数も 20,000 を突破しています。

Infisical が解決する 3 つの課題

シークレット管理ツールが注目される背景には、開発現場の生々しい課題があります。

.env ファイルの平文保存。リポジトリへの誤コミットや、開発者の PC ローカルに残った認証情報が漏えい源になる
認証情報のローテーション忘れ。退職者のキーが残り続け、半年後に攻撃に使われるケースが後を絶たない
環境ごとの分離不足。本番用の API キーが開発環境にも書かれており、ステージングのバグから本番データが漏えいする

Infisical はこの 3 つを、暗号化されたボールト・自動ローテーション・環境別アクセス制御という三層で解決します。

競合との位置づけ

シークレット管理の世界には HashiCorp Vault という巨大な先駆者がいます。エンタープライズ向けに完成度の高い機能を持つ一方、運用負荷が高く中小規模のチームには重すぎるという声も少なくありません。Infisical は「Vault ほど重くなく、AWS Secrets Manager よりベンダーロックインが弱い」というポジションを取り、開発者体験を重視した設計が支持されています。

編集部としても、社内で Vault を本格運用するには専任 SRE が必要になりがちで、AI 開発のスピード感とは相性が悪いと感じる場面が多々ありました。Infisical はその間隙を突いた製品です。

Infisical のコア機能｜Secret Management・Identity・PKI の 3 本柱

Infisical は単なるシークレット保管庫にとどまらず、Identity 管理と PKI（Public Key Infrastructure）まで統合した複合プラットフォームに進化しています。

Secret Management（シークレット管理）

中核機能はシークレット管理です。AES-256-GCM による暗号化、E2EE モード、バージョニング、ロールバック、Webhook トリガーによる自動同期など、必要な機能はひととおり揃います。

特に注目したいのが「Dynamic Secrets」です。データベースや AWS IAM への一時認証情報を必要なタイミングで動的に発行する仕組みで、長期保存される静的キーをそもそも持たない設計を実装しています。

Machine Identity（マシン識別）

CI/CD パイプライン、Kubernetes クラスタ、AI エージェントなど「人ではない主体」に認証トークンを発行・管理する機能です。GitHub Actions、AWS、Azure、GCP、Kubernetes Service Account との OIDC 連携をネイティブサポートし、長期キーをばらまかない設計が可能になります。

「エージェントに API キーを直接渡したくない」というニーズに対し、短命トークンを動的発行できる Machine Identity は強力な選択肢です。

PKI（証明書管理）

2024 年以降、Infisical は PKI 機能を拡張しています。内部 CA 構築、X.509 証明書の発行・失効管理、ACME 対応など、Vault の PKI Secrets Engine が担ってきた領域に踏み込んでいます。マイクロサービス間 mTLS や社内ツール SSO 連携で必要になるケースが増えており、シークレット管理と一体で使える設計が好評です。

補足機能

Secret Scanning。Git リポジトリやファイルシステムから、漏えいしたシークレットを検出する
Approval Workflows。本番シークレットの変更に承認フローを必須化できる
Audit Logs。誰がいつ何のシークレットにアクセスしたかを完全記録する
SDK 提供。Node.js、Python、Go、Java、.NET 用の SDK が公式提供される

Infisical vs HashiCorp Vault｜詳細比較表で見る使い分け

シークレット管理を語る上で避けて通れないのが HashiCorp Vault との比較です。両者は同じ目的を持ちながら、設計思想と運用コストが大きく異なります。

機能対比表

項目	Infisical	HashiCorp Vault
ライセンス	MIT（コア）+ Enterprise	BSL（2023 年以降）+ Enterprise
セルフホスト	Docker Compose で 5 分	Consul / Raft の構築が必要
Dynamic Secrets	主要 DB / AWS / GCP	30 種類以上の Secret Engine
PKI 機能	2024 年以降に拡充	10 年以上の実績
UI 完成度	高い（モダンな SPA）	必要十分
運用負荷	低い（兼任 SRE で OK）	高い（専任 SRE 推奨）
料金（マネージド）	Free〜$18/seat/月	HCP Vault: $0.03/時間〜
日本語対応	UI 一部のみ	ドキュメントは英語

選び方のガイドライン

多種多様な Secret Engine を使い倒す予定があり、専任 SRE を抱えているなら依然として Vault が有力です。HashiCorp Vault 公式が掲げる「Secrets at Scale」のメッセージどおり、大規模環境での実績は他の追随を許しません。

一方、スタートアップから中堅企業の AI 開発チーム、エージェントを内製する組織には Infisical が導入しやすいケースが多くなります。Infisical 公式ドキュメントのとおり、初期セットアップは Docker Compose で 5 分以内、UI も直感的です。

編集部で両者を試した感触は、Vault は「習熟すれば最強」、Infisical は「最初から快適」。AI 開発のように要件が変動しやすい現場では、後者の軽さが効きます。

Infisical vs AWS Secrets Manager / Doppler｜マネージド系競合との比較

Infisical の競合は Vault だけではありません。AWS Secrets Manager や Doppler のような SaaS 専業サービスも有力な選択肢です。

AWS Secrets Manager との比較

AWS を全面的に使っている組織であれば、AWS Secrets Manager は自然な第一候補です。AWS Secrets Manager 公式によれば、Lambda・RDS・ECS などとのネイティブ統合が強力で、IAM ポリシーで権限管理を完結できる点も大きな魅力です。

ただし、料金は 1 シークレットあたり月 0.4 ドル + API 呼び出し 1 万回ごとに 0.05 ドルがかかります。シークレット数が数百を超える AI 開発環境では、無視できないコストになります。さらに、マルチクラウド構成や、AWS 外の SaaS（Vercel、Cloudflare、Snowflake など）への配信を考えると、AWS Secrets Manager だけでは完結しない場面が増えてきます。

Infisical はマルチクラウドや SaaS 連携に強く、Webhook と Integration の選択肢が豊富です。AWS にロックインしたくない、あるいは複数クラウドを跨ぐチームには Infisical が向きます。

Doppler との比較

Doppler は Infisical と同じく「開発者体験重視」のシークレット管理 SaaS です。Doppler 公式によれば、CLI からのアクセス性や CI/CD 連携の手軽さでは Infisical と双璧を成します。

両者の最大の違いは、セルフホストの可否です。Doppler はマネージド SaaS 専業で、オンプレや VPC 内で完結させる選択肢がありません。一方の Infisical は MIT ライセンスのオープンソース版を自社環境で動かせるため、規制業界（金融・医療・公共）では Infisical が選ばれやすい傾向にあります。

三者比較サマリー

観点	Infisical	AWS Secrets Manager	Doppler
セルフホスト	可	不可	不可
マルチクラウド	強い	AWS 偏重	強い
料金透明性	高い（seat 制）	従量課金で読みづらい	高い（seat 制）
OSS コミュニティ	活発	クローズド	クローズド
規制業界対応	強い（自社運用可）	条件付き	条件次第

💡 ワンポイント AWS だけで完結するチームは AWS Secrets Manager、開発者体験を最優先するならどちらでも、自社環境で完結させたいなら Infisical 一択になります。最初の判断軸はセルフホストの要否です。

AI 開発で発生するシークレット管理の課題｜API キー・Claude Code・MCP server

AI 開発の現場には、従来の Web 開発にはなかった独特のシークレット管理課題が存在します。Infisical の真価が問われるのは、まさにこの領域です。

LLM API キーの大量化

ChatGPT、Claude、Gemini、Mistral、ローカル LLM の認証情報に加え、OpenAI Embeddings、Anthropic Cache API、Voyage AI のリランカー。AI 機能を 1 つ作るだけで数本の LLM 関連キーを扱います。マルチモデル戦略を採るチームでは 1 サービスあたり 5〜10 本が当たり前で、.env 管理ではすぐに統制が崩壊します。

Claude Code やエージェントツールの認証情報

Claude Code、Cursor、Aider など AI コーディングエージェントは外部 API への直接アクセスが必須です。これらに渡す認証情報は開発者 PC ローカルに保存されがちで、PC 紛失や退職時のクリーンアップが甘くなります。

編集部でも、Claude Code に渡す API キーの管理方針は何度も議論になりました。最終的に「個人に紐づく Machine Identity を Infisical で発行し、組織レベルの API キーを直接配布しない」方針に落ち着きました。

MCP server の認証情報

Model Context Protocol（MCP）の普及で、エージェントが Notion、Slack、GitHub、DB に直接アクセスする構成が増えています。MCP 公式仕様では各 server に個別クレデンシャルを設定する設計のため、サーバー数に比例して認証情報も増えます。

ここで起きやすいのが「MCP server がローカルに認証情報を保存し、複数の AI ツールから読み出す」構造で、エージェントが意図せず本番環境にアクセスしてしまうリスクです。Vercel の 2026 年 4 月インシデントも近い構造でした。

ベクター DB やワーカーの認証情報

Pinecone、Weaviate、Qdrant、Chroma などのベクター DB、画像生成 API（fal.ai、Replicate）、Inngest や Trigger.dev のジョブキュー。AI 開発では「外部サービスとの接続点」が爆発的に増えます。

LLM 系で 5〜15 本
エージェントツール系で 3〜10 本
MCP server 系で 5〜20 本
ベクター DB / ワーカー系で 3〜10 本

平均的な AI プロダクト開発チームで、1 プロジェクトあたり数十本のシークレットを扱う計算になります。Infisical のような専用ツールなしで運用するのは、現実的ではありません。

AI 開発でのシークレット管理ベストプラクティス 5 つ

ここからは、Infisical を導入する前提で、AI 開発に特化したベストプラクティスを 5 つ整理します。

ベストプラクティス 1: 環境を厳格に分離する

開発・ステージング・本番のシークレットは、Infisical の Environment 機能で完全に分離します。

本番の API キーを開発環境で読み取れない設定にする
環境間の Secret コピーは手動承認フローを必須化する
個人開発者用の Sandbox 環境を別建てにし、本番データに触れさせない

これだけで、AI エージェントが暴走したときの最大被害範囲を 1 桁絞れます。

ベストプラクティス 2: 自動ローテーションを有効化する

LLM API キーや DB 認証情報は、3 ヶ月に 1 度のローテーションを Dynamic Secrets でスケジュール化します。手作業のローテーションは必ず形骸化するため、最初から自動化するのが鉄則です。

退職者が出たときに「このキーは誰が発行して誰が使っているのか」を辿るのが難しい構造を防ぐため、Machine Identity と組み合わせ、人ではなくマシンに紐づけて発行する設計に切り替えます。

ベストプラクティス 3: 監査ログを全件保存する

Audit Logs を有効化し、最低 1 年は全アクセス記録を保存します。AI エージェントが意図しないデータにアクセスしたときに、後追いで原因特定できる状態がガバナンス上の最低ラインです。

NIST Cybersecurity Framework の Detect / Respond / Recover カテゴリも監査ログの実装を求めています。Infisical は Datadog / Splunk などの SIEM 連携を標準サポートしており、既存運用に組み込みやすい設計です。

ベストプラクティス 4: 最小権限の原則を徹底する

エージェント・CI/CD・開発者の各主体に、必要最小限のシークレットのみアクセス可能にします。RBAC と Tag を組み合わせ、「LLM 系だけ」「DB 系だけ」といった粒度で権限を切ります。

特に AI エージェントは、本来不要なシークレットにまでアクセス可能な状態で動かされがちです。エージェントごとに個別の Service Token を発行し、必要なシークレットだけを与える運用へ切り替えます。

ベストプラクティス 5: シークレットを直接渡さず参照型にする

CI/CD や Kubernetes ワークロードには、シークレットの値そのものを環境変数で渡さず、Infisical の参照（Reference）を渡します。実行時に Infisical から取得することで、ログやエラー出力に平文で漏れるリスクを抑えられます。

💡 ワンポイント AI エージェントの実行時は、エラースタックトレースが LLM のコンテキストに混入することがあります。シークレットがログに残らない設計にしておかないと、LLM プロンプトインジェクション経由で漏えいする経路まで開いてしまいます。

Infisical の導入ステップ｜セルフホストとマネージド SaaS の選択

導入手順は、セルフホストかマネージド SaaS かで分岐します。マネージド SaaS は最短 10 分で稼働、セルフホストは 1〜2 日が目安です。

マネージド SaaS の導入ステップ

アカウント作成。Infisical Cloud で組織を作成
プロジェクト作成。アプリケーション単位でプロジェクトを切る
Environment 設定。Development / Staging / Production を分離
Secret 投入。CLI または UI から既存の .env をインポート
SDK 統合。アプリケーションコードを Infisical SDK 経由のシークレット取得に書き換え
CI/CD 連携。GitHub Actions / GitLab CI / Vercel に Infisical Token を設定
本番切り替え。.env ファイルをリポジトリから完全削除、本番デプロイで切り替え完了

セルフホストの導入ステップ

セルフホストは Docker Compose または Helm チャートで構築できます。AWS / GCP / Azure の VPC 内、あるいはオンプレミスの Kubernetes クラスタに展開する構成が一般的です。

PostgreSQL（メタデータ保存）と Redis（キャッシュ）が必要になり、これらは既存のマネージド DB（RDS、Cloud SQL）を流用するのが楽です。HA 構成にする場合は、Infisical アプリ層を 3 ノード以上で水平展開し、PostgreSQL も Multi-AZ で組みます。

料金体系

プラン	料金	主な機能
Free	0 ドル	5 ユーザー、3 プロジェクト、Audit Logs 7 日
Pro	18 ドル/seat/月	無制限プロジェクト、Audit Logs 30 日、SAML SSO
Enterprise	個別見積	SLA、専任サポート、Audit Logs 1 年以上、HSM 対応
Self-Hosted Community	0 ドル	MIT ライセンス、機能制限あり
Self-Hosted Enterprise	個別見積	機能フル、サポート付き

2026 年 4 月時点の公式料金で、最新の価格はInfisical 公式の料金ページを必ず確認してください。

AI Beat 編集部の見解｜Infisical を AI 開発の標準装備にすべき理由

編集部は、2026 年現在、AI 開発に取り組む組織が「シークレット管理ツールを持っていない」状態は、もはやリスク許容を超えていると考えています。

スコープの拡大に運用が追いつかない

理由は単純で、AI エージェント開発のスピードに対して、人手による .env 管理の精度が追いつかないからです。LLM 1 種類だった時代から、5 種類のモデルをフォールバック構成で使い、20 種類の MCP server に接続する構成へとわずか 1 年でスコープが拡大しました。手で管理できる規模をとうに超えています。

加えて AI エージェントは「与えられた認証情報を最大限使う」よう設計されているため、不要なシークレットにアクセス可能な状態で動かすと想定外の挙動を起こす確率が跳ね上がります。最小権限の原則を物理的に強制できる仕組みなしには、本番にエージェントを置くべきではありません。

Vault でも AWS Secrets Manager でもなく Infisical を推す理由

Vault は強力ですが専任 SRE がいないチームには重すぎる。AWS Secrets Manager は AWS ロックイン前提でマルチクラウドや SaaS 連携が弱い。この 2 つの隙間を Infisical がちょうど埋めています。

しかも Infisical はオープンソースのため、企業が消えても自社運用を続けられる安心感があります。AI 開発のように長期運用が前提のシステムでは、ベンダーロックインの薄さが意外と効いてきます。Doppler のような SaaS 専業サービスにはない強みです。

現実的な導入プラン

編集部が推奨するのは、以下の 3 段階アプローチです。

Phase 1（1 週間）。Infisical Cloud の Free プランで 1 プロジェクト試用、開発環境のみ移行
Phase 2（1 ヶ月）。Pro プランに昇格、ステージング・本番まで展開、CI/CD 統合
Phase 3（3 ヶ月）。規制要件に応じてセルフホスト版へ移行、または Enterprise に昇格

最初から完璧を目指さず、Free プランで触ってから判断する。AI 開発のテンポにはこのやり方が合います。すでに Vercel 2026 年 4 月セキュリティインシデント解説や AI エージェント時代のセキュリティ脅威モデルでも触れたとおり、認証情報の取り扱いは AI 時代の最大の弱点です。MCP server セキュリティの実装ガイドとあわせて、組織として一段上の運用に進めるかどうかが問われています。

よくある質問（FAQ）

Q. Infisical は完全無料で使えますか

A. オープンソース版（Self-Hosted Community）は MIT ライセンスで完全無料です。マネージド SaaS の Free プランも 5 ユーザー・3 プロジェクトまで無料。本格運用するチームは Pro プラン（18 ドル/seat/月）に進むケースが多いです。

Q. HashiCorp Vault からの移行は難しいですか

A. シークレットのインポートは CLI で一括対応できますが、Dynamic Secrets や PKI を全面活用している場合は移行コストが上がります。まず開発環境で併用運用し、段階的に切り替える方針をおすすめします。詳しくは Vercel 2026 年 4 月セキュリティインシデント解説でも触れた構造的課題と合わせて検討してください。

Q. AI エージェントに API キーを直接渡しても問題ないですか

A. 推奨しません。Machine Identity で短命トークンを動的発行し、エージェントには API キーではなくトークンを渡す設計にしてください。万が一エージェントが意図しない動作をしても、被害範囲を時間と権限で制限できます。

Q. セルフホスト版と SaaS 版で機能差はありますか

A. Self-Hosted Community 版には SAML SSO や HSM 対応など一部の Enterprise 機能が含まれません。フル機能を自社環境で使いたい場合は Self-Hosted Enterprise を契約します。SaaS の Pro 版で十分なチームも多く、要件次第です。