👌
GitBookでヘルプサイトをAI管理にして、問い合わせ件数を3割減らした

denjiQ
2025/09/24に公開
GitBook
ヘルプサイト
idea
 概要みなさんGitBookというサービスはご存知でしょうか。

これはGit上で管理しているmdファイルをそのままWeb上でドキュメントサイトとしてホスティングしてくれるサービスです。もともとOSSでもあったようですが、SaaSとしてもサービスを提供しています。State of Docsを主催するなど、最近存在感が増しているかと思います。

この度GitBookにヘルプサイト管理を移行したところ、CS -> エンジニアへの問い合わせ量は３割削減し、顧客 -> CSへの仕様に関する質問は激減したため、その報告がてら記事としてまとめたいと思います。

 課題immedioは、顧客のウェブサイトに埋め込むことで面談モーダルを出すことができるSaaSプロダクトなのですが、その性質上、どうしても複雑になりがちです。基本的に顧客サイトの作りに依存して設定が変わるため、例えばiframe形式で埋め込まれたフォームの場合、設定をこうする、みたいな感じで、サイトの作りによって設定すべき値が変わります。
その複雑さの結果、問い合わせが増えがちです。そしてその問い合わせの負荷は顧客対応者（つまりCSとエンジニア）にきます。自分はこれまでに数社程度のBtoB SaaSのプロダクトに関わってきましたが、immedioのサポートコストはおそらくダントツに高いです。問い合わせの難易度も高く、数も多いという状態で、問い合わせ対応だけで一日が終わることもザラにありました。そのため、プロダクトの成長のためにはここの課題解決は非常に重要な意味を持っていました。

 GitBook導入前の社内体制やったことを紹介する前に、それまでの社内の体制をざっと紹介しておきます。
ヘルプはZendesk
Zendeskの記事でヘルプを更新。いわゆるCMS的な感じで、サイト上で記事を書いて、それをそのまま発行して公開するというような形。
更新は基本的に全てPdM。新機能リリース時には基本的にPdMが記事を書く。また、何かヘルプに追記してほしいことがあった時は、ワークフローをあげて、PdMに更新してもらう体制。

CSが問い合わせ対応
CSが顧客から来た問い合わせをZendeskや社内SlackやNotionを検索して情報を集め、返答できるものは返答し、返答できないものはテクサポ（下記）へ

テクサポ
エンジニアが窓口になって問い合わせ対応するところ。Slackでワークフローを起動させる運用。基本的には即日で優先対応。

上記のような体制がある中で、大きな課題としては下記がありました。

 課題1. 情報が集積されていない（情報が散逸している）Zendesk, Slack, Notionと、信頼できる情報がどこにあるのかわからない状態でした。基本的には、ヘルプであるZendeskが正なのですが、一方で足りない情報も多く、過去のSlackのスレッドやNotionを探って探し当てることもありました。

 課題2. ヘルプ更新が遅い例えばテクサポで対応したもののなかで、これはヘルプに書けそうだと思ったものをPdMに更新依頼するのですが、PdMが忙しいことが多く、更新が数週間後だったり、書いてもちょっとテクサポ側との認識がずれていたり、更新自体されなかったりすることがありました。PdMが1人しかいない状況で多忙だったので仕方がないとは思います。が、これも大きな課題でした。

 課題3. ヘルプサイトの構造が整っていないヘルプサイトの構造が秩序だっておらず、どこになんの情報が書いてあるのか全くわからない状態でした。そのため情報に辿り着くための難易度がそもそも高く、書いてあるのに情報にたどり着けないこともありました。また、構造が整っていないために、ある情報を書き足したいとなってもどこに書いて良いかわからず、時間がかかるという問題もありました。これは、上記のヘルプ更新が遅い問題とも大きく関連しているでしょう。どこにどう書いたら良いかわからないので、更新に時間がかかるということです。

 GitBookにヘルプサイトを移行したZendeskからGitBookというドキュメントサイト管理ツールにヘルプサイトを移行しました。

