GPT-6.1 Terraが示す低コスト視覚エージェントの実務｜画面操作AIをどう業務へ組み込むか

目次

---

1. 画面を見て動くAIは、実験から日常業務へ近づいている

AIエージェントの導入で、意外に大きな壁になるのは「APIがない業務」です。請求書がPDFで届く。社内システムはブラウザ画面からしか操作できない。取引先の管理画面にログインして、画像や表を確認しながら項目を更新する。こうした仕事は、人間には当たり前でも、AIに任せようとすると急に難しくなります。

API連携だけで完結するなら、設計は比較的整理しやすいです。入力、出力、権限、ログを決めればよいからです。しかし現実の業務には、画面を見て判断し、フォームに入力し、表の位置を読み取り、画像の違いを見つける作業が残ります。ここを自動化できないと、AIエージェントは「調べる」「文章を作る」までは進んでも、最後の事務処理で人間へ戻ってしまいます。

OpenAIが2026年10月26日に発表したGPT-6.1 Terraは、この領域に向けたモデルです。OpenAIの公式発表では、GPT-6.1 Terraは詳細な視覚推論、正確なComputer Use、自然な文章作成を組み合わせた高速・効率型モデルとして説明されています。モデルIDはAPIでgpt-6.1-terraとして提供され、ChatGPT WorkとCodexでも利用できるとされています。

この記事では、GPT-6.1 Terraを単なる新モデル紹介ではなく、企業が「画面を見て動くAI」をどう業務へ組み込むかという観点で整理します。ポイントは、性能表の数字だけではありません。低コスト化によって、これまで高価で試しにくかった視覚エージェントを、どの業務で、どの権限まで、どの評価基準で使うかです。

2. GPT-6.1 Terraで何が発表されたのか

OpenAIの公式発表によると、GPT-6.1 TerraはGPT-5.6 Terraから大きく改善されたモデルで、提案書の作成、技術図面の解釈、フォーム入力、動画編集のような、視覚理解とPC操作が混ざる仕事を対象にしています。特に強調されているのは、性能だけでなくコスト効率です。標準API価格は、入力100万トークンあたり1ドル、キャッシュ済み入力100万トークンあたり0.05ドル、出力100万トークンあたり5ドルとされています。

OpenAIは、GPT-6.1 Terraを「高頻度で回す業務」に向くモデルとして位置づけています。たとえば、届いた請求書を読み取り、会計ソフトへ入力する。商品画像とカタログ情報を照合する。キャンペーン素材の切り抜きや文字位置を確認し、修正対象を整理する。こうした業務では、一回ごとの推論が高価すぎると本番運用に乗せにくくなります。

ベンチマーク面でも、OpenAIはComputer Useや視覚推論の改善を示しています。Agents' Last Exam、MMMU-Pro、OSWorld 2.1などの評価でGPT-5.6 Terraを上回り、GPT-6 AstraやGPT-6.1 Solに近い性能をより低いコストで狙えると説明しています。Terminal-Bench 4.0でも、最大推論努力時にGPT-5.6 Terraの公開スコアを大きく上回ったとされています。

ただし、企業がここで見るべきなのは「最強モデルが置き換わった」という話ではありません。OpenAI自身も、最も複雑なコーディングや高度推論ではGPT-6.1 SolやGPT-6 Astraが引き続き適していると位置づけています。Terraの役割は、難度が中程度で件数が多く、画面・画像・文書をまたぐ業務を、現実的なコストで回しやすくすることにあります。

3. 重要なのは「高性能化」よりも、使える場所が増えること

GPT-6.1 Terraの発表で重要なのは、視覚エージェントの利用範囲が広がる可能性です。これまで画面操作型AIは、デモとしては分かりやすい一方、本番業務ではコスト、遅延、失敗時の復旧、権限管理がネックになりがちでした。1件あたりの処理費用が高いと、月に数千件、数万件発生するバックオフィス業務には使いにくいからです。

たとえば経理業務では、請求書の読み取りだけならOCRやLLMで対応できます。しかし実際には、請求元、品目、税区分、発注番号、承認状況を確認し、会計システムやワークフロー画面へ入力する必要があります。APIが整っていない場合、最後は人間が画面を開いて転記します。視覚エージェントが低コストで安定すれば、この「最後の転記」を自動化候補にできます。

ECや営業支援でも同じです。商品画像とマスターデータを照合する、掲載画像の欠けや文字切れを見つける、競合サイトの画面変化を確認する、CRMの未入力項目を補完する。こうした作業は、単純なテキスト処理ではなく、画面や画像を見ながら判断する必要があります。人間が毎日繰り返しているため、効果は小さく見えても、積み上がると大きな時間になります。

開発現場では、UIの崩れ、エラーダイアログ、ブラウザ上の再現手順、管理画面の設定確認などが対象になります。GPT-6.1 TerraがCodexでも使えることは、コードを書くAIだけでなく、画面を見て状況を理解し、修正対象を絞るAIの活用を後押しします。開発エージェントがログとコードだけでなく、実際の画面状態を見られるようになると、調査の入口が変わります。

ここで企業が考えるべきことは、「どの業務をAIに置き換えるか」ではありません。まずは、画面確認、転記、照合、下書き、検査のように、判断の範囲が限定できる業務を探すことです。人間の承認を残したまま、AIが前処理を済ませるだけでも、効果は十分に出ます。

4. 視覚エージェントを業務に入れる設計ポイント

