【2026年】Zenityで社内AIを見張る｜市民開発を止めない統制

「現場が Copilot Studio でエージェントを作り始めたが、社内にいくつあるのか誰も知らない」「止めたら現場の工夫が止まるし、放っておくのも怖い」——社員が自分でAIエージェントを作れるようになった会社の情報システム部門と、AI推進の担当者から聞こえてくる声です。どちらの声ももっともで、片方だけを取ると、もう片方の問題が大きくなります。答えは「禁止か黙認か」の二択ではありません。本当は、作ることは止めずに、作られたものを見つけて、危ない動きだけを止める仕組みと、その判定をする人を決めることが要ります。この記事では、2026年に資金調達と日本市場への展開を発表した Zenity を例に、社員が作るエージェントの統制を、1つのエージェントが広がっていく段階に沿って整理します。

Zenityは何をする製品か

Zenity は、AIエージェントのための安全と統制の基盤です。公式サイトでは、クラウドの業務サービスの中で動くエージェント、自社で作るエージェントの基盤、社員の端末で動くエージェントの3つを対象に、エージェントを見つけて見える化し、危ない設定を早い段階で抑え、実行中の脅威を検知して対応する、という3つの働きを説明しています。

見える化の働きについて、公式サイトは「どのエージェントがあり、誰が持ち主で、何に触れられ、どこが悪用されうるか」を示すと書いています。検知については、エージェントの道具の呼び出し、記憶の参照、データの使い方、処理の流れを見て、操作の意図から危なさを判断する方式だとしています。検知の結果は、AIの安全で使われる2つの脅威の分類（OWASP と MITRE ATLAS）に対応づけられます。

2026年8月の資金調達の発表では、対象として Microsoft Copilot、ChatGPT Enterprise、Gemini、Claude・Codex・Cursor などのコーディングエージェント、Bedrock や Vertex などで自社が作るエージェントが挙げられています。そして、操作が起きる前に、許可・変更・遮断を決める仕組みだと説明しています（2026年10月時点）。エージェントの権限をどう委任するかは同じ便の Arcade の記事に、作る基盤の配り方は Dust の記事に譲り、この記事では見張る側に絞ります。

対象が3つに分かれていることには意味があります。クラウドの業務サービスの中のエージェントは、社員が画面の操作だけで作るもの、自社の基盤のエージェントは開発の担当が作るもの、端末のエージェントは社員が自分の手元で動かすコーディングの道具などです。作る人も、作られる場所も、記録の残り方も違うため、基盤ごとの管理画面を別々に見ていると、社内のエージェントの全体の数はつかめません。横断して見る道具の価値は、この3つを1つの一覧にまとめられるかどうかで決まります。

作っている会社と、国内でまだ知られていない理由

Zenity は、研究開発の拠点をイスラエルのテルアビブに、事業の拠点を米国ニューヨークに置く会社です。公式の発表によれば、2026年8月3日に1億2,500万ドルのシリーズCの資金調達を発表しました。米国の投資会社ノーウェストが主導し、新たにソフトバンク・ビジョン・ファンド2や日立のベンチャー投資部門なども加わっています。従業員は世界で230人を超えるとされています。

国内ではまだ知名度が高くありません。日本語で読める情報は資金調達の報道が中心で、製品のまとまった解説は2026年10月時点でほとんど見当たりません。理由の1つは、これまで日本の顧客や販売の協力会社と海外から取引してきたことです。公式ブログでは2026年10月8日に、東京に責任者を置いて日本市場に本格的に展開すると発表し、10月から11月にかけて東京での展示会や自社のイベントへの出展を案内しています。

もう1つの理由は、市場そのものの新しさです。社員が作ったエージェントを見張る、という課題は、社員が実際にエージェントを作り始めてから初めて表に出ます。国内ではその段階に来た会社がまだ限られています。なお、公式の公開資料では、製品の画面や窓口の日本語対応は確かめられませんでした。検討するなら、日本語の支援の範囲を販売の窓口に確かめる必要があります。

