仕事中もプライベートでも、ご飯を食べながらでもトイレの中でもAIエージェントを触っている私が、Claude Code 2.1.283〜2.1.288（2026-09-25〜10-02）の変更13個に★を付けました。基準は、自分の作業がどれだけ良くなったか（なりそうか）です。

分かったこと

Claude Modsは一番深く拡張できますが、Claude Code専用です。管理サーバーとつなぐ設計をしたところ、Nodeが使えないことと、hookが10秒を超えると権限の判断が素通りになることが分かりました
claude --resume <id> "prompt"でbgセッションに指示を送れますが、端末のない呼び出し元や、権限モードが違うセッションからは届きませんでした
verifyスキルは、コミット前に検査を呼ばせるだけです。30ラン以上試した結果、今の私の運用ではなくても困らないと判断しました

評価

★	機能	一言	効く人
5	Claude Mods	使いどころは難しいが、外とやり取りできれば可能性が大きい	自作の管理ツールや監視とつなぎたい人
4	`claude --resume`	管理サーバーからの起動や送信が楽になりそう	bgセッションを外から操作したい人
4	Ctrl+Cのドラフト復元	誤って消しても戻せる（アップデートするだけで効く）	全員
3	`/doctor prompt-audit`	設定の古い記述が11件見つかったが、期待が高すぎた	CLAUDE.mdやスキルを長く育てている人
3	`claude plugin validate` / `eval`	自作の評価ランナーを置き換えられるか次第	プラグインを自作している人
3	Remote Controlのスリープ	スリープで止まらなくなった（アップデートするだけで効く）	MacでRemote Controlを使う人
3	モデル切り替えの修正	拡張思考が落ちなくなった（アップデートするだけで効く）	会話の中でモデルを切り替える人
3	インラインスクリプトの承認	承認の回数が減った（アップデートするだけで効く）	sandboxの自動許可を使っている人
2	verifyスキル	今後に期待。今は使わなくてもよさそう	Claudeにコミットまで任せている人
2	`claude plugin configure`	便利そうだが未試用	セットアップをスクリプトにしたい人
2	`/mcp reconnect all`	私の構成では出番が少ない	中継経由でMCPを複数使う人
2	You should know	有効にしたが、動いている様子がなかった	長いタスクを任せる人
1	`claude agents`の検索	管理サーバーがあるので使わない	自分の管理ツールを持っていない人

変更の一覧は、先行のまとめ記事（NaokiIshimura氏「Claude Code v2.1.284 - v2.1.288リリースノートまとめ」）にあります。この記事では、一つずつの説明は短くし、★の理由に字数を使います。

前提：私の使い方

★は、次の使い方を前提に付けています。

プラグインを自作しています（自分用のマーケットプレイスに9本あります）
bgセッションで、エージェントが別エージェントを操作する運用をしています
エージェントとタスクを一覧して操作するWebサーバーを自作しています（以下、管理サーバー）
コミット前のlintはgitのpre-commit（husky + lint-staged）で回しています
Claude、Gemini、Cursor、Codexを、どれも月3,000円前後のプランで併用しています。出力の多い作業は安いモデル、日本語の本文はGemini、レビューはCodexに回しています
試した環境はClaude Code 2.1.288、macOSです

★5〜4：運用が変わりそうなもの

Claude Mods（★5）: 管理サーバーとつなぐ設計をして、制約が2つ見つかった

2.1.287でClaude Modsが既定で有効になりました。プラグインからClaude Codeの内部の挙動に介入できる仕組みです。できることは、ターミナル画面への独自のパネルや帯の描画、ツール呼び出しへの介入と実行結果の書き換え、独自コマンドの追加、内部からのモデル呼び出しなどです。2.1.288では、ターミナルで選択中のテキストを取得する$.ui.selection()APIも追加されました。

