シグナルスコアリングパイプライン：決定論的ナレッジトリアージ

ナレッジマネジメントの大半は「感覚」で成り立っています。「重要そうだから」という理由でノートを保存する。6ヶ月後には7,000件のノートが溜まり、どれが本当に重要なのか分からなくなっています。私はそれを教えてくれる決定論的スコアリングパイプラインを構築しました。

このシステムは733行のPythonで書かれています。入力されるすべてのシグナルを4つの重み付き次元でスコアリングし、複合スコアを算出し、12のドメインフォルダ、手動レビュー用のインボックス、またはスキップのいずれかにルーティングします。手動でのタグ付けは不要です。「後でレビューする」と言って結局やらないこともありません。アルゴリズムが判断します。

TL;DR

重み付き複合スコア（関連性35%、実用性30%、深度20%、信頼性15%）が各シグナルに0.0〜1.0の評価を付けます。ルーティングは3つの閾値を使用します：0.55以上はドメインフォルダに自動書き込み、0.30以上は手動レビューのキューに入り、0.30未満はサイレントにスキップされます。14ヶ月間で7,700以上のノートを処理し、Development（2,837件）とDesign（1,709件）が分布の大半を占めています。最も興味深い欠陥は、深度次元がコンテンツの品質ではなくメタデータの豊富さを測定している点です。そのため、花の写真についてのタグが充実したツイートが0.85のスコアを獲得してしまいます。

「感覚」の問題点

私はObsidianをナレッジベースとして使っています。RSSフィード、Twitterブックマーク、GitHubスター、ニュースレター、手動キャプチャからシグナルが流入します。パイプライン導入前は、すべてのシグナルが単一のインボックスフォルダに入っていました。2ヶ月以内に400件以上の未処理ノートが溜まりました。

よくあるアドバイス（「毎週レビューして、都度タグを付けて、フォルダシステムを使いましょう」）は、レビューが実行されることを前提としています。実行されません。インボックスは書き込み専用になります：アイテムは入るが出ていかない。キャプチャしたナレッジは、キャプチャしなかったナレッジと機能的に同じです。Clay Shirkyはこの問題を的確に表現しました：「情報過多ではない。フィルターの失敗だ。」⁸

7,700以上のノートを読むより速く評価でき、一度定義した基準を均一に適用できるシステムが必要でした。レコメンドエンジンではなく、スコアリングアルゴリズムです。

複合スコア

スコアリングの計算式は、多基準意思決定分析（MCDA）における標準的な手法である4次元の重み付き線形結合です：⁹

composite = (
    relevance     * 0.35 +
    actionability * 0.30 +
    depth         * 0.20 +
    authority     * 0.15
)

各次元は0.0から1.0の間の浮動小数点数を生成します。計算式は複合スコアを小数第3位まで丸めます。重みは意図的な優先順位を反映しています：自分にとって重要なもの（関連性）が使えるもの（実用性）より優先され、メタデータの豊富さ（深度）より優先され、ソースの信頼度（信頼性）より優先されます。¹

4つの次元

関連性（35%）：興味のマッチング

関連性は、40以上のエントリを持つ手動キュレーションされたキーワード辞書を使用し、各エントリは0.15（nft）から1.0（claude code、swiftui）までスコアリングされています。スコアリングは最高マッチと全マッチの平均をブレンドします：

# 60% best match, 40% average of all matches
return min(1.0, best_score * 0.6 + avg_score * 0.4)

マッチなしのアイテムには0.0ではなく0.25のベースラインが付与されます。未知のトピックに対するペナルティは、無関係なトピックよりも軽くなるようにしています。このベースラインは最も頻繁にチューニングされるパラメータです：高すぎると無関係なコンテンツがインボックスに溢れ、低すぎると本当に新しい興味の対象が目に触れる前にフィルタリングされてしまいます。²

実用性（30%）：学習ポテンシャル

実用性は22のアクション指向キーワードに対してマッチングします：tutorial、guide、how-to、build、github.com。URLには特別な処理が適用されます：

if "github.com" in url:
    hits += 2  # Repositories are inherently actionable
if "/docs" in url or "/tutorial" in url:
    hits += 1

