mendoi-apps

ゼロイチから地方大会優勝を狙うロボコンレース戦略設計

ロボコンレースで初心者チームが勝つために、最初に狙うべきものは「最高速度」ではありません。

読書機能の使い方

聴く：本文を読み上げます。速読：語句を順に表示し、速さを調整できます。語学練習：別の言語版と対訳を読み比べます。保存：このブラウザーにブックマークし、プレイヤーの保存済み一覧から開けます。

この記事をシェア

この記事をシェア

LINEで共有（新しいタブで開きます）Xで共有（新しいタブで開きます）

広告
広告

初心者チームが「速いけど死ぬロボット」ではなく「ばらついても勝てるロボット」を作るための、設計思想・計測・改善・チーム運用・Pythonコード実例

この記事の結論

ロボコンレースで初心者チームが勝つために、最初に狙うべきものは「最高速度」ではありません。

最初に狙うべきものは、完走率です。

1回だけ速いロボットは、地方大会では見栄えがいいかもしれません。
でも本番で1回でもコースアウトしたら終わります。
センサーが一瞬暴れた、タイヤが少し滑った、床が汚れていた、電池電圧が少し落ちていた、スタート角度が2度ずれていた。
その程度で死ぬロボットは、理論上は速くても、試合では弱いです。

この記事で採用する基本方針は、これです。

採用基準：
1. 完走率が一番高いもの
2. ワーストケースでも死なないもの
3. その中で速いもの
4. タイムのばらつきが小さいもの

言い換えると、こうです。

速いロボットを作る前に、死なないロボットを作る。
死なないロボットができた後で、少しずつ速くする。
ロボコンは、速度勝負に見えて、実際はばらつき管理ゲーである。

これがこの記事の中心です。

第1章：ロボコンは「平均タイム」ではなく「本番で死なない確率」を競う

初心者チームがやりがちな失敗は、1回の試走タイムで判断することです。

たとえば、次の2台があったとします。

機体 平均タイム 完走率 失敗内容
A 7.8秒 70% 右カーブで3回に1回コースアウト
B 9.2秒 100% ほぼ毎回同じ動きで完走

予選や決勝が1回勝負に近い場合、強いのはBです。
Aは理論値では速いですが、本番で死ぬ可能性が高い。
Bは少し遅いですが、まず確実に帰ってくる。

ロボコンレースでは、「平均で速い」よりも「最悪でも死なない」の方が重要です。

本番で必要なのは、これです。

見るべき指標：
- 完走率
- 失敗率
- 失敗地点
- ワーストケースタイム
- タイムの標準偏差
- 電池残量別のタイム差
- タイヤ摩耗後のズレ
- 初期位置ズレへの強さ

最初から「最速」を狙うと、だいたい失敗します。
理由は、現実のロボットは毎回同じ動きをしないからです。

第2章：宇宙船の着陸で考えると、補正しない設計は普通に死ぬ

ロボコンの自律走行を、宇宙船の月面着陸で考えると分かりやすいです。

月へ向かう軌道を計算したとします。
この角度で飛び出して、このタイミングで減速して、この場所に着陸すればよい。
シミュレーション上は成功です。

でも、実際の着陸地点に岩があったらどうでしょうか。
クレーターがあったらどうでしょうか。
傾斜があったらどうでしょうか。

「理論通りだからそのまま降ります」と言って突っ込んだら、普通に死にます。

ロボコンも同じです。

事前計画：
この距離を進む
この角度で曲がる
この速度で走る

現実：
床が滑る
タイヤが摩耗する
電池電圧が落ちる
センサー値が揺れる
スタート角度がズレる
障害物との距離が微妙に違う

だから、強いロボットは「理論通りに動く前提」では作りません。

強いロボットは、理論からズレる前提で作ります。

強い設計：
1. 目標ルートを持つ
2. 現在のズレを測る
3. ズレたら補正する
4. 危険なら減速する
5. 無理なら停止・復帰する

これが、この記事でいう「目標動作＋補正」です。

第3章：オープンループとクローズドループ

専門用語を入れると、ここはこうです。

オープンループ制御

オープンループ制御とは、センサーで結果を見ずに、決め打ちで動かす方法です。

3秒前進
0.8秒右旋回
2秒前進
停止

これは作るのが簡単です。
でも、床や電池やタイヤが変わると一気に弱くなります。

クローズドループ制御

クローズドループ制御とは、センサーで状態を見ながら補正する方法です。

壁との距離を見る
ラインからのズレを見る
ジャイロで角度を見る
エンコーダで移動量を見る
ズレたら補正する

本気で勝ちたいなら、基本はクローズドループです。

ただし、完全に高度なロボットを最初から作る必要はありません。
初心者チームでも、次のような補正なら十分に実装できます。

- 右に寄ったら左へ戻す
- 壁に近づきすぎたら離れる
- カーブ前だけ減速する
- 角度がズレたらジャイロで戻す
- 一定時間ゴールできなければ停止する

重要なのは、最初から完璧なAIロボットを作ることではありません。
ズレを測る基準を持つことです。

第4章：採用基準をチームで最初に決める

ロボコンチームが壊れる原因は、技術不足だけではありません。

判断基準がないまま、全員が別々のことを言い始めることです。

「もっと速くしよう」
「いや、安定させよう」
「見た目を直したい」
「センサー増やそう」
「コード全部書き換えよう」
「とりあえず走らせよう」

これをやると、チームが感覚会議になります。
口が悪く言えば、猿会議です。

だから、最初に採用基準を固定します。

採用基準：
1. 完走率
2. ワーストケース
3. ばらつき
4. 平均タイム

チームに説明する台本は、これでいいです。

今日はまず、最速のロボットを作る前に、死なないロボットを作る方針で進めたいです。

理由は、本番では1回だけ速い機体より、何回走っても完走する機体の方が強いからです。

採用基準は、
1. 完走率
2. ワーストケース
3. タイムのばらつき
4. 平均タイム
の順番にします。

まずはコースを分解して、
どこで失敗しそうか、
何を測るべきか、
誰がどのデータを見るかを決めたいです。

この進め方でよさそうですか？
他に先に確認したいルールや制約はありますか？

ポイントは、押し付けではなく、判断基準をチームの共通言語にすることです。

第5章：まずコースを分解する

コースが決まっているなら、まずコースを区間に分けます。

たとえば2m×3mのコースなら、次のように分解します。

区間A：スタート直後
区間B：第1直線
区間C：第1カーブ
区間D：障害物前
区間E：障害物回避
区間F：第2直線
区間G：ゴール前

各区間について、次を考えます。

区間 目的 失敗しそうなこと 見るデータ
スタート直後 まっすぐ出る 初期角度ズレ スタート位置、角度
第1直線 速度を出す 左右に寄る 左右ズレ、壁距離
第1カーブ 曲がる 外側に膨らむ カーブ後の位置
障害物前 減速・判断 衝突 距離センサー
障害物回避 安全に抜ける 近づきすぎ 最短距離
ゴール前 安定して入る 最後にズレる ゴール到達位置

この分解をせずにコードを書くと、どこで死んでいるか分からなくなります。

第6章：何を測るべきか

ロボコンで勝つためには、感想ではなくログが必要です。

