※この記事は私のポッドキャストの音声を基に作成しています。音声で聞きたい方はこちら listen.style

ローカル文字起こしAIとウェアラブルレコーダーで構築する「パーソナル全録音システム」の衝撃

最近、AIの進化が目覚ましいですね。特に大規模言語モデル（LLM）や生成AIは、私たちの情報収集や整理のあり方を大きく変えつつあります。文字ベースのAI活用はすでに身近なものになりましたが、音声の文字起こしAIの進化は、さらに新たな可能性を秘めていると感じています。

今回は、私が個人的に試している「全録音生活」というプロジェクトをご紹介します。これは、安価なウェアラブルレコーダーとAI技術を組み合わせることで、日常の会話や出来事を自動でテキスト化し、情報として活用する試みです。

音声データのテキスト化：ローカル文字起こしAIの活用

音声データをテキストに変換する「文字起こし」は、AIの中でも特に身近な技術になりつつあります。以前は専用のサービスや高性能なPCが必要というイメージでしたが、今は手元の環境でも十分に実用レベルの文字起こしが可能です。 (今回利用したのは、ThinkPad L15 Gen2を購入した - inajob's blog で紹介しているノートパソコンです。特にGPUが強いとかでもないので、CPUのみで処理を実行しています。）

私はまず、オープンソースの文字起こしツール「Whisper」を試しました。これは無料で利用でき、PCのCPUだけでも動作するのが魅力です。しかし、実際に試してみると、私のノートPC（GPUはオンボード）では、10分の音声データに20分近い処理時間がかかり、日常の雑音や無音区間が多いデータでは精度も今ひとつでした。同じ言葉を繰り返したり、意味不明な文字が羅列されたりすることも。

そこで見つけたのが「Faster Whisper」です。名前の通りWhisperを高速化した実装らしく、これを試したところ、驚くほど処理速度が向上しました。10分の音声データがなんと5分もかからずに文字起こしできるようになったんです。特に無音区間が多いデータでは、その部分をうまくスキップしてくれるようで、効率が格段に上がりました。

プログラムはたったこれだけです

from faster_whisper import WhisperModel
import subprocess
AUDIO_FILE_NAME = "XXXX.mp3"

model = WhisperModel("large-v3", device="cpu", compute_type="int8")

segments, info = model.transcribe(
        AUDIO_FILE_NAME,
        beam_size=5,
        vad_filter=True,
        without_timestamps=True,condition_on_previous_text=False)
print("Detected language '%s' with probability %f" % (info.language, info.language_probability))
for segment in segments:
    print("[%.2fs -> %.2fs] %s" % (segment.start, segment.end, segment.text))

実際には全録音生活の録音データの大半は会話ではなく雑音なので、10時間とかのデータであっても書きおこし自体は1時間以内で終わることがほとんどでした（多く会話がある日は書きおこしにも時間がかかります）。

同じ文字が繰り返し出力されてしまう問題に関してはcondition_on_previous_textをFalseに設定することで回避できました

加えて音声データを少し加工することで、音声認識の精度が上がることにも気づきました。具体的には、ノイズの低減、低周波数の音声のカット、ラウドネスノーマライズを実施しました（この手法は私のポッドキャストの音声編集時にも行っています。こんなところで知見が役に立つとは！）

もちろん、Faster Whisperで出力されるテキストは完璧ではありません。単語レベルでは合っていても、文脈が不自然だったり、固有名詞が間違っていたりすることはよくあります。

生成AIとの連携によるデータ分析

Faster Whisperで文字起こしされたデータは、そのままでは活用しにくい部分があります。そこで、私は次のステップとして、クラウドベースの生成AIを組み合わせることにしました。具体的には、普段使い慣れているGoogleの「Gemini」や「ChatGPT」といったサービスです。

文字起こしされたテキストをこれらの生成AIに投入し、「このテキストは音声から文字起こしされたもので、多少の誤字脱字や繰り返し、意味不明な箇所がある。これをきれいな日本語に直してほしい」「箇条書きで要約してほしい」といった指示を与えます。すると、比較的自然な日本語で、かつ要点がまとまったテキストが返ってくるんです。

ここでもローカルLLMを使う選択肢もあるのですが、ローカルLLMでは速度・性能面でクラウドベースの生成AIに劣るということに加え、Geminiの無料使用の範囲で十分に分析できるという理由から、クラウドベースの生成AIを利用することとしました。

この「音声データ → ローカル文字起こしAIでテキスト化 → 生成AIで分析」というワークフローを確立することで、不完全な文字起こしデータでも、実用的な情報へと生まれ変わらせることができるようになりました。日常の何気ない会話も、トピックレベルであれば十分に把握できるレベルになります。

全録音生活を支えるデバイス(このデバイスは買い換えました、追記を確認してください)

この全録音生活を実践する上で、手軽に長時間録音できるデバイスは欠かせません。私が目をつけたのは、中国通販サイトのAliExpressで見つけたウェアラブルレコーダーです。

私が購入したのは、わずか15ドル（約2,000円強）ほどのキーホルダー型の小型レコーダーです。バッテリーは8時間程度持続し、16GBのデータ容量で約160時間分の録音が可能。8時間なので丸一日には少し足りませんが、どこかで1時間ほど充電時間を取るか、明らかにしゃべらない時間帯に録音を停止することで、1日のほとんどすべての会話を録音することができます。（現在もっとバッテリー容量の大きなものを注文中です）

盗聴器として販売されているケースも多いようですが、私自身のプライベートな記録として、倫理と法律の範囲内で利用する分には非常に魅力的なデバイスだと感じました。もし試してみたい方がいれば、AliExpressやAmazonなどで「ウェアラブルレコーダー」と検索してみてください。様々な形状やバッテリー容量のものが、10ドル〜30ドル程度の価格帯で手に入ります。

以下はAmazonで探した近い製品です。私の手元にあるものは16GBモデルなので厳密には違います。

もう少し電池が長持ちするとしたらこれかなと思っていますが、上と比較するとちょっと値段が高いかなとも思います（電池も長持ち、容量も大きいので妥当な値付けだとは思いますが・・）。

追記: 全録音生活を支えるデバイス

上で紹介したデバイスは、1日中の録音に堪えなかったため、新しく以下のモデルを購入しました （AliExpressで$20程度でした）

ポッドキャストにて音声で紹介もしています。 listen.style

• 1日中録音できるバッテリー（カタログによると35時間、実際に16時間程度録音しているが問題なし）
• USB Type-C端子がそのまま刺さる（前機種は特殊ケーブルだった）
• mp3で録音できるのでストレージにたくさん音声が入る
• 大きさは前機種よりむしろ小さい
• 録音中かどうかをLEDで確認する方法がない（前機種は長押しでLEDが点灯した）
• 2時間単位でファイルが別になる
• 充電しながらの録音ができない（前機種は出来た、これは人によってはつらいかも）

日常への適用：家族との会話の記録

この「全録音生活」は、特にご家族、とりわけお子さんがいる環境と非常に相性が良いと感じています。普段の生活では、家族間の会話は常に発生し、大人も自然と発話する機会が非常に多いですよね。例えば、子供と遊んでいる時、食事中に話している時、ちょっとした出来事を話している時など、意識せずとも多くの会話が生まれます。

そうした自然な会話を継続的に録音することで、例えば先日科学館に行った際の会話や、昼食の感想、娘との何気ないやり取りなども、後からテキストデータとして手元に残せるようになりました。これは、後から振り返るための貴重な「日記」や「記憶のトリガー」になりうると感じています。

実践における課題と今後の展望

実際にこのウェアラブルレコーダーとAI連携システムを導入し、3〜4日ほど「全録音生活」を試してみた結果、期待通りに機能していることを確認できました。1日の行動内容や、どのような会話をしたかといったトピックレベルであれば、問題なく抽出できています。先日科学館に行った際の会話や、昼食の感想などもテキストデータとして手元に残るようになりました。

このシステムの最大の魅力は、そのコストパフォーマンスです。

• デバイス: ウェアラブルレコーダーは15ドル程度の初期費用のみ。
• 文字起こし: ローカル文字起こしAI（Faster Whisper）を使用するため、PCのCPUパワーと電気代のみ。
• 整形・要約: 生成AI（Geminiなど）は、無料の範囲で十分に利用可能。

つまり、実質的にかかる費用は15ドルのデバイス代と、PCの電気代くらいで、誰でもこの「全録音生活」を試すことができるんです。Pythonでの簡単なプログラミングは必要ですが、それ以外は購入してボタンを押すだけなので、エンジニアでなくとも十分チャレンジ可能です。

しかし、現時点での最大の課題は、「集まった大量のデータをどう活用するか」という点です。日々の記録がテキストとして手元に集まるのは素晴らしいのですが、それをどう整理し、ナレッジとして活用していくかについては、まだ明確な答えが見つかっていません。これは、世の中のAI活用全体にも言えることかもしれませんが、データを集めることはできるようになっても、その次のステップが見えていないのが現状です。

もちろん、過去の会話を聞き直して「あの時何話してたっけ？」と確認するような使い方はできますが、日常でそこまで頻繁に振り返ることもありません。今後は、これらのデータを知識ベースとして構築したり、パーソナルアシスタント機能と連携させたりといった、さらなる活用方法を探っていきたいと思っています。

既存サービスには、録音とAIによる文字起こし・要約を組み合わせた「PLAUD AI」のような製品もすでに存在します。しかし、これらは28,000円前後と高価な上に、クラウドサービス利用料がサブスクリプション形式になっている場合が多いです。今回ご紹介した自作システムは、それらのサービスに比べて圧倒的に低コストで、同様の体験ができるのが大きなメリットです。

もちろん「PLAUD AI」が法外に高いというわけではなく、このような製品はまさに、前述した「集まった大量のデータをどう活用するか」についての答えを考えて実装されているものとなっています。このような点に価値を見出すのであれば妥当な金額とは思いますが、今回私はこの部分を自分で作りたいという気持ちと、PLAUD AIが（おそらく）フォーカスしているビジネスでの活用という面には興味がないということから、自作することを選択しました。

手元で現在行っている分析

「集まった大量のデータをどう活用するか」ということで、今試しているのが、音声データからナレッジを抽出する試みです。ここではナレッジというのはタイトル＋短い本文という形のデータです。全生活録音の書きおこしデータをもとにこのナレッジを生成させるのです。

今の仕組みでは1日の録音に対して大体50~100個のナレッジが生成されています。まぁこれがあっても「それで？」という話なのですが、何となくこの形式のほうが活用しやすいと考えています。

たとえばある日の会話データの書きおこしから、以下のようなナレッジが抽出できます

• 缶詰の蓋の危険性
  • ある容器の蓋が非常に危険であると警告されている。開けた後の蓋の縁が鋭利で、指を切る可能性があるとのこと。包丁ほどではないが、滑らせるように触ると切れるほどの切れ味があるため、取り扱いには注意が必要である。
• 幼稚園への適応と遊び方の変化
  • 以前は幼稚園に行きたがらなかったが、現在は適応している様子が語られている。休みの日には幼稚園に行けないことを残念がるほどになった。また、幼稚園のおもちゃに飽きても、新しい遊び方（絵本を読むなど）を自分で見つけるようになったという成長が報告されている。
• 青ワザのケアと出発前の身体確認
  • 青ワザの治療として軟膏を塗布し、ズボンをずり下げて患部を確認。青ワザはかなり治ってきている様子。その後、背中を「もちもち」とケアし、出発前の最終的な身体の状態を確認した。着替えを促し、準備が順調に進んでいることを確認した。
  • (注：これは「青アザ」の間違いですね)

さらにここから、LLMに雑談や蘊蓄（うんちく）のようなものを生成してもらいました

• 缶詰の蓋の危険性
  • 缶詰の蓋の鋭利さ、本当に危険ですよね。古代エジプトでは、メスという道具が使われていました。これは、現代の外科手術で使われるメスと同じように、物を切るための道具です。石器時代から続く、鋭利な刃物への人間の探求心は、缶詰の蓋にも受け継がれているのかもしれません。缶詰の蓋は、その構造上、開けた時に縁が鋭利になってしまうことがあります。これは、缶詰の密封性を保つための工夫でもありますが、同時に危険もはらんでいるという、まさに諸刃の剣ですね。
• 青ワザのケアと出発前の身体確認
  • 青ワザは、内出血によって赤血球が破壊され、そこに含まれるヘモグロビンが分解される過程で様々な色に変化します。最初は赤紫色ですが、時間が経つにつれて緑色、黄色へと変化していくのが特徴です。

とりあえず今はこんな感じで、翌日以降、妻や5歳の娘に隙あらばこの手のうんちくを伝えて反応を見たりしています。

これ以外にも、ナレッジの類似度の高いものを検索する仕組みや、1日の活動のサマリを生成する仕組み、明日に残したタスクを列挙するなど、いろいろと試していますが、なかなか「これぞ！」というものが見つかっていないのが実情です。

ぜひあなたも試してみてほしい

「全録音生活」は、現代のAI技術が個人の情報環境にどのような変化をもたらすのかを、身をもって体験できる面白い試みです。低コストで手軽に始められるので、もし興味を持たれたら、ぜひご自身でウェアラブルレコーダーを手に入れ、無料のツールと組み合わせて試してみてください。

もちろん、録音デバイスの利用には、法律やマナーを遵守し、周囲に配慮することが重要です。プライバシーに関する問題がない範囲で、ご自身の生活に新しい風を吹き込んでみてはいかがでしょうか。

この「全録音生活」から得られたデータに、もし何か良い活用アイデアがあれば、ぜひ教えてください！

参考

zenn.dev

この記事ははJLCPCBの提供でお送りします。

JLCPCBとは

jlcpcb.jp (↑こちらは日本語版のログインページで、お得なクーポンも配布されています。)

JLCPCBとは、プリント基板製造などで有名な香港の企業です。

日本からでもWebページでポチポチするだけでKiCADなどで作成した基板データの製造を依頼できます。

値段もかなりお手頃で、ホビー電子工作ユーザーの間では広く利用されています

これは何？

8×8=64個のフルカラーLEDを制御するための基板です。 コアとなるマイコンはESP32で、USB接続で簡単に開発できるというものです。

設計

以下のような要件で基板を設計しました。

• USB Type-Cでパソコンと接続できる
• USB シリアル変換IC CH340G
• 自動リセット回路
• 2mm角のシリアル制御できるフルカラーLED (8×8=64個)
• ESP32の足をそのまま引き出した拡張ポート
• フルカラーLEDの制御を3.3V、5Vのどちらか選択できるジャンパ

個々の要素はこれまで作ってきた基板で検証済みのものが多いので、比較的スムーズに設計できました。

例えば、USB Type-CコネクタについてはUARTで書き込みできるCH32V003開発ボードを作った - inajob's blogで検証しましたし、自動リセット回路についてはESPboyというオープンソースの携帯ゲーム機を日本用に再設計してみた - inajob's blogで学んだものです。

部品も上記の製作の時に買ったものがまだ残っていたので、新たに買い足す部品は少なくて済みました。

2mm角、シリアル制御フルカラーLED

今回使用したのはYF923-2020というフルカラーLEDです。

このサイズでメジャーなものとしてはWS2812B-2020やWS2812C-2020なのですが、仕様書を見るとこれらのLEDは3.7~5.3Vということで3.3Vで動かないようなのです（しかし実際のところはそれでも動く、という情報が多数見られますが・・）

今回はどうせ買うなら、ということでプロトコルはWS2812互換ですが、3.3Vでも動作可能とうたっているYF923-2020を選びました。

この情報は3.3V電源で動くNeoPixel LED YF923-2020 をXIAO RP2040に乗っけてPRK Firmware使ってLチカ - kuriharaのブログで学びました。有益な記事に感謝します。

まぁ、3.3Vで動くということですが、何かあったときのために5Vで動かすための仕組みも用意しておき、ジャンパで切り替えできるようにしておきました。（5V接続は結局試してないですが・・）

LEDを配置する面はこんな感じ。GNDを白抜き文字にしてみました。

ICを配置する面はこんな感じ。 ESP-WROOM-32のアンテナ部分は基板から飛び出すように配置しています。 また、各フルカラーLEDに対応したコンデンサも実装できるようにしましたが、これは実装しなくても問題なく動作しました。

発注

サイズは63mm角なので、$4 + 送料という安価で基板製造できました。

実装

さて、この基板、結構表面実装部品が多いので、実装は大変です。

まずは、USB Type-CポートとCH340G、レギュレータ周りの部品を実装して、USBシリアルデバイスとして認識できるかを確認しました。

はんだ付けにははんだペーストとホットエアーガンを使いました。さすがに何度も実装しているので、ここはすんなりと認識されました。

その後、ESP-WROOM-32の実装です。このモジュールは1.27mmピッチの端面スルーホールになっており表面実装部品として実装することにしたのですが、意外とはんだ付けにてこずりました。

この程度のピッチであればそんなに苦労したことはないのですが、特にGNDの端子について、熱が伝わりづらくうまくはんだが乗らないような感じがしました。

まぁ四苦八苦しながらESP-WROOM-32をはんだ付けしたところで、Arduinoとしての書き込みができない問題に気付きました。

色々調べてみると、IO0をHIGHにした状態でRSTをLOWにしてHIGHに戻すとシリアルコンソールに文字が出ていることに気づきました。これはうまくESP32は起動しており、シリアル接続もうまくできているが、自動リセット周りが何かおかしいぞ・・・ということであたりをつけて調べていると、自動リセット回路にプルアップが足りていないことを発見しました。

これは凡ミス・・（こういう回路のピンに求める条件みたいなのをテストするような仕組みはないのかな？、ソフトウェアの単体テストで書くアサーションのような・・）

ということで、とりあえず手元にあった10KΩの抵抗でプルアップを付け足したところ、無事、Arduinoとしての書き込みができました。

自動リセット回路だけでなく、IO0やRSTに対応するスイッチをつけておいてもよかったかなと感じました。

さて、最後は大量のフルカラーLEDです。

その前に、LED制御信号線に問題があることに気づきました。まず3.3Vレベルの信号線と5Vレベルの信号線につけているラベルが逆になっており、シルクの記載と実際に流れる信号レベルが異なっていました。

まぁこれはシルクの記載を無視してジャンパすれば問題なさそう。

そしてもう一つは、3.3Vレベルの信号線が実際のフルカラーLEDの制御ポートと接続されていない問題がありました。

これは大問題で、接続されていないので、当然信号をいくら出力してもフルカラーLEDには到達しません。

原因となっているのがこのラベルのようで、これDIN5とIO27というラベルがくっついており、横切っている配線と2つのラベルはくっついていない状態だったのです。

設計図がこうなっていると、DRCでも配線ミスとして検出されないため、結果として必要な結線を見落としてしまっていました・・

まぁここも必要な配線をジャンパすることで、問題を解決できました。

気を取り直してフルカラーLEDの実装です。

まず1つ実装してみて、ESP32から制御できるかを確かめました。

簡単にESP32から制御するために、ここからはMicroPythonを用いることにしました。

ThonnyというMicroPython用のIDEを使って、MicroPythonのファームウェアをまず焼きこんで、その後以下のようなプログラムを転送して動作を確認しました。 ESP32向けのMicroPythonにはNeoPixel互換のフルカラーLEDを制御するためのモジュールが標準搭載されているので本当に簡単に制御できました。

import neopixel
import machine
import time
np = neopixel.NeoPixel(machine.Pin(27), 64)

count = 0
while True:
    for i in range(64):
        np[i] = (0,((i + count)%8)*2,((int(i/8) + count)%8)*2)
    np.write()
    time.sleep(0.1)
    count = count + 1

Arduinoだと、（特にWindowsだと）コンパイルが非常に遅く、転送も含めると開発のイテレーションが非常に遅くなってしまい、イライラするのですが、MicroPythonだと、さっと書いたコードを実行できるのでストレスなく動作テストができました。

さて、ここからはフルカラーLEDをどんどん実装していって、キリの良いところで動作テストをすることを繰り返しました。

このフルカラーLEDはデイジーチェーンで数珠繋ぎに接続されているので、あるLEDのはんだ付けがうまくできてない場合は、そのLEDより先は全部制御できなくなるため、これを頼りにはんだ付けを進めました。

そしてついに64個すべてのLEDの実装が完了しました。（肩凝った・・）

まぁここまでできれば、あとは好きな模様を表示したり、WiFi経由で表示内容を制御するなど、応用先は様々ありそうです。

まぁ今回は基板の機能が一通り動くことを確認できたということで、ひとまず記事にしました。

まとめ

ESP32をコアとした8×8=64個のフルカラーLEDを制御する開発ボードを作りました。 表面実装部品が結構ありましたが、実装面で苦労することはあまりなく、はんだ付けが少しは上達したかなと感じました。

ESP32の開発はコンパイルが遅いという印象でしたが、MicroPythonを使うことで迅速に開発サイクルを回すことができました。

回路のミスもいくつかありましたが、切り分けがうまくでき、そこまで悩まずに対処できたのもよかったです。

今までESP-WROOM-32を使うときには開発ボードを使っていましたが、今回初めて自作の基板に直接実装することを試すことができました。今後は自作のガジェットにも積極的にESP32を採用できそうです。