環境依存文字・半角カタカナ・PPAP|電子メールのマナー
- 著者:YAMANJO
- 公開日:2008年11月24日
- 最終更新日:2026年9月10日
電子メールの書式とマナーについて、具体的に理解していきましょう。
テキスト形式とHTML形式
これまで電子メールの仕組みやセキュリティーについて学習してきた方は、もはや基礎的な知識はもちろん応用的な知識まで身についていると思います。
本項では、電子メール編の締めくくりとして、電子メール特有の書式について学習します。電子メールで使われている書式を理解すれば、ひいてはマナーの向上にもつながります。
前項でも少し触れましたが、電子メールの世界には暗黙のルールのようなものがあって、そのルールやマナーを知らずに送信してしまうと、相手の印象を悪くする恐れがあります。重要な商談メールであれば、情報リテラシーの低い会社(担当者)なんだなと思われて、契約できない可能性がないわけではないのです。
現在では、LINEなどのSNSの普及によって一般的な電子メールを使う機会のある方は多くないかもしれません。しかし、依然として電子メールは、特にビジネスでは必須のツールになっています。
また、メールを介したマルウェア(ウイルスを含む悪意あるプログラムを総称する用語)や偽装メールによる被害が社会問題となり、一方でメールが電子証明書によって公文書としての効力を持つなど「たかがメール」と軽んじられる時代ではなくなっています。
そのため、電子メールの書式の使い分けやマナーを知っておくことはとても重要です。
実際のメーラーの操作方法や実践的なテクニック等は、基本操作 メール編 で詳しく解説していますので、本項では知識と基本的なマナーについて知っておきましょう。
さて、簡単に「書式」といっても電子メールは電子的な手紙であるので、基本的に文字でのやり取りが主になります。その書式とはどういうことかというと、フォント(書体)のことではなく、
そのメールがどのような形式で記述されているか
ということになります。
つまり、普段何気なくやり取りしている電子メールには複数の記述形式があるということです。
すでに前項で「MIMEタイプ」として学習していますが、MIMEに定義された7ビットコードへの変換方法がBASE64以外にもあるのと同じように、電子メール本文にも記述形式があるのです。
その記述形式は、大きく分けて2つです。
テキスト形式とHTML形式(リッチテキスト形式)
です。
これらの形式の特徴や違いについては、下記の表のとおりです。
| 名称 | 特徴 |
|---|---|
| テキスト形式 | すべてのメーラーで使用することができるテキストデータ(文字)のみで構成された形式。一切の装飾がなく、シンプルでデータサイズは他の形式に比べて小さい。添付ファイルとして画像等を送信することはできるが、本文中に画像等を貼り付けることはできない。 |
| HTML形式 | HTMLはウェブページの記述言語で、ウェブページのようにメールの文字の大きさや色、フォントの種類を変えることができる。さらに本文中に背景や画像、音声を挿入したり、リンクを埋め込むことができる。受信者側もHTML形式に対応したメーラーを使用していないと正しく表示されない場合がある。 |
| リッチテキスト形式 | Outlookで利用できるWindows独自の形式。HTML形式と同様に文字の大きさや色、フォントの種類を変えたり画像等を貼りつけることができる。ただし、HTML形式のように音声を埋め込んだり、ひな型を使用することはできない。ExcelやWordなどのデータをオブジェクトとして挿入した場合に、挿入元のデータを更新すると挿入先のデータも更新される「リンクオブジェクト」機能がある。テキスト形式とHTML形式の中間的な形式。 |
下図は、Outlookの形式選択画面です。

