Business Central のPer-Tenant Extensionと ISVアプリ、どちらを選ぶべきか?
By Mirko Peters ·
Business Central のPer-Tenant Extension(PTE)とISVアプリを比較します。ERP環境に適したカスタマイズ戦略の選び方を解説します。
Automatically translated with AI from the original post. Read the English original

Dynamics 365 Business Central をカスタマイズする際、組織はカスタムのPer-Tenant Extension(PTE)を構築するか、AppSourceで提供される既製のISVアプリを購入するかを決める必要があります。本ガイドでは、両方の選択肢におけるコスト、保守、スケーラビリティ、技術的な影響を整理し、IT責任者や意思決定者が自社のワークフローに適した統合戦略を選べるようにします。
重要なポイント
- ISVアプリは、出荷、銀行、税務のローカライズといった一般的な業務プロセス向けに、構築済みでスケーラブルなソリューションを提供します。
- Per-Tenant Extension(PTE)は、特定の組織の固有のワークフロー専用に設計された、カスタムコーディングのアドオンです。
- カスタムPTEを選択した場合、テスト、ドキュメント作成、更新への互換性確保について、組織が長期にわたるすべての責任を負うことになります。
- AppSourceのマーケットプレース アプリは、初期の開発時間を節約でき、多くの場合、独立系ソフトウェアベンダーによる継続的な更新とサポートが含まれます。
- 社内リソースをカスタム開発に投入する前に、意思決定者はまず中核となる業務要件を必ず評価すべきです。
Business Central カスタマイズのジレンマを理解する
Dynamics 365 Business Central は、財務、販売、在庫、サプライチェーン管理のための堅牢なERP基盤として機能します。しかし、標準の機能が各企業の業務実態に100%合致することはほとんどありません。組織は必ず、標準のページ、フィールド、またはレポートでは専門的なワークフローを十分にカバーできない場面に直面します。
従来、ERPソフトウェアの変更とはコアアプリケーションのコードを書き換えることを意味していました。これは、ソフトウェアベンダーが自動更新を配信するたびに大きな問題を引き起こすやり方でした。現代のBusiness Central のアーキテクチャは、拡張機能によってこの問題を解決しています。カスタムコードを標準アプリケーションの基盤からきれいに分離して保持できるのです。ただし、拡張機能を使うと決めた時点で、重要な戦略上の分岐点が現れます。ISV(独立系ソフトウェアベンダー)からパッケージ化されたアプリを購入するのか、それともカスタムのPer-Tenant Extension(PTE)を発注するのかという選択です。
ISVアプリ: パッケージ化された再利用性のメリット
ISVアプリとは、独立系ベンダーが、複数のBusiness Central 顧客に共通する特定の業務課題を解決するために開発した商用ソフトウェアパッケージです。これらのソリューションは、多くの場合Microsoft AppSourceを通じて直接見つけられ、導入されます。
大手グローバル配送業者との連携、標準化された決済ゲートウェイの組み込み、または複雑な国際的な電子インボイス規制への対応が必要な場合は、通常、ISVアプリが最も効率的な方法です。同じアプリケーションを数百社もの企業が利用しているため、ベンダーがコードベースを継続的に保守、更新、サポートします。
ISVアプリのメリット:
- ゼロから自社開発するのに比べ、初期導入コストを抑えられます。
- ドキュメント、セットアップ ウィザード、積極的なベンダーサポートの窓口が標準で用意されています。
- Microsoft の Business Central のウェーブリリースに合わせて、互換性に関する更新が提供されます。
ISVアプリのデメリット:
- アプリに定義された既定のパラメーターに合わせて、社内の業務フローを多少変更する必要がある場合があります。
- 継続的なサブスクリプション料金や、利用量に応じて増加する従量課金が発生します。
- 業務プロセスが一般的な業界標準から大きく外れる場合、柔軟性が低くなります。
Per-Tenant Extension:独自の業務に合わせて構築
Per-Tenant Extension(PTE)は、単一の組織の Business Central 環境向けに開発された専用のアドオンです。AppSource で一般公開されることはありません。PTE は、自社のビジネスモデルに固有で、他社とは明確に異なる業務プロセス向けに設計されています。
例えば、温度管理された輸送、リターナブルコンテナの追跡、長年のクライアント契約で取り決められた動的な配送ゾーンによって、価格アルゴリズムが複雑になっている地域の食品卸売業者を想像してください。既存の配送アプリのどれも、これらの細かなビジネスルールに合致しない場合、認定 Microsoft パートナーが専用の PTE を構築できます。
Per-Tenant Extension のメリット:
- 独自性が高い、または競争上重要な業務フローに、正確かつ手作りで適合させられます。
- 妥協が不要になり、既存の社内手順を変えずに業務を続けられます。
- 項目の配置、ビジネスロジック、自動検証ルールを完全に制御できます。
Per-Tenant Extension のデメリット:
- 保守に関する全責任と長期的な負担を、組織が負うことになります。
- Business Central を更新するたびに、開発者またはパートナーが PTE のコードを十分にテストし、必要に応じて修正する必要があります。
- カスタム開発、ドキュメント作成、継続的なサポート契約に、より多くの初期投資が必要です。
自社に適した選択肢の選び方
ISVアプリとカスタムの Per-Tenant Extension のどちらを選ぶかは、要件の整理を慎重に行う必要があります。自社専用に作られているというだけで、カスタム開発が本質的に優れていると思い込むという、よくある落とし穴は避けてください。
まず、ビジネスギャップの性質を評価します。銀行、クレジットカード決済事業者、宅配業者などの汎用的なサービスプロバイダーへの接続が必要な場合は、まず AppSource を検索してください。成熟し、サポートされているマーケットプレース アプリを購入すれば、開発と保守にかかる膨大な工数を節約できます。
逆に、競争上の中核的な優位性や、市場で自社ブランドを定義するような、特殊な業務モデルが要件の中心である場合は、Per-Tenant Extension が論理的な選択肢になります。購入したものでも自社開発したものでも、すべての拡張機能は本番環境へデプロイする前に、Business Central のサンドボックス環境で徹底的にテストしてください。
まとめ
ISVアプリと Per-Tenant Extension のどちらを選ぶかは、IT チームが今後の保守やプラットフォームのアップグレードをどう管理するかを左右します。それぞれのアプローチの利点と所有に伴う責任の違いを理解すれば、Business Central の基盤を守りながら、従業員に必要なツールを提供できます。拡張機能の仕組みと、インストール前に確認すべき点をさらに詳しく知るには、エピソードの全編を聴き、Microsoft クラウド エコシステムに関する専門的な知見を毎日発信しているポッドキャストを購読してください。
よくある質問
Business Central における ISVアプリと Per-Tenant Extension の主な違いは何ですか?
ISVアプリは、独立系ソフトウェアベンダーが複数の顧客向けに開発し、AppSource でホストされる、パッケージ化された再利用可能なソリューションです。一方、Per-Tenant Extension(PTE)は、単一の組織の固有のテナント環境向けにカスタムコーディングされたものです。
購入したISVアプリが業務フローに完全には合わない場合、変更できますか?
一般的に、パッケージ化されたISVアプリのソースコードを直接変更することはできません。ただし、ページ拡張やイベント発行元を使用して機能を補完したり、ISVアプリの出力を基にした補助的なルールを構築したりすることは可能です。
Microsoftが Business Central を更新したとき、Per-Tenant Extensions(PTE)の更新は誰が担当しますか?
最終的な責任は、PTEを保守する組織にあります。Microsoftが大規模なプラットフォーム更新をリリースした際には、社内のIT担当チームまたは外部のBusiness Centralパートナーがテストを行い、互換性を維持するためにPTEのコードを必要に応じて更新する必要があります。
Per-Tenant Extensionsは常にISVアプリより高価ですか?
カスタムPTEの初期開発コストは、通常、既存のISVアプリのライセンス費用より高くなります。ただし、長期的に見ると、ISVアプリで複数のユーザーライセンスに対して発生する定期的なサブスクリプション料金が、用途を絞った安定したPTEの保守費用を上回ることもあります。
新しい拡張機能を本番のBusiness Central環境にデプロイする前に、どのようにテストすればよいですか?
新しい拡張機能は、必ず専用のBusiness Centralサンドボックス環境にデプロイしてテストしてください。コードが実際の企業データに触れる前に、エンドユーザーと実際の業務に即したテストケースを実行することをお勧めします。