Googleドキュメントの提案モード｜修正案を出し、承認・却下する手順

こんにちは！なかびーです。

共有している文章を直したいとき、すぐに本文を書き換えると、元の表現と修正理由を相手が比べられないことがあります。Googleドキュメントの提案モードは、追加や削除を修正案として残し、採用するかを判断するための機能です。書き直す操作と、その変更を確定する操作を分けて考えられます。

この記事ではPCのGoogleドキュメントを想定し、提案への切り替え、短い変更の出し方、理由の返信、個別の承認・拒否、一括判断前のプレビューを整理します。画面はアカウント、権限、言語、更新で異なるため、手元の項目を読んでください。この記事が実際の相手へ修正案を送り、採用されたという体験談ではありません。

教材は架空の「作業見本会の説明」です。原文は「見本は三つです。作業の順番を説明します。説明のあとで、内容を見直します。」という短文にします。開催が決まったイベントでも、実在する依頼の原稿でもありません。変更案の数や採否も、仕組みを考えるための教材であり、実機で処理して測った件数ではありません。

1．元の文書と、提案する範囲を先に確認する

何を直す相談かを一つに絞る

文章を読みながら気になる箇所が見つかっても、最初に「何を判断してほしいか」を整理します。誤字を直すのか、情報を更新するのか、表現を分かりやすくするのかで、必要な説明が違います。教材では見本の数を変える案、説明の対象を補う案、冗長な言葉を除く案を、別の理由を持つものとして扱います。

一つの提案へ段落全体の修正を詰め込むと、相手はどの変更へ同意するかを選びにくくなります。内容の変更と表記の修正を分けられるなら、短い範囲ごとに考えます。細かくすれば必ずよいという意味ではありません。一つの判断で採用か不採用を決められるまとまりが、今回の目安です。

文書名と対象の本文を読む

開いているファイルが直す対象かを、文書名と本文で確かめます。同じ名前のコピーや、古い練習版があると、正しい操作をしても違う文書へ提案を残すことになります。教材なら「練習・作業見本会の説明」とし、冒頭に架空の練習文だと書いて区別する例です。実在の連絡先や未公開の顧客原稿を持ち込む必要はありません。

本文の最初と最後を読めば、対象が一致するか確かめる入口になります。「三つの見本」の説明なのか、別の作業手順なのかを見ます。相手からリンクを受け取った場合も、そのリンクが編集してよい対象かは別に確認します。文書を開けたことだけで、すべての内容を直してよいという担当範囲まで決まったとは考えません。

提案できる権限と、採否を決める役割を分ける

Googleの公式説明では、コメント権限または編集権限を付与されたユーザーが編集を提案できます。提案の項目が見当たらない場合に、権限を確認することも案内されています。自分にその操作ができるかと、業務上どこまで判断してよいかは別の問いです。この記事のために共有範囲を広げたり、権限を取り直したりする必要はありません。

実際の仕事なら、誰が修正案を出し、誰が採用を決めるかを合わせます。操作できるから自分が全部承認する、という進め方にはしません。教材では「提案する側」「採否を確かめる側」という二つの役割を想像して読みますが、本物の相手が参加した事実はありません。一人で操作を試した場合も、独立した他者の承認を得た記録とは分けます。

変更前の文章を比較の入口にする

教材の原文では見本が三つ、説明するのは作業の順番、最後に内容を見直す流れです。まずこの三つを短く読めることを確かめます。修正後だけを見ると、何を変えたのかが曖昧になります。提案を出す前に、元の文がどんな意味かを言葉にしておくと、色付きの追加や取り消し線を見たときも意味をたどれます。

原文の数値は架空設定です。現実に三つあることを確認したわけではなく、修正案を使って「三つを二つへ変えたら意味が変わる」と理解するために使います。教材を仕事へ置き換える際は、確認済みの資料や担当者の判断に基づいて提案してください。古い表現を新しい事実へ直す場面と、単に言い方を整える場面を同じ理由にはしません。

2．提案モードへ切り替え、短い変更から始める

編集・提案・閲覧のどれを開いているか見る

公式のPC向け手順は、右上の編集アイコンのメニューから提案を選ぶ方法を案内しています。変更対象を選択し、右余白の提案アイコンから入る方法もあります。今回は、最初に現在のモードを読んでから、提案へ切り替える流れで考えます。表示が似ていても、直接編集しているのか、修正案を残しているのかを区別します。

