Ch.2 2026年1〜3月の新機能 ── CLI からプラットフォームへ

2026/04/26

Ch.2 2026年1〜3月の新機能 ── CLI からプラットフォームへ

2026年に入ってから、Claude Code のリリースノートは別のツールかと思うほど密度が増した。単機能の追加ではなく、「どこでも、長時間でも、安全に動き続けるエージェント」というビジョンを実現するためのピースが、3ヶ月の間に次々と揃えられた。

本章ではその主要な6つの機能を、リリース時期とともに丁寧に解説する。コードが動く場面では実際のコマンドを示し、概念が複雑な場面では図で補う。

timeline
    title 2026年 Claude Code 主要機能リリースタイムライン
    section 1月
        Auto Mode（自動許可モード）: Zero-Trust / Relaxed / Auto の3段階
        Voice Mode（音声入力）: /voice コマンド・Push-to-Talk
    section 2月
        /loop スケジュールタスク: 自然言語でのバックグラウンド定期実行
        Computer Use（デスクトップ操作）: GUI・ブラウザ操作の統合
        Remote Control（遠隔操作）: モバイルからデスクトップを制御
    section 3月
        MCP Lazy Loading（遅延ロード）: MCPエリシテーションサポート

1. Auto Mode ── 「許可待ち」からの解放

なぜこの機能が生まれたか

Claude Code を使っていると、しばらくするとターミナルが止まっていることに気づく。ファイルを削除してよいですか？[Y/n] のような確認プロンプトで待機しているのだ。30分の複雑なリファクタリングを任せたつもりが、最初の3分で停止している──この体験は、長時間タスクにおける最大の摩擦だった。

2026年1月にリリースされた Auto Mode は、この問題を「AIによるリスク判定」で解決する。

3段階の許可モード

Claude Code には現在、以下の3段階の許可モードがある。

モード	動作	適したシーン
Zero-Trust	すべてのツール呼び出しに人間の確認が必要	本番環境・高リスク操作
Relaxed	読み取り操作は自動実行、書き込み・削除は確認	通常の開発作業
Auto	AIクラシファイアがリスクを評価し、低リスクは自動実行	長時間・バッチタスク

settings.json での設定例：

{
  "permissions": {
    "mode": "auto",
    "autoApproveThreshold": 0.85,
    "alwaysAsk": ["rm -rf", "git push --force", "DROP TABLE"]
  }
}

autoApproveThreshold は0〜1の値で、クラシファイアの確信度がこの閾値を超えたツール呼び出しのみ自動実行される。デフォルトは0.85。

AIクラシファイアの判断ロジック

Auto Mode の核心は、各ツール呼び出しを評価するインラインAIクラシファイアだ。

flowchart LR
    A[ツール呼び出し要求] --> B[クラシファイア評価]
    B --> C{リスクスコア\n≥ 閾値？}
    C -- "低リスク（閾値以下）" --> D[自動実行]
    C -- "高リスク（閾値超え）" --> E[人間に確認]
    B --> F{alwaysAsk\nリストに該当？}
    F -- "Yes" --> E
    F -- "No" --> C

    style D fill:#27AE60,color:#fff
    style E fill:#E74C3C,color:#fff

評価に使われる主なシグナルは「操作の可逆性（ファイル削除 vs 読み込み）」「影響範囲（ローカルファイル vs 本番DB）」「コンテキストとの整合性（タスク指示と操作内容のずれ）」の3つだ。

いつ Auto Mode を使うべきか

Auto Mode は万能ではない。以下の判断基準が実用的だ。

Auto Mode が適しているケース：

テスト環境や個人プロジェクトでの長時間リファクタリング
CI/CD パイプライン内での自動コードレビュー・修正
夜間バッチ処理（依存ライブラリ更新、ドキュメント生成など）

Zero-Trust/Relaxed を維持すべきケース：

本番データベースへのアクセスを含むタスク
複数リポジトリをまたぐ大規模変更
初めて Claude Code に任せるタスク種別

2. Voice Mode ── キーボードから離れた指示

Push-to-Talk という設計選択

2026年1月にリリースされた Voice Mode は、/voice コマンドで有効化できる音声入力機能だ。仕様として注目すべきは、常時リスニングではなく Push-to-Talk 方式を採用していることだ。

