Aembit：社員のAIに鍵を貸すか分けるか｜本人の権限か専用のIDか

「営業の担当者が、自分で契約したAIエージェントに顧客管理の画面を読ませて、商談の準備をさせているらしい」「便利なのは分かるが、そのエージェントが本人のログインのまま社内の何にでも触れる状態を、情シスとして認めてよいのか」——生成AIの利用が個人単位で広がった会社の情シスとマーケの間で、こうしたやり取りが増えています。問われているのは、エージェントを使うかどうかではありません。エージェントに社員本人の鍵を貸すのか、エージェント専用の鍵を分けて渡すのかという、鍵の渡し方の選択です。この記事では、米国の Aembit が2026年10月に対応を発表した「社員個人のAIエージェント」の社内アクセスを題材に、二つの方式を比べ、エージェントだけを止められる体制と、情シスの棚卸しの進め方を整理します。

Aembit は、人以外の利用者の出入りを管理する製品

Aembit は、社員のような人ではなく、業務のプログラムやAIエージェントが社内外のシステムに接続するときの身元確認と権限を管理する製品です。公式は自社を「AIエージェントと業務プログラムのための身元の管理の中枢」と説明しています。配信リリースの発信地は米国メリーランド州シルバースプリングで、共同創業者のデビッド・ゴールドシュラグ氏が最高経営責任者を務めています。日本語の紹介はまだごく少なく、国内ではエージェントの権限管理を調べている情シスの担当者の間で名前が出始めた段階です。

公式の製品説明によれば、仕組みは大きく三つに分かれます。方針を定めて判定する管理の中枢（Aembit Cloud）、接続の要求を途中で受け取って鍵を差し込む部品（Aembit Edge）、そしてAIエージェントの持つ通行証を MCP の接続先用の資格に引き換える関所（公式の呼び名は MCP Identity Gateway）です。どれも、エージェント自身には本物の鍵を持たせず、使う瞬間に必要な分だけ渡すという考え方でつくられています。

接続先として公式が挙げているのは、Salesforce、Snowflake、BigQuery、Redshift、Microsoft Graph などで、エージェント側では Claude、OpenAI、Gemini、LangChain などとの組み合わせが示されています。鍵を短命で発行するほか、既存の鍵の保管庫（Azure の保管庫や HashiCorp Vault）から取り出す使い方もできるとされています。マーケが日常的に使う顧客管理とデータ基盤が、どちらも接続先の例に入っている点が、この記事でこの製品を取り上げる理由です。

2026年の発表：7月の Snowflake 連携と、10月の個人エージェント対応

直近の動きは二つあります。一つ目は7月28日に発表された Snowflake との連携です。配信リリースによれば、社外の道具のAIエージェントが Snowflake のデータに接続するときに、利用者とエージェントの両方の身元を保ったまま、一元的に管理する方針を当て、エージェントの接続を実行中の作業に必要な範囲に限るものです。長く使える鍵をなくすことも狙いとして挙げられています。Snowflake の最高セキュリティ・信頼責任者も、エージェント同士の相互運用の土台になるとコメントしています。提供の段階や時期は、このリリースでは明示されていません。

二つ目が10月6日の発表で、社員個人のAIエージェントが社内の環境に接続するときの保護に対応しました。対象として、Meta が発表した個人向けエージェントを筆頭に、Microsoft の Copilot Studio、Claude、ChatGPT、Gemini、自社で作った生成AIの処理の流れが挙げられています。既存の顧客は追加費用なしで、新しい製品の導入もなく使えると説明されています。

同じ日の公式ブログで、ゴールドシュラグ氏は「個人のAIエージェントは、かつて個人の端末がそうだったのと同じ理由で企業に入り込んでくる」と書いています。私物の端末の業務利用を禁止しきれなかった経験を踏まえ、禁止ではなく、入ってくる前提で鍵の渡し方を設計するという立場です。この記事も同じ前提に立ち、使わせるかどうかではなく、使わせる場合の方式を比べます。

いま起きていること：個人のエージェントは本人の許可で動いている

