はじめに

先日、このLT資料を読みました。

AI時代の兎と亀 - miso_taku

童話の兎と亀になぞらえて、AIの使い方でエンジニアが二極化していく話です。これがめっちゃ良かった。スライド自体は数分で読めるので、まず原典を読んでほしいです。

この記事は要約じゃなくて、読んで自分が考えたことを書きます。

ざっくりだけ書いておくと、こういう対比です。

兎エンジニア：AIを「丸投げ業者」として使う。速いけど、理解が残らない
亀エンジニア：AIを「家庭教師」として使う。遅いけど、理解が積み上がる

で、普通ならここで「よし、亀になろう」で終わる話なんですが、自分はこれを読んでエンジニアの外側のことを考えてました。兎エンジニアの構造をそのまま延長した先に、非エンジニアのバイブコーダーがいるんですよ。マネージャーとしては、正直こっちのほうが怖い。

まず刺さったのは「共犯関係」の話

資料の中に、兎エンジニアは組織と個人の共犯関係で構造的に生まれる、という指摘があります。

組織は速く多く出してほしい。個人は早く終わらせて評価されたい。どっちの動機も、それ単体では完全に合理的なんですよ。誰にも悪意がない。ないのに、その2つが噛み合った結果として兎が量産される。

これを読んだとき、「うわ、これ自分やん」と思いました。

自分はいまエンジニア組織のマネージャーをやってるんですが、この構図でいう「組織側の論理」を回してるのは、まさに自分の立場なんですよね。ベロシティを見て、納期を気にして、速く出してくれる人を「助かる〜」と思ってしまう。悪意ゼロで、兎に報酬を払う側に立ってる。

そしてこの共犯関係、恐ろしいことにエンジニアの枠の外でも全く同じ構造で回ります。

兎の極北：非エンジニアのバイブコーダー

いま、AIのおかげで非エンジニアでも「動くもの」が作れるようになりました。企画職がツールを作る、営業が業務スクリプトを組む、それ自体はすごいことだし、止める理由もないと思ってます。

ただ、兎と亀の枠組みで見ると、**非エンジニアのバイブコーダーは構造的に「純度100%の兎」**なんですよ。

兎エンジニアには、まだ最低限の土台があります。読もうと思えばコードが読めるし、レビューを受ける文化の中にいるし、「本番」「個人情報」「権限」といった単語に対する恐怖心もある。理解をサボってるだけで、理解する回路自体は持ってる。

非エンジニアのバイブコーダーには、その土台がないです。これは能力をバカにしてるんじゃなくて、単に職業訓練の話です。

コードを読めないので、「動いたからヨシ」以外の検証手段を持っていない
何が危ないかを知らないので、確認すべき項目のリスト自体が頭にない（SQLインジェクション、権限設定、個人情報の扱い、シークレットの管理…）
レビュー文化の外にいるので、誰のチェックも通らずに動き始める
そして壊れたとき、本人にもAIにも直せない

しかも、です。ここが一番強調したいところなんですが——

それでも動くものが出てくる限り、評価はされるんですよ。

「営業のあの人、AIでツール作ってて業務効率化がすごい」。この評価、間違ってないんです。実際に速いし、実際に役に立ってる。スピードと成果物は目に見えて、リスクと理解の欠如は目に見えない。だから称賛だけが積み上がって、作られたものは増え続ける。

その結果どうなるかというと、

社内のあちこちで「誰も中身を知らないもの」が動き始める
作った本人は説明できない、エンジニアは存在すら知らない
障害・データ漏洩・不正な挙動が起きて、初めて発見される
そのとき、直せる人がいない

スピードは評価される。でも中身は空洞。そして誰も管理できない。 これが兎エンジニア問題の、組織全体スケールでの完成形だと思ってます。

原典に「兎しかいない組織は意思決定能力を失う」という話がありますが、非エンジニアのバイブコーディングが野放しの組織は、意思決定能力を失う前に、そもそも自分たちが何を動かしているのかを把握する能力から失っていきます。棚卸しすらできない。

「亀がサボって見える」問題は、ここでも効いてくる

マネージャーとして原典で一番ぐさっと来たのは、亀の「理解に時間をかけた」は成果として見えにくくて、マネージャー視点では亀のほうがサボって見えるという指摘でした。

……見えるんですよ、実際。ぶっちゃけ。

で、この構造は非エンジニアのバイブコーディングが加わると、さらに悪化します。比較対象が「兎エンジニア vs 亀エンジニア」じゃなくて、**「AIで一晩でツール作った非エンジニア vs 設計の理解に一週間かけたエンジニア」**になるからです。

経営層から見たら、前者のほうが輝いて見えて当然です。「非エンジニアでもこれだけできるのに、エンジニアは何をやってるの？」——この問いが出てきた時点で、亀の評価はもう詰んでます。理解のコストが、コストとしてすら認識されてない。

だから、これは啓蒙で解ける問題じゃないです。構造が兎を作ってるので、構造を直すしかない。

じゃあマネージャー側で何ができるか

自分が意識してること・やろうとしてることを書きます。個人の意識に頼る仕組みはだいたい負けるので、制度側の話が中心です。

1. 「禁止」ではなく「線引き」にする

