はじめに
Meta のパーソナル AI エージェント「Muse」（muse.ai、2026-10-23 に日本で提供開始）に、大阪・日本橋を舞台にした鳩の 3D シミュレーションを作ってもらいました。成果物は GitHub で公開しています（kai-kou/nihonbashi-pigeon-simulation）。
依頼したのは筆者で、半分冗談のつもりでした。ところが筆者の体感では約 10 分で、想定以上の品質の初版が動く形で出てきて、驚きました。この記事は、その成果物の中身と、確認できたこと・できていないことの記録です。
追跡モードで撮った画面です。この記事の画像はすべて、GPU のないクラウド環境のブラウザ（ソフトウェア WebGL）で、リポジトリの index.html を開いて撮影したものです。
名前が紛らわしいので先に整理します。この記事で Muse と書いたときは、Meta のパーソナル AI エージェントを指します。基盤になっている Meta のモデルは Muse Spark で、エージェント本体とは別の名前です。Muse Code という CLI ツールもありますが、この記事の対象ではありません。過去に同じ名前や似た名前のサービスがあったこともあり、ここでは Meta の公式発表に出てくるものだけを Muse と呼びます。
対象読者は、AI エージェントにものづくりを依頼したとき、成果物の中身と確認できていない範囲まで含めて知りたいエンジニアです。
「約 10 分」は筆者の記憶に基づく概算で、計測したログはありません。制作経緯の記述は、リポジトリの docs/ に残った記録に基づいています。docs は作り手を「ビルダー」と呼ぶ第三者視点で書かれていて、どこまでが Muse の出力で、どこからが人の手直しかは区別できません。一方、完成物の構成と動作は、この記事を書く時点でリポジトリを clone し、クラウド環境のブラウザで動かして確認しました。
この記事で分かること
- Muse が公式にどう説明されているか（確認できた範囲だけ）
- 依頼文と、筆者の体感での初版の速さ、依頼者が途中で下した判断の記録
- 完成物の中身（ファイル構成、データの出どころ、論文値と演出値の割合）
- クラウドで動かして確認できたことと、確認できていないこと
- 初版のあとに加えられた改善と、検証で分かったこと
Muse とは（公式が書いている範囲）
Meta Japan の発表（2026-10）と、米国発表時の Meta の記事（2026-09）から、確認できた範囲を表にします。
| 項目 | 記載内容 |
|---|---|
| 位置づけ | 利用者の目標達成を能動的に支援し、実際にタスクを進めるパーソナル AI エージェント |
| 日本での提供 | 2026-10-23 から。iOS、Android、muse.ai |
| 基盤モデル | Muse Spark（米国発表の記事による） |
| 実行環境 | 専用の仮想マシン「Muse Secure VM」で動作（米国発表の記事による） |
| できること（例） | メール送信や旅行予約などのタスク実行、計画立案、ブラウザ操作とフォーム入力、アプリを閉じた後も続く長い作業と承認が必要な場面での通知 |
| 安全面の記載 | 重要な操作の前に利用者へ確認。操作履歴の確認が可能 |
出典は Meta Japan の発表と、米国での発表の記事です。
2 つの記事のどちらにも、アプリの生成や、作ったページの公開ホスティングに関する記載はありませんでした。したがって「Muse にはアプリ生成機能がある」とも「ない」とも、この記事では言いません。リポジトリの README は、デモのリンクとして muse.ai ドメインの URL を載せ、「Muse 上でホストされている現行ビルド」と書いています。書かれているのはそこまでで、リンク先がいつまで開けるかも分かりません。そのため、この記事の主リンクは GitHub のリポジトリにしています。
料金の金額、日本語への対応範囲、API の有無、データの保存場所、安全性の評価、他のエージェントとの比較は、この記事では扱いません。
依頼文と進め方
依頼は 2026-10-24 に出されました。リポジトリの docs/concept.md が、所有者（筆者）の依頼文として次のように引用しています。
ハトの生態や行動を論文なども含め詳細に調査したうえで、大阪・日本橋の地図データをもとにした 3D マップ上で、ハトが自律的に行動するアプリ（または動画一式）を作ってほしい。実際のハトの視点を再現し、最初は眺めるだけでもよいが、いずれは操作できるのが理想。
筆者はこの依頼を、半分冗談のつもりで出しました。出てきたのは、筆者の体感で依頼から約 10 分後です。想定以上の品質で、動く形の初版でした。この所要時間は筆者の申告による概算で、計測した記録ではありません。
この 1 文には、調査、実在の地図、自律行動、鳩の視点、将来の操作という 5 つの要素が入っています。docs の記録では、初版（v1）は同じ 10-24 に納品されたとあり、観察、追跡、鳩視点、操作の 4 モードが最初から入っていました。「いずれは操作できるのが理想」と書いた操作モードも、初版に含まれています。
docs に残っている所有者の判断は次のとおりです。
| 日付 | 所有者の判断・指摘 | その後 |
|---|---|---|
| 10-24 | 建物と鳩をもっとリアルに、観察モードで鳩が遠い、餌まきの反応が分かりにくい（3 点） | 同日中に改善版を納品 |
| 10-24 | 「ハトがずっと飛んでいるが、普段見るハトは地上で採餌している。生態として正しいのか」 | 調査レポートと照合し、飛行に寄りすぎていた行動配分を是正 |
| 10-24 | 「鳩も場所もリアリティをとことん追求してください」 | 以後の開発の基準になった |
| 10-31 | 公開リンクを新ビルドへ更新する指示 | 項目ごとに再検証 |
| 10-31 | 低速の時間設定がないと検証できない状況で、追加を選択 | ×1、×2 を追加 |
| 10-31 | 「ステップは観察条件の限界として記録し、この件は閉じてよい」 | 項目 7 を閉鎖 |
| 10-31 | OSS としての公開を指示 | リポジトリを作成 |
作り手の側（docs の言う「ビルダー」）は、ディープリサーチを実施して調査レポートを作り、地図データの選定、実装、納品、自己レビューを行ったと記録されています。調査レポート（docs/research/report.md）は 415 行あります。
完成物の構成
日本橋の鳩シミュレーションは、index.html 1 枚で完結しています。リポジトリを clone して実測した値は次のとおりです。
| 項目 | 実測値 |
|---|---|
index.html のサイズ |
1,883,363 bytes（約 1.88 MB） |
| 行数 | 3,884 行 |
| 自前の JavaScript | 約 3,315 行（3 ブロック） |
| CSS | 約 236 行 |
| 埋め込みの Three.js | r128（ミニファイ版、デコード後 603,445 bytes） |
| 埋め込みの街データ |
window.CITY（デコード後 631,567 bytes、建物 9,079 棟） |
| コードが通信する外部ホスト | Google Fonts のみ |
大きな 2 つのファイルは、<script src="data:application/javascript;base64,..."> の形で HTML に埋め込まれています。base64 にしたテキストは 804,596 文字と 842,092 文字で、合計約 1.65 MB です。ファイルの大半がこの 2 本にあたります。自前のコードは約 3,300 行で、ビルド工程の痕跡はなく、リポジトリには index.html、README、CHANGELOG、LICENSE、docs/ だけが置かれています。
この構成なら、静的サーバーに置くだけで動きます。README も、ローカルでは python3 -m http.server で配信する手順を案内しています。
論文をパラメータに落とす
アプリの「研究ノート」パネルには、行動パラメータの根拠が出典つきで書かれています。各項目には 3 種類のタグが付いていて、実測で数えると次の件数でした。
| タグ | 件数 | 意味 |
|---|---|---|
| 確立 | 20 | 査読論文や公的機関の資料で複数確認できた知見 |
| 設計案（演出値） | 21 | 根拠が弱いか、見た目のために置いた値 |
| 未検証 | 3 | 一次資料で確認できなかったもの |
「確立」の例として、巡航速度 8〜16 m/s、羽ばたき頻度は巡航で約 6.6 Hz、首振りの hold が歩行時間の約 63%、視野が約 320°（後方の盲域が約 40°）といった値が並びます。画面の左上にも、バーゼルの GPS 研究（Rose et al. 2006）を出典に「都市ドバトの 32% 以上は、ねぐらから 0.3 km 以内に留まる」という生態メモが出ます。
「未検証」には、一般向けサイトにある最高速度 125〜149 km/h 級の数字を査読一次資料で確認できなかったこと、日本橋が PLATEAU の LOD2 の範囲に入るか断定できなかったことなどが書かれています。分からないことを推測で埋めず、分からないと書いてある点は、この作品の中でも評価できる部分です。
ただし、論文の数値そのものが正しいかどうかは、この記事では検証していません。ここで紹介しているのは、アプリと docs/research/ に書かれている内容です。
次に、街のデータです。調査レポートは、地図データに国土交通省の PLATEAU 大阪市（2022 年度）の LOD1 を推奨していました。一方、研究ノートには、初版は Web 静的配信での軽量さを優先し、OpenStreetMap（2026-10-24 取得、日本橋周辺の約 1.9 × 1.8 km）から構築したと書かれています。docs の開発の経緯では、実データの取得と統合が先に成立したためと説明されています。PLATEAU への差し替えは将来の候補として残されています。
建物の高さは、出どころが 3 つに分かれます。
| 高さの出どころ | 棟数 | 扱い |
|---|---|---|
OSM の height タグ |
4,706 | そのまま採用 |
building:levels × 3.1 m |
981 | 階数からの換算 |
| フットプリント面積からの推定 | 3,392 | 設計案（演出値） |
合計は 9,079 棟で、約 37%（3,392 棟）の高さは面積からの推定です。窓や階線、屋上の設備、鳩の羽模様も手続き生成のテクスチャによる演出で、実在の個別の建物や個体を再現したものではありません。鳩の描画サイズは視認性のために実寸の 1.6 倍で、速度、高度、距離、接地の計算だけが実寸スケールです。
このため、実在の街と生態に基づいたシミュレーションではあっても、論文準拠の正確なシミュレーションとして読むのは誤解になります。「街は実データ、鳩は調査値、見た目の細部は演出」という 3 層で受け取るのが実態に近いです。
動作確認の結果と限界
この記事を書く時点で、リポジトリの clone を python3 -m http.server 8765 で配信し、Playwright の Chromium で開きました。クラウドのコンテナには GPU がないため、WebGL はソフトウェア描画です。
const { chromium } = require('playwright');
const b = await chromium.launch();
const p = await b.newPage({ viewport: { width: 1440, height: 810 } });
await p.goto('http://localhost:8765/index.html', { waitUntil: 'load' });
3 回の実行で確認できたことを表にします。
| 実行 | 条件 | 結果 |
|---|---|---|
| 1 | 1280x720、SwiftShader 系のフラグ付き | load まで約 8 秒。console の error と warning は 0 件、pageerror 0 件、requestfailed 0 件 |
| 2 | 1280x720、フラグなし | load まで約 6.8 秒。error 0 件。GL ドライバーの性能 warning（GPU stall due to ReadPixels）が 4 回 |
| 3 | 1440x810、ボタンを順にクリック | error、pageerror、requestfailed とも 0 件。どのクリックでも例外は出ず |
3 回目でクリックしたのは、「鳩に寄る」「追跡」「鳩視点」「紫外線視」「雨」「路面で見る」「夕方へスキップ」「研究ノート」です。画面では次のことを目視で確認できました。
- 左上に時刻、群れの内訳（実行時は「24 羽（地上 9・止まり 15・飛行 0）」）、天候、出典つきの生態メモが表示される
- 追跡モードでは「注目：ジン／止まって休んでいる」のタグとリングが鳩に付く
- 鳩視点では、左下に「鳩の視野（水平面）」の図（前方の両眼視野 約 20°、後方の盲域 約 40°）が出る。紫外線視を入れると画面がピンク寄りの疑似カラーに変わる
- 路面で見るでは、自動販売機、電柱、架線、マンホール、阪神高速の高架、看板が見える
- 天候で「雨」を押すとチップが「雨 22℃」に変わり、群れは飛行 18 羽の状態になる
鳩視点で紫外線視を入れた画面です。左下の視野図と、ピンク寄りの疑似カラーが出ています。
路面で見るモードの画面です。自動販売機、電柱、架線、阪神高速の高架が確認できます。
研究ノートを開いた画面です。論文名つきの項目に「確立」「設計案」「未検証」のタグが付いています。
見つかった粗さもあります。1280x720 と 1440x810 のどちらでも、右上のボタン群が右側のテレメトリパネルのタイトル行（「注目個体 テレメトリ」）に重なり、タイトルが隠れました。docs の検証項目は路面の小物や鳩の外観が中心で、この UI の重なりは記録に出てきません。
1440x810 の追跡画面です。右上のボタンの下で、「注目個体 テレメトリ」のタイトルが途切れて隠れています。
確認できていないことは次のとおりです。
- 操作モード（群れのリーダーとして自分で飛ぶ）
- 実 GPU での描画負荷とフレームレート
- 天候の自動遷移と、雨や雪の見た目の質（「雨」を選んだ後の HUD の変化までしか見ていません）
- 季節の手動切替、ハヤブサの襲撃、餌まきのイベント
- モバイル端末での挙動
ソフトウェア描画での読み込み時間は、実 GPU での体感とは一致しません。「エラーなく開いて主要ボタンが動く」ところまでが、確認できた範囲です。
初版から改善へ
docs には、初版のあとに加えられた改善が記録されています。
初版の時点で、OSM の実データによる 9,079 棟の街、24 羽の鳩、4 モード、餌まきとハヤブサのイベントが動いていました。同じ 10-24 には、建物と鳩の改修、行動配分の再調整、季節と天候の仕組みの追加も記録されています。
その後の改善の中心は、見た目の判別確認でした。docs によると、街路レベルの判別確認（電柱と架線、自販機、マンホール、横断歩道、遮音壁、首の虹色、赤い脚、袖看板の文字、川面の質感）が未完了のまま残っていました。セルフレビューは、原因を 3 層で整理しています。
- 監査用の環境がソフトウェア WebGL で、読み込みの上限が 15 秒だったため、デスクトップ解像度の初回描画が収まらなかった
- 監査経路を唯一の検証経路として扱い、公開リンクを実ブラウザで開く独立した経路を試していなかった
- 失敗が納品報告の留保に埋もれ、担当と次の手を持つ未完了項目として残らなかった
そこで「監査キャプチャの失敗は検証の終端状態ではない。独立経路を必ず 1 回試し、それでも確認できない項目は担当と次の手つき付きで記録に残す」という運用ルールが作られました。
項目ごとの再検証の結果は、docs/improvement-log.md の表のとおりです。
| # | 項目 | 結果 |
|---|---|---|
| 1 | 電柱・架空線 | 部分確認（太い電柱と垂れた束は見えたが、束の本数は分離できず） |
| 2 | 自販機 | 部分確認（飲料ウィンドウと取り出し口は見えたが、価格帯は読めず） |
| 3 | マンホール | 確認 |
| 4 | 横断歩道・車線表示 | 部分確認（停止線・中央線・矢印は個別に判別できず） |
| 5 | 半透明の遮音壁 | 部分確認（柱・レール・継ぎ目は分離できず） |
| 6 | 首の虹色 | 追加改善後に確認 |
| 7 | 赤い脚 | 色・太さ・歩行は確認。左右交互ステップは観察条件の限界として閉鎖 |
| 8 | 袖看板の文字 | 部分確認（縦書き様の印は見えたが、語は読めず） |
| 9 | 川面の質感・流れ | 部分確認（2 層の流れの分離は判別できず） |
9 項目のうち、完全に「確認」と書かれているのは 1 項目だけです。首の虹色は追加改善の後に確認、脚は色・太さ・歩行までで、残りの 6 項目は部分確認でした。
左右交互ステップは、4 回条件を変えても読み取れませんでした。対象の鳩が速度 0 km/h で留まったこと、距離約 10〜11 m では両脚が同色で奥の脚が体の陰に入ること、低速条件を作るために ×1 と ×2 を追加した後も脚が数ピクセルにしかならないことが理由として記録されています。所有者が観察条件の限界として閉じる判断をしました。docs は、これがモデルの欠陥の認定ではなく、ステップの実装がないことの証拠でもないと明記しています。
著者視点の所見
動かして docs を読み比べ、気づいたことを 4 つ挙げます。
1 つ目は、調査したことと、調査どおりに実装されることは別だったことです。 初版の鳩は飛びすぎていました。調査レポートには、実在のドバトは覚醒時間の大半を地上の採餌と止まり木での休息に使うと書かれていたのに、初版の行動配分は飛行に寄っていました。気づいたのは所有者の「普段見る鳩は地上で採餌している」という指摘で、そこから調査レポートと照合して直しています。論文を調べさせた事実が、行動の正しさを保証するわけではありません。
2 つ目は、検証の停滞が、成果物の欠陥ではなく検証経路の欠陥だったことです。 判別確認が止まっていた原因は、見た目の問題より、確認の手段が 1 本だったことにありました。独立した 2 本目の経路（実ブラウザ）を持った後は、確認が進みました。この記事の動作確認も、ソフトウェア描画の Chromium という 1 本の経路にすぎず、実 GPU や操作モードを見ていない点は同じ弱さを持っています。
3 つ目は、未確認のまま閉じるという判断が人の側にあったことです。 左右交互ステップは、4 回試して読み取れませんでした。ここで閉じるか、さらに条件を探すかを決めたのは所有者です。確認できなかった事実を、確認できなかったと記録して閉じている点を、この作品でいちばん信頼できる部分だと感じています。
4 つ目は、動かして初めて見える粗さが残っていたことです。 右上のボタンとテレメトリパネルの重なりは、docs の検証項目になく、実際に開いて気づきました。docs の記録がどれだけ丁寧でも、記録の対象から外れた部分は誰も見ていないことがあります。
何を任せられて、何を人が決めたかを整理すると次のとおりです。
| 区分 | 内容（docs の記録による） |
|---|---|
| 作り手の側 | 論文を含む調査と調査レポートの作成、地図データの取得と統合、実装、納品、自己レビューと原因の整理 |
| 所有者が決めた | 何を作るかの依頼、リアリティの方針、生態の誤りの指摘、公開リンクの更新、低速設定の追加、未確認項目の閉鎖、OSS 公開 |
| どちらか区別できない | 個々のコードや文章をどちらが書いたか |
まとめ
- 半分冗談で Meta の Muse に鳩の 3D シミュレーションを依頼したところ、筆者の体感で約 10 分で動く初版が出てきました（概算で、計測ログはありません）。その後、docs には見た目の検証と追加改善が記録されています
- 完成物は 1.88 MB の単一 HTML で、Three.js r128 と建物 9,079 棟の OSM データを base64 で埋め込み、外部通信は Google Fonts だけです
- 行動パラメータは「確立 20・設計案 21・未検証 3」のタグで出典が示されていますが、建物の約 37% は高さが推定の演出値で、論文準拠の正確なシミュレーションではありません
- クラウドのソフトウェア描画では、エラーなく開いて主要ボタンが動きました。操作モード、実 GPU の負荷、天候の自動遷移などは未確認です
- 検証で見つかった粗さ（ボタンとパネルの重なり）は docs に記録がなく、どこまでが Muse の出力かは docs から区別できません
筆者の体感では、動く初版までは驚くほど早く届きました。その後の作業は、動くものを疑って確認し、確認できなかった範囲を記録することでした。
関連記事
- Meta Muse Spark入門 — HealthBench首位・Contemplate modeの全貌と活用ガイド
- Meta Muse Spark入門 — Contemplating Modeと並列推論エージェントの全貌