10月の配信リリースは、個人のエージェントがメール、業務の道具、ソースコードの置き場、社内の道具などに、社員の資格と委任された権限で接続していると指摘しています。典型的なのは、社員が自分のエージェントに「顧客管理を読んでよい」と画面で許可を出す形です。このとき裏では、本人の権限を委ねる許可（OAuth の許可）がエージェントの提供元に渡ります。公式ブログはこれを、情シスが発行しておらず、簡単には取り消せない資格をエージェントが持っている状態と表現しています。

リリースが挙げる危険は三つです。機密のデータが外に出ること、許可していない変更が加えられること、そしてエージェントの動きが社員本人の操作と見分けられないことです。加えて、資格がエージェントの提供元の基盤に保管され、情シスの管理の外に置かれる点も指摘しています。社員が退職したり、エージェントの提供元で事故が起きたりしたとき、どの資格がどこに残っているかを情シスが把握できていない、ということになります。

社員のIDをエージェントに貸さないという一般論や、鍵の保管の原則は別の記事で扱っているため、ここでは繰り返しません。この記事で考えたいのは、社員がすでに個人でエージェントを使い始めている状況で、情シスがどちらの方式を選び、どう移行するかです。理想の形を最初から作るのではなく、いま本人の権限で動いているものをどう扱うかが現実の問題です。

比べる二つの方式：本人の権限を貸すか、エージェント専用のIDを分けるか

一つ目の方式は、本人の権限を丸ごと貸す方式です。社員がエージェントに自分のログインや委任の許可を与え、エージェントは本人と同じ範囲で社内システムに触れます。追加の仕組みは要らず、社員が自分で設定できるため、始めるのは簡単です。現在、多くの会社で起きているのはこの形です。

二つ目の方式は、エージェント専用のIDを分ける方式です。Aembit の10月の説明では、個人のエージェントは借りたログインではなく、特定の社員のために動く独立したエージェントとして登録されるとされています。要求のたびに、エージェントの身元、代わりに動いている社員、求めている操作の三つを確かめ、その作業だけに使える鍵を発行し、作業が終われば失効させます。公式はこれを、エージェント自身の身元と、代理している社員の身元を組み合わせた「混ぜ合わせた身元」と呼んでいます。

二つの方式は、どちらが絶対に正しいというより、何をどこまで許すかで選び分けるものです。社内の予定表を読ませるだけなら本人の権限で十分な場合もありますし、顧客管理の書き換えやデータ基盤の大量の読み出しを許すなら、専用のIDを分けないと管理しきれません。以下では、比べる軸を五つに分けて見ていきます。

比較軸1：記録に「誰が」残るか

本人の権限を貸す方式では、エージェントの操作は記録の上で本人の操作として残ります。顧客管理で商談の金額が書き換わったとき、本人が手で直したのか、エージェントが直したのかを記録から区別できません。監査や事故の調査で「この操作は誰の判断か」を問われても、答えようがなくなります。

専用のIDを分ける方式では、記録に「どのエージェントが、誰のために、何に触れ、どの方針で許可されたか」が残ります。Aembit の公式ブログの本文と配信リリースは、判定の記録を一元的に残すと説明しています。製品説明では、許可・拒否の判定ごとに理由付きで記録が残り、方針や利用者の変更も管理の記録として残るとされ、外部の監視基盤（Snowflake など）に書き出せると書かれています。

なお、同じ公式ブログのよくある質問の欄には、記録の有無について本文と食い違うように読める回答が載っていました。どの操作がどの粒度で記録され、どれだけの期間保存されるかは、導入前に自社の契約で確かめてください。記録は、残っていることよりも、誰が定期的に見るかのほうが重要です。見る人を決めない記録は、事故のあとにしか開かれません。

比較軸2：触れる範囲を作業の分だけに狭められるか

本人の権限を貸す方式では、エージェントが触れる範囲は本人の権限と同じです。営業の担当者が顧客管理の全件を見られるなら、エージェントも全件を見られます。商談の準備に要るのは担当している数社の情報だけでも、エージェントは全件を読み出せる状態にあります。外から紛れ込んだ指示でエージェントがだまされた場合、被害の範囲は本人の権限の全体になります。

