図面を一枚描かせるのではなく、筐体やプリント基板からファームウェアまで、デバイス全体をAIに任せることはできるのだろうか。2026年11月3日、OpenAIは、AstraモデルがGPT‑6とともに、Codexと対話するためのデバイスの設計を支援した実験について説明した。エンジニアにとって重要な結論は、AIの有用な役割は複数の設計工程を結び付け、反復を速めることにあるという点だ。デジタルモデルから製造可能な製品へ移行するには、今も構造や製造工程に関する細部の確認が欠かせない。

説明によると、このプロジェクトではまず機能要件を定めた。その後、Astraが外観、筐体、内部構造を設計し、電子部品を選定。部品の配置と接続を含むプリント基板を設計し、インターフェース、ファームウェア、ソフトウェア連携も準備した。これは一連の工程が結び付いたワークフローだ。筐体の寸法変更は基板の配置に影響する可能性があり、部品やその接続方法は構造の選択肢を制約する。
モデルの作業で何が変わったのか
一般的な画像生成AIが答えるのは、「どのような見た目になり得るか」という問いだ。OpenAIが説明した手法は、要件、機械的な形状、電気回路、ソフトウェアを一つのタスクの中で扱い、これらの表現をより緊密に結び付けることを目指している。エンジニアにとって重要なのは、表現間の移行だ。たとえば、基板が筐体に物理的に収まり、選定した部品がデバイスの想定機能に合っていることを確認する必要がある。
OpenAIによると、2人の社員が副業的なプロジェクトとして1週間足らずで試験用デバイスを作り、受託製造業者は1か月足らずで少量の試作機を製造した。これらは特定の社内実験と説明された試作機に関する期間だ。構想から実物の試作機まで迅速に進められる可能性は示すものの、他のデバイスやチームにおける設計速度を一般化して評価できるものではない。
この事例が興味深いのは、AIが単一の成果物を作るだけにとどまらなかった点だ。モデルが筐体、基板、ソフトウェアの整合を支援すれば、異なるツールや専門家の間で成果を受け渡す際に表面化しがちな相互依存関係を、エンジニアがより早く把握できる。複数分野の調整を一人で担うこともある小規模チームでは、とりわけこうした連携が重要になる。
デジタル設計だけでは製造に進めない理由
画面上では整合して見える構造をモデルが提案しても、実際の製造上の制約が考慮されていないことがある。この実験についてOpenAIは、Astraが製造業者の制約、公差、組み立てに必要な細部を一貫して考慮できなかったと明らかにした。そのため、製造に向けた準備では、確認と修正を何度か繰り返す必要があった。

この隔たりが生じる仕組みは実務的なものだ。デジタル設計では形状と部品同士の位置関係が定められるが、製造には寸法の許容誤差、加工方法、組み立て要件など、具体的な条件が加わる。筐体内の余裕が少なすぎたり、部品の取り付け方法が考慮されていなかったりすれば、ファイルとしては整っていても、指定された工程で製品を作るのが難しい、あるいは不可能になる。
したがって、責任分担は明確だ。モデルは選択肢の準備と調整を支援し、専門家は設備、材料、製造業者の工程との適合性を確認する。チームは3Dモデルの見栄えではなく、実用的な試作機を完成させるまでに、重要なエンジニアリング確認や修正がどれだけ残っているかを基準に成果を評価するとよい。
すでに具体性が見えている活用法
OpenAIの社内ハードウェアチームは、CADモデルの作成・変更、製造図面の準備、シミュレーションの設定、構造の分析にCodexとChatGPTを使っている。同社の発表によると、ハードウェアチームにおけるモデル利用量は、トークン数で測ると2月以降23倍に増加した。この指標が表すのは、これらのチーム内でのモデル消費量であり、設計期間やコストの削減ではない。
Chip Ganassi Racingとの協力では、既存部品の3Dスキャンから、編集可能なCADモデルと製造図面へ移行する方法をチームが研究している。元の設計ファイルがない場合に有用な手法だ。スキャンを形状復元の出発点とし、パートナー側のエンジニアが図面の正確さと製造適性を確認する。
Mazdaとの共同作業では、自動車設計にモデルを活用し、車両前部の形状を検討して空気の流れをシミュレーションし、性能、デザイン、コストを踏まえて案を比較している。OpenAIはこれを研究協力と位置付け、結果は後日発表する予定だと説明している。この手法の狙いは、より多くの形状案を検討し、空力シミュレーションと構造上の判断をすばやく結び付けることにある。ただし、公開資料からは、完成車の性能向上を示す数値はまだ分からない。
エンジニアリングチームがシステムを評価する方法
OpenAIは、プログラミングとエンジニアリングの知識を組み合わせたタスクにおけるモデル評価の一つとしてBenchCAD 2.0を挙げている。このテストでは、3D部品やアセンブリの再構築と、プリント基板上の接続関係の認識を評価する。この評価で新しい社内モデルは平均0.875を記録し、最大推論モードのGPT‑6 Astraは0.594だった。
実用面では、この結果は形状の生成や接続関係の認識という特定のタスク領域で進歩があったことを示す手掛かりになる。しかし、材料選定、熱・機械試験、認証、製造可能性の確認を含む開発サイクル全体を測るものではない。そのため、チームは自社の代表的なタスクでモデルを試し、どの出力ファイルがエンジニアリングツールにそのまま受け入れられ、どれに手作業での修正が必要なのかを記録するとよい。
実用的な試験運用は、繰り返し行う工程を一つ選んで始められる。たとえば、部品スキャンのCAD化、図面の準備、シミュレーションの初期設定などだ。各タスクについて、受け入れ基準を事前に定め、形状や制約を確認するエンジニアを任命し、製造業者への引き渡し前に必要な修正を記録する。そうすれば、モデルが定型作業をどこで軽減し、どこで追加の確認工程を生んでいるかを把握できる。
設計と検証の境界が重要
OpenAIのプロジェクトは、AIを文章、コード、単独の画像だけでなく、物理設計の連携した工程に活用できることを示している。システムが機械、電子回路、ソフトウェアの間で要件や案をすばやく調整できれば、その効果が生まれる。しかし、製造適性の確認は別個のエンジニアリング課題だ。公差、組み立て、そして個別の製造工程の能力によって決まる。
ハードウェア製品の開発者にとって、評価を始める際の指針は明快だ。範囲を限定して検証可能な工程から着手し、生成したモデルの数ではなく、エンジニアの承認に至るまでの手作業による修正量を測る。この方法なら、案をすばやく生成する利点を活用しつつ、デジタル設計が物理的な製品へ変わる段階で人の管理を保てる。