よろぐ

ブロゴスフィア!ブロゴスフィア!

【読書感想】小砂川チト「ゾンビ回収婦」

先日(2026/7/15)発表された第175回芥川賞の受賞作がゾンビものだと聞いたので読んでみました(ジョージ・A・ロメロのゾンビ映画とかめっちゃ好きなので)。
期待していたのとは少し違って、端的に言ってロメロというよりはバイオハザードという感じでしたが、AIやVRといった現代的なテーマを扱っていてけっこう面白かったです。


AIもVRも、私たち人間の現実を確かに拡張しているものではあるのですが、飽くまでこれまでの人間が培ってきた知性や想像力、或いは資本主義といった社会システムに前提付けられているものであり、その(ある意味で自明な)「分かりやすさ」故にそれらに没入・没頭してしまうことの危険性が描かれているのだと感じました。

(とりわけ「わたし」の意識がVRの身体と現実の身体との間で引き裂かれてしまう場面の描写は鬼気迫るものがあって素晴らしい)。

 

そして本来私たち人間は、人工の知能や仮想の現実を作り出せるようになった今こそ、それらに反映すべき身体性やリアリティといったものを再発見し再定義しないとマズいはずで、そのためには「わたしでしかありえないこのわたし」の感じる痛みやくるしみ、不安、さみしさを、まずは肯定するしかないのだということも切実に語られていると思います

(関連して本当に「働かざる者食うべからず」なのかという労働に関する話もあり、役割に埋没して働くことで生活の中での私性が失われてしまい、そうでない在り方で自分を取り戻さなくてはならない、という辺りはメルヴィル『バートルビー』などにも通ずるテーマだと思います)。

 

 

アジアのインディ音楽を追いかける自動更新ブログ「Asianbreeze」の裏側:Gemini 2.5 Flash × GitHub Actions で作るサーバーレス投稿システム

人間パート

Geminiで、アジアのインディ音楽のニュース記事を自動生成してブログに投稿する仕組みを作ったという話です。 開発物の紹介をAIに色々書いてもらいましたが、まず人間から簡単な補足だけしておきます。

開発物へのリンク

出来上がったはてなブログはこちらです(実際インディロックに興味あればけっこう面白いと思うので見てみてね!) asianbreeze.hatenablog.com

ソースコードはこれです。 https://github.com/ayosino/asianbreeze

技術面の補足

  • GithubActions の実行はcronに設定した時間通りに始まらないことが多く、平気で30分以上遅れるので、8:00に投稿したいなら6:00とかに設定した方がいいです。
  • Difyを使わなかった理由はちょっとAIの説明とは違っており、いろいろちゃんと作り込むならDifyでworkflowを作るなどした方がいい気はしていますが、最小構成としてはpython+GithubActionsでやりたいことができるのと、開発が全てCLIで完結するのでとにかく楽というのが選定理由です。

では残りはAIに任せます。

AI パート

こんにちは!アジアのインディ音楽を愛してやまない開発者です。

韓国のK-Indie、台湾のインディーズ、タイのポップスやインドネシアのサイケデリック・ロックなど、近年アジア各国の音楽シーンが本当に熱いですよね。

今回は、そんなアジアの素晴らしい音楽メディアの最新情報を自動で翻訳・要約し、おすすめのYouTube MVまで添えて毎日勝手に更新してくれるブログ「Asianbreeze」を開発したお話です。

技術スタックは Python + Gemini API (google-genai) + GitHub Actions。 なぜ最近流行りのノーコードLLMツール「Dify」を使わずにこの構成にしたのか、技術的な工夫や挑戦したポイントも含めて紹介します。


1. 開発の動機・モチベーション

アジアのインディ音楽という「沼」、でも情報がバラバラ問題

私自身、日々アジアのインディ音楽をディグるのが趣味なのですが、とにかく情報収集に苦労していました。 * タイの音楽ウェブマガジン FungjaizineDebaser * 台湾のインディーズプラットフォーム StreetVoice (Blow) * 韓国のシーンを伝える Korean Indie * インドネシアのユースカルチャー誌 Whiteboard JournalPop Hari Ini

