Blog Dice

Notes from Simon Willison's Interview on Software Misadventures

Michael Lynch

Software MisadventuresでのSimon Willisonインタビュー覚え書き

ポッドキャストSoftware MisadventuresでのSimon Willisonインタビューを聴き終えたところです。インタビューから多くを学べたので、自分のための覚え書きをまとめました。

これはインタビュー全体の要約ではなく、自分にとって新しかったことや覚えておきたい部分だけを抜き出したものです。

ポッドキャストSoftware Misadventuresに出演したSimon Willison

Simon Willisonとは？

プラグインという形のオープンソース貢献

元の議論

  • 機能を拡張するプラグインを受け入れられるようにアプリケーションを設計することは、オープンソースのコントリビューションを受け入れるよりもさらに摩擦の少ないコラボレーションの形です。
    • 外部の協力者はレビューや承認を経ることなく機能を追加でき、あなた自身がそのコードのメンテナンスに責任を負う必要もありません。

プラグインの素晴らしいところは、人のコードをレビューしなくても自分のプロジェクトに機能を追加できる仕組みを作れることです。ある朝目が覚めたら、誰かがプラグインを公開したおかげで、自分のソフトウェアが新しいことができるようになっている、なんてことが起こるんです。

[編注：興味深い指摘だと感じました。自分はプラグインを受け入れるソフトウェアを設計したことはありませんが、Simonはこの種のアーキテクチャについて非常に説得力のある説明をしています。]

LLM

LLMの使い方の勘所を身につける

元の議論

  • LLMは制約が一見分かりにくいため、見かけによらず使いこなすのが難しいものです。
    • チャットボットなので簡単そうに見えますが、できることとできないことの感覚を掴むには、さまざまなタスクで数時間使い込む必要があります。
    • 例：LLMは数えるのが苦手です。コンピューターは一般的に数を数えるのが得意なだけに、これは意外に感じられます。
  • Simonは、LLMの使い方を上達させる方法としてAnthropicのプロンプトエンジニアリングのドキュメントを勧めています。
  • セルフホスト可能なモデル（例：Phi-3、Llama 3.1）で学ぶことも勧めています。そうしたモデルはハルシネーションや間違いをより頻繁に起こすため、LLMの苦手なことがよりよく分かるようになるからです。

SimonのLLM活用法

元の議論

  • 情報の要約
    • 長いコンテキストウィンドウを活用してリサーチを加速させます。例えば、ある人物について調べる際は、その人物のWikipediaページや関連記事、本人の文章などをチャットにまとめて放り込み、具体例を交えた主要なテーマの要約をLLMに頼みます。
    • 直接引用を求め、LLMが引用をハルシネーションしていないか原文で確認します。

      もし友人がWikipediaのページを読んで自分の質問に答えられるなら、LLMもその質問に答えられるはずです。でも、Wikipediaのページにそもそも載っていなさそうな内容であれば、LLMが答えられる可能性は低くなります。

  • 自分が専門知識を持つ分野について尋ねる

    法律に関する質問をしたりもします。利用規約を貼り付けて、「何か怪しいところはない？」と聞くんです。

    でも、これは良くない使い方だと自分でも分かっているんです。法律の知識がないのですから、なんとなく分かったふりをしながら付き合っているだけで、LLMから得た法的助言をもとに人生を左右するような決断をすることは絶対にありません。

    もし自分が弁護士だったら、どんどん使うでしょうね。自分の専門知識を拠り所にして、責任ある使い方ができるはずですから。

  • SQLクエリの作成
    • Simonは、LLMにテーブルスキーマ全体と数行のサンプルデータを見せることを勧めています。
  • データ入力
    • 例：手書きメモからの書き起こしや、非構造化文書からの構造化データの抽出
    • 最高性能のLLMでも精度は約95%で、人間のインターンを集めて同じ作業をさせた場合とほぼ同程度です。
  • ソフトウェアアーキテクチャの意思決定
    • 同じタスクを達成するための多様な選択肢をLLMに提示させ、それぞれの長所と短所について議論させます。
  • 学術論文を読む
    • Simonは、馴染みのない用語を解説してくれるDejargonizerというツールを作りました。
    • [編注：このツールは実用的な道具というより面白いアイデアだと感じました。テキストを貼り付ける必要があり、5ページの論文を入れるとコンテキスト制限に達してしまいました。専門用語をインラインで定義しながら文章自体を書き換えてくれる方が理にかなっていると思います。]

