Pythonは分かる、Webは素人。それでも“完全無料”でAIを使ってWebサービスを作って公開してみた

自己紹介

使ったことある言語は Python / C / C++ / VBA あたりです。
ラズパイなどの組み込みとか、PC1台の中で完結するソフト（スタンドアロン系）は作ったことがあります。

が、Web系はほぼ未経験です。
（「HTML？あぁ、あのカギカッコがいっぱいあるやつね。JavaScript？Javaの親戚でしょ？」くらいの認識）

Webサービスは昔からやってみたかったんですよね。 でもやってこなかった。
「ワリカ」みたいなサービスを使って、

• これ、便利すぎない？
• 自分もこういうの作ってみたい

となって、ようやく重い腰を上げました。

ワリカ　インストール不要で割り勘計算してくれるアプリ
https://walica.jp/

目的

今回の目的はこれです。

• 1円も払わん。 AI を使って、サーバー代も開発費も「完全無料」で Web サービスを召喚する。
• 公開後もお金は払いたくないので(ケチ)、無料枠の範囲で完結させる。
• AIをこき使うが、魂は売らない。
  AIに丸投げして「できました！」で終わらせず、中身を読んで「ヘェ〜、君こういう仕組みなのね」と上から目線で学ぶ。

アプリのコンセプト

何を解決する？

複数人で集まるとき、あるあるだと思うんですが……

• 「どこ集合？」で決まらない
• 気づいたら毎回同じ場所
• 幹事は面倒すぎてやりたくない

これを、できるだけラクにしたい。

ざっくり何をするアプリ？

参加者がそれぞれ 最寄り駅 を入力すると、

1. みんながなるべく公平になる 集合駅（中間地点） を提案
2. その周辺の お店候補 も出す
3. 最後に 決定して共有 できる

…という感じの Web サービスを作ります。

「割り勘」じゃなくて「場所決め」版、みたいなイメージです。

利用者目線の流れ

このサービスは難しい操作は不要で、スマホやPCで次のように進みます。

短く言うと：

• 幹事が「部屋を作る」→ 招待URLを送る
• 参加者は「自分の駅を入力」するだけ
• システムが候補を提示 → 幹事が決定 → みんなに共有

とてもシンプルな操作で、初めての人でも使えるようなシステムを目指しました。

まずは作ったアプリを紹介

下記がアプリのリンクになります。無料ですので是非お試しください。

もし問題があったら、トップページのgoogleフォームで教えて下さると嬉しいです。

せっかくなので、色んな人に使ってもらえるよう、宣伝目的でXアカウントも作りました。

主な機能

• 中間地点の自動計算: 全員の最寄り駅から、公平な集合場所（中間地点）を算出します。
• 好みを反映する「ジャンル投票」: その日の気分（イタリアン、焼肉など）を投票し、結果をお店選びに反映。
• 店舗情報の自動提案: 集合駅周辺の飲食店情報を取得し、皆で投票したジャンルの結果に合わせて候補を表示。
• リアルタイム共有: 参加者の入力状況や最終的な決定内容を、全員の画面へ即座に反映します。

"AIにおまかせ"ってあるけどAI使ってないだろって？「これも広義に考えればAI」ってAIが言ってました。

操作の流れ

1. ルーム作成・招待: 幹事がニックネームと駅を入力してルームを作成し、URLをメンバーに共有します。
   

2. 参加・投票: メンバーはURLから入り、自分の駅を入力。「今日の気分」を最大3つまで選んで投票します。この投票結果は集合場所の選定に使用されます。
   
   

3. 候補の確認: 全員の入力が完了すると、最適な中間地点とお店の候補が自動で提案されます。
   

4. 最終決定: 候補の中から集合する駅を選んで決定！全員の画面に最終的な集合場所が表示されます。
   

では、以降はweb素人の私向けに、学びとして残します。

そもそもwebサービスってどう動くのか？

Webサービスは、私たちが使っているブラウザ（スマホやPC）と、インターネットの向こう側にある「サーバー」がキャッチボールをすることで動いています。
イメージしやすいように、このQiitaで記事を読むときの流れを例に見てみましょう。

1. リクエスト (お願い): ブラウザがサーバーに対して「この記事を見せて！」とリクエストを送ります。
2. 処理 (データ探し): Qiitaのサーバーが、膨大な記事が保管されているデータベースの中から、指定された記事を探し出します。
3. レスポンス (お返事): サーバーが「はい、この記事ですよ」とデータを送り返すと、ブラウザがそれを解釈して、私たちがいつも見ているきれいな画面を描き出します。