スコアリングは線形ではなくステップ関数に基づきます：0ヒット → 0.10、1ヒット → 0.40、2ヒット → 0.60、3ヒット以上 → min(1.0, 0.70 + hits * 0.05)。ステップ関数は実用性シグナルの量よりも存在をより高く評価します。1つのチュートリアルリンクは、キーワード3つと4つの差よりも価値があります。³

深度（20%）：メタデータの豊富さ

深度は純粋に構造的なものです。コンテンツの品質ではなく、フィールドの存在と長さを測定します：

深度は最も信頼していない次元です。花の写真についてのツイートでも、完全な説明文と4つのタグがあれば深度0.85を獲得します。メタデータは豊富だがコンテンツは無関係。深度は「ソースが構造化データを提供した」ことの代理指標であり、品質と相関はしますが保証はしません。⁴

信頼性（15%）：ソースの信用度

信頼性はベースライン0.40から開始し、ソースタイプに応じて調整されます：

if source in ("twitter", "x"):        score = 0.50
elif source in ("blog", "newsletter"): score = 0.60
elif source in ("github", "docs"):     score = 0.70

ドメイン許可リストは上方にのみ上書きします（下方には適用しません）：github.com、anthropic.com、apple.com、arxiv.org、docs.python.orgなどは信頼性を最低0.75に設定します。許可リストは、これらのソースがデフォルトでより高い信頼に値するという判断をエンコードしています。

閾値ルーティング

3つのルーティングビンが、スコアリングされた各シグナルの処理先を決定します：

THRESHOLD_AUTO_WRITE = 0.55   # → domain folder
THRESHOLD_INBOX      = 0.30   # → 00-Inbox (manual review)
# Below 0.30 → silently skipped

パイプラインは0.55以上のシグナルを、タグとタイトルのマッチングから推定される12のドメインフォルダのいずれかに直接書き込みます。中間レンジのシグナル（0.30〜0.55）は手動レビュー用のインボックスに入ります。0.30未満のものはボルトに到達しません。

0.30〜0.55の範囲は、システムの確信度が最も低い「曖昧ゾーン」です。オプションの--llm-triageフラグを使うと、これらのシグナルをClaudeに送って評価させることができ、複合スコアを最大±0.20調整して、シグナルを自動書き込み閾値を超えさせる可能性があります。Claudeが見るのは曖昧なシグナルのみで、高スコアや低スコアのシグナルは見ません。決定論的スコアラーが既に処理したシグナルにAPIトークンを使うのは無駄です。⁵

ドメイン推定は投票システムを使用します。各タグがドメインにマッピングされ、タイトル内の各キーワードが一票を追加します。最多得票のドメインが選ばれます。同点の場合はdict順（実質的に任意）で決まります。デフォルトのフォールバック先：「Inspiration」。

結果

14ヶ月間で7,700以上のノートを処理した結果：

この分布は現実を反映しています。私はDevelopmentとDesignのコンテンツを他のどのカテゴリよりも多く消費しています。Inboxのアイテム（420件）は曖昧ゾーンを表しており、アルゴリズムが自信を持って自動ルーティングできなかったシグナルです。⁶

アルゴリズムが間違えたこと

深度の罠

ネモフィラの花の写真ツイートのスコアはcomposite 0.36, relevance 0.25, actionability 0.10, depth 0.85, authority 0.50でした。深度（0.85）と信頼性（0.50）がほぼゼロの関連性と実用性を補ったため、インボックスにルーティングされました。メタデータは豊富だがコンテンツは無関係：花のきれいな写真です。

この例は、メタデータ代理スコアリングの根本的な限界を示しています。深度は「ソースが構造化データを提供した」ことを測定しているのであって、「コンテンツに価値がある」ことではありません。Twitterはすべてのツイートに完全な説明文とタグを提供します。朝食についてのタグが充実したツイートも深度0.85を獲得します。情報検索の研究では、この根底にある緊張関係を適合率/再現率のトレードオフと呼びます：再現率（関連するものをすべて捕捉すること）を最適化すると、必然的に偽陽性を許容することになります。¹⁰

