C#とDelphiを共通アーキテクチャで：実務的な統合、二者択一ではなく

多くのIT部門で状況は類似しています。安定してプロセスに密着したDelphiデスクトップアプリケーションが重要な業務を担う一方で、Web、ポータル、モバイル利用、クラウドサービスとの統合といった新たな要件が強く求められています。同時に、サービス、Web-API、Identity統合に関しては多くの企業でC#が既定の選択肢として採用されています。したがって中心的な問いはもはや「DelphiかC#か？」ではなく、C#とDelphiを共通のアーキテクチャに組み合わせ、運用、保守、データ管理、セキュリティを制御可能に保つことです。

本稿は、すべてを一から作り直せない、あるいは作り直すべきでない企業環境で実務的に有効なアーキテクチャ原則を述べます。焦点はデスクトップクライアント、サービス、データ、インターフェース間の明確な責任分担と、稼働中のプロセスを危険にさらさずにモダナイゼーションをリスク低く計画する方法にあります。

なぜ企業で混在スタックが普通なのか

成熟してきた企業向けデジタルソリューションはほとんどの場合、無から構築されるものではありません。Delphiアプリケーションは長年にわたり業務プロセスに密着して拡張され、豊富なデータロジックと特殊ケースに関する深いノウハウを内包しています。一方で、セルフサービスポータル、自動化されたデータ交換、DMS/CRM/ERPの連携、マルチテナンシー、より強い監査対応、Single Sign-onなどの新たな要件が発生してきました。

この文脈でC#はWebやサービスのエコシステムにおいてしばしば利点を提供します：幅広いホスティングオプション、標準化されたミドルウェア、Identity Providerとの良好な統合、Web-API向けの確立されたパターンなどです。対してDelphiは、パフォーマントなWindowsデスクトップクライアント、長期的に維持されたVCLアプリケーション、あるいは特定のマルチプラットフォームクライアント（例：FMX経由）といった領域で依然として強みを持ちます。

したがって混在は「例外」ではなく、投資保護とモダナイゼーション要求に対する現実的な回答です。重要なのは、共通運用が継続的な工事現場にならないことです。

アーキテクチャ原則：言語の境界よりも明確な層分け

二つの言語が共存すると、技術で境界を分けたくなる誘惑があります（「Alles Delphi ist Legacy, alles C# ist neu」 のように）。技術的には短期的に機能することがあっても、長期的には摩擦を生みます：ビジネスルールの重複、責任範囲の不明確化、再現困難な障害などです。

代わりに有効なのは、しばしばLayer-3 Architekturとして実装されるような、機能に基づく層構造です：プレゼンテーション（UI）、ドメイン（業務ロジック）、インフラストラクチャ（データアクセス、外部システム）。重要なのは教科書的なモデルそのものではなく、日常業務における具体的な効果です：データ、バリデーション、ワークフローに関する判断が一箇所で行われ、安定したインターフェースを通じて提供されることです。

混在アーキテクチャにおける実務的な意味は次のとおりです：Delphiは引き続きUI部分（あるいは特定のワークフロー）を担うことができ、同時にC# Servicesが業務ドメイン層をカプセル化する、またはその逆があり得ます。重要なのは、層間の境界が技術的に整備され、テスト可能であることです。

C# und Delphi in einer gemeinsamen Architektur: drei bewährte Integrationsmuster

DelphiとC#の連携に「唯一の正解」はない。良い判断は運用、セキュリティ要件、レイテンシ、データ量、リリースサイクルに基づく。実務では三つのパターンが定着している。

1) HTTP/RESTによるサービス指向：標準的な結合

運用と今後の拡張性の観点で最も堅牢なのは、REST-API（HTTPベースのインターフェース）による連携であることが多い。DelphiクライアントはC#やDelphiのサービスを呼び出し、C#ポータルも同じエンドポイントを利用する。このような疎結合によりリリースが計画しやすくなる：APIが後方互換であればクライアント側の更新は必須ではない。

重要なのは専門的な設計である：タイムアウト、リトライ、冪等性（副作用のない再試行）、明確なエラーコード、バージョニング戦略。運用・管理側ではさらに統一されたログ、追跡可能なリクエストID、明確に計測できる応答時間が求められる。