ヘルプサイト以外の社内体制は特に変わっていないので、CSやテクサポなどの窓口はそのままです。

GitBookを選定したのは、下記が主な理由です。
Gitとマークダウンで管理できるので、ベンダー依存が少ない
GitBookがダメになっても別のものに移行しやすい
DevinやClaude CodeなどのAIツールを活用しやすい

GitBookチームがAIに積極的
AI検索機能を始め、AIに力を入れており、その機能進化の恩恵を享受できそう

PdM / エンジニアどちらも更新ができる
詳しくは後述。

さて、では実際にGitBookを導入したことで何が良かったかを紹介していきたいと思います。

 良い点1. AI駆動なヘルプサイト更新Gitでmd管理しているので、何ができるかというと、AIが使いやすくなります。Devinにリポジトリを登録すれば、リポジトリの中身を読んで、いい感じにヘルプを更新してくれます。DevinはSlack上から呼べるので、例えば下記のような流れが実現できます。
CSからエンジニアにSlack上で問い合わせが来る
一通り調査をして解決する
Devinに「ヘルプを更新して」と頼む
スレッドの内容をもとにヘルプ更新のPRが作成される
PRを確認し、マージするとヘルプサイトに反映される
ヘルプ更新の一連の流れがスムーズですよね。Devinはスレッドの流れも読んでくれるので、特にコンテキストを渡さずとも、空気を読んで更新してくれます。もちろん特定のニュアンスを入れたいという時は、そのような旨をメッセージに足すだけで良いので、その辺りの柔軟さもあります。


サブのカレンダーにも連携できるかを聞かれている様子
また重要なのは、あくまでPRを出すだけだというところです。完全にAIに任せるつもりはなく、最終的な確認を人間がしっかりやるところを大事にしています。これはコーディングと同じで、最終的な品質の担保は人間が行うべきだからです。特にヘルプの場合、ヘルプが嘘をついているとそれだけで信用できなくなってしまうので、人間が間に入ってレビューすることはとても大事です。

あと課題点としては、ほとんどの場合、Devinが出してくれたものが一発で通ることはなく、追加で修正することです。大体の場合、「うーん、ちょっと違うなあ」と思うことがあります。この辺りはknowledgeなどでチューニングの余地はあるでしょう。ただ、それでも修正対象箇所を特定して、下書きをしてくれるだけでありがたいのは確かです。
サンプルとして、ヘルプ更新依頼が来て、それをDevinに任せるところも載せておきます。
これで来たのが下記PRなのですが、Slackスレッドの内容を確認していい感じに修正をしてくれています。また修正対象箇所を示さずとも、適切な箇所を探して、そこに修正を入れてくれています。これは後述の「サイトの構造化」が活きていると言えるかもしれません。
ちなみにDevinには下記のようなKnowledgeを渡して管理しています。
When creating or editing documentation for immedio-docs repository:
- Always reference the actual codebase to ensure documentation accuracy
- Do not include any information that cannot be verified in the codebase
- Documentation must be based on actual implementation, not assumptions
こちらは全てではなく一部の記述ですが、大事にしないといけないのは常にコードベースを確認させることです。

例えば新機能についてのヘルプをDevinに書かせると、場合によってはDevinは結構適当にヘルプ記事を書きます。夏休みの読書感想文みたいな感じで当たり障りのない適当な文章で記述したり、嘘をついたりもするので、この辺りはしっかりチューニングする必要があります。それでも100%の精度は出ないので、必ず人間がレビューすることが大事です。
またこの運用にする上で当然なのですが、ヘルプ更新はエンジニアがやっています。PdM一人にヘルプ更新が収束すると、どうしてもそこがボトルネックになって全体の更新が遅れます。例えば新機能のヘルプ更新となると負荷が高いので、こういった更新を分散できるのは大きな利点です。

