自分のためのツールを、人に使ってもらう"場所"に出した話｜AIエージェント奮闘記 #4
自分のパソコンで動くことと、誰かに使ってもらえることの間には、思ったより深い谷がありました。
この回で分かること
公開して初めて、この開発は「自分のため」から「使う人のため」に変わった
最初に開いた本番は、真っ白だった。手元では一度も起きなかったこと
4回かけて見えた、AIとの開発の「型」
前回まで3回かけて、化粧品の表記チェッカーを「動く」から「使える」、そして「信頼できる」へと育てるところまで来ました。第4話は、それを世に出した話——Vercel というサービスで本番公開し、自分以外の人にも触ってもらえる状態にする、化粧品チェッカー編の結びです。
実を言うと、公開の設定そのものは、第1話で書いた最初の3日間の、その初日に済ませていました。その後に育てた分も、同じ場所に反映してあります。
だからこの回は、手順の話ではありません。「出した」ことが、何を変えたかの話です。
本番に出す——CDNとサーバーレスの二段構え
公開そのものは、二段構えの仕組みになっています。
画面を作っているファイル（HTMLやCSS、JavaScript）は、世界中に配信網を持つCDNというところから配られます。一方、AI——Claude API——とのやり取りは、その都度だけ動く小さなサーバー（サーバーレス関数）が、間に立って代行します。
利用者のブラウザが直接AIを呼ぶのではなく、必ずこのサーバーを経由する作りです。
これで、URLを知っていれば、誰でもブラウザからこのツールを開けるようになりました。いま本番に置いてあるファイルを確かめても、第3話で384件に増やした成分データベースも、テキストを貼り付けてチェックするモードも、ちゃんと入っています。
もっとも、最初に開いた本番の画面は、真っ白でした。
最初に開いた本番は、真っ白だった
初めての公開コマンドが通り、払い出されたURLを開くと、画面には「Cannot GET /」という一行だけが出ていました。
Vercel が、手元で動作確認するために置いていた小さなサーバー（Express）のほうを入口だと解釈してしまい、画面のファイルを配ってくれなかったのです。設定ファイルに「画面のファイルはCDNから、/api/check だけは関数へ」と振り分けを明示して、ようやく画面が出ました。
画面が出ても、まだ動きません。AIを呼ぶための鍵を、本番の環境にまだ登録していなかったからです。
管理画面で環境変数として登録し、再デプロイして、状態が「Ready」になるのを確かめました。画像の読み取りに時間がかかっても途中で打ち切られないよう、関数が1回に使える時間の上限も30秒に設定しました。
どれも、自分のパソコンの中では一度も起きなかったことです。
手元で動いていたのは、手元の条件が揃っていたからにすぎません。開発環境では動いたものが、実際の環境に持ち出すと黙り込む——組込みで何度も味わってきたことを、久しぶりに思い出しました。
とはいえ、この回で大事なのは、つまずきの細かさではありません。「自分のパソコンの中」にあったものが、「誰でも触れる場所」に出た——その事実のほうです。
そして、出した瞬間に、相手が"自分"ではなくなりました。
公開した瞬間、相手が「自分」でなくなる
ローカル、つまり自分のパソコンの中だけで動かしているうちは、触るのは自分ひとりです。多少お行儀の悪い使い方をしても、困るのは自分だけ。
でも、公開すると、見知らぬ誰かが触ります。前提が、まるごと入れ替わるのです。
ここで、立ち上げのときから仕込んでおいた"守り"が、ようやく本当の意味を持ちました。
ひとつは、AIを呼ぶための鍵（APIキー）を、サーバー側にだけ置き、利用者のブラウザには絶対に出さないこと。
鍵が画面に漏れれば、他人に使い込まれて、料金だけ私に請求される——そんな事故を防ぐためです。万一漏れたときに備えて、鍵を失効させ、再発行して差し替え、古い鍵が使われた履歴を確かめる、という手順も、手順書に先に書いておきました。
もうひとつは、短時間に何度も叩かれないようにするレート制限です。同じ接続元からは1分間に10回まで。超えると「送信回数の制限に達しました」と返し、あと何秒待てばよいかを伝えます。
公開の設定を済ませた直後、改良の第1回で入れたものです。手元で動作確認するためのサーバーには、この制限を入れていません。
守りが要るのは、見知らぬ誰かが触る側だけでした。
そして、画面の下に常に出している免責の一文。「本ツールによる判定はAIによる参考情報です」と書き、最終的な判断は専門家や行政機関に確かめてほしい、と添えています。
同じ文面は、書き出すレポートにも入れました。
これらは、自分ひとりで使っていたときには、正直、なくても困らないものでした。
でも公開した今は違います。使う人を守り、同時に自分も守る仕掛けです。
公開とは、便利さを差し出すのと引き換えに、この「使う人への責任」を引き受けることだったのだと、出してみて実感しました。 第1話で引いた「どこを握るか」の線が、いちばん効いてきたのは、この公開の場面だったのです。
振り返ると、この4回は、バラバラの工夫ではありませんでした。
4回かけて見えた、AIとの開発の「型」
化粧品チェッカー編の4回を、並べ直してみます。
第1話では、どこまでをAIに任せ、どこからを自分が握るか、という線を引きました。
第2話では、AIの「判定不可」とコストに計器をつけて、育てる手綱を握りました。
第3話では、テストという安全網を広げて、量を信頼に変えました。
そして今回、使う人への責任を引き受けて、世に出しました。
並べてみて、はっきりしました。これらは別々のテクニックではなく、一本の"型"だったのです。
どこを握り、どう育て、どう守り、どう届けるか。その流れ全体が、AIと開発するときの自分なりの型になっていました。
AIは、確かに速い。コードを書くのも、直すのも、文書を作るのも、私より速い。
けれど、この「型」を持つのは、人間の側の仕事でした。
組込みの世界で、私は何度も「製品を世に出す」ことをやってきました。動くだけでは出せない、誰かの手に渡るものには別の重さがある——それは体に染みついています。
その感覚が、相手がAIに変わっても、個人開発という小さな舞台でも、最後まで一周した。完走して初めて、型は型になる。
そう感じた4話でした。
もっとも、公開はゴールではありませんでした。
それでも、まだ「完璧」ではない
正直に書いておくと、公開はスタートラインでもあります。
第2話で「コストに見合わない」と保留にした機能——複数のAIで信頼度を出す仕組みや、定期的に自動でチェックを回す監視——は、まだ手つかずのままです。
画面の「参考情報です」という免責も、外していません。最終的な判断は人間がする、という線は、引いたまま残してあります。
守りそのものにも、限界があります。先のレート制限は、厳密なものではありません。
サーバーレスの関数は、呼ばれるたびに別の入れ物で立ち上がることがあり、回数の記録もその入れ物ごとに別々だからです。コードには、AI自身が「厳密な全体の制限ではないが、暴走的な連打の抑制には有効」という趣旨の注記を残していました。
守りの限界を、守りと一緒に書き残しておく。 こういう一行があるかどうかで、後から読む人の安心はまるで違います。
改良案の一覧にも、未チェックのまま残っている項目が二つあります。どれくらい使われているかを見るアクセス解析と、コードを更新したら自動で本番に反映させる仕組みです。
第2話で計器の大切さを書いた身としては、耳の痛い宿題です。
それでも、こうして穴を残したまま出したことは、弱さではなく誠実さだと思っています。完成したから出す、のではなく、使われながら育てていく前提で世に出した。
動くものを抱え込んで磨き続けるより、線を引いたうえで、まず人の手に渡してしまう。これも、AIと組んで速く作れるようになったからこそ、選べた出し方でした。
動く、使える、信頼できる、そして届く
これまで積み上げてきた「動く・使える・信頼できる」に、今回ようやく「人に届く」が加わりました。
公開という最後の一歩で、AIとの開発がひとまわりし、私は最初の"型"を手にしました。第1話で引いた一本の線が、4話かけて、ひとつの形になった感覚です。
まとめ
任せたこと：実装・テスト・文書、そして守りの限界をコードに注記することまで
握ったこと：APIキーの置き場所、レート制限、免責の一文——使う人への責任
次の課題：保留した機能、アクセス解析、自動デプロイ。使われながら育てていく
化粧品チェッカーは、私にとって「AIに実装を任せて、公開まで完走した」プロジェクトでした。
次回からは、もう一本の個人開発に移ります。今度は、対照的なアプローチの話です。コードを1行も書き始める前に、AIと一緒に"文書"から積み上げていった——請求書を自動で集めるツールの話を書きます。
仕事の依頼（ココナラ）：作業の自動化を頼む／Claude Code の使い方を教わる
