AI×音声入力でブログ自動化——「オーディオブログ」構想記
目次
ブログを書くのって、正直めんどくさいですよね。
書きたいことはあるんです。日々AIを触っていると「これ記事にしたいな」って思う瞬間はたくさんある。でも、いざPCの前に座ってマークダウンを開くと、なんか腰が重い。
「さあ書くか」と決意したのに、気づけば別のタブを開いている——あの感覚、ありますよね。考えをまとめて、構成を考えて、文章として整えて。その工程がしんどい。
で、ふと思ったわけです。喋ればよくない？と。最近、日々の作業もAIへの音声入力ばかりですし。
音声でタラタラと喋った内容を、AIに記事として整形してもらう。自分の過去記事の文体をスキルとして参照させておけば、それっぽい記事が出てくるはず。これが「オーディオブログ」という企画の出発点です。
そして面白いことに、今まさにあなたが読んでいるこの記事自体が、その企画の最初の1本目だったりします。音声で喋った内容をAIに整形してもらって、ブログ記事にしてみています。
なので、ここに書いてあることは「最初の構想メモ」みたいなものです。実際にパイプラインを組んでみたら、たぶん色々変わっていく。後から読み返して「あのときこんなこと考えてたのか」って振り返る記録として、残しておこうと思います。
やりたいことを整理する
まず完成形のイメージから。
- スマホで音声メモを録る
- 文字起こしされて、AIが記事に整形する
- GitHubにpushされて、下書き状態で記事が生成される
- Discordに通知が届く
- 確認して、よければ公開
この5ステップが自動で回る状態を目指します。
で、これを実現するために必要なパーツを分解すると、大きく3つに分かれます。
- 文字起こし＋記事生成（AIの仕事）
- 記事の状態管理（draft / public の切り替え）
- 通知と編集の導線
それぞれ見ていきます。
技術スタックと設計方針
土台になるのはAstro + MDXの構成です。記事はマークダウンファイルとしてGitリポジトリに置いて、SSG（静的サイト生成）してCloudflare Workersにデプロイします。SEO的にも問題ないし、デプロイも楽です。
大事にしたいのが「マークダウン完結」という方針です。記事の中身も、公開状態の制御も、すべてテキストファイルを編集するだけで完結させる。データベースも管理画面も、最初は持ち込まない最小構成をゴールにします。
「Next.jsに移行した方がいいんじゃないか」という考えもよぎりました。インタラクティブなコンポーネント（辞書ページとか、記事内の比較表とか）を入れるならNext.jsの方が自由度は高い。
でも、AstroでもIslandsアーキテクチャ（client:loadディレクティブで特定のコンポーネントだけクライアント側で動かす仕組み）を使えばインタラクティブな要素は作れます。わざわざフレームワークを変える必要はないかなと。
デザインについては「Claudeでガッと作って、後で直す」でいきます。見た目にこだわって手が止まるぐらいなら、まず動くものを出した方がいいですからね。
公開フローは最小限でいい
最初に手をつけたいのが、記事の公開制御です。音声をアップしたら即公開、はさすがにまずいので。
やることはシンプルで、記事を生成したらとりあえず「未公開」の状態でリポジトリにpushするだけ。公開するときはフラグを書き換えてコミットする。まずはこれで十分。今は余計なことを考えすぎずにマークダウン完結でいきます。
「管理画面ゼロ」という設計に対して、ちょうど同じ時期にCloudflareが「EmDash」というCMSを発表しています。WordPressの精神的後継を謳っていて、AstroベースでCloudflare Workers上で動くというスタックは同じ。
でも管理画面をきちんと提供している点では、このブログとは対極にある設計です。「やっぱり管理画面は欲しいよな」という需要を正直に受け止めている感じがして面白いですね。欲しくなったときに改めて考えます。
Discord通知でスマホ完結にする
次に通知の仕組み。記事がpushされたらDiscordに「新しい下書きができたよ」と通知が届くようにしたい。
Dropboxに新しい音声ファイルが入ったのを起点に、文字起こし→記事生成→GitHubへのpushまで一気に走って、最後にDiscordのWebhook URLへPOSTする。通知メッセージにはGitHub上のファイルへのリンクを含めておきます。
リンクがあればスマホから直接GitHubのWebエディタに飛べるので、簡単な修正であればそこで簡潔できます。
- Discordで通知を受け取る
- リンクをタップしてGitHubのファイルを開く
- Webエディタで
draft: falseに書き換える - コミットボタンを押す
- 自動ビルドが走って公開完了
スマホだけで完結する。管理画面ゼロ。最初のバージョンとしてはこれで十分です。
記事生成パイプラインの肝
ここが本丸ですね。音声ファイルからブログ記事を生成する部分。
処理の流れは、音声ファイルをWhisperなどのAPIで文字起こしして、そのテキストを素材にAIが記事を生成して、MDXファイルとしてリポジトリにpushする。シンプルに言えばそれだけなんですが、2番目の「AIが記事を生成」の部分が肝です。
単に文字起こしを整形するだけだと、口語調のだらだらした文章にしかなりません。ここでClaudeのスキルが効いてきます。スキルに過去の記事を参照させておけば、自分の文体に近い記事を生成してくれる。さらに記事の構成パターンや、frontmatterのスキーマ定義、タグの一覧なんかも渡しておく。
そうすると「ただの文字起こし整形」ではなく「自分のブログの記事として成立するもの」が出てきます。ここは手を抜くとクオリティに直結するので、スキルの設計がかなり重要になりますね。
ここまでが最低限のパイプラインの構成です。ここから先は、余裕ができたらやりたいこと。喋っているうちにあれもこれもと思いついてしまった機能のメモを書き残しておきます。
やりたいことメモ
優先度はまちまちですが、将来的に組み込んでいきたい機能をまとめておきます。
タグの自動管理
記事が自動生成されるとなると、タグも自動で付けたい。でも野放しにするとタグが無限に増えていきます。
対策として考えているのは、タグの一覧をJSONで管理しておいて、記事生成時にAIに参照させるという方法。既存のタグから選ばせるのが基本で、どうしても当てはまらない場合だけ新規タグを提案させる。
さらに将来的な案としては、タグの増減を観察してカテゴリ分けを自動更新するという発想も。記事が増えていくにつれて「あ、このジャンルの記事が増えてきたな」とAIが判断して、カテゴリを再編してくれる。最初にカテゴリを決め打ちしなくていい。
辞書ページの自動生成
タグの発展として、辞書機能の構想もあります。
例えば記事の中で「Claude Agent SDK」って言葉が出てきたとする。普通のブログだと、初出のときに軽く説明を入れるぐらいですよね。でもそれだけじゃなくて、Wikipediaみたいに、自動でそのキーワードの辞書ページを生成できたら面白いですね。
しかもただの用語解説じゃない。自分のブログの中でそのキーワードについて言及している記事の一覧が載っていて、さらにそれらの記事で話された内容を全部踏まえた上での解説ページになっている。自分の発言のアーカイブから、自動で知識が積み上がっていくイメージ。
開発でCLAUDE.mdを自動で育てていくのと同じ感覚を、記事の辞書機能として展開していきたいですね。
エビデンス補強
もう1つ、喋りながら「これ絶対必要だな」と思ったのがエビデンス検証の仕組みです。
音声で喋ってると、自分の理解が曖昧なまま話してしまうことがめちゃくちゃある。「たしかコンテキストウィンドウって20万トークンだったかな……」みたいな。書いてるときは調べながら書けるけど、喋ってるときはそうもいかない。
なので、文字起こしの段階で「ここ、ファクトチェックが必要そうだな」というポイントをAIが検知して、自動で調べて補正してくれるスキルがあるといい。
画像の管理
記事に載せる画像の管理も考えないといけません。選択肢は大きく2つで、1つはGitHubのリポジトリにそのまま画像を置いてしまう方法。もう1つは外部の画像ホスティングサービスを使う方法。
個人的には、最初はGitHub完結でもいいのかなという気がしています。リポジトリが重くなるという問題はあるけど、個人ブログの規模感なら当面は大丈夫でしょう。外部サービスを挟むと管理ポイントが増えるし、パイプラインも複雑になる。
ここに関しては検討の余地がありますね。運用してみて不便を感じたら、そのとき外部に移していく。
まず動かす
ここまで色々と書いてきましたが、初期バージョンで実装するのはこれだけです。
- 文字起こし→記事生成のスキル
draft: trueデフォルトの状態管理- GitHub Actions→Discord通知
- GitHub Webエディタでの公開操作
辞書機能もエビデンス補強もタグ自動最適化も、全部後回し。判断基準はシンプルで、自分で再現できるかと管理が複雑にならないかの2軸。この記事に出てきた設計判断は全部ここから来ています。まずはこの最小ループを回してみて、使ってみてから次を考えます。
ということで、引き続き開発を進めていきます。ではでは。
