Webマニュアル（オンラインマニュアル）の作り方と運用

編集画面は開いた。ツールの契約も済んだ。それなのに、最初の1ページが書き出せない。マニュアルのWeb化を任された担当者から、よく聞く話です。

原因は文章力ではありません。どの単位でページを分けるのか、「クリックする」と「押す」のどちらを使うのか、画面キャプチャは誰がいつ撮り直すのか。書き始める前に決めるべきことが、決まっていないだけです。

Webマニュアルの作り方でつまずくのは、たいていこの手前の工程です。この記事では、情報設計、執筆規約、画面キャプチャの運用、多言語、更新フロー、検索性の6つを順に扱います。

読み終えたときに、着手初日に社内へ配る設計メモの目次が決まっている状態を目指します。

Webマニュアルとは｜PDFを置くことと何が違うのか

Webマニュアル（＝オンラインマニュアル。手順をトピック単位のWebページに分け、ブラウザ上で検索・参照できるようにした説明書）は、PDFをサーバーに置く形とは作り方そのものが違います。PDFは、1つのファイルが完結した1冊です。オンラインマニュアルは、独立した小さなページの集まりに、目次と検索という2つの入口を付けたものです。

この違いは、編集画面の使い勝手ではなく原稿の設計に効いてきます。1冊として通しで読ませる前提の原稿を機械的にページへ切り分けると、どのページも前後を読まないと意味が通じない状態になります。見た目はWeb、中身は分割されたPDF、という結果になりがちです。

なお、使用情報（＝製品の使い方を伝える情報）の作成には国際規格があります。IEC/IEEE 82079-1:2019は、情報の品質だけでなく、作成のプロセスと作成者に求められる力量までを要求事項に含めています。作り方が担当者の裁量に委ねられてよい、という前提は取られていません。

難所は編集ツールの操作ではなく、書き始める前の取り決めにあります。

作る前に決める4つのこと｜情報設計でマニュアルの質は決まる

編集ツールに触る前に決めることは4つです。分割の単位、階層の深さ、入口の設計、名前の付け方。この4つさえ決まっていれば、残りは書くだけの作業になります。

逆に、既存のWordファイルをそのまま流し込めば済む、という進め方は成立しません。マニュアル制作を手がけるクイックスも、自由に作られたWordなどのデータを一瞬で整ったHTMLに置き換える機能は存在しないと指摘し、導入前の準備として現状マニュアルの調査・分析、ルールの策定、スタイルガイドの整備の3点を挙げています。作り方の入口は、変換ではなく棚卸しにあります。

1. 分割の単位を決める：どこで1ページを区切るか
2. 階層の深さを決める：何層までで収めるか
3. 入口を設計する：目次から辿る人と検索から来る人を、どちらも通す
4. 名前の付け方を決める：用語と型番を固定する

4つ目の「名前の付け方」は、用語と型番の2つを指します。用語は次章の執筆規約で扱います。型番のほうは、マニュアルをどの製品に紐付けるかという話です。読者は製品を探した流れのまま、そのままマニュアルへ進みます。製品情報を型番で管理する仕組み（製品登録機能のような形）と、マニュアルの参照キーを最初に揃えておくと、公開後に紐付け作業をやり直さずに済みます。

①分割の単位｜1トピック1タスクに割る

分割の単位は「章」ではなく、「読者が達成したい1つの作業」で決めます。「第3章 保守」ではなく、「フィルターを交換する」「エラーコードE12を解除する」という粒度です。1ページを開けば1つの作業が終わる。これを1トピック1タスクと呼びます。

この粒度で割っていくと、手順を伴わない内容が余ります。「対応OSは何ですか」「保証期間はどれくらいですか」といった問いです。これらはマニュアルではなくFAQへ寄せたほうが、双方が読みやすくなります。切り分けの基準はFAQサイトの作り方で整理しています。

②階層の深さ｜4層目を作りたくなったら、分類を間違えている

階層は、製品＞機能グループ＞トピックの3層で収めます。4層目が欲しくなったときは、階層が足りないのではありません。上位の分類軸が、読者の目的ではなく製品の内部構造や組織図に寄っている合図です。

読者は目次の全体像を覚えません。現在地はパンくずで常に示し、1つ上の階層へいつでも戻れるようにします。

深い階層をきれいに整えるより、浅い階層で迷わせないほうが先です。

③入口の設計｜目次から辿る人と、検索で飛び込む人は別

読者は2通りに分かれます。目次の先頭から順に読む人と、エラーメッセージをそのまま検索して途中のページへ直接飛び込む人です。実際に多いのは後者のほうです。

だからどのページも、単体で意味が通る状態にします。「上記の手順で」「前ページの設定を済ませてから」という書き方は、順に読む人だけを想定しています。前提条件があるなら、そのページの冒頭に条件として明記し、該当ページへリンクを張ってください。

