@shibayama/pdgkit 0.1.0 → 0.1.1

package/docs/ai-authoring-guide.md

@@ -1,6 +1,8 @@
 # PatentDSL（.pdg）記述ガイド — AI 用
 
-このガイドは、特許図面を PatentDSL（`.pdg`）で記述する AI のための指示書です。ホスト（明細書作成ツールなど）のシステムプロンプトにそのまま注入して使います。読んだ AI が、説明から正しい `.pdg` を一度で再現できることを目的に書かれています。正典は [spec.md](spec.md) です。
+このガイドは、**発明の説明文やクレーム文を読み、特許図面を PatentDSL（`.pdg`）へ翻訳する AI** のための指示書です。ホスト（明細書作成ツールなど）のシステムプロンプトにそのまま注入して使います。読んだ AI が、与えられた文章から正しい `.pdg` を一度で組み立てられることを目的とします。正典は [spec.md](spec.md) です。
+
+あなたの仕事は創作ではなく **翻訳** です。入力の文章にある構成要素・関係・流れを、過不足なく `.pdg` の 3 種類の文へ写してください。文章に無いものを足さず、文章にあるものを落とさないことが最優先です。
 
 ---
 
@@ -23,181 +25,228 @@
 
 ---
 
-## 1. 言語の全体像
+## 1. 全体像 — これは「文章 → .pdg」の翻訳
 
-- 1 行 = 1 文。改行が文の終わり。文は 3 種類だけ（定義・包含・接続）。`#` から行末はコメント。
-- 符号（ID）は `[A-Za-z0-9_*]+`。装置の構成要素には数値（`10`, `11`, `100`）、方法のステップには `S100`, `S110` のように `S` + 10 刻みを使うのが慣例。
-- ラベルは「日本語 / english」の形。区切りは前後に空白のある ` / ` のみ。`A/D` や `I/O` のような語中の `/` はそのまま書ける。片方だけでもよい。
+`.pdg` は 3 種類の文しか持ちません。翻訳とは、入力の文章をこの 3 文型に振り分ける作業です。
 
----
+| 文型 | 役割 | 書式 | 文章中の現れ方 |
+|---|---|---|---|
+| 定義 | 符号に名前を付ける | `10 = 制御部 / controller` | 名詞（部・装置・ステップ・主体） |
+| 包含 | 親が子を内包する | `10 : 11 12` | 「A は B と C を備える／含む／有する」 |
+| 接続 | 線・矢印を引く | `11 -> 12 : 信号 / signal` | 「A が B へ〜を送る／出力する」 |
 
-## 2. 3 つの文（正確な書式）
+図種（block / flow / state / seq）は宣言ではなく、書いた構造から自動的に決まります（→ 第 4 節）。だからまず文章を 3 文型へ翻訳し、その結果として図種が定まる、という順で考えます。
 
-### 定義 — 符号にラベルを付ける
+---
 
-```pdg
-10 = 制御装置 / control device
-11 = CPU
-13 = "I/O インターフェース" / "I/O interface"
-```
+## 2. 翻訳パイプライン
 
-### 包含 — 親が子を内包する（スペース区切り）
+入力の文章を、次の A→F の順で機械的に処理します。各ステップの判断材料は第 3 節の対応辞典にあります。
 
-```pdg
-10 : 11 12 13
-```
+**A. 入力を読み、図の性質を見極める。**
+文章が何を語っているかで、目指す図種の当たりを付けます（確定は D）。
+- 物の構成（何が何を含み、何と何がつながるか） → ブロック図
+- 処理・方法の手順、条件分岐 → フローチャート
+- 状態とその間の遷移 → 状態遷移図
+- 複数の主体の間のやりとり（要求と応答の往復） → シーケンス図
 
-### 接続 — 線・矢印を引く（演算子の前後に半角スペース必須）
+**B. 構成要素を抽出し、符号を割り当てる。**
+文中の名詞（装置・部・部品・ステップ・主体）を漏れなく列挙し、それぞれに符号（ID）を与えます（割り当て規則は 3.7）。各要素は必ず定義文 `符号 = 名前` を書きます。
 
-```pdg
-11 -> 12 : 制御信号 / control signal
-```
+**C. 関係を抽出する。**
+要素どうしの関係を、述語（動詞・助詞）から読み取ります。
+- 「備える／含む／有する／から成る」「内部に」 → 包含 `親 : 子...`
+- 「送る／出力する／供給する／入力する／戻す／受け取る」 → 接続。**向きと線種**は 3.3 の辞典で決める。
 
-演算子:
+**D. 図種を確定する。**
+B・C で書いた構造に含まれる「目印」から図種が決まります（4.3 の優先順位）。狙った図種になるよう目印を整え、他の図種の目印を混ぜないようにします。
 