# Voice Mode を有効化
/voice

# ターミナルに表示されるメッセージ
# [Voice Mode ON] スペースバーを押しながら話してください。
# 離したら認識が始まります。

スペースバーを押している間だけマイクが開き、離した瞬間に音声認識が走る。常時マイクがオンになることはない。

この設計はプライバシーへの配慮から来ている。開発環境はしばしば機密情報が飛び交う場所だ──APIキーの話、顧客データの話、未発表機能の話。常時リスニングのシステムは、そういう環境では受け入れられない。Anthropic は「便利さよりも、ユーザーが確実にコントロールできる設計」を優先した。

2026年3月時点で20言語に対応しており、日本語の認識精度は技術的な専門用語（関数名、フレームワーク名など）も含めて実用水準に達している。

典型的な使い方

コードレビューの結果を見ながら口頭でフィードバックするシーン：

[スペースバーを押しながら]
「このファイルの handlePayment 関数、エラーハンドリングが甘い気がする。
 Stripe の API エラーコードごとに分岐して、ユーザーに適切なメッセージを
 返すように修正してほしい」
[スペースバーを離す]

Claude Code はこの音声指示をテキストに変換し、通常のプロンプトと同様に処理する。

3. `/loop` スケジュールタスク ── エージェントを「飼い続ける」

Cron との根本的な違い

従来の定期タスクは Cron で実装するものだった。0 9 * * 1 ./weekly-audit.sh のように、何をするかをスクリプトとして事前に書き切る必要があった。

/loop は違う。自然言語で「何を気にしてほしいか」を指示するだけで、Claude Code が毎回状況を判断しながら実行する。

# 毎朝9時に、昨日マージされたPRを確認してSlackに要約を投稿する
/loop "毎朝9時に、昨日マージされたPRを確認して、
       変更内容の要約と潜在的なリスクを #dev-updates に投稿してください"

# CI が失敗したら即座に通知・初期調査
/loop "CI が失敗するたびに、ログを読んで原因の仮説を立て、
       該当コミットの作者に Slack DM で送ってください"

# 週次の依存ライブラリ監査（月曜10時）
/loop "毎週月曜10時に、package.json の依存ライブラリを確認し、
       重大な脆弱性があるものをリストアップして、
       可能なら自動で patch バージョンアップのPRを作成してください"

裏側では /schedule コマンドと Cron が動いているが、ユーザーはそれを意識しなくていい。

ループの実行フロー

sequenceDiagram
    participant U as ユーザー
    participant L as /loop スケジューラ
    participant C as Claude Code Agent
    participant T as ツール群（Git/Slack/CI等）

    U->>L: /loop "毎朝PRレビュー要約を投稿"
    L->>L: スケジュール登録（09:00 daily）

    loop 毎朝9時
        L->>C: タスク起動
        C->>T: git log --since="yesterday" --merges
        T-->>C: マージされたPR一覧
        C->>T: 各PRの diff を取得
        T-->>C: 変更内容
        C->>C: 要約・リスク分析
        C->>T: Slack #dev-updates に投稿
        T-->>C: 投稿成功
        C-->>L: 完了
    end

ユースケースの広がり

/loop が実現するのは「定期的に気にかけてくれるエージェント」の存在だ。従来のCronと違い、状況が変われば対応も変わる。先週は問題なかったライブラリが今週 CVE が出た、なら自動でPRを作る。そういう文脈を読んだ対応が /loop の真価だ。

4. Computer Use ── デスクトップが操作対象になる

セットアップ不要の GUI 操作

2026年2月にリリースされた Computer Use は、Pro/Max プラン向けの機能だ。Claude Code がマウスカーソルの移動・クリック・ドラッグ・キーボード入力・ブラウザ操作を直接実行できる。

特筆すべきは「セットアップ不要」という点だ。Selenium や Playwright のようなテストフレームワークの設定が不要で、Claude Code に「ブラウザでこのフォームを埋めてテストして」と指示するだけで動く。

エンドツーエンド QA ワークフローの例

# E2E テストを自然言語で記述して実行させる
claude "ステージング環境（https://staging.example.com）で
        以下のユーザーフローをテストしてください：
        1. 新規ユーザーとして会員登録
        2. プロフィール画像をアップロード
        3. 商品を3点カートに追加
        4. クーポンコード SAVE10 を適用
        5. チェックアウトまで進む（決済は完了させない）
        各ステップのスクリーンショットを ./test-results/ に保存してください"

