2026年4月のClaude Codeデスクトップ刷新で変わった開発体験の全体像

2026年4月のClaude Codeデスクトップ刷新で変わった開発体験の全体像

Anthropicが2026年4月14日にリリースしたClaude Codeデスクトップアプリの全面刷新は、AIコーディングツールの位置づけそのものを再定義する内容でした。従来のチャット型インターフェースから脱却し、複数のAIエージェントを同時に操作できるダッシュボード型ワークスペースへと生まれ変わっています。今回のアップデートでは、マルチセッションサイドバー、ドラッグ＆ドロップ対応のペインレイアウト、統合ターミナル、アプリ内ファイルエディタ、拡張プレビュー機能という5つの主要機能が一挙に追加されました。同日にはクラウド自動化機能「Routines」も同時発表されており、単なるUI改善にとどまらない戦略的なプロダクトの転換点となっています。

旧バージョンで常態化していた4窓切り替えとコンテキスト断絶の課題

刷新前のClaude Codeデスクトップ体験は、機能的には十分だったものの、作業環境としては断片的でした。チャットインターフェースはひとつのウインドウに、コードエディタは別のアプリケーションに、ターミナルはさらに別のウインドウに分かれた状態が標準的な使い方だったのです。複数のプロジェクトを同時に進行する開発者にとって、この分散構成は深刻なコンテキストスイッチコストを生んでいました。

たとえば、バックエンドのリファクタリングをClaude Codeに依頼しつつ、フロントエンドのバグ修正を別セッションで進めたい場合、4つのターミナルウインドウを開き、それぞれでディレクトリ移動コマンドを打ち、どのウインドウでどのタスクを実行中かを頭の中で管理する必要がありました。この物理的なウインドウ管理こそが、AIペアプログラミングの生産性を引き下げる最大のボトルネックだったといえます。開発者コミュニティでは以前から改善要望が上がっていたポイントであり、今回の刷新はまさにその課題を正面から解決するものです。

2026年4月14日リリースの刷新で追加された主要5機能の概要

今回のリリースで追加された機能は大きく5つに整理できます。第一に、すべてのアクティブセッションと最近のセッションを一覧表示するマルチセッションサイドバーです。プロジェクト別やステータス別のフィルタリングに対応しており、セッション管理の視認性を格段に高めた点が特徴です。第二に、ペインの配置をドラッグ＆ドロップで自由に変更できるレイアウト機能が加わりました。

第三の機能は、テストやビルドをアプリ内で直接実行できる統合ターミナルです。第四に、簡易的なコード修正に対応するインラインファイルエディタが搭載され、外部エディタへの切り替えが不要な場面が増えています。そして第五に、HTMLファイルやPDFをアプリ内で表示できるプレビューペインが拡張されました。これら5機能の同時投入は、Claude Codeを単独のAIチャットツールからIDE的な統合ワークスペースへと変貌させるものであり、2025年までのチャットベースの開発体験とは一線を画す進化を遂げた形です。

チャット型UIからエージェントダッシュボードへ移行した設計思想の転換

今回の刷新で最も注目すべき変化は、UIの表面的な改善ではなく、アプリケーションの設計思想そのものが転換された点にあります。Anthropicは公式発表で「複数のタスクが同時進行し、ユーザーがオーケストレーターの席に座る」という新しいメンタルモデルを明確に打ち出しました。これは、AIが1つのタスクを順番に処理するペアプログラマーから、複数のAIエージェントを並列で指揮・監督する運用プラットフォームへの移行を意味しています。

実際のインターフェースを見ると、従来の「ユーザーが質問し、AIが回答する」一問一答の形式から、左側にセッション一覧、中央に作業ペイン、右側にプレビューやターミナルを配置するダッシュボード型に変わっていることがわかります。この設計は、1人の開発者が同時に4つのセッションを走らせ、完了したものから順にレビューしていく並列ワークフローを前提としたものです。ジュニア開発者の逐次処理型から、テックリードの並列管理型へ、作業スタイルを根本から変える設計思想が反映されています。

対応OSがmacOSとWindowsに限定される初期リリースの提供条件

今回のデスクトップ刷新は、Pro、Max、Team、Enterpriseの各有料プランに加え、API利用者にも提供されています。ダウンロードはclaude.com/downloadから可能で、既存ユーザーには自動アップデートが配信される仕組みです。ただし、初期リリースの時点で対応OSはmacOSとWindowsの2プラットフォームに限定されており、Linuxデスクトップ版は数週間以内の追加が案内されています。

Linux環境で開発を行っているユーザーにとっては、これまで通りCLI版のClaude Codeを引き続き利用する形になります。CLI版自体は全プラットフォームで従来通り動作するため、機能的な後退はないものの、新しいマルチセッション管理やドラッグ＆ドロップレイアウトといったGUI固有の体験は当面享受できません。また、AWS BedrockやGoogle Vertex AI経由での利用では、アクティビティダッシュボードやRoutinesなど一部機能が制限される点にも留意が必要です。

ストリーミング応答や自動アーカイブなど日常操作を変える品質改善の詳細

主要5機能の追加に加えて、日常的な使い勝手を向上させる品質改善も数多く盛り込まれています。まず、ストリーミング応答が強化され、Claudeがテキストを生成している最中から逐次表示されるようになりました。従来のように全出力の完了を待つ必要がなくなったことで、長文のコード生成やリファクタリング指示でも体感的な待ち時間が大幅に短縮されています。

セッションのライフサイクル管理も改善されており、関連するプルリクエストがマージまたはクローズされると、対応するセッションが自動的にアーカイブされる仕組みが導入されました。アーカイブされたセッションはサイドバーの「Archived」フィルタからいつでも参照・再開が可能で、明示的な削除操作とは区別されています。さらに、トークン使用量を常時確認できる使用量ボタンが常時表示に変更され、想定外のコスト発生を未然に防ぎやすくなった点も、日常運用においては地味ながら重要な改善といえるでしょう。

マルチセッション管理で複数タスクを同時に進められるサイドバー設計

今回のデスクトップ刷新において、最も作業効率に直結する変更がマルチセッションサイドバーの導入です。従来はひとつのウインドウで1セッションしか扱えなかったため、複数のタスクを並行して進めるには複数のターミナルを個別に開く以外に方法がありませんでした。新しいサイドバーでは、すべてのアクティブセッションと最近のセッションが左ペインに一覧表示され、ワンクリックでセッション間を行き来できる操作性を備えました。Cmd+N（macOS）またはCtrl+N（Windows）で新規セッションを即座に追加できるため、思いつきベースのタスク並列化も容易になっています。

