🚛学習100時間のトラックドライバーが、自分のFlaskコードの積載ミスを9つ発見して全部直した話📦

Last updated at 2026-07-16Posted at 2026-06-28

🚛学習100時間のトラックドライバーが、自分のFlaskコードの積載ミスを9つ発見して全部直した話📦

筆者について

物流現場7年の現役トラックドライバー。IT実務経験ゼロ。
2026年5月12日、13年前のPCにLinuxを入れてPython学習を開始。
独学100時間で自分が作ったシステムを見直した話をします。

GitHubはこちら👈️

最新版デモ映像はこちら👈

なぜコードを見直したか

「作って終わり」が嫌だった。

中身の無い新しいものを量産するより、一つのシステムを本当に使えるレベルまで突き詰めたかった。Qiitaの過去記事も誤字を見つけたら直す。ミニ四駆×Pythonの記事は3〜4回修正した。コードも同じだと思っている。
日々の業務でも

「この積み方で本当に出発していいだろうか？」

と疑り深くなっている。
コードを書くときも同じ癖が出る。
職場の事故の大半は「だろう運転」から生まれる。

「止まってくれるだろう」「大丈夫だろう」

大切なのは「かもしれない運転」だ。バック中に後ろを確認する、初めての環境では降りて目視する、車間を空ける、商品を固定する。全て対策が打てる。

コードも同じだった。

・「動いてるから大丈夫だろう」→debug=True が本番に残っていた。
・「使わないけど消さなくていいだろう」→不要なimportが積み上がっていた。
・「入力値は正常だろう」→バリデーションが抜けていた。
「だろうコーディング」が積載ミスを生む。
「かもしれないコーディング」で防げる事故はかなりある。それを現場で知っている。

では、職場の事故はどうやって防ぐか。
小さいミスが何度も重なると大きな事故に繋がる。「積み卸し忘れ・積み卸し間違い・商品破損」これら単体なら復旧は早い。

でも車両事故になると話が変わる。
「安全確認、車両移動、警察への連絡、情報交換、積み替え、遅延連絡」——復旧にとんでもない時間がかかる。 責任問題 にも 信用問題 にもなる。

コードも同じだ。debug=True の本番残留、不要なimportの放置、バリデーションの欠如。一つひとつは小さい。でも本番環境で重なったとき、復旧コストは跳ね上がる。だから小さいミスを潰す。

完璧なものなんて存在しない。常に環境をアップデートする意識が必要だ。

車検を受けたから安心、とはならない。ボルトが緩んでいるかもしれない。修理を頼んでも直っていないかもしれない。だから毎日自分で車両点検する。ダブルチェックする。

コードも同じだ。「完成した」と思った瞬間 が一番危ない。

*Photo by Graficon Stuff on Unsplash

積載ミス1〜6（最初のレビューで発見）

積載ミス1：関数の「積み残し」

build_sales_prompt という関数が、app.pyとprompts.pyの2箇所に存在していた。prompts.pyは誰にも使われていない状態で放置されていた。

【原因】：荷解き前の積み残し
関数をprompts.pyへ引っ越しさせた段階で満足してしまい、app.pyの古い関数を消し忘れた。「コピーして動いたからヨシ」という「だろうコーディング」だった。

【対策】：荷降ろし後の目視確認
「古いものは消したか？」「新しい接続先に切り替わっているか？」をセットで確認する。荷を降ろしたら荷台が空になったか目視確認するのと同じだ。

# 修正前：app.pyにも同じ関数が存在していた
def build_sales_prompt(sales_summary: str) -> str:
    return f"..."

# 修正後：prompts.pyからimportするだけ
from prompts import build_sales_prompt

積載ミス2：実験場の片付け忘れ

本番用のtemplatesフォルダの中に、JavaScriptの非同期通信を練習するために作ったjs_test.htmlが残っていた。ユーザーが触る本番環境に不要なゴミファイルが混入している状態だ。

