Meta Museは自分の紹介ページをどこまで自律開発できるか。約6分の作業とCodexレビューの記録

紹介(PR):この記事には私のMuse紹介コード U7RB06 を掲載しています。適用条件を満たして使うと、利用した方と紹介者の双方に特典が入る仕組みです。特典内容・期限・残り枠はMuse側の画面で確認してください。

この記事で分かったこと

Museは、既存のLPを読み直して改善し、検証が失敗すると代替手段を探すところまで進めました。約6分で進んだのは継続作業の範囲です。実ブラウザ確認は別のWindows環境でCodexが補い、公開前に修正が必要な点も見つかりました。

  • Muse:競合の再調査、LP v2、Node.jsでの4項目のロジック検証、実験記録と記事下書きを作成。
  • Codex:別環境で独立レビューと修正を実施。修正版LPは31チェックPASS。
  • 初期成果:紹介成立1人。ただし経路は不明で、当時未公開だったLPの効果ではありません。

Museは、会話で依頼した内容に応じて調査やブラウザ操作、ファイル作成を進めるAIエージェントです。今回は、その一連の作業を紹介ページの改善で試しました。

MetaのAIエージェント「Muse」に、自分自身の紹介コードを使ってもらうためのページを作らせてみました。今回確かめたかったのは、案を出すところから、調査、実装、検証、記録まで、どこまで一つの会話で進められるかです。

2026年11月12日朝の継続作業は、ログ上で約6分。競合調査、LPの改善、JavaScriptのロジック検証、実験ログと記事下書きまで進みました。一方、実ブラウザでの表示と操作の確認は終わりませんでした。そこで成果物をCodexに渡し、別のWindows環境でレビューと追加検証を行いました。

短時間でページを作れることと、そのまま公開できることの間に、何が残ったのか。その記録です。

10億トークンの紹介特典から、小さな実験を始めた

きっかけの一つは、紹介する側とコードを利用する側の両方に、10億Museトークンが付くという案内でした。利用を試したい人と、もう少しMuseを使いたい紹介者にとって、紹介制度は接点になります。ただし、この数字を全員に適用される保証としては扱いません。現在の公式特典画面を今回のレビューで確認したわけではなく、最終条件は各自のMuse画面が基準です。

そこでコード U7RB06 を案内しつつ、Museに集客施策そのものを考えさせることにしました。「Museを使って何ができたか」を、Museの紹介ページ作りで示せれば、コードを並べるだけの記事よりも読んでもらえるのではないか、と考えた実験です。

実験前から、Gamerch、Muse紹介コード専用掲示板、星落掲示板、X(@iwadjp)の4経路には掲載済みでした。これは掲載経路の申告上の区分です。各投稿URLを照合して4つの独立した媒体と確認したわけではありません。

コードだけでは、選んでもらう理由が弱い

Museの調査ログには、Gamerchで数分の間に新しいコード投稿が増え、同じコードの繰り返しもあったと記録されています。投稿番号の差は約5分で21件。ただし、これはMuseがその時点で取得した表示の差であり、私が全投稿を数え直した値ではありません。

Codexの追加調査でも、紹介コード掲示板や入力方法を説明する記事は確認できました。「使い方の説明が競合にない」とまでは言えません。差を出せるとすれば、自分の実験過程、失敗した操作、その後の検証結果を一緒に公開することです。

LPでは、コードと入力手順に加えて、参加から48時間の締切計算と、登録直後のチェックリストを用意する方針になりました。便利さが利用につながるかは、公開後に測る必要があります。

Museに任せたことと、約6分の範囲

依頼の要旨は、紹介コードの利用者を増やす施策を調査し、成果物を作り、その作業能力も後から検証できるよう記録することでした。ここでは提出されたレポートと実験ログから要約しています。最初の指示文全文をそのまま再掲したものではありません。

ログで時刻を追えるのは、11月12日06:24〜06:30 JSTの継続作業です。開始時点ですでにレポート、LP v1、投稿文案がありました。そのため、「調査もv1も全部ゼロから6分で完成」とは言えません。

継続作業では、次のことを進めています。

  • 既存成果物を読み直し、掲示板や体験記事を再調査する。
  • LP v1に足りない点を整理し、v2を別ファイルで作る。
  • コピーボタンに代替処理を加え、48時間の締切計算と3項目のチェックリストを実装する。
  • HTMLを静的に確認し、ブラウザ検証を試す。
  • 失敗した操作と代替検証を記録し、ブログ下書きを作る。