この「お願い」と「お返事」が爆速で繰り返されることで、私たちはアプリを操作できているのです。

みんなで「一つの状態」を共有する仕組み

今回のアプリのような、複数人でリアルタイムに情報を共有するサービスでは、もう少し踏み込んだ仕組みが動いています。
組み込み用途のスタンドアロン開発と一番違うのは、複数人が同時に、別々の場所から操作する点です。これを支えるのが「サーバー」と「データベース」です。

誰かが駅を入力すると、その情報は「サーバー」を経由して「記憶（DB）」に書き込まれます。他の人のブラウザは、定期的にサーバーへ「最新の状態はある？」と聞きに行くことで、全員の画面が同期される仕組みです。

サーバーとデータベース、何を選べばいいの？

上記のWebサービスを理解して、さあ作ろうとなった時、一番最初にぶつかった壁が「そもそも作ったプログラムをどこに置けば世界中の人が見れるようになるのか？」という問題でした。

サーバー：AWSやAzure…ではなく「PaaS」という魔法

最初は「サーバーといえば、AWSやAzureを使いこなさないといけないのかな？」と思っていました。
でも、素人が手を出すには設定が難しそうだし、「設定ミスによる高額請求」という即死呪文を唱えてくる恐ろしい存在らしいのでやめました。

そんな時に見つけたのが、Vercel や Netlify といった 「PaaS（Platform as a Service）」 と呼ばれるサービスです。

これらを一言で言うと、「作ったプログラムをアップロードするだけで、ものすごく簡単かつ高速に世界中に公開してくれるサービス」 です。

• サーバーの複雑な設定（OSがどうとか、セキュリティがどうとか）を全部お任せできる
• GitHubにコードを保存するだけで、自動でWebサイトに反映（デプロイ）してくれる
• 何より、趣味レベルで使う分には 完全無料 で使える

「これこそ初心者(私)が求めていたものだ！」と思い、今回はこの仕組みを採用することにしました。

データベース：「状態」をどこに保存するか？

もう一つ必要だったのが、ユーザーが入力した情報を保存しておく データベース（DB） です。
今回のアプリで言うと、「誰がどの駅を入力したか」や「今どのフェーズにいるか」といった情報を、参加者全員で共有するためにネット上に保存しておく必要があります。

これも調べた結果、Supabase というサービスを使わせていただくことになりました。

• 高機能なデータベースを、数クリックで作成できる
• これも小規模な利用なら無料で使い続けられる

ドメイン：アプリの「住所」を固定する

さらにこだわったのが、アプリのURL（ドメイン）です。
VercelやNetlifyを使うと、通常は my-app.vercel.app のようなURLになります。これでも動くのですが、今回は思い切って 「お名前.com」 で独自のドメイン（basyogime.com）を取得しました。

わざわざドメインを取ったのは大きなメリットがあるからです。

• URLが変わらない: もし将来、サーバーを別の場所へ引っ越したとしても、ドメインさえ持っていればユーザーがアクセスするURLを変えずに済みます。「住所（ドメイン）はそのままに、家（サーバー）だけ建て替える」ことができるのです。
• 信頼感: やっぱり .com や .jp のドメインだと、「ちゃんとしたサービス感」が出ますよね。

ちなみに、これもキャンペーンなどを活用すれば 1年目はほぼ無料（1円とか） で取得できることが多いです。2年目からは更新料がかかりますが、まずは1年、自分のサービスに看板を掲げてみることにしました。

これで、「1円もかけずに、Webサービスを世界に公開する」 という、魔法のような環境を整えることができました。
(当然ですが、もしたくさんの人に使ってもらえるようになった場合、課金することになります)

地図や駅、店舗情報をどうやって無料で集める？

このアプリは「場所を決める」ためのサービスなので、地図・駅・お店の3つの情報が欠かせません。これらは、外部のサービスが提供している API（プログラム同士が会話してデータをもらう仕組み）を活用して取得しています。
今回、完全無料にこだわって選んだ3つの強力なサポーターを紹介します。

1. HeartRails Express API（駅情報の取得）

「参加者の最寄り駅」を地図上の座標（緯度・経度）に変換したり、路線の情報を取得したりするために使っています。

• 役割: 駅名から場所（位置情報）を特定する
• なぜこれ？: 日本全国の駅や路線のデータが非常に充実しており、しかも無料で使いやすいためです。中間地点を計算するには「駅がどこにあるか」の数値データが必要なので、このAPIが心臓部になっています。
• HeartRails Express API 公式サイト

