> For the complete documentation index, see [llms.txt](https://open-dataspaces.gitbook.io/ods-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://open-dataspaces.gitbook.io/ods-docs/jp/introductory-guide/kegaido/06-build-basics.md).

# 第6章 ODS Protocolsを実装するサービス構築の基本的考え方

## 6.1 本章の位置付けとねらい

本章は、第4章で整理したOpen Dataspacesにおけるサービス提供の構造、ならびに第5章で整理した参入パターンを前提として、ODS Protocols実装のマネージドサービス及びデータを中心としたサービスのソフトウェアを提供する主体が、技術的な実装に着手する際に押さえておくべき基本的な考え方を整理するものである。

## 6.2 サービスの構築フェーズにおける全体像

サービスの構築フェーズに進むにあたり、開発事業者は次の観点を整理しておく必要がある：

* 自社が担う関与形態（Fundamental/Complementary/Industry、またはその組み合わせ）
* プロトコルによる規律領域と設計の裁量がある領域との切り分け
* 参照実装OSS（ODS Middleware）活用と自社開発部分の切り分け
* 非機能要求と運用設計の基本観点を含めたサービス構築スコープの明確化

## 6.3 プロトコルによる規律領域と設計の裁量がある領域との切り分け

「ODS Protocols（ODP）」は、参加者間の相互運用性を成立させるために必要な役割分担や手続き、主体間のやり取りの構造を定義するものである。「どのような振る舞いが求められるか」という外形的な枠組みを示す一方で、具体的な技術スタック・内部コンポーネントの構成までを固定するものではない。

重要なのは、「プロトコルが示すのは外部との整合が必要な振る舞いであり、内部構成までを固定するものではない」という理解である。この切り分けを明確にすることで、外部との相互運用性を確保しながら、自社の差別化領域に開発リソースを集中させることが可能となる。

## 6.4 オープンソース利用と自社開発部分の切り分け

プロトコルを実装するための基本的なコンポーネントについては、ODSの開発コミュニティが擁する参照実装OSS（ODS Middleware）を活用することで、実装負荷を軽減しつつ相互運用性を確保しやすくなる。

一方で、業務固有のロジック、運用を支援する管理機能、分析や可視化などの付加価値領域は、自社の強みを活かした実装対象となる。OSSをマネージドサービスとして提供する際には、どの部分をOSSに依存し、どの部分を自社の責任範囲として保持するかというSLAを明確に設計する必要がある。 また、プロトコルやOSSの更新に追随できるよう、マイクロサービスアーキテクチャを採用することが設計指針として示されている。

## 6.5 非機能要求と運用設計の基本観点

サービス提供では、非機能要求と運用設計が重要な位置を占める。可用性や拡張性は分散データマネジメントの継続性に直結する。また、監査性や可観測性も重要であり、データのトランザクション履歴やプロセスを追跡可能な形で記録し、必要に応じて参照できることは、ガバナンスやトラストを技術的に支える基盤となる。セキュリティについてはOpen Dataspaces固有の要件に加え、通信の暗号化や鍵管理、脆弱性対応といった一般的な標準との整合を前提とする。

## 6.6 開発事業者が整理すべき観点の総括

サービスの構築において開発事業者が特に意識すべき要点は、次の三点に整理できる：

* プロトコルによって規律される領域と、自社裁量で設計できる領域を混同しないこと
* ODS Middleware活用と独自実装の境界を明確にし、更新追随や交換可能性を意識した構造とすること
* 非機能要求と運用設計を、実装の後工程ではなく初期段階から構築スコープに含めること これらの観点は、Design Philosophyに示された設計指針3原則（①ベンダーロックインの回避、②制度的ロックインの回避、③Product-likeなサービス志向の設計）とも対応する。

本章で整理した観点は、次章で扱う導入ステージ別の検討や実践に直結する基盤となるものである。