なぜアプリを作り込む前に、サービス紹介ページのキャッチコピーにこだわるのか

「価値が何かはちゃんと伝えるべきです」

開発中の会話を読み返すと、2日目の始まりに、僕はそんなことを言っていました。

1日目は、深夜の「GPTsの代わりになるものを、自分でつくればいいじゃん」から始まりました。AIをつくる。教材を入れる。共有する。質問に答える。自分のカードで決済する。その一連の流れを、なんとか本番で動かすところまで進めた日です。

でも、動くようになったアプリをもう一度見たら、別のことが気になり始めました。

これ、誰のためのアプリなのか、ちゃんと伝わっているだろうか。

見た目を整えるうちに、一番言いたかったことが薄くなっている。管理画面はできたけれど、毎回開くには遅い。記事は書けるけれど、何を読んでもらい、その先で何を試してほしいのか。

2日目は、そのあたりを一つずつ直していく日になりました。

ロゴを何度も変え、管理画面を表に戻し、検索されている言葉を調べ、講座運営者向けのガイドを12本つくる。会社サイトやAI Crewのサイトからもアプリへ来られるようにする。そして、記事を並べた後に「この二つは一緒に置かない方がいい」と、入口まで分け直しました。

この記事で振り返るのは、2026年9月11日未明から、その日の夜までです。1日目の最後に触れた料金・運営画面の続きも含みます。きっちり次の24時間を連続で開発したという意味ではなく、日付をまたいだ作業を、その後の改善としてまとめています。

1. きれいになった。でも、一番伝えたかったことは？

日付が変わってしばらくしたころ、Codexに、トップページの第一稿をもう一度見せてもらいました。

最初の文章と、何度も直した今の文章で、内容が結構変わっていたからです。

初期の文章にあったのは、GPTsやGemsで自分のAIをつくれず困っている人へ、分身AIをつくって受講生やチームに渡せる、という話でした。

一方、見た目を整える過程では、「あなたらしさ」「得意にもう一つの形」といった、柔らかい表現が前に出てきていた。

柔らかい雰囲気はいい。でも、それだけだと、何ができるのか分からない。

僕が伝えたかったのは、自分の教材や考え方を知っている分身が、受講生の質問に答えてくれることです。「自分らしいAIをつくれる」の、その先にある使い道でした。

そこで、「講座のあとも、あなたの分身が質問に答える」という説明へ戻しました。対象も「講師・クリエイター」から「講師・講座運営者」へ。少しの言い換えですが、誰が、どんな場面で使うのかが具体的になります。

右側のプレビューも、キャラクターを見せるだけでなく、分身が質問に返事をするチャットにしました。講座、発信、コーチングの会話例を切り替え、ページを開いた人が使い道を想像できるようにしています。

最初は切り替わること自体に気づかなかったので、自動で変わるように。今度は速すぎたので、3秒間隔へ。下に並ぶ用途の説明も、会話例と色・キャラクターを揃えました。

直した場所を並べると、「誰の何に役立つか」を戻していたことが分かります。

見直したところ	変更前	変更後
トップの説明	あなたらしさ・得意の表現が中心	講座後の質問に分身が答える
対象の呼び方	講師・クリエイター	講師・講座運営者
右側のプレビュー	キャラクターを見せる	用途ごとの質問と返事を見せる

さらに、教材から分身へ、受講生から分身へ質問、分身から受講生へ回答、という図を入れました。ここも一度では決まらず、「質問と回答の矢印がちゃんと相手まで伸びている方が分かりやすい」と修正しています。

第一稿を見直すのは、後戻りのようにも見えます。でも、今回は、最初にあった大事な意図を取り戻す作業でした。

2. 動かすと楽しい。動かしすぎると、うるさい

チャットの会話例が自動で変わるのは、使い道が伝わるのでよかった。

では、下に並ぶ3体のキャラクターも、スクロールやマウスを重ねたときにブルンブルン動かしてみたらどうか。そう頼んで、実際に入れてもらいました。

見てみたら、ちょっとうるさい。

すぐに、そこは外してもらいました。

チャットの枠も同じです。少し浮いたように見せたい。前の収まりのよさは残したい。でも、斜めにすると文字が読みにくい。まっすぐにすると、今度は重く感じる。

