For the complete documentation index, see llms.txt. Markdown versions of documentation pages are available by appending .md to the page URL.
メインナビゲーション
Theme
Sep 23, 2026 Codex

GPT-Live-1 と Codex で作った、声に応える LED ディスプレイ

Codex、GPT-Live-1、Raspberry Pi を使い、LED ディスプレイを音声で操作できるアシスタントに作り変えた過程を紹介します。

著者: Sid Rampally

GPT-Live-1 と Codex で作った、声に応える LED ディスプレイ

ルームメイトの誕生日に、窓の外を飛ぶ飛行機の便名を表示する小さな LED ディスプレイを贈りました。なかなか面白いプレゼントでしたが、画面に次々と飛行機が現れるのを見ているうちに、飛行機を追いかけるほかにも使い道があるのではと思うようになりました。天気や自分の予定を表示できないだろうか。出かけるときに「次の電車は何時?」と声をかけるだけで、答えが画面に出たらどうだろう。

そこからすぐに、Raspberry Pi、128 × 64 の HUB75 LED パネル、Codex を使った個人プロジェクトが始まりました。そこで作ったアシスタントを、いつしか Jack と呼ぶようになりました。会話を担うのは、最近 API で提供を開始した全二重音声モデルの GPT-Live-1 です。調べ物には別のモデルを使い、画面の描画はレンダラーに任せています。もっとも、最初からここまで考えていたわけではありません。この記事では、今の形にたどり着くまでを振り返ります。

Codex と進めた HUB75 RGB LED パネルの立ち上げ

最初に Codex と取り組んだのは、このディスプレイに自分の表示したいものを出す方法を見つけることでした。手元にあったのは 128 × 64 の HUB75 RGB パネルですが、コントローラーにも配線にも詳しくありません。もともと表示されていたものとは別の内容を送る方法もわかりませんでした。

まずは Codex に写真を送り、何が写っているのか説明してもらいました。どこが重要な接続箇所なのか、ESP32 を搭載したコントローラーがどんな仕組みなのか、HUB75 パネルが実際にどうやって表示データを受け取るのかが、少しずつわかってきました。Codex は写真に印をつけて、注目すべき箇所まで示してくれました。自分ひとりで基板を眺めていたら、あちこちで見当違いの推測をしていたと思います。

ハードウェアの基本がわかったところで、Codex の助けを借りてコントローラー上で WLED-MM を動かし、パネルの解像度が正しく 128 × 64 に設定されていることを確認しました。これで自作のフレームを送れるようになり、この小さな画面で何がきれいに見えるのか、実際に試せるようになりました。調査とトラブルシューティングは Codex が担当し、私は実機の配線をして、予想と違う動きをしたらその様子を伝えました。

Mac での音声操作 LED ディスプレイの試作

最初に動いた試作品は、最終的にできたものよりずっとシンプルでした。コントローラーで WLED-MM が動くようになると、Codex と一緒にレンダラーとカスタムスキルを作り、ChatGPT デスクトップアプリの音声モードを使って、ディスプレイに何を表示したいか伝えました。

それだけで、ディスプレイの印象はすっかり変わりました。天気、自分の予定、地下鉄の到着時刻、金融チャート、メッセージ、カウントダウン、写真、アート作品、自作のアニメーションシーンまで表示できます。思いついたものをこの小さな画面に出してみて、見え方がいまひとつなら、そのたびにレンダラーを調整しました。

この段階では、音声のやり取りはまだ Codex の中で行っていました。Codex はカスタムスキルを使って、壁のディスプレイの表示内容を更新できます。そのレイアウトを Mac 上のレンダラーが 128 × 64 の RGB フレームに変換し、DDP を使ってローカルネットワーク経由で送信します。受け取ったフレームをパネルに表示するのは、WLED-MM を実行する ESP32 コントローラーです。

Codex に助けてもらったのは、各部分をつなぐ作業だけではありません。128 × 64 の画面では、使えるスペースが限られます。文字や画像、天気、カレンダーの予定、地下鉄の到着時刻を詰め込んで読めなくならないよう、配置を何度も工夫しました。見づらいところを伝えると、Codex がレンダラーやレイアウトを調整してくれます。そうして表示を試すうちに、待機画面も、普段からつけておきたいと思えるものになってきました。

問題は、まだすべてが私の Mac に依存していたことです。レンダラーが動いているのも、音声で話しかける先も Mac です。ノート PC がスリープしたり、外に持ち出したりすると、壁のディスプレイは思いどおりに使えません。本当は、仕事から帰ってきたら、そのまま壁に向かって見たいものを頼めるようにしたかったのです。

音声アシスタントとレンダラーの Raspberry Pi への移行

ノート PC がなくても使えるようにしたいと Codex に伝え、常時動かす必要のある部分を Raspberry Pi に移しました。コードはプライベートリポジトリに置き、バックアップを取り、何か壊してしまっても元に戻せるようにしました。私が Pi を接続したあとは、コードの起動やログの確認、発生した問題の解決を Codex が引き受けてくれました。その間、私はどんな動作にしたいかを伝え続けました。

今は Pi 上で、小さなサービスが 2 つ動いています。

  • 音声サービスは、マイク、PipeWire での音声処理、WebRTC のエコーキャンセル、呼びかけによる起動とスリープへの移行、発話への割り込み、GPT-Live-1 への接続、クライアント側へのタスクの委譲を担当します。
  • レンダラーサービスは、待機画面のアニメーションを動かし続け、天気と MTA 地下鉄の到着情報を更新します。サニタイズ済みのカレンダーデータを使用し、シーンの記述を検証して、壁のディスプレイにフレームをストリーミングします。

