BuildMidasハンドブック: プラットフォームの地図

サイドバーの項目を一つずつ説明するのではなく、実際のアカウントの一部始終をご紹介しましょう。たとえば、プラットフォームを使い始めて1週間目のフリーランサーが、小規模クライアント向けに習慣管理アプリを構築するケースを考えてみます。ダッシュボードを進んでいく中でビルドに実際に何が起きるか——その順序と、各ステップがどこで役立ち、どこで5分を無駄にしたかを見ていきます。

プロンプト

彼らはAI Builderを開き、「習慣管理アプリを作って」に近い内容を入力します。最初の一文としては妥当ですが、最終的なプロンプトとしては不十分です。返ってくるのはコードではなく、平易な言葉で書かれたプランです。「よさそう」と思った時点で読むのをやめて承認すると、「習慣管理アプリ」という言葉には対応しているものの、それ以外のあらゆる点で汎用的なものが出来上がります。このフリーランサーのクライアントは、ソーシャル機能なし、ローカルストレージのみ、デフォルトはダークモードを希望していました。しかし、これらは最初のプロンプトには含まれていませんでした。代わりに、承認前の3つの編集としてプランに反映されます。プランが勝手に作った「連続記録をシェア」機能を削除し、ストレージの記述を差し替え、デフォルトテーマを切り替える——編集にかかった時間は30秒。こうして完成したビルドは、「習慣管理アプリ」という言葉ではなく、実際の要件に合ったものになります。

見落とされがちなプラン確認ステップ

最初のプランを読まずに承認し、3回イテレーションを重ねたところで、本来プラン段階で決めておくべき制約を改めて説明し直す——他のユーザーが実際にこの失敗をするのを何度も見てきました。プラン確認ステップは、まさにそれを防ぐために存在します。コストはほとんどかからず、コードの出力をデバッグするのではなく、自分の言葉でエージェントと調整できる唯一のタイミングです。

ビルドの実際の行き先

生成が完了すると、習慣管理アプリはMy Builds——種類別に絞り込みできるライブラリページ——にカードとして表示されます。3週目に5〜6件のビルドが積み上がる頃には、このフリーランサーが最も頻繁に開くページになるでしょう。Showcaseには表示されません。このページは自動掲載ではなく厳選されたものであり、クライアント向けのビルドを無用に公開しないのが正しいデフォルトです。また、Templatesにも、フリーランサーが自らテンプレートとして保存しない限り表示されません。実はこれをやっておく価値は大いにあります。習慣管理アプリの骨格は、次のクライアント向けにブランディングを変えて再構築するのにまさにうってつけだからです。多くの人は6件目のビルドになって初めて「テンプレートとして保存」機能に気づき、1件目でやっておけばよかったと後悔します。

公開か、それとももっと本格的な選択肢か

次は配信方法の選択です。名前だけ違う一つの選択肢ではなく、実質的に異なる3つの選択肢があります。Publishedは無料サブドメインを提供し、数秒で公開でき、設定は一切不要です。クライアントがまだレビュー中で、デザイン変更を求めてくる可能性がある段階では、これが正解です。Domain Managementは、クライアント自身のドメインをこのビルドに向ける準備ができたときのためのもので、このステップには二重の役割があります。ドメイン接続はURLの変更だけでなく、サイドバー下部にあるアナリティクスページにデータを紐づけるためにも必要なのです。設定内にあるDeployは、クライアントが自社管理のインフラでビルドを稼働させることを譲らない場合のためのSFTPパスです。設定はより煩雑になり、稼働状況の責任もフリーランサーの手を離れます——これは偶然発見するのではなく、明確に把握しておくべきトレードオフです。

このビルドについては、まずPublishedを選びます。後からサブドメインからカスタムドメインへ移行するのは何の問題もありません。一方、キャンセルされたクライアントプロジェクトでカスタムドメインのデプロイを取り消すのは、その手間に見合わないほど面倒です——実際、このフリーランサーは以前のプロジェクトでまさにそれで痛い目に遭っており、それが「まずPublishedをデフォルトにする」習慣の理由になっています。

アプリストアの寄り道