プロジェクト別・ステータス別フィルタで実現する一覧性の高い管理画面

サイドバーに搭載されたフィルタ機能は、セッション数が増加しても管理が煩雑にならない工夫が凝らされた設計です。プロジェクト単位でのグルーピングに対応しており、複数のリポジトリを横断的に扱う開発者でも、現在どのプロジェクトのどのタスクが動いているかを即座に把握可能です。ステータスフィルタでは、実行中・完了・アーカイブ済みといった状態で絞り込みができ、完了したセッションのレビューに集中したい場面でも視覚的なノイズを排除できます。

環境別のフィルタリングも用意されており、開発環境とステージング環境で異なるセッションを走らせている場合にも混同を防げる設計です。サイドバーにはRoutinesセクションへのリンクも統合されており、同日発表されたクラウド自動化機能へのアクセスもシームレスになっています。セッション数が10を超えるような大規模な並列運用でも、フィルタとグルーピングの組み合わせで目的のセッションに2クリック以内で到達できる点が、この管理画面の最大の強みといえます。

Gitワークツリーによるセッション間の変更分離とコンフリクト防止の仕組み

マルチセッション機能を実用的にしている技術的な基盤が、Gitワークツリーを活用した変更分離の仕組みです。Gitリポジトリ内で新規セッションを開始すると、そのセッション専用のワークツリーが自動的に作成され、他のセッションの変更内容と干渉しない独立した作業空間が確保されます。これにより、セッションAでバックエンドの大規模なリファクタリングを進めながら、セッションBで同じリポジトリのフロントエンドを修正しても、コミット前に意図しないコンフリクトが発生するリスクを回避できます。

この設計は、複数のブランチで同時に作業を行うチーム開発のフローをそのままAIセッションに適用したものです。各セッションが独立したブランチのように振る舞うため、完成したセッションの成果物だけを選択的にマージする運用が可能になっています。従来のように1つのディレクトリで複数の変更を混在させ、手動でスタッシュや退避を繰り返す必要がなくなったことは、特にモノレポ構成のプロジェクトで大きな恩恵をもたらすでしょう。

Cmd+;で起動するサイドチャットがメインコンテキストを汚さない分岐設計

マルチセッション管理と並んで注目すべき新機能が、ショートカットキーCmd+;（macOS）またはCtrl+;（Windows）で起動するサイドチャットです。この機能は、メインスレッドのコンテキストを参照しつつも、サイドチャット側の質問や回答はメインスレッドに書き戻されない「一方向参照型」の分岐設計が採用されています。たとえば、Claudeがリファクタリングを実行中に「このデザインパターンの名前は何だったか」と確認したい場合、サイドチャットで質問すれば、メインタスクの文脈を理解した上で回答を得られるにもかかわらず、本線のコンテキストには一切影響を与えません。

従来の運用では、同一セッション内で雑多な質問を投げると、コンテキストウインドウにその質問と回答が蓄積され、後続のタスクで不要な情報がモデルの判断に影響を及ぼすことがありました。サイドチャットはこの問題を構造的に解消しており、メインスレッドの純度を保ちながら、必要に応じて知識ベースへのアクセスが可能になっています。ちょっとした確認のために新しいセッションを立ち上げるオーバーヘッドも不要になるため、思考の流れを中断せずに作業を継続できる点が実用上の最大の利点です。

4セッション並列運用で1人のテックリードに近づく作業効率の実測事例

実際に刷新後のデスクトップアプリを使い込んだ開発者のレポートによると、4つのセッションを並列で運用した場合の作業効率は、従来の逐次処理型と比較して劇的に向上したと報告されました。あるソロ開発者は、クライアント向けSaaSのバックエンド、Next.jsフロントエンドの再構築、データ収集用スクレイパー、実験的な新機能の4タスクを同時に走らせ、どれかが完了するたびにレビューに切り替えるワークフローを日常的に実践しているとのことです。

この並列運用の本質は、AIの応答待ち時間を他タスクの進行で埋められる点にあります。セッション1でリファクタリングが「思考中」の間にセッション2のバグ修正を開始し、セッション2のレビュー準備が整う頃にはセッション1の出力が完了しているというサイクルが自然に生まれます。1人の開発者がジュニアエンジニア的な「1タスク完了→次タスク開始」の流れから、テックリード的な「4件同時進行中で手が空いたものからレビュー」の流れに近づけるという評価は、マルチセッション機能がもたらす最も顕著な恩恵を端的に示しているといえるでしょう。

PRマージ時に自動アーカイブされるセッションのライフサイクル管理

マルチセッション運用で避けて通れない課題が、完了したセッションの後始末です。並列数が増えるほど、終了済みのセッションがサイドバーに残り続けることで管理画面が雑然とするリスクが高まります。今回の刷新ではこの問題に対して、関連するプルリクエストがマージまたはクローズされたタイミングでセッションを自動的にアーカイブする仕組みが導入されました。

自動アーカイブされたセッションはサイドバーのメインビューからは非表示となりますが、「Archived」フィルタを使えばいつでも一覧表示が可能で、過去のセッションを再開して続きの作業を行うこともできます。削除とアーカイブは明確に区別されており、削除は各セッションのメニューからの明示的な操作が必要になっています。この設計により、アクティブなセッションだけが常にサイドバーの上位に表示される状態が自動的に維持され、手動でのセッション整理に時間を取られることがなくなりました。作業完了からPRマージまでの一連の流れがアプリ内で完結する点も、開発フローの一体感を高めています。

統合ターミナルとファイルエディタで実現するエディタ切り替え不要の作業環境

マルチセッション管理と並ぶもう一つの大きな変化が、開発に必要なツール群をアプリ内部に統合した点です。統合ターミナル、インラインファイルエディタ、再設計されたdiffビューア、拡張プレビューペインの4要素が加わったことで、従来は外部アプリとの間で頻繁に発生していたコンテキストスイッチが大幅に削減されています。Anthropicは「よく使うツールをアプリ内に取り込み、エディタに切り替えずにClaudeの成果物をレビュー・修正・出荷できるようにする」という方針を明確にしており、開発者の作業動線を自社アプリ内に集約する意図がうかがえます。

