1Password vs Infisical｜AIコーディング時代の個人開発シークレット管理
Claude CodeやCursorなどのAIコーディングアシスタントを使い始めてから、APIキーや環境変数の取り扱いに不安を感じている方は多いのではないでしょうか。私自身、長年 .env ファイルでローカルにシークレットを置く運用を続けてきましたが、AIアシスタントの普及で「もう .env のままではまずい」と感じる場面が明確に増えてきました。
この記事では、個人開発者・小規模チーム向けのシークレット管理ツールとして注目度が高い 1Password と Infisical を、機能・料金・AI連携の観点で比較します。両者とも私自身がいま選定中の段階で、実機で長期運用した結果ではなく、公式情報・業界レポート・実装ドキュメントを当たって検討した結果のまとめです。導入前検討の参考にしてください。
なぜ「.envを裸で置く」がAIコーディング時代に危険なのか
個人開発者の多くが今も .env や .env.local でローカルにキーを置き、.gitignore で除外する運用を続けています。これは Node.js の世界では長く標準でした。実際 dotenv パッケージは週間4,500万ダウンロードを記録しており、Node.js v20.6 以降は --env-file がネイティブ対応するなど、エコシステム側もこの慣習を支えています。
では何が変わったのか。AIコーディングアシスタントの普及です。
AIアシスタントは.envを「読む」
セキュリティ調査会社 Knostic が2026年に公開した報告で、AIコーディングエージェントの実際の挙動が詳細に検証されました。報告によれば、Claude Code は対話の中で必要に応じて .env や .env.local を黙ってコンテキストに読み込み、Cursor も同様の挙動をします。実害として「Claude Code が Gemini API キーを GitHub に commit した」「Cursor が API キーを含むファイルを外部にアップロードしようとした」といった具体的な事例が公開されています。
これは「AIに渡してはいけない情報」と「AIが扱える情報」の境界が、従来のローカル開発と根本的に違うことを意味します。.gitignore に書いてあるからといって、AIアシスタントの目には入っていないわけではありません。
漏洩率は人間コミットの2倍
GitGuardian の「2026 State of Secrets Sprawl」レポートでは、AI が関与したコミットからのシークレット漏洩率が、人間によるコミットの約2倍（3.2% 対 1.6%）に達することが報告されました。AIサービス系 credential（OpenAI API キー、Anthropic API キー等）の漏洩件数は前年比で81%増加しています。
背景には、AIが大量のファイルを横断して読み・書きするため、人間ならば踏みとどまるところで踏み込んでしまう傾向があります。「コードレビューの粒度」という人間の安全装置が、AIには標準装備されていません。
Vercelインシデント以降の業界動向
2026年4月に Vercel が経験したセキュリティインシデント以降、Vercel公式は「Sensitive フラグの有無に関わらず、保管されている全環境変数のローテーションを推奨する」と明言しました。これは「クラウドプラットフォーム側に置けば安全」という安易な前提が崩れたことを示しています。
GitHub も2026年3月に push protection の対応プロバイダを大幅拡張し、Vercel・Supabase・Snowflake・Lark などを含む28種に対応、9種を追加しました。Vercel・Figma・Google・PostHog などのキーは 個人アカウントでもデフォルトで push protection が有効化 されます。シークレット漏洩は「自分が気をつける」から「プラットフォームが事前に止める」時代に明確に移行しています。
候補ツール3つの俯瞰
個人開発者向けのシークレット管理として2026年時点で評価されているのは、大きく3つの方向です。
- 1Password + 1Password CLI: パスワードマネージャー型。UI が成熟しており、CLI（
op）も洗練されている - Infisical: オープンソース系。Self-host 可能、SDK が豊富、DevOps 寄りの設計
- sops + age: 完全無料で git に暗号化版を直接 commit する方式。鍵管理を自前でやる必要があり、上級者向け
このうち sops + age は記事の最後で軽く触れる程度にとどめ、本記事のメインの比較対象は 1Password と Infisical の2つに絞ります。両者は思想が大きく異なり、選択を間違えると運用負荷が変わるためです。
1Password を個人開発で使う実態
料金プラン
2026年時点の主なプランは次のとおりです。料金は USD ベースで、為替によって日本円換算は変動します。
- Individual: 月 $2.99 程度（年払い 約 $36）。1人用、CLI 利用可
- Families: 月 $4.99 程度。最大5人
- Teams Starter Pack: 月 $19.95、最大10人
- Business: ユーザーあたり月 $7.99 程度。Service Account（完全headlessな自動化向けトークン）が使えるのはこのプラン以上
個人開発者で、対話的に CLI を使う前提なら Individual プランで足ります。「cron や launchd で完全に headless な自動化を組みたい」という要件があると Business プランが必要になります。月500円前後で済む点は強みです。
CLI体験 — opコマンド
1Password の特徴は、CLI である op コマンドの体験が非常に洗練されている点です。代表的な使い方は2つあります。
1つめは op inject による値の埋め込み。プロジェクトに .env.1password.tmpl のようなテンプレートを置き、中に op://Personal/openai-api/credential のような参照だけを書きます。op inject -i .env.1password.tmpl -o .env を実行すると、参照が実値に展開された .env が生成されます。
2つめは op run による環境変数注入。op run -- next dev のように起動時にラップすると、テンプレートの参照を解決した状態で Next.js が立ち上がります。ファイルとしての .env を作らずにアプリを動かせるため、シークレットがディスクに書き出されません。AIアシスタントとの組み合わせを考えると、こちらが本命の使い方です。
macOS では Touch ID と統合されており、CLI からの値取得も指紋認証で承認できます。普段からパスワードマネージャーとして 1Password を使っていれば、開発用シークレットも同じ vault に「Secure Note」や「API Credential」として保存するだけで、追加学習はほぼゼロで済みます。
Vercelとの統合
1Password は Vercel と公式に統合されており、ダッシュボード上でリンクすれば、本番環境の Sensitive Environment Variables を 1Password の vault と同期させられます。「ローカル開発用の値も本番用の値も、保管の真実は 1Password」という一元管理が可能です。
想定されるハマりポイント
- セッションがロック解除されている前提なので、完全な無人運用にはService Account（Business以上）が必要
- vault 構造の設計を最初に決めておかないと、プロジェクト数が増えたときに乱雑になる
- 1Password のサブスクリプションが切れると、CLI から実値を取得できなくなる（ローカルキャッシュは限定的）
Infisicalを個人開発で使う実態
料金とself-host
Infisical は MIT ライセンスのオープンソースとして公開されており、GitHub のスター数は2026年2月時点で25,000を突破しました。Volkswagen、LG、Hugging Face などの採用事例が公式に公開されています。
料金体系は2系統です。
- Self-host: 完全無料。Docker で自分のサーバーや VPS に立てる
- Cloud（マネージド）: 個人 Free Tier あり、有料は月 $8/ユーザーから
「サブスクリプションを払いたくない」「将来チームに展開したときも内製で持っておきたい」という志向には Infisical の self-host が刺さります。一方で、self-host は VPS 代と運用責任が発生するため、個人開発者にとっては「無料」とは言い切れない面もあります。
SDK・CLI体験
Infisical は SDK が手厚く、Node.js / Python / Go / Java / Ruby など主要な言語で公式サポートされています。CLI も infisical run -- next dev のように、1Password の op run と同じ感覚で使えます。
違いとして、Infisical は最初から「環境（dev / staging / prod）」「フォルダ」「シークレットローテーション」といった DevOps 向けの概念をネイティブに持っています。1Password が「個人の認証情報も開発シークレットも一緒に管理する」のに対し、Infisical は「シークレット管理に専念したツール」という性格です。
Vercelとの統合
Infisical も Vercel との公式 Integration があり、ダッシュボード上で対象プロジェクトを選択すれば Vercel 側の環境変数に push 同期されます。複数環境（preview / production）の値分けも Infisical 側で完結できます。
想定されるハマりポイント
- Self-host する場合は VPS の維持・アップデート・バックアップが自分の責任になる
- パスワードマネージャー機能はないため、別途 1Password や Bitwarden を併用することになる
- 普段使いの認証情報と分離する分、ツール数が増えてアカウント管理が煩雑になりがち
機能・料金・適性の比較
主な観点で並べると次のようになります。
- 料金（個人）: 1Password = 月 $2.99 / Infisical = self-host無料 or cloud Free Tier
- OSS: 1Password = ❌ / Infisical = ✅（MIT）
- パスワードマネージャー兼用: 1Password = ✅（本来の用途） / Infisical = ❌（シークレット管理専門）
- CLI体験: どちらも
op run/infisical runで同等の使い心地 - Vercel公式Integration: 両者対応
- headless完全自動化: 1Password = Business プラン必須 / Infisical = self-host で柔軟
- 環境分離（dev/stg/prod）の概念: 1Password = vault 設計でカバー / Infisical = ネイティブにある
- セットアップの手軽さ: 1Password = アプリ導入のみ / Infisical = self-host なら VPS 構築あり
個人開発者・小規模チームの判断基準
条件A：すでに1Passwordをパスワード管理で使っている
これに当てはまるなら、追加検討なしで 1Password CLI に揃えるのが最短です。新しいアカウントを増やさず、既存の vault に開発シークレットを足すだけ。Touch ID 連携・PC 紛失時の即時無効化・新しい Mac での即復旧、すべてが既存の運用に乗ります。
条件B：OSS志向、将来的なチーム展開を視野
受託開発でクライアントごとに環境を分けたい、将来的にメンバーを増やしてもベンダーロックを避けたい、という方は Infisical の self-host がフィットします。シークレット管理の DSL（環境・フォルダ・ローテーション）を最初から持っているのは、規模が大きくなったときに効きます。
条件C：今すぐ何かを使い始めたい・予算を1円も使いたくない
この場合は sops + age という選択肢もあります。これは age という公開鍵暗号で .env 自体を暗号化し、暗号化されたファイルを git に commit する方式です。鍵だけを別管理（1Password に Secure Note として置く、物理メディアに保存する等）すれば、git だけで完結します。ただし鍵管理を間違えると復号不能になり、すべてを失うリスクがあります。「git の世界観で完結したい」「鍵管理に自信がある」という方向けです。
AIコーディング時代の安全な運用パターン
1Password と Infisical のどちらを選んでも、AIアシスタント時代に追加で実装すべき安全装置があります。これらは選んだツールに関係なく共通の「やるべきこと」です。
secret reference方式に統一する
プロジェクトに .env ではなく .env.tmpl のようなテンプレートを置き、値の代わりに op://... や infisical://... の参照だけを書きます。実値はランタイムに op run や infisical run で注入されるため、ディスクには参照しか存在しません。AIアシスタントが見るのも参照だけになり、実シークレットがコンテキストに載ることがなくなります。
.claudeignore と CLAUDE.md で .env* を明示的に拒否
Claude Code には対話に取り込むファイルを除外する仕組みがあります。プロジェクトのルートに .claudeignore を置き、.env* を含めることで、AIが意図せず読み込む経路を遮断できます。CLAUDE.md にも「.env 系のファイルは絶対に開かないこと」と明示的に書いておくと、二重の安全装置になります。
pre-commitにgitleaks
commit 前に gitleaks や detect-secrets を走らせ、シークレットらしい文字列を検出したら commit を止める仕組みを入れます。AIが万一テンプレートの参照ではなく実値を書き込んでしまっても、push 直前で止まります。
GitHub push protectionを有効化
GitHub の Settings から push protection を有効化します。個人アカウントでも無料で使えます。Vercel・Supabase・OpenAI・Anthropic などの主要キーは、push 時にパターンマッチでブロックされ、漏洩前に止められます。
Vercel本番はSensitive Environment Variablesに
Vercel ダッシュボードで環境変数を設定する際、Sensitive フラグを必ず付けます。これを付けると保存後はダッシュボードや API から実値を読み出せなくなり、漏洩時の被害が抑えられます。1Password / Infisical どちらの Integration を使う場合も、このフラグを忘れないことが重要です。
私の選択基準（執筆時点）
私自身は受託開発の現場でクライアント情報を扱うことが多く、シークレット管理の責任は単なる「自分のキーを守る」では済みません。クライアントの Supabase service role key、OpenAI 課金アカウントのキー、Google サービスアカウントの秘密鍵など、漏洩したときの影響範囲が私個人だけでない情報を多数扱っています。
その前提で、現時点では 1Password Individual から始めることを最有力候補にしています。理由は3つです。
- 個人のパスワード管理と開発シークレット管理を1つの vault に集約できる。「PCが壊れても新しい Mac で
op signinするだけで全プロジェクトの環境が復活する」という単純さは、運用負荷を最小にする - 受託開発では「すぐ動く」「クライアントへの説明が短く済む」が価値で、self-host の VPS 運用に時間を使う ROI は薄い
- 月500円程度の固定費は事業の経費として説明しやすい
将来的にチームが拡大したり、複数クライアントの環境を厳格に分離する必要が出てきたら、その段階で Infisical の self-host に移行するか、1Password Business + Service Account へ昇格するか、再評価すれば良いと考えています。最初から完璧な選択を狙うより、今の自分の規模に合った最小構成で動き始めて、必要になった時点で組み替えるほうが、結果的に学習コストも安く済みます。
大事なのは、AIアシスタントを業務で使う時点で「.env を裸で置く」運用は明確に卒業すべきタイミングに来ている、という認識を持つことです。.env 運用は Node.js エコシステムの中では完全に標準ですが、業務で AI アシスタントを介在させる以上、もう「個人だけが目にする」前提は成立しません。
シークレット管理ツールの選定そのものに正解はありません。しかし、ツール選定をしていない状態は、AIアシスタント時代では明確にリスクの高い状態です。今この記事を読んでいる方には、まず1ヶ月だけでも 1Password か Infisical のいずれかを試して、自分の運用に合うかを体感することをおすすめします。
関連記事として、Claude Code と MCP の API キー管理の総論、Claude Code のデータ取り扱いに関する解説も合わせて参考にしてください。
御社の業務に合わせたClaude Code導入支援
「AIツールを導入したが、現場で使われない」を終わらせる。
業務課題のヒアリングから設計、ハンズオン実践、運用定着まで一貫して支援します。