即興演劇データの収集・$96誘導ロケット・決定木の可視化 (2025-07-14)
音声AIの次の競争軸は「感情が生起するプロセス」のデータにある
HandshakeがOpenAIなどのAIラボ向けに、即興演劇俳優のビデオ・音声データを収集し始めた。時給74ドルという設定で、スクリプトなしの即興シーンを演じさせ、感情の遷移・トーンの変化・キャラクターの一貫性を丸ごと記録する。
なぜ今この動きが起きているかは明確だ。ChatGPT Advanced Voice Mode、Grok、Claude Voiceなど、主要LLMが音声モードを本番展開した結果、「テキストは流暢だが感情的に平板」という弱点が可視化された。大規模Webコーパスには、感情の動的な遷移を記録したデータがほぼ存在しない。即興演劇はその空白を埋める数少ない人間行動のリポジトリだ。
核心はここにある。音声AIの感情表現訓練が必要としているのは、「感情を記述したテキスト」ではなく「感情が生起するプロセスのデータ」だ。驚き→動揺→受容という感情遷移が、音声の韻律・発話速度・間の取り方として数秒単位で記録される。即興演劇はまさにそのプロセスの連続で、驚き→動揺→受容という感情遷移が台本なしに数秒単位で起きる。ロールプレイ指示で生成したデータや、俳優が感情を「演じた」スクリプトベースの収録とは質が異なる。
ただし、この収集モデルには構造的な問題がある。即興セッションの品質は参加者の協力度・誠実さに完全に依存する。記事によると即興演劇コミュニティの一部は意図的なサボタージュを計画しており、「一流AIラボ向け」と謳うほどQAコストが跳ね上がる逆説が生まれる。
また、英語圏の即興演劇で収集したデータが日本語や他言語の音声AIの感情表現にどこまで転移するかは自明ではない。マルチリンガル音声モデルを開発するラボにとって、このデータの汎化性は大きな疑問符が残る。
開発者への示唆
音声・対話AIを自社プロダクトに組み込むなら、今すぐ感情表現の評価指標を定義すべきだ。「自然に聞こえるか」という主観評価だけでは開発の方向性が定まらない。感情遷移の速度、トーンの一貫性、文脈整合性を分離して測定できる評価セットを持っていないと、モデルの改善が進んでいるのか退行しているのかが判断できなくなる。
感情表現データを自社で収集するなら、「演じた感情」と「生起した感情」を区別する設計が必要だ。台本を与えた収録は前者になりやすく、モデルが学ぶのは感情の「記号」であって「プロセス」ではない。Handshakeが即興演劇に目をつけた理由はそこにある。
テキスト生成の品質は各社が収束しつつある。次の競争軸が音声の感情的リアリティに移るなら、その訓練データ調達コストは今後上昇する。Scale AIやHandshakeへの依存度を下げたいなら、独自のデータパイプラインを今から設計しておく必要がある。
2015年の決定木可視化が今も参照される理由
r2d3.usの「A Visual Introduction to Machine Learning」は2015年の記事だ。コードゼロ・数式ゼロで、決定木・過学習・汎化誤差という概念を直感的に伝えることに成功している。10年近く参照され続けている。
設計の核心は「概念を体験させてから名前を与える」という順序にある。
【例】これは認知科学でいう「具体から抽象」の学習順序に対応する。例えばr2d3.usでは、読者が「標高240フィート以上ならSF、以下ならNY」という直感的な仕切りを自分で試みた後に初めて「決定境界（decision boundary）」という用語が登場する。先に用語を定義してから例を示す従来の教科書と逆の構成だ。サンフランシスコとニューヨークの住宅データという誰でもイメージできる題材を選び、標高240フィートという単一の閾値から始める。スクロールに連動したアニメーションで、読者が「自分ならこの境界をどこに引くか」を考え始めた瞬間に、機械学習が「その判断を数学的に自動化するものだ」という理解が自然に生まれる。
「overfitting」という用語が初めて登場するのは、訓練データで100%精度の木を作り、テストデータを流すと精度が落ちる落差を「見た」後だ。従来の教科書と順序が逆になっている。
決定木を選んだのも偶然ではない。ニューラルネットワークやSVMと違い、決定木は中間状態を人間が追跡できる。「なぜその予測になったか」が木の経路として可視化できる。インタープリタブルなモデルを選ぶことで、アニメーションと概念が一致する。
この設計思想はLLM時代に逆説的な価値を持つ。GPTやClaudeは「なぜその答えになったか」を経路として見せられない。ブラックボックスが当たり前になればなるほど、「境界線を人間が確認できる」という決定木の特性が、AI説明可能性（XAI）の文脈で再評価されている。
また、この記事はD3.jsのデータバインディング機構を活用し、スクロール位置と決定木の分岐状態を同期させることで、データビジュアライゼーションを「ドキュメント」ではなく「思考の補助具」として機能させた初期の事例の一つだ。Observable NotebookやExcalidrawを使った技術解説の先駆けになっている。
開発者への示唆
機械学習モデルを選定するとき、精度だけで判断するのをやめるべきだ。決定木は精度でニューラルネットに劣ることが多いが、経路の追跡可能性という点で圧倒的に優れる。規制業界（金融・医療）でモデルを使うなら、説明可能性の要件を最初の選定基準に入れる必要がある。
過学習の検出を「精度の数値比較」だけで行うのは危険だ。決定木なら木の深さと検証精度の関係をプロットする。深さを増やすほど訓練精度は上がるが、検証精度が下がり始める折れ点が過学習の閾値だ。
チームや顧客にモデルの挙動を説明できないなら、そのモデルは本番に乗せるべきではない。この記事が2015年にやったこと、つまり「非専門家に決定木の分岐を追わせる」という体験設計は、今でも技術選定の説明責任として同じ問いを突きつけている。
ESP32とMPU6050で$96の誘導ロケットが飛んだ
GitHubのnovatic14/MANPADS-System-Launcher-and-Rocketは、$96で飛翔中に軌道を再計算するガイドロケットの実装だ。
【補足】MANPADSは「Man-Portable Air-Defense System（携帯式防空システム）」の略で、本来は肩撃ち式の対空ミサイルを指す軍事用語。このプロジェクトはその名称を借用したホビーロケットの実装であり、実際の兵器ではない。ただしプロジェクト名が軍事用語を直接使用している点は、法的・輸出規制上のグレーゾーンに触れる可能性がある（後述）。従来の軍用誘導システムは専用ASICと軍用グレードIMUで数万ドル規模だったが、このプロジェクトはその機能を$96で実現した。ESP32をフライトコンピュータとして搭載し、$5のMPU6050（6軸IMU）からの加速度・角速度データをリアルタイムで処理する。カナード翼をアクチュエータで動かして軌道修正を行い、折り畳み式フィンは射出時の収納を前提にした設計になっている。
ランチャー側にはGPS・コンパス・気圧センサーを統合し、目標方位と高度を計算してテレメトリーを送る。機体はFusion 360で設計し、OpenRocketで空力シミュレーションを回した後、3Dプリンターで出力している。ソフトウェアからハードウェアまでのスタックが全部オープンで再現可能な状態になっている。
【警告】誘導ロケットの設計・製造・飛行は国や地域によって厳しく規制される。日本では火薬類取締法・航空法・武器輸出三原則関連法令が関係し得る。米国ではITAR（国際武器取引規則）やEAR（輸出管理規則）の対象になる可能性がある。このプロジェクトを参考にする場合は、自国の法令を事前に確認することが不可欠だ。
このコスト構造が成立する理由は3つの要素が同時に揃ったからだ。ESP32の処理能力（240MHz dual-core）がリアルタイム飛行制御に十分なレベルに達した。FDM 3Dプリンターの材料（PETGやASA）が高温・高G環境に耐えられるようになった。OpenRocketのような空力解析ツールが無料で使えるようになり、試作サイクルを回せるようになった。
技術的に面白いのは、MPU6050のドリフト問題をどう処理しているかという点だ。MPU6050は積分誤差が蓄積しやすい低価格IMUだが、飛翔時間が数秒から十数秒の範囲であれば、ドリフトが致命的な誤差になる前に制御が完了する。逆に言えば、長時間飛行の無人機には同じアーキテクチャが使えない。このセンサーの限界が、このシステムの設計上限を規定している。
カナード制御の実装では、ESP32でPIDループを回す場合の制御周期とサーボ応答速度のバランスが設計の核心になる。カナードは機首付近の翼で、後方の主翼より小さな舵角で大きなモーメントを生み出せる。制御アルゴリズムの詳細がコードに実装されており、そこが再現性を左右する部分だ。
開発者への示唆
ESP32でリアルタイム制御システムを作るなら、FreeRTOSのタスク分離を最初から設計に組み込むべきだ。センサー読み取り・PID演算・アクチュエータ出力を別タスクに分けないと、ループ遅延が制御性能を直接劣化させる。
【補足】PID（比例・積分・微分）制御は、目標値と現在値の差（偏差）に対して3つの項の和で操作量を決める古典制御手法。比例項は即時応答、積分項は定常偏差の除去、微分項は急激な変化への先行制動を担う。ロケットのカナード角度制御のように応答速度が要求される系では、各項のゲイン調整（チューニング）が安定性を左右する。このプロジェクトのファームウェアコードはその実装例として読む価値がある。
MPU6050を使う場合、DMP（Digital Motion Processor）機能を使うかソフトウェアで姿勢推定するかを最初に決める必要がある。DMPはオフロード処理で楽だが、ライブラリの品質にばらつきがある。自前で相補フィルターやマドウィックフィルターを実装する方が挙動を把握しやすい。
【補足】相補フィルターは加速度計（低周波成分が正確）とジャイロスコープ（高周波成分が正確）の出力を重み付け合成して姿勢角を推定する手法。マドウィック（Madgwick）フィルターはその発展版で、四元数（クォータニオン）を用いて3次元姿勢を計算し、計算コストが低いためマイコンへの実装に向く。どちらもカルマンフィルターより実装が単純で、ESP32クラスのMCUで十分リアルタイム動作する。
3Dプリント部品で動的荷重がかかるシステムを作るなら、OpenRocketのような専用シミュレーターで空力荷重を先に計算してから材料と積層方向を決める順序が正しい。逆順で作ると、テストで壊れてから設計を見直すことになる。
今日の傾向
3つのトピックに共通するのは「希少性の崩壊」だ。感情プロセスのデータ、機械学習の直感的理解、誘導システムの実装——いずれも数年前まで大規模組織か専門家集団にしかアクセスできなかった領域が、個人・小規模チームの射程に入ってきている。
ただし崩壊の仕方は一様ではない。MANPADSは部品コストの崩壊だ。r2d3.usは専門知識の民主化だ。Handshakeの即興演劇データ収集は逆方向で、大規模Webコーパスでは代替できない「人間の感情プロセス」という希少性が新たに発見され、その調達コストが上昇し始めている。
コスト崩壊が進む領域と、希少性が再発見されて価値が上昇する領域が同時に動いている。開発者にとって問うべきは「自分が依存しているリソースはどちらの方向に動いているか」だ。