社員ごとにAIエージェントを配る企業が知っておきたい隔離基盤OSS「OneCLI」の確認点

「部署ごとにAIエージェントを試したいという声が増えたが、誰のエージェントがどの鍵を持っているのか、もう把握できていない」「個人が勝手に動かしているエージェントを、会社として一つの決まりの下にまとめたい」——AIエージェントの社内展開を任された情報システム部門から、ここ数か月で聞くことが増えた声です。OneCLI は、こうした悩みに応えるとうたう、チーム向けのAIエージェントの実行基盤を公開しているソフトウェアです。社員一人ひとりに、外と切り離された個人用のエージェントを配る、という位置づけです。ただし、基盤を入れれば統制が終わる、という話ではありません。本当は、社員全員の鍵を一か所に預ける仕組みを、自社で守り続けられるかを確かめる話です。この記事では、OneCLI が何をするものかを公開情報で確かめられる範囲で押さえ、無償と有償の範囲、変更の記録に残った守りの直し方から、企業が導入を考えるときに確かめるべき点を整理します。導入や設定の方法は扱いません。

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

OneCLI は、同名の組織がGitHubで公開しているソフトウェアです。リポジトリの説明には「チーム向けの、隔離されたエージェントの実行基盤。すべての社員に、守られた個人用のエージェントを」とあります。2026年10月16日時点で、スター（関心を示す登録）は約3,600、派生（フォーク）は約260です。リポジトリの作成は2026年3月8日で、平均すると1日あたり16件ほどスターが増えてきた計算になります。

READMEによると、OneCLI はもともと、AIエージェント用の鍵の保管庫として Rust で作られました。自律的に動くエージェントを使う個人やチームからの要望が多く、足りないものとして「鍵と権限の管理」と「チームでの管理」の二つが挙がったため、チームでエージェントを動かす基盤へと作り直した、と説明されています。これが2026年8月18日に出た2.0系です。鍵の保管庫から、エージェントの実行基盤へと役割を広げてきたという経緯は、評価の前提として押さえておきたい点です。

開発の速さも特徴です。リリースの一覧には、2026年3月11日の1.0.0から10月14日の2.14.0まで、およそ110の版が並びます。10月だけでも10回の版が出ています。ライセンスの文書の著作権表示は ChartDB という企業で、公式サイトには、著名なスタートアップ支援の組織の支援を受けていると書かれています。ただし、これは公開元の自己紹介で、この記事では独立に裏づけを取っていません。運営の組織アカウントは2026年2月24日の作成で、歴史は約8か月です。

なぜ今、社員ごとのAIエージェントを束ねる基盤が求められるのか

AIエージェントは、指示を受けると自分で道具を呼び出し、外部のサービスにつなぎ、ファイルを読み書きしながら作業を進めます。メールの下書き、顧客管理の記録の更新、表計算の集計など、業務の道具に直接触れる使い方が広がってきました。そのためにはエージェントに鍵（外部のサービスに接続するための秘密の情報）を渡す必要があり、鍵がエージェントの手元に置かれること自体が危うさの源になります。

READMEは、世の中の自律型エージェントの多くは一人で使うことを前提に作られている、と指摘しています。一人で使う分には便利でも、チームに広げた途端に、誰のエージェントか、何をしてよいか、どこで動かすか、の管理が散らばる、という問題意識です。情報システムの担当者から見れば、把握できないエージェントと、把握できない鍵が社内に増えていく状態です。これは、かつて部署ごとに勝手に導入されたクラウドの道具が管理の外に置かれたのと、よく似た構図です。

加えて、エージェントは読み込んだ文書や網上のページに紛れ込んだ指示に引きずられる（プロンプトインジェクション）おそれがあります。エージェントの判断を完全に信じることはできないので、判断を誤ったときに届く範囲を、エージェントの外側で狭めておく必要があります。OneCLI の「エージェントは隔離された場所で動き、外へ出る道は関所だけ」という設計は、この考え方を基盤の形にしたものと言えます。

