📅
Claude Code、この1週間で13発。全部深堀りしたる

2026/04/15に公開
今週、Claude Code は何個の新機能出したと思う？ わしが数えた範囲で 13 本や。しかも全部がメンテリリースやなくて、1 本ずつが記事になる密度や。1 日平均 1.8 本——そろそろ「リリースノートを読む専任」を雇う時代ちゃうかと本気で思いはじめた。
この記事は、2026-04-08 から 2026-04-15 までの 1 週間で Claude Code と Claude Platform に入った変更を 1 本ずつ全部深堀りする 週刊総集編や。いつもの単発深堀りの体力を、1 記事に 13 発ぶん詰めた格好になる。長い。覚悟して読んでや。事実関係は全部、claude.com/blog と code.claude.com/docs と GitHub の releases から一次取ってる。URL は各章に貼る。

 目次 — 今週出たもの全部まずは一覧や。各機能の詳細は下のセクションで 1 個ずつ深掘る。


日付
機能
種別
一言


04-08
Claude Managed Agents
Platform public beta
自前 agent loop を全部畳む managed サービス。$0.08 / session-hour

04-08
v2.1.96 / 2.1.97
CLI リリース
focus view (Ctrl+O) / Cedar syntax / flicker-free 強化 / Bedrock 認証 fix

04-09
Cowork for Enterprise
管理機能 GA
RBAC / spend limits / OTel 拡張 / per-tool connector / Zoom MCP

04-09
Advisor strategy / advisor tool
Platform 機能
Opus を相談役にして Sonnet に実行させる。advisor_20260301


04-09
v2.1.98
CLI リリース

Monitor tool / Vertex AI 設定 wizard / Perforce mode / subprocess sandbox

04-10
Seeing like an agent
設計エッセイ
AskUserQuestion tool / Task tool / progressive disclosure の舞台裏

04-10
Multi-agent coordination patterns
設計エッセイ
5 パターンの使い分け指針

04-10
AI-accelerated offense
セキュリティ記事
攻撃者 AI 時代のセキュリティプログラム改訂指針

04-10
Ultraplan / /autofix-pr / /team-onboarding
CLI 機能群
plan をクラウドで起草 / PR auto-fix を CLI から / teammate ramp-up 出力

04-10
v2.1.101
CLI リリース
OS CA trust / default cloud env 自動化 / Bash permission 強化

04-13
v2.1.105
CLI リリース

PreCompact hook / plugin background monitors / /proactive alias

04-14
Routines
本命 / research preview
prompt + repo + connectors をクラウド routine 化。cron がセッションに化けた

04-14
Desktop 再設計
アプリ全面刷新
sidebar / multi-session / integrated terminal / side chat / 3 view mode

04-14
v2.1.107 / 2.1.108
CLI リリース

/recap / 1 時間 prompt cache / model 内から slash command 呼出

上の表だけ見ても、「画面」「クラウド」「組織」の 3 方向に同時に手を入れとるのが分かるはずや。最後の総論でもう一回この 3 面に戻って来る。

 記事の読み方各章は 独立した深堀り として書いとる。順番に読まんでええ。目次から気になる所だけつまみ食いしてもろて構わん。最後まで通して読む人には、締めで一本通した「今週の意味」を置いとく。
ほな行くで。

 ① Claude Managed Agents — 2026-04-08 / $0.08 で agent の土管を丸投げする

 何が起きたか2026-04-08、Anthropic が Claude Platform 上で Claude Managed Agents を public beta として公開した。公式ソースはここや: Claude Managed Agents: get to production 10x faster — claude.com/blog。
一言で言うと、「クラウドホストされた agent を作って走らせるための composable な API 群」や。これまで agent を自前で組むと必ず自分で書かされとった部分——secure sandboxing、認証、credential 管理、state 永続化、tool execution、session tracing——これらを Anthropic 側が managed で提供する。あんたは体験（UX）だけに集中できる、ちゅう謳い文句や。

 仕様の詳細公式ブログと pricing docs から事実を拾うと、こうや。

提供形態: Claude Platform 上の API 群（public beta）

runtime 課金: active runtime 1 session-hour あたり $0.08。これに加えてトークンは標準 Claude Platform レートで通常課金

tool: 組み込みで web search、MCP 経由で custom tool 接続

state: 長時間走る自律セッションで persistent state を持てる

multi-agent coordination: これは research preview（access by request）で、beta 本体よりさらに手前の段階

観測性: session tracing と integration analytics を Claude Console で

対応モデル: 「purpose-built for Claude」とだけ書かれとる。Opus/Sonnet 系を前提に設計されとる
価格の詳細は platform.claude.com の pricing ページ に各 tier が載っとる。

 なぜ今このタイミングで出たかこれな、順番で理解するのが早いで。先週以前に Anthropic は Agent SDK と Claude Code on the web を出した。Agent SDK は「agent を書く道具」、Claude Code on the web は「Claude Code のクラウド版」や。ほんで今週 Managed Agents が入って、さらに Routines（後述）と Desktop 再設計が来とる。
つまりこういう階層が完成したんや:

Claude Code CLI — 個人の terminal 上の相棒

Claude Code Desktop — 画面ベースの parallel agent 司令塔

Claude Code on the web / Routines — 手元を離れたクラウド実行

Managed Agents — agent そのものを商品として組むための土台

Agent SDK — 低レイヤーの自由度
Managed Agents は Agent SDK と Claude Code の間を埋める層や。「SDK でスクラッチは辛い、でも Claude Code そのものをエンドユーザーに見せるわけにはいかん」っていう SaaS を作る側の会社 向け。ここが今まで空いとった。

 実務での使いどころAnthropic の blog は「production に 10 倍速く辿り着ける」と書いとる。実務では次のパターンがハマる:

社内 agent を全社員に配る: state / auth / sandbox を自前で組まず、session ごとに課金して配れる

外向けの agent プロダクトを作る: 自前で infra 組む体力のない会社が 2〜3 人で立ち上げられる

long-running な調査タスク: persistent state が前提なんで、数時間〜数日単位で走らせる「下請け agent」に向く

 既存機能との差分


Agent SDK
Managed Agents
Claude Code


インフラ管理
自分
Anthropic
Anthropic（CLI は手元）

カスタマイズ
最大
高
中

エンドユーザーに直接見せる
難
前提
非前提

課金モデル
token のみ
token + $0.08/session-hour
plan subscription

立ち上げ速度
遅
速
即

これは「自分で作るフェーズ」と「買うフェーズ」の境界が引かれた話や。これまでは Agent SDK か Claude Code の 2 択やったのが、中間の SKU が 1 個挟まった。

 落とし穴・リスク
public beta: 仕様は動く可能性がある。本番の SaaS の心臓にいきなり置くのはまだ早い

