加速するプロダクトの進化に追従せよ！ヘルプページ作成自動化への道のり
公開日：
更新日：こんにちは。Autify の Customer Support Engineer の Iwa です。
Customer Support チームでは AI Ops チームを新設し、AI チャットボットの活用やドキュメント運用の自動化など、AI を活用した日常業務の効率化に取り組んでいます。AI チャットボットの導入については、別記事「新プロダクト『Autify Nexus』リリースとお問い合わせ増を乗り切る！AIチャットボット(Fin)導入と成果」で詳しく紹介していますので、ぜひご覧ください！
今回はもう一つの取り組みである Autify 製品のヘルプページ作成を自動化していくまでの道のりをご紹介します。
運用破綻の危機
ヘルプページの作成・運用は多くを人の手に頼っており、大きく2つの課題を抱えていました。
- 人手コスト: 仕様調査・執筆・日英韓3言語への展開を、リリースのたびに手作業で実施。1記事あたりの工数が大きく、リリースが増えるほど負荷がかさむ。
- 属人化: トンマナやレビュー基準が担当者の経験に依存し、作業も特定メンバーに偏りがち。スタイルの一貫性を保つのも困難。
そこに拍車をかけたのが、プロダクト数の増加とリリース頻度の高さです。Autify NoCode（Web / Mobile）に加え、昨年は Autify Nexus、今年は機能強化されたAutify Genesis の一般提供を開始し、Nexus は毎週・Genesis は週に複数回のペースでリリースを行っており、半年で100回超のリリースに達しています。手作業前提の運用が破綻するのも時間の問題でした。
どこから手をつけるか
施策を検討するにあたり、まずドキュメント業務を工程に分解し、どこから着手すれば一番効くのか を見極めることから始めました。
各工程を「自動化できるか」「負荷が高いか」の2軸で仕分けていきます。
- ✴️ 自動化の余地があり、負荷も高い（投資対効果が大きく、優先度高）
- ❇️ 自動化の余地があるが、負荷は高くない
仕様確認・執筆・翻訳・レビューのように、人手コストの大半を占める記事作成周辺の工程に ✴️ が集中しました。一方、タスク作成や記事公開などの前後工程は ❇️（負荷は低いが自動化可能）に並びます。
この分布を踏まえ、進め方を2つのステップに分けました。
- 2025 Q4（フェーズ1）: まず ✴️ の個別タスクに絞り、自動化の実現性を検証する
- 2026 Q1-Q2（フェーズ2）: ❇️ も含めて、ワークフロー全体を再構築する
次章以降で、この2フェーズの具体を紹介します。
フェーズ1：n8n × Devin → Genesis による半自動化
きっかけと狙い
ドキュメントに関するタスクは、Notion の DB でチケット管理し、Document360 というサービスを利用し記事の執筆・公開をしていました。
フェーズ1は、既存の運用に手を入れずに始められることを主眼に置き、✴️ のタスクを個別に実施できるワークフローを作成しました。
ワークフローの基盤には n8n を採用しました。n8n はノードを繋いでワークフローを組むオープンソースの自動化ツールで、Slack・Notion などの SaaS 連携ノードに加え、AI エージェント向けのノードも標準で揃っています。AI エージェントを組み込んだワークフローを短時間で組み立てられた ことも、この施策を進める後押しになりました。
進め方としては、まず Gemini の Gems で個別タスクごとに必要な情報・プロンプト・アウトプットを検証するところから始め、おおよその精度を確認できた段階で n8n のワークフローに組み立てていきました。
Slack で起動する4つの自動化ワークフロー
ワークフローは、普段利用しているツールで起動できるようにしたかったため、Slack のメニューを自作し、メンションで起動できるようにしました。
対応するタスクは4つあります。作成フローで生成する仕様書と整備したライティング・ガイドラインを AI ブロックのプロンプトに渡し、ドラフト・翻訳・レビューを生成する流れとしています。
実際にワークフローを起動するときは、Slack 上で次のようなフォームから対象タスクの URL と指示を渡します。
送信すると、依頼内容の受付から完了報告までが Slack のスレッドに流れていきます。
出来上がったドラフトには、機能の利用手順から留意点まで踏み込んだ内容が含まれます。後述するツールでプロダクトのソースコードを参照しながら生成しているため、細かい仕様や挙動が正確に反映され、これまで仕様確認・動作確認に費やしていた時間を大幅に削減できました。
一度作成したワークフローはインプットとアウトプットを継続的にモニタリングし、気になる箇所は少しずつ改善しています。
たとえば、記事の執筆や翻訳のたびに、UI に表示している文字を正確に記載・レビューする作業は地味に辛く、品質のばらつきにもつながっていました。そこで、仕様書に各言語の UI 用語対応表 を持たせて AI ブロックに渡すようにし、正確な記事が作れる状態に整えました。小さな改善ですが、こうした積み重ねにより全体の精度を押し上げることができました。
Devin から Genesis への移行
プロダクトのソースコードを利用した仕様調査は、当初、自律型 AI ソフトウェアエンジニアの Devin（Cognition Labs 提供）に任せていました。リポジトリを読み解きながらタスクを進めてくれる汎用のエージェントで、ヘルプ記事のために必要な仕様の調査でも十分機能していました。
その後、これを自社サービスの Autify Genesis に置き換えました。Autify Genesis はもともと QA 向けの SaaS ですが、プロダクトのリポジトリを連携し AI エージェントを利用したワークフローを組むことができ、サポート業務でも活躍しています。
Autify Genesis について、詳しくはプロダクトページ をご覧ください！
取り組みの効果
フェーズ1の運用を始めて数ヶ月、効果は数字に現れました。新規記事1本あたりの作成時間は60分から15分まで圧縮され、3ヶ月単位の記事リリース数も導入前の15件から導入後の45件へと3倍に伸びました。
数字以上に印象に残っているのは、運用が定着した頃にチームメンバーから「もう前の運用には戻れない」と言ってもらえた瞬間でした。日々の負荷の重さと、自動化が体感としてもたらした変化を端的に表してくれた言葉だったと思います。
一方で課題も残っています。負荷がかかる工程は半自動化できたものの、そうなってくると ❇️ 自動化の余地があるが、負荷は高くない 工程が面倒に思えてきます。
そして完全な自動化を考えたときに、既存の運用を見直す必要が出てきました。
フェーズ2：docs-as-code（GitBook）× Genesis
なぜ docs-as-code へ移行したのか
フェーズ1は「既存運用に乗せる半自動化」でしたが、運用を続けるうちに、ドキュメントそのものを Git で管理する（docs-as-code） ほうが、以下の点で AI エージェントとの相性が良いと分かってきました。
- ヘルプページ全体の構造を理解しながら新規作成・既存編集ができる
- AI エージェントが各工程の作業をリポジトリ上で完結できる
- ガイドラインやルール、手順をドキュメントの作業と並行して管理・改善できる
ちょうど新プロダクトのリリースが重なるタイミングでもあったため、既存のドキュメント運用を改修するのではなく、GitBook × GitHub で一から立ち上げることにしました。
GitBook は Markdown でドキュメントサイトを構築・公開できるサービスです。GitHub と双方向に同期できるため、リリース作業を含めた全ての工程をリポジトリ上で完結できます。加えて Web UI から記事を直接作成・編集することもでき、エンジニア以外のメンバーも運用に参加できる点も採用の決め手になりました。
スタイルガイドと作業スキルの整備
新しい運用を立ち上げるにあたり、フェーズ1で培ったライティングのノウハウを スタイルガイドとしてブラッシュアップ し、これまで各メンバーの暗黙知に依存していた各工程の手順も明文化して リポジトリに集約 しました。これにより、AI エージェントが同じ品質で自律的に作業できる環境を整えました。
参考までに、実際のリポジトリ構成と、整備したルール・ガイドラインの一部を紹介します。
リポジトリ構成
help-docs/
├── .agents/skills/ # AI エージェント用スキル
├── docs/
│ ├── guidelines/ # 表記・構成規約
│ └── rules/ # 作業フェーズ別ルール
└── {product}-docs/ # 製品単位の docs セット
ルールとガイドラインの参照構造
docs/rules/ 配下には、作成・編集・翻訳・レビュー・構造変更・公開・Issue 起票・リリースノートなど 工程ごとのルール をまとめており、作業開始時にスキルで該当フェーズを参照します。
docs/guidelines/ には、コンテンツ設計（記事種別・構成・テンプレート・カテゴリ階層）と スタイルガイド（文体・書式・表記規則）を集約しています。
ガイドラインの一例：アラートの種類と使い分け
一例として、記事で利用するアラートの使い方を明文化しました。 info / success / warning / danger の4種類を利用し、それぞれの使い分けを以下のように定義しています。
info（補足） — 作業の遂行に必須ではないが、知っておくと役立つ補足情報や例外的なケースに使用します。 例：共有設定を有効にすると、チーム全員が閲覧可能になります。 success（ヒント） — 効率的な操作方法、ショートカット、ベストプラクティスなど、ユーザーの利便性を高める情報に使用します。 例：「?」キーを押すと、ショートカット一覧を表示できます。 warning（警告） — 操作ミスによって発生するトラブルや、ユーザーが目的を達成するために見落としてはならない必須の情報を強調します。 例：保存せずにページを閉じると、入力内容は破棄されます。 danger（重大な警告） — データの消失、セキュリティリスク、課金発生など、不可逆的または重大な損害を招く恐れがある場合に使用します。 例：実行すると、関連するすべてのデータが完全に削除されます。
Genesis のワークフローを利用した完全自動化
ガイドラインと手順を整備したことで、Autify Genesis のワークフロー を利用し、プロダクトのリリースをトリガーにドキュメントを更新するプロセスを一気通貫で実施する基盤が整いました。
Autify Genesis はプロダクトの GitHub リポジトリと連携でき、リリースイベントをトリガーにワークフローを起動できる 仕組みを備えています。プロダクトのソースコードに加え、ドキュメントリポジトリも同じく連携した上で、以下の一連の工程をワークフローに組み込みました。
ワークフローが完了すると Slack に PR とレビュー依頼を投稿し、人がレビューしてマージする運用としました。
Genesis のワークフローを利用した自動化では対象外とした記事素材の撮影は、人によるレビュー時に Claude などを利用して自動化しました。挿入箇所の特定・対象領域のクリップ・赤枠ハイライト・PII(個人を特定可能な情報)のダミー値置換・多言語（日英韓）の連続撮影・PR 追加の一連の工程を行うスキルを作成しています。
マージ後は GitBook 側にも自動で反映・公開されます。これで、ドキュメントを常にプロダクトのリリースに追従させ続けられる見込みです。
これは 現在進行中の取り組み です。フェーズ1から基盤も運用も大きく変わるため、各ツールの使い方やレビュー体制についてチームへのレクチャーを進めながら、本格運用の開始に向けて準備を進めています。
工夫した点と学び
ガイドラインとルールの明文化にあたっては、GitHub Docs の Best practices for GitHub Docs を大いに参考にしました。自分たちの運用に合わせてカスタマイズし、独自のガイドラインを作成しています。
AI エージェントにガイドラインやルールをどう参照させるかも試行錯誤しました。最終的に、網羅的に記述したガイドラインとルールから、作業手順を定義したスキルが該当ドキュメントだけを動的にピックアップする構造に落ち着いています。
仕様調査などのタスクごとのコンテキスト消費はまだ大きく、まずは ハイエンドのモデルで自律的に動かす ことを優先していますが、今後は手順や運用をよりコンパクトに整え、軽量モデルでも実施できる状態を目指していく予定です。
また、AI エージェントは 完了条件に強く引っ張られて動く ため、ガイドラインを参照させるだけではルールを守りきれない場面もありました。各作業フェーズのルールに完了条件を明示的に書き、エージェントが「完了とみなすために満たすべきこと」としてガイドを取り込むよう設計しています。
これから
AI エージェントの進化と、さまざまなツール・サービスとの連携強化により、これまで以上に活用の幅が広がっています。今回の取り組みを通じて、個人としてだけでなくチームとしても、GitHub や AI エージェントに関する知識やスキルが深まったのは収穫でした。
また、Autify Genesis をはじめとする自社サービスを実業務に組み込んだことで、社内発の活用事例や運用で得られたフィードバックをプロダクトに還元できるようになり、サービスそのものの改善にもつながりました。
今回の取り組みを足がかりに、サポート品質やプロダクトの向上を通じて、お客様に提供できる価値を高めていきたいと考えています。
