Delphi デスクトップと Web ポータルを組み合わせる：アーキテクチャ、インターフェース、断絶のないモダナイゼーション

多くの企業では、業務の“中枢”が長年にわたりDelphiデスクトップアプリケーションとして成長してきました：VCLクライアント、蓄積された業務知識、高速なデータ入力、印刷・レポーティング経路、専用ハードウェア、そしてしばしばLAN内での直接的なデータベースアクセスです。一方で、セルフサービスや外部との協働に対する期待は高まり続けています。顧客はVPNやデスクトップのロールアウト、ローカルインストールなしで、受注状況の確認、ドキュメント交換、クレームの登録を望みます。

Delphi デスクトップと Web ポータルの組み合わせは実務上、運用性、セキュリティ、データ整合性を維持できる形でこれら二つの世界を統合することを意味します。重要なのはブラウザ上で画面を単に“再現”することではなく、プロセス、権限、データ経路を明確に分離し、両フロントエンドが共通のルールに従って動作するアーキテクチャです。得られるのは Big-Bang を避けたモダナイゼーション経路です：デスクトップは生産性を保ちつつ、Web ポータルは段階的に管理された形で拡張されます。

本稿はIT責任者、管理者、技術プロジェクト担当者を対象としています。焦点は運用、管理、インターフェース、セキュリティ、データ保持、マイグレーションへの影響であり、フレームワークの細部ではありません。実務で使えるパターン、意思決定基準、典型的な落とし穴とその対策を提供します。

「ポータル instead of デスクトップ」が現実的でない理由

B2B環境では、デスクトップクライアントが依然として有効である多くの理由があります。管理者が現場で実感する点は明確です：ポータルは分散ユーザーには適しているが、特定の作業はデスクトップの方が効率的、あるいはそもそも実行不可能な場合があります。

日常で効いてくるデスクトップの強み

• 複雑なデータ入力：非常に密な画面、キーボード操作、大きなテーブル表示、レコード間の高速な切替え。
• 周辺機器とローカル統合：ラベルプリンタ、スキャナ、シリアル機器、あるいは特定のWindowsコンポーネントなど。
• LAN近接型のパフォーマンス：大量データ処理や極めて低遅延を必要とするプロセス。
• 成長したワークフロー：多数の例外処理があり、1:1でポータルに移すことが初期段階で高リスクとなる場合。

新たな要件を満たすポータルの強み

• 外部アクセス：顧客、仕入先、パートナーがクライアントの配布なしに利用可能。
• 中央管理性（バージョン、機能、権限）を明確な外側の境界で制御できること。
• デバイス非依存性（ブラウザ、モバイル利用）により、営業や経営層にも対応。
• 狙いを定めたプロセス公開：ステータス照会、アップロード、承認、チケットワークフロー等の限定的公開。

組み合わせることで利点が生まれます：デスクトップは内部ユーザー向けの高性能ツールとして残り、ポータルは外部ユーザー向けの管理された入り口になります。これが二つの並列した“真実”に分裂しないようにするには、結合するコアが必要です。

Delphi デスクトップと Web ポータルを組み合わせる場合の三つの目標アーキテクチャ

アーキテクチャ判断の主題は責任範囲です：業務ルールはどこに置くか？誰がデータを変更できるか？どの層が「Single Source of Truth（規定と状態の根拠）」になるか？技術的な意思決定者にとって重要なのは、選択が運用、障害解析、リリース管理、セキュリティに直接影響する点です。

変種 A: ポータルはREST-APIで補完、デスクトップが主導

ポータルは典型的に「参照と起点」を担う限定的なユースケースに対応します：ステータス、ドキュメント、承認、簡易入力など。そのためにDelphi REST-APIや独立したREST-サーバを導入します。デスクトップアプリケーションは当面データベースへ直接アクセスを続けられます。

運用面の利点：導入が速く、デスクトップへの介入が少なく、最初のポータル価値を早期に提供できます。

リスクポイント：二つのデータ経路が存在します（デスクトップ → 直接DB、ポータル → API）。業務ルールがデスクトップ内にのみ存在する場合、整合性の問題が生じます。対策としては、ポータル機能をルールが単純でサーバ側で表現可能な領域から始めること（例：ドキュメント提供、ステータス照会、定義済みの承認アクション）です。