-| 演算子 | 線種 | 用途 |
-|---|---|---|
-| `-` | 単線 | 方向のない接続 |
-| `->` | 矢印 | 方向のある接続（基本） |
-| `<-` | 逆矢印 | `A <- B` は `B -> A` と同じ |
-| `<->` | 双方向 | 相互通信 |
-| `..` | 破線 | 論理的・補助・電源など |
-| `.>` | 破線矢印 | 無線通信などの方向あり破線 |
-| `=>` | 太矢印 | 主信号の強調 |
+**E. 3 文型へ翻訳して並べる。**
+定義 → 包含 → 接続の順に書くと読みやすい。1 行 1 文、接続は 1 行 1 本。ラベルは可能なら「日本語 / english」。
+
+**F. 1 行目に図種を宣言し、自己点検する。**
+`#! kind: ...` を先頭に置く。第 7 節のチェックリストを通してから出力する。
 
 ---
 
-## 3. 絶対規則（破るとエラーになる）
+## 3. 文章の手がかり → 記法 対応辞典
 
-1. 接続演算子の前後には半角スペースを必ず置く。`11 - 12` は正、`11-12` は誤り。
-2. 接続は 1 行に 1 本だけ。連鎖記法 `A -> B -> C` は使えない。`A -> B` と `B -> C` の 2 行に分ける。
-3. 1 ファイルに 1 つの図だけを書く。複数の図は別々に出力する。
-4. 符号（ID）に使えるのは `A-Za-z0-9_*` だけ。`=` `:` `-` `>` `<` `.` `/` `#` `"` `(` `)`・空白は使えない。
-5. ラベルに ` / `（区切り扱いの空白付きスラッシュ）、`:`、`=`、`#`、`"` を含めたいときは、その語を `"..."` で囲む。
-6. 色・線の太さ・座標・フォントは指定できない（特許図面は黒線・無装飾）。
+翻訳の中核です。特許文の定型表現を、そのまま記法に写すための対応表です。
 
----
+### 3.1 図種を選ぶ手がかり
 
-## 4. 図種の決め方（手順）
-
-図種は宣言ではなく、書いた構造から自動的に決まります。次の手順で「狙った図種」を確実に作ります。
+| 文章の語 | 図種 |
+|---|---|
+| 装置／システム／機器／〜部／〜を備える／構成 | block |
+| 方法／手順／工程／〜するステップ／処理の流れ／〜してから〜する | flow |
+| 状態／モード／〜状態になる／遷移 | state |
+| 通信／プロトコル／要求と応答／やりとり／ハンドシェイク／送受信 | seq |
 
-### 手順 1: 入力から図種を選ぶ
+迷ったら：物の話なら block、ことの順序の話なら flow。
 
-- 装置・システムの構成（何が何を含み、何と何がつながるか） → ブロック図 `block`
-- 処理・方法の流れ、条件分岐 → フローチャート `flow`
-- 状態とその間の遷移 → 状態遷移図 `state`
-- 複数の主体（クライアントとサーバなど）間のやりとり → シーケンス図 `seq`
+### 3.2 包含を読む（ブロック図）
 
-### 手順 2: 「目印」で図種を成立させる
+| 文章 | 記法 |
+|---|---|
+| 「A は B と C と D を備える／有する／含む／具備する」 | `A : B C D` |
+| 「A は、B と、C と、D と、を備える」（クレーム文体） | `A : B C D` |
+| 「A の内部に B」「A に B が設けられる／配置される」 | A を親にした包含 |
+| 多段（A が B を含み、B が C を含む） | `A : B` と `B : C` の 2 行 |
 
-図種は次の優先順位で推論されます（上にあるものが優先。最初に該当したもので確定）。
+「、と、」で列挙され「を備える（有する／含む）」で締める形は、締めの主語を親、列挙された各要素を子とする包含です。
 
-1. 包含文 `:` が 1 つでもある → ブロック図
-2. ラベル末尾が `?` の符号がある → フローチャート
-3. 符号 `*` が登場する → 状態遷移図
-4. `<->`、または往復ペア（`A -> B` と `B -> A` の両方）がある → シーケンス図
-5. 上記以外（片方向の接続のみ） → フローチャート
+### 3.3 接続と線種を読む
 
-選んだ図種に応じて、必要な目印を入れ、他の図種の目印を混ぜないようにします。
+向きは「誰から誰へ」を述語で判断します。「A が B へ送る」は `A -> B`、「A は B から受け取る／取得する」は `B -> A`（向きが反転する点に注意）。
 
-| 狙う図種 | 入れる目印 | 入れてはいけないもの |
+| 文章 | 記法 | 線種の意図 |
 |---|---|---|
-| block | 包含 `親 : 子...` | （`:` があれば最優先で block になるので他は気にしなくてよい） |
-| flow | 片方向 `->` でつなぐ。条件分岐は末尾 `?` | 包含 `:`（あると block になる） |
-| state | `*` と状態をつなぐ | 包含 `:`、末尾 `?` |
-| seq | 主体間で往復させる、または `<->` | 包含 `:`、末尾 `?`、符号 `*` |
+| A が B へ〜を送る／出力する／供給する／入力する／与える | `A -> B : 〜` | 矢印（基本） |
+| A は B から〜を受け取る／取得する | `B -> A : 〜` | 矢印（向き反転） |
+| 前記 A が…した〜を B が処理する（クレーム） | `A -> B : 〜` | 「前記」は既出要素＝同じ符号 |
+| A と B が相互に／双方向に通信する | `A <-> B : 〜` | 双方向 |
+| A が B へ無線で送信する／非接触で | `A .> B : 〜` | 破線矢印（無線・論理） |
+| 電源を供給する／給電する／〜に接続（補助的） | `A .. B` | 破線（補助・電源） |
+| 主たる〜／主信号を伝える（強調したいとき） | `A => B : 〜` | 太矢印（任意） |
+| 単に「つながる／接続される」（向き不問） | `A - B` | 単線 |
+| フィードバックする／帰還する／〜へ戻す | 戻り線 `A -> B`（または `.>`） | 後述の通り自動で側方へ回る |
 
