Documentation Index
Fetch the complete documentation index at: https://factory-docs-auto-sync-jp-docs.mintlify.app/llms.txt
Use this file to discover all available pages before exploring further.
このスキルは、Droidが内部データソース(分析ウェアハウス、レポートデータベース、内部データAPI)を使用して質問に答える必要がある際に、安全で監査可能かつ再現可能な方法で行うために使用します。
セットアップ手順
このスキルをFactoryで使用するには、リポジトリに以下のディレクトリ構造を作成してください:
.factory/skills/data-querying/
├── SKILL.md
├── metrics.md (任意)
├── examples.sql (任意)
└── data-governance.md (任意)
クイックスタート
-
スキルディレクトリを作成:
mkdir -p .factory/skills/data-querying
-
以下のスキルコンテンツを
.factory/skills/data-querying/SKILL.md(または skill.mdx)にコピー
Factoryに社内データのクエリやメトリクス分析を依頼すると、タスク説明に基づいてこのスキルが自動的に呼び出されます。
スキル定義
以下のコンテンツを .factory/skills/data-querying/SKILL.md にコピーしてください:
---
name: data-querying
description: 明確に範囲設定された質問に答えるため内部データサービスをクエリし、共有しても安全で再実行しやすい結果と成果物を生成します。ステークホルダーが内部ウェアハウス、マート、レポートAPIからメトリクス、傾向、データスライスを必要とする場合に使用します。
---
# スキル: 内部データクエリ
## 目的
明確に範囲設定された質問に答えるため内部データサービスをクエリし、共有しても安全で再実行しやすい結果と成果物を生成します。
## このスキルを使うタイミング
- ステークホルダーが内部データに基づく**メトリクス、傾向、スライス**を求めている。
- 既存の**ウェアハウス、マート、レポートAPI**から答えを導出できる。
- アドホックな手動エクスポートではなく、**再現可能なクエリ**が必要。
## 入力
- **ビジネス上の質問**: 知りたいことを1〜2文で説明する。
- **期間とフィルター**: 日付範囲、顧客セグメント、環境など。
- **ソースシステム**: 使用するウェアハウス、スキーマ、APIの名前。
- **データ機密性メモ**: PII、財務データ、規制対象データが含まれるかどうか。
## 対象外
- 明示的に許可されていない本番OLTPデータベースへの直接クエリ。
- 新しいパイプラインや取り込みジョブの作成。
- 承認済みの場所の外部に生PIIやシークレットを共有すること。
## 規約
- 利用可能な場合は、生テーブルではなく**推奨クエリレイヤー**(例: dbtモデル、セマンティックレイヤー、分析API)を使用する。
- 保存済みクエリや分析ノートブックには、確立された**命名規約とフォルダー規約**に従う。
- 内部の**データ分類とアクセス制御**ポリシーを尊重する。
## 必須の動作
1. ビジネス上の質問を正確なクエリ仕様(メトリクス、ディメンション、フィルター)に変換する。
2. 適切なソースを選び、複数の選択肢がある場合はトレードオフを説明する。
3. 対象システムに対して高性能でコストを意識したクエリを書く。
4. **結果**と**再実行可能なクエリ成果物**(SQL、API呼び出し、ノートブック、ダッシュボードリンク)の両方を生成する。
## 必須の成果物
- 適切なリポジトリまたはフォルダーにチェックインされたクエリ本文(SQL、DSL、APIリクエスト)。
- 手法、前提、注意点をまとめた短い**分析サマリー**。
- 作成した**ダッシュボード、ノートブック、レポート**へのリンク。
## 実装チェックリスト
1. ビジネス上の質問、期間、フィルターを明確にする。
2. 鮮度、完全性、ガバナンスに基づいて最適なデータソースを特定する。
3. クエリを作成し、限定された期間またはサンプルで検証する。
4. 回答を歪める可能性がある結合、フィルター、集計を確認し、必要に応じて修正する。
5. 承認済みの場所に、内容が分かる名前でクエリを保存する。
6. 結果を取得し、主要な発見と制限を要約する。
## 検証
データスタックに存在する検証メカニズムを使用します。例:
- 関連プロジェクトで`dbt test`
- カスタムメトリクスまたは変換の単体テストや回帰テスト
- 既知のベンチマークまたは過去レポートとの手動スポットチェック
以下を満たしたらスキルは完了です:
- クエリが許容される時間とコストの範囲内で正常に実行される。
- 結果が期待値または既知の参照値と一致する(妥当な許容範囲内)。
- 別のエンジニアまたはアナリストが再利用できる程度に、クエリと結果が文書化されている。
## 安全性とエスカレーション
- クエリが**機密データまたは規制対象データ**に触れる場合、サンプル行を含める前に、送信先(PR、ドキュメント、チケット)が承認済みの場所であることを確認する。
- データ品質問題を特定した場合は、データ品質チケットを作成または更新し、分析サマリーで目立つように明記する。