Summer '25 で認定 Heroku アーキテクト資格を更新する
学習の目的
この単元を完了すると、次のことができるようになります。
- Heroku のレガシールーターから Router 2.0 への移行について説明する。
- Heroku VS Code 拡張機能を使用して、開発ワークフローを効率化する。
- Heroku Data for Redis から Heroku Key-Value Store への改称に対応する。
- 新しいビルドパックを活用して、Heroku に .NET アプリをリリースして管理する。
- 次世代のプラットフォームである Heroku Fir にアプリを移行する。
- AI 駆動型アプリ向けの Heroku Inference (MIA) と MCP を実装する。
- Heroku CLI を使用して、アプリの SSL/TLS 証明書を管理する。
- Automated Certificate Management (ACM) に対する最近の更新とサポートされている機能について説明する。
認定資格を更新する
認定 Heroku アーキテクト資格を保有している場合、その認定資格を維持するためには期日までにこのモジュールを修了する必要があります。
この資格の取得を検討している方は、「認定 Heroku アーキテクト」資格を参照してください。
このバッジは誰でも取得できますが、このモジュールは認定 Heroku アーキテクトの有資格者を対象としています。
認定資格の信頼性を守る
Salesforce は、質の高い認定試験と価値ある資格を提供することを最優先事項としています。試験のセキュリティと機密の保護は、業界をリードする評価の高い認定資格をお客様に提供するために不可欠です。
Salesforce 認定資格プログラムに参加する場合は、「Salesforce 認定資格プログラム同意書」に同意いただく必要があります。詳細は、Trailhead ヘルプ記事「Salesforce 認定資格プログラム同意書および行動規範」に記載の Salesforce 認定資格試験の受験ポリシーを確認してください。
この 1 年間にすばらしい機能強化が導入されています。その中で特に重要なものについて説明します。
レガシールーターの EOL と Router 2.0
Cedar フレームワークへの移行の一環として、長年使用されてきたレガシールーターの後継となる Router 2.0 が導入され、Heroku の HTTP ルーティングアーキテクチャが大幅に変更されています。Heroku の Common Runtime 環境において、この更新は近年でも特に重要なバックエンドインフラストラクチャの移行であり、パフォーマンス、信頼性、オブザーバビリティ、長期的なメンテナンス性の向上につながります。
レガシールーターは非推奨になり、2025 年の春にサポートが終了 (EOL) しました。したがって、このルーターに依存していたアプリは現在サポートされていません。
Router 2.0 に移行すると、リクエストのキューイングが強化され、負荷分散の動作が改善し、トラフィックのデバッグや監視のメトリクスが向上します。また、このルーターは、地域別ルーティングのサポート強化や TLS ターミネーションの高速化など、将来のネットワークに関連する機能強化の基盤となり、次の機能をサポートします。
機能 | レガシールーター | Router 2.0 | 備考 |
|---|---|---|---|
x | x | TLS ターミネーションなど、基本的なルーティングがサポートされています。 | |
x | x | リクエストごとのルーターログがアプリのログストリームに表示されます。 | |
x | x | 大半の H コードがサポートされ、ルーターログに記録されます。現在、例外は H23 と H26 のみです。 | |
x | x | Eco dyno で dyno のスリープ (アイドル状態) がサポートされています。 | |
x | x | 各ルーターがアプリごとの内部リクエストカウンターを保持し、アプリごとに同時リクエスト数を制限します。 | |
x | x | Heroku のヘッダーは、Heroku が HTTP 応答に追加するヘッダーのセットです。 | |
x | x | WebSockets プロトコルは両方のルーターでサポートされています。 | |
x | x | Expect: 100-continue ヘッダーは両方のルーターでサポートされています。 | |
x | x | ルーターが到達不能な dyno を隔離します。 | |
x | x | Preboot リリース動作は両方のルーターで機能します。 | |
x | x | エンドユーザーから受信したすべての HTTP リクエストを Web dyno に関連付けます。 | |
x | HTTP/2 は Router 2.0 でのみ使用できます。 | ||
x | ルーターと dyno 間の HTTP キープアライブをサポートするのは Router 2.0 のみです。 | ||
IPV6 | Router 2.0 のみに追加される予定です。 |
Heroku アーキテクトは、技術面と運用面の両方からこの変更を理解することが不可欠です。Router 2.0 が接続の再利用やリクエストのキューイングをどのように処理するかによってアプリの動作が異なることがあります。そのため、特にリクエスト量が多いアプリやトラフィックのパターンに時間的な制約があるアプリでは、移行後に回帰テストを実施することをお勧めします。
詳細は、「Router EOL FAQ (ルーターの EOL に関する FAQ)」や Router 2.0 のドキュメントを参照してください。
Heroku VS Code 拡張機能
Visual Studio Code 向け Heroku 拡張機能を使用すると、Heroku プラットフォームにおける開発者の生産性が大きく向上します。VS Code 環境内で直接、統合型エクスペリエンスが実現するため、開発者やアーキテクトはエディターを開いたまま、アプリの管理、変更のデプロイ、パフォーマンスの監視を行うことができます。
つまり、次のことが可能になります。
- VS Code 内で直接 Heroku アプリ、dyno、アドオンを管理する。
- VS Code のターミナルまたはコマンドパレットから Heroku CLI コマンドを実行する。
- コンテキストを切り替えることなく、Heroku アドオンを表示、追加、削除する。
- VS Code からワンクリックでアプリをデプロイする。
- VS Code や、Salesforce コードビルダー、Cursor、Windsurf のようなフォークなど、サポートされている IDE を使用する。
インストール手順や機能の詳細は、VS Code 向け Heroku 拡張機能のドキュメントを参照してください。
Heroku Key-Value Store (旧称 Heroku Data for Redis)
Heroku Data for Redis が Heroku Key-Value Store (KVS) に改称されました。単なる名称変更で、既存の KVS インスタンスやアプリに影響はありません。また、KVS のプロビジョニングや管理のコマンドにも変更はありません。機能的に、Heroku Key-Value Store は開発者が長年使用してきた Redis の管理サービスと同じです。
新しい名称のメリットの 1 つは、特に Salesforce アーキテクトがビジネス関係者に Heroku の機能を説明する際に明確に伝わることです。「Key-Value Store」であれば、このサービスが実施する内容と、スケーラブルなアプリ設計パターンに適合することが明白になります。
詳細は、「Heroku Key-Value Store」Changelog エントリを参照してください。
Heroku Fir: 次世代のプラットフォーム
Heroku Fir は、Private Spaces の導入以来、最も革新的な Heroku のプラットフォームです。Fir は Heroku の次世代のインフラストラクチャを体現するもので、パフォーマンス、信頼性、オブザーバビリティ、エンタープライズへの対応性を向上させるランタイムが再設計されています。今回、正式リリースされ、本番環境で使用できるようになりました。
Fir は Heroku の Cedar スタックと同等の機能を装備しながら、主要な機能強化も導入されています。Fir 上でアプリを実行すれば、起動時間の短縮、ビルドとデプロイの最新のパイプライン、クラウドネイティブビルドパック (CNB) のサポートといったメリットを得ることができます。CNB は従来のビルドパックに代わるもので、DevOps の最先端の実務に合わせて標準化された構成可能なビルドワークフローが付属します。
Fir ではさらに、OpenTelemetry と高度なオブザーバビリティツールのサポートが強化され、複雑な分散システムを簡単に計測して監視できます。この点は特に、Salesforce やサードパーティ API と緊密に統合するマルチサービスアプリを構築するアーキテクトに役立ちます。
また、コンプライアンスを重視する組織で必要性が高まっている地域別ネットワーキングやデータレジデンシーのサポートも強化されています。Fir を使用すれば、ネットワークポリシーやインフラストラクチャのスケーリングなど、Heroku でアプリのデプロイ環境をきめ細かく管理できます。
アーキテクトが最小限の中断でアプリを Cedar から Fir に移行できるように、専用の移行ガイドが用意されています。既存のアプリの大半は直接移植できますが、テストと環境検証を実施することを強くお勧めします。
Heroku の .NET サポート
Heroku が .NET サポートの正式リリース (GA) を発表しました。これは、プラットフォームの言語サポートエコシステムにおける大きなマイルストーンになっています。このリリースに伴い、開発者が正式にサポートされている統合ワークフローを使用して、.NET アプリを構築しデプロイできるようになりました。
.NET ビルドパックを使用すれば、ASP.NET Core や .NET 8+ アプリのスムーズなデプロイが可能になります。また、適切な .NET SDK が自動的に検出されインストールされます。C#、F#、Visual Basic を使用しているチームにとっては、立ち上げ時間が短縮し、Heroku の管理ランタイムモデルとの連携が強化されることになります。
さらに、Heroku でのビルドに .NET SDK バージョン 8.0.115、8.0.311、8.0.408、9.0.105、9.0.203 を利用できるようになりました。.NET 8.0 SDK には .NET Runtime と ASP.NET Core Runtime のバージョン 8.0.15 が付属し、.NET 9.0 SDK には両方のランタイムのバージョン 9.0.4 が付属します。
また、ビルドパックのプロセスタイプの命名規則も更新されています。.NET ビルドパックで、デフォルトのプロセスタイプに新しい命名形式が使用されるようになりました。Procfile が存在しない場合、自動的に検出されたプロセスタイプは小文字に変換され、スペース、ドット、アンダースコアがハイフンに置換されます。
Procfile を使用してプロセスタイプを定義するアプリには影響ありません。Heroku の Fir 世代にデプロイされたアプリは、すでにこの新しい形式に従っています。
ただし、Cedar 世代のアプリではプロセスタイプ名が変更されるときに、Web 以外の Worker dyno が削除されることがあります。今後 .NET プロジェクトファイル名から派生したプロセスタイプがどのような形式に従うかを示す数例をご紹介します。
プロジェクトファイル | 以前のプロセスタイプ | 新しいプロセスタイプ | 備考 |
|---|---|---|---|
EmailWorker.csproj | EmailWorker | emailworker | すべての文字が小文字に変換されます。 |
Email.Worker.csproj | Email.Worker | email-worker | ドットがハイフンに置換されます。 |
Email Worker.csproj | EmailWorker | email-worker | スペースがハイフンに置換されます。 |
Email_Worker.csproj | Email_Worker | email-worker | アンダースコアがハイフンに置換されます。 |
SDK バージョンの更新とビルドパックの変更については、「.NET GA」Changelog エントリと「.NET SDK version (.NET SDK バージョン)」Changelog を参照してください。
Heroku Managed Inference and Agents と Managed Compute Platform
Heroku は、「アプリのデプロイやスケーリングから複雑性を排除し、開発者がインフラストラクチャの管理ではなく、優れたソフトウェアの構築に専念できるようにする」というシンプルなアイデアに基づいて設立されました。
そして今、この同じ理念を AI にも適用しています。Heroku AI については、開発者が運用の複雑さに煩わされることなく、人工知能の威力を簡単に活用できるようにしています。私たちの最初のサービスである Managed Inference and Agents (MIA) は、Heroku 上の AI に対する戦略的なアプローチの基盤になるもので、開発者を念頭に考案されています。
Heroku MIA
Heroku MIA は、モデルのリアルタイムの推論を処理するように設計されており、アプリが API エンドポイント経由で予測と分類を行えるようになります。各自のモデルの用途がパーソナライズでも、レコメンデーションエンジンでも、自然言語処理でも、MIA の最小限の設定で推論エージェントをデプロイしてスケーリングできます。
Heroku Managed Inference があれば、お客様が重要視する領域で効果が得られるようにすることを目的に厳選された、強力で高性能な一連の生成 AI モデルに効率的にアクセスできます。選定されたモデルは、使いやすさと効果の両面から最適化されます。
AI モデルは Heroku アプリに簡単に統合できます。heroku ai:models:create というコマンド 1 つで、Heroku CLI からモデルをプロビジョニングできます。この操作で必要な環境変数が自動的に設定されるため、アプリが簡単にモデルに接続してやり取りできます。
テストや改良を容易にするために、CLI は heroku ai:models:call コマンドもサポートしています。このコマンドでターミナルから直接モデルを呼び出し、プロンプトの微調整、さまざまな入力の試行、AI インテグレーションのトラブルシューティングを簡単に行うことができます。
Managed Inference を基盤に構築された Heroku Agents は、一連のクリーンなプリミティブと操作を提供し、開発者が Heroku の信頼できる dyno 内でコードを実行できる AI エージェントを簡単に作成できるようにします。このエージェントはツールやアプリロジックを呼び出すこともできるため、ユーザーの代わりに有用なアクションを実行できます。開発者はこうした機能を活用して、Heroku の開発エクスペリエンスに自然に溶け込む一元的なプログラム型ワークフロー内で、アプリコード、AI 呼び出し、AI 生成ロジック、外部ツールのすべてをシームレスに組み合わせることができます。
Heroku MCP
待望の Heroku MCP Server がリリースされました。これは、エージェント駆動型の開発と Heroku の AI 搭載プラットフォームを結び付ける重要なステップです。Heroku がクラウドアプリのエクスペリエンスを刷新したように、私たちは現在、その同じシンプルさと威力を AI にも拡大しています。MCP Server を使用すれば、Heroku の堅牢なプラットフォーム機能を、AI エージェントが Model Context Protocol (MCP) 経由で呼び出すことができる直感的で構造化された一連のアクションとして利用できるようになります。
しくみ
Heroku MCP Server は開発者がすでに信頼している基盤、つまり Heroku CLI をその中核に使用しています。このサーバーは、バックグラウンドで実行エンジンとして機能し、CLI に組み込まれたコマンドオーケストレーションを使用して互換性と一貫性を確保します。
特に複雑なワークフローで速度と応答性を最適化するために、MCP Server は CLI を REPL (入力・評価・出力のループ) モードで実行します。この永続的なプロセスにより、コマンドの迅速な実行と円滑なマルチステップ操作が可能になり、新しい CLI インスタンスを繰り返し起動することによるオーバーヘッドがありません。
エージェントができること
初回のリリースでは、開発ワークフローに大きなインパクトをもたらす次の機能が重視されました。
- アプリライフサイクル管理: アプリのデプロイ、スケーリング、再起動、監視、ログへのアクセス。
- データベース操作: Heroku Postgres データベースに対するアクションの実行。
- アドオン管理: アプリのアドオンの検索、接続、接続解除。
- スケーリングとパフォーマンス: アプリのニーズに応じてリソースを動的に調整。
Heroku MCP Server は、Claude Desktop、Cursor、Windsurf のようなツールとのインテリジェントなインテグレーションを可能にし、自動化、効率性、AI を活用したアプリ管理の新たな時代をもたらします。
詳細は、Heroku Managed Inference and Agents の発売に関する投稿や Heroku MCP についての発表を参照してください。
Heroku CLI の更新
進化し続ける Heroku コマンドラインインターフェース (CLI) は、最新の開発ワークフローをサポートし、デプロイプロセスを効率化して、開発者の生産性を高めています。過去 1 年間に Heroku CLI v10 と Plugin Enterprise v5.0.0 という 2 つのメジャーリリースがあり、アーキテクトや開発者が認識すべき有意義な変更が導入されました。
Heroku CLI v10 では、Fir 世代の Heroku プラットフォームが正式にサポートされました。大半のコマンドはこれまでと同じように動作しますが、特に Fir アプリを使用する場合は、重大な変更と機能強化を理解しておく必要があります。
重大な変更 | |
|---|---|
Node.js バージョン |
|
process フラグと dyno フラグ |
|
プロセス管理コマンド |
|
コマンドの互換性 |
|
OpenTelemetry のインテグレーション |
|
spaces の機能強化 |
|
Fir のコマンドの機能強化 |
|
また、Heroku CLI Plugin Enterprise のバージョン 5.0.0 は主にアーキテクチャの更新で、すべての CLI コマンドを oclif プラットフォーム (Open CLI Framework) に移行して、プラグインの基盤を刷新します。これまでプラグインは、oclif が登場する前のレガシーアーキテクチャを使用していました。
機能面に変更はなく、コマンドは以前のバージョンと同じように動作します。CLI とそのプラグインは、Debian/Ubuntu パッケージまたは npm install を使用してインストールされない限り、自動的に更新されます。
- Node.js 20: このプラグインが Node.js 20 で実行され、コア Heroku CLI と連携するようになりました。この変更が、依然として旧バージョンの Node.js に依存している環境やカスタムツールに影響を及ぼす可能性があります。
- oclif v4.14.36: このプラグインが、パフォーマンスと互換性を向上させる目的で、oclif の安定した最新バージョンを使用するようになりました。
- セキュリティの機能強化: 連動関係が更新され、以前のバージョンで検出された既知の脆弱性が排除されました。
Automated Certificate Management (ACM)
Common Runtime で実行されるアプリのワイルドカードドメインが ACM でサポートされるようになりました。これまでは、アプリでワイルドカードドメイン (例: *.example.com) を使用する場合、独自の TLS 証明書を手動で管理する必要がありました。今回の更新で、ACM でこうしたワイルドカードドメインの証明書を自動的に管理できるようになったため、時間が節約され、複雑さが軽減します。
アプリにワイルドカードドメイン証明書と特定のドメイン証明書 (例: app.example.com) の両方がある場合、Heroku は特定のドメイン証明書を優先します。特定のドメイン証明書が削除されると、ACM はワイルドカード証明書を使用するようにフォールバックします。
Eco dyno で ACM を使用可能
以前は、Basic dyno 以上のアプリのみが ACM を使用できました。今回、Eco dyno で実行されるアプリでも ACM を使用可能になり、すべてのユーザーがセキュアな HTTPS 接続を利用できるようになりました。
ACM を有効にするには、$ heroku certs:auto:enable CLI コマンドを実行します。
ACM が有効になると、期限が切れる前に証明書が自動的に更新されるほか、カスタムドメインを追加または削除したときに新しい証明書が生成されます。
ACM の有効化動作の変更
以前は、Eco dyno から上位の dyno にアップグレードすると、ACM が自動的に有効になっていました。
今後は、dyno タイプに関係なく、アプリごとに ACM を手動で有効にする必要があります。さらに、dyno タイプを変更しても、既存のアプリは現在の ACM ステータスを維持します。
まとめ
Heroku プラットフォームは進化を続けているため、Salesforce アーキテクトは、アプリの開発、デプロイ、運用に影響を及ぼす変更を常に把握しておくことが不可欠です。Router 2.0 や Fir といった基盤となるインフラストラクチャの変更から、.NET サポートや AI 推論のような新機能、CLI の機能強化まで、プラットフォームの重要な更新を理解することができました。
こうした変更を理解して適用することで、アプリのスケーラビリティとセキュリティを維持し、最新のベストプラクティスに従うことができます。積極的に行動し、学習を続け、Heroku で自信をもって開発を続けてください。
リソース
- Heroku ブログ: HTTP Routing: Legacy Router and Router 2.0 (HTTP ルーティング: レガシールーターと Router 2.0)
- Heroku
- Heroku ブログ: Eco-Tier Applications Now Require Router 2.0 (Eco 層のアプリで Router 2.0 が必須に)
- Heroku ブログ: Heroku Extension for VS Code is Now Available (VS Code 向け Heroku 拡張機能のリリース)
- Heroku ブログ: Heroku Extension for VS Documentation (VS 向け Heroku 拡張機能のドキュメント)
- Heroku ブログ: Heroku Key Value Store is the New Name for Heroku Data for Redis (Heroku Data for Redis が Heroku Key/Value Store に改称)
- Heroku ブログ: Heroku Key-Value Store
- Heroku ブログ: .NET support on Heroku is now generally available (Heroku の .NET サポートの正式リリース)
- Heroku ブログ: Heroku .NET Support (Heroku の .NET Support)
- Heroku ブログ: .NET SDK 8.0.115, 8.0.311, 8.0.408, 9.0.105 and 9.0.203 are now available (.NET SDK 8.0.115、8.0.311、8.0.408、9.0.105、9.0.203 のリリース)
- Heroku ブログ: .NET buildpack process type naming convention updated (.NET ビルドパックのプロセスタイプの命名規則の更新)
- Heroku ブログ: Fir: Heroku’s Next Generation Platform is Now Generally Available (Fir: Heroku の次世代プラットフォームの正式リリース)
- Heroku ブログ: Heroku Fir: Dive into the New Platform Capabilities (Heroku Fir: 新しいプラットフォーム機能の詳細を確認)
- Heroku ブログ: Get Started with Fir (Fir 入門)
- Heroku ブログ: Migrating Apps From a Cedar Private Space to a Fir Private Space (アプリを Cedar Private Space から Fir Private Space に移行)
- Heroku ブログ: Generations: Fir (世代: Fir)
- Heroku ブログ: Heroku Cloud Native Buildpacks: Bringing Heroku Magic to Container Images (Heroku クラウドネイティブビルドパック: コンテナイメージに Heroku の魔法をかける)
- Heroku ブログ: Creating Cloud Native Buildpacks from Classic Buildpacks (従来のビルドパックからクラウドネイティブビルドパックを作成)
- Heroku ブログ: Heroku AI: Managed Inference and Agents
- Heroku ブログ: Introducing the Official Heroku MCP Server (正式な Heroku MCP サーバーのご紹介)
- Heroku ブログ: Heroku CLI Plugin Enterprise v5.0.0
- Heroku ブログ: Heroku CLI v10 production release (Heroku CLI v10 の本番リリース)
- Heroku ブログ: Automated Certificate Management (ACM) for Eco dynos (Eco dyno の Automated Certificate Management (ACM))
- Heroku ブログ: Automated Certificate Management (ACM) support for wildcard domains for Common Runtime apps (Common Runtime アプリのワイルドカードドメインに対する Automated Certificate Management (ACM) のサポート)