「もっと具体的に」「わかりやすくしてください」。原稿の余白にそう書いても、執筆者は何を残し、どこまで変えてよいかで迷います。
原稿の赤入れでは、直したい箇所、読者が困る理由、次にしてほしい作業をつなげて書きます。修正文を提案できる箇所と、根拠や発言の確認が必要な箇所も分けます。確認できていない情報まで、完成した修正文へ入れないことが大切です。
この記事は、企業の記事を確認して執筆者へ戻す編集・広報担当者に向けた実務案です。紙の校正記号一覧ではなく、文書のコメントや変更提案で意図を伝える方法を扱います。以下の原稿・製品名・コメントはすべて編集部の架空の作例で、顧客案件や実測の改善事例ではありません。
カバーは、原稿とコメントの関係を表した生成イラストです。実際の原稿や納品物を写したものではありません。
まず、何をどこまで確認するかをそろえる
赤入れを始める前に、今回の原稿の段階と、自分が判断できる範囲を確かめます。構成から見直す初稿と、公開直前の誤記確認では、戻す修正の大きさが変わります。
たとえば、企業メディアの初稿を戻すなら、次のように依頼文へ書けます。
今回は、経理担当者が製品の用途と導入条件を理解できるかを中心に確認します。構成・説明の不足は変更案を付け、数値と取材発言は確認事項として残します。表記は共有の用字表に合わせます。回答が必要な項目には担当と返答日を記します。
これはそのまま全案件に適用する決まりではありません。実際には、依頼書、編集方針、確認者の権限、締切に合わせて調整します。構成変更が範囲外でも、重大な事実の疑義を見つけたら、無視せず担当へ戻してください。
英国教育省のコンテンツ指針は、レビューに先立ち、文脈、求めるフィードバック、その渡し方を説明するよう案内しています。これは同省の運用ですが、企業の記事でも確認範囲を共有する参考になります（Quality and assurance）。
用語や工程が曖昧なら、赤入れ・校正・校閲などの用語集で、相手と同じ意味で使っているかを先に確かめられます。
「修正する」「提案する」「確認する」を分ける
赤入れの書き方は、修正内容を確定できるかで選びます。理由が確かな誤記を直す作業と、未確認の数字を尋ねる作業を、同じ「要修正」にまとめないようにします。
| 扱い | 向く場面 | 伝える内容 |
|---|---|---|
| 修正 | 原典や適用ルールで正しい形を確認でき、担当範囲内で直せる | 変更箇所と根拠。意味への影響があれば再確認先も残す |
| 提案 | 伝わり方を改善する複数案があり、選択が必要 | 読者が困る点、変更案、残したい意図 |
| 要確認 | 数字、発言、提供条件などを手元の資料で確定できない | 不明点、確認先・資料、回答後に変える箇所 |
この3区分は本記事の整理方法です。英語の編集者団体CIEPに掲載された著者向け解説でも、編集者だけで解決できない事項や承認が必要な変更について、著者への質問を行うと説明しています。回答形式は一律ではなく、当事者間で決める扱いです（What are queries, and how should an author respond?）。
すべての修正に長いコメントを添える必要はありません。共有済みのルールに沿う軽微な誤記は、その運用に従います。一方、発言の意味、数値の確度、製品の能力を変える修正には、判断をたどれる記録が必要です。
一つの原稿に、どんなコメントを付けるか
以下の架空原稿を、初めて製品を知る経理担当者向けの記事として確認します。手元にあるのはこの段落だけで、性能資料や取材記録はまだない、という設定です。
架空の原稿
経費精算サービス「Kiro」は、AIで業務を効率化します。導入すると、すべての企業で月末の作業時間を30%削減できます。開発担当者は「確認の負担が減る可能性がある」と話します。詳しい設定方法は後半で紹介しますが、領収書の入力を支援する製品です。
ここで「30%を20%へ変える」「可能性があるを削る」と直しても、根拠を補ったことにはなりません。読みにくさと、確認できない主張を分けて戻します。
| 対象箇所 | コメント例 | 次に必要な作業 |
|---|---|---|
| AIで業務を効率化 | 【提案】経理のどの作業を支援するかがわかりません。段落末の「領収書の入力を支援」を冒頭へ移す案です。製品の機能として正しいかも確認してください | 説明順を変更し、機能の範囲を確認する |
| すべての企業で／30%削減 | 【要確認】対象企業、比較期間、測定した作業、元の資料を確認できますか。全社に当てはまる根拠も必要です。確認できなければ効果の断定を外す案です | 製品担当者が根拠を提示し、掲載範囲を決める |
| 開発担当者の発言 | 【要確認】取材記録と掲載可能範囲を照合してください。「可能性がある」は確度を示すため、確認なしに言い切りへ変えません | 発言・話者・前後の文脈を確認する |
| 詳しい設定方法は後半 | 【提案】後半に対応する説明があるか確認し、あれば見出し名やリンクで案内してください。なければ予告を外してください | 原稿全体を見て参照先を決める |
この段階で、修正例を「領収書の入力を支援するKiroは、月末の作業を短縮します」と完成させるのも早計です。入力支援の機能を確認できても、短縮効果まで確認したことにはならないからです。
機能だけ確認でき、数値と発言は確認が済んでいないなら、機能説明のみの案を別に用意し、未確認の部分を公開用本文から外す判断ができます。反対に、取材記事の中心がその効果なら、裏付けの不足を説明の工夫だけで埋めず、追加確認まで公開を待ちます。
曖昧な感想を、相手が動ける指示へ変える
修正指示は、書き手への評価ではなく、読者がつまずく箇所に結び付けます。「弱い」「冗長」という感想を、原稿のどの関係を変える話なのかへ置き換えます。
たとえば、冒頭に専門語が続く段落なら、次のように伝えられます。
コメント例： 初めて担当する読者には、この略語が何をする仕組みか伝わりません。初出の直後に、担当者のどの作業と関係するかを一文添える案です。専門用語自体は残し、正式名称と機能の範囲を原資料で確認してください。
単に「短く」では、削ってはいけない条件まで消える可能性があります。重複が理由なら、残す情報を指定します。
コメント例： 第2段落と第4段落が同じ導入手順を説明しています。第2段落にまとめ、第4段落は例外条件だけ残す案です。対象部署と利用条件は削らないでください。
案を決めきれない場合は、無理に完成文を示すより「この節で読者に何を判断してほしいか」を質問します。企画から変える必要があるなら、単語の修正を大量に付ける前に、その変更を相談します。
媒体の表記の好みと事実の誤りも分けます。「Webをウェブへ」は、固有名詞や引用に含まれるかで扱いが変わります。表記ルールの作り方を参照し、対象範囲と例外を近くに残してください。
指示が重なったら、執筆者へ戻す前に整理する
複数人の赤入れは、矛盾を確認担当者側で整理してから戻します。一人が「詳しく」、別の人が「半分に」と書いたまま渡すと、どちらの目的を優先するかが執筆者へ移ってしまいます。
同じ段落への指示を並べ、両立できるかを見ます。たとえば「本文を短くして、操作手順は別枠へ移す」なら一つの案にできます。対象読者そのものが違うなら、企画の判断者へ戻す必要があります。合意していない案を「編集部で決定」とまとめないことも大切です。
整理
同じ箇所の指示を集め、矛盾と重複を確認する。
回答
誰が、何を根拠に、いつまでに答えるかを決める。
反映
採用・不採用・未決を分け、回答しただけで反映済みとしない。
再確認
修正文と周辺、見出し・図表・説明文への波及を照合する。
返答欄には「対応しました」だけでなく、何をどう変えたか、採用しなかった場合の理由、未決事項を残します。修正指示を取り消すときも、削除線を消すだけではなく、どの指示を取り消して元に戻すかを明示します。
文書の提案機能と、公開判断を分ける
Googleドキュメントでは、元のテキストを直接置き換えずに編集を提案でき、提案は承認・拒否できます。理由を添えるコメントも使えます。具体的な操作と必要な権限は、Google公式ヘルプで確認してください。
ただし、提案が承認されたことは、その数字の検証や取材先の掲載確認が完了した証拠にはなりません。「文言の反映」「事実の確認」「掲載の判断」は、それぞれ実際の担当と結果で確認します。文書の共有範囲も案件に合わせて決めてください。
原稿を戻す際は、対象版、今回見てほしい範囲、回答が必要な項目と担当、返答日を短くまとめます。取材先に送る確認依頼そのものは、取材原稿の確認依頼とメール例文を使い分けられます。
最後はコメント数ではなく、本文を通して読みます。修正により主語が変わっていないか、条件が消えていないか、見出しや図表に古い数字が残っていないか。公開前の画面でも、本文・画像の説明・リンクを確認します。指示を付けた記録と、直った原稿の両方がそろって、赤入れを次の工程へつなげられます。
参照資料
- 英国教育省：Quality and assurance — レビューの文脈・求める内容・渡し方、最終版を実際の文脈で確認する運用を参照。同省の運用を企業の義務として示すものではありません。
- CIEP：What are queries, and how should an author respond?（2024年1月19日） — 著者への質問の役割と、回答の形式を当事者間で決める説明を参照。掲載著者の解説です。
- Google：Googleドキュメントで編集を提案する — 提案・承認・拒否とコメントの機能を参照。
資料確認日：2026年10月15日。3区分、架空原稿、コメント、確認手順は編集部の提案です。特定のツールの利用で誤りや手戻りがなくなると保証するものではありません。