hooksとの違いは動き方です。設定ファイルのhooksは、イベントのたびに外部のシェルコマンドを起動します。Modsは、Claude Codeのプロセスの中で関数として動きます。

Claude以外のエージェントも使っている私は、Modsを作業の中核には使いません。

理由は、拡張の手段ごとに、他のエージェントへ持ち運べるかどうかが違うからです。比較すると次のとおりです。

Skills:SKILL.mdはCodexやCursor、Geminiでも読める
MCP:各エージェントが対応している
hooks:エージェントごとに書き方が違い、移すのに手間がかかる
Mods:Claude Code専用

ここで言う中核は、どのエージェントで作業しても同じ結果になってほしい処理です。手順や検査、コミットの流れがそれに当たり、SkillsやMCPに書きます。Modsに向くのは、なくても作業が止まらない見やすさや操作性です。

具体例として、自作プラグインで設計中のものがあります。ModがセッションごとにUnix socketを1つ開き、そこへセッションやターン、ツールの開始と終了、権限の要求、contextの使用量といった出来事を書き出します。管理サーバーは、同じsocketからメッセージや割り込みを送ります。Mod自身は判断しません。異常の検知などの判断は、受け手の管理サーバーに置きます。こうしておけば、他のエージェントの出来事も同じ検知に流せます。

設計の途中で公式の型定義とドキュメントを読み、制約が2つ分かりました。

Modのコード（hooks module）はNodeのAPIも、自前のネットワークやファイルアクセスも持たない。上の設計のようにMod自身がUnix socketを開くことはできない。socketは外部のプロセスに持たせるか、$.http.fetchなどの用意された呼び出しを使って外とやり取りする
hook自身が使える時間は10秒で、超えるとhookは飛ばされ、保留していたツール呼び出しはそのまま実行される。$の呼び出しの中で待つ時間はこの10秒に数えない。権限の判断を管理サーバーに聞くなら、自前のPromiseではなく$の呼び出しの中で待たないと、許可したのと同じ結果になる

なお、実行中のセッションと外部をつなぐ手段はMods以外にもあります。claude-socket（https://github.com/cunicopia-dev/claude-socket ）は、ModsではなくMCPのchannelsを使ってWeb UIと実行中のセッションをつなぎ、メッセージの送信と権限の応答に対応しています。

正直なところ、Modsは思った以上に使いどころが難しいと感じています。それでも、socketを通して外とやり取りできれば可能性が大きいので、期待を込めて★5にしました。

claude --resume（★4）: bgセッションに届かない場面が3つあった

2.1.285で、実行中のbgセッションにclaude --resume <id> "prompt"でプロンプトを渡すと、そのセッションの次のターンとして送られるようになりました。以前は拒否されていました。

今の私は、追加の指示を親のセッションからSendMessageで送るか、claude attachで中に入って送っています。今はこれで足りています。それでも、管理サーバーからセッションを起動したり指示を送ったりするのが楽になりそうなので、★4にしました。

しかし、実際に使おうとして当たった壁が3つあります。

1つ目は、端末のない環境（標準入力に端末をつないでいない状態）から叩いた場合です。headless（--print）として解釈され、「--printと使うならセッションIDはUUIDかtitleで指定せよ」と返されて、実行中のセッションには届きませんでした。管理サーバーからサブプロセスとして呼ぶと、同じことが起き得ます。仮端末（pty）を与えれば通るかは、まだ確かめていません。

2つ目は、SendMessageで送り手と受け手の権限モードが違うと、受け手側で保留される問題です。bypassモードのセッションからautoのbgセッションへ送ったら保留され、承認する人がいないまま期限切れで届きませんでした。2.1.271から、保留されたことが送り手に通知されるようになっています。両方をautoにそろえたら届きました。

3つ目は、bgセッションに「コミットして」とだけ頼んだのに、pushまで進んだことがあった点です（bgでコミットした4本のうち1本）。bg用の指示に従ったものと見ていますが、確かめてはいません。bgに任せるときは、外に出る操作を依頼文で明示的に禁止するようにしました。