2. ホットペッパーグルメAPI（店舗情報の取得）

集合駅が決まった後、その周辺にある「いい感じのお店」を探すために使っています。

• 役割: お店（飲食店）の名前、写真、予算、ジャンルなどの情報を取得する
• なぜこれ？: リクルートが提供している膨大な店舗データを利用でき、APIの仕様も分かりやすいためです。「飲み放題はあるか？」「おしゃれな内装か？」といった細かい条件で絞り込むこともできます。
• ホットペッパーグルメAPI 公式サイト

3. OpenStreetMap & Leaflet（地図の表示）

アプリ上で地図を表示し、ピンを立てるために使っています。

• 役割: 背景の地図タイル（画像）を表示し、駅やメンバーの場所を可視化する
• なぜこれ？: Google Mapsも有名ですが、無料で使い続けるには制限やクレジットカード登録が必要です。一方で、OpenStreetMap(OSM) は「地図界のWikipedia」のようなプロジェクトで、誰でも自由に利用できます。
• Leaflet: このOSMの地図をWebサイト上でスムーズに動かす（拡大・縮小、マーカー設置など）ための軽量なライブラリです。

この3つを組み合わせることで、「駅を探す → 中間地点を計算する → お店を出す → 地図で見せる」という一連の流れを、すべて無料枠の範囲で実現することができました。

使用した言語

ぶっちゃけ、この辺はAIに丸投げして選んでもらいました。Web系はやたら選択肢が多くて訳分からなくなりますが、自分なりに「スタンドアロン開発」の知識に置き換えて理解しました。

• HTML / CSS

  • 組み込み視点: 「GUIの画面レイアウト」と「各パーツの見た目設定」です。
  • 解説: ボタンをどこに置くかをHTMLで書き、そのボタンを何色にして、角をどれくらい丸めるかをCSSで指定します。Webブラウザという「表示機」に出力するための共通規格、という感じです。

• JavaScript (JS)

  • 組み込み/Python視点: 「ブラウザという『仮想マシン』上で動く、共通標準言語」です。
  • 解説: 画面に動きをつけるためのスクリプト言語です。Pythonのように型を決めずに書ける（動的型付け）のが特徴です。Webサイトで何らかの処理（計算や通信）をさせるなら、最終的には必ずこのJSが動くことになります。

• TypeScript

  • Python/C言語視点: 「C/C++みたいにコンパイラが型チェックをしてくれる、進化したJavaScript」です。
  • 解説: Webの標準言語はJavaScriptですが、これはPythonのように型がゆるく、実行して初めてエラーに気づくことが多いらしいです(pythonと同じですね)。TypeScriptを使うと、ビルド（コンパイル）段階で「int型にstr型を入れようとしてるよ！」と教えてくれます。

• Next.js

  • 組み込み視点: 「メインループ、画面遷移（ルーティング）、周辺制御が全部入った高機能SDK」です。
  • 解説: 本来バラバラだったHTML/CSS/JSを一つにまとめて、関数を呼び出す感覚で画面のパーツ（コンポーネント）を作れます。「このボタンを押したらこの画面へ飛ぶ」といった制御も、Next.jsがよしなにやってくれます。

• Tailwind CSS

  • Python(Tkinter)視点: 「ボタンの引数に直接 color="blue" と書くような、直感的なデザインツール」です。
  • 解説: 本来はCSSという別ファイルに「ボタンの設定...」と長々書く必要がありますが、これはHTMLの中に「青い！太い！横長！」といった合言葉（クラス）を直接書くだけで完了します。設定ファイルをいじるより、コード上でパラメータを微調整する感覚に近いです。

• Node.js

  • Python視点: まさに python.exe（実行環境）そのものです。
  • 解説: ブラウザ以外でもプログラムを動かすためのエンジンです。これをインストールしておくことで、自分のPC上で「Webサービスの開発環境」を動かすことができます。

使用したAIサービス

「完全無料で、素人が最短で形にする」ために、強力なツールたちに助けてもらいました。

• VSCode: 私のメイン武器。
• GitHub Copilot: 1ヶ月の無料体験を使います。
• ChatGPT Plus: 1ヶ月の無料体験を使います。ChatGPT Codexが付いてきて、vscodeの拡張機能でAIが使えます。
• Antigravity: 無料枠を使います。Claude Opus4.5など最強AI使えます。