$0.08 / session-hour の積算: session を何時間放置するか次第で請求が跳ねる。特に long-running セッションを前提にするなら、idle 切断のポリシー設計が必須

「Claude 専用」: ポータビリティはゼロ。モデル切替の余地がない所に全体を乗せるかどうかは判断いる

Console 観測性に依存: 既存の Datadog/NewRelic 系に丸投げはできん。OTel 連携の詳細はまだ薄い

 おっちゃんの見立てええ話や。正直、わしが今 SaaS 会社やっとったら即 POC 入れる。agent の土管を自前で組んどったら土管の保守ばっかりして、肝心の体験設計に時間回せへんのはみんな経験しとる。$0.08 / session-hour は一見高く見えるけど、自分で sandbox 作る人件費と計算したら安いで。
ただな、これは 「Claude Code の客」と「Managed Agents の客」は別 やっちゅう所を間違えたらあかん。Claude Code は開発者本人の道具、Managed Agents は「開発者が作る agent を使う別の人」向け。組織内運用で自分たちが使うだけなら Claude Code でええ。商品として agent を出す会社が使うのが Managed Agents や。

 ② v2.1.96 / 2.1.97 — 2026-04-08 / flicker-free 強化と焦点 viewCLI 本体の話や。タイムライン的には Managed Agents と同じ日やけど、こっちは地味系。全部を列挙するとごちゃつくんで、要点だけ拾う。一次ソース: v2.1.96 / v2.1.97 — github.com/anthropics/claude-code, changelog.

 仕様の詳細v2.1.96（2026-04-08 04:37）:
Bedrock の AWS_BEARER_TOKEN_BEDROCK / CLAUDE_CODE_SKIP_BEDROCK_AUTH を使うと 403 Authorization header is missing で落ちとったバグを修正（v2.1.94 の regression）
v2.1.97（2026-04-08 21:52）:

Focus view toggle: NO_FLICKER mode で Ctrl+O で focus view にできる。prompt、1 行 tool 要約（diffstat 付き）、最終 response だけに畳む

Status line 拡張: refreshInterval で N 秒ごとに status line コマンド再実行。workspace.git_worktree を JSON input に追加

● N running 指標が /agents で live subagent 数を見せる
Cedar policy file（.cedar / .cedarpolicy）のシンタックスハイライト

--dangerously-skip-permissions が protected path への write 承認後に accept-edits mode へ silent 降格されとった重大 fix
Bash tool permission の env-var prefix / network redirect 系の強化（後で v2.1.98 でさらに強化される）
MCP HTTP/SSE 接続で ~50MB/hr 漏れとった buffer leak fix

 おっちゃんの見立てv2.1.97 で一番効くのは地味やけど Cedar のシンタックスハイライト や。Amazon の permission 言語で、enterprise の認可設計でボチボチ採用が進みはじめとる。Claude Code 側が最初に色付けたっちゅうことは、「Cedar で policy 書いて Claude に食わせる」フローを前提にしとるっちゅうことや。後述の Cowork Enterprise の per-tool connector 制御と繋がっとる気配がする。
Ctrl+O focus view は、長い conversation を動画撮影するときに重宝する。うちの yokoi-ai-zenn のスクリーンショット撮影でもここから使うで。

 ③ Cowork for Enterprise — 2026-04-09 / 「導入される側の準備」が揃った

 何が起きたか2026-04-09、Anthropic が Claude Cowork の enterprise 機能群を一気に GA にした。一次ソース: Making Claude Cowork ready for enterprise — claude.com/blog。
「機能群」と言うのは文字通りで、6 つの柱がいっぺんに追加されとる。どれも、個人が遊ぶ Cowork から 会社が全社配布する Cowork への移行に必要な管理棚や。

 仕様の詳細① Role-based access control
手動 or SCIM（identity provider 連携）でユーザをグループ化
グループごとに custom role を定義し、capability を絞れる
つまり「設計チームは MCP read のみ / 実装チームは write 可」といった細分化ができる
② Group spend limits
admin console から team 単位で予算上限を設定
運用中に動的に上げ下げできる
これが無いと Routines の暴走で月末に冷や汗かく未来が確定するので、同日に出たのは意図的
③ Usage analytics
管理ダッシュボードに session 数 / active user 数が日付範囲で表示される

Analytics API: per-user activity / skill・connector 呼出 / DAU・WAU・MAU を取れる
Team と Enterprise プランのみ
④ OpenTelemetry 拡張
tool call、file 操作、skill 使用、manual vs automatic approval の event が流れる
Splunk、Cribl 等の SIEM パイプラインへ直接流せる
監査ログが「Claude が何を触ったか」を event 単位で追えるようになる
⑤ Per-tool connector controls
MCP connector の action 単位で org-wide に許可/禁止
例: 「Slack は read 許可、write 禁止」を組織設定で強制
個別 user の connector 設定を override できる
⑥ Zoom MCP connector
meeting summary / action items / 文字起こし / smart recording を Cowork workflow に直流し
「会議 → action item → Linear issue」が 1 session で完結する
デスクトップアプリは macOS と Windows 両対応で、claude.com/download から。OpenTelemetry と Analytics API は Team・Enterprise のみ。価格は既存プラン構造のまま、追加課金なし。

 なぜ今このタイミングで出たかRoutines と同じ週に出とる所がミソや。Routines は「autonomous で承認プロンプトが出えへん」仕組みで、入れると組織の監査担当者は真っ青になる。そこに先回りして RBAC・spend・OTel・per-tool control を並べとるんや。つまり「Routines を organisation で安全に使うための器」を同時に配っとる。これは Anthropic のローンチ計画として相当きれいな順序や。

 実務での使いどころ実務で言うたら、次の組合せが即戦力や:

OTel → 既存 SIEM: 既に Splunk 入れとる会社なら、approval が automatic やった run を後から全部追える

per-tool control で Slack write を全社禁止 → Linear だけ read/write: これで Routines の誤爆範囲を物理的に制約できる

group spend limit で実験用チームの上限を低めに: $0.08/session-hour の Managed Agents と併用するならここは必須

 既存機能との差分これまでの Cowork は「個人ユーザが連携 tool を追加して使う」道具やった。企業が全社配布する時に必要な 3 点セット——認可、予算、監査——が欠けとった。今回でその 3 点が揃ったから、セキュリティ部門が「じゃあ入れてええよ」と言える前提条件がクリアされた、ちゅう状態や。

 落とし穴・リスク
OTel は Team 以上のみ: Pro では使えへん。個人〜小規模チームは SIEM 連携の旨みを受け取れん

SCIM は identity provider 側の対応が前提: Okta や Entra ID 使っとる会社はすぐやけど、legacy の AD 運用のままやと追加設計がいる