結論として、管理サーバーからの指示は、--resumeを使うより、前の節のModsの設計（管理サーバーからのメッセージや割り込みをModが受ける形）で受けることにしました。

★3：あると嬉しいもの

/doctor prompt-audit（★3）: 指摘16件のうち11件が古い設定だった

私は2026-09-26に、自分のObsidian vault（AIエージェントの設定ファイル群）で/doctor prompt-audit（2.1.283で追加）を実行しました。公式の説明では、CLAUDE.md・スキル・エージェント・コマンドを点検し、古いモデル向けに書かれたプロンプトのパターンを洗い出す機能です。古いパスやコマンド、矛盾する指示ファイルは、レポートの先頭に出るとされています。

実行すると、16件の指摘のうち11件は、設定の古い事実や矛盾といった現実とのずれでした。古いモデル向けの書き方は5件でした。

11件の設定のずれの例は次の3点です。

AGENTS.mdが「自律的に呼べ」と指示しているMCPツール名が実在しなかった
移動済みのディレクトリを参照していた
ルールファイルのYAMLの例がリスト記号を失って壊れていた（真似すると壊れたfrontmatterが増える）

古い書き方の修正より、日々の運用で設定がいつの間にか現実とずれていたのを見つけてくれたことが私には効きました。先行記事でsuwa_nobu氏も「価値は古い書き方の検出より環境のずれの検出」と結論付けられていますが、私は自分のAIエージェント設定ファイル群という別の環境から、まったく同じ結論に行き着きました。ただ、正直に言うと、期待が高すぎました。

claude plugin validate / eval（★3）: 自作の評価ランナーを置き換えられるか

私はすでに、自作のシェルスクリプトで全プラグインにclaude plugin validate --json --strictを回しています。CLIが異常終了して出力のJSONが空になったときに成功と見誤らないよう、終了コードも合わせて見ています。

評価の方は、自作の評価ランナーを使っています。スキルを入れない場合との比較と、スキルが呼ばれたかどうかの判定を持たせています。

claude plugin eval（2.1.269で追加。今回の範囲より少し前）は、プラグインの評価スイートをClaude Codeに対して実行し、スコア付きで再現可能な結果をJSONとHTMLのレポートで返します。これまでとの違いは、自作ランナーの保守を公式に寄せられるかどうかです。まだ試していないので今後に期待して★3にしました。

★2〜1：今は使わないもの

verifyスキル（★2）: 30ラン以上試して、今は使わなくてよいと判断した

先に結論を書くと、今の私の運用ではverifyがなくても困りません。実際の開発では、Claudeが自分で型チェックやテストを済ませてからコミットしていて、verifyは一度も呼ばれませんでした。ここからは、その判断に至るまでに試したことを書きます。

verifyはコミット前に検査を呼ばせるスイッチにすぎません。失敗したときに直すか止まるかは、verifyスキルの文面・周りの指示・起動方法の3つで決まります。

私は普段からコミット前の検査をpre-commit（husky+lint-staged）で回しています。そのため、最初は「pre-commitは止める門番、verifyはClaudeが自分で直す修復ループ」と使い分けられると思っていました。しかし、この見立ては半分外れました。

試験で一番意外だったのは、私の環境では、まったく同じverifyスキルでも起動方法で挙動が分かれたことです。バックグラウンド（bg）セッションで起動すると自分で直してコミットまで進み、headless起動だと止まって報告しました。

changelogには「プロジェクトかユーザーのスキルにverifyという名前のものがあれば、Claudeはコミットの直前にそれを実行するよう指示される。docsだけ・testsだけのコミットは除く」とあります。実体としては、Bashツールの説明のGitの節に次の1行が入るだけです。Claude Codeのバイナリの文字列でもこれを確認しました。

Always run /verify right before the commit command (never for docs or tests).

