OpenAI DevDayを仕事の設計から読む。dotsとSol、共同作業の接点

DevDayを、継続する仕事の設計として読み直す

OpenAIが9月29日のDevDay 2026で示した発表は、新しいモデルだけではない。常時稼働のdots、クラウドで動くCodex、外部ツールを組み込むプラグイン、チームで成果物を扱うSpaceなど、仕事を任せてから受け取るまでの仕組みが広がった。

そのため、導入時の問いも「どのモデルが賢いか」だけでは足りなくなる。誰のIDで動くか、どの資料を読み、どこへ書けるか、支出が増えたら止められるか、途中の成果を誰が確認するか。長い仕事をAIへ渡すほど、こうした運用が製品の使いやすさを左右する。

本稿はイノベトピアのDevDay解説を起点に、公式発表と現在の開発者資料を確認して構成した。9月29日の発表時点の情報と、10月18日に確認できる情報を区別する。以下の導入例や評価方法は編集部の考察であり、実際に企業へ導入して得た成果ではない。

同じ発表でも、四つの層に分けると選びやすい

最初に区別したいのは、モデル、エージェント、作業環境、成果を共有する場所だ。モデルは推論や生成を担い、エージェントはそれを使って手順を進める。作業環境にはファイル、ブラウザー、実行するコード、認証などが入り、共有する場所には会話、文書、レビューの履歴が残る。

一つの名称で複数の層が案内される場合もあるが、変更したときの影響は違う。モデルを変えれば出力や費用が変わり、接続するアプリを増やせば読める情報と実行できる操作が変わる。成果物の共有先を変えれば、見る人と承認の流れが変わる。

この区別をしないと、必要なのは文書の共同編集なのに高額なモデルだけを導入したり、モデルの単価が下がったので権限まで広げたりする判断につながる。発表された機能を一式で評価するより、現在の仕事で不足している層から見たい。

dotsの基盤モデルと、新しいSolは別の話

dotsは、GPT-6 Astraを搭載し、専用のクラウドコンピューターで働く常時稼働のエージェントとして発表された。GPT-6.1 Solも同日に紹介されたが、dotsの説明を、そのままSolの機能紹介に置き換えることはできない。

モデルが道具を使う力と、いつ仕事を始め、どの環境を持ち、どの利用枠を消費するかは、異なる仕様だ。たとえばモデルのAPIを呼べることだけでは、個人のdotと同じ記憶や接続アプリ、常時稼働の環境が自動で付くわけではない。

編集部の考察では、利用者は成果を任せる相手と、その相手が使う計算資源を分けて把握する必要がある。仕事が遅いときも、推論の遅さ、外部サービス待ち、確認待ちのどれかで対策は変わる。モデルを上位へ変えるだけでは解決しない場合がある。

常時稼働を、常に全権限で動くことと捉えない

専用のコンピューターを持つ利点は、依頼者がノートPCを閉じても、仕事の状態を保ちやすいことだ。同時に、依頼者の端末やファイルへ当然にアクセスしてよいという意味ではない。どの接続を許可したかが、作業範囲を決める。

dotsの発表は、隔離された環境、専用の身元、行動のレビューなどを組み合わせる設計を説明する。人が直接依頼していないときの先回り調査と、外部へ影響する操作も同じ権限では扱わない。パスワード変更のように本人が行う作業もある。

この境界は、便利さを損なう付属条件というより、長く任せるための前提だ。仕事を途中で再開できるAIほど、古い依頼がいつまで有効か、権限が変わったときにどこで止まるかが重要になる。人の不在中にも続く処理は、終了条件まで定めておきたい。

依頼文には、成果物と完了条件を入れる

「営業を支援して」のような目標だけでは、どんな成果を受け取れば終わりなのかが曖昧になる。調査、候補の整理、文面の下書き、送信は、それぞれ別の操作だ。最後の操作を許可していなくても、その手前までの仕事には価値がある。