「なんか曲がらない」では改善できません。
「第1カーブ後に右へ平均7cmズレる」なら改善できます。

見るべきデータは、次です。

1. 成功/失敗

最重要です。

成功：ゴールまで到達した
失敗：コースアウト、衝突、停止、タイムアウト

まず、完走率を出します。

完走率 = 成功回数 ÷ 試走回数

2. タイム

平均タイムだけではなく、悪い時のタイムを見ます。

平均タイム
最速タイム
最遅タイム
ワースト5%タイム
標準偏差

3. 失敗地点

失敗した場所を必ず記録します。

第1カーブ
障害物前
ゴール前
スタート直後
不明

失敗地点が集中している場所が、最優先改善ポイントです。

4. 電池電圧

電池残量で動きが変わるなら、本番で再現しません。

100%時
80%時
60%時

同じ動作を試します。

5. タイヤ状態

タイヤは摩耗します。
摩耗すると半径やグリップが変わり、移動距離や曲がりが変わります。

新品
10回走行後
30回走行後
交換前

状態を記録します。

6. 床状態

床の摩擦、汚れ、傾きは地味に効きます。

床A
床B
汚れあり
清掃後
本番想定床

場所を変えて試走すると、環境依存が見えます。

7. センサー値

センサーは信じすぎてはいけません。
センサー値にはノイズがあります。

距離センサー
ラインセンサー
ジャイロ角度
エンコーダ値

最低限、試走時に主要値をログに残します。

第7章：試走ログテンプレート

ExcelやGoogleスプレッドシートで、次の列を作ります。

試走番号 日時 設定名 成功/失敗 タイム 失敗地点 失敗内容 電池電圧 タイヤ状態 床状態 変更点 メモ
1 6/3 18:00 base_v1 成功 9.20 - - 8.1 新品 通常 基準 まっすぐ
2 6/3 18:03 base_v1 失敗 - 第1カーブ 外側接触 8.0 新品 通常 基準 カーブ後右ズレ
3 6/3 18:06 curve_slow_v1 成功 9.80 - - 8.0 新品 通常 カーブ前減速 安定

重要なのは、変更点を残すことです。

変更点が分からないログは、後で使えません。

悪い例：
なんか良くなった

良い例：
第1カーブ前で速度を0.8→0.6に変更
turn_gainを3.0→3.5に変更
右タイヤを新品に交換
距離センサーの閾値を18cm→22cmに変更

第8章：改善は1回につき1変数

初心者チームがやりがちな失敗は、一気にいろいろ直すことです。

速度を変える
センサー位置を変える
タイヤを変える
コードを書き換える
重心も変える

これを同時にやると、何が効いたか分かりません。

改善のルールはこれです。

1回の改善で変えるのは1つだけ。
変えたら10〜20回走らせる。
改善前後で比較する。
良くなったら採用。
悪くなったら戻す。

これだけでチームの改善速度が上がります。

改善判断表

データの出方 疑う原因 改善案
毎回同じ方向にズレる 左右タイヤ差、モーター差、初期角度 オフセット補正、タイヤ交換
たまに大きくズレる センサーノイズ、床汚れ、滑り フィルタ、減速、安全マージン
電池が減ると遅い 電圧依存 電圧補正、満充電運用
カーブだけ失敗 速度、曲率、重心 カーブ前減速、弧の半径変更
最後だけズレる 累積誤差 壁・ライン・マーカーで再補正
障害物付近で死ぬ 距離認識不足 センサー閾値変更、速度低下
走るたびにタイムが散る 制御が不安定 PID調整、速度低下、機体剛性確認

第9章：専門用語をロボコン用に翻訳する

専門用語は、賢そうに見せるために使うものではありません。
チーム内で同じ現象を同じ言葉で扱うために使います。

モンテカルロ法

一言でいうと、現実のばらつきをランダムに入れて、何百回・何千回も仮想レースする方法です。

ロボコンでは、次をランダムに変えます。

タイヤ摩耗
床の滑り
電池電圧
センサーノイズ
スタート位置
左右モーター差

そして、どの設定が一番死ににくいかを見ます。

標準偏差

一言でいうと、ばらつきの大きさです。

平均タイムが速くても、標準偏差が大きいと本番で不安定です。

平均9.0秒、標準偏差0.1秒 → 安定
平均8.5秒、標準偏差1.5秒 → 速いけど怖い

ワーストケース

一言でいうと、悪い時にどれくらい悪いかです。

ロボコンでは平均より大事です。

パーセンタイル

たとえば95パーセンタイルタイムは、悪い方から見てもだいたいこの範囲に収まるタイムです。

平均だけではなく、95パーセンタイルや最悪タイムを見ると、本番リスクが見えます。

PID制御

一言でいうと、ズレをどれくらい戻すかを決める代表的な制御方法です。

P：今どれくらいズレているか
I：ズレがたまり続けているか
D：急にズレたか

初心者はまずP制御だけでもいいです。

補正量 = ズレ量 × 係数

これだけでも、「右に寄ったら左に戻す」ができます。

エンコーダ

車輪がどれだけ回ったかを見るセンサーです。
移動距離の推定に使います。

ただし、タイヤが滑るとズレます。

ジャイロ

ロボットの角度変化を見るセンサーです。
曲がりすぎ、曲がらなさを検出できます。

ただし、時間が経つとドリフトすることがあります。

オドメトリ

エンコーダやジャイロから、今どこにいるかを推定する方法です。

ただし、これもズレます。
だから壁、ライン、マーカーなどの外部基準で補正します。

キャリブレーション

センサーの基準合わせです。

ラインセンサーなら、白い床、黒いライン、照明条件に合わせて値を調整します。
距離センサーなら、実測距離とセンサー値の対応を確認します。

フェイルセーフ

失敗しそうな時に安全側へ倒す仕組みです。

迷ったら停止
壁に近すぎたら減速
センサー値が異常なら安全モード
一定時間ゴールできなければ停止

勝ちたいなら、フェイルセーフは必須です。

Sim-to-Real Gap

シミュレーションと現実の差です。

PC上では勝てたのに、実機では死ぬ。
これは普通に起きます。

だから、シミュレーターは神ではありません。
シミュレーターは仮説作成装置です。

第10章：制御設計は「目標動作＋複数基準で補正」

強いロボットは、1つの基準だけに頼りません。

エンコーダだけ → タイヤ滑りでズレる
ジャイロだけ → ドリフトする
距離センサーだけ → 壁形状やノイズでズレる
ラインセンサーだけ → 床・照明・汚れでズレる

だから、複数基準で補正します。

エンコーダ：移動距離
ジャイロ：向き
距離センサー：壁との距離
ラインセンサー：外部基準
タイマー：異常検出
電圧：速度補正

設計としては、次のようにします。

1. 目標ルートを決める
2. 現在の状態を推定する
3. 目標との差を計算する
4. 補正量を出す
5. 危険なら減速する
6. 失敗しそうなら復帰・停止する

第11章：止まって曲がるより、弧を描いて曲がる

初心者はよく、こう作ります。

直進
停止
右旋回
停止
直進

これは分かりやすいですが、遅くなりやすいです。
さらに、停止と再加速で挙動がばらつくこともあります。

レースとしては、できるなら弧を描いて曲がる方が速いです。