今回受け取った成果物は、調査レポート、投稿文案、記事下書き、LP v2、実験ログの5ファイルです。旧版そのものは今回の入力に含まれていないため、v1からの改善内容はログの記述として扱いました。

CodeBeautifyへのアップロードは、人間が止めた

ブラウザ検証で、Muse側はローカルHTMLを表示するために、第三者サイトCodeBeautifyのHTMLビューアへファイルをアップロードしようとしました。ここで承認要求が出て、私は拒否しました。

ログ上では、アップロードは実施されていません。その後、第三者サイトへ送らず、ローカル表示か外部送信を伴わない方法で検証するよう指示しました。

この点は自律性を評価するときに分けておきたいところです。外部アップロードを避けるという境界は、人間の拒否と追加指示で明確になりました。その境界の中で代替手段を探したのが、次のMuseの作業です。

Chromiumは起動せず、Node.jsで検証を補った

MuseはVM内にChromiumを見つけ、ヘッドレスで起動しようとしました。しかし、実験ログではWebGLのドメインポリシーに関するエラーで2回とも起動に失敗しています。終了コードは2で、スクリーンショットは生成されませんでした。

次に、HTMLから実際のJavaScriptを取り出し、最小限のDOMスタブを用意してNode.jsで実行しました。ログに残っている確認は次の4項目です。

  • コピー用の代替処理が呼ばれ、成功メッセージが出る。
  • 2026年11月12日09:00に48時間を加えると、11月14日09:00になる。
  • 空入力で日時を求めるメッセージが出る。
  • チェックリストを3つ選ぶと完了メッセージが出る。

これはロジック検証です。実際のクリップボードに文字が入った証拠でも、スマートフォンでタップできた証拠でもありません。提出ログにあるテストスクリプト自体は今回の5ファイルに含まれていないため、4項目の成功はMuseの実行記録として受け取り、Codexでは別途検証しました。

チャット内のHTMLプレビューも作られていますが、その表示だけで全操作の検証が済んだとは扱いません。失敗後に代替手段を見つけ、何を確認できたかを限定して報告した点は、今回の成果だと思います。

Codexの独立レビューで見つかったこと

Codexは提出されたLP v2を、既存のPlaywrightとChromeで開きました。追加パッケージのインストールや、HTMLの外部アップロードは行っていません。ページはローカルの一時HTTPサーバーとfile URLで表示しました。

Codexによる提出原本の主観採点は、技術品質74/100、記事品質66/100、集客品質70/100でした。通常のコピーや表示は動く一方、日時の案内、記事の構成、冒頭での紹介特典の開示に改善余地があるという評価です。修正後のLPの点数ではありません。

元のLPは、PC表示、スマートフォン相当の表示、紹介コードのコピー、チェックリストが動きました。文字列を実際にコピーし、ブラウザのClipboard APIで U7RB06 を読み戻すところも確認できています。

一方、修正すべき点もありました。

  • 未来の参加日時を入れても締切が出る。
  • 48時間を過ぎていても、コード入力を促す文章が出る。
  • 日時が端末の現地時刻として扱われるのに、タイムゾーンが表示されない。
  • コピーAPIが同期的に例外を投げる条件では、失敗案内が出ない。これは意図的な障害注入で確認したものです。
  • 紹介者にも特典が入るという開示が、LPの末尾にしかない。

日時計算で大事なのは、「2日後の同じ時刻」と「48時間後」が、夏時間の切替をまたぐ地域では一致しないことです。元のコードはミリ秒で48時間を加えていたため、この加算自体は正しく動いていました。問題は、どの地域の日時なのかが読者に伝わらないことでした。

修正版では加算方法を維持し、タイムゾーン、未来日時、期限経過を表示しました。存在しない日付や夏時間の切替で存在しない時刻を拒否し、二通りに解釈できる重複時刻は計算せずMuse側の表示確認を促します。コードとコピーボタンも冒頭へ移し、紹介特典の開示を先に置きました。

修正版の検証で、確認できた範囲

修正版はChrome 157.0.8103.40とPlaywright 1.60.0で、31件のチェックがPASSしました。この数には表示・操作に加え、ページ内の計算関数を直接呼ぶ境界値テストや、コピー失敗を模擬したテストも含みます。31人が使えた、あるいは31種類の端末で確認した、という意味ではありません。

実ブラウザで確認したのは、PC表示、幅320・390・768pxでの横方向のはみ出し、コピーと読み戻し、タッチ模擬のコピーとチェック操作、空入力・未来日時・期限経過、チェック解除、JavaScript無効時の案内などです。PCと幅390pxの全体画像も保存しました。