変種 B: サービスコアを共通のプロセス層に（並行運用時に推奨）

ここでは業務ロジックを段階的にデスクトップからサービスへ移行します。デスクトップとポータルは同一のエンドポイントを使用します。デスクトップはリッチクライアント（UI、ローカル統合）により特化し、ルールとバリデーションはサーバ側に置かれます。

運用面の利点：権限、監査、ステータスロジック、バリデーションの中央管理が可能になり、すべてのフロントエンドで一貫した挙動が得られます。

工数：初期は大きくなります。API標準、エラー形式、バージョン管理、モニタリング、デプロイを綿密に設計する必要があります。しかしその分、特殊対応が減り、後続の工数は大幅に低減します。

変種 C: ポータルが主導、デスクトップは専門クライアントとして残る

ブラウザを戦略的に標準アクセスとする（例：強く分散した組織）場合に有効な選択です。デスクトップは特定の役割で専用ハードウェアや高性能なデータ収集のために残ります。これを実現するには、サービスコアが特に堅牢でスケーラブルであることが求められます。

Layer-3 アーキテクチャは理解しやすい指針

どの変種でも有用なのがLayer-3アーキテクチャです：(1) プレゼンテーション（デスクトップ/ポータル）、(2) アプリケーション・ドメイン層（ユースケース、ルール）、(3) インフラ（データベース、ファイルストレージ、メッセージング、外部システム）。管理者にとって重要なのは運用の境界が明確になる点です：何が「フロントエンドの問題」で、何が「サービスの問題」で、何がデータベースやストレージに起因するのか。この分離により障害解析が短縮され、デプロイ時の副作用が減ります。

実務の観点：デスクトップとポータルが同じプロセスを共有する方法

最大の課題は「ポータルを作ること」ではなく、デスクトップとポータルが同一プロセスの責任をどのように分担し、ルールを二重実装せずに済ませるかです。実務で特に有効なパターンを三つ紹介します。

1) テーブルやCRUD APIではなくユースケースAPI

行き詰まりになりやすいのは、データベースのテーブルを単に外部に晒すAPI（Create/Read/Update/Delete）のみを提供するケースです。その場合、ポータル側でルールを再実装する必要があり、デスクトップは独自のルールを維持してしまいます。より望ましいのはユースケースAPIです：エンドポイントが「クレーム作成」「受注承認」「ドキュメントアップロード」「出荷ステータス確認」など業務上の操作を表現します。

運用での効果は明白です：バリデーションはサーバ側で行われ、エラーメッセージは再現可能になり、両クライアント（デスクトップとポータル）が同一のロジックで同じ手続きを駆動します。

2) 競合と再試行を制御可能にする

ポータル導入により並行変更やリクエストの再送（タイムアウト、リトライ、ユーザーの二重クリック等）の確率が上がります。ここでは三つの概念が有効で、永続的なロックを導入する必要はありません：

• 冪等性：重要な操作は再送しても同じ結果になるよう設計します。実務では一意のリクエスト識別子（Idempotency Key）で実現することが多いです。
• 楽観的同時実行制御：レコードにバージョン情報（例：「Row Version」）を持たせ、更新時にサービスがバージョン整合性をチェックして競合を明確に返します。
• 短いトランザクション：全てをロックするのではなく、書き込みを短時間に抑え、長時間の作業（例：エクスポート、レポート生成）は非同期で処理します。

技術的意思決定者にとって重要なのは、これらの仕組みがサポート負荷を低減する点です。「二重に処理された」「自分の変更が消えた」といった事象が明確に減ります。

3) 状態と受渡しを明確にモデル化する

デスクトップが複雑なケースを処理し、ポータルが「申請」や前段階を提供するだけの場合、明確なステータス遷移が必要です。実務的な切り分けは次の通りです：ポータルは明確に限定されたステータス領域（例：「提出済み」）で処理を作成・補完し、デスクトップは専門的な処理を行い、サービスコアがステータス変更を決定して記録します。これにより、ポータルクライアントが間接的にプロセスを「壊してしまう」ことを防げます。