アプリ内ターミナルでテスト実行とビルドを完結させる具体的な操作手順

統合ターミナルは、Claudeが生成したコードに対してテストの実行やビルドの確認を即座に行える機能です。従来であれば、Claudeがコードを出力した後に外部のターミナルアプリに切り替え、該当ディレクトリへ移動し、テストコマンドを手動で入力する流れが一般的でした。統合ターミナルでは、現在のセッションが紐づいているリポジトリのコンテキストがそのまま引き継がれるため、ディレクトリ移動の手間なくコマンドを実行できます。

操作手順としては、セッション画面の下部または任意のペイン位置にターミナルパネルを展開し、通常のシェルコマンドを入力するだけです。npm testやpytestなどのテストコマンドを実行し、その結果を確認した上で、必要があればClaude に追加の修正指示を同じセッション内で出せるワークフローが成り立ちます。ビルドが失敗した場合のエラーログもターミナル上に表示されるため、エラー内容をコピーしてClaude に貼り付ける際にもウインドウ切り替えが発生しません。この一連の流れがアプリ内で完結する点が、開発の反復速度を高める鍵になっています。

スポット修正に特化したインラインファイルエディタの用途と制約

インラインファイルエディタは、Claude が生成したコードに対して1〜2行程度のスポット修正を加えたい場面で活用する機能です。変数名の変更やコメントの追加など、わざわざVS CodeやJetBrains系IDEを開くほどではないが手動で直したい箇所がある場合に、アプリ内で完結できるようになりました。Claude Codeの成果物を確認しながら、その場で微調整を施してコミットまで進められる動線は、レビューから修正までの往復コストを最小化しています。

ただし、このエディタは本格的なIDE の代替を意図した設計ではない点には注意が必要です。シンタックスハイライトや自動補完といった高度なエディタ機能は限定的であり、大規模なリファクタリングや複数ファイルにまたがる修正には従来通り専用のエディタを使う方が効率的な場面も残ります。Anthropic自身がこのアプリを「IDEではなくエージェントダッシュボード」と位置づけていることからも、ファイルエディタはあくまでスポット修正用の補助ツールという役割が明確に定義されています。全ファイル編集をアプリ内で完結させることを期待すると、かえってストレスが生じる可能性があるため、用途を限定して使うのが効果的な運用方針といえるでしょう。

大規模変更セットに対応する再設計されたdiffビューアの表示速度と精度

刷新に伴い、diffビューアもゼロから再設計されています。Claude Codeが大規模なリファクタリングを行った場合、変更差分が数百行から数千行に及ぶことは珍しくありません。旧バージョンのdiffビューアでは、このような大規模変更セットの表示に時間がかかり、スクロール操作にもたつきが生じることがありました。今回の再設計では表示速度が大幅に改善され、大きなチェンジセットでもスムーズに全体を俯瞰できる水準に到達しました。

精度面でも向上が見られ、変更箇所のハイライト表示がより正確になったことで、Claudeがどの行を追加し、どの行を削除したかを視覚的に瞬時に把握できる仕様です。行単位だけでなく、行内の文字レベルでの変更箇所も色分け表示される仕様が採用されており、微妙な修正内容の見落としを防ぐ効果があります。レビュー作業においては、外部のGitクライアントやGitHub上のdiff画面に切り替えなくても、アプリ内でコードレビューの大部分を完了できる品質に到達しているといえます。

HTMLファイルやPDFをアプリ内で確認できるプレビューペインの対応範囲

拡張されたプレビューペインは、Claude Code が生成した成果物をブラウザやPDFリーダーを開かずにアプリ内で即座に確認できる機能です。HTMLファイルの場合はレンダリング結果がリアルタイムで表示され、ウェブアプリケーションのフロントエンド開発においてレイアウトや見た目の確認が高速化されます。PDFファイルについても、ドキュメント生成タスクの出力をそのまま閲覧できるため、成果物の品質チェックまでをアプリ内で一貫して行えるようになりました。

さらに、ローカルで起動しているアプリサーバーの出力もプレビューペインで表示可能とされており、開発サーバーの出力を確認するためだけにブラウザを開く手間が省けるケースが増えています。ペインの配置はドラッグ＆ドロップで自在に変更できるため、セッションチャットを左側、プレビューを右側に並べて表示しながらClaude に修正指示を出す、といったレイアウトを自分好みに構築可能です。これまで点在していた確認作業のタッチポイントを1つのアプリ画面内に集約できることは、特にフロントエンド開発者にとって実用的な価値が高い改善となっています。

Verbose・Normal・Summaryの3表示モードで調整する情報密度の最適化

開発者によって、Claude の出力に求める情報量は異なります。デバッグ中であれば思考過程も含めた詳細な出力を確認したい場面がある一方、定型タスクの実行状況を流し見するだけなら概要だけで十分なこともあるでしょう。今回の刷新で導入された3つの表示モードは、この情報密度の最適化を実現する仕組みです。Verboseモードでは思考過程やツール呼び出しの詳細を含む全情報が表示され、Normalモードでは標準的な応答のみに絞られた表示となり、Summaryモードでは出力が要約され、進捗の全体感を把握するのに適した密度になります。

この3モードの使い分けは、マルチセッション運用との組み合わせで特に威力を発揮する場面が増えるでしょう。メインで注力しているセッションはVerboseモードにして詳細を追い、バックグラウンドで進行中のタスクはSummaryモードに切り替えておくことで、注意力の配分を効率化できる利点が生まれました。情報過多による認知負荷を軽減しながら、全セッションの進行状況を把握し続けるバランスが取りやすくなるため、並列セッション数が3つ以上になる運用スタイルでは、この表示モード切り替えの活用が生産性に直結するポイントといえます。

クラウド上で自動実行されるRoutines機能の仕組みと3種類のトリガー設定

デスクトップアプリの刷新と同日の2026年4月14日にリサーチプレビューとして発表されたのが、Claude Code Routinesです。Routinesは、プロンプト・リポジトリ・コネクタの設定を一度パッケージ化すれば、Anthropicのクラウドインフラ上で自動的に繰り返し実行できる自動化機能です。最大の特徴は、ユーザーのローカルマシンが起動していなくてもRoutinesが動作し続ける点でしょう。従来のCLIにおける/scheduleや/loopコマンドはセッションが開いている間しか有効ではありませんでしたが、Routinesはその制約を根本から解消した機能です。

プロンプトとリポジトリとコネクタを1度設定するだけの基本構造

