Daisuke Miyazaki

自分の関心とニーズが乖離している

2026-09-27T00:00:00+00:00

自分の関心から生まれる文章、つまりこのようなブログとマーケティング的なニーズが乖離していることは十分にありえるし、むしろそうであることのほうが多いだろう。一般的に読まれたい、人の目にとまってほしい、との思いで書いた文章が読まれないことがほとんどだ。それは自分が世間のニーズを自分が認識できていないだけかもしれない。実際言葉よりもっと細かく最適化された形で提供されない限り、真の意味でニーズを満たすわけではない。

とはいえ言葉が読まれることはもちろんのこと、そこからつながる広報的な関係の構築こそ最終的には対価につながる。つまり広報的な意味でのブログは人の縁をつなげるきっかけづくりに十分になりうるのではなかろうか。

LLMは行間が読めないが網羅性がある

2026-09-22T00:00:00+00:00

LLMは行間が読めないが網羅性がある。人間が持っているすべての情報をコンテキストにいれることは難しいし、すべての情報を等価に扱い重み付けを優先的にすることもない。議事録の作成は網羅性が必要だから得意、しかし実際合意形成がなされたわけではないのに、話されただけでやると明記されることもある。

LLMの端的な出力はproviderの利益に反する

2026-09-22T00:00:00+00:00

LLMの記述は常に冗長になりやすいが、冗長であればあるほど出力token数が増えるのでLLM providerにとって利益となる。逆に端的に短く出力することは利益になりずらい。どれだけプロンプトを改良しても、人間のように端的な出力にはならないのかもしれない。

Hide properties in notes in Canvas view

2026-09-17T00:00:00+00:00

canvasだけでプロパティを消す方法を学んだ。ノートを空間的に有効に使うにはどうしても邪魔になる一方で、個別のノートを開いているときには有効に活用できるプロパティ。メインの設定からプロパティを非表示にしてしまうと、canvasと個別ノートそれぞれに適用されてしまうのでこれで回避できる。

.markdown-embed .metadata-container,
 .markdown-embed-content .metadata-container {
   display: none !important;
 }

obsidianでノートを貯めても思考が深まらない悩み

2026-09-15T00:00:00+00:00

箇条書きでobsidianを使っていても思考が深まらない悩みを書いておく。

すべてバックリンクで表現しようとしても抜け漏れる。
空間的側面がないのでメタ的な分類ができない。
辿ろうとしてもノートのリンクが等価に見えてしまうため手がかりが無い。
自分のノートは全体感を考えることなく自分で育てていくため常に動的に変化する。
index的な側面を持つノートを手で更新するのはボトムアップで自由に記述をするスタイルと親和性が低い

日記を書く時にはテーマを変えて気分転換する

2026-09-15T00:00:00+00:00

obsidianを用いて仕事していると、夜に自分の気が向くままに日記を書きたいときにどうしても仕事の延長線として頭が錯覚してしまうことがある。リモートワークをしていてずっとプライベートの時間でも同じ場所にいるときに覚える間隔と似ているのかもしれない。

テーマプラグインを変えることでUI全体の印象が変えることができる。

自分のタスク管理

2026-09-03T00:00:00+00:00

tasksプラグインを使ってdailynoteにためる。毎日デイリーノートを開けば並列されている。なるべく文脈が一目でわかるように入れたいので、「ノート記入」ではなく「この文脈をノートに記入」と書く。「この」はノートを辿ってわかる。

そして朝になってTODOを眺めながら実際に空いているカレンダーに予定をいれてその日の過ごし方を設定する。テキストだけでは伝わらないこともある。今日じゃないと思ったらまた他の日にずらす。

タスクの日付設定は思いついたときに。細かい時間設定は当日に。

ソースコードをagentが書く前提で、エンジニアはソースをどう体系化して管理すれば十分に長続きする理解を委任しないままソフトウェアを運用できるか？

2026-08-25T00:00:00+00:00

ソースコード をagentが書く前提で、エンジニアはソースをどう体系化して管理すれば、十分に長続きする理解を委任しないままソフトウェアを運用できるか？

将棋棋士は必ずAIの評価値をみるだけでなく、新しい戦法の研究では棋譜を並べる。彼らは理解を委任しない。

本質的な人間の認知資源には限りがある。その中で、使われていない分岐。ベルカーブの極端にいるユーザーのための機能。競合他社に追いつくためのとりあえずの機能。これらは人的で限りある資源を技術的、認知的負債の両面で消費する。