直線では速度を出す
カーブ前で少し減速する
弧を描いて曲がる
曲がり終わりで加速する

ただし、最初から攻めすぎないこと。

第1段階：確実に完走
第2段階：カーブ前だけ減速
第3段階：弧を描いて曲がる
第4段階：速度と曲率を最適化

最初からレーシングラインを狙って死ぬより、まず安全マージンを取ります。

第12章：モンテカルロシミュレーターの考え方

ここから、Pythonでシミュレーターを作ります。

目的は、本物の物理エンジンを作ることではありません。
初心者チームが、次の感覚を持つことです。

1回だけ速い設定は危ない
ばらつきを入れると失敗する設定が見える
完走率、ワーストケース、標準偏差で比べる
速度を上げる前に安全マージンを見る

シミュレーターに入れるばらつき

タイヤ/モーター左右差
センサーノイズ
床滑り
電池電圧
初期位置ズレ
初期角度ズレ

評価指標

成功率
平均タイム
95パーセンタイルタイム
標準偏差
失敗理由

第13章：Pythonコード実例

下のコードは、2m×3mの仮コースで、障害物を避けながらゴールを目指す簡易シミュレーターです。

現実の大会に使う時は、必ず以下を修正してください。

- Courseのwidth/height
- obstacles
- waypoints
- robot_radius
- max_speed
- センサーばらつき
- 失敗判定


import math
import random
import statistics
from dataclasses import dataclass

@dataclass
class Course:
    width: float = 2.0
    height: float = 3.0
    robot_radius: float = 0.08
    goal_radius: float = 0.12
    obstacles: tuple = (
        (1.00, 1.45, 0.16),
    )

@dataclass
class RobotParams:
    max_speed: float
    turn_gain: float
    lookahead: float
    safety_margin: float
    tire_bias_sigma: float = 0.025
    sensor_noise_sigma: float = 0.010
    floor_slip_sigma: float = 0.020
    battery_sigma: float = 0.030
    start_pos_sigma: float = 0.015
    start_angle_sigma: float = math.radians(2.5)

def clamp(x, lo, hi):
    return max(lo, min(hi, x))

def wrap_pi(angle):
    return (angle + math.pi) % (2 * math.pi) - math.pi

def distance(a, b):
    return math.hypot(a[0] - b[0], a[1] - b[1])

def is_crash(x, y, course: Course):
    r = course.robot_radius
    if x < r or x > course.width - r or y < r or y > course.height - r:
        return True, "course_out"
    for ox, oy, orad in course.obstacles:
        if math.hypot(x - ox, y - oy) < (r + orad):
            return True, "obstacle_collision"
    return False, ""

def simulate_once(params: RobotParams, seed=None):
    if seed is not None:
        random.seed(seed)
    course = Course()
    waypoints = [
        (0.25, 0.25),
        (0.25, 0.90),
        (0.55, 1.05),
        (1.45, 1.05),
        (1.75, 1.35),
        (1.75, 2.75),
    ]
    goal = waypoints[-1]
    tire_bias = random.gauss(0, params.tire_bias_sigma)
    sensor_noise = params.sensor_noise_sigma
    floor_slip = random.gauss(0, params.floor_slip_sigma)
    battery_scale = 1.0 + random.gauss(0, params.battery_sigma)
    x = waypoints[0][0] + random.gauss(0, params.start_pos_sigma)
    y = waypoints[0][1] + random.gauss(0, params.start_pos_sigma)
    theta = math.pi / 2 + random.gauss(0, params.start_angle_sigma)
    dt = 0.10
    t = 0.0
    max_t = 14.0
    current_wp = 1
    min_obstacle_distance = 999
    while t < max_t:
        if distance((x, y), goal) < course.goal_radius:
            return {"success": True, "time": t, "reason": "goal", "min_obstacle_distance": min_obstacle_distance}
        target = waypoints[current_wp]
        if distance((x, y), target) < params.lookahead and current_wp < len(waypoints) - 1:
            current_wp += 1
            target = waypoints[current_wp]
        observed_x = x + random.gauss(0, sensor_noise)
        observed_y = y + random.gauss(0, sensor_noise)
        desired_heading = math.atan2(target[1] - observed_y, target[0] - observed_x)
        heading_error = wrap_pi(desired_heading - theta)
        curve_slowdown = 1.0 - clamp(abs(heading_error) / math.radians(90), 0, 0.55)
        nearest = min(math.hypot(x - ox, y - oy) - (orad + course.robot_radius) for ox, oy, orad in course.obstacles)
        min_obstacle_distance = min(min_obstacle_distance, nearest)
        obstacle_slowdown = 0.60 if nearest < params.safety_margin else 1.0
        v = params.max_speed * battery_scale * curve_slowdown * obstacle_slowdown
        omega = params.turn_gain * heading_error
        omega += tire_bias
        v *= (1.0 - abs(floor_slip))
        theta = wrap_pi(theta + omega * dt)
        x += v * math.cos(theta) * dt
        y += v * math.sin(theta) * dt
        t += dt
        crashed, reason = is_crash(x, y, course)
        if crashed:
            return {"success": False, "time": t, "reason": reason, "min_obstacle_distance": min_obstacle_distance}
    return {"success": False, "time": max_t, "reason": "timeout", "min_obstacle_distance": min_obstacle_distance}

def percentile(values, p):
    if not values: return None
    values = sorted(values)
    return values[int((len(values) - 1) * p)]

def evaluate(params: RobotParams, n=50):
    results = [simulate_once(params) for _ in range(n)]
    successes = [r for r in results if r["success"]]
    success_rate = len(successes) / n
    times = [r["time"] for r in successes]
    reasons = {}
    for r in results:
        reasons[r["reason"]] = reasons.get(r["reason"], 0) + 1
    if times:
        avg_time = statistics.mean(times)
        std_time = statistics.pstdev(times) if len(times) > 1 else 0.0
        p95_time = percentile(times, 0.95)
        worst_time = max(times)
    else:
        avg_time = std_time = p95_time = worst_time = None
    if success_rate < 0.995:
        score = -1_000_000 + success_rate * 10_000
    else:
        score = success_rate * 1_000_000 - p95_time * 10_000 - avg_time * 1_000 - std_time * 5_000
    return {"params": params, "success_rate": success_rate, "avg_time": avg_time, "std_time": std_time, "p95_time": p95_time, "worst_time": worst_time, "reasons": reasons, "score": score}

def fmt_time(x):
    return "--" if x is None else f"{x:.2f}s"

def main():
    candidates = []
    for max_speed in [0.40, 0.60, 0.80]:
        for turn_gain in [2.5, 3.5]:
            for safety_margin in [0.15, 0.30]:
                candidates.append(RobotParams(max_speed=max_speed, turn_gain=turn_gain, lookahead=0.08, safety_margin=safety_margin))
    evaluated = [evaluate(c, n=50) for c in candidates]
    evaluated.sort(key=lambda r: r["score"], reverse=True)
    print("Top 10 candidates")
    print("=" * 100)
    for i, r in enumerate(evaluated[:10], start=1):
        p = r["params"]
        print(
            f"{i:02d} success={r['success_rate']*100:5.2f}% "
            f"avg={fmt_time(r['avg_time']):>7} p95={fmt_time(r['p95_time']):>7} "
            f"std={fmt_time(r['std_time']):>7} speed={p.max_speed:.2f} "
            f"turn_gain={p.turn_gain:.1f} safety={p.safety_margin:.2f} reasons={r['reasons']}"
        )