データとドキュメント：過小評価されがちな統合領域

ほとんどすべてのポータルはファイル操作を伴います：アップロード、証跡、納品書、画像、PDF出力。管理者にとってこれは重要なポイントであり、バックアップ、権限、ウイルスチェック、ストレージコスト、パフォーマンスに直接影響します。

ファイルはどこに置くか：データベース、ファイル共有、またはオブジェクトストレージ？

代表的な保存オプションは三つあり、それぞれ運用の実態を変えます：

• データベース（BLOB）：トランザクションを厳密に結合する必要があり、バックアップ/リストアを一つにまとめたい場合に良い。欠点はデータベースサイズの増大とバックアップウィンドウの延長です。
• ファイルシステム/共有：オンプレミスで典型的。既存のバックアップ概念に統合しやすい。重要なのは明確な権限管理とアクセスを制御するAPI層です。
• オブジェクトストレージ：スケール、ライフサイクルルール、外部アクセスの技術的分離が必要な場合に適する。鍵や権限モデルを意図的に設計する必要があります。

保存先にかかわらず、ポータルがファイルを共有から直接読み込むべきではありません。サービスのエンドポイント経由での制御されたダウンロード（権限チェック、記録化、必要に応じた期限付きダウンロードURL）が望ましいです。

PDFとレポート：二重実装ではなくサーバ側生成

Delphiデスクトップはしばしば成長した印刷・レポーティング経路を持ち、ポータルでも同じ内容をPDFで提供する必要が出ます。二重に実装するのではなく、テンプレート、バージョン管理、出力形式をサービスコアに集約してドキュメントを生成し、デスクトップとポータルがその成果物を消費する方が合理的です。運用上の利点は明確です：出力の追跡可能性、統一的な保管、デスクトップ依存の低減。

RESTサーバとサービス：Delphi、C#、あるいは混成アーキテクチャ

「DelphiかC#か」の判断は企業にとってイデオロギーではなく、チーム能力、運用環境、保守性に基づくものです。多くの環境では、責任範囲が明確であれば混成アーキテクチャが現実的です。

業務ロジックが既にDelphiにある場合、Delphiをサービスプラットフォームとして使うのは合理的

業務ロジックとデータアクセスが既にDelphiで堅固に実装されている場合、DelphiベースのREST-サーバは効率的になり得ます。管理者と意思決定者が押さえておくべきは：サーバ運用は「デスクトップの延長線」ではないという点です。実稼働サービスには明確な構成、適切なタイムアウト、構造化ログ、ヘルスチェック、再現可能なデプロイが必要です。

古いドライバやBDEが絡む場合はデータ接続の近代化も重要です。BDE-Ablösungやモダンなデータアクセスへの移行は、運用障害の低減とデプロイ容易化に寄与します。レガシーコンポーネントのインストールや保守が減るためです。

ポータルエコシステムにおけるC#サービス：ホスティングとアイデンティティの都合で選ばれることが多い

ポータルが.NET中心の環境で構築される場合、C#サービスは自然な選択になりがちです。Identity 統合、既存の運用標準、Microsoft IIS の背後やコンテナ化プラットフォームでのホスティングといった利点があるためです。重要なのは二重実装を避けることです：業務ロジックをDelphiサービスに残し、C#をエッジ（例：ポータル固有のオーケストレーション）に使うか、あるいはロジックを.NETへ計画的に移行するならば制御されたフェーズと明確な業務境界を設けることです。

APIゲートウェイ：整理要素だが必須ではない

APIゲートウェイはルーティング、レート制限、ロギング、認証などの共通機能を集約できます。小規模な初期アーキテクチャでは一貫したAPI標準があれば十分なこともありますが、複数のサービスや利用者グループが増える段階では、ゲートウェイが外部境界を安定化させ、ポリシーを集中して適用するのに役立ちます。

認証と権限：内部デスクトップから外部ポータル世界へ

ポータルの導入によりユーザー層が変化します：内部ユーザーに加えて外部アカウント、ロール、テナントが増えます。これによりIdentity、権限、監査可能性の要件が生じます。管理者にとって重要なのは、Identityシステムやロールモデルは後から変更するのが難しい点です。