以下は編集部が考える依頼の組み立て方だ。まず、作るものを指定する。次に、使ってよい資料と、足りないときの扱いを示す。そのうえで、どの結果を人が確認し、どの操作で止めるかを決める。作業量が多い場合は、件数や期限、費用の上限も付ける。

たとえば定例報告なら、参照する期間、対象データ、比較対象、出力先を明示する。資料が未着なら推定で穴を埋めず、不足として残す。文書を保存した後に関係者へ配信するかは、保存する依頼とは別に扱う。こうした定義は、人へ引き継ぐ際にも役立つ。

完了条件は、AIの「できました」という報告ではなく、結果を独立して確認できる形にする。ファイルが開けるか、計算が再現できるか、対象の画面へ反映されたか。工程ごとの証拠があれば、途中で止まった場合も、どこから人が受け取るかが分かる。

会話の窓口が増えても、一つの指示として整合させる

dotsはChatGPTのほか、SlackやTeamsなどから連絡する設計を示した。公式の連絡方法の案内では、チャネルごとの使い方や条件を確認できる。発表時にはテキストメッセージなど一部の機能に限定条件があったため、日本で利用できる範囲を名前だけから推定しないことが必要だ。

複数の窓口は便利だが、依頼が増える場所も増える。あるチャットで対象を10件に絞り、別の場所で追加の資料を渡したとき、それが対象を増やす指示なのか、既存の仕事の補足なのかを明確にしたい。

編集部の考察では、仕事ごとに共通の識別子や成果物へのリンクを使う方法が有効だ。新しい依頼と、進行中の作業への訂正を分ける。複数人が指示を変えられる場合は、確定する責任者を決める。会話の文脈を引き継げることと、意見の食い違いを自動で解決できることは同じではない。

支払いは、モデルの料金とプランの利用枠を分ける

サブスクリプションにエージェントが含まれることと、あらゆる作業が無制限であることは別だ。dotsとの相談と、そこから始めるCodexやWorkのタスクでは、利用枠の数え方が異なりうる。追加のエージェントや速度をどう買うかも、契約条件の確認が必要になる。

9月の発表では、新しい月額500ドルのProや、対象企業向けの提供など、複数の買い方が示された。価格が高いプランにすれば、外部アプリの契約やAPIの請求もすべて含まれるという意味ではない。接続先ごとの費用を含めた一覧を作りたい。

実務では、相談、調査、コード実行、画像作成、外部サービスという工程別に、どこが請求元かを記録する。利用者一人の上限に達したとき、チームの仕事が止まるのか、追加課金へ移るのかも確かめる。停止と支出が分かれば、作業を安心して定期化しやすい。

GPT-6.1 Solの料金は、比較する分母をそろえる

10月18日に確認したGPT-6.1 Solの公式モデルページは、標準の100万トークン当たり入力2ドル、出力10ドル、キャッシュ済み入力0.10ドルを示す。キャッシュ書き込みは2.50ドルで、長い入力や処理モードには別の倍率がある。

前世代Solと比べる場合、通常の入出力単価が同じであることと、キャッシュ単価が下がったことを分ける。Astraとの比較では、同じ種類の標準料金を並べれば入出力は5分の1だ。しかし、これは一つの仕事が必ず5分の1の費用で終わるという意味ではない。

同じ入力でも、出力の長さ、思考量、ツールの呼び出し、失敗後の再試行が変わる。キャッシュに乗る部分の割合も、仕事ごとに違う。モデルの単価と、仕事を完了する費用を、別の表で扱う必要がある。

キャッシュの効果を見積もる

繰り返し使う前提資料が多い場合、再利用される入力の費用は総額へ影響する。ただし、毎回大きく内容を変えたり、再利用が成立しない形式で送ったりすれば、期待した削減が得られない可能性がある。キャッシュが使われた量は、実際の使用量で確認したい。

編集部の考察では、固定の説明、タスクごとに変わる情報、外部ツールの結果を整理しておくことに意味がある。費用のためだけでなく、どの情報が古くなったかを特定しやすくなるからだ。古い価格表を効率よく読み続けても、正しい仕事にはならない。

