Pandocの使い方｜MarkdownからWordへ変換し、納品前に構造と版を確認する

こんにちは。『脱会社員』脱サラを応援し続けるブログ、運営者の『なかびー』です。

PandocでMarkdownをWord形式に変換するときは、ファイルができたことだけで納品を終えないようにします。見出しが見出しとして残っているか、表の値が欠けていないか、修正した原稿から今回の出力を作ったかを確認して初めて、受け渡す版を選べます。変換の操作と、内容を確かめる作業を分けるのが基本です。

本記事は、すでにPandocを使える環境がある人が、短い業務メモをMarkdownからDOCXへ変換するための実務ガイドです。新しいソフトの導入、外部の変換サイトへの送信、他人の文書の一括処理は行いません。記法を一から暗記するより、原稿、出力、見た目の基準を別々に残し、直した内容がどこへ反映されるかを確かめます。

変換の目的と完成条件を先に決める

写真は変換と確認の概念イメージです。実際のWord画面や取引実績ではありません。

Word形式にする理由を一つに絞る

Markdownで書いた原稿をWordへ渡す理由には、相手が追記しやすくする、指定の提出形式へ合わせる、担当者が印刷して確認できるようにする、といったものがあります。それぞれ必要な点検は違います。編集用なら見出しや表の構造、印刷用なら折り返しや改ページ、改訂の確認用なら元の原稿との対応を重視します。

今回は、架空の研修について実施条件と配布物をまとめた引継ぎメモを、編集可能なDOCXにする場面を選びます。実在の依頼者や開催予定はありません。相手の社内書式を完全に再現する課題でもなく、四つの見出し、三つの手順、一つの表、二つの補足、脚注を失わずに渡すことを目標にします。

受け渡しの形式がDOCXだけでよいのか、原稿のMarkdownも必要なのかも先に決めます。DOCXだけを求められた相手に、変換用のファイルをすべて渡すと、どれを開けばよいか分からなくなります。一方、継続して再生成する担当者へは、元原稿と変換条件がなければ引継ぎに不足します。同じ成果物でも、相手の役割で渡す範囲を変えます。

原稿の内容と書式の責任を分ける

変換ツールは、書いてある日時が依頼どおりか、配布枚数の計算が正しいかを判断しません。今回の例なら参加者八人に演習紙を二枚ずつ配るので十六枚ですが、原稿に十二枚と書いても、その誤りを自動で修正してくれるとは限りません。計算と文意は作者が確かめ、変換後はその確かめた値が保たれているかを見ます。

同様に、見出しに指定した言葉が適切かどうかも別の判断です。「確認メモ」の下に実施日と人数が混ざっていれば、書式がきれいでも読む順番が分かりにくくなります。内容を整理してから変換すれば、出力の不具合と原稿の構成不足を分けやすくなります。変換結果を見ながら無計画に見出しを増やすより、最初に項目の役割をそろえましょう。

今回の完成目印は、文書名一つと主要見出し四つ、番号付き手順三項目、箇条書き二項目、三列の表一つ、脚注一つ、参考リンク一つです。表は見出し行を含め四行、合計十二セルあります。これらは万能なチェック項目ではなく、この原稿のための確認リストです。自分の文書では必要な要素に置き換えます。

1. 原稿の内容と完成条件を確定する。
2. 原稿を残して別名のDOCXを生成する。
3. 構造と数値、表示を照合する。
4. 修正を正本へ戻し、渡す版を確認する。

長い文書を最初から対象にすると、どこで崩れたのか分かりにくくなります。まず一ページ程度の原稿で、よく使う構造が変換できることを確かめます。短い教材で成功しても大きな文書の品質を保証するわけではありませんが、入力形式や作業場所の基本的な誤りを小さい範囲で切り分けられます。

変換で保たれるものを過信しない

公式ガイドは、形式の間で表現できる範囲が異なり、すべての変換で細かな書式まで完全に一致するわけではないと説明しています。複雑なレイアウトや特殊な表を、そのまま別形式へ移せると決めつけないでください。今回のような段落、見出し、単純な表から始めると、失敗時に原稿と出力を対応させやすくなります。

