はじめに

DataCoreはナレッジウェアハウスです。チームが生のリソース (PDF、GitHubリポジトリ、CSV、音声、 Markdown) を登録すると、システムは各リソースを設定可能なプラグインステップのパイプラインへ 自動的にルーティングし、パイプラインは下流のLLMが問い合わせ可能な再利用可能な成果物 (ベクトル 埋め込み、ナレッジグラフ、要約、またはカスタム分析データ) を生成します。

コアコンセプト

概念	内容
リソース (Resource)	ユーザーが登録する生データの1件 — 名前、ソース (アップロードファイルまたはURL)、タイプを持ちます。すべてのリソースにはステータスがあります: Pending → Processing → Completed/Failed。
パイプライン (Pipeline)	特定のリソースタイプに対して自動的に実行される、順序付けられた処理ステップの並びです。トリガータイプごとに最大1つのパイプラインが存在します。
プラグイン (Plugin)	パイプラインの1ステップを実行し、イベントブローカー経由で成果物 (または失敗) を報告する独立したワーカー (専用のDockerコンテナ) です。
成果物 (Artifact)	プラグインステップによってリソースに対して生成される再利用可能な出力 — ベクトル埋め込み、グラフ、テキスト要約、またはプラグインが定義する任意のカスタム分析データタイプです。

ユースケース

DataCoreは再利用可能なRAG基盤です。新しいコンテンツをLLMに理解させるたびに独自の取り込みパイプラインを 書く代わりに、リソースを1件登録すればプラグインのパイプラインが自動的にそれを問い合わせ可能な成果物へ 変換します — 同じタイプの以後のリソースすべてに対して、一度設定するだけで済みます。具体例:

• 個人ポートフォリオ / 活動サマライザー — まずは**ライブデモ** (英語版もあります) を実際に触ってみてください。これは 本物の、最初から最後までDataCoreだけで動いています: github-profile-scanner がGitHubプロフィールを スキャンし、リポジトリのメタデータ、README、そして上位リポジトリの実際の package.json/pom.xml/Dockerfile の内容まで取得します。Geminiがその実データに基づいて ポートフォリオの文章を作成し、「私の仕事について質問する」検索ボックスが同じデータに対する検索 (RAG) で訪問者の質問に答えます。デモ自身の DataCoreリソース タブには、背後で実際に実行された すべてのリソースと成果物が表示されます — モックは一切ありません。ソースコードは examples/github-portfolio — スキャナープラグインとそのストレージステップの仕組みについては プラグインの作り方 を参照してください。
• エンジニアリングチームのナレッジベース — リポジトリ、エクスポートしたドキュメント、PDFに パイプラインを向けると、新しいリソースが追加されるたびに埋め込みと要約が最新の状態に保たれ、 MCP対応の任意のLLMクライアント (Claude、Cursorなど) から問い合わせ可能になります。各ツールが独自の 検索ロジックを実装する必要はありません。
• サポート / オンボーディングアシスタント — 散在するCSV、通話記録、運用手順書を一度取り込めば、 下流のどのチャットボットも各アプリで検索ロジックを再実装することなく、MCP経由で根拠のある回答を 得られます。

なぜイベント駆動なのか

コア (ウェアハウスAPI) とプラグインワーカーは同期的に互いを呼び出しません。代わりに:

1. リソースがパイプラインに一致すると、コアが RESOURCE_CREATED を発行します。
2. Pipeline Routerがそれを受け取り、最初のステップを PIPELINE_STEP_DISPATCHED イベントとして、 担当プラグインへルーティングします。
3. プラグインは処理を行い、単一の内部HTTPコールバック (POST /api/v1/internal/artifacts/{resource_id}) 経由で結果を報告します — これがシステム全体で 唯一の同期呼び出しです。
4. コアは次のステップへ進むか、リソースを Completed/Failed としてマークします。

これにより、プラグインがクラッシュ・ハング・低速になっても、コアや他のプラグインを停止させることは 決してありません — 詳しい理由はアーキテクチャを参照してください。

自分で実行してみたいですか? クイックスタートへ進んでください。