Odoo Knowledge: 内部 Wiki とナレッジ ベースを構築する

このガイドでは、記事のアーキテクチャから埋め込みコンテンツ、アクセス制御、テンプレート システム、顧客対応ナレッジのためのヘルプデスクとの統合まで、Odoo 19 Knowledge を使用した内部 Wiki の完全なセットアップと最適化について説明します。

重要なポイント

• 組織的な知識を論理的かつ直観的に整理する記事階層を設計する
• ブロックベースのエディターを使用して、テキスト、画像、表、コード、埋め込みビューを含むリッチな記事を作成します
• Odoo のライブ データ (リスト、グラフ、カンバン ボード) をナレッジ記事内に直接埋め込みます。
• 記事、セクション、ワークスペースレベルでアクセス制御を設定する
• 標準化されたドキュメント (会議メモ、プロジェクト概要、SOP) の記事テンプレートを作成する
• すべてのユーザーのお気に入りおよびパーソナライズされたコンテンツの検出を有効にする
• きめ細かな権限を備えたポータルやパブリック リンクを介して外部と知識を共有
• ナレッジをヘルプデスクと統合して、エージェント支援および顧客のセルフサービス解決を実現

---

ナレッジ アーキテクチャの設計

記事階層の計画

コンテンツを作成する前に、知識ベースの成長に合わせて拡張できる情報アーキテクチャを設計します。階層は、部門の編成方法ではなく、人々が情報についてどのように考えるかに従う必要があります。

ナレッジ > 記事 に移動し、最上位セクションを計画します。

ネスト戦略

Odoo Knowledge は無制限のネストの深さをサポートします。ベスト プラクティスは最大 3 ～ 4 レベルです。

Level 1: Section (Company Handbook)
  Level 2: Category (HR Policies)
    Level 3: Article (Remote Work Policy)
      Level 4: Sub-article (Equipment Allowance)

ネストが深くなると、コンテンツが見つけにくくなります。 4 つ以上のレベルが必要な場合は、階層を再考してください。コンテンツをより深く埋め込むのではなく、追加のレベル 1 セクションに分割します。

ナビゲーションと発見

Odoo Knowledge は、複数の検出パスを提供します。

• サイドバー ツリー: ユーザーがアクセスできるすべてのセクションと記事を示す階層ナビゲーション
• 検索: 埋め込みコンテンツを含む、アクセス可能なすべての記事の全文検索
• お気に入り: よく参照される記事の個人的なお気に入りリスト
• 最近: 最近閲覧した記事にすぐにアクセスできるようにします
• 私と共有: 同僚によって明示的に共有された記事

---

記事エディターの機能

ブロックベースの編集

Odoo 19 Knowledge は、Notion や Confluence に似た最新のブロックベースのエディターを使用します。各ブロックは、個別に移動、コピー、またはスタイル設定できる独立したコンテンツ要素です。

利用可能なブロックの種類

リッチフォーマット

テキスト ブロック内で書式設定を適用します。

• 見出し: 文書構造の H1 ～ H4
• 太字、斜体、下線、取り消し線: インライン強調
• インライン コード: 技術用語とコマンド用
• リンク: 内部 (他の記事へ) および外部 (Web サイトへ)
• 色: テキストと背景のハイライト
• 配置: 左揃え、中央揃え、右揃え、両端揃え

スラッシュコマンド

エディターで / と入力して、クイック コマンドにアクセスします。

---

埋め込みコンテンツ: 記事内のライブ Odoo データ

埋め込みの力

Odoo Knowledge の際立った機能は、ライブ Odoo ビューを記事内に直接埋め込む機能です。これにより、ナレッジ ベースが静的なドキュメント リポジトリから動的な運用ダッシュボードに変換されます。

Odoo ビューの埋め込み

/view コマンドまたは挿入メニューを使用して、Odoo ビューを埋め込みます。

埋め込みビューの構成

各埋め込みビューは以下をサポートします。

• フィルター: 表示されるデータを事前にフィルターします (例: オープンなチケットのみ、自分のチームのタスクのみ)
• 表示タイプ: リスト、カンバン、グラフ、またはピボット
• 列: 表示するフィールドを選択します
• グループ化: 整理して表示するために任意のフィールドごとにグループ化します。
• 制限: 表示されるレコードの最大数を設定します
• インタラクティブ性: ユーザーは埋め込みビューから完全な Odoo レコードをクリックして参照できます。

リアルタイム更新