専用のIDを分ける方式では、エージェントの範囲を本人とは別に決められます。Aembit の製品説明では、方針は実行時に、エージェント、利用者、求める接続先、そのときの条件を見て判定されるとされ、条件には端末の安全性の状態、時間帯、接続元の地域などを使えると説明されています。端末の状態は CrowdStrike や Wiz の情報を判定の材料にできるとされています。本人には許しても、エージェントには許さない操作を作れるのが、この方式の利点です。

ただし、範囲を狭めるには「エージェントに何をさせたいか」を先に言葉にする必要があります。読むだけなのか、書き換えるのか、どの項目までか。ここが決まっていないと、結局は本人と同じ範囲を許すことになり、分けた意味がなくなります。範囲の案はエージェントの利用を申し出た部署に作らせ、データの持ち主（顧客管理なら営業企画、データ基盤ならデータ担当）が承認する形にすると、情シスだけで抱え込まずに済みます。

比較軸3：エージェントだけを止められるか

本人の権限を貸す方式で、エージェントの挙動がおかしいと気づいたとき、情シスができることは限られます。委任の許可を取り消すには、社員本人に操作を頼むか、本人のアカウントを止めるしかないことが多く、エージェントを止めると本人の仕事も止まるという状態になります。結果として、怪しいと思っても止める判断が遅れます。

専用のIDを分ける方式では、エージェントの接続だけを取り消せます。Aembit の公式ブログは、エージェントの接続を単独で取り消すと、次の要求からはどこでも拒否される一方、社員のログインと仕事には影響しないと説明しています。配信リリースでもゴールドシュラグ氏は、エージェントに独自の身元を与え、届く範囲を管理し、社員をオフラインにせずにエージェントを止めることを要点に挙げています。

止められる仕組みがあっても、誰が止める判断をするかが決まっていなければ使われません。止める判断の基準（記録に不審な大量の読み出しがある、本人が身に覚えのない書き換えがある、エージェントの提供元で事故が公表された、など）と、判断できる人、止めたことを本人に知らせる手順を先に決めます。止めたあとに再開する条件も、あわせて決めておきます。

比較軸4：異動と退職のときに鍵が残らないか

本人の権限を貸す方式では、異動や退職のたびに問題が起きます。マーケから営業に異動した社員のエージェントは、新しい部署の権限をそのまま引き継ぎます。退職した社員のアカウントを止めても、エージェントの提供元に残った委任の許可が有効なままになっていないかは、提供元ごとに確かめる必要があります。社員がいくつのエージェントに許可を出していたかを、情シスは把握していないことがほとんどです。

専用のIDを分ける方式では、エージェントは特定の社員のために動くものとして登録されるため、社員の異動や退職をエージェントの見直しの合図にできます。さらに、Aembit の説明では、エージェントは常時使える資格を持たず、要求のたびに短命の鍵を受け取るため、提供元の基盤に長期間有効な鍵が残る状況そのものを減らせるとされています。

ここで情シスが決めておきたいのは、人事の異動・退職の連絡を、エージェントの棚卸しにつなぐ流れです。社員のアカウントの停止と同じ日に、その社員のために登録されたエージェントを止める。異動の場合は、新しい部署で同じエージェントを使い続けるかを本人と上長に確かめ、範囲を作り直す。人の入退社の手順に、エージェントの項目を一行足すだけで、残った鍵の多くは防げます。

比較軸5：鍵がどこに置かれ、何が社外に出るか

本人の権限を貸す方式では、委任の許可や鍵はエージェントの提供元の基盤に置かれます。10月の配信リリースも、資格がエージェントの基盤に保管され、情シスの管理の外になることを危険として挙げています。加えて、エージェントが顧客管理から読み出したデータは、エージェントの提供元の処理を通ります。顧客の担当者名や商談の金額が、どの提供元のどの契約のもとで扱われるかは、エージェントの種類ごとに違います。

専用のIDを分ける方式でも、エージェントが読んだデータがエージェントの提供元を通る点は変わりません。Aembit が変えるのは鍵の置き場所と発行の仕方であり、読み出したデータがその後どこに行くかまでは管理しないことを押さえておく必要があります。公式ブログの説明では、エージェントは接続先に直接つながらず、Aembit の関所か既存の関所を通るとされていますが、関所を通った後のデータの扱いはエージェントの提供元の契約次第です。

