antrieb

Antrieb MCP サーバー

LLM が生成するネットワークやインフラ向けの、すぐに使える使い捨てクラスター。

LLM が VyOS の NAT 設定、OpenWrt のファイアウォールルール一式、あるいは CentOS クラスターを強化する bash スクリプトを書いたとします。それが環境に影響を与える前に、どこで実行しますか？ Antrieb は、LLM が生成したものを試せるよう、実際の VM と実際のネットワークを備えた使い捨てのマルチノードクラスターを LLM に提供します。壊して、すぐに再プロビジョニングして、もう一度試せます。後片付けは不要です。

LLM が生成したコードの本番環境での実行先と同じ OS やアプライアンスを使えます。CentOS Stream、Ubuntu、Debian、Alma、Alpine、VyOS、OPNsense、SONiC、OpenWrt に対応しています。NIC ごとに割り当て可能なマルチネットワークトポロジーを構築できます。コンテナーでも、マイクロ VM でも、正体の分からない Linux でもありません。実際のサーバーフリートで稼働するものと同じカーネルやパッケージです。

root アクセス、プライベートネットワーク、ノード間のパスワードなし SSH を利用できます。クラスターは 10 分間有効です。毎回まっさらな状態から始められます。LLM が間違えることのコストを変える、即座に使えるクラスターです。

クイックスタート

Antrieb はリモート MCP サーバーです。インストールは不要です。設定に追加すれば、すぐにプロビジョニングを開始できます。

Claude Web / ChatGPT

Web ベースの AI クライアントでは、Antrieb をカスタムコネクターとして追加します。

claude.ai では、Settings → Connectors に移動し、Add custom connector をクリックします。次を入力します。

• Name: Antrieb
• URL: https://antrieb.sh/mcp

Add をクリックし、続けて Connect をクリックしてサインインします。チャットに戻ったら、次のように試してみてください。

3 ノードの Kubernetes クラスターを作成してください。node1 はコントロールプレーンとワーカーの両方として実行し、node2 と node3 はワーカー専用にしてください。3 つの Pod を持つ nginx をインストールし、Pod のアンチアフィニティを設定してください。

手順の動画：https://youtu.be/8nts8ol-yeA

MCP クライアント（Claude Desktop、Claude Code、Codex、カスタムクライアント）

antrieb.sh/dash で無料の API キーを取得し、MCP クライアントの設定に次を追加します（例：Claude Desktop の場合は .mcp.json）。

Claude Code

現在のフォルダーに .mcp.json という名前のファイルを作成し、次の JSON を記述します。Claude Code が自動的に検出します。

{
  "mcpServers": {
    "antrieb": {
      "type": "http",
      "url": "https://antrieb.sh/mcp",
      "headers": {
        "Authorization": "Bearer ant_YOUR_API_KEY"
      }
    }
  }
}

Codex

次の TOML の内容を ./.codex/config.toml に記述します。その後、Codex を起動する前に API キーを使って ANTRIEB_TOKEN 環境変数を設定します。

 [mcp_servers.antrieb]
  url = "https://antrieb.sh/mcp"
  bearer_token_env_var = "ANTRIEB_TOKEN"

ローカルへのインストールも、依存関係も、Docker も不要です。

仕組み

LLM は 5 つのツールを通じて実際の VM を制御します。

1. provision  →  Spin up a cluster (sub-second per VM, declare custom networks and NICs)
2. exec       →  Run commands on any node (cluster-scoped env vars auto-injected)
3. save       →  Snapshot a node as an image, or save a runbook
4. search     →  Discover images, runbooks, or active clusters
5. delete     →  Destroy a cluster, or decommission a saved artifact

LLM がワークフロー全体を実行します。クラスターをプロビジョニングし、コマンドを 1 つずつ実行してソフトウェアをインストールし、各手順を検証し、動作するまで繰り返します。Antrieb はインフラを提供し、LLM は知能を提供します。

ワークフローの例

You: provision 3 ubuntu nodes and install nginx on all nodes


LLM: provision(cluster: ["ubuntu24.04 x3"])
→ { session_id: "abc12", nodes: ["node1", "node2", "node3"], provision_time_ms: 720 }

LLM: exec(session_id: "abc12", node: "node1", command: "apt-get update && apt-get install -y nginx")
→ { exit_code: 0, stdout: "..." }

