「この図面、あの人に見てもらわないと不安だ」。検図（設計審査）の前に、特定のベテランの予定を確認してから図面を回す——そんな運用になっている設計部門は少なくありません。その人が見れば危ないところを拾ってくれる。逆にその人が多忙だと、検図は形式的な承認印だけになり、後工程や客先で問題が顕在化します。

結論から言えば、これは検図者個人の優秀さや若手の経験不足の問題ではなく、指摘の「観点」が図番に紐づかず、個人の記憶にだけ残るという業務構造の問題です。図面は直っても、なぜ直したのかという勘所は組織に残りません。

この記事では、検図がベテラン頼みになる構造を3つに分解し、設計OS（AIエージェント基盤）でそろえられる範囲と、人が握り続けるべき判断を整理します。読み終えたときに、自社の検図で「まず図番に紐づけて残すべき観点1つ」が見えている状態を目指します。

検図とは？なぜ属人化しやすいのか？

検図とは、作成した図面が要求仕様・製造性・過去の不具合の観点から問題ないかを、設計者以外の目で確認する工程です。品質マネジメントの国際規格でも、設計・開発のレビュー（デザインレビュー、DR）は要求事項として位置づけられています（出典：JIS Q 9001:2015 8.3.4 設計・開発の管理）。つまり検図は個人の善意ではなく、本来は仕組みで担保すべき業務です。

それでも検図が属人化するのは、確認すべき観点の多くが明文化されていないからです。公差の与え方、干渉のリスク、加工・組立のしやすさ、過去に似た形状で起きたクレーム——これらは規格書や標準に載っていない「勘所」であり、多くは過去の失敗経験から個人の中に蓄積されます。図面という成果物は残っても、その観点は残る場所を持ちません。

結果として、検図にかかる時間の多くは、図面そのものを技術的に評価する時間ではなく、判断材料を探す時間に消えていきます。下の図は、検図1件あたりの時間配分を模式化した参考図です。

上の図は割合を模式化した参考図で、実測値ではありません（案件や現場の管理状態により大きく変わります）。注目してほしいのは個々の数字ではなく構造です。「過去の指摘を探す」「類似図面を確認する」「レビュアーの空きを待つ」に時間の6割前後が食われ、公差や干渉といった本来の技術判断が一部にとどまる——この構造に心当たりがあるなら、それは検図者のスキル不足ではなく、判断材料が引き出せる形で残っていないことの結果です。

検図がベテラン頼みになる3つの構造とは？

検図の属人化は、「観点」「履歴」「負荷」という3つの情報・状態が、いずれも個人に閉じることで起きます。順に分解します。

構造1：指摘の観点が明文化されず、レビュアーの頭にしかない

検図でベテランが見ている観点は、多くの場合チェックリスト化されていません。「この部位は熱で伸びるから公差を詰めすぎない」「この形状は過去にバリで組立不良を出した」といった勘所は、汎用的な項目表には落とし込みにくく、案件ごとに異なります。観点が言語化されないまま個人に蓄積されるため、その人がいなければ同じ視点で図面を見られません。

構造2：過去の指摘・不具合履歴が図番に紐づかない

DR会議の議事録や不具合報告書は存在しても、それが今まさに検図している図面と結びつきません。似た構造の製品で過去に何を指摘したかを引き出すには、記憶に頼るか、大量の議事録を掘り返すことになります。だからこそ、同じ種類の指摘が案件をまたいで繰り返され、設計変更（ECN）として後追いで直す事態が減りません。既存の基幹システムがあっても、この「引き出せなさ」は残ります。

ERPは「お金とモノの記録台帳」、PLMは「図面とBOMの保管庫」であり、いずれも「業務そのもの」を実行する仕組みではない。

「この仕様で大丈夫か」に即答できる人が限られる——技術問い合わせ対応が属人化する構造と、業務OSでそろえられる範囲

構造3：検図できる人が限られ、レビュー負荷が集中する

観点と履歴が個人に閉じている結果、まともに検図できる人が1〜2名に限られます。その人に図面が集中すると、多忙な時期には確認が浅くなり、見逃しが増えます。逆に若手は、指摘された理由を体系的に学ぶ機会がないまま「言われたから直す」を繰り返し、観点が育ちません。属人化がさらなる属人化を生む循環です。この構図は検図に固有のものではなく、他の設計・品質業務でも同じ形で観察されます。

記録の入れ物は各所にあるのに、判断に使える形で引き出せない、という共通点です。

測ってはいるのに、検査成績書づくりで時間が溶ける——検査記録が現場と個人に散らばる構造と、品質OSでそろえられる範囲

設計OS（業務基盤）は検図の何をそろえ、何を人に残すのか？

設計OSがそろえられるのは、検図の「判断材料」であって「判断そのもの」ではありません。設計OSとは、図面・過去の指摘・不具合履歴・類似案件を、図番や製品に紐づけて検索・提示できる業務基盤を指します。汎用の生成AIツールと違い、自社の設計資産に紐づいて動く点が本質です。次の表は、検図に関わる情報ごとに、個人に閉じた運用で起きることと、業務基盤に載せられる範囲、人が握り続ける判断を整理したものです。

