機械設計の要求仕様書の作り方｜設計条件・受入基準・トレーサビリティを実務で整理する

設計は図面を描く前から始まっている

機械設計の出発点はCADではない。「何を、どの条件で、どの程度達成すれば合格か」を決めることにある。要求が曖昧なまま詳細設計に進むと、図面が完成しても、強度計算・機器選定・試運転の合否を判断できない。

本記事では、要求仕様を単なる要望の一覧ではなく、設計判断と検証を結ぶ契約として扱う。要求の抽出、制約との分離、定量化、トレーサビリティ、変更管理までを、架空の油圧昇降装置で一貫して説明する。例示する数値は教育用の仮定であり、実機の推奨仕様ではない。

機械設計の全体像：要求から受入まで

設計業務は「構想→CAD→製作」の一方向だけではない。要求を満たせる根拠を段階的に積み上げ、必要に応じて前工程へ戻る反復プロセスである。

flowchart TD
  A[利用目的と使用条件] --> B[要求と制約の明確化]
  B --> C[機能分解と構想比較]
  C --> D[荷重条件と設計計算]
  D --> E[部品選定と図面・BOM]
  E --> F[製作・組立]
  F --> G[要求ごとの検証]
  G --> H[実使用での妥当性確認]
  G -->|不適合| B
  H -->|用途との不一致| B

各段階で残すべき成果物

**検証（verification）**は仕様への適合確認、**妥当性確認（validation）**は意図した用途への適合確認である。例えば「15秒以内に上昇する」という試験に合格しても、作業者が安全に積み降ろしできなければ、用途としての妥当性は未確認のままである。

要求・制約・設計解を混同しない

要求は達成すべき状態、設計解は実現手段

「φ63のシリンダを使う」は、特定の採用理由がない限り要求ではなく設計解である。一方「指定した荷重を指定時間内に持ち上げる」は、装置が実現すべき機能・性能要求になる。

「予算100万円以内」は一般にプロジェクト制約であるが、契約上の受入条件にもなり得る。分類名よりも、誰が変更を承認でき、どの証拠で適合を判定するかが重要である。

要求文を検証可能にする六つの要素

要求を記述するときは、対象、動作・特性、定量基準、適用条件、検証方法、根拠・出典を一組にする。

• 対象：装置全体か、シリンダか、制御盤か。
• 動作・特性：上昇推力、位置決め、停止など何を規定するか。
• 定量基準：下限・上限・公差・時間・頻度を明示できるか。
• 適用条件：温度、負荷、供給圧力、測定位置、運転モードは何か。
• 検証方法：試験・解析・検査・実演のどれで確認するか。
• 出典と責任者：顧客要求、法規、安全分析、社内仕様のどれに由来するか。

悪い例：「十分な力で速く動くこと」。改善例：「指定した使用条件において、出力端で20 kN以上の上昇方向推力を発生し、500 mmの上昇動作を15 s以内に完了すること」。ただしこの改善例も、温度・測定方法・負荷変動が未定なら最終仕様ではない。

要求仕様書に必要な設計変数と単位

架空の垂直昇降装置について、検討開始時の要求候補を整理する。荷重と推力は区別し、荷重の内訳・摩擦・加速度を含む必要推力の定義を別途明確にする。

荷重・圧力・流量を指定するときは、最大値／最小値／通常値／異常時値を混同しない。10 MPaを「常用圧力」「設計上限」「試験圧力」のどれとして扱うかで、要求の意味が変わる。

代表計算例：要求の成立性を初期段階で確かめる

この計算は、要求仕様の数値に対して候補方式が概ね成立するかを調べる構想段階の概算である。実機の安全性、シリンダ選定、法規適合を証明するものではない。

推力要求を満たせるか

単動の押し側を想定し、圧力差をシリンダ有効差圧として近似する。断面積 $A$ と推力 $F$ の関係は次のとおり。

$$ A = \frac{\pi D^2}{4} $$

$$ F = p A \eta_F $$

ここで、$A$ は受圧面積（m²）、$D$ は内径（m）、$p$ は有効差圧（Pa）、$F$ は推力（N）、$\eta_F$ は摩擦等を一括して近似した無次元係数である。$1\ \mathrm{MPa}=10^6\ \mathrm{Pa}$、$1\ \mathrm{mm}=10^{-3}\ \mathrm{m}$ とする。