ソフトウェアを動かすものは 実行可能なソースコード である。しかしそれを 創出する こと自体が安価になってしまった結果、乖離が発生している。これまで当たり前にあった「書き手の十分な理解」と出てくるソースコードの非対称性である。

Agenticコーディング以前は適当な理解で仕立てたコードでは要求や非機能要件を満たすことが原理的にできなかった。当たり前だが非対称性を紐づけていたのは「十分に長続きする理解のための書き手の血肉」にあった。

シーケンスダイアグラムやER図、包括的なドキュメンテーション。コードベースの空間認識やある種の概念モデルへの紐づけ。これらはソースコードに 結果として 閉じ込めた手前で、その過程で生まれてくるものである。畳み込まれ収束したソースコードの手前には、発散した大きなストーリーがあり試行錯誤がある。

これはただ綺麗なソースコードだけを見るだけでは構造的に生まれず、ある種発散したカオスを文章化や図式化を通して収束させ生じるものである。発散から収束までの過程を辿るのが十分に長いこと理解するという行為そのものである。「要求を加味した仕様を咀嚼し機械語まで翻訳する」といえば、ソフトウェアの工程に具体化できよう。

ソフトウェアは要求を最も荒い粒度として、実行可能で最も冗長な記述の塊である。冗長な規約文章は99%の人は読まず、ハイコンテキストな理解まで昇華させ不必要な所を意図的に忘却/無視する。十分な理解を抜きにこの昇華も忘却も行えないのだ。

「十分に長続きする理解を持った実装者はトークンの浪費を回避し、かつ責任説明を担保できる」という経済性やSLAメリットを持つのにもかかわらず、その理解に達するのは名人芸として十分に話されていないと思われる。これを体系化して仕組み化するにはどうすべきか？デジタルなものづくりの実装者、そして組織づくりをする立場の人に問われていると思う。

この過程を名人芸として体系化することなく、この議論を抜きにして「コードを書いた人、マージした人が責任を持て」だったり「ソースコードを書く時間が圧倒的に短くなったから、大量の機能を同じ工数で実装しきれるはずである」と指示するのは中長期で間に合わなくなってくると思う。速度を取った10xではなく、質を取った2xを目指すべきでなかろうか。

仮説とオントロジーとフォルダー階層

2026-08-20T00:00:00+00:00

obsidianを使っていて仮説とその検証をどうやって管理しようか迷っていた。仮説検証には大抵複数の領域を横断的に組み合わせることが必要となる。例えば家計と自分や家族との幸せの方針を決めるための仮説には、それぞれの価値観と会計的な領域を組み合わせる必要がある。

フォルダー階層とオントロジーをハイブリットとして使い分ける前提で、仮説そのものをフォルダーの名前とする案はどうか。仮説には、仮説を支える子仮説や何故なぜの組みあわせが存在するが仮説を親として受け継ぐ従属関係がある。これにはフォルダー階層が親和性が高そうだ。

一方でオントロジーによる組み合わせは何を概念の最小単位とするかで重点となる。そしてその最小単位そのものがタイトル名、つまりファイル名となる。仮説や仮説を支える子仮説、何故なぜはそれ以上切っても切れない最小単位となる。よってファイル名そのものだ。

将来の自分に任せられる

2026-08-16T00:00:00+00:00

良いプロダクトやPKMに忘れられるデザインがある。能動的に忘れられることは幸せなことである。ここで重点は、将来の自分に任せられるか。今安心して忘れるためにはあとで必ず自分が掘り起こせるだろうと確信がないといけない。

エビングハウスの忘却曲線、再学習時にどれだけ手間が節約できたかと睡眠による記憶の固定について

2026-08-13T00:00:00+00:00

忘却曲線について少し学び直し。振り返って思い出すときにどれくらい負荷なく思い出すことができるか、睡眠によって固定化される記憶があるならば情報社会において大切。逆に眠れないとどれだけ詰め込んでも記憶が固定されなくなる。

当たり前だけど再認識したのは、覚えておきたいものでも使っていなければ思い出すことができなくなること。自分が考えていたことを文章にまとめてもずっと前まで振り返ることなく思い出さない限り、思い出すことが困難になる。たとえば言語のようにすぐに思い出さないと大変なものと、コーディングのようにリアルタイムでなくても「思い出す」までの時間が与えられているもので切り分けられる。

