Gemini agentとClaude Code、情シスから見た管理の仕組みの違い。公式ドキュメントから整理

「AIエージェントを入れたいと言われたけれど、情シスとしてどこを見れば判断できるのか」という相談が増えてきました。
Googleが2026年10月8日（米国時間）に発表した仕事用のAIエージェント「Gemini agent」は、まさにその判断が必要になる製品です。

今回は、情シスやAI推進担当の目線で、Gemini agentの管理の仕組みを整理します。
比べる相手は、すでに社内で使っている会社も多いClaude Codeです。
どちらも公式のドキュメントに書かれていることを引用し、2026年10月9日時点の情報でまとめています。

先にお断りしておくと、Gemini agentはまだプライベートプレビューの段階で、筆者も実際には触れていません。
この記事では、公式ドキュメントに書かれている仕組みを比べます。

Gemini agentで何ができるのかは、Googleが「Gemini agent」を発表。何ができるのか、自分のメールアドレスを持つ「coworker agent」まで整理しましたにまとめています。

Gemini agentには「本人の代わり」と「自分の名義」の2つの働き方がある

安全面を見る前に、Gemini agentの働き方を整理しておきます。

公式ブログ（Google Cloud Blog：Gemini at Work 2026）には、エージェントが3つの形で出てきます。

1つ目は、自分が入力欄から頼む、自分用のGemini agentです。
自分の代わりに、自分が見られる情報を使って仕事をします。
2つ目は、手順の多い仕事のためにGemini agentが自動で作るサブエージェントで、その仕事が終わればいなくなります。

3つ目が、「coworker agent」です。
必要な役割を文章で説明すると作られ、チームの同僚として何日も働きます。
日本語の公式の呼び方はまだ出ていないので、ここでは英語のまま書きます。

coworker agentには、人の社員と同じように専用のWorkspaceアカウントが用意されます。
メールアドレス、カレンダー、ドライブを持ち、社内の名簿にも載ります。
チームのメンバーは、Chatのスペースに追加したり、@メンションしたりして仕事を頼みます。
見られるのは、共有されたものだけです。

つまり、自分用のGemini agentは「本人の代わり」に動き、coworker agentは「エージェント自身の名義」で動きます。
この違いが、次の章の話につながります。

エージェントが「誰として」動くかが、いちばん大きく違う

両者を並べると、まずエージェントが誰の名義で動くかの違いが目に付きます。

Claude Codeは、使っている人のPCの上で、その人の権限のまま動きます。
公式のセキュリティのページには、「承認したBashのコマンドは、そのユーザーアカウントが書き込める場所ならどこにでも書き込める」と書かれています（筆者訳。Claude Code Docs：Security）。

作業するフォルダの中だけに閉じて動くわけではなく、一度承認したコマンドは、本人ができることなら何でもできるという意味です。
そのため、後で書く「何を承認するか」の設定が大事になります。

決まった時間に自動で動かす「routines」も同じです。
つないだGitHubやコネクタを通してやったことは、「あなたがやったものとして表示される」とされています（Claude Code Docs：Routines）。

一方のGemini agentは、エージェントごとに専用のIDを持ちます。
土台になっているGoogle Cloudの「Agent Identity」のドキュメントでは、エージェントは複数で使い回す共有アカウントではなく、1体ずつ固有のIDを持つと説明されています。
ユーザーの代わりに動いたときは、記録に「エージェントと本人の両方のID」が残ります（Google Cloud：Agent Identity overview）。

coworker agentの場合は、さらにはっきりしています。
公式ブログでは、ドキュメントのコメントでcoworker agentをタグ付けすると、エージェントが文書に修正案を出す例が紹介されています。
その変更は、変更履歴にエージェント自身の名前で残ります。

人の操作とAIの操作を、記録の上で分けられるかを確かめる

情シスの目線で言えば、ここは「誰がやったのか」が記録の上で分かれるかどうかの違いです。
分かれていれば、何か起きたときに、人がやったのか、エージェントがやったのかを後から追えます。

AIが仕事を進める場面が増えるほど、ある変更を人がやったのか、AIがやったのかの見分けはつきにくくなっていきます。
どこまでが人の判断で、どこからがAIの作業だったのかを追えないと、問題が起きたときの調べ方としても、責任の所在としても困ります。

その意味で、変更履歴や操作の記録にエージェントの名前が残る仕組みは、法人が使うAIでは今後の主流になっていくと考えています。
AIを導入するときの確認項目にも、「AIの操作を人の操作と分けて記録できるか」を入れておくとよいと思います。

管理の仕組みを、8つの項目で並べる

それぞれの公式ドキュメントに書かれていることを、項目ごとに並べました。

Gemini agentは実機で確かめていないので、表の左側は公式ドキュメントの記載です。
ここからは、それぞれの中身を順に見ていきます。

Gemini agentは、許可しない限りどこにもつながらない

Gemini agentの仕組みは、発表ブログと、土台になっている「Gemini Enterprise Agent Platform」のドキュメントから拾いました。
Agent Platformの統制の機能は、ドキュメント上はほぼすべて一般提供（GA）と表示されています。

