[IBM Bob tips] Bob のことを Bob に尋ねる: part2

Last updated at 2026-04-16Posted at 2026-03-05

はじめに

IBM Bob について、Bob の Ask モードを使用して追加で質問した回答内容をご参考までに記載します。

参考リンク

IBM Bob 公式サイト

前の内容と別の質問を実施しています。

(質問) Bob version 1.0 で新しくなったことについて教えて

Bob version 1.0の新機能についてご説明します。

Bob version 1.0では、以下の主要な機能強化が行われました:

🎯 主な新機能

1. モードシステムの導入

複数の専門モードが利用可能になりました:

📝 Plan モード: タスクの計画・設計・戦略立案
💻 Code モード: コードの作成・修正・リファクタリング
🛠️ Advanced モード: MCP・ブラウザツールを含む高度な開発
❓ Ask モード: 技術的な質問への回答・説明（現在のモード）
🔀 Orchestrator モード: 複雑なマルチステッププロジェクトの調整

2. 効率的なファイル読み取り

read_fileツールが強化され:

一度に最大5ファイルまで読み取り可能
行範囲指定による部分読み取りをサポート
PDF・DOCXファイルからのテキスト抽出に対応

3. GitHub統合機能

fetch_github_issueツールにより:

GitHubイシューの取得と分析
ローカル変更とイシュー要件の整合性チェック
イシュー番号またはURLによる直接アクセス
割り当てられた全イシューの検索

4. PRレビュー機能

generate_description_from_diffツールで:

ブランチ間のdiffからPR説明を自動生成
PRテンプレートのサポート

5. ブラウザ自動化

browser_actionツールによる:

Puppeteerベースのブラウザ制御
スクリーンショット取得とコンソールログ監視
Web開発タスクの検証・テスト

6. TODOリスト管理

update_todo_listツールで:

複雑なタスクの段階的追跡
タスクステータスの管理（pending/in_progress/completed）
動的なタスク追加

7. コード定義の一覧表示

list_code_definition_namesツールにより:

クラス・関数・メソッドなどの定義名を抽出
コードベース構造の理解を支援

8. Markdownリンク規則

すべての応答で:

ファイル名や言語構文をfilename形式でクリック可能に表示
コードレビューとナビゲーションの向上

🔧 改善点

ステップバイステップ実行: 各ツール使用後にユーザー確認を待機
効率的な読み取り戦略: 関連ファイルを一度に読み取り（最大5ファイル）
モード制限: 各モードで編集可能なファイルパターンを制限
環境詳細の自動提供: プロジェクト構造とアクティブなターミナル情報を自動取得

これらの機能により、Bobはより効率的で強力な技術アシスタントとして、複雑な開発タスクをサポートできるようになりました。

(質問)Bob の Orchestrator mode とは？

Bob の Orchestrator mode (🔀 オーケストレーターモード) は、複雑で多段階のプロジェクトを管理・調整するための特別なモードです。

主な特徴

1. 複雑なタスクの分解と調整

大規模なタスクを複数のサブタスクに分解
異なる専門分野にまたがる作業の調整
複数のドメインや専門知識が必要なプロジェクトの管理

2. ワークフロー管理

タスク間の依存関係を理解し、適切な順序で実行
各サブタスクの進捗を追跡
必要に応じて他のモード（Code、Plan、Askなど）を活用

3. 使用すべき場面

複数のステップが必要な大規模プロジェクト
設計、実装、テスト、ドキュメント作成など、複数の作業フェーズがあるタスク
異なる技術スタックや専門領域にまたがる開発
チーム作業のような複雑な調整が必要な場合

他のモードとの違い

実際の使用例

例えば、「フルスタックのWebアプリケーションを構築する」というタスクの場合：

Orchestrator mode が全体を統括
Plan mode でアーキテクチャ設計
Code mode でバックエンド実装
Advanced mode でフロントエンド実装（Browser toolsを使用）
Ask mode で技術的な質問に回答

Orchestrator modeは、これらすべてを適切な順序で調整し、各段階の完了を確認しながらプロジェクトを進めます。

まとめ

Orchestrator modeは、単一のモードでは対応しきれない複雑なプロジェクトのための「指揮者」のような役割を果たします。各専門モードの強みを活かしながら、全体として一貫性のある成果物を作り上げることができます。

Bob の Orchestrator mode (🔀 オーケストレーターモード) について説明しました。

主な特徴

