AIビルダーで13日、ランディングとアプリを一度に作り替えた話

Laplace V4を作りながら学んだこと：知っていることを渡し、絵で受け取り、最後まで疑う

Eugene · 2026年10月30日

こんにちは、Laplaceでプロダクトを作っているEugeneです。

10月29日の午後6時27分、アプリのリポジトリにひとつのPRがマージされました。名前はLaplace V4、変更されたファイルは4,116個です。このPRで、Laplace Analyticsのすべての画面とランディングページが新しく生まれ変わりました。5つの言語に対応し、これまでまともに開けなかったスマートフォンでも、画面が本来の姿で表示されるようになりました。ここまでにかかった時間は13日、作ったのは私ひとりです。

始めたときは、正直に言って自信がありませんでした。開発を深く知らない私が、バイブコーディングだけでプロダクト全体を作り直すなんて本当にできるのだろうか、と思っていたからです。ところが最後までやってみると、結果を分けたのは開発の知識ではありませんでした。デザイン、PM、CS、セールスを行き来しながら積み重ねてきた経験が、AIを扱ううえで一番心強い元手になってくれました。

プロンプトを書くたびに、それを実感しました。アナリティクス製品でUIとUXをなぜ別々に設計すべきかを知っていましたし、どんな機能やチャートが必要かは、お客様からの問い合わせやミーティングを通じてすでに頭の中に蓄積されていました。AIに必要だったのは、まさにその文脈でした。

私は長い間、ひとつの分野を深く掘り下げるスペシャリストに憧れていました。現実の私は、あれこれ幅広く手がけるジェネラリストに近い人間です。ところがAIと一緒に働くうちに、その幅広さが初めてそのまま強みになりました。この記事では、13日間で何を、どのように作ったのかをお話しします。

まず、何が変わったのか

言葉より絵のほうが早そうです。以下の画像はすべて、同じダミーデータを入れたローカルのアプリで、同じ幅で撮影しました。左が以前の画面（ui-classicブランチ）、右が現在デプロイされているV4です。

一番大きく変わったのはスマートフォンです。以前のアプリにはモバイル画面がまったくありませんでした。デスクトップの画面がそのまま縮小されるので、メニューが画面の大部分を覆い、設定のタイトルは1文字ずつ折り返されていました。

そして言語です。以前のアプリで表示言語を日本語に切り替えると、英語と韓国語が混ざって表示され、メニューにはgroup.strategyのような翻訳キーがそのまま見えていました。

ランディングも同じ流れで作り替えました。ランディングはV4より少し早く、10月初めにFramerのサイトを診断してコードに移す作業から始めました。診断してみると、ファーストビューのモックアップは「2024 ブラックフライデー成果レポート」のままで、チャートの凡例にはseries-1がそのまま表示されていました。スマートフォンでは製品画面がまったくありませんでした。

V4の期間中、ランディングに日本語版、中国語簡体字版、中国語繁体字版を追加しました。訪問者のブラウザの言語を見て対応する言語版に案内し、海外版の料金はドルで表示します。言語の自動切り替えは、ビルドされたHTMLを18通りのケースで開く回帰テストでカバーしました。

ランディングで「5つの言語に対応しています」と言いながらアプリが韓国語だけなら、海外のお客様は登録した瞬間にがっかりしてしまいます。だから、この2つをひとつのまとまりとして考えました。

1. 知っていることを全部渡すところから始めました

AIはコマースを知りません。正確に言えば、私たちのお客様が何を最初に見て、何に不便を感じているかを知りません。そこで最初の数日は、ほとんど説明ばかりしていました。

• コマース企業の代表が朝一番に見る数字（昨日の売上、目標対比、広告費に対する売上）

• お客様にお会いする中で聞いた声。「以前のダッシュボードと数字の位置が変わっては困る」「表を横にスクロールするとカクカクする」「地図で地域名が枠からはみ出す」

• 以前の画面で作りたかったのに実装できずに諦めた機能やUI、そしてその理由

• データの見せ方。日付と時刻は常に韓国時間、今年の日付でも年を省かない、表は基本的にどの列も固定しない

• 使い勝手で必ず守るべきこと。文字は11pxより小さくしない、スマートフォンでタップする場所は44px以上、システム標準のドロップダウンは使わない

• これまでなかったモバイル画面で、何を残して何を畳むか

一度言っただけで終わると、次の会話では忘れられてしまいます。そこでルールはドキュメントとスキルに残しました。「チャートカードには見出しを入れない」「カードの高さは以前の画面と互換性を保てるよう160px単位で保存する」といったルールが、次の作業指示に自動で付くようにしました。毎回説明し直さなくてもいい状態を作ること、それが最初の仕事でした。

2. 一度に全部作らず、絵で受け取りました

最初は「全部作って」と言いたくなりました。でもそうすると、結果は広く浅くなります。そこで順番を変えました。

頭の中に描いている画面があれば、まず言葉で説明し、AIに案を2〜3個作ってもらいました。案は実際のアプリをローカルで立ち上げ、その中に描いてもらいました。そうすれば本物の製品のように見えますし、スマートフォンの幅とデスクトップの幅でどう見えるかをすぐに確認できるからです。