Routineの基本構造は極めてシンプルで、3つの要素で構成されるシンプルな仕組みです。まず、Claudeに実行させたいタスクを記述したプロンプトが中核となります。次に、対象となるリポジトリを1つまたは複数指定し、最後にSlack、Linear、Google Drive、GitHubなどの外部サービスとの連携に必要なコネクタを設定します。この3要素を一度パッケージ化してしまえば、以降は手動操作なしで自動的に繰り返し実行される仕組みです。

作成はclaude.ai/code/routinesのWeb画面からGUIで行う方法と、CLIで/scheduleコマンドを使って会話形式で設定する方法の2通りが用意されています。CLIからは/schedule daily PR review at 9amのように自然言語に近い形式で設定でき、既存の/scheduleによる予約済みタスクは自動的にRoutinesへ移行される互換性も確保されています。設定の変更や実行状況の確認は、Web画面とCLIのどちらからでも可能です。1回の設定で継続的な自動化が得られるこのシンプルさが、Routines導入の心理的ハードルを大きく下げている要因といえるでしょう。

毎時・毎日・毎週から選べるスケジュールトリガーの設定方法と実行タイミング

Routinesの第一のトリガータイプが、スケジュールトリガーです。毎時・毎日・平日のみ・毎週の4パターンからプリセットを選択し、実行時刻をローカルタイムゾーンで指定する形式になっています。設定画面で入力した時刻はサーバー側で自動変換されるため、クラウドインフラがどの地域で動作しているかを意識する必要はありません。なお、実行開始は指定時刻から数分程度のずれが生じる場合がありますが、各Routineごとのオフセットは一定に保たれます。

スケジュールトリガーの典型的な活用例としては、毎晩の未対応イシューのトリアージがあります。深夜2時にRoutineが起動し、Linearから当日の新規バグを取得して優先度分類を行い、対応担当者のアサインを済ませた上でSlackの指定チャンネルにサマリーを投稿するといったフローが、プロンプトの設定1回で実現可能です。週次で実行するドキュメント整合性チェックも有力なユースケースで、直近のマージ済みPRを走査して変更されたAPIに関連するドキュメントを検出し、更新PRを自動で作成するRoutineが公式のサンプルとして紹介されています。

HTTP POSTで任意のシステムから起動できるAPIトリガーの連携パターン

第二のトリガータイプであるAPIトリガーは、任意の外部システムからHTTPリクエストを送信してRoutineを起動できる仕組みです。各Routineには専用のエンドポイントURLと認証トークンが発行され、POSTリクエストにメッセージを含めて送信するとRoutineが実行を開始し、セッションURLが返却される流れです。この仕組みにより、監視ツールからのアラート通知、CI/CDパイプラインのデプロイ完了通知、社内ツールからのタスク起動など、既存のワークフローにClaude Codeの処理を自然に組み込めます。

具体的な連携パターンの1つとして、アラートトリアージが挙げられます。モニタリングツールがエラーを検知した際にAPIトリガーを叩き、Claudeがスタックトレースと直近のコミット履歴を照合して原因を特定し、修正案のドラフトPRを作成した上でオンコールチャンネルにサマリーを投稿するフローです。もう1つの典型例がデプロイ後の検証で、CDシステムのデプロイ完了フックからAPIトリガーを呼び出し、スモークテストを実行して合否判定をリリースチャンネルに通知するRoutineが実装例として紹介されています。HTTP リクエストさえ送信できる環境であれば連携可能なため、既存インフラへの統合の柔軟性が際立っています。

PR作成やマージを検知して自動起動するGitHubトリガーの実務活用例

第三のトリガータイプであるGitHubトリガーは、リポジトリ上で発生するイベントを検知してRoutineを自動起動する仕組みです。対応するイベントはPRのオープン、クローズ、ラベル付与、同期（コミット追加）のほか、PRレビューの送信やレビューコメントなど13種類以上に及びます。利用にあたっては、Claude GitHub Appのインストールが必要で、CLIの/web-setupコマンドによるリポジトリアクセス設定とは別の手順である点に注意が必要です。

最も実用的な活用例の一つが、カスタムコードレビューの自動化です。PRがオープンされたタイミングでRoutineが起動し、チーム独自のレビュー基準に基づいたチェックリストを適用してインラインコメントを残す運用が可能になります。この仕組みの本質的な価値は、レビュー基準を一度プロンプトに定義すれば一貫した品質でレビューが適用される点にあります。また、マージ済みPRを検知して別言語のSDKへ自動ポートを行うRoutineや、特定のモジュール変更を検出してセキュリティチーム向けのSlack通知を送るRoutineなど、組織固有のワークフローに合わせた柔軟な設計が可能です。

claude/プレフィクス制限やWebhookの時間上限など運用時の注意点

Routinesの運用にあたっては、リサーチプレビュー段階ゆえの制約をあらかじめ把握しておく必要があります。最も重要な制約は、Routinesがプッシュ可能なブランチがclaude/プレフィクス付きのブランチに限定されている点です。この制限は、誤った設定のRoutineがmainブランチやproductionブランチに直接変更をプッシュしてしまうリスクを防ぐための安全機構として機能しています。

GitHubトリガーに関しては、Routineごと・アカウントごとにWebhookの時間あたり発火回数に上限が定められている点にも注意が必要です。アクティブなリポジトリでPRの頻度が高い場合は、フィルタ条件を適切に設定してイベント数を絞り込むことが推奨されるでしょう。また、Routinesの実行はインタラクティブセッションと同じサブスクリプション使用量から消費される仕組みのため、Routinesを多数設定するとインタラクティブな作業に使えるトークン枠が圧迫される可能性も否定できません。日次の実行上限もプランごとに異なるため、自動化の規模と日常的な対話利用のバランスを考慮した設計が運用成功の鍵になるでしょう。

CursorやGitHub Copilotとの機能差から見る開発ツール選定の判断材料

Claude Codeのデスクトップ刷新とRoutinesの同時発表は、AIコーディングツール市場における競争を一段と激化させました。主要な競合であるCursorとGitHub Copilotもそれぞれ独自の進化を遂げており、開発者にとってはどのツールを主軸に据えるかの判断が一層重要になっている状況です。ここでは、並列セッション対応、クラウド自動化、IDE統合度、課金体系という4つの観点から3ツールの違いを整理し、自分の開発スタイルに合った選定を行うための材料を提供していきましょう。