「むずいですね」と言いながら配置を変え、最後は枠を水平に戻しています。

1日目にもデザインで迷いましたが、2日目も普通に迷っています。AIに頼めば、一瞬で自分の好みが言語化されるわけではありません。

ただ、頼んだものを実物で見て、「これは合う」「これは違う」と判断できるまでが速い。その速さがあるから、試してから外せる。

会話が切り替わる動きには意味がある。読みたいものの周りで揺れ続ける動きは、邪魔になることもある。 同じアニメーションでも、置く場所と役割で受け取り方が変わりました。

試した見せ方	実物を見た感想	最終形
会話例の自動切り替え	使い道は伝わるが、速すぎる	3秒間隔に調整
3体のキャラクターを揺らす	動きがうるさい	外す
チャットの枠を斜めにする	文字が読みにくい	水平に戻す

FAQには、「受講生の会話履歴を、AIをつくった講師は見られるのか」という質問も追加しました。答えは、講師でも利用者の会話本文は見られない設計です。機能として分離していても、使う前の疑問に答えていなければ伝わりません。

「ナレッジ」という言葉も、教材や資料をAIに添える説明の中へ入れました。やさしい表現にすることと、これから使う画面の用語を知ってもらうこと。その両方が必要でした。

3. ロゴを何案も出した末に、目の前のキャラクターを選んだ

ロゴも、かなり往復しました。

最初の星のようなマークは、Geminiと紛らわしく見えるのが気になっていました。このアプリらしい、チャットや分身が伝わるマークにしたい。

まず、二重のチャットをイメージした案をつくり、実際のヘッダーに置いて比較。B案を選び、サイトやファビコンへ反映し、他でも使える画像として書き出しました。

ところが、使ってみると、しっくりこない。

次はシンプルな案、立方体とプラスの案。これも一度採用しましたが、まだ違う。そこで、方向の違う10案、さらにチャットアイコンを重ねた10案まで出してもらいました。

その後で、僕が言ったのが、これです。

いっそのこと、このメインキャラクターをロゴマークにしてみる？

結局、選んだのは、すでにサイトにいた紫のキャラクターの全身でした。

画像を拡大 ↗

新しい記号を足すより、このアプリの中ですでに動いているキャラクターを、そのまま顔にする。その方が、ようやく納得できました。

採用後はヘッダーだけでなく、ブログ、ファビコン、スマホ用アイコンまで揃えました。星形のモチーフも、ロゴだけ外して終わりにせず、画面やブログ画像まで確認しています。

ここで決めたのは、見た目とブランドの方針です。他社との法的な問題が解消されたとか、商標登録が完了した、という話ではありません。

4. 管理画面は「運営するのがうれしい」と「読める」を両立したい

運営画面には、少しコックピットのようなワクワク感が欲しくなりました。

これは受講生に見せる画面ではなく、僕がアプリの状況を見る場所です。「このサービスを運営しているんだ」と感じられる画面にしたかった。

ただ、色付きの背景を増やしたら、見づらくなりました。そこで白を基調としたシンプルな配色へ戻しました。文字も小さく、薄いグレーが多かったので、大きさと濃さを調整しています。

課金ダッシュボードも、一度カード中心の見せ方に変わったのですが、契約を見比べるには前の表の方がよかった。そこで、プランと契約の一覧は表へ戻しました。

見たい情報は、同じ時点の契約や、次回の変更予定です。横に並べて比較したいものまで、それぞれ大きなカードにすると、かえって追いにくい。

ワクワクすることと、情報を探さず読めることは、両方欲しい。 ここでも、装飾を増やすだけでは解決しませんでした。

遅さの原因は、画面の色ではなかった

メニューを一つ押すたびに、表示を待つのも気になっていました。

調べると、待ち時間には三つの要因がありました。画面の色を変えても、ここは速くなりません。

調べたところ	変更前	変えたこと
処理とデータの場所	管理画面の処理は米国、DBは東京	処理先も東京へ揃える
認証の確認	同じ画面の中で何度も確認	その画面内の重複をまとめる
データ取得	独立した集計と一覧も順番待ち	同時に取得する

