ota2000
10 min read

Claude Code のスキルに使えるオープンライセンスのガイドラインを探した

Data EngineeringClaude CodeBIdbt

前回の記事で、デジタル庁のダッシュボードガイドブックを Claude Code のスキルにした話を書いた。「他にもスキルにできるガイドラインはないのか」と聞かれたので、調べた結果を書く。

ガイドラインをスキルにする動機

ダッシュボードの YAML を書いたり dbt モデルを設計したりするとき、Claude Code はコードの書き方は知っているが、設計判断の根拠を持っていない。「このチャートは棒グラフと折れ線のどちらにするか」「このモデルの粒度はどうすべきか」といった判断は、人間がレビューで都度指摘するか、スキルに判断基準を入れておく必要がある。

世の中にはデータエンジニアリング領域のガイドラインが数多く公開されている。問題は、それらをスキルに組み込めるかどうか。スキルに入れるにはガイドラインの内容を要約・加工する必要があるので、ライセンスが改変を許可していないと使えない。

調べたガイドラインとライセンス

ガイドラインライセンス改変条件
デジタル庁 ダッシュボードガイドブックPDL1.0OK出典記載 + 加工した旨の明記
IBCS (International Business Communication Standards)CC BY-SA 4.0OK出典記載 + 同じライセンスで共有
dbt Best Practices (docs.getdbt.com)Apache 2.0OKライセンス表記
ODCS (Open Data Contract Standard)Apache 2.0OKライセンス表記

一方、著名だがライセンス上そのまま使えないものもある。Kimball Group のディメンショナルモデリング（All rights reserved）、Stephen Few のダッシュボード設計原則（書籍著作権）、DAMA-DMBOK（著作権保護、一部図表のみ CC BY-ND）など。どれも優れた内容だが、スキルに要約・加工して組み込むことはライセンス上できない。概念を参考にして自分の言葉で書く分には問題ないが、「ガイドラインをそのまま変換する」というアプローチとは区別している。

上の4つがオープンライセンスで改変可能なのは、それぞれのメンテナが意図的にそうしているから。デジタル庁は公共データの利活用を促進するため、IBCS Association はレポート表記の普及を目的として CC BY-SA を選択している。dbt Labs と Bitol は OSS コミュニティとしてドキュメントも Apache 2.0 で公開している。こうしたライセンス選択のおかげでスキル化が可能になっている。

スキル化したガイドライン

1. デジタル庁 ダッシュボードガイドブック → チャート設計判断

前回の記事で詳しく書いたので省略するが、チャートタイプの選択、Do’s/Don’ts、カラーパレットの設計判断をスキルにしている。Lightdash の YAML を書くときに自動で読み込まれて、「円グラフより棒グラフの方が正確に伝えられる」といった判断を Claude が自分でやってくれるようになった。

2. IBCS → レポート・ダッシュボードの表記統一

IBCS はビジネスレポートの表記を標準化するための国際規格。CC BY-SA 4.0 で公開されていて、ISO 標準化も進行中（ISO/AWI 24896）。

核になるのは SUCCESS の7原則（SAY・UNIFY・CONDENSE・CHECK・EXPRESS・SIMPLIFY・STRUCTURE）で、レポートの設計からセマンティックな表記ルールまで体系化している。詳しくは公式サイトを参照してほしい。

デジタル庁のガイドブックと重なる部分もあるが、IBCS の方がより体系的で、特に表記の統一（UNIFY）と情報密度（CONDENSE）はデジタル庁ガイドブックにはない観点。

スキルに入れる際は、デジタル庁ガイドブックのスキルと役割を分けた。デジタル庁の方は「個々のチャートをどう作るか」、IBCS の方は「ダッシュボード全体をどう構成するか」という棲み分け。

3. dbt Best Practices → モデリング規約

dbt Labs の公式ベストプラクティスは Apache 2.0 で公開されている。内容は大きく3つ。

スタイルガイド:

  • snake_case でフィールド命名、略語を使わない
  • stg_、fct_、dim_ のプレフィックスでモデルの役割を明示
  • 主キーは <object>_id 形式（account_id など）

プロジェクト構造:

  • source-conformed（外部システムの形）から business-conformed（ビジネスの形）へのアークを作る
  • staging → intermediate → marts のレイヤリング

テスト:

  • 全モデルの主キーに unique + not_null テスト必須
  • sqlfluff 等のリンターでスタイルを自動チェック