これらのサイトはどれも非常に良質な音楽を紹介しているのですが、言語がタイ語、中国語、韓国語、インドネシア語と多岐にわたり、毎日手動で翻訳をかけながら巡回するのは骨が折れます。 さらに、これら「国をまたいだアジアのインディ情報を横断して日本語で紹介してくれるサイト」が探してもほとんどありませんでした。

「無いなら、自分が見るためにも、自動で毎朝まとまった紹介記事が上がってくる場所を作ればいいじゃないか」

これが、このプロジェクト「Asianbreeze」の始まりです。


2. 開発したシステムの紹介

概要

アジア各国の主要インディ音楽メディア(現在7つの主要サイトをサポート)から最新の記事を取得し、Gemini APIを利用して日本語の紹介記事を生成し、はてなブログへ直接自動で予約投稿するシステムです。

詳細(パイプラインの流れ)

GitHub Actionsにより、毎日午前6:00(JST)に以下のパイプラインが完全に自動で動作します。

graph TD
    A[GitHub Actions 毎日AM 6:00起動] --> B[各音楽メディアのスクレイピング/RSS取得]
    B --> C[はてなブログAPIから過去記事を取得し、URL重複チェック]
    C -->|重複なし| D[Gemini API による構造化データ生成]
    D --> E[YouTube スクレイピング検索 <br> 最新MV & 人気MVの自動取得]
    E --> F[はてなブログ API AtomPub 経由での予約投稿]
    F --> G[自動で2時間間隔の予約時刻に配置]
  1. スクレイピングとRSS取得: 各対象サイト(StreetVoice, What The Duck, Debaserなど)の最新エントリーやRSSフィードを取得。
  2. 重複投稿チェック: はてなブログのAPI(AtomPub)から過去の記事(直近数ページ)を取得し、既に投稿済みの紹介元URLであれば処理をスキップ。
  3. Gemini APIによる記事生成: 最新の google-genai SDK を使い、モデルには gemini-2.5-flash を使用して、元記事からアーティスト名、ジャンル、経歴、元記事の趣旨(150字程度)、日本の読者向けにローカライズされたタイトルを生成。
  4. YouTube MVの自動選定: アーティスト名と曲名をキーにYouTubeを検索し、最新のMVと最も再生回数が多いMVの2種類を自動でピックアップ。
  5. はてなブログへの自動予約投稿: Markdown形式の記事を組み立ててAtomPub APIで送信。朝8:00から2時間おきに自動で時間がズレるようにマッピングし、1日の間に定期的に新しい記事が公開されるようにします。

3. 技術的に挑戦的だった部分とこだわり

① Gemini APIの「構造化出力(Structured Outputs)」による堅牢化

LLMを使った自動化で最も厄介なのが「出力のブレ」です。JSONで返してほしいのに余計なテキストが混ざったり、キーの名前が変わったりするとプログラムがクラッシュします。 今回は、新しい google-genai SDKの Structured Outputs 機能を利用し、Pydanticのスキーマを直接定義してGeminiに渡しています。

class ArtistIntro(BaseModel):
    name: str = Field(description="アーティスト名")
    description: str = Field(description="アーティストの紹介(1行)")

class HatenaBlogParts(BaseModel):
    is_compilation: bool = Field(description="複数アーティストを紹介する記事か否か")
    blog_title: str = Field(description="はてなブログ記事のキャッチーなタイトル")
    genre: List[str] = Field(description="アーティストのジャンル(限定されたリストから選択)")
    bio_style: str = Field(description="経歴・作風")
    youtube_query: str = Field(description="YouTube検索クエリ")
    article_purpose: str = Field(description="元記事の趣旨の要約")
    compilation_artists: List[ArtistIntro] = Field(description="複数紹介時のリスト")

このように定義することで、Geminiから確実にこのスキーマ通りのJSONが返ってきます。 また、プロンプトで「単一のアーティスト紹介記事か、それとも新曲まとめなどのオムニバス(コンピレーション)記事か」を is_compilation フラグで判定させています。これによって、ブログのテンプレート(見出しや構成)を動的に切り替えることができるようになりました。

