2026/10/06 に「Microsoft Fabric 入門」が技術評論社から発売されます。
著者の一人であり、第 4～6 章の執筆を担当された株式会社ジール (企業 HP / LinkedIn) の 永田亮磨さん (X / LinkedIn) から本書籍を献本いただきました。
書籍を一通り内容を読むことができましたので感想を本投稿で残しておきたいと思います。
投稿時点では発売前の書籍となり、購入できるのは少し後となりますが、興味を持たれている方の参考になれば幸いです。
Archive for 9月, 2026
SQL Database で互換性レベル 180 の対応が始まったようです
Azure SQL Database では、2026/05 付近から、データベースエンジンのバージョンが 17.x (SQL Server 2025 相当) から 18.x (v.Next) にバージョンアップが進められており、私の環境であれば本投稿の作成時点では「18.0.256.210」というデータベースエンジンのバージョンが使用されています。
先週ぐらいまではデータベーエンジンのバージョンは 18 が使用できるようになっていたのですが、互換性レベルは 170 までしか設定できないという状態となっていました。
先ほど、互換性レベル 180 が使用できるかを確認してみたところ、互換性レベル 180 も設定することができるようになったようです。
ALTER DATABASE CURRENT SET COMPATIBILITY_LEVEL = 180 GO
現時点では、互換性レベル 180 の情報は公開されていないようですが、https://github.com/microsoft/SqlScriptDOM/tree/main/release-notes/180 では、ScriptDOM に互換性レベル 180 についてのパーサーの実装が進んでいるようで、リリースノートから、どのような機能の実装が進んでいるのか多少なりとも確認をすることができるようです。
以下に、SQL Server 2025 と比較した情報を記載しておきたいと思います。
SQL Server の互換性レベル変更に伴い行ストアでのバッチモードが増えたことで実行効率が極端に悪化する可能性はあるのか？
SQL Server では インテリジェントなクエリ処理 として、バージョン / 互換性レベルに応じてクエリ最適化が自動的に行われる機能が実装されています。
この中で、「互換性レベル 150 以上」で有効化される「行ストアでのバッチモード」があります。この最適化機能に起因して、クエリの実行効率が極端に悪化する可能性があるのかについて、確認した情報をまとめておきたいと思います。
Microsoft Foundry の Autopilot シナリオの基本構成について
先日、Microsoft Foundry で Autopilot シナリオを検証する際に参照する情報 という投稿をしました。この投稿は Microosft Foundry のオートパイロットシナリオ を実現するためのものとなります。
同様のシナリオは Agent 365 SDK のクイックスタート でも提供されており、こちらの構成は App Service+Bot Service を使用して エージェント ユーザー のシナリオが実現されていました。
先日起票した Issue の回答 で Microsoft Foundry を使用した Autopilot シナリオのサンプルを動作させることができるようになりましたので、個人的に気になっていた基本構成について確認した内容をまとめておきたいと思います。
Microsoft Foundry で Autopilot シナリオを検証する際に参照する情報
Microsoft Foundry では Autopilot のシナリオ がサポートされています。
これは、Microsoft Foundry のエージェントを Agent 365 の エージェント ユーザー (AI チームメイト / デジタル ワーカー) として実行して、次の動作でエージェントを実行するものとなるのかと思います。
Autopilot のシナリオを検証する際に、参照したほうが良いと思える情報についてまとめておきたいと思います。
先日から検証をしているのですが、2026/09/16 時点では、私はインスタンス化したエージェントを利用しようとすると次のエラーが発生してしまい、最終的な動作までは確認ができていません。
Error from user container for agent ‘fndauto01-autopilot-agent’: Autopilot activity authorization currently supports only access boundaries ending with ‘.developers’.
同様の事象については、Microsoft の Stefano 氏の From Zero to an Agent 365 Lab: An Open GitHub Copilot Toolkit でも確認されているようで、このコミット でも注釈として記載が行われています。
今回は、Foundry のサンプルを展開しているので Issue は登録しましたので、どのような事象が発生したかについてはこちらで確認もできるかと思います。
2026/09/17 追記
Issue で回答があり、上述の「.developers」の Access Boundaries のエラーは、「publish-digital-worker.ps1」に「accessBoundaries」の設定を追加することで対応ができました。
エラーが出ていた状態から再展開したところ、正常に動作するようになりました。
SSMS 22.10.0 で SQL Server のアップグレード評価の精度が向上しているようです
以前、SQL Server の互換性レベル変更に伴う構文解析ツールを作成しました という投稿をしました。
この投稿の検証をした理由の一つとして、SQL Server の互換性レベル毎の構文評価が動作していないというものがありました。
この事象については、フィードバックをしており開発チームにも事象の共有ができていたのですが、 SSMS 22.10.0 で改善したようです。
本投稿時点では、リリースノート には記載されていないのですが、以前のアップグレード評価では検知されなかった互換性の問題が検知されるようになっています。
Windows Server 2025 で SQL Server を動作させた場合の LPIM の問題についての情報を整理する
先日、Microsoft: Windows Server 2025 changes causing app crashes という記事が公開されました。
日本語で公開されている記事もあるようですが、元は上記の記事となるようなので私は上記の記事の参照をお勧めします。
この記事では Windows Server 2025 で SQL Server 2019 / 2022 / 2025 を使用しており、LPIM (Lock Pamge in Memory: メモリ内のページロック) を有効化している場合に、Access Violation が発生するというものです。
今回のような問題が発生している場合、どのように情報を見つければよいのかをまとめておきたいと思います。
SQL Server 2022 で実装された PSP optimization の挙動を把握するために参考にする情報
SQL Server 2022 の Intelligent query processing では、PSP optimization というクエリ最適化の処理が実装されました。
この機能はパラメーター スニッフィングに対する最適化として期待されるものとなり、パラメーターによって実行プランが大きく異なるケースで、パラメーターの値範囲に応じた実行プランを生成してくれるものとなります。
この機能が使用されているかを確認する際には、どの情報を参照すればよいのかを調べる機会がありましたのでまとめておきたいと思います。
Global Secure Access で Claude Desktop の生成 AI 分析情報ログを取得する
Global Secure Access (GSA) には「生成 AI 分析情報ログ」という、生成 AI のログを取得する機能があります。
このログでは生成 AI に対してのプロンプト ログを取得することができ、サポートされている生成 AI についてはログを取得することができます。
サポートされる AI には、「Claude」も含まれているのですが、Claude Desktop (claude.exe) を使用していた際にログの出力が行われなかったので、その挙動について調査した際の情報をまとめておきたいと思います。
Microsoft 365 管理センターを使用したシャドウ AI / ローカルエージェントの検出
Global Secure Access (GSA) を使用したエージェントの管理について / Global Secure Access (GSA) を使用したエージェントの管理について その 2 で GSA を使用したエージェントの管理について投稿をしました。
これらの投稿ではタイトルの通り、GSA を使用してエージェントの管理を実現していました。
エージェントの管理については、GSA を使用せず Microsoft 365 管理センターを使用して管理を行うことができます。
この画像はシャドウ AI を管理するための機能となります。
当初は Intune を使用してシャドウ AI の検出が行われていましたが、現在は Microsoft Defender for Endpoint を使用した検出に切り替わっているようです。
本投稿では Microsoft 365 管理センターによるエージェントの管理について情報をまとめておきたいと思います。