Core Projects

主要プロジェクト

BODIK R&Dの研究開発は、公共データ基盤を構成する各層の課題に対応したプロジェクト群で進行しています。各プロジェクトは独立した機能群ではなく、相互に接続されることでAI時代に適した公共データ連携基盤を形づくる構成要素です。

Collection

cms_to_ckan

既存CMSから公開基盤への接続

多くの自治体では、公開すべき情報が既にCMS上に存在していても、それをオープンデータ基盤へ再整理し、継続的に反映する工程に大きな負荷がかかります。その結果、公開の継続性が失われたり、担当者の個別努力に依存したりする状況が生まれやすくなります。

cms_to_ckanは、既存CMS上の情報資源をオープンデータ公開基盤へ接続するための研究開発です。対象構造の解析、変換ルールの適用、公開形式への整形、差分更新への対応などを通じて、公開作業の自動化と運用負荷の軽減を目指します。AIを補助的に用いることで、構造理解や移行処理の柔軟性を高めることもこのプロジェクトの重要な特徴です。

このプロジェクトは単なる移行ツールではありません。既存の情報資産との接続性を高めることで、オープンデータ公開を持続的な基盤運用へ変えていく役割を担います。

cms_to_ckan によるCMSからCKANへの接続イメージ
既存CMS上の情報を公開基盤へ継続反映するための接続イメージ。
このプロジェクトが担う課題
既存CMSと公開基盤の断絶再入力・再整形の手作業負荷差分更新の継続運用公開の持続可能性の確保
アーキテクチャ層
L2 — Collection / Ingestion
対応する研究領域
→ 自動探索・自動変換
アーキテクチャ全体図を見る
Architecture →
Collection

ODMM-ai

自治体サイトの公開箇所自動探索

公共データ利活用の前提となるのは、まず「どこに、どのような形で公開されているのか」が把握できることです。しかし実際には、自治体ごとに公開場所や構成が異なり、収集や追跡には継続的な人手が必要になります。

ODMM-aiは、この探索と把握の工程を自動化するための研究開発です。自治体サイトを横断的に探索し、公開箇所を見つけ、適切な収集対象として認識し、継続的な更新追跡へつなげることを目指します。

このプロジェクトの価値は省力化だけにはありません。公開場所の把握が安定すれば、収集、メタデータ拡張、API提供といった後続工程の成立性も高まります。ODMM-aiは、基盤全体の入口を担うプロジェクトとして位置づけられます。

ODMM-ai による自治体サイト探索のイメージ
公開箇所の発見と更新追跡を自動化し、収集工程の入口を安定させます。
このプロジェクトが担う課題
公開場所の分散手動探索の限界更新追跡の不安定さ継続的収集基盤の不足
アーキテクチャ層
L2 — Collection / Ingestion
対応する研究領域
→ 自動探索・自動変換
アーキテクチャ全体図を見る
Architecture →
Enrichment

拡張メタデータサーバー

AI補助による多層メタデータ拡張

公開されたデータセットが存在していても、その内容や用途、比較可能性が十分に伝わらなければ、利活用は限定的になります。人間にとっても、AIにとっても、メタデータの不足は探索性と理解可能性を大きく下げる要因です。

拡張メタデータサーバーは、メタデータを多層的に拡張するための研究開発です。公開時点のオリジナル情報に加え、機械的な正規化・補足情報、さらにAIによる要約や意味補強を重ねることで、データセットをより理解しやすい状態へ整えます。BODIK R&DにおけるAI Readyの考え方を最も直接的に体現するプロジェクトです。

このプロジェクトにより、利用者はデータの内容や用途を把握しやすくなり、AIは検索、分類、推薦、比較支援を行いやすくなります。公開基盤を「掲載の場」から「理解可能な資源の集積」へ高めていくための中核層として位置づけられます。