この設計判断が、後述する検索性の土台になります。

執筆規約はA4一枚に収める

書き手が2人になった瞬間から、マニュアルの品質は崩れ始めます。原因は文章力の差ではありません。「クリックする」と「押す」、「ボタン」と「アイコン」、どちらを使うかの基準がないだけです。

規約は分厚くすると読まれません。A4一枚に収めます。

執筆規約に最低限入れる6項目を、決めないまま進んだ場合の影響とあわせて整理しました。

規約をゼロから作る必要はありません。テクニカルコミュニケーター協会の『日本語スタイルガイド（第3版）』は、文法、用字・用語、表記、読みやすさ、誤解を防ぐ書き方、翻訳しやすい日本語までを1冊で扱っています。市販のスタイルガイドを土台にして、自社製品の固有名詞と操作動詞だけを追記する。この作り方なら、規約づくりに数か月をかけずに済みます。

表記ゆれは、根性ではなく辞書ファイルで潰す

表記ゆれを目視で潰す運用は続きません。3か月もすれば、レビュー担当の集中力のほうが先に尽きます。

用語集はCSVで持ち、校正ツールの辞書として読み込ませます。特に揺れるのはカタカナ語の長音です。サーバとサーバー、ユーザとユーザー、プリンタとプリンター。テクニカルコミュニケーター協会は外来語（カタカナ）表記ガイドラインを公開しており、判断基準を自社で一から決める手間を省けます。

マニュアルの設計方針を社内で固める段階の方へ。tovira では顧客向け情報基盤の設計をまとめた資料をご用意しています。資料をダウンロードする

画面キャプチャは「撮り直し方」から設計する

キャプチャの運用が破綻するのは、撮るときではありません。撮り直すときです。製品のUIが少し変わっただけで、どの画像を差し替えればよいのかが分からなくなります。50枚なら手作業で追えます。500枚になると追えません。

最初から撮り直しを前提に、次の5点を決めておきます。

• 撮影条件を固定する：ブラウザ幅、OS、テーマ、画面に映すダミーデータの内容まで決めて文書化します
• ファイル名に画面IDと撮影日を入れる：order-list_20260401.png のような形にすると、UI変更時に対象を日付で絞り込めます
• 文字を画像に焼き込まない：画面内に矢印付きの説明文を描き込まず、本文側のテキストに出します
• 加工前の原本を必ず残す：囲み枠や番号を描き込んだ画像だけを保管すると、UI変更のたびに一から撮り直しになります
• altテキストを書く：画像が表示されない環境の読者に届き、ページ内容を説明するテキストとしても機能します

3つ目は多言語対応にも効きます。画像に日本語を焼き込むと、言語の数だけ画像を作り直すことになります。文字を本文側へ出しておけば、翻訳の対象はテキストだけで済みます。

撮り直しのコストは、撮り方を決めた日にほぼ確定します。

多言語対応の順番

翻訳から始めないでください。日本語の原文で用語と粒度が揃っていない状態のまま翻訳へ進むと、言語の数だけ揺れが増えます。3言語に展開していれば、原文の1か所の修正が3か所の修正になります。

順番は、原文の統一、用語集の確定、翻訳です。用語集を先に固めておくと、機械翻訳を下訳に使う場合でも訳語のばらつきを抑えられます。

言語ごとに見せる相手が違う場合は、権限設計とセットで考えます。国内代理店には日本語版を、海外パートナーには英語版だけを見せる、といった出し分けです。ユーザーロール機能のように、閲覧者の属性で公開範囲を切り替える仕組みが前提になります。

多言語は、あとから足す機能ではなく最初に決める設計です。

更新が止まらないフローをつくる

公開後にマニュアルの更新が止まる理由は、担当者の怠慢ではありません。更新が「気づいた人がやる仕事」のまま放置されているからです。起票の入口を1つ決めれば、フローは回り始めます。

1. STEP1 起票する（担当：サポート窓口／所要：即日）問い合わせ対応の中で「マニュアルの記述が原因だ」と判断した時点で、その場で起票します。書く人ではなく、気づく人に起票の役割を持たせるのが要点です
2. STEP2 書き換える（担当：ドキュメント担当／1〜3営業日）該当トピックだけを直します。前後のページにも手を入れたくなったら、別の起票に分けます
3. STEP3 2段階で見る（担当：開発とドキュメント担当／2営業日）技術確認と表現確認を分けます。理由は後述します
4. STEP4 公開して記録を残す（担当：ドキュメント担当／即日）改訂履歴に日付と変更点を残します。いつ何が変わったかが分かると、取引先からの問い合わせに即答できます

