Unboundを入れる前に止め方を決める｜コーディングAIを配る線

「Claude Code には実行の前に確認する画面があるのだから、社員に配っても大丈夫だろう」「コーディングエージェントは開発部門の道具なので、情報システム部門が口を出す話ではない」——コーディングエージェントを社内に広げる段階で、よく交わされる会話です。どちらも半分だけ正しく、半分は外れています。配る前に決めておくべきなのは、使ってよいエージェントの一覧よりも、何をどこで止め、誰がそれを見るかという止め方のほうです。この記事では、2026年3月にこの統制の仕組みを製品として打ち出した Unbound を手がかりに、エージェントが触れるファイル・コマンド・MCP の範囲を誰が決め、どこで止め、例外をどう認め、記録を誰が見るかを、課題と原因と対策の順に整理します。

Unbound は、コーディングエージェントの操作を社内の方針で止める関所

Unbound は、米国サンフランシスコの Unbound AI が提供する製品です。米国の起業支援プログラムの2024年夏の採択企業で、もとは社員が生成AIを安全に使えるよう、やり取りを仲介する仕組みとして調査会社に紹介されていました。現在の公式サイトは、コーディングエージェントが何をできるかを統制する関所を前面に掲げています。

仕組みの中心は、エージェントが操作を実行する直前に、その内容を Unbound に問い合わせさせることです。Claude Code、Cursor、Codex、GitHub Copilot などが外部の制御のために用意している差し込み口を使い、ターミナルのコマンド、ファイルの読み書き、MCP の呼び出しを、管理者が決めた方針と突き合わせます。配る方法は、社員の端末を一括管理する仕組みからの配布と、個人の端末への小さな導入の二通りです。

ガードレールの一般論や、エージェントを隔離した実行環境で動かす考え方、AIゲートウェイの役割は別の記事で扱っているため、ここでは繰り返しません。この記事では、社員にエージェントを配る会社が、止める範囲と例外と記録を誰の責任で決めるかに絞って、Unbound の公開資料を材料にします。製品の解説ではなく、入れる側の判断の整理です。

2026年3月の発表で、何が打ち出されたか

Unbound AI は2026年3月、米国の大規模なセキュリティの展示会を前に、コーディングエージェント向けのアクセス統制を新しい製品分類として発表しました。クラウドのサービスへの社員のアクセスを仲介する製品が10年ほど前に生まれたのと同じように、エージェントと、エージェントが触れる開発環境・ターミナル・ファイル・API・データベース・外部の道具の間に、統制の層を置くという位置づけです。

発表で挙げた機能は四つです。社内で使われているエージェントとその版、配下のエージェント、設定の決まり、つながっている MCP を見つけること。自動で承認する設定や過剰な権限などの危ない構成を見つけること。破壊的なコマンドや危ない MCP の操作、機密の流れを、記録・警告・遮断・承認待ちのいずれかで扱うこと。そして監査に出せる証跡を残すことです。記録だけの段階から、全面的な遮断まで、段階的に広げられるとしています。

発表では、初期の導入先で、頼まれていないサービスの再起動や、指示のないままの変更の送信、変更を止めている期間中の破壊的なコマンドなど、行き過ぎた動作を数百件止めたとしています。これは同社の発表の数字で、外部の検証は示されていません。製品の判断に使うなら、自社の端末で記録だけの期間を設け、何がどれだけ引っかかるかを自分で確かめるのが確実です。

誤解：エージェント自身の確認画面があれば足りる

Claude Code をはじめ、多くのコーディングエージェントは、危ない操作の前に利用者へ確認を求める仕組みを持っています。それで十分だと考えたくなりますが、Unbound の公式の説明が指摘するとおり、エージェントに備わった確認は道具ごとにばらばらで、使う本人が切ることができ、会社がその設定を一括で強制したり監査したりできないという限界があります。

さらに、確認の画面は、人がその場にいる前提で働きます。Unbound の資料では、継続的な自動化の中や開発用の部品から Claude Code を動かすと、確認を求める相手がいないため、組織として遮断を指定していない限り操作はそのまま実行されると説明しています。開発部門が自動化の中にエージェントを組み込み始めると、人が確認する前提そのものが成り立たない場面が増えていきます。