ただリリースノートなど、問い合わせ起点ではなく、プロダクトの価値訴求に直結する内容は、顧客解像度の高いPdMに書いてもらっています。
ヘルプ更新に対するオーナーシップをエンジニアが取っていることについて。組織体制としてユニークに感じる人もいそうです。「ヘルプの更新なんてエンジニアの仕事じゃない」と思うのも一理あるとは思います。またヘルプ文章の品質面でも不安があるのもわかります。
ただ仕様に最も詳しい人がそれを記載するのがおそらく最も信頼できる情報となると思いますし、回り回って問い合わせ対応となって仕事が増えるというのもあると思います。

エンジニアがヘルプ更新をする際のボトルネックはおそらく「コードは書けるけど文章は思い浮かばない / かったるい」というところなのかと思っています。
過去と現在で大きく異なるのはAIで自動化できるようになったことです。つまりある程度ドラフトをAIが仕上げてくれるので、それに手を加えたり指示したりして直すだけで良いわけです。なのでゼロから記述するのと比べると格段にハードルは低いです。AIを使うこと自体もエンジニアの方が得意なことが多いため、組織全体の時間に対する成果の効率という観点から見ても、特にリソースの足りないスタートアップにおいて、エンジニアによるヘルプ更新は選択肢の一つではあるかなと思います。
Devinに偏った解説ばかりしたのですが、自分が一番大事だと思っているのはAIが使える土台が整っていることです。あくまでGitでマークダウンファイルを管理しているというだけのため、管理の仕方に応用が効き、AIの進化の恩恵を享受しやすい状態かと思います。例えばクラウド型のAIのDevinや、ローカル開発用のClaude Codeも使えますし、今後優秀なAIが出てきたらそれに乗り換えるのも容易でしょう。今後もGitやマークダウンといった技術がすぐに廃れることは考えにくいでしょうし、こういった枯れた技術にだけ依存していると、様々なツールを応用しやすいですね。

 良い点2. AI検索GitBookにはネイティブでAI検索が実装されています。これがとても優秀で、GitBook本体のドキュメントサイトを見るとわかりやすいのですが、なんとチャット形式でAIに質問ができます。

このAIはドキュメントサイト全体だけでなく、これまでの会話の情報もコンテキストに入れてくれるので、個々のヘルプサイトに特化した高性能なチャットボットを顧客に展開できます。

これはぜひGitBookのドキュメントサイトで実際に触ってもらって確認してもらいたいです。とても体験がよく、精度も非常に高いです。
衝撃的だったのは、仕様を完全に把握した上で、機能の使い方を適切に提案してくれたことがあったことです。

ある日、面談の参加者以外が代理で予定を変更したいという顧客要望が来たので、それをAIに流してみたところ、「リスケ機能」を使えば良いという返答が来ました。実際にAIに流したのは顧客からの文章をそのままコピペしただけのものだったのですが（下記画像を参照）、この返答の精度に衝撃を受けました。実際、私も、これに対してはリスケ機能を使うのがベストだと考えていたからです。
おまけにどこでリスケができるかまで示してくれています。これはプロダクトの仕様を完全に把握していないとできないことでしょう。この精度の回答がいつでも得られるわけで、仕様理解度の高いサポートデスクが24時間稼働しているような感覚です。

 良い点3. PdM / エンジニアどちらも更新ができるこれもGitBookのすごいところですが、Gitで管理しているからエンジニアしか更新できないと思いきや、PdMなどのビジネス側のメンバーでもWebサイト上でCMSライクに簡単に更新ができるようになっています。これもGitBookにした理由の一つです。
このようにWYSIWYGライクに編集ができるため、特にGitに対する知識がない人でも修正ができます。プルリクエストをベースにしているので、例えば誰かレビューをリクエストすることも可能です。詳しくはこちらを参照。

 その他GitBookには他にも色々と便利機能があるので、箇条書きで紹介してみます。

GitHub連携がスムーズ。初回設定時に迷ったことはなかった
GitHubとリンクしていると、PRを出した時にGitBookのプレビューを自動生成してくれる

カスタムドメインを発行できる

