ai-geek.love
← 実験ノート一覧へ

GEEK NOTE /

「シフト表って作れる?」から始まった、AIと作るレストランの勤務希望アプリ

AI実験ノート

「シフト表って作れる?」という相談から、レストランの研修用勤務希望アプリをAIと作りました。80人規模を想定し、厨房・接客の区分、社員番号、期間変更に対応。自分だけでの動作確認と不具合修正、管理者向け説明書の作成までを振り返ります。

「例えばアルバイトのシフト表とかつくれそうですか?」。今回の実験は、AIに投げかけたこの一言から具体的になりました。レストランのオープン前、約80人の研修を想定した勤務希望の受付。紙で扱っていた情報を、スタッフが入力し、管理者がスプレッドシートで確認できる形にしたい。そんな相談を、動作確認できるアプリと管理者向け説明書まで進めた記録です。

2026年9月24日時点では、自分だけがアクセスできる設定でのテスト段階です。80人での本番運用や同時アクセスの検証は、これからです。

最初に伝えたのは、現場の事情だった

人数は80人ぐらい。しかも、人によって出勤・退勤の時間が違います。厨房と接客に分かれ、研修中にはピザ、スパゲティ、仕込みといった担当もあります。担当を決めるのは会社側です。

もう一つ大事だったのは、使う期間でした。オープン後は別のアプリを使う予定なので、今回必要なのはオープン前の研修期間を支える仕組み。長く使う大きなシステムを最初から作る必要はありませんでした。

こうした事情を一つずつ伝えると、「どんな画面を作るか」より先に、「今回どこまで必要か」が整理されていきます。

まずは「希望を集める」ところに絞る

相談の途中で、やりたいことをこう言い直しました。

まずは簡単な厨房 接客 可能時間 休みを提出できるスプレッドシートでまとめられる形にしたい

ここで今回の軸が決まりました。スタッフが出勤できる日・時間や休み希望を提出し、管理者が内容を確認してシフトを決める流れです。ピザなどの細かな担当管理は今回の簡易版には入れず、会社側で登録する厨房・接客の区分を使うことにしました。

提出された勤務希望は、確定シフトとは別です。この区別は、入力する人にも管理する人にも伝わるようにしておく必要があります。

できた仕組みは、入力アプリと管理用シート

今回はGoogle Apps ScriptとGoogleスプレッドシートを組み合わせました。スタッフ向けにはブラウザで開く入力画面を用意し、管理者はスプレッドシートで名簿や提出内容を管理します。

社員番号は事前に配布する想定です。管理者が社員番号・氏名・厨房または接客の区分・受付可否を名簿に登録し、スタッフは社員番号と氏名を入力して自分の勤務希望へ進みます。

日ごとに「勤務可能」「休み希望」「未定」を選び、勤務可能なら開始・終了時刻を入力します。未入力の日と休み希望の日は分けて扱います。あとから自分の提出内容を修正するためのコードも設けました。社員番号と氏名の照合だけで厳密な本人確認ができるわけではないため、本番配布前には利用範囲と本人確認の運用を確認する必要があります。

管理用シートは「設定」「社員名簿」「勤務希望」「提出履歴」「使い方」に分けました。勤務希望では現在の提出内容を確認し、提出履歴では再提出を含む記録を追えるようにしています。

期間は、あとから変えられるように

最初に設定した対象期間は2026年10月13日から11月30日まで。ただ、研修の日程が変わることも考えて、開始日・終了日を設定シートから変更できる形にしました。

受付の締め切りや受付中・停止の切り替えも管理側で扱います。日付を変えるたびにプログラムを直すのではなく、普段使うシートで調整できることを重視しました。期間変更後は入力画面を開き直し、表示を確認する流れです。

保存できた。でも、開き直すと表示されない?

テストでは、保存済みの希望が入力画面に正しく戻らない不具合も見つかりました。原因は社員番号の扱いです。シート側では数値、アプリ側では文字列になっていて、同じ番号でも一致しない判定になっていました。

比較するときに社員番号を文字列としてそろえる修正を行い、アプリを更新。保存した勤務可能日と休み希望が再表示されること、再提出しても現在の希望が重複しないことを確認しました。提出履歴には再提出分が残ります。

画面ができて、送信ボタンが動けば終わりと思いがちですが、「閉じて、もう一度開く」「同じ内容を再提出する」まで試すと、見つかることがありました。AIと作ったものも、実際の使い方に沿って確かめる。この工程まで含めて、今回の実験です。

まず自分だけで試して、説明書まで作る

アプリを利用できる状態にする「デプロイ」では、ひとまずアクセス範囲を「自分のみ」にしました。スタッフへの配布は、入力と保存の動きや運用方法を確認した後の段階です。管理用シートとスタッフ用の入力画面も、配布先を分けて考えます。

最後に、初めて使う管理者向けの取扱説明書も作成しました。社員番号の登録、対象期間の変更、提出テスト、希望の確認、困ったときの対処をまとめた6ページのPDFです。

アプリを作るだけでなく、「次に触る人は、何から始めればいいか」を文書にしておく。短期間の研修用でも、ここまで用意すると運用の姿が具体的になります。

今回わかった、AIへの相談の進め方

今回のやり取りは、完成した仕様書を渡すところから始まったわけではありません。「80人ぐらい」「今は紙」「オープン前だけ」「担当は会社が決める」「社員番号を配る」。現場の条件を少しずつ言葉にしていきました。

似た相談をするなら、まずは「誰が使うか」「今どうしているか」「いつまで使うか」「人が決めることは何か」を伝えてみると、作るものを整理しやすくなりそうです。今回も、スタッフは希望を出し、管理者がシフトを決める、という役割が軸になりました。

これから確認したいのは、実際のスタッフの端末での入力、提出が集中したときの動作、修正コードをなくした場合の対応、未提出者の確認方法です。現時点で、シフトの自動作成や未提出者への自動通知は入れていません。

「シフト表って作れる?」という素朴な相談から、現場の条件を整理して、小さく作って、試して、説明書にするところまで進みました。次の検証では、少人数で試して、入力する側と管理する側の両方から使いやすさを確かめたいところです。

※この記事はAIとの対話と作業記録をもとに編集しています。実際の社員情報、管理用URL、修正用コードは掲載していません。