Microsoft 365の「Create a signature request from Word」は、Word文書から直接、電子署名リクエストを作成できる機能です。2026年4月更新ポイントとして最初に押さえるべき結論は、今回のMicrosoftDocs上の差分は大きな機能追加ではなく、セキュリティとコンプライアンス制御に関する説明文の表記調整が中心だという点です。一方で、現場の管理者・ITチーム・業務ユーザーにとっては、Wordから署名依頼を出すための前提条件、SharePoint保存、グループポリシー、外部ユーザー対応を改めて確認するよいタイミングです。MicrosoftDocsの履歴では、該当ファイルに2026年4月22日付のコミットがあり、日本時間では4月23日の更新として扱えるタイミングです。(GitHub)
Microsoft 365の最新動向: Create a signature request from Wordで何が変わったか
2026年4月の更新では、「Create a signature request from Word」本文に含まれるセキュリティとコンプライアンス制御の説明行で、ダッシュ記号の表記が調整されています。差分を見る限り、Wordから電子署名を依頼する操作手順、対象チャネル、保存先、管理者設定そのものが新しく拡張されたわけではありません。(GitHub)
ただし、表記調整だから軽視してよい、という意味ではありません。該当箇所は、管理者がeSignature for Wordを特定ユーザーに対して有効化できること、SharePointサイト単位で利用範囲を制限できること、Purview監査ログにeSignatureアクティビティを記録できることを説明する重要な部分です。つまり今回の更新ポイントは、「新機能の追加」よりも、Wordから署名要求を作成する機能を安全に展開するための管理ポイントを再確認することにあります。(Microsoft Learn)
| 確認項目 | 2026年4月更新で見るべきポイント | 実務上の意味 |
|---|---|---|
| 更新の性質 | MicrosoftDocs上の表記調整が中心 | 機能仕様が大幅に変わったと誤解しない |
| 注目箇所 | セキュリティとコンプライアンス制御の説明 | 管理者設定、対象ユーザー、対象サイト、監査ログを確認する |
| 現場への影響 | 操作手順は基本的に従来の説明どおり | 既存の導入手順や社内マニュアルは、前提条件を中心に見直す |
| 優先対応 | Wordリボン表示、SharePoint保存先、外部署名者の認証を検証 | 問い合わせが増える前にパイロットで詰まりどころを潰す |
Create a signature request from Wordとは
Create a signature request from Wordは、Wordデスクトップアプリの画面から署名フィールドを配置し、受信者に電子署名を依頼できるMicrosoft 365のeSignature機能です。従来のようにWord文書を手動でPDF化し、別の署名サービスにアップロードし直す手間を減らせる点が大きな特徴です。(Microsoft Learn)
公式ドキュメントでは、Wordの［挿入］リボンからeSignature fieldsを使い、署名フィールドを文書内に配置して署名依頼を作成する流れが示されています。署名を依頼すると、受信者は元のWordファイルではなく、自動生成されたPDFコピーに署名します。署名済みPDFは、元のWordファイルと同じSharePoint上の場所に保存されます。(Microsoft Learn)
この仕組みの実務上のメリットは、単に「署名が楽になる」だけではありません。契約書、申込書、承認書、同意書のように、Wordで作成してSharePointで保管している文書を、Microsoft 365の管理境界内で署名フローに乗せやすくなります。Microsoftの説明でも、署名プロセス中に文書がMicrosoft 365の信頼境界を離れないこと、署名済みPDFで監査証跡を確認できることが強調されています。(Microsoft Learn)
利用できるユーザーと前提条件
この機能は、Microsoft 365 Beta、Current、Monthly Enterprise Channelsのユーザー向けに提供されると説明されています。利用するには、管理者がMicrosoft Wordで署名要求を許可する設定を完了している必要があります。(Microsoft Learn)
利用前提としては、サブスクリプション版のWordデスクトップアプリ、eSignatureが有効化されたSharePointサイト、.docx形式の文書、暗号化されていない文書が必要です。つまり、「Wordファイルならどこからでも署名依頼できる」という機能ではなく、SharePointに保存された対象文書を、管理者が許可した条件下で使う機能と考えるべきです。(Microsoft Learn)
| 対象 | 必要な条件 | 失敗しやすいポイント |
|---|---|---|
| Wordアプリ | サブスクリプション版のWordデスクトップ | Web版や古いクライアントを前提に案内してしまう |
| 文書形式 | .docx形式 | PDFや暗号化文書で同じ操作ができると誤解する |
| 保存場所 | eSignatureが有効なSharePointサイト | OneDriveやローカル保存の文書で試してメニューが見つからない |
| 利用者 | 対象チャネルかつ管理者設定済みのユーザー | ポリシー未適用で［eSignature fields］が表示されない |
| 管理範囲 | テナント設定、サイト設定、Officeポリシー | どれか1つだけ設定して完了したと思い込む |
管理者が確認すべき設定
Microsoft 365管理センターでeSignatureを有効にするには、［設定］>［組織の設定］>［従量課金制サービス］からeSignatureを選択し、組織内のユーザーにeSignatureを使わせる設定を行います。eSignatureは従量課金制サービスとして扱われ、利用にはAzureサブスクリプションのリンクが必要です。設定にはSharePoint管理者またはグローバル管理者の権限が必要とされています。(Microsoft Learn)
Wordで署名要求を使わせるには、eSignatureパネルの「eSignatureを使用できるアプリ」でWordデスクトップを選択し、さらにOfficeグループポリシーを適用する必要があります。公式ドキュメントでは、Cloud Policy service for Microsoft 365、Microsoft Intune、グループポリシーマネージャー、Office用ADMX/ADMLテンプレートによる展開が案内されています。ポリシーが無効または未適用の場合、Wordの［挿入］リボンにeSignatureアクションが表示されません。(Microsoft Learn)
検証用として、Windowsデバイスでは次のレジストリコマンドでWordデスクトップの［挿入］リボンにeSignature fieldsを表示する方法も示されています。ただし本番展開では、端末ごとの手作業ではなく、Intuneやクラウドポリシーで対象ユーザー・対象デバイスを管理するほうが安全です。(Microsoft Learn)
reg add HKCU\software\policies\microsoft\office\16.0\word\options /v isesignenabled /t REG_DWORD /d 1 /fサイト管理も重要です。eSignatureを利用できる場所は、すべてのサイトまたは選択したサイトに制限できます。選択したサイトを指定する場合は最大100サイトまでと説明されており、CSVでの指定も可能です。最初のeSignature要求は通常より時間がかかる場合があるため、管理者が最後のセットアップ手順としてSharePointサイトで最初の要求を作成することが推奨されています。(Microsoft Learn)
業務ユーザーがWordから署名要求を作成する手順
業務ユーザーの操作は比較的シンプルです。eSignatureが有効なSharePointサイトにあるWord文書をWordデスクトップで開き、［挿入］リボンから［eSignature fields］を選択します。その後、受信者を追加し、文書内の署名位置にフィールドを挿入して、必要に応じてメッセージを追加し、［Create request］を選択します。(Microsoft Learn)
| 手順 | 操作 | 確認ポイント |
|---|---|---|
| 文書を開く | eSignature有効サイトの文書をWordデスクトップで開く | ローカル保存ではなくSharePoint上の対象文書か |
| フィールドを追加 | ［挿入］リボンから［eSignature fields］を選ぶ | メニューがない場合はIT管理者にポリシー適用状況を確認 |
| 受信者を追加 | サイドパネルで署名者を追加 | メールアドレス、氏名、署名依頼先を送信前に再確認 |
| 署名位置を指定 | 文書内の該当箇所に署名フィールドを挿入 | 契約当事者ごとの署名欄を取り違えない |
| 依頼を作成 | メッセージを追加し［Create request］を選択 | 送信後に受信者へ署名用リンクが届く |
署名要求が送信されると、依頼者には確認メールが届き、受信者にはWord文書のPDFコピーに署名するためのリンクが送られます。署名依頼を送った後は、eSignatureパネルを閉じるか、新しい要求を開始できます。(Microsoft Learn)
何に使うと効果が大きいか
Create a signature request from Wordが特に向いているのは、Wordで作成し、SharePointで管理している定型文書です。たとえば、業務委託契約書、NDA、注文書、社内承認書、入社関連の同意書、取引先への確認書などです。WordファイルをeSignatureテンプレートとして再利用できるため、同じ種類の文書を繰り返し送る部署ほど効果が出やすくなります。(Microsoft Learn)
一方で、すべての署名業務をこの機能だけに置き換えるべきとは限りません。高度なワークフロー、複雑な承認順序、業界固有の電子署名要件、既存の契約管理システムとの連携が必要な場合は、現在利用している電子署名サービスや契約管理基盤との役割分担を検討すべきです。MicrosoftのeSignatureはSharePoint上のPDFやWord文書から署名依頼を作成でき、Adobe Acrobat SignやDocuSignとの統合も説明されていますが、どのプロバイダーを使うかは管理者が設定します。(Microsoft Learn)
セキュリティとコンプライアンスで押さえるポイント
Wordから電子署名を要求した場合、受信者は署名プロセス中に元のWord文書へアクセスしません。また、受信者のメールアドレスなどの情報はWord文書内に保存されず、署名完了後のPDFは元のWord文書と同じ場所に保存されます。これは、契約書や申請書のように保管場所とアクセス権が重要な文書で大きな意味を持ちます。(Microsoft Learn)
外部受信者に署名依頼を送る場合は、Microsoft Entra B2B統合やSharePoint/OneDriveのゲスト共有設定が関係します。外部署名者はテナント内のゲストとして扱われるため、要求の進行中にゲストが削除されると、要求文書や最終的な署名済み文書にアクセスできなくなる可能性があります。(Microsoft Learn)
さらに、秘密度ラベルや条件付きアクセスも確認が必要です。署名対象のWordまたはPDFが秘密度ラベル付きサイトにある場合、ラベル設定によって外部ユーザーへの要求送信が妨げられることがあります。また、条件付きアクセスの構成によっては、外部受信者が文書を読めても署名操作に失敗する場合があります。(Microsoft Learn)
保持とリンク期限も見落としやすいポイントです。署名要求が作成されると、サービスはSharePointの非表示ドキュメントライブラリに作業コピーを作成し、要求の作業コピーは5年間またはSharePoint/テナント管理者が設定した保持ポリシーに従って保持されます。要求が完了、キャンセル、拒否の状態になると、受信者がメール内リンクから文書を表示・ダウンロードできる期間は30日間と説明されています。(Microsoft Learn)
問い合わせが来たときの切り分け
導入後に多い問い合わせは、「WordにeSignature fieldsが出ない」「外部の署名者が開けない」「署名済みPDFが想定場所に保存されない」の3つです。これらはユーザー操作のミスだけでなく、管理センター設定、Officeポリシー、SharePoint権限、外部共有、条件付きアクセスが絡むため、ITチーム側で切り分け表を用意しておくと対応が速くなります。(Microsoft Learn)
| 症状 | 主な原因候補 | 最初に確認する場所 |
|---|---|---|
| Wordに［eSignature fields］が表示されない | Word機能が未有効、Officeポリシー未適用、対象チャネル外 | Microsoft 365管理センター、Intune、Cloud Policy、Wordの更新チャネル |
| 署名要求を作成できない | 文書が.docxではない、暗号化されている、対象SharePointサイトではない | 文書形式、保存場所、サイトのeSignature有効化 |
| 外部署名者がアクセスできない | Entra B2B、ゲスト共有、秘密度ラベル、条件付きアクセスの制約 | Entra管理センター、SharePoint共有設定、Purviewラベル |
| 署名済みPDFが保存されない | 送信者の書き込み権限変更、元フォルダー削除、権限ダウングレード | SharePoint権限、元フォルダーの状態 |
| 初回だけ処理が遅い | テナント初回のeSignature要求 | 管理者による初回リクエスト実行状況 |
| コストが不明 | 従量課金設定とトランザクション課金の確認不足 | Azureサブスクリプション、Microsoft 365管理センター |
グローバル組織での注意点
Microsoftは、eSignature for Microsoft 365がMicrosoft 365 public cloudsで世界的に利用可能になったと案内しており、Word文書やSharePoint上のPDFに対する署名要求に対応すると説明しています。ただし、同案内ではworldwide availabilityからIndonesiaとTürkiyeが除外される注記もあります。グローバル企業では、国・地域ごとの利用可否、外部共有ポリシー、データ所在地、社内の契約管理ルールを確認してから展開するのが安全です。(TECHCOMMUNITY.MICROSOFT.COM)
特に多国籍環境では、外部署名者が所属する組織のMicrosoft 365設定や認証条件が署名体験に影響する可能性があります。日本本社では問題なく動いても、海外子会社や海外取引先で条件付きアクセスやゲスト共有の制約に引っかかることがあります。パイロットでは、社内ユーザーだけでなく、実際に想定される外部署名者を含めてテストすることが重要です。(Microsoft Learn)
ITチーム向けの導入手順
いきなり全社展開するより、まずは署名業務が多く、文書管理ルールが比較的明確な部署でパイロットを行うのがおすすめです。たとえば法務、購買、人事、営業事務などです。対象部署を絞ることで、SharePointサイト、文書テンプレート、外部共有、監査ログ、ユーザー教育をまとめて検証できます。
導入の流れは次のように進めると失敗しにくくなります。
| フェーズ | やること | 成功条件 |
|---|---|---|
| 事前整理 | 署名対象文書、利用部署、外部署名者の有無を洗い出す | どの文書に使うかが明確になっている |
| 管理設定 | eSignature、Wordアプリ、Officeポリシー、対象SharePointサイトを設定 | 対象ユーザーのWordにメニューが表示される |
| 文書検証 | .docx、未暗号化、SharePoint保存、署名欄の配置を確認 | 署名要求を最後まで送れる |
| 外部検証 | ゲスト共有、Entra B2B、秘密度ラベル、条件付きアクセスを確認 | 外部署名者が開封・署名・完了できる |
| 運用設計 | 署名済みPDFの保存場所、監査、保持、問い合わせ窓口を決める | ユーザーが迷わず利用できる |
| 展開 | 対象部署を広げ、社内マニュアルを更新する | 問い合わせ内容が想定範囲に収まる |
パイロット時の判断基準は、「便利そうか」ではなく、「既存の紙・PDF・メール添付の運用をどこまで減らせるか」です。Wordから署名依頼できても、最終的に別の場所へ手動保存したり、メールで署名済みPDFを転送したりするなら、運用改善の効果は薄くなります。SharePoint上の保存先、権限、保持ポリシーまで含めて設計しましょう。
業務ユーザーに伝えるべき使い方
業務ユーザーには、細かい管理設定よりも「使える文書の条件」と「送信前チェック」を伝えることが重要です。特に、署名依頼は相手に届く業務プロセスなので、文書の内容、署名欄、受信者、保存場所の確認を習慣化する必要があります。
送信前チェックリストとしては、次の5つを案内すると実用的です。
| チェック項目 | 確認内容 |
|---|---|
| 文書の場所 | eSignatureが有効なSharePointサイトに保存されているか |
| 文書形式 | .docx形式で、暗号化されていないか |
| 署名欄 | 署名者ごとの署名フィールドが正しい位置にあるか |
| 受信者 | メールアドレス、氏名、社内外の区分が正しいか |
| 保存先 | 署名完了後のPDFがどこに保存されるか関係者が理解しているか |
この機能は、Wordで作った文書をそのまま署名フローに乗せられる点が強みです。ただし、送信後の訂正や再送は業務負荷になります。最初の社内展開では、よく使う契約書や申請書をテンプレート化し、署名フィールドを事前配置した状態で使うとミスを減らせます。公式ドキュメントでも、Word文書をeSignatureテンプレートとして再利用できることが説明されています。(Microsoft Learn)
まとめ：2026年4月更新は「機能追加」より「運用確認」が重要
Microsoft 365のCreate a signature request from Wordは、Word文書から直接電子署名要求を作成し、署名用PDFの作成、通知、署名済みPDFのSharePoint保存までをMicrosoft 365内で進めやすくする機能です。2026年4月のMicrosoftDocs更新は大きな機能追加ではなく表記調整が中心ですが、該当箇所はセキュリティ、コンプライアンス、管理者制御に関わる重要な説明です。(GitHub)
次に取るべき行動は、立場によって異なります。Microsoft 365管理者は、eSignatureの従量課金設定、Wordデスクトップの有効化、Officeグループポリシー、対象SharePointサイトを確認しましょう。ITチームは、外部署名者、秘密度ラベル、条件付きアクセス、保存先、監査ログを含めてパイロットを実施すべきです。業務ユーザーは、.docx形式、SharePoint保存、署名フィールド、受信者情報を送信前に確認する運用を徹底しましょう。
「Wordから署名依頼できるようになった」で終わらせず、誰が、どの文書を、どのサイトで、どの相手に送れるのかを明確にすることが、Microsoft 365 eSignatureを安全に活用するための最短ルートです。
コメント