見積もりでは、一回の平均だけでなく、長い入力に当たる割合や最大の使用量も見る。普段は短い問い合わせでも、月末の集計で大量の資料を渡すなら、その日の費用と処理時間は変わる。平均に埋もれる負荷を、定期業務の予定と合わせて確認する必要がある。

速度の倍率は、仕事全体の倍率ではない

DevDayではUltrafastのような速度の選択肢も示された。9月時点の記事には、6.1 Sol版を近日予定とする説明があるが、10月18日の公式モデルページではUltrafastの指定方法が案内されている。提供の状態は更新されるため、当時の予定をそのまま現在の状態として伝えるべきではない。

また、トークン生成速度が何倍になったとの説明は、調査や承認を含む全工程が同じ倍率で短くなることを示さない。外部サイトの応答、ファイルの変換、テスト、人の確認が長ければ、モデルを高速化しても短縮は小さい。

高速モードには費用の差もある。編集部としては、急ぐ仕事だけへ使う方法と、通常モードで早めに開始する方法を比較したい。性能を測るなら、最初の文字が返る時間、出力が終わる時間、成果物が使える状態になる時間を区別する。利用者が知りたいのは、多くの場合最後の時間だ。

ベンチマークの近さは、仕事の交換可能性ではない

OpenAIは、コーディング、コンピューター操作、専門資料の読解、科学的な作業など、複数の評価でSolの改善を示した。これらはモデルの用途を考える手がかりになるが、同じ点数に近いからすべての作業を同じように任せられるわけではない。

コードの修正を評価する課題と、複数の業務ツールを使って仕事を終える課題では、失敗の種類が違う。部分点のある画面操作と、最後まで完了しないと価値が出ない実務も違う。モデル単体の結果と、特定のツールやフォールバックを組み合わせた構成の結果を混ぜないことが大切だ。

他社モデルとの比較は、測定した時点や実行環境も見る必要がある。公開値を並べたグラフでは、同じ試験を同じ環境で走らせたとは限らない。人が確認する時間を含めた成功一件当たりの費用まで、自社の課題で評価して初めて、導入の判断へ近づく。

日本語の仕事に合わせた試験を用意する

日本のチームなら、日本語の固有名詞、社内略語、表の形式、長い議事録、古い版と新しい版の混在を含む課題を用意したい。一般的な文章の要約だけでは、日常業務で起きる失敗が見えない。

正解を一つにできない仕事では、確認すべき点を先に定める。根拠へ戻れるか、比較条件を保つか、分からないところを残すか、承認前の操作をしないか。成果物の読みやすさと、判断の妥当性を別々に見ると、何を直せばよいかが分かりやすい。

また、失敗した課題を次の評価へ残す。モデルを更新した際に同じ入力を再実行できれば、改善した点と悪化した点を比較できる。最高の例を選んで紹介するデモとは異なり、運用の試験は、平均と失敗の両方を見せる必要がある。

安全性補遺は、能力の増加と防御の条件を読む資料

GPT-6.1 Solの安全性補遺は、Preparedness Frameworkにおけるサイバー能力をCritical、生物・化学をHighと位置づけ、評価と防御策を説明する。これらはモデルの能力区分であり、一般利用者がその能力を無制限に使えるという意味ではない。

同資料では、改善した指標だけでなく、上がった懸念も報告する。社内の配備シミュレーションで深刻な逸脱フラグが少なかったことと、制限の回避を試みる一部の評価値が高かったことは、矛盾せず同時に成り立つ。測っている条件と対象が違うからだ。

ここで避けたいのは、小さな割合をそのまま実社会の事故率と呼ぶことだ。意図的に難しくした課題、システム側の制御を外した試験、社内業務を模した構成は、通常利用の分布と同じではない。フラグは確認を要する観測であり、すべてが同じ深刻さの実害を意味するわけでもない。

指標が改善しても、境界は残す