Zoom MCP の書き込み: Zoom の recording にどこまで access するかは organization によって違う。per-tool control で write を切る設計が先にいる

既存の connector を後から絞る運用: 一旦全員に配って後から絞ると現場が怒る。最初から絞って配る設計の方がええ

 おっちゃんの見立てこれはな、content-marketing の観点から見ても重要な発表や。「Claude はもう組織に入れてええ段階に来た」というメッセージを、Anthropic がリリースノートやなくて blog で大々的に出しとる。つまり営業と情シスに向けた弾や。
小さい組織やったら RBAC は overkill やけど、per-tool connector control は即欲しい人は多いはずや。Routines 入れる時に Slack の write を全社禁止できたら、おっちゃん基準で合格や。

 ④ Advisor strategy — 2026-04-09 / Opus を相談役にする 1 line の API 変更

 何が起きたか2026-04-09 の blog The advisor strategy: Give agents an intelligence boost — claude.com/blog で、Anthropic が advisor tool を Claude Platform に導入した。これは pattern 紹介やなくて 実機能のリリース や。

 仕様の詳細
declare: Messages API で advisor_20260301 を宣言する 1 line の変更で使える

分担:

Executor（Sonnet or Haiku）: end-to-end で tool を呼んで iterate

Advisor（Opus）: executor が詰まった時に escalate され、plan / correction / stop signal のどれかを返す


handoff: 1 API リクエスト内で完結。追加の round-trip は発生せん

課金: executor token は安いモデルのレート、advisor token は Opus レートで 別計上
これ、めっちゃ実務的な機能やで。一番の狙いは「Opus 単体と同じ品質を、Sonnet 単体の値段に近い形で届ける」っちゅうこと。

 なぜ今このタイミングで出たかOpus と Sonnet のギャップが効いてきたフェーズやからや。単純なタスクなら Sonnet で足りる。でも critical な所で Opus に頼みたい。これまでは「全部 Opus にする」か「自前で executor/advisor ルータを書く」の 2 択やった。前者は高い、後者は面倒くさい。
Anthropic は「それ、API レベルで 1 line で済むようにするで」と出してきた。これは autonomous agent の経済性 を改善する話で、Routines と完全にセットや。Routines が autonomous で走ると、1 日何回も Opus 代払うのはバカらしい。でも Sonnet だけやと肝心な所で詰まる。そこに advisor を噛ませる、と。

 実務での使いどころ・コード例擬似コードはこんな感じになる（Messages API の設計想定）:
response = client.messages.create(
    model="claude-sonnet-4-6",
    tools=[{"type": "advisor_20260301", "model": "claude-opus-4-6"}],
    messages=[...]
)
executor が困った時だけ advisor へ escalate される。呼出元は気にせんでええ。ログには executor token 数と advisor token 数が別に載る。
使いどころ:

バグ修正 routine: 小さい修正は Sonnet、設計が絡む所で Opus に助言を仰ぐ

PR レビュー: 普通のスタイル指摘は Sonnet、アーキ変更を伴う PR だけ Opus

顧客サポート agent: 通常の Q&A は Haiku、escalation が必要な問い合わせだけ Opus

日次の品質監査 routine: 複数プロジェクト巡回は Sonnet、最終判断だけ Opus に advise させる

 既存機能との差分
model routing（自前）: 実装が面倒。prompt 分岐や history の重複送信で死ねる

Opus 単体: 高い。大半のやり取りに対して過剰品質

Sonnet 単体: 肝心な所で判断ミス

advisor tool: 1 line。コストは executor 主体で、必要時だけ Opus 差し込み

 落とし穴・リスク
billing の可視化を混乱させる: 1 request に 2 モデルの課金が入る。既存の課金モニタリングが model 単位でタグ付けしとると集計が崩れる

escalation ポリシー: 何をもって「詰まった」と判断するかは executor 次第。ここが頻発すると結局全部 Opus に聞いとる状態になりかねん

latency: escalate 発生時は 1 turn に 2 モデル分の時間がかかる。対話 UI では体感が遅くなる可能性

 おっちゃんの見立てこれ、地味やけど今週で 一番経済性に効く発明 やと思っとる。Routines で autonomous 運用を拡大する時の「高すぎる」問題への回答や。
使うなら、advisor が呼ばれた回数と advisor token の合計を必ずダッシュボードで見ること。割合が 30% 超えたら executor の prompt が悪いか、executor モデルの選定が間違っとる。ここを自動でアラート出す設計にしとくとええ。

 ⑤ v2.1.98 — 2026-04-09 / Monitor tool が本丸

 何が起きたか2026-04-09 19:18 にリリースされた v2.1.98 は、今週の CLI 本体リリースのなかで 一番新機能ぶんがデカい やつや。中でも Monitor tool の追加が本丸。
一次ソース: v2.1.98 changelog と Monitor tool reference、week 15 digest。

 仕様の詳細（Monitor tool 中心）
Monitor tool: 背景で watcher プロセスを spawn して、event を conversation に 新しい transcript message として流し込む
Claude はそれに対して 即座に 反応できる
典型用例: training run の tail、PR の CI babysitting、dev server の crash auto-fix

/loop の self-pacing: /loop は interval を省くと Claude がタスクに基づいて次の tick をスケジュール。あるいは Monitor tool に置き換えて polling そのものを不要にする

/proactive は v2.1.105 で /loop の alias になる（後述）

 v2.1.98 のその他（軽めの目玉）
Google Vertex AI の interactive setup wizard: login 画面から "3rd-party platform" 選択で GCP 認証・project・region・credential 確認・model pinning まで案内

CLAUDE_CODE_PERFORCE_MODE: Edit/Write/NotebookEdit が read-only file に対して silent overwrite やめて p4 edit のヒントを出す

Subprocess sandboxing 強化: Linux で CLAUDE_CODE_SUBPROCESS_ENV_SCRUB 設定時に PID namespace 分離、CLAUDE_CODE_SCRIPT_CAPS で session あたりの script 呼出数制限

--exclude-dynamic-system-prompt-sections: print mode で cross-user の prompt cache 効率改善

W3C TRACEPARENT env var を Bash subprocess に伝搬（OTEL 対応）

重大 security fix: backslash-escaped flag が read-only 扱いで通っとったのを修正。compound Bash コマンドが forced permission prompt を回避しとった問題も修正

/agents が tabbed layout になり、Running tab で live subagent を表示

 なぜ今このタイミングで出たかMonitor tool は Routines と 5 日ずれで出とる。これは偶然やなくて、長時間走る session に「背景 watcher」が必要になる からや。Routines がクラウドで 1 時間走る routine を回すようになると、polling ループで 1 turn 専有するのは致命的に不経済。そこで Monitor tool が必要になった、と。

 実務での使いどころ> Tail server.log in the background and tell me the moment a 5xx shows up
