AI Markdown入門から基礎編　基本文法を実務で使ってみよう

はじめに

生成AIを業務に活用しようとすると、最初にぶつかる壁は「モデルの性能」ではなく「ファイル形式」にあります！という記事を前回書きました。

AITC | AI TRANSFORMATION CENTER

AI Ready Data　生成AI活用のボトルネックはファイル形式にある

🕒️2026年2月12日

Markdown（マークダウン）が生成AI活用には効きやすく、Excel／PowerPointが詰まりやすい理由を、ファイル形式の特性から整理しました。

その理由を一言で言えば、Markdownは文章の構造がテキストとして明示されるため、生成AIが読み取りやすく、検索（RAG）や再利用の前提データとして扱いやすい、という点にあります。

では、そのMarkdownを実務でどう書けば「AI Ready」になるのでしょうか？

ここを押さえないと、せっかくMarkdownに寄せても、見出しの切り方や箇条書きの作法次第で、AIが取り違えたり、必要な情報に辿り着けなかったりします。

そこで本記事では、Markdownの基本文法を、実務で使える形で説明したいと思います。

対象を具体化した方がイメージしやすいと思いますので、題材は製造業のエンジニアリング／オペレーション領域をターゲットにします。手順書、点検記録、不具合報告、変更管理、設計レビュー議事録、品質監査メモといった「文章資産」を、AIが理解・検索・要約しやすい形に整えるためのMarkdown基礎を、現場の例で解説します。

ただし、ここで扱う考え方は製造業に限りません。規程・手順・FAQ・各種報告・議事録・形式知文章など、文章が業務を支える業種であれば同じように効きますので、製造業以外の方も自分の業務文書に置き換えながら読み進めてください。

改めてMarkdown（マークダウン）とは？

Markdownは、プレーンテキストに最小限の記号で「構造」を付ける軽量マークアップで、2004年にJohn Gruberが提案し、いまや広く使われています。WordのようなWYSIWYG（ウィジウィグ：What You See Is What You Get＝「画面に見えているままが、そのまま完成結果になる」仕組み）と違って、HTMLのように、文章の中に記法を書いて構造化します。結果として、移植性が高く、将来も読める形式として扱いやすいのが特徴です。

Markdownは多くのアプリで基本文法が動きますが、各アプリや環境ごとに、細かな差分があります。

この基礎編では「ほぼどこでも問題なく理解される」書き方を説明します。

製造業のSOP（標準作業手順書）を題材に、文法を“現場文書の形”で覚える

Markdownの文法は、単体で覚えるよりも「実際に書く文書の型」を前提にした方が定着します。

そこで今回は、製造業のSOP（Standard Operating Procedure：標準作業手順書）を題材に、見出し・箇条書き・強調・リンクといった基本文法を、SOPを完成させていく流れで説明します。読み終わったときに、手順書だけでなくほかのドキュメントにも適用できるような内容を目指したいと思います。

まずは「最低限この形にしておけば、AIが読み取りやすく、人も運用しやすい」SOPの最小テンプレを置きます。以降の章は、このテンプレの各要素をMarkdown文法として分解しながら解説します。

すぐ使えるSOPテンプレ

# 手順書タイトル（SOP-XXX-000）
## 目的
（この手順で何を達成するか）
## 適用範囲
- 対象ライン：
- 対象設備：
- 対象ロット／条件：
## 安全上の注意
- （保護具、停止条件、禁止事項）
## 手順
1. （作業）
2. （作業）
3. （確認）
   - 判定基準：