並列セッション・クラウド実行・IDE統合で比較する3ツールの機能対応表

Claude Code、Cursor、GitHub Copilotの3ツールを機能面で比較すると、それぞれの設計思想の違いが明確に浮かび上がってきました。

この対応表が示す通り、Claude Codeは並列セッション管理とクラウド自動化において他の2ツールに対して明確な差別化を実現した格好です。一方、IDE機能の充実度ではCursorがフルエディタを提供しており、既存のエディタ環境を維持したまま導入したい場合はGitHub Copilotの拡張機能型アプローチに強みがあるでしょう。ツール選定においては、自分の開発ワークフローで並列性と自動化のどちらを重視するかが、判断の最大の分岐点になるといえます。

Cursorのクレジット制とClaude Codeの5時間リセット制の課金構造の違い

課金構造の違いは、日々の開発体験に直結する重要な判断要素です。Cursorは月額20ドルのProプランで月間クレジットプールを提供し、プレミアムモデルの利用にクレジットを消費する方式を採用しています。未使用クレジットは月末まで持ち越し可能で、Auto モードでは無制限のモデル選択が可能なため、ルーティンタスクのコストを抑えやすい設計です。一方、Claude Codeのサブスクリプションプランは5時間ごとのローリングウインドウでトークン使用量がリセットされる方式を採用した点が特徴的です。

この構造上の違いは、作業パターンによって有利不利が逆転する構造になっている点を理解しておくべきでしょう。Cursorのクレジット制は月間通して均等に使う開発者に適しており、特定の日に集中して大量のクレジットを消費する使い方では月途中で枯渇するリスクが伴うでしょう。Claude Codeの5時間リセット制は、5時間ごとに枠が回復するため短期間の集中利用には強い反面、リセット直前に枠を使い切ると次のリセットまで待つ必要が生じる点がデメリットです。バースト型の作業スタイルにはCursorの月間プール、毎日コンスタントに使う開発者にはClaude Codeの5時間リセットがそれぞれフィットしやすい傾向にあります。

GitHub Copilotのエージェントモードとの自律性レベルの比較観点

GitHub Copilotも2025年後半からエージェントモードを強化しており、単なるコード補完ツールからの脱却を図っている段階です。Copilotのエージェントモードは、VS CodeやJetBrains上でファイル編集、ターミナルコマンドの実行、PRの作成まで一貫して行える点が特徴です。ただし、2026年4月時点では並列セッションの同時管理やクラウド上での自律的な自動実行といった機能はClaude Codeほど前面には出ていません。

自律性のレベルという観点で比較すると、Claude CodeのRoutinesは「人間がいなくてもクラウド上で自律的にタスクを実行し続ける」というスタンスを取っているのに対し、GitHub Copilotのエージェントモードは「人間がIDE上で作業する際の自律的アシスタント」という位置づけに留まっています。この違いは、開発組織のガバナンス方針にも関わる選択です。AIの自律的な実行範囲を広く許容できるチームにはRoutinesの活用が大きなメリットをもたらしますが、すべてのAI操作に人間の承認を介在させたい組織では、IDE統合型のCopilotの方が管理上の安心感があるでしょう。

長時間の自律コーディングが必要な場面でClaude Codeが有利になる条件

Claude Codeが競合に対して最も明確な優位性を持つのは、長時間の自律コーディングが必要となる開発タスクです。大規模なリファクタリング、複数ファイルにまたがるアーキテクチャ変更、テストの網羅的な追加といったタスクでは、AIがまとまった時間をかけて自律的に作業を進められることが生産性に直結する要素です。Claude CodeのMaxプラン（20x）では、Pro比で20倍のトークン使用量が確保されており、Opusクラスのモデルを活用した長時間セッションに耐えうる設計が採用されました。

反対に、短いコード補完やスニペット生成が主な用途であれば、GitHub Copilotの軽量な拡張機能やCursorの応答速度に軍配が上がる場面も少なくないでしょう。Claude Codeが真価を発揮する条件を整理すると、以下の要件が複数当てはまる場合に最も恩恵が大きくなります。

• マルチリポジトリで並列にタスクを回す必要がある
• 夜間や週末にもタスクをクラウド上で自動実行したい
• コードレビューを一貫した基準で自動化したい
• 大規模リファクタリングなど長時間の自律的処理を任せたい

自分の開発ワークフローがこれらの条件にどの程度合致するかを見極めることが、適切なツール選定の出発点になるでしょう。

ツール移行時に見落としやすいMCP連携やSSH対応の互換性チェック項目

既存のAIコーディングツールからClaude Codeへ移行する際、もしくはClaude Codeと他ツールを併用する際に見落としやすい互換性のチェック項目がいくつかあります。まず、Claude CodeはModel Context Protocol（MCP）を通じてSlack、Linear、Google Drive、GitHubなど多数の外部サービスとの連携をサポートしていますが、これらのコネクタ設定はツールごとに個別のセットアップが必要です。CursorやCopilotで使用していた拡張機能やプラグインがそのまま移行できるわけではありません。

SSH接続については、今回の刷新でmacOSからのSSH接続が新たに追加され、従来からサポートされていたLinuxと合わせて2プラットフォームでリモートマシンへのセッション接続が可能になりました。Windows環境でのSSH対応は現時点で公式に言及されていません。また、AWS Bedrock、Google Vertex AI、Microsoft Foundryを経由してClaude Codeを利用している場合、アクティビティダッシュボードやRoutinesなど一部機能がclaude.aiの直接アカウントでのみ利用可能となっている点も見落とされがちな制約です。移行前に現在の開発環境で使用しているサービス連携、SSH接続、クラウドプロバイダ経由の利用状況を棚卸しし、Claude Code側で対応可能かどうかを一つずつ確認するプロセスが不可欠といえるでしょう。

Pro・Max・Team・Enterpriseの各プランで異なる利用上限と費用対効果

Claude Codeの料金体系は、月額サブスクリプションとAPI従量課金の2系統が併存する構造になっており、開発者の利用パターンによって最適な選択肢が大きく変わります。今回のデスクトップ刷新とRoutines導入により、各プランの実質的な価値も変化しているため、現在のプラン選択を改めて見直す良い機会です。ここでは、Pro・Max・Team・Enterpriseの各プランについて、利用上限・Routines実行制限・費用対効果を具体的な数値とともに整理します。