これだけ。以後 Claude は別のタスクに返答しながら、5xx が出た瞬間に event message として気づく。Bash の while sleep ループと違って、turn を占有せん。
使いどころ:

デプロイ検証: デプロイ後 10 分間 error 率を監視し、閾値を超えたら Claude が自動 rollback の提案

long test の監視: 1 時間かかる E2E test を流しつつ、手元では別 task を進める

file watcher: inotify 相当のことを Claude の conversation にそのまま流せる

 既存機能との差分
Bash sleep loop: turn 占有、反応遅延、Claude は polling 中 idle

cron + 通知: Claude が介在できる余地なし

Monitor tool: event driven、即時反応、他 task と並行

 落とし穴・リスク
長時間 watcher の暴発: 背景で動き続けるもんやから、session を閉じる時に自動 teardown できとるかは要検証

event flood: 流量が多い log を監視すると transcript が爆発する。filter 前提

sandbox の穴: v2.1.98 で修正された「compound Bash で permission 迂回」は過去分まで遡ると複数 version に跨がる。古い version で Monitor を使う時は要注意

 おっちゃんの見立てMonitor tool はな、「Claude Code が react して動く対象」を conversation から 外界の event に広げたっちゅうことや。これまで Claude は「ユーザが打ったメッセージ」と「tool の返り値」にしか反応できんかった。ここに「log file の新しい行」「CI の status 変化」が入った。つまり Claude が リアクティブなシステムの一部になる ための tool や。Routines と組み合わせた時に本領発揮する。

 ⑥ Seeing like an agent — 2026-04-10 / tool は増やすより減らす

 何が起きたか2026-04-10 に Seeing like an agent: how we design tools in Claude Code — claude.com/blog が公開された。これは feature launch やなくて Anthropic の中の人が書いた 設計論エッセイ や。でも中で触れとる tool は実機能やから、設計の話と合わせて拾う。

 語られた事実
AskUserQuestion tool が導入された: 以前は plan mode で質問したい時、ExitPlanTool のパラメータに質問を埋め込んだり、markdown 出力に頼ったりしとったが、2 回失敗した末に 専用 tool で modal UI を出す 方式に落ち着いた

Task tool が TodoWrite を置き換えた: 以前の TodoWrite は常時 todo を reminder として注入しとった。model が賢くなってくるとこの reminder が邪魔になり、agent 同士の coordination / dependency tracking / shared state を持つ Task tool に進化

Claude Code Guide subagent: ドキュメント質問用に新 tool を足すかわりに、progressive disclosure を採用し、専用 subagent に委譲することで main agent の context をクリーンに保つ

Claude Code の tool 数は ≒ 20 で横ばい: 追加より削除と統合を優先する

 なぜ今このタイミングで出たかこれは Managed Agents と Routines を触りはじめた開発者への 間接メッセージ や。「agent を作る時、tool を足しすぎるな。減らせ。置換えろ」ちゅう設計原則を、Anthropic 自身の内側の例で示しとる。Agent SDK 使う人にとって、公式の設計観が公開されたのはデカい。

 実務での使いどころ読んで即使える話やないけど、役職ごとにスキル（tool）を増やし続けとる組織には刺さる:
新しい skill を追加する前に、既存のどれかを進化させられへんか を先に考える
todo の常時 reminder より、task ごとの subagent 委譲 の方が大きな model では綺麗に動く
agent を外向けにする時は tool の listing cap も意識（v2.1.105 で 250 → 1,536 文字に拡張されたのはこの流れ）

 既存との差分Anthropic の内製事例が 外に出る頻度 が上がっとる。これまでは docs に書かれる程度やったが、最近は engineering blog がほぼ weekly。内側の意思決定プロセスが透明化されとるのは、採用面でも競合（Cursor、Windsurf）に対する差別化要因や。

 おっちゃんの見立てMaster Skill 一覧（frontend-master、svg-master、css-master、…）が増えすぎとるチームは、「今度 skill を追加したら古いの 1 本消せ」ルールを入れるタイミングかもしれん。記事は読んだ方がええ、全員。

 ⑦ Multi-agent coordination patterns — 2026-04-10 / 5 パターンの使い分け
 何が起きたか同じ 2026-04-10 に Multi-agent coordination patterns — claude.com/blog が公開された。こちらは完全に pattern essay で、新機能の発表は伴っとらん。でも週の総集編として外せんので触れる。

 内容5 つの multi-agent coordination パターンと、それぞれの使い所:

Generator-verifier: 片方が生成、片方が検証

Orchestrator-subagent: 親が分解・委譲、子が実行（Claude Code 自身の構造）

Agent teams: 同格複数の協働

Message bus: 疎結合の pub/sub

Shared-state coordination: 共有状態を介した同期
Anthropic の推奨は「最も単純なパターンから始めて、詰まったら次に進化させろ」。

 既存との差分これまで multi-agent は学術的な話が多くて、production の指針は薄かった。Anthropic が自分のところの Claude Code を orchestrator-subagent として参照しながら書いとるのが価値や。

 おっちゃんの見立て役職分担で subagent を指揮命令系統に並べた構成は、orchestrator-subagent に agent teams を被せた変形 やと見立てられる。こういう構成を組んどるチームは、次の /retro でこの分類を使って内部構造を見直すとええかもしれん。

 ⑧ Preparing your security program for AI-accelerated offense — 2026-04-10 / 攻撃側の加速
 何が起きたか同じく 2026-04-10 に Preparing your security program for AI-accelerated offense — claude.com/blog が出とる。これは先週の Project Glasswing（セキュリティ特化の Mythos モデルの限定配備）に続く 守る側の指針 や。

 内容の要点攻撃者が AI を使いこなす前提で security program を再設計しろ
「AI による偵察 → AI による exploit 生成 → AI による lateral movement」の流れに対する防御
守る側も AI を組み込むこと。具体的には SIEM の alert triage、脆弱性の先読み、patch の優先付け

 今週的な意味Cowork Enterprise の OTel 拡張と真横にある。OTel で event を全部出す → SIEM で AI triage、が想定されとる構図や。

 おっちゃんの見立てsecurity 系の skill を組んどるチームは、方針文書を更新するタイミング。あと、Claude 自体が attacker に操作された時の脅威モデル（prompt injection + tool use による lateral movement）は、セキュリティと品質保証の共同 agenda に上げるべき話や。

 ⑨ Ultraplan — Week 15 research preview / plan モードをクラウドで書かせる

 何が起きたかUltraplan は Week 15（2026-04-06〜10）の目玉 feature として code.claude.com/docs/en/whats-new/2026-w15 で正式扱いされとる。v2.1.101（2026-04-10）で default cloud environment の自動生成 が加わり、web setup なしで初回から使える状態になった。

 仕様の詳細CLI で /ultraplan <目的> と打つと、Claude Code on the web 側で plan が draft される