本文をすでに消してから提案へ切り替えても、その前の操作を提案として残したと決め付けることはできません。何を直すかを決め、モードを確認し、それから短い範囲を変更する順序にします。既存の仕事用文書で確かめるより、無害な練習文で一つだけ試す方が、自分がどの操作をしたかを追いやすくなります。

色は候補を読む手掛かりにする

公式では、変更した箇所は別の色で表示され、削除した箇所には取り消し線が付くと説明しています。色はすべての人や環境で必ず同じ色とは限りません。「緑だから自分」「赤だから拒否」といった独自の意味を色だけへ与えず、どの文字が追加候補で、どの文字が削除候補かを本文と提案欄で確かめます。

提案が見えることは、その内容が正しいと確認できたことではありません。教材の三つを二つへ変える案も、色付きで残せれば操作上の候補になったという段階です。実際に二つだという根拠は別に必要になります。表示を正しく読めることと、変更の妥当性を判断することを分けると、操作ができた勢いで内容まで確定しにくくなります。

最初は一つの語だけを対象にする

教材の最初の案は、「三つ」を「二つ」へ置き換えるものです。対象の語を選ぶときは、助詞や句点まで必要以上に含めていないかを見ます。変更後に文が「見本は二つです」と読めるか考えます。提案がどんなまとまりで表示されるかは手元で確認し、この記事が実際の提案スレッドの数を測ったものだとは読み替えないでください。

大きい範囲を選んで同じ文を書き直すと、変更していない文字まで差として読まれる可能性を考える必要があります。今回は短い語から始め、元の意味と候補の意味を比べます。文章全体を改稿する場合もありますが、そのときは一語の修正とは別に、どの範囲を見てほしいか説明することが大切です。

提案になったかを本文と欄の両方で確かめる

変更を入れた後は、元の文字と新しい候補の対応が読めるか確認します。本文を見ているだけで分からなければ、提案の欄を選び、どの範囲を扱うものかを見ます。別の提案を選んだまま理由を書くと、相手が違う箇所への説明だと受け取るかもしれません。対象の文字と、今選んでいる提案を対応させましょう。

画面が狭くて欄の表示が変わっている場合も、同じ見た目へ合わせるために設定を増やす必要はありません。今の画面で提案の対象をたどれるかを優先します。見えないから直接編集へ切り替えて先へ進むのではなく、どのモードで、どの範囲を変更したかを読める状態で一区切りにします。

3．追加・削除・置換と、理由のコメントを対応させる

追加は、元の文に何を補う案かを書く

二つ目の教材案は、「作業の順番を説明します」の前に「最初に、」を加えるものです。説明の始まりが分かるようにしたい、という理由の候補になります。追加するだけでも、文全体の読み方が変わることがあります。すでに別の文に「最初に」があるなら重複するかもしれません。挿入した語だけでなく、前後の文を読みます。

理由を書くなら、「短くしたい」「分かりやすくしたい」だけでなく、どこで読み手が迷うかを示せます。教材なら「説明と見直しの順が分かるよう、説明する文を先の行動として示す案です」とします。効果を実際に測っていないので、「この追加で理解率が上がった」などの結果は作りません。目的を説明することと、効果を確認したことを分けます。

削除は、意味まで消していないかを見る

三つ目の案を考えるため、練習用に「説明のあとで、内容をもう一度見直します」という文があると仮定します。「もう一度」を外して「内容を見直します」とする案なら、何を簡潔にするかを比べられます。ただし本来二回目の確認を伝えたい文なら、言葉を削ることで大切な意味を落とすかもしれません。短ければ必ずよいとは考えないことが要点です。

この追加の文は、原文へ無言で事実として混ぜず、削除を考える別の練習例として扱います。実際の原稿を修正するときも、対象が変更されていたら、以前見た文への理由をそのまま使わないようにします。どの文字が今の原文で、どの案を比較しているのかを、提案する側も読む側もそろえる必要があります。

置換は表記の修正と内容の変更を分ける

「三つ」を「二つ」へ変える教材案は、単なる見た目の変更ではありません。読む人が想像する見本の数が変わります。採用の判断では、数を二つとする根拠があるかを確認する必要があります。一方、「３つ」を「三つ」へそろえる案なら、同じ数をどう表記するかの相談です。同じ短い置換でも、確認する理由が違います。

一つの説明で両方を済ませると、表記を統一するつもりで数まで変えることがあります。教材では「内容の変更」「表記の変更」とメモで区別してみます。これはGoogleドキュメントが自動で分類してくれる設定ではなく、提案の目的を整理するための書き方です。必要な根拠がまだないなら、内容を確定せず確認事項として残します。