埋め込みビューにはライブデータが表示されます。商談が CRM の段階に移行すると、週次ミーティングの記事に埋め込まれたパイプライン ビューが即座に更新されます。サポート チケットが解決されると、サポート ランブックのオープン チケット リストから消えます。これにより、従来の Wiki を悩ませていた情報が古いという問題が解消されます。

例: ライブデータを使用した販売ハンドブック

Sales Playbook Article
├── Overview (text)
├── Current Pipeline (embedded CRM Kanban, filtered to this quarter)
├── Top Opportunities (embedded list, sorted by expected revenue, top 10)
├── Win Rate by Source (embedded graph, last 6 months)
├── Competitor Matrix (table, manually maintained)
├── Objection Handling Scripts (text with callouts)
└── Proposal Templates (file attachments)

この 1 つの記事が、毎週のパイプライン レポートの電子メール、個別の競合他社分析ドキュメント、散在する営業スクリプトのコレクションをすべて 1 つのライブの常に最新の場所に置き替えます。

---

アクセス制御

権限レベル

Odoo Knowledge は 3 層の権限モデルを使用します。

権限の継承

デフォルトでは、権限は親記事から子記事にカスケードされます。

• 「会社ハンドブック」への編集者アクセス権がある場合は、すべてのサブ記事への編集者アクセス権があります。
• 子記事は親の権限をオーバーライドしてアクセスをさらに制限できます
• 親が提供する以上のアクセス権を子レベルで付与することはできません

ワークスペースレベルのアクセス

広範な組織アクセスのためにセクション レベルでアクセスを構成します。

外部ユーザーとの共有

特定の記事またはセクションを次の方法で共有します。

• ポータル アクセス: ポータル アカウントを持つ顧客およびベンダーは、指定された記事にアクセスできます。
• パブリックリンク: リンクを知っている人は誰でも閲覧できます (Odoo アカウントは必要ありません)
• 招待: 特定の記事を表示/編集するための招待を電子メール アドレスに送信します。
• 埋め込み: Web サイト モジュールを使用して記事を Web サイトに埋め込みます。

---

記事テンプレート

テンプレートシステム

テンプレートは、チームが繰り返しのコンテンツを文書化する方法を標準化します。記事に移動し、[テンプレートとして保存] をクリックして再利用可能にします。

推奨テンプレート

テンプレート変数

テンプレートには、作成者に特定の情報の入力を促すプレースホルダー テキストを含めることができます。

## Meeting Date: [Enter date]
## Attendees: [List all participants]
## Agenda
1. [First agenda item]
2. [Second agenda item]

## Discussion Notes
[Summarize key discussion points]

## Action Items
- [ ] [Action] — [Owner] — [Due date]

チーム メンバーがテンプレートから新しい記事を作成する場合、これらのプレースホルダーがガイドとして表示され、一貫性のある完全なドキュメントが確保されます。

テンプレートのカテゴリ

テンプレートをカテゴリに分類して簡単に見つけられるようにします。

• 一般: 会議メモ、ステータス更新、お知らせ
• プロジェクト: プロジェクトの概要、スプリントの振り返り、プロジェクトの終了
• 人事: 仕事の説明、面接のフィードバック、業績評価
• 技術: アーキテクチャの決定、ランブック、API ドキュメント
• 営業: 提案概要、競合分析、取引レビュー

---

お気に入り登録とパーソナライゼーション

個人的なお気に入り

すべてのユーザーは記事をお気に入りに追加して、すぐにアクセスできます。お気に入りの記事は、ナレッジ サイドバーの専用の「お気に入り」セクションに表示されます。これにより、各個人に最も参照されるコンテンツのパーソナライズされた「本棚」が作成されます。

お気に入りの使用例:

• 新入社員が最初の 1 か月間お気に入りのオンボーディング記事を選ぶ
• 営業担当者は競争力のあるマトリックスと価格設定ガイドを好んでいます
• サポート エージェントがお気に入りのトラブルシューティング記事トップ 10
• マネージャーはチームの会議メモとダッシュボードをお気に入りにします

おすすめ記事

ユーザーの役割または部門に基づいて記事の推奨を構成します。サポート部門の従業員がナレッジを開くと、ナレッジ マネージャーによって事前に選択された最も関連性の高い記事を含む厳選された「サポートに推奨される」セクションが表示されます。

個人的なメモ

ユーザーは自分だけが閲覧できる非公開記事を作成できます。これは、チームで公開する準備ができていない個人的なメモ、アイデアの下書き、ブックマーク、および作業文書に役立ちます。準備ができたら、非公開の記事をチームに表示される記事に昇格させることができます。

---

ヘルプデスクとの統合

エージェントの知識へのアクセス