if __name__ == "__main__":
    main()

このコードは、最初から完全な答えではありません。
むしろ、あなたの大会条件を入れて育てるための土台です。

Codex、Claude Code、ChatGPTなどに、次のように投げてください。

このPythonコードを、私たちのロボコンコース用に修正してください。

コース条件：
- コースサイズ：
- 障害物：
- スタート位置：
- ゴール位置：
- ロボットサイズ：
- 使えるセンサー：
- 最高速度：
- 大会ルール：

やりたいこと：
- 完走率を最大化したい
- 失敗地点をログに出したい
- 速度、曲がり補正、安全マージンを探索したい
- 結果をCSVに保存したい

第14章：実機で取るべきログ

シミュレーターだけでは勝てません。
現実の実機ログが必要です。

最低限、次を記録します。

run_id
datetime
config_name
success
time_sec
failure_point
failure_reason
battery_voltage
tire_state
floor_state
start_position_note
change_note
memo

ArduinoやRaspberry Piを使うなら、シリアル出力で次のようなログを出します。

RUN,12,config=curve_slow_v2,success=1,time=8.42,battery=7.9,fail=none
RUN,13,config=curve_slow_v2,success=0,time=0,fail=first_curve_outer,battery=7.8

ログをCSVにまとめると、AIにも投げやすくなります。

第15章：チーム運用マニュアル

ここからが重要です。

ロボコンは、1人で全部やると詰みます。
機体、コード、試走、記録、動画、原因分析、改善判断を1人で全部やると、情報が脳内に散って終わります。

だから、チームにも制御設計が必要です。

ロボットにはセンサーと補正が必要です。
チームには、役割とログと会議台本が必要です。

役割分担

役割 やること
進行役 今日の目的、判断基準、次回タスクを整理
機体担当 タイヤ、重心、ネジ、配線、摩耗、破損を見る
制御担当 速度、曲がり、補正、PID、フェイルセーフを見る
センサー担当 距離、ライン、ジャイロ、キャリブレーションを見る
記録担当 成功/失敗、タイム、失敗地点、変更点を記録
動画担当 試走を毎回同じ角度から撮影
AI担当 議事録、試走ログ、エラー、改善案をAIに投げる

重要なのは、全員が全部見ないことです。

全員で見ていると、誰も見ていないのと同じです。

第16章：初回ミーティング台本

そのまま読める台本です。

今日は、ロボコンレースで地方大会優勝を狙うために、まず方針をそろえたいです。

最初から最高速を狙うのではなく、まず完走率を最優先にします。

採用基準は、
1. 完走率
2. ワーストケース
3. タイムのばらつき
4. 平均タイム
の順番です。

理由は、本番で1回でも失敗したら終わるからです。
1回だけ速いロボットより、何回走っても死なないロボットを先に作ります。

まず今日は、
- コースを区間に分ける
- 失敗しそうな場所を洗い出す
- 何を測るか決める
- 誰が何を担当するか決める
ところまで進めたいです。

この進め方でよさそうですか？
他に先に確認したいルールや制約はありますか？

第17章：試走前ミーティング台本

今から10回試走します。

今回見るのは、速さではなく安定性です。

記録する項目は、
- 成功/失敗
- タイム
- 失敗地点
- 失敗内容
- 電池電圧
- 変更点
です。

今回は途中で設定を変えません。
途中で変えると、何が効いたか分からなくなるからです。

10回終わったら、
どこで失敗したか、
どの失敗が一番多いか、
次に1つだけ何を変えるかを決めます。

第18章：試走後ミーティング台本

10回試走した結果を整理します。

成功は○回、失敗は○回です。
失敗地点は、第○カーブが○回、障害物前が○回、ゴール前が○回です。

今の最優先課題は、平均タイムではなく、第○カーブの失敗率です。

改善案は3つあります。

1. カーブ前だけ減速する
2. 曲がり補正を少し強める
3. 壁センサーで再補正する

まずは一番リスクが低い、カーブ前減速だけを試したいです。

これでまた10回走らせて、
成功率、平均タイム、タイムのばらつきを比較します。

この方針でよさそうですか？
他に先に潰すべきリスクはありますか？

第19章：意見が割れた時の進め方

チームから違う意見が出るのは普通です。
むしろ良いことです。

ただし、意見だけで決めないこと。

悪い進め方：
Aさん「速くした方がいい」
Bさん「いや、安定させた方がいい」
Cさん「センサー増やそう」
全員「どうする？」

こうなると止まります。

良い進め方は、これです。

1. 意見をログに残す
2. 目的に照らして分類する
3. 試せる形にする
4. 1つずつ検証する

台本はこれです。

意見ありがとうございます。

今の意見を整理すると、
A案は速度改善、
B案は安定性改善、
C案はセンサー追加による補正改善だと思います。

今の採用基準では、完走率が最優先なので、
まず失敗率を下げるB案かC案を優先したいです。

ただ、C案は実装コストが大きいので、
まずB案を10回試して、改善しなければC案を検討する流れでどうでしょうか？

このように、相手の意見を消さず、判断基準に戻します。

第20章：分からなくなったら、議事録・録画・ログをAIにぶち込む

チームで進めていると、途中で必ず分からなくなります。

どの案がいいか分からない
意見が割れた
ログの見方が分からない
コードが動かない
コース条件が変わった
本番ルールが変わった
試走結果が想定と違う

この時に、チーム内だけで悩み続ける必要はありません。

やることはシンプルです。

1. 議事録を取る
2. 試走ログを残す
3. できれば動画を撮る
4. 変更点をメモする
5. それをAIに投げる

AIへのプロンプトはこれです。

以下はロボコンレースチームの議事録、試走ログ、現在の課題です。
完走率を最優先に、次に何を試すべきか提案してください。

採用基準：
1. 完走率
2. ワーストケース
3. タイムのばらつき
4. 平均タイム

大会条件：
【ここに大会ルール】

機体条件：
【ロボットサイズ、センサー、モーター、電池】

コース条件：
【コース図、障害物、スタート、ゴール】

試走ログ：
【CSVや表を貼る】

議事録：
【チームで出た意見を貼る】

現在の悩み：
【何で迷っているか】

出してほしいもの：
- 次に試すべき改善案を3つ
- 優先順位
- その理由
- 10回試走するときの記録項目
- チームに説明する台本

これで、だいたい次の一手は出ます。

もちろんAIの回答を丸呑みする必要はありません。
でも、詰まって止まるより、仮説を出して試す方が強いです。

第21章：PowerPointやExcel作成に時間を溶かすな

チームでやると、資料作りに時間が吸われます。

発表資料を作る
Excel表を整える
議事録をきれいにする
説明用のスライドを作る

もちろん最低限の資料は必要です。
でも、資料作りが目的ではありません。

目的は、改善して挑戦することです。

だから、資料作成はAIに投げます。

PowerPoint作成プロンプト

以下のロボコン改善方針を、チーム説明用のPowerPoint構成にしてください。

目的：
初心者チームに、完走率優先の設計思想、試走ログの取り方、役割分担を説明する。

