Claude Codeで要件シートからデータ基盤の全体像を生成するSkillを作ってみた

データ基盤の案件で要件をまとめるのに時間がかかる課題を解決するため、要件シートの回答からデータ基盤の全体像を HTML で自動生成する Skill を作って試してみました。
2026.11.03
 はじめにデータ事業本部のkasamaです。

今回は要件シートの回答から、データ基盤の全体像を HTML にまとめる Skill を作って試してみたので紹介します。データ基盤の案件では、要件を決めてから構成や進め方を考えるまでに時間がかかります。この Skill は画面のイメージ・構成図・テーブルの構成・進め方・次にやることを HTML 1 ファイルにまとめ、構築を始める前に関係者と全体像を確かめられるようにします。
 前提Claude Code がインストール済みであること
macOS で Homebrew を使えること
draw.io のデスクトップアプリ・uv・公式の drawio skill を使うこと
 アーキテクチャデータ基盤を計画するときは、毎回同じ項目を決める必要があります。決めたいこと・使いたいデータの置き場所と件数・データの鮮度・既存のクラウドと BI ツールなどです。この Skill ではこれらの項目をシートに記入し、回答からデータ基盤の全体像を作ります。シートは自分で記入しても、データを使う部署の人に記入してもらってもかまいません。
使い方は次の 3 手順です。
要件シートをブラウザで開いて入力し、「回答を保存」を押す。回答を JSON で埋め込んだ HTML がダウンロードされる
/data-platform-overview {記入済みの HTML のパス} を実行すると、Claude Code が HTML から回答の JSON を読む
Claude Code が回答から全体像の HTML を 1 ファイルで書き出す。回答のテキストには HTML のパスと判断が要ることだけを書き、HTML の内容は繰り返さない
構成は推奨案と代替案を各社の設計の指針で比べ、案で使う製品の仕様を公式ドキュメントで確認します。AWS は AWS Knowledge MCP サーバー、dbt は dbt MCP サーバー、Snowflake と Databricks は WebFetch で読みます。実際に動かしたときの手順や制約は DevelopersIO の記事で確かめます。
 実装実装コードはGitHubに格納しています。
https://github.com/cm-yoshikikasama/blog_code/tree/main/75_data_platform_overview_skill
75_data_platform_overview_skill/
├── .mcp.json                              # AWS Knowledge MCP と dbt MCP の設定
├── README.md
└── .claude/skills/data-platform-overview/
    ├── SKILL.md
    ├── references/
    │   ├── answer-mapping-guide.md        # 回答の使い方と取り込みの選び方
    │   ├── architecture-sources-guide.md  # 構成の根拠を確かめる手段
    │   └── overview-style.md              # 全体像の HTML の書き方
    └── templates/
        ├── requirements-sheet.html        # 要件シート
        └── overview-page.html             # 全体像の HTML の枠と CSS
 MCP サーバーの設定https://github.com/cm-yoshikikasama/blog_code/blob/main/75_data_platform_overview_skill/.mcp.json
公式ドキュメントを読むための MCP サーバーの設定です。AWS Knowledge MCP サーバーと dbt MCP サーバーは、どちらも認証情報なしで使えます。dbt MCP サーバーは環境変数 DBT_MCP_ENABLE_TOOLS で、ドキュメントを検索するツールだけに絞っています。
 Skillshttps://github.com/cm-yoshikikasama/blog_code/blob/main/75_data_platform_overview_skill/.claude/skills/data-platform-overview/SKILL.md
