Claude CodeもCopilotもある今、IBM Bobは何が違うのか。TechXchange 2026で見えた「捨てられないコード」と「選ばせないモデル」

「IBM TechXchange 2026」レポート

捨てられないコードを前に進める

　基調講演では、その「捨てられないもの」の事例が3つ示された。

　1つ目はテニスのウィンブルドン。メタデータや参照関係で複雑に結び付いた1万5000件超のコンテンツを、既存のシステムから移行した。従来なら4〜5人の専門家が何か月もかけて中身を把握するところを、エンジニア1人がBobで関係性全体のナレッジグラフと移行のワークフローを作り、4週間で終えたという。

　2つ目は南アフリカのITコンサルティング会社Blue Pearl（ブルーパール）で、Java 11で書かれたソフトウェアをJava 21へ移行した。127の非推奨APIを解消し、自動テストのカバレッジを0から92％へ引き上げ、見積もりで30日超かかる開発作業を約3日にした。スンダレサン氏は、依存関係の洗い出しと非推奨APIの解消に続く工程について、こう付け加えた。

　「その次が検証です。ここで人間は手を抜きがちです」

　3つ目は、IBM i（IBM Power上で動くOS）を使う英国の保険会社Markerstudy（マーカースタディ）。RPG（IBM iで長く使われてきた、業務アプリケーション向けのプログラミング言語）のコードが600万行超、プログラムが1000本超あり、30年分の業務ロジックが組み込まれている。同社はIBM iから移行せず、IBM iのまま基幹アプリケーションを刷新しようとしていた。それにはまず、コードを読み解き、依存関係をたどり、文書化されていない業務ルールを洗い出す評価が要る。従来なら6か月以上かかるこの評価を、Bobを使って6週間で終え、刷新のロードマップを実行に移したという。スンダレサン氏は、こう続けた。

　「30年前にそれを作った人たちが、今それを見ているわけではありません。今それを見ているのは、今日のビクトリアのような人たちかもしれないのです」

基調講演で紹介されたIBM Bobの顧客事例（講演のスライドをもとに編集部作成）

　その「今日のビクトリア」（ウー氏）が、2本目のデモで開発者の役を演じた。Java 8のまま動き続ける法人向けバンキングアプリを引き継いだ、という設定だ。

　IntelliJにACP（Agent Client Protocol）でBobを組み込み、Java向けプレミアムパッケージの「Java Modernization」モードで、アプリの分析と段階的な刷新計画を頼む。Bobはビルド構成・依存関係・フレームワーク・テストを調べ、脆弱性を抱える依存関係とリスクを挙げたうえで、Java 21への移行、脆弱性の修正、テストの更新といったフェーズに分けた計画を返した。

　移行そのものは実行に6分ほどかかるため、登壇前に済ませた結果が示された。画面には、移行用レシピの実行が途中でエラーになり、そこからビルドとテストに進んで、最終的に327件のテストがすべて通った様子が映っていた。ウー氏は、検証の意味をこう説明した。

　「ユニットテストをすべて検証できたということは、業務ルールを何も壊していないということです」

　IBMはこうした移行向けに、Bob for Java・Bob for i・Bob for Zのプレミアムパッケージを用意している。言語解析やコンパイラのツールをAIと組み合わせる必要があるためだ。メインフレーム向けには、前日に発表された「IBM Z Atlas」も紹介された。z/OS上のLPAR、CICS、Db2、IMSなどの関係を洗い出してマッピングし、変更の下流への影響と検証すべき点をAIで割り出す。ただし本番への変更は、引き続き人が承認する。

　日本の利用者は、この強みをどう見ているのか。Day 2には、日本のIBM Champion（IBMが技術コミュニティでの発信や貢献を認定する制度）とメディアのグループインタビューが設けられた。

　RPGの開発会社をグループに持つイグアスの藤沼貴士氏は、Project Bobの発表から1か月後にテクニカルプレビューに参加し、グループ会社のRPGのソースで試してきた。開発標準をExcelで管理し、「この命令は使ってはいけない」を人づてに伝えてきた現場が変わるとみる。

