経理・発注・在庫・シフト・売上集計を、まるごと自動化。

背景と課題：店舗が増えるほど積み上がる手作業と、数字の不確かさ

複数の店舗を展開する飲食企業のお取り組みです。

売上日報・タイムカード・納品伝票・請求書・勤怠・給与振込・月次損益まで、Excelとクラウドストレージをベースにしながらほぼ手入力・手計算で回していました。

POSレジの売上のように一部は自動で取り込めても、それ以外の数字は人が一つひとつ転記する運用です。

店舗が増えるたびに同じ作業が掛け算で増え、月をまたぐたびに無視できない工数として積み上がっていました。

「いまのやり方を大きく変えずに、この手間だけをなくせないか」というのが出発点です。

手入力中心の運用には、二つの代償がありました。一つは時間のコストです。

店舗側のExcel入力・本社のダブルチェック・勤怠データの打ち直し・振込先の入力・月次損益の計算——いずれも人手でなければ進まない作業として毎月くり返されていました。

もう一つは、数字の信頼性です。手計算が連なるほど、ミスの発生源が特定しづらくなります。

経営判断のもとになる損益が「だいたい合っている」状態では、攻守どちらの判断にも踏み切りにくい。

放置すれば増えた工数がそのまま固定費化し、誤請求や不正の発見も遅れ続けることになります。

なぜHarry&か・解決の中身：現場の動きはそのまま、裏側をAIで自動化する

私たちはいきなり「システムを作りましょう」とは申し上げませんでした。

まず現地でヒアリングを行い、誰が・何を・どの媒体で・どこまで自動化できているかを分解しました。

「全部を新しいツールに置き換えること」ではなく「既存のExcelを残したまま裏側でAIを動かすこと」が本当に効くと判断し、ご提案しました。

スタッフが新しい操作を覚え直す設計は、現場の負担が大きく定着もしにくい。

だからこそ現場の動きはこれまで通りに保ち、見えないところで自動化を効かせる方針を最初に握ることを重視しました。

段階導入——小さく試して効果と安定性を確かめてから広げる——を前提にし、リスクを抑えながら進める形にしています。

中核にしたのは「スタッフはチャットグループに帳票の写真を投稿するだけ」という体験です。

投稿された画像はOCRで読み取り、大規模言語モデルが項目を構造化して、スプレッドシートの専用テーブルに自動で行追加されます。

新しいアプリのインストールも、操作の再学習も必要ありません。

そのうえで、いくつかの自動化を重ねました。

請求書と納品書の金額不一致を通知する異常値アラート、勤怠データの自動変換、複数店舗を合算した月次損益の自動生成、双方向で反映されるWeb管理画面です。

技術はOCR・大規模言語モデルによる構造化抽出・スプレッドシート連携・データベースを組み合わせています。

重複や処理中ロックの管理、受信画像の保管、双方向同期など「現場で事故を起こさないための地味な作り込み」まで含めてテストを伴いながら実装しました。

請求書や勤怠といった機微なデータを扱うため、保管場所・アクセス範囲・処理の各段階を設計時から明確にしています。

お客様のセキュリティ要件に合わせて、データの保管場所や連携先は調整可能です。

成果：現場を変えずに手作業が消え、経営判断に使える数字になった

最大の成果は、現場のオペレーションを一切変えずに手作業を大きく減らせたことです。

日報入力・ダブルチェック・勤怠の変換・振込の確認といった定型作業は自動化され、人が担うのは最終チェックに絞り込まれました。

月次の損益が自動で組み上がり、手入力に起因するばらつきが大きく減るため、数字をそのまま意思決定に使いやすくなります。

異常値アラートによって誤請求や不正の兆候を早く拾えるようになりました。

なお、定量データはお客様の機微情報のため本ページでは公開していません。

私たちがここで迷ったこと：全部を入れ替えるか、現場の仕組みをそのまま残すか

ヒアリングを終えた時点で、設計の方向が二つありました。

一つは「全部を新しいシステムに移す」設計、もう一つは「現場の操作は変えずに裏側だけをAIで動かす」設計です。

迷いを解いたのは「現場が慣れた動きを変えずに自動化を効かせることが、この案件の本当の成果だ」という判断でした。

スタッフが新しい操作を覚え直す必要が生まれると、定着までに時間がかかり自動化の効果が現場の負担でかき消されます。

その判断から段階導入の方針も出てきます。小さく試して確かめてから広げる——この進め方自体がリスクを最小化する設計の一部です。

内製ではなく外に出す価値：業務を解剖してから、必要なものだけを作る

私たちがまずやったのは、「誰が・何を・どの媒体で・どこまで手作業で行っているか」を分解する診断です。

この工程なしに実装を始めると「必要だと思っていたもの」を作ることになり、実際に効くものとズレが生じやすい。

業務を一度解体してみると、本当に自動化すべきボトルネックが想定とは違う場所にあることが少なくありません。

診断→設計→実装→段階検証→本展開という工程を伴走し、各フェーズで確認しながら進める体制は、社内だけで賄いにくい場合が多いのが現状です。

「作って終わり」ではなく確かめながら広げる進め方そのものも、外部と組む価値の一つです。

どんな会社に向く事例か：手作業が毎月くり返されていて、現場の動きはそのままにしたい

この事例が当てはまりやすいのは、複数の店舗や拠点を展開していて、日報・請求書・勤怠・発注の集計が毎月手作業で積み上がっている状況です。

現場のスタッフが使い慣れたExcelやチャットのやり取りを大きく変えたくない——という前提がある場合に特に向きます。

このパターンは店舗型の飲食業にとどまらず、卸売や製造など紙やExcelで日々の数字を回している現場にも同じ設計が応用できます。

逆に、業務フロー自体がまだ固まっていない段階や、自動化したい業務量がほとんどない場合には、この規模の実装は先になることがほとんどです。

「今すぐ全部を作る」ではなく「小さく試してから広げる」進め方に納得できるかも、向き不向きを判断する基準の一つです。

まずヒアリングから始めて、御社の業務で本当に効くかを一緒に確かめます。