AI業務管理秘書たすきばの提案機能｜意味検索で"気づかなかった過去"を自動で並べる
たすきばの核心機能は、実は “提案” です
たすきば Knowledge Relay は AI 業務管理秘書 です。プロジェクト管理ツールでもあり、ナレッジ管理ツールでもありますが、その両方は 手段 にすぎません。
たすきばの核心機能は、 提案 です。
過去に蓄積された——
- ナレッジ
- リスク
- 課題
- 振り返り
- メモ
- 過去プロジェクトそのもの
——これらの中から、 「いま、ユーザがやろうとしていることに関連するもの」 を、システムが自動的に並べます。
今日は、リリース告知（B-1）の翌日として、たすきばがいちばん時間とこだわりを注いだ 提案機能 が、実際にどんな体験を作るのかを書きます。
提案が出てくる 3 つの場面
提案は、3 つの場面で出てきます。それぞれ少し意味合いが違います。
1. プロジェクト作成・更新時
新規プロジェクトを作成すると、 purpose / background / scope のテキストから、 最大 50 件 の関連資産が自動提示されます。
[新規プロジェクト: EC サイト リニューアル案件]
→ 関連ナレッジ（10 件）
- 「Stripe Webhook の Idempotency 設計」（関連度 0.82）
- 「EC サイトの個人情報マスキング設計」（関連度 0.79）
- ...
→ 過去リスク（10 件）
- 「カート操作中のセッション切れ」（関連度 0.71）
- ...
→ 過去課題（10 件）
→ 振り返り教訓（10 件）
→ 関連メモ（10 件）「この過去案件で似た問題が起きていました」とシステムが教えてくれる。ユーザは、これまで覚えていなかった過去案件にも、自然と目を向けることになります。
2. 参考タブ（プロジェクト内）
プロジェクト詳細画面に「参考」タブがあり、 いつでも提案候補を再表示 できます。プロジェクトの内容を更新すると、提案候補も自動で更新されます。
「あのとき出た候補、もう一回見たい」を 1 クリックで取り戻せる場所です。
3. 課題起票画面の Inline 提示
リスク / 課題を新規起票する画面では、入力内容に応じて、 過去に類似した起票 が下部にリアルタイムで表示されます。
「同じ課題が過去にもあって、こう解消しました」と、 過去の自分（あるいはチーム）が、いまの自分に教えてくれる ——そんな体験を目指しています。
なぜ “プッシュ型” にしたのか
通常のサービスは、ユーザが情報を 「取りに行く」 設計（プル型）です。 たすきばは、ユーザが情報を 「届けに来てもらう」 設計（プッシュ型）です。
理由はシンプルです。
ユーザが「あの過去案件を見たい」と思いつく前に、システムが先に提示しないと、その案件は永遠に “存在しないもの” になる。
連載第 1 回 で書いた「意思決定者の目に触れなければ、データは存在しないものとして扱われる」を、システム側から能動的に解消する仕組み——それが提案機能です。
Voyage AI Embedding が生成される瞬間
提案機能が成立する裏側には、 Voyage AI Embedding という技術が居ます。少しだけ深堀りさせてください（深い技術解説は Qiita 側に分けていきますが、概念だけはここで触れておきたいのです）。
Embedding とは、文章を 1,024 個の数字の並び（ベクトル）に変換する処理のことです。たすきばが採用しているのは voyage-4-lite というモデルで、ナレッジでもリスクでも振り返りでも、テキストを入れると「意味の座標」のような 1,024 次元のベクトルが返ってきます。
意味が近い文章ほど、このベクトル同士の距離が近くなります。「セキュリティ要件」と「情報漏洩対策」は、表記が完全に違っても、 数字の並びとしては近い場所に位置する ——そんな性質が、Embedding という技術には備わっています。
たすきばで Embedding が生成される瞬間は、大きく分けて 6 つあります。
| タイミング | 対象 | 何が起きるか |
|---|---|---|
| プロジェクト作成・更新 | purpose / background / scope | Voyage で 1,024 次元ベクトルを生成し、 content_embedding 列に保存 |
| ナレッジ作成・更新 | 本文 + タイトル | 同上 |
| リスク作成・更新 | 説明文 | 同上 |
| 課題作成・更新 | 説明文 | 同上 |
| 振り返り作成・更新 | KPT 本文 | 同上 |
| メモ作成・更新 | 本文 | 同上 |
つまり、ユーザが何かを 作成・更新したとき に、その瞬間だけ Voyage AI を呼び出して、ベクトルを PostgreSQL の content_embedding 列に保存しています。 読むとき・検索するときには、もう呼びません。
これが、後で書く「検索時 ¥0」の構造を支えている、いちばん下の判断です。
3 軸合算スコア — 提案の中身
候補のランキングは、3 軸を合算したスコアで決まります。
| 軸 | 重み | 役割 | データソース |
|---|---|---|---|
| タグ類似度 | 0.3 | Jaccard 係数で補助的にマッチ | businessDomainTags / techStackTags / processTags |
| 文字列類似度 | 0.2 | pg_trgm で表記揺れに強い補助 | purpose + background + scope |
| 意味類似度 | 0.5 | Voyage embedding の Cosine 類似度 | 各 entity の content_embedding（1,024 次元） |
意味類似度に 0.5 の重み を置いている理由は、これがたすきばの差別化軸そのものだからです。
「セキュリティ要件」と「情報漏洩対策」が、表記が完全に違っても意味的に近接する——このつながりを拾うのが、意味類似度の役割です。
計算式、もう少しだけ詳しく
3 軸合算スコアは、こんな式で表せます。
score = 0.3 × tag_jaccard + 0.2 × string_pg_trgm + 0.5 × cos(query_vec, candidate_vec)tag_jaccardは、 業務ドメイン／技術スタック／プロセスのタグの Jaccard 係数 （0〜1 の重なり率）string_pg_trgmは、 PostgreSQL のpg_trgm拡張による トライグラム類似度 （表記揺れに強い）cos(query_vec, candidate_vec)は、 Voyage embedding 同士の Cosine 類似度 （ベクトルのなす角度）
3 つの「全く違う性質を持つ類似度」を、 重みつきで一本のスコアに合算 する。これがたすきばの判定ロジックの中核です。
同じ土俵で全候補を比べる
「タグ全文検索」と「ベクトル検索」が別経路で走るのではなく、たすきばは 1 つの統一スコア体系 で全データを比較します。
これにより：
- ベクトルが保存されている候補 → 意味類似度で寄与
- ベクトルが NULL の候補 → 意味類似度は 0 として扱う（それでもタグ + 文字列で評価される）
全候補は、常に同じ土俵（3 軸合算）で評価されます。
——この設計のおかげで、 外部 API 障害時にも提案機能は止まりません 。重み再配分縮退モード（Graceful Degradation）の話は、また別の記事で書きます。
候補の量は調整可能
提案候補は、各カテゴリで：
- スコアしきい値 0.05 以上
- 最大件数 10 件
を返します。5 カテゴリ合計で 最大 50 件 。
これは 「網羅性最優先」 という設計方針の表れです。
「精度よく絞り込んで上位 3 件」ではなく、 「再現率を最大化して段階表示する」 を選んでいます。ユーザは目で吟味するため、 見落としを防ぐ網羅性 が、精度より優先される、という判断です。
提案実行時のコストは ¥0
ここが、たすきばのアーキテクチャ上の優位性です。
提案画面を何度開いても、外部 API は呼ばれません。
理由はシンプルです。
- Voyage embedding は 作成時に 1 回だけ生成 され、
content_embedding列に保存される - 提案画面が開かれたときは、 pgvector が DB 内で類似度計算するだけ
これにより：
- Voyage の従量課金が、 提案画面の表示回数で増えない
- Voyage に障害が起きても、 提案機能は止まらない（fail-safe）
「検索時 ¥0 + 障害耐性」というこの構造は、たすきばの中核設計判断のひとつです。「使った分だけ請求する」という課金スタンスは、こうした コスト構造を支える技術選択 とセットで成立しています。
チャットと「なぜ？」 — 同じ embedding 基盤の上に乗る 3 つの機能
ここまで書いてきた「Embedding を作成時に 1 回生成し、後は DB 内で計算する」という基盤は、 実は提案機能だけのためのものではありません 。
たすきばの 3 つのユニークな特徴 は、すべてこの基盤の上に立っています。
| 機能 | 状況 | 入力 | 出力 |
|---|---|---|---|
| 提案機能 | リリース済み | プロジェクト / 起票画面の構造化入力 | 5 カテゴリ × 最大 10 件の関連候補 |
| チャット意味検索 | リリース済み | 自然言語クエリ | 自然言語で会話しながら過去資産を引き出す |
| 「なぜ？」機能（Pro 限定） | リリース済み | 提案候補 上位 N 件 | LLM が「なぜ関連するか」を言葉にして返す |
3 つの機能はバラバラに開発したわけではなく、 同じ content_embedding 列を読みに行く という構造を共有しています。 連載第 4 回の差別化軸 で「掘り起こし」と書いた特徴は、この 3 つに枝分かれして実装されています。
それぞれの機能は、別記事で深堀りします（公開 1〜2 日後に続けて書きます）。 ここでは、 提案機能の embedding 基盤が、たすきばの 3 つの体験すべての土台になっている ——という事実だけ覚えておいてください。
まとめ — “気づかなかった過去” を画面に並べる
提案機能の役割を、一文に圧縮するなら、
「あ、これ忘れてた」を、システム側から差し出すこと。
たすきばは、この一点に労力を注いでいます。 整った UI 哲学 の「あるべきでないものは置かない」と同じくらい、 「あるべきものを、あるべきタイミングで置く」 ことに、エネルギーを使っています。
次回は、 「儲けるための課金ではなく、続けるための課金」 というスタンスが、3 プラン × 従量課金の細部にどう落ちているかを書きます。
意味検索・自動提案に関するよくある質問
Q. 意味検索（セマンティック検索）とは何ですか？
A. キーワードの一致ではなく、文章の意味の近さで関連情報を見つける検索方式です。たとえば「リソース不足」と書かれた過去メモを、「人手が足りない」という別表現の質問からでも拾えます。たすきばはこの仕組みで、過去プロジェクトの資産から関連するものを自動で提案します。
Q. 全文検索（キーワード検索）と何が違うのですか？
A. 全文検索は同じ単語が含まれていないと見つかりません。意味検索は表現が違っても文意で関連を判定するため、「言葉を思い出せないと探せない」問題を解消します。本記事の提案機能は、検索する前に関連しそうな過去を自動で並べる点が、従来の検索ともさらに異なります。
Q. 関連資料を自動で提案させるには、どんな準備が必要ですか？
A. 特別なタグ付けは不要です。プロジェクト・ナレッジ・振り返りを記録しておけば、たすきばが embedding（ベクトル化）して関連度を計算し、必要な場面で自動的に差し出します。蓄積した情報が「探さなくても届く」状態になります。
関連記事
- 【リリース告知】たすきば Knowledge Relay、2026 年 6 月 1 日公開しました — 連載第 7 回・リリース告知
- 競合と何が違うのか — たすきばが選んだ 6 つの差別化軸 — 提案機能が差別化の中核である理由
- 毎日「1 時間」が蒸発していた — 私がたすきばを作った理由 — 「埋もれているデータは存在しないもの扱い」問題の原点
たすきば について
たすきば Knowledge Relay の提案機能の世界観は、 プロダクトページ からご覧いただけます。提案機能の上に乗る「チャット意味検索」と「なぜ？」機能（いずれもリリース済み）も、それぞれ別記事で深堀りします。