仕組み1：社員ごとのエージェントと、隔離された作業場所

READMEによると、OneCLI ではエージェントを社員一人ごとに作ります。各エージェントは、ファイルの置き場と操作の窓口を持つ専用の隔離された作業場所（サンドボックス：外と切り離した実行の場）を持ち、そこから外に出る道は関所（ゲートウェイ）だけで、許可されたものにしか届かない、と説明されています。エージェントとのやりとりは管理画面か、Slack の中で行います。

エージェントは一回きりの指示ではなく、続いていく存在として設計されています。READMEには、会話の記録、学んだことを残す記憶、あらかじめ書いておく手順や補助の部品、予定を立てて決まった時刻に動く仕組みが挙がっています。記憶は基盤が保管し、人がいつでも読んで書き換えられる、とされます。エージェントの記憶も、社内の情報が溜まる保管場所になるので、扱うデータの区分を決めておく必要があります。

エージェントを動かす部分（ランナー）は自社の環境で動き、外向きの通信だけを使って受け付けの口を開けないため、社内の閉じた網の中でも動かせる、とREADMEは説明しています。コンテナの管理基盤で動かす場合は、エージェントの作業場所ごとに専用の領域を割り当て、既定ですべての通信を断ったうえで関所などへの通信だけを許す囲いを作る、と配布の説明書にあります。その囲いが働いていることを確かめられなければ、エージェントを起動しない（迷ったら止める）作りだとされます。

仕組み2：出口を一つにする関所と、鍵を見せない差し込み

OneCLI の中心は関所です。READMEによると、関所はエージェントから外への通信を途中で受け止め、暗号化された通信も中間で開いて中身を確かめたうえで、鍵を差し込んで送り出します。エージェントが持つのは関所を通るための通行用の証だけで、外部のサービスの本物の鍵はエージェントに渡らない、というのが基本の考え方です。

保管された鍵は、保存時に強い暗号方式（AES-256-GCM）で暗号化され、要求のときにだけ復号されて、行き先の名前と住所の形に合ったものが差し込まれる、と説明されています。自社運用の説明書によると、社内の網の住所や機械自身を指す住所など、内部の行き先への通信は既定で拒否され、明示した行き先だけが許されます。クラウドの管理用の住所は、正確に指定したときだけ開くとされます。

この設計の裏側も押さえておきます。暗号化された通信を中間で開く関所は、すべての社員の鍵と通信の中身が通る場所です。関所が破られたり、設定を誤ったりすれば、影響は一人のエージェントにとどまりません。関所を動かす機械の管理、関所の鍵（暗号化の元になる秘密の値）の保管、関所の記録の扱いは、ほかの重要な社内の仕組みと同じ水準で守る必要があります。

仕組み3：チームで一つの方針と、チャットの中の人の承認

READMEによると、OneCLI ではチームの方針を一か所で管理し、作業場所の中のすべてのエージェントに同じ方針が当てはまります。共有の接続（AIのモデルを使うための鍵や、業務用のアカウントなど）はチームの単位で一度つなぎ、エージェントごとに使ってよいかを許可します。許可されても、鍵そのものがエージェントに手渡されることはない、と説明されています。

取り消せない操作には、人の承認を挟めます。READMEは例として、メールの送信、作業管理の道具の記録の削除、クラウドの保管場所を空にする操作を挙げ、チャットの中で「決定的な」人の承認ができる、と書いています。ここでいう決定的とは、AIの判断ではなく、決めた規則に当たれば必ず人に回る、という意味と読めます。Slack では承認の依頼が、承認と拒否のボタンの付いた札として届く、と配布元の説明書にあります。承認を挟むかどうかを、AIの判断ではなく規則で決める点は、評価の物差しとして使えます。