ここには、失敗したときにどうするかは書かれていません。先行記事でsuwa_nobu氏が「スキル名がverifyならコミット前に走る。トリガーは名前だけ」を30回の実測で確かめられています。私が知りたかったのはその先の2点（すでにgitのpre-commitがある環境にverifyを足すとどうなるか、verifyが失敗したらClaudeは自分で直すのか）でした。

私は2026-10-03に、Claude Code 2.1.288（モデルはOpus）を使い、個人開発のリポジトリで試験しました。リポジトリはFGO周回育成計画シミュレーター（Next.js+Vitest）です。このリポジトリのpre-commitは、ステージしたファイルのlint違反数が増えていないか（ラチェット）を見るだけで、型チェックとテストは走りません。

verifyスキルは、pnpm type-checkとpnpm vitest runを実行して失敗したら報告する素朴なものを用意しました（「失敗したら直せ」とは書かない）。そして別プロセスのClaudeに「この変更をコミットして」とだけ頼みました（verifyやテストには言及しない）。条件（素の環境／私の実環境、headless／bg）は表の列で示します。変更ケースとしては次の4つを用意しました。

ケースA:テストが失敗する変更
ケースB:lintのラチェットだけで止まる変更
ケースC:docsだけの変更
ケースD:機械的に直せる型エラー（リネーム漏れ）

環境	起動方法	verify の「失敗したら報告する」	ケース	verify が失敗したラン	自分で直してコミット
素の環境	headless	あり	A, D	4	0/4（すべて停止）
素の環境	headless	なし	A, D	3	0/3（すべて停止）
私の実環境	headless	あり	A, D	4	0/4（すべて停止）
私の実環境	headless	なし	D	3	3/3
私の実環境	bg	あり	D	2	2/2

素の環境では文面に関係なく止まりました。私の実環境では文面で分かれました。bgでは「失敗したら報告する」と書いた版でも直しました。コードを変えたランではverifyは28/28回呼ばれ、docsだけの変更では0/4回でした（Claudeは最初に「ドキュメントだけなので省く」と宣言しました）。

テストの書き換え、skip、--no-verifyによる回避、lintのベースライン更新といった不正な直し方は、30ラン以上で一度もありませんでした。実際の直し方は呼び出し元のリネームでした。

このリポジトリのpre-commitは型エラーを止めません。verifyがない条件では型エラー入りのコミットが1/2で通り、verifyがある条件では一度も通りませんでした。

しかし、実際の開発ではこの試験結果と食い違う観察が得られました。同じリポジトリの実際のissue（クラウド自動保存の重複発火の修正）を、verifyスキルを置いた状態でbgセッションに実装させました。すると、実装時のコミットとPR作成時の追いコミットの2回とも、verifyは呼ばれませんでした（0/2）。その2回とも、Claudeはコミットの前に自分で型チェック、テスト、eslint、lintラチェットを走らせていました。

この原因は特定していません。起動方法の違い（bg）と作業の中身（実装+テスト追加）は追加試験で否定されました（どちらでもverifyは呼ばれました）。残る候補は「verifyの中身（型チェックとテスト）を全部自分で済ませていたので重複とみなした」ですが、未検証です。

**止めたいもの（lintなど）はpre-commitに置き、Claudeにコミット前に思い出させたい検査（型・テスト）はverifyに置きます。**pre-commitはgitの仕組みなので、CodexでもGeminiでも効きます。verifyはClaude Codeだけで効きます。失敗したときに直させたいか止めたいかは、verifyの文面か起動方法で選びます。私のリポジトリで型エラーを止めたのはverifyだけでした。今後のアップデートに期待しています。

claude plugin configure（★2）: 設定を対話画面なしで入れられる

