MENU

OutlookメールをWebフォームにドラッグ＆ドロップして内容を取得する方法と実装パターン徹底解説

Outlook

Outlook デスクトップ アプリからメールをそのまま Web フォームにドラッグ＆ドロップして、「差出人」「件名」「本文」を自動で取得したい――業務システムや問い合わせ管理画面で、こうしたニーズは非常に多くなっています。しかし、単に JavaScript で e.dataTransfer.files を拾うだけでは、思ったように Outlook メールの中身は取れません。本記事では、.msg ファイルの扱い方から、サーバー・クライアント・Microsoft Graph API を使った複数の実装パターンまで、実務で選びやすい形で詳しく整理します。

ITtripTOOLS
その「面倒」、無料で解決。 ITtripがつくる、6つの道具。 無料ツール一覧へ すべて無料・追加課金なし
先頭0を守るCSV編集こわさないCSV PDFに直接書き込みかけるPDF 写真＋説明をPDFに写レポ スマホ⇄PCで共有コピペ便 · 文章・写真 みんなの日程を調整日程Fit 匿名質問・投票を集めるKOEQ
目次

Outlook メールをドラッグ＆ドロップしたときブラウザで何が起きているか

まずは前提となる動きを正しく理解しておきましょう。Outlook デスクトップ アプリからメールをブラウザ上のドラッグ＆ドロップ領域に放り込んだとき、ブラウザは「Outlook のメールオブジェクト」を受け取るわけではありません。

  • ブラウザが受け取るのは、あくまで .msg ファイル という単なるファイルです。
  • JavaScript の drop イベント内で参照できるのは、e.dataTransfer.files に入った File オブジェクトの配列です。
  • .msg の中に「差出人」「宛先」「件名」「本文」「添付ファイル」などが詰め込まれていますが、その構造は Outlook 独自形式であり、JavaScript 標準 API だけでは解析できません。

つまり、ドラッグ＆ドロップしただけでは 「見えているのは .msg という箱だけ」であり、中身は自力で開梱しないといけない 状態です。ここを勘違いして、「JavaScript から直接 mail.Sender のようなプロパティにアクセスできるはず」と考えてしまうと、いつまでも実装が進みません。

HTML5 ドラッグ＆ドロップで取得できる情報

ブラウザで Outlook メールをドロップしたときの基本コード例を確認しておきます。

<div id="dropZone">Outlook メールをここにドロップ</div>

<script>
  const dropZone = document.getElementById("dropZone");

  dropZone.addEventListener("dragover", (e) => {
    e.preventDefault();
    e.dataTransfer.dropEffect = "copy";
  });

  dropZone.addEventListener("drop", (e) => {
    e.preventDefault();
    const files = e.dataTransfer.files;

    for (const file of files) {
      console.log(file.name);        // 例: "問い合わせについて.msg"
      console.log(file.type);        // 多くの場合 ""（空文字）
      console.log(file.size);        // バイト数
    }
  });
</script>

この段階で分かるのは、「ファイル名」「サイズ」などのメタ情報だけです。つまり、差出人や件名を取得するには .msg をパースする処理が必須になります。

.msg の中身はどうやって取り出す？ 大きく 4 つのアプローチ

.msg の内容を解析する方法は、大きく以下の 4 パターンに整理できます。

アプローチ処理場所主な技術特徴
Outlook Interop を使うサーバーMicrosoft.Office.Interop.Outlook（C#）Outlook がインストールされた Windows サーバー限定。Microsoft 非推奨。
JavaScript ライブラリで解析ブラウザmsg-reader などOutlook 不要。クライアントで完結。ファイルサイズに注意。
サーバー側ライブラリで解析サーバーNode.js / Python / Ruby などサーバーの言語に合わせて柔軟に選択可能。
API 経由でメール取得クラウド / サーバーMicrosoft Graph API, EWS など.msg を扱わず JSON でメール情報を取得。長期的に最も推奨。

以下では、各アプローチを詳しく見ていきます。

Outlook Interop を使ったサーバー側 .msg 解析（クラシック ASP.NET）

