これはAIによるコーディングでも同じだ。「なぜこのロジックが必要なのか」「この実装で本当に目的を達成できるのか」といった思考をAIに委ねれば、アウトプットを評価・レビューする力は育たない。やがてAIに依存しなければ開発できなくなり、品質の低い成果物が組織に蓄積されていく。

　AIによる効率化が、開発者のスキルと評価能力を低下させ、組織の生産性向上を阻む。この負のループこそ、「AI活用のパラドックス」を生む1つ目の要因だ。

AI依存が奪う「レビューできる人」

　AI活用のパラドックスを生む2つ目の要因は、開発者がAIの出力に責任を持つ「オーナーシップ」の欠如だ。

　経営学では、人が対象を「自分のもの」と感じ、責任を持つようになるには、3つのきっかけが必要だとされている。ところが、AIによる自動コーディングでは、そのきっかけが生まれにくい。自分で考えたり手を動かしたりする場面が減ることで、自分が作ったという実感が薄れ、成果物への責任感も弱くなってしまう。

　では、オーナーシップを生む3つのきっかけとは何か。そして、AI自動コーディングによって、それぞれはどう弱まるのか。

　その結果、現場では「AIがそう言ったから」と思考が停止し、最終的な判断と責任を担う主体が曖昧（あいまい）になってしまう。杉本氏は、こうしたオーナーシップの欠如がもたらす弊害を示す事例として、AIの利用を一時的に禁止した不動産テック企業、いえらぶGROUPを紹介した。

　同社のある開発プロジェクトでは、新人エンジニアがAIによる自動コーディングのアウトプットを盲信して実装を進めていた。作成されたコードをPR（Pull Request）レビューしたところ、レビューコメントは実に830件に達したという。コードレビューとしては異例の数だった。

　事態を重く見た同社は、一時的にAIの利用を禁止する「AI禁止令」を発令した。AIへの過度な依存をいったん断ち切り、なぜこのモジュールがこの責務を持つのかを自分の言葉で説明できるよう、自ら考え、自ら調べるという基本に立ち返らせた。その上で、約4カ月をかけてAIの利用を段階的に解禁した。

　杉本氏によれば、当時のエンジニアは「AIの答えが正解だ」と疑わなかったという。つまり、判断の主体が自分ではなくAIになっていた。それが、コード品質を巡る多くの問題につながった。

　この経験を通じて、同社は「自分でできないことは、AIにやらせても判断できない」という結論に至った。そしてエンジニア自身も、「最後に責任を持って意思決定するのは自分だ」という原則を再認識したという。

　杉本氏は、「スキルが育たないこと」と「オーナーシップが欠如すること」は、実は同じ構造の表裏だと指摘する。

　スキル侵食の悪循環によって、AIの出力を評価・レビューする「目」が育たなくなる。すると、さらにAIに依存するループに陥る。一方、オーナーシップが欠如すれば、誰も最終的な判断を引き受けなくなり、レビューそのものが組織の機能から外れてしまう。

　つまり、この2つが絡み合うことで、徐々に「レビューできる人」がいなくなっていく。AIによって生成できるコードの量は増えても、そのコードが本当に正しいのか、目的に適合しているのかを評価し、品質を保証できる人がいなくなる。

　では、どうすればこの状況を回避できるのか。AIによる開発効率を維持しながら、「レビューできる人」を組織の中で育てるには、どのような仕組みが必要なのか。杉本氏は、そのための具体的な仕掛けを提案した。

「誰も責任を取らない」開発現場

　その結果、現場では「AIがそう言ったから」という思考停止が生まれ、最終的な判断と責任を担う主体が曖昧（あいまい）になってしまう。杉本氏は、こうしたオーナーシップの欠如がもたらす弊害として、AIの利用を一時的に禁止した不動産テック企業、いえらぶGROUPを紹介した。

　同社のある開発プロジェクトでは、新人エンジニアがAIによる自動コーディングのアウトプットを盲信して実装を進めていた。作成されたコードをPR（Pull Request）レビューしたところ、レビューコメントは実に830件に達したという。コードレビューとしては異例の数だった。

　事態を重く見た同社は、一時的にAIの利用を禁止する「AI禁止令」を発令した。AIへの過度な依存をいったん断ち切り、「なぜこのモジュールがこの責務を持つのか」を自分の言葉で説明できるよう、自ら考え、自ら調べるという基本に立ち返らせた。その上で、約4カ月をかけてAIの利用を段階的に解禁した。

