「Glue Code」危機：分散ワークフローオーケストレーションはなぜ難しいのか

SchemaBridge Team · 2025-12-01 · Distributed Systems, Architecture, DevOps

API の配管作業にエンジニアリング時間を浪費するのはもうやめましょう。2026 年、分散したシステムを拡張する鍵が分散ワークフローオーケストレーションである理由を解説します。

アーキテクチャのボトルネック：生産性を静かに蝕むもの

シニア開発者やアーキテクトであれば、このサイクルを経験したことがあるはずです。最初は「シンプルな」連携から始まります。たとえば、Shopify の注文をレガシー ERP と同期するといったものです。50 行のスクリプトを書き、Lambda や cron ジョブで包んでリリースします。初日は動きます。10 日目も動きます。しかし、やがて世界は変わります。Shopify API にレート制限が追加されます。レガシー ERP は午前 2 時にデータベースのロック競合を起こします。外部の配送プロバイダーが JSON レスポンスの構造を変更します。

気づけば、その「ちょっとしたスクリプト」はミッションクリティカルなインフラになっています。しかし、それはインフラとして作られたものではありません。スクリプトとして作られたのです。適切なエラーハンドリングはなく、状態という概念を理解しておらず、組み込みのレジリエンスもありません。失敗するときは静かに失敗するか、さらに悪いことに部分的に失敗し、データを壊れた状態のまま残します。その修復には何日もの手作業が必要になります。

3 か月後、あの 50 行のスクリプトは 5,000 行の怪物へと変貌しています。今ではリトライを（無限ループを伴う、お粗末な形で）処理し、3 か所にログを出力し（そのうち 1 か所はディスクが満杯）、本当のエラーを覆い隠すネストした try-except ブロックを抱えています。こうしたスクリプトが 20 本、インフラのあちこちで動いています。これが組織の 「Glue Code」 です。これはエンジニアリングではなく、場当たり的な配管工事です。

これが Glue Code 危機 です。エンジニアリングの速度を静かに奪う元凶です。もはやビジネスを前進させる機能を作っているのではなく、データが漏れ、負荷で詰まり、午前 3 時に破裂して優秀なエンジニアを叩き起こすアラートを鳴らす、脆い「パイプ」を作っては保守しているのです。分断されたマイクロサービスと果てしない SaaS API の世界で、耐久性のあるオーケストレーションの戦略がなければ、それは速乾性のセメントの上に家を建てているようなものです。1 週間は堅牢に見えますが、ひび割れは避けられません。

危機の歴史的ルーツ：CGI-BIN からクラウドへ

なぜこの危機に陥っているのかを理解するには、ソフトウェア統合の歴史を振り返る必要があります。1990 年代には CGI スクリプト と Perl がありました。リクエストをレスポンスに変換する、小さくステートレスなコマンドです。これが元祖「Glue Code」でした。当時としては素晴らしいものでしたが、現代のデジタルビジネスにおける、複数ステップ・複数日にわたるジャーニーを扱うことはまったく想定されていませんでした。常時接続でもグローバルにつながってもいない世界のための「撃ちっぱなし」のツールだったのです。

2000 年代には、Tibco や BizTalk のような巨大で重厚なミドルウェアである ESB（Enterprise Service Bus） に移行しました。強力ではありましたが、非常に複雑で高価でした。あらゆるものを集中管理しようとした結果、「バス・アーキテクト」がボトルネックになりました。変更のたびに委員会の会議が必要でした。バスは、解決するはずだった問題そのもの、すなわち単一障害点であり、組織的な摩擦の巨大な源泉になってしまったのです。

2010 年代には、ESB を捨てて マイクロサービス を選びました。REST API と軽量なスクリプト（Python、Go、Node.js）へ移行しました。自由を手に入れたと思っていました。しかし実際には、複雑さを「バス」から「サービス間の空間」へ移しただけでした。1 つの重いミドルウェアを、環境中に散らばる何千もの小さく脆いスクリプトに置き換えたのです。今やサービス数に対して複雑さが O(N^2) で増える世界にいます。集中型のボトルネックを、分散型の混沌と引き換えにしたのです。

スクリプトの心理学：なぜ脆い道を選び続けるのか

なぜ私たちはスクリプトを書き続けるのでしょうか。分散システムの落とし穴を知っているシニアエンジニアでさえ、「耐久性のあるオーケストレーター」よりも「ちょっとしたスクリプト」に手を伸ばしがちです。その理由は心理的なものです。

1. 「クイックウィン」という誤謬

