M365

MicrosoftはMicrosoft Build 2026の開催に合わせ、Microsoft Teamsの2026年5月アップデートを公開した。開発者向けのプラットフォーム強化を中心に、会議、電話、フロントライン向けまで幅広い領域で多数の新機能が追加されている。 Teams上でコードが動く時代——Cursor・Linear・Atlassian Rovoエージェント統合 今回のアップデートで最も注目すべきは、開発者ツールとTeamsの直接統合だ。 Cursor agent をTeamsのチャンネルや会話内で @mention することで、Cursorのクラウドエージェントがその場で起動し、会話のコンテキストを保ったまま結果を返す。バグ修正や機能追加のためにTeamsを離れてIDEを起動する手間が省ける。 Linear agent は、チャンネルでの会話や決定事項をそのままLinearのIssueとして作成し、プロジェクト状況を更新する。「あの会話の結論、誰かIssue作っといて」が不要になる。 Atlassian Rovo agent は、JiraとConfluenceおよびTeamwork Graphの組織データをTeams会話に接続し、チャット内でJiraのIssue作成・Confluenceページ起草・ワークフロー更新をまとめて実行する。Atlassianの従来のJira/Confluenceアプリを統合した「ユニファイドエージェント」として進化した形だ。 3つのエージェントはいずれもMicrosoft Marketplaceから利用可能。 開発者を解放する新Teams CLI Teamsエージェントの開発で従来の最大の障壁だったのが、登録・資格情報・マニフェスト作成・デプロイを別々のツールで行う煩雑なセットアップだった。新しいTeams CLIはこの一切を単一コマンドに集約し、エージェントのアイデアから動作インスタンスまでを数分で実現する。コーディングエージェントと組み合わせて使うことで、設定の複雑さに時間を取られずエージェントのロジック開発に集中できる。 エージェント向けのUI強化——スラッシュコマンド・引用返信・絵文字リアクション エージェントとの会話体験も大幅に改善された。 スラッシュコマンド：コンポーズボックスで / 入力するだけでエージェントを呼び出し、情報取得やタスク開始が可能 引用返信：エージェントが特定のメッセージに対して返答する際に引用が使えるようになり、長いスレッドでも文脈が追いやすくなった 絵文字リアクション：エージェントが返信の代わりに👍などのリアクションで軽量な確認を返せるようになり、スレッドの見通しが改善 いずれもパブリックプレビュー。 会議を見逃しても大丈夫——Video Recap（ビデオ要約） Teams会議の録画を短いナレーション付きのハイライト動画に自動変換する「Video Recap」が登場した。AIが重要な発言・決定・画面共有を抽出し、ボイスオーバー付きで再構成する。録画全体を見返す必要なく、会議の流れと結論を素早く把握できる。Microsoft 365 Copilotライセンスが必要で、英語での10〜90分の録画に対応。Windows/Mac/Webのチームズで利用可能。 なりすまし通話をリアルタイム検知——Brand Impersonation Protection Teams PhoneにBrand Impersonation Protectionが追加され、銀行・ITヘルプデスク・Microsoftサポートなどを装った通話をリアルタイムで検知して警告を表示する。「Scam suspected」などのアラートが通話中に表示され、着信を拒否・退話・報告できる。追加ツール不要でTeamsの通話機能に組み込まれているため、導入の手間がない。ユーザーが不審な通話を報告すると、そのシグナルがMicrosoftの検知システム強化にも貢献する仕組みだ。 セキュリティ・管理強化 Bot Detection（TAC Policy）：会議に参加するボットや自動参加者を管理者がテナント全体でポリシー設定でき、参加者リストで明示的にフラグが立つ エージェントメタデータの可視化：IT管理者がTeams管理センターでエージェントの機能・知識ソース・許可されたアクションを一覧できるようになり、承認前の審査が容易に M365認定アプリの一括管理：「Microsoft 365認定アプリのみ許可」という単一選択でテナント全体の認定アプリを一括有効化できるようになった フロントライン向け強化 Smart Scheduling（スマートスケジューリング）：空きシフトを従業員の可否・休暇・最大稼働時間・過去の実績をもとに自動割り当て Communicator app：現場向けの安全アラートや研修リマインダーを構造化メッセージとして配信・開封追跡 Frontline Agent（音声によるサイト点検）：現場を歩きながら音声でインスペクション記録を作成し、自動で構造化データ化 実務への影響 開発チームへの影響は大きい。 CursorやLinearがTeams内から呼び出せるようになったことで、「Teamsで議論→別ツールでIssue起票→また戻る」という往復コストが削減される。特にリモート・分散チームでは、コンテキストの引き継ぎロスがボトルネックになりがちなので効果が出やすい。 IT管理者にとっては「エージェント管理」が新しい業務領域になる。 エージェントのメタデータ可視化・評価スコア・Bot Detectionポリシーといった機能群は、これまで存在しなかった「AIエージェントのガバナンス」を本格的に担う体制を組む必要があることを示している。管理センターでのエージェント承認フローを早急に整備すべき時期に来ている。 Teams Phoneを利用している組織では、Brand Impersonation Protectionの展開確認を優先したい。 ビジネスフォンへのなりすまし詐欺は世界的に増加しており、追加コスト不要でビルトインされるのは実務上のメリットが大きい。 ...

Microsoft が AIエージェント向けのID管理基盤「Microsoft Entra Agent ID」の一般提供（GA）を開始した。LangChain・OpenAI Agents SDK・Anthropic Claude Agent SDK・Google ADKなど主要フレームワークに対応した「Microsoft Agent 365 CLI/SDK」と組み合わせることで、フレームワークを問わずエンタープライズグレードの本番運用が可能になる。 AIエージェントの本番運用が難しい本当の理由 プロトタイプを動かすのは難しくない。難しいのは「本番環境で安全に、継続的に、説明責任を持って動かすこと」だ。 従来のサービスアカウントやAPIキーによるアクセス管理は、AIエージェントとの相性が悪い。エージェントは人間と違い、複数インスタンスが並列実行されたり、長時間バックグラウンドで稼働し続けたりする。インシデント発生時に「何が、いつ、何をしたか」を追跡する手段が人間向けのID管理の流用のままでは、原因特定も権限の即時失効も難しい。Microsoft Entra Agent IDはこの課題に正面から取り組む設計だ。 3つのコアコンセプト エージェントブループリント エージェントの「型定義」にあたる再利用可能なIDテンプレート。認証情報・スコープ・設定を一元管理し、複数のエージェントインスタンスを一貫した設定で展開できる。開発チームが新しいエージェントを追加するたびにゼロから設定しなくて済む。 エージェントアイデンティティ 各エージェントインスタンスが個別のIDを持つ。それぞれに独立したサインインログ・監査証跡・割り当てスコープが紐付けられ、Microsoft Entraの条件付きアクセスポリシーのターゲットにも指定できる。 重要なのは「キルスイッチ」の存在だ。不審な動作を検出したエージェントインスタンスを、他のインスタンスに影響を与えずに即座に無効化できる。ゼロトラストの原則——常時検証、最小権限——をNon-Human Identity（NHI）の世界に実装したものと言えるだろう。 スポンサーとオーナー エージェントに対する説明責任を「ビジネス側（スポンサー）」と「技術側（オーナー）」に明確に分離する。スポンサーはエージェントの目的・ライフサイクル判断に責任を持ち、オーナーはID設定・技術管理を担う。この2役分離は、IAMガバナンスフレームワークとして実践的な設計だ。 どのフレームワークでも対応——Microsoft Agent 365 CLI/SDK 注目すべきは対応フレームワークの幅広さだ。Microsoft Foundry・Copilot Studio・Security CopilotなどMicrosoft製品ではIDが自動プロビジョニングされるが、それ以外には Microsoft Agent 365 CLI/SDK が提供されている。 対応フレームワーク（抜粋）： OpenAI Agents SDK / Anthropic Claude Agent SDK / Google ADK AWS Bedrock / LangChain / LlamaIndex / CrewAI Semantic Kernel / GitHub Copilot SDK どのフレームワークを採用していても、同じEntraのID管理基盤に統合できる。マルチベンダーのAIエージェント環境を持つ企業にとって、管理コンソールを一本化できるのは大きなメリットだ。 ...

