老眼でも分かった：AIと作ったプログラムが7,000行を超えたときに起きること

この記事は、FDMで印刷したギヤを測る自作ツール「gear_analyzer」を、AI（Claude）と一緒に育ててきた記録です。ツールそのものの使い方は、取扱説明書の記事にまとめています。シリーズの一覧はこちらです。

はじめに

gear_analyzerは、USB顕微鏡で撮ったギヤの写真から歯形を測るPythonのツールです。最初は写真から歯先の直径を測るだけのスクリプトでした。

AIに機能を足してもらい続けた結果、次のようになりました。

項目	問題に気づいたとき（v141）	整理した今（v144）
本体の行数	6,769行（1ファイル）	7,452行（1ファイル）
別ファイルの部品	6本	6本
サイドバーのボタン	約40個	約40個（説明と早見表つき）

機能は増えて便利になりました。しかし、ある日気づきました。作った本人が、どんな機能が入っているのかを忘れています。

v142〜v144の3回で、使いやすさの改良と重複の整理を行いました。整理したのに行数が増えているのは、ボタンの説明や早見表の文章、整理のための新しい関数が入ったためです。行数を減らすことより、迷わず使え、直しても壊れないことを優先しました。

この記事では、長大になったプログラムで実際に起きた問題と、その直し方をまとめます。

起きた問題

1. 何が入っているか、作った本人が分からない

ボタンが約40個になると、どのボタンが何をするのか、いつ使うのかを覚えていられません。取扱説明書を書き直そうとしたときも、記憶だけで書いた下書きは、実際の機能の半分も拾えていませんでした。

原因：機能を足すたびに説明を更新していなかったこと。機能を足す速さに、覚える速さが追いつきません。

2. AIにもプログラム全体が読めない

AIに改良を頼もうとしたとき、ファイルが大きすぎて、AIが一度に全部を読み込めませんでした。AIは、必要な部分を探しながら少しずつ読むしかありません。

その結果、AIが全体を見ないまま修正を提案する危険が出てきます。ある部分を直したとき、離れた場所にある同じ処理を直し忘れる、ということが起きやすくなります。

3. 同じ処理が何か所にも書かれていた

AIにプログラム全体を調べさせたところ、同じ処理が2か所以上に書かれている例が、いくつも見つかりました。

重複していた処理	書かれていた場所
写真の明るさの診断（白飛び・暗部・二峰性）	解析の本体と、画像を読み込んだときの診断
ギヤの外形と軸穴の中心の求め方	解析の本体と、カメラ映像への重心ずれの表示
歯を切り出して描く処理	「歯形比較」と「歯面拡大」の2つの画面
写真を撮って保存する処理	「キャプチャ」と「繰り返し測定」

困るのは、片方だけが直されて、食い違いが生まれることです。実際に、解析の本体にだけベベルギヤ用の調整が入っていて、カメラの表示側には入っていませんでした。ベベルギヤを撮ったとき、画面に出る値と解析の値がずれる状態になっていました。

原因：AIに機能を頼むとき、「似た処理がもう入っていないか」を確かめずに、新しく書いてもらっていたこと。AIは頼まれたものを、頼まれた場所に書きます。

4. 同じ目的の機能が何種類も並んでいた

目的	入っていた方法
歯形の誤差	旧：半径方向の差／新：歯面に垂直な方向の差
点数	旧：寸法スコアと微分スコア／新：点数v2
圧力角	直線の当てはめ、推定機能、スライダー、傾きの指標の4通り
CSVの保存先	「保存先を変更」と「新しいCSVを開始」

新しい方法を足すとき、古い方法を残したままにしていました。過去のデータと比べるために残すこと自体は正しいのですが、どれを見ればよいのかが分からなくなります。

5. 名前と動きが合わない機能があった

「キャプチャ→解析」というボタンは、実際には写真を撮るだけで、解析はしていませんでした。昔は解析まで行っていたのか、最初から名前だけが先に付いたのか、もう分かりません。

6. 直すと結果が変わる怖さ

長大なプログラムを整理するときに一番怖いのは、計算結果が知らないうちに変わることです。

実際に、このツールの最初の版では、ギヤの中心を「外形の面積の重心」で取っていました。これを「軸穴の中心」に変えたところ、それまでの「樹脂のギヤは圧力角が17°になる」という結論が、測り方の誤りだったと分かりました。

プログラムの小さな変更が、研究の結論をひっくり返すことがあります。

どう直したか

1. 使い方を画面の中に入れる

• ボタンに説明を出す：マウスを乗せると「何をするか・いつ使うか」が出るようにしました
• 早見表：「新しいギヤの出来を見る」「ベンチで比べる」など、やりたいこと別の手順を1枚にまとめ、ボタン1つで開けるようにしました
• 使用回数の記録：各ボタンが押された回数を記録します。使わない機能が分かれば、しまうか消すかを決められます

覚えなくても使える形にするのが、作った本人が忘れても困らない一番の方法でした。

2. 重複した処理を1つの関数にまとめる

明るさの診断、外形と軸穴の求め方、写真を撮って保存する処理を、それぞれ1つの関数にまとめ、どこからも同じ関数を呼ぶようにしました。これで、片方だけ直す失敗が起きなくなります。

3. 古い方法は「旧」として後ろへ移す

旧来の点数は消さずに、画面の下の方の「旧来の点数（過去データとの比較用）」の欄へ移しました。CSVには今までどおり残るので、過去のデータとも比べられます。

4. 整理の前後で、結果が1つも変わっていないことを確かめる

これが一番大事でした。

整理の前（v143）と後（v144）で、同じギヤの写真を、しきい値を変えた4通りで解析し、出てくる約70項目をすべて比べました。解析画像まで含めて完全に一致したことを確かめてから、新しい版に切り替えました。

確かめる仕組みがあれば、整理は怖くありません。確かめる仕組みがないまま整理すると、どこかで結果が変わっても気づけません。

長大になっても困らないために

今回の経験から、AIとプログラムを作るときに気をつけたいことをまとめます。

時期	やること
始めるとき	目的を一文で書く。計算と画面を別のファイルに分ける
作りながら	見本の写真と正しい結果を残し、修正のたびに比べる。版の番号を出力に残す
AIに頼むとき	「似た機能がもう入っていないか」を先に確かめさせる。直す範囲をはっきり言う
定期的に	機能を足す回と同じくらい、整理だけの回を作る。使わない機能をしまう

AIはプログラムを書く速さを大きく上げてくれます。しかし、整理と確認は、こちらから頼まない限り進みません。書く速さに比べて、理解する速さと確かめる手間は、ほとんど変わらないからです。

おわりに

7,000行を超えたのは、AIと一緒なら一人でもここまで作れる、という証拠でもあります。一方で、行数そのものに個人の限界があるのではなく、全体を把握できるかどうかが限界を決めると感じました。

ファイルを役割ごとに分け、確かめる仕組みを持てば、もっと大きくても扱えるはずです。次は、本体を役割ごとのファイルに分ける作業に取りかかります。

老眼でも、書くより整える方が大事だと分かりました。

---

環境

項目	内容
言語	Python（tkinter、OpenCV、NumPy、SciPy、matplotlib）
AI	Claude（ChatGPTにも一部の修正を見てもらった）
対象	FDMで印刷したミニッツ用ギヤ（モジュール0.5、8T・41T）
版	gear_analyzer v141〜v144