Go言語の並行処理を業務システムで活かす方法

業務システムで「並行処理」が効く理由（難しい話は抜きで）

業務システムの遅さは、CPUの性能よりも「待ち時間」で決まることが多いです。たとえば、画面から検索をかけたときに、裏側では在庫DB、顧客DB、外部の配送API、ファイルサーバーなど複数の参照先に問い合わせます。このとき、1つずつ順番に待っていると、体感速度はどうしても遅くなります。

並行処理とは、「同時にいくつかの待ち時間を重ねて、全体の所要時間を短くする」考え方です。料理で言えば、煮込みを待っている間にサラダを作るようなものです。システムは「計算」より「待つ」ことが多いので、並行処理の効果が出やすい領域です。

ここで活躍するのがGo（Go言語）です。Goは並行処理を前提に設計されており、goroutine（軽量スレッド）とchannel（安全な受け渡し）で、複数作業を扱いやすくします。結果として、次のような業務課題に直結します。

• 検索・集計・ダッシュボード表示が遅い（API/DBの待ちが多い）
• バッチ処理が夜間に終わらず、朝の業務に影響する
• 外部サービス連携（決済、配送、SaaS）の待ち時間で画面が固まる
• 同時アクセスが増えると急に遅くなる（スケールの壁が早い）

一方で、並行処理は「速くなる魔法」ではなく、設計を誤ると不具合が増えます。この記事では、非エンジニアの方でも判断しやすいように、Goの並行処理を業務システムに落とし込む方法を、導入手順・設計の勘所・失敗回避まで含めて整理します。

Goの並行処理で何が変わる？業務での典型パターン

並行処理が効くかどうかは、業務処理の中身が「CPUで重い計算」か「待ち時間が多いI/O（DB、API、ファイル）」かで大きく変わります。業務システムは後者が中心です。Goの並行処理は、まさにこの「待ち」を短縮するのに向いています。

まず狙い目なのは「1リクエスト内に複数の外部参照がある」処理です。たとえば、受注一覧画面で「顧客名」「与信」「出荷状況」「請求状況」をまとめて表示するケース。順番に問い合わせると、待ちが足し算になりますが、並行に投げて最後にまとめれば、待ちは最大値に近づきます（もちろん相手側の制限は考慮が必要です）。

次に多いのが「大量データの分割処理」です。月次締めの集計や、データ移行・クレンジング、PDF一括生成、メール送信など、同じ作業を多数回繰り返す業務は多いです。Goではワーカー（作業員）を複数立て、キュー（仕事の箱）から順次処理させる設計がしやすく、処理時間を短縮しつつ、システム負荷を一定に保つことができます。

• 画面表示の高速化：複数API/DB参照を並行化して待ち時間を圧縮
• バッチの短縮：同種作業をワーカーで分散し、夜間枠に収める
• イベント処理：注文確定→在庫引当→請求→通知などを非同期化し体感を改善
• 同時アクセス耐性：1台でも多重処理に強く、スケール設計が素直

ただし、何でも並行にすれば良いわけではありません。外部APIにはレート制限があり、DBにも同時接続数の上限があります。並行処理は「同時に投げる量」をコントロールして初めて安全に効きます。この点でGoは、channelを使って「同時実行数を制限する」設計が自然に書けるため、業務システムの現実（制限が多い）と相性が良いです。

業務システムでの設計ポイント：速さより「安定」と「説明できること」

情シスや管理部門の方にとって重要なのは、速くなることだけでなく、運用時に困らないことです。並行処理は、設計が雑だと「たまに失敗する」「再現しにくい不具合」が起きがちです。そこで、業務システムでの並行処理は、次の原則で設計するのが現実的です。

原則は「ユーザーに見える処理は確実に」「裏側は再実行できる形で」です。たとえば、受注登録ボタンを押した瞬間に、在庫引当やメール送信まで全部終える設計は、遅くなりやすく失敗点も増えます。受注登録（事実の記録）だけは同期で確実に完了させ、通知や帳票生成などはキューに積んで非同期で処理し、失敗しても再実行できるようにします。

また、並行処理は「競合」を避けることが大切です。たとえば同じ在庫を同時に引当しようとして二重に引かれる、同じ請求書を二重発行する、といった事故です。これを防ぐ考え方として、次の2つを押さえると判断しやすくなります。