計算関数では、月末・うるう年、48時間直前とちょうど48時間の境界、不正な暦日を確認しています。ニューヨークの夏時間をまたぐ48時間と、存在しない・重複する現地時刻も確認しました。

ただし、実機のiPhone・Android、Safari、スクリーンリーダー、Muse内でのコード入力と特典付与は未検証です。この独立レビューの段階では、本番WordPressのテーマ上での表示も未確認でした。ローカルのLPが動くことと、紹介制度が適用されることは別です。

LPのPC・モバイル検証画像

以下はCodexの独立レビュー時に保存した修正版LPの画面です。PCは幅1365px、モバイル相当は幅390pxのChrome表示で、実機のiPhone・Androidの画像ではありません。今回の公開準備では入力手順を締切計算より先に移しているため、画像のセクション順は公開予定版と異なります。

PC検証画像(幅1365px)。画像を開くと全体を確認できます。
モバイル相当の検証画像(幅390px)。今回の並び替え前の画面です。

紹介成立1人は確認したが、LPの効果とは言えない

11月12日06:35頃、私が紹介成立1人を確認しました。これは所有者による確認として記録しています。CodexがMuseのアカウント画面を確認した値ではありません。

その時点でLPは公開していません。既存の4掲載経路のどこから利用されたのかも分かりません。そのため、「Museが作ったLPで1人獲得した」「6分の作業で集客に成功した」という結論にはなりません。実験の初期状態として1人の成立があった、というところまでです。

公開後は、日時、紹介成立数、残り枠、施策の変更、記事やLPの閲覧数、リンククリック数を分けて記録する予定です。紹介成立数は、Museの招待画面に表示される件数を優先します。トークン残量は作業で消費されるため、「残量の増加÷10億」だけでは成立数を正しく数えられません。

公開リンクに流入元別のパラメータを付けられれば、どこからクリックされたかを整理する助けにはなります。ただし、それでMuse内の紹介成立まで結び付けられるわけではありません。今回は計測タグも追加していません。

MuseとCodexの順位を決める実験ではない

今回のMuseは、調査からLP改善、検証の試行、失敗時の代替案、記録作成までを短時間で進めました。Codexは、その成果物を受け取り、Windowsに既存のChromeとPlaywrightがある条件で追加検証し、修正と公開原稿の整理を行いました。

同じ課題を同じ初期状態、同じ環境、同じ制限時間で解かせた比較ではありません。MuseのVMでは起動できなかったブラウザを、Codexの環境では利用できています。この結果からモデルの優劣や速度差を断定することはできません。Museのトークン消費量も取得できていません。

人間が担ったのは、CodeBeautifyへのアップロードを拒否すること、外部送信の境界を明示すること、紹介成立数を確認すること、そして最終的に公開してよいか判断することでした。この記事では、実装と検証の記録を残し、紹介ページから利用につながるかを継続して測ります。

Museを試す方へ:紹介コードと入力方法

紹介コードLPでコードと入力手順を確認する

今回のように調査と小さなページ作りをまとめて任せる使い方に興味があれば、Museを試す際の参考にしてください。紹介コードは U7RB06 です。条件を満たして利用すると、利用した方と私の双方に特典が入ります。残り枠・現在の有効性は未確認です。

  1. Museの参加案内から参加する。リンクを開くだけではコードの引き換えは完了しません。
  2. Museへの参加から48時間以内に、Muse内の設定を開く。アプリは「Redeem token/紹介コードを利用」、Webは「一般 → Usage/使用量 → Redeem invite code」が提出資料にある案内です。現在の画面では名称や配置が異なる可能性があります。
  3. U7RB06 を入力し、Muse側の成功表示・適用条件・特典を確認する。入力欄が1文字ずつの場合は、その画面に合わせて入力してください。

48時間の起点はMuseへの参加時刻です。この記事を読んだ時刻やコードをコピーした時刻ではありません。特典額、入力可能回数、対象条件は、現在のMuse画面を優先してください。

参照と記録の扱い

この記事の作業経過は、Museから提出された調査レポート、投稿文案、記事下書き、LP v2、2026年11月12日の実験ログを基にしています。約6分の内訳と過去のブラウザ操作は提出記録、06:35頃の1人成立は所有者の確認、修正版LPの動作はCodexの追加検証として区別しました。

Museがレポート内で参照した内部文書は今回の入力に含まれておらず、Codexから原文を確認できていません。紹介条件を公式に独立確認済みとは扱っていません。