AIで手順書を自動生成する仕組み
画面操作の記録からマニュアルを作る技術解説

「手順書を作る時間がなくて、結局作られない」「システム更新のたびにマニュアルだけが古くなる」——どの現場でも聞く悩みです。弊社ではこの問題に対して、普段のPC操作をそのまま記録し、生成AIがスクリーンショット付きの手順書に変換するという自社製品「FlowLens（フローレンズ）」を開発しています。

本記事では、その開発の裏側を技術者向けに解説します。画面キャプチャ方式の設計判断、プライバシー保護の実装方針、Vision対応LLMのコスト最適化、そして出力を支える中間表現の設計まで、実際の技術検討の内容をベースにお届けします。

FlowLensが製品として何を解決するのか（できること・想定ユースケース・先行モニター募集）は、FlowLens 製品ページにまとめています。本記事は実装技術にフォーカスします。

全体アーキテクチャ

FlowLensは大きく3つのコンポーネントで構成されます。

[Windows クライアント (常駐エージェント)]
  ├─ 画面キャプチャ（操作イベント駆動 + 周期スクリーンショット）
  ├─ UI イベントフック（クリック / キー入力 / ウィンドウ遷移）
  └─ ローカルバッファ → 解析サーバへ送信
        │
        ▼
[解析サーバ (Docker)]
  ├─ Vision 対応 LLM による画面・操作解析
  ├─ 操作シーケンスの構造化（アプリ / 画面 / アクション）
  ├─ 手順書ジェネレータ（Markdown / docx 出力）
  └─ 最適化アドバイザ（操作パターン分析 → 改善提案）
        │
        ▼
[Web UI]
  ├─ 記録セッション一覧・手順書プレビュー / 編集
  └─ 改善提案レポート

設計上のポイントは2つあります。1つはクライアントを「記録に徹する軽量エージェント」に絞り、解析をすべてサーバ側に寄せたこと。ユーザーのPCに負荷をかけず、AIモデルの差し替えや改善をサーバ側だけで完結できます。もう1つは解析サーバをDockerコンテナとして構成したこと。クラウドにも顧客の社内サーバ（オンプレミス）にも同じ構成で展開でき、「画面データを社外に出せない」という要件に最初から備えています。

画面キャプチャ方式の設計判断

「操作を記録する」と一口に言っても、実装方式はいくつかあります。検討した3方式の比較です。

FlowLensはC. 併用方式を採用しました。手順書とは本質的に「操作 → 画面変化」の系列なので、操作イベントを主キーにして画面を従属させるデータ構造が最も適しています。周期キャプチャだけでは「なぜ画面が変わったのか」が失われ、後段のAIに推測を強いることになります。

Windows APIの選定

実装に使うWindows API / ライブラリは役割ごとに次の通りです。

• 入力イベントフック：SetWindowsHookEx（WH_MOUSE_LL / WH_KEYBOARD_LL）。PoCではPythonのpynput
• ウィンドウ遷移の検出：SetWinEventHook（EVENT_SYSTEM_FOREGROUND等）
• UI要素情報：UI Automation（UIA）。クリック座標から要素のName / ControlType / ウィンドウ階層を逆引き。PoCではuiautomation / pywinauto
• スクリーンショット：Windows.Graphics.Capture / DXGI Desktop Duplication。PoCではmss。マルチモニタとDPIスケーリング（125%〜200%）への対応が必須

プライバシー設計は「後付け」にしない

画面操作の記録ツールで最初に設計すべきは、実は記録機能ではなく「記録しない」仕組みです。FlowLensでは以下を必須要件としてクライアント側に組み込んでいます。

1. パスワードフィールド検出：UIAのIsPasswordプロパティを持つ要素へのフォーカス中は、スクリーンショットとキー入力記録を停止
2. 打鍵内容は保存しない：既定では「テキストを入力した」というイベントと、入力後の画面上の表示のみを記録
3. 対象アプリのオプトイン：記録対象を業務アプリのホワイトリストに限定。既定は「記録しない」
4. 送信前マスキング：解析サーバへ送る前にクライアント側で機密領域をマスク。将来はOCRベースのPII検出を予定

特に2番目は重要です。手順書に必要なのは「顧客コードを入力した」という事実と入力後の画面であって、打鍵の生ログではありません。要件を分解すると「記録しなくていいもの」が明確になる——監視ツールと業務改善ツールを分ける、設計上の分水嶺だと考えています。

