AIに最初に任せる仕事を選ぶ。記事からメルマガの下書きへ

最初にAIへ任せる仕事として、公開済みの記事一本から、メルマガ一通の下書きと根拠のメモを作ることを勧めます。すでにある記事を使え、人が元の情報と読み比べて出来を判断できるからです。準備や書き直しにかかる人の時間がどう変わるかを、一回分の仕事で確かめます。

10月12〜17日に観察した6人の発信と公開資料から、この一件の頼み方を考えました。以下は編集側の提案で、実行や時間短縮を確かめた事例ではありません。

なぜ、いまはメルマガ一通なのか

受け取るものを、一通分の文面、根拠をたどれるメモ、未確認事項の三つに決めます。本文の主張を元資料と比べられ、不自然な言い回しや説明不足も、どの文を直すかまで指定できます。

売上を二期間で比べる仕事も候補になります。Pieter Levelsが示したのは、利用者が売上の増減を尋ね、AIが集計する道具を用意するという例でした。実際に頼むには、期間、通貨、返金などの扱いをそろえた表と、人による検算が要ります。試す場合は、同じ長さの二期間を集計させ、使った行と除外理由も受け取ります。人が全行を別に足して一致すれば次の期間へ進め、不一致なら直します。確認時間と訂正箇所が判断材料です。今回は手元の売上資料を点検していないため、準備できているとは扱いません。

選んだ理由は、公開資料で準備と照合を始められることです。全業務の時間や費用を比べ、利益への影響が最も大きいと確認したわけではありません。ふだんの発信で使う予定のある一通を対象にし、資料の準備、確認、書き直しにどれだけ時間がかかるかを測ります。発信する予定がなければ、試すためだけにメルマガを増やす必要はありません。

6人から、今回の頼み方へ持ち帰ること

全員が同じ自動化を実践していたわけではありません。本人の報告、設計案、製品の仕様から、今回の仕事に使える部分を選びました。

今週の観察と、メルマガ一通の依頼に生かす点（右欄の応用は編集側の提案）

人物	確認したことと、今回の使い方
James Dickerson	10月8日のニュースレターで、ページの先の案内やメールまで実例を集め、AIへ渡したと説明。今回は、元記事に加え、読者と読後にしてほしいことも渡す。
Greg Isenberg	10月8日の記事で、確認済みの会社情報とAIの推測を分け、却下理由を次の入力へ返す設計を提案。直した文と理由を、次の依頼にも添える。
Danny Postma	公開スキルには、スマホ修正後の再撮影とPC表示の確認まで含まれる。メールへの応用として、修正後の全文をもう一度読み、変更の影響も確かめる。
Marc Lou	MailCheapの公開仕様では、原稿作成、テスト、本配信、結果取得が別の操作。最初の依頼は下書きと確認メモまでに区切る。初回配信で本人がAIへ任せた範囲は不明。
Pieter Levels	10月11日に、利用者が知りたい売上の変化をAIへ尋ねる例を提示。今回は、読者に何を理解してほしいかを依頼へ書く。本人の売上分析の実行結果ではない。
Liam Ottley	Morningside AIは、既存システムに合う開発に加え、訓練・調整と日々の業務への組込みを案内。受け取った原稿を、普段使う下書きファイルへ戻す手間も測る。

Jamesの出力改善は本人の評価です。公開された確認工程や操作一覧だけでも、手間の削減までは分かりません。今回の依頼文は編集側で作成しました。

渡すのは、記事、出典、伝えたいこと

初回の材料には、当サイトのGregの記事を使えます。主な出典は10月8日の本人記事です。本人の提案と編集側の試し方を分けているため、下書きでも区別を保てたかを確認できます。

そこへ、誰に、何を理解してほしいかを書き添えます。自分らしい文章の例があれば、使ってよい短い一例と、気に入っている理由も渡します。例がなければ、落ち着いた説明文で頼めます。AIに本人の体験や気持ちを補わせる必要はありません。

次の依頼文では、読者を「AIに情報発信を任せたい小さな会社の経営者」、本文を600〜800字としました。これは練習用の設定で、実際の配信対象や毎回の分量を決めたものではありません。初回に使える文章例と訂正履歴は未提供としています。

そのまま渡せる依頼文

公開記事一本をもとに、メルマガ一通の下書きを作ってください。読者が、AIの案を直した理由を次の依頼にも渡す方法を理解し、自分の下書き一つで試せる内容にしてください。

【材料】
元記事：Greg Isenbergが提案する、AIの推測を会社の方針に混ぜない方法
https://thecryptocompass.net/greg-isenberg-approved-context-2026-w42/
主な出典：Greg Isenbergの2026年10月8日の記事
https://x.com/gregisenberg/status/2108188646973313195
確認基準日：2026年10月18日。10月8日の発信を今日の新発表として書かないでください。
自分の文章例・訂正履歴：今回はありません。

【読者と伝えたいこと】
読者は、AIに情報発信を任せたい小さな会社の経営者です。伝えたいことは、直した文章だけでなく、なぜ直したかも次の依頼へ添えるという方法です。読後の行動は、手元の下書き一つで、直した一文と理由を残すことにしてください。

【作業の順番】
1. 元記事と出典を読み、読めた資料と読めなかった資料を報告してください。本人の説明、本人の提案、元記事の編集側の提案を分けてください。
2. 読者へ伝える中心を一文で定め、使う事実とその根拠箇所を抜き出してください。
3. 件名一つ、受信箱に表示する短い説明、本文600〜800字を作ってください。冒頭で今回の使い道を示し、理由と具体例から、読者が試すことへつなげてください。
4. 書いた本文を元資料と照合し、日付、数字、条件、誰の意見か、主張の強さを確かめてください。全文を通読し、不自然な対比、抽象的な説明、同じ話の繰り返しを直してください。

