AI向けのコードは人間には重い説: vibe coding製コードはAI経由で読む

Claude Code や Codex の実用性が上がって、まずAIに実装させる割合がかなり大きくなってきました。明らかに開発速度は上がり、コード品質に関してもマクロな設計は任せられないものの、ミクロな実装については丁寧さの観点でAIの方が上だと感じることも増えています。

一方で、運用を続ける中で別のしんどさも見えてきました。実装が速くなるほど、あとから人間がコードを読んで調整する工程の負荷が目立つようになり、そこが詰まりやすくなっている感覚があります。今回書きたいのは、まさにその点です。

きっかけになった改修

社内で、他のメンバーが vibe coding で作った小規模な社内ツールを少し改修したときの話です。コード品質は高く、ドキュメントも丁寧で、見た目にはとても整っていました。構成もきれいで、雑に作られた雰囲気はまったくありませんでした。

ただ、触り始めると印象が変わりました。プロジェクト規模のわりにコード量が多く、docstring や説明も厚い。変更自体は小さいのに、関連する記述を整合させるための修正範囲が思ったより広く、体感としては「直す」より「読み解いて揃える」に時間を使う感覚でした。品質が低いわけではないのに、メンテナンスは軽くならない。このギャップが強く残りました。

AIフレンドリーとHumanフレンドリーのズレ

このギャップは、「Vibe CodingされたコードはAIフレンドリーであり、Humanフレンドリーとは限らない」ということに気づきました。人間は背景知識や暗黙知を使って最小限を書くことが多いですが、AIは暗黙知を前提にできないため、情報を明示して取りこぼしを減らす方向に寄りやすいです。

その結果、コードやドキュメントは整っていて、AIには扱いやすくなります。ただ、人間が直接読む立場だとプロジェクト規模に対して情報量が多くなりすぎて、軽微な変更でも負荷が大きく感じてしまいます。AI導入で読解とレビューが新しいボトルネックになるとよく言われていますが、これは開発速度が上がったことだけによるものだけではなく、このAIフレンドリーとHumanフレンドリーとのギャップが及ぼす影響も大きいのではないでしょうか。

では我々はどうするべきか

前述の経験の中で得た知見として、vibe codingで書かれたコードは、仕様を確認するだけの場合も含め、基本AI経由で読む・直す運用にするのが良いと感じています。どうしても今までの経験上、綺麗に整ったドキュメントを読みたくなりますが、vibe codingでちゃんと書かれたレポジトリは素直にAIに聞いた方が圧倒的に早いです。

この運用をする上では、チームとして「AIをどこまで信用し、詳細は必要なときに見る」という合意をしておくことが何より重要です。その上で、新たな開発者にもこの運用がわかるようにREADME冒頭に「このリポジトリはAI経由での改修を推奨」と書いておくのが良いでしょう。コードレビューにおいては、細部の品質はAIを信用し、レビュワーはインターフェースの変化など外部プロダクトやチーム活動に影響する仕様部分のチェックに集中することで、チームとしての速度と安全性のバランスを取れるのではないでしょうか。

もちろん、すべて同じ強度でAIを信頼するべきではありません。失敗しても影響が限定的なツールはAI実装を厚めに信頼し、失敗コストが高い領域は人間レビューを厚く維持する。この線引きを先に合意しておくことが、これからのチーム運用では重要になると思っています。

終わりに

Vibe Codingされたコードは実はHumanフレンドリーじゃないよね、ということに気づき記事にしました。最近のAIの進化は凄まじく、我々がコードを直接書かない日は遠くないと感じています。最後に記載したやり方はまだベストな方法とは断言できないですが、今までの習慣としてのコードレビューやワークフローをある程度アンラーニングし、AIを信頼するラインを見極め仕事を手放していくことは、これからより一層重要になってくるのではないでしょうか.