決めることが出てきたら、文章ではなく変更前後の絵で受け取りました。変わる箇所があまりに多く、文章の報告を読むだけでは何が違うのか判断できなかったのです。「何が違うのかわからない、絵でちょうだい」と何度も言っていたので、そのうち作業ルールそのものになりました。

ひとつの画面ができあがると、そこから先は速くなりました。設定画面は同じ仕様と流れを持っているので、「マイ情報」画面でヘッダー、左メニュー、右側のヘルプ、保存バーの仕様を決めてしまえば、残りはその仕様に沿って順に合わせていくだけでした。

3. AIの提案が自分の考えより良いことがかなりありました

正直、ここが一番意外でした。データをまったく連携していないお客様にカスタムダッシュボードをどう見せるかを考えていたとき、私は「サンプル画面をひとつ」思い浮かべていました。AIは業種別の事例ボード8つを実際のチャート部品で描き、その上に「自分のデータで確認したいならデータ連携へ」を添える案を出してきました。在庫管理、税務・損益、リピート商品分析、クロスセル、CRMといったボードを眺めていると、「これ、うちもやりたい」と思えてきます。私が求めていたのは、まさにそれでした。

ただ、確認は欠かせませんでした。画面の真ん中に大きな案内ウィンドウを出してしまう、カードが少なくてボードが寂しく見える、表の右側ががらんと空いている、といったことはAIが自分ではうまく気づけませんでした。事例に実在する顧客企業の名前を入れないといった判断が必要な部分も、人が決める必要がありました。

詳細フィルターを作ったときもそうでした。AIが最初に出した案は、値のチップごとに条件のドロップダウンを付け、チップの間にある「または」ひとつで全条件のつなぎ方が一度に変わる方式でした。画面だけ見ればもっともらしいのですが、条件を組み合わせたりグループにまとめたりできませんでした。その案は捨てて、Notionの詳細フィルターのようにルールを1行ずつ積み上げる方式に変えました。AIが「できました」と言っても、私が自分で画面を触って確かめるまでは、できたことにはなりませんでした。

4. デザインシステムは参考程度にしました

今回の作業では、あえて決めたルールがあります。既存のデザインシステムは参考にするだけで、最初からそのまま従うことはしませんでした。

最初からデザインシステムを守ろうとすると、システムの中でしか考えられなくなります。手持ちの部品で作れる画面しか思い浮かばず、お客様に本当に必要な画面はシステムにないことが多いのです。そこで案の段階では幅広く考えつつ、色や余白のトークン、共通部品は再利用して一貫性を保ちました。

そしてデザインが終わってデプロイを始める前に、既存のデザインシステムを現在のバージョンに入れ替えました。統合PRでデザインシステムのパッケージのファイルが151個一緒に変わったのはそのためです。システムがデザインを縛るのではなく、完成したデザインがシステムを書き直したわけです。

入れ替えたあとは画面全体を見直して、「同じ役割なのに別々に作られた部品」を探しました。たとえば、デスクトップでは中央のダイアログ、スマートフォンでは下からのシートになるダイアログが34個のファイルで使われていて、似たようなダイアログがさらに4種類ありました。こうしたリストが、次のデザインシステム作業の出発点になりました。

5. 使い勝手の判断に迷ったら、他社の事例をすぐに持ってきました

「このボタンはここでいいのか」「このステータスバッジを何と呼ぼうか」「Internet Explorerで来た人に案内を出すべきか」といった問いは、ひとりで悩んでいるときりがありません。そんなときはAIに、他のサービスがどうしているのか、コミュニティでどう語られているのかを調べてもらい、そのやり方をすぐにローカルの画面に適用して、絵で受け取りました。

自分で調べて比較するよりずっと速かったです。判断するのは今も私ですが、判断の材料が数分で画面になって出てきます。検索結果のリンクを10個読むのと、自分たちの画面にそのやり方を載せた絵を2枚並べて見るのとでは、決めるスピードがまったく違いました。

6. 専門家が必要な仕事には専門家を付けました

チャートの可視化、パフォーマンス計測、翻訳チェックのように専門知識が必要な仕事には、その分野のスキルやエージェントをダウンロードして付けました。そして複数の作業を同時に回しました。日付の表記、バッジの文言、カードの高さ、地図の差し替えをそれぞれ別のサブエージェントに任せ、私は戻ってきた絵を見て選ぶ役割でした。

表のスクロール。 「表を横にスクロールするとカクカクする」というフィードバックは、長年の宿題でした。勘で直すのではなく、CPUを4倍遅くした条件でアプリの表27個をすべて計測し、原因を突き止めました。修正後は、50msを超える長いタスクが119回から14回に、スクリプトの実行時間は半分に減りました。この修正はリリースの翌日に出したPRなので、まだレビュー中です。