-### 手順 3: 1 行目で宣言する
+向きが文章から判然としないときは、データ・信号・物が流れる自然な向き（上流→下流）を採用します。
 
-`#! kind: block` のように、選んだ図種を 1 行目に必ず書く。これは検証で構造と照合され、食い違えばエラーになる。宣言と実際の構造を一致させること。
+### 3.4 フローチャート特有（分岐・ループ）
 
----
+| 文章 | 記法 |
+|---|---|
+| 〜するステップ／〜してから〜する／次に〜する | 順次に `S100 -> S110 -> ...`（ただし 1 行 1 本に分ける） |
+| 〜か判定する／〜かどうか／〜の有無を判定する／成功したか | 判定ノードのラベル末尾を `?` にする（菱形になる） |
+| Yes なら X、No なら Y／真なら／偽なら／一致すれば | 判定から 2 本の接続を出し、`: Yes` `: No` 等のラベルを付ける |
+| 失敗したら再試行する／繰り返す／〜へ戻る | 戻り線（前のステップへ `->`） |
+| 開始／終了 | 入次数 0・出次数 0 のノードが自動で角丸になる |
 
-## 5. 形状の自動決定
+**戻り線（ループ）は素直に書く。** 前のステップへ戻る接続（例 `S140 -> S110`）は、自動的に図の右側の縦レーンへ回り込ませて描かれ、前進する線と重なりません。戻り先を別ノードにする等の小細工は不要です。戻り線が複数あるときは入れ子になり、距離の長いものほど外側を通ります（状態遷移図の戻り遷移も同様）。
 
-書く必要はなく、図種と構造から自動で決まります。狙って形を出すために知っておくこと。
+### 3.5 状態遷移図特有
 
-- フローチャートで条件分岐の菱形を出すには、ラベル末尾を `?` にし、その符号を接続に登場させる。
-- フローチャートで入次数 0 のノードは開始（角丸）、出次数 0 のノードは終了（角丸）になる。
-- 状態遷移図で `*` は初期・終端の黒丸になる。
+| 文章 | 記法 |
+|---|---|
+| 〜状態／待機状態・動作状態 | 状態ノードを定義 |
+| 初期状態／開始時は〜 | `* -> S1`（`*` が初期の黒丸） |
+| 〜になると／〜をきっかけに〜へ遷移する | `S1 -> S2 : きっかけ`（ラベルは遷移の契機） |
+| 終了状態／最終状態になる | `S2 -> *`（`*` が終端） |
 
----
+### 3.6 シーケンス図特有
+
+| 文章 | 記法 |
+|---|---|
+| A が B へ要求し、B が応答する | `A -> B : 要求` と `B -> A : 応答`（往復で seq になる） |
+| 双方向にやりとりする | `A <-> B : 〜` |
+| 主体（登場人物） | 接続に**登場した順**に左から配置されるので、流れの起点から書く |
+| 時系列 | **行の順序がそのまま上から下の時間順**になる |
 
-## 6. 符号の付け方
+### 3.7 符号（ID）の割り当て
 
-- 装置クレーム: 上位構成に大きい番号（`100` = システム）、その下の部に十の位（`10`, `20`）、さらに下の部品に一の位を加える（`11`, `12`）と階層が読みやすい。
-- 方法クレーム: `S100`, `S110`, `S120` のように `S` + 10 刻み。後から間に挿入しやすい。
-- 図に登場する符号はすべて定義する。定義せず接続だけに書いた符号は「暗黙ノード」になり、意図しない空ノードが現れる。
-- 複数の図で同じ部品を指すときは、図をまたいで同じ符号・同じ名称を使う（この一貫性は書き手が管理する）。
+符号は特許明細書の「符号の説明」と対応する番号です。文章中の同じ要素には必ず同じ符号を使います（「前記〜」は既出要素を指す）。
+
+- 装置・システム: 上位構成に大きい番号（`100` = システム）、その下の部に十の位（`10`, `20`, `30`）、さらに下の部品に一の位を足す（`11`, `12`）。階層が読みやすくなる。
+- 方法のステップ: `S100`, `S110`, `S120` のように `S` + 10 刻み。後から間に挿入しやすい。
+- 状態: `S1`, `S2`（または `待機` 等の英数字 ID）。初期・終端は `*`。
+- 使える文字は `A-Za-z0-9_*` のみ。
 
 ---
 