claudeによるエビングハウスの忘却曲線のリサーチ

理解を壊さないためのプロンプト

2026-08-11T00:00:00+00:00

Ankur Sethi から引用

I want to understand every line of code that goes into this project. Never create, edit, move, rename, or delete project files unless I explicitly ask you to do so. Instead, show me every proposed edit in the chat so I can type it in manually.

Do not run commands that modify project files, install dependencies, or change repository state unless I explicitly request that action. Instead, show me those commands in the chat so I can run them manually.

I’m an experienced developer. Do not explain syntax, APIs, programming concepts, or implementation details unless explicitly asked.

コンテキストスイッチングが多いと没頭している時間が消える

2026-08-11T00:00:00+00:00

没頭していると頭の中の作業記憶が進化、整理されて長期記憶に変わる。短期記憶に詰め込むものが発散するとスイッチングが発生してしまう。没頭と思考の収束は比例関係にあり、思考の発散は逆比例関係があるのかもしれない。

理解を委任してはいけない

デジタルウェルビーイング

2026-08-10T00:00:00+00:00

Digital Wellbeing through technology

Find a balance with technology that feels right for you. As technology becomes more and more integral to everything we do, it can sometimes distract us from the things that matter most to us. We believe technology should improve life, not distract from it. We’re committed to giving everyone the tools they need to develop their own sense of digital wellbeing. So that life, not the technology in it, stays front and center.

職業がソフトウェア開発であるからこそ1日にスクリーンを見ている時間は平均して10時間を超える。1日10時間もテクノロジーに触れている、と言ったら普通の人であれば誰もが「技術のしもべ」になっているというであろう。自分がしもべと思ってなくても、この塩梅や匙加減を覚えるには試行錯誤しないといけない

I Built an Obsidian Plugin to Tidy Up Notes That Once Mattered but Gathered Dust

2026-07-13T00:00:00+00:00

I built an Obsidian plugin that finds and helps you tidy up the notes you once thought were important but that have quietly gathered dust. It’s out now as an official community plugin.

Hard to spot in the graph view

As a vault grows, so do its notes and backlinks. When links pile up and cross-connect, the graph view turns a note into a catch-all that seems connected to everything. There’s plenty of information, but that abundance is exactly what keeps you from reaching the note you actually want.

A node with many lines stands out. But you can’t tell from its look whether it’s an index you meant to build or an unconscious pile-up.

And connections you organized a while ago can stop being appropriate as time passes. Whether they still hold today is not something the graph view shows you.

Let go before you add

When you grow a note, you naturally think only in terms of adding — drawing relations, adding links, deepening your thinking.

But there’s a step worth being aware of before that. Before adding connections, first reduce the ones you don’t need. It’s the subtractive mindset of discarding a note that has become too tangled.

What this does resembles tidying a room. Before you place something new, first let go of the old. Wanting to do the same with notes is what set this off — and it’s where the plugin’s name comes from. (Katazuke means “tidying up” in Japanese.)

Earlier I built a plugin that enlarges the notes I edit most. That one surfaces the notes I keep my hands on — like the favorite belongings in a room. Because you reach for them often, they never gather dust.

This time it’s about the things I thought were important but that ended up gathering dust anyway. Maybe it’s a similar feeling.

Surfacing old, over-connected notes in one command

What matters in tidying is a question like: have I used this in the last month? Using that as a guide, I gave more weight to old notes and over-connected notes.

score = number of a note's links × (1 + days untouched / 1 month)

Intentional notes are excluded. Some notes are important and allowed to gather dust — and as long as it’s intentional, that’s fine.

Links to attachments like images and videos aren’t counted. What I want to see is the connections between notes.

A quick tidy, or a proper one

Tidying is a special event, almost a festival — something I learned from Marie Kondo’s book. So I prepared two modes: one as a small ritual, and one for when you settle in, closer to that festival in how it’s used. And so you can start right away, each is a single command straight from Obsidian’s command palette.

Face one note. It surfaces just the single top note. Good for a daily habit or a spare moment.

Or face a handful. It surfaces the top few. Marie Kondo’s style of tidying leans more this way.

It’s not about mechanically reordering everything and gazing at the result. You face them one at a time, by your own hand, starting from the top.

After tidying up

Being in a tidied room feels good. You’re surrounded by what you love, and whatever you need, you can pull it out right away, wherever it is.

