Claude Code 4月アップデート詳細：Memory Store・/ultrareview・ポストモーテムまとめ

はじめに：2026年4月、Claudeに何が起きたか

2026年4月、AnthropicはClaude APIとClaude Codeの両面で大きな変更を矢継ぎ早に打ち出した。

ひとつはManaged AgentsにおけるMemory Store APIの公開。エージェントがセッションをまたいで記憶を持ち越せるようになった。もうひとつは/ultrareviewコマンドの正式提供。クラウドで動くマルチエージェントがコードの深いバグを検出する仕組みだ。さらにv2.1.116・v2.1.117では大量のバグ修正が行われ、4月23日にはClaude Codeの品質低下インシデントを正直に記したポストモーテムが公開された。

これらの変更は単なる機能追加ではない。「エージェントに記憶を持たせる方法」「コードレビューをAIに委任する方法」「品質劣化をいかに検知・復旧するか」という3つの大きなテーマへのAnthropicの回答だ。

本記事では各アップデートの技術的な詳細と実装方法を解説し、それらが示す設計思想を読み解く。

この記事でカバーする内容：Memory Store API（永続記憶）、/ultrareview（クラウドコードレビュー）、v2.1.116/v2.1.117の主要変更、4/23ポストモーテムから学ぶ品質管理の教訓

Memory Store APIとは：Managed Agentsに「前回の記憶」が加わった

セッションが終わると消えていた情報

Managed Agentsのセッションは、デフォルトでは起動するたびにまっさらな状態から始まる。セッションが終了すると、エージェントが学習したユーザーの好み、プロジェクトのコーディング規約、過去に犯したミスの情報はすべて消える。

この「記憶喪失」問題を解決するのがMemory Store APIだ。

何が保存できるか

Memory Storeには任意のテキストを保存できる。典型的なユースケースはこうだ。

• ユーザーの好み（コードスタイル、命名規則、好みのフレームワーク）
• プロジェクト固有の規約（コミットメッセージのフォーマット、レビューのチェックリスト）
• エージェントが過去に犯したミスとその修正方法
• ドメイン知識（業務用語集、APIの仕様メモ）
• 共有リファレンス資料（GAAP会計フォーマット、ISO規格のサマリ）

各メモリはパス（/preferences/formatting.mdのような形式）で管理されるファイル構造を持つ。

Memory Storeのアーキテクチャ

Memory Store APIの実装：ストア作成からセッション接続まで

ステップ1：Memory Storeの作成

betaヘッダー managed-agents-2026-04-01 が必要だ（Pythonクライアントは自動で付与される）。

import anthropic

client = anthropic.Anthropic()

# Memory Storeを作成
store = client.beta.memory_stores.create(
    name="User Preferences",
    description="Per-user preferences and project context.",
)
print(store.id)  # memstore_01Hx...

descriptionはエージェントのシステムプロンプトに自動的に渡され、「このストアに何が入っているか」をエージェントが理解するために使われる。意味のある説明を書くことが重要だ。

ステップ2：初期コンテンツをシードする（オプション）

エージェントが最初のセッションから使えるように、リファレンス資料を事前に書き込んでおける。

# 規約ドキュメントを事前に書き込む
client.beta.memory_stores.memories.create(
    store.id,
    path="/formatting_standards.md",
    content="All reports use GAAP formatting. Dates are ISO-8601...",
)

# ユーザー設定ファイルも書き込む
client.beta.memory_stores.memories.create(
    store.id,
    path="/preferences/code_style.md",
    content="Use tabs for indentation. Max line length: 100 chars. Prefer explicit over implicit.",
)

1つのメモリは最大100KB（約2万5千トークン）。大きなドキュメントは小さなファイルに分割して管理するのが推奨パターンだ。

ステップ3：セッション作成時にアタッチする

Memory Storeはセッション作成時のresources[]配列で指定する。

session = client.beta.sessions.create(
    agent=agent.id,
    environment_id=environment.id,
    resources=[
        {
            "type": "memory_store",
            "memory_store_id": store.id,
            "access": "read_write",
            "instructions": "User preferences and project context. Check before starting any task.",
        }
    ],
)

