Amazon CodeCatalystは終了した？新規受付終了の事実と移行先の選び方

Amazon CodeCatalystの公式サービスページを開くと、本文より先に新規受付終了の告知が目に入ります。ただし「新規受付終了」と「サービス終了」は違います。既存スペースは2026年8月現在も動いており、終了日は公表されていません。この記事では、AWSが2025年10月に発表した内容を公式ドキュメントで確認したうえで、既存ユーザーが移行を判断する材料と、リポジトリを実際に移す手順を整理します。

まとめ：2026年8月時点のCodeCatalystの状態

• 2025年11月7日以降、新規顧客は利用できません。既存顧客は既存スペースを使い続けられますが、新しいスペースは作成できません。
• AWSはセキュリティ・可用性・パフォーマンスの向上には投資を続けるとしていますが、それ以外の新機能を導入する予定はないと明言しています。
• 既存顧客向けのサービス停止日は、AWSから発表されていません。「いつまでに出ろ」という期限は現時点で存在しません。
• AWSが案内する移行先は、GitLab Duo with Amazon Q（2025年4月17日にGA）と、CodeBuild・CodePipeline・CodeDeploy・CodeArtifactの各サービスです。

期限が切られていないぶん判断は先送りできますが、新機能が止まった基盤に依存が積み上がるという意味では時間が味方をしません。以下、事実関係、料金、機能ごとの移行先の順に見ていきます。

2025年11月7日の新規受付終了で実際に変わったこと

公式発表の内容と、既存スペースに残る3つの制約

AWSは移行ガイドの冒頭で、CodeCatalystへの新規顧客アクセスを2025年11月7日付で閉じたと記載しています。既存顧客への影響は、同じ文中に条件付きで書かれています。既存スペースの利用は継続できる一方、新しいスペースは作成できません。加えて、セキュリティ・可用性・パフォーマンスの強化を除いて新機能を導入する予定はない、と明記されています。

この3点を実務に落とすと、既存スペースが器として固定されるということです。組織再編で新しいスペースを切りたい、別部門用に分けたい、といった要求には応えられません。既存スペース内でのプロジェクト追加は可能ですが、器そのものを増やす道は閉じています。

「終了」との違いと、終了日が未公表であることの読み方

SERPの関連質問に「CodeCatalystは終了したのですか？」が並ぶとおり、この混同が最も多い誤解です。AWSの発表は新規顧客の受付停止であって、サービス廃止のアナウンスではありません。2026年8月時点で、既存顧客に対する停止日・データ削除期限のいずれも公表されていません。

ただし、期限が無いことを安心材料に読み替えるのは誤りです。AWSは同じ時期の発表で、AWS Protonのようにサポート終了日まで示したものと、CodeCatalystのように新規停止にとどめたものを分けています。Protonの公式ドキュメントには「2026年10月7日にサポートを終了し、以後コンソールにもリソースにもアクセスできなくなる」と明記されました。後者が前者に移行しない保証はどこにもありません。新機能が止まった時点で、CodeCatalyst固有の機能に業務プロセスを新しく寄せる合理性は消えています。

料金体系と、移行後も課金が残る箇所

サブスクリプションのティアは、管理者ガイドに Free・Standard・Enterprise の3つが記載されています。ただし公開料金ページ（aws.amazon.com/codecatalyst/pricing/）は、2026年8月16日時点で英語版・日本語版とも404を返します。現在の単価を確認する手段は、スペースのBillingタブと請求先AWSアカウントの請求書だけです。他社記事に残っている月額表は、AWSがすでに公開をやめた値なので、そのまま見積もりの根拠にしないでください。

課金設計で見落とされやすいのは次の2点です。1つは、Free tierの範囲内でも全スペースに請求先AWSアカウントの指定が必須である点。もう1つは、Free tierの上限に達するとスペース全体のサービスが停止しうる点で、これは管理者ガイドが例示として明記しています。

移行時にさらに注意が要るのは、CodeCatalystのコンソール経由で他のAWSサービスやサードパーティに作ったリソースです。スペースを削除してもCodeCatalyst側のデータが消えるだけで、そこから作られた外部リソースは各サービス側で止めない限り課金が続きます。移行完了とコスト停止は別作業だと考えてください。

機能別の移行先と、AWSネイティブに残すかの判断

ソースリポジトリ：GitLabかGitHubへのインポート

