業務システムを納品して3か月ほど経つと、こういう連絡が来ることがあります。「マニュアルの画面と実際の画面が違うのですが」。
たいていは軽微な変更です。ボタンのラベルを変えた、メニューの並びを整理した、項目を1つ追加した。改修としては正しく、リリースノートにも書いてあります。書き換わっていないのは手順書のスクリーンショットだけ です。そして手順書は、新しく入った人が最初に読むものなので、ここがずれていると「このシステムは信用できない」という印象から始まってしまいます。
陳腐化しているのは中身ではなく更新経路
この問題を「マニュアルの品質」として扱うと解けません。納品時点では正確だったからです。
壊れているのは更新の経路です。コードを変更するとき、開発者はテストを直します。テストは変更しないと落ちるので、直さざるを得ません。一方、手順書は変更しなくても何も起きません。壊れても検知されない成果物は、必ず放置されます。
保守契約に「マニュアル更新」を含めればよさそうに見えますが、これも実務では機能しにくい。画面変更のたびに手作業でスクリーンショットを撮り直し、囲みや矢印を入れ直す作業は、工数が読めないうえに単調で、優先度が最後に回ります。契約に書いてあることと、実際に回ることは別です。
自動化できるのは操作と撮影、できないのは「何を載せるか」
ここに対する実装のアプローチが、2026年8月に公開された事例で示されています。コミューンの開発チームが取り組んだのは、Webサービスのガイドブックを Playwright と LLM で自動生成・更新できるようにする仕組みです。
構成の要点は役割分担にあります。LLM がコードから仕様を読み取って説明文を書き、Playwright が実際の画面を操作してスクリーンショットを撮る。 強調のための囲みを入れた画像まで含めて生成し、人間は「何を作るかの指示」と「最終確認」を担当する、という切り分けです。
この分け方には理由があります。手順書の作業を分解すると、性質の違う3つが混ざっています。
- 画面を決められた順序で操作する（機械的・再現可能）
- 撮影して加工する（機械的・再現可能）
- どの画面をどの粒度で載せるかを決める（判断が要る）
前の2つは、変更のたびに繰り返される割に判断がほとんど入りません。ここを自動化すると、改修後の再生成が現実的なコストに収まります。逆に3つ目を自動化しようとすると、出来上がるのは網羅的だが読む気にならないドキュメント になりがちです。
撮れない画面をどう扱うか
実際に組み込むと、最初にぶつかるのはここです。ブラウザ自動操作で撮れる画面には条件があります。
テストデータが要ります。 「請求書一覧」の画面を撮るには、それらしい請求データが入った状態が必要です。空の状態を撮っても手順書にはなりません。既存のE2Eテスト用のシードデータを流用できるなら、そこが起点になります。無い場合、シード整備が先行タスクとして発生します。
権限ごとに画面が違います。 管理者・一般ユーザー・閲覧のみ、で見えるものが変わるシステムでは、役割ごとにログインして撮る必要があります。これは自動化と相性がよく、むしろ手作業では抜けやすい部分なので、自動化の効果が大きいところです。
外部連携が絡む画面は撮れないことがあります。 決済代行の画面、外部認証プロバイダのログイン画面、メール本文。自社の管理下にない画面は、そもそも自動操作の対象にできないか、できてもテスト環境の都合で本番と見た目が違います。ここは手動撮影を残すか、「外部サービスの画面のため実際とは異なる場合があります」と注記を入れる運用に倒すのが現実的です。
機密情報の写り込みに注意が要ります。 本番に近いデータで撮影すると、氏名・メールアドレス・取引先名がそのまま画像に残ります。ダミーデータで撮る前提を最初に固めておかないと、後から全部撮り直しになります。
成果物の定義を「手順書」から変える
受託の観点で本質的なのは、契約上の成果物の書き方です。
従来は「操作マニュアル一式（PDF）」のように、成果物そのものを納品物として定義します。この定義だと、納品した瞬間から劣化が始まり、更新は追加作業になります。
これを 「手順書を再生成できる仕組み」と「その仕組みで生成した初版」 という定義に変えると、性質が変わります。画面が変わったとき、発注側の作業は再生成の実行になります。差分をレビューして、必要なら文章に手を入れる。撮り直しの作業は消えます。
ここで正直に言っておくべきことがあります。この形は初期費用が上がります。 操作シナリオを書き、テストデータを整え、生成した文章をレビューする工程が最初に必要です。改修頻度が低いシステム、画面が10枚程度のシステムでは、手作業で撮り直したほうが安く済みます。
判断の目安は、画面数と改修頻度の掛け算です。四半期ごとに画面が変わるシステムで、画面が50枚あるなら、2回目の改修で元が取れます。 年に1回しか変わらないなら、仕組みを作った側が先に陳腐化します。
外部リンクや参照先が静かに壊れていくのと同じ構造なので、判断の枠組みはリンク切れの棚卸しと共通します。ブラウザ自動操作を保守の作業に組み込む考え方はヘッドレスブラウザによるE2E自動化で扱った構成がそのまま使えます。
残る落とし穴
再生成の仕組みを入れても消えない問題が2つあります。
1つは差分レビューが人間に残ることです。生成された文章が正しいかどうかは、生成した側では判定できません。50枚の画面を一括再生成すると、50枚分のレビューが一度に発生します。改修のたびに変更があった画面だけを再生成する運用にしないと、レビューが滞留します。
もう1つは仕組み自体の保守です。画面のセレクタが変われば操作シナリオが壊れます。壊れたときに直せる人が社内にいないと、仕組みごと放置されます。「マニュアルの陳腐化」を「シナリオの陳腐化」に付け替えただけ、という結末はありえます。 これを避けるには、シナリオをCIで定期実行し、壊れたら気づける状態にしておくことです。テストと同じ扱いにする、ということになります。
次にやること
まず、いま運用しているシステムの手順書を開いて、スクリーンショットの1枚目と実画面を見比べてください。ずれていたら、そのずれがいつ発生したかを特定できるかどうかを確認します。 できないなら、更新経路が無いということです。
そのうえで、今後1年で画面がどれくらい変わる見込みかを見積もってください。変更が続く前提なら、成果物の定義を見直す価値があります。変わらない前提なら、いま一度撮り直すだけで十分です。
業務システムの納品物の設計、保守契約に含める範囲の整理、ドキュメント生成の自動化については、グリームハブの開発・AI・自動化のご相談で承っています。画面数と改修頻度によって最適な形が変わるため、個別にお見積りします。お問い合わせからご相談ください。