さて、ではこれらの形式をどのように使い分けるのか、また電子メールの世界ではどんなマナーや暗黙のルールがあるのか学習していきましょう。
まず書式のマナーとして、
HTML形式(リッチテキスト形式)のメールは極力送らない
ということが暗黙のルールとなっています。
現在では、ひと昔前とは異なりあまり意識されなくなっていますが、メールの重要度が高いほどテキスト形式を使用するべきです。
なぜなら、
HTML形式のメールにはウイルス(マルウェア)混入の危険性がある
というのが大きな理由です。
現在ではメーラー側の対策が強化されていますが、昔はHTMLメールの表示機能やブラウザの脆弱性を悪用して、HTMLメールの本文を開いただけ(プレビュー)で感染してしまうこともありました。
HTMLはウェブページを作成するための記述言語で、画像やリンクなどを組み込むことができます。そのため、HTMLメールはフィッシングやトラッキングなどに悪用されることがあります。
したがって、重要なメールでは、相手の環境やセキュリティーポリシー(組織のルール)を考慮し、必要がなければテキスト形式を使用するのが無難です。
ただし、Outlookなどの多くのメーラーは、
デフォルト(初期設定)がHTML形式に設定されている
ので注意が必要です。
すなわち、意識しなければHTML形式でメールを送信していることになります。設定を変更しておくことをオススメします。(メールの基本操作編 本文の書き方とマナー を参照してください)
環境依存文字
次に、これも暗黙のルールとなっているのが、
環境依存文字(機種依存文字)を使用しない
ということです。
環境依存文字(機種依存文字)とは、文字どおり「その機種でしか扱えない文字」または「他の機種では正しく表示できない文字」になりますが、もう少し詳しく理解しておきましょう。
ガラケーのメールを利用されたことがある方は、docomoやSoftBankなどのメーカーの違いによって、絵文字が正しく表示されなかった経験をお持ちのことと思います。
なぜメーカーによって表示される文字が異なるのでしょうか?
前項で学習のとおり、文字は電子メールに限らず「文字コード」に変換されて通信されます。(文字コードについては、文字コードとは で詳しく学習します)
したがって、どんな文字コードを使用していたとしても、それが世間一般で使用されている文字コードであれば「1000001=A」のように関連付けられているはずで、正しく変換されるはずです。
つまり、きちんと定義された同じ文字コードを使用してやり取りしているのに、メーカーによって双方で表示される文字が異なるというのは普通に考えればおかしな話です。(使用している文字コード自体が異なれば文章全体が文字化けしたり意味不明の文字列になってしまいます)
なぜこのような現象が起きるのかというと、日本語の文字コードはその生成過程において、メーカーなどがシェアの拡大やユーザーの要望のため、コードの空き領域に独自に文字を定義して、それぞれの環境で使用できる文字を増やすことが許されてきたためです。
当時は、異なるメーカーや機種間のやり取りが想定されていなかったり規制がなかったことから、それらの文字が統一されることはなかったのです。
すなわち、同一の文字コードでも、メーカーによって違う文字が割り当てられてしまい、ある部分のコード(メーカーが独自に定義した拡張領域)は異なった文字が表示されるようになったというわけです。
このように環境依存文字とは、
文字コードの空き領域にメーカーがそれぞれ独自に定義している文字
のこと言います。
これは「その機種でしか使えない」のと同じことのようですが、機器的な環境によって使用できる文字が異なるわけではなく、そのメーカーが独自に定義している文字コードが原因となっているので注意が必要です。
つまり、携帯電話だけが対象なのではなく、文字コードを使うすべての機器が対象となります。現在はスマートフォンが主流となり、文字表示はOSの役割となっているため「機種依存」というよりも「OS依存文字」とも言えます。
またWindowsでは、これらの拡張文字を含んだフォント「MS明朝」や「MSゴシック」を作ったので、同じ環境(OS)であっても、フォント(書体)によって表示される文字が異なる場合があります。
これらは、
フォント依存文字
と呼ばれています。
その他、Unicode(ユニコード)という世界中の全ての文字の網羅を目指して開発された文字コードでは、従来の環境依存文字も定義しています。環境依存文字であっても新しい文字コードには正しく定義されているものもあります。(UTF-8はUnicodeの規格になります)
したがって環境依存文字は、ある特定の文字コードで定義が曖昧なだけで、すべての文字コードで機種に依存する訳ではありません。
少しややこしいですが、
環境依存文字やフォント依存文字は、正しく表示されない可能性がある
と思っておきましょう。
こうした問題は、古い文字コードやメーカー独自の拡張文字などによって生じていました。そのため、異なる環境でも確実に表示できるとは限らない文字は、現在でも電子メールなどの文書では使用を避けることがあります。
下図は、Windowsで「環境依存文字」として表示される文字の代表例です。古い環境では、異なるOSや文字コードを使用すると正しく表示されない場合がありました。
| 種類 | 文字 |
|---|---|
| 囲み文字 ローマ数字 |
![]() |
| その他 | ![]() |
よく使われる数字の囲み文字は環境依存文字になります。現在では文字化けすることはほぼありませんが、電子メールでは極力使用しないのがマナーです。
上表の他にも、Windows固有の漢字などの環境依存文字があります。
ただ、Windowsも親切に環境依存文字を知らせてくれるので、覚える必要はありません。下図は文字を変換しようとした時の変換リストです。「環境依存文字」としてメッセージが表示されています。