• 排他が必要なデータはDB側で守る：ユニーク制約、トランザクション、行ロックなど
• アプリ側は「同時実行数」を制御する：ワーカー数、キュー、タイムアウト

さらに運用面では「見える化」が欠かせません。並行処理は裏で複数の作業が動くため、ログが散らばると原因追跡が困難になります。Goで実装する場合でも、技術の話に閉じず、業務上のSLA（何分で終わるべきか）に紐づけて、監視とアラートを設計することが重要です。

最低限そろえるべき運用要件は「タイムアウト」「リトライ」「冪等性（同じ処理を複数回しても結果が壊れない）」です。たとえば外部APIが一時的に遅いだけで全体が詰まるのを防ぐために、一定時間で諦める（タイムアウト）、後でやり直す（リトライ）、やり直しても二重請求にならない（冪等性）をセットで考えます。これがあると、並行処理の恩恵を受けながら、業務事故を避けやすくなります。

導入の進め方：いきなり全改修せず「効果が出る部分」から

既存の業務システムにGoの並行処理を取り入れるとき、最初から基幹全体を置き換えるのは現実的ではありません。おすすめは、影響範囲が限定され、効果が数値で見えやすいところから始めることです。非エンジニアの方でもプロジェクト化しやすいように、進め方を段階で整理します。

最初のステップは「遅い処理の棚卸し」と「待ち時間の分解」です。画面やバッチで遅いと言われる処理について、「どのDBクエリが遅いのか」「外部APIを何回呼んでいるのか」「ファイルI/Oがあるか」を切り分けます。ここで重要なのは、体感の遅さを“勘”ではなく、計測で捉えることです。計測ができると、改善効果も説明しやすくなります。

次に、並行化の対象を選びます。目安は次の通りです。

• 1リクエスト内で外部参照が複数あり、互いに依存しない
• 同じ種類の処理を大量に繰り返している（送信、生成、変換など）
• 失敗しても再実行可能で、業務影響を局所化できる

実装の形としては、Goを「新規マイクロサービス」として切り出すのが取り組みやすいです。たとえば「帳票生成サービス」「データ連携サービス」「通知サービス」など、機能単位で分けて、既存システムはAPIで呼び出すだけにします。これなら、既存の言語やフレームワークを大きく変えずに、Goの強み（並行処理と高いスループット）を活かせます。

プロジェクト管理としては、PoC（小さな実証）→段階リリースが安全です。PoCで見るべき指標は、単なる処理時間だけではありません。

• 処理時間：平均だけでなく最大（ピーク時）も見る
• 失敗率：タイムアウトや外部APIエラー時の挙動
• 運用負荷：ログ追跡のしやすさ、アラートの妥当性
• コスト：サーバー台数やDB負荷の増減

並行処理は、速くするほど相手（DBや外部API）に負荷をかけます。したがって「速い」だけではなく、「許容負荷の範囲で速い」状態を作ることが業務システムでは重要です。ここまで設計しておくと、情シスとしても説明責任を果たしやすく、社内合意を取りやすくなります。

実務イメージが湧く活用例：ダッシュボード、バッチ、外部連携

ここでは、Goの並行処理が業務でどう効くかを、システムの“よくある場面”で具体化します。コードの詳細よりも、設計と効果のイメージを重視します。

ダッシュボードの表示を速くする（複数参照の並行化）

経営ダッシュボードや現場KPI画面は、複数の指標を同時に出します。「今日の売上」「未出荷件数」「遅延」「在庫アラート」など、データ源が分かれていることが多いです。順番に集計すると、最も遅い集計が全体を引っ張り、画面が重くなります。

このケースは、指標ごとに並行に集計し、最後に合流する設計が効果的です。ただし、DBを同時に叩きすぎると逆効果なので、同時実行数の上限を決めます。Goではワーカー数を固定し、キューに投入して処理する形が取りやすいです。

夜間バッチを短縮する（ワーカー＋キュー）

月末月初の締め処理やデータ連携は、件数が増えるほど時間が伸びます。「朝までに終わらない」「失敗したらやり直しでさらに遅れる」という悩みが典型です。

