はじめに こんにちは。バンダイナムネクサス データ戦略部の山野です。 今回は、Google Cloudのサービスを活用してエンジニア向けの開発環境を刷新した事例をご紹介します。私たちの課題と、それをどう解決したかについて、具体的なポイントを深掘りしていきます。 経緯と背景 エンジニア向けの開発環境を、ユーザーと管理者の両方にとってより使いやすく、効率的にしたいという要望がありました。そのため、以下の点に注目して改善を試みました。 マネージドサービスを活用した運用の効率化： 弊チームでは、これまでエンジニア向けの開発環境としてVM環境を提供してきました。しかし、運用コストの増

はじめに こんにちは。 開発本部 開発1部 デリッシュリサーチでデータエンジニアをしている吉田です。 今回は、DatabricksのUnity Catalog管理下のテーブルを、自然言語で検索できるClaude Codeスキルを構築した話を紹介します。 背景 以前の記事 では、Databricks Managed MCP Serverを通してUnity Catalog Functionを実行することでテーブルのスキーマ情報を取得する方法を紹介しました。 この仕組みは便利でしたが、テーブルのパスを把握していることが前提でした。 しかし実際の運用では｢あのデータはどのテーブルだっけ？｣というケースが多く、テーブルがわからない状態から対象のテーブルを探したいというニーズがありました。 そこで今回は、社内で活用が進んでいるClaude Codeのスキルとして、自然言語でテーブルを検索するスキルを作成します。 スキルの概要 スキルの動作フローは以下のようになります。 ユーザが質問 : ｢アプリの動画視聴ログはどこ？｣ Claude CodeがSkillを起動 質問文からLLMが文脈に応じてキーワードを抽出 : アプリ/動画/視聴/app/search など scriptを利用して検索SQLを作成 Databricks DBSQL MCPを使ってsystemテーブルに対してクエリを発行 結果を受け取り解釈、イマイチな場合、キーワードを変えて再検索 Claude Codeが回答 : ｢最有力候補は以下です。その他候補は ~ です｣ アプローチとしてテーブル情報をVector Searchすることも考えましたが、今回は簡単な手法を選択しました。 Databricks Managed MCPの活用 今回のスキルでは、Databricksが提供するManaged MCP ServerのDBSQLを利用しています。 https://docs.databricks.com/gcp/ja/generative-ai/mcp/managed-mcp 以前の記事ではUnity Catalog FunctionsのMCP Serverを使い、事前に定義した関数を呼び出すアプローチでした。 今回は任意のクエリを実行できるDBSQLのMCP Serverを使い、SQLを直接実行するアプローチを取っています。 DBSQL MCPでは以下のツールを提供しています。 execute_sql 任意クエリの実行ツール execute_sql_read_only Select,Showなど読み取りクエリの実行ツール poll_sql_result 長時間実行されるクエリの結果を取得するツール execute_sql ツールは、 Delete , Drop などの危険なクエリを発行できるため、必要に応じて利用制限を行うのが良いです。 // settings.json { " permissions ": { " deny ": [ " mcp__<mcp_name>__execute_sql " ] } } DBSQL MCPは標準で提供されており、すぐに利用する事ができます。 systemテーブルによるメタデータ検索 Databricksの system.information_schema にはカタログ配下のオブジェクトに関するメタデータが保存されています。 https://docs.databricks.com/aws/ja/sql/language-manual/sql-ref-information-schema 主に system.information_schema.tables を利用してテーブル名やコメント名に対してLIKE検索を行うことでテーブルを探しています。 SELECT table_catalog, table_schema, table_name FROM system.information_schema.tables WHERE LOWER (table_name) LIKE ' %<keyword1>% ' OR LOWER ( comment ) LIKE ' %<keyword1>% ' Claude Codeスキルとして実装 スキルの構成 Claude Codeのスキルは SKILL.md というファイルで定義します。 今回のスキルのディレクトリ構成は以下のとおりです。 ~/.claude/skills/<skill-name>/ ├── SKILL.md # スキル定義 └── scripts/ ├── _common.py # 共通ユーティリティ ├── gen_search_table_query.py # テーブル検索（基本） ├── gen_get_columns_query.py # カラム情報取得 └── gen_get_sample_data_query.py # サンプルデータ取得 SKILL.mdのfrontmatterで、スキルが使用できるツールを制限しています。 --- name : <skill-name> description : Databricks Unity Catalogのテーブル検索スキル。 context : fork allowed-tools : - Bash - mcp__databricks-sql-mcp__execute_sql_read_only - mcp__databricks-sql-mcp__poll_sql_result --- context: fork スキルを独立したサブプロセスで実行し、メインの会話コンテキストを汚さない allowed-tools Bashに加え、読み取り専用のMCPツールのみを許可 SKILL.md の本文にはワークフロー（検索の手順）や出力ルール（最有力候補1件＋その他最大4件に絞り込む等）を記述しており、Claude Codeはこの指示に従ってSQLを生成・実行します。 sqlglotによるSQL生成 SQLは sqlglot ライブラリを利用したpythonスクリプトで生成しています。 https://sqlglot.com/sqlglot.html プロンプトでSQLの生成をAgentに任せる方法と比べて、確実に目的のクエリを作成することができます。 SKILL.md中に以下のようなコマンドを指示することでSQLを作成しています。 uv run --no-project --with sqlglot scripts/<スクリプト名>.py <パラメータ> sqlglotでのクエリ生成は以下のようにして行っています。 gen_search_table_query.py,_common.pyから抜粋 # gen_search_table_query.py from sqlglot import exp, select from _common import like_or def build_query (keywords: list [ str ]) -> exp.Expression: return ( select( "table_catalog" , "table_schema" , "table_name" , "comment" ) .from_( "system.information_schema.tables" ) .where(like_or([( "table_name" , None ), ( "comment" , None )], keywords)) ) # _common.py def like_or ( columns: list [ tuple [ str , str | None ]], keywords: list [ str ] ) -> exp.Expression: """Build OR chain: LOWER(col) LIKE '%kw%' for each (column, keyword) pair.""" conditions = [ exp.Like( this=exp.Lower( this=exp.Column( this=exp.to_identifier(col), table=exp.to_identifier(tbl) if tbl else None , ) ), expression=exp.Literal.string(f "%{kw}%" ), ) for kw in keywords for col, tbl in columns ] return reduce ( lambda a, b: exp.Or(this=a, expression=b), conditions) 検索精度とデータカタログの重要性 今回のスキルの検索精度は、テーブルやスキーマに付与されたコメントの充実度に強く依存します。 テーブル名とコメントをLIKEで検索するため、コメントが空のテーブルはテーブル名のみでしかマッチしません。 十分な結果が得られなかった場合はサンプルデータの取得や別キーワードでの再検索など探索的にテーブルを探しますが、判断材料としてコメントは非常に重要です。 データカタログの育成こそが、データ活用全体の効率化につながると考えています。 まとめ Databricks Managed MCP ServerのDBSQLとsystemテーブルを組み合わせることで、Unity Catalogのテーブルを自然言語で探索できるClaude Codeスキルを構築しました。

