Tank OS — OpenClawを分離実行する安全設計の全容

AIエージェントが仕事の一部を担う時代になりました。しかし、ホストマシンに深くアクセスするエージェントをどう安全に動かすか、企業の多くはまだ答えを持っていません。

この記事では、OpenClawのメンテナー本人が設計した企業向けセキュリティ基盤「Tank OS」の仕組みを解説します。

この記事でわかること：

Tank OSがOpenClawのリスクをどう封じ込めるか
bootcとrootless Podmanを使ったOS設計の考え方
APIキーの安全な分離管理の仕組み
エンタープライズ以外でも参考になる設計の観点

OpenClawとは何か

OpenClawは「Any OS. Any Platform. The lobster way.」を掲げるオープンソースのAIエージェントです。GitHubで36万を超えるスターを獲得しており、ローカル環境でコーディング・ファイル操作・タスク自動化を実行できます。Claude CodeやCursorと並ぶ人気ツールとして、開発者から企業まで幅広く導入が広がっています。

エージェントが抱えるセキュリティの現実

AIエージェントはホストマシンのファイルシステム・ネットワーク・外部サービスのAPIにアクセスする設計上、攻撃者にとっても魅力的な標的になります。

2026年1月末、セキュリティ研究者のMav Levin氏（DepthFirst）がCVE-2026-25253を公開しました。深刻度は10段階中8.8。OpenClaw実行中のブラウザで特定のページを訪問するだけで、攻撃者がそのマシンの認証情報を取得し完全制御できる脆弱性でした。修正パッチが1月30日にリリースされるまで、公開インスタンス1万7500件以上が脆弱な状態に置かれていました。

脆弱性は修正されましたが、エージェントが「何でもできる」状態で動いている構造的な問題は残ります。設定ミスやゼロデイが再発したとき、被害をどこまで閉じ込められるかが問われます。

Tank OSとは

https://github.com/LobsterTrap/tank-os

Tank OSは、Red HatのシニアソフトウェアエンジニアであるSally O’Malley氏が週末のプロジェクトとして公開したオープンソースのFedora系OSイメージです。O’Malley氏はOpenClaw自体のメンテナーでもあり、エンタープライズ用途とRed HatのLinuxエコシステムへの対応を担当しています。

目的はひとことでいえば「OpenClawをOSごとコンテナに封じる」ことです。ツールを安全な箱の中で動かし、何かが起きても被害を箱の内側に留める設計になっています。Tank OS自体がサードパーティのパッチではなく、プロジェクト内部から出てきた提案であるという点が、この取り組みの性格を表しています。

bootcによるOSイメージ配布

Tank OSが使う中核技術のひとつが「bootc」です。bootcはコンテナイメージをそのままブート可能なLinux OSに変換する仕組みで、Red Hatが中心になって開発しています。

通常のLinuxサーバーでは、インストール後に個別のパッケージをインストール・設定し、環境を手作業で整えます。この方法は設定の不一致やパッチ抜けの温床になります。

Tank OSはOpenClawのランタイム・OS設定・systemdユニット・CLIシム・アップグレードパスを1つのOCIコンテナイメージとしてまとめます。このイメージを使ってマシンを起動すると、常に同一の環境が立ち上がります。更新はイメージの差し替えと再起動だけで完了し、個別のパッチ適用は不要です。クラウドサーバー・仮想マシン・物理ハードウェアのいずれにも同じイメージを適用できます。

rootless Podmanによるコンテナ隔離

もうひとつの核心はPodmanによる隔離です。OpenClawはrootless、つまり管理者（root）権限なしで動作するPodmanコンテナとして実行されます。Podmanはコンテナ内のプロセスをユーザー権限に閉じ込めるよう設計されたツールで、Red Hatが開発しました。

rootlessで動作させることで、コンテナ内部での問題がホストマシンの他の領域に波及しにくくなります。OpenClawが攻撃を受けたとしても、攻撃者はコンテナの外側に出られません。CVE-2026-25253のような脆弱性が今後発生した場合でも、被害範囲をコンテナ内に収める効果が期待できます。

APIキーの分離管理

APIキー——メールやSlackなどの外部サービスへの接続に使うシークレット——はインスタンスごとにPodmanのシークレットストアで保管されます。

この設計が持つ意味は2点あります。まず、APIキーがOSイメージに含まれないため、イメージを共有・公開してもシークレットが漏れません。次に、あるインスタンスのエージェントが別のインスタンスのAPIキーを参照できません。複数のエージェントを同一ホストで動かす企業にとって、この分離は権限昇格攻撃への耐性を高めます。

OS本体はbootcイメージ管理により大部分が読み取り専用として扱われます。ユーザー固有のOpenClaw設定は~openclaw/.openclawディレクトリに分離されており、OSとデータの境界が明確です。

誰が使うか

READMEにはRed Hatのエンタープライズユーザーをターゲットとすると明記されています。ただし設計の原則——エージェントを専用ユーザーで動かす、シークレットをOSのシークレットストアに預ける、OSを読み取り専用に近づける——は個人でも参考にできるセキュリティの基本です。

現在、公式イメージquay.io/sallyom/tank-os:latest（arm64/amd64対応）がQuay.ioで公開されており、Podman DesktopのBootC拡張機能を使ってローカルVMとして起動できます。SSHでログインし、systemctl --user status openclaw.serviceでサービス状態を確認するところから始められます。

O’Malley氏はTechCrunchに「数百万の自律エージェントが互いに通信し合う規模になったとき、それがどう見えるかに強い関心がある」と語っています。Tank OSはそのスケールを見据えた設計の起点として位置づけられています。

AIエージェント運用の次の問い

AIエージェントの普及は「使い始める」段階から「安全に維持する」段階へ移り始めています。OpenClawのような強力なツールをチームに展開するとき、設定の統一・シークレットの管理・障害の局所化は避けられない問題です。

Tank OSはその問いに、OS設計レベルから答えようとした試みです。bootcによるイメージ統一・rootless Podmanによる隔離・インスタンスごとのシークレット分離という3つの要素を組み合わせることで、「動けばよい」から「安全に動き続ける」への移行を支援します。