編集部の考察では、モデルの改善は権限設計を省略する理由にはならない。機密ファイルを読める環境で自由に外部通信できるなら、一つの誤りが情報送信へ変わりうる。必要な範囲だけを接続し、外部へ影響する操作を確認する仕組みを重ねることが重要だ。

特に、資料不足や道具の不調で完了できない課題を評価に含めたい。存在しないデータを補って成功したように見せるより、どの入力が欠けているかを報告するほうが実務では有用だ。成功率を上げるという目標に、正しく止まることを含める必要がある。

承認された作業でも、途中で新しい接続や別の相手への送信が必要になったら、判断の前提が変わる。最初に許可した目的だけで、すべての手段が許可されたことにはならない。どこで人へ戻すかを決めたほうが、任せる側も結果を受け取りやすい。

監視は、最終報告だけに頼らない

エージェントの最後の文章は、途中のすべての操作を網羅するとは限らない。何を読み、どのコマンドを実行し、どこへ書いたかを、実行環境の記録でも追える必要がある。人に分かりやすい要約と、調査に使うログは役割が違う。

安全性評価では思考の記録を使う監視も扱われるが、それだけで十分と決めつけないほうがよい。外部へ出た通信やファイルの変更は、実行結果として確認できる。申告と観測を分ければ、誤った最終報告にも気付きやすい。

運用で残す記録は、多ければよいわけでもない。機密を含むログを不用意に共有すると、監視自体が新しい情報管理の問題になる。取得する項目、保存期間、閲覧者、事故時の提出方法を決め、必要な確認ができる範囲で管理することが望ましい。

Codexクラウドは、実行環境を共有する判断でもある

クラウドで開発を進められると、端末の状態へ依存しにくくなり、共通の環境を再利用できる。複数のタスクを進める場合にも、設定をそろえやすい。一方、ローカルにしかないファイルや認証が必要な仕事は、そのまま移せるとは限らない。

編集部としては、移す前に、依存関係、環境変数、必要なサービス、実行するテストを整理したい。秘密情報を含む設定を丸ごと複製するのではなく、作業に必要な権限を別に用意する。再現できる環境ができれば、人がレビューするときにも同じ条件で結果を確かめやすい。

並列に進める開発では、コードの競合だけでなく、共有データベースや外部APIへの影響もある。worktreeのようにファイルを分ける方法があっても、接続先まで分離されるわけではない。作業を同時に走らせる前に、共有してはいけない資源を把握する必要がある。

コードレビューは、変更の意図と実行結果を結ぶ

開発用AIが差分を作れるようになるほど、その変更を受け入れてよいかを判断する工程が重要になる。自動レビューは最初の指摘を早めるが、レビューを実行したことと、製品の要件を満たしたことは別だ。

確認する人に必要なのは、何を変えたか、どんな条件で使われるか、どう検証したかだ。AIが出した長い説明より、再現する手順と実際の挙動が役立つ。問題がないという結論にも、確認した範囲を付けたい。

修正を作るAIとレビューするAIを分けても、同じ前提や評価の誤りを共有していれば見落としは残る。別の役割を与えたこと自体を独立した検証の証拠にせず、テストや実際の画面など、異なる方法の証拠を組み合わせることが重要になる。

セキュリティの継続処理は、発見後の流れも含む

DevDayでは、リポジトリ全体のスキャンや修正をクラウドで進めるCodex Security Cloudも紹介された。継続的な防御という方向は、発見の頻度を高めるだけでなく、調査、重複排除、修正までをつなぐものだ。

ただし、検出件数が増えれば安全になったとは限らない。誤検知を見分け、影響を調べ、担当を決め、修正を適用し、動作を確かめる処理能力が必要だ。確認待ちの指摘が大量に積み上がれば、重要な問題が埋もれることもある。

日本の開発チームなら、まず限られたリポジトリで、検出から修正完了までの時間を測る方法が考えられる。コードの送信範囲、必要な保存条件、外部依存の扱いを決め、AIが作る修正の承認先を明確にする。スキャンの定期化と、本番への適用は分けて設計したい。