条件：
- スライド10枚以内
- 1枚1メッセージ
- チームメンバーがそのまま動ける内容
- 最後に次回タスクを入れる

内容：
【この記事の該当部分を貼る】

Excel作成プロンプト

以下の試走ログ項目を、Excelで使える表にしてください。

列：
run_id
date
config_name
success
time_sec
failure_point
failure_reason
battery_voltage
tire_state
floor_state
change_note
memo

追加してほしいもの：
- 成功率の計算
- 平均タイム
- 標準偏差
- 失敗地点別の件数
- グラフ用の集計表

議事録作成プロンプト

以下の会議メモを、ロボコンチーム用の議事録に整理してください。

整理形式：
- 今日の目的
- 決定事項
- 出た意見
- 未決事項
- 次に試すこと
- 担当者
- 期限

会議メモ：
【音声入力やメモを貼る】

資料はAIで作って、人間は試走と改善に時間を使います。

第22章：資料作りより、改善サイクルを回せ

ロボコンで勝つチームは、資料がきれいなチームではありません。
試走から情報を回収し、次の改善に変換できるチームです。

やるべきことは、これです。

1. 走らせる
2. 記録する
3. 失敗を見る
4. 1つ直す
5. また走らせる
6. 比較する
7. 良ければ採用、悪ければ戻す

このサイクルを速く回します。

資料：最低限
会議：短く
試走：多く
ログ：必ず
改善：1つずつ
AI：詰まったら使う

合言葉はこれです。

資料作りが目的ではない。
改善して挑戦することが目的である。
話す時間を減らして、試す回数を増やす。

第23章：1週間の進め方サンプル

Day 1：方針決め

- 採用基準を決める
- コースを分解する
- 役割を決める
- ログ表を作る

Day 2：基準機体を作る

- まず動く機体を作る
- 遅くてもよい
- とにかく完走を目指す

Day 3：試走ログを取る

- 10〜20回走らせる
- 失敗地点を記録する
- 動画を撮る

Day 4：最重要失敗を1つ潰す

- 一番多い失敗地点を選ぶ
- 改善案を1つ入れる
- 再度10回走らせる

Day 5：シミュレーターで候補を比較

- 速度
- 曲がり補正
- 安全マージン
- 減速位置

Day 6：本番想定テスト

- 電池残量を変える
- スタート位置をずらす
- タイヤ状態を変える
- 床を変える

Day 7：本番設定を固定

- 本番用設定を決める
- 予備設定を作る
- フェイルセーフを確認
- チェックリストを作る

第24章：本番前チェックリスト

□ 本番設定名は決まっている
□ コードのバージョンは固定した
□ 予備設定がある
□ 電池は満充電
□ タイヤ状態を確認した
□ ネジの緩みを確認した
□ センサーのキャリブレーションをした
□ スタート位置の合わせ方を決めた
□ 失敗時の復帰/停止条件を確認した
□ 試走ログで完走率を確認した
□ チーム全員が採用基準を理解している

本番直前に大きな変更はしない方がいいです。

本番前にやっていいこと：
- 電池交換
- ネジ確認
- センサー確認
- スタート位置確認

本番前にやると危険なこと：
- 制御ロジック大変更
- センサー位置変更
- タイヤ種類変更
- コース戦略変更

本番直前の思いつき改善は、だいたい事故ります。

第25章：この記事をチーム用プロンプトとして使う

この記事は、読み物ではなくテンプレートとして使ってください。

自分たちの条件を入れて、AIに投げると使いやすいです。

この記事の方針を前提に、私たちのロボコンチーム向けの作戦に落とし込んでください。

大会条件：
【ここに入力】

コース条件：
【ここに入力】

機体条件：
【ここに入力】

使えるセンサー：
【ここに入力】

現在の試走ログ：
【ここに入力】

チームの状況：
【人数、得意不得意、残り日数】

作ってほしいもの：
1. 勝つための優先順位
2. 失敗しやすいポイント
3. 計測すべきデータ
4. 試走ログ表
5. 改善計画
6. チーム役割分担
7. 会議台本
8. Pythonシミュレーター修正案
9. 本番前チェックリスト

コードが動かない場合は、エラーをそのまま貼ります。

以下のPythonコードを実行したらエラーが出ました。
目的はロボコンレースのモンテカルロシミュレーションです。
エラー原因を説明し、動くように修正してください。

エラー：
【ここに貼る】

コード：
【ここに貼る】

第26章：最終まとめ

ロボコンで勝つために必要なのは、天才的な一発芸ではありません。

必要なのは、次の順番です。

1. 死なない設計
2. ズレを測る基準
3. 補正する制御
4. 試走ログ
5. 1変数ずつ改善
6. チーム役割分担
7. AIを使った高速な整理
8. 最後に速度改善

速いロボットではなく、死なないロボットを作る。
シミュレーションで候補を作り、現実ログでズレを測る。
ズレたら補正する。
失敗したら記録する。
改善は1つずつ入れる。
資料作りで満足せず、試走と改善を回す。

ロボットだけでなく、チームにも制御設計を入れる。

これが、初心者チームが地方大会優勝を本気で狙うための基本戦略です。

ロボコンは、速さ勝負に見えて、実際はばらつき管理ゲーである。
勝つロボットは、理論通りに動くロボットではない。
現実に裏切られても戻ってくるロボットである。

参考資料・出典

追補A：中学生でも動ける「行動手順書」に落とす

ここまでの内容は、設計思想としてはかなり強いです。

ただし、チームで動く場合は、思想だけでは足りません。

特に、ロボコンは中学生でも取り組む競技です。
「完走率を見よう」「ばらつきを測ろう」「センサー値を確認しよう」と言っても、受け身のメンバーはそこで止まります。

必要なのは、ここまで落とすことです。

誰が
いつ
どこで
何を
どの道具で
どこからどこまで
何回やって
Excelのどの列に
どう書いて
なぜそれをやるのか

つまり、リーダーが困らないように、作業を「行動」に変換します。

ロボコンでリーダーが詰むのは、メンバーが悪いからだけではありません。
「何をすればいいか」が行動レベルまで分解されていないからです。

「センサーを確認して」ではなく、こう書きます。

前方距離センサー担当は、
作業開始から10分以内に、
白い壁の前で、
メジャーを使って壁から5cm、10cm、15cm、20cm、25cm、30cmの位置にロボットを置き、
各距離でセンサー値を10回読み、
Excelの「実測_距離センサー」シートに、実測距離cm、値1〜値10、平均、標準偏差を入力する。

目的は、センサー値が実際の距離に対してどう変化するか確認し、
壁との距離補正に使う閾値を決めるため。

ここまで書けば、動けます。

逆に、ここまで書かれていない手順書は、受け身のメンバーには優しくありません。

「1から説明しないとだめか？」
答えは、はいです。

最初だけ1から説明します。
その代わり、2回目以降は手順書を見れば動けるようにします。

追補B：ゴール日から逆算する全体計画

ロボコン準備は、ゴール日から逆算します。

「今週何をするか」から考えると、だいたい場当たりになります。
「大会日までに、いつまでに、何ができていないと詰むか」から考えます。

8週間ある場合の標準計画

