多くの人がよく知っているナレッジマネジメントの一形態があります。5つのブラウザタブを開き、多数のドキュメントを照合し、help centerで半分覚えている記事を手動で検索し、火曜日の午後に12の記事の価格段落を一つずつ更新する作業です。

それはつい最近まで私の仕事でした。コンテンツの所在、内容、変更があった場合の矛盾点をほぼ百科事典のように頭の中に構築していました。その知識は私の頭の中にありました。つまり、私がオフィスを離れた瞬間や、変化が追いつかない速さで起きた瞬間に、問題が表面化し始めたのです。

それから、Fin Operatorをワークフローの中核として使い始めました。以前は数時間かかっていた作業が数分で終わるようになりました。この記事はhelp centerを維持するナレッジマネージャーとコンテンツチーム向けです。Operatorをワークフローに設定し、製品アップデート時に変更影響スキャンを実行し、コンテンツのギャップを埋め、14要素の準備フレームワークに基づいてすべてのコンテンツを検証するために使ってください。

注意: Fin Operatorは現在ベータ版です。Operatorが提案するすべてのコンテンツ変更は、公開前にあなたのレビューと承認が必要であり、自動的に公開されることはありません。

ベータ版のIntercomのAIアシスタントであるOperatorのスクリーンショット、Inboxインターフェースでの会話を表示

以前：手動のナレッジマネジメントの現実

製品の変更があった場合、例えば価格の更新、すべてのプランに展開される新機能、または廃止された統合など、私のプロセスは次のようなものでした：

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が答えるために使うコンテンツでは合理的だけでは不十分です。

メモリ：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.