1 並行稼働の概要
1.1 定義と目的
1.1.1 待ち時間削減とスループット向上
並行稼働は、複数の処理を同時に進めることで、処理の完了までの待ち時間を縮め、単位時間あたりの処理量（スループット）を高めることを狙う概念である。たとえば、計算機が外部I/Oの完了待ちをしている間に別タスクを前進させれば、アイドル時間が減る。その結果、全体の応答性や処理能力が改善しやすい。
1.1.2 リソース活用（CPU、I/O、ネットワーク）
目的は単に「同時に走らせる」ことではなく、各種資源の空き時間を埋める点にある。CPUバウンドな計算が中心の領域では並行度の上げすぎが効率低下につながる一方、I/Oやネットワーク待ちが大きい領域では待機中のCPUを別作業へ回せる。こうした資源の偏りを見極めることで、投入した計算機資源に対する成果を最大化する。
1.2 関連概念との違い
1.2.1 並列処理との関係
並行稼働と並列処理はしばしば混同される。並行稼働は「進行の重なり」を重視し、必ずしも同一時点で物理的に同じだけ実行されるとは限らない。対して並列処理は複数の処理が同時に実行されること（多くの場合、複数コアや複数装置での同時実行）を強く意識する。実装としては、並行機構の上に並列実行が実現される場合もあり、目的に応じて概念を使い分ける必要がある。
1.2.2 タスク分割とスケジューリング
並行稼働の成否は、タスクをどう分解し、どの順序で割り当てるかに左右される。分割が粗すぎれば待ち時間の圧縮が不足し、細かすぎれば管理コストが増える。スケジューリングは、優先度や資源制約、依存関係を考慮してタスクを前進させる仕組みであり、設計の中心になる。
2 実装方式
2.1 1プロセス内での並行
2.1.1 スレッドによる並行
2.1.1.1 スレッド生成とライフサイクル管理
スレッドによる並行では、同一プロセス内に複数の実行経路を持たせ、各経路が別タスクを処理する。生成コスト、スケジューリングの公平性、停止手順（終了の合図、リソース解放）の設計が重要である。短命スレッドを大量に作るとオーバーヘッドが支配的になりやすいため、再利用（プール）や終了条件の明確化が実務で用いられる。
2.1.2 非同期処理（イベントループ）
2.1.2.1 タイムアウトとリトライ設計
イベントループ方式では、待機をブロックせずにI/O完了などの通知を受けて処理を進める。タイムアウトは無限待ちを防ぎ、リトライは一時的失敗に対処するために使われるが、設計を誤ると輻輳や冪等性違反による二重実行を招く。待ち時間、上限回数、指数バックオフ、失敗理由の分類などを含めて、再試行が安全かつ制御可能になる形に整えることが求められる。
2.1.3 コルーチンによる並行
コルーチンは、明示的な中断と再開により並行性を表現する実行単位である。スレッドのようにOSが直接管理する単位ではなく、言語ランタイムやフレームワークの協調によって切り替えが行われることが多い。軽量性が利点になりやすい一方、ブロッキング呼び出しを混在させると利点が失われるため、実装側の規約（同期I/Oの回避など）を整備することが重要である。
2.2 複数プロセス・複数ノードでの並行
2.2.1 プロセス並行
プロセス並行では、独立したアドレス空間を持つ実行体にタスクを割り当てる。共有メモリの扱いが難しくなる代わりに、影響範囲の分離やクラッシュ耐性を得やすい。通信はIPCやファイル、ネットワークを通じて行うことが多く、シリアライズやメッセージングのコストを考慮する必要がある。並行度の調整や再起動戦略も運用設計の一部になる。
2.2.2 分散並行
2.2.2.1 キューとワーカー配置
分散並行では、複数ノードに処理を配り、キューにより作業の割当を行う構成がよく用いられる。キューは要求やジョブの受け口として機能し、ワーカーがそこから取り出して実行する。重要なのは、配信方式（プッシュ/プル）、再配送時の重複許容、ワーカーのスケール制御、キューの容量制限といった運用面の整合である。配置戦略は、ネットワーク遅延、データ局所性、計算資源の偏りを踏まえて決める。
3 同期・整合性の考え方
3.1 排他とクリティカルセクション
3.1.1 ミューテックスとロック
クリティカルセクションとは、同時実行によって整合性が壊れ得る処理区間を指す。ミューテックスやロックは、その区間への同時アクセスを制限して破壊的な競合を防ぐ仕組みである。設計では、ロックの保持時間を短くする、獲得順序を統一する、例外やキャンセル時にも確実に解放される実装形を選ぶことが重要になる。
3.1.2 セマフォによる制御
セマフォは、同時に許可される実行数を制御するのに用いられる。排他（1件のみ）では足りない場合、たとえば限られた数の接続枠や同時実行枠を守りたいときに適する。獲得と解放の対応が崩れると容量超過や枯渇が起きるため、許可数、待機の扱い、タイムアウトの方針を明確にする必要がある。
3.2 共有データの扱い
3.2.1 不変データとコピー戦略
共有領域をめぐる不整合は、設計の段階から減らせる。たとえば不変（イミュータブル）なデータを作り、更新は新しい版として差し替えると、同時アクセス時の競合を減らせる。コピー戦略は、サイズや頻度に応じてコストが変わるため、どこまで共有し、どこから複製するかを判断する必要がある。
3.2.2 原子操作とメモリ可視性
原子操作は、中間状態が観測されないことを前提に更新できる操作である。さらにメモリ可視性は、ある処理が行った更新が別の処理からいつ観測可能になるかに関する概念で、言語やCPUのメモリモデルに依存する。適切なメモリ順序（または同等の同期手段）を選ばないと、整合性が成立しないことがあるため、仕様と実装の対応を理解することが不可欠である。
3.3 デッドロックと競合の回避
3.3.1 ロック順序設計
デッドロックは、複数のロックを取得する順序が循環し、互いに進めなくなる状態である。回避の基本は、取得順序を設計で固定し、全経路で同じ規則に従わせることである。補助として、ロック粒度の見直しや、必要なデータを先に読み取ることで保持時間を短縮すると、衝突確率も下げられる。
3.3.2 タイムアウト付きロック
タイムアウト付きロックは、待ち続ける状況を避け、一定時間後に処理を中断して代替経路へ進むための仕組みである。デッドロックの根本解決ではないが、復旧能力を高める手段になる。実装では、失敗時に整合性を壊さない後処理（ロールバック、補償、待機の再設計）が必要であり、単に待ち時間を短くするだけでは不十分になりがちである。
4 性能・運用
4.1 ボトルネックの特定
4.1.1 CPUバウンドとI/Oバウンド
並行化は常に万能ではない。CPUバウンドでは並行度を上げても計算資源が飽和し、切替コストが増えてむしろ悪化することがある。一方、I/Oバウンドでは待機が支配的になり、並行性により待ち時間を隠せる可能性が高い。ボトルネックの見極めは、測定結果に基づいて行うべきである。
4.1.2 計測指標（レイテンシ、スループット）
評価では複数の指標を組み合わせる。レイテンシは応答の速さを、スループットは処理量を示す。加えて、エラー率、キュー滞留時間、資源使用率（CPU使用率、I/O待ち比率など）も含めると原因に辿り着きやすい。平均値だけを見ると遅延の偏りを見落とすため、分位点（例えば中央値や高パーセンタイル）も有効である。
4.2 スケール戦略
4.2.1 並行度（ワーカー数）の決め方
ワーカー数の設定は、上げれば良いとは限らない。増加に伴い競合や管理コストが増え、同時に利用可能な資源が頭打ちになるためである。実務では段階的に上限を探索し、測定指標が改善から悪化へ転じる点を探す。さらにタスクごとの性質（重い計算か、待機中心か）で適正値が変わるため、一律の固定値よりもカテゴリ別の調整が有利な場合がある。
4.2.2 バックプレッシャー設計
バックプレッシャーは、需要が供給を上回る局面で投入量を抑え、崩壊を防ぐ考え方である。キューの上限、拒否や遅延の方針、ワーカーの減速、優先度に基づく制御などが含まれる。単にキューを肥大化させるとメモリ逼迫や遅延増大につながるため、「いつ、何を、どう抑制するか」を明文化する必要がある。
4.3 障害時の挙動
4.3.1 再試行と冪等性
障害時の再試行は、遅延や一時不良に対処するために一般的である。ただし、同じ処理が複数回実行されても結果が変わらない性質、すなわち冪等性が成立するかが鍵になる。冪等性がない場合は、重複排除（キーによる去重）や状態遷移の設計、補償による整合回復が必要になる。
4.3.2 キャンセルと後片付け
キャンセルは、不要になった処理を停止して資源を回収するための手段である。並行環境では、途中で中断された処理がロックを保持したままになったり、外部I/Oが継続してリークを起こしたりする懸念がある。従って、キャンセル伝播の方法、終了時の後処理（解放、状態更新、ログ出力）を整理し、停止が安全に完了することを保証する。
5 自動化（Automation）での活用
5.1 ワークフロー自動化における並行
5.1.1 ステップの並列化
ワークフロー自動化では、複数のステップを同時に実行できる場合が多い。依存関係がない処理（例：独立したデータ収集やビルド成果物の生成）を並行化することで全体の実行時間を短縮できる。並行化の範囲は、共有資源の競合や順序要件を考慮して段階的に広げるのが一般的である。
5.1.2 依存関係グラフの扱い
依存関係は有向グラフとして表現されることが多く、並行化はグラフ上で「先行する条件を満たしたノード」から実行することで実現される。サイクルを持つと実行順序が確定しないため、グラフ構造の検証が重要である。さらに、実行失敗時にどのノードを止め、どれを再実行するかという方針も依存関係に基づいて決められる。
5.2 監視と制御
5.2.1 進捗集計とアラート
自動化では多数のタスクが同時に走るため、進捗の集計と異常検知が必要になる。完了数や処理量、平均・最大の遅延、再試行回数などを統合して、しきい値を超えた場合にアラートを出す設計が用いられる。単純な「失敗件数」だけでなく、遅延の蓄積やキュー詰まりを早期兆候として扱うと復旧が速い。
5.2.2 実行履歴と監査
並行実行では、同じタイミングで多数の事象が起きるため、追跡可能性が特に重要になる。実行履歴には、入力、実行条件、実行結果、所要時間、例外情報、使用したバージョンなどを記録する。監査用途では、再現可能性の確保や、誰がいつどの設定を行ったかの記録も関係する。
5.3 テストと再現性
5.3.1 並行テストの観点
並行テストでは、競合条件やタイミング依存の不具合を明らかにする必要がある。観点としては、ロック取得順の差、遅延注入によるレースの顕在化、負荷下での安定性、キャンセル・リトライ時の整合性などが挙げられる。単体テストだけでは見えにくいので、統合テストと組み合わせることが多い。
5.3.2 決定性を高める設計
決定性の向上は、失敗時に原因を再現しやすくする。乱数の固定化、外部I/Oのスタブ化、時計やスケジューラを制御する工夫、ログの粒度を揃えることが有効である。完全な決定性が難しい場合でも、観測可能な順序関係（イベントのタイムスタンプや相関ID）を揃えて調査コストを下げる。
6 よくある誤解と落とし穴
6.1 「並行＝必ず速い」ではない
6.1.1 オーバーヘッドとコンテキスト切替
並行稼働には管理コストが伴う。スレッドやタスクの生成、状態保持、切り替え、同期待ちなどが増えると、純粋な処理時間よりもオーバーヘッドが支配的になる。特に短時間タスクを多数投入すると切替の割合が大きくなり、全体の速度が落ちることがある。
6.2 スレッドセーフの誤認
6.2.1 共有状態の見落とし
「スレッドセーフなはず」と判断しても、共有状態が別経路で更新されていれば安全とは限らない。グローバル変数、シングルトン、キャッシュ、内部で保持されるバッファなど、見落としが起きやすい。安全性は設計意図だけでなく、実際のアクセス経路を把握したうえで検証する必要がある。
6.3 ログとデバッグの難しさ
6.3.1 時系列の追跡設計
並行環境ではログが時系列に沿って出力されない場合がある。結果として原因の推定が難しくなるため、相関IDの付与、イベントの整列基準（どの基準で順序を見なすか）、遅延の計測点を揃える工夫が重要になる。さらに、再現手段（同一条件での再実行、観測データの保存）もデバッグの成否を左右する。
7 参考：実務での設計チェックリスト
7.1 目的・制約の明確化
7.1.1 SLAとリソース制限
まず、どの指標を満たすべきかを定義する。応答時間の上限、同時実行数の上限、許容できるエラー率、データ保持期間などの制約を整理し、並行化の方針と整合させる。さらに計算資源やネットワーク帯域の上限も明らかにし、理想論に偏らない設計にする。
7.2 同期方式の選定
7.2.1 ロック粒度とデータ設計
ロック粒度は、競合の回数と保持時間のバランスで決まる。大きすぎると待ちが増え、小さすぎると設計負荷や整合性の難化につながりやすい。データ設計としては、不変化、分割、スナップショット、原子性が必要な範囲の明確化を行い、同期方式が実装に自然に落ちる形を目指す。
7.3 運用設計
7.3.1 障害対応と観測性
運用では、失敗が起きたときの挙動を事前に決めておく必要がある。再試行の回数、キャンセル方針、後片付けの手順、フォールバック手段などを明記し、実行中の状態を観測できる指標を用意する。ダッシュボードやアラートだけでなく、必要なログやトレースが取得できることも確認対象になる。