毎日開く画面なので、見た目の好みと別に、待ち時間も確かめたいところです。

確認したのは、ユーザー分析・課金・サポート・概要を3周する、同じ操作です。

同じ4メニューを3周した計測	変更前	変更後
計測した操作数	12回	12回
表示までの平均待ち時間	約2.32秒	約1.08秒

操作ごとの待機判定や通信の揺れを含む、12回ずつの比較です。すべての画面が常に1秒で開くという意味ではなく、初回には約2秒の待ちも残っています。

5. 料金を変えたら、利用者の画面だけ直しても終わらない

1日目の最後には、3段階の料金と、使うほど減る利用枠、繰り越しやプラン変更を入れました。

その続きを見ていて、管理側の課金ダッシュボードが新しい仕様に追いついていないことに気づきました。「もっとトータルで全件チェックした方がいい」と伝え、関係する経路を洗い直しています。

見つかったのは、例えばこんな漏れです。

漏れていた場所	見つかったこと
管理画面	当月分・繰り越し分・次回変更予定が十分に見えない
利用の集計	編集中のプレビューが通常のチャット利用に混ざる
通知メール	下位プランへの変更予約・取消の案内が足りない
問い合わせ・初期設定	契約情報に古い形式が残る

料金表の数字を変えると、契約処理だけでなく、通知、問い合わせ、分析、運営画面まで関係します。使う人から見た一つの変更が、裏側ではいくつもの場所につながっていました。

監査では14ファイル・82テストを通し、検証用の契約を使って、画面の集計とデータベースの値も照合しました。本番の表示や実際のプレビューまで確認しています。

料金を変えるときには、申込む人だけでなく、その後の問い合わせを受ける自分も困らないかを見る必要がありました。

同じころ、利用人数や使い方を変えて、運営費の試算もしました。AIは使われるほど費用がかかるので、契約が増えたら売上が増える、だけでは見切れません。たまに使う人が多い場合と、毎日よく使う人が多い場合を分けて考えています。

考え方の土台は、「毎月の固定費 ÷ 1契約から固定費に回せる額」。端数を切り上げた数が、固定費をまかなうのに必要な契約数です。式の中で見るお金も分けました。

式に入れるもの	どう見るか
毎月の固定費	契約数にかかわらず、毎月かかる費用
1契約の月額料金	プランごとに分けて見る
1契約にかかる費用	決済手数料・AI利用料・契約ごとに増える費用
固定費に回せる額	月額料金から、上の1契約にかかる費用を引く

税の扱いと集計期間を揃え、固定費に回せる額が0以下なら、契約を増やす前に料金や提供範囲を見直します。

式そのものは中小機構の損益分岐点の解説にもある考え方です。ただ、今はAIが平均してどれだけ使われるかが分からない。だから、ひとつの予想だけで安心せず、使い方を変えて試算しました。初期費用をいつ回収するか、翌月に繰り越された利用枠の費用を払えるかも別に見ます。

この日にしたのは、続けられる条件を仮定で確かめるところまで。実際の契約数や収支が、その通りになったという話ではありません。

6. 最初の日記を書くことも、2日目の開発だった

この日、1日目の開発記録を公開しました。

アプリ本体はNext.jsですが、ブログにはAstroを使い、同じサイトの中で読めるようにしています。記事はMarkdownで保存し、公開時にHTMLを生成して、既存の配布先へ一緒に載せる構成です。

現在の原稿フォルダから、この2本の置き場所を抜き出すと、こうなっています。

blog/src/content/
└─ posts/
   ├─ first-24-hours.md
   └─ day-two.md

このMarkdownが書き直す原稿で、公開用のHTMLは public/blog/ に生成されます。原稿と公開するファイルを分けた構成です。

最初に頼んだのは、深夜の思いつきから約24時間でやったことを、この会話だけでなく、別タスクやアーカイブ、Gitの履歴まで見て書くことでした。

自分が読み返したときに、「ああ、こんなことをやっていた」と思い出したい。気持ちや意図も残したい。でも、それだけでなく、Vibe Codingで、どこまでの仕事ができるのかも伝えたい。

だから、文字だけの記事にはしませんでした。

