Broadcom TechDocsでは、Tanzu Platform for Cloud Foundry向けのDecoupled Stack Tile (cflinuxfs4) v1.0.5が、2026年6月15日リリースとして確認できます。この記事では、リリースノートの一覧紹介ではなく、運用者が適用前に見るべき3点、つまりcflinuxfs4、Cloud Foundry buildpack、Apply Changes後の確認を整理します。
Decoupled Stack Tileは、Tanzu Platform for Cloud Foundry本体の大型アップグレードとは別に、cflinuxfs4 stackとCloud Foundry buildpackを更新するための部品です。アプリ開発者から見ると「いつものcf push」でも、基盤チームから見るとrootfs、buildpack、restage、変更窓、ロールバック会話が関わります。ここを分けずに読むと、v1.0.5の意味が「新しいtileが出た」だけで終わってしまいます。
Broadcom Watch JapanはBroadcomおよびVMware by Broadcomの公式サイトではありません。この記事は、2026年6月15日時点のBroadcom TechDocsを利用者目線で読み解く非提携の確認メモです。価格、契約条件、サポート範囲、利用権限、実環境の変更手順は、必ずBroadcomの最新資料と自社の変更審査で確認してください。
3行まとめ：v1.0.5で確認するのはstack、buildpack、Apply Changes
Packaged Binariesのstack版を確認し、自社環境のcf stacksやアプリの利用状況と比べる。
標準buildpack、固定buildpack、custom buildpack、Docker image appを分けて影響を確認する。
Decoupled Stack Tileだけで終わらせず、Tanzu Platform for Cloud Foundry tile側の反映と代表アプリ検証まで見る。
CVE修復候補の可視化ではなく、アプリが実際に乗るstackとbuildpackの更新として扱います。
- Decoupled Stack Tile v1.0.5では、cflinuxfs4 1.322.0と複数のCloud Foundry buildpack版がPackaged Binariesとして確認できます。まず自社環境の現在値と差分を見ます。
- この更新はTanzu Platform for Cloud Foundry本体の機能追加ではなく、アプリ実行基盤に近いstack/buildpack更新です。cflinuxfs3残存、manifestのstack指定、custom buildpackの有無を先に棚卸しします。
- Apply ChangesはDecoupled Stack Tileだけで完結させず、Tanzu Platform for Cloud Foundry tile側が新しいruntime configを拾う流れ、代表アプリのrestage/repush、smoke testまでを変更計画に入れます。
今回の話題は、直近の<a href="https://avgo-watch.blog.mo-gmo.com/avgo-46-tanzu-platform-104-vulnerability-remediation-check/" rel="noopener">Tanzu Platform 10.4の脆弱性修復記事</a>とは少し違います。Vulnerability InsightsやTanzu HubでCVE修復候補を見る話ではなく、Cloud Foundryアプリが実際に乗るstackとbuildpackの更新をどう扱うかという運用の話です。
Spring/Java側の緊急パッチやApplication Advisorを先に押さえたい場合は、<a href="https://avgo-watch.blog.mo-gmo.com/avgo-39-tanzu-spring-java-security-day-zero-check/" rel="noopener">BroadcomのSpring/Javaセキュリティ投資を導入前に確認する</a>が近い入口になります。この記事では、Spring依存関係の更新ではなく、Tanzu Platform for Cloud Foundry側のDecoupled Stack Tileに絞ります。
Decoupled Stack Tileは本体アップグレードとは分けて見る
Broadcom TechDocsのOverviewでは、Decoupled Stack Tileはcflinuxfs4 stackとCloud Foundry buildpackを、メインのTanzu Platform for Cloud Foundry tileから切り離して提供するものとして説明されています。これにより、platform tileのリリースサイクルとは別に、stackとbuildpackを更新できます。
この「切り離し」は便利ですが、責任範囲も分かれます。Tanzu Platform for Cloud Foundryの新機能を検証する作業ではなく、アプリ実行環境の部品を更新する作業として扱う必要があります。たとえばJava、Node.js、Python、Rubyなどのbuildpackを使うアプリでは、tile更新そのものより、更新後にどのアプリを再検証するかが実務上の焦点になります。
根拠
確認した一次情報は、Broadcom TechDocsのDecoupled Stack Release Notes、Decoupled Stack Tile Overview、Tanzu Platform for Cloud Foundry upgrade preparation、Managing Stack Lifecycleです。v1.0.5ページではRelease Dateが2026年6月15日、Packaged Binariesにcflinuxfs4 1.322.0が含まれることを確認しました。
注意点
Decoupled Stack Tileを「セキュリティ修復機能」とだけ読むと狭くなります。結果としてセキュリティ修正を含む場合があっても、運用上はrootfsとbuildpackの更新です。CVE件数の増減より先に、現在のstack、buildpack、アプリの再起動・再デプロイ方針を見てください。
最初に決める3つの問い
適用前レビューでは、まず3つの問いを決めます。
- 自社環境はTanzu Platform for Cloud Foundry 10.2系か、10.3系か。
- Decoupled Stack Tileをすでに使っているか。使っていない場合、導入そのものを変更計画に入れる必要があるか。
- cflinuxfs3、古いmanifest指定、固定buildpack、custom buildpackが残っていないか。
この3つが曖昧なままApply Changesへ進むと、Ops Manager上では更新が終わっても、アプリ側では期待したbuildpackに切り替わっていなかったり、特定チームだけ古いstack指定を残していたりします。
評価基準
読者が「すぐApply Changesに載せる」「アプリ棚卸し後に載せる」「自社環境では対象外」と切り分けられるなら、この更新の読み方としては十分です。全環境に一律で急ぐ話ではありません。
v1.0.5のPackaged Binariesを現在値と比べる
適用前にはOps Manager上のtile版、cf buildpacks、cf stacks、manifest、直近のdeploy履歴を合わせて確認します。
Decoupled Stack Tile v1.0.5の中心は、Packaged Binariesの確認です。2026年6月15日時点で確認した10.2版と10.3版のv1.0.5ページでは、少なくとも次の構成が示されています。
| コンポーネント | v1.0.5で確認した版 | 種別 | 適用前に見るポイント |
|---|---|---|---|
| cflinuxfs4 | 1.322.0 | stack | 既存stackの版、cflinuxfs3残存、代表アプリの再検証 |
| binary-buildpack | 1.1.71 | buildpack | バイナリ配布アプリや独自起動スクリプトの確認 |
| dotnet-core-buildpack | 2.4.94 | buildpack | .NETアプリのruntime、SDK、再ビルド影響 |
| go-buildpack | 1.10.82 | buildpack | Goアプリのbuildpack指定と再push時の挙動 |
| java-buildpack | 4.93.0 | buildpack | Java/Springアプリのbuildpack指定、JRE、依存関係更新との分離 |
| nginx-buildpack | 1.2.80 | buildpack | 静的配信やreverse proxy用途の確認 |
| nodejs-buildpack | 1.8.91 | buildpack | Node.js runtime、package lock、CIとの差分 |
| php-buildpack | 4.6.79 | buildpack | PHP runtime、拡張、アプリ起動確認 |
| python-buildpack | 1.8.94 | buildpack | Python runtime、native extension、依存解決 |
| r-buildpack | 1.2.71 | buildpack | Rアプリや分析系ワークロードの代表確認 |
| ruby-buildpack | 1.10.74 | buildpack | Ruby runtime、gem、native extensionの確認 |
| staticfile-buildpack | 1.6.80 | buildpack | 静的サイト、SPA配信、nginx設定の確認 |
この表は、公式ページで確認できる値を運用レビュー用に整理したものです。実際の変更判断では、Ops Manager上のtile版、cf buildpacks、cf stacks、アプリmanifest、直近のdeploy履歴と突き合わせてください。
cflinuxfs4 1.322.0をstack更新として確認する
cflinuxfs4は、Cloud Foundryアプリがbuildpack経由で動く時のLinux root filesystemです。v1.0.5でcflinuxfs4 1.322.0が示されている場合、単に「stackの数字が上がった」と見るだけでは足りません。アプリがそのstack上で再stageされた時に、OSパッケージ、言語runtime、native extension、外部ライブラリとの相性が変わる可能性があります。
まず確認するのは、現在のfoundationで利用可能なstackです。cf stacksでstack一覧を確認し、cf stack cflinuxfs4で詳細を見ます。アプリ側では、manifestにstackを明示しているか、過去の運用でcf push -sを使っているか、古いdeploy automationにstack指定が埋まっていないかを見ます。
確認項目
確認の粒度は、アプリ全件を同じ深さで見る必要はありません。業務重要度が高いアプリ、native extensionを使うアプリ、過去にstack更新で失敗したアプリ、古いbuildpack指定が残るアプリを優先します。GoやJavaのようにビルド成果物の依存が比較的読みやすいものと、PythonやRubyのようにnative extensionやsystem libraryの影響を受けやすいものでは、テストの見方も変わります。
注意点
cflinuxfs4へ移行済みだからといって、v1.0.5の検証が不要になるわけではありません。cflinuxfs4系の中でrootfs版が変わるため、代表アプリのsmoke test、ログ確認、ヘルスチェック、外部サービス接続確認は残ります。
buildpack更新はアプリ再検証の入口にする
buildpackは、ソースコードや成果物をCloud Foundry上で実行可能なdropletへ変換する入口です。v1.0.5では複数のCloud Foundry buildpackが更新対象として並びます。ここで大事なのは、buildpackの版を眺めることではなく、自社アプリがどのbuildpackを使っているかを確認することです。
標準buildpackを使うアプリなら、cf buildpacksの順序や有効状態を見ます。アプリがbuildpackを明示している場合は、manifestやCI/CDのdeploy stepを見ます。URL指定や社内ミラー、forkしたcustom buildpackを使っている場合、Decoupled Stack Tile側の更新だけでは期待したbuildpackへ切り替わらない可能性があります。
java-buildpackを見る時の分け方
java-buildpack 4.93.0という数字だけを見ると、Spring/Javaのセキュリティ更新と混同しやすくなります。buildpack更新はアプリをどうstageするかの話であり、Spring BootやSpring Frameworkの依存関係更新そのものではありません。Spring libraryやCVE-only patchの判断は、アプリの依存関係、Maven/Gradle、SBOM、Tanzu Springの契約範囲と合わせて別に見ます。
cached、offline、custom運用の注意点
オフライン環境や厳格な変更審査がある環境では、buildpackの取り込み経路も確認が必要です。標準buildpackを使っているつもりでも、社内ミラー、固定URL、古いzip、カスタムforkを参照している場合があります。tileの更新が完了しても、実際のアプリが古いbuildpackでstageされ続けるなら、運用上の効果は限定的です。
10.2版と10.3版を照合して対象読者を明確にする
今回確認したTechDocsでは、10.2版と10.3版のDecoupled Stack v1.0.5ページが用意されています。記事としては「10.2/10.3向けのv1.0.5」と読めますが、実務では自社が参照すべき製品バージョンのページを必ず開いてください。
Tanzu Platform for Cloud Foundryは、バージョン、foundation構成、Ops Manager、BOSH release、サービスbroker、内部ネットワーク、オフライン運用の有無によって更新手順が変わります。10.2と10.3で表の値が同じに見えても、運用手順まで同じとは限りません。
公開前リスク
TechDocsは更新される可能性があります。この記事では確認日を2026年6月15日とし、公式ページの表を基準にしています。適用直前には、必ず該当バージョンのTechDocsと自社ポータルで最新のtile、BOSH release、stemcell、buildpackを確認してください。
cflinuxfs3移行前提を適用判断に入れる
- 1stack確認
利用可能なstackと、アプリが実際に使っているstackを分けて確認する。
- 2cflinuxfs3残存
古いstack上のアプリ、移行待ちのmanifest、過去のrestage失敗を洗い出す。
- 3buildpack指定
標準buildpack、URL指定、社内ミラー指定、custom buildpack、Docker image appを分ける。
- 4テスト対象選定
native extension、古いruntime、OSパッケージ依存、nginx設定を持つ代表アプリを選ぶ。
- 5restageまたはrepush判断
更新後すぐ反映させるアプリと、次回deploy時に反映させるアプリを分ける。
cflinuxfs4へ移行済みでも、rootfsとbuildpackが変わる以上、代表アプリの再検証は省略しません。
Decoupled Stack Tile v1.0.5を読む時に、cflinuxfs3からcflinuxfs4への移行前提を避けて通れません。Broadcom TechDocsのupgrade preparationでは、Tanzu Platform for Cloud Foundry v10.0へ進む前に、cflinuxfs3上のアプリをcflinuxfs4へ移行し、cflinuxfs3 buildpackやstackを整理する観点が示されています。
v1.0.5自体はcflinuxfs4の更新ですが、環境にcflinuxfs3が残っていると、話は単純ではありません。新しいcflinuxfs4を入れる前に、どのアプリが古いstackに残っているかを把握する必要があります。
cf stacksとstack stateで残存状況を見る
Cloud Foundryでは、stackのlifecycleや状態を管理できます。Managing Stack Lifecycleでは、stack stateやcf update-stackのような運用が説明されています。実務では、まず利用可能なstackとアプリの実利用を分けて見ます。
利用可能なstackにcflinuxfs3が残っていることと、実際にアプリがcflinuxfs3を使っていることは別です。アプリ一覧、Spaceごとの所有者、manifest、CI/CDのdeploy設定、Stack Auditorまたは同等の棚卸しで、実利用を確認します。
確認項目
棚卸し表には、アプリ名、org/space、担当チーム、現在のstack、利用buildpack、manifestのstack指定、直近deploy日、restage可能性、業務重要度を入れると判断しやすくなります。cflinuxfs3が残っている場合は、v1.0.5適用そのものより先に、移行の順序と所有者を決めるほうが安全です。
注意点
古いstackをdeprecateする運用は、開発者に警告を出すための早期通知として使えます。ただし、警告が出てもcf pushやcf restageが成功する状態と、実際にstackを削除する状態は違います。開発者通知、移行期限、例外申請、削除時期を分けて扱ってください。
cflinuxfs4移行済みでも再検証は省略しない
すでにcflinuxfs4へ移行済みの環境では、v1.0.5を比較的シンプルなstack/buildpack更新として扱える可能性があります。それでも、rootfsとbuildpackが変わる以上、アプリ再検証は必要です。
たとえばPythonやRubyでnative extensionを使うアプリ、Node.jsで古いruntimeを固定しているアプリ、JavaでOSパッケージに依存するアプリ、staticfile-buildpackでnginx設定を持つアプリは、代表テストに入れる価値があります。
評価基準
全アプリを同日にrestageするより、buildpack別、業務重要度別、過去の障害履歴別に代表アプリを選ぶほうが現実的です。初回のsmoke testで問題が出た場合、残りのアプリへ広げる前に止められる運用が望ましいです。
custom buildpackと固定buildpack指定を別枠で扱う
標準buildpackを使うアプリと、custom buildpackを使うアプリでは、Decoupled Stack Tileの影響が違います。標準buildpackならtile更新で提供される版へ移りやすい一方、固定URLや社内forkを使う場合は、tile側の更新を受けないことがあります。
このため、適用判断の棚卸しでは「標準buildpack利用」「標準buildpackを明示指定」「URLまたは社内ミラー指定」「custom buildpack」「Docker image app」を分けます。Docker imageでpushしているアプリは、buildpack更新の影響を受けない場合がありますが、platform全体のstack管理や周辺機能の影響は別に見ます。
下振れ要因
もっとも厄介なのは、運用チームが標準buildpackだと思っているのに、実際にはアプリ側で古いbuildpackを固定しているケースです。この場合、Ops Managerでv1.0.5を入れても、期待した更新がアプリへ反映されません。cf buildpacksとmanifest、CI/CDのdeploy定義を両方見る必要があります。
Apply Changes前後の実務ポイントを固定する
- 1Decoupled Stack Tile
cflinuxfs4 stackとCloud Foundry buildpackを提供するtileとして更新内容を確認する。
- 2Tanzu Platform for Cloud Foundry tile
runtime configを拾うため、platform tile側のApply Changes対象と影響範囲を確認する。
- 3基盤側の確認
BOSH task、Diego cells、platform health、cf stacks、cf buildpacksを変更計画に入れる。
- 4アプリ側の確認
代表アプリの起動、route、service binding、ログ、性能、外部接続を確認する。
- 5切り戻し判断
tile版、BOSH release、restage済みdroplet、buildpack cacheの扱いを事前に会話しておく。
成功判定はOps Managerの完了表示だけにせず、アプリ実行側で使える状態になったかまで含めます。
Decoupled Stack TileのOverviewでは、Decoupled Stack tileがruntime config add-onでcflinuxfs4 stackを提供するため、Decoupled Stack tileとTanzu Platform for Cloud Foundry tileの両方でApply Changesを行い、Tanzu Platform for Cloud Foundry tileがそのruntime configを拾う必要があると説明されています。
ここは、記事で一番見落としやすい点です。Decoupled Stack Tileを追加・更新するだけでなく、Tanzu Platform for Cloud Foundry側のDiego cellsが新しいstackを使える状態になるかを確認します。
Decoupled Stack Tileだけで完結させない
Ops Manager上では、Review Pending Changesでどのtileを選ぶか、どのerrandを実行するか、対象foundationはどこか、変更窓はどれくらいかを確認します。画面操作は環境によって変わるため、この記事では手順そのものより確認観点を重視します。
適用前には、現在のtile版、pending changes、依存tile、BOSH taskの監視方法、ログ取得先、バックアップ、既知障害、直近のApply Changes所要時間を確認します。更新後には、Ops Managerの完了表示だけでなく、Cloud Foundry側のstack/buildpack表示と代表アプリの動作を確認します。
根拠
Broadcom TechDocsのOverviewは、Decoupled Stack tileが提供するruntime configをTanzu Platform for Cloud Foundry tileが拾う必要があると説明しています。つまり、変更成功の判定は、tile更新完了だけではなく、アプリ実行側で使える状態になったかまで含みます。
注意点
「Apply Changesを押すだけ」と書いてしまうと危険です。実際にはfoundationの規模、Diego cells、BOSH deploy、errand、network、service broker、オフライン環境、監視連携によって影響が変わります。自社の標準変更手順に合わせて、影響範囲と切り戻し条件を事前に確認してください。
変更窓ではBOSH再配置とアプリ影響を分ける
基盤側の変更とアプリ側の確認は、同じ変更窓の中でも担当が違います。基盤チームはBOSH task、tile apply、Diego cells、platform healthを見る一方、アプリチームは代表アプリの起動、route、service binding、ログ、性能、外部接続を見ます。
特に、更新後にアプリをrestageする運用か、次回deploy時に自然に反映させる運用かで影響が変わります。buildpack更新の効果をすぐ確認したいなら、対象アプリのrestageまたはrepushが必要になる場合があります。
確認項目
変更計画には、誰がcf stacksとcf buildpacksを確認するか、誰が代表アプリをrestageするか、どのアプリをsmoke test対象にするか、問題時にどこで止めるかを入れます。ログ取得先と連絡先も同じメモに入れておくと、変更中の判断が速くなります。
smoke testとロールバック会話を先に用意する
rootfsやbuildpack更新後のsmoke testでは、単にアプリが起動するかだけでなく、主要route、service binding、外部API、DB接続、ログ出力、メトリクス、ヘルスチェックを見ます。アプリによっては、起動直後は成功しても、特定のコードパスでnative libraryやruntime差分が表面化します。
ロールバックも事前に会話しておくべきです。tile版を戻せるか、BOSH releaseを戻せるか、すでにrestageしたdropletをどう扱うか、buildpack cacheをどう見るか、再push済みアプリがあるかで判断が変わります。
条件
すぐ全アプリをrestageする運用なら、変更窓と監視体制を厚めに取ります。段階適用する運用なら、初回対象アプリと次の波を明確にします。どちらが正しいというより、環境の規模とテスト信頼性で決めます。
適用するか、待つかを判断するチェックリスト
待つ場合も放置ではなく、待つ理由、期限、影響範囲、次の変更窓で見る項目を明確にします。
v1.0.5を見た時の判断は、単純な「適用する/しない」ではありません。自社環境の状態によって、早めに変更計画へ載せる場合、棚卸し後に進める場合、いったん待つ場合に分かれます。
| 判断 | 環境条件 | 先に見ること | 次のアクション |
|---|---|---|---|
| 早めに変更計画へ載せる | Decoupled Stack Tileを既に運用し、cflinuxfs4移行済み、標準buildpack中心 | 現在値との差分、代表アプリ、変更窓、smoke test | Apply Changes計画とアプリ検証をセットで作る |
| 棚卸し後に進める | cflinuxfs3残存、custom buildpack、古いmanifest、固定buildpack指定がある | アプリ所有者、stack指定、buildpack指定、過去のrestage失敗 | 先にアプリ台帳と移行順序を作る |
| いったん待つ | 変更凍結期間、対象バージョン不明、TechDocs照合不足、テスト不足 | 待つ理由、期限、次回確認日、影響範囲 | 放置ではなく、次の変更窓へ調査を残す |
すぐ適用候補になる条件
すでにDecoupled Stack Tileを運用しており、cflinuxfs4へ移行済みで、標準buildpack利用が中心、代表アプリの自動テストやsmoke testがある環境なら、v1.0.5は早めに変更計画へ載せる候補になります。
ただし、これは「すべての環境で即適用」という意味ではありません。公式表と現在値の差分、変更窓、担当者、確認項目、問題時の止め方がそろっている場合に、早めに進めやすいということです。
評価基準
変更審査で説明すべき一文は、「Tanzu Platform本体の新機能追加ではなく、cflinuxfs4とCloud Foundry buildpackの独立更新であり、代表アプリのrestage/repushとsmoke testを含めて確認する」です。この説明ができれば、関係者の期待値がそろいやすくなります。
棚卸し後に適用したほうがよい条件
cflinuxfs3が残っている、custom buildpackが多い、古いmanifestがある、CI/CDのdeploy定義がチームごとに違う、ネイティブ依存のアプリが多い。このような環境では、v1.0.5の適用前に棚卸しを優先したほうがよいです。
棚卸しといっても、完璧なCMDBを作る必要はありません。少なくとも、どのアプリがどのstackとbuildpackを使っているか、誰が確認するか、どの順番でrestage/repushするかを明らかにします。
確認項目
棚卸し表には、アプリ所有者、利用buildpack、stack指定、Docker image利用有無、外部サービス依存、直近deploy日、変更凍結期間、テスト担当、SLO影響を入れます。これだけで、Apply Changes後に誰へ確認を依頼するかがかなり見えます。
いったん待つ場合でも確認だけは進める
待つ判断は、何もしないことではありません。変更凍結期間や大規模リリース前で適用を遅らせるなら、待つ理由、期限、次回確認日、未確認項目を明記します。
Decoupled Stack Tileやbuildpack更新を長く止めると、次回の差分が大きくなります。待つ場合でも、TechDocs、現在値、残存cflinuxfs3、custom buildpack、Apply Changesの依存関係は先に確認しておくべきです。
下振れ要因
もっとも避けたいのは、次の更新時に「前回も見ていなかったので今回も分からない」となることです。適用を待つなら、次回の変更窓へ持ち越す調査メモを残してください。
本文末の導入判断メモ
本体の大規模アップグレードではなく、cflinuxfs4とbuildpackの独立更新として変更計画に入れる。
自分たちのアプリがどのbuildpackやimageで動いているかを確認し、restage/repushとsmoke testの担当を決める。
CVE可視化そのものではなく、rootfsとbuildpackの更新状態として追跡する。
cflinuxfs4とbuildpackの更新は、変更窓、開発者のデプロイ体験、アプリ検証、セキュリティ対応にまたがります。
Tanzu Platform for Cloud Foundryの運用者にとって、Decoupled Stack Tile v1.0.5は目立つ発表会ニュースではありません。ただ、日々のアプリ運用には近い更新です。cflinuxfs4とbuildpackの更新は、開発者のデプロイ体験、セキュリティ対応、基盤チームの変更窓、アプリチームのテスト計画に直結します。
プラットフォームチームに渡す一文
v1.0.5はTanzu Platform本体の大規模アップグレードではなく、cflinuxfs4 1.322.0とCloud Foundry buildpackの独立更新として扱い、Decoupled Stack TileとTanzu Platform for Cloud Foundry tileのApply Changes、代表アプリ検証までを同じ変更計画に入れる。
アプリチームに渡す一文
自分たちのアプリが標準buildpack、固定buildpack、custom buildpack、Docker imageのどれで動いているかを確認し、更新後のrestage/repushとsmoke testの担当を決める。
セキュリティチームに渡す一文
この更新は脆弱性可視化そのものではなく、アプリ実行基盤の部品更新です。CVE対応の期待値は、Tanzu HubやSpring依存関係更新と分け、rootfs/buildpackの更新状態として追跡する。
2026年6月のBroadcom/VMware/Tanzu更新を継続して追う場合は、<a href="https://avgo-watch.blog.mo-gmo.com/monthly-topics-2026-06/" rel="noopener">2026年6月 重要トピックまとめ</a>も合わせて確認できます。更新通知を受け取りたい場合は、記事読了後の導線として<a href="https://avgo-watch.blog.mo-gmo.com/newsletter/" rel="noopener">ニュースレター</a>を使えます。
更新履歴・運用メモ
2026年6月15日JST時点の確認として扱う。
Decoupled Stack Tile v1.0.5、10.2版と10.3版、Overview、upgrade preparation、Managing Stack Lifecycleを見る。
実環境のOps Manager画面やBOSH taskログは確認していない。
TechDocsの表やサポート条件は更新される可能性があるため、該当バージョンの公式資料を開き直す。
公開資料に基づく導入前チェックとして読み、実環境への適用判断は最新の公式資料と自社変更手順で確認します。
- 確認日：2026年6月15日JST。
- 確認対象：Broadcom TechDocsのDecoupled Stack Tile v1.0.5、10.2版と10.3版、Overview、upgrade preparation、Managing Stack Lifecycle。
- この記事では、実環境のOps Manager画面やBOSH taskログは確認していません。公開資料に基づく導入前チェックです。
- TechDocsの表やサポート条件は更新される可能性があります。適用前には必ず該当バージョンの公式資料を開き直してください。
次に読むなら
参照した主な情報源
- Broadcom TechDocs, "Decoupled Stack Release Notes", Release v1.0.5。確認日：2026年6月15日。https://techdocs.broadcom.com/us/en/vmware-tanzu/platform/elastic-application-runtime/10-2/eart/decoupled-stack-v1-0-5.html
- Broadcom TechDocs, "Decoupled Stack Tile (cflinuxfs4) Release Notes"。確認日：2026年6月15日。https://techdocs.broadcom.com/us/en/vmware-tanzu/platform/elastic-application-runtime/10-2/eart/decoupled-stack-rel-notes.html
- Broadcom TechDocs, "Decoupled Stack Tile Overview"。確認日：2026年6月15日。https://techdocs.broadcom.com/us/en/vmware-tanzu/platform/elastic-application-runtime/10-2/eart/decoupled-stack-overview.html
- Broadcom TechDocs, "Preparing Tanzu Platform for Cloud Foundry for upgrades"。確認日：2026年6月15日。https://techdocs.broadcom.com/us/en/vmware-tanzu/platform/elastic-application-runtime/10-2/eart/configuring.html
- Broadcom TechDocs, "Managing Stack Lifecycle in Cloud Foundry"。確認日：2026年6月15日。https://techdocs.broadcom.com/us/en/vmware-tanzu/platform/elastic-application-runtime/10-2/eart/managing-stacks.html
- Broadcom TechDocs, "Decoupled Stack Release Notes", 10.3版v1.0.5。確認日：2026年6月15日。https://techdocs.broadcom.com/us/en/vmware-tanzu/platform/elastic-application-runtime/10-3/eart/decoupled-stack-v1-0-5.html