HTMLからテキストへ変換

Q: HTML からテキストへの変換は元のマークアップに戻すことができますか

いいえ。タグ、属性、スタイルが削除されると、 その構造情報は永久に失われます。 プレーン テキスト ファイルには単語のみが含まれるため、マークアップの再作成はタグと書式設定を最初から再構築することを意味し、ロスレス プロセスを元に戻すことはできません。

Q: HTML からテキストへの変換で絵文字や特殊な Unicode 文字は保持できますか

はい、ソースドキュメントとコンバーターの両方がUnicode ベースのエンコードを使用している限り、可能です。 エンティティが正しくデコードされる場合、絵文字、アクセント付き文字、および非ラテン文字はそのまま通過します。問題は、コンバータが誤って古い狭いエンコードを想定した場合にのみ発生します。

Q: HTML をテキストに変換すると SEO に影響しますか、または重複コンテンツの問題が発生しますか

直接ではありません。検索エンジンは、後から生成されたプレーン テキストのコピーではなく、ライブ ページをインデックスに登録します。 重複コンテンツのリスクは、抽出されたテキストが変更や帰属なしにオープン Web 上の別の場所に再公開された場合にのみ発生します。

Bogdan Sandu (EN) 著 · 公開 2025 年 6 月 9 日 · 最終更新日 2026 年 9 月 13 日

HTMLコードを、整った読みやすいテキストに変換します。この軽量なHTML→テキスト変換ツールは、ブラウザ標準のHTMLパーサーでマークアップを解析し、タグを取り除いて中のテキストを返します。

ツールの機能:

すべての HTML タグを削除し、<script>、<iframe>、<object>、および <embed> ブロックをその内容とともに削除します。
&、 、– などのエンティティを実際の文字にデコードします。
ソースの改行を維持するため、1 行に 1 つの要素を記述した HTML が読みやすくなります。
変換ごとに最大 500KB のマークアップを受け入れます
完全にブラウザ内で実行されます。何もアップロードされず、何も保存されません。

この HTML からテキストへのコンバーターの使用方法

HTML を上部のボックスに貼り付けます
[テキストに変換] をクリックします。
下部のボックスのプレーンテキストを確認します。
[結果をコピー] をクリックして取得するか、[クリア] をクリックして最初からやり直します。

前後の簡単な説明:

<h2>Order &amp; shipping</h2>
<p>Ships in <strong>2&ndash;3 days</strong>.</p>
<ul>
  <li>Free returns</li>
  <li>Tracked delivery</li>
</ul>

Order & shipping
Ships in 2–3 days.

  Free returns
  Tracked delivery

貼り付ける前に知っておくべき 2 つのこと: 改行のない縮小された HTML は 1 つの長い行として表示されること、および <style> ブロックは削除されないため、ソースにインライン CSS が含まれている場合は、最初にこれらのブロックを削除してください。単一のドキュメントを超えたものについては、さらに下にあるライブラリセクションの方が適切です。

一般的なジョブ: HTML 電子メールの代替テキストの作成、スクレイピングされたページから読み取り可能なコピーの抽出、CMS 移行前のコンテンツのクリーニング、またはクリーンテキストの NLP パイプラインへのフィード。

HTML からテキストへのコンバーターとは

HTML からテキストへのコンバーターは、文書からマークアップ、タグ、エンコードされたエンティティを除去し、その下にある読み取り可能なテキストを維持するソフトウェアユーティリティです。

これは、レンダリングされたスクリーンショットではなく、ページまたはファイルの生のソースで機能します。

出力はプレーンテキストです。書式設定やスタイル設定など、ブラウザがレイアウトを描画するために必要なものは何もありません。

人々はこれを、そうではない他のいくつかのことと混同します。

レンダラーではありません。レンダラーはページを視覚的に描画します。これにより、視覚的なレイヤーが完全に破棄されます。
スクリーンショットツールではありません。画像はなく文字のみです
OCRエンジンではありません。 OCR はピクセルを読み取り、HTML からテキストへのコンバーターは既にテキストを含むマークアップを読み取ります。

この値は、生のマークアップが人間、スクリプト、または機械学習パイプラインが実際に使用できるものになる必要がある場所であればどこにでも表示されます。

