ここで差がつく！アプリを作るときに使った外部サービス・管理機能18個を全部教える

AIが答える。教材も使える。支払いもできる。

そこまで動くようになったアプリで、次に気になったのは「ログインしたら、どこへ行くのか」でした。

使いたいAIを選ぶ。前の会話を開く。自分でもAIをつくる。誰かから受け取ったAIを使う。そのたびに画面の考え方が変わったら、使い続けるのは面倒です。

2026年9月12日、AIチャットつくーるの開発3日目。この日は画面を作り直しながら、料金、問い合わせ、メールでの案内を整え、商標出願の記録も残しました。

初日は、思いついたものを動かす日。2日目は、どんな人に使ってほしいかを伝える入口をつくる日。3日目は、動き始めたアプリを、使う側と運営する側の両方から見直す日になりました。

この記事は、9月12日の会話・開発メモ・変更履歴と、本番での確認記録を照合して振り返っています。前日までに用意した仕組みと、この日に追加・変更した部分は分けて書いています。

1. ログインしたら、まずAIを選ぶ

ログイン後のホームは、AIを選ぶ画面にしました。

最初から会話を開く案や、会話と管理を一緒に置く案も比べましたが、自分でつくったAIも、誰かから受け取ったAIも、同じ場所から選べる方が自然だと考えたんです。

このとき僕が伝えたのは、こんなことでした。

利用者と作成者のUI上の違いはそこまで大きく分ける必要はなく、基本的には両者とも同じUIで問題ありません。

自分のAIを受講生に渡す人も、別の人がつくったAIを使うことがあります。「つくる人用」と「使う人用」の別世界に分けず、同じサイドバーから移動できるようにしました。

操作	今回決めた動き
普通にログインする	AIを選ぶホームへ進む
左上のロゴを押す	ログイン後のホームへ戻る
AIを選ぶ	そのAIとの最後の会話を開く。履歴がなければ新しく始める
会話中に「新しいチャット」を押す	同じAIとの新しい会話を始める
AIをつくる・編集する	共通のサイドバーを残したまま、作成画面を開く

「最後の会話」にも細かい判断がありました。新しく作成した順ではなく、最後にやり取りした順で開きたい。以前につくった会話でも、さっき続きを話していたなら、そこへ戻りたいからです。

作成者が見る利用状況も、数字の意味を分けました。

表示するもの	何を数えるか
ゲットした人数	現在、その共有AIをマイAIに迎えて使える人
会話した人数	対象期間に、そのAIの通常チャットで回答を受け取った人
AIごとの使用量	通常の会話やテストで確定した利用枠の消費（資料の登録・再処理は対象外）

人数には作成者自身を含めず、「ゲットしただけ」と「実際に会話した」を分けています。作成者に受講生の会話本文を見せる機能ではありません。

途中では、Codexとのやり取りも行き違いました。僕は見本どおりに実アプリへ反映してほしいのに、AIが見本の承認を記録したところで止まったんです。さらに、見本そのものを本番へ置く話になり、目的を伝え直しました。

最終的には、見本の状態切替や架空データを公開するのではなく、実際のAI・会話履歴・作成・配布・利用状況へ接続。本番でも短いAI回答の受信と保存まで確かめました。

2. 共有されたAIを「ゲットする」体験

受講生が講師からリンクを受け取ったとき、何が起きるのか。ここも作り直しました。

リンクを開くと、まずAIの名前と写真が見える。そこから会員登録しても、同じAIのところへ戻る。そして、自分で「ゲットする」を押して、マイAIに迎える流れです。

共有リンクでAIの名前・写真を見る
  ↓
登録・ログインする
  ↓
同じAIの受け取り画面へ戻る
  ↓
「このAIをゲットする」を押す
  ↓
追加の成功を確認してから演出する
  ↓
そのAIと会話を始める

僕が頼んだのは、写真がふわっと自分の中へ溶け込むような見せ方でした。ただし、演出だけ先に成功させるわけにはいきません。サーバーで追加できたことを確認してから動かし、失敗したときはやり直せるようにしています。

登録しただけで、勝手にAIを追加する形にもしていません。「会員になる」と「このAIを使いたい」は、別の操作として残しました。