本人の投稿画像や顔写真を使い、サムネイルをつくる。アプリの構成、教材が回答になる仕組み、決済の確認を図解する。「何をチェックしたか」も本文に入れる。

開発日記は、画面をつくって終わる話になりやすい。でも実際には、届くメールや壊れたPDF、権限や契約の状態まで直している。その部分も、ちゃんと見える形にしたかったんです。

一方で、ブログの入口をアプリの上部メニューへ大きく置く必要はありませんでした。使いたい人の邪魔にならないよう、フッターの運営会社の次へ。ここも「右隣に固定する」という意味ではなく、ほかの項目と同じように並べる位置づけへ直しました。

記事を書くことと、それをアプリのどこに置くか。最初の日記から、両方を考えていました。

7. 夕方は、検索している人の言葉を調べた

夕方以降は、必要な人に見つけてもらうための入口づくりが中心になりました。

その前に、もう一台のMacにもリポジトリを入れました。依存関係を入れ、ビルドを通し、トップやブログが開くところまで確認しています。ただ、この時点では接続設定の移行が残っていて、そのMacでログインやAIとの会話まで試せたわけではありません。

同じGitの履歴を持ってきても、すぐに全部が動くとは限らない。それでも、夕方からのサイトや記事の改善は、こちらのMacでも進めていきました。

まず、トップページの検索向けタイトルと説明文に、GPTs・Gemsの代替を探している人へ、AIをつくって共有できる用途が伝わる表現を加えました。

そのうえで、記事のテーマを決めるために、Google広告のキーワードプランナーで関連する140語を調べています。

作り方、無料で使える範囲、共有、ナレッジ、使えないときの対処、代替の選び方。「GPTs」だけでなく「Gem」「Gems」や日本語表記も含めました。

ところが、広く候補を出すと、Gemには宝石など別の意味も混ざる。言葉の表記が同じでも、このアプリの読者が調べていることとは限りません。

そこで、AIに関する意図が明確な語を選んで、調べ直しました。

取得できたのは、正確な検索件数ではなく、一定期間の平均を示すレンジです。数字が表示されない項目もあり、それを「誰も検索していない」とは扱いませんでした。9月の変化を、その前の期間の平均だけで説明することもできません。

検索されている言葉は、記事の中へ詰め込む材料というより、読者が何に困っているかを知る手がかりでした。

140語それぞれにページをつくるのではなく、同じ疑問を持つ言葉をまとめて、12本の記事へ割り当てました。

8. 12本書いた。でも、一般的な解説だけでは足りなかった

最初にできたのは、GPTsやGemの作り方、料金・利用条件、共有、指示、教材、代わりになるアプリなどの原稿でした。記事ごとの専用画像も用意しています。

19時台には12本が揃いましたが、まだ下書きのままです。公開前に僕が気になったのは、一度に出していいのか、ということ。そして、もっと根本的には、中身でした。

やっぱり一次情報がないと意味がないので

そう伝え、Discordや会員サイトに残っている自分の経験を、講座運営者向けの切り口で入れ直すことにしました。

このアプリを使ってほしいのは、受講生へ自分の知識を届けたい講師や講座運営者です。それなら、一般的な機能説明だけでなく、僕が講座の中でAIをつくり、更新し、渡してきた経験を入れたい。

僕の過去の投稿や、教材・配布ガイドの記録まで遡り、12本を改訂しました。

例えば、次のような話を足しました。

もともとの解説	講座で使ってきた経験から足したこと
教材をAIに添付する	教材を追加・更新したら、AI側のナレッジも更新する
AIへの指示をつくる	古いツールの前提が残っていないか見る
質問に答えるAIをつくる	ゴール・聞く順番・整理の仕方・終わり方を決める
共有リンクを渡す	用途・最初の入力・一区切りの目安も添える

講座の中で案内しやすいか、受け取った人が使い始められるか。実際に配る側の論点を、一般的な機能説明の先へ入れています。

会員向け教材をそのまま公開することとも違います。公開前のレビューで、教材の具体的な内訳は外し、「教材に合わせてAIも更新した」という経験を残す形へ直しました。