すべての改訂を同じ速度で回す必要はありません。区分ごとに公開までの目安を分けておくと、緊急の訂正がレビュー待ちで止まる事態を避けられます。

レビューを2段階に分ける理由

レビューを1人にまとめると、技術的な正しさか読み手への伝わりやすさか、どちらかが必ず甘くなります。見るために必要な能力が別物だからです。

開発担当は「この記述のとおりに操作して動くか」だけを見ます。ドキュメント担当は、規約への適合と手順の抜けを見ます。役割を先に書き分けておくと、レビュー依頼のたびに何を見てほしいかを説明せずに済みます。

検索されないマニュアルは、無いのと同じ

検索窓を置いただけでは検索されません。検索されても目的のページが上位に出てこなければ、読者はブラウザを閉じて電話をかけてきます。効くのは3つの設計です。

1. ページタイトルに、読者が使う言葉を入れる：社内呼称や型番だけのタイトルは、社外の読者が打ち込む検索語と一致しません
2. エラーコード、型番、消耗品の品番で必ずヒットさせる：本文のどこにも書かれていない文字列は、検索できません
3. 検索結果がゼロ件だったクエリを、ログから拾う：探しにきたのに存在しなかったページの一覧が、そのまま手に入ります

3つ目が改善サイクルの核です。閲覧数の多いページを磨くより先に、ヒットしなかった語を潰す。この順序のほうが、自己解決率は動きやすくなります。

例えば tovira のマニュアル機能では、FAQと同じ全文検索の基盤をマニュアルにも使い、サジェストと関連度順の並び替えを前提にする考え方をとっています。マニュアルと検索を別々の仕組みに分けない、という設計判断です。

自己解決を促す全体像は問い合わせ対応の工数を削減する方法で扱っています。

よくある質問

Webマニュアルはどうやって作り始めればよいですか

既存マニュアルの棚卸しから始めます。章立てと表記の実態を洗い出し、分割の単位、階層、執筆規約を決めてから執筆に入ります。全製品を一度に移さず、1製品10トピック程度で型を作る進め方が現実的です。

画面キャプチャの撮り直しが追いつきません

撮影条件とファイル名の規則を先に決めておくと、UI変更時に差し替え対象を絞り込めます。画像に文字を焼き込まないこと、加工前の原本を残すことの2点も、撮り直しの負担を大きく変えます。

表記ルールはどこまで細かく決めるべきですか

A4一枚に収まる範囲が目安です。操作動詞、UI要素の呼び方、語尾、番号の振り方、注意表示のレベル、単位の6項目を押さえれば、書き手が増えても揺れは抑えられます。細部は市販のスタイルガイドに委ねて構いません。

多言語対応はいつから考えればよいですか

翻訳の予定が固まっていなくても、用語集は最初に作っておくと後が楽になります。原文が揃わないまま翻訳を始めると、修正が言語の数だけ増えます。展開の判断は後でも、原文の統一は先に済ませてください。

まとめ｜設計と規約を先に、ツールは後に

Webマニュアルの作り方は、書く技術よりも先に、決めごとの数で差が付きます。この記事で扱った内容を整理します。

1. 編集ツールに触る前に、分割の単位・階層の深さ・入口・名前の付け方の4つを決める
2. 執筆規約はA4一枚に収め、市販のスタイルガイドを土台にして自社の固有名詞だけを足す
3. 画面キャプチャは撮影条件とファイル名の規則から決める。文字は画像に焼き込まない
4. 更新は起票の入口を1つに決め、改訂の区分ごとに公開までの速度を変える

最初から全製品を移す必要はありません。1製品、10トピック。この規模で設計から公開までを一周させると、自社に必要な規約の項目と、更新フローの詰まりどころが具体的に見えてきます。

tovira のカスタマーポータルは、マニュアルを製品と紐付けて公開し、取引先ごとに見せる範囲を分けられます。自社の製品構成とマニュアル量で運用が回るかは、実際の画面でご確認ください。デモを依頼する

出典

• ISO『IEC/IEEE 82079-1:2019 Preparation of information for use (instructions for use) of products — Part 1: Principles and general requirements』 iso.org（参照：2026-07-26）
• 一般財団法人テクニカルコミュニケーター協会『日本語スタイルガイド（第3版）』 jtca.org（参照：2026-07-26）
• 一般財団法人テクニカルコミュニケーター協会『TC関連ガイドライン』 jtca.org（参照：2026-07-26）
• 株式会社クイックス『【製品マニュアル作りの基礎⑦】Webマニュアル導入の第一歩』 kwix.co.jp（参照：2026-07-26）
• tovira『問い合わせ対応の工数を削減する方法｜FAQ・ポータルで自己解決を促す』 tovira.jp（参照：2026-07-26）