設計DRが終わるたびに、議事録のテンプレートだけが綺麗に更新され、肝心の指摘事項が次のDRまでに片付いていない——こんな状況に心当たりはないでしょうか。多くの設計部で、デザインレビュー（DR）は本来の「設計品質を上流で確定させる場」から、「形式上やっておく会議」に変質しています。設計部長が頭を抱えるのは、参加者全員が真面目に参加しているのに、結果として品質トラブルやECN（設計変更通知）の漏れが減らないという矛盾です。本稿では、設計DRが形骸化する5つの構造的理由を分解し、AIエージェントで補える部分・補えない部分を業務単位で整理します。

設計DRが形骸化する瞬間——よくある一日の風景

朝9時、DR会議室。スクリーンには新製品の3面図とBOM、過去類似機の不具合一覧が映っています。参加者は設計者本人、設計課長、製造技術、品質保証、購買、サービス部門。冒頭15分で資料説明、次の60分で各部門が指摘、最後の15分でアクションアイテム確認。表面上は手順通りに進みます。

しかし、終わってみると毎回似たことが起きています。「過去類似機で同じ部位の発熱トラブルが出ていなかったか」という指摘に対して、その場で過去DRの議事録を引いて回答できる人がいない。「次回までに○○を再検討」と決まったタスクが、次回DRの直前に思い出される。最終承認後3週間でECNが3件発行され、現場の組立指示書まで手戻りが波及する。これらは個々の人の能力の問題ではなく、設計DRという業務の構造そのものに原因があります。

形骸化の5つの構造的理由

現場の設計部長と話していると、形骸化の症状はバラバラに語られます。しかし業務フローで分解すると、原因は「人」「プロセス」「情報」「ツール」の4分類に整理でき、最終的に5つの構造に集約されます。

理由1: 出席者の固定化（人）

DRの参加者は、いつも同じ顔触れになりがちです。設計部内のレビュアーは経験年数で序列化され、課長クラスが必ず出席する一方、その分野の最新の不具合事例を一番把握している若手担当者が呼ばれない。製造技術や品質保証も「いつもの担当」が出てきて、設計対象の特性に最適な人が選ばれていません。結果、レビューの観点が固定化し、新しい不具合パターンが見逃されます。

理由2: 議題の雑多さと優先度の不明瞭さ（プロセス）

1回90分のDRに、構造設計・電装・制御・コスト・調達リードタイム・サービス性まで全項目を詰め込もうとして、結局すべてが浅くなる。「重要な論点に時間を割くこと」と「漏れなく確認すること」のバランスが取れず、毎回後者を優先した結果、議論が表層的になります。何をDRで決めるべきか、何を別レビューに切り出すべきか、判断軸が組織として共通化されていません。

理由3: 過去DR議事録・不具合履歴が活用されない（情報）

過去類似機のDRで何が指摘され、何が見逃されて市場不具合になったか——この情報は議事録ファイル、品質トラブル報告書、4M変更履歴、サービスレポートに分散しており、DRの場でリアルタイムに参照できません。「念のため過去事例を確認した」と言いつつ、実際には個人の記憶に頼った確認になっています。FMEAのワークシートも一度作ったきりで、実不具合のフィードバックが反映されていないケースが少なくありません。

理由4: 評価軸（QCD）が共通言語化されていない（プロセス）

「この設計は妥当か」を判断する基準が、レビュアーの暗黙知に依存しています。設計者によって「品質を見るときの基準値」が違い、コストや調達リードタイムへの言及度合いも担当による偏りがあります。組織として「DRで合格と判断するための最低条件」が文書化されておらず、結果として「経験豊富なベテランの感覚」がレビュー品質を決めてしまう。ベテランが退職すると一気にDR品質が落ちます。

理由5: 決定事項のフォローアップが追えていない（ツール・情報）

DRで決まったアクションアイテムは、議事録の末尾に箇条書きで書かれます。担当者と期限はそこに書いてあるはずですが、Excel議事録は次のDRまでアーカイブされて誰も見ません。タスク管理ツールに転記している組織もありますが、設計の3面図やBOMとリンクしておらず、何の設計判断に紐づくアクションなのか追えなくなります。「次回DRで確認」と言っているうちに、設計変更通知（ECN）が出始め、フォローアップが上書きされていきます。

AIエージェントで補える部分と、補えない部分の境界線

5つの理由のうち、AIエージェントが効くのは「情報」と「ツール」に分類される業務です。逆に「人」と「プロセス」は、AIが代替しようとすると失敗します。境界線を業務単位で整理します。

AIで補える業務（情報の構造化と検索）

過去DRの議事録、不具合報告書、FMEAワークシート、ECN記録、サービスレポートを横断して、設計対象の類似機種で「過去にどんな指摘が出て、どう対応されたか」を瞬時に引ける状態を作る——これはAIエージェントの最も得意な領域です。社内に分散している文書を、設計者が今レビュー中の3面図やBOM項目に対して関連付けて提示する。これが実現すると、理由3（過去活用の不在）が直接解消されます。

同様に、DRで決まったアクションアイテムを、設計BOMの該当部品や3面図の特定箇所に紐づけて記録し、ECN発行時にその履歴を参照できる状態を作るのもAIで実装可能です。理由5（フォローアップ追跡の欠落）に対する直接的な処方箋になります。

AIで部分的に補える業務（評価軸の標準化支援）

