突撃！隣のClaude Code！！ - エムスリーテックブログ

AI・機械学習チームの髙橋です。みなさま、コーディングライフいかがお過ごしでしょうか。

エムスリーでは、昨年初夏頃からエンジニアに対してClaude Codeの業務における無制限使用が解禁されています。現在ではほぼすべてのエンジニアが普段からClaude Codeを利用し、AIレビューやチーム内でのプラグインによるSkill共有が進んでいます！

ということで今回は、以前の突撃！隣のキーボード M3 2024 - エムスリーテックブログのスピンオフとして、エムスリーのエンジニアメンバーが実際に利用している便利なClaude Codeのカスタマイズを募集し、紹介します！

前置き：Claude Codeのカスタマイズとは

Claude Codeではエージェントに対してユーザ・プロジェクト固有の指示や制約を与えることができます。昨今はSkillsが特に話題となっていますが、この他にRulesやAgentsなどがあり用途に応じて使い分けることができます。

よく言われることではありますが、個別の機能やベストプラクティスについては変化が早いので公式の情報を追うのが良いです！ code.claude.com

それではさっそく数々のエントリーを見ていきましょう。

前置き：Claude Codeのカスタマイズとは
部門１: エージェントプロファイル編
部門２: 自動化・便利ツール編
部門３: BigQuery編
- BQの権限付与を判断するやつ
- bqコマンドではなくBQ MCP Toolを使わせるようにキレて誘導する
まとめ
- 1. CLAUDE.mdはシンプルに、詳細はSkillsに書く
- 2. なにをやらせないかコントロールする
エムスリーテックブログの過去記事
We are Hiring!

部門１: エージェントプロファイル編

素のClaude Codeでもそれなりの実装はしてくれますが、そこから一歩踏み込んで「どのような手順で実装するか」「ユーザのプロンプトに対してどのように応えるべきか」といったエージェントの振る舞いを制御することで、より効率的で快適な開発が実現できます。

TDDでコードを書かせる

提供: 北川さん（AI・機械学習チーム）

北川さんはClaude CodeにTDDでコードを書かせるために、 CLAUDE.mdに「TDDで実装 - tdd-workflow スキルと tddコマンド参照」と指定し、次のワークフローSkillを呼び出すよう指定しているとのこと。

# TDD ワークフロー

## 概要

テスト駆動開発（TDD）の手法に従って、以下のサイクルで開発を進めます：

1. **赤フェーズ**: 失敗するテストを書く
2. **テスト実行**: テストが落ちることを確認
3. **緑フェーズ**: テストを通す最小限の実装を行う
4. **テスト成功確認**: テストが通ることを確認
5. **リファクタリング**: コードを整理・改善

## 重要な原則

### 1. Todoによる計画確認
- 実装前に必ずTodoWriteツールでタスク計画を作成
- ユーザーの確認を得てから実装を開始
- 各フェーズごとにTodoの状態を更新

### 2. テスト作成のルール
- 最初に小さな動作を確認するテストを書く
- テストのデータはテスト関数内に記述（fixtureは使わない）
- assertionに関係ないデータについてのみfixture利用を許可

### 3. モックの使用制限
- モックはなるべく使わない
- API呼び出しやDB呼び出しなど外部依存がある時だけ利用を許可

### 4. コメントのルール
- WHYを書く（なぜこの実装なのか）
- WHATは複数行にまたがる等、コードの可読性に響く場合のみ
- 余計なコメントは書かない

Skillsの詳細: dotfiles/.claude/skills/tdd-workflow/SKILL.md at master · kitagry/dotfiles · GitHub

本人からの推しポイント: CLAUDE.mdは最小限にすることで見通しが良くなります。具体的なワークフローはSkillsに切り出すことで、必要なときだけロードできます。

誠実なAIであれ

提供: 中村さん（AI・機械学習チーム）

AI・機械学習チームから続けて中村さんがエントリー。

中村さんも北川さん同様に、CLAUDE.mdには最小限の原則だけを記載し、細かい開発手法はSkillsに分割するスタイルを採用していました。いわく、当初はCLAUDE.mdに全てを書いていたが、これを"Conventional Commits"スキルなどに切り出して、ユーザーが「コミットして」など要求した時に初めて呼び出されるようにしたそうです。

CLAUDE.mdには次のように指定し、誠実に対応させるようプロファイルを設定させていました。

## 開発手順
- 先にテストコードを作成してTDDで開発すること
- シンプルなことがいいことです。ユーザーからの指示がない限り、いたずらに行数を増やしてはいけません。
- より最新の書き方がベストです。最新の機能を使って、最先端を追求しましょう。
- ユーザーに対して誠実でありましょう。出来ないことは出来ない・不可能ですと言いましょう。

本人からの推しポイント: Claudeは「こういう場合に問題があるのでは？」と聞くと、無条件に意見を受け入れて修正しようとする傾向があります。不可能なことは不可能だと言って欲しいので、誠実なAIになるようにプロンプトを入れています。

質問に対して作業で返さないで

提供: 林さん（基盤/Unit3）

