先日、高校物理の定番テーマである「斜方投射（しゃほうとうしゃ）」の典型問題を解いていた生徒の答案を見ていたときのことです。最高点に達するまでの時間、最高点の高さ、そして水平到達距離——見事なまでに、最初から最後まで「全問バツ」でした。
しかし、答案の数式を1行ずつ追跡（トレース）してみると、その生徒は等加速度直線運動の公式を忘れていたわけでも、二次関数の計算をミスしていたわけでもありませんでした。そこには、先日私が深夜のサーバー構築でやらかした「思わず笑ってしまうようなバグ」と、寸分違わぬ構造的エラーが潜んでいたのです。
01. 斜方投射の「全滅」を引き起こした1行のスキップ
生徒の答案をデバッグしてみると、クラッシュの原因は開始1秒のところにありました。
斜め上方に角度 \theta で打ち出された物体の初速度 v_0 を、水平方向（v_{0x} = v_0 \cos\theta）と鉛直方向（v_{0y} = v_0 \sin\theta）に分解せず、問題文に書かれた斜めの v_0 の数値を、そのまま鉛直方向の公式へと放り込んでいたのです。
- ERROR_LOG // 生徒の脳内で起きていた「未分解データの直接代入」
- 問題文で最初に目に入った「初速度 v_0」という記号を見て、「公式にある v_0 と同じ名前だからこれでいいや」とそのまま代入。斜めのベクトルを縦軸（y 軸）と横軸（x 軸）に切り分ける初期設定を飛ばしたため、以降の全プロセスがドミノ倒しで破綻。
- CORRECT_PROTOCOL // 物理における「パーティション分割（座標分解）」
- どれほど複雑に見える放物運動も、まずは「水平方向の等速直線運動（v_{0x} = v_0 \cos\theta）」と「鉛直方向の鉛直投げ上げ運動（v_{0y} = v_0 \sin\theta）」という2つの独立した座標軸へ分解することから始まる。数式を動かす前の「軸の定義と初期設定」こそが力学の本体である。
等加速度直線運動の公式（v = v_0 + at や x = v_0 t + \frac{1}{2}at^2）という「上位のプログラム」自体は、生徒の頭の中で正常に動いていました。ただ、一番最初の「ベクトルの座標分解」という初期化処理をスキップして生のデータを突っ込んだため、1問目から最終問まで全てがバツになってしまったのです。
02. 深夜のデバッグ記録：210MBの罠と「キーボード未接続」という物理バグ
実はこの答案を見た瞬間、私は「あ、これこないだの自分とまったく同じだ」と思わず苦笑いしてしまいました。先日のローカルLinuxサーバー構築記でも触れた通り、ラボのサーバー環境を構築していた深夜の作業中、これと完全に同じ構造の「バグとの格闘」を2つも経験していたからです。
- TROUBLE 01 // 6TBではなく「210MB」をマウントしていた罠
- 外付けHDDを初期化してマウントした直後、念のため容量を確認してみると、なぜか選択していたのは6TBの本体領域ではなく、出荷時に先頭へ切られていた「210MBの小さな管理パーティション」でした。ディスク全体の構造を確認せず、最初に見えた領域を「これが本体だ」と思い込んでそのままマウントしてしまったのです（斜めの v_0 をそのまま公式に代入した生徒と完全に同じ構造です）。そのままではデータを数冊分入れただけでパンクしてしまいます。すぐにマウント定義をリセットし、全パーティションを一度削除して「単一の6.0TB領域」へ統合し直すことで事なきを得ました。
- TROUBLE 02 // ターミナルが完全無反応になった「物理レイヤー」の盲点
- 後半戦、Pythonコードを配置して確認コマンドを打ち込もうとしたとき、ターミナルがうんともすんとも言わなくなりました。「さっきのプロセスが裏でロックしているのか？」「構文の終端記述が抜けたか？」とソフトウェア側の原因をあれこれ疑ったのですが、真犯人はまったく別の場所にありました。配線を整理した際に、自分自身でキーボードのUSBレシーバーを引っこ抜いていたのです（笑）。
03. 「しまった！」という表情が証明する自己デバッグの完了
物理の問題で全問バツになると、多くの生徒は「二次関数の計算をミスしたかな？」「重力加速度 g のマイナスを忘れたかな？」と、数式の変形や計算処理（ソフトウェア層）ばかりを疑いがちです。
しかし、今回の生徒に「後半の計算ロジックは全部合っているよ。ただ、一番最初に斜めの v_0 を縦と横に分解する配線が抜けたままスイッチを入れていたね」と伝えた瞬間、生徒はハッとして「しまった！」という顔をしました（笑）。
原因不明のフリーズに散々悩んだ挙げ句、手元に転がっているUSBレシーバーを見つけた瞬間のエンジニアとまったく同じ表情です。
教える側からすると、指摘したときに「えっ、どういうことですか？」とキョトンとされるより、この「あ、やっちゃった！」という悔しそうな顔が見られるのが一番安心します。なぜなら、ベクトルの分解や運動の法則という「プログラムの中身」自体はちゃんと理解できていて、単純に最初の初期化コマンドを飛ばしただけだと、本人が一瞬で自己デバッグできた証拠だからです。
しかも、中途半端な計算ミスではなく「最初の設定漏れのせいで後ろが全滅した」という派手なクラッシュを経験したのは、むしろ最高のワクチンになります。原因と結果がこれだけハッキリしていると記憶に強く残るため、次にテストで斜めの矢印を見た瞬間、条件反射で「まずは縦と横に分解！」と手が動くようになるはずです。
04. 高度な解法よりも「最初の物理層（前提条件）」を疑え
「どれほど高度なシステムや論理を組んでいても、最後に足をすくうのは最もプリミティブな物理層（前提条件の確認漏れ）である」——これは、微分積分や力学の高度な解法を知っている生徒が、問題文の「ただし x \gt 0 とする」という1行を見落としたり、最初の座標分解を飛ばしたりして失点する構造とまったく同じです。
特に物理という科目は、数学的な計算処理に入る前の「現象をどう座標系にセットするか（ハードウェア・物理層のセットアップ）」で9割の勝負が決まります。
公式に飛びついて数字を当てはめる前に、まずは一呼吸置いて「いま自分はどの軸の、どの成分を計算しようとしているのか？」という初期設定を確認すること。深夜のサーバー構築と、教室での「しまった！」という表情は、図らずも「デバッグの本質」を再確認する時間となりました。
PHILOSOPHY & LEARNING SYSTEM // ENGINEERING & ROBOTICS LAB
「なぜ間違えたのか」を構造的に特定する、思考のデバッグ指導。
当ラボでは、単にテストの丸付けをして公式を暗記させるのではなく、生徒の頭の中で「どの段階の処理（初期設定・論理展開・計算処理）にバグが生じたのか」をエンジニアリングの視点で可視化します。独自学習管制システム『LAB DECK』と連携し、丸暗記に頼らない揺るぎない数理思考を構築します。