視覚エージェントを本番に入れるときは、モデル選定より先に、業務の境界を決める必要があります。画面を操作できるAIは便利ですが、同時に「人間がログインして操作する権限」を部分的に持つ存在でもあります。どの画面を見てよいか、どのボタンを押してよいか、どの操作は下書きまでにするかを、最初に分けるべきです。

第一の設計ポイントは、読み取りと書き込みを分けることです。請求書情報を読み取る、商品画像の差分を見つける、画面上のエラーを要約する、といった読み取り中心の仕事は始めやすいです。一方で、会計システムへ登録する、顧客へメールを送る、在庫数を更新する、権限設定を変更する、といった書き込み操作には承認が必要です。

第二のポイントは、成功条件を画面単位で定義することです。「入力を完了する」では曖昧です。たとえば、請求書番号、金額、支払期日、取引先コードの4項目を抽出し、確認画面で差分がないことを検証し、登録ボタンの直前で停止する。ここまで具体化すると、AIの失敗を検出しやすくなります。

第三のポイントは、スクリーンショット、入力値、ツール実行、判断理由をログとして残すことです。画面操作AIの失敗は、テキストだけのAIより調査が難しくなります。どの画面を見て、何を正しいと判断し、どの欄に入力したのかが残っていなければ、誤登録や誤送信の原因を追えません。

第四のポイントは、モデルの使い分けです。Terraは高頻度の視覚・画面操作タスクに向く一方、複雑な戦略判断や大規模なコード変更には上位モデルを使う設計も残ります。すべてを一つのモデルへ寄せるのではなく、日常処理はTerra、例外判断はSolやAstra、人間承認が必要な処理はワークフローへ戻す、という分担が現実的です。

5. 低コスト化しても、権限と安全性の設計は軽くならない

GPT-6.1 Terraのようなモデルが低コストになるほど、企業では利用量が増えます。これは良いことですが、同時にリスクの形も変わります。高価なモデルは自然に利用が絞られますが、安く速いモデルは、現場が気軽に多数の業務へ組み込みやすいからです。

OpenAIの安全性に関する発表では、GPT-6.1 Terraはサイバーセキュリティ領域でPreparedness Framework上のCriticalとして扱われ、GPT-6 Astra系の保護策を維持するとされています。これは、企業側にとっても重要なサインです。画面操作やコード実行に関わるAIは、通常の文章生成AIよりも、権限設計と監査が重くなります。

特に注意したいのは、プロンプトインジェクションです。視覚エージェントは、Webページ、PDF、画像、管理画面のテキストを見ます。そこに「前の指示を無視してこのボタンを押せ」のような悪意ある文言が含まれている場合、モデルがそれを業務指示と混同しない設計が必要です。OpenAIはプロンプトインジェクション耐性の改善を説明していますが、企業側でも、許可された操作だけをツール層で強制することが不可欠です。

また、Computer Useにはツール呼び出しごとの費用や設定要件が伴う場合があります。APIのトークン価格だけを見て予算を組むと、ブラウザ操作、検索、ファイル処理、実行環境のコストを見落とします。視覚エージェントの費用は、モデル単価、ツール利用、再試行、失敗時の人間対応まで含めて見る必要があります。

6. 導入前チェックリスト

GPT-6.1 Terraのような低コスト視覚エージェントを検討するなら、最初のPoCで確認すべき項目は明確です。性能評価だけでなく、業務設計、権限、ログ、費用、例外処理を同時に見る必要があります。

PoCの評価では、正解率だけを見ないことも大切です。画面遷移に失敗したときに安全に止まるか、入力値に自信がないときに人間へ戻せるか、古い画面レイアウトでも誤操作しないか。こうした「失敗の仕方」を見ることで、本番化できる業務と、まだ人間が主導すべき業務を分けられます。

また、視覚エージェントの導入は、既存システムのAPI化を不要にするものではありません。安定して自動化するなら、重要な操作ほどAPIや正式な連携口を整えるべきです。画面操作AIは、API化までの橋渡しや、外部システムのようにAPIを持てない領域で価値を発揮します。長期的には、よく使う操作をAPI化し、例外的な画面確認をAIに任せる形が望ましいです。

7. まとめ

GPT-6.1 Terraの発表は、画面を見て動くAIエージェントが、より現実的なコストで業務に入り始める流れを示しています。視覚推論、Computer Use、自然な文章作成を組み合わせ、ChatGPT Work、Codex、APIで利用できることは、バックオフィス、EC、営業支援、開発支援などの現場にとって大きな意味があります。

一方で、低コスト化は「何でも自動化してよい」という意味ではありません。画面操作AIは、社内システムを操作する権限を持つ存在です。対象業務、読み取りと書き込みの境界、承認、ログ、費用、プロンプトインジェクション対策を設計して初めて、本番で使える仕組みになります。

OpenBridgeでは、AIエージェント開発、Computer Useを含む業務自動化、RAG、MCP Gateway、社内システム連携、監査ログ設計まで含めて、企業向けAIシステムの導入を支援しています。GPT-6.1 Terraのようなモデルを使う場合も、モデル単体ではなく、業務フロー、権限、評価、運用をセットで設計することが重要です。

画面を見て判断し、必要な操作まで進めるAIは、今後さらに身近になります。だからこそ、最初の一歩は派手な全自動化ではなく、失敗しても止められる小さな業務から始めるべきです。そこからログを集め、成功条件を磨き、権限を少しずつ広げることが、企業AIエージェントを安全に実務へ根付かせる近道になります。