まず、作ったものと結論
高専ロボコン2026「雑巾投擲」を題材に、Claude Code と OpenAI Codex を合計およそ19.5時間動かして、ブラウザ上で試合を再現できる3Dシミュレーターを作りました。
- 試合シミュレーター（ブラウザで即動く・インストール不要・スマホ可）
- ソースコード
最初の目的は「当時利用できた最上位クラスのモデルに全国優勝戦略を書かせたら、どこまで使える案が出るか」を試すことでした。
ところが、AIが書いた戦略書は、文章としては綺麗でも、実際の設計判断に使えるほど具体的ではありませんでした。一方で、AIにフィールドの viewer を作らせ、物理シミュレーションや自動計測を足していくと、AIコーディングの強みが一気に見えてきました。
今回いちばんの学びは、これです。
AIに正解を考えさせるより、AI自身が実装を動かし、結果を計測し、修正できる「環境」を作らせた方が圧倒的に強い。
この記事では、viewer が試合シミュレーターへ育っていく過程を通して、AIコーディングで特に効いた次の点を紹介します。
- AIに図面や競技ルールを正しく認識させる方法（PDFは画像で渡す）
- AI自身が結果を検証できるフィードバックループの作り方
- AIが高速に試行錯誤できる技術スタックの選び方
- AIに戦略を直接書かせるだけでは不十分だった理由
使ったモデルの整理
7月19日に NHK学生ロボコン2026 が放映されました。番組では、複数のチームが開発にAIを活用している様子も紹介されていました。それに触発されて、自分でもガッツリ回してみたのが今回の内容です。
用途ごとに使い分けたので、先に一覧化しておきます。
| 用途 | ツール | モデル |
|---|---|---|
| 初期実装（土台づくり） | Claude Code | Fable 5 |
| 改修・経路追従の最適化 | Claude Code | Opus 4.8 |
| 使用制限に当たってからの実装 | Codex | GPT-5.5 xhigh |
途中で Claude の使用制限に当たったため、後半の一部は Codex（GPT-5.5 xhigh）へ切り替えて実装を続けました。「最強AI」というのはキャッチーな言い方で、正確には当時利用できた高性能モデル、という意味です。
最初は「全国優勝戦略書」を書かせたが、使えなかった
最初は、ルールとフィールドのPDFを渡して「この競技で全国優勝する戦略をまとめて」とやっていました。
もちろん、AIはそれっぽいことを言います。得点効率、リスク管理、優先順位、機構案、試合展開――文章としてはかなり綺麗にまとめてくれます。
でも、ロボコン経験者の目線だと、それだけでは実際の意思決定にほとんど使えませんでした。
ロボコンで本当に難しいのは「綺麗な戦略を考えること」ではなく、その戦略を成立させる機構を作り切ることだからです。この競技で勝とうとすると、結局効いてくるのは次の方です。
- 射出の機構的な精度／制御精度
- 装填・位置合わせ・再現性
- 試合中に失敗したときの復帰性
- 完成度8割のものを10割へ詰める、泥臭い作業
この泥臭い部分を、AIにただ文章で考えさせても意味がないと感じました。
だから方針を変えました。AIに「すごい答え」を文章で出させるより、答えを検証できる環境をコードで作らせる。ここからがAIコーディングの本番でした。
viewer が試合シミュレーターに変わった
最初はフィールドを見るだけの viewer のつもりでしたが、段階的に検証環境へ育っていきました。
- 最初はフィールドを3D表示するだけの viewer だった
- 「雑巾が放物線を描いて飛ぶアニメーション」が一発で追加された
- ロボット・射出条件・カメラ（マルチカム／クレーン／選手視点）を足した
- 物理エンジン Rapier を使った検証環境を追加した
- ブラウザ表示と、ヘッドレス（画面なし）実行を分離した
- AIが自分で実行・計測できるようになった
この順番で見ると、単なる機能紹介ではなく、検証環境が段階的に育ったストーリーになります。「国技館っぽい座席を作って」「選手視点で動かせるようにして」と、細かい指示を数十件レベルで出しました。こだわりが強すぎたのは反省点です。
この過程で強く感じたのは、Web（Three.js）と生成AIの相性の良さです。ブラウザ上で動く3D viewer は、AIにとってかなり扱いやすい。ホットリロードで即座に見た目が反映され、型チェックでミスが早期に潰れ、URL 1本で共有でき、ヘッドレスで自動実行までできる。この「AIが速く回せる土俵」を選ぶこと自体が、成果物の質を決めると感じました。
なお完成物は、ブラウザ上でフィールドを3D表示し、ロボットの経路・雑巾の射出・得点状況を時系列で再生できます。射出条件や戦略を切り替え、マルチカム・クレーンカメラ・選手視点から確認できます。
雑巾の飛び方を「物理」で試せるようにした
検証環境の一つとして、雑巾の飛び方を物理エンジン（Rapier）で試せるヘッドレスsimも作らせました。私は雑巾を実際に投げたことがなく挙動が分からなかったので、「AIに物理を試せる環境を作らせて、数値で確かめる」ためのものです。
ここでAIは、雑巾を「1枚の薄いシート」ではなく質点をばねで結んだ布として扱い、雑巾の飛び方を決め打ちのアニメーションとして実装するのではなく、質点・ばね・減衰・空気抵抗の相互作用から、ばたつき・タンブリング・滑空といった挙動が生じるモデルを構築しました。物理エンジンに Rapier を選んだのは「JSで動く物理ライブラリを探したら出てきたから」くらいの理由でしたが、想像よりはるかに深いところまで行けたのは素直に感心しました。
補足：このモデルも、質量・ばね定数・減衰・空気抵抗・接触摩擦・雑巾の寸法といったパラメータに依存しています。「パラメータではなく物理から創発」というのは言い過ぎで、正確には「決め打ちアニメではなく、少数の物理パラメータの相互作用から挙動が出るモデル」です。さらに重要な注意として、実物の雑巾を使ったパラメータ同定や実験との比較はまだ行っていないため、このシミュレーターは実機の軌道を高精度に予測するものではありません。現時点では、条件比較や実装検証のための環境として使っています。
AIに競技を理解させる入力設計（PDFは画像で渡す）
AIコーディングを進める中で、地味だけど重要だったのが、AIへの資料の渡し方です。
PDFから抽出された文字情報だけでは、競技フィールドの図面や寸法の関係までは正しく理解できないだろう、とは思っていました。ただ、最新のAIなら「この情報だけでは図面を理解できていない」と自分で判断し、PDFのページを画像として確認するなど、必要な手段に自律的に切り替えてくれるのではないかと期待していました。
しかし、今回使用したコーディングエージェントでは、そうなりませんでした。AIは、PDFをテキスト化した、構造の崩れたMarkdownをそのまま読み続けており、フィールドの形状や物体の配置、寸法同士の関係をほとんど理解できていませんでした。こちらは「PDFを読ませた」つもりでも、AIは人間のように図面を見ていたわけではありません。
テキスト抽出だけで起きた誤り
- フィールド外形の縦横比を取り違えた
- オブジェクトの左右関係を間違えた
- 寸法線の数字を別の部材の寸法として解釈した
- 図と注釈の対応関係を失った
ページを画像として渡した後
- フィールド形状を正しく修正できた
- 寸法の基準点を認識できた
- 物体の配置関係が修正され、シミュレーターの修正も一気に進んだ
ロボコンのルールでは、文章だけでなく、図面や物体の配置、寸法の関係が極めて重要です。今回の環境では、図面は最初から画像として渡し、視覚情報として認識させる必要がありました。ここは「PDFを渡せばAIが競技を理解する」という思い込みが、はっきり崩れたポイントでした。
AI自身が検証できるループを作った
今回いちばん強く感じた学びです。自律性のあるAIを活かす鍵は、賢いAIに命令すること自体ではなく、AIが自分の出力を検証できる仕組みを作ることでした。
文章で「この戦略は強い？」と聞いても、返ってくるのは文章です。でも viewer やヘッドレスsimを作らせると、
- 「この角度だと届かない」
- 「この初速なら入りそう」
- 「この機構はこっちに大きくバラつく」
という数値のフィードバックが返るようになります。ここで初めて、AIは「それっぽいことを言う相手」から「検証しながら詰める相棒」に変わりました。
具体的には、経路追従の調整を次のループで詰めました。
1. コーディングエージェントが経路追従アルゴリズムを修正
2. ヘッドレスsimを worker_threads で並列実行
3. パラメータを多数通り掃引し、最大横偏差・到達時間・オーバーシュートを計測
4. 結果を JSON へ保存
5. エージェントが JSON を読み、上位条件の共通点を分析
6. その分析をもとに再度アルゴリズムを修正
ポイントは、AIが実装するだけでなく、AI自身が回して数値で確かめるところです。このループを回すのに効いたプロンプトの型は、たとえば次のようなものでした。
この変更が正しいと仮定せず、実装後にヘッドレスシミュレーターを実行してください。
横方向の最大偏差・到達時間・最終姿勢の誤差を計測し、変更前と比較してください。
改善していない場合は、原因を分析して再実装してください。
「この変更は正しいと仮定するな、走らせて数値で示せ」と縛るだけで、成功を装う報告が減り、実際に計測された数値ベースで会話できるようになりました。
補足：改善前後の定量値（横偏差やタイムが何mm・何秒縮んだか）は、実物との較正を経ていない現時点では「実機の予測」として出せる段階になく、この記事では意図的に断定を避けています。ここは今後、実機ログとの比較で埋めていきたい部分です。
図にするとこういうループです。
この「実装 → 並列で回す → 計測 → 掃引 → AIが読んで直す」を閉じられるかどうかが、自律AIを「使える」かの分かれ目だと感じました。AIコーディングで一番投資すべきは、賢いモデルを選ぶことより、この検証ループを先に用意することです。
なぜWebスタックが効いたか
スタック選定の軸は一貫していました。「AIが速く回せて、すぐ見られて、すぐ共有できる」ことです。
- Vite + Svelte 5 + TypeScript(strict)：軽くて速い。型チェック（
svelte-check）でAIのミスを早期に潰せる。 - Three.js：ブラウザで3D。今回の開発では相性が良く、「見せられる」絵がすぐ出る。
- Rapier（物理）：JSで動く物理エンジン。ブラウザ/Nodeの両方で同じコードが回るので、検証simをそのままヘッドレス化できる。
- worker_threads：ヘッドレスsimを並列で回し、パラメータ掃引を現実的な時間で。
- Cloudflare Pages：URL 1本で誰でも触れて、短時間でデプロイできる。
構成をざっくり描くとこうです。ブラウザとヘッドレスで同じシミュレーションコアを共有しているのが肝です。
重厚なフレームワークより、反復速度と共有性を最優先しました。AIコーディングでは、モデルが1周する時間が短いほど検証ループが速く回るので、ここが効きます。
かかった時間とコスト
注意：以下はログをAPI単価で換算した参考値であり、実際の請求額そのものではありません。サブスクリプション利用分を公開API単価に当てはめて計算しています。総トークン約8.7億のうち大半は「cache 読み」で、これは過去の文脈を毎ターン読み直すために積み上がった分です。
Claude Code
| モデル | 単価(入/出) | 応答 | 出力tok | cache読tok | コスト |
|---|---|---|---|---|---|
| opus-4-8 | $5 / $25 | 1,476 | 2.22M | 684M | $428.5 |
| fable-5 | $10 / $50 | 377 | 0.78M | 174M | $287.7 |
- 総トークン 約8.7億（大半は cache 読み 858M）／ コスト ≈ $716
Codex（GPT-5.5）
- 入力 49.4M（うち cache 46.8M）／ 出力 0.25M ／ コスト ≈ $44
合計
- API換算コスト ≈ \$761（Claude \$716 + Codex $44）
- 実作業 ≈ 19.5h（実質2日）
意外だったのは、コストの大半が「cache読み」だったことです。長時間・大コンテキストのセッションを何度も回すと、過去の文脈を毎ターン読み直すのでこうなります。反省点として、1セッションを長くしすぎました。用途ごとにセッションを切り、文脈を持ち込みすぎないだけでも、この換算コストはかなり下げられたはずです。「AIに長く付き合わせるほど、出力より文脈の再読で効いてくる」というのは、実際に回してみないと分からない感覚でした。
限界と今後
- 雑巾モデルは未較正です。実物での同定・実験との比較をしていないため、実機の軌道を高精度に予測するものではありません。
- したがって、このsimが戦略の強さを保証するものではありません。あくまで条件比較・実装検証のための環境です。
- sim-to-real ギャップ（綺麗なsimが実機と合わない問題）が最大のリスクです。使うなら実機ログで較正する前提です。
ロボコン開発：Webベース vs ROS2
AIコーディングの話からは少し外れますが、今回の手応えとして書いておきます。結論は「どちらか一方」ではなく併用が最適、です。今回のWeb開発は ROS2 の置き換えではなく、ROS2 に無い層（戦略sim・可視化・共有）を埋めるものでした。
- Webが効いた所：反復が速い（Viteビルドは秒オーダー、Cloudflare Pages で短時間デプロイ）／Three.jsで「見せられる」絵が出る／URL 1本で無摩擦に共有できる／pure TS でsimが完結し、ハード無しで大量試行できる。AIコーディングと相性が良いのはこの層です。
- ROS2が要る所：実機のドライバ・リアルタイム制御・センサ統合。ここはWebでは代替できません。
- 最大のリスク：sim-to-real ギャップ。綺麗なsimが実機と合わないのが罠で、使うなら実機ログで較正する前提が要ります。
要は「ROS2から乗り換える」ではなく、実機制御は ROS2、戦略検証・可視化・共有は Web、という役割分担が今回は適していました。将来的には、実機ログやROS2トピックを Web シミュレーターへ rosbridge で接続し、シミュレーションと実機の差を較正する構成を考えています。ROS2 ＋ Web可視化/戦略sim を繋ぐのが、今回の手応え的にはいちばん伸びる形だと思います。
まとめ
最初は最上位クラスのモデルに「全国優勝戦略」を書かせるつもりでした。でもやってみると、戦略書は実際の意思決定に使えるほど具体的ではありませんでした。面白かったのは、AIに viewer を作らせ、それを少しずつ拡張して試合シミュレーターにしていく過程と、AI自身がそれを回して数値で確かめられるようにしたところです。
持ち帰りたい学びは3つです。
- AIに図面を理解させるには、テキストだけでなく視覚情報（ページ画像）を渡す。
- AIには実装だけでなく、実行・計測・改善まで行わせる。
- 技術スタックは、AIの反復速度を基準に選ぶ。
最後に一度だけ。
AIコーディングで重要なのは、最も賢いモデルを選ぶことではなく、モデルが間違いを発見できる環境を作ることだった。
高専ロボコン2026 試合シミュレーター
ソースコード