確認画面は、開発者本人の手元の安全装置としては役に立ちます。ただ、それは会社としての止め方ではありません。会社として止めるには、本人の設定とは別の場所に方針を置き、本人が変えられない形で効かせる必要があります。以下の課題は、この前提から出てきます。

課題1：エージェントは開発部門の外にも配られている

コーディングエージェントと呼ばれていても、使う人は開発者に限りません。マーケのデータ担当が分析用の処理を書かせる、業務部門が表計算の加工やファイルの整理を任せる、といった使い方はすでに広がっています。Unbound も、Claude Desktop の作業代行の機能を対象に加え、調査、報告書の下書き、営業資料づくり、契約の確認などに使う知識労働者を、開発者と同じ方針の枠組みに入れられると説明しています。

業務部門のエージェントで危ないのは、本番のサーバーを壊すことよりも、読むべきでないファイルを読む、顧客の名簿を外のサービスに上げる、大量のファイルを消す、といった操作です。Unbound の業務部門向けの初期方針の例でも、指示の中に貼られた鍵や接続文字列、カード番号の検出、資格情報のファイルの読み取り、外部への送信、ブラウザ操作でのファイルのアップロードが並んでいます。

問題は、開発部門の外で誰が何を使っているかを、多くの会社が把握していないことです。社員が個人の契約でエージェントを使っていれば、会社の統制の外でデータが動きます。まず端末の棚卸しで、どのエージェントと MCP が入っているかを見える形にすることが、止め方を決める前の出発点になります。Unbound も、端末を走査してエージェントと MCP の一覧を作る機能を最初の入口にしています。

課題2：エージェントは使う人の権限をそのまま持つ

コーディングエージェントは、それを動かしている人の権限で動きます。開発者の端末であれば、サーバーに入るための鍵、クラウドの操作の資格、ソースコードの管理の資格、データベースへの接続まで、手の届くところにあります。公式サイトは、エージェントが開発者の資格をそのまま受け継ぐと指摘し、環境設定のファイルに書かれた鍵を読む、資格情報の表を検索する、本番のデータベースに MCP 経由で触れるといった操作を、実際に見た例として挙げています。

MCP は、この権限の範囲をさらに広げます。エージェントに Slack や Notion、Jira、社内のデータベースをつなげば、エージェントはそれらの道具でも、使う人の権限で書き込みや送信ができます。Unbound の資料は、個人のデータへのアクセス、信用できない内容の読み込み、外への送信路の三つがそろうと、仕込まれた指示によってデータが持ち出される危険が高まると説明しています。

この課題は、エージェントを配ることが、実質的には権限を配ることだという点にあります。社員にコーディングエージェントを渡す判断は、その社員が持つ全権限を、自然な言葉で指示を受ける仕組みに預けるかどうかの判断として扱う必要があります。

課題3：止めたい操作を、誰も一覧にしていない

「危ない操作は止めたい」という方針には誰も反対しません。ところが、具体的にどのコマンド、どのファイル、どの MCP の操作を止めるのかを一覧にしている会社は多くありません。一覧がなければ、止める仕組みを入れても設定のしようがありません。

Unbound は、コーディングエージェント向けに最初に適用する方針の一式を公開しています。7つの分類に分けた49の方針で、23を遮断、26を記録のみにしています。取り返しのつかない操作と本番環境に向けた操作は止め、それ以外は記録して、実際の利用を見てから締めるか緩めるかを決めるという考え方です。本番の分類では、本番環境のクラウド資源の削除、本番への配備、本番のデータベースへの書き込み、本番のサーバーへの接続などが遮断になっています。

この一式は出発点として役に立ちますが、そのまま自社の一覧にはなりません。何を本番と呼ぶかの名前の付け方、業務部門で守るべきファイルの場所、つないでよい MCP は、会社ごとに違います。一覧を作るのは製品ではなく、開発部門と情報システム部門と業務部門の代表が、一度は同じ席で決める作業です。

原因：権限を決める人と、使う人と、記録を見る人が同じになっている