-## 7. 自然言語から組み立てる手順と例
+## 4. 言語仕様リファレンス
 
-以降の `.pdg` はすべて検証済み（`validate` が通り、宣言どおりの図種になる）。発明の説明を図にする際の手本として使う。
+### 4.1 3 つの文（正確な書式）
 
-### 7.1 組み立ての手順
+```pdg
+10 = 制御装置 / control device       # 定義（ラベルは「日本語 / english」、片方だけでも可）
+13 = "I/O インターフェース" / "I/O interface"   # 予約記号を含む語は "..." で囲む
+10 : 11 12 13                        # 包含（子はスペース区切り）
+11 -> 12 : 制御信号 / control signal  # 接続（演算子の前後に半角スペース必須）
+```
 
-1. 構成要素を洗い出す。文中の名詞（部・装置・ステップ・主体）を列挙する。
-2. 符号を割り当てる。装置は数値（上位ほど大きく、下位部品ほど小さく）、方法ステップは `S100`, `S110`。
-3. 包含関係を書く（ブロック図のとき）。「A は B と C を含む／備える／有する」→ `A : B C`。
-4. 接続を書く。「A が B へ〜を送る／出力する」→ `A -> B : ラベル`。1 行 1 本。
-5. ラベルを付ける。可能なら「日本語 / english」。
-6. 図種を宣言する。1 行目に `#! kind: ...`。
-7. 自己点検する（セクション 8）。
+- 1 行 = 1 文。改行が文の終わり。`#` から行末はコメント。
+- ラベルの区切りは前後に空白のある ` / ` のみ。`A/D` や `I/O` のような語中の `/` はそのまま書ける。
 
-### 7.2 詳しい組み立て（思考過程の例）
+### 4.2 接続演算子
 
-指示: 「センサ端末は、温度センサと加速度センサを有する検出部と、取得部および判定部を有する処理部と、通信部とを備える。検出部のセンサ値は処理部へ送られ、処理部の送信データは通信部を介してゲートウェイへ無線送信される。」
+| 演算子 | 線種 | 主な用途 |
+|---|---|---|
+| `-` | 単線 | 方向のない接続 |
+| `->` | 矢印 | 方向のある接続（基本） |
+| `<-` | 逆矢印 | `A <- B` は `B -> A` と同じ |
+| `<->` | 双方向 | 相互通信 |
+| `..` | 破線 | 論理的・補助・電源など |
+| `.>` | 破線矢印 | 無線通信などの方向あり破線 |
+| `=>` | 太矢印 | 主信号の強調 |
 
-- (1) 構成要素: センサ端末 / 検出部 / 温度センサ / 加速度センサ / 処理部 / 取得部 / 判定部 / 通信部 / ゲートウェイ（外部）。
-- (2) 符号: 100=センサ端末、10=検出部、11=温度センサ、12=加速度センサ、20=処理部、21=取得部、22=判定部、30=通信部、200=ゲートウェイ。
-- (3) 包含: 端末は検出部・処理部・通信部を備える（`100 : 10 20 30`）。検出部は 2 センサを有する（`10 : 11 12`）。処理部は取得部・判定部を有する（`20 : 21 22`）。
-- (4) 接続: 検出部→処理部（センサ値）、処理部→通信部（送信データ）、通信部→ゲートウェイ（無線なので破線矢印 `.>`）。
-- (5)(6) ラベルを付け、包含があるので `#! kind: block`。
+### 4.3 図種の推論（優先順位）
 
-```pdg
-#! kind: block
-100 = センサ端末 / sensor terminal
-10 = 検出部 / detector
-11 = 温度センサ / temperature sensor
-12 = 加速度センサ / acceleration sensor
-20 = 処理部 / processor
-21 = 取得部 / acquisition unit
-22 = 判定部 / determination unit
-30 = 通信部 / communication unit
-200 = ゲートウェイ / gateway
-100 : 10 20 30
-10 : 11 12
-20 : 21 22
-10 -> 20 : センサ値 / sensor value
-20 -> 30 : 送信データ / tx data
-30 .> 200 : 無線 / wireless
-```
+上から順に判定し、**最初に該当したもので確定**します。
+
+1. 包含文 `:` が 1 つでもある → **block**
+2. ラベル末尾が `?` の符号がある → **flow**
+3. 符号 `*` が登場する → **state**
+4. `<->`、または往復ペア（`A -> B` と `B -> A` の両方）がある → **seq**
+5. 上記以外（片方向の接続のみ） → **flow**
 
-### 7.3 図種別の例
+| 狙う図種 | 入れる目印 | 入れてはいけない目印 |
+|---|---|---|
+| block | 包含 `親 : 子...` | （`:` があれば最優先で block。他は気にしなくてよい） |
+| flow | 片方向 `->`。分岐は末尾 `?` | 包含 `:` |
+| state | `*` と状態の接続 | 包含 `:`、末尾 `?` |
+| seq | 主体間の往復、または `<->` | 包含 `:`、末尾 `?`、符号 `*` |
 
-#### ブロック図（基本）
+### 4.4 形状の自動決定（書かずに決まる）
 
