長文の下書きを作るならどのAI？

長文の下書きを作るなら、最初から全文を書かせるより、構成、資料、章ごとの執筆、全体レビューを分けられる環境を選びます。会話しながら章を詰めたいならChatGPT、プロジェクトに資料と指示を置いて継続するならClaude、Google Driveの資料を参照してDocsで仕上げるならGeminiが候補です。長文の完成度は同条件で比較していないため順位を付けません。

「長く書ける」と「長文を完成できる」は違う

長文の失敗は、文章が途中で止まることだけではありません。導入で約束した内容が後半にない、同じ説明を繰り返す、章ごとに用語が変わる、資料の数字と本文が食い違う、といった問題もあります。下書きの長さより、途中で方向を直せるか、全体の矛盾を見つけやすいかが実務では重要です。

選ぶ前に、完成物を次のどれにするか決めます。

• 既存資料をまとめた報告書

• 読者の疑問へ順番に答える記事

• 複数人で更新する社内手順書

• 調査結果と出典を残す提案書

• 構成案を何度も変える企画書

同じ「長文」でも、資料の出典を維持する文書、複数章の論理をつなぐ文書、チームで更新する文書では必要な機能が違います。

作業フローから候補を選ぶ

表は横にスクロールできます

作業の中心	候補	選定の見どころ	先に確かめること
構成案と本文を会話で往復する	ChatGPT	Projectに関連チャット、ファイル、指示をまとめられる	プロジェクトのファイル上限・機能が利用条件に合うか
複数資料と指示をプロジェクトに置く	Claude	Projectsに資料と専用指示を持たせられる	プランで使える容量・機能と、資料の更新方法
Driveの資料からDocs原稿へつなぐ	Gemini	Docsで文章作成・推敲し、選んだDrive資料を参照できる	利用アカウント、Workspace設定、対応言語
どれが読みやすいか決める	同一条件の試作	自分の読者と資料で評価できる	テーマ、資料、字数、修正回数をそろえる

OpenAI Projectsは、関連する会話・ファイル・プロジェクト指示をまとめる仕組みです。Claude Projectsは知識ファイルとプロジェクト専用指示を扱えます。Gemini in Docsは下書き、既存文章の改善、選択したファイルを情報源にした作成を案内しています。利用可能な機能やプランは変わるため、契約前に各公式案内と自分の画面で確認してください。これらは作業場所の特徴であり、事実確認や編集判断を自動で代行する保証ではありません。

下書きの前に「文書の設計図」を作る

書き始める前に、次の設計メモを一枚作ります。見出しを先に大量生成するのではなく、読者が読み終えたときにできることから逆算します。

読者と状況：誰が、何に困っているか

読後の状態：何を決める、作る、説明できるようにするか

中心の答え：冒頭で伝える結論または判断軸

根拠資料：どのファイルのどの箇所を使うか

章の役割：各章が読者の疑問を一つずつ解消する

保留事項：資料にないこと、確認が必要なこと

完成条件：長さではなく、必要な情報・検証・次の行動がそろった状態

各章の役割は「背景を説明する」だけで終えず、「読者が何を判断できるようになるか」で書きます。たとえば社内導入提案なら、現状の困りごと、候補の比較、導入前の条件、試行方法、判断の順に配置します。候補機能を並べるだけでは、誰が何を決める資料なのかが見えません。

章ごとに作るときの入出力

一章を依頼するたびに、その章に必要な材料と禁止事項を明示します。

入力

• 文書全体の目的と読者

• この章で答える質問

• 前章までに確定した用語・結論

• 参照してよい資料と該当箇所

• 数字、引用、固有名詞など変更禁止の情報

• この章の出力形式とおおよその分量

出力

• 章本文

• 参照した資料の箇所

• 資料からは確認できない記述

• 前後の章と矛盾しそうな点

• 人が判断する必要のある項目

章を積み上げる途中で、確定事項を別のメモに保存します。すべてのチャット履歴をモデルが正確に覚えている前提にせず、文書の目的、用語、決定事項、根拠を更新して渡します。後から前提を変えた場合は、影響する章を一覧にしてから修正します。

長文向けの制作手順

1. 目的を一文にする：読後に読者が何を完了するかを書く。

2. 資料を棚卸しする：必須の根拠、参考資料、古い資料、未確認の主張を分ける。

3. 構成を作る：各章の問いと役割を一行ずつ記す。重複する章を統合する。

4. 本文を分けて書く：一章ずつ、根拠と出力条件を添えて依頼する。

