AIエージェントの変更を差分で確かめて確定か破棄を選べるOSS「DeltaBox Lite」とは

「AIエージェントに作業を任せたら、どのファイルをどう書き換えたのか後から追いきれなかった」「失敗したときに元へ戻せる保証がないので、結局は人が横で見張っている」——開発部門でAIエージェントを試し始めた企業の、情報システム担当者からよく聞く声です。これはエージェントの賢さの問題に見えます。しかし本当の問題は、エージェントが加えた変更を、確かめてから受け入れるという段階が、作業の流れの中に用意されていないことです。この記事では、AIエージェントに閉じた作業場所を与え、変更を差分で見せたうえで「確定」か「破棄」を選べるようにするOSS「DeltaBox Lite」を取り上げ、一次情報で確かめられる仕組みと限界、公開して日が浅いことによる注意点を整理します。導入や設定の手順は扱いません。

DeltaBox Liteとは何か。2026年10月時点で確かめられる事実

DeltaBox Liteは、GitHubで公開されているOSSです。リポジトリの説明は「軽量で、エージェントのために作られた、差分・確定・破棄を備えるサンドボックス（隔離された実行環境）」です。READMEは、プログラムを書くAIエージェントのための単体で動く隔離の仕組みだと説明しています。エージェントは閉じたファイルの見え方の中で自由に動け、加えた変更はすべて確かめる、確定する、破棄する、のいずれかを選べるというのが中心の考え方です。

配布の形を確かめます。リポジトリは2026年8月5日に作られ、ライセンスはApache-2.0です。2026年10月27日時点でスターは164、派生は6、変更の記録は142件でした。最後の更新は10月21日です。READMEの更新履歴によると、10月14日に0.1.0版と0.1.1版を出し、10月16日にOSSとして公開、10月21日の0.1.4版でWindowsにも対応したとされています。版の一覧には0.1.0、0.1.1、0.1.2、0.1.4が並んでいます。

対応するOSは、macOS、Linux、Windowsの三つで、それぞれ用に組み立て済みの配布物が用意されています。READMEは、Gitになぞらえて「エージェントの作業のためのGit」と説明しています。つまり、エージェントの一回の作業を、確かめてから受け入れる取引のように扱う道具という位置づけです。このOSSは、海外の技術者向けの掲示板で「巻き戻せるエージェント用サンドボックス」として紹介されたことで目に触れるようになりました。

なぜ「やり直せる作業場所」が求められるのか

プログラムを書くAIエージェントは、ファイルを作り、書き換え、消し、コマンドを走らせます。作業が思いどおりに進めば問題ありませんが、エージェントが誤った判断をしたり、紛れ込んだ悪意ある指示（プロンプトインジェクション）に従ったりすると、必要なファイルが書き換えられたり消されたりした状態が残ります。

多くの現場では、版管理の仕組みで後から戻せば足りると考えています。しかし、版管理に登録していない設定ファイルや生成物、大きなデータ、作業の途中で消された一時的な状態は、版管理の外にあります。READMEがこの道具の売りとして「二進数のファイルや大きなファイルを気にせずに済む」点を挙げているのは、まさにこの隙間を埋めるためだと読めます。

企業の立場から見ると、問題は「戻せるかどうか」が個々の開発者の注意力に委ねられている点です。エージェントの作業ごとに、何が変わったかを確かめ、受け入れるかどうかを決める段階があれば、事故の芽を、作業の結果が本番の作業場所に混ざる前に摘めることになります。この道具は、その段階を仕組みとして用意しようとするものです。

仕組み：OSごとの標準機能で作業場所を閉じる

DeltaBox Liteは、仮想マシンやコンテナを使いません。READMEは「コンテナではなく、OSに備わる隔離の仕組みを使う」と明記しています。Linuxでは、カーネルが用意する権限制限の機能と、利用者の側で動くファイルシステムの仕組みを組み合わせます。macOSでは、標準の隔離機能と、ファイルの複製を素早く作る仕組み、ファイルの変化を知らせる仕組みを使います。Windowsでは、プロセスの権限制限と、ファイルの見え方を切り替える別の部品を使うとされています。

どのOSでも、作業の状態は小さな補助のプロセスと、記録用のファイルで管理されます。READMEと作業の流れの文書によると、常に動き続ける管理用のサービスは要らず、記録用のファイルが作業の状態の正本になる設計です。途中でプロセスが落ちても、記録から状態を立て直せるとされています。

