なぜ僕は飲食店向けAI SaaS「Kitchen Pilot」を作っているのか

飲食店の原価管理は、なぜ今でも紙の納品書、Excel、月末集計に頼っているのか。Kitchen Pilotを作り始めた理由と、今どこまで進んでいるのかを正直に書きます。

なぜ僕は飲食店向けAI SaaS「Kitchen Pilot」を作っているのか

飲食店の現場を見ていると、原価管理という仕事が、信じられないほど原始的なまま残っていることに気づく。

紙の納品書をファイルに挟む。

月末に棚卸しをする。

Excelに数字を打ち込む。

最後は電卓で原価率を出す。

この流れは、20年前からほとんど変わっていない。

POSレジはクラウド化した。

予約管理はネットに移った。

勤怠はスマホで打刻できるようになった。

それでも、「今月の食材費がいくらかかっているのか」をリアルタイムで把握できている飲食店は、驚くほど少ない。

僕は今、Kitchen Pilotという飲食店向けのAI SaaSを1人で作っている。

この記事では、なぜこのプロダクトを作り始めたのか、何を解決しようとしているのか、そして今どこまで進んでいるのかを、できるだけ正直に書いていく。

飲食店の原価管理は、なぜ20年間変わらなかったのか

紙の納品書、月末棚卸し、手計算Excel

多くの飲食店では、仕入れの納品書が今でも紙で届く。

それをファイリングし、月末にまとめてExcelへ打ち込み、棚卸しをして原価率を手計算する。

つまり、月末になるまで原価率がわからない。

この状態が、長年ずっと続いている。

「見えない原価」が経営を圧迫する

食材価格が上がっていても、月末まで気づけない。

仕入れ先の単価がじわじわ上がっていても、すぐには見えない。

このタイムラグが、薄利になりやすい飲食店の利益をさらに圧迫している。

しかも、このフローは「不便だけど一応回る」からこそ、なかなか変わらなかった。

ここに、ずっと違和感があった。

既存ツールでは解決しきれなかった理由

高機能すぎて現場が使わない

世の中には高機能な管理ツールもある。

でも、入力項目が多すぎたり、初期設定が重すぎたりして、現場で定着しないことが多い。

飲食店の現場では、高機能であることよりも、使い続けられることの方がずっと重要だ。

「壊れない設計」の方が大事

Kitchen Pilotで意識しているのは、派手さよりも「壊れにくさ」だ。

OCRには、どうしても誤読が起きる。

現場入力にも揺れが出る。

CSVやシートも、理想通りの形では来ないことが多い。

だからこそ、少し入力が荒くても、最終的に月次の数字が正しく着地するような堅牢な設計を重視している。

Kitchen Pilotが解こうとしている課題

LINEで写真を撮るだけの入力体験

Kitchen Pilotのコアは、できるだけ現場の負担を減らすことだ。

理想は、納品書をLINEで撮って送るだけ。

その先のOCR処理で、品目、数量、単価を自動で抽出し、手入力を減らしていく。

「現場で面倒だから使われない」を避けるために、最初の入力体験はとにかく軽くしたい。

棚卸式を正本とする原価計算

原価計算のベースは、使用高を期首棚卸、当月仕入、期末棚卸から出す考え方だ。

ただ仕入れ金額を足すだけでは、実際に使った食材費は見えない。

だからKitchen Pilotでは、棚卸式を正本にする設計を重視している。

さらに、前回と比べて食材価格が大きく上がっていれば通知するなど、単なる記録ではなく、気づける仕組みにしたいと考えている。

今、どこまでできているのか

OCR解析、Sheets同期、CSVプレビュー

現時点では、OCR解析、Google Sheetsへの同期、CSVインポートのプレビュー機能まで進んでいる。

少なくとも、現場データを受け取り、整えて、見える形にする流れはかなり具体化してきた。

7shiftsは申請中、Lightspeedはモック作成済み

外部連携については、7shiftsへの申請を行い、現在返答待ちの状態だ。

Lightspeedについては、データ形式をもとにテスト用のアダプタを作成している。

まだ本接続が完了しているわけではない。

でも、接続に向けた下準備はかなり進んでいる。

正直に書く。まだできていないこと

ここは、あえて正直に書いておきたい。

本番環境でのCSVインポートは、まだプレビュー中心だ。

外部APIとの本接続は未完了。

有料顧客もまだいない。

セキュリティ認証もこれから。

つまり、Kitchen Pilotはまだ実験中のプロダクトだ。

もう完成しているSaaSではない。

売れるかどうかも、これから検証していく段階にある。

でも、飲食店の原価管理が今のままでいいとは思っていない。

そして、AIはこの問題にかなり有効だと感じている。

なぜ1人で作るのか

AIエージェントというチーム

僕は、Codex、Gemini CLI、AntigravityのようなAIツールを、役割ごとに使い分けながら開発を進めている。

実装、秘書、統括のように役割を分けることで、1人でも前に進める体制を作っている。

もちろん、何でも自動でうまくいくわけではない。

止めるべき作業もある。

やってはいけない実装もある。

本番に出す前に確認しなければいけないことも多い。

それでも、役割分担を明確にするだけで、開発の進め方はかなり変わった。

Build in Publicという選択

人を雇う前に、まずは仕組みで回る開発体制を作りたい。

そのために、開発の過程や判断のログも、できるだけ外に出していこうと思っている。

完成品だけを見せるより、途中経過も含めて公開した方が、結果的にプロダクトの信頼につながると考えている。

失敗もある。

手戻りもある。

思ったより進まない日もある。

でも、それも含めて、1人でSaaSを作る現実だと思っている。

まとめ

Kitchen Pilotは、まだ完成したサービスではない。

でも、飲食店の原価管理が古い構造のまま残っていること、そしてそこにAIを使う余地が大きいことは、かなり確信している。

単なるAIっぽいツールではなく、本当に現場で使えるものを作りたい。

紙の納品書、月末の棚卸し、Excelの手入力。

この当たり前になっている負担を、少しずつでも減らしていきたい。

次の記事では、この開発をどうAIチームで回しているのかを書く予定だ。

1人開発で、AI秘書、統括、実装担当を分けると、開発の進め方がどう変わるのか。

そのあたりを、かなり具体的に書いていく。

この記事が少しでも参考になったら、スキやフォローをしてもらえると嬉しいです。

そして、もっと実務寄りの内容。

たとえば、実際に使っているプロンプト、AIチーム運営の考え方、判断ミスを減らすためのルールまで見たい方は、有料記事の方も読んでもらえると嬉しいです。

有料記事では、AIエージェントで1人SaaSを進めるための実践プロンプト集と、Kitchen Pilot開発の裏側をまとめる予定です。