2026-04-26

ポケモン用ツールをAIに丸投げしたら時間とトークンが溶けた — 学んだ"任せ方"の順番

ポケモンチャンピオンズ向けに、ダメージ計算ツールを個人開発で作っている。

最初は全部AIに任せようと思った。仕様も、データも、実装も。何でもできる時代だし、ポケモンの知識をAIが知らないわけがない、と思っていた。

ロジック面はサンプルデータで進めていたので、序盤はそんなに困らなかった。問題はその先、実際のポケモンデータを作るフェーズに入ったときだった。ここで時間とトークンを溶かした。

何が起きたか

具体的には2つあった。

開発を始めた当初、ポケモンチャンピオンズはまだ正式リリース前で、Webにある情報は限られていた。AIにレギュレーションを聞くと、SVのレギュレーションIをベースにした答えが返ってくる。

最初はそれでいいと思っていた。チャンピオンズも似たようなものだろう、と。

ところがチャンピオンズは個体値が廃止されている。能力ポイント制（旧努力値とは別物）になり、上限値も違う。

なのに「ダメージ計算機能を作って」と頼むと、AIはSV準拠のロジックを書いてくる。何度修正しても、別のファイルでまたSV準拠のロジックを書き直してくる。チャンピオンズには存在しないルールで計算する処理が、気づくと紛れ込んでいた。

「AIは最新の情報も知っているはず」という思い込みが、ここで初めて崩れた。

これが一番イラっとした。

このプロジェクトはポケモンのデータを PokeAPI から取得している。PokeAPIは英語が前提なので、DBには英語と日本語の両方を持たせる構成にしていた。

ところがAIにデータ取り込み処理を触らせていると、いつの間にか日本語のフィールドに英語が入っていたり、フォルム違いのポケモンなのに日本語名が同じになっていたり、使うはずの画像が全然違うポケモンのものに差し替わっていたりした。

完全にデータが壊れているわけじゃない。動いてしまう。でも中身が間違っている。動くけど一部間違っている、テストで検出しづらいタイプのデグレだった。

完全に壊れていた方が、まだ気づきやすかったと思う。

そして、これらを毎回手作業で訂正していくとトークンがどんどん減っていく。AIで効率化してるはずが、AIに振り回されて時間が増える、本末転倒な状態だった。

ある時点で気づいた。

AIは万能じゃない。特に 最新の仕様や、自分のプロジェクト固有のルール は知らない。学習データのカットオフがあるし、自分の作っているものの独自制約は学習データに存在しない。

「AIに丸投げしたら作れる」のは、AIが既に知っている領域の話だった。CIのYAML、UIのコンポーネント、汎用的なロジック。これらは丸投げできる。

でも「ポケモンチャンピオンズの能力ポイント制」みたいに、AIが知らない領域は丸投げできない。自分が知識を渡してから、初めて任せられる。

順番が逆だった。

やり方を変えた。

仕様を文章にしてAIに渡す。具体的には、Claude Code の skill としてまとめた。「ポケモンチャンピオンズの能力値計算式」「個体値は廃止」「能力ポイントは合計上限66、1ステータス上限32」といった仕様を、skill 化してプロジェクトに置いておく。

skill にしておくと、関連する作業に入ったときAIが自動でその知識を読みに行く。CLAUDE.md に全部書く方法もあるけど、量が増えるとノイズになるので、ドメイン知識は skill として切り出す方が相性がよかった。

これで「同じ間違いを繰り返す」が大きく減った。手戻りが減って、トークンも保つようになった。

合わせて、設計フェーズも変えた。いきなり実装させず、仕様説明 → AIと壁打ち → 一緒に設計を固める → 実装 の順番に。

壁打ちの段階で「ここ伝え忘れてた」「ここの例外処理どうしよう」が出てくる。実装に入ってからの手戻りより、設計段階での手戻りの方が遥かに安い。

整理するとこうなった。

AIに任せている：

自分でやっている：

判断基準はシンプル。「ポケモン特有の知識が必要かどうか」。必要ない領域はAIに任せる。必要な領域は、まず自分が知識を整えてから渡す。

順番を間違えると時間とトークンが溶ける、という話だった。

「AIで何でも作れる時代」と言われるけど、正確には「AIが知っている領域なら何でも作れる時代」だと思う。自分の好きな領域、自分の作りたいものに固有のルールは、自分が知識を整えてからAIに渡す必要がある。

逆に言えば、その手間さえかければ、好きなものを作る速度はずっと上がる。

自分の好きな領域でツールを作りたいなら、まずその領域の知識を整理することから始めるといい。AIへの丸投げは、その後でいい。