【原因】：目的達成と同時に頭が切り替わった
「まず動くか試したい」という気持ちで本番フォルダ内に実験ファイルを作った。非同期通信の実装が成功した瞬間、頭が次のタスクへ切り替わり、実験場の片付けが抜け落ちた。動いた安心感のまま放置された。

【対策】：気づいた時点で即削除
不要になった実験ファイルはその場で削除。今後は本番フォルダに実験用のファイルを直接作らず、確認が終わったらすぐ消す習慣をつける。

積載ミス3：デバッグモードの「消し忘れ」

app.run(debug=True) のまま本番環境に公開しそうになっていた。デバッグモードが有効な状態でエラーが起きると、システムの内部コードや重要な情報が画面に丸見えになる。セキュリティ上、最も危険な積載ミスだった。

【原因】：「決まり文句」になっていた
開発中はエラーの原因が画面に表示されるdebug=Trueの恩恵を100%受けていた。そのため app.run(debug=True) が「アプリを起動するための決まり文句」になってしまい、本番へ持っていく段階でオフにする意識が完全に抜け落ちた。

【気づいたとき】：
「もしこのまま誰かに使われてエラーが出たら、システムの裏側が全部丸裸になっていた」。ゾッとした。

【対策】：人間の消し忘れに頼らない仕組みへ
環境変数で制御し、本番では自動的にデバッグモードがオフになる設計に変更した。

# 修正前
app.run(debug=True, host="0.0.0.0", port=5000)

# 修正後
debug_mode = os.environ.get("FLASK_DEBUG", "false").lower() == "true"
app.run(debug=debug_mode, host="0.0.0.0", port=5000)

積載ミス4：新旧の「二重積載」

PostgreSQLへの移行が完了したにもかかわらず、Excelへ書き込む古い処理がコードの中にそのまま残っていた。データが2箇所に分かれる中途半端な状態で、「どちらのデータが正しいのか」が分からなくなる原因になる。

【原因】：お守り代わりに残していた
「今まで動いていたExcelの処理を消してしまうのが怖かった」。PostgreSQLへの保存が成功した安心感のまま、もう必要のないExcelの処理を削除するという最後の仕上げを後回しにした。

【対策】：Gitを信じて思い切って削除
バージョン管理があれば、いつでも戻せる。古いコードはお守りではなく、邪魔な荷物だ。移行が完了したら迷わず削除する。

# 修正前：ExcelとDBが並走していた
generate_excel(year, month, products_data)  # 削除
get_filtered_sales_data(target_year, target_month)  # 削除

# 修正後：DBだけに一本化
_get_sales_from_db(target_year, target_month)

積載ミス5：年度の「賞味期限切れ」設計

dashboard.htmlの年度セレクトボックスに「2025」「2026」「2027」が直書きされていた。2028年になった瞬間、手動でコードを書き換えないとシステムが使えなくなる設計だった。

【原因】：「今動けばヨシ」という視点
開発時点では2025〜2027年のデータが表示されていれば完璧に動いた。「未来の年度になったらどうなるか」という保守性の視点にまで頭が回らず、「とりあえず動くからこれでヨシ！」と直書きのままにした。

【対策】：現在の年を基準に自動生成
Pythonで現在の年を取得し、Jinja2のループで動的に選択肢を生成する仕組みに変更した。手動での書き換えが不要な「寿命の長いシステム」になった。

<!-- 修正前：直書き -->
<option value="2025">2025年</option>
<option value="2026">2026年</option>
<option value="2027">2027年</option>

<!-- 修正後：動的生成 -->
{% set current_year = now.year %}
{% for y in range(current_year + 1, current_year - 3, -1) %}
<option value="{{ y }}">{{ y }}年</option>
{% endfor %}

積載ミス6：不要な荷物の「積みっぱなし」

requirements.txtにGoogleのAI用ライブラリが新旧2つ混在していた。不要なライブラリが残っていると、インストールに無駄な時間がかかるだけでなく、バージョン衝突でシステムが動かなくなるリスクがある。

