はじめに

こんにちは、MSP セクションの毛利です。

幕張で開催された AWS Summit Japan 2026 に行ってきました。たくさんのセッションがある中で、タイトルを見た瞬間に「これはぜひ聞きたい」と思ったのが「AI でコードは書けても、レビューできる人がいなくなる ― ソフトウェア開発における自動化のパラドックス」（セッション ID: AIM223）でした。

最近、私たちのチームでは業務の自動化に取り組んでいます。その中で、私の頭の中にずっとモヤモヤしていることが 2 つあり、1 つは「AI を使って開発を進めるとき、ものごとを判断するためのスキルは、どうやって身につけていけばいいのか」。もう 1 つは「業務を自動化していくと、自分の頭で考えながら手を動かす時間が減っていく。そんな中で、業務そのものへの理解を、どう深めていけばいいのか」。

ちょうどそんなことを考えていたタイミングだったので、このセッションのタイトルが目にとまりました。この記事では、セッションの内容と、その中で私が感じたことをお伝えします。

セッション情報

AIM223 ― AI でコードは書けても、レビューできる人がいなくなる ― ソフトウェア開発における自動化のパラドックス

AI がコードを生成すれば開発者は設計やレビューに集中できる—この期待には落とし穴があります。日常的なコーディング経験を失った開発者は、コードレビューや設計判断の能力も衰えていく「AI 活用のパラドックス」です。要件定義や設計工程でも、AI が仕様整理やパターン提案を担うほど、それを評価できる PM やアーキテクトが育たなくなります。本セッションでは、経営者・PM・開発リーダーに向けて、この構造的課題の本質と対処法を解説します。段階的な AI 活用設計、安全な開発環境での失敗経験、AI 駆動開発における「AI が実装し人間がレビューする」役割分担など、開発組織の技術力を維持しながら AI 活用を進める実践手法をお伝えします。

アジェンダ
  1. AI 活用は組織の強みと弱みを増幅させる
  2. AI 活用のパラドックスの正体とは?
  3. 解決策：「意図的な非効率」と AI-DLC の両輪

「AI 活用のパラドックス」とは

セッションは、こんな問いかけから始まりました。

AI の活用によって、皆様の開発プロジェクト”全体”の生産性は向上していますか？

直感的には、上がってそうな気がします。ですが、セッションが紹介したのは、もう少しややこしい現実でした。

  • 個人の生産性は上がっているが、プロジェクト全体では上がっていない（McKinsey 2025：生成 AI を継続利用する組織は 65%。ただし、利益（EBIT）に貢献できた企業は 5% 未満）
  • 「速くなった」と感じても、実際は遅くなっていることがある（METR 2025：熟練開発者でも AI 使用時に 19% 遅延。なのに本人は「20% 速くなった」と感じていた）
  • コード作成は速くなったが、品質の相談はむしろ増えている

ここから導かれるのが、「個人は効率化を感じているが、全体にはさほど効果が出ていない」という状態 ―― これが AI 活用のパラドックス です。

AI は組織を映す「鏡」であり「増幅器」

もう 1 つ印象的だったのが、AI は組織を映す「鏡」だという指摘です。

  • AI は、組織の意思決定の仕組みや健全さを映し出す
  • そして、組織の強みも弱みも、そのまま「増幅」する
  • だから「AI が弱みを作り出す」のではなく、「もともとあった弱みの在り処を、はっきりさせる」

対策として挙げられていたのが、DevOps の 「作った人が、運用まで責任を持つ（You build it, you run it）」 という組織設計です。自分の仕事を「壁の向こうに投げる」構造がなければ、弱みは構造的に抑えられる、という考え方でした。

パラドックスの正体 ― 2 つの要因

なぜこんなことが起きるのか。セッションは、その正体を 2 つの要因に分けて説明していました。

  • 要因 A：スキル侵食の悪循環 ―「簡単にできる」ツールが、人の考える工程を消してしまう。考えないからスキルが落ちる、落ちるからますます AI に頼る、という悪循環に陥る。
  • 要因 B：オーナーシップの欠如 ― 仕事を「自分ごと」として引き受ける心理的オーナーシップは、「コントロール」「深い知識」「自己投入」という 3 つの経路から生まれる。AI に任せきると、その 3 つが満たされなくなる。

この 2 つが重なると、AI が書いたものをレビューできる人が育たなくなる ―― セッションのタイトルそのものの状態に行き着く、という整理でした。

解決策 ― 「意図的な非効率」と AI-DLC

では、どうするか。セッションの答えは 「意図的な非効率」 でした。あえて効率化しきらず、人が考えて判断する余白を残す、という設計思想です。具体的な勘どころは 3 つ。

  • オーナーシップ（コントロール／深い知識／自己投入）が育つ領域を確保する
  • ジュニアからシニアまで、経験値に合わせて段階的に AI 活用を設計する
  • 安全に失敗できるトレーニング環境を用意する

ポイントは「AI を禁止する」ことではなく、どこを人間の領域として残すかを設計する 「ガードレール型の統制」 だ、という点でした。

そして、これを 「育成」と「実践」の 2 つの歯車で回す、と。「意図的な非効率」で人を育て、育った人が AI-DLC（AI 駆動開発ライフサイクル） を回して実践する。AI-DLC は「育ったスキルを発揮する実践の場」であって、「スキルを育てる場」そのものではない、という整理も印象的でした。

セッションは、こんな言葉で締めくくられていました。

「コード」は、あくまで象徴にすぎない。AI は、業務全般にわたる。

意図的な非効率は、AI から離れるためではなく、AI を使い続けるための仕掛け。

まとめ

AI は、私たちの仕事を確実にラクにしてくれます。ですが、ラクになった分だけ自動的に「判断できる人」が育つわけじゃない。短期的な成果のために、長期的な価値を犠牲にしない（これは Amazon のリーダーシップ・プリンシプル “Ownership” の言葉だそうです）― 業務の自動化に取り組んでいる私にとって、刺さりまくる言葉でした。

私たち MSP は、お客様の環境を 24 時間 365 日支える運用の現場です。AI 活用を進めながら、どうやって「判断できる人」を育て続けるか。業務の自動化と並行して、考え続ける必要があるテーマだと思いました。