mail アラカルト with ChaatGPt

大規模言語モデル講座 基礎編 2025 Autumn　敗因を勝因に
https://qiita.com/kaizen_nagoya/items/34ffd2b0c47a5f3665d9

最初の案内はメールで来た。
大事なURLなどが書いてあった。

いちいちメールを開くのは面倒。

slack, Google Drive, Notion, Zoomなど４箇所以上に同じ情報があると嬉しいかもってなった。
自分専用のPrivate Webに掲載するのも手かも。

ChatGPT

mail サーバ 10種類とmail クライアント 10種類それぞれの特徴をお示しください。

ChatGPT:

もちろんです。メールサーバ（Mail Server）とメールクライアント（Mail Client）は、それぞれ用途や機能が異なりますので、分けて整理します。以下に代表的な10種類ずつと特徴をまとめました。

1. メールサーバ（Mail Server）10種類と特徴
   サーバ名 主な特徴
   Microsoft Exchange Server Windows環境向け。Active Directory連携、カレンダー・タスク管理、Outlookとの統合が強力。企業向け。
   Postfix Linux/Unix向け。高性能・軽量でセキュア。設定が比較的簡単で広く利用されるオープンソース。
   Exim Linux向け。柔軟なルール設定が可能。Debian系で標準採用されることが多い。
   Sendmail 歴史あるメールサーバ。非常に柔軟だが設定が複雑。Unix系で伝統的に使用。
   Qmail セキュリティ重視。高スループット。設定は独自形式だが安定性が高い。
   Zimbra Collaboration Suite メールだけでなく、カレンダーやファイル共有も統合。Webメール対応。
   IBM Notes/Domino メール＋アプリケーションサーバ。企業向けのコラボレーション機能が充実。
   Google Workspace（旧 G Suite） クラウドベース。メンテナンス不要、スパムフィルタリングが強力。Web/モバイル対応。
   hMailServer Windows向けオープンソース。小規模オフィス向け。POP3/SMTP/IMAP対応。
   Courier Mail Server Unix/Linux向け。IMAP/POP3サーバとして安定性が高く、メーリングリスト対応も可能。
2. メールクライアント（Mail Client）10種類と特徴
   クライアント名 主な特徴
   Microsoft Outlook Exchangeとの連携が強力。カレンダーやタスク管理も統合。企業ユーザー向け。
   Mozilla Thunderbird 無料オープンソース。拡張機能豊富でクロスプラットフォーム。POP/IMAP対応。
   Apple Mail macOS/iOS標準。iCloudとの統合、シンプルで直感的。
   Gmail (Web) Webブラウザベース。Googleサービスとの統合。ラベル管理、検索機能が強力。
   Windows Mail Windows標準。シンプルで軽量、Outlookより簡易的。
   Mailbird Windows向けサードパーティ。複数アカウント管理やチャット統合が可能。
   eM Client Windows/macOS対応。カレンダー・タスク・チャット統合。UIが直感的。
   Evolution Linux向け。メール・カレンダー・アドレス帳統合。企業向けExchange対応あり。
   KMail Linux KDE向け。IMAP/POP3対応、暗号化（GPG）対応。
   Proton Mail (Web/Mobile) プライバシー重視。エンドツーエンド暗号化。クラウド型でWeb/Mobile対応。
   補足
   メールサーバは 送受信やアカウント管理 が主機能。
   メールクライアントは ユーザー操作と管理、読み書き が主機能。
   Exchange + Outlook のように、サーバとクライアントをセットで使うと機能を最大化できます。
   クラウド型（Gmail, ProtonMail）ではサーバ管理不要で導入が容易です。
   希望であれば、サーバとクライアントの組み合わせ別おすすめ例も作れます。
   作ってほしいですか？

メールの設定には、DNSが関係しますか？　サーバとクライアントの例をお示しください。

ChatGPT:

はい、メールの設定にはDNSが非常に深く関係します。順を追って解説し、サーバ・クライアントの例も示します。

