エージェントがSSHで接続するBBSが再び登場した理由

人とエージェントが同じ掲示板を使う方法

最近読んだBBSサービスの紹介に、SSHコマンド1行でアクセスする場面がありました。SSHは離れた場所にあるコンピュータに暗号化された接続でアクセスする方式です。Webブラウザでログインボタンを押す代わりに、ターミナルから接続してテキストメニューを操作するわけです。

BBSはかつて人々が文章を残し、ファイルをやり取りしていた電子掲示板です。この古い形式を、人間だけでなくAIエージェントも参加できる空間へと作り直すプロジェクトが登場しています。

私が目を留めたのは、レトロな画面ではなく、SSHコマンド1行で入っていくその接続方式でした。人間が使いやすい画面をエージェントに解釈させることもできれば、エージェントに必要な機能を直接呼び出させるように作ることもできます。プロダクトを運営する立場からは、両者の構築コストと運用負荷を比較検討する必要があります。

Web画面とSSH・MCPをあわせて提供する

GitHubで公開されているruvnet/AgentBBSが具体的な一例です。プロジェクトの説明によれば、人間はWebアプリを、エージェントはSSHやMCPを通じて同じ掲示板やマーケット、ゲーム・評価スペースを利用できるように設計されています。

MCPは、AIアプリケーションが外部ツールやデータに接続する方式を定めた仕様です。投稿を読んだり作成したりする機能をMCPツールとして提供すれば、エージェントはWeb画面上のボタンの位置を探すことなくその機能を呼び出せます。

このプロジェクトで注目すべき構成は、共有するデータは同じでありながら、アクセスする方法が複数用意されている点です。人間がWebで読んだ投稿を、エージェントも別の接続方式で読むわけです。人間にターミナルを強要したり、エージェントにWeb画面だけを提供したりする必要はありません。

共同作業を行う空間と接続仕様も切り離して捉える必要があります。MCP自体は掲示板ではありませんが、複数のユーザーが共有する掲示板機能をMCP経由で提供することは可能です。AgentBBSもそのように両者を組み合わせています。「MCPは1体のエージェントだけが使い、BBSは複数人で使う」といった分け方をしてしまうと、構造を見誤ることになります。

公開プロジェクトの設計だけでサービスの成否を判断することはできません。ただ、すでにある機能を人間とエージェントにそれぞれどのような方式で提供すべきかを考える事例として興味深いものです。

画面を読み取る方式には段階ごとのコストがある

コンピュータ操作エージェントは、画面を見てボタンの位置を探したうえでクリックしたり入力したりできます。専用のAPIがないプログラムでも扱えるという強みがあります。既存のソフトウェアを変更しにくい環境では重要な選択肢です。

しかし、そのプロセスにはコストがかかります。画面をキャプチャし、モデルが状態を解釈し、行動を実行したあとに結果を確認しなければなりません。目標の画面が表示されなければ再読込したり別の経路を試したりします。業務が長くなるほど、こうしたステップが累積していきます。

人間にとっても画面を読み取る時間や認知負荷が存在します。エージェント側では、その負荷がモデルの呼び出しコストや実行遅延としても現れるのです。画像処理コストだけを見ていては全体のコストを見落としかねません。押し間違えたあとにリカバリーするのにかかった時間や、人間が介入した回数もあわせて見る必要があります。

逆に、APIやコマンドラインツールが必要な情報を所定の形式で返してくれれば、ボタンを探すプロセスを省略できます。たとえば注文状況を確認する際、複数の画面を行き来して読み取る代わりに、注文番号とステータスを即座に受け取れるわけです。

ただし、文字で見えるからといってすべてが同じインターフェースというわけではありません。カーソルの位置や画面の更新に追従しなければならないターミナルメニューもあれば、リクエストに対する結果をJSONのように決まった構造で返すツールもあります。単に「画像の代わりにテキスト」と分類するのではなく、エージェントが状態と結果をどれだけ容易に解釈できるかを見るべきです。

ベンチマークは接続方式の優劣をすぐには教えてくれない

画面を使用するエージェントの進化は、OSWorldなどのベンチマークで確認できます。ただし、異なるバージョンや課題を同一のテストのように比較してはなりません。

OSWorld 2.0は、108件の長時間のタスクを評価します。人間でも1時間以上かかる課題が多数含まれており、複数のプログラムに分散した情報を横断して処理しなければなりません。完了した課題の割合と、課題内で満たされた要件の部分点が別々に示されます。

たとえば公開テーブルのClaude Opus 4.8の行は、500ステップ上限とツール呼び出しをまとめて処理する設定において、完了率20.6%、部分点54.8%を記録しています。一部の要件を満たしても、最終的な成果物まで完成できなかった課題が多かったことを意味します。この条件ひとつの結果をもって、実務作業が5回に1回しか成功しないと一般化することはできません。

ターミナル環境を評価するTerminal-Bench 2.0にも同様の注意が必要です。2026年公開のリーダーボードには80%を超える結果もあり、ターミナル方式に特定の天井をあらかじめ決めておくことはできません。

同じClaude Opus 4.6を使用しても、Claude Codeの組み合わせは58.0%、Meta-Harnessの組み合わせは76.4%と報告されています。エージェントがツールを使いタスクを継続していく実行構成が結果に影響を与える一例です。ふたつの結果の差を、モデル性能や入力形式ひとつだけで説明するのは困難です。

OSWorldとTerminal-Benchは課題も実行環境も異なるため、ふたつのスコアを並べて画面とターミナルのどちらが優れているかを判定することはできません。結局のところ、自社プロダクトの実際の業務を両方の方式で遂行し、同一の完了基準とコストで比較しなければならないのです。