翻訳。 社内には日本語や中国語のネイティブスピーカーがいません。そこでAIでチェックしました。文字列ごとに原文と翻訳を並べ、翻訳をもう一度韓国語に訳し戻して意味を比べる方法です。連携ガイドの文字列711個をこの方法で確認し、93個を修正しました。「設定するとログインできます」が、本来の意味である「設定しないとログインできません」と違って読めてしまうケースのように、文法は正しいのに意味がずれている翻訳が主に引っかかりました。

リリース前の点検。 最後に、119の画面を5つの言語と8種類の幅で開き、重なり、見切れ、残った韓国語、小さすぎるタップ領域をまず機械で探し、引っかかったものだけを人が確認しました。Safari、Firefox、iPhone、iPad、Androidの端末設定や、PretendardフォントのないWindows環境も別途回しました。マージ後にもう一度回したとき、新たに見つかった致命的な問題は0件でした。

ただ、一度に回しすぎるとノートパソコンが持ちませんでした。ブラウザを立ち上げるエージェントが何体も同時にテストを回して一斉に止まってしまってからは、重い作業は一度にひとつ、ブラウザはひとつだけ立ち上げるというルールを指示に入れました。

7. それでも事故は起きました

すべてがうまくいったわけではありません。自動化ブラウザを本番データを使うプレビューのURLにつないでしまい、3分間で本番APIに認証失敗（401）のリクエストを約1万8千件送ってしまったことがあります。ログインしていないブラウザで、アプリは認証に失敗するたびにリトライしていました。

それ以来、ルールを作りました。自動化は、認証とAPIをすべてダミーに置き換えたローカルアプリでだけ実行し、ブラウザから127.0.0.1の外に出るリクエストは最初からすべてブロックします。この記事のアプリ画面も、すべてそのローカルアプリで撮影しました。このルールもスキルのドキュメントに書いてあるので、すべてのサブエージェントへの指示に自動で付きます。

AIは指示すれば素早くやってくれます。だからこそ、何を指示してはいけないかを決めておくのが人の役目です。

デプロイはどうしたのか

領域ごとに別々のPRを出してレビューを受け、最後にひとつの統合PRにまとめました。設定・メニュー・カスタムダッシュボードから始めて、多言語対応、データ連携、データ管理、標準ダッシュボードを順に載せていき、まとめたリストは25行、PRに積み上がったコミットは820件になりました。変更されたファイル4,116個のうち、1,333個はテストファイルです。

一度にリリースしつつ、元に戻す道は残しておきました。アプリバーの「新しい画面」スイッチで、誰でも新しい画面と以前の画面を行き来できます。お客様が慣れた画面を一夜にして失わないようにするための仕組みです。このスイッチのおかげで、以前の画面とV4を同じダミーデータで並べて撮影し、この記事の比較画像を作ることができました。

13日間を振り返って

一番大きく変わったのは、悩む量です。以前は「これでいいのか」をひとりで長く抱え込んでいましたが、今回は案をいくつか受け取って選びました。その代わり、選ぶ目とお客様をどれだけ知っているかが、結果をほぼすべて決めました。

似たような働き方を試してみたい方に、3つのことをお伝えしたいと思います。

ひとつ、渡す知識から整理してください。 AIが作った画面の品質は、私が渡したお客様の話の量にほぼ比例していました。お客様のフィードバック、諦めた機能、業界で重視される数字をドキュメントに残しておけば、AIは毎回それを読んでから始めてくれます。

ふたつ、文章ではなく絵で決めてください。 画面が数十を超えると、文章の報告では判断できなくなります。同じ画面の変更前後の絵1枚が、会議1回の代わりになりました。

みっつ、「できました」を信じないでください。 AIの提案は思った以上に良いことが多かったのですが、スマートフォンの幅で触ってみる、別の言語に切り替えてみる、実在のお客様の名前が紛れ込んでいないか確かめる、といったことは最後まで私の仕事でした。何を指示してはいけないかを決めることも、です。

これから

遠からず、プロダクトを作る仕事のかなりの部分をAIが担うようになると思います。良い機能が、今とは比べものにならないスピードで世に出てくるでしょう。そうであれば、働き方や組織の構造も考え直す必要があります。デザイナー、プランナー、開発者のように職種を分ける境界が、今ほど固い必要があるのかもわかりません。

それでも私は、この変化を危機よりもチャンスだと考えています。頭の中にしかなかったアイデア、ドキュメントにしか残っていなかった企画を、すぐに形にしてお客様の前に出し、検証できるようになったのですから。

Laplaceは今、データ分析を超えてautomated planningの準備を進めています。目標は年内です。グローバル版のアプリもリリースを控えています。データインフラの先へと続くLaplaceの次の旅路も、ぜひ見守ってください。

---

この記事のアプリ画面はすべてダミーデータを入れたローカルアプリで撮影したもので、画面内のブランド名・数値・メールアドレスはすべてサンプルです。数字の出典：アプリリポジトリのgit履歴（PR #4984、2026-10-29マージ）、ランディングリポジトリのgit履歴、リリース前点検レポート（plan/v4_qa/sweep.md）、表のパフォーマンス計測（.local/hscroll/agg_all4.md）、翻訳チェックの記録（plan/i18n_ai_review.md）。