今回のポッドキャストの概要:
中国発のオープン・ローカルモデルを中心に、Qwen3の音声まわり（TTS/ASR）と、Kimi 2.5 Thinkingモデル、さらにそれらを動かすためのハードウェア規模感（H200＝アルファード比喩）について話しました。

• Qwen3 Text-to-Speechで音声クローニング
  　– 自分の声を3〜4秒程度でクローンして別テキストを読ませる実験
  　– 音声のみ／音声＋文字起こしの2パターンで学習させたときの違い
  　– 感情表現や話し方のクセをどこまで再現できるか、悪用リスクも含めた所感

• Qwen3の「音声設計（ボイスデザイン）」機能
  　– カスタムボイスとの違い
  　– テキストプロンプトで性別・ピッチ・話速・感情（怒り・明るさなど）、残響（ホールで喋っている感じ）まで指定できる話
  　– これまで「感情の乗った音声データで学習」していた手間が、プロンプト指定でどこまで代替できるかという期待

• Qwen ASR：多言語対応の新しい音声認識モデル
  　– 約1.7BパラメータのASRモデルが登場した話
  　– 対応言語が約30言語＋中国語方言22種と、Whisper以降久々の大型多言語ASR
  　– モデル側から直接タイムスタンプが出せるので、無音検出（VAD）と組み合わせて「どこで誰がしゃべっているか」まで取れるのでは、という構想
  　– Whisperからの乗り換え候補として、日本語精度にも期待している点

• Qwen VLM（Vision-Language Model）を触ってみた話
  　– 画像×テキストのQwen VLMも試してみて、かなり良い印象だったこと
  　– Qwen（クエイン）の読み方談義や、Alibabaがなぜここまで強力なオープンモデルを出してくるのか（技術力アピール／エコシステム狙いなど）について雑談

• Kimi 2.5 Thinkingモデル：1Tパラメータ級の巨大LLM
  　– Moonshot AIのKimi 2.5 Thinkingモデルが約1Tパラメータ、Hugging Face上のサイズ約595GBという規模感
  　– Kimi公式チャットサイトで試せること、DeepSeek的な位置づけ
  　– OpenAI GPT-4.2系・Claude Opus・Gemini 3 Pro等の“Thinking積み”と比較してもベンチマークは拮抗、一部タスクでは上回るスコアもあるという話
  　– ローカルで動かせる前提なら、API課金モデルに対抗しうるポテンシャルと、バックエンドに資源を持つプレイヤーが有利になる構図

• Kimi 2.5をローカルで動かすためのハードウェア規模
  　– M3 Ultra Mac Studio × メモリ512GBマシンを2台、Thunderbolt 5接続で非量子化モデルを動かした事例：24トークン/秒ほど出たという報告
  　– この構成で1台あたり約150万円級、それを2台＝約300万円という「車が買える」コスト感
  　– 1ビット量子化モデルなら、ストレージ＋RAM＋VRAM合計240GB＆24GB GPU 1枚程度でも10トークン/秒で動くというガイドライン
  　– フルモデルをGPUで回そうとするとH200 GPU×4枚クラス（1枚約500万→合計約2,000万円）という試算と、
  　　「H200 1枚＝アルファード1台」「アルファード4台が机の上に乗っている」的な比喩トーク

• H200＝アルファード比喩とインフラ時代の感覚
  　– 高級ミニバン級の価格のGPUが4枚必要、というスケールの話から、
  　　「APIを使うか自前でインフラを持つか」の判断軸
  　– そんな規模で仕事を回す面白さと、景気のよいハード投資談義

• Apple SiliconマシンとローカルLLMのこれから
  　– M4/M5世代Macのメモリ上限や構成の違い
  　– Apple Intelligenceの有無に関わらず、開発用ハードとしてMacが強く求められている感覚
  　– Claude Codeなどによる開発自動化と、ローカル巨大モデルの登場で、今後の開発スタイルがさらに変わっていくのでは、という展望

次回もお楽しみに。