ここでいうゲットは、使えるAIを自分の一覧へ加えること。講師の教材や設定、AIの所有権をコピーすることではありません。作成者が共有を止めた場合や、利用枠が足りない場合の制限も続きます。

呼び名も、その場その場で変えないように用語集へ残しました。画面の文言は小さなことに見えますが、同じ操作に違う名前が付いていると、使う人は毎回考え直すことになります。

3. 月額料金を変えると、決済の履歴も気になる

料金は、この日に税込3,300円・11,000円・33,000円へ変更しました。

プラン名は2026年9月13日の名称変更に合わせて記載しています。月額料金は変わりません。

プラン	今回決めた月額（税込）
Pro	3,300円
Max	11,000円
Ultra	33,000円

料金表の数字だけなら、すぐに直せます。でも、初日に僕自身が試した3,000円の本番決済が、すでにありました。

過去の支払いまで書き換えるのか。途中で差額を請求するのか。次回から切り替えるのか。ここは自分の契約で試しているからこそ、具体的に決める必要がありました。

今回は、初回3,000円の履歴を残し、次回の更新から3,300円へ変更。途中の追加請求は発生させず、更新日と利用枠も維持しました。

確かめた場所	確認したこと
料金ページ・規約・通知	税込の新料金が揃っている
自分の本番契約	次回から新料金へ移り、初回の決済履歴が残る
テスト環境	旧料金からの更新、支払い失敗と復旧、プラン変更、解約が動く

一般向けの有料受付は、まだ開放していません。また、本番の次回更新を実際に迎えて請求を確認したわけではなく、更新の一連の処理はテスト環境で確かめています。

このあたりは、見た目の料金表と、Stripeの契約と、アプリ内の利用枠がつながっています。一つを変えたら、ほかも同じ意味になっているかを見る作業でした。

4. 問い合わせとメルマガは、別の仕事だった

問い合わせの入口は、フォームへ揃えました。メールによって電話や直接返信へ誘導していると、対応する場所が散らばってしまうからです。

お問い合わせはすべてフォーム経由にするべきですし、そうしないと一元管理ができません。

すでに直接メールが届いた場合に問い合わせとして保存する仕組みはあったので、そこは残しています。案内する入口をフォームへ揃え、届いたものを見失わないようにしました。

一方、AI Crewのセミナーや法人研修を案内するために、会員向けのメルマガ機能も追加しました。こちらは問い合わせへの返事とは目的が違うので、管理画面も分けています。

メールの種類	今回の扱い
問い合わせへの対応	フォームから受け付け、一つの問い合わせとして履歴を追う
セミナーなどの案内	受信に同意した人を対象に配信し、配信停止を受け付ける
認証・契約などの重要通知	案内メールを停止した後も、必要な通知として届ける

登録時の説明は、最初かなり長くなりました。Google登録のための大きな注意書きもあり、画面が説明だらけになったので、実際の他社の登録画面も調べて短くし直しています。詳しい内容は規約に置き、登録ボタンの近くでは何に同意するかを簡潔に伝える形にしました。

配信機能は「送れた」で終わらせず、止めたい人が止められるところまで確認しました。

本番の試験用宛先で試したこと	結果
新規登録後の購読	メール確認が済んだ後に対象へ入る
管理画面からの配信	Resendからの配達結果が管理画面へ戻る
メール末尾からの配信停止	ログインせずに停止できる
停止前から待っていたメール	送信直前の確認で除外する
停止後の重要通知	認証・契約などの通知は引き続き届ける

既存会員をさかのぼって自動追加したり、再ログインしただけで配信を再開したりする動きにもしていません。

この確認にはResend公式の試験用宛先を使いました。実会員へ一斉配信した実績ではなく、普段使う受信箱での表示や迷惑メールへの入り方、大量配信まで試したわけでもありません。

5. バナーは、つくってから外した

案内を出す仕組みも試しました。セミナーのポスターを横長のバナーにし、ログイン後の画面へ置いたんです。

ところが、実物を見ると目立ちすぎる。AIを選んで使いたい場所で、案内の方が強く見えてしまいました。

試した配置	その後の判断
横長の大きなバナー	主な操作より目立つので縮小する
AI一覧の下の小さなバナー	掲載場所をもう一度考える
この日の最終状態	バナーは非表示。管理機能と素材は残す

