ひとことで言うと

AIサンドボックスの威力を発見する

ハイライト

• 本の読者を見つけるための新しい戦略が成果を上げています。
• AIエージェントを制限なしモードで動かしてみたところ、ブレイクスルーとなる体験ができました。
• 後悔していた技術スタックの選択を、AIを使って修正しています。

目標の達成度

毎月初めに、その月に達成したいことを宣言しています。結果は次のとおりです。

Refactoring Englishを3章公開する

• 結果：2つの新しい章を公開しました
• 評価：B-

先月と同じく、AIの実験に夢中になりすぎて執筆の時間が削られてしまうという課題が続いています。

2025年の年次レビュー（8年目）を公開する

• 結果：公開しました
• 評価：A

完了しました！仕上がりにも満足しています。恒例の行事や時期に左右されるテーマなど、期日までに公開しなければならないと感じていた一連の記事がようやく一段落しました。

Refactoring Englishの指標

1月初めに「The Most Popular Blogs of Hacker News in 2025」を公開したところ、予想をはるかに上回る反響がありました。おかげで1月は、昨年のKickstarter以来、最も訪問者数と収益が多い月になりました。

その他の収益は減少しています。編集のクライアントがいなかったことに加え、TinyPilotの現オーナーによる本へのスポンサーが2025年で終了したためです。今後は法人スポンサーを積極的に探す予定はありません。企業側の関心がそれほど高くないうえ、読者に集中したほうがシンプルだからです。

他の書き手を紹介することで得られた成功

「The Most Popular Blogs of Hacker News in 2025」は、ここ半年ほど試してきた戦略の延長線上にあります。要するに、他のソフトウェア系ライターを称えるということです。

去年の夏、あるパーティーで自費出版をしている恋愛小説家の方と出会いました。書いているジャンルはまったく違うのに、抱えている悩みは驚くほど似ていて興味深かったのを覚えています。

どうやって読者を見つけているのか尋ねると、彼女は「それが一番の悩みよね！」と答えました。

彼女は、主にインディー作家の恋愛小説をレビューするニュースレターを始めたところ、大きな成果があったと教えてくれました。次のような好循環が生まれたそうです。

1. 読者がニュースレターを読んで彼女の本を見つけ、購入します。
2. 他のインディー作家が自分の作品のレビューを喜び、自身の読者を彼女のニュースレターに誘導するため、（1）がさらに増えます。
3. 購読者はニュースレターを通じて、他の魅力的な小説に出会えます。

誰にとってもメリットがあるこうした戦略が私は大好きなので、自分の本でも応用できないか考え始めました。自分が好きなブロガーや著者を紹介する記事を書き、ブログで公開してみたところ、これがうまくいっています。

AIサンドボックスの威力を発見する

1年ほど前、はじめてAIエージェントを使ったときは衝撃を受けました。当時は、目の前でファイル編集をさせているだけでも、LLMに与える権限としては怖いほど大きいと感じました。

この1年ほどは、VS CodeのAIエージェント拡張であるClineを中心にコーディングしてきました。多くの作業が速くなった一方、開発マシン上で勝手な操作をされるのが怖くて、細かく監視しながら使っていました。

数週間前、友人のokayが、OpenAIのターミナル型AIエージェントであるCodexを使ったワークフローを見せてくれました。okayはCodexにファイル編集やコマンド実行を直接監督なしで任せていました。自分がいかにAIエージェントに付きっきりになり、Clineのハングに時間を取られていたかを思い知らされました。

okayいわく、Codexを1時間以上 unsupervised（無人）で動かすこともあるそうです。私には信じられませんでした。Clineに10分以上かかるタスクを任せると、UIが固まるか、見当違いの方向に進むか、コストが跳ね上がるのが常だったからです。一方、Codexは従量課金ではなく定額制なので、コストを気にせず使えます。

とはいえ、AIエージェントを自分の実機で自由に暴れさせる気にはなれなかったので、マシン上でAIエージェントを動かすための専用サンドボックスを用意しました。プロジェクトのディレクトリに移動して自作コマンドのsbを実行すると、rootless Podmanコンテナが立ち上がります。ローカルネットワークにはアクセスできず、カレントディレクトリだけが見える状態です。中にはCodexとClaude Codeがインストール済みで、私のアカウントで認証も済んでいます。

AIをサンドボックス内で動かすことで、ファイル編集やアプリケーションのインストールなどをフル権限で任せることに抵抗がなくなりました。

そして、その違いは驚くほどでした！

