ServiceNow Research所属のBechardらは2026年3月31日に「Terminal Agents Suffice for Enterprise Automation」(arXiv:2604.00073)を公開しました。要点は、シェルとファイルシステムだけ与えたコーディングエージェントが、MCPツール統合型やブラウザ操作型より同等以上の精度で5〜9倍安いという結論です。
本記事では、ServiceNow・GitLab・ERPNextの3システムで検証された結果とStarShell実装の直感を整理します。日本企業が社内自動化で「どの層のエージェント設計に投資すべきか」を読み解く視点を示します。
Terminal Agents論文の本質は、「抽象化レイヤーを足さず、強い基盤モデルにAPIを直接触らせた方が良い領域がある」という主張です。
要点は次の3つです。
社内システムを自動化するエージェントを設計するとき、現場は2つの方向に引っ張られます。
ひとつは、Model Context Protocol(MCP)などのツール統合層を作る方向です。安全に呼べる関数だけを公開できる一方で、対象APIごとにラッパー実装と保守の負担が増えていきます。
もうひとつは、ブラウザを操作するWeb/GUIエージェントです。人が触る画面を直接動かせる柔軟さがある一方で、画面の構造変更で簡単に壊れ、トークン消費も大きくなります。
論文の問題提起は明確です。社内システムの多くはすでにREST APIやCLIを持っているのに、なぜ抽象化レイヤーを重ねるのか。**「シェルとファイルシステムを与えれば足りるのではないか」**という仮説を、実環境で検証した研究です。
著者らは「StarShell」と呼ぶターミナル型エージェントを構築します。
StarShellは、サンドボックスのシェルと永続ファイルシステムだけをLLMに渡します。エージェントはcurlでAPIを叩き、結果をJSONとしてファイルに保存し、必要なら再利用します。
ツールレジストリは持たず、新しい操作が必要なら、APIドキュメントをその場で読みに行きます。
StarShellの構造は3層に分かれます。
MCP型のように事前定義した関数群を持たないため、未知のエンドポイントにも応用が利きます。逆に言えば、安全に呼べる操作の絞り込みは、シェル側のサンドボックスとAPIの権限設計に委ねられます。
差分は、エージェントとAPIの間に「人が設計した抽象化層」を置かない点です。MCPがツールスキーマで安全と再現性を担保するのに対し、StarShellはAPI側のスキーマと権限設計を信頼します。
著者らは、ServiceNow・GitLab・ERPNextの3システムで成功率(SR)と1タスク当たりコストを比較しました。代表的な数値は次のとおりです。
| プラットフォーム | ターミナルSR | WebエージェントSR | MCPツールSR | ターミナル平均コスト | Web平均コスト | 実務上の読み方 |
|---|---|---|---|---|---|---|
| ServiceNow | 73.6% | 72.4% | 11.5% | $0.78 | $4.49 | API中心の業務でMCP層は逆効果 |
| GitLab | 76.5% | 82.9% | 45.2% | $0.28 | $0.88 | UI操作主体ならWeb型が優位 |
| ERPNext | 67.6% | 61.8% | 55.6% | $0.46 | $3.63 | 多段ワークフローでターミナルが有利 |
数値は論文arXiv版v2(2026年4月3日改訂)の本文・付表に基づきます。
3つの読み方を分けて押さえます。
評価対象モデルはClaude Sonnet 4.6・Opus 4.6、GPT-5.4 Thinking (Medium)、Gemini 3.1 Proの4種類です。
Sonnet 4.6ではERPNextでターミナル型が+6.8ptと最も改善しました。Opus 4.6では「プランナー＋実行者」構成がGitLabでむしろ精度を下げる(76.1% vs 80.2%)現象も報告されています。
著者らは、ターミナル型が苦手な領域を明示しています。
論文自体の限界として、次の点も意識する必要があります。
「ターミナル型は安いから常に最適」という結論には飛ばないことが重要です。論文も**「ターミナルとブラウザ系の併用」**を推奨しています。
中小企業がこの論文を社内自動化の判断に使うときは、次の順で整理します。
API中心の業務(チケット起票、レコード更新、レポート生成)が多い場合は、ターミナル型寄りの設計がコストと精度の両立に効きます。
LLM評価とコスト監視の基礎はLLM評価・モニタリング実践の記事、コスト最適化はプロンプトキャッシュ・コスト最適化の記事もあわせて参照してください。
本論文は、エージェント設計の議論を「複雑なツール統合 vs 抽象化を引いた最小構成」という軸で整理し直す価値があると評価しています。
特に社内のデータ基盤や業務システムにAPIが整備済みの企業では、MCPサーバーを増設するより、API権限設計とサンドボックス設計を磨く方が安く済む可能性があります。
一方で、ターミナル型がそのまま日本企業の現場に乗るとは限りません。理由は3つです。
Blackford DataRoidは、社内データ基盤の整備と業務システム連携の設計を支援しています。API整備・権限分割・ログ集約まで含めて整えると、ターミナル型・MCP型・Web型のいずれを選んでも、エージェント実装の選択肢が広がります。
A. 置き換えではなく併用が推奨されています。論文も、UIに固有の操作や対話型エディタが必要な場面ではブラウザ系との組み合わせが有効だと述べています。社内システムの大半がAPIで完結する企業ほど、ターミナル型の比重を高める設計に妥当性があります。
A. 論文付録に実装の概要は示されていますが、本番導入にはサンドボックス境界・API権限・監査ログの設計を企業側で行う必要があります。Skills相当の再利用スクリプトのレビュー運用も合わせて整える必要があり、PoCではなく組織横断の運用設計が前提になります。
A. 論文の検証対象は海外SaaS(ServiceNow・GitLab)とオープンソースERP(ERPNext)に限られます。日本のSaaSやERPは公開APIの粒度が異なるため、自社環境で小規模なPoCで精度・コストを再計測することが必要です。論文の数値はあくまで参照値として扱うのが安全です。
A. 論文ではClaude Sonnet 4.6・Opus 4.6、GPT-5.4 Thinking (Medium)、Gemini 3.1 Proの4種類を比較していますが、システムや構成によって最適モデルは変わります。Sonnet 4.6はERPNextで強く、Opus 4.6は構成によってはむしろ精度を落とす場合もあります。社内自動化では、コストと精度の両面でモデルを継続評価する設計が前提になります。
ServiceNow Researchの「Terminal Agents Suffice for Enterprise Automation」は、エージェント設計に抽象化レイヤーを足すべきか引くべきかという重要な問いを実証データで提示しました。
API中心の社内業務であれば、ターミナル型は精度・コストの両面で有力な選択肢です。ただし、セッション依存や対話型UIには弱いため、Web型やMCP型との併用を前提に運用設計する必要があります。
自社の社内システムでどの設計が適しているか判断に迷う場合は、API整備状況とエージェント運用要件を整理したうえで、専門家に相談しましょう。
