「読み取りだけ」で済まないAI連携——権限21件の実名と、戻せなくなる操作

AIを社内のGmail・Slack・Google Drive・GitHub・Google Sheetsにつなぐと、許可の画面でお願いする権限は21件になります。AIに渡している操作は36件です。この記事は、その21件を英語の原文のまま1件も伏せずに並べたものです。

株式会社Latensは、ClaudeなどのAIを社内のGmail・Slack・Google Drive・GitHub・Google Sheetsなどにつなぐ LatensOS という製品を提供しています。つなげる先の一覧と、AIに渡せる操作、つなぐときにお願いする権限は、すべて公開しています。

読むだけのものと書き込みを含むものを分け、書き込みが何件あるかを数で出します。数えた元は、公開しているコネクタ一覧（生成日 2026-10-24。Google Sheets は2026年10月24日に加わりました）と、当社のMCPサーバーが返す操作の一覧です。当社1社の構成の話で、業界の傾向として一般化できるデータは持っていません。

権限の層と、道具の層

この2つはずれます。 操作名の一覧を見ているだけでは、権限の層で何を許したかは分かりません。逆に、権限の名前を読んだだけでは、AIが実際にどこまで届くかも決まりません。この記事は、その両方を並べて置くためのものです。

権限21件と操作36件の内訳

算出式＝コネクタ一覧の scopes と tools をコネクタごとに数え、5件分を足したもの。確認日 2026-10-24。

権限21件の内訳は、読み取りのみが10件、書き込みを含むものが7件、どちらか判定できていないものが4件です（10＋7＋4＝21）。判定できていない4件はSlackの履歴の権限で、理由は後ろに書きます。

操作の数と権限の数は単位が違うので、合計を引き算しても意味がありません。見るのはコネクタごとの開きです。Slackが操作5件に対して権限13件、Google Sheetsが権限1件に対して操作17件。この2件が逆方向に大きく開いています。

図：コネクタごとの「お願いする権限の数」と「AIに渡す操作の数」。Slackは操作5件に対して権限13件、Google Sheetsは権限1件に対して操作17件で、逆方向に開きます。

読み取り専用の権限と、それを使っていない構成

5件のうち4件には入っていて、Google Sheetsだけ入っていません。 当社がお願いしているのは https://www.googleapis.com/auth/spreadsheets の1本だけで、この1本に読み取りと書き込みが同居しています。

Googleには読み取り専用の権限が用意されています。公式の説明文はこうです。

See all your Google Sheets spreadsheets.

これが https://www.googleapis.com/auth/spreadsheets.readonly です。いっぽう当社が使っている spreadsheets の説明文は、

See, edit, create, and delete all your Google Sheets spreadsheets.

です（出典：Google Sheets API / Scopes、確認日 2026-10-24）。読み取り専用が存在しないのではなく、当社の構成がそれを使っていません。

図：読み取り専用と注記された権限が構成に入っているか。5件のうち4件に入っていて、Google Sheetsだけ入っていません。ただし4件の側も、読み取りだけを渡した構成にはなっていません。

そのうえで、4件の側にも同じことが言えます。読み取りだけを渡した構成は、どのコネクタにも作っていません。 Gmailは gmail.readonly と送信・下書きの権限を3件まとめてお願いしています。Google Driveは drive.readonly と drive.file の2件まとめてです。GitHubは読み取り専用の read:org と、書き込みを含む repo を同時にお願いしています。読み取り専用の権限が構成に入っていることと、読み取りだけを渡していることは別の話です。後者はやっていません。

権限21件の実名

英語の原文のまま並べます。「注記」は当社の生成スクリプトが権限の名前から付けたラベルで、公式の説明文ではありません。

出典は各個別ページ、確認日 2026-10-24。

図：権限21件の早見表。読み取りのみ10件、書き込みを含む7件、判定できていない4件。社内審査にそのまま転記できる体裁です。

この表を社内審査に引用するときの注意が2つあります。

