AX Code を入手 · 無料ドキュメント

このページは英語版ドキュメントの翻訳です。コマンド、識別子、例はそのままです。ランタイム 7.24.4 · SDK 2.6.7。 英語版

クラウド運用モード

ステータス: 現行 対象範囲: 現在の状態 最終確認: 2026-09-04 所有者: ax-code runtime

クラウド運用モードは、基盤を管理するための既製の姿勢です。対象はクラウドプロバイダー(AWS、GCP、Cloudflare、OVHcloud、DigitalOcean、RunPod)とネットワーク機器(VyOS、Juniper Junos)で、誤りが稼働中のシステムに影響し、git のロールバックでは状態を戻せません。組み込みの cloudops エージェント として出荷されます。システムプロンプトと権限の姿勢であり、規則を手で書く代わりに 1 回の選択で有効にします。

このモードが与えるもの

  • 読み取り優先のエージェント。 cloudops エージェントはすべてのタスクを棚卸しとドライランから始め、計画、差分、ロールバック手順が存在する前の変更をプロンプトが禁じます。
  • 実行前に尋ねるシェル。 bash は ask に設定されるため、すべてのシェルコマンドが確認されます。クラウドやネットワークの変更動詞(aws/gcloud/az/doctl の削除系、kubectl delete/apply --prune、計画ファイルのない terraform apply、commit-confirm のない ssh のリモートコミット、コントロールプレーン API に対する curl の変更)は bash_destructive に分類され、迂回できない別の対話的関門を持ちます。
  • 第一級の運用ツール。 ops_plan、ops_diff、ops_verify、ops_journal は事前に許可されます。ops_approve と ops_apply は対話的な経路のままです(下記)。

ワークフロー: 計画 → 差分 → 承認 → 適用 → 検証 → 日誌

  1. ops_plan — OperationPlan を開きます。対象(プロバイダー、アカウント、リージョン、または機器)、意図、正確な適用コマンドとコマンド文脈、効果、可逆性(reversible | hard | irreversible)、影響範囲(low | med | high)を持つ手順です。正規の計画ハッシュを生みます。
  2. ops_diff — 機械が検査できる成果物(terraform plan -out、show | compare、CLI のドライラン出力)を作り、レビューし、添付します。差分がなければ承認はありません。
  3. ops_approve — 人間がハッシュで固定された計画を承認します。この関門は対話のみです。ワイルドカード規則も自律モードも事前承認できず、永続的な「常に許可」の付与は提供されません。
  4. ops_apply — 承認トークンを使って、承認された計画の変更を実行します。これが唯一の認められた変更経路です。何かが走る前にトークンは引き換わります。
  5. ops_verify — 計画の宣言的な読み取り専用アサーションを実行し、合格と失敗の証拠を記録します。
  6. ops_journal — 追記専用でプロジェクトに限定された運用日誌を、プロジェクト、計画、または状態で照会します。

モードを有効にする

TUI では、エージェントピッカーから クラウド運用 を選ぶか、範囲を限ったタスクのために cloudops を @ で言及します。プロジェクトの既定にするには、ax-code.json に追加します。

{
  "default_agent": "cloudops",
  "isolation": {
    "mode": "workspace-write",
    "network": true
  }
}

workspace-write はファイル変更をワークスペースに閉じ込めます。network: true は webfetch、websearch、プロバイダー CLI を到達可能なままにします(サンドボックスモードではネットワークはそれ以外オフです。サンドボックスモード を参照)。どちらもセッションの隔離設定であり、エージェントとは独立なので、エージェントプリセットの中ではなくここで設定します。

プロジェクトごとに agent.cloudops.permission の下で姿勢を厳しくしたり広げたりできます。たとえば特定のツールを拒否します。リポジトリにコミットされた設定が追加できるのは 拒否 規則だけです。ask を allow へ緩めるのは、信頼されたユーザーまたは管理された設定からでなければならず、リポジトリからであってはなりません。エージェントを完全に取り除くには "agent": { "cloudops": { "disable": true } } を設定します。

具体例

VyOS ルーターへファイアウォール変更を適用します。

  1. あなたが尋ねます。「エッジファイアウォールで 10.0.0.0/8 からの tcp/8443 を許可して。」
  2. エージェントは vyos-firewall スキルを読み込み、SSH 経由で現在の設定を捕捉し(show configuration commands を日付付きファイルへ保存)、ops_plan で計画を開きます。手順は 1 つ、効果は add firewall rule、可逆性は reversible(規則の削除が状態を戻す)、影響範囲は med です。
  3. 設定モードで変更をステージし、ops_diff で機器の差分を添付します。
  4. ops_approve が計画ハッシュと正確なステージ済み変更を示します。承認すると、10 分のトークンが発行されます。
  5. ops_apply がトークンを引き換え、commit-confirm の手順を実行します。自動ロールバックのタイマーは、検証まで武装したままです。
  6. ops_verify が到達性と、規則が意図したトラフィックに一致することを確認します。承認と結果の両方が日誌に残るため、あとから ops_journal で照会すると変更全体を再構成できます。

