BitTorrentクライアントをAIエージェントだけで作った話

はじめに#

「BitTorrent クライアントを Go でゼロから書きたい」——そう思い立ってから完成まで、かかった時間は約 3.5 日だった。

成果物は stor ↗。外部の torrent ライブラリに一切依存せず、bencode パーサーから DHT、uTP、暗号化まで全てスクラッチで実装した BitTorrent クライアントだ。Web UI、Chrome 拡張、Docker イメージまで含めて、129 コミット。

そしてこのプロジェクトは、コードの実装をほぼ全て Claude Code（AI エージェント）に任せて完成させた。

何を作ったか#

stor が実装している主な仕様は以下の通り。

14 の BEP をカバーし、ダウンロードからシーディング、暗号化、DHT によるトラッカーレス通信まで一通り動く。Web UI は SvelteKit で Deluge 風のレイアウトを作り、Go バイナリに embed して単一バイナリで配布できるようにした。Docker イメージは distroless ベースで約 9 MB。

人間がやったこと#

コードを書いたのはほぼ全て Claude Code だが、人間（自分）の役割がなかったわけではない。自分がやったのは以下のようなことだ。

アーキテクチャの方向づけ#

最初のプロンプトでプロジェクトの大枠を伝えた。「Go でゼロ依存の BitTorrent クライアントを作る」「デーモンモードで動かして JSON-RPC で操作する」「Web UI は SvelteKit で embed する」といった設計判断は人間が行った。

レビューと品質管理#

実装がある程度進んだ段階で、こんなプロンプトを投げた。

goにおけるアンチパターンがないかコードを全部レビューして

Claude Code がコード全体を走査して問題点をリストアップしてくる。ただし AI のレビュー結果を鵜呑みにはしない。

HIGHのものが本当に起きているか詳細に確認して、パット見だけで言ってないか

「本当に起きるのか？」と突き返すと、誤検知が削ぎ落とされて本当の問題だけが残る。確認が取れたら修正を指示する。

対応して, TDD準拠 RED first

テスト駆動で直させる。この一連の流れ——レビュー → 精査 → TDD で修正——がセキュリティ強化のフェーズでは特に効いた。4/12 だけで 20 件以上のセキュリティ修正コミットが入っているが、SSRF、Path Traversal、DNS Rebinding、Integer Overflow、Race Condition といった脆弱性を体系的に潰せたのはこのプロセスのおかげだ。

デバッグの方向づけ#

実際に動かしてみると当然バグは出る。例えば DHT 周りではこんなやり取りがあった。

DHTノードがずっと0なんだけどそんなことある？
delugeのときは300くらいずっとあったんだけど

既存クライアント（Deluge）との比較で「何かがおかしい」と気づくのは人間の仕事だ。Claude Code は原因を調査して修正するが、「おかしい」と感じるセンサーは人間にしかない。

DHTノードの情報は再起動すると揮発する？

必須だなそれは

DHT ルーティングテーブルの永続化が必要だと判断したのも人間。「それは必要だ」という一言で実装が走る。

リリース管理#

意図ごとにcommit push

tag bumpして

docker image build push, ciに組み込みたいなこれ

コミットの粒度、バージョニング、CI/CD の構成も人間が指示した。

3.5 日の流れ#

振り返ると、開発は大まかに 4 つのフェーズに分かれていた。

Day 1（4/10）: コア実装#

bencode パーサー、ピアプロトコル、トラッカー通信、DHT の基本実装。同時に Web UI の骨格と Chrome 拡張も作った。この日だけで 50 コミット以上。デーモンモード、Docker 対応、日本語 README まで含めて一気に形にした。

Day 2（4/11）: 機能拡充#

BEP 6 (Fast Extension)、BEP 19 (WebSeed)、BEP 27 (Private Torrents)、BEP 52 (v2 Hybrid) を追加。uTP の統合、アップロード機能の実装もこの日。「動くもの」から「ちゃんと動くもの」への移行期間。

Day 3（4/12）: セキュリティ強化とリリース#

コード全体のレビューを実施。bencode の DoS 対策、トラッカーレスポンスのサイズ制限、SSRF 防止、Race Condition の修正など、セキュリティを体系的に強化した。goreleaser による自動リリース、Homebrew tap の設定もこの日。

Day 4（4/13）: 安定化#

DHT ルーティングテーブルの永続化、PEX の panic 修正、goroutine リークの修正、データ競合の解消。最後の磨き込み。

エージェント駆動開発で見えたこと#

プロンプトは短いほどいい#

振り返ると、効果的だったプロンプトはどれも短い。「対応して, TDD準拠 RED first」「必須だなそれは」「commit push tag bump」。コンテキストが共有されている状態では、長い説明は不要だった。

人間の仕事は「判断」と「検証」#

コードを書く速度では AI に勝てない。でも「何を作るか」「この品質で十分か」「これはおかしい」という判断は人間にしかできない。DHT ノードが 0 のままだと気づいたのは、Deluge での運用経験があったからだ。

レビューは二段階で#

AI にレビューさせると、実際には起きない問題も指摘してくる。「本当に起きるか確認して」と一度突き返すだけで精度が大幅に上がる。このフィルタリングは今後も使えるパターンだと思う。

セキュリティは AI の得意分野#

SSRF、Path Traversal、DNS Rebinding、Integer Overflow——こうした教科書的な脆弱性を網羅的にチェックするのは AI が圧倒的に得意だ。人間がひとつひとつ確認するのに比べて、漏れが少なく速い。

数字で見る stor#

おわりに#

3.5 日で BitTorrent クライアントが作れたのは、AI エージェントのおかげだ。ただし「AI が全部やってくれた」わけではない。アーキテクチャの設計、品質の判断、バグに気づくセンサー、リリースの意思決定——これらは全て人間の仕事だった。

AI エージェント駆動の開発は、人間の役割を「コードを書く人」から「プロダクトの方向を決める人」に変える。それは制約ではなく、レバレッジだと思う。

リポジトリ: skmtkytr/stor ↗