AIエージェントの「ハーネス」とは何か：Cowork時代の事務作業エージェントを3問だけ試して見えたこと
本文の状態
日本語全文を表示中
詳細モードで約23分の本文を読めます。
同じ出来事の情報源
この情報源を基点に整理
HEROZ Tech Blog
HEROZ Tech Blog は、AI エージェントの基盤である「ハーネス」概念を整理し、事務作業や表計算を含む実務タスクでの挙動を実験的に検証した結果、トークン消費量の増加とコスト対効果の重要性を指摘している。
AI深層分析を開く2026年7月31日 22:59
AI深層分析
キーポイント
AI エージェント構成要素の明確化
記事は AI、LLM モデル、エージェント、そして実行基盤であるハーネスを区別し、人間に例えてモデルが頭脳、ハーネスが作業環境であると定義している。
実務タスクにおける実験結果
コーディングだけでなく事務作業や表計算処理にも現代的なハーネスが適用可能であることが示唆された一方で、賢い動作の裏には大量のトークン消費があることが判明した。
コスト対効果の重要性
AI エージェントを「Cowork」として利用する際、単に機能するかだけでなく、どの作業領域でどの程度の費用対効果が得られるかが重要な判断基準となることを強調している。
ハーネス設計の重要性
ファイルの読み込み順序やコマンド実行のタイミング、失敗時の対処法などはモデル性能だけでなくハーネス側の設計に大きく依存する。
ツール接続と賢い作業の違い
MCP などの標準化でツール接続は容易になったが、中間結果の保持や探索範囲の判断など現代的なハーネスの強さが実務では重要となる。
重要な引用
現代的なハーネスは、コーディングだけでなく事務作業にも使えそう
AI エージェントを「LLM にツールを渡してループを回すもの」と捉えるだけでは、現代的なハーネスの振る舞いを説明しにくくなってきた
賢く作業できるようになった一方で、裏側ではかなり大量のトークンを消費している
実際の作業では、どのファイルを先に読むか、どこまで探索するか、中間結果をどう保持するか、コマンド実行結果をどう解釈するか、失敗したときにやり直すか、別案に切り替えるか、といった判断が大量に発生します。
編集コメントを表示
編集コメント
本記事は、AI エージェントの技術的定義を整理し、実務導入における現実的な課題であるトークンコストとコスト対効果を鋭く指摘している。具体的な製品名や企業名への言及はないが、開発者がハーネス設計や運用戦略を考える際の重要な指針となる内容である。
Source Article
元記事を日本語で読む
本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。
はじめに
最近、AIエージェントという言葉を聞く機会が増えました。
エンジニア向けには、Codex CLI、Claude Code、Gemini CLI のようなコーディングエージェントが広がっています。一方で、最近はこの流れがエンジニアだけのものではなくなってきているように感じます。
ファイルを読み、内容を整理し、表を加工し、レポートを作り、必要に応じて何度かやり直して成果物を作る。こうした「作業相手」としてのAI、いわゆる Cowork 的な使い方が広がりつつあります。
この文脈では、利用者はそれを「AI」と呼ぶこともあれば、「AIエージェント」と呼ぶこともあります。さらに、Claude Code や Codex のような具体的な製品名が、そのまま「賢く作業してくれるもの」の代表名のように使われることもあります。
しかし、実際に仕組みを見ていくと、AI、LLM、AIエージェント、ハーネスは少し分けて考えた方が理解しやすいです。
今回の記事では、AIエージェントを支える「ハーネス」という概念を整理しつつ、いくつかのハーネスを使って、事務作業系・表計算系・コーディング系のタスクを3問だけ試してみた結果を紹介します。
先に結論を言うと、今回の実験は3問だけの予備実験なので、ハーネスやモデルの優劣を決めるものではありません。統計的な有意性もありません。また、評価用の集計ロジックにも、まだデバッグしきれていない部分があります。
それでも、少なくとも今回の範囲では、次のような示唆が得られました。
- 現代的なハーネスは、コーディングだけでなく事務作業にも使えそう
- AIエージェントを「LLMにツールを渡してループを回すもの」と捉えるだけでは、現代的なハーネスの振る舞いを説明しにくくなってきた
- 賢く作業できるようになった一方で、裏側ではかなり大量のトークンを消費している
- Cowork的な利用を考えるなら、「できるか」だけでなく「いくらで、どの作業なら割に合うか」も重要になる
まず、この記事での用語を整理します。
用語
この記事でのざっくりした意味
AI
機械学習、LLM、画像認識、推薦システムなども含む広い概念
LLM / モデル
文章を理解・生成する中核部分。GPT、Claude、Gemini など
AIエージェント
目標に向かって、考える、道具を使う、結果を見る、やり直す、というループでタスクを進める仕組み
ハーネス
AIエージェントを実際に動かすための実行基盤。ツール、ファイル操作、コマンド実行、ループ制御、ログ、成果物管理などを含む
Cowork文脈では、これらの言葉がかなり混ざって使われがちです。
たとえば、ファイルを渡して「このExcelを整理して」「この資料を要約して」「このCSVからグラフを作って」と依頼できるものがあったとします。利用者から見ると、それは単に「AIが作業してくれた」と見えます。ある人はそれを「AI」と呼び、ある人は「エージェント」と呼び、また別の人は「Claude Codeみたいなもの」と呼ぶかもしれません。
しかし技術的には、そこにはいくつかの層があります。
モデルは、文章を読み、指示を理解し、次に何をすべきかを考える頭脳に近い部分です。AIエージェントは、そのモデルがツールや環境を使いながらタスクを進める仕組みです。そしてハーネスは、そのエージェントを実際に動かすための作業環境です。
人間にたとえるなら、モデルは頭脳、ハーネスは作業机、道具、手順、作業ログ、ファイル置き場を含む環境のようなものです。
ここで重要なのは、最近のAIエージェントの能力はモデルだけで決まっているわけではない、という点です。
もちろんモデル性能は重要です。しかし、ファイルをどう読むか、どのタイミングでコマンドを実行するか、失敗したときにどう戻るか、途中結果をどう保持するか、どこまで探索するか、といった部分はハーネス側の設計にも大きく依存します。
「ツールを渡せばエージェント」から、その先へ
一昔前のAIエージェント理解は、「LLMにツールを渡して、考える・実行する・観察するループを回すもの」という捉え方が中心だったように思います。ReAct はその代表的な考え方の一つで、推論と行動を組み合わせる枠組みとして提案されました。
この考え方は今でも重要です。AIエージェントの基本形を理解するうえでは、ReAct的なループは分かりやすい入口です。
一方で、実務でAIエージェントを使う段階になると、「ツールを渡せばよい」という理解だけでは足りなくなってきました。
最近は、MCPのようにツールやデータソースを接続するための仕組みも整備されつつあります。つまり、ツール接続そのものは以前より標準化されつつあります。
しかし、ツールがつながることと、AIエージェントが賢く作業できることは同じではありません。
実際の作業では、どのファイルを先に読むか、どこまで探索するか、中間結果をどう保持するか、コマンド実行結果をどう解釈するか、失敗したときにやり直すか、別案に切り替えるか、といった判断が大量に発生します。
このあたりが、現代的なハーネスの強さになっているように感じます。
つまり、「LLMにツールを渡してループを回せばエージェントになる」という理解と、Codex CLI、Claude Code、Gemini CLI のような現代的なハーネスの間には、かなり大きな距離があります。
なぜコーディング用ハーネスが事務作業にも使えそうなのか
多くの現代的なハーネスは、もともとコーディング用途から発展してきました。
コードベースを読む、ファイルを編集する、テストを実行する、エラーを見て修正する、差分を作る。これはソフトウェア開発では自然な作業です。
しかし、よく考えると、非エンジニアの事務作業にも似た構造があります。
- ExcelやCSVを読む
- 必要なデータを抽出する
- 表を整形する
- グラフを作る
- 複数ファイルを比較する
- レポートを生成する
- 出力ファイルを所定の形式で保存する
これは「コードを書く」作業ではありませんが、ファイルを読み、加工し、成果物を作るという意味では、コーディングエージェントの作業環境と近いものがあります。
そこで今回は、いくつかのハーネスを使って、コーディング系だけでなく、事務作業系・表計算系のタスクも試してみました。
実験条件
今回の目的は、モデル単体の優劣を決めることではありません。
モデルとハーネスの組み合わせによって、どの程度タスクを進められるのか。コーディング用に見えるハーネスが、事務作業にも使えるのか。素朴なツール利用型の実装と、現代的なハーネスの間にどれくらい差がありそうか。そして、その裏側でどれくらいトークンやコストを使うのか。
そのあたりを見るために、モデル、ハーネス、評価セットを組み合わせて実験しました。
なお、今回の比較では、Codex CLI、Claude Code、Gemini CLI、OpenCode、mini-SWE-agent、AutoGen、ReActを同じ枠組みで比較し、コーディング評価と事務作業評価を同じ実行基盤で扱えるようにしています。これは実験用の内部構成であり、記事では内部基盤の詳細には踏み込みません。
評価セット
評価セットは以下の3つです。
評価セット
説明
SpreadsheetBench V1 Verified
実世界由来のスプレッドシート操作を評価するベンチマークです。SpreadsheetBench全体は912問で、400問の人手検証済みサブセットが公開されています。本記事では、SpreadsheetBench 2と区別するため、今回使った評価セットを SpreadsheetBench V1 Verified と表記します。
複数アプリケーションをまたぐ現実的なオフィス自動化ワークフローを評価するベンチマークです。
実際のGitHub issueをもとに、コードベースを編集して問題を解決するソフトウェアエンジニアリング評価です。Verifiedは人手検証済み500問のsubsetです。
今回は各評価セットからランダムに50問のsubsetを用意し、予備実験としてその先頭3問だけを実行しました。3問はランダムsubset由来ではありますが、サンプル数が非常に少ないため、評価セット全体の難易度分布を代表しているとは限りません。
モデル
今回比較したモデルは、以下の4系統です。
記事内表記
位置づけ
GPT-5.5
OpenAI系モデル
Claude Sonnet 4.6
Claude系モデル
Gemini 3.5 Flash
Gemini系モデル
gpt-oss:20b
ローカルLLM枠
ハーネス
比較したハーネスは以下です。
記事内分類
実体
説明
純正ハーネス
Codex CLI / Claude Code / Gemini CLI
各モデル系列で代表的に使われるベンダー系CLIハーネスです。Codex CLIはOpenAIのローカル実行型coding agent、Claude CodeはAnthropicのagentic coding tool、Gemini CLIはGoogleのオープンソースAI agentです。
AgentCore
AWSのエージェント実行・運用基盤です。今回はマネージド参考枠として扱います。
OpenCode
OSS系の現代的なcoding agentです。
mini-SWE-agent
SWE-agent系の軽量ハーネスです。
AutoGen
MicrosoftによるAI agents / applications構築フレームワークです。
ReAct
Reasoning and Actingを組み合わせる古典的なエージェント枠組みです。今回は素朴なツール利用型の比較対象として扱います。
以降の結果表では、行方向をおおむね「純正ハーネス・マネージド参考枠・OSS系現代ハーネス・汎用フレームワーク・素朴なツール利用型」の順に並べています。列方向は、左から GPT-5.5、Claude Sonnet 4.6、Gemini 3.5 Flash、gpt-oss:20b としました。
表中の「純正ハーネス」は、GPT-5.5列では Codex CLI、Claude Sonnet 4.6列では Claude Code、Gemini 3.5 Flash列では Gemini CLI を指します。これは同じハーネスを複数モデルで動かした結果ではなく、各モデル系列で代表的に使われるベンダー系CLIハーネスをまとめて表示したものです。gpt-oss:20b には対応する純正ハーネスを設定していないため、空欄にしています。
実行と評価の単位
今回の予備実験では、各タスクを1回ずつ実行しました。したがって、スコアは pass@k のように複数回試行した成功率ではなく、今回の1回の実行結果に基づく値です。
スコアは、各評価セットの判定方法に従って集計しました。SWE-bench Verified では、生成された修正が対象issueを解決できたかをテストベースで判定します。SpreadsheetBench V1 Verified と OfficeBench では、タスクごとに期待される出力や評価条件に対する達成度を集計しています。
ただし、この記事では評価基盤の内部実装には踏み込まず、各ハーネス・モデルの組み合わせで得られた予備的な傾向を見ることを目的とします。
注意点
今回の実験には、強い制約があります。
注意：
本実験は各評価セット3問だけの予備実験であり、統計的な有意性はありません。また、評価・集計ロジックにはまだデバッグしきれていない部分があり、一部の数値には怪しい箇所が残っている可能性があります。以降の結果はランキングではなく、傾向や論点を見るための予備結果として読んでください。
また、AgentCore は他のCLI / SDK型ハーネスとは実行環境が異なるため、厳密な横並び比較ではなく、参考枠として扱います。
実験結果
スコア
まず、各評価セットのスコアを見ます。
以下の表では、行方向をおおむね「現代的なハーネス → 素朴なツール利用型」の順に並べています。また、列方向は「クラウドモデル → ローカルLLM」の順に並べています。
ハーネス
GPT-5.5
Claude
Sonnet 4.6
Gemini
3.5 Flash
gpt-oss:20b
純正ハーネス
66.7%
0.0%
33.3%
-
AgentCore
-
16.7%
-
-
OpenCode
100.0%
16.7%
33.3%
0.0%
mini-SWE-agent
33.3%
16.7%
0.0%
33.3%
AutoGen
33.3%
16.7%
66.7%
33.3%
ReAct
0.0%
0.0%
33.3%
0.0%
SpreadsheetBench V1 Verified：スコア
ハーネス
GPT-5.5
Claude
Sonnet 4.6
Gemini
3.5 Flash
gpt-oss:20b
純正ハーネス
100.0%
100.0%
100.0%
-
AgentCore
-
100.0%
-
-
OpenCode
100.0%
100.0%
66.7%
0.0%
mini-SWE-agent
100.0%
100.0%
100.0%
100.0%
AutoGen
100.0%
66.7%
33.3%
66.7%
ReAct
66.7%
66.7%
33.3%
0.0%
OfficeBench：スコア
ハーネス
GPT-5.5
Claude
Sonnet 4.6
Gemini
3.5 Flash
gpt-oss:20b
純正ハーネス
66.7%
33.3%
66.7%
-
AgentCore
-
33.3%
-
-
OpenCode
66.7%
33.3%
66.7%
0.0%
mini-SWE-agent
66.7%
33.3%
33.3%
0.0%
AutoGen
66.7%
33.3%
33.3%
0.0%
ReAct
0.0%
0.0%
0.0%
0.0%
SWE-bench Verified：スコア
個別の数値を細かく読むのではなく、表全体の傾向として見ると、いくつかの特徴が見えます。
まず、行方向では、上側に置いた純正ハーネス、AgentCore、OpenCode、mini-SWE-agentのような現代的なハーネスの方が、下側に置いたAutoGenやReActよりスコアが出やすいように見えます。特にReActは、今回の範囲ではSWE-bench Verifiedで苦戦していました。
次に、列方向では、左側に置いたクラウドモデルの方が、右側に置いたローカルLLM枠よりスコアが出やすいように見えます。もちろん、これはOSSモデル一般の限界という意味ではなく、今回使ったモデルサイズ、ハーネス実装、tool callingとの相性、評価タスクとの相性を含んだ結果です。
また、評価セットごとの違いも見えます。今回の3問では、OfficeBenchは比較的スコアが出やすく、SpreadsheetBench V1 Verifiedはばらつきがあり、SWE-bench Verifiedはより難しいタスクに見えました。これは、事務作業系タスクの方が今回の範囲では解きやすく、実コードベースを修正するSWE-bench Verifiedは難度が高い、という感触と合っています。
トークン消費
次に、トークン消費を見ます。
以下の表は、3問平均の消費トークンを k tokens 単位で示しています。たとえば 392.2 は約392,200 tokensです。スコア表と同じく、行方向を「現代的なハーネス → 素朴なツール利用型」、列方向を「クラウドモデル → ローカルLLM」の順に並べています。
なお、トークン消費が 0.0 になっているセルがあります。これは実際に無コストで解けたという意味ではなく、実行失敗、ログ欠損、または集計上の未デバッグ箇所を含んでいる可能性があります。そのため、0.0 のセルは低コストな成功例として解釈しないでください。
ハーネス
GPT-5.5
Claude
Sonnet 4.6
Gemini
3.5 Flash
gpt-oss:20b
純正ハーネス
123.7
174.9
879.2
-
AgentCore
-
364.0
-
-
OpenCode
170.5
95.3
863.4
16.7
mini-SWE-agent
15.1
139.6
992.1
17.6
AutoGen
17.1
47.2
23.4
11.6
ReAct
4.6
52.1
163.8
12.0
SpreadsheetBench V1 Verified：トークン消費（3問平均、k tokens）
ハーネス
GPT-5.5
Claude
Sonnet 4.6
Gemini
3.5 Flash
gpt-oss:20b
純正ハーネス
252.5
359.8
579.3
-
AgentCore
-
834.7
-
-
OpenCode
314.3
205.2
362.8
37.8
mini-SWE-agent
29.7
133.7
506.0
31.5
AutoGen
34.1
55.7
24.4
29.0
ReAct
18.2
63.3
60.2
0.0*
OfficeBench：トークン消費（3問平均、k tokens）
ハーネス
GPT-5.5
Claude
Sonnet 4.6
Gemini
3.5 Flash
gpt-oss:20b
純正ハーネス
392.2
2175.3
3586.7
-
AgentCore
-
1172.8
-
-
OpenCode
322.1
878.2
3191.0
53.9
mini-SWE-agent
441.3
1512.0
2015.7
127.8
AutoGen
645.4
904.1
105.4
8.8
ReAct
0.0*
449.7
173.1
68.7
SWE-bench Verified：トークン消費（3問平均、k tokens）
- は実行失敗・ログ欠損・集計上の未デバッグ箇所を含む可能性がある値です。
こちらも個別の値を厳密に比較するのではなく、表全体の傾向として見るのがよさそうです。
大まかには、スコアと同じく、上側に置いた現代的なハーネスほどトークン消費が大きく、下側に置いた素朴なツール利用型ほどトークン消費が小さくなる傾向が見えます。また、列方向でも、左側のクラウドモデルではトークン消費が大きく、右側のローカルLLM枠では小さく見えます。
これはある意味で自然です。現代的なハーネスは、単に一度回答して終わるのではなく、ファイルを読み、探索し、コマンドを実行し、結果を見て、必要に応じてやり直します。そのぶん、スコアが出やすくなる一方で、トークン消費も大きくなります。
特に目立つのは、SWE-bench Verifiedです。SpreadsheetBench V1 VerifiedやOfficeBenchと比べて、SWE-bench Verifiedではトークン消費が一段大きくなっています。実コードベースを読み、問題箇所を探し、修正し、検証する必要があるため、事務作業系タスクよりもトークンが膨らみやすいと考えられます。
コスト
トークン消費は、そのままコストにも効いてきます。
ただし、ここで示すコストは「各モデルで実行した全ハーネス分の合計」です。モデルごとに実行したハーネスの数や種類は完全には揃っていません。特に AgentCore は Claude Sonnet 4.6 の参考枠として追加しているため、Claude Sonnet 4.6 列には他モデルにはない実行分が含まれます。
そのため、以下のコスト表はモデル同士の厳密な価格比較ではありません。今回の予備実験を実際に回したときの費用感、および50問評価へ広げた場合の概算規模を見るためのものです。
3問だけの実績コストは次のようになりました。
評価セット
GPT-5.5
Claude
Sonnet 4.6
Gemini
3.5 Flash
gpt-oss:20b
SpreadsheetBench
V1 Verified
¥899.9
¥1,308.8
¥2,250.9
¥0.0
OfficeBench
¥1,648.4
¥2,365.5
¥1,153.1
¥0.0
SWE-bench
Verified
¥4,341.7
¥9,855.6
¥6,297.1
¥0.0
合計
¥6,890.1
¥13,529.9
¥9,701.2
¥0.0
3問実行時の実績コスト
商用モデル3系統の合計だけを見ると、3問ずつの予備実験でも約3万円です。
さらに、これを50問に単純換算すると次のようになります。
評価セット
GPT-5.5
Claude
Sonnet 4.6
Gemini
3.5 Flash
gpt-oss:20b
SpreadsheetBench
V1 Verified
¥14,998.9
¥21,812.9
¥37,515.5
¥0.0
OfficeBench
¥27,473.2
¥39,425.3
¥19,219.0
¥0.0
SWE-bench
Verified
¥72,362.3
¥164,259.5
¥104,952.2
¥0.0
合計
¥114,834.3
¥225,497.7
¥161,686.8
¥0.0
50問実行時の推定コスト
imageベンチマーク別・モデル別のコスト
商用モデル3系統を50問ずつ実行すると、単純換算で約50万円規模になります。
もちろん、これは3問の結果を単純に50問へ引き伸ばしただけです。問題の難易度分布、キャッシュ、実行設定、レート、モデル単価、集計方法、実行対象ハーネスの数によって変わります。
それでも、予備実験の段階で「これはフル実験を軽々しく回せない」と分かりました。
考察
スコアとトークン消費はセットで見る必要がある
今回の予備実験で見えた一番大きな傾向は、スコアとトークン消費を別々に見るのではなく、セットで見る必要があるという点です。
表全体を見ると、現代的なハーネスやクラウドモデル側では、スコアが出やすい一方で、トークン消費も大きくなる傾向がありました。逆に、素朴なツール利用型やローカルLLM枠では、トークン消費は小さく見えるものの、スコアも伸びにくい場面がありました。
ただし、これは個別セルごとに「トークンを多く使えば必ずスコアが上がる」という意味ではありません。実際には、少ないトークンで高めのスコアが出ている組み合わせもあれば、多くのトークンを使ってもスコアが伸びていない組み合わせもあります。
したがって、今回の結果は「トークンを燃やせばよい」という話ではなく、現代的なハーネスは大量に読み、探索し、実行し、やり直すことでタスクを進める傾向があり、その結果としてスコアとコストの両方に影響が出る、という読み方がよさそうです。
特にCowork的な事務作業では、ユーザーからは単に「AIがファイルを処理してくれた」と見えます。しかし裏側では、現代的なハーネスがかなり多くのトークンを使って作業している可能性があります。
そのため、実務でAIエージェントを使うときは、「できるか」だけでなく、「その作業をそのコストで任せる価値があるか」を見る必要があります。
事務作業にも一定の適用可能性がありそう
OfficeBenchでは、今回の3問に限ると比較的スコアが出やすい傾向がありました。これだけで「事務作業は十分に解ける」とは言えません。問題がたまたま簡単だった可能性もありますし、評価ロジックに怪しい部分が残っている可能性もあります。
ただし、ファイルを読み、加工し、成果物を作るような作業に対して、コーディング用に発展してきたハーネスが一定の力を発揮しそうだ、という感触はあります。
Cowork的な使い方を考えるうえでは、これは重要です。
非エンジニアの作業をAIが手伝うとき、必要なのは必ずしもコードを書く能力だけではありません。むしろ、ファイルを読み、内容を理解し、必要な操作を行い、最終成果物を作る能力です。
その意味では、コーディングハーネスで発展してきた作業能力は、事務作業にも転用できる可能性があります。
素朴なツール利用型だけでは厳しそう
今回の結果では、下側に置いた素朴なツール利用型ほど、スコアが伸びにくい傾向が見えました。特にSWE-bench Verifiedのように、実際のコードベースを読み、編集し、検証するタスクでは、その傾向が目立ちます。
もちろん、これは今回の実装・プロンプト・評価対象に依存します。ReActそのものが不要という話ではありません。ReActは、AIエージェントの基本構造を理解するうえでは今でも重要です。
ただし、今から実務用のAIエージェントを作るときに、素朴なツール利用型の実装だけで、Codex CLIやClaude Codeのような現代的ハーネスと同じ振る舞いを目指すのは、かなり厳しいのではないかと感じました。
以前は「LLMにツールを渡せばエージェントになる」という理解でも、ある程度は話が通じました。
しかし現在は、探索、編集、実行、検証、リトライ、コンテキスト管理を含むループ全体の作り込みが性能に効いているように見えます。
実務的には、ゼロから手組みで頑張るよりも、既存の現代的ハーネスの能力と制約を理解し、どこで使うべきかを考える方が現実的かもしれません。
ローカルLLMはどう見るか
今回、gpt-oss:20b もローカルLLM枠として試しました。
結果だけを見ると、商用ベンダーモデルと比べて苦戦する場面が多く見えました。特にSWE-bench Verifiedでは、今回の3問ではスコアが伸びませんでした。
ただし、これをもって「OSSモデルは使えない」と言うつもりはありません。
今回の結果には、モデルサイズ、tool callingへの適性、プロンプト、ハーネス側の実装、評価タスクとの相性がすべて含まれています。また、ローカルLLMはAPI課金が0円として扱われていますが、実際には計算資源、運用、チューニング、セットアップのコストがあります。
一方で、データ管理や閉域環境での利用を考えると、ローカルLLMやOSSモデルには別の価値があります。
そのため、今回の結果は「OSSモデル一般の限界」というより、「今回の設定では、現代的な商用モデルの方がタスク遂行には有利に見えた」と解釈するのが妥当だと思います。
まとめ
今回は、AIエージェントを支える「ハーネス」という概念を整理し、いくつかのハーネスを使って、事務作業系・表計算系・コーディング系のタスクを3問だけ試してみました。
繰り返しになりますが、これは3問だけの予備実験です。統計的な有意性はありませんし、評価用の集計ロジックにもデバッグしきれていない部分があります。そのため、ハーネスやモデルの優劣を決めるものではありません。
それでも、いくつかの示唆は得られました。
Codex CLIやClaude Codeのような現代的なハーネスは、もはやコーディングだけの道具ではなく、ファイルを読み、加工し、成果物を作る Cowork 的な作業相手になりつつあります。
一方で、その賢さは無料ではありません。裏側では大量のトークンを使い、SWE-bench Verifiedのような重いタスクでは、3問だけでも無視できないコストになります。
また、AIエージェントを「LLMにツールを渡してループを回すもの」と捉えるだけでは、現代的なハーネスの振る舞いを説明しにくくなってきました。ツール接続は重要ですが、それだけでは差別化になりにくく、探索、編集、実行、検証、リトライを含むループ全体の作り込みが性能に効いているように見えます。
次にやるなら、評価セットや集計ロジックをもう少し安定させたうえで、予算を確保して50問評価まで広げたいです。そのうえで、タスク種別ごとに「どの作業を、どのハーネスに、どれくらいのコストで任せると割に合うのか」を見ていきたいと思います。
ハーネスをサービスとしてどう提供するかは、今回は扱いませんでした。ただ、Cowork的なAI活用を考えるうえでも、ハーネスの性能とコスト構造を理解しておく必要はありそうです。
原文を表示
はじめに
最近、AIエージェントという言葉を聞く機会が増えました。
エンジニア向けには、Codex CLI、Claude Code、Gemini CLI のようなコーディングエージェントが広がっています。一方で、最近はこの流れがエンジニアだけのものではなくなってきているように感じます。
ファイルを読み、内容を整理し、表を加工し、レポートを作り、必要に応じて何度かやり直して成果物を作る。こうした「作業相手」としてのAI、いわゆる Cowork 的な使い方が広がりつつあります。
この文脈では、利用者はそれを「AI」と呼ぶこともあれば、「AIエージェント」と呼ぶこともあります。さらに、Claude Code や Codex のような具体的な製品名が、そのまま「賢く作業してくれるもの」の代表名のように使われることもあります。
しかし、実際に仕組みを見ていくと、AI、LLM、AIエージェント、ハーネスは少し分けて考えた方が理解しやすいです。
今回の記事では、AIエージェントを支える「ハーネス」という概念を整理しつつ、いくつかのハーネスを使って、事務作業系・表計算系・コーディング系のタスクを3問だけ試してみた結果を紹介します。
先に結論を言うと、今回の実験は3問だけの予備実験なので、ハーネスやモデルの優劣を決めるものではありません。統計的な有意性もありません。また、評価用の集計ロジックにも、まだデバッグしきれていない部分があります。
それでも、少なくとも今回の範囲では、次のような示唆が得られました。
- 現代的なハーネスは、コーディングだけでなく事務作業にも使えそう
- AIエージェントを「LLMにツールを渡してループを回すもの」と捉えるだけでは、現代的なハーネスの振る舞いを説明しにくくなってきた
- 賢く作業できるようになった一方で、裏側ではかなり大量のトークンを消費している
- Cowork的な利用を考えるなら、「できるか」だけでなく「いくらで、どの作業なら割に合うか」も重要になる
まず、この記事での用語を整理します。
用語
この記事でのざっくりした意味
AI
機械学習、LLM、画像認識、推薦システムなども含む広い概念
LLM / モデル
文章を理解・生成する中核部分。GPT、Claude、Gemini など
AIエージェント
目標に向かって、考える、道具を使う、結果を見る、やり直す、というループでタスクを進める仕組み
ハーネス
AIエージェントを実際に動かすための実行基盤。ツール、ファイル操作、コマンド実行、ループ制御、ログ、成果物管理などを含む
Cowork文脈では、これらの言葉がかなり混ざって使われがちです。
たとえば、ファイルを渡して「このExcelを整理して」「この資料を要約して」「このCSVからグラフを作って」と依頼できるものがあったとします。利用者から見ると、それは単に「AIが作業してくれた」と見えます。ある人はそれを「AI」と呼び、ある人は「エージェント」と呼び、また別の人は「Claude Codeみたいなもの」と呼ぶかもしれません。
しかし技術的には、そこにはいくつかの層があります。
モデルは、文章を読み、指示を理解し、次に何をすべきかを考える頭脳に近い部分です。AIエージェントは、そのモデルがツールや環境を使いながらタスクを進める仕組みです。そしてハーネスは、そのエージェントを実際に動かすための作業環境です。
人間にたとえるなら、モデルは頭脳、ハーネスは作業机、道具、手順、作業ログ、ファイル置き場を含む環境のようなものです。
ここで重要なのは、最近のAIエージェントの能力はモデルだけで決まっているわけではない、という点です。
もちろんモデル性能は重要です。しかし、ファイルをどう読むか、どのタイミングでコマンドを実行するか、失敗したときにどう戻るか、途中結果をどう保持するか、どこまで探索するか、といった部分はハーネス側の設計にも大きく依存します。
「ツールを渡せばエージェント」から、その先へ
一昔前のAIエージェント理解は、「LLMにツールを渡して、考える・実行する・観察するループを回すもの」という捉え方が中心だったように思います。ReAct はその代表的な考え方の一つで、推論と行動を組み合わせる枠組みとして提案されました。
この考え方は今でも重要です。AIエージェントの基本形を理解するうえでは、ReAct的なループは分かりやすい入口です。
一方で、実務でAIエージェントを使う段階になると、「ツールを渡せばよい」という理解だけでは足りなくなってきました。
最近は、MCPのようにツールやデータソースを接続するための仕組みも整備されつつあります。つまり、ツール接続そのものは以前より標準化されつつあります。
しかし、ツールがつながることと、AIエージェントが賢く作業できることは同じではありません。
実際の作業では、どのファイルを先に読むか、どこまで探索するか、中間結果をどう保持するか、コマンド実行結果をどう解釈するか、失敗したときにやり直すか、別案に切り替えるか、といった判断が大量に発生します。
このあたりが、現代的なハーネスの強さになっているように感じます。
つまり、「LLMにツールを渡してループを回せばエージェントになる」という理解と、Codex CLI、Claude Code、Gemini CLI のような現代的なハーネスの間には、かなり大きな距離があります。
なぜコーディング用ハーネスが事務作業にも使えそうなのか
多くの現代的なハーネスは、もともとコーディング用途から発展してきました。
コードベースを読む、ファイルを編集する、テストを実行する、エラーを見て修正する、差分を作る。これはソフトウェア開発では自然な作業です。
しかし、よく考えると、非エンジニアの事務作業にも似た構造があります。
- ExcelやCSVを読む
- 必要なデータを抽出する
- 表を整形する
- グラフを作る
- 複数ファイルを比較する
- レポートを生成する
- 出力ファイルを所定の形式で保存する
これは「コードを書く」作業ではありませんが、ファイルを読み、加工し、成果物を作るという意味では、コーディングエージェントの作業環境と近いものがあります。
そこで今回は、いくつかのハーネスを使って、コーディング系だけでなく、事務作業系・表計算系のタスクも試してみました。
実験条件
今回の目的は、モデル単体の優劣を決めることではありません。
モデルとハーネスの組み合わせによって、どの程度タスクを進められるのか。コーディング用に見えるハーネスが、事務作業にも使えるのか。素朴なツール利用型の実装と、現代的なハーネスの間にどれくらい差がありそうか。そして、その裏側でどれくらいトークンやコストを使うのか。
そのあたりを見るために、モデル、ハーネス、評価セットを組み合わせて実験しました。
なお、今回の比較では、Codex CLI、Claude Code、Gemini CLI、OpenCode、mini-SWE-agent、AutoGen、ReActを同じ枠組みで比較し、コーディング評価と事務作業評価を同じ実行基盤で扱えるようにしています。これは実験用の内部構成であり、記事では内部基盤の詳細には踏み込みません。
評価セット
評価セットは以下の3つです。
評価セット
説明
SpreadsheetBench V1 Verified
実世界由来のスプレッドシート操作を評価するベンチマークです。SpreadsheetBench全体は912問で、400問の人手検証済みサブセットが公開されています。本記事では、SpreadsheetBench 2と区別するため、今回使った評価セットを SpreadsheetBench V1 Verified と表記します。
複数アプリケーションをまたぐ現実的なオフィス自動化ワークフローを評価するベンチマークです。
実際のGitHub issueをもとに、コードベースを編集して問題を解決するソフトウェアエンジニアリング評価です。Verifiedは人手検証済み500問のsubsetです。
今回は各評価セットからランダムに50問のsubsetを用意し、予備実験としてその先頭3問だけを実行しました。3問はランダムsubset由来ではありますが、サンプル数が非常に少ないため、評価セット全体の難易度分布を代表しているとは限りません。
モデル
今回比較したモデルは、以下の4系統です。
記事内表記
位置づけ
GPT-5.5
OpenAI系モデル
Claude Sonnet 4.6
Claude系モデル
Gemini 3.5 Flash
Gemini系モデル
gpt-oss:20b
ローカルLLM枠
ハーネス
比較したハーネスは以下です。
記事内分類
実体
説明
純正ハーネス
Codex CLI / Claude Code / Gemini CLI
各モデル系列で代表的に使われるベンダー系CLIハーネスです。Codex CLIはOpenAIのローカル実行型coding agent、Claude CodeはAnthropicのagentic coding tool、Gemini CLIはGoogleのオープンソースAI agentです。
AgentCore
AWSのエージェント実行・運用基盤です。今回はマネージド参考枠として扱います。
OpenCode
OSS系の現代的なcoding agentです。
mini-SWE-agent
SWE-agent系の軽量ハーネスです。
AutoGen
MicrosoftによるAI agents / applications構築フレームワークです。
ReAct
Reasoning and Actingを組み合わせる古典的なエージェント枠組みです。今回は素朴なツール利用型の比較対象として扱います。
以降の結果表では、行方向をおおむね「純正ハーネス・マネージド参考枠・OSS系現代ハーネス・汎用フレームワーク・素朴なツール利用型」の順に並べています。列方向は、左から GPT-5.5、Claude Sonnet 4.6、Gemini 3.5 Flash、gpt-oss:20b としました。
表中の「純正ハーネス」は、GPT-5.5列では Codex CLI、Claude Sonnet 4.6列では Claude Code、Gemini 3.5 Flash列では Gemini CLI を指します。これは同じハーネスを複数モデルで動かした結果ではなく、各モデル系列で代表的に使われるベンダー系CLIハーネスをまとめて表示したものです。gpt-oss:20b には対応する純正ハーネスを設定していないため、空欄にしています。
実行と評価の単位
今回の予備実験では、各タスクを1回ずつ実行しました。したがって、スコアは pass@k のように複数回試行した成功率ではなく、今回の1回の実行結果に基づく値です。
スコアは、各評価セットの判定方法に従って集計しました。SWE-bench Verified では、生成された修正が対象issueを解決できたかをテストベースで判定します。SpreadsheetBench V1 Verified と OfficeBench では、タスクごとに期待される出力や評価条件に対する達成度を集計しています。
ただし、この記事では評価基盤の内部実装には踏み込まず、各ハーネス・モデルの組み合わせで得られた予備的な傾向を見ることを目的とします。
注意点
今回の実験には、強い制約があります。
注意：
本実験は各評価セット3問だけの予備実験であり、統計的な有意性はありません。また、評価・集計ロジックにはまだデバッグしきれていない部分があり、一部の数値には怪しい箇所が残っている可能性があります。以降の結果はランキングではなく、傾向や論点を見るための予備結果として読んでください。
また、AgentCore は他のCLI / SDK型ハーネスとは実行環境が異なるため、厳密な横並び比較ではなく、参考枠として扱います。
実験結果
スコア
まず、各評価セットのスコアを見ます。
以下の表では、行方向をおおむね「現代的なハーネス → 素朴なツール利用型」の順に並べています。また、列方向は「クラウドモデル → ローカルLLM」の順に並べています。
個別の数値を細かく読むのではなく、表全体の傾向として見ると、いくつかの特徴が見えます。
まず、行方向では、上側に置いた純正ハーネス、AgentCore、OpenCode、mini-SWE-agentのような現代的なハーネスの方が、下側に置いたAutoGenやReActよりスコアが出やすいように見えます。特にReActは、今回の範囲ではSWE-bench Verifiedで苦戦していました。
次に、列方向では、左側に置いたクラウドモデルの方が、右側に置いたローカルLLM枠よりスコアが出やすいように見えます。もちろん、これはOSSモデル一般の限界という意味ではなく、今回使ったモデルサイズ、ハーネス実装、tool callingとの相性、評価タスクとの相性を含んだ結果です。
また、評価セットごとの違いも見えます。今回の3問では、OfficeBenchは比較的スコアが出やすく、SpreadsheetBench V1 Verifiedはばらつきがあり、SWE-bench Verifiedはより難しいタスクに見えました。これは、事務作業系タスクの方が今回の範囲では解きやすく、実コードベースを修正するSWE-bench Verifiedは難度が高い、という感触と合っています。
トークン消費
次に、トークン消費を見ます。
以下の表は、3問平均の消費トークンを k tokens 単位で示しています。たとえば 392.2 は約392,200 tokensです。スコア表と同じく、行方向を「現代的なハーネス → 素朴なツール利用型」、列方向を「クラウドモデル → ローカルLLM」の順に並べています。
なお、トークン消費が 0.0 になっているセルがあります。これは実際に無コストで解けたという意味ではなく、実行失敗、ログ欠損、または集計上の未デバッグ箇所を含んでいる可能性があります。そのため、0.0 のセルは低コストな成功例として解釈しないでください。
* は実行失敗・ログ欠損・集計上の未デバッグ箇所を含む可能性がある値です。
こちらも個別の値を厳密に比較するのではなく、表全体の傾向として見るのがよさそうです。
大まかには、スコアと同じく、上側に置いた現代的なハーネスほどトークン消費が大きく、下側に置いた素朴なツール利用型ほどトークン消費が小さくなる傾向が見えます。また、列方向でも、左側のクラウドモデルではトークン消費が大きく、右側のローカルLLM枠では小さく見えます。
これはある意味で自然です。現代的なハーネスは、単に一度回答して終わるのではなく、ファイルを読み、探索し、コマンドを実行し、結果を見て、必要に応じてやり直します。そのぶん、スコアが出やすくなる一方で、トークン消費も大きくなります。
特に目立つのは、SWE-bench Verifiedです。SpreadsheetBench V1 VerifiedやOfficeBenchと比べて、SWE-bench Verifiedではトークン消費が一段大きくなっています。実コードベースを読み、問題箇所を探し、修正し、検証する必要があるため、事務作業系タスクよりもトークンが膨らみやすいと考えられます。
コスト
トークン消費は、そのままコストにも効いてきます。
ただし、ここで示すコストは「各モデルで実行した全ハーネス分の合計」です。モデルごとに実行したハーネスの数や種類は完全には揃っていません。特に AgentCore は Claude Sonnet 4.6 の参考枠として追加しているため、Claude Sonnet 4.6 列には他モデルにはない実行分が含まれます。
そのため、以下のコスト表はモデル同士の厳密な価格比較ではありません。今回の予備実験を実際に回したときの費用感、および50問評価へ広げた場合の概算規模を見るためのものです。
3問だけの実績コストは次のようになりました。
商用モデル3系統の合計だけを見ると、3問ずつの予備実験でも約3万円です。
さらに、これを50問に単純換算すると次のようになります。
商用モデル3系統を50問ずつ実行すると、単純換算で約50万円規模になります。
もちろん、これは3問の結果を単純に50問へ引き伸ばしただけです。問題の難易度分布、キャッシュ、実行設定、レート、モデル単価、集計方法、実行対象ハーネスの数によって変わります。
それでも、予備実験の段階で「これはフル実験を軽々しく回せない」と分かりました。
考察
スコアとトークン消費はセットで見る必要がある
今回の予備実験で見えた一番大きな傾向は、スコアとトークン消費を別々に見るのではなく、セットで見る必要があるという点です。
表全体を見ると、現代的なハーネスやクラウドモデル側では、スコアが出やすい一方で、トークン消費も大きくなる傾向がありました。逆に、素朴なツール利用型やローカルLLM枠では、トークン消費は小さく見えるものの、スコアも伸びにくい場面がありました。
ただし、これは個別セルごとに「トークンを多く使えば必ずスコアが上がる」という意味ではありません。実際には、少ないトークンで高めのスコアが出ている組み合わせもあれば、多くのトークンを使ってもスコアが伸びていない組み合わせもあります。
したがって、今回の結果は「トークンを燃やせばよい」という話ではなく、現代的なハーネスは大量に読み、探索し、実行し、やり直すことでタスクを進める傾向があり、その結果としてスコアとコストの両方に影響が出る、という読み方がよさそうです。
特にCowork的な事務作業では、ユーザーからは単に「AIがファイルを処理してくれた」と見えます。しかし裏側では、現代的なハーネスがかなり多くのトークンを使って作業している可能性があります。
そのため、実務でAIエージェントを使うときは、「できるか」だけでなく、「その作業をそのコストで任せる価値があるか」を見る必要があります。
事務作業にも一定の適用可能性がありそう
OfficeBenchでは、今回の3問に限ると比較的スコアが出やすい傾向がありました。これだけで「事務作業は十分に解ける」とは言えません。問題がたまたま簡単だった可能性もありますし、評価ロジックに怪しい部分が残っている可能性もあります。
ただし、ファイルを読み、加工し、成果物を作るような作業に対して、コーディング用に発展してきたハーネスが一定の力を発揮しそうだ、という感触はあります。
Cowork的な使い方を考えるうえでは、これは重要です。
非エンジニアの作業をAIが手伝うとき、必要なのは必ずしもコードを書く能力だけではありません。むしろ、ファイルを読み、内容を理解し、必要な操作を行い、最終成果物を作る能力です。
その意味では、コーディングハーネスで発展してきた作業能力は、事務作業にも転用できる可能性があります。
素朴なツール利用型だけでは厳しそう
今回の結果では、下側に置いた素朴なツール利用型ほど、スコアが伸びにくい傾向が見えました。特にSWE-bench Verifiedのように、実際のコードベースを読み、編集し、検証するタスクでは、その傾向が目立ちます。
もちろん、これは今回の実装・プロンプト・評価対象に依存します。ReActそのものが不要という話ではありません。ReActは、AIエージェントの基本構造を理解するうえでは今でも重要です。
ただし、今から実務用のAIエージェントを作るときに、素朴なツール利用型の実装だけで、Codex CLIやClaude Codeのような現代的ハーネスと同じ振る舞いを目指すのは、かなり厳しいのではないかと感じました。
以前は「LLMにツールを渡せばエージェントになる」という理解でも、ある程度は話が通じました。
しかし現在は、探索、編集、実行、検証、リトライ、コンテキスト管理を含むループ全体の作り込みが性能に効いているように見えます。
実務的には、ゼロから手組みで頑張るよりも、既存の現代的ハーネスの能力と制約を理解し、どこで使うべきかを考える方が現実的かもしれません。
ローカルLLMはどう見るか
今回、gpt-oss:20b もローカルLLM枠として試しました。
結果だけを見ると、商用ベンダーモデルと比べて苦戦する場面が多く見えました。特にSWE-bench Verifiedでは、今回の3問ではスコアが伸びませんでした。
ただし、これをもって「OSSモデルは使えない」と言うつもりはありません。
今回の結果には、モデルサイズ、tool callingへの適性、プロンプト、ハーネス側の実装、評価タスクとの相性がすべて含まれています。また、ローカルLLMはAPI課金が0円として扱われていますが、実際には計算資源、運用、チューニング、セットアップのコストがあります。
一方で、データ管理や閉域環境での利用を考えると、ローカルLLMやOSSモデルには別の価値があります。
そのため、今回の結果は「OSSモデル一般の限界」というより、「今回の設定では、現代的な商用モデルの方がタスク遂行には有利に見えた」と解釈するのが妥当だと思います。
まとめ
今回は、AIエージェントを支える「ハーネス」という概念を整理し、いくつかのハーネスを使って、事務作業系・表計算系・コーディング系のタスクを3問だけ試してみました。
繰り返しになりますが、これは3問だけの予備実験です。統計的な有意性はありませんし、評価用の集計ロジックにもデバッグしきれていない部分があります。そのため、ハーネスやモデルの優劣を決めるものではありません。
それでも、いくつかの示唆は得られました。
Codex CLIやClaude Codeのような現代的なハーネスは、もはやコーディングだけの道具ではなく、ファイルを読み、加工し、成果物を作る Cowork 的な作業相手になりつつあります。
一方で、その賢さは無料ではありません。裏側では大量のトークンを使い、SWE-bench Verifiedのような重いタスクでは、3問だけでも無視できないコストになります。
また、AIエージェントを「LLMにツールを渡してループを回すもの」と捉えるだけでは、現代的なハーネスの振る舞いを説明しにくくなってきました。ツール接続は重要ですが、それだけでは差別化になりにくく、探索、編集、実行、検証、リトライを含むループ全体の作り込みが性能に効いているように見えます。
次にやるなら、評価セットや集計ロジックをもう少し安定させたうえで、予算を確保して50問評価まで広げたいです。そのうえで、タスク種別ごとに「どの作業を、どのハーネスに、どれくらいのコストで任せると割に合うのか」を見ていきたいと思います。
ハーネスをサービスとしてどう提供するかは、今回は扱いませんでした。ただ、Cowork的なAI活用を考えるうえでも、ハーネスの性能とコスト構造を理解しておく必要はありそうです。
AI算出
技術分析ainew評価標準
記事は AI エージェントとハーネスの定義を明確にし、Codex CLI や Claude Code などの具体的なツールを用いた実験結果を通じて、現代的なエージェント運用の実態やコスト面での課題（トークン消費など）を分析しています。これは単なるニュース報知ではなく、実装や利用を検討する開発者向けの技術的考察が含まれています。
6つの評価軸を見る
- AI関連度
- 75
- 情報源の信頼性
- 100
- 新規性
- 50
- 調べる価値
- 25
- 重複の少なさ
- 100
- 日本での有用性
- 50
関連記事
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み