バッチは「1件ずつ順番」をやめ、一定数のワーカーで分散し、失敗は再投入できる形にすると運用が安定します。ポイントは、全部を一気に並行化しないことです。DB更新が絡むなら、同時更新数を抑え、処理単位を小さくします。また、途中で止まっても再開できるように、進捗やステータスをDBに持つ設計にしておくと、運用が楽になります。

外部SaaS連携を安定させる（タイムアウト＋リトライ＋遮断）

会計、請求、配送、電子契約など外部サービス連携は増えていますが、外部は自社でコントロールできません。遅延や障害が起きたとき、社内業務が止まるのが一番の問題です。

外部連携は「すぐ返す」「後で確実にやる」を分けるのが基本です。たとえば画面操作は「受付完了」までを短くし、実処理は非同期ジョブにします。Goの並行処理はジョブ実行に向いていますが、同時に重要なのは「やりすぎない制御」です。外部APIのレート制限に合わせ、同時実行数を制限し、一定以上の失敗が続くなら一時停止（サーキットブレーカー的な考え方）して、回復後に再開します。

このように、Goの並行処理は「速くする」だけでなく、「止まりにくくする」「業務を継続させる」ための設計とセットで活きます。結果として、現場の問い合わせや情シスの火消しが減り、運用コストの削減につながります。

失敗しがちな落とし穴と、発注側が確認すべきチェックリスト

並行処理の導入で多い失敗は、「速くすること」だけに目が向き、運用や障害時対応が後回しになることです。非エンジニアの発注側でも確認できるように、落とし穴とチェック観点をまとめます。

落とし穴は「同時実行数が無制限」「待ちの連鎖」「二重実行」です。たとえば、画面アクセスが増えた瞬間にgoroutineが大量発生し、DBコネクションが枯渇して全体が遅くなる。あるいは、タイムアウト後にリトライして、実は相手側では成功しており二重登録になる。こうした事故は、技術力の問題というより、要件の決め方で防げます。

• 同時実行数の上限：「最大何件を同時に処理するか」が設計に入っているか
• タイムアウト：外部API、DB、内部処理それぞれに上限時間があるか
• リトライ方針：回数、間隔、失敗理由による打ち切り条件があるか
• 冪等性：再実行で二重請求・二重登録が起きない仕組み（キー、状態管理）があるか
• 監視とアラート：遅延・失敗が“業務影響になる前”に検知できるか
• ログの追跡：処理IDなどで一連の流れを追えるか（問い合わせ対応が可能か）

また、Goを採用する場合の体制面も重要です。Go自体はシンプルで学びやすい一方、並行処理は設計思想が必要です。ベンダー選定時には「Goでの開発経験」だけでなく、「運用設計（監視、障害対応、再処理）まで含めた実績」を確認すると失敗が減ります。

費用対効果の説明も、発注側にとって大切です。単に「処理が何秒短縮」ではなく、業務時間の短縮、夜間バッチの安定、問い合わせ削減、障害時の復旧時間短縮など、業務指標に落とし込めるかがポイントです。Goの並行処理は、適用範囲を見極めて設計すれば、システムの体感と運用を同時に改善しやすい選択肢です。

まとめ

業務システムが遅くなる原因は、CPUの性能不足よりも、DB・外部API・ファイルなどの「待ち時間」が積み上がることにあります。Goの並行処理は、この待ち時間を重ねて全体時間を短縮しやすく、画面表示・バッチ・外部連携で効果が出やすいのが強みです。

一方で、並行処理はやり方を誤ると、たまに起きる不具合や二重実行など、運用上の事故につながります。成功の鍵は、同時実行数の上限、タイムアウト、リトライ、冪等性、監視とログ追跡をセットで設計することです。特に既存システムでは、全置換ではなく、帳票生成・通知・データ連携など「切り出しやすく効果が見えやすい領域」から段階的に導入すると、投資判断もしやすくなります。

もし「どこを並行化すべきか分からない」「外部連携が増えて不安定」「バッチが終わらない」といった課題がある場合は、現状の計測とボトルネック分解から始めるのが近道です。要件定義の段階で運用まで見据えることで、Goの並行処理は“速いだけ”ではなく“止まりにくい業務基盤”として活きてきます。