ただし、承認の仕組みがあることと、承認が意味を持つことは別です。依頼が多すぎれば、人は中身を読まずにボタンを押すようになります。どの操作を人に回すかの絞り込みが、承認の仕組みそのものより大切です。公式サイトは、どの変更に承認が要るかを規則で決め、決まった作業は承認なしで進められる、と説明しています。規則の作り方しだいで、承認は守りにも形だけの手続きにもなります。

鍵の預け先：基盤の保管庫と、外部のパスワード管理

鍵の置き場は二通りあります。一つは基盤のデータベースに暗号化して保管する方法です。もう一つは、外部のパスワード管理の道具とつなぐ方法で、READMEは Bitwarden と 1Password を挙げ、サーバーに何も保存せずに必要なときだけ差し込める、と説明しています。

連携の説明書によると、Bitwarden の場合は、基盤に保管された鍵が見つからないときの予備として、行き先の名前で保管庫に鍵を問い合わせます。取り出した鍵は記憶領域に60秒だけ置かれて捨てられ、ディスクやデータベースには書かれない、とされます。1Password の場合は、基盤の鍵の値の代わりに保管庫の項目を指す参照を置き、要求のときに中身を取りにいく形です。

外部の保管庫を使えば、基盤のデータベースが漏れたときの被害は小さくなる可能性があります。一方で、行き先の名前だけで保管庫から鍵を引き出す仕組みは、保管庫に入っている鍵の範囲がそのままエージェントの届く範囲になりうる、ということでもあります。社員が個人で使っている保管庫をつなぐのか、エージェント専用に分けた保管庫だけをつなぐのかは、導入の前に決めておきたい論点です。この点について公開元の推奨は、確かめた範囲では見当たりませんでした。

隔離の道具「nono」との違い（比べる表）

このラインでは、AIエージェントを囲う公開ソフトウェアとして nono も取り上げています。どちらも「エージェントに本物の鍵を見せない」点は共通していますが、狙っている場面が大きく違います。下の表は、両者の公開元の説明に基づく目安で、この記事で性能や強さを測ったものではありません。

観点	OneCLI（公開元の説明）	nono（公開元の説明）
主な使い手	会社のチーム。社員ごとにエージェントを配る	個人の手元のエージェント
囲いの作り方	エージェントごとの隔離された作業場所。外への道は関所だけ	基本ソフトの制限の機能で、道具の呼び出しごとに囲う
鍵の扱い	関所が通信の途中で差し込む。外部のパスワード管理とも連携	代理の仕組みが外へ出る境目で差し込む
人の承認	チャットや Slack の中で承認と拒否を選ぶ	方針の外の操作を人に回す
管理の単位	チームで一つの方針。社員の身元との連携は有償の範囲	設定のまとまりを道具ごとに書く
守る側が抱えるもの	全社員の鍵と通信が通る関所と管理画面	手元の機械ごとの設定と版の更新

表のとおり、nono は「一人の手元を細かく囲う道具」、OneCLI は「チーム全体のエージェントを一か所で束ねる基盤」です。OneCLI は管理を一か所に集める分、集めた場所そのものを守る責任が、自社に移ってくることになります。どちらが良いかではなく、誰が、どこで、何の鍵を使ってエージェントを動かすのかに合わせて選ぶ、あるいは組み合わせる、という発想が現実的です。

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

このラインでは、OSSをクローンもインストールも実行もせず、公開されている事実だけで安全面を判定しています。OneCLI の判定は「注意付き」です。悪意のあるソフトの報告、説明と配布方法の食い違い、有名なソフトと紛らわしい名前といった、記事にしない理由に当たる事実は見つかりませんでした。GitHubのセキュリティ勧告は、2026年10月16日時点で0件です。

