【マイレース開発記録(28)】丸投げしない開発　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

この開発記録では、AIと共同で制作している Webアプリケーション「マイレース（My Race）」 の制作過程を記録しています。

今回は、開発を進める中で意識していた「AIに丸投げしない開発」 という考え方について書いてみます。

AIがコードを書けるようになった今、「AIに全部書かせればいいのでは？」という考え方もあります。

しかし、実際に開発を進めていく中で、私はむしろ 逆の姿勢が大事だと感じるようになりました。

AIはコード生成ツールではなく、検証相手

AIは確かにコードを生成できます。

関数の実装
アルゴリズムの提案
エラーの原因推測
設計の改善案

こうしたことは非常に得意です。

しかし、それをそのまま使うだけでは、コードの理解が自分の中に残りません。

マイレースの開発では、AIから提案されたコードをそのまま使うことはほとんどありません。

必ず次のプロセスを踏んでいます。

• コードを読む
• 何をしているのか理解する
• 実際に動かして確認する
• 必要に応じて修正する

AIは答えを出す存在というよりも、コードレビューをしてくれる相手に近い存在です。

コード理解を優先する

マイレースでは、占星術の計算やレースロジックなど、複数の要素が組み合わさっています。

たとえばバックエンドでは、

• Swiss Ephemeris を使った天体計算
• ユリウス日変換
• トランジットとの角度差
• スピード計算
• レース順位の決定

といった処理が行われています。

AIはこれらのコードを書くこともできますが、それだけでは 仕組みが自分のものにはなりません。

そのため私は、

• 変数の意味を確認する
• 数式の意図を理解する
• どこで値が変化しているか追う

といった形で、必ず一度コードを読み解く時間を取るようにしています。

この作業は時間がかかりますが、理解が深まるほど、後から修正や拡張がしやすくなります。

動作検証を必ず行う

AIが提示したコードは、論理的には正しく見えても、実際の動作とは一致しないことがあります。

そのため、マイレースでは必ず

• 実際に API を叩く
• JSONレスポンスを確認する
• フロント側の挙動を見る

といった形で、動作ベースの検証を行っています。

例えばレースのロジックでは、

Python

finish_times[key] = base_time + finish_bonus(phase)

という計算を使っていますが、数式として正しいだけでは意味がありません。

実際にレースを走らせてみて、

• 順位のバランスは自然か
• 速度差が大きすぎないか
• 直感的に理解できる結果になっているか

といった観点で調整を行いました。

AIのコードは必ず改変する

AIの提案は便利ですが、そのまま使うと プロジェクト全体の設計と合わないことがあります。

例えば今回のプロジェクトでは、

• Flask API
• JavaScriptの非同期通信
• Canvasによるレース描画
• メッセージ生成ロジック

といった要素が組み合わさっています。

そのためAIのコードをそのまま使うのではなく、

• 命名規則を統一する
• 関数の役割を整理する
• 重複コードを削除する

といった リファクタリングを必ず行います。

この作業を通じて、コードが徐々に 自分の設計として整理されていきます。

再現性のある開発を目指す

AIを使うと、一見すると開発がとても速く進むように感じます。

しかし、本当に重要なのは同じ問題をもう一度解決できるかどうかです。

そのため私は、

• ロジックの理解
• 実装の意図
• 動作確認の手順

を意識しながら開発を進めています。

これは少し遠回りのように見えるかもしれませんが、結果的には 再現性のある技術力につながると感じています。

AI時代のエンジニアリング

AIがコードを書く時代になったからこそ、

• 何を作るかを考える力
• コードを理解する力
• 問題を分解する力

がより重要になってきているように思います。

マイレースの開発では、AIを コード生成ツールとしてではなく、

思考を整理するためのパートナー

として使っています。

丸投げではなく、理解と検証を繰り返しながら進めること。

それが、AI時代の開発の一つの形なのではないかと感じています。

次回予告

次の記事は、

【マイレース開発記録(29)】自分の特性と開発スタイル

として、
発達特性と向き合いながら開発を進める中で見えてきたAIとの思考整理のプロセスについて書いていきます。