提案への返信と、普通のコメントを使い分ける

公式の提案手順では、詳しい説明を添えるとき、提案を選んでコメントを入力し返信できます。本文の別の箇所へ一般のコメントを付ける方法もあります。特定の修正案の理由ならその提案へ対応させ、文章全体への問いならどの範囲への質問かを分かるようにします。コメントの数を増やすことより、何について答えるかを読めることが大切です。

返信へ「確認しました」と書いても、何を見たかが分からなければ採否は判断できません。「二つとする根拠は未確認」「順番を明確にする案として検討」といった形で、分かっていることを具体化します。教材の相談を本物の相手が承認したように記録せず、自分で試した範囲なら自己確認と分けておきます。

横に長い表は、画面に収まらないとき横へスクロールして比較してください。

4．個別に承認・拒否し、反映された本文を読む

採用する理由を提案ごとに確かめる

公式では、対象の提案を選び、承認または拒否のアイコンで扱いを決める手順が案内されています。本稿の題名でいう「却下」は、この拒否する判断を指します。どの提案を操作しているかを本文と欄で確かめてから、必要な判断を行います。別の提案の説明を読んだまま隣のアイコンを押さないようにします。

教材なら、順序を補う追加案は採用を考えられても、数を変える根拠がない置換案はそのまま採用できない、という比較ができます。どちらも実際の業務上の承認ではありません。目的は、一つの提案に同意したから別の提案も正しい、という読み方を避け、変更ごとに理由を確認することです。

承認後の文字を、残したい意味と比べる

承認した場合は、候補が本文へどう反映されたかを読みます。追加案なら挿入した位置が合うか、削除案なら必要な言葉までなくなっていないか、置換案なら前後の助詞や句点が自然かを見ます。承認の操作が受け付けられたことだけで、完成した文が目的に合うと決めません。操作と内容を別々に確認します。

数を二つへ変える案を採用したと仮定する場合は、同じ文書のほかの箇所に三つと書いた説明が残っていないかも見る観点になります。教材の短文には大きな表はありませんが、実際の文書では見出しや表に同じ情報があるかもしれません。修正範囲を超えて勝手に一括置換する前に、同じ根拠で直せる対象かを確かめます。

拒否は、相手の意見全体を否定した記録にしない

拒否する対象は、その文書のその修正案です。教材で数の変更を採用しないなら、「三つの設定を維持するため、二つへの変更は使わない」と理由を残せます。提案者が間違っているという広い評価をする必要はありません。別の案や、次の原稿で使える着想まで同じ扱いにせず、今回の判断範囲を示します。

理由が分からないまま拒否するより、確認待ちの点があるなら、それを先に質問として整理できます。ただし、この記事はすべての案件で返事を待たなければ操作できないという規則を作るものではありません。担当と判断の範囲が決まっている場合は、その範囲で進めます。決めていないことを決まったと記録しないことが大切です。

コメントの解決と、提案の採否を混同しない

Googleのコメント説明では、話し合いが終わったコメントを解決して閉じる操作があります。これは修正案を本文へ採用する操作そのものとは分けて読みます。質問への返事が済んだことと、該当の提案を承認または拒否したことを、同じ完了記録にまとめないようにします。画面から欄が見えなくなった理由も、操作に沿って確かめます。

「確認しました」という返信の後、提案はまだ未処理という場面も考えられます。逆に採否を処理しても、別の質問が残っている場合があります。教材では、文をどう変えたかと、理由の確認がどこまで済んだかを別々に読みます。コメントを隠しただけで相談も提案も全部終わった、という推測をしない確認です。

採用した案だけで、残る一文を組み立ててみる

教材の基本の原文へ戻り、数の置換を拒否し、「最初に、」の追加を承認した場合を紙の上で考えます。残したい文は「見本は三つです。最初に、作業の順番を説明します。説明のあとで、内容を見直します。」です。これは実際のアプリが返した本文の転記ではなく、二つの判断から考える期待する文章です。手元で練習した場合は、その文字が実際の本文にあるかを比べます。

この結果では、数は三つのまま、行動の順序だけを補っています。本文が二つになっていたら、紙で考えた判断とは違う状態です。数の案も承認したのか、別の編集があったのか、違う文書を読んでいるのかを分けて確認します。色が落ち着いたから正しく反映したはず、と判断せず、期待する意味を文字にしてから読む練習です。