時期 工程 完了条件 なぜ必要か
T-8〜7週 ルール確認・勝利条件定義 失格条件、コース、機体制約、採点基準が1枚にまとまる ルールを知らないと、速くても失格するため
T-7〜6週 コース分解 直線、カーブ、障害物、ゴール前などの危険区間が表になる どこで失敗するかを測れるようにするため
T-6〜5週 センサー・駆動系の実測 距離センサー値、直進ズレ、カーブズレの基準データが取れる 感覚ではなく数値で改善するため
T-5〜4週 低速で最初の完走 遅くても3回連続で完走する 速度改善前に、死なないルートを作るため
T-4〜3週 失敗モード潰し 一番多い失敗が半分以下になる 本番で死ぬ原因を先に消すため
T-3〜2週 速度改善 完走率を維持したままタイム短縮する 死なない範囲で速くするため
T-2〜1週 本番想定試走 電池、タイヤ、初期位置ズレ込みで20〜50回試走する 本番差分に強いか確認するため
T-1週 凍結・チェック 大きな変更を止め、予備部品・電池・手順を確認する 直前の思いつき変更で壊さないため
T-0 本番 当日チェックリスト通りに動く 焦りによる事故を防ぐため

4週間しかない場合

4週間しかない場合は、欲張らない方が勝ちやすいです。

第1週：ルール確認、コース分解、センサー実測、直線・カーブの基礎確認
第2週：低速完走ルート作成、失敗地点の記録
第3週：最多失敗地点を潰す、完走率を上げる
第4週：速度改善は小さく、本番チェックと凍結

この場合、最初から複雑な最適化を狙いすぎない方がいいです。

目標は、こうです。

1. 低速で完走
2. 失敗地点を潰す
3. ばらつきを減らす
4. 余裕があれば速くする

2週間しかない場合

2週間しかない場合は、さらに絞ります。

第1週：最低限の完走ルートを作る
第2週：本番で死なないようにする

この場合、狙うべきは最速ではありません。

やること：
- 低速でも完走するルートを作る
- 一番危ないカーブだけ重点的に直す
- 電池満充電・タイヤ状態・スタート位置を固定する
- 大きな変更はしない

捨てること：
- 複雑な最適経路
- ギリギリの高速化
- 見た目の凝った資料
- 全区間の完璧な最適化

2週間しかないのに、全部やろうとすると死にます。
勝つためには、やることを減らします。

追補C：ロール別手順書――いつ、どこで、どうする、なぜ

チーム運用では、全員に同じ説明をするより、ロールごとに手順を渡す方が強いです。

進行役

項目 内容
いつ 作業開始時、試走前、試走後
どこで 会議机、コース横、作業台前
使う道具 今日の作業表、タイマー、試走ログ、会議ログ
何をする 今日の目的、変更する変数、試走回数、終了条件を決める
Excelに書く場所 会議ログ、改善ログ
終わりの条件 全員が「今日やること」を一言で言える状態
なぜ必要か チームが別々の方向に動くのを防ぐため

進行役の最初の30秒台本

今日は、速さではなく完走率を見ます。
今回変える変数は1つだけにします。
試走は10回やります。
記録担当は成功/失敗と失敗地点を書いてください。
動画担当は毎回同じ角度から撮ってください。
試走後に、一番多い失敗を見て、次に直す場所を決めます。

機体担当

項目 内容
いつ 試走前、試走後、落下・衝突後
どこで 作業台
使う道具 ドライバー、六角レンチ、予備ネジ、予備タイヤ、メジャー
何をする ネジ、タイヤ、配線、重心、センサー固定、破損を確認する
Excelに書く場所 試走ログの「タイヤ状態」「メモ」
終わりの条件 ネジ緩みなし、配線干渉なし、タイヤ状態が記録済み
なぜ必要か 機械側の不具合を、コードや制御のせいにしないため

機体担当のチェック手順

1. タイヤが外れかけていないか見る
2. 左右タイヤの汚れ・摩耗を確認する
3. ネジが緩んでいないか軽く確認する
4. 配線がタイヤや床に当たっていないか見る
5. センサーの向きがズレていないか見る
6. 変更があれば試走ログに書く

制御担当

項目 内容
いつ 改善時、試走前、試走後
どこで PC前、コース横
使う道具 PC、コード、AI、試走ログ、改善ログ
何をする 速度、曲がり補正、停止条件、センサー閾値を調整する
Excelに書く場所 改善ログの「変更ID」「変更前」「変更後」
終わりの条件 今回変えた変数が1つだけ記録されている
なぜ必要か 何が効いたか分かるようにするため

制御担当の禁止事項

同時に、速度・PID・センサー位置・停止条件を全部変えない。

理由は、何が効いたか分からなくなるからです。

センサー担当

項目 内容
いつ 実測時、試走前、センサー値が怪しい時
どこで 壁の前、ライン上、コース横
使う道具 メジャー、PC、シリアルモニタ、Excel
何をする 実測距離とセンサー値の対応を確認する
Excelに書く場所 実測_距離センサー
終わりの条件 距離ごとの平均値とばらつきが入っている
なぜ必要か センサー値を現実の距離に変換するため

記録担当

項目 内容
いつ 試走中、試走直後
どこで コース横
使う道具 Excel、Googleスプレッドシート、ストップウォッチ、ペン
何をする 1走につき1行、成功/失敗・タイム・失敗地点を書く
Excelに書く場所 試走ログ
終わりの条件 試走番号と動画番号が対応している
なぜ必要か 失敗を感想ではなくデータにするため

動画担当

項目 内容
いつ 試走中
どこで コース全体が見える固定位置
使う道具 スマホ、三脚、充電器
何をする 毎回同じ角度から動画を撮る
Excelに書く場所 試走ログの「動画ファイル名」
終わりの条件 試走番号と動画が対応している
なぜ必要か 失敗地点や姿勢のズレを後から確認するため

AI・資料担当

項目 内容
いつ 会議後、迷った時、資料が必要な時
どこで PC前
使う道具 ChatGPT、Claude、Claude Code、Codex、Excel、PowerPoint
何をする ログ・議事録・動画要約をAIに入れて、次の一手・資料・表を作る
Excelに書く場所 会議ログ、改善ログ
終わりの条件 次回の作業リストがロール別に出ている
なぜ必要か 人間が資料作成に時間を溶かさないため

追補D：実測マニュアル――メジャーでどこからどこまで測るか

変数を出しただけでは足りません。

次に必要なのは、その変数をどう測るかです。

「センサー誤差を見る」と書くだけでは動けません。
「メジャーで壁から10cmに置き、センサー値を10回読む」まで書きます。

1. 距離センサーの測り方

目的

実測距離とセンサー値の対応を確認します。

これをやらないと、センサー値が「近い」「遠い」くらいの感覚でしか使えません。

使う道具

- メジャー
- 白い壁または段ボール
- ロボット
- PC
- センサー値を表示する画面
- Excelテンプレート
- マスキングテープ

場所

白い壁の前、または反射しやすい面の前で行います。
本番の壁や障害物に近い材質があるなら、それを使います。

手順