　杉本氏によれば、当時のエンジニアは「AIの答えこそが正解だ」と疑わなかったという。つまり、判断の主体が自分ではなくAIになっていた。それが、コード品質を巡る多くの問題につながった。

　この経験を通じて、同社は「自分でできないことは、AIにやらせても判断できない」という結論に至った。そしてエンジニア自身も、「最後に責任を持って意思決定するのは自分だ」という原則を再認識したという。

　杉本氏は、「スキルが育たないこと」と「オーナーシップが欠如すること」は、実は同じ構造の表裏だと指摘する。

　「スキル侵食の悪循環によって、AIの出力を評価・レビューする『目』が育たなくなる。すると、さらにAIに依存するループに陥る。一方、オーナーシップが欠如すれば、誰も最終的な判断を引き受けなくなり、レビューそのものが組織の機能から外れてしまう」

　つまり、この2つが絡み合うことで、レビューできる人が徐々にいなくなっていく。AIによって生成できるコードの量は増えても、そのコードが本当に正しいのか、目的に適合しているのかを評価し、品質を保証できる人がいなくなる。

　では、どうすればこの状況を回避できるのか。AIによる開発効率を維持しながら、「レビューできる人」を組織の中で育てるには、どのような仕組みが必要なのか。杉本氏は、そのための具体的な仕掛けを提案した。

　こうした点に留意した人材育成が1つ目の鍵になる。

AI時代にこそ必要な“あえて苦労する時間”

　もう一つの鍵は、こうして育成した人材がAIを活用して生産性を高めるための実践的なフレームワーク、「AI-DLC」（AI駆動開発ライフサイクル）の構築だ。AI-DLCは、2025年にAWSが提唱したAI活用の方法論。AIを開発チームの協力者／チームメイトと位置付け、ソフトウェア開発ライフサイクル全体でAIを活用することを目指す。

　特徴は、「AIが実行し、人間が監視する」という役割分担にある。AIがルーティンタスクを担う一方、人間は問題解決や創造的思考、意思決定に注力する。AIに作業を任せるだけでなく、人間が判断と責任を担いながら、開発プロセス全体の生産性を高めることがAI-DLCの狙いだ。

AI-DLCの3つのフェーズと内容

　AI活用の熟達者、つまり、レビューできる人材の力をさらに引き出すのがAI-DLCだ。杉本氏は、「AI-DLCによって組織の弱点が浮き彫りになる。そこで見つかった欠陥を、『意図的な非効率』を組み込んだ人材育成で埋めていくことが重要だ」と指摘する。

　いわばAI-DLCは、組織のありのままの姿を映し出す「鏡」である。その「鏡」には、次のような課題が映し出される。

　AIに任せれば効率化できる部分でも、あえて人間が考え、判断する工程を残す。そうした人材育成によってAI-DLCを回せる人材を増やし、AI-DLCによって明らかになった組織の弱点を、さらに人材育成によって埋めていく。この循環こそが、AI活用のパラドックスを解消する鍵となる。

　杉本氏はまた、オーナーシップについて「真のオーナーシップとは、全てを引き受けることではない。何を実行し、何を捨てるのか、優先順位を判断して取捨選択し、その選択に責任を持つことだ」と語る。

　全機能を網羅的に実装すべきだと主張する人は、一見するとオーナーシップがあるように見える。しかし実際には、「全てやっておけば文句を言われない」という発想にすぎず、自分で優先順位を決めることを避けているともいえる。

現場の思考停止を防ぐ、今日からできる3つのステップ

　以上の取り組みを実践するには時間がかかりそうだが、杉本氏は今日からでも始められる具体的なステップも示した。次のステップを順に実行することで、AIを最強のパートナーとして活用し、組織の生産性向上につなげることができる。

　AI活用では、自動コーディングに限らず、単なる作業効率の向上だけでなく、人間が判断し、最終的な責任を負うことを重視する方向へシフトする必要がある。AIに任せず、人間が考え、判断する工程をあえて残す。そうした人材を育てることが、AIを組織の生産性向上につなげる鍵なのだろう。

　DevOpsの領域でよく語られる「You build it, you run it」（作った人が運用せよ／開発者は運用にも責任を持つべき）という言葉は、AIを活用した開発においても、改めて重要なキーワードになりそうだ。