概要:
巨大データ処理で活躍したParquet＋Polarsの話から、開発環境を快適にするzoxideやStarship、そして数学の証明もできるプログラミング言語Leanまで、2026年のはじめに試した技術・ツールについて話しました。

• Apache Parquet（パルケ／パークエット）とは
• CSVとの違い（行指向 vs 列指向）
• カラムごとにデータをまとめることで、必要な列だけを高速に読み出せる構造
• Row Group／Column Chunkという単位で保存され、並列処理と相性が良い
• フッターにスキーマ（型情報）を埋め込むことで、型推定不要＆圧縮効率アップ

• ランレングス圧縮・辞書圧縮などにより、CSVよりも小さいサイズ＆高速読み込みを実現

• Parquet＋Polarsで1000万〜1400万行をさばいた話

• 1000万行のCSV処理でI/O待ちがボトルネックになり、CPUコア（32コア）が遊んでいた問題
• データをParquetに変換＋Polarsを利用することで、読み込みが約30倍高速化
• Polarsの
  • ストリーミングモード：ファイルと接続しつつ少しずつ処理
  • レイジーモード（遅延実行）：フィルタやマップをチェインして、最後に一括最適化実行
• それでも1400万行ではI/Oが張り付き、CSVでもParquetでも厳しい状況に
• 解決策：メモリを大量に積んだインスタンスを借り、ストリーミングせず全データをメモリ上でイーガー（即時）実行
  • 「金で殴る」戦略で処理が一瞬で終わるように
• データベースや分散処理（DuckDBなど）が本来向いている領域だが、制約の中でのベストプラクティスとしての選択

• CSVとParquetの使い分け（ヒューマンリーダブル vs 型付き・高速・大規模向き）、手札を増やすことの大事さ

• zoxide：次世代CDコマンド

• cdコマンドの「賢い」代替として使えるツール
• 一度訪れたディレクトリを学習し、曖昧な入力からジャンプできる
  • 例：cd doc で、どこにいても「documents」的なディレクトリに飛べる
• 深い階層や長いパスを毎回フルで打たなくてよくなる

• コマンド自体は z だが、ホストは cd にエイリアスして完全な置き換えとして使用中

• Starship：リッチなシェルプロンプト

• ターミナルのプロンプトをカラフルかつ高機能にするツール
• Gitリポジトリの状態、使用中の言語ランタイムやバージョン（例：UV管理下のPython 3.x）などを自動表示
• 見た目がきれいになるだけでなく、「今このディレクトリはどんな環境か」を一目で把握できる

• そこまで意識して凝視はしていないが、入れておくと地味に便利な存在

• Lean：数学の証明もできる関数型言語

• マイクロソフト発の定理証明支援・関数型プログラミング言語
• 数学の証明（定理・公理系の形式化）にも使われる一方、普通のプログラミング言語としても利用可能
• 現在ホストがやっていること：
  • 四則演算をする簡単な電卓プログラムをLeanで実装（パーサ付き）
  • いずれは本格的な研究にも組み込みたい構想
• 「証明」とは何か：
  • 例：ペアノの公理系で自然数を定義
  • 0があり、その「次の数（サクセッサ）」として1, 2, 3…を定義する
  • 足し算のルールなどを公理として書き、そのルールから「1+1=2」が導けることを機械的に証明
  • Leanでは、ループや再帰が「必ず停止する」と証明されないと実行できない構造もあり、無限ループを防ぐ
  • ソート関数がどんな入力でも必ず終了し、正しく並び替えることなども数学的に保証できる
• 数学・論理・型システムを通じて、「AI時代でも残る問題解決力」を鍛える道具としての側面
• かなり難易度は高めなので、未経験の人はまずHaskellから入るのが良さそう、という話

今回のポッドキャストの概要:
Replicube の話から、AIと学校教育の関係、そしてSpotify APIで集計した2025年のポッドキャスト年間レポートを振り返りつつ、来年の展望（「1200%成長」宣言）について話しました。

