Creators Log の記録アーカイブ

過去のデータと合わせて事業モデリングできるだけの数値情報が貯まり、タイミングを見て一気に資金投下できる状況となったため。初回更新が2件生まれた今は、参加してくれた人のその後の動きを見守りたいためです。

まずは浮かれずに足場を固めます。監査で見つかった安全性の問題について、開発基盤の更新と、重大な問題を見逃さない自動検査の修正範囲を確認する。

黒背景と白背景のX広告が同時配信された区間を24時間観測し、クリック率・クリック単価と登録以降の動きを確認する。

広告停止後にプロダクトが大きく変わっているため、過去との単純比較ではなく、現在版Creators Logで新しい人がどこまで進むかを新しい基準線として測るためです。

広告開始から24時間後に、黒背景と白背景の配信実績と、登録以降の動きを確認する。

トップページ全体を大きく作り替えると必要以上に複雑になりそうだったため、まずは他のクリエイターのプロジェクトを見せることと、横に流れる表示へ変えることだけに絞りました。

日本語表現をさらに自然にした更新用プロンプトを確認し、問題がなければ本番へ反映する。

広告を止めてから、公開画面、多言語化、制作履歴、交流や依頼の導線など、多数の実装を重ねています。そのため過去の広告実績だけでは現在の体験を正しく評価できず、まず訪れたくなる見せ方へ改修したうえで、新しい利用データを取り直す必要があると判断しました。

明るいテーマでもトップページの星や線が消えず、暗い部分だけが不自然に残らない状態へ仕上げ、試験画面で確認してから本番へ反映する。

翻訳文を本人が直せる機能を先に作っても英語で読める範囲そのものは増えないため、まず制作履歴まで英語だけで追える状態を優先しました。

制作履歴の英語表示を本番へ反映し、バックアップと最新原文の再照合後に636件を取り込み、英語だけで履歴を追えるか確認する。

初回だけ必要な既存データの英訳を5分に1件ずつ処理し続けるより、公開情報だけを安全にまとめて翻訳し、反映直前に公開状態と原文が変わっていないことを再確認する方が、速さと安全性を両立できると判断したためです。

追加した54項目を一括翻訳し、英語だけでクリエイター・プロジェクトの基本内容を理解できる状態になったか確認してから本番へ反映する。

メニューや見出しだけ英語になっても、Creatorが何者で、何を作り、なぜ作り、今どこまで進んでいるのかを読めなければ意味が薄いと感じたため、ページの中身まで英語だけで理解できることを多言語化の完成条件にしています。

Creator・Projectの主要な内容を本番で翻訳し、その状態で英語だけでは理解できない部分を洗い出して、追加で翻訳する範囲を決める。

Creators Logの価値はメニューの翻訳ではなく、何を作り、どう判断し、どこまで進んだかを第三者が理解できることにあるためです。また、その履歴が企業の発注前の選定・発注中の確認・発注後の実績として繰り返し使えれば、制作記録そのものが取引を生む可能性があると考えました。

Codexの言語タブ修正結果を受け取り、Previewで上部の日本語／English切替と既存画面への影響を確認する。

Projectには既に、探している相手の設定、公開デモやテストサイトへのリンク、コメント、協力の申し出と会話、仕事依頼、Wall Meeting、Creator Supportがあります。似た機能を重ねるより、今ある入口が実際に使われるかを見る方がよいと判断しました。

公開Creator・Project・更新を日本語と英語で安全に読めるようにするため、URLの持ち方、翻訳する範囲、原文との関係、検索、費用、公開範囲を確認する。

アプリ、ゲーム、音楽、物販では、売り方や権利の扱いがそれぞれ違うので、すべてを一つの決済機能で扱おうとすると、Projectごとの対応が増え続ける。分野が違っても共通して作れそうなのは、制作履歴、翻訳、信頼を判断する材料、外部の人が次の行動へ進む入口までだと考えました。

何でも売れる仕組みは作らないという方針を含めてロードマップを最終判断し、採用する場合だけ、今ある機能のどこを再利用できるか確認する。

今ある応援・相談の手数料だけでは成長余地が小さいため、「もし100億円作るならどうするか？」という地点から逆算して、事業モデルそのものを再検討しています。

組織向けのProject履歴基盤や、企業向けのProject発見基盤というモデルなども考慮・検証しつつ、実際に採用する事業モデルを決める。

これ以上機能を足すより、まず実際の利用者同士で投稿や返信が生まれる状態に進めることにしました。

登録ユーザー全体へ「みんなのリアル」の公開を知らせられるよう、運営お知らせの対象範囲を広げて告知を掲載する。

見るだけの人に制作開始を求めず、交流を始める時だけプロフィール設定を求める方が自然だと判断したためです。