Microsoftは2026年6月、Microsoft TeamsとOutlookに対してCopilotアップグレードとUI改善を順次展開する。TeamsではUIの再設計によりツールバーのカスタマイズが可能になり、長年悩みのタネだった「退出（Leave）」ボタンの誤タップ問題が解消される見込みだ。OutlookではiOS版でファイルプレビューからCopilotを直接起動できるようになるほか、Windows版では.ics形式でのカレンダーエクスポートなど実用的な機能が追加される。 Teamsのツールバー刷新と誤タップ問題の解消 今回のTeamsアップデートの目玉は、6月に予定されているUIの再設計だ。会議中のツールバーがカスタマイズ可能になり、よく使うボタンを手前に配置したり、使わないボタンを非表示にしたりできるようになる。 特に注目したいのが、退出ボタンの誤タップ問題への対応だ。会議の終盤、発言しようとしたタイミングで退出ボタンを押してしまった経験はTeamsユーザーなら誰しも持っているはずだ。新しいUIではボタンの配置と大きさが見直され、誤操作を減らす設計に改められる。細かい改善に見えるが、ハイブリッドワークが当たり前になった今、会議の質を直接左右する変更といえる。 Outlook iOS版：ファイルプレビューからCopilotを直接起動 Outlook for iOSでは、メールに添付されたファイルをプレビューする画面から直接Copilotを呼び出せるようになる。これまでは添付ファイルの内容を確認してから別途Copilotに貼り付けるという手順が必要だったが、新機能ではプレビュー画面のまま「この書類を要約して」「この契約書のポイントを教えて」と問いかけられる。 外出先でスマートフォンから契約書や報告書を素早く確認したいビジネスパーソンにとって、ワークフローが大幅に短縮される改善だ。 Outlook Windows版：.icsエクスポートと実務的な改善 Outlook for Windowsでは、カレンダーイベントをiCalendar標準の.ics形式でエクスポートできる機能が追加される。Google カレンダーやApple カレンダーなど他プラットフォームとの互換性が高いフォーマットのため、Outlookを持っていない社外の相手でも予定を取り込める。社外パートナーとのスケジュール共有でこれまで手間だった部分がスムーズになる実用的な改善だ。 実務への影響 Teamsのカスタマイズ機能は組織展開のポイント：ツールバーをカスタマイズできるようになると、部門ごとの使い方に合わせた推奨構成を管理者側から提示できる可能性がある。展開ポリシーと合わせて検討する価値がある。 Copilotとの接触点が自然に増える：ファイルプレビューからの直接起動は「Copilotを使おう」と意識しなくても触れる導線だ。ライセンスを購入済みの組織では、利用率向上のきっかけになりうる。 .icsエクスポートはExchange環境外との橋渡しに：オープンソースカレンダーツールや社外パートナーとの連携でこれまで手間だった部分がスムーズになる。 筆者の見解 TeamsのUI改善は、正直ずっと待っていた。退出ボタンの誤タップは笑い話になることもあるが、実際には「大事な会議で突然切れた」という経験がある人も少なくないはずで、地味ながら確実に生産性を削る問題だった。ツールバーのカスタマイズも「なぜ今まで」というレベルの機能だ。こういった「当然あるべき標準機能」を着実に埋めてくれることは素直に評価したい。 Copilotとの統合については、Teamsの議事録整理やOutlookの定型業務処理という使い方に限れば、確かに理にかなっている。プレビュー画面から直接Copilotに問いかけられる体験は、Copilotを積極的に使いたいユーザーには便利に映るはずだ。 一方、Copilotに期待するタスクの範囲設計は組織として慎重に考えたい。高度な分析や創造的なタスクではM365のCopilotだけに閉じず、Azure AI Foundry経由の外部AIモデルを組み合わせる「併用」の視点が現実的な活用戦略になる。Teamsの議事録はCopilotに任せ、より精度を求めるタスクには別の選択肢を組み合わせるアーキテクチャだ。 Microsoftは統合プラットフォームとしての総合力に本物の強みを持っている。今回の改善がTeams・Outlook・Copilotを有機的につなぐ一歩になるなら歓迎したい方向性だ。Copilot本体の実力が利用者の期待に追いついてくれる日を引き続き心待ちにしている。 出典: この記事は Microsoft Teams and Outlook to Get Copilot Upgrades And UI Changes の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft Purview の Data Security Triage Agent に、Microsoft Teams 経由で機密データの修復を自動化する新機能が追加される。2026年6月末にパブリックプレビューが開始される予定で、SharePoint および OneDrive 上の機密情報を AI が検出し、ファイルの最終更新者に Teams メッセージで修復を促すクローズドループの仕組みだ。 何が変わるのか 従来の DLP（データ損失防止）運用では、コンプライアンス担当者が DLP アラートを確認し、該当ユーザーを特定して個別に連絡を取るという手動プロセスが一般的だった。組織規模でこれが発生すると担当者の工数は膨大になり、対応が遅れるほど情報漏洩リスクは拡大する。 今回の機能追加により、Data Security Triage Agent が DLP アラートを自動的に分析し、「Needs attention（要対応）」と判定されたアラートに対して当該ファイルの最終更新者へ Teams メッセージを自動送信する。修復が完了するまで毎日リマインダーが届き、対応状況は Data Security Posture Management（DSPM）ダッシュボードで一元管理される。 主要な仕様と制限事項 対象範囲 SharePoint Online および OneDrive for Business のファイル 「Needs attention」にトリアージされたアラートのみ エンドポイントや Teams 発のアラートは対象外 設定・運用 デフォルトはオフ。管理者が Data Loss Prevention 設定から明示的に有効化が必要 リマインダーの送信日数は管理者が設定可能 Teams 環境側でも専用アプリの展開が必要 スケジュール パブリックプレビュー：2026年6月末〜7月末 実務への影響 コンプライアンス担当者の工数削減 「アラートが出たら誰に連絡するか探して、メールを書いて…」という手作業が自動化される点は、実務上のインパクトが大きい。特にファイル数が多い大規模テナントほど恩恵は顕著だ。 「Teams 経由」という設計の意味 修復依頼が「メール」ではなく「Teams メッセージ」で届く点は重要だ。日本企業でも Teams を主要コミュニケーションツールとして使っている組織であれば、ユーザーが気づきやすく対応率の向上が期待できる。メールは埋もれる。Teams なら見る。この差は運用上、思った以上に大きい。 ...

Microsoft は2026年6月中旬から下旬にかけて、Microsoft 365 Copilot の Planner Agent を全世界で正式提供（GA）する。これにより、Copilot ライセンスを持つユーザーはアプリを切り替えることなく、自然言語でタスクの作成・更新・管理が完結できるようになる。 Planner Agent とは何か Planner Agent は、Microsoft 365 Copilot の会話インターフェース上で動作するタスク管理エージェントだ。従来は Planner を使うために別タブや別アプリを開く必要があったが、このエージェントの登場により Copilot のチャット上でそのまま作業を完結できる。 主な機能は以下のとおり： 個人タスク・共有プランの作成・更新・管理（コンテキスト切り替えなし） ゴール・バケット・タスク階層を含む構造化プランの生成 優先度・締切・リスクのある作業に関するインサイト提供 インタラクティブなタスクカード——AIが提案した変更をユーザーが確認・承認してから適用する安全設計 複数プランを扱う場合のプラン選択UI ロールアウトは 2026年6月中旬に開始、6月末に完了予定。対象は Microsoft 365 Copilot のアクティブライセンスを持つユーザーで、Copilot エージェントストアから追加できる。 管理者が知っておくべきこと 管理者向けに重要な変更点がある。Planner Agent は対象ライセンスユーザーに自動でプレインストールされるようになり、従来は可能だった「特定のユーザーグループに限定する」という制御が廃止された。現在のプレインストールエージェント共通のポリシーに統一されたかたちだ。 ただし、テナント全体での無効化は引き続き Microsoft 365 管理センターから可能。「テナント全体で使わせるか、それとも全社禁止か」という二択に集約されたと理解しておこう。 コンプライアンス面では、Planner Agent はタスク・メール・会議・ファイルなど既存の M365 データにアクセスしてインサイトを生成するため、データ処理の範囲が広がる。機密プロジェクト情報をタスクに書いている組織は、情報の取り扱いポリシーを改めて確認しておきたい。 実務への影響——日本のエンジニア・IT管理者にとっての意味 まず確認すべきこと： ライセンスの棚卸し: Copilot ライセンスを持つユーザーに自動展開される。誰がライセンスを持っているかを把握していないと、想定外のユーザーがエージェントを使い始める可能性がある テナントポリシーの見直し: 「特定グループに限定」の制御が廃止されたため、既存のパイロット運用計画が崩れる可能性がある。全社展開を前提に準備を進めるか、テナント全体ブロックで時期を調整するかの判断が必要だ ヘルプデスクへの事前周知: 「Planner Agent が突然現れた」という問い合わせが来る前に、展開スケジュールと使い方を社内展開しておくと混乱を防げる 実際の活用シーン： Teams 会議のフォローアップ中に「さっきの議論からタスクを起こして」と話しかけるだけで Planner に登録 「今週締め切りのタスクで遅延リスクがあるものは？」とリスク確認を自然言語で プロジェクト計画のたたき台を Copilot に生成させ、インタラクティブカードで承認しながら整備 ただし、基本プラン（Planner for Microsoft 365）と Planner Premium の機能差は依然として存在する。ガントチャートや高度な依存関係管理は引き続き Premium ライセンスが必要だ。 ...