三つの課題に共通する原因は、エージェントの権限を決める人、エージェントを使う人、エージェントの動きを確かめる人が、同じ一人になっていることです。開発者が自分でエージェントを入れ、自分で確認の設定を決め、自分で結果を見ている限り、その人が見落としたことは誰も気づきません。

人の社員であれば、権限を申請する人と承認する人、操作する人と監査する人を分けるのが、多くの会社の内部統制の基本です。エージェントについても、方針を決める人、方針の例外を承認する人、記録を見る人を、使う本人とは別に置くことが、統制の出発点になります。Unbound のような製品は、この分担を仕組みとして効かせるための道具であって、分担そのものを決めてはくれません。

逆に言えば、この分担が決まっていない会社が製品だけを入れると、管理画面の設定を開発部門の一人が持ち、承認の通知も同じ人に届き、記録は誰も見ない、という状態になりがちです。製品の選定より先に、三つの役を誰が持つかを決めておきます。

対策1：止める範囲を三段で決める

止め方は、遮断、承認待ち、記録のみの三段で決めるのが分かりやすい形です。Unbound はこれに警告を加えた四つの扱いを用意していますが、警告の効き方はエージェントによって違うため、会社の基本の方針は三段で組み、警告は補助に使うのが無難です。

扱い	向いている操作	決める人
遮断	本番環境の削除や配備、権限の付与、資格情報のファイルの読み取り、社外への大量の送信	情報システム部門と開発の責任者
承認待ち	共有の設定の書き換え、外部の MCP での書き込み、新しい部品の導入など、業務上は必要だが影響が大きい操作	承認者は使う本人以外の人
記録のみ	日常の開発やファイルの整理など、まずは実態を知りたい操作	記録を見る担当が、週に一度見直す

ここで大事なのは、記録のみの段を「止めていない」と見なさないことです。記録のみは、実態を知って次に締める範囲を決めるための期間です。記録のみで放置した方針は、止めていないのと同じになります。週に一度、記録のみの方針で何が引っかかったかを見て、遮断や承認待ちに上げるかを決める担当を置きます。

• 承認待ちの通知が、操作をしようとしている本人に届く設定のまま運用する
• 記録のみの方針を入れたまま、誰も記録を見ていない
• 製品の初期方針を、本番の名前の付け方を確かめずにそのまま適用する
• 遮断した操作が業務に必要になったとき、開発者が自分でエージェントの設定を変えて回避する

対策2：効き方はエージェントごとに違うと知っておく

同じ方針を書いても、エージェントによって効き方が違います。Unbound の資料は、エージェントごとに何が効くかの表を公開しており、遮断と記録のみはどのエージェントでも同じに働く一方、警告と承認待ちはエージェントが何を表示できるかで変わるとしています。たとえば Cursor と Codex では警告が使えず、Codex は操作を拒み、Cursor は操作を実行したうえで警告をエージェントに伝えるだけだと説明されています。

ファイルの編集についても、Cursor は編集が終わった後に報告する仕組みのため、編集を事前に止めるのではなく記録になると書かれています。また、API の窓口として Unbound を指定する形でつなぐエージェントでは、通信の記録と費用の計測はできても、コマンドや MCP に対する方針は効かないとしています。一覧の作成はできても、まだ方針が効かないエージェントもあります。

もう一つ見落としやすいのが、端末から Unbound に届かないときの動きです。資料によれば、初期設定では判定ができないと作業はそのまま続きます。組織として、判定できないときは止める設定にもできます。本人が外せるかどうかも、エージェントによって違います。資料によれば、Claude Code や Cursor では一括管理の配布で管理用の設定に登録され、本人の設定より優先されますが、Codex や GitHub Copilot のコマンド版は本人の設定から読み込むため、毎日の再設定で保つ形になるとしています。管理用の設定の守られ方も、端末の基本ソフトによって違うと注意書きがあります。どのエージェントを配ってよいかは、方針がどこまで効くかの表で決めるのが筋です。承認待ちが必要な操作があるなら、承認待ちが効かないエージェントは、その部署には配らない、という判断になります。