特に「元の画面と同じ」が必要な仕事では、何を同じにするかを具体化します。文章と数値が同じなのか、ページ数や改ページも固定なのか、指定フォントが必要なのかで確認方法が変わります。見た目の固定が最優先なら、編集できるDOCXだけで要件を満たすかを依頼者と確認する必要があります。ここでは形式変更を勝手に提案して送付するのではなく、条件を整理する段階にとどめます。

入力する文書に個人情報や取引上の秘密がある場合、試験用にそのまま使う必要はありません。まず架空の名前や日付で作った原稿で手順を確かめます。ローカルで動く道具でも、文書内の外部画像や追加処理の設定によって外部アクセスが関係することがあります。今回の教材には外部画像も追加フィルターも含めず、リンクは参照先の文字列として置いています。

入力ファイルと出力先を取り違えずに準備する

写真は変換と確認の概念イメージです。実際のWord画面や取引実績ではありません。

作業用のフォルダーを一つ用意する

練習では専用のフォルダーを作り、その中に原稿と出力を置きます。既存の納品フォルダーや共有先を試験場所にすると、同名ファイルを上書きしたり、未確認の版が相手から見えたりするおそれがあります。ファイルを一つ生成できるか試すだけなら、実際の提出先を使う理由はありません。

今回の原稿名はsource-v1.md、初回の出力はoutput-v1.docxです。後で内容を変更した原稿はsource-v2.md、出力はoutput-v2.docxとしました。短い名前に版を含めることで、どの原稿を使ったかを対応させています。これは本記事の練習用の命名であり、実案件では合意した命名規則を優先します。

※表は横にスクロールできます。

同じフォルダーに見えるファイルでも、拡張子が隠れていると正しく見分けられないことがあります。source-v1.md.txtのようにテキスト用の拡張子が重なると、想定と違う入力として扱う場合があります。名前の末尾まで確認し、エディターで開いた内容が今回の原稿と一致しているかを見ます。拡張子を変えただけで中身が別形式になるわけではありません。

原稿の文字コードもそろえます。今回の教材はUTF-8で保存しました。日本語が崩れるときは、変換の前にテキストエディターで原稿そのものが読めるかを確認します。入力時点で文字が置き換わっているなら、変換後のWord側だけを直しても元の問題は残ります。元ファイルを保持したまま、正しく読めるコピーを使う方が原因を追いやすくなります。

コマンドを実行する場所を確かめる

コマンドにsource-v1.mdとだけ書く場合、実行している場所からそのファイルを探します。エディターで原稿を開いているからといって、端末の作業場所も同じとは限りません。見つからないエラーが出たら、入力名の打ち直しを繰り返す前に、現在の場所と原稿の保存場所を照合します。

Windows、macOS、Linuxでは、フォルダーへ移動する画面やパスの書き方が異なります。本記事の例は、原稿のあるフォルダーで実行する前提です。別の場所から実行したい場合は、入力と出力の位置を明示し、空白のあるパスを適切に引用符で囲みます。自分の利用環境で表示されたパスを使い、記事中の例を実在の場所だと取り違えないようにします。

変換の前にはpandoc –versionで利用中の版を確認できます。ここに表示された版を作業メモへ残すと、別の環境で結果が違ったときの比較材料になります。今回使った3.1.11.1は既存環境の版であり、最新であるという主張ではありません。現在の公式マニュアルにある機能がすべて同じように使えるとは限らないため、必要なオプションが受け付けられるかも確認します。

入力と出力の形式は、例では-f markdownと-t docxで明示します。短いコマンドだけを覚えるより、どの部分が入力の解釈で、どの部分が出力形式なのかを理解しておくと、エラーの切り分けがしやすくなります。出力先を指定する-oの後ろに原稿名を入れないよう、実行前に左右を読み直してください。

成功の表示と保存先を別々に読む

端末に何も表示されず処理が終わる場合もあります。逆に警告が表示されても出力ファイルが作られることがあります。どちらも、その場の印象だけで品質を決めないようにします。処理が終了したか、予定した場所にファイルがあるか、そのファイルの中身を開けるかを順番に確認します。

失敗したコマンドを修正するときは、出力ファイルが残っているかにも注意します。前回の成功ファイルが同名で残っていれば、今回失敗していてもそれを開けてしまいます。初回と再試行で出力名を分ける、更新時刻と内容を照合するなど、今の実行で作られたものかを見分ける方法を持ちます。開けたという事実だけでは新しい結果と判断できません。