この設計の背景には、研究の成果があります。READMEは引用先として、2026年5月に論文の公開サイトに投稿された論文「DeltaBox」を挙げています。論文の要旨によると、AIエージェントが試行錯誤を繰り返すときに、作業の状態をまるごと写すのではなく変わった部分だけを記録して、保存と巻き戻しを速くするという考え方です。READMEは論文側の仕組みを軽量な仮想マシンを使うものとしており、DeltaBox Liteはその考え方を、仮想マシンを使わない単体の道具にしたものと読めます。ただし両者の関係を詳しく説明した一次情報は見当たりませんでした。

差分・確定・破棄という流れ

この道具の中心は、作業のあとに差分を見て、確定か破棄かを選ぶ流れです。READMEによると、差分は通常の文章のファイルなら行ごとの違いとして表示され、二進数のファイルや大きなファイルには、変わったことを示す印が付きます。破棄を選ぶと、選んだ時点の状態に戻り、確定を選ぶと、その時点の状態が受け入れられます。

確かめる単位は、作業ひとつ分と、道具の呼び出し一回分の二通りです。作業の流れの文書によると、単体で使う場合は直前に確定した状態、作業単位なら作業を始めた時点、道具の呼び出し単位なら呼び出す直前が、破棄したときの戻り先になります。利用者が自分で保存点を作らなくても、連携する側が、適切な戻り先を自動で選ぶ仕組みです。

連携については、READMEに、DeepSeek系の作業環境向けの部品と、別のコーディングエージェント向けの拡張が用意されていると書かれています。ほかのエージェントとつなぐための取り決め（標準入出力でやり取りする方式）も文書で公開されています。ただし、主要な商用のAIエージェントとの公式な連携は、確認した一次情報には挙げられていませんでした。社内でよく使うエージェントとつながるかは、別に確かめる必要があります。

三つの作業の見え方と、その違い

DeltaBox Liteには、作業中の変更を外からどう見せるかについて、三つの方式があります。一つ目は、変更がすぐに元の作業場所に反映される方式です。LinuxとmacOSでは、これが初期の設定です。確定はそのまま受け入れるだけの軽い処理になり、破棄するときは記録をたどって元に戻します。

二つ目は、作業場所の写しの中で動き、確定したときに、触れたファイルだけを元の作業場所に反映する方式です。READMEはこれを「確定するまで変更を元の側から隠す方式」と説明しています。三つ目は、互換性のための予備の方式で、写しを丸ごと使います。安全の面から見ると、確定するまで元の作業場所に変更が届かない二つ目の方式のほうが、守りは厚いと言えます。

注意したいのは、初期の設定が一つ目の方式である点です。macOSの文書によると、この方式は「作業中はDeltaBox Liteだけが元の作業場所に書き込む」ことを前提にしています。同じ作業場所を、ほかの道具や人が同時に書き換えると、破棄したときに正しく戻せる保証がなくなるということです。厳格な設定では外からの書き込みを検知して破棄を拒むとされていますが、どの方式を使うかは、使う側が意識して選ぶ必要があります。

秘密の置き場所・通信・環境変数の制限

READMEは、この道具の考え方を「方針を先に決める」と表現しています。方針の文書によると、読み書きできるのは作業場所と一部のシステムの場所に限られ、書き込めるのは作業場所だけです。初期の方針では、環境設定を書いたファイル、秘密鍵のファイル、サーバー接続やクラウドの認証情報の置き場所が拒否の対象に入っています。これらを作ったり書き換えたりする操作は、変更が反映される前に拒否されるとされています。

環境変数（プログラムに渡す設定値）は、空の状態から始め、言語や端末の種類など、ごく少数の値だけを引き継ぎます。文書は、管理する側のAIの利用キーが暗黙に引き継がれることはないと明記しています。書き込みの量にも上限があり、初期の方針では1回の書き込みが16メビバイト、確定していない変更の合計が1ギビバイトまでです。

通信には四つの方式があります。すべて拒否する方式、決めた接続先だけを許す方式、コマンドごとに一時的な許可を与え、コマンドが終われば失効させる方式、そして制限せず記録だけを取る方式です。重要なのは、初期の設定は、通信を制限しない最後の方式だという点です。外へ送られる情報を絞りたいなら、使う側が明示的に方式を選び直す必要があります。