Microsoft 365 Copilotの本格展開に向け、MicrosoftがSharePointおよびM365 Backup/Archiveと組み合わせたデータレジリエンス設計の指針を公開した。Copilot利用の拡大に伴い、基盤となるデータ管理の整備が導入成否を左右するとして、バックアップ・アーカイブポリシーの重要性を強調している。 Copilot導入の「地盤」をどう固めるか AIアシスタント機能を組織全体で活用するには、Copilotライセンスを購入するだけでは不十分だ。MicrosoftはM365 Copilotを安定的に運用するための基盤として、SharePointのデータ整備とM365 Backup/Archiveの活用を強く推奨している。 Copilotはユーザーのメール、Teams会話、SharePointドキュメントなど膨大な組織データを参照してAIによる提案を行う。基となるデータの質と可用性が回答精度を直接左右するため、データが散乱していたり誤って削除されたりすると、Copilotの提案も不正確なものになりかねない。 M365 Backup／Archiveの役割 M365 Backup（バックアップ）とArchive（アーカイブ）は、組織のデータ資産を保護する2つの異なるアプローチを提供する。 M365 Backup は、SharePoint・OneDrive・Exchange Onlineのデータを最大180日の範囲で高速に復元できる機能を提供する。ランサムウェア攻撃や誤削除が発生した際、管理者がアイテム単位の粒度で迅速に復旧できるのが特徴だ。 M365 Archive は、アクセス頻度の低いデータを低コストで長期保管するサービスだ。SharePoint Storageのクォータを効率的に管理しながら、コンプライアンス要件（電子メール保持ポリシー等）を満たす運用を可能にする。 Copilot利用が拡大するにつれてデータ参照範囲も広がるため、これらのバックアップ・アーカイブポリシーの整備が「Copilot Readiness（Copilot導入準備）」の重要な構成要素として位置づけられている。 SharePointのデータ品質がCopilot品質を決める Copilotの回答精度はSharePoint上のドキュメント管理の質に大きく依存する。Microsoftが推奨するCopilot導入前のSharePoint整備ポイントは以下の通りだ。 適切なアクセス権限の設定: Copilotはユーザーがアクセスできるデータのみを参照するため、過剰な権限付与は情報漏洩リスクに直結する 最新情報の維持: 古いドキュメントや重複ファイルを整理し、Copilotが正確な情報を参照できる環境を作る ストレージ管理のポリシー化: M365 Archiveを活用して不要なデータを適切にアーカイブし、アクティブなデータプールの品質を維持する 実務への影響 日本のエンジニア・IT管理者にとって、このMicrosoftの指針が示す実務的なポイントは3つある。 1. Copilot導入前の棚卸しを先に行う ライセンス購入と並行して、SharePoint上のドキュメント構造・権限設定・古いデータの整理を実施すること。「まず使い始めてから整理する」では、Copilotが誤った情報を参照するリスクが残る。 2. M365 Backupを費用対効果で評価する M365 Backupは追加コストが発生するサービスだ。Azure Backupとの比較も含め、自組織のRTO（目標復旧時間）・RPO（目標復旧時点）要件を明確にした上で導入判断を行うこと。「5分・1時間以内の高速復元が必要か」という観点で評価すると判断しやすい。 3. アーカイブポリシーをコンプライアンスと連動させる 日本では改正電子帳簿保存法や各種業法でのデータ保持要件がある。M365 Archiveの保持ポリシーをこれらの法令要件と連動して設計することで、コンプライアンス対応とストレージ効率化を同時に実現できる。 筆者の見解 M365 Copilotに関する議論では「効果がある/ない」の二項対立に陥りがちだが、今回Microsoftが強調したのはその手前の話——「使えるデータ環境の整備」だ。 この主張自体は正論だと思う。どれほど優れたAI機能も、参照するデータが散乱していたり品質が低かったりすれば、まともな提案はできない。データレジリエンスの設計をCopilot展開の前提条件とするアプローチは理にかなっている。 一方で気になるのは、「準備が必要」という語り口が導入の敷居を上げてしまう側面もあることだ。SharePointの棚卸し、バックアップポリシーの整備、アーカイブ設計——これらを丁寧にやろうとすると、中小企業には相当な工数がかかる。 Microsoftにはデータ整備のステップをもっとシンプルに、可能な限り自動化できる形で提供してほしい。「準備してから使う」ではなく「使いながら整備が進む」設計が、Copilot普及の本当の鍵になるのではないだろうか。M365の統合プラットフォームとしての底力があるからこそ、そこへの期待値は自然と高くなる。 出典: この記事は Microsoft 365 Copilot readiness and resiliency with SharePoint and M365 Backup/Archive の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは、Microsoft 365 E5およびE7ライセンスに対して、これまで別途購入が必要だったIntune Suiteの主要機能を段階的に統合すると発表した。2026年8月1日までに全機能のロールアウトを完了予定で、エンタープライズのデバイス管理・特権管理の体制が大きく変わる可能性がある。 何が変わるのか これまでIntune Suiteは、Microsoft Intuneの標準ライセンスに加えてユーザーあたり月額約10ドルの追加費用が必要なアドオンだった。今回の統合により、Microsoft 365 E5/E7を保有する組織は以下の機能を追加コストなしで利用できるようになる。 統合される主要機能 Remote Help ヘルプデスク担当者が安全にエンドユーザーのデバイスをリモート操作できるツール。ロールベースのアクセス制御（RBAC）に対応しており、「誰が」「誰のデバイスを」操作できるかを厳密に制限できる。従来のRDPベースのリモートサポートと異なり、Entra IDの認証基盤に乗った管理が可能だ。 Advanced Analytics AIを活用したデバイスの健全性分析機能。異常な動作パターンの検知や、ソフトウェアの互換性問題の事前把握など、従来のエンドポイント管理では見えにくかったインサイトをダッシュボードで提供する。Windowsアップデート展開前のリスク評価にも活用できる。 Cloud PKI オンプレミスの証明機関（CA）サーバーを不要にするクラウドネイティブな証明書管理基盤。デバイス証明書やユーザー証明書の発行・失効・管理をIntune管理コンソール内で完結させられる。Wi-Fi認証やVPN、SCEPプロファイルとの統合が前提設計になっている。 Endpoint Privilege Management（EPM） Windowsのローカル管理者権限を持たない標準ユーザーに対して、特定のアプリケーション実行時だけ一時的に昇格権限を付与するジャストインタイム（JIT）特権管理機能。「常時管理者」という最も危険な運用形態を排除するための機能として位置づけられている。 Microsoft Tunnel for MAM デバイス全体をIntuneに登録することなく、特定のマネージドアプリからだけ社内リソースへのVPNアクセスを実現する機能。BYODデバイスや業務委託先のPCへの対応として有効だ。 段階的ロールアウトのスケジュール Microsoftは「2026年8月1日までに全機能を段階的にロールアウト」としており、機能ごとに提供開始時期が異なる。既存のE5/E7テナント管理者はMicrosoft 365管理センターやIntune管理センターで各機能の提供状況を随時確認することを推奨する。なお、既存のIntune Suite単体ライセンスを購入済みの場合、移行・価格の取り扱いについては担当のMicrosoft営業またはCSPパートナーへの確認が必要だ。 実務への影響 ライセンスコストの見直しが急務 現在Intune Suite（アドオン）を別途契約しているE5/E7組織は、契約更新のタイミングで重複コストが発生しないよう今すぐ契約条件を確認したい。大規模組織では年間コストに数百万円規模の差が出る可能性がある。 Cloud PKIはオンプレミスCA廃止の好機 多くの日本企業では、Active Directory証明書サービス（AD CS）を運用しているケースが今でも多い。Cloud PKIへの移行は一定の作業コストを伴うが、オンプレミスCAサーバーの維持・更新コストや、証明書失効管理の自動化メリットは大きい。2026年中に移行検討を始めるプロジェクトを立ち上げる価値がある。 EPMは「標準ユーザー化」の最後の砦 セキュリティポリシー上「ローカル管理者権限を全廃したい」と思いながらも、業務上必要なソフトウェアのインストールや設定変更のためにやむなく管理者権限を与え続けているケースが多い。EPMはこのジレンマを解消する。展開にはポリシー設計と業務部門との調整が必要だが、セキュリティ成熟度を一段引き上げる施策として今回の統合は大きな後押しになる。 Remote HelpでRDP依存の脱却を 社内ヘルプデスクが今もRDP+VPNでサポートしている組織は、Remote Helpへの移行を検討する価値がある。RBACによる操作権限の分離と、監査ログの自動記録はコンプライアンス要件への対応にも直結する。 筆者の見解 Intune Suiteの統合は、Microsoftが長年推進してきた「統合プラットフォームによる全体最適」という戦略の正しい具現化だと思う。特権管理（EPM）とCloud PKIがE5/E7の標準機能になるのは、ゼロトラスト推進の観点からは歓迎すべき動きだ。「常時管理者権限の付与はゼロトラストの最大の穴」とずっと言い続けてきたが、EPMがコスト障壁なく使えるようになれば、導入に踏み切れる組織は確実に増える。 Cloud PKIも同様で、「オンプレCA廃止は難しい」と言い続けている組織の言い訳がひとつ減る。インフラの複雑さを減らしてクラウドに寄せるのは、運用コストだけでなくセキュリティリスクの低減にも直結する。 一方で、Advanced AnalyticsについてはCopilot系の分析機能との棲み分けがまだ不明確な印象もある。「AIが何かを検知した」というインサイトが、実際に現場のIT担当者にとって使いやすいワークフローに落ちるかどうか——機能の追加より、運用への定着設計の方が難易度は高いと思っている。 Microsoftが持つ統合基盤の強みは、こういうタイミングに改めてよくわかる。バラバラのポイントソリューションを寄せ集めるのではなく、Entra ID・Intune・Defenderが連携した一枚岩の管理基盤として価値を出せるポテンシャルは本物だ。その方向性でぜひ走り続けてほしい。 出典: この記事は Microsoft 365 adds advanced Microsoft Intune solutions at scale の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Windows Server 2016 に Microsoft が2026年5月リリースした累積更新プログラム KB5087537 をインストールした環境で、ドメインコントローラー（DC）の検出が失敗するバグが確認された。Microsoft はこれを公式の既知の問題（Known Issue）として認識しており、Active Directory を運用する企業環境では即座の状況確認が必要だ。 何が起きているのか ドメインコントローラー検出（DC Lookup）とは、Windows クライアントおよびサーバーが Active Directory の DC を特定し、認証・グループポリシー適用などのサービスを受けるための基盤プロセスだ。これが機能しなくなると、ユーザーはドメインにログオンできなくなり、グループポリシーの適用も停止する。 今回の問題は、特定のホスト名条件を持つ Windows Server 2016 マシンで KB5087537 のインストール後に発生する。Microsoft は公式に問題を確認しており、回避策と修正の提供に向けた対応が進んでいる。 影響を受ける構成 現時点で明らかになっている情報は以下のとおりだ。 影響 OS: Windows Server 2016 トリガー: 2026年5月の累積更新プログラム KB5087537 症状: ドメインコントローラーの検出失敗、それに伴う認証エラーおよび管理機能の停止 条件: 特定のホスト名条件（詳細は Microsoft の Windows Server 2016 リリース正常性ページを参照） Windows Server 2019・2022・2025 への影響は現時点では報告されていない。 実務への影響 ドメインコントローラー検出の失敗は、単なるパフォーマンス低下ではなく 業務停止レベルの障害 に直結する。具体的には以下の機能が影響を受ける。 ユーザーログオンの失敗: ドメインアカウントでのサインインができなくなる グループポリシーの適用停止: セキュリティポリシーやソフトウェア配布が止まる AD 連携サービスへの影響: SharePoint、Exchange、SQL Server など Active Directory に依存するサービスが正常動作しなくなる Windows Server 2016 は延長サポートが2027年1月まで続くため、日本の多くのオンプレミス環境で現役稼働中だ。「まだ使えるから」と継続運用している環境ほど、今回のような更新起因の障害に直撃されやすい。 ...