instructionsはエージェントへの追加ガイダンス（最大4,096文字）で、ストア固有の使い方をエージェントに伝える。たとえば「タスク開始前に必ず確認すること」「新しいユーザー設定を検出したら記録すること」といった指示を書ける。

注意点：Memory Storeはセッション作成時にのみアタッチできる。実行中のセッションへの追加・削除はサポートされていない。

Memory Storeの制限値一覧

Memory Versioningと監査：すべての書き込みを追跡する

Memory Storeのもっとも重要な設計のひとつがイミュータブルなバージョン管理だ。メモリへの書き込みが発生するたびにmemver_...形式のバージョンが自動的に作られる。

バージョン履歴の活用

# あるメモリの変更履歴を確認する
for v in client.beta.memory_stores.memory_versions.list(
    store.id,
    memory_id=mem.id,
):
    print(f"{v.id}: {v.operation}")
    # memver_01abc: update
    # memver_02def: create

バージョン一覧は「誰がいつ何を書き込んだか」の監査証跡として機能する。特定バージョンのコンテンツを取得してロールバックすることも可能だ。

# 特定バージョンの内容を取得してロールバック
old_version = client.beta.memory_stores.memory_versions.retrieve(
    version_id,
    memory_store_id=store.id,
)
# 古い内容で現在のメモリを上書き
client.beta.memory_stores.memories.update(
    mem.id,
    memory_store_id=store.id,
    content=old_version.content,
)

コンプライアンス対応：redact機能

GDPRのような規制対応で「特定ユーザーのデータを削除したい」という場合、バージョン履歴の内容を消去するredactが使える。バージョンの存在は残るが、コンテンツは消去される。

client.beta.memory_stores.memory_versions.redact(
    version_id,
    memory_store_id=store.id,
)

ただし制約がある。「現在のhead」にあるバージョン（生きているメモリの最新版）はredactできない。先に新しい内容で上書きするか、メモリを削除してから、古いバージョンをredactする必要がある。

楽観的排他制御（Optimistic Concurrency）

複数のセッションが同じメモリを同時に書き換える場合の競合を防ぐために、SHA256ハッシュを使った前提条件チェックが使える。

# 現在のSHA256ハッシュを前提条件として指定
client.beta.memory_stores.memories.update(
    mem.id,
    memory_store_id=store.id,
    content="Updated content here",
    precondition={
        "type": "content_sha256",
        "content_sha256": mem.content_sha256
    },
)
# ハッシュが一致しなければエラーを返す（別セッションが書き換えていた）

セキュリティ設計：prompt injectionリスクをread_onlyで管理する

対策として、変更不要なリファレンス資料や共有参照データはread_onlyで管理することが推奨される。

resources=[
    {
        "type": "memory_store",
        "memory_store_id": shared_reference_store_id,
        "access": "read_only",    # 読み取り専用：書き込み不可
        "instructions": "共通の規約とスタイルガイド。変更しないこと。",
    },
    {
        "type": "memory_store",
        "memory_store_id": user_store_id,
        "access": "read_write",   # ユーザー固有のプリファレンスは書き込み可
        "instructions": "このユーザー専用の設定と過去の会話のサマリ。",
    }
]

1セッションに最大8つのストアをアタッチできるため、「読み取り専用の共有ストア＋読み書き可能なユーザー固有ストア」というパターンが推奨される。

Amazon Bedrock経由でのMemory Store API：非対応と代替手段

Memory Store APIはBedrockでは利用不可

Anthropic公式ドキュメントの「Claude in Amazon Bedrock」ページには、Bedrockで利用できない機能として以下が明記されている。

Not supported:

• Anthropic-defined tools (Web Search, Web Fetch, Remote MCP, Memory, Files API, Computer Use, Skills, Code Execution)
• Claude Managed Agents

Memory Store APIはClaude Managed Agentsの一部であり、Anthropicが運営するインフラストラクチャに依存している。AWSが管理するBedrock側のインフラからはアクセスできない。これはHaiku 4.5を含む全モデルに共通する制限だ。