巻き戻せないもの：開発元が明記する限界

一次情報で評価できるのは、巻き戻せないものを文書がはっきり書いている点です。READMEと方針の文書は、作業場所の外への書き込みは巻き戻せないと明記しています。コマンドごとに書き込みの範囲を作業場所の外まで広げる設定もあり、その場合も外側に加えた変更は元に戻せないと書かれています。

作業の流れの文書には、ほかにも限界が並んでいます。動いているプロセスや開いているファイル、シェルの状態は記録から立て直せません。失敗したコマンドは、すでに外に影響が出ている可能性があるため、自動でやり直されません。初期の設定は、プロセスが落ちることには備えていますが、突然の停電までは想定していないと文書自身が書いています。より強く守る設定は別に用意されています。

OSごとの差もあります。方針の文書によると、Windowsでは隔離はファイルの範囲だけに効き、通信の方針は効かない状態として報告されます。macOSでは、プロセスの数やプロセッサの使用率の上限は、OSの制限としては効きません。またREADMEは、シェルの書き方によっては、操作の一部が隔離の外で行われうると注意しています。「閉じた作業場所」には、OSや設定によって穴があることを前提に考える必要があります。

比べる表：版管理・コンテナ・仮想マシンとの違い

DeltaBox Liteの立ち位置を、企業の担当者が判断に使える形で整理しました。READMEと文書の記載をもとにした比較で、どれが優れているかではなく、何を守りたいかで選ぶ話です。

見る点	版管理の仕組み	コンテナ・仮想マシン	DeltaBox Lite
主な目的	ファイルの変更履歴を残す	実行環境を丸ごと分ける	エージェントの作業を確かめてから受け入れる
戻せる範囲	登録したファイルだけ	環境ごと捨てられる	作業場所の中の変更（外への書き込みは戻せない）
大きなファイル・二進数のファイル	扱いにくい	影響しない	変更の印を付けて扱える
普段の道具との相性	そのまま使える	入れ直しや同期が要る	作業場所でそのまま動く
壁の強さ	隔離の機能はない	強い	OSの権限制限に頼る。仮想マシンより弱いと考えるべき
外への通信	関係しない	設定しだいで絞れる	初期は制限なし。方式を選べば絞れる（Windowsでは効かない）

表のとおり、DeltaBox Liteは版管理とコンテナの間を埋める道具です。版管理より広い範囲を戻せる一方で、コンテナや仮想マシンのような強い壁を作るわけではありません。READMEも「コンテナではない」と書いており、悪意を前提にした強い隔離が要る作業には、仮想マシンなどを別に使うと考えるのが妥当です。なお、READMEには開発元が測った処理の速さの数値も載っていますが、開発元自身の測定であり、この記事では評価していません。

想定される使い方・使う場面

一次情報で確かめた機能から考えると、企業での使いどころは三つに整理できます。一つ目は、開発者の端末やサーバーで、AIエージェントにまとまった作業を任せる場面です。作業の終わりに差分を確かめる段階を挟めるため、エージェントの変更が、確かめないまま作業場所に積み重なる状態を減らせます。

二つ目は、同じ作業場所を複数のエージェントに触らせる場面です。READMEの更新履歴によると、複数のエージェントが並行してそれぞれの写しで作業し、確定の順番を調停する仕組みが加えられています。ただし、作業の流れの文書は、一つの作業場所を借りられる作業は一度に一つだけ、とも書いており、どこまで並行できるかは方式によって異なります。

三つ目は、社内のルールの具体化です。「エージェントの変更は、人が差分を見てから確定する」「秘密の置き場所への書き込みは拒否する」といった決まりを、道具の上で確かめられる手順に落とし込めるのは利点です。逆に、外への通信を厳しく絞る必要がある作業や、Windowsの端末で通信まで守りたい場面には、この道具だけでは足りません。

安全性の評価：注意付きとした根拠

このラインでは、紹介するOSSを、公開されている事実だけを基に精査しています。OSSを入手したり動かしたりはしていません。DeltaBox Liteの判定は「注意付き」です。

まず、問題が見つからなかった点です。ライセンスはApache-2.0で、商用を含めて使えます。GitHub上にこのリポジトリのセキュリティ勧告は登録されていませんでした。取り込みのときに自動で動く処理を含む設定も見当たりませんでした。スターの伸びは1日あたり約2件で、不自然な水増しの兆候は見られませんでした。