2) 共有データベース：明確なルールがある場合のみ

DelphiとC#が同一データベースに直接アクセスするのは初期は手早く感じられるが、同じテーブル群に両者が直接書き込むと長期的にはリスクが高い。理由は、業務ルールがトリガーやストアドプロシージャ、あるいは「クライアントのどこか」に移り、障害解析や監査が困難になるためである。

共有データベースが避けられない（移行期間など）場合は、明確なルールが必要である：

• 書き込みを集中させる：特定エンティティについて一つのシステムをSystem of Record（記録系システム）とする。
• 契約を定義する：直接テーブルにアクセスするのではなく、ビューやAPIを安定した読み取り層として定義する。
• マイグレーションウィンドウを計画する：データベース変更は常に後方互換性を保って展開する（例：新しいカラムはまずオプションにする）。

この場合、データベースはインテグレーションのバスではなくインフラストラクチャの一要素として扱うべきである。

3) 非同期プロセスのためのメッセージング／イベント

インポート処理、通知、後処理、インターフェースジョブなどの疎結合なワークフローには、非同期モデルが有効である：あるシステムがイベントを公開し、別のシステムがそれを処理する。これにより直接依存が減り、負荷の尖峰が緩和される。

IT責任者や管理者にとって重要なのは、モニタリング（キュー長）、デッドレターの設計（失敗メッセージの扱い）、再実行挙動、そして業務上の冪等性の明確化である。イベントは正しいマスターデータ運用の代替ではないが、堅牢なプロセスチェーンを構築する有効な手段である。

データ契約と互換性：過小評価されがちな中核

どの統合パターンを採用するにせよ、安定性を決めるのはデータ契約の質である。データ契約とはフィールド、型、必須／任意、意味論を拘束的に定義した記述である。REST-APIでは通常JSONが用いられるが、重要なのは「JSONそのもの」ではなく、変更管理における規律である。

運用を大幅に簡素化する実践的なルール：

• 壊すのではなく拡張する：新しいフィールドを追加し、古いフィールドは当面維持する。
• フィールドの意味論を文書化する：単に「string」とするのではなく、例えば ISO 日付、タイムゾーン、許容状態などを明記する。
• 列挙値は寛容に扱う：クライアントは未知の値に耐える（フォワード互換性）。
• APIバージョニングを意図的に活用する：すべてのリリースで新バージョンを切る必要はない；しかし破壊的変更は明確に分離する。

これらは、DelphiデスクトップクライアントがWebサービスほど頻繁に更新できない場合に特に重要である。

認証と認可：共通のセキュリティモデル

混在するアーキテクチャは「技術」で失敗することは稀で、むしろ不整合なセキュリティが原因で失敗することが多い。企業にとって重要なのは：誰が何を許可されているか？どのように検証するか？どのように監査するか？共通のモデルは二重のユーザー管理や矛盾したロールを回避する。

実務では、中央のアイデンティティ層を設けることになる。例えば SAML 2.0（フェデレーション型のシングルサインオン、エンタープライズ環境で多い）やOpenID Connect（OAuth2ベースで、モダンな Web API でよく使われる）。 C#-Services は通常 Identity Provider に直接接続でき、Delphi-クライアントはトークンを取得して API コール時に送信できる。重要なのは、デスクトップアプリケーションにもデータベースアクセスによる「特別権限」を与えないことだ。

管理者にとって重要な点:

• トークンの有効期間とリフレッシュ戦略（クライアントが安定して稼働しつつ安全性を確保するため）
• サービス間認証（内部通信向け、例: mTLS または署名付きトークン）
• 最小権限: ロールや権限を過度に大まかに設定しない
• 監査ログ: セキュリティ関連の操作を追跡可能に記録すること

運用コンセプト：Windows-およびLinux-Services、IIS と日常のプロセス

企業でアーキテクチャが「良い」と言えるのは運用可能である場合のみ：更新が計画可能で、障害が特定可能、負荷が制御可能であること。混在する環境での一般的な運用形態は次の通り：