削除の例は、途中で示した「もう一度」を含む別の練習文に対するものです。基本の原文にはその語がありません。基本の原文だけを使っている場合、削除する箇所を作るために無理に文章へ足す必要はありません。追加と置換の二つだけでも、候補と採否の関係を学べます。自分が使っている原文に合わせて、適用できる例を選ぶことが大切です。

削除の別練習を行う場合は、そちらの原文を「説明のあとで、内容をもう一度見直します」と決め、その語を残す場合と外す場合を比べます。原文が違う二つの例を、一つの連続した実行記録として読まないようにします。実際の原稿へ置き換えて使うときも、今見ている版と修正理由が対応しているかを確かめれば、古い例の条件を持ち込みにくくなります。

5．一括判断の前に、承認・拒否した場合をプレビューする

一括操作は、同じ判断でよい範囲を先に決める

提案が多いときは、すべてを一つずつ操作する手間が気になることがあります。公式には、ツールから編集の提案を確認し、全部を承認または拒否した結果をプレビューする方法があります。まず、今ある提案の種類を見ます。根拠の確認が必要な数の変更と、同じ方針でそろえる表記を、件数だけでまとめて扱わないようにします。

教材では、三つを二つへ変える案と、順序の説明を補う案は同じ理由では判断できません。そのため最初は個別に読む方が、何を採用したか説明しやすくなります。全部承認が必ず悪いという話ではなく、全件を同じ扱いにしてよいと確認できているかが先です。一括の操作を使う目的と、判断を省くことを分けます。

プレビューと実際の採用を別に扱う

公式の手順では、すべて承認した場合、すべて拒否した場合をプレビューできます。結果を先に読む段階と、実際に一括の採否を選ぶ段階は別です。候補を見たからもう本文へ反映されたと思い込まず、今表示しているのはどの状態かを確かめます。画面の言葉を読み、試しに見た状態を確定結果として報告しないようにします。

すべて承認した場合を読むなら、文全体の意味がつながるかを見ます。すべて拒否した場合を読むなら、元の文章を維持したときに不足する情報は何かを考えます。二つを比較しても、両方の中間を自動的に選べるという意味ではありません。必要な案だけ採用したいなら、それぞれの対象と判断へ戻って進めます。

文を通して読み、局所の正しさだけで終えない

短い追加は、それだけを見ると自然でも、別の提案と組み合わさると重複するかもしれません。教材の「最初に、」を足した後、前の段落にも同じ順序を示す文があれば、繰り返しになります。一語ごとの正しさと、文章全体での役割は別に読む必要があります。プレビューはその組み合わせを考える入口になります。

数字や条件を変更した場合は、文の読みやすさだけでなく内容の整合を見ます。二つの見本としたのに、後で三つ目を説明する文があれば対応しません。実際の文書に対象が広がるときも、どこまで同じ修正の根拠を使えるかを考えます。手早く見たことを、全文の事実検証まで済んだ記録へ広げないようにします。

提案を一括処理する前のメモを残す

判断の準備として、「表記をそろえる案は確認済み」「数の変更は根拠未確認」「説明の追加は前後を読み直す」と短く分けられます。Googleの機能がこの分類を必ず自動で付けるわけではありません。人が内容を読むための整理です。何件あったかだけでなく、何について判断したかが分かるメモにします。

実務で相手の確認が必要なら、今残っている提案と、尋ねたいことを対応させます。すでに処理した案まで未確認として送り直すと、同じ判断が繰り返されることがあります。逆に、一部の返事だけで全部確認済みにしないよう、返答がどの箇所へ適用されるかを読みます。確認する側の時間を使うためにも、質問は対象を分かる形にまとめます。

6．採否後の本文と、残る提案・質問を別々に見直す

最終文として何を読むかを決める

提案を扱い終えたら、本文を先頭から読みます。教材なら見本の数、説明する順番、最後の見直しが、残したい意味と対応するかを確認します。提案欄の数が減ったことだけで本文が完成したとは扱いません。色がなくなった部分にも、採用した文字が意図しない場所へ入っていないかを読む必要があります。

別の表示へ切り替えたときに提案が見えなくなっても、処理が済んだ証拠とは限りません。今のモードと表示、コメントの一覧などを確かめます。見た目がすっきりしたことと、修正案を判断したことを分ける考え方です。印刷や配布へ進む場合も、何を最終文として確認したかが言える状態にします。

