はじめに
現役のトラックドライバーとして物流の現場を走りながら、Pythonを独学しているtosane932です。
物流の現場には 「ハインリッヒの法則」 という考え方があります。1件の重大事故の裏には29件の軽微な事故があり、その裏にはさらに300件の 「ヒヤリハット」 （事故には至らなかったが危なかった出来事）が存在する、というものです。
先日、sales_data_appにpytestとGitHub Actionsを導入する作業をしていた最中、まさにこの 「ヒヤリハット」を3回続けて体験しました。 幸い、どれも実害はありませんでした。ただ、実害がなかったからこそ振り返る価値があると思ったので、記録として残しておきます。
🐧ヒヤリハット①：ターミナルのログが、そのままファイル名になっていた
docker buildを実行した時のログを、確認のためターミナルにそのまま残していました。ログにはこんな行が並びます。
=> [internal] load build definition from Dockerfile
=> => naming to docker.io/library/sales-after:latest
その後、何気なくgit statusを叩いてみたら、見慣れないファイルが並んでいました。
Untracked files:
=
CACHED
[internal]
exporting
naming
resolve
transferring
unpacking
原因を考えて気づいたのですが、ターミナル上で>や=>という記号は、シェルにとってはリダイレクト（出力先の指定）の記号です。ログをコピペする過程か何かのタイミングで、この記号がシェルに解釈されてしまい、その周りの単語がそのままファイル名として生成されてしまっていたようでした。
実害としては空のゴミファイルが8個できていただけで、Gitに登録される前だったので実質ノーダメージでした。ただ、これに気づかずgit add .していたら、意味のないファイルがリポジトリの履歴に紛れ込むところでした。
教訓：git add .のような一括コマンドを打つ前に、必ずgit statusで中身を確認する。
🐧ヒヤリハット②：.gitignoreへの追記が、前の行にくっついていた
Dockerfile.bakのようなバックアップファイルをGit管理から除外するため、.gitignoreに1行追記しようとしました。
echo "*.bak" >> .gitignore
追記できたか確認してみると、こうなっていました。
sales_data_app_android_demo.mp4*.bak
本来は2行に分かれるはずが、改行なしでくっついてしまっていたのです。原因は、追記する前の.gitignoreの最後の行に、そもそも改行が入っていなかったこと。そこにecho >>で追記すると、同じ行の末尾にそのまま連結されてしまいます。
このままだと、Gitはsales_data_app_android_demo.mp4*.bakという1つの奇妙なパターンとして認識してしまい、.mp4ファイルも.bakファイルも、どちらも正しく除外されない状態になっていました。実際、git statusで確認すると、本来無視されるはずの.mp4ファイルがUntrackedとして表示されており、除外が効いていないことが分かりました。
教訓：echo >>で追記する時は、追記後に必ず中身をcatで確認する。ファイルの末尾に改行があるとは限らない。
🐧ヒヤリハット③：書き換えるファイルを間違えかけた
これが3つの中で、一番肝を冷やした出来事です。
pytestのテストコードを改善する作業をしていた時のことです。修正するべきはtest_prompts.py（テストファイル）だったのですが、開いていた2つのファイル（test_prompts.pyと、本体であるprompts.py）の名前が似ていたこともあり、誤って本体のprompts.pyの方を、テストコードの内容で上書きしてしまいました。
幸い、保存した直後に「あれ、これは違う」と気づき、すぐに正しい内容に戻すことができました。実害はゼロです。
ただ、もし気づかずそのままgit pushしていたら、どうなっていたでしょうか。
- 本番で使うはずのGeminiプロンプト生成ロジック（
prompts.py）が、テストコードの中身に置き換わった状態でデプロイされる - アプリが正常に動かなくなる、もしくは意図しない挙動になる
- GitHub Actionsのテストは通ってしまう可能性がある（テストファイルの中身が壊れたわけではないため）
つまり、今回導入したばかりのテストの網をすり抜けて、本番に直接影響が出るタイプのミスでした。テストという点検ゲートを作ったばかりだったのに、そのゲートが検知できない種類の事故だった、という点で、今回の3つの中で一番背筋が冷えた出来事です。
教訓：似た名前のファイルを並行して編集している時は、保存の直前にファイル名を指差し確認する。編集後は必ずgit statusやgit diffで「本当に変更したかったファイルだけが変わっているか」を確認する。
🐧まとめ
3つとも、実害としては何も起きませんでした。ですが、共通しているのは 「気づくのが少し遅れていたら、実際に問題が起きていた」 という点です。
現場のヒヤリハットと同じで、こうした出来事は「防げてよかった」で終わらせるのではなく、なぜ起きたのか、なぜ気づけたのかを振り返ることに意味があると思っています。
- ①は「
git statusを習慣化していたから」気づけた - ②は「追記後に中身を確認する癖があったから」気づけた
- ③は「保存した直後に違和感を覚えたから」気づけた
どれも特別なスキルではなく、一手間の確認があったかどうかの差でした。コードを書く作業も、トラックを運転する作業も、事故を防ぐ最後の砦は、結局はこうした地味な確認の積み重ねなのだと感じています。
（この記事は実際の作業ログに基づいて書いています。）