まず、既に WinForms などで Microsoft.Office.Interop.Outlook を使った経験がある場合、同じ発想でサーバー側 ASP.NET から .msg を解析したくなるかもしれません。構造としては次のようになります。

  1. ブラウザで Outlook メールをドラッグ＆ドロップ。
  2. JavaScript で File を取得し、フォームや AJAX でサーバーにアップロード。
  3. サーバーで一時フォルダーに .msg を保存。
  4. Outlook Interop を使って MailItem として読み込み、差出人・件名・本文などを取得。

サーバー側の典型的な C# コード例（WebForms）

ファイルアップロードを行うシンプルな ASP.NET WebForms の例です。
ASPX:

<asp:FileUpload ID="fileUpload" runat="server" AllowMultiple="true" />
<asp:Button ID="btnUpload" runat="server" Text="アップロード" OnClick="btnUpload_Click" />

コードビハインド（C#）:

using System;
using System.IO;
using Outlook = Microsoft.Office.Interop.Outlook;

protected void btnUpload_Click(object sender, EventArgs e)
{
    if (!fileUpload.HasFile)
    {
        // エラーメッセージ表示など
        return;
    }

    foreach (var postedFile in fileUpload.PostedFiles)
    {
        var file = (System.Web.HttpPostedFile)postedFile;
        var ext = Path.GetExtension(file.FileName).ToLower();

        if (ext != ".msg")
        {
            // .msg 以外はスキップ or 別処理
            continue;
        }

        string tempPath = Path.Combine(
            Path.GetTempPath(),
            Guid.NewGuid().ToString("N") + ".msg"
        );

        file.SaveAs(tempPath);

        // Outlook Interop で .msg を開く
        var app = new Outlook.Application();
        Outlook.MailItem mail = app.Session.OpenSharedItem(tempPath) as Outlook.MailItem;

        if (mail != null)
        {
            string senderEmail = mail.SenderEmailAddress;
            string senderName  = mail.SenderName;
            string subject     = mail.Subject;
            string body        = mail.Body;  // もしくは BodyFormat に応じて HTMLBody

            // ここで DB 登録や画面表示用オブジェクトに詰める
        }
    }
}

このように、技術的には WinForms と同じく OpenSharedItem で .msg を開くことができます。

Outlook Interop 方式の注意点

ただし、このアプローチには重要な注意点があります。

  • サーバーに Outlook クライアントをインストールする必要がある
  • ASP.NET アプリケーション プールを STA（Single Threaded Apartment）にする必要がある
  • アプリケーション プールの実行ユーザーに Office/Outlook を実行する権限が必要
  • Outlook の自動起動・プロセスハンドリングを誤ると、サーバーが不安定になりやすい
  • Microsoft はサーバーサイドで Office COM (Interop) を使うことを公式に非推奨としている

つまり、「動かすこと」はできるが、「サーバー環境としてはあまりおすすめできない」という位置付けです。小規模・閉じた環境で、サーバーは必ず Windows + Outlook という前提が崩れない案件であれば、短期的な解決策としては有効ですが、長期運用を考えると別の方法を検討した方が安全です。

この方式が向いているケース

  • 既に Windows サーバー上で Outlook を常駐させている、またはそれに近い運用がある
  • オンプレミス環境で、クラウドや外部 API を使えない事情がある
  • 既存の WinForms / WPF の処理資産をできるだけ流用したい

クライアント側で .msg を解析する：JavaScript ライブラリ（msg-reader）

サーバーに Outlook を置きたくない、または OS を問わずホスティングしたい場合は、ブラウザ側で .msg を解析してしまう方法が有力です。その代表格が純粋な JavaScript で .msg を読めるライブラリ msg-reader です。

msg-reader を使った基本コード

npm などでライブラリを取り込み、ドラッグ＆ドロップした .msg ファイルから差出人・件名・本文を取り出す例です。

// ES Modules での読み込み例
import MsgReader from "msgreader";

const dropZone = document.getElementById("dropZone");

dropZone.addEventListener("dragover", (e) => {
  e.preventDefault();
});

dropZone.addEventListener("drop", async (e) => {
  e.preventDefault();

  for (const file of e.dataTransfer.files) {
    if (!file.name.toLowerCase().endsWith(".msg")) continue;

    const arrayBuffer = await file.arrayBuffer();
    const reader = new MsgReader(arrayBuffer);
    const msgData = reader.getFileData();

    console.log(msgData.senderName);
    console.log(msgData.subject);
    console.log(msgData.body);

    // Web フォームの入力欄に自動セットする例
    document.getElementById("txtSubject").value = msgData.subject || "";
    document.getElementById("txtBody").value    = msgData.body || "";
  }
});