Pi にマイクとスピーカーをつなぐと、部屋に入って「Hey Jack」と呼びかけるだけで、コンピューターを開かずに頼み事ができるようになりました。呼びかけで起動する際の動作や応答の仕方には、しばらく時間をかけて手を入れました。でも、ノート PC で動かすデモから、いつでも使えるようにつけておけるものに変わったと実感したのは、Mac から切り離したときです。

GPT-Live-1 と Raspberry Pi の役割分担

最終的には、私と話す役目を GPT-Live-1 に任せ、壁のディスプレイへの描画はレンダラーが受け持つ構成にしました。GPT-Live-1 は自分が話している最中もこちらの声を聞き続けるので、会話の途中で口を挟めます。また、頼まれたことに応えるのに、会話以外の処理が必要かどうかも判断します。

処理が必要になると、Raspberry Pi がタスクを引き受け、クライアント側から Responses API にリクエストを送ります。使うのは、推論強度を低く設定した GPT-5.6 Luna です。Luna は公開されているウェブ情報を検索したり、読み取り専用の接続を通じて私のカレンダーを確認したり、Wikimedia Commons で再利用可能な画像を探したりできます。依頼に合うシーンの種類を判断するのも Luna です。

あるとき Jack に壁のディスプレイに写真を出してほしいと頼んだら、「できません」と言われました。レンダラーはすでに画像に対応していたのですが、画像を探して送るためのツールを音声アシスタントに渡していなかったのです。そこで Codex の助けを借りて Wikimedia Commons と接続し、依頼に合う画像を探して、ライセンスとクレジット表記を確認できるようにしました。パネルへの画像の収め方も調整しました。画面に合わせて画像が引き伸ばされないよう、Pi が縦横比を保ったまま 128 × 64 ピクセル以内にリサイズします。

機能を増やすたびに、それぞれの役割が入り混じらないよう Codex が手伝ってくれました。Luna に使わせるツールは Pi 上のコードが決め、どんな情報やシーンが必要かは Luna が判断します。レンダラーはシーンの JSON を検証してから、ちょうど 128 × 64 ピクセルの RGB フレームに変換します。そのフレームを DDP 経由で WLED-MM コントローラーに送ると、コントローラーが HUB75 パネルを駆動します。

ユーザーは Raspberry Pi を介して GPT-Live-1 と会話します。Pi は調査やツールを使うタスクを GPT-5.6 Luna に送り、結果を受け取ります。Pi 上のレンダラーから壁の LED ディスプレイにピクセルデータを送ります。

開発の初期には、ごく普通の会話でバグが見つかりました。Jack にニューヨークの天気を聞いてから「それを壁に表示して」と頼んでも、「それ」が何を指すのかわからなかったのです。Codex が調べると、アプリが表示を更新するモデルに渡していたのは、いちばん新しい依頼だけでした。そこで、直近の会話とそれまでに得られた結果も一緒に引き渡すようにしました。

「Hey Jack」と呼びかけてから LED ディスプレイに表示されるまで

Jack に何かを調べてディスプレイに表示してほしいと頼むと、おおよそ次のように処理が進みます。

  1. Raspberry Pi が私の声を 24 kHz の PCM 音声として取り込み、ローカルで音声処理を行います。
  2. GPT-Live-1 が音声ストリームを受け取り、依頼の内容を理解します。会話は続いているので、私が途中で口を挟んだり、補足したりできます。
  3. 依頼に応えるために、調べ物、カレンダーの情報、画像、壁のディスプレイの更新のいずれかが必要な場合、GPT-Live-1 がクライアント側に処理を委譲し、Pi が Responses API を通じて GPT-5.6 Luna にタスクを送ります。
  4. Luna は、その依頼に対して私が使えるようにしたツールを利用します。たとえば、ホスト型のウェブ検索、カレンダーへの読み取り専用接続、再利用可能な画像の検索、壁のディスプレイを更新するツールなどです。
  5. 天気、予定一覧、メッセージ、カウントダウンなど、依頼に合う既存のシーンがあれば Luna はそれを選びます。想定していなかったものを頼むと、新しいシーンを作ります。
  6. ローカルのレンダラーがシーンを検証し、128 × 64 の RGB フレームに変換して、DDP 経由で壁のディスプレイに送ります。その間に GPT-Live-1 が調べた結果を教えてくれます。

気に入っているのは、次に何か言いたくなったとき、音声アシスタントが話し終えるまで律儀に待つ必要がないところです。Jack の話に割り込んで、自分が言いたかったことを説明し直せます。その間も、調査と描画はバックグラウンドで進みます。

振り返ってみると、わりとシンプルな個人プロジェクトでした。HUB75 パネルも、ESP32 コントローラーも、Raspberry Pi も、音声モデルも、私にとっては初めてでした。以前の私なら、ディスプレイを開けて中を見たところで手を止めていたと思います。今回は Codex と一緒にひとつずつ仕組みを理解しながら進められました。知らないものに出会っても、その場で Codex に聞けました。

こんなふうに作ってみたいものがあって、どこから手をつければいいか迷っているなら、Codex に聞いてみてください。思った以上に先まで進めるかもしれません。