SimonのLLMに対する「奇妙なインターン」というメンタルモデル

元の議論

  • Simonは妻にLLMのことを「うちの奇妙なインターン」と説明しています。

    あらゆるプログラミング言語のドキュメントを丸暗記していて、突拍子もない陰謀論を信じ込んでいて、時々とんでもないアイデアを出してきて……そしてとにかく自信過剰なインターンを抱えているようなものなんです。

  • LLMが人間のチームメイトより優れている大きな点は、解決策の改善を何度でも頼み続けられることです。
    • 人間の同僚相手では、プルリクエストを良くするための新しいアイデアを出し続けるのは相手に負担をかけるので、いずれ切り上げなければなりませんが、LLMなら相手の時間を奪うことを気にせず、大幅な書き直しを頼むことができます。
  • 単に「もっと良くして」と言うだけでLLMの回答を改善させられることに気づきました。

    私のお気に入りのプロンプトの一つは、ただ「もっと良くして」と言うことなんです。でもこれが効くんですよ。本当に信じられないことです！

    コードを書かせてから「もっと良くして」と言うと、「すみません」と言って、もっと良いコードを吐き出してくる。こんな仕組みでこの技術が動いているなんて馬鹿げていますが、ちょっと楽しいんですよね。

LLMが、これまで手間に見合わなかったプロジェクトを実現可能にする

元の議論

  • LLMがSimonに与えた大きな影響の一つは、開発者としてより野心的になれたことです。
    • 以前は、プロジェクトを思いついても、実装に最適な言語がAppleScriptやGoだと分かると、自分がそれらの言語を知らないためにアイデアを棚上げにしていました。
    • 今ではLLMにコードを生成させ、期待通りに動くか検証することができます。
  • 以前からそれらの技術を学ぶことはできましたが、LLMによって参入のハードルが十分に下がり、実際に作ることが現実的になりました。

    これらの小さなプロジェクトは、LLMがなければ存在しなかったでしょう。作れなかったからではなく、かける労力に見合うだけの速さで作れなかったからです。

LLMの最新動向を追うには

元の議論

  • 最も質の高い情報は、15人程度のプライベートなWhatsAppやDiscordグループから得られるそうです。
  • X（旧Twitter）には良いAI関連の議論があります。
    • 一方Mastodonにはあまりありません。AI懐疑派が集まる場だからです。
  • Simonのブログのおかげで、LLMに関する興味深い新しい動向について人から教えてもらうことも多いそうです。

LLMが世界をひどいコードで汚染しないかもしれない理由

元の議論

  • LLMの欠点は、作者自身も理解していないコードが本番環境に投入されていることです。
    • これは世界にとってリスクであり、LLMがソフトウェア全体の品質を低下させることを示唆しています。
  • Simonは、世界の多くがLLMが生成する「グープ（ぐちゃぐちゃな）」コードよりもひどいコードで動いていることを指摘します。

    私たちは今、世界の半分が単体テストもバックアップもバージョン管理もないExcelのスプレッドシートで動いている世界に住んでいます。誰でも数式をちょっと変えただけで、企業の評価額が一夜にして半減するようなことが起こり得る……

    それが今の世界なんです。Excelのスプレッドシートは、すでにグープのようなものです。それでも社会は何とか回っている。

    だから、「コードは一行たりとも完璧でなければならない」と考えている私たちは、もしかしたら間違っているのかもしれない。実はグープこそが未来なのかもしれない。でも、ちょっと恐ろしいですよね？

ブログ

毎日新しい記事を書く

元の議論

  • Simonは毎日新しいブログ記事を書くようにしています。
    • 10年間毎週動画を投稿し続けたTom Scottに触発されたものです。
    • その日何か面白いことを見つける動機付けになります。

かける時間

元の議論

  • Simonは1日10〜15分ブログを書いています。
  • 22年間続けてきたことで、より速く書けるようになったそうです。

ブログからニュースレターへの流れ