月額20ドルのProプランで対応できる1日あたりの作業量と制約の目安

Proプランは月額20ドルで、Claude Codeのターミナル利用、ファイル生成とコード実行、プロジェクト管理、Google Workspace連携、リモートMCPコネクタ、そして拡張推論モデルへのアクセスが含まれるプランです。トークン使用量は5時間ごとのローリングウインドウでリセットされ、おおむね5時間あたり45メッセージ相当の利用が可能とされています。1日に1〜2回の集中セッションで完結する開発スタイルであれば、このプランの枠内で十分に運用できる水準です。

ただし、Claude Codeのセッションは通常のチャットと比較してトークン消費量が大きい点には留意が必要です。大規模なシステム指示やファイルコンテキスト全体の送信、複数ステップにわたる自律的な処理が発生するため、1セッションあたりのトークン消費は一般的なチャット利用の数倍に達することがあります。マルチセッション機能で4つのタスクを並列に走らせた場合、5時間のリセット枠を想定以上の速さで消費する可能性があるため、並列運用を本格的に行う場合はMaxプランへの移行を検討する判断基準になるでしょう。

Max 5x・20xプランの月額100〜200ドルで得られるトークン上限の拡張幅

Maxプランには月額100ドルの5xティアと月額200ドルの20xティアの2段階が用意されています。5xティアではPro比で5倍のトークン使用量が確保され、20xティアでは20倍に拡張されます。マルチセッション機能を日常的に活用し、複数のリポジトリにまたがる作業を並列で回す開発者にとっては、5xティアが最初の検討対象になるでしょう。月間のトークン消費量が約5,000万トークンを超える水準であれば、API従量課金よりも5xプランの方がコスト効率が高くなるとされています。

20xティアは、Claude Codeをほぼ終日にわたって稼働させるヘビーユーザー向けの選択肢です。Opusクラスのモデルを用いた長時間の自律セッションを複数並列で実行し、さらにRoutinesによる自動化タスクも高頻度で回す場合、20xティアの枠でもなお上限に到達する可能性はありますが、同等のトークン量をAPI従量課金で消費した場合と比較すると月額数千ドル単位のコスト削減になる計算です。新機能の優先アクセスも含まれているため、最新機能をいち早く試したい開発者にとっての付加価値もあります。

Routinesの日次実行上限がProで5回・Maxで15回と異なるプラン別制限

Routinesの実行にはプランごとの日次上限が設定されています。Proプランでは1日あたり5回、Maxプランでは15回、TeamまたはEnterpriseプランでは25回が基本的な上限です。この日次上限を超えた実行については、追加使用量として別途課金される仕組みになっています。Routinesの実行はインタラクティブセッションと同じサブスクリプション使用量から消費されるため、Routinesの自動実行が多いほど、手動の対話セッションに使える枠が減少する点にも注意が求められます。

Proプランの1日5回という上限は、毎晩1回のイシュートリアージと、PRオープン時のコードレビュー数回で概ね消費される水準です。Routinesを本格的に運用して開発ワークフローの自動化を推進したい場合は、Maxプランの15回枠がより現実的な選択肢になります。なお、CLIで従来使用していた/scheduleコマンドのタスクは自動的にRoutinesへ移行されるため、移行後に想定外のRoutines実行が発生して日次上限を圧迫していないかを初期段階で確認しておくことが重要です。

API従量課金とサブスクリプション定額制で月額コストが逆転する損益分岐点

Claude Codeにはサブスクリプションプランとは別に、API従量課金で利用する選択肢も存在します。APIの場合はトークン単価がモデルごとに設定されており、たとえばSonnet 4.6は入力100万トークンあたり3ドル・出力100万トークンあたり15ドル、Opus 4.6は入力100万トークンあたり5ドル・出力100万トークンあたり25ドルという料金体系です。月間のトークン消費量が少ない場合はAPIの方が安くなり、一定量を超えるとサブスクリプションの方が割安になる構造です。

損益分岐点はモデルの選択と使用パターンによって変動しますが、目安としてSonnet 4.6を主軸に月間で入力100万トークン＋出力50万トークン程度の利用であれば、API料金は約10.50ドルとなりProプランの20ドルを下回ります。しかし、Claude Codeのセッションはファイルコンテキスト全体の送信を伴うためトークン消費が急速に増加しやすく、日常的にClaude Codeを使うのであればProプランの定額枠を超過してAPI従量課金に移行するパターンが多くの開発者にとって最もコストが高くつくケースです。自分の月間トークン消費量をまず計測し、その数値に基づいてプラン選択を行うアプローチが最も合理的といえるでしょう。

TeamとEnterpriseで追加される管理者向け機能と組織利用時の選定基準

個人利用ではなくチームや組織単位でClaude Codeを導入する場合、TeamプランとEnterpriseプランが選択肢に入ります。Teamプランには2種類のシートが用意されており、Standardシートは月額25ドル、Claude Codeが利用可能なPremiumシートは月額125ドル（いずれも月払いの場合）という料金体系です。最低5シートからの契約となり、一元的な請求管理、共有プロジェクト設定、チームメンバー間でのClaude Code利用環境の統一が可能で、StandardとPremiumのシートを混在させる運用にも対応しています。使用量の上限は個人単位で適用されるため、特定のメンバーが大量にトークンを消費しても他のメンバーの利用枠には影響しない設計です。

Enterpriseプランはカスタム見積もりとなり、SSO（シングルサインオン）、監査ログ、管理者向けのトークン消費量モニタリングダッシュボード、プロジェクト単位の予算設定、ユーザーごとのレート制限設定などが追加されます。2026年4月のアップデートで追加されたRoutinesについても、Enterpriseプランでは日次25回の上限に加えてチーム全体のRoutines管理画面が提供されます。組織利用での選定基準としては、メンバー数が10名未満でガバナンス要件が軽い場合はTeam、セキュリティポリシーやコンプライアンス要件が厳格な組織はEnterpriseが妥当な選択です。

既存ワークフローへの導入手順と初期設定で押さえるべき実務ポイント

Claude Codeデスクトップの刷新版を実際に導入し、Routinesを含めた新機能を日常のワークフローに組み込むには、いくつかの初期設定と確認作業が欠かせません。インストール自体は簡単ですが、GitHub Appの設定漏れやクラウドプロバイダ経由での機能制限など、つまずきやすいポイントが複数存在する点に注意が必要です。ここでは、ダウンロードから初日の運用開始までの一連の流れを実務的な視点で整理していきましょう。

