AI大活用時代に現場で感じた3つの開発者タイプ

この記事の要約

• 開発者の明確な分化: AI活用が進む開発現場では、開発者が「適切に活用する人」「AIの言いなりになる人」「使いたがらない人」の3タイプに明確に分かれ、それぞれ異なる課題と対応が必要な状況が生まれている

• 技術理解不足による品質リスク: 最も深刻なのは技術理解不足からAI生成コードを無批判に採用する層で、既存コードベースとの整合性を無視し、動作するが品質・保守性・拡張性を損なうコードを量産する危険性がある

• AI消極派の生産性格差: 新技術への関心不足により環境整備や活用スキル習得に消極的な層は、AI前提の工数見積もりや生産性評価において相対的に不利になり、チーム全体の効率化を阻害する要因となっている

• レビュー体制の構造的変化: AI生成コードは機能要件を満たすため従来の動作確認中心レビューをすり抜けやすく、設計意図・一貫性・将来的な拡張性を評価する人間の深い理解と精読がこれまで以上に重要になっている

• 層別対策と基本姿勢: 技術理解不足層には具体的な問題説明と教育強化、消極派には環境整備と段階的導入による効率化実感が有効で、最終的には**「AIは使っても使われるな」**の姿勢でチーム戦略としてのAI活用を推進すべき

はじめに

昨今はCursorに賭けたと思ったらClaudeCodeに賭けたりDevinに（ry

1年どころか数ヶ月で情勢が変わってくる時代です。たまたま会社でもAIｦﾂｶｳﾝﾀﾞｰ活動が盛んなので、なんでも使えるわけではないのですが、GPTやGitHub Copilotをメインで利用してます。

導入して約1年...私の周りもいろんな人がいてくれるおかげで、開発者が大きく3つのタイプに分かれてきてる感じがするなぁと思いカタカタ記事を書きました。多分ほぼ愚痴です（殴

筆者の環境

WEB系の開発チームで数十人規模（その中でいろんなラインに分割していく）。フロントとバック混在のような感じです。既存の基盤があるため、新規開発より運用・既存への改修・修正が主な業務なので、キラキラした世界では一切ないです（無いです

開発者の3つのタイプ

個人的にざっくり分けるとこんな感じ：

1. AIを活用する・興味のある人 - 業務効率化を目指したり、各モデルをなんとなくわかって利用してる層
2. AIの言いなりになる人 - AIが生成したコードを鵜呑みにしちゃう人。めっちゃ危険
3. AIを使いたがらない人 - 新しいものに消極的な人

チーム内でも結構露骨に分かれているので、それぞれが私の目からどのように見えているかを書いていきます。

1. AIを活用する・興味のある人

AIをツールとして使いこなし、プロンプトもちゃんと考えて書けている人たちです。え、そんなの当たり前？と思う皆様は多分この記事は刺さらないです。

何を持って使いこなせるか〜とかは一旦割愛します。私もそんなにAIマスターでは無いので...

2. AIの言いなりになる人

さて、ここからが愚痴本題です。
この層は、AIが生成したコードを鵜呑みにしてコーディング〜PRを作成しレビュワーを泣かせる人を指します。

既存コードとの親和性のなさになぜ気付けない

まず、既存コードとの親和性がめちゃくちゃ低いコードを生み出しがちです。

AIが生成したコードがスタンダードなのはわかるんですが、命名規則等は既存通りに作ってほしい

でもそういうプロンプトの考慮が足りてない、生成されたコードにも違和感を持たない。
「なんで急にsnake_caseで書いてるの？他全部camelCaseだろうが！」みたいなツッコミが毎回...

実際にあった困った例

最近あった例でいうと：

• Loggerを設定してるのに突然コンソール出力のデバッグログを出す
  • あらやだちゃんとLogger設定してるのに、printやconsole.log叩くなんて⭐︎
• ファイルの命名規則が他と比べて合っていない
  • 急にPascalCaseのファイル名が出現したり、Commonの中に専用ロジックがお引越ししたり
• ディレクトリ構造が無駄に冗長
  • 1ディレクトリ1ファイルみたいなのが大量に...拡張性？そんなの無いです
• 処理を書く場所があっちこっち飛んで安定しない
  • 無理に共通化させてたり、と思ったら似たような処理があるのに個別実装したり一貫性がない
• 内製ライブラリを使った実装ができない
  • 横断的に使う内製ライブラリの導入タスクが1からの実装になってたり、不要な処理がてんこ盛りだったり

今までの仕事の振り方では回避できなかった例