あんたの terminal は 即座に解放 される（待たんでええ）
browser で plan を見て、section ごとに comment / revise 依頼 ができる
完成後、「remote で execute」するか「CLI に送り返す」かを選べる
v2.1.101 以降: 初回は default env を自動作成するので、事前の web setup が不要

 なぜ今このタイミングで出たかここも Routines と接続しとる。plan 作成だけクラウドに投げて、実装は手元で回すという分業パターンが、Claude Code を「ターミナルの相棒」から「クラウドの同僚」に変える大きな一歩や。Routines の full cloud session に対して、Ultraplan は 半 cloud の立ち位置で橋渡しになっとる。

 実務での使いどころ> /ultraplan migrate the auth service from sessions to JWTs
これで:
CLI は即解放（別 task 続行可能）
browser で plan が draft されとるのを見る
section 3 に「secret rotation の頻度は？」とコメント
返事が来たら「execute remotely」か「send back to CLI」か選ぶ

 既存との差分
plan mode（CLI のみ）: turn を占有、plan 策定中は他作業できず

Claude Code on the web（全部 cloud）: 実装までクラウド

Ultraplan: plan だけクラウド、実装は選択可能

 落とし穴・リスク
research preview: 仕様は動く

browser タブを開きっぱなしにする運用: セキュリティ上のルール次第では ブラウザ + CLI の併用が制限されとる会社がある

 おっちゃんの見立て設計と実装の分離は、現場の実情に近い。設計は時間かかって頭使う、実装は流れ作業で早い——この 2 つを同じ CLI の同じ turn で回すのは元々しんどかった。Ultraplan は そのしんどさをインフラで分離 した解や。

 ⑩ /autofix-pr — Week 15 / CLI から PR auto-fix を ON にする
 何が起きたかPR 自動修正機能は Week 13 に web 側で先行ローンチされとった。Week 15 で CLI から 1 コマンドで有効化できる ようになった。

 仕様の詳細現在の branch の open PR を自動推定

/autofix-pr 実行で Claude Code on the web 側で auto-fix が enable
CI 結果と review comment を Claude が見て、green になるまで push を繰り返す
途中で walk away してええ

 実務での使いどころ$ git push origin feature/jwt-migration
$ claude
> /autofix-pr
以後、散歩に出ても Claude が修正 push を続ける。帰ってきたら green か、green にできん所で止まっとる。

 落とし穴・リスク
レビュアーの役割が変わる: 機械的な fix が自動化されるんで、人間レビュアーの焦点が「設計・影響範囲」に寄る。役割の再教育が要る

loop の暴走: 修正と失敗を延々繰り返す pattern を避けるガードが必要

 おっちゃんの見立てこれ、うちの /daily-improve と真正面からかぶる。/daily-improve は 3 projects + ai-nazo を朝巡回するけど、/autofix-pr は PR 単位で常駐する。使い分けは「主体がどこにあるか」や。プロジェクト主体 → /daily-improve、PR 主体 → /autofix-pr。

 ⑪ /team-onboarding — v2.1.101 / あんたの Claude Code 運用をそのまま後輩に渡す
 何が起きたかv2.1.101 で /team-onboarding コマンドが追加された。自分のプロジェクトでの Claude Code の使い方から、teammate 用の ramp-up ガイドを生成する。

 仕様の詳細自分がよく使っとる project で実行
出力された guide を新メンバーに渡すと、defaults から始めずに あんたのセットアップを replay できる

 実務での使いどころランブックや運用ノウハウがあちこちに散らばっとるチームは、/team-onboarding をルートで回して、経験者の実運用を guide に落とす のは大いにアリや。

 おっちゃんの見立てこれはナレッジの属人化を解毒する公式の仕組みや。小さい変更やけど、中小企業や個人チームでの波及はデカい。

 ⑫ v2.1.101 のその他 — 2026-04-10 / OS CA trust とデフォルト cloud envv2.1.101 は /team-onboarding 以外にも重要変更がてんこ盛りや。

 仕様の詳細
OS CA certificate store を default trust: enterprise の TLS proxy が追加設定なしで動く。CLAUDE_CODE_CERT_STORE=bundled で従来の bundled CA のみに戻せる
/ultraplan が default cloud env を自動生成

brief mode retry: Claude が structured message ちゃうと 1 回 retry

rate-limit retry message の改善: どの limit に当たってどこで reset されるかが具体値で表示

Bedrock SigV4 fix: ANTHROPIC_AUTH_TOKEN 等が Authorization header を上書きしとった 403 を解消

permissions.deny vs PreToolUse hook: 以前は hook が deny を prompt に降格できとった。これを遮断

--setting-sources without user の history 削除 bug: 30 日より古い会話が勝手に消えとったのを fix

Grep tool の ripgrep 自己治癒: embedded rg のパスが VS Code 自動更新や macOS App Translocation で消えても、system rg にフォールバック

 おっちゃんの見立てEnterprise TLS proxy 対応は地味やけど、営業現場に効く やつや。これまで「proxy の CA 認証設定せな動かん」が POC で必ず詰まっとったのが解消された。営業入れる会社が増える。

 ⑬ v2.1.105 — 2026-04-13 / PreCompact hook と plugin の背景 monitor2026-04-13 21:53 リリースの v2.1.105 は、plugin エコシステム向けの大き目の拡張を含む。

 仕様の詳細
EnterWorktree tool に path パラメータ: 既存の worktree に切替できる

PreCompact hook: compaction を {"decision":"block"} や exit code 2 で ブロックできる ようになった

Plugin の背景 monitor: 先週出た Monitor tool の plugin 版。monitors manifest key で session 開始時 or skill 起動時に auto-arm
/proactive が /loop の alias に
API stream が 5 分 idle で abort → non-streaming 再試行

Skill description の上限: listing cap 250 → 1,536 文字
WebFetch が <style> と <script> を削除するように（content budget 節約）

 なぜ今このタイミングで出たかPreCompact hook は context 管理の自動化に人間が介入する穴を空けた 変更や。これまで compact は Claude 側の判断で勝手に走っとった。hook で block できるっちゅうことは、「今 compact されたら困る」状況（例: plan レビューの最中）を外部から止めれる。つまり Claude の自律性に対するブレーキが 1 個追加された、という話や。
Plugin monitors は、Monitor tool（v2.1.98）を plugin 作者が再利用できる形で exposing したもん。独自の skill 群を育てとる組織にとって、「skill 起動時に自動で file watcher が arm される」ことの実装コストが激減する。

 実務での使いどころ# plugin manifest の背景 monitor 例
monitors:
  - name: test-runner-watch
    start: on_skill_invoke
    command: pnpm vitest --watch
