業務プロセスの全体最適を目指す際、個別のワークフローは自動化できても、部門間やシステム間の連携がボトルネックとなるケースを私は何度も目にしてきました。特に、法人営業から契約管理、バックオフィス業務まで複数プロセスが絡む場合、データの受け渡しミスやタイミングのずれが発生しやすく、「個々の業務は速くなったが、全体では遅延が解消されない」という状況に陥りがちです。本記事では、Claude Code を活用した複数業務プロセスの統合設計において、部門間データ連携・非同期処理・エラーハンドリング・トランザクション管理の観点から、実務で適用可能な設計パターンを提示します。
本記事の結論: ワークフロー統合の成否は、データスキーマの標準化・イベント駆動型の非同期連携・段階的なロールバック設計の3つを初期から組み込むかで決まる
ワークフロー統合設計における4つの技術課題
複数業務プロセスを連携させる際、Claude Code の「部門横断ワークフロー」や「動的ワークフロー」との違いは、システムアーキテクチャレベルでの統合設計に焦点を当てる点です。具体的には以下の4つの課題に対処する必要があります。
1. 部門間データ連携の標準化 — 営業 CRM・契約管理・会計システムなど異なるデータモデルを持つシステム間で、データ構造のミスマッチが発生しやすい
2. 非同期処理の設計 — プロセスの実行タイミングがずれる場合（承認待ち・外部 API の応答遅延など）、後続処理をどう開始するか
3. エラーハンドリングの範囲 — 途中でエラーが発生した際、どこまで処理を戻すか、どの状態を保持するかの判断基準
4. トランザクション管理の境界 — 複数システムにまたがる更新処理で、一部が成功・一部が失敗した場合の整合性担保
これらを曖昧なまま統合を進めると、「一見動いているが、データ不整合が後から発覚する」「エラー時の復旧手順が不明確で運用が回らない」といった事態を招きます。
部門間データ連携の標準化パターン
複数システムから Claude Code へデータを送る際、各システムが独自の項目名・日付形式・必須/任意の定義を持っていると、統合ロジックが複雑化します。私が推奨するのは、共通データスキーマ（Canonical Data Model） を最初に定義し、各システムからのデータを一旦この形式に変換する方式です。
実装例：受注～請求ワークフローの統合スキーマ
ある企業では、営業部門の案件管理システム（Salesforce）、契約部門の契約管理ツール、経理部門の請求システムが別々に稼働していました。各システムの顧客 ID・案件番号・金額フィールドの定義が異なるため、Claude Code で統合する際、以下の共通スキーマを定義しました。
| フィールド | 型 | 説明 | 必須 |
|---|---|---|---|
unified_customer_id | string | 全システム共通の顧客識別子 | Yes |
deal_id | string | 案件番号（営業システムの案件 ID を正規化） | Yes |
contract_id | string | 契約番号（契約システムの契約 ID） | No |
total_amount | decimal | 合計金額（税込・通貨コード付き） | Yes |
currency_code | string | ISO 4217 通貨コード | Yes |
contract_start_date | ISO 8601 | 契約開始日 | Yes |
billing_cycle | enum | 請求サイクル（monthly / quarterly / annual） | Yes |
この共通スキーマを Claude Code が受け取る前段で、各システムから送られるデータを変換するAdapter レイヤーを設けました。Adapter は、たとえば Salesforce の Account.Id を unified_customer_id にマッピングし、日付形式を統一します。この設計により、Claude Code のワークフロー本体は「共通スキーマのデータが来る」前提でロジックを組めるため、メンテナンス性が向上しました。
API 連携の詳細 については「Claude Code API 連携パターン」で、外部システムとのデータ受け渡し設計を解説しています。
非同期処理とイベント駆動型の設計パターン
ワークフロー統合では、「前の処理が完了したら次を開始」という同期的な流れだけでなく、承認待ちや外部 API の応答遅延など、実行タイミングが不定な状況が頻発します。この場合、イベント駆動型（Event-Driven） の設計が有効です。
実装例：契約承認～請求書発行の非同期連携
ある製造業では、契約書の内容確認に法務部門の承認が必要であり、承認完了までに数時間～数日かかる状況でした。以下のフローを設計しました。
1. 契約書作成完了イベントの発行 — 営業が契約内容を入力完了したタイミングで、Claude Code が契約書 PDF を生成し、contract_created イベントを発行
2. 法務承認待ちキューへの登録 — イベントを受けて、法務部門の承認ダッシュボードにタスクが追加される。この時点で後続の請求処理は待機状態
3. 承認完了イベントの発行 — 法務担当者が承認ボタンを押すと、contract_approved イベントが発行される
4. 請求書発行ワークフローの起動 — contract_approved イベントを Claude Code が受け取り、請求データを経理システムへ送信
このイベント駆動方式では、各プロセスが疎結合となり、承認の遅延が全体のワークフローを停止させる問題を回避できます。イベントの発行・購読には、AWS EventBridge や Google Cloud Pub/Sub などのメッセージングサービスを利用するケースが多く見られます。
非同期処理の状態管理
非同期処理では「現在どのステップまで進んでいるか」の状態管理が重要です。私が推奨するのは、ワークフロー実行テーブルに以下の項目を記録する方式です。
| 項目 | 説明 |
|---|---|
workflow_instance_id | ワークフロー実行の一意識別子 |
current_step | 現在のステップ名（例: awaiting_approval） |
status | 状態（in_progress / completed / failed） |
started_at | 開始日時 |
updated_at | 最終更新日時 |
error_message | エラー発生時のメッセージ |
この状態テーブルを Claude Code が参照することで、「承認待ちのまま24時間経過した案件」をリストアップしてリマインドを送る、といった運用が可能になります。
エラーハンドリングと段階的ロールバック
複数システムにまたがるワークフローでは、途中でエラーが発生した際の復旧範囲を明確にする必要があります。すべての処理を最初からやり直すのか、一部のステップのみ再試行するのか、設計段階で決めておくべきです。
実装例：受注～在庫引当～出荷指示のエラー処理
ある EC 事業者では、以下のフローでエラー処理を設計しました。
- 受注登録 → 成功
- 在庫引当 → 在庫不足でエラー
- 出荷指示 → 未実行
このとき、「受注登録」まで戻すのは望ましくありません（顧客データはすでに保存されているべき）。そこで、以下の段階的ロールバックを実装しました。
1. 受注登録は確定 — 顧客データ・注文データは保持し、order_status を pending_inventory に設定
2. 在庫引当の再試行 — 在庫が補充されるまで定期的にリトライ。リトライ回数を記録し、3回失敗したら order_status を manual_review に変更
3. 手動介入の通知 — 在庫担当者へアラートを送り、代替品の提案や入荷見込みの確認を促す
このように、エラーの種類（一時的な通信エラー / 恒久的なデータ不整合）に応じて、全ロールバック・部分再試行・手動介入待ちの3つの処理を使い分けることが重要です。
エラー処理の設計を後回しにしない: 統合初期は「正常系」のフローだけ実装しがちだが、本番運用では想定外のエラーが必ず発生する。事前にエラーシナリオを列挙し、各ステップの「戻せる範囲」を定義しておくこと。
トランザクション管理の境界設計
複数システムにまたがる更新処理では、分散トランザクションの管理が課題となります。例えば、「CRM に商談データを登録」→「契約管理システムに契約データを登録」→「請求システムに請求データを登録」という3つの更新を行う場合、途中で失敗したときに全体の整合性をどう保つかが問題です。
Saga パターンの適用
私が推奨するのは、Saga パターンです。これは、各ステップを独立したトランザクションとして実行し、失敗時には「補償トランザクション（Compensating Transaction）」で元に戻す方式です。
実装例：3システム連携の Saga フロー
| ステップ | 処理 | 補償処理（失敗時） |
|---|---|---|
| 1. CRM 登録 | 商談データを Salesforce に POST | Salesforce の商談を削除 |
| 2. 契約登録 | 契約データを契約管理 API に POST | 契約データを削除 |
| 3. 請求登録 | 請求データを経理システムに POST | 請求データを削除 |
ステップ2で失敗した場合、Claude Code は以下の手順で補償を実行します。
1. ステップ1の補償 — Salesforce API で商談データを削除（または status を cancelled に変更）
2. エラーログの記録 — ステップ2のエラー内容を管理画面に表示し、担当者が手動で対処できるようにする
3. リトライ判定 — エラーが一時的なもの（タイムアウト等）なら、全体を再試行。データ不整合なら手動介入へ移行
Saga パターンの実装には、各ステップの実行状態を記録するSaga 実行テーブルが必要です。以下の項目を管理します。
| 項目 | 説明 |
|---|---|
saga_id | Saga 実行の一意識別子 |
step_name | 現在のステップ名 |
step_status | pending / completed / failed / compensated |
compensation_required | 補償が必要かどうか（boolean） |
retry_count | リトライ回数 |
この設計により、「ステップ2で失敗 → ステップ1を補償 → 全体を再試行」という流れを自動化できます。
結果整合性（Eventual Consistency）の許容
分散システムでは、すべてのデータが即座に一致する強整合性を保つことは困難です。代わりに、結果整合性（一定時間後には一致する）を許容する設計が現実的です。例えば、「CRM の商談ステータスは即座に更新されるが、請求システムへの反映は数分遅れる」といった状況を運用上許容できるかを、事前に関係部門と合意しておく必要があります。
部門間の合意形成: 結果整合性を許容する設計では、「請求データの反映が5分遅れても業務に支障がないか」を各部門に確認し、SLA（Service Level Agreement）として明文化しておくことが重要です。
実装時の技術選定とアーキテクチャパターン
ワークフロー統合の実装には、以下の技術要素を組み合わせることが一般的です。
技術レイヤーの構成
| レイヤー | 役割 | 技術例 |
|---|---|---|
| API Gateway | 外部システムからのリクエスト受付・認証 | AWS API Gateway / Google Cloud Endpoints |
| Workflow Engine | Claude Code の実行制御・状態管理 | Step Functions / Cloud Workflows |
| Message Broker | イベントの発行・購読 | EventBridge / Pub/Sub / RabbitMQ |
| Data Store | ワークフロー状態・履歴の保存 | DynamoDB / Firestore / PostgreSQL |
統合アーキテクチャの3パターン
- ハブ&スポーク型: Claude Code を中央ハブとし、各システムがスポークとして接続。設計がシンプルだが、ハブが単一障害点になりうる
- イベント駆動型: 各システムがイベントを発行し、Claude Code が購読。疎結合で拡張性が高いが、イベントの順序保証が課題
- API 連携型: 各システムが REST API を提供し、Claude Code が同期的に呼び出す。即座に結果が得られるが、タイムアウト対策が必要
実務では、イベント駆動型とAPI 連携型を併用するハイブリッド構成が多く見られます。即座に結果が必要な処理（在庫確認など）は API 連携、非同期でよい処理（承認待ちなど）はイベント駆動とする設計です。
モニタリングと運用設計
ワークフロー統合後の運用では、以下の項目を継続的に監視する必要があります。
1. ワークフロー実行時間 — 各ステップの所要時間を計測し、ボトルネックを特定。目標処理時間を超えた場合のアラート設定
2. エラー率 — ステップごとのエラー発生率を集計。特定のステップで頻発する場合、データ連携仕様の見直しを検討
3. データ整合性チェック — 定期的に各システムのデータを突合し、不整合が発生していないか確認。不整合検出時の自動修正または手動介入の手順を整備
4. SLA 遵守状況 — 結果整合性の許容時間内にデータ反映が完了しているかを追跡。遅延が発生した場合の影響範囲を事前に把握
これらの監視には、AWS CloudWatch や Google Cloud Monitoring などのクラウド標準の監視ツールを活用し、ダッシュボードで可視化することが有効です。
まとめ
複数業務プロセスの統合設計では、以下の4つの技術課題に対処することが成否を分けます。
特に、データスキーマの標準化を初期に行わないと、後からの修正コストが大きくなります。また、エラー処理の設計を後回しにすると、本番運用で想定外のトラブルが頻発し、現場の信頼を失うリスクがあります。私の経験では、統合設計の8割は「正常系」ではなく「異常系」の設計に時間を割くべきです。
DigiRise の Claude Code 統合設計支援
株式会社デジライズでは、Claude Code を活用したワークフロー統合設計を、研修とコンサルティングの両面から支援しています。
- 研修プログラム: Saga パターン・イベント駆動設計・エラーハンドリングの実装演習を含む3日間の技術研修
- 統合設計コンサルティング: 既存システムとの連携仕様策定・共通スキーマ設計・Saga 実行テーブルの設計支援・モニタリング基盤の構築支援
まずは無料相談で、貴社の業務プロセスと既存システムの構成をお聞かせください。統合設計の初期フェーズでの課題整理から、段階的な導入計画の策定までサポートいたします。