2.1.285でclaude plugin configure <plugin>が追加されました。プラグインが要求する設定項目の一覧と、そのうち未設定の項目が表示されます。--values-stdinを付けると、対話プロンプトを開かずに標準入力から設定値を保存できます。claude plugin install --configも<server>.<key>=<value>の形式に対応し、プラグイン同梱の.mcpb形式のMCPサーバーの初期設定値を、インストール時に引数で渡せます。

これまでは、/pluginの画面からConfigureを開いて設定していました。手作業が減らせそうで、新しいマシンのセットアップをスクリプトにできそうだと見ています。まだ試していないので★2にしました。

/mcp reconnect all（★2）: 中継経由でMCPを複数使う人向け

/mcp reconnect all（2.1.284）は、接続に失敗したか認証待ちのMCPサーバーを、まとめて再試行します。対象は失敗や認証待ちのものだけで、全サーバーではありません。リモートのMCPは切れても最大5回まで自動で再接続を試み、それでも失敗するとfailedになります。効きそうなのは、gatewayなどの中継側を通して複数のMCPを使っていて、中継側が長く落ちたときに配下がまとめてfailedになる場面だと見ています（私自身はこの構成で試していません）。

You should know（★2）: 有効にしたが、動いている様子がなかった

2.1.287で入った組み込みのmodです。サイドエージェントが作業を見守り、私やClaudeが見落としそうなことを、入力欄の上にノートとして出します。既定では無効で、/plugin enable cc-plugin-you-should-know@builtinで有効にします。

有効にしてみましたが、ノートが出るなど動いている様子はありませんでした。プラグインを読み込み直していなかっただけかもしれず、原因はまだ確かめていません。サイドエージェントがどのモデルで動き、利用枠をどれだけ使うかも、公開情報には書かれていません。

claude agentsの検索（★1）: 管理サーバーがあるので使っていない

claude agentsの画面に、2.1.287でセッション名とタスクを絞り込むn:<text>フィルタが、2.1.288でセッション名を探すCtrl+Fと、グループ間を移動するAlt+↑/↓が入りました。どちらもEnterで、最もよく一致するセッションを開きます。キー割り当ては変えられます。

私は管理サーバーを自作しているので、この画面はあまり使っていません。たまに開くと使い方が分からず困っていたので、検索できるなら使うかもしれません。★1にしました。

アップデートするだけで効くもの

Ctrl+Cで消したドラフトの復元（2.1.288）★4:入力中にCtrl+Cで消してしまったプロンプトを、空の入力欄で↑を押すと、貼り付けた長文や画像ごと戻せます。たまに間違えて消してしまうので、ありがたい機能です。
Remote Controlのスリープ（2.1.287）★3:スリープしたまま止まっていることが、たびたびありました。claude remote-controlで始めたセッションが、Macのアイドルスリープでターンの途中で止まる問題が直りました。
Opus 5.5とSonnet 5.5の切り替え（2.1.287）★3:/modelやopusplanで切り替えると、それまでの拡張思考が落ちることがある不具合が直りました。私は1つの会話の中でモデルを切り替えることは少ないのですが、覚えておくと得な修正です。
インラインスクリプトの承認（2.1.285、2.1.288）★3:sandboxの自動許可で、python3 -cやnode -eが=を含むだけで毎回承認を求めていた問題が2.1.285で直りました。2.1.288では、python3 <<EOFのような引用符なしのheredocで、本文がただのテキストと単純な$VARだけのときに承認を求める問題が直りました。どちらも条件付きの修正で、全部の場合ではありません。手作業での承認が減るため、ありがたい改善です。

おわりに

13個のうち、私の運用を一番変えそうなのはModsでした。ただしClaude Code専用なので、どのエージェントで作業しても同じ結果になってほしい処理はSkillsやMCPに置き、Modsは管理サーバーへ出来事を出す口に留めるつもりです。verifyとpre-commitの関係も同じで、どのエージェントでも効くpre-commitを土台にして、Claude Code専用の機能はその上に重ねる形が、複数のエージェントを使う私には合っていました。