Bedrockで利用できる機能は、Messages API・プロンプトキャッシュ・Extended Thinking・ツールユース（クライアント定義）・Citations・構造化出力に限られる。

現在Bedrockで使えるClaudeモデル

Amazon Bedrock AgentCore Memory：AWSネイティブの代替手段

BedrockでClaudeを使いながら永続記憶を実装したい場合、Anthropicのメモリ機能の代わりにAWSが提供するAmazon Bedrock AgentCore Memoryが選択肢になる。

AgentCore Memoryは、Amazon Bedrock AgentCoreプラットフォームの一部として提供されるAWSネイティブの記憶サービスで、Runtime・Memory・Identity・Gateway・Code Interpreter・Browser Tool・Observabilityという7つのサービスコンポーネントを持つ。

BedrockでClaude（Haiku 4.5を含む）を使い永続記憶を持たせる主な方法は3つある。

Haiku 4.5でメモリを実装する場合の注意点

Bedrockで最もコスト効率の高いHaiku 4.5をエージェントのバックエンドに使う場合、記憶の実装はクライアント側のtool useで行う。

from anthropic import AnthropicBedrockMantle

client = AnthropicBedrockMantle(aws_region="us-east-1")

# 記憶の読み書きをツールとして定義（DynamoDB等への読み書きを想定）
memory_tools = [
    {
        "name": "read_memory",
        "description": "過去のセッションから記憶を読み込む",
        "input_schema": {
            "type": "object",
            "properties": {
                "user_id": {"type": "string"},
                "key": {"type": "string"}
            },
            "required": ["user_id", "key"]
        }
    },
    {
        "name": "write_memory",
        "description": "次回のセッションのために情報を記憶する",
        "input_schema": {
            "type": "object",
            "properties": {
                "user_id": {"type": "string"},
                "key": {"type": "string"},
                "value": {"type": "string"}
            },
            "required": ["user_id", "key", "value"]
        }
    }
]

response = client.messages.create(
    model="anthropic.claude-haiku-4-5",
    max_tokens=2048,
    tools=memory_tools,
    messages=[{"role": "user", "content": "前回話した内容を教えてください"}]
)

このアプローチはAnthropicのMemory Store APIよりも実装コストが高いが、記憶の保存先（DynamoDB・S3・RDS・Aurora等）をAWSの既存インフラで完全に制御できる利点がある。ZDR（Zero Data Retention）も組み合わせやすい。

どちらを選ぶか

Anthropicのfirst-party APIを使うプロジェクトであれば、Memory Store APIが最も手軽で機能が充実している。一方、AWSのセキュリティ境界内にすべてのデータを収めたい・既存のAWSインフラと深く統合したい場合は、Bedrock + AgentCore Memoryまたはカスタムtool useが現実的な選択だ。

Claude API Skill：多言語対応の公式実装ガイドが登場

Anthropicはanthropics/skillsリポジトリに、Claude APIを使ったアプリケーション構築をガイドするclaude-apiスキルを公開した。

このスキルはClaude CodeのSkillシステムと連携し、開発者が/claude-apiとタイプするだけで適切なコード例や設計ガイダンスを得られるように設計されている。

対応言語と主要機能

claude-apiスキルはPython・TypeScript・Java・Go・Ruby・C#・PHPと、cURL（Raw HTTP）の8言語をカバーする。各言語ごとに以下のドキュメントが整備されている。

• 基本的なMessages API呼び出し（テキスト生成、Q&A、要約）
• ストリーミング（チャットUIでのリアルタイム表示）
• ツールユース（関数呼び出し、コード実行）
• バッチ処理（大量リクエストの非同期処理、50%コスト削減）
• プロンプトキャッシュ（キャッシュ配置とサイレント無効化の防止）
• Managed Agents連携（セッション作成、イベントストリーム処理）

どのサーフェスを選ぶか：意思決定フレームワーク

スキルには使用するAPIサーフェスを選ぶための意思決定ツリーが含まれている。

