Bob のダウンロードはこちら：https://bob.ibm.com/
※ 本記事で扱う Bob は Bob IDE を指します。
目次
はじめに
Bob 1.0 では、生成・レビュー・修正・確認といった作業を、すべてひとつの会話の中で進めていました。
ただしタスクが長くなるほど、要件・生成結果・レビュー結果・修正指示が同じ context window にたまっていき、状態の管理が難しくなります。その結果、要件を取りこぼしたり、出力品質が低下したりすることがありました。
もちろん、要件や生成結果をファイルに保存し、必要なときだけ読み直すことで、context window への負荷をある程度は抑えられます。とはいえ、生成・レビュー・修正方針の判断・ユーザー確認といった役割を、すべて同じ会話の流れの中で扱う点は変わらないため、状態が混ざりやすいという課題は残っていました。
こうした課題に対して、Bob 2.0 では新たに Subagents という機能が導入されました。
Subagents は、Bob が独立した context window を持つサブエージェントに作業を委譲するための仕組みで、状況に応じて Subagent ツール と Subtask ツール の2つを使い分けます（それぞれの役割と違いは次章で詳しく説明します）。
一方で、最近注目されている Loop Engineering は、AI コーディングエージェントにユーザーが毎回手動でプロンプトを与えるのではなく、エージェント自身を自律的にプロンプトし、オーケストレートするシステムを設計する方法論です。生成・レビュー・修正・再生成といった処理を「ループ」として設計することで、AI が継続的に出力を改善できる構造を作れます。
Bob2.0 で Subagents 機能が提供されたことで、生成やレビューのような自律処理と、ユーザーの確認・承認・差し戻しを明確に分けながら、Bob 上でも Loop Engineering 的なワークフローを実現できるようになりました。
この記事では、Bob2.0 の Subagents 機能そのものを網羅的に紹介するのではなく、Subagent / Subtask を使って Bob 上に Loop Engineering 的なワークフローを組んでみた過程を紹介します。あわせて、実際に動かしてみて分かったことも整理します。
その題材として、今回は会社サイト生成を取り上げます。
Bob2.0 の新機能：Subagent と Subtask
Bob2.0 では多くの機能更新が入っていますが、本記事ではそのうち Loop Engineering に直接関係する Subagents 機能、特に Subagent と Subtask の2つのツールに絞って紹介します。
この2つは、どちらも「独立した context window を持つ作業を切り出す」ための仕組みです。ただし、可視性 と 人間が介入できるかどうか が大きく異なります。
Subagent ツール（バックグラウンド・非表示）
Subagent ツールは、Bob が独立した context window を持つサブエージェントを起動し、与えたタスクをバックグラウンドで実行させるための仕組みです。
実行中の詳細なやり取りは本体の会話には表示されず、最終的には結果の要約だけが Bob に返ってきます。そのため、長い中間出力や試行錯誤をメインの context に混在させずに済みます。
Subagent ツールには次の2種類があります：
| 種類 | 用途 | モデル |
|---|---|---|
explore |
読み取り中心の探索向け | 軽量モデル |
general |
フルツールアクセス | 既定モデル |
このため、Subagent ツールは「生成」「レビュー」「分析」など、ユーザーが毎回確認しなくてもよい自律処理に向いています。
Subtask ツール（UI・対話可能）
Subtask ツールは、専用の UI と会話スレッドを持つタスクとして実行される仕組みです。本体とは別の会話スレッドで進むため、確認中のやり取りをそのままメインの context に抱え込まずに済みます。
Subagent が「バックグラウンドで静かに進む処理」だとすると、Subtask は「人間が進捗を確認し、必要に応じて判断や差し戻しができる処理」です。
そのため、Subtask ツールは「人間の確認」「承認」「差し戻し」など、可視性と判断が必要な処理に向いています。
Subagent と Subtask のまとめ
| Subagent | Subtask | |
|---|---|---|
| 呼び出し | spawn_subagent |
start_subtask |
| 実行 | バックグラウンド・非表示 | UI 付き・可視 |
| 人間の介入 | なし（要約だけ返る） | あり（対話・差し戻し） |
| 向く役割 | 生成 / レビュー / 分析 | 承認 / 差し戻し / 判断 |
| ループ上の位置 | 内ループ（自律） | 外ループ（人間ゲート） |
この「自律的に回す部分は Subagent、人間が判断する部分は Subtask」という切り分けが、次章で作る Loop Engineering ワークフローの土台になります。
以降の実装説明では、この対応関係に沿って、生成・レビューは spawn_subagent、ユーザー確認は start_subtask で呼び出します。
会社サイト生成で Loop Engineering を組む
全体のアーキテクチャー
今回のデモでは、架空のおもちゃ会社 Andy Toys の会社公式サイトを生成するワークフローを作ります。
ポイントは、Bob 本体にすべてを実行させるのではなく、Bob 本体は オーケストレータ として振る舞い、生成・レビュー・ユーザー確認をそれぞれ別の役割に分けることです。
大きな流れだけを見ると次のようになります。
役割を表にすると、次のようになります。
| Step | 役割 | 実行手段 |
|---|---|---|
| ユーザー入力 | 会社サイト要件と採点基準を渡す | ユーザー |
A Input Setup |
要件と採点基準をファイル化する | Bob 本体 |
B Auto Build Loop |
生成とレビューを自動で回す |
spawn_subagent（Subagent） |
C Human Review Gate |
ユーザーがプレビューを確認し、承認または差し戻す |
start_subtask（Subtask） |
D Final Export |
承認済み成果物を出力する | Bob 本体 |
まず A Input Setup では、ユーザーから受け取った会社サイト要件と採点基準を、Bob 本体の context に保持し続けるのではなく、ファイルとして保存します。
以後の各ステップでは、その本文を直接渡すのではなく、ファイルのパスを渡します。
これにより、後続の Subagent / Subtask は必要な内容を自分でファイルから読み取り、Bob 本体は大きな中間データを抱え込まずに全体の制御に集中できます。
次に、B Auto Build Loop がバックグラウンドで自律的に回る 内側のループ です。
この中でコード生成とレビューを行い、基準未達であればレビュー結果をもとに自律的に再生成します。
この自律処理には spawn_subagent で呼び出す Subagent を使います。
そして、レビュー結果が基準値を満たすと、C Human Review Gate に進みます。
C Human Review Gate は、ユーザーが判断する 外側のゲート です。ここでは確認・承認・差し戻しが必要になるため、UI 上で対話できる Subtask を start_subtask で呼び出します。
このステップでユーザーが承認せず差し戻した場合、その内容は一時的な指示ではなく、最初に入力した採点基準へ追加基準として保存され、再び B Auto Build Loop に戻ります。
つまり今回の設計では、次のように責務を分けています。
- Bob 本体：全体の制御、パスの受け渡し、ループ判定
- Subagent：ユーザーが毎回確認しなくてもよい生成・レビュー処理
- Subtask：ユーザーの確認、承認、差し戻し
- ファイル：要件、採点基準、生成結果、レビュー結果の保存先
この分離により、Bob 本体の context window には大きな HTML/CSS やレビュー全文を載せず、必要な保存先と判定に必要な小さな値だけを保持できます。
Bob 側の実装構成：Command と Skill
前節で挙げた役割分担は、Bob では Command と Skill という2種類のファイルに対応します。
- Command：ワークフローの入口。ユーザー入力を受け取り、A / B / C / D の実行順序やループ判定を定義します。前節でいう「Bob 本体」の振る舞いにあたります。
-
Skill：Generator / Reviewer / Human Review Gate など、各役割のプロンプトと実行方針を定義します。
spawn_subagent/start_subtaskで呼び出される側の中身です。
実際の構成は次の通りです。
| ファイル | 役割 |
|---|---|
.bob/commands/web-site-gen.md |
全体の制御フローを定義する Command |
.bob/skills/webgen_generator/SKILL.md |
会社サイトの HTML / CSS を生成する Generator |
.bob/skills/webgen_reviewer/SKILL.md |
生成結果を採点基準に沿ってレビューする Reviewer |
.bob/skills/webgen_review_gate/SKILL.md |
ユーザー確認・承認・差し戻しを扱う Human Review Gate |
Command 側では、A / B / C / D のどのステップをどの順番で実行するか、B のループルールをどう扱うかを定義します。
たとえば、B の生成・レビューでは webgen_generator と webgen_reviewer を spawn_subagent で呼び出し、C のユーザー確認では webgen_review_gate を start_subtask で呼び出します。
つまり、Bob 本体はサイトの HTML / CSS やレビュー文書を直接作り込むのではなく、全体の進行、ファイルの保存先の受け渡し、ループ判定を担当します。実際の生成・レビュー・ユーザー確認の振る舞いは、それぞれの Skill に分離しています。
この構成にすることで、Command はワークフロー全体を見通しやすく保ちつつ、各ノードの具体的な指示は Skill 側で独立して調整できるようになります。
各ステップの説明
ここからは、先ほどの全体フローに沿って A / B / C / D の各ステップを見ていきます。
A：Input Setup（入力のセットアップ）
A Input Setup では、ユーザーが入力した会社サイトの要件と採点基準を整理し、ファイルとして保存します。
今回の設計で重要なのは、ユーザーから受け取った内容を Bob 本体に保持し続けるのではなく、参照できるファイルとして外に出しておくことです。
要件や採点基準はワークフロー全体で何度も参照されるため、それらを Bob 本体の context に保持すると、後続の生成結果やレビュー結果、ユーザーの差し戻し内容と混ざり、context window を圧迫しやすくなります。
そのため、次の2つをファイルとして保存し、後続のステップには本文ではなく保存先だけを渡します。
- 会社サイトの要件
- 採点基準
特に採点基準ファイルは、ワークフロー全体の判断基準になります。B のレビューではこのファイルの内容を基準として採点し、C Human Review Gate でユーザーが差し戻した場合も、その内容を追加基準としてここに保存します。
つまり A は、後続の Subagent / Subtask が参照する 入力の正本 を作るステップです。Bob 本体は本文を持ち回らず、必要なエージェントに保存先だけを渡します。
B：Auto Build Loop（生成・レビューの自動ループ）
B Auto Build Loop は、コード生成とレビューを自律的に回すステップです。
ここでは spawn_subagent を使い、バックグラウンドで動く Subagent に処理を任せます。
流れを図にすると、次のようになります。
内部では、主に次の2つの役割があります。
| 役割 | 内容 | 実行手段 |
|---|---|---|
| Generator | 会社サイトの HTML / CSS を生成する | spawn_subagent |
| Reviewer | 生成された実ファイルを採点基準に沿ってレビューする | spawn_subagent |
- Generator は、要件ファイルと採点基準ファイルを読み、会社サイトの実ファイルをプレビュー用フォルダに書き出します。
- Reviewer は、採点基準ファイルとプレビュー用フォルダ内の生成結果を読み、機械判定用のレビュー結果と、ユーザーが読むためのレビュー文書を保存します。
- Bob 本体はレビュー全文を context に保持せず、合否・スコア・周回番号のような判定に必要な小さな値だけを読みます。基準未達であれば、レビュー結果を次回生成への差し戻し指示として Generator に渡し、もう一度生成処理を実行します。
この部分が、今回のデモにおける 自律的な内側のループ です。
C：Human Review Gate（ユーザーによる確認ゲート）
C Human Review Gate は、ユーザーが生成結果を確認するステップです。
ここでは start_subtask を使い、UI 上で対話できる Subtask を起動します。
Subtask には、生成されたプレビューやレビュー結果そのものを全文で渡すのではなく、次のような情報の保存先と判定に必要な小さな値だけを渡します。
Subtask 側はそれらをもとに、ユーザーが確認すべき内容を UI 上に表示します。
- プレビュー用フォルダ
- 採点基準ファイル
- 機械判定用のレビュー結果
- ユーザーが読むためのレビュー文書
- 現在のスコア
- これまでのスコア履歴
ユーザーがこれらの内容を確認して問題なければ、承認として D Final Export に進みます。
一方、差し戻しがある場合は、ユーザーの指摘内容を受け取り、採点基準へ追加します。
このとき、ユーザーの指摘内容は一時的な指示ではなく、次のループで使う 追加採点基準 として扱います。
そのため、差し戻し後は B Auto Build Loop に戻り、新しい基準に基づいて再生成とレビューを行います。
D：Final Export（最終出力）
D Final Export は、ユーザーが承認した成果物を最終出力するステップです。
この時点で、生成された HTML / CSS はすでに プレビュー用フォルダ に存在しています。
そのため、Bob 本体は HTML / CSS の本文を context に読み込まず、ファイル操作として最終出力先へコピーします。
あわせて、採点基準やレビュー結果、採点履歴などを含む生成レビューサマリも出力されます。
これにより、最終成果物だけでなく、どの基準で生成・レビューされ、どのように改善されたかも後から確認できます。
実際にデモを動かしてみる
入力したプロンプト
ここでは、架空のおもちゃ会社「Andy Toys」の会社サイトを生成する要件と採点基準を Bob に渡しました。
また、今回のデモでは、Reviewer の結果を 100 点満点のスコアとして扱い、90 点未満の場合は自動的に Auto Build Loop に戻って再生成する前提にしています。
架空のおもちゃ会社「Andy Toys」の会社公式サイトを作ってください。
会社設定：
Andy Toys は、子ども向けの木製玩具と知育玩具を企画・販売する小さなおもちゃ会社。
親子で安心して遊べる、やさしくて楽しいブランドイメージを大切にしている。
要件：
- HTML/CSS で動く最小構成の会社公式サイトにする
- トップページを中心に、ナビゲーション、ヒーロー、サービス紹介、導入メリット、問い合わせ導線、ログイン導線を含める
- ヒーローでは会社名「Andy Toys」を中央に大きく表示する
- 全体はシンプルで、少し可愛い雰囲気にする
- Login はナビゲーション上で見つけやすくする
- スマホ幅でも読めるレイアウトにする
採点基準：
① `index.html` と `styles.css` を含む
② ナビゲーションに Services / About / Contact / Login がある
③ ヒーロー中央に会社名「Andy Toys」が大きく表示されている
④ サービス紹介と導入メリットがそれぞれ別セクションとして存在する
⑤ Contact または問い合わせ CTA が明確にある
⑥ Login 導線がナビゲーション上で明確
⑦ 外部 CDN、外部画像、外部フォントに依存しない
⑧ スマホ幅でも横スクロールしない想定の CSS になっている
⑨ シンプルで少し可愛い配色と余白になっている
実行結果
Input Setupの結果
まず Bob 本体は、上記で入力したプロンプトを「要件」と「採点基準」に分けて整理し、それぞれファイルとして保存しました。
実行時の画面と、保存されたファイルの内容は次の通りです。
- 実行時の画面：
- 要件内容：
- 採点基準：
Auto Build Loop の結果
Input Setup ステップで保存した要件と採点基準は、Bob 本体の context に抱え込むのではなく、ファイルの保存先として後続ステップへ渡されます。
Auto Build Loop の生成ステップでは、spawn_subagent で起動された Generator が、要件ファイルと採点基準ファイルを読み取り、会社サイトの HTML / CSS を書き出します。
- Generator の実行画面：
生成が完了すると、そのまま Reviewer による自動レビューへ進みます。Reviewer は、プレビュー用フォルダ内の実ファイルを採点基準に沿って確認し、レビュー結果を保存します。
- Reviewer の実行画面：
この自律ループでは、会社サイトの実ファイルだけでなく、後続の判定や確認に使う情報もファイルとして残します。
- プレビュー用フォルダに生成された
index.html/styles.css - Generator が参照した入力と、生成したファイル内容の記録
- Reviewer が保存したレビュー結果（合否、スコア、指摘内容、次回生成への差し戻し）
この時点で index.html / styles.css はすでに生成されているため、直接開いて確認することもできます。ただし、このステップはあくまで Subagent による自律処理です。そのため、ユーザーが内容を確認して判断するタイミングは、次の Human Review Gate に集約しています。
実際に保存されたファイルとレビュー結果は次の通りです。
Human Review Gate の確認
上記の Auto Build Loop のレビューステップでは、Reviewer が生成結果を 100 点と評価しました。基準として設定した 90 点を満たしたため、start_subtask により Human Review Gate が起動され、ユーザーがプレビューと生成結果を確認するステップに進みました。
実際に生成されたウェブサイトを確認しました。
全体としては非常に良いです。ただし、ログイン画面と問い合わせ画面がまだ十分に整備されていません。現在のデザインと構成を維持したまま、ログイン用ページと問い合わせ用ページを、単独ページとしてそれぞれ1ページずつ追加してほしいです。
ここで注目したいのは、Reviewer の自動採点では 100 点だったにもかかわらず、ユーザーが実際に見ると「まだ足りない」と感じる部分があったことです。また、今回の場合は、あらかじめ設定した採点基準に「ログイン画面 / 問い合わせ画面をそれぞれ独立したページとして用意する」という観点が含まれていなかったため、このような差が出ました。
そのため、承認せず、差し戻しを選択し、「追加の改善点」を入力しました。
その後、ユーザーの指摘内容は一時的な修正指示ではなく、追加の採点基準として保存されます。ワークフローは B Auto Build Loop に戻り、新しい基準に基づいて再生成とレビューを行います。
生成結果が基準を満たした場合は、再度 C Human Review Gate に進みます。
再生成された結果を確認すると、初回の Human Review Gate で指摘したログイン画面と問い合わせ画面が、それぞれ独立した HTML ページ（login.html / contact.html）として追加されていることが分かります。ナビゲーションやボタンのリンクから各ページへ遷移できるようになっており、差し戻し内容が次の生成結果に反映されていました。
- ログイン画面：
- 問い合わせ画面：
最終出力
生成結果がすべての要件を満たしたため、Human Review Gate で承認しました。
承認後、D Final Export により最終成果物が出力されました。
出力先には、生成された HTML / CSS と生成レビューサマリが保存されています。
- 生成された HTML / CSS
- 生成レビューサマリ
生成レビューサマリのイメージ：
終わりに
本記事では、Bob2.0 の Subagents（Subagent / Subtask）機能を使い、会社サイト生成を題材にした Loop Engineering 的なワークフローを試しました。
今回特に意識したのは、役割ごとに担当を分けることです。
- 生成やレビューのように、ユーザーが毎回確認しなくてもよい処理は
spawn_subagent（Subagent）に任せる - 確認・承認・差し戻しのように、ユーザーの判断が必要な部分は
start_subtask（Subtask）で受け持つ
また、要件、採点基準、生成結果、レビュー結果を Bob 本体の context に抱え込まず、ファイルとして保存し、必要なステップには保存先だけを渡す構成にしました。これにより、長い HTML / CSS やレビュー全文でメインの context を圧迫せずに、生成・レビュー・差し戻しを扱えます。
今回のデモでは、Bob2.0 が生成した初回結果の品質が高く、Auto Build Loop 内での再生成はほとんど発生しませんでした。
一方で、自動採点で 100 点に達した結果であっても、Human Review Gate でユーザーが実際に確認すると、「ログイン画面と問い合わせ画面をそれぞれ単独ページとして表示したい」といった、事前の採点基準には含まれていなかった追加要望が出てきました。
その後、ユーザーからの指摘内容を追加の採点基準として保存し、再度 Auto Build Loop に戻すことで、ログイン画面と問い合わせ画面を含む生成結果へ改善することができました。
今回の結果からも分かるように、実際の業務では、事前に設定した採点基準だけでは、ユーザーの細かい意図や、生成結果を見て初めて気づく「もう少しこうしたい」という感覚までは、すべて拾いきれないケースも少なくないと考えられます。
だからこそ、すべてを自律的なループに任せきりにするのではなく、処理フローの設計の中に Human Review Gate のような人による確認ポイントをあらかじめ組み込んでおくことが重要だと、今回あらためて実感しました。
この結果から、内側の自律ループだけでなく、人間の判断を起点にした外側のループも含めて、Bob 2.0 上で Loop Engineering 的な処理フローを構成できることを確認できました。
参考資料
-
Loop Engineering入門：AIコーディングエージェントを動かすシステムを設計する
Loop Engineering の考え方と、その構築方法がまとめられた記事です。本記事のワークフロー設計の考え方も、ここで紹介されている内容を参考にしています。