1つめ。判定できていない4件は、読み取り専用という意味ではありません。 当社の生成スクリプトが権限の名前から読み書きを判定できなかった状態です。この4件を「読むだけ」と判定した記録は、当社にありません。

2つめ。注記に公式の説明文を併記できているのは、21件のうち4件だけです。 GitHubの2件（repo・read:org）とGoogle Sheetsの2件（spreadsheets・spreadsheets.readonly）です。Googleの5件（Gmail 3件＋Drive 2件）とSlackの13件については、公式の原文をこの記事では引用していません。

認証の方式は、5件すべて「OAuth 2.0（利用者本人の許可）」です。利用者ご本人が許可の画面で同意してつなぐ形で、管理者が代わりに押す形ではありません。

コネクタ別の中身

操作名の英語だけでは手元の作業に結びつかないので、先に対応を1つ置きます。これは「どの操作がどの業務に当たるか」の対応で、何分縮んだかの数字ではありません（当社では測っていません）。

書き込み側の操作が混ざっています。 下書きを作る・メモを貼る・行を足すは、どれも書き込みです。「AIに読ませたいだけ」で始めたつもりでも、やりたいことの半分は書き込みになります。

Gmail｜3件まとめて渡した結果の到達範囲

権限3件・操作5件。操作は gmail_search_emails（メールを検索する）／gmail_read_email（メールを閲覧する）／gmail_send_email（メールを送信する）／gmail_create_draft（下書きを作成する）／gmail_list_labels（ラベル一覧を取得する）です。

gmail.readonly という読み取り専用の権限は独立して存在します。つまり「見るだけで動かす」構成を権限の層で表現できます。ただし当社は、それを単独では渡していません。 gmail.readonly・gmail.send・gmail.compose の3件を同時にお願いしています。同時に渡した結果の合計の到達範囲は、「受信箱の全体を読める、かつ、下書きと送信ができる」です。

そして送信の操作 gmail_send_email は、AIに渡しています。権限の層でも道具の層でも、送信はできる状態です。当社が送信を使っていないのは運用上の決めごとで、送信ボタンは人が押します。

なぜ「下書きだけ」を権限で表現できないのか、Googleの権限の階層と審査の区分は、公式の説明文まで当たって別の記事に書いています。

→ AIに「下書きだけ」を許す権限は作れない

gmail.readonly は受信箱の全体が対象です。「特定のラベルだけ」「直近3か月だけ」に絞れるかどうかは、当社で試していません。

Slack｜操作5件に対して権限13件

権限13件・操作5件。5件の中で、操作の数と権限の数がもっとも開きます。操作は channels_me（参加中のチャンネルとDMの一覧）／conversations_history（会話履歴の取得）／conversations_replies（スレッド返信の取得）／conversations_add_message（メッセージの投稿とスレッド返信）／reactions_add（リアクションの追加）です。

操作名だけを見ていると気づけないことが、権限の側にあります。 履歴の権限を4件お願いしていて、内訳はこうです。

im と mpim はDMとグループDMに当たります。つまり権限の層では、DMの履歴まで許可をお願いしています。操作の側は conversations_history の1本だけなので、操作名の一覧を見ているかぎりでは分かりません。

図：Slackの履歴の権限4件の対象。im と mpim がDMとグループDMに当たります。

この4件は、注記が「—」のままです。読むだけなのか書き換えも含むのかを、当社の生成スクリプトが判定できていません。

実際にどこまで届くかは、この記事では確定できていません。 渡しているトークンがアプリのものか利用者ご本人のものかを、当社で特定していないためです。アプリのトークンであれば、アプリが参加していない会話には届かないはずですが、im:history と mpim:history を渡した構成で、アプリを追加していないDMがどうなるかを試していません。「アプリを追加したチャンネルだけが対象です」と断定することは、この記事ではしません。

chat:write について1行足します。 この1本は、新しい投稿を追加する権限だけではありません。既存の投稿の編集（chat.update）と削除（chat.delete）にも権限を与えます（出典：Slack公式 / chat:write、確認日 2026-10-24）。chat.delete の必要スコープは、botトークンでも利用者トークンでも chat:write の1件だけです（出典：Slack公式 / chat.delete、同日）。Gmailの gmail.send／gmail.compose と同じく、1本の権限に複数の到達範囲が入っています。 注記の「書き込みを含む」は誤りではありませんが、「書き込み＝追加だけ」と読まないでください。