Vision LLMパイプラインとコスト最適化

記録したスクリーンショットと操作イベントの解析には、画像を理解できるVision対応LLMとしてClaude APIを採用しました。日本語UIを含むスクリーンショットの理解精度と、高解像度画像で座標が実ピクセルと1:1対応する点（UI要素の位置特定に有利）が決め手です。

ただし1回の記録セッションで画像は数十〜数百枚になるため、全部を高品質モデルに投げるとコストが成立しません。そこで2段構成のパイプラインにしています。

[大量スクリーンショット]
   │  ① 小型モデル（Claude Haiku 4.5）:
   │     画面の分類・重複除去・無意味フレームの間引き（安価・高速）
   ▼
[キーフレーム + 操作イベント]
   │  ② 高品質モデル（Claude Opus 4.8）:
   │     操作シーケンスの構造化・手順書生成・改善提案
   ▼
[手順書 / 改善レポート]

さらに2つのAPI機能を前提に設計しています。

• Batch API：手順書生成はリアルタイム性が不要なため、非同期バッチ処理（料金50%オフ）を基本とする
• Prompt Caching：手順書フォーマット定義などのシステムプロンプトをキャッシュし、繰り返し入力分のコストを大幅に圧縮

なお、解析層はLLMプロバイダを差し替え可能な抽象化を入れています。データを一切外に出せない顧客向けには、オンプレGPUでのローカルVLM（オープンモデル）への切り替えを将来の選択肢として確保しています。まずはクラウドAPIで品質を確立するのが現在のフェーズです。

中間表現JSON——出力形式を増やすための土台

FlowLensの内部では、キャプチャした操作も生成した手順も、すべてJSONの中間表現を正規形として扱います。クライアントが送る操作イベントはこんな形です。

{
  "session_id": "uuid",
  "seq": 42,
  "timestamp": "2026-07-17T10:23:45+09:00",
  "event": {
    "type": "click",              // click | input | key | window_change | scroll
    "app": "EXCEL.EXE",
    "window_title": "見積書.xlsx - Excel",
    "element": {                  // UIAで取得（取れない場合はnull → Vision LLMが補完）
      "name": "保存",
      "control_type": "Button",
      "path": ["リボン", "ホーム", "保存"]
    },
    "position": { "x": 120, "y": 48, "monitor": 0 }
  },
  "screenshot": "042.png"        // イベント直前のフレーム
}

解析サーバが出力する「手順ステップ」も同様に正規形を定義しています。

{
  "step": 3,
  "title": "見積書を保存する",
  "description": "リボンの [保存] ボタンをクリックします。",
  "app": "Excel",
  "screenshot": {
    "image": "042.png",
    "annotation": { "type": "rect", "x": 100, "y": 30, "w": 60, "h": 40 }
  },
  "source_events": [41, 42],
  "notes": ["Ctrl+S で代替可能"]   // 最適化提案
}

手順書はこの正規形からレンダリングして生成します。この分離のおかげで、出力形式の追加が「テンプレートを1枚増やす」だけで済みます。

スクリーンショットへの注釈（クリック位置の枠や番号バッジ）はPillowで焼き込みますが、注釈情報そのものは正規形に保持します。画像を作り直さずに再レンダリングでき、マスキング領域も同じ仕組みで出力時に再適用できます。

手順書の先へ——操作の最適化提案

中間表現には、もう1つの狙いがあります。操作イベントが構造化データとして蓄積されるため、操作パターンの分析がそのまま業務改善の材料になるのです。

• マウス操作の系列から、ショートカットや標準機能で置き換えられる操作を検出（例：メニュー3クリック → Ctrl+S）
• 同一セッション内・セッション間の繰り返しパターンから、無意味な往復や遠回りの操作列を発見
• 毎日発生する定型作業を、自動化（RPA化・スクリプト化）の候補としてレポート

「手順書を作る」がゴールではなく、記録された操作ログから手順そのものを良くしていく——ここがFlowLensで一番作りたい部分です。

よくある質問（FAQ）

まとめと現在地

FlowLensは現在、キャプチャPoCと解析エンジンのコア開発を進めている段階です。実際の業務での検証にご協力いただける先行モニター企業さまを募集しています。この記事のアーキテクチャに興味を持たれた方も、「うちの手順書問題を何とかしたい」という方も、ぜひ製品ページをご覧ください。