元の議論

  • 前回のニュースレター以降にブログに追加された内容の差分をそのまま配信するニュースレターを運営しています。

    メールクライアントで情報を追っている人たちに届けるには、とても良い方法なんです。

  • ブログからコンテンツを取得してSubstack互換のリッチテキストに変換するObservableノートブックを作りました。ノートブックからSubstackにコピー＆ペーストしてニュースレターを送信しています。
  • Substackの購読者は6,000人います。
  • この作業はニュースレター1通あたり2分で終わります。

[編注：Simonは触れていませんが、このSubstackへの転載方法はSEOに悪影響を与えていると思います。同じ内容が異なるURLで2つ存在することになり、Googleがどちらをオリジナルと判断すべきか分からなくなってしまうからです。]

[編注：Substackでは独自ドメインを使えるはずなのに、SimonがSubstackのドメインをそのまま使い、simonwillison.netのサブドメインを使っていないのも意外でした。]

ブログのインフラ

元の議論

  • メインブログは、CDNとしてCloudflareの背後にあるHerokuインスタンスで動いています。

Cloudflareの素晴らしいところは、Hacker Newsのトップページにリンクされてトラフィックが急増しても、格安の小さなHerokuインスタンスには全く影響がないことです。Cloudflareがすべてのトラフィックを吸収してくれるからです。

Bingチャット騒動

元の議論

すべてをGitHub Issueで管理する

元の議論

  • 個人的なToDoリストをGitHub Issueとして管理しています。
  • 250ものプロジェクトを抱えています。
    • あらゆる細部を忘れてしまう前提でドキュメントを書いています。

      1年間触っていなかったプロジェクトに戻ってきても、そのプロジェクトをまったく知らない人のつもりでドキュメントを読めば、すぐに作業を再開できるんです。

  • 設計ドキュメントもIssueとして書いています。

    100件以上のコメントが付いたIssueスレッドがあるんですが、全部自分のコメントなんです。ただ自分自身と会話しているだけなんですよ。

[編注：これは書き込みを優先し読み取りを犠牲にしたワークフローで驚きました。あるIssueを理解しようとすると、何百ものコメントを読む羽目になり、現在の状態をまとめた単一のコメントを読むだけでは済まなくなってしまうからです。]

「一時的」なドキュメントと「現行」のドキュメント

元の議論

  • ソフトウェアのドキュメントには2種類あると考えています。
    1. ソフトウェアが現在何をするのかを説明するドキュメント。
    2. ドキュメントが書かれた時点でソフトウェアが何をしていたかを記述するもので、今日では必ずしも正確とは限らないもの（「一時的ドキュメント」）
  • GitHub Issueは一時的なドキュメントに向いています。
    • Issueを見れば、いつ書かれたものか日付で分かるので、そのドキュメントがいつ時点では正確だったのかを理解できます。
  • コードと一致している必要があるドキュメントについては、コードと同じリポジトリ内にMarkdownファイルとして保存し、コードを更新する際は必ずドキュメントも合わせて更新するようにしています。

インディー開発者としての生活

元の議論

  • Simonが独立した働き方に初めて触れたのは、スタンフォード大学でデータジャーナリズムの1年間の有給フェローシップを授与されたときでした。

    それは素晴らしい経験で、そして私を完全にダメにしてしまいました。だって、最も面白いと思うことに1年間取り組むためにお金を払ってもらえるんですから。

    一度それを経験してしまうと、他の誰かに自分が何をするかを決められる働き方に戻るのはとても難しくなります。基本的に問題は、1年間自由を味わってしまい、「もうこれを手放したくない。これらのことに取り組むのが本当に楽しい」と思ってしまったことなんです。

時間の管理

元の議論

  • 何に取り組むかを決めるのが非常に難しいと感じています。雇用されて働く場合に比べて、外からのプレッシャーや説明責任がほとんどないからです。
    • AIには探求すべき興味深い分野がたくさんあり、それを探求し続けることを止めるものは何もありません。
  • 時にはVCの投資家がいて、目標に集中させてくれればと思うこともあるそうです。
  • カンファレンス駆動開発
    • カンファレンスに間に合うように機能を約束することで、期限までに実装を優先せざるを得ない状況を作り出しています。
  • Weeknotes（ウィークノート）

経済的自立に向けて

元の議論

  • 経済的自立を目指しています。
    • EventbriteがSimonのスタートアップを成長途中で買収し、その後彼はそこでエンジニアリングディレクターとして6年間働きました。
    • 「十分なランウェイ（当面の資金）」はあるものの、収入を気にしなくてよいほどではないそうです。
    • Datasetteが主要な収入源となるだけの収益を生むまでの間、収入を確保するためにコンサルティングの機会を模索しています。