1. メールとDNSの関係
   メールの送受信には、DNS（Domain Name System）が必須です。主に以下の役割があります。
   DNSレコード 用途
   MXレコード (Mail Exchanger) 送信元メールサーバが宛先ドメインのメールサーバを特定するため。
   Aレコード / AAAAレコード MXレコードで指定したホスト名をIPアドレスに変換する。
   SPFレコード (TXTレコード) 送信ドメインのなりすまし防止。どのサーバから送信可能かを指定。
   DKIMレコード (TXTレコード) 送信メールに電子署名を付与し、改ざん防止・認証。
   DMARCレコード (TXTレコード) SPF/DKIMの結果をもとに受信側が処理方針を決定。
   例: DNSが使われる流れ
   ユーザーA（[e-mail]）がメールを送信。
   Aliceのメールサーバが example.com のMXレコードをDNSで問い合わせ。
   MXレコードで指定されたメールサーバのIPにA/AAAAレコードをDNSで変換。
   メールをそのサーバに配送。
   SPF/DKIM/DMARCにより送信元認証が行われ、受信者の迷惑メール判定に使われる。
2. メールサーバの設定例（DNS関係）
   サーバ名 DNS設定例
   Postfix main.cf で自ドメインを設定。DNS MXを参照してリレー。SPF/DKIMのDNS TXTレコードも設定。
   Microsoft Exchange Exchange管理センターでドメイン登録。DNSでMX/SPF/DKIM/Autodiscoverを設定。
   hMailServer 管理画面でドメイン追加。MXレコードで受信、SPF/TXTで送信認証。
   DNSで必要な設定例（example.comの場合）:
   example.com. MX 10 mail.example.com.
   mail.example.com. A 192.0.2.10
   example.com. TXT "v=spf1 ip4:192.0.2.10 -all"
   default._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=…"
   _dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:[e-mail]"
3. メールクライアントの設定例
   クライアントは基本的にDNSの知識を直接操作する必要はありませんが、正しいサーバ名を入力する必要があります。
   クライアント名 DNSとの関係
   Outlook 受信サーバ名: imap.example.com / SMTPサーバ名: smtp.example.com。DNSで名前解決される。
   Thunderbird 自動設定ではMXやAutodiscoverをDNS参照してサーバ情報を取得。
   Apple Mail IMAP/SMTPサーバ名を入力するだけ。DNSでA/AAAAレコードに変換され接続。
   Gmail (Web) サーバ設定不要（クラウド型）。内部でDNS参照して他ドメインにメール配送。
   ポイント
   メールサーバ運用では DNSが正確に設定されていないと受信・送信トラブル が発生。
   クライアントは基本的にサーバ名を入力するだけでDNSが裏側で解決される。
   SPF/DKIM/DMARCを設定しておくと 迷惑メール判定回避 に効果的。
   希望であれば、サーバ・クライアント別に具体的な設定例のスクリーンショット付き手順 も作れます。作りますか？

あるドメインから、別のあるドメインにメールが届かないという現象がありました。よく知られた原因と対策をお示しください。

ChatGPT:

了解です。ドメイン間でメールが届かない場合は、原因が複数考えられます。ここではよくある原因と対策を整理します。

1. 送信側・受信側共通でよくある原因
   原因カテゴリ 詳細 対策
   DNS関連 MXレコードが正しく設定されていない、A/AAAAレコードの不整合 - MXレコードとAレコードを確認

• nslookup や dig で検証
  SPF認証失敗 送信元サーバがSPFに含まれていない → 受信側で拒否 - DNSに正しい SPF TXT レコードを追加
• 複数サーバから送信する場合はIP追加
  DKIM署名不一致 DKIM署名が破損、公開鍵と一致しない - 送信サーバで DKIM 鍵を正しく設定
• TXTレコードで公開鍵確認
  DMARCポリシーによる拒否 DMARCポリシーが厳しく送信ドメインを拒否 - SPF/DKIM整合性を確認
• DMARCポリシーを p=none でテスト
  ブラックリスト/スパム判定 送信IPがスパムリスト入りしている - mxtoolbox.com などでブラックリスト確認
• リスト除外依頼
  受信サーバ設定 受信側のフィルタリング、容量制限、メールボックス停止 - 受信サーバのログを確認
• 容量があれば空き確保
  ネットワーク/接続障害 SMTPポート（25/587）がブロックされている - telnet/opensslでポート接続確認
• ファイアウォール設定を見直す
  メールサイズ制限 添付ファイルが大きすぎる - 送信サイズを受信側制限内に収める
  間違ったメールアドレス ドメイン部分は合っているがアカウント名が間違い - 正しいアドレスか再確認
  一時的なサーバ障害 メールサーバの停止やメンテナンス - 送信リトライを待つ
