typo修正の修正対象「縮退」と「拡張」：スコープ判断のタイミングを誤らない作法

「ジョブ名のtypoを修正してほしい」と AI に頼みました。

第1次調査:「修正対象は YAML コメント文1行のみに縮退」 → 1分で終わる楽勝案件第2次調査:「実は4ファイル + 設定 Label に分散」 → 半日仕事

たった1文字の修正が、スコープ判断のタイミングで大きく工数が変わりました。本記事はその時系列と作法です。

発端：「day6x → day_6x のtypo修正」依頼

データ処理パイプラインのジョブ名が、内部的に day6x と day_6x の2通りで混在していました。

1
# あちこちで見かける2形態
2
_xxxJob_day6x の設定
3
_xxxJob_day_6x.sh

「アンダースコアありに統一したい」という単純な依頼でした。

第1次調査：「縮退」と判断したAI

AI の最初の調査結果。

1
調査結果:
2
- メインのvalidateスクリプト本体: 該当箇所なし
3
- 手順書ファイル: 未作成
4
- 設定ファイル: 未作成
5
- bash スクリプト: 未作成
6

7
結論: 修正対象は YAML コメント文1行のみに縮退しています
8
推奨: 1行修正の小規模PRで対応可能

「縮退」という言葉に違和感を覚えました。

typo が「コメント文1行のみ」に縮退するのは、変ではないか?

ジョブ名を内部で参照しているコードがどこにもないというのは、考えにくいことです。

第2次調査：実は4ファイル + 設定

「念のため別の検索範囲・別のパターンで再調査して」と再依頼。30分後の結果。

1
追加調査結果:
2
- validate_*.sh L1003, L1007 (find パターンに day6x 直書き)
3
- validate_*.sh L1049, L1050 (ログパスに day6x 含む)
4
- .docs/469_*.md L146, L147 (手順書にも記載)
5
- _xxxJob_day6x の設定 (Label が typo)
6

7
修正対象: 4ファイル + 設定 Label
8
推定作業時間: 半日（設定はrelabel 必要）

完全に逆でした。第1次調査は「縮退」と判断しましたが、第2次調査は「拡張」だったわけです。

なぜ「縮退」したのか

第1次調査でAIが見落とした構造的要因を分析しました。

要因1: 検索範囲が狭かった

最初の grep -r "day6x" . は、現在のディレクトリのみを対象にしていました。

validate_*.sh は scripts/ 配下
設定は ~/Library/ 配下
手順書は .docs/

これらが検索対象に含まれていませんでした。

要因2: 「ない」を確証しにくいAI

「該当箇所なし」を根拠なく断言してしまう傾向があります。

1ファイル grep して見つからない → 「未作成」と推論
「他のディレクトリも確認すべき」という仮説を生やさない

要因3: 「縮退」という言葉の罠

AI は「修正対象が予想より少ないとき」に 「縮退」 という言葉を使います。これは「楽になった」という意味合いを含むため、人間も油断します。

しかし実態は 「検索漏れ」 の可能性が高いものです。

スコープ判断のタイミング

修正対象が「縮退」と「拡張」のどちらに振れるかは、最初の調査範囲で決まります。

パターン1: 縮退方向（要警戒）

「思ったより少ない」という結果は、検索漏れの可能性。

検索範囲が狭くないか
別パターンで grep してみたか
ファイル拡張子で絞りすぎていないか

パターン2: 拡張方向（妥当）

「思ったより多い」という結果は、設計時の見積もりが甘かった可能性。

修正対象が予想より多くても、それは事実
スケジュールを再見積もりすべき

縮退方向への警戒スイッチ

「修正対象が予想より少なくなった」と聞いたら、自動で警戒スイッチを入れます。具体的には。

「検索範囲を変えてもう一度確認して」
「別のキーワードでも grep して」
「拡張子を絞らずに検索して」

設定 Label のtypo：別PR切り出し判断

第2次調査で発覚した設定 Label のtypo は、本体ファイル名と独立した問題です。

1
Label: com.example.simJob.day6x  ← typo含む
2
filename: _simJob_day_6x.{ext}    ← 修正済

Label の typo を直すには、

古い Label を unload
設定ファイルを書き換え
新しい Label で load

これは運用手順を伴うため、ファイル名修正PRとは分離する判断にしました。

1
PR #A: ファイル名・スクリプト内 typo 修正（即時可能）
2
PR #B: 設定 Label rename + 再 load（運用手順を伴う、別タイミング）

「スコープを広げる」と「別PRに切り出す」は別物です。広げすぎると1つのPRが巨大化します。修正対象が4ファイル+設定と判明した時点で、即座にPR分離を判断するのが肝です。

教訓：3つの作法

作法1: 「縮退」は警戒シグナル

修正対象が予想より少なくなった場合、まず検索漏れを疑います。確認するまで「楽勝」と判断しません。

作法2: 検索範囲は3階層で確認

階層1: プロジェクトルート
階層2: ホーム配下（~/Library/、~/.config/ 等）
階層3: システム設定（/etc/、/usr/local/etc/ 等）

少なくとも階層1+2は必ず検索します。

作法3: スコープ拡張時は即座にPR分離判断

「対象が増えた」を発見した瞬間に、

1つのPRで全部やる
複数PRに分割する

の判断をします。引き伸ばすと PR が肥大化して衝突しやすくなります。

チェックリスト

typo修正・小規模修正の前に確認します。

grep の検索範囲は十分か（プロジェクトルート以外も含むか）
検索パターンを2通り以上で試したか
「縮退」報告には警戒スイッチを入れたか
修正対象が増えた場合、PR分離を即座に判断したか
設定ファイルなど、運用手順を伴うものは別PRか

まとめ

「修正対象が縮退した」は楽勝シグナルではなく警戒シグナル
検索範囲はプロジェクトルート + ホーム配下 + システム設定の3階層
スコープ拡張時は即座にPR分離判断
運用手順を伴う変更は別PRに切り出す

typo修正の難しさは「修正の難しさ」ではなく「スコープ判断の難しさ」。修正範囲を見誤らないことが、品質と速度を支えます。