また、人名に用いられる漢字には多くの環境依存文字があります。例えば「高」の口の部分がはしごの文字や「崎」の右上部分が「立」という文字などです。人名の場合は正しい漢字を使用すべきですが、使用する時には注意が必要です。
ただ現在では、絵文字などの明らかに特殊な文字以外、たいていの環境依存文字は正しく表示されるので、これもそこまで意識されることはなくなっています。
半角カタカナ
これも現在では暗黙のルールですが、
半角カタカナを使用しない
というのも意識しておきましょう。半角カタカナは環境依存文字ではないのですが、敬遠される存在です。
このことを理解するには、まず文字コードの基礎を知っておく必要があります。(詳しくは、文字コードとは であらためて学習します)
前項の学習で、電子メールは7ビットコードでやり取りされるというのは十分理解されたと思いますが、現在よく使われる日本語の文字コードには、2バイト(16ビット)のものや、それ以上のものがあります。
それらを7ビットコードにエンコードして送受信するための規格がMIMEでした。
テキストの場合は、MIMEに定義された文字コードを選択して記述することで7ビットコードに変換することができ、添付ファイルなどのバイナリデータの場合は、MIMEに定義されたエンコード方式によってやり取りすることが可能になります。
ただし、7ビットでやり取りするという電子メールのルールですが、メーラーの設定等によって、8ビットコードでメールを送信することも実際には可能となっています。前項で学習したメールヘッダーを確認すると、まれに8ビットでエンコードされたメールを受け取っているケースがあります。

8ビットのメールを送信してしまうと、どうなるのでしょうか?
現在では問題とならない場合が多いですが、メールの中継をするサーバ(SMTPサーバ)の中には、7ビットにしか対応していないサーバがあります。
このため、7ビットしか扱えないサーバーやソフトウェアを経由すると、8ビットのデータを正しく扱えず、データが破損したり、文字化けしたりする可能性があります。
そこでこの現象を避けるために、日本語の文字コードでも7ビットコードを使う方法が考え出されました。
この広く利用された7ビットコードを、
ISO-2022-JP(一般的には「JISコード」)
と言います。
詳しくは、文字コードとは を参照していただきたいのですが、正確なことを言うとISO-2022-JPは「符号化(エンコード)方式」になります。
文字コードを作成するために集められた文字の集合体に、数値を割り当てて表のように整理したものを「文字コードセット(符号化文字集合)」、その文字コードセットで割り当てられた数値を、さらにコンピュータが効率的に扱えるようにエンコードする方式を「符号化方式」と言います。
つまり文字コードとは、どのような文字コードセットを用いて、それをどのような符号化方式で符号化(ビット化)するのかを定義したものになります。
もっとも、文字コードと符号化方式は同じ名称のことが多く、同じ意味で用いられる場合もあります。したがって、厳密にこれらの用語が使い分けられているわけではありません。
ISO-2022-JPであれば、文字コードセットは「JIS X 0208」などを用い、符号化方式は「ISO-2022-JP」になり、文字コードと同じ名称です。
またASCIIのような単純な文字コードは、文字コードセット(符号化文字集合)で定義された数値(文字と数値を対応させた単純な整数値)を、エンコードの必要もなくそのまま使うことができるので、ASCIIは文字コードセットの意味でも用いられます。
前項で、ISO-2022-JPはこのASCIIと同じコードのように扱えると学習しました。その理由は「エスケープシーケンス」という切り替えコードを用いて、複数の文字コードセットを切り替えて使用することができるからです。
使用するコードはASCIIと同じです。エスケープシーケンスにより文字コードセットをASCIIと切り替えることで、同じコードでも異なる文字を表現することができ、ASCIIよりも多くの文字を扱えるのです。
エスケープシーケンスは、文字コードセットが変化する位置を示すコードです。例えば「1b 28 42」のようなコードで表され、このコードを使うことで「AAA エスケープシーケンス あああ エスケープシーケンス 亜亜亜」のように、ASCIIと同じコードで日本語を扱うことができるようになっています。
ISO-2022-JPに定義されている文字コードセットには、「ASCII」「JIS X 0208」など複数の種類があります。
2バイト以上を必要とする漢字などの文字コードを「マルチバイトコード」などと言いますが、ISO-2022-JPはエスケープシーケンスによる文字コードセットの切り替えによって、マルチバイト文字を使用することができます。
ここまで理解できると、あとは簡単です。
ISO-2022-JPで扱えない文字を使用しない
ということが電子メールのマナーになるわけです。
長くなりましたが、
半角カタカナはISO-2022-JPに定義されていない
ということになります。
したがって、ISO-2022-JPで半角カタカナを変換することができません。さらに言うと、半角カタカナを送信することができないということになります。
ひと昔前は、半角カタカナを送信することによってシステムに誤作動を引き起こすこともあったそうです。現在、ISO-2022-JPでエンコードする場合は、メーラーが「全角カタカナ」に自動的に変換します。
環境依存文字との違いは、半角カタカナはISO-2022-JPに存在しないだけで、他の文字コードには定義されており、機種や環境に依存するわけではありません。あくまでISO-2022-JPだけの話です。
よって、ISO-2022-JP以外でエンコードすれば使用することができます。Unicodeの「UTF-8」でエンコードする場合は、半角カタカナでも送受信することができます。
現在では、ISO-2022-JPよりもUTF-8が広く利用されており、従来の日本語メールではISO-2022-JPが広く使われていたため、この方式で扱えない文字を使用しないことが長くメールのマナーとされてきました。次第にこうした暗黙のルールはなくなっていくものと思われますが、歴史を知っておいて損はありません。
下図はOutlookのエンコード方式の一覧です。前項で学習した「MIMEタイプ」によってメーラーがエンコード方式を選択しています。日本語メールの場合は「日本語(自選選択)」が選択されているケースが多いです。これがJISコードになります。

