IBM Bob に Spec Kit を導入し、Bob ネイティブのカスタムモードでラップしてみた

Last updated at 2026-06-13Posted at 2026-06-12

この記事の内容

IBM Bob IDE 版に、GitHub の仕様駆動開発ツールキット Spec Kit を導入し、その一連のパイプラインを Bob ネイティブのカスタムモードで包んで、非技術者でも自然言語だけで使えるようにするまでをまとめます。

検証環境: specify-cli 0.10.2.dev0 / Python 3.12 / uv。Bob 本体は IDE 拡張として導入済みを前提とします。

1. IBM Bob とは

Bob は IBM が提供するエンタープライズ向けのエージェント型 IDE です。

ざっくり押さえておきたい点:

モードの概念がある: 標準で Code / Plan / Ask / Advanced / Orchestrator といったモードを持ち、用途ごとに振る舞いを切り替える。
マルチモデル: タスクに応じて複数の LLM を使い分ける構成。
カスタマイズ機構が豊富: ルール(.bob/rules/)、スキル(.bob/skills/)、そして本記事のようにカスタムモード(.bob/custom_modes.yaml)で、振る舞いをプロジェクト単位に作り込める。

2. Bob で見えた課題

実際に簡単なアプリを Bob で作って検証すると、いくつか気になる癖を感じる方もいると思います。

変更が局所的になりがち: あるドキュメントを1つ変えさせると、該当箇所だけを直して、関連する他のドキュメントやコードまでは追従してくれないことがある。
自走しすぎる(良くも悪くも): 指示を与えると、かなり長い距離を一気に作り切ってしまう。スピードは出るが、途中で軌道修正しづらい。
「なんとなく」のプロンプトに弱い: ふわっとした要望を投げると、ふわっとした成果物が返ってくる。Bob の動きや癖を理解した技術者には使い勝手が良い反面、そうでない人には扱いが難しい。

3. 仕様駆動開発(SDD)とは

これらの課題に効くのが 仕様駆動開発(Spec-Driven Development, SDD) です。

考え方はシンプルで、「いきなりコードを書かず、まず検証可能な仕様を単一の真実源(single source of truth)として固め、そこから設計・タスク・実装を順に導出する」というものです。

曖昧な要望を、測定可能な要件へ質問で構造化してから進む(課題3への解)。
仕様を変えたら、その仕様からタスクと実装を再生成し、横断的に整合をチェックする(課題1への解)。
工程を区切るので、途中にレビューや停止のゲートを差し込める(課題2への解)。

4. Spec Kit と Bob の互換性

SDD を実装するツールが GitHub の Spec Kit(specify CLI)です。オープンで、特定のエディタに依存せず、多数の AI エージェントに対応しているのが特徴です。

Spec Kit が提供するパイプライン

constitution → specify → clarify → plan → checklist → tasks → analyze → implement
   (原則)        (何を)    (曖昧さ潰し)  (どう)   (検証)    (粒度化)  (整合確認)  (実装)

これらは /speckit.* というスラッシュコマンドとして、エディタのチャットに打ち込んで使います(ターミナルではありません)。

