月額110ドルの自己改善パイプライン

自分のバックログを手動で管理する作業に疲れたので、ラップトップ上で Claude Code を使って自分で実装するのはやめました。そこで、システムが自動でトリアージを行い、タスクが大きすぎれば分解し、実装を実行してテストを走らせ、PR を作成するというループを構築しました。マージ作業はスマホから行っています。

この仕組みは 2 週間稼働しており、これまでに 27 件のマージと 1 件の失敗を記録しています。平均コストは課題あたり約 1.61 ドルです。

2 週間経過した現在、数値はまだ変動する可能性があります。現在は引き続きデータを収集中ですが、システムが成熟するのを待って更新するよりも、今の時点でこの仕組みの概要を共有したいと考えました。なぜなら、このパターンはすでに十分に機能しているように見えるからです。

コスト

$100.00/月 Claude Max（5 回使用：トリアージおよび Claude Code CLI を介した実装）

$ 9.99/月 VPS（Hostinger、2 vCPU、8GB RAM、Ubuntu）

$ 0.00/月 GitHub

─────────

$109.99/月 合計

設定

このシステムは autoloop です。ループを設定する単一のファイルがあります。

autoloop.toml

repo = "your-org/your-repo"

triage_model = "sonnet"

impl_model = "claude-opus-4-6"

verify_cmd = "uv run pytest"

max_retries = 3

protected_paths = ["autoloop/", "autoloop.toml"]

systemd タイマーを 3 つ設定するだけです。Kubernetes も、オーケストレーションフレームワークも、複雑なキューサービスも使いません。

OnCalendar=*-*-* 00:00:00 UTC # トリアージ

OnCalendar=*-*-* 02:00:00 UTC # 実装

OnCalendar=*-*-* 04:00:00 UTC # チンジログ

イシューへの処理フロー

imageimage

GitHub のイシューがキューに入ります。放置された場合の処理は以下の通りです。

トリアージ (Sonnet、約 0.10 ドル): 課題を読み込み、その妥当性を検証し、ストーリーポイントを算出、優先度を決定します。もし課題が大きすぎる場合は、依存関係の順序を考慮してサブタスクに分解し、それぞれを個別にトリアージします。すべてのピースが一度の通しでビルド可能になるまで再帰的に分割し、スマホでレビューできる程度の小さな PR を生成します。

実装 (Opus、約 1.50 ドル): 依存関係に基づき最優先の課題を選び出し、ブランチを作成。Claude に課題仕様とリポジトリの文脈を渡して実行し、テストとリンティングを実行。テストファイルが追加されたか確認した上で PR を作成します。

検証ゲート: テスト失敗やテストファイル未追加の場合は最大 3 回再試行し、エラー内容をフィードバックして次の試行の文脈として提供します。それでも全試行で失敗した場合、「人間の介入が必要」とラベル付けし、キューの次項目へ進みます。

私はスマホで待機中の PR をレビューし、マージします。これが私のループへの貢献です。PR マージを自動化できないか？可能です。しかし、あえて私がゲートキーパーとなるよう設計したのが、このアーキテクチャの意図です。

失敗した日

8 日目。Issue #40 は重複する課題でした。すでに実装済みである旨が記述されていたにもかかわらず、システムは変更を生成しようと 3 回試行しました。しかし変更点は見つからず、差分がないため検証に失敗。「人間の介入が必要」とラベル付けされ、キューの次項目へ進みました。

課題を確認し、失敗の理由を読み込みました。その上で課題をクローズしました。これは正しい判断です。人間であれば重複と気づいてクローズしますが、当時はシステム側がそれを理解することはできませんでした。単に有効な PR を生成できないという事実だけを知っていたのです。そのため、システムは自ら退避しました。

12 日目。Issue #159 が 3 つのサブ課題に分解されました。そのうち 2 つ目のサブ課題で生成された PR が、1 つ目の PR で導入したインポートパスを壊してしまい、マージ競合が発生しました。私は Claude Code のリモートセッション（VPS 上の tmux）からスマホで修正し、わずか 4 分で解決しました。

見えてきたパターン: 失敗するときは、ほぼ例外なく私の課題記述が曖昧だったか、ビルダーが持っていない前提の文脈が含まれていたからです。より良い課題記述が、より良い PR を生みます。このシステムは、従来のコードレビューよりも早く、私の不十分な仕様を露呈させてくれました。

安全を保証する制約

システムは自分自身を変更できません。

protected_paths = ["autoloop/", "autoloop.toml"]

課題が protected_paths 内のファイルを対象とする場合、トリアージ（選別）プロセスで「人間の介入が必要」として処理されます。ビルダーは自らのロジックやパイプライン、設定ファイルに一切手を加えることができません。この安全チェックは、トリアージ段階（第一のゲート）と実装段階（セーフティネット）の両方で実行されています。

*自己改修なしでの自己改善*。システムが改善するのはあくまで*製品*そのものです。プロセス自体を改善することはできません。この境界線こそが、無人で運用しても安全だと私が考える理由です。

何を作ったか

Patina は、Python コードが約 7,200 行、テストコードが 9,200 行、そして MCP ツールが 31 個あります。

初期のアーキテクチャは対話形式で私が構築しました。基盤がしっかり固まると、その後は「autoloop」がバックログ処理を引き継ぎます。直近マージされた PR 40 件のうち、27 件は自律的に作成されたものです。

パイプライン自体のコード量は 3,500 行です。当初は Patina のリポジトリ内に埋め込まれていましたが、現在は スタンドアロンのパッケージとして独立 しています。これを使えば、他のリポジトリにもワンコマンドで適用可能です。

autoloop init --repo your-org/your-repo --verify-cmd "pytest"
autoloop triage
autoloop implement

どこで機能し、どこで機能しないか

このアプローチがどこに適用可能か、正直にお話しします。

向いているケース:

ソロビルダー、小規模チーム、あるいは一人（または一つのチーム）がシステム全体の文脈を把握できるリポジトリ。24 時間以内に修正が間に合えばよい、クリティカルパスではないシステムです。

まだ向いていないケース:

規制の厳しい環境、複数チームで開発するコードベース、ロールバック機能が必要だが今回のセットアップでは提供されていない SLA（サービスレベルアグリーメント）を課された顧客向けプロダクションなどです。このパターンは規模に関係なく適用可能ですが、今回の実装は「ゲートキーパーとして人間が一人」であることを前提としています。

2 週間という期間で長期的な証明をするのは無理があります。3 ヶ月、6 ヶ月の時点でもう一度更新します。もし性能が低下すれば、その発見も共有します。私は単にこのパターンを提示しているだけで、「勝利宣言」をしたり、すべての実世界ユースケースを解決する万能なソリューションだと主張したりしているわけではありません。

学んだこと

ボトルネックはモデルでもインフラでもありません。重要なのは「課題の質」です。曖昧な課題から生まれるのは品質の低いプルリクエストですが、明確な受入基準とファイルパスのヒントを含む具体的な課題からは、最初のレビューで即座にマージされるような高品質なコードが生まれます。

1 年前ならこれを実現するにはチームが必要でしたが、今では単なる VPS と、課題を記述する文章力だけで十分です。

code: github.com/Sanctum-Origo-Systems/autoloop。次の投稿では、なぜ「観測者」と「構築者」が別々のインスタンスとして設計されているのかを解説します。