ケチすぎる...w 自分で書いてて引きました

アプリを作成していく

アプリのシステム仕様

このサービスは、大きく分けて4つの「場面（ステップ）」で進むように設計しました。
「誰が何をするのか？」をイメージしながら、Web素人の私が考えた設計図を紹介します。

Step 1. ルーム作成

まずは、集まりの「場所（ルーム）」をネット上に作ることから始まります。

• 幹事さんが「新しいルームを作る」ボタンをポチッと押す。
• 自分の名前（ニックネーム）や最寄り駅を入力。
• ユニークな「ルームID」と「招待用URL」が発行されます。
• ポイント: このURLをLINEなどで友達に送るだけで、準備完了です！

Step 2. メンバーの入力と「今日の気分」投票

URLを受け取った参加者が、それぞれの画面から情報を入力します。

• 招待URLから入ると、そのルーム専用の画面が開きます。
• 自分の名前と最寄り駅を入力して送信。
• ポイント: 登録後、「今日の気分（食べたいジャンルの希望）」を投票できます。「居酒屋」「イタリアン」「焼肉」など最大3つまで選べて、リアルタイムでみんなの好みが集計されます。
• ポイント: DB（Supabase）に情報が保存されるので、全員がリアルタイムで「今は誰が登録済みか」「誰が投票を終えたか」を確認できるようにしました。全員揃ったことを確認して、次のステップへ。

Step 3. 候補の提案（システムが中間地点を計算）

ここがこのアプリの売り部分になりますね。

• 全員の駅が揃ったら、ボタン一つで「みんなの不公平が少ない中間地点（集合駅）」を計算。
• ここがポイント: 先ほどみんなが投票した「今日の気分」の集計結果をもとに、最も人気の高いジャンルのお店を優先的に探し出します。
• ポイント: 計算アルゴリズムと店舗APIを連携させ、「どこで何を食べるか」という悩みを一気に解消します。

Step 4. 最終決定と共有

最後は、出された候補の中から決定します。

• 幹事さんが「この駅のこのお店にしよう！」と決めて決定ボタンを押す。
• すると、全員の画面が「ここが今日の集合場所です！」という最終結果画面に切り替わります。

AI駆動開発

ここからは、実際にどうやって開発を進めたかについてお話しします。
結論から言うと、webエンジニアとしての知識がゼロでも、AIがいればWebサービスは(とりあえずは)作れるということを身をもって体感しました。

コードを1文字も書かずに完成

驚くべきことに、今回の開発プロセスにおいて、私は(マジで)一度も自分自身でコードを触っていません。 全てAIに対する「自然言語での指示」だけで作り上げました。
当初はJavaScriptなどの読み方さえ一切分からず、「この記号はどういう意味？」という状態でしたが、AIに作りたい機能を言葉で伝えるだけで、特に問題なく開発が進んでいきました。
正直、AIが優秀過ぎて、苦労した記憶がほとんどないです。苦労したのは何のサービスでサーバー立てるとか、何のAPIつかうとか、仕様策定(調べもの)のところでした。

ブラウザで確認しながらの改善ループ

開発の進め方は、常に localhost でサーバーを立てて、実際のUIや処理の具合をブラウザで確認しながら進めました。
画面を動かしてみて「このボタンはもう少し大きく」「ここでエラーが出たから直して」と指示を出し、その場で改善していくスタイルです。自分の目で挙動を確認しながら対話形式でブラッシュアップしていく感覚は、プログラミングというより、優秀なエンジニアにデザインを依頼しているような感覚でした。

状況に応じたAIモデルの使い分け

複数のAIを適材適所で使い分けました。
利用コストが低い GPT-5-miniなどはでは、やはり複雑なバグの解消や、一度に多くのファイルを修正するような高度な機能の実装となると、難しさを感じる場面がありました。

そんな難所にぶつかった時は、上位モデルである GPT-5.2 や Claude Opus 4.5 を使うことで解決していきました。

• GPT-5-mini: 簡単なUIの調整
• GPT-5.2 / Claude Opus 4.5: 複雑なアルゴリズムの構築や、迷宮入りしそうなバグのデバッグ

難易度に合わせてAIを使い分けて開発していきました。

気を付けたこと

初めてWebアプリを作る上で、特に「セキュリティ」や「プライバシー」は素人ながらに一番怖い部分でした。AIと相談しながら、以下の3点は特に徹底して作り込みました。

1. APIキーを「隠す」仕組み