SAML 2.0 または OIDC による SSO：管理負荷を減らし制御を向上

B2B環境ではSAML 2.0（Identity Provider 経由のシングルサインオン）が普及しています。既存のアイデンティティを活用したいためです。OIDC（OpenID Connect）も特に最新のプラットフォームで一般的です。従来のユーザー名/パスワード認証も可能ですが、パスワードポリシー、MFA、リセットプロセス、サポートといった追加作業が発生します。

アーキテクチャ上の重要点：認証（あなたは誰か？）と認可（何を許可されているか？）はサーバ側で検証されるべきであり、ポータルのフロントエンドだけで判断してはいけません。

マルチテナント性とロールモデル：後回しにしない

顧客向けポータルは実務上ほぼ常にテナント分離を要求します：顧客は自分のデータのみを閲覧できます。これはサービスコアで表現されるべきで、理想的には次の仕組みを用います：

• トークン内のClaims（例：Tenant-ID、ロール、契約参照）によりサービスが判断できるようにすること。
• データ行レベルのチェック（Row-Level-Checks）を業務ロジックで行い、「メニューを隠す」だけに留めないこと。
• 重要操作の監査トレイル（誰が、何を、いつ行ったか）と、障害解析のためのリクエストIDによる相関。

必要に応じてデスクトップも同じIdentityスタックに対してトークンで動作させられます。これにより特殊対応が減り、ポータルとデスクトップが同じレコードを操作する際の追跡が容易になります。

データアクセスの近代化：FireDAC、PostgreSQL と制御されたデータ経路

多くのDelphiデスクトップソリューションは歴史的に直接DBアクセスで構築されています。ポータルが加わると、これはアーキテクチャ上の主要な課題になります：データ経路を制御可能にし、バリデーションを中央で効かせ、並列負荷時にもパフォーマンスが安定するようにする必要があります。

FireDACは保守可能なデータアクセスの基盤

BDE-Ablösung mit nativer Anbindungは、Delphi環境でモダンなデータベースへアクセスする際の一般的な標準です。重要なのはコンポーネント自体よりも統一化です：パラメータ化されたクエリ、明確なトランザクション境界、統一エラー処理、計測可能な実行時間。運用面ではタイムアウトやリソース消費を計画可能にし、ログとモニタリングで問題の追跡ができることが重要です。

Delphiでの PostgreSQL：型とマイグレーション計画が整っていれば扱いやすい

PostgreSQL mit Delphiは、UUID、タイムスタンプ、JSONフィールドなどの型マッピング、インデックス、スキーママイグレーションを適切に扱えば堅牢です。ポータルは多くのフィルタを含む一覧問い合わせを発生させます。フィルタ、ページング、ソートはサーバ側で実装すべきであり、不要な大量データ転送を避けることで負荷を低減し、デスクトップのパフォーマンスを損なわずにユーザ体験を向上できます。

運用、デプロイ、モニタリング：Delphiバックエンドのポータル成熟度を高める

ポータルは通常常時稼働を要求されるため、純粋なデスクトップより運用面で負荷が高くなります。管理者にとって、ここで良いアーキテクチャがすぐに効果を発揮します：再現可能なデプロイ、明確な可観測性（ログ/メトリクス）、定義されたメンテナンスウィンドウです。

WindowsサービスまたはLinuxサービス：重要なのは運用モデル

DelphiサービスはWindows-およびLinux-サービスとして、あるいはLinuxデーモンとして運用できます。重要なのはOSではなく、運用を安定化させるための標準です：

• ヘルスチェック：モニタリングやロードバランサ用（例：「サービス生存」「データベース接続可能」）。
• 構造化されたログ：リクエストID、ユーザー/テナント、実行時間、ステータスコードを含め、サポートで再現可能にすること。
• ビルド不要の構成変更（環境変数、中央構成ファイル等）でデプロイを自動化できるようにすること。
• ロールバック可能性：明確なバージョン管理とマイグレーションに耐えるデータベース変更。

負荷プロファイル：ポータルは「多数の短いリクエスト」

デスクトップ利用はユーザーごとに長い作業セッションを生みやすく、ポータルは短時間で並列的な多数のリクエストを生みます。典型的な技術対策は：