Agent Platformのドキュメントには、「明示的なポリシーで許可しない限り、すべての接続は遮断される」とあります（筆者訳。Google Cloud：Govern your agents）。
発表ブログによると、エージェントに渡す権限は、会社のセキュリティ担当が承認します。

会社のルールは、Agent Gatewayで全エージェントにまとめて効かせる

Gemini agentでは、ルールを社員のPCごとではなく、ネットワークの側で効かせます。
エージェントの通信は、出入りもエージェント同士のやり取りも、すべて「Agent Gateway」を通ります。
発表ブログでは、AI用のネットワークのファイアウォールと説明されています。

ルールは一度書けば、社内のすべてのエージェントに効きます。
発表ブログには、「Need to Know（関係者限り）に分類された文書は開かない」というルールの例が載っています。
ルールは普通の文章で書けるほか、本番で効かせる前に、試しに動かして影響を確かめることもできます（Google Cloud：Agent Gateway overview）。

プロンプトインジェクションは、Model Armorが通信の途中で検査する

外から入ってくる内容への対策も、仕組みとして用意されています。

「Model Armor」という仕組みが、ユーザーの指示やツールから返ってきた内容をその場で検査します。
プロンプトインジェクションや、機密情報の漏えいを止めるとされています。

隔離された環境で動き、費用の上限でも止められる

作業する場所と、使いすぎへの備えも見ておきます。

Gemini agentは、ネットワークの境界を持った隔離環境（Agent Sandbox）の中で作業します。
発表ブログでは、Gemini agentがした操作はすべて記録に残り、人ではなくエージェントの名義で残ると書かれています。
プロジェクトごとにAIの費用の上限を決めておくと、上限に達した時点でエージェントが止まります。

また、Gemini agentはClaudeのモデルも使えますが、Gemini Enterpriseのリリースノート（10月8日）では、Claudeのモデルは管理者が有効にするものとされています。
外部のモデルは、既定でオフです（Gemini Enterprise release notes）。

データの扱いについては、Googleは、Workspaceのデータや指示の内容をGeminiのモデルの学習に使わないとしています（Google Workspace：Generative AI Security, Compliance and Privacy）。

Claude Codeは、操作ごとに人が確認する使い方ができる

次に、Claude Code側の仕組みです。
Claude Codeにも、会社で使うための仕組みは一通りあります。

初期設定の考え方は、Claude Codeを社内で使い始める。初期設定と安全設計で整理しています。

まず、操作のたびに人が許可する使い方ができます。
手動の承認モードでは、作業中のフォルダの中を読む以外のことには、毎回「実行してよいか」の確認が出ます。
ファイルの編集、コマンドの実行、Webのページの取得などが対象です（Claude Code Docs：Permission modes）。

操作ごとに「禁止」「必ず確認」「許可」のルールも決められ、判定は禁止、確認、許可の順で行われます（Claude Code Docs：Permissions）。
例えば、「外部への公開に近い操作だけは、必ず人が確認する」といった決め方ができます。

なお、ターミナルとVS Codeでは、v2.1.283から最初の状態が自動モードになっています。
毎回確認を出したい場合は、会社としてそう設定しておく必要があります。

管理者の設定で、全員のClaude Codeの設定をそろえられる

社員一人ひとりの設定に任せず、会社としてそろえる仕組みもあります。

全員の設定をそろえるには、管理者が配る設定（managed settings）を使います。
この設定がいちばん強く、ユーザーやプロジェクトの設定では上書きできません。
自動モードや、すべてを許可するモードを使えなくしたり、MCPサーバーを許可したものだけに絞ったりできます（Claude Code Docs：Managed settings）。

利用状況はOpenTelemetryで集められます。
TeamとEnterpriseでは利用状況の分析画面、Enterpriseではコンプライアンス用のAPIも使えます。
データについては、法人向けの規約では学習に使わず、保存期間は標準で30日、Enterpriseではデータを残さない設定も選べます（Claude Code Docs：Data usage）。

権限の設定を社内でどう決めるかは、内製環境の権限設定をどう整えるか。安全と速度を両立させるも参考になります。

公式ドキュメントは、設定で補う前提の注意点も明記している

Claude Codeの公式ドキュメントには、設定するときに知っておきたい注意点も書かれています。

• コマンドを隔離して動かすサンドボックスは、既定ではオフ。Windowsではまだ使えない（Sandboxing）

• サンドボックスを使っても、ファイルを読み書きする機能やMCPサーバーはその外で動く

• claude.aiの管理画面から配る設定は、「セキュリティの境界ではなく、手元で効かせる制御」という位置づけ。確実に効かせたいなら、PCに配る管理者の設定ファイルと組み合わせる（Server-managed settings）

• 自動モードは確認の回数を減らすが、「安全を保証するものではない」（Permission modes）

• 外部のMCPサーバーは、Anthropicが安全性を確認しているものではない。どれを使ってよいかは会社で決める

どれも、気をつける点を公式が明記しているということで、多くは管理者の設定やPCの管理で補えます。
自動モードを使う場合も、会社として禁止する操作や、信頼してよい範囲を先に設定しておくことが前提です。