同じブログでは、日本での具体的な予定として、伊藤忠テクノソリューションズが10月16日に開く展示会への出展、11月10日の自社の催し、11月17〜18日のセキュリティの国際会議コードブルーへの出展と研究者の講演が案内されています。日本の大手の情報通信企業の担当者が自社の催しに登壇することも記されており、国内の販売の協力会社を通じた提供が広がる段階にあると読めます。製品を検討するなら、直接の契約か販売の協力会社経由かで、問い合わせの窓口と支援の範囲が変わる点も確かめておきます。

2026年、作る人が情シスの外に出た

社員が業務の道具を自分で作る「市民開発」は、表計算のマクロやノーコードの業務アプリの時代からありました。違うのは、AIエージェントが文章を読んで判断し、自分で道具を呼び出すことです。業務アプリなら決まった手順しか動きませんが、エージェントは受け取った文章によって動きが変わります。

Zenity は2025年9月4日に、Microsoft Copilot Studio との連携を広げたと発表しました。発表によれば、Copilot Studio で作られた各エージェントの中で動き、MCP サーバー・CRM・業務アプリ・メールなどへの道具の呼び出しに制御をかけます。対象として挙げているのは、データの持ち出し、直接・間接の指示の乗っ取り、秘密の情報の不適切な扱いで、操作が完了する前に意図と振る舞いを見て止めると説明しています（発表時点では公開プレビュー）。

ここから分かるのは、統制の重心が「作る前の審査」から「作られたあとの見張り」へ移っていることです。作る人が情シスの外に増えると、すべてを事前に審査することはできません。エージェントの統制の考え方そのものは、AIエージェントのガバナンスの記事で、市民開発の体制の作り方は、市民開発を安全に広げる体制の記事で扱っています。ここからは、1つのエージェントが広がる段階を追いながら、見張る道具が何を担えるかを見ていきます。

段階1 作る：作った瞬間に一覧に載るか

営業部の社員が、問い合わせへの返信の下書きを作るエージェントを Copilot Studio で作った、という場面から始めます。最初に起きる問題は、情シスがその存在を知らないことです。届け出の制度があっても、試しに作っただけのエージェントは届け出されません。

見張る道具が最初に担うのは、この「見つける」仕事です。Zenity の公式サイトは、見える化の働きとして、どのエージェントがあり、誰が持ち主かを示すと説明しています。届け出を待たずに、作られた時点で一覧に載ることが、統制の出発点になります。

さらに、Copilot Studio 向けの公式ページでは、作る段階で安全の制約をかけ、権限の広すぎる接続を防ぎ、安全な接続の使い方を求めると書かれています。ただし、一覧に載っただけでは判断はできません。そのエージェントが何のためのもので、業務にどれだけ影響するかは、作った人に聞かなければ分からないからです。一覧を判断の材料に変えるのは人の仕事です。

一覧に新しいエージェントが載ったときに作った人へ聞くことは、3つに絞ると負担になりません。何の仕事を楽にするためのものか、誰に使わせるつもりか、どの情報を読ませ、どこに書かせるつもりか、です。回答は一覧の行に書き足し、業務への影響の大きさで3段階ほどに分けておくと、以降の段階で見張る強さを変えられます。聞き取りの質問文の下書きや、回答の要約はAIに任せてもかまいません。

段階2 つなぐ：接続と資格情報で危なさが決まる

返信の下書きを作るエージェントは、作った社員の工夫で、顧客管理の記録を読み、メールを送れるように育っていきます。危なさが大きく変わるのはこの段階です。読むだけのエージェントと、外にメールを送れるエージェントでは、起きうる事故の大きさが違います。

Zenity の Copilot Studio 向けのページでは、エージェントの構成とやり取りを「ステップ」に分けて記録し、操作・処理の流れ・起動の条件・データの参照を捉えると説明しています。どの接続を使い、何を読んで、何に書くのかが見えれば、読むだけのエージェントと、外に出せるエージェントを分けて扱えるようになります。

この段階で人が決めておくのは、どの接続の組み合わせを危ないと見なすかの基準です。たとえば、顧客の個人情報を読めて、かつ社外にメールを送れるエージェントは、自動的に確認の対象にする、といった形です。接続の権限を誰の資格で持たせるかの設計は、同じ便の Arcade の記事で扱っています。見張る道具は、基準に当たるエージェントを挙げるところまでを担います。

