「Claude Code導入してから、若手の質問が減って、PRがめちゃくちゃ通るようになった」
これは2025年末、僕がうちのリードエンジニアから受けた報告だ。生産性が上がっている。新人の立ち上がりも早い。最高じゃないか、と当時の僕は思った。
半年経った2026年春。同じ若手と1on1をやっていて、ふと気づいた。
「このPR、なんでこの設計にしたか説明できる?」
返事が、揃わなかった。コードは動く。テストも通っている。でも、なぜそうしたかが、本人の言葉で出てこない。Claude Codeが書いた設計を、ほぼそのまま採用していたからだ。
2つの研究が、この不安に具体的な数字を突きつけた。ひとつはMETR（Model Evaluation & Threat Research）が2025年に行ったランダム化比較試験で、経験豊富な開発者でも、AIエージェントを使うと作業が平均19%遅くなるという結果。もうひとつはAnthropicが2026年初頭に発表した「How AI Impacts Skill Formation」で、AI支援ありで学んだエンジニアは、課題後の理解度テストのスコアが17%低かった――開発スキルの習得そのものが落ちる、というシグナルだ。
AIを使うのか、それとも技術力を残すのか。今日は、17人のITコンサルを回している僕らが、両立のために組織制度として組み込んだ「AI依存防止の3仕組み」を、正直に書いておきたい。
2つの研究の中身: 「19%遅くなる」「17%スキル習得低下」が示す本当のシグナル
METRの研究は、エンジニアの界隈で2026年初頭にちょっとした騒ぎになった。
直感的には、AIを使えば開発は速くなる。Claude Code、Cursor、Devin、GitHub Copilot――どれを使っても、ボイラープレートを書く時間は確かにゼロに近づいた。だが、METRが行った実証実験では、経験豊富な開発者がAIエージェントを使用したタスクは、AIなしのときと比べて平均19%遅かったという結果が出た。
理由は単純で、AIが提案するコードのレビュー時間、AIが間違えたときの修正時間、AIに「何をやってほしいか」を伝えるブリーフィング時間――これらの合計が、自分で書くより重くなるケースがある、という話だ。
そして、もっと痛い指摘が、Anthropicが2026年初頭に発表した別の研究「How AI Impacts Skill Formation」だ。現役エンジニア52名を2グループに分けてコーディング課題に取り組ませたところ、完了時間にはほぼ差がなかった（AI支援あり約23分／なし約24分）のに、課題後の理解度テストではAI支援ありグループのスコアが17%低かった。しかもこの差は経験年数に関わらず全レベルで観測され、最も差が開いたのがデバッグ力だった。AIがエラーを解消してくれるぶん、「自分でエラーに向き合い、原因を突き止める」経験そのものが減り、判断の筋肉が育たない、というメカニズムらしい。
これは、Claude Codeを毎日使っている僕自身も心当たりがあった。テストコードのバリエーションが、自分の頭の中から減っている気がする。配列処理のループの書き方を、AIに先に書かせるのが当たり前になってから、ふと手が止まる瞬間がある。
研究結果がそのまま現場に当てはまるかは慎重に見るべきだが、肌感としては「あり得る」と思った。だから、僕らは半年前から「AIを使う組織であるほど、技術力を構造で残す仕組みが要る」という前提で動き始めた。
（出典：METR『Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity』2025年／Anthropic『How AI Impacts Skill Formation』2026年。いずれも経験者を対象にしたランダム化比較試験。）
K.Platinumの17人組織で、半年で起きていた「静かな技術力流出」
うちは2026年初頭の段階で、Claude CodeとCursor、Devinを実務で使い分けている（このあたりの話は COMPANYBLOG-49 AIエージェント3つ使い分け と COMPANYBLOG-60 AIブリーフィング に書いた）。
定量的に見ると、AIエージェント導入後の3〜4ヶ月で、こんな変化があった。
- PR数は1.6倍に増えた
- ボイラープレートの実装時間は3分の1に短縮
- 新規メンバーの初PRまでの日数は7日 → 3日に短縮
数字だけ見れば「導入大成功」だ。だが、半年経って、僕らが気にしはじめた質的な変化はこんな感じだった。
- ペアプロ中、AIが書いたコードについて「なぜこの書き方?」と聞くと、若手だけでなく中堅も詰まる
- レビュー時の議論が「設計の選択肢」から「AIが出した結果でいいか」へシフト
- 障害対応で、エラーログを読まずにいきなりAIに貼り付ける動きが増えた
- 新人が「AIなしでログを追う訓練」を経験しないまま、PRを通すようになっていた
どれもPR数や納期には現れない、静かな流出だ。2つの研究が警告していたのは、まさにこれだ、と思った。
放っておくと、3年後の組織には「AIに発注はできるが、AIが死んだら何もできない」エンジニアだけが残る。これは、僕らのMVV「CHANCE, CHANGE, CHALLENGE」（COMPANYBLOG-20で書いた）と決定的にズレる。「変化に挑戦する」会社が、変化に乗りすぎて技術力を捨ててしまうのは、本末転倒だ。
仕組み①: 週1の「AI禁止デー」 — コードを書く筋肉を意図的に取り戻す日
ひとつめは、組織としての「AI禁止デー」だ。
毎週1日、Claude Code・Cursor・Devin・GitHub Copilot、全ての自動コーディング支援を切る日を作っている。タスクとしては「自社プロダクトの小さな改善」「社内ツールのリファクタ」「個人学習のコードを書く」など、顧客案件を止めない範囲のもの限定だ。
ルールは3つだけ。
- AI支援系のIDE拡張・CLIは全部OFF
- 検索エンジンとドキュメントはOK（人間の調べ物は禁止しない）
- 「今日書いたコードを言語化して翌日のスタンドアップで共有」
最初の2ヶ月、社内では「これ、業務時間使うほどか?」という議論があった。やってみると、効果はじわじわ出た。
- 「ループの中で何を書いてるか」を自分の頭で再確認できる
- アルゴリズムの選択肢を、検索ではなく自分の引き出しから出す訓練になる
- 「AIに頼んで5分で書けるコード」を「20分かけて自分で書く」ことで、新人にレビュー観点が戻ってきた
これは「AIを否定する日」ではない。AIを使うときに、ちゃんと判断できる人間を作るための筋トレ日だ。週5のうち4日はフルにAIを使い倒す。残り1日だけ、人間側の筋肉を錆びさせない。
「AIが止まったらどうしますか?」という顧客からの質問にも、自信を持って答えられるようになった。
仕組み②: PRレビューは「コードを言葉で説明できるか」をフィルタにする
ふたつめは、PRレビューの観点を変えた。
以前は「コードが動くか/テストが通るか/設計がきれいか」をレビュー観点にしていた。これだと、AIが書いたコードを「読まずに承認する」流れが組織で発生する。だから、観点を1つ追加した。
「このPRの設計を、口頭で30秒以内に説明できるか」
レビュー時、PR作成者がオンラインで設計の意図を口頭で説明する。AIが書いたコードでも、自分の言葉で「ここは正規化のためにあえてこの順序にした」「この型はあとで拡張する余地を残した」と説明できれば、合格。
詰まったら、その場で書き直す or もう一度AIにブリーフィングし直す。
これを始めて1〜2ヶ月、社内で起きた変化はこんな感じだ。
- AIが出したコードを「うのみにする」癖が消えた
- レビュー時間は確かに長くなった（10〜15分プラス）が、レビュー後の手戻りは半分以下
- 「AIが書いたから自分は知らない」という空気が完全に消えた
これは1on1や評価制度と組み合わせて初めて回る。レビューだけでなく、月次の1on1で「今月、自分の言葉で説明できなかったコード」を振り返るセッションを入れている。
短期で見るとコストが上がる仕組みだ。だが3年後の組織を想像したとき、「AIに発注はできるが、AIなしで何もできない人」を作らないために、ここはコストを払う価値がある、と僕は判断している。
仕組み③: ペアプロをAI込みで可視化する — 「AIに任せた部分／自分で書いた部分」を分けて記録
みっつめは、ペアプロの記録のとり方を変えた。
うちはエンジニア同士のペアプロを週1〜2回入れているが、AIエージェントを使うようになってから、「AIに任せた部分」と「自分で書いた部分」の境界が曖昧になっていた。だから、ペアプロ後にこんな表を残すようにしている。
| 工程 | 担当 |
|---|---|
| 要件理解・設計 | 人間（ペア） |
| 主要モジュールのスケルトン | AI |
| エッジケース設計 | 人間 |
| 単体テスト雛形 | AI |
| 統合テストの設計 | 人間 |
| ドキュメント | AI（人間レビュー） |
「AIに任せた部分」が増えすぎている場合、その工程を次回は人間で書く、というローテーションを入れる。逆に「人間が全部書いている」工程があれば、その工程はAIに任せる試みを次回入れる。
これは可視化することで初めて議論できる話だ。可視化されていないと「AI使ってます」「使ってません」の主観論争で終わる。表にして月次で振り返ると、自分たちのAI依存度がどこに偏っているかが、はっきり見える。
ペアプロは、AIが入る前は「相手から学ぶ場」だった。AI込みのいま、これは「相手とAIをどう使い分けるかを学ぶ場」に変わっている。可視化はその進化を支える土台になる。
AIに「書かせる」より「ブリーフィングする」を組織のコアスキルに据える理由
ここまでの3つの仕組みを通して、僕が組織のコアスキルとして据え直したのが「AIブリーフィング」だ。
これは COMPANYBLOG-60 AIブリーフィング でも書いたが、AIに「書かせる」より「ブリーフィングする」ほうが10倍難しい。コードを書くスキルは「自分の頭の中の設計を言語化する」スキルが土台になる。逆に、自分の頭の中の設計を言語化できる人間は、AIへのブリーフィングも上手い。
要素を4つに分解している。
① 文脈の構造化 — このタスクが何の課題を解いているか、上位ゴール・制約・既存資産を整理してAIに渡せる
② 仕様の精度 — 入力・出力・エラー処理・パフォーマンス要件を、推測の余地が少ない粒度で書ける
③ 出力のレビュー目線 — AIが出したコードが「何を見落としているか」を瞬時に判断できる
④ 反復の設計 — 一発で完璧を狙わず、出力→検証→指摘→再出力のループを設計できる
これらは「AIを使う前にエンジニアとして持っているべき土台スキル」と完全に重なる。だから、AI依存を防ぐ仕組みを回すと、結果的に「AIブリーフィングが上手い人間」が育つ、という循環ができる。
新人面接でも、最近は「AIに何を任せて、何を自分で書いてきましたか」と必ず聞くようにしている（採用基準は COMPANYBLOG-53 採用面接3つの質問 と組み合わせて運用中だ）。この問いに具体的に答えられる人は、入社後の伸びが速い。
（参考までに――K.Platinumでは、この「AIに頼りすぎない技術力の育て方」を一緒に設計してくれるエンジニアを募集しています。詳しい条件は採用ページで。）
17人ITコンサルが目指す「AI使うほど人が伸びる」設計と、これからの3年計画
最後に、3年スパンで僕が組織として目指している姿を書いておく。
1年目（2025〜2026前半）: AIエージェントを実務に組み込み、生産性を1.6倍にする。これは達成済み。
2年目（2026後半〜2027）: AI依存防止の3仕組みを定着させる。2つの研究が示した「19%遅延／17%スキル習得低下」を組織として乗り越え、「AIを使っても技術力が落ちない」状態を作る。
3年目（2028〜）: 「AIブリーフィング力」を組織のコアスキルとして外部に発信する。中堅・中小ITコンサルとして、AIに置き換わる仕事ではなく、AIを設計する仕事を主戦場にする。
エージェンティクAIの「実行の年」と言われる2026年、組織として一番怖いのは「AIに置き換わる」ことじゃない。AIを使いすぎて、AIを使う側の人間が育たなくなることだ。
17人という小さい組織だからこそ、ひとり一人の技術力の総量がそのまま会社の生存力に直結する。AIに頼りすぎず、AIを使い倒し、人間側を伸ばし続ける。この矛盾するように見える設計を、3つの仕組みで回し続けるのが、僕らの今の挑戦だ。
「Claude Code導入してから、PRがめちゃくちゃ通るようになった」――この言葉のあとに、「で、ちゃんと中身を説明できるようにもなった」が続く組織でありたい、と本気で思っている。
筆者プロフィール
沼田 海斗（ぬまた かいと）
株式会社K.Platinum 代表取締役 / 27歳 / 3期目。沖縄高専卒・トヨタ自動車を経てスタートアップITコンサルへ、24歳で起業。AI／RAG／エージェント案件を中心に、17人体制で製造業・流通・金融向けの受託開発を行う。資本金10万円から始めて、設立2年で20以上のプロジェクトを完遂。趣味はキックボクシング。
K.Platinumで一緒に働きたい方へ
K.Platinumでは、Claude Code・Cursor・Devinを実務に組み込みながら、AIに頼りすぎない技術力の伸ばし方を組織として設計しているITコンサル会社です。受託開発のエンジニア・ITコンサルタントを積極的に採用しています。
👉 採用情報を見る
👉 カジュアル面談を申し込む