AIを使えば本当に使える業務システムは作れるのか。
この問いに対する答えは以前であれば「ある程度のプログラミング知識がある人なら可能」というものでした。
しかしClaude Codeのような開発支援AIが登場したことでその前提は少しずつ変わり始めています。
今回WorXupでは、検証シリーズ第2弾としてClaude Codeを使ったPOSシステム開発に取り組みました。
※ちなみに第1弾は開発では無く不動産賃貸向けのマーケティング施策の事です。
テーマは飲食店向けの売上管理・オーダー管理・給与計算などを含む、実務寄りのPOSシステムです。
単なるサンプルアプリではなく、実際の店舗運営で使うことを想定しながら要件整理から開発、デプロイまでを一通り検証しました。
結論から言えばプログラミングの専門知識がなくても、Claude Codeを活用すればかなり実用に近いシステム開発まで進めることが可能です。
ただし、魔法のように一発で完成するわけではありません。
重要なのはAIに丸投げすることではなく、「何を作りたいのか」「どの業務をどう変えたいのか」を人間側が言語化することです。今回はその開発プロセスと、実際につまずいたポイント、かかった費用や期間まで含めてできるだけリアルにまとめます。
このAI時代の活用方法のヒントや、課題から抜け出せない状態からの脱却など少しでも役に立てれば幸いです。
そもそもなぜPOSシステムなのか
きっかけは知り合いの飲食店経営者との何気ない会話でした。
ビジネスの雑談をしているなかで出てきたのは、「今の業務にぴったり合うサービスが、意外と見つからない」という相談です。
既存のPOSシステムや店舗管理ツールは数多くあります。便利な機能も揃っていますしすぐに導入できる安心感もあります。一方で、実際の店舗運営には、その店ごとの細かなルールや慣習があるのです。
WorXupでもAIを活用した社内業務効率化の仕組みは常に模索し、構築を繰り返しています。
ただ、それはあくまで社内だからこそ、ある意味緩く柔軟性を用いながら進行できるものでもあります。
「実際に課題や悩みがある企業の解決が本当にできるのか」
「現場のルールや制約を踏まえたうえで本当に使える形に落とし込めるのか」
むしろそこまでできて初めて、AI活用ならびにWorXupの存在価値があるといえます。
今回のPOSシステム開発は、WorXupが掲げる「ビジネスを加速させる」ための実践的な検証として開始しました。
まずはPOSシステムの設計・要件整理から
まず最初に行ったのは「Claude.ai」を使った要件整理です。
いきなりClaude Codeに向かって「POSシステムを作って」と指示したわけではありません。
すでに知り合いの経営者からは「やりたいこと」「最低限はずせない部分」「任せてもいい部分」は整理、ヒアリングしているため、どの画面が必要か、どの機能を優先するか、管理画面はどのような構成にするか、店舗スタッフが触る画面と管理者が見る画面はどう分けるか、そうした内容をまず「Claude.ai」と会話しながら整理していきました。
※ちなみに今回WorXupで使用しているClaude CodeはProプラン（月額約20ドル）となります。
プロセスその１
まずClaude.aiに対して、作りたいシステムの概要を伝えました。
このような形で、最初はかなりラフに伝えています。
するとClaude.ai側から、必要な画面や機能、データ構造の候補が返ってきます。それを見ながら、不要なものを削り、必要なものを足していく。まさに壁打ちのような進め方です。
特に効果的だったのは、画面サンプルを作りながら要件を固めたことでした。
言葉だけで「テーブル管理が必要」と言っても、実際に何を管理するのかは人によってイメージが違います。
テーブル番号だけでいいのか。席数も必要なのか。ステータスは「空席」「利用中」「会計待ち」だけで足りるのか。注文履歴と連動させるのか。
画面として表示されると、こうした論点が一気に見えてきます。
今回の体感として文章だけで議論するよりもサンプル画面を触りながら話す方が10倍くらい速く要件が固まる感覚がありました。
今回の検証で最初に得た学びは、コードを書く前にまず“ガワ”を作ることの重要性です。
実際に相手にも共有して、触ってみてもらい、イメージをすり合わせながら着実に進行していけるのです。
プロセスその２
次にClaude.aiに相談しながら開発範囲をフェーズごとに分けました。
最初からすべての機能を作ろうとすると開発量が膨らみすぎます。また後から手直しなどが発生すると時間や手間も掛かってしまいます。
そこで以下のように段階を分けて進めることにしました。
Phase1
まずは「認証機能」と操作の基本となる「テーブル管理」を中心にしました。
ログイン、ユーザー管理、店舗管理、テーブル一覧など、システムの土台となる部分です。
Phase2
オーダー管理と会計機能を対象にしました。
注文入力、商品追加、数量変更、会計処理、売上登録など、POSシステムとして最も基本的な機能です。
Phase3
スタッフ管理と売上分析を対象にしました。
勤務時間、日別売上、月次売上、など店舗運営に踏み込んだ機能です。
Phase4
最後にマスタ管理とセキュリティを対象としました。
商品マスタ、スタッフマスタ、権限管理、店舗設定、データ保護など、運用を継続するために必要な部分です。
このようにフェーズを分けることで、「今作るべきもの」と「後で作るもの」が明確になりました。
まずはサンプル画面を作り、画面を見ながら業務の流れを考え、必要な機能をフェーズに分ける。
そうすることで、ひとつひとつのフェーズごとに集中しながら機能の過不足や連動などの確認、ブラッシュアップができますし、何よりも進行として安心感があります。
実際の開発：Claude Codeで何ができたのか
要件整理がある程度進んだところで、いよいよ実際の開発をClaude Codeを使って進めました。
Claude Codeはターミナル上で動く開発支援AIです。
通常のチャットAIと違い、プロジェクト内のファイルを読み取り、コードを修正し、必要に応じてコマンドを実行しながら開発を進めることができます。
これまでのAI活用では、ChatGPTやClaudeにコードを書いてもらい、それを人間がコピーしてファイルに貼り付けるような使い方が中心でした。しかしClaude Codeでは、開発環境の中でAIと会話しながら、実際のファイル修正まで進められます。
今回の技術スタックは、Next.js、Supabase、Vercelを中心に構成しました。
| サービス名 | フリガナ | 今回の用途 |
|---|---|---|
| Next.js | ネクストジェイエス | 画面やアプリケーションを作るためのフレームワーク |
| Supabase | スーパーベース | データベースや認証機能を扱うためのバックエンド |
| Vercel | ヴァーセル | 作成したアプリを公開するためのデプロイ環境 |
非エンジニアからするとここで一気に難しく感じるかもしれません。
ただ、実際にはこの技術選定もClaude.aiやClaude Codeと相談しながら進めることができます。
「店舗向けPOSシステムをWebアプリとして作りたい」
「ログイン機能とデータベースが必要」
「できるだけ低コストで公開したい」
「将来的に複数店舗対応もしたい」
このような条件を伝えると、候補となる技術構成を提案してくれます。
最終的には低コストで始めやすく情報も多い構成として、Next.js、Supabase、Vercelを選びました。
Claude Codeへの指示は、必ずしも完璧な仕様書のように書く必要はありませんでした。
このような指示でもClaude Codeはかなり意図を汲み取ってくれます。
一方で、店舗独自のルールについてはより細かく伝える必要があります。
例えば条件によってスタッフ時給を変える、インセンティブの設定、会計時に割引設定、などです。
こうした独自のルールはしっかりと定義されたものをClaude.aiに伝えて組み込んでいかないといけません。
AI開発というとどうしても自動化や効率化ばかりに目が行きますが、実際にはかなり対話的なプロセスでした。Claude Codeは、開発を完全に代行してくれる存在というより一緒に手を動かしてくれる開発パートナーに近い存在です。
実際につまずいたポイントと解決法
今回の検証ではすべてがスムーズに進んだわけではありません。
むしろ非エンジニアが初めて開発環境を触る場合、つまずくポイントはかなり多いと感じました。
ただし、重要なのは、つまずいたとしても前に進めることです。
今回特に印象に残ったのは、エラーメッセージをそのままClaude.aiに貼るだけで、多くの問題を解決できたことです。
専門用語が分からなくても、エラー文をコピーして「これはどういう意味ですか」「どうすれば直りますか」と聞けば、かなり具体的な解決手順を返してくれます。
実際につまずいた点をいくつか紹介します。
1. 開発コマンドを実行しようとしたら、Windowsのセキュリティ設定で止まった
（PowerShellの実行ポリシーエラー）
最初につまずいたのが、PowerShellの実行ポリシーです。
PowerShellとは、Windowsでコマンドを実行したり、開発環境の設定を行ったりするためのツールです。
通常のPC操作ではあまり意識しませんが、アプリ開発では必要なパッケージをインストールしたり、開発用サーバーを起動したりする場面で使うことがあります。
今回、Claude Codeを使うための環境構築や、Next.jsのプロジェクトを動かす過程で、PowerShell上でコマンドを実行する必要がありました。
ところがコマンドを実行しようとした際に、スクリプトの実行が許可されていないというエラーが表示されました。
これは、Windows側のセキュリティ設定によって、外部から取得したスクリプトや一部のコマンド実行が制限されていることが原因でした。プログラミングに慣れていないと、この時点で「何か壊してしまったのではないか」と不安になります。
ただ、エラーメッセージをClaude.aiに貼り付けると、WindowsのPowerShellには実行ポリシーという仕組みがあり、セキュリティ上の理由でスクリプト実行が制限される場合があることがわかりました。
最終的には実行ポリシーの設定を一時的に見直すことで解決しました。
もちろんセキュリティに関わる設定なので内容を理解せずに何でも実行するのは危険です。
特にインターネット上のコマンドをそのままコピーして実行するのは避けるべきです。
ただ、少なくとも「何が原因で止まっているのか」を把握できたことで、開発環境の構築を前に進めることができました。
2. データベースに入るための“合鍵”が見つからなかった
(Supabaseのキー名が変わっていた)
次につまずいたのが、SupabaseのAPIキーです。
Supabaseとは、アプリに必要なデータベースやログイン機能などを簡単に用意できるサービスです。
今回のPOSシステムではテーブル情報、商品情報、スタッフ情報、注文履歴、売上データなどを保存するために利用しました。
アプリを作るうえでは、画面だけが存在していても意味がありません。入力した注文内容や売上情報を保存し、後から呼び出せるようにする必要があります。そのため今回の開発ではSupabaseとの連携が必須でした。
ただ、Supabaseとアプリを接続するにはAPIキーと呼ばれる認証情報を設定する必要があります。
これは、アプリ側からSupabaseにアクセスするための“接続用の鍵”のようなものです。
ここで混乱したのが、キー名の違いです。
古い記事やサンプルコードでは、anon keyやservice_role keyといった表記が出てくることがあります。
一方で、現在のSupabaseではPublishable keyなどの新しいキー形式が案内されており、実際の管理画面に表示される名称と、ネット上の記事の表記が一致しない場面がありました。
今回も環境変数に設定するキー名で混乱しました。
Claude Codeが生成したコードとSupabase管理画面に表示されているキー名が微妙に違っていたため、接続エラーが発生しました。
しかし、これもエラー内容とSupabase管理画面の表示をClaude.aiに伝えることで、新しいキー形式に合わせて修正できました。
3. 新しいデータに付くはずの管理番号が発行されなかった
(UUIDの自動生成設定漏れ)
データベースまわりでは、UUIDの自動生成設定にもつまずきました。
UUIDとは、データを一意に識別するためのIDのようなものです。
例えば商品、スタッフ、注文、売上データなど、それぞれのレコードを区別するために使われます。
POSシステムでは、同じ商品名や同じスタッフ名が登録される可能性もあります。そのため、名前だけでデータを管理するのではなく、裏側では重複しないIDを持たせる必要があります。
今回、Supabase上の各テーブルでデータごとにUUIDを使って管理する設計にしていました。
ところがSupabaseでテーブルを作成し管理画面からレコードを追加しようとした際、IDが自動生成されずエラーになりました。
原因は、UUIDのデフォルト値設定が漏れていたことです。
つまり、本来であれば新しいデータを追加したタイミングで自動的にIDが発行されるはずが、その設定が入っていなかったため、データを登録できなかったということです。
アプリケーション側から登録する場合は問題なく見えても、管理画面から手動でデータを追加しようとするとエラーになる。このような細かい違いは、実際に触ってみないと分かりません。
Claude.aiにエラーを貼ると、UUIDカラムに自動生成の設定を入れる必要があると説明され、Supabaseの管理画面から設定を修正することで解決しました。
この経験から、データベース設計では、単にテーブルを作るだけでなく、IDの自動生成、初期値、入力必須項目、制約なども重要だと分かりました。
4. 作ったコードの保存先が想定と異なり送り先が迷子になった
（GitHubへのpushでブランチ名が違っていた)
GitHubへのpushでもつまずきました。
GitHubとは、作成したコードをインターネット上で管理・保存するためのサービスです。
開発したファイルをバックアップしたり、変更履歴を管理したり、Vercelなどの公開環境と連携したりするために使います。
今回の開発でも、ローカル環境で作成したPOSシステムのコードをGitHubにアップし、そこからVercelに連携してデプロイする流れを取りました。
ここで必要になるのが、pushという作業です。
pushとは、自分のPC上で作成・変更したコードを、GitHub上のリポジトリにアップロードする作業です。
簡単に言えば、「手元の作業内容をGitHubに反映する」操作です。
しかし、この段階でブランチ名の違いによるエラーが発生しました。
チュートリアルや記事ではmainブランチを前提にしていることが多いのですが、実際の環境ではmasterブランチになっていました。
ブランチとは、コードを管理するための作業ラインのようなものです。
現在はmainという名称が使われることが増えていますが、以前から使われている環境ではmasterという名称になっていることもあります。
そのため、記事やAIの指示通りにmainへpushしようとしても、実際のブランチ名がmasterだったため、うまく反映できませんでした。
これも、エラーメッセージをClaude.aiに貼ることで、現在のブランチ名を確認し、それに合わせてpushする方法を教えてもらいました。
GitHubに慣れている人にとっては基本的な内容かもしれませんが、初めて触る人にとっては、mainとmasterの違いだけでも十分につまずきます。
ただ、AIに聞けば、その場で意味と対処方法を説明してくれるため、独学よりもかなり進めやすいと感じました。
5. 本番公開先に必要な接続情報を設定できていなかった
（Vercelデプロイ時の環境変数設定）
ローカル環境で動いていたアプリをVercelにデプロイした際にも、エラーが発生しました。
Vercelとは、作成したWebアプリをインターネット上に公開するためのサービスです。
今回のPOSシステムも、開発中は自分のPC上で動かしていましたが、実際に店舗側で確認したり、外部からアクセスしたりするには、Web上に公開する必要があります。
その公開作業がデプロイです。
デプロイとは開発したアプリを本番環境に反映し、ブラウザからアクセスできる状態にすることです。
今回の場合、GitHubにアップしたコードをVercelと連携し、Webアプリとして公開しました。
ここで問題になったのが、環境変数の設定です。
環境変数とは、アプリの中で使う重要な設定情報をコードとは別に管理するための仕組みです。
例えばSupabaseのURLやAPIキーなどが該当します。
これらをコードの中に直接書いてしまうと、外部に見えてしまうリスクがあります。
そのため、通常は.env.localやVercelの管理画面に設定して、アプリ側から読み込む形にします。
今回、ローカル環境では.env.localにSupabaseのURLやキーを設定していたため、問題なく動いていました。
しかし、本番環境であるVercel側には同じ環境変数が設定されていなかったため、デプロイ後のアプリがSupabaseに接続できませんでした。
これも最初はなぜローカルでは動くのに本番では動かないのかが分かりませんでした。
Claude.aiに状況を伝えると、ローカル環境と本番環境では環境変数の管理場所が異なることがわかりました。
最終的にはVercelの管理画面から必要な環境変数を追加し、再デプロイすることで解決しました。
開発環境で動くことと本番環境で動くことはまた別物だということがわかりました。
6. 自分のPCでは動くのに、公開したら動かなかった
（localhostと本番URLの違い）
最後にlocalhostと本番URLの違いです。
localhostとは、自分のPC上でアプリを動かして確認するための開発用URLです。
一方、本番URLとはVercelなどにデプロイしたあと外部の人もアクセスできる公開用のURLです。
開発中はlocalhostで問題なく動いていても、本番URLに切り替えると動かないことがあります。
今回も、ローカル環境では動いていた機能が、本番環境では正しく動かない場面がありました。
理由は、localhostと本番URLでは、アプリが動いている場所や参照する設定が異なるためです。
例えばSupabaseの認証設定やログイン後のリダイレクトURLは、どのURLからアクセスするかによって設定が変わる場合があります。localhost用の設定しか入っていないと、本番URLでログインした際に正しく遷移できないことがあります。
また、開発中は自分のPC内だけで完結していた処理も、本番環境では外部サービスとの接続やセキュリティ設定の影響を受けます。
今回もログイン後の遷移や認証まわりで本番URLに合わせた設定が必要になりました。
当然のことではありますが、アプリ開発では「手元で動く」だけでは不十分で「公開した環境でも正しく動く」ことを確認する必要があります。
実際に開発にかかった費用・期間
今回のPOSシステム開発にかかった費用は以下のとおりです。
Claude.ai MAXプランで月額110ドル。
Claude Codeの利用費（従量課金）として現状追加課金無し
Supabaseは無料枠を利用。
Vercelも無料枠を利用。
現状ではなんと、もともとWorXupで利用していたClaude.aiの月額のみで構築が出来てしまいました。
もちろんこれは今回の検証範囲における費用です。
今後、開発する機能が増えたり、利用人数が増えたり、運用していくなかでデータ量が増えたりすれば、SupabaseやVercelの有料プランが必要になる可能性はあります。
それでも、既存のPOSシステムや業界特化型サービスを導入する場合と比較しても、自作システムであれば初期開発後のランニングコストはかなり抑えられる可能性があります。
開発期間としては、要件整理からデプロイまで約3週間でした。
この3週間の中には、Claude.aiでの要件整理、サンプル画面作成、先方とのすり合わせや確認、Excelでの機能整理、Claude Codeでの開発、Supabase設定、GitHub連携、Vercelデプロイ、エラー対応などが含まれています。
通常のシステム開発であれば、要件定義、見積もり、設計、開発、テスト、納品までにかなりの期間と費用がかかります。
もちろん今回の検証システムとプロの開発会社が納品する商用システムを単純比較することはできません。
ただ、業務改善の検証や小規模店舗向けの専用ツール作成という観点ではAI開発はかなり現実的な選択肢になってきていると改めて感じました。
既存サービスとの比較で見ると、メリットは大きく2つあります。
1つ目は、ランニングコストを抑えられることです。
月額数万円のサービスを使う代わりに、自社・自店舗向けに必要な機能だけを作れば、固定費をかなり抑えられます。
2つ目は、カスタマイズ自由度です。
既存サービスは完成度が高い一方で、どうしてもサービス側の仕様に業務を合わせる必要があります。一方、自作システムであれば、自分の店舗のルールに合わせて設計できます。
ただし、既存サービスよりもAI開発の方が優れている、という単純な話ではありません。
既存サービスには、すでに多くの利用者に使われてきた実績があり、安定性やサポート体制、継続的なアップデートといった強みがあります。導入してすぐに使える安心感は、既存サービスならではの大きなメリットです。
AI開発の強みは自分たちの業務に合わせて小さく作り、動かしながら改善できる点にあります。
必要な機能だけを優先して作り、不要な機能は持たない。使ってみて違和感があれば修正し、業務の変化に合わせて機能を追加していく。
このように、AI開発は完成されたサービスを置き換えるものではなく、既存サービスでは届きにくい細かな業務課題に対応するための新しい選択肢だと感じました。
総括
今回の検証を通じて強く感じたのは、プログラミング知識そのものよりも、「何を作りたいか」を言語化する力の方が重要だということです。
AIがコードを書けるようになったことで人間側に求められる役割は少し変わりました。
すべてのコードを自分で書く必要はありません。
しかし、業務の流れを理解し、必要な機能を整理し、優先順位を決め、独自ルールを説明する必要はあります。
つまり、AI時代のシステム開発では、エンジニアリングの入口が少し広がった一方で、業務理解や言語化力の重要性はむしろ高まっていると言えます。
AIは「作ってくれるもの」ではありません。一緒に考え、一緒に修正し、一緒に形にしていくパートナーです。
そして、つまずくことを恐れないことも大切です。
今回も、PowerShell、Supabase、GitHub、Vercel、環境変数、localhost、本番URLなど、多くのポイントでつまずきました。
しかし、そのたびにエラーメッセージをClaude.aiに貼り、原因を確認し、修正して前に進むことができました。
プログラミング知識がなくても、完全に止まることはありませんでした。
これは非常に大きな変化だと思います。
今回の検証はいきなり完成された商用POSシステムを作ることが目的ではありません。
重要なのはAIを使うことで、これまで実現できなかったことが実現できるのか、外注しなければ難しかった業務システム開発のハードルがどこまで下がるのかを確認することでした。
その意味では今回の検証は大きな手応えがありました。
実際に知り合いの経営者にも喜んでいただけて現場での活用も広がっているようです。
AIによって、非エンジニアでも自分たちの業務に合わせたシステムを作れる時代が近づいています。
もちろん、セキュリティや保守、決済連携、個人情報管理など、本格運用に向けては専門家の確認が必要な領域もあります。
それでも、最初の一歩として、自分たちの業務課題をAIと一緒にシステム化してみる価値は十分にあります。
「こんなものがあったら便利なのに」
「既存サービスでは少し合わない」
「毎月の固定費を抑えながら、自分たち用にカスタマイズしたい」
そう感じている業務があるなら、まずはClaude.aiで要件を整理し、サンプル画面を作ってみるところから始めてみるのもよいかもしれません。
コードを書く前に、業務を言葉にする。
その言葉を、AIと一緒に画面に変える。
そして、画面を見ながら、少しずつシステムに育てていく。
今回のPOSシステム開発は、AI時代の新しい業務改善の形を実感できる検証となりました。
