Outlook を テキスト にオンラインで無料で変換

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

Outlook の MSG メールをテキストに変換する:読む、索引を張る、検索する

RE_ 請求書の件.msg というファイルが転送されてきます。ダブルクリックすると、 テキストエディタで開きますかと聞かれ、開いてみれば読める単語がぱらぱら混ざったバイナリの塊が 画面いっぱいに出てきます。手元に Outlook はありません。ただメールの中身が知りたいだけです。

Outlook の MSG をオンラインでテキストに変換するいちばん短い理由がこれです。 Outlook なしで .msg ファイルを開いて中身を読むには、これが最速です。もう一つの理由は、 検索インデックスも埋め込みモデルも分類器も、求めているのはフラットなテキストだという点です。1 通ではなく メールボックスのエクスポートを相手にするなら、出発点はここになります。無料、登録不要、1 ファイル 50 MB まで、 こちら側には何も保存しません。

MSG ファイルが開けない理由

.msg は Outlook 独自の 1 通単位の形式で、テキストではありません。複合バイナリファイル、 つまり内部にディレクトリツリーを持つコンテナで、件名、本文、受信者ひとりひとり、添付ファイルひとつひとつが MAPI プロパティ識別子でタグ付けされた別々のストリームに入っています。テキストエディタがノイズを見せるのは この構造のせいです。見えているのはメールではなく、小さなファイルシステムの生のバイト列です。

オープンな代替は RFC 5322 で定義された .eml で、こちらは本当にプレーンテキストです。 ヘッダー、空行、MIME 本文という並びで、どのエディタでも読めます。Thunderbird、Apple Mail、 たいていの Web メールのエクスポートはこれを渡してきます。Outlook が渡すのは .msg で、 受信トレイからデスクトップにドラッグしたときや、「ファイル」→「名前を付けて保存」で 「Outlook メッセージ形式」を選んだときに生まれます。ファイル自体はどこも壊れていません。 それをネイティブに読める唯一のソフトが手元にないだけで、変換してしまえばその問題は消えます。

Outlook メールをテキストに変換したほうがよい場面

これは「Markdown から書式を落としたもの」ではありません。テキストは、かなり広い種類の作業にとって 正しい出力形式です。そしてその多くでは、構造マークアップは失われる情報ではなく、むしろ邪魔になります。

  • 検索インデックス。 Elasticsearch、SQLite FTS、Postgres の tsvector、 どれもカラムに入った生のテキストを求めます。Markdown を食わせれば、サニタイズの工程が一段増え、 さらにステマーが余ったパイプやアスタリスクの扱いを決めなければならなくなります。
  • キーワード調査と証拠開示。 往復文書のフォルダを変換してから、取引先名、契約上の定義語、 そこにあってはいけない言い回しを grep で探します。オフラインで、即座に終わり、 シェルが使える人なら誰でも検証できます。
  • 埋め込み。 分割して、埋め込んで、類似度で引く。書式文字は意味を運ばないのに ベクトル内の位置は占めるので、結果を薄めます。きれいな文章の塊のほうが検索精度は上がります。
  • 分類と感情分析。 問い合わせメールをトピックで振り分ける、顧客の返信の不満度を採点する、 四半期分の往復文書をテーマごとにタグ付けする。Bag-of-words や TF-IDF の手法は、剥がさない限り ### を平気で 1 トークンとして扱います。だったら最初から作らないことです。
  • 量が出るときのトークン単価。 1 通ならマークアップのコストは語るに値しません。 4000 通なら、余分な 1 文字が 4000 倍になります。テキストが下限です。

逆に、大量処理ではなく 1 つのスレッドを読むとき、つまり誰が何にいつ同意したのかを組み立て直すときは、 MSG から Markdown のラベル付きヘッダーと目に見える引用階層のほうが、増える文字数に見合います。ページ上部の形式トグルで 両者を行き来でき、選択済みのファイルはそのまま引き継がれます。

メールボックスのエクスポートを処理する

検索用のコーパスを作るのに .msg を 1 個だけ変換する人はいません。この仕事はたいてい、 Outlook から引きずり出した数百通がフォルダに入っている、という形をしています。だからまとめ方が効きます。 1 つのアーカイブに固めて ZIP からテキスト にかければ、中の対応ファイルが数百回ではなく 1 回のアップロードで全部変換されます。

メールは個人情報や商業的に機微な内容を含みがちなので、業務メールをアップロードする前に、 往復文書の取り扱いに関する社内規程を確認してください。ファイルは変換して返すだけで、保持しません。

もう一つ織り込んでおくべきは重複で、メールコーパスが膨れる最大の原因がこれです。返信は積み上がります。 12 通目のメールの中には 1 通目から 11 通目までが引用として入っています。スレッド全体を変換すれば、 最初の 1 通は出力に十数回登場します。そこに署名ブロック、つまり氏名、肩書、電話番号、住所が全通に 繰り返され、さらに多くの企業が送信メールすべてに貼り付ける法務免責文が乗ると、 定型文が本題より重くなります。

検索や埋め込みにとって、この繰り返しは実害です。同じ一節が十数回索引され、検索スコアが歪みます。 手間に見合う対処は 2 つあります。履歴が欲しいならスレッドごとに最新の 1 通だけを残すこと、そして 最初の「差出人:」引用ヘッダー、または免責文の書き出しから後ろを切り落とす正規表現を 1 本書くことです。 どれだけ削れたかは出力の下のトークンカウンタが教えてくれます。

