Claude Managed Agents｜セッション閲覧とAuto modeで単価設計

9月10日更新で何が変わったか—Claude Managed Agentsのセッション閲覧とAuto mode

2026年9月10日、Claude Managed Agentsについて、作業中のセッションを見て接続できるセッションビューアと、操作ごとの判断を助けるAuto modeが相次いで案内されました。ここで確認できるのは機能の追加と操作の考え方であり、これだけで品質や安全が保証されるという意味ではありません。セッションを観察できることと、案件の判断を人が引き受けることを分けて捉えるのが出発点です。更新の事実は、セッションビューアの公式告知（出典: https://x.com/ClaudeDevs/status/2098120133549895978 ）とAuto modeの公式告知（出典: https://x.com/ClaudeDevs/status/2098120135718433024 ）で確認できます。

セッションビューアは実行中の作業へ確認・接続する入口

公式告知では、ant beta:sessions connect によって稼働中のセッションへ端末から接続でき、--web を付ければWebからも確認できると案内されています。つまり、完了した結果だけを受け取るのではなく、作業がどこまで進んでいるか、判断が止まっていないか、途中で出力が変わっていないかを見る接点が増えたということです。長い依頼ほど、最後に一度だけ開くより、確認の節目を先に設計した方が手戻りの原因を見つけやすくなります。

たとえば、調査を任せる案件なら開始直後に入力資料の読み取り状況を見て、途中で参照先や解釈に迷いがないかを確認し、終了前に成果物の形式と不足項目を確かめます。ビューアに表示された内容をそのまま合格判定にせず、表示された事実、依頼者が確認した事実、まだ確認していない事項を別々に記録してください。この三つを混ぜないことが、顧客へ説明する際の信頼性を支えます。

Auto modeは操作ごとの判断を依頼の意図と分けて考える

同日の告知では、user.message に含まれる依頼の意図を踏まえて、Claudeが個々の操作を実行するか判断するAuto modeが案内されました。ここで大切なのは、作業全体を一括で許可する仕組みとして扱わないことです。読み取り、整理、下書きのような戻しやすい処理と、外部へ影響する変更を同じ扱いにすると、確認が必要な場面を見落としやすくなります。

案件に組み込むときは、Auto modeが判断しやすいように依頼の目的、対象範囲、完了条件、止まる条件を短く書きます。そのうえで、操作が実行されたかどうかだけではなく、なぜその操作を許容したのか、どの確認が残っているのかを人の記録として残します。機能の便利さを評価する軸を「放置できる時間」だけにせず、「確認すべき判断を見逃さない設計」に置き換えることが重要です。

画面のペイン分離は監督の視線を分ける補助になる

同日には、Claude Codeのデスクトップ画面で、差分や端末のペインを別ウィンドウへ切り離せる更新も発表されました。これはManaged Agentsそのものの機能説明ではありませんが、長時間の作業を確認する際に、作業の進行と成果物の差分を別々に見る発想と相性がよい補助情報です。公式のペイン分離告知は https://x.com/ClaudeDevs/status/2098090911137972271 で確認できます。

ただし、画面を広く表示できることと、確認の責任が軽くなることは別です。左側で進捗を追いながら右側で成果物を確認する場合でも、誰が、いつ、どの条件を見て合格としたかは一行で残します。複数の表示を並べる目的は作業を華やかに見せることではなく、判断の見落としを減らし、あとから経緯を説明できるようにすることです。

実行中セッションを見える化する—案件の確認点と顧客へ渡す記録の置き方

セッションを見られるようになっただけでは、監督の品質は上がりません。見る対象が曖昧なままだと、画面を開いても「動いている」という印象しか残らず、顧客へ渡せる根拠にならないからです。最初に目的と合格条件を固定し、途中の確認を同じ順序で行い、最後に未確認事項まで記録することで、閲覧機能を案件の品質管理へ変えられます。確認のタイミングを案件ごとに変えると担当者の感覚が結果を左右するため、誰が同じ基準で読める記録にすることが実効性を決めます。

開始前に目的と合格条件を一行で固定する

作業開始前に、何を入力し、何を成果物として受け取り、どの状態なら合格とするかを一行で書きます。調査なら対象期間と引用の条件、制作ならファイル形式と修正回数、開発なら対象範囲と確認する画面を決めます。目的が「調べる」だけだと判断が広がるため、成果物の名前、必須項目、確認者まで置くと、途中で見るべき箇所が具体的になります。