Claude Code は実際にブラウザを開き、フォームに入力し、ボタンをクリックし、エラーが出れば原因を調べる。

Before / After：QA 作業の変化

Before（Computer Use 以前）：

// Playwright でテストを事前に書く必要があった
test('checkout flow', async ({ page }) => {
  await page.goto('https://staging.example.com/register');
  await page.fill('[name="email"]', '[email protected]');
  await page.fill('[name="password"]', 'SecurePass123!');
  await page.click('[type="submit"]');
  // ... 数十行続く
});

After（Computer Use 利用時）：

# 自然言語で指示するだけ
claude "ステージング環境で会員登録からチェックアウトまでのフローをテストして"

コードを書く前の探索的テストや、自動化スクリプトの初期作成に特に効果が大きい。

5. Remote Control ── スマホからエージェントを操る

2026年2月：リサーチプレビューの衝撃

2026年2月、Anthropic は Remote Control のリサーチプレビューを公開した。概念はシンプルだが、体験としては非常に未来的だ──スマートフォンの Claude App から、デスクトップで動いている Claude Code を操作できる。

仕組みとしては、Claude Code がローカルで起動したまま、Anthropic のサーバーを経由してモバイルクライアントとの通信チャンネルを確立する。デスクトップのファイルシステムやターミナルへのアクセスは常にローカルのClaude Codeが担うため、コードや機密データがクラウドに直接送られるわけではない。

実際の使い方

[移動中にスマホから]
「さっきPRレビューのコメントがいくつか来てたと思うんだけど、
 対応できそうなものから修正しておいてもらえる？
 終わったら通知して」

[デスクトップのClaude Codeが応答]
「PRを確認しました。3件のコメントがあり、
 うち2件は対応完了、1件は設計判断が必要です。
 詳細を送ります。」

Remote Control のユースケース

会議中のタスク割り当て：議論でTODOが決まったら、その場でスマホから Claude Code に投げる
長時間タスクの監視：夜間ビルドの進行状況を外出先から確認
緊急の本番対応：インシデント発生時に、ラップトップが手元になくてもトリアージを始めてもらう

現時点ではリサーチプレビューのため、安定性や応答速度に課題があるケースも報告されているが、方向性としての重要性は明らかだ。

6. MCP Lazy Loading ── コンテキストを食いつぶさない

MCPの普及がもたらした問題

MCP（Model Context Protocol）の普及により、Claude Code には多彩なツールを接続できるようになった。Slack、Notion、GitHub、Jira、Figma、データベース──開発チームが使うすべてのサービスを MCP 経由で Claude Code に渡せる。

しかし、ここに問題が生じた。接続する MCP サーバーが増えるほど、起動時にすべてのツール定義がコンテキストウィンドウに読み込まれるのだ。10個のMCPサーバーがそれぞれ20個のツールを提供していれば、200個分のツール定義が常にコンテキストを占有する。これは実質的なコンテキスト汚染だ。

2026年3月：MCPエリシテーションサポート

flowchart LR
    subgraph Before["従来方式（全ロード）"]
        direction TB
        S["起動時"] --> T1["Slack tools × 15"]
        S --> T2["Notion tools × 20"]
        S --> T3["GitHub tools × 25"]
        S --> T4["Jira tools × 18"]
        T1 & T2 & T3 & T4 --> CTX_B["コンテキスト\n【常時 2,400 tokens 消費】"]
    end

    subgraph After["新方式（Lazy Loading）"]
        direction TB
        S2["起動時"] --> META["メタデータのみロード\n（ツール名・説明の概要）\n【約 200 tokens】"]
        META --> NEED{タスクに\n必要？}
        NEED -- "Yes" --> LOAD["該当MCPだけ\nオンデマンドロード"]
        NEED -- "No" --> SKIP["スキップ"]
        LOAD --> CTX_A["コンテキスト\n【必要分のみ消費】"]
    end

    style CTX_B fill:#E74C3C,color:#fff
    style CTX_A fill:#27AE60,color:#fff

