メカニズム設計理論がアマゾンとベンダーの協力最適化にどう役立つか

When Amazon places a purchase order with a vendor, a deceptively simple question arises: how many units should go to which fulfillment center, and when? Amazon optimizes this decision based on its demand forecasts, inventory positions, and transportation costs. The vendor, meanwhile, has its own production schedules, warehouse locations, and shipping economics. Each side optimizes independently, and the result is often a plan that is suboptimal for both, resulting in higher costs for all. This is a classical problem in economics: “ coordination under asymmetric information”. Each party holds cost and capacity data the other cannot observe, yet their decisions are deeply intertwined. The theoretical tools for solving such problems have existed for decades, rooted in mechanism design, the branch of economics that asks whether transaction rules can be designed so that self-interested parties nonetheless produce an outcome that is good for everyone. Specifically, solutions to this problem tend to involve the Vickrey-Clarke-Groves (VCG) framework, one of the foundational results in mechanism design. What has been missing is a practical architecture that makes these ideas work at supply chain scale. In new work, my colleagues in Amazon’s Supply Chain Optimization Technologies (SCOT) organization and I show how combining VCG with Amazon's consensus planning protocol (CPP), a distributed, agent-based optimization framework, achieves exactly this. The resulting system, called Flo Pro, was successfully piloted over nine weeks with a prominent consumer-product manufacturer, demonstrating that the theory translates into real cost savings. The coordination gap To understand the opportunity Flo Pro presents, consider what happens today. Amazon issues purchase orders under a just-in-time (JIT) policy: it decides when, where, and how many units it wants, and the vendor decides how much of each order to fulfill. Within this sequential, noncooperative process, there’s room for further optimization: A vendor might be able to ship far more cheaply to one fulfillment center than another, but Amazon's JIT orders don't incorporate this information. Conversely, the vendor doesn't know Amazon's downstream demand patterns or outbound transportation costs, resulting in information asymmetry and preventing both parties from identifying the most cost-effective solution for all. The potential benefits from collaboration are easy to state in principle. If both parties shared their information, they could compute an optimized supply plan minimizing total supply-chain cost inbound and outbound, production and fulfillment. The hard question is how to realize these synergies when neither party wants to fully reveal its proprietary cost structure. From auction theory to supply chain coordination The VCG mechanism, named after William Vickrey, Edward Clarke, and Theodore Groves, achieves two ends simultaneously: social efficiency (the outcome maximizes total welfare) and incentive compatibility (every participant's best strategy is to report truthfully). The classic application is auctions, but the logic is far more general. In our setting, VCG works as follows. Amazon and the vendor each submit implicitly, through their optimization agents, their true preferences about supply plans. The mechanism computes the jointly optimal plan, then determines a transfer payment that equals each party's externality on the other. Concretely, the vendor pays Amazon an amount equal to the cost Amazon incurs by deviating from its preferred JIT plan to accommodate the proposed solution, a payment known as a cost-benefit transfer (CBT). Because this payment structure makes truthful reporting a dominant strategy, neither party benefits from misrepresenting its costs, regardless of what the other side does. CPP as the computational backbone The theoretical elegance of VCG faces a well-known practical barrier: it requires agents to submit their complete utility functions. In high-dimensional supply-chain problems with dozens of fulfillment centers, multiple products, and rolling weekly horizons, this is infeasible. This is where CPP comes in. CPP is a distributed optimization protocol based on the alternating-direction method of multipliers (ADMM). Rather than asking agents to reveal everything at once, CPP works iteratively. A central coordinator proposes a consensus plan and a set of prices. Each agent responds with its preferred plan given those prices — a "best response" that requires solving only the agent's own local optimization problem. The coordinator then updates the proposal, and the process repeats until convergence. The connection between CPP and VCG is natural and deep. CPP submissions from a truthful agent — one that honestly optimizes in response to each query — are equivalent to the submission of a truthful utility report in the direct VCG mechanism. The CPP iterations serve as the computational engine that finds the socially efficient plan. A second CPP run with one agent removed computes the cost to the remaining agent of its preferred plan; this provides the counterfactual needed to calculate the VCG transfer. The outcome is identical to that of the direct mechanism, but the information requirements are radically lighter: the vendor never reveals its cost structure, only its responses to iterative queries. This property — what we might call “information privacy” — is practically important. Vendors are understandably reluctant to disclose their production costs and capacity constraints. With CPP-based VCG, they don't have to. Their agents communicate preferences implicitly, through their optimization behaviors, and the mechanism extracts only the information needed to compute the efficient plan and the associated transfer payment. From theory to a rolling horizon Real supply chains don't stand still. Demand forecasts shift, supply conditions change, and plans must be updated continuously. We extend the static VCG framework to a dynamic, rolling-horizon setting inspired by the dynamic pivot mechanism that my colleague Juuso Välimäki and I described in 2010 and 2019. Each week, Amazon and the vendor plan a six-week forward-looking horizon. The mechanism issues a purchase order for the current week, computes what the resulting JIT policy would look like going forward, and determines the CBT. The CBT has an intuitive interpretation: it is the immediate cost of the current-week deviation plus the certainty-equivalent cost — that is, the cost that Amazon is willing to pay today to avoid an uncertain cost in the future — of that deviation on future periods. Whenever the proposed plan departs from JIT, the vendor compensates Amazon for the additional cost incurred, ensuring that neither Amazon nor the vendor is ever worse off from participating and benefiting the overall supply chain cost structure. This one-directional payment structure keeps the mechanism simple and robust, though extending it to two-way transfers — where Amazon might also compensate the vendor — remains an open design challenge A menu of contracts as an alternative For settings where the decision space is lower-dimensional, we also develop a “menu-of-contracts” approach. Here, Amazon computes a set of candidate supply plans and their associated prices — each price equal to the cost Amazon incurs from that plan— and offers the full menu to the vendor. The vendor simply picks the option that maximizes its own utility. By the logic of VCG, the vendor's best strategy is to choose the socially efficient plan. This approach has the advantage of transparency: the vendor sees concrete options and prices, rather than participating in an iterative optimization. It also opens the door to incorporating partial information: if a vendor indicates a general preference (say, for shipping more to one region), Amazon can tailor the menu accordingly. In our numerical example, the menu approach recovers the first-best outcome, with the vendor choosing the globally optimal plan from among the offered alternatives. Looking ahead The CPP-VCG framework is, at its core, a general-purpose tool for achieving consistent outcomes when each party acts on information unavailable to the other. The supply chain application we describe here is a natural first use case, but the underlying logic extends well beyond it. Vendor negotiations, Fulfillment-by-Amazon seller collaboration, and multiparty logistics planning all involve the same fundamental structure: interdependent decisions, private costs, and benefits that can be unlocked only through carefully designed incentive-compatible mechanisms. Several open questions remain. How should the mechanism handle the situation in which the vendor faces supply shortages and cannot deliver the agreed-upon quantities? Can mutual commitment structures — where both parties share obligations — improve outcomes when forecasts are highly uncertain? These are questions that sit at the intersection of economic theory and large-scale systems engineering, precisely the space where mechanism design has the most to offer. With Flo Pro, we have taken a first step toward making that potential concrete.