今回、ホットペッパーや駅情報のAPIを使っていますが、これらには自分専用の「APIキー（パスワードのようなもの）」が必要です。これが他人にバレると、勝手に自分の枠を使われて高額請求……なんてことになりかねません。(今回は無料プラン使ってるので高額請求はないですが)

• 対策: APIキーをプログラムの中に直接書かず、Netlifyのサーバー設定（環境変数）という金庫の中に隠しました。(当たり前なんでしょうが)
• 仕組み: 鍵はNetlifyの管理画面から直接入力し、サーバーの中だけで扱われます。コードには1文字も残りません。APIの呼び出しはすべて「サーバー側」で行うようにし、ブラウザ（利用者側）に鍵の情報が渡る余地をなくすことで、ガードを固めました。

2. 「プライバシーモード」での徹底したデータ隠蔽

「自分の最寄り駅を他人に知られたくない」という人もいるはずです。そこで、ルーム設定で「プライバシーモード」をONにできるようにしました。

• 対策:「データマスク処理」を作りました。
• 仕組み: プライバシーモードがONの時、サーバーからユーザーのスマホにデータが送られてくる直前で、全員の「座標」を空っぽに、「駅名」を "非公開" という文字に無理やり書き換えます。「表示だけ隠す」のではなく、「そもそもデータとして送らない」ことで、通信を覗き見されてもバレないようにしました。

3. リアルな「現在地」は1秒も保存しない

このアプリでは、周辺の駅を探すためにスマホのGPS（現在地）を使うことができます。でも、「今どこにいるか」という生々しい情報は、サーバーには一切保存したくありませんでした。

• 対策: DBに保存するのは「駅の場所」だけで、「ユーザーの場所」は保存しません。
• 仕組み:
  1. スマホで現在地（緯度・経度）を取得。
  2. その瞬間にAPIを叩いて「一番近い駅」の名前と場所を特定。
  3. DBに保存するのは「その駅の名前と座標」だけ。

ユーザーの自宅の座標などは、駅を探すための一瞬だけブラウザ上で使われるだけで、ネットの海（DB）には1文字も送信されない設計にしました。これなら安心して「現在地から探す」を使ってもらえるはずです。

残っている課題

「完全無料」という縛りの中でベストを尽くしましたが、やはり無料縛りゆえの限界や改善案もいくつか見えてきました。

1. 店舗データの「密度」の差

店舗情報はホットペッパーグルメAPIのみに頼っています。

• 課題: 繁華街は強いですが、場所によっては店舗情報が極端に少ない、あるいは全くヒットしないことがあります。
• 解決策としての理想: Google Maps APIを使えば圧倒的な情報量が得られますが、あちらは一定数以上の利用で課金が発生します。「無料」という今回のコンセプトを優先したため、情報の網羅性についてはトレードオフとなりました。

2. 「物理的な距離」と「移動の苦労」のズレ

現在の中間地点計算は、全員の駅の緯度・経度を足して割った「幾何学的な重心」をベースに、一番近い駅を探す仕組みです。

• 課題: 直線距離では中間でも、実は「特急が止まらない」「乗り換えが異常に多い」「運賃が片方だけ高い」といった、交通の便やコストが考慮できていません。
• 解決策としての理想: これもGoogleのDistance Matrix API等を使えば「移動時間」や「運賃」ベースでの計算が可能ですが、やはり費用の壁にぶつかります。

3. 広域移動における「納得感」の欠如

遠距離のメンバーで試すと、ロジック的には正しいのに人間の感覚では「？」な場所が選ばれます。

• 課題: 例えば「宮城県」と「愛知県」のメンバーで計算すると、重心付近の「群馬県」あたりの駅が提案されます。計算上は正解ですが、普通なら「東京でいいじゃん！」となりますよね(群馬県民の皆様すみません)。
• 今後の展望: 単純な重心計算だけでなく、「主要なハブ駅（ターミナル駅）からのアクセス」を重み付けするような、日本特有の交通網を意識したアルゴリズムの改良が必要だと感じました。

まとめ

Web開発の「右も左も分からない」状態から、AIとの対話だけでここまで形にすることができました。
「無料でどこまでできるか」に挑んだ結果、いくつかの課題は見つかりましたが、それ以上に「自分のアイデアが形になって世界中からアクセスできる」という感動は、組み込み開発とはまた違ったワクワクがありました。

もしこの記事が、同じように「Webサービス作ってみたいけど難しそう……」と足踏みしている方の背中を少しでも押せたら幸いです。