ただし、GPTsでの経験を、そのまま「Gemでも実際に運用して成果が出た」という話にはしていません。試した記録のあることと、それを応用した設計案は分けました。利用条件についても、確認できていない範囲は明記しています。

記事から先の流れも、全部を「だから乗り換えましょう」にはしませんでした。FAQを整理するだけで足りる場合もあるし、今使っているツールで条件を満たせる場合もある。そのうえで専用AIが役立つなら、教材1本で試作し、少人数で確かめる。

記事を読み終えた人が、自分の講座で次に何をすればいいか分かる。 そこまでつながる内容にしてから、12本を公開しました。

20時台の改訂でも、まだ公開はしていません。残っていた利用条件の確認を進め、21時過ぎに「ブログ全部公開しよう」と伝えました。原稿が12本できた時刻と、読める形で公開した時刻は、同じではありませんでした。

画像を拡大 ↗

9. 記事を公開することと、検索で見つかることは別だった

検索とアクセスの確認も、既存の会社サイトやAI Crewの構成と比べながら整えました。

1日目にGA4の計測は入れていましたが、それだけで、検索実績までまとめて取得できるわけではありません。

Search Consoleでサイトの所有権を確認し、サイトマップを登録。GA4との関連付けも進め、共通のツールから検索やアクセスのデータを取得できるようにしました。Bingへの登録と、更新したURLを知らせるIndexNowも接続しています。

役割を整理すると、こうなります。

確かめたいこと	主に使うもの
どんな検索で表示され、クリックされたか	Search Console
公開ページのどこへ来て、何を読んだか	GA4
登録後、AI作成や初回チャットまで進めたか	既存のPostHog
検索エンジンへページの存在・更新を伝える	サイトマップ、IndexNow

接続の途中では、AIがGA4のAPIも使えると返した後で、「管理画面では受信を確認できたが、APIには権限が足りなかった」と訂正する場面もありました。計測タグがあることと、外からデータを読めることは別です。最終的には必要な権限を揃え、日別・ページ別の結果を実際に取得できるところまで確認しました。

公開するページと、検索に出すべきでない画面も分けました。会話・共有・管理画面などには検索除外の設定を付け、本番の応答を確認しました。これは検索への指示であり、会話を守る認証やアクセス権限の代わりにはなりません。

当日の確認結果も、一つの「公開できた」にまとめずに見ました。

確認した対象	2日目の結果
Search Console・GA4のAPI	必要な権限を揃え、結果を取得できた
トップページ	Googleへの登録を確認できた
新しく公開した比較記事	URL検査では、まだGoogleに知られていなかった
検索流入・利用者の増加	この日の記録では成果を確認できていない

サイトマップの送信が成功しても、全部の記事が検索に載ったわけではない。検索結果に載っても、必要な人が来て、使ってくれるかは、また別です。

10. 会社・講座・個人サイトから、アプリへつなぐ

検索から来てもらう道をつくる一方で、すでに僕や会社、AI Crewを知っている人への案内も進めました。

変更したのは、アプリ本体だけではありません。

紹介する場所	置いた案内
会社サイト	事業内容とフッターからアプリへリンク
AI Crewのサイト	講師紹介の後に、本人の開発実践を伝える特集
個人サイト	アプリの紹介と、追従ナビゲーションからの入口

AI Crewでの紹介は、最初の案から主題を変えました。

「AI Crewの運営会社がつくるサービス」という見せ方に、僕は違和感がありました。会社を主語にするより、教えている本人が何を実践しているかを伝えたい。

ここで伝えたかったのは、ただ「新しいサービスをつくりました」という宣伝ではありません。教えている本人が、今も実際に開発し、運営し、その過程で得た知識を教材やサポートへ戻していくことです。

紹介の見出しも、「教える本人が、開発の最前線に。」へ。

AIチャットつくーるは、その実践の一例です。実際につくっているから、うまくいくところだけでなく、途中で困ることも分かる。その経験を、教える内容へつなげていきたい。

ただし、この日に得たノウハウが、もうすべて教材へ収録されたという意味ではありません。ここでは、開発を続けながら学びを還元する姿勢を伝えています。

