Blog Dice

Notes from Simon Willison's Interview on Software Misadventures

Michael Lynch

Simon Willison氏の『Software Misadventures』インタビュー覚書

原文は Michael Lynch により に公開されました。 このブログを購読する

先ほど、ポッドキャスト『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%で、これは同じ作業を人間のインターンたちに頼んだ場合とほぼ同程度だ。
  • ソフトウェアアーキテクチャの意思決定
    • SimonはLLMに同じタスクを達成するためのさまざまな選択肢を挙げさせ、それぞれの長所と短所について議論させる。
  • 論文を読む
    • Simonは、馴染みのない用語を解説するDejargonizerというツールを作った。
    • [編注：このツールは実用的な道具というより、面白いアイデアという印象を受けた。テキストを貼り付ける必要があるのだが、5ページの論文を投入したところコンテキスト制限に達してしまった。専門用語をインラインで定義しながらテキスト自体を書き換えてくれる方が理にかなっていると思う。]

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

元の議論

  • Simonは妻に対してLLMのことを「自分の奇妙なインターン」と説明している。

    あらゆるプログラミング言語のドキュメントを丸暗記していて、荒唐無稽な陰謀論者でもあり、ときどき突拍子もないアイデアを出してきて……しかもものすごく自信過剰なインターンを抱えているようなものなんだ。

  • 人間のチームメイトに対するLLMの大きな利点は、解決策の改善を何度でも頼み続けられることだ。
    • 人間の同僚相手だと、プルリクエストを改善するための新しいアイデアを次々と思いついて繰り返し頼むのは相手を苛立たせるので、どこかで切り上げなければならないが、LLMなら相手の時間を無駄にしているのではと気兼ねすることなく、大幅な書き直しを頼める。
  • Simonは、単に「もっと良くして」と言うだけでLLMに回答を改善させられることに気づいた。

    お気に入りのプロンプトの一つが、単に「もっと良くして」と言うことなんだ。そしてそれが実際に効く。信じられないことだよ！

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

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

元の議論

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

    これらの小さなプロジェクトはすべて、LLMがなければ存在しなかっただろう。作れなかったからではなく、手間に見合うほど素早く作れなかったからだ。

LLMの最新動向を追う

元の議論

  • 最もシグナル／ノイズ比の高い情報は、15人程度のプライベートなWhatsAppやDiscordグループから得られる。
  • Twitterには良質なAI関連の議論がある。
    • Mastodonにはない。AI懐疑派が集まるからだ。
  • Simonのブログのおかげで、興味深いLLMの新展開についての情報が人から寄せられることも多い。

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

元の議論

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

    私たちは今、世界の半分が、単体テストもバックアップもバージョン管理もないExcelスプレッドシートで動いている世界に生きている。誰でも数式を台無しにできて、一夜にして企業の評価額が半減することもある……

    それが今日私たちが生きている世界だよね？ Excelのスプレッドシートは、ある意味ですでにグープなんだ。でも somehow 社会は機能している。

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

ブログ

毎日新しいブログ記事を書く

元の議論

  • Simonは毎日新しいブログ記事を書くようにしている。
    • 10年間毎週動画を公開し続けたTom Scottに触発されたものだ。
    • それが、その日に何か面白いことを見つけようという動機になっている。

時間の投資

元の議論

  • Simonは1日10〜15分ブログに費やしている。
  • 22年間続けているため、より速く書けるようになった。

ブログからニュースレターへのパイプライン

元の議論

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

    メールクライアントで生活している人たちに情報を届ける本当に良い方法なんだ。

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

[編注：Simonは触れていないが、このようにSubstackへ配信する方法はSEOに悪影響を与えると思う。同じ内容が異なるURLで重複して存在することになり、Googleがどちらがオリジナルか判断できなくなるからだ。]

[編注：Substackは独自ドメインの持ち込みが可能だと思うので、Simonがsimonwillison.netのサブドメインではなくSubstackのドメインを使っているのも意外だった。]

ブログのインフラ

元の議論

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

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

Bingチャット騒動

元の議論

すべてをGitHub Issueにする

元の議論

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

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

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

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

[編注：これは驚きのワークフローだ。読みやすさよりも書きやすさを最適化している。あるIssueを理解したいときに、現在の状態をまとめた一つのコメントを読むのではなく、何百件ものコメントを読まざるを得なくなるからだ。]

「一時的（Temporal）」なドキュメント vs. 現行のドキュメント

元の議論

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

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

元の議論

  • Simonが独立した働き方の味を知ったのは、スタンフォードでデータジャーナリズムの有給フェローシップを1年間得たときだった。

    素晴らしい経験で、完全に駄目にされてしまった。だって、自分が最も面白いと思うことに1年間取り組むためにお金をもらえたんだから。

    一度それを経験すると、また誰かに……自分が何をすべきかを決められる状態に戻るのはとても難しい。つまり問題は、1年間自由を経験してしまって、「これを手放したくない。こんなに楽しく取り組めているのに」と思ってしまったことなんだ。

時間管理

元の議論

  • Simonは、何に取り組むかを決めるのが極めて難しいと感じている。雇用主のために働く場合と比べて、外部からのプレッシャーや説明責任がほとんどないからだ。
    • AIには探求すべき興味深い領域があまりにも多く、それを永遠に探求し続けることを止めるものは何もない。
  • 時にはVC投資家がいてくれれば、誰かが自分の目標に集中させてくれるのにと思うこともある。
  • カンファレンス駆動開発
    • Simonはカンファレンスに間に合うように機能を約束することで、期限までに実装を優先せざるを得ない状況を作り出している。
  • Weeknotes
    • Simonは数週間ごとに「weeknotes」と呼ぶブログ記事を書き、過去数週間の仕事をまとめていた。
    • [編注：私も似たようなことをやっている。Googleで身につけた習慣だ。]
    • [編注：偶然にもSimonはこのインタビュー直後にこれをやめてしまった。]

経済的自立を目指して

元の議論

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

[編注：このインタビューで私が最も驚いたのは、Simonがまだ経済的に自立していないことだった。てっきりそうだと思い込んでいたので。]

Datasetteの目標

元の議論

  • Datasetteに関するSimonの目標は、ジャーナリストがDatasetteを使ってピュリッツァー賞を受賞する記事を書くことだ。
  • 一人で働くのは寂しいので、プロジェクトを共に進めるチームを雇いたいと考えている。
  • コードをオープンソース化し、マネージドサービスとして提供することで収益を得るというWordPressモデルを踏襲したいと考えている。

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

元の議論

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

ジャーナリストなら、扱う一次資料の中にはひどいものもあるよね？ 暴力事件に関する警察の報告書とか、ファシストの掲示板とか……。今、そういうものを処理するのを手伝ってくれるLLMがあって、このファシストの掲示板からテーマを要約してって頼んだら、「できません」って言うわけだよね？

多くのLLMはそういった処理を真っ向から拒否する。それが……どれだけ役に立てるかに大きな制限をかけているんだ……

メタ：この覚書をどのように作成したか

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

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

そしてWhisperを使って文字起こしを生成した。

VIDEO_FILE="~/LLMs\ are\ like\ your\ 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の言葉を完全に書き換えていたが、ほとんどの場合、引用は正確だった。

リンク

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

コメント