段階3 共有する：部署から全社へ広がると範囲が変わる

便利なエージェントは、作った人の手を離れて共有されます。最初は営業部の数人だったものが、営業部全体、さらに他部署へと広がります。共有されるたびに、エージェントを呼び出せる人と、エージェントが読める情報の組み合わせが変わります。

ここで起きやすいのが、作った人には見えてよかった情報が、共有された相手にも見えてしまうことです。作った人の資格で記録を読むエージェントを全社に共有すると、本来その記録を見られない社員も、エージェント経由で中身を知ることができてしまいます。Zenity の公式ページに載る導入企業の声でも、過剰に共有された資源の発見が挙げられています。

見張る道具は、共有の範囲と読める情報の組み合わせから、こうした形を見つける手がかりを出せます。ただし、その共有が業務に必要なのか、うっかりなのかは道具には分かりません。共有の範囲を広げる前に、情報の持ち主の部署が確認する、という線を人が引いておく必要があります。

段階4 動かす：実行中の道具の呼び出しで止める

全社で使われ始めたエージェントは、毎日、多くの文章を読み、道具を呼び出します。この段階の危なさは、設定ではなく実行中に起きます。受け取ったメールに紛れた指示でエージェントが乗っ取られ、読めるデータを社外に送ろうとする、といった形です。指示の乗っ取りの仕組みそのものは、AIが外部の指示に乗っ取られる原因と対策の記事に譲ります。

Zenity の発表は、この段階での制御を強みとしています。2025年9月の発表では、MCP サーバーや CRM、メールへの道具の呼び出しに制御をかけ、操作が完了する前に止めると説明しています。2026年8月の発表でも、操作の前に許可・変更・遮断を決める仕組みとしています。危ない呼び出しを、完了する前に止められることが、作る前の審査では担えない部分です。

一方で、実行中に止める仕組みは、止めすぎると業務が止まります。正当な社外へのメールを持ち出しと誤って判定すれば、営業の返信が届きません。導入の初期は、止めずに警告だけを出す期間を置き、誤って止める形がどれだけあるかを数えてから、止める範囲を広げていくのが現実的です。

公式ページでは、実行中の見張りが、外部からの攻撃だけでなく、悪意のある利用者や不審な内部者の振る舞いの検知も対象にすると説明されています。見る材料として、判断の流れ、道具の呼び出しの型、記憶の書き換え、エージェント同士のやり取りが挙げられています。つまり、社員がエージェントを使って本来見られない情報を集めようとする動きも検知の対象になりえます。この点は、後で触れる社員への説明の内容と合わせて決めておく必要があります。

段階5 作った人が異動・退職する：持ち主のいないエージェント

最後の段階は、エージェントが使われ続けたまま、作った人がいなくなることです。異動や退職のあと、エージェントは作った人の資格や設定のまま動き続けることがあります。誰も中身を説明できないのに、業務がそのエージェントに頼っている、という形です。

Zenity が見える化の項目に「誰が持ち主か」を入れているのは、この段階のためです。一覧に持ち主の欄があれば、人事の異動の情報と突き合わせて、持ち主のいないエージェントを洗い出せます。洗い出したあとに、引き継ぐか、止めるかを決めるのは人です。

引き継ぎの判断では、そのエージェントを使っている人の数、読んでいる情報の重さ、止めたときに困る業務を見ます。持ち主が決まらないエージェントは、使われていても期限を切って止める、という原則を先に決めておくと、判断が属人的になりません。止める前には利用者に知らせ、代わりの手段を案内します。

突き合わせの周期は、人事の異動の発令に合わせるのが分かりやすい方法です。4月や10月の異動の時期に、一覧の持ち主の欄と異動・退職の名簿を照らし合わせ、持ち主が部署を離れたエージェントを洗い出します。名簿との照合はAIや表計算の処理に任せられますが、引き継ぎ先の候補を決めるのは、そのエージェントを使っている部署の上長です。

見張る道具で担えること・担えないこと

5つの段階を通して見ると、見張る道具が担えることと、担えないことがはっきりします。公式で確かめた働きをもとに、段階ごとに分けると次のようになります。