Opus 4.7のデフォルト設定

スキルのSKILL.mdには現行のモデル推奨設定が明示されている。

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-4-7",
    max_tokens=8096,
    thinking={"type": "adaptive"},
    messages=[{"role": "user", "content": "複雑なシステム設計を分析してください"}]
)

Opus 4.7ではeffortパラメータ（output_config.effortで指定）に"xhigh"という新しい値が追加されている。Claude Code内部でもデフォルトとして使われており、高度なコーディング・エージェントタスクに最適だ。

Managed Agentsとの連携設計

スキルのもうひとつの重要な教えは「エージェントは一度だけ作成する」という原則だ。

# 悪い例：毎回エージェントを作成（コストが高くなる）
def handle_request():
    agent = client.beta.agents.create(...)  # リクエストのたびに呼ぶのはNG
    session = client.beta.sessions.create(agent=agent.id)

# 良い例：エージェントIDを保存して使い回す
AGENT_ID = "agt_01Hx..."  # 一度作成してIDを保存

def handle_request():
    session = client.beta.sessions.create(agent=AGENT_ID)  # セッションだけ作成

エージェントオブジェクトは永続的な設定（モデル、システムプロンプト、ツール）を保持する。セッションは各タスクの実行インスタンスだ。

/ultrareview：クラウドで動くマルチエージェントコードレビュー

概要：何が違うのか

Claude Code v2.1.86から利用可能になった/ultrareviewは、通常の/reviewとは根本的に異なるアーキテクチャで動く。

ローカルの/reviewが単一パスで数秒〜数分かかるのに対し、/ultrareviewはAnthropicのクラウドインフラ上でリモートサンドボックスを起動し、複数のAIレビュアーエージェントを並列で走らせる。各エージェントがコード変更を独立してスキャンし、バグを発見したエージェントが再現・検証を行い、検証済みの知見のみを報告する仕組みだ。

これにより「スタイル提案」ではなく「実際のバグ」にフォーカスした高精度なレビューが可能になる。

基本的な使い方

# 現在のブランチをレビュー（デフォルトブランチとの差分）
/ultrareview

# 特定のGitHub PRをレビュー
/ultrareview 1234

引数なしで実行すると、カレントブランチのdiff（ステージング済み・未ステージの変更を含む）がバンドルされてリモートサンドボックスに送られる。PRモードでは、リモートサンドボックスがGitHubから直接PRをクローンするため、ローカルのワーキングツリーをアップロードする必要がない。

実行フロー

確認ダイアログでは以下が表示される。

• レビュー対象のファイル数・行数
• 残りの無料利用回数
• 推定コスト

確認後、レビューはバックグラウンドで実行される。ターミナルはそのまま使い続けられる。/tasksコマンドで実行中・完了済みのレビューを確認できる。

レビューが完了すると、検証済みの知見がセッションへの通知として届く。各知見にはファイルのパス、行番号、問題の説明が含まれており、そのままClaudeに「このバグを修正して」と指示できる。

/reviewとの比較

料金と無料試用

利用不可の場合

以下の環境では/ultrareviewは使えない。

• APIキーのみで認証している場合（/loginでClaude.aiアカウント認証が必要）
• Amazon Bedrock、Google Cloud Vertex AI、Microsoft Foundry経由での利用
• Zero Data Retentionを有効にしている組織

v2.1.116の変更点：ターミナルの信頼性とセキュリティ修正

2026年4月20日リリースのv2.1.116は「ターミナル入力の信頼性向上」に焦点を当てたパッチだ。25件の変更が含まれる。

主要な改善

/resumeの67%高速化：大規模セッション（40MB超、または多数のdead-forkエントリを持つ）での/resume実行が大幅に高速化された。以前は50MB超のファイルで空白表示になるバグもあった。

MCP起動の高速化：複数のstdioサーバーが設定されている場合、resources/templates/listの実行が初回の@メンション時まで遅延されるようになった。起動時の待ち時間が短くなる。

