Google Docs / Sheets / Slides API がコメントに対応、Docs API は「提案」もプログラムから作れる

要約

Google は 2026-09-30、Docs / Sheets / Slides の API からコメントを作成・読み取り・管理できるようにしました。さらに Docs API では「提案（suggested edits）」をプログラムから作成できます。

公式の説明文が、この更新の意図をそのまま表しています。 「自動化ツールやサードパーティのシステムが、本文を直接書き換えるのではなく、ユーザーのレビューに向けて改訂を提案できる」。

ここが重要なので、丁寧に展開します。

これまで、API から文書を変更する方法は「書き換える」しかありませんでした。 Docs API で本文を編集すれば、その変更は確定した変更として入ります。 誰かが後から「ここは直してほしくなかった」と思っても、変更履歴を辿って手で戻す以外に方法がありません。

この制約が、文書処理の自動化を難しくしてきました。

自動化したい処理の多くは、「たぶん正しいが、確認したい」種類のものです。 表記の統一、誤字の修正、用語の置き換え、構成の整理。どれも機械的にできますが、間違える可能性があります。 そして文書は、間違った自動修正が入ると、元の意図が失われます。

結果として、多くの組織は自動化を見送ってきました。 「AI に文書を直させる」構成は、技術的には可能でも、本番の文書へは適用できないという判断です。

提案（suggested edits）が API から作れるなら、この判断が変わります。

提案は、Google Docs の既存機能です。 編集者モードではなく提案モードで編集すると、変更が「提案」として表示され、承認または却下を選べます。 これは、Word の変更履歴に相当する機能で、組織の文書レビューでは広く使われています。

つまり、新しい概念を導入する必要がありません。 既存のレビューフローへ、自動化の出力をそのまま流し込めます。 レビューする側から見ると、「人が提案したか、システムが提案したか」の違いだけで、作業は同じです。

コメント対応も、同じ方向の機能です。 Docs / Sheets / Slides の3つで、コメントを作成・読み取り・管理できます。読み取りができる点も見落とせません。 文書に付いたコメントをプログラムから取得できるなら、「指摘事項を集約する」「未解決のコメントを一覧にする」といった処理が可能になります。

提供条件は緩やかです。 対象は全 Workspace 顧客と個人の Google アカウントで、専用の管理者設定やエンドユーザー設定は不要です（ただし管理者はアプリの Workspace データへのアクセスを制限できます）。ロールアウトは 2026-09-30 開始で、Rapid Release / Scheduled Release の両ドメインで15日以内に反映される見込みです。

公式が挙げる用途は、「社内のレビューツール、自動化されたコンテンツパイプライン、プロジェクト追跡システムを Workspace のエディタへ直接つなぐ」ことです。

何が変わったか

• Docs / Sheets / Slides API からコメントを作成・読み取り・管理できる
• Docs API から「提案（suggested edits）」を作成できる
  • 本文を直接書き換えず、ユーザーのレビューに向けて改訂を提案する形
• 対象 API: Google Docs API / Google Sheets API / Google Slides API
• 対象ユーザー: 全 Workspace 顧客 + 個人の Google アカウント
• 専用の管理者設定・エンドユーザー設定は不要（管理者はアプリの Workspace データへのアクセス制限は可能）
• ロールアウト: 2026-09-30 開始、両ドメインで15日以内に反映
• 公式が挙げる用途: 社内レビューツール、自動化されたコンテンツパイプライン、プロジェクト追跡システムとエディタの直接連携

業務インパクト（一般企業向け）

この更新は、「AI に文書を触らせる」ことへの社内の抵抗を、技術的に解消する手段を与えます。

AI による文書処理を提案したとき、返ってくる反対意見はほぼ決まっています。 「勝手に書き換えられたら困る」「誰が確認するのか」「間違っていたときに誰の責任か」。これらはすべて、正当な懸念です。 そして、全文を上書きする方式では、答えられません。

提案として出す構成なら、答えが用意できます。 「書き換えません。提案として出します。承認するのは担当者です」。責任の所在が変わらないため、既存の承認プロセスをそのまま使えます。

実務として組めるものを、具体的に挙げます。

1つ目。表記統一の自動提案です。

社内の表記ルール（「お客様」か「顧客」か、半角か全角か、固有名詞の表記）は、ルールがあっても守られません。 人が目で確認するには量が多すぎます。

提案として入れるなら、網羅的にかけられます。 文書を走査し、ルール違反を全部提案として出す。担当者は提案を順に承認していくだけです。 1つずつ判断できるため、例外（引用部分など）だけ却下すれば済みます。

2つ目。レビューコメントの自動生成です。

コメントの作成が API からできるようになったため、「指摘をコメントとして付ける」処理が可能です。 契約書のチェック、仕様書の不整合の指摘、過去の文書との矛盾の指摘。修正を提案するのではなく、「ここを確認してください」とコメントで指摘する形です。

この方が、提案より適している場面があります。 判断が必要な指摘は、修正案を出すべきではありません。 「この条項は前回と違いますが、意図的ですか」という指摘は、コメントで問う方が正確です。 修正案として出すと、承認ボタンを押すだけで意図しない変更が入ります。

3つ目。コメントの集約と追跡です。

コメントの読み取りができる点を使います。 複数の文書に散ったコメントを取得し、未解決のものを一覧にする。 レビューの進捗を管理する仕組みが作れます。

これは地味ですが、実際に困っている組織が多い領域です。 文書レビューの進捗は、文書を1つずつ開いて確認するしかありませんでした。 10本の文書を複数人でレビューしている状態で、「あと何が残っているか」を把握する手段がありませんでした。

導入時に決めるべきことを、3つ書きます。

