PCBデータ形式：Gerber・ODB++・IPC-2581

プリント基板（PCB）実装の製造データ形式は、ファイル拡張子だけでなく、実装委託先が検証できる情報に基づいて選びます。受領側のワークフローで、基板データ、承認済みの部品表（BOM）、部品配置ファイル、実装指示書を確実に組み合わせられる場合は、Gerberを中心としたパッケージを使用します。エクスポート側と受領側が必要な製造情報を保持できる場合は、ODB++またはIPC-2581を選択します。いずれの場合も、正式な基準となるパッケージを1つだけリリースし、データ区分ごとに基準情報源を明示したうえで、製造上重要な不一致を解決するまで生産準備を進めないことを求めます。

必要な製造情報を軸にデータの引き渡しを設計する

製造データの引き渡しでは、どの基板を製造し、どの部品をどこに実装し、どのリリース済み構成を作業の基準とするかを受領側に伝える必要があります。これらの要件に照らして、完全なパッケージ同士を比較します。Gerberの描画データだけを、情報がすべて格納されたインテリジェントな製品モデルと比較すると、誤解を招く結果になります。

まず、未実装のプリント基板の製造に必要な情報と、実装、調達、試験準備に必要な情報を分けます。そのうえで、各区分のデータを受け取るアプリケーションと担当チームを特定します。供給元が銅箔層を表示できるからといって、調達用BOMを抽出できることや、部品属性を保持できることまでは証明されません。

この区別は実務に関わります。参照先のサプライヤーは、PCB製造データ、BOMデータ、部品配置データを、それぞれ独立した実装用入力データとして説明しています。これはあるメーカーが文書化したワークフローであり、すべてのメーカーに同じファイルの使用を求める要件ではありません。

同じ基準で情報の収録範囲を比較する

この比較表は収録可能な情報を示すものであり、特定のエクスポートデータにそれらが含まれている証拠ではありません。各形式の節では根拠となる仕様を説明し、受領側の確認事項は推奨する受入確認の作業として示しています。

不適切な選択によるコストを理解する

不適切な引き渡しは、システム間の受け渡し部分で作業を増やします。設計部門がデータに組み込まれていると思っていた部品リストを、調達部門が作り直さなければならない場合があります。基板形状しか受け取れなかったために、生産技術部門が部品配置を再構築することもあります。古いバックアップが、誤って新しい製造の情報源になる可能性もあります。

インテリジェントファイルは正しくインポートできたものの、メーカー部品番号の列が空になっている架空のリリース例を考えてみます。基板の画像が正しくても、どの認定済み部品を調達するべきかは判断できません。このプロジェクトに必要なのは、フィールドの対応付けの修正、または基準として明示された調達用BOMであり、基板のスクリーンショットを追加することではありません。

提案する引き渡し方法を、回避できる照会、再構築、再承認の工数という観点で評価します。受領側が何を直接利用し、何を手作業で作成するのかを確認します。一律の追加コストを作り上げたり、ある形式なら必ず納期が短縮すると約束したりする必要はありません。

Gerberで補助BOMと部品配置ファイルが必要になる範囲

Gerberを中心とした実装用パッケージには、通常、基板製造データに加えて、承認済みBOMと部品配置情報が必要です。提供したGerber部品層から得られる同等の情報を受領側が明示的に受け入れ、その完全性を検証しない限り、これらの補助ファイルを残します。

Extended Gerber（RS-274X）、Gerber X2、Gerber X3を区別してください。X2はレイヤーや形状の意味を示す属性を、X3は部品情報を追加します。受け取り側がX2属性を無視しても画像が正しく見える場合があり、表示互換性だけでは情報の受け渡しを証明できません。

Gerber X3は実装関連の部品情報を含みます。適格性を確認したX3工程では、一部の配置・部品記録を別途重複作成せずに利用できます。ただし銅箔、マスク、文字のファイルは、Gerber拡張子があるだけで承認済み購買BOMにはなりません。

従来型のパッケージでは、調達に対するBOMの役割と、部品配置に対するCPLの役割を分けて定義します。調達情報には、リファレンス番号、数量、承認済みの部品識別情報を含めます。部品配置については、X/Yの単位、原点、面、向きの規則を定義します。基板形状と基板製造文書は、受領側が受け入れる構成で提供します。

Gerber Jobファイルは材料、表面仕上げ、厚さなどの製造特性を伝えられますが、完全な実装指示一式ではありません。実装によって対応欄が限られる場合があるため、受け取り側が実際に処理する欄を確認してください。