案内先にはUTAGEの専用登録経路も用意して、どこから来たかを区別できるようにしました。ただ、つないだからといって、今日ここへ置く必要があるわけではありません。

仕組みは残しておいて大丈夫ですが、どこに配置するかはまたゆっくり考えましょう。

最後は、表示をオフにしました。せっかくつくったから載せ続ける、とはしなかった部分です。

6. トップの比較表も、説明を増やしすぎない

トップページには、他のAIツールとの違いを伝える比較欄を用意しました。ここでも、説明を足して、実際に見て、減らすことを繰り返しています。

「教材から自分の分身AIをつくり、受講生へ渡す」という説明と図の途中へ表を入れると、話が切れてしまう。元の説明は戻し、図の後を独立した比較のまとまりにしました。

PCでは表で見渡せても、そのままスマホへ縮めると読みにくい。小さい画面では、同じ情報をカードで縦に読むようにしています。

見直したところ	最後に残した形
文章と図の流れ	元のまとまりを保ち、その後に比較欄を置く
説明の量	長さを揃え、要点だけ太字にする
配色と記号	他のツールは同じ色に揃え、自社の欄を強調する
スマホ	文字を小さく詰めず、カードを縦に並べる

「可愛くして」と頼んだ後にも、ツールごとの色や丸いバッジは減らしました。可愛さと、比較しやすさ。その両方を見ながら、実物で調整していました。

7. 使っている外部サービスを整理したら、18項目になった

AIチャットつくーるで使っている外部サービスの一覧を、見直しました。

前の表には、OpenAI、Resend、Stripe、Supabase、Vercel、GitHub、Cloudflareの7つ。エラー監視のSentryや、運営画面を守るBasic認証は載っていませんでした。ほかにも抜けているものがありそうだったので、Codexに実装と確認記録を調べてもらいました。

整理し直すと、外部サービスと管理機能を合わせて18項目。その一覧を見て、僕はこう話しました。

これ結構有益だから開発日記に書いてあげましょう。

自分の教材を使うAIを受講生に渡す。顧客が繰り返し使えるアプリをつくり、月額で提供する。そんなことを考えたとき、会員登録や決済、メールの仕組みをどう用意するのか。このアプリで実際に使っている構成は、参考になると思ったんです。

それぞれに任せている仕事と、僕のアプリ側で決めていることを、利用者の操作からたどって整理しました。

18項目には、同じVercelの機能を分けた行や、自作の管理機能も含みます。18社と契約している、という意味ではありません。AI回答や検索向けの運用も含む、今回のアプリの構成です。案内先に使うUTAGEや、商標の書類作成を頼んだGVAは別用途なので、この18項目には数えていません。

2026年9月12日時点の記録です。アプリ本体は公開していますが、新規の有料申込は本人の検証用アカウントに限定しています。一般の有料受付はまだ開放していません。

利用者の「登録して、使う」を裏側から見る

僕がつくりたいのは、講師や専門家が自分の知識をAIに持たせて、必要な人に渡せるアプリです。利用者には、登録したら使い始められる形にしたい。その一連の操作を、裏側の仕事に分けるとこうなります。

利用者の操作	裏側の仕事と担当
サイトを開く	Cloudflareがドメインの行き先を案内し、Vercelが画面を届ける
会員登録・ログイン	Supabaseで会員を確認する。Googleアカウントから入る入口も用意
確認メールを開く	Supabaseの認証処理から、Resendを通じてメールを送る
月額プランを申し込む	Stripeが決済し、結果をアプリへ知らせる
AIに質問する	アプリで利用権限と利用枠を確認し、OpenAIへ回答を依頼する
またログインする	Supabaseに保存したAIや会話履歴を読み込む

会員登録、決済、メールの配信まで、全部を一からつくる構成にはしていません。既存サービスにそれぞれの仕事を任せ、Codexとアプリを組み立てています。

ただ、外部サービスを契約すれば、利用者の体験まで自動で完成するわけではありませんでした。例えば、決済を担当するStripeと、利用枠を持つアプリの間には、次の処理を用意しています。

Stripeで支払いが完了する
  ↓
支払い結果の通知をアプリが受け取る
  ↓
通知の署名と契約を照合する
  ↓
契約状態と利用枠に反映する

外部サービスが別のシステムへ出来事を知らせる仕組みを、Webhookと呼びます。今回なら「支払いが完了した」という通知です。Stripeの公式説明