AWSの移行ガイドは、CodeCatalystのGitリポジトリURLとHTTPS用の認証情報を使い、GitLabのURLインポートまたはGitHub Importerで取り込む方法を第一に案内しています。AWS内で完結させたい場合は、いったん新規受付が停止されていたAWS CodeCommitが2025年11月24日にGA復帰しているため、こちらも選択肢に戻っています。

ワークフロー：CodePipelineとGitHub Actionsの選択軸

判断軸は、デプロイ先がAWSに閉じているかどうかです。デプロイ対象がAWSリソースだけで、IAMロールやVPCエンドポイントで権限と経路を締めたい場合は、AWS CodePipelineとCodeBuildの組み合わせが素直です。一方、コードレビューとCIを同じ画面で回したい、あるいはAWS以外にもデプロイ先がある場合は、GitHub ActionsからOIDCでAWSへ権限を渡す構成のほうが運用が軽くなります。CodeCatalystのワークフローYAMLはそのままでは移植できないため、どちらを選んでもジョブ定義は書き直しになります。

Dev Environments：後継不在とIDE Toolkits・CloudShellへの退避

ブラウザやIDEから接続するクラウド開発環境という点で最も近かったAWS Cloud9も、すでに新規顧客への提供を終えています。Cloud9の公式ドキュメントが案内する移行先は、各エディタ向けのAWS IDE ToolkitsとAWS CloudShellです。CodeCatalyst Dev Environmentsの「リポジトリと紐づいた使い捨て環境」をそのまま置き換えるAWSサービスは存在しません。同等の運用を続けたいなら、GitHub CodespacesやGitLabのWorkspacesなど、リポジトリ側の機能に寄せる形になります。

Issues：一括エクスポート不可と手作業転記の工数

CodeCatalystのIssues機能に相当するプロジェクト管理はAWSのサービス群に含まれません。しかも移行の逃げ道が最も狭いのがこの領域です。AWSの移行ガイドがIssues関連で案内しているのは添付ファイルの個別ダウンロードだけで、チケット本文やコメントの一括エクスポート機能はありません。公開APIも同様で、CodeCatalyst APIリファレンスに載る38のオペレーションはスペース・プロジェクト・リポジトリ・ワークフロー・Dev Environmentに関するもので占められ、Issueを読み書きするオペレーションは1つも定義されていません。スクリプトで吸い出す前提の移行計画は立てられないため、GitHub IssuesやJiraへ移すなら手作業での転記を工数に織り込んでください。

リポジトリ移行とスペース削除の実手順

ミラークローンによる全ブランチ・タグの移送

AWSが示す汎用手順は、ミラークローンで丸ごと取得し、移行先をリモートに追加してミラープッシュする流れです。下記の手順をGit 2.50.1で実行したところ、ブランチ2本とタグ1件が移行先の空リポジトリへ欠けずに渡りました。

git clone --mirror https://git-codecatalyst.us-east-2.amazonaws.com/v1/repos/MyDemoRepo my-demo-repo
cd my-demo-repo
git remote add gitlab https://gitlab.example.com/your-group/my-demo-repo.git
git push gitlab --mirror

移行先リポジトリは空である必要があります。また、移行先にブランチ保護が設定されているとミラープッシュが強制プッシュとして弾かれるため、保護を一時的に外してから実行してください。押し込んだあとは、ブランチとタグが欠けていないかクローンし直して照合します。

アーティファクトと添付ファイルの個別ダウンロード

Gitの履歴に含まれないデータは、コンソールから個別にダウンロードする必要があります。対象は3種類。ワークフローの実行結果はランごとにArtifactsから取得でき、実行開始時点のソースを固めたソースアーティファクトと、ワークフロー定義のOutputsで指定したワークフローアーティファクトに分かれています。Issueの添付ファイルは各Issueの添付メニュー、独自アクションのソースコードはアクション詳細のダウンロードが取得口になります。

スペース削除と課金停止の実行順序

スペースの削除にはSpace administratorロールが必要で、削除すると復元できません。自分で操作せず、CodeCatalystコンソールのSupport Center経由でサービスチームに削除を依頼することもできます。順序としては、外部サービス側のリソース停止を先に済ませ、抽出物の検証が終わってからスペースを消すのが安全です。逆順にすると、どのリソースがCodeCatalyst由来だったかを追う手掛かりが消えます。