Microsoft 365 Copilotは2026年5月のアップデートで、OpenAIの「GPT-5.5 Instant」とAnthropicの「Claude Opus 4.8」を新たに統合した。カレンダー管理を自動化する「Copilot Calendar Agent」も同時に登場し、M365のAI機能がまた一歩進化した。 GPT-5.5 Instant——低レイテンシと画像理解 GPT-5.5 InstantはOpenAIの最新モデルで、低レイテンシを売りにしている。特に以下の用途で威力を発揮する。 画像入力のサポート: スクリーンショットや図表をそのまま貼り付けて質問できる STEM分野の最適化: 数学・科学・技術系の計算や推論に強い 即応性重視のシナリオ: 待ち時間を感じさせない素早い応答 毎日何十回もAIに質問するヘビーユーザーにとって、レイテンシの差は地味に効いてくる。 Claude Opus 4.8——複雑なタスクの切り札 Anthropicの「Claude Opus 4.8」もM365 Copilotに統合された。Opusシリーズはマルチステップの複雑なタスク処理を得意とし、長文の読み込みや段階的な推論が求められる場面で力を発揮する。 M365環境に閉じたまま、GPT-5.5の速さとClaude Opusの深さを使い分けられる選択肢が生まれた形だ。 Copilot Calendar Agent——自然言語でスケジュール管理 新登場の「Copilot Calendar Agent」は、自然言語の指示でカレンダーの管理を自動化する。 「来週の午後に2時間のブロックを確保して」 「プロジェクトXのメンバー全員が空いている時間を探して会議を入れて」 「定期の1on1を30分短縮して」 こうした指示を日本語で入力するだけで、カレンダー操作を代行する。OutlookやTeamsと連携しているため、既存の業務フローにも乗りやすい。 実務への影響——日本のエンジニア・IT管理者に何が変わるか モデル選択の実用的な判断軸 複数モデルが選べるようになった今、「どれを使うべきか」という判断が必要になる。 シナリオ 推奨モデル 素早い質問・即興の壁打ち GPT-5.5 Instant 長文ドキュメントの深掘り・多段階の分析 Claude Opus 4.8 通常のExcel/Word/メール作業 既存のCopilot Calendar Agentの実運用でのポイント Calendar Agentは便利そうに見えるが、企業利用では以下の点を先に整理しておきたい。 権限スコープの確認: エージェントがどこまでカレンダーを操作できるか、管理者ポリシーで制限する 外部参加者の扱い: 社外の人が含まれる会議の自動設定は人間がレビューする運用を推奨 変更のログ確認: エージェントが行った操作をAudit Log（管理センター）で追える設定にしておく 筆者の見解 率直に言えば、複数のAIモデルを選べるようになったこと自体は歓迎したい方向性だ。用途に応じてモデルを使い分ける「賢い使い方」の余地が生まれた。 ただし、モデルの数を増やすこととユーザーが実際に価値を得ることは別の話だ。複数モデルが並ぶことでUIが複雑になり、「どれを選んだらいいかわからない」というユーザーを増やすリスクもある。Microsoftには、モデル選択の判断をCopilotが自動的に最適化する仕組みを磨き込んでほしい。ユーザーが毎回悩まなくていい状態こそが「本当のAI支援」だ。 Calendar Agentのアイデアは面白い。カレンダーは日々の生産性に直結するし、スケジュール調整のストレスを減らせるなら価値は高い。とはいえ、エージェントが勝手にスケジュールを変更した結果トラブルが発生した場合、IT部門への問い合わせが増えることは容易に想像できる。エンタープライズ展開前にパイロット期間を設け、トラブルシューティングのフローを先に整備しておくことを強く勧める。 Microsoftが持つユーザーベースとM365の統合力は今も強力な資産だ。その資産を最大限に活かすためにも、一つひとつのAgentとモデルを確実に磨いていってほしい。「総合力では一番」の立場をAI領域でも取り戻せるポテンシャルはある。 出典: この記事は What’s New in Microsoft 365 Copilot | May 2026 | Microsoft Community Hub の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoftは2026年5月28日、中小企業向けの新SKU「Microsoft 365 Business Standard with Copilot」および「Microsoft 365 Business Premium with Copilot」を2026年7月1日から提供開始すると発表した。これまでアドオンとして別途購入が必要だったCopilot機能を最初からバンドルし、中小企業におけるAI活用を「標準」として位置づける狙いだ。 CopilotをM365の「標準装備」として再定義 これまでMicrosoft 365 BusinessプランにCopilotを追加するには、別途ライセンスを購入する必要があった。今回の変更で、Business StandardおよびBusiness Premiumの各Copilot付きバリアントが新たに設けられ、AI機能が最初から組み込まれた形で提供される。発表を担当したのはMicrosoft 365およびCopilot担当コーポレートバイスプレジデントのNicole Herskowitz氏で、中小企業向けのAI活用を「新たな標準（new standard）」として推進するMicrosoftの意志が明確に示されている。 1,000以上のコネクタとの連携が最大の特徴 新プランで注目すべきは、Shopify・PayPal・Asanaをはじめとする1,000以上の外部サービスとのコネクタ連携が含まれている点だ。ECプラットフォームや決済サービス、プロジェクト管理ツールと直接連携することで、業務データをCopilotのAI分析に活かせる。たとえば、Shopifyの売上データをExcelやTeamsのCopilotに取り込んで在庫判断や売上予測に使う、といったユースケースが想定される。 ただし、コネクタの数が多いことと、実際に使いこなせることは別問題だ。中小企業では専任のIT担当者がいないケースも多く、コネクタの設定・運用には一定の技術的知識が求められることを念頭に置いておく必要がある。 実務への影響：日本の中小企業・IT担当者が確認すべきこと 7月1日前後の契約変更を要確認 既存のBusiness StandardまたはBusiness Premiumを利用中の場合、7月以降の契約がどう変わるのかを早めに確認すべきだ。新SKUへの自動移行なのか、価格はどう変わるのか、既存ユーザーに選択肢があるのかについては、Microsoft公式または担当リセラーへの問い合わせを推奨する。 Copilotの恩恵を受けやすい業務から着手する Copilotがバンドルされても「どこから使えばいいか分からない」という状況に陥りがちだ。まずはTeamsの会議の文字起こしと要約、Outlookのメール下書き支援、ExcelのPivotやデータ整理支援といった、ROIが見えやすい業務から試すのが現実的なアプローチだ。 コネクタ連携はEC事業者に特に刺さる ShopifyやPayPalとの連携は、小規模EC事業者にとって実際の業務改善に直結する可能性がある。注文データや顧客データをCopilotで分析できれば、手作業でのCSV集計が不要になるケースもある。ただし、連携に必要な設定やデータの取り扱いポリシー（特に個人情報）については、事前に確認と整備が必要だ。 利用ポリシーの整備はセットで AIバンドルの導入と同時に、「何をCopilotに入力してよいか・よくないか」という社内ポリシーの策定も欠かせない。特に中小企業は顧客情報や取引情報が少人数で管理されているケースが多く、AI入力データの管理は慎重に行う必要がある。 筆者の見解 Copilotをバンドルして「標準」と定義するMicrosoftの方向性は、プラットフォーム戦略として一貫している。エンタープライズ向けと同様、中小企業にもAIを「特別な追加オプション」ではなく「最初からある道具」として提供したい意図は明確だ。 正直なところ、Copilotがこの「標準」というポジションを実力で支えられているかは、まだ使う人によって評価が割れる。特に日本語対応の深さや、実際の業務フローへの馴染みやすさについては、エンタープライズ用途での課題がそのまま中小企業向けにも引き継がれる可能性がある。 ただ、Microsoftには実力がある。プラットフォームとしての強さ、Office文書との親和性、Teams・Outlook・Excelという企業ITのど真ん中を押さえているという事実は揺るがない。バンドルによる導入ハードルの引き下げは一手だが、それよりも「使い続けたいと思えるCopilot体験」の実現がより重要だと思っている。コネクタ1,000以上という数字に説得力を持たせるには、その先のユーザー体験がついてこなければならない。7月以降の現場からの反応を、引き続き注視していきたい。 出典: この記事は Introducing Microsoft 365 Business with Copilot: The new standard for small business の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftのセキュリティ研究チーム（Microsoft Defender Security Research Team）は2026年5月28日、「Mini Shai-Hulud」と名付けられた悪意あるnpmパッケージキャンペーンが、開発者環境のクラウド認証情報およびCI/CDシークレットを組織的に窃取していると報告した。 Mini Shai-Hulud とはどんな攻撃か このキャンペーンはタイポスクワット（typosquatting）という古典的だが今も有効な手口を利用している。タイポスクワットとは、広く使われている正規パッケージ名に似た「打ち間違えやすい名前」のパッケージを公開し、開発者が誤ってインストールしてしまうのを狙う攻撃だ。 例えば lodash に対して lodahs や lod4sh のような名前のパッケージをnpmレジストリに登録し、npm install 時のタイプミスやコピペミスを悪用する。インストールされた悪意あるパッケージは、インストール時または初回実行時にポストインストールスクリプト（postinstall）を起動し、以下のような情報を外部サーバーへ送信する。 クラウド認証情報: AWS、Azure、GCPの環境変数に格納されたアクセスキーや接続文字列 CI/CDシークレット: GitHub Actions、GitLab CI、Azure DevOpsなどのパイプライン変数 開発者ローカル環境: .env ファイル、SSHキー、認証トークン 「Mini Shai-Hulud」というキャンペーン名は、映画『デューン』に登場する砂の大虫（Shai-Hulud）に由来するとされる。地下に潜んで気づかれにくいという特性を示唆したネーミングだ。 攻撃チェーンの詳細 攻撃の流れは大まかに次の通りだ。 悪意あるパッケージをnpmレジストリに公開: 人気パッケージの類似名を取得し、package.json の scripts.postinstall に攻撃コードを仕込む 開発者が誤ってインストール: ローカル開発環境、Dockerビルド、CI/CDパイプライン上いずれでも発動する 環境変数とファイルシステムをスキャン: OSの環境変数、.env ファイル、設定ファイル群を走査 外部C2サーバーへのデータ送信: 窃取したシークレットを攻撃者のサーバーへHTTP/HTTPSで送信 横展開: 取得した認証情報を使ってクラウドリソースへ不正アクセス 特にCI/CDパイプラインが標的になることで、ソフトウェアサプライチェーン攻撃へ発展する可能性がある。パイプラインが侵害されれば、本番デプロイに悪意あるコードを注入されるリスクがある。 実務への影響 — 日本のエンジニアが今日からできること 1. npm install 前にパッケージ名を2回確認する コピペでも手打ちでも、パッケージ名は必ずnpmjs.comで検索して確認する習慣をつけたい。特に「ちょっとしたユーティリティ」として導入する小さなパッケージは要注意だ。インストール数や公開日、メンテナンス状況を見ると偽物の見分けがつきやすい。 2. postinstall スクリプトを監査する npm install --ignore-scripts オプションを活用すると、インストール時のスクリプト実行を抑止できる。CI/CDパイプラインでは特にこのオプションを検討したい。また、npm audit や socket.dev、Snyk といったサプライチェーン監査ツールを導入することで、不審なスクリプトを自動検出できる。 3. CI/CDのシークレットは最小権限で管理する GitHub ActionsやAzure DevOpsでは、シークレットの有効期限を設定し、不要になったらすぐに失効させる運用を徹底する。また、クラウドへのアクセスにはマネージドID（Azure Managed Identity）やOIDC（OpenID Connect）を利用し、長期間有効な静的キーを環境変数に保持しない構成が理想だ。 ...