• Windows- und Linux-Services: バックグラウンドジョブ、インターフェース処理、ワーカーに適している。従来の Windows サーバ運用モデルに統合しやすい。
• Windows- und Linux-Services/Daemon: コンテナ化や VM ベースの運用モデルに適する。長期稼働で安定しやすく、systemd による自動化が行いやすい。
• Microsoft IIS: Windows 中心の環境における Web アプリケーションやリバースプロキシの実績あるホスティング。

重要なのは、Delphi- und C#-コンポーネントが類似した運用基準を満たすこと：一貫したヘルスエンドポイント（生存確認）、定義済みのタイムアウト、制限されたリソース消費、明確なデプロイおよびロールバック手順。これにより「技術特有の」特別扱いを減らせる。

ロギング、トレーシング、メトリクス：共通の観測性レベル

特に二つの技術スタックが混在する場合は、切れ目のない診断チェーンが決定的に重要だ。典型的な問題例：Delphi-クライアントが「保存時のエラー」を報告し、C#-サービスがタイムアウトし、データベースがロックを報告する — 共通の関連付けがない。

実務上有効な対策は次のとおり：

• 相関IDを各リクエスト（Client → API → DB）に付与し、ログを統合できるようにする。
• 構造化ログ（キー/値形式、単なるテキスト行ではない）にして後でフィルタリングできるようにする。
• メトリクス（レイテンシ、エラー率、キュー長、リソース使用率）を収集する。
• 障害分類：ビジネスエラー（バリデーション）を技術的エラー（タイムアウト、ネットワーク）と分離する。

これらの基礎は、実務において「正しい言語」を巡る議論よりも多くの時間を節約します。

データアクセスとマイグレーション：BDEの置換、FireDACおよびモダンなデータベース

歴史的に、Delphiの資産ではデータアクセスが重要な役割を果たしてきました。Borland Database Engine (BDE) のような古いアクセス経路がまだ使われている場合、追加のプレッシャーが生じます：OSの更新、64ビット移行、ドライバの可用性、セキュリティ要件。BDEの置換は単なる近代化ではなく、リスク低減でもあります。

典型的には、BDEのネイティブ接続を伴う置換（Delphiにおけるモダンなデータアクセス層）と、運用上扱いやすいデータベース（例：PostgreSQL、SQL Server、MariaDB）を組み合わせる移行が多いです。共通の Delphi/C# アーキテクチャには、次の2点が重要です：

• トランザクション境界: どちらがトランザクションを開始/コミットし、並行書き込みをどのように扱うか。
• ロッキングおよび分離戦略: デスクトップワークフローとサービスが互いにブロックしないようにすること。

マイグレーションでは段階的な計画が有効です：まずドライバとアクセス層を近代化し、次にデータモデルを統合し、その後に統合インターフェースを安定化させる。こうすることで障害原因を切り分け可能にし、ロールバックも現実的になります。

リリース管理：異なる更新サイクルを調整する

繰り返し生じる緊張点は更新頻度です：Webサービスはより頻繁にロールアウトできる一方、デスクトップクライアントは（ロールアウト窓口、ユーザーへの周知、パッケージ化の都合で）頻度が低くなることが多い。共通のアーキテクチャはこの非対称性を考慮しなければなりません。

実務上の帰結：

• APIの下位互換性は義務であり、オプションではありません。
• Feature Flags（機能のフラグ）は、新機能をサーバー側で制御して有効化するのに有効です。
• スキーママイグレーションは段階的に行う必要があります：まずデータベースを拡張し、その後サービスを利用し、最後にクライアントを追従させる。
• 明確な非推奨方針：古いエンドポイントやフィールドは所定の期間経過後に削除する。

特に規制の厳しい環境では、これらのルールをアーキテクチャの指針として書面化して固定することが重要です。そうすることで、決定がプロジェクトごとに都度再発明されるのを防げます。

典型的な落とし穴とそれを体系的に回避する方法

運用の観点から、混在する Delphi/C# 環境で最も頻繁に起きる問題は予測可能です。早期に対処すれば、長期的なコストは顕著に低下します。

落とし穴1：重複するビジネスロジック

もし Delphi クライアントと C# サービスが同じルールを別々に実装すると、「幽霊的なエラー」が発生します：UI上では動作するプロセスがAPIインポートで失敗する。対策：ルールをドメイン層（サービス）に集約するか、業務的に明確に割り振り、明確なバリデーション応答を含めることです。

