ClaudeがGoogleドキュメントを直接編集。承認は既定でオン、見積書から消える行

「社内の資料を AI に読ませて、要約や下書きを作りたい」という相談は多い。見積書には、ファイルを置く画面、文書の中身を取り出す処理、権限の管理、結果を書き戻す画面といった行が並び、数百万円になる。

その見積書のうち何行かが、表計算や文書ソフトの標準機能の側に移ってきている。2026 年 10 月 6 日、Anthropic が Claude を Google ドキュメント・スプレッドシート・スライドの中で動かすアドオンを公開ベータとして出した。

発注側が読むべきなのは「便利になった」ではなく、自社の案件のどの行が標準機能と重なり、どの行が残るかである。

公表されている事実

公式の案内（2026 年 10 月 6 日）に書かれているのは次の内容である。

• 提供形態: Google ドキュメント / スプレッドシート / スライドに入れるサイドバーのアドオン。「Claude for Google Workspace is now in public beta on all paid Claude plans」（有料プラン全体で公開ベータ）
• できること: 開いているファイルを読み、利用者が選択している範囲（文字・セル・スライド）を認識し、ファイルを直接編集する
• 編集の承認: 既定は 「Ask before edits」。変更は要約の付いた承認カードとして出て、利用者が承認するまで反映されない。「Accept all edits」を選べば止まらずに適用される
• 権限: 「Claude's access matches your existing Google sharing permissions」（既存の Google 共有権限と一致する）
• 管理機能: Enterprise プランの Compliance API・顧客管理の暗号鍵（CMEK）・OpenTelemetry での監査ログ出力が、このアドオンにも適用される
• 逆方向の接続: Claude のチャット側から Google のファイルを作成・編集するコネクタもベータ
• 導入: Google Workspace Marketplace から導入し、管理者は Google 管理コンソールで配布できる

同種の動きは 1 社に限らない。表計算や文書ソフトの中に AI の作業領域を置く形は各社が進めており、「業務ソフトの中で AI が編集する」こと自体は差別化要素ではなくなりつつあると考えられる。

発注者・企業への影響

ここから先は見立てである。

1. 見積書から消える可能性のある行

社内文書を扱う案件の見積書には、だいたい次の行が入る。標準機能と重なる範囲では、作らない判断ができる。

見積書によくある行	標準機能と重なるか
ファイルのアップロード画面・保管先	重なる（元のファイルのまま扱う）
文書・表・スライドの中身を取り出す処理	重なる
閲覧権限の管理・同期	重なる（共有設定をそのまま使う）
結果を人が確認して直す画面	重なる（承認カード）
利用者ごとのアカウント管理	重なる

ここで注意したいのは、「重なる＝削れ」ではないことである。重なる行を削るには、利用者が全員その有料プランを持ち、対象の文書がすべてそのクラウド上にあり、管理者がアドオンの配布を許可している、という前提が要る。前提が崩れる部分は作る必要が残る。

判断の順番は、まず標準機能で足りる範囲を確定し、残った範囲を見積もりに出す、である。この順番を逆にすると、標準機能と同じものを作る見積書を比較することになる。境界の引き方はSaaSとスクラッチ開発、AIはどちらを選ぶべきかで整理した。

2. 残る行は「人が開かない処理」

標準機能が得意なのは、人がファイルを開いていて、人が結果を承認する使い方である。裏を返すと、次のような処理は標準機能の外に残る。

• 夜間に数千件をまとめて処理する（人が開かない）
• 基幹システムや CRM から取り出したデータを突き合わせる
• 判定の根拠と結果を記録に残し、後から監査できるようにする
• 同じ入力に対して毎回同じ判定を返すことを保証する
• 精度を定義し、定期的に測って劣化を検知する

発注の価値が残るのはこちら側である。相談の段階で「人が開いて使うのか、人が開かずに回すのか」を先に決めておくと、見積もりの額が大きく変わる。業務ごとの切り分けはAIに任せる業務の選び方に手順を書いた。

3. 権限をそのまま継ぐことは、利点でもあり穴でもある

共有権限をそのまま使う設計は、権限の二重管理が要らないという点で素直である。その一方で、共有設定が緩い組織では、緩いまま AI が読めることを意味する。

よくあるのは、過去に「リンクを知っている全員」で共有したまま残っているファイル、退職者が作ったフォルダ、部署をまたいで共有されたままの人事・給与関連の表である。これらは人が開かないから問題が表に出ていないだけで、AI に探させれば出てくる。

導入前にやることは開発ではなく棚卸しである。

• 共有範囲が「リンクを知っている全員」になっているファイルの洗い出し
• 機微なデータを含むフォルダの権限の見直し
• アドオンを配布する対象者の範囲（全社か、部署単位か）

これは情シス側の作業で、開発会社の見積書には載らない。載らないが、やらないと使えない。見積もりを取る前に誰がやるかを決めておく項目である。

4. ベータを前提にした提案は、条件を書かせる

公開ベータは、仕様が変わること・提供条件が変わることを織り込んで使うものである。提案に組み込むなら、次を文面で確認しておきたい。

• 対象の機能がベータであることが提案書に明記されているか
• 仕様変更で動かなくなった場合の修正は、保守に含むか別途か
• ベータが終了したときの料金（プラン条件）はどちらの負担か
• 代替手段（標準機能が使えない場合の作り）を用意するか

「標準機能で足ります」という提案は安く見えるが、その標準機能がベータである場合、安さの根拠に期限が付いている。期限の扱いが書かれていない提案は、運用開始後に追加費用の相談になりやすい。提供条件の変更が運用費に効く例は法人契約から開発ツールが分離された件でも扱った。

5. 「承認してから反映」は検収と監査の設計に効く

既定で承認を挟む作りは、業務に入れるうえで扱いやすい。ただし運用設計としては、誰が承認したかを記録するかが別の論点になる。

契約書や請求書のように、後から「誰がこの数字を確定させたか」を問われる書類では、承認者と日時の記録が要る。標準機能の承認カードは作業を進めるための仕組みであって、監査証跡として設計されているとは限らない。記録が必要な業務では、そこだけを作る判断になる。

見積もりを取るときに揃える 4 点

複数社に依頼するなら、次を同じ文面で出す。これを書かないと、A 社は標準機能を前提にした小さい金額、B 社は全部作る前提の大きい金額を出し、比較にならない。

1. 対象の文書がどこにあるか（クラウド上 / ファイルサーバー / 基幹システムの中）
2. 人が開いて使うのか、人が開かずに回すのか（両方ある場合は件数の比率も）
3. 利用者が持っているプランと、アドオン配布の可否（情シスに確認した結果を書く）
4. 判定の記録・承認者の記録が必要か（必要なら保存期間も）

3 つ目が書かれていると、各社は「作らない範囲」を同じ前提で引ける。無料で相見積もりの案件票では、扱うデータの置き場所と利用者の範囲を選択式で揃えているので、各社が同じ線引きで出したかを横並びで確認できる。

まとめ

今回の発表で変わったのは、「社内文書を AI に読ませる」こと自体の希少性である。読ませて直させるところまでは、業務ソフト側の標準機能に寄っていく流れだと考えられる。

発注側がやることは 2 つ。見積書の行を標準機能と重なる分と残る分に分けること、そして共有権限の棚卸しを開発の前に自社で終わらせることである。どちらも金額を下げる方向に効く。

参考・出典

• Anthropic「Claude now works with Google Docs, Sheets, and Slides」（2026 年 10 月 6 日） https://claude.com/resources/articles/claude-now-works-in-google-docs-sheets-and-slides
• Anthropic 公式ブログ一覧 https://www.claude.com/blog