最初から、細かな要件定義はしていませんでした。
まずAIと一緒にアプリをつくる。動くものができたところで、実際に触りながら、一から自分好みにしていく。
2026年9月13日、AIチャットつくーるの開発4日目は、そんな一日でした。3日目に整理した外部サービスや管理機能を土台にして、この日はアプリそのものを一気につくり込んでいきました。
AIをつくる画面は、構成とプレビューを中心に
9月14日に当時のコードを再表示して撮影。表示データはサンプル、画像内容の加工なし。
受講生にAIを渡すとき、どんな文章なら使ってみたくなるか。ゲットした瞬間は、どんな動きと音ならワクワクするか。プランを選ぶ画面では、何をどの順番で見せたいか。
普段の仕事で講座を届け、自分でもいろいろなアプリを使っている。そのときの感覚を、文面、画面、ボタンを押した後の動きまで入れていきました。
何をつくってもらうかに加えて、出てきたものを見て、どこまで自分の好みに近づけるか。 今回は、そのやり取りを具体的に書いてみます。
画像について：比較画像は、9月12日末と9月13日末のコードを、9月14日に同じ画面幅で動かして撮影しました。当日に保存したスクショではなく、当時の画面を再表示したものです。名前・設定・会話・利用枠は撮影用のサンプル。9月14日の本番画面は、その旨を個別に記しています。画像を押すと拡大できます。
1. AIを受け取る瞬間に、ワクワクしてほしい
このアプリでは、講師が自分のAIをつくり、リンクで受講生へ渡せます。
僕が気になったのは、そこで送る文章でした。講座運営者から受講生へ届くものなら、学びを広げる相棒が届いた、と感じてもらえる誘い方にしたい。
そこで、AIの名前とリンクを知らせる文面を見直し、登録された紹介文も使いながら、受講生へAIを届ける招待文へ変えました。
この先の、AIをゲットする瞬間にも演出をつけました。ここは何度もつくり直しています。
最初は、カードを手に入れたときのような楽しさを伝えて、立体的にひっくり返るカードの演出ができました。でも、見てみるとカードの見た目に寄りすぎている。AIの写真を主役にして、背景は白くしたい。
写真が弾み、丸い波紋と色の粒が広がる形へ変えて、次は音です。短い通知音では物足りず、画面の動きに合わせて3〜4秒くらい盛り上がる音をお願いしました。
ところが、長く響く音にすると、今度は鐘のような重い響きになってしまった。欲しいのは、もっと明るく、何かを手に入れた喜びがある音です。
最後は、金管楽器のような明るい5音のファンファーレへ。写真が大きくなる頂点と、最後の音が合うようにしてもらいました。
| 見て・聴いて気になったこと | 僕が伝え直した方向 |
|---|---|
| カードの見た目が強い | 白背景にして、AIの写真を主役にする |
| 音が短く、演出と一緒に盛り上がらない | 3〜4秒ほどの長さで、写真の動きと合わせる |
| 鐘のように重く響く | 明るいファンファーレにして、最後の音と写真の山場を揃える |
「ワクワクする感じ」と伝えるだけでは、いろいろな形が出てきます。動いたものを見て、音を聴いて、欲しい感じをさらに伝える。その繰り返しで、僕の好みに近づいていきました。
招待文からゲットの演出まで、講座でAIを渡す場面としてつなげて考えたところです。
招待の入口から、ゲットして会話を始めるまで
2. 料金画面でも、先に楽しみが伝わる順番にする
アップグレードの画面も、僕の中では同じ話です。
プランを変えたら何ができるようになるのか。それを見て、使ってみたいと思える。その流れでボタンを押せるようにしたい。
最初の画面では、長い説明が先に並び、申し込みのボタンへなかなか届きませんでした。そこで、プラン名、短い紹介、料金、ボタンを先に見せ、特長や詳しい条件を下へ整理してもらいました。
プランの魅力と料金が分かる
↓
使いたいプランのボタンを押す
↓
すぐ「処理中」と表示する
↓
Stripeの決済画面で内容を確認し、申し込むここも、見た目の順番を変えて終わりにはなりませんでした。
一度目の修正では、決済前に請求書の宛名や住所を必ず書く欄が残っていました。必要な人が設定する形にしたかったので、契約管理へ移しています。後から変更した宛名などは、今後発行する請求書に反映する扱いです。
さらに、一覧でアップグレードを押すと、選んだプランの紹介カードがもう一度出てきました。僕は今、そのプランに進もうとして押した。だったら、すぐ処理中になって、決済画面へ進んでほしい。
そこまで伝え直して、新規契約と上位プランへの変更は、一覧のボタンから直接進めるようにしました。料金や契約条件を確かめる表示は、ボタン付近や決済の確定前に残しています。
魅力が伝わる順番と、決めた人がそのまま進める操作。その両方を揃えたかった。 この画面には、僕が届けたいと思う見せ方の感覚を入れています。
PCでは、プランの紹介とボタンが見える位置へ
9月14日に当時のコードを再表示して撮影。表示データはサンプル、画像内容の加工なし。
スマホでも、現在の契約表示をコンパクトに
9月14日に当時のコードを再表示して撮影。表示データはサンプル、画像内容の加工なし。
3. 使い慣れた操作に、自分たちの色を合わせる
チャット画面とAIをつくる画面は、ChatGPTやGPTsのエディターを参考にしました。
チャットの配置や操作感は、普段使っているものに近くていい。AIの作成も、設定しながら隣で会話を試せる構成がいい。そのうえで、背景色や世界観は、自分たちのかわいい雰囲気にしたいと伝えました。
使い慣れた操作と、自分好みの見た目は、両方取り入れられます。
サイドバーの操作を、同じ高さの行へ揃える
9月14日に当時のコードを再表示して撮影。表示データはサンプル、画像内容の加工なし。
もう一つ、何度も伝えたのが、説明文を増やしすぎないことです。
利用状況なら、残りの枠と、いつリセットされるかがすぐ分かってほしい。AIを試すプレビューなら、会話を読む場所を広くしたい。説明を足すたびに、その画面で見たいものが下へ押されてしまいます。
| その画面で見たいもの | 揃えた見せ方 |
|---|---|
| 残りの利用枠 | ゲージと残量を優先し、詳しい説明は開いて読める形にする |
| AIをあと何個つくれるか | 「残り数 / 上限個」を一か所にまとめる |
| 利用枠が戻る日時 | プラン名の下に、リセット日時を表示する |
| プレビューの会話 | 重複する見出しやAI名を減らし、読む場所を広げる |
| 本文と補足 | AI作成画面などの本文を18px、補足を16pxにし、補足の色も濃くする |
途中の本番確認では、幅393px・高さ700pxの画面で、プレビューの会話領域が118pxから432pxへ広がりました。その時点の画面条件での実測で、この後も見出しや入力欄を調整しています。
スマホのプレビューで、すぐ会話を試せる広さへ
9月14日に当時のコードを再表示して撮影。表示データはサンプル、画像内容の加工なし。
この比較は前日末と4日目末の画面です。本文の118px→432pxは、途中の別の変更時点で測った値です。
文字を小さくして全部押し込むより、常に出しておくものを選ぶ。その方が、自分の欲しい画面に近づきました。
一方で、ファイルの容量制限のように、操作する前に知りたいこともあります。これは添付前に確認できる場所へ。説明の量だけでなく、読むタイミングも考えました。
利用状況は、残量とリセット日時を先に
9月14日に当時のコードを再表示して撮影。表示データはサンプル、画像内容の加工なし。
スマホで、残りの枠を一目で見られるように
9月14日に当時のコードを再表示して撮影。表示データはサンプル、画像内容の加工なし。
4. ボタンの名前と、押した後の動きを揃える
AIをつくる画面では、アップロードボタンの動きも伝え直しました。
ファイルを入れようと思って押したのに、その前にAIの保存や入力チェックが始まる。ボタンの文言だけを変えても、この順番は変わりません。
僕は、押したらまずファイルを選びたい。そこで、ファイル選択画面を先に開き、選んだ後に取り込む順番へ変えました。資料をまとめて入れられるよう、ドラッグ＆ドロップにも対応しています。
プロフィール画像も、AIを一度保存してからでなく、最初に選べるようにしました。画面の上に画像の欄があれば、そこから入れていく操作を自然にできるようにしたかったからです。
作成途中の内容は、自動保存にしました。名前や説明、指示を書きながら、別の画面へ移って、また戻って続きをつくれます。
名前・説明・指示などを書いていく
↓
作成者だけの下書きへ自動保存
↓
戻って続きを書き、プレビューで試す
↓
公開すると、利用者向けの設定に反映する書きかけの下書きと、公開中の設定は分けています。編集中に、受講生が使うAIまで少しずつ変わってしまう形にはしませんでした。
会話を開く入口も、押したものから期待する動きへ揃えています。
| 押す場所 | この日の最終的な動き |
|---|---|
| マイAI | そのAIとの新しいチャットを開く |
| 会話履歴 | 選んだ会話の続きを開く |
| 会話のきっかけ | 通常チャットでもプレビューでも、そのまま送信する |
前日の日記では、マイAIを選ぶと最後の会話へ戻る、と書きました。この日はその判断を変え、新しく始める入口と、続きを開く入口を分けました。
こういう細かい順番は、実際に押してみると自分の希望がはっきりします。
現在の作成画面でも、画像から入力を始められる
5. 同じ質問例から始めても、その先の相談は違う
会話のタイトルをAIが付ける機能では、一つ先の使い方を考えました。
このアプリには、最初の質問を選べる「会話のきっかけ」があります。僕は、そこを押して始める人が多いだろうと考えました。
最初の質問と回答だけで名前を付けると、みんな同じようなタイトルになるかもしれません。でも、その後に相談したい内容は、一人ずつ違うはずです。
そこで、定型のきっかけや相づちでは命名を待ち、個別の相談が出てから名前を付けるようにしました。
同じ「メールを書きたい」から始まっても……
写真講座の持ち物を案内したい
→ その相談内容で会話に名前を付ける
取引先へ日程変更を伝えたい
→ こちらは別の相談内容で名前を付けるこの二つは、実際の検証に使った合成会話です。きっかけと相づちでは命名せず、個別の相談が出た後、それぞれ1回生成することを確認しています。
会話を始めやすくする質問例と、後から探しやすいタイトル。別々の機能としてつくっていても、使う場面はつながっています。そのつながりを考えて、名前を付けるタイミングを決めました。
新しく相談する入口と、続きの会話を開く入口
6. 講師の教材を入れる意味を、回答に残したい
回答の中身にも、自分の考えを入れました。
講師が教材を登録して受講生へ渡すAIなら、その講師の知識や考え方を中心に答えてほしい。ネットの一般的な情報を集めるだけでは、わざわざ教材を入れる意味が薄れます。
この日はウェブ検索も追加しました。必要な外部情報を調べ、根拠のページを回答の引用と末尾の「ソース」から開けるようにしています。
ところが、教材を優先してほしいと調整する途中で、「利用者が明示的に検索を頼んだ場合だけ検索できる」という制限が入りました。使ってみると、今度は検索が働かなくなってしまった。
僕はそこまで制限したいわけではなかったので、戻してもらいました。
| 目指した回答 | 調整したこと |
|---|---|
| 講師の教材を基本にする | 登録資料の知識や考え方を回答の中心にする |
| 必要な外部情報も確かめる | 検索が必要かをAIが判断できるようにする |
| 何を根拠にしたか分かる | 検索したページへの引用とソースを表示する |
最終の本番確認では、「検索して」と書いていない最新料金の質問で検索が動き、挨拶と登録資料だけで答えられる質問では検索しませんでした。
AIの名前と説明も、画面に出すだけでなく、回答に反映するようにしています。自分がつけた名前や役割で話してくれるところまで揃えました。
教材を用意する側の感覚から、利用枠の扱いも変えました。
| 行うこと | 利用枠の扱い |
|---|---|
| ナレッジを登録する・再処理する | 利用枠を減らさず、処理費用は運営側が負担する |
| 登録した資料を使って会話する | 会話として利用枠を使う |
| 作成者がプレビューで会話を試す | テストの会話として利用枠を使う |
教材を入れただけで、まだ会話に使っていない枠が減るのは、自分の感覚と合わなかった。処理費用を確認したうえで、登録と再処理は運営負担に決めました。
7. 資料を使いたい場面から、添付の範囲を決める
講師がAIの教材として登録する資料と、受講生が会話の中で見せたい資料。その両方を扱えるようにしました。
教材の上限は1ファイル10MBから50MBへ。チャットには、画像とPDFを添付できるようにしています。
| 資料の使い方 | この日に決めた範囲 |
|---|---|
| 作成者がAIの知識として登録する | ナレッジとして使う。1ファイル50MBまで |
| 会話中に画像やPDFを添える | その会話の資料として使う。1回4ファイル、各10MBまで |
| 会話にPDFを添える | 100ページ以内。抽出本文やAIへ渡す量にも上限がある |
PDFは最初20ページまででしたが、僕から100ページぐらいまで扱いたいと伝えました。
ここで一つ分かったのが、ファイル容量と、AIが読む量は別だということです。検証用の100ページPDFには、約33KBしかないものもありました。小さいファイルでも、読むページが少ないとは限りません。
このアプリでは、PDFの本文と各ページの画像をAIへ渡します。そのため、ページ数だけでなく、変換後の容量や会話全体の入力上限も合わせて調整してもらいました。
本番では、合成した日本語の100ページPDFを使い、1ページ目、50ページ目、100ページ目の文字と色を実際のAI回答で確認しています。最後のページを続けて質問するところまで試しました。
8. 欲しい反応の速さを伝え、計測で確かめる
画面を切り替えるときも、普段使っているアプリのように、押したらすぐ反応してほしい。
メニューの待ち時間を調べてもらうと、データベースは東京にあるのに、会員画面のサーバー処理は米国東部を経由していました。処理する地域を東京へ揃え、データを取得する順番も見直しています。
| 調べて分かったこと | 対応 |
|---|---|
| サーバー処理とデータベースが離れていた | 処理する地域を東京へ揃える |
| データが揃うまで画面が反応しなかった | 押したことと読み込み中であることを、すぐ表示する |
| 同じ画面の中で認証確認が重なっていた | 同じ処理内の確認を共有する |
| 独立したデータ取得も順番に待っていた | 同時に取得できるものを並行して取る |
修正前後は、本番のPC版Chrome・幅1440pxで、8種類のメニューを3周、合計24操作ずつ計測しました。クリックしてから表示が終わるまでの平均です。
| 計測対象 | 修正前 → 修正後 |
|---|---|
| 24操作全体 | 約1.64秒 → 約0.50秒 |
| マイAI | 約3.39秒 → 約0.63秒 |
| 利用状況 | 約1.34秒 → 約0.26秒 |
| プラン・お支払い | 約1.94秒 → 約0.56秒 |
全体の平均では、約70％短くなりました。初回などには約1.5秒の待ちも残っています。
これは当日の高速化直後の数字で、第4章の「マイAIから新しい会話を開く」変更より前の計測です。最終版全体や、すべての利用者の速度を示す値ではありません。
僕が伝えたのは、メニューを押したときに欲しい操作感です。地域設定や通信の整理は、Codexに調べてもらいました。使う側の基準を伝えることで、どこを調べて直すかも具体的になりました。
9. 動くものを触りながら、自分の好みが具体的になる
今日は、要件定義なしでつくったアプリを触りながら、自分ならどうしたいかを一つずつ形にしました。
ワクワクする演出、と伝えたら、画面と音ができる。それを見て、写真を主役にしたい、音はもっと明るくしたい、と次に伝えることが見えてくる。
アップグレードのボタンができたら、実際に押す。すると、ここでもう一度プランを見せる必要はない、と気づく。
できたものに反応して、好みを具体的に伝え直すことも、アプリづくりの大きな部分でした。 講座を届けてきた経験や、普段アプリを使っている感覚を、そのまま判断の材料にしています。
見せ方や音によって申し込みや受講生の利用が増えたかは、これからです。この日は、まず自分が届けたい体験へ揃えていきました。
別のアカウントで進めた開発も、Gitの開発メモに判断理由ややり直しが残っていたので、今回こうして経緯をたどれました。
自分の仕事に合うアプリをつくるときにも、普段どこで手が止まり、どう見せたいと考えているかが、具体的な指示になります。僕が運営するAI Crewでは、受講生がつくったホームページや業務アプリを紹介しています。自分ならどんなアプリにしたいか、制作物から考えてみてください。