重要なのは、設計OSは検図者を置き換えないという点です。担うのは、レビュアーが本来なら記憶や勘に頼って思い出していた「見るべき観点」を、過去の指摘から引き当てて先に並べておくことです。人は空白から観点を絞り出すのではなく、提示された候補から取捨選択し、技術判断に集中できます。下の図は、検図で得た観点が「個人に閉じる運用」と「設計OSに載せた運用」でどこに残るかを対比した概念図です。

投資対効果は、金額を先に置くより「観点が残らないことで毎回発生している再作業」を数える発想で考えるのが現実的です。同種の指摘を後追いの設計変更で直す件数、検図待ちで止まっている図面の滞留、ベテラン1名への問い合わせ時間——これらが観点の共有でどれだけ減るかが評価軸になります。

業務OS（AIエージェント基盤）がそろえられるのは、類似案件の検索・候補回答と出典の提示・履歴の全社共有までです。

客先で直した内容が、次の号機に返らない——据付・試運転の現地調整が個人に閉じる構造と、業務OSでそろえられる範囲

自己診断：検図の観点は「人」と「図番」のどちらに紐づいているか

次の5項目のうち3つ以上に「はい」がつく場合、検図は仕組みではなく個人に支えられている可能性が高い状態です。設計OSのような業務基盤で観点を束ねる余地が大きいと言えます。

• 特定のベテランが検図に入れないと、図面を先に進めにくい。
• 過去に似た図面で何を指摘したかを、記憶か議事録掘り返しでしか引き出せない。
• 同じ種類の指摘や不具合が、案件をまたいで繰り返し起きている。
• 検図で「なぜ指摘したか」の理由が、図番に紐づく形では残っていない。
• 若手が検図の観点を体系的に学べる資料や仕組みが社内にない。

「検図はベテランの目でないと無理」は正しいのか？

半分は正しく、半分は構造の問題です。設計の妥当性を最終判断する技術力は、確かに経験に裏打ちされたベテランの領域であり、そこをAIが置き換えるべきではありません。

ただし「ベテランでないと無理」の中身を分けると、多くは技術判断そのものではなく、判断に入る前の「思い出す作業」です。過去に何を指摘したか、似た図面はどれか、どの部位が危ないか——この想起を個人の記憶に依存させているから、その人しかできなくなります。想起の部分を業務基盤に移せば、ベテランは技術判断に集中でき、若手も同じ観点の入口から検図を学べます。全数の観点を一度に移す必要はなく、指摘の多い図番から小さく始めるのが定着の条件です。合わないのは、そもそも検図対象がごく少量で、観点の再利用がほとんど発生しない現場です。

自社の検図で、観点がどこまで「図番」に紐づいているか。まずは問い合わせや後追い設計変更の多い図面から、観点の残り方を棚卸ししてみてください。

よくある質問

検図チェックリストを作れば属人化は解決しますか？

チェックリスト単体では解決しないことが多いです。汎用的な項目表は作れても、過去の指摘や不具合から生まれた勘所は案件ごとに異なり、対象の図番や製品に紐づけて引き出せなければ更新も参照も止まります。過去の指摘履歴を設計対象に結びつけ、類似設計時に自動で観点を提示する仕組みまで含めて、初めて機能します。

ベテランが在籍しているうちに検図の観点を残すには何から始めればよいですか？

流用・再設計の頻度が高い図番から着手するのが現実的です。全図面を網羅するより、よく手が入る設計について「過去にどんな指摘・不具合があったか」「なぜその公差・形状にしたか」を一問一答で図番に紐づけて残すほうが、負荷対効果が高くなります。まず10図番からの部分着手で効果を確認できます。

検図の観点をAIに任せると、レビューの質が下がりませんか？

任せる範囲を分ければ質は下がりにくいと考えられます。AIエージェント基盤が担うのは、類似図面の抽出と過去指摘・観点の想起、抜け漏れ候補の提示までです。指摘を出すか、設計が妥当かという技術判断は人が握り続けます。人の判断を置き換えるのではなく、判断に入る前の準備時間を圧縮する位置づけです。

次に読みたい関連記事

• その治具がなぜその形なのか、作った本人しか答えられない——治具の設計意図が個人に閉じる構造と、業務OSでそろえられる範囲
• 「この仕様で大丈夫か」に即答できる人が限られる——技術問い合わせ対応が属人化する構造と、業務OSでそろえられる範囲
• 測ってはいるのに、検査成績書づくりで時間が溶ける——検査記録が現場と個人に散らばる構造と、品質OSでそろえられる範囲

出典

• JIS Q 9001:2015（ISO 9001:2015）品質マネジメントシステム 8.3.4 設計・開発の管理（設計・開発のレビュー／検証／妥当性確認の要求事項）
• 本文中の時間配分および観点の残り方の図は、業務構造を説明するための参考図であり、実測値ではありません。割合は現場の管理状態・案件により大きく変わります。