【AWS Summit】 AIが書いたコードをレビューできる人はいますか？AI時代に求められる組織づくり

はじめに

みなさんこんにちは！パーソル&サーバーワークスの榎本です。
先日AWS Summit Japan 2026に参加してきました。
今回は参加したセッションの中でも、以前から自身でも課題感を抱いていたこともあって、特に印象に残った内容をご共有いたします。

テーマは「AIコーディングツールを導入したのに、なぜかプロジェクト全体の生産性は上がっていない」という、多くの現場が直面している課題についてです。
単なるAIコーディングの話にとどまらず、「組織論」「人材育成」という深いところまで踏み込んだ内容で、非常に考えさせられるセッションでした。

※セッション動画はこちらからご覧いただけます。
AWS Summit Japan 2026 セッション動画

AI-Driven Development Lifecycle（AI-DLC）とは

今回のAWS Summitで個人的には一番耳にしたワードであり、本セッションにおいても中心概念として紹介されていたのが AI-DLC（AI-Driven Development Lifecycle） です。
開発における AIの関与度合いを3層で表現しています。

層	説明
AI-Assisted Development	AIがコード補完・サジェストで人を支援する
AI-Driven Development	AIが開発プロセスの主要部分を主導する
AI-Managed Development	AIが計画・タスク分解・アーキテクチャ提案などを通じてプロセス全体を制御する

重要なのは、どの層においても開発者は検証・意思決定・監視の最終責任を持つ という点です。AIに任せ切りにするのではなく、AIを制御下に置きながら活用することが求められています。

「AIを入れたのに生産性が上がらない」3つの現実

セッションでは、AIの活用によって開発プロジェクトの生産性に関して「現場で感じていること」として以下の3点が挙げられました。

1. 個人単位では生産性向上しているが、プロジェクト全体は向上していない
2. 生産速度が速くなったと「感じている」が、実際は遅くなっている
3. コード作成は速くなったが、品質の相談は増えている

これらはいずれも「何も考えずにAIを使っても生産性向上に繋がらない」という課題を示しています。

AI活用は組織の「鏡」

セッションの中で印象的だったのが「AI活用は組織の『鏡』」というフレーズです。
AIを導入すると、その組織の意思決定の仕組みや健全性がそのまま映し出されるという指摘です。

• 責任範囲が曖昧 → レビューが不足し、「詰まり」が後ろに移動するだけ
• 判断を下す人がいない → AI出力の取捨選択ができない
• 言語化を諦めている組織 → プロンプトも曖昧、要件も曖昧

AI活用によって、既存の組織課題が拡大されて顕在化するということが取り上げられていました。

"You build it, you run it" が生む二重の効果

強みの増幅：
顧客の反応が直接届く構造は、エンジニアの学習速度を加速させます。フィードバックの精度が上がるほど、人が育つ速度も上がります。

弱みの構造的抑制：
「壁の向こうに投げる」選択肢が存在しないため、下流の痛みが必ず上流の自分に跳ね返ってくる構造があります。

この「作った人が運用まで責任を持つ」という組織設計が、強みを最大化し弱みを構造的に抑えるという考え方です。

AI活用パラドックスの2つの要因

生産性が向上しない背景には、2つの根本的な要因があるとされていました。

要因A：スキル侵食の悪循環

「簡単にできる」ツールが、人が考える工程を消していきます。
AIが高品質なコードを即座に生成してくれるがゆえに、エンジニア自身が「なぜそのコードなのか、どのような処理内容か、改善点や懸念点はないか」を考えなくなる。その結果、判断力・設計力が徐々に失われていくという悪循環です。

要因B：オーナーシップの欠如

「AIに任せる」戦略が「自分のコード」という実感を消していきます。

心理的オーナーシップが生まれるためには3つの経路が必要とされています：

経路	説明	AIによる侵食
コントロール（Control）	自分がコントロールしている感覚	「そのコードを書いたのはAIです」
深い知識（Intimate knowledge）	細部まで知り尽くしている感覚	「コードの設計妥当性は未確認です」
自己投入（Self-Investment）	時間・思考・努力が染み込んでいる感覚	「AIが10分で出しただけです」

事例紹介

具体的な事例も紹介されていました。
某企業では、AI活用を進める中でスキル侵食とオーナーシップ欠如が顕在化し、一時的にAI使用を全社禁止する判断を下したとのことです。

その結果、以下のような気付きがあったようです。

• 執行役員の気づき：「自分でできないことは、AIにやらせても判断できない」
• エンジニアの気づき：「最後に責任を持って意思決定するのは自分」
• 思考力（問・設計判断・調べる）が強化され、エンジニアのオーナーシップが回復した

この事例が示すのは、AIを禁止することが目的ではなく、「自分でできないことはAIにやらせても判断できない」という根本的な事実です。

「意図的な非効率」という設計思想

セッションを通じて繰り返し強調されたキーワードが 「意図的な非効率」 です。

効率化からあえて外す工程を組織に残す設計思想

「効率化だけを目的にすると、判断と育成の余地が同時に消える」という考え方です。
学術的にも「簡単すぎる環境は育成を止める」とされており、「熟達は、自分の判断で楽な環境の外に踏み出し続けることでしか起こらない」とも言われています。

意図的な非効率の3つの働きどころ

• オーナーシップを形成する育成場所の確保
  「コントロール」「深い知識」「自己投入」の育成場面を意図的に残す
• ジュニアからシニアまで、個人の経験値に合わせた段階的なAI活用の設計
  全員に同じAI活用を強要せず、スキルレベルに応じた適切な活用範囲を設定する
• トレーニングの環境を用意する（安全な失敗経験の設計）
  失敗してもリカバリーできる環境で、意思決定の経験を積ませる

セッションのメッセージ：「AIを活用し、かつレビューできる人も育つ」組織へ

セッションの結論として印象的だったのが、目指すべき姿の定義です。

「AI活用してレビューできる人」とは、AI出力を正しく評価し、判断と取捨選択の責任を引き受けられる人

そしてこの人材は：

短期的な効率化からは生まれない。意図的な非効率の中でこそ育つ。

Amazonのリーダーシップ原則「Ownership」にも通じる言葉でした。
「リーダーは長期的視点で考え、短期的な結果のために、長期的な価値を犠牲にしません。」

まとめ・所感

今回のセッションで最も刺さったのは、大半の他のセッションでAI活用を推進するような内容が発表されている中で、本セッションは「AIを入れれば生産性が上がる」という前提への問い直しをしていた点です。

AIツールの導入は確かに個人の作業速度を上げると思います。しかし、チーム・組織全体として本当に強くなっているか という問いに答えるためには、「意図的な非効率」という逆転の発想が必要なのかもしれません。

ツールを入れることと、それを使いこなせる人材を育てることは別の問題です。
特に「AIが出したコードに責任を持てるか？」という問いは、AIコーディングが普及する今の時代にエンジニア全員が向き合うべき問いだと感じました。

AIを活用しながら、自分の判断力・設計力・オーナーシップを失わないようにするためには、意識的に「考える経験」を積み重ねることが重要です。
このセッションは、そのことを改めて強く意識させてくれる内容でした。

「AIに任せっきりにしてたら、自分で判断できなくなっていた」なんてことが起きないよう、私自身も気をつけていきたいと思います。
最後までお読みいただきありがとうございました！

この記事は私が書きました

榎本 将希

記事一覧

2024,2025 Japan All AWS Certifications Engineers サッカー観戦とサウナが好きです！ 機械学習とAIを勉強中です！