Cloud-Native | The .NET Blog

Python、TypeScript、.NETでazdフックを書く：シェルスクリプトとの決別

Emiliano Montesdeoca — Thu, 23 Apr 2026 00:00:00 +0000

この投稿は自動翻訳されました。元のバージョンはこちらをクリックしてください。

完全に.NETで書かれたプロジェクトを持ちながら、azdのフックのためにBashスクリプトを書かなければならなかった経験はないだろうか。あの苦痛を知っている人は多いはず。C#でプロジェクト全体を書いているのに、なぜpre-provisioningのステップだけシェル構文に切り替えなければならないのか。

その不満がついに公式に解決された。Azure Developer CLIがフックのマルチ言語サポートを発表し、想像通りの素晴らしい機能となっている。

フックとは

フックはazdのライフサイクルの重要なポイントで実行されるスクリプト — プロビジョニング前、デプロイ後など。azure.yamlで定義され、CLIを変更せずにカスタムロジックを注入できる。

これまではBashとPowerShellのみサポートされていた。今やPython、JavaScript、TypeScript、.NETが使えるようになり、azdが残りを自動で処理する。

検出の仕組み

フックをファイルに向けるだけで、azdが拡張子から言語を推論する：

hooks:
 preprovision:
 run: ./hooks/setup.py
 postdeploy:
 run: ./hooks/seed.ts
 postprovision:
 run: ./hooks/migrate.cs

追加設定は不要。拡張子が曖昧な場合はkind: python（または対応する言語）を明示的に指定できる。

言語別の重要な詳細

Python

スクリプトと同じディレクトリ（または親ディレクトリ）にrequirements.txtやpyproject.tomlを置くだけ。azdが自動的に仮想環境を作成し、依存関係をインストールしてスクリプトを実行する。

JavaScriptとTypeScript

同じパターン — スクリプトの近くにpackage.jsonを置くとazdがまずnpm installを実行する。TypeScriptの場合はnpx tsxを使用し、コンパイルステップもtsconfig.jsonも不要。

.NET

2つのモードが利用可能：

プロジェクトモード：スクリプトの隣に.csprojがあれば、azdが自動的にdotnet restoreとdotnet buildを実行。
シングルファイルモード：.NET 10以降では、スタンドアロンの.csファイルをdotnet run script.csで直接実行可能。プロジェクトファイル不要。

エグゼキューター固有の設定

各言語はオプションのconfigブロックをサポート：

hooks:
 preprovision:
 run: ./hooks/setup.ts
 config:
 packageManager: pnpm
 postprovision:
 run: ./hooks/migrate.cs
 config:
 configuration: Release
 framework: net10.0

.NET開発者にとっての重要性

フックはazd基盤のプロジェクトで言語切り替えを強制する最後の場所だった。これで、アプリコード、インフラスクリプト、ライフサイクルフックを含むデプロイパイプライン全体を1つの言語で管理できる。既存の.NETユーティリティをフックで再利用し、共有ライブラリを参照し、シェルスクリプトの保守から解放される。

まとめ

小さな変更のように見えるが、azdの日常ワークフローから多くの摩擦を取り除く変更の一つ。フックのマルチ言語サポートは今すぐ利用可能 — 公式ポストで全ドキュメントを確認してほしい。

Global Azure Spain 2026

Sat, 18 Apr 2026 00:00:00 +0000

Global Azure Spain 2026 は 2026年4月18日 にマドリード、Alcobendas の Kinépolis Diversia で開催されます。スペイン最大のコミュニティ主導のAzureイベントで、AIエージェント、Azureネットワーク、Cosmos DB、Fabric、IoT、セキュリティなどをカバーする3つの並行トラックに38名のスピーカーが登壇します。

イベントは 08:30 から 18:30 まで開催され、キーノート、コーヒーブレイク、ランチ、クロージングQ&Aセッションを含みます。

アジェンダのハイライト

Domando Agentes de IA: Azure AI FoundryとAzure API Managementによるガバナンス、ツール、API
Construyendo agentes con LibreChat en Azure
How Can I Steal Your Data with Azure Private Endpoints
Stop Building APIs. Forge Agents with Azure
Agentic DevOps Meets IoT: Real-Time Systems with Fabric and GitHub Copilot
El regreso de los tamagotchis!: マルチエージェントシステムの実践
Foundry Control Plane como plataforma de Agentes global
Rompiendo el perímetro: Zero Trust aplicado en Azure

