この記事の対象読者
- Mac ユーザー
- AIコーディングエージェントのテスト環境を探している方
- AIコーディングエージェントの承認依頼に少し疲れた方
- ターミナルの操作が少しできる方
動作を検証したPCのスペック
- OS: macOS Tahoe 26.5.1
- チップ: Apple M1 Max
AIコーディングエージェントの自律性と安全性
AIコーディングエージェント(以下、エージェント)とは、与えられた開発の目的に向けて自律的に判断し、ツールを呼び出しながらコーディング作業を進める AI ツールのことです。
質問に回答するチャットボットとは違い、ターミナルでのコマンド実行、ファイルの読み書き、外部 API の呼び出しといった「手を動かす」操作まで自分でこなせるのが大きな特徴です。
目的に向かって、真っ直ぐ素直に様々な作業を進めてくれるのですが、これには相応のリスクを伴います。
例えば
- 意図しないコマンド実行
- 予定のなかったファイル削除
- 勝手にツールをバンバン導入
- 外部から読み込んだ情報から不正な命令を実行(プロンプトインジェクション)
といったことです。
自分が普段利用している端末で、このような操作が発生すると取り返しがつかない状態になるかもしれません。
たいていのエージェントはコマンドを実行する際、頻繁に操作者に承認を求めてきます。
最初は危険性も頭にあるため内容に目を通し、承認を行うことが多いのではないでしょうか。
しかし、Yes の選択が何度も何度も続けば確認するのが次第に面倒になり承認に疲れてくると思います。
そこで目に入るのが、承認をスキップするようなオプションです。(Claude Code であれば —dangerously-skip-permissions というオプション)
名前からして実行することを躊躇してしまいますよね。
このような性質を持つエージェントをどう安全に扱えばよいのでしょうか。
参考になるのが、Anthropic が公開している Claude を制御するための考え方です。
同社は、エージェントを制御する仕組みを大きく 3つの層に分けて整理しています。(※1)
- 実行環境の層: エージェントが到達できる範囲を物理的に制限する層
- モデルの層: システムプロンプトや学習などによって、モデルの振る舞いを望ましい方向へ導く層
- 外部コンテンツの層: MCP サーバーやプラグイン、Web ツールなど、外部から流れ込むコンテンツを監視・制限する層
3つの層はどれか一つを守ればいいという訳ではありません。
あくまでそれぞれに対して対策を行うという前提です。
しかし、安全性をより重視するなら「実行環境の層」でエージェントの到達範囲を絞り込むことが最も効果的で確実です。
今回の記事は自分が普段利用している環境とエージェントを動作させる環境を分けることで利便性と安全性のバランスを取りながら、エージェントに積極的に作業を任せるという試みです。
エージェントの動作環境の境界
「環境を分ける」といっても、その分け方にはいくつかのレベルがあります。
境界の独立性が高いほど万が一の場合の影響を閉じ込められますが、その分だけ準備に手間がかかったり、端末への負荷は増えていきます。
代表的な分離レベルを、境界の独立性が低い順にならべると次のようになります。
| 分離レベル | 境界の作り方 | 独立性 | GUI の利用 |
|---|---|---|---|
| フォルダレベル | 触ってよいフォルダを決めておく | ★☆☆☆ | ◯(ホストの画面をそのまま使える) |
| OS レベル(アプリ単位の制限) | アプリごとに触れてよいファイルや通信先を OS が制限する | ★★☆☆ | ✕(文字のコマンド操作が中心) |
| OS レベル(コンテナ) | アプリとファイルをひとつの箱にまとめて動かす | ★★★☆ | ✕(文字のコマンド操作が中心) |
| ハードウェアレベル | もう 1 台分のパソコンをソフトウェアとして丸ごと立ち上げる | ★★★★ | ◯(デスクトップ画面ごと利用できる) |
※ 独立性は ★ が多いほど高い(最大 ★★★★)
フォルダレベル
- 具体例: このフォルダだけ触ってもいいと作業範囲を決めておく
- 特徴: いちばん手軽。ただし約束ごとに近い制限なので、その気になれば外のファイルにも届いてしまう
OS レベル(アプリ単位の制限)
- 具体例: アプリごとに触れてよいファイルや通信先を OS の力で制限する。エージェントの Claude Code にも、この仕組みのサンドボックス機能が標準搭載されています(※2)
- 特徴: フォルダレベルより堅く、承認なしでも作業を任せやすい。ただしパソコン本体(OS の中核)は共有したままなので、完全な隔離ではない
OS レベル(コンテナ)
- 具体例: Docker などの「コンテナ」で、アプリとファイルをひとつの箱にまとめて動かす
- 特徴: 手軽さと隔離の強さのバランスがよい。ただし OS の中核を本体と共有している点は弱点として残る
ハードウェアレベル
- 具体例: 仮想マシン(VM)で、もう 1 台分のパソコンをソフトウェアとして丸ごと立ち上げる
- 特徴: OS ごと別になるため、1 台のなかで作れる隔離としては最も強い。準備の手間はあるが、画面(GUI)まで普段どおり使えることが多い
文字のコマンド操作(CUI)で触れれば十分という場合は、アプリ単位の制限やコンテナによる分離でも事足りるのですが、できればいつものデスクトップのように画面で操作できる環境がいいと思います。 今回紹介する Tart はハードウェアレベルの境界を準備してくれるツールです。
Tart(タート/タルト) について
Tart (※3) は、Mac の上に、もう一つの Mac や Linux のデスクトップ環境を手軽に立ち上げられる仮想化ツールです。
Apple 純正の仮想化の仕組み(Virtualization framework)を使っているため、仮想環境でも普段の Mac に近い軽快さで操作できます。
あらかじめ用意された環境のイメージをコマンドひとつで複製できるので、思い立ったときにすぐ作業場を用意できます。壊れても作り直すだけで済むため、エージェントに思い切って作業を任せる「使い捨ての環境」として相性が良いツールです。
もともとは Cirrus Labs が 2022 年に公開したツールで、2026 年に同社が OpenAI に参画したことにともない、現在は OpenAI のプロジェクトとして開発されています(※4)。
必要なマシンスペック
- チップ: Apple Silicon(M1 以降)。Intel 搭載の Mac では利用できません
- OS: macOS 13.0(Ventura)以降
- 空き容量: VM のイメージは大きく、macOS イメージは初回ダウンロードだけで 25 GB ほど。複数の環境を持つなら数十 GB 以上の余裕があると安心です
- メモリ: ホストと仮想マシンで分け合うため、16 GB 以上あると快適に動かせます
ライセンス
Tart は Functional Source License(FSL-1.1-ALv2) で公開されています。
社内での利用や商用利用も含めて基本的に無償で使えます。Tart と競合する製品を提供するような場合は制限されます。
たとえば今回のように、個人や社内でエージェントの作業環境として使うぶんには問題がないライセンスです(※5)。
※ 2026年7月1日のライセンスです。
Tart のインストールと VM の作成・起動
※2026年7月1日の情報です。
ここからは実際に Tart を導入し、仮想マシンを起動するところまでを進めます。
インストール
Tart は Homebrew(macOS のパッケージ管理ツール)で導入できます。
ターミナルで次のコマンドを実行します。
brew install cirruslabs/cli/tart
インストール後、tart --version でバージョンが表示されれば準備完了です。
VM イメージの取得と起動
Tart には、すぐに使える macOS / Linux のベースイメージが公開されています。ここでは macOS のイメージを取得して起動してみます。tart clone で公開イメージをローカルに複製し、tart run で起動します。
# 公開イメージをローカルに複製(初回は 25 GB ほどダウンロードするため通信環境がよいところで実行してください)
tart clone ghcr.io/cirruslabs/macos-tahoe-base:latest tahoe-base
# 仮想マシンを起動(デスクトップ画面がウィンドウで開きます)
tart run tahoe-base
これ以降は現在自分が操作している macOS をホスト OS、VM 起動後にモニタ内で動作しているもう一つの macOS をゲスト OS と呼ぶことにします。
GUI で操作できるので、普段の Mac と同じ感覚で操作することができます。
日本語で利用するためのゲスト OS の設定
tart で作成したゲスト OS でターミナルを開いてください。
もし仮想マシン内でユーザー名とパスワードを聞かれることがあれば、 ユーザー名: admin パスワード: admin がデフォルト設定です
# 地域(Region)を「日本 (Japan)」に変更する
defaults write NSGlobalDomain AppleLocale -string "ja_JP"
defaults write NSGlobalDomain AppleCountryCode -string "JP"
# 時刻を jst へ
sudo ln -sf /var/db/timezone/zoneinfo/Asia/Tokyo /etc/localtime
# メニューバーなどの言語表示は好みによってどちらかを実行する
# 日本語優先にする場合
# 1. 優先する言語(Preferred Languages)の一番上に「日本語」を追加・設定する
defaults write NSGlobalDomain AppleLanguages -array "ja-JP" "en-US"
# 2. システム全体のデフォルト言語を日本語に固定する(要パスワード入力)
sudo languagesetup -langspec ja
# 表示などは一旦英語で大丈夫な場合
# 1. 優先する言語(Preferred Languages)に「日本語」を追加・設定する
defaults write NSGlobalDomain AppleLanguages -array "en-US" "ja-JP"
あとは画面操作で日本語入力を追加します。
こちらのコマンドを実行してください。
open "x-apple.systempreferences:com.apple.Keyboard-Settings.extension?TextInputs"
キーボードの設定が出力されるので、このように設定します。
ここまで設定したらゲスト OS を一度再起動しましょう。
基本操作
VM の管理はホスト OS のターミナルで次のコマンドで行えます。
停止や削除が手軽にできるため、「壊れたら作り直す」をカジュアルに行えます。
tart run tahoe-base # VM の起動
tart list # VM の一覧を表示
tart stop tahoe-base # VM を停止
tart delete tahoe-base # VM を削除
ゲスト OS 内でエージェントを動かしてみる
仮想環境が整ったら、いよいよエージェントを動かしてみます。
今回はエージェントツールとして Claude Code を例にしてセットアップを行っていきます。
ここからの操作は、すべてゲスト OS(VM の中)のターミナルで行います。
Claude Code のインストール
Claude Code は、ゲスト OS のターミナルで次のコマンドを実行するだけで導入できます。
公式が推奨しているネイティブインストーラーを使う方法です。Node.js などを別途用意する必要はなく、インストーラーがそのまま実行ファイルを配置してくれます。
curl -fsSL https://claude.ai/install.sh | bash
インストールが終わったら、claude --version でバージョンが表示されることを確認しておきましょう。
(Homebrew が好みであれば brew install --cask claude-code、Node.js 18 以降が入っている環境なら npm install -g @anthropic-ai/claude-code でも導入できます)
起動とログイン
作業したいフォルダに移動して claude を実行すると、Claude Code が起動します。
claude
初回起動時はログインを求められます。
ブラウザが自動で開きますが、そちらはひとまずスルーします。
(ゲスト OS 内のブラウザにウェブサービスのログインセッションを残さないようにするため)
- ターミナルに表示されるログイン用 URL をコピー
- ホスト OS 側の普段使っているブラウザで開いて貼り付けし認証コードを発行、コピー
- ゲスト OS 側へ認証コードを貼り付けします。
ログインが完了すれば、そのままゲスト OS の中でエージェントに指示を出せるようになります。
隔離環境で承認スキップも試してみる
ここまでの準備で、エージェントはホスト OS から切り離されたゲスト OS の中だけで動くようになりました。
万が一おかしなコマンドが実行されても、影響が及ぶのはこの使い捨ての VM の内側だけです。壊れてもホスト OS 側で tart delete を実行し消して作り直せばよいので、思い切って権限を渡すことが可能です。
冒頭で「躊躇する」と紹介した承認スキップのオプションも、この環境であれば選択肢に入ってきます。
ゲスト OS の中で次のように起動すると、コマンドごとの承認依頼を省いてエージェントに作業を任せられます。
claude --dangerously-skip-permissions
# もしくは
claude --permission-mode bypassPermissions
ここで強調したいのは「このオプションを使いましょう」ということではありません。
普段の端末では利用できない権限でもゲスト OS 内では動作させられるということです。
実際に利用する場合は settings.json(Claude Code の設定ファイル)などを活用してエージェントを制御することになりますが、ホスト OS 側ほど神経質に調整する必要がなくなるでしょう。
また今回守れたのは 3 層のうち「実行環境の層」だけで、残る「モデルの層」と「外部コンテンツの層」は手つかずのままです。
たとえば外側への通信は制限していませんし、ゲスト OS 内のブラウザで各種サービスへ自分のアカウントでサインインしてしまえば、Claude Code でブラウザを操作する際にそのアカウントのまま動けてしまいます。
あくまで「実行環境の層が整い、最悪の場合でも被害をこの VM に閉じ込め VM ごと捨てられる状態になった」という理解にとどめ、過信は禁物です。
弊社の開発チームでは、このようなゲスト OS を立ち上げて自社サービスの動作確認などで利用しています。
活用の様子はこちらの記事をご覧ください。
ゲスト OS で調整可能な設定
詳しくはTart のクイックスタートを見てもらうといいですが、便利な設定をいくつか紹介します。
こちらのコマンドはホスト OS で実行するものです。
別の名前の VM を立ち上げる
※それぞれにホスト側のメモリなどを割くことになるので、重くなると思います。
tart clone ghcr.io/cirruslabs/macos-tahoe-base:latest {好きなVM名}
ホスト OS とゲスト OS でフォルダを共有する
例えば、ゲスト OS の中で画像生成を行って、ホスト側で参照したいようなケースです。
tart run --dir={ゲスト側のフォルダ名}:{ホスト側の同期したいフォルダまでのパス} tahoe-base
たとえば、ホスト側で tart run を実行するフォルダに shared_folder を用意してゲスト OS へ共有する場合は、次のようになります。
tart run --dir=host_shared:"$(pwd)"/shared_folder tahoe-base
これでゲスト OS の host_shared フォルダと、コマンドを実行したフォルダ内の shared_folder が同期されます。
"$(pwd)"の部分は、コマンドを実行した現在のフォルダのパスに自動で置き換わります- ゲスト OS 側では
/Volumes/My\ Shared\ Files/{ゲスト側のフォルダ名}/で確認できます
ゲスト OS からホスト OS への通信をできなくする
より厳密にネットワークを分離したい場合は、--net-softnet を付けて起動します。
tart run --net-softnet tahoe-base
これを付けるとゲスト OS はホスト OS やローカルネットワークへ到達できなくなります。
なお Softnet は別途インストールが必要なので、未導入の場合はホスト OS で次のコマンドを実行しておきます。
brew install cirruslabs/cli/softnet
まとめ
エージェントは目的に向かって素直に手を動かしてくれる頼もしい存在ですが、その自律性はリスクも伴います。
それを制御するために承認フローがありますが、何度も対応するのは面倒ですし、かといって承認をスキップするオプションは普段使いの端末では怖くて踏み切れません。
この記事では、その解決策として「実行環境の層」でエージェントの到達範囲を絞り込むアプローチを取りました。
分離レベルにはフォルダ・OS・ハードウェアといった段階がありますが、画面(GUI)まで普段どおり使いながら最も強い隔離を得られるのがハードウェアレベル、つまり仮想マシンです。
そして Mac 上で仮想マシンを手軽に立ち上げる手段として Tart を使い、ゲスト OS の中で Claude Code を動かすところまでを通しで見てきました。
ポイントを振り返ると次のとおりです。
- エージェントの制御は「実行環境 / モデル / 外部コンテンツ」の 3 層で考え、なかでも実行環境の層での隔離が確実
- Tart なら
tart cloneとtart runだけで使い捨ての macOS / Linux 環境を用意でき、壊れても作り直すだけで済む - 隔離された VM の中であれば何かあっても環境ごと捨てられるため、強めの自律実行も選択肢になる
普段の環境を守りつつ、エージェントに思い切り動いてもらう。
その両立のためのちょうどよい作業場として、ぜひ一度 Tart をお試しください。
GiftXは、社内での AI 活用を促進するための支援サービスを用意しています。
「うちでもやってみたい」と思ったら、ぜひお気軽にお問い合わせください。
補足: ゲスト OS で Claude Cowork も動かせるか?
検証しましたが自分の環境では動作しませんでした。
Claude Cowork 内部でも部分的に仮想化を行う※6ため、ゲスト OS 内でさらに仮想化を行うと、入れ子になる仮想化を行う構造になるからです。
M3チップ以降の Mac を利用されている方は
それぞれ入れ子になる仮想化をサポートしているようなので動作する可能性が高いのではと思います。
自分はM1なので未対応でした…
参考リンク
- ※1Anthropic での Claude の抑え込み体制
- ※2Claude Code のサンドボックスコマンドについて
- ※3Tart 公式サイト
- ※4Cirrus Labs の OpenAI 参画に関するアナウンス
- ※5Tart のライセンス(FSL-1.1-ALv2)
- ※6Claude Cowork デスクトップアーキテクチャの概要
- ※7Apple: 入れ子になる仮想化のサポート状況(isNestedVirtualizationSupported)
- ※8Tart FAQ: Nested Virtualization Support