技術コメントは英語、業務コメントは日本語にする

AIがコードベースを読む時代になったことで、ソースコードのコメント言語にも別の評価軸が生まれた。従来は「読みやすさ＝日本語か英語か」という単純な問題だったが、技術コメントと業務コメントでは役割が違うという指摘は本質的だ。技術コメントとは「なぜこう実装したか」という実装上の理由を説明するもの。一方、業務コメントとは「なぜこの処理が必要か」という業務規則や契約上の判定条件を残すもの。前者は既にコード内で英語が支配的だ。関数名、変数名、ライブラリの概念（timeout、exponential backoff、race condition）はすべて英語で存在する。後者は日本語で定義された要件を反映するべきだ。「申請日が締日の翌日以降の場合は翌月処理とする」という日本の商慣行は、英語に訳して「Process in the following month if application date is after cutoff date」にしても、元の業務ロジックは失われない。だが元の形で留めることで、要件定義書や担当者との対話との直線的なつながりが保たれる。

AIの鬼が指摘すべき点は、この分け方がコードベース全体の「検索可能性」を高めるという点だ。技術語彙を英語に統一すれば、技術的なトラブルシュートは単純なgrepで事足りる。timeout関連の実装を調べるなら「grep -R timeout」だけで十分。技術コメントまで日本語だと、同じ概念について「タイムアウト」「時間超過」「応答待ちエラー」など複数の表記が生まれ、すべてを探す手間が増える。一方、業務コメントを日本語で書くことは、コード内に業務ナレッジの第一次保管庫を作ることになる。要件定義書が古くなったり、担当者が辞めたりしても、コード内に元の日本語が残っていれば、新しいチームもその背景を理解しやすい。AI時代に「検索」と「保存」の双方が効くこの分け方は、むしろ必然だ。

中小企業で内製開発を進めるなら、この指針はそのまま使える。技術コメントを英語に統一することで、ChatGPT等のAIツールが提案するコード片との親和性も上がり、コード補完の精度が向上する。同時に、業務コメントを日本語で残すことで、社内の継承資料としての価値も保つ。両立は可能だし、むしろそうすることで、人間の読みやすさとAIの処理効率の両立が初めて実現する。