チケット

登録は象徴的な寄付です — チケット代金は全額 Plan International に寄付され、世界中の子どもの権利と平等を支援します。定員に限りがありますので、お早めにお申し込みください。

Azure Tour 2026

マドリード以外にも、Global Azure Tour 2026 は サラゴサ、テネリフェ、セビリア でも開催されます。

Aspire 13.2にMongoDB EF CoreとAzure Data Lakeが追加 — 試す価値のある2つのインテグレーション

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

この記事は自動翻訳されています。オリジナル版はこちらをご覧ください。

Aspire 13.2が2つの新しいデータベースインテグレーションと共にリリースされました。注目すべきはMongoDB Entity Framework CoreとAzure Data Lake Storageです。AspireアプリでMongoDBとEF Coreを使いたかった方、あるいはサービスディスカバリ付きでData Lakeワークロードを接続したかった方にとって、今回のリリースはまさにそれを提供してくれます。

AspireでMongoDBとEF Coreが出会う

これが一番ワクワクしているインテグレーションです。AspireはMongoDBを以前からサポートしていましたが、常に生のドライバーでした — EF Coreなし、DbContextなし、ドキュメントに対するLINQクエリなし。今回から、MongoDBでフルのEF Core体験が得られるようになり、さらにAspireの自動ヘルスチェックとサービスディスカバリも付いてきます。

セットアップは典型的なAspireパターンです。AppHostで：

var mongodb = builder.AddMongoDB("mongodb")
 .WithDataVolume()
 .WithLifetime(ContainerLifetime.Persistent);

var apiService = builder.AddProject<Projects.ApiService>("api")
 .WithReference(mongodb);

次に、コンシューマープロジェクトでEF Coreインテグレーションを追加します：

dotnet add package Aspire.MongoDB.EntityFrameworkCore

そしてDbContextを登録します：

builder.AddMongoDbContext<MyDbContext>("mongodb", "mydb");

あとは標準的なEF Coreです。エンティティを定義し、他のプロバイダーと同じようにDbContextを使います。コネクションプーリング、OpenTelemetryトレース、ヘルスチェックはインテグレーションがバックグラウンドで処理します。

生のドライバーでMongoDBを使い、コネクション文字列を手動で設定していた.NET開発者にとって、これは嬉しい改善です。Aspireのサービスディスカバリを失うことなく、EF Coreの完全な抽象化が手に入ります。

Azure Data Lake Storageが仲間入り

2つ目の大きな追加はAzure Data Lake Storage（ADLS）インテグレーションです。データパイプライン、ETLプロセス、分析プラットフォームを構築しているなら、他のAspire依存関係と同じ方法でData Lakeリソースを接続できるようになりました。

AppHostで：

var storage = builder.AddAzureStorage("azure-storage");
var dataLake = storage.AddDataLake("data-lake");
var fileSystem = storage.AddDataLakeFileSystem("data-lake-file-system");

var analyticsService = builder.AddProject<Projects.AnalyticsService>("analytics")
 .WithReference(dataLake)
 .WithReference(fileSystem);

コンシューマープロジェクトで：

builder.AddAzureDataLakeServiceClient("data-lake");
builder.AddAzureDataLakeFileSystemClient("data-lake-file-system");

コネクション文字列の手動管理も、資格情報の探索も不要です。Aspireがリソースをプロビジョニングして注入します。オペレーショナルデータと分析ワークロードの両方を扱うクラウドネイティブな.NETアプリを構築している私たちにとって、Data LakeがAspireモデルのファーストクラスシチズンのように感じられるようになります。

地味だけど大事な修正

メイン機能以外にも、いくつかの改善が注目に値します：

MongoDBコネクション文字列の修正 — データベース名の前のスラッシュが正しく処理されるようになりました。ワークアラウンドを使っていた方は、もう不要です
SQL Serverエクスポート — Aspire.Hosting.SqlServerが追加のサーバー構成オプションをエクスポートし、より細かい制御が可能に
エミュレーターの更新 — ServiceBusエミュレーター2.0.0、App Configurationエミュレーター1.0.2、CosmosDBのプレビューエミュレーターにレディネスチェックが追加
Azure Managed Redis — デフォルトでrediss://（Redis Secure）を使用するようになり、接続が最初から暗号化されます

