はじめに
第1回では、IBM BobとMCPを使って「AIが迷わない開発の土台」を組んでみた話を書いた。ルール・カスタムモード・Skills・MCPを整えて、AIが迷わず働けるレールを敷く、という検証だ。
その最後で、こう予告していた。
第2回は、ここで整えた
.bobの設定を、そのままClaude Codeの.claudeに持っていって検証した話を書く予定です。先に結論だけ言うと、設定がほぼそのまま動いた。
この記事は、その検証の続きだ。同じ土台を別のツールに載せ替えると何が起きるのか。実際にどんなSkillsやプロンプトで動かしているのかも含めて、正直に書く。
本記事は筆者個人の検証と見解に基づくものであり、所属組織の公式見解を示すものではありません。特定のツールの優劣を主張するものではなく、同じ設計が別環境でどう動くかを確かめた記録です。
これはシリーズの第2回です。第1回(IBM BobとMCPで土台を組んだ話)を先に読むと、この記事の前提がつかみやすいです。
▼ 第1回はこちら
この記事で話すこと
- 同じ設定を別ツール(Claude Code)に載せ替える検証をした理由
- 移行が拍子抜けするほど簡単だった理由
- 検証して気づいたこと(モデルの挙動と、サブエージェントの自動振り分け)
- 実際に動かしているSkillsとプロンプトの例
なぜ同じ設定を別ツールでも試したのか
第1回で組んだ土台は、特定のツールに依存しない形を意識していた。ルールもSkillsも、特殊な機能ではなくただのMarkdownで書いている。
だとすれば、この設計は本当にツール非依存なのか、別のツールに載せ替えても同じように動くのか、を確かめたくなった。検証としては自然な続きだ。
加えて、第1回で書いた「利用枠の消費」や「指示が曖昧なときの出力のブレ」のような運用上の気づきが、別の環境だとどう変わるのかにも興味があった。そこで、同じ.bobの設定をClaude Codeの.claudeに持っていって動かしてみた、というのがこの記事の流れだ。
移行は拍子抜けするほど簡単だった
ここが第1回の伏線回収になる。
第1回で整えた設定は、その多くがただのMarkdownファイルだ。ルールもSkillsも、特定のツールにロックインされた特殊フォーマットではない。
.bob/
├── rules/ # コア原則・規約(Markdown)
├── skills/ # 作業手順(Markdown)
└── custom_modes # 役割定義
Claude Codeも、考え方は驚くほど近い。
.claude/
├── CLAUDE.md # プロジェクト共通の指示
├── agents/ # サブエージェント(Bobのカスタムモード相当)
└── skills/ # Skills(ほぼそのまま流用)
やったことは、ざっくり言えば.bobの中身を.claudeへ持っていって、ファイルの置き場所と先頭の書式を合わせただけ。ルールの本文やSkillの手順は、ほとんど書き換えずにそのまま動いた。
これは「移行が楽でラッキーだった」という話に留まらない。ワークフローの設計が、特定のツールに縛られていなかったことの確認になった。第1回で「レールを敷く」ことに時間を使った投資が、ツールをまたいでも生きた、というのが検証で一番うれしかった点だ。
「規約や手順を、ツール独自の機能ではなくMarkdownで素直に書いておく」。これが移行コストを下げる地味なコツだと思う。資産がプレーンテキストなら、行き先がどこでも持っていける。
検証して気づいたこと①： モデルの挙動
同じ依頼でも、ツールやモデルが変わると返ってくるものの質感が変わる。
第1回で「曖昧な指示や難しめの設計判断で、想像していた成果物にならないことがあった」と書いた。Claude Codeで同じような頼み方をすると、設計の意図を汲んだ提案が返ってくる場面が増え、手戻りが減る感触があった。
ただし、仕様書を用意して前提を渡す、という工夫はどちらでも有効だ。土台が同じなら、土台がしっかりしていれば、その分の安定感はそのまま効く。エンジンが変わると走りは変わるが、レールが敷いてあること自体の価値は変わらない、というのが正直な印象だった。
検証して気づいたこと②： モードを切り替えなくてよくなった
検証していて一番「お、楽だ」と感じたのはこれだ。
第1回の土台では、コンポーネントを作るときは開発モード、レビューのときはレビューモード、と作業のたびに自分でモードを切り替えていた。地味だが、これが思考の流れを止める。
Claude Codeでは、.claude/agents/に置いたサブエージェントが、それぞれ「自分はいつ呼ばれるべきか」をdescriptionとして持っている。そしてClaudeがその説明を読んで、依頼内容に応じて適切なサブエージェントへ自動で振り分けてくれる。
たとえば、こういう定義をしておく。
---
name: component-dev
description: 新規コンポーネント作成・リファクタリング時に使用。React Aria ComponentsベースのStorybook-Driven TDDを自動実行する。「Buttonコンポーネントを作って」のような依頼で起動する。
tools: Read, Edit, Write, Bash, Glob, Grep, TodoWrite
---
あなたはReact Aria Componentsを使ったStorybook-Driven TDD開発の専門家です。
（以下、第1回のカスタムモードとほぼ同じ手順）
こうしておくと、「Buttonコンポーネントを作って」と素で頼むだけで、開発担当のサブエージェントが起動する。レビューを頼めばレビュー担当が、コミットメッセージを頼めばその担当が動く。自分は「何をしてほしいか」を言うだけで、「どのモードでやるか」を意識しなくてよくなった。
役割ごとに権限を絞る、という第1回の考え方はそのまま。違うのは「切り替えを人がやるか、ツール側がやるか」だけだ。そして、その小さな違いが体験を大きく変えた。
実際に動かしているSkillsとプロンプト
土台として用意しているSkillsは、だいたい次の通り。いずれも第1回からの流用が中心だ。
| Skill | 役割 |
|---|---|
| page-development | ページ単位の一気通貫開発(デザイン分析→各コンポーネント開発→統合→確認→仕様書更新) |
| component-development | Storybook-Driven TDDでコンポーネントを作る |
| coding-standards-review | 規約に沿ったコードレビュー |
| pr-review | PR前のセルフチェックとPR本文の用意 |
| common-migration-advisor | 共通化すべきかの判断 |
プロンプトは、特別な呪文を覚える必要はほとんどない。素直に日本語で頼むのが基本だ。いくつか例を挙げる。
・「一覧ページを作って」
→ ページ開発のSkillが起動し、各パーツの開発まで連れて行ってくれる
・「Buttonコンポーネントを作って」
→ コンポーネント開発のサブエージェントが起動(仕様書確認→Story→テスト→実装)
・「いまの変更をレビューして」
→ レビュー担当が規約・依存・テストの有無をチェック
・「コミットメッセージ作って」
→ 変更内容を読んでConventional Commits形式の日本語メッセージを提案
ポイントは、プロンプトを賢くするより、Skillとサブエージェントのdescriptionを整えておくこと。入口の頼み方がラフでも、振り分け先が手順を持っているので、出力の質が安定する。
実際にページ開発を頼んだときの流れは、だいたいこうなる。
ページ開発を1回頼んだときの流れ(クリックで展開)
依頼: 「一覧ページを作って」
1. Figmaからデザイン情報を取得
2. 仕様書を確認・更新
3. 必要なコンポーネントを洗い出す
→ それぞれcomponent-devへ(Story→テスト→実装)
4. ページに統合
5. ブラウザで表示を確認
6. 主要導線のE2Eを用意
7. 仕様書を現状に合わせて更新
一度の依頼で、ここまでをレールに沿って進めてくれる。
検証して感じた、現実的なところ
良いことばかり書くと嘘くさいので、触ってみて感じた点も正直に書いておく。
「Claude Code＝ターミナル専用」と身構える人がいるかもしれないが、実際にはVS Codeの拡張機能が用意されていて、IBM Bobと同じようにエディタ内のGUIで操作できる。自分も普段はこの拡張機能で使っていて、ターミナルに張り付く必要はない。CLIが苦手でも問題なかった。
- コスト感はどちらでも意識が必要。 モデルが賢いぶん、何も考えず大きく投げれば相応に消費する。「小さく刻む」という第1回の教訓はそのまま生きている。
- 自動振り分けは万能ではない。 たいていは適切な担当に振られるが、依頼が曖昧だと意図とずれることもある。そのときは「レビューだけして、コードは触らないで」のように、ひとこと添えると安定する。
- 優劣の話ではない。 どちらも一長一短があり、相性や好みで選べばいい。今回の検証で確かめたかったのは「どちらが上か」ではなく、「同じ設計が両方で通用するか」のほうだった。そして、それは通用した。
まとめ
- 第1回で組んだ設定(ルール・手順)はプレーンなMarkdown中心だったので、別ツールへほぼそのまま載せ替えられた
- これは「ワークフロー設計がツール非依存だった」ことの確認。土台への投資はツールをまたいで生きる
- 検証で気づいたのは(1)ツール/モデルで応答の質感が変わること、(2)サブエージェントの自動振り分けでモード切替が不要になること
- プロンプトを凝るより、Skillとサブエージェントの
descriptionを整えるほうが効く - ツールはどちらも一長一短。優劣より相性で選べばいい
第1回と通して言いたかったのは、「どのAIツールを使うか」より「AIが迷わない土台をどう設計するか」のほうが、ずっと寿命が長いということだ。ツールは変わる。設計は残る。
ここまで読んでいただきありがとうございました。「うちはこう設計してる」「この設定どうしてる？」など、コメントで気軽に教えてください。