情シスから見て、Claude Codeより少し安心できそうな点

両方の公式ドキュメントを並べると、情シスが管理するという目線で、Gemini agentのほうが少し安心できそうな点が4つあります。
もちろん、どれも「Claude Codeが危ない」という話ではありません。
管理の仕組みを、人のPCの側に置くか、会社のクラウドの側に置くかの違いです。

1つ目は、誰の操作かが記録の上で分かれることです。
Claude Codeでは、エージェントがやったことも本人の操作として残ります。
Gemini agentでは、本人の代わりに動いたときはエージェントと本人の両方のIDが残り、coworker agentなら変更履歴にもエージェントの名前で残ります。

2つ目は、出発点が「何もつながらない」ことです。
Claude Codeは、使っている人のPCとその人の権限が出発点で、そこから禁止するものを設定で絞っていきます。
Gemini agentは逆に、何もつながらない状態から、許可したものだけを足していきます。

3つ目は、会社のルールを、PCの外のネットワークの側で効かせられることです。
Claude Codeで設定を確実に効かせるには、社員のPCに管理者の設定ファイルを配るなど、PCの管理が前提になります。

4つ目は、作業する場所が社員のPCではなく、隔離された環境であることです。
手元のファイルやブラウザとは切り離された場所で作業します。

ただ、Claude Codeにもクラウドで動かす使い方があり、こちらはセッションごとに隔離された仮想マシンで動きます。
上の比較は、手元のPCで動かすいちばん一般的な使い方と比べたものです。

とはいえ、操作の1つ1つに人の確認を挟めるという点では、今のところClaude Codeのほうが細かく決められます。
どちらが安全かは一概には言えず、どこで止める仕組みなのかが違う、と捉えるのがよいと思います。

提供が始まったら、管理画面で確かめておきたいこと

公式ドキュメントを読む限り、Gemini agentの管理の仕組みはよく考えられています。
それでも、情シスとして実物で確かめたい点はいくつか残ります。

まず、今回引用したドキュメントの多くは、開発者向けの「Agent Platform」のものです。
Workspaceの中で使うGemini agentに、どこまでそのまま当てはまるかは、管理画面が出てから確かめる必要があります。
実際、Gemini EnterpriseでのAgent Gatewayは、外向きの通信だけに対応しているとされています。

また、手元のPCのファイルにつなぐ機能も確かめたい点です。
発表ブログでは、デスクトップのファイルにもつながるとされています。
これを使うなら、結局は手元のPCの管理の話に戻ってきます。

coworker agentのアカウントの管理も、確かめておきたい点です。
このアカウントがWorkspaceのライセンスとして数えられるのか、費用がかかるのかは、まだ発表されていません。
誰が持ち主なのか、どの権限を持たせているのか、作った人が異動や退職をしたときにどうするのか。
こうした点は、人のアカウントと同じように棚卸しの対象になります。

操作のたびに人が承認する仕組みがあるかどうかも、見ておきたいところです。
Claude Codeでは、操作ごとに確認を出したり、特定の操作だけは必ず人が確認するように決めたりできます。
今回読んだGemini agentの発表ブログとドキュメントの範囲では、こうした仕組みについての記載は見当たりませんでした。

目標を渡して任せるエージェントなので、どこで人が確認するのかは、使い始める前に決めておきたいところです。

最後に、「何もつながらない」状態から始まるということは、許可する範囲を情シスが設計する手間があるということでもあります。
外部のモデルとしてClaudeを有効にする場合は、データがどこを通るのかも合わせて確認しておきます。

入力したデータがどこまで学習や保存に使われるかの整理は、AIに入力した情報は学習される？無料版・法人版・APIの違いを整理が土台になります。

エージェントの社内ルールづくりから相談できる

AIエージェントは、業務ごとに「どの権限で動かすか」「どこで人が確認するか」を決めないと、情シスの判断が止まったまま広がりません。
私たちのAI活用の伴走支援では、AIを入れるときの社内ルールづくりから、業務への組み込みと定着までを一緒に進めています。

エージェントを「社員と同じように管理する」準備を始める

Gemini agentの安全の仕組みは、エージェントに社員と同じようにIDと権限を与え、会社のルールの中で働かせる考え方でできています。
Claude Codeは、人の道具として、その人のPCと設定で管理する考え方です。
どちらが正しいというより、業務によって向き不向きがあると思います。

両方を使う会社では、「この業務はエージェント自身のIDで動かすのか、人の権限で動かすのか」を業務ごとに決めておくと、あとで整理しやすくなります。

AIを使うときの社内ルール全体の作り方は、生成AIの社内ルールの作り方。ガイドラインの項目サンプルと守れる環境で扱っています。

日本での提供はまだ先になりそうですが、エージェントのアカウントを誰が管理するのか、どんなルールを書くのかは、今のうちから考え始めておけます。

まずは、社内で使っているAIのうち、本人の権限のまま動いているものを書き出し、記録の上で人の操作と分けられているかを一覧にしてみてください。