過去 15 年のどこかで、ウェブはひそかに、すべての重要なサイトにはモバイルアプリも必要だと 決めました。HTML が動かなくなったからではなく、アプリが 制御された表面 だからです。 すなわち、キュレーションされた一連のアクションであり、自分が選んだのではない chrome は なく、一つの対話の仕方のために構築されたインターフェースなのです。
私たちは、同じ動きが、別のユーザー層と別のインターフェース群のためになされるのを待って いると考えています。みんなが自分のサイトを Android アプリに変えるなら、私たちはサイトを 音声アプリに変えられます — そしてコマンドラインアプリにも、スクリーンリーダーネイティブ なフローにも。同じ発想で、逆方向です。サイトを、あなた が対話したい方法のために構築された 表面で包むのです。ただしその表面は、タッチスクリーンではなく、あなたの声とあなたの ターミナルです。
ウェブは耳ではほとんど使えない
マウスを持つ晴眼のユーザーにとって、現代のサイトは問題ありません。音声で、あるいは スクリーンリーダーを通じて、あるいはターミナルから閲覧する人にとって、ウェブの大部分は 敵対的な環境です。無限スクロールの壁、クッキーバナー、ポップアップ、ポインターを必要と するメニュー、3 層のインタラクティブな雑物の下に埋もれたコンテンツ。情報はそこにあります。 それをハンズフリーで取り出すのは、惨めなものです。
いつもの答えは「サイトはもっとアクセシブルであるべきだ」であり、実際そうあるべきです。 しかし、丁寧にお願いすることでウェブ全体を直すことはできません。私たちが できる ことは、 重要なサイトを取り上げ、それぞれにきれいな、話せるインターフェースを構築することです — アプリストアがタッチのためにやったように、ただし音声と CLI のために、そしてオープンに。
2 つの層：きれいな API、それから音声スキル
これらの音声アプリはどれも 2 つのピースを積み重ねたものであり、私たちはすでにその両方を 構築しています。
第 1 層 — サイトを API に変える型付けクライアント。 これはまさに私たちの スクレイピングと API リバースエンジニアリングの仕事 です。使える公開インターフェースを持たないサイトに手を伸ばし、脆い HTML ではなく構造化 された型付きのオブジェクトを返します — スクレイピングではなく、動詞を：
from py_bandcamp import BandCamp
for release in BandCamp.search_albums("king gizzard"):
artist = release.work.credits[0].entity.name if release.work.credits else ""
print(release.work.title, artist, release.uri)その下にある偵察と
アンチボット・トランスポート
のツールが、サイトが変わってもそのアクセスを機能させ続けます。そのクライアントは、それ
自体ですでに有用です。ターミナルユーザーにとって、API こそ がそのウェブサイトの
アクセシブルなバージョンなのです — 私たちの SoundCloud クライアントは、ブラウザを一切
使わずに音楽を検索・再生するコマンドラインアプリである nds まで同梱しています。ひとたび
サイトが API になれば、それは視覚的なアーティファクトであることをやめ、機械 — あるいは
音声パイプライン — が駆動できるものになります。
第 2 層 — その API を話す OVOS プラグイン。 クライアントの上には、話された意図を API 呼び出しにマッピングし、私たちの オフライン TTS 音声 で結果をナレーションする OpenVoiceOS プラグインが乗ります。 それは意図的に、サイトごとのあつらえのスキルでは ありません — その道は、誰も維持できない 数十もの使い捨てスキルへとつながります。メディアの形をしたものについては、それは OCP プロバイダープラグインです。 サイトの検索・再生の表面を Open Common Play フレームワーク全体に公開する一つの小さな アダプターであり、「検索」「再生」「次へ」「再開」が、他のあらゆるソースと同じように すでに機能します。サイトは独自のものを発明するのではなく、統一された音声インターフェースに 組み込まれるのです。
その結果：「SomaFM の Groove Salad チャンネルを再生して。」「Bandcamp で Creative-Commons の ambient を検索して。」ウェブサイトが、見ずに使えるもの — そしてサイトごとに新しい文法を 学ぶ必要のないもの — へと変わります。
LLM の時代には、型付き API は自然言語 UI が生まれるのを待っている
この形が 5 年前よりも今のほうが重要である第 2 の理由があります。きれいな型付き クライアントは、大規模言語モデルがウェブサイトへの 自然言語フロントエンド になるために まさに必要とするものなのです。
LLM に文書化された一連の関数 — search_albums、get_recommendations、stream_url — を
与えれば、「Naxatras みたいで、でももっと重いものを見つけて」を喜んで正しい呼び出しに
翻訳し、それらを連鎖させ、結果を話して返してくれます。構造化された API が難しい部分です。
その上の会話インターフェースは、手渡されるツールが適切に型付けされ、何を返すかについて
誠実である限り、モデルがますます単に 提供する ものになっています。乱雑な HTML は LLM に
つかまるものを何も与えません。型付きクライアントは、それに制御表面を与えます。
だからこそ、私たちのウェブサイトクライアントには SKILL.md が同梱されています — API が
何をするか、その動詞、その戻り値の型、そして呼び出しの例を、エージェントが読むために
書いた、平易な言葉による説明です。LLM 駆動のアシスタントをそこに向ければ、クライアントは
モデルがすぐに使えるツールになります。グルーコードなし、あつらえの統合なし、ただ「この
サイトができることは、言葉にするとこうです」だけです。一つの文書が、スクレイパーを、言語
モデルがあなたに代わって操作できるものへと変えます。
同じ構造化データが、一度に 3 つのフロントエンドに供給されます。ターミナルユーザーのための CLI、ハンズフリー利用のための OCP/音声プラグイン、そして自然言語制御のための LLM ツール です。API を一度構築し、それを 3 通りに着こなすのです。
なぜこれが画面を見られない人々にとって最も重要なのか
盲目や弱視のユーザーにとって、これは利便性の機能ではありません — アクセスと排除の 分かれ目です。スクリーンリーダーは、ページがきれいに公開するものしか読めず、ほとんどの ページはそうしません。専用の音声アプリはページを完全に飛ばします。構造化データへ行き、 コードの最初の行から聞くために設計されたフローで、それ を話すのです。
それは、私たちの オーディオファーストのゲーム の背後にあるのと同じ原則です — 目ではなく耳のために構築され、盲目のプレイヤーを後付けではなく主要な対象として据えて います。ウェブサイトのための音声アプリは、その原則をゲームからウェブの残りの部分へと 広げるものです。
一度に 1 サイトずつ — しかし向かう先は音声ブラウザ
正直な部分をお話しします。普遍的な近道はありません。「ウェブ」を一度に音声対応させることは できません。なぜなら、どのサイトもそれ自身のもつれだからです。それは サイトごとに 行わなければなりません — 一度に一つのクライアント、一つのスキル、注意深くマッピングされた 一連の意図です。それは制約のように聞こえますし、短期的にはそのとおりです。
しかし、その積み重ねがどこを指すかを見てください。私たちが包む各サイトは、今や音声と CLI で到達できるようになったウェブのもう一つの片隅です。それらを十分な数だけつなぎ 合わせれば — 共通のメタデータ語彙、共有された音声層、「検索／開く／読む／再生／次へ」の 一貫した一連の意図 — もはや別々のスキルの山を見ているのではありません。音声ブラウザ の始まりを見ているのです。話すことでウェブを移動する方法であり、個々のサイトは、すでに どう応えればよいかを知っている行き先にすぎません。
モバイル時代の賭けは、使う価値のあるサイトはアプリに値するというものでした。私たちの 賭けは、使う価値のあるサイトは 声 に値するというものです。私たちはそれらを一度に一つずつ、 オープンに構築しており、その一つ一つが、視覚的なウェブが置き去りにした人々にとって、 ウェブを少しだけ閲覧しやすいものにしています。
特定のサイトを音声アプリや CLI アプリに変えたいですか — アクセシビリティのため、あなたの 製品のため、あるいは単にそれが存在すべきだから？お話ししましょう。