自分のチームでは dbt のモデリング規約を独自にまとめたスキルを持っているが、dbt Labs の公式ガイドと照らし合わせて足りない部分を補完した。特にフィールド命名規則とプレフィックスの標準は、公式の記述をベースにした方がチーム内の合意を取りやすい。実際、Claude が customer_id ではなく cust_id のような略語を出してくることがあったが、スキルに命名規則を入れてからは出なくなった。

4. ODCS → データ契約の定義

Open Data Contract Standard（ODCS）は Linux Foundation の Bitol プロジェクトが策定するオープン標準。Apache 2.0 ライセンス。

データ契約とは、データの提供者と利用者の間で「このデータはこのスキーマで、この鮮度で、この品質で提供する」という合意を形式化したもの。ODCS は YAML でこれを記述する。

schema:
  - name: orders
    logicalType: object
    physicalType: table
    description: "注文データ"
    properties:
      - name: order_id
        logicalType: string
        primaryKey: true
        required: true
      - name: order_date
        logicalType: date
        required: true

スキルとしては、dbt のソース定義やテスト設計と組み合わせている。「このソースにはどんなテストが必要か」を Claude に考えさせるとき、ODCS の考え方（スキーマ、鮮度、ボリューム、セマンティクス）がフレームワークとして機能する。

ODCS の仕様をそのまま全部入れているわけではなく、dbt の sources.yml と対応する部分を抜き出して、「データ契約的に考えるとこのソースにはどんなテストが必要か」を判断できるようにしている。

スキル化のパターン

4つのガイドラインをスキルにしてみて、共通するパターンが見えてきた。

原文をそのまま入れない

前回の記事でも書いたが、PDF やドキュメントをそのまま突っ込んでもコンテキストが長すぎて効かない。「コード生成に使える部分」だけを抽出する。

ツール固有のマッピングを足す

ガイドラインはツール非依存で書かれている。「時間変化には折れ線グラフ」は正しいものの、それが Lightdash の chartType: cartesian の type: line だとは書いていない。dbt の stg_ プレフィックスも、自分のプロジェクトでどのディレクトリに置くかまで公式ガイドには書いていない。このマッピングを足す作業の効果が一番大きい。

自チームの文脈を足す

汎用的なガイドラインには選択肢が複数並んでいる。IBCS のカラーパレット、dbt のプロジェクト構造のバリエーション、ODCS の品質レベルの定義など。全部入れると Claude が迷うので、自チームで採用しているものだけに絞る。

設計判断と実装手順を分ける

1つのスキルに全部入れると膨れる。「なぜそうするか（設計判断）」と「どう書くか（実装手順）」は別スキルにした方が、Claude Code の自動選択も効きやすい。

設計判断（WHY / WHAT）  → *-design-principles, *-patterns
実装手順（HOW）          → *-guide
制約・規約（MUST）       → rules/

ガイドラインの探し方

「スキルにできるガイドラインは他にないか」と探すとき、以下の基準で見ている。

  1. ライセンス: CC BY / CC BY-SA / Apache 2.0 / MIT など、改変・再配布が明示的に許可されているもの
  2. 具体性: Do’s/Don’ts やチェックリストなど、判断基準が明確に書かれているもの。抽象的な原則だけだと Claude の判断に使えない
  3. 自分のワークフローとの接点: コード生成やレビューの場面で参照できるもの。組織設計やプロセス改善の話はスキルに向かない

この3つを満たすものは意外と少ない。著名なガイドラインでもライセンスが All rights reserved だったり、内容が抽象的すぎたりする。今のところ上記の4つが自分の業務に合っている。

やってみて

既に体系化されたガイドラインをスキルの素材にすると、自分でゼロから判断基準を書くより早い。dbt の命名規則なら公式ガイドの記述をベースにすればチーム内で「なぜそうするのか」の説明も不要になる。

ガイドラインをそのまま入れても効かないので「自チームの文脈に合わせて削る・足す」作業は必要だが、この作業自体がガイドラインの理解を深めるプロセスにもなる。PDF を読んで終わりにするより定着する。

今回調べてみて、オープンライセンスで公開されている良質なガイドラインは思ったより少なかった。逆に言えば、上記4つはライセンス・具体性・実務との接点の3つを満たす貴重なドキュメント。公開してくれているメンテナに感謝しつつ、ライセンス条件を守って活用していきたい。

本記事で言及したガイドラインの出典は以下のとおり。