とある内製ライブラリ導入を全アプリに適用する必要があるタスクがありました。

既に1~2アプリの導入終わらせていたので、「アプリAのPR通りに、このアプリBにも実装お願い」 とタスクを投げました。内容的に処理はほぼコピペで微調整するだけのタスク、後は検証だけのお仕事だと思ってました。

するとレビューに回ってきた内容はびっくり、参考にしてほしいPRガン無視の実装だったのです...

作業者曰く、「これが一般的な方法だから」と言われてしまいまして、唖然としてしまいました。

根本的な原因は技術理解力不足だと痛感した事例

AIの言いなりになるということは、利用者の技術に対する理解力不足が一番の原因だと思った一番の事例があります。

珍しく新規でAPI構築する案件が発生した時、担当者がAIをふんだんに使ってコードを書いてくれました。新規構築だし、そんなに変なことにはならないだろう！と思っていました。
作成されたAPIはクリーンアーキテクチャを採用しさもナウい感じを醸し出していたのですが、とんでもアーキテクチャが完成されていました。

• ほぼ全てのビジネスロジックがInfrastructure層に鎮座
• Domain層が息をしていない（ファイルがほぼない）
• 1ファイル1ディレクトリで無駄に深い階層構造
• CommonじゃないCommon ※新規構築のアプリです
• 新規構築はエンドポイント2つでシンプル処理なのでそもそもクリーンアーキテクチャである必要性？

書くとキリがないですが、私が見た時には既に完成されたクソコードがそこにありました。

生成した本人はそれを良かれと思って作成しているので、「AIが作ったものをちゃんと確認してくれ！」と言っても多分頭の上に「？」だったと思います。

クリーンアーキテクチャを理解しているのか？と言われると私は自信を持ってわからないと言います。だって難しいんだもの。しかもそれをチームに展開するとなると色んな障壁が（割愛

ちなみに、流石にまずいと思ったのでシンプルな構造にリファクタリングしました

AI生成コードのレビュワー側の問題

上記ツラツラと文句を書きましたが、レビューの段階で弾けるだろ、改善できるだろと思った方もいるかもしれません。実は私、チーム内の別案件でこれらの案件に全ていたわけじゃなく、リリース前にどんなコードになってるのかな〜と興味本位で覗いた時に発覚したものばかりです。

ということなので、次にレビュワー側の問題を書いていきます。

動作確認優先でコード詳細まで把握していなかった

先ほどのクリーンアーキテクチャ(笑)が生成された時、そのAPI自体は動いており、ある程度の検証作業まで完了していました。

つまり機能要件は満たしている状態なので、もし私が文句異論を唱えなければそのままリリースされていたかもしれません...恐ろしや...

つまり、そのクソコードはレビューを通っていたのですﾅﾝﾃｺｯﾀﾊﾟﾝﾅｺｯﾀ

AI生成されるリスクは人間の目でしか弾けない

AI生成したコードは動きはするが今後の拡張性がなかったり無駄に難解なコードになる可能性を多分に含んでいます。

今回のように動作確認だけでは弾けないリスクがあるので、これまで以上にPRの重要性が増すのではないか。と考えます。（ちゃんとレビューしようよ...と言われたら何も言い返せませんが）

勿論、再度Claudeなりに新規で内容を読み込ませてAIによるレビューを通すだけでも人間の負担は軽便します（AIレビューについては後述）。それでも最終的にどのようなコードにしたいかは人間が判断していくものなので、全てAIにやらせる！はまだ無理だなという感覚です。

3. AIを使いたがらない人

新しいものへの関心の低さ

AIｽｺﾞｰｲ界隈ではないですが、この1年で何回も盛り上がりがあったと思います。ここで扱う層はそういった部分への関心が低く興味も薄いようです。
必然的に新しいものが出てきても使おうとしないので、何かと出遅れ感があります。

既存ツールすら活用できてない

この層の一番ダメな部分だと思ってます。

未だにChatGPT等の対話型AIもたまに利用する程度で、プロンプトについての理解があまりない。精度が悪いから使えないでしょ？という先入観がまだあるようです。

興味がないためか、Github Copilotに対応したIDEの更新しておらずそもそも利用できない環境のまま開発をしていたりしていて利用率がかなり低い。

「使えるようになってますよ〜」って言っても「あ、そうなの？」みたいな反応で終わっちゃうことが多かったです。

相対的に仕事が遅くなってることに気付けているのか？

この1年足らずでコーディング支援AIの精度も格段に良くなってきているので、単純な修正や繰り返し作業の多いものはGitHub Copilot利用前提でタスクや工数を引くようになってきました。