Mailchimp は、プラットフォームを通じて送信されるすべての HTML 電子メールキャンペーンのプレーンテキストバージョンを自動的に生成します。これは主に、リッチフォーマットを拒否する受信トレイやメールクライアントのために存在します。

この 1 つのユースケース (電子メールフォールバックコンテンツ) は、同じ基盤となるプロセスが適用される数十のユースケースのうちの 1 つです。

HTML からテキストへ vs HTML からマークダウンへ

プレーンテキスト出力では単語のみが保持されます。マークダウン出力では、単語に加えて、タグの代わりにシンボルとしてレンダリングされた構造、見出し、太字、リンク、リストの軽量バージョンが保持されます。

2 つのターゲットは異なる問題を解決するため、間違ったものを選択すると、後で頭痛の種が発生します。

プレーンテキストで保持される内容:

文、段落、生の言葉遣い
他には何もありません。強調なし、見出しレベルなし、リンク構文なし

Markdown が保持するもの:

プレーンテキストで保持されるすべてのもの
ハッシュ記号でマークされた見出しレベル
太字と斜体のマーカー、箇条書きリスト、およびリンク構文

広く使用されているオープンソースのドキュメントコンバータである Pandoc (EN) は、これらを同じもののバリエーションではなく、2 つの別個の出力形式として扱います。

検索インデックス、スパムフィルター、単語のみを考慮する NLP パイプラインにはプレーンテキストを選択してください。

ドキュメントシステム、静的サイトジェネレーター、または旅行中に構造物が必要な場所であればどこでも Markdown を選択してください。

逆の方向、つまり Markdown を HTML に戻す必要がある場合は、代わりに専用の Markdown to HTML ツールがその変換を処理します。

HTML からテキストへのコンバーターの仕組み

すべてのコンバーターは同じ大まかなシーケンスを実行します。つまり、マークアップをロードし、タグを削除し、エンティティをデコードし、空白をクリーンアップし、テキストを返します。

各ステップの詳細はツールによって大きく異なり、それらの詳細によって出力が使用可能か文字化けするかが決まります。

パーサーベースの抽出と正規表現ベースの抽出

正規表現ベースの抽出では、正規表現を使用してタグパターンを照合し、タグと思われるものをすべて削除します。

これは高速かつシンプルであり、ネストされたタグや不正な形式の HTML では、人々が予想するよりも頻繁に壊れます。

パーサーベースの抽出: 最初にマークアップから実際のドキュメントオブジェクトモデルツリーを構築し、次にそのツリーをたどってテキストノードを抽出します。

正規表現ベースの抽出: ツリー全体をスキップし、ドキュメント全体をパターンマッチングの対象となる文字列として扱います。

Firefox の Reader View の背後にあるライブラリである Mozilla の Readability.js (EN) は、正規表現一致ではなく完全な DOM 解析を使用します。これが、正規表現のみのツールが窒息するような乱雑な現実世界のページでも生き残れる理由の 1 つです。

エンティティのデコード

一般的なエンティティ変換:

& はアンパサンドになります
  はプレーンスペースになります
< と > は、小なり文字と大なり文字になります。

変換ツールは、この符号化を元に戻す必要があります。そうしなければ、出力には本来の文字の代わりに、エンティティのコードがそのまま並んでしまいます。

同じエンティティを2回デコードすると、文字列を直すどころか壊してしまいます。この失敗は、一般に思われているよりもよく起こります。

空白の正規化

生の HTML は空白だらけで、ブラウザにとっては何の意味も持たず、プレーンテキストではカオスのように見えます。

ソース内のインデント、タブ、改行は、ブラウザーがレンダリング時にすでに無視しているため、折りたたまれます。

複数の連続したスペースが 1 つに折りたたまれます
単一の段落タグ内の改行は削除されるか、スペースに置き換えられます
ブロックレベルの要素 (段落、div、リスト項目) 間の区切りは、実際の改行として保持されます。

サポートされている入力形式と文字エンコーディング

コンバーターは、コンテンツに触れる前に、マークアップのバージョンと文字エンコーディングという 2 つのことを正確に識別する必要があります。

どちらかを間違えると、出力は読み取れるテキストではなく文字化けした記号になってしまいます。

エンコーディングとマークアップの採用:

UTF-8 は、W3Techs (EN) によって追跡される すべての Web サイトの 98.5% をエンコードしており、最新のコンバータのデフォルトの前提となっています。
同じ調査 (EN)によると、現在オンラインになっているウェブサイトの 95.7% で使用されているマークアップ言語は HTML5 です。
ISO-8859-1 は UTF-8 に次いで一般的なエンコーディングであり、サイトのわずか 1.1% にとどまっています。このギャップは十分に広いため、ほとんどのツールはターゲットではなくフォールバックとして扱います。

XHTML ドキュメントは、XML (EN) のより厳格な構文ルールに従っています。つまり、すべてのタグが適切に閉じられていなければ解析が完全に失敗します。

CDATA セクションは、特にパーサーが触れるべきではないコンテンツを保持するためにマークアップ内に配置されます。スクリプトブロックとインラインデータは一般的な例であり、コンバータは、生の内容を読み取り可能なテキストとして抽出するのではなく、これらをスキップすることになっています。

コンバーターが破損または不完全な出力を生成する最も一般的な理由は、不正な HTML (閉じられていないタグ、不一致のネスト) です。運用コンテンツを含むツールを信頼する前に、テストする価値があります。

リンク、テーブル、リストがプレーンテキストでどのように処理されるか

構造的な HTML 要素は、プレーンテキストに移行しても同じようには存続しません。

それぞれはコンバーターが定義するルールに従ってフラット化されますが、それらのルールはツールごとに異なります。

ハイパーリンクの 3 つの結果:

完全に削除され、リンクテキストのみが残ります
インライン化すると、URL が括弧内のテキストのすぐ隣に表示されます。
脚注に変換され、本文に番号付きの参照が含まれ、完全な URL が個別にリストされます。

テーブルはプレーンテキストになった瞬間に視覚的なグリッドを失います。

通常、行は行になり、行内の列はスペースまたはタブで区切られます。これは狭いテーブルでは機能しますが、広いテーブルではすぐに読み取れなくなります。

後で構造化ファイル内の抽出された行が必要な場合は、専用のテーブルから CSV へのコンバータ (EN)を通じて同じテーブルを実行します。行と列をばらばらのテキストに折りたたむのではなく、そのままの状態で保持します。

リストはテーブルよりも優れています。

順序なしリスト項目では、通常、箇条書きの代わりにハイフンまたはアスタリスクのマーカーが保持されます。
順序付きリストの項目は番号付けを維持します
ネストされたリストは相対的なインデントを維持するため、階層が引き続き表示されます。

変換方法の選択: オンラインツール、ライブラリ、またはスクリプト

HTML からテキストへの変換を実行するには 3 つの実際的なパスが存在し、それぞれが異なる作業量に適合します。

抽象的な中で「最適な」方法を選択することよりも、方法を仕事に適合させることが重要です。

方法	セットアップの手間	バッチ機能	最適な用途
オンラインツール	なし、ブラウザで動作します	一度に 1 つのファイル	迅速かつ不定期の変換
コードライブラリ	パッケージをインストールする	ループ内の数千のファイル	アプリと内部ツール
コマンドラインスクリプト	スクリプトファイルを追加してインストールします	スケジュールされた無人実行	自動化されたパイプライン

オンラインツールは、それを使用する人に何も要求せず、マークアップを貼り付け、テキストを取得するだけで完了します。

仕事に数枚以上の文書が関係する瞬間に、それは崩壊します。

コードライブラリはバックエンドコード (EN) に直接組み込まれます。つまり、アプリケーションは何もクリックすることなく、一晩で数千ページをバッチ処理できます。

一部のサービスは、呼び出し可能な API (EN) を通じて変換を公開しており、依存関係を管理するよりもリクエストを送信したいチームに適しています。

コマンドラインスクリプトは 2 つの中間に位置し、cron ジョブとして十分にスクリプト化可能であり、必要なときに手動で実行できるほど単純です。

言語別の最適な HTML からテキストへのライブラリ

すべての主要なプログラミング言語には、このための成熟したオプションが少なくとも 1 つあり、適切な選択は通常、プロジェクトがすでに依存しているものによって異なります。

Python ライブラリ

BeautifulSoup (EN) は、lxml や html.parser などのパーサーと組み合わせて、出力を詳細に制御できる汎用抽出を目的としています。
依存関係を追加しない軽量ジョブ用の Python 標準ライブラリに組み込まれている html.parser
html2text (EN)、生のプレーンテキストではなくマークダウンのように読み取れる出力用