複雑なタスクの分解: 大規模プロジェクトを複数のサブタスクに分割し、段階的に実行
ワークフロー管理: 異なる専門分野にまたがる作業を調整し、適切な順序で進行
モード間の調整: Plan、Code、Advanced、Askなど他のモードを必要に応じて活用

使用すべき場面

複数ステップが必要な大規模プロジェクト
設計・実装・テスト・ドキュメント作成など複数フェーズがあるタスク
異なる技術スタックや専門領域にまたがる開発

Orchestrator modeは、単一モードでは対応しきれない複雑なプロジェクトの「指揮者」として、各専門モードの強みを活かしながら一貫性のある成果物を作り上げます。

(質問)サブタスクについて説明して

Orchestrator mode のサブタスクについて

Orchestrator modeでは、複雑なタスクをサブタスクに分解して管理します。

サブタスクの仕組み

サブタスクとは、大きなプロジェクトを実行可能な小さな単位に分割したものです。Orchestrator modeは各サブタスクを：

適切なモードに割り当て
- コード実装が必要 → Code mode または Advanced mode
- 設計・計画が必要 → Plan mode
- 説明・調査が必要 → Ask mode
順序立てて実行
- 依存関係を考慮（例：設計 → 実装 → テスト）
- 各サブタスクの完了を確認してから次へ進む
進捗を追跡
- 完了したサブタスク、進行中のサブタスク、未着手のサブタスクを管理
- 必要に応じて計画を調整

具体例：Webアプリ開発

大きなタスク：「ユーザー認証機能付きのWebアプリを作成」

サブタスクへの分解：

サブタスク1: システム設計（Plan mode）
サブタスク2: データベーススキーマ作成（Code mode）
サブタスク3: バックエンドAPI実装（Code mode）
サブタスク4: フロントエンド実装（Advanced mode）
サブタスク5: 動作確認（Advanced mode + Browser tools）
サブタスク6: ドキュメント作成（Plan mode）

各サブタスクは独立して実行可能で、Orchestrator modeが全体の流れを管理します。

サブタスクの利点

明確な進捗管理: どこまで完了したか一目瞭然
柔軟な対応: 問題が発生した場合、該当サブタスクのみ修正
効率的な実行: 各専門モードの強みを最大限活用
複雑さの軽減: 大きな問題を扱いやすい単位に分割

(質問) .bob ディレクトリの有用な具体例は？

.bob ディレクトリの有用な具体例を、実際のユースケース別に紹介します:

1. 新規参画メンバーのオンボーディング加速

.bob/
├── onboarding.md                # 環境構築から初タスクまでの手順
├── team-structure.md            # チーム構成・連絡先
└── domain-knowledge.md          # ビジネスドメイン知識

効果: 新メンバーが質問する前にBobが必要情報を提供、立ち上がり時間を50%短縮

2. 複雑な運用手順の標準化

.bob/
├── deployment-checklist.md      # デプロイ前チェックリスト
├── rollback-procedure.md        # ロールバック手順
└── incident-response.md         # 障害対応フロー

効果: Bobに「デプロイ手順を教えて」と聞くだけで、プロジェクト固有の正確な手順を取得

3. 設計判断の記録と共有

.bob/
├── decisions/
│   ├── 001-why-postgresql.md    # なぜPostgreSQLを選んだか
│   ├── 002-api-versioning.md    # APIバージョニング戦略
│   └── 003-cache-strategy.md    # キャッシュ戦略

効果: 「なぜこの技術を使っているのか」という質問に即座に回答、設計意図の継承

4. トラブルシューティングの知識ベース

.bob/
├── common-errors.md             # よくあるエラーと解決策
├── performance-issues.md        # パフォーマンス問題の対処法
└── debugging-tips.md            # デバッグのコツ

効果: 過去の問題と解決策を蓄積、同じ問題の再発時に即座に解決

5. コードレビュー基準の統一

.bob/
├── code-review-checklist.md     # レビュー観点
├── security-checklist.md        # セキュリティチェック項目
└── performance-guidelines.md    # パフォーマンス基準

効果: Bobがコードレビュー時に基準に沿ったチェックを実施、品質向上

6. API仕様の一元管理

.bob/
├── api-overview.md              # API全体像
├── authentication.md            # 認証・認可の仕様
└── endpoints/
    ├── users-api.md
    └── orders-api.md

効果: 「ユーザーAPI仕様を教えて」でプロジェクト固有の詳細仕様を即座に提供

7. インフラ構成の可視化

.bob/
├── infrastructure-overview.md   # インフラ全体図
├── network-topology.md          # ネットワーク構成
├── server-inventory.md          # サーバー一覧
└── monitoring-setup.md          # 監視設定