注意を付けた理由は三つです。一つ目は、運営の組織アカウントが2026年2月の作成で、歴史が約8か月と浅いことです。二つ目は、スターの伸びが1日あたり約16件と速く、話題が先行している可能性があることです。三つ目は、開発用の部品の一覧に、部品を取り込んだときに自動で動く準備の処理が書かれていることです。中身は、版管理の操作の前に検査を走らせる道具を用意するもので、開発の現場ではよく使われる設定ですが、自動で動く処理である以上、確かめる対象に入ります。

勧告が0件であることも、そのまま安心の材料にはなりません。後で見るとおり、変更の記録には、関所の方針をすり抜けられる不具合の修正が含まれていますが、勧告としては公開されていません。問題が見つからなかった点があっても、それは安全の保証ではありません。ここでの判定は、公開された情報を2026年10月16日に確かめた時点のものです。

無償の範囲と有償の範囲：ライセンスと運営体制

READMEによると、ライセンスはApache-2.0ですが、例外があります。企業向けの機能を収めた特定のフォルダは、別の企業向けライセンスの対象です。このライセンスは、開発・試験・評価には無償で使えますが、本番での利用には有償の契約が必要とされます。それ以外の部分は、商用のライセンスなしで本番の自社運用ができる、と説明されています。

確かめておきたいのは、どの機能が有償の範囲に入るかです。コンテナの管理基盤向けの配布の説明書には、企業向けの機能として、SSOとSCIM（社員の身元と所属の自動連携）、所属のまとまり、役割に応じた権限管理、複数の組織の管理、利用額の上限が挙がっています。READMEの冒頭にある「会社の身元管理の仕組みとつないで、社員ごとにエージェントを用意する」という機能は、本番で使うには有償の契約が前提になると読めます。

運営体制の面では、脆弱性の報告方針が公開されており、GitHubの非公開の報告の窓口とメールで受け付け、3営業日以内に受領を返し、10営業日以内に評価と修正の目安を示すとしています。関心の高い報告として、鍵の漏えい、組織をまたいだデータの閲覧、方針の判定のすり抜け、権限の昇格が挙がっています。この報告方針の文書が加わったのは2026年8月で、それより前の7月には、公開の課題の欄で非公開の報告の窓口があるかを尋ねる投稿がありました。両者の関係は確認できていません。

変更の記録から読み取れる、守りの直し方

勧告は0件ですが、変更の記録には守りに関わる修正がいくつか残っています。最も重いのは、2026年7月23日の1.42.0で入った修正です。修正の説明によると、ブロックや承認の規則がかかったエージェントが、鍵は差し込まれるのに規則の判定が当たらない別の行き先に切り替えることで、規則をすり抜けられた、とされます。

原因は、鍵を差し込む行き先の一覧と、規則を当てる行き先の一覧が別々に管理され、ずれていたことだと説明されています。修正では、規則を当てる範囲を、鍵を差し込む範囲から導くように改め、変更はいつも判定の範囲を広げる側、つまり守りが強くなる側に倒した、とされます。鍵が届く範囲と、規則が見張る範囲は、必ず一致していなければならないという教訓は、どの関所の仕組みにも当てはまります。

ほかにも、9月3日の2.5.0では、資格情報を伴う、別の出どころのページからの呼び出しを信頼できる出どころに限る修正が、10月6日の2.8.0では外への通信の見張り（変更の記録では「出口の守り」）が加わっています。直す流れが動いていることは良い材料です。一方で、こうした修正が勧告として公開されていないため、勧告の一覧だけを見ていては、自社の版に影響があるか判断できないことになります。変更の記録まで読む運用が必要です。

悪用されうるリスク

OneCLI は守りのための基盤で、それ自体を攻撃に使う道具ではありません。それでも、悪用の可能性は考えておく必要があります。一つ目は、基盤そのものが狙われることです。全社員の鍵が一か所に集まり、関所がすべての通信を中間で開く以上、基盤の管理画面や関所を乗っ取られれば、多くのサービスに一度に手が届く可能性があります。ただし、OneCLI が実際の攻撃に使われたという報告は、この記事の調査では見つかっていません。