Microsoft は、2026年5月27日のメッセージセンター通知（MC1324288）で、「Microsoft 365 Usage Analytics」Power BI テンプレートアプリを 2026年8月1日をもって廃止すると発表した。テナントの Microsoft 365 利用状況をワンクリックで可視化してきた定番ツールが、約9年の役割を終える。 Microsoft 365 Usage Analytics とは何だったのか 2017年に「Office 365 adoption Power BI content pack」として登場したこのアプリは、Exchange Online・SharePoint Online・Teams・Yammer などの利用状況データをテナント管理者がサインインするだけで取り込み、Power BI ダッシュボードとして可視化できる仕組みだった。 当時は利用状況を把握する手段がほとんど存在せず、「Office 365 のライセンスにお金を払っているが、実際に使われているのか」という疑問に答えるツールとして重宝された。Power BI の表現力を活かした美しいレポートは、IT 部門が経営層に投資対効果を示す際にも活躍した。 廃止のスケジュールと代替手段 日付 内容 2026年6月1日 テンプレートアプリの新規ダウンロードをブロック 2026年8月1日 アプリおよびデータパイプラインの終了（end of support） Microsoft が提示する代替手段は2つ: Microsoft 365 管理センターの利用状況レポート 管理センター内に組み込まれた Graph ベースのレポートで、Exchange Online・Teams・SharePoint・Planner・Visio・ブラウザ・Microsoft 365 Copilot まで幅広くカバーしている。データ鮮度はリアルタイムから2日遅れで、従来の Power BI アプリ（月次更新）より大幅に改善されている。 Graph usage reports API を利用した自作 Power BI ダッシュボード Graph API 経由でデータを取り込み、自前のダッシュボードを構築する方法。Microsoft は「テンプレートアプリの代替となる単一パッケージのソリューションは提供しない」と明言しており、カスタマイズが必要な場合は DIY 対応が求められる。 ...

Microsoft が2026年5月、Microsoft 365 Notebooks に複数の大型機能を一斉追加した。SharePoint コンテンツや OneNote ノートブックの参照、Copilot による Pages 直接編集、ノートブックから Word・PowerPoint を生成する機能が順次展開される。 今回追加された主な機能 SharePoint・OneNote との統合参照 これまで M365 Notebooks は比較的スタンドアローンなツールだったが、今回のアップデートで SharePoint に格納されたドキュメントや OneNote ノートブックをコンテキストとして直接参照できるようになった。散在していた社内ナレッジを Notebooks の探索・整理機能と組み合わせて活用できる基盤が整いつつある。 Copilot による Pages 編集 Copilot が Notebooks 内の Pages を直接編集できる機能が追加された。テキストの言い換えや構成変更といった基本的な編集から、コンテキストを踏まえた内容補完まで対応する。これまでは「Copilot に聞いて、内容を自分でコピーする」という手順が必要だったが、このステップが省ける。 Word・PowerPoint の直接生成 ノートブックの内容をもとに Word 文書や PowerPoint プレゼンテーションを直接出力できるようになった。調査・ブレインストーミングから成果物作成までが Notebooks 内で完結する。 マインドマップ・学習ツールの強化 情報の可視化を助けるマインドマップ機能と、知識定着を支援する学習ツール群が強化された。情報量が増え続ける中で、「収集から理解」へのプロセスを構造化する支援ツールとしての側面が強まっている。 日本のエンジニア・IT管理者への実務的な意味 日本企業では SharePoint をすでにドキュメント管理の基盤として使っている組織が多い。Notebooks からその資産を参照できるようになれば、「SharePoint を検索して内容を転記する」という非効率な作業を削減できる可能性がある。 Word・PowerPoint への直接出力は、ドキュメント作成業務が多い日本のビジネス現場に馴染みやすい。Notebooks で構造化した内容がそのまま社内文書として出力できれば、ツールの行き来によるコストが下がる。 実際の展開では注意点もある。Copilot ライセンスの有無、SharePoint のアクセス権限設計が適切かどうかによって、使える機能の範囲が変わる。大企業では権限構造が複雑になりやすいため、全社展開の前に部門単位での小規模パイロットで動作確認することを強く推奨する。 筆者の見解 M365 Notebooks が SharePoint・OneNote・Word・PowerPoint と深く統合される方向性は、Microsoft の統合プラットフォーム戦略として一貫している。部分ツールとして独立させるより、エコシステム全体の「接着剤」として機能させることでこそ価値が出る。この設計思想は正しい。 一方で、機能の追加と現場での実用性は別の話だ。「Copilot で Pages が編集できる」「Word が生成できる」という機能は魅力的だが、使いこなすにはデータ設計と権限設計がきちんと整備されている必要がある。この整備が追いついていない組織では、機能だけが増えて実態は使われないままになるリスクがある。 ...