手順 5 で適用が失敗した場合、トークンは消えています。再試行の前に手順 4 が再び走ります。

承認トークンの意味

  • 1 回限り — ops_apply の開始時に原子的に引き換わります。消費済み、不明、または期限切れのトークンは、何も実行せずに失敗します。
  • TTL に束縛 — 既定は 10 分、最大は 60 分です。期限は消費時に遅延検査されます。背景の掃除役はありません。
  • 計画に束縛 — トークンは計画の正規 sha256 ハッシュに対して発行されます。それには正確な適用コマンド、任意のスナップショットコマンド、作業ディレクトリが含まれます。引数のずれと、別の計画に提示されたトークンは、消費前に拒否されます。これにより再生、計画をまたぐ混同、コマンドのすり替えを防ぎます。
  • 1 回だけ開示 — 生のトークンは ops_approve の結果にちょうど 1 回現れ、永続化されません(保存されるのはその sha256 だけです)。
  • 返却なし — 失敗または時間切れの適用はトークンを返しません。再試行には ops_approve を通じた再承認が必要です。

セキュリティモデル

  • 場当たりの変更の関門は引き続き bash_destructive です。 運用ワークフローが覆うのは計画された変更です。一回限りの破壊的コマンドは引き続き破壊的分類器とその対話的関門に当たり、どの権限規則もそれらを自動承認できません。
  • ops_approve は対話のみ で、isolation_escalation や bash_destructive と同様です。ワイルドカード許可の規則集の下でも、ヘッドレスの自律モードでも、常に尋ねます。
  • 日誌はエージェントから見て追記専用 で、プロジェクトに限定されます。セッションより長生きし、セッション削除時に連鎖削除されません。
  • スキルパックがプロバイダーの手順書を持ちます。 cloud-ops-aws、cloud-ops-gcp、cloud-ops-cloudflare、cloud-ops-digitalocean、cloud-ops-runpod、vyos-firewall、junos-firewall が、読み取り優先のチェックリスト、変更前の計画手順、ロールバックの型を保持します。エージェントは面を操作する前に、対応するパックを読み込みます。OVHcloud とその他のプロバイダーは、設定された MCP サーバーとその文書を通じて扱われ、即興の CLI 連鎖ではありません。
  • 認証情報は記録に届きません。 永続化された bash 入力の中のインライン認証情報の代入は、イベントログに届く前に伏字になります。

厳格モード

既定では、破壊的に分類された bash コマンド(bash_destructive ファミリー: クラウドやネットワークの変更動詞、rm -rf、git push --force、および分類器一覧の残り)は、迂回できない対話的な確認を受けます。利用者は一回限りのコマンドを承認でき、それは実行されます。厳格モードはその選択肢を取り除きます。

厳格モードが有効なとき、破壊的に分類された bash コマンドは、確認の前に 直ちに拒否 されます。拒否メッセージは、分類されたコマンドを理由とともに一覧し、モデルを認められたワークフローへ導きます。ops_plan → ops_diff → ops_approve(1 回限りの承認トークンを発行)→ ops_apply です。場当たりの破壊的シェル変更は、まったく不可能になります。すべての変更は、日誌に裏打ちされた経路を通じて、計画、差分、承認、適用されなければなりません。

信頼された設定で有効にします(ユーザー設定ディレクトリの ax-code.json、管理された設定、または利用者が明示的に信頼したプロジェクト設定)。

{
  "ops": {
    "strict": true
  }
}

注:

  • 確認との相互作用: 厳格モードは bash_destructive の確認を、硬い拒否に 置き換えます。フラグがオフ(既定)のとき、挙動は上に述べたとおりで、対話的関門は残ります。
  • 範囲: フラグはグローバル設定であり、エージェントごとではありません。サブエージェントを含め、セッション内のすべての bash 呼び出しに適用されます。cloudops エージェントは自らそれを有効にできません。エージェントが持つのは権限とプロンプトであり、設定ではありません。
  • 信頼の範囲: 信頼されない、リポジトリにコミットされたプロジェクト設定は、厳格モードを有効にできません。マシンごとにオプトインする(AX_CODE_TRUST_PROJECT_CONFIG=1)か、信頼されたユーザーまたは管理された設定に置いてください。
  • ops_apply は影響を受けません。 認められた変更経路は、ツール内部に計画に束縛された独自のトークン関門を持ち、このフラグを参照しません。

信頼できる情報源

  • packages/ax-code/src/agent/agent.ts — cloudops エージェントの定義と権限のマージ
  • packages/ax-code/src/agent/prompt/cloudops.txt — エージェントのシステムプロンプト
  • packages/ax-code/src/tool/ops_*.ts — 6 つの運用ツールとその説明
  • packages/ax-code/src/permission/index.ts — INTERACTIVE_ONLY(ops_approve、bash_destructive、isolation_escalation)
  • サンドボックスモード — 隔離モード、ネットワーク制御、優先順位