AIに最初に任せるなら、下書き一通の事実確認から

今週の6人から一つ選ぶなら、メルマガの下書き一通を元資料と照合し、直すべき箇所と根拠をAIにまとめてもらう仕事を勧めます。数字や条件、誰が言ったことかを元の文章と比べられ、人も指摘の正しさを確かめられるからです。

先週は、公開記事一本からメルマガの下書きを作る方法を提案しました。今週は、その下書きを受け取った後の確認を具体化します。まだ下書きを作っていなくても、後半の短い練習用原稿で頼み方を試せます。以下は編集側の提案で、時間短縮を確かめた実施報告ではありません。

どの文が、どの資料と食い違うかを出してもらう

受け取るのは、原稿の一文と根拠を並べた校閲メモです。指摘ごとに元資料の該当箇所と修正案があれば、人は両方を読み、採用するか決められます。

たとえば、他社についての観察が本人の成功談に変わっていないか。提案が実績になっていないか。資料にない納期や効果が足されていないか。こうした食い違いを調べるところまでが、一回分の依頼です。原稿の本文を一つのファイルにまとめ、確認する版を決めて始めます。

6人が見ていた問題を、今回の頼み方へつなぐ

6人全員が校閲をAIに任せていたわけではありません。納品、製品改善、データの提供、保守と、それぞれ違う仕事を見ています。

10月19〜24日に得た観察。各行の「今回なら」以降は編集側の応用案です。

人物	本人の判断・行動と、今回使う考え方
James Dickerson	毎月続く納品を問題にし、Harish Ganapathiが作った、修正後のページを調べ直す道具を紹介。今回なら、AIの「確認しました」に、確認した文と根拠も添えてもらう。
Greg Isenberg	仕事別にモデルを使い分け、利用者の編集・書き出し・共有で比べる他チームを報告。今回なら、AIの自己採点に加え、人が指摘を採用できたかと修正の手間を見る。
Danny Postma	利用状況やアンケートを分析し、支払う対象層に合わせて機能や説明を調整する方針を提案。AI利用や成果は不明。今回なら、採用・却下した指摘を記録し、次の頼み方を直す。
Marc Lou	MailCheapの公開コードは、送信・予約時に原稿を確認し、同じ確認対象の内容には保存済み結果を使う形へ変更。本人の詳しい動機は不明。今回なら、確認した原稿の版を残す。
Pieter Levels	AI企業の進出を見越し、会員の街の評価などを含む有料データAPIを始めたと説明。今回なら、実際の訂正と人が記した理由を手元に残す。これは本人のAI校閲の実践ではない。
Liam Ottley	独自システムの保守や担当者への依存を問題にし、提供会社がなくなった後に何を持ち出せるか問うよう提案。今回なら、元資料・原稿・校閲結果を、元のチャットの外へ保存する。

Marcの製品が出すのは、迷惑メールと判断されやすい書き方などへの助言です。出典との照合とは仕事が違います。また、PieterのAPIには推計や古い情報も含まれ得ます。記録や確認結果が残っていることだけで、内容まで正しいとは扱えません。

渡すのは、元資料と確認用の下書き

必要なのは、使ってよい資料、確認したい原稿、誰に何を伝えたいかの説明です。原稿には「確認用v1」のように名前を付けます。元資料はURLだけでなく、確認日と、原稿の根拠に使った箇所も添えます。使えるAI一つと、手元で開ける文書があれば始められます。

初回の例では、Gregの10月15日の投稿の項目6と、当サイトのFAQ比較の記事を使います。前者は本人の観察、後者のFAQ二問を比べる手順は編集側の提案です。この違いを保てたかを確かめます。

次の依頼文に入れた下書きは、わざと根拠のない実績と納期の約束を含めた架空の練習用原稿です。Gregの発言や、実際の顧客に送った文面ではありません。自分の下書きがある場合は、その部分を差し替えてください。顧客情報や非公開資料を、この公開例へ足す必要はありません。

コピーして使える依頼文

次の下書き一通について、元資料との食い違いを調べ、校閲メモを作ってください。読者はAIに文章の仕事を任せたい小さな会社の経営者です。伝えたいことは、AIの出力を、根拠と人の修正の手間から確かめる方法です。

【元資料】
S1：Greg Isenbergの投稿、項目6
https://x.com/gregisenberg/status/2110414696037716372
発表日：2026年10月15日、日本時間。10月25日の新発表として書かないでください。
S2：当サイトの解説と編集側の試し方
https://thecryptocompass.net/greg-isenberg-faq-model-comparison-2026-w43/
資料の確認基準日：2026年10月25日。取得できなければ、読めなかった資料と、貼り付けが必要な箇所を返してください。

【対象原稿D1・確認用v1】
Gregは自分の会社でAIを二つ比較し、FAQの確認時間を半分にしました。資料に答えがない質問でも、AIに納期を補って回答してもらえます。
これは誤りを含む架空の練習用原稿です。本人の実績や、承認済みの提供条件として扱わないでください。