APIを組み込むとき、任せる基盤と自社の責任を区切る

Agents APIのようなマネージドな基盤では、アプリ側が仕事と接続先を定義し、共通の実行機構を利用する方向が示された。コンピューター操作が使えても、アプリの業務上の判断や権限の設計まで自動で決まるわけではない。

利用者がブラウザー上で何を許可し、どの画面で本人が操作するかを、製品の流れとして用意する必要がある。認証が切れたとき、確認が必要な契約画面へ来たとき、利用者が途中で依頼を取り消したときに、処理をどう止めるかが問題になる。

また、接続先の仕様変更で作業が止まる場合もある。画面操作を使う構成では、ボタンや表示の変化が実行結果へ影響する。途中の状態を保存し、再試行してよい操作と、二重に行ってはいけない操作を分けておくことが、長く使うアプリでは重要だ。

判断専用のAPIと、自由な生成を使い分ける

DevDayで紹介されたDecisions APIは、有限の回答候補から選ぶ仕事を扱う方向だ。問い合わせを担当へ振り分ける場合など、自由な文章を作ることより、許された選択肢を確実に返すことが重要な用途がある。

編集部の考察では、このような用途は、判断の前後を明確にすると評価しやすい。分類の定義、迷う場合の戻し先、誤った振り分けの費用を定める。確率や確信度が返る場合も、その数値をそのまま正答率と解釈せず、実データで対応を確かめたい。

判断を細かく分ければ、すべてを最大のモデルへ渡さずに済む可能性がある。ただし、分割した各段階の誤りが積み重なる場合もある。単体の分類精度と、最後まで仕事を終えた結果の品質を両方測る必要がある。

プライバシー機能は、保存先と監視を具体的に見る

Private Intelligenceの発表では、ゼロデータ保持と安全性の審査を組み合わせる方向や、コンフィデンシャルコンピューティングを使う構想が示された。ここでは「保持しない」という語だけで、処理や記録の全体を理解したつもりにならないことが大切だ。

誰が元の内容へアクセスできるか、暗号化した記録をどこへ置くか、どれだけの期間残すかは別の条件になる。社内の資料を使う場合は、モデルへの入力に加え、外部ツール、ブラウザー、ログ、成果物の共有先も調べる必要がある。

編集部としては、機密性の異なる仕事を同じ設定へまとめず、データの種類ごとに使える構成を決めることが有効と考える。発表された機能の名称より、実際の契約と設定で何が行われるかを確認したい。

プラグインが、会話の外へ仕事をつなぐ

プラグインの拡張は、外部サービスへ接続するだけでなく、パネルやファイルビューアーなど、作業する画面をChatGPTの中へ持ち込む方向を示す。会話から別の製品へ移るたびに文脈を説明し直す負担を減らせる可能性がある。

一方、接続できる相手が増えるほど、どの情報を共有し、どんな変更ができるかを利用者へ伝える必要がある。公式ディレクトリの掲載と、自分で登録する接続、組織が許可した接続は、導入の経緯が違う。名前やロゴだけで同じ信頼水準と扱わないほうがよい。

仕事を依頼する側も、対象の作品や文書を明示するとよい。新しい成果物を作るのか、既存のものを更新するのかは、影響が大きく違う。変更前の状態を残し、書き込み先を確認できることが、便利な接続を安心して使う条件になる。

イベントで動く処理には、重複と順序の管理が要る

MCP Eventsへの対応は、接続されたアプリの変化をきっかけに作業を始める方向だ。定刻の実行だけでなく、新しい依頼や更新へ反応できる。しかし、イベントを受け取った回数と、仕事を実行してよい回数は一致しない場合がある。

同じ通知が再送されたり、複数の変更が短時間に届いたりしたとき、毎回同じ成果物を追加すれば重複する。編集部の考察では、対象IDと処理状態を残し、同じイベントを再度受けても結果が増えない設計が重要になる。