対策3：例外申請の通り道を先に作る

止める仕組みを入れると、必ず「この作業のためにこの操作を許してほしい」という申請が出てきます。通り道がなければ、開発者は止められた操作を手で実行したり、統制の外の道具に移ったりします。例外申請の通り道は、止める仕組みと同じ日に用意するものです。

Unbound では、承認待ちの操作は Slack で承認者の返答を待つ形になります。ただし資料では、初期設定の承認の宛先は開発者本人だと説明されています。これでは本人が自分の操作を承認するだけになるため、承認者を別の人に向ける設定に変えておく必要があります。承認待ちを持てないエージェントでは、本人以外が判断すべき操作は遮断にするよう、資料自身が勧めています。

例外は、期限と範囲を付けて認めるのが原則です。特定の利用者の集まりに方針を絞る機能もありますが、資料には、利用者の集まりを消すと、その集まりだけに絞っていた方針が全社に広がるという注意が書かれています。例外のつもりで作った集まりを片付けたら、全員が止められたということが起きないよう、集まりを消す前に方針の範囲を付け替える手順を決めておきます。方針を文書の形で版管理し、変更を相互確認で通す機能も用意されています。

対策4：記録を誰が見るか、どこまで残すかを決める

記録は、止めた証拠であると同時に、社員の作業の詳細な記録でもあります。Unbound の資料では、すべての操作が、止めたかどうかにかかわらず記録され、エージェントによっては指示の文章そのものも記録されるとしています。一方で、ソースコードの中身は持ち出さず、どの道具が呼ばれ、どのファイルに触れ、どの MCP が使われたかという動きの情報を見ていると説明しています。

保存期間も確かめておくべき点です。資料によれば、指示の文章、コマンド、MCP の呼び出し、方針の判定などの記録には、製品として保存期間の設定がなく、消すまで残ります。書き出したファイルは6時間で消え、外部への通知の受け手は自分の側で写しを持ちます。組織ごとの保存期間の設定は今のところないため、決まった期間で消す必要があるなら、サポートに文書で確認するよう案内されています。一方で、公式サイトの料金の案内には、契約の種類ごとに監査の記録を30日、あるいは90日以上残すという書き方があり、資料の説明とは読み方が分かれます。何がいつまで残り、何がいつ消えるのかは、契約書の条件として書面で確かめるのが確実です。外部への通知を使う場合は、受け手に届く内容に指示の文章が含まれるため、通知を受け取る先の保存期間も自社で管理します。

記録には、社員が指示に書いた顧客の情報や、悩みの相談のような内容まで含まれることがあります。誰が記録を見てよいか、何の目的で見るか、社員にどう知らせるかを、就業規則や社内規程と合わせて決める必要があります。セキュリティの担当が見る範囲と、部門の管理者が見る範囲を分け、作業の監視ではなく、方針の見直しのために見るという目的を明記しておくと、社員の不信を招きにくくなります。

• 料金や機能の範囲は、2026年11月時点の公式サイトと公式の資料で確かめたものです。契約前に最新の内容を営業窓口で確認してください
• 記録の扱いが従業員の個人情報に当たるかどうかは、社内規程と合わせて法務に確認してください

業務部門に配るときに、追加で引く線

マーケのデータ担当や業務部門にエージェントを配る場合は、開発部門の方針に加えて、扱うデータに応じた線を引きます。業務部門で守るべきものは、本番のサーバーよりも、顧客の名簿、売上の表、契約書といったファイルです。Unbound の業務部門向けの初期方針の例は、指示に貼られた鍵やカード番号の検出、資格情報のファイルの読み取り、大量のファイルの削除、外部への送信、新しいソフトウェアの導入を対象にしています。

マーケの仕事に置き換えると、顧客の一覧を書き出したファイルを外部のサービスに上げる操作、広告や分析の道具の鍵が書かれた設定ファイルを読む操作、共有のフォルダのファイルを一括で整理し直す操作が、承認待ちや遮断の候補になります。ブラウザ操作の道具をつないでいる場合は、外部のサイトのフォームにファイルを上げる操作も候補です。

