2026年5月13日、404 Mediaはある記事を公開し、業界全体に波紋を広げました。Meta、Google、Microsoftなど大手テック企業の開発者たちが、Copilot・Claude・Cursorといった AIコーディングツールへの過度な依存により、自力で問題を考え抜く能力が徐々に失われていると報告したのです。あるエンジニアは「コードをレビューもせずに通している」と述べ、他の開発者たちは「AIが代わりにやってくれるので、長年培ったスキルを使わなくなった」と語っています。
見出しはこう躍りました：「ソフトウェア開発者、AIが脳を腐らせていると訴える」
テック業界の不安として流し読みするのは簡単です。しかし、外注開発チームを評価しているCTOであれば、この記事をもっと深く読む価値があります。厳格なエンジニアリング文化と社内コードレビューを持つ大企業でこれが起きているなら、一部の外注ベンダーでも確実に起きています。そしてその結果は、ベンダーではなく、あなたのプロジェクトに降りかかるのです。
実際に何が起きているのか
AIコーディングツールは本質的に有用です。ボイラープレートを自動補完し、実装を提案し、よくあるエラーを検出し、以前は何時間もかかっていた作業を数分に圧縮します。これは誰も否定しません。
問題は、規律なく使用した場合に生まれる依存性です。AI生成のコードを理解せずに受け入れることを習慣にしたエンジニアは、エッジケースを検出し、スケールのために設計し、「動く」けれど本質的に誤ったコードを認識するための思考筋肉を鍛えなくなります。このスキル退化は現実のものです。GPSナビゲーションに関する認知研究と同じパターンです。ターンバイターンの案内を与え続けると、人はナビなしで方向を把握する空間認識能力を失っていきます。
ソフトウェアでは、これが他の多くの分野より重大な意味を持ちます。今日動くコードがスケール時に壊滅的に失敗することがあります。セキュリティの脆弱性は訓練されていない目には見えませんが、深いパターン認識を持つ人には明らかです。初期のアーキテクチャ判断は、保守可能なシステムか、技術的負債の連鎖かを決定します。これらはすべてコードを生成するだけでなく、判断力を必要とします。
開発者がAIツールに思考を委任すると、その判断力を育てることをやめてしまいます。速くなります。そして浅くなります。
AI支援 vs. AI依存——引くべき境界線
優れたAI活用のバージョンがあります。シニアエンジニアがCopilotを使って日常的な実装を加速させながら、システムのアーキテクチャ設計、出力のレビュー、AIが自信を持って出力した誤りの箇所を見つける——これは生産性の乗数です。エンジニアの判断がループの中に残っています。
一方、AI依存型の納品があります。モデルが生成したものをそのまま受け入れ、速く出荷し、締め切りが今日でクライアントが待っているのでレビューしない。これは高速に提供されたシニアエンジニアリングではありません。速いターンアラウンドの凡庸さです。
この違いは提案書の中では見えません。どちらのベンダーも「AIパワード」や「AI強化」と自称するでしょう。あるチームがAI出力を精査すべき草稿として扱い、別のチームがそれを成果物として扱っていることを、誰も自発的に教えてくれません。
ここが、あなたが深掘りすべき点です。
エージェンシーのAIワークフロー成熟度を評価する際に見るべきこと
「AIツールを使っていますか？」は適切な質問ではありません。すべての真剣なチームが使っており、そうでないと主張するエージェンシーは嘘をついているか、危険なほど遅れています。正しい質問は「どのようにガバナンスしていますか？」です。
ベンダー評価で尋ねる価値のある質問を挙げます：
AI生成コードのコードレビュープロセスはどのようなものですか？ 成熟したチームはAI出力を考慮したレビュー慣行を説明できます——モデルが幻覚を起こしやすい場所、もっともらしいが誤った実装を生成する場所を知っており、それらを明示的に確認します。このプロセスのないチームは「品質基準」について曖昧な答えを返します。
AIが見逃すものを誰が責任を持って確認しますか？ 明確な答えがあるはずです：シニアエンジニア、リード、レビューゲート。「ツールを信頼する」という答えなら、それがシグナルです。
AIが間違っていた具体例と、チームがどう発見したかを教えてもらえますか？ これが最も多くを明かす質問です。批判的思考を積極的に維持しているチームは具体的なエピソードを語れます。AIに任せきりのチームは明確な例を思い出すのに苦労します。
アーキテクチャプロセスはどのようなもので、AIはどこで役割を担いますか？ アーキテクチャ上の決定——システムの構造、データフロー、サービス間の通信——はドメイン知識を持つ人間が行うべきです。AIがプロジェクトのアーキテクチャ判断を主導しているなら、それは問題です。
新しいメンバーのオンボーディングプロセスはどうなっていますか？ 真のエンジニアリング文化を維持するエージェンシーには、ジュニアがプロンプトで解決するのではなく、問題を考え抜く力を教える体系的な方法があります。この質問は、彼らがエンジニアを育てているのか、AIオペレーターを訓練しているのかを明かします。
TMNSolutionsのアプローチ
私たちはAIツールを使います。頻繁に使い、それを恥ずかしいとは思っていません。Copilot、Claudeなどのツールは実装レイヤーで開発者を速くします。そしてその速さはコストとタイムラインの両面でクライアントへ直接還元されます。
私たちがしないのは、AI出力を完成した成果物として扱うことです。
TMNSolutionsでは、すべてのAI生成コードが人間が書いた実装と同じレビューを経ます。各プロジェクトのシニアエンジニアがアーキテクチャ上の決定に明示的な責任を持ちます——AIがそれらの判断を下すことはありません。新規プロジェクトを受注した際は、コードを1行書く前にビジネスコンテキストを理解することに時間をかけます。そのコンテキストこそが、正しいコードを適切なコードに変えるからです。
チーム内でのAI依存を作らないことにも意識的です。ジュニア開発者はプロンプトしたコードではなく、出荷するコードを理解することが求められます。AIが具体的にどこで間違えるかについての社内セッションを実施し、エンジニアが懐疑心を持つべき場所を知っています。
目標は、AIによって速くなっても、AIによって浅くならない開発者チームです。そのバランスには能動的な管理が必要です。自然には生まれません。
次のベンダー評価での実践的な質問
外注開発パートナーを評価中、または既存の関係を見直す場合、以下の実践的なテストを試みてください：
-
コードウォークスルーを依頼する。 エージェンシーの開発者に最近の実装を詳しく説明してもらいます。なぜその判断をしたかを説明できない場合、コードは完全に理解されずに生成されたシグナルです。
-
過去の問題のポストモーテムを求める。 チームはどのように問題を診断・解決しますか？深いデバッグはAI依存が最も早く退化させる独立的な思考を必要とします。
-
チーム構成を確認する。 明確なシニアリティの階層がありますか？「全員がAI開発者」という1層構造は危険なサインです。経験は判断力において重要であり、AIはそれを均等に配分しません。
-
コードを直接確認する。 技術者がいれば、実際の成果物を確認してもらいます。AI生成コードには認識可能なパターンがあります——過剰なコメント、過度に汎用的な実装、稀に幻覚したメソッド名。良いレビュワーは違いを見分けられます。
-
AIガバナンスポリシーについて尋ねる。 ポリシーが存在するかではなく（誰でも書ける）、その内容を聞きます——人間のレビューなしにAIが何をできて何をできないかについての具体的なルール。
本当のリスクはエージェンシーがAIを使うことではない
本当のリスクは、判断力なしにAIを使い——判断力を持って使ったかのように請求することです。
AIツールのスピードの恩恵により、より安く入札し、より速く納品することが容易になりました。表面上はクライアントにとってより良い取引に見えます。しかし、品質のない速さは納品書付きの技術的負債です。今日受け取り、次の12ヶ月でバグ、手直し、スケールしないシステムとして支払います。
あなたのビジネスにふさわしいエージェンシーは、速く動くためにAIを活用しながらも、思考の質を落とさない方法を見つけたところです。その区別は自然には明らかにならず、提案資料からも見えません。
質問が必要です。質問してください。