-指示: 「制御装置が CPU、メモリ、I/O インターフェースを内蔵し、I/O インターフェースが外部機器へ信号を出力する。」
+- flow: ラベル末尾 `?` → 菱形。入次数 0 → 開始（角丸）、出次数 0 → 終了（角丸）。他 → 長方形。
+- state: `*` → 黒丸。他 → 角丸。
+- block → 長方形。seq → アクタ。
+
+### 4.5 絶対規則（破るとエラー）
+
+1. 接続演算子の前後に半角スペースを必ず置く。`11 - 12` は正、`11-12` は誤り。
+2. 接続は 1 行 1 本。連鎖 `A -> B -> C` は不可。`A -> B` と `B -> C` に分ける。
+3. 1 ファイルに 1 図だけ。複数の図は別々に出力する。
+4. 符号に使えるのは `A-Za-z0-9_*` のみ（`=` `:` `-` `>` `<` `.` `/` `#` `"` `(` `)`・空白は不可）。
+5. ラベルに ` / `・`:`・`=`・`#`・`"` を含めたいときは、その語を `"..."` で囲む。
+6. 色・線の太さ・座標・フォントは指定できない（特許図面は黒線・無装飾）。
+
+---
+
+## 5. 翻訳例（思考過程つき）
+
+以下の `.pdg` はすべて検証済み（`validate` が通り、宣言どおりの図種になる）。文章をどう読み、どう構造化したかを併記します。
+
+### 5.1 装置クレーム → ブロック図
+
+入力: 「撮像部と、前記撮像部が取得した画像を処理する画像処理部と、処理結果を表示する表示部と、を備える撮像装置。」
+
+翻訳:
+- A: 「〜を備える…装置」＝物の構成 → block。
+- B: 要素＝撮像装置(10)・撮像部(11)・画像処理部(12)・表示部(13)。
+- C: 「撮像装置 … を備える」→ `10 : 11 12 13`。「前記撮像部が取得した画像を処理する画像処理部」→ 11→12（画像）。「処理結果を表示する表示部」→ 12→13（処理結果）。
+- D: 包含があるので block 確定。
 
 ```pdg
 #! kind: block
-10 = 制御装置 / control device
-11 = CPU
-12 = メモリ / memory
-13 = "I/O インターフェース" / "I/O interface"
-20 = 外部機器 / external device
+10 = 撮像装置 / imaging device
+11 = 撮像部 / imaging unit
+12 = 画像処理部 / image processor
+13 = 表示部 / display unit
 10 : 11 12 13
-13 -> 20 : 信号 / signal
+11 -> 12 : 画像 / image
+12 -> 13 : 処理結果 / result
 ```
 
-#### ブロック図（階層 + 外部機器、有線・無線）
+### 5.2 説明文（多段の包含＋外部機器） → ブロック図
 
-指示: 「システム本体は制御部（CPU・メモリ）と通信部（無線部・有線部）を備える。無線部は外部端末と無線で、有線部は外部サーバと有線でつながり、外部サーバと外部端末は相互通信する。」
+入力: 「システム本体は制御部（CPU・メモリ）と通信部（無線部・有線部）を備える。無線部は外部端末と無線で、有線部は外部サーバと有線でつながり、外部サーバと外部端末は相互通信する。」
 
-考え方: 多段の包含。`<->` を含むが、包含 `:` があるため必ずブロック図になる（`:` が最優先）。
+翻訳:
+- B: システム本体(100)、制御部(10)・通信部(20)、CPU(11)・メモリ(12)、無線部(21)・有線部(22)、外部サーバ(30)・外部端末(40)。
+- C: 多段包含 `100 : 10 20`／`10 : 11 12`／`20 : 21 22`。無線部→外部端末は無線なので `.>`。有線部→外部サーバは `->`。外部どうしは相互通信 `<->`。
+- D: `<->` を含むが、**包含 `:` が最優先**なので block 確定。
 
 ```pdg
 #! kind: block
@@ -218,11 +267,11 @@
 30 <-> 40 : 通信 / comm
 ```
 
-#### ブロック図（制御ループ / フィードバック）
+### 5.3 制御ループ（フィードバック） → ブロック図
 
-指示: 「制御システムは制御部・駆動部・センサ部・対象装置を備える。制御部が駆動部へ指令を出し、駆動部が対象装置を駆動し、センサ部が対象装置の状態を検出して制御部へ測定値を戻す。」
+入力: 「制御システムは制御部・駆動部・センサ部・対象装置を備える。制御部が駆動部へ指令を出し、駆動部が対象装置を駆動し、センサ部が対象装置の状態を検出して制御部へ測定値を戻す。」
 
-考え方: フィードバックの戻り線は破線矢印 `.>` にすると読みやすい。
+翻訳: 包含 `100 : 10 20 30 40`。流れは指令→駆動→状態→測定値の環。「状態を検出して…戻す」のフィードバックは破線矢印 `.>` にすると読みやすい。
 
 ```pdg
 #! kind: block
@@ -238,51 +287,35 @@
 30 -> 10 : 測定値 / measured value
 ```
 