この方法であれば、Outlook も Office もインストール不要で、ユーザーは単にブラウザにドラッグ＆ドロップするだけで済みます。

クライアント解析方式のメリット

  • サーバー OS に依存しない（Linux やクラウド PaaS でも問題なし）
  • Outlook のライセンスや COM の設定を気にしなくてよい
  • ファイル内容の解析はブラウザメモリ内で完結し、サーバー側は結果だけを受け取る構成も取れる
  • SPA (React / Vue / Angular) と相性が良い

クライアント解析方式のデメリット・注意点

  • .msg ファイルが非常に大きい場合（添付が多いなど）、ブラウザメモリを圧迫しパフォーマンスが落ちる
  • ブラウザによってはドラッグ＆ドロップの挙動が微妙に異なるため、テストが必要
  • セキュリティ要件によっては、解析前に必ずサーバーでウイルスチェックを行いたいケースがあり、その場合はアップロードも併用する必要がある
  • ライブラリのメンテナンス状況をウォッチしておく必要がある

とはいえ、多くの Web 業務システムにおいて、最も導入しやすく、将来のクラウド移行にも対応しやすいのがこのアプローチです。

サーバー側ライブラリで .msg を解析する（Node.js / Python / Ruby 等）

バックエンド側で処理を集約したい場合は、利用している言語ごとに .msg パーサーを利用する方法が現実的です。代表的なライブラリを整理すると、次のようになります。

言語代表的ライブラリ主な機能備考
Node.jsmsgreader, outlook-msg-parser など件名・本文・差出人・添付ファイルの抽出JavaScript 資産と共通化しやすい
Pythonextract-msg, msg_parser など詳細なプロパティや添付ファイルの解析バッチ処理や ETL でも活用しやすい
Rubyruby-msg.msg の基本情報・添付の取り出しRails ベースの社内システムと相性良

Node.js バックエンドでの例

サーバー側が Node.js の場合、ファイルをアップロードしてから解析する Express ベースの例です。

// 例: Express + msgreader
import express from "express";
import multer from "multer";
import MsgReader from "msgreader";

const upload = multer({ dest: "uploads/" });
const app = express();

app.post("/upload-msg", upload.single("file"), async (req, res) => {
  const fs = await import("fs/promises");
  const filePath = req.file.path;
  const buffer = await fs.readFile(filePath);
  const reader = new MsgReader(buffer);
  const msgData = reader.getFileData();

  // 必要な情報だけ返す
  res.json({
    sender: msgData.senderName,
    subject: msgData.subject,
    body: msgData.body,
  });
});

app.listen(3000);

フロント側では、ドラッグ＆ドロップしたファイルをそのまま FormData で /upload-msg に送信するだけで、サーバーから JSON で解析結果を受け取れます。

Python バックエンドでの例

Python では extract_msg ライブラリを使うケースが多いです。Flask と組み合わせた例を示します。

# app.py
from flask import Flask, request, jsonify
import tempfile
import os
import extract_msg

app = Flask(__name__)

@app.route("/upload-msg", methods=["POST"])
def upload_msg():
    file = request.files["file"]
    _, temp_path = tempfile.mkstemp(suffix=".msg")
    file.save(temp_path)

    msg = extract_msg.Message(temp_path)
    sender = msg.sender
    subject = msg.subject
    body = msg.body

    os.remove(temp_path)

    return jsonify({
        "sender": sender,
        "subject": subject,
        "body": body
    })

このように、サーバー側の好みの言語に合わせてライブラリを選べるのがこのアプローチの強みです。

そもそも .msg を扱わない：Microsoft Graph API / EWS を使う

ここまでの話は「ドラッグ＆ドロップされた .msg をどう解析するか」にフォーカスしてきました。しかし、長期的な保守性やセキュリティ、モバイル対応まで視野に入れると、そもそも .msg を扱わずに API からメール情報を直接取得するという発想転換も非常に重要です。

Microsoft Graph API の特徴

  • Microsoft 365 のメール・予定表・ユーザー情報などを REST API で取得できる
  • 認証は OAuth2 / OpenID Connect ベースで、Azure AD（Entra ID）と連携
  • /me/messages エンドポイントでサインインしているユーザーのメールを JSON で取得
  • .msg ファイルを解析する必要がなく、「件名」「本文」「差出人」「添付ファイル」などが最初から構造化された形で手に入る