順序も確認したい。古い更新の処理が遅れて、新しい結果を上書きすることがある。単に「変化があったらAIを起動する」だけでなく、どの版を処理し、反映時に対象が変わっていないかを確かめる必要がある。定期処理とイベント処理が同時に動くなら、共通の重複防止も必要になる。

SpaceやPagesは、チームの前提をそろえる場所

文書やスライドを共同で扱う機能は、AIの出力を受け取って別のツールへ貼り付ける流れを変える。共通の目標、過去の作業、コメントを近い場所に置けば、修正の理由を残しやすい。

ただし、情報が集まることと、常に最新で正しいことは別だ。古い指示と新しい決定が並んだとき、どちらを優先するかを整理する必要がある。担当者が変わっても、決定済みの内容、仮説、未確認の資料が分かる状態にしておきたい。

AIが資料を定期更新する場合は、本文だけでなく、出典の日付や数値の対象期間も更新する。結論が変わった場合は、その理由が追えることが望ましい。人が書いた重要な注記が再生成で消えないかも、確認の対象になる。

スライドと会議メモは、完成の意味を定義する

スライドの共同編集や会議の記録が便利でも、保存されたことを会議で使える状態と同一視しない。グラフの数値、注記、見切れ、配布形式を確かめる必要がある。エクスポートできることと、相手の環境で同じように表示されることも別だ。

会議メモなら、発言の要約、決定事項、次の担当を区別したい。議論に出た案を決定として記録すると、その後の自動処理が誤った前提で動く。AIが抽出した担当者や期限は、確認できる形で残すとよい。

記録する許可や共有先も工程の一部だ。録音や会議の内容には、普段の共有フォルダーへ置いてよいとは限らない情報が含まれる。作る機能があることだけで、対象の会議をすべて記録する運用にしてはいけない。

日本のチームが最初に試すなら、戻せる仕事から

以下は編集部の提案だ。まず、参照する資料が限られ、成果物を人が確認できる仕事を選ぶ。週次報告の下書き、社内文書の比較、テストを伴う小さなコード修正などは、完了条件を定めやすい。

試験では、成果物の品質だけでなく、不足した入力を報告するか、許可のない送信へ進まないか、途中停止後に状態が残るかを確認する。成功例と失敗例を同じ形式で記録し、担当者以外も結果を確かめられるようにする。

次に、処理する量を少しずつ増やす。十件の試験で問題がなくても、千件では例外や料金が変わる。外部サービスの上限、再試行、同時実行、担当者の確認待ちを含めて評価する。人が処理できる量を超えて下書きだけを作り続けないことも大切だ。

共通の入口が増えると、IDとデータの境界が重要になる

DevDayでは、SlackやMicrosoft TeamsからChatGPTを呼び出す共同作業、対応製品へChatGPTでサインインする仕組み、承認された外部ソフトの購入に既存契約の一部を充てるMarketplaceも示された。提供条件は、発表全体の公式一覧で確認できる。購入、認証、仕事の実行という別の段階で、共通の入口を増やす発表と読める。

ここで区別したいのは、サインインと業務データの共有だ。公式説明では、サインインによって名前やメールアドレスなどのプロフィール情報は共有されるが、会話やメモリまで自動的に共有されるわけではない。追加のアクセスには別の承認が必要になる。あるサービスへ入れたことを、そのサービスが自分の過去の仕事をすべて理解していることと取り違えないようにしたい。

共同作業の権限も、同じ画面に参加できることだけでは決まらない。たとえば、会議に参加した人がページを読めても、関連する顧客管理システムの全件を読めるとは限らない。チームでAIへ頼んだ仕事が、誰の接続と権限で実行されるかを確かめる必要がある。担当者の異動で接続が切れたときに、定期処理がどの状態になるかも運用の課題だ。

Marketplaceについても、対象契約の支出を振り替えられることと、組織内の利用承認が終わることは別だ。契約対象、情報管理、支払いの責任者、既存ツールとの重複を確認して初めて、自社にとっての購入価値が見える。以下は、その判断を具体化するための編集部の提案である。

