国際契約法務の要点――FIDICを題材として
第3回 第1章・幹となる権利義務（1）――工事等の内容その1
京都大学特命教授 大 本 俊 彦
森・濱田松本法律事務所
弁護士 関 戸 麦
弁護士 高 橋 茜 莉
第3回 第1章・幹となる権利義務（1）――工事等の内容その1
１ Rainbow Suite
前回、複雑な契約においては、「幹」となる権利義務が何であるかを意識することが有用であると述べた。FIDICのような建設・インフラ工事契約において、幹となる権利義務は、Contractor（受注者）の工事等を行う義務と、Employer（発注者ないし施主）の代金支払義務である。
まずは、このうちContractorの義務について解説する。
FIDICの契約書式には複数の種類があり、それぞれ色によって特定されているところ、基本的にはContractorの義務内容ないし守備範囲によって、以下のとおり種類分けがされている。これらは、様々に色分けされていることにちなんで、Rainbow Suiteと呼ばれている。
- ・ Red Book（Construction）― 建設工事および資材、設備等の調達を対象。設計は含まない（設計は、Employer側が行う）。
- ・ Pink Book（Construction, MDB Harmonized Edition）― 多国間開発銀行（MDB）による資金提供を想定して、Red Bookを修正したもの。Contractorの義務内容ないし守備範囲は、Red Bookと同じ。
- ・ Yellow Book（Plant and Design-Build）― 建設工事、資材、設備等の調達、および設計をいずれも対象とする。ただし、設計の概要または性能仕様は、Employer側が指定する。またプロジェクトのフィージビリティー・スタディー時に得られた地質、海象、天候等の設計条件を入札者に与える場合が多い。
- ・ Silver Book（EPC/Turnkey Projects）― 建設工事、資材、設備等の調達、および設計をいずれも対象とする。Employer側は施設や構造物の最終的機能や性能、見栄え（たとえば、製油所であれば、日産Ｘバレルの石油を精製する能力を持つこと、工場に隣接する芝のサッカー場を備えること）等の要求項目を提示するが、設計に関与する必要はない。Employer側が、Yellow Book同様、フィージビリティー・スタディー時に得られた設計条件を入札時に提示することがあるが、入札者、後のContractorは自らこのデータを検証（verify）しなければならない。すなわち、設計の概要または性能仕様の段階を含めて、Contractorが設計を行う。
- ・ Gold Book（Design, Build and Operate Projects）― 建設工事、資材、設備等の調達、および設計をいずれも対象とし、更に完成後の運用（オペーレーション）も対象とする。
上記の区分において重要な視点は、設計をEmployerおよびContractorのいずれが行うかである。Red BookおよびPink Bookにおいては、設計をEmployerが行い、Yellow Book、Silver BookおよびGold Bookにおいては、設計をContractorが行うことになっている。ただし、Yellow Bookは中間的な性質であり、上記のとおり、設計の概要または性能仕様は、Employer側が指定する。
上記のうち、実務でよく用いられているのは、Red Book、Yellow BookおよびSilver Bookの3つである。本連載では、このうちRed Bookの2017年版を主に念頭において解説を行うこととし、特に断りがない限り、引用条項は同Red Bookのものとする。ただし、Yellow BookおよびSilver Bookの2017年版にも、適宜言及することとする。
なお、Contractorの「幹」となる義務に関しては、その納期ないし履行時期も重要な意味を持つ。特に、大規模なプロジェクトであればあるほど、工事等が遅れ、当該設備の利用開始時期が遅れれば、そこで予定されていた経済活動等も遅れることになり、多大な損失となり得る。この点については、別途章を設けて、追って解説する。
２ 設計はEmployerおよびContractorのいずれが行うべきか
⑴ design-bid-buildとdesign-build（turn-key）
上記のとおり、設計を誰が行うかは、重要なポイントである。Employerが設計を行う場合は、その設計を前提に、Contractor選定の入札が行われるため、「design-bid-build」と呼ばれる。
これに対し、設計をContractorが行う場合は、設計および工事をともにContractorが行うことになるため、「design-build」と呼ばれる。また、Employerが行うべきことが限られていることを念頭に、「turn-key」とも呼ばれる。すなわち、Employerが行うべきことは、完成した目的物に鍵を入れて、稼働させることに基本的に限られており、換言すれば、Contractorは直ぐに稼働できる状態まで責任をもって、設計を含め基本的に全てを行うことが求められるという趣旨で、「turn-key」と称されている。
なお、FIDICの契約書式でよく用いられるもののうち、「design-build」に該当するのは、Yellow BookおよびSilver Bookである。ただし、Yellow Bookにおいては、上記のとおり、設計の概要または性能仕様は、Employer側が指定するため、「turn-key」という呼称は用いられていない。これが用いられているのは、Silver Bookである。
Contractorに支払われる代金の決め方には様々なものがあり、追って解説するが、「design-build」ないし「turn-key」においては、固定金額（lump-sum）とされることが多い。この場合、予め定められた一定の金額で、直ぐに稼働できる状態まで目的物を仕上げることをContractorが約束することになり、Employerは予算の管理がしやすい一方、Contractorはコストの増加による損失を被るリスクを負担することになる。
⑵ design-bid-buildよりもdesign-build（turn-key）が優れている点
このように「design-build」ないし「turn-key」は、代金を固定金額とすることによって、Employerの負担およびリスクを抑えることができる。かかるリスクの限定は、Employerに出資ないし融資をする投資家および金融機関にとっても非常に重要なことである。すなわち、資金の拠出者は、リスクと期待利回りを比較して資金拠出の判断をするところ、工事に関するリスクが限定されていれば、かかる判断が行いやすくなり、資金拠出が促進されることになる。近年、「design-build」ないし「turn-key」がより多く用いられる傾向にあるが、その理由としては、これら投資家および金融機関の存在が大きいと考えられる。
また、設計と工事をいずれもContractorが行うため、設計担当者と、工事担当者との間の連携がよりスムースになることが期待でき、これがプロジェクト全体の期間およびコストを圧縮することにつながるとも考え得る。
構造物に瑕疵のある場合においては、設計瑕疵と施工瑕疵の区別を問うことなく、同一のContractorの責を問えばいいので、Employerにとっては有益である。すなわち、設計瑕疵なのか、施工瑕疵なのかという争点を回避することができる。
⑶ design-build（turn-key）よりもdesign-bid-buildが優れている点
これに対し、「design-bid-build」では、Employerが設計をするため、そのプロジェクトに対するコントロールがより強くなり、目的物がEmployerのニーズにより即したものとなることが期待できる。これは裏を返すと、「design-build」ないし「turn-key」では、プロジェクトがContractorに任せきりという傾向になり、それがEmployerのニーズから乖離するリスクを高める要因となり得る。
また、「design-build」ないし「turn-key」では、特に代金を固定金額とする場合、Contractorが大きなリスクを負担するため、入札が慎重に行われることになり、そこで、「design-bid-build」の場合よりも、多くの時間と労力が費やされる。
加えて、かかる慎重な入札の結果、Contractorが安全をみてより高い金額を提示することになり、Employerのトータルの経済的負担は、「design-build」ないし「turn-key」の方が、「design-bid-build」よりも多額になり易いともいえる。この傾向は、入札時に発注者から与えられたデータのリスクもContractorが負わなければならないことによって、強くなり得る。
その上、「design-build」ないし「turn-key」で、代金を固定金額として契約を締結した後は、Contractorに、コスト削減のインセンティブが過剰に働く可能性もある。すなわち、Contractorの利益は、決められた固定代金額から、コストを控除したものとなるため、コスト削減が直にContractorの利益となる。このインセンティブが過剰に働くと、設計および工事の質が犠牲となり、後にトラブルになることが懸念される。
以上のとおり、いずれの方式にも一長一短があり、一概に優劣は決め難い。プロジェクト毎に、いずれが望ましいかを考える必要がある。