-#### フローチャート（条件分岐）
+### 5.4 方法クレーム → フローチャート
 
-指示: 「開始後に条件 A を判定し、真なら処理 X、偽なら処理 Y を行い、いずれも終了へ進む。」
+入力: 「画像を取得するステップと、前記画像から特徴量を抽出するステップと、欠陥の有無を判定するステップと、欠陥が有る場合に警告を出力するステップと、を含む検査方法。」
 
-考え方: 包含を使わず片方向でつなぐ。条件は末尾 `?` で菱形。分岐に Yes / No ラベル。
+翻訳:
+- A: 「〜するステップ…を含む方法」＝手順 → flow。
+- B: 取得(S100)・抽出(S110)・欠陥あり?(S120)・警告(S130)・終了(S140)。
+- C: 順次接続。「欠陥の有無を判定する」→ 判定なので末尾 `?` で菱形。「欠陥が有る場合に警告」→ S120 から Yes/No に分岐。
+- D: 包含なし・片方向のみで flow。
 
 ```pdg
 #! kind: flow
-S100 = 開始 / Start
-S110 = 条件A? / "Condition A?"
-S120 = 処理X / Process X
-S130 = 処理Y / Process Y
+S100 = 画像を取得 / Acquire image
+S110 = 特徴量を抽出 / Extract features
+S120 = 欠陥あり? / "Defect?"
+S130 = 警告を出力 / Output alert
 S140 = 終了 / End
 S100 -> S110
-S110 -> S120 : Yes
-S110 -> S130 : No
-S120 -> S140
-S130 -> S140
-```
-
-#### フローチャート（並列 / フォーク・ジョイン）
-
-指示: 「開始後に分岐し、経路 A と経路 B を並行して行い、合流してから終了する。」
-
-```pdg
-#! kind: flow
-S100 = 開始 / Start
-S110 = 分岐 / Branch
-S120 = 経路A / Path A
-S130 = 経路B / Path B
-S140 = 合流 / Join
-S150 = 終了 / End
-S100 -> S110
 S110 -> S120
-S110 -> S130
-S120 -> S140
+S120 -> S130 : Yes
+S120 -> S140 : No
 S130 -> S140
-S140 -> S150
 ```
 
-#### フローチャート（リトライのループ）
+### 5.5 分岐とループのあるフロー → フローチャート
 
-指示: 「試行して成功かを判定する。成功なら完了。失敗なら待機してから再試行する。」
+入力: 「試行して成功かを判定する。成功なら完了。失敗なら待機してから再試行する。」
 
-考え方: ループがあるが、末尾 `?` があるためフローチャートになる（`?` は往復判定より優先）。
+翻訳: 「成功か」→ 末尾 `?` の菱形。「成功なら/失敗なら」→ Yes/No 分岐。「再試行する」→ 待機から試行への戻り線。戻り線は自動で側方へ回るので素直に書く。
 
 ```pdg
 #! kind: flow
@@ -298,11 +331,11 @@ S120 -> S140 : No
 S140 -> S110
 ```
 
-#### 状態遷移図（基本）
+### 5.6 状態遷移図
 
-指示: 「待機から起動で動作中になり、停止で待機へ戻る。動作中に異常が起きるとエラーになり、リセットで待機へ戻る。」
+入力: 「待機から起動で動作中になり、停止で待機へ戻る。動作中に異常が起きるとエラーになり、リセットで待機へ戻る。」
 
-考え方: 初期は `*`。各遷移にきっかけをラベルで。
+翻訳: 状態＝待機(S1)・動作中(S2)・エラー(S3)。初期は `* -> S1`。各遷移のラベルは契機（起動・停止・異常・リセット）。戻り遷移も素直に書く。
 
 ```pdg
 #! kind: state
@@ -316,27 +349,11 @@ S2 -> S3 : 異常 / fault
 S3 -> S1 : リセット / reset
 ```
 
-#### 状態遷移図（初期と終端）
-
-指示: 「待機で受信すると処理中になり、完了で待機へ戻る。処理中に異常終了すると終了状態になる。」
-
-考え方: 初期も終端も `*` で表す（`* -> S1` が初期、`S2 -> *` が終端）。
-
-```pdg
-#! kind: state
-S1 = 待機 / Idle
-S2 = 処理中 / Processing
-* -> S1
-S1 -> S2 : 受信 / receive
-S2 -> S1 : 完了 / done
-S2 -> * : 異常終了 / abort
-```
-
-#### シーケンス図（基本）
+### 5.7 シーケンス図
 
-指示: 「クライアントがサーバへ認証要求を送り、サーバがトークンを返す。続いてリソース要求と応答を行う。」
+入力: 「クライアントがサーバへ認証要求を送り、サーバがトークンを返す。続いてリソース要求と応答を行う。」
 
-考え方: 主体間のやりとり。往復するので seq になる。行の順序がそのまま時系列。
+翻訳: 主体＝クライアント(100)・サーバ(200)。要求と応答が往復するので seq。行の順序が時系列。
 
 ```pdg
 #! kind: seq
@@ -348,98 +365,11 @@ S2 -> * : 異常終了 / abort
 200 -> 100 : リソース応答 / resource response
 ```
 