ここではGerber Layer Format Specification Revision 2026.05を対象とします。「Gerber」を選ぶだけで同改訂の全機能に対応するとは限らないため、エクスポーターと有効機能を記録してください。既存工程では、直ちに形式を移行するより属性とリリース管理の改善が有効な場合があります。

ODB++に格納できる情報と検証すべき内容

ODB++には統合された製造モデルを格納できますが、受領側はモデルの実際の内容を検証する必要があります。設計から製造への今回の引き渡しでは、ODB++Designを指定します。ODB++Designの公式サイトが説明するように、ODB++ファミリーには、役割の異なるProcessおよびManufacturing形式も含まれます。

2024年8月のODB++Design Release 8.1 Update 4は、レイヤー、基板外形、部品配置、EDA接続情報、BOM記録を含む構造化製品モデルを定義します。圧縮納品はその構造を収める容器であり、必要な記録がすべて存在する証拠ではありません。

対象の基板ステップ、実装対象部品、部品番号間の関係を受領側に確認してもらいます。実装情報が除外されていれば、基板製造業者には十分なパッケージでも、実装業者には不十分なことがあります。ODB++Designのデータシートは、部品レベルの情報の除外やネット名の変更など、収録する内容を送信側が制御できることを明示しています。

設計モデルと調達の境界を確認します。CADの部品識別子が、そのまま承認済みのメーカー部品番号になるわけではありません。調達で使用するのが埋め込みBOMなのか、別途管理されたBOMなのかを定め、重複して存在する識別情報の照合を求めます。

エクスポートツールとインポートツールを新たに組み合わせる場合は、解釈上の問題が現れやすい例を含めます。設計に存在する場合には、非対称のコネクタ、有極性部品、下面の部品配置を確認対象とします。圧縮ファイルが開いたという確認だけでなく、リリース済みの設計意図に照らした確認を求めます。

受領側のワークフローで抽出されない情報については、実装指示書を残します。ODB++を選んだからといって、実装委託先が形状だけから取り付け上の制限、試験要件、構成の決定事項を推測してよいことにはなりません。

IPC-2581に格納できる情報と検証すべき内容

IPC-2581には、基板製造と実装に関する構造化情報をXMLで格納できます。ただし、リビジョン、エクスポートされた内容、受領側のワークフローについて対応を確認する必要があります。IPC-2581 Consortiumは、この規格をIPC-DPMX（Digital Product Model Exchange）としています。

引き渡しに関する合意では、リビジョンを具体的に指定します。IPCによるRevision Cのリリース発表では、リジッドフレックス情報、内蔵部品、製造容易性を考慮した設計への双方向フィードバックなどの追加機能を説明しています。こうした機能があることは、個々のエクスポートツールがその情報を出力することや、実装業者が利用することの証明にはなりません。従来のデータ受け渡しではRevision AやRevision Bを使用している場合がありますが、合意済みの製造要件を保持できる場合に限って継続します。

バージョン9.0の出力例ではIPC-2581BとIPC-2581Cを選択でき、BOM欄の対応を設定できます。メーカーとメーカー部品番号を省略できるため、一見有効な出力でも発注に必要な購買品識別情報が欠ける場合があります。

エクスポート前に、収録すべき内容を確認します。対象は、製造形状、製造対象に関係する層構成情報、部品、部品配置、接続情報、必要な部品識別情報です。インポート後には、どの情報が受領側の作業用データベースで利用可能なレコードになったかを示してもらいます。

3種類の承認を区別します。XML／スキーマ検証は構造上の適合性を確認するものです。インポートレビューは、受領側アプリケーションがデータをどのように解釈したかを確認します。製造受入確認では、得られた情報がその案件に十分で、正しいかを判断します。最初の検証に合格しても、残りの2つを満たしたことにはなりません。

必要なリビジョンと内容について、双方がその受け渡し方法の有効性を実証できる場合にIPC-2581を選びます。受入可能なリビジョンでは必要な要素を表現または伝達できない場合、別の検証済みの方法を選ぶか、承認済みの補助指示を文書化します。黙ってエクスポートのリビジョンを下げ、欠けた情報を重要ではないと考えてはいけません。

インポート対応、バージョン互換性、データ欠落を確認する

インポートへの対応は、具体的なアプリケーション、バージョン、有効なモジュール、想定する処理について確認する必要があります。「IPC-2581を受け入れています」「当社のビューアーでODB++を開けます」という回答は出発点であって、完全な受入記録ではありません。