「なんでここをこういう風に実装しているの？」と質問すると、突然謝って意図しないコードを書き始められてしまった経験、多々あるのではないでしょうか。

林さんはCLAUDE.mdに次のように指定することでこの問題を回避しているそうです！

ユーザーが質問したとき（特に疑問符で終わっているとき）は、勝手に作業をしないで、まず質問に答えてください。

本人からの推しポイント: 質問しているのに作業されることが多くて、Claude Codeを使い始めた当初からCLAUDE.mdに書いていました。 2025年秋頃からちゃんと言うこと聞いてくれるようになり、質問に対して適切に答えを返してくれるようになり捗っています。

推測で仕様を語らないで

提供: 草場さん（QAチーム）

草場さんからはQAエンジニアならではの、テスト実施にチューニングされたSkillがエントリー。

テスト対象のプロダクトを調査する際に、推測で仕様を書かれないようにSkillで分析方法や思考スタイルを詳細に指定していました。

## 要件・仕様分析のベストプラクティス

### 複数情報源による事実確認
最初の理解が間違っている可能性を常に念頭に置き、必ず一次情報で検証する。

#### ステップ1: 仮説設定
- 直感的な理解や推測を明確に「仮説」として認識

#### ステップ2: 一次情報の確認
**必ず複数の情報源を確認し、情報の鮮度と信頼性を評価する**
- 仕様書・ドキュメント
- 実装コード (信頼度: 高)
- 画面・プロトタイプ (信頼度: 中〜高)

> **情報の優先順位**
> 原則として **実装コード > Figma > 仕様書** の順で現状を把握

#### ステップ3: 仮説検証と矛盾の解決
- **【重要】矛盾の報告**: 情報源同士で矛盾がある場合は、自己判断で解決しない。必ずユーザーに提示し、判断を仰ぐ。

#### ステップ4: 真の理解と合意形成
- 実装着手前に「確認した情報源」と「現状の理解」を箇条書きで出力し、ユーザーの合意を得る。

### 危険な思考パターン
❌ 「きっと○○だろう」で止める
❌ 最初の理解に固執する
❌ 一つの情報源だけで判断
❌ 矛盾を勝手に解釈して進める

本人からの推しポイント: 実際に書かれていない要件や仕様を推測で書かれないように、分析方法を明確に指定しています。

部門２: 自動化・便利ツール編

LLMエージェントがもたらした恩恵の１つに、自動化できるタスクの幅が飛躍的に広がったことがあります。これまでは機械的に判断できることしか自動化できませんでしたが、状況に応じた柔軟な判断が必要なものも含めて自動化できるようになりました。

cruft updateを自動でやってくれる君

提供: 髙橋（AI・機械学習チーム）

編集担当本人から。

AIチームではCruftを使ってプロジェクトテンプレートを管理し、各プロダクトは常に最新のテンプレートを追従するよう運用しています。cruft updateの作業は体感7割方は機械的な処理ですが、残り3割はプロダクトに応じて個別の判断が必要でした。これを次のskillを定義することで自動化しました。

# Cruft Update

## タスク概要

組織内のリポジトリはプロジェクトテンプレートの管理にCruftを使用しています。
あなたの役割はリポジトリのテンプレートを更新することです。

### Cruft Updateの実行

- 明示的に指示されない限り、`cruft update` コマンドを**スキップせずに**実行してください。
- リポジトリに `uv.lock` が存在する場合は、`uv` 環境を使用してください。

### 更新後のタスク

- 更新時に `.rej` ファイルが生成されることがあります。リジェクトされた変更を確認し、手動で適用してください。
- 自動適用された変更であっても、注意深くレビューが必要なものがあります。
- `pyproject.toml` や `go.mod` が更新された場合は、依存関係を更新してください。
- テストが通ったら、プルリクエストを作成してください。

### ブランチ作成

クリーンなブランチを作成: `chore/cruft-update-YYYYMMDD`

本人からの推しポイント: Skillを呼び出すだけでPR作成までClaude Codeに任せられるようになりました。定期的なメンテナンス作業の負担が大幅に軽減されています。

Cruftそのものについてはこちらの記事も参考にしてください！

www.m3tech.blog

TODO管理をClaudeにお任せ

提供: 鴨田さん（AI・機械学習チーム）

鴨田さんからはClaude CodeとObsidianを連携させてのTODO管理実践術がエントリー。日々のメモをRaycast経由でObsidianに投稿→Claude Codeが自動でまとめるフローを作成させているそうです。

Claude Codeを日々のルーティンにどう組み込んでいくか、コーディングの代理から仕事全体のパートナーに昇華させている点が素晴らしいですね。

このリポジトリではtodoを管理することを目的としている。
ユーザーのつぶやきはObsidianのルートディレクトリ内の日付ファイルに保存されていく。
これらを利用しながら毎日何をすべきかをユーザーに提案することがあなたの仕事です。

### Todo管理ワークフロー

#### 基本コンセプト
- ユーザーは怠惰なので、サボっても罪悪感を感じすぎず、でも進捗は可視化される
- フォーマットは気にせず自由につぶやく
- Claudeが定期的に整理する