セキュリティベンダーESETは、中国と関連するサイバースパイ集団「Webworm」が、DiscordおよびMicrosoft Graph APIを指令・制御（C2）通信の隠れ蓑として悪用し、ヨーロッパの政府機関への侵入・長期潜伏を継続していると報告した。正規の信頼済みクラウドサービスをC2チャネルとして利用することで、従来のネットワーク監視をすり抜ける高度な手口が明らかになった。 Webwormとはどんな脅威アクターか Webwormは、中国政府と関連があるとされるAPT（Advanced Persistent Threat）グループだ。主に政府機関・防衛・外交関連組織を標的とし、長期的なサイバースパイ活動を目的とする。今回の攻撃キャンペーンでは、ヨーロッパの政府組織が主要な標的となっており、ESETの分析によると、侵入後の永続的アクセス確保と情報窃取が最終目標とみられている。 Discord・Microsoft Graph APIをC2に使う手口 今回の攻撃で特に注目すべきは、C2通信の隠ぺい手法だ。 Discordの悪用では、正規のDiscordチャンネルやDMをC2サーバーとして利用する。攻撃者はDiscordのWebhookやBot APIを通じて感染端末へ命令を送り、窃取した情報を受け取る。企業ネットワーク内でDiscordへの通信が許可されている場合、この通信は「正規のDiscordトラフィック」と区別がつかない。 Microsoft Graph APIの悪用も同様の発想に基づく。OneDriveやOutlookのメールボックスをデータの中継・保管場所として使い、Graph APIを通じて読み書きすることでC2通信を実現する。Microsoft 365のエンドポイントへの通信は多くの企業で許可リストに入っているため、セキュリティツールの目をかいくぐりやすい。 こうした手法は「Living-off-the-Land（環境寄生）」攻撃の進化形であり、攻撃インフラを自前で用意するのではなく、被害組織自身が日常的に使うサービスに乗り込む点が巧妙だ。 ステルス性を高めるプロキシネットワークの活用 Webwormはさらに、OperationalRelayBox（ORB）と呼ばれるプロキシネットワークも活用していると報告されている。これは侵害済みのルーターやIoT機器、VPSなどを踏み台として連鎖させる手法で、攻撃元IPの追跡を困難にする。ネットワーク層・認証層・認可層のいずれの観点から見ても、発信元を特定することが極めて難しい構造になっている。 実務への影響——日本のエンジニア・IT管理者が今日から取るべき対策 この攻撃手法は、欧州政府機関だけの問題ではない。日本の官公庁・大手企業・インフラ企業も同様のリスクにさらされている。以下の点を即座に確認すべきだ。 1. Microsoft Graph APIへのアクセス監視 Entra ID（旧Azure AD）の監査ログで、ServicePrincipalやアプリ登録経由のGraph APIアクセスを定期的にレビューする。見知らぬアプリ登録が存在しないか、特にMailboxやOneDriveへのアクセス権限を持つものを優先確認すること。 2. Discordへの通信制御 業務上必要のない端末・サーバーからのDiscord通信はファイアウォールでブロックする。許可している場合でも、異常な通信頻度や時間帯のログを監視する。 3. 条件付きアクセスポリシーの見直し 「すべてのクラウドアプリを一律に信頼する」構成は見直す必要がある。マネージドデバイス・準拠デバイス以外からのアクセスを制限し、特権ロールに対してはPhishing-resistant MFA（FIDO2/Windows Hello for Business）を必須化する。 4. 非人間ID（NHI）の棚卸し サービスプリンシパル・マネージドID・APIキー等の非人間IDに過剰な権限が付与されていないか定期的に監査する。使われていない認証情報は即座に無効化すること。 5. ネットワーク内部の横断移動（ラテラルムーブメント）対策 侵入を前提とした「内部脅威」への対応として、ゼロトラストアーキテクチャの徹底と、マイクロセグメンテーションによる被害の局所化が有効だ。 筆者の見解 この攻撃キャンペーンで最も重要な示唆は、「信頼済みサービスへの通信が安全とは限らない」という当然の事実を、多くの組織がまだ運用上の現実として消化できていない点だ。 DiscordやMicrosoft Graph APIへのアクセスを「ホワイトリスト登録済みだから問題ない」と思考停止するのは、昔のVPNで外部トラフィックをすべて塞いでいれば安全と考えていた時代の発想と本質的に変わらない。ゼロトラストの本来の意味は、「ネットワークの内外を問わず、すべてのアクセスを都度検証する」ことであり、通信先が有名サービスであることはそれ自体では何の保証にもならない。 特に懸念するのは、Microsoft 365を全社導入しているにもかかわらず、Graph APIやEntra IDの監査ログをほとんど見ていない組織の多さだ。ツールは揃っているのに使われていない。Microsoft Sentinelや Microsoft Defender for Cloud Appsを活用すれば、今回のような異常なGraph APIアクセスパターンはかなりの精度で検出できる。導入済みの機能を使い切る——それだけでセキュリティ態勢は大きく変わる。 日本の大企業では、レガシーなセキュリティモデルとゼロトラストの取り組みが中途半端に混在し、かえって死角を生んでいるケースをよく見かける。Webwormのような高度な脅威アクターは、まさにそうした「ハイブリッドな曖昧さ」を狙ってくる。今こそ、Microsoft 365に含まれているセキュリティ機能を正面から使い倒す好機だ。 出典: この記事は Webworm APT Uses Discord And Microsoft Graph To Target European Governments の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