GitHubの復旧後、投稿メニューの修正から順に公開前の改善を反映する。

更新内容を隠すと何が変わったのか分からず、「プロジェクト更新の墓場」に見えました。また、ここでは更新以外の雑談や会話も生まれるはずなので、「みんなの更新」より「みんなのリアル」の方が合うと感じています。

すべてのプロジェクト更新に何が変わったか分かる一文を表示し、投稿枠全体から詳細へ進めるようにして、見出しを「みんなのリアル」へ変更する。

Project更新だけを並べると「更新という名の文字の墓場」に見え、みんなの人柄や考え方などが伝わらず、会話も生まれにくいと感じたためです。

タイムラインのUI/UX向上と、投稿へのいいね・返信・メンション・通知までつないだうえで、全体公開前の実機確認を行う。

迷わず使えて、Projectの更新が利用者へ届きやすい状態にするためです。

協業・支援の連絡機能を、条件を満たす全Projectへ広げる。

機能を増やしても、更新や新しい動きが利用者に届かなければ、戻ってくるきっかけが生まれない。Projectを進める機能だけでなく、人が集まり、会話し、関係が続く仕組みが必要だと考えました。

日次の更新通知と将来の週間ダイジェストが必要な利用者に届くように、同意と配信設定の仕組みを整理する。

Needを表示しても、外部の人がその場で行動できなければ発見導線を整える意味が薄いと考えました。また実機確認で、資金面の申し出画面がCreator側の主語になっていて自分でも離脱し、Owner自身が外部からの見え方を確認できない問題も分かりました。

Ownerログイン状態で「公開時の見え方」を実機確認し、実際の外部表示と一致しているかを検収する。

最初の実装は選択肢や説明が多く、的外れな提案まで表示されて不快でした。外部へ公開され、実際の行動につながることに意味があるため、本人が選んだ一件だけをそのまま表示する形へ絞りました。

公開ページの募集表示を進捗記録の直前へ移し、モバイルの表示を少し小さくしたうえで、適切な既存導線がある場合だけ行動ボタンを表示する。

公開画面だけでは、資金調達や本格的な事業化への意向までは分かりません。そこで、公開情報だけで次の行動を決めず、プロジェクトが今つまずいている点と、本人が望んでいることの両方を確認する仕組みにしたいと考えました。

各プロジェクトに必要な支援と、クリエイター本人が望む機会を整理し、次に取るべき行動を理由とともに提案する仕組みの設計をまとめる。

プロジェクト更新を続ける楽しみを提供しつつ、AIへ送る情報の範囲などを整えた上で開放すべきと判断したため。

細かな作業を一度止める。 「企業や支援者などが見たい情報は何か」「それをどのように可視化していくか」など、一度大きく俯瞰して、全体戦略から考えて動く。

キャラクターが自然にコメントしてくれるかどうか。

右下の小さな表示では流してしまい、汎用的な台詞や外から講評するような口調では、更新後の反応として弱かったためです。表示の速さだけでなく、内容と表現の正確さを優先して調整しました。

Ownerとして意味のある公開更新を1回行い、具体的な内容、キャラクターらしさのある口調、表情の一致を確認する。

日々の更新作業は地味になりがち。すぐに反応を返してくれるキャラクターの存在が、更新行動に影響を与えるかどうか。まずは試験的に検証から進める。

Owner限定で本番環境まで反映し、手動更新とAI更新を各1回行って、台詞・表情・表示方法などを確認する。

もう十分やったと判断し、一般公開へ進めることにしました。

トップページやXで内容は伝わっているため、登録画面を大きな説明ページにせず、「新規登録」とサービスの種類だけを短く補う方がいいと判断しました。

登録開始ページの変更後、signup_viewからsignup_submitへの転換率を観測する。

見つけやすさの改善に加え、実際に仕事を依頼したり、仕事を受けれるように導線などを整備しました。

仕事の依頼は届いても返信できない状態となっていたため、先んじて手を打つ必要があると判断しました。

これまでに多数の実装を進めてきているので、各種追加した機能周りの効果測定を実施し、PCDAを早める。

新しい機能を増やすより、記録した内容が伝わり、人を招き、次のCreatorやProjectを見つけられる流れを優先しています。

更新内容と理由が履歴の奥へ埋もれ、公開中のCreatorやProjectを名前から探す手段もなかったため。

ExploreにCreatorとProjectを横断するキーワード検索を追加します。

安全条件を満たしたクリエイターが自分で応援受付を始められる形へ進めました。

安全な公開範囲を制御できる基盤が整い、実際の利用へ進められると判断したためです。

プロジェクトやクリエイターの見つけやすさの改善、友だち招待機能の利便性向上などを検討していきます。