• 徹底したページング、サーバ側フィルタ、応答サイズの制限
• マスタデータや頻度の低い問い合わせへのキャッシュ
• 長時間処理（エクスポート、レポートバンドル）は非同期ジョブで処理
• レートリミットや悪用対策

意思決定者にとって重要なのは、パフォーマンスは「最後の微調整」ではなく、API定義の一部（レスポンスサイズ、タイムアウト、バックグラウンド処理）であるという点です。

Big-Bang を避けるモダナイゼーション：五段階の現実的な道筋

完全な再構築は稀で、プロセス知識がDelphiクライアントに埋め込まれているためリスクが高いことが多いです。各段階が実際に稼働可能で運用を危険にさらさない進め方が実績として有効です。

1) 現状把握：プロセス、データ所有権、統合

画面から始めるのではなくユースケースから始めてください：どの業務がポータルに載るべきか？外部ユーザーが見たり変更したりできるデータは何か？ERP、DMS、CRM への既存インターフェースは何か？ここから優先順位付けされたAPIリストが生成され、実際の価値をもたらします。

2) サービス基盤の定義：認証、エラー形式、ロギング、バージョン管理

この基盤が後の保守性を決めます。認証/認可、統一エラー形式、リクエスト相関、APIバージョニング、テレメトリの標準を早期に合意してください。これによりポータルチーム、バックエンドチーム、運用の摩擦が減ります。

3) 最初のポータル経路をエンドツーエンドで提供

ドキュメント領域やステータス照会など明確に切り分けられたプロセスを選びます。重要なのはチェーン全体が機能すること：ログイン、権限チェック、API、UI、ロギング、モニタリング、運用まで。これにより組織は早期に日常運用で機能する基準を確認できます。

4) デスクトップの選択的連携：重要な書き込みパスをサービス経由にする

サービスが安定したら、デスクトップの一部機能を移行します：特にステータス変更、承認、中央バリデーションなど。デスクトップは引き続き高性能でありつつ、ルールは一貫化され、直接DBへの書き込みは段階的に減らせます。

5) 統合：二重ルールと特殊経路を削減する

時間が経つと「二つのシステム」が発生しがちです。定期的な統合作業を計画してください：どのルールが重複しているか？どこでポータルがデスクトップのサービスを利用できるか？どのレポートを中央生成に移すべきか？目標は管理可能なプラットフォームであり、教条ではありません。

運用面での典型的な落とし穴と回避策

ルールがポータルで再実装される

これにより逸脱とサポート事象が発生します。対策：ユースケースAPIとサーバ側バリデーション、明確なエラー返却、可能なら共通の業務テストシナリオ。

デスクトップとポータル間でのデータ所有権の不明確さ

両クライアントが「何でも」変更できると競合が発生します。対策：ステータスモデル、責任範囲の定義、競合変更には楽観的同時実行制御を導入。

セキュリティを後付けのオプションとみなす

顧客ポータルでは SSO、テナントチェック、安全なファイルダウンロード、監査が初期から必要です。後付けは高コストでセキュリティリスクを増大させます。

運用の透明性欠如

リクエストID、構造化ログ、ヘルスチェックがないと障害解析は探偵的作業になります。対策：初期サービスリリースから可観測性を必須にすること。

結論：サービスコアがデスクトップの強みとポータルの到達範囲を結ぶ

Delphiデスクトップと Web ポータルの組み合わせは、多くの企業にとって現実的な道であり、既存のコアプロセスを維持しつつ外部協業を可能にします。重要なのは二つの分断された世界を運用するのではなく、結合するサービスコアを構築することです：ユースケースAPI、明確な権限、追跡可能な状態、制御されたデータ経路、ロギング、モニタリング、計画可能なデプロイを備えた運用モデルです。

こうして段階的なモダナイゼーションが可能になります：デスクトップは生産性を維持し、ポータルは早期に価値を提供し、アーキテクチャは段階的に一貫性と保守性を高めていきます。

業務的には、Delphi Modernisierungも重要な役割を果たします。統合、データフロー、継続的な開発が適切に連携する場合に限り効果が発揮されます。

Projekt oder Modernisierungsvorhaben mit Net-Base besprechen.