二つ目は、エージェントが紛れ込んだ指示に引きずられ、許可された範囲の中で不適切な操作をすることです。関所は、許していない行き先には通しませんが、許した行き先での誤った操作までは止められません。前の章で触れた規則のすり抜けのように、判定の隙間があれば、許していない操作に届く可能性もあります。許可した範囲の中の誤りは、規則と人の承認でしか止められないことを前提に、承認を挟む操作を選ぶ必要があります。

三つ目は、外部からの登録です。自社運用の説明書によると、新しい利用者の登録は意図して開いたままにされており、登録を止める切り替えはありません。新しく登録した人は自分だけの組織に入り、ほかの組織からは切り離される、とされます。部外者を入れたくない場合は、管理画面を網の境界の内側に置くことが前提とされています。管理画面を外から届く場所に置けば、誰でも登録できる状態になる点は、見落としやすい落とし穴です。

自社で運用するときに見落としやすい点

自社運用の説明書には、守りに関わる注意がいくつも書かれています。一つ目は版の扱いです。各部品は既定で最新の版を使う設定になっており、続けて使うなら版を固定するよう勧められています。データベースの構造を書き換える処理は元に戻せない、とされているので、版を上げる判断は、戻せない変更として扱う必要があります。

二つ目は、更新の漏れです。説明書によると、ある種の簡略な更新の仕方では、管理画面や関所は新しくなるのに、エージェントの作業場所の元になる部品だけが古いまま残り、そのずれは何も知らせてくれない、とされます。修正を当てたつもりで、エージェントの側だけ古いという状態が起こりうるわけです。三つ目は、ログイン機能のない古い版からの移行です。古い版のデータは最初に登録した人に引き継がれるため、外から届く場所では部外者に先を越されないよう注意するよう書かれています。

四つ目は、隔離の強さです。コンテナの管理基盤向けの説明書は、エージェント同士が基本ソフトの中核を共有するため、作業場所専用の機械を分けることを勧めています。また、配布元の手順を取り寄せてそのまま実行させる導入方法も案内されています。こうした導入方法を社内で許すかどうかは、調達の決まりと照らし合わせて決めておくべきでしょう。

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

導入を検討する段階で確かめておきたい点を、順に並べます。動かして試す前に、書類と公開情報で確かめられる範囲です。

この五つは、動かす前に紙の上で決められることです。試しに動かしてから決めようとすると、すでにエージェントが社員の日常の作業に入り込んでいて、止めにくくなります。とくに一つ目は、決めないまま進めると、統制の機能が使えないと分かった時点で計画を作り直すことになりかねません。

企業が取るべき対策

OneCLI を使うかどうかにかかわらず、社員ごとにAIエージェントを配ろうとする企業が取っておきたい対策を四つ挙げます。一つ目は、エージェントの基盤を、最も重要な社内の仕組みと同じ扱いにすることです。全社員の鍵と通信が集まる場所なので、管理画面を外から届かない場所に置き、管理者の権限を絞り、基盤の版を資産の台帳に載せて脆弱性管理の対象に入れます。

二つ目は、鍵の見直しです。エージェントに使わせる鍵は、人が使う鍵と分け、操作の種類と行き先を絞った専用のものにします。基盤が鍵を見せない作りでも、預けた鍵の権限が広ければ、関所が破られたときの被害は大きくなります。三つ目は、記録を見る体制です。公式サイトは呼び出しをすべて記録すると説明していますが、どの記録を、誰が、どの頻度で見るかは自社で決めなければ働きません。

四つ目は、社内規程です。エージェントに渡してよい鍵の種類、承認を挟む操作、エージェントの記憶に残してよい情報の区分、使ってよい基盤と版の決め方を書き込みます。基盤の選定と、渡す権限の決めごとを、別々に管理することで、基盤を替えても決めごとは残ります。社員が個人で動かしているエージェントの洗い出しも、あわせて進めておきたいところです。

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