検討したが却下した修正案： 深度の重みを0.20から0.10に下げれば、タグが充実した無関係コンテンツによる偽陽性は減りますが、メタデータが乏しいソースからの本当に深いコンテンツもペナルティを受けることになります。現在の重みは妥協点です。

関連性ベースラインの問題

マッチなしの関連性ベースラインが0.25であるため、妥当なソースからの構造が整ったシグナルは少なくとも0.30を獲得し、インボックスに入ります。このベースラインは偽陽性の下限を作り出します：インボックスにはタグが充実していて妥当なソースからのシグナルが溜まりますが、私の興味とは無関係です。

実際の修正策： 定期的なインボックスレビューは依然として必要です。パイプラインはレビュー対象を7,700件から420件に減らしました（約95%の削減）が、曖昧ゾーンの手動レビューを完全に排除することはできません。

実装メモ

パイプラインはCLIツールとして実行されます。入力はシグナルのJSON配列（RSS、Twitter API、または手動入力から）です。出力はドメインフォルダに書き込まれるObsidian互換のマークダウンファイルです。

python triage.py --input signals.json --vault ~/obsidian-signals/
python triage.py --input signals.json --vault ~/obsidian-signals/ --llm-triage
python triage.py --input signals.json --min-score 0.60  # Stricter routing

スコアリング前にプレフィルタリングが実行されます：既存のボルトノートに対するURL重複排除、空コンテンツのフィルタリング、ノイズソースのブロックリスト。重複ノートとスパムソースはスコアリング段階に到達しません。

スコアリング関数はピュアです：副作用なし、APIコールなし、ファイルシステムアクセスなし。各関数はシグナルのdictを受け取り、スコアのdictを返します。このピュアなアプローチにより、分離してテスト可能であり、曖昧なサブセットのみに対して実行されるLLMトリアージステージとの合成も容易になります。⁷

重要なポイント

トリアージシステムを構築するエンジニアへ：

• 決定論的スコアリングはスケールにおいて手動キュレーションに勝ります。 14ヶ月で7,700件のノート。手動トリアージには50時間以上のレビュー時間が必要だったでしょう。パイプラインはそれを数分で処理し、約95%のルーティング率を達成しました（手動レビューが必要だったのはわずか5.5%です）。

• メタデータ代理指標には既知の失敗パターンがあります。 深度は構造を測定するのであり、品質ではありません。信頼性はソースを測定するのであり、正確性ではありません。どちらの代理指標も集計レベルでは機能しますが、個別シグナルレベルでは予測可能な偽陽性を生み出します。失敗パターンを認識することは、アルゴリズムが「機能する」と主張するよりも誠実です。

ナレッジマネジメント実践者へ：

• 重み付き複合スコアは実際の優先順位を可視化します。 35/30/20/15の重みは恣意的ではありません。関連性は実用性より重要であり、実用性はメタデータの豊富さより重要であり、メタデータの豊富さはソースの信用度より重要である、という特定の判断をエンコードしています。重みを明示的かつ調整可能にすることが、「システム」と「習慣」の違いです。

• 曖昧ゾーンは排除不可能です。 0.30から0.55の間のシグナルは本質的に曖昧です：決定論的スコアラーでは解決できません。LLMトリアージは助けになりますが、ゾーンを排除するわけではありません。曖昧なサブセットの手動レビューは依然として必要です。

この記事は生産性のヒントとしてではなく、エンジニアリングの問題として構成しました。複合スコアリングは、アイテムの決定論的ルーティングが必要なあらゆるドメインに適用できます：サポートチケット、コンテンツモデレーション、リード評価、異常検知。私の具体的な重みと閾値は個人的な優先順位をエンコードしていますが、アーキテクチャは汎用的です。蓄積されたナレッジが非線形の価値を生み出す仕組みについては、知識の複利効果をご覧ください。OODA Loop for Prompt Engineeringでは関連するパターンを探求しています：直感に代わる構造化された観察です。パイプラインの各コンポーネント（スコアリング、ルーティング、トリアージ）は独立して有用であり、他のコンポーネントと組み合わせることで複利的エンジニアリングパターンに従い、価値が蓄積されます。