Refactoring English:14ヶ月目
原文は Michael Lynch により に公開されました。 このブログを購読する
一言サマリー
AIサンドボックスの力を発見
初めての方はこちら
こんにちは、Michaelです。ソフトウェア開発者で、小さなインディーテックビジネスをいくつか立ち上げてきました。現在はRefactoring English: Effective Writing for Software Developersという本の執筆に取り組んでいます。
毎月、こうした振り返り記事を公開して、本の進捗や仕事全体の状況を共有しています。
ハイライト
- 本の読者を見つけるための新しい戦略が成果を上げ始めています。
- AIエージェントを制限なしで動かしてみたことで、大きな発見がありました。
- 後悔していた技術スタックの選択を、AIを使って修正しています。
目標の成績表
毎月初めに、その月に達成したいことを宣言しています。今月はこのように結果が出ました。
Refactoring Englishの3章を公開する
- 結果:2つの新しい章を公開しました
- 評価:B-
先月と同じく、AIの実験に夢中になりすぎて、執筆の時間を削ってしまうという問題が続いています。
2025年の年次レビュー(8年目)を公開する
- 結果:公開しました
- 評価:A
完了しました!仕上がりにも満足しています。慣例や時事性から期日までに公開しなければならないと感じていた一連の投稿が、ようやく一段落しました。
Refactoring Englishの指標
| 指標 | 2025年12月 | 2026年1月 | 増減 |
|---|---|---|---|
| ユニークビジター | 2,266 | 38,511 | +36,245 (+1600%) |
| 予約販売による収益 | $492.55 | $1,132.75 | +$640.20 (+130%) |
| スポンサー収益 | $48.25 | $0.00 | -$48.25 (-100%) |
1月初めに「The Most Popular Blogs of Hacker News in 2025」を公開したのですが、予想をはるかに上回る反響がありました。おかげで1月は、昨年のKickstarter以来、最も訪問者数と収益が多い月になりました。
一方で、その他の収益は減少しています。編集の依頼がなかったことに加え、TinyPilotの現オーナーによる本のスポンサーシップが2025年で終了したためです。今後は企業スポンサーを積極的に探すつもりはありません。企業側の関心がそれほど高くないうえ、読者に集中した方がシンプルだからです。
他の書き手について書くことで得られた成功
「The Most Popular Blogs of Hacker News in 2025」は、ここ半年ほど試してきた戦略の延長線上にあります。一言で言えば、他のソフトウェア系の書き手を称賛することです。
昨夏のパーティーで、セルフ出版をしているロマンス小説家の方と知り合いました。全く異なるジャンルを書いているのに、抱えている悩みが似通っていて、話を聞くのがとても興味深かったです。
読者をどう見つけているのか尋ねると、彼女は「それが一番の悩みなのよね!」と答えました。
彼女は、主にインディー作家のロマンス小説を紹介するニュースレターを始めたところ、大きな成果があったと教えてくれました。それによって次のような好循環が生まれたそうです。
- 読者がニュースレターを読んで彼女の本を見つけ、購入する。
- 他のインディー作家たちは自分の作品が紹介されるのを喜び、自身の読者を彼女のニュースレターに誘導する。これが(1)をさらに増やす。
- 購読者はニュースレターを通じて、他の面白い小説に出会える。
私は、関係者全員のインセンティブが一致する戦略が大好きなので、これを自分の本に応用できないか考え始めました。そこで、自分が好きなブロガーや著者について書き、それをブログで公開し始めたところ、うまくいっています。
| 記事 | ユニーク読者数 | Hacker Newsスコア | Lobstersスコア |
|---|---|---|---|
| The Most Popular Blogs of Hacker News in 2025 | 33.8k | 692 | - |
| The Software Essays that Shaped Me | 25.6k | 308 | 85 |
| What Makes the Intro to Crafting Interpreters so Good? | 3.5k | - | 137 |
AIサンドボックスの威力に気づく
1年前に初めてAIエージェントを使い始めたとき、目から鱗が落ちるような体験をしました。当時は、ただ見守りながらファイル編集を任せるだけでしたが、それでもLLMに与える権限としては恐ろしいほど大きいと感じていました。
この1年ほどは、VS CodeのAIエージェント拡張であるClineを主に使ってコーディングしてきました。多くの作業が速くなりましたが、開発マシン上で勝手な操作をされるのが怖くて、かなり細かく管理していました。
数週間前、友人のokayが、OpenAIのターミナルベースのAIエージェントであるCodexを使ったワークフローを見せてくれました。okayはCodexに直接の監視なしでファイル編集やコマンド実行を任せています。それを見て、自分がAIエージェントにつきっきりで監視したり、Clineのフリーズに対処したりするのに、どれだけ時間を無駄にしていたかに気づかされました。
okayは、時には1時間以上Codexを監視なしで動かしっぱなしにすることもあると言い、信じられませんでした。Clineに10分以上かかるタスクを任せると、UIがハングするか、間違った方向に進むか、コストが跳ね上がるかのいずれかでした。しかしCodexはトークン課金ではなく定額制なので、コストを気にする必要がなくなります。
それでも、実際の自分のPC上でAIエージェントを野放しにする気にはなれないので、マシン上でAIエージェントを動かすための独自のサンドボックスを用意しました。プロジェクトのディレクトリに移動して、自作コマンドのsbを実行します。するとrootlessなPodmanコンテナが起動し、ローカルネットワークにはアクセスできず、カレントディレクトリだけが見える状態になります。そこにはCodexとClaude Codeがあらかじめインストールされ、自分のアカウントで認証済みになっています。
AIをサンドボックスに入れておけば、ファイル編集やアプリケーションのインストールなど、フル権限を与えても安心でした。
そして、その違いは驚くべきものでした!
フル権限で動くAIエージェントを見ることは、私にとってまた別のブレイクスルーでした。以前は「過去8年間の収入の棒グラフを作って」と頼むと、3割ほどの確率でAIエージェントは何かしら不完全なものを作りました。自分で結果を確認して「いや、棒の位置がずれているよ。直して」と言わなければなりませんでした。しかし、AIエージェントが自身のサンドボックス内でroot権限を持てば、テストサーバーを立ち上げ、ブラウザでページを確認し、タスクが完了するまで自律的に反復できます。
そしてRalph Loopsのことを知りました。今でも良い解説が見つかっていないので、自分が「公式」なRalph Loopsをやっているのかは定かではありませんが、私のやり方はこうです。ralph-loopというbashスクリプトを実行するのですが、中身はこのようなシンプルなコードです。
#!/usr/bin/env bash
rm ALL-DONE.txt || true
while true; do
cat AGENT-WORKFLOW.md | codex exec
if [[ -f "ALL-DONE.txt" ]]; then
echo "ALL-DONE.txt detected. Exiting."
exit 0
fi
done
そしてAGENT-WORKFLOW.mdはこんな感じです。
1. Pick the top task in TODO.md and begin work on it
- If no actions remain, write a file called ALL-DONE.txt to the current
directory, and exit.
1. Complete the task and delete the entry from TODO.md.
- If the task is unachievable, explain why in the commit message.
1. Commit the changes with a detailed commit message explaining what you
changed, why you changed it, and what impact it had.
あとはTODO.mdというファイルにタスクのリストを書いておくだけです。タスクの中には後続のタスクを生成するものもあるので、リストはエージェントの進行に合わせて増えたり減ったりします。
Ralph Loopのおかげで、AIエージェントを10時間以上、監視なしで自律的に動かせるようになりました。朝起きてパソコンの前に戻ると、自分が寝ている間に割り当てた作業をすべてAIエージェントが終えているのを見るのは、なんとも不思議な感覚です。
AIはコードの移植が得意
この数ヶ月AIでいろいろ試す中で、最も効果が大きいのは次のような場合だと気づきました。
- 成功の基準を客観的に定義できる。
- 例:「このクラッシュの原因を見つけて」は客観的で定義可能だが、「このランディングページを良くして」はそうではない。
- AIエージェントが成功を自律的に検証できる。
- 例:「ブラウザでページを開き、ボタンを押すと背景が青くなることを確認して」
- ジュニアレベルのソフトウェア知識を持つ人間が、検索エンジンと試行錯誤と根気があれば解決できるような問題である。
これらの基準を満たすソフトウェアタスクの例は次のとおりです。
- 自動テストがあるコードのリファクタリング
- 挙動を保ったまま、ある言語・技術から別の言語・技術へコードを移植すること
- 必要な依存関係をインストールし、プロジェクトをソースからコンパイルすること
- テストが通るようにコードを修正すること
最近、私はAIを使ってコードの移植をしています。技術スタックについて別の選択をしておけばよかったと思うコードベースがいくつかありますが、すべてを書き直すにはこれまで時間がかかりすぎていました。でもAIを使えば、スタックの一部を入れ替えることが安く、速くできます。
いくつかのプロジェクトで、コードの移植に成功しました。
- ZestfulのウェブサイトをVue/Nuxt2からHugoを使った素のHTMLへ変換
- GitHubから、聞いたこともない推移的なNode.jsライブラリ経由で脆弱性があるというアラートが届きました。「もうこんなアラートは見たくないな」と思ったので、AIにHugoと素のHTML/JS/CSSでサイトを書き直してもらいました。
- PicoShareのCSSフレームワークをBulmaからBootstrapへ移植
- PicoShareを作ったとき、CSSフレームワークとしてBulmaを試してみたかったのです。悪くはなかったのですが、私はBootstrapの方が好みで、他の場所ではずっとBootstrapを使っていたので、PicoShareに取り組むたびに頭を切り替えなければなりませんでした。
- LogPasteのE2EテストをCypressからPlaywrightへ変換
- E2Eテストを書いたのはPlaywrightを知る前で、今ではすっかりPlaywrightに慣れてしまったので、Cypressに戻るのが難しくなっていました。
- fusion RSSリーダーをSvelteから素のHTML + Goテンプレートへ変換
- これは単なる概念実証で、fusionは私のプロジェクトではありませんが、自分の好みの技術スタックで使えるようフォークしたいと考えています。AIはすべてのSvelteコードを素のHTMLとGoテンプレートに変換するのをうまくやってくれましたが、本気で移植するなら、もう少しテスト基盤を整えたいところです。
- MeshCoreウェブアプリをVue.jsからFlutterへ変換
- これは実はうまくいきませんでした。「AIが結果を検証できる」というステップが欠けていたからです。Flutterはウェブアプリの出力としてセマンティックなHTMLを生成すると思っていましたが、実際にはいびつなFlutter中心のHTML方言を生成します。しかもMeshCoreアプリは外部ハードウェア(LoRa無線)に大きく依存しているため、私自身が頻繁に介入する必要がありました。
サイドプロジェクト
StreamPreserve
目の前で起きている出来事をスマホで記録したいけれど、誰かにスマホを奪われて映像を消されたり、スマホ自体を破壊されたりする可能性がある状況で、どうすればいいかを考えていました。
そこで作ったのがStreamPreserveです。重要な映像を素早くリモートの安全なサーバーに転送するウェブアプリです。