Graph API でメールを取得する C# のイメージコード

認証部分は省略し、アクセストークン取得済みとします。

// Microsoft.Graph SDK を利用する例
var client = new GraphServiceClient(new DelegateAuthenticationProvider(
    (requestMessage) =>
    {
        requestMessage
            .Headers
            .Authorization = new System.Net.Http.Headers.AuthenticationHeaderValue("Bearer", accessToken);
        return Task.CompletedTask;
    }));

var message = await client.Me.Messages["メールID"].Request().GetAsync();

var senderEmail = message.From.EmailAddress.Address;
var senderName  = message.From.EmailAddress.Name;
var subject     = message.Subject;
var body        = message.Body.Content; // HTML or Text

このように、Graph API であれば .msg の構造を気にせず、最初から JSON として扱えるため、実装も保守も非常にシンプルになります。

ドラッグ＆ドロップとの組み合わせはどうする？

「ドラッグ＆ドロップしたメールをきっかけに、そのメールの内容を Graph API から取得したい」というケースでは、次のような UI パターンが考えられます。

  • Web アプリ側でユーザーのメール一覧（Graph API）を表示し、ユーザーに対象メールを選択してもらう
  • Outlook アドイン（Office アドイン）として Web ページを埋め込み、その中から選択中メールの ID を直接取得する
  • ドラッグ＆ドロップでは .msg ファイルを受け取りつつ、添付ファイルとしてだけ利用し、本文などは Graph API 側から取得する

純粋なブラウザだけで「ドラッグされた .msg ファイルから Microsoft 365 内のオリジナル メール ID を特定する」ことは基本的にできません。そのため、「ドラッグ＆ドロップで .msg を扱う必要が本当にあるのか？」を一歩引いて見直し、UI から見直して Graph API を中心に設計することが、エンタープライズでは特に重要です。

オンプレ Exchange の場合：EWS

Microsoft 365 ではなくオンプレミスの Exchange Server を使っている場合は、Graph API の代わりに Exchange Web Services (EWS) を使う選択肢があります。考え方は Graph API と同様で、メールをサーバー側で直接取得し、JSON 相当のオブジェクトとして扱う構成です。

シナリオ別のおすすめアプローチ比較

ここまでの内容を、代表的なシナリオ別に整理します。

シナリオ推奨アプローチ理由 / 留意点
Windows サーバー & Outlook が既に稼働している小規模環境Outlook Interop + .msg アップロード既存の WinForms ノウハウを流用しやすく、短期で実装可能。ただし COM 障害時の復旧が難しく、サーバー OS のアップデートにも注意が必要。
クライアント PC のみで完結させたい / インストール制限ありmsg-reader などフロントエンド JavaScriptOutlook や .NET ランタイムが不要で、ブラウザさえあれば動く。SPA との相性が良い反面、大きな .msg ファイルではブラウザメモリの消費に注意。
Linux サーバーやクラウド PaaS で運用したいNode.js / Python などサーバーライブラリで解析ホスティング環境を選ばず、コンテナ化もしやすい。API サーバーとしてアウトプットだけをフロントに返す構成と相性が良い。
エンタープライズ / 将来の保守や拡張性を重視Microsoft Graph API（または EWS）.msg に依存せず、メール情報を常に API 経由で取得するため、仕様変更に強い。セキュリティ・監査・認可制御の観点でも有利。

ドラッグ＆ドロップ UI と ASP.NET バックエンドの組み合わせ例

次に、実際の構成イメージを具体的に見ていきます。ここではクラシック ASP.NET（WebForms / MVC）と、フロントエンド JavaScript の組み合わせ例を示します。

フロントエンド：ドラッグ＆ドロップ + 非同期アップロード

まずは .msg ファイルをサーバーに渡すための基本的な JavaScript コード例です。

<div id="dropZone" style="border:2px dashed #999;padding:40px;text-align:center;">
  Outlook メール（.msg）をここにドラッグ＆ドロップ
</div>

<textarea id="subject" placeholder="件名" style="width:100%;margin-top:8px;"></textarea>
<textarea id="body" placeholder="本文" style="width:100%;height:200px;margin-top:8px;"></textarea>