これで、自作 skill が呼ばれた瞬間にテストウォッチャーが走る。skill と観測の距離が 0 に近づく。

 おっちゃんの見立てPreCompact hook は、quality-gate や review-audit みたいな「途中で context を失うと致命的な skill」と組合せるべきや。Hook で compact を block しとく設計が要る。

 ⑭ Routines — 2026-04-14 / 本命。cron がセッションに化けたここから 2026-04-14 の 3 連発に入る。1 日 3 発は今週の density の主犯や。

 何が起きたか2026-04-14、Anthropic が Claude Code Routines を research preview として公開した。一次ソース: Introducing routines in Claude Code — claude.com/blog, Automate work with routines — code.claude.com/docs。
「prompt + repositories + connectors + environment」を 1 セットで保存し、scheduled / API / GitHub の 3 トリガで自動起動 する。実行場所は Anthropic 管理のクラウドインフラ。あんたの Mac は閉じててええ。

 仕様の詳細（公式ドキュメントから 1 次拾い）
対象プラン: Pro / Max / Team / Enterprise（Claude Code on the web が有効な組織）

作成経路: claude.ai/code/routines、CLI の /schedule、Desktop app の "New task → New remote task"

承認: "Routines run autonomously as full Claude Code cloud sessions: there is no permission-mode picker and no approval prompts during a run." ——承認プロンプトは 一切出ない

帰属: routine は個人アカウント紐付き。チーム共有不可。GitHub コミット、Slack 投稿、Linear チケット——全部あんたの名前で飛ぶ
Scheduled trigger
preset: hourly / daily / weekdays / weekly
custom cron: CLI の /schedule update で設定

最小間隔は 1 時間（サブ hour は拒否）
実行時刻は local zone で入力、内部で変換
stagger により数分ずれることあり
API trigger
各 routine ごとに専用 URL と bearer token が発行される
token は 生成時に 1 度だけ表示 され、後から取り出せん（regenerate / revoke 可）
endpoint は https://api.anthropic.com/v1/claude_code/routines/<routine_id>/fire
request body: {"text": "..."} optional。freeform text で、JSON を送っても文字列として渡る
curl -X POST https://api.anthropic.com/v1/claude_code/routines/trig_01ABCDEFGHJKLMNOPQRSTUVW/fire \
  -H "Authorization: Bearer sk-ant-oat01-xxxxx" \
  -H "anthropic-beta: experimental-cc-routine-2026-04-01" \
  -H "anthropic-version: 2023-06-01" \
  -H "Content-Type: application/json" \
  -d '{"text": "Sentry alert SEN-4521 fired in prod. Stack trace attached."}'
successful response:
{
  "type": "routine_fire",
  "claude_code_session_id": "session_01HJKLMNOPQRSTUVWXYZ",
  "claude_code_session_url": "https://claude.ai/code/session_01HJKLMNOPQRSTUVWXYZ"
}
beta header: experimental-cc-routine-2026-04-01。将来 breaking change は新 dated header で入り、2 つ前までは互換維持 される。
GitHub trigger
Claude GitHub App を repo に install する必要あり。/web-setup は clone 権限は取れるが webhook delivery は別
対応 event カテゴリは 17: pull request / pull request review / pull request review comment / push / release / issues / issue comment / sub issues / commit comment / discussion / discussion comment / check run / check suite / merge queue entry / workflow run / workflow job / workflow dispatch / repository dispatch

filter: author / title / body / base branch / head branch / labels / is draft / is merged / from fork

research preview 中は per-routine および per-account の hourly cap あり。超過は drop
Daily cap（research preview 時点）

Pro: 5 回 / 日

Max: 15 回 / 日

Team / Enterprise: 25 回 / 日
extra usage（metered overage）が有効な組織は超過を従量で継続可能
権限モデル — 3 層で輪郭を決める

Repositories: 触らせる repo を明示。default で Claude は claude/ prefix のブランチにしか push できん。main を守る最初のフェンス。「Allow unrestricted branch pushes」を明示 ON にしない限り破れん

Environment: network access / env vars / setup script を cloud environment で管理。API キーはここに入れる

Connectors: 接続済み MCP connector は デフォルトで全部入る。必要ないものは外す運用が鉄則

 なぜ今このタイミングで出たかこれは Claude Code の立ち位置を ターミナル相棒から クラウド同僚へ 移すための中心ピースや。Devin や Cowork、Cognition の autonomous agent 製品群が目指しとった領域に、Anthropic が真横からスライドしてきた構図。Cowork Enterprise の管理機能（4/09）、Managed Agents（4/08）、Advisor tool（4/09）、Desktop 再設計（4/14）、v2.1.108 の 1 時間 prompt cache（4/14）——全部 Routines を運用で成立させるためのピースや。「今週の 13 発」は、Routines を真ん中にして組まれた sortie や。

 実務での使いどころ官僚制の翻訳すると、次の型に嵌めるのが安全:

Backlog triage: 毎晩 Linear/GitHub Issues のラベル付けと担当割当

Docs drift: 週 1 で merged PR をスキャンして docs PR 起票

PR 自動レビュー: チーム checklist をコメント。approve はさせない

Deploy verification: CD パイプラインから POST で fire。Slack に結果のみ

Alert triage: Sentry → routine。draft PR までで停止

 既存の解との違い（cron / GitHub Actions / Zapier / Temporal）既存の schedule 実行と何が違うか。答えは「枯れた trigger 層に完全な Claude Code session を 1:1 でくっつけた」のが新しい所。cron はシェルを叩くだけやから、認証・repo clone・connector 接続・rate limit・fallback・ログ収集を全部自前で書く羽目になる。Routines はそこを全部畳んで、「trigger が来たら Claude Code の 1 session が起動する」という 1 ステップに圧縮した。
言うたら、cron は「タイマー」やったのが、Routines は「自動販売機」になったんや。タイマーで時間になったら、販売機の前に人が立って、ボタン押して、商品出してくれる。その人が Claude。

 落とし穴・リスク
autonomous で承認プロンプト無し: Repositories / Environment / Connectors の 3 層で事前に輪郭を決めとかん限り暴れる

個人アカウント紐付き: 監査上「誰がやったか」が Claude と あんたの区別がつかない。監査が厳しい会社はここで導入計画を練り直す必要

research preview: beta header 追跡責任を誰かに持たせなあかん

daily cap の「少なく見える」罠: 「Pro で 5 回」は回数やなくて 型の本数。PR レビュー / バグ triage / docs drift / deploy verification / alert triage で 5 個埋まる。それ以上は別の handle で

 おっちゃんの見立て触るならどの順番がええか。失敗しても人が死なん仕事から順に型を作る のが正解や:
バックログ triage（失敗しても直せる）
docs drift（草案 PR 止まりやから安全）
PR 自動レビュー（必ずコメント止まり、approve はさせへん）
deploy verification（rollback 権は与えん、Slack 通知のみ）
alert triage（draft PR までで停止、マージは人間）
逆に 初回から避けるべき パターン:

main への直 push を許可する routine
本番 DB を触る routine
「Allow unrestricted branch pushes」を常時 ON
全 connector そのまま入れた routine（特に Slack の chat.write）
autonomous で承認プロンプトが出えへん特性と、これらの組合せが最悪や。「このくらいやったら大丈夫やろ」が一番あかん時代に入った。

 ⑮ Desktop 再設計 — 2026-04-14 / 1 ウィンドウに parallel agents を住まわす

 何が起きたか同じ 2026-04-14、Claude Code Desktop が大規模再設計された。一次ソース: Redesigning Claude Code on desktop for parallel agents — claude.com/blog。
設計思想はタイトルに出とる——「parallel agents 前提の UI」や。Routines と同時に出た意味がここで分かる。

 仕様の詳細Session 管理
サイドバーで active / recent session を一元管理
status / project / environment で filter
project 単位で grouping
PR merged/closed の時に auto-archive
Workspace レイアウト

全パネルが drag-and-drop で入替可能

Integrated terminal: test / build を同じウィンドウ内で

In-app file editor: spot edit と保存

Rebuilt diff viewer: 大きい changeset でも速い

HTML / PDF preview、ローカル app server 対応
Multi-task workflow

Side chat (⌘+; / Ctrl+;): 主会話から分岐した質問。primary task を misdirect せずに 横道の質問ができる
複数 repo に跨がる parallel session 実行
View モード

Verbose / Normal / Summary の 3 モード
新 keyboard shortcut（⌘+/ で全一覧）

Usage button で context window と session metrics を表示
技術系
response streaming で信頼性と速度を再構築

CLI plugin parity: desktop でも CLI plugin が同じに動く

SSH サポートが macOS に拡張（以前は Linux のみ）
local session / cloud session の両方
対象プラン: Pro / Max / Team / Enterprise + Claude API アクセス。ダウンロードは claude.com/download、ドキュメントは docs.claude.com/claude-code。

 なぜ今このタイミングで出たかこれは Routines を使う人の UI や。routine を持つと session の数が爆発する（docs drift / PR review / deploy verify / alert triage / ...）。それらを 1 ウィンドウで横並べて管理する器が要る。サイドバーで filter、status で絞り込み、PR merge 時に auto-archive——全部 routine の run を前提にした設計や。
Side chat も重要や。primary task（例: auth refactor）を走らせとる最中に、「ちなみに JWT の secret rotation 推奨は？」と横で訊きたい時、これまでは主タスクの context を汚すか、別 terminal を開くかの 2 択やった。side chat はその 3 つ目の選択肢になる。

 実務での使いどころ複数プロジェクトを同時に動かしとる開発者で想定すると、こうなる:

左サイドバー: 各プロジェクトの active session（プロジェクトA / プロジェクトB / …）

メインペイン: 今のタスクの会話（summary view）

サイドペイン: 統合 terminal で test 実行

下ペイン: diff viewer で今触っとるファイル

side chat: 「ちなみにトーン定義どこに書いてあったっけ？」を裏で訊いて context 汚さん
つまり 「複数のコンテキストを同時に動かす実務の構造」と desktop の structure が初めて一致した んや。これは地味にデカい。

 既存との差分
v1 desktop: 1 session を 1 ウィンドウで見る。terminal / editor / diff は外部

redesigned desktop: N session + terminal + editor + diff + preview を 1 ウィンドウに内蔵
競合は VS Code + Continue / Cursor IDE やけど、Claude Code Desktop は session 管理を主役に据えた ところが独自。IDE ベースは「ファイル中心」、Claude Code Desktop は「session 中心」の哲学の違い。

 落とし穴・リスク
ウィンドウが重い: 多機能になれば冷蔵庫みたいになる。軽量な CLI 派はそのまま CLI

session が爆発: Routines と組み合わせると数十の routine run が並ぶ。auto-archive を信じて生きる必要あり

SSH の macOS 対応が新しい: まだ細かい edge case がある可能性

 おっちゃんの見立て今週、Claude Code の「住処」が 3 箇所 に広がったんや。ターミナル（CLI）、画面（Desktop）、クラウド（Routines / web）。Desktop 再設計は「画面」の拡張で、そこで parallel session を住まわせる前提の造りになっとる。

 ⑯ v2.1.107 / v2.1.108 — 2026-04-14 / /recap と 1 時間 prompt cache

 何が起きたか同じ 2026-04-14 に v2.1.107（06:11）と v2.1.108（19:12）が連続リリース。v2.1.107 は小さく「thinking hints を長い操作で早めに表示する」だけ。本題は v2.1.108 や。
一次ソース: v2.1.108 changelog。

 仕様の詳細（v2.1.108 の目玉）1 時間 prompt caching

ENABLE_PROMPT_CACHING_1H=1 で prompt cache の TTL を 5 分 → 1 時間に
対応: API key / Bedrock / Vertex / Foundry
逆に FORCE_PROMPT_CACHING_5M=1 で強制 5 分

ENABLE_PROMPT_CACHING_1H_BEDROCK は deprecated（互換維持）

DISABLE_TELEMETRY をセットしとるユーザが 5 分にフォールバックしとった bug も同時 fix
起動時に DISABLE_PROMPT_CACHING* 系が立っとったら warning
/recap と away summary
session に戻った時の context を自動生成する /recap コマンド

/config で on/off 切替、手動起動可能
telemetry off のユーザ向けに CLAUDE_CODE_ENABLE_AWAY_SUMMARY で強制 ON
「思い出す」コストが実質 0 turn になる
その他（細かいが効く）
Model が built-in slash command（/init, /review, /security-review）を Skill tool 経由で発見・起動できる

/undo が /rewind の alias に

/model がモデル切替時に警告（次の response がフルで再読されキャッシュ無効化のため）

/resume が現在 directory のセッションを default 表示、Ctrl+A で全 project
エラーメッセージ改善: server rate limit を plan usage limit と区別、5xx/529 に status.claude.com のリンク、unknown slash command は近い候補を提案
言語設定時に diacritical mark（アクセント等）が抜けとった fix

--teleport の terminal escape 残骸 fix

 なぜ今このタイミングで出たか1 時間 prompt cache は Routines + advisor tool との combo で効く やつや。Routines が毎時 fire すると、同じ prefix（システムプロンプト、repo context）を何度も送ることになる。5 分 TTL やと routine 間隔の方が長いので cache hit せん。1 時間 TTL に延ばしたら 毎時 routine の prefix は普通に hit する。コストが目に見えて下がる。これは Routines ローンチのためのコスト最適化や。