一方で、注意付きとした理由は運営体制にあります。リポジトリを所有する組織のアカウントは2026年9月22日に作られており、リポジトリ（8月5日作成）より新しい状態でした。別の場所で作られたリポジトリを後から組織へ移したものとみられますが、経緯は一次情報では確かめられませんでした。組織のアカウントには説明も所在地もなく、公開しているリポジトリは5件、フォロワーは2人で、組織としての実績を判断できる材料が乏しい状態です。なお、勧告がないことや自動実行がないことは、安全の保証ではありません。精査は公開情報の範囲に限られ、コードの中身を検証したものではないからです。

運営体制と公開の経緯で確かめたいこと

GitHubの記録では、このリポジトリに変更を加えた人は4人で、変更の件数は多い順に67件、30件、28件、16件でした。そのうち一人は、引用先の論文の著者と同じ名前のアカウントです。研究に由来する道具である可能性は高いと考えられますが、運営している組織や所属は、確認した一次情報には書かれていませんでした。公式サイトも、確認した時点では題名以外の情報をほとんど読み取れませんでした。

版はまだ0.1系で、OSSとして公開されてから10日ほどしか経っていません。この短い間に新しいOSへの対応や通信の制限の仕組みが加わっており、動きは活発です。裏を返せば、仕様や初期の設定が今後も変わりうる段階だということです。確認した時点で、弱点を見つけたときの報告の窓口をまとめた文書（セキュリティポリシー）は登録されていませんでした。

配布物の確かめ方も見ておきます。版の一覧によると、0.1.0版と0.1.4版の配布物には、改ざんを確かめるための値（ハッシュ値）のファイルが添えられています。ただし、配布物への電子署名や、作られた経緯の証明についての記載は見当たりませんでした。守りの要になる道具なので、入手元と版を固定し、社内で確かめたものだけを配る形が前提になります。

悪用されうるリスク

DeltaBox Liteは守りのための道具で、攻撃に使うためのものではありません。それでも、使い方しだいで生まれうる危険はあります。最も大きいのは、破棄できることが、エージェントの承認の確認や人の見張りを省く理由になることです。作業場所の外への書き込みや外への通信は巻き戻せないため、破棄で取り消せない被害は残ります。

次に気になるのが、導入の方法です。READMEには、端末を操作できるAIエージェントに渡す導入用の文章が載っており、エージェントがリポジトリ上の別の文書を読み、それに従って導入と確認を進める形になっています。この方式では、エージェントが従う文書の中身を、人が事前に確かめないまま実行が進むおそれがあります。文書が書き換えられた場合の影響も考えられるため、社内では使わない方針を取るのが無難です。これは推測を含む評価で、実際に悪用された事例は、2026年10月27日時点で確認した一次情報からは見つけられませんでした。

さらに、通信の初期設定が制限なしである点も推測上の危険につながります。悪意ある指示を紛れ込ませた文書をエージェントが読めば、作業場所の中で読める情報が外へ送られうる状態に残ります。差分の確認はファイルの変更を見るもので、外へ送られた情報は、差分には現れません。ファイルの守りと通信の守りを別のものとして考える必要があります。

導入を検討するときに確かめること

実際に検討するときは、動かす前に、資料と社内の取り決めで確かめられる点から整理します。下の手順は、OSSを動かす前の段階で終えられるものに絞っています。

この手順の要は、道具を入れる前に「破棄で取り消せないもの」を言葉にしておくことです。やり直せる仕組みは、入れた瞬間から「失敗しても戻せる」という安心を生みます。その安心の範囲を先に決めておかないと、確認を省く使い方だけが広がります。

企業が取るべき対策

一つ目は、差分を確かめる人を決めることです。確定を押すのがエージェント自身や、内容を読まない利用者であれば、差分の機能は形だけになります。確定は人が差分を読んでから行うことを、作業の決まりとして明記します。二つ目は、エージェントの承認の確認の扱いを決めることです。破棄できる道具を入れても、作業場所の外に触れる操作や外への通信を伴う操作は、承認の対象に残します。

三つ目は、通信の監視です。初期の設定では通信が制限されないため、端末や社内の出口で、想定外の送信先への通信を見られるようにしておきます。四つ目は、作業場所に秘密を置かないことです。拒否の対象は決まった種類のファイルに限られ、作業場所の中に置いたほかの形の秘密は、読まれうると考えて扱います。