## 記録すべき項目
- アラームコード：
- 設備ID：
- ロット：
- 写真： ![何が写っているか](/img/xxx.jpg)
## 関連資料
- [図面](https://example.com/...)
- [変更申請](https://example.com/...)

見出し：文章に“骨格”を入れる

SOPの文章は、人が読むときは「見出し」を頼りに目的・安全・手順・記録といった必要箇所を素早く探します。見出しが正しく入っていると、生成AIが文書を意味のまとまり（章・節）として分割しやすくなり、「どの話がどの章に属するか」を取り違えにくくなります。

逆に、見出しがない／階層が崩れていると、目的と手順、注意事項と例外条件が混ざって扱われ、検索で引っ掛かっても回答がズレる原因になります。

Markdownの見出しは、行頭の # の数で階層を表します。

# ：文書全体のタイトル（SOPのタイトル）
##：章（目的、適用範囲、安全上の注意、手順…）
###：節（対象設備、判定基準、例外条件…）

実務では、「タイトル＝#」「章＝##」を揃えるだけで、AIが読みやすい構造になります。

ポイントは、「人が読みやすい章立て」と「AIが分割しやすい章立て」が一致させることです。まずはSOPの見出しだけでも整える、これがAI Ready化の最短ルートになります。

例：

# ライン停止時の一次対応手順（SOP-OPS-012）
## 目的
停止時間を最小化し、安全を担保しつつ一次切り分けまで実施する。
## 適用範囲
- 対象ライン：Line-A
- 対象設備：`Vision-02`、搬送コンベア
- 対象条件：夜勤帯／湿度60%以上 など
### 対象設備
- 搬送コンベア（Line-A）
- 画像検査装置（`Vision-02`）

段落：空行が段落の区切り

Markdownでは、文章のまとまり（段落）は「空行」で区切ります。

ここでいう空行は、ただ改行するだけではなく、1行まるごと何も書かれていない行が入っている状態です。

なぜこれが大事かというと、SOPや不具合報告では「事実」「推測」「手順」「注意」「例外条件」など、意味の異なる情報を混ぜると読み違いが起きるからです。

段落で区切っておくと、人間はもちろん、生成AIも「ここから話題が切り替わった」「別の観点の情報だ」と判断しやすくなり、要約やRAGでの引き当てが安定します。

よくある失敗：改行したつもりが“同じ段落”になっている

Markdownでは、単に行を変えただけ（改行だけ）だと、多くの環境で「同じ段落の中の折り返し」として扱われます。

つまり「別の話に移ったつもり」が伝わらず、抽出・要約で混ざりやすくなります。

段落を切り替えたいときは、必ず空行を入れるのが基本です。

もう1つの注意：先頭の空白（タブ／スペース）を入れない

Wordやメモ書きのクセで、段落の先頭をタブやスペースで字下げすると、Markdownでは「コードブロック」や「特別な整形」と誤解されることがあります。

そうなると、見た目も検索も崩れ、AIも「これは本文ではなくログ／コード」と判断して文脈を外すことがあります。 基本は左揃え（行頭に余計な空白を入れない）で書きましょう。

例：

不具合の再現条件は「湿度60%以上」「夜間帯」「材料ロットL2409」のときに偏る。
現場では、当該条件での段取り替え直後にエラー頻度が上がるという観察がある。

この例では、1段落目が「再現条件（事実・条件）」、2段落目が「現場観察（追加情報）」として分かれます。こうしておくと、AIが「再現条件」は1段落目だとわかるため、AIが回答を組み立てるときも混線しにくくなり、回答精度が高まります。

強調：重要語を目立たせる

SOPや品質ルールは、読み手が急いでいるほど「太字」「斜体」などの視覚的な手掛かりに頼ります。生成AIも同様で、強調されている語は「重要な条件・禁止事項・例外条件」として扱いやすくなります。

ただし、強調を多用すると逆に重要度が分からなくなるので、現場文書では「本当に重要な箇所」だけに絞るのがコツです。

太字（最優先事項・必須条件）

太字は **...**（または __...__）で表します。

SOPでは、次のような用途が向いています。

• 安全に関わる必須条件（例：安全柵、保護具、停止条件）
• 品質事故につながる禁止事項（例：混入リスク、異物混入、NG条件）
• 判定基準の閾値（例：3.0mm/s以上は停止）

例：

注意：この手順は **安全柵を閉じた状態** で実施すること。

斜体（用語の強調・現場用語）

斜体は *...*（または _..._）で表します。

SOPでは「用語として強調したい」「呼び名を明確にしたい」程度に使いましょう。

例：

混入リスクがあるため *エアブロー* は禁止。

実務上のおすすめ：基本は **太字**、斜体は控えめに

強い注意喚起（must／禁止）を伝えたいときは、表現を 太字（...） に寄せるのが適切です。

重要度の高い指示が埋もれにくくなります。一方で、斜体は多用せず、「用語」や「呼称」といった言葉そのものを強調したい場面に限定すると、文章全体のトーンが安定します。

また、強調表現には __...__ や _..._ も使えますが、単語の途中に入る場合や、記号・ID（例：ABC_123 のようなもの）が混ざる場合は、表示環境によって解釈が揺れることがありますので、アスタリスク記法（...／...）を選ぶのが無難です。私は通常アスタリスクを使用します。

引用：現場の声や暫定見解を“本文”と分けて残す

不具合対応やSOPの周辺資料では、「確定した事実」と「現場の観察（肌感）」「暫定の仮説」が混ざりがちです。ここが混ざると、後から読み返した人（や生成AI）が、仮説を事実として扱ってしまう事故が起きます。

そこで使うのが引用です。Markdownでは行頭に > を付けると、その段落が「本文とは別枠（引用）」として表示されます。

現場コメント、ヒアリング内容、暫定結論、未確認情報などを引用に寄せると、「これはメモ／見解で、確定事項ではない」という境界が明確になります。

例：

発生状況：ライン停止は夜勤帯に偏って発生している（過去2週間のログより）。
> 現場コメント：夜勤帯に限って、ワークの反りが大きいロットで詰まりやすい。
> 温調の立ち上がりが影響しているかもしれない（未検証）。

たとえばこの形式で記述しておくと、構造が自然に二層に分かれます。1行目には「ログに基づく事実」を置き、続く引用ブロックには「現場の観察／仮説（未検証）」をまとめる。こうすることで、読む人にとっても「確定している情報」と「まだ確証のないコメント」が一目で判別できます。

さらにRAGで検索・参照する場面、AIが“確定事項”と“コメント”を切り分けて解釈しやすくなり、回答生成時に仮説を事実のように扱ってしまうリスクを下げられます。結果として、検索精度だけでなく、出力の信頼性や説明の透明性も上がります。

リスト：手順書・点検・切り分けに直結する主役

製造業の文書で一番出番が多いのがリストです。

SOP、点検表、一次切り分けは「順番」と「抜け漏れ」が重要なので、文章でだらだら書くより、リストにした方が人もAIも正しく理解できます。RAGでも、リストは手順が分割されて取り出されやすく、「手順だけ」「確認項目だけ」を回答に使いやすくなります。

番号付きリスト：順番が重要な手順に使う

行頭を 1. のように「数字＋ピリオド」で書きます。
Markdownでは数字が連番でなくても表示上は連番になる環境が多いのですが、運用上は 1から順番に書く のが一般的です。

番号なしリスト：確認項目の列挙に使う

行頭を -（または * / +）で書きます。
点検項目や観点の列挙など、「順番より漏れなく並べること」が大事なときに向いています。

ネスト（入れ子）：手順の中に“確認項目の束”を入れる

手順のあるステップの下に、具体的な確認項目をぶら下げたいときは、空白でインデントして下位のリストにします。

例：

1. 安全確認（非常停止解除前に周囲確認）
2. アラームコードを記録（HMI画面の履歴も保存）
3. 次を順に確認する
   - センサ汚れ（光電、近接）
   - エア圧（0.5MPa以上）
   - ワーク詰まり（搬送部の目視）
4. 復旧できない場合は保全へエスカレーション

この書き方にすると、
1〜4は「実行順序がある手順」
3の下の箇条書きは「3番で確認すべき項目」
と切り分けられます。

このように、リストを上手く活用することで、現場での読み間違いが減り、AIに渡しても「手順の順番」と「チェック観点」が混ざりにくくなります。

コード：タグ名・パラメータ・ログを“そのままの文字列”として守る

製造業の文書には、PLCタグ、アラームコード、設備ID、設定値、ログ行など「1文字でも違うと意味が変わる情報」が頻繁に出てきます。

ところが通常の文章として書くと、記号や空白が詰まったり、環境によって装飾扱いされたりして、検索で一致しにくくなることがあります。

そこでMarkdownでは、こうした“正確さが重要な文字列”を コードとして書くのが基本です。コードとして書くと、記号や空白を含めても「そのまま表示する」扱いになり、誤読や崩れを防げます。

インラインコード：文中にタグ名や値を埋め込む

1語〜1行程度の短いトークン（タグ名、設定値、コマンドなど）は、バッククォート(')で囲みます。

例：

PLCタグ `MTR_A01_RUN` がONなのに回転数が0のままの場合、インバータ側を疑う。

この書き方にすると、MTR_A01_RUNが“装飾”として解釈されず、タグ名としてそのまま残ります。検索でも MTR_A01_RUN で確実に当たりやすくなります。

コードブロック：ログや設定を複数行でそのまま貼る

ログやコンソール出力のように複数行を載せたいときは、コードブロックにします。基礎編では「各行を4スペース（またはタブ）でインデント」する方法が扱いやすいです。

例：

    [2026-02-15 09:14:22] ALM=E231  Axis=Z1  Temp=74.2
    [2026-02-15 09:14:23] ALM=E231  Axis=Z1  Temp=74.5

コードブロックにしておくと、

• 空白の位置が崩れないいう
• 日付・キー・値の並びがそのまま残る
• ログ部分だけをそのまま抜き出して共有できる

といったメリットがあります。

例外：バッククォート（`）そのものを表示したいとき

たとえば「ls という文字列」をコードとして見せたいなど、コードの中にバッククォートが含まれる場合は、外側を二重バッククォートで囲んで逃がせます。

例：

`` `ls` `` を実行する。

区切り線：章の境目をはっきりさせる

SOPや不具合対応メモでは、「発生状況」「一次対応」「暫定対策」「恒久対策」「再発防止」のように、話題が大きく切り替わるポイントがあります。

この切り替えが本文の流れだけだと、生成AIが前後を同じ話としてまとめてしまったりします。

そこで使うのが区切り線です。Markdownでは "--- "を1行だけ置くと、水平線（区切り線）として扱われます。

見出しだけでも章立てはできますが、区切り線を入れると「ここで話が切り替わる」ことが構造的に明確になります。

書き方の作法（崩れにくくする）

Markdownで区切り線（水平線）を使うときは、ルールを2つだけ押さえておきましょう。

まず、"---"は 必ず単独の行 に書きます（同じ行に他の文字を混ぜない）。文字や記号が一緒に入ると、見た目どおりに区切り線として解釈されないことがあります。

次に、"---"の 前後には空行を入れます。本文や箇条書きと隣接すると、意図せず見出し扱いになったり、リストの一部として解釈されたりして表示が崩れることがあります。

どのような場合に使うと効くか

区切り線が本当に効くのは、「文章の流れを止めずに、読み手の頭を切り替えたい」ときです。見出しを増やすほどでもないけれど、ここから先は意味合いが変わる、そんな場面で、水平線はちょうどよいスイッチになります。

たとえば、同じ章の中で 「暫定対応 → 恒久対応」 のように重要なフェーズ転換が入る場合。読み手は、ここから先は“別の段階の話”だと瞬時に理解できます。暫定の注意事項と、恒久の設計・運用を混ぜないだけで、後から見返したときの誤読が減ります。

また、同じ文書の中で 「手順」と「補足情報（背景、参考資料）」 を切り分けたいときにも効果的です。上は手順だけを追えば実務が進む、下は理解を深めたい人が読む——という構造にできるので、初見の人にも、レビューする人にも優しいドキュメントになります。

不具合報告ではさらに重要で、「事実」と「対策案」 を明確に分離したいときに区切り線が役立ちます。事実（暫定対応）と、提案（恒久対応）が混ざると議論がブレますが、線一本で“事実”と“提案”を分けられると、判断と合意形成が速くなります。

例：

## 暫定対策
- 当該ロットは手動検査に切り替える
- `Vision-02` の閾値を一時的に緩和する（承認済み範囲）
---
## 恒久対策（案）
- 治具Bの位置決めピン公差を見直す
- 画像検査の閾値をロット別に管理する（管理手順をSOP化）

リンク：仕様・図面・チケットなど、“正本に飛べる形”で残す

SOPや不具合報告、変更管理メモでは、本文だけで完結しない情報が必ず出てきます。たとえば「最新版の図面」「仕様変更申請（ECR: Engineering Change Request）/ECO: Engineering Change Order）」「不具合チケット」「検査条件の根拠」などです。
ここを本文にコピペしてしまうと、後から更新が入ったときに文書側が古くなり、現場で参照する内容がズレます。

そこで基本方針はシンプルです。本文には要点を書き、詳細は正本（Single Source of Truth）へリンクする。
こうしておくと、人もAIも「どこを見れば最新版か」が明確になり、RAGでも“根拠に戻れる”文書になります。

基本の書き方：本文の中にリンクを埋め込む

リンクは次の形です。

• [表示文字](URL)

例：

関連： [ECR-2417 仕様変更申請](https://example.com/ecr/2417)

ポイントは、表示文字に「何のリンクか」が分かる情報（ECR番号、図面番号、チケット番号）を入れることです。URLそのものをベタ貼りするより、後から見返したときに意味が通ります。

URLが長いとき：参照形式リンクで“本文を読みやすくする”

URLが長い／同じリンクを何度も使う場合は、参照形式リンクが便利です。本文は短く、リンク先は文末にまとめられます。

例：

参照：
- [設備図面D-102][dwg]
- [不具合チケットINC-8891][inc]
[dwg]: https://example.com/drawings/D-102
[inc]: https://example.com/incidents/8891

この書き方のメリットは2つあります。

• 本文がスッキリして読みやすい（現場で拾い読みしやすい）
• URLが変わっても、文末の定義だけ差し替えれば修正が一箇所で済む

実務でのコツ（AI Ready的に効く）

まず、表示文字の中に必ず「管理番号」を含めることが重要です。たとえば「ECR-2417」「D-102」「INC-8891」といった具体的な番号を明示することで、検索や照合の際に、該当情報にヒットさせやすくなります。一意性のある識別子が含まれていることで、情報の追跡性が大きく向上します。

次に、「関連」「参照」「根拠」などのラベルを明示的に付けることが効果的です。単にリンクを貼るのではなく、そのリンクが「根拠」なのか「参考情報」なのか、あるいは「申請元」なのかを明確にしておくことで、AIがリンクの意味を文脈として解釈しやすくなります。これにより、RAGなどで情報を取り込む際にも、関係性を構造的に理解させることができます。

さらに、常に「正本」を指すようにすることも重要です。SharePoint、PLM、ALM、チケット管理システムなど、公式な一次情報の保管場所を参照先として明示しておくことで、コピーや転記による情報の陳腐化を防ぐことができます。リンク先が常に最新状態であれば、文書自体が古くなるリスクも最小化できます。

このように、管理番号の明示、関係ラベルの付与、正本へのリンクという三点を徹底することで、人にもAIにも扱いやすい「AI Readyな情報構造」を実現することができます。

画像：写真は“説明（alt）”を書くことで資産価値を高める

不具合対応では写真が強い証拠になりますが、画像ファイルだけ置いても「後から探せない」「要約できない」「AIが意味を拾えない」ことがよく起きます。そこで重要なのが alt（代替テキスト） です。altは、画像の内容を文章で説明する部分で、Markdownでは  の形で書きます。

製造業の文書では、altに次の情報を入れると効果が出ます。

• 何の不具合か（例：端子曲がり、キズ、欠け、異物、焼け）
• どこが異常か（部位、位置、方向：右端、左上、根元など）
• 比較条件（正常品との比較、ロット、工程、撮影条件など必要に応じて）

こうしておくと、画像を開かなくても内容が分かり、検索（RAG）でも「端子曲がり」でヒットし、AIの要約でも“どんな不良が写っているか”を正しく拾いやすくなります。

例：

![外観不良：リード端子が根元から曲がり。右上に正常品との比較](/img/ng-lead-bent.jpg "NGサンプル：端子曲がり")

ポイントは、「外観不良」という大枠だけで終わらず、具体的な異常（曲がり）と位置（根元）と比較（正常品）まで文章にしておくことです。これが後で効く“検索できる不具合写真”になります。

エスケープ：品番や記号を“記法”として誤認させない

Markdownには、見出し（#）、強調（* や _）、リンク（[]()）など、記号に意味があるルールがあります。そのため、本文の中に品番や記号が出てくると、本当は「文字として書きたいだけ」なのに、Markdownの記法として解釈されてしまうことがあります。

そこで使うのが「エスケープ」です。記号の直前にバックスラッシュ（円マーク） \ を付けると、「これはMarkdown記法ではなく、ただの文字です」という指定になります。

例：

品番：\#A-102（#を見出しとして扱わせない）
注意書き：\*混入注意\*（* を強調記号として扱わせない）

特に製造業の文書だと、品番・図番・工程記号・注記に # や * が混ざることが多いので、エスケープは覚えておきましょう。

まとめ：まずは“基本文法だけでAI Ready”は十分に作れる

以下、本記事で説明した内容を表形式でまとめました。

本記事では、製造業のSOP（標準作業手順書）を題材に、Markdownの基礎文法を実務の書き方として整理しました。ポイントは難しい記法を覚えることではなく、AIと人が同じ構造で読めるように「骨格」を揃えることです。

見出しで章立てを固定し、段落で話題を分け、リストで手順と確認項目を明確にし、タグやログはコード表記で崩さず、根拠資料はリンクで正本へつなぐ。写真はaltで内容を言語化し、記号はエスケープで誤解を防ぐ。これだけでも、生成AIが理解しやすく、検索（RAG）で当たりやすく、要約や再利用がしやすい“AI Ready Data”に近づきます。

まずは既存のSOPや不具合メモを1本選び、この基礎ルールだけで書き直してみてください。形式が揃うと、同じ内容でも「探せる」「混ざらない」「再利用できる」感覚がすぐに出るかと思います。

生成AI活用の成否は「モデル性能」だけで決まるのではなく、現場にある情報資産が“AIにとって扱いやすい形（AI Ready Data）”になっているか？に、大きく左右されます。

AI Ready Data整備の進め方から、RAG設計、運用まで見据えたプラットフォームづくりなど、現場で本気で生成AIを活用したいと思ってらっしゃる方、ぜひご相談ください。

次回：AI Ready DataのためのMarkdown入門（拡張編）

拡張編では、一番重要なテーブルや、フェンス付きコードブロックなど、現場運用で良く使う領域を取り上げておりますので、合わせてご確認ください。

AITC | AI TRANSFORMATION CENTER

AI Markdown拡張から応用編　拡張記法を使ってみよう

🕒️2026年2月25日

筆者
AITC センター長
深谷 勇次