架空の研修メモを変換し構造を照合する

写真は変換と確認の概念イメージです。実際のWord画面や取引実績ではありません。

原稿の中身を先に数える

教材の題名は「架空研修の引継ぎメモ」です。主要項目は実施条件、当日の手順、配布物、確認メモの四つにしています。最初の版では開催日を2026年10月20日、参加人数を八人と書きました。後の版では開催日だけを21日へ変え、人数や配布物は変更しません。この一か所の差を使って、修正が出力へ届いたかを確認します。

配布物は、案内紙が一人一枚で合計八枚、演習紙が一人二枚で合計十六枚、振り返り紙が一人一枚で合計八枚です。合計は三十二枚となります。表の合計欄と本文の合計を別々に計算してそろえます。ここでは予備を含めていないことを脚注にし、数だけ見て実際の印刷枚数を決めないようにしています。

番号付きの手順は、資料の版を確認する、受付用の机を準備する、終了後に配布物を数える、の三項目です。箇条書きでは、配布用と控え用を混ぜないこと、未確認の項目は未確認と書くことを補足しています。順番のある作業と、順番のない注意を分けるため、どちらも同じ記号で並べない構成にしました。

参考リンクはPandocの公式案内一つです。リンク文字が見えることと、参照先が正しいことは別なので、DOCX内に残ったリンク先も照合します。この教材の変換で、リンク先のページを取得して文書へ埋め込んだわけではありません。ウェブページの文字列をそのまま本文として取り込む操作とは区別します。

※表は横にスクロールできます。

練習用の原稿全文

---
title: 架空研修の引継ぎメモ
lang: ja-JP
---

# 実施条件

この文書は変換確認のための架空教材です。実在する依頼や開催予定ではありません。

開催日：2026年10月20日。参加人数：8人。

# 当日の手順

1. 資料の版を確認する
2. 受付用の机を準備する
3. 終了後に配布物を数える

# 配布物

| 品目 | 一人分 | 合計 |
| --- | ---: | ---: |
| 案内紙 | 1 | 8 |
| 演習紙 | 2 | 16 |
| 振り返り紙 | 1 | 8 |

- 配布用と控え用を混ぜない
- 未確認の項目は空欄ではなく未確認と書く

# 確認メモ

合計は32枚です。[^note]