Facing your notes is, by nature, also the work of locking many ideas away across many places — which makes it all the more important to forget well when the time comes.

The reason you can keep adding things, keep adding notes, is that you believe you’ll be able to pull them out later when you need them. Only when there’s a system that lets you forget with peace of mind can you truly stockpile in your own room.

If everything is neatly tidied, reaching the notes you treasure will be quicker. I hope Katazuke helps you face notes that matter more to you.

大事でも気づいたら埃をかぶっていたノートを片付けるObsidianプラグインを作った

2026-07-13T00:00:00+00:00

大事だと思っていたけれど気づいたら埃をかぶっていたノートを見つけて片付ける。そんな手助けをできるObsidianプラグインを作りました。公式のコミュニティプラグインとして公開しています。

グラフビューでは見つけにくい

保存庫が大きくなるとノートもバックリンクも増えます。リンクが多重に繋がっているとき、グラフビューではノートは何にでも繋がる寄せ集めに見えてしまう。こうなると情報は多いけれど、多いがゆえに目的のノートにすぐたどり着けなくなります。

線が多いノードは目立ちます。でもそれが意図した目次なのか無自覚な寄せ集めなのかは見た目で区別できません。

また前にまとめたノートのつながりは時間が経つにつれて妥当でなくなることもあります。それが今も妥当かはグラフビューに表示されません。

足す前に、手放す

ノートを育てるときはつい足す方向ばかり考えます。関連を張ってリンクを増やして思考を深めていく作業です。

でもその前に意識したい作業があります。つながりを足す前にまず要らないつながりを減らす。絡まりすぎたノートを捨てる引き算の発想です。

これでやっていることは部屋の片付けに似ています。新しい物を置く前にまず古い物を手放す。ノートでも同じことをしたいと思ったことがきっかけでした。プラグインの名前もここからとりました。

以前よく編集するノートを大きく表示するプラグインを作りました。これは「よく手を入れるノート」を見せるものです。これはいわば部屋の中でお気に入りの持ち物に似ていると思います。よく手に取るから、埃がかぶっていることもないでしょう。

今回は自分が大事だと思っていたけれど、結局埃をかぶってしまったもの。そんな感覚に似ているのかもしれません。

古くて結合しすぎたノートを一コマンドで出す

片付けで大事なのは、たとえばここ1ヶ月で使っているかどうか？という観点です。これを参考に、古いノートと結合しすぎたノートに重みを置くようにしました。

採点 = ノートのつながりの数 × (1 + 放置日数 / 1ヶ月)

意図的なノートは除外します。大事で埃をかぶってもいいノートもあるでしょう。それに意図的であればいいんです。

画像や動画などの添付ファイルへのリンクは数えません。見たいのはノート同士の結合だからです。

少しだけ片付けるか、腰を入れて片付けるか

片付けは祭りであると、近藤麻理恵さんの書籍で習いました。一つであれば儀式に、腰をすえるのであれば使い方も祭りに近く2つ用意しました。すぐに始められるように、Obsidian標準のコマンドパレットを叩くだけで1コマンドでできます。

一件のノートと向き合う。首位の1件だけを出します。日課や隙間時間向けです。

あるいは数件と向き合うか。上位の数件を出します。近藤麻理恵さんの流儀の片付けはどちらかというとこちらです。

全体を機械的に並べ替えて眺めるのではありません。上位から1件ずつ自分の手で向き合います。

片付けたあとは

片付いた部屋にいることは気持ちがいいものです。好きなものに囲まれていますし、何がどこにあるのかすぐに取り出せる。

ノートと向き合うことは性質上いろんなアイデアを複数に閉じ込める作業ともいえますが、その分必要なときにうまく忘れることが大切です。

ものを、ノートを増やし続けられるのはあとで必要なときに引き出せると信じられるからです。安心して忘れられる仕組みがあって初めて自分の部屋に貯め込めます。

綺麗に片付いていれば、大切にしているノートに辿り着くことも早いでしょう。Katazukeを通して、あなたがもっと大切なノートと向き合えるようになったら嬉しいです。

The Notes You Can No Longer Find, and Two Kinds of Work

2026-07-03T00:00:00+00:00

Six years ago, in the very first piece I wrote here, I described the small magic in our pockets. The magic that stretches memory almost forever, and blurs the line around who owns knowledge. Since then my notes kept growing. The magic kept its promise and pushed my memory further and further outward.

