OCDS入門：オープン・コントラクティング・データ標準の解説

OCDSとは

Open Contracting Data Standard（OCDS）は、計画から入札、落札、契約履行に至る契約プロセス全体について、構造化されたデータを公開するためのオープンで非独占的なJSONスキーマです。グローバルな非営利団体であるOpen Contracting Partnership（OCP）が開発し、2014年に最初にリリースされたOCDSは、現在50以上の国と国際機関が、公共調達データを一貫した機械可読形式で公開するために使用しています。

中核となる考え方はステージベースです：すべての調達は、定義されたステージ（計画、入札、落札、契約、履行）を経て進む「契約プロセス」であり、OCDSは各ステージで生成されるデータを捕捉します。各国が独自のフォーマットを発明する代わりに、OCDSは共通の語彙を提供し、調達データをグローバルに比較可能にします — エストニアの落札公告とコロンビアの落札公告を、同じツールで並べて分析できるのです。

OCDSのリリースモデル

OCDSは、OCID（Open Contracting ID）をキーとする、タイムスタンプ付きの「リリース」としてデータを公開します。各リリースには、その時点で契約プロセスについて判明しているすべて — 当事者、入札条件、落札、契約 — のスナップショットが含まれます。1つの契約プロセスは通常、ステージの進行に伴って複数のリリースを持ちます：

• 計画リリース — 予算が配分され、プロジェクトが定義される。
• 入札リリース — RFPが公示され、基準が判明し、締切が設定される。
• 落札リリース — 落札者が選定され、価格が判明する。
• 契約リリース — 契約が署名され、条件が添付される。
• 履行リリース — 成果物、支払い、変更が時系列で記録される。

公開者は、個別のリリース（不変のスナップショット）を投稿することも、「レコード」— 1つのプロセスのすべてのリリースを統合した現在状態のビュー — を維持することもできます。ほとんどの実装は両方を行っています。

OCDSを公開しているのは誰か

政府の採用例（一部。採用は年々増えています）：

• 英国 — Contracts FinderとFTSがOCDS抽出データを公開。
• ウクライナ（ProZorro） — OCDS実装の旗艦。ProZorroのすべての入札がOCDS準拠です。
• コロンビア（SECOP II） — 中央政府全体で完全なOCDS公開。
• パラグアイ、ホンジュラス、メキシコ — ラテンアメリカのオープン・コントラクティングのリーダー。
• モルドバ、ジョージア、キルギス — OCPの能力構築支援による東欧での採用。
• スロバキア、エストニア、ポルトガル — 強力なオープンデータ政策を持つEU加盟国。

国際機関：世界銀行は一部のプロジェクトデータをOCDS互換形式で公開しています。EBRDやIDBを含む国際開発金融機関も段階的に採用を進めています。

発注者にとってOCDSが重要な理由

発注者は、OCDS以前はPDFに閉じ込められていた分析能力を手に入れます：

• 価格ベンチマーキング — 類似契約が地域をまたいでいくらだったかを確認できます。
• サプライヤー集中度分析 — 1社のベンダーに支配されているカテゴリーを特定できます。
• レッドフラグ検知 — 応札1社のみの結果、短すぎる締切、基準額未満への疑わしい分割発注をアルゴリズムがフラグできます。
• 契約ライフサイクルの追跡 — 変更の頻度、コスト超過、納期遅延が体系的に可視化されます。

サプライヤーにとってOCDSが重要な理由

サプライヤー側にとっては、さらに変革的です：

• 大規模なマーケットインテリジェンス。発注者、カテゴリー、CPVコード単位で契約履歴全体をクエリできます — 誰が、いくらで、どんな条件で落札したのか。
• 既存業者の追跡。契約がいつ満了し、再競争にかけられるかを把握できます。
• 価格の較正。自社カテゴリーの過去の落札金額から、発注者の支払い意欲がわかります。
• 機械での取り込み。構造化されたJSONということは、調達公告が、脆弱なPDFスクレイピングなしに、サプライヤーのCRM、応札管理ツール、あるいは（TenderYetiのように）AI関連度スコアリングエンジンへ直接流れ込むということです。

コアスキーマ（簡略版）

OCDSリリースのトップレベルは、おおよそ次のような形をしています：

• ocid — 契約プロセスの一意なID
• date — このリリースのタイムスタンプ
• tag — ステージ（planning / tender / award / contract / implementation）
• parties[] — 役割タグ付きの発注者、応札者、サプライヤー
• tender — タイトル、説明、調達方式、品目、日付、基準、締切
• awards[] — 金額、日付、サプライヤー、関連ロット付きの落札者
• contracts[] — 署名済み契約、マイルストーン、変更、取引
• planning — 予算、プロジェクトの根拠

調達方式（open / selective / limited / direct）、落札基準（priceOnly / costOptimal / bestProposal / ratedCriteria）、入札ステータス（planning / active / cancelled / unsuccessful / complete / withdrawn）などのコードリスト列挙型が定義されています。

拡張機能

OCDSのコアは、ほとんどの公開者が必要とするものの約80%をカバーします。残りは拡張機能 — 公開者がオプトインできるモジュール式のアドオン — で対応します。よく使われるもの：

• 入札統計 — ロットごとの応札者数。
• 質問（Enquiries） — 入札期間中のQ&A。
• 追加の連絡先 — 発注者・応札者の追加連絡先フィールド。
• フレームワーク契約 — フレームワーク構造のための追加フィールド。

限界

• 公開品質にはばらつきがあります。採用国でもデータ完全性の問題があります — 日付の欠落、非標準のコードリスト、乏しい落札情報など。
• 普遍的ではありません。主要な公開者（米国SAM.gov、中東のほとんどの政府）はまだOCDSを公開していません。
• 言語。OCDSはスキーマであって翻訳者ではありません — 記述フィールドは公開者の言語のままです。
• 添付ファイルは依然としてPDF。入札文書、仕様書、契約書のテキストは通常、OCDS内に構造化されず、PDFのURLとして参照されます。

TenderYetiの役割

TenderYetiのスクレイピングスタックは、OCDSが公開されているすべての場所（ウクライナProZorro、スロバキア、モルドバ、英国Contracts Finderなど）でOCDSを読み取り、非OCDSソースも共通の内部スキーマに正規化するため、336以上のポータルすべてが同じインターフェースを通じてクエリ可能になります。ポータルのカバレッジをご覧ください。

よくあるご質問