顧客から受け取った資料に版や期限がある場合は、開始時点の名称も残してください。あとで入力が差し替わると、同じ結果に見えても前提が変わっている可能性があります。セッションの記録へ入力の版、開始時刻、依頼文の要点を添えておけば、結果の良し悪しだけでなく、どの条件で作業したかを説明できます。

途中の確認を進捗・判断待ち・失敗・成果物に分ける

長時間の作業は、確認の目的を四つに分けると見やすくなります。進捗は予定した範囲を進んでいるか、判断待ちは人の回答が必要な状態か、失敗は再試行や方針変更が必要か、成果物は納品条件に近づいているかを見る項目です。単に回数や経過時間を追うのではなく、次に誰が何を決めるのかまで記録します。

案件で確認を行う順序は、次のように固定すると担当者が変わってもぶれにくくなります。

1. 開始時に、目的、入力、成果物、合格条件、確認者を記録する。
2. 中盤で、作業範囲が広がっていないか、判断待ちが残っていないかを見る。
3. 異常が出たら、原因を推測して進めず、止める条件に当たるか確認する。
4. 完了前に、成果物の形式、必須項目、引用、未確認事項を照合する。
5. 顧客へ渡す記録には、見えた事実と人が確認した事実を分けて書く。

見えた事実と人が確認した事実を記録で分ける

「セッションに表示された」「操作が終了した」「ファイルが生成された」は観測した事実です。一方、「仕様に合う」「公開してよい」「顧客へ納品できる」は、人が条件と照合して下した判断です。この二つを同じ完了欄へ書くと、表示された結果が人の承認を受けたように読めてしまいます。記録では、観測、確認者、確認日時、判定、残課題を別欄に分けてください。

顧客へ渡す短い報告では、長い画面記録をそのまま添付する必要はありません。対象のセッション、主要な節目、確認した成果物、未確認の範囲、次に必要な判断を数行でまとめます。詳しい情報が必要な場合だけ元の記録へ案内する形にすると、説明の負担を増やさず、納品の透明性を保てます。

Auto modeに任せる範囲と人が引き受ける判断—機密・公開・契約の境界

Auto modeを案件へ取り入れるときの基準は、機能名ではなく、失敗したときに戻せるか、影響範囲を限定できるか、結果を人が確認できるかです。任せる対象を広げるほど作業時間は短く見えるかもしれませんが、問題が起きた際の説明と修正に時間がかかります。最初は戻しやすい処理から始め、判断が重い箇所ほど人の確認を残す設計が現実的です。判断の重さを言葉にできれば担当者が変わっても同じ範囲で使えるため、機能の設定より先に責任の境界を案件に合わせて明らかにします。

任せやすいのは読み取り・整理・下書き・限定修正

読み取り、資料の分類、重複の整理、下書きの作成、決められた範囲の表記修正は、元データを残し、差分を確認できるなら任せやすい作業です。対象フォルダや対象項目を限定し、変更前の状態へ戻せることを開始条件にしてください。ここでいう任せやすさは、必ず正しく終わるという意味ではなく、人が短時間で差分と合格条件を照合できるという意味です。

一方、整理の途中で新しい資料を探す、元の仕様を変える、対象外のファイルへ触れるといった動きが出たら、いったん止めて範囲を確認します。依頼文に書かれていない目的を善意で補わないことも重要です。便利な提案が出ても、成果物の合格条件に必要か、修正した場合に影響範囲を説明できるかを人が判断します。

人が確認するのは機密・請求・公開・契約に触れる場面

機密情報を含む資料、金額や請求に関わる処理、外部へ公開する文章やファイル、契約条件を変える判断、取り消しにくい変更は、人が確認してから進めます。これらは正誤だけでなく、権限、責任、顧客との合意に関係するためです。画面で操作内容が見えていても、誰が許可したか、どの合意に基づくかまでは機能だけで決まりません。

人の確認を残す場面は、次の三つの問いで判断できます。

1. 失敗したとき、元の状態へすぐ戻せるか。
2. 影響を受ける人、資料、金額、公開先を限定できるか。
3. 合格条件と承認者を事前に説明できるか。

三つのうち一つでも答えが曖昧なら、操作を任せる範囲を狭めます。確認者が不在の時間帯に無理に進めるのではなく、読める状態の下書きや判断待ちの記録で止める方が、後からの手戻りを小さくできます。