したがって、顧客の個人情報を含む顧客管理を個人のエージェントに読ませるなら、鍵の方式とは別に、エージェントの提供元が学習に使わない契約か、会話の記録がどれだけ保存されるか、海外のどこで処理されるかを確かめます。個人情報保護法の委託や外国にある第三者への提供の扱いは、自社の法務と個人情報の担当に判断してもらう項目です。鍵を分けても、データの扱いの判断は省略できません。

二つの方式を並べると：どの業務でどちらを選ぶか

ここまでの五つの軸を、表にまとめます。どちらの方式も、社員が個人で選んだエージェントを社内システムにつなぐ前提で比べています。

比較の軸	本人の権限を貸す方式	エージェント専用のIDを分ける方式
始めやすさ	社員が自分で設定でき、すぐ始められる	情シスの登録と方針づくりが要る
記録	本人の操作と区別できない	どのエージェントが誰のために何をしたかが残る
触れる範囲	本人の権限の全体	作業ごとに狭められる
止め方	本人のアカウントごと止めることが多い	エージェントだけを取り消せる
異動・退職	提供元に許可が残りやすい	社員の異動を見直しの合図にでき、常時有効な鍵を持たせない
データの行き先	エージェントの提供元を通る	同じく提供元を通る（鍵の方式では変わらない）

選び分けの目安は、エージェントに許す操作の重さです。社員本人の予定表やメールの下書きなど、本人の範囲で完結し、他人のデータを扱わないものは、本人の権限を貸す方式でも管理しきれる場合があります。一方で、顧客管理の商談の書き換え、データ基盤の顧客データの読み出し、ソースコードの置き場への変更などは、他人のデータや会社の記録に触れるため、専用のIDを分ける側に寄せるのが妥当です。

迷うのは、読むだけだが対象が広いもの、たとえば顧客管理の全件を読んで傾向を分析させる使い方です。読むだけでも、外から紛れ込んだ指示で読み出した内容を外に送られる危険があるため、件数や項目を絞れない限りは専用のIDの側で扱います。本人の権限で始めたものを、対象が広がった時点で専用のIDに移す、という段階的な移行も現実的な選択です。

顧客管理とデータ基盤では、決める人が違う

マーケと営業の現場で個人のエージェントがつながりたがる先は、主に顧客管理（Salesforce や HubSpot）とデータ基盤（Snowflake や BigQuery）です。この二つは、データの持ち主も、事故のときの影響も違います。顧客管理は営業の記録そのもので、書き換えられると予測や評価に直結します。データ基盤は量が大きく、読み出しだけでも漏えいの規模が大きくなります。

顧客管理については、エージェントに書き換えを許すかどうかを営業企画が決め、許す場合も項目を絞り、書き換えの前に本人の確認を挟むのが基本です。商談の金額と段階は、エージェントに書き換えさせないと決めている会社も少なくありません。データ基盤については、データ担当が、エージェントに読ませてよい表と項目を決め、個人を特定できる列を除いた見え方を用意するのが一般的です。7月の Snowflake との連携は、まさにこの、社外のエージェントのデータ基盤への接続を作業の範囲に限る話です。

どちらの場合も、情シスは仕組みを用意する側、データの持ち主は範囲を決める側と役割を分けておくと、申請が情シスに滞留しません。Aembit のような製品が受け持つのは、決められた範囲を実行時に当てはめることであり、範囲そのものを決めることではありません。

Aembit に任せられることと、人が決めること

ここで、製品に任せられることと任せられないことを整理しておきます。Aembit の公式説明から読み取れる範囲では、任せられるのは、エージェントの身元の確認、代理している社員との結び付け、方針に基づく許可と拒否の判定、作業ごとの短命の鍵の発行、判定の記録、そしてエージェント単位での取り消しです。これらは、人が毎回手で行うのは現実的でない作業です。

一方で、人が決めなければならないのは、どの社員にどのエージェントの利用を認めるか、エージェントに何をさせるか、どのデータに触れさせるか、記録を誰がいつ見るか、どんなときに止めるか、です。AIに判断させてはいけない部分でもあります。方針の中身をAIに作らせる場合も、案として扱い、データの持ち主が根拠を確かめてから承認するようにします。