最後のポイントは地味ですが重要です — デフォルトで暗号化されたRedisは、本番環境で設定すべきことが1つ減ることを意味します。

まとめ

Aspire 13.2はインクリメンタルなリリースですが、MongoDB EF CoreとData Lakeのインテグレーションは実際のギャップを埋めてくれます。AspireでのMongoDBに対する適切なEF Coreサポートを待っていた方、またはData Lakeをファーストクラスの依存関係として必要としていた方は、13.2にアップグレードして試してみてください。aspire addコマンドで必要なものがすべてスキャフォールドされます。

完全なリリースノートで詳細を確認し、インテグレーションギャラリーで完全なリストをチェックしてください。

Azure Smart TierがGAに — ライフサイクルルール不要でBlob Storageのコストを自動最適化

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

この記事は自動翻訳されています。オリジナル版はこちらをご覧ください。

Azure Blob Storageのライフサイクルポリシーの調整に時間をかけた結果、アクセスパターンが変わった途端に全部崩れた経験があるなら、この記事はまさにあなた向けです。Microsoftは、Azure BlobおよびData Lake Storage向けのsmart tierの一般提供を発表しました — 実際の使用状況に基づいて、オブジェクトをhot、cool、coldティア間で自動的に移動するフルマネージドのティアリング機能です。

Smart tierが実際にやること

コンセプトはシンプルです。smart tierはストレージアカウント内の各オブジェクトの最終アクセス時刻を継続的に評価します。頻繁にアクセスされるデータはhotに留まり、非アクティブなデータは30日後にcoolへ、さらに60日後にcoldへ移動します。データが再びアクセスされると、すぐにhotに昇格します。サイクルが再開します。

設定するライフサイクルルールなし。アクセスパターンの予測なし。手動チューニングなし。

プレビュー期間中、Microsoftはsmart tierで管理された容量の50%以上が、実際のアクセスパターンに基づいて自動的にクールなティアに移行したと報告しています。大規模なストレージアカウントにとって意味のあるコスト削減です。

.NET開発者にとってなぜ重要か

ログ、テレメトリ、分析データ、あるいは何らかの成長するデータ資産を生成するアプリケーションを構築しているなら — 正直なところ、そうでない人はいないでしょう — ストレージコストはすぐに膨れ上がります。従来のアプローチは、ライフサイクル管理ポリシーを書き、テストし、アプリのアクセスパターンが変わったら再調整することでした。Smart tierはそのワークフロー全体を排除します。

これが役立つ実用的なシナリオ：

アプリケーションのテレメトリとログ — デバッグ中はhot、数週間後にはほとんどアクセスされない
データパイプラインとETL出力 — 処理中は頻繁にアクセス、その後はほぼcold
ユーザー生成コンテンツ — 最近のアップロードはhot、古いコンテンツは徐々に冷却
バックアップとアーカイブデータ — コンプライアンスのため時々アクセス、ほとんどアイドル

セットアップ方法

Smart tierの有効化は一度きりの設定です：

新しいアカウント：ストレージアカウント作成時にsmart tierをデフォルトのアクセスティアとして選択（ゾーン冗長が必要）
既存のアカウント：blobアクセスティアを現在のデフォルトからsmart tierに切り替え

128 KiB未満のオブジェクトはhotに留まり、モニタリング料金は発生しません。それ以外は、ティア移行料金なし、早期削除料金なし、データ取得コストなしの標準hot/cool/cold容量料金を支払います。オブジェクトごとの月額モニタリング料金がオーケストレーションをカバーします。

知っておくべきトレードオフ

Smart tierのティアリングルールは固定です（30日→cool、90日→cold）。カスタムしきい値が必要な場合 — 例えば、特定のワークロードで7日後にcoolに移動したい場合 — ライフサイクルルールが引き続き正解です。そして両方を混ぜないでください：smart tierで管理されているオブジェクトにライフサイクルルールを使用すると競合する可能性があるため、避けてください。