紹介に使うキャラクター画像は、アプリ側の公式素材を直接参照する形にしました。各サイトへ別々にコピーすると、ロゴを変えたときに更新漏れが出るからです。

同じアプリでも、会社の事業を見に来る人と、講座で何を学べるか知りたい人では、気になることが違います。同じ紹介文を3か所へ貼るのではなく、その場所で伝える意味を考えました。

会社サイトは、夜の後半にもう一往復ありました。4つの事業を、大きな画像と説明で一つずつ見せる構成へ変更。でも、AIチャットつくーるの紹介がしっくりこなくて、「ホームページのファーストビューをそのまま載せてもいいぐらい」と伝えました。

実際のトップ画面を一度は掲載したものの、今度は4枚を並べたときの統一感が気になる。まず大きさを4対3に揃え、その後、タイトルの位置も揃えることにしました。

僕が「トップページのスクショ」って言ったけど、他のやつと合わせたほうがいいかもしれないですね。

23時台の会話に、そんな方向転換が残っています。最終的には、スクリーンショットから、公式キャラクターと「講座の教材をもとに質問へ答える」会話のイメージへ変更しました。

一枚だけ見ればよくても、四枚並べたら合わないことがある。自分が頼んだ案でも、実物を見たら変えていい。ここでも、最初に言った通りにつくってもらうことより、最後にどう伝わるかを見ていました。

案内文だけでなく、ホームページそのものも自分でつくり、仕事に合わせて直せるようになりたいなら、AI Crewで、Claude Code・Codexを使った制作を学べます。自分の事業で必要なものを題材に、手を動かしていきます。

この日に確かめたのは、3サイトからアプリへ進めることまでです。そこから何人が使い始めたかは、これから見ていきます。

11. 「使い方を知りたい人」と「開発の裏側を読みたい人」を分けた

12本のガイドを公開すると、ブログには、最初の開発記録と、検索から来る人向けの記事が並びました。

そこでまた、違和感が出てきました。

GPTsの共有方法を知りたい人と、僕が深夜に何を考えながらつくったのかを読みたい人。同じアプリに興味はあっても、今読みたいものが違います。

そのため、二つの入口を独立させました。

入口	読む内容	並べ方
AIチャット活用ガイド	選び方・設計・教材・共有・困ったときの対処	目的別
開発の記録	技術の仕組み・検証と、着想・迷い・判断の経緯	日付順

9月11日時点の媒体名は「AIチャット活用ガイド」と「開発ノート」です。入口を分ける際には、一覧だけでなく、記事から戻る先、媒体名、RSS、サムネイルのラベルまで揃えました。

一方で、すでに公開した記事のURLは維持しています。場所の整理のために、既存のリンクが使えなくなることは避けたかったからです。

ガイドの12本は、「知る・選ぶ」「設計して、つくる」「共有して、運用する」「困ったときに」の4つに分類しました。

ここでも、並べてみて終わりにはなりませんでした。

まず、1〜4の章タイトルを枠で囲ってほしいと伝えたら、上のメニューまで大きく変わってしまいました。「その下のタイトルの見せ方だけの話をしてた」と伝え、上部は元に戻すことに。

見出しだけを直しても、まだ区切りが弱い。サムネイルの雰囲気が似ていて、どこから次のまとまりなのかが分からなかったからです。

その後、章タイトルの文字組みを調整し、各章と記事群を薄紫・薄緑・薄青・薄橙の背景でまとめ、間に余白を入れました。タイトルだけ囲うより、記事を含めた一つのまとまりが見えるようになりました。

分類がデータ上で正しくても、読者の目に区切りが見えなければ、まだ整理しきれていない。 記事が増えて初めて、気になる場所が変わってきました。

12. 最後に直していたのは、枠の余白とリンクだった

夜の後半の履歴を見ると、変更はどんどん細かくなっていきます。

記事の画像やタイトルだけでなく、説明文や余白を含めて、カードの枠全体を押せるようにしました。キーボードでも、1枚のカードに一度フォーカスして、そのまま記事を開けるようにしています。

トップページのFAQの下には、活用ガイドと開発の記録を案内する二つの枠を追加しました。フッターだけでなく、アプリについて読んだ流れで、その先の記事も見つけられるように。