• Aembit が管理するのは鍵の渡し方であり、エージェントの出力の正しさや、読み出したデータの社外での扱いは管理の対象外
• エージェントの提供元によって、登録の仕方や対応の範囲が異なる。自社で使われているエージェントが対応しているかは個別に確かめる
• 製品の対応範囲は発表のたびに広がっている。導入の検討時点の公式の説明を確かめる

情シスの棚卸し：いま本人の権限で動いているものを洗い出す

どちらの方式を選ぶにしても、最初にやるべきは、すでに本人の権限で動いているエージェントの洗い出しです。社員が個人で許可を出したエージェントは、情シスの台帳に載っていないことがほとんどです。次の順番で進めると、業務を止めずに移行できます。

棚卸しは一度で終わりません。四半期に一度、許可の一覧を取り直して差分を見ることを決めておきます。新しい個人向けエージェントは次々に発表されているため、前回の棚卸しになかったものが必ず出てきます。差分が出たら、同じ手順で仕分けます。

費用、提供状況、やめるとき

10月の個人エージェントへの対応は、既存の顧客には追加費用なしで提供されると発表されています。公式の製品説明には料金の案内のページへの導線があり、無期限で使える無料の利用枠があること、営業との面談なしで利用の環境を作れることが書かれていますが、規模ごとの料金はこの調査では確かめられませんでした。費用は、エージェントの数や接続先の数でどう増えるかを、見積もりの段階で確かめる必要があります。

費用を考えるときは、製品の料金だけでなく、方針を作り、記録を見る人の時間を数えます。専用のIDを分ける方式は、本人の権限を貸す方式より明らかに手間がかかります。その手間は、エージェントだけを止められること、誰がやったかを答えられることへの対価です。エージェントの利用が数人の試験段階なら、まずは対象を顧客管理とデータ基盤の二つに絞って始めると、手間を抑えられます。

やめるときは、Aembit の関所を外すと、エージェントは接続先に届かなくなります。やめた後に本人の権限を貸す方式に戻すと、記録と停止の利点は失われます。やめる場合は、エージェントの接続そのものをやめるか、別の方法で専用のIDを維持するかを先に決めておくことが大切です。製品に依存しないよう、方針の中身（誰に何を許したか）は、製品の外にも台帳として残しておきます。

方式を決める前のチェックリスト

最後に、二つの方式のどちらを選ぶかを決める前に、社内で答えておきたい問いをまとめます。すべてに答えが出ていれば、方式の選択は自然に決まります。

• 社員が個人で使っているエージェントと、出している委任の許可の一覧があるか
• エージェントに許す操作が、読むだけか、書き換えるかを業務ごとに言えるか
• 顧客管理とデータ基盤のそれぞれで、範囲を決めるデータの持ち主が決まっているか
• エージェントの操作を本人の操作と区別して記録に残す必要があるか（監査・取引先との契約）
• エージェントだけを止める判断の基準と、判断できる人が決まっているか
• 人の異動・退職の手順に、エージェントの見直しが入っているか
• エージェントの提供元が、読み出したデータを学習に使わない契約か、記録の保存期間はどうか
• 記録を誰が、どの頻度で見るかが決まっているか

• 個人のエージェントを全面禁止にし、実態の把握をやめてしまう
• 専用のIDを分けたのに、範囲を本人と同じにして意味をなくす
• 移行後に、本人の権限で出していた古い許可を取り消さない
• 記録を残すだけで、誰も見ない

まとめ

社員個人のAIエージェントは、私物の端末と同じように、禁止しても入ってきます。Aembit は2026年10月、そうしたエージェントに社員と結び付いた独自の身元を与え、作業ごとの短命の鍵と実行時の判定で社内システムへの接続を許し、エージェントだけを止められる仕組みへの対応を発表しました。本人の権限を丸ごと貸す方式は始めやすい反面、記録・範囲・停止・異動のすべてで本人とエージェントを切り離せません。他人のデータや会社の記録に触れるエージェントは、専用のIDを分ける側に寄せるのが基本の考え方です。製品が受け持つのは鍵の渡し方までで、誰に何を許し、いつ止めるかは人が決めます。まずは、いま本人の権限で動いているエージェントの棚卸しから始めてください。

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