通知の署名を確かめるのは、正しい送信元から届いたものか確認するため。利用者の画面に「支払い完了」と出たことだけを根拠に、利用枠を増やす形にはしていません。ここは、自分で本番の支払いをして、契約と利用枠への反映まで確かめました。

アプリを動かすために使っている8つ

まずは、公開、会員登録、保存、決済、メール、AI回答を担当するサービスです。名前から公式の説明を開けます。

サービス	このアプリで任せている仕事
Cloudflare	ドメインの管理と、サイト・メールの行き先を決めるDNS設定
GitHub	ソースコードの保存、変更履歴、修正事項の管理
Vercel	サイトとサーバー処理の公開、GitHubと連動した更新
Supabase	会員認証、データベース、画像・教材・添付ファイルの保存
Google Cloud／Googleログイン	Googleアカウントで登録・ログインするための接続設定
Stripe	月額課金、プラン変更、更新・解約、請求書・領収書
Resend	登録確認、パスワード再設定、契約などの通知、問い合わせ・メルマガの配信
OpenAI Platform	AIの回答生成と、教材を検索しやすい形にする処理

GitHubとVercelとCloudflareは、別の仕事をしている

GitHubには、アプリのプログラムと変更履歴を置いています。Vercelは、そのプログラムを利用者が開ける形で動かす場所。Cloudflareでは、そのアプリへたどり着くドメインを管理しています。

ドメインは、このサイトなら ai-chat-maker.ai という名前です。DNSは、その名前に対して、サイトやメールの行き先を案内する設定。名前を用意することと、アプリを動かすことは分かれています。

僕の構成では、プログラムを修正した後の更新を、こうつないでいます。

Codexとアプリを修正する
  ↓
GitHubへ変更を送る
  ↓
Vercelが公開用に組み立てる（ビルド）
  ↓
動かす環境へ配置する（デプロイ）
  ↓
本番の画面と動作を確認する

GitHubへ変更を送るところと、本番で使えることを確かめるところは別です。この開発では組み立てに失敗したこともあり、最後に実際の画面を見るところまでを確認しています。

会員登録も、一つのサービスだけでは完結しない

Supabaseでは、会員アカウントやデータを管理しています。Googleログインは、その会員アカウントへGoogleのアカウントから入るための入口です。

「Googleで続ける」という一つのボタンにも、Google側とSupabase側の設定があります。本番でログインし、実際に入れることを確認しました。

登録確認メールは、Supabaseの認証処理からResendの送信機能を使います。契約などの通知は、アプリからResendへ依頼します。登録を受け付ける処理と、メールを届ける処理も分けているわけです。

そのうえで、自分のアプリとして決める部分が残ります。

アプリ側で決めたこと	今回の使い方
誰のデータを見られるか	会話履歴は利用者ごとに分ける。AIをつくった講師でも受講生の会話本文は見られない
共有されたAIをどう使うか	共有先が使う権利を、自分の一覧に登録する。教材の元ファイルを配る操作にはしない
AI利用料を誰が負担するか	運営側でOpenAIへ接続し、作成者が契約した利用枠を共有先も含めて使う

元ファイルを直接配らなくても、AIの回答に教材の内容が含まれることはあります。

自分の教材を渡すとき、どこまで共有したいのか。受講生の相談内容は誰が見られるのか。こうした使い方は、外部サービスの名前を選ぶこととは別に決めてきました。

OpenAIには、回答生成と教材の数値化を任せる

APIは、アプリから外部サービスへ処理を頼むための窓口です。質問と必要な情報を送って、OpenAIから回答を受け取ります。

教材には、文章を検索に使える数値へ変換するEmbeddingという処理も使っています。その数値をSupabaseに保存し、質問に近い部分を探します。登録時と質問時を分けると、役割が見えやすくなります。

教材を登録するとき
  文章を取り出して分割する：アプリ
  検索用の数値へ変換する  ：OpenAI
  文章と数値を保存する    ：Supabase

質問を受けたとき
  質問を検索用の数値にする：OpenAI
  関連する教材を探す      ：Supabase
  必要な情報をまとめる    ：アプリ
  その情報から回答をつくる：OpenAI

