CopilotKitが公開したOpenBotがGitHubで1,541スターを集め、トレンド入りした。AIごとに専用PCを割り当て、全操作を承認・記録するという触れ込みだ。だが「AI同僚」という耳障りのいい言葉に踊らされる前に、この設計が抱える構造的な落とし穴と、日本企業が陥りやすい導入の罠を辛口で腑分けしておきたい。

何が起きたか

CopilotKitがOSSとして公開した「OpenBot」が、公開直後にGitHubトレンド入りし、1,541スターを獲得した。仕組みはシンプルで、AIエージェント一体ごとにブラウザ・ファイル・ツールがセットになった「専用PC環境」を丸ごと割り当てる。人間の社員に業務用ノートPCを配るのと同じ発想だ。特徴は二つ。第一に、エージェントの全操作を実行前に人間が承認し、実行後にログとして記録する監査設計。第二に、AG-UI（Agent-UI）準拠で、既存の社内エージェントをそのまま接続できる互換性である。これまで「暴走が怖い」「監査に耐えない」として本番導入を凍結してきた企業が動き始めた、というのが動画の骨子だ。

なぜこのニュースが重要か

重要なのは、OpenBotが「AIエージェントに責任範囲を割り振る」という発想を、OSSレベルで一般化しかけている点だ。これまでLangChainやAutoGenの議論は「どう賢く動かすか」に偏っていた。OpenBotはそこから半歩ずれて、「どう止めるか、どう記録するか」を先に設計している。これは金融・医療・法務のように監査ログが法的要件となる領域で、初めてAIエージェントを本番稼働させる下地になる。逆に言えば、この監査レイヤーを持たないPoCは、今後ほぼ全て「本番昇格不能」の烙印を押される。1,541スターという数字は派手ではないが、CTOやSREが黙ってブックマークしている類の数字だ。ここで注意すべきリスクは、「承認と記録があれば安全」という誤った安心感である。承認プロセスは人間のクリック疲れを引き起こし、3週間もすれば「全部承認」が常態化する。ログは取ってあっても、誰も見ない。監査設計は仕組みではなく運用の問題だという冷徹な事実を、OSSの美辞麗句は隠してしまう。

過剰評価への反論

「AI同僚」というフレーズは、はっきり言って営業用の詩である。エージェントごとにPC環境を渡すという構図は、裏を返せばインフラコストがエージェント数に比例して膨らむということだ。ブラウザセッション、ファイルストレージ、ツール認証情報を人数分抱えるのは、SaaSのライセンス費用を人数分払うのと同じ構造で、「AIだから安い」という前提は崩れる。推定だが、10体のAI同僚を常時稼働させれば、クラウド費用だけで月額数十万円規模に到達するケースは珍しくない。さらに深刻なのは、承認フローがボトルネックになる点だ。人間の承認速度を超えてAIは動けない。つまり「AI同僚10人」を雇っても、承認する管理職が1人なら、スループットはその1人の処理能力で頭打ちになる。これは古典的なアムダールの法則そのものだ。加えてAG-UI準拠という互換性の売り文句も、標準化されていないプロトコルへの依存であり、CopilotKitが方針転換すれば既存資産が孤立する。OSSだから安心、という思考停止は最も危険だ。1,541スターの熱狂は、半年後には「なぜ動かないのか」という運用現場の呻きに変わる可能性が高い。

経営者として次に取るべき動き

第一に、OpenBot導入の可否を「承認する管理職の可処分時間」から逆算せよ。エージェント数ではなく、承認者のキャパシティが上限だ。人事評価に「AI承認業務」を明記しないなら、導入は見送るべきである。第二に、監査ログを「取る」ではなく「読む」体制を先に作れ。週次で異常操作を人間がレビューする運用が設計されていないログは、コンプライアンス上の免罪符にならず、むしろ発見された時の証拠として牙を剥く。第三に、AG-UI依存のロックインリスクを見積もれ。CopilotKitが将来仕様を変更した場合の移行コストを、稟議書段階で算出しておく。この三点を潰せない企業は、OpenBotを「触ってみた」で終わらせるのが賢明だ。流行に乗るコストは、流行を無視するコストよりしばしば高い。