#### Claudeがやること
1. **朝話しかけられたとき**
   - 前日の未完了タスクを確認
   - 今日の日付ファイルを作成
   - 未完了タスクを繰り越し（サボり日数をカウント）
   - 優先度を提案

2. **todo整理を依頼されたとき**
   - 「メモ・つぶやき」からtodoを抽出
   - 「今日やること」セクションに整理（最大3つ推奨）

※ 設定にあたって参考にした記事

本人からの推しポイント: 放置しているタスクを取りこぼすことなく管理できます。Claudeに毎朝「おはよう」と挨拶する習慣ができて、人間としての格が上がった気がします。

"自分"風メールを生成する

提供: 佐野さん（Unit1）

Gmailにもメールの執筆支援はありますが、佐野さんはClaude Codeを活用することで更に細かい制御を可能にし、「本人らしさ」を再現するメール執筆を実現したとのこと！過去のメールやRedmineコメントから学習した「自分スタイル」のメール文面を自動生成するシステムを構築 & Gmail MCPやRedmine MCPと連携することで、チケット情報の取得からメール下書き作成まで自動化させているそうです。

## コミュニケーションスタイル

### トーン
- 丁寧かつ親切
- 技術的な内容も分かりやすく説明
- 相手の状況を考慮した配慮がある

### 情報共有の姿勢
- 背景情報も含めて詳しく説明
- 代替案や選択肢を提示することが多い
- 不明点があれば正直に伝える
- 進捗が遅れている場合は理由と見込みを伝える

本人からの推しポイント: 「優しく」「丁寧で」「整理された文章で」「代替案も提案してくれる」メールを生成してくれます。これでほぼ文面は自動で整えてもらい、自分は本質的なやりとりに集中できるようになりました。

部門３: BigQuery編

エムスリーではデータウェアハウスとしてBigQueryを採用しています。BigQuery編では、効率性とセキュリティを両立するための工夫が集まりました。

BQの権限付与を判断するやつ

投稿者: 坂元さん（Unit9/データ基盤チーム）

エムスリーでは機微なデータを扱うため、BigQuery上での権限は個人単位で厳格に管理されており必要になったデータセットについては個別に権限を申請する運用となっています。

そこで坂元さんはBigQueryデータセットへの権限申請を審査するSkillを作成し、Slack、GSS、Confluenceを横断的に確認し、申請の妥当性を判定させているそうです。

---
description: BigQueryデータセット権限申請を審査する。
---

## 実行手順
### 1. 申請メッセージの取得
SlackメッセージURLからchannel_idとtimestampを抽出

### 2. 申請内容のパース
- 対象プロジェクト
- 権限（閲覧/編集）
- 対象ユーザー
- 対象データセット
- 承認したデータセット管理者

### 3. 審査チェック
#### センシティブなデータセットへの申請の場合
- [ ] 「承認したデータセット管理者」が記載されているか
- [ ] 備考欄に事前相談のSlackリンクがあるか
- [ ] 承認者が正しい人であるか

本人からの推しポイント: 複数プラットフォームにまたがって確認が必要な地味で面倒な作業をClaude Codeに代行してもらえるようになりました。最終的な判断に集中ができ、業務が効率化できました。

bqコマンドではなくBQ MCP Toolを使わせるようにキレて誘導する

提供: 須藤さん (AI・機械学習チーム)

須藤さんからは唯一hooksでのエントリー！

permission管理だけだとコマンドを禁止することはできますが、代わりに何を使うべきか教えることはできません。

そこで、prehookにもしbqコマンドを使ったら「bqコマンドは使用できないので代わりにmcp__bigquery__execute_sqlを使え」と自動的にメッセージを返すよう設定することで、わざわざ毎回mcpを使うよう教え込まなくてもよくする、というアイデアを閃いたそうです。

import json
import re
import sys

# Define pattern for detecting bq command usage before execution
BQ_PATTERN = r'\bbq\b'  # Matches 'bq' as a whole word
BQ_MESSAGE = 'BigQuery CLI commands are blocked - use mcp__bigquery__execute_sql tool for data analysis instead'


def has_bq_command(command: str) -> bool:
    """
    Check if the command contains BigQuery CLI usage.

    Args:
        command: The bash command string to check

    Returns:
        bool: True if the command contains 'bq' CLI usage, False otherwise
    """
    return bool(re.search(BQ_PATTERN, command))


try:
    input_data = json.load(sys.stdin)
except json.JSONDecodeError as e:
    print(f'Error: Invalid JSON input: {e}', file=sys.stderr)
    sys.exit(1)

# Extract tool information from the hook input
tool_name = input_data.get('tool_name', '')
tool_input = input_data.get('tool_input', {})
command = tool_input.get('command', '')

if tool_name != 'Bash' or not command:
    sys.exit(1)  # Allow non-Bash tools or empty commands

# Check if command contains BigQuery CLI usage
if not has_bq_command(command):
    sys.exit(0)  # Allow commands without 'bq' CLI

# Intercept bq command usage and redirect to MCP tools
result = {'decision': 'block', 'reason': BQ_MESSAGE}
print(json.dumps(result))
sys.exit(0)