効果: 「本番環境の構成は?」という質問に図解付きで回答

8. テスト戦略の明確化

.bob/
├── test-strategy.md             # テスト方針
├── test-data-setup.md           # テストデータ作成方法
└── ci-cd-pipeline.md            # CI/CDパイプライン説明

効果: テスト追加時にBobが既存戦略に沿った提案を実施

9. レガシーコードの理解促進

.bob/
├── legacy-system-overview.md    # レガシーシステム概要
├── migration-plan.md            # 移行計画
└── known-issues.md              # 既知の問題・制約

効果: レガシーコード修正時にBobが制約を考慮した安全な変更を提案

10. プロジェクト固有の用語集

.bob/
├── glossary.md                  # 用語集
├── abbreviations.md             # 略語一覧
└── business-rules.md            # ビジネスルール

効果: ドメイン固有用語をBobが理解し、正確なコミュニケーションが可能

実際の活用シーン

シーン1: 新機能開発

開発者: "ユーザー認証機能を追加したい"
Bob: .bob/authentication.md を参照し、既存の認証方式に沿った実装を提案

シーン2: 障害対応

開発者: "本番でエラーが出た、どう対処する?"
Bob: .bob/incident-response.md の手順に従い、段階的な対応方法を提示

シーン3: コードレビュー

開発者: "このPRをレビューして"
Bob: .bob/code-review-checklist.md に基づき、セキュリティ・パフォーマンス観点でチェック

まとめ

.bobディレクトリはプロジェクトの暗黙知を形式知化し、Bobを通じてチーム全体で活用できる仕組みです。一度作成すれば、継続的に価値を生み出す「生きたドキュメント」として機能します。

(質問) walkthrough と to do の違い

Walkthrough（ウォークスルー）

タスク実行中に自動的に表示される進捗レポートです。

特徴：

自動生成: Bobが作業を進めるたびに自動更新
過去の記録: 完了した作業の履歴を表示
読み取り専用: ユーザーは編集不可
詳細な説明: 各ステップで何をしたか、なぜそうしたかを記録

内容例：

✓ ファイル構造を分析しました
✓ package.jsonを読み込みました
✓ 新しいコンポーネントを作成しました
→ 現在テストを実行中...

TODO リスト

タスクの計画と進捗管理のためのチェックリストです。

特徴：

手動管理: update_todo_list ツールで明示的に更新
未来志向: これから実行する予定のタスクを表示
編集可能: 状況に応じて追加・変更が可能
ステータス管理: [ ] 未着手、[-] 進行中、[x] 完了

内容例：

[x] 要件を分析
[x] アーキテクチャを設計
[-] コアロジックを実装
[ ] テストを作成
[ ] ドキュメントを更新

主な違い

項目	Walkthrough	TODO リスト
目的	作業履歴の記録	計画と進捗管理
時制	過去（完了した作業）	未来（予定の作業）
更新	自動	手動（ツール使用）
編集	不可	可能
詳細度	詳細な説明付き	簡潔なチェックリスト
表示	常に表示	複雑なタスク時のみ

使い分け

Walkthrough: 「何をしたか」を振り返る
TODO: 「何をするか」を計画・追跡する

両方を組み合わせることで、過去の作業と今後の予定を明確に把握できます。

(質問) Bob のエージェント的自律動作について

現在の動作モデル：半自律型

Bob は完全自律ではなく、承認ベースの半自律動作を行います。

自律的な部分

✅ 自動で行うこと

タスクの分析と計画
- 複雑なタスクを自動的にサブタスクに分解
- 最適な実行順序を決定
- 必要なツールを選択
情報収集
- ファイル構造の分析
- コードの読み取り
- 依存関係の理解
問題解決の思考
- エラーの原因分析
- 解決策の立案
- 代替アプローチの検討
TODO管理
- 進捗の自動追跡
- 次のステップの判断

非自律的な部分（承認が必要）

❌ 承認なしでは実行できないこと

ファイル操作
- 作成、編集、削除
コマンド実行
- ターミナルコマンド
- スクリプト実行
外部アクセス
- ブラウザ操作
- API呼び出し
システム変更
- 設定変更
- パッケージインストール

動作フロー

Orchestrator Mode での自律性

最も自律的な動作を示すのが Orchestrator mode です：

自律的に行うこと：

サブタスクへの分解
適切なモードの選択
実行順序の決定
進捗管理

承認が必要なこと：