【作らないもの】
書き手の体験、感情、会話、顧客の声、売上や時間短縮の実績を創作しないでください。資料にない商品・料金・効果は足さないでください。Gregの設計案を実証済みの成功事例に変えないでください。

【提出するもの】
A. 件名、短い説明、本文を、一通として使える形で提出してください。
B. 本文の主な事実と、元資料のURL・見出し・該当箇所の短い要約を対応させた確認メモを付けてください。編集側で考えた試し方は、そのように記してください。
C. 未確認事項と、判断のために人へ尋ねたいことを別に残してください。

中心となる事実の出典が読めない、資料が矛盾する、重要な条件が不明な場合は、その資料と不足箇所を報告し、下書きを完成扱いにせず保留してください。不要な数字は本文へ入れなくて構いません。今回は文面と確認メモの提出までです。配信システムへの入力、テスト送信、予約、本配信、元資料の変更は行わないでください。

依頼文のA〜Cが、一回分の提出物です。資料の不足が返ってきたら、必要な本文や説明を補ってから再開します。

キングスマンが見るのは、元資料との違いと、送る理由

確認メモから、元資料の該当箇所を実際に開きます。AIが付けたURLが存在するだけでは、その文の根拠にはなりません。今回なら、次の対応を見ます。

1. 本人の提案を実績に変えていないか。 Gregの元記事のStep 2・8と下書きを比べます。却下理由を次へ戻すという勧めが、修正回数や売上の改善を確認した話に変わっていたら差し戻します。
2. 説明を強めたり、条件を落としたりしていないか。 元記事と下書きの日付、数字、効果の言い方を照合します。10月8日の発信を最新ニュースと呼んだり、根拠のない成果を足したりしていれば直します。資料を分ければ書換えも防げる、と読める説明も避けます。
3. 一通として読む意味があるか。 件名と冒頭だけで何を持ち帰れるか分かり、最後の「一文と訂正理由を残す」までつながるかを読みます。自分なら使わない言葉は、該当する文と、何を伝えたかったかを添えて返します。

直したら、その文だけでなく前後を含めて読み直します。意味を直した箇所は出典とも再照合します。Dannyの表示修正後の確認を、文章へ応用する部分です。

根拠をたどれない、資料にない実績や体験がある、重要な質問が未回答なら、その稿は保留です。初回は、原稿と根拠と未確認一覧がそろい、人が照合し、重要な誤りや未回答が解消したら完了とします。採用した文と直した理由を、普段使う下書きファイルへ残します。送るかどうかは、その後に判断します。

最初の一回で、何を測るか

材料を選び、依頼を書き始めた時点から記録します。準備、原稿の照合、書き直し、普段の下書きファイルへ移す作業に、人がそれぞれ何分使ったかを残します。AIを待った時間は分けておくと、人の作業時間と混同しません。直した箇所は、事実・条件の誤りと、文体・構成の修正を分けて記します。

過去に同じような原稿を作った時間の記録があれば、そのときの資料量や長さも確かめて比べます。記録がなければ、初回は次と比べるための基準です。原稿ができたというだけで、時間が減ったとは判断しません。

次の一通でも同じ手順を使い、訂正理由を添えたことで同じ誤りが減るかを見ます。事実を守った原稿が、確認と修正に使える時間内で仕上がるなら続けます。毎回ほぼ書き直す、同じ事実誤認が続く、資料探しと確認で以前より時間がかかるなら、渡す資料か対象を見直します。重要な条件を推測して埋めたときは、その回を止めて直します。

この提案で最初に確かめるのは、発信に使う一通を任せた結果、人の準備・確認・修正まで含めた仕事がどう変わるかです。開封、返信、売上への影響は、実際に配信して記録を取る段階の別の問いとして残ります。

出典と確認範囲

対象は2026年10月12〜17日に公開した6人の記事と、10月18日の一次資料の再確認です。6人分の公開記事は読み戻せました。毎日の調査で得た発信を振り返る総まとめで、すべてがこの一週間に発表された情報ではありません。

• James Dickerson：Boring Funnelsの発表（2026年10月8日）。実例収集と出力改善についての本人の説明。
• Greg Isenberg：Marketing Engineers（2026年10月8日）。Step 2・6・8。確認済み情報、ツールの権限、却下理由の扱い。
• Landingfolio：Mobile Responsive Pass。10月18日に公開本文の修正・再撮影・PC確認の工程を再確認。掲載日時は不明。
• MailCheap：操作一覧。10月18日に原稿作成、テスト、配信、結果取得が別操作であることを再確認。ツールの導入や実行はしていません。
• Pieter Levels：利用者がAIへ頼むことの例（2026年10月11日）。売上分析は提示した例として扱っています。
• Morningside AI：Develop・Adoptの説明。10月18日確認、掲載日時は不明。提供側の説明であり、導入効果の独立した測定ではありません。

Liamの17日記事に使った動画は、日本語の自動生成字幕と一部の画面を確認したものです。英語原語の字幕と個々の発言者の細部は未確認のままです。10月18日の再取得でも動画本文を十分に読めず、新しい発言や成果は加えていません。今回の手順への応用は、上記の公開資料から編集側が考えたものです。