And now I stand on its other side. Too many to find.

Organizing had become the work

If you use Obsidian, you probably know the feeling. Past a few hundred notes, you can no longer reach the one you know you wrote. All that remains is the déjà vu — “I’ve written this before” — while the note itself stays hidden.

So you organize. You recut the folders. You settle on a tag system. You relink. It works, at first. But as the pile grows you end up back in the same place. Before long you spend more time organizing than writing. Organizing itself had become the work.

Recut folders, added tags, and it collapsed again

Everything I tried was an attempt to solve it by place. First the folder hierarchy. Then tags. When that wasn’t enough, maps of content tied together by links. I even tried Bases. I wove ontology-style cross-links between notes too, of course — and still, things slipped through and went uncaught.

Each one feels good the moment you cut it — the shelves line up, the world seems legible. But half a year later the shelves overflow again. I can’t remember which drawer I put it in. The more places you add, the higher the cost of remembering those places. It was never a real fix.

There were two kinds of organizing

At some point I noticed that the single word “organizing” was really two piles of a different nature.

One is hunting for duplicates and relations by hand. Tracing memory, opening folder after folder, just to check “did I write this already?” This grows heavier in proportion to the pile. When a human does it, it only drains you and produces nothing. It is, by rights, the machine’s work.

The other is facing the text itself. Merging, splitting, renaming, deciding what to keep and what to throw away. In code we would call it refactoring. This is the body of intellectual work — the good kind, the kind I want more time for.

My mistake was not separating the two. The drain of the former eats the time of the latter. The good work gets pushed out by the bad.

A question that place cannot answer

The decisive moment came when I went looking for a note. What I wanted to recall was this:

“What became important in my career, and what I learned from failing at it.”

You cannot pull that with grep, or folders, or tags. There is no folder called “what became important.” You could never have tagged it in advance. People remember by meaning, not by where they filed it. The very premise of searching by place no longer fit.

Discovery you may hand off. Judgment you keep.

From here it stops being about which tool to use, and becomes about where to draw the line.

Discovery you may hand off — the work of finding duplicates and pulling the near-in-meaning ones toward you. In fact you should. The more you do it by hand, the more it drains you and loses to sheer volume.

But judgment you must not hand off. What is the same and what is different. What to keep and what to discard. That understanding stays on your side. It is the “understanding” side of a piece I once wrote, We Must Not Delegate Understanding. Understanding means connecting the dots yourself. The moment you hand that to something else, your own mind quietly goes shallow.

This has long been ordinary in software. No one hunts for duplicate code by eye. You leave it to the linter, to “find usages.” The human moves only on what comes after — the judgment of how to rewrite. Notes should have been the same.

After that

Once I made peace with this line, I began building a small mechanism to return the “discovery” side to the machine. Nothing is sent to someone else’s server; it stays at hand, and I hold the key.

I haven’t stopped facing my notes. I’m only letting go of the part a machine can do. The time it frees I return to facing the text — merging, splitting, throwing away, and writing again.

Next I want to write about how to keep doing that judgment. Because the assurance that a future me can surely find it again is what makes forgetting a happiness.

増えすぎて探せないノートと二種類の仕事

2026-07-03T00:00:00+00:00

六年前。この場所の最初の記事で、僕はポケットの中の小さな魔法について書いた。記憶を半永久に伸ばし、知識の所有者の境界をぼんやりさせる魔法だ。あれからノートは増え続けた。魔法は約束どおり僕の記憶を外へと押し広げてくれた。

そしていま、その裏面に立っている。増えすぎて探せない。

整理そのものが仕事になっていた

Obsidian を使う人なら、たぶん覚えのある感触だと思う。ノートが数百を超えたあたりから、書いたはずの一枚に辿り着けなくなる。「これ前にも書いたよな」という既視感だけが残って本体が出てこない。

だから整理する。フォルダを切り直す。タグの体系を決める。リンクで結び直す。最初はうまくいく。けれど母数が増えればまた同じ場所に戻ってくる。気づけば書くことより整理に時間を使っている。整理そのものが仕事になっていた。

フォルダを切りタグを足し、また崩れた

僕が順に試したのは、どれも「場所」で解こうとする手だった。まずフォルダの階層。次にタグ。それでも足りずに地図のようなノートを作ってリンクで束ねる。Basesもやってみた。オントロジーによる相互リンクももちろん試したが、結局取りこぼしも発生して拾いきれていない。