2025年11月7日に一斉に閉じた開発者向けサービスと、CodeCommitだけが戻った差

CodeCatalystの新規停止は単発の判断ではありません。同じ2025年11月7日を境に、Amazon CodeGuru Reviewerも新しいリポジトリ関連付けを作成できなくなっています。AWS Cloud9はそれ以前から新規顧客への提供を終えていました。AWSの開発者向けサービスのうち、統合型・付加機能型のものがまとめて縮小された形です。

対照的なのがCodeCommitです。2024年7月25日にいったん新規受付を停止しながら、2025年11月24日のAWS DevOpsブログでGA復帰が発表され、新規顧客もその場からリポジトリを作成できるようになりました。CodeCatalystが閉じた17日後の出来事です。

この差はサービスの人気ではなく、代替可能性の差だと考えるのが妥当です。CodeCommitはIAM連携・VPCエンドポイント・CloudTrailという、規制業種がAWS内で完結させる必要のある性質を持ち、外部SaaSでは置き換えられません。CodeCatalystが提供していたリポジトリ、CI、Issue、開発環境の統合体験は、GitHubやGitLabがすでに満たしています。AWSが自前で持ち続ける理由が薄かった機能から閉じていった、と読むほうが実態に合います。

したがって、これから新規にAWS上でCI/CDを組む場合、CodeCatalystの後継を探す発想は捨ててください。ソース管理は既存のGitホスティングに寄せ、ビルドとデプロイだけAWSネイティブに置く構成が、現時点で最もサービス終了リスクの低い組み合わせです。逆に、統合体験そのものを重視して単一ベンダーに寄せる設計は、今回のように上位レイヤーから縮小されたときに移行コストが集中します。GitHubとGitLabのどちらを土台にするかを先に決め、AWS側はビルドとデプロイの実行基盤に絞るのが実務的です。

よくある質問

CodeCatalystは終了したのですか？

サービス終了ではありません。2025年11月7日以降、新規顧客が利用できなくなっただけで、既存顧客は既存スペースを使い続けられます。既存顧客向けの停止日はAWSから公表されていません。ただし新機能の追加予定は無いとAWSが明言しているため、機能面での改善は期待できません。

Amazon CodeCatalystとは何ですか？

ソースリポジトリ、CI/CDワークフロー、Issue管理、クラウド上の開発環境（Dev Environments）を1つのスペースにまとめたAWSの統合開発サービスです。ブループリントからプロジェクト雛形を生成し、リポジトリからデプロイまでをAWS内で完結させる位置づけでした。新規受付終了により、これから採用できるサービスではなくなっています。

Amazon CodeCatalystの料金はいくらですか？

サブスクリプションは Free・Standard・Enterprise の3ティアですが、公開料金ページは2026年8月16日時点で404を返し、AWSは単価を公開していません。現在の料金はスペースのBillingタブとAWSの請求書でのみ確認できます。なお、Free tierの範囲内でも請求先AWSアカウントの指定は必須で、上限に達するとスペースのサービスが停止する場合があります。

移行先としてAWSが公式に案内しているサービスは何ですか？

移行ガイドが名指ししているのは、2025年4月17日にGAとなったGitLab Duo with Amazon Qです。サービスページではCodeBuild、CodePipeline、CodeDeploy、CodeArtifactにも誘導しています。リポジトリの移行先としてはGitLabとGitHubの取り込み手順が具体的に示されており、AWS内で完結させたい場合はGA復帰したCodeCommitも選べます。

CodeCatalystのワークフロー定義はそのまま移行できますか？

できません。CodeCatalystのワークフローYAMLは独自形式で、GitHub ActionsやCodePipelineの定義形式と互換性がありません。アクションのソースコードはコンソールからダウンロードできますが、移行先での実行にはジョブ定義の書き直しが必要です。移行工数を見積もる際は、リポジトリのミラー移行よりワークフローの再実装のほうが大きいと考えてください。

関連記事

• AWS CodePipelineとは？仕組み・料金・V1/V2の違いと構築手順を解説
• GitHub ActionsとTerraformでAWSのCI/CDを構築する手順（OIDC・S3ネイティブロック対応）
• GitHubとGitLabの違いを比較｜CI/CD・セキュリティで選ぶ判断基準
• CI/CDとは？仕組み・パイプライン・導入すべき企業の判断基準を解説