なので、こういったAIを利用しない層が相対的に仕事が遅くなってます。工数見積もりの前提が変わっちゃってるから、どうしても差が出ちゃう。

改善への消極的な姿勢

「GitHub CopilotやClaude使ってやってほしい」と言ってみても、「大丈夫だから〜」のようになかなか受け入れてくれないか、使ってみたけど全然使えなかったよ〜のようなフィードバックばかり（使えていないだけだろとツッコミたい...）

かといって、使い方を手取り足取り教えていると気が遠くなります。
自分で調べて改善しようというプロセスがすっ飛んでる感じがして、これはこれで困りものです。

各タイプへの対策・アプローチ

問題を指摘するだけでは意味がないので、それぞれのタイプに対してどうアプローチしていけばいいか考えてみました。完全な解決策ではないですが、少しでも改善につながればと思います。

「AIの言いなりになる人」への対策

ダメなコードの理由をしっかり説明する

なぜこのコードがダメなのか？を理解していないので、そこに対しては労力を使って教えてあげる必要があります。

頭ごなしにAI生成だからダメ！とか、作り直せ！は意味がないどころか同じ過ちを繰り返すだけなので、こういう方法にすればいいよ〜と代替案を示しながら導くのが理想です。

可能であれば、「どんなプロンプト使ったの？」まで踏み込めるといいのかなぁと思います。大体はプロンプトを改良するだけで改善しそうなので。

わからないものをわからないだけで終わらせないで

今までのレビュー返しの時に、「一般的な方法だからこの方法にした」という返答が多かったです。

こういう時は大体、内容を理解していない時なので通常は説明すれば終わりますが、説明を聞かずに、「やり直します」とだけ返答される場合も多々ありました。つまりわからないからやり直せばいいんでしょ？という思考で同じことを繰り返す可能性大です。

そういう時は、しっかりと理解していないものをリリースするリスクについて解くといいのかなと考えます。作成者が理解していないコードほど危険なものはないので、ちゃんと理解するか理解できるコードに置き換えていけるマインドの情勢が不可欠だと思います。

分からないことは質問を促す

理解できないコードを生成してしまった場合は、理解できるよう努めるか、チームメンバーに質問することを促すようにするのも手だと思います。

質問されれば答えてくれる関係を築く必要もありますが、一緒に理解を深められるので win-win です。

【最終手段】わからないものを作るな

この層の一番の欠点は、生成されたコードに対する理解が追いついていないので全てAIが正解だと思い込んでしまう所だと考えてます。その結果、動くから大丈夫〜でクソコード量産体制に入ります。

不明なコードになるくらいなら、コーディング時に自動コーディングはNGとするくらいのマインドが時には必要になるのではないでしょうか。その方が”お勉強”にはなるのかな...

ダメな理由を説明した時に理解してくれれば良いのですが、そこが難しいならレビューのコスト的にもAI任せをさせないようにするしかなと思います。

「AIを使いたがらない人」への対策

環境整備は半強制で

まずはAIを使える環境に更新してもらうことから始めます。これは半強制的にやった方がいいと思います。できることなら、チーム一律で実施するのが好ましいです。

「個人の自由で」としてると、結局更新しない人が出てくるので、チーム方針として「全員更新しましょう」と決めちゃった方が楽です。

少なくもと「環境がないから使えない」はこれで淘汰できる（はず

単純作業から利用促進

環境が整ったら、AIが得意な単純作業系のタスクを振って利用促進を図ります。

「このデータ変換処理、AIなら○○分で終わると思うのでやってみてください」みたいに、具体的な時間を示してタスクを振れればいいかなと思います。最初はそれだけ簡単なものからやってもらって、だんだんとやり方を掴んでいってもらうイメージです。
例えば、定型的にやっているタスク（繰り返し処理やテストデータ作成）あたりから始めてもらいましょう。

効率化の実感から活用へ

一度効率化を実感してもらえれば、あとは放っておいてもどんどん活用できる人になっていくケースが多いです。

「あれ、これもAIでできるんじゃない？」って自発的に考えるようになってくれると、こっちとしても嬉しいですし、チーム全体の生産性も上がります。

その時に、AIに使われるだけの人にならないようにすることにも注意しましょう...難しいですね

まとめ

「AIは使っても使われるな」

結局AIもまだまだ道具なんですよね。いつになったらAIが仕事を奪ってくれるのか...

このビッグウェーブに乗れる人が楽をし、乗れない人が苦しむ世の中になっていくので、頑張って楽をしたいですね。