/recap も同じ文脈。Routines で session 数が爆発する → session に戻った時に「前回どこまでやった？」のコストがバカにならん → /recap で Claude 側が自動で思い出す。Desktop 再設計の session 管理との相性もバッチリ。

 実務での使いどころexport ENABLE_PROMPT_CACHING_1H=1
claude
これだけで TTL が延びる。Routines を organization で運用するならこれを default にしとけ。
/recap は Desktop app の verbose mode と組むと特に効く。session archive から戻って Ctrl+O → /recap の流れが新しい「復帰動作」になる。

 既存との差分
5 分 TTL（従来）: 対話的 session には十分、routine には不十分

1 時間 TTL（新）: routine / 長期 session 向き

/recap: session 再開のナレッジ継承コストを 0 に

 落とし穴・リスク
1 時間 TTL はストレージ効率が下がる: Anthropic 側のコストが増えるので、恐らく最終的な cache 戦略は opt-in で残る。強制はされへん

/recap の精度: まだ初版。複雑な session では要約が粗い可能性

 おっちゃんの見立てこれで Routines のコスト問題は半分解決や。残りの半分は Advisor tool（Opus escalation のレート制御）。この 3 つ—— Routines + 1h cache + advisor ——を合わせて運用すると、autonomous 運用のトークン経済 が初めて成立する。

 今週全体の見立て — 3 面攻めの意味
13 本を並べた後、見えてくる構造はこうや。
① 画面（Desktop / focus view / Cedar / view modes）

Claude Code が住める場所を terminal だけでなく画面にも広げた。parallel agents 前提の UI で、1 人が N 本の session を同時に管理する世界を既定にした。
② クラウド（Routines / Ultraplan / Managed Agents / autofix-pr / Monitor / 1h cache / /recap）

「あんたが寝とる間も Claude は走る」体制を全方向から組み立てた。cron の後継じゃなくて、cron の上に完全な Claude Code session を 1:1 で乗せる仕組み。Managed Agents で商品化、Routines で組織運用、Advisor tool で経済性、1h cache でコスト、/recap で再開コストを全部下げた。
③ 組織（Cowork Enterprise / team-onboarding / OS CA trust / Seeing like an agent / AI-accelerated offense）

企業が全社導入するための管理棚・監査証跡・営業障壁の解消。RBAC・spend・OTel・per-tool control——全部 Routines を organisation で安全に使うための前提条件や。ついでに設計論エッセイで「tool を減らせ」と内部知見を公開して、採用と信頼性の面でも攻めとる。
この 3 面が揃った週は過去にない。 Claude Code はもう「ターミナル相棒」の枠を完全に抜けた。

 どこに向かっとるかわしの読みはこうや。Anthropic は Claude Code を 「1 人の開発者が使う道具」から「会社が運用する業務システム」へ 段階的に変えとる。その最終形は、Cowork が全社配布される enterprise ソフト、Claude Code Desktop が CEO から現場まで使う画面、Routines / Managed Agents がインフラ、Claude Platform が API 層。この 4 レイヤーで、ERP じゃない新しい形の「業務 OS」を作ろうとしとるように見える。
競合はもう Cursor や Windsurf やなくて、ServiceNow や Zendesk やと思っといた方がええ。

 締め — 問cron で済んどった夜間バッチが、今日から「セッション」として立ち上がる。draft PR が勝手に立つ。Slack に要約が落ちる。朝のコーヒーの前に、Claude の昨日分の残業ログが残っとる。
ほんで、ふと気づく。あんたが Claude Code に勝っとる部分って、今、何や？
答えは 1 つあると思う。「どの routine を作るべきか決める所」 や。仕事の型を決めるのは、まだ人間の仕事や。そこだけは今週も譲られてへん。それで十分やろか。それとも、次に来週 Anthropic が持って行くのは、ここやろか。

 📎 編集後記 — おっちゃんの現場から実は、うちでも毎朝 /daily-improve で複数プロジェクトの品質監査を回しとる。今までは人間が朝イチに起動する運用やったんやけど、Routines と Advisor tool と 1h prompt cache の 3 点セットが揃ったら、クラウド側に投げたら、こっちがコーヒー飲む前に改善 PR が 3 本立っとる 世界に今週から移行できる。ただし、無承認実行と相性の悪い箇所もあるから、最初の型は docs drift 検出みたいな「失敗しても人が死なん仕事」から。そこで転ばんかったら次や。この記事自体、来週には routine が自動で吐いとる未来が、意外とすぐ来るかもしれん。
横井のAI日和 — AI の深堀りをお届け。
日付	機能	種別	一言
04-08	Claude Managed Agents	Platform public beta	自前 agent loop を全部畳む managed サービス。$0.08 / session-hour
04-08	v2.1.96 / 2.1.97	CLI リリース	focus view (Ctrl+O) / Cedar syntax / flicker-free 強化 / Bedrock 認証 fix
04-09	Cowork for Enterprise	管理機能 GA	RBAC / spend limits / OTel 拡張 / per-tool connector / Zoom MCP
04-09	Advisor strategy / advisor tool	Platform 機能	Opus を相談役にして Sonnet に実行させる。`advisor_20260301`
04-09	v2.1.98	CLI リリース	Monitor tool / Vertex AI 設定 wizard / Perforce mode / subprocess sandbox
04-10	Seeing like an agent	設計エッセイ	AskUserQuestion tool / Task tool / progressive disclosure の舞台裏
04-10	Multi-agent coordination patterns	設計エッセイ	5 パターンの使い分け指針
04-10	AI-accelerated offense	セキュリティ記事	攻撃者 AI 時代のセキュリティプログラム改訂指針
04-10	Ultraplan / /autofix-pr / /team-onboarding	CLI 機能群	plan をクラウドで起草 / PR auto-fix を CLI から / teammate ramp-up 出力
04-10	v2.1.101	CLI リリース	OS CA trust / default cloud env 自動化 / Bash permission 強化
04-13	v2.1.105	CLI リリース	PreCompact hook / plugin background monitors / /proactive alias
04-14	Routines	本命 / research preview	prompt + repo + connectors をクラウド routine 化。cron がセッションに化けた
04-14	Desktop 再設計	アプリ全面刷新	sidebar / multi-session / integrated terminal / side chat / 3 view mode
04-14	v2.1.107 / 2.1.108	CLI リリース	/recap / 1 時間 prompt cache / model 内から slash command 呼出
	Agent SDK	Managed Agents	Claude Code
インフラ管理	自分	Anthropic	Anthropic（CLI は手元）
カスタマイズ	最大	高	中
エンドユーザーに直接見せる	難	前提	非前提
課金モデル	token のみ	token + $0.08/session-hour	plan subscription
立ち上げ速度	遅	速	即