• 受信側運用情報確認

'2. 調査手順の例
送信側でログ確認
Postfix: /var/log/mail.log
Exchange: メッセージトレース
→ エラーコード（550, 554, 421など）を確認。
DNS・認証確認
dig MX example.com
dig TXT example.com # SPF/DKIM/DMARC確認
SPF失敗 → 受信拒否の可能性
DKIM失敗 → 改ざん扱いされる可能性
受信側でログ確認
メールが拒否されている場合、受信側ログに理由が残る
スパム判定、容量不足、ポリシー拒否など
外部ツールでテスト
MXToolbox でブラックリスト、SMTP接続、SPF/DKIM/DMARC確認
'3. よくある具体的ケースと対策例
ケース 原因 対策
送信ドメインがGmailに届かない SPF未設定 DNSに v=spf1 include:_spf.example.com ~all を追加
自社サーバから外部に届かない ISPがSMTPポート25をブロック ポート587に変更、認証付きSMTPを使用
受信ドメインで「550 5.7.1 …」 ブラックリスト入り IP除外依頼、送信認証（SPF/DKIM/DMARC）設定
添付ファイル大きすぎ メールサイズ制限 ファイル分割またはクラウドリンク送信
要点としては：
DNS（MX/SPF/DKIM/DMARC） は最初に確認
送受信ログ で拒否理由を確認
ブラックリストやネットワーク障害 も確認
メールアドレス・サイズ・一時的障害 も見落とさない
希望であれば、「送信元example.com→受信先example.netが届かない場合の具体的な調査手順」 をステップごとにコマンド例付きで作成できます。
作りますか？

はい。

ChatGPT:

では、「送信元 example.com → 受信先 example.net が届かない場合」の具体的な調査手順を、コマンド例や確認ポイント付きで整理します。
送信トラブル調査手順（例）

1. 送信側ログの確認
   Linux（Postfixなど）の場合

直近100行を確認

tail -n 100 /var/log/mail.log

送信先ドメインに関連するログだけ抽出

grep example.net /var/log/mail.log
確認するポイント：
SMTPエラーコード（例: 550, 554, 421）
「Relay access denied」「SPF fail」「Mailbox unavailable」などの文字列
エラーが出ていれば原因の手掛かりになります。
2. 受信側ログの確認
ExchangeやLinux系受信サーバ
Exchange: メッセージトレースで送信元・送信時間・ステータス確認
Linux/Postfix:
grep example.com /var/log/mail.log
確認するポイント：
受信拒否理由（SPF/DKIM認証失敗、スパム判定）
宛先ユーザー存在の有無
サーバ容量・メールボックス状態
3. DNS設定の確認
MXレコードの確認
dig MX example.net +short
正しいメールサーバが返るか確認
例: 10 mail.example.net.
A/AAAAレコードの確認
dig A mail.example.net +short
dig AAAA mail.example.net +short
MXで指定されたホスト名が正しいIPに解決されるか確認
SPF/DKIM/DMARC確認
dig TXT example.com +short
dig TXT _dmarc.example.com +short
dig TXT default._domainkey.example.com +short
SPF: v=spf1 … の設定確認
DKIM: 公開鍵が正しいか
DMARC: ポリシーが適切か (p=none / p=quarantine / p=reject)
4. ネットワーク接続の確認
SMTPポート接続確認

送信サーバから受信サーバへポート25で接続できるか

telnet mail.example.net 25

SSL/TLSの場合

openssl s_client -connect mail.example.net:465
接続できなければ、ファイアウォールやISPのブロックが原因の可能性
5. ブラックリスト確認
外部ツールを利用：
MXToolbox Blacklist Check
送信元IPがスパムリストに入っていれば、受信拒否の可能性あり
6. メールサイズ・添付ファイル確認
受信サーバのメールサイズ制限を確認
大きすぎる添付ファイルは分割やクラウドリンク送信を検討
7. 実際のテスト送信
テキストだけのメールを送る
問題がなければ添付やHTMLメールで再現確認
エラーが再現されれば原因を特定しやすい
まとめの流れ
送信側ログ確認 → エラー内容把握
受信側ログ確認 → 拒否理由把握
DNS確認（MX/A/SPF/DKIM/DMARC） → 正しい設定か
ネットワーク確認（ポート、ファイアウォール）
ブラックリスト確認
メールサイズや添付ファイル確認
テスト送信 → 問題の切り分け
希望であれば、これをフローチャート図にして、メール送信→受信までの障害原因を視覚的に確認できる形にもできます。
作りますか？
Is this conversation helpful so far?