claude.com/downloadからのインストールと自動アップデートの適用手順

刷新版デスクトップアプリのインストールは、claude.com/downloadにアクセスして対応OS（macOSまたはWindows）のインストーラをダウンロードするだけで完了します。既にClaude Codeデスクトップアプリを使用しているユーザーの場合は、自動アップデートによって新バージョンが配信されるため、手動でのダウンロードは不要です。アプリを起動すると、初回から新しいサイドバーが表示され、マルチセッション管理がすぐに利用可能な状態になります。

インストール後の初期設定として推奨されるのは、まずリポジトリの接続確認です。既存のプロジェクトが正しく認識されているか、サイドバーにプロジェクト名が表示されるかを確認します。次に、ペインレイアウトのカスタマイズを行い、自分の作業スタイルに合った画面配置を構築しておくと、本格運用時の効率が向上します。表示モードの初期設定もこの段階で済ませておくとよいでしょう。メインセッション用にNormalまたはVerbose、バックグラウンド監視用にSummaryを設定しておくと、マルチセッション運用への移行がスムーズになります。

CLIの/scheduleコマンドからRoutinesへの既存設定の自動移行の確認方法

従来からCLIの/scheduleコマンドを使ってタスクの定期実行を設定していたユーザーにとって重要なのが、既存設定のRoutinesへの自動移行です。Anthropicはこの移行を手動操作なしで自動的に行うと公式に案内しており、既存の/scheduleタスクはRoutinesに変換された状態で引き継がれる仕組みです。移行が正しく完了したかどうかは、claude.ai/code/routinesのWeb画面で確認できるため、初回は必ず目視で検証しておきましょう。

確認すべきポイントは3つあります。第一に、移行されたRoutineのプロンプト内容が元の/schedule設定と一致しているかどうかです。第二に、トリガーの種類と実行頻度が意図した通りに設定されているかを確認します。第三に、コネクタ（Slack、GitHub等）の接続が有効な状態で維持されているかのチェックです。自動移行の過程でコネクタの認証が切れていると、Routineは実行されるものの外部サービスへの通知やPR作成が失敗するケースがあります。移行直後は最初の1〜2回の実行結果を手動で確認し、期待通りの出力が得られているかを検証する運用が安全策として推奨されます。

GitHub Appのインストール漏れで発生するWebhookトリガー未発火の対処法

RoutinesのGitHubトリガーを設定したにもかかわらず、PRの作成やマージに反応してRoutineが起動しないトラブルで最も頻繁に報告されている原因が、Claude GitHub Appのインストール漏れです。CLIで/web-setupコマンドを実行してリポジトリへのクローンアクセスを設定する手順と、GitHub Appをインストールしてイベント通知を有効にする手順は別々のプロセスであり、前者だけ完了して後者を見落とすケースが非常に多いのが実情です。

対処法としては、まずclaude.ai/code/routinesのWeb画面からRoutineの編集画面を開き、トリガーセクションのGitHub設定でアプリのインストール状態を確認してください。インストールが未完了であれば、画面上のプロンプトに従ってClaude GitHub Appをリポジトリにインストールし、必要なイベントの通知許可を付与する作業が必要です。インストール済みにもかかわらず発火しない場合は、フィルタ条件が厳しすぎてイベントが除外されている可能性があるため、条件を一時的に緩和してテストPRで動作確認を行う方法が有効です。GitHubトリガーの設定はRoutines運用で最もつまずきやすい工程であるため、初回セットアップ時に動作検証まで確実に完了させておくことが安定運用の基盤になります。

Bedrock・Vertex AI経由の利用で制限される機能と設定上の注意事項

Claude Codeは、Anthropic直接のclaude.aiアカウントに加えて、AWS Bedrock、Google Vertex AI、Microsoft Foundryを経由した利用にも対応しています。デスクトップアプリの基本機能であるマルチセッション管理やドラッグ＆ドロップレイアウトは、いずれの接続方式でも利用可能です。ただし、クラウドプロバイダ経由の利用では一部の機能に制限がかかる点を事前に把握しておく必要があります。

具体的には、アクティビティダッシュボード（セッション数やトークン消費量の可視化）とRoutinesのクラウド実行は、claude.aiの直接アカウントでのみ利用可能な機能です。Enterprise契約でサードパーティクラウドを利用している組織では、管理者がどの機能が有効化されているかをAnthropicまたはクラウドプロバイダの担当者に確認する必要があります。既にBedrock経由でClaude Codeを運用しているチームがRoutinesの導入を検討する場合、Routines用にclaude.aiの直接アカウントを別途契約するか、Bedrock上でRoutines相当の自動化をAWS Lambda等で自前構築するかの判断が求められます。組織のセキュリティポリシーやデータガバナンス要件を踏まえた上で、適切な利用形態を選択することが重要です。

初日に試すべきマルチセッション×Routinesの組み合わせワークフロー例

導入初日に新機能の効果を体感するために推奨されるのが、マルチセッション管理とRoutinesを組み合わせた実践的なワークフローの構築です。まず、デスクトップアプリで2つのセッションを並列に開き、一方でバグ修正、もう一方でテスト追加というシンプルな2タスクの並列運用を試してみてください。2セッション程度であれば、トークン消費もProプランの枠内で十分に収まる水準です。

1. セッション1を開き、既知のバグに対する修正をClaudeに依頼する
2. セッション1の応答待ちの間にCmd+Nで新規セッション2を開き、テストの追加を依頼する
3. 完了した方からレビューを開始し、統合ターミナルでテストを実行して結果を確認する
4. 確認が完了したらPRを作成し、セッションが自動アーカイブされることを確認する

並行してRoutinesの初期体験として、PRオープン時にコードレビューコメントを自動投稿するGitHubトリガーRoutineを1つ設定してみましょう。プロンプトにはチームのコーディング規約の要点を記載し、先ほどのバグ修正PRに対してRoutineが自動的にレビューコメントを投稿するかを検証します。この一連の流れを30分程度で体験することで、マルチセッションによる並列作業の効率向上と、Routinesによるレビュー自動化の両方を具体的にイメージできるようになるでしょう。

リサーチプレビュー段階の制約と今後のアップデートで注目すべき拡張予定