拡張メタデータサーバーの多層メタデータ拡張イメージ
公開時点の情報に正規化とAI補強を重ね、理解可能性を高める中核レイヤー。
このプロジェクトが担う課題
メタデータの粒度不足AIによる理解可能性の低さ利用者にとっての探索負担データセット間比較の難しさ
アーキテクチャ層
L3 — Metadata & Enrichment
対応する研究領域
→ AI Readyなメタデータ拡張
アーキテクチャ全体図を見る
Architecture →
API / NGSI

VAPI

仮想データモデルによる横断API

同じテーマのデータであっても、自治体ごとに項目名、日付形式、型、単位、表現が異なります。この違いは、それぞれの運用には自然であっても、横断比較や広域利用の場面では大きな障壁になります。

VAPIは、この差異をAPI層で吸収し、利用者に対して共通的な取得インターフェースを提供するための研究開発です。背後では、仮想データモデルにもとづいて項目の読み替え、型変換、書式統一、クレンジング処理を行い、個別データの違いを意識しなくても扱える状態を目指します。

重要なのは、VAPIが一律の標準化を強制するものではないという点です。また、NGSIインターフェイスとして整備することで、既存FIWARE系資産や共通基盤との接続も確保します。

VAPI の仮想データモデルによる横断APIイメージ
形式差異を背後で吸収し、利用者には共通的な取得インターフェースを提示します。
このプロジェクトが担う課題
自治体ごとの形式差異横断比較の困難さAPI利用時の前処理負荷共通利用基盤の不足
アーキテクチャ層
L5 — Access & API
対応する研究領域
→ 仮想データモデル
アーキテクチャ全体図を見る
Architecture →
API / NGSI

RAPI

軽量リアルタイムデータ連携API

公共データの多くは、依然として静的ファイルの公開を中心としています。一方で、施設予約状況、防災関連情報、センサー値、運行状況など、更新頻度の高い情報を扱う必要性は高まっています。

RAPIは、このような動的データに対応するための軽量なリアルタイムデータ連携基盤です。FastAPIやElasticsearch、MQTT等を組み合わせ、更新通知、購読、短期履歴の管理、API経由での利用を実現する方向で研究開発が進められています。NGSIインターフェイスを備えることで、既存基盤との相互接続も可能にします。

RAPIは、静的な公開データと動的な連携データを同じ基盤思想の中で扱えるようにし、公共データ利活用の対象を拡張していくための重要な構成要素です。

RAPI の軽量リアルタイムデータ連携イメージ
動的データを軽量構成で接続し、通知・検索・履歴管理を一体化する設計です。
このプロジェクトが担う課題
静的公開に偏った基盤構成動的データの接続先不足重すぎるリアルタイム基盤の導入負荷更新通知と履歴管理の分断
アーキテクチャ層
L5 — Access & API
アーキテクチャ全体図を見る
Architecture →
Platform

Data Platform

認証・API・モデル統合基盤

個々の研究成果やAPIが存在していても、それらが利用者にとって分断されたままであれば、基盤全体としての価値は十分に発揮されません。利用者に必要なのは、複数の技術要素を意識せず、目的に応じて一貫した形でアクセスできる環境です。

Data Platformは、そのための統合的な利用基盤として位置づけられるプロジェクトです。認証と権限管理、APIへの接続、データモデルの参照、利用者向けのインターフェースなどを一つの環境として整理し、BODIK R&Dの各成果を相互接続された基盤として成立させます。

このプロジェクトの役割は単なるポータル画面を作ることではありません。メタデータ拡張、VAPI、RAPI、自動探索・自動変換といった各成果を、利用者視点から再構成し、研究成果を社会実装の入口へ接続することにあります。

Data Platform の統合利用基盤イメージ
認証、API、モデル参照、利用導線を統合し、研究成果を一つの利用環境へまとめます。
このプロジェクトが担う課題
研究成果の分断利用者にとっての導線不足認証・API・モデル管理の散在実利用環境への接続不足
アーキテクチャ層
L6 — Platform & Governance
対応する研究領域
→ 統合プラットフォーム設計
アーキテクチャ全体図を見る
Architecture →