今回のクライアントはアプリストアへの掲載も希望していたため、ビルドはPublishedで止まらずShippedを経由します。このページが存在するのは、ストア審査がウェブデプロイとは違って非同期だからです。あるストアに提出すれば2日待たされ、別のストアなら20分で通ることもあります。Shippedは、それぞれ異なるログインとステータス表記を持つ5つのストアコンソールをブラウザタブで開かずに、この状況を追跡できる場所です。

誰も教えてくれなかった空白のページ

ドメインを接続してから1週間後、フリーランサーは状況を確認しようとSearch Performanceを開きます。すると空っぽです。グラフも数字もなく、アカウント接続を促すだけの、いささか寂しい画面です。しかしこれは不具合ではなく、正直な表示です。まだデータがないだけなのです。Search Performance、Google Analytics、Store Analyticsはいずれも設定内のGoogleアカウント連携を起点としており、過去に遡ってデータを取得することはありません。同期は接続した瞬間から始まり、以降のデータのみが蓄積されます。初日にドメインを接続すれば2週目には1週間分の履歴があり、うっかり忘れて10日目に接続すれば、その10日目からゼロで始まることになります。このフリーランサーはドメインは接続していましたが、Googleアカウントは接続していませんでした——一見一つに見えて、実は別々の2つのステップです。

ここで本当にコストがかかるのは、グラフが表示されないことそのものではありません。最適化エージェントも同じデータを参照しているため、Search Performanceの履歴がゼロの状態でページの順位改善を依頼されたエージェントは、そのサイトの実際の数値ではなく一般的なベストプラクティスに基づいて動作することになります。連携をスキップすると、ダッシュボードのページが空欄になるだけでなく、エージェントができることの上限も下がってしまうのです。

頼んでもいないのに現れるブリーフ

2週間が経つと、Discoveryにカードが現れる。クライアントのサイトのコンテンツギャップを指摘する機会提案(オポチュニティブリーフ)で、ビルド開始ボタンが付いている。どのみち対応するようなことに当たれば、確かに役立つ。しかしDiscoveryは設計上、精度よりも量に振れている——誰も対応しきれないほど多くのブリーフが出てくる——ので、正しい姿勢は「処理すべきキュー」ではなく「提案の受信箱」だ。フリーランサーは数日おきにざっと目を通し、ほとんどを無視する。それが想定された使い方であり、対応しきれていないわけではない。

初日に済ませておくべきだった設定

ここまでで、フリーランサーは意図的に設定メニューを開くことなく、4つの設定ページに触れている——それぞれ、他の何かが空だったことがきっかけで見つかったものだ。

先に済ませておく価値があるのはGoogleアカウント連携だ。これは3つの独立したダッシュボード画面の裏にある単一の接続ポイントであり、それを苦労して知ることになる——3つの異なる空白ページ、3つの異なる「あ、これを接続しないと」という瞬間——のは、初日に5分かけて設定を済ませておけば避けられる摩擦そのものだ。

ずっとそこにあった2つのもの

浮動表示のAsk AIボタンは、これらのページすべてに最初からずっと存在していた。しかも、範囲の限られたFAQボットではない——あなたの代わりにアカウントを接続したり、ビルドを開始したり、なぜページが空なのかを説明したりできる。フリーランサーのクライアントは英語を話さず、レビュー通話のためにインターフェース全体を別の言語にする必要があった。ナビにある地球アイコンは、進行中のビルドを失うことなく、セッションの途中でも20言語すべてに切り替えられる。このどちらも、他のすべてがそうだったように試行錯誤で発見される必要はなかった。ただそこにあっただけだ。

それがこのアカウントの最初の2週間を正直にまとめたものだ——「まずドキュメントを読み、それからビルドする」ではなく、その逆だ。My Buildsは、そこにカードが入るまでは抽象概念だった。検索パフォーマンスは、ドメインがデータを供給するまでは空の状態だった。最初のビルドの前にフロアプランを読んでおくのは背景知識としては悪くないが、フロアプランが意味を持つのは、そこに実際に習慣トラッカーのようなものがどこかに存在してからだ。