1つ目。提案とコメントの使い分けの基準です。

原則は、こうです。機械的に判定できるものは提案、判断が必要なものはコメント。 表記の統一、明らかな誤字、形式の不備は提案。内容の妥当性、意図の確認、リスクの指摘はコメント。

この線を曖昧にすると、承認作業が危険になります。 判断が必要な事項が提案として並んでいると、承認ボタンを連続で押す流れの中で、確認せずに通ってしまいます。 人は、同じ操作を繰り返すとき確認を省きます。提案に入れるものを絞ることが、レビューの質を保ちます。

2つ目。アクセス権限です。

API から文書を操作するには、その文書へのアクセス権が必要です。 自動化の仕組みにサービスアカウントを使う場合、そのアカウントがどの文書を読めるかを設計する必要があります。

管理者が「アプリの Workspace データへのアクセスを制限できる」と公式が書いている点は、ここに関わります。 自動化の仕組みが、意図しない範囲の文書を読める状態になっていないかを確認してください。 文書の自動処理は、権限設計を間違えると情報漏洩の経路になります。

3つ目。提案の量の制御です。

網羅的に提案を出せるということは、大量の提案を出せるということです。 1つの文書に200件の提案が付いた状態は、レビューできません。 担当者は全部承認するか、全部却下するかを選ぶことになり、どちらにしてもレビューとして機能しません。

実務的な上限を決めてください。 文書あたり何件までにするか、優先度の高い指摘だけに絞るか。「全部出す」は、技術的に可能でも運用上は失敗します。

最後に、この更新を Gemini の文脈へ置く視点を1つ。

同日、Google は skills の導入と Gems の廃止日程を発表しています。 こちらは利用者がプロンプトで Gemini を使う側の機能です。今回の API 更新は、開発者がシステムを組む側の機能です。

両者を合わせると、「Workspace の中で AI の出力を人のレビューへ載せる」という方向が見えます。 skills で指示を再利用可能にし、API で出力を提案として文書へ入れる。AI が文書を作る工程と、人が承認する工程を、Workspace の中で完結させる構成です。

副業・個人活用視点

個人開発と受託の両方で、これは作れるものを増やす更新です。

まず、受託の文脈です。ここに明確な案件があります。

「文書チェックの自動化」は、相談として来る頻度が高いテーマです。 契約書、仕様書、マニュアル、提案書。どの業種にもチェックが必要な文書があり、人手で見ています。

これまで、この相談への回答は難しかったです。 AI でチェックして修正する仕組みは作れますが、顧客は「勝手に書き換えられる」ことを受け入れません。 結果として、「チェック結果をレポートで出す」という構成に落ち着きます。 これは作れますが、顧客はレポートと文書を見比べる作業が残るため、楽になった実感が薄いです。

提案として文書内へ入れられるなら、この問題が消えます。 チェック結果が、該当箇所に提案として付いている。 顧客は文書を開いて、提案を順に処理すればよい。レポートを見比べる作業がなくなります。

提案の見せ方として、この差は大きいです。 「チェックしてレポートを出します」と「文書の該当箇所に提案が付きます」では、後者の方が価値が伝わります。 デモで見せたときの反応も違います。

構築する際の設計方針を書きます。

提案とコメントの使い分けを、顧客と先に合意してください。 機械的に判定できるものは提案、判断が必要なものはコメント。この基準を文書化しておくと、「なぜこれは提案じゃないのか」という議論を繰り返さずに済みます。

提案の件数に上限を設けてください。 網羅的に出すと、レビュー不能になります。優先度を付けて、上位N件だけ提案として出す構成が実用的です。 残りはコメントで「他に○件の軽微な指摘があります」と伝える、という設計もあり得ます。

権限設計を軽視しないでください。 サービスアカウントが顧客の文書を読む構成になります。どのフォルダまで読めるかを明確にし、文書で残してください。 情報セキュリティの審査で必ず問われます。

次に、個人の作業効率という観点です。

自分の文書作業に対して、提案ベースの自動処理を組めます。

使いどころとして現実的なのは、公開前のチェックです。 ブログ記事、提案書、納品物。自分で書いたものを自分でチェックするのは、最も見落ちが出る作業です。 書いた直後は、間違いが見えません。

提案として入れる構成なら、1件ずつ確認できます。 「ここは直す」「ここは意図的だから却下」。全文を書き換えられると、どこが変わったか追いきれません。

コメントの読み取りも、個人では使えます。 複数のドキュメントに残した自分のメモやコメントを集約する。「あとで確認」と書いて放置したコメントを一覧にするという処理は、個人でも効きます。

学習の観点では、「書き換えるのではなく提案する」という設計原則そのものに注目する価値があります。

これは、自動化の設計で繰り返し使える判断です。

自動化を作るとき、「確定的に実行する」か「提案して人が決める」かを選ぶ場面が必ず来ます。 そして、提案型を選べるかどうかは、対象システムが提案という状態を持っているかに依存します。

持っていない場合、自分で作ることになります。 変更前後を並べて見せる、差分を出す、承認キューを作る。これは実装コストがかかるため、多くの場合は確定的な実行が選ばれます。 そして、間違ったときの被害が大きくなります。

今回の更新は、Google Docs において提案という状態がすでにあり、そこへ API からアクセスできるようになったという話です。 自分で承認フローを作らずに、提案型の自動化が組めます。

この視点で、他のシステムも見てみる価値があります。 「このシステムに、提案や下書きの状態はあるか」。あるなら、そこへ出力を入れる設計を選べます。 ないなら、確定的に実行する設計のリスクを、先に評価する必要があります。 自動化の安全性は、対象システムが持つ状態の種類に大きく左右されます。