volcengine-landing-zone

Volcengine Landing Zone

このスキルは、組織設計、アカウント構成、財務上の関係、アイデンティティ、監査、ネットワークの基盤など、Volcengine Landing Zone に関するコンサルティング、分析、セットアップ、管理のタスクを支援します。

明確さを保つため、このスキルはインテントルーターと、共通プレイブックおよびパス別ガイドブックで構成されています。

パスアンカー（実行前に一度だけ解決）

このスキル内の ./skills/volcengine-landing-zone/... や ./volcengine-landing-zone-workspace/... などの相対パスは、任意の現在の作業ディレクトリを基準とするものではありません。 まず、次の2つのアンカーを通じて解決し、その後の実行中はそのパスを再利用してください。

• SKILL_ROOT：このスキルの SKILL.md が置かれている、インストール先の絶対パスです。組み込みブループリント、HTML テンプレート、tos_activate.py、baseline.schema.json などの読み取り専用アセットはここにあります。./skills/volcengine-landing-zone/<x> のパスは ${SKILL_ROOT}/<x> に解決されます。
• WORKSPACE_ROOT：今回の実行で使用する、書き込み可能なランタイムルートです。ユーザーが別の書き込み可能な場所を明示的に指定しない限り、デフォルトは <current working directory>/volcengine-landing-zone-workspace/ です。実行用のコピー、出力ファイル、ベースラインのランタイム状態はすべてここに置かれます。./volcengine-landing-zone-workspace/<x> のパスは ${WORKSPACE_ROOT}/<x> に解決されます。
• ${WORKSPACE_ROOT}/confirmed-architecture.json：G1 で確認された、バージョン管理された完全なアーキテクチャです。デフォルトブランチとカスタムブランチの両方でこのファイルが作成され、ユーザーの設計意図を示す唯一の情報源となります。
• ${WORKSPACE_ROOT}/landing-zone-context.json：フィルタリング済みの、機密情報を含まない Phase 01 の引き継ぎ契約です。確認済みアーキテクチャと Phase 01 の実際の Terraform 出力から再構築できるキャッシュであり、別のリソース状態ではありません。

以降のすべての読み取りと書き込みでは、解決済みの絶対パスを使用してください。プロセスの cwd に依存しないでください。

ローカルファイルの表示

ユーザーにファイルを渡す必要がある場合は、現在のエージェントクライアントとランタイムでサポートされている方法の中から、ユーザーが実際のファイルにアクセスできる最適な方法を選んでください。生成またはコピーした成果物は ${WORKSPACE_ROOT} 以下に置き、読み取り専用のスキルアセットは変更しないでください。機密性の高いファイルの内容をチャットで公開したり、ファイルを表示することだけを目的にリスニングサービスを起動したりしないでください。必要な確認や一時停止には G1 と G4 が適用されます。

エントリールーティング（意図ルーター）

volcengine-landing-zone が有効になると、ユーザーの意図に合致するメインパスへ自動的にルーティングしなければなりません。最初に、ユーザーにパスの選択を求めないでください。複数のパスが同時に明確に該当する場合、または続行に必要な最低限の情報が不足している場合に限り、追加で質問してください。

トリガーの意味	ルーティング先
landing zone の構想／理念／ベストプラクティス／各フェーズの価値／実施順序／組織設計の提案／アカウント計画の提案／実施する価値があるか／実現方法	Consulting and Solution Design
企業の Landing Zone アーキテクチャの構築／初期化／再構築を明確に求めている、または Landing Zone に沿った組織、OU、コアアカウント、財務、アイデンティティ、監査、共有ネットワーク基盤の構築／調整	Initial Landing Zone Setup
アカウントの追加、アカウントの開設、アカウントの作成、baseline、baseline の適用、ベースラインの設定、baseline の作成	Account Creation and Baseline Setup
具体的なソリューション／ブループリントのデプロイ、この git リポジトリ／ローカルディレクトリ／組み込みパッケージのデプロイ、要件に沿った IaC の生成とデプロイ、ネットワーク／セキュリティ／データ／アプリケーションソリューションのデプロイ	Solution Deployment
失敗からの復旧、失敗時の再試行、失敗した実行の修復、前回の実行でのエラー	Failure Recovery

対応方針：