メールに暗号付きZIPファイルを添付して、パスワードを別メールで送るという、セキュリティ上同じ媒体でパスワードを送ってはいけないという原則を外れたことが横行していたそうです。まだ、やめていない人たちはいるのでしょうか。

ChatGPT:

はい、実際のところまだ同じメールでパスワードを送る方法を使っている人は少なくありません。特に企業や組織の中でも、ITリテラシーが低い部署や、古い習慣を続けている人たちの間では横行しています。
以下に整理します。

1. なぜ同じメールでパスワードを送ると危険か
   メール自体はほとんど暗号化されていない場合が多く、途中で盗聴される可能性がある。
   添付ファイルとパスワードを同じメールで送ると、ZIP暗号の意味がなくなる。
   フィッシングやマルウェア感染時に、攻撃者がまとめて情報を入手できる。
2. 現状でこのやり方をやめない理由
   習慣・手間の問題
   パスワードを別に送る手間を省きたい。
   短期的には簡単で便利。
   教育不足
   セキュリティ教育が行き届いていない。
   暗号化ZIPとパスワード分離のリスクを理解していない。
   環境依存
   クラウドストレージや安全なファイル転送ツールが使えない環境で、古い方法を使い続けている。
3. 現代の推奨セキュリティ手法
   方法 特徴
   クラウドストレージの共有リンク + アクセス制限 パスワード不要。閲覧者を特定でき、ログ追跡可能。
   専用ファイル転送サービス ファイルを一時的に暗号化して送信。URLの有効期限やダウンロード回数制限あり。
   PGP/GPG暗号化 メール自体を暗号化。パスワード送信不要。公開鍵暗号方式で安全。
   Teams/Slackなどの内部チャネルで送信 社内ツールで安全に送信。権限管理が可能。
   結論
   同じメールでパスワード送付はセキュリティ原則違反であり、まだ使っている人は一定数いる。
   特に「便利だから」「慣習だから」と理由で続けるケースが多い。
   安全な代替手段（クラウド共有リンク、PGP暗号化など）を教育・導入すれば減らせる。
   もし希望であれば、「暗号付きZIP＋パスワード送付」をやめさせるための社内ルールや教育例を具体的に作ることもできます。作りますか？

はい。

ChatGPT:

では、「暗号付きZIP＋パスワード送付」をやめさせるための社内ルールと教育例を具体的に整理します。
暗号付きZIP＋パスワード送付廃止の社内ルール例

1. 基本ルール
   同一メールでパスワードを送らない
   添付ファイルとパスワードを同じメールで送付してはいけません。
   暗号化ZIPの使用は原則禁止
   特例としてどうしても必要な場合は、情報システム部の承認を得る。
   安全なファイル送信手段を使用
   クラウドストレージの共有リンク（アクセス制限付き）
   社内ファイル転送サービス（OneDrive、Google Drive、SharePointなど）
   PGP/GPGによるメール暗号化
   パスワード送信は別安全媒体で
   例：Teams/Slackの社内チャネル、電話、SMSなど安全にアクセスできる別手段
2. 推奨代替手段
   手段 方法 注意点
   クラウドストレージ共有リンク ファイルをアップロード→アクセス権を指定→リンク送信 有効期限・アクセス権を必ず設定
   社内ファイル転送サービス 暗号化通信で送信、受信者のみダウンロード可能 一時的ファイル削除設定を推奨
   PGP/GPG暗号化メール 公開鍵で暗号化して送信 受信者は秘密鍵で復号、鍵管理が必須
   安全な社内チャネル利用 Teams, Slackなどでパスワード共有 アクセス権限を適切に設定
