こんにちは、ゆうきです。
ある朝、本番が落ちる。
AIに任せてサクッと作った、あのサービスが、です。
データが消えてる、とか。
決済でエラーが出てる、とか。
「うわ、やば」って画面開くんですけど。
……直せないんですよ。
だって、自分でコード書いてないから。
中身、ぜんぜん読めないから。
これ、これから死ぬほど増えると思ってて。
ちょっと今日は、その話をします。
「コードなんて、AIが書くんだから読まなくてよくない?」
こう言うとですね。
「いや、コードなんてもうAIが書く時代でしょ。わざわざ自分で読む必要なくない?」
「読めなくてもAIに聞けばいいし」
って声、絶対出るんですよ。
わかります。
実際、AIにポーンと投げたら、動くもん出てきますからね。
「じゃあ自分で読まなくてよくね?」ってなる気持ち、めっちゃわかる。
でもね。
これ、けっこう危ないんですよ。
AIが書いたコードが、本番で壊れた時の話
さっきの「本番が落ちた」やつ、もうちょい具体的にいきますね。
AIに全部書かせて、動くものができた。
「お、動いてるじゃん。よしリリース」
……で、これが何ヶ月か経って、本番で壊れる。
ある日突然サーバーが落ちる、とか。
データが消える、とか。
で、ここで詰むんです。
だって、自分でコード読めないから。
「どこがおかしいのか、わからない」
「AIに『直して』って言っても、的外れな修正が返ってくる」
「それ適用したら、今度は別のとこが壊れる」
もう、無限モグラ叩きですよ。
自分で書いたわけじゃない。
中身も理解してない。
だから、壊れた瞬間、手も足も出ない。
……これ、僕の知り合いにガチで起きた話なんですけどね。
「AIで作れば、エンジニアいらないじゃん」って言ってた人が、2ヶ月後に「助けてください」って泣きついてきました。
その時の話、こっちに詳しく書いたんで、よかったら。
しかも、AIが書くコードって、けっこう穴があるんですよ
「いやいや、AIが書くんだから、人間より正確でしょ」
って思うじゃないですか。
これがね、そうでもないんですよ。
最近の調査だと、AIが生成したコードの半分近くに、セキュリティの穴があったみたいな話もあって。
AIが「ノリ」で作ったサービスから、ユーザーの個人情報がダダ漏れになってた、なんて事件も普通に起きてる。
なんでかっていうと、AIは「動くコード」は書けるけど、「安全なコード」「運用に耐えるコード」を考えてるわけじゃないから。
とりあえず動くやつを、サッと出してくる。
それを、誰もチェックせずに本番に出したら……まぁ、そりゃ事故りますよね。
で、その事故を防げるのも、直せるのも。
コードを読んで「あ、ここヤバいな」って気づける人だけなんですよ。
「動くコード」と「読めるコード」は、全然ちがう
ここ、大事なんですけど。
AIが出すのは、「動くコード」なんですよ。
「あなたが理解してるコード」じゃない。
ここ、ぜんぜん別物なんですよね。
ローカルで動くのと、それを自分が読めるのは、まったく違う話。
で、読めないコードは、壊れた時に直せない。
だから、AI時代こそ「読める」が効くんです。
AIが書く量が増えるほど、「読んで、ヤバいとこに気づいて、直せる人」の価値が逆に上がっていく。
…で、ここで朗報です。
「コードを読む」って、実力じゃなくて、コツなんですよ。
経験が浅いから読めない、んじゃない。
読み方を知らないだけなんです。
コードが読めないのは、読み方が間違ってるだけ
なんで読むのが遅くなるか。
答え、シンプルで。
みんな「1行目から順番に」読もうとするんですよ。
ファイル開いて、上からimport見て、変数の定義見て、関数の中身見て……。
これやってると、どんどん細部に潜っていって、最後に「で、このファイル結局なにすんの?」って迷子になる。
これ、小説の読み方なんですよね。
小説は1ページ目から読むからいい。
でも、コードは小説じゃない。
コードは地図なんですよ。
地図見る時、左上の角から1mmずつ見ていく人、いないでしょ。
まず全体をバッと見て、「ここが東京、ここが大阪、この線が新幹線か」ってつかんでから、必要なとこを拡大する。
コードもおんなじ。
なのに1行目から読むから、迷子になるんですよ。
速く読むコツは「外側から内側へ」
じゃあ、どうするか。
僕がやってるのは、外側から内側に読むやり方です。
まず、中身を読まない。
最初に見るのは、ディレクトリ構成。
フォルダ名とファイル名だけ。
controllers/ services/ repositories/ って分かれてたら、「あ、ここがAPIの入口、ここがロジック、ここがDB周りか」って、全体像がわかる。
これだけで、1000ファイルあっても「自分のタスクに関係あるの、この辺だな」って絞れる。
次に、関数名とクラス名だけ見る。中身はまだ読まない。
getUserById createUser deleteUser って並んでたら、「ユーザーの取得・作成・削除のファイルね」ってわかる。
1行も読んでないのに、役割がわかるんですよ。
で、ここまで来てやっと、必要な関数の中身だけ読む。
全部じゃない。「今のタスクに関係あるやつだけ」。
この「ディレクトリ → 関数名 → 中身」の順番で読むだけで、体感3倍速くなります。
なんでかって、読まなくていいとこを先に捨ててるから。
1000ファイル中、自分に関係あるのなんて、せいぜい5〜10ファイルですからね。
具体的にやること3つ
明日から使えるやつ、3つ。
1つ目。AIに書かせたコードでも、最初の30分は自分で全体を眺める。
いきなり中身を読まない。ディレクトリ構成だけ眺めて、ノートに5行メモ。
「ここがフロントエンド、ここがバックエンド、ここにAPI定義、ここにDB」くらいでいい。
これがあるだけで、その後の速さが激変します。
2つ目。「このファイル、一言で言うと?」を自分に聞く。
関数名・クラス名だけ見て、「これは○○するファイル」って言えるか試す。
言えなかったら、まだ構造つかめてない。もう一回、外側から見直す。
3つ目。処理の流れは「入口から1本」追う。
「ボタン押したら何が起きるか」を調べたいなら、関係ありそうなファイルを片っ端から開くんじゃなくて、入口から1本の線で追う。
「このURLが叩かれたら、このcontrollerが呼ばれて、このserviceで、このrepositoryでDB問い合わせ」って、縦に1本。
横に広げるのは、後でいい。
AIにレビューさせる時も、結局この順番が効くんですよ
「いや、AIに『このコード、ヤバいとこある?』って聞けばいいじゃん」
って、思いますよね。
半分正解です。
AIにレビューさせるの、めっちゃ便利です。僕も使ってます。
でもね。
AIの指摘を、自分の地図に置けない人は、結局わからないままなんですよ。
AIが「ここ、認証が甘いです」って言っても、「で、それが全体のどこにあって、直すとどこに影響するの?」がわかってないと、判断できない。
AIの言うこと、鵜呑みにして直して、別のとこ壊す。
……さっきの無限モグラ叩きに、逆戻りですよ。
結局、
全体像を自分でつかむ → AIに細部をチェックさせる → 指摘が正しいか自分で判断する
この順番は、AI使っても変わらないんです。
AIは「読む作業」を速くするだけ。
「どこを見るか」「その指摘が正しいか」を決めるのは、自分なんですよ。
ここがわかってる人が、AIを使いこなす。
わかってない人が、AIに振り回される。
AIが量産する時代こそ、読める人が勝手に頼られる
まとめると。
コードを速く読むコツは、全部読もうとしないこと。
外側から内側に。
全体から部分に。
入口から出口に。
この順番、守るだけです。
…で、これ、地味にすごいことが起きるんですよ。
これからAIが、とんでもない量のコードを吐き出す時代になる。
その全部が、ちゃんと安全で、運用に耐えるとは限らない。
むしろ、穴だらけのコードが大量に世に出る。
そうなった時、誰が必要とされるか。
「読んで、ヤバいとこに気づいて、直せる人」ですよ。
技術力がバリバリじゃなくても、いいんです。
AIにぶん投げるだけの人が増えるほど、「読んで、わかって、判断できる人」が、勝手に重宝される。
そうやって頼られる人になると、評価も単価も、後からついてくる。
その「AI時代に頼られる動き方」を、僕の無料メルマガで全部書いてます。
- コードが読める人が、なぜAI時代にこそ重宝されるのか
- 技術力が普通でも「この人いないと困る」って思われる動き方
- AIに振り回される人と、AIを使い倒す人の決定的な差
ブログには書けない、現場のリアルな話です。
気になる人は、以下から登録してください。
コメント