最も効果的なナレッジ統合はヘルプデスクとの統合です。サポート エージェントがチケットを開くと、次の横にナレッジ パネルが表示されます。

1. 自動提案: チケットの件名と説明に基づいて、Odoo は関連するナレッジ記事を提案します。
2. 手動検索: エージェントはチケット ビューから離れることなくナレッジ ベースを検索できます。
3. レスポンスに挿入: [チケットで使用] をクリックして、記事のコンテンツ (または記事へのリンク) をチケットのレスポンスに直接挿入します。
4. チケットから作成: エージェントが新しい問題を解決すると、チケット解決から直接新しいナレッジ記事を作成できます。

顧客セルフサービス

ポータルを通じてサポート ナレッジ記事を顧客と共有します。

1. ナレッジベースで記事を「顧客対応」としてタグ付けします。
2. ナレッジセクションを表示するようにカスタマーポータルを設定します。
3. 顧客は利用可能な記事を検索および閲覧します
4. 記事の閲覧数とフィードバック (役に立った/役に立たなかった) により記事の効果を追跡します
5. 自動チケット応答および定型メッセージ内のナレッジ記事をリンクする

チケットのディフレクション

知識ベースのチケットディフレクションを実装します。

1. 顧客がサポート チケットの作成を開始したら、ナレッジ ベースで一致する記事を検索します。
2. 顧客が送信フォームに記入する前に関連記事を表示する
3. 顧客が答えを見つけた場合は、送信せずにフォームを閉じることができます。
4. 知識ベースの有効性を測定するために逸脱率を追跡する

これにより、一般的な問題に対するチケットの量が減り、同時に顧客エクスペリエンスが向上します。顧客はサポートの応答を待つことなく、すぐに回答を得ることができます。

ナレッジループ

サポートとナレッジの間に継続的な改善ループを構築します。

Customer reports issue → Support agent resolves →
  Is this a new issue? →
    Yes → Agent creates knowledge article →
      Knowledge manager reviews and publishes →
        Future customers find it via self-service →
          Fewer tickets for this issue
    No → Agent links existing article in response →
      Track usage count →
        High-usage articles promoted in portal

---

コンテンツ ガバナンス

所有権とレビューのサイクル

すべての記事には、正確性と最新性に対して責任を負う指定された所有者が必要です。

古いコンテンツの検出

古い記事を検出するための自動アクションを構成します。

1. 6 か月間更新されていない記事には「要レビュー」タグが付けられます
2. 記事所有者がレビュー活動通知を受け取る
3. 30 日以内に確認されない場合は、セクションマネージャーにエスカレーションします。
4. 60 日以内にレビューされない場合は、すべての読者に表示される「古い可能性がある」バナーを追加します

品質基準

ナレッジ ベースのコンテンツ品質基準を確立します。

• 完全性: 記事はトピックを完全にカバーしているか、補足リソースにリンクしている必要があります。
• 正確性: 情報は公開する前に対象分野の専門家によって検証される必要があります
• 明確さ: 対象読者に向けて書きます — 顧客向けの記事では専門用語を避けます
• 一貫性: テンプレートと命名規則に従います。
• 見つけやすさ: 適切なタグ付け、明確なタイトル、階層内の正しい配置

---

検索の最適化

コンテンツを検索可能にする

ナレッジ ベースの価値は、その検索エクスペリエンスによって決まります。記事の見つけやすさを最適化します。

タイトル: ユーザーがトピックについてどのように考えているかに合わせて、明確で説明的なタイトルを使用します。 「パスワードをリセットする方法」は「認証のトラブルシューティング手順 4.2」よりも優れています。

エイリアスとキーワード: ユーザーが検索する可能性のある代替用語や頭字語を追加します。 「休暇」に関する記事には、「休暇」、「休暇」、「有給休暇」、「休日」、「欠勤」などのキーワードを含める必要があります。

概要ブロック: 各記事は、重要な情報をまとめた簡単な概要で始めます。これにより、ユーザーは記事を開かずに検索結果から関連性を判断できます。

内部リンク: 関連記事を相互にリンクします。これによりナビゲーションが向上し、ユーザーが直接検索しなかった関連コンテンツを発見できるようになります。

検索分析

検索分析を監視してナレッジ ベースを向上させます。

• 最も検索された用語: 上位の検索用語に対応する記事があることを確認します。
• 結果ゼロの検索: 結果が返されない用語はコンテンツのギャップを示します
• 検索放棄: ユーザーが結果をクリックしなかった検索では、不適切な記事タイトルまたは概要が提案されます。
• 記事別のクリックスルー: どの記事が最も頻繁に検索され、読まれているか

---

よくある質問