参考リンク：[Pandocの公式案内](https://pandoc.org/getting-started.html)。

[^note]: 予備分は含めない架空の計算です。

小さな出力を作って開く

初回はpandoc source-v1.md -f markdown -t docx -o output-v1.docxとして変換します。入力は一つ、出力も一つなので、まずはこの対応を確認します。まだ複数ファイルの結合や追加処理を入れません。操作を増やさない方が、変換結果が予想と違うときに原因を絞れます。

pandoc source-v1.md -f markdown -t docx -o output-v1.docx

DOCXができたら、文書名、日付、人数、配布物、合計を原稿と見比べます。読み慣れた文章は誤りを見落としやすいため、まず数字や固有の目印から確認します。今回なら20日、八人、八枚、十六枚、八枚、三十二枚の順に追えます。文章全体の読みやすさは、その後で改めて読みます。

見出しは大きく見えるだけでなく、文書の見出しとして扱われているかも点検します。今回のDOCX内部では四つの主要項目に見出し用のスタイルが対応していました。これは構造の確認であり、Wordのナビゲーション画面を実際に操作したという意味ではありません。利用するWordで編集や移動に使うなら、その画面でも確認してください。

表も同じです。目で見て三列に並んでいても、実際には空白で区切った文字列かもしれません。今回の生成物では表が一つあり、見出し行を含めた十二セルの値が原稿と一致することを確認しました。表の編集が必要な納品では、受取人が行を増やしたり数値を書き換えたりできるかも、使うアプリで試す項目になります。

脚注とリンクを本文から切り離さない

脚注は本文中の印と、ページ下部などに出る説明が対応して初めて意味を持ちます。三十二枚という合計の後に印があり、予備を含めない架空計算という注が一つあることを確認します。脚注だけが消えれば、数字の条件が変わって伝わります。小さい文字だから後回しにせず、本文の根拠として点検しましょう。

リンクでは、表示名と参照先を確認します。表面に「Pandocの公式案内」と表示されていても、別のURLへ向いていれば内容と一致しません。実案件のリンクにアクセスする際は、その権限や共有範囲も別途確認します。本文にURLが入っていることだけで、受取人がアクセスできる状態になったわけではありません。

今回の構造点検では、番号付きと箇条書きを合わせて五つのリスト段落、脚注一つ、表一つを確認しました。表示画像でも日本語の主要部分と表、脚注を読み取れました。ただし、画面読み上げやキーボード移動、すべてのWord版の表示は試していません。検査した項目を限定して残す方が、次の担当者が未確認の部分を判断できます。

表のセル数が合っていても、文章が長くなればはみ出しが起きることがあります。教材の短い品目では収まっても、本番の品目に長い説明を入れたら別の検査が必要です。行を増やしたときの改ページ、列幅、数字の折り返しを実際の内容で見直します。小例の成功は、確認の手順を作るための土台と考えます。

参照用のDOCXで見た目を整える

写真は変換と確認の概念イメージです。実際のWord画面や取引実績ではありません。

内容の原稿とは別に書式の基準を持つ

同じ原稿から、本文の文字サイズや見出しの大きさをそろえたDOCXを作りたいときは、参照用のDOCXを使う方法があります。本記事ではreference-custom.docxという別ファイルにして、原稿のsource-v2.mdと区別しました。どちらも文書に関係するファイルですが、役割は同じではありません。

今回の参照文書は、Pandocが用意する既定の参照用ファイルを出力し、本文や見出しのスタイルを調整して作っています。公式ガイドに沿った出発点を使うと、どの設定を変えたか追いやすくなります。手元にある複雑な納品済み文書をそのまま指定して、すべての装飾が再現されると期待するより、小さい変更で確認します。

pandoc -o reference-default.docx --print-default-data-file reference.docx
# 既定の参照文書を複製し、必要なスタイルを調整して別名保存
pandoc source-v2.md -f markdown -t docx --reference-doc reference-custom.docx -o output-v2.docx

参照文書の本文へ試しに「参照文書だけにある追加文章」という一文も入れました。変換後のDOCXには、この一文は入りませんでした。これは、書式の基準に使うファイルの本文と、変換したい原稿の本文を混同しないための教材です。実際に追加したい案内文は、元原稿の適切な場所へ書きます。

参照用ファイルに会社名や個人情報が含まれていないかも確認します。題名を変えただけの既存文書には、ヘッダーやフッター、プロパティなどに以前の情報が残ることがあります。自分に利用権限がある基準ファイルを使い、不要な情報を持ち込まないようにします。他人の指定書式を改変してよいか不明な場合は、勝手に変えず確認が必要です。

一度に多くの書式を変えない

今回調整したのは、本文と見出しなどのフォント、色、サイズです。日本語用のフォント指定も含め、生成後の表示画像で文字が読めることを確かめました。ここで使えたフォントが受取人の環境にもあるとは限りません。フォントが置き換われば行の長さやページ数も変わるため、納品先での表示は別の確認として残します。

書式を直す際は、本文だけ、見出しだけというように変更箇所を絞ります。すべてを同時に変えると、どの設定で表が次のページへ移ったのか分からなくなります。まず一か所変えて再生成し、内容が同じまま見た目だけが変わったかを見ます。原稿の日付なども同時に直す場合は、内容差分と書式差分を別に記録します。

コマンドでは–reference-doc reference-custom.docxを指定して、どの基準を使うか明示します。ファイル名を入力しただけでは、意図した場所のものを読めたか分からないことがあります。似た名前の参照文書が複数あるなら、専用フォルダーへまとめ、古い版を誤って指定しないようにします。基準の名前だけでなく、その中身の変更履歴も必要です。

本文を大きくした結果、表や脚注が次ページへ移っても、変換エラーとは限りません。読みやすさとページの収まりを両方見て調整します。一ページに無理に詰めるため本文を極端に小さくするより、必要な内容が読めることを優先します。ページ数を固定する条件がある場合は、余白や項目構成を含めて別途検討します。

元原稿と参照文書のどちらを直すか判断する

例えば、表の「演習紙」を「演習シート」へ変えたいとします。出力だけの置換で済ませると、元原稿には古い品目名が残ります。後日人数を変更して再生成したとき、古い呼び方が復活するかもしれません。今回のようにMarkdownを原稿の正本として扱うなら、品目名を原稿へ反映し、そこから出力し直す方が再現できます。

一方、受取人がWord上で大幅に編集していく段階へ移るなら、いつからDOCXを正本にするかを合意する方法もあります。MarkdownとWordを両方同時に編集し続けると、どちらが最新か分からなくなります。変換の便利さを保つことより、実際に修正する人が迷わない運用を優先しましょう。正本の切替えは、ファイルが生成されたというだけでは自動で決まりません。

修正した原稿から新しい版を作り直す

写真は変換と確認の概念イメージです。実際のWord画面や取引実績ではありません。

一か所の修正で反映先を確かめる

教材の第二版では、開催日を10月20日から10月21日へ変更しました。人数八人、表の品目と枚数、手順や脚注はそのままです。原稿を別名で残し、第二版の出力も別名にしたので、第一版と見比べられます。最初に変更点を一つに絞ると、反映漏れと予期しない変更の両方を確認しやすくなります。

出力された第二版では、本文に21日があり、20日がそのまま残っていないことを確認します。文書によっては日付が題名、本文、表、ヘッダーなど複数箇所にあります。今回は本文の一か所ですが、本番では変更対象を一覧にして、必要な場所をすべて確認します。一か所直したから文書全体も一致したはずだとは判断しません。

変更しない項目も重要です。開催日だけを直したのに人数が変わっていれば、別の原稿を使った可能性があります。八人、配布合計三十二枚、主要見出し四つ、表一つなど、維持する条件を一緒に照合します。差分がある場所だけでなく、変えてはいけない場所が保たれているかも見るのが改訂確認です。

※表は横にスクロールできます。

出力だけを直したときの扱いを決める

出力DOCXを開いた後、誤字に気付いてその場で直すことはあります。その修正を次回にも残したいなら、正本へ戻す工程が必要です。Markdownを正本にする運用では、Word側で直した内容を原稿にも反映し、再生成して一致を確認します。手元で直したファイルをそのまま別名保存しただけで、原稿まで更新されたことにはなりません。

今回の教材では、Word上の直接編集操作は実施していません。したがって、変更履歴の追跡やコメント承認がどのように見えるかを検証済みとはしていません。そうした機能を必要とする仕事では、受取人が使うWordの機能と運用を別に確かめる必要があります。本記事の単純な再生成試験と、校閲業務の確認を混ぜないでください。

受取人から修正版が戻ってきた場合も、まず対象の版を確認します。「最新版を直しました」という返答だけでは、自分が最後に送ったものと同じか分からないことがあります。元のファイル名、送った日付、相手の修正箇所をそろえ、取り込む内容を判断します。まだ合意していない修正を、機械的に正本へ反映することは避けます。

差分の確認では、表の数値だけでなく、否定や条件の語にも注意します。「予備を含めない」が「予備を含める」に変われば、三十二枚という数字の意味が変わります。文字数が一字違うだけでも、意味は大きく変わります。自動比較が見つけた箇所を、担当者が文脈と合わせて読む工程を省かないようにします。

出力先を固定し過ぎない

毎回同じoutput.docxへ上書きすると、受渡し済みの版を後から確認できなくなることがあります。少なくとも練習段階では、版ごとに原稿と出力を残す方が安全です。実務で上書き運用をするなら、履歴やバックアップがどこに残るかを確認し、復元できることを前提にした管理を考えます。履歴があると思い込んで古い版を消さないでください。

フォルダーにファイルが増えたら、作業中と受渡し候補を分けます。候補フォルダーには、確認対象を絞って置くと誤送信を減らせます。ただしファイルを移動すると、画像や参照文書への相対的な位置関係が変わる場合があります。再生成に使う一式を移すなら、移動後も同じ条件で出力できるかを確認します。

今回は原稿に画像を含めていないので、画像埋め込みや配置は教材の検証範囲に入りません。自分の原稿に画像を入れる場合は、ファイルの場所、利用権限、代替テキスト、出力での大きさを追加で点検します。リンク文字列が保持されたことを、画像が正しく埋め込まれた証拠として扱わないことが重要です。

納品前に内容と表示を開き直して確認する

写真は変換と確認の概念イメージです。実際のWord画面や取引実績ではありません。

構造検査と目視を組み合わせる

構造検査では、見出しの数、表の行列、セルの文字、脚注やリンクの存在を確かめられます。今回の教材でも、この方法で原稿の主要要素を照合しました。一方、行間が詰まり過ぎていないか、表の右端が切れていないか、脚注が読みにくくないかは、実際の表示を見る方が適しています。どちらか一方だけで完成とはしません。

フォントが変わると、同じ文書でも行の折り返しやページ数が変わることがあります。自分のPCで一ページだったことを、相手のPCでも一ページになる保証にしないでください。指定フォントやページ数の条件がある場合は、受取人側の環境も含めた点検が必要です。今回は小さい教材の範囲で読みやすさを確認しています。

表示を確認するときは、文書の最初だけでなく最後まで見ます。表や脚注が後ろへ押し出され、末尾に一行だけ残ることもあります。印刷して使うなら、印刷プレビューでページの境目を確認します。編集用なら、表のセルへカーソルを置けるか、見出しを適切に変更できるかも、対象アプリで試す項目になります。

• 本文・表・脚注の文字が読めるか。
• 改ページや端の切れがないか。
• 編集が必要な要素が構造として残っているか。

渡すファイルを最後に選び直す

確認したファイルと、送信画面で選んだファイルが同じかを最後に照合します。似た名前の第一版と第二版が並んでいると、正しい内容を確認していても古い方を選ぶことがあります。ファイル名だけでなく、文書内の日付などの識別しやすい箇所を開き直し、今回渡す内容かを確かめます。

相手へ伝える説明は、何を渡すかと、何を確認してほしいかに絞ります。例えば、開催日を21日に変更した編集用メモであり、人数と配布数は変えていないこと、利用環境での表示確認が必要なことを分けて書けます。これは説明文の考え方であり、本記事の教材を実際の依頼者へ送ったわけではありません。

内部の試験ログや参照文書を、必要がない相手へ一緒に渡す必要はありません。教材を再現する担当者には役立つ記録でも、当日の運営担当者には最終メモだけで十分な場合があります。内容、共有先、編集権限を確認し、目的に合う最小限の一式を選びます。渡してよい相手が不明な文書は、そのまま外部へ送らないでください。

ファイル名に「最終」と付けることだけでは、確認が済んだ証拠になりません。作成、検品、承認、送信は別の状態です。未承認のものは候補として扱い、相手の返答が必要なら完了扱いにしないようにします。変換作業を速くできても、その後に必要な判断まで自動で済むわけではありません。

次回のために再現条件を残す

再生成する可能性があるなら、元原稿、使った参照文書、コマンド、Pandocの版を残します。さらに、どの出力を確認したかと、確認していない点も短く記録します。今回なら、日付変更、四見出し、一表十二セル、五リスト段落、一脚注の一致と、別エンジンでの一ページ目視が実施済みです。Word操作、画像埋め込み、アクセシビリティ検査は含みません。

• 元原稿と参照文書の版。
• 実行したコマンドとPandocの版。
• 確認した出力と、未検証の項目。

記録を残す目的は、すべての操作を長文で保存することではありません。次に困ったとき、原稿の問題なのか、参照書式なのか、出力の取り違えなのかを判断できるようにするためです。手順書に関係のない個人名やパス、秘密情報まで残す必要はありません。再現に必要な情報と、不要な情報を分けます。

初めての文書でうまくいったら、次は表の行を一つ増やす、長い項目名にする、見出しを一段増やすなど、実際に必要な変化を一つずつ試します。今回使っていない機能を、成功した教材の範囲に含めないようにします。複雑さを増やした分だけ、対応する検査項目も増やすのが無理のない進め方です。

PandocでWord形式を作る作業は、コマンド一行だけで完結するものではありません。元原稿を確定し、出力先を区別し、構造と表示を確かめ、修正を正本へ戻してから渡す版を選びます。この順序が整えば、形式変換のやり直しや古い版の取り違えを減らし、相手が使いやすい文書へ仕上げやすくなります。

記法そのものを確認したい場合は、Markdownの基本と表示先の違いへ戻れます。原稿と出力の版名を決めるときは、ファイル名のルールと同名衝突の確認も参考にしてください。

公式の操作根拠：Pandoc公式ユーザーガイド、Pandoc公式 Getting started、Pandoc公式 Demos。本記事の独自教材の数値・生成結果は、本文で示した実行環境と検査範囲に限ります。