内径63 mmなら、

$$ A = \frac{\pi(0.063)^2}{4} = 0.003117\ \mathrm{m^2} $$

$$ F = 10.0\times10^6\times0.003117\times0.85 \approx 26,500\ \mathrm{N} $$

概算推力は約26.5 kNで、仮の20 kN要求を上回る。 推力余裕率を、要求推力に対する超過割合として定義すると、

$$ M_F = \frac{F-F_{\mathrm{req}}}{F_{\mathrm{req}}}\times100 \approx 32.5\ % $$

となる。ただしこの32.5%を安全率と呼んではならない。安全率には材料強度、荷重ケース、座屈、取付部などの別途評価が必要である。圧力損失や背圧、負荷による変動があれば計算値も変わる。

時間要求を満たせるか

漏れや圧縮性を無視した定常近似では、速度 $v$ と流量 $Q$ は次式で結ばれる。

$$ v = \frac{Q}{A}, \qquad t = \frac{L}{v} $$

$Q$ は体積流量（m³/s）、$v$ は速度（m/s）、$L$ は移動距離（m）、$t$ は移動時間（s）である。8.0 L/minをSI単位に直すと、

$$ Q = \frac{8.0\times10^{-3}}{60} = 1.333\times10^{-4}\ \mathrm{m^3/s} $$

$$ v = \frac{1.333\times10^{-4}}{0.003117} \approx 0.0428\ \mathrm{m/s} $$

$$ t = \frac{0.500}{0.0428} \approx 11.7\ \mathrm{s} $$

理想化した定常移動時間は約11.7秒で、15秒以内という仮要求に対して約3.3秒の余裕がある。 ただし起動・停止時の加減速、制御遅れ、実供給流量の低下、油温変化は未反映である。したがって、この段階での判定は「概算成立、実機合格は未判定」とする。

次元は、$pA$ が Pa×m² = N、$Q/A$ が (m³/s)/m² = m/s、$L/v$ が m/(m/s) = s で整合する。

要求を試験へつなぐトレーサビリティ

IDを付け、要求・設計・証拠を接続する

要求ごとに一意のIDを与え、出典、設計根拠、図面・部品、検証方法、証拠を紐付ける。次表は設計開始時点の検証計画であり、試験済みの実績ではない。

REQ-S01は意図を表す上位要求にとどまる。リスクアセスメント後に、危険源、想定故障、許容される動き、検出・停止の条件、検証方法へ分解する必要がある。安全機能の成立を、推力や速度の概算だけで判断してはならない。

変更の影響を双方向に追えるか

例えば上昇時間を15秒から10秒に短縮すると、必要流量、ポンプ・モータ、配管圧損、発熱、騒音、制御弁、試験条件に影響する。変更要求に対して「影響する図面と計算書」「再試験すべき要求」「承認者」が検索できる状態が望ましい。

要求ID→設計変数→計算書→図面/BOM→試験記録という順方向だけでなく、図面変更→影響する要求IDという逆方向も確保する。トレーサビリティは単なる番号付けではなく、変更漏れを減らす仕組みである。

設計仕様を確定するための実務手順

要求ヒアリングから設計開始判定まで

1. 使用場面を記述する：誰が、何を、どの頻度・環境で、通常時と異常時に操作するか。
2. 要求を原文のまま収集する：顧客の言葉を保存し、設計者の解釈と分ける。
3. 要求を分解する：「速く、安全に、静かに」は別々の検証可能な要求へ分ける。
4. 定量基準を付ける：数値、単位、許容差、試験条件、測定位置を決める。
5. 制約と設計解を分離する：既設設備など変更困難な条件と、代替可能な方式を区別する。
6. 矛盾と欠落をレビューする：高速化と発熱、低価格と高精度などの競合を明示する。
7. 要求ごとに検証方法を先に決める：試験できない要求は表現か測定方法を見直す。
8. ベースラインを承認する：版、日付、責任者、未決事項、変更手続きを記録する。