Odoo Knowledge は Confluence や Notion とどう違うのですか?

Odoo Knowledge は、Odoo ビジネス アプリケーションからの埋め込みライブ データという独自の利点を備えた、同等の編集機能とコラボレーション機能を提供します。複雑な統合を行わないと、ライブ CRM パイプラインやインベントリ ビューを Confluence に埋め込むことはできません。すでに Odoo を使用している組織にとって、Knowledge はユーザーごとの追加コストなしで優れたコンテキスト統合を提供します。 Confluence と Notion には、より高度なコラボレーション機能 (コメント、メンション、ページ履歴の比較) がありますが、ビジネス データの統合がありません。

既存の Wiki コンテンツを Confluence または SharePoint からインポートできますか?

はい。既存の Wiki からコンテンツを HTML またはマークダウンとしてエクスポートします。 Odoo は、画像や添付ファイルを含む記事コンテンツの一括インポートをサポートしています。大規模な移行 (数千の記事) の場合は、Odoo API を使用して、適切な階層、タグ、権限を持つ記事をプログラムで作成します。 ECOSIRE は、Confluence、SharePoint、Google Sites、および Notion からナレッジ ベースを移行しました。

記事数に制限はありますか?

技術的な制限はありません。 Odoo Knowledge は数万の記事まで拡張できます。パフォーマンスはサーバー インフラストラクチャによって異なります。 Odoo は全文検索用に記事コンテンツにインデックスを付けるため、記事数に関係なく検索パフォーマンスは高速です。

顧客向けドキュメントにナレッジを使用できますか?

はい。特定の記事ツリーをポータル ユーザーと共有します。顧客向けの記事には、社内記事とは異なる表示スタイルとアクセス レベルを設定できます。 ECOSIRE クライアントの多くは、内部と外部の両方のナレッジ ベースを同じシステム内に維持しており、各閲覧者が何を参照するかをアクセス制御によって決定しています。

従業員にナレッジ ベースへの貢献を奨励するにはどうすればよいですか?

エントリの障壁を下げるテンプレートから始めます。最初から作成するよりもテンプレートに記入する方が簡単です。ナレッジを既存のワークフローに統合します (会議メモ テンプレート、インシデント後のレビュー テンプレート)。チームミーティングで貢献者を表彰します。チームごとに 1 週​​間に 1 つの新しい記事を作成するという目標を設定します。最も重要なのは、ナレッジ ベースを信頼できる唯一の情報源にすることです。電子メールやチャットで古い情報を見つけた場合は、ナレッジにリダイレクトして記事を更新します。

誰がどの記事を読んだかを追跡できますか?

はい。 Odoo は記事の閲覧数とユニークな閲覧者を追跡​​します。記事の所有者は、誰がいつ記事を読んだのかを確認できます。これは、コンプライアンス (ポリシーの承認の確認) やコンテンツの有効性 (どの記事が最も多くのエンゲージメントを獲得するか) の測定に役立ちます。

記事間で矛盾する情報を処理するにはどうすればよいですか?

単一情報源ポリシーを実装します。どのトピックについても、1 つの記事が信頼できる情報源となります。他の記事でその情報を参照またはリンクすることはできますが、情報を複製してはなりません。矛盾が発見された場合、記事の所有者は矛盾を解決し、参照しているすべての記事を更新する責任があります。 「正規記事」パターンを使用します。1 つの記事を決定的なものとしてマークし、他の記事を補足的なものとしてマークします。

---

ECOSIRE で組織の知識ベースを構築する

プロセス知識、顧客の状況、技術的専門知識、組織内の記憶など、従業員が退職する際に流出する知識は、把握されていない限り、かけがえのないものです。適切に構造化された知識ベースは、新入社員の 3 か月間の立ち上げと 3 週間の立ち上げの違いです。

ECOSIRE の Odoo 実装チーム は、テクノロジー企業、プロフェッショナル サービス会社、メーカー、カスタマー サポート組織向けのナレッジ マネジメント システムを構築してきました。当社の実装には、情報アーキテクチャの設計、テンプレートの作成、コンテンツの移行、ヘルプデスクの統合、ガバナンス フレームワークのセットアップ、チーム トレーニングが含まれます。

ECOSIRE に連絡 してナレッジ マネジメント戦略について話し合うか、継続的なナレッジ ベースの最適化とコンテンツ ガバナンスについての Odoo サポートおよびメンテナンス サービス を検討してください。

関連書籍:

• Odoo ナレッジベースのセットアップ
• Odoo 文書管理システム ガイド
• Odoo ヘルプデスク発券システム ガイド
• Odoo 実装サービス