Thinkingスピナーの進捗表示：「still thinking」「thinking more」「almost done thinking」といった進捗メッセージがインラインで表示されるようになった。従来の別行ヒント表示から変更。

/config検索の改善：設定の値でも検索できるようになった。たとえば「vim」と検索するとEditor modeの設定を見つけられる。

バグ修正（主要なもの）

セキュリティ修正

サンドボックス内でのrmコマンド実行時に、危険なパスの確認をバイパスできる脆弱性が修正された。詳細は非公開だが、エージェントが意図せず重要なファイルを削除できてしまうケースをカバーする修正とみられる。

v2.1.117の変更点：モデル設定の永続化とeffort改善

2026年4月22日リリースのv2.1.117は28件の変更を含む。主なテーマは「設定の永続化」と「Opus 4.7対応の改善」だ。

モデル選択の永続化

/modelコマンドで選択したモデルがClaude Codeの再起動後も保持されるようになった。以前は起動するたびにデフォルトに戻っていた。また、プロジェクトのピン設定やManaged設定との優先順位が起動ヘッダーに表示されるようになり、「どのモデルが使われているか」が一目でわかるようになった。

MCP並行接続での起動高速化

ローカルとclaude.ai両方のMCPサーバーが設定されている場合、デフォルトで並行接続されるようになった。従来は順次接続で時間がかかっていた。

Opus 4.7のコンテキストウィンドウ修正

重要な修正：Opus 4.7のコンテキストウィンドウが1Mであるにもかかわらず、Claude Codeが200Kとして扱っていたバグが修正された。これにより、大きなプロジェクトでのOpus 4.7利用時に不要なコンテキスト切り捨てが発生していた問題が解消される。

Pro/Maxユーザーのデフォルトeffortをhighに変更

Pro・Maxユーザーに対し、Opus 4.6とSonnet 4.6のデフォルトeffortが"medium"から"high"に引き上げられた。

その他の修正

• OAuthトークンの期限切れ時の自動更新
• 大規模HTMLページでのWebFetchのハング解消
• サブエージェント実行時の誤検知マルウェア警告の排除
• Ctrl+_のアンドゥが入力直後に反応しない問題の修正
• プラグイン依存関係の自動解決機能

4/23ポストモーテム：3つのインシデントと品質管理の内幕

Anthropicは2026年4月23日、Claude Codeの品質低下インシデントについてのポストモーテムを公式エンジニアリングブログに公開した。2026年3月〜4月にかけて、3つの別々の問題が重なって発生したと報告されている。

インシデント1：推論effortのデフォルト低下（3月4日〜4月7日）

何が起きたか：3月4日、UIフリーズとレイテンシ問題に対処するためClaude Codeのデフォルト推論effortをhighからmediumに変更した。

影響：effortを下げることでレイテンシは改善したが、推論品質が低下し、ユーザーから「以前より頭が悪くなった」という声が寄せられるようになった。

修正：4月7日にhighに戻した。

インシデント2：キャッシュバグによる思考履歴の喪失（3月26日〜4月10日）

何が起きたか：3月26日にデプロイしたキャッシュ最適化の実装に重大なバグがあった。本来「アイドル状態（1時間以上）のセッション再開時に古い思考ブロックをクリアする」という意図だったが、実際には毎ターンで思考ブロックをクリアしてしまっていた。

影響：Claudeが各ターンで「前回何を考えたか」を覚えていない状態になった。これにより「物忘れ」「繰り返し」「奇妙なツール選択」という症状が報告された。バグが継続的（毎ターン）だったため、影響範囲が広くかつ診断が困難だった。

修正：4月10日に修正をデプロイ。

インシデント3：verbosity制限プロンプトの誤適用（4月16日〜4月20日）

何が起きたか：Opus 4.7の冗長性を減らすため、4月16日に「ツール呼び出し間のテキストは25語以内に収める」というシステムプロンプトの指示を追加した。

影響：この指示がモデルのパフォーマンスに予期しない影響を与えた。内部評価でSonnet・Opusの両バリアントで3%の知能低下が検出された。

