次のレベルのAzure IaC：Azure Verified Modules
Infrastructure-as-Code（IaC）、とりわけTerraformを用いたIaCは、当社のAzure Foundationの中核をなす要素であり、あらゆるクラウド移行の土台でもあります。IaCを体系的に使えば、クラウドサービスの導入も新しい製品の開発も速くなります。ここで浮かぶのが次の問いです。どこから始めるのが一番よいのでしょうか。
Azure Verified Module - Microsoftのベストプラクティスに沿ったIaC
Microsoftはこのテーマに本腰を入れて取り組み、Azure Verified Modules (AVM)という、ベストプラクティスに沿ってAzureにリソースを体系的にデプロイするためのフレームワークを作り上げました。
AVMには3つの種類があります。
- Resource Modules - 定義された1つのクラウドリソースをデプロイする
- Pattern Modules - 定義された1つのクラウドワークロードをデプロイする
- Utility Modules - Resource ModulesやPattern Modulesから利用される補助モジュール
統一された標準を保つため、Microsoftは新しいAVMリソースが満たすべき一連の要件を定めています。これはTerraformにも、Microsoft Azure独自のIaC言語であるBicepにも当てはまります。
どのAVMにもMicrosoftの担当者が割り当てられており、作成、継続的な開発、問題への対応を担当しています。
利用できるモジュールはすべてオープンソース（MITライセンス）として、Azure GitHub Organisationの公開GitHubリポジトリで入手できます。モジュールがうまく動かない場合や、必要なパラメーターがまだない場合は、誰でも問題を報告したり、開発に加わったりできます。
AVMはどのように始めるのか
AVMはTerraformやBicepの他のモジュールと同じように動作します。独立して呼び出され、必要なパラメーターをすべて受け取ります。AVMの作成要件により、必要なパラメーターは最小限に抑えられ、無理なく使い始められるようになっています。
Terraformの例です。追加のデータディスクを持つ仮想マシンをデプロイするには、Azureで少なくとも次のリソースが必要になります。
- azurerm_windows_virtual_machine または azurerm_linux_virtual_machine
- azurerm_network_interface
- azurerm_managed_disk
- azurerm_virtual_machine_data_disk_attachment<
これらのリソースにはそれぞれ必須のパラメーターがあり、リソースグループ名、対象リージョン、リソース自体の名称など、何度も繰り返し登場するものが少なくありません。
AVMを使うと、自分のコード内での呼び出しは必要なパラメーターを備えた単一のリソースに簡略化され、その先はモジュールの中で処理されます。AVMはMicrosoftの代表的なベストプラクティスをあらかじめ組み込んでいるため、多くのパラメーターには既定値が設定されており、追加の設定は不要です。たとえば多くのモジュールでは、TLS 1.2が既定値になっていたり、パブリックアクセスがブロックされていたりします。
使いたいリソースのAVMがまだない場合はどうするのか
AVMのオープンソースライセンスがあるので、フレームワークを土台に自分で開発を始められます。後日Microsoftの担当者が公式のAVMリソースの作成に着手した場合には、オープンソースの考え方どおり、それまでに積み上げた成果でその開発を後押しできます。
GKVM - glueckkanja ❤️ Open Source
glueckkanjaはまさにこのアプローチをとっており、AVMフレームワークを基にしたモジュールを開発し、その後に一般公開する取り組みでもお客様を支援しています。
当社はこれらのモジュールをGKVM（GlueckKanja Verified Modules）と呼んでいます。AVMの要件を満たしているだけでなく、数多くのプロジェクトで得た当社自身の知見も反映されているからです。
GKVM Resouce Modules:
GKVM Pattern Modules:
モジュールに機能を追加するきっかけになるイシューは、どれも歓迎します。
参考リソース
お問い合わせはこちら
Azure上のInfrastructure as Codeについてもっと知りたい方は、ぜひご連絡ください。Azure Verified Modulesを使って、より速く、より標準化された、より持続可能なかたちでクラウドを活用する方法をご紹介します。最初の一歩でも、スケールする実装でも、当社は経験とベストプラクティスでお手伝いします。ご連絡をお待ちしています。
関連記事
MFA向けSMSの終わり
企業がいまフィッシング耐性のある、できるだけパスワードレスな認証方式へ移行すべき理由。
ClickFix。ユーザー自身がエクスプロイトになるとき、そしてそれを止める方法
ClickFixはユーザーを自分自身への攻撃者に変えます。偽のCAPTCHA、コピー＆ペースト、そして悪意あるコードがメモリ上で走り、ディスクには何も残りません。Microsoft Defenderがこの攻撃をどう検知するのか、検知はどこで限界に達するのか、そしてRunMRUハントと4つの防御レイヤーでその隙間をどう埋めるのかを解説します。
管理業務と日常業務を1台のPCで。Game Overです。
CIOにとってテナントが1つでは足りない理由と、2つ目がめったに検討されない理由。Managed Red Tenantは管理業務をオフィス環境からアーキテクチャとして分離し、Managed Dark Tenantは防御が破られてもなお組織が動き続けられるようにします。それが運用モデル、SOCのシグナル、そしてNISG 2026による証明義務にとって何を意味するのかを解説します。
4度のLeader。ISGドイツ調査2026のglueckkanja
ISG Provider Lens®調査2026は、ドイツにおいてglueckkanjaを4つのクアドラントでLeaderに位置づけました。Microsoft Productivity and Business Process ServicesとAzure Managed Servicesの、それぞれLarge MarketとMid Marketです。調査の名称はMicrosoft AI and Cloud Ecosystemに変わり、評価の尺度も移りました。AIとエージェントのワークロードを制御可能なかたちで運用できるかが問われています。
Rising StarからLeaderへ。ISGスイス調査2026のglueckkanja
ISG Provider Lens®調査2026は、スイスにおいてglueckkanjaをMicrosoft AI and Cloud Ecosystemクアドラントの、Azure Managed Services領域とMicrosoft Productivity and Business Process Services領域でLeaderに位置づけました。ベルンでの市場参入から2年、Rising Star選出から1年でのことです。
Outbreak。OpenAI／Hugging Faceの事案が示すこと、示さないこと
AIエージェントがテスト環境から脱出し、ゼロデイを見つけ、別の企業をハッキングする。映画の脚本のようですが、2026年7月に実際に起きました。冷静に位置づける時期です。少しの心理学、2人のセキュリティ専門家、そしてそれが自社の防御にとって何を意味するのかという問いとともに。
LeaderそしてRising Star。ISGサイバーセキュリティ調査2026のglueckkanja
ISG Provider Lens®調査 Cybersecurity 2026は、glueckkanjaをNext-Gen SOC/MDR Services（Midmarket）クアドラントのLeaderに選出しました。Next-Gen SOC/MDR Servicesの全体市場では、当社はRising Starです。ISGは当社の平均を上回る成長、Microsoftセキュリティに関する深い専門性、そしてドイツ国内から提供する24時間365日のSOCを評価しています。
The Holy Trinity：AIが実際に働くために本当に必要なもの
ある製造業の企業が、14,000あるSKUのうちどれが実際に利益を生んでいるのかを知りたいと考えました。答えは3つのシステムの中にありますが、それらは一度もデータを1件たりともやり取りしたことがありません。少し前までは、その答えを得るのに3つの部門、2週間、そして相当な善意が必要でした。2026年初頭からは、AIがこの問いに数分で答えられます。データを走査し、関連を結び、推奨を出す。ただし、アクセスできることが前提です。
契約書にサインしたあと：当社のオンボーディングはこう進みます
契約書にサインが済み、大きな一歩は終わりました。では、ここからどうなるのでしょうか。PreBoardingからチームでの最初の1週間まで、当社のオンボーディングの舞台裏をご案内します。
Microsoft Frontier Partner：当社もその一員です
最近、Microsoft AI Cloud Partner Programに新たな最高位の称号としてFrontier Partner Badgeが設けられました。Microsoftがこれを授与するのは、ワークプレイスからクラウドプラットフォーム、セキュリティ、そしてAIアプリケーションそのものに至るまで、Microsoftスタック全体でAIプロジェクトを確実に届けられると実績で示した、世界でもごく限られたパートナーだけです。DACH圏でこのグループに属するのは数社にすぎず、当社はそのうちの1社です。
チャリティのために160キロ
同僚11人、16周、160キロ、雷雨、そして表彰台。glueckkanjaはFrankfurter Runden 2026に参加し、走った1周ごとにVAIR e.V.へ寄付しました。同団体はオフェンバッハでインクルーシブなスポーツ・カルチャーパークを建設しています。
未知のAMOSスティーラーの解剖：アラートから免疫獲得まで数時間
これまで文書化されていなかったAMOSスティーラーの亜種が、macOSエンドポイントを侵害しました。既知のハッシュはなく、公開データベースにC2データもありません。当社のSOCは6層の難読化を解体し、すべての指標を抽出したうえで、業界がこの検体を目にするよりも前に、数時間以内ですべてのSOCのお客様へ保護を配布しました。
Edgeを唯一の社内標準ブラウザーにすべき理由
Chromeを本気で選んだ企業はほとんどありません。独自の同期ロジック、独自のアカウント管理、独自のポリシー画面を抱えたまま、ただそこにあっただけです。一方でMicrosoft Edgeは、すでに動いているインフラ、つまりEntra ID、Intune、Defenderに直接組み込まれます。本記事では、移行がどのようなものか、IntuneのポリシーでどのようにChromeをランディングページへリダイレクトするか、そして2つのブラウザーを並行運用するのをやめると何が不要になるかを紹介します。
必要だったのは管理者アカウント1つだけでした
2026年3月11日、Handalaは79か国の端末を消去しました。そのために必要だったのは、侵害されたIntuneの管理者アカウント1つだけです。マルウェアもエクスプロイトもなく、正規の管理ツールが所有者自身に向けられました。何が起きたのか、なぜそれが通用したのか、そして塞ぐべき2つのアーキテクチャ上の穴について説明します。
6つのAgent。4週間。実際の運用へ。
6社、4週間のビルドフェーズ、6つの動作するAI Agent。これが第1回glueckkanja AI Agent Hackathonの成果です。Kiekert、Dr. Oetker、Eckes-Granini、igefa、lila logistikがCopilot StudioでAgentを構築し、それらは現在すでに本番で稼働しています。そこで何が生まれ、この形式がどのように機能するのかを紹介します。