エージェントの基盤は、AIにどこまで任せるかを決めやすくする道具であって、決めること自体を肩代わりするものではありません。避けたい向き合い方を挙げます。

• 基盤が鍵を見せない作りだからと、本番の強い権限の鍵をそのまま預ける
• 承認を挟むかどうかを、AIの判断や自動の承認に任せる
• エージェントに、なぜその操作が必要かの根拠を書かせないまま承認する
• 管理画面を外から届く場所に置いたまま、誰が登録できるかを確かめない
• 勧告が0件だからと、変更の記録を読まずに古い版を使い続ける

裏を返せば、人が決める範囲ははっきりしています。どの鍵を預けるか、どの操作に承認を挟むか、どの版を使うか、いつ止めるか。この四つはAIに判断させません。承認を求められたときは、エージェントに操作の目的と根拠を書かせ、人がそれを読んで決めます。人が確認する範囲を先に決めておけば、AIに任せてよいのは、その範囲の中で取り消せる作業を速く進める部分だけになります。

よくある質問：無償で使えるか、MCPへの対応はどうか

問い1：無償で全社に配れますか。中心部分はApache-2.0で、本番の自社運用もできると説明されています。ただし、社員の身元との連携や役割に応じた権限管理などは企業向けライセンスの範囲で、本番での利用には有償の契約が必要とされます。公式サイトにはクラウド版の無料の枠も示されていますが、上限があります。全社への展開を考えるなら、必要な統制の機能がどちらに入るかを先に確かめてください。

問い2：MCPには対応していますか。リポジトリの話題の分類（トピック）にはMCPが挙がり、ソースの中にはMCPの橋渡しとみられる部品の名前があります。ただし、READMEや公式の文書の概要ではMCPの扱いが詳しく説明されておらず、どこまで関所の規則や承認の対象になるかは、現時点で確認できる情報が限られます。問い3：日本語の情報はありますか。2026年10月時点で、日本語で OneCLI を詳しく紹介した情報はほとんど見当たりません。公式の文書は英語が中心で、更新も速いため、判断の前には一次情報を確かめる必要があります。

• この記事の事実は、GitHubのリポジトリ（README・ライセンス・報告方針・説明書・変更の記録・リリースの一覧）と公式サイト・公式の文書を2026年10月16日に確かめた範囲に基づきます。版は短い間隔で増えるため、使う前に最新の状態を確かめてください
• 規則のすり抜けの修正は、変更の記録と修正の説明に基づくもので、勧告としては公開されていません。影響を受けた版の範囲は、この記事では確かめていません
• この記事は OneCLI を動かして試したものではありません。導入・設定の方法は扱いません

まとめ

OneCLI は、社員一人ひとりに隔離されたAIエージェントを用意し、外への通信を一つの関所に通して、鍵の差し込み・チームの方針・人の承認をまとめて扱う公開ソフトウェアです。中心部分はApache-2.0で、2026年10月時点でスターは約3,600、ほぼ毎週のように版が進んでいます。エージェントに本物の鍵を見せない作りや、承認を規則で決める考え方は、社内でエージェントを使うときの物差しとしても参考になります。

一方で、運営の歴史は約8か月と浅く、社員の身元との連携などの統制の機能は有償の範囲です。2026年7月には関所の規則をすり抜けられる不具合が修正されていますが、勧告としては公開されていません。全社員の鍵が集まる基盤そのものが、新しい守りの対象になるという前提は外せません。

情報システムやセキュリティの担当者が持ち帰るべきは、特定の基盤の是非ではなく物差しです。どの鍵を預け、どの操作に人の承認を挟み、どの版を使い、いつ止めるか。基盤を選ぶ前に、この決めごとを人が先に持っておくことが、社員ごとのエージェントを安全に広げる一番の備えになります。

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