Outlook を Markdown にオンラインで無料で変換

オンラインで Outlook ファイルを Markdown に無料で変換します。ファイルをアップロードすると、クリーンで LLM 対応の出力が即座に得られます。サインアップなし、ファイルあたり 50 MB、何も保存されません。

MSGをMarkdownに変換する:Outlookのスレッドをモデルが読める形にする

契約更新をめぐる40通のスレッドには、意思決定の全過程が入っています。誰が何を提案し、誰が押し返し、条件が 実際にいつ変わったのか。同時に、ほとんど読めない代物でもあります。返信のたびにそれまでの全文のコピーが 積み重なり、しかも3種類のメールクライアントがそれぞれ流儀の違う引用記号で包んでいるからです。それを チャット欄に貼り付ければ、同じ段落が11回登場する灰色の壁ができあがります。

MSGをMarkdownに変換するとは、その混沌に形を与えることです。ヘッダーは冒頭のラベル付き ブロックになり、差出人・宛先・CC・件名・送信日時は、モデルが文脈から推測するものではなく、明示された事実に なります。本文は段落とリストを保ちます。引用された返信は、地の文に溶けて消える代わりに、入れ子のまま 目に見える形で残ります。結果として「誰が、いつ、何を言ったか」に答えられる文書になります。上の変換ツールに .msgファイルをドロップしてください。無料、登録不要、上限50MBです。

.msgファイルの正体

.msgとの出会いは、たいてい偶然です。誰かがOutlookからメールをデスクトップにドラッグして、 できたファイルを送りつけてくる。あるいは「ファイル」→「名前を付けて保存」で「Outlookメッセージ形式」を 選ぶ。いずれにせよ、1通のメールを収めた1つのファイルが手元に残ります。

中身はテキストではありません。.msgは複合バイナリファイルです。Microsoftが昔の .doc.xlsで使っていたのと同じOLE構造化ストレージ——1つのファイルの内側に ディレクトリとストリームを持つ、ミニチュアのファイルシステムです。メールの各要素はMAPIプロパティタグに ちなんだ名前のストリームに分かれて格納されます。件名が1つ、本文が別の1つ、受信者はそれぞれ番号付きの ストレージに、添付ファイルもまた別に。テキストエディタで開くと、バイナリのノイズの海に読める単語が ぽつぽつ浮かんでいる画面になります。

オープンな対応物が.emlです。こちらは単なるRFC 5322のメッセージ——ヘッダー、空行、MIME本文——で、 本当にメモ帳で読めます。Thunderbird、Apple Mail、大半のWebメールのエクスポートは.emlを出し、 Outlookは.msgを出します。この違いこそ、多くの人がOutlookなしで.msgファイルを開く 方法を検索するはめになる理由です。ファイルは壊れていません。それをネイティブに扱う唯一のアプリケーションが 手元にないだけです。変換は読むための最短ルートで、おまけに検索も貼り付けもできる形が手に入ります。

変換で表に出てくるもの

渡ってくるのは3つの層です。プロンプトを書き始める前に、どれがどれかを知っておく価値があります。

  • ヘッダー。差出人、宛先、CC、件名、送信日時が、地の文に埋もれる代わりにラベル付きの ブロックとして描画されます。ここはMarkdownがフラットなテキストより目に見えて優れる部分です。 **From:** Priya Ramanを読んだモデルは、それが誰かの書いた文ではなくメタデータだと 分かります。
  • 本文。メッセージそのものです。送信者がHTMLで書いていれば——ビジネスメールの大半が そうです——見出し、太字、箇条書き、ハイパーリンクがMarkdownの対応物に写し取られます。プレーンテキストで 書かれていれば、打たれたままの段落が出てきます。よりクリーンですが、より平坦です。
  • 引用の連鎖。「〇月〇日、Xは書きました:」の行から下のすべてです。インデントされ、 区別のつく形で残ります。交渉ごとでは、いちばん上のメッセージより連鎖のほうが重要なことが多いからです。

ファイルは変換して返却され、保存はされません。メールは個人的な内容や商業上の機密を含むことが多いので、 業務メールをアップロードする前に、所属組織の文書取り扱いルールを適用してください。

返信チェーンの重複問題

これが全員を引っかけるクセです。やみくもに回避するより、仕組みを理解しておく価値があります。

メールの返信は累積します。スレッドの12通目は、その内側に1通目から11通目までを含んでいます。つまり同じ会話から 複数のメッセージをエクスポートしてすべて変換すると、変換しているのは12通ではありません。各メッセージが先祖を 引きずってくるため、およそ78通ぶんのコピーです。長いスレッドの最初のメッセージは、出力の中に十数回現れる ことになります。

そこに署名ブロックが加わります。メッセージごとに送信者の名前、肩書き、電話番号、オフィスの住所が繰り返される。 さらに企業の法的免責事項——「本メールおよび添付ファイルは機密情報を含み……」の段落——を、多くの組織は返信を 含む全送信メールに自動で付加します。長いスレッドでは、この定型文が本来の内容を本当に上回ることがあります。

実務的な対処は2つです。第一に、スレッドの全履歴が欲しいだけなら、いちばん新しい1通だけを変換してください。 そこにすべてが入っています。フォルダごと変換して得られるのは、ほぼ重複だけです。第二に、どこかに貼り付ける前に 出力の下のトークンカウンターを確認してください。画面では数ページに見えるスレッドも、繰り返しを数え上げると 驚くほど高くつきます。数字を先に見るほうが、切り詰めエラーで知るよりましです。

構造が効いてくる場面

