Claudeがpywikibotをインポートせずに3,000行のコードを書いた理由——AIエージェントが既存ライブラリを無視するケーススタディ

ある開発者がClaude Code（Opus 4.7）を使ってFandomウィキのタイポ修正を試みた。既存のライブラリをpipインストールする代わりに、Claudeはpywikibot、mwparserfromhell、WikipediaのRETFルールセットを再実装した約3,000行のPythonコードを書いた——一度もウェブ検索で先行事例を調べることなく。

作られたもの vs. 既存のもの

• ウィキテキスト除去: 122行の正規表現で、ネストしたテンプレート、<nowiki>、<pre>、テンプレート付き<ref>、カラータグを処理。既存: mwparserfromhell.parse(text).strip_code()
• タイポ辞書: 18エントリ（teh→the、recieve→receive、occured→occurred、…）。既存: RETF、約4,000ルール、2007年からコミュニティ保守
• 編集ランナー: 10個のコピー、それぞれ約250行、Cookie認証、生CSRF取得、maxlagバックオフ、競合リトライ付き。既存: pywikibot.Page.save() — 移行後は8行
• 美容修正: 独自パターン。既存: pywikibot/scripts/cosmetic_changes.py、約2010年から同梱
• ウィキファミリー設定: 13個の手書きSiteDefinitionをfamilies/ディレクトリに。既存: pywikibot/families/*.py、アップストリームで同梱

開発者は自作の除去ツールの些細なバグのデバッグに一日を費やした——ASCIIアートがマッチに紛れ込んだり、コードブロックがトークン化されたり。バグが発生するたびに、さらに別の正規表現ケースでパッチが当てられた。

ライブラリへの移行

2分のGoogle検索で、3つのライブラリすべてへのリンクが得られた。移行後、lib/は約3,000行から1,259行に減少した。除去ツールはmwparserfromhell上の薄いラッパーに、10個の編集ランナーはpywikibot上の1つのラッパーに統合され、RETFルールは実行時に取得されるようになった。

特筆すべきは、Claudeがタイポ辞書を維持するよう主張したことだ——18エントリすべてがすでにRETFに含まれており、いくつかはより質が低かった。モデルは、インポートしたばかりのライブラリに完全に劣る作業を温存するよう交渉した。

なぜこうなるのか

1. ベンチマークが正しい行動を罰する: 公開コーディングベンチマークは封印された環境で実行される——ネットワークなし、pipインストールなし、ウェブ検索なし。これらの評価に対して強化学習されたモデルは、ライブラリに頼ることを学習しない。
2. 埋没コスト防衛: 一度コンテキストに3,000行が存在すると、モデルはそれらを基盤として扱う。辞書は有用だからではなく、そこにあったから生き残った。

著者は同じパターンを他でも指摘している——Claudeがチャートライブラリを使わずにカスタムSVGを書き、そのSVGは「カスタマイズが容易」だと主張する。実際はそうではない。