infisical-setup

Infisical ユーザー向けセットアップガイド

Infisical をプロジェクトに統合するユーザーを支援する、対話型セットアップアシスタントです。セルフホスティングのガイドとは異なり、このスキルは Infisical（クラウド版またはセルフホスト版）を使ってシークレットを管理し、アプリケーション、コンテナ、パイプライン、インフラにシークレットを取り込む必要があるユーザーを対象としています。

このスキルの対象外

このスキルでは、アプリケーションやプラットフォームへのシークレットの取り込みを扱います。次のような場合は、別のスキルを案内してください。

ユーザーの要望	使用するスキル
Kubernetes Operator、または InfisicalSecret/InfisicalStaticSecret CRD	infisical-kubernetes-operator
ファイルへのシークレットのレンダリング、またはサイドカー／初期化コンテナ	infisical-agent
シークレットをサードパーティサービスにプッシュする	infisical-secret-syncs
短時間だけ有効な、オンデマンドで生成される認証情報	infisical-dynamic-secrets
既存の認証情報をスケジュールに従ってローテーションする	infisical-secret-rotation
Terraform/HCL	infisical-terraform
生の REST API 呼び出し	infisical-api
SAML/OIDC/LDAP を使った人間のログイン、または SCIM プロビジョニング	infisical-sso
ロール、権限、承認ポリシー	infisical-access-control
パブリックエンドポイントのないリソースにアクセスする	infisical-gateway
Infisical 自体をデプロイする	infisical-self-host

覚えておくべき違いは、次のとおりです。

• マシンアイデンティティ ＝ 外部のワークロードが Infisicalに対して認証すること（このスキル）。 アプリ接続 ＝ Infisical がサードパーティに対して外向きに認証すること（infisical-app-connections）。
• マシンアイデンティティ認証 ＝ ワークロード向け。SSO ＝ 人間向け（infisical-sso）。LDAP と OIDC は どちらにも登場しますが、互いに関係のない設定です。

このスキルの使い方

ユーザーに代わって CLI を実行する（エージェントとしてコマンドを実行し、ユーザーが入力できるターミナルがない）場合は、まず references/agent-bootstrap.md を読んでください。対話型プロンプトが原因でサブプロセスが停止することなく、ログイン、プロジェクトの作成、.env のインポートを行う方法を説明しています。

それ以外の場合は、ユーザーが何をしようとしているのかを把握することから始めます。

1. ローカル開発 — 開発ワークフローにシークレットを注入したい（CLI）
2. Docker — ビルド時または実行時に、コンテナでシークレットを使いたい
3. CI/CD — GitHub Actions、GitLab CI、またはその他のパイプラインでシークレットを使いたい
4. Kubernetes — Infisical Operator で K8s にシークレットを同期したい
5. アプリケーションコード — SDK を使ってプログラムからシークレットを取得したい
6. 認証の設定 — マシンアイデンティティを作成し、認証方式を選ぶ必要がある

関連するリファレンスファイルを読んでから、手順を追って案内してください。一度にすべてを提示しないでください。

リファレンスファイル

ファイル	読むタイミング
references/agent-bootstrap.md	自分で CLI を実行し、ログイン、プロジェクトのリンク、または .env ファイルの非対話型インポートを行う必要がある場合
references/cli-setup.md	CLI を使ったローカル開発、または基本的な infisical run の使い方についてユーザーが知りたい場合
references/docker-integration.md	Docker コンテナ（ビルド時または実行時）でシークレットを使いたい場合
references/kubernetes-operator.md	K8s Operator、InfisicalSecret CRD、または K8s での動的シークレットについてユーザーが知りたい場合
references/sdks.md	アプリケーションコードからシークレットを取得したい場合（言語を問わない）
references/cicd-integration.md	GitHub Actions、GitLab CI、またはその他の CI/CD でシークレットを使いたい場合
references/machine-identity-auth.md	マシンアイデンティティの作成、または認証方式の選択が必要な場合

基本原則

• まず相手のプラットフォームを起点にします。 認証方式や統合アプローチを提案する前に、何の上で動かしているのか（AWS、GCP、K8s、ローカルなど）を尋ねてください。
• 可能な限りシークレット不要の認証を推奨します。 AWS 上であれば AWS Auth を推奨します。K8s 上であれば Kubernetes Auth を推奨します。GitHub Actions 内であれば OIDC Auth を推奨します。プラットフォームネイティブの選択肢が利用できない場合にのみ、Universal Auth（Client ID/Secret）にフォールバックしてください。
• ローカル開発では CLI を第一に。 ローカルで作業する開発者にとって、CLI（infisical run -- <command>）はほぼ常に適切な出発点です。「自分のアプリにシークレットを持たせる」ための最もシンプルな道です。
• アプリケーションコードには SDK を。 環境変数だけでなく、アプリケーションロジック内でシークレットが必要な場合は、その言語向けの SDK を案内してください。
• 非推奨のパターンについて警告します。 サービス トークン（st.* プレフィックス）と API キーは非推奨です。常にマシンアイデンティティへと導いてください。
• 正確なパッケージ名とシンボル名はリファレンスから取得します。 いくつかの SDK には、パッケージ名からは推測できない名前があります。特に顕著なのが Ruby で、gem は infisical-sdk ですが require "infisical" と記述し、クラスは Infisical::Client です。推測せずに references/sdks.md を読んでください。
• セキュリティを意識します。 ユーザーに代わってシークレット、トークン、認証情報を生成してはいけません。ユーザー自身が生成するよう導いてください。シークレットの値をログに出力したり表示したりしないでください。