5. 章ごとに照合する：数字・引用・定義が資料と一致するか確認する。

6. 全体をつなぐ：導入の約束、章間の重複、用語、結論の食い違いをチェックする。

7. 最終QAをする：読者が結論と次の行動を取れるか、欠けた資料がないか確認する。

章が完成したら、章本文だけでなく「確定した主張・根拠・保留」を更新します。これをしないと、同じ資料から別の章を書いたときに、例外条件や定義が変わることがあります。

長文の一貫性を保つ確認表

表は横にスクロールできます

確認項目	問い	修正のしかた
目的	最初の問いに最後で答えたか	導入の約束に戻り、結論へ対応を追加
用語	同じ概念に別名を付けていないか	用語表を作り、表記を統一
事実	数字や条件が章ごとに変わっていないか	出典ファイルと該当箇所へ戻る
重複	同じ説明を別の章で繰り返していないか	共通説明へ集約し、各章は差分を書く
つながり	前章の結論が次章の前提になっているか	章末に次章で扱う論点を一文で示す
未確認	根拠のない主張を確定形で書いていないか	保留表示にするか、資料を追加する
行動	読者が次に何をすればよいか分かるか	担当、対象、期限、判断条件を記す

「全体を校正して」と頼むだけでは、モデルが文章の表面だけを整え、根拠や構成を見逃すことがあります。目的・構成・Fact・表現のレビューを分けると、何を直したのか追いやすくなります。

失敗の兆候と戻し方

章ごとに結論が違う場合は、本文の言い回しを直す前に、文書の決定事項メモを更新します。どの前提が変わったのかを特定し、影響章を再生成します。

出典が曖昧なら、文章をもっともらしく補わず、「資料で確認できること」と「追加確認が必要なこと」を分けます。検索結果のスニペットだけを根拠にしないでください。

同じ説明が増える場合は、重複する段落を章名とともに一覧化し、一か所に残す説明を決めてから削ります。

文書が長いのに読者が動けない場合は、各章の末尾に判断や実行の結果があるかを見ます。長さや見出し数ではなく、読者の問いに答える具体物が欠けていないかを確認します。

編集時に大事な表や構造が崩れる場合は、最終形式の原本を複製し、小さな章で生成と取り込みを試します。出力形式や既存レイアウトを維持する要件を最初に指定します。

同じ条件でサービスを比べる

長文品質を比較するなら、同一テーマ、同じ資料、同じ目標読者、同じ章構成、同じ字数範囲、同じ修正回数をそろえます。出力を採点する人にはサービス名を隠し、次の点を別々に評価してもらいます。

• 読者の問いに答えているか

• 主張と根拠の対応が追えるか

• 章間で用語・数字・結論が一貫しているか

• 重要な例外や反論が抜けていないか

• 人が修正した時間と箇所

• 形式に合ったファイルとして取り出せるか

一つの試作結果で万能な順位を作らないことも大切です。社内報告で扱いやすいサービスが、出典を厳密に追う調査記事や共同編集の手順書でも最適とは限りません。自分の用途に必要な条件で評価します。

AIものさし編集部の判断

構成から章ごとに会話で詰めるならChatGPT、資料と専用指示をプロジェクトにまとめて継続するならClaude、Drive内の資料を参照しながらDocsで仕上げるならGeminiが候補です。どれを選んでも、長文の一貫性や根拠の正しさは最後に人が確認します。

まず代表的な一文書を選び、同じ設計メモ・資料・完成条件で試します。読みやすさだけでなく、修正量、出典の追いやすさ、最終形式への移しやすさを比べ、次の文書でも再現できる方法を採用してください。

改稿が増えたときの履歴と版管理

長い原稿では、修正を繰り返すうちに「どの版の前提が正しいか」が分からなくなります。原稿の冒頭や管理表に、版、更新日、承認者、参照資料の版を記録します。たとえば「構成案 v2」「Fact確認済み v1」「公開用 v3」のように、完成度と用途を分けると、未確認の下書きを完成稿として共有する事故を減らせます。

大きな変更を入れる前に、変更要求を三種類に分けます。

• 構成変更：順序や章の役割を変える。影響する章と導入・結論を再確認する。

• Fact変更：数字や条件を直す。根拠資料と、そのFactを使う全章を更新する。

• 表現変更：読みやすさを直す。意味、用語、例外を保ったかを差分で見る。

一つの依頼で構成とFactと文体をまとめて変えると、どの変更が原因で内容がずれたか追いにくくなります。変更を小分けにし、レビューが済んだ部分へ明示的に印を付けます。