Google Drive｜絞れるのは書き込み側の範囲だけ

権限2件・操作4件。5件の中で、お願いする権限がもっとも少ないコネクタです。操作は drive_search_files（ファイルを検索する）／drive_read_file（ファイル内容を読む）／drive_upload_file（ファイルをアップロードする）／drive_list_files（ファイル一覧を取得する）です。

権限は drive.readonly（読み取りのみ）と drive.file（書き込みを含む）の2件で、当社はこの2件を同時にお願いしています。

ここは要約を誤りやすいところなので、限定して書きます。 範囲を絞れる設計になっているのは、書き込み側の drive.file だけです（出典：Google Drive API のページ、ただし原文の引用はこの記事ではしていません）。同時に渡している drive.readonly は、ご本人が見えるドライブが対象です。読み取りの範囲は絞れません。

したがって、同時に渡した結果の合計の到達範囲は、「ご本人が見えるドライブを読める、かつ、限定された範囲に書き込める」です。 「フォルダ1個だけ渡す」という形には、読み取り側ではなりません。共有ドライブが読み取りの対象に入るかどうかは、当社で確かめていません。

drive.file の「範囲を絞れる」が当社の製品でどう効くかも確かめていません。この権限は、アプリが作ったファイルと、利用者が画面で明示的に選んだファイルに限られる作りです。当社がAIに渡している操作4件の中に、利用者がファイルを選ぶ画面に当たる操作はありません（確認日 2026-10-24）。製品の画面に選択の仕組みがあるかは開いて確かめていないので、無ければ対象は drive_upload_file が作ったファイルだけになる、というのが当社の推測です。

GitHub｜repo が組織に届く範囲

権限2件・操作5件。操作は github_list_repos（リポジトリ一覧）／github_create_issue（Issue作成）／github_list_issues（Issue一覧）／github_create_pr（PR作成）／github_search_code（コード検索）です。

お願いしている権限の実名と、GitHub公式の説明文（原文）です。

1件目　repo

Grants full access to public and private repositories including read and write access to code, commit statuses, repository invitations, collaborators, deployment statuses, and repository webhooks. Note: In addition to repository related resources, the repo scope also grants access to manage organization-owned resources including projects, invitations, team memberships and webhooks. This scope also grants the ability to manage projects owned by users.

2件目　read:org

Read-only access to organization membership, organization projects, and team membership.

（出典：GitHub Docs / Scopes for OAuth apps、確認日 2026-10-24）

原文が言っていることを、要約せずに書きます。 repo は、公開・非公開を問わずリポジトリへの全面的なアクセスを与えます。そしてリポジトリの外、組織が持つプロジェクト・招待・チームの所属・webhook の管理まで含みます。原文に書かれているとおりです。社内審査でいちばん効くのはここで、AIに渡したトークンで、組織へのメンバー招待や webhook の作成が権限の層では可能になります。当社がAIに渡している操作は上記の5件ですが、権限の側はそれよりずっと広いところまで開きます。

読み取り専用の read:org は構成に入っていますが、広い repo を同時にお願いしているため、読み取りだけに切り分けた構成にはなっていません。 GitHubの側に細かい読み取り権限や、別方式のトークンで同じ5操作を狭い権限に置き換える方法があるかどうかは、この記事では調べていません。

GitHubの権限設定の画面で、外せない権限があるかどうかも当社で画面を開いて確かめていません。公式の説明を3ページ当たりましたが（Scopes for OAuth apps／Permissions required for GitHub Apps／Scopes for OAuth apps の一覧）、必須と書かれた記述には行き着いていません。あるともないとも書きません。

Google Sheets｜1本に同梱された読みと書き

権限1件・操作17件。権限は https://www.googleapis.com/auth/spreadsheets の1本だけで、この1本の中に読み取りと、値の更新・追加・消去が同居しています。

