皆さん、 Excel設計書 作ってますか？
こんにちは！@2626 です。
我々のチームでは、社内向けの生成AI利用環境を構築・運用しており、その中に FileOCR という機能があります。この機能はざっくり言うと Officeファイルやスキャン文書を、生成AIが扱いやすいMarkdownに変換する 機能です。
今回はこの機能を作ろうと思った背景と、実際にどんな構成で作っているのかをご紹介したいと思います。生成 AI を活用したいけど、Excel データの活用に困っていて中々できない…。 という方は是非最後まで一読いただければ幸いです。
目次
本記事は下記で構成されています。
- なぜ「Excelの活用」にこだわるのか
- Excel設計書はなぜ生成AIと相性が悪いのか
- Excelを生成AIに入れる3つのアプローチ
- 実際に作っているFileOCR機能の構成
- 工夫しているポイント
- 実際に変換してみた
- まとめ
前半は「そもそも何が問題なのか」という話なので、非エンジニアの方にも読んでいただけると思います。後半は実装寄りの話になります。実際の構成は第 4 章以降になりますので、興味のあるところから読んでいただければ幸いです。
また、筆者は Excel設計書自体には反対 という立場ではございません。Excel自体にも利用できるシーンは数多くある と思っております。特定の利用者を批判するものではなく、むしろ「今ある Excel データをどう活用するか？」を考えていくべきと考えておりますので、あらかじめご了承いただければ幸いです。
なぜ「Excelの活用」にこだわるのか
生成AIは「使うだけ」では差がつかない
技術的な話に入る前に、なぜこの機能を作っているのかを説明します。
昨今、生成AIのツールは充実しています。Claude、ChatGPT、Gemini のいずれも優秀ですし、契約すれば明日から使えます。コードも書いてくれるし、議事録も要約してくれる。さらに ChatGPT for Excel や Claude in Excel のような Excel に特化したサービスも現れています。一人あたり、数千円程度払えば、色々な作業を生成 AI にさせることが可能な時代になっています。
ということは、「生成AIを使っている」こと自体は、もう差別化になりません。同じツールを、同じように、誰でも使えるからです。「社内でDXを進めたい」「生成AIを活用したい」という話になったときに「便利なチャットツールを全社に配りました」で止まってしまうと、そこから先に進みません。
そこで、 「社内にすでにあるデータをどう活用するか」 というのが、差別化する上で重要だと思っています。自社が積み上げてきたナレッジは自社にしかない資産なので、この部分こそが数少ない他社と差別化できる要素だと思っています。
社内データの多くがExcelだった
日本の開発現場には、Excelで書かれた設計書が本当に大量にあります。せっかくRAG（検索拡張生成）で社内文書を検索できるようにするなら、真っ先に入れたいのがこの設計書たちです。ところが、Excelファイルをそのまま生成AIに渡しても、まともに読んでもらえません。
我々がぶつかったのは、大きく2つの問題でした。
1つ目は、いわゆる Excel 設計書そのものの問題です。 基本的に Excel を使って各種設計書を作っており、ChatGPT for Excel や Claude in Excel のような Excel に特化したサービスであっても対応できないような図形や画像が数多く存在しています。
2つ目は、RAG の取り組みの上で大きな障害になることです。 RAG についてはご存じの方も多いかと思いますので詳細は割愛いたしますが、データをどれだけきれいに整えるのかに RAG 構築の 9 割が掛かっている といって過言ではないと思います。入れるデータが崩れていれば、どれだけ検索の仕組みを工夫しても、返ってくる答えは崩れたままです。
これらの問題を解決するために、Excel をどうにかして AI Ready なデータにすることが求められました。これが、FileOCR 機能を作った背景になります。では、なぜ生成 AI や RAG 構築の上で Excel 設計書は相性が悪いのか、解説していきます。
Excel設計書はなぜ生成AIと相性が悪いのか
そもそも Excel はなぜ設計書に使われ続けるのか
まず Excel が設計書に使われ続ける理由を挙げてみます。
- 罫線とセル結合で、どんなレイアウトでも作れる（いわゆる「Excel方眼紙」）
- 図形・オートシェイプでフロー図や構成図がその場で描ける
- 1ファイルに複数シートを持てるので、機能ごとにタブで整理できる
- 誰のPCにも入っていて、印刷レイアウトまで含めて調整できる
つまり Excel は「紙に印刷したときに意味が通じるドキュメント」を作るツールとして、非常に優秀だと思っています。専用のドキュメントツールを導入しなくても、全員が今すぐ書けます。新入社員に対して、「このツール何ですか？」という状態から指導するより、「Excel を知ってます」「Excel を実際に使っていました」という状態から指導する 方が楽ですからね。
Excel 設計書の問題点
この「人間が紙で読む前提の作り」が、生成 AI にはとても読みづらいことにあります。
1. セル結合と方眼紙レイアウトで、読み順が異なる
素直にセルを左上から順に読んでいくと、人間が読む順番とは全く違う順番でテキストが並びます。例えば、
| | A | B | C | | | X | Y | Z |
| Yes | 10 | 20 | 30 | | 10 ~ 19 | 22 | 15 | 23 |
| No | 14 | 33 | 21 | | 20 ~ 29 | 23 | 5 | 22 |
| | | | | | 30 ~ 39 | 3 | 45 | 18 |
...（中略）...
| | | | | | 90 ~ | 1 | 5 | 4 |
のような Excel 設計書があるとします（ | | を 1 つのセルだと思ってください）。人間が読む場合は、2 つの表が並列に並んでいることはすぐに分かると思いますが、生成 AI は 空欄 → A → B → C → 空欄 → 空欄 → X → Y → Z の順に読みます。
2. 図・矢印・スクリーンショットはセル値として存在しない
フロー図の四角形や矢印も、Excelの内部では「セルの上に浮いているオートシェイプ」です。セルの値を読むライブラリでは、存在しないものとして扱われます。業務画面のスクリーンショットや図形の矢印、吹き出しの図を貼り付けている設計書も多いですが、これも同様に消えてしまいます。
各社のAIサービスは壁を越えつつあるが RAG となると話は別
当社では既に Gemini や NotebookLM などの利用環境を整えており、全社員が利用できます。しかしほんの1年前ほどは Excel の認識が良くなかったり、Excel ファイルを貼り付けても csv ファイルとして認識されたりと、何かと Excel 活用に問題がありました。
ちなみに、執筆時点では状況はかなり改善しており、Gemini に Excel を貼り付けた場合、添付されている画像や構造をかなり詳細に解析してくれます。Claude in Excel なども含め、各生成 AI サービスは Excel の壁を着実に越えつつあります。
ただし、RAG などの運用環境を構築しようとすると話は変わってきます。 チャットに1ファイルずつ貼り付けて読ませるのと、数千、数万の文書をあらかじめ検索可能な形に変換して蓄えておくのは、まったく別の作業だからです。後者では「毎回同じ結果になること」「全ファイルを機械的に処理できること」が要求されます。だからこそ、自前の変換パイプラインが必要になりました。
Excel 設計書に対する本音
もちろん、Excel 設計書は生成 AI を活用する立場としてはできるだけ避けてほしいというのが本音です。UMLで書くこと、そしてそれを書けるツール（PlantUML、Mermaid、draw.io、astah など）や、構造を持ったドキュメント管理サービスへ移行すれば、
- テキストなので差分が見える。レビューができる
- 図が構造として保存される。人間の目視以外でも読める
- 再利用できる。コードやテストと紐付けられる
- そして何より、機械が読める
という生成 AI にとってのメリットを数多く享受できます。これから紹介する苦労は、その大半が最初からこうしたツールで書かれていれば発生しないものでもあります。
とはいえ、「だから Excel は悪」ではありません。Excel設計書が世の中に溢れかえっているのは、構造的な理由があるからです。
- 目の前の納期に追われていて、新しいツールの学習・導入に時間を割けない
- レビューする相手や提出先がExcelしか開かない
- テンプレートがすでにExcelで存在し、それに沿うことが求められる
- 誰のPCにも入っていて、追加の費用も稟議もいらない
実際の作業に追われながら、合理的な判断として Excel 設計書が利用されてきた背景も数多くあると思っています。
「じゃあ移行すればいい」が通らない理由
**問題はすでにあるデータをどうするかです。「何年分のナレッジが蓄積されているのに活用できないな」と頭を悩ませている方も多いのではないでしょうか。これを人手で移行するのは、正直なところ現実的ではありません。
- 今後利用するツールをどうしていくか
- 今すでにある情報資産をどう生かすか
という問題は別々に考える必要があります。
とここまで、Excel 設計書に対する問題点を書いてきましたが、次からは実際にどんな方法で実装していくのかを説明していきます！
Excel を生成 AI に入れる 5 つのアプローチ
方針を決めるにあたって、選択肢を 5 つに整理しました。
| アプローチ | 代表例 | Excel設計書への対応（※ pdf 状態から） | 他社へのデータ送信 | 開発の難易度 | 初期コスト（○：安い ～ ×：高い） | ドキュメント変換コスト（○：安い ～ ×：高い） |
|---|---|---|---|---|---|---|
| ① Python のライブラリを使用する | openpyxl, xlwings, pywin32, anydoc | △ | × | python の知識を要する | ○ | ○ |
| ② クラウドサービス | Azure Content Understanding, Google Document AI | ○ | ○ | クラウドサービスの知識を要する | △ | △ |
| ③ 企業が提供しているサービス | サービスによる | 契約による | 簡単 | ○（API の場合） | × | |
| ④ OCRモデルを使う（API / ローカル） | dots.mocr , MonkeyOCRv2 | ◎ | ○ | ローカルマシン構築の専門知識を要する | ×（GPU などの高価なマシンが必要） | ○ |
| ⑤ LLM API & プロンプト | Gemini, Claude, GPT | ○ | × | クラウドサービスの知識を要する | △ | △ |
ただし、皆さんのドキュメント管理状況によっても変動があるかと思います。当社では、Excel 設計書を pdf で管理している例もありましたので、pdf を前提にして計測しております。また、いずれの場合も利用規約などによって、使用に制限が掛かる場合がございます。あらかじめご留意ください。
① Python ライブラリ
openpyxl は、Excel 2010のxlsx/xlsm/xltx/xltmファイルを読み書きするためのPythonライブラリです。Python ライブラリによって、Excel を変換し、生成 AI が読み取りやすい形式に変換する方法がよく利用されます。Python の多少に知識があれば解析できますし、特別なマシンなどは一切不要なので、気軽に試すことができます。
② クラウドサービス
PDFや画像を投げると、見出し・段落・表・ページ区切りを構造化して返してくれます。表の行列構造をきちんと取ってくれるのは非常にありがたく、自前で罫線検出を書く気にはとてもなりません。
一方で、これらのサービスは基本的に 「文字を読む」ことに最適化されています。フロー図を渡すと、図の中の文字列は拾ってくれますが、「AからBへ矢印が伸びている」という関係性は返ってきません。図が図として扱われず、バラバラのテキストになって出てくることもあります。
③ OCRモデルを使う
APIを使う方法と、ローカルマシンでモデルを動かす方法があります。ローカル実行の最大のメリットは、文書を外部に送らなくて済むことです。設計書は機密情報の塊なので、この観点は無視できません。ただし、GPUを持つマシンの運用が必要だったり、ある程度高度に AI を理解している人材が必要になります。
ちなみに、③の方法を用いたい場合はこちらのサイトが参考になると思います。
オープンソースかつ日本語におけるリーダーボードで 1 位になっている dots.mocr というモデルを実際に構築してみましたが、驚くほどに精度が高かったです。GPU マシンを持っていたり、AI 開発が可能な人員がいる場合はこちらも十分な選択肢に入るのではないでしょうか。
④ 企業が提供しているサービス
こちらは利用したことはないですが、様々な企業から様々な Excel のファイル変換システムが公開されており、デモ映像では非常に高い精度で markdown への変換が行われているように見えます。python や AI に明るい人材が中々いないけど、Excel を何とかしたい！と言う方は一度試してみてはいかがでしょうか。
⑤ LLM API とプロンプトを組み合わせる
ページを画像にしてマルチモーダルLLMに渡し、「これをMarkdownにしてください」と頼む方法です。図の意味を言語化できるのはこの方法だけで、実際に驚くほどうまくいくことがあります。
問題は安定しないことです。
- 同じページを2回投げると違う結果が返ってくる
- ページ数が多いと出力が途中で切れる
- 稀に、書かれていないことを書く
- ページ数×コストがそのまま効いてくる
「たまに素晴らしい結果を出すが、たまに壊れる」パイプラインは、業務システムとしては使えません。
結論：役割分担をさせる
5 つ（実際には 4 つ）を比べて、今回は ②と⑤の合わせ技 を行うことにしました。
最初に検討したのは、openpyxl だったのですが、あまりにも Excel 設計書が複雑すぎて、どうにもなりませんでした。同じラベルのノードが複数ある、図形で数式を組んでいる、色分けした領域枠で意味を表現している……。人間が見れば分かるけれど、グラフ構造には落ちない図が現実には大量にあったためです。「図を Mermaid や drawio の記法に変換して構造を保持する」という案も検証しましたが、実物を見た結果ほぼ全件が構造化不能でした。
- 図形は「四角形」「直線」「テキストボックス」がバラバラに並んでいるだけで、どれが1つの図なのかという情報がない
- 矢印は多くの場合ただの直線シェイプで、どのノードとどのノードを繋いでいるかという接続情報を持っていない（コネクタで正しく繋いでいる文書は少数派でした）
- そもそもファイル形式ごとに実装が分岐する（.xlsx / .xls / .pptx / .docx …）
様々な実験を繰り返し、最終的に下記のような方針でいくことにしました。
| 対象 | 担当 |
|---|---|
| Excel から pdf への変換 | Adobe PDF Service |
| 本文・見出し・表（＝文字と構造） | ドキュメント解析サービス |
| 図・フローチャート・スクリーンショット（＝意味） | マルチモーダルLLM |
| 両者の突き合わせ・矛盾の解消 | 自前のコード（決定的な後処理） |
次章から、これを実際にどう組んでいるかを説明します。
実際に作っているFileOCR機能の構成
全体の流れ
FileOCRは、ファイルがアップロードされると非同期で走る変換パイプラインです。全体像はこんな形になっています。
ポイントは大きく3つです。
1. まずPDFに変換して「レイアウトの正」を作る
Excelを直接読むのを諦めた代わりに、最初にPDF変換を挟みます。ここではAdobe PDF Servicesを使っています。PDFにしてしまえば、
- 人間が印刷して読むのと同じレイアウトが確定する
- オートシェイプの図も、スクリーンショットも、ページ上の絵として確実に残る
- Excel / Word / PowerPoint を 1本のパイプラインで扱える
というメリットが一気に手に入ります。ファイル形式ごとの分岐が消えるのは、実装・保守の両面でかなり効きました。
ちなみに Excel から pdf へと正確に変換するには、改ページ設定を正しくおこなっている 必要があります。当社で作成していた Excel では、改ページ設定を基本的には正しくおこなっていたため、この方法を利用できました。
2. テキストはOCRサービス、図はマルチモーダルLLM
PDFができたら、2系統に分けて処理します。片方はAzure Content Understandingに投げて本文・見出し・表をMarkdownとして取得。もう片方はPyMuPDFで各ページを高解像度のPNGにレンダリングし、Gemini Visionに「図・フローチャート・UIスクリーンショットの位置」を検出させます。構造化出力 を利用することで、「図・フローチャート・UIスクリーンショットの座標」だけを出力させることが可能です。
ここの処理では、正確に座標を抜き出す性能を持ったモデルが必要になります。今回はこちらのリーダーボードに記載されていた、Gemini 3 Flash を利用することにしました。
この2つは独立に走らせられるので、ページ単位で並列に処理できます。
3. 最終成果物は「Markdown＋切り出しPNG群」
出力は、本文のMarkdownと、切り出した図のPNGファイル群です。Markdownの中には図が  として埋め込まれ、その直下に検索用のキャプションが付きます。このキャプションが後述する工夫の肝になります。
パイプラインを擬似コードで書くと
実際の処理順を、雰囲気が伝わる程度に簡略化するとこうなります。
async def convert_document(raw_markdown, acu_result, pdf_bytes):
# 1. PDFの全ページを画像にする
pages = render_all_pages(pdf_bytes)
# 2. 各ページから図・スクショを検出して切り出す（同時実行数は絞る）
cropped = await detect_and_crop_pages(pages, concurrency=4)
# 3. 切り出した領域の中身がOCRで表になっていたら、それを除去する
crop_pages = {c.page_num for c in cropped}
filtered = remove_image_embedded_tables(raw_markdown, pdf_bytes, crop_pages)
# 4. OCR結果が持つ図参照を、実体のある画像へ差し替える
expanded, figure_assets = expand_figure_references(filtered, acu_result, pages)
# 5. 本文と画像をマージし、各画像に検索用キャプションを付ける
final_markdown = await merge_with_captions(expanded, cropped)
return final_markdown, cropped + figure_assets
また、実際に使っているプロンプトは下記のようにしています。ちなみにこのプロンプトは、切り抜いた画像のキャプションを生成する部分になります。実際は、手元にあるドキュメントを処理させながら、プロンプトを調整されるのがいいかと思います。
PROMPT = """You are a professional technical document editor.
You are given ONE image cropped from a page of a technical document, plus the
markdown text of that page as context. Describe the image for RAG indexing.
Return a JSON object with exactly two fields:
- "label": a short noun phrase naming the image, used as the markdown alt text.
Keep it under 30 characters. No trailing punctuation.
- "caption": a detailed, searchable description of the image.
Caption rules:
1) Write ONE flowing prose paragraph. Never use markdown heading syntax
(#, ##, ###), bold sub-headings, bullet points, numbered lists, or line
breaks - even if the image itself is laid out as boxes, sections, or a list
with its own headings. Describe that structure in prose instead (e.g. "A
leads to B, which in turn triggers C").
2) Write 3-6 sentences, weaving in:
- the visual type (flowchart, architecture diagram, screen capture, bar
chart, data grid, ...),
- every legible label, entity/component name, menu item, field name, and
visible text or numeric value inside the image,
- the relationship, sequence, or flow it conveys (what connects to what,
what precedes/triggers what, what increases/decreases),
- how it relates to the surrounding section in the page context, so the
caption is understandable on its own without viewing the image.
3) Write BOTH "label" and "caption" in the same natural language as the page
context markdown, NOT the language of the text inside the image. If the page
context is Japanese, write Japanese even when the image is labelled in
English.
4) Describe only what is actually visible. Do not speculate about intent or
invent values."""
工夫しているポイント
ここからが本題です。作りながら「これは効いた」と感じた工夫をいくつか紹介します。
図を「画像＋検索用キャプション」に変換する
RAGはベクトル検索なので、Markdownに画像を貼っただけでは検索に一切引っかかりません（マルチモーダル RAG のように、画像までベクトル化している場合はその限りではありません）。なので、図の中に重要な単語や説明がある場合に問題になりえます。
そこで、切り出した各画像の直下に、検索でヒットさせるための説明文を必ず生成させるようにしました。プロンプトでは、先に説明した各画像の座標の他に、次のようなキャプションを生成するように指示しています。
- 視覚的な種別（フローチャート、構成図、画面キャプチャ、棒グラフ、データグリッド等）
- 画像内で読み取れるすべてのラベル・項目名・メニュー名・数値
- それが表す関係・順序・流れ（何が何に繋がるか、何が何を引き起こすか）
- 前後の見出しとの関係（画像を見なくても文脈が分かるように）
そして「短いタイトルで済ませない」「3〜6文の1段落の散文にする」ことを強く指定しています。ここはどんなキャプションが読みやすいのか（または不要なのか）、要件に合わせて調整されるのが良いかと思います。
LLMの出力を制御するために構造化出力
座標検出において、「座標を出して」のように素直なプロンプトにしてしまうと不安定になります。例えば下記のような感じですね。
- フィールド名が指示と違う名前で返ってくる（
xminのつもりがx1やbox_2d） - JSONの前後にマークダウンのコードフェンスが付いてくる
- 座標が指定範囲（0〜1000）を外れた値で返ってくる
- 図が明らかにあるページで、検出0件が返ってくる
そこで、先で説明しましたが、構造化出力を利用します。例えば、下記のように実装します。
class Detection(BaseModel):
xmin: int = Field(ge=0, le=1000)
ymin: int = Field(ge=0, le=1000)
xmax: int = Field(ge=0, le=1000)
ymax: int = Field(ge=0, le=1000)
caption: str
def parse(raw_json: str) -> list[Detection]:
detections = []
for item in json.loads(raw_json)["detections"]:
try:
detections.append(Detection.model_validate(item))
except ValueError as e:
# 壊れた1件だけをログに残して捨て、他は活かす
logging.warning("検出1件のスキーマ検証に失敗: %s", e)
return detections
利用しているプロンプトの例はこちらです。
PROMPT = """Detect only the bounding boxes for 'Visual Illustration Assets'.
**WHAT TO EXTRACT (TARGETS):**
1. **Complex Diagrams:** Architecture maps, flowcharts, or diagrams with arrows and logical connectors.
2. **Software UI Screenshots:** Application windows containing interactive widgets (buttons, input fields, checkboxes, scrollbars).
3. **Visual UI Grids:** Data grids that are part of a software interface (usually have colorful headers, specific UI fonts, or are nested within an app window).
**STRICT EXCLUSIONS (DO NOT EXTRACT):**
- **Documentation Tables:** Standard tables used for text definitions, glossary terms, or revision history (typically black text on a plain white/light grid).
- **Body Text:** Standard paragraphs, titles, or page headers/footers outside of diagrams.
**CROP RULES:**
- **Tight Boundary:** Crop as closely as possible to the graphical/UI frame. Do not include surrounding explanation text.
- **Logical Unit:** If a screenshot is linked to a magnified callout by an arrow, capture them together as one unit.
**RESPONSE FORMAT (STRICT - MUST FOLLOW EXACTLY):**
Return a JSON object with a "detections" key containing an array of bounding boxes.
{
"detections": [
{
"xmin": <integer 0-1000>,
"ymin": <integer 0-1000>,
"xmax": <integer 0-1000>,
"ymax": <integer 0-1000>
}
]
}
**CRITICAL RULES:**
- **Field names MUST be:** xmin, ymin, xmax, ymax (not x, y, x1, y1, x2, y2, box_2d, etc.)
- **All 4 fields REQUIRED per detection object**
- **All values MUST be integers 0-1000**
- **label is OPTIONAL - include only if available**
- **Return ONLY the JSON object - no markdown, no explanations**"""
これによって、「たまに壊れる」が「たまに検出が1件少ない」程度に軽減されました。LLMを組み込むときは、モデルの出力を信用せず、必ず自分のコードで検証する層を挟むのが結局一番効きます。
LLMに判定させなくていい部分はできるだけ判定させない
LLM を使えばルールベースで対応できない部分にも対応できるようになりますが、その分コストがかかります。そこで、ルールで対応できるところはルールで対応することも重要です。
例えば、元のドキュメントには ① や 1⃣ など様々な文字が混在していました。RAG を構築する上でどうしても揺らぎになりやすい部分です。そこで NFKC 正規化 をかけて空白を全部落としています。ただし、実際は ① や 1⃣ に意味を持たせているドキュメントもありますので、皆さんの持っているドキュメントの性質と相談しながら決めてください。
一方、Azure Content Understanding で本文・表を抽出した結果と Gemini Vision で図・スクショを検出し切り出した結果に重複が起こることがあります。このような場合は、ルールベースで重複を抜き出すのは難しいので、生成 AI にお任せすべき部分かと思います。
まとめ
ここまで長くなってしまいましたが、まとめです。
- Excelの中身を読もうとせず、PDFを経由してレイアウトを固定する。図が絵として残り、Office各形式を1本のパイプラインで扱えるようになる
- 文字はドキュメント解析サービス、図はマルチモーダルLLMと役割分担させ、図には「検索でヒットするキャプション」を必ず付ける
- 非決定的な部分は、決定的な後処理で押さえ込む。スキーマ検証・再試行・テキストレイヤーとの照合など、普通のコードで確実に決められることはLLMに聞かない
作りながら一番強く感じたのは、最後の点です。生成AIを組み込んだシステムを作っていると、難しい判断はどうしてもLLMに投げたくなります。実際それで動くことも多いのですが、「壊れたときに原因が分かる」「毎回同じ結果が返る」「コストが増えない」 という性質は、業務システムでは精度と同じくらい重要です。
そしてもう一度書いておきたいのが、今ある Excel の資産は生かした方がいいと思っています。色んなナレッジが詰まっているドキュメントの中には、そのままにしておくのはもったいないものも数多くあるのではないでしょうか。
FileOCR機能はまだ改善の途中で、表領域を切り出して再抽出した結果と突き合わせる案や、図の中の領域枠・レーン帰属を取る案など、試したいことがたくさん残っています。このあたりも形になったら、また記事にしたいと思います。
この記事が、Excel設計書と格闘している方のお役に立てば幸いです。最後までお読みいただき、ありがとうございました！