2025年を振り返る問い
動く試作を、任せられる仕事へ変えるには
AIがサイトを開き、資料を集め、比較レポートを作る。 画面上では一連の仕事が終わったように見える。 ところが担当者が公開前に読むと、取得できなかった資料が比較から消え、製品の説明と著者の判断が混ざっていた。 この想定例で残った仕事は、文章の修正だけでなく、調査のやり直しである。
2025年には、ブラウザー操作、外部への接続、実行を繰り返すSDK、手順の編集と評価を支える製品が具体化した。 本稿は、それぞれの公式発表と仕様を比べ、仕事のどの部分を組み立てやすくしたかを振り返る。 発表の数から導入率や業務全体の成功率を推定する総括ではない。
本稿の判断は、任せる範囲を「エージェントが何をできるか」だけで決めず、「何ができれば、この仕事は完了か」から定めることだ。 操作や接続の部品が増えるほど、資料、下書き、公開物という異なる成果を作れる。 その間に残る不足と、人が確かめ直す負担まで見れば、次に任せるべき部分を選びやすくなる。
操作と引き継ぎ
ブラウザーを使えることが、仕事の入口を広げた
1月23日のOperatorの発表は、画面を見てブラウザーを操作する研究プレビューを示した。 APIが用意されていないサイトでも、フォームや画面を通じて作業する道が開かれる。 一方、ログイン、支払い情報、CAPTCHAなどでは利用者へ操作を渡し、重要な操作には確認を求める設計も説明されている。
これは、画面を扱う能力と、最後まで無人で終える能力を分けて見る材料になる。 比較レポートの想定例なら、公開資料の閲覧を任せられても、会員サイトへのログインで人を待つ場合がある。 待っているのに資料がないものとして進めば、後の比較が欠ける。 操作の途中で人へ戻ることを、仕事の失敗とも、資料の不存在とも取り違えない表示が必要になる。
人へ引き継ぐ仕組みは、自動化の不足だけを意味しない。 誰の資格でアクセスするか、どの操作まで認めるかを利用者が決める機会にもなる。 ただし、引き継ぎのたびに担当者が最初から調べ直すなら、操作を任せた利益は小さくなる。 何を取得できて、どこで待っているかを伝えられるかまでが、実用上の比較になる。
接続の共通化
つながる相手と、受け取った結果の意味を分ける
4月9日のA2Aの発表は、相手の能力を見つけ、タスクの進行や成果物を受け渡す構想と仕様の草案を示した。 MCPの2025年6月18日版のツール仕様は、ツールの呼び出しと結果、構造化した出力を扱う。 エージェント同士の仕事の受け渡しと、エージェントからデータや機能を使う接続は、関連していても同じ役割ではない。
接続方法が共通になれば、相手ごとに通信の仕組みを作る負担を減らせる可能性がある。 しかし、同じ項目名を返す二つの検索先が、同じ版の資料、同じ閲覧範囲、同じ失敗の扱いを持つとは限らない。 レポートの検索先を交換したときは、「検索結果が空だった」が資料なしなのか、権限不足なのかを確かめたい。
MCPのツール仕様は、通信上のエラーと、ツールが実行中に返すエラーを区別する。 この区別からも、応答を受け取った事実だけで仕事を完了と扱えないことが分かる。 本稿のレポートなら、取得した本文と出典に加え、未取得の資料も残す必要がある。 これは本稿の成果条件であり、共通プロトコルが比較レポートの完全性を保証するわけではない。
モデルと実行の反復
次の手を選ぶ能力と、確かめ直す仕組みがそろう
8月7日のGPT-5の開発者向け発表は、JSONに限らず、テキストを渡すカスタムツールや、その出力形式を文法で制約する方法を説明した。 9月29日のClaude Agent SDKの説明は、情報を集め、行動し、結果を検証する反復と、ファイルやコマンドを使う仕組みを示す。 モデルが表現できる操作と、その操作を実際に繰り返す実装の両方が、仕事の構成に関わる。
レポート作成では、根拠が足りない段落を見つけて別の資料を探し、下書きを直す反復が役立つ。 単純な一回の生成より、必要な情報を取りに戻れるためだ。 ただし、検証役が同じ誤読を繰り返したり、もっともらしい説明を根拠として採用したりすれば、反復しても正しくならない。
そこで、出典の実在や数値の一致など、決まった方法で確認できる条件を先に分ける。 資料から解釈を導く部分はモデルに任せても、読み取れなかった値を推測で埋めてよい条件にはしない。 SDKが確認の機会を用意することと、確認する対象や合格条件が正しいことは別である。
この比較を、モデルの能力はもう重要でないという結論にはつなげられない。 読み取り、計画、ツール選択の能力が不足すれば、良い手順も役に立たない。 一方、モデルを替えるだけでは、どの資料を使い、何を確かめたかを記録する仕組みは決まらない。 同じ仕事について、能力と実装の両方を評価する必要がある。
作成と変更の確認
手順が見えることで、成果の誤りを探す入口が増える
10月6日のAgentKitの発表は、視覚的な手順作成、版管理、実行記録を使う評価などを示した。 ChatKitとEvalsは一般提供、Agent Builderはベータと、部品の提供段階は異なる。 11月25日のFoundryの複数エージェントワークフローは公開プレビューで、図とYAML、変数、構造化出力による工程の接続を説明する。
どちらも、手順を作り、実行を調べる対象を具体化する資料である。 ただし、同じ実装や同じ観測範囲を示す製品比較ではない。 Foundryの初期リリースの観測は、ワークフロー内の個々のFoundryエージェントが中心とされる。 図が表示されたから、外部の資料や公開先の状態まで一括で確認できるとは言えない。
レポートの手順が「検索、執筆、確認」の順で動いた記録は、原因を探す入口になる。 それでも検索時の資料が古かったか、執筆時に条件を落としたか、確認役が引用先へ戻ったかは、別に読む必要がある。 経路が予定どおりであることと、比較の内容が正しいことを、別の合格条件にする。
版を保存できることにも、同じ区別がある。 手順を同じ版に戻しても、外部の資料が更新されていれば、前と同じ下書きにはならない。 変更前後を比べるときは、手順だけでなく、入力と使う資料をそろえる。 見える手順は判断を助けるが、判断に必要な条件を自動で選んではくれない。
実行を制限する
許可された操作と、役に立つ結果は別に確認する
12月2日のAgentCore PolicyとEvaluationsのプレビュー発表は、この違いを具体的に示す。 Policyは、関連付けたGatewayを通るツール呼び出しへ、エージェントの推論の外側で条件を適用する。 発表の返金例は、認証情報の役割と、金額が200未満であることを条件にする。 Gatewayで強制する設定と、記録のみの設定も区別されている。
この条件を満たしても、対象の注文が返金可能か、顧客や金額が正しいかまでは、この例の条件だけでは分からない。 反対に、文章として正しい返金理由を書けても、実行権限を得たことにはならない。 実行を許す条件と、内容を正しいと判断する条件を分ける必要がある。
同じ発表のEvaluationsは、実行記録やセッションなどを対象に、組み込み・独自の品質評価を行う方法を説明する。 設定した割合で実行を抽出する評価も示される。 品質の傾向を調べる仕組みから、すべての操作が事前に許可済みだとは判断できない。 本稿の公開作業でも、下書きの質の評価と、どの版をどこへ公開してよいかという許可を、同じ点数で代用しない。
想定例でつなぐ
根拠収集、下書き、公開を、それぞれ終えられる仕事にする
ここまでの進展を、比較レポートの三段階へ当てはめる。 これは各製品をすべて組み合わせる導入案でも、実測した成功例でもない。 どの部品を使うにせよ、任せる仕事の終わり方を具体化する設計例である。
根拠を集める
取得した資料の出典、日付、該当箇所と、取得できなかった資料を渡す。 通信の成功だけでは、調査完了としない。
下書きを作る
資料の主張、比較条件、著者の解釈を区別する。 条件が違う測定値を、同じ順位へ並べない。
公開する
確認した版と、実際に公開した版を一致させる。 公開先の結果が不明なら、完了と表示しない。
資料の収集だけを任せる段階でも、人の負担を減らせる可能性はある。 担当者が出典へ戻り、不足を把握し、そのまま比較を始められるなら、収集の成果が役に立つからだ。 逆に、きれいな下書きを受け取ってから出典を全部探し直すなら、見かけの進み具合ほど仕事は進んでいない。
この差を見てから、下書きや公開へ任せる範囲を広げたい。 途中の成果が検証できれば、誤りを見つけた段階まで戻れる。 全工程を一度に任せる方法は、最後に誤りが見つかったとき、どこから直すべきかを調べる負担も含めて比べる必要がある。
次に任せる判断
機能の数ではなく、確認後に残る仕事で選ぶ
比較には、同じ依頼と資料を使い、従来の人の作業や固定した処理を置く。 公開できる成果の割合、欠けた根拠を見つけられたか、担当者の修正・再調査にかかった時間を見る。 取得失敗、条件の曖昧な依頼、資料の更新も含める。 範囲を絞れば必ず速くなるという前提ではなく、どの範囲なら負担が減るかを調べるためである。
2025年の資料から読めるのは、操作、接続、反復、作成、評価、制限を実装する選択肢が増えたことだ。 それを業界全体の導入成功や、モデル競争の終わりとは言い換えられない。 既存の処理で十分な部分には、新しい部品を加えない判断もある。
本稿のレポートなら、最初の目標は最後まで無人で動かすことより、担当者が調査をやり直さずに次へ進める資料を渡すことになる。 その条件を満たした範囲から、下書き、公開へと任せる対象を広げる。 一年の進展を仕事の改善へつなぐのは、使える機能を数えることではなく、受け取った成果によって人の次の判断が確かに進むかを確かめることだ。