Microsoft Teams Blog articles ... ノート

Microsoft Teams Blog articles 日本語

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

ノートのスレッド

Azure MCP Server を介して接続された AI アシスタントが、エンジニアの Azure アプリケーションの遅延診断を支援できるようになりました。この接続により、AI は Azure Monitor をクエリし、構成を検査し、リソースを比較して、調査を効率化できます。ただし、この機能は適切に管理されない場合、重大なセキュリティリスクをもたらします。主な懸念は、AI が機密性の高い Azure データにアクセスしたり、不正な本番環境の変更を実行したりする可能性です。これらのリスクを軽減するには、厳格な ID およびアクセス管理から始まる、多層的なセキュリティアプローチが不可欠です。各 AI の対話は、Entra ID の最小権限の原則を利用し、必要なリソースへのアクセスを制限することで、特定の権限によって境界付けられる必要があります。アプリケーションからのテレメトリは信頼できない入力として扱われ、指示として解釈されるのを防ぎ、プロンプトインジェクションを防ぐ必要があります。読み取り専用アクセスは、変更のリスクを軽減しますが、トークンや顧客データなどの機密情報を公開しないように、慎重なデータ処理が必要です。適切な Azure リソースを対象とすることが重要であり、結果を伴うアクションには検証チェックと承認ワークフローが必要です。Key Vault などのサービスに対するデータプレーンの権限は、資格情報の漏洩を防ぐために、管理プレーンのアクセスから分離する必要があります。Azure MCP Server 自体もセキュリティで保護する必要があり、資格情報は慎重に管理され、アクセスは制限される必要があります。自動化による間違いの増幅は、操作に対する制限と堅牢なエラー処理の実装を必要とします。Azure Policy とガバナンスは不可欠なガードレールを提供し、包括的なロギングは、AI 主導のすべての活動の可観測性と監査に不可欠です。
ビジネスでは、ワークフローのためにドキュメントを構造化データに変換する必要がよくあります。これには、下流システムのために正しい値とレコードを抽出することが含まれます。長いドキュメントや繰り返しのあるテーブルは、このプロセスに課題をもたらします。研究者たちは、高度なフロンティアモデルの費用対効果の高い代替手段として、gpt-oss-20bとgpt-oss-120bをテストしました。当初、両モデルはフィールドカバレッジに短所を示しました。パフォーマンスを向上させるために、タスク固有のファインチューニングが検討されました。彼らは、ドキュメントテキストとJSONスキーマをモデルに提供するスキーマガイド抽出方法を使用しました。抽出精度を測定するために、精度、再現率、F1スコアが使用されました。ファインチューニングは、gpt-oss-20bとgpt-oss-120bの両方のF1スコアを大幅に向上させました。gpt-oss-20bは相対的なゲインが大きかったものの、gpt-oss-120bはより高い最終F1スコアを達成しました。これらのモデルは、フロンティアモデルには及ばないものの、タスク固有のファインチューニングの価値を示しました。この研究は、トレーニング前に単純なアプローチを評価し、パフォーマンスを測定することが重要であると結論付けています。Foundry Interactive Trainingのようなツールを使用したカスタムファインチューニングは、大幅な改善をもたらす可能性があります。最終的なモデルの選択は、実証された品質と全体的な展開コストに依存します。
Microsoft Marketplace は、クラウド、AI、ビジネスニーズに対応する 229 の新しいソリューションをローンチしました。Accenture NewsPage は、ディストリビューター向けの Route-To-Market バリューチェーンをデジタル化します。Assurance Map は、組織の脆弱性を可視化し、Microsoft Teams と統合します。Ataytis Motion は、Power BI レポートにアニメーションチャートを追加してトレンドを可視化します。Blekline Mark と Redact は、Kubernetes 上の AI コーディングエージェントのガバナンスを提供します。Charm Security の AI ワークフォースは、人間中心の不正行為と戦います。CSCloudSolutions FinOps は、Azure 請求から実行可能なインサイトを提供します。Digital Gov DMS は、公共部門向けのドキュメント管理ソリューションです。Dimension Management Transact は、Dynamics 365 Business Central におけるディメンション管理を簡素化します。Dropbox Sign は、ドキュメント署名を Dynamics 365 Business Central に統合します。Elsagility は、クライアントアカウントのワークフロー管理を合理化します。Humanly は、候補者のエンゲージメントを自動化して採用を迅速化します。Kepion EPM は、Microsoft ネイティブの財務計画プラットフォームです。Keytos Shield は、クラウドベースのパスワードレス認証を提供します。Kyvoi は、Microsoft 365 の継続的な監視とセキュリティ評価を提供します。LFM2-24B-A2B-InsilicoMMAI-Chem は、創薬のための大規模言語モデルです。QNSI は、暗号資産管理のための量子ネイティブセキュリティプラットフォームです。Routebase は、開発を合理化するための API ライフサイクルプラットフォームです。Shift Handover Log は、タスク追跡によってチームの引き継ぎを改善します。Simmie は、現実的なシミュレーションのための AI セールスレディネスプラットフォームです。SqlCertForge は、SQL Server 証明書を安全に管理します。Symitri Prism は、ファーストパーティデータを使用して e コマースキャンペーンの意思決定を行います。Tenant Strike は、Microsoft 365 および Azure のセキュリティスキャナーです。LG CNS は、Azure 上の AI インフラストラクチャ向けのプライベート GPU サービスを提供します。ThePoint は、SharePoint Web パーを提供してイントラネットを迅速に作成します。AKS 上の Titan SFTP Server は、安全なファイル転送を提供します。V-Track は、銀行の担保ライフサイクル管理を一元化します。VeriForm Health は、AI のための合成ヘルスケアデータセットを生成します。VR Payment は、QR コード決済を Dynamics 365 Business Central に統合します。Your DMARC Exposed は、DMARC レポートの分析を簡素化します。Zentrix Advanced Gantt は、Power BI で高度なプロジェクトスケジューリングを提供します。
AIワークロードが対応可能なデバイスに分散されるにつれて、エンドポイントとAI戦略は融合しています。ITリーダーは、デバイスの決定が将来のAIプラットフォームにどのように影響するかを考慮する必要があります。エンタープライズAIはプラットフォーム、モデル、クラウドサービスに焦点を当ててきましたが、AI PCはエンドポイントを重要な実行環境として導入しています。異なるAIワークロードは多様な実行環境を必要とし、機密性の高いタスクやレイテンシが重要なタスクはローカル処理の恩恵を受けます。クラウドモデルは、大規模または複雑な推論タスクに引き続き最適です。ハイブリッドインテリジェンスは、ローカルリソースとクラウドリソースを統合し、デバイスをAIプラットフォームの能動的な一部とします。時間とともに動作し、データにアクセスするエージェントは、アーキテクチャの決定をさらに複雑にします。この交差点は、アプリケーション設計、セキュリティ、コストに影響を与え、エンドポイント、セキュリティ、アプリケーションチーム間の協力を必要とします。組織は、要求の厳しいAIワークロードに対して特別な構成を提供しながら、デバイスを標準化できます。既存のクラウドベースのAIソリューションは、ローカル推論によって拡張でき、デバイスとクラウド間で処理を分散します。障害およびフォールバック戦略は、エンドポイントベースおよびクラウドベースのワークロードの両方にとって重要であり、セキュリティ、プライバシー、信頼性に影響を与えます。エージェント型アプリケーションは、ファイルアクセス、ツール使用、および環境全体のアクティビティに対する制御を必要とします。Microsoft Execution ContainersやMicrosoft Agent 365のようなテクノロジーは、エンタープライズの一部としてエージェントアクティビティを管理することを目指しています。ワークロードの配置は、応答時間、プライバシー、接続性、利用可能なリソースなどの要因に依存します。ハイブリッドランタイムは、リアルタイムの条件に基づいて、適切なローカルまたはクラウドリソースに動的にタスクをルーティングできます。ソフトウェア開発は、複雑な問題にはクラウドモデルを、ターゲットを絞ったタスクにはローカルモデルを活用することで、これを実証しています。ローカル実行には、互換性のあるモデル、ランタイム、アプリケーションパス、および十分なシステム容量が必要です。Windows MLは、さまざまなハードウェアリソース全体でサポートされているモデルを実行するための基盤を提供します。ローカル推論を組み込むことは、ハードウェアがアーキテクチャの不可欠な一部となり、パフォーマンスとコストに影響を与えることを意味します。デバイス計画は、従業員の役割と潜在的な専用ローカルインフラストラクチャを考慮する必要があります。フィールド検査ワークフローとコパイロットは、ローカル機能とクラウド機能を組み合わせることで、ハイブリッドインテリジェンスを例示しています。ローカルAIワークロードは、全体的なデバイスアクティビティのコンテキスト内で評価する必要があります。デバイスメーカーは、コンピューティング、RAM、および電力を考慮して、進化するAIランドスケープをサポートするハードウェアを設計しています。代表的なハードウェアでアプリケーションをテストすることは、実際のパフォーマンスを理解し、情報に基づいた配置決定を行うために重要です。ローカル推論の経済性は、ローカルコンピューティングコストとクラウド推論費用との間のトレードオフを含みます。
FSLogix がユーザーごとの VHDX コンテナーに同期ルートをリダイレクトすると、Cloud Files 同期プロバイダーで問題が発生します。具体的には、オンデマンド ポップレーションが有効になっており、最近アクセスされていないプレースホルダー ディレクトリ内の存在しない子要素の名前検索によってトリガーされる特定の FETCH_PLACEHOLDERS コールバックで、プレースホルダー転送のための CfExecute 呼び出しが E_INVALIDARG で失敗します。ただし、ディレクトリ列挙コールバックは正しく処理されます。この問題は、FSLogix プロファイル コンテナーを使用したクリーンな Windows Server 2022 および 2025 のインストールで再現できます。同期ルートが、プレーンな VHDX ボリュームやマウント ポイント、または Windows 11 上にある場合のように、FSLogix でリダイレクトされたプロファイル内にない場合は、問題は発生しません。異なる OS パッチレベルや FSLogix リリースでも、このバグの再現性に影響はありませんでした。回避策としては、コールバックに応答する前に FILE_LIST_DIRECTORY でディレクトリを開くか、CfUpdatePlaceholder を使用してディレクトリのオンデマンド ポップレーションを無効にすることが挙げられます。プロバイダーは現在、ディレクトリを開くという回避策を使用しています。開発者は、これが FSLogix でリダイレクトされたプロファイルにおける Cloud Files 同期ルートの既知の問題であるかどうかの確認を求めています。問題を示すための PowerShell スクリプトとログは、パブリック リポジトリで提供されています。詳細および環境マトリックス情報は、Microsoft Q&A で入手できます。
Azure SQL Database は、インフラストラクチャ管理なしでシームレスなコンピューティングスケーリングを提供します。スケーリング操作には、vCore の調整だけでなく、新しいコンピューティングのプロビジョニング、データの準備、接続の切り替え、古い環境のクリーンアップが含まれます。スケーリングにかかる時間は、2 つのデータベース間で一見同じような変更であっても、大きく異なる場合があります。データベースサイズは重要な要因であり、データベースが大きいほど、ターゲットコンピューティングでのデータ準備に時間がかかります。データベースのアクティブなワークロードもスケーリング時間に影響を与える可能性があります。ターゲット環境の準備中、データベースはオンラインのままです。切り替え時に存在する長時間実行されるトランザクションは、接続遷移を遅延させ、操作を長引かせることがあります。Azure SQL 内のリソースの可用性も、操作が保留状態に入る原因となり、全体的な時間を増加させる可能性があります。スケーリング操作は、Azure PowerShell の Get-AzSqlDatabaseActivity および Get-AzSqlDatabase コマンドレットを使用して監視できます。sys.dm_operation_status DMV は、PENDING や IN_PROGRESS のような操作状態の SQL 側のビューを提供します。sys.dm_operation_status の PercentComplete 列は、通常、スケーリングの細かい進捗状況ではなく、操作の状態を示します。スケーリング中、データベースは利用可能なままで、切り替えまで接続は元のコンピューティングに継続されます。切り替え自体は短い中断を引き起こし、アプリケーションは再試行ロジックを実装する必要があります。スケーリング操作が遅いことは、必ずしも失敗を示すわけではありません。正当に複雑な準備段階を処理している可能性があります。トラブルシューティングには、正確な変更の確認、データベースサイズの比較、ワークロードアクティビティ、および長時間実行されるトランザクションの有無の確認が含まれます。
最近のセッションでは、Query StoreとSSMS Copilotを組み合わせてSQLパフォーマンスの問題を調査する方法が実演されました。デモでは、テーブルを成長させ、パフォーマンスの変化や異なるクエリ実行プランを引き起こしたPHPプログラムが使用されました。重要な観察結果として、同じPlan IDの下でクエリの実行時間が劇的に増加し、プラン内の劣化を示唆していました。セッションでは、CopilotがAskモードからAgentモードへと進化しながら調査をガイドする方法と、これらのプロセスを再利用可能なスキルとしてキャプチャする方法が示されました。Query Storeは履歴パフォーマンスデータを提供し、Copilotはこれらのデータの分析と次のステップの決定を支援しました。実践的なデモンストレーションでは、PHPプログラムを使用して、テーブルにレコードを段階的に追加することで様々なパフォーマンスの問題をシミュレートしました。データ量が増加するにつれて、dbo.GiveNotesクエリの実行プランとパフォーマンスは進化しました。詳細な比較により、新しいプランが導入される前でさえ、あるPlan IDのCPU、期間、論理読み取りが大幅に増加したことが明らかになりました。調査は、変更のタイムラインを構築し、ワークロードの貢献者の集計された影響を理解することに焦点を当てました。加重平均は、異なる間隔と実行回数にわたるパフォーマンスを正確に評価するために重要でした。論理読み取りの増加は、データ処理とアクセスパスの問題を示唆していました。セッションでは、Copilotとの3つの対話方法が探求されました。ガイド付きの質問のためのAskモード、自律的な診断のためのAgentモード、標準化された調査のための再利用可能なAgent Skillsです。SQL Performance Investigatorパックが開発され、エージェントに貢献者の特定、プラン履歴の分析、プラン内の劣化の確認、選択性、統計、インデックスの調査を指示しました。提案されたインデックスが評価されましたが、その実際の改善には、比較可能なワークロードに対するさらなる検証が必要でした。中心的な教訓は、パフォーマンスの変化を理解するには、プラン間の違いと単一プランの履歴内のバリエーションの両方を調べる必要があるということでした。
Azure SQL Database がパフォーマンスの問題を抱えている場合、CPU 使用率を確認するだけでは不十分です。クエリは、リソースメトリクスが健全であっても、実行よりも待機に多くの時間を費やしている可能性があります。重要なのは、CPU がどれだけ使用されているかだけでなく、経過時間がどこに費やされているかということです。リソース使用率は最初のチェックポイントであるべきで、sys.dm_db_resource_stats に対するクエリで、CPU、データ IO、ログ IO、メモリ、またはワーカーの制限に近づいているかどうかを特定できます。リソースが飽和していない場合は、待機統計の分析が必要です。PAGELATCH_* (インメモリ競合) や LCK_M_* (ブロッキング) のような待機パターンは、さらに調査すべき領域を示します。PAGEIOLATCH_* 待機は物理 IO に関連し、PAGELATCH_* 待機はメモリ内のページでの同期に関係しており、単一のホットページでの高い同時実行性によって引き起こされる可能性があります。クエリ実行の頻度も、個々のクエリコストだけでなく、パフォーマンスに大きく影響します。Query Store はクエリ実行履歴を追跡するために不可欠であり、時間の経過に伴う期間、CPU 使用率、待機動作の比較を可能にします。クエリの経過時間が長いが CPU 使用率が低い場合は、ASYNC_NETWORK_IO のような待機を調査してください。これは、クライアントアプリケーションが結果を十分に速く消費していないことを示していることがよくあります。最初の行までの時間と最後の行までの時間を測定することで、データベースの応答時間と結果の消費時間を区別するのに役立ちます。セッションが別のトランザクションを待機する永続的なブロッキングも、CPU が低い場合でも、認識される遅延の原因となる可能性があります。データベースのスケーリングは、根本的なパフォーマンスのボトルネックに対処するのではなく、一般的なリソース可用性を向上させることで、根本原因を隠蔽する可能性があります。実践的なワークフローには、インシデントウィンドウの定義、リソースの確認、CPU と経過時間の比較、支配的な待機の特定、ブロッキングの確認、Query Store の使用、実行プランの検査、およびアプリケーションの調査が含まれます。最終的に、Azure SQL のパフォーマンスを効果的にトラブルシューティングするには、データベースがどれだけビジーに見えるかだけでなく、時間がどこに費やされているかを理解する必要があります。
このブログ記事では、Microsoft Azure 上のミッションクリティカルな Oracle データベースの高可用性 (HA) アーキテクチャについて、特にアベイラビリティゾーンをまたいだ Oracle RAC を有効にするための FlashGrid Cluster の使用に焦点を当てて議論します。組織は、Oracle AI Database@Azure、セルフマネージドシングルインスタンス、または Oracle RAC の選択肢に直面します。Oracle Data Guard は、スタンバイデータベースを維持することで、アベイラビリティゾーンの障害から保護するのに役立ちます。Oracle RAC は、ローリングメンテナンス中のダウンタイムゼロと、予期せぬ障害発生時のほぼゼロのリカバリ時間目標 (RTO) を備えたアクティブアクティブ HA を提供し、ミッションクリティカルな HA において Data Guard を凌駕します。Azure は、99.99% のアップタイム SLA のために、アベイラビリティゾーンをまたいだマルチ VM デプロイメントを推奨しています。Oracle RAC のためのマルチ AZ オプションは 2 つ提案されています。Data Guard レプリケーションを備えた 2 つの RAC クラスター、または 2 つまたは 3 つのアベイラビリティゾーンにまたがる 1 つの RAC クラスターです。オプション A、Data Guard を備えた 2 つの RAC クラスターは、リソースを重複させ、コストと運用上の複雑さを増加させます。また、Data Guard フェイルオーバー時間を導入し、アップタイム SLA に影響を与えます。オプション B、単一のマルチ AZ RAC クラスターは、ローカル RAC クラスターと同じ HA 機能を提供し、さらにアベイラビリティゾーンの障害に対する保護を提供します。FlashGrid Cluster は、自動化された Azure Resource Manager テンプレートと事前にテストされたコンポーネントを使用して、この複雑なデプロイメントを簡素化します。デプロイメントはわずか 30 ~ 90 分で完了し、オンプレミスの典型的な Oracle RAC デプロイメントよりも迅速かつシンプルです。Azure アベイラビリティゾーン間のネットワーク遅延は通常 1ms 未満であり、ほとんどのワークロードにクリティカルな影響を与えません。遅延に敏感な Cache Fusion 操作の場合、優先データベースインスタンスを使用することで、ノード間のトラフィックを最小限に抑えることができます。どちらのオプションも完全なディザスタリカバリソリューションを提供するわけではありません。リージョン障害に対しては、通常、非同期 Data Guard または Oracle GoldenGate を使用したマルチリージョン DR 戦略が必要です。FlashGrid Cluster は、Azure 上のマルチ AZ Oracle RAC のインフラストラクチャを自動化し、クラスターを重複させたり Data Guard FSFO に依存したりすることなく、迅速なリカバリ、ローリングメンテナンスのサポート、およびアベイラビリティゾーンの障害に対する保護を提供します。FlashGrid Cluster は Microsoft Marketplace で入手可能であり、2017 年から本番環境でのデプロイメントが行われています。
このドキュメントは、アプリケーションワークフローを高速化するためのJevスタイルの型付き決定インターフェースを探求し、構造化されたアクションにつながるセマンティック理解に焦点を当てています。注文処理のようなアプリケーションで、モデルが高速で境界のある決定を下す方法を、明示的な制約のための従来のルールや、オープンエンドな問題のための大規模モデルと比較して強調しています。中核となる概念は、頻繁で局所的な決定のためにSmall Language Models (SLMs) を使用し、決定を行動の近くに保つことです。このアプローチは、低レイテンシでタスクレベルの意図決定が重要な垂直アプリケーションや具現化されたシステムに有益です。アーキテクチャは、タスクの分担を強調しています。オープンエンドなタスクには大規模モデル、境界のあるセマンティック決定には小規模モデル、制約には決定論的なコードを使用します。このドキュメントでは、Qwen3.5-0.8Bを使用して一般的な決定コンポーネントをファインチューニングし、LoRAファインチューニングを採用してONNXにエクスポートするプロセスを詳述しています。このワークフローは、データからデプロイ可能な決定機能への具体的なパスとして機能し、長い回答ではなく境界のある選択を学習することに焦点を当てています。前処理は、各質問をトレーニング例に展開し、choice、noul、scoreのような決定タイプが特定の出力フォーマットと一致するようにします。Microsoft Oliveを使用したOliveワークフローは、ファインチューニング設定を標準化し、再現可能なプロセスを保証します。重要な違いは、Hmmプロジェクトの候補文字混合ではなく、標準的なフルシーケンス言語モデルSFTを使用することです。エクスポートプロセスでは、ModelBuilderを使用してベースモデル、アダプター、トークナイザー、および設定をデプロイ可能なONNXユニットにパッケージ化します。エクスポートプロセス中のバージョン境界と互換性の問題のナビゲーションは、堅牢なバージョン管理の必要性を強調する重要な学習ポイントとして強調されています。テストは2つの段階で構成されます。モデルが実行されることを確認し、その決定がアプリケーションで使用可能であることを検証します。これには、オプション文字のロジットから確率を抽出して、モデルの出力をchoice、noul、scoreタイプの分布として解釈することが含まれ、これは校正された正しさではなく集中度の尺度を提供します。
コラボレーションは、人間とエージェントのチームを含むように進化しており、エージェントにはより良いチームコンテキストが必要とされています。Copilotは、これらのチームをサポートするために強化されており、新しい機能により、エージェントはSharePoint内でチームのナレッジベースにアクセスおよび管理できるようになります。このナレッジベースは、電子メール、メッセージ、ファイルなどのさまざまなソースからの情報を統合し、人間とエージェントの両方がアクセスできるようにします。法務、エンジニアリング、営業チームは、この統合された情報からすでにメリットを得ています。Copilotは、生のコンテンツを有機的なナレッジベースに変換し、エージェントの応答時間と効率を向上させます。SharePointは、このコンテキスト情報の中央ハブとして機能します。このナレッジベースは現在、プレビューテナントに展開されています。今後のアップデートでは、その可用性と他のMicrosoftツールとの統合が拡大されます。同社は、人間とエージェントのコラボレーションのためにコンテンツを使用可能な知識に変換することにコミットしています。最近のアップデートには、AIを活用したコンテンツのための強化されたガバナンスツールも含まれています。
Microsoftパートナーは、Microsoft Marketplaceを通じて購入可能なトランザクト対応ソリューションを提供しています。Heaviside AIのNiaShield AI Control Planeは、規制産業の従業員がAIモデルを安全に使用できるようにします。NiaShieldはAzureサブスクリプション内に展開され、揮発性メモリ内で動作するため、セッション後にデータが保持されないことが保証されます。ユーザーは、インストール中にさまざまなAIモデルプロバイダーを選択および切り替えることができます。OneTrustは、AI展開、ベンダーオンボーディング、および製品ローンチ全体でのデータ使用を管理するためのプラットフォームを提供します。これは、イノベーションとコンプライアンスのバランスを取りながら、グローバルスタンダードに対するリスクを特定するのに役立ちます。NKUSI-ITは、学習管理システムへの投資を最大化するためのLMSコンテンツ作成サービスを提供します。これらのサービスは、従来の教材をデジタルでマルチメディア豊富なコースに変革します。プロセスには、標準に準拠したテクノロジースタックの開発と、ビデオ、オーディオ、およびアニメーションアセットの作成が含まれます。NKUSI-ITは、インタラクティブでSCORM準拠の学習モジュールも開発しています。
Bob Ward氏は、さまざまなSQLプラットフォーム向けの新しいオープンソースワークロードシミュレーションツールスイートであるsqlsimtoolsを導入しました。このプロジェクトは、SQL Serverの顧客の問題を再現する上で重要な役割を果たした古いツールostress.exeの現代的な再構築です。Sqlsimtoolsは、ユーザーがSQL環境のパフォーマンスをテストおよび理解する方法に革命を起こすことを目指しています。SQL Server 2019、2022、2025、およびAzure SQL Database、Azure SQL Managed Instance、Microsoft FabricのSQLデータベースをサポートしています。パブリックプレビューには、ネイティブコマンドラインツールであるsqlsim、Pythonベースの代替であるsqlpysim、および構成と監視のためのブラウザアプリであるsqlsim Studioの3つの主要コンポーネントが含まれています。ユーザーはカスタムベンチマーク、ストレステストを作成し、キャプチャされたSQL Serverアクティビティをリプレイできます。これらのツールは柔軟な認証を提供し、Windows、Linux、macOSで実行できます。Sqlsimtoolsは、詳細なパフォーマンス比較のための実行前後の実験も容易にします。ワークロードの自動化は、JSON結果とライブイベントストリームを通じてサポートされます。このプロジェクトは、ワークロード作成のためのAIエージェントとの統合を奨励しています。関心のあるユーザーは、aka.ms/sqlsimtoolsで入手でき、GitHubを通じて貢献できます。
カテゴリは、トピックごとに受信トレイのメールにタグを付けるのに便利な方法です。これにより、トピック固有のフォルダーにメールを手動で移動することなく、後でメッセージをグループ化したり見つけたりすることが容易になります。 しかし、多くのカテゴリが作成されている場合、メッセージにカテゴリを割り当てるのが不便になります。カテゴリリストのナビゲーションが困難になり、カテゴリメニュー内で検索することもできません。そのメニューに検索フィールドがあれば、適切なカテゴリを見つけて適用することがずっと容易になります。 また、ルールについても質問があります。当社の社内環境では、Outlook はオンプレミスサービスに接続しており、VPN なしで自宅で作業しているときでも実行され続けるため、サーバーサイド ルールは重要です。私の経験では、カテゴリを割り当てるサーバーサイド ルールを作成できません。その結果、カテゴリを使用するルールは、Outlook が開いて接続されている場合にのみ実行されるようです。 新しい Outlook for Mac のサーバーサイド ルールで、カテゴリ割り当てをオプションとして追加することは可能でしょうか?また、カテゴリピッカーに検索機能を追加することは可能でしょうか? これらの制限が Outlook のバージョンまたはメールボックス/サーバー構成に依存するかどうかも知っておくと役立ちます。