各サブタスクの実際の実行
ファイル変更
コマンド実行

例：Webアプリ開発

[自律] タスク分解
  ├─ [自律] Plan modeで設計が必要と判断
  ├─ [承認待ち] 設計ドキュメント作成
  ├─ [自律] Code modeで実装が必要と判断
  ├─ [承認待ち] コード実装
  └─ [承認待ち] テスト実行

完全自律動作との比較

機能	Bob（現在）	完全自律エージェント
タスク分析	✅ 自律	✅ 自律
計画立案	✅ 自律	✅ 自律
ファイル編集	❌ 承認必要	✅ 自律
コマンド実行	❌ 承認必要	✅ 自律
エラー修正	❌ 承認必要	✅ 自律
外部API呼び出し	❌ 承認必要	✅ 自律

なぜ完全自律ではないのか？

安全性の理由：

意図しない変更の防止
データ損失のリスク回避
セキュリティ確保
ユーザーのコントロール維持

より自律的に使う方法

1. 一括承認的な指示

「以下を順番に実行して、各ステップで承認を求めて：
1. 設計
2. 実装
3. テスト」

2. 信頼できる範囲を明示

「src/test/ 内は自由に編集していいよ」

3. Orchestrator modeの活用

複数ステップを計画的に実行

結論

Bob は「監督付き自律エージェント」

思考・計画: 完全自律
実行: ユーザー承認が必要
利点: 安全性とコントロールを保ちながら、効率的な作業が可能

完全自律ではありませんが、これにより安全で予測可能な動作を実現しています。

(質問) 検証環境などで、スクリプト開発とテストを成功するまで繰り返し修正とテストを実施することは可能？

Bob による反復的なスクリプト開発とテスト

はい、可能です！ Bob は検証環境でスクリプトの開発・テスト・修正を繰り返し実行できます。

基本的な反復フロー

実際の動作例

シナリオ：Pythonスクリプトのテスト

1回目：初期実装

# Bob が作成
def calculate(x, y):
    return x + y

print(calculate(5, 3))

→ ユーザー承認 → テスト実行 → 成功

2回目：機能追加でエラー

def calculate(x, y, operation):
    if operation == 'add':
        return x + y
    elif operation == 'subtract':
        return x - y
    # 除算を忘れた

→ ユーザー承認 → テスト実行 → エラー発見

3回目：Bob が自動修正

def calculate(x, y, operation):
    if operation == 'add':
        return x + y
    elif operation == 'subtract':
        return x - y
    elif operation == 'divide':
        return x / y  # 追加

→ ユーザー承認 → テスト実行 → 成功

各ステップでの動作

ステップ1：スクリプト作成

<write_to_file>
<path>test_script.py</path>
<content>...</content>
</write_to_file>

→ ユーザー承認待ち

ステップ2：テスト実行

<execute_command>
<command>python test_script.py</command>
</execute_command>

→ ユーザー承認待ち → 結果を受信

ステップ3：エラー分析（自律）

Bob が自動的に：

エラーメッセージを解析
原因を特定
修正案を立案

ステップ4：修正実施

<apply_diff>
<path>test_script.py</path>
<diff>...</diff>
</apply_diff>

→ ユーザー承認待ち

ステップ5：再テスト

ステップ2に戻る

承認の扱い方

パターンA：毎回承認（安全）

Bob: スクリプトを作成します
ユーザー: [承認]
Bob: テストを実行します
ユーザー: [承認]
Bob: エラーを修正します
ユーザー: [承認]
Bob: 再テストします
ユーザー: [承認]

パターンB：一括指示（効率的）

ユーザー: 「成功するまで修正とテストを繰り返して。
         各ステップで承認を求めて」

Bob: [スクリプト作成] → 承認待ち
     [テスト] → 承認待ち
     [修正] → 承認待ち
     [再テスト] → 承認待ち
     ...成功まで継続

実用的な使用例

例1：単体テスト開発

1. テストケース作成 → 承認
2. テスト実行 → 失敗
3. コード修正 → 承認
4. 再テスト → 成功

例2：API統合テスト

1. APIクライアント実装 → 承認
2. ローカルサーバー起動 → 承認
3. テスト実行 → エラー（認証失敗）
4. 認証ロジック修正 → 承認
5. 再テスト → エラー（レスポンス解析失敗）
6. パーサー修正 → 承認
7. 再テスト → 成功

例3：ブラウザ自動化テスト