1. 壁から5cmの位置にテープで印をつける
2. ロボットのセンサー先端を5cmの印に合わせる
3. ロボットを動かさず、センサー値を10回読む
4. Excelの「実測_距離センサー」シートに、値1〜値10を入れる
5. 同じことを10cm、15cm、20cm、25cm、30cmで行う
6. Excelで平均と標準偏差を見る
7. 実測距離cmと平均センサー値の対応を見る

Excelに書く列

列 書く内容
日付 測った日
センサー名 前方距離、右距離、左距離など
実測距離cm メジャーで測った距離
値1〜値10 センサー値を10回読む
平均 Excelで平均を出す
標準偏差 ばらつきを出す
場所/条件 白壁、段ボール、本番床など
メモ 値が暴れた、暗い、反射が弱いなど

判断

平均値が距離に応じてきれいに変わる → 使いやすい
同じ距離でも値が大きく暴れる → フィルタや別センサーが必要
距離が変わっても値があまり変わらない → その範囲では使いにくい
本番材質で値が変わる → 本番材質で再測定する

2. 直線走行の測り方

目的

「まっすぐ進むつもり」が、実際にどれくらいズレるか確認します。

使う道具

- メジャー
- マスキングテープ
- ストップウォッチ
- Excel
- スマホ動画

場所

床に1mまたは2mの直線を作ります。
スタートラインとゴールラインをテープで貼ります。

手順

1. 床にスタートラインを貼る
2. スタートラインから1m先にゴールラインを貼る
3. スタート位置を毎回同じにする
4. ロボットを1m直進させる
5. ゴールライン付近で止まった位置を見る
6. 中心線から横に何cmズレたかをメジャーで測る
7. ロボットの向きが何度くらいズレたかも記録する
8. 10回繰り返す

Excelに書く列

列 書く内容
日付 試験日
試験ID STR-001など
距離m 1.0、2.0など
速度設定 低速、中速、高速など
開始位置 直線開始テープなど
回数 1〜10
成功/失敗 成功、失敗、中断
到達タイム秒 ストップウォッチまたはログ
終点横ズレcm 中心線から何cmズレたか
向きズレ度 目視または角度ログ
電池電圧V 測れるなら入れる
床状態 普通、滑る、汚れなど
メモ 左に寄る、右に寄るなど

判断

毎回同じ方向にズレる → 左右モーター差、タイヤ差、初期角度を疑う
毎回バラバラにズレる → 床、タイヤ滑り、センサーノイズを疑う
電池が減るとズレる → 電圧補正を考える
速度を上げるとズレる → その速度はまだ危険

3. カーブ区間の測り方

目的

カーブで外側に膨らむ、内側に入りすぎる、出口角度がズレるなどを確認します。

通し試走だけでは不十分

最初から最後まで通して走らせるだけだと、失敗地点まで到達する前の誤差も混ざります。

だから、カーブだけを試す区間テストをします。

使う道具

- メジャー
- マスキングテープ
- スマホ動画
- Excel
- 必要なら分度器、角度目印

場所

本番コースのカーブ手前30cm〜50cmに、仮スタートラインを貼ります。

手順

1. カーブ手前30cmに仮スタートラインを貼る
2. ロボットを毎回同じ向きで置く
3. カーブだけ走らせる
4. カーブ出口で横ズレを測る
5. 出口角度のズレを見る
6. 失敗したら、外側接触・内側接触・曲がり不足・曲がりすぎに分類する
7. 10回繰り返す
8. 改善後も同じ条件で10回繰り返す

Excelに書く列

列 書く内容
日付 試験日
試験ID CUR-001など
区間 第1カーブ、第2カーブなど
開始位置 カーブ手前30cmなど
目標曲率/角度 90度、ゆるい右カーブなど
速度設定 低速、中速、高速など
回数 1〜10
成功/失敗 成功、失敗、中断
失敗内容 外側接触、内側接触、曲がり不足など
出口横ズレcm 出口の中心から何cmズレたか
出口角度ズレ度 可能なら角度で書く
電池電圧V 測れるなら入れる
動画 ファイル名
メモ 滑った、速度が高いなど

判断

外側に膨らむ → カーブ前減速、曲がり補正強化、曲率をゆるくする
内側に入りすぎる → 曲がり補正弱め、速度を少し上げる、目標軌道を外側へ
出口角度がズレる → ジャイロ補正、出口で再補正
成功するがタイムが遅い → 完走率を維持したまま少しずつ速度を上げる

4. スタートから試すのか、途中から試すのか

これはかなり大事です。

結論は、両方やります。

ただし、目的が違います。

試し方 目的 いつ使うか
スタートから通し試走 本番で完走するか見る 全体評価、本番前、改善後の確認
途中から区間試走 特定の失敗原因を潰す 同じ場所で何度も失敗する時
センサー単体実測 センサーが使えるか見る 制御に入れる前
直線・カーブ単体 足回りの基礎を見る 複雑なコースに入る前

進め方

1. まず低速でスタートから通し試走する
2. 失敗地点を記録する
3. 同じ地点で2回以上失敗したら、途中から区間試走する
4. 区間で安定したら、スタートから通し試走に戻す
5. 通しで安定したら、少しだけ速度を上げる

つまり、こうです。

通し試走：本番で死ぬかを見る
区間試走：なぜ死ぬかを直す

通しだけだと原因が見えにくい。
区間だけだと本番で通用するか分からない。

だから、区間で直して、通しで確認します。

追補E：Excelテンプレートの使い方

Excelテンプレートには、次のシートを用意します。

シート 使うタイミング 目的
README_使い方 最初 全体の使い方確認
逆算計画 初回、毎週 ゴール日から工程を逆算する
ロール別手順 作業前 誰が何をするか確認する
試走ログ 試走中 成功率・失敗地点・タイムを記録する
実測_距離センサー センサー確認時 実測距離とセンサー値の対応を見る
実測_直線走行 駆動系確認時 まっすぐ進むか確認する
実測_カーブ カーブ調整時 曲がり方の安定性を見る
改善ログ 修正時 何を変えたか残す
会議ログ 会議後 決定・理由・次回タスクを残す
ダッシュボード 試走後 完走率・失敗数・平均タイムを見る

記録担当への説明台本

試走1回につき、Excelに1行書いてください。
書くのは、成功/失敗、タイム、失敗地点、失敗内容、電池電圧、変更ID、動画ファイル名です。
全部を完璧に書けなくても、成功/失敗と失敗地点だけは必ず書いてください。
このログがないと、次に何を直すか決められません。

センサー担当への説明台本

今から距離センサーの実測をします。
メジャーで壁から5cm、10cm、15cm、20cm、25cm、30cmの位置を作ります。
それぞれの距離でセンサー値を10回読みます。
Excelの値1〜値10に入力してください。
平均とばらつきはExcelが出します。
目的は、センサー値を実際の距離として使えるか確認することです。

制御担当への説明台本

今回変えるのは1つだけです。
速度を変えるなら、PIDやセンサー位置は変えません。
PIDを変えるなら、速度やタイヤは変えません。
変更IDをつけて、改善ログに変更前と変更後を書いてください。
10回試走して、成功率と失敗地点を比較します。

追補F：リーダーが困った時の進め方

リーダーが困るのは、たいてい次の場面です。

- 何からやればいいか分からない
- メンバーが感覚で意見を言い始めた
- 試走はしているが改善している感じがしない
- 資料作りに時間を使いすぎている
- 途中でルールや条件が変わった
- 誰が何をするか曖昧になった