フル権限で動くAIエージェントを見るのは、私にとってまたしてもブレイクスルーでした。以前、「過去8年間の収入を棒グラフにして」と頼むと、3回に1回くらいはどこか不完全なものが出来上がりました。自分で結果を確認して「いや、棒の位置がずれているよ。直して」と伝えなければなりませんでした。でも、サンドボックス内でroot権限を持つAIエージェントなら、自分でテストサーバーを立ち上げ、ブラウザでページを確認し、タスクが完了するまで自律的に試行錯誤してくれます。

そして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時間以上 unsupervisedで動かせるようになりました。朝起きてパソコンを開くと、寝ている間にエージェントが割り当てた作業をすべて終えているのを見るのは、なんとも不思議な感覚です。

AIはコードの移植が得意です

ここ数ヶ月AIを試してきて、AIが最も効果を発揮するのは次の条件がそろったときだと感じています。

1. 成功の基準を客観的に定義できる。
   • 例：「このクラッシュの原因を見つけて」は客観的に定義できますが、「このランディングページを良くして」はそうではありません。
2. AIエージェントが自分で成功を検証できる。
   • 例：「ページをブラウザで開いて、ボタンを押したら背景が青くなることを確認して」
3. ジュニアレベルのソフトウェア知識を持つ人間が、検索エンジンと試行錯誤と根気があれば解ける程度の問題であること。

これらの条件を満たすソフトウェアタスクの例は次のとおりです。

• 自動テストがあるコードのリファクタリング
• 挙動を保ったまま、ある言語・技術から別の言語・技術へコードを移植すること
• プロジェクトをソースからコンパイルし、必要な依存関係をインストールすること
• テストが通るようにコードを修正すること

最近、私はAIを使ってコードの移植をしています。技術スタックについて別の選択をしておけばよかったと思うコードベースがいくつかあったのですが、すべてを書き直すのは時間がかかりすぎると諦めていました。でもAIを使えば、スタックの一部を入れ替えるときのコストも時間もぐっと小さくなります。

いくつかのプロジェクトで、実際に移植に成功しました。

• ZestfulのウェブサイトをVue/Nuxt2からHugoを使った素のHTMLへ変換しました。
  • 一度も聞いたことのない推移的なNode.jsライブラリ経由で脆弱性があるというGitHubアラートが届きました。「もうこんなアラートは見たくない」と思い、AIにサイトをHugoと素のHTML/JS/CSSで書き直してもらいました。
• PicoShareのCSSフレームワークをBulmaからBootstrapへ移植しました。
  • PicoShareを作ったとき、CSSフレームワークとしてBulmaを試してみました。悪くはなかったのですが、他のすべてのプロジェクトでは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です。重要な映像をできるだけ早くリモートの安全なサーバーへ退避するウェブアプリです。

仕組みは次のとおりです。

1. StreamPreserveアプリを開いて録画を開始します。
2. アプリは利用可能な帯域に合わせて品質を調整しながら、低解像度の映像をバックエンドサーバーへストリーミングします。
3. アプリは高解像度の映像を、分割されたチャンクとしてブラウザのストレージに記録します。
4. 空き帯域があれば、ストリーミングを続けながら高解像度のチャンクをサーバーへアップロードします。
5. 録画を停止すると、高解像度の映像がローカル端末にダウンロードとして保存されます。
6. 録画していない状態でアプリを開いている間は、端末上の高解像度映像がすべてサーバーへ同期されます。

つまり、録画中に誰かにスマホを壊されても、StreamPreserveサーバーには低解像度のコピーが残ります。誰かにスマホを奪われて録画を止められても、ウェブアプリがバックグラウンドで高解像度の映像をアップロードし続けます、という発想です。

やがて、このアイデアへの熱は冷めてしまいました。いくつか欠点に気づいたからです。

• 長時間の録画には向いていません。
• ウェブアプリとして実装すると複雑さが増し、映像を失うリスクも高まります。本来はネイティブのモバイルアプリにすべきですが、私はモバイル開発が苦手です。
• ブラウザのカメラAPIに依存するため、AIのサンドボックスでごまかすのが面倒で、AI向きのタスクではありません。

まとめ

何ができましたか？

• ブートストラップな創業者としての8年目を公開しました
• Refactoring Englishの新しい章を2つ公開しました
• PoDoFo PDFリーダーで見つかったクラッシュを修正しました。PDFファジングのワークフローで発見したものです

学んだこと

• 他のソフトウェア系ライターを称えることが、新しい読者との出会いにつながります。
• AIエージェントは、root権限を持ち、アプリケーションのインストールやウェブ検索ができる環境で動かすと、格段に有用になります。
• 成功基準を客観的に定義でき、エージェント自身が成功を検証して反復的に自己修正できる場合、AIは問題解決が得意です。
• AIはある技術から別の技術へのコード移植が得意です。

来月の目標

• Refactoring Englishを2章公開します。
• Refactoring Englishの読者向けライブイベントを企画します。