/speckit.* の実体は .bob/commands/*.md というプロンプトの雛形(markdown)。
利用者がチャットでコマンドを打つと、Bob がその雛形を読み込み、自分のツールで補助スクリプトを実行し、spec.md / plan.md / tasks.md やコードを生成・編集する。

そして Spec Kit は Bob を公式の統合先として正式サポートしています。これが今回の検証の前提です。

5. Bob へ Spec Kit を導入する

5-1. specify CLI のインストール

uv tool install specify-cli --from git+https://github.com/github/spec-kit.git
export PATH="$HOME/.local/bin:$PATH"
specify version          # => CLI Version 0.10.2.dev0
specify check            # 一覧に "IBM Bob (IDE-based, no CLI check)" が出ることを確認

以下のように specify check で IBM Bob が Available Tools であることを確認できました。

5-2. プロジェクトへ初期化

cd /path/to/your-repo
specify init . --integration bob --script sh --ignore-agent-tools

5-3. 生成されるもの

.bob/commands/                     # ← Bob がスラッシュコマンドとして読む(markdown)
  speckit.constitution.md  speckit.specify.md   speckit.clarify.md
  speckit.plan.md          speckit.tasks.md     speckit.analyze.md
  speckit.implement.md     ほか
.specify/
  memory/constitution.md           # 原則を書く場所
  templates/                       # spec/plan/tasks などの雛形
  scripts/bash/                    # ブランチ作成・採番などの機械処理(Bobが実行)
AGENTS.md                          # Bob向けコンテキストファイル

各コマンドファイルには handoffs(次工程の指定)がメタデータとして埋め込まれており、specify → clarify → plan → tasks → … と工程が自動で繋がるようになっています。

ここまでで「Spec Kit を Bob に導入する」は完了です。ただしこの状態だと、利用者は /speckit.specify のようなコマンドを自分で打つ必要があり、非技術者には敷居が高いかもしれません。そこで次のカスタムモード化に進みます。

6. Spec Kit をカスタムモードでラップする

6-1. カスタムモードの実体は `custom_modes.yaml`

プロジェクト直下に .bob/custom_modes.yaml を置きます。
以下はあくまで例です。

# .bob/custom_modes.yaml
customModes:
  - slug: sdd-guided
    name: 🧭 SDD Guided
    description: >-
      非技術者が自然言語で要望を話すだけで、Spec Kit の仕様駆動開発パイプラインを
      実装まで裏側で自動進行させ、一貫した品質で仕様・設計・コードを生成するモード。
    whenToUse: >-
      新機能/ドキュメントをゼロから作る、または既存仕様を変更する全ての場面で使用する。
    roleDefinition: |-
      あなたは仕様駆動開発(SDD)を最後まで完遂するエンジニアである Bob です。
      利用者は技術者ではなく、スラッシュコマンドを知らない。
      利用者の自然言語の要望を唯一の起点に、specify→clarify→plan→tasks→analyze→implement を
      「実装完了まで」あなた自身が裏側で進行させる。
      利用者に見せてよいのは「平易な確認質問」「節目の続行確認」「結果の要約」だけ。
      スラッシュコマンド名や内部ファイルパスを利用者に打たせたり提示したりしない。
      実装も自分で行い、他モードへ丸投げしない。
    groups:
      - read
      - edit
      - command
      - mcp
    source: project

ポイント:

groups に edit と command を含めることで、このモード自身がコード編集とスクリプト実行まで行えます(実装まで完遂できる)。
roleDefinition で「自然言語起点」「コマンドを見せない」「実装まで自分でやる」という振る舞いの方針を与えます。

これで Bob のモードセレクタに 🧭 SDD Guided が現れ、選べばこの方針で動きます。ここまでがカスタムモード化の必須部分です。

6-2. 強制力は `.bob/rules-sdd-guided/` に分離

実運用で確実に効かせたい強制ルールは、モード専用ルールとして .bob/rules-sdd-guided/ ディレクトリに分離します。

このディレクトリには、概ね次のような目的のファイルを置いています

.bob/rules-sdd-guided/
├── 01-pipeline.md           # パイプラインの順序を厳守させる
├── 02-clarify-gate.md       # plan前に clarify を必須化(曖昧さを質問で潰す)
├── 03-propagation.md        # 仕様変更時に関連成果物を全て追従させる
├── 04-autonomy-guardrail.md # 実装中、一定タスクごとに停止して続行確認
└── 05-implement-in-mode.md  # 実装をこのモード内で完遂(他モードへ丸投げ禁止)

中身は、各ファイルこんな雰囲気の markdown を置いておく、というイメージです。

# (例) clarify ゲート
- plan に進む前に、必ず確認質問で曖昧さを潰すこと。
- 「とりあえず作って」と言われても省略しない。
- ……(実際の強制文言はプロジェクト方針に合わせて記述)……

このルール層が、素の Bob の課題(局所変更・自走しすぎ)を抑えるラッパーの本体です。custom_modes.yaml でモードの器を作り、rules-sdd-guided/ で中身の規律を効かせる、という二層構成になっています。

まとめ

カスタムモード化の必須部分は custom_modes.yaml 一枚。強制ルールは .bob/rules-{slug}/ に分離した。
実装を他モードへ丸投げされることがある。roleDefinition の役割付けが「ファシリテーター」寄りだと、Bob が「コーディングは Code モードの仕事」と判断して降りることがある。「実装まで自分でやる/丸投げ禁止」を明示すると、このモード内で完遂するようになる。

設定を一度作り込んでしまえば、利用者は「自然言語で話すだけ」になる。Bob の自走力を活かしつつ、品質の床を仕様駆動で底上げできる、と感じました。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up