LLM: exec(session_id: "abc12", node: "node1", command: "systemctl start nginx && curl -s localhost")
→ { exit_code: 0, stdout: "<html>Welcome to nginx...</html>" }

LLM: save(type: "image", session_id: "abc12", node: "node1", name: "my-nginx", commands: [...])
→ { ani: "antrieb:my-nginx:v1" }

LLM: delete(type: "cluster", name: "abc12")
→ { success: true }

利用可能なイメージ

ベースイメージ

ANI	説明
ubuntu24.04	Ubuntu 24.04 LTS：apt、bash、Python 3、curl、wget、jq
almalinux9	AlmaLinux 9（RHEL 互換）：dnf、bash、Python 3
centos-stream10	CentOS Stream 10：dnf、bash、Python 3
debian13	Debian 13：apt、bash、Python 3、curl、wget、jq
alpine	Alpine Linux 3.23：apk、軽量、musl libc
sonic	SONiC：データセンタースイッチ向けのオープンソースネットワーク OS
vyos	VyOS：統合 CLI を備えた Linux ベースのルーター／ファイアウォール
openwrt	OpenWrt 25.12：UCI 設定を備えた Linux ベースのファームウェア
opnsense	OPNsense：Web UI を備えた FreeBSD ベースのファイアウォール／ルーター

スタックイメージ

スタックイメージは、ベースイメージに追加パッケージを加えて作成したカスタムイメージです。

ANI	説明
terraform-aws	Terraform と実際の AWS（無料利用枠、Antrieb の認証情報、Vault を介した STS）
ansible-controller	コレクションを含む Ansible コントロールノード
podman	Podman、Buildah、Skopeo（rootless、Docker API 互換）
mongodb	データベースのプロビジョニングと統合テスト用の MongoDB サーバーイメージ
postgresql	SQL データベーステスト用の PostgreSQL サーバーイメージ
vault	シークレットのワークフローと Terraform ベースの認証情報用の HashiCorp Vault イメージ
mariadb	MySQL 互換データベーステスト用の MariaDB サーバーイメージ
nginx	Web サーバーとリバースプロキシのシナリオ用の NGINX イメージ
helm-k3s	軽量な Kubernetes シナリオ用の Helm を備えた K3s
asterisk-pbx	SIP とテレフォニーのシナリオ用の Asterisk PBX イメージ

search を使うと、すべての利用可能なイメージを詳細な説明とともに検索できます。または、ディストリビューション名を指定するだけで、Antrieb が適切なイメージを選択します。

クラスターネットワーク

ネットワークは後回しにするものではなく、provision の主要な入力項目です。すべてのクラスターは、（自分が所有するクラスターも含め）互いに L2 分離されており、ホスト名解決、自身のノード間でのパスワードなし SSH、すべての exec 呼び出しへのクラスター単位の環境変数の自動注入に対応しています。実行ごとに異なるのは、provision のオプションパラメーター networks と nics によるノードの接続方法と制御方法です。

2 つのモードがあります。デフォルトネットワーク（フラットな単一サブネットで、インターネットに接続可能）と、宣言型ネットワーク（複数のサブネットと NIC を備えた、標準機能としてのトポロジー）です。

すべてのクラスター（両方のモード）

• ホスト名解決： すべてのノードの /etc/hosts に node1、node2、node3 が登録されます。
• パスワードなし SSH： クラスターごとの ed25519 鍵ペアがすべてのノードに配布されます。ssh node2 hostname をそのまま実行できます。
• L2 分離： CIDR の重複やアカウントにかかわらず、異なるクラスターのノード同士は到達できません。
• すべての exec に環境変数を設定： NODE_NAME、NODE_INDEX、NODE_IP、CLUSTER_HOSTS（複数行の IP NAME 形式で、/etc/hosts にそのまま追加できます）、CLUSTER_SSH_PUBKEY、CLUSTER_SSH_PRIVKEY。

LLM: exec(node: "node1", command: "ssh node2 hostname")
→ { stdout: "node2" }

デフォルトネットワーク（networks／nics を省略した場合）

LLM: provision(cluster: ["ubuntu24.04 x3"])

以下が利用できます。

• 自動割り当てされる /24 ネットワークが 1 つ（名前は default）、各ノードに NIC が 1 つ、IP は DHCP により割り当てられます。
• キュレーションされたポートの許可リスト（HTTP、HTTPS、DNS、SSH、パッケージマネージャー）を介したインターネットへの送信通信。任意の送信通信はブロックされます。
• ルーター VM、ファイアウォールゾーン、設定が必要なトポロジーはありません。ノード同士、および外部との通信が可能です。