理由4のQCD評価軸の共通言語化は、AIだけでは解けません。組織として「何を合格基準とするか」を決めるのは設計部長と関連部門のマネージャーの仕事です。ただし、過去DRで実際に問題になった指摘を分類し、「この種類の指摘は何回出て、どの設計フェーズで多いか」を可視化することで、評価軸を作る素材を提供できます。AIは「組織の意思決定を代替する」のではなく、「意思決定の素材を整える」役割に徹するのが正解です。

AIで補えない業務（人の選定と議題の優先付け）

理由1（出席者の固定化）と理由2（議題の優先度）は、設計部のマネジメントの課題そのものです。「この設計対象に対して誰を呼ぶべきか」を判断するには、製品特性・対象市場・想定不具合パターン・社内人材の専門性のマッピングが必要で、これは部門長の判断領域です。AIに「最適な参加者を提案させる」のは技術的には可能ですが、提案の妥当性を組織として担保できないため、運用するとレビュアー間の不和を招きます。

議題の優先度も同様です。「今回のDRで何を最も深く議論すべきか」は、設計の難易度・市場リスク・前回不具合の重さを総合判断する仕事で、設計部長の責務です。AIに「議題を並び替えさせる」のは早計で、まずは部長自身が「重要論点を選ぶための判断軸」を言語化することが先です。

ビフォー・アフターの業務フロー比較

具体的に、AIエージェントが組み込まれた設計DRはどう変わるか。仮想例で整理します。

この変化を支える基盤を、当社では「設計OS」と呼んでいます。図面・BOM・設計変更・DR記録・FMEA・市場品質を一気通貫で扱う業務基盤です。汎用ChatGPTのような「外側に置くAIツール」ではなく、設計業務のデータと意思決定を構造化して保持する「業務基盤としてのソフトウェア」を指します。

ROI試算の考え方

金額換算は組織によって幅が大きいため、ここでは試算の組み立て方だけ示します。設計DRに関連するROI項目は、(1)DR前準備の工数削減、(2)市場不具合の予防（過去事例活用による）、(3)ECN発行件数の削減、(4)アクションアイテム未消化の削減、の4つです。

このうち(1)は工数で直接見える化できますが、本質的なリターンは(2)〜(4)です。市場不具合1件の対応コスト（調査・リコール・顧客対応・社内調整）が大きい組織ほど、設計OSの効果は大きくなります。逆に、市場不具合がほぼゼロで設計品質に余裕がある組織には不要です。「自社のDRで過去どれくらいのアクションアイテムが未消化のままECN発行に至ったか」を1四半期分カウントするだけで、投資判断の素材になります。

自己診断ミニチェックリスト

貴社の設計DRが形骸化リスクを抱えているかを、5項目で確認してください。3つ以上当てはまる場合は、上記の構造的理由のいずれかが進行している可能性があります。

• 過去3ヶ月のDR議事録を、今この瞬間にキーワードで横断検索できない
• DRで「過去類似機で同様の不具合がなかったか」と聞かれた際、その場で根拠を引けない
• DRの参加者リストが過去2年で実質的に変わっていない
• 1回のDRで議題が10項目以上あり、深く議論できているのは2〜3項目だけ
• 前回DRのアクションアイテムのうち、期限内に完了したものを確認する仕組みがない

反論への先回り——「うちはそこまで困っていない」と感じた方へ

ここまで読んで、「うちのDRは機能している、AIで仕組みを変える必要はない」と感じた方もいらっしゃるかもしれません。その判断は正しい場合があります。具体的には、(a)設計対象の機種数が少なく1人の設計部長が全製品を把握できる、(b)市場不具合の発生頻度が極めて低い、(c)設計者の入れ替わりが少なく暗黙知が継承されている、の3つすべてが成立する組織です。この場合、設計OSのような業務基盤の投資対効果は出にくく、むしろ既存運用の徹底が優先です。

逆に、機種数が増えている、ベテラン設計者の退職が見え始めている、または市場不具合のリピート率（同じ部位での再発）が一定以上ある組織は、暗黙知の依存度が組織的リスクになり始めています。「困っていないから不要」ではなく、「困りが顕在化する前に基盤を作る」のが、設計OSのような業務基盤への投資の本質です。汎用ChatGPTで済むかという問いには、「Excel議事録の要約だけなら可能、ただし設計BOMや3面図と紐付いた構造化記録は別の仕組みが要る」と申し上げています。

次のアクション

本稿の5つの理由を、貴社の設計DRに当てはめて整理する作業を、30分の業務診断（無料）で行っています。具体的には、直近3ヶ月のDRで実際に発生した指摘・アクションアイテム・ECN発行事例を題材に、形骸化の主因がどの理由（1〜5）に偏っているかを可視化します。当てはまり方によって、設計OSが効く業務と効かない業務が明確に分かれます。

関連記事

• 設計部長が知らないと損する、図面検索の本当のコスト——年間1,200時間が消える理由——DR前準備で消える時間の構造を、図面検索の側面から分解した記事です
• 業務OSとは何か——製造業ERPでもPLMでもない、第3の業務基盤の正体——本稿で言及した「業務基盤としての設計OS」の上位概念を解説しています（5月1日公開）
• 設計OSとは——図面・部品表・設計変更を一気通貫させる業務エージェント基盤——DR記録と設計BOM・ECNを統合する業務基盤の中身を整理しています（5月2日公開）