3. 教育・啓蒙施策例
   社内セミナー・eラーニング
   「安全なファイル送信と暗号化の基本」
   なぜ暗号ZIP＋同メールパスワードが危険か実例を紹介
   マニュアル配布
   図解入りで「安全なファイル送信手順」
   代替手段（クラウドリンク、PGP）の操作例を掲載
   メールテンプレート提供
   安全にファイルを送るための例文を提示
   例：
   添付ファイルは社内クラウドにアップロードしました。
   アクセスリンク：https://...
   アクセス権限は〇〇のみです。
   パスワードはTeamsで送信しました。
   運用チェックリスト
   上長または情報システム部がランダムで確認
   違反があれば改善指導
   定期周知・注意喚起
   社内ニュースレターや掲示板で「安全な送信ルール」の再周知
4. コンプライアンス・リスクの明示
   個人情報・機密情報を含む場合は法的リスクあり
   不適切な送信による情報漏洩で、社内懲戒の対象になる場合もある
   ルール遵守は安全性確保だけでなく、法令・社内規程の遵守にも直結
   💡 ポイント
   「便利だから暗号ZIP＋パスワード」を使う → 最大のリスク
   安全な代替手段を提示し、手順を簡単にすることが習慣を変える鍵
   希望であれば、このルールをもとに**「フローチャート形式の送信手順図」**を作り、誰でも直感的に理解できる形にすることもできます。
   作りますか？

メールに添付する以外の方法としては、Githubなどのgit系の利用、Google Driveなどのクラウドファイルサーバの利用などいろいろ考えられます。７つ以上の方法を示し、その長短をお示しください。

ChatGPT:

了解です。メール添付以外で安全にファイルを共有・送信する方法を7種類以上整理し、それぞれの長所・短所を示します。
メール添付以外の安全なファイル共有手段と評価
方法 長所 短所

1. クラウドストレージ（Google Drive, OneDrive, Dropboxなど） - アクセス権限設定可能

• URL共有で大容量も対応
• バージョン管理可能 - インターネット接続必須
• 権限設定ミスで情報漏えいのリスク
• 社内ポリシーにより利用制限される場合あり

1. Git/GitHub/GitLabなどのリポジトリ管理 - バージョン管理・履歴管理が容易

• コードやテキスト中心の共有に最適
• 共同編集可能 - バイナリ大容量ファイルは不向き
• 操作にはGitの知識が必要
• 公開リポジトリは情報漏洩のリスク

1. 専用ファイル転送サービス（WeTransfer, Firefox Sendなど） - 一時的URLで大容量ファイル送信可能

• 暗号化転送対応 - 無料版は容量制限あり
• 受信期限が短い場合がある
• URL紛失で受信不可

1. 社内ファイルサーバ（NAS, SharePointなど） - 社内ネットワーク内で完結、セキュリティ高い

• 権限管理・アクセスログ取得可能 - 外部アクセスに制限あり
• 設置・運用コストがかかる
• VPN接続が必要な場合も

1. PGP/GPGによるメール暗号化 - 既存メールシステムをそのまま利用可能

• 高度な暗号化で安全 - 受信者側も鍵管理が必要
• 初期設定や操作がやや複雑

1. 安全なチャット/コラボレーションツール（Teams, Slack, Mattermostなど） - 社内ユーザーに即座に送信可能

• アクセス権・チャネル制御可能
• ファイル履歴の管理が容易 - 社外ユーザーとの共有は制限される場合あり
• 大容量ファイルには不向き

1. SFTP / FTPSなどの暗号化ファイル転送 - 通信路暗号化済みで安全

• 大容量ファイル送信可能
• 自動スクリプトで運用可能 - 初期設定・アカウント管理が必要
• 一般ユーザーには操作が難しい場合

1. 仮想プライベートクラウド（Nextcloud, OwnCloudなど） - 社内運用可能でクラウドサービス同等の利便性

• アクセス権、共有リンク、バージョン管理あり - サーバ構築・運用コストがかかる
• インターネット経由でアクセスする場合はセキュリティ設定必須
  まとめ・選び方のポイント
  大容量ファイル・共同編集 → クラウドストレージ / 社内ファイルサーバ
  ソースコードやテキスト中心 → Git/GitHub
  一時的に安全に渡す → 専用ファイル転送サービス / SFTP
  既存メールインフラを活用 → PGP/GPG暗号化
  社内向け即時共有 → Teams/Slackなどのコラボレーションツール
  💡 補足
  「暗号付きZIP＋同メールパスワード」の代替としては、クラウドリンク＋アクセス制御か、PGP/GPG暗号化が最も安全かつ手軽です。
  共有対象（社内/社外）、ファイルサイズ、操作スキルに応じて最適手段を選択するのが重要です。
  希望であれば、**この8種類を安全性・利便性・運用コストの観点で比較した図表（マトリクス形式）**に整理することもできます。
  作りますか？