操作17件の内訳は、書き込みを含むものが10件、読み取りだけのものが7件です（10＋7＝17）。

分類は操作名から当社でやったもので、当社の課金側の分類結果と一致するかは確かめていません。

図：spreadsheets という1つの権限の中に、読み取り7件と、値の更新・追加・消去を含む書き込み10件が同居しています。

「AIにスプレッドシートを読ませたいだけ」でも、権限の層では書き換えと行の消去まで渡すことになります。 Gmailのように読み取り専用の権限を分けて渡す構成が、当社にはありません。

対象のファイルを絞れるかどうかも書けていません。 sheets_spreadsheets_sheets_copyTo は別のスプレッドシートへシートを複製する操作です。権限 spreadsheets の公式の説明文は「all your Google Sheets spreadsheets」と書いているので、特定の1ファイルに限定される作りではありません。

Google Sheetsを顧客環境で動かした実績はまだありません。17件のうちどれが実際に使われるかの数字も持っていません。今日の提案に入れるなら、書き込む操作の前に人が承認する形を前提にしてください。

読み取りと書き込みが同じ構成に入ることの意味

対策は確定していないので、事実だけ並べます。

1. AIが読む入力は、社外の人が書き込める場所にあります。

2. 読んだ内容を外に出す口が、同じ構成の中にあります。 gmail.send と gmail_send_email は社外へ、chat:write は公開チャンネルへ、github_create_issue は公開リポジトリへ出ます。しかも chat:write は、新しい投稿を出す口であるだけでなく、既存の投稿の編集と削除にまで届きます。 つまり、過去の投稿を書き換える・消すことが権限の層では可能です。読み取りと書き込みを同じ構成で渡すと、読んだものが外に出る道が1本で繋がります。

3. 当社の料金の説明は、安全の説明ではありません。 当社の料金は、AIが社内システムのデータを変えた操作で数えます。読むだけの操作は数えません。これは請求の話であって、安全の話ではありません。 請求が増えていないことは「書き換えが起きていない」ことの手がかりにはなりますが、「見られていない」ことの保証にはなりません。

4. 人の承認を挟む形は、機能としては存在します。 書き込む操作だけを、人が承認してから実行する形にできます（出典：/ja/media/mcp/slack の記述、確認日 2026-10-24）。ただし、それが上の1〜2に対して効くかどうかは分かりません。 承認の画面に何が出るのか——宛先と本文の全文か、要約か、呼び出す操作の名前だけか——を当社で確かめていません。要約だけが出るのであれば、混ぜ込まれた指示は承認を通ります。

5. 当社の対策は確定していません。 確定していないものを対策として書くことはしません。

戻せるものと、戻せないもの

緊急停止の手段は、この記事では書けません。 トークンの漏れやAIの異常を疑ったときに、利用者ご本人の取り消しを待たずに、お客様の単位・コネクタの単位で即時に止められるのかを、当社で確かめていません。

この数字が当てはまる構成の範囲

ここは注意して読んでいただきたいところです。

上に書いた「操作36件」は、公開しているコネクタ一覧の構成——当社が標準として選んだ組み合わせ——のものです。AIに実際に届く範囲は、①つなぐ先にお願いした権限、②お客様のテナントの設定、③当社のMCPサーバーがどの操作を出すか、の3つで決まります。この記事が扱っているのは①で、③については公開している構成の数を出しているだけです。

当社の社内には、公開している一覧より広い操作を返す開発用の構成があります。 そこには、メールやファイルの削除、メールの転送設定の変更、ファイルの共有相手の追加に当たる操作が含まれます（出典：当社の開発用の接続で操作の一覧を数えたもの、確認日 2026-10-24）。その実名は、どの構成をお客様に配るかが確定していないため、この記事では出しません。

したがって、「この一覧にない操作はできません」とは、無条件には書けません。 正確には「公開しているこの構成では、一覧にない操作は出てきません」です。お客様のテナントで実際に配られる操作の一覧が、この記事の36件と一致するかは、当社で突き合わせていません。社内審査では、「どの構成の、いつ時点の一覧か」を当社に確認してください。

