IBM Bobがファイアウォールの内側へ、それがすべての要点

IBMは、エージェント型ソフトウェア開発プラットフォーム「IBM Bob」のセルフホスト版を提供開始した。オンプレミス、プライベートクラウド、主権クラウド、エアギャップ環境へのデプロイがすべて可能だ。顧客は独自のモデル構成を選択でき、ソースコードとアプリケーションコンテキストを自社ネットワーク内に保持し、データレジデンシーとセキュリティポリシーの管理権を維持できる。

それはデプロイ方法の補足説明のように聞こえる。しかし実際は、誰がコーディングエージェントを使えるのかという根本命題に近い。

セルフホストが埋めるギャップ

コーディングエージェントの進歩は速い。リポジトリを読み、変更を提案し、テストを実行し、プルリクエストを開く。スタートアップなら、クラウドサービスに組み込むのは火曜日の午後の仕事だ。しかし防衛請負業者、銀行、病院システムにとって、同じことをすれば最初の法務レビューで止まる。ソースコードは建物の外に出せない。コードベースを理解可能にする厄介な組織的知識である内部コンテキストも、外に出せない。エアギャップ環境には、設計上、クラウドへの経路が存在しない。

その結果、経済の大きな部分は、ガラスの向こうからエージェント時代を眺めている。IBMはその層に売り込んでおり、最初の企業ではない。このカテゴリは今のところ小さい。主な理由は、セルフホスト型エージェントにはモデルの重み、ハードウェア、そして通常クラウドベンダーが提供するオーケストレーション層が必要だからだ。この配管を解決した企業は、APIファーストのラボが到達できない顧客基盤を手に入れる。

見た目より難しい理由

エージェントは、単一のものとしてより、ループとして理解するほうが簡単だ。計画し、行動し、観察し、調整する。クラウドでは、呼び出すツールはサービスであり、障害モードは他人の問題だ。ファイアウォールの内側では、エージェントは同じリポジトリ、同じチケットトラッカー、同じビルドシステムに到達しなければならない。ただしネットワークは分断され、認証情報は定期的にローテーションされ、サービスの半分は「エージェント」という言葉が意味を持つ前に最後の更新が行われている。

IBMの提案は、同社がすでにこうした環境に販売しているという事実に依拠している。その顧客は、誰も触りたがらないメインフレームやレガシーシステムを運用している。そこでエージェントを動作させるのは地味で遅い作業だが、まさに堀を生み出す種類の仕事だ。

ガバナンスの側面もある。そしてそれは繰り返し浮上する論点だ。セルフホスト型エージェントは、自社が所有するログを生成する。規制下の監査では、どのモデルが実行され、何を読み、何を変更したかを正確に示せる。クラウド構成では、その証拠はベンダーのコンソールとサービス契約に分散している。何か問題が起きたとき、「ログを持っている」と「ログを請求した」の違いは、インシデントを閉じられるか、四半期を証拠開示に費やすかの違いになる。

根底にあるモデルの問題

エージェントをセルフホストするとは、モデルをセルフホストすること、少なくとも自社のシリコン上に置けるモデルを選ぶことを意味する。IBMは顧客がサポート対象の構成を選択できるようにしており、実際にはオープンウェイトモデルとIBM独自モデルの混合だ。ここではオープンウェイトの選択肢が重要になる。プライベートクラスタで動く70Bクラスのモデルは、最高のホスト型モデルより遅く、能力も低い。しかし、ネットワークがダウンしたとき、ベンダーが値上げしたとき、あるいは読んだこともないポリシーにあなたのユースケースが違反するとベンダーが判断したときにも利用できる。

企業はこの10年、データベースで同じトレードオフを行ってきた。そして同じ結論に至る。制御と引き換えに能力差を受け入れ、ハードウェアの進歩とともに時間をかけて差を埋めるのだ。

ファイアウォールの内側では経済性が異なる