残っている提案と、未回答の質問を数え方から分ける

本文へまだ反映していない提案と、コメントで尋ねた未回答の問いは、別の単位です。一つの修正案へ二つの質問をした場合、質問への返事が一つ届いても、すべて解決したとは言えません。教材では「数の根拠」「順序の説明」というように対象を書き、何が残っているかを言葉で示す方法を考えます。

反対に、同じ理由を別々の欄へ重ねて書いているだけなら、未完の仕事が二つあるとは限りません。件数を増やして管理するより、残る判断は何かを整理します。操作画面が示す数と、内容上の確認事項の数が同じとは限らないためです。本稿は画面の件数を実測していないので、教材の三案を実際のスレッド三件として断定しません。

途中で原文が変わったら、提案の対象を読み直す

共同の文書では、自分が読み始めたときと、判断するときで周囲の文章が違っていることも考えられます。提案の理由を前の状態のまま使わず、今の本文へ戻ります。「最初に」を追加する案が、別の編集で同じ語が足された後にも必要かを考える場面です。過去に妥当だった案が、今も同じ条件とは限りません。

対象が変わっていて分からなくなったときは、すぐ文書全体を元へ戻す作業へ進まず、どの文とどの提案を見ていたかを整理します。この記事は変更履歴からの復元手順を実演するものではありません。現在の文字、残っている案、判断の根拠を分け、必要な確認へつなげる考え方です。未知の原因を決め付けて操作を重ねないようにします。

数字と参照語を続けて読み、局所の変更を照合する

反映後の本文を読むときは、変更した語と、その語を受ける説明を一緒に見ます。「見本は二つ」に変えたなら、その後の「三つ目」「すべての見本」「残りの一つ」といった表現も確認の手掛かりになります。必ずその語が文書にあるという意味ではありません。対象の情報がほかでどう使われているかを考えるための読み方です。

ただし、同じ数字が見つかったら全部同じ理由で変えられるとは限りません。見本の数の三つと、説明の手順の三つは別の対象かもしれません。検索で同じ文字を見つけることと、同じ内容を指すと判断することを分けます。教材の短文では見本の数だけを変える案なので、作業手順の数まで自動的に修正する根拠はありません。

指示語も同じように読みます。「これを確認します」という文の前を削った結果、これが何を指すか分からなくなることがあります。短くする提案を採用するときは、削った語の分だけ文章が簡潔になったかだけでなく、残した文から対象をたどれるかを見ます。局所的には自然な一文でも、前後の対応がなくなれば、読む人の手掛かりは減ってしまいます。

この点検で新しい修正が必要だと気付いたら、前に承認したことを隠すために無言で全体を書き直すのではなく、今回追加する対象を決めます。決まった誤字の修正なのか、また判断が必要な提案なのかを選びます。作業の段階を戻すことはありますが、何を新たに検討するかが分かれば、済んだ確認を全部やり直す必要があるかも判断しやすくなります。

確認の区切りには、変更した対象を一つ言い直してみます。「見本の数は維持し、順序の語だけを補った」と説明できれば、同じ文を見直すときの目印になります。何が変わったかを自分でも説明できない状態なら、見た目だけで完了へ進めず、採用した対象と本文の対応へ戻ります。

作業報告は、提案・判断・反映の段階を示す

報告するときは、「短い追加案を残した」「数の変更は採用しなかった」「反映後の本文を読んだ」のように、確認した範囲を分けて書けます。「修正完了」だけでは、提案した段階なのか、採用が決まった段階なのか、本文まで読んだ段階なのかが分かりません。相手が次に何をすればよいか分かる程度に具体化します。

資料の編集を仕事として任される場合は、オンライン秘書の担当業務と確認範囲を整理するガイドも、作業の境目を考える参考になります。提案モードが使えることと、内容の確定や外部への送信まで担当してよいことは別です。本稿の教材では、実在の相手への共有、通知の送信、第三者の採用判断を行っていません。

最後は、原文を読む、候補を出す、理由を対応させる、採否を判断する、反映後の文を読むというつながりを確かめます。機能を覚えるだけでなく、何を変える相談なのかを言葉にしておくと、小さな修正でも対象と判断を追いやすくなります。自分の練習では、無害な短文から一つずつ確かめてください。

確認した公式資料：Googleドキュメントで編集を提案する、コメントの追加・返信・解決。確認日：2026年10月25日。機能説明を参照し、見本会の文章と修正理由は本稿の独自の架空教材として作成しています。