どれも切った直後は気持ちが良く、棚が整い世界が見通せた気がする。けれど半年も経てばまた棚は溢れる。どの引き出しに入れたか自分でも思い出せない。場所を足すほど、その場所を覚えておくコストが増えてしまう。根本解決ではないのだ。

整理には二種類あった

あるとき気づいた。「整理」と一括りにしていた仕事は性質の違う二つの塊だった。

ひとつは重複や関連を人力で探す作業。「前に書いたっけ」を確かめるために記憶をたどりフォルダを開いて回る。これは母数に比例して重くなる。人がやると消耗するだけで何も生まない。本来は機械の仕事だ。

もうひとつは文章そのものと向き合う作業。束ね、割り、名前を付け直し、何を残し何を捨てるかを決める。コードで言えばリファクタリングにあたる。これは知的生産の本体だ。むしろ時間を増やしたい好ましい仕事だ。

僕の失敗はこの二つを分けなかったことだった。前者の消耗が後者の時間を食う。良い仕事が悪い仕事に押し出されていく。

「場所」では引けない問い

決定的だったのは、あるノートを探そうとしたときだ。僕が思い出したかったのは

「以前キャリアで大事になり、その失敗から学んだこと」。

これはgrep でもフォルダでもタグでも引けない。「大事になったこと」というフォルダは存在しない。そんなタグを前もって貼れるはずもない。人は保存した場所ではなく意味で思い出す。場所で探すという前提そのものが、もう合っていなかった。

発見は手放していい。判断は手放さない

ここから先は道具の使い方の話ではなく線の引き方の話である。

発見は手放していい。重複を見つけ、意味の近いものを手繰り寄せる作業のことだ。というより手放すべきだ。人力でやるほど消耗し量に負ける。

けれど判断は手放してはいけない。何が同じで何が違うのか。どれを残しどれを捨てるのか。その理解だけは自分の側に置く。以前に別の記事で書いた「理解を委任してはいけない」の、その理解の側だ。理解とは点と点を自分で繋ぐ作業を指す。そこを何かに委ねた瞬間、自分の頭は静かに浅くなる。

これはソフトウェアの現場ではとっくに当たり前でもある。重複したコードを目で探す人はいない。リンタや「使用箇所を探す」に任せる。人が手を動かすのはその先だけだ。どう書き直すかという判断のところ。ノートも同じでいいはずだった。

それから

この線引きに納得してから、僕は「発見」の側を機械に返す小さな仕組みを組み始めた。他所のサーバーに送らず、手元で完結して鍵は自分が持つ。

ノートに向き合うことはやめていないが、機械にできることを手放しつつある。空いた時間は文章と向き合う側に戻す。束ねて割り、捨ててまた書くのだ。

次はその「判断」を続けるための話を書きたい。未来の自分が確かに引けるとの安心感が、忘れる幸せを後押ししてくれるからだ。

I Want to Listen to My Unread Papers, Not Read Them — and the Auto-Podcast Wasn't Enough

2026-06-25T00:00:00+00:00

The papers I’m curious about but never sit down to read

I keep running into papers and long essays I’m genuinely curious about. The curiosity is real; the focus to sit down and read them is not. Reading is active work, and I rarely find the slot for it.

The time I do have is the passive kind — a commute, a walk, the few minutes I spend staring out a window. That time arrives whether I plan for it or not, and for this kind of material those moments are actually the best ones: listening slots into them in a way reading never will. So what I want isn’t a summary to skim or a transcript. I want the thing broken down plainly enough that it comes in just by listening, hands free.

NotebookLM and the auto-podcast almost solve this

Google’s existing tools already do most of this. NotebookLM’s Audio Overview, and the audio in Deep Research, turn a pile of text into a natural, podcast-style conversation between two hosts. For a daily listen, for gathering information, for buying back the reading time I never have, it’s genuinely good — the voices sound human and the tone lands.

After a while, though, the limit shows. The examples are thin, and I can’t control the length. It explains, but it doesn’t make the thing click, and it isn’t always comprehensive. Next to a real podcast — where a good host pulls a vivid, specific example out of a guest — the auto version feels flat. It tells you what the paper says without ever making it land.

So I built the part the auto-podcast skips

Two things the generic version is weak on: examples and questions. Those are the parts I built up. The script is split into two roles.