今回のデスクトップ刷新とRoutinesの発表は、Claude Codeの進化における大きな節目ですが、いずれもまだ発展途上の段階にある点は押さえておくべきでしょう。特にRoutinesはリサーチプレビューという位置づけであり、本番環境での全面採用には慎重な判断が求められる状況です。ここでは、現時点で認識しておくべき制約と、Anthropicが今後の方向性として示唆している拡張の可能性を整理していきましょう。

Routinesがリサーチプレビューである現時点で注意すべき出力品質のばらつき

Routinesは2026年4月14日時点でリサーチプレビューとして提供されており、正式リリース版ではないことを前提に運用する必要があります。リサーチプレビュー段階で最も注意すべきリスクは、実行ごとの出力品質にばらつきが生じる可能性がある点です。同一のプロンプトとリポジトリ設定で繰り返しRoutineを実行しても、バックエンドのモデル更新や処理環境の変化によって結果が異なるケースも報告されている状況です。

このばらつきは、特に本番環境に影響を及ぼすタスクでは深刻な問題を引き起こしかねません。Routinesの公式ガイドラインでも、自動的にproductionへの変更をプッシュするのではなく、「証拠と推奨事項を提示する」レベルに留めることが推奨されています。具体的には、Routineの出力をドラフトPRやSlack通知として人間のレビューに回し、最終的な適用判断は人間が行うフローを設計するのが安全です。リサーチプレビュー期間中は実行ログを定期的に確認し、出力の品質が自チームの基準を満たしているかをモニタリングし続ける運用体制を整えておくことが実務上の必須事項といえるでしょう。

本番ブランチへの自動プッシュを防ぐclaude/プレフィクス制限の安全設計

Routinesにおける安全設計の中核が、ブランチ名のclaude/プレフィクス制限です。デフォルトの設定では、Routinesがプッシュ可能なブランチはclaude/で始まるブランチに限定されており、mainブランチやreleaseブランチへの直接的な変更は物理的にブロックされます。この制約は、誤ったプロンプト設定やモデルの予期しない挙動によって、本番コードに意図しない変更が適用されるリスクを最小化するためのガードレールです。

実運用においては、Routineがclaude/fix-issue-123のような命名規則でブランチを自動作成し、そのブランチからPRを作成するフローが標準的なパターンになります。PRの段階で人間がレビューとマージの判断を行うため、完全な自動化ループにはならないものの、作業の大部分をRoutineに委任しつつ最終判断は人間に留保できるバランスの取れた設計です。将来的にRoutinesの信頼性が向上した段階でプレフィクス制限が緩和される可能性もありますが、現時点ではこの制約を安全ネットとして積極的に活用し、Routine出力は必ずPR経由でレビューする運用ルールを徹底することが推奨されます。

Linux版デスクトップアプリの追加時期とCLI版との機能差の現状

初期リリースの段階でLinuxデスクトップ版が提供されていない点は、Linux環境を主力の開発プラットフォームとしている開発者にとって最も大きな制約です。Anthropicは数週間以内のLinux版追加を公式に案内していますが、具体的なリリース日は公表されていません。Linux環境のユーザーは、当面はCLI版のClaude Codeを引き続き使用する形になり、マルチセッション管理のGUI、ドラッグ＆ドロップのペイン配置、統合ターミナルといったデスクトップ固有の新機能は利用できない状態が続きます。

ただし、CLI版自体はLinuxを含む全プラットフォームで引き続きフル機能が利用可能であり、Routinesの作成や管理もCLIから/scheduleコマンドで行えます。Routinesのクラウド実行はサーバー側で処理されるため、ローカルOSの違いによる影響はありません。したがって、Routinesを中心とした自動化ワークフローの構築はLinux環境でも即座に着手可能です。デスクトップ版の追加を待つ間に、CLIベースでRoutinesの運用を先行させておくことで、Linux版がリリースされた際にスムーズにGUIワークフローへ移行できる体制を整えておく戦略が合理的です。

トークン消費量の増加傾向に対するProプラン上限引き上げの可能性

マルチセッション機能とRoutinesの導入により、Claude Codeの1ユーザーあたりのトークン消費量は従来よりも増加する傾向にあると複数の利用者が報告しています。4つのセッションを並列で走らせれば、単純計算で従来の4倍のトークンが消費されることになり、Proプランの5時間リセット枠を早期に使い切るケースが増加している状況です。開発者コミュニティでは、Anthropicがプランの上限を調整するか、あるいはトークン消費を最小化するための運用ノウハウが確立されるかが注目点となっているようです。

すでにコミュニティ内では、不要なファイルコンテキストの送信を削減する設定方法や、SummaryモードとVerboseモードを切り替えることでトークン消費を抑えるテクニックが共有され始めました。Anthropic側も今後のプラン改定でProプランの枠を拡大する可能性がありますが、公式な言及はまだありません。現時点では、自分のトークン消費量をアプリ内の使用量ボタンで定期的にモニタリングし、Proプランの枠で収まらない場合はMax 5xへの移行を検討するのが実際的な対応策です。月間のトークン消費量を2〜3週間計測した上で判断を下すアプローチが、無駄な出費を避けるうえで最も確実でしょう。

Ultra Planやマルチエージェント連携など公式が示唆する将来の拡張方向

Anthropicは今回のアップデートと前後して、Claude Codeの将来像についていくつかの示唆を与えている点にも注目すべきでしょう。その一つが「Ultra Plan」と呼ばれる上位プランの存在で、通常のプランニング機能を超えた高度なアーキテクチャ決定支援を提供するものとされる上位機能です。また、複数のAIエージェントが異なるタスクを自律的に分担し、相互に連携しながらプロジェクト全体を推進するマルチエージェント連携の構想も、将来の方向性として言及されました。

これらの拡張が実現すれば、Claude Codeは単一のAIコーディングアシスタントから、プロジェクト運営全体を統合管理するAIオペレーションプラットフォームへとさらに進化する道筋が描かれていると読み取れるでしょう。ただし、いずれもまだ正式な機能発表やリリース時期の公表には至っておらず、現時点では可能性の段階にとどまっている点を認識しておく必要があります。開発者として現実的にできることは、まずは今回の刷新版デスクトップとRoutinesを使いこなすことに注力し、新機能が発表された際にすぐ対応できる知識的な基盤を築いておくことです。6か月後の開発環境がどう変わっているかは未知数ですが、並列セッション管理とクラウド自動化というパラダイムが今後のAIコーディングツールの標準になっていく方向性は、今回のアップデートで明確に示されたといえるでしょう。