13道県、1,294拠点、2,121学科。AI のサブエージェントを約120本走らせて、この規模の学校データ整備が2日で終わりました。
個人開発している「まなびマップ」（親子で使う学校選びの地図ノート、https://manabi-map.app ）の全国展開の一環です。群馬から始めて関東1都6県まで来ていたので、次は東日本を全部。北陸・甲信越・東北・北海道の13道県をまとめて仕込むことにしました。
Claude Code のマルチエージェント運用、サブエージェントの並列指揮、データ収集の品質管理あたりに興味がある人向けの振り返りです。
人間は1人、手はAI。役割分担をどう切ったか
前提として、作業者は自分1人です。手を動かすのは全部 AI エージェント。ただし1つの巨大なセッションに全部やらせるのではなく、モデルの得意で役割を切りました。
- 指揮者: 全体の整合・派遣・検収判断・計画の更新。一番賢いモデルを1本だけ
- 調査・SQL生成: Web から公的資料を集めて構造化する数の勝負。中位モデルを大量に並列
- 機械検査: grep と件数照合だけの決定的なチェック。一番安いモデルで十分
- 偏差値推計: 公的資料の適格性判断が要る繊細な仕事。ここは上位モデル
上の図のとおり、指揮1本の下に「調査は数で、検査は安く、推計は賢く」という配役です。全部を最上位モデルでやると財布が死に、全部を安いモデルでやると品質が死ぬ。仕事の性質ごとにモデルを変えるのが、コストと品質の両立点でした。
進め方は「波」で区切りました。小さい地方（北陸3県、約150校）で手順を検証してから、甲信越、東北、最後に最大の北海道（約300校）へ。県の中はさらに30〜50校のブロックに割って、1ブロック1エージェントで同時に走らせます。研究フェーズで13道県の学校リストを一斉に作ったときは、13本を1メッセージで同時に投げました。
1つの県ができあがるまでの流れ
県単位のパイプラインは4段です。
- マスターリスト作成。県教委の学校一覧から全校を確定
- ブロック並列調査。各校の公式サイトから学科・課程・所在地を集めて SQL 断片に
- 統合と機械検査。断片を1本に結合し、校数照合・重複・座標範囲など8項目を別エージェントが独立チェック
- 偏差値推計と入試実績の収集。ここが実は最終検収を兼ねる
図にすると単純な直列ですが、効いたのは4段目の「兼ねる」の部分でした。偏差値や入試実績は県教委の学科別資料と突き合わせて作るので、学校データ側に穴があると、ここで必ず引っかかる。つまり収集フェーズがそのまま検収フェーズになる。この構造は狙って作ったというより、回してみて「これは検収として機能してるな」と気づいた類のものです。
規律として最初から決めていたのは1つだけ。データソースは公的資料と学校公式サイトのみ、商用の偏差値サイトは検索結果に出ても開かない。これを全エージェントのプロンプト冒頭に非交渉事項として書き、統合時 grep、独立検査、最後の横断 grep と、合計4重でチェックしました。結果、120本の成果物すべてで商用サイト参照ゼロ。プロンプトに書くだけでは不安ですが、機械検査を重ねれば規律は守り切れます。
パイプラインが勝手にミスを見つけ始めた
面白かったのはここからです。走らせているうちに、エージェント同士が互いのミスを拾い始めました。
富山では、ブロック分担の境界にいた私立高校が1校、どのエージェントの担当にも入らず消えました。これは統合時の「マスターリストと校数照合」で発覚。以降は全エージェントに「担当外と判断して除外した学校は必ず校名を報告せよ」というルールを足して、同じ欠落を長野でも検出できました。
新潟では、入試実績を集めていたエージェントが「統合先の新設校が学校データに存在しない」と報告してきました。調べると2026年4月開校の統合校で、元のリスト作成時点では見落とされていたもの。宮城では市立高校が1校丸ごと抜けていたのを、偏差値担当が県資料との突合で発見しています。
福島では県立と私立に同名の高校があり、名前で参照する SQL が壊れる構造になっていました。これは生成段階のエージェントが自分で気づいて、私立側を法人正式名称で収録して回避。
並べてみると、欠落や衝突がパイプラインのどの段で捕まったかがそれぞれ違います。単一のチェックリストで全部防いだのではなく、独立した工程が別の角度から同じデータを見ることで、網の目が細かくなっていた。多段パイプラインの副産物として、これは想定以上でした。
途中で方針を変えた話
順調な話ばかりでもなくて、途中で設計を1つひっくり返しています。
偏差値です。まなびマップの偏差値は商用サイト転載ではなく、公的資料からの独自推計なのですが、北陸3県を終えた時点で嫌な傾向が出ました。この地方は学校別の試験平均点を公表していないため、志願倍率ベースの参考推計しか作れない。すると定員割れの学科が軒並み推計下限の同じ値に張り付く。225件中175件が同じ数字。これを地図に出したら、誤解を招くだけです。
正直、参った。で、相談の結果、発想を変えました。推計をがんばるのをやめて、「募集人数・志願者数・受検者数・合格者数」という公表された事実そのものを3年分持つテーブルを新設する。数字を作らず、事実を並べる。倍率の推移は保護者にとって偏差値より実用的なことも多い。
この方針転換で収集対象は一気に増えましたが、パイプラインは同じ形のまま回せたので、最終的に21都道県×3年分で7,746件の入試実績が揃いました。設計の手戻りというより、走りながらの軌道修正として一番大きい判断でした。
つまずきも普通にあった
きれいに回った話に見えるかもしれませんが、指揮側のミスもありました。
一番恥ずかしいのは、エージェントの派遣数を「報告書の要約値」で決めてしまったこと。実際の分割案はファイルに6ブロックと書いてあったのに、要約の「3」を信じて3本しか出さず、最初の完了報告で校数が全然足りないことに気づきました。以降は派遣前に必ず元ファイルの該当節を直接読む。伝聞で指揮しない。当たり前のことに1回転んでから気づきました。
あとは利用上限。20本超を並列で走らせ続けたら、途中で時間あたりのクォータを使い切り、15本が同時に止まりました。ただ、成果物を「同じ入力なら同じ出力になる冪等な形」で書かせていたので、リセット後に同じ指示を投げ直すだけで無傷で復旧。並列の規模より、失敗しても投げ直せる設計のほうが大事だと実感しました。
で、いくらかかったのか
裏側の数字も置いておきます。
上のとおり、指揮役のセッション単体で、ツールのコスト集計は 891 ドル相当と表示されていました。定額プランの範囲内なので実際にこの金額を払ったわけではないのですが、API の従量課金に換算するとこの規模の仕事だった、という目安にはなります。安いモデルに数を任せて、賢いモデルを指揮と難所に絞っても、この数字。全部を最上位モデルでやっていたらと思うと、ちょっと怖い。
もう1つはコンテキストです。親セッションは 1M トークンの窓の 80% まで膨らみました。サブエージェントの調査の中身は親に戻さず「完了・変更ファイル・検証1行」だけ返す設計にしていたのに、120本ぶんの完了報告を受け続けるとここまで来ます。サブエージェント側の消費を足し合わせると、ログの概算で 2,000 万トークンを超えていました。2日で終わったのは、正直、窓の残量との競争でもありました。
学んだこと
- モデルの配役はコスト設計そのもの。調査は数、検査は安く、判断は賢く、で役割を切ると規模が出せる
- 品質は「プロンプトのお願い」ではなく「独立した機械検査の重ね掛け」で守る。grep できるルールは全部 grep する
- 多段パイプラインは検収装置になる。後工程が別ソースで同じデータに触る設計だと、ミスが勝手に浮く
- 冪等な成果物は並列運用の保険。中断は起きるものとして、投げ直せる形で書かせる
データは揃いましたが、本番投入とアプリ側の対応はこれから。西日本はこの倍の規模があるので、今回の手順書をそのまま持っていけるかは、またやってみてから書きます。
小さく。1県ずつ。地図はまだ半分です。
※ ヘッダー画像とインフォグラフィックは AI（画像生成）で作成しています。
書いた人: ishizakahiroshi
群馬の北部で、保護猫2匹と暮らす、在宅エンジニア（何でも屋）
https://ishizakahiroshi.github.io/
https://github.com/ishizakahiroshi
X（業務委託・各種相談はこちら）：
https://x.com/ishizakahiroshi
バックエンド・インフラ・AI連携まわりで、業務委託のご相談を受け付けています。フルリモートです。スポットや週2〜3時間からでも歓迎で、いろんな案件に携われたらうれしいです。こんな相談、歓迎です。