月次報告を任せる場合の、仕事の分解例

例として、営業実績の表と顧客対応の記録から月次報告を作る場面を考える。売上の増減の要因を推測で確定せず、資料にある事実と、担当者へ確認する事項を分ける。AIへ渡す前に、対象月、集計の単位、返品や取消の扱い、前月との比較条件を決める必要がある。

最初の工程では、対象のファイルがそろっているかを確認する。足りない拠点の数値があれば、全社の合計を確定させず、未着の範囲を示す。モデルが長い資料を読めても、存在しない数値まで補ってよいことにはならない。入力が不足した状態で作ったグラフを、確定資料と同じ場所へ置かないようにしたい。

次に、計算と解説を分ける。増減率は表の数値から再計算できる状態にし、増減の理由は根拠の記録へ結び付ける。問い合わせ件数が増えたことから売上増の原因を断定するなど、相関を因果へ置き換えない。複数の説明がありうる場合は、判断に必要な追加情報を示すことに価値がある。

成果物は、本文、集計表、図、参照資料の一覧を組み合わせる。役員会用のスライドへ変換するなら、桁、単位、期間、注記を引き継ぐ。元の表にあった注意書きが、見栄えを整える工程で消えていないかも確認する。長い文章を短いスライドへすることは、単純な形式変換ではなく、何を残すかという編集上の判断になる。

最後に人が確定し、共有先と版を決める。資料の保存までは自動化しても、全社員への配布や顧客への転送には別の境界を置ける。訂正が入ったら、配布前の版を更新し、どのグラフと文章に影響したかを追う。この流れなら、dotsの継続実行、Pagesの共同作業、プラグインの接続を、それぞれ必要な役割として評価できる。

長い仕事を比べるには、途中の状態も残す

一回の質問に答えるAIと違い、継続する仕事では、入力が増えたり担当者が変わったりする。最終成果だけで比較すると、途中で人が補った作業が見えなくなる。どの時点で資料がそろい、何をAIが行い、何を人が直したかを記録したい。

評価には、結果の正しさ、納期、支出、人の修正時間を同時に使う方法がある。同じ完成品質でも、確認者が何時間も差分を探す必要がある結果と、変更理由と参照元を示す結果では、チームの負担が違う。処理時間だけが短くなっても、確認時間が増えれば全体の改善とは言えない。

中断後の再開も、一度は試しておきたい。資料の読み取りまで終わった状態、成果物を保存した状態、外部サービスへの変更が一部だけ成功した状態では、再開時に必要な判断が違う。毎回最初からやり直すと、同じ変更を二度行う可能性がある。再実行してよい工程と、結果を照会してから進む工程を分ける必要がある。

試験の報告には、使わなかった資料、失敗した接続、確認が必要な判断も残す。モデルを変えた後も同じ入力で比較できるよう、対象の版と評価日を記録する。AIの機能が増える速度が速いほど、一度決めた評価を再利用できることが導入の効率につながる。

比較するのは、自動化の量より受け取れる成果

DevDayの発表を一つの方向として読むなら、AIが回答する場から、継続して仕事を進める場への拡張だ。モデルの改善、実行環境、接続、共同編集がそろうことで、依頼から成果物までの距離を縮めようとしている。

その価値を測るには、AIが何時間動いたかより、人がどんな状態の成果を受け取れたかを見る必要がある。使える成果が増え、確認に必要な証拠が残り、誤りを戻せるなら、自動化は仕事を助ける。反対に、長い実行と大量の出力だけが増えるなら、運用の設計を見直すべきだ。

同じモデル名でも、接続先、権限、記憶、評価、承認の置き方で結果は変わる。新機能を順番に有効にすることを目的にせず、何を任せ、どこで止め、誰が受け取るかを定める。発表された道具を実務の仕組みへ変える作業は、その具体化から始まる。

確認日：2026年10月18日。料金や提供範囲は、契約と公式の現在の案内を確認されたい。運営会社：RO合同会社の公式HP。