ChatGPTに渡すシフト条件の作り方｜スタッフIDと入力データのテンプレート

ChatGPTにシフトを頼む準備では、スタッフ情報、勤務可否、必要人数、固定条件を別にすると訂正箇所が分かりやすくなります。すべてを一つの文章へ詰めると、どの条件が新しいか判断しにくくなります。

まず一期間の表を作り、更新日時と対象期間を付けます。次月はそのコピーを使えますが、前月の希望や退職者をそのまま残さないようにしてください。入力表の使い回しと、入力内容の確認省略は別です。

最初から完璧な条件一覧を作ろうとすると、準備だけで疲れてしまいます。まず前月の表を開き、手直しした場所を三つ思い出してみてください。「この日は新人だけになる」「この人は授業で夕方まで来られない」「閉店の鍵を扱える人がいない」。その理由が、入力表へ移すべき条件の候補です。

ただし、店長が覚えている条件が今も同じとは限りません。授業の時間割や担当可能な業務は変わります。「前月はこうだった」を今月の確定条件として扱わず、変わりやすい項目から確認します。入力表には、誰が、いつ確認した情報かを短く残しておくと、古い条件を見つけやすくなります。

本人への質問も一度に広げすぎない方が答えやすくなります。「来月いつ入れる？」ではなく、「10月8日は17〜20時の勤務が可能ですか」「閉店までの勤務が難しければ何時までですか」と、作成に必要な項目へ分けます。回答をもらうための表なので、入力する側が迷う言葉は早めに直しておきましょう。

外部サービスへ渡す入力例にはS001のようなIDを使います。氏名との対応表は店内の管理場所へ分け、連絡先や詳細な欠勤理由を勤務可否表へ混ぜません。これは情報を減らすための運用例で、IDに置き換えるだけで完全に匿名になるという意味ではありません。

珍しい役職や少人数の勤務条件から本人が推測できることもあります。実データを外部AIへ送る前に、店や会社が利用を認めているサービスと入力範囲を確認してください。試す段階はこの記事の架空データだけでも進められます。

空欄を勤務可として埋めると、まだ確認していない人が配置されます。未回答を明示し、時刻が分からない場合も推測で埋めないでください。この表は入力準備用で、ShiftEngineの取込テンプレートではありません。

一日の一部だけ可の場合は時間帯を限定します。17〜20時が可だからといって、15時からも可とは扱いません。複数の時間帯がある人は別行にし、区間が重なっていないか確認します。

勤務できる日と、できれば働きたい日は同じではありません。たとえば月曜も火曜も勤務可能でも、本人は火曜を希望しているかもしれません。可否の列に「できれば火曜」とだけ書くと、月曜が不可なのか、優先度が低いだけなのか分からなくなります。

まず勤務の可否を決め、そのうえで希望の優先度を別に残します。本人へ確認できていないなら、「月曜は勤務可か未確認」として待ちます。AIへ曖昧さの解釈を任せるより、店側で意味をそろえてから渡す方が、あとで説明が食い違いにくくなります。

同じように「週3回くらい」も、最大3回なのか、3回働きたいのかで違います。「2回でもよいか」「4回は避けたいか」など、必要な範囲だけ聞き直します。全員に長いアンケートを送る必要はありません。実際に案が変わる条件だけを確認することで、スタッフ側の負担も抑えられます。

一日4人と書くと、開店から閉店まで常に4人必要なのか、延べ4人が出勤すればよいのかが伝わりません。たとえば開店直後は2人、夕方は3人、閉店時は2人という店なら、その時間帯を分けて入力します。細かくする目的は表を複雑にすることではなく、人が足りない時間を見つけることです。

区切り方は、勤務が入れ替わる時間や、必要人数が変わる時間を基準にします。毎分の表から始める必要はありません。レジと売場を兼ねられるのか、それぞれ専任が必要かも確認します。同じ人をレジで一人、売場で一人と数えると、実際には二人いないのに条件を満たしたように見えてしまいます。

必要人数の表には、その数字を決めた担当者や根拠のメモも役立ちます。「前年のセールと同じ」「通常日は店長確認済み」といった短い記録で構いません。AIに人数そのものを推測させる前に、店として何人必要と考えているかを決めておくと、生成後の議論がぶれにくくなります。

「閉店できる人が必要」を文章の末尾へ埋めず、条件番号を付けて残します。条件に違反した場合も、AIに番号で報告させると元の入力と照合できます。

