AIエージェント
AI 時代、技術者の判断力をどう守るか——自動化が奪う「思考の深さ」
AIエージェントに次々と仕事を任せるほど、人間の判断力は低下し、システムへの理解も薄れていく。この避けられない現象に対抗するには、「何を学ぶか」を意識的に設計する必要がある。
原題
“To Read—Or Not to Read the Code?” （コードを読むべきか、読まないべきか？）
原文からの引用
“A codebase compounds from the ground up. If a person doesn't compound alongside it, the two curves start to diverge: The system keeps getting more capable while the person's ability to judge it keeps getting weaker.”
日本語訳 コードベースは土台から積み上がっていく。人間がそれと並んで積み上がらなければ、二つの曲線は乖離し始める。システムは能力を高め続けるのに対し、それを判断する人間の力は弱くなっていく。
要点
- 著者は自分の仕事をスキル・フレームワーク・次のエージェントに渡す手順などへ置き換え続けた（Every のメールアシスタント Cora の開発もその一例）結果、効率は上がったが、学習への報酬感が失われ、脳が「TikTok のような短期的な快楽の集合体」になっていることに気づいた
- 自動化が高性能になるほど人間側の技能が落ちる「自動化の皮肉（irony of automation）」は、自動化された工場や発電所のオペレーターを研究していた安全性の研究者が 1983 年に指摘しており、AIエージェントはその進行を速めただけである。Margaret Mitchell・Avijit Ghosh・Samir Passi の 3 氏は最近の論文で既存の証拠を整理し、AIエージェントの長期利用が人間による監督の前提である警戒心・批判的思考・ドメインの技能を測定可能なかたちで損なうという一貫したパターンを見出している
- コード読みの役割が変わった。著者は昨年、コードレビューで全行を読むのをやめた（検証は計画・テスト・レビューのエージェントに任せている）が、最近になって「学習のため」にコードを読み直し始めた。細部ではなく、システム全体の流れと判断理由を理解することが重要
- 実例：顧客が送信済みメールを削除されたバグで、表面的に妥当な修正案（待機時間の追加や条件チェック）は、システム全体を理解していないと不十分。著者が「Gmail に問い合わせてから削除する」という根本的な解決策を提案できたのは、システムの全体像を持っていたから
- 判断力を保つには、継続的に「どこで学びが足りないのか」を把握し、意識的に学習を習慣化する。ツールの使い方を知ることと、その背後にある仕事を理解することは別タスク
編集部の考察
Cora のメール削除バグ事例が示すのは、「もっともらしく聞こえる修正」と「実際に効く修正」を見分ける基準を、デリバリー速度中心の評価制度はそもそも測れていないという問題だ。（要点4）Cora が作った下書きを顧客が Gmail 上で編集・送信した後に、Cora が後片付けでそのメールを削除したこのバグでは、「削除前に30秒待つ」「Cora 自身が送信した場合はスキップする」という2つの修正案が出たが、どちらも表面的にはもっともらしい内容だった。それでも両方とも本当の原因とは無関係で、実際に有効だったのは「削除前に必ず Gmail に事実確認し、確証が得られなければ削除しない」という、システム全体の処理フローを事前に理解していたからこそ出せた根本解決策だった。人材評価が PR のマージ数やデリバリー量だけで測られている組織では、まさにこの種の「もっともらしいが的外れな修正」を最速で出す人材を高く評価してしまっている可能性がある。
決めるべきは、評価基準に「なぜその修正が正しいと言えるかをシステム全体から説明できるか」という項目を加えるかどうかだ。これを変えないまま自動化だけを進めれば、判断力を測らない評価制度の下で「即応は速いが原因を説明できない人材」が昇進し、次の障害でも同じ種類の誤った修正が繰り返されることになる。
本記事は海外記事の独自キュレーション・考察であり、原文の翻訳ではありません。引用部分の著作権は原著者に帰属します。
この記事の調査と下書きにはAIを使っています。数値や事実は出典と照合し、公開するかどうかは運営者が判断しています。（制作方針）