「生成AIを設計業務に使う時代です」
最近、社内外のセミナーでこんな言葉を耳にすることが増えました。
けれど、実務の設計者としてはこう思いませんか？
「AIに何を聞けばいいの？」
「そもそも設計レビューで使えるの？」
「AIが何か“答えてくれる”って言われても、結局は人が考えるんじゃないの？」
これらの疑問は私自身が感じていたこと、まさにそのものの声です。
不安に思いながら足踏みするくらいなら、まずはスモールスタートで良いので試してみる精神で、実際に生成AI（Copilot）を試験的に活用してみました。
本記事ではその体験をベースに、「実務レベルでAIをどう使えば役に立つのか？」を具体的なシーンを交えながら紹介します。
生成AIは魔法の道具ではありません。でも、使い方次第で“気づけなかったことに気づく”強力な補助ツールになります。
同じようなお悩みを抱えている設計の実務者の方にとって、少しでも参考になればうれしいです。
設計変更で生まれる“見落とし不安”
設計者であれば一度は経験したことがあるはずです。
「あの変更、あの確認、ちゃんとやっていたっけ？」
「あの不具合、最初から想定できなかったのか？」
設計変更は、コストダウンや性能改善など前向きな目的で行われることが多い一方で、それに伴うリスクの“見落とし”が重大な不具合に直結するという怖さを持っています。
なぜ“見落とし”が起きるのか？
実際の現場では、設計変更を進める際に以下のような状況がよくあります。
- タイトな納期に追われて、変更内容の影響範囲を短時間で判断する
- 担当者の交代や属人化により、過去の知見が共有されていない
- 複数部門をまたぐ検討が必要なのに、連携が形式的になってしまう
- DRBFMなどのフレームワークを使っていても、“確認作業”が目的化してしまいがち
どんなに優れたツールや手法があっても、それを扱う設計者が判断の幅を持って検討しなければ、「リストにないことは検討されない」という状態になりかねません。
設計変更は「見えている範囲の外」にこそリスクがある
設計変更では、変更箇所だけに目が行きがちです。
しかし、例えば過去のトラブル事例を見ると、
- 微細なレイアウト変更による放熱経路の変化
- ほんの数ミクロンの寸法調整による組立時に受ける応力の増加
- 材料変更が原因で起きた予期せぬ経年劣化
といった、「気づいていれば回避できた」失敗が多く見られます。
つまり、人間が意識の外に置いてしまうことこそが、不具合の芽になりやすいのです。
既存のプロセスで限界を感じたとき、AIを試してみた
私はとある製造メーカで電子部品の設計を担当していたことがあり、当時は従来通りのDRBFM（Design Review Based on Failure Mode）の手法を用いて検討を進めていました。
- 変更内容の把握
- 機能や仕様の整理
- 懸念点の抽出
- 評価条件の検討
一見、手順通りに進んでいましたが、「この変更、本当に見落としはないのか？」ふと不安がよぎりました。
もちろん、当時は社内に蓄積された資料や過去の知見も自分で探して、できるだけ抜け漏れのないように情報を集めました。
しかし、周りに有識者が少ないこともあり、私の判断がそのまま採用される形で通ってしまうことも多く、本当にこれで十分なのか日々不安と疑問を感じながら業務にあたっていました。
その後、担当業務も変わりましたが、あらためて生成AIが普及してきた今の時代に、ある思いがふと頭をよぎりました。
「あの頃の設計業務を生成AIと一緒に進めていたら、どうなっていただろうか？」
そこで、次の章では、生成AIを実際に試してみた結果として、具体的に検討の幅がどのように広がったのか、設計プロセスのどの範囲まで使えるのか、現場目線でお伝えしたいと思います。
設計プロセスを俯瞰して見直す 〜AIが入り込む余地とは？〜
前章では、見落としへの不安や、変更時の懸念がどこから来るのかについて触れました。
では、そもそも設計変更における一連のプロセスは、どのようなステップで構成されているのでしょうか？
設計部門の多くが使っているDRBFMやFMEAの手法も、実際の現場では「忙しさの中で形骸化してしまっている」「リスク抽出が網羅的にならない」といった声も聞こえてきます。
ここで一度、代表的な設計変更プロセスの流れを整理してみましょう。
設計変更における標準的な業務プロセス
以下の表は、設計変更における標準的な業務プロセスの例です。
リスク検討という意味では、Step3以降のイメージを強く持たれるかもしれません。
しかし、「Step1 目的・背景の明確化」や「Step2 機能・要求仕様の整理」は、あらためて全体像や制約条件を明確にするプロセスで、軽視してはいけません。
リスク評価に実際に着手してから、後になって「そもそも何のために変更する必要があったのか？」という問いかけが生まれていないでしょうか？
ちょっとしたメリットに飛びついて設計変更したのに、実はリスク評価のほうが大変過ぎて変えなきゃよかった・・・なんてことは起きていないでしょうか？
そもそもの目的をきちんと共有した上で、リスクを取るだけの価値があることを踏まえて、検討プロセスを進める判断を下すのが望ましいです。
また、Step2については、これが意外とできていないのですが、変更対象の製品・部品は何の機能を果たすものなのか？という点です。
そして、その機能をすべて満足するためには、何が必須条件なのか、この点を明らかにできているか否かで、Step3以降のリスク抽出と評価の質に大きく影響します。
Step2の具体的な進め方は後ほどの章で説明します。
「見落としの起点」はどこにでもある
こうして見ると、一つひとつのステップが大きな「見落としの起点」になり得ることが分かります。
特に、影響範囲の洗い出しや懸念点の抽出は、過去の知見や複雑な因果関係が絡み合う領域であり、ベテラン設計者でも悩ましいところです。
そこで、生成AIの出番です。
単なるアイデア出しではなく、過去の設計資産やレビュー情報を踏まえて、“抜け漏れのない準備”を支援するツールとして、実務での活用が進んでいます。
次章では、実際に私がトライアルしたセラミック配線基板の設計変更を題材にして、具体的なAI活用のシーンを紹介します。
【事例】設計プロセスと生成AIの融合 ～パワーデバイス向けセラミック配線基板～
まず、全体像として、先ほどご紹介した一連の設計プロセスのどのステップに生成AIが活用できる可能性があるのか、ご覧いただきましょう。
これは私が実際にトライアルでやってみたステップの例です。
水色でハイライトした部分が「設計者から生成AIにインプット」する情報、緑色でハイライトした部分が「生成AIから設計者にインプット」する情報を表しています。
これだけではイメージが付きにくいと思いますが、各ステップでこんなにも生成AIとキャッチボールできる要素があるんだ！？という程度で捉えていただければと思います。
設計者と生成AIのやり取りをもう少し整理した概念図が以下になります。
当然ながら、最初にボールを投げる（情報をインプットする）側は人間である”設計者”になります。
ここで準備する情報の質によって、どれだけ生成AIのパフォーマンスを発揮できるか決まると言っても過言ではありません。
以降では、私が実際にトライアルで実施したデータを例に説明します。
※この記事で紹介するデータはすべてトライアル用に架空の値を入れたものです
機能・要求仕様（設計者⇒生成AI）
Step2が重要と説明したのは、ここでも関わってくるのですが、対象製品の機能はそもそも何なのかという点です。
さらには、その機能を発揮するための要求仕様、あるいはお客様からの要求仕様など、制約条件となるものを整理します。
項目を漏れなく挙げることも重要ですが、さらに効果を高めるためには、仕様や目安となる値・条件が何をもって決まったのか、技術的な背景や理由を併記するのが良いと思います。
まさにこの部分が「ナレッジ」の情報であり、人間の頭で記憶しきれない情報をきちんと文書化して残し、さらにはそれをAIに学習させることで、検討の質がますます高まります。
設計変更点（設計者⇒生成AI）
次にインプットするのが、設計変更点です。
Before / Afterで何をどう変えたのか、リスト形式でインプットするのが良いと思います。
この時、変更点の抽出漏れを減らすには、QC工程表を用いて工程全体を網羅的に見るなど、思いつきの項目の列挙にならないようにしましょう。
過去トラブル事例（設計者⇒生成AI）
会社ごとのノウハウが詰まっているのが過去トラブルの事例集です。
類似機種で起きた不具合や、具体的な不具合発生の条件、対策の内容など、リスクを考えるうえで重要な情報です。
この情報をいかに多く学習させるか、より具体的な情報をインプットできるかによって、生成AIからの回答の質も漠然とした内容か、具体的で的を射た内容になるのか左右されます。
社内設計基準（設計者⇒生成AI）
社内設計基準は制約条件として必要になる情報です。
具体的にいくつの範囲まで許容できるのか、あるいは後工程の情報も含めて、これを満足することが大前提になります。
DRBFM形式でのリスク抽出（生成AI⇒設計者）
ここまでの情報を順番に学習させたら、いよいよ生成AIの助けを借りる番です。
設計変更に対して、DRBFMの視点で懸念事項を整理して。
■影響を受ける機能・部位
■懸念される事象（具体的に）
■その要因（なぜ起こるか）
■社内設計基準との照合
■関連部品への影響
■確認項目／設計での対策
すると次のような表が生成AI（Copilot）から返ってきました。
取り込んだ情報を上手く反映させて、DRBFMの形式で回答を出力してくれています。
懸念事象や技術要因など一般知識ではありますが、とても的確なコメントに思います。
また、確認項目についても、シミュレーションから実サンプルでの検証、さらには分析方法まで幅広い視点で項目をリストアップしてくれています。
この内容でもDRBFMのたたき台としては十分といったところですが、ここでもう一つ質問を加えてみました。
変更よって意図しない変化が生じた場合の波及リスクは？
「変更」と「変化」は別ものです。「変更」は意図して「変えること」、「変化」は意図しないものも含めて「変わったこと」です。
最も見落としがちなのが、意図しない変化によるものであり、実は他の部品や後工程に影響していて別の弊害が出てしまった、という実例も少なくありません。
このように、生成AIでは一般的な知識をもとに波及リスクの抽出までサポートしてくれるので、特に経験の浅い設計者にとっては大変心強い伴走者と言えるかと思います。
私自身感じたこととして、このステップでの変更点・変化点の抽出が生成AIを活用する一番のメリットと思われ、このツールがあるとどれだけ質の高いレビューができていたか、心にしみました。
評価方法のアドバイス（生成AI⇒設計者）
生成AIの活用術はまだ他にもあります。
DRBFMのシートで確認項目を抽出しましたが、これを具体的な評価計画に落とし込む必要があります。
専門的な知識を持った設計者であれば、あとは自分で考えて計画を立てられますが、初心者の場合では何をどう具体化すれば良いのか迷うかもしれません。
例えば、「断面SEM観察」や「XPS分析」といった専門用語が登場しても、ピンとこないかもしれません。
それぞれどのような分析手法なのか、インターネットで調べれば概要を把握することは可能です。
しかし、生成AIを使えばさらに詳細のアドバイスまでサポートしてくれるのです。
以下を具体的に教えて
断面SEM観察：観察倍率、観察箇所
XPS分析：対象のスペクトル、異常有無の目安
分析に精通したエンジニアであれば当たり前の情報ですが、初めて触れる場合には考察の糸口につながる貴重なアドバイスではないかと思います。
もちろん、生成AIの回答を鵜呑みにするのではなく、きちんと熟練の設計者や分析のプロに監修してもらうことが必要です。
しかし、少なくとも意見を求める前段階の予備知識として頭に入れておくことで、有識者に一から説明してもらう手間を省くことが期待できます。
スケジュール案の作成（生成AI⇒設計者）
ここまでに紹介した生成AIの活用術でも十分に設計者のサポートに有効かと思います。
しかし、生成AIはとても優秀で、なんと設計者が評価するスケジュール案まで考えてくれるのです。
確認項目の評価スケジュール案を作成して。
担当の設計者は3名とします。
W1からW5は週を表します。
あらかじめ生成AIに質問を入れる際に、評価項目と担当者を行に、週を列に取るように指定すると、このような形でドラフト案を作成してくれました。
ガントチャート（プロジェクトの進捗状態を可視化するためのスケジュール表）の見かたとして、例えば一行目の収縮率の試作の場合、1週目に3日（バーの長さ）、2週目に1日かかるという具合いです。
このドラフト案の素晴らしいのが、設計者Ａ～Ｃでそれぞれ担当を割り振って、さらにすぐに結果の出る分析と時間のかかる試作を上手く振り分けて、といった形で組まれています。
もちろん内容の精査は必要ですが、ゼロからスケジュール表を作り込むよりも、圧倒的に作業時間を減らすことが期待できます。
報告書・レビュー資料の作成（生成AI⇒設計者）
いよいよ最後ですが、ここまでに整理した評価を実施した後は、評価結果報告書としてまとめ、さらには後工程などの関係者へのレビュー資料として申し伝えることが必要です。
当然ながら、すでに色んな情報を学習済みの生成AIであれば、章立ての提案から表・グラフのテンプレートの提案、さらには評価結果をインプットすれば報告書やレビュー資料のドラフト案も作成してくれます。
考察や結論を導く部分は人間の設計者がきちんと責任を持って判断することが必要ですが、ドラフト案の作成だけでも設計者の手間を省く十分な助けになろうかと思います。
最後に
生成AIは“使うか悩むもの”から“ともに考える相棒”へ
今回の記事では、セラミック配線基板の設計変更を一つの例として、生成AIが設計プロセスの中でどのように活用できるかご紹介しました。
実務の設計者にとって、設計変更は常にリスクと隣り合わせです。「見落としがないか」「試験条件や検証観点は適切か」「スケジュールは現実的か」……。
こうしたプレッシャーの中、短納期と高精度が求められる現場では、思考と資料作成の往復で毎日が過ぎていきます。
生成AIは、そうした設計業務の“雑務”や“思考の整理”において、とても頼りになる存在です。
もちろん、AIの出力がそのまま使えるわけではありません。
前提条件の提示、過去情報の共有、状況に応じた調整など人間の知見と判断は不可欠です。
しかし、設計者の「問い」に対して「たたき台」を即座に出してくれる存在として、AIは確実に私たちと並走する設計者の一員となりつつあります。
例えば
- 忙しい週明け、DRBFMの洗い出し項目を整理してくれていた
- 試験仕様を考える際に、見落としがちな観点をAIが指摘してくれた
- 部門レビューの資料を作る際、ドラフトをAIが用意してくれていた
そんな「ひと仕事を一緒にこなす感覚」が生まれつつあるように感じました。
生成AIとの共創は、実務設計者にこそ必要なスキル
AIの活用は、決して大げさなDXの話ではありません。
むしろ、目の前の一枚のチェックリストや、一通のレビュー依頼メールをどう処理するかという「現場の悩み」に応えるツールです。
設計者自身が「何に困っているのか」「どこで助けてほしいのか」を言語化し、AIに投げかけることで、次の一歩が見えてきます。
生成AIは、“人間の代わり”ではなく、“ともに考える相棒”へ。
今回のトライアルを通じて、設計の品質を高めるその瞬間にAIを使いこなす未来の設計者の姿が垣間見えたような気がしました。
最後までご覧いただきまして、ありがとうございました。
皆さまの設計プロセスの一助になれば幸いです。
コメント