上図は、任意のメールをダブルクリックして別画面で開き「メッセージ」タブの「アクション」→「その他のアクション」→「エンコード」で確認することができます。Unicodeで送信されたメールは「Unicode(UTF-8)」が選択されています。

文字化けが起こった場合は、このエンコード方式を選択しなおすことで解消できる場合があります。
また、こちらが送信する際のエンコード方式は、デフォルト(初期設定)でJISコードが設定されています。

添付ファイル
では、最後に「添付ファイル」のマナーについてです。
添付ファイルも7ビットコードにエンコードして送信するというのはこれまでの学習のとおりで、テキスト以外のバイナリデータは、base64などのエンコード方式でコード化されます。
よく間違えがちなのが、Wordで作成した文書ファイルも「バイナリファイル」になることです。文字だけのWordファイルでも、実際にはレイアウト情報などのいろいろな情報が含まれているからです。純粋なテキストファイルとしては「メモ帳」というアプリケーションソフトを使って作成したファイルであればテキストファイルになります。
したがって、添付ファイルの容量が大きければ大きいほど、コード化するデータ量は膨大なものになり、処理時間がかかることになります。
そのため、
原則として容量の大きい添付ファイルを送信しない
というのがマナーになります。
これは暗黙のマナーではなく当然のマナーです。添付ファイルを送る場合は、相手の通信環境に配慮することが大切です。
送信相手が光回線等の定額大容量通信であれば問題ありませんが、例えば、モバイルの契約しかしていない場合は、容量の大きいファイルをダウンロードするのにパケット通信料がかかったり、通信量の上限を超えて通信制限がかかってしまうなどの迷惑をかけることにもなりかねません。
どうしてもサイズの大きな添付ファイルを送信する場合には、事前にそのファイルのサイズを相手に伝え、了承を得ておくということも必要になります。
最近では、特に注意しなければならないのが写真を添付する場合です。近年のデジカメやスマートフォンは超高画質で撮影することができるため、1枚の写真が10MB程度になることも珍しくありません。
プロバイダによっては10MB以上の添付ファイルは受信できない場合もある
ので注意してください。
利用しているサービスによって容量制限は異なりますが、例えば、2枚の写真を添付して送信しても、相手側では1枚しか添付されていなかったり、添付ファイルがすべて削除されてしまうなどのトラブルが起こる可能性があります。基本的には10MBを目安にしましょう。
また、添付ファイルは送信時にエンコードされるため、実際のメールサイズは元のファイルサイズより大きくなります。現在では大容量ファイルをメールに直接添付するより、クラウドストレージなどを利用して共有する方法も一般的になっています。
そして、添付ファイルについてもっとも大切なことは、
添付ファイルのファイル形式(拡張子)に注意する
ということです。
拡張子は、拡張子 で学習のとおり、ファイルの形式を表す文字列です。送ろうとしているファイルが、相手も扱うことができる形式であるのかどうか確認することが必要です。
特殊なソフトウェアで作成したファイルであれば、そのソフトウェアをインストールしていない環境では利用できず、ファイルを送る意味がありません。これも暗黙のマナーではなく当然のマナーになります。
また、原則として送ってはいけないファイル形式もあります。
実行ファイル「.exe」、データベースファイル「.mdb」、バッチファイル「.bat」など
これらは、マルウェア混入の危険性があったりシステムに影響を与える可能性がある(そうした悪用事例が多い)ファイル形式です。これらは相手の了承を得ていたとしても「そのまま」で送信するのは御法度です。
なぜなら、プロバイダやメーラーの設定によってブロックされる設定になっている場合があるからです。
これらのファイルをどうしてもメールで送信する場合は、相手の了承を得たうえで、ZIPなどの圧縮ファイルにまとめて送信する方法があります。が、現在ではセキュリティー上の理由から、実行ファイルなどをメールで直接送受信すること自体を避けることが推奨されます。(圧縮については、圧縮・解凍とは で詳しく解説しています)
添付ファイルの圧縮についても、近年問題となった事例があります。
特に日本で流行している手法で、
PPAP(ピーピーエーピー)
と呼ばれる手法です。
PPAPは、パスワード(Password)付きファイルの送付、パスワード(Password)の送付、暗号化(Angouka)、プロトコル(Protocol)の頭文字を取って日本で作られた造語です。
ZIP(ジップ)という圧縮形式で圧縮すると、簡単に解凍パスワードを設定することができます。これを利用して添付ファイルに復号化パスワードを設定するというものです。
こうすることで、添付ファイルはパスワードを入力しないと見ることができません。S/MIME等によって暗号化通信を行うわけではなく、パスワードだけをかけることで一定の機密性を保持した手法になります。
日本では、このように注文書や見積書といった正式な書類は、ZIPで圧縮されて解凍パスワードが設定された状態でメールに添付されるのが一般化していました。
そして、解凍パスワードは別のメールで送付するのです。つまり、パスワードが設定された添付ファイルを1通目で送付し、そのあとに「先ほどのパスワードは〇〇です」といった内容のメールを2通目に送付します。
添付ファイルとパスワードを一緒に送らないことから、一定のセキュリティー対策になると考えられ、現在でもたまに見かける手法です。
しかし、PPAPはむしろセキュリティー上のリスクが高いことが指摘されています。
基本的に2通とも同じ経路で送信されるため、1通目が盗聴された場合、2通目のパスワードも盗聴されてしまうこと、圧縮ファイルにパスワードが設定されていると、ウイルス対策ソフトなどが中身を検査できない場合があり、マルウェアが混入していても検知できない可能性があることです。
特に後者が重大で、PPAPを装った「Emotet(エモテット)」というマルウェアが猛威を振るいました。こうしたことから、2020年11月、内閣府をはじめとする政府機関で、いわゆるPPAP方式を廃止する方針が示されました。
代替策としては、ファイルをクラウドストレージにアップロードし、メールにはダウンロード用のURLを記述するなどの方法が利用されています。ただし、こちらもパスワードをどうやって伝達するかという暗号通信と同じ課題に直面しています。
最後に補足として、
送信したメールは取り消すことができない
ということを忘れてはいけません。
大切なメールであればあるほど、何度も確認して送信することが大切です。取り消し機能付きメールのサービスを行うプロバイダもありますが、基本的には取り消すことはできません。
以上で基本的なマナーと書式についての学習は終了です。このほかにも実践的なマナーや注意点はたくさんありますが、メーラーやアプリケーションソフトの操作を伴うので、メール編 で詳しく解説しています。
更新履歴
- 2008年11月24日
- ページを公開。
- 2009年6月3日
- ページをXHTML1.0とCSS2.1で、Web標準化。レイアウト変更。
- 2018年1月30日
- ページをSSL化によりHTTPSに対応。
- 2026年9月10日
- 内容修正。
著者プロフィール
YAMANJO(やまんじょ)
- 経歴
- 岡山県出身、1980年生まれ(申年)の♂です。現在、総合病院で電子カルテなどの情報システム担当SEとして勤務。医療情報学が専門ですが、ネットワーク保守からプリンタの紙詰まり、救急車の運転手までこなしています。
- 医療情報技師、日本DMAT隊員。ITパスポート、シスアドなど、資格もろもろ。
- 趣味は近所の大衆居酒屋で飲むこと、作曲(ボカロP)、ダイビング。
- 関連リンク
- 詳細なプロフィールはこちら
- 作成したボカロ曲などはYoutubeへ
- X(Twitter)


