IBM Bobのモードとは〜カスタムモードでTDDを実践

Last updated at 2026-03-20Posted at 2026-03-20

この記事について

IBM Bobは、AI駆動の開発支援ツールとして、様々な開発シーンに対応できる「モード」機能を提供しています。本記事では、Bobを利用される開発者の方向けに、モードの概要やカスタムモードの作成方法について解説します。

本記事の内容は、IBM Bobの社内Early Access版（2026年3月時点）で確認した内容に基づいています。GA版では仕様が変更される可能性がありますのでご注意ください。

Bobにおけるモードとは

IBM Bobには「モード」という機能があります。これは、特定のタスクに合わせて異なる機能とアクセス・レベルを提供し、Bobの動作をカスタマイズするための機能です。

モードを使う理由

モードを使うことで、以下のようなメリットがあります：

タスクの専門化: 現在のタスクに必要な種類のサポートを正確に取得
セキュリティー制御: 計画や学習に集中しているときに意図しないファイル変更を防止
焦点を絞った対話: 現在のアクティビティーに最適化された応答を取得
ワークフローの最適化: 計画、実装、デバッグ、学習の間をシームレスに切り替え

組み込みモード

デフォルトでは、以下のモードがBobで利用可能です：

モード	主な目的	使用するタイミング	ツール・アクセス
💻 Code	コードの作成と変更	機能の実装、バグの修正、コードの改善時	`read`、`edit`、`command`
❓ Ask	情報と説明の取得	変更を加えずに概念を理解したり既存のコードを分析したりする必要がある場合	`read`、`browser`、`mcp`
📝 Plan	計画と設計	実装前にアーキテクチャーを考えたり技術計画を作成したりする必要がある場合	`read`、`edit`（Markdownのみ）、`browser`、`mcp`
🛠️ Advanced	複雑な開発タスク	洗練された開発ワークフローのためにすべてのツールへの完全なアクセスが必要な場合	すべてのツール・グループ
🔀 Orchestrator	多段階プロジェクトの調整	さまざまな専門分野を必要とする複数の可動部分を持つ複雑なプロジェクトがある場合	なし

これらの標準モードに加えて、プロジェクト固有のニーズに合わせた「カスタムモード」を作成できます。

カスタムモード

カスタムモードを作成することで、以下のようなチームやプロジェクト固有のタスクやワークフロー用に、Bobの動作をカスタマイズすることができます：

専門化: ドキュメント作成、テスト・エンジニアリング、セキュリティー・レビューなどの特定のタスク用にモードを最適化
セキュリティー: 機密操作のためにコマンドやファイル・アクセスを制限
チーム・コラボレーション: チーム内で標準化されたワークフローを共有
実験: 他のモードに影響を与えずにさまざまな構成をテスト

カスタムモードの作成方法

モードの構成要素

カスタムモードは以下の要素で構成されます：

要素	説明
Slug	内部およびモード固有の指示ファイルに使用される一意の識別子
Name	Bobインターフェースに表示される表示名
ロール定義	Bobのペルソナと動作を定義するコア・アイデンティティーと専門知識
使用するタイミング	（オプション）このモードを使用するタイミングのガイダンス
利用可能なツール	モードが使用できるツール・グループとファイル・アクセス権限
カスタム・ルール	（オプション）追加の動作ガイドラインまたはルール

構成ファイルを作成する

カスタムモードは、YAML形式で定義します。

グローバル・モード: すべてのプロジェクトで利用可能
プロジェクト・モード: プロジェクト内の.bob/custom_modes.yamlで定義

基本的な構成は以下の通りです：

customModes:
- slug: your-mode-slug
  name: Your Mode Name
  roleDefinition: モードの役割定義をここに記述
  whenToUse: このモードを使用すべき場面の説明
  customInstructions: 追加の指示（オプション）
  groups:
    - read
    - - edit
      - fileRegex: \.(ext)$
        description: 編集可能なファイルパターン
    - command

利用可能なツール・グループ

モードが使用できるツール・グループは以下の通りです：

read: ファイルとディレクトリーを読み取る
edit: ファイルを変更する（fileRegexで制限可能）
browser: ブラウザー自動化を使用する
command: ターミナル・コマンドを実行する
mcp: MCPサーバーにアクセスする

カスタムモードを作成してみる

今回は、カスタムモードの例として、BobにJava/JUnitを使ったテスト駆動開発（TDD）を実施してもらうためのモードを作成してみました。

（参考）TDDとは

TDD（テスト駆動開発）は、以下のRed-Green-Refactorサイクルを繰り返す開発手法です：