任せる条件・止める条件・戻す条件を先に決める

案件開始時には、任せる条件、止める条件、戻す条件をそれぞれ短く書きます。任せる条件は対象と合格条件が明確で、元に戻せること。止める条件は対象外の資料、想定外の依頼、機密や金額への接触が出たこと。戻す条件は合格条件を満たさない、差分の理由を説明できない、確認者が判定できないことです。

この三つを先に決めると、Auto modeを使うかどうかをその場の勢いで決めずに済みます。作業の途中で条件が変わったときは、依頼文へ追記して続けるのではなく、変更点と新しい確認者を記録してから再開してください。短い中断は、納品直前に大きな修正を抱えるリスクを抑えるための費用です。

監督を成果物に変える—受託案件の見積もりと単価を守る確認基準

セッションの確認を無償の見張り時間として扱うと、長時間案件ほど担当者の負担だけが増えます。提案時点で、作業そのものに加えて、確認表の作成、途中の判断、成果物の照合、顧客への説明、手戻りへの対応を提供範囲へ入れてください。速く作れることを値引きの理由にせず、確認可能な品質を納品単位として示すと、単価の議論を作業時間だけから動かせます。確認にかけた時間と、その確認で防げた手戻りを分けて示すと、監督が見えない付加作業ではなく説明可能な成果物になります。

見積もりを作業時間だけから確認単位へ広げる

見積もりには、作業時間だけでなく、確認の回数と一回あたりの時間、手戻りの想定、納品記録の作成を置きます。例えば作業5時間、確認1.5時間、顧客説明0.5時間、修正予備1時間というように、何に時間を使うかを項目化します。数字は案件ごとに変わりますが、項目が見えていれば、顧客は単に「AIを使ったから安い」と比較するのではなく、どの品質を受け取るのかを判断できます。

確認単位の考え方は、担当者の熟練度にも有効です。作業が速い人ほど確認を省くのではなく、確認に必要な条件を先にそろえ、同じ合格条件で記録を残します。作業者が変わっても確認表と納品記録を引き継げるなら、個人の勘に依存せず、継続案件として提案しやすくなります。

監督付き納品を顧客に説明する項目

顧客向けの提案では、「長時間任せられます」とだけ書くと、何が保証されるのかが不明確になります。代わりに、どの場面を確認するか、どの変更を人が承認するか、未確認事項をどう知らせるかを明記します。セッション閲覧は作業の経緯を共有する手段であり、品質判定そのものではないことも、最初に説明しておくと期待値のずれを抑えられます。

提供範囲として示しやすいのは、次のような項目です。

1. 開始時の入力資料、目的、合格条件の確認。
2. 中間の進捗、判断待ち、失敗時の停止と連絡。
3. 完了前の成果物照合、差分確認、未確認事項の明示。
4. 納品後に見つかった修正点の整理と、次回への改善提案。

これらを記録として渡せば、顧客は結果だけでなく、どのような確認を経たかを把握できます。すべての操作を詳しく報告する必要はありませんが、重要な判断の根拠と未確認の範囲は省かないことが大切です。

単価を守る提案文は速さではなく合格条件で書く

提案文の中心は「短時間で作成できる」ではなく、「指定された条件を確認できる形で納品する」です。作業時間が短くなった分をすぐ値引きすると、確認と説明の価値まで消えてしまいます。作業、監督、納品記録、改善の四つを分けて示し、顧客が不要な項目を選べるようにすると、価格の根拠を会話しやすくなります。

例えば、下書きだけを渡すプラン、確認表と差分を付けるプラン、納品後の改善提案まで含むプランを用意します。各プランで確認者、修正回数、記録の範囲を変えれば、安さだけでなく必要な安心の量で選んでもらえます。Auto modeの利用そのものを価値として売るのではなく、機能を使っても人が引き受ける判断と記録を含めて提供することが、単価を守る要点です。

小さく試して提案へつなげる—長時間案件の時間・手戻り・確認の測り方

新しい機能をいきなり全案件へ広げる必要はありません。直近の案件から、入力と合格条件が比較的明確で、失敗しても戻せる一件を選び、同じ作業を従来の方法と比べます。見る数字は作業時間だけではなく、任せた時間、人の確認時間、手戻りの時間、納期への影響です。セッションビューアで途中を見られるようになったことが、実際の説明負担や修正回数をどう変えたかを測ります。数値を取る目的は機能の優劣を決めることではなく、自社の案件条件でどの監督が必要かを確かめることです。

