AIが書いたコードを読むか読まないか、という話に少し違和感がある

みなさん、こんにちは！
現役IT執行役員のグイグイです⚡

最近、XでAIコーディングに関する投稿を見ていると、こんな話をよく見かけます。

AIが書いたコードを読むべきか。
読まなくてもいいのか。
レビューするべきか。
しなくてもいいのか。
AIが書いたコードを読めないと、結局修正できないのではないか。

言っていること自体は分かります。AIにコードを書かせる場面が増えている以上、そのコードを人間がどこまで理解するのか、どこまで確認するのか、という話は避けて通れません。

ただ、こういう議論を見ていると、前提が抜けていると感じます。

読むのか、読まないのか。レビューするのか、しないのか。そこだけを切り出して話しても、意味がないと思っています。

大事なのは、AIが書いたかどうかではなく、何を作っているのか、どこまでの品質を求めるのか、その結果に誰がどこまで責任を持つのか、です。

システムやサービスにもレベルがある

AIコーディングの話をする前に、作るシステム側にもレベルがあることを整理しておきます。

• Lv.1　自分用ツール／自分が困るだけ／動けばOK

• Lv.2　プロトタイプ／検証が遅れる程度／早く試せること

• Lv.3　小規模サービス／一部ユーザーに迷惑がかかる／一定の安定性

• Lv.4　社内業務システム／社内業務が止まる・混乱する／保守性、仕様準拠、引き継ぎやすさ

• Lv.5　顧客向け業務システム／顧客業務や信用に影響する／テスト、レビュー、障害対応、運用設計

• Lv.6　社会インフラ系システム／障害が起きるとニュースになる／監査、再現性、可用性、障害耐性、長期保守

同じ「システム」でも、失敗したときの影響はまったく違います。自分だけが使うツールに、社会インフラ系と同じ開発プロセスを持ち込む必要はない。逆に、顧客の業務を支えるシステムを「とりあえず動けばいい」で作るのは論外です。

ここを分けて考えないと、AIコーディングの話はすぐに噛み合わなくなります。

私自身もソースコードを読まないことはよくある

特にLv.1やLv.2の自分用ツール・プロトタイプでは、CursorやClaude Codeなどで「こんな感じで作って」と投げ、生成されたコードをほとんど読まずに動かしながら修正していくことが普通にあります。

自分用のツールや小さな検証であれば、それで十分ですし、そのスピード感に価値があります。

一方で、エンタープライズの現場では全く違ったアプローチを取っています。
ソースコードは見る前提にしつつ、AIにレビューさせて、Checkstyle、SpotBugs、SonarQubeなどの静的解析ツールを導入し、テストコードもAIに生成させています。

その際は、テスト設計の方針を事前に明確にし、C1カバレッジを意識した業務的に意味のあるテストを書かせるようルール化しています。
責任の範囲が変われば、AIの使い方も当然変わります。
特にLv.4以上（社内業務システムや顧客向け開発）では、個人開発と同じノリでは対応できません。そこで重要になるのは、AIが適切に動くための環境づくりです。

具体的には以下のような取り組みが必要です：
•  AIが判断できるように、十分な前提や仕様を渡す
•  AIが逸脱しないように、ルールや制約を明確にする
•  AIの出力を確認できるように、テストやレビューの仕組みを作る
•  複数の開発者が使っても品質がバラつかないように、プロセス全体を設計する
エンタープライズでAIコーディングを使うというのは、「AIにコードを書かせる」のではなく、「AIが迷わず高い品質で出力できる土台を人間が設計する」という話です。

さらに、開発者のレベルが全員同じとは限りません。経験のある人もいれば、まだ慣れていない人もいる。複数の開発者がAIを使いながら一定の品質でアウトプットを出せるようにするには、個人の感覚だけに任せるわけにはいきませんし、チーム開発では品質を均一化するためにレビューは必要でしょう。

ソースを読まないことが良い悪いという話ではなく、背負っている責任の範囲が変われば、AIの生成するコードの見方も変える必要があります。

AIに自由に書かせるだけでは足りない領域がある

個人開発なら、AIに自由に書かせればいいと思っています。その方が速いし、試行錯誤もしやすい。

ただ、エンタープライズ開発になると、AIに自由に書かせるだけでは足りません。これはAIが悪いという話ではなく、人間の開発者でも同じです。

新しくプロジェクトに入った開発者に、何の説明もせず「自由にいい感じに作ってください」とは言いません。開発ルール、設計方針、コーディング規約、レビュー観点、テスト方針、禁止事項、そういうものがあります。

それと同じように、AIに対してもプロジェクトの前提や制約を渡す必要があります。

エンタープライズでAIコーディングを使うというのは、AIにコードを書かせる話というより、AIが迷わない開発環境を作る話です。

• AIが判断できるように、前提を渡す

• AIが逸脱しないように、ルールを渡す

• AIの出力を確認できるように、テストやレビューの仕組みを作る

• 複数人の開発者が使っても品質がバラつかないように、プロセスを整える

ここまで含めて、エンタープライズ開発でAIを使う話になります。

整理するとシンプル

ここまでの話を整理すると、こうなります。

• 個人用ツール（自分だけ）→ バイブコーディング

• プロトタイプ（検証チーム内）→ AIに投げて素早く形にする

• 小規模Webサービス（一部ユーザー）→ AI実装＋人間確認

• 社内業務ツール（社内全体）→ 仕様整理＋AI実装＋レビュー

• 業務システム（顧客・取引先）→ ルール整備＋AI駆動開発

• 社会インフラ系（社会・経済活動）→ AI前提の開発プロセス設計

個人開発の文脈で正しいことが、エンタープライズでもそのまま正しいとは限りません。逆に、エンタープライズの厳密なやり方を、個人開発にそのまま持ち込む必要もない。

作りたいものに求める品質と、背負っている責任の範囲に応じて、手法を選べばいい。ここを分けて考えることが大事だと思っています。

まとめ

AIコーディングの議論は複雑に見えますが、結局はひとつの問いに収束していきます。

自分はその結果に、責任を取れるのか。

責任を取れる範囲なら、自由にやればいい。コードを全部読まなくていい。バイブコーディングで一気に作っていい。AIに任せていい。

ただ、責任の範囲が広がるなら、話は変わります。確認プロセスを設計する。レビューやテストの仕組みを作る。ルールやinstructionsを整える。AIが動く前の構造を設計する。

ソースコードを一行ずつ読まなくても品質を保証できる仕組みを作ることを目指す、そこに価値があります。

AIが書いたコードを読むか読まないか、レビューするかしないか。そういう話も、結局はここに戻ってきます。

作るものは何か。どこまでの品質が必要か。誰に影響するのか。どこまで責任を持つのか。

AIコーディングはもう単なる補完ツールの話ではなく、品質要求と責任範囲に応じて開発手法を選ぶ話になってきている。今の私にはそう見えています。

#AIコーディング
#生成AI
#AI駆動開発
#バイブコーディング
#ソフトウェア開発
#システム開発
#エンタープライズ開発
#品質管理
#コードレビュー
#開発プロセス