まとめ

革命的ではありませんが、実際の運用上の頭痛の種を解決します。成長するBlob Storageアカウントを管理していて、ライフサイクルポリシーの維持に疲れているなら、smart tierを有効化してAzureに任せましょう。現在、ほぼすべてのゾーンパブリッククラウドリージョンで利用可能です。

AzureでAIエージェントをどこにホストすべき？実践的な判断ガイド

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

この記事は自動翻訳されています。オリジナル版はこちらをご覧ください。

今.NETでAIエージェントを構築しているなら、おそらく気づいていることがあるでしょう：Azureでホストする方法がたくさんあるということです。Container Apps、AKS、Functions、App Service、Foundry Agents、Foundry Hosted Agents — どれも合理的に聞こえますが、実際に選ぶ段階になると困ります。MicrosoftがAzureでのAIエージェントホスティングに関する包括的なガイドを公開しました。これを.NET開発者の実践的な視点から整理します。

6つのオプション早見表

オプション	最適な用途	管理するもの
Container Apps	K8sの複雑さなしにコンテナを完全制御	オブザーバビリティ、状態、ライフサイクル
AKS	エンタープライズコンプライアンス、マルチクラスター、カスタムネットワーキング	すべて（それがポイント）
Azure Functions	イベント駆動の短時間エージェントタスク	ほぼなし — 真のサーバーレス
App Service	シンプルなHTTPエージェント、予測可能なトラフィック	デプロイ、スケーリング設定
Foundry Agents	ポータル/SDKによるコード不要エージェント	ほぼなし
Foundry Hosted Agents	マネージドインフラでカスタムフレームワークエージェント	エージェントコードのみ

最初の4つは汎用コンピュートです — エージェントを動かすことはできますが、そのために設計されたものではありません。最後の2つはエージェントネイティブで、会話、ツール呼び出し、エージェントのライフサイクルをファーストクラスの概念として理解しています。

Foundry Hosted Agents — .NETエージェント開発者にとってのスイートスポット

注目すべきはこれです。Foundry Hosted Agentsはちょうど中間に位置しています：自分のコード（Semantic Kernel、Agent Framework、LangGraph — 何でも）を実行する柔軟性がありながら、プラットフォームがインフラ、オブザーバビリティ、会話管理を処理します。

キーピースはHosting Adapterです — エージェントフレームワークをFoundryプラットフォームに接続する薄い抽象化レイヤーです。Microsoft Agent Frameworkの場合：

from azure.ai.agentserver.agentframework import from_agent_framework

agent = ChatAgent(
 chat_client=AzureAIAgentClient(...),
 instructions="You are a helpful assistant.",
 tools=[get_local_time],
)

if __name__ == "__main__":
 from_agent_framework(agent).run()

これがホスティングの全体像です。アダプターがプロトコル変換、server-sent eventsによるストリーミング、会話履歴、OpenTelemetryトレーシングを自動的に処理します。カスタムミドルウェアも手動の配管作業も不要です。

デプロイは本当にシンプル

以前Container Appsにエージェントをデプロイしたことがありますが、状態管理やオブザーバビリティのためのグルーコードをたくさん書くことになります。Hosted Agentsとazdなら：

# AIエージェント拡張機能をインストール
azd ext install azure.ai.agents

# テンプレートから初期化
azd ai agent init

# ビルド、プッシュ、デプロイ — 完了
azd up

この1つのazd upがコンテナをビルドし、ACRにプッシュし、Foundryプロジェクトをプロビジョニングし、モデルエンドポイントをデプロイし、エージェントを起動します。5つのステップが1つのコマンドに凝縮されています。

組み込みの会話管理

本番で最も時間を節約するのはここです。独自の会話ステートストアを構築する代わりに、Hosted Agentsがネイティブに処理します：

# 永続的な会話を作成
conversation = openai_client.conversations.create()

# 最初のターン
response1 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Remember: my favorite number is 42.",
)

# 2回目のターン — コンテキストが保持される
response2 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Multiply my favorite number by 10.",
)

Redisなし。Cosmos DBセッションストアなし。メッセージシリアライゼーション用のカスタムミドルウェアなし。プラットフォームがすべて処理します。