落とし穴2：UIの回避策（ワークアラウンド）に頼る

「ちょっとデータベースのフィールドに書き込むだけ」は個別には無害に見えますが、ログ、認証、バージョン管理のないシャドウ・インターフェースを生み出します。より良いのは、初期はより厳格さが必要でも、定義済みのエンドポイントを一貫して使うことです。

落とし穴3：運用における責任範囲の不明確さ

何のチームがどのサービス、どのログ、どの運用パラメータを担当しているかが明確でないと、障害調査はPing-Pongに終わる。実務的には、サービスマップ（どのサービスが、どの依存関係を持ち、どのポートを使い、内部でどのSLAがあるか）と、頻発する障害向けの統一されたRunbooksが有効である。

落とし穴 4: セキュリティの整合性欠如

SSOを持つポータルがある一方で、デスクトップクライアントがローカルの管理者アカウントを使用していると、多くの監査で問題となる。共通のIdentityおよびロールモデルはリスクとサポート負担を低減する。

判断支援：何をDelphiに残し、何をC#へ移すか?

妥当な分割はイデオロギーではなく、プロセスの近接性と運用要件に依存する。アーキテクチャおよび運用の観点からの指針としては：

• Delphiは頻繁に向いている: bestehende Windows-Desktop-Clients（VCL）、非常に応答性の高いUIワークフロー、オフラインに近いシナリオ、長期的な既存画面の保守。
• C#は頻繁に向いている: zentrale REST-APIs、ERP/DMS/CRMへの統合サービス、Identityに近いコンポーネント、ポータルおよび変更頻度の高いバックエンドプロセス。
• 意図的に決定する: データロジックと検証は、複数のフロントエンド（デスクトップ、ポータル、インポートジョブ）が存在する場合に「クライアント内」に置くべきではない。

重要: 目標は「すべてをC#へ移す」ことではなく、モダナイゼーション段階が計画可能で業務プロセスが安定稼働する耐久性のある全体アーキテクチャを構築することである。

モダナイゼーションパス：アプリケーションからシステムへ段階的に

実務では共通アーキテクチャはしばしば移行段階であり、長期化することが多い。現実的なモダナイゼーションパスは高リスクの大型プロジェクトを避け、測定可能な中間目標を設定する：

1. インターフェースを安定化する: REST-APIを業務的境界として導入する。内部がまだ「きれい」でなくても。
2. データアクセスをモダナイズする: BDE-Ablösung、ドライバー、64ビット対応、明確なトランザクション。
3. Identityを集中化する: すべてのアクセス経路に対するSSOとロールモデル。
4. 運用を統一する: ログ／モニタリング／ヘルス、明確なデプロイ、再現可能な環境。
5. 業務モジュールを疎結合にする: 特に変更頻度の高い部分をサービスへ移行し、UIを段階的にスリム化する。

この順序は教条的ではないが、典型的には依存関係を最小化する。安定したインターフェースと運用コンセプトがなければ、その後の変更はすべてよりコスト高になる。

結論：統合はアーキテクチャの課題であり、言語の問題ではない

DelphiとC#の実用的な組み合わせは、「ブリッジライブラリ」によって生まれるのではなく、明確な業務的境界、明瞭なデータ契約、および監視、セキュリティ、リリース管理を真剣に扱う運用コンセプトによって成立する。C#とDelphiが共通アーキテクチャ内で責任範囲に沿って意図的に連携するとき、企業が得るものは主に一つである：プロセスを壊さないモダナイゼーション。Delphiは安定したデスクトップワークフローを引き続き確実に担い、C#-Servicesは統合、Web-API、ポータルを中央のプラットフォーム機能として提供する。

既存のDelphi環境を段階的にモダナイズする、あるいはC#-Servicesを適切に接続したい場合、インターフェース、データ、運用、セキュリティの観点からのアーキテクチャレビューが、信頼できる判断に至る最短の手段である。詳細は直接の対話で：

業務的な文脈では、Delphi モダナイゼーション と REST-API は、統合、データフロー、継続的な開発が正確に連携する必要がある既存ソフトウェアにとって重要な役割を果たします。

プロジェクトまたはモダナイゼーション案件をNet-Baseと相談する.