🔴 Red：失敗するテストを書く
🟢 Green：最小限の実装でテストを通す
🔵 Refactor：コードを改善する

このサイクルをBobに実践させるため、各フェーズでの具体的な手順をroleDefinitionに組み込みました。

作成した.bob/custom_modes.yaml

カスタムモードの定義自体をBobに作成してもらうことが可能です。
今回作成したTDD-Javaモードのカスタムモード定義は以下の通りです：

customModes:
- slug: tdd-java
  name: 🧪 TDD Java
  roleDefinition: >-
    あなたはBobです。Java/JUnitを使用したテスト駆動開発（TDD）の専門家として、Red-Green-Refactorサイクルを厳格に実践します。
    
    ## TDDサイクル
    🔴 Red: 失敗するテストを書く → 🟢 Green: 最小限の実装でテストを通す → 🔵 Refactor: コードを改善する
    
    ## ワークフロー
    1. 要件理解: 機能の目的、入出力仕様、エッジケースを明確化
    2. プロジェクト構造確認: list_filesでsrc/test/java、src/main/javaを確認、read_fileでpom.xml/build.gradleを確認
    3. テスト戦略決定: 単体テスト（ビジネスロジック）、統合テスト（DB/API連携）、E2Eテスト（REST API）から選択
    
    ## Redフェーズ（失敗するテストを書く）
    - write_to_fileで新規テストクラス作成: {対象クラス名}Test、src/test/java配下に同じパッケージ構造
    - insert_contentで既存テストクラスにテストメソッド追加: read_fileで内容確認後、閉じ括弧の直前に挿入
    - テンプレート: @ExtendWith(MockitoExtension.class)、@Mock、@InjectMocks、@DisplayName("日本語説明")
    - AAA構造: Arrange（準備）→ Act（実行）→ Assert（検証）
    - execute_commandでテスト実行: mvn test -Dtest=クラス名 または gradle test --tests クラス名
    - 期待結果: コンパイルエラーまたはテスト失敗を確認
    
    ## Greenフェーズ（最小限の実装）
    - write_to_fileで新規実装クラス作成: YAGNI原則、テストが通ることだけを目標
    - apply_diffで既存クラスにメソッド追加: read_fileで内容確認後、複数変更は1つのdiffにまとめる
    - execute_commandでテスト実行: すべてのテストが成功することを確認
    
    ## Refactorフェーズ（コード改善）
    - apply_diffでコード改善: 重複削除（DRY）、メソッド分割（単一責任）、変数名改善、定数化
    - テストコード改善: @BeforeEachで共通データ準備、ヘルパーメソッド抽出、パラメータ化テスト活用
    - execute_commandで回帰テスト: すべてのテストが引き続き成功することを確認
    
    ## テスト作成原則
    - テスト命名: test{メソッド名}_{条件}_{期待結果} + @DisplayName("日本語説明")
    - AssertJ使用: assertThat(actual).isEqualTo(expected)、assertThatThrownBy(() -> ...).isInstanceOf(Exception.class)
    - Mockito使用: when(mock.method()).thenReturn(value)、verify(mock).method()、ArgumentCaptor使用
    - テスト独立性: 各テストは他に依存せず独立実行可能、@BeforeEachで初期化
    - 1テスト1振る舞い: 1つのテストメソッドで1つの振る舞いのみ検証
    
    ## ツール優先順位
    1. read_file: 変更前に既存コード確認（必須）
    2. write_to_file: 新規ファイル作成（テスト/実装クラス）
    3. insert_content: 既存ファイルへの追加（テストメソッド）
    4. apply_diff: 既存コードの修正（実装追加、リファクタリング）
    5. execute_command: テスト実行（各フェーズで必須）
    
    ## コマンド例
    Maven: mvn test -Dtest=クラス名、mvn test、mvn clean install
    Gradle: gradle test --tests クラス名、gradle test、gradle clean build
    
    ## 小さなステップで進める
    - 1サイクル5-15分、複雑な機能は小さく分割、各ステップでコミット
    - 頻繁にテスト実行、グリーンを維持、問題の早期発見
  whenToUse: >-
    このモードは、Java/JUnitを使用してテスト駆動開発を実践する際に使用します。
    新機能の実装、既存コードのリファクタリング、バグ修正、レガシーコードへのテスト追加など、
    テストファーストのアプローチで開発を進めたい場合に最適です。
    Spring Boot、Jakarta EE、マイクロサービスなどのエンタープライズアプリケーション開発に対応します。
  groups:
    - read
    - - edit
      - fileRegex: (.*\.java|pom\.xml|build\.gradle|.*\.properties|.*\.yml|.*\.yaml)$
        description: Javaソースファイル、テストファイル、ビルド設定ファイル
    - command

設計のポイント

1. 具体的なワークフローを明示

各フェーズで「何をすべきか」を具体的に記述しました。

例えば、Redフェーズでは：

使用するツール名（write_to_file、insert_contentなど）
ファイル配置場所（src/test/java配下に同じパッケージ構造）
実行すべきコマンド（mvn test -Dtest=クラス名）

このように具体的に記述することで、Bobが迷わず作業を進められます。

2. ツール使用の優先順位を明確化

Bobが適切なツールを選択できるよう、優先順位を明示しました：

read_file：変更前の確認（必須）
write_to_file：新規ファイル作成
insert_content：既存ファイルへの追加
apply_diff：既存コードの修正
execute_command：テスト実行

3. ベストプラクティスを組み込む

TDDの原則を守るための指針を含めました：

YAGNI原則（You Aren't Gonna Need It）：必要最小限の実装
DRY原則（Don't Repeat Yourself）：重複コードの削除
単一責任の原則：1メソッド1責務
テスト独立性の確保：各テストは独立実行可能

4. ファイル編集権限を制限

fileRegexで編集可能なファイルをJava関連ファイルに限定し、意図しないファイル変更を防止しました。

fileRegex: (.*\.java|pom\.xml|build\.gradle|.*\.properties|.*\.yml|.*\.yaml)$

TDD-Javaモードを使ってみる

実際にTDD-Javaモードを使って、BobにJavaクラスの実装を指示してみました。
対象は「金額と人数を入力し、1人あたりの支払額を出す割り勘計算クラス」としました。

プロンプト

モードを設定した上で、以下のプロンプトを入力しました。

金額と人数を入力し、1人あたりの支払額を出す割り勘計算用のクラスを実装してください。
作成したソースは @/src/ においてください。

TDD-Javaモードのアプローチ

TDD-Javaモードでは、以下のようなToDoリストが作成されました：

カスタムモードの定義に従って、TDDのサイクルに沿った段階的なアプローチで進めようとしていることがわかります。

途中経過は省略しますが、ToDoリストの通りにTDDサイクルに沿った実装作業が完了しました。

組み込みのCodeモードとの比較

参考までに、同じタスクを組み込みのCodeモードでも実行し、アプローチを比較してみます。

Codeモードのアプローチ

先ほどのプロンプトを入力したところ、Codeモードでは以下のようなToDoリストに沿って実装作業が進められました：

シンプルで直接的なアプローチです。またテストではなく、動作確認用のメインクラスが作成されました。

カスタムモード作成のポイント

実際にカスタムモードを作成してみて、いくつかのポイントが分かりました。

具体的なツール使用方法を記述する

Bobが使用できるツール名と、その使用タイミングを明示しましょう。

roleDefinition: >-
  ## ツール優先順位
  1. read_file: 変更前に既存コード確認（必須）
  2. write_to_file: 新規ファイル作成
  3. apply_diff: 既存コードの修正
  4. execute_command: テスト実行

ワークフローを段階的に定義する

複雑なタスクは、小さなステップに分解して記述します。

roleDefinition: >-
  ## ワークフロー
  1. 要件理解: 機能の目的、入出力仕様を明確化
  2. プロジェクト構造確認: list_filesで確認
  3. テスト戦略決定: 単体/統合/E2Eから選択
  4. 実装: Red-Green-Refactorサイクルを実行

ファイル編集権限を適切に制限する

意図しないファイル変更を防ぐため、fileRegexで編集可能なファイルを制限します。

groups:
  - read
  - - edit
    - fileRegex: (.*\.java|pom\.xml|build\.gradle)$
      description: Java関連ファイルのみ編集可能
  - command

まとめ

本記事では、IBM Bobのモードの概要やカスタムモードの作成方法について解説し、TDDを実践するためのカスタムモードを作成して確認を実施しました。

カスタムモードを作成することで、チーム固有の開発プロセスやベストプラクティスをBobに組み込むことができます。

以下のようなモードの作成を検討してみてはいかがでしょうか：

API設計モード：OpenAPI仕様を先に作成し、実装を進める
セキュリティレビューモード：OWASP Top 10を考慮したコードレビュー
パフォーマンス最適化モード：ボトルネック分析と改善提案
ドキュメント作成モード：コードから技術文書を自動生成

カスタムモードを活用して、より効率的で品質の高い開発を実現しましょう！

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

IBM Bobのモードとは 〜 カスタムモードでTDDを実践