非エンジニアのバイブコーディングを禁止するのは、たぶん悪手です。便利なものは地下に潜るだけで、シャドーIT化して余計に見えなくなる。

なので「誰が作るか」じゃなくて、「作ったものがどこで動くか」で線を引くのが現実的だと思ってます。

使い捨て・検証・個人の作業効率化 → 自由にやってOK。むしろ推奨
継続的に運用される／他人が使う／個人情報や決済に触れる → エンジニアのレビューと運用責任の引き受けが必須

ポイントは、右側に入った瞬間に「作れるかどうか」ではなく**「壊れたとき誰が直すか」「事故ったとき誰が説明するか」**の問題に変わる、ということです。コードの品質の話にすると「動いてるじゃん」で押し切られるので、運用責任の話として線を引くのが通りやすいです。

2. 「作業の速さ」と「待ち時間」を分けて見る

「AIがあるんだから開発はもっと速くなるはずでは？」と言われること、あると思います。このとき、手を動かしてる時間と着手されるまでのキュー待ち時間を分けずに「速度」を語ると、話が噛み合わないんですよね。

体感の「遅い」は、たいてい後者です。ここを混ぜたまま議論すると「もっと兎になれ」という圧だけが残るので、まず分けて可視化するのが先やなと。

3. 理解のコストを工数として計上する

亀の弱点って、成果が出ないことじゃなくて、成果として計上する枠がないことだと思うんですよ。

「調査」「設計の理解」「レビュー」を工数の一級市民として扱わない限り、それは永遠にサボりに見えます。特にバイブコーディング製のものをエンジニアが引き取ってレビューする時間は、ちゃんと工数として見えるようにしないと、エンジニアがタダで尻拭いをする構図になります。ここが崩れると、亀から先に辞めていきます。

4. レビューを「動作確認」から「理解の検算」に戻す

AIが書いたコードのレビューで一番危ないのは「動いてるからLGTM」です。これをやるとレビュアーまで兎になる。

レビューで見るべきは動作じゃなくて、こっちだと思ってます。

なぜこの実装を選んだのか、著者が説明できるか
他の選択肢を検討した形跡があるか
変更したときに壊れる範囲を把握してるか

つまりレビューは、書いた人が理解してるかを確かめる場。コードの品質はその副産物でいい。

5. 「AIに聞き返す」をチームの標準作法にする

原典で紹介されてた質問例がすごく良かったので、そのまま使わせてもらってます。

- このコードを一行ずつ、なぜそう書くのか説明して
- この設計のトレードオフを3つ挙げて
- 私の理解が正しいか、逆に質問して確かめて

特に3つ目が強い。AIに説明させるんじゃなくて、AIに試問させる。自分の理解の穴って、自分では見つけられないんですよね。

これ、実は非エンジニアにこそ配りたい作法です。コードは読めなくても「このツールが扱うデータで、漏れたらまずいものは何？」「これが壊れたら誰が困る？」とAIに聞くことはできる。理解の完全な代替にはならないけど、「動いたからヨシ」よりは何段もマシです。

「思考は外注できるが、理解は外注できない」

資料の中で一番効いた一文がこれでした。

AIに任せられるのは思考の結果だけで、理解そのものは自分の頭を通す以外に手に入らない。

これ、能力の話というより情報の経路の話だと思ってます。他人が長い時間かけて出した結論は1秒で受け取れるけど、その過程で捨てられた選択肢の情報は結論に含まれてない。で、実務で効くのはだいたい捨てられたほうの情報なんですよね。

「なぜAじゃなくてBなのか」を説明できない人は、状況が変わってAが正解になったときに気づけない。障害対応って、まさにこの「状況が変わった瞬間」の連続なので。

とはいえ、将来のことは分からん

原典が最後に正直に書いてた点も好きでした。

電卓が出たとき「そろばんを使わないと計算力が衰える」と言われた。実際衰えたかもしれないけど、別に困ってない。同じことがコーディングでも起きる可能性は普通にあります。

自分も3年前は、仕事のコーディングをAIに任せられるとは思ってなかったです。今は普通に任せてる。なので5年後に「レビューも運用もAIがやるから人間の理解は不要」になってる可能性、正直ゼロとは言えない。

だからこの記事は「亀が正義」「バイブコーディングは悪」という主張ではないです。現時点では、理解を捨てた側から先に、自分が何を動かしているのか分からなくなる、という観察です。

ただ、個人のスキルは学び直せますけど、組織が「把握できてないまま動いてるもの」を棚卸しして管理下に戻すのは、めちゃくちゃ時間がかかります。だから少なくとも自分の見てる範囲については、線を引く側に回ってます。

おわりに

AIは優秀で、これからも賢くなる。それを優秀な丸投げ業者として使うか、優秀な家庭教師として使うかは自分次第——というのが原典の結びでした。

これに一つ付け足すなら、この問いはもうエンジニアだけの問いじゃないです。AIで誰でも作れる時代は、誰でも兎になれる時代でもある。スピードは勝手に評価されるので、放っておくと組織は空洞化した「動くもの」で埋まっていきます。

だからこそ、理解に賭けることが合理的になるように評価と線引きを設計するのがマネージャーの仕事だと思ってます。個人の意識に賭ける仕組みは、だいたい構造に負けるので。

良い資料をありがとうございました。

参考