from bs4 import BeautifulSoup

soup = BeautifulSoup(html, "html.parser")
for tag in soup(["script", "style"]):
    tag.decompose()
text = soup.get_text(separator="\n", strip=True)

pepy.tech (EN) によると、BeautifulSoup4 は PyPI で過去 30 日間で 4 億回以上のダウンロードを記録しました。これは、Python 開発者がデフォルトでどれくらいの頻度でそれに到達するかを物語っています。

PyPI 統計 (EN)によると、html2text は単独で 1 か月で 1,410 万ダウンロードを記録しました。数は少ないですが、それでも安定して献身的に使用されている証拠です。

両者が直接競合することはほとんどありません。 BeautifulSoup は一般的なパーサーであり、html2text は Markdown 形式の出力のスペシャリストです。

JavaScript および Node.js ライブラリ

html-to-text (EN) npm パッケージは、npm レジストリによれば、およそ週に 1,100 万ダウンロードされており、これを必要とするほとんどの Node.js プロジェクトでデフォルトの選択肢となっています。

これはブラウザではなく JavaScript (EN) 環境向けに書かれたサーバー側で実行され、実際の DOM 実装に依存せずに機能します。

import { convert } from "html-to-text";

const text = convert(html, {
  wordwrap: false,
  selectors: [{ selector: "a", options: { ignoreHref: true } }],
});

構成可能な出力ルールを使用してテーブル、リスト、リンクを処理します
プレーンテキストのフォールバックを生成するノードベースの電子メールパイプライン内でうまく機能します
適切なデフォルトが同梱されているため、ほとんどのプロジェクトでは設定がほとんどまたはまったく必要ありません

Java および Ruby ライブラリ

Java と Ruby はどちらも、複数のオプションに注意を分散させるのではなく、単一の主要なライブラリに依存しています。

jsoup (EN) (Java):

長所: フロントエンドコードを書いたことがある人なら誰でも使い慣れた CSS スタイルのセレクター、アクティブなメンテナンス、不正な HTML に対する耐性
短所: まだ HTML に触れていないプロジェクトには依存関係が 1 つ増える

ノコギリ (EN) (Ruby):

長所: 高速で、libxml2 上に構築されており、HTML ドキュメントと XML ドキュメントを同様に適切に処理します。
短所: ネイティブ拡張機能に依存するため、制限のあるホストでの展開が複雑になる場合があります。

どちらのライブラリも、その言語に関して危機一髪というわけではありません。ほとんどの Java および Ruby プロジェクトは、多くの議論の余地なく、デフォルトでこれら 2 つのいずれかになります。

HTML からテキストへの変換が使用される場所

同じ基盤となるプロセスが、電子メール、検索とスクレイピング、アクセシビリティ、機械学習というソフトウェアの 4 つのまったく異なる領域に現れます。

それぞれがコンバーターにわずかに異なる問題を解決するように要求します。

実際に変換が実行される場所:

HTML バージョンの隣にプレーンテキストのフォールバックを生成する電子メールシステム
Web スクレイピングパイプラインがクロールされたページから読み取り可能なコンテンツを抽出する
必要最低限のテキストを使用するスクリーンリーダーやその他の支援ツール
クリーンテキストをモデルにフィードする NLP 前処理ステップ

公開 Web をアーカイブする非営利団体である Common Crawl Foundation (EN) は、クロールしたすべてのページからプレーンテキストを抽出し、機械学習専用に構築された個別の WET ファイルに入れます。生の HTML は、WARC ファイル内に別々に存在します。

このプロジェクトの単一の月次スナップショットは 20 億ページ以上をカバーします。これにより、この変換がユーザーの目の前ではなく舞台裏で実行される頻度について、ある程度の規模感が得られます。

アクセシビリティの面では、NVDA は全体的に最も一般的に使用されているスクリーンリーダーであり、WebAIM スクリーンリーダーユーザー調査 #10 (EN) の回答者の 65.6% が定期的に使用しています。

これらのユーザーは皆、直線的なテキストベースの順序でコンテンツを読み取るソフトウェアに依存しています。これは、タグとレイアウトが取り除かれると、HTML からテキストへのコンバーターが生成するものとまったく同じです。