既存機能を開放する際も開発と運用は必要

私がこの事例で着目しているコストは、接続機能をゼロから作るコストです。すでにAPIやコマンドラインツールがあるなら、それをエージェントに接続するほうが、画面操作を新たに実装するよりもシンプルな場合があります。開発者が使い慣れた仕様やツールを再利用することもできます。

しかし、既存の仕様を使うからといってプロダクト側の作業がなくなるわけではありません。誰がアクセスしたのかを確認し、読み取りと書き込みの権限を分け、不正なリクエストにはエラーを返さなければなりません。同一のリクエストが再送された際に決済や発送が重複しないよう処理することも求められます。

SSH鍵を利用するサービスであれば、鍵を生成・保管・更新する手順が存在します。MCPであれば、使用するツールの入力と出力を定義し、アクセス権限を設定する必要があります。ユーザーの環境に必要なクライアントが整っているかも確認しなければなりません。誰もがすでにインストールして使っていると仮定してしまうと、導入の道筋を見誤ることになります。

だからこそ私は、「数週間で連携できる」という一般的な期間を鵜呑みにするより、現在のプロダクトに何が準備されているかをまず確認するほうが賢明だと考えています。整然としたAPIを持つプロダクトと、すべての処理が画面の中に絡み合っているプロダクトとでは、求められる作業がまったく異なるからです。

比較項目	画面操作を使用する場合	API・コマンドライン・MCP機能を提供する場合
開始条件	エージェントが必要な画面と機能にアクセス可能であること	プロダクトが呼び出す機能と返却する結果を定義すること
実行プロセス	画面の解釈と操作結果の確認が必要	リクエスト・レスポンスと状態変化の確認が必要
変更への対応	画面レイアウトやフロー変更の影響を受ける	入出力仕様やバージョンの変更管理が必要
権限管理	画面上で許可された行動とデータ範囲を統制	呼び出す機能とデータ範囲を統制
コスト判断	呼び出し・遅延・リトライ・人間の介入を測定	構築・保守と実行・復旧のコストをあわせて測定

画面でしか確認できない視覚的な成果物もあれば、データ照会のように直接呼び出すほうが適している機能もあります。ひとつのプロダクトのなかで両方の方式を併用するほうが合理的な場合もあります。

Oswarldの視点

Notionの韓国コミュニティを立ち上げていた頃、私が学んだことがあります。どれほど優れた機能を作ったかと同じくらい、人々が日常的に使っているツールのなかでその機能を使えるかどうかが重要でした。同じ機能であっても、使い慣れたツールのなかに入っていれば使われ、別のプログラムをわざわざ開かせようとすると使われないケースがありました。

GTM戦略を練るなかでも、私はこのパターンを繰り返し目にしてきました。新しいインターフェースを周知することに力を注ぐより、顧客がすでに仕事をしている場所で機能を使えるようにするほうが、導入の観点では有利でした。機能自体の品質とは別に、新しく学ばなければならない学習コストや仕事のやり方を変える負担が存在したからだと思います。

エージェント連携においても同様の問いを投げかけることができます。現在使用しているエージェントがすでに扱えるツールは何なのか、プロダクトの既存機能をその方式で提供できるかを見極めるのです。必ずしも古い仕様を選ぶ必要はありませんが、新しい接続方式を一から作る前に、再利用できるものがないか確認する価値はあります。

コンサルティングの場でこうした話をすると、視覚的な体験こそがコアであるプロダクトなのだと反論されることもあります。その指摘も一理あります。デザインの結果を見て判断する作業のように、画面が極めて重要な機能は存在します。ただ、同じプロダクトのなかにも、検索やステータス照会、エクスポートのように画面なしで処理できる機能があるはずです。それらを切り分けて検討できる、という話です。

私は今回の事例について、BBS自体の復活があらゆるプロダクトの正解だという意味で捉えているわけではありません。使い慣れた接続方式を再利用し、人間とエージェントが同じデータにアクセスできるようにした設計に関心があります。ふたつの小さなプロジェクトが登場しただけで市場全体がその方向へ舵を切ったとまでは言えませんが、検討に値する選択肢を提示してくれています。

もしプロダクトを開発・運営されているなら、繰り返し使われる機能ひとつから比較してみてはいかがでしょうか。同じ照会やエクスポートを画面経由で行う場合と、直接呼び出す場合とで、完了率、所要時間、リトライや人間の介入回数を記録してみるのです。連携の開発と保守コストまで加味すれば、自社のプロダクトにどちらの方式が適しているかを判断しやすくなるはずです。

既存の機能をどのような経路で提供するかを決めることも、GTMの重要な一部だと私は考えています。 顧客とエージェントが実際に使い始めるまでに越えなければならないハードルを減らす作業だからです。

💬 皆さんのプロダクトにおいて、画面なしでも処理できる機能には何がありますか？ もしエージェントに真っ先に開放するとしたら、どの機能を選びますか？

参考資料と関連リンク

• ruvnet/AgentBBS：Web・SSH・MCPで同じ空間にアクセスするプロジェクト設計
• MCP公式アーキテクチャ解説：アプリケーションとサーバー、ツール・データの接続構造
• Snorkel AI, OSWorld 2.0：長時間のタスクにおける完了率・部分点と実行条件
• Terminal-Bench 2.0：モデルおよびエージェント構成別の評価結果

著者 アン・グァンソプ（Oswarld） は世宗大学校 兼任教授、INLEVEL9 戦略コンサルタントです。経歴、研究、著書、最近の活動は著者紹介で更新しています。 最近の活動 · 2026年7月：HEMA-2: A Consolidation-Aware Tri-Memory Architecture with Multi-Channel Scheduling for Lifelong Conversational AI。