業務部門では、承認する人を部門の管理者に置くか、情報システム部門に置くかも決めておきます。部門の管理者は業務の必要性は判断できても、操作の危険性は判断しにくいことがあります。業務の必要性は部門が、危険性は情報システム部門が見る二段の承認にするか、危険性の高い操作は最初から遮断にしておくのが現実的です。

入れるときの順番

止め方を決める作業と、製品を入れる作業は、並べて進めます。いきなり遮断を全社に効かせると、開発が止まり、統制そのものへの反発を招きます。段階を分けて広げます。

各段階で、遮断や承認待ちが業務をどれだけ止めたかと、開発者が回避しようとした痕跡がないかを確かめます。回避の痕跡が出たら、方針が厳しすぎるか、例外申請の通り道が使いにくいかのどちらかです。方針を緩めるか、申請の手間を減らすかを、責任者が判断します。

費用の増え方と、外し方

公式サイトの料金の案内では、上位でない方の契約が利用者1人あたり月20ドルで、人数の下限はなく、利用者1人あたり月5,000回の操作の判定を組織全体で合算して使えるとしています。100人以上の組織向けの契約は利用者1人あたり月28ドルからで、Unbound を経由したモデルの利用額の10パーセントを統制の手数料として加える形が示されています。100人以上の契約には、利用者の一括登録や単一の認証、役割ごとの権限、外部の記録の分析基盤への書き出し、承認の流れを自社で組む機能が含まれるとされています。承認の流れや役割ごとの権限が必要になるのは、統制を全社に広げる段階であることが多いため、最初の契約の形を選ぶときに、広げた後の費用まで見積もっておきます。

注意したいのは、上位でない方の契約で判定の回数の上限を超えると、初期設定では記録のみの状態に切り替わると書かれている点です。エージェントの利用が増えて上限を超えると、遮断していたはずの操作が止まらなくなる可能性があります。利用の伸びを見て、上限に近づいたら通知が来るようにしておくか、契約の形を見直す必要があります。

外し方も入れる前に確かめます。端末の一括管理から配布した場合、Unbound は Claude Code や Cursor の管理用の設定の場所に差し込み口を登録し、利用者の個人の設定より優先させます。外すときは、この管理用の設定から Unbound の登録を消す手順と、記録のデータを消してもらう依頼を、それぞれ確かめておきます。資料によれば、組織の停止と記録の消去は別々の依頼として、サポートが受け付ける形です。

配る前に確かめるチェックリスト

コーディングエージェントを社員に配る前に、次の項目が埋まっているかを確かめます。Unbound を使うかどうかにかかわらず、止め方を決めるための項目です。

• どのエージェントと MCP が誰の端末に入っているかの一覧がある
• 止める操作を、遮断・承認待ち・記録のみの三段で一覧にしてある
• 本番環境や守るべきファイルの場所を、名前の付け方まで含めて決めてある
• 配るエージェントごとに、方針がどこまで効くかを確かめてある
• 判定ができないときに作業を続けるか止めるかを決めてある
• 承認者が使う本人以外になっている
• 例外申請の期限と範囲の決め方が文書になっている
• 記録を見る人、見る目的、保存期間、社員への告知が決まっている
• 判定の回数の上限を超えたときの扱いを確かめてある
• 外すときの手順と、記録の消去の依頼先を確かめてある

このうち、承認者と記録を見る人の二つが埋まっていないなら、製品を入れる前に体制を決めるほうが先です。止める仕組みは、止めたことを誰かが見て初めて統制になるからです。

まとめ

Unbound は、コーディングエージェントのコマンド・ファイル・MCP の操作を、実行の前に社内の方針で判定する仕組みで、2026年3月にこの分野を新しい製品分類として打ち出しました。エージェントに備わった確認画面は本人の安全装置にすぎず、会社としての止め方にはなりません。配る前に、止める範囲を三段で決め、エージェントごとの効き方の差を知り、例外を承認する人と記録を見る人を使う本人とは別に置くことが前提です。AIに止めるかどうかを判断させるのではなく、人が決めた方針で止め、その結果を人が見る。この分担を決めてから、記録のみの試験運用で始めてください。

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