DevOpsはこの問題を何年も前にソフトウェアで解決しました。本番環境にコードを直接プッシュすることはありません。ローカルで開発し、ステージングでテストし、ゲートを通じて昇格し、レビュー付きでデプロイします。このパターンが機能するのは、ミスがユーザーに届く前に検出できるからです。
AIワークフローも同じ規律に値します。プロンプトの変更、モデルの交換、新しいツール統合——これらはコード変更がアプリケーションの動作に影響するのと同様に、本番出力品質に影響します。しかし、ほとんどのAIプラットフォームはすべての変更を本番変更として扱います。workflowを編集すると、即座にライブです。レビューなし。ステージングなし。セーフティネットなし。
JieGouの環境管理はdev-staging-prodパイプラインをAIワークフローに導入します。
3つの環境
すべてのworkflowは3つの環境にわたって独立して存在します。各環境には独自の設定、独自の承認要件、独自のデプロイ履歴があります。
| 環境 | 承認が必要 | 最小昇格ロール |
|---|---|---|
| Development | いいえ | Member |
| Staging | はい | Dept Lead |
| Production | はい | Admin |
Developmentはサンドボックスです。チームの誰でも承認なしでここにデプロイできます。新しいプロンプトのテスト、モデルの交換、ステップの追加——リスクなしで自由に反復できます。
Stagingは本番をミラーリングしますが、安全な境界内で。devからstagingへの昇格にはDept Leadのレビューと承認が必要です。ここで実際のワークロードを処理する前にworkflowが正しく動作することを検証します。
Productionはライブ環境です。stagingから本番への昇格にはAdminの承認が必要です。ここでの変更は実際のユーザー、実際のデータ、実際の出力に影響します。
環境ごとの独立した設定
環境は単なる権限ティアではありません。各環境が独自の運用設定を持ちます：
- MCPサーバーインスタンス — devではサンドボックスSlack、prodでは本番Slack。実際の副作用をトリガーせずにモックインテグレーションに対してテスト。
- デフォルトLLMプロバイダーとモデル — devでは高速反復のためにより安価で高速なモデルを使用。prodでは出力品質のために最高のモデルを使用。
- 承認ゲート — 各ティアでの組織のリスク許容度に一致する、環境ごとに異なるロール要件。
- デプロイWebhook — 環境ごとに異なるSlackチャネルやCI/CDシステムに通知。devのデプロイメントは
#eng-devにping、本番のデプロイメントは#ops-alertsにping。 - 環境変数 — ステップテンプレートに注入される非シークレットのキーバリューペア。stagingでは
API_BASE_URLをテストサーバーに、prodでは本番サーバーに設定。
この分離により、開発中のworkflowはサンドボックスAPIを呼び出し、安価なモデルを使用し、高価なツール呼び出しをスキップできます——一方、本番の同じworkflowは実際のインテグレーション、最高のモデル、完全な処理を使用します。
昇格パイプライン
昇格は厳密なシーケンスに従います。ショートカットはありません。
- 開発者が変更を加え、devにデプロイします。承認不要——何度でもデプロイできます。
- 開発者がdevからstagingへの昇格をリクエストします。システムはバージョン差分——現在のstagingバージョンと提案されたバージョンの間で何が変わったかの構造的比較——を計算します。
- Dept Leadが差分をレビューし、昇格を承認または却下します。
- 承認時にworkflowバージョンがstagingに自動デプロイされます。これはアトミックです——承認とデプロイが1ステップで行われます。昇格が承認されたがまだデプロイされていないウィンドウはありません。
- 同じプロセスがstagingからproductionへ繰り返され、Admin承認が必要です。
自己承認防止：昇格をリクエストした人は承認できません。これにより、本番に向かうすべての変更に対して2番目の目が強制されます。
バージョン差分エンジン
レビュアーは盲目的に承認しません。何が変わったかを正確に見ることができます。
差分エンジンはバージョン間でIDによってステップをマッチングし、15以上のプロパティを比較します：
- ステップタイプ、ラベル、モデル、プロバイダー
- Recipe割り当てとタスクの説明
- システムプロンプトの内容
- 条件ロジック（if/then/else設定）
- ループ設定（反復制限、ブレーク条件）
- 評価基準と品質閾値
- ステップの依存関係
- 条件とループ内のネストされたステップ
変更は人間が読める説明として表示されます：
- 「モデルが’claude-sonnet’から’claude-opus’に変更」
- 「品質閾値が0.7から0.9に変更」
- 「システムプロンプトが変更」
- 「ステップ’Summarize’が追加」
- 「ループの最大反復回数が3から5に変更」
差分はまた入出力スキーマの変更（フィールドの追加、削除、変更）と実行モードの変更（シーケンシャル vs. DAG）も検出します。レビュアーは完全な状況を確認できます：どのステップが変わったか、どのように変わったか、workflow全体にどのような構造的変化が起こったか。
デプロイ追跡
すべてのデプロイがレコードを作成します：
- ステータス —
active、superseded、またはrolled_back - デプロイヤー — デプロイをトリガーした人
- 承認情報 — 昇格を承認した人、日時、元のリクエスター
- 差分サマリー — 前回のデプロイと比較してこのデプロイで何が変わったか
- タイムスタンプ — デプロイがライブになった時刻
デプロイ履歴はworkflowごと、環境ごとにクエリ可能です。任意のworkflowの任意の環境でのフルライフサイクルを追跡できます：何がデプロイされたか、いつ、誰によって、そして毎回何が変わったか。
ロールバック
ワンクリック。即座に。
ロールバックは何も再実行しません。デプロイステータスを反転させます：現在のactiveデプロイがrolled_backにマークされ、前のsupersededデプロイが再びactiveになります。
これはリデプロイではなく、ステータス変更です。前のバージョンはすでに存在しています——再アクティベートするだけです。ビルドステップなし、昇格パイプラインなし、承認待ちなし。本番が壊れた場合、数秒で修正し、余裕を持って根本原因を調査できます。
監査証跡
すべての操作がログに記録されます：
- 環境設定への設定変更
- 任意の環境へのデプロイ
- 昇格リクエスト（リクエストした人、どの環境から、どの環境へ）
- 昇格の承認、却下、キャンセル
- ロールバック操作
各ログエントリには完全な変更前/変更後のスナップショットが含まれます。任意の時点での任意の環境の正確な状態を再構築できます。これは運用上の衛生管理だけでなく——規制産業の組織にとってのコンプライアンス要件です。
VPCエージェントとの統合
ハイブリッドデプロイメントを実行している組織では、VPC実行エージェントを特定の環境にスコープできます。
productionエージェントはproduction workflowの実行のみを処理します。devエージェントはdevelopment実行のみを処理します。これにより、インフラストラクチャレベルでのデータ分離が提供されます——開発の実験がproductionのコンピュートリソースに触れることはなく、productionデータが開発インフラストラクチャを流れることもありません。
環境固有のMCPサーバーと環境変数と組み合わせることで、統合レイヤーから実行レイヤーまでの完全な分離が作成されます。
提供状況
環境管理はEnterpriseプランでご利用いただけます。3環境の昇格パイプライン、バージョン差分、承認ゲート、デプロイ追跡、ロールバック、監査証跡が含まれています。エンタープライズ機能の詳細を見るか、無料トライアルを開始する。