段階	道具で担えること	道具では担えないこと（人が判定）
作る	作られたエージェントを見つけて一覧に載せる	何のためのものか、業務への影響の大きさ
つなぐ	接続・データの参照・処理の流れを記録し、広すぎる権限を指摘する	どの接続の組み合わせを危ないと見なすかの基準
共有する	共有の範囲と読める情報の組み合わせから候補を出す	その共有が業務に必要かどうか
動かす	実行中の道具の呼び出しを見て、完了前に止める・警告する	止めた操作が正当だったかの最終判断と例外の承認
いなくなる	持ち主の欄から、持ち主のいない候補を挙げる	引き継ぐか止めるか、利用者への知らせ方

表の右の列は、どれも業務の事情を知らないと決められないことです。道具を入れると左の列は自動になりますが、右の列の担当が決まっていなければ、警告の一覧が積み上がるだけになります。製品を選ぶ前に、右の列を誰が持つかを決めておくことをおすすめします。

誰が判定するか：検知は道具、止めるかは人

見張る道具が出す警告は、そのままでは判断になりません。判定の担当を決めるときは、警告の種類で分けると回しやすくなります。設定の不備（広すぎる権限、危ない接続）は情シスが判定し、作った人に直してもらう。共有の範囲の問題は、情報の持ち主の部署が判定する。実行中に止めた操作は、情シスと業務の担当が一緒に見て、正当なら例外にする、という分け方です。

判定に使う基準は、警告が出る前に文書にしておきます。1件ずつ議論していると、同じ種類の警告に違う判定が出て、作った人の不満が増えます。AIに任せてよいのは、警告の要約、似た警告のまとめ、過去の判定の検索までです。止めるかどうかの判定そのものを、AIに任せないことが前提になります。

判定の結果は、見張る道具の側の設定に戻します。正当と判定した操作が毎回止まるなら、方針を直します。逆に、警告だけにしていた形で実際に問題が見つかったら、止める側に移します。判定の結果を道具の設定に戻す周期を決めておくと、誤って止める件数が少しずつ減っていきます。

判定のたびに、警告の内容、判定した人、判定の結果と理由、作った人へ返した内容を1行ずつ残しておきます。この記録があれば、担当者が替わっても同じ基準で判定でき、監査で「なぜ止めたのか、なぜ止めなかったのか」を問われたときにも説明できます。記録の項目は、見張る道具の側に書けるのか、社内の別の台帳に書くのかを、導入の前に決めておきます。

自動で直す設定を、どこまで許すか

Zenity の Copilot Studio 向けのページでは、検知の結果を自動の対応手順につなげ、すぐに抑える働きが案内されています。導入企業の声には、危険度の高い違反が自動で直されたという記述もあります。自動で直せれば判定の担当の負担は減りますが、許す範囲は慎重に決める必要があります。

自動で直してよいのは、直しても業務が止まらず、元に戻せる変更に限るのが目安です。たとえば、社外に公開されていた共有を社内に戻す、使われていない接続を止める、といった変更です。一方、エージェントそのものを止める、接続の権限を大きく削る、といった変更は、業務を止めるおそれがあるため、人の判定を挟みます。

自動で直したときは、必ず作った人に知らせます。知らせずに直すと、作った人は理由が分からないまま同じ設定に戻し、いたちごっこになります。何を、なぜ直したのか、どう作れば次から止まらないのかを短く返す形にしておくと、作った人の側で同じ不備が減っていきます。

作った人に返す情報の形

市民開発を止めない統制の要は、作った人を処罰の対象にしないことです。社員がエージェントを作るのは、多くの場合、目の前の仕事を楽にしたいからです。警告のたびに上長に報告されるなら、社員は見張りの届かない道具でこっそり作るようになります。

作った人に返す情報は、3つの要素に分けると伝わりやすくなります。何が見つかったのか（例：顧客の個人情報を読めて、社外にメールを送れる）、なぜ危ないのか（例：受け取ったメールの指示で、個人情報を外に送らされるおそれがある）、どう直せばよいのか（例：送信先を社内に限るか、送信の前に人の確認を入れる）、です。

