はじめに
僕はAIエージェント素人なのですが、IBM Bobを使い始めたときに選べるモードを見てふと思いました。
「Agent・Plan・Ask…どれを選べばいいんだろう？」
3つのモードがあるのは分かる。でも、何が違うのかよく分からない。Agentが一番強そうだからAgentをずっと使っておけばいいのか？ Planは何のためにあるのか？
この疑問を解消するために、まったく同じプロンプトを3つのモードそれぞれに投げて、何が変わるかを実際に検証してみました。
今回も例のごとく、検証からこの記事の作成まで一貫してIBM Bobにやらせました。
Agent / Plan / Ask とは
まず、IBM Bobの公式定義を整理します。
| モード | 公式上の目的 |
|---|---|
| Agent | コードの作成・修正・リファクタリングに使用。機能実装、バグ修正、新規ファイル作成、コード改善全般。 |
| Plan | 実装前の計画・設計・戦略立案に使用。複雑な問題の分解、技術仕様作成、システム設計、実装前のソリューション検討。 |
| Ask | 説明・ドキュメント・技術的質問への回答に使用。概念理解、既存コード分析、推奨事項取得、変更を加えずに学習。 |
モードごとに使えるツールが違う
単なる「回答スタイルの違い」ではなく、各モードに許可されているツール（行動）そのものが異なります。
| 機能 | Ask | Plan | Agent |
|---|---|---|---|
| ファイルを読む | ✅ | ✅ | ✅ |
| ファイルを書く・編集する | ❌ | ✅ | ✅ |
| コマンドを実行する | ❌ | ❌ | ✅ |
| ToDoリストで進捗管理する | ❌ | ❌ | ✅ |
| サブタスクを起動する | ❌ | ❌ | ✅ |
| HTMLアーティファクトを作成する | ❌ | ❌ | ✅ |
出典: IBM Bob システム定義（各モードの
available_toolsセクション）
つまり、選ぶモードによってAIが実際に「何をできるか」が根本的に変わります。
今回の検証方法
実験条件
| 項目 | 内容 |
|---|---|
| 使用ツール | IBM Bob |
| 検証対象モード | Agent / Plan / Ask（3モード） |
| 実行環境 | Windows 10 / PowerShell |
| 初期状態 | 空のワークスペース（各モード独立コンテキスト） |
| プロンプト | 全モード共通・同一 |
| 追加指示 | なし（1回のみ投入） |
トークン数について
IBM BobのUIでは、消費トークン数の詳細（Input/Output Token数）を直接確認する手段が公開されていません。
本記事でのトークン関連の数値は、各モードの出力文字数・ツール呼び出し回数・実行内容から導いた推定値・相対比較です。実測値ではありません。
同じプロンプトを投げてみる
以下のプロンプトを3モード全てに投入しました。
以下の要件でシンプルなTodoアプリを作成してください。
【要件】
- 言語：Python
- タスクの追加・一覧表示・完了マーク・削除ができること
- データはJSONファイルに保存すること
- CLIで操作できること
以下をすべて実施してください：
1. 要件整理
2. 設計（ディレクトリ構成・クラス設計）
3. 実装（コード作成）
4. README作成
5. 自己レビュー
Ask で実行
出力概要
AskモードはファイルへのWrite権限を持たないため、すべての成果物がチャット上のテキストとして返却されました。
- 要件整理：機能要件5件・非機能要件3件をテーブルで整理、ユースケース図（Mermaid）付き
- 設計：ディレクトリ構成・クラス図・データモデル・シーケンス図をMermaidで提示
- 実装：
task_manager.py・todo.pyのコードを回答内に掲載 - README：使い方・コマンド例・データ形式を含む完成品をテキストで提示
- 自己レビュー：良い点5項目・改善余地5項目をテーブルで整理
実測値
| 指標 | 値 |
|---|---|
| 出力文字数（推定） | 約 4,800 文字 |
| ツール呼び出し回数 | 1 回（read_file のみ） |
| 作成されたファイル数 | 0（ファイル操作ツールなし） |
| 実行コマンド数 | 0（コマンド実行ツールなし） |
特徴
- 会話がすっきりしている。 回答が1つのレスポンスにまとまっており、読みやすい。
- コードはすぐに使える品質。 提示されたコードをコピーして貼り付ければ動く。
- 動作確認はしない。 コードが正しいかは人間が確認する必要がある。
- Mermaidで設計図を出せる。 図示が得意で、設計フェーズの相談に向く。
Plan で実行
出力概要
Planモードはファイル書き込みが可能ですが、コマンド実行ツールは持ちません。実際にどう動いたか：
- 設計ドキュメント（
todo-app-plan.md）をファイルとして生成した - 内容はサブタスク一覧・設計上の決定事項・ディレクトリ構成・処理フローを含む詳細な計画書
- 「実装はAgentモードで行う」という明確な境界線を引いた
- アーキテクチャ図（Mermaid）付きで設計の全体像を提示
実測値
| 指標 | 値 |
|---|---|
| 出力文字数（推定） | 約 2,800 文字 |
| ツール呼び出し回数 | 5 回（use_skill × 1、list_files × 1、read_file × 2、write_file × 1） |
| 作成されたファイル数 |
1（todo-app-plan.md） |
| 実行コマンド数 | 0（コマンド実行ツールなし） |
特徴
- 「何をどう作るか」を精緻に設計した。 各サブタスクにIntent・Expected Outcomes・Todo Listが付いており、実装者への引き渡し書類として機能する。
- 実装は意図的にしない。 「このPlanモードでは計画・設計ドキュメントの作成までが範囲です」という境界を明示した。
-
設計の決定理由を記録した。 なぜ
argparseを使うか、なぜIDを連番にするかといった設計判断とその根拠が文書化されている。
Agent で実行
出力概要
Agentモードはファイル書き込みとコマンド実行の両方が使えます。
-
models.py：TodoItemデータクラス（uuid短縮IDを採用） -
storage.py：Storageクラス（JSONファイルのI/O） -
manager.py：TodoManagerクラス（ビジネスロジック） -
todo.py：CLIエントリーポイント（argparse、Windows UTF-8対応） -
README.md：使い方・コマンド例・クラス設計・エラー処理を含む完成ドキュメント - 動作確認コマンドを実行し、各機能が正常動作することを確認
実測値
| 指標 | 値 |
|---|---|
| 出力文字数（推定） | 約 8,000 文字 |
| ツール呼び出し回数 | 21 回 |
| 作成されたファイル数 | 5（.py × 4 + README.md） |
| 実行コマンド数 | 5 回 |
特徴
- 実際に動くものが出来上がる。 ファイルが生成され、コマンドで動作確認まで完了する。
- Windows環境の考慮が入った。 UTF-8エンコーディングの問題を自律的に検出・対処した。
- クラス分割が3層構造になった。 Ask・PlanはシンプルなModel+CLIの2ファイル構成を提案したが、AgentはModels/Storage/Manager/CLIの4ファイル構成を選んだ。
- ツール呼び出しが多い分、処理が段階的に進む。 計画→実装→確認のサイクルを自律的に回した。
比較してみる
計測値の比較
| モード | 出力文字数（推定） | ツール呼び出し | 作成ファイル数 | 実行コマンド数 |
|---|---|---|---|---|
| Ask | 約 4,800 文字 | 1 回 | 0 | 0 |
| Plan | 約 2,800 文字 | 5 回 | 1 | 0 |
| Agent | 約 8,000 文字 | 21 回 | 5 | 5 |
⚠️ トークン数（Input/Output Tokens）はIBM Bobの現在のUIでは直接確認できませんでした。上記はすべて推定・相対比較です。
評価比較（各モード本来の目的を踏まえた評価）
| 評価項目 | Ask | Plan | Agent |
|---|---|---|---|
| 要件理解 | 5 | 5 | 5 |
| 正確性 | 4 | 5 | 5 |
| 網羅性 | 4 | 5 | 4 |
| 設計品質 | 3 | 5 | 4 |
| 実用性 | 3 | 4 | 5 |
| 自律性 | 2 | 3 | 5 |
| 過剰さ（少ない＝良い） | 5 | 4 | 3 |
| 構造化 | 4 | 5 | 4 |
| トークン効率 | 5 | 4 | 3 |
（5：非常に良い / 4：良い / 3：普通 / 2：やや問題あり / 1：問題あり）
何にトークンを使っているのか
3モードで消費リソースに大きな差が出た原因を考えます。
Ask が軽い理由
Askはファイルを読む以外のツールを使いません。モデルが「考えて回答する」だけです。ツール呼び出しごとに発生するContext（ツール定義の注入・結果の受け取り）がほぼないため、消費トークンが少なくなります。
Plan が中間の理由
Planはファイルを読み・書きします。ツール呼び出しのたびに「ツール定義」「ファイル内容」「結果」がコンテキストに積み上がります。ただしコマンド実行がないため、試行錯誤のループは発生しません。
Agent が最も重い理由
AgentはWrite・Executeの両方を使います。コマンドを実行すると「実行結果」がコンテキストに積み上がり、それを読んで次の行動を決めます。21回のツール呼び出しは、ファイル作成 → コマンド確認 → エラー修正 → 再確認という反復的な作業の結果です。
つまり、トークンの差は「AIが何をしたか」の直接的な反映です。
Agent を使えばいいわけではない
実験を通じて分かった重要な事実：トークンが多い ≠ 品質が高い
Ask で十分なケース
- 「このコードの動きを教えて」
- 「この設計のどこが問題か指摘して」
- 「この技術の概要を説明して」
- → 回答だけほしい場合。ファイルを変えてほしくない場合。
Plan を使う価値があるケース
- 「大きなリファクタリングに入る前に、影響範囲と手順を整理してほしい」
- 「複数の実装方針を比較検討したい」
- 「AIにいきなりコードを書かせる前に計画をレビューしたい」
- → 実装前の設計・思考整理に。変更を加えてほしくないが、計画書は欲しい場合。
Agent に任せる価値があるケース
- 「この機能を実際に実装して」
- 「複数ファイルにまたがる変更を一気にやってほしい」
- 「コマンドも含めて動作確認まで完了させてほしい」
- → 実際に手を動かしてほしい場合。成果物（ファイル・動作するコード）が必要な場合。
Agent / Plan / Ask をどう使い分けるか
今回の実験結果から、以下のシンプルな軸で整理できます。
| やりたいこと | 使うモード |
|---|---|
| 「質問する」 ── 聞いて理解したい | Ask |
| 「考えさせる」 ── 計画・設計を作ってほしい | Plan |
| 「やらせる」 ── 実際にファイルを変えてほしい | Agent |
人間に仕事を頼む場合に例えると：
- Ask → 「このコードどうなってる？」と詳しい人に聞く
- Plan → 「この仕事をやるとしたらどう進める？計画を作って」と相談する
- Agent → 「じゃあ実際にやっておいて」と仕事そのものを任せる
この比喩は今回の実験結果とよく一致しています。Planは計画書（todo-app-plan.md）を作って「あとはAgentで実装してください」と明示的に言いました。Agentは誰にも聞かずに最後まで実装・動作確認を完了させました。Askはコードを見せてくれましたが、ファイルには一切手を触れませんでした。
まとめ
今回の実験から分かったことを整理します。
-
モードの違いは「回答スタイル」ではなく「許可された行動」の違い。 ToolがAskにはなく、PlanにはWrite系があり、AgentにはさらにExecuteがある。
-
Ask・Plan・Agent の順にトークン消費（推定）・ツール呼び出し・作成ファイル数が増える。 しかしそれはモードが「多くの仕事をした」ことの反映であって、品質の優劣ではない。
-
設計品質はPlanが最高だった。 「なぜその設計にしたか」の根拠・サブタスク分割・Expected Outcomesが最も整理されていたのはPlanモードだった。
-
Agentは実際に動くものを作り、動作確認まで完了させた。 Windows環境固有のエンコーディング問題への対処など、環境適応も自律的に行われた。
-
「どこまでAIに任せるか」でモードを選ぶのが正しい使い方。 理解したいだけならAsk。設計を整理したいならPlan。実際に作業させたいならAgent。常にAgentを使うのは、コマンドの多い外部委託と同じ ── 確認なしに進むので速いが、意図しない変更が起きるリスクもある。
付録：公式情報の出典
本記事の「各モードの定義・利用可能なツール」に関する情報は、IBM Bob のシステム定義（<available_modes> セクション）に基づいています。
IBM Bobの外部向け公式ドキュメントとして一般公開されているモード別の詳細仕様は、執筆時点（2025年）では確認できませんでした。公式ドキュメントが公開された場合は、そちらを参照することを推奨します。
検証環境：IBM Bob / Agent mode / Windows 10 / PowerShell / Python 3.10