claude.devの公式記事4本 自動化・クラウド・mods・評価づくり

Anthropicの開発者向けブログclaude.devに、9月28日から10月8日にかけて載った、作る人向けの手引きから4本を紹介する。日付は2週間から3週間半前で、新しい発表ではない。ただ、どれもAnthropicの人が、手順と失敗の例まで付けて書いている。Claude CodeやCodexで道具を作る個人や小さなチームが、明日から使える決まりが多い（編集部の読み）。新しい順に紹介する。

定時の自動化の6つの決まり

10月8日のエージェントによる自動化の組み方は、Claude Managed Agents（ベータ）で作った見本を順に説明する。SlackのチャンネルとGitHubのプルリクエストを決まった時刻に読み、前回からの変化をSlackに1本の投稿で知らせるものだ。動くのはAnthropicの基盤の上なので、手元の機械を付けっぱなしにしなくてよい。

記事の中心は、自動化がよく失敗する所を潰す6つの決まりだ。読む範囲を「直近24時間」と決めず、前回どこまで読んだかの印から読む。読めなかった情報源は「新しいことは無い」とせず、読めなかったと書く。投稿の直前に、各項目の今の状態を確かめ直す。Slackが受け取ったと返して初めて送ったと数え、それから記録を進める。好みの設定は毎回読み直し、エージェントには書き換えさせない。読むだけの所は読む権限だけにし、1回に使える費用に上限を付ける。上限は、普段の1回の費用の3〜5倍から始めて詰めるよう勧めている。

Claude Codeで/claude-api managed-agents-onboardの後にこの記事のURLを渡すと、同じ構成を組む手伝いをしてくれるという（会社の申告）。

クラウドで動くClaude Code

10月6日のクラウドのセッションの手引きは、Claude Codeを自分のノートPCではなく、作業ごとに用意される新しい仮想マシンで動かす使い方を書く。リポジトリは新しいブランチに複製され、終わった作業はそのブランチに残るので、プルリクエストにできる。Pro、Max、Team、Enterpriseの契約に含まれ、機械の分の追加料金は無く、Claude Codeのほかの使い方と同じ利用枠を使う。

筆者は見本のリポジトリで、たまに落ちるテストの修正、古くなったAPIの説明書の書き直し、ログの形式の変更という3つの作業を、16秒のあいだに別々のセッションで始めた。3つとも、最初の開始から87秒後には終わったという（会社の申告）。ただし見本のリポジトリは架空の物で、各セッションは最初にリポジトリを作り直しており、それに実行時間の約3分の1から半分強を使っている。テストを直したセッションは、テスト全体を40回続けて流し、1回も落ちないことを確かめたという（会社の申告）。GitHubの鍵は仮想マシンの外の中継役が持ち、セッションには自分のブランチにだけ書ける短い期限の鍵が渡る。手元のデータベースやVPNの先、GPUが要る作業は、手元で動かすよう勧めている。データを残さない設定（ZDR）の組織では、クラウドのセッションは使えない。

modsで自分の道具を足す

10月1日のmodsの入門は、Claude Codeのセッションの中で動く小さなJavaScriptやTypeScriptのファイルを紹介する。セッションの出来事を見張り、Claude Codeの動きを変え、画面に独自の表示を描ける。中身はプラグインに入ったフックで、最初から有効で、Claude Code 2.1.287以降が要る。ただし、仕組みは版が変わると変わりうると断っている。

例は、コンテキストウィンドウがどれだけ埋まったかを天気の印で入力欄の上に出すToken Weatherで、80行ほどだ。rm -rfや強制push、データベースの移行の前に止めて、触れるファイルを一覧にするBlast Radiusもある。ただ記事は、これは安全網で権限の仕組みではなく、確実に止めたいなら権限のルールを使うよう書いている。配るのはプラグインと同じ方法で、GitHubのリポジトリがそのまま置き場になる。modsはClaude Codeと同じ権限で手元で動くので、信頼できる人の物だけを入れるよう注意している。

評価を作り1つずつ直す

9月28日の評価づくりと改善の自動化は、claude-apiのskillに入った/claude-api build-evalと/claude-api hillclimbの2つの命令を説明する。前者は聞き取りをしながらコードの中に評価を作り、採点の仕方を人に確かめさせる。後者は改善を1回に1つずつ試し、練習用と確かめ用に分けた例の両方で点が上がった時だけ残す。

例では、44件の問い合わせのうち30件で探し、14件を取っておいた。探索に使った30件では、Opus 4.8でeffortをhighにした設定の正しい判断が74.4%、1件4.6セントだった。プロンプトを見直し、Opus 5.5を経てSonnet 5でeffortをlowにした設定にモデルを段階的に下げた結果、88.9%、1件約1セントになった。さらにプロンプトに振り分けの決まりなどを足した最後の構成は、探索に使わなかった14件で90.5%となり、元の構成の78.6%を上回った。費用は約5分の1だったという（会社の申告）。

編集部の見方

4本に共通するのは、エージェントに任せる範囲を広げる時に、確かめる仕組みを先に作ることだ。投稿を確かめてから記録する、テストを40回流す、権限の広いmodsは中身を読んでから入れる、確かめ用の例で点が上がらなければ戻す。どれも小さなチームがすぐ真似できる（編集部の読み）。

日付は少し前だが、自動化やクラウドのセッションをこれから試すなら、最初に読む手引きとして今も十分に役に立つ。とくに、読めなかったことを「何も無かった」と報告させない決まりは、毎朝の要約を自動で作っている人なら今日から取り入れられる（編集部の読み）。