Skill の手順です。判断基準は references/ の 3 ファイルに分け、各手順でどのファイルを読むかを指定しています。disable-model-invocation: true で、Claude Code が会話の流れから Skill を自動で呼び出さないようにしています。
https://github.com/cm-yoshikikasama/blog_code/blob/main/75_data_platform_overview_skill/.claude/skills/data-platform-overview/references/answer-mapping-guide.md
シートの質問ごとに、どの判断に使うかを決めた対応表です。たとえば「出力される範囲」が「毎回すべてのデータ」なら洗い替え、「変わった分だけ」なら差分の反映にします。表にない回答は根拠に使わず、空欄・「不明」・回答どうしの食い違いは推測で埋めずに「次にやること」に回します。
取り込みと読み込みは、回答から方式（1 日 1 回の差分・CDC・手作業のファイルなど）を決めてから製品を選びます。製品名はサービスの追加や名前の変更で変わるため書きません。DWH が持つ機能・同じクラウドのマネージドサービス・短いコードの順に、実行した日の公式ドキュメントで探します。
https://github.com/cm-yoshikikasama/blog_code/blob/main/75_data_platform_overview_skill/.claude/skills/data-platform-overview/references/architecture-sources-guide.md
構成の根拠を確かめる資料と手段の一覧です。モデルが学習した時点の情報は古いことがあるため、実行した日の日付を取得し、直近 3 か月のリリースノートで名前の変更や提供状況の変化を確かめます。そのうえで選んだ構成の制約（提供状況・東京リージョンで使えるか・エディションの要件）を公式ドキュメントで確かめ、出典に URL と確認日を付けます。
https://github.com/cm-yoshikikasama/blog_code/blob/main/75_data_platform_overview_skill/.claude/skills/data-platform-overview/references/overview-style.md
全体像の HTML の節ごとの書き方です。構成図は公式の drawio skill で描き、AWS と Google Cloud は draw.io に入っている公式のアイコンを使います。draw.io にアイコンがない Snowflake や dbt はロゴの画像を使わずに汎用の線のアイコンで描きます。グラフ・テーブルの関係図・ガントチャートは draw.io を使わずに HTML の中に描き、費用の金額は書きません。
https://github.com/cm-yoshikikasama/blog_code/blob/main/75_data_platform_overview_skill/.claude/skills/data-platform-overview/templates/overview-page.html
全体像の HTML の枠です。CSS と節の見出しはこのファイルで決めてあり、Claude Code は {{...}} の部分だけを書き換えます。実行ごとに見た目と節の並びが変わらないようにするためです。
https://github.com/cm-yoshikikasama/blog_code/blob/main/75_data_platform_overview_skill/.claude/skills/data-platform-overview/templates/requirements-sheet.html
ブラウザで入力する要件シートです。「回答を保存」を押すと、回答を JSON にしてファイルの中に埋め込み、HTML をダウンロードします。サーバーを用意せずに回答を受け渡しでき、保存したファイルを開き直すと回答が入力欄に戻ります。
要件シートと全体像の HTML は外部と通信せず、回答はダウンロードした HTML の中にだけ保存されます。Content-Security-Policy の <meta> タグで、HTML から外部への接続をブラウザに禁止させています。
この要件シートは、この記事のために作った例です。実際のプロジェクトで使っているシートとは別に作ったものなので、質問の内容は参考程度に見てください。
 試してみた セットアップdraw.io のデスクトップアプリと uv をインストールします。draw.io のデスクトップアプリは構成図の .drawio を drawio コマンドで PNG に書き出すために使います。uv は dbt MCP サーバーを uvx で起動するために使います。
brew install --cask drawio
brew install uv
次に draw.io 公式の drawio skill をインストールします。drawio skill は draw.io の開発元の jgraph が GitHub で公開しており、リポジトリが Claude Code の plugin の marketplace を兼ねています。Claude Code を起動して次の 2 つのコマンドを実行します。
https://github.com/jgraph/drawio-mcp
/plugin marketplace add jgraph/drawio-mcp
/plugin install drawio@drawio
最後にこの記事のリポジトリを clone し、75_data_platform_overview_skill で Claude Code を起動します。.claude/skills/data-platform-overview/ の Skill と .mcp.json の MCP サーバーはこのディレクトリで起動したときに読み込まれます。起動時に .mcp.json のサーバーを使うかどうかを聞かれるので、許可します。
git clone https://github.com/cm-yoshikikasama/blog_code.git
cd blog_code/75_data_platform_overview_skill
claude
 回答を入力して保存するここからはテスト用の回答で試します。店舗名・数値はすべてダミーです。
templates/requirements-sheet.html をブラウザで開き、テスト用の回答を入力しました。見る人は営業企画部と店舗の責任者の 50 名で、毎週月曜に店舗別の売上と目標の差を見てテコ入れする店舗を決める内容です。
Q2 には販売管理・POS と EC サイトの DB、人事・勤怠の SaaS、予算・目標の Excel の 4 行を入れました。販売管理・POS は SQL Server で、出力される範囲は「変わった分だけ」、変わった行を見分ける列は「更新日時の列がある」にしています。予算・目標は置き場所を「不明」、データの単位を「月ごと」にしました。
Q4 では DWH に Snowflake を「導入を検討中」とし、データ基盤に接続できる場所は「社内のネットワークからだけ許す」、社内とクラウドをつなぐ経路は「VPN がある」を選びました。
「回答を保存」を押すと、プロジェクト名と保存した日時を名前に付けた 要件シート_{プロジェクト名}_{日付}_{時刻}.html がダウンロードされました。このファイルをもう一度ブラウザで開くと、4 行の回答と選択した値が入力欄に戻ります。
 全体像の HTML を作る記入済みの HTML のパスを引数にして Skill を実行します。