-#### シーケンス図（双方向通信）
-
-指示: 「端末がサーバへ接続要求し、サーバが応答する。確立後にデータを双方向でやりとりし、最後に端末が切断する。」
-
-考え方: 双方向のやりとりは `<->`。`<->` があれば seq になる。
-
-```pdg
-#! kind: seq
-100 = 端末 / terminal
-200 = サーバ / server
-100 -> 200 : 接続要求 / connect
-200 -> 100 : 応答 / response
-100 <-> 200 : データ通信 / data exchange
-100 -> 200 : 切断 / disconnect
-```
-
-### 7.4 クレーム文からの変換
-
-#### 装置クレーム → ブロック図
-
-「〜と、〜と、〜と、を備える（有する／含む）装置」という文は、装置を親、各構成要素を子とするブロック図になる。
-
-指示: 「撮像部と、前記撮像部が取得した画像を処理する画像処理部と、処理結果を表示する表示部と、を備える撮像装置。」
-
-考え方: 撮像装置=10 が撮像部=11・画像処理部=12・表示部=13 を備える。「前記撮像部が取得した画像を処理する」→ 11 から 12 へ画像。「処理結果を表示する」→ 12 から 13 へ処理結果。
-
-```pdg
-#! kind: block
-10 = 撮像装置 / imaging device
-11 = 撮像部 / imaging unit
-12 = 画像処理部 / image processor
-13 = 表示部 / display unit
-10 : 11 12 13
-11 -> 12 : 画像 / image
-12 -> 13 : 処理結果 / result
-```
-
-#### 方法クレーム → フローチャート
-
-「〜するステップと、〜するステップと、…を含む方法」という文は、各ステップを順につないだフローチャートになる。判定のステップは末尾 `?` で菱形にする。
-
-指示: 「画像を取得するステップと、前記画像から特徴量を抽出するステップと、欠陥の有無を判定するステップと、欠陥が有る場合に警告を出力するステップと、を含む検査方法。」
-
-考え方: 取得=S100、抽出=S110、欠陥あり?=S120（判定→菱形）、警告=S130、終了=S140。判定で Yes/No に分岐。
-
-```pdg
-#! kind: flow
-S100 = 画像を取得 / Acquire image
-S110 = 特徴量を抽出 / Extract features
-S120 = 欠陥あり? / "Defect?"
-S130 = 警告を出力 / Output alert
-S140 = 終了 / End
-S100 -> S110
-S110 -> S120
-S120 -> S130 : Yes
-S120 -> S140 : No
-S130 -> S140
-```
-
----
-
-## 8. 出力前の自己点検
-
-出力する前に、次をすべて確認する。
-
-- 1 行目が `#! kind: ...` で、宣言した図種が実際の構造と一致している。
-- 接続演算子の前後に半角スペースがある。連鎖記法（1 行に複数の接続）を使っていない。
-- 図に登場する符号をすべて定義した（暗黙ノードが意図的でない）。
-- 狙った図種以外の目印（`:` `?` `*` `<->`）を誤って入れていない。
-- ラベルの予約記号は必要に応じて `"..."` で囲んだ。
-- 1 ファイルに 1 つの図だけを書いている。
-
----
-
-## 9. よくある誤りと修正
-
-| 誤り | 直し方 |
-|---|---|
-| `A -> B -> C` と 1 行に複数接続 | `A -> B` と `B -> C` に分ける |
-| `11-12`（スペースなし） | `11 - 12` にする |
-| フローチャートにしたいのに `:` を書いた | 包含 `:` を消す（`:` があると必ずブロック図になる） |
-| 菱形にしたいのに長方形になる | ラベル末尾を `?` にし、そのノードを接続に登場させる。図がブロック図になっていないか確認 |
-| 同じ符号を 2 回定義（警告） | 重複定義を 1 つにまとめる |
-| 宣言した図種と推論が不一致 | 目印（`:` / 末尾 `?` / `*` / 往復・`<->`）を見直すか、宣言を修正 |
-
 ---
 
-## 10. 図種別テンプレート
-
-必要に応じてコピーして書き換える。
+## 6. 図種別テンプレート
 
-ブロック図:
+要素名だけ差し替えれば使えます。
 
 ```pdg
 #! kind: block
@@ -450,8 +380,6 @@ S130 -> S140
 10 -> 20 : データ / data
 ```
 
-フローチャート:
-
 ```pdg
 #! kind: flow
 S100 = 開始 / Start
@@ -461,8 +389,6 @@ S100 -> S110
 S110 -> S120
 ```
 
-状態遷移図:
-
 ```pdg
 #! kind: state
 S1 = 状態1 / State 1
@@ -472,8 +398,6 @@ S1 -> S2 : 遷移 / transition
 S2 -> S1 : 復帰 / return
 ```
 