**MCPエリシテーション（Elicitation）**とは、Claudeが「このタスクにはどのツールが必要か」を推論し、必要なMCPサーバーだけをその場で動的ロードする仕組みだ。

Before / After：コンテキスト使用量の比較

Before（一括ロード）：

起動時コンテキスト使用量:
- Slack MCP:   ~800 tokens（15ツール定義）
- Notion MCP:  ~900 tokens（20ツール定義）
- GitHub MCP:  ~1,100 tokens（25ツール定義）
- Jira MCP:    ~750 tokens（18ツール定義）
計: ~3,550 tokens が常にコンテキストを占有

After（Lazy Loading）：

起動時コンテキスト使用量:
- 全MCPのメタデータ概要: ~200 tokens のみ

タスク「PRのdiffを読んでSlackに要約を投稿して」実行時:
- GitHub MCP のみロード: ~1,100 tokens
- Slack MCP のみロード: ~800 tokens
- Notion, Jira はロードしない
実質使用: ~2,100 tokens（タスク完了後は解放）

設定方法

~/.claude/mcp_settings.json に "lazyLoad": true を追加するだけで有効化できる：

{
  "mcpServers": {
    "slack": {
      "command": "mcp-slack",
      "lazyLoad": true
    },
    "notion": {
      "command": "mcp-notion",
      "lazyLoad": true
    },
    "github": {
      "command": "mcp-github",
      "lazyLoad": true,
      "alwaysLoad": false
    }
  }
}

頻繁に使う MCP（たとえば常にファイルシステムへのアクセスが必要な場合）は "alwaysLoad": true にしておくことで、Lazy Loading の対象から外せる。

2026年Q1の機能を俯瞰して

6つの機能を見てきたが、共通したテーマが浮かび上がる。

mindmap
  root((Claude Code\n2026 Q1))
    自律性の向上
      Auto Mode
        AIによるリスク判定
        長時間タスクの無停止実行
      /loop
        定期タスクの自然言語化
        文脈を読んだ定期実行
    インターフェースの拡張
      Voice Mode
        Push-to-Talk設計
        20言語対応
      Remote Control
        モバイルからの遠隔操作
        非同期タスク割り当て
    操作範囲の拡大
      Computer Use
        GUI・ブラウザ操作
        コード不要のE2Eテスト
    効率化・最適化
      MCP Lazy Loading
        コンテキスト消費の最小化
        動的ツールロード

自律性：Auto Mode と /loop により、Claude Code は「呼ばれたら動く」から「継続的に働く」へ
インターフェース：Voice と Remote Control により、CLIの外側にも操作の起点が広がった
操作範囲：Computer Use により、コード以外のGUIやブラウザまでがアクション対象になった
効率化：MCP Lazy Loading により、ツール統合の規模を大きくしてもパフォーマンスが劣化しない

これらはバラバラな機能群ではなく、一貫したビジョンの実装だ。どこにいても、どんな状況でも、安全に、長時間動き続けるエージェント──そのビジョンが、2026年Q1の3ヶ月で急速に形になりつつある。

前章：Ch.1 プロローグ 次章：Ch.3 ユースケース大全（近日公開）

Ch.2 2026年1〜3月の新機能 ── CLI からプラットフォームへ

1. Auto Mode ── 「許可待ち」からの解放

なぜこの機能が生まれたか

3段階の許可モード

AIクラシファイアの判断ロジック

いつ Auto Mode を使うべきか

2. Voice Mode ── キーボードから離れた指示

Push-to-Talk という設計選択

典型的な使い方

3. /loop スケジュールタスク ── エージェントを「飼い続ける」

Cron との根本的な違い

ループの実行フロー

ユースケースの広がり

4. Computer Use ── デスクトップが操作対象になる

セットアップ不要の GUI 操作

エンドツーエンド QA ワークフローの例

Before / After：QA 作業の変化

5. Remote Control ── スマホからエージェントを操る

2026年2月：リサーチプレビューの衝撃

実際の使い方

Remote Control のユースケース

6. MCP Lazy Loading ── コンテキストを食いつぶさない

MCPの普及がもたらした問題

2026年3月：MCPエリシテーションサポート

Before / After：コンテキスト使用量の比較

設定方法

2026年Q1の機能を俯瞰して

3. `/loop` スケジュールタスク ── エージェントを「飼い続ける」