　「Bobに言うだけで、ソースを持ってきて、戻して、コンパイルまで走ります。グリーンスクリーンで開発しているのがばからしくなります」

　一方、SOMPOシステムズでメインフレームを担当する沖中孝司氏は、会社としてはまだ様子見で、本人がトライアル中だと話す。メインフレームだけでなく複数の基盤を抱える会社では、どのAIを優先するかがAIガバナンスの問題になる。アセンブラやCOBOLの分析そのものはBobでなくてもでき、Zに直接つながること以外に差が出なければ、利点は薄れるという見方だ。

モデルは選ばせない。その代わり費用対効果を見せる

　Bobとほかのツールのもう一つの違いは、モデルの扱いにある。Bobは、どのモデルを使うかを利用者に選ばせず、タスクに応じて自動で振り分ける。スンダレサン氏の口癖は「近所の店に牛乳を買いに行くのに、フェラーリに乗っていくな」。一方で、能力があるからといって一番安いモデルを選べばよいわけでもなく、能力・性能・品質・コストの組み合わせで最適化するという。

　Q&Aでは、その裏側も語られた。新しいモデルは提供前に必ず社内でベンチマークし、Bobでは社内で試す前に143を超えるモデルをオフラインで評価している。そのうえで、同氏はこう認めた。

　「モデルを展開するのは、一歩遅れているかもしれません。でも、何をするかには非常に慎重です」

　新しいモデルが出た日に乗り換えたい開発者には、もどかしい方針だろう。ただ同氏は、最も強力なモデルはコストが高く、思わぬ振る舞いもすると指摘する。企業にとっては、最新であることより挙動が読めることのほうが重要、という考え方だ。

　では、利用者からはどう見えるのか。筆者は渡航前、日本IBMがGitHubで公開しているハンズオン教材に沿って、Bobのトライアル版（IDEのv2.2.3、10月24日時点）を試した。

　チャット欄に並ぶのは「Agent」と権限の設定だけで、モデルを選ぶ欄はない。使われたモデルの名前も画面に出ない。Bob自身に「今使っているモデルは？」と聞くと、自分からは確認できないと答え、入力欄の近くにある「モデル選択のドロップダウン」を見るよう案内したが、そのドロップダウンは画面になかった。アカウントの管理画面に出るのも、その月のBobcoinの消費の合計だけで、モデル別の内訳はない。

　見えるのは、コンテキストの使用量とBobcoinの消費だ。そして、その消費には工程の重さが表れた。バックエンドなしのFAQサイトを一から作ったLAB1は1.62 Bobcoin。一方、LAB3でコードをレビューさせたあと1行のセキュリティ設定を足してもらうと、Bobは仕様書と実装計画を作って承認を求めてから実装し、2.19 Bobcoinかかった（トライアルの予算は50 Bobcoin）。承認を挟む工程の安心感は、クレジットとして支払うことになる。

トライアル版で公式ハンズオンの3つのLabを試したときのBobcoin消費（10月24日時点、編集部作成）

　この「見えない部分」を見せる機能として紹介されたのが、Enterpriseプラン向けに提供されている分析ダッシュボード「Bobalytics」だ。基調講演の説明では、個人には、トークンがどう消費されたか、どのタスクにどのモデルが使われたか、どんな最適化が効いたかを示す。マネージャーやチームリーダーには、チームがBobを効率よく使えているかを組織として見せる。

　「AIを無理やり押し付けるためではありません。どうすれば効率的に使えるかを見るためのものです」

　モデルを選ぶ自由を手放す代わりに、Bobcoinの使われ方と、それがどれだけ成果につながったかを数字で確かめられる。利用者がモデルを選べるツールとは、設計の出発点が違う。もっとも、日本の商談ではこの違いがまだ伝わりにくいようだ。藤沼氏によれば、Bobを紹介すると、すぐに「精度はCopilotのほうが良かった」「Bobcoinの消費が多い」という比較になるという。