「GPTsが作れなくなったなら、僕が代わりになるサービスを作ればいいじゃん」
2026年9月10日の深夜。そんな勢いで始めたのが、AIチャットつくーるです。
きっかけは、「GPTsが作れなくなって、本当に困っています」という声でした。僕はそれまで「自分でチャットボットを作ればいいじゃん」と返していました。でも、作る方法を学んでいるAI Crewのメンバーならともかく、誰にでも気軽にできることではない。
だったら、作るためのサービスを、僕らが用意すればいい。 そう思ったときの投稿が、これです。
画像を拡大 ↗
講師が自分の教材や考え方をAIに持たせて、受講生に渡す。コンサルタントが、次の面談までの壁打ち相手を顧客に届ける。会社のマニュアルを、スタッフが会話で引き出せるようにする。
自分の分身のようなAIをつくって、必要な人に配れる。あの便利さを、もっと気軽に使えるアプリにしたいと思いました。
そこでCodexに話しかけ、仕様を決めるところから開発を開始。コードを書く以外に、アカウントを間違え、デザインを何度も戻し、自分のクレジットカードで実決済し、届かないメールや文字の見えないPDFまで直すことになりました。
この記事は、9月10日未明から翌11日未明までの最初の約24時間を、開発中の会話・別タスクの記録・変更履歴から振り返ったものです。24時間ずっと手を動かしていた、という意味ではありません。各時刻も、作業を始めた時刻ではなく、主に実装や確認の記録が残った時刻です。
先に一点だけ。きっかけになったのは、個人アカウントでのGPTの新規作成・公開の制限です。既存のGPTが一斉に使えなくなった、という話ではありません。9月11日に確認したOpenAI公式の説明でも、この二つは区別されています。
1. 最初に決めたのは「誰が、誰に渡すか」
欲しかったのは、講師や専門家が、自分の知識を受講生・顧客・スタッフに渡せる仕組みです。
受講生に渡すところを想像すると、作成画面に欲しいものも決まってきました。
| 作成画面に入れるもの | 渡すときの役割 |
|---|---|
| プロフィール写真、AIの名前と概要 | 誰の、何をするAIか伝える |
| 会話を始める質問、4つ | 最初に何を聞けばよいか示す |
| 内部プロンプト | AIの役割や話し方を決める |
| 教材・社内資料などのナレッジ | 回答の根拠になる知識を渡す |
| 公開設定 | 自分だけで使うか、リンクで共有するか選ぶ |
作る人がAPIキーを発行したり、独自の会員データベースを用意したりせずに使えるようにする。AIの利用費用は運営側で支払い、作成者が契約した利用枠を、共有先も含めて使う。上限に達したら止め、自動で追加料金が発生する形にはしない。
この時点で、画面の見た目と同じくらい、誰に費用が発生し、誰が何を見られるのかが大事でした。
振り返ると、最初に「講師がつくって、受講生に渡す」と決めたことが、後の判断のよりどころになっています。機能を増やしたくなっても、その場面で必要かどうかを考えられるからです。
名前もその場で相談し、「AIチャットつくーる」に決定。ドメインも ai-chat-maker.ai にしました。
2. 「管理者」と「利用者」を分けるのをやめた
最初は、共有リンクを受け取った人が、ログインなしですぐ使える想定でした。ところが途中で、使う人も自分のAIをつくれる方が自然だと思ったんです。
僕が誰かのAIを使うこともあるし、僕のAIを誰かに使ってもらうこともある。そこで、管理者と利用者を別アカウントにせず、一人の会員が両方をできる設計に変えました。
| 考えたこと | 最初の想定 | 変えた後 |
|---|---|---|
| 作る人と使う人 | 別の立場として分ける | 同じ会員が両方できる |
| 共有先の利用開始 | ログインなしですぐ使う | 登録・ログインして使う |
共有された人の流れは、こうなります。
共有リンクを開く
↓
登録・ログイン
↓
共有AIを一覧へ追加
↓
会話を始める「追加」は、相手のプロンプトや教材をコピーすることではありません。元のAIを使う権利を、自分の一覧に登録します。作成者が内容を更新すれば、共有先もそのAIを使います。
あわせて、最初にどの共有リンクから登録したのかと、その後どのAIを追加したのかを、別々に残すことにしました。ここは後から分析したくなっても、記録していなければ取り戻せない部分です。
会話履歴も利用者ごとに分離。AIを作った講師であっても、受講生の相談本文を見られない形にしました。教材の元ファイルや内部設定を共有画面に表示しないことと、AIが教材をもとに回答することは別です。回答を通じて内容が伝わる以上、「情報が絶対に漏れない」といった約束にはしません。
3. 深夜1時台から4時台。まず、本当に動くところまで
最初のコードの記録は午前1時6分。その後、仕様、認証、利用枠の土台を作り、3時台にはAIの作成・編集・共有・会話まで実装が進みました。
会員登録や決済まで、一から自分でつくるわけではありません。役割ごとに既存サービスを使い、Codexとつないでいきました。
僕が考えるのは、その組み合わせで講師と受講生にどんな使い心地を渡すかです。本人確認やカード登録は自分で進める必要がありましたが、接続や実装はAIと進められました。
選んだ技術は次の構成です。
| 役割 | 使ったもの |
|---|---|
| 画面とアプリケーション | Next.js / TypeScript / Tailwind CSS |
| 公開・ビルド・定期処理 | Vercel |
| 会員認証・データ・ファイル保存 | Supabase |
| AIの回答と資料検索用の処理 | OpenAI API |
| メール | Resend |
| 月額課金 | Stripe |
| ドメイン・DNS | Cloudflare |
画像を拡大 ↗
教材をアップロードできるだけでは、会話の根拠にはなりません。ファイルから文字を取り出し、検索しやすい単位に分け、質問に関連する部分を探して回答に使うところまで必要です。
PDF・Word・テキスト・Markdownを対象に、保存、文字の抽出、検索用データの作成、資料に基づいた回答をつなぎました。資料の本体はSupabaseに保存し、回答に必要な情報をAI APIへ送る構成です。
添付した教材を、回答の根拠にする
教材を全部丸暗記させるというより、質問に関係する箇所を探してから答えてもらう仕組みです。
この仕組みはRAG（検索拡張生成）と呼ばれます。今回つないだ処理を、教材を入れるときと、質問が来たときに分けると、こうなります。
| タイミング | 処理 | 次へ渡すもの |
|---|---|---|
| 教材の登録時 | ファイルから文字を取り出し、小さく分割する | 検索できる単位の文章 |
| 教材の登録時 | 文章の意味を検索用の数値に変える | 埋め込みベクトル |
| 質問が来たとき | 質問も数値に変え、関連する文章を探す | 質問に近い教材の部分 |
| 回答を作るとき | 見つけた文章と役割・話し方の指示をOpenAI APIへ渡す | 資料を踏まえた返事 |
20ファイルを毎回丸ごと送る設計ではありません。教材の元ファイルを保存することと、回答用に検索できる状態をつくることを分けています。
ここで確かめたかったのは、添付に成功したかだけでなく、資料の内容を踏まえて返事ができるかどうか。資料に書いてあっても、うまく探せなければ答えには使われません。ファイルを入れ、回答まで試すことにしました。
画像を拡大 ↗
午前4時台には、独自ドメインでの公開と、本番環境でのファイル取り込み・回答まで確認しました。ただし、すんなり通ったわけではありません。
ローカルで読めたPDFが、本番では読めない
PDFを処理するための部品が、本番の配布物に含まれていませんでした。手元では動くのに、公開環境では失敗する。そこで必要な部品を明示的に配布対象へ加え、本番でPDFをもう一度取り込んで確認しました。
この日のかなり早い段階で、「手元で動いた」と「利用者の環境で動く」は別だと突きつけられました。完成の報告を見るだけでなく、使ってもらうURLで自分も試す。そのひと手間で、公開先だけの不具合を見つけられました。
興奮して、朝5時まで眠れなかった
翌日の投稿には、そのまま「興奮しすぎて5時まで眠れなかった」と書いていました。思いついたことが、触れる画面になっていく。その場で「こうしたい」を言って、試して、また変えられる。やっぱり自社サービス開発が一番面白い、という気持ちでした。
画像を拡大 ↗
とはいえ、画面ができてうれしい気持ちと、アプリを運営できる状態にする仕事は、別々にやってきます。
4. いちばん地味に時間を使った、アカウントの整理
サービスをつなぎ始めると、「どのアカウントで入っていたっけ？」が連発しました。
会社用のメール、個人用のメール、GitHub認証、Google認証。Codexにログインしているアカウントと、OpenAI APIの料金を払うアカウントも別です。
OpenAIの接続では、再認証しても意図した会社側に切り替わらず、ブラウザを見ながら設定を進めました。本人確認やカード情報の登録は僕が操作し、AIが設定画面の確認や接続作業を進める、という分担です。
Resendでは、別アカウントに設定を進めた後に、以前から使っていたアカウントがあると気づきました。既存アカウントへドメイン認証とメール設定を移し、送信確認をしてから、不要になった側を整理しました。
最終的に、サービス名だけでなく、次の項目を一覧にしました。秘密鍵の値は一覧に書きません。
| 記録した項目 | 後から分かるようにしたこと |
|---|---|
| ログイン方法 | Google・GitHub認証など、どの入口で入るか |
| 利用する組織 | 会社用・個人用のどちらを使っているか |
| プロジェクト | そのアカウント内の、どの作業場所か |
| 用途 | このアプリの何を担当しているか |
DNSでも、ドメインを買ったら終わりではありません。www付きでアクセスした場合の設定が抜けていたので、HTTPSで本来のドメインへ移動するところまで直しました。
5. つくり方の説明も、アプリの一部だった
ナレッジは1つのAIにつき20ファイルまで。1ファイル10MBで、対応形式はPDF・DOCX・TXT・Markdownにしました。画像だけのPDFの読み取りや、動画・Excelの直接取り込みまで最初から詰め込むことはしませんでした。
でも、アップロードボタンだけ渡されても、「じゃあ何を添付すればいいの？」となります。
そこで、Claude CodeやCodexで、社内資料・教材・会員サイトの内容を整理し、添付用のナレッジにするガイドを作りました。コピペで使える指示文と、Markdownのひな形も用意。AI作成画面からヘルプとして開けるようにしています。
対応拡張子、容量、ファイル数の上限もアップロード欄に書きました。作成途中で「この形式は使えません」と初めて知るより、最初に分かる方が親切です。
実際のガイドはこちらです。Claude Code・Codexでナレッジをつくる方法
6. 午後、ホームページのデザインで迷走する
機能ができてきた一方で、ホームページには何度も「違う」と言いました。
最初は簡素すぎる。もっとワクワクさせたい。カラフルにしたら、今度は子どもっぽい。落ち着かせると、また楽しさがなくなる。
僕が届けたいのは、自分の講座や事業を持つ大人の講師・クリエイターです。「使えそう」だけでなく、「私の分身、作ってみたい」と思ってほしい。
そのイメージを伝えようと、「スマブラみたいな感じ」「Poeみたいな感じ」と例を挙げました。ただ、これも意図がうまく伝わりませんでした。
AIが並ぶんじゃなくて、自分の分身がいっぱい作れるぞっていう感じなの。
いろいろなAIを選ぶ画面と、自分の分身をつくれるという期待は違う。参考に挙げたアプリの見た目だけを拾われると、そこがずれてしまいます。
15時台から16時台にかけて、構図を変え、以前の版へ戻し、「その次のやつ」と戻し先を修正し、キャラクターを変えて、また戻しました。実装を速く変えられても、欲しい体験を言葉にする作業は残ります。
さらに夜には、文字サイズ、左右の余白、中央の空白、スマホでの読みやすさを調整。トップだけでなく、規約・ナレッジガイド・ログイン後の画面も揃え、ロゴとフッターを共通化しました。
「表示が壊れていない」と「人が見て気持ちよく使える」も、別の確認でした。
7. 名前を決めた勢いで、商標と法務も進めた
名前も決まり、この名前でアプリを育てていきたい。そこで、GVA商標で出願準備を進め、書類作成・サポートを購入しました。支払ったのは、税込 23,840円 です。
費用の記録を「商標代」で一括りにすると、どこまで済んだか分からなくなる。支払った範囲と、これからの工程を分けました。
| 項目 | 初日の時点で分かっていたこと |
|---|---|
| GVAの書類作成・サポート | 23,840円（税込）を支払済み |
| 書類と出願 | GVAから発送済み。受領・特許庁への提出・出願日の確認はこれから |
| その後の費用 | 電子化手数料や登録料は上の金額に含まない |
この時点では商標を取得しておらず、23,840円も取得までの総額ではありません。サイトの表示も「商標出願準備中」です。
利用規約と特定商取引法に基づく表記も作成。会社サイトの既存のプライバシーポリシーを参照しつつ、このアプリでのデータの扱いを整理しました。
月額課金は、料金を書くだけでは済みません。いつ更新するのか、プランを変えるとどうなるか、解約するといつまで使えるか。申込画面・実際の処理・規約の説明を照合しました。
法律のページを置いたことと、サービスの条件がちゃんと伝わることは別。後で料金設計を変えたときも、関連する表示を一緒に直しています。
8. 夜、自分のカードで月額3,000円を払ってみた
Stripeでは、まずテスト決済で、申込みから利用枠の反映、プラン変更、解約までを検証しました。本番の決済もつなぎ、最後は僕自身が実際に月額3,000円を決済しました。
そこに至るまでに、ログイン後の料金画面でボタンを押せない問題もありました。調べると、一般向けの新規受付を止めている状態が、利用者に分かる表示になっていなかった。本人の検証用の申込みを通せるようにし、受付停止時の案内も直しました。
決済後は、契約状態と利用枠が反映されたことを確認しました。自分がお客さんになったつもりで払うと、申込みから使い始めるまでを、ひと続きで見られます。
成功画面のURLだけを信じて枠を付けるのではなく、Stripe側の支払結果をサーバーで照合する仕組みです。
お金の記録も見てみました。自分の試し決済1件を分けると、こうなります。
| この取引の内訳 | 金額と記録の意味 |
|---|---|
| 自分のカードで払った額 | 3,000円。本人による試し決済 |
| 差し引かれた手数料 | 119円。108円＋税11円 |
| Stripe残高への差引額 | 2,881円。銀行への着金額や利益ではない |
お客さんからの売上ではありませんし、ここからAIの利用料などもかかります。継続課金の管理など、別途請求される分は月次明細で確認します。この119円は、今回の取引記録の金額です。
画面に書く「月額3,000円」と、運営に使えるお金は違う。料金を決める側として、その差も見ておく必要がありました。
さらに、同じ決済通知が再送されても二重に枠が増えないか、支払いに失敗したらどうなるか、回復したら戻るか、期間末の解約でどう止まるかも確認しました。
ここでの月次更新や支払失敗の検証は、テスト環境で進めたものです。実際に1か月待って2回目の本番決済を確認したわけではありません。 また、自分の試し決済が通ったことを、一般の利用者へ有料受付を全面開放したこととも分けています。
画像を拡大 ↗
9. 決済は成功。でも、メールと請求書は終わっていなかった
支払いが通ったので一段落、と思いきや、次はメールでした。
Stripeから来た英語のメールを見て、顧客向けメールのことだと思っていたら、運営者への通知だった。では利用者には何が届くのか。確認すると、決済後の通知や領収書まわりに、まだ整っていない部分がありました。
ここから、別タスクでもメールを整理しました。
アプリから送るものと、Stripeから送るものを分担し、日本語と返信先を揃えました。
| メールの種類 | 送信元と案内すること |
|---|---|
| アカウント | アプリから送信。会員登録、パスワード再設定、退会 |
| 契約と利用枠 | アプリから送信。プラン開始・更新・変更、解約予約と取消、契約終了、利用枠の案内 |
| 支払いへの対応 | Stripeから送信。支払失敗、追加認証など |
「送信処理を呼んだ」だけでは届いたことになりません。送信待ちを保存し、失敗したら再試行し、同じ通知を重複して送らないようにする。配信サービスが受け付けた状態と、配送完了した状態も分けて記録しました。
登録・再設定リンク、通知の実受信、配達状況まで確認しています。
PDFを作ったら、日本語が見えない
請求書も、宛名・税の内訳・発行者情報を確認しました。最初の決済分では補完する書類を用意したのですが、そのPDFの日本語が正しく表示されない問題が発生。フォントを埋め込み、実際に開いて読めることを確認して直しました。
チャット画面を作り始めた日の終わりに、まさか請求書の日本語フォントを直しているとは思いませんでした。でも、お金を受け取るサービスなら、ここも利用体験です。
10. 「そのメールに返信する人」を受け止める
通知メールが届けば、そのまま返信する人もいるはずです。「送信専用です」と書いても、自然に返信ボタンを押す人はいます。
そこで、問い合わせ管理のタスクにメールの受信もつなぎました。通知の返信先を窓口に揃え、送信専用という名前のアドレスへ直接届いたメールも拾えるようにしました。
問い合わせフォーム、運営側の一覧、返信、その返信への返事まで、同じ問い合わせとして追えるようにしています。ログイン中の問い合わせには、その人の契約や利用状況も関連付け、状況を一から説明してもらわずに調べやすくしました。会話や教材の本文を勝手に添付する設計にはしていません。
一方で、画面に「会員IDや契約情報を調査用に記録します」と細かく書くと、問い合わせたい人にはかえって不安になる。技術的な注意書きを何でも表に出すのはやめ、利用者に必要な案内へ絞りました。
機能を足すことと、説明を減らすことを、同じ日にやっています。
11. 解析と監視は「入れました」で終わらせない
アクセスを見るためにVercel AnalyticsとGA4、操作の流れを見るためにPostHog、エラーを把握するためにSentryを接続しました。
最初のPostHogは公開ページの限定的な計測だけ。「ちゃんと入れるなら、入れ切った方がいい」と、登録後の操作まで追加しました。
会員登録 → AI作成 → ナレッジ添付 → 初回チャット → 共有 → 有料申込み。
ボタンを押した回数だけでなく、実際に処理が完了したことを記録し、同じ利用者の操作としてつなぐ。途中で止まる場所と、継続利用を見るための画面を用意しました。会話本文、教材、メールアドレスや画面録画を、改善のためのイベントへ送る必要はありません。
テスト用の一連の操作が、計測先まで届くことも確認しました。ただし、初日に見えているのは仕組みが動くことです。実際の利用者の継続率や、有料で使いたい理由が分かったわけではありません。
Sentryの通知先は、普段見ないSlackを増やすより、僕が見るメールへ。本人宛ての通知設定を保存し、テストメールの実受信まで確かめました。通知対象は設定した条件に限られるので、「すべての障害が必ず届く」という意味ではありません。
デプロイ失敗のメールも来た
並行して進めた変更の中で、まだコミットされていないファイルへの参照が入ったことがありました。作業中の手元にはファイルがあるので見逃しやすい。でも、Vercelが取得したコミットには存在せず、ビルドに失敗しました。
参照を整理して再デプロイし、本番の復旧を確認。以後は「ローカルのビルドが通った」だけでなく、実際に公開するコミットに必要なファイルが全部入り、Vercelのデプロイと本番表示が成功したかまで見るルールにしました。
Sentryの実行時エラーと、Vercelのビルド失敗は別です。監視サービスを入れたから、公開作業の確認を省けるわけではありませんでした。
以後はAIの「できました」という報告の先に、公開先で動くことまで含めて確認するようにしました。
12. 日付が変わるころ、料金の見せ方まで作り直した
最初の料金画面は、作る側の都合が前に出ていました。利用者が知りたいのは内部の計算ではなく、「いくらで、どれくらい使えるのか」です。
そこで、3段階の料金プランと、使うほど減っていく利用枠のメーターへ変更しました。上位プランほど、100%が表す利用容量も大きくなります。
2026年9月13日追記：現在のプラン名はPro・Max・Ultraです。容量名は「利用枠」に統一し、メーターは「利用状況」として、残り利用量とリセット日時を表示しています。
余った分の扱いも詰めました。未利用分は上限を設けて翌契約期間まで繰り越し、再繰り越しはしない。下位プランへの変更は次回更新から適用する。切り替え前に、利用者が条件を理解できる表示にする。
AIの編集画面にはプレビューも追加。「試す」と言っても、表示を眺めることと、AIを実際に動かすことを分けました。
| すること | 利用枠の扱い |
|---|---|
| 名前・写真などの見た目を確認する | 消費しない |
| プレビューでAIに質問する | 消費する |
| 自分のAIを自分で使う | 消費する |
この変更は料金カードだけでは済まず、契約処理、利用枠、通知メール、申込画面、規約にも及びました。翌11日未明に、テストと本番での表示・実際の試用まで確認しています。
同じころ、プロフィール・アカウント設定や、運営用ダッシュボードも別タスクで整備しました。アプリを使う画面と、運営が問い合わせや状況を確認する画面の両方が必要になっていました。
13. 表に出ない「片付け」と、初日の費用
削除ボタンも、画面から項目を消せば終わりではありません。例えば講師が古い教材を削除したとき、保存先への通信が一時的に失敗すると、ファイルの実体だけが残る可能性があります。
そのため、削除できなかったファイルを記録し、毎日定期的に再試行する処理を入れました。教材を毎日勝手に消すのではなく、利用者が削除したものの、処理が終わらなかった分を片付ける仕組みです。初日の時点では、定刻に自動実行される初回の確認はまだ先でした。
AIの処理が中断され、実際の利用量が不明な場合の扱いも整理しました。不明な利用枠を安易に戻して使い放題にせず、記録を照合して復旧するための手順を用意しています。
費用も、初期費用と月額と従量を分けて確認しました。今回使ったサービスでも、支払い方はそれぞれ違います。
| 項目 | 支払いの扱い |
|---|---|
| ドメイン取得 | 複数年分を取得時に支払い。月額ではなく、後の更新もある |
| OpenAI API | 前払いの残高から利用に応じて消費。入金額と、実際に使った料金は別 |
| Supabase | プロジェクトの月額相当の費用。既存組織の基本料や超過分とは別 |
| 商標の書類・サポート | 出願準備の単発費用。電子化手数料や、その後の登録料とは別 |
| Vercel | 既存のPro契約を利用。このアプリ専用に基本料をもう1契約増やしたわけではない |
契約の基本料だけで運営費を見積もることもできません。決済手数料や今後のAPI利用、各サービスの超過分もあります。お金の話でも、入金済み・支払済み・これから発生する費用を混ぜないようにしました。
14. AIと開発して、最後に変えたのは進め方
この日、僕は何度か「説明だけじゃなくて、直してほしい」「残タスクを進めてほしい」と言っています。
AIが状況を整理してくれるのは助かる。でも、直せることまで報告だけで止まると、僕がもう一度「やって」と言う必要がある。逆に、完了した作業までずっと残タスクの表に入っていると、本当に残っていることが分からなくなります。
そこで、開発ルールにも書きました。
- 承認された範囲で進められることは、実行と確認まで進める。
- 「残タスク」は、このセッションで頼んだ、本当に未完了のものだけ。
- 新しい依頼が来ても、以前の未完了事項を忘れない。
- 作業単位でコミットし、公開後の画面まで確認する。
画面だけでなく、AIと一緒に仕事を進める方法まで、その場で直していたわけです。
この日の役割分担を並べると、僕の仕事も見えてきます。
| 僕が主にやったこと | Codexに進めてもらったこと |
|---|---|
| 誰に何を届けるか決める | 仕様と設計を具体化する |
| 実物を見て、違和感を伝える | コードや接続設定を直す |
| 本人確認・カード登録・実決済 | 調査とテストを進める |
| 届いたメールや公開画面を確かめる | デプロイし、変更と検証を記録する |
ここで言うVibe Codingは、自然な言葉で意図を伝え、AIと実装を行き来する作り方です。今回、AIと進めたのはチャット画面の生成だけではありません。認証、データの権限、教材検索、課金の状態変化、通知の再試行、デプロイの失敗原因まで、同じ開発の中で扱えました。
今回の僕には、もともとの会社の契約や、AIを使って仕事を進めてきた経験があります。同じ日数や予算で誰でも再現できるわけではありません。それでも、「自分の仕事には何が必要か」を伝え、返ってきた実物を見て直す、という進め方は、小さな試作から使えそうです。
ただ、確認を減らして速くしたわけではありません。例えば公開するときは、必要なファイルをコミットに含めた状態でビルドし、Vercelの公開成功を確認し、独自ドメインで実際の画面と導線を操作する。スマホで文字やボタンがはみ出さないかも見ます。変更履歴と検証スクリプトが残るので、「何を変えて、何を確かめたか」を後から追えます。
自然文で頼めば一発で完成、という一日ではありませんでした。それでも、違和感を伝えてから試せるものが返ってくるまでが速い。その速さで何度も直せることが、AIと開発する面白さでした。
「自分の仕事にも、こんなアプリがほしい」を自分で形にしたい方は、AI Crewで、Claude Code・Codexを使ったアプリづくりを学べます。受講生も、自分の仕事で使うアプリをつくっています。
15. 約24時間でできたこと。まだ、できていないこと
深夜は、思いついた仕組みを動かすことに夢中でした。昼はアカウントや見た目に迷い、夜には、自分で払ったお金や届くメール、問い合わせの受け取り方まで考えていました。
「チャット画面をつくる」で始めたはずが、使ってもらう場面を一つずつ試すうちに、運営する仕事が見えてきた一日でした。
| 時間帯（日本時間） | 進めたこと |
|---|---|
| 9/10 深夜1〜4時台 | 仕様・認証・AI作成・ナレッジ・共有・会話・テスト課金・独自ドメイン公開 |
| 午前〜昼 | サービスの訴求整理、商標の出願準備、Resendのアカウント移行 |
| 午後 | DNS・アカウント台帳、アップロード案内、ホームページの作り直し |
| 夜20〜21時台 | 認証の確認、削除失敗の再処理、本番課金接続、自分での実決済 |
| 夜22〜23時台 | メールと請求書、問い合わせ、Googleログイン、解析・監視、デザイン調整、復旧手順 |
| 9/11 未明 | 料金メーター・繰り越し・プラン変更・プレビュー、アカウント設定と運営画面 |
この時点で、AIを作って資料を読み込ませ、共有し、会話し、有料契約の決済を反映する一連の流れは動きました。問い合わせを受け、通知やエラーを確認する仕組みもできてきました。
一方で、一般向けの有料受付を広く開放する判断、商標書類の受領と特許庁への提出、初回の定刻処理の確認などは残っていました。利用者が長く使ってくれるか、講座の運営にどれだけ役立つかは、これから確かめることです。
「24時間で事業が完成した」とは言えません。自分で試し、使ってもらうための土台を、本番で動かすところまで進めた。 そのくらいの表現が、実態に合っています。
僕が作りたかったのは、講師や専門家の頭の中にある知識を、必要な人が会話で引き出せる場所です。自分が直接返事できない時間にも、その人の学びや次の一歩を助けられる。そんな分身を、もっと気軽につくれるようにしたい。
深夜の「じゃあ自分でつくればいいじゃん」が、翌日には、動く画面と実際の決済、その先の運営の課題になっていました。
この開発日記では、ここからアプリを育てる過程も残していきます。次に何を直すことになるのか。僕も、実際に使いながら確かめていきます。
2026年9月12日、日記の流れと技術の表・図解・検証内容を保ち、判断の理由と支出・決済の記録を加えて本文を改訂しました。この記事は2026年9月10日〜11日未明の開発記録です。記述は当時の状態で、現在の仕様・料金・受付状況はサービスの案内をご確認ください。本文は開発者本人の会話・提供画像と開発記録をもとにCodexが構成・執筆しました。サムネイルは本人の写真を参照して画像生成し、技術構成・教材・決済の図解も画像生成で制作。著者写真と最初の投稿画像は本人提供の写真・画像を使用しています。ログイン情報、秘密鍵、個人の連絡先、内部の原価配分などは掲載していません。