出力に現れる癖

  • HTML 本文はかなり平坦になります。 業務メールの大半は HTML で送られます。太字、 箇条書き、進捗報告の色付きステータス表、そのすべてが装飾のない文章になります。普通はそれで困りません。 ただしメールの意味が表にあった場合、数値は残っても、それがどの列のものだったかは残りません。
  • 引用の書き方が揃っていません。 Outlook は引用文の上に 「差出人/送信日時/宛先/件名」のブロックを書きます。Gmail は「2026年3月4日(水) 山田太郎:」の形です。 古いクライアントは > を行頭に付けます。複数の組織をまたいだスレッドには この 3 つの流儀が全部入るので、メールを分割する正規表現を書くときに効いてきます。
  • 時刻は送信側の値です。 変換したものを時系列で並べるときは、地域をまたぐ順序を 信用する前にタイムゾーンのオフセットを確認してください。
  • 添付ファイルは取り出されません。 .msg は添付を抱えていますが、 変換が返すのはメール本体です。中身が必要なら添付を別途保存して、 PDF からテキストWord からテキスト にかけてください。
  • 貼り付けられたスクリーンショットは出てきません。 本文中の画像は読み取らないので、 エラーダイアログの画像が中身のすべてだったメールは、ほとんど何も残らずに変換されます。 画像を保存して 画像からテキスト にかけてください。こちらは画像内の文字を認識します。

これで片付く仕事

  • 送られてきたメールを読む。 いちばん素朴で、いちばん多いケースです。本文が知りたい、 その形式を開けるメールソフトがない、10 秒で終わり。
  • 検索できるアーカイブを作る。 何年分ものプロジェクトの往復文書を、 grepripgrep、デスクトップ検索が届くテキストファイルのフォルダにします。 PST をマウントする必要も、メールソフトを起動する必要もありません。
  • レビューと開示の作業。 定義語で一括検索してヒット一覧を作り、チーム全員分の Outlook ライセンスを買わなくても読める形でレビュー担当に渡します。
  • 往復文書に対する RAG。 顧客とのメール履歴を埋め込んでおけば、サポートのアシスタントが 4 か月前の同僚の回答と矛盾せず、すでに約束した内容を踏まえて答えられます。
  • まとめて分類する。 四半期分の受信メールに感情分析やトピックモデルをかけて、 エスカレーションがどこに固まっているかを探します。
  • 背景をアシスタントに渡す。 返信を書かせる前に、何が合意済みかをモデルに知らせたい。 テキスト化したスレッドがいちばん安上がりな渡し方です。

よくある質問

Outlook なしで MSG ファイルを開くには

ここにアップロードしてください。MSG コンテナがパースされ、送信者、宛先、件名、日時、本文が読めるプレーンテキストとして返ってきます。Outlook もプラグインもインストールも不要です。無料、登録不要、1 ファイル 50 MB まで、こちら側には何も保存しません。

MSG ファイルをテキストエディタで開くとバイナリの塊に見えるのはなぜですか

テキストファイルではなく複合バイナリファイルだからです。Outlook はメールを、内部にディレクトリツリーを持つコンテナとして保存します。件名、本文、受信者ひとりひとり、添付ファイルひとつひとつが、MAPI プロパティ識別子でタグ付けされた別々のストリームに入っています。テキストとして開けば、そのコンテナの生のバイト列に読める単語が少し混ざったものが見えます。

添付ファイルは抽出されますか

いいえ。出力はメール本体、つまりヘッダーと本文です。添付はファイルの中に残ります。添付文書の中身も必要なら、まずメールから保存して、その形式のページで変換してください。複数のメールをまとめて ZIP にし、ZIP からテキスト にかける手もあります。

メールボックスのエクスポートをまるごと変換できますか

1 回のアップロードではできません。ここが受け取るのは .msg 1 個です。フォルダ単位なら ZIP に固めてアーカイブを変換すれば、中のメールを一度に処理できます。証拠開示の作業、スレッドの復元、メールボックスに対する検索インデックスの構築では、これが定番の経路です。

メールの内容は外に漏れませんか

ファイルは処理後に破棄します。保存もログ記録も索引化もせず、アカウントも紐づきません。とはいえ本当に機微な内容なら、安全側に倒すなら ローカルフォルダの変換 です。こちらはアップロードせずブラウザ内でファイルを読みます。

ほかのツール

MSG は File2Txt が扱う形式の一つなので、 ページを選ばず 1 回のアップロードで何でも投げられます。近いところでは、保存した Web ページや ニュースレターのマークアップに HTML からテキスト、 変換しているメールに添付されがちなエクスポートに CSV からテキスト があります。 公開中のページなら Web2Txt が URL をそのまま テキストにしますし、コード側には GitHub リポジトリをテキストに変換するツール があるので、議論されていた実装とスレッドを並べて渡せます。 LLM 向けに文書を用意するガイド で一般的な考え方を説明しています。

Repo2Txt を開発・運用しているのは v12hero、 プライバシーを最優先にしたネイティブアプリと Web アプリを作る独立開発者です。