クラウドのコーディングエージェントはトークン単位で課金される。つまりコストは、エージェントが読むコードと書くコードの量に応じて増える。スタートアップにとっては予測可能な費目だ。しかし大企業では、単一のリポジトリに数十年の履歴が含まれ、エージェントが役立つ前に大量のコンテキストを取り込まなければならないため、メーターはすぐに回る。

セルフホストはこのモデルを逆転させる。コストはハードウェアと運用になり、それは組織がすでに負担している資本支出だ。データセンターを持つ銀行は、エージェントがさらに100万行を読んでも追加料金を払わない。追加のエージェントタスクの限界費用は電気代とGPU時間に近づき、それらは埋没費用である。この非対称性があるからこそ、クラウド製品が客観的に優れていても、セルフホストの提案が刺さるのだ。

ただし、マーケティングが飛ばすコンプライアンスコストがある。セルフホストは、パッチ適用、監視、モデル更新の負担を顧客に移す。クラウドベンダーなら修正をプッシュすれば終わりだ。オンプレミス展開では、アップグレードをスケジュールし、内部システムに対してテストし、変更管理委員会を通過しなければならない。ツールはより制御可能になり、作業も増える。そのトレードオフこそがエンタープライズソフトウェアのすべてだ。

これを可能にする隣接市場

エージェントのセルフホストは、壁の内側で動かす価値のあるものがあって初めて機能する。そしてその供給は増えた。実際のコーディング作業ができる範囲のオープンウェイトモデルは今や一般的で、複数の大陸のラボから寛容なライセンスで公開されている。欠けていたのはモデルではなかった。欠けていたのは、制御されたネットワーク内で開発者が委任できるものへとモデルを変えるハーネスだ。

それこそがIBMが売っている層だ。最高のモデルを訓練することは目的ではない。クラウド呼び出しが選択肢にならない場所で、既存モデルを使えるようにする統合になることが目的だ。戦略はAPIファーストのラボの鏡像である。彼らは能力を外へ押し出し、誰でも接続できるようにする。IBMは能力を内へ引き込み、境界の内側で生き残らせる。

その境界の内側に閉じ込められた買い手にとって、ここ2年の選択肢は不快なものだった。遠くからエージェントの波を眺めるか、セキュリティルールを破って加わるかだ。セルフホストの選択肢は波を小さくするわけではない。ただ手が届くようにするだけだ。規制対象の組織にとって、それは現実にするのと同じ意味を持つ。

注目すべき点

セルフホスト型エージェントコーディングについて、デモは正直な問いではない。正直な問いは、15年分の技術的負債を抱え、すでに退職した人々が書いたコードベースで結果が持ちこたえるかどうかだ。クラウドエージェントもそこでは苦戦する。違いは、セルフホスト型エージェントは、顧客が作業をしない限り、ベンダーが一夜にして改善できないことだ。すべての改善は顧客自身のチームが勝ち取らなければならない。

そのため導入は遅く、粘着性が高くなる。IBMにとっては都合がいい。同社は、成功をスプリントではなく年単位で測り、検査できない優れたツールを借りるより、少し劣るツールを所有するほうを選ぶ買い手のために構築している。2年間ベンチマークを追い続けてきたコーディングエージェント市場にとって、それは保守的な賭けだ。同時に、まだ十分にサービスされていない市場部分への賭けでもある。

これが悪い方向に進む可能性もある。セルフホスト型ツールは、一度リリースされた後に停滞するという評判がある。ベンダーには改善を続ける継続的な動機がなく、顧客には要求する交渉力もないからだ。もしIBM Bobが、意味のある改善が決して行われない安定した製品に落ち着けば、惹きつけられた買い手は、求めていたものは手に入るが、期待したものには届かない。代替案、つまり顧客が管理するスケジュールでセルフホスト型エージェントが改善される道は、運用が難しく、はるかに価値がある。IBMがどちらを届けるのかが、今後1年で注目すべき点だ。