初期段階で全てを確定できない場合は、未決項目を「TBD（要決定）」として残す。ただし安全に関わる条件や構想選定を左右する前提を、根拠なく確定済み扱いにしない。TBDには担当者・期限・決定前に着手してよい範囲を付ける。

設計開始ゲートの判定例

仮に要求10件のうち、受入基準・検証方法が確定したものが8件、未決が2件だったとする。単純な定義率は、

$$ C = \frac{N_{\mathrm{defined}}}{N_{\mathrm{total}}}\times100 = \frac{8}{10}\times100 = 80\ % $$

となる。$N_{\mathrm{defined}}$ と $N_{\mathrm{total}}$ は件数（無次元）である。80%という数値だけで設計開始可とは判定できない。 残り2件が安全機能や最大荷重なら開始不可とするなど、重要度を加味したゲートが必要である。この80%は進捗指標であり、規格が定める合格閾値ではない。

実務で起きやすい失敗と故障モード

特に油圧装置では、圧力保持と荷重保持を同義とみなさないこと。内部漏れ、配管破損、弁の故障、外力などの故障シナリオに対し、安全要求を別途設計・検証する必要がある。

一次資料と規格の位置付け

• ISO/IEC/IEEE 29148:2018（第2版）：要求エンジニアリングのプロセス・情報項目を扱う。ISO公開情報では2024年確認済みで、2026年10月時点では現行版。次版はDIS段階。規格本文の詳細条文は本記事で転載していない。
• ISO 9001:2026（第6版）：品質マネジメントシステム要求事項。ISO公式情報では2026年9月発行。旧2015年版は廃止扱い。組織での適用・認証移行は別途確認が必要。
• ISO 12100:2010（第1版）：機械のリスクアセスメントとリスク低減の一般原則。次版は策定中。
• ISO 4413:2010（第3版）：油圧システムと構成要素の一般規則・安全要求。実際の適用には対象機械の関連規格・法令の調査も必要。
• NASA Systems Engineering Handbook, NASA/SP-2016-6105 Rev 2：要求の記述、要求検証マトリクス、検証と妥当性確認の区別に関する公開実務資料。NASA向け手法を一般機械へ応用する場合は、組織規模とリスクに応じて簡素化する。

参考一次資料（2026年10月20日確認）：

• ISO/IEC/IEEE 29148:2018（ISO）
• ISO 9001:2026（ISO）
• ISO 12100:2010（ISO）
• ISO 4413:2010（ISO）
• NASA Systems Engineering Handbook（NASA）
• NASA：要求記述・検証マトリクス（付録）

設計チェックリスト

• [ ] 利用目的、運転シナリオ、作業者、設置環境を記述した。
• [ ] 要求と制約、設計解を別々に管理した。
• [ ] すべての要求に一意のID、出典、責任者を付けた。
• [ ] 性能要求に数値、単位、上下限、公差、測定位置を付けた。
• [ ] 最大・通常・異常時の荷重条件を区別した。
• [ ] 安全要求をリスクアセスメントへ接続した。
• [ ] 主要な要求に計算・試験・検査等の検証方法を設定した。
• [ ] 仮定、TBD、未検証事項を明示した。
• [ ] 要求変更時に図面・BOM・試験へ影響を追える。
• [ ] 承認版と未決事項を管理し、設計開始ゲートを判定した。

知識資産化できる項目

要求を文章だけで保存せず、データとして扱えば、単位検証、未定義項目の検出、計算書との紐付け、試験記録の自動集計へ展開できる。

最小のJSONレコード例を示す。これは独自のデータ設計例であり、特定規格が定める必須スキーマではない。

{
  "requirement_id": "REQ-F01",
  "description": "指定条件で上昇推力20 kN以上",
  "parameter": "lifting_force",
  "comparator": ">=",
  "threshold": 20000,
  "unit": "N",
  "operating_conditions": {
    "load_case": "maximum_defined_load",
    "temperature_range": "TBD"
  },
  "verification_method": "test",
  "evidence_id": null,
  "status": "unverified",
  "revision": "A"
}

このレコードに試験値と測定条件を追加すれば、合否判定のコード化ができる。ただし「測定条件がTBDなら自動合格にしない」という制約を必ず設ける。要求管理の自動化は、設計判断そのものを省略するためではなく、判断根拠と未確認事項を見失わないために使う。