• Replicube と「プログラミング×パズル」教材の可能性

  • Replicube ファミ通記事
  • シェーダープログラミング的な3Dパズルとしての仕組み
  • GitHubクローンをベースにPython版を作る話
  • プログラミング教育用ゲームとしてのお題拡張のしやすさ

• AIに頼りすぎる12歳？探偵ナイトスクープの回から考えるAIと学校教育

  • AIに頼りすぎる12歳の娘…これは学校教育の崩壊なのか！？
  • 人権標語をAIで生成して賞を取った事例
  • 「AIで作っても受賞は嬉しい」という価値観ギャップ
  • 「AIばかり使うとバカになる」というステレオタイプ批判
  • 選考側（審査員）の基準・「お気持ち」に最適化するゲーム性の話
  • 学校教育がAIとどう付き合うべきか、崩壊なのか進化なのかという視点

• 2025年ポッドキャスト年間レポート振り返り（Spotify API集計）

  • 今年のエピソード数・配信ペース
    • エピソード数：28本（テスト含む）
    • 平均37分／本、最長50分・最短25分
    • 投稿間隔：平均2週間に1回前後
    • 最長の空白期間：7/13〜8/26（マット氏の北海道一周旅行期間）
  • 前半と後半の更新頻度の差
    • 1〜4月はほぼ毎週更新
    • 7〜8月は各1本、後半は仕事多忙でペースダウン
  • 今年よく話したテーマ
    • AI/LLM（Claude Code, DeepSeek, OpenAI, Gemini, MCP, エージェントなど）
    • 開発ツール（uv, ruff, pyproject.toml, Codex CLI, Ghosttyターミナルほか）
    • ハードウェア（M4 Mac、Xreal One、Apple Watch Series 10 など）
    • 3Dプリンタ（Bambu Lab）、Tauri など
  • 旅行・生活系ハイライト
    • 北海道一周＋利尻山登山（約6200km・16日間）
    • 別府・二日市温泉、有田陶器市、宮崎シーガイア など
  • 社会・経済＆交通ネタ
    • チームみらい、残クレアルファード、米価高騰
    • JR九州運賃改定、八木山バイパス有料化、西鉄バス減便、二重決済問題 など
  • クロードによるメタまとめの所感
    • 「技術だけでなく、趣味・生活・社会問題まで幅広くカバー」
    • 「DLsiteやトレンドニュースなど独自ネタ」がこの番組らしさとの指摘
    • 番組ナンバリング（Side-B形式／重複ナンバー問題）への軽いツッコミ

• リスナー統計と“尖った”リスナー像

  • Spotify for Podcasters の2024ラップ的な振り返り
  • リスナー増加率：オーディエンス数 622%、フォロワー数 600%、再生時間2倍
  • 24カ国から再生（日本、アメリカ、エクアドル、スペイン、ニュージーランドなど）
  • リスナーがよく聴いている音楽・ポッドキャストのラインナップがかなり尖っている話
  • 「少数精鋭ゆえ、統計がほぼ個人の嗜好に引きずられている説」

• 来年の番組方針と展望

  • 番組として：
    • 継続して配信は続けたい
    • 技術だけでなく、しょうもない話・雑談も意識的に入れていく構想
    • コンテンツ確保の難しさと、どうリスナーを増やすかの課題
    • noteやQiita等の外部記事からの流入も検討
    • 「九州のエンジニアがやっている技術系ポッドキャスト」としてのポジション
  • 個人として：
    • 仕事・研究でバズる → そこから番組へ流入してもらう線もアリ、という話
    • 開発スタイルがLLMで激変した一年を踏まえ、来年はさらにAI×研究・ロボティクス方面へ
  • マインド面：
    • 「怒り・貧困・嫉妬」など負の感情で尖っていた昔と違い、丸くなってきた自覚
    • 今年ややなまくら気味だった“尖り”を、来年は意識的に取り戻していく宣言
  • 数値目標：
    • 今年600%成長 → 来年は「1200%成長」でいきましょう宣言

次回もお楽しみに。