発言の帰属と順序が重要なとき——メールではほとんどの場合がそうです——Markdownが正解になります。

  • 意思決定の経緯の再構築。「支払期限60日にいつ合意して、誰が承認した?」——日付入り ヘッダーを持つ構造化されたスレッドからなら、モデルは答えられます。平坦化された散文からでは言葉を濁すか、 もっと悪いことに、自信満々で発言を別人に帰属させます。
  • 交渉の要約。立場は時間とともに動きます。引用レベルが読める形で残っていれば、9通目の 第3段落が4通目の引用であって新しい表明ではないことを、モデルは見分けられます。
  • アクションアイテムの抽出。箇条書きは箇条書きのまま生き残るので、6通目に打ち込まれた 「次のステップ」のブロックは、切れ目のない1文ではなくリストとして出てきます。
  • 引き継ぎ文書。スレッドを変換してプロジェクトのメモの隣にMarkdownで置いておけば、 半年後に引き継ぐ人は結論だけでなく、そこに至った理由を手にします。
  • レビュー用の往復文書の準備。法務、人事、コンプライアンスの担当者は、送信者、宛先一覧、 タイムスタンプがひと目で見えることを求めます。ラベル付きヘッダーブロックなら、メールクライアントを 開かずにそれを渡せます。

どれにも当てはまらないなら——数千通を検索用にインデックスする、あるいは埋め込みに回すなら——マークアップは 不要なオーバーヘッドで、 MSGをプレーンテキストに変換のほうが 適切です。ページ上部の形式切り替えは両者を行き来し、選択済みのファイルも引き継ぐので、比較のコストは 再アップロードではなくクリック1回です。

添付ファイルと、スレッドの一括処理

.msgは内部に添付ファイルを抱えられます。複合ファイル形式はそのためにあるようなものです。ただし 変換ツールから出てくるのはメッセージの内容——ヘッダー、本文、引用の連鎖——です。添付された契約書のPDFや 予算のスプレッドシートは個別には抽出されないので、その中身も必要なら、メールから保存して単体のファイルとして 変換してください。文書なら PDFをMarkdownに変換、DOCXなら WordをMarkdownに変換、 表構造を実際に保って変換したいスプレッドシートなら ExcelをMarkdownに変換で、 2分あれば済む作業です。

インライン画像も関連する落とし穴です。メール本文に貼り込まれたスクリーンショットは画像であり、ここには OCRがありません。エラー画面のスクリーンショットこそが本題だったメッセージは、ほとんど空に変換されます。 壊れているわけではなく、抽出すべきテキストが最初から存在しなかっただけです。

2〜3通を超えるなら、まとめてしまいましょう。.msgファイルを選択して1つのアーカイブに圧縮し、 ZIPをMarkdownに変換に かけてください。中の対応ファイルすべてが1回のアップロードで変換されます。Outlookのフォルダをまるごと ディスクに書き出して、往復の記録を1つの読める文書にしたいときの自然な選択です。

よくある質問

Outlookの.msgファイルをMarkdownに変換するには?

上にメッセージをアップロードすると、Markdownになって返ってきます。ヘッダーはラベル付きブロックに、本文はその下に、対応づけられる範囲で書式を保ったまま。無料、1ファイル50MB、アカウント不要、そしてファイルを読むためにOutlookをインストールする必要もありません。

メールをプレーンテキストではなくMarkdownにする理由は?

メールには部位があり、Markdownはそれを分けたまま保つからです。送信者、宛先、件名、日付は、最初の段落に流れ込む代わりに、本文の上のはっきり区切られたブロックに収まります。引用された返信の連鎖は、引用と分かる形のまま残ります。メッセージをチケットや文書に貼り付けるなら、この分離こそが価値のすべてです。それが要らなければプレーンテキストのほうがシンプルです。

引用された返信チェーンは読める形で残りますか?

たいていは残ります。長いスレッドは入れ子のblockquoteレベルとして変換されるので、どの返信がどの返信の内側にあったかが分かります。限界は、返信チェーンの整形が「それを書いたクライアント」任せで標準が存在しないことです。Outlook、Gmail、スマートフォンのクライアントを3往復したスレッドは、構造的には正直でも見た目には雑然としたものに変換されます。

HTMLメールはプレーンテキストのメールよりきれいに変換されますか?

材料が多いぶん有利です。HTML本文には本物のマークアップ——見出し、リスト、リンク、表——があり、それらはMarkdownに直接写し取れます。プレーンテキストのメールにあるのは改行と慣習だけなので、出力は元とほぼ同じになります。最悪のケースはレイアウト用テーブルだらけのマーケティングメールで、読む価値のないものに変換されます。

メッセージをリポジトリやwikiにアーカイブする用途に使えますか?

理にかなった使い方です。Markdownは長持ちし、diffが取れ、grepでき、メールクライアントなしで読めます。.msgファイルの詰まったフォルダには言えないことばかりです。メッセージを変換して出力をコミットしておけば、10年後もスレッドを検索できます。添付ファイルは別途保存が必要です。

ツールキットの残り

MSGはFile2Txtが扱う形式の1つです。 ページを選ぶのが面倒なら、あちらが1回のアップロードで対応ファイルすべてを受け付けます。Webコンテンツなら Web2TxtがURLをMarkdownに変換します。 スレッドがオンラインの仕様書を何度も参照しているときに便利です。コード側では GitHubリポジトリをテキストに変換するか、 手元のフォルダを変換して、メールの スレッドと実装を一緒にモデルへ渡せます。こうした話の一般論は LLM向けに文書を整える方法のガイド にまとまっています。

Repo2Txtを開発・運営しているのは v12hero、 プライバシー最優先のネイティブアプリとWebアプリを作る独立系デベロッパーです。