五つ目は、調達のときの確認です。運営組織の実態が分からないOSSを業務で使う場合は、ライセンス、報告の窓口、更新の頻度、止まったときの代わりを、導入前に文書で残します。使い続けるかどうかを、四半期ごとなど決めた間隔で見直すことも含めておきます。版が0.1系のうちは、とくに短い間隔で確かめるのが現実的です。

AIに任せる範囲と、人が決める範囲

DeltaBox Liteは、AIエージェントに自由に作業させつつ、その結果を受け入れるかどうかを後から決められるようにする道具です。便利な一方で、確定するかどうかの判断までAIに委ねてしまうと、差分を確かめる段階そのものが意味を失います。AIは変更の内容を要約する手伝いはできますが、受け入れるかどうかは人が決める範囲に残します。

AIに差分の要約を作らせる場合も、変更ごとに理由を書かせ、人が差分そのものを読み、理由に納得できない変更は破棄するという確認の段階を置きます。やってはいけない向き合い方を挙げます。

• 「破棄できるから」を理由に、エージェントの承認の確認を一律に省く
• 差分を読まずに、エージェントの作業の結果をまとめて確定する
• 確定するかどうかの判断を、エージェント自身に任せる
• 通信の初期設定が制限なしであることを知らないまま、機密の資料を作業場所に置く
• AIエージェントに導入用の文書を読ませて、そのまま導入まで任せる
• 運営体制や更新の状況を誰も見ず、版が古いまま使い続ける

裏を返せば、人が決める範囲ははっきりしています。誰が差分を読んで確定するか、どの通信を許すか、どの作業で承認を省くか、誰が運営体制を見るか。この四つを決めたうえで、決めた範囲の作業をエージェントに任せるのが、道具とAIの正しい使い分けです。

よくある質問：破棄できるなら承認の確認は要らないのか

答えは「それだけでは足りない」です。DeltaBox Liteで取り消せるのは、作業場所の中のファイルの変更です。作業場所の外への書き込みや、外へ送られた情報、動いているプロセスの状態は、文書自身が巻き戻せないと書いています。承認を省くかどうかは、作業の中身と扱う情報で決める話で、破棄できるかどうかだけで決めるものではありません。

では入れる意味がないのかというと、そうではありません。エージェントの変更を、作業の結果が本番の作業場所に混ざる前に確かめる段階を作れます。版管理に載らないファイルの変更も含めて取り消せるため、誤った変更が積み重なる状態を減らせます。もう一つ、「論文の仕組みと同じ強さで守れるのか」という問いもありそうです。READMEは論文側の仕組みを軽量な仮想マシンを使うものとしており、DeltaBox Liteは仮想マシンを使いません。守りの強さは同じではないと考えるべきです。

• DeltaBox Liteの機能・初期の設定・対応環境・運営体制は、GitHubのリポジトリとその中の文書、版の一覧、組織のアカウントの情報、引用先の論文の要旨を2026年10月27日に確かめた範囲に基づきます。版が0.1系のため、内容は今後変わる可能性があります
• 運営組織の所属、組織のアカウントへリポジトリが移った経緯、論文の仕組みとの詳しい関係、配布物の電子署名の有無は、確認した一次情報の範囲では確かめられませんでした
• この記事は守りと評価の目線で書いています。導入・設定・実行の手順は扱いません

まとめ

DeltaBox Liteは、AIエージェントに閉じた作業場所を与え、加えた変更を差分で確かめてから「確定」か「破棄」かを選べるようにするOSSです。仮想マシンやコンテナではなく、各OSに備わる権限制限とファイルの仕組みを使い、版管理に載らないファイルの変更も含めて取り消せる点が特徴です。秘密の置き場所への書き込みの拒否や、環境変数の絞り込み、通信の制限の選択肢も備えています。Apache-2.0で公開され、セキュリティ勧告は登録されていません。

一方で、作業場所の外への書き込みや外への通信は巻き戻せず、通信は初期状態で制限されません。Windowsでは通信の方針が効かないとも書かれています。所有する組織のアカウントはリポジトリより新しく、版も0.1系と若いため、運営体制は使う側が見ていく必要があります。確定する人、許す通信、承認を省く条件、運営体制を見る担当を先に決めたうえで使うことが、AIエージェントを業務で動かす企業にとってのDeltaBox Liteの使いどころです。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。