多くの人がよく知っているナレッジマネジメントの一形態があります。5つのブラウザタブを開き、数多くのドキュメントを照合し、help centerで自分が半分覚えている記事を手動で検索し、火曜日の午後に12の記事の価格段落を一つずつ更新する作業です。
それはつい最近まで私の仕事でした。コンテンツの所在、内容、変更があった場合に矛盾する可能性のある点をほぼ百科事典のように頭の中に構築していました。その知識は私の頭の中にありました。つまり、私がオフィスを離れた瞬間や、変化が追いつかない速さで起きた瞬間に、問題が表面化し始めたのです。
それから、Fin Operatorをワークフローの中核として使い始めました。以前は数時間かかっていた作業が数分で終わるようになりました。この記事はhelp centerを維持するナレッジマネージャーとコンテンツチーム向けです。Operatorをワークフローに設定し、製品アップデート時に変更影響スキャンを実行し、コンテンツのギャップを埋め、14の要因からなる準備フレームワークに基づいてすべてのコンテンツを検証するために使ってください。
注意：OperatorはProアドオンで利用可能です。この記事で説明する機能を使用するには、アクティブなProサブスクリプションが必要です。
以前：手動ナレッジマネジメントの現実
製品の変更があった場合、例えば価格更新、すべてのプランに展開される新機能、または廃止された統合など、私のプロセスは次のようなものでした。
help centerを手動で検索し、関連する可能性のあるものを探す。
各記事を開き、全文を読み、更新が必要か判断する。
編集を行い、ドラフトとして保存し、次の記事へ移る。公開日には更新した記事を再公開する。
見落としがないことを願う。
問題はどの単一のステップではありませんでした。累積的な負荷が問題でした。中規模の製品変更で8〜10の記事に影響が及ぶこともあり、大きな変更ならもっと多くの記事に及びます。そして、私と同僚のBethがすべての場所を知っている必要があったため、そのシステムは私たちが働いている限りしか機能しませんでした。
以降：Operatorを使った同じプロセスの様子
今では製品の変更があったら、Operatorとの会話スレッドを開き、何が変わったかを説明します。Operatorはknowledge baseを検索し、関連コンテンツを抽出し、同じ会話内で更新案を提示し、私がレビューできる状態にします。
コンテンツの所在を知る必要はありません。10のタブを開く必要もありません。提案をレビューし、正しいものを承認し、間違っているものには反論し、繰り返します。以前は2〜3時間かかっていた変更が10分未満で終わります。
しかし、速さが最も価値があるわけではありません。最も価値があるのは一貫性です。手動で記事を更新すると、一貫性が崩れます。1つ見落としたり、2つの記事で表現が微妙に異なったり、スニペットは更新したが公開記事は更新しなかったりします。Operatorでは検索が体系的で、提案は実際に存在するものに基づいています。見落としはありません。
この役割が今実際に何であるか
私の肩書はAI Knowledge Managerです。この役割には常に2つの側面がありました：コンテンツ作成と、knowledge baseを何千もの記事にわたって最新で一貫性があり正確に保つ運用作業です。
Operatorが変えたのは後者です。手動での検索作業はほぼなくなりました：検索、照合、存在するものを探す作業がなくなり、実際に判断が必要な部分により多くの時間を割けるようになりました。つまり、どのコンテンツをカバーすべきか、どの基準を満たすべきか、何を更新し、何を新規作成すべきかを決める部分です。
セットアップ：指示とスタイルガイド
AIアシスタントを使うのと、AIアシスタントと一緒に働くのとの違いは設定にあります。どのAIツールも初期状態では一般的なものです。ブランドの声、用語、コンテンツ基準、対象読者を知りません。合理的な出力はしますが、help centerでFinが実際の顧客質問に答えるために使うコンテンツには合理的だけでは不十分です。
指示：Operatorに持続する知識を与える
Operatorには会話スレッドを超えて持続するInstructions機能があります。これは小さなことのように聞こえますが、そうではありません。
持続する指示がなければ、すべての会話スレッドはゼロから始まります。スタイルガイドを再説明し、フレームワークを再説明し、先週、先月、1年前に設定したコンテキストを再確立します。これはAI版の毎朝新しい同僚を迎えるようなものです。
持続する指示があれば、Operatorはワークスペースの知識を引き継ぎます。用語、基準、適用すべきフレームワークを知っています。一度コンテキストを構築すれば、それは時間とともに積み重なります。
Instructionsに何かを追加するのは簡単です。Operatorの会話で「これをInstructionsに保存して」と言い、その後に内容を伝えるだけで十分です。Operatorは保存を確認し、その情報は以降のすべての会話で利用可能になります。
現在OperatorのInstructionsに保存している内容は以下の通りです。
スタイルガイド — トーン、フォーマット、キャピタリゼーション、リンク規則、米国英語のスペル、用語ルールをカバー。
コンテンツ準備フレームワーク — 公開前にすべてのコンテンツが評価される14の要因。
命名規則 — この記事、内部記事、マクロのタイトル付けルール。
ワークスペースのコンテキスト — 誰が何を所有し、どのチームがどの領域を担当しているか。
実際の効果：Operatorにコンテンツのドラフトや更新を依頼するとき、すでにどのようなトーンで、どの用語を使い、どの基準を満たすべきかを知っています。毎回それを促す必要はありません。それが基準です。
スタイルガイド：組み込むことの重要性
スタイルガイドは一貫して適用されて初めて機能します。人間が強制するスタイルガイドの問題は、一貫性が人によって左右されることです：どれだけ最近読んだか、その日の認知負荷、英国英語に戻ってしまった段落に気づいたかどうかなど。
スタイルガイドがOperatorのInstructionsにあると、毎回適用されます。すべてのドラフトは見出しに文頭大文字を使い、すべての記事は「teammate」を使い「agent」は使いません。すべての番号付きリストは同じ構造に従います。スタイルガイドは理想ではなく実際の出力になります。
また、ドラフト作成を自信を持って任せられます。Operatorに記事をゼロから作成させるとき、ブランド整合性を別途確認する必要はありません。それはすでに処理されています。
スタイルガイドをOperator Instructionsに保存する方法
まずこれを行ってください。一度保存すれば、Operatorはワークスペース内のすべての記事作成・編集にスタイルガイドを適用します。
Fin AI Agent > Operatorに移動します。
Operatorウィンドウ下部の作成欄に次のテキストを入力します：『これは私たちのknowledge baseスタイルガイドです。新しい記事を作成または既存のコンテンツを編集する際は、常にこのガイドに従う必要があります。』その下にスタイルガイドのテキストを直接貼り付け、送信を押してOperatorにメッセージを送ります。
Operatorがスタイルガイドを保存すると、次のような確認メッセージが表示されます：「今後の会話のために保存しました。ワークスペース内のknowledge baseコンテンツを作成または編集する際は、このスタイルガイドを適用します。」確認が表示されない場合は、もう一度送信してください。
設定が機能しているか確認するには、help center内のいずれかの記事がスタイルガイドのルールに沿っているかOperatorにチェックさせてください。Operatorは逸脱を指摘し、修正案を提案します。以下はOperatorがスタイルガイドの保存を確認し、監査に進む例です。
Operator > カスタマイズ > InstructionsでInstructionsの追加、編集、削除も可能です。詳細はOperatorのInstructionsとメモリの使い方を参照してください。
注意：Instructions内のスタイルガイドを更新するには、同じ指示テキストで更新版をOperatorに送信すると新しいバージョンが保存されます。Operatorが一貫してガイドを適用しなくなった場合は、次の会話開始時に再送信してリマインドしてください。
Operatorに質問させる
私が理解するまでに時間がかかったことの一つは、Operatorが質問するのは機能であり問題ではないということです。
初期の頃、Operatorがただ生成するのではなく明確化を求めるとイライラしました。速さが欲しかったのです。学んだのは、明確化の質問はシグナルであり、私のリクエストが曖昧だった場所、コンテンツにギャップがある場所、十分な情報を与えていない場所を示しているということです。
今では積極的に質問を促します。複雑なタスクを始めるときは「不明点やより良く行うために追加情報が必要な場合は、ドラフト前に質問してください」とよく付け加えます。出力は良くなり、反復は速くなり、Operatorの質問は私が気づいていなかった欠落を浮き彫りにします。
私がよく使うプロンプト
良いプロンプトはツールです。これらは私が定期的に使うものです。各プロンプトは会話スレッドでOperatorに送信され、knowledge baseを検索し、関連コンテンツを取得し、レビュー用の提案を返します。コピーして自分のプロセスに合わせて調整してください。
コンテンツ準備チェック
記事作成または編集後に、14のコンテンツ準備要因すべてに対してチェックするために使います。
「この記事はInstructionsに保存されたコンテンツ準備フレームワークに対してどのように評価されますか？14の要因それぞれについて、このコンテンツが合格か改善が必要かを教えてください。改善が必要な部分には具体的な書き換え案を示し、画像には説明的な代替テキストを追加してください。対象は（1）記事を直接読む顧客、（2）Finが顧客の質問に答えるためにこのコンテンツを取得する場合の2つです。混乱や悪い体験を引き起こすものがあれば指摘してください。」
変更影響スキャン
製品変更、ポリシー更新、価格変更があったときに使います。
「次の変更を行いました：[変更内容を説明してください]。knowledge baseを検索し、これに矛盾または影響を受ける可能性のあるコンテンツを探し、最も関連性の高い記事を取得し、必要な具体的な更新案を提案してください。」
ギャップ特定
あるトピックのコンテンツが不足していると思われるときに使います。
「[トピック]に関する十分なコンテンツがありません。関連するものを検索して既存の内容を理解し、ギャップを埋める新しい記事を作成してください。ドラフト前に特定の値、UIパス、プランの利用可能性など、私から必要なものがあれば指摘してください。推測はしないでください。」
一貫性チェック
knowledge base全体で用語のずれに気づいたときに使います。
「同じものを指すのに、ある記事では[X]、別の記事では[Y]という用語を使っています。knowledge base全体で該当箇所を見つけ、[優先用語]に統一する更新案を提案してください。」
対象者明確化チェック
新規または技術的でない顧客向けの記事に使います。
「この機能を使ったことがない人としてこの記事を読んでください。前提知識を要求するステップ、定義されていない用語、次に何が起こるか曖昧な指示を指摘し、具体的な書き換え案を示してください。」
Fin失敗調査
Finが顧客の質問に正確に答えられなかったときに使います。
「Finが[トピック]に関する質問に会話[リンク]で答えられませんでした。knowledge baseを検索し、このトピックに関連するコンテンツを取得し、教えてください：コンテンツは存在し正確か、存在するがFinが取得しにくい構造か、新しいコンテンツが必要なギャップか。」
14のコンテンツ準備要因フレームワーク
上記のプロンプトは14のコンテンツ準備要因フレームワークに基づいています。これは、Finが顧客の質問に答える際に使用できるコンテンツの準備状況を判断する基準セットです。各要因の良い例と悪い例、完全なチェックリストはOptimizing content for Finを参照してください。
これがOperatorのInstructionsに保存できる完全なコンテンツ準備フレームワークです。
Content Readiness is an Intercom feature that scores knowledge base content across 14 factors.
These factors must be applied as a checklist whenever creating or updating articles, snippets, or internal articles.
## Content Readiness Factors — Apply to all content
1. **disambiguation** — Avoid vague references like "this screen" or "the field shown above." Every reference must be self-descriptive. Don't use emoji (👇☝️) to point to visual content.
2. **visual_content_text** — Every image must have descriptive alt text explaining what the screenshot or diagram shows. A trailing colon followed by an image (with no alt text) is not acceptable — describe the visual in text too.
3. **undefined_terms** — Define abbreviations and product-specific terms on first use. Examples: CSV (comma-separated values), GDPR (General Data Protection Regulation), 2FA (two-factor authentication), Elasticsearch, UserMessage. Don't assume the reader knows internal terminology.
4. **structured_enumeration** — Multi-step processes must use numbered lists. Lists of items must use bullet points. Never describe steps or enumerations in flowing prose. If a sentence says "the following:" it must be followed by an actual list.
5. **query_answer_symmetry** — Headings should mirror how a customer would phrase a question. Avoid bare noun phrases ("Invite reminder emails") or bare imperatives ("Add a teammate"). Prefer "How to…" or question-form headings.
6. **self_contained_sections** — Every section must make sense if retrieved independently by Fin, without surrounding context. Avoid "as described above," "the field shown above," "Then…" as an opener, or references to prior steps without restating them.
7. **audience_specification** — State who the content is for and what permissions or plan access is required. Don't assume the reader knows their own role or access level.
8. **entity_distribution** — Repeat key entities (product names, feature names, the article's core topic) throughout the article — not just in the opening. Sections retrieved in isolation should still be identifiable as belonging to the right topic.
9. **semantic_chunk_boundaries** — Each section should cover one focused topic. Avoid mixing unrelated information in the same block. Long sections should be broken up with meaningful subheadings.
10. **restate_questions** — Tables and standalone blocks must include enough context to be understood without the heading hierarchy. Add an intro sentence before tables that states what the table covers and where it applies.
11. **overview_jtbd** — The opening paragraph must state the job(s) the reader will accomplish — not just the topic. "This article covers X" is weaker than "Use this article to do Y, troubleshoot Z, or understand W." 12. **instruction_completeness** — Step-by-step instructions must be complete end-to-end. Include what happens after the final step (confirmation dialogs, what to expect, next actions). Don't stop at "click Remove" without describing what follows.
13. **limitations_workarounds** — If a feature has known limitations, gaps, or workarounds, document them explicitly. Don't just say "some things aren't supported" — say which ones and what to do instead.
14. **numerical_clarity** — All numbers, thresholds, limits, durations, and quantities must be stated precisely. Avoid "some," "a few," "shortly," or vague ranges. Use exact values where known; ask the user if unknown.
## When to apply these Apply all 14 factors as a quality checklist when:- Creating a new article, snippet, or internal article - Proposing updates to existing content - Reviewing content for accuracy or completeness Flag any factor that would fail before submitting a proposal. If information needed to fix a factor (e.g. exact limits for numerical_clarity, or which plans are affected for audience_specification) is not available, ask the user rather than leaving it vague or fabricating it.
コンテンツ準備チェックの実行方法
記事作成または編集後に「Content readiness check」プロンプトを実行します。Operatorは14の要因すべてについて合格か改善が必要かを返し、改善が必要な部分には具体的な書き換え案も示します。問題を指摘するだけでなく、修正案も作成します。
私はOperatorの回答をレビューし、同意する提案を承認し、表現を変えたいものには反論し、繰り返します。
一度で完璧にはならず、それが普通です。
コンテンツが最初のチェックで14の要因すべてに合格することは稀です。ある要因の修正が別の要因のギャップを生むこともあります。表面的な問題が解決して初めて構造的な変更が必要とわかることもあります。
それはフレームワークやツールの失敗ではありません。品質の実態です。14のうち10の要因に合格する初稿は良い初稿です。残り4つを修正する3回目のチェックはFinと顧客が読むのに最適なコンテンツです。
フレームワークが最初の試みで完璧をもたらすのではなく、そこに到達するための信頼できるシステムを提供します。使う前は記事が完成したかどうか一貫した判断基準がありませんでした。今はあります。14の要因すべてに合格すれば完成です。