「SNSの投稿を月に8本お願いします」と頼まれたとき、文章と画像だけを作るのか、公開まで担当するのか、過去のやり取りを探し直していませんか。
引き受けたい気持ちはあるのに、どこまで含まれるかが曖昧なままだと、返事を書く手も止まります。
この記事では、依頼文・過去の合意・自分の対応条件をClaude Codeで読み比べ、決まっていることと未確認のことを分ける方法を説明します。
相手に確認するための1枚と返信下書きを作り、回答が届いた後の更新まで進められるようにします。
最初の結論は、AIに条件を決めてもらうのではなく、条件の根拠と空白を見つけてもらうことです。
「資料に書いてある」「こちらが希望している」「相手が了承した」を分けるだけでも、次に誰が何を確認すればよいかが見えやすくなります。
動画とあわせて確認したい方は、ソウタのYouTubeチャンネルをご覧ください。
「Claude CodeでSNS依頼を整理｜確認表と返信を作る」の収録では、今回の考え方を、資料を読むところから返信後の変更管理まで順に話しています。
結論：「月8本」の依頼は、作業と完成条件を分けて確認する
Claude CodeでSNS制作の依頼を整理するときは、今回の依頼文、過去の合意、自分の対応条件を読み比べます。
「月8本」という本数だけから、画像枚数、撮影、公開、修正回数、権利許諾まで決まったものとして扱いません。
以下は説明用の架空例であり、実際の顧客との合意や成果ではありません。
先に埋める、依頼範囲の確認表
スマートフォンでは、表を左右にスクロールできます。
| 論点 | 今回の依頼文から分かること | まだ決められないこと | 次に確認する資料・相手 |
|---|---|---|---|
| 本数 | 「月8本」と書かれている。 | 1本が画像1枚か複数枚か。原稿も8本か。 | 過去の合意と依頼者への確認。 |
| 素材 | 写真は依頼側が用意すると書かれている。 | 利用許可、加工範囲、納品日。 | 素材の権利条件と受渡し予定。 |
| 制作 | 文章と画像の作成を求められている。 | 企画、撮影、動画、投稿後の運用を含むか。 | 対応条件と新しい依頼内容。 |
| 公開 | 公開操作の担当は明記されていない。 | 誰が予約・投稿・最終確認をするか。 | 過去の合意、決まっていなければ依頼者。 |
| 修正 | 修正回数は明記されていない。 | 何を1回と数え、どこまで含むか。 | 自分の対応条件を提案として示す。 |
過去の合意に「公開は依頼者」とあれば、その根拠を記して確認表へ移します。
一方、自分の対応条件に「修正は2回まで」とあるだけなら、依頼者が了承した条件としては書きません。
「書かれている」「提案する」「相手の確認を待つ」を分けることが、この表の役割です。
返信文は確定事項を読み戻してから質問する
ご依頼ありがとうございます。
今回の依頼文では月8本、写真は御社から支給、文章と画像の制作をご希望と理解しました。
作業範囲をそろえるため、1投稿あたりの画像枚数と公開操作の担当を確認させてください。
撮影・動画制作・投稿後の運用は、現時点の依頼文だけでは範囲に含めていません。
確認後、制作物と担当を一枚の表にしてお返しします。
この文面も架空例です。
過去の合意があれば先に読み、確定していることを再質問しないでください。
依頼者に送る前に、本文で示した五つの観点で事実・宛先・言い方を確認します。
元になった動画「Claude CodeでSNS依頼を整理する」では、資料の読み分けから返信後の変更管理まで話しています。
確認表と返信下書きを自分の案件へ当てはめたい方は、記事末尾の公式LINEで「範囲の合意」と送って「依頼範囲をそろえる合意準備キット」を受け取れます。
「月8本お願いします」だけでは、8本分の仕事が見えていない
ここから扱うSNS制作案件は、使い方を説明するための架空例です。
僕や受講生の実績を紹介するものではなく、依頼を受けたときにどこを読み分けるかを具体的に考えるための例として使います。
依頼文には「月8本、写真はこちらで用意します。
文章と画像をお願いできますか」と書かれているとします。
この文から読み取れるのは、月8本という数量、依頼側が写真を用意すること、文章と画像の制作を求めていることです。
一方で、1投稿あたりの画像枚数、初稿を渡す日、修正の進め方までは書かれていません。
投稿という言葉に、公開操作まで含めているかどうかも、この依頼文だけでは判断できません。
ここで「SNS運用の依頼だから公開も含むはず」と補うと、書いていない期待を自分で引き受けることになります。
逆に「公開について書いていないから、必ず相手に質問しよう」と考えるのも、まだ早いんです。
過去の合意メモに「公開操作は依頼側が行う」と残っているかもしれません。
最新の1通だけを読むのではなく、今回の依頼に関係する資料を照合する理由は、ここにあります。
期待に応えるために、まず「できます」の中身を言葉にする
仕事を受けるとき、相手の期待に応えたいからこそ、すぐに「できます」と返したくなることがあります。
僕が今回の使い方で大切にしたいのは、その前向きさを消さずに、引き受ける内容を見えるようにすることです。
「何でも対応します」は、受け取る人によって意味が変わります。
文章と画像の制作だと思う人もいれば、企画、撮影、公開、その後のコメント対応まで頼めると受け取る人もいます。
たとえば月8本という同じ数字でも、完成した画像を渡す仕事と、投稿後の反応を見ながら運用する仕事では、必要な作業が違います。
数字が一致していることと、仕事の範囲が一致していることは別なんです。
ゲームで言えば、同じミッション名を見ていても、クリア条件が違えば動き方はそろいません。
目的地だけでなく、何を持って到着すれば完了なのかを共有しておく必要があります。
そこで、「何でもできます」の代わりに「ここまでを想定しています」と伝えます。
これは相手を遠ざける線引きではなく、相手が希望との差を伝えられるようにするための説明です。
準備する資料は「依頼文・過去の合意・対応条件」の3つ
最初に、今回の案件だけを扱う作業フォルダーを用意します。
Claude Codeを利用できる環境がある前提で、この記事では導入設定ではなく、何を読ませ、どこを人が確認するかに絞ります。
フォルダーに入れる資料は、まず3つです。
- 依頼文.txt：今回、相手から届いた依頼内容。
- 合意メモ.txt：今回の案件について、これまでに双方で決めた内容と、その根拠が分かる記録。
- 対応条件.txt：自分が対応できる内容、稼働上の制約、これから提案したい条件。
名前を分けるのは、それぞれの資料が持つ意味を混ぜないためです。
依頼文に書かれた希望と、自分の対応条件に書いた希望は、どちらも重要ですが、それだけで双方の合意にはなりません。
たとえば対応条件.txtに「修正は2回までを希望」と書いたとします。
これは自分の案を忘れないための記録であり、相手が2回という条件を受け入れた証拠ではありません。
過去の合意がない初回案件なら、合意メモを埋めるために内容を作らないでください。
「今回の案件について過去の合意記録はない」と分かる状態にして、存在する資料だけを出発点にします。
資料を集めるときは、量よりも今回の判断との関係を見る
AIに任せるなら資料は多いほどよい、と考えるかもしれません。
ただ、今回確認したいのが月8本の文章と画像制作の範囲なら、別のお客様の資料や関係のない個人情報まで入れる必要はありません。
まず、今回の条件を判断するために必要な部分をそろえます。
依頼文の前後に重要な前提があるなら、その前提も含めますが、関係のない会話を機械的にすべて複製しなくて大丈夫です。
一方で、短くしすぎて意味が変わる切り出し方には気をつけます。
たとえば「公開はこちらで行います」が、今回の8本を指しているのか、以前の別案件を指しているのか分からない状態では、確定条件に使えません。
合意メモには、条件に加えて、元のやり取りの日時や場所を追える情報を残します。
長い会話を丸ごと読む代わりに、必要なときに原文へ戻れる状態をつくるという考え方です。
また、フォルダーを分けることは整理には役立ちますが、それだけでアクセスを完全に制御できるわけではありません。
実際の権限設定を確認し、Claude Codeには指定した資料以外を参照しないよう、読む範囲も明示します。
最初はファイルを作らず、3つの資料を読み比べる
資料がそろったら、すぐに返信文を完成させるのではなく、まず読み取り結果を確認します。
収録では、Claude Codeのプランモードを使い、元資料を変更しない段階から始める流れを説明しています。
依頼する内容は、難しい言い回しである必要はありません。
何を読むか、何に分類するか、何を根拠として出すかを、次のように指定します。
「この作業フォルダーの依頼文.txt、合意メモ.txt、対応条件.txtだけを読んでください。
確定している条件、未確認の項目、資料間の食い違いを分け、各項目に根拠のファイル名と原文を添えてください。
」
「こちらの希望や提案は、双方の合意と区別してください。
新しい資料を自動的に正解とせず、この段階では元資料の変更や新しいファイルの作成をしないでください。
」
大切なのは、最初からきれいな文章を求めすぎないことです。
読む段階では、丁寧な表現よりも、どこに何が書いてあって、何が書かれていないかを確認します。
もし根拠が示されない項目があれば、分類を整える前に原文へ戻ります。
見た目が整った一覧でも、判断の根拠がなければ、そのまま相手への確認に使うことはできません。
比較するときは「確定・未確認・提案・食い違い」を分ける
収録では、まず確定条件、未確認、資料間の食い違いを分けています。
実際に読むときは、そこに自分の提案という区別を加えると、対応条件.txtの内容を合意と取り違えにくくなります。
4つの違いを、今回の架空例で比較してみます。
- 確定している条件：合意メモに双方で決めた記録がある「公開操作は依頼側」。ただし、今回の案件に適用される記録かを確認します。
- 未確認の項目：依頼文に写真を用意するとあるものの、利用許可については資料に記載がない。
- こちらの提案：各投稿5枚までの画像制作を想定しているが、相手から指定された数ではなく、了承もまだない。
- 資料間の食い違い：過去には依頼側が公開すると決めた一方、新しい依頼には制作者が公開するよう求める記載がある。
この比較で重要なのは、未確認と食い違いも別だということです。
新しい依頼文に公開担当が書かれていないだけなら、それだけで過去の合意と矛盾したことにはなりません。
また、提案があるからといって、未確認が解消したわけでもありません。
「各5枚までなら対応できる」という自分の案を出して、相手の希望と合うかを確認する段階です。
分類の名前そのものより、次の行動が分かることを優先してください。
確定なら読み戻す、未確認なら質問する、提案なら案として伝える、食い違いならどちらを採用するか確認する、という使い分けです。
「写真はこちらで用意します」から、利用許可まで補わない
AIの出力で特に確認したいのが、原文よりも意味が広がっていないかという点です。
今回の例なら、「写真はこちらで用意します」という一文が分かりやすい確認箇所になります。
この一文は、写真を準備する担当について説明しています。
しかし、その写真を今回の投稿で利用してよいことまで、確認済みだとは読み取れません。
確認表に「写真は依頼側が提供、利用許可確認済み」と書かれていたら、後半の根拠が必要です。
根拠の資料がないなら、「写真の提供担当は依頼側」「利用許可は未確認」と分け直します。
ここでは、問題がある写真だと決めつける必要もありません。
確認できていないことを、そのまま未確認として扱うだけです。
相手に伝える文も、「ご提供いただく写真について、今回の投稿への利用に問題がないかもご確認をお願いします」と、作業に必要な確認として整えられます。
実際の表現や確認の深さは案件に合わせますが、AIに「きっと大丈夫」を埋めてもらわないことが出発点です。
根拠の原文は、要約の正しさを自分で確かめるために残す
「根拠：合意メモ.txt」とファイル名だけが書かれていても、確認には少し手間がかかります。
そのファイルのどの一文を使ったのかまで出してもらうと、判断をたどりやすくなります。
たとえば「公開担当：依頼側」の横に、「原文：公開操作は依頼側が行う」と添えます。
そして、自分でも合意メモ.txtを開き、その記載が本当にあるかを確認します。
原文があるように見えても、AIが言葉を整えた結果、条件を強めている場合は注意が必要です。
「公開は基本的に依頼側で行う予定」という文と、「公開は必ず依頼側が行う」という文では、残っている余地が違います。
今回の記事で勧めたいのは、引用らしく見える文章を信用することではありません。
引用元を開き、対象の案件、言葉の強さ、前後の条件まで照合することです。
確認する順番は、公開担当、納品範囲、納期など、作業の進め方に影響する項目からで構いません。
誤りが見つかったら、その項目を直したうえで、同じような補完がほかにもないかを見ます。
確認表は「納品物・担当・完成条件」の3本柱で組み立てる
読み取り結果を確認できたら、相手に伝わる形へ整理します。
項目を思いつくまま並べるより、「何を納品するか」「誰が何をするか」「どの時点で完成か」の3つに分けると、仕事の流れが見えます。
納品物には、文章、画像、数量、数える単位を入れます。
担当には、素材提供、制作、事実確認、公開など、工程ごとの役割を入れます。
完成条件には、確認する人、修正の扱い、最終確認の方法などを整理します。
ただし、一般的によさそうな条件をAIに決めさせて埋めるのではなく、未決定の部分は空白の意味が分かるように残します。
確認表の各項目には、内容だけでなく、状態と根拠を添えます。
たとえば「画像枚数：各投稿5枚まで／こちらの提案／対応条件.txt」という形なら、相手の了承がまだ必要だと分かります。
「1枚にまとめる」とは、すべての情報を小さな文字で詰め込むことではありません。
今回判断したい内容を見渡せるようにし、詳しい経緯は元の記録へ戻れるようにすることです。
月8投稿と画像8枚は違うので、数える単位をそろえる
納品物の確認で最初に見るのは、数字そのものより、何を数えている数字かです。
月8本の投稿という依頼でも、1本に含まれる画像枚数が分からなければ、制作量を見積もる前提がそろいません。
説明用の提案として、「月8投稿分の文章と、各投稿5枚までの画像」を考えてみます。
この場合、各投稿が5枚なら画像は合計40枚ですが、40枚という計算結果も、あくまでこの提案を前提にした数字です。
相手の依頼が最初から40枚だったわけではありません。
ここを混ぜて「ご依頼の画像40枚を制作します」と書くと、こちらが補った条件を相手の依頼として扱ってしまいます。
返信では、「画像は各投稿5枚までを想定していますが、ご希望と合っていますか」と提案として伝えます。
相手が各投稿3枚を考えていたなら、その返事をもとに制作範囲をそろえられます。
さらに、表紙を1枚に含めるかなど、実際に解釈が分かれそうな点があれば確認します。
最初から数え方の細則を増やすのではなく、その案件で作業量が変わる境目を押さえることが大切です。
担当は「制作する人」だけでなく、確認と公開まで分ける
文章と画像を作る人が決まっていても、仕事全体の担当が埋まっているとは限りません。
たとえば文章中のサービス情報を誰が確かめるのか、完成したデータを誰が公開するのかは、制作とは別の役割です。
今回の架空例では、次のように工程を分けて考えます。
- 素材提供：依頼側が写真を用意する。
- 制作：こちらが文章と画像の初稿を作る。
- 事実確認：依頼側が掲載内容の正確さを確認する案を置く。
- 公開：過去の合意に従って依頼側が操作する。
このうち、事実確認の担当は、今回の依頼文だけで確定しているわけではありません。
例として適切そうな役割分担を考えたことと、相手と決めたことを分けておきます。
すべてをこちらで担当する案件もあるので、役割分担の形を固定する必要はありません。
大事なのは、どの工程にも「誰かがやるはず」という空白を残さないことです。
担当が複数いる場合は、最終的に誰の確認を受ければよいかも見ます。
担当者ごとに違う修正が届く状態なら、作業者を増やす前に、確認意見をまとめる窓口を決める方が進めやすい場合があります。
「修正2回まで」は、1回の意味が決まって初めて使える
修正回数は、数字を入れると条件が明確になったように見えます。
でも「修正2回まで」だけでは、何を1回と数えるかが残っています。
8投稿分の修正をまとめて返してもらうことを1回とするのか、投稿ごとに2回ずつ対応するのかで、進め方は変わります。
誤字の訂正と、確認後に企画の方向性を変える修正を、同じように扱うかも自動的には決まりません。
だから僕は、AIに一般的な回数を入れてもらう前に、自分が対応できる進め方を整理することを勧めます。
回数の数字だけでなく、どの段階で、誰が、どうまとめて返すと作業しやすいかを考えます。
たとえば「修正のご希望は、各確認時に担当者の方でまとめてお戻しいただく形を想定しています」と提案できます。
そのうえで回数や、当初の範囲から変わる修正の相談方法を、実際の対応可能な条件に合わせます。
ここで出した2回という数字は、誰にでも勧める標準ではありません。
自分の作業量や体制を見て決めるための検討例であり、相手の了承前に確認表の確定欄へ移さないようにします。
完成条件を決めると、納品後の「まだ終わっていない」を減らせる
制作物を渡した時点と、仕事が完了した時点は、案件によって一致する場合も、しない場合もあります。
だから、「何を渡すか」に加えて、「どうなったら今回の制作が完了するか」を確認します。
たとえば初稿を渡しただけなのか、修正を反映した最終版を渡すのかでは、同じファイル送付でも意味が違います。
月8本という数量がそろっていても、8本すべてが確認中なら、最終版として完了したとは言えません。
確認表では、初稿、確認中、修正反映後、最終確認済みといった段階を、必要な範囲で区別します。
ただし、状態名を増やすことが目的ではなく、相手と自分が次の作業を判断できることが目的です。
「最終版を渡した後に内容変更が出たら、追加の作業として相談する」といった進め方も、採用するなら事前に提案します。
自分に都合のよい終了条件を、納品時に初めて知らせる形にはしないようにします。
つまずきやすいのは、完成条件を細かく書けば不安がすべて消えると考えることです。
今回の作業に必要な境目を共有し、変更が出たときの相談方法まで用意できれば、すべてを先回りして書く必要はありません。
読み取りを確認してから、確認表と返信下書きを保存する
分類と根拠を自分で確認できたら、成果物を作る段階に進みます。
収録で扱っている保存先は、今回の案件の作業フォルダーです。
必要な書き込みを許可する段階で、次のように頼めます。
「確認した整理結果をもとに、この作業フォルダーへ確認表.mdと返信下書き.txtを保存してください。
元の依頼文.txt、合意メモ.txt、対応条件.txtは変更しないでください。
」
「確認表は納品物、担当、完成条件を軸にし、確定事項、未確認、こちらの提案、食い違いを区別してください。
返信には合意済みの内容の読み戻しと、今回相手に確認したい項目を入れてください。
」
読む段階と保存する段階を分けると、誤った解釈のまま文章が整ってしまうのを見つけやすくなります。
また、元資料を残しておけば、整理後の文に疑問が出たときに戻れます。
保存が終わっても、Claude Codeの「完了しました」という返事だけで終わらせないでください。
2つのファイルを実際に開き、指定した場所にあるか、内容が想定どおりか、元資料が保たれているかを確認します。
確認表の見本は、条件と状態をセットで読む
今回の架空例を、確認表の項目として並べると次のようになります。
これは相手にそのまま送る完成版ではなく、何を確認すればよいかを見渡すための見本です。
- 投稿数：月8本。依頼文に明記された希望として記録し、受ける範囲の読み戻しに使う。
- 制作物：文章と画像。依頼文に記載あり。画像枚数などの内訳は別に確認する。
- 写真提供：依頼側。依頼文に記載あり。素材を受け取る日は未確認。
- 公開操作：依頼側。今回に適用される過去の合意メモを根拠とする。
- 画像枚数：各投稿5枚までというこちらの提案。相手の了承はまだない。
- 修正：回数と数え方、まとめて戻す方法を確認する。AIの判断で数字を補わない。
- 写真の利用許可：現在の資料では未確認。提供担当と分けて扱う。
- 初稿や最終版の日程：素材の受領日と確認の予定を踏まえて調整する。
見本でも、依頼文に書かれた内容をすべて「双方の合意済み」にしていない点が重要です。
依頼されたことを読み取れた段階と、その条件で引き受けることを双方で確認した段階は違います。
表を見て判断しにくければ、「資料に明記」「こちらから提案」「返答待ち」など、状態の表現を具体的に直します。
分類を守るために実務を複雑にするのではなく、誤解が起きるところを見えるようにするために使ってください。
返信は、決まっていることを読み戻してから質問する
確認表ができたら、その項目を全部そのまま質問文に変える必要はありません。
過去に決まっていることは読み戻し、まだ決まっていないことを質問にします。
収録の例では、次のような返信下書きを扱っています。
「ありがとうございます。
月8本の文章と画像制作、公開操作は御社という認識です。
」
「制作後の行き違いを減らし、必要な投稿を予定どおりお渡しするため、画像の枚数と、修正をまとめてお戻しいただく方法、素材をいただける日を先に合わせられますでしょうか。
」
この文では、公開担当を最初から質問し直していません。
合意メモの内容を認識として伝え、未確認の3点に相手の注意を向けています。
もちろん、実際の案件で写真の利用許可が着手判断に必要なら、その確認も適切なタイミングで加えます。
この例の3項目だけ確認すれば、どの案件でも十分という意味ではありません。
返信下書きは、相手が答えやすい順番へ整えるための材料です。
最後は普段の相手との言い方に合わせて、硬すぎる表現や、不要に遠回りな文章を直します。
条件を伝えると冷たく見えそうなら、確認する目的を添える
「条件を並べたら、面倒な人だと思われないだろうか」と感じる方もいると思います。
相手とよい関係をつくりたいほど、曖昧なところを聞きにくくなることがあります。
そこで、確認事項の前に、なぜ確認するのかを1文添えます。
今回なら「制作後の行き違いを減らし、必要な投稿を予定どおりお渡しするためです」と説明できます。
この1文があると、確認の目的が相手の間違い探しではなく、仕事を進める準備だと伝わります。
ただし、理由を添えればどんな条件でも受け入れてもらえる、という話ではありません。
相手の希望と自分の対応範囲が違うなら、違いは残ります。
その違いを早く見つけて、調整できる選択肢を話すために、確認表を使います。
心理的に意識したいのは、「断る会話を準備している」と考えすぎないことです。
「一緒に仕事の範囲を決める会話を準備している」と捉えると、何を聞くべきかも、何をこちらで整理すべきかも変わってきます。
自分で決められることまで、相手への質問にしない
確認項目を増やす前に、その答えを誰が持っているかを考えます。
自分が対応できる曜日や作業量は、まず自分で整理できることです。
たとえば「何回まで修正に対応できますか」と相手に聞いても、こちらの体制は相手には分かりません。
自分が継続して対応できる条件を整理し、その案で合うかを相談する方が具体的です。
一方、何のための投稿なのか、必要な納品物は何か、社内で誰が最終確認するのかは、相手に聞かないと決められない部分があります。
この2種類を分けるだけでも、返信文の質問を絞れます。
確認表には「自分が先に整理すること」と「相手の回答が必要なこと」を分けて置くと便利です。
相手への返信には、後者のうち、今の段階で必要なものを選びます。
つまずきやすいのは、自分の準備不足を、そのまま相手への長い質問に変えてしまうことです。
相手に考えてもらう前に、こちらから出せる案を用意しておくと、往復の中身が具体的になります。
依頼が短いときは、最初から20項目を聞かない
依頼文が短いほど、確認したいことはたくさん出てきます。
でも、最初の返事で20項目を並べれば丁寧になるとは限りません。
まず、その仕事を始められるかに影響する項目を絞ります。
収録では、たとえば「納品物」「公開担当」「希望日」の3つから聞く方法を紹介しています。
これは、ほかの条件を無視してよいという意味ではありません。
入口となる条件を確認し、その回答を受けて、必要な細部へ進むという順番です。
今回の架空例では公開担当の過去の合意があるため、そこは質問ではなく読み戻しにできます。
案件によって、最初の3つが何になるかは変わります。
質問の優先順位を決めるときは、「この答えが違うと、引き受ける内容や予定が変わるか」と考えます。
逆に、今回依頼されていない撮影の機材など、着手判断に関係しない質問は、いったん外せます。
保存後は、文章の丁寧さより「事実の混入」を先に見る
AIが作った返信は、自然で丁寧に見えることがあります。
ただ、その読みやすさと、条件が正しいことは別です。
僕が先に確認したいのは、資料にない事実が増えていないかです。
たとえば「前回と同様に対応します」と書かれていたら、本当に今回の相手との前回があるのかを確かめます。
「修正は2回までで承知しました」とあれば、その2回は相手と決めたのか、自分の対応条件に書いた希望なのかを見ます。
「承知しました」という表現が入るだけで、まだ相談中の条件が合意済みに見えることがあります。
確認する順番は、数字、担当、日付、過去の経緯、了承の有無です。
そのあとで、相手の呼び方や語尾など、普段の関係に合う文章へ整えます。
確認表と返信文も見比べてください。
確認表では「提案」なのに、返信では「決定」として書かれているなら、同じ条件を別の状態で扱ってしまっています。
下書きの保存と、相手への送信は別の作業
今回Claude Codeに頼んでいるのは、確認表と返信下書きを作ることです。
メールやDiscordへ送信するところまで、自動的に含めているわけではありません。
返信下書き.txtが保存されている状態は、送れる文章の候補ができた状態です。
相手へ届いたことも、相手が読んだことも、条件を了承したことも、まだ意味していません。
この区別は、後で合意状況を管理するときにも役立ちます。
「作成済み」「送信済み」「回答あり」「合意内容を確認済み」を混ぜると、どこで止まっているかが分からなくなります。
送る前には、宛先となる相手に合った呼び方か、質問に答えやすい形か、勝手な条件が入っていないかを確認します。
下書きの質を上げることと、確認を省いてそのまま送ることは別です。
最初の1案件では、文章を自分で開き、普段のやり取りへ合わせて整えるところまでを一連の作業にしてください。
このひと手間で、自分がどこをAIに任せ、どこを判断しているかも把握しやすくなります。
不要な質問があれば、2つのファイルを部分修正する
確認表を読んで、今回の依頼に関係のない質問が混ざっていることもあります。
たとえば文章と画像の制作依頼なのに、撮影機材についての質問が入っていた場合です。
このとき、全部を最初から作り直す必要はありません。
「今回は文章と画像の制作依頼なので、撮影機材に関する質問を確認表.mdと返信下書き.txtの両方から外してください」と、修正箇所を具体的に伝えます。
同時に、「ほかの確定事項や未確認項目は維持してください」と添えると、変更したい範囲を伝えられます。
ただし、指示しただけで意図どおりになったと判断せず、修正後に両方を開きます。
確認表から消えていても、返信下書きに残っていれば、相手への質問は減っていません。
逆に返信だけ直して確認表が古いままだと、次の更新で同じ質問が戻る原因になります。
関連する複数のファイルへ、1つの修正をそろえて反映するところに、Claude Codeを使う意味があります。
その価値を得るには、どのファイルが今回の修正対象なのかを明示し、反映後の整合を自分で確かめます。
回答が届いたら、決まった項目だけを更新する
相手から返事が来たら、回答.txtとして今回のフォルダーへ追加します。
回答を読みながら、確定したところだけを確認表へ反映します。
依頼する文は、次のようにできます。
「回答.txtを読み、今回の回答によって確定した項目だけを確認表.mdへ反映してください。
答えがない項目は未確認のまま残し、根拠となる回答の原文を添えてください。
」
たとえば相手が「画像は各投稿5枚まででお願いします」と答え、素材を渡す日には触れていなかったとします。
この場合、画像枚数には回答がありますが、素材受領日は未回答のままです。
返事が1通来たからといって、確認事項すべてが解消したことにはなりません。
AIが文章の流れから「素材日も問題なし」と補っていないかを見ます。
更新後は、「月8本、各投稿5枚までの文章と画像、公開操作は御社という内容で進める認識です」と、決まった内容を読み戻します。
そのうえで「素材をいただける日については、引き続きご確認をお願いします」と、残っている項目を分けて伝えます。
「送った」「読まれた」「了承された」を同じにしない
返信後に気をつけたいのが、返事のない状態を合意と呼ばないことです。
確認文を送ったこと、相手が読んだこと、その条件に了承したことは、それぞれ違います。
たとえば各投稿5枚までという提案を送っても、相手から枚数について返事がなければ、了承したとは扱いません。
別の質問にだけ回答があった場合も、5枚という提案の状態はそのまま残します。
「承知しました」という短い返事が来た場合は、何に対する返答かを前後のやり取りで確認します。
複数の案を送っているのに採用する案が分からないなら、推測して選ばず、必要な部分を読み戻します。
作業前に必要な合意が取れていないなら、「現在は画像枚数の確認待ちです」と、待っている項目を具体的にします。
単に「先方待ち」と書くより、何が決まれば進められるかが分かります。
AIが確認表を更新したことも、双方の合意が成立した証拠にはなりません。
確認表はやり取りを整理した記録であり、根拠となる相手の回答を代わりにつくるものではないからです。
「公開までお願いしたい」と返ってきたら、変更の中身を見えるようにする
確認した結果、相手から「公開までお願いしたいです」と返ってくることがあります。
これは、確認に失敗したということではなく、相手の期待が具体的に分かった状態です。
過去の合意では依頼側が公開することになっていたなら、変更前の担当と新しい希望を並べます。
新しい希望が来たからといって、以前の記録を黙って書き換えないようにします。
Claude Codeには、「公開操作を追加する場合に発生する作業と確認事項を、変更メモ.mdへ整理してください」と頼めます。
追加する作業、必要な権限、公開前の確認方法、予定への影響などを洗い出すために使います。
ただし、その一覧を見て、受けられる条件を判断するのは実際に作業する人です。
AIが料金や責任範囲を決定したり、必要な権限があるものとして話を進めたりするわけではありません。
返信は「公開まで含める場合の作業と確認方法を整理し、対応できる条件をご案内します」といった形にできます。
すぐに断るか、無条件に受けるかの2択にせず、変わる内容を確認してから条件を返します。
「動画もお願いします」は、元の8投稿へ黙って混ぜない
制作の途中で、「やっぱり動画もお願いします」と依頼が広がる場合もあります。
このとき大切なのは、追加の希望を元の依頼へ自然に混ぜてしまわないことです。
変更メモには、変更前、追加したい内容、納期と費用への影響、決まったことの4つを残します。
まだ決まっていない部分は、検討中や回答待ちとして分けます。
説明用の案としては、「今の8投稿のうち2本を動画へ変える」と「8投稿とは別に動画を追加する」が考えられます。
ただし、これは誰でも出すべき選択肢ではなく、自分が実際に対応できる場合にだけ提示する案です。
返信では、「動画制作を加える場合、8投稿のうち2本を動画へ変更する案と、別に追加する案があります。
納期と費用を整理しますので、どちらをご希望か教えていただけますか」と伝えられます。
ここでも、変更案を示したことと、条件が決まったことは分けます。
関係がよい相手ほど、口頭で話してそのまま進めたくなるかもしれません。
だからこそ、後から双方が同じ内容を見られるように、短くても変更内容を残しておきます。
納期は、素材が届く日と確認が返る日まで含めて考える
納品物が月8本と決まっても、それだけでは制作の予定を組めません。
素材がいつ届くか、相手の確認がいつ戻るかによって、使える制作時間が変わるからです。
こちらの納品日だけを約束して、必要な入力の予定を空白にしないようにします。
素材受領、初稿作成、相手の確認、修正、最終版の受け渡しを、つながった流れとして見ます。
収録では、説明用の条件として「素材を受け取った翌営業日から初稿の作成を始める」という考え方を挙げています。
これは翌営業日に初稿を完成させるという意味ではなく、作成を始める時点の例です。
また、全員に勧める日数でもありません。
自分の稼働日と作業量に合わせて、無理なく守れる条件を考える必要があります。
相手の確認が遅れたときに、後ろの日程をどう相談するかも決めておくと、予定を読み直しやすくなります。
AIが作った日程表がきれいでも、実際の作業時間が足りるかどうかは、人が確認してください。
「早めに」「いい感じに」「いつもの形」を、同じものを見られる表現へ変える
依頼文には、関係がある程度できているからこそ使う曖昧な言葉があります。
「早めに」「いい感じに」「いつもの形で」は、その代表です。
言葉が曖昧だから悪いわけではありません。
ただ、解釈の違いが日程や制作内容に影響するところは、同じものを見て話せる形に置き換えます。
- 早めに：必要な日付や、いつまでに何を確認したいかへ置き換える。
- いい感じに：参考にしたい表現と、避けたい表現を共有する。
- いつもの形で：今回の基準にする過去の成果物を具体的に示す。
たとえば「いつもの形」が、画像の構成を指すのか、文章の長さを指すのかで、再現する対象は変わります。
過去の1本を一緒に見られる状態なら、「この表紙の見せ方を踏襲する」と具体的に話せます。
つまずきやすいのは、曖昧な言葉を見つけるたびに、細かい仕様書へ変えようとすることです。
すべてを数値にする必要はなく、後から解釈が分かれると困る部分に絞って確認すれば大丈夫です。
初回は1本の見本で、方向性の違いを小さく確かめる
初めての依頼では、月8本すべてを一気に進める前に、1本の見本で合わせる方法もあります。
文章の長さや画像の方向性は、言葉だけで確認するより、具体物を見た方が違いに気づきやすい場合があります。
ただし、見本を作るという話は、必ず無料で作るという意味ではありません。
対応範囲や条件を合意したうえで、どの1本を使って方向性を確認するかを決めます。
見本で確かめる対象も、先に絞ります。
文章量、画像の見せ方、避けたい表現など、残りの制作に影響する項目を確認します。
「何となくよさそうです」という返事だけでは、どの部分が基準になったか分からないことがあります。
次の制作で引き継ぐ点を短く読み戻し、確認表や合意メモから参照できるようにします。
見本の役割は、すべての修正をなくすことではありません。
方向性が大きく違ったまま8本進めるより、違いが見えたときに直す範囲を小さくすることです。
変更履歴は、長い会話の複製ではなく「前後と根拠」を残す
相手とのやり取りが増えると、全部を残さないと不安になるかもしれません。
実務で見返したいのは、現在採用している条件と、そこに至った根拠です。
変更メモには、誰が、いつ、何について回答したかと、元のやり取りの場所を残します。
そのうえで、変更前と変更後を並べます。
たとえば「公開担当：依頼側」から「公開担当：こちらへ変更を希望」という返事が来た段階なら、後者はまだ希望です。
作業や条件を調整して了承を確認した後で、今回採用する担当として確認表へ反映します。
元資料はそのままにして、現在の条件を確認表で分かるようにします。
古い条件が存在したことを消さないからこそ、なぜ内容が変わったかを追えます。
Claude Codeへの指示でも、「以前の条件を黙って消さず、変更前後と根拠を変更メモに残してください」と伝えます。
最新版だけをきれいにするのではなく、最新版を信用できる理由まで残すという考え方です。
普通のチャットで足りる場面と、Claude Codeが役立つ場面を比較する
この作業をするために、どんな依頼でもClaude Codeを使う必要はありません。
短い依頼文が1つだけで、確認したいことも少ないなら、普通のチャットで整理して足りる場合があります。
収録で伝えたいのは、道具を大きくすることではなく、扱う情報に合う方法を選ぶことです。
比較するときは、資料の数と、更新する成果物の数を見ると分かりやすくなります。
- 短い依頼文が1つ：まず、その文章に明記された条件と未確認事項を抜き出す。普通のチャットでも進められる場合がある。
- 依頼文と過去の合意と対応条件がある：資料をまたいで、根拠や食い違いを整理する価値が出てくる。
- 確認表と返信下書きを継続して更新する：同じ修正を関連ファイルへそろえて反映する使い方が役立つ。
- 回答や変更が増える：新しい回答で決まった部分だけ更新し、過去の条件との関係を追う必要が出てくる。
一方で、ファイルを扱えることと、内容の判断が自動で正しくなることは別です。
根拠を見て、提案と合意を分け、現実的な日程かを確かめる作業は残ります。
最初は1案件で試してください。
自分が何度も探している資料や、繰り返し打ち直している条件が見つかれば、どこで使うと助かるかも具体的になります。
1案件を最初から最後まで進める実践手順
ここまでの内容を、実際に動く順番へまとめます。
一度ですべてを自動化しようとせず、資料を読む、成果物を作る、回答で更新するという3段階で進めます。
- 手順1：今回の案件用フォルダーを用意し、依頼文.txt、合意メモ.txt、対応条件.txtをそろえる。
- 手順2：指定した資料だけを読ませ、確定事項、未確認、提案、食い違いを根拠の原文とともに整理する。
- 手順3：元のファイルを開き、数量、担当、日付、了承の有無に勝手な補完がないか確認する。
- 手順4：納品物、担当、完成条件を軸に、確認表.mdと返信下書き.txtを保存する。
- 手順5：2つのファイルを開き、状態の食い違いや不要な質問を直す。
- 手順6：普段の相手との言い方へ整え、必要な確認を相手へ伝える。
- 手順7：返事を回答.txtとして加え、決まった項目だけを更新し、未回答を残す。
- 手順8：決まった条件を読み戻し、変更があれば前後と根拠を変更メモへ残す。
たとえば手順3で公開担当の根拠が見つからなければ、手順4では確定事項として書かず、確認が必要な項目として扱います。
途中で分からないことが出たら、無理に最後まで埋めるより、その項目の状態を正しく残す方が大切です。
作業を終えるときは、「ファイルを作ったか」だけでなく、「今決まっていることと、まだ返事が必要なことが分かるか」を見てください。
この問いに答えられれば、確認表は次の行動を決めるための道具として使えます。
送る前の確認は、5つの観点に絞って行う
長いチェックリストを毎回見直すのが負担なら、最初は5つの観点で確認します。
今回の依頼範囲の整理に直結する内容だけに絞ります。
- 根拠：条件の出どころとなる原文を、自分で開いて確かめたか。
- 状態：資料に書かれた希望、こちらの提案、双方の合意を分けているか。
- 範囲：文章、画像、確認、公開のどこまで含むかが分かるか。
- 予定：素材受領や相手の確認など、こちらの作業に必要な前提が見えているか。
- 次の行動：相手に答えてもらうことと、自分が先に整理することが分かれているか。
この5つを見た結果、すべてが確定していなくても構いません。
確認のための返信なら、未確認が残っていること自体は自然です。
問題なのは、未確認なのに確定したように書くことや、こちらの希望を相手の了承として扱うことです。
空白を消すより、空白が何かを正しく伝えることを優先します。
この順番で確認した後に、文章の丁寧さや読みやすさを整えます。
表現を磨く前に内容を確かめる方が、書き直しの理由も明確になります。
FAQ：過去の合意と新しい依頼が違うときは、どちらを採用しますか
新しい方を自動的に正解にせず、違いを並べて確認します。
新しい依頼に変更の意図があるのか、単に担当者が過去の条件を把握していないのかは、資料だけでは判断できない場合があります。
たとえば過去の合意では依頼側が公開し、新しい依頼にはこちらへ公開を求める記載があるなら、担当変更の希望として整理します。
「以前は御社で公開する形でしたが、今回は公開まで含めるご希望でしょうか」と、食い違う点を具体的に読み戻します。
一方、新しい依頼に公開担当が書かれていないだけなら、それだけで変更とは扱いません。
過去の合意が今回にも適用されるかを確認し、不要に同じ質問を繰り返さないようにします。
FAQ：対応条件.txtに書いた内容は、確認表の確定欄に入れてよいですか
自分が対応できる条件としては記録できますが、相手との合意とは分けます。
「こちらは各投稿5枚までなら対応可能」という事実と、「相手も各投稿5枚までに了承した」という事実は別です。
確認表では、こちらの提案や対応可能な条件として置きます。
その条件を相手へ伝え、回答が来た後で、何が決まったかを更新します。
自分の希望がファイルに保存されているだけなのに、返信で「合意のとおり」と書かれていたら修正が必要です。
保存されている情報の量ではなく、誰がどこまで了承したかを見てください。
FAQ：確認項目が多すぎて、返信が長くなります
確認表に残す項目と、今回の返信で聞く項目を分けてください。
一覧に10項目あっても、最初の返事で10項目すべてを聞かなければならないわけではありません。
まず、納品物や希望日など、受ける内容や着手判断に影響する項目を優先します。
その返答がないと意味が決まらない細部は、次の確認に回せる場合があります。
また、自分の稼働日や対応できる修正方法など、こちらで整理すべきことが混ざっていないかも見ます。
相手にしか答えられない質問へ絞ると、返信の目的がはっきりします。
FAQ：返事が一部だけでも、作業を始めてよいですか
回答の数ではなく、未回答の項目がどの作業に影響するかで考えます。
画像枚数が決まっていないのに全8投稿の画像を作り始めると、後で制作範囲が変わる可能性があります。
一方、すでに合意した範囲で進められる準備があるなら、その範囲を見極めます。
未回答のまま進めることをAIに判断させるのではなく、自分の作業と残っている条件の関係を確認します。
確認表には「素材提供日が未回答」「画像枚数の返答待ち」など、具体的に残します。
相手にも、どの回答があると次の作業へ進めるかを伝えると、必要な返事が分かりやすくなります。
FAQ：AIが出した日程や修正回数を、そのまま使ってもよいですか
検討材料にはできますが、自分が守れる条件かを確認してから提案します。
文章として自然な「修正2回まで」や「翌営業日から着手」でも、自分の稼働や作業量に合うとは限りません。
月8本の制作以外にどの仕事があるか、素材の状態によって準備が必要かなど、実際に作業する人が把握している前提があります。
その前提を見ずに数字だけ採用すると、分かりやすいけれど守れない条件になります。
また、相手へ提案した時点では、まだ合意済みではありません。
自分が対応できることを確かめ、相手の希望と合わせるという2段階で考えてください。
FAQ：確認表を作れば、トラブルをなくせますか
すべての変更や行き違いをなくせるわけではありません。
仕事が進んで初めて見える希望もあれば、途中で必要な内容が変わることもあります。
確認表で目指すのは、変更が起きない状態を保証することではなく、何が変わったかを同じ情報で話せる状態です。
「公開も追加したい」「8本のうち2本を動画にしたい」といった希望が出ても、変更前と比較して相談できます。
使った後には、後から追加になった仕事を1つ記録してください。
実際に起きたズレを次の確認へ反映する方が、使わない注意書きを増やし続けるより、今回の仕事に合う型を育てられます。
毎回のズレを1つだけ残し、次の質問を改善する
確認表は、最初に完成させて終わる書類ではありません。
使ってみて初めて、どこを先に聞けばよかったかが分かります。
たとえば、毎回画像の枚数で認識がずれるなら、次の依頼では早い段階で枚数を確認します。
確認者が途中で増えて修正が何度も戻るなら、次は意見をまとめる窓口を先に決めます。
この改善は、一般的な注意事項を増やすこととは違います。
自分の案件で実際に起きた出来事をもとに、次の質問の順番や内容を変える作業です。
残す記録は、まず1つで構いません。
「何が後から追加になったか」「最初に何を聞けば分かったか」を短く書きます。
そして、次回の確認表へ反映したら、本当に役立ったかを見ます。
質問が増えたことではなく、必要な条件が早くそろったかを基準にすると、確認表が重くなりすぎません。
AIで減らしたいのは会話ではなく、探し直しと取り違い
今回の使い方は、相手との会話をなくすためのものではありません。
むしろ、相手にしか決められないことを、具体的に話せるようにするための準備です。
減らしたいのは、過去の条件を何度も探すこと、同じ内容を別のファイルへ打ち直すこと、返事が来たのに古い条件を使ってしまうことです。
依頼文、確認表、返信下書き、回答という情報のつながりを保つことで、その取り違いを見つけやすくします。
僕は、よい確認とは相手を試す質問ではなく、共同作業の地図をそろえる行為だと考えています。
地図に空白があること自体は問題ではなく、空白なのに道があると思い込んで進むことが、後の行き違いにつながります。
月8本という目的地に対して、何を作り、誰が確認し、どこで完成とするかをそろえる。
Claude Codeには、その地図を資料から整理し、変更を反映する部分を手伝ってもらいます。
具体的な指示の流れや、返答後に変更を扱う考え方は、動画でも詳しく話しています。
記事で自分の案件を整理してから動画を見ると、どこを確認したいかを絞って見られると思います。
今日の一歩は、今ある依頼文から「明記された条件」だけを抜くこと
最初から、すべての依頼を管理する大きな仕組みを作る必要はありません。
まず1案件を選び、今ある依頼文を開いてください。
そして、「月8本」「写真は依頼側が用意」「文章と画像を依頼」のように、実際に書かれている条件だけを抜き出します。
画像は5枚までだろう、公開はこちらだろう、修正は2回だろうという推測は、いったん混ぜません。
次に、過去の合意と自分の対応条件を並べます。
すでに決まっていること、相手に聞くこと、自分から提案することを分け、確認表と返信下書きへつなげます。
相手から返事が来たら、決まった項目だけを更新し、未回答は残します。
この往復を1案件で経験すると、資料をそろえる意味と、AIの出力をどこで確認すべきかが具体的になります。
ここまで読んで、まだ手元に残る作業は、自分の依頼文を実際の確認表に落とし込み、相手に送る確認文へ整えることです。
その作業を始めるために、今回の整理表と確認文の作り方を「依頼範囲をそろえる合意準備キット」にまとめています。
受け取りたい方は、記事末尾のリンクからソウタのAIインスタ大学を友だち追加し、LINEのトークで「範囲の合意」と送ってください。
「依頼範囲をそろえる合意準備キット」を受け取る流れです。
受け取り後の最初の行動も、今ある依頼文から、明記された条件だけを抜き出すことです。
まず1件の依頼文を開き、「書いてあること」と「まだ決めていないこと」を分けるところから始めてください。
記事の手順を自分の投稿に使う
「依頼範囲をそろえる合意準備キット」は、公式LINE「ソウタのAIインスタ大学」で「範囲の合意」と送ると受け取れます。
今ある依頼文から、明記された条件だけを抜き出すところから使ってください。
このページは岡田颯太の動画を基に、S.Hift向けの実践表と確認手順を加えて編集しました。
架空のSNS制作案件は、実際の顧客との合意や成果を示すものではありません。