【作業の順番】
1. 読めた資料と読めなかった資料を報告し、確認した原稿名を示してください。
2. 原稿中の事実や約束を、S1・S2の該当箇所と照合してください。本人の報告、当サイトの編集側の提案を分けてください。
3. 指摘ごとに「原稿の一文／元資料IDと該当箇所／食い違う理由／修正案」を返してください。全文を書き直さず、必要な文だけ修正案を出してください。根拠がないときは、その旨を書いてください。
4. 最後に、指摘しなかった主張とその根拠、重要な未確認事項、人が決めることを残してください。判断できない箇所を確認済みにしないでください。

数字、日付、条件、誰が行ったことかを守ってください。資料にない体験、成果、顧客の声、約束を足さないでください。人が直した理由は、記録がなければ不明としてください。

提出物は、D1・確認用v1に対応した校閲メモと未確認一覧です。テキストファイルへ保存できる文章で返してください。今回は確認案の提出までです。原稿ファイルの上書き、ページ変更、配信システムへの入力、送信・予約・公開はしないでください。

URLを開けないAIには、公開してよい元資料の該当本文を、資料IDとURL、確認日を付けて渡します。本人の投稿が読めない場合に、当サイトの解説だけで本人の原文も確認したことにはしません。

キングスマンは、指摘の根拠を開いて採否を決める

この練習例なら、まず「Greg自身が比較した」という帰属が合っているかを、S1の項目6で確かめます。原文は、他のチームについての報告です。「確認時間が半分」という数字の根拠も示されていません。S2では、資料にない納期は約束せず、担当者への確認を残す試し方を提案しています。

AIがこうした点を指摘できたら、人も元の箇所を読みます。指摘を採用するなら、その理由と直した文を残します。正しい文まで誤りとされたら、却下した理由を記録します。上の説明は期待する確認の例で、実際にAIで試した結果ではありません。

存在しない根拠を挙げた、読めなかった資料を確認済みにした、修正案で条件を落とした場合は差し戻します。AIが何も指摘しなかった主張も、人が元資料と照合します。指摘の一覧だけを読むと、見逃した誤りが残るためです。

修正後は「確認用v2」として残し、変えた文と前後の意味を再確認します。出典や数字を変えた場合は、その数字を使った比較や結論も見直します。構成を大きく変えた場合や元資料が更新された場合は、全文を確認し直します。

原稿と資料、各指摘の根拠、人の採否がたどれ、重要な未確認を解消できたら、一回分の校閲は完了です。元の原稿、校閲メモ、修正後の原稿、採否の理由を手元へ保存します。人の判断をAIに想像させて記録すると、次回にも誤った前提を渡してしまいます。送るかどうかは、その後に判断します。

最初の一回では、何に時間を使ったかを残す

測るのは、資料をそろえた時間、指摘と元資料を照合した時間、修正と再確認の時間です。AIの返答待ちは分けて記録します。根拠のない指摘と、人が後から見つけた重要な見逃しも残してください。

練習用原稿でできても、実際の長い原稿を任せられるかは別に確かめます。次の同程度の一通でも同じ記録を取り、前に直した理由を一つ添えます。同じ誤りの説明を繰り返さず、根拠を探し直す手間も減るなら、続ける判断材料になります。比較できる過去の所要時間がなければ、初回を基準にします。

重要な誤りを繰り返し見逃す、正しい文への指摘が多い、人の確認と修正が毎回増えるなら、資料の渡し方か任せる範囲を見直します。資料自体が不足している場合や、元資料を読める人がいない場合は、確認済みの原稿として使えません。

まずは一通について、AIが返した校閲メモを使うと、自分の確認がどう変わるかを確かめる。そこで残した訂正と理由が、次の一通を任せる材料になります。

出典と確認した範囲

対象は10月19〜24日に調査・公開した6人の記事です。Marcの22日予定分とPieterの23日予定分は、24日に後追いで調査・公開しました。すべての発信がこの週に新しく出たものではありません。25日に公開記事6本を読み戻し、主要資料を照合しました。動画の採用範囲は、24日の確認記録に基づきます。

• James Dickersonのニュースレター（10月15日）とVisibilityKitの公開説明。本人の問題意識と第三者製品の紹介。実動作は未検証です。
• Greg Isenbergの投稿（10月15日、日本時間）。主に項目6・19。他チームの観察で、効果の測定値は不明です。
• Danny Postmaの提案（10月15日）。利用と支払う対象層から改善を考える流れ。AI利用と実施結果は不明です。
• MailCheapの変更記録（10月23日）と公式ヘルプ。確認の時点と保存済み結果の利用。費用や待ち時間の改善は測っていません。
• Pieter Levelsの説明（10月16日）とNomads.com APIの案内。有料提供は確認できても、購入社数や利益は未確認です。
• Liam Ottleyの動画（公開ページは10月20日表示）。7〜8分台と17分台など、24日に照合した英語自動字幕と説明欄の記録を使用。25日の再取得では字幕を確認できず、新しい発言や移行結果は加えていません。