正解: CCorrect: C
モデルを差し替え可能にし、競争優位をモデル以外（データ・ワークフロー・顧客関係）に置く設計が、どちらの勢力が優勢になっても有効です。Making models swappable and locating advantage outside the model, in data, workflows, and customer relationships, remains effective whichever camp prevails.
楽観シナリオ（オープン優勢）では、高性能モデルが安価に利用可能となり、差別化はモデルの上に構築する製品体験とデータに移ります。ベースシナリオでは、最先端は独占モデルが担い、一世代遅れの性能をオープンモデルが安価に提供する棲み分けが続きます。悲観シナリオ（独占固定化）では、少数のプラットフォームが価格と条件を支配し、依存した企業は交渉力を失います。選択肢Aはベンダーロックインと価格変動のリスクを抱え、Bは性能面で不利になる局面を許容せざるを得ず、Dは市場参入の遅れそのものが致命的です。Cの方針は、ある層がコモディティ化すると価値は隣接する層（データ、統合、顧客体験）に移動するという Clayton Christensen の議論と整合し、Linux とプロプライエタリ OS の共存の歴史も二者択一ではない展開を示唆しています。In the optimistic scenario (open models prevail), high-performance models become cheaply available and differentiation shifts to the product experience and data built on top. In the base scenario, proprietary models lead the frontier while open models offer one-generation-older capability at low cost, and this division persists. In the pessimistic scenario (proprietary lock-in), a few platforms dictate prices and terms and dependent firms lose bargaining power. Option A carries vendor lock-in and pricing risk; option B forces you to accept periods of performance disadvantage; option D makes delayed market entry itself fatal. Option C aligns with Clayton Christensen's analysis of modularity and commoditization: when one layer commoditizes, value migrates to adjacent layers such as data, integration, and customer experience. The history of Linux coexisting with proprietary operating systems also suggests coexistence and segmentation rather than a winner-take-all outcome.
抽象層を設けると、各モデル固有の強みを活かしきれず、性能が平均化される恐れがあります。また、モデル差し替えは技術的には可能でも、評価・再検証・プロンプト調整のコストが大きく、実際には切り替えが進まない「見せかけの可搬性」に陥りがちです。オープンモデルの運用には自社の計算資源と専門人材が必要です。An abstraction layer may prevent you from fully exploiting each model's particular strengths, averaging out performance. Even when switching is technically possible, the cost of evaluation, revalidation, and prompt tuning is high, so 'portability on paper' often never gets exercised. Running open models also requires in-house compute and specialist staff.
自動化された評価セットを整備し、モデル変更時の再検証コストを下げておくことが可搬性を実効的にします。用途ごとにリスクと要求性能を整理し、高リスク・高性能が必要な機能は最先端モデル、定型処理は小型モデルというように使い分ける「ポートフォリオ」設計が現実的です。ベンダー契約には価格改定や提供終了時の移行条件を盛り込みましょう。Maintain automated evaluation suites so revalidation costs stay low and portability is real. Sort use cases by risk and required performance, routing high-stakes, high-capability functions to frontier models and routine processing to small models in a portfolio design. Include terms in vendor contracts covering price changes and migration on discontinuation.