このように関連資料を探して回答に使う仕組みが、RAGです。教材を渡した後、実際にその内容を使って回答できるかも、本番で確かめています。

AIチャットつくーるの利用者には、自分でOpenAIのAPIキーを用意してもらう方式にしていません。利用者が教材を持たせて使うまでの準備は、できるだけアプリ側で引き受けたいところです。

一覧から抜けていた、公開後の運営を支える3つ

今回、表を更新しようと思ったきっかけの一つが、Sentryと運営画面でした。AIが回答することに目を向けていると、こうした裏側の仕事は一覧から抜けやすいですね。

サービス・機能	このアプリで任せている仕事
Sentry	アプリが動いている最中のエラーを記録し、設定した条件で通知する
Vercel Cron	通知、問い合わせ、分析データの配信、不要ファイル回収の処理を定期的に呼び出す
自作の運営画面・Basic認証	ユーザー、契約、問い合わせ、メルマガ、バナーの管理と、運営画面の入口保護

Sentryを入れても、ビルド失敗の通知とは別だった

利用者が別の場所で使っているときのエラーは、僕の画面を見ていても分かりません。その記録と通知にSentryを使い、検証用のエラーが届くことと、高優先度アラートのメール受信を確認しました。

一方、この開発では、Vercelで公開用のアプリを組み立てる段階の失敗もありました。そのときに確認したのは、Vercelからのビルド失敗メールです。

エラーが起きる場面	今回確認する場所
公開用のアプリを組み立てている途中	Vercelのビルド記録・失敗通知
公開されたアプリを使っている途中	Sentryに送った実行時エラーと、設定した通知

同じ「エラー監視」でも、どの場面を見ているかが違います。Sentryを接続済みにするだけで終わらず、通知の種類と実際の受信まで照合した理由がここにあります。

定期処理は、設定した時刻に動くかまで見る

Cronは、決まった時刻に仕事を始める仕組みです。僕のアプリでは、「配信待ちの通知を処理する」「削除待ちのファイルを回収する」といった呼び出しに使っています。

呼び出された後の処理や、失敗した仕事をどう再処理するかはアプリ側の実装です。今回は4つの処理について、設定を保存するだけでなく、定刻の実行記録と処理待ちのデータを照合しました。

メールが届かないとき、送信機能への接続だけを見るのか、そもそも配信待ちの処理が動いているかも見るのか。分担を記録しておくと、確かめる場所をたどれます。

Basic認証は、運営画面の入口を守る機能

Basic認証は、ブラウザでユーザー名とパスワードを求める認証方式です。外部サービスの名前ではありませんが、運営の構成を把握するために今回の一覧へ入れました。

このアプリでは、その入口を通った後にも、ログイン中のアカウントが運営者かを確認します。データを取得する処理でも権限を確認します。

誰かを確かめる「認証」と、その人に何を許すかという「権限の確認」は、分けて考えています。 会員登録ができることを、運営データも見られることにはつなげません。実際に、運営者以外からのデータ取得が拒否されることを確認しました。

使われ方を知るための3つ

エラーが出ていなくても、登録した人がAIをつくる前に止まっていたら、アプリは十分に役立っていないかもしれません。そこで、公開ページの閲覧と、登録後の操作を記録しています。

サービス	このアプリで知りたいこと
Google Analytics 4（GA4）	公開ページがどれくらい読まれ、どこから来ているか
PostHog	登録、AI作成、チャット、共有、課金へ進んでいるか。繰り返し使われているか
Vercel Web Analytics	公開ページのアクセス状況をVercel側でも確認する

GA4は本番の受信とAPI経由の集計取得、PostHogは操作の記録が届くことと分析画面の作成、Vercel Web Analyticsは本番の受信を確認済みです。

「ページを読んだ」と「AIをつくって使った」は別の出来事。今回の役割分担では、前者を主にGA4、登録後の操作をPostHogで見ています。ただし機能の重なりもあるので、この3つすべてが決済付きアプリの必須条件というわけではありません。

また、今の構成では、登録前の匿名の閲覧と登録後の操作をつなげていません。「このページを読んだ人の何％が登録したか」まで、全部が分かる状態ではないです。

何を記録するかも決めました。チャット本文、教材、内部プロンプト、メールアドレスを行動分析へ送らず、登録や回答の完了など、必要な出来事を集計します。画面録画も無効にしています。

