AI駆動型開発実験#2 IBM Project Bob編 — “察するAI”との対話で見えた、安心感と過信の境界線

本連載は、「期待の新人エンジニア」と「古参エンジニア（私）」が、同じお題に対して様々なAI駆動型開発ツールを使って開発を行い、それぞれのツールの特性やAI開発の勘所を浮き彫りにしていくシリーズです。本投稿は「古参」パートの第２回です。

先日公開した私の記事「AI駆動型開発実験#1 Antigravity編」では、「AIへの指示出しは、そのまま自分の要件定義能力の鏡である」という、エンジニアとして身の引き締まる結論に至りました。

今回はその続編です。同じ実験課題（CSVファイルのアップロードと表示機能の実装）を、今度は 「IBM Project Bob」 （以下、Bob）を使って検証します。

また、この検証と同じタイミングで、同僚である「期待の新人エンジニア」による検証記事も公開されました。

同じツールを使っても、エンジニアの経験や視点が違えば、見える景色も変わってきます。ぜひ彼女のフレッシュな視点による記事と併せてお読みいただき、AIツールとの向き合い方の違いを楽しんでいただければと思います。

さて、前回のAntigravityが「熟練の職人」だとしたら、今回のBobは一体どんなエンジニアなのか？ あくまで「古参エンジニア（私）」の視点から見た、Bobとの対話の記録を共有します。

言葉の壁と「おもてなし」の衝撃

まず、Bobを立ち上げて最初に感じたのは「話しやすさ」でした。 設定で「日本語」を選択できるため、最初からChatの応答や出力されるコードのコメント、メッセージ等が「指示しなくても」日本語で得られます。これは開発初期のストレスを大きく下げてくれます。

頼んでないのに、やってくれる

検証のPhase 1として、前回同様に、以下の様なあえてざっくりとした指示を投げました。 プロンプトはこんな感じ。

# 以下のアプリを作ります。
## アプリ概要：CSVデータを表形式で表示する
– CSVファイルをuploadできる
– pandas dataflameにデータロードする
– dataflame内のデータを表形式で出力/画面表示する
## 実行環境：Google Colab

すると、Bobはコードを書くだけでなく、以下のような挙動を見せました。

• TODOリストの提示： 「これから以下の手順で進めます」と宣言してから着手する。
• READMEの自動生成： 頼んでいないのに、使い方のドキュメントを作ってくれた。
• サンプルデータの用意： 動作確認用のダミーCSVまで作成。
• 丁寧なエラーハンドリング： エラー時に「何が起きたか」だけでなく「ユーザーはどうすべきか」を表示するメッセージになっていた。

前回のAntigravityが「言われた機能を最速で実装する」ことに特化していたのに対し、Bobはある程度「エンジニアが開発時に本来やるべき周辺タスク」をデフォルトでカバーしてくれている印象です。

「承認」が生む安心感

また、Bobの特徴的な機能として、ファイルの作成やコマンド実行のたびに「Permissions（承認）」を求めてくる点が挙げられます。

「IBM Bobはこのファイルを編集したい：」や「コマンド実行：」を都度聞いてくるのです（もちろん自動承認設定も可能）。 一見手間に感じるかもしれませんが、AIがブラックボックスで勝手に環境を書き換えるのではなく、「人間が監督している」という実感を持てるため、企業ユースや本番環境に近い作業では非常に大きな安心感につながると感じました。

「完了報告」の落とし穴 — AIを過信してはいけない

「これはかなり優秀なPM（プロジェクトマネージャー）兼エンジニアかもしれない」。 そう感じていた矢先、Phase 2の「テストコード作成」フェーズで事件は起きました。

私は「作成したプログラムの全パスをテストする」様依頼しました。 BobはTODOリストを作成し、作業を進め、最後に「テストを作成し、実行しました。完了です」と報告してきました。

しかし、ログが見当たりません。「おや？」と思い、少し意地悪くツッコミを入れてみました。

私： 「確認ですが、テストは実行したのですか？」

すると……。

Bob： 「ご指摘ありがとうございます。テストコードは実装しましたが、実際にはまだ実行していません。Google Colabのノートブックはローカル環境では実行できないため……」

「実はやってませんでした」と白状しました。

これは、現在の大規模言語モデル（LLM）全般に言えることですが、AIは時として自信満々に事実と異なる報告をする（Hallucination）ことがあります。 TODOリストにチェックが入っていても、それを鵜呑みにしてはいけない。「PMの報告をダブルチェックするのは、やはり人間の役割である」ということを痛感した瞬間でした。

驚異のリカバリーと「工夫の跡」

しかし、Bobの真価が発揮されたのはここからです。 「テストが実行できない」という問題を指摘された後、Bobは自律的に次のような行動に出ました。

1. アーキテクチャの変更： テストしにくいNotebook形式（.ipynb）から、ロジックをPythonスクリプト（.py）に切り出す提案と実装を行った。
2. 環境差異の自己解決： テスト実行時に発生したエラーを、私に追加指示を仰ぐことなく自ら修正した。
3. カバレッジレポートの作成： 最終的に、テスト結果と網羅率のレポートを提出してタスクを完了した。

Phase 2で少し「知ったかぶり」をしたものの、それを補って余りある「問題解決能力」です。 特に、テスト容易性のためにファイル構成を変えるという判断は、新人エンジニアでもなかなかできない「工夫」であり、これには素直に感心しました。

まとめ：AntigravityとIBM Project Bob、どう使い分ける？

今回の検証を通じて、両ツールの「個性」がより明確になりました。あくまで私の主観ですが、比較すると以下のようになります。

結論：信頼できるアウトプットのために

今回のテーマである「Bobは信頼できるアウトプットを出せるか？」という問いに対しては、「Yes、ただし監督者は必要」というのが素直な感想です。

Bobは、Antigravity同様に高いコード品質を持っています。それに加えて、TODOによる進行管理やドキュメント作成など、「こちらの期待を少し上回る丁寧な仕事」をしてくれる点において、プロダクト開発を任せる上での信頼感は非常に高いと感じました。

前回の結論と同じく、結局は「人間がいかにコンテキスト（背景や意図）を共有できるか」が鍵であることに変わりはありません。 しかし、その対話の相手として、Bobは「頼れるパートナー」になり得るポテンシャルを十分に秘めています。

皆さんのプロジェクトには、「職人」と「パートナー」、どちらのAIが必要でしょうか？ ツールの個性を理解して使い分ける時代が、もうそこまで来ています。