【原因】：pip freeze でそのまま書き出した
AI機能の導入時に複数のライブラリを試した。正解のライブラリが判明して動いた後、pip freeze > requirements.txt で一覧をそのまま書き出したため、実験段階で入れた古いライブラリまで一緒に混入した。

【対策】：使わなくなったらその都度アンインストール
ライブラリを変更した際は pip uninstall で即削除してからリストを更新する。積んだ荷物は降ろしたか、必ずその都度確認する。

# 修正前：新旧が混在
google-genai==2.4.0
google-generativeai==0.8.6  # 不要

# 修正後：必要なものだけ
google-genai==2.4.0

*Photo by Alghogy on Unsplash

積載ミス7〜9（Geminiに指摘された）

積載ミス7：思い入れのある荷物の「積みっぱなし」

PostgreSQL移行が完了し、Excelからデータを集計する必要がなくなったにもかかわらず、auto_aggregator.pyがフォルダに残っていた。ミス4の「ファイル丸ごと版」だ。使われていない過去の遺物がプロジェクト内に放置されている状態。

【原因】：サンクコスト（未練）
このファイルは、データベース導入前に一生懸命作って実際に動いていた思い入れのあるコードだった。「もう使わない」と頭では分かっていた。でも「せっかく頑張って書いたから念のため残しておきたい」という気持ちが働き、フォルダの隅に眠らせてしまった。

【対策】：Gitに預けて、現場は一軍だけ
過去のコードはGitの履歴の中に美しく保存されている。現在の作業フォルダは常に「今必要なものだけ」にするスクラップ＆ビルドを徹底する。

積載ミス8：異物検品ゼロの「無防備な荷受け」

日次売上入力フォームで、マイナス値や文字列が入力されてもエラーにならずそのままDBに保存される状態だった。売上合計がおかしくなったり、システムが予期せぬエラーで止まったりする原因になる。

【原因】：「自分ルール」でしかテストしていなかった
自分で作った画面なので、テスト時も正しい数字しか入力しなかった。「他人が触ったらマイナスを入れるかもしれない」「変な文字を送信するかもしれない」という想像が完全に抜け落ちていた。「だろうコーディング」の典型だ。

【対策】：二重の検品体制
異物が混じった原材料は、検品で絶対に工場内に入れない。それと同じ体制を整えた。

HTML側：min="0" や required でマイナス値・空欄を送信不可に
Python側：それでもすり抜けてきた値をDBの手前で弾く最終防衛線を実装

# 修正後：二重チェック
try:
    qty_int = int(float(quantity))
except ValueError:
    continue
if qty_int < 0:
    continue

積載ミス9：出発前の「積載確認ゼロ」

アプリ起動時に必要な環境変数（APIキーなど）が揃っているかチェックする仕組みがなかった。設定を忘れたままアプリが起動し、ユーザーがボタンを押した瞬間に初めて致命的なエラーが起きる設計だった。

【原因】：自分の環境では「いつでも動くのが当たり前」だった
自分のPCには一度環境変数を設定してしまえばいつでも動いた。「別のPCへ持っていったとき」「本番サーバーに配置したとき」に設定が漏れるかもしれないという想定が完全に抜け落ちていた。

【対策】：出発前に積載確認する仕組みを実装
トラックが出発する前に積載確認をするように、アプリが起動した瞬間に必要な環境変数が全部揃っているか自動チェックする。1つでも足りなければ即座に起動を停止する。「動かしてから気づく」ではなく「起動時に1秒で検知する」設計に変えた。

# 起動時に一括チェック（Fail-Fast）
_required_env_vars = ["GEMINI_API_KEY"]
_missing = [var for var in _required_env_vars if not os.environ.get(var)]
if _missing:
    raise RuntimeError(f"起動に必要な環境変数が設定されていません: {', '.join(_missing)}")