さらに、よくある不備と直し方を、社内の手引きにまとめておきます。見張る道具の検知の結果を数か月分集めると、社内でよく起きる不備の形が見えてきます。検知の結果を、作る人の教材に変えることが、統制と市民開発を両立させる近道です。手引きの下書きをAIに作らせるのはよい使い方ですが、載せる内容は情シスが確かめます。

社員の作ったものを見張ることの説明

見張る道具は、エージェントの設定だけでなく、エージェントとのやり取りや、エージェントが読んだデータの使い方も見ます。社員から見ると、自分の作ったものと、自分がエージェントに頼んだ内容が会社に見られている、と受け取られることがあります。

導入の前に、何を見ていて、何のために見ていて、誰が見るのかを社員に説明しておきます。見ているのはエージェントの設定と道具の呼び出しであり、社員の評価に使うものではないこと、検知の記録を読む人を限っていることを、社内の規程と合わせて示します。記録にどこまでやり取りの中身が残るのか、どれだけの期間残るのかは、製品の設定と契約で確かめ、説明と食い違わないようにします。

説明を省くと、見張りは社員の監視として受け止められ、エージェントを作る意欲そのものが下がります。見張りの目的を、作ったものを安全に全社に広げるため、と位置づけることが、市民開発を止めない統制の前提になります。

導入の順番と、対象の広げ方

見張る道具は、最初から全社の全エージェントにかけるより、段階を踏んで広げるほうが判定の担当が回ります。公式の発表では、Copilot・ChatGPT Enterprise・Gemini から、コーディングエージェント、自社で作るエージェントまで対象が広いことが示されていますが、社内で一度に全部を扱う必要はありません。

費用は金額ではなく増え方で見ておきます。見張る対象のエージェントの数、対象にする基盤の数、検知の結果を判定する人の時間のどれが増えるかで、全社に広げたときの姿が変わります。とくに判定の人の時間は、製品の見積もりには出てこない費用なので、試用の期間に1週間あたりの警告の件数と判定にかかった時間を数えておきます。

入れる前に考えたい、やりがちな失敗

見張る道具を入れても、次の形が残っていると統制は回りません。導入を検討する段階で、当てはまるものがないかを確かめてください。

• 道具を入れれば統制が終わると考え、警告を判定する担当を決めていない
• 最初から実行中の制御を全面的に止める設定にして、正当な業務まで止めてしまう
• 自動で直す範囲を広く取り、作った人に理由を知らせずに設定を戻している
• 見張っていることを社員に説明せず、監視だと受け止められている
• 持ち主のいないエージェントを見つけても、引き継ぐか止めるかの原則がない
• 各基盤の標準の管理機能でできることを確かめずに、重ねて製品を入れている

最後の項目は、入れない選択肢とも関わります。社員が使う基盤が1つだけで、作られるエージェントの数も少ないなら、まずは基盤に付いている管理の機能で一覧と権限を見るところから始めても遅くはありません。複数の基盤にエージェントが散らばり、実行中の動きまで見る必要が出てきたときが、Zenity のような横断の道具を検討する時期です。

まとめ

Zenity は、社員が作ったAIエージェントを見つけて一覧にし、設定の不備と実行中の危ない操作を検知・停止する、エージェント専用の安全と統制の基盤です。2026年8月に1億2,500万ドルの資金調達を、10月に日本市場への展開を発表しましたが、日本語でのまとまった解説はまだほとんどありません。1つのエージェントは、作る・つなぐ・共有する・動かす・作った人がいなくなる、の5段で広がり、段ごとに見張る点が変わります。道具が担えるのは、見つける・記録する・候補を挙げる・完了前に止めるところまでです。業務への影響、危ない組み合わせの基準、共有の要否、止めた操作の正否、引き継ぐか止めるかは、人が判定します。まずは、社内で社員がエージェントを作っている基盤を書き出し、その一覧を誰が見て判定するかを決めるところから始めてみてください。

• 製品の機能・対象・資金調達・日本市場への展開の内容は、Zenity の公式サイト、公式ニュースルーム、公式ブログを2026年10月15日に確かめた範囲に基づきます。機能や提供の範囲は変わることがあるため、導入前に最新の原文と販売の窓口で確かめてください
• Copilot Studio との連携は2025年9月の発表時点で公開プレビューとされていました。現在の提供の状態は提供元に確かめてください

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