ここでは、制約理論について、次の観点で説明します。
制約理論とは
制約理論（TOC: Theory of Constraints）とは、1984年にエリヤフ・ゴールドラット博士が著書『ザ・ゴール』で提唱した理論で、組織やシステムの成果を最も制限している制約（ボトルネック）に着目し、それを集中的に改善することで全体最適を達成するマネジメント理論のことです。
TOCの根本的な考え方は、「部分最適は全体最適にならない」という点にあります。
例えば、ある工程だけの生産性を高めても、その後工程が詰まっていれば、在庫が増えるだけで売上は増えません。
これは「部分最適」を積み重ねても、「全体最適」にはならない典型的な例です。
非ボトルネック工程の効率をいくら上げても、ボトルネックが改善されなければ、システム全体のスループットは1ミリも向上しません。
TOCでは、このような部分最適を避け、システム全体の流れを制限している一点（制約）に改善を集中させることで、はじめて全体の成果が最大化されると考えます。
そのためTOCでは、すべてを均等に改善するのではなく、全体を制限している制約に改善を集中させることが重要だと考えます。
TOCの目的は、制約（ボトルネック）を特定し、それを適切に管理・統制することで、組織全体のスループットを最大化することです。
利益最大化のためには、単にコストを削減するのではなく、「スループットを増やすこと」が最も本質的な手段とされています。
スループット（Throughput）とは、単位時間あたりに企業が得る、真の「利益の源泉」、すなわち、顧客に販売して初めて得られる、売上から完全変動費を差し引いた金額のことです。
スループット = 売上高 − 完全変動費
- 売上高（Sales）
顧客に対して販売が成立した金額。 -
完全変動費（TVC: Totally Variable Cost）
「1単位売れなければ、絶対に発生しない費用」かつ「売れた数量に正比例して増減する費用」のことです。
TOCでは、これをほぼ「原材料費」だけと考えます。
TOCでは、スループット、在庫、業務費用の3つの指標で業務のパフォーマンスを測定します。
在庫は、販売のために保持しているすべての投資で、資金が固定されているものです。
業務費用（Operating Expense）は、スループットを生むために使われた全費用。固定費（人件費など）です。
在庫は、販売のために保持しているすべての投資で、資金が固定されているものです。
次の指標で関係づけることができます。
利益＝スループットー業務費用
ROI = 利益 ÷ 在庫
TOCは、会社をお金の循環システムとして観ます。
現金
↓
在庫（I） ← お金が眠る
↓
販売
↓
スループット（T） ← お金が解放される
↓
現金
スループットは、販売を通じて会社に入ってくるお金の速度を表します。
なので、制約を制御してスループットを最大化することで、キャッシュフローを最大化することができます。
スループット会計（Throughput Accounting）
スループットをベースとした会計の考え方は以下のようになります。
- ボトルネック以外の最適化は全体最適につながらない
従来の管理会計では、すべてのリソース（人や機械）に効率的な稼働率を求め、原価計算でコストを配賦します。
しかし、TOCでは「制約（ボトルネック）以外の効率化は利益に貢献しない」と考えます。
たとえば、
工場全体の稼働率を上げても、ボトルネックが処理できる量が限界なら、全体のスループットは増えない。
逆に不要な生産が在庫となり、コストを増やしてしまう。 - 直接労務費が変動費ではなく「固定費化」している現実
多くの現代企業では、労働者は正社員として固定給を受け取っており、労務費は実質的に固定費です。
TOCでは完全変動費のみをスループットの計算に使います。
つまり、
材料費など、製品を作るたびに必ず増えるコストだけを変動費とし、労務費は業務費用として処理します。 - 意思決定を単純かつ迅速にするため
従来の管理会計は、詳細な配賦計算や標準原価差異分析など、複雑で遅い分析手法になりがちです。
しかし、TOCでは、「スループットを増やす／在庫を減らす／業務費用を減らす」というシンプルな判断軸で、意思決定を加速できます。 - 局所最適による誤ったインセンティブを避けるため
直接労務費ベースでの原価管理では、工場や部門ごとにコスト削減目標が設定されます。
その結果、「とにかく人を遊ばせない」「無駄でも作る」といった無意味な作業や在庫の積み上げが起きやすくなります。
TOCでは、全体最適（制約のスループット最大化）を重視するため、こうした部分最適を避けるのが目的です。
制約理論の方法
ここでは、次の点について解説します。
制約理論の５つのステップ
制約理論では、制約を特定し克服するための5つの手順を提唱しています。
- 制約を特定する（Identify the Constraint）
システム全体のパフォーマンスを制限している最も大きなボトルネックを特定する。 - 制約を改善する（Exploit the Constraint）
制約の効率を最大化するために、現在のリソースを最適化する。
例：生産ラインのボトルネック工程の稼働率を最大化する。 - 制約へ適合させる（Subordinate Everything Else to the Constraint）
制約が最適なパフォーマンスを発揮できるように、他のプロセスを調整する。
例：非制約工程が無駄な作業をしないように同期を取る。 - 制約を克服する（Elevate the Constraint）
もし制約が依然としてボトルネックである場合、新しいリソースを追加したり、プロセスを改善したりする。
例：新しい設備を導入する、追加の人員を投入する。 - 新たな制約がないかチェックする（Repeat the Process）
制約を克服した後、新たな制約が生まれる可能性があるため、継続的にプロセスを繰り返す。
システムは、常にどこかに制約を持つ構造です。
まったく制約がない状況、たとえば無限に作れる、無限に売れるということはありません。
いくら売れても、いつか市場は飽和しますし、どれだけリソースを投入しても必ず限界があります。
つまり、システムが存在する限り、必ずどこかに制約は存在します。
制約は相対的なものであり、ある時点で経営成果を決定づけている制約は必ず一つです。
ある活動が制約である場合、その制約が解消されると、相対的に他の活動が制約として顕在化します。
これは新たな制約が生まれたのではなく、もともと存在していた別の制約が露出したにすぎません。
次のような小さな飲食店を考えてみましょう。
・席数：20席
・厨房：料理が遅い
・接客：十分
この場合、売上を決めている制約（ボトルネック）は「厨房」になります。
そこで、
下ごしらえの改善、
調理オペレーションの標準化
などの方法で制約を解消したとします。
すると、店舗回転率が上がることで、
席数が足りない
という状況になり、今度は、「客席」という制約が露呈します。
そこで、
席数の増加、
テイクアウト
などの方法で制約を解消すると、
平日の来客が少ない
集客力が弱い
など市場側の制約が現れます。
このように、組織内部の制約が適切に管理・統制されると、制約は組織内部から組織外部へと顕在化し、市場や顧客の意思決定が、経営成果を左右する主たる制約となります。
衣食住といった基本的な欲求が満たされると、次に、美しさや美味しさといった、より高次の価値が求められるように、顧客の欲望、すなわち選択の基準は、段階的に遷移していきます。
このように制約は、解消されて消えるのではなく、形を変えながら次の制約として顕在化します。
したがって、制約を管理・統制する5つのステップは一度きりで終わるものではなく、システムが存在する限り、継続的に繰り返されていきます。
つまり、TOCは、問題解決の手法ではなく、進化のフレームワークなのです。
制約を特定する方法
ここで、制約を特定する方法について、少し深堀ってみます。
バリューチェーンを
価値を創る活動（Innovation）
価値を届ける活動（Operation）
価値を伝える活動（Communication）
に分けて考えると、制約は、価値を届ける活動（Operation）に潜んでいることが多いです。
それは、価値を届ける活動（Operation）は、売上を上げる一連のプロセスだからです。
それでは、価値を届ける活動（Operation）を構成するビジネスプロセスのうち、具体的に、どのビジネスプロセスが制約になるのでしょうか。
ここでは、制約を発見する方法を次の５つの手順で制約を特定します。
スループットを止める活動は何か考える
例えば、価値を届ける活動（Operation）が次のビジネスプロセスから構成されるとします。
- 製品管理計画、マーケティング計画の策定
- 販売計画、サービス提供計画、生産計画、購買計画の策定
- 製品の改良、顧客の活性化
- 製品の販売
- 部品の購買
- 部品の入荷
- 代金の支払
- 製品の生産
- 製品の出荷
- 代金の請求
- 製品管理計画、マーケティング計画の検証・改善
このうち、どのビジネスプロセスが止まればスループットが止まる（売上がたたない）かを考えます。
そう考えると、次のビジネスプロセスが制約の候補になると考えることができます。
- 製品の販売
- 部品の購買
- 部品の入荷
- 製品の生産
- 製品の出荷
代替が効くか？でふるいにかける
次に、代替が効くビジネスプロセスかどうか分析します。
- 製品の販売
他の販売チャネル・代理店・手段で代替できるか？ - 部品の購買
他の仕入先、代替部品で回避できるか？ - 部品の入荷
在庫、前倒し、別ルートで吸収できるか？ - 製品の生産
他ライン、外注、残業で逃げられるか？ - 製品の出荷
別倉庫、別運送会社で代替できるか？
代替できるものは「真の制約」ではありません。
逃げ場がないものが残ります。
他が従属しているか？を観る
残った候補について、次を観察します。
- 他工程が「待たされている」
- 前後に在庫、滞留、WIP（仕掛）が溜まっている
- スケジュールがそこ基準で決まっている
そのビジネスプロセスのうち、スループット定義点になっている活動が制約です。
スループット定義点とは、そこを通過した瞬間に、会社に新しいお金が入ってくることが確定する一点です。
例
- 製品の販売が制約の場合
他工程が「待たされている」
・生産・出荷が終わっても「売れ待ち」で止まる
・倉庫・在庫は十分あるのに出荷指示が出ない
在庫・滞留・WIP
・完成品在庫が倉庫に山積み
・出荷可能だが未販売の在庫が増え続ける
スケジュールの従属
・生産計画が「販売見込み」に縛られる
・生産はできるが「売れないから作らない」判断が増える
典型的な例
・BtoBで営業担当が少数
・契約締結に時間がかかる商材
・見積・承認プロセスが重い
この場合の制約
「販売確定（契約・受注）」がスループット定義点になります。 - 部品の購買が制約の場合
他工程が「待たされている」
・生産ラインが「部品待ち」で止まる
・生産計画はあるが、発注が間に合わない
在庫・滞留・WIP
・半製品（途中まで作ったもの）が滞留
・特定部品だけが常に欠品
スケジュールの従属
・生産スケジュールが「部品の調達日」に引きずられる
・納期が購買リードタイム基準で決まる
典型的な例
・特定サプライヤー依存
・発注承認フローが遅い
・購買が人手・属人化
この場合の制約
「発注〜確定」または「購買判断」がスループット定義点になります。 - 部品の入荷が制約の場合
他工程が「待たされている」
・発注済だが届かないため生産できない
・倉庫・生産現場が到着待ちで止まる
在庫・滞留・WIP
・入荷待ちの未完成品が増える
・入荷後、一気に処理が集中する
スケジュールの従属
・生産・出荷日が物流日程に左右される
・「いつ届くか分からない」が前提になる
典型な例
・海外調達
・通関・検品がボトルネック
・倉庫の受入キャパ不足
この場合の制約
物流および受入プロセス（活動）がスループット定義点になります。 - 製品の生産が制約の場合
他工程が「待たされている」
・出荷・販売が「生産完了待ち」
・受注はあるが生産が追いつかない
在庫・滞留・WIP
・生産工程前に原材料・部品が滞留
・生産後工程は暇、前工程は混雑
スケジュールの従属
・全体スケジュールが生産能力基準
・残業・特急対応が常態化
典型な例
・特殊技能が必要な工程
・設備台数が限られる
・段取り替えが多い
この場合の制約
特定工程（活動）がスループット定義点になり、それを実行する人や設備（資産）の能力（キャパシティ）も影響します。 - 製品の出荷が制約の場合
他工程が「待たされている」
・生産完了しているが出荷できない
・倉庫が満杯で次が置けない
在庫・滞留・WIP
・出荷待ち完成品が山積み
・梱包・検品前後で滞留
スケジュールの従属
・納期が物流キャパに縛られる
・出荷可能日＝納品日になる
典型的な例
・倉庫人員不足
・梱包作業が属人化
・出荷システムが遅い
この場合の制約
出荷作業（活動）がスループット定義点になり、それを実施する物流設備（資産）の能力（キャパシティ）も影響します。
1点だけ仮説として決める
ここで重要なのは、「全部制約っぽい」は NGで、必ず1つに決めることです。
TOCは分析ではなく、意思決定の理論です。
「現時点で、最もスループットを制限しているのは〇〇工程である」
と仮説を置きます。
最小実験で裏取りする
仮説に対して、小さく試します。
例：
・その工程を少しだけ優先する
・余計な仕事を外す
・段取り替えを減らす
・AI・自動化・人手投入を一点だけ行う
そして見るのは 1 つだけ、スループット（売上・出荷・提供量）が即反応するか？です。
反応すれば、そこが制約です。
反応しなければ、仮説が違うので、次候補を試します。
マイクロサービス×AIエージェントによる制約理論の実践
最後に、マイクロサービス×AIエージェントで制約理論を実践する方法について説明します。
マイクロサービスとAIを組み合わせることで、制約理論（TOC）に基づく業務改善を「考え方」ではなく「システム構造」として実装できます。
以下では、製品の出荷プロセスを例に、マイクロサービス×AIによって制約を可視化・活用・克服する方法を説明します。
次の図は、UMLのコミュニケーション図で、「製品の出荷」プロセスにおける各ジョブの連携を表したものです。
このプロセスの各ジョブをマイクロサービスで置き換えると次のようになります。
業務活動をマイクロサービスで実現することで、次のように、制約を活動単位で可視化、制御、拡張することができるようになります。
制約が「人」ではなく「工程」として見えるようになる
マイクロサービス化していない場合、
・在庫管理者が遅い
・品質管理者が忙しい
・請求管理者がボトルネック
など、制約の特定が、 属人的で印象論になりがちです。
しかし、マイクロサービス化していると、
・在庫管理サービスの処理待ちが増えている
・品質管理サービスの処理時間が突出している
・請求管理サービスは常にアイドル
というように、制約が「特定工程（サービス）」として定量的に見えるようになります。
これは TOC において、「ある時点でシステム全体のスループットを決めている制約は1つ」という前提を守るために極めて重要です。
制約活用（Exploit）が技術的に可能になる
次に、マイクロサービス化した場合、比較的容易に、制約を最大限活用する（無駄を削る）ことができます。
例えば、品質検査活動が制約の場合、品質管理サービスを以下のように設計することで、それを最大限活用することが可能です。
・不要な同期呼び出しをやめる
・非制約マイクロサービスへの通知を非同期化
・判断が不要なケースを事前フィルタ
・処理順を最適化（優先キュー）
つまり、人の努力ではなく、設計でExploitできるわけです。
他工程の従属（Subordinate Everything Else to the Constraint）を構造で保証できるようになる
マイクロサービス化していない場合、
・「急ぎだから先に出荷して」
・「請求だけ先に切って」
・「とりあえず配送して」
という TOC違反が起きます。
しかし、マイクロサービス化していると、
・配送サービスは「品質管理完了イベント」を待つ
・請求管理は「配送完了イベント」に従属
・会計管理も同様
というように、人が守らなくても、システムがTOCを守ります。
つまり、ビジネスプロセスを仕組化することができます。
これは非常に大きなメリットです。
制約克服（Elevate）が一点投資で済む
マイクロサービス化していない場合、
・人を増やす
・全体を作り直す
・大規模システム更改
など比較的大規模投資になりがちです。
しかし、マイクロサービス化していると、
・制約マイクロサービスだけを強化すればよい
・スケールアウトできる
・比較的容易にAIを活用できる
・専用ロジックを追加できる
というように、TOCが求める「局所投資による全体改善」が可能になります。
次の例は、品質検査活動の品質が制約となるとき、品質管理サービスに連携したAIエージェントが不良リスクを予測することで制約を克服するというものです。
次のような流れになります。
- 出庫報告を受け取った品質管理サービスが品質管理エージェント（MCPホスト）に部品のロット情報を渡して不良リスクの予測を依頼します。
例
POST /tools/invoke
Host: mcp-agent.example.com
Content-Type: application/json
{
“tool”: “suggestExtraInspection”,
“input”: {
“lotNumber”: “LOT-20251116-001”
}
} - 品質管理エージェント（MCPホスト）は、品質管理エージェントが持つ過去のロット別品質検査結果を格納する品質DB（MCPサーバー）にアクセスして、不良リスクを予測し、「重点検査を実施してください」など次のアクションとして結果を品質管理サービスに返します。
例
{
“recommendation”: “重点検査を実施してください”,
“riskScore”: 0.82,
“reason”: “このロットは過去に20%以上のNG率を記録しています”
} - 品質管理サービスは、品質管理エージェントの結果を受取り、品質管理者に「重点検査を実施してください」などの指示を出します。
重要なのは、AIを全体に広く漫然と適用するのではなく、スループットを制約している工程に限定して投入する点です。
次の制約が自然に見える
マイクロサービス化していると、品質管理の制約を克服した後に、
・次は配送か？
・次は請求か？
・次は在庫管理か？
が ログとメトリクスで自動的に分かります。
TOCの「制約は移動する」を継続的に回せる構造になります。
このように、マイクロサービスによって業務活動を工程単位で分離し、AIを制約工程に集中して適用することで、企業全体のスループットとキャッシュフローを継続的に改善するビジネスアーキテクチャを実現することができます。
AIエージェントドリブンBPR
AIエージェントドリブンBPRは、AIエージェントの活用を前提にビジネスプロセスを再設計するアプローチです。
しかし、その成否は、TOC（制約理論）をベースに進めるかどうかで決定的に分かれます。
AIエージェントドリブンと言うと、多くの場合こう始まります。
・AIエージェントでできることは何か？
・自動化できる業務はどこか？
・人を減らせるところはどこか？
・精度を上げられるところはどこか？
つまり、最初の問いが「能力起点」です。
一方、TOCの問いは常にこれです。
今、システム全体のスループットを決めている制約は何か？
TOCをベースにしないAIドリブンBPRは、次のような危険性を孕んでいます。
・非制約にAIエージェントを入れる
・制約をさらに忙しくする
制約工程にAIエージェントの判断結果や追加確認作業を流し込み、かえって処理能力を下げる
・制約が見えなくなる
あちこちにAIエージェントが入り、どこが本当に詰まっているのか分からない
つまり、制約ファーストでBPRを進めないと、労多くして実りなし、投資しても効果がでないという結果を招きかねないのです。
TOC的に正しいAIエージェントの役割は、ほぼこの3つに限定されます。
・制約工程の判断補助
・制約工程の前処理・フィルタ
・制約工程のキャパシティ拡張
その場合、AIエージェントを「構造」に埋め込むことが前提になります。
つまり、人に「使わせるAIエージェント」ではなくイベントとサービスに組み込まれたAIにして 「人が頑張らなくてもTOCが守られる」仕組にするのです。
AIエージェントドリブンでのビジネスプロセス再設計は、制約理論の視点を欠くと部分最適に陥りやすくなります。
一方、TOCに基づいて制約を特定・制御した上でAIエージェントを制約工程に集中して適用する場合、AIエージェントはスループットを直接拡張する強力な手段となるのです。
さて、TOCに基づいて制約を順番に克服していくと、各工程は「制約になったタイミング」でAIエージェントによる強化を受け、結果として多くの工程にAIエージェントが存在する状態になります。
ただし、それは常に制約ファーストで段階的に行われます。
各工程から見ると
- 非制約のとき
AIエージェントは不要、または最低限 - 制約になった瞬間
最優先でAIエージェント投入 - 制約でなくなった後
そのAIは「標準装備」になる
このサイクルを繰り返すことで、ビジネスプロセスは進化していき、結果的に、価値を届ける活動（Operation）を極限まで自律化することができるのです。
[…] ここでは、制約理論（TOC）に基づいた業務改革・改善について説明しә […]
[…] 76;ーションします。 その際、制約理論（TOC）の現場レベルのステップ１ […]
[…] 制約理論（TOC） 上述したように、価値を届ける活動（Operation）は、AIエージェント前提でビジネスプロセスを再構築（BPR：Business Process Re-engineering）し、極限まで自動化すること（AIエー […]
[…] 制約理論（TOC）でいうと、価値を届ける活動（Operation）は、制約になりやすく、スループットの最大化に直結する業務領域です。 それに対して、価値を創る活動は、顧客価値に対する製 […]