はい。

ChatGPT:

では、先ほどの8種類のファイル共有手段を 「安全性」「利便性」「運用コスト」 の3軸でマトリクス形式に整理しました。これで、どの方法がどの状況に適しているか一目でわかります。
ファイル共有手段の比較マトリクス
方法 安全性 利便性 運用コスト コメント
クラウドストレージ（Google Drive, OneDrive, Dropbox） 高 高 低〜中 アクセス権管理が可能、大容量ファイルに最適。社外共有も容易だが権限設定ミス注意
Git/GitHub/GitLab 高（コード向け） 中 低 バージョン管理が強力。テキストやコード向き。大容量バイナリは不向き
専用ファイル転送サービス（WeTransferなど） 中〜高 高 低 一時的リンクで大容量送信可能。無料版は容量制限や有効期限に注意
社内ファイルサーバ（NAS, SharePoint） 高 中 中〜高 社内ネットワーク完結でセキュリティ高い。外部アクセスにはVPN等が必要
PGP/GPG暗号化メール 非常に高 低〜中 中 メールを暗号化できるが鍵管理が必須。操作に慣れが必要
安全なチャット/コラボツール（Teams, Slack） 中〜高 高 低 社内ユーザー向けに即時共有可能。ファイル履歴管理も容易だが大容量向きではない
SFTP / FTPSなどの暗号化ファイル転送 非常に高 中 中〜高 大容量でも安全に送信可能。自動化も容易だが初期設定・アカウント管理が必要
プライベートクラウド（Nextcloud, OwnCloud） 高 中 中〜高 社内でクラウド型ファイル共有。アクセス権・バージョン管理あり。構築・運用コストあり
3つの軸の見方
安全性: データ暗号化・アクセス制御・認証の強さ
利便性: ユーザーが簡単に操作できるか、大容量対応か、共同作業対応か
運用コスト: 導入・管理・教育のコスト
💡 ポイント
高安全性を求める場合 → PGP/GPG、SFTP、社内クラウド
利便性を重視する場合 → クラウドストレージ、チャットツール、専用転送サービス
大容量やバージョン管理 → クラウドストレージ、Git/GitHub、SFTP、社内クラウド
希望であれば、このマトリクスを基に 「利用シーン別おすすめ手段」表 を作り、どの状況でどれを選ぶべきかを具体例付きで示すこともできます。
作りますか？
ChatGPT の回答は必ずしも正しいとは限りません。重要な情報は確認するようにしてください。

mail @ Qiita

添付ファイルの後に送られてくるパスワードの意味
https://qiita.com/Akio-1978/items/4630bf4ebf18aa5b5200

PPAP対策とは？パスワード付きZipファイルの添付メール廃止について解説
https://qiita.com/KenjiYuasa/items/608c81118cfdf41a8b28

添付ファイルのパスワードは私の誕生日です♡からの脱却！Power Automate Desktopで真面目にPPAP自動化してみた。
https://qiita.com/katourina0120/items/eeec69b92ca243f29dbd

#PowerAutomate と Forms で問い合わせ受付＋添付ファイル PPAP回避
https://qiita.com/yamad365/items/b7a9fd865b905eb9165a

ポストPPAP時代について思うところ
https://qiita.com/nfwork01/items/28bf63b6e4da62d891ed

メールにパスワード付きzipを添付して「パスワードは別途お送りいたします」とする慣習がめんどくさいのでなんとかした
https://qiita.com/Kta-M/items/afa94a6728416511b78b

PPAPを拒否するMilterを作ってみました
https://qiita.com/hirachan/items/898e3554c007ae1026ef

S3のsinged url を使えば、zipパスワード後送なんて要らん
https://qiita.com/yugo-yamamoto/items/be03e9867840c9e88eab

脱PPAP（パスワード別送問題）に向けて今できること
https://qiita.com/mindwood/items/3882c4884b9aa6121ce7