Microsoft Teams Blog articles ... ノート

Microsoft Teams Blog articles 日本語

TechNet 上の Microsoft Teams Blog は、Microsoft Teams についての様々なトピックをカバーする専門的なプラットフォームです。製品改善、ベストプラクティスなど、ユーザーエクスペリエンスを向上させるための情報が含まれています。このブログは、Microsoft 製品チームのメンバー、MVP、フィールドの専門家たちが執筆しています。ブログの投稿は、Microsoft Teams の様々な側面を扱い、設定、デプロイメント、トラブルシューティング、ユーザーフィードバック、共有された知識などをカバーしています。

ノートのスレッド

最新のMixed Reality Linkアップデートは、Mixed RealityヘッドセットとWindows PC間の接続を強化します。ヘッドセットは、Windowsアプリケーションのマイクとして機能できるようになりました。これにより、装着しているデバイスから直接、会議、ゲーム、チャットでのより自然なコミュニケーションが可能になります。さらに、ヘッドセットの前面カメラは、Windowsアプリケーションがあなたの視点を共有するために利用できるようになります。これは、あなたがリアルタイムで何を見ているかを他の人に示すことができることを意味します。Meta Questユーザーは、アバターカメラを利用して、Windows上でアバターとして表示できるようになりました。この機能により、ユーザーは従来のウェブカメラを必要とせずに、仮想インタラクションでのプレゼンスを維持できます。これらの新しい機能は、Mixed Reality Linkバージョン26.9105.9070.0以降で利用可能です。Mixed Reality Link経由でヘッドセットを接続するだけで、Windowsでこれらの新しいマイクとカメラソースが有効になります。これらのソースには、マイク、パススルーカメラ、およびMetaユーザー用のアバターカメラが含まれます。これらのデバイスは、お好みのアプリケーション内で選択できます。
Microsoft Foundry は、A2A Tool およびプロトコルバージョン 1.0 をサポートする A2A エンドポイントの一般提供により、エージェント間のコラボレーションを強化しました。既存の統合では、引き続き古い a2a_preview ツールとプロトコルバージョン 0.3 を使用できます。ホストエージェントは、MCP を介して公開される Foundry Toolboxes を通じて A2A ツールにアクセスできます。これらの機能により、エージェントが専門化し、スキルを共有し、境界を越えて安全に協力するマルチエージェントシステムを作成できます。標準化された A2A プロトコルにより、カスタム API や密結合されたオーケストレーションロジックの必要がなくなります。エージェントは、エージェントカードによる発見と A2A プロトコルによる通信を使用して、実装の詳細を複雑に知ることなく、他のエージェントに支援を要求できるようになりました。Foundry でホストされる A2A エンドポイントの場合、発見とエンドポイントアクセスは Microsoft Entra ID 認証によって保護されます。外部エージェントは、エージェントカードとやり取りし、A2A プロトコルを使用して、A2A エンドポイントとして公開されている Foundry エージェントを発見および呼び出すことができます。逆に、Foundry エージェントは A2A Tool を使用して別の A2A 互換エージェントに接続でき、これは RemoteA2A プロジェクト接続を通じて構成されます。ホストエージェントは、Foundry Toolbox をアタッチすることで A2A 機能を統合し、その後 A2A Toolbox Tool と RemoteA2A 接続を呼び出してリモートエージェントとやり取りします。認証は重要なアーキテクチャ上の決定として浮上し、RemoteA2A 接続には none、custom-keys、oauth2、user-entra-token、project-managed-identity、agentic-identity などのオプションがありますが、着信 A2A エンドポイントは Microsoft Entra ID 認証を厳密に強制します。Foundry エージェントを A2A エンドポイントとして公開するには、機能とエージェントエンドポイント上の A2A プロトコルを記述するエージェントカードを構成する必要があります。
Azureスポンサーシッププログラムを利用していた企業が、Azure AI Foundryを通じてClaudeモデルを利用することがスポンサーシップクレジットでカバーされると誤解していました。ClaudeはAzure Marketplaceの請求とみなされ、スポンサーシップから明確に除外されていることが判明しました。この誤解により、3日間で約22,000カナダドルの直接請求が発生しました。同社は、Claudeが別途Marketplaceの費用を発生させることや、スポンサーシップが適用されないことについて、デプロイ中に明確な警告を受けなかったと述べています。また、設定した予算も、この予期せぬ支出についてタイムリーかつ有益なアラートを提供しませんでした。これらの請求の発見はほぼ偶然であり、コストがどれだけ高くなる可能性があったかについての懸念が生じています。Microsoftサポートを通じてこの問題を解決しようとする試みは、適切なチケットの作成における困難さや、一般的または役に立たない自動応答の受信により、フラストレーションの多いものとなっています。一部の推奨されるコスト管理ツールも、レガシーなスポンサーシップサブスクリプションでは利用できないか、制限されていると報告されています。1つのサポートチケットは解決されないままクローズされ、懸念を増幅させています。同社は、状況をレビューできる権限を持つ担当者に、標準的なスポンサーシップサポートを超えて、この請求に関する紛争を緊急にエスカレートさせることを求めています。例外的な状況下でのMarketplace請求の異議申し立て方法と、未解決のサポートケースのエスカレーション方法についてガイダンスを求めています。最終的に、同社は、正当な費用を回避しようとしているのではなく、明確な警告の欠如と困難なサポート体験による支援を求めていることを強調し、状況のレビューを希望しています。
Windows Admin Center はバージョン 2610 のプレビュー版をリリースしました。このバージョンでは、Administration Mode (aMode) と Virtualization Mode (vMode) が単一のインストーラーに統合され、デプロイが簡素化されました。この統合インストーラーはセットアップを合理化し、管理オーバーヘッドを削減すると同時に、ユーザーはインストールごとに 1 つのモードのみを選択できます。vMode の新機能には、より少ない権限とテナントレベルの管理者同意を必要としない再設計された登録エクスペリエンスによる、Azure Arc のオンボーディングの容易化が含まれます。このアップデートでは、vMode 環境向けの組み込みバックアップおよび復元機能、および証明書ライフサイクル管理も導入されています。本番環境では、vMode は Active Directory Certificate Services を介した証明書の管理をサポートし、ガバナンスとスケーラビリティを強化します。vMode のネットワーキングの改善は、より優れたインテントの可視性、ワークフローを再起動せずにネットワーキング状態を更新する機能、およびストレージ VLAN オーバーライドのサポートを提供します。VM Conversion ツールは、必要な VMware VDDK パッケージに影響を与える変更により削除され、System Center Virtual Machine Manager や Azure Migrate などの代替手段が推奨されています。ライブマイグレーション機能は、vMode で管理されるマシン用の Virtual Machines ツールに統合され、ダウンタイムを最小限に抑えたシームレスな VM 移動を可能にします。Windows Admin Center SDK はバージョン 6.0.0 に更新され、React ベースの拡張機能の作成とテストのサポートが追加されました。インストーラーの失敗を解決し、GPU ツールを vMode で利用可能にするなど、いくつかの重要なバグ修正が実装されました。
Azure のネイティブサービスは、堅牢なガバナンス、監視、コスト管理を提供する FinOps 対応ランディングゾーンの基盤を形成します。Azure エステートがサブスクリプションやビジネスユニット全体に拡大するにつれて、特定のアプリケーションの所有権、依存関係、および真のコストを理解する上でギャップが生じます。ここで、追加の管理プラットフォームが、ネイティブ機能を置き換えるのではなく、補完することができます。これらのプラットフォームは、リソース中心のビューだけでなく、アプリケーション中心の監視を提供することで、Azure の基盤を強化します。多数のサブスクリプションやリージョンにわたる監視を統合し、トラブルシューティングを容易にします。アラートシステムは、アラートを特定のアプリケーションとその影響に関連付けることで、より実行可能にすることができます。決定論的な問題に対する自動修復は、これらのプラットフォームを通じてより合理化されます。FinOps の場合、ビジネスユニットやアプリケーションに費用を割り当てることで、より深いコスト分析が可能になります。支出パターンの異常検出が可能になり、関係者に異常な逸脱を警告します。プラットフォームは、リソースの適正化とコスト削減のために、利用率の低いリソースを特定することもできます。ライブ Azure 環境を反映した最新のドキュメントを維持することも別の利点です。Turbo360 のような追加の運用レイヤーは、Azure の基盤の上に位置し、アプリケーション監視、FinOps の洞察、および運用自動化を強化します。このようなプラットフォームは、リソース数が多く、複数のアプリケーションがあり、アラート量が significant な、大規模で複雑な Azure 環境に価値があります。追加プラットフォームを採用するという決定は、ネイティブサービスでは効率的に対処できない明確な運用上のニーズと測定可能なビジネス成果によって推進されるべきです。
CdXz5zHNQW_aOH5aQ1ZRW.png
mssql-django 2.0 リリースでは、既存の pyodbc メソッドに加え、Microsoft の新しい mssql-python ドライバーのサポートが導入されました。これにより、ユーザーは Django 設定内でデータベースエイリアスごとに好みのドライバーを選択できます。新しい mssql-python ドライバーは、必要な ODBC ドライバーを含めることでデプロイを簡素化し、個別のインストール手順を不要にします。認証、プーリング、datetimeoffset 値などのさまざまな機能を処理します。ただし、このドライバーにはいくつかの違いがあり、host_is_server や MARS のような特定の pyodbc オプションは無視されます。名前付き DSN、FreeTDS、MARS、または Always Encrypted に依存している場合は、pyodbc のままにしてください。このリリースでは、Python、Django、および SQL Server のサポートバージョンが更新されました。古い Python および Django バージョンは公式にはサポートされなくなりました。MARS 設定、F() 式でのブラケットワイルドカード、inspectdb でのスキーマ名引用、localhost への接続に関する問題など、いくつかのバグが修正されました。pytz への依存関係が削除され、タイムゾーン処理のために標準ライブラリの zoneinfo モジュールに切り替えられました。2.0 へのアップグレードの前提条件は、オペレーティングシステムに互換性のある mssql-python ディストリビューションが存在することです。
SMBはAIの重要性を認識していますが、ガイド付きで低リスクのエントリーポイントを必要としています。Copilot in 30は、パートナーがパッケージ化した25人のMicrosoft 365 Copilot Businessユーザー向けの無料の30日間トライアルを提供します。これをMicrosoft Marketplaceのオファーとして公開することで、SMB顧客にリーチするためのスケーラブルなストアフロントが作成されます。この構造化されたアプローチは、AIへの好奇心を長期的な顧客関係と継続的なマネージドサービスに変革します。高い需要と限られた社内AI能力を持つSMBセグメントは、この再現可能なパートナー主導のソリューションに最適です。Microsoft 365 Copilot Businessは、使い慣れたアプリケーションに統合されたアクセスしやすいAIツールを提供します。パートナーが管理する30日間のトライアルは、ユーザーが具体的な価値を体験できるように導きます。パートナーは、このトライアルを持続的なAI習慣に変える上で極めて重要です。このオファーには、特定、計画、アクティベーション、体験、コンバージョンといった特定のステージが含まれます。収益は、トライアルからだけでなく、その後の有料サブスクリプションとマネージドサービスからも生まれます。パートナーは、Microsoftのインセンティブと資金を活用して、このジャーニーをサポートできます。長期的なエンゲージメントは、導入管理、ライセンス拡大、エージェント開発、セキュリティに焦点を当てます。これにより、パートナーが不可欠なAIアドバイザーとしての地位を確立する、継続的で成果に基づいたサービスにつながります。
リテール組織は、Fabric IQ、Ontology、およびERP MCPを備えたCopilot Studioエージェントを使用して、サードパーティシステムおよびD365 Finance and Operationsからの過去のプロモーション販売データを分析しています。このシステムは、顧客を都市別に店舗にリンクし、販売イベントを製品および店舗にリンクすることにより、トップパフォーミング店舗、成功した販売イベント、および顧客フットプリントを特定するのに役立ちます。リテーラーは現在、プロモーション販売に影響を与える調達リスクの特定と、都市間の最適なマーケティング支出配分の決定という新たな課題に取り組むことを求めています。これらの新たなニーズを満たすために、Foundry IQ、Fabric IQ、およびWeb IQをナレッジソースとして活用するFoundryエージェントが提案されています。Foundry IQは、Azure AI Searchによる正確な結果をバックアップとして、Fabric IQ、Work IQ、Web IQ、SharePoint、およびカスタムエージェントを含むさまざまなソースからのインサイトを接続する、推論およびオーケストレーションレイヤーとして機能します。このソリューションには、サードパーティシステム(製品、店舗、販売イベント)およびD365 F&O(顧客データ)からのデータソース、顧客と店舗の都市の整合性、および販売イベントと製品と店舗の関連付けなどの確立された関係を含む、いくつかの前提条件が必要です。国固有のマーケティングポリシーはSharePointに保存され、Web IQはサプライヤーニュース、市場の混乱、および地政学的なイベントに関するリアルタイム情報のために設定されています。Finance and OperationsデータはFabric Lakehouseに接続され、他のデータはLakehouseに取り込まれ、顧客、店舗、製品、およびイベントデータを組み合わせたFabric Ontologyを形成します。LLMデプロイメントと適切な認証を備えたAzure Foundryプロジェクトも必要です。アーキテクチャパターンは、エージェントの推論を容易にするためにこれらのコンポーネントを統合することを含みます。構成には、Azure Searchサービスのセットアップ、ERP MCPをツールとして使用したAzure Foundryポータルでのエージェントの作成、およびFabric IQ、Web、SharePointを含むFoundry IQナレッジの設定が含まれます。この統合されたナレッジベースは、Retail Growth Intelligenceエージェントによって使用されます。エージェントは、M365、Teams、またはCopilot Studioなどのさまざまなチャネルに公開できます。エージェントは、「調達のタイムラインまたはプロモーション販売に影響を与えるその他のリスクはありますか?」のような複雑な質問に答えることができます。これは、エンティティ関係の理解のためにFabric IQ、運用調達データのためにERP MCPを介したD365 F&O、ポリシー検証のためにSharePoint、および外部市場リスクのためにFoundry IQ/Web Intelligenceを組み合わせて行われます。このプロセスには、今後の販売イベント、発注書および在庫データによる製品在庫の可用性、およびポリシーコンプライアンスをカバーするサブ質問が含まれます。このアプローチは、ばらばらの情報を統一された意思決定支援に変換します。これにより、運用上の事実とビジネスコンテキストおよび外部シグナルを相関させることにより、より迅速で高品質かつスケーラブルなAI主導の意思決定が可能になり、プロアクティブなリスク検出とビジネス上の優位性の向上が実現します。
MLモデルは、評価なしでは時間の経過とともに劣化します。これは、会話データエージェントではしばしば見過ごされる問題です。Genie Ontologyは、特にGenie Agent Benchmarksを通じて、エージェントを継続的に評価および改善することで、この問題に対処します。ベンチマークには、個別の会話が含まれ、質問の種類に応じて2つのモードのいずれかで評価されます。チャットモードでは、エージェントが生成したSQLまたはその結果を「正解」の回答と比較し、「良い」結果と「悪い」結果に対して客観的なルールが適用されます。エージェントモードは、複数ステップのテキストベースの推論レポート用であり、LLMジャッジが応答をオプションの評価ノートと比較して評価します。チャットモードの重要な設計上の詳細は、正当なバリエーションを報酬として与えながら構造的なエラーをフラグ付けする能力であり、ベンチマークへの信頼を育みます。ベストプラクティスでは、包括的なテストを保証するために、ビジネス上の質問ごとに2〜4のフレーズバリエーションを登録することが推奨されています。ベンチマークの実行後、Genie Codeは結果を分析し、特定されたギャップに対処するための指示またはコンテキストの調整を提案します。この「バッチレビュー」は、実際の使用データにも適用され、プロアクティブな問題解決を可能にします。ただし、ユーザーフィードバックはエージェントの動作を自動的に変更しないため、人間のレビューは不可欠です。正解SQLの品質も重要であり、ツールは長期的な精度トレンドを内部に保存しません。ベンチマークへの初期投資は、変更を効率的に検証し、エージェントの継続的な信頼性を確保するために不可欠です。
この記事では、一貫性の原因となる手動の方法から脱却し、エンタープライズ仮想マシンイメージを管理するための堅牢なプロセスを概説します。推奨されるアプローチは、各イメージをバージョン管理されたビルド成果物として扱い、管理されたソースから開始し、決定論的な構成を経ます。このプロセスには、パラメータ化されたビルドにHashiCorp Packerを使用し、オーケストレーションにAzure DevOpsを使用することが含まれます。コアステップは、イメージのビルド、Azure Compute Galleryへの発行、一時仮想マシンを使用した発行済みバージョンの検証、および追跡可能なプロモーションのための証拠の生成です。このソリューションは、レイヤードパイプラインの複雑さを回避するために、単一の再現可能なPackerビルドを強調しています。環境固有の値はパイプラインパラメータとして分離され、柔軟性が確保されます。Packer構成は、ビルダーと決定論的なプロビジョニングシーケンスを定義し、一貫性を保証します。重要なのは、この記事では、一時VMをデプロイしてリモートチェックを実行することにより、ビルドVMだけでなく、発行済みイメージバージョンの検証を強調しています。検証カバレッジには、OSベースライン、ランタイム、パッケージ、サービス、および信頼チェックが含まれ、結果は証拠として公開されます。この証拠は、ビルドログおよびスキャン出力とともに、完全な追跡可能性のためにパイプライン実行と相関付けられます。プロモーションは制御されており、再ビルドではなく、正確に同じ検証済みイメージバージョンがプロモートされることが保証されます。障害処理とクリーンアップが統合されており、一時リソースが削除されることが保証されます。本番環境の考慮事項には、ビルド、機能、セキュリティ、およびプロモーションステージのリリースゲートが含まれ、安定した検証契約によってサポートされます。イメージパイプラインは、バージョン管理され、検証されたギャラリー成果物で終了し、消費者はこれを制御されたロールアウトのために参照できます。最終的に、イメージのベーキングを、バージョン管理された出力と独立した検証を備えたソフトウェア配信問題として扱うことで、運用が簡素化されます。