8月27日、Semiconductor Engineeringが「How Agentic AI Turns IC Engineers Into Architects」と題した記事を公開した。AIエージェントの普及によってICエンジニアの役割が実装者からアーキテクトへと移行しつつある変化について詳しく紹介されている。
「実装する人」から「設計する人」へ
ソフトウェア開発ではすでに起きていることだ。AIコーディングツールはオートコンプリートからエージェントへと進化し、自然言語の指示を受け取り、コードベースを調べ、変更を加え、テストを実行して自律的に反復する。
次はチップ設計の番だ。ただし、この分野での移行はより遅く、より難しく、影響もより大きいと記事は指摘する。
AIネイティブなチップ設計ワークフローにおける最大の変化は、RTL生成やテストベンチ作成が速くなることではない。エンジニアの働き方そのものが変わる。自分ですべてのステップを実行するのではなく、代わりに作業を実行するインテリジェントなシステムを管理するようになる。
つまり、エンジニアの役割は「書く人」→「レビューする人」→「オーケストレーター」→「アーキテクト」へと上位に移動していく。
エンジニアリング管理の民主化
記事がおもしろい視点を提示している。自然言語で要望を伝え、実装を委任し、結果を確認して反復する手法——いわゆる「バイブコーディング（vibe coding）」と呼ばれる開発スタイル——は新しいアイデアのように見えるが、エンジニアリングマネージャーはこれを数十年間やってきたというのだ。
マネージャーは仕様書・チケット・メールで「何を作るか」を伝え、実装はエンジニアに委任し、上がってきた成果物をレビューして判断する。人間エンジニアの代わりにAIエージェントを置くと、このワークフローは驚くほど似たものになる。
その結果、エージェントを使うエンジニアには、従来はマネジメント層の仕事だった責務が発生する：
- 誤解されない仕様を書くこと
- 各エージェントに何のコンテキストを与えるかを決めること
- 問題を独立した部分に分解すること
- 自分で全部作るのではなく、成果物を評価すること
- 複数の専門エージェントを調整すること
- 一見もっともらしい結果が実は間違っていると気づくこと
AIはエンジニアリング管理を不要にするのではなく、民主化するというのが記事の主張だ。
チップ設計がAIエージェントにとって最難関である理由
ソフトウェア領域との比較で、半導体設計の難しさが浮き彫りになる。
第一の問題はデータだ。 ソフトウェアは膨大な公開コードベースとオープンソースの蓄積から恩恵を受けている。半導体設計データははるかに少なく、多くは非公開だ。記事によれば、デジタル設計プロジェクトはPythonリポジトリと比べて桁違いに少なく、アナログ設計データはさらに乏しい。
第二の問題は、チップは英語を話さないことだ。 エンジニアが扱うのはスケマティック、ネットリスト、配置配線、波形、寄生素子、デザインルール、デバイス物理といった表現形式であり、テキストではない。
ただし、半導体業界はこれらの表現を理解するツールを数十年かけて構築してきた。シミュレーター、フォーマル検証ツール、物理設計ツール、タイミングエンジンがある。AIエージェントはこれらすべてを内部に持つ必要はなく、「どのツールに何を聞くか」「答えをどう解釈するか」を学べばよい。
レビューがボトルネックになる「エンジニアリングのアムダールの法則」
エージェントが実装を得意とするようになると、逆説的な現象が起きる。
生成が増えるほど、レビューが希少になる。
エンジニアが数百行のRTLを書くのに数時間かかるところを、エージェントは数分で複数の実装を生成できる。10個のエージェントを同時に走らせれば10通りのアプローチが得られる。しかし、エンジニアの目は1つしかない。
記事はこれを「**エンジニアリングのアムダールの法則**」と表現する。生成は水平スケールできるが、人間によるレビューは直列のままだ。
Fig. 1: エンジニアリングのアムダールの法則
ソフトウェアでは「ほぼ正しい」解はテスト失敗やロールバックで済む。シリコンでは、「ほぼ正しい」がマスクセットになりかねない。だから目標は「より多く生成すること」ではなく、人間が中間出力を手動で確認しなくても、生成・評価・棄却・改善ができるシステムを構築することだと記事は述べる。
シングルスレッドからマルチスレッドへ
従来のエンジニアは、シングルスレッドのプログラムのように動く。1つの問題を理解し、仮説を立て、実装し、テストして繰り返す。
エージェントを活用すれば、エンジニアは「マルチスレッド」になれる。あるエージェントは波形を調査し、別のエージェントはRTLを追跡し、複数のエージェントが根本原因の仮説を並行して生成し、別のエージェントがそれをシミュレーションやフォーマルツールで検証し、ジャッジが結果をランク付けして、エンジニアは有力な候補だけを受け取る。
記事著者によれば、著者自身が関わるChipAgents（※著者自身のプロダクト）では、この原則に基づいたシステムをすでに構築中だという。根本原因分析において、複数のエージェントがSoCの異なる部分・異なる仮説を並行調査し、絞り込まれた原因候補をエンジニアに提示する、という使い方だ。
アーキテクトに求められる4つのスキル
実装が安価になると、価値は上位の工程に移る。
Fig. 2: AIネイティブなエンジニアに求められる4つのアーキテクチャスキル
希少になるスキルは次の4つだと記事は整理する：
- Intent（意図の定義）： 何を作るべきかを正確に定義する能力
- Decomposition（分解）： 大きなシステムを、人間とエージェントが独立して解ける問題に分解する能力
- Verification（検証）： 「正しい」とは何かを定義し、「ほぼ正しい」解を検出するフィードバックループを構築する能力
- Judgment（判断）： 複数の技術的に妥当な設計の中から、実際に出荷すべきものを選ぶ能力
これらはいずれも従来からアーキテクチャスキルと呼ばれてきたものだ。
さらに記事が指摘するのは若手育成の問題だ。ジュニアエンジニアは実装作業を通じて判断力を養ってきた。エージェントがその基礎作業を担うようになれば、その直観をどう教えるかという新たな課題が生じる。だからこそ、基礎知識の重要性は下がるのではなく、むしろ上がる。委任できるのは、その結果の正誤を判断できる者だけだからだ。
詳細はHow Agentic AI Turns IC Engineers Into Architectsを参照していただきたい。