これまでPCビューを中心に見ていた関係もあり、モバイルビューの見づらさを再確認したため、応援機能よりも先に修正を入れました。

応援は更新ができて初めて生まれる。そもそもの使いづらさを解消すべきだと判断したため。

モバイル改善が一区切りついたので、応援機能の本格実装を進める。

支払い画面だけでなく、応援後の通知、売上確認、入金予定の確認までを一つの体験として整えました。

実際に使うと、決済できるだけでは足りず、誰に届き、いくら受け取れ、いつ確認できるかまで分かる必要があると気づいたためです。

500円の応援を1件だけ本番で試し、受取額の反映と双方への通知を確認します。

応援は、Projectに対してではなく、クリエイターに対して出来るように仕様変更をかけています。

応援したい対象を突き詰めて考えると、プロジェクトを作り続けている人そのものだと分かったためです。

応援ボタンをクリエイター欄へ設置し、金額選択からStripe画面へと進める新しい導線を本番で確認します。

更新を届ける仕組みに加え、最初の制作ログへ迷わず到達し、その記録がクリエイターの収入につながるところまでを一つの流れとして整えています。

ユーザー体験の向上として、ログがお金になるという体験を早期に実装すべきと判断したため。

応援の実決済を1件通し、クリエイターの受取、管理画面への反映までを確認します。

制作途中のプロジェクトに、応援したいと思うのはどんな場面ですか？

画面内の通知だけでなく、アクセスしていない人にも制作の動きが届く再訪導線を追加しました。

実際のメールでは更新を多く載せるほど読みにくかったため、異なるクリエイターを優先し、本人の更新から確認できる構成にしました。

次回の自動配信で、実データの到達と読みやすさを確認します。

制作更新のメールは、1通に何プロジェクトくらいなら読みやすいですか？

公開ページ周りのアップデート続けて、クリエイター自身が継続して使いやすくなるように管理画面周りのUI/UXを磨きました。

実際に使うと、何が公開中で、何を次に操作すればよいか凄く分かりにくかったため。

PCビューを中心に整備したので、モバイルビューでの主要画面を確認し、見やすさと使いやすさを調整します。

売る導線だけでなく、支援ニーズを拾うことと、外から見た信頼面を整えることを優先しました。

流入や相談導線があっても、何を作っていて何を相談できるのかが伝わらなければ、支援や取引に進みにくいと分かったためです。

広告流入、相談・壁打ちミーティング、クリエイターの困りごとの入力状況を見ながら、次に強める接点を決めます。

この公開ページで、何を作っていて何を相談できるか伝わりますか？

参加人数が増えてきたため、プロジェクト更新時のメール周知は停止しました。 その代わりに、運営からDashboard上でお知らせできる導線を作りました。

X広告が順調に推移しているため、今このタイミングでの変更が必要と判断したためです。

次は、クリエイターが今ほしい支援や困りごとを入力できる導線を設計します。

制作中のプロジェクトで、いま一番ほしい支援は何になりますか？

公開ページに見せる段階から、実際に購入され、相談へ進める段階に進みました。

売れた後に迷子にならないよう、購入者とクリエイターへの通知、問い合わせ導線、運営側の確認画面も整えました。

次は全体の優先順位を整理し、相談メニューを少人数のクリエイターへ段階的に開く条件を決めます。

制作中のプロジェクトを見て、短時間の相談を申し込める導線があると使いやすそうですか？

"実務スキルに応じた有料の相談導線"も検討していましたが、クリエイターごとに「相談・壁打ちmtg」の窓口を設け、導線を一本化する方向で再設計しました。

わかりやすさを重視することで、クリエイター側で収益を上げやすくなると判断したため。

決済を開く前に、注文管理、返金・キャンセル条件、規約表示、日程調整URLの開示方法を確認します。

個別の相談や壁打ちを、自分が「良さそう」と思ったクリエイターに有料で聞いてもらえるとしたら、価値を感じますか？

第一優先として、実ユーザーが詰まった保存・返信・編集・発見面の摩擦を特定して直す判断にしました。

登録後に実際のプロジェクト作成やコメントが始まり、使う中での違和感がプロダクト改善の材料になってきたためです。

iPhoneで入力時に画面が拡大されたまま戻らない問題と、コメント欄の見やすさを実機で確認して直します。

プロジェクトページのコメント欄は、反応や返信を読みやすい場所に見えますか？

マネタイズ導線を広げる前に、ユーザーが増えた後に必要になる運営窓口と法務表示を先に整える判断に変えました。

初期利用者が増え始めたことで、疑問や不具合を受け止める場所、安心して使える表示、管理側の対応導線が必要になったためです。