<script>
  const dropZone = document.getElementById("dropZone");

  dropZone.addEventListener("dragover", (e) => {
    e.preventDefault();
    dropZone.style.backgroundColor = "#f0f8ff";
  });

  dropZone.addEventListener("dragleave", (e) => {
    e.preventDefault();
    dropZone.style.backgroundColor = "";
  });

  dropZone.addEventListener("drop", async (e) => {
    e.preventDefault();
    dropZone.style.backgroundColor = "";

    const files = e.dataTransfer.files;
    if (!files || files.length === 0) return;

    const formData = new FormData();
    formData.append("file", files[0]);

    const response = await fetch("/api/parse-msg", {
      method: "POST",
      body: formData
    });

    if (!response.ok) {
      alert("メールの解析に失敗しました");
      return;
    }

    const data = await response.json();
    document.getElementById("subject").value = data.subject || "";
    document.getElementById("body").value    = data.body || "";
  });
</script>

ここでは、/api/parse-msg というエンドポイントに FormData で .msg ファイルを送っています。サーバー側は、先ほど紹介した Interop 方式・Node.js 方式・Python 方式など、任意の解析方法を裏側で使えます。

バックエンド：ASP.NET MVC でのエンドポイント例（C#）

public class MsgController : Controller
{
    [HttpPost]
    [Route("api/parse-msg")]
    public ActionResult ParseMsg(HttpPostedFileBase file)
    {
        if (file == null || file.ContentLength == 0)
        {
            return new HttpStatusCodeResult(400, "no file");
        }

        var ext = Path.GetExtension(file.FileName).ToLower();
        if (ext != ".msg")
        {
            return new HttpStatusCodeResult(400, "invalid extension");
        }

        string tempPath = Path.Combine(Path.GetTempPath(), Guid.NewGuid().ToString("N") + ".msg");
        file.SaveAs(tempPath);

        // ここで .msg を解析する（Interop / 独自ライブラリなど）
        var result = ParseMsgFile(tempPath);

        System.IO.File.Delete(tempPath);

        return Json(result);
    }

    private object ParseMsgFile(string path)
    {
        // 例として Interop を使う
        var app = new Outlook.Application();
        Outlook.MailItem mail = app.Session.OpenSharedItem(path) as Outlook.MailItem;

        return new
        {
            sender  = mail.SenderName,
            subject = mail.Subject,
            body    = mail.Body
        };
    }
}

このように、フロント側は「ドラッグ＆ドロップして JSON をもらうだけ」、バックエンドは「.msg をどう解析するか」を隠蔽する、という役割分担が綺麗です。

実装前に押さえておきたいセキュリティ・運用のポイント

Outlook メールを扱うということは、ほぼ確実に機密情報・個人情報を扱うことになります。そのため、実装前に次のようなポイントを必ず確認しておきましょう。

ファイルサイズとアップロード制限

  • .msg は添付ファイルを含むため、数 MB〜数十 MB になることがあります。
  • サーバー側のアップロード制限（IIS / Kestrel / Nginx / アプリケーション設定）を適切に設定する必要があります。
  • クライアント解析方式でも、大きなファイルに対しては「解析に時間がかかる」「ブラウザタブが固まる」などの UX 上のリスクがあるため、サイズの上限チェックを入れておくと安心です。

ウイルスチェックと添付ファイルの扱い

  • .msg 内には任意の添付ファイルが含まれるため、アンチウイルス製品やサンドボックスとの連携を検討する必要があります。
  • クライアント解析方式では、添付ファイルをサーバーへ送る前にユーザーへ明示的な確認を出すなど、情報漏洩リスクを軽減する工夫が重要です。
  • サーバー側解析方式の場合、添付ファイルを自動的に外部システムへ転送する前に、必ずスキャン処理を挟む運用が望まれます。

ログ出力とマスキング

  • トラブルシュートのために、メール本文や件名をログに出したくなりますが、個人情報保護の観点から内容は極力マスキングするか、ログ対象から外す方が安全です。
  • 最低限、ファイル名・サイズ・解析結果のハッシュ値など、特定の個人に紐づかない範囲での記録を検討しましょう。

よくあるつまずきポイントと対処法

