連載コラム:IBM BobでAIエージェント開発を試してみた

連載コラム:IBM BobでAIエージェント開発を試してみた

第8回:チームは、AIエージェントとどう関わるのか。PMとしてIBM Bobを触ってみた

はじめに

IBM Bobが一般公開(GA)になりました。モダナイゼーションチームでは、20年以上使ってきたプログラム変換やテスト自動化ツールをAI-Readyにしていくための手直しを、AIと協働しながら進めています。

PMの立場で気になるのは、AIの分析力や生成スピードを活かしつつ、どこで人が介入し、どう品質を担保するかです。AI駆動開発(AIDD)は情報の更新が速い領域なので、やはり実際に触ってみないと見えてこない部分があります。

今回はBobのアーリーアクセス版を試した経験をもとに、PM視点でAI駆動開発に関わるときに何を見ておくべきか、そしてBobがその場面でどう役立つかを整理してみます。

Bobでやってみたこと

モダナイゼーション前準備タスク

対象にしたのは、現新比較テストの自動化ツールのモダナイゼーションです。具体的には、テスト自動実行用のShellとファイルコンペア用のJavaプロジェクトを、GitHubリポジトリで管理できる状態にする前準備を行いました。
今回Bobに任せた主なタスクは、次の3つです。

1.

プロジェクト構造の整理と構成ファイルの追加
2012年に作成されたJavaプロジェクトだったため、ディレクトリ構造や依存ライブラリが古く、そのままでは扱いづらい状態でした。.gitignoreの作成、README.mdの追加、Maven標準構造へのリファクタリングを進めました。

2.

既存コードからの設計仕様書の再構成
Excelベースの仕様書も残っていましたが、最新状態を把握するには実コードから再構成した方が確実だと判断し、Bobに解析させて設計仕様書を作成しました。

3.

Shell版からPowerShell版への変換
既存のUnix/Linux向けShell(ksh)を、Windows環境でも検証しやすいようにPowerShellへ変換しました。

ワークロードの実績

  • 実行タスク数:7つ(指示不足によるやり直しを含む)

  • 承認フロー:自動承認は使わず、内容を都度確認しながら進行

  • プロンプト介入:3回程度

  • 総入力回数:10回

  • 所要時間:2時間30分(Bobの処理待ち時間中に、本記事の執筆やキャプチャ撮影も実施)

短時間で前準備を一通り進められた点は、率直に使いやすさを感じたポイントでした。

IBM Bob 履歴画面

PMから見たBobとの付き合い方

事前設定なしでも、最初の一歩は進めやすい

AI駆動開発では、カスタム指示、技術スタック、利用ツール、ワークフローの定義などを詰めていくほど精度が上がります。一方で、そこまで整えるにはAI開発の知識だけでなく、モダンITの設計に関する理解も必要です。

今回はBobの素の実力を見たかったので、事前のカスタム指示やテンプレートはあえて与えず、ワークスペースに対象ソースを置いたうえで、「まず何が不足しているか」を聞くところから始めました。最初に投入したプロンプトは次のような内容です。

「2つのJavaプロジェクトのソースファイルディレクトリがあります。これらをMavenのJava projectとしてGitのリポジトリに管理したいです。まずはディレクトリの内容を精査して、不足する点を教えてください。」

Askモードでの、Bobの回答の一部です。

Bobの解析回答

その後の応答では、Bobが要件確認、Todoリスト作成、チェックポイントでの承認依頼まで含め、標準的な開発フローに沿った進め方を自然に提案してくれました。非エンジニアや、AI駆動開発にまだ慣れていないメンバーでも入りやすいと感じます。

もちろん、同じプロンプトでも出力がぶれる点は他のIDE型AIツールと同様です。実プロジェクトでは、AIと対話をしながら、基本設計段階でコンフィギュレーションやプロンプトテンプレートの整備をしていくでしょう。ただ、最初の探索や論点整理の段階では、事前設定なしでも十分に会話を始められる印象でした。

人はどこで介入しやすいか

生成AIを使ったIDEベースの開発で、PMとして特に気になるのは、開発者がAIをどう使い、どこで判断しているかが見えるかという点です。問いの立て方で生産性は変わりますし、AIの出力をどう評価するかで品質も変わります。
その意味で、Bobは「人が途中で入りやすい」設計になっていると感じました。

UIの見やすさ

まず印象に残ったのが、BobのUIの見やすさです。解析結果、選択肢、次の操作が比較的整理されており、チャットウィンドウ内でのやり取りを追いやすい構成になっています。
PMが途中で進捗を確認したり、レビュー観点を拾ったりするとき、単純に画面が見やすいことは想像以上に効きます。細かなことですが、運用時のストレスを減らす要素です。

BobのUI表示

ヒューマン・イン・ザ・ループ

以前、AIを安全に業務へ適用していくことは、「AIの自律性を少しずつ制御していくことだ」という話を聞いたことがあります。Bobには、まさにその発想に近いヒューマン・イン・ザ・ループの考え方が組み込まれています。
エンタープライズ開発を意識したチェックポイントがあり、ファイル読み込み、コード生成、保存といった場面でユーザー承認を求めます。Todoリストをウィンドウ内で編集できる点も含めて、PMが途中で判断を挟みやすい設計です。
「承認」を明示的に挟めることで、PMは後追いで結果だけを見るのではなく、途中の意思決定にも関われます。

