Viewer開発で失敗しないための判断基準｜APSを使うべきケースとは
キャパ編集部1. はじめに
Viewer開発は、CADやBIMデータをブラウザ上で共有・可視化できる有効な手段ですが、「目的や判断基準が曖昧なまま着手する」ことで失敗するケースが多く見られます。
Viewer開発で失敗しやすい企業の共通点
- 利用業務が決まっていない
- 対象データが決まっていない
- カスタマイズ範囲が決まっていない
整理されていない状態では、開発コストや運用負荷だけが増え、結果として使われないシステムになりやすくなります。
本記事では、「Viewerを自作すべきか」「APS（Autodesk Platform Services）を使うべきか」「既存ツールで十分か」を判断するための具体的な基準を整理し、プロジェクト規模や要件に応じた最適な選択肢を解説します。
2. Viewer開発とは何か
Viewer開発とは、DWGやIFCなどのCAD/BIMデータを、ブラウザで閲覧・操作できる形式に変換し、Web上で利用できるようにする仕組みを作ることです。単に3Dモデルを表示するだけでなく、計測、断面表示、属性確認、関係者間での共有までを含めて設計する必要があります。
特に実務では、元の設計データをそのまま表示できるとは限らないため、変換処理と表示処理を分けて考えることが重要です。ここで使われる代表的な選択肢の一つがAPSで、Viewer SDKによる表示機能と、Model Derivativeによるデータ変換機能を組み合わせることで、DWGやIFCなど複数フォーマットに対応しやすくなります。
つまりViewer開発の本質は、単なる画面づくりではなく、「どのデータを、どの形式に変換し、誰にどう見せるか」を設計することにあります。
3. Viewer開発の全体像
Viewer開発は、表示（フロントエンド）とデータ処理（バックエンド）を分離した構造で設計するのが基本です。
一般的な処理の流れは以下の通りです。
Viewer開発の基本フロー
- CAD/BIMデータ（DWG・IFCなど）をアップロードする
- サーバー側で変換処理（例：Model Derivative）を実行する
- 変換済みデータをブラウザに配信する
- Viewer（WebGL）で表示・操作する
このように、「変換してから表示する」前提で設計することが重要です。
特にDWGやIFCはそのままブラウザ表示できないため、変換処理をどう実装するかが開発難易度を大きく左右します。APSを利用する場合、この変換処理やフォーマット対応をAPIで吸収できるため、自作と比較して開発負荷を大幅に抑えることが可能です。
この構造を理解しておくことで、「どこを自作し、どこを外部サービスに任せるべきか」という判断がしやすくなります。
3.1. Viewerの基本構造
Viewerの基本構造は、大きく分けてフロントエンドとバックエンドで構成されます。フロントエンドは主にWebブラウザで動作する部分で、ユーザーが3Dモデルを閲覧・操作するインターフェースを担います。この部分ではWebGLを利用し、ブラウザ上でリアルタイムに3Dデータを表示します。
バックエンドでは、APSなどのAPIを活用し、Model Derivativeによるファイル変換や認証処理を管理します。DWGやIFCなどのさまざまな形式のデータを一度サーバー側で変換し、それをブラウザのViewer SDKで表示できる形に整えるイメージです。ここでセキュリティや権限管理を適切に行うことが、機密保持や不正利用の防止において重要になります。
一方、サーバー構成については、AWSやAzureと連携しながらクラウド上にデータを保存する方法が一般的です。大規模建設プロジェクトでは、複数拠点のメンバーが同時にアクセスするケースも多く、スケーラビリティの確保が求められます。そのため、クラウド環境の活用が現実的な選択肢となります。
こうしたフロントとバックの両面を意識した設計が不十分だと、「表示はできるが操作が遅い」「アクセス集中で動作が不安定になる」といったトラブルにつながる可能性があります。
3.2. 必要な技術要素とプロセス
まず、プロジェクトの初期段階でViewer開発の判断基準を設定することが重要です。現場で必要とされる機能の優先度を整理し、それに基づいて開発方針を決めます。次に、想定するインフラ構成や使用技術（WebGLライブラリやAPSのViewer SDKなど）を選定し、具体的な要件定義を行います。
この要件定義が曖昧だと、開発途中で「別の3Dフォーマットにも対応したい」「計測や断面機能を追加したい」といった要望が後から出てきて、開発期間やコストが膨らみやすくなります。そのため、CAD/BIMデータのどの部分をどの程度活用するかを、初期段階で明確にすることが重要です。
技術面では、Model Derivativeによる変換設定やViewer SDKのAPIの使い方、認証の仕組み（OAuthやトークン管理など）を理解する必要があります。3D表示のライブラリを適切に扱うことに加え、データをやり取りするAPI設計やWebサーバーとの通信効率にも配慮しなければ、実務で使いにくいシステムになる可能性があります。
さらに、テスト段階ではセキュリティの確認や、ユーザー視点での操作性チェックを十分に行うことが重要です。特に大規模建設プロジェクトでは、現場作業員や外部協力会社など多様なユーザーが利用するため、使いやすさと権限設計の両立が求められます。
4. Viewer開発でよくある失敗パターン
Viewer開発が失敗しやすいのは、表示技術そのものよりも、要件整理や運用設計を後回しにしやすいためです。実際には、開発費用の高騰、変換処理の見積もり不足、使われないUI、権限管理の不備といった問題が起こりやすく、導入後にPDF運用へ逆戻りするケースもあります。
ここでは、Viewer開発で特に起こりやすい失敗パターンを4つに絞って整理します。
よくある失敗パターン
- 自作範囲が広がりすぎてコストが膨らむ
- ファイル変換の前提を見落とす
- UI/UXが現場利用に合わない
- セキュリティと権限設計が後回しになる
4.1. 自作の誤算：自由度とコスト
「Viewerを自作すれば自由に機能を追加できる」という考えで開発を始めた結果、想定以上のコストや長期化した開発期間に悩まされるケースは少なくありません。
確かに、Three.jsなどの3Dライブラリを使って一から構築すれば、カスタマイズ性は高まります。しかし、Model Derivativeのような変換機能を自前で用意する必要があるなど、開発範囲が大きく広がります。特にDWGやIFCを安定して扱うには専門知識が求められ、試行錯誤が続くことも多くなります。
その結果、コストが想定を超えるだけでなく、開発チームの負担も増え、プロジェクトが停滞する可能性があります。Viewerは開発後の運用も含めて考える必要があり、保守性を踏まえた選択が重要です。
すべてを自作するのではなく、APSなどの既存APIやツールを活用し、必要な部分のみをカスタマイズする方法が現実的といえるでしょう。
4.2. ファイル表示の誤解
「DWGファイルをそのままブラウザにドラッグ＆ドロップすれば表示できるのでは」と考え、準備不足のまま開発を進めてしまうケースもあります。しかし実際には、CAD/BIMデータは形式が多様であり、直接ブラウザで表示できる形式は限られています。
3Dデータを可視化するには、Model Derivativeのような変換処理が必要になります。APSを利用すればこの変換を効率よく行えますが、これを自社で一から構築しようとすると大きな負担がかかります。その結果、開発期間が延び、実際に利用できるまでに時間がかかることもあります。
また、ファイル表示の問題はセキュリティや権限管理とも密接に関係します。許可されたユーザーのみがデータを閲覧できる仕組みを構築するには、認証と連携した設計が必要です。こうした点を軽視すると、Viewerの完成度に影響を及ぼします。
そのため、ファイル変換の重要性を早い段階で理解し、外部サービスを利用するか自社で対応するかを慎重に検討することが重要です。
4.3. ユーザー体験の軽視
Viewer開発では、技術的な要素に注目するあまり、ユーザー体験が後回しになるケースも見られます。例えば、複雑なUI構造や分かりにくい操作導線、読み込みに時間がかかるモデルなどは、結果として現場で使われない原因になります。
特に大規模建設プロジェクトでは、ITスキルに差のあるさまざまなユーザーが利用します。初心者でも扱いやすいか、タブレットなどの端末でも操作しやすいかといった視点が欠けると、導入後の活用が進まなくなります。
これを防ぐには、早い段階でプロトタイプを作成し、関係者に試用してもらうことが有効です。また、本格導入前にUI/UXの検証を行い、改善点を反映することが重要です。
ユーザーの意見を収集する体制が整っていない場合は、外部の専門家に相談することも有効な選択肢となります。
4.4. セキュリティと権限の後回し問題
Viewer開発に限らず、システム構築ではセキュリティや権限管理が後回しになりがちです。特に外部に3Dモデルを共有する場合は、機密情報の流出リスクを十分に考慮する必要があります。
認証やアクセス制御が不十分な場合、意図しないユーザーに情報が公開される可能性があります。また、閲覧リンクの管理が甘いと、誰でもアクセスできる状態になり、プロジェクト全体の信頼性に影響を及ぼす恐れがあります。
こうしたリスクを防ぐためには、閲覧権限の設定やログ管理、データ保護の仕組みを適切に設計することが重要です。APSではトークン管理やOAuthによる認証機能が提供されており、これらを初期段階から組み込むことで、セキュリティを確保しやすくなります。
セキュリティ対策は後から追加すると整合性が取りにくく、工数も増加します。開発初期から考慮しておくことが重要です。
5. Viewer開発をやるべきかの判断基準
ここでは、Viewer開発を行うべきかどうかの判断基準を整理します。大規模建設プロジェクトのマネージャーにとっては、どの視点で判断すべきかを考えるうえで重要なポイントです。
Viewer開発を本格的に進めるには、一定のコストと開発期間が必要になります。十分な検討をせずに導入すると、後から方向転換が難しくなるため、明確な判断基準を持つことが重要です。
ここで示す「やるべきケース」と「避けるべきケース」を参考に、自社のプロジェクト規模やニーズに適しているかを見極めましょう。例えば、単にファイルを閲覧できればよい場合と、大規模データを活用するオンライン基盤が必要な場合とでは、求められるViewerの役割は大きく異なります。
| 判断観点 | Viewer開発を検討しやすいケース | Viewer開発を避けやすいケース |
| 業務要件 | 独自ワークフローと連携したい | 単純閲覧だけで足りる |
| データ規模 | 大規模データを継続利用する | 小規模・短期案件が中心 |
| 必要機能 | UIや機能を細かく作り込みたい | 既存機能で十分 |
| 体制 | IT人材や運用体制がある | 社内リソースが不足している |
| 投資判断 | 長期運用で回収しやすい | 開発費を回収しにくい |
以下では、Viewer開発を進めるべき場面と、別の手段を検討したほうがよい場面を簡潔に整理します。
5.1. Viewer開発が必要なケース
① 自社システムやワークフローと密に連携したい場合
CAD/BIMデータを独自の業務プロセスで活用する場面が多く、標準的なViewerでは対応しきれない場合に有効です。必要な機能を絞って追加できる点がメリットです。
② 大規模データを扱うプロジェクトで可視化が不可欠な場合
複数拠点や多数の関係者が関わる中で、3Dデータの可視化が重要な役割を担うケースです。APSは複数フォーマットに対応しやすく、大規模データにも対応できる設計となっているため、プロジェクト運営において有効です。
③ カスタマイズ性を重視したい場合
ViewerのUIや操作性を独自に最適化したり、計測や断面表示などの機能を高度に作り込みたい場合です。単なる閲覧にとどまらず、分析にも対応する機能を組み込みたい企業に適しています。
④ 投資対効果を重視し、長期的に運用できる仕組みが必要な場合
Viewer開発にはコストがかかりますが、それを上回る業務効率化や意思決定の迅速化が期待できる場合、長期的な投資として有効です。特に大規模建設現場では、ミスや遅延による影響が大きいため、導入の価値は高いといえます。
5.2. Viewer開発を避けるべきケース
① 単純な閲覧機能だけで十分な場合
社内でPDFなどの2Dデータ共有が中心で、3D表示の必要性が高くない場合は、Viewer開発まで行う必要はありません。既存サービスや簡易Viewerで対応できる場合は、過剰な投資を避けるべきです。
② 小規模で短期のプロジェクトが多い場合
期間が短く開発費用を回収しにくい環境では、専用Viewerの構築はコストに見合わない可能性があります。既存ツールやSaaSを活用したほうが効率的です。
③ 社内のITリソースが不足している場合
Viewer開発にはJavaScriptやAPI、セキュリティに関する知識が求められます。対応できる人材が不足している状態で内製化すると、運用が停滞し、十分に活用できなくなる恐れがあります。
④ 明確なプロジェクト方針や目的が定まっていない場合
開発目的が曖昧なままだと、必要な機能が定まらず、不要な機能追加が続く可能性があります。その結果、開発期間の長期化や運用コストの増加につながるため、導入時期は慎重に検討する必要があります。
6. Viewer開発の3つの選択肢を比較
Viewer開発の選択肢は、大きく自作、APSの利用、既存ツールの活用の3つに分かれます。違いが出やすいのは、どこまで自社で実装するかと、変換・表示・運用の負荷をどこで吸収するかです。
| 比較項目 | 自作 | APSの利用 | 既存ツールの活用 |
| 導入速度 | 遅い | 中程度 | 速い |
| 柔軟性 | 高い | 高め | 低め |
| 変換対応 | 自前実装が必要 | APIで対応しやすい | ツール依存 |
| 初期負荷 | 高い | 中程度 | 低い |
| 運用負荷 | 高い | 中程度 | 低め |
| 向いているケース | 独自要件が強い | 柔軟性と効率を両立したい | まず早く使いたい |
以下では、コスト・導入期間・柔軟性・運用負荷の観点から3つの方法を比較します。
6.1. 自作：コストと柔軟性
自作は自由度が高い一方で、多くの時間とITリソースを必要とします。Three.jsなどのライブラリを使ってWebGLによる描画を実装し、バックエンドを構築してファイル変換や権限管理も行う必要があります。
この方法は、Viewerの見た目や機能を柔軟に設計できる点がメリットですが、開発者のスキルやチーム体制によって成果が大きく左右されます。また、開発後の運用や機能追加にかかるコストも考慮しなければなりません。
大規模建設プロジェクト向けの独自機能を実装する場合には有効ですが、全体としてはリスクが高いため、明確な要件と十分な開発体制が整っている企業に適した選択肢です。
さらに、CAD/BIMデータへの対応は複雑になりやすく、その分のコストは慎重に見積もる必要があります。
6.2. APSの利用：効率とコスト
APSはViewer SDKやModel Derivativeなどの機能をまとめて提供しているため、開発効率が高く、必要な機能に集中しやすい点が特徴です。DWGやIFCなど複数のフォーマットに対応しており、WebGLベースの表示環境を構築しやすくなっています。
また、Viewer APIを利用することで比較的少ないコードで開発を始められるため、プロトタイプの作成やUXの検証をスムーズに進めることができます。大規模建設プロジェクトで複数のユーザーが利用する環境にも対応しやすく、必要に応じてUIのカスタマイズや機能追加も行えます。
一方で、APSには無料枠（Free Tier）があるものの、利用量や使用するAPIによっては有料（従量課金）となるため、コスト設計には注意が必要です。利用量によってはランニングコストが増える可能性がありますが、自作に比べて開発期間を短縮できる点は大きな利点です。
そのため、開発の本質的な部分に集中したい企業にとって、有効な選択肢といえます。
6.3. 既存ツールの活用：速度と簡便性
既存ツール（Viewer SaaSなど）を利用する方法は、最も短期間で導入できる点がメリットです。導入や運用が比較的簡単で、ITエンジニアが少ない環境でも対応しやすい特徴があります。
ただし、標準機能以外の拡張が難しい場合が多く、必要なカスタマイズやシステム連携が実現できないこともあります。大規模建設プロジェクトでは独自のワークフローや権限管理が求められるため、要件を満たせるか事前に確認することが重要です。
また、SaaSの場合は提供元のアップデートに依存するため、機能追加のタイミングや内容によっては使いにくさを感じることもあります。とはいえ、小規模や短期のプロジェクトには適しており、運用負担の軽減につながる点は大きな利点です。
最終的には、「導入の速さ」と「柔軟性」のどちらを重視するかで判断するのが適切です。
7. APSを使うべきケースとは
APSが有効なのは、CAD/BIMデータの変換や表示といった負荷の高い処理を外部に任せたい場合です。特に複数フォーマットを扱う場合や、大規模データを扱うプロジェクトでは、自作よりも効率的に開発を進めやすくなります。
一方で、単純な閲覧用途であれば過剰になることもあるため、要件に応じて選択することが重要です。
例えば、「DWGを含む多様なデータ形式を扱いたい」「社内外の複数拠点からモデルを共有したい」「ViewerのUIや操作性を調整したい」といった要望がある場合、APSは有効な選択肢となります。API利用料が発生する場合もありますが、低レイヤーの処理を省略できるため、開発期間や工数の削減につながる可能性があります。その結果、状況によってはコストの最適化につながることもあります。
結論として、APSは「機能と柔軟性のバランスを重視したい」「大規模データに対応したい」といった企業に適した手段といえます。
8. APSでのViewer開発の流れ
APSを使ったViewer開発は、「認証」「変換」「表示」の3つの工程で構成されます。
まず認証設定を行い、次にModel Derivativeでデータを変換し、最後にViewer SDKで表示します。
このように、データを変換してから表示する流れを前提に設計することが、開発の基本となります。
8.1. 実務での具体的な手順
APSでのViewer開発の基本手順
- APSの開発者アカウントを作成し、クライアントIDとシークレットを取得する
- 必要に応じて社内認証基盤と連携し、OAuthを設定する
- モデルをアップロードし、Model Derivativeで変換する
- 生成されたURNをViewer SDKに渡して表示する
- 必要に応じてUIや機能をカスタマイズする
- テスト環境で検証し、本番運用へ移行する
9. まとめ｜Viewer開発は「要件の切り分け」で決まる
Viewer開発の成否は、3D表示の技術そのものではなく、「何を実現したいのか」をどこまで具体化できるかで決まります。
要件別の考え方
- 独自ワークフローと連携したい
→ 自作またはAPS - 複数フォーマットや大規模データに対応したい
→ APSが有力 - 単純な閲覧が中心
→ 既存ツールで十分
特にAPSは、データ変換・表示・認証といった負荷の高い処理をまとめて扱えるため、開発工数を抑えつつ柔軟性を確保したいケースに適しています。
まずは小さな範囲で要件を検証し、「Viewerが本当に必要か」を見極めたうえで段階的に拡張していくことが、失敗を防ぐ最も現実的な進め方です。
＜参考文献＞
Viewer SDK | Autodesk Platform Services (APS)
https://aps.autodesk.com/developer/overview/viewer-sdk
Overview | Viewer | Autodesk Platform Services
https://aps.autodesk.com/en/docs/viewer/v6/developers_guide/overview/
Viewer & UI | Autodesk Platform Services Tutorials
https://get-started.aps.autodesk.com/tutorials/simple-viewer/viewer/
Autodesk Platform Services (formerly Forge) | Official APIs and Services
https://www.autodesk.com/products/autodesk-platform-services/overview
Autodesk Platform Services
https://aps.autodesk.com