対象読者向けのページ構成に関する詳細なガイダンスは、ほとんどのウェブアクセシビリティ (EN) リソースに記載されています。テキストの順序とセマンティックマークアップは両方とも、スクリーンリーダーがページをどの程度うまく追えるかに影響します。

電子メールには独自の工夫が加えられています。 Apple Mail と Gmail を合わせると、Litmus (EN) によって追跡されるすべての電子メール開封の 90% 近くを占めます。プレーンテキストのフォールバックは、ほとんどの場合、数十の環境ではなく 2 つの環境で正しくレンダリングする必要があります。

HTML からテキストへの変換が適用されない場合

いくつかの特定の状況では、変換が失敗するか、単に意味がありません。

それらを事前に知っておくと、機能しない出力をデバッグする時間を節約できます。

故障箇所:

生の HTML ソースにはコンテンツが含まれないため、JavaScript の実行後にのみ存在するコンテンツ
位置と配置に意味があるレイアウト。財務諸表やフォームが最もわかりやすい例です。
後の再処理のために元のマークアップを保存する必要があるワークフロー
文書の形式が非常に不正であるため、パーサーが使用可能なツリーをまったく構築できない

そのリストの最初の項目は、実際には重要なものです。

W3Techs (EN) によると、JavaScript は現在、すべての Web サイトの 98.9% で実行されています。これらのサイトでは、最初の HTML 応答で送信するのではなく、実際のコンテンツをクライアント側でレンダリングする割合が増加しています。

React や Vue などのフレームワークを使用して構築されたシングルページアプリケーションは、多くの場合、生のソース内の空のシェルとスクリプトタグ以上のものを提供しません。そのソースを指すコンバータは、ほとんど役に立たないものを引き出します。

最初にヘッドレスブラウザを通じてページを取得し、JavaScript が実行できるようにするのが通常の回避策です。この時点で、タスクは単純な変換からページ全体のレンダリングに移行しました。

視覚的なレイアウトは、繰り返し発生する 2 番目の失敗点です。

コンバータは、2 列の請求書を 1 つの行のストリームにフラット化します。列が折りたたまれた瞬間に、品目とその価格の関係が失われる可能性があります。

HTML をテキストに段階的に変換する方法

先ほどのどの方法を選択してもプロセスは同じで、ツールが変わるだけです。

コンテンツに触れる前に、ソースが有効な HTML (EN) であることを確認し、宣言された文字エンコーディングを確認してください。
1 つのファイルにはオンラインツール、スクリプトにはライブラリ、定期的なバッチにはスケジュールされたジョブなど、量に応じた方法を選択してください。
変換を実行し、エンティティがどのように処理されるかを監視します。これは、破損した出力が最初に表示される場所であるためです。
タグ除去の結果を元の結果と比較して、リンク、テーブル、リストが期待どおりに解決されていることを確認します。
最終テキストをソース文書と照合して検証し、特に黙って消えたコンテンツを探します。

ステップ 3 は特に注意が必要です。

エンティティの問題を早期に発見する簡単な方法は、出力内で文字が後に続くリテラルのアンパサンドを検索することです。このパターンは通常、何かのデコードに失敗したことを意味します。

この変換をスケジュールに従って実行するチームは、多くの場合、それを既存の自動化に接続します。 GitHub Actions は、手動でバッチジョブを実行するのではなく、夜間にバッチジョブをトリガーするのに一般的な場所です。

ステップ 5 をスキップすることは、後で戻ってきて人を傷つける最も一般的な近道です。

HTML からテキストへの変換中によくある間違い

変換の問題のほとんどは、少数の繰り返し発生するエラーに遡ります。

どれもエキゾチックではありません。一見すると出力が問題ないように見えるため、見逃してしまうだけです。

間違い	原因	修正方法
二重デコードされたエンティティ	パイプラインでエンティティのデコードを 2 回実行する	一度デコードし、下流で繰り返されないようにステップをログに記録します
文字化け	宣言されたエンコーディングを無視する	解析を開始する前にエンコードを検出または確認する
残ったコードの断片	不完全なスクリプトまたはスタイルタグの削除	テキストノードを抽出する前にスクリプトとスタイルブロックを削除します
サイレントリンク損失	フォールバックなしでハイパーリンクを削除する	URL を破棄せずにインライン化するか脚注を追加します