StreamPreserveは重要な映像を捉え、できるだけ迅速にリモートサーバーへ転送します。
仕組みは次のとおりです。
- StreamPreserveアプリを開いて録画を開始します。
- アプリは低解像度の映像をバックエンドサーバーにストリーミングし、利用可能な帯域に応じて画質を調整します。
- アプリは高解像度の映像を、分割されたチャンクとしてブラウザのストレージに記録します。
- 帯域に余裕があれば、ストリーミングを続けながら、高解像度のチャンクをサーバーにアップロードします。
- 録画を停止すると、アプリは高解像度の映像をローカルデバイスにダウンロードとして保存します。
- アプリが開いていて録画中でないときは、デバイス上のすべての高解像度映像をサーバーに同期します。
つまり、何かを録画している最中に誰かにスマホを叩き割られても、StreamPreserveサーバーには低解像度のコピーが残るという考えです。そして、誰かにスマホを取り上げられて録画を止めさせられても、ウェブアプリがバックグラウンドで高解像度の映像をアップロードし続けます。
いくつかの欠点に気づいて、このアイデアへの熱意は冷めてしまいました。
- 何時間もの映像を記録するには向いていません。
- ウェブアプリとして実装することで複雑さが増し、映像を失う可能性もあります。本来はネイティブモバイルアプリにすべきですが、私はモバイル開発が苦手です。
- ブラウザのカメラAPIに依存しており、AIサンドボックスでごまかすのが面倒なため、AIに任せるのにはあまり向いていません。
まとめ
何を達成したか?
- ブートストラップな創業者としての8年目を公開
- Refactoring Englishの新しい章を2つ公開
- 自作のPDFファジングワークフローで発見したPoDoFo PDFリーダーのクラッシュを修正
学んだこと
- 他のソフトウェア系の書き手を称賛することで、新しい読者を見つけることができる。
- AIエージェントは、root権限を持ち、アプリケーションのインストールやウェブ検索ができる環境で動かすと、はるかに有用になる。
- 成功基準を客観的に定義でき、エージェントが成功を検証して反復的に自己修正できる場合、AIは問題解決が得意だ。
- AIはコードをある技術から別の技術へ移植するのが得意だ。
来月の目標
- Refactoring Englishの2章を公開する。
- Refactoring Englishの読者向けにライブイベントを企画する。
記事をランダムに読む
コメント
ログインしてコメントする