技術的実装（第2部）：事件記録のフル自動作成とインテリジェントな文書ハンドリング

連載の第1部では、Apify、n8n、Actaportを使用したクラウドネイティブ・アーキテクチャを採用した理由を説明しました。大きな反響をいただき、多くの同業者から「具体的にどのような仕組みなのか？」という質問が寄せられています。

この第2部では、データパイプラインの技術的な実装について説明します。単なるマスターデータのインポートにとどまらず、さらに一歩進んだ「事件記録のフル自動作成」を紹介します。これには、すべての関係者の紐付けや、商業登記簿から自動取得した登記書類の正確な保存までが含まれます。

ステップ1：フォーム・トリガーによるデータキャプチャ

自動化の出発点は n8n Form Trigger です。これにより、データ入力と実際の処理ロジックを切り離すことができます。

フォームでは、API経由の取得に必要なパラメータのみを取得します：

• 地方裁判所（Amtsgericht）： ドロップダウンによる標準化された選択。
• 登記番号： 数値入力。
• 担当者： Actaport内での後のタスク割り当て用。
• 記録を作成する： ブール値（チェックボックス）。これがオンの場合、プロセスは連絡先の作成で止まらず、関連する事件記録を作成します。

フォーム送信後、データはHTTPリクエストに渡され、Webhookを介してメインワークフローを開始します。

動画：n8n フォーム・トリガー – 登記情報取得のためのデータ入力。

ステップ2：登記データ（XJustiz）の処理

クローラーはデータを XJustiz標準 のXML形式で返します。Actaport APIで処理するには変換が必要です。なぜなら、法的形態コード 221110 のような生の値は直接解釈できないからです。

処理はn8n内の JavaScript Code-Node で行われ、2つの主要な機能を果たします：

1. パース： XMLツリー構造（例：tns:basisdatenRegister）を反復処理し、資本金、事業目的、住所データを抽出します。
2. マッピング： XJustizコードを内部のマッピングテーブルと照合します。例えば、コード 111000 は、Actaportのデータモデルの要件を満たすために文字列 "OHG" に変換されます。

図：生のXMLからn8nコードノード（マッピング）を経て、整理されたJSONペイロードへ。

ステップ3：連絡先の作成と重複回避

すべての記録の土台となるのは、正確な連絡先データです。冗長性を避けるため、ワークフローは作成前に必ずその個人または法人が既に存在するかを確認します。

プロセスは以下のスキーマに従います：

• APIクエリ (GET)： Actaportの既存データから検索（名前と場所でフィルタリング）。
• 条件付きロジック (IF-Node)：
  • ケースA（データ発見）： 既存の連絡先IDを抽出します。
  • ケースB（一致なし）： POSTリクエストを介して新しい連絡先を作成し、新しく生成されたIDを返します。
• データの正規化： どのパスを通っても、有効な kontakt_id が統一された変数に保存されます。

Actaportで作成または更新された連絡先。

ステップ4：事件記録の自動作成

ここにこの拡張機能の本当の価値があります。「記録を作成する」チェックボックスが有効な場合、ワークフローは先ほど取得した kontakt_id を使用して、新しい事件記録を作成します。

ワークフローはActaport API (POST /v1/akten) を介して以下の操作を実行します：

1. 紐付け： 会社（IDで識別）を「クライアント」として新しい記録に関連付けます。
2. メタデータ： 記録には自動的に名称（例：「HR-Import: [社名]」）、タグ、およびフォームで選択された担当者が割り当てられます。
3. 戻り値： APIは新しい記録番号（例：「123/24」）を返します。これは次のステップで不可欠です。

ステップ5：ドキュメントの取得と記録への保存

空の記録ではあまり役に立ちません。そのため、ワークフローは最終ステップで関連する登記書類（登記簿謄本、株主名簿、定款）をダウンロードし、新しく作成された記録のドキュメントエリアに直接保存します。

その際、n8nはドイツの商業登記における技術的な問題、つまりファイル形式の不一致を解決します。

• MIMEタイプチェック： IFノードが、ファイルがPDFかZIPかを分析します。
• 解凍 (Unzip)： ZIPアーカイブは自動的に解凍され、含まれているPDFが抽出されます。
• アップロード： エンドポイント POST /v1/akten/{aktennummer}/dokumente を介して、整理されたPDFを記録内の「商業登記（Handelsregister）」サブフォルダに直接アップロードします。

結果

プロセスの最後には、完全に作成され、すぐに業務を開始できる状態の記録が残ります。

完成した記録：クライアントが紐付けられ、担当者が割り当てられ、すべての書類がフォルダに保存されています。

最後に、担当者には記録へのリンクとステータスレポートを含む確認メールが送信されます。これは、現代のAPIアーキテクチャが単にデータを移動させるだけでなく、複雑な法的ワークフローを完全に自動化できることを示しています。

確認メール：記録作成を含むインポートが成功しました。

結論：管理者から設計者へ

私たちの「エンジンルーム」へのこのディープダイブは、今日のリーガルテックが単なる紙の記録のデジタル化をはるかに超えるものであることを示しています。API（Apify & Actaport）とプロセスロジック（n8n）をインテリジェントに組み合わせることで、会社法業務における時間のかかる事務作業である「受任記録の作成」をほぼ完全に排除しました。

その恩恵は、節約された時間（数時間から数分へ）だけでなく、何よりも品質にあります。社名や個人名、住所、代表取締役の割り当てにおけるタイポ（入力ミス）がなくなり、書類の漏れもなく、すべての案件で統一されたデータ構造が保証されます。事務スタッフや弁護士は、「データの転記係」から、本来情熱を注ぐべき業務、すなわち「法的アドバイス」に集中できるプロセス設計者へと進化します。