• ユーザーが、最初にディレクトリ構成、フェーズ番号、ブループリントの構造を把握する必要はありません。エージェントが目標の達成を直接引き受け、必要なリファレンスの確認と実行準備を行ってください。
• Create baseline と apply baseline は、最初の画面に独立したパスとして表示されませんが、ユーザーから直接求められた場合は、その依頼をそのまま受け入れ、パス選択に差し戻さないでください。
• 製品名やリソース名ではなく、求められている成果に基づいてルーティングしてください。VPC、ネットワーク、アイデンティティ、ロギングなどの名称だけで、Initial Landing Zone Setup に該当すると判断しないでください。
• Initial Landing Zone Setup に進むのは、企業の Landing Zone アーキテクチャまたは基盤の確立や再構成を明確に求められた場合に限ります。Landing Zone の各フェーズで使われるリソースを管理する場合でも、具体的にデプロイ可能なソリューションやパッケージであれば、Solution Deployment に進んでください。
• 依頼が両方のパスに該当する可能性がある場合、または意図する成果が不明確な場合は、ルーティングの前に確認の質問を1つしてください。ルートが確定するまでは、G1 を実行したり、Landing Zone セットアップの確認ファイルを提示したりしないでください。

ユーザー向けのコミュニケーション

• ビジネス向けの言葉を使い、現在のタスクに合わせて応答してください。特に指定がなければ、結論、重要な影響、次に有用なアクションを優先し、ユーザーから求められた場合やトラブルシューティングで必要な場合に限り、コマンド、パス、状態の詳細、オーケストレーションの仕組みを示してください。
• 確認済みの設計と、リアルタイムの読み取り専用状態から、安全なデフォルト値や確認可能な値を確定してください。確実に導出できず、現在のステップに必須の入力のみを尋ねてください。関連する質問はまとめ、ワークフローが項目ごとの聞き取りにならないようにしてください。
• ハードゲートで許可されている場合は、調査、事前チェック、ワークスペースの準備、計画の生成をバックグラウンドで行ってください。読み取り専用の準備について確認を求めないでください。クラウドへの書き込みの承認は G2 に従います。
• 固定のステータステンプレートではなく、自然な応答構成を使ってください。該当する場合は、完了した作業、阻害要因、重要なフォローアップ、次のアクションを明確に区別してください。

実際の実行前に必ず通過するハードゲート

これらのゲートは、ユーザーの意思決定とクラウドの状態を保護します。厳格に適用しつつ、周囲のやり取りは自然に進めてください。

G1. ソリューションの確認（初期ランディングゾーンのセットアップ）

• G1 は、ルーティングによって Initial Landing Zone Setup が明確に選択された後にのみ適用されます。スキルの有効化や組織／ネットワークリソースへの言及だけでは不十分です。その場合は ${SKILL_ROOT}/assets/html/landing-zone-solution-plan.html を提示し、推奨アーキテクチャを承認するか、変更を依頼するようユーザーに尋ねて、返答を待ちます。先に事前チェックやクラウド操作を開始してはいけません。
• ユーザーがそのまま承認した場合は recommended-v1 を選択します。不足している実行設定のみを解決し、設計全体を ${WORKSPACE_ROOT}/confirmed-architecture.json として生成して、contract.schema.json に照らして検証し、その正確な SHA-256 を記録します。
• 変更が依頼された場合は、ビジネス上の差分のみを recommended-v1 に適用し、アーキテクチャ全体の JSON と Markdown 表現を生成します。Markdown を提示し、実際の設計について承認を得ます。ユーザーが内部キーや Terraform オブジェクトを記述する必要はありません。
• 確認済みのアーキテクチャのバイト列に後から変更があった場合、G1 は無効となり、更新後の設計を再度表示して承認を得る必要があります。

G2. フェーズの確認（デプロイタスク／フェーズごと）

• クラウドへの書き込みを伴う各フェーズの前に、許可されたすべての読み取り専用の調査、照合、状態の検査、初期化、計画を完了します。解決済みの対象、対象と ID の対応付け方針、作成、更新、置換、削除、および Terraform 以外の書き込みによる重大な影響を提示し、明示的な承認を得ます。
• 承認により許可されるのは、そのフェーズで保存されたプランと、列挙された CLI／API の書き込みのみです。別のフェーズやタスクには適用されません。対象、入力、ブループリントのリビジョン、確認済みアーキテクチャのダイジェスト、書き込み対象、または保存済みプランに変更があった場合は、新たな承認が必要です。
• 承認後は、対象となるすべての書き込みをリソースごとの確認を挟まず、連続して実行します。01-organization から 05-network までは個別のフェーズです。アカウントの作成とベースラインの適用も個別のフェーズです。1 回のソリューションデプロイは 1 つのフェーズです。