不正なHTMLは、別の問題を引き起こします。パーサーがエラーを出さずに内容を読み飛ばすことがあるためです。

HTML ビューティファイア (EN)を介して疑わしいマークアップを実行すると、通常は気づかれずに通過してしまう壊れたタグや閉じられていないタグが最初に明らかになります。

二重デコードについては、上の表とは別に、単独でもう一度説明する価値があります。

これは、複数の処理ステージがあるパイプラインで最も頻繁に発生します。前のステージではエンティティがすでにデコードされており、後のステージではそれらをチェックせずに再度デコードします。

この修正は技術的なものではなく手順的なものです。デコードが行われるパイプライン内のすべてのポイントをログに記録し、存在するのは 1 つだけです。

よくある質問：HTMLからテキストへ変換

HTML からテキストへの変換は元のマークアップに戻すことができますか

いいえ。タグ、属性、スタイルが削除されると、その構造情報は永久に失われます。

プレーンテキストファイルには単語のみが含まれるため、マークアップの再作成はタグと書式設定を最初から再構築することを意味し、ロスレスプロセスを元に戻すことはできません。

HTML からテキストへの変換と OCR ベースのテキスト抽出の違いは何ですか

OCR は、スキャンした画像または写真からピクセルを読み取り、表示された文字を推測するため、精度は画質に依存します。

HTML からテキストへの変換では、実際の文字がすでに含まれているマークアップを読み取り、毎回正確で確定的な出力を生成します。

HTML からテキストへの変換で絵文字や特殊な Unicode 文字は保持できますか

はい、ソースドキュメントとコンバーターの両方がUnicode ベースのエンコードを使用している限り、可能です。

エンティティが正しくデコードされる場合、絵文字、アクセント付き文字、および非ラテン文字はそのまま通過します。問題は、コンバータが誤って古い狭いエンコードを想定した場合にのみ発生します。

HTML をテキストに変換すると SEO に影響しますか、または重複コンテンツの問題が発生しますか

直接ではありません。検索エンジンは、後から生成されたプレーンテキストのコピーではなく、ライブページをインデックスに登録します。

重複コンテンツのリスクは、抽出されたテキストが変更や帰属なしにオープン Web 上の別の場所に再公開された場合にのみ発生します。

HTML からテキストへのコンバーターはデフォルトで JavaScript でレンダリングされたページを処理します

ほとんどはそうではありません。標準コンバータは生のソースを読み取るため、後から JavaScript によって挿入されたコンテンツは表示されません。

コンバーターを Puppeteer、Selenium、Playwright などのヘッドレスブラウザ ツールと組み合わせると、最初にページがレンダリングされ、その後抽出が正常に機能します。

一般的なコンバーターがパフォーマンスが低下する前に処理できるファイルの大きさ

ほとんどのライブラリは、数メガバイトまでのドキュメントを問題なく快適に処理します。

深くネストされたマークアップや不正な形式のマークアップでは、パフォーマンスが急激に低下します。パーサーベースのツールは、何かを抽出する前に完全なドキュメントツリーを構築するため、ファイルが大きいほど多くのメモリを消費します。

HTML からテキストへのコンバーターはどこで故障しますか?

HTML からテキストへのコンバーターは、未解決の文字エンコーディング、JavaScript の実行後にのみ存在するコンテンツ、およびパーサーが使用可能なドキュメントツリーを構築できないほど不正なマークアップの 3 つの予測可能なポイントで機能不全に陥ります。

壊れた変換の修正は特定の順序に従い、先にスキップすると、節約されるよりも多くの時間を無駄にします。

最初にソースエンコーディングを確認してください
2 番目に不正なタグまたは閉じられていないタグをチェックします
JavaScript に依存するコンテンツのテスト 3 番目

エンコードの問題により下流のすべての文字が破損するため、構造的な問題が注目される前に問題を分離することで、後で書き直す手間が省けます。

変換前にヘッドレスブラウザ経由でページをルーティングすると、JavaScript のギャップが解消されます。そのトレードでは、完全なテキストと引き換えに、独自のメモリとホスティングコストを備えた低速のレンダリングパイプラインを受け入れます。

読者は逆のワークフローを処理し、書式設定されたドキュメントを公開可能なマークアップに変換し、通常は専用の Word から HTML へのコンバータの隣に移動します。