私の判断フレームワーク

6つすべてのオプションを検討した結果、私のクイックメンタルモデルはこうです：

インフラゼロが必要？ → Foundry Agents（ポータル/SDK、コンテナなし）
カスタムエージェントコードがあるがマネージドホスティングが欲しい？ → Foundry Hosted Agents
イベント駆動の短期エージェントタスクが必要？ → Azure Functions
K8sなしで最大限のコンテナ制御が必要？ → Container Apps
厳格なコンプライアンスとマルチクラスターが必要？ → AKS
予測可能なトラフィックのシンプルなHTTPエージェント？ → App Service

Semantic KernelやMicrosoft Agent Frameworkで構築しているほとんどの.NET開発者にとって、Hosted Agentsが適切なスタート地点でしょう。scale-to-zero、組み込みOpenTelemetry、会話管理、フレームワークの柔軟性が得られます — Kubernetesの管理やオブザーバビリティスタックの構築なしに。

まとめ

AzureのエージェントホスティングランドスケープはFastに成熟しています。今日新しいAIエージェントプロジェクトを始めるなら、習慣でContainer AppsやAKSに手を伸ばす前に、Foundry Hosted Agentsを真剣に検討することをお勧めします。マネージドインフラは実際の時間を節約し、hosting adapterパターンでフレームワークの選択を維持できます。

Microsoftの完全ガイドとFoundry Samplesリポジトリで動作するサンプルを確認してください。

KubeCon Europe 2026：.NET開発者が本当に知るべきこと

Emiliano Montesdeoca — Sun, 29 Mar 2026 00:00:00 +0000

この記事は自動翻訳されました。オリジナル版はこちらをご覧ください。

巨大なアナウンス記事が出て、スクロールしながら「クール、でも実際に自分にとって何が変わるの？」と思うあの感覚、分かりますよね？毎回KubeConシーズンになると私はそうなります。

MicrosoftがKubeCon Europe 2026の完全なまとめを公開しました。Brendan Burns自身が執筆しています。正直に言うと、ここには本物の中身があります。機能のチェックリストだけでなく、本番環境での運用方法を変える運用面の改善です。

.NET開発者として本当に重要なことを整理しましょう。

サービスメッシュ税なしのmTLS

サービスメッシュの問題点：全員がセキュリティの保証を求めるけど、運用オーバーヘッドは誰も望まない。AKSがついにこのギャップを埋めています。

Azure Kubernetes Application Networkは、相互TLS、アプリケーション認識型の認可、トラフィックテレメトリを提供します。サイドカーの重いフルメッシュをデプロイする必要はありません。Advanced Container Networking ServicesのCilium mTLSと組み合わせれば、X.509証明書とSPIREによるID管理を使った暗号化されたpod間通信が実現します。

実際にはどういうことか：ASP.NET Core APIがバックグラウンドワーカーと通信する、gRPCサービスが相互に呼び出す — すべてがネットワークレベルで暗号化・ID検証され、アプリケーションコードの変更はゼロ。これは大きいです。

ingress-nginxから移行しているチームには、Meshless IstioによるApplication Routingもあり、Kubernetes Gateway APIの完全サポート付きです。サイドカーなし。標準ベース。段階的な移行のためのingress2gatewayツールも提供されています。

後付けではないGPUオブザーバビリティ

.NETサービスと並行してAI推論を実行している場合（正直、誰が始めていないでしょうか？）、GPUモニタリングの盲点に遭遇したことがあるでしょう。CPU/メモリのダッシュボードは素晴らしかったのに、GPUについては手動のエクスポーター設定なしでは何もなかった。

AKSはGPUメトリクスをネイティブにマネージドPrometheusとGrafanaに表示するようになりました。同じスタック、同じダッシュボード、同じアラートパイプライン。カスタムエクスポーターもサードパーティエージェントも不要。

ネットワーク側では、HTTP、gRPC、Kafkaトラフィックのフローごとの可視性がワンクリックAzure Monitor体験で追加されました。IP、ポート、ワークロード、フロー方向、ポリシー判定 — すべてが組み込みダッシュボードに。