G3. ワークスペースの分離

トリガー：Terraform の操作または書き込み操作。 アクション：実際の実行は ${WORKSPACE_ROOT}/ 内（つまり ./volcengine-landing-zone-workspace/ 内）でのみ行います。上記のパスアンカーを参照してください。 禁止事項：${SKILL_ROOT}/assets/blueprints/ から実行したり、そこに書き戻したりしてはいけません。組み込みのブループリントソースは常に読み取り専用です。 セルフチェック：組み込みのブループリントソースからではなく、${WORKSPACE_ROOT} 配下のワークスペースコピーから実行していますか？ そうでない場合は停止してください。

G4. ファイル確認のための一時停止

トリガー：初期パスワード、ログイン情報、概要レポートなど、ユーザーが確認する必要のあるローカルファイルをフェーズで生成した場合。 アクション：上記のローカルファイル表示ルールに従って実際のファイルを提示し、ユーザーに確認を依頼して、次の指示を待ちます。 禁止事項：後で複数のファイルをまとめて表示したいという理由で、一時停止を省略してはいけません。G2 はこの一時停止を免除しません。初期パスワード全体をチャットに転載してはいけません。また、ファイルの提示を、テキストでの書き直しに置き換えてはいけません。 セルフチェック：機密ファイルまたはユーザー確認用ファイルを生成した後、表示プロトコルに従って開くか提示し、その後停止しましたか？ そうでない場合は停止してください。

G5. コンサルティングは読み取り専用

トリガー：ユーザーの意図が、概念、順序、価値についての相談、設計、評価、または学習である場合。 アクション：説明と推奨事項のみを提供します。 禁止事項：便利だからという理由であっても、事前チェック、認証情報のセットアップ、Terraform の実行、またはいかなる書き込み操作も行ってはいけません。 セルフチェック：ユーザーは実際の実行を明確に依頼していますか？ そうでない場合は、説明のみを行い、操作してはいけません。

常に Volcengine の公式ランディングゾーンの方法論に基づいて設計および実装してください。

パス

コンサルティングとソリューション設計

• ユーザーが、実際に実行する前に、概念、各フェーズの価値、ロールアウトの順序、組織設計の提案、または実用的な導入方法を理解したい場合は、このパスを使用します。

ランディングゾーンの初期セットアップ

• guidebook.md の実行フローに進む前に、G1 を完了します。クラウドへの書き込みを伴う各フェーズには G2 を適用します。
• フェーズ固有の手順：
  • 01-organization.md
  • 02-finance.md
  • 03-identity.md
  • 04-log.md
  • 05-network.md

アカウントの作成とベースラインのセットアップ

• 全体の実行フローは guidebook.md に記載されています。
• アカウントの作成とベースラインの適用には、それぞれ個別の計画と G2 の確認があります。

ソリューションのデプロイ

• 全体の実行フローは guidebook.md に記載されています。
• ソリューションパッケージの検証とデプロイには、このパスを使用します。対象、ソースのリビジョン、実際の影響が確定した後に G2 を適用します。

障害からの復旧

• 復旧フローは failure-recovery.md に記載されています。
• landing-zone-setup、account-factory account create、account-factory baseline apply、solution-deployment の障害からの復旧には、このパスを使用します。

参考ファイル

ソフトなレイヤーとハードなレイヤー：ソリューションの確認、フェーズ単位の認可、ワークスペースの分離、ファイルの一時停止、読み取り専用のコンサルティングなど、実行に関するすべての必須要件は、上記の G1～G5 のみで定義されています。以下の参考ファイルにはパス固有の詳細のみを記載し、ルールを再掲するのではなく、ハードゲートの番号を参照してください。

• 機械的な事前チェック：preflight-checks.md
• ランディングゾーンのセットアップ：guidebook.md
• アカウントファクトリーのワークフロー：guidebook.md
• ソリューションデプロイのワークフロー：guidebook.md
• 障害からの復旧：failure-recovery.md
• ランディングゾーンのランタイム契約：contract.schema.json