The explainer’s real job is to translate. Every abstract claim has to come with a concrete example or an analogy. If a term shows up, it gets unpacked on the spot. No bare jargon survives.

The questioner is the listener’s proxy. I studied a list of the “ten best podcast interviewers”¹ and read what each says about their craft, then deliberately pulled out only the hard skills that move comprehension forward: ask short questions, follow up on the thing just said, voice the exact place a listener gets stuck, push past breadth toward the crux, and demand an example. The soft skills — warmth, rapport, humor itself — I dropped on purpose, because in this context they add noise to the script, and when you’re working with an agent they invite hallucination.

The pipeline itself is plain: take a PDF, extract it, map its logic, digest it into plain language with examples, budget the length to 15–30 minutes, write the two-voice dialogue, and verify it against the source. Then Gemini 3.1 Flash TTS gives it a natural voice — the one part the auto-podcast already nails, so I let the machine keep doing it.

The TTS step is just a small script — voices fixed, paced, and chunked to fit the model’s limits: gemini_tts.py.

Where it went wrong

Early on I used gemini-2.5, and the tempo was too fast — tonton-byoushi, the two voices volleying without a breath between them. It sounded efficient and felt exhausting. The fix was small: pauses between turns, a calmer delivery, a director’s note telling the model not to rush. What it taught me wasn’t small, though — it needs ma, room to breathe.

What surprised me: Gemini 3.1 Flash TTS supplies those pauses and that speaking tone — the parts that look a lot like soft skills — on the model’s side. Listening to 2.5 and 3.1 back to back, the difference was obvious.

Wrapping up

The job of this tool is to digest things down so I’ll actually touch the primary source I’d otherwise never open. The audio is an on-ramp to the paper, not a substitute for it. For something I just want to be aware of, it gets me far further than reading a summary would. But for a paper that snags me, I don’t stop at listening — I go to the source and digest it in my own words. That digestion is the part I have to do myself. As I wrote in the walking piece, the first-hand insight AI can’t generate for you only comes from there.

This tool has its limits, too: even after it writes a script and I ask it for examples, some things still don’t click. For those, I ask the agent in my own words — not from a template — keeping the paper itself in context, and in my case having it sketch a diagram when that helps. Then I write the resolution into Obsidian. It’s slow, but clearing them one at a time is how a paper I only listened to slowly becomes my own. We must not delegate understanding.

A note on rights: I’m not publishing the generated audio — or the script it’s read from — here. The audio is just the script spoken aloud, so both are the same derivative work. I’d rather not distribute a derivative of someone else’s paper without the rightsholder’s permission, so I keep it to my own personal use — and if you run the same setup, please keep it to material you’ve legitimately obtained, for your own use.

Source: Frank Racioppi, “The Ten Best Interviewers In Podcasting” (Ear Worthy / Pod-Alization, 2023). Starting from this article, I dug into each host’s own statements, blogs, and interviews. Primary sources, per host: Michael Barbaro, David Pogue, Audie Cornish, Elaine Appleton Grant, Robert Peterpaul, Mike Carruthers, Evan Stern, Matt Gilhooly, Jordan Harbinger, Zale Mednick. ↩

積読の論文は読むよりまず聞きたいが、自動ポッドキャストでは物足りなかった

2026-06-25T00:00:00+00:00

興味はあっても腰を据えて読めない論文たち

どこかで見かけて「興味はある」のに積まれたままの論文や長文記事があります。好奇心はあります。でも、腰を据えて読む集中の時間は、なかなか取れません。読むのは能動的な作業で、その枠を確保するのが難しいのです。

一方であるのは、受動的な時間のほうです。移動中、散歩、窓の外をぼーっと眺めている数分は、意識しなくても訪れます。むしろそういう瞬間がベストで、聞くのは読むのと違ってそこにすっぽり収まります。だから私が欲しいのは、斜め読み用の要約や書き起こしではありません。手を空けたまま、ただ聞くだけで入ってくるくらいに平たく噛み砕かれたものです。

NotebookLMなど自動ポッドキャストはほぼ解決してくれる

実は、既存のGoogleのツールはこの大半をすでにやってくれます。NotebookLMの音声概要（Audio Overview）や Deep Research の音声機能は、テキストの塊を2人のホストによる自然なポッドキャスト調の会話に変えてくれます。日々の聞き物として、情報収集として、取れない読書時間を取り戻す手段として、これは本当に良いです。声は人間らしく、トーンも決まっています。