そして二度見させられたもの：agentic container networkingは、クラスターのネットワーク状態について自然言語で質問できるWeb UIを追加します。「ポッドXがサービスYに到達できないのはなぜ？」→ ライブテレメトリからの読み取り専用診断。午前2時に本当に役立ちます。

博士号不要のクロスクラスターネットワーキング

マルチクラスターKubernetesは歴史的に「自分でネットワークの接着剤を持ってくる」体験でした。Azure Kubernetes Fleet Managerが、マネージドCiliumクラスターメッシュによるクロスクラスターネットワーキングを提供するようになりました：

AKSクラスター間の統一された接続性
クロスクラスター検出のためのグローバルサービスレジストリ
クラスターごとに繰り返すのではなく中央で管理される設定

レジリエンスやコンプライアンスのために複数リージョンで.NETマイクロサービスを実行しているなら、多くの脆弱なカスタムの接着剤が置き換えられます。West EuropeのサービスAがメッシュを通じてEast USのサービスBを発見して呼び出せます。一貫したルーティングとセキュリティポリシーが適用されます。

勇気を必要としないアップグレード

正直に言いましょう — 本番環境のKubernetesアップグレードはストレスフルです。「アップグレードして祈る」があまりにも多くのチームのデファクト戦略であり、クラスターがバージョンに遅れる主な理由です。

2つの新機能がこれを変えます：

Blue-greenエージェントプールアップグレードは新しい設定でパラレルなノードプールを作成します。動作を検証し、トラフィックを段階的に移動し、クリーンなロールバックパスを維持します。本番ノードでのインプレース変更はもう不要。

エージェントプールロールバックにより、アップグレードがうまくいかなかった場合、クラスターを再構築することなく、ノードプールを以前のKubernetesバージョンとノードイメージに戻せます。

組み合わせることで、オペレーターにアップグレードのライフサイクルに対する本当のコントロールを提供します。.NETチームにとっては、プラットフォームの速度が新しいランタイム、セキュリティパッチ、ネットワーク機能をどれだけ早く採用できるかを直接制御するため重要です。

AIワークロードがKubernetesのファーストクラス市民に

アップストリームのオープンソース作業も同様に重要です。Dynamic Resource Allocation (DRA)がKubernetes 1.36でGAになり、GPUスケジューリングがワークアラウンドではなく本物のファーストクラス機能になりました。

注目すべきプロジェクト：

プロジェクト	内容
AI Runway	推論のための共通Kubernetes API — K8sを知らなくてもモデルをデプロイ、HuggingFace検出とコスト見積もり付き
HolmesGPT	クラウドネイティブ向けのエージェント型トラブルシューティング — CNCF Sandboxプロジェクトに
Dalec	SBOM生成付きの宣言的コンテナイメージビルド — ビルド段階でのCVE削減

方向性は明確：あなたの.NET API、Semantic Kernelのオーケストレーション層、推論ワークロードはすべて一貫したプラットフォームモデル上で実行されるべきです。そこに向かっています。

今週から始めるなら

チームでこれらの変更を評価しているなら、私の正直な優先順位リスト：

まずオブザーバビリティ — 非本番クラスターでGPUメトリクスとネットワークフローログを有効にする。見逃していたものを確認する。
Blue-greenアップグレードを試す — 次の本番クラスターアップグレード前にロールバックワークフローをテストする。プロセスへの信頼を構築する。
ID認識型ネットワーキングをパイロット — 内部サービスパスを1つ選んでCiliumでmTLSを有効にする。オーバーヘッドを測定する（ネタバレ：最小限）。
Fleet Managerを評価 — 2つ以上のクラスターを運用しているなら、クロスクラスターネットワーキングはカスタムの接着剤削減だけで元が取れる。

小さな実験、素早いフィードバック。それが常に正しい手。

まとめ

KubeConのアナウンスは圧倒的になりがちですが、今回のバッチはAKS上の.NETチームにとって本当に針を動かします。メッシュオーバーヘッドなしのより良いネットワークセキュリティ、本物のGPUオブザーバビリティ、より安全なアップグレード、そしてより強力なAIインフラストラクチャの基盤。

すでにAKSを使っているなら、運用ベースラインを強化する絶好のタイミングです。.NETワークロードをKubernetesに移行する予定なら — プラットフォームは大幅にプロダクションレディになりました。