Google Cloud AIディレクターのアディ・オスマニ氏は、AIエージェント時代のエンジニアには、「AIより速くコードを書く」といったスキルではなく、別のスキルを持つことが重要になると説明する。
AIが実装作業の多くを担うようになったあと、エンジニアにはどのような役割が残るのか。
Google Cloud AIディレクターで、Google Chromeの開発チームなどでエンジニアリングリーダーを務めてきたアディ・オスマニ氏は、将来のエンジニアを特徴付けるのは「何をする価値があるのかを選択できる人」だと説明する。
本稿では、オスマニ氏の講演を基に、AIエージェント時代にエンジニアが担うべき役割と、スキルの構築過程で避けるべき3つの落とし穴を紹介する。
AIエージェントの進化によって、試作品の作成、機能開発、コード修正、テスト、保守といった幅広い作業を自動化できるようになりつつある。
AIエージェントに対して、仕様書や既存のコード、開発ルール、利用可能なツールを与えれば、一定の範囲で自律的に作業を進められる。さらに、AIエージェントにコードを書かせるだけでなく、テスト結果を確認し、失敗した場合に修正し、再度テストさせる仕組みを作れば、AIエージェントは長時間にわたる作業も実行できる。
このような環境では、単に「何ができるか」だけを競う意味は薄れる。AIエージェントが実行できる作業の範囲は、今後も広がる可能性が高いためだ。オスマニ氏は、代わりに「何を実行する価値があるのか」を見極める能力が重要になると指摘する。
AIエージェントは多数の選択肢を高速に提示できる。しかし、どの選択肢がユーザーやビジネスにとって意味を持つのか、どのリスクを許容できるのか、どこに人員や予算を投入するのかを決めるには、事業や組織、ユーザーに関するコンテキストの理解が必要になる。
オスマニ氏によると、将来のエンジニアは、AIエージェントが実行した作業に関する「証拠」を保持し、変更内容やシステムへの影響を理解した上で、最終的な判断を下す役割を担うという。ここでいう判断とは、単にコードを承認することではない。
その変更を本番環境へ反映するのか、差し戻すのか、別の方法へ方向転換するのか、あるいは残るリスクを受け入れるのかを決めることだ。
品質を確認するだけであれば、テスト結果や性能指標といった証拠を集めればよい。しかし、最終的な判断には、「誰がその判断を下し、誰が結果を引き受けるのか」という責任が伴う。
AIエージェントが設計、実装、テストなど複数の工程にまたがって作業するようになると、従来の職種や役職の境界も曖昧になる。
これまでは、設計者、開発者、テスト担当者、運用担当者といった形で、工程ごとに役割を分ける企業が多かった。しかし、AIが複数工程を横断して作業する環境では、「自分は開発担当だから、運用については知らない」といった分業だけでは、結果に責任を持ちにくい。
重要になるのは、「自分の肩書は何か」ではなく、「システムのどの部分を理解し、所有し、責任を持てるか」である。
例えば、AIエージェントが認証機能を修正した場合、担当者は変更されたコードだけでなく、アクセス権限、監査ログ、既存利用者への影響、障害発生時の復旧手順まで理解している必要がある。
エンジニアは、単にコードを書いてコンピュータを動かす人ではない。システム全体について考え、制約条件を整理し、複数の選択肢の利点と欠点を説明し、リスクを管理する人である。
そして、問題が起きたときに、なぜその変更を承認したのか、どのリスクを受け入れたのかを説明できる人でもある。
オスマニ氏は、人間とAIの能力差を考えるために、「アルファ」（Alpha）と「ディケイ」（Decay）という概念を挙げる。
アルファとは、人間にはできるが、現在のAIモデルにはできない能力の差だ。例えば、以前はコードを素早く書く能力や、膨大なAPIの仕様を記憶する能力が、エンジニアの強みになった。
しかし、現在のAIは短時間でコードを生成し、必要な仕様を検索し、複数の実装案を提示できる。このように、AIモデルの進化によって、人間とAIの能力差が時間とともに縮まっていく過程がディケイである。
現在、人間に残されているように見える強みも、永久に続くとは限らない。
コードを書く速度だけでなく、知識の想起、コードレビュー、テスト結果の評価なども、AIや自動評価システムによって代替されつつある。
主観的な判断力やセンスを意味する「テイスト」（Taste）もある。
誰でも多数の案を生成できるようになれば、どの案を選ぶべきかを判断する能力の価値は高まる。客観的な評価指標がまだ存在しない状況で、より良い案を見分けられる人は重要になる。ただし、この判断力も絶対的な強みではない。
人間が優れた判断例や評価基準を記録し、それをAIに学習させれば、AIも徐々に同じような判断をできるようになる。現在の強みである判断力にも、長期的にはディケイが起こる可能性がある。
AIエージェントは、コードの生成や不具合の調査、テストなどの高速化に寄与する。一方、作業をAIに任せる範囲を広げるほど、人間がシステムを理解したり、出力を検証したりする能力は弱まる恐れがある。
オスマニ氏は、AIやAIエージェントを活用するエンジニアが警戒すべき問題として、「認知の負債」（Cognitive Debt）、「認知の降伏」（Cognitive Surrender）、「オーケストレーションのコスト」（Orchestration Tax）の3つを挙げる。
認知の負債とは、問題解決に関する人間の理解や記憶が失われ、自分たちがリリースするシステムを自ら説明できなくなる状態を指す。
ソフトウェア開発では、リポジトリに蓄積されたコードの量と、チーム内の人間が実際に理解しているコードの量との差として表れる。
AIエージェントが不具合の原因を調べ、修正コードを生成し、テストまで実行すれば、人間は最終結果だけを見て変更を承認できる。短期的には効率的だが、この作業を繰り返すと、「なぜこの実装になっているのか」「障害が起きたときにどこを確認すべきか」を説明できる人がいなくなる恐れがある。
ビルドやテストに成功し、プルリクエストを問題なくマージできたとしても、チームがシステムを理解しているとは限らない。AIが生成したコードが増える一方で、人間の理解が追い付かなければ、正常に稼働している間は問題が表面化しなくても、障害や仕様変更への対応が難しくなる。特に注意が必要なのは、AIエージェントに長時間の作業を任せる場合である。
数十秒で完了する処理であれば、人間はAIとの対話として作業内容を把握しやすい。一方、数時間から数日に及ぶ処理は、単なる対話ではなく、独立した業務の流れになる。
複数の長時間タスクを並行して動かせば、担当者はAIが途中で下した判断や、採用しなかった案を追えなくなる。最後に出力されたコードやテスト結果を眺めるだけでは、十分なレビューにならない。
認知の負債を防ぐには、AIエージェントが変更したファイル、参照した仕様、実行したテスト、判断の理由、採用しなかった案、残存するリスクなどを記録し、人間が処理の流れを後から再構成できる状態を保つ必要がある。
AIにコードを生成させるだけでなく、そのコードを理解するための証拠も同時に提出させることが重要になる。
認知の降伏とは、人間が自ら思考し、判断する前に、AIの回答を無条件に受け入れてしまうことである。そこで考えたいのは、AIへの「委任」と「降伏」だ。両者はどう違うのか。
委任とは、AIに作業を実行させた上で、人間が判断するために必要な証拠を提出させることである。AIが調査や実装を担っても、最終的な結論は人間が下す。
認知の降伏では、人間が自分の意見を形成する前に、AIが提示した回答を自分の回答として受け入れてしまう。例えば、AIが「この変更によるセキュリティ上の問題はない」と回答したとする。担当者がコードの差分やテスト結果、影響範囲を確認せずに変更を承認すれば、作業だけでなく判断までAIに明け渡したことになる。
AIは、誤った内容でも自信ありげな文章として提示する。その文章を見たユーザーは、十分に検証していないにもかかわらず、自分が正しい判断を下したかのように感じる可能性がある。
これは、AIが示す自信を人間が借りて、自分にも十分な根拠があると錯覚する「借り物の自信」といえる。
問題は、AIを利用すること自体ではない。AIの確信に満ちた表現を見て、自分もその根拠を理解していると思い込むことである。
認知の降伏を防ぐには、AIを利用する前に、人間側が仮説や判断基準を持っておく必要がある。
AIの回答を受け取った後も、どの根拠を確認したのか、どこに不確実性が残っているのか、反対の結論が成立する可能性はないかを検討する。
AIに結論だけを尋ねるのではなく、判断に使った証拠や、結論が誤っている可能性、追加で確認すべき点を提示させる運用を実行することが大切だ。
オーケストレーションのコストとは、大量のAIエージェントを並列で動かすことで、出力の確認や統合に必要な人間の注意力や認知帯域が圧迫される問題を指す。
AIエージェントを100体同時に動かしても、人間が100倍の情報を理解し、100倍の速さで判断できるようになるわけではない。
AIエージェントを増やすほど、生成されるコードや修正案、テスト結果、警告、例外も増える。人間は、それらを振り分け、検証し、必要に応じて統合しなければならない。
例えば、あるAIエージェントがデータベースを変更し、別のAIエージェントがAPIを修正し、さらに別のAIエージェントが画面を更新したとする。それぞれの変更が単独では正しくても、組み合わせた結果として不具合が起きる可能性がある。
複数のAIが異なる修正案を提示すれば、どの案を採用するかを人間が決めなければならない。変更が競合すれば、統合方法も判断する必要がある。
AIによって実行能力を増やすほど、人間に流れ込む判断事項も増えることになる。
オーケストレーションのコストを抑えるために、必ずしもAIエージェントの数を減らす必要はない。重要なのは、人間がどの段階で介入するのか、AIにどのような証拠を提出させるのか、どの条件で処理を停止させるのかをあらかじめ設計することである。
全ての変更を、人間が同じ深さで確認する必要もない。文言修正や定型的な更新は自動テストに任せ、認証、決済、個人情報、インフラ構成など、影響の大きい変更だけを人間に通知する方法が考えられる。
AIエージェントを並列化できても、人間の注意力は同じようには並列化できない。企業は人間の認知帯域を有限の資源と捉え、どの判断に集中させるかをシステムとして設計する必要がある。
AIエージェント時代の開発体制は、「インナーループ」と「アウターループ」に分けて考えることができる。
AIエージェントが調査、実装、テスト、結果報告を担うのがインナーループだ。例えば、不具合の原因を調べ、修正案を作成し、コードを書き、テストを実行し、結果をまとめるところまでをAIに任せる。ここで求められるのは、与えられた目的に沿って処理を実行する能力である。
どの課題に取り組むのかを人間が決め、AIが提示した証拠を検証し、本番環境への反映を承認し、残るリスクを引き受ける。
AIエージェントがインナーループの処理を高速化するほど、人間はアウターループの判断に集中できる。
ただし、「人間がAIの出力を一度眺めるだけでは、アウターループを担ったことにはならない」とオスマニ氏は指摘する。
AIが提出したコードの差分、テスト結果、ログ、判断理由、操作履歴などを基に、変更内容や影響を理解し、承認、差し戻し、停止、方向転換を判断する必要がある。
インナーループにあるのは、作業を実行する能力である。アウターループにあるのは、何を実行するかを決め、その結果を所有する主体性だ。
AI時代には、「ハイエージェンシー」（High Agency）と呼ばれる主体性も重要になるとオスマニ氏は説明する。ハイエージェンシーは、全ての作業を人間が自分で抱え込むことではない。
AIに任せられる作業まで人間が手作業で実施すれば、AIを利用する意味は薄れる。逆に、全てをAIへ委ねれば、人間がシステムの理解や責任を失う。必要なのは、いつAIに委任し、いつ人間が検査し、いつ処理を止め、いつ自分の名前で結果に責任を持つのかを判断することだ。
例えば、AIが既存コードの整理を提案した場合、影響の小さい部分はAIに任せてもよい。一方、顧客データを扱う処理や、本番環境の設定変更については、人間による詳細な検証や承認が必要になる。
問題を発見するだけで終わらず、原因を調べ、対応案を示し、解決まで進める。さらに一段高い主体性は、その問題に取り組む価値があるかを判断する。
AIエージェントを利用する企業にとって、重要な運用原則が「説明できないならリリースしない」（Explain it or don't ship it）だ。この原則は、人間が全てのコードを自分で書き、全ての行を詳細に読むべきだという意味ではない。
AIがコードを書いたとしても、その変更を本番環境へ反映するのであれば、誰かが変更内容とリスクを説明できなければならない。
そこで、変更の目的、主要な処理、影響範囲、検証結果、残るリスクを理解し、その判断を他者に説明できるようにする。
例えば、AIが認証処理を変更した場合、担当者は「テストに合格したから問題ない」と説明するだけでは不十分である。なぜ変更が必要だったのか、どの認証経路が変わったのか、既存ユーザーへの影響はあるのか、権限昇格や認証回避の可能性をどのように検証したのかを説明できるようにする。
プログラミング言語やフレームワーク、クラウドサービス、ローコード／ノーコード開発が登場するたびに、「開発が容易になればエンジニアの仕事は減る」との声が挙がった。しかし、実際には逆のことが起きている。
ソフトウェアを作る費用や難易度が下がると、それまで採算が合わなかった製品や業務システムが開発対象になった。実現可能なアイデアが増え、ソフトウェアへの需要は拡大した。
AIエージェントも同じ変化を起こす可能性がある。
AIによって実装費用が下がれば、企業はこれまで作れなかった機能やシステムを短期間で開発できるようになる。
その一方で、作成可能な選択肢が増えるほど、「何を作るべきか」という判断が難しくなる。
開発のボトルネックは、「これを作れるか」から、「これを作るべきか」「その結果に責任を持てるか」へ移っていく。
AIエージェントは、調査し、コードを書き、テストし、複数の案を提示できる。しかし、その仕事に取り組む価値があるのか、証拠は十分なのか、残るリスクを受け入れられるのかを判断する役割は人間に残る。
AI時代のエンジニアに求められるのは、AIより速くコードを書くことではない。
AIが生み出す多数の選択肢から、実行する価値のある仕事を選ぶことだ。AIに任せる作業と、人間が判断すべき領域を切り分ける。提示された証拠を検証し、自分たちがリリースするシステムについて説明する。そして、最終的な結果に自分の名前で責任を持つことである。
本稿は、IBM Technologyが2026年7月15日に公開した動画「"The engineer of the future is the person who is able to choose what is worth doing."―Addy Osmani」を基に作成しました。
Copyright © ITmedia, Inc. All Rights Reserved.
瞬時にM365が乗っ取られる――全社員に周知すべき“新フィッシング”の教訓
MFA（多要素認証）を入れたから安心という常識が崩れ去っている。フィッシング集団「Tycoon2FA」が摘発されたが、脅威が完全になくなったというわけではない。
「サイト内検索」＆「ライブチャット」売れ筋TOP5（2025年5月）
今週は、サイト内検索ツールとライブチャットの国内売れ筋TOP5をそれぞれ紹介します。
「ECプラットフォーム」売れ筋TOP10（2025年5月）
今週は、ECプラットフォーム製品（ECサイト構築ツール）の国内売れ筋TOP10を紹介します。
「パーソナライゼーション」＆「A／Bテスト」ツール売れ筋TOP5（2025年5月）
今週は、パーソナライゼーション製品と「A／Bテスト」ツールの国内売れ筋各TOP5を紹介し...
ITmediaはアイティメディア株式会社の登録商標です。