この時は、次の順番に戻ります。

1. ゴール日を確認する
2. 今日の目的を1つにする
3. 今一番多い失敗を選ぶ
4. 変更する変数を1つだけ決める
5. 10回試す
6. Excelに書く
7. 改善前後を比べる
8. 次の一手を決める

リーダー用の困った時台本

いったん整理します。
今は意見が増えてきているので、ログに戻ります。
今回一番多い失敗はどこですか？
まず、その失敗を減らすために、変えるものを1つだけ決めたいです。
速度、曲がり補正、センサー閾値、開始位置のうち、今回はどれを見ますか？
決めたら10回試して、成功率で判断します。

条件が変わった時

大会ルール、コース、機体条件、使えるセンサー、チーム人数などが変わった時は、無理にその場で判断しません。

1. 変更内容を会議ログに書く
2. 変更前と変更後を分けて書く
3. 関係する工程を洗い出す
4. AIに投げる
5. 影響が大きい順に作業を組み直す

AIに投げる文はこれです。

以下はロボコンチームの変更ログです。
大会条件が変わりました。

変更前：
{変更前の条件}

変更後：
{変更後の条件}

現在の進捗：
{今できていること}

残り期間：
{大会日までの期間}

この変更によって、どの工程に影響があるかを整理してください。
やるべき作業を、優先順位順に、ロール別・日付別に分けてください。
捨てるべき作業も教えてください。

追補G：資料作成はAIに任せる。人間は試走と改善に時間を使う

資料作りは大事です。
でも、資料作りは目的ではありません。

目的は、改善して挑戦することです。

ロボコンで勝つために必要なのは、美しいPowerPointを作ることではありません。

試す
測る
記録する
比べる
直す
また試す

これです。

だから、PowerPointやExcelの見た目に時間をかけすぎないでください。

必要なら、ChatGPT、Claude、Claude Code、Codexにこう依頼します。

PowerPoint生成プロンプト

以下のロボコン試走ログと改善方針をもとに、チーム共有用のPowerPoint原稿を作ってください。
5枚以内でお願いします。

構成：
1. 今日の目的
2. 現在の完走率と失敗地点
3. 次に直す1つの変数
4. ロール別の作業
5. 次回までのタスク

中学生でも分かる言葉で、1枚あたり3行以内にしてください。

Excelテンプレ修正プロンプト

以下のロボコン試走ログテンプレートを、私たちの大会条件に合わせて修正してください。
必要なシート、列名、入力例、計算式、判断ルールを出してください。

大会条件：
{ルール}

コース：
{コース情報}

使えるセンサー：
{センサー}

今測りたいこと：
{測定項目}

会議後の次回タスク生成プロンプト

以下は今日の会議ログと試走ログです。
次回30分でやる作業を、ロール別に分けてください。

条件：
- 変更する変数は1つだけ
- 10回試走する
- Excelにどの列を書くかも指定
- なぜその作業が必要かも書く
- 受け身の中学生でも動ける粒度にする

会議ログ：
{会議ログ}

試走ログ：
{試走ログ}

資料はAIで最低限作る。
人間はコースに戻る。
試す。
ログを取る。
直す。

これが勝ち筋です。

追補H：最終的な作業単位は「作業カード」にする

チームで動くなら、最終的には作業をカード化すると強いです。

作業カード例：距離センサー実測

作業名：前方距離センサーの実測
担当：センサー担当
時間：15分
場所：白い壁の前
道具：メジャー、PC、Excel、ロボット、テープ
手順：
1. 壁から5cmにロボットを置く
2. センサー値を10回読む
3. 10cm、15cm、20cm、25cm、30cmも同じように測る
4. Excelの「実測_距離センサー」に入力する
完了条件：距離ごとの平均値と標準偏差が出ている
なぜ：壁との距離補正に使う閾値を決めるため

作業カード例：第1カーブ区間テスト

作業名：第1カーブ区間テスト
担当：制御担当、記録担当、動画担当
時間：20分
場所：第1カーブ手前30cm
道具：ロボット、電池、Excel、スマホ、テープ
手順：
1. カーブ手前30cmに仮スタートラインを貼る
2. ロボットを毎回同じ向きで置く
3. 10回走らせる
4. 成功/失敗、出口横ズレ、失敗内容をExcelに書く
5. 動画ファイル名も書く
完了条件：10回分のログが入っている
なぜ：通し試走では分からないカーブ単体の失敗原因を見るため

作業カード例：試走後の改善判断

作業名：試走後の改善判断
担当：進行役
時間：10分
場所：会議机またはコース横
道具：試走ログ、改善ログ、動画
手順：
1. 成功数と失敗数を見る
2. 失敗地点を数える
3. 一番多い失敗を選ぶ
4. 改善案を3つ出す
5. 一番リスクが低い改善を1つだけ選ぶ
6. 改善ログに変更IDを書く
完了条件：次に変える変数が1つに決まっている
なぜ：感覚ではなくログで改善するため

ロボコンチームのリーダーは、メンバーに「考えて動いて」と言うより、まず作業カードを渡した方がいいです。

考える部分は、リーダーとAIで先に整理する。
作業する人には、迷わず動ける単位で渡す。

これがチームを動かすコツです。

今日これ読んで

この記事を読んだ人の次の疑問に、それぞれ答える記事です。

近いテーマ・ほかの記事から

すべての記事から探す「制度・仕組み」の記事をもっと見る

この記事をシェア

LINEで共有（新しいタブで開きます）Xで共有（新しいタブで開きます）

この記事が役に立ったら、応援できます。 応援する

広告

もう1個、なんか面白いのない？

読み終わったついでに。近い話と、ぜんぜん違うけど面白い話を少しずつ。

  1. 近い話全員ほぼ0歳なのにデカくてペラペラキメラアントの完成品出産、女王の食いすぎ、ポンズと銃の悲劇
  2. なぜガソリンスタンドの価格表示は赤く点滅するのか？赤い数字・広告ルール・看板費用まで調べた
  3. ぜんぜん違うけどなぜ『ペルソナ4』は今でも特別なのか？
  4. 父親席、結婚式前日にやっと返却へ『花まんま』で兄の家族監査がほどけ、死者の記憶が“花の弁当”になるまで
  5. 散歩だけではなぜ体重が落ちないことがあるのかジム習慣が途切れた時系列から考える「戻し方」
  6. 火力は消えたのではなく、出力先が変わった約86日で1,225本を生んだ一人編集部

他の記事を探す

すべての記事

めんどいちゃん

このサイトの運営者

めんどいちゃん

仕事や日常の「めんどい」を構造化して、次に動きやすくする記事を書いています。

広告

新着記事

  1. 1『VIVANT』続編は好評なのに、なぜ自分には低予算に見えたのか――AIハヤト、説明劇、別班の正体開示を考える
  2. 28.6秒バズーカーとボチリストは同一人物なのか？「10年後」説と現在の仕事を調べた
  3. 3ベッドで話すだけで、記事づくりが進む理由
  4. 4護衛軍には実質勝てていない――「倒す」より分断・遅延で勝つキメラアント編
  5. 5複利だけ早送りして、人生はゆっくり進んでほしい
広告