00:04
SNSの投稿を月に8本お願いします。 過去のやり取りと今の依頼、食い違ってませんか?
今日は、Claude Codeで手元の資料を総合し、依頼の抜けを見つけて、相手に確認する一枚でまとめます。
仕事を受けるとき、相手の期待に応えたいからこそ、出来ますと言いたくなることがあります。
でも、何を含むか決めないまま進めると、お互いに当然だと思っていた範囲が食い違ってしまう。
相手が悪いと決めつける前に、言葉にしていなかったところを見つけたいんです。
今日は、SNSの制作依頼を受ける方に向けた、Claude Codeの使い方です。
今日は、利用できる環境がある前提で、何を読ませ、どこを確認するかを説明します。
まず、今回の案件だけの作業フォルダを用意します。
入れるのは、依頼文、過去の合意、自分の対応条件の3つ。
読みやすいテキストにして、依頼文TXT、合意名もTXT、対応条件TXTと名前を付けます。
ここからは説明用の学例です。
依頼文には月8本、写真はこちらで用意します。
文章と画像をお願いできますか?とあります。
一方で合意メモには、公開操作は依頼側が行う、と残っていたとします。
今の依頼文に公開担当が書いていなくても、既に決まった話をまた聞く必要はありません。
Claude Codeには、最新の1つだけでなく、この3つの資料を称号してもらいます。
食い違いがあれば、勝手に新しい方を正解にしないように伝えます。
最初は資料を読む段階です。
Claude Codeのプランモードで指定した3つのファイルを読み、確定条件、未確認、資料間の食い違いを分けてください。
判断の根拠になったファイル名と原文を添えてください。
と頼みます。
この段階では、元資料を変更させず、何を根拠に、どう整理するかを確認します。
例えば依頼文の、写真はこちらで用意します、だけで、写真を使う権利まで確認済みとは言えません。
一方、公開担当は、合意メモに根拠があります。
出力では、公開は依頼側、根拠は合意メモ、写真の利用許可は未確認と分かれているかを見ます。
根拠の一文を実際に開くと、もっともらしい補完にも気づけます。
読み取り結果を見たら、作成へ進めます。
プランモードを追え、必要な書き込みを許可する段階で、確認表.mdと変身した書き.txtをこの作業フォルダへ保存してください。
元の3資料は変えないでください。
と頼みます。
何を納品するか。
誰が何をするか。
どの時点で完成か。
この3つで整理すると、相手も仕事の流れを想像できます。
何を納品するかでは、月8投稿分の文章と各投稿5枚までの画像など、数える単位を揃えます。
5枚という数字は仮の提案です。
相手から指定された数ではありません。
この範囲を想定していますが、合ってますか?とこちらの案として伝えます。
誰が何をするかでは、素材提供、制作、確認、公開を分けます。
写真は依頼側が用意、文章と画像の書庫はこちらが作成、事実確認は依頼側、公開は依頼側。
これは一例です。
03:00
全部こちらが担当する案件もあります。
大事なのは、その仕事の担当が空白になってないことです。
完成の条件には修正の数え方も入れます。
修正2回までと書くだけでは、何を1回と呼ぶのかも分かりません。
8本をまとめて返す1回なのか、1本ごとなのか。
5時の直しも回数に入るのか。
AIに一般的な数字を決めさせず、自分が対応できる範囲を提案して、相手と合わせます。
依頼内容を確認するときは、何でも対応しますより、ここまでを想定していますと伝えてください。
文章、画像、公開のどれを含むか。
誰が最後に確認するか。
追加の作業が出たときに、どう相談するか。
最初に言葉にしておくほど、後から相手を断る会話ではなく、一緒に範囲を決める会話にできます。
返信した書きの例は、コード。
ありがとうございます。
月8本の文章と画像制作。
公開操作は、御社という認識です。
画像の枚数と修正をまとめてお戻しいただく方法。
素材をいただける日を先に合わせられますでしょうか。
合意済みの公開担当は、読み戻し。
まだ決まっていない3点を質問にし、ファイルが保存されたら、クロードコードの完了しましたという返事だけで終わらせず、自分で開いて読みます。
確認表の元の一文があるか。
返信文に勝手な条件が増えていないか。
ここで作ったのは下書きです。
メールやディスコードの送信まで頼んだことにはなりません。
送る前に、普段の相手と言い方へ整えます。
準備する資料は、その案件の確認に必要な部分へ絞ります。
関係のない個人情報や別のお客様の資料までまとめて入れなくて構いません。
フォルダを分けるのは整理のためで、それだけでアクセスを完全に制御できるわけではありません。
実際の権限設定も確認し、指定外の資料を参照しないよう範囲を伝えます。
クロードコードが保存した文では、丁寧さより先に事実の混入を見ます。
前回と同様と書いてあるけど、本当に前回があるのか。
修正は2回までとあるけど、対応条件に書いた自分の希望なのか、相手の了承済みなのか。
自分の条件がファイルにあることと、相手との合意があることを混ぜないでください。
条件を並べると、責めたい人に見えそうだと感じる方もいると思います。
そこで、なぜ確認するのかを一文添えます。
制作後の行き違いを減らし、必要な投稿を予定通りお渡しするためです。
相手を疑うためではなく、仕事を進めるための確認だとわかると、会話の方向が変わります。
確認表に不要な質問が混ざったら、
今回は文章と画像の依頼なので、撮影機材の質問は外してくださいと具体的に直します。
全部を最初から作り直す必要はありません。
クロードコードに確認表と返信した書きの該当箇所だけ直してもらい、
両方から消えたかを開いて確かめます。
一度の指示を複数の関連ファイルへ反映する使い方です。
自分で確認したい項目と、相手に答えてもらう項目も分けます。
自分の作業時間や対応できる曜日には、先にこちらで整理できます。
それまで相手に考えてもらう必要はありません。
相手には目的や必要な納品物など、相手しか決められないところを聞く。
準備をした上で確認すると往復を減らせます。
06:02
返事をもらったら、回答.txtとして今回のフォルダへ追加します。
新しい回答で確定したところだけ確認表へ反映し、未回答は残してくださいと頼みます。
その後、引き8本、各5枚までの文章と画像、公開は御社というように決まった内容を空いて読み戻します。
AIが更新しただけで、双方の合意が完成するわけではありません。
曖昧な言葉も置き換えておくと役立ちます。
早めには日付、いい漢字は参考と避けたい表現、
いつもの形は実際の過去の成果物、すべてを細かい仕様にする必要はありません。
が、後から解釈が分かれそうなところは同じものを見て話せる状態にします。
この使い方で減らしたいのは、相手との会話そのものではありません。
資料を探して同じ条件を打ち直す作業や、返事が来たのに古い条件を使う取り違いです。
最初は一案件だけで試してください。
短い依頼文一つなら普通のチャットでも足ります。
関連資料や変更が増えたときに、ファイルをまたいで扱う価値が出てきます。
初めての依頼では、全部を月単位で固める前に、一本の見本で合わせる方法もあります。
これは必ず無料で作るという意味ではありません。
対応範囲の条件を合意した上で、文章の長さや画像の方向性を一本で確認する。
違いが大きいまま8本進めるより、直す範囲を小さくできます。
今回使っている整理表と確認文の作り方は、依頼範囲を揃える合意準備キットにまとめました。
概要欄から公式LINE、SOTAのAIインスタ大学を追加し、LINEのトークで範囲の合意と送ってください。
今ある依頼文を一つ入れて、明記された条件を抜くところから始められます。
ここから返事が来た後の話です。相手が公開までお願いしたいです。
と言ったら、依頼が間違っていたわけではありません。
確認したことで期待がわかったので、追加する作業、必要な権限、確認方法、予定への影響を整理して、受けられる条件を返します。
確認は断る理由を集める作業ではありません。
相手が公開も頼みたいと言った場合には、回答を追加して、変更前の担当と新しい希望を並べます。
クロードコードには追加で発生する作業と確認事項を変更メモ.mdへ保存してくださいと頼めます。
ただし、料金や責任範囲をAIが決定するわけではありません。
その一覧を見て、自分の時間や体制と照らし合わせます。
途中でやっぱり動画もお願いします。
となったら、元の依頼に黙ってまず内容にして、変更前、追加したい内容、納期と費用への影響、決まったこと、この4つを小さく残します。
関係が良いほど口頭で済ませがちですが、後で双方が同じ内容に見られる形にすると助かります。
変更を確認する分も強い言い方でなくて構いません。
動画制作を追加する場合は、今の8投稿のうち2本を動画へ変える案と別に追加する案があります。
その結果、納期と費用を整理しますので、どちらを希望されますか?
自分が実際に対応できる選択肢だけを出します。
ここで納品物の数だけ決まれば十分という落とし穴があります。
例えば、8本納品でも素材がいつ届くか決まってないと、制作時間を確保できません。
09:03
相手の確認が遅れた時にどうするかも含め、日付の前提を揃えます。
こちらの納期だけを約束して、必要な入力を予定を空白のないようにします。
説明用の例なら、素材を受け取った翌営業日から書工の作成を始めるという条件が考えられます。
ただ、これは全員にお勧めする日数ではありません。
自分の稼働日と作業量で決めます。
AIが提案した日程が現実的かは、実際に作業する人が確認する必要があります。
もう一つ、返信がない状態と合意と言わないことです。
確認文を送った、相手が読んだ、条件に了承した、この3つは同じではありません。
作業を進める前に、必要な合意が取れていなければ、どの項目の返事を待っているかを明確にします。
送信した、という記録だけで合意済みにしないでください。
実務で残すのは、長い会話の複製ではなく、決まった条件と元のやり取りの場所です。
誰が、いつ、何に合意したか。
フロードコードへ追加の回答を渡した時も、以前の条件を黙って消さず、変更メモに前後と根拠を残します。
元資料はそのままにして、今回採用する条件を確認表でわかるようにし、
もし相手の依頼が短すぎるなら、最初から20項目を聞かない方がいい場合もあります。
仕事を始められるかに影響する3つに絞る。
例えば納品物、公開担当、希望、その返事を受けて、必要な細部を詰める。
相手の負担を増やすことと、確認を丁寧にすることは同じではありません。
この1枚を使った後は、後から追加になった仕事を1つ記録してください。
毎回画像の枚数でズレるなら、次からそこを先に聞く。
確認者が増えて修正が戻るなら、窓口を決める。
実際に起きたズレから質問を直す方が、使わない注意書きを増やすよりも役に立つ。
今日の一歩は、一案件の依頼文、過去の合意、自分の対応条件を揃えることです。
クロードコードで読み比べ、確認表と返信した書きを作る。
そして返事が来たら、どこが決まり、何が残ったかを更新する。
次の依頼でも、前回実際にズレたところを先に確認する形へ集めていきます。