ビジネス側のステークホルダーが新しい連携を求めるとき、彼らはそれを「昨日」欲しがっています。スクリプトは速く感じられます。1 時間で書けます。生産的な気分になれます。「チェックボックスを埋める」ことができます。しかし、それは偽りの生産性です。将来のキャパシティを担保に高利のローンを組んでいるのです。今日節約した時間は、翌月、本番環境の部分障害のデバッグで何倍にもなって返ってきます。スクリプトは、長期的な安定性よりも短期的な指標を重視するエンジニアリングマネージャーにとって、中毒性のあるドラッグなのです。

2. 分散システムにおけるダニング＝クルーガー効果

多くの開発者は「リトライは簡単だ」と信じています。API 呼び出しを sleep タイマー付きの while ループで包めば十分だと考えています。本当の本番環境で起こる リトライストーム、孤立したアイデンティティ、状態の破損 をまだ経験していないのです。障害に対処する自分の能力について、「過度な期待のピーク」にいるわけです。午前 3 時の最初の大規模障害を経験して初めて、分散状態がインフラレベルの解決策を必要とする問題だと気づくのです。

3. より良い作業単位の欠如

最近まで、オーケストレーションのための標準的な作業単位がありませんでした。「関数」と「サービス」はありましたが、「ジャーニー」はありませんでした。SchemaBridge は、その作業単位として Durable Workflow を導入します。複数ステップのジャーニーを、状態が永続化される単一のエンティティとして表現できるため、ワーカーのクラッシュや再起動が起きても、ジャーニーを失うのではなく実行中のステップが再取得されます。

障害の解剖学：なぜ「スクリプト」はスケールしないのか

10 ユーザーで動くスクリプトが 10,000 ユーザーで失敗するのには、分散システムの本質に根ざした 3 つの主な理由があります。これらの問題は「より良いコード」だけでは解決できません。インフラ で解決する必要があります。

1. 部分的成功の問題：「生焼け」の状態

分散システムにおいて、成功は二値ではありません。スクリプトが 3 つのステップを実行するとしましょう。1) Stripe で顧客に課金する。2) 社内の在庫データベースを更新する。3) SendGrid で確認メールを送る。ステップ 1 の後でプロセスがクラッシュしたらどうなるでしょうか。

顧客には課金されているのに、在庫は「在庫あり」のままで、ユーザーには領収書が届いていません。これを素のコードで解決するには、複雑な Saga パターン を手で書かなければなりません。実質的に、スクリプトごとにミニオーケストレーターを書くことになります。課金が行われたかを確認し、在庫の状態を確認し、ロールバックを処理する必要があります。このボイラープレートが開発時間の大半を占めるようになり、それでも分散状態は難しいため、ときどき間違えます。

2. 冪等性のギャップ：リトライの危険性

接続は不安定です。スクリプトが API のタイムアウトを捕捉してリトライします。しかし、API 自体は実際には成功していて、タイムアウトしたのはレスポンスだけだったとしたら？ 冪等性 がなければ、リトライによって二重課金や二重出荷が発生します。ほとんどの「Glue Code」開発者は、顧客に 500 ドルではなく 5,000 ドルが課金される最初の事故が起きるまで、この問題を無視します。

数十のサービスにまたがるすべての API 呼び出しに冪等性キーを付けるのは、一貫してこなせるチームがほとんどない、物流的な負担です。連携が 100 個あれば、キーを付け忘れる場所が 100 か所あります。オーケストレーションエンジンはこの負担の一部を肩代わりできますが、どの部分なのかは正確に把握しておく必要があります。SchemaBridge は インバウンド のトリガーを（ペイロードのコンテンツハッシュ、またはユーザーが指定するキーによって）重複排除するため、プロバイダーが同じ Webhook を再送しても、同じジャーニーが 2 回開始されることはありません。一方で、アウトバウンド の副作用は at-least-once で実行されます。クラッシュ後にステップが再実行される可能性があるということです。冪等でない宛先に対しては、安定したビジネスフィールド（注文 ID、payment intent など）から導出した冪等性キーを、呼び出しそのものに渡してください。

8 つの誤謬：失敗の土台

Glue Code がなぜ失敗するのかを本当に理解するには、Sun Microsystems の Peter Deutsch らによって最初に提唱された 分散コンピューティングの 8 つの誤謬 に立ち返る必要があります。これらは、ネットワークを扱うコードを書き始めたすべての開発者が抱く誤った前提です。エンジニアリングにおける「偽りの楽園」と言えるでしょう。

