---
title: 新 さよなら？Azureクラシック
tags: 
author: [kotaro harada](https://www.docswell.com/user/6258098609)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/V7NW1X6478.jpg?width=480
description: 新 さよなら？Azureクラシック by kotaro harada
published: May 10, 25
canonical: https://www.docswell.com/s/6258098609/K6V244-2025-05-12-195036
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/V7NW1X6478.jpg)

新 さよなら？
Azureクラシック
2025/05/10
NTTデータ先端技術株式会社
経営企画部 Microsoft技術センター
原田 幸太郎
© 2025 NTT DATA INTELLILINK Corporation


# Page. 2

![Page Image](https://bcdn.docswell.com/page/YJ9X58L4E3.jpg)

自己紹介
所属:NTTデータ先端技術株式会社
代表的なインダストリー＆プロジェクト経験
役割:コンサルタント
◼ 医薬系 Azure 基盤構築プロジェクト
医薬系企業の Azure によるアプリケーション基盤構築プロジェクトに参画。
グランドデザイン策定から入り、プロジェクトキックオフ後は Azure 基盤チームのマネジメント
を実施し、カットオーバー後の保守運用に関わる技術支援を実施。
(技術要素：Azure 基盤 IaaS / 運用基盤)
氏名:原田 幸太郎 (ハラダ コウタロウ)
職務経験年数：
ITスペシャリスト（プラットフォーム）：15年
◼ 金融系 Azure 基盤構築プロジェクト
金融系企業の Azure によるマルチシスシステム基盤構築プロジェクトに参画。
グランドデザイン策定から提案支援から入り、プロジェクトキックオフ後は Azure 基盤チーム
のマネジメントと並行してコンサルおよび技術支援を実施。
(技術要素：Azure 基盤 PaaS・IaaS / セキュリティ基盤 IDS・IPS / 運用基盤)
ITスペシャリスト（クラウド）：10年
教育とコンピテンシー
業務経験
◼ 全社横断組織でのコンサルティング・技術開発を担当
◼ 専門分野はクラウド（Azure ・ Microsoft 365） ・ デバイス（PC ・ モバイル ・ VDI）、
他 Microsoft プロダクト全般
◼ Azure 技術コンサルティング
医薬系：Azure 基盤の設計・構築および維持運用改善に関するコンサルティング（技術
要素：Azure Monitor / Log Analytics ）
保険系：Azure データ分析基盤のグランドデザイン策定～ PoC 実施に関するコンサル
ティング（技術要素：Azure SQL MI / Power BI ）
化学系：Azure IoT 基盤のグランドデザイン策定～ PoC 実施に関するコンサルティング
（技術要素：Azure IoT Hub / Raspberry Pi ）
情報・通信系：Azure 基盤構築自動化のグランドデザイン策定～ PoC 実施に関するコ
ンサルティング（技術要素：Azure Resource Manager / Powershell ）
保有資格
◼ 各種 情報処理技術者試験
◼ Microsoft 認定資格
✓ Microsoft Certified: Azure Solutions Architect Expert
✓ Microsoft Certified: Azure DevOps Engineer Expert
✓ Microsoft Certified: Power Platform Solution Architect Expert
✓ Microsoft Certified: Cybersecurity Architect Expert
✓ Microsoft 365 Certified: Administrator Expert
✓ Microsoft Certified Trainer 2023-2024
◼ マイクロソフトプロダクト関連 技術評価
Azure 検討ガイドライン：Azure の技術要素・ノウハウをまとめたガイドラインおよびデザイ
ンパターン資料（技術要素：Azure IaaS / Azure PaaS ）
性能解析方式ガイドライン：Windows サーバー性能解析のガイドライン資料（技術要
素：SQL Server / IIS ）
特徴/業務知識
◼ Microsoft プロダクト全般への知見
◼ Microsoft プレミアサポートの特徴を理解した上でのインシデント対応
※一部、経歴を抜粋して記載しております
2


# Page. 3

![Page Image](https://bcdn.docswell.com/page/GJ82Y8XVJD.jpg)

Azureクラシックの廃止
https://azure.microsoft.com/en-us/updates/cloud-services-retirement-announcement/
(以下機械翻訳)
クラウド サービス (クラシック) 展開モデルは 2024 年 8 月 31 日に廃止されます
公開日: 2021年8月24日
2024 年 8 月 31 日をもって、Cloud Services (クラシック) デプロイ モデルは廃止されます。 その日までに、このモデルを使
用してデプロイされたサービスを、Azure Resource Manager の Cloud Services (拡張サポート) に移行する必要があります。こ
れにより、次のような新しい機能が提供されます。
• デプロイメント テンプレートのサポート。
• ロールベースのアクセス制御。
• 地域の回復力。
必要なアクション
Cloud Services (クラシック) を使用して展開されたクラウド サービスを引き続き使用するには、 2024 年 8 月 31 日までに
Resource Manager でCloud Services (拡張サポート) に移行してください 。
3


# Page. 4

![Page Image](https://bcdn.docswell.com/page/LJL24R8RER.jpg)

Azureクラシックとは？
Q.
Azureクラシックについて教えてください。
A.
Azureクラシックは、Microsoft Azureの初期の管理モデルで、クラシックポータルを通じてリソースを管理します。このモデルは、
Azureが最初に提供されたときに使用されていたもので、以下の特徴があります：
• クラウドサービス: リソースはクラウドサービス内に配置され、仮想マシンやストレージアカウントなどが含まれます。
• リソースグループの欠如: 現在のAzure Resource Manager (ARM)とは異なり、リソースグループの概念がありませんでし
た。
• 管理API: Azure Service Manager (ASM) APIを使用してリソースを管理します。
Azureクラシックは、現在のARMモデルに比べて柔軟性や効率性が劣るため、MicrosoftはARMへの移行を推奨しています。
ARMでは、リソースグループを使用してリソースを論理的にグループ化し、より効率的に管理できます。
4


# Page. 5

![Page Image](https://bcdn.docswell.com/page/47M8KR6P7W.jpg)

Azureクラシックとは？
Q.
Azureクラシックの公開から廃止までの年表を作成してください。
A.
• 2008年10月: Azureの初期バージョンが発表され、クラシックデプロイメントモデルが導入されました。
• 2010年2月: Azureが正式にリリースされ、クラシックモデルが広く利用され始めました。
• 2013年4月: AzureクラシックVMが一般提供開始。
• 2014年: Azure Resource Manager (ARM) が導入され、クラシックモデルに代わる新しいデプロイメントモデルが提供
されました。
• 2020年2月28日: クラシックVMの新規作成が非推奨となり、既存のクラシックVMの管理も非推奨となりました。
• 2021年8月: クラシックストレージアカウントの廃止が発表されました。
• 2023年3月1日: クラシックVMのサービスが完全に廃止され、稼働中のVMは停止されました。
• 2024年8月31日: クラシックストレージアカウントが完全に廃止される予定です。
5


# Page. 6

![Page Image](https://bcdn.docswell.com/page/P7R5XRPYJ9.jpg)

何が「新」になったのか
死活監視を
AI エージェント化しました
6


# Page. 7

![Page Image](https://bcdn.docswell.com/page/PJXK6R347X.jpg)

準備作業
https://learn.microsoft.com/ja-jp/microsoftteams/platform/toolkit/build-an-ai-agent-inteams?tabs=buildnew
VSCode と Teams はインストール済みとしますと、
1. Teams Toolkit 拡張機能をインストール
2. Node.js をインストール
https://learn.microsoft.com/ja-jp/microsoftteams/platform/toolkit/build-environments#nodejsversion-compatibility-table-for-project-type に Teams Tookit との互換性テーブルがあります
3. Azure OpenAI Service のデプロイ
4. VSCode プロジェクトの作成
https://learn.microsoft.com/ja-jp/microsoftteams/platform/toolkit/build-an-ai-agent-inteams?tabs=buildnew#create-a-new-ai-agent-project
で準備完了です。
7


# Page. 8

![Page Image](https://bcdn.docswell.com/page/3JK51RYP7D.jpg)

コードの追加
今回は既存の Logic Apps の呼び出しと Web API による検索 の単純実装でしたので、
https://learn.microsoft.com/ja-jp/microsoftteams/platform/toolkit/build-an-ai-agent-inteams?tabs=buildnew#create-an-ai-agent-using-teams-ai-library に記載の、
1. src/prompts/planner/actions.json にアクションのスキーマを記述
2. src/app/actions.js に追加するアクションそのものを記述
3. src/app/app.js にアクションを登録
3点セットを追加していきます。
8


# Page. 9

![Page Image](https://bcdn.docswell.com/page/LE3KQ894E5.jpg)

src /prompts /planner/ actions.json にアクションスキーマを記述
実装の過程でなかなか興味深い事象にあたりましたのでご紹介。
GitHub Copilot で「searchWeb というアクションのスキーマを定義してください、なおパラメータは不要です。」とお願いすると、
{&quot;name&quot;: &quot;searchWeb&quot;,&quot;description&quot;: &quot;Search using web&quot;,&quot;parameters&quot;: {&quot;type&quot;: &quot;object&quot;, &quot;properties&quot;: {}}} と言うコードが提案
されるのですが、これこのまま実行すると No arguments were sent with called action. とエラーが発生します。
その際内部的には、“action”:{“name”:“searchWeb”,“parameters”:{}} と言う json が生成されているのですが…
何とこのエラーを理解して(くれたんだろうと思います)、“action”:{“name”:“searchWeb”,“parameters”:{“query”:“クラシックストレージア
カウント リタイアメント”}} と自動的に補完して投げなおしてくれて、結果エラーが発生せず正常に検索結果が返ってくると言う動作
がありました。
まあ自動補完が良いのか悪いのかというのはありますが、AI エージェントの実力の一端を見た気がしました。
ちなみに正解は {“name”: “searchWeb”,“description”: “Search using web“} と parameters を記述しなければ良いだけなので
すが、GitHub Copilot がなかなか頑固でこれを提案してくれないというオチもありました。
9


# Page. 10

![Page Image](https://bcdn.docswell.com/page/8ED39MG57G.jpg)

src /app /actions.js に追加するアクションそのものを記述
ここには GitHub Copilot バッチリ効きました。
「searchWeb というアクションのスキーマを定義してください、なおパラメータは不要です。」とお願いすると、
async function callLogicApp(context, state, parameters) {
// Logic App のエンドポイントは環境変数から取得
const logicAppUrl = process.env.LOGIC_APP_URL;
～～～ 略 ～～～
try {
// 必要に応じて parameters を POST ボディとして送信
const response = await axios.post(logicAppUrl, parameters, {
headers: {
&quot;Content-Type&quot;: &quot;application/json&quot;,
},
});
const result = response.data;
await context.sendActivity(&quot;Logic App の呼び出し結果: &quot; + JSON.stringify(result));
return &quot;Logic App called successfully.&quot;;
～～～ 略 ～～～
}
とほぼそのまま正解なコードが提案されました。
10


# Page. 11

![Page Image](https://bcdn.docswell.com/page/V7P4ZR3DE8.jpg)

AI エージェントっぽい動作の確認
2つ期待通りの動作を確認することができました。
1. 複数のアクションを自律的に実行してくれる
今回 Logic Apps による死活監視 と Web API による検索 の2つのアクションを実装しています。
もちろん単体でも有用に動作しますが、そこは AI エージェント「クラシックストレージアカウントの状態を確認してください、
もし稼働中の場合はリタイアメントの情報を検索して提示してください」とプロンプトを投げると、ちゃんと Logic Apps の実
行結果を判定しつつ2つのアクションを実行してくれます。
これ極められたら Power Automate だとなかなかに面倒な制御動作を、AI エージェントお任せにできちゃうんじゃない
かとの希望を持たせる結果でしたね。
2. 戻り値を自律的に解釈してくれる
当初の実装では Logic Apps の実行結果をパースして If 文で判定していましたが AI エージェントに任せるべく戻り値
そのものを渡したところ、見事に True/False を解釈して適切なメッセージを返してくれました。
API コールして戻り値をそのまま解釈させれば1の制御動作も含めてよしなにやってくれる、なんて夢。
11


# Page. 12

![Page Image](https://bcdn.docswell.com/page/2JVXWR4G7Q.jpg)

まとめ
AI エージェント触るのほぼ初めてでしたけど面白いですね、デ
バックしてると AI エージェントが捻り出すプロンプトの流れが追え
て新鮮でした。
次回はハードコーディングしちゃってる部分を取り除きつつ、アク
ションの中でのパラメータやコードの自動生成でも組み込んでみ
ようかと思います。
クラシックストレージアカウントがリタイアするまでのこの営み、果た
してどこまで行けるのか。
12


# Page. 13

![Page Image](https://bcdn.docswell.com/page/5EGVDMKDEL.jpg)