直近一件を選び三つの時間を測る

最初の試行では、案件全体の効率を大きく語らず、三つの時間を分けて記録します。任せた時間は作業が進んでいた時間、人の確認時間は画面や成果物を人が見て判定した時間、手戻り時間は修正ややり直しにかかった時間です。これに納期への影響と、確認できなかった項目を添えると、単純な短縮率では見えない品質の差が分かります。

測定時は、前回案件と今回案件で入力資料、成果物、合格条件が大きく変わらないようにします。条件が違う場合は、比較結果として断定せず、今回の観測として扱ってください。公式発表が示す機能の存在と、自社案件で得た実測値は別の情報です。二つを混ぜずに書くことが、顧客への説明と次の改善を正確にします。

顧客向け記録と次回見積もりを分ける

顧客へ渡す記録には、その案件の目的、確認した節目、合格した成果物、未確認事項、次に必要な判断だけを残します。一方、次回見積もり用の記録には、任せた時間、確認時間、手戻り、質問の回数、資料の不足など、改善に必要な細部を残します。二つを分けると、顧客へ過剰な内部情報を渡さずに、次回の価格と体制を具体化できます。

試行後は、次の順序で結果を整理します。

1. 事実として測れた時間と回数を確定する。
2. 人の確認で合格した項目と、未確認の項目を分ける。
3. 手戻りの原因が入力、判断、成果物、説明のどこにあったかを分類する。
4. 次回も残す確認と、条件付きで任せる確認を決める。
5. 見積もりへ追加する時間、記録、修正範囲を反映する。

継続支援として提案し、導入可否を見直す

一件の試行で良い結果が出ても、すぐに常時任せる結論へ進めないでください。案件の種類、資料の機密性、確認者の在席時間、顧客の修正頻度が変われば、同じ設計が合わないことがあります。月に一度、任せた範囲、停止した場面、手戻り、顧客からの質問を見直し、条件を広げるか狭めるかを決めます。

提案を継続支援へつなげるなら、月次の確認会、記録の更新、合格条件の見直し、改善項目の優先順位付けを組み合わせます。単発の作業量が減っても、顧客が安心して任せられる条件を整え続ける価値は残ります。セッション閲覧とAuto modeは、その価値を作る道具の一部です。最終的に単価を守るのは、機能名ではなく、どの判断を誰が確認し、どの成果物をどの条件で渡したかを説明できる運用です。

今回の補助視聴資料は、表示上の最新公開が2026年7月25日で、対象日の直近速報ではありません。モデル比較、低価格、プログラミング、成果物作成への関心を読む材料として扱い、9月10日の機能事実を裏付ける根拠には使いません。

公式発表と補助資料を分けて確認する—Claude Managed Agents出典一覧

今回の記事の中心根拠は、2026年9月10日に公開されたClaudeDevsの三つの告知です。セッションビューアとAuto modeについての事実はそれぞれの告知へ戻り、デスクトップ画面の補助情報はManaged Agentsの機能と混同しないように扱いました。Anthropicの脅威インテリジェンス報告は同日の周辺動向を確認する資料ですが、この記事の機能説明や案件判断の根拠ではありません。動画は関心の傾向を読む補助資料として列挙します。

• セッションビューアの更新（2026年9月10日）: https://x.com/ClaudeDevs/status/2098120133549895978
• Auto modeの更新（2026年9月10日）: https://x.com/ClaudeDevs/status/2098120135718433024
• デスクトップ画面のペイン分離（2026年9月10日）: https://x.com/ClaudeDevs/status/2098090911137972271
• Anthropicの脅威インテリジェンス報告（2026年9月10日）: https://x.com/AnthropicAI/status/2098097512544444447
• 補助動画: https://www.youtube.com/watch?v=IH0cg0bHNsg
• 補助動画: https://www.youtube.com/watch?v=SovZK4r6odI
• 補助動画: https://www.youtube.com/watch?v=nap0kyhoZm8
• 補助動画: https://www.youtube.com/watch?v=8bNSnRlvQ-4
• 補助動画: https://www.youtube.com/watch?v=nNjXOmmbVEc

※ 利用可否、権限設定、料金、保存期間などは契約や公開状況で変わる可能性があるため、利用前に一次情報をご確認ください。