受講生や顧客がアプリで相談する内容と、運営のために知りたい操作の記録は分けたい。今の構成と確認範囲を並べておくと、何が見えて、何は見ていないのかも残せます。

検索とページ改善に使っている4つ

講座や仕事で使うアプリをつくっても、必要な人が見つけられなければ、使うところまで届きません。AIチャットつくーるでは、検索向けの設定や、ページの表示速度を調べる道具も使っています。

サービス	このアプリで任せている仕事
Google Search Console	Google検索での表示・クリック、ページの登録状況、サイトマップの管理
Bing Webmaster Tools	Bing側のサイト登録と、検索エンジンがページを読み取った状況の確認
IndexNow	公開・更新したURLを、対応する検索エンジンへ知らせる
PageSpeed Insights	ページの表示速度などを診断し、改善点を調べる

サイトマップは、公開しているページの一覧です。検索エンジンがページを見つける手がかりとして送ります。GA4が主に「サイトへ来た後」を見るのに対し、Search Consoleでは「Google検索でどう見えているか」を調べます。

Search Consoleは所有権の確認とAPI接続、トップページの検索登録まで確認しました。Bingは所有権の確認、サイトマップ送信、API接続まで。IndexNowは公開URLの送信成功、PageSpeed InsightsはAPI接続と実際の計測を確認し、後者は手動で実行しています。

ここは、確認できたことを広く言いすぎないようにしています。URLを送信できたこと、検索結果に載ったこと、そこから読者が来たことは別です。つないだ道具の数を、集客の成果として数えるわけにはいきません。

設定画面の先で、実際に確かめたこと

一覧を更新するときは、「接続済み」という言葉だけでは足りませんでした。利用者の操作まで戻って、どこまで確かめたかを記録と照合しました。

確かめたこと	確認した範囲
登録確認メール	実際に届き、リンクを開いてログインできること
本番の初回決済	自分で支払い、契約と利用枠へ反映されること
決済後の変化	テスト環境で、更新、支払い失敗からの復旧、解約を処理できること
問い合わせの往復	相手からの再返信が、同じ問い合わせへ戻ること
エラー通知	検証用エラーがSentryへ届き、設定したメールを受信すること
運営画面の権限	運営者以外は、画面だけでなくデータ取得も拒否されること
定期処理	予定どおり動き、照合時点で処理待ちが残っていないこと

本番の初回決済と、テスト環境での更新や解約は分けています。実際に翌月まで待って、本番の継続課金を確認したという意味ではありません。

会員情報を保存する場所はSupabase、支払いはStripe、メールはResend。そう整理できても、誰が何を使えて、どんなときに通知するかは、自分のアプリの使い方から決める必要がありました。

今回の一覧には、AIが回答するまでの仕組みだけでなく、利用者からの問い合わせを受け、エラーに気づき、使われ方を確かめるための道具も入っています。アプリをつくり始めたときには、こうした裏側まで同じ表で見ることはできていませんでした。

8. データの扱いは、実装と説明をそろえる

運営に必要なのは、接続先の一覧だけではありません。利用者が入力した内容を何に使うのか、会社のプライバシーポリシーも見直しました。

最初の改定案では、細かい説明や新しい告知枠を足しすぎて、一度元へ戻しています。僕が求めていたのは、従来の文章に必要な変更を加えることでした。

その後、変更する箇所を具体的に確認し、アプリでの回答生成・資料検索と、アクセス解析で外部へ送る情報などを反映しました。

照合したこと	今回の確認
入力内容・会話・資料の処理	回答生成や資料検索のために外部AIで処理する説明を追加
アクセス解析	送信先の事業者、送る情報、使う目的を整理
OpenAI側のデータ共有	利用中の組織の共有設定が無効であることを実画面で確認

ここでの共有設定の確認は、データの保存期間や個別契約まで監査した、という意味ではありません。画面で確かめた設定と、それ以外のことを一緒に「確認済み」にしないようにしています。

記事には外部サービスの構成を載せつつ、会社の文書には、その文書に必要な説明を置く。何でも同じ場所に全部書けばよいわけではなく、読む場面に合わせて整える作業でもありました。

9. 商標の出願書類を、ポストへ