以下の例では、ソフトウェアの公開文書と、案件ごとの適格性確認を区別しています。JASPERやその他の実装業者がどのアプリケーションを使用しているかを示すものではありません。

取込プラグインの説明とコンソーシアム対応表は異なるレベルの能力を示します。製品掲載や過去版の記載は実受入工程での試験取込の代用にはなりません。

見た目と意味の両方を確認します。層の役割、基板寸法、穴あけ情報、部品識別情報、部品配置、接続情報、実装対象部品の意図を比較します。その後、警告、未対応属性、変換中に行った手動編集を確認します。

回転値には特に注意が必要です。Gerber Layer Format Specificationでは、上から下を見たときの部品の正回転を反時計回りと定義しています。一方、ODB++仕様ではCMPの回転フィールドを時計回りと定義しています。生の角度値ではなく、共通の座標系で物理的な向きを比較します。2つの部品配置が食い違うかを判断する前に、下面の座標変換とフットプリントのゼロ角度の向きを考慮します。

エクスポート設定、受領側アプリケーション、変換プラグインが変わった場合は、影響する適格性確認を繰り返します。以前に承認されたパッケージとそのインポート証拠を保存します。別のソフトウェアビルドで成功した結果は、新しい受け渡し方法の有効性を証明しません。

形式を承認する前に10の評価基準を適用する

製造データの各受け渡し方法を、確認可能な証拠に基づいて評価します。以下の基準はOEMのレビュー枠組みとして使うものであり、供給元のランキングや規格で義務付けられた採点制度ではありません。確かな回答は、情報源、受領側のレコード、責任者を特定します。根拠の弱い回答は、形式名だけに頼ります。

提案する取引にこれらの基準を適用します。検証済みのGerberパッケージを使うリピート注文で、新しさだけを理由に形式を移行する必要はありません。別の実装委託先への移管では形式変更が妥当な場合もありますが、受領側の工程で同等の製造上の意味を保持できると示された後に限ります。

証拠が不足していることを、供給元の自動的な不採用につなげてはいけません。まず、未対応の受け渡し方法なのか、修正可能なエクスポート設定なのか、管理対象の補助文書が不足しているのかを区別します。実務上の判断点は、リリース前にパッケージを曖昧さのない状態にできるかどうかです。

製造データの引き渡しを6段階でレビューする

製造データのレビューでは、ファイルが生産用入力になる前に、受け渡し方法の適格性を確認します。調達部門の受領確認を技術承認と取り違えないよう、責任を明確に割り当てます。

1. 必要な情報を定義する

OEMの技術責任者が、基板リビジョン、実装リビジョン、構成、引き渡しの対象となる製造作業を特定します。どのデータ区分をデジタルに伝達する必要があり、どの区分を管理文書として提供してよいかを記録します。要件は実際の製造対象に結び付けます。

2. 受領側の受け渡し方法に合意する

実装委託先の生産技術担当者が、受領ソフトウェア、対応リビジョン、必要なモジュール、後工程向けの出力を特定します。主形式、補助ファイル、試験インポートの証拠について合意します。基板製造業者や試験技術部門の受領担当者の独自のワークフローが判断に影響する場合は、それらの関係者も参加させます。

3. 元データを凍結してエクスポートする

承認済みの設計状態と選択した実装構成から、提案するパッケージを生成します。エクスポート設定、データが設定されたBOMフィールドの対応付け、座標に関する前提を記録します。2つ目の形式を生成する場合も、後の作業コピーではなく、同じリリース済み元データを使用します。

4. 受領側で試験インポートを行う

受領側が対象のワークフローにパッケージをインポートし、認識された層、部品のリファレンス番号、必要なフィールド、警告を返します。必要なオブジェクトの集合全体を照合します。部品数が同じでも、欠落したリファレンス番号の代わりに意図しない重複が入り込んでいることがあります。非対称部品や下面の選択したビューは座標変換の確認に使い、この照合の代わりにはしません。比較の精度は物理的な部品配置公差とは別に定義します。エクスポートされた小数桁の精度は、実装機の能力を表すものではありません。

5. 例外を解決し、情報の意味を承認する

OEMと受領側が、欠落したフィールド、説明できないオブジェクト差分、指示の矛盾を照合して解決します。各問題に対し、修正したエクスポート、検証済みの代替形式、承認済みの補助指示のどれが必要かを記録します。修正前のインポート報告を承認するのではなく、修正後に影響するデータを再確認します。

6. パッケージをリリースし、受領確認を得る

OEMが最終マニフェストと管理対象ファイルをリリースします。受領側はリリース識別情報、基準情報源、例外の処置を確認します。この証拠を注文とともに保存します。後の変更が承認済みの受け渡し方法や製造上の意味に影響する場合は、レビューを再開します。

読みやすいバックアップを添えて、唯一の正式パッケージをリリースする

正式な基準となるリリースパッケージに複数のファイル形式が含まれていても、競合する複数のマスターを作る必要はありません。情報区分ごとに基準を定義します。形状、調達、部品配置、実装指示を、すべて同じ物理ファイルで管理する必要はありません。

読みやすい上面・下面の実装図、リリース済み部品リスト、レビューに必要な指示を含めます。各文書が要件の基準となるのか、それとも他の情報源を基準とするデータを可視化しただけなのかを明示します。図面が取り付け指示の基準となる一方で、その部品ビューは参考情報にとどまる場合もあります。基準としての効力は要件ごとに割り当てます。「PDFを優先する」という一律のルールでモデルとの矛盾を回避してはいけません。

以下の例は、従来型のGerberリリース1件の中で、情報源ごとに異なる基準範囲を割り当てています。基板リビジョンと実装リビジョンは異なる管理対象を識別し、リリース識別情報がそれらを1つの承認済み製造構成に結び付けます。

ODB++またはIPC-2581では、マニフェストで形状と部品配置の基準をインテリジェントモデルに割り当てながら、調達用BOMや指示書を別途管理することもできます。この分担を明示し、リリース前に重複データを照合します。

ファイル名、リビジョン、チェックサムを含むマニフェストを使い、誤った差し替えや破損を検出します。チェックサムが示すのはファイルの同一性であり、技術的な正しさや承認ではありません。エクスポート設定と受入記録をアーカイブとともに保存します。

Gerber、ODB++、IPC-2581を、同じ効力を持つ3つの代替情報源として送ってはいけません。別の表現形式がレビューや復旧に役立つ場合はありますが、その位置付けを明示し、受入済みの生産用情報源を置き換える前に、管理された判断を求めます。

引き渡し時の8つの警戒兆候を責任者に上げる

必要な製造上の意味が欠落している、曖昧である、または未検証の変換に依存している場合は、引き渡しの問題を責任者に上げます。担当責任者が解決するまで影響する準備を保留し、根本原因の解決につながる場合に限って形式を変更します。

1. アーカイブは開くものの、必要な部品、部品配置、調達用部品識別情報が存在しない。内容の修正、または合意済みの補助情報源を求めます。
2. 選択したリビジョンに受領側アプリケーションが対応していない。互換性のあるエクスポートに合意し、表現が変わった部分を再確認します。
3. 変換時に必要な属性が消失する。失われた意味を特定し、作業を進める前に代替手段の適格性を確認します。
4. 下面の部品や非対称部品が、説明できない向きの変化を伴ってインポートされる。設計意図に照らして座標変換を解決します。
5. 基板ステップやパネルの解釈が不確かである。想定する製造単位と座標系を確定します。
6. モデルと基準となる実装文書が異なる製造構成を示している。現場でどちらかを選ばず、矛盾をOEMの技術部門に戻します。
7. 受領側が、後工程で必要な情報についてオブジェクト単位の証拠を提示できない。別のツール、または対応済みのデータ受け渡し方法を検証します。
8. リリースマニフェストがないまま、複数のパッケージが生産上の基準を主張している。曖昧さを解消し、整合した1つのリリースとして再発行します。

よくある質問

以下の回答は、形式を選ぶ際の判断を対象としています。プロジェクトに必要な具体的なファイルは、合意済みのリリース方法と受領側のインポート証拠に基づいて決定します。

次のデータ引き渡しをJASPERと準備する

基板と実装のリビジョン識別子、意図する製造構成、提案する製造データ形式、承認済みの調達情報、読みやすい実装指示書を用意します。エクスポートに使用したアプリケーションとバージョンを記載し、パッケージを確定する前に、受領側の受け渡し方法と必要な補助ファイルの確認を求めます。

JASPERのプリント基板実装サービスを利用するプロジェクトでは、受入確認の問いを具体的にします。このパッケージは今回の製造に必要な情報を保持できるか、各要件の基準となる情報源はどれか、という問いです。その証拠に基づいてGerber、ODB++、IPC-2581を選び、合意した作業に向けて整合した1つのパッケージをリリースします。