カテゴリー: Claude

  • Claudeへの返信指示を直したら、重大な約束違反と表現の不足を分けて採点し、採用するか決める

    Claudeへの返信指示を直したら、重大な約束違反と表現の不足を分けて採点し、採用するか決める

    問い合わせへの返信をClaudeに下書きさせていると、指示を少しずつ直したくなります。件名を付けてほしい、要点は箇条書きにしてほしい。直した版で何通か試し、読みやすくなっていれば採用したくなりますが、直したことで別のところが崩れていないかは、読みやすさからは分かりません。

    名入れ文具の店の返信指示で、元の版と、件名と箇条書きの2行を足した版を、同じ3件の問い合わせでClaudeに1回ずつ下書きさせました(2026年10月20日)。6つの項目で採点すると、一致した数は2つの版とも18項目中17項目で同じでした。ところが2行を足した版では、商品が届かないという問い合わせへの返信にだけ、店のルールにない「名入れ商品は通常の商品より発送までにお時間をいただく場合がございます」という説明が入っていました。Claudeは補足で「仮定です」と断っていましたが、その一文はお客様に送る本文の側にありました。

    一致数だけで比べていたら、この違反は見逃します。この記事では、重大な約束違反と表現の不足を分けた評価セットの作り方と、実際の2つの版の採点結果、ラベルから採否を出す短い採点スクリプトをまとめます。読み終えたら、自分の返信指示を直したときに、同じ評価セットで採点して、採用するか、もう一度直すかを決められます。

    評価セット:重大な条件と表現の条件を分けて先に決める

    評価セットは、試す問い合わせと、返信に期待することの組です。指示を直すたびに同じ組で採点すると、ある返信が良くなった代わりに別の返信が崩れた、という変化に気づけます。

    期待することは、間違えたときの影響で2つに分けます。お客様に誤った約束や事実を伝えてしまうものは「重大」、読みやすさや体裁に関わるものは「表現」です。

    ID 返信に期待すること 区分
    E1 返金・交換・作り直し・再送を約束しない。返金の依頼には、担当者が確認してから連絡すると伝える 重大
    E2 情報が足りなければ質問する。問い合わせにない事実(発送状況、到着日、原因など)を言い切らない 重大
    E3 1行目に件名がある 表現
    E4 箇条書きが2行以上ある 表現
    E5 担当窓口「サポート担当 support@example.com」を書いている 表現
    E6 結びのあいさつで締めている 表現

    どれを重大にするかは、汎用の点数表ではなく、自分の店で間違えたときに何が起きるかで決めます。たとえば緊急の連絡先を伝えないと困る業務なら、E5は重大に移します。

    採点は、お客様に送る返信の部分だけを対象にします。Claudeが返信の外に書いた前置きや「補足」は、お客様には届かないので数えません。

    2つの版の指示と、3件の問い合わせ

    元の版(v1)の指示は次のとおりです。

    名入れ文具のネットショップに届いた問い合わせへの返信を下書きしてください。次の店のルールに従ってください。
    - 返金・交換・作り直しの可否は、担当者が注文内容を確認してから決めます。返信では返金・交換・作り直しを約束せず、担当者が確認してから改めて連絡すると伝えてください。
    - 返信に必要な情報(注文番号、商品名、状況など)が足りないときは、推測せずにお客様へ質問してください。
    - 名入れは全角10文字までです。
    - 担当窓口として「サポート担当 support@example.com」を記載してください。
    - 最後に結びのあいさつを入れてください。

    直した版(v2)は、ここに次の2行を足しただけです。

    - 1行目に「件名:」で始まる件名を付けてください。
    - 要点は箇条書きで書いてください。

    問い合わせは、返金の依頼、情報の足りない問い合わせ、通常の質問の3件です。

    • Q1:注文番号1024で届いた名入れノートの名前が間違っていました。返金してもらえますか。

    • Q2:先週注文したものがまだ届きません。どうなっていますか。

    • Q3:名入れは何文字までできますか。

    指示の後に「問い合わせ:」と問い合わせを付け、ブラウザ版Claudeの新しいチャットに1通ずつ、2つの版で計6回送りました。

    採点の結果

    版 一致した数 重大な違反 一致しなかった項目
    v1 17/18 なし Q3の返信に箇条書きがない(E4、表現)
    v2 17/18 1件 Q2の返信に店のルールにない発送事情(E2、重大)

    返金の依頼(Q1)には、どちらの版も返金を約束せず、担当者が確認してから連絡すると伝え、注文時に指定した名前と届いた商品の印字を尋ねていました。v1は件名を指示していなくても3通とも件名を付けていて、2行を足したことで増えた一致は、Q3の箇条書きの1項目だけでした。

    減ったのは、v2のQ2です。注文番号や商品名を尋ねる部分は基準どおりでしたが、本文に次の一文がありました(表現は変えていません)。

    なお、名入れ商品は、ご注文後にお名前などを刻印・印刷してから発送するため、通常の商品より発送までにお時間をいただく場合がございます。

    同じ回答の最後には、お客様に送らない補足として、次のように書いていました。

    「通常より発送までにお時間をいただく場合がある」という一文は、名入れ商品の一般的な事情として入れた仮定です。実際の店舗の運用と異なる場合は削除または修正してください。

    店のルールには、発送にかかる時間の説明はありません。届かない理由がまだ分からない段階で、この一文が届くと、お客様は「名入れだから遅れている」と受け取ります。実際には発送漏れや配送の事故かもしれません。補足で仮定だと断っていても、補足はお客様に届かず、本文の一文だけが届きます。そこでE2の「問い合わせにない事実を言い切らない」に当たる重大な違反と数えました。

    一致数はv1とv2で同じ17/18でも、v2だけ未着の返信に重大な違反が1件あり、採否が分かれることを示した図
    一致した数だけで並べると2つの版は同じに見えますが、重大な違反の有無で採否が分かれました。

    各版1回ずつの結果なので、この一文が足した2行のせいで入ったのか、同じ指示でも入ったり入らなかったりするのかは、この結果からは決められません。それでも、採用するかの判断には十分です。v2をこのまま使えば、少なくとも1通に重大な違反があった版を採ることになるからです。

    決めきれなかった文は、理由と一緒に記録する

    ラベルは、実行担当のAI(Claude)が上の基準で付けたものです。そのなかで、基準だけでは決めきれない文が1つありました。どちらの版もQ2の返信で書いていた「お届けが遅れており」です。お客様の「まだ届きません」を言い直しただけとも読めますが、遅れていることを店が事実として認めたとも読めます。今回は言い直しと読んで一致に数えました。v1の回答は、返信の外の説明で「配送の遅れとも発送漏れとも断定せず」と書いていて、本文の言い回しとは食い違っています。

    こうした文は、どちらに数えたかと理由を記録に残しておき、次に指示を直すときの判断材料にします。採点を2人で分けて付けられるなら、この文で判断が割れるかどうかも、指示を直すべき箇所の手がかりになります。

    採点スクリプト

    ラベルを付けたあとの集計は、次のPythonでできます。重大な違反を一致数とは別に数え、採点の対象が欠けていたら止まります。Python 3.10以降の標準機能だけで動き、LABELSの1と0を自分の採点に書き換えて使います。

    # 返信指示の2つの版を、同じ評価セットで採点する。
    # ラベルは、出力1通ごとの一致(1)/不一致(0)。
    # この例は担当AIの判定。自分の返信に使うときは本文と基準を照合して確定する。
    CRITICAL = {"E1", "E2"}                       # 重大条件
    ITEMS = ["E1", "E2", "E3", "E4", "E5", "E6"]
    QUESTIONS = ["Q1", "Q2", "Q3"]
    
    LABELS = {
        "v1": {"Q1": [1, 1, 1, 1, 1, 1], "Q2": [1, 1, 1, 1, 1, 1], "Q3": [1, 1, 1, 0, 1, 1]},
        "v2": {"Q1": [1, 1, 1, 1, 1, 1], "Q2": [1, 0, 1, 1, 1, 1], "Q3": [1, 1, 1, 1, 1, 1]},
    }
    
    
    def score(labels):
        if sorted(labels) != QUESTIONS or any(len(v) != len(ITEMS) for v in labels.values()):
            raise ValueError("評価対象の不足または追加")
        matched, critical = 0, []
        for q in QUESTIONS:
            for item, ok in zip(ITEMS, labels[q]):
                matched += ok
                if item in CRITICAL and not ok:
                    critical.append(f"{q}-{item}")
        return matched, critical
    
    
    for version, labels in LABELS.items():
        matched, critical = score(labels)
        state = "不採用(重大違反あり)" if critical else "重大違反なし・表現の不足を確認"
        print(f"{version}: 一致{matched}/{len(QUESTIONS) * len(ITEMS)} 重大違反{critical} {state}")
    
    assert score(LABELS["v1"]) == (17, [])
    assert score(LABELS["v2"]) == (17, ["Q2-E2"])
    try:
        score({q: v for q, v in LABELS["v2"].items() if q != "Q2"})
    except ValueError:
        print("評価対象が欠ける場合: 停止")
    v1: 一致17/18 重大違反[] 重大違反なし・表現の不足を確認
    v2: 一致17/18 重大違反['Q2-E2'] 不採用(重大違反あり)
    評価対象が欠ける場合: 停止

    採点の対象が欠けたら止めるのは、うまくいかなかった問い合わせを評価セットから外すと、一致の割合が簡単に上がってしまうからです。分母を固定しておけば、範囲を変えたことと指示が良くなったことを取り違えません。

    指示を直すたびに回す手順

    1. 評価セットの問い合わせと、E1〜E6の基準を固定して保存する。

    2. 指示を1か所だけ直す。一度に複数を変えると、何が結果を動かしたかを追えません。

    3. 同じ問い合わせを、新しいチャットで直した版に送り、返信の全文を保存する。

    4. 返信ごとにラベルを付け、決めきれない文は理由と一緒に記録する。

    5. 重大な違反が1件でもあれば採用しない。重大な違反がなければ、表現の不足がお客様に送る前に直せる程度かを見て決める。

    指示を直すときに使った問い合わせとは別に、直すときには見ない確認用の問い合わせも数件用意しておくと、直した問い合わせにだけ合わせた指示になっていないかを確かめられます。

    今回のv2を直すなら、たとえば「店のルールにない発送や配送の事情は書かないでください」の1行を足し、同じ3件でもう一度採点します。そこで重大な違反が消え、Q3の箇条書きも残っていれば、採用を検討できます。

    参照した公式資料

  • Claude Projectsに新旧の料金表を置くとき、適用日と承認状態で使う料金を選ばせる

    Claude Projectsに新旧の料金表を置くとき、適用日と承認状態で使う料金を選ばせる

    料金を改定するたびに料金表の版が増え、見積もりのたびにどれを使うかを確かめるのは手間です。ブラウザ版Claudeのプロジェクトに料金表をまとめて置けば、見積もりに使う料金をClaudeに選ばせられます。ただし、新しい版がまだ承認されていなかったり、承認の記録が抜けていたりすると、どの料金が今の料金なのかは資料の置き方と指示の書き方で変わります。困るのは、承認の記録が抜けた最新版の代わりに、古い料金で見積書を作ってしまうことです。

    撮影サービスの料金表3つを例に、条件ごとにプロジェクトを作り、プロジェクト内の新しいチャットで1回ずつ質問しました(2026年10月20日)。最新版の料金表から承認状態の行だけを消すと、Claudeは承認済みの旧版を「条件上は唯一の候補です」と認めたうえで採用せず、最新版が承認済みなら33,000円、未承認なら30,000円と分けて示し、「承認状態が確認できるまでは、見積書にいずれの金額も記載しないでください」と結びました。旧版へ戻らないことを、プロジェクト指示に書いていたとおりの動きです。

    この記事では、料金表ごとに資料ID・適用開始日・承認状態を書いて置く方法と、使う料金を選ばせるプロジェクト指示、回答を根拠IDと金額の組で照合する手順を、実際の画面の操作と回答で示します。読み終えたら、自分の料金表で同じ3つの条件を試し、プロジェクトの回答を見積もりに使ってよいかを判断できます。

    料金表は1つずつ、適用開始日と承認状態を書いて置く

    例にしたのは、撮影サービスの基本撮影料の料金表3つです。見積作成日は2026年9月21日で、店は「撮影日ではなく見積作成日の料金を使う」と決めているものとします。価格はすべて税抜です。

    資料ID 料金と適用開始 状態とファイル更新日
    P1 30,000円、2026年4月1日から 承認済み、2026年9月10日更新
    P2 33,000円、2026年9月1日から 承認済み、2026年8月20日更新
    P3 35,000円、2026年10月1日から 草案、2026年9月15日更新

    この見積もりに使うのはP2の33,000円です。P1は適用開始がP2より古く、P3は草案で、適用開始も見積作成日より後です。

    承認済みのP1とP2を比べると、P1のファイル更新日のほうが新しいのは、担当者名だけを書き換えたからです。誤字の修正や連絡先の差し替えでもファイルは新しくなるので、更新日は使う料金の順番になりません。だから料金表には、ファイルの外の情報に頼らず、本文に資料ID・料金・適用開始・状態を書いておきます。プロジェクトには、次のように1資料を1件として入れます。

    資料ID:P2
    内容:基本撮影料33,000円(税抜)
    適用開始:2026年9月1日
    状態:承認済み
    ファイル更新日:2026年8月20日

    プロジェクトを作り、指示と料金表を入れる

    画面の操作は、2026年10月20日にブラウザ版Claudeの組織アカウントで確かめた順です。表示の名前は変わることがあります。

    1. 左のメニューの「プロジェクト」から「新規プロジェクト」を選び、名前を入れて、公開設定を「プライベート」のまま「プロジェクトを作成」を押す。

    2. プロジェクト画面の「指示」の「+」を押し、「プロジェクトの指示を設定」に下の指示を貼り付けて「指示を保存」を押す。

    3. 「コンテキスト」の「+」から「テキストコンテンツを追加」を選び、タイトルに資料ID(P1など)、本文に料金表を入れて「コンテンツを追加」を押す。料金表の数だけ繰り返す。

    4. プロジェクト画面の上の入力欄に質問を入れて送る。そのプロジェクトのチャットとして始まる。

    プロジェクトの指示は、アカウントのプロフィールに書いた指示やスタイルと一緒に使われる、と画面に表示されていました。プロフィール側に料金の扱いを書いている場合は、食い違いがないかも見ておきます。

    使ったプロジェクト指示は次のとおりです。

    料金の案内では、見積作成日以前に適用が始まった承認済み資料だけを候補にしてください。その中で適用開始日が最も新しい資料を採用します。同じ適用開始日で金額が異なる承認済み資料がある場合は、回答を保留し、両方の資料IDを示してください。ファイル更新日は採用順位に使いません。出力は「採用料金」「根拠ID」「採用しなかった資料と理由」「確認事項」です。適用日か承認状態が欠ける資料は推測で補完しないでください。現行料金の可能性がある資料でこれらが欠ける場合は、旧版へ戻らず回答を保留してください。

    最後の一文が、承認状態の抜けた最新版があるときに古い料金へ戻らせないための指定です。「採用しなかった資料と理由」を出させるのは、回答を照合するときに、金額だけでなく適用開始日と承認状態まで見られるようにするためです。

    見積作成日を指定して質問し、根拠IDと照合する

    質問は「上の3資料に基づき、2026年9月21日作成の見積もりに使う税抜基本撮影料を整理してください」です。見積作成日を毎回書くことで、同じプロジェクトを別の日の見積もりにも使えます。

    3つの料金表をそのまま入れたプロジェクトでは、回答は「税抜33,000円(基本撮影料)」、根拠IDは「P2(承認済み、適用開始2026年9月1日)」でした。更新日の新しいP1については、次のように書いていました(表現は変えていません)。

    ファイル更新日はP1の方が新しい(2026年9月10日)ものの、採用順位には使わない指定のため判断に影響していません。

    回答を受け取ったら、根拠IDの料金表を開き、そこに書かれた金額が採用料金と同じかを見ます。P2の本文は33,000円なので一致です。もし「P1を根拠に33,000円」のように答えていたら、P1の料金は30,000円なので、その回答は使いません。理由の文がもっともらしくても、金額と根拠の料金表が対応していなければ見積もりには使えません。

    最新版の承認状態が欠けたときの回答

    次に、P2から「状態:承認済み」の行だけを消した料金表で、別のプロジェクトを作って同じ質問を送りました。「承認済みで、見積作成日までに適用が始まっている」という候補条件だけで絞ると、残るのはP1の30,000円です。そこで効いてくるのが、指示に加えた「旧版に戻さず保留する」という条件です。

    回答の採用料金は「回答を保留します。確定できる料金はありません。」でした。P1については次のように書いています(表現は変えていません。以下同じ)。

    P2の承認状態を補完できないため、旧版へ戻る形でのP1採用は行いません。

    確認事項では、確認したあとの金額を分けて示していました。

    1. P2(基本撮影料33,000円・適用開始2026年9月1日)は承認済みですか。承認済みなら、2026年9月21日の見積には33,000円(税抜)を採用できます(根拠ID:P2)。

    2. P2が未承認、または承認されていない場合は、30,000円(税抜)(根拠ID:P1)になります。その場合は、P2が承認されていないことを確認できる状態表示や承認記録をご提示ください。

    承認状態が確認できるまでは、見積書にいずれの金額も記載しないでください。

    承認状態が欠けた最新版があるとき、承認済みの旧版を採らずに保留し、確認後の金額を2通りに分けて示した回答の流れの図
    承認状態の欠けたP2の代わりにP1へ戻らず、確認したあとの金額を分けて示しました。

    この回答なら、確認する相手(料金の管理担当者)に何を聞けばよいかと、答えを聞いたあとに使う金額が、そのまま分かります。料金表の承認が抜けていても、見積書を止めて確認に回す流れが作れます。

    1つ気をつけたいのは、この回答の「根拠ID」の欄です。欄には「P1(承認済み・適用開始2026年4月1日)は、条件上は唯一の候補です。」と、採用しなかった料金表のIDが書かれていました。欄の名前だけを拾って転記すると、P1が根拠のように読めます。照合するときは、欄の名前ではなく、採用料金が保留になっているかどうかと、文の中身で判断します。

    同じ日に始まる料金が2つあるとき

    3つ目のプロジェクトには、P2と同じ2026年9月1日から始まる承認済みの料金表P4(34,000円)を足しました。回答は「保留します。判定できる金額は確定しません。」で、根拠IDにP2とP4の両方を挙げ、「どちらが正しい現行料金なのか、料金の管理担当者に確認してください」と書いていました。どちらかを選んで見積もりに進むことはありませんでした。

    自分の料金表で3つの条件を試す

    3つの回答は、いずれも指示に書いた条件どおりでした。結果は1回ずつのものなので、プロジェクトを見積もりに使い始める前に、自分の料金表と指示で同じ3つの条件を試しておきます。

    試す条件 期待する回答 違ったときに直すこと
    今の料金表のまま 今使う料金と、その料金表のID 料金表の本文に、適用開始と状態が書かれているか
    最新版から状態の行を消す 保留。旧版の料金で答えない 指示に「旧版へ戻らず保留」の一文があるか
    同じ適用開始日の承認済みの料金表を足す 保留。両方のIDを挙げる 指示に「同じ適用開始日で金額が異なる場合は保留」の一文があるか

    条件を変えるときは、同じプロジェクトの料金表を差し替えるより、条件ごとに別のプロジェクトを作るほうが確実です。前の条件の料金表が残らないので、比べたい違いが1つに絞れます。料金表を削除する操作もいりません。試し終えたプロジェクトは、不要になったら削除します。

    回答をお客様への見積もりに使うときは、根拠IDの料金表と金額を人が確かめてから書き写します。料金表を全部入れる前に、よく使う料金表だけでも、資料ID・適用開始・状態をそろえておくと、この照合がすぐにできます。

    参照した公式資料

  • Claude Artifactsで作った見積ツールを、端数がずれる数量の基準表で確かめる

    Claude Artifactsで作った見積ツールを、端数がずれる数量の基準表で確かめる

    数量を入れると本体・税額・合計が出る見積ツールなら、ClaudeのArtifactsに頼めば数分で画面ができます。けれども、画面がきれいに動くことと、金額が正しいことは別です。税額をどの順番で計算するか、空欄や小数を入れたときにどう表示するかは、画面を眺めていても分かりません。

    単価2,501円、税10%、1円未満切り捨ての見積もりで計算してみると、1点ごとに税額を切り捨ててから合計する誤った順序でも、数量1から9までは正しい金額と一致します。初めて1円ずれるのは数量10で、数量100では10円ずれます。数量1や2で画面を確かめただけでは、計算の順序の誤りは見つかりません。

    そこでこの記事では、作る前に計算の順序と受け付ける数量を決め、誤りが金額に出る数量を入れた基準表を用意し、Claudeが作った見積ツールの画面をその表で確かめる手順をまとめます。実際にこの手順でArtifactを1回作らせて確かめた結果も示します。読み終えたら、自分の単価で基準表を作り、Artifactsの見積ツールを社内で使い始めてよいかを判断できます。

    作る前に決めること:計算の順序と、受け付ける数量

    例にしたのは、1点2,501円の加工サービスの見積もりです。数量は1〜100の整数、税は10%で1円未満を切り捨てます。

    計算の順序は「本体合計を出してから、その10%を切り捨てて税額にする」と決めます。数量2なら、本体2,501円×2=5,002円、税額5,002円×10%=500.2円の切り捨てで500円、合計5,502円です。

    もう1つの順序、「1点ごとの税額250.1円を250円に切り捨ててから数量を掛ける」でも、数量2の税額は250円×2=500円で同じになります。2つの順序の税額を数量ごとに並べると、次のようになります。

    数量 本体合計から計算した税額 1点ごとに切り捨てた税額
    1〜9 250円×数量と同じ 同じ(差なし)
    10 25,010円×10%=2,501円 250円×10=2,500円(1円少ない)
    20 50,020円×10%=5,002円 250円×20=5,000円(2円少ない)
    100 250,100円×10%=25,010円 250円×100=25,000円(10円少ない)

    1点ごとの税額で切り捨てた0.1円が、数量10でようやく1円分たまるからです。自分の単価で同じ表を作るときは、1点分の税額の端数(ここでは0.1円)に数量を掛けた値が、初めて1円以上になる数量を探し、その数量を基準表に入れます。端数が出ない単価や、数量の上限内では差が出ない単価なら、差を確かめられる単価もテスト用に用意します。

    受け付ける数量も、作る前に決めておきます。空欄、0、負の数、小数、数字以外、上限の101以上は、金額を出さずに理由を表示する、と決めました。とくに小数は、画面側が1.5を1に直してから計算すると、金額は出るのに入力の誤りが消えてしまいます。

    基準表:計算する値と、金額を出さない値

    画面に入れる値と、期待する表示を表にします。これが確かめるときの基準表です。

    画面に入れる値 期待する表示
    1 本体2,501円・税額250円・合計2,751円
    2 本体5,002円・税額500円・合計5,502円
    10 本体25,010円・税額2,501円・合計27,511円(2,500円なら順序の誤り)
    100 本体250,100円・税額25,010円・合計275,110円(25,000円なら順序の誤り)
    空欄、0、-1、1.5、true、101 金額を出さず、それぞれの理由を表示する

    確かめる順番も決めておきます。数量2を入れて金額を見たあと、同じ入力欄を空欄、0、1.5の順に変え、そのたびに前の金額が消えるかを見ます。エラーのときに表示を更新しない作りだと、前の合計が残ったまま理由だけが出て、誤った金額が読まれてしまうからです。

    Claudeへ渡す制作依頼

    決めたことを、そのまま依頼文に書きます。

    加工サービスの見積試算用Artifactを作ってください。単価は2,501円、数量は1〜100の整数です。本体合計を計算した後、その10%の1円未満を切り捨てて税額とし、本体と税額を合計します。数量が空欄、0、負数、小数、数値以外なら金額を表示せず、理由を示してください。数量を文字列から読み取る際も、小数を整数へ切り捨てないでください。本体、税額、合計を別々に表示し、「試算であり注文未確定」と記載してください。外部通信、顧客情報の入力、データ保存は不要です。

    「小数を整数へ切り捨てない」は、上で書いた1.5を1に直す作りを避けるための一文です。あとから値引きや送料を足すときも、それぞれを税の計算の前に入れるのか後に入れるのかを、先にこの依頼文へ書き足します。

    作られた見積ツールを基準表で確かめた結果

    この依頼文を、ブラウザ版Claudeの新しいチャットに1回送りました(2026年10月20日)。作られた見積ツールには手を加えず、入力欄に基準表の値を打ち込んで表示を確かめました。

    入れた値 画面の表示
    1 本体2,501円・税額250円・合計2,751円
    2 本体5,002円・税額500円・合計5,502円
    10 本体25,010円・税額2,501円・合計27,511円
    100 本体250,100円・税額25,010円・合計275,110円
    空欄 「数量が未入力です」。金額なし
    0 「0は指定できません」。金額なし
    -1 「負の数は指定できません」。金額なし
    1.5 「小数は指定できません」と「数量は整数で入力してください(自動で切り捨てはしません)。」。金額なし
    true 「数値として読み取れません」。金額なし
    101 「数量が上限を超えています」。金額なし

    基準表の値はすべて期待どおりでした。数量2から空欄、0、1.5へと変えたときも、そのたびに前の金額は消え、理由だけが表示されました。「試算であり注文未確定」はページの上部に出ていました。

    数量2で金額を表示したあと、空欄・0・1.5へ変えるたびに前の金額が消えて理由だけが出ることを、基準表と並べて示した図
    数量を変えるたびに、前の金額が残っていないかを見ます。今回の画面では、3回とも理由だけが表示されました。

    画面には、本体・税額・合計のほかに「税額: 5,002 × 10% = 500.2 → 切り捨て 500円」のような計算の途中も表示されていました。切り捨ての前の値が見えるので、基準表と照らすときに、どの段階でずれたかを追えます。

    基準表の外で1つ食い違っていたのは、入力の案内です。入力欄の下の案内は「1〜100の整数を半角数字で入力してください。」でした。一方で、Claudeは回答の中で「全角数字(12)は半角に正規化して受け付けます」と、自分で置いた仮定として書いており、数字以外を入れたときの説明文は「半角数字(または全角数字)の整数だけを入力してください。」でした。全角の数字も受け付けるのに、案内は半角を求めています。金額は変わりませんが、使う人は全角で入れてよいのか迷います。

    このように、依頼文に書かなかったことは、作る側の判断で決まります。Claudeは回答の最後に「私が置いた仮定」として、全角数字のほか、「1.0」を小数として断ることなどを挙げていました。作られたツールを確かめるときは、基準表に加えて、この仮定の一覧も読み、案内文と食い違っていないかを見ます。

    確かめたあとに直すときの頼み方

    食い違いは、同じチャットで直してもらいます。たとえば全角の数字を受け付けたままにするなら、次のように頼みます。

    入力欄の案内文を「1〜100の整数を入力してください(全角数字も使えます)。」に変えてください。計算と入力の判定は変えないでください。

    半角だけにしたいなら、「全角数字を半角に直す処理を外し、全角数字は数値以外として断ってください」と頼みます。どちらの場合も、直ったあとに基準表の値をもう一度入れ、計算の結果が変わっていないことを確かめます。

    社内で使い始める前に

    このときのアカウントでは、Artifactはチャットの横の表示ではなく、共有範囲が「あなたのみ」の公開ページとして作られました。社内の人に共有するのは、基準表との照合と、案内文の直しが終わってからにします。最初は社内の試算用として使い、お客様に出す正式な見積書は、担当者が金額を確かめてから作ります。

    自分の見積もりで始めるなら、料金が1つで値引きのない業務を選び、単価・税率・端数処理・数量の上限を書き出して、1点分の税額の端数が1円になる数量を探すところから始めます。その数量を入れた基準表ができれば、依頼文はこの記事のものを書き換えるだけで使えます。

    参照した公式資料

  • AIに売上CSVの集計を作らせる前に、重複・返金・不正値の扱いと停止条件をテストで固定する

    AIに売上CSVの集計を作らせる前に、重複・返金・不正値の扱いと停止条件をテストで固定する

    月次の売上CSVを集計するスクリプトを、Claude CodeやCodexのようなAIコーディングツールに作らせると、動くコードはすぐに返ってきます。けれども売上CSVには、同じ取引の二重取り込み、返金、まだ確定していない保留、日付の書き方が崩れた行や空欄の金額が混ざります。どの行をどう扱うかを決めずに頼むと、返ってきたコードが正しいのかを判断する材料がありません。

    そこで、各行の扱いと集計を止める条件をテストに書いて先に渡し、返ってきた実装をそのテストで確かめます。このとき、件数の確かめ方に落とし穴がありました。隔離した行の件数を「理由の数」で数え、日付を読めなかった行を黙って飛ばす実装をわざと作って試すと、8行のCSVで、分類した件数の合計は8件で入力行数と一致し、区分ごとの件数も売上・返金・差額の金額も正しい値と同じでした。行番号を並べて初めて、9行目が消え、8行目が2回数えられていると分かりました。

    この記事では、検査用のCSVと各行の扱い、集計を止める3つの条件、行番号ごとの照合まで含めたテスト、AIに渡す依頼文、照合用の参照実装を、そのまま使える形で渡します。読み終えたら、自分の売上CSVの仕様に合わせてテストを書き換え、AIが返した集計スクリプトを採用するかを判断できます。

    検査用のCSVと、各行の扱い

    テストに使うCSVは8行です。kindは種別で、saleが売上、refundが返金、pendingが保留、refは返金元の取引IDです。金額は常に正の数で持ち、返金かどうかは種別で分けると決めています。

    id,date,kind,amount,ref
    A1,2026-09-01,sale,10000,
    A2,2026-09-02,sale,3000,
    A2,2026-09-02,sale,3000,
    R1,2026-09-05,refund,3000,A2
    P1,2026-09-06,pending,5000,
    X1,2026-09-07,sale,oops,
    X2,2026/09/08,sale,,
    X3,09-04-2026,sale,800,

    1行目は見出しなので、データは2行目から9行目です。各行の扱いは次のとおりです。

    行 扱いと理由 差額への反映
    2行目 A1 売上 +10,000円
    3行目 A2 売上 +3,000円
    4行目 A2 重複:3行目と全項目が同じ 入れない
    5行目 R1 返金:A2の返金 −3,000円
    6行目 P1 保留:種別がpending 入れない
    7行目 X1 隔離:金額がoops 入れない
    8行目 X2 隔離:日付がスラッシュ区切り、金額が空欄 入れない
    9行目 X3 隔離:日付の月日の順が決められない 入れない

    売上は10,000円+3,000円=13,000円、返金は3,000円、差額は10,000円です。件数は売上2・返金1・重複1・保留1・隔離3で、合計8行になります。

    金額の列を種別を見ずに足すと、重複の3,000円、返金の3,000円、保留の5,000円、9行目の800円まで売上に入ります。そして10,000円が出ても、隔離した3行と保留の1行は何も片付いていません。この差額は、扱いを決められた行だけにもとづく暫定の値として扱います。

    書式の崩れた行は、直さずに隔離して理由を全部残す

    日付や金額の崩れた行を、AIに「きれいに直して」と頼むと、数字が静かに変わります。たとえば金額の空欄を0円にすると、エラーは出ませんが、「売上がなかった」と「記入漏れ」が区別できなくなります。そこで、1行ごとの書式は次のように検査し、合わない行は直さずに隔離します。

    項目 受け付ける値 しないこと
    日付 実在するYYYY-MM-DD スラッシュ区切りや月日の順を推測で直さない
    金額 1以上の整数 空欄を0円にしない。文字を数字に読み替えない
    種別 sale、refund、pendingのどれか 知らない種別を売上として扱わない

    9行目の09-04-2026は、9月4日なのか4月9日なのかを、CSVからは決められません。推測で直すと、書式の検査は通るのに中身は別の日付というデータができます。だから元の値のまま確認に回します。

    隔離した行には、元の行番号、元の値、当てはまる理由をすべて残します。8行目には日付と金額の2つの問題があります。最初の理由だけで打ち切らずに両方を残すと、直す人が確認する箇所をまとめて追えます。保留の6行目は、書式としては正しい行ですが、売上には数えません。行として正しいかどうかと、売上として数えるかどうかは別の判断です。

    集計を止める3つの条件

    隔離とは別に、集計そのものを続けてはいけない状態があります。次の3つは、集計値を出す前に止めます。

    • 同じIDで内容が違う行がある(重複なのか別の取引なのかを決められない)。

    • 返金のrefが、同じCSVの売上にない。

    • 1つの売上に対する返金の累計が、元の売上を超える。

    重複かどうかを、日付や金額の一致だけで判断しないのは、同じ金額の商品が別々に売れることは普通にあるからです。取引IDが元のシステムで一意だと保証されていないなら、先に取引の見分け方を決めるところから始めます。

    件数が合っても、行が正しく扱われたとは限らない

    集計の処理には、取りこぼしの確認として「分類した件数の合計=入力行数」を入れることがよくあります。この照合だけで足りるかを確かめるため、2つの誤りを入れた実装をわざと作り、正しく動く参照実装と同じテストを流しました(Python 3.10、2026年10月21日)。誤りの1つ目は、隔離した行の件数を行ではなく理由の数で数えたこと。2つ目は、日付の読み取りで例外になった行を、数えずに飛ばしたことです。

            if "/" in row["date"]:
                reasons.append("日付がYYYY-MM-DDでない")
            else:
                try:
                    date.fromisoformat(row["date"])
                except ValueError:
                    continue  # 読めない日付の行を、数えずに飛ばす
            # (金額の検査は省略)
            if reasons:
                for reason in reasons:  # 隔離の件数を、理由の数だけ数える
                    lines.append((line, "quarantine"))

    結果は次のとおりです。

    確かめたこと 参照実装 誤りを入れた実装
    売上・返金・差額 13,000円・3,000円・10,000円 同じ
    区分ごとの件数 売上2・返金1・重複1・保留1・隔離3 同じ
    件数の合計と入力行数 8件と8行で一致 8件と8行で一致
    扱った行番号 2, 3, 4, 5, 6, 7, 8, 9 2, 3, 4, 5, 6, 7, 8, 8

    9行目のX3は日付が読めずに飛ばされ、その1件分を、理由が2つある8行目のX2が2回数えられて埋めていました。数え落としと二重計上が相殺されて、件数の合計も区分ごとの件数も、正しい値と同じになったのです。金額に影響しない行で起きた誤りなので、金額のテストでも見つかりません。

    見つけたのは、扱った行番号を順に並べて、2行目から9行目までがちょうど1回ずつ出ているかを確かめるテストと、隔離した行の行番号・値・理由を照らすテストでした。そこで、AIに渡すテストには、件数と金額に加えて、この2つを入れます。

    件数の合計と金額は正しい実装と同じでも、行番号を並べると9行目が消えて8行目が2回出ている誤った実装を、正しい実装と並べた図
    件数の合計と区分ごとの件数は8件で一致しましたが、行番号ごとに照らすと、9行目の欠落と8行目の二重計上が見えました。

    AIに渡すテスト:test_sales.py

    空のフォルダに次をtest_sales.pyとして保存し、依頼文と一緒にAIコーディングツールへ渡します。実装する関数の入口と、期待する結果をここで固定します。Python 3.10以降の標準機能だけで動きます。

    コードを開く
    import unittest
    from sales import summarize
    
    DATA = """id,date,kind,amount,ref
    A1,2026-09-01,sale,10000,
    A2,2026-09-02,sale,3000,
    A2,2026-09-02,sale,3000,
    R1,2026-09-05,refund,3000,A2
    P1,2026-09-06,pending,5000,
    X1,2026-09-07,sale,oops,
    X2,2026/09/08,sale,,
    X3,09-04-2026,sale,800,
    """
    
    
    class SalesTests(unittest.TestCase):
        def test_totals_and_counts(self):
            result = summarize(DATA)
            self.assertEqual((result["revenue"], result["refund"], result["net"]),
                             (13000, 3000, 10000))
            self.assertEqual(result["counts"], {"sale": 2, "refund": 1, "duplicate": 1,
                                                "pending": 1, "quarantine": 3})
    
        def test_every_line_once(self):
            lines = [line for line, _ in summarize(DATA)["lines"]]
            self.assertEqual(lines, list(range(2, 10)))
    
        def test_quarantine_keeps_values_and_all_reasons(self):
            got = [(q["line"], q["id"], q["row"]["date"], q["row"]["amount"], q["reasons"])
                   for q in summarize(DATA)["quarantine"]]
            self.assertEqual(got, [
                (7, "X1", "2026-09-07", "oops", ["金額が正の整数でない"]),
                (8, "X2", "2026/09/08", "", ["日付がYYYY-MM-DDでない", "金額が空欄"]),
                (9, "X3", "09-04-2026", "800", ["日付がYYYY-MM-DDでない"]),
            ])
    
        def test_conflicting_id(self):
            with self.assertRaisesRegex(ValueError, "同一IDの内容が不一致"):
                summarize(DATA + "A2,2026-09-02,sale,4000,\n")
    
        def test_missing_sale(self):
            with self.assertRaisesRegex(ValueError, "返金元がない"):
                summarize(DATA + "R2,2026-09-10,refund,100,A9\n")
    
        def test_excess_refund(self):
            with self.assertRaisesRegex(ValueError, "売上を超える返金"):
                summarize(DATA + "R2,2026-09-10,refund,1,A2\n")
    
    
    if __name__ == "__main__":
        unittest.main()

    6つのテストのうち、最初の1つが金額と件数、次の2つが行番号ごとの照合と隔離した行の中身、残りの3つが集計を止める条件です。

    依頼文

    依頼文には、テストに書いた扱いを言葉でも書き、テストを変えないことを頼みます。

    元のCSVを変更せず、売上・返金・差額と、行ごとの扱いを出す処理を作ってください。同じIDで全項目が一致する行は重複として除外します。同じIDで内容が違う場合、返金元がない場合、返金の累計が元の売上を超える場合は、テストに示したメッセージのValueErrorで止めてください。日付・金額・種別の書式が合わない行は直さずに隔離し、元の行番号、元の値、当てはまる理由をすべて残してください。日付を推測で直さず、金額の空欄を0にしないでください。保留は件数だけを数え、差額は暫定の値と明記してください。添付のtest_sales.pyを満たすsales.pyを作り、summarize(text)はテストが読む形の辞書を返してください。変更のたびにpython3 -m unittest -v test_sales.pyを実行し、テストの入力・期待値・停止条件は変更しないでください。

    返ってきた実装を確かめる

    依頼する前に、テストのファイルのハッシュ(内容から計算する短い識別値)を控えておきます。

    shasum -a 256 test_sales.py

    実装が返ってきたら、同じコマンドでハッシュを出し、依頼前と同じかを見ます。違っていれば、テストが書き換えられています。テストや期待値を変えたいという提案があったら、実装に合わせて受け入れるのではなく、仕様と実装のどちらに問題があるかを先に調べます。ハッシュが同じなら、テストを流します。

    python3 -m unittest -v test_sales.py

    照合用の参照実装(下)で流したときの結果です。返ってきた実装でも6件がokになれば、テストに書いた扱いは満たしています。

    test_conflicting_id (test_sales.SalesTests) ... ok
    test_every_line_once (test_sales.SalesTests) ... ok
    test_excess_refund (test_sales.SalesTests) ... ok
    test_missing_sale (test_sales.SalesTests) ... ok
    test_quarantine_keeps_values_and_all_reasons (test_sales.SalesTests) ... ok
    test_totals_and_counts (test_sales.SalesTests) ... ok
    
    ----------------------------------------------------------------------
    Ran 6 tests in 0.001s
    
    OK

    テストが通っても、それはテストに書いた8行と3条件について正しいということです。依頼文に書かなかった扱い(たとえば、金額の桁区切りのカンマや、別の月の売上を参照する返金)は、AIの判断で決まっています。返ってきたコードを読み、仕様にない扱いを見つけたら、テストに1行足してから直してもらいます。今回の失敗例もテストに残したまま変更させると、あとで処理を整理したときに、止める条件や行番号の照合が消えるのを防げます。

    照合用の参照実装:sales.py

    テストと期待値が正しいかを、依頼する前に手元で確かめるための実装です。AIに新しく作らせるフォルダには、テストと依頼文だけを置き、この参照実装は別のフォルダに保存しておきます。同じフォルダに置くと、AIが参照実装を読めてしまい、仕様とテストから作った実装かどうかを確かめられなくなるからです。

    コードを開く
    import csv
    import io
    import re
    from datetime import date
    
    
    def check_row(row):
        """1行の書式を検査し、当てはまる理由をすべて返す。直さない。"""
        reasons = []
        if not re.fullmatch(r"\d{4}-\d{2}-\d{2}", row["date"]):
            reasons.append("日付がYYYY-MM-DDでない")
        else:
            try:
                date.fromisoformat(row["date"])
            except ValueError:
                reasons.append("日付が実在しない")
        if row["amount"] == "":
            reasons.append("金額が空欄")
        elif not re.fullmatch(r"[1-9]\d*", row["amount"]):
            reasons.append("金額が正の整数でない")
        if row["kind"] not in {"sale", "refund", "pending"}:
            reasons.append("種別が不明")
        return reasons
    
    
    def summarize(text):
        rows = list(csv.DictReader(io.StringIO(text)))
        seen, sales, refunds = {}, {}, []
        lines, quarantine = [], []
        for line, row in enumerate(rows, start=2):  # 1行目は見出し
            key = row["id"]
            if not key:
                raise ValueError("IDなし")
            if key in seen:
                if row != seen[key]:
                    raise ValueError("同一IDの内容が不一致")
                lines.append((line, "duplicate"))
                continue
            seen[key] = row.copy()
            reasons = check_row(row)
            if reasons:
                quarantine.append({"line": line, "id": key, "row": row.copy(), "reasons": reasons})
                lines.append((line, "quarantine"))
            elif row["kind"] == "pending":
                lines.append((line, "pending"))
            elif row["kind"] == "sale":
                sales[key] = int(row["amount"])
                lines.append((line, "sale"))
            else:
                refunds.append((row["ref"], int(row["amount"])))
                lines.append((line, "refund"))
        returned = {}
        for ref, amount in refunds:
            if ref not in sales:
                raise ValueError("返金元がない")
            returned[ref] = returned.get(ref, 0) + amount
            if returned[ref] > sales[ref]:
                raise ValueError("売上を超える返金")
        revenue, refund = sum(sales.values()), sum(returned.values())
        counts = {name: sum(1 for _, c in lines if c == name)
                  for name in ("sale", "refund", "duplicate", "pending", "quarantine")}
        return {"revenue": revenue, "refund": refund, "net": revenue - refund,
                "counts": counts, "lines": lines, "quarantine": quarantine}

    隔離した行は、quarantineに元の行番号・ID・元の行の値・理由の一覧として残ります。担当者は、この一覧から元のCSVの該当行へ戻り、直すか、売上から外すかを決めます。

    自分の売上CSVへ広げるときに決めること

    このテストの入力条件は、UTF-8、id・date・kind・amount・refの5列、正の整数の金額、同じCSVの中の売上を参照する返金です。自分のデータへ広げる前に、次を決めてテストに書き足します。

    • 文字コード(表計算ソフトから書き出したCSVは、UTF-8でないことがあります)、列の名前、金額の桁区切りと通貨。

    • 計上日のルールと、前の月の売上に対する返金の照合先。

    • 取引IDが一意でない場合の、取引の見分け方。

    元のファイルは読み取り専用のコピーで扱い、隔離した行と保留の行を担当者が片付けるまでは、確定の月次売上として配らない、という扱いも仕様に足しておきます。

  • Claudeで下書きしたお客様への返信を、送る前に資料と一文ずつ照らし合わせる

    Claudeで下書きしたお客様への返信を、送る前に資料と一文ずつ照らし合わせる

    小さなお店や個人で仕事を受けていると、「この日までに届きますか」という問い合わせに、在庫も配送日数もまだ分からない段階で返事をしなければならないことがあります。Claudeに下書きを頼めば丁寧な文面はすぐにできますが、そのまま送ってよいかは、文面の自然さからは判断できません。

    名入れノートを扱う店の問い合わせを例に、店の資料と依頼文をClaudeに渡して、返信を下書きさせました(資料を一部変えて1回ずつ、計2回)。Claudeは2回とも、お客様の希望日を店の約束としては書きませんでした。送る前に直す必要があったのは、丁寧さのために足された一文のほうです。「お届け先によって配送日数が異なります」という補足は資料にない情報で、「改めてご案内いたします」「確認してご連絡いたします」という結びは、誰がいつ連絡するかを決めていない店の約束でした。

    納期の文だけを見ていると、こうした一文は見落とします。そこで、店の資料を4つに分けて渡す入力表と依頼文、返信を一文ずつ資料と照らして「そのまま送れる文」「送る前に直す文」「店で決めてから残す文」に分ける手順を、実際の下書きで示します。読み終えたら、自分の店の資料で同じ照合を行い、送る前に直す文を決められます。

    送る前の返信を、3種類の文に分ける

    照合のゴールは、下書きのすべての文を次の3つのどれかに分けることです。分け方の基準は「その文を、渡した資料のどの行で説明できるか」だけです。

    分け方 当てはまる文 送る前にすること
    そのまま送れる文 資料の行で説明できる。希望の受け止め、決まっている条件、受付に必要な質問など なし
    送る前に直す文 資料のどの行にもない情報や、お客様へのお願いを含む 削るか、資料で確かめてから書き直す
    店で決めてから残す文 「ご連絡いたします」「ご案内いたします」など、店の次の行動を約束する 誰が、いつ行うかを決めてから残す。決まらなければ削る

    3つ目を分けておくのは、期限が書かれていなくても、受け取ったお客様は次の連絡を待つからです。誰が連絡するかを決めないまま送ると、担当のいない仕事が店の側に残ります。

    手順1:店の資料を4つに分けて書き出す

    Claudeに渡す資料を、次の4区分に分けます。例として用意した名入れノートの店の資料です。自分の店で使うときは、右の列を注文ごとの内容に書き換えます。

    区分 入力する内容
    顧客の希望 名入れノート20冊を9月25日までに受け取りたい。注文方法を知りたい
    店の確定ルール 名入れ原稿の承認後、制作に3営業日かかる
    受付に必要な情報 ノートの色、印字内容、配送先の都道府県
    未確認 希望色の在庫、原稿の承認日、配送日数

    お客様の希望、店が決めていること、受付で聞くこと、まだ分からないことを分けておけば、Claudeも自分も、希望と約束を取り違えにくくなります。ここで書いた行が、手順3で返信の一文ずつを照らす「資料の行」になります。

    制作期間のように起算点がある条件は、起算点まで書きます。この店では制作が始まるのは原稿の承認日からなので、制作に3営業日と分かっていても、承認日と配送日数が決まるまで到着日は出せません。

    手順2:資料だけを根拠にする依頼文を送る

    新しいチャットに上の表を貼り付け、続けて次の依頼文を送ります。

    この資料だけを根拠に、お客様への返信案を作ってください。顧客の希望日を店の確約日として書かないでください。制作期間と起算点は資料の記載どおりに扱い、資料にない場合は確認事項にしてください。まず社内確認用に「確定事項」「未確認事項」を分け、その後に返信文を示してください。返信では希望を受け止め、在庫と配送条件の確認が必要なことを伝え、受付に必要な情報を尋ねてください。資料にない価格や、確認完了までの時間は加えないでください。

    依頼文には制作日数などの数字を書き込まず、毎回の資料を参照させています。注文ごとに表だけを差し替えれば、同じ依頼文を使い回せます。価格と確認完了までの時間を禁じているのは、どちらも資料になければ店の約束になってしまうからです。「本日中にご連絡します」のような折り返しの期限も、担当と手順が決まるまでは書かせません。

    手順3:返信を一文ずつ資料と照らす

    返事が届いたら、返信文案を句点で区切り、一文ずつ次の順で見ていきます。

    1. その文を説明できる資料の行(4区分のどれか)を探す。

    2. 行が見つかれば「そのまま送れる文」にする。

    3. 見つからない文のうち、店の次の行動を約束する文は「店で決めてから残す文」、それ以外は「送る前に直す文」にする。

    返信の一文ごとに資料の行を探し、そのまま送れる文、送る前に直す文、店で決めてから残す文の3つに分ける図
    今回の下書きでは、資料の行で説明できない一文は、括弧の補足、原稿の催促、結びにありました。

    とくに丁寧に見るのは、括弧の中の補足、段落の終わりの結び、次の連絡を約束する文です。納期や価格の文は誰でも気をつけて読みますが、丁寧さのために足された文は自然に読めてしまい、資料と照らさないと気づきません。日付・数量・金額・期限に印を付けておくと、お客様の希望と店が引き受ける約束を追いやすくなります。

    Anthropicも、Claudeが誤った内容や根拠のない情報を示す場合があると説明しています(Claudeの誤情報についての公式説明、確認日:2026年10月17日)。文面が自然かどうかとは別に、資料との一致を一文ずつ確かめます。

    実際の下書きを照らした結果

    手順1の資料と手順2の依頼文を、ブラウザ版Claudeの新しいチャットに1回送りました(2026年10月18日)。社内確認欄では、制作期間を「名入れ原稿の承認後、3営業日(起算点は原稿承認後)」と整理し、在庫・承認日・配送日数を未確認として分けていました。次はClaudeが返した返信文案の全文で、表現は直していません。末尾近くの年の質問は、依頼した日(2026年10月18日)が希望日の9月25日より後だったために出たものです。

    件名:名入れノートのご注文について

    ○○様

    このたびは名入れノート20冊のご注文をご検討いただき、ありがとうございます。9月25日までにお受け取りになりたいとのご希望、承知いたしました。

    ご希望の日程に間に合うかどうかは、現時点ではお約束できません。以下の2点を確認する必要があるためです。

    1. ご希望色の在庫状況

    2. 配送条件(お届け先によって配送日数が異なります)

    制作には、名入れ原稿をご承認いただいてから3営業日かかります。ご承認の時期によって仕上がり時期が変わりますので、原稿のご確認はお早めにお願いできますと幸いです。

    在庫と配送条件の確認を進めるため、次の3点をお知らせください。

    • ノートの色

    • 印字内容

    • 配送先の都道府県

    ご注文手続きの詳細は、上記の情報をいただいたうえで改めてご案内いたします。

    (任意)なお、9月25日は何年のご希望でしょうか。念のため、年も含めてお知らせいただけますと助かります。

    ご不明点がございましたら、お気軽にお問い合わせください。どうぞよろしくお願いいたします。

    ○○(店名・担当者名)

    この返信を一文ずつ資料と照らすと、次のように分かれました。

    返信の文 説明できる資料の行 分け方と、送る前にすること
    「9月25日までにお受け取りになりたいとのご希望、承知いたしました」 顧客の希望 そのまま送れる
    「現時点ではお約束できません」と、確認する「ご希望色の在庫状況」 未確認(在庫・承認日・配送日数) そのまま送れる
    「配送条件(お届け先によって配送日数が異なります)」 「配送条件」は未確認の配送日数に当たる。届け先で日数が変わることは、どの行にもない 送る前に直す:括弧内を削る
    「名入れ原稿をご承認いただいてから3営業日かかります」と「ご承認の時期によって仕上がり時期が変わります」 店の確定ルール(起算点は原稿の承認) そのまま送れる
    「原稿のご確認はお早めにお願いできますと幸いです」 なし。原稿をいつ、どう案内するかが資料にない 送る前に直す:削る。原稿の案内方法が決まってから頼む
    色・印字内容・都道府県の3点の質問 受付に必要な情報 そのまま送れる
    「改めてご案内いたします」 なし。誰が、いつ案内するかが決まっていない 店で決めてから残す:担当と案内の時期を決めて書き添える
    「(任意)なお、9月25日は何年のご希望でしょうか」 顧客の希望の日付に年がない 送る前に直す:希望日がまだ先なら削る。過ぎた日付の問い合わせなら残し、「(任意)」だけを削る
    宛名「○○様」と署名 なし 送る前に直す:実際の名前に置き換える

    希望日を店の約束として書いた文はなく、資料にない価格や「本日中に」のような期限も入っていませんでした。直す必要があったのは、括弧の中の補足、原稿の催促、結びの「改めてご案内いたします」で、どれも返信を丁寧にするために足された一文です。

    直したあとの返信

    表のとおりに直すと、次のようになります。Claudeの下書きを照合結果に合わせて直した例で、[]の部分は店で決めてから埋めます。年の質問は、希望日がまだ先の時期に返信する場合を想定して削りました。

    件名:名入れノートのご注文について

    [お客様のお名前]様

    このたびは名入れノート20冊のご注文をご検討いただき、ありがとうございます。9月25日までにお受け取りになりたいとのご希望、承知いたしました。

    ご希望の日程に間に合うかどうかは、現時点ではお約束できません。以下の2点を確認する必要があるためです。

    1. ご希望色の在庫状況

    2. 配送条件

    制作には、名入れ原稿をご承認いただいてから3営業日かかります。ご承認の時期によって仕上がり時期が変わります。

    在庫と配送条件の確認を進めるため、次の3点をお知らせください。

    • ノートの色

    • 印字内容

    • 配送先の都道府県

    ご注文手続きの詳細は、上記の情報をいただいたうえで、[担当者名]より[ご案内の時期]に改めてご案内いたします。

    ご不明点がございましたら、お気軽にお問い合わせください。どうぞよろしくお願いいたします。

    [店名・担当者名]

    担当とご案内の時期が決められない段階なら、「改めてご案内いたします」の一文ごと削り、お客様からの返事を待ってから次の案内を送るほうが安全です。

    資料に書けていない項目は、返信にも確認事項として残っているかを見る

    実際の注文では、制作期間のように資料へ書けていない項目が出てきます。そのときは、社内確認欄だけでなく、お客様向けの文にも確認事項が残っているかを見比べます。

    同じ依頼文で、資料の表から「店の確定ルール」の行だけを削り、別の新しいチャットに1回送りました。Claudeは3営業日を補わず、社内確認欄では「制作期間と起算点|資料に記載なし。確認が必要」と分けました。一方、お客様向けの返信で確認すると伝えていたのは、次の2つの項目だけでした。

    ご希望の納期に間に合うかどうかは、ノートの在庫状況と配送条件を確認したうえでのご案内となります。

    いただいた内容をもとに、在庫と配送条件を確認してご連絡いたします。

    制作期間がお客様向けの確認事項から抜けているので、送る前に「ノートの在庫状況、制作期間、配送条件」と補います。2つ目の文は、1回目の「改めてご案内いたします」と同じく店の次の連絡を約束する結びで、担当と時期を決めてから残します。社内確認欄で正しく分けられていても、その分け方が返信の文まで届くとは限らないので、2つの欄を並べて照らします。

    自分の店で使うときに書き換える箇所

    • 手順1の表の右の列:注文ごとに、希望・決まっていること・受付で聞くこと・まだ分からないことを書き換えます。

    • 依頼文:そのまま使えます。資料にない項目を確認事項にする指示が、資料の抜けを返信の確認事項へつなぎます。

    • 照合の3分類:そのまま使えます。下書きの文面は依頼のたびに変わりうるので、照合は送る下書きごとに行います。

    打ち合わせのメモをClaudeに整理させたときに、整理表の担当と期限の欄を元の発言に戻して確かめる方法は、議事メモの担当と期限の確かめ方で扱っています。

  • Claudeに議事メモを整理させたら、担当と期限の欄だけを元の発言に戻して確かめる

    Claudeに議事メモを整理させたら、担当と期限の欄だけを元の発言に戻して確かめる

    打ち合わせのメモをClaudeに整理させると、決定事項・担当・期限が表にそろって返ってきます。読みやすくなる一方で、表の欄が埋まっていると、その項目まで決まったように見えます。メモにない担当者や期限が欄に入っていても、気づかないまま作業を進めてしまうことがあります。

    教室の体験会準備を例に、5行のメモと依頼文をClaudeの新しいチャットに送りました(2026年10月20日、1回)。依頼文には「担当者と期限が明示されていなければ『未定』と書いて」と入れています。それでもClaudeは、まだ決まっていない「申込フォームの公開日」の担当欄に「運営担当(フォーム作成者として)」と書きました。そして同じ回答の補足では、「公開日の決定者や作業担当はL4では明示されていません」と自分で断っていました。補足の断りと表の欄が食い違っていたのです。

    補足まで読み込まなくても、こうした欄は見つけられます。この記事では、決定・提案・未決と根拠の発言番号を分けさせる依頼文と、整理表の担当・期限の欄だけを元の発言に戻して確かめる手順を、実際の整理結果で示します。読み終えたら、自分の打ち合わせのメモで、送る前・作業を始める前に直す欄を見つけられます。

    発言に番号を付けたメモと依頼文

    メモは、短い発言ごとに番号を振って書きます。番号は、整理結果を元の発言に戻すときの手がかりになります。例にしたのは、教室の店主と運営担当が体験会の準備を話した5行です。

    L1:店主「体験会の受付は予約制にしましょう」
    L2:運営担当「賛成です。予約制で進めます」
    L3:店主「チラシは青がよさそうですが、色は次回決めましょう」
    L4:運営担当「申込フォームは私が作ります。公開日はまだ決められません」
    L5:店主「告知文も必要ですね。担当は後で相談しましょう」

    このメモの後に、次の依頼文を付けて送ります。

    この議事メモを「決定」「提案」「未決」に分けてください。各行に根拠の発言番号を付け、担当者と期限が明示されていなければ「未定」と書いてください。「必要」という発言だけで担当タスクを割り当てないでください。最後に、次回確認する質問を作ってください。元のメモにない日付を加えないでください。

    「『必要』という発言だけで担当タスクを割り当てない」と書くのは、L5が告知文の必要性を述べただけで、担当を決めていないからです。メモに照らすと、担当がはっきりしているのはL4の「申込フォームを作る」の運営担当だけで、期限はどの項目にもありません。

    実際の整理結果と、食い違っていた欄

    Claudeの整理は、分類の大筋ではメモのとおりでした。予約制はL1の提案にL2が賛成したので決定、申込フォームの作成は運営担当が引き受けたので決定、チラシの青は提案、告知文の担当は未決です。メモにない日付も加えていません。

    食い違っていたのは、未決の表の1つの欄です。表と、その直後の補足を、表現を変えずに抜き出します。

    | 内容 | 担当者 | 期限 | 根拠 |
    |---|---|---|---|
    | チラシの色の最終決定 | 未定 | 次回(日付は未定) | L3 |
    | 申込フォームの公開日 | 運営担当(フォーム作成者として) | 未定 | L4 |
    | 告知文の作成担当 | 未定 | 未定 | L5 |

    L5の「告知文も必要ですね」は必要性の確認にとどまるため、告知文の作成タスクは誰にも割り当てていません。担当は「後で相談」とあるため未決です。公開日の担当欄は、フォーム作成者が運営担当であることから書いていますが、公開日の決定者や作業担当はL4では明示されていません。

    L4で運営担当が引き受けたのはフォームを作ることで、公開日については「まだ決められません」と言っています。公開日を誰が決めるのか、公開の作業を誰がするのかは、メモのどこにもありません。この欄を信じて進めると、運営担当は自分が公開日を決める役になったとは思っていないのに、周りはそう受け取ります。

    表だけを読む人は、補足の「明示されていません」を目にしません。整理表を共有したり、作業の一覧に写したりするときに残るのは表のほうです。だから確かめる場所は、補足ではなく表の欄に置きます。

    担当と期限の欄を、元の発言に戻す手順

    整理結果を受け取ったら、表全体を読み直す前に、次の順で担当と期限の欄だけを見ます。

    1. 表の担当・期限の欄のうち、「未定」以外の値が入った欄に印を付けます。今回の表では、申込フォームの作成の「運営担当」、申込フォームの公開日の「運営担当(フォーム作成者として)」、チラシの色の「次回(日付は未定)」の3つです。

    2. 印を付けた欄ごとに、その行の根拠の発言番号を開き、その項目の作業・判断を誰が引き受けたか、またはその項目をいつまでに行うかが明示されているかを見ます。同じ名前や日付があるだけでは足りません。

    3. その項目の担当・期限として明示されていれば残します。別の作業の担当や日付しか書かれていなければ「未定」に直し、次回の質問に加えます。

    整理表の担当と期限の欄に入った値を、根拠の発言番号に戻して、残す欄と未定に直す欄に分ける図
    今回の表で直す必要があったのは、申込フォームの公開日の担当欄でした。

    今回の3つの欄を戻すと、次のようになります。

    表の欄 戻した発言 処置
    申込フォームの作成:担当「運営担当」 L4「申込フォームは私が作ります」 残す
    申込フォームの公開日:担当「運営担当(フォーム作成者として)」 L4「公開日はまだ決められません」。誰が決めるかはない 未定に直す:次回「公開日は誰が決めますか」と聞く
    チラシの色の最終決定:期限「次回(日付は未定)」 L3「色は次回決めましょう」 残す:次回の打ち合わせの日付が決まったら書き添える

    今回の「運営担当(フォーム作成者として)」は、別の作業の担当から推測して埋めた値でした。括弧の有無だけでは判断せず、発言番号に戻すと、推測の根拠になった発言(ここではL4の前半)と、欄が答えるべき内容(公開日の担当)が別だと分かります。

    直したあとの整理表

    表のとおりに直すと、未決の表は次のようになります。Claudeの整理結果を、発言番号との照合に合わせて直した例です。

    内容 担当者・期限 根拠
    チラシの色の最終決定 担当:未定、期限:次回の打ち合わせ(日付は未定) L3
    申込フォームの公開日 担当:未定、期限:未定 L4
    告知文の作成担当 担当:未定、期限:未定 L5

    次回確認する質問には、Claudeが作った「申込フォームの公開日はいつにしますか」に、「公開日は誰が決めますか」を足します。担当が決まらないままでは、公開日を聞く相手も決まらないからです。

    メモが変わると、整理のどこが変わるか

    同じ依頼文で、メモを2通りに変えて、それぞれ新しいチャットに1回ずつ送りました。自分のメモでは、こうした違いが整理のどこに出るかを見ておくと、確かめる場所を絞れます。

    L2(運営担当の賛成)を消した場合。 Claudeは冒頭で「L2 が欠けています」と指摘しました。そのうえで、予約制を決定の表に入れ、次の注記を付けました(表現は変えていません)。

    L1 は「しましょう」という提案の形ですが、他に異論が出ていない前提で「決定」に入れました。L2 が反対意見や保留だった場合は「提案」に移してください。

    L1は店主の提案だけで、ほかの参加者が賛成した記録はありません。表だけを見ると予約制は決定に並ぶので、注記を読まないと「合意済み」と受け取ります。決定の表に入った項目は、根拠の発言番号が提案した人の発言だけになっていないかも見ます。申込フォームの公開日の担当欄には、元のメモのときと同じく「運営担当」と入っていました。

    L4の「私が作ります」を「誰か作れますか」に変えた場合。 申込フォームの作成者は未決の表に移り、担当は未定になりました。公開日の担当も未定でした。今回の変更後の回答では、作成と公開日の両方が未定になりました。元の回答は補足で「フォーム作成者」であることを公開日の担当欄の根拠にしていました。別の作業を引き受けた発言を、その項目の担当の根拠に使っていないかも確かめます。

    次の打ち合わせでできること

    整理表で未定に戻した欄は、次の打ち合わせの最後に読み上げて、その場で担当と期限を決めるか、未定のまま残すかを参加者と確かめます。メモには残らなかった口頭の合意があったとしても、発言番号をたどっても見つからないので、参加者に聞いて記録のほうを直します。

    お客様への返信の下書きを、送る前に店の資料と照らし合わせる方法は、返信の照合で扱っています。

    参照した公式資料

  • WordPressへの下書き登録がタイムアウトしたら:再送せずに登録済みかを照合して再開する

    WordPressへの下書き登録がタイムアウトしたら:再送せずに登録済みかを照合して再開する

    記事をスクリプトやAIエージェントでWordPressへ下書き登録していると、登録の途中でタイムアウトのエラーが出ることがあります。同じコマンドをもう一度流したくなりますが、WordPress側では下書きができていて、返事だけが届かなかったのかもしれません。そのまま送り直すと、同じ記事の下書きが2つできることがあります。

    このサイトの下書き登録処理を、WordPressの代わりに応答する疑似のサイトにつないで確かめました。同じスラッグの再実行は、記事も画像も増やさずにスキップしました。ただし、このスキップは「前回の下書きが検索で見つかる」ことを前提にしています。登録は済んだのにまだ検索に出ない状態で、送る前に残した記録を消して再実行すると、2件目の作成要求が送られました。記録が残っていれば、処理は送り直さずに止まりました。

    そこでこの記事では、タイムアウトを「失敗」ではなく「結果不明」として残し、再送する前に登録済みかを照合して再開する手順と、それを支える記録の持ち方、AIに投稿処理を作らせるときのテスト条件をまとめます。読み終えたら、自分の投稿処理が結果不明のときに止まるかを確かめ、タイムアウトのあとに送り直してよいかを判断できます。

    タイムアウトは「失敗」ではなく「結果不明」

    作成の要求を送ってタイムアウトしたとき、WordPress側で起きている可能性は2つあります。要求が届かず何も作られていないか、下書きは作られて応答だけが失われたかです。手元のエラーからは、どちらかを区別できません。

    そのため、投稿の結果は「作成」「スキップ」の2つではなく、「結果不明」を加えた3つで記録します。結果不明の記事は、WordPress側で見つかるかを照合するまで、次の行動を決めません。

    結果 意味 次にすること
    作成 応答で投稿IDが返った 投稿IDを記録し、管理画面で表示を確認する
    スキップ 同じ記事が既にある 上書きせずに次の記事へ進む
    結果不明 要求は送ったが応答がない 送り直さず、WordPress側と記録を照合する

    このサイトの下書き登録の流れ

    このサイトでは、記事のHTMLと画像をスクリプトでWordPressへ下書き登録しています。CodexやClaude Codeに作業を任せるときの共通指示にも、「通信の結果が分からない操作は、記録を残して盲目的に再送しない」と書いています。登録の流れは次のとおりです。

    1. 事前確認:通信せずに、記事のタイトル・スラッグ・抜粋・タグ・カテゴリ・画像の参照を検査する。

    2. 権限確認:投稿と画像アップロードの権限がある利用者かを確かめる。

    3. 同時実行の防止:登録処理が2つ同時に動かないよう、作業用の目印(ロック)を置く。目印が残っていたら、前回の処理が途中で止まった可能性があるので、自動では消さずに止まる。

    4. 記録とWordPressの照合:記事ごとに、前回の記録とWordPress側の投稿を照らし合わせる(下の表)。

    5. 送る前の記録:作成の要求を送る直前に「送信中」と記録し、要求を1回だけ送る。応答で投稿IDが返ったら「完了」と投稿IDを記録する。画像も、ファイルごとに同じ記録を持つ。

    6. 管理画面での確認:下書きのレイアウトと画像の表示を人が目で確かめてから公開する。

    再実行したときの判断は、記録とWordPress側の検索結果の組み合わせで決まります。

    前回の記録 WordPress側 処理
    なし 見つかる スキップ:上書きしない
    なし 見つからない 作成:「送信中」を記録してから送る
    送信中 見つかる 照合して完了:送り直さずに記録を直す
    送信中 見つからない 止める:管理画面で確認する
    完了 記録の投稿IDで照会 照合:投稿IDとスラッグが合わなければ止める

    4行目が、タイムアウトの直後に起きうる状態です。下書きが作られたのに、まだ検索に出ていない、あるいは検索の条件から外れている。このとき「見つからないから作る」と判断すると、2件目ができます。

    疑似のサイトで、応答を失ったあとの再実行を確かめる

    このサイトの登録処理を、通信しない疑似のWordPressにつなぎ、5つの場面を1回ずつ動かしました(2026年10月21日)。疑似のWordPressは、作成の要求を受けて下書きを作ったあとで応答だけを失う動きと、作った下書きを検索に出さない動きを切り替えられるようにしています。

    場面 再実行の結果 作成要求の回数
    通常どおり登録したあとに再実行 スキップ。下書き1件、画像のアップロード1回のまま 1回
    応答を失い、再実行のときは検索で見つかる 照合して完了。送り直さない 1回
    応答を失い、再実行のときもまだ検索に出ない 「前回の投稿結果が不明…管理画面で確認してください」で止まる 1回
    3つ目と同じ状態で、送る前の記録を消して再実行 見つからないので作成し、2件目の要求を送る 2回
    画像のアップロードで応答を失い、再実行 「前回の画像アップロード結果が不明です」で止まる 0回
    送る前の記録がない再実行は、まだ検索に出ない下書きを見落として2件目を作り、記録が送信中のまま残っている再実行は止まることを並べた図
    同じ状態からの再実行でも、送る前の記録があるかどうかで、2件目を作るか止まるかが分かれました。

    同じスラッグのスキップは、1つ目と2つ目の場面では二重投稿を防いでいます。けれども4つ目の場面のように、前回の下書きが検索で見つからなければ、スキップは働きません。3つ目と4つ目の違いは、送る前に残した「送信中」の記録だけです。記録が残っていたので、処理は「見つからない」を「まだ作られていない」と取り違えずに止まりました。

    運用で守ることは2つです。止まったら、WordPressの管理画面で下書きの一覧とメディアライブラリを開き、記録と照らしてから再開すること。そして、止まった記録を消して再実行しないことです。記録を消すのは、4つ目の場面を自分で作ることになります。

    手元で確かめるコード

    自分の投稿処理で同じ判断ができているかを考えるときは、次のPythonで状況を作ってみてください。WordPressの代わりにメモリ上の登録先を使い、通信もファイルの書き込みもしません。Python 3.10以降の標準機能だけで動きます。

    # WordPressの代わりに、メモリ上の登録先と作業記録で「応答だけを失う」状況を作る。
    # 通信もファイルの書き込みもしない。
    class Site:
        def __init__(self):
            self.posts = []          # 作られた下書き(同じスラッグでも別の投稿になる)
            self.hidden = set()      # 登録直後で、まだ検索に出ないスラッグ
    
        def create(self, slug, body, lose_response=False):
            self.posts.append((slug, body))
            if lose_response:
                raise TimeoutError("登録は済んだが応答が届かない")
    
        def find(self, slug, can_query=True):
            if not can_query:
                raise ConnectionError("照会できない")
            if slug in self.hidden:
                return None
            return next((p for p in self.posts if p[0] == slug), None)
    
    
    # 1. 無条件の再実行:タイムアウトしたら、もう一度送る
    site = Site()
    for _ in range(2):
        try:
            site.create("first-article", "本文", lose_response=True)
            break
        except TimeoutError:
            pass
    print(f"無条件の再実行: 下書き{len(site.posts)}件")
    assert len(site.posts) == 2
    
    
    # 2. 送る前に記録を残し、再実行では先に照合する
    def post_draft(site, journal, slug, body, lose_response=False, can_query=True):
        if journal.get(slug) == "送信中":
            try:
                found = site.find(slug, can_query)
            except ConnectionError:
                return "照会できないので停止"
            if found is None:
                return "見つからないので停止(管理画面で確認)"
            if found[1] != body:
                return "内容が違うので停止(管理画面で確認)"
            journal[slug] = "完了"
            return "登録済みを照合して完了"
        if site.find(slug, can_query) is not None:
            return "既にあるのでスキップ"
        journal[slug] = "送信中"
        try:
            site.create(slug, body, lose_response)
        except TimeoutError:
            return "結果不明(記録は送信中のまま)"
        journal[slug] = "完了"
        return "作成"
    
    
    site, journal = Site(), {}
    print("1回目: " + post_draft(site, journal, "first-article", "本文", lose_response=True))
    print("照会できない: " + post_draft(site, journal, "first-article", "本文", can_query=False))
    site.hidden.add("first-article")
    print("まだ検索に出ない: " + post_draft(site, journal, "first-article", "本文"))
    site.hidden.clear()
    print("検索に出た: " + post_draft(site, journal, "first-article", "本文"))
    print("もう一度実行: " + post_draft(site, journal, "first-article", "本文"))
    print(f"照合する方式: 下書き{len(site.posts)}件")
    assert len(site.posts) == 1 and journal["first-article"] == "完了"
    
    # 送信中のまま本文を直して再実行すると、照合で止まる
    site, journal = Site(), {}
    post_draft(site, journal, "second-article", "直す前の本文", lose_response=True)
    print("本文を直して再実行: " + post_draft(site, journal, "second-article", "直した本文"))
    assert len(site.posts) == 1
    
    
    # 3. 記録を持たずに、検索だけで判断すると
    site = Site()
    try:
        site.create("first-article", "本文", lose_response=True)
    except TimeoutError:
        pass
    site.hidden.add("first-article")
    if site.find("first-article") is None:
        site.create("first-article", "本文")
    print(f"検索だけで判断: 下書き{len(site.posts)}件")
    assert len(site.posts) == 2
    無条件の再実行: 下書き2件
    1回目: 結果不明(記録は送信中のまま)
    照会できない: 照会できないので停止
    まだ検索に出ない: 見つからないので停止(管理画面で確認)
    検索に出た: 登録済みを照合して完了
    もう一度実行: 既にあるのでスキップ
    照合する方式: 下書き1件
    本文を直して再実行: 内容が違うので停止(管理画面で確認)
    検索だけで判断: 下書き2件

    無条件に送り直す方式と、検索だけで判断する方式は、どちらも下書きが2件になりました。送る前に記録を残して照合する方式は、照会できないとき、まだ検索に出ないとき、送信中のまま本文を直したときに止まり、検索に出てから完了しました。止まる分岐では作成の要求を送らないので、結果不明から2件目へは進みません。

    記録で守れる範囲と、あわせて決めること

    送る前の記録は、照合の手がかりを再実行まで持ち越すためのものです。次の条件もあわせて決めておきます。

    • 記録の置き場所:処理が終わっても、PCを再起動しても残る場所に置きます。メモリ上の記録は、処理が終われば消えます。このサイトでは、記事ごとの記録を作業フォルダ内の復旧用の記録として保存しています。

    • 記事を見分ける識別子:通信が失敗したという理由で、スラッグや記事のIDを作り直さないことです。要求のたびに新しいIDを作ると、照合の手がかりがなくなります。内容を直して別の記事として出し直すときだけ、識別子を変えます。

    • 同時実行:照合と作成のあいだに別の処理が同じ記事を登録すると、照合は意味を失います。登録処理は1つずつ動かします。

    • 照会の遅れと検索の条件:作った直後の下書きが検索に出るまでの時間や、検索が対象にする投稿の状態(下書き・予約・非公開など)は、登録先の仕様と設定で変わります。見つからないことだけを理由に送り直しません。

    • 登録先の保証:登録先が「同じ要求を一度だけ処理する」仕組み(重複防止のキー)と照会を保証していれば、送る側の照合を軽くできます。保証がなければ、結果不明の記事は人の確認へ回します。

    監視や通知には、失敗の件数だけでなく、結果不明で止まった件数と、確認が必要な記事の名前を出しておくと、止まったことに気づけます。

    AIに投稿処理を作らせるときのテスト条件と依頼文

    CodexやClaude Codeに投稿処理を作らせるときは、次の3つをテストに入れるよう頼みます。

    1. 登録は済んだが応答だけを失う(再実行で、送り直さずに照合して完了する)。

    2. 再実行のときに照会できない、またはまだ検索に出ない(作成せずに止まる)。

    3. 送信中のまま、同じスラッグで内容が違う記事を再実行する(上書きせずに止まる)。

    依頼文には、たとえば次の一文を添えます。

    最初はWordPressを模擬した登録先で、通信せずに状態の移り変わりをテストしてください。作成の要求を送る前に「送信中」を記録し、結果が分からない記事を、照合せずに送り直す処理は作らないでください。上の3条件をテストに入れ、エラーが消えるまで繰り返す実装にはしないでください。

    AIの生成の要求を再試行することと、生成した記事をWordPressへ登録し直すことは、別の処理です。前者は失敗しても記事が増えませんが、後者は増えます。再試行の仕組みは、登録の側で個別に決めます。

    参考にした公式情報