初日の日記では、名前を決めた勢いでGVA商標の書類作成・サポートを申し込んだところまで書きました。その後、出願書類を郵送するところまで進みました。

出願した名前は、AIチャットつくーる。手元の願書には、その文字と特許印紙が並んでいます。

画像を拡大 ↗

願書の写真で見えるもの	記載内容
商標	AIチャットつくーる
文字の形式	標準文字
区分	第42類
貼られた特許印紙	10,000円・1,000円・1,000円の計12,000円分

封筒の品名は「商標登録願 在中」。準備した書類を入れて、ポストへ。

画像を拡大 ↗

初日は書類の準備、そこから実際の提出へ。書類作成のサポートを頼んだ後にも、自分で手を動かして進める工程がありました。

これで、商標は出願済みになりました。商標登録が完了した、という意味ではありません。アプリをつくる作業と一緒に、名前に関する手続も一つ進みました。

10. 日記のために、仕事の残し方も変えた

今日、かなりやり取りしたのが、この開発日記そのものです。

事業者向けに役立つ記事にしたい。そう頼んだら、AIが経営教材のような見せ方に変え、タイトルや表紙まで変わってしまいました。僕が残したかったのは、もともとの日記の読み心地です。

その技術的な学びもあるし、判断の経緯も見れるというところを狙っていきたいんですよ。

技術の表や図解を減らして、判断の文章だけにしたいわけでもありません。何をどう組み合わせたかが見え、その横で「なぜそうしたか」も分かる。その形へ戻しました。

日記で使う表現	残したいもの
表	サービスの分担、操作の前後、実際に確かめたこと
図や処理フロー	どこで何が起きるか、どんな順番で進むか
本人の言葉	迷ったこと、頼み直した理由、採用・撤回した判断
写真	その日に自分で進めたことの記録

毎回同じ本人写真を表紙に入れることや、読む前に「約何分」と長さを見せることもやめました。この日記も、同じ日の題材を別々の記事にせず、1日1本へまとめています。

もう一つ困ったのが、別のパソコンで進めた会話の引き継ぎです。コードの変更履歴だけでは、「なぜ戻したか」まで分からないことがあります。一方、毎回会話を全部集め直すのも負担が大きい。

そこで、作業したAIが区切りごとに短い開発メモを残し、コードと一緒に保存する運用に変えました。

作業を担当したAIが残すこと
  成果：何を変えたか
  判断：なぜ選んだか、何を戻したか
  本人の言葉：判断のきっかけ
  確認：実際に試したこと、まだ分からないこと

日記を書くときは、そのメモと変更履歴を読み、必要なところだけ元の会話へ戻ります。今回も関連サイトの記録を確認し、アプリに関係する出来事を選びました。

自分の仕事に合うアプリをつくるとき、コードを書くことだけでなく、実物を見て判断し直す場面は何度もあります。僕が運営するAI Crewでは、受講生がつくったホームページや業務アプリを紹介しています。自分の仕事なら何をつくりたいか、具体的な制作物から考えてみてください。

11. 3日目を終えて

時間帯は日本時間で、主に変更履歴や確認の記録が残った時刻です。表の時間ずっと作業していた、という意味ではありません。

時間帯	この日に進めたこと
未明〜午後	2日目の日記の公開・改稿、読者と表現の見直し、外部サービス一覧の整理
15〜17時台	開発メモの共有、トップの比較、共有AIの受け取りとゲット演出
18〜19時台	税込料金の変更、問い合わせの案内統一、メルマガ機能、商標出願の記録
20〜22時台	比較表の調整、バナーの設置と撤回、登録説明の短縮、配信と停止の検証、会社文書の改定
23時台	ログイン後の共通画面を本番へ反映し、実AI回答を含む操作を確認

最後のログイン後画面では、PCとスマホで本番の40項目を確認しました。画面が表示されるだけでなく、AIを選ぶ、会話を再開する、つくる、受け取る、配る、という操作がつながるところまでです。

料金もメールも、仕組みを用意したことと、使い続けてもらえることは別。一般の有料受付、バナーの置き場所、その先の実際の利用状況には、まだ考えることが残っています。

でも今日は、画面を変え、金額を決め、出願済みの記録を残し、必要なところは一度戻すこともできました。

動いたものを見ながら、次に何を整えるかを決める。 3日目は、そんな作業を繰り返した一日でした。