1. ネットワークは信頼できる：そうではありません。パケットは失われ、ルーターは再起動し、ケーブルは切断されます。クラウド環境では、規模が大きくなれば断続的なネットワーク障害が毎日起こると考えるべきです。

2. レイテンシはゼロである：そうではありません。最速のグローバル光ファイバー網でさえ、何千回もの呼び出しで積み重なるミリ秒単位の遅延をもたらします。この遅延は揺らぎがあり予測不能で、ローカルでデバッグしようとすると消えてしまう競合状態を引き起こします。

3. 帯域幅は無限である：そうではありません。大きなペイロードはパイプを詰まらせ、タイムアウトを引き起こします。クラウドプロバイダーには厳格な帯域幅クォータもあり、予告なく「Glue Code」をスロットリングします。

4. ネットワークは安全である：そうではありません。中間者攻撃、DNS ポイズニング、漏洩したトークンは常に存在する脅威です。適切に隔離されていない「Glue Code」スクリプトは、認証情報窃取の格好の標的です。

5. トポロジーは変化しない：変化します。ロードバランサーは移り変わり、ノードは停止し、IP アドレスは再利用されます。スクリプト内の「ハードコードされた IP」は時限爆弾です。

6. 管理者は 1 人である：そうではありません。あなたは AWS、Cloudflare、そしてスタック内のあらゆる SaaS プロバイダーに左右されます。彼らが API を変更すれば、最初の犠牲者はあなたのスクリプトです。

7. 転送コストはゼロである：そうではありません。大規模な JSON のシリアライズとデシリアライズには、実際の CPU とメモリのコストがかかります。スクリプトは、json.loads() でペイロードを何度もパースし直すだけで、驚くほど多くの時間を費やすことがあります。

8. ネットワークは均質である：そうではありません。スタックは Linux、Windows、JVM、Node、レガシーな SOAP サービスの混在です。この環境で一定の振る舞いを期待するのは幻想です。

技術的ディープダイブ：イベントソーシングと永続化のスケーラビリティ

耐久性のあるオーケストレーションエンジンを構築するうえで最も難しい部分の 1 つが、状態の永続化 の管理です。大量のワークフローが同時に実行され、それぞれが多数のステップを実行すると、永続化レイヤーへの書き込み負荷は急速に増大します。

データベースのボトルネック

素朴なスキーマ、つまりステップごとに完全な状態で書き換えられる、幅広で可変な workflow_history 行は、いずれこの負荷に耐えられなくなります。ホットな行に対するインデックスとロックの競合が主なボトルネックになるからです。SchemaBridge は PostgreSQL 上でこの問題を 2 つに分割します。変化する小さな現在状態のレコードと、増えるだけの履歴です。

1. 小さく保護されたステータス行：各実行と各ステップの現在状態は、コンパクトなステータス行に保持され、compare-and-set 方式の条件付き書き込みで更新されます（ステップが DISPATCHED から EXECUTING に移るのは、他の誰も先にそれを取得していない場合だけです）。大きなペイロードはこれらの行から完全に切り離され、SeaweedFS（S3 互換）のオブジェクトストアにオフロードされます。また、ステージ間の作業の受け渡しは Valkey Streams が担います。

2. 追記専用の実行トレース：各ステップは不変のトレースレコードも追記するため、実行のステップごとの軌跡が得られます。トレーステーブルは月単位で時間パーティション分割されているため、保持期間を過ぎた古いパーティションは、行ごとに削除するのではなく低コストで破棄されます。

3. 再水和（リハイドレーション）不要のクラッシュリカバリー：現在状態が永続化されているため、ワーカーがそれをメモリ上で再構築する必要はありません。ステップの途中でワーカーが停止すると、そのステップの取得（クレーム）が失効し、別のワーカーが再取得して再実行します。これは at-least-once 実行であり、だからこそ先述のアウトバウンドの冪等性に関するアドバイスが重要なのです。

ガバナンスのギャップ：配管は誰のものか

技術的な課題の先には、文化的な課題があります。ガバナンスのギャップ です。従来のマイクロサービスアーキテクチャでは、オーナーシップがサイロ化されています。「Product Service」チームは商品データベースを所有し、「Shipping Service」チームは FedEx との連携を所有します。

では、その間にある ブリッジ は誰のものでしょうか。

たいていは誰のものでもありません。「Glue Code」スクリプトは、手早い修正を必要とした開発者が書き、その後は放置されます。壊れると、Product チームは Shipping チームを責め、Shipping チームは API プロバイダーを責めます。ビジネスプロセスが実際にどうつながっているのかについて、中央の「信頼できる唯一の情報源（Source of Truth）」が存在しないのです。