外部サイトへのリンクは、新しいタブで開くように揃えました。プライバシーポリシーや参考資料を確認しても、元のアプリの画面が残るようにするためです。

そして、ガイドの最後には、ナレッジのつくり方への案内を置きました。最初の「試作に使う資料は」という言い方が少しずれて感じられたので、AIをつくるときに添付するナレッジを準備する話だと分かる文へ変更。「ナレッジのつくり方」の部分だけをテキストリンクにしました。

どれも、機能一覧では目立ちにくい変更です。でも、読む人が「ここを押せばいい」「次はこれを準備するんだ」と迷わず進めるかどうかは、この細かい部分に出ます。

13. 2日目にできたこと。まだ、分からないこと

朝方は、説明やロゴ、管理画面を何度も見直す。夕方からは、検索の言葉を調べ、記事を書き、3つのサイトから案内する。夜は、並べた記事の入口や余白を直していました。

時刻は日本時間で、主に変更履歴や確認の記録が残った時間帯です。

時間帯	進めたこと
未明0〜1時台	料金変更の全件監査、運営画面の読みやすさと速度、ロゴの比較・採用、最初の開発記録、トップの訴求と会話プレビュー
17時台〜18時初め	もう一台のMacへリポジトリを導入し、ビルド・公開ページのローカル表示を確認。ログイン・AI会話はこの時点では未確認
18時台	検索向けタイトル・説明文の更新、140語の検索需要調査と記事への割り当て
19〜20時台	12本の原稿・画像、検索と計測の接続、関連3サイトからの紹介、講座運営の経験を踏まえた原稿の改訂
21時台	12本のガイドを公開、Search Console・GA4のAPI取得と本番導線を確認
22〜23時台	活用ガイドと開発記録の分離、分類と見出しの調整、カード全体のリンク、トップの案内、ナレッジへの導線。会社サイトの4事業の見せ方と紹介画像も再調整

2日目は、大きな新機能を次々に積み上げた、というだけの日ではありませんでした。

つくったAIで何ができるのかを、文章と会話例で伝える。運営する自分が、状況を読み取れるようにする。困って検索した人が、講座の中で何を試せばいいか分かる記事を用意する。僕をすでに知っている人には、今やっている開発の意味を伝える。

その入口をつくり、並べ、使ってみて、また直していました。

一方で、この日の記録から、検索流入が増えたとか、有料利用が伸びたとか、受講生の学びが改善したとは、まだ言えません。検索に知らせる仕組みができたことと、必要な人へ届いたことは別です。

一般向けの有料受付や商標についても、トップの文言やロゴを変えたことだけで、手続きや判断まで完了したことにはなりません。当日の記録と、現在のサービスの案内は分けて見ています。

それでも、1日目に「自分で試せるもの」になったアプリが、2日目には「どんな人に、どう使ってほしいか」を伝える場所を持ち始めました。

Codexに任せたのは、コードを書くことだけではありません。履歴を読み直す、検索需要を調べる、原稿と画像をつくる、別サイトを更新する、公開した画面を操作して確かめる。その間、僕は実物を見て、価値がずれていないか、読めるか、使いたくなるかを伝えていました。

そして、「これは違ったから戻そう」も、何度も言いました。

つくるのが速くなると、つくった後に考えられることが増える。 2日目の履歴を振り返ると、そんな一日だったように思います。

1日目は、思いついたものを動かす日。

2日目は、そのアプリを必要な人へ届けるために、入口をつくる日でした。

---

2026年9月12日、日記の流れと技術の解説・図解・検証内容を保ち、判断の理由と採算を考えた経緯が伝わるよう本文を改訂しました。この記事は2026年9月11日の開発記録です。2台のパソコンに残る開発者本人の会話と、本体・関連3サイトのGit、実装・検証記録を照合してCodexが構成・執筆しました。別の日にまたがる改善は本文で区別し、現在の仕様・料金・受付状況はサービスの案内をご確認ください。表紙は当時のトップページの保存画像をもとにAIで構成し、星形の装飾を除いています。ガイドの図解はAI生成です。測定値は記載した当時の条件での確認結果であり、検索流入や事業成果を示すものではありません。