テスト対象がネットワークではない場合は、こちらをお使いください。アプリケーションレベルの作業、ディストリビューション固有の設定、Ansible プレイブック、CI パイプライン、Ubuntu 3 台での Kubernetes などが該当します。

宣言型ネットワーク（マルチネットワーク、マルチNIC）

トポロジーそのものがテスト対象となる場合は、networks と nics を指定します。対象には、ルーター、ファイアウォール、DMZ、分離されたバックエンドサブネット、デュアルホームノード、BGP メッシュなどがあります。

LLM: provision(
  cluster: ["vyos", "ubuntu24.04", "ubuntu24.04"],
  networks: [
    { name: "wan", egress: true },
    { name: "lan", cidr: "10.10.1.0/24", egress: false }
  ],
  nics: {
    node1: [{ net: "wan" }, { net: "lan" }],   // vyos: dual-homed router
    node2: [{ net: "lan" }],                    // ubuntu backend
    node3: [{ net: "lan" }]                     // ubuntu backend
  }
)

仕様：

• 宣言された各ネットワークは、それぞれ独立した L2 セグメントであり、専用の DHCP サーバーと /24 を持ちます。省略した CIDR は自動割り当てされます。サポートされるのは /24 のみです。
• egress: true — デフォルトのポート許可リストに従ってインターネットに接続できます。egress: false — トラフィックはネットワーク内にとどまり、外部へのデフォルトルートはありません。
• dhcp: true（デフォルト）— プラットフォームが IP アドレスを割り当てます。dhcp: false — IP アドレスを自分で割り当てます（ルーター VM がアドレス管理を担う場合や、正確な /31 リンクが必要な場合に使用します）。
• NIC の順序が重要です。 nics.<node> の各エントリーは、記載された順に eth0、eth1、... になります。
• DHCP が有効なすべてのネットワークでは .1 が予約済みで、プラットフォームのブリッジゲートウェイに割り当てられます。ルーター VM には .254 を割り当てるか、DHCP クライアントを使用してください。VM に .1 を割り当てると、ARP がフリップフロップします。