SchemaBridge は、連携をグローバルな資産 にすることでこれを解決します。

生物学的メタファー：神経系としてのソフトウェア

私たちは、ソフトウェアが静的なツールの集合ではなく、生きた神経系 となる世界へ向かっています。生物の神経系では、信号は指（センサー）から脳（ロジック）へ伝わり、筋肉（アクション）へと戻ります。経路の一部が塞がれても、システムは適応します。反射があり、記憶があります。

耐久性のあるオーケストレーションは、企業の神経系です。分断されたサービスを、単一のまとまった有機体のように機能させます。

1. 反射：バックオフ付きの自動リトライが、小さな「痛み」（一時的な 5xx、レート制限のレスポンス、HTTP 呼び出し中の接続断）を、脳（開発者）を煩わせることなく吸収します。

2. 記憶：実行状態が永続化されているため、再起動の後でも（クラスター全体の再起動であっても）、実行中のステップは忘れ去られるのではなく、再取得されて再実行されます。この再実行は at-least-once であるため、副作用は依然として宛先側で冪等である必要があります。

3. 認識：ビジュアルなオブザーバビリティ（オブザーバビリティのギャップ を参照）により、各実行をリアルタイムで確認できます。どのステップが実行中か、どれが失敗したか、そして入出力されたペイロードは何かが分かります。

例示シナリオ：静かなる照合のメルトダウン

この危機の深刻さを理解するために、社内の元帳と複数の提携銀行の API との間で、日次取引の照合を大量の Python スクリプトで行っているフィンテック企業を考えてみましょう。

障害

ある金曜日、提携銀行の 1 つが照合 API の認証方式を変更したとします。Python スクリプトはクラッシュしません。単に拒否され、例外を捕捉し、その日の照合を「静かに」「Pending」とマークするだけです。ビジュアルなダッシュボードがないため、障害は何日も気づかれません。

誰かがようやく確認した時点で、元帳と銀行の間には大きく、しかも拡大し続ける差異が蓄積しています。監査人が呼ばれ、経営陣に報告され、エンジニアリングチームは照合のタイムラインを手作業で再構築するために何日も費やすことになります。スクリプトは「ハッピーパス」では完璧に動いていましたが、「自己修復」能力も「目に見える真実」もまったく持っていなかったのです。

SchemaBridge による代替案

では、同じ照合ロジックを SchemaBridge 上で動かしている場合を想像してください。同様の認証変更が起きると、Gateway vertex（銀行へのアウトバウンド HTTP 呼び出し）が失敗し、モニター上で実行が赤く表示され、失敗したステップには拒否されたレスポンスが添付されます。SchemaBridge が自ら誰かに通知することはありませんが、チームはこのケースを確実に目立たせることができます。Gateway の clientErrorMode を complete に設定すれば、拒否された（4xx の）呼び出しは invalid_input という結果になり、それをもとにルーティングして、そのまま Slack 通知のステップへ流すことができます。いずれにせよ、障害は何日も後ではなく、その日のうちに可視化されます。チームは認証情報を修正し、失敗したステップで Retry（再試行）をクリックすれば、照合は手作業で再構築されることなく、停止した地点から再開されます。

エラーのないオーケストレーションのための推奨リソース

耐久性のある実行の技術を極めたい方には、次の厳選された読書リストをおすすめします。

結論：アーキテクトの新たな使命

Glue Code 危機は、移行期の症状です。私たちは「サイロとスクリプト」の世界から 「つながったエコシステム」 の世界へと移りつつあります。この新しい世界では、サービス間のつながりはサービスそのものと同じくらい重要です。

アーキテクトとしてのあなたの使命は、もはや信頼性の高いサービスを作ることだけではありません。信頼性の高いつながり を作ることです。Glue Code は信頼性の対極にあります。一時しのぎのパッチが、必然的に恒久的な負担になるのです。脆いパイプを作るのをやめ、デジタル神経系 を作り始める時です。

SchemaBridge のような耐久性のあるオーケストレーションエンジンを採用することで、エンジニアリングの未来を取り戻せます。自らの状態を把握し、障害に強く、組織全体から見えるシステムを構築できます。それこそが、速度を取り戻し、長く使い続けられるシステムを作る方法です。

この記事は「Building the Bridge」シリーズの一部です。あわせてお読みください：速度のための設計：スキーマレスなイベント取り込みのすすめ — イベント取り込みにおけるレイトバインディングのアプローチ。

詳しく見る