修正：4月20日にプロンプト変更を元に戻し、4月23日にすべてのサブスクライバーの利用制限をリセットした。

インシデントのタイムライン

ポストモーテムが示す改善の方向性

Anthropicが公開した再発防止策から、今後の品質管理戦略が読み取れる。

1. 内部チームが公開ビルドを使う

「Standardize internal teams to use public Claude Code builds」と明記されている。内部の開発チームが別ビルドを使っていたため、一般ユーザーが経験した問題の早期発見が遅れた。

2. Code Reviewツールの強化

再発防止策の一つとして「Expand Code Review tool capabilities with multi-repository context support」が挙げられている。これは/ultrareviewの多リポジトリ対応拡張を示唆している。

3. すべてのシステムプロンプト変更に評価を義務化

「Implement broader per-model evaluations for all system prompt modifications」という方針が示された。今回のインシデント3は「プロンプトの小さな変更が大きな副作用を生む」という典型例だった。

4. 段階的ロールアウトとソーク期間

「Establish soak periods and gradual rollouts for intelligence-sensitive changes」という教訓が追加された。一度に全ユーザーに変更を展開するのではなく、段階的に展開して問題を早期検知する仕組みを整備する。

5. プロンプト変更の審査プロセス強化

「Add enhanced audit tooling and prompt change review processes」という対策が明記されている。今後、システムプロンプトへの変更は独立した評価チームのレビューを経るようになる。

ポストモーテムが示す姿勢

4月の変更点が示すAnthropicの設計思想

以上4つの大きなアップデートを俯瞰すると、Anthropicの開発方針が見えてくる。

「エージェントの永続化」への投資：Memory Store APIは単なる機能追加ではなく、「ステートレスなAI」から「文脈を記憶するAI」への移行を促す基盤だ。ユーザー設定やプロジェクト規約をエージェント自身が管理・更新する、というパターンが現実的になった。Claude Code v2.1.108で導入された/recap機能がセッション内の文脈管理を改善したとすれば、Memory Storeはセッションを超えた記憶の解決策だ。

「品質の透明性」への転換：4/23ポストモーテムは、AIの品質管理が「ブラックボックスの中の問題」ではなく、ソフトウェアエンジニアリングとして公開・議論できる問題であることを示した。

「深いレビュー」への需要応答：/ultrareviewは「AIがコードを書く」だけでなく「AIがAIの書いたコードを検証する」というメタレベルの品質保証の幕開けともいえる。マルチエージェントによる独立検証という設計は、AIエージェントフレームワーク比較2026で解説したマルチエージェントパターンの実用的応用例でもある。

「開発者体験の地道な改善」の継続：v2.1.116・v2.1.117の変更点は派手さはないが、/resumeの67%高速化、Kittyプロトコル対応、Opus 4.7のコンテキストウィンドウ修正など、実際の開発体験を詰まらせていた問題をひとつずつ潰している。

これらは単独で評価するより、「エージェントが長時間・複数セッションにわたって使える実用的なツールに育てる」という一貫した方向性として読むべきだ。

まとめ

Claude Code 2026年4月のアップデートをまとめると以下のとおりだ。

Memory Store APIの実装を始めるなら、まずclient.beta.memory_stores.create()でストアを作成し、セッション作成時にresourcesでアタッチするフローを試してほしい。/ultrareviewは無料試用3回があるうちに、実際のPRで試してみる価値がある。

参照ソース

• Using agent memory — Anthropic Managed Agents Documentation
• anthropics/skills: claude-api Skill — GitHub
• Find bugs with ultrareview — Claude Code Documentation
• April 23 Postmortem — Anthropic Engineering Blog
• Claude Code v2.1.116 Release Notes — claudeupdates.dev
• Claude Code v2.1.117 Release Notes — claudeupdates.dev
• claude-code CHANGELOG — GitHub
• Claude in Amazon Bedrock — Anthropic Documentation（Feature availability一覧）
• Amazon Bedrock AgentCore and Claude — AWS Machine Learning Blog
• Amazon Bedrock AgentCore Runtime: managed session storage — AWS What’s New