はじめに PSSLの佐々木です。 AIコーディングアシスタントの進化により、テストコードの自動生成が身近になりました。しかし、ここに大きな落とし穴があります。 AIが実装コードを見ながらテストを書くと、実装のロジックをそのままテストにコピーしてしまう ので仕様の不具合に気づくことができません。 これを「トートロジカルテスト（同義反復テスト）」と呼びます。 // 実装コード function calculateTax(price: number): number { return Math.floor(price * 0.1); } // AIが生成した"テスト"（実装を見て書いた場合） it('税額を計算する', () => { const price = 1000; const expected = Math.floor(price * 0.1); // 実装と同じロジック！ expect(calculateTax(price)).toBe(expected); }); このテストは 常に成功 します。なぜなら、実装が間違っていてもテストも同じ間違いをするからです。カバレッジは100%でも、バグは検出できません。 解決策：AIに実装コードを「見せない」 この問題を解決するため、 仕様書のみを参照してテストを生成する ワークフローを構築しました。 Claude Codeのエージェント機能を使い、 テスト生成エージェントには Read ツールを与えない という技術的制約を設けます。 # .claude/agents/test-generator.md --- name: test-generator description: 仕様書のみに基づいてテストを生成する tools: Write, Bash # Readがない = 実装コードを読めない --- これにより、AIは仕様書（ spec.md ）だけを頼りにテストを書くしかなくなります。 アーキテクチャ全体像 specs/features/{feature}/ ├── spec.md # 仕様書（Given/When/Then形式） └── plan.md # 実装計画 ↓ 並列実行 ┌─────────────────┐ ┌─────────────────┐ │ implementer │ │ test-generator │ │ (tools: 全て) │ │ (tools: Write, │ │ │ │ Bash) │ │ 実装コードを │ │ 仕様書のみ参照 │ │ 自由に読み書き │ │ src/は読めない │ └────────┬────────┘ └────────┬────────┘ │ │ ▼ ▼ src/lib/*.ts src/lib/*.test.ts src/app/**/* e2e/*.spec.ts 仕様書のフォーマット テスト生成の精度を上げるため、仕様書は Given/When/Then形式 で記述します。 ## 受け入れ条件 ### AC-01: 定額割引の適用 - Given: 価格1000円の商品がある - When: クーポンコード「SAVE100」を適用する - Then: 割引後価格は900円になる ### AC-02: パーセント割引の適用 - Given: 価格2000円の商品がある - When: クーポンコード「OFF10」（10%割引）を適用する - Then: 割引後価格は1800円になる この形式により、AIはテストケースを正確に生成できます。 核心となるルール：仕様整合ルール テストが失敗した場合、 どちらを修正するか という判断が重要です。 私たちは「 仕様整合ルール 」を採用しました： テストが失敗し、かつテストが仕様書と整合している場合、 実装を修正する （テストを修正しない） # .claude/rules/src-lib.md ## 仕様整合ルール（Spec-aligned Rule） テスト失敗時の対応: 1. テストが仕様書（spec.md）と整合しているか確認 2. 整合している → 実装を修正 3. 整合していない → テストを修正 これにより、仕様書が「信頼できる唯一の情報源（Single Source of Truth）」として機能します。 実際のワークフロー Step 1: 仕様書を作成 # specs/features/discount-calculator/spec.md ## 概要 クーポンコードを適用して割引価格を計算する機能 ## 受け入れ条件 ### AC-01: 定額割引 - Given: 価格1000円 - When: SAVE100を適用 - Then: 割引後900円 ### AC-04: 無効なクーポン - Given: 価格1000円 - When: INVALIDを適用 - Then: エラー「無効なクーポンコードです」 Step 2: 並列エージェントを実行 # 2つのエージェントを同時に起動 claude --agent implementer "specs/features/discount-calculator/plan.mdに基づいて実装" claude --agent test-generator "specs/features/discount-calculator/spec.mdに基づいてテスト生成" Step 3: テストを実行して結果を確認 npm run test:run npx playwright test Step 4: 失敗があれば仕様整合ルールに従って修正 実際のプロジェクトでは、以下のような失敗がありました： FAIL src/lib/discount.test.ts ✕ SAVE100で100円割引が適用される Expected: 100 Received: 0 テストは仕様書通り「100円割引」を期待しています。実装側のバグなので、実装を修正しました。 GitHub Actions での自動化 CI/CDパイプラインで品質を担保します： # .github/workflows/ci.yml jobs: test: steps: - name: Type check run: npx tsc --noEmit - name: Run unit tests run: npm run test:run - name: Run unit tests with coverage run: npm run test:coverage e2e: steps: - name: Run E2E tests run: npx playwright test さらに、ミューテーションテストで「テストの質」も検証します： # .github/workflows/mutation.yml - name: Run mutation tests run: npm run test:mutation # Stryker 技術スタック 用途 ツール フレームワーク Next.js 15 (App Router) 単体テスト Vitest E2Eテスト Playwright ミューテーションテスト Stryker AIエージェント Claude Code 得られた効果 1. テストが仕様の検証になる 実装を見ずに書かれたテストは、「仕様通りに動くか」を純粋に検証します。 2. バグが確実に検出される 実際に3件の実装バグがテストで検出されました： 割引額の計算ミス クーポン情報の返却漏れ 0円時の割引処理 3. リファクタリングが安全になる テストが仕様に基づいているため、内部実装を変更しても「振る舞いが変わっていないこと」を確認できます。 注意点とトレードオフ 仕様書のメンテナンスコスト 仕様書が古くなると、テストと実装が乖離します。仕様変更時は必ず spec.md を更新する運用が必要です。 E2Eテストのセレクター問題 仕様書だけではDOM構造がわからないため、E2Eテストでは data-testid の命名規則を事前に決めておく必要があります。 # 仕様書に記載 ## UI要素のTestID - 価格入力: `data-testid="price-input"` - 計算ボタン: `data-testid="calculate-button"` - 結果表示: `data-testid="discounted-price"` 初期設定の手間 エージェント設定、ルール定義など初期構築には時間がかかります。ただし、一度作れば再利用可能なテンプレートになります。 まとめ AIによるテスト生成の最大の罠は、「実装を見てテストを書く」ことです。 これを防ぐため： テスト生成エージェントから Read ツールを剥奪 仕様書（Given/When/Then）を信頼できる情報源に 仕様整合ルールでテスト失敗時の判断を明確化 このワークフローにより、AIが生成するテストは「実装の複製」ではなく「仕様の検証」になります。 テンプレートはGitHubで公開しています。ぜひ活用してください。 https://github.com/atomic-kanta-sasaki/-claude-test-driven-template ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post AIがテストを書くと「実装をコピーしたテスト」になる問題を解決するテンプレート公開！ first appeared on SIOS Tech Lab .