monorepo構成に対応している
例えば /product-a /product-b という形で、それぞれのプロジェクトを一つずつスペースに紐づけられる
スペース: GitBook上での管理単位


 意識したこと全体として一つ大きく意識したのは信頼できる唯一の情報源として機能させることです。

Zendesk, Slack, Notionと情報源が散乱している状況は、管理がしづらく、また顧客にとっても社内ユーザーにとっても混乱を招きますし、不便なだけです。スケールもしていきません。このような状況を脱するため、プロダクトに関することはできるだけ一つの情報源に寄せるようにしようと思いました。

これを大きな目標として、以下のようなことを行なっています。

 構造を定めること大きく、下記のセクションに分けています。
リリースノート
ガイド（トラブルシューティング系もここ）
管理画面の各ページに1:1で対応する各セクション
「管理画面の各ページに1:1で対応する」とは、管理画面上の１URLに対して、一つのヘルプページがあるイメージです。immedioだと「日程調整URL」というページで一つのURLが区切られているので、その単位でヘルプページを切っています。
こうしておくと、機能追加・修正時に、書く場所に迷わないというメリットがあります。以前までだと、どこにどのような情報が収まっているかわかりづらかったのですが、画面単位で分かれていることによって大体どこに書いてあるか推測がつくようになります。これによって、機能の更新があったとしても、記述されている場所に辿り着きやすいです。

リリースノートやガイドは、機能を横断して解説する時に使います。例えば初期設定ガイドは、どうしても各ページをいったりきたりするため、ページで区切ることはできないからです。

 宣伝すること@channelでSlack通知して宣伝するのは当たり前のこと、ことあるごとに「新ヘルプのAIが優秀」と新ヘルプリリース時にAI検索の使い方と一緒に触れ込みまくりました。何度も言っていると共鳴してくれる人は一定数いてくれて、特にCSにはAIが優秀というのが伝わったのか、すぐに使ってくれるようになり、顧客にも定例で宣伝してくれるようになりました。


AI検索でチャット機能が使えるようになった時の宣伝
やっぱり機能があるだけでは存在がわからなかったりするので、社内に対して宣伝していくと、自然と顧客にも広がっていくのだと思いますし、そもそも機能として優秀なので、きっかけがあればあとは自然に広がっていくのだと感じます。

 とにかく爆速で更新すること「ヘルプには情報が全て集積している」という信頼感を醸成するため、テクサポに上がってきた問い合わせは基本的にほとんどヘルプに反映させていますし、ヘルプ更新リクエストがあったら即日対応しています。

「ヘルプにはないだろうから直接聞こう」となってしまうのは、そもそもヘルプに対する信頼感がないからだと考えて、それを払拭するように徹底的に更新速度を早めています。

これが実現できるのは、ヘルプ更新に対するオーナーシップを問い合わせ対応側であるエンジニアが取っているからだと考えています。

 成果とまとめ上記を行った結果、CS -> エンジニアへの問い合わせ量は３割削減し、顧客 -> CSへの仕様に関する質問は激減しました。前者は統計の結果で、後者はCSからのフィードバックとしてもらいました。数値として見せられるのは前者だけではありますが、この結果だけを見ても、GitBookを導入してとても良かったと思っています。


直近数ヶ月のテクサポへの問い合わせ件数。8/1に新ヘルプへ移行
8/1に新ヘルプへ移行したのですが、それまで大体70件以上あったのが３割ほど減っています。移行してすぐに効果が出ているのが面白いところです。この辺りは宣伝の効果が活きているのかと思います。9/23時点の集計ですが、9月の着地見込みは40件程度で、8月よりさらに効果が出そうです。
ヘルプサイトに課題を感じている方にGitBookはおすすめのサービスです。Gitでmdファイル管理しているだけなのでベンダーロックイン要素が少なく、もし「GitBook失敗したなー」となったとしても、他サービスに乗り換えやすいのもメリットです。

日々の問い合わせに向き合う人に、この記事の内容が参考になれば幸いです。