JavaScript で e.dataTransfer.files が空になる

  • ドラッグ＆ドロップのイベントが drop ではなく dragover にだけハンドラを書いている
  • イベント内で e.preventDefault() を呼んでいないため、ブラウザのデフォルト動作（ファイルを開く）が優先されてしまう
  • ドロップ対象の要素が iframe 内など特殊なコンテナにあり、ブラウザの制限を受けている

といったケースが多く見られます。最低限、dragover と drop の両方で e.preventDefault() を呼び出しているかを確認しましょう。

.msg 以外の形式がドロップされる

ユーザーが Outlook ではなく、ファイルシステム上の .eml などをドロップする場合もあります。そのため、サーバー側では拡張子をチェックし、.msg 以外が来た場合のメッセージを丁寧に出しておくとユーザビリティが向上します。

Outlook Interop で動く環境と動かない環境がある

  • 開発環境では Outlook が入っていて動くが、本番サーバーには Outlook がない
  • アプリケーション プールのアカウントが変更されたことで、Outlook 起動に失敗する
  • Windows Update 後に COM の挙動が変わり、突然エラーが発生する

など、「開発機では動くのに本番では動かない」というトラブルの根源になりがちです。長期運用を前提とするならば、Interop ではなくライブラリ or Graph API への移行を強く検討する価値があります。

実務でのおすすめ構成パターン

最後に、実務でよく出てくる要件に合わせた構成例をまとめます。

パターン 1：短期でさっと作りたい社内ツール

  • 前提: サーバーは Windows、既に Outlook をサーバーで利用中
  • 構成: ASP.NET + Outlook Interop
  • ポイント:
    • 既存の WinForms コードを流用しやすい
    • 将来、別方式に移行することを見据え、.msg 解析部分をクラスやサービス層に切り出しておく

パターン 2：クラウド前提の新規開発（Linux / PaaS 含む）

  • 前提: コンテナ化やクラウド PaaS を想定、サーバー OS に縛られたくない
  • 構成:
    • フロント: SPA（React / Vue 等）+ ドラッグ＆ドロップ
    • バックエンド: Node.js or Python で .msg 解析 API
  • ポイント:
    • バックエンドは stateless な API として構築し、スケールアウトしやすくする
    • 添付ファイル解析が重い場合は、キュー（メッセージング）を使って非同期処理に逃がす

パターン 3：Microsoft 365 をフル活用するエンタープライズ

  • 前提: 全社的に Microsoft 365 を利用。セキュリティポリシーが厳格。
  • 構成:
    • フロント: Web アプリ + Outlook アドイン or Microsoft 365 アプリ統合
    • バックエンド: Microsoft Graph API でメール情報を取得
  • ポイント:
    • 「ドラッグ＆ドロップ」ではなく、「対象メールを UI で選択する」UX へ設計をシフトする
    • メッセージ ID をキーに、Graph API から常に最新のメール情報を取得
    • 将来の API 変更やセキュリティ要件の強化にも対応しやすい

まとめ：ドラッグ＆ドロップだけではメール詳細は取れない、どう設計するかが勝負

  • Outlook デスクトップからブラウザにドラッグ＆ドロップした時点で、ブラウザが受け取っているのは .msg ファイル だけです。
  • 差出人・件名・本文などを取得するには、必ず .msg を解析する仕組みが必要です。
  • 解析方法は、
    • サーバーで Outlook Interop を使う
    • JavaScript ライブラリ（msg-reader など）でクライアント解析する
    • Node.js / Python などサーバー用ライブラリで解析する
    • そもそも .msg を使わず Microsoft Graph API / EWS から取得する
    の 4 パターンに整理できます。
  • どれを選ぶかは、環境制約（Windows / Linux）・クラウド利用方針・セキュリティ要件・保守ポリシーで決めるのがポイントです。
  • 特に中長期の運用を考えると、Microsoft Graph API を軸に設計し、ドラッグ＆ドロップに過度に依存しない UI を検討することが、結果的にシステム全体の寿命を伸ばします。

「とりあえずドラッグ＆ドロップで .msg を受け取る」だけで終わらせず、その先で どのように解析し」「どの程度まで自動入力するか」「どこから先はユーザーに確認させるか」を設計しておくと、実際の現場運用で使いやすい Outlook 連携フォームに仕上がります。

Outlook
Outlook JavaScript ASP.NET ドラッグ＆ドロップ Microsoft Graph msgファイル

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次