これにより、本格的なネットワーク作業が可能になります。WAN/LAN ゾーンを備えた VyOS / OPNsense ファイアウォール、L2 スイッチまたは L3 ルーターとしての SONiC、fw3 のゾーンモデルを使用した OpenWrt、リバースプロキシ LAN 配下の nginx、/31 トランジットリンク経由の BGP ピアリング、ヘアピン NAT、DNAT ポートフォワーディングなどです。各パターンの詳しい手順は、@antrieb/* ランブックライブラリにあります。

再利用するトポロジーはランブックに記録してください。ネットワークは provision の実行時にインラインで宣言します。同じトポロジーを複数のシナリオで使う場合は、トポロジー、コマンド、検証手順をまとめてランブックとして保存してください。

ネットワークラボの例

デフォルトの antrieb/* ランブックライブラリには、次のような検証済みのシナリオが含まれています。

• VyOS： ゾーンベースの DMZ ファイアウォール、DNAT ポートフォワーディング、DHCP/DNS フォワーディング、DHCP リレー、デュアル WAN フェイルオーバー、ポリシーベースルーティング、eBGP、OSPF、VRRP、WireGuard、IPsec、VLAN トランキング、QoS シェーピング。
• SONiC： L2 ブリッジング、L3 ルーティング、VLAN セグメンテーション、ポリシーを用いた VLAN 間ルーティング、FRR を使用した BGP、OSPF、DHCP リレー、LAG、SPAN ミラーリング、VXLAN L2 ストレッチ。
• OPNsense： DNAT ポートフォワーディング、3 ゾーン DMZ、WireGuard ロードウォリアー、HAProxy による HTTPS 負荷分散。
• OpenWrt： ホームルーターの NAT、ゲストゾーンの分離、ポートフォワーディング、dnsmasq の静的 DHCP とローカル DNS の上書き。
• サービスのトポロジー： nginx リバースプロキシ、Ansible で管理する nginx バックエンドと HAProxy による負荷分散およびフェイルオーバー訓練。

ランブックは実行可能な証明として作成されています。トポロジー、コマンド、想定されるパケットの動作、そして tcpdump、ルートテーブル、conntrack、BGP/OSPF の状態、DHCP トレース、VPN ハンドシェイク、フェイルオーバーテストなどのツールを使った検証手順が含まれています。

ランブック

ランブックは、ブログ記事にするほどではない小さな注意点も含め、複雑なマルチノードシナリオを記録しておくためのものです。LLM が実行できる構造を持つ Markdown ドキュメントです。

• ## Topology required — 適用対象となるクラスター構成（イメージ、ネットワーク、NIC）
• ## Variables — 呼び出し側が適用時に置き換える <LAN_SUBNET> などのプレースホルダー
• ## Steps — 番号付きの手順。説明文では 理由 を示し、フェンス付きのシェルブロックには実行するコマンドを記載します。各ブロックには対象ノードを注記します。
• ## Verify — 成功を確認する方法

次のようにして保存します：save(type: "runbook", session_id: "...", name: "...", body: "...markdown...")。session_id は、そのランブックの実行を証明する exec 履歴を持つセッションを指している必要があります。本文は search(type: "runbook", fq_name: "namespace/name") で取得します。

ランブックはイメージを補完します。イメージにはインストール済みの状態（パッケージ、qcow2 に組み込まれた設定）が記録されます。ランブックにはワークフロー（動作するシステムを構築するための、順序付けられたマルチノード操作）が記録されます。VM 間の連携を単一のイメージで表現することはできないため、複数のノードを使うものにはランブックを使用してください。

保存した内容はすべて組織の名前空間に置かれます。antrieb/* 名前空間には、読み取り専用のデフォルト設定があります。

カスタムイメージ

設定済みのノードを再利用可能なイメージとして保存します。

1. ベースイメージをプロビジョニングします
2. exec を使ってソフトウェアをインストールし、設定します
3. 成功したコマンドのリストを指定して save(type: "image", ...) を呼び出します
4. Antrieb が build-image.sh、startup.sh、説明を生成します
5. イメージは以降の provision 呼び出しですぐに利用できます

今すぐ試す

MCP クライアントは必要ありません。API キーを使って curl を実行してください。

# 1. Provision a single Ubuntu node
curl -s -X POST https://antrieb.sh/mcp \
  -H "Authorization: Bearer ant_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"provision","arguments":{"cluster":["ubuntu24.04"]}}}'

→ { "session_id": "abc12...", "nodes": ["node1"], "provision_time_ms": 680 }

# 2. Run a command on the node
curl -s -X POST https://antrieb.sh/mcp \
  -H "Authorization: Bearer ant_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"exec","arguments":{"session_id":"abc12...","node":"node1","command":"cat /etc/os-release | head -3"}}}'

→ { "node": "node1", "exit_code": 0, "stdout": "PRETTY_NAME=\"Ubuntu 24.04 LTS\"\nNAME=\"Ubuntu\"\nVERSION_ID=\"24.04\"" }

# 3. Tear it down
curl -s -X POST https://antrieb.sh/mcp \
  -H "Authorization: Bearer ant_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":3,"method":"tools/call","params":{"name":"delete","arguments":{"type":"cluster","name":"abc12..."}}}'

ant_YOUR_KEY を API キーに、abc12... を手順 1 の session_id に置き換えてください。

FAQ

Antrieb を選ぶ理由は何ですか？

AI は、クラウド、オンプレミス、レガシーシステム、セキュリティ、ネットワーク、エッジなど、運用のあらゆる層に浸透しつつあります。クラウドサーバーの設定ミスは大きな問題になります。現場にある 1 万台のエッジデバイスの設定を誤れば、壊滅的な事態になりかねません。

Antrieb は LLM と運用の間にある検証レイヤーです。AI が生成したインフラコードを環境に適用する前に、運用上の障害が明らかになる程度に対象アーキテクチャに近い、実際の破棄可能な環境で実証する必要があります。同じ OS、同じパッケージ、同じ動作です。コンテナーでも、近似環境でもありません。Antrieb は、AI が生成した運用上の変更を監査可能な形で実証する場です。

クラスターが 10 分間なのはなぜですか？

10 分の TTL は、主にコンピューティングの制限を目的としたものではありません。クラスターはすぐに再作成できます。TTL を設けているのは、検証の再現性を確保し、LLM が意図せず状態を蓄積するのを防ぐためです。

ラボではなく、学びを残しましょう。

• 状態のドリフト： LLM は、以前の試行で残ったファイル、不完全な修正、隠れた変更に頼ることができません。各ソリューションは、何もない状態から動作する必要があります。
• 再現性： 新しいクラスターで再現できないソリューションは、成功とはみなされません。
• 認知のドリフト： クラスターが長期間稼働すると、LLM は最初の計画に固執しやすくなります。環境が残っていて途中まで進んだ状態があるため、壊れたアプローチを修正し続ける場合があります。厳格な TTL によって、強制的にチェックポイントが設けられます。LLM は学んだことを要約し、意図せず残った状態を破棄し、より明確なコマンド手順を選び、最初から結果を再現しなければなりません。
• 不正利用の防止： TTL は、スキャン、ボット活動、マイニング、ホスティングなど、長時間にわたる不正利用も防ぎます。

クラスターが不変なのはなぜですか？

クラスターのアーキテクチャはプロビジョニング時に固定されます。イメージ、ノード数、ネットワーク、NIC の割り当てが対象です。LLM が別のトポロジーを必要とする場合は、より適切な設計で新しいクラスターをプロビジョニングしてください。

これにより、アーキテクチャのドリフトを防ぎます。不変性がなければ、LLM はノード、ネットワーク、ルート、例外を追加し続け、ラボが検証対象のシステムと一致しなくなる可能性があります。結果として「動作」するかもしれませんが、それは環境がミスに合わせて変化したからにすぎません。

不変性により、トポロジーは明示的な仮説になります。

1. アーキテクチャを選択します。
2. プロビジョニングします。
3. 実装をテストします。
4. アーキテクチャが誤っていた場合は破棄し、より適切な構成でプロビジョニングし直します。

これにより、検証対象が理解しやすく、再現可能になり、ランブックとして保存する価値も保たれます。

無料ですか？

はい。antrieb.sh/dash で無料の API キーを取得できます。

各 VM のリソース仕様はどのようになっていますか？

ほとんどの Linux ベースイメージとスタックイメージには、4 vCPU、2 GB の RAM、20 GB のディスクが割り当てられます。ネットワークアプライアンスや小型のエッジイメージでは仕様が異なる場合があります。search(type: "image") を実行すると、現在の仕様とイメージの詳細な説明が返されます。

1 つのクラスターに何個のノードを配置できますか？

1 つのクラスターにつき最大 4 ノードです。専用のコントローラーノードが必要なトポロジー（たとえば、Ansible の制御ノードで複数のノードを管理する場合）では、ノードを 1 つ追加でき、最大 5 ノードになります。

同時に実行できるクラスターはいくつですか？

アカウントごとに同時実行できるクラスターは最大 2 つです。

ノードはインターネットにアクセスできますか？ はい、デフォルトではアクセスできます。デフォルトネットワーク上の各ノードはインターネットに直接アクセスできますが、セキュリティ上の理由から、許可されているポートは限られています。パッケージマネージャー、curl、pip、npm は、いずれも通常どおり動作します。egress: false を指定してネットワークを明示的に宣言した場合、そのネットワーク上のノードはインターネットから完全に隔離されます。

クラスターはどのくらい存続しますか？

認証済みクラスターの有効期限（TTL）は、最長で10分です。その後は、コンピューティングリソース、ネットワークなど、すべてが完全に破棄されます。TTLを延長することはできません。以前のセッションと同じIPアドレスが割り当てられた場合でも、VMは完全に新しいものです。

チャットセッションが終了すると、クラスターはどうなりますか？

クラスターは、削除するかTTLが切れるまで存続します。その後、IPアドレスは今後のVMに再利用される場合があります。コマンドは別途ログに記録され、ダッシュボードから引き続きアクセスできます。

VMは本当にエフェメラルですか？使用済みのノードが割り当てられることはありませんか？

はい、完全にエフェメラルです。セッションVMがセッション間で再利用されることはありません。使用が終わるかTTLが切れると、VMは破棄されます。プロビジョニングするすべてのノードは完全に新しいものです。

VMで実行したコマンドを見られるのは誰ですか？

あなただけです。他の人がコマンド履歴にアクセスすることはできません。

LLMがコマンドログに機密データを誤って含めてしまうことはありますか？

コマンドには、シークレットや認証情報などの機密データを含めないでください。コマンドログはダッシュボードからアクセスできるため、取り扱いにはご注意ください。

VMは他のユーザーから隔離されていますか？

はい。クラスター内のノード同士は通信できますが、別のクラスターに属するノードには、たとえご自身が所有する別のクラスターであってもアクセスできません。ご自身で確認するには、LLMに「ノードが1つのクラスターを2つプロビジョニングし、それぞれのノードのIPアドレスを取得してから、各ノードにSSH接続してもう一方のノードにpingを試してください」と指示してください。pingが失敗することを確認できます。

LLM経由だけでなく、自分でノードにSSH接続できますか？

いいえ。すべての操作はLLMを通じて行います。実行したいことを伝えれば、LLMが代わりに実行します。すべて会話形式で操作できます。

どのようなデータがログに記録されますか？コマンドは保存されますか？

はい。すべてのコマンドがログに記録され、antrieb.sh/dashのダッシュボードから確認できます。

どのクライアントで利用できますか？

Claude.ai、ChatGPT Web、Claude Desktop、Cursor、Windsurf、Claude Codeで利用できます。HTTP経由のリモートMCPサーバーに対応しているクライアントであれば、利用できるはずです。

Claude以外のモデルでも利用できますか？

はい。AntriebはMCPサーバーにすぎず、インテリジェンスはすべてLLMが担います。MCPクライアントが対応しているモデルであれば、どれでも利用できます。

保存したイメージを利用できるようになるまで、どのくらいかかりますか？

目標は2分です。最長で5分かかります。ランブックはqcow2イメージではなくメタデータのため、すぐに保存されます。

カスタムイメージやランブックは非公開ですか？

はい。デフォルトでは非公開です。チーム内で共有するには、antrieb.sh/dashでプロフィールを開き、組織のネームスペースを設定してください。それ以降、保存したものはすべて組織のメンバーのみがアクセスできます。

Antriebはどのように不正利用を防いでいますか？

• コマンドのログ記録とAIによる監視。 すべてのノードで実行されたすべてのコマンドをログに記録します。AIを使って、暗号資産のマイニング、DDoS、スパム、不正なスキャンなどの不正利用を積極的に検知し、防止します。
• クラスターの上限。 ユーザーあたり同時に実行できるクラスターは最大2つです。各クラスターには最大4つのノードを配置できます。
• クラスター間の隔離。 クラスター内のノード同士は通信できます。アカウントが同じでも、クラスターをまたいだノード同士は通信できません。
• 送信ポートの許可リスト。 デフォルトネットワークからの送信トラフィックは、厳選されたポート（HTTP、HTTPS、DNS、SSH、パッケージマネージャー）に制限されています。任意の送信接続はブロックされます。egress: false を指定して宣言したネットワークには、送信経路が一切ありません。

E2BやMorphとはどのように違いますか？ vs E2B: E2B はコード実行用サンドボックスとして優れています。コードの実行に最適化されており、インフラ向けではありません。利用できるのは単一のサンドボックスで、クラスターではなく、環境も OS レベルで実際の環境と一致しません。インフラ（Ansible のプレイブック、systemd の動作、SELinux ポリシー、ネットワーク）をテストするには、実際の OS と実際のパッケージが必要です。

vs Morph Cloud: Morph はエージェントに開発環境を提供します。Morph の devbox は、ソフトウェアを構築し、反復的に改善するコーディングエージェントに最適です。Antrieb はインフラ作業向けで、実際に使用しているディストリビューションとの忠実度が重要です。Ubuntu、AlmaLinux、Alpine、Arch、SONiC など、カスタマイズされた devbox ではなく、実際に稼働させているものと同じ OS を使えます。

Docker コンテナや GitHub Codespaces を使うだけの場合と、何が違いますか？

Docker コンテナはホストのカーネルを共有するため、コンテナ内では SELinux ポリシー、カーネルモジュール、systemd の動作、ディストリビューション固有のパッケージの細かな違いを確実にテストできません。Antrieb では、LLM 上で実際の VM を実行し、環境で使用する OS とまったく同じ OS を利用できます。

Linux ディストリビューション以外にも、多くのネットワークアプライアンスやインフラプラットフォーム（SONiC、Cisco IOS-XE、Palo Alto、F5、Juniper）は VM イメージとしてのみ提供されているか、コンテナの提供が限られています。コンテナ版が存在する場合も、ほとんどの場合、実物のサブセットにすぎません。機能が不足していたり、API が異なったり、動作が不完全だったりします。ベンダーごとに、コンテナ版で実際にサポートされている機能を把握すること自体が問題になります。VM なら実際のアプライアンスイメージを実行でき、完全な忠実度が得られます。

Codespaces は人間向けに作られています。ブラウザーやエディターを開き、クリックして操作し、入力します。Antrieb は、LLM が作業を検証できるように作られています。LLM は会話の中でツール呼び出しを通じてクラスターをプロビジョニングし、コマンドを実行し、出力を読み、反復的に改善します。これは、クリックして操作するためのスクリーンショットを LLM に渡すのと、直接 API を使わせることの違いです。

ツールリファレンス

provision

VM クラスターを起動します。セッションハンドル、ノード名、TTL、プロビジョニングにかかった時間を返します。ノードにはプライベート IP、/etc/hosts エントリー、パスワードなしの SSH 接続に使う共有 ed25519 キーペアが設定されます。

Parameter	Type	Required	Description
cluster	array	yes	VM トポロジーです。各エントリーには、短縮形式の文字列（"ubuntu24.04" = VM 1 台、"ubuntu24.04 x3" = VM 3 台）またはオブジェクト {image, count?} を指定します。
networks	array	no	クラスターごとのプライベートネットワークです。それぞれ {name, cidr?, egress?, dhcp?} または保存済みの仕様を参照する文字列 @namespace/name を指定します。デフォルトは、NAT イグレスを使用する default という名前のネットワーク 1 つです。
nics	object	no	ノード名をキーとする、ノードごとの NIC 割り当てです。例：{ "node1": [{"net":"lan"}] }。デフォルトでは、各ノードに最初のネットワーク上の NIC が 1 つ割り当てられます。

session_id、nodes、provision_time_ms、ttl_seconds、expires_at を返します。

exec

指定したノードでシェルコマンドを実行します。標準出力、標準エラー出力、終了コードを返します。各コマンドからは、ノード間の連携に使うクラスター環境変数（NODE_NAME、NODE_INDEX、NODE_IP、CLUSTER_HOSTS、CLUSTER_SSH_PUBKEY、CLUSTER_SSH_PRIVKEY）を利用できます。

Parameter	Type	Required	Description
session_id	string	yes	provision から取得します。
node	string	yes	ノード名です（例："node1"）。
command	string	yes	実行するシェルコマンドをそのまま指定します。

save

アーティファクトを保存します。保存したアーティファクトは組織の名前空間に置かれ、以降の provision ／ search 呼び出しですぐに利用できます。

パラメーター	型	必須	説明
type	string	いいえ	"image"（デフォルト）または "runbook"
name	string	はい	小文字とハイフンで構成される識別子（イメージの場合は antrieb:<name>:v1、ランブックの場合は @<namespace>/<name> になります）
description	string	いいえ	検索で使われる簡潔な説明（ランブックでは強く推奨されます。ブラウズモードで LLM に表示される内容です）
session_id	string	type=image または type=runbook の場合	イメージの場合は、スナップショットを作成するノードを含むセッションです。ランブックの場合は、シナリオを示す実行履歴を含むセッションです。
node	string	type=image の場合	保存するノード
commands	array	type=image の場合	ノードで実行した成功済みコマンドの順序付きリスト
body	string	type=runbook の場合	Markdown ドキュメント（構成については ランブック を参照）

search

カタログを閲覧するか、特定のランブックを取得します。2 つのモードがあります。ブラウズ（キーワードを指定するか、パラメーターなしの場合 → メタデータのリスト）と取得（type=runbook、fq_name=namespace/name の場合 → 本文全体を含む単一のランブック。適用する前に必ず取得してください）です。

パラメーター	型	必須	説明
type	string	いいえ	"image"（デフォルト）、"cluster"、または "runbook"
keywords	string	いいえ	名前、説明、fq_name を対象とする全文検索フィルター
fq_name	string	いいえ	完全修飾名で特定のランブックを取得し、Markdown 本文全体を返します。イメージとクラスターでは無視されます。
limit	number	いいえ	最大結果数（デフォルトは 20、最大 100）

delete

クラスターを破棄するか、保存済みアーティファクトを廃止します。antrieb/* のデフォルトは削除できません。

パラメーター	型	必須	説明
type	string	はい	"cluster"、"image"、または "runbook"
name	string	はい	クラスターの場合は session_id、それ以外の場合は短縮名または namespace/short 形式の fq_name

ライセンス

Apache 2.0