こんな人に役立ちます
考えや専門知識は話せるのに、文章へ整理する時間が取れない人
この記事を読むと、音声の文字起こしと、読める記事へ編集する作業が別物だと分かります。
はじめに
AIライフラボの実験ログ No.007 では、AIエージェントと一緒に、音声ファイルをもとに記事下書きを作り、さらに音声ファイルをジャンル別に整理するローカルツールを作りました。
今回作ったのは、音声ファイルを文字起こしし、その内容からnote記事の下書きを生成し、最後に内容に応じてジャンル別フォルダへ分類するツールです。
今回の目的は、完成度の高い音声編集サービスを作ることではありません。
「AIエージェントと一緒なら、音声メモを記事化し、ファイル整理まで自動化する小さな仕組みを作れるのか」
これを検証することです。
今回作ったもの
今回の成果物は、ローカル環境で動くPythonツールです。
主な流れは以下です。
- 音声ファイルを文字起こしする
- 文字起こし結果からnote記事っぽい下書きを作る
- 内容からジャンルを判定する
- 音声ファイルをジャンル別フォルダへ移動する
- catalog.jsonに処理結果を記録する
最終的に中心となったファイルは、organize.py です。
このコマンドで、音声ファイルを処理できます。
./venv/bin/python organize.py process <音声ファイルのパス>また、ジャンル別の一覧も確認できます。
./venv/bin/python organize.py list
./venv/bin/python organize.py list 学習なぜこのテーマにしたのか
AIライフラボでは、実験ログやnote記事を継続的に作っています。
ただ、毎回ゼロから文章を書くのは時間がかかります。
一方で、思いついたことを音声で話すだけなら、文章を書くよりも気軽にできます。
そこで今回は、
- 音声で考えを残す
- 自動で文字起こしする
- note記事の下書きにする
- 元の音声ファイルもジャンル別に整理する
という流れを作れないか試しました。
これは、AIライフラボの発信を続けるための仕組み化実験でもあります。
今回の設計
最初から大きなアプリにはしませんでした。
今回のMVPでは、まずローカルで動く一連の流れを優先しました。
作成した主なファイルは以下です。
transcribe.py：音声を文字起こしするgenerate_note.py：文字起こしから記事下書きを作るaudio_to_note.py：文字起こしと下書き生成をつなぐorganize.py：文字起こし、下書き生成、ジャンル判定、フォルダ移動、カタログ管理をまとめる
ジャンルは以下の5つにしました。
- 仕事
- 雑談
- アイデアメモ
- 学習
- その他
処理後の音声ファイルは、sorted/ジャンル名/ の中へ移動します。
記事下書きは、drafts/ フォルダにMarkdownファイルとして保存されます。
AIエージェントに任せたこと
今回、AIエージェントには以下を任せました。
- Python環境の確認
- 音声文字起こしスクリプトの作成
- 文字起こし結果からnote記事下書きを生成する処理
- 複数音声ファイルの処理
- ジャンル判定ロジックの作成
- ジャンル別フォルダへの移動
- catalog.jsonへの記録
- テスト音声での動作確認
- 実際の音声ファイルでの再テスト
- 文字起こしモデルの比較
一方で、人間側で判断したこともあります。
- まずは小さく動くMVPから始めること
- サブエージェント構成は後回しにすること
- 実際の録音ファイルで試すこと
- 文字起こし精度を上げるために、Whisperモデルを
baseからsmallへ変えること
実際にできたこと
最終的に、実際の録音ファイルでも一気通貫で動作しました。
試した音声ファイルは、新規録音 5.m4a です。
この音声は、WOOPや目標達成に関する内容でした。
処理結果として、以下のことができました。
- 音声ファイルを文字起こし
- 文字起こしをもとに記事下書きを生成
- 内容からジャンルを「学習」と判定
- 音声ファイルを
sorted/学習/新規録音 5.m4aへ移動 catalog.jsonにタイトルとジャンルを記録- 記事下書きを
drafts/新規録音 5.mdに保存
生成された記事タイトルは、以下のようなものでした。
21日で人生は変わらない。でも「WOOP」なら目標達成率が2〜3倍になる音声から記事の下書きが作られ、元の音声ファイルも分類されるところまで確認できました。
開発中に起きた問題
最初は、ジャンル判定がうまくいきませんでした。
テスト音声の内容が違うにもかかわらず、すべて「アイデアメモ」に分類されてしまいました。
これは明らかにおかしいので、プロンプトの挙動を確認しました。
その結果、プレーンテキストでジャンルを答えさせる方式だと、判定が不安定になることがわかりました。
そこで、出力をJSON形式に固定し、さらにジャンルをenumで制限する形に修正しました。
具体的には、--json-schema を使い、出力できるジャンルをあらかじめ決めました。
この修正によって、3回連続テストでも判定が安定するようになりました。
ここは今回の大きな学びです。
AIに自由に答えさせるより、出力形式をしっかり決めた方が、ツールとしては安定しやすいと感じました。
文字起こしモデルの比較
最初は、Whisperのbaseモデルで文字起こしを試しました。
処理時間は速かったものの、日本語の認識ミスがやや目立ちました。
たとえば、以下のような誤認識がありました。
ウープの放速
かわく的に締めされているその後、モデルをsmallに変更して再テストしました。
同じ約45秒の音声で比較すると、結果は以下でした。
base：約3.17秒
small：約6.94秒smallは約2.2倍遅くなりました。
ただし、文字起こし精度は明らかに改善しました。
特に、句読点が入りやすくなり、文の区切りが自然になりました。
また、
かわく的に締めされているのような表現が、
科学的に示されているに近い形で認識されるようになりました。
一方で、「WOOPの法則」のような専門用語やカタカナ語は、smallでも完全には安定しませんでした。
それでも、個人のメモ用途であれば、smallは十分実用的だと感じました。
使ってみた感想
実際に使ってみると、音声メモを記事下書きに変える流れはかなり便利だと感じました。
話した内容がそのまま完成記事になるわけではありません。
ただ、ゼロから文章を書くよりも、最初の下書きがあるだけでかなり楽になります。
また、音声ファイル自体がジャンル別に整理されるのも便利です。
後から「あの学習系の録音どこに置いたっけ」と探す手間が減ります。
一方で、文字起こしの精度にはまだ限界があります。
特に、専門用語や固有名詞は間違えることがあります。
そのため、最終的には人間が下書きを確認し、必要に応じて直す前提で使うのがよさそうです。
わかったこと
AIエージェントと一緒に、音声から記事下書きを作り、さらに音声ファイルを分類する一連のツールは作れました。
今回特に大きかった学びは、AIを使う部分ほど出力形式を固定する必要があるということです。
ジャンル判定のように、後続処理に使う情報は、自由文で返させるよりも、JSONなどの構造化された形式にした方が安定します。
また、文字起こしモデルは、速さと精度のバランスを見て選ぶ必要があります。
baseは速いですが、認識ミスが多めでした。
smallは少し遅くなりますが、日本語の文章としてはかなり読みやすくなりました。
今回のように、note記事の下書きに使うなら、smallの方が実用的だと感じました。
次に改善したいこと
今後改善するなら、以下を試したいです。
- note記事の文体をAIライフラボ用にさらに寄せる
- タイトル案を複数出せるようにする
- 下書きに見出しを自動で増やす
- 文字起こし前に音声ファイル名を自動で整える
- ジャンルを自由に追加できるようにする
- catalog.jsonから過去の録音一覧を見やすくする
- GUIやWeb画面から操作できるようにする
- podcastファイルの保存先ルールを細かく設定できるようにする
今回の結論
AIエージェントだけで、音声ファイルを文字起こしし、note記事の下書きを作り、ジャンル別に分類するローカルツールは作れました。
ただし、文字起こし精度にはまだ限界があり、生成された記事下書きもそのまま公開できる完成原稿ではありません。
今回の成果物は完成版の音声記事化サービスではなく、音声メモを発信の下書きに変えるためのMVPとして公開します。
実験データ
- 実験番号：No.007
- テーマ：AIエージェントだけで「音声をnote記事にして分類するツール」は作れるか？
- ステータス：MVP完成
- 使用AI：Codex / Claude
- 成果物：ローカルで動くPythonツール
- 使用技術：Python / Whisper / LLM / JSON Schema
- GitHubリポジトリ：未公開
- 公開URL：なし（ローカルツール）
- 今回の結論：音声メモを文字起こしし、記事下書き化し、ジャンル別に整理する一連の流れはMVPとして動かせた
コメント