特定商取引法に基づく表記を整え、有料相談や支援などの導線を本番化できる条件を整理します。

問い合わせ窓口や利用規約があることで、初めて使うときの不安は減りますか？

実機で見つかった導線の崩れや表示の見切れ、遷移の遅さを改善し、一覧から初期データが混ざる問題も取り除きました。

実際に使うと、機能の数より、迷わず移動でき、面白い活動を正しく見つけられることの方が重要だと分かったためです。

終了済みのプロジェクトを活動中の一覧から除外し、発見面の掲載条件を整える。

「探す」ページで、開いてみたいと思うプロジェクトは見つかりますか？

登録者全体ではなく、公開中のクリエイターだけに更新メールを届ける運用へ変更しました。

登録しただけの人へ不要な通知を送らず、活動する人同士の再訪を確かめるためです。

実際の公開更新を1件出し、対象者への送信と受信を確認する。

他のクリエイターの更新通知は、活動を見に戻るきっかけになりそうですか？

機能を増やし続ける段階から、実際のクリエイターを迎え、登録・更新・再訪が起きるかを確かめる段階へ移りました。

記録と相談の仕組みは試験で一周したため、次に確かめるべきことは、使う人が増えたときに記録が継続や新しい機会につながるかどうかだから。

更新通知の限定テストを完了し、初期クリエイター募集を始めて、登録後の行動を観測する。

この説明で、Creators Logを使うと自分に何が返ってくるサービスか伝わりますか？

公開ページを、熱量を直接語る構成から、活動状況、概要、公開中のもの、最近の動き、制作の裏側が静かに伝わる構成へ変更した。

すべての迷いや努力を前面に出すと、初見の人には重く、プロジェクトの魅力より説明の圧が勝つと分かった。深い記録は裏側に蓄積し、必要な断面だけを見せる方が熱量が滲むため。

更新した入力プロンプトを使い、Creators Log・退職診断・My Tiny Worldで新しいSnapshotを作り、異なる種類の挑戦でも公開断面が自然に伝わるか確認する。

このページを見て、最初に気になったのはどの部分ですか？

相談・依頼・取引につなげることを中心に考える方針から、まだ完成していない挑戦の瞬間そのものを記録し、共有することを中心に据えた。進捗だけでなく、何が変わり、なぜそう判断したのかまで残せるようにした。

問題解決や助言は必要になる前に自力で突破できる場合があり、それだけでは継続して使う理由にならない。一方で、完成前の迷い、確信、方向転換をその時点のまま残し、誰かに見届けてもらうことには、完成品の公開とは異なる価値があると分かったため。

Creators Log自身のプロジェクトで最初の公開Snapshotを残し、初見の人にも現在地と挑戦の熱量が伝わるかを実際のページで確認する。

この記録を見て、続きを追いたいと思いますか？

Creators Log自身のログを使って、売れそうな切り口、想定依頼、最初に見せる相手を3つずつ手動で作る。

この説明で、作っている途中が依頼につながるサービスだと伝わりますか？

Creators Log自身の公開ページで、新しい更新文を1本作り、初見の人に挑戦の現在地と応援・関わり方が伝わるかを確かめる。

このページを見て、応援したい・関わってみたいと思いますか？

Claudeの監査結果をもとに、現在の画面・導線・データ構造を「見てほしい問い→外部反応→改善履歴→信頼」のループに照らして棚卸しし、最初に埋めるGAPを1つ決める。

見る人がなぜ反応したくなるのか、その反応がどう改善に使われたと見えると信頼に変わるのか。この体験を最小の導線で成立させられるかを見てほしい。

AIチャットや実装報告などの材料をプロジェクトに追加し、進捗・判断・学び・次アクション・公開候補へ整理できる最小導線を設計する。

AIで複数プロジェクトを進める作り手にとって、「材料を投げれば現在地が整理され、必要な分だけ外に出せる」体験は、継続して使う理由になるか。

PCとiPhone実機でトップページを確認し、Hero、Creators Logを使うメリット、公開範囲、注目プロジェクトの文字が初見でも読めるかを確認する。

「プロセスを残すほど、信頼が広がる。」という訴求で、AIを使って作っている個人が「ここに載せたい」と感じるかを見てほしい。

Creators Log自身の更新を1件反映し、公開ページ上のDecision Logが初見の人にも「何を考え、どこで判断が変わったか」として伝わるかをiPhoneで確認する。

初見のクリエイターが、技術的な作業履歴ではなく、問い・迷い・判断の変化を見て「自分も制作過程を残したい」と感じるかを見てほしい。

最初のクリエイターに使ってもらい、AI更新フローの体験を検証する。

初見のクリエイターが「ここに載せたい」と感じるか。導線のどこで迷うか。