コネクタ一覧は、製品側の定義から機械的に作り直すしくみです（生成日 2026-10-24）。手では直しません。 製品側でコネクタが増えたら作り直すまで反映されないので、一覧の生成日と、見ている日付がずれていないかは見てください。

確かめていないこと

社内審査で質問が出たら、現時点では分からないと答えるのが正確なものです。

• 読み取ったメールの本文やファイルの中身が、どこへ行くのか。 どの事業者のどのモデルに渡るのか、どこに保存されるのか、学習に使われるのか、当社の運用担当が見られるのか。
• 事故を疑ったときに、即時に止める手段。
• 誰がつなげるのか。 管理者の側で「許可するコネクタを限定する」「部署や利用者を限定する」ことができるか。
• 操作の記録の中身。 操作の呼び出しだけなのか、メールの本文まで残るのか。ご自身で閲覧・書き出しできるか。保持期間と、その延長の条件。契約が終わったときの記録とトークンの扱い。
• トークンの保管場所と暗号化、当社側での管理の方法。
• 退職者のトークンをまとめて失効させる手段が製品にあるか。
• 権限を1つ外した状態で、どの操作が落ちるか。 実機で試していません。
• 読み取りをラベル単位・チャンネル単位・フォルダ単位に絞れるか。 「不要な範囲は外せます」とは書けません。
• 読み取りだけを渡した構成が実際に動くか。 gmail.readonly だけ、drive.readonly だけの構成を当社で立てて動かしたことがありません。この記事の後ろで挙げる進め方を、当社自身がまだ試していません。
• Slackに渡しているトークンの種別と、実際に届く範囲。
• 承認の画面に何が出るか。 宛先と本文の全文か、要約か、操作の名前だけか。
• お客様のテナントで実際に配られる操作の一覧が、こゆ36件と一致するか。

この記事でできないことも書いておきます。他社のAI製品が要求する権限とは比べられません。調べていないので、「どのAIツールが安全か」の比較表は作れません。法律上の評価もしません。個人情報保護法や改正電気通信事業法の外部送信の規律が、AI経由のデータの移転にどう当たるかは条文まで遡っていないので、専門家にご相談ください。許可の画面のスクリーンショットも、この記事には入れていません。つなぐ手順も書いていません（公開しているメディア上に設定手順の記事は、2026-10-24時点でありません。製品内のセットアップガイドは別にありますが、記事としては出していません）。

社内審査に回すときの4点

このURLをそのまま渡していただいて構いません。そのうえで、聞かれる4点に先に答えておきます。

図：社内審査で聞かれる4点。取り消せるか／対象を限定できるか／記録が残るか／読んだものが外に出ないか。

1. 取り消せるか。 利用者ご本人が許可してつなぐ形なので、ご本人の側で許可を取り消せます。いっぽう、退職者のトークンをまとめて失効させる手段と、事故を疑ったときに即時に止める手段は、当社で確かめていません。ここは未確認とお伝えください。

2. 対象を限定できるか。 つなぐ先によって違います。読み取り専用の権限が構成に入っているのは、Gmail・Slack・Google Drive・GitHubの4件です。Google Sheetsには入っていません。ただしどのコネクタでも、読み取り専用だけを渡す構成を作っていません。 Google Driveで範囲を絞れるのは書き込み側だけで、読み取りはご本人が見えるドライブが対象です。ラベル単位・フォルダ単位まで絞れるかは試していません。

3. 記録が残るか。 記録は残ります。ただし保持期間・記録の粒度・ご自身で書き出せるかは、この記事では書けていません。「本人が手でやったのか、AIがやったのか」が分かるかも未確定です。

4. 読んだものが外に出ないか。 読み取りと書き込みが同じ構成に入っているため、権限の層では道がつながっています。当社の対策は確定していません。

