【IBM Bob v2】サブエージェント並行処理によるTerminal-MCPの競合と1つの回避策

こんにちは、IDELIBです。

おかげさまでご好評いただいている「Terminal-MCP」ですが、IBM Bob 2.0（以下、Bob v2）上で動作させた際に、意図しない挙動（競合）が確認されました。

Bob v2 の「サブエージェント」で分かった考慮点

Bob v2の大きな目玉機能として、タスクを並行実行する「サブエージェント（Sub Agents）」が導入され、処理性能が大幅に向上しました。

しかし、この並行実行の仕組みが、Terminal-MCPの仕様と重なったことで注意点が生じました。

現行のTerminal-MCPは、ターミナル・セッションの接続を維持し、
「コマンド実行 → 結果確認」
を順番に繰り返す前提で設計されています。
Terminal-MCPの詳細はこちら

Bob v1とv2での挙動の違い

• Bob v1: 単一セッションに対して、1つずつ順番にコマンドを実行。

• Bob v2: 処理のループ中にサブエージェントが追加で send_command を並行実行。

この結果、同じセッション内で複数の send_command が同時に動いてしまい、session_buffer に複数コマンドの応答が混在してしまう現象が発生していました。

Terminal-MCPの動作

Bob v1

図中の「1. send_command」から、「5.解析と判断」までのループが順次実行されます。

Bob v2

図中の「1. send_command」 が終了する前にサブエージェントが割り込みし別のsend_commandを同一セッションに対して要求してしまう。
その結果「4. session_buffer.join」に複数のコマンドの応答が混在し、データ破壊が起きてしまう。

当面の回避策と今後の展望

【回避策】
とりあえずの対応としては、
「順次実行（シーケンシャルに実行）するようにBobにプロンプトで指示する」ことで、Bob v1と同様にスムーズに動作します。

【今後の実装】
根本的な修正に向けては、せっかくのサブエージェントによる並行処理のメリット（高速化）を活かしつつ、セッションを安全にコントロールできる実装を検討中です。後日別記事でご報告予定です。

順次実行では問題なく動いていても、並行処理になると競合が起きるというのは開発でよくあるテーマですが、Bob v2を活用される皆様の参考になれば幸いです。

あとがき

前回の記事「【IBM Bob】5250画面のテスト自動化ツール「5250TestUnit」を作ってみた」もご好評いただいておりますが、このツールは画面の切れ目を確認しながらテストシナリオを実行するので、今のところ同様の問題は確認できておりません。

IDELIBでは、技術サポートやご相談をお受けする【お仕事依頼】や【IDELIBのメンバーシップ】を開設しております。ご興味のある方はぜひ覗いてみてください!
最後まで読んでいただきありがとうございました。