なぜ「綺麗なコード」よりも「文脈の通ったコード」がAI時代に勝つのか

この記事でわかること:

• なぜ「綺麗なコード」がAI時代に通用しないのか
• 「文脈の通ったコード」の具体的特徴
• DRY原則と意図的な冗長性のバランス

結論: AI時代は「文脈」が最強の資産

2026年、「綺麗なコード」を追求してきたエンジニアほど、AIエージェントに苦戦しています。理由は明快で、抽象化された美しいコードはAIから見ると文脈が剥がれているからです。これからの時代に勝つのは、多少冗長でも文脈が通ったコードを書ける人です。

「綺麗なコード」の死角

クリーンコードの教科書は「DRY（Don’t Repeat Yourself）」「単一責任原則」「短い関数」を推奨してきました。しかしこれらを過剰適用すると、コードは「抽象の海」になります。AIは抽象を辿るたびに参照を解決する必要があり、推論コストが跳ね上がります。

具体例を挙げます。3箇所で似た処理があるからといって、共通関数processData()に抽出すると、AIは「この共通関数はどの呼び出し元で何のために使われているか」を毎回逆引きしなければなりません。元の3箇所がそれぞれ違うコンテキストで動いていた場合、AIは間違った文脈を引きずって新機能を実装してしまいます。

文脈の通ったコードとは

文脈の通ったコードには3つの特徴があります。

1. 局所完結性

1関数を読めば、その関数が何をしたいか分かります。外部参照を最小限にし、必要な情報は引数で受け取るか関数内に書きます。

2. 意図のコメント

「何をしているか」ではなく「なぜそうしているか」をコメントに残します。AIは「何を」はコードから読めますが、「なぜ」は読めません。

3. 限定的な抽象化

抽象化は3回以上重複し、かつ同じ理由で重複している場合のみ行います。「形が似ているから」程度の抽象化は将来の地雷です。

意図的な冗長性のすすめ

2026年のベテランエンジニアは、しばしば意図的に冗長なコードを書きます。たとえば、メール送信処理を「会員登録」「パスワードリセット」「招待」の3箇所で実装する際、共通化せずに3関数を独立させます。

理由は、それぞれが将来別々に進化するからです。会員登録メールには利用規約を入れたい、パスワードリセットメールには有効期限のロジックを入れたい、招待メールにはテナント情報を入れたい—これらは似て非なる要件です。共通化していると、変更時に他2つに影響しないかを毎回検証する必要があります。AIにこの検証を任せると、3回に1回は壊します。

コメント戦略

AI時代のコメントは「未来のAIへの手紙」だと考えてください。以下のようなコメントが効きます。

// 注: ここで再試行を3回に限定しているのは、外部APIの
// レート制限が10req/分のため。これ以上増やすと429が頻発する。
// 2025-11、PR#1234参照。
const MAX_RETRY = 3;

背景・理由・参照を残すことで、AIは将来「再試行を増やしたい」というリクエストが来た時に、安易に変更しない判断ができます。

移行のコツ

既存の抽象化されたコードを一気にバラすのは現実的ではありません。新規機能から文脈重視で書き始め、既存コードは触る時にリファクタリングするのが現実的です。半年で半分以上のコードが「文脈リッチ」になります。

まとめ

2026年は「綺麗なコード」より「文脈の通ったコード」が勝ちます。DRY原則を絶対視せず、意図的な冗長性を許容し、コメントで「なぜ」を残す—これらの実践が、AIエージェントとの協働を成功させる鍵です。美しさは、AIが追える範囲内でだけ追求しましょう。