しまなみ海道のライド記録を、StreetWarpのWEBサイト(streetwarp.com)でハイパーラプス動画にした。だが完成した動画にはブロックノイズが目立ち、画質に満足できなかった。もっときれいな動画を作れないか。そう考えて、GitHubで公開されているストリート・ビューを動画化するコードを用いて実験した。Claude Fable 5は他の用事で忙しかったので、Claude Sonnet 5にお願いしている。
StreetWarp
StreetWarpはローカル環境でも動く。実体はRust製のCLIツールstreetwarp-cliで、GoogleのStreet View Static APIを使う。Homebrew経由でRustを導入し、GitHubからダウンロードしたソースをビルドした。依存クレートのバージョン不整合があったので、これはcargo updateで解決した。他には問題なく利用できたので、よくメンテナンスされているようだ。
当初はWEB版StreetWarpでの画像の粗さは解像度（ピクセル数）に起因すると考えた。しかしAPIのドキュメントによると、上限は640×640ピクセルだった。そして実際にCLI版が出力した画像はWEB版と大差なく、やはり粗い。そもそも低解像度の画像を引き伸ばした粗さとは異なる種類の粗さだから、高解像化できたとしても解決できないかもしれない。
次に移動間隔を小さくして見栄えが良くなることを試してみた。移動間隔はstreetwarp-cliのオプションであるframes-per-mile（1マイルあたりのフレーム数）で指定し、デフォルトは100、すなわち約16m間隔。そこで5m間隔としてframes-per-mile=322と指定した。これで確かにフレーム数が増えて時間的に滑らかになっているハズ。しかし画像そのものは相変わらず粗い。
このように試行錯誤しているうちに気がついた。歪みの犯人はフレーム補間だった。これはffmpegのminterpolateフィルタを使って合成フレームを生成する処理だ。だが、フレーム間の差異が大きすぎるのだろう。結果的に歪んだ画像になっていたわけだ。このフレーム補間を指定するminterpオプションにskip（補間なし）を選べば、撮影されたままであろう歪みの少ない画像になる。
なお、WEB版ではSmoothボタンがデフォルトのgoodに当たり、歪みが生じる。もう一つのFastボタンはfastの指定でブレンド処理として軽い補間を行う。これらのフレーム補間によって映像が滑らかに見えるとしても、少なくともライド動画としては逆効果だったわけだ。ただ、しまなみ海道だけでなく、より緻密であろうサンフランシスコでも同様だったので、このオプションの意図は謎である。
streetview-dl
こうしてStreetWarpで歪みのない映像が得られたものの、使用しているStreet View Static APIの制約で640×640ピクセルを超える映像は得られない。そこで、GoogleのMap Tiles APIを使うPythonパッケージstreetview-dlを利用することにした。これはCLIおよびライブラリとして利用できるので、今回はより柔軟な制御ができるライブラリとして用いた。
Map Tiles APIでは、ある地点で撮影したパノラマ（360°全天周）映像が得られる。実際には全天周を構成する複数のタイル画像のセットなので、APIの名称の由来になっている。このMap Tiles APIを使ってstreetview-dlはルートの地点ごとのパノラマ画像を取得する。そして必要な範囲を透視投影画像に変換し、それをフレーム画像として動画化する。
この方式は大量のデータを取得すると予想されたので、東京で短めのルートを設定し、そのGPXデータを用いた。こうして得られた動画には斜めを向いた画像、黒い画像、さらには路上ではない画像が混じる問題が生じた。ある程度は改善できたものの、路上ではない画像は解消できなかった。地点を指定してMap Tile APIを呼び出すと地下や店舗内の画像が得られることがあり、これを制御できないからだ。路上走っているのに急に地下に潜るのは面白い。だが、目的からは逸脱してしまう。
ちなみに一つのタイルは512×512pxで、一地点のパノラマ画像を構成する最大タイル数は横に32、縦に16で、全部で512タイルになる。従ってパノラマ画像の最大サイズは16,384×8,192px。これをStreetWarpと同じ水平視野角100°、アスペクト比4:3で切り出すと4,551×3,413pxになる。これでStreetWarpより遥かに解像度が高い画像が得られることになる。
GSV-hyperlapse
地下に潜ってしまうMap Tiles APIは諦めて、別の方式を使うGSV-hyperlapseを試した。何とこれはWEB版Googleマップが使用する内部APIだ。この非公式APIはMap Tiles APIと同じく、ある地点のパノラマ画像をタイル分割して配信する。ただし、検索エンドポイントや検索インデックスは異なる。認証なしでAPI使用料も発生しない。将来の保証はないけれど、それは公式APIとて似たり寄ったり。
GSV-hyperlapseはGPXファイルには対応しておらず、Directions APIで2地点間のルートを計算して用いる。そこで、streetview-dlとの比較のために、同じ東京のルートになる2地点を指定して映像を生成した。実際の走行データから映像化できないので、これは後に改善することになる。ちなみに、レガシー扱いのDirections APIは無効化されているので、有効化する必要がある。
このようにして映像を生成すると、streetview-dlと同じルートでも地下に潜ることはない。解像度は、streetview-dlもGSV-hyperlapseも地点によって異なるが、最大で16,384×8,192pxのパノラマ画像が得られる。これを視野角やアスペクト比によって切り出すのも同じ。撮影密度にも上限があり、このルートでは間隔を詰めても約100枚だった。これは大きな問題で、次の節で詳しく検証する。
ところで、撮影地点は等間隔ではないので、フレームごとの表示時間を変えることも試してみた。これは理にかなっているようで、実際に見ると非常に奇妙に感じる。その原因は撮影間隔が長い区間が多々あるためだ。そして可変フレーム時間の映像など見たことがないからだ。実時間を反映していなくとも、等間隔でフレームが流れる映像に慣れきっているわけだ。
GSV-hyperlapse+GPX
これまで試した3方式では、GSV-hyperlapseが高解像であり映像が破綻しない。そこでGSV-hyperlapseのコードをモジュールとして利用し、独自パイプラインとしてGPXファイルを入力できるようにした。方位はGSV-hyperlapseの方位角計算をそのまま使っている。東京の同じルートで検証すると、既存のGSV-hyperlapseの実行結果と完全に一致した。
一方、しまなみ海道の実走データで試したところ、見つかったパノラマが全ルートのごく一部しかなかった。つまり、全ルートの映像化ができていないという大問題。実際に検証すると僅か1.7%しか取得できておらず、実用にならない。他の方式では90%前後であったので、こちらの結果は極端に悪い。とは言え、バグ・レポートを出して改善を求めるわけにはいかないのが、非公式APIの辛いところ。
ちなみに、パノラマの取得数が少ない理由として、しまなみ海道はグラベル道なのでストリート・ビューの撮影が行われていないから、とClaudeは推察した。しかし、実際に走ったコースはすべて舗装道路であった。これはGPXデータに含まれる「グラベル・ロード」という車種の情報から勘違いしたようだ。身体と経験を欠く AIらしい間違いだ。フィジカルAIの必要性を痛感する。
ここで、以下に3つのライブラリの特徴をまとめておく。GPX対応以外は使用しているAPIの特徴だ。StreetWarpは画像の解像度が低く、streetview-dlは画像の妥当性に問題があり、GSV-hyperlapseは画像の網羅性に問題がある。つまり、どれも一長一短であり、ストリート・ビューと同等の機能にはならない。まだまだ探求すべき秘密のメソッドがあるのだろう。
| StreetWarp | streetview-dl | GSV-hyperlapse | |
| 使用API | Street View Static API | Map Tiles API | 内部API |
| プログラミング言語 | Rust | Python | Python |
| 最大解像度 | 640×640px | 4,551×3,413px(*) | 4,551×3,413px(*) |
| GPX対応 | 対応 | 対応 | 非対応 |
| 妥当性 | 妥当 | 問題あり | 妥当 |
| 取得数（しまなみ） | 5,959/6,906 | 6,520/6,906 | 117/6,906 |
| 取得数（東京） | 370/393 | 393/393 | 191/393 |
| 制限 | 30,000クエリ／分 | 15,000タイル／日 | なし |
屍のその先へ
以上のように本稿は成功譚ではなく失敗の連続だ。ただ、失敗を公開することは有意義に違いない。同じ志を持つ人の礎になるからだ。WEB野郎ではない筆者にとって未知のGoogleのCloud APIも、Claudeなら自分の庭らしく、テキパキと作業を進めてくれる。まだまだ十分に探求し尽くしたとは言い難いので、是非、この屍を超えて行って欲しい。筆者ももう少しだけ取り組んでみるつもりだ。
【追記】初出時は4fpsであったstreetview-dl以降の3つのYouTube動画を6fpsとして入れ替えた。これは4fpsでは瞬間的な停止が周期的に起こっていたのを解消するためだ。非公式の経験則的な情報ではYouTubeでは6の倍数のfps（フレーム／秒）で動画を制作するのが良いそうだ。通常は24fpsや30fpsで6の倍数なので問題にならない。（2026.06.12）