/data-platform-overview ~/Downloads/要件シート_店舗売上の分析_20261103_0840.html
実行には 15 分 40 秒かかりました。Claude Code は公式ドキュメントで構成の制約を確かめ、drawio skill で構成図を描き、Chrome で表示を確かめてから HTML を書き出します。最後の応答は次のとおりです。
全体像の HTML を作りました。上部に「ダミーデータです」を表示しており、Q 番号はページにありません。

- 全体像の HTML: ~/Downloads/全体像_店舗売上の分析_20261103.html

## 判断が要ること

- Snowflake のリリースノートは 2026 年 10〜11 月の分しか読めていません。8〜9 月の分は見つからず、手順の決まりで探すのを打ち切りました。製品名の変更や一般提供への変更がないかの確認はその 2 か月分が抜けています。
- Snowflake Intelligence が一般提供か、どのリージョンで使えるかは公式ドキュメントで確かめられませんでした。このため理由の表には書かず、次にやることの 4 番目に入れました。
- 構成図の PNG は縮小せずに埋め込んでいるので、ページ上では横にスクロールして見ます。

## 分かったこと

- Snowflake 自身の SQL Server と MySQL のコネクタは、元の DB の設定変更を前提にしています。
  - SQL Server のコネクタは、DB とテーブルで変更追跡を有効にする必要があります。
  - MySQL のコネクタは、binlog を行の形式で出す設定と、テーブルごとの複製用のキーが要ります。
  - シートの回答にはこれらの変更がないので、販売管理と EC サイトの取り込みには AWS Glue の JDBC ジョブを選びました。
- dbt Projects on Snowflake をタスクで動かすときは、サーバーレスのタスクを使えません。ユーザーが管理するウェアハウスを指定する必要があります。
書き出されたファイルは、要件シートと同じフォルダにある次の 2 つです。
全体像_店舗売上の分析_20261103.html   # 全体像の HTML（構成図の PNG を埋め込んだ 1 ファイル）
構成図_店舗売上の分析.drawio           # 構成図の元ファイル
以下は全体像の HTML の中身です。冒頭には、このページの使い方と前提にした回答が並びます。前提にした回答の欄には、構成を決めるのに使った内容が書かれています。
画面のイメージには、数値のタイル・店舗別の目標との差のグラフ・全店の売上と目標の推移のグラフ・AI チャットの例が記載されています。数値はすべてダミーです。
構成図では、既存の VPN を通して AWS Glue のジョブが SQL Server から更新日時の列で差分を取り出し、Snowflake のタスクが読み込みと変換を動かします。Skill は取り込みの製品を Snowflake 自身の機能から先に探します。Snowflake にも SQL Server から直接取り込む機能（Openflow）があり、使うには元の DB で変更追跡を有効にします。有効にできるかは回答から分からないため、回答のまま動く AWS Glue が選ばれました。Openflow は、変更追跡を有効にできる場合の案として「この構成を選んだ理由」の選ばなかった案に入っています。
テーブルの構成には、RAW・STAGING・MART の関係図・テーブルごとの更新の方法と理由・ロールごとに読めるテーブルが並びました。店舗の責任者に自分の店舗だけを見せるかは回答から決まらないので、「未定」になっています。
「この構成を選んだ理由」には、決めたことごとに選んだ理由と選ばなかった案、確かめた公式ドキュメントが記載されています。
進め方と期間の例は、要件の確認から本番への展開までの工程です。担当はデータを使う部署・データ基盤の担当・情報システム部門の役割で書かれています。
次にやることには、決まっていないことが順番に並び、決める人と決まると進められる工程が付きました。
 最後に今回は要件シートの回答から、データ基盤の全体像を HTML にまとめる Skill を作って試してみました。画面・構成・テーブル・進め方をまとめて見られるため、作りたいものの全体像を早い段階で関係者と共有して概要を掴むことができます。この HTML はプロジェクトとアーキテクチャの概要をつかむためのもので、この構成で構築して良いことを保証するものでは決してありません。アーキテクチャの実現性やCI/CD・権限管理・セキュリティなど構築の前に検討する点はほかにも多いため、実際に構築するときは参考の 1 つとして使ってください。どなたかの参考になれば幸いです。