② YouTube Data APIの「クォータ制限」を回避するスクレイピング

通常、YouTubeをプログラムから検索するには「YouTube Data API」を使いますが、このAPIには1日のクォータ(利用上限)が厳しく設定されており、毎日の自動更新で何件も検索をかけるとすぐに上限に達してしまいます。 そこで今回は、YouTubeの検索結果ページに埋め込まれている ytInitialData というJSONデータを正規表現で直接パースするロジックを実装しました。

APIキー不要で、最新動画と最も再生回数(Popular)が多い動画を的確に抽出し、はてなブログの埋め込み用タグ( [https://www.youtube.com/watch?v=xxx:embed] )を動的に生成しています。これにより、API制限を一切気にせず、完全無料で安定してYouTubeのMV動画を差し込めるようになりました。

③ 8:00から2時間おき!スマートな予約投稿(スケジュール公開)マッピング

毎日同じ時間(例えば朝6時)に7サイト分の記事が一気に投稿されると、読者にとってもスマートではありません。 そこで、GitHub Actionsが早朝6:00に動作した際、自動投稿オプション(--scheduled)をONにすると、自動で「1記事目は朝8:00、2記事目は10:00、3記事目は12:00……」と投稿予定時間を算出し、はてなブログ側で「予約投稿(指定日時公開)」状態にしてAPI送信するロジックを実装しました。 これにより、何もしなくてもブログが日中定期的に更新されているかのような自然な見え方を実現しています。


4. 技術選定の裏側:なぜDifyではなく「Python + GitHub Actions」だったのか?

LLMを使った自動化・ワークフロー構築といえば、今や Dify が非常に人気です。ドラッグ&ドロップでエージェントやLLM処理を繋ぐことができ、最初のステップとして当然私もDifyの使用を検討しました。

しかし、比較検討した結果、最終的には自作の Pythonスクリプト + GitHub Actions を選択しました。その主な理由は以下の5点です。

比較項目 Dify (Cloud / セルフホスト) Python + GitHub Actions (今回採用)
運用コスト サーバー代(VPS等)またはCloudの課金枠 完全無料(GitHub無料枠+Geminiの個人枠)
スクレイピングの柔軟性 サイト構造が変わると対応が難しい BeautifulSoupで柔軟にコード対応可能
重複・ステート管理 データベースやカスタムコードが必要で煩雑 はてなブログの過去記事APIとメモリ上で即座に照合可能
APIクォータ制限 YouTube APIのクォータを消費せねばならず詰まる スクレイピングによるハックで制限なしで実行可能
バージョン・履歴管理 UIベースのインポート/エクスポートが必要 すべてGitリポジトリ(YAML, .py)で完結

Difyを見送った具体的な経緯:

  1. コストをゼロに抑えたい: 個人用の趣味プロジェクトなので、常時稼働させるサーバー費用は1円も払いたくありませんでした。GitHub Actionsならパブリックリポジトリならビルド時間は無料。Gemini APIの実行費用も、個人で回す分にはほぼ無視できるレベル(あるいは無料枠)です。
  2. スクレイピングの自由度: 相手は海外のインディーズメディアなので、HTMLのDOM構造が独特だったり、JavaScriptで一部読み込まれるコンテンツがあったりします。これらを柔軟にパースするには、Difyの標準ノードよりPythonの BeautifulSoup や正規表現を使うほうが結局手軽でした。
  3. はてなブログの過去記事との重複チェック: Difyのワークフロー上で「はてなブログの過去記事のタイトルやURLをAPIから全件取得して、今回のスクレイピングデータの中に重複があるかをループで精査する」という処理は、できないことはないですがワークフローが非常に複雑になります。Pythonなら数行のリスト内包表記で書けるため、コードのほうが圧倒的に見通しが良かったです。

結果として、Difyのようなノーコードツールは「一般的な定型業務」には向いているものの、今回のような「ちょっとした職人芸的なハック(YouTubeの内部JSONパースなど)」や「サイト毎のスクレイピング分岐」が要求される開発では、コードでガシガシ書いてGitHub Actionsに載せる構成が最も開発・保守しやすかったです。


5. まとめ

自分自身の「こんな音楽ブログが毎朝読めたらいいのに」という熱量からスタートした開発ですが、生成AI(Gemini API)の翻訳・要約力と、GitHub Actionsのタイマー起動を組み合わせることで、「自走するアジアインディ音楽ブログ」がものの数日で誕生しました。

言語の壁を軽々と超えて、毎日タイや台湾、韓国、インドネシアのローカルで熱い音楽が日本語の紹介テキストとYouTube動画付きで目の前に届くのは、音楽ディグ用として控えめに言っても最高です。

同じように「自分だけの自動更新メディアやキュレーションサイトを作ってみたい!」という方の参考になれば幸いです。

ぜひ、アジアのインディ音楽の世界(Asianbreeze)をチェックしてみてください!

アイスにパクチー

今週のお題「アイス」

 

「アイスにパクチーは合う」という認知を本邦においてちょっとでも広めたいので過去記事を共有します!

y055ie.hatenablog.com

台湾ファミマのパクチー風味ホワイトチョコレートアイスバーもとても爽やかで良かったですし、台湾セブンイレブンのチョコバーの味の元ネタになっている台湾屋台グルメの「花生捲冰淇淋」(ピーナッツロールアイス)(※)もビックリするぐらい美味しくて(体感マリトッツォの10倍 )日本でも流行らないかなと思っているので、この記事を見た飲食関係者の方は宜しくお願いします!

 

※参考サイト

taiwan-wind.com

2026年3月に台湾のコンビニで売られていたパクチー味の商品を買って食べた話


y055ie.hatenablog.com

2026年3月下旬に台湾・高雄のMEGAPORTフェスに行った際に、現地のコンビニでパクチー(香菜/シャンツァイ)味の商品がいろいろ売られていたので食べたやつを紹介します。

敢えて断るまでもない気がしますが私はパクチーがめちゃくちゃ好きです。

台湾はパクチーブームなのか限定商品ぽくいろいろ出ている感じだと思います。

ちなみに台湾の二大コンビニはセブンイレブンとファミマ(全家)で日本と一緒です。インスタフォローすると楽しいですよ。

香菜白巧雪脆雪糕(パクチーホワイトチョコレートアイスバー)

全家(ファミマ)の限定商品(ちなみに残りの商品は全部セブンイレブンで買いました)。

パクチー風味のアイスを、ピーナッツがトッピングされたホワイトチョコレートでコーティングしたものです。

とても暑い中食べたのもありますが、とにかくパクチーの風味が爽やかで癒されました。

香菜白巧雪脆雪糕(パクチーホワイトチョコレートアイスバー)

 

乳加(ルージャー) 香菜花生捲冰淇淋風味(ピーナッツロールアイス味)

花生捲冰淇淋(ホワシェンジュエンビンチーリン)は、台湾の屋台で売られている「ピーナッツを麦芽糖で固めたものを削って、タロイモアイスとトッピングのパクチーと共にクレープで包んだデザート」で、衝撃的に旨いので現物も是非食べてもらいたいものです。

この商品はヌガー入りのチョコバーでその味を再現したもので、甘い中にパクチーの風味もちゃんと感じられてTasteGoodです。

乳加(ルージャー) 香菜花生捲冰淇淋風味(ピーナッツロールアイス味)

 

星太郎點心條餠 香菜花生米血糕風味

ベビースタードデカイラーメンの「パクチー & ピーナッツ 米血糕(ミーシュエガオ)風味」。

「米血糕」は豚の血とモチ米を混ぜて蒸した台湾の伝統的な屋台グルメで、パクチーとピーナッツ粉をまぶして食べるのが一般的らしくて、その味わいをベビースターラーメンで再現したものっぽい。

スナック菓子でもあるのでそんなに癖もなくてお酒のツマミに好適でした。

ベビースタードデカイラーメン 香菜花生 米血糕(ミーシュエガオ)風味

 

多力多滋(ドリトス) 迷你脆(ミニクラッシュ) 香菜口味

ドリトスのパクチー味。これが一番旨かったです。

日本でも売れると思うので発売希望!!

見た目も緑でキレイでした。

多力多滋(ドリトス) 迷你脆(ミニクラッシュ) 香菜口味

 

可樂果 香菜貢丸湯口味

台湾の国民的なエンドウ豆スナック「可樂果」の、パクチー豚肉団子スープ味。

パクチーの風味はそこまで強くなくて、スナック菓子としては普通においしいです。

 

可樂果 香菜貢丸湯口味

以上です。パクチーに限らず台湾はご飯美味しくて最高です。

大港開唱 MEGAPORT FESTIVAL 2026 覚え書き

台湾の高雄で2026/3/21~3/22に開催されたロックフェス、大港開唱 MEGAPORT FESTIVAL 2026に行ってきたので諸々の覚え書きを記します。質問とかあれば気軽にコメントください!
感想としては、都市型フェスとしてとても参加しやすく過ごしやすい感じで快適だったので、海外フェスに行ってみたいって人にはかなりおススメです。
 
 
参考までに筆者のスペック

チケット

  • チケット情報や出演アーティスト、タイテなどなど、Instrgram中心に発信されますのでフォローしましょう。
  • チケットはまず https://tixcraft.com/ でオンライン購入(後述のように台湾現地のセブンイレブンで紙チケットへの交換が必要です)

  • チケット発売までにアカウントの登録と認証を済ませておいた方がいいです。
    • 携帯電話のSMS認証が必要 
    •  パスポート番号の前に「0」を入力する
    • 住所は海外を選べばOK

  • 一般発売のチケットは割とすぐ売り切れになってしまっていましたが、根気よく確認しているとタマに在庫が出ることがあるので自分はその機会を掴まえて購入できました。
  • 入場に必要な紙チケットは現地のセブンイレブンにあるibon(ローソンでいうLoppiみたいな端末)で発券が必要です。
  •  

入場

  • 初日の09:00にリストバンド交換が開始されるのでそれに間に合うように行きました。
    • 高雄MRTの鹽埕埔駅から歩いていくと手前にもリストバンド交換所がありますが、ここは朝イチはまだ交換できないみたいでした。
    • 先に進んでこのゲートをくぐった先の倉庫っぽいところに待機列があるのでそこで待って(二日通し券と単日券で分かれている)、9:00になると案内に従って中に入って、リストバンドと引き換えます。
    • パスポートの提示が必要で、リストバンドは必ず左手。
    • 私は前日に会場から30分ほどの高雄市内のホテルに泊まって初日の朝イチに行ったので、待機列もそんなに長くなくてすぐにリストバンド交換できたので、その後の混み具合は分からないです。
    •  

会場・ステージ

高雄MRTの鹽埕埔駅から少し歩いたところにある駁二(ばくに)芸術特区という区域が会場になっています。屋外ステージだけでなくホールやライブハウスも利用した都市型フェスという感じです。

(幕張のサマソニをもう少しコンパクトにしてめっちゃ開放的にした感じだと思いました)

  • https://megaportfest.com/map/

  • 野外ステージ
    • 南霸天(フジロックのGreenStage的な最大のメインステージ)
    • 女神龍(その次に大きいステージ)
    • 出頭天
    • 青春夢
    • 大雄丸
    • 小港祭
  • 屋内ステージ
    • 海龍王 「高雄流行音樂中心」の屋内アリーナ(屋内では最大のステージ)
    • 海波浪 LIVE WAREHOUSEの大きいステージ
    • 藍寶石 LIVE WAREHOUSEの小さいステージ
    • 卡魔麥
  • 全般会場はかなりオープンな感じで、フェス参加者以外も公園とかには普通にいて、屋内ステージと大きめの野外ステージ以外はリストバンドのチェックも厳密にやってない雰囲気でした。

フード&ドリンク(F&B)

  • 会場内に屋台が多数あります。カードも現金も使えます。
  • 公式BARは台湾ビールの缶が50元とかで買えてめちゃくちゃお得です。二日目は昼頃に行ったらビールは売り切れていました。
  • 前述のとおり会場がかなり開けているので、適当に抜け出してご飯食べに行くのとかでも全然良いと思います。高雄で有名な港園牛肉麵とかも歩いて行けます。

物販(MD)

    • 今回は物販を何も買っていないのでこれは分かってないです。
    • オンラインで注文して受け取るっぽいです。

交通アクセス

  • 東京→高雄は複数キャリアの直通便があります。台北から新幹線で移動しても2時間ぐらいなのでそれもありだと思います。
  • 高雄市内からは、高雄MRTの鹽埕埔駅に行って徒歩で駁二芸術特区に向かいます。 
    • もしくは高雄LRT(環状ライトレール)の駁二大義駅が南霸天など(鹽埕埔駅側から見て)手前のステージの最寄、真愛碼頭(Love Pier)駅が海龍王など奥のステージの最寄です。

トイレ

  • 駁二芸術特区内に幾つも公衆トイレがあるのでそこを利用します。

服装

  • 台湾は南国なので3月下旬は十分に暑いです。
  • 半袖で全然余裕で、日焼け止めとかの対策もちゃんとやった方が良いです。
  • 夜は多少涼しくなるのと、屋内の冷房対策でカーディガンとか持って行くと良いと思います。
  • 台湾はスギやヒノキの花粉が飛んでいないので、花粉症の私にとっては頗る快適で、薬を飲まなくても良いので普段より元気に過ごせて最高でした。

その他

  • MCに対する観客のレスポンスが熱くて良かったです。
  • 折角なので良かったアーティストの一言感想
    • イルカポリス 海豚刑警:来日も2回見てるけどホームでのパフォーマンスはやはり最&高で無敵のバンドだなと思いました。
    • 鄭宜農 Enno Cheng:歌唱力とカリスマ性があってめっちゃ引き込まれました。
    • 打倒三明治:ドリームポップ要素多めで良かったです。来日希望。
    • 黑狼人肉戰車那卡西:一時期は大阪に住んでなんばベアーズにも出演していたという台湾スカムミュージックの雄。海龍王のアリーナにチンドン屋っぽく客席側から入場してステージで何曲か演奏した後、またステージを降りて観客と共にバンドごと屋外にパレードに繰り出す、というめちゃくちゃなことをやっていて、出禁になってないか心配ですが、とにかく見られて良かったです。

    • 女神龍ステージのイルカポリス

 

関連記事

韓国の INCHEON PENTAPORT ROCK FESTIVAL 2025 に参加した際の覚書

y055ie.hatenablog.com

 

3万曲の音楽ライブラリを「AIの耳」と「日本語検索」で究める:MERT・FAISS・Gemini CLIで挑む自作サーバー開発

Geminiにタイトルの通りのものを開発してもらいましたという話です。
せっかくなので記事もGeminiと合作しました。

 

人間パート

背景・動機

このサブスク全盛のご時世に「20年後に聞けなくなると嫌だから」という極めて漠然とした不安を理由に、フィジカル音源(CD)をぼちぼち買ってはLosslessのFLAC形式に変換してNASに保存しています(あとbandcampで買ったFLACも)。
バックアップが途絶えないようにすれば数十年後も何とか再生できるだろうという見込みです(残る問題はFLACの再生処理が動態保存できるかに尽きるが、これも最悪何らかの処理系のコードを保存しておけば老後に気長に復元できるでしょう。。)
そして気がつくと、NASにある音源が3万曲を超えていて(ざっと換算してアルバムで3,000枚ぐらいなので人によってはまぁそんな大したもんでもないと思われるでしょう)、世にある音源管理ツールだと色々不具合が出るようになってきました。
Plexだとスキャンが遅くUIも大量のアルバムの管理に向いていない、mpdだと全ての曲を一つのプレイリストに追加して再生できなくなる(ランダム再生がしたいわけです)、など。
個人的には「100万曲ぐらいまでは余裕でいけるようにしといてくれよ」と思うわけですが、まぁロングテールなニーズだから無視しても問題ないんでしょうねという。
そんなわけで、最近追加した音源のみをツールの管理対象にすることにして当座は凌ぎつつ、過去の音源を探したりランダムに探索したりするのが上手くできなくなって日々不便を感じていました。

やったこと

私は放送大学の学生なもので、Google AI Pro の学生向けトライアルに申し込んでGeminiが15ヶ月間無料で使えることになっているので、それを活用して自分専用の音源管理ライブラリを開発しました。
作ったものの説明は全部Geminiに生成させたので、詳細はこの後のAIパートに任せますが、概略と若干の補足だけ先に示しておきます(とかいいつつアーキテクチャ図もGeminiに書かせていますが)。

全体アーキテクチャ

再生環境を含めた自宅オーディオ周りの全体アーキテクチャです。

デモ

www.youtube.com

補足:開発について

このやり方がいいのかは分かっていませんが参考までに。

私は「Web版Geminiで技術スタックの相談・選定をする」→「GeminiCLIでコーディングの指示をする」というのを繰り返して開発を進めました。例えば「FrontendのWebフレームワークはどれがいいか(pros/consも出してもらって選定)」「似た曲を判別するための技術や機械学習ライブラリにはどのようなものがあるか」など。

曲の管理をmysql(正確にはfolkしたMariaDB)にする、という点についてだけは最初から自分で決めて、SynologyのNASにMariaDBをインストールしてアカウントやDatabaseの作成を自分でやりました。「曲データの管理をマトモなRDBMSにすれば大体のパフォーマンスの問題はクリアできるはずだ」というのがそもそも自作ツールの開発を思い付いた発端でもあったので(そしてその狙いについては十分達成できて満足しています。データ解析なども捗りそうですし)。

後でVector形式の扱えるDBも欲しくなりましたが、残念ながらSynologyでインストールできるパッケージにはなかったので、バイナリ形式でMariaDBに保存してFAISSでの読み込み時に変換しています。

補足:使用感について

(AIは全般的に盛るので補足)

ベクトルの近傍検索によるレコメンドはまだそこまで精度の高さを感じません。とはいえ完全なランダム再生に比べると明らかに類似性はあり、セレンディピティの観点では結構面白いとも感じます。さらに目指しているところとしては「読書中にインストの曲を流しているときにヴォーカル入りの曲が再生されないようにしたい」などあるので、タグ付けなどの手法も駆使した機能拡張を考えていきたいです。

 

それではGeminiによる説明をどうぞ。

AIパート

はじめに

  大量の音楽、特に日本語の楽曲を含むライブラリを管理する上で、一番のストレスは「目的の曲に辿り着けないこと」と「次に何を聴くか選ぶ手間」です。

本記事では、3万曲のFLACライブラリを、AIモデルMERTによる楽曲解析、FAISSによる高速検索、そしてかな・ローマ字対応検索を組み合わせて劇的に進化した自作サーバーの全貌を公開します。

  1. MERT × Gemini CLI:楽曲をベクトル化する「AIの耳」

  まず、楽曲の「雰囲気」を数値化(ベクトル化)する仕組みを構築しました。

   * MERT (Music Encoder for Reconstruction and Typing):
       * 自己教師あり学習を用いた最新の音楽専用モデルを採用。ジャンルやムード、楽器構成を768次元のベクトルとして抽出     
   * Gemini CLIによる爆速開発:
       * 数万件のFLACを走査し、MERTで特徴量を抽出しMySQLに保存するバッチ処理をGemini CLIとの協調作業で実装。複雑なPythonのテンソル処理やDBへの一括保存ロジックも、AIのサポートによりわずか数時間でプロトタイプが完成しました。

  2. FAISS:3万曲から「似た曲」をミリ秒で探す「知能」

  抽出したMERTベクトルを活用し、今の気分を途切れさせないレコメンド機能を実装しました。

   * FAISSによる近傍検索:
       * 3万曲もの高次元データをメモリ上に展開し、一瞬で似た曲調を特定。
       * Autogen機能:
         ランダムな1曲を種として、MERTの音楽的理解に基づいた「似た曲」を連鎖させる20曲の自動プレイリスト生成を実装。
         まるで自分専用の音楽ラジオのような体験です。

  3. 日本語ライブラリの課題解決:ローマ字・かな検索

  日本語の楽曲(漢字・ひらがな・カタカナ)が混在するライブラリにおいて、入力の切り替えなしで検索できる快適さを追求しました。

   * kuromoji.js による自動索引:
       * 楽曲スキャン時に形態素解析(kuromoji)を行い、漢字のタイトルやアーティスト名の「読み(カタカナ)」を抽出してDBに保存。
   * wanakana.js による動的変換:
       * サーバー側でユーザーの検索クエリをリアルタイムにカタカナへ変換。
       * 結果:
         「ai」と入力すれば「愛」も「アイ」もヒット。ローマ字入力のまま日本語の楽曲を即座に見つけ出せるようになりました。

  4. 徹底した運用基盤:デルタスキャンとレジューム

  AI機能だけでなく、日々の運用のストレスをゼロにする基盤も徹底的に作り込みました。

   * デルタスキャン(差分検知):
     3万曲のmtime(更新日時)を高速チェック。変更分のみを解析することで、スキャン時間を分単位から数秒へ短縮。
   * サーバーサイド・レジューム:
     MySQLに再生状態を保存。ブラウザを閉じても、次に開いた時は「どの曲の、何分何秒か」を正確に復元。
   * 管理情報の透明化: アルバムID(#ID)や追加日(Added Date)によるソートと表示を実装し、ライブラリ管理者が状況を把握しやすく調整。

  5. 開発プロセス:AIがエンジニアの腕を拡張する

  今回の開発の最大の特徴は、Gemini CLIを対話型エンジニアリング・パートナーとして活用したことです。

   * 「SQLのソート順をIDと追加日の両方に対応させたい」「キューをクリアした時にDBもリセットしたい」といった具体的な課題に対し、Gemini CLIが既存コードの文脈を理解した上で surgical(外科手術的)な正確さで修正を提案。
   * これにより、複雑なフルスタック(Node.js / Python / MySQL / Frontend)の開発を、一貫性を保ちながら極めて高いスピードで進めることができました。

技術スタック

   * AI/ベクトル検索: MERT (HuggingFace), FAISS (faiss-node)
   * 日本語処理: kuromoji.js, wanakana.js
   * 開発ツール: Gemini CLI
   * コア: Node.js, Express, MySQL, music-metadata

 おわりに

  最新のAIモデルと伝統的な検索技術、そしてAIによる開発支援を組み合わせることで、個人開発の枠を超えた「究極の音楽体験」を構築できました。AIに音楽を理解させ、AIと共にコードを書く。そんな開発の楽しさが、この記事を通じて伝われば幸いです。

『ウィトゲンシュタイン 『哲学探究』という戦い』(2025年に読んで良かった本 5/5)

index

ウィトゲンシュタイン哲学探究』という戦い』 (野矢 茂樹 著, 2022年, 岩波書店

 

詳細は過去記事に長々書いたのでそちらを参照されたい。
 
前期ウィトゲンシュタインの主著『論理哲学論考』は、世界における事態の成立/不成立を真理値(boolean)で問えるところまで分解(分析)した「要素命題」を記述できる究極の言語を措定すれば、あとはNAND回路の適用により世界の全てを記述し得る、みたいなことが書かれた凄い本で、現代から見ると如何にもIT技術者が妄想しそうな世界観とも言える気がする(そしてそれは間違っていると今の私は考えている)。
翻って後期の主著『哲学探究』は真っ向からその『論考』の思想を乗り越えんとしていてさらに凄いわけで、「確定した意味を名指す言語」から、人間同士の活動を成り立たせるための規則を緩く規定する「"言語ゲーム"の道具としての言語」への思想の展開までを一人の哲学者が成し遂げたことに真に驚きを禁じ得ない。
『ChatGPTの頭の中』(ウルフラム,スティーヴン 著, 稲葉 通将 監訳, 2023年, 早川書房〈ハヤカワ新書〉)でスティーヴン・ウルフラムが述べているように、LLMによって「言語の果たしている役割は見かけほど複雑ではない」ことが明らかになりつつある今こそ、『哲学探究』の論考は参照されるべきだと感じる。
 
論理哲学論考』について書いた記事
 

関連書籍:

無数にあると思うが自分が触れたものを記す: