なぜZunaviはオンプレ第一なのか：半導体の図面は社外に出ない

多くの図面管理ツールに埋め込まれた前提

技術文書管理向けの現代的なSaaS製品のほとんどは、クラウドファーストで作られています。サインアップすればファイルは提供元のインフラに置かれ、「オンプレ」が存在するとしても、たいていは後付けのエンタープライズオプションであり、多くの場合高額で、二級市民的な体験になりがちです。多くのソフトウェアカテゴリでは、これは十分に合理的な既定値です。

しかしZunaviが想定する顧客層にとっては、これは間違った既定値です。半導体・精密製造業が扱う図面は、その定義からして機密情報です。「半導体は機密」というのは、この業界にとってコンプライアンスのチェック項目ではなく、出発点となる前提そのものです。エンジニアが図面を閲覧する前に、静かに第三者のサーバーを経由することを暗黙に要求するツールは、機能セットがどれだけ優れていても、この市場のかなりの部分にとって選択肢から外れます。

オンプレをフォールバックではなく第一級のデプロイ形態にする

これがZunaviのアーキテクチャにどう現れているかというと、テナントレコード自体のフィールドとしてです。Tenant.deploymentはONPREMかCLOUDのいずれかを取ります。これはサポート対応で個別に発生する例外パスではなく、システムの残り全体がそれを前提に設計される第一級の値です。オンプレのテナントはクラウド依存の機能が既定でOFFになりますが、それは制限されているからではなく、本質的に機密性の高いワークロードの既定姿勢は、誰かが明示的に別の指示をしない限り「データは社外に出ない」であるべきだからです。

この「明示的に別の指示をする」という部分が重要です。図面データを外部サービスに送信することになる機能は、別の記事で紹介した一般的なフィーチャーフラグの仕組みとは別に、独自の同意フラグの裏側に置かれます。クラウド依存機能を有効化することは、テナント管理者が意図的に下す判断であり、他の理由で何かの機能が有効化された結果として暗黙に発生することはありません。

ストレージ：既定はローカルファイルシステム、求めればS3互換も選べる

ファイルストレージも同じ論理に従います。Zunaviのストレージ層はSTORAGE_DRIVERという設定によって駆動され、既定はローカルファイルシステム、S3互換のオブジェクトストレージは明示的なオプションとして選べます。オンプレ導入では、図面、DXF/DWG/STEPファイル、生成されたサムネイルは、製造業者が既に管理しているインフラ上に置かれます。自分たちが選んでもいないリージョンのバケットも、既定でベンダーリスク評価に加わる第三者ストレージプロバイダもありません。クラウドオブジェクトストレージは、それを望むチーム — より軽量なセットアップ、デモ環境、サーバーインフラを管理する余力のない小規模な町工場など — のために用意されていますが、それはオプトインであり、アーキテクチャの既定の前提ではありません。

この業界にとって「機密」は曖昧な形容詞ではない

「半導体は機密」というのは、アーキテクチャ上の選択を正当化するために借りてきたマーケティング用語ではなく、半導体エンジニアが実際に置かれている規制上の現実を表しています。米国の輸出管理規則の下では、半導体の設計情報や製造ノウハウを明示的に含む管理対象技術データが外国籍の人物と共有された場合 — たとえそれが輸出元企業自身の建物の中であっても — それは「みなし輸出（deemed export）」とみなされ、管理対象品を海外へ物理的に出荷するのと同様に扱われます。企業はそれに応じたアクセス制御とスクリーニング手続きを実施することが求められます（Kharon、AIと半導体輸出管理コンプライアンスについて）。立法者の中には、輸出管理対象のチップ設計へのリモートクラウドアクセス自体を制限しようとする提案を出し、クラウド経由の伝送そのものを規制の対象点として扱おうとする動きさえあります（Kharon）。規制業界向けのクラウドPDM評価用セキュリティチェックリストは、購入者に対して監査ログ、権限設定、外部共有の挙動を確認すること、そして何より、ベンダーが既定で保護している範囲と顧客自身が設定しなければならない範囲を明確にすることを求めています（CAD Rooms、クラウドPDMセキュリティレビューチェックリスト）。この背景を踏まえると、「既定はクラウド、頼めばオンプレも用意します」という姿勢は単なるUXの好みのミスマッチではありません。それは、最もミスを許容できない顧客にこそコンプライアンスの負担を押し付けるアーキテクチャなのです。

ジョブキューでさえこの制約を尊重している

これは見落とされがちですが、「オンプレ第一」がどれだけ本気で扱われているかを最もよく物語る細部です。Zunaviのバックグラウンドジョブ処理 — OCR抽出、サムネイル生成、CADファイル変換、類似検索用の埋め込み計算 — は、既定でPostgreSQLベースのキューを使い、FOR UPDATE SKIP LOCKEDにより安全な並行ジョブ取得を実現します。最初からRedisを必須とすることはありません。より高負荷な状況で稼働するチーム向けにRedisをオプションとして用意していますが、最小構成のオンプレ導入において、それは必須の依存関係ではありません。

これは些細な実装の詳細に聞こえるかもしれませんが、「自社のサーバーにZunaviを導入する」ことが実際に何を要求するかを大きく左右します。必須の追加サービスが1つ増えるたびに、オンプレ顧客のIT部門はそれを調達し、パッチを当て、セキュリティレビューに対して正当化しなければなりません。中核的なワークフローを動かすのにPostgreSQL以外何も必要としない図面管理プラットフォームは、あらゆる新規サービスを詰問すべき対象として扱うセキュリティ姿勢を持つ製造業者にとって、根本的に「イエス」と言いやすいものになります。

なぜクラウドファーストのSaaSはここで構造的にミスマッチなのか

これはクラウドファーストのアーキテクチャ全般への批判ではありません。多くのソフトウェアにとってそれは正しい判断であり、Zunaviもそれを望むチーム向けにCLOUDデプロイを実在するサポート対象モードとして提供しています。ミスマッチはもっと具体的です。「あなたのファイルは私たちのサーバー上にある」ことを固定された前提とし、オンプレをエンタープライズ向けの後付けティアとして扱うツールは、半導体・精密製造業界のかなりの部分が既定にできないデプロイモデルに最適化してしまっています。オンプレを（格下げされたパスや特別なSKUとしてではなく）既定のデプロイ形態として構築するということは、アーキテクチャが最初からそれをきちんとサポートしなければならないということです。互換性のための応急処置ではないローカルストレージ、マネージドRedisインスタンスがワンクリックで手に入る前提を置かないジョブキュー、そして便利さではなく同意の裏に置かれるクラウド機能——これらすべてが必要です。

既存のPDMベンダーがこの問題にどう向き合っているか

この分断に気づいているのは私たちだけではありません。Autodesk自身の製品ラインナップがそれをよく表しています。Vaultは「データレジデンシー要件、エアギャップ環境、IT統制上の理由でオンプレ導入にコミットするチーム」向けのオンプレ製品として存続する一方、Autodeskの新しいクラウドPLM製品であるFusion Manageにはオンプレ版が一切存在しません（DemystifyingPLM、Autodeskのクラウドファーストへの転換について、KETIV、Vaultのデプロイオプションについて）。これは業界全体のパターンの縮図です。オンプレ対応は古く、開発があまり活発でない製品ラインに残り続け、新規投資はクラウド専用ツールへ向かう — 最新のツールとデータレジデンシーの両方を必要とする半導体製造業者が、まさに落ち込んでしまうギャップです。このギャップは、日本市場に関しては、一般的なデジタル化の物語が示唆する以上に重要な意味を持ちます。経済産業省による2025年版中小企業白書によれば、中小製造業の64.8%がデジタル成熟度の最も低い2段階にとどまっており、最も進んだ段階に達しているのはわずか3.2%です。また別の業界解説は、あらゆる案件で図面や仕様が異なる多品種少量生産の現場こそ、まさにこのハードルが高くなり、デジタル化の取り組みが停滞しがちな場所だと指摘しています（経済産業省、2025年版中小企業白書、The Worldfolio、日本の製造業中小企業向け図面中心DXについて）。この市場を狙うプラットフォームがクラウド移行を前提条件として求めてしまうと、本来1つで済むはずの困難な課題 — デジタル化とクラウド移行 — を同時に2つ課すことになります。本来の目的は、まさにその1つ目のハードルだけを、単独で乗り越えやすくすることのはずです。

生成AIツールが見落としがちな日本市場特有の詳細

このユーザー層に対して、欧米発の汎用エンジニアリングツールが抱えがちな、もう1つの静かな市場適合上の問題があります。エンコーディングとローカライズです。日本の製造現場に存在する図面データの多くは — 旧来のCADエクスポート、古いDXFファイル、表題欄のテキスト — UTF-8ではなくShift-JISでエンコードされていることが多く、UTF-8を前提としたビューアはそのテキストを文字化けさせるか、そもそも描画を拒否します。Zunaviが採用するCADビューアは、Shift-JISデコードとIPAexGothicフォントレンダリングを組み込んだ、日本語対応にフォークされたビューアをベースにしているため、日本語の表題欄や注記を含む図面も文字化けせず正しく表示されます。些細に聞こえるかもしれませんが、これがまさに「ある町工場が20年間作り続けてきた図面に対してツールが実際に機能するかどうか」を分ける理由になります。

現在の状況

Zunaviは現在も活発に開発中であり、これはプラットフォームが今どこかで稼働しているという主張ではありません。実際には稼働しておらず、リリース時期も明言していません。今の時点で具体的にお伝えできるのは、アーキテクチャがコミットしている方向性です。オンプレをエンタープライズ向けの後付けとしてではなく既定のデプロイ姿勢とすること — それがまさに重要な意味を持つ業界のために。

---

関連記事：「確実 vs オプション」というZunaviのフィーチャーフラグの考え方、なぜ図面台帳をゼロから作り直しているのか、そしてZunaviの紹介記事。機密性の高いエンジニアリングデータのオンプレ導入という要件に取り組んでいる方は、ぜひ情報交換させてください。[email protected]