未確認のまま稟議に進めない場合、できるのは3つです。 (1) 当社に問い合わせていただく。(2) デモで実際の画面をご覧いただく。(3) 御社の試用の環境で動かしていただく。ただし、未確認の項目のうちどれがデモで確かめられるかは、この記事では書けていません。デモのご依頼の際に、確かめたい項目を先にお伝えください。

どこから始めるか。 当社の考えを3つ書きます。

• Gmail・Google Driveから始める形をおすすめしますが、条件を付けます。 読み取り専用の権限が構成に入っているのはこの2件ですが、当社が渡しているのはまとめた3件・2件です。読み取りだけを渡した構成を当社でまだ試していないので、試していない構成をおすすめしていることを先にお伝えします。
• Slackから始める場合。 専用のチャンネルを1本作って、そこにだけアプリを追加する形が考えられます。ただし im:history・mpim:history を渡した構成でDMがどうなるかを試していないため、この形で境界が引けると断定はしません。
• Google Sheetsは、今日は入れないことをおすすめします。 権限1本で書き換えまで渡ることになります。入れる場合は、書き込む操作に人の承認を挟む前提にしてください。

「全部許可」で始めて後から絞る順番は、上の表のとおり、戻すのが難しくなります。

稟議にそのまま添付できる要点

この節だけ転送できます。

AIを社内のGmail・Slack・Google Drive・GitHub・Google Sheetsにつなぐとき、Latensがお願いしている権限の名前を、この5件について全件公開しました（確認日 2026-10-24）。5件で権限は合計21件、AIに渡す操作は合計36件です。

判断に効くのは2点です。

1. 読み取り専用の権限が構成に入っているのは、5件のうち4件（Gmail・Slack・Google Drive・GitHub）です。Google Sheetsには入っていません。算出式＝コネクタ一覧の注記に「読み取りのみ」が1件以上あるかを数えたもの。
2. そのうえで、どのコネクタでも「読み取りだけを渡す構成」を作っていません。 Google Sheetsについては、Googleに読み取り専用の権限が用意されているのに、Latensの構成がそれを使っていません。

Latens側の歯止めは、今日の時点で1つです。 書き込む操作の前に人が承認する形にできます。機能としては存在しますが、運用した件数・所要時間・差し戻しの率を測っていません。

金額について。 基本料金の水準は1人あたり月3,000円です（出典：/ja/product、確認日 2026-10-24）。従量の料金は、AIが社内システムのデータを変えた操作で数え、読むだけの操作は数えません。最低のご利用料金・段階ごとの単価・税の扱いは製品ページに書かれていないため、見積りでご確認ください。

何がどれだけ減るかは、この記事では分かりません。 工数の before / after を集計していません。ご判断いただきたいのは金額対効果ではなく、進め方の可否です。 具体的には——(1) 読み取り専用の権限が構成に入っている2件（Gmail・Google Drive）から始める。(2) 書き込みを含む操作には人の承認を挟む。(3) データの行き先・緊急停止・誰がつなげるかの3点をLatensに確認してから広げる。 この3点でよいか、です。

LatensOS への接続点

LatensOSの標準コネクタは、採用の前に次の点を確かめたものだけです。1つでも欠けるものは標準コネクタにしません。

• 誰が作っているか
• どこを通って、どう認証するか
• どこまでの権限を求めてくるか
• 書き込みをどれくらい細かく止められるか
• あとから「何をしたか」の記録が残るか

この記事の早見表は、その判断の材料を横に並べたものです。ただし2番目の「どこを通って、どう認証するか」について、この記事は認証の方式しか書いていません。

コネクタごとの詳細は、個別ページにあります。

• Gmail
• Slack
• Google Drive
• GitHub
• Google Sheets
• 関連記事：AIに「下書きだけ」を許す権限は作れない

実際につないだ画面をご覧いただくほうが早い場合は、デモをご用意します。確かめたい項目を先にお知らせください。社内審査に回す資料が必要な場合は、資料請求からお申し付けください。この記事の早見表は、そのまま添付していただいて構いません。

訂正

2026-10-26：冒頭の段落を入れ替えました（記事の要旨を先、会社の説明を後に）。本文の数字と主張に変更はありません。