チェックポイント画面

Semantic Routingによるモデル選択

Bobでは、ユーザーがモデルを手動で選ぶ方式ではなく、要求内容に応じてBob側がモデルを切り替える設計になっています。ユーザーが毎回モデル選択で迷わなくてよい点は、現場運用では扱いやすいと感じました。
もちろん、熟練の開発者にとっては「自分でモデルを選びたい」と感じる場面もあるはずです。一方で、PMの立場から見ると、利用者ごとの差が出にくく、運用のばらつきを抑えやすい点はメリットです。

長いタスクをどう扱うか

生成AIには、コンテキストウィンドウの制約や、長い入力で精度が落ちやすいといった特徴があります。Bobはその前提で、タスクを小さく分けながら進める方向へ自然に誘導してくれます。

サンプリング、チャンキング、MVP的な進め方

対象ファイル数や行数が多いとき、Bobは「一部を省略して読み込みます」「主要な機能だけ実装します」といった形で、処理対象を絞る動きを見せました。

タスクの分割処理

この挙動は合理的ですが、最終成果物の精度にそのまま影響する可能性もあります。今回のPowerShell変換でも、一部を省略したまま処理が終わっていた場面がありました。したがって、大きいタスクでは「どこまでを今回の対象にするか」を人が明示することが重要だと感じます。
ただ、タスク履歴から分割のされ方を追えるため、事後検証しやすいのは助かります。

外部メモリの活用

多数のファイルを対象にした調査では、影響範囲のリストをいったん外部ファイルへ書き出し、それを読み込みながら次のタスクを進める様子が見られました。複雑な作業を分解して扱ううえで、かなり妥当なやり方です。

チャットウィンドウのリセット

個人的に良いと感じたのは、タスク完了後に「新たなタスクを開く」よう促す設計です。同じスレッドで続けることもできますが、会話を切り替えるガイドがあることで、コンテキストが混ざりにくくなります。

新しいタスクの開始

知識はどう蓄積されるのか

インコンテキスト学習のように見えた挙動

設計書の出力様式を最初は指定せずに進め、途中で「この様式に合わせてください」と依頼したところ、Bobは構成を修正してくれました。さらに今回の試用では、次のタスクで既存の設計書を参照し、様式を寄せて出力しているように見える場面もありました。
恒常的な挙動だとまでは言えませんが、少なくともセッション内では、前の成果物を踏まえて出力を寄せる動きが確認できました。

タスク完了時のまとめ

タスク完了時に、実行内容がMarkdown形式でまとまるのも便利です。完了時点で振り返りがしやすく、その場で不足を補いやすくなります。

タスク完了まとめ

タスク履歴の蓄積

Bobは履歴画面から、プロンプト、入力、途中経緯、出力結果をMarkdownとしてエクスポートできます。作業の振り返りや状態管理がしやすく、担当者が変わっても引き継ぎしやすい点は、プロジェクト運営上かなり実務的な利点です。

まとめ

使い始めるための学習コストが低い

実装経験がそれほど多くないPMであっても、Bobの解析を手がかりに「いま何があり、何を更新すべきか」をタスク単位で把握しやすいと感じました。今回も、約2時間半で実装前のリポジトリ整備とツール変換まで進められました。
この使い始めやすさは、プロジェクト全体でAI活用を広げるうえで大きな意味があります。

エンジニアとの会話の質が変わる

Bobの履歴を参照しながら話せるようになると、エンジニアの集中を妨げすぎずに、PMとして実装状況や課題を把握しやすくなります。
「ここまではBobで確認した」「この判断はどこで入ったのか」といった会話がしやすくなれば、PMとエンジニアのコミュニケーションも少し変わってくるはずです。

PMにとっての安心材料もある

GA後に公開されたBobのドキュメントを見ると、編集前ファイルの自動バックアップや復元の仕組みなど、運用面で安心しやすい機能が用意されています。今後のブログで触れる予定の脆弱性対応に関する機能も含めて、PMとしては「安心して試しやすい枠組み」が整えられている印象です。
総じて、Bobは単なるコーディング支援ツールというより、プロジェクトの進め方そのものに影響を与える存在だと感じました。今後は、ロードマップ、カスタマイズ性、大規模開発への適応力を引き続き見ていきたいと思います。


※ 記載の製品名及び社名は各社の商標もしくは登録商標です。
※ IBM、ibm.comは、米国やその他の国におけるInternational Business Machines Corporationの商標または登録商標です。他の製品名およびサービス名等は、それぞれIBMまたは各社の商標である場合があります。現時点での IBM の商標リストについては、ibm.com/trademarkをご覧ください。

執筆者:
IBM Bob検証コミュニティ(基盤システム本部 モダナイゼーション部 代表編集)

連載コラム:IBM BobでAIエージェント開発を試してみた

エクサでは、様々なAIエージェントを検証していますが、セキュリティや規制が厳しいエンタープライズの基幹システム構築やレガシーモダナイゼーションにも適用可能な選択肢として、間もなく正式版が公開されるIBM Bobの活用も視野に入れています。
公開に先立ち、アーリーアクセス版を試用しましたので、その過程を共有します。

関連コラム

関連ソリューション

関連事例

お問い合わせ

CONTACT

Webからのお問い合わせ
エクサの最新情報と
セミナー案内を
お届けします