ただ、しばらく使うと限界が見えてきます。具体例が薄かったり、尺も自分でコントロールできなかったりします。説明はしてくれますが、腑に落ちさせてはくれません。包括的でないこともあります。名ホストがゲストから鮮やかで具体的な例を引き出す本物のポッドキャストと並べると、自動版は平板に感じます。論文が何を言っているかは伝わるのに、刺さってはこないのです。

だから自動版が飛ばす部分を作った

汎用版が弱いのは2つ——具体例と質問です。ここを作り込みました。まず、大きな2つの役割に分けて台本を作成します。

説明役の本業は「翻訳」です。抽象的な主張には必ず具体例か比喩を添えます。専門用語が出たらその場でほどきます。裸の専門用語は1つも残しません。

質問役はリスナーの代理人です。「最高のポッドキャスト・インタビュアー10人」のリストを調べ¹、各人が語る技術を読み、理解を前に進めるハードスキルだけを敢えて抜き出しました。短く問う、直前の発言を受けて掘る、リスナーがつまずくその場所を代弁する、網羅でなく核心へ寄せる、具体例を要求する——といった型です。温かさ・ラポール・ユーモアそのものといったソフトスキルは、この文脈では台本にノイズが入ったり、エージェント相手では幻覚を引き起こす恐れがあるため、意図的に捨てました。

パイプラインはいたって簡単です。PDFを取り込み、抽出し、論理を地図にし、具体例つきで平易に噛み砕き、15〜30分に尺を見積もり、2声の対話に書き起こし、原文と突き合わせて検証します。そのうえで Gemini 3.1 Flash TTS が自然な声を与えてくれます——ここは自動ポッドキャストがすでに得意な部分なので、機械に任せています。

音声化は、この小さなスクリプトにまとめてあります（声を固定し、間を入れ、モデルの上限に合わせてチャンク分割しています）: gemini_tts.py。

どこで失敗したか

初期にはgemini-2.5を使いましたが、テンポが速すぎました。とんとん拍子で、2つの声が息継ぎもなく打ち合います。効率的に聞こえて、聞いていて疲れます。直し自体は小さく、ターンの間に「間」を入れ、落ち着いた話し方にし、急がないよう演出指示を足しました。間が要ることに、大きく気づかされました。

驚くべきことに、Gemini 3.1 Flash TTSでは、この「間」や話し手のトーン——いわゆるソフトスキルに相当しそうな部分を、モデル側が補ってくれています。2.5と聴き比べると、差は明らかでした。

まとめ

このツールの役割は、「噛み砕いて、一次情報に触れやすくする」ことです。要約や音声は、本来なら一生開かなかった論文への入口であって、原文の代わりではありません。「知っておきたい」程度なら、ただ概要を読むよりもグッと理解が進みます。けれど引っかかった論文なら、聞いて終わりにせず原文にあたり、自分の言葉で噛み砕く——その消化は自分でやらないといけません。散歩の話で書いたように、AIが代わりに生み出せない「一次の気づき」は、結局そこからしか出てこないと思います。

このツールにも限界があり、台本を作らせ、具体例をきいてもわからないことがあります。そういうときは、フォーマット化された問いではなく、自分の言葉で agent に聞きます。例えば私の場合、論文そのものをコンテキストに置いたまま、必要なら図にも起こしてもらったりします。そして、その解消を Obsidian にまとめていきます。地道ですが、一点ずつ潰していくことで、聞いただけの話が少しずつ自分の血肉に変わっていきます。理解を委任してはいけない。

なお、生成した音声も台本も、権利上ここでは公開していません（音声は台本の読み上げで、中身は同じ二次的著作物です）。元論文の著作権者の許諾なく配布するのは避け、あくまで自分の個人利用にとどめています。同じ仕組みを使う場合も、各自が正当に入手した文献を、自分の範囲で噛み砕く用途に留めていただければと思います。

出典: Frank Racioppi「The Ten Best Interviewers In Podcasting」(Ear Worthy / Pod-Alization, 2023)。この記事を起点に、各ホスト本人の発言・ブログ・インタビューを調査して整理しました。各ホストの一次ソース: Michael Barbaro、David Pogue、Audie Cornish、Elaine Appleton Grant、Robert Peterpaul、Mike Carruthers、Evan Stern、Matt Gilhooly、Jordan Harbinger、Zale Mednick。 ↩