-シーケンス図:
-
 ```pdg
 #! kind: seq
 100 = 主体A / Actor A
@@ -484,21 +408,47 @@ S2 -> S1 : 復帰 / return
 
 ---
 
-## 11. 出力フォーマットの指定(レンダリングも行う場合)
+## 7. 出力前の自己点検
+
+- 1 行目が `#! kind: ...` で、宣言した図種が実際の構造（4.3 の目印）と一致している。
+- 文章中の要素を**漏れなく**定義し、文章に**無い**要素を足していない。
+- 接続の**向き**が文章どおり（「A から B へ」「B から A へ」を取り違えていない）。
+- 接続演算子の前後に半角スペースがある。1 行に複数の接続を書いていない。
+- 接続だけに現れる未定義符号がない（暗黙ノードが意図的でない）。
+- 狙った図種以外の目印（`:` `?` `*` `<->`）を誤って入れていない。
+- ラベルの予約記号は必要に応じて `"..."` で囲んだ。1 ファイルに 1 図だけ。
+
+---
+
+## 8. よくある誤りと修正
+
+| 誤り | 直し方 |
+|---|---|
+| `A -> B -> C` と 1 行に複数接続 | `A -> B` と `B -> C` に分ける |
+| `11-12`（スペースなし） | `11 - 12` にする |
+| フローチャートにしたいのに `:` を書いた | 包含 `:` を消す（`:` があると必ず block になる） |
+| 菱形にしたいのに長方形になる | ラベル末尾を `?` にし、そのノードを接続に登場させる。block になっていないか確認 |
+| 接続の向きが逆 | 「受け取る／取得する」は向きが反転する点に注意して書き直す |
+| 同じ符号を 2 回定義（警告） | 重複定義を 1 つにまとめる |
+| 宣言した図種と推論が不一致 | 目印（`:` / 末尾 `?` / `*` / 往復・`<->`）を見直すか、宣言を修正 |
+
+---
+
+## 9. 出力フォーマットの指定（レンダリングも行う場合）
 
-`.pdg` を書くだけでなく、あなた自身が pdgkit で描画まで行う環境(コードを実行できるチャットやエージェント)では、利用者の自然文の指定を次のコマンド/オプションに対応させる。指定が無ければ SVG を既定とする。描画の前に必ず検証(`pdgkit validate` / `validate()`)を通す。
+`.pdg` を書くだけでなく、あなた自身が pdgkit で描画まで行う環境（コードを実行できるチャットやエージェント）では、利用者の自然文を次のコマンド／オプションに対応させます。指定が無ければ SVG を既定とし、描画の前に必ず検証（`pdgkit validate` / `validate()`）を通します。
 
-| 利用者の言い方(例) | CLI | ライブラリ |
+| 利用者の言い方（例） | CLI | ライブラリ |
 |---|---|---|
-| SVG で / ベクタで | `pdgkit render fig.pdg -o fig.svg` | `renderToSvg(src)` |
-| PNG で / 画像で | `pdgkit render fig.pdg --to png -o fig.png` | `renderToPng(src)` |
+| SVG で／ベクタで | `pdgkit render fig.pdg -o fig.svg` | `renderToSvg(src)` |
+| PNG で／画像で | `pdgkit render fig.pdg --to png -o fig.png` | `renderToPng(src)` |
 | JPEG で | `pdgkit render fig.pdg --to jpeg -o fig.jpg` | `renderToJpeg(src)` |
-| PDF で / 出願用に | `pdgkit render fig.pdg --to pdf -o fig.pdf` | `renderToPdf(src)` |
-| PowerPoint で / PPTX で / スライドに | `pdgkit render fig.pdg --to pptx -o fig.pptx` | `renderToPptx(src)` |
-| 編集できる PPTX で / 図形として編集できるように | `pdgkit render fig.pdg --to pptx --editable -o fig.pptx` | `renderToPptx(src, { editable: true })` |
-| 符号表(符号の説明)も | `pdgkit refs fig.pdg --format md`(または `csv`) | `refsToMarkdown(parse(src))` |
+| PDF で／出願用に | `pdgkit render fig.pdg --to pdf -o fig.pdf` | `renderToPdf(src)` |
+| PowerPoint で／PPTX で／スライドに | `pdgkit render fig.pdg --to pptx -o fig.pptx` | `renderToPptx(src)` |
+| 編集できる PPTX で／図形として編集できるように | `pdgkit render fig.pdg --to pptx --editable -o fig.pptx` | `renderToPptx(src, { editable: true })` |
+| 符号表（符号の説明）も | `pdgkit refs fig.pdg --format md`（または `csv`） | `refsToMarkdown(parse(src))` |
 
-言語の指定は上記に足す: 日英併記なら `--lang both`(`{ lang: 'both' }`)、英語なら `--lang en`(`{ lang: 'en' }`)。既定は日本語。
+言語の指定は上記に足す: 日英併記なら `--lang both`（`{ lang: 'both' }`）、英語なら `--lang en`（`{ lang: 'en' }`）。既定は日本語。
 
 例: 「この図を編集できる PPTX にして」→ `.pdg` を書いて `pdgkit validate` を通したうえで、`pdgkit render fig.pdg --to pptx --editable -o fig.pptx` を実行する。