多くの人がよく知っているナレッジマネジメントの一形態があります。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ツールも初期状態では一般的です。ブランドの声、用語、コンテンツ基準、対象読者を知りません。合理的な出力はしますが、help centerでFin（当社のAIエージェント）が実際の顧客質問に答えるために使うコンテンツには十分ではありません。
メモリ：Operatorに持続する脳を与える
Operatorには会話スレッドを超えて持続するメモリ機能があります。小さなことのように聞こえますが、そうではありません。
持続的なメモリがなければ、すべての会話スレッドはゼロから始まります。スタイルガイドを再説明し、フレームワークを再説明し、先週、先月、1年前に設定したコンテキストを再確立します。これはAI版の毎朝新しい同僚を迎えるようなものです。
持続的なメモリがあれば、Operatorはワークスペースの知識を引き継ぎます。用語、基準、適用すべきフレームワークを知っています。一度コンテキストを構築すれば、時間とともに蓄積されます。
メモリへの追加は簡単です。Operatorの会話で「これをメモリに保存して」と伝えるだけで十分です。Operatorは保存を確認し、その情報は以降のすべての会話で利用可能になります。
現在Operatorのメモリに保存しているものは以下の通りです。
スタイルガイド — トーン、フォーマット、キャピタリゼーション、リンク規則、米国英語の綴り、用語ルールを含みます。
コンテンツ準備フレームワーク — すべてのコンテンツが公開前に評価される14の要素。
命名規則 — このワークスペースでの記事、内部記事、マクロのタイトル付けルール。
ワークスペースのコンテキスト — 誰が何を所有し、どのチームがどの領域を担当しているか。
実際の効果：Operatorにコンテンツのドラフトや更新を依頼すると、すでにどのようなトーンで、どの用語を使い、どの基準を満たすべきかを知っています。毎回それらを指示する必要はありません。これが基準です。
スタイルガイド：組み込むことの重要性
スタイルガイドは一貫して適用されて初めて機能します。人間が管理するスタイルガイドの問題は、一貫性が人によって左右されることです：どれだけ最近読んだか、その日の認知負荷、英国英語に戻ってしまった段落に気づいたかどうかなど。
スタイルガイドがOperatorのメモリにあれば、毎回適用されます。すべてのドラフトは見出しに文頭大文字を使い、すべての記事は「teammate」を使い「agent」は使いません。すべての番号付きリストは同じ構造に従います。スタイルガイドは理想ではなく実際の出力になります。
また、ドラフト作成を自信を持って任せられます。Operatorに記事の新規作成を依頼すると、ブランド整合性の確認は不要です。それはすでに処理されています。
スタイルガイドをOperatorのメモリに保存する方法
まずこれを行ってください。一度保存すれば、Operatorはワークスペースで作成または編集するすべての記事にスタイルガイドを適用します。
Fin AI Agent > Operatorへ移動します。
作成画面（Operatorウィンドウ下部のテキスト入力）に次の文を入力します：『これは私たちのknowledge baseスタイルガイドです。新規記事作成や既存コンテンツ編集時は常にこのガイドに従う必要があります。』その下にスタイルガイドのテキストを直接貼り付け、送信を押してOperatorにメッセージを送ります。
Operatorがスタイルガイドを保存すると、次のような確認メッセージが表示されます：「今後の会話のために保存しました。ワークスペースのknowledge baseコンテンツ作成・編集時にこのスタイルガイドを適用します。」確認が表示されない場合は、再度メッセージを送信してください。
設定が正しく行われたか確認するには、help center内の記事がスタイルガイドに沿っているかOperatorにチェックさせてください。Operatorは逸脱を指摘し修正案を提案します。以下はスタイルガイド保存確認と監査開始の例です。
注意：スタイルガイドを更新するには、更新版を同じ指示文と共にOperatorに送信してください。Operatorがガイドの適用を停止した場合は、次回会話開始時に再送してリマインドしてください。
Operatorに質問させる
私が理解するまでに時間がかかったことの一つは、Operatorが質問するのは機能であり問題ではないということです。
初期の頃、Operatorがただ生成するのではなく明確化を求めるとイライラしました。私は速さを求めていました。学んだのは、明確化の質問はシグナルであり、私の依頼が曖昧な箇所、コンテンツのギャップ、十分な情報を与えていない箇所を示しているということです。
今では積極的に質問を促します。複雑なタスクを始める時は「不明点や追加情報が必要なら、ドラフト前に質問してください」と付け加えます。出力は良くなり、反復は速くなり、Operatorの質問は私が気づかなかった欠落を浮き彫りにします。
私がよく使うプロンプト
良いプロンプトはツールです。以下は私がよく使うものです。各プロンプトはOperatorとの会話スレッドで送信され、Operatorはknowledge baseを検索し関連コンテンツを取得し、提案を返します。コピーして自分のプロセスに合わせてください。
コンテンツ準備チェック
記事作成や編集後に、14のコンテンツ準備要素すべてに対してチェックするために使います。
「この記事はメモリに保存されたコンテンツ準備フレームワークに対してどう評価されますか？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のメモリに保存できる完全なコンテンツ準備フレームワークです。
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.
コンテンツ準備チェックの実行方法
記事作成や編集後に「コンテンツ準備チェック」プロンプトを実行します。Operatorは14要素すべてについて合格か改善が必要かを判定し、改善案を具体的に示します。問題を指摘するだけでなく修正案も作成します。
私はOperatorの回答をレビューし、同意する提案を承認し、表現を変えたいものには反論し、繰り返します。
一度で完璧にはならないのが普通です
コンテンツが14要素すべてに初回で合格することは稀です。ある要素の修正が別の要素のギャップを生むこともあります。表面的な問題が解決して初めて構造的な変更が必要になることもあります。
これはフレームワークやツールの失敗ではありません。品質の実態です。14要素中10要素に合格する初稿は良い初稿です。残り4要素を修正する3回目のチェックはFinと顧客が読むのに優れたコンテンツです。
フレームワークが最初から完璧をもたらすのではなく、そこに到達するための信頼できるシステムを提供します。使う前は記事が完成したかどうか一貫した判断基準がありませんでしたが、今はあります。14要素すべて合格すれば完成です。