必須条件と希望条件を分けます。希望条件のために必須条件を破らせないこと、不足は不足のまま出すことを依頼します。以下は例であり、実店舗の契約・労務条件を網羅していません。

準備の段階でいきなり完成シフトを求めず、不明点一覧を出させます。例のS003は未回答なので、勤務可否が不明です。入力が足りないまま完成形の表が出ても、確認が終わったわけではありません。

入力表が四つそろったら、全員分を一度に渡す前にS001だけを追ってみます。スタッフ表に存在し、可否表に対象日の情報があり、必要な担当業務を行えるか。IDが表ごとに違っていないか。この一往復で、名前の表記揺れやコピー漏れを見つけられます。

次に一日分を選びます。必要人数が2人で、勤務可と確認できた人が2人、うち閉店対応可能者が1人なら、少なくともその日を考える材料はあります。勤務可の人が一人しかいないなら、案を作る前から不足です。入力チェックでは、空欄を探すだけでなく、条件を組み合わせたときに無理がないかも見ます。

最後に、意図的に誤りを一つ入れたコピーで試します。存在しないIDや期間外の日付を加え、確認の手順で見つけられるかを確かめる方法です。本番の表へ試験行を混ぜないよう、必ず別のコピーで行います。正しいデータだけを見せるより、異常に気づけるかを試した方が、点検方法の弱いところが分かります。

条件が矛盾していても、どちらを優先するか店長がまだ決めていないことがあります。「S001の8日は確定済み」という表と、「8日は不可」という新しい回答が同時にあれば、勝手に古い方を消すのではなく、訂正の受付と配置への反映が終わっているかを確認します。

確認待ち一覧には、対象日、スタッフID、食い違っている表、聞きたいこと、担当者を書きます。日付だけの「8日要確認」では、一週間後に何を聞く予定だったか思い出せません。「8日17〜20時の確定枠について、不可の回答が正式な変更希望か本人へ確認」のように、次の行動が分かる一文にします。

回答をもらったら、確認待ちの行だけ完了にして終わりにせず、現行の入力表へ反映します。「本人へ聞いた」という記録と、AIへ渡す値が変わったことは別です。反映した表の版を記録し、必要なら作成中のシフトにも同じ変更が入っているかを見ます。

一人の回答が残っていても、他の人の確認まで止める必要はありません。ただし、未確定の人が配置に関係する枠は保留と分かるようにします。全体を完成扱いにしないまま、確認できた部分から準備を進める。この分け方ができると、締切前にまとめて全員へ聞き直す負担を減らせます。

AIに渡す段階では、何が確定していて、何がまだ確認待ちかを明示します。未確認の条件を除いた結果、人が足りなければ不足のまま出してもらいます。空欄を埋めることより、誰に何を聞けば先へ進むかが分かることを、入力準備の完了条件にしてください。

スタッフIDや担当可能な業務は、変更がなければ次月も使える情報です。一方、希望休、勤務可能時間、特定日の必要人数は、毎回確認する情報です。同じファイルを複製するだけだと、前月の希望が自然に今月へ残ってしまいます。使い回す欄と消して回収する欄を、作業手順の中で分けておきます。

月を替えるときは、最初に対象期間、在籍者、業務担当の変更を確認します。その後で新しい希望を取り込み、未回答者を一覧にします。古い希望が入ったセルを空白にするだけでなく、「未回収」という状態へ戻すと、回収が終わった人と区別できます。前月の原本は、変更せず保管してください。

副店長へ引き継ぐときは、四つの表だけでなく、更新する順番と確認待ちの一覧を渡します。どのファイルが最新か、誰が条件を変更できるかも一行で書いておきましょう。AIへ渡しやすい入力を作ることは、結果として人へ仕事を渡しやすくすることにもつながります。

M001の内容が訂正されたら、元のメッセージと受付時刻を手元で確認し、現行の勤務可否表へ反映します。原文の全履歴をAIに渡す必要はありません。入力した現行版と、修正対象の行を明示します。

準備に時間がかかる原因が、毎回違う書き方のLINEを読み直すことなら、回収段階で日付・可否・時刻をそろえる方法を検討します。ShiftEngineの提出リンクをLINEで共有する運用は、LINEのチャット履歴を自動で読み込む機能とは異なります。