HPは、一部のプレミアムビジネスノートPC向けに配信した最新BIOSファームウェアアップデートが、システムのクラッシュや起動ループを引き起こしているとの多数の報告を受け、現在公式に調査を進めている。 何が起きているか 今回の問題は、HPが配信したBIOS（Basic Input/Output System）ファームウェアの更新プログラムを適用した後に顕在化している。報告されている症状は以下のとおりだ。 システムの著しい動作遅延：アップデート適用後から全体的なパフォーマンスが低下する ブルースクリーン（BSOD）の頻発：Windowsが突然クラッシュし再起動を繰り返す 起動ループ：最も深刻なケースでは、Windowsが正常に起動できずに再起動を繰り返す「スタートアップループ」状態に陥り、通常の手順では回復が困難になる 影響を受けているのは、HPのプレミアムラインナップ、特に法人向けElitebookシリーズなど高価格帯モデルが中心とされている。一般的なBIOSアップデートが「ルーティンな作業」から重大な業務障害へと発展するケースが相次いでおり、HPは現在、詳細の調査と対処法の提供に向けて動いている。 BIOSアップデートとはそもそも何か BIOSはPCの電源投入後に最初に動作するファームウェアで、ハードウェアの初期化やOSへの制御の引き渡しを担う。アップデートの目的は主に、セキュリティ脆弱性の修正、新しいCPUやメモリへの対応、安定性の向上などだ。 通常、BIOSアップデートは慎重なリグレッションテストを経て配信されるべきものだが、今回のように広範囲のユーザーに影響が出る問題が見つかった場合、その更新プログラムの品質管理プロセスに疑問が生じることになる。 現時点での対処法 HPからの公式な修正パッチはまだ提供されていないが、現時点でユーザーが取れる対策は以下のとおりだ。 BIOS更新を一時停止する：問題が解決されるまで、該当するBIOSアップデートの適用を保留にする 以前のBIOSバージョンへのロールバックを検討する：一部のHP製品ではBIOS Recovery機能を利用して以前のバージョンに戻せる場合がある（機種によって手順が異なるため、HP公式サポートページを参照のこと） HP公式情報をウォッチする：HPのサポートページおよびコミュニティフォーラムで最新情報を確認する 実務への影響——日本のIT管理者が今すぐ確認すべきこと 今回の問題は、企業のIT管理部門にとって他人事ではない。法人向けノートPCとしてHPのElitebook等を導入している環境では、エンドポイント管理ツール（Microsoft IntuneやSCCM/MECM等）を通じてファームウェアアップデートが自動展開されるように設定されているケースがある。 即時確認すべき事項： 自動アップデートポリシーの一時停止または除外設定：Intuneのデバイスポリシーや、HPのBIOS管理ツール（HP BIOS Configuration Utility等）でBIOSアップデートの自動適用を無効化する 影響モデルのインベントリ確認：管理下のHP端末の型番と現在のBIOSバージョンを棚卸しする。Intuneであればデバイスのレポート機能で確認できる パイロット展開の徹底：今後のファームウェアアップデートは、まず少数の検証端末で適用→1週間程度の安定稼働確認→全体展開というフローを改めて徹底する ユーザーへの周知：すでに問題の症状が出ているユーザーがいる場合は、自己判断で再起動を繰り返さないよう案内し、IT部門に報告するよう促す とりわけ「起動ループ」状態に陥った場合、一般ユーザーが自力で回復することは難しく、オンサイト対応またはHPサポートへの依頼が必要になる。リモートワーク環境の端末が起動不能になった場合のインパクトは特に大きいため、早期の情報収集と予防措置が重要だ。 筆者の見解 BIOSというのは「触らぬ神に祟りなし」と言われがちな領域だが、今日のセキュリティ要件においてファームウェアのアップデートは避けて通れない。特にTPMやセキュアブート絡みの脆弱性対応は、放置するとゼロトラスト構成の足元を崩す。にもかかわらず、今回のようなインシデントが起きると「やっぱり当てないほうがいい」という保守的な方向に組織全体が振れてしまいがちで、それはそれで困る。 「適用して壊れるより、当てないほうがまし」という判断が積み重なった先にある光景は、脆弱性だらけのファームウェアが数年間放置された法人PCの山だ。これは2025年以降の脅威環境では到底許容できない。 HPには、今回の不具合の根本原因と再発防止策を速やかに公開してほしい。原因が品質管理プロセスの問題なのか、特定ハードウェア構成との相性なのかによって、IT管理者の対処方針も変わってくる。プレミアムラインの信頼性は価格帯に見合ったものであるべきで、「高いから安心」がいつまでも通用する前提はない。 今回の件を機に、自社のエンドポイントにおけるファームウェアアップデートのガバナンス——誰が、いつ、どのデバイスに、どのように適用を承認するか——を見直す良い機会と捉えていただきたい。 出典: この記事は HP Investigates BIOS Updates Causing Crashes, Startup Loops On Premium Laptops の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftはSharePointおよびOneDriveにおけるMarkdown（.md）ファイルのネイティブブラウザ編集機能を正式リリース（GA）し、2026年4月下旬から5月にかけて展開を進めている。専用ツールのインストールや管理者による追加設定なしに、ブラウザだけでMarkdownの閲覧・編集・プレビューが可能となった。 これまでの課題と今回の変化 これまで、SharePointやOneDriveに保存された.mdファイルをブラウザで開くと、書式が一切レンダリングされず生のテキストがそのまま表示されるだけだった。Markdownとして確認・編集するには、ローカルのVS CodeやObsidianなどを起動するか、GitHubなど外部サービスに持ち出す必要があり、M365エコシステムの中で完結しない不便さがあった。 今回のアップデートでこのギャップが埋まる。.mdファイルをSharePointまたはOneDrive上で開くだけで、新しいMarkdownエディタが自動的に起動する。 3つの編集モード 新エディタは用途に応じた3つのモードを備えている。 Viewモード: レンダリングされた見やすい形式でMarkdownを閲覧 Editモード: 生のMarkdownテキストを直接編集 Splitモード: 左ペインで編集しながら右ペインでリアルタイムプレビューを確認 SplitモードはVS CodeやObsidianのSplit Viewに近い使い心地を、ブラウザ上で実現している点が特筆に値する。 設定ゼロ・Teams/Outlookともシームレスに連携 この機能の大きなポイントは「設定不要」で使えることだ。テナント管理者側での有効化操作も、エンドユーザー側のアプリインストールも必要ない。SharePointやOneDriveに.mdファイルを配置するだけで、次回以降のアクセスから新しいエディタが有効になる。 TeamsのチャンネルファイルタブやOutlookからSharePoint上のMarkdownファイルを開いた場合も同じエディタが動作する。M365の各サービスが一貫したUXでMarkdownを扱えるようになった点は、統合プラットフォームとしての強みが出ている部分だ。 実務への影響 開発チームのドキュメント管理が変わる GitHubと並行してSharePointでドキュメントを管理しているチームにとって、これは実質的な改善だ。設計書やREADMEなどの.mdファイルをSharePoint上で直接確認・編集できるようになれば、「ダウンロード→ローカルで編集→再アップロード」という手間のかかるフローを省ける。 非エンジニアとの共同編集 Markdownはエンジニアには自然な書式だが、ビジネスサイドのメンバーには扱いにくかった。SharePointという慣れ親しんだインターフェースの中でMarkdownがきれいにレンダリングされることで、技術者と非技術者が同じドキュメントを共同で管理するハードルが下がる。 Copilotとの連携を見越した準備 Markdownはプレーンテキストベースのフォーマットであるため、AIによる読み取り・生成との相性が良い。SharePoint上のMarkdownコンテンツをCopilotのナレッジソースとして参照するワークフローを構築する際、ネイティブのブラウザ表示が整っていることは前提条件として重要になってくる。 筆者の見解 SharePoint・OneDriveのMarkdownネイティブ対応は、地味に見えて実は重要なアップデートだ。 Markdownはエンジニアリングの現場を超え、社内Wiki・技術ドキュメント・AI出力テンプレートとして急速に用途を広げている。それをM365エコシステムの中でシームレスに扱えるようにすることは、プラットフォームとしての成熟を示す動きだと評価している。 正直に言えば、「やっと来た」という感覚もある。NotionやConfluenceはとっくにMarkdownを当然の機能として提供しており、M365エコシステムの中で日常的に仕事をしているユーザーにとって、これが「新機能」として扱われること自体が、逆に遅れを示しているとも言える。 ただ、遅くとも届けてくれることは、届かないよりはるかに良い。M365は「統合して使ってこそ価値が出る」プラットフォームであり、SharePoint・OneDrive・Teams・Outlookが一貫した体験でMarkdownを扱えるようになれば、ドキュメント管理の中心としての説得力が増す。この積み重ねが、M365を日常の仕事の軸として使い続けるための土台になっていくことを期待している。 出典: この記事は Introducing Markdown support in SharePoint and OneDrive の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年5月12日、SharePoint Server Subscription Editionを対象とした累積セキュリティ更新プログラム（KB5002863）をリリースした。認証済み攻撃者がネットワーク経由でリモートコード実行（RCE）を可能にする7件のCVEに対処するもので、オンプレミスのSharePoint環境を運用するすべての組織に即時適用が推奨される。 対処する7件のCVE一覧 今回の更新プログラムは、すべてリモートコード実行（Remote Code Execution）に分類される脆弱性7件を修正する。 CVE番号 分類 CVE-2026-40357 RCE CVE-2026-33112 RCE CVE-2026-33110 RCE CVE-2026-40368 RCE CVE-2026-35439 RCE CVE-2026-40367 RCE CVE-2026-40365 RCE 「認証済み攻撃者によるネットワーク経由のRCE」という条件は、一見すると「認証が必要なので大丈夫」と思われがちだが、それは誤りだ。社内ユーザーや不正に取得した認証情報を用いた攻撃者が踏み台として利用できるケースは多く、内部からの侵害やフィッシング経由での認証情報漏洩が現実に起きている日本企業の環境では、決して軽視できない深刻度だ。 適用後のビルドは 16.0.19725.20280。現在のビルドバージョンはSharePoint管理センターの「システム設定」→「このファームのサーバーを管理する」から確認できる。 適用前に必ず確認すべき前提条件 このアップデートには適用順序の制約がある。見落とすとファームが不安定になる可能性があるため、事前確認を徹底されたい。 SharePoint Workflow Managerを利用している場合 SharePoint Workflow Manager（KB5002799）を先にファームへインストールする必要がある。本パッチを先に当てると問題が発生する可能性があるため、適用順序を必ず守ること。 Classic Workflow Managerを利用している場合 Classic版を継続利用するには、以下のPowerShellコマンドでデバッグフラグを有効にしてから iisreset を実行する必要がある。 出典: この記事は Description of the security update for SharePoint Server Subscription Edition: May 12, 2026 (KB5002863) の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftがAndroid向け軽量メールアプリ「Outlook Lite」を2026年5月25日をもって完全廃止する。既に2025年10月からGoogle Playでの新規ダウンロードが停止されており、既存ユーザーもこの日を境にアプリからメールボックスへアクセスできなくなる。 Outlook Liteとは何だったのか Outlook Liteは、通信速度が低速な環境や、ストレージ容量が限られたローエンドAndroid端末向けに設計された軽量版Outlookアプリだ。アプリサイズを大幅に抑えつつ、メール・カレンダーの基本機能を提供することで、新興国市場や企業のBYOD環境における廉価端末での利用を想定していた。 Microsoftは2022年ごろから積極的に展開してきたが、約4年での終了となる。 移行先と注意点 Microsoftが推奨する移行先はOutlook Mobile（Android版）だ。移行にあたっての主なポイントは以下のとおり。 メールデータ・連絡先は保持される: データはサーバー側（Exchange Online / Microsoft 365 / Outlook.com）に保存されているため、アプリを切り替えても消失しない アプリからのアクセスは廃止日以降不可: Outlook Liteアプリ自体が機能停止するため、新しいアプリへの移行が必要 Google Playからのインストール: Outlook Mobile（旧称: Microsoft Outlook）は通常版としてGoogle Playで引き続き提供される 移行手順はシンプルで、Outlook Mobileをインストールしてアカウント情報でサインインするだけだ。MDM（モバイルデバイス管理）を利用している環境では、管理者側でポリシーを確認し、必要であれば展開対象アプリを更新する必要がある。 企業IT管理者への影響 日本企業においてもBYODや会社支給のAndroid端末でOutlook Liteを利用しているケースがある。IT管理者として確認すべき点を整理する。 1. 利用状況の把握 Intune（Microsoft Endpoint Manager）やその他MDMのデバイスインベントリでOutlook Liteのインストール状況を確認する。対象端末数が多い場合は、段階的な移行計画を立てると良い。 2. アプリ構成ポリシーの更新 Microsoft Intuneでアプリ構成ポリシーや保護ポリシー（App Protection Policy）をOutlook Liteに適用していた場合、Outlook Mobileへの適用に切り替える作業が必要だ。Outlook MobileはIntune MAM（モバイルアプリ管理）に対応しているため、設定自体は引き継げる。 3. 条件付きアクセスの確認 Entra ID（旧Azure AD）の条件付きアクセスで「承認済みクライアントアプリ」を指定している場合、Outlook Mobileが対象に含まれているか確認しておく。標準的な設定であれば問題ないはずだが、カスタマイズが多い環境では要チェックだ。 4. エンドユーザーへの周知 廃止日をまたいで気づかないユーザーが出ると問い合わせが増える。5月25日以前に社内通知を出し、自発的な移行を促すことを推奨する。 筆者の見解 Outlook Liteの廃止そのものは、Microsoftのモバイルアプリ戦略を「Outlook Mobile」に一本化する流れとして理解できる。分散した複数のアプリを維持するコストとUXの一貫性を考えれば、統合の判断は妥当だ。 ただし、Outlook Mobileはかつての「Acompli」を買収して作られたアプリであり、軽量性という点ではLiteに及ばない面がある。通信環境や端末スペックが限られた状況での使用感が気になるユーザーは、移行後の動作を実機で確認しておくと安心だ。 Microsoft 365全体のアプリ体験については、「一つのサービスとして統合して使う」ことで真価が発揮されるプラットフォームだと今も思っている。モバイル体験の足並みがそろうことで、Teams・Outlook・OneDriveをシームレスに使える環境が整うのであれば、今回の統合は前向きに評価したい。 今後Outlook MobileがさらにIntune連携やCopilot機能を強化していくことが予想されるが、軽量性・パフォーマンスの改善にも引き続き投資してほしいというのが正直な期待だ。「重くて使えない」という声が広がると、せっかくの統合戦略が逆効果になりかねない。 出典: この記事は Outlook Lite Shutdown Confirmed as Microsoft Pushes Users to Outlook Mobile の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoftは2026年4月27日、Microsoft 365 Frontierプログラムの一環として、Outlook向けCopilotに「エージェントモード」を追加した。これまでのオンデマンド補助から一歩踏み込み、メールの整理・フォローアップ・カレンダー管理を自律的に実行できる機能として提供が開始される。 「補助ツール」から「自律エージェント」への転換 従来のCopilot in Outlookは、ユーザーが明示的に操作した場合にのみメールの下書きやスレッド要約を行う「リアクティブ」な仕組みだった。今回のエージェントモードでは、ユーザーの指示を待たずにバックグラウンドで継続的に動作する「プロアクティブ」な仕組みへと転換する。 マルチステップのワークフローをコンテキスト理解と事前設定に基づいて自律実行するが、すべての操作はユーザーが確認・修正・キャンセルできる透明性が確保されている。 受信トレイ自動管理の主要機能 エージェントモードが提供する受信トレイ管理の主な機能は以下のとおり： 未解決スレッドの自動フォローアップ: 24時間返信がないメールを検出し、フォローアップ文を自動生成 週次プロジェクト更新の抽出: 進捗メールをまとめて管理層向けのブリーフィングメールを下書き 優先受信ルールの自動生成: 重要な関係者からの連絡を優先表示するダイナミックルールを作成 不在時の要約: 不在中に受信したメールを優先度別に整理し、緊急対応が必要なものをハイライトしてアーカイブ カレンダー管理の自律化 カレンダー機能についても、さらに踏み込んだ自律化が実装されている： 会議ダブルブッキングの自動解消: 競合を検出して自動的にリスケジュール、会議室の再手配も実行 集中作業時間のブロック確保: ワークロードパターンに基づいてフォーカスタイムを自動設定 会議の受諾・辞退・委任の推奨: 参加の必要性をAIが判断して提案 会議アジェンダの自動生成: 目的と参加者に合わせたアジェンダを事前に作成、クライアントとの面談前には潜在リスクのコンテキスト情報も提供 なお、受信トレイ管理機能はデスクトップ・Web・モバイルすべてのOutlookプラットフォームで展開されるが、高度なカレンダー委任機能は現時点でOutlook for WindowsおよびWebクライアントに限定されている。 企業セキュリティへの影響と注意点 エージェントがメール・カレンダー・ワークフローに深くアクセスするようになることで、セキュリティとデータガバナンスの課題も浮上する。特に注意すべき領域は以下の3点だ。 DLP（データ損失防止）ポリシーとの整合性: AIが自動生成・送信するメールが既存のDLPルールに準拠しているか 監査ログとアクセス制御: 誰が何をいつ実行したかの追跡が自動操作でも維持されているか 機密要件への対応: 機密度の高いメールに対してエージェントが適切に振る舞うか IT管理者はエージェントモードの展開前に、既存のコンプライアンス要件との整合性を必ず確認すること。 日本の現場への影響 日本企業では依然としてメール中心のコミュニケーションが多い。会議招待の調整、プロジェクト進捗の集約、不在時の対応——これらはすべてエージェントモードが直接支援できる領域だ。 Microsoft 365を全社導入済みの企業であれば、Frontierプログラムへの参加で早期検証が可能だ。特に「メール対応に追われて本来業務ができない」という管理職層の課題解消に直結する可能性がある。 ただし、自動送信される返信メールやカレンダー変更が社外の取引先にも及ぶ場合、事前のルール設定と社内周知が不可欠だ。いきなり全社展開ではなく、パイロットユーザーでの検証から始めることを強く推奨する。 筆者の見解 Outlookのメールトリアージやカレンダー調整といった「定型的な事務処理」こそ、Copilotが本来の力を発揮できる領域だ。エージェントモードという方向性は理にかなっており、「ボタンを押すと何かしてくれるツール」から「常時バックグラウンドで動くアシスタント」への転換は、ユーザーの認知負荷を本質的に下げうる変化だ。 個人的には、定型タスクはCopilotに任せ、高度な分析や創造的な業務には外部AIとの併用という組み合わせが現実的な解だと考えている。メール整理や会議調整でCopilotが時間を作り出し、その余白をより深い思考に充てられる環境——これが目指すべき姿ではないだろうか。 ひとつ強く期待したいのは、セキュリティガバナンスの設計だ。「承認なしに外部送信できる範囲」と「必ず人間が確認する範囲」の境界を管理者が細かく設定できる仕組みの充実が、エンタープライズ展開の成否を大きく左右する。エージェントの自律性とゼロトラスト原則を両立させる設計に、Microsoftには本気で取り組んでほしい。 出典: この記事は Microsoft Launches Copilot Agent Mode for Outlook, Inbox, and Calendar Management の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftがMicrosoft 365 CopilotおよびCopilot StudioにOpenAIの「GPT-5.5 Instant」の展開を開始した。低レイテンシに最適化されたこのモデルにより、ビジネス現場での日常的な質問への応答速度が大幅に向上するほか、画像入力やSTEM系タスクへの対応力も強化される。 GPT-5.5 Instantとは何か GPT-5.5 Instantは、低レイテンシ（応答遅延の最小化）に特化したモデルバリアントだ。「Instant」の名が示すとおり、スピードが最大の特徴であり、連続的なやり取りや即座のフィードバックが求められる業務シナリオに最適化されている。 主な強化点は以下のとおり： 画像入力への対応強化：スクリーンショットや図表、資料の画像を直接入力して内容を解析・説明させることが可能になる STEMタスクの処理能力向上：科学・技術・工学・数学に関連する論理的・計算的なタスクへの応答精度が上がる 応答速度の全体的な改善：一般的な日常業務の質問に対してより素早く回答が返ってくるようになり、業務フローの中断が減る Microsoft 365 CopilotとCopilot Studioへの統合 今回の展開は、ExcelやOutlook・TeamsなどのOfficeアプリに統合されたAI機能「Microsoft 365 Copilot」と、企業が独自のCopilotエージェントを構築・カスタマイズするプラットフォーム「Copilot Studio」の両方を対象としている。 Copilot Studioを利用している企業にとっては、自社開発したエージェントのパフォーマンスにも直接影響する話だ。カスタムエージェントにGPT-5.5 Instantが活用されることで、エンドユーザーの体験向上が期待できる。 Microsoftはこのタイミングで「AIやエージェントが実行面を担うことで、人間がより高次の判断・方向設定に集中できる」という戦略的メッセージも発信している。GPT-5.5 Instantの導入はその方向性とも一致しており、チャットボットから自律エージェントへの移行を加速させる布石でもある。 実務への影響——日本企業が今日から使えること M365 Copilotをすでに導入しているIT管理者・エンジニアへの実務ポイントをまとめる。 即日活用できること Outlookでのメール要約・返信作成の応答がより軽快になる Teams Copilotの議事録生成・会議要約のリアルタイム感が向上する可能性がある 画像入力機能を使い、スクリーンショットをそのまま貼り付けてエラー内容を解析させるワークフローが現実的になる Copilot Studio活用者へのヒント 既存のカスタムエージェントを再テストし、応答速度・精度の変化を確認する FAQ応答やフォーム入力補助など速度重視のタスクではGPT-5.5 Instantが特に効果を発揮する可能性が高い データ分析や技術ドキュメント生成などSTEM系タスクには積極的に試す価値がある テナント管理者の確認事項 展開は段階的ロールアウトのため、Microsoft 365管理センターで自テナントへの展開状況を確認することを推奨する。 筆者の見解 GPT-5.5 Instantの採用は、Copilotの弱点として長年指摘されてきた「応答のもたつき感」に正面から向き合う動きとして評価できる。モデルの性能向上という基礎体力を着実に積み上げているのは間違いない。 ただし率直に言えば、モデルが良くなるだけではCopilot全体の体験が改善されたとは直結しない。UIの完成度、コンテキスト理解の深さ、エンタープライズ用途における細かい制御の難しさ——これらは依然として課題として残っている。MicrosoftにはM365という圧倒的なユーザーベースとOffice統合という強みがある。そのポテンシャルを考えれば、もっと力を発揮できるはずだ、という気持ちがある。 実務観点からは、Copilotだけに閉じない設計を引き続き推奨したい。TeamsやOutlookとの統合・M365データへのネイティブアクセスはCopilotの真骨頂だ。その強みを最大限活用しつつ、高度な分析や創造的タスクにはAzure AI Foundry経由で補完するハイブリッド構成が、現時点での現実解である。GPT-5.5 Instantの展開が、Copilot全体の信頼回復へ向けた足がかりになることを期待している。 出典: この記事は GPT-5.5 Instant now rolling out in Microsoft 365 Copilot and Copilot Studio の内容をもとに、筆者の見解を加えて独自に執筆したものです。