1. Puppeteerスクリプト作成 → 承認
2. ブラウザ起動 → 承認
3. 操作実行 → 要素が見つからない
4. セレクタ修正 → 承認
5. 再実行 → タイムアウト
6. 待機時間追加 → 承認
7. 再実行 → 成功

高度な機能

1. TODO リストで進捗管理

[x] スクリプト作成
[x] 初回テスト実行
[-] エラー修正（2回目）
[ ] 最終テスト
[ ] ドキュメント作成

2. 複数の修正案を提示

Bob: 「エラーの原因は2つ考えられます：
     1. タイムアウト設定が短い
     2. セレクタが間違っている
     
     どちらを先に試しますか？」

3. 段階的なテスト

1. 単体テスト → 成功
2. 統合テスト → 成功
3. E2Eテスト → 成功

制限事項

❌ できないこと

完全自動修正: 各修正に承認が必要
無限ループ: 一定回数失敗したら停止を提案
本番環境での実行: 検証環境のみ推奨

✅ できること

反復的な修正: 成功するまで繰り返し
エラー分析: 自動的に原因特定
複数アプローチ: 異なる解決策を試行

ベストプラクティス

検証環境を用意

「test/ ディレクトリで作業して」
「本番データには触れないで」

明確な成功基準

「すべてのテストがパスするまで」
「エラーが0になるまで」

段階的な承認

「各修正後に結果を見せて」
「3回失敗したら別のアプローチを提案して」

Git でバックアップ

git commit -m "テスト前"
# Bob が作業
# 問題があれば git reset

結論

Bob は反復的な開発・テスト・修正サイクルを実行できます：

✅ 自律的な部分: エラー分析、修正案立案、進捗管理
❌ 承認が必要: 各実行ステップ（安全性のため）

推奨される使い方:
「成功するまで修正とテストを繰り返して。各ステップで承認を求めて」

これにより、安全性を保ちながら効率的な反復開発が可能です。

(質問)Bob コイン消費を抑える方法

Bob コイン消費を抑える方法

コスト発生の仕組み

Bob コインは主に AI モデルの使用量（トークン数）に応じて消費されます。

消費が多い操作：

長いファイルの読み取り
大量のコード生成
複雑な分析・推論
繰り返しの試行錯誤

💰 コスト削減テクニック

1. 必要な範囲だけ読み取る

❌ コスト高：ファイル全体を読む

<read_file>
<args>
  <file>
    <path>large_file.py</path>
  </file>
</args>
</read_file>

✅ コスト低：行範囲を指定

<read_file>
<args>
  <file>
    <path>large_file.py</path>
    <line_range>100-150</line_range>
  </file>
</args>
</read_file>

節約効果： 大きなファイルで 50-90% 削減

2. 明確で具体的な指示

❌ コスト高：曖昧な指示

「アプリを改善して」
→ Bob が全体を分析、複数の提案、試行錯誤

✅ コスト低：具体的な指示

「src/utils/helper.js の formatDate 関数に
ISO 8601 フォーマット対応を追加して」
→ Bob が直接実装

節約効果： 2-5倍のコスト削減

3. 段階的なアプローチ

❌ コスト高：一度に全部

「完全なWebアプリを作って」
→ 大量の分析、計画、実装

✅ コスト低：段階的に

1. 「まず基本構造を作って」
2. 「次に認証機能を追加」
3. 「最後にUIを改善」

節約効果： 各ステップで必要最小限の処理

4. ファイル探索を効率化

❌ コスト高：全ファイルを探索

<search_files>
<path>.</path>
<regex>.*</regex>
</search_files>

✅ コスト低：対象を絞る

<search_files>
<path>src/components</path>
<regex>useState</regex>
<file_pattern>*.tsx</file_pattern>
</search_files>

節約効果： 検索範囲を限定して 70-90% 削減

5. コード定義名の活用

❌ コスト高：ファイル全体を読む

「このプロジェクトの構造を教えて」
→ 全ファイルを読み取り

✅ コスト低：定義名だけ取得

<list_code_definition_names>
<path>src/</path>
</list_code_definition_names>

節約効果： 概要把握で 80-95% 削減

6. 不要な繰り返しを避ける

❌ コスト高：毎回同じ分析

セッション1: 「ファイル構造を分析して」
セッション2: 「ファイル構造を分析して」（同じ）

✅ コスト低：情報を再利用

セッション1: 「ファイル構造を分析して」
セッション2: 「前回の分析を基に、新しい機能を追加」

節約効果： 重複分析を回避

7. 適切なモードを選択