[編注：インタビュー全体で私が最も驚いたのは、てっきり経済的に自立していると思っていたSimonが、実際はそうではなかったことです。]

Datasetteの目標

元の議論

  • Datasetteの目標は、ジャーナリストがDatasetteを使って記事を書き、その記事がピュリッツァー賞を受賞することです。
  • 一人で働くのは寂しいので、一緒にプロジェクトに取り組むチームを雇いたいと考えています。
  • WordPressのモデルに倣い、コードをオープンソース化し、マネージドサービスとして提供することで収益化したいと考えています。

データジャーナリズムでLLMを使う際の課題

元の議論

  • 主要なLLMはすべて情報を検閲しており、それがデータジャーナリズムをより困難にしています。

ジャーナリストであれば、扱う一次資料の中には不快なものもありますよね。暴力事件に関する警察の報告書だったり、ファシストの掲示板だったり……今、そういったものを処理するのにLLMを使っていて、例えばそのファシストの掲示板のテーマを要約してくれと頼むと、「できません」と断られてしまうんです。

多くのLLMはそういった内容の処理をきっぱり拒否してしまうので……それがLLMの有用性を大きく制限しているんです。

メタ：このノートをどう作ったか

yt-dlpでインタビューをダウンロードしました：

yt-dlp https://www.youtube.com/watch?v=6U_Zk_PZ6Kg

次にWhisperで文字起こしを生成しました：

VIDEO_FILE="~/LLMs\ are\ weird,\ over-confident\ intern\ ｜\ Simon\ Willison\ \(Datasette\)\ \[6U_Zk_PZ6Kg].webm"
whisper $VIDEO_FILE

私のNixOSシステムのCUDA設定が原因不明で動かなくなったため、WhisperはCPUで動作し、遅くてエラーも多くなりました。そこでGoogle Gemini 2.5 Pro Previewを使って整えました：

Split this transcript into sections by topic.

Under each topic, write the timestamp that the section covers in the transcript.

Break groups of sentences into logical paragraphs under each heading.

Fix words that appear to be transcription errors, but don't editorialize or
change language.

```
1
00:00:00,000 --> 00:00:06,000
call it my weird intern. I'll say to my wife Natalie sometimes, hey so I got my weird intern

2
00:00:06,000 --> 00:00:10,800
to do this. And that works, right? It's a good mental model for these things as well because

[elided...]

```

Geminiは一度に約30分分の文字起こししか処理できず、出力トークンが尽きてしまうので、指示の末尾にStart at 00:26:26,240と付け加えて何度も繰り返す必要がありました。

それから、整形されたすべての文字起こしをまとめました。

すると、このような整理された文字起こしができます：

### The Efficiency and Benefits of Consistent Blogging
(00:08:44,480 --> 00:11:24,800)

Well, that's the secret of blogging, is that it takes a lot of work at first,
but I've been blogging for 22 years...

次に、自分のノートを以下のプロンプトでGemini 2.5 Proに渡しました：

Here is a transcript of an interview that's available on YouTube
at https://www.youtube.com/watch?v=6U_Zk_PZ6Kg:

```
SRT TRANSCRIPT GOES HERE
```

Here are  my notes about the interview:

```
MARKDOWN VERSION OF THIS BLOG POST GOES HERE
```

Reproduce the headers in my notes, but under each, include a link to the
original YouTube video that the transcript came from with a timestamped link
that points to that part of the conversation.

直接の引用がすべて正確かどうか検証したかったのですが、良い方法が見つかりませんでした。最初はGemini ProとFlashにプロンプトを送って、引用部分だけに編集した動画を作るffmpegコマンドを生成させようとしましたが、うまくいきませんでした。次に、すべての引用にタイムスタンプ付きのYouTubeリンクを付けさせようという控えめな方法を試しましたが、常に数分ずれてしまいました。結局、SRTファイルを検索して動画の該当箇所に手動でシークして確認しました。ある箇所ではGeminiがSimonの言葉を完全に書き換えていましたが、引用のほとんどは正確でした。

リンク

原文は Michael Lynch により に公開されました。

この記事は「muse-spark-1.2-contributor」を使用して翻訳されました。