タスク	❌ 高コスト	✅ 低コスト
質問・説明	Code mode	Ask mode
計画・設計	Advanced mode	Plan mode
簡単な実装	Advanced mode	Code mode

理由： 各モードは必要な機能のみ有効化

8. ブラウザ操作を最小限に

❌ コスト高：頻繁なスクリーンショット

1. ページ表示 → スクリーンショット
2. ボタンクリック → スクリーンショット
3. フォーム入力 → スクリーンショット
4. 送信 → スクリーンショット

✅ コスト低：必要な時だけ

1. 最終結果の確認のみ
2. エラー発生時のみ

節約効果： ブラウザ操作で 50-75% 削減

9. TODO リストで計画的に

❌ コスト高：行き当たりばったり

試行 → 失敗 → 別の方法 → 失敗 → ...

✅ コスト低：事前計画

<update_todo_list>
<todos>
[ ] 要件分析
[ ] 設計
[ ] 実装
[ ] テスト
</todos>
</update_todo_list>

節約効果： 無駄な試行錯誤を削減

10. エラー情報を提供

❌ コスト高：Bob に調査させる

「動かないから直して」
→ Bob が全体を分析

✅ コスト低：エラー情報を共有

「以下のエラーが出ました：
TypeError: Cannot read property 'map' of undefined
at line 42 in App.js

修正してください」

節約効果： 直接原因に対処

🎯 実践例：コスト比較

シナリオ：React コンポーネントの修正

高コストアプローチ（$0.15）：

1. プロジェクト全体を分析
2. 全ファイルを読み取り
3. 複数の修正案を生成
4. ブラウザで詳細テスト
5. 繰り返し調整

低コストアプローチ（$0.03）：

1. 「src/components/Button.tsx の
   onClick ハンドラーに loading 状態を追加」
2. 該当ファイルの該当行のみ読み取り
3. 直接修正
4. 完了

節約：80%

📊 コスト削減チェックリスト

指示を出す前に確認：

具体的なファイル・関数名を指定したか？
必要な範囲だけに限定したか？
適切なモードを選択したか？
エラー情報があれば提供したか？
段階的なアプローチを取っているか？

Bob の動作中に確認：

不要なファイル読み取りをしていないか？
同じ分析を繰り返していないか？
ブラウザ操作が必要最小限か？

💡 最も効果的な方法

1. 具体的な指示（最重要）

❌「コードを改善して」
✅「src/api/client.ts の fetchUser 関数に
   エラーハンドリングを追加して」

削減効果：50-80%

2. 行範囲指定

大きなファイルは必ず行範囲を指定

削減効果：50-90%

3. 適切なモード選択

質問 → Ask mode
計画 → Plan mode
実装 → Code mode

削減効果：20-40%

🚀 上級テクニック

テクニック1：コンテキストの事前準備

「以下の情報を覚えておいて：
- プロジェクトはReact + TypeScript
- APIは /api/v1/ 配下
- 認証はJWT

この情報を基に、ログイン機能を実装して」

テクニック2：差分のみ確認

「変更した部分だけ見せて」
（全ファイルではなく diff のみ）

テクニック3：バッチ処理

「以下の3つのファイルを一度に修正：
1. A.ts - 型定義追加
2. B.ts - import 追加
3. C.ts - 関数呼び出し更新」

📈 コスト削減の目安

手法	削減率	難易度
具体的な指示	50-80%	易
行範囲指定	50-90%	易
適切なモード	20-40%	易
段階的実行	30-50%	中
エラー情報提供	40-60%	易
TODO計画	20-30%	中

まとめ

最も重要な3つ：

✅ 具体的に指示する
- ファイル名、関数名、行番号を明示
✅ 必要最小限の範囲
- 行範囲指定、ディレクトリ限定
✅ 適切なモード選択
- Ask（質問）、Plan（計画）、Code（実装）

これらを実践すれば、50-80% のコスト削減が可能です。

今回の質問はここまでです。

IBM Bob をとりあえず動かしてみたい方へ

当記事の検証時点ではまだ一般公開前でしたが、先日3月24日に待望のGA（一般提供）を迎え、どなたでも触れるようになりました。(筆者は Early Access で検証しています)

実際に手元で試してみたい方向けに、30日間の無料トライアル枠があります。期間中は40Bobコイン分のクレジットが付与されるので、ひとまず新しい環境の感覚を掴むのには十分な枠かと思います。

セットアップのやり方や、クレジットの仕組みについては以下のページをご参照ください。

IBM Bob Trial
必要になった際のクレジット追加について

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