ai-sns CRM・WORKLENS・FREEBORN INSIGHT の実装を能力カードとして知識化し、 実装済み／一部対応／カスタム対応可／未実装（計画あり）／非対応を、 根拠つきで返します。根拠がなければ、はっきり「要確認」と答えます。 音声で聞けるので、運転中でも、客先のエレベーター前でも。
能力カードを読み込み中…
商談は止まった瞬間に冷めます。持ち帰った案件が戻ってくる確率は、その場で答えた案件よりずっと低い。
御社のシステムでLINE連携できますか
持ち帰り、開発に確認し、翌日回答。その一往復のあいだに、商談の熱が下がります。
他社は◯◯ができるらしいが
実は自社プロダクトに実装済み。担当者が知らないだけで、勝てる商談を落としています。
できます
その場の安請け合い。実装できず、失うのは案件ではなく代理店との関係そのものです。
どの判定にも、必ず根拠となる実装箇所が付きます。判定は検索結果に対する決定的な規則で確定させており、AIの作文ではありません。
標準機能として動いています。そのまま提案してください。
できる範囲と、できない範囲を明示します。制約を伏せた提案はさせません。
移植元の実装があり、工数と概算費用を出せます。
ロードマップ上にあるが、まだ動かないもの。「できます」と言えば導入初日に嘘だと分かり、「非対応」と言えば取れる案件を落とすため、独立した判定にしています。
提供実績なし。断ったうえで、通る代替案を出します。
根拠がない。憶測で答えず、未回答キューへ回します。
一般的なAIチャットボットは、資料が見つからないとそれらしく作文します。 代理店がそれを信じて受注し、実装できなければ、失うのは1件の案件ではなく代理店との信頼関係です。
SALESLENS は、根拠となる能力カードが見つからなければ必ず「要確認」を返します。 質問の大半を説明できないときも同じです。知っている半分だけに答えて、全体に答えた顔をすることはありません。 判定はAIではなく決定的な規則が確定させているため、作文する余地が構造として存在しません。
判定・確証度・根拠・工数・費用・注意点まで。画面を見せながら話しても成立する情報量にしています。
worklens/src/fx.js:35-46
worklens/src/*.js 全体で送信系の外部連携なし（確認日 2026-08-28）
機能カタログ platform-061（未実装のため実装箇所なし）該当なし — 能力カード 0件ソースコードと仕様書を、機能単位の構造化データに変換します。コードの断片は「何ができるか」を語らないので、生テキストを埋め込むだけでは「できますか？」に答えられません。
客先は「タイムカード」と言い、コードは「打刻」と書きます。別名辞書がその溝を埋め、実際に使われた言い回しを質問ログから取り込んで育ちます。
AIに判定を丸投げしません。AIは能力カードの解釈と文章生成だけを担当し、可否そのものは検索結果に対する決定的な規則が決めます。ここが安全弁です。
ファイルパスと行番号、工数、概算費用、そして注意点まで。「その根拠は？」と聞かれても答えられます。
商談ブレーンは業種ごとに論点・提示・効果・価格の順で骨子を組み立てます。刺さる順番は業種で変わるからです。
痛点：入庫から納車までが見えない
ピット回転率とクレーム対応から入ります。作業を人手で記録させず、カメラが勝手に区切る点が決定打になります。
痛点：現場ごとの粗利が締めるまで分からない
赤字現場に気づくのが2か月後、という話から入ります。「防げた損失」で語ると、費用が保険に見えます。
痛点：ホールの人手が採れない
売上向上より「同じ人数で回る」を軸に。採用コストと離職率を先に聞き出すと、判断が早くなります。
痛点：申告された残業が実態と合っていない
「導入して何が良くなるか」より「放置したら何が起きるか」。是正勧告と未払い残業の遡及請求から入ります。
登録のない業種は汎用の型で返し、そのことを明示します。知らない業種を知っているふりはしません。
それぞれの実装を読んでカード化しています。件数も実装状況も、この画面の数字はすべて稼働中の知識ベースから取得しています。下は代表的な3商材です。
営業CRM。機能カタログ500件をそのまま能力カードにしているため、製品ページの一覧と営業の回答が同じ出所から出ます。実装済みと計画中を明確に分けています。
AI働き方分析。PC操作ログから隠れ残業・シャドーIT・情報持ち出しを検出。18カード、ファイルパスと行番号つき。
AI経営参謀。経営診断・AI経営会議・提案書生成・モックサイト公開。11カード。「12データソースをスキャン」の実体まで含めて記録しています。
代理店ごとに扱える商材を制限できます。対象外のカードは検索にも判定にも質問ログにも到達しないため、 そのカードが存在すること自体が分かりません。
照会して終わりではなく、答えられなかったことが次の答えになる形にしています。
可否・確証度・根拠・工数・費用。音声でもテキストでも。
業種別の提案骨子。推測を許す代わりに参考意見と明示します。
その代理店が扱える全カード。根拠と制約つきで一覧できます。
「要確認」が溜まり、回答すると能力カードに昇格します。
非対応で頻出する機能が、開発の優先度リストになります。
「これ売れる？」の先にある「どう売る？」と、聞かれた内容そのものの資産化まで。
押しながら話すだけ。判定は読み上げ、根拠は画面に出します。移動中や客先の直前でも使えます。端末のブラウザだけで動くため、別途の契約は不要です。
業種を伝えると、論点・提示・効果・価格の順で提案骨子を組み立てます。推測を許すモードなので、参考意見として明確に色分けして表示します。
「要確認」は自動でキューに入り、回答されると能力カードに昇格します。質問の言い回しも辞書に還元されるので、次に同じことを聞いた担当者には即答されます。
代理店が何を聞いたかは、市場が何を求めているかの生データです。「非対応」で頻出する機能が、そのまま開発の優先度リストになります。
A社はWORKLENSのみ、B社は全商材、といった制御ができます。スコープ外のカードは検索にも判定にも到達しないため、他社向け商材の存在と価格が漏れません。
「SSOに対応していますか」のように商材を特定しない質問では、製品ごとに答えが変わります。最も一致したカードで答えたうえで、他プロダクトの状況をカード名つきで併記します。正しい判定を、間違った商材について持ち帰らせないためです。
コードは変わります。最終確認から90日を超えた根拠は確証度が減衰し、「要再確認」として扱われます。知識が静かに腐ることを防ぎます。
プロダクトを追加するたびに、その実装を読んで能力カードに落とし込んでいます。
導入前に必ず聞かれることです。
代理店の営業担当が、商談の場で「その機能はできますか？」に即答するための照会エージェントです。全プロダクトの実装を能力カードとして知識化し、実装済み／一部対応／カスタム対応可／非対応の4判定に、根拠となるファイルパスと行番号、工数、概算費用を添えて返します。判断がつかないときは「要確認」と答えます。
判定はAIが決めていません。検索で取得した能力カードに対する決定的な規則が確定させています。根拠となるカードが見つからない場合、質問の大半を説明できない場合、聞かれた製品名の記録がない場合は、いずれも「要確認」になります。作文して埋める経路が構造としてありません。
要確認は自動で未回答キューに入り、運営側が回答すると能力カードに昇格します。同時に質問の言い回しが別名辞書に取り込まれるため、次に同じことを聞いた担当者には自動で答えが返ります。使うほど要確認は減ります。
見えません。商材スコープはカードの読み込み時点で適用しており、表示時のフィルタではありません。対象外のカードは検索にも判定にも質問ログにも到達しないため、そのカードが存在すること自体が分かりません。
能力カードは最終確認日を持ち、日数に応じて確証度が減衰します。90日を超えると「要再確認」として運営コンソールに一覧され、確証度が閾値を割ると要確認に落ちます。古い根拠が静かに生き残らない設計です。
「未実装（計画あり）」という独立した判定を返します。ロードマップにある機能を「実装済み」と言えば導入初日に嘘だと分かり、「非対応」と言えば取れるはずの案件を落とします。どちらの丸め方も誤りなので、丸めません。回答には「『できます』ではなく『計画にあります』と伝えてください。時期を約束しないこと」という注意が付きます。
最も一致したカードで判定し、他プロダクトの状況をカード名つきで併記します。たとえば「SSOに対応していますか」なら、FREEBORN INSIGHT は一部対応、ai-sns CRM は未実装（計画あり）と並べて表示します。併記する条件は主判定に近い一致度を満たすものに限っており、弱い一致で他商材の可否を主張することはありません。
記録がある連携については答えます。記録のない製品名が質問に含まれる場合は「要確認」を返します。連携の可否は相手側の仕様にも左右されるため、実績のない製品について断定することはしません。
不要です。音声認識と読み上げは端末のブラウザ機能で完結しており、外部の音声APIを使いません。ボタンを押しているあいだだけ録音し、判定は読み上げ、根拠は画面に出ます。
不要です。デモはログインなしでそのまま開けます。ログイン画面にはデモアカウントも表示しています。
出荷したものだけを書いています。設計しただけ・検討中のものは載せません。
自治体の入札公告を集めるようにしたことで、公告の発注者と計画の発行元が ようやく重なりました。これまではNEXCO（高速道路会社）の公告に対して 自治体の計画しか持っていなかったため、原理的に当たりようがありませんでした。 例:「大宮小学校外2校アフタースクール電気設備修繕」→ 千葉市学校施設長寿命化基本計画（一致した語：学校・電気、本文1ページ目）。
あわせて、当たり方の質を上げました。 計画でないものは出しません（制度の案内などを「関連しそうな計画」として出すと、 読んだ人は「この工事はこの制度に載っている」と読みます）。 また当たった場所で重みを変えます — 本文の見出し（ページを指せる）＞ 計画の名前 ＞ 分野タグ（資料名から起こしたもの）の順で、 分野タグだけで1語当たっただけの組み合わせは採りません。 実際に「若葉・緑環境事業所LED化修繕」の事業所名に含まれる「環境」が、 無関係な文書の環境タグに当たっていました。事務所の名前と施策は関係がありません。
発注者の照合も直しました。団体名の末尾（都・県・市）を落として部分一致していたため、 「東京都」が「東京」としてNEXCOの東京支社に当たり、 高速道路会社の公告に都の計画がぶら下がっていました。 間違った計画が付くくらいなら、当たらないほうがましです。
千葉市・千葉県・横浜市の入札情報を読む仕組みは作ってありましたが、 毎日の収集から呼ばれていませんでした。 作ってあるのに動いていない状態は、画面からは 「その自治体に公告が無い」と見分けがつきません。 登録されている収集元をすべて順番に回すようにしました。 1つの収集元が不調でも、他の収集はその日も進みます。
見出しの件数表示も「60件のうち24件を表示」のように直しました。 24件しか出していないのに「60件」とだけ書くと、並んでいるものが全部に見えます。
横浜市は入札情報を表ではなくリンクの一覧で載せているため、 その形でも読めるようにしました（件名の【公募型プロポーザル】【契約結果公表】は 方式と状態として取り出し、件名からは外します。残すと同じ案件が状態違いで別物に見えます）。 千葉県も同じ形でした。入口のページ（入札・契約）には案件が無く、 公告は「入札等の公告」の下にリンクで並んでいます — 所管課ごとにURLが分かれるため、 パスの前方一致ではなく綴りで見ています。 千葉県65件・横浜市24件を読めるようになりました。
締切は詳細ページの見出し語から拾います。「参加表明書の提出期限」と 「企画提案書の提出期限」が別の日のとき、何の期限か言っている長いほうを採ります — 単に「提出期限」で当てると、どちらを取ったのか分からなくなるためです。 入札方式が別の欄に無いときは件名から読みます（自治体は「企画提案募集」と件名にだけ書くことがあり、 「その他」と出すと方式で絞る人の画面から消えてしまいます）。
計画PDFの本文を読むとき、一部の文字が黙って抜け落ちていました。 「基本計画・実施計画」が「基本計画・施計画」、 「特定課題等」が「特定題等」になる、という欠け方です。 日本語として読めてしまうため、見ても間違いだと気づけません。 原本と違う文を「原本から抜き出した一文」として出すのは、 この製品が拒むために存在しているものそのものでした。
原因はPDF側の文字対応表（ToUnicode）の欠けで、千葉市の実施計画では2.5%の文字が 載っていませんでした。埋め込まれたフォント本体の対応表から 読み直すようにして、この資料では欠けが0になりました。 推測ではなく、そのフォント自身が持っている対応表を引いています。
それでも欠けが残る資料は、抜き出しを出しません。 「文字欠け（引用不可）」と表示し、原本のリンクだけ残します。 欠けたまま引用するより、読めなかったと言うほうが正しいためです。 すでに読み込み済みだったものは、読み直しの対象に戻しました。
あわせて、同じ見出しの繰り返しをまとめ（章の柱書きが各ページ頭に入る資料があり、 60件のうち違うのは21件でした）、事業費が表の中にあって単位が表の外に一度だけ 書かれている場合に「拾えていません」と明示するようにしました。 0件とだけ出すと「予算の書かれていない計画」に見えますが、そうではありません。 表の数字を推測で円に直すことはしません — 桁を1つ間違えた事業費が、 根拠つきの数字として客先で読み上げられることになるためです。
公告の一覧と計画の一覧を、いまの絞り込みのままCSVで書き出せるようにしました。 絞り込みは画面と同じ処理で組み立てています — 別々に書くと、画面で見た表と 落としたファイルが食い違う日が来て、食い違ったことには誰も気づきません。 計画側は「読み取れなかった理由」まで書き出します。 読取済／未読取の2値にすると、画像PDFで読めないものが「待てば読める」に見えるためです。
ウォッチに当たった新着を、毎朝1通にまとめて通知するようにしました。 画面を開かせる前提の仕組みは、開かれなくなった日に黙って止まります。 止まったことは「新着が無い日」と区別がつきません。 1ウォッチ1通ではなく1テナント1通にしたのは、多すぎる通知はミュートされ、 ミュートされた通知は無いのと同じだからです。
国（省庁）の計画を、省庁の語彙で読むようにしました。 省庁は「総合計画」を作りません — 置くのは重点計画・大綱・白書です。 自治体の語彙のまま見に行っていたため、拾えるのは予算のページばかりで、 国土交通省は5件中4件が予算関係という状態でした。 あわせて索引ページを文書として並べない（「予算・決算・税制等」のような看板）、 古い年度の予算を取り込まない（省庁の予算ページは令和元年度まで遡れる書庫です）、 同じ題名の行を増やさない（防衛白書が6行並んでいました）を直しました。
自動収集を受け付けないサイト（外務省・経済産業省）は、0件ではなく「拒否されています」と表示します。 0件と同じ顔で並べると、待てばいつか埋まるものに見えますが、待っても変わりません。 なお、名乗りを偽って回避することはしません。
収集の当たった索引ページを覚えるようにしました。 これまでは毎回トップページから探し直していたため、同じ団体でも走らせるたび取れ高が変わっていました。 当たった場所を覚えるので、動かすほど確かになります。
整合性・出典切れ・取込ソース・納品実績・利用者・教育レポート・監査ログ・書き出しの8タブ。 いずれもAPIは稼働していたものの画面がなく、とくに整合性と出典切れは 「いま現在エージェントが答えるべきでないことを答えている」を示す2つの報告なので、 開けない状態はそのまま放置と同じでした。 あわせて商材スコープの違うデモアカウント4種（全商材・ai-sns CRM・WORKLENS・運営コンソール閲覧）を ログイン画面に掲示。運営コンソールのデモは変更操作をサーバ側で拒否します。
追う条件を登録しておくと、その条件に当たった新着だけが出るようにしました。 毎朝すべてを昨日と見比べる必要がありません。条件は一覧の絞り込みと同じで、 絞り込んだ状態から「この条件を登録」で作れます。
公告の詳細に「関連しそうな計画」を出すようにしました。 「いま出たこの公告は、どの計画に書かれていたものか」が分かると、 同じ計画に載っている他の事業も同じ時期に出ると読めます。 突き合わせは語の一致なので、一致した語を必ず添えます — 何で当たったのかが見えないと、外れていても分からないためです。
計画本文の読み取りも毎日自動で行うようにしました。
これまで「資料の所在」までしか出していませんでしたが、計画本体のPDFを読み、 施策の見出し・金額・分野の語数をページ番号つきで出すようにしました。 「（4）道路の長寿命化 … 12億3,000万円（p.64）」のように、原本のページを開けば確かめられる形です。
要約はしません。要約は「誰も書いていない文」を作る作業で、 それを信じた営業が客先で言い、原本に書いていなければ失うのは1件の案件ではありません。 抜き出した一文は確かめられますが、要約は確かめようがない — だから抜き出しに留めます。
読み取れないPDFもあります（文字が画像のもの、フォントに文字対応表が無いもの）。 その場合は「読み取れませんでした」と表示します。「書いていない」ではないからです。 千葉市の計画12件で、読めたのは6件でした。
あわせて都道府県での絞り込みを追加しました。県を選ぶと、 その県と県内の市がまとめて出ます（担当エリアは「千葉県」であって「千葉県庁」ではないため）。 47都道府県すべてが選べます — 0件の県も0件と表示します。
収集先を128団体に広げました。都道府県は47すべて、市は政令指定都市と
中核市を中心に64、国は17省庁です。
自治体サイトのURLは公的な一覧に載っていないため、
pref.〇〇.lg.jp などの型を実際に確認して200が返ったものだけを登録しています
（推測のURLは1件も入れていません）。
毎日は全部を回しません。1団体あたりの往復を考えると全部で30分以上つなぎっぱなしになり、 中期計画は日に何度も変わるものでもないためです。 最後に見てから古い順に24団体ずつ、数日かけて一巡します。 失敗した団体は翌日に先頭へ来るので、取りこぼしが放置されません。
登録したことと、取れていることは別です。 いま実際に計画を取得できているのは、計画一覧ページを指定した8団体です。 残りは自治体ごとにサイトの作りが違うため、1団体ずつ一覧ページを足していきます。 どこが薄いかは画面に出しています。
「計画」をプロスペクトの直下に独立したタブとして置きました（/crm/plans）。
収集元は9団体に増え、都道府県・市・国で分けて表示します。
入札公告と計画の両方を1日1回、自動で巡回します
（相手ごとに時間をずらし、1団体ずつ、上限つきで）。
自治体ごとにサイトの作りが違うため、取れ高は揃いません。 計画の一覧ページを指定した千葉市は30件取れていますが、指定なしの自治体は数件にとどまります。 どの団体が薄いかは画面に出しているので、その自治体の一覧ページを1本足せば同じ品質になります。 「取れていない」ことを「計画が無い」ように見せないための表示です。
入札公告が「いま出ている仕事」なら、自治体の実施計画は2〜3年後に出る仕事です。 そこには、その自治体がこれから3年で何をどの分野でやるつもりかが書かれています。 千葉県・千葉市を第1対象に、計画の名前・計画期間・分野別の資料の所在を集め、 現行計画があと何年度で切れるかを並べます。計画は切れる1〜2年前から 次の策定が始まるので、そこが提案の入り口になります。
これは資料の索引で、計画内容の要約ではありません。 計画本体は数百ページのPDFで、このシステムは中身を読んでいません。 読んでいないものを要約すれば、それは当社が最も避けたい「もっともらしい作文」になります。 出すのは「どの計画が、いつからいつまでで、どの分野の資料がどこにあるか」までです。
対象の自治体を増やすのは設定に1行足すだけで、省庁も同じ形で扱えます。
このサイトには永続ディスクが付いていないため、これまでは再デプロイのたびに
中身が消えていました。収集した案件も、追わないと決めた判断も、リード化の記録もです。
非公開の保管先へ自動で控えを取り、起動時に戻すようにしました。有料ディスクは要りません。
状態は /api/backup/status で確認できます。
公告日・提出期限・開札日の範囲、締切まで何日か、金額、現在状況、契約種類、契約方法、 支社、工種・業種、等級で絞れます。並び順は公告日・締切・開札日・金額・落札率。 選択肢は実際にあるものだけを件数つきで出します — 0件の選択肢が並ぶと、 絞り込みが壊れているように見えるためです。
絞り込んだ状態がそのままURLになります。
「橋梁で、今月締切で、A等級」を同僚にリンクで渡せます。画面ごとにもURLがあり
（/crm/prospects など）、ブラウザの戻るも効きます。
公共機関が公開している入札公告を集めて一覧にし、追うと決めた案件を そのままリードに変換できるようにしました。リードの上流にあたるので、 画面もリードの直下に置いています。第1対象は NEXCO東日本で、 発注事業所・契約方法・工種・提出期限・開札日・予定価格・落札者と、 仕様書などの資料の所在までを1案件1行にまとめます。
自動収集は既定で止めてあります。収集先は当社のサイトではなく、 自動収集の可否は先方の利用規約の話になるためです。確認のうえで有効にしてください。 収集を止めていても、取り込み済みの案件の閲覧・検索・リード変換は使えます。 有効にしたときも robots.txt を毎回確認し、1.2秒以上の間隔で、1回の実行に上限を置いて巡回します。
CRM は別サイトとして動いていて、その中に SALESLENS を窓として埋め込んでいました。 同じ場所で動くようになり、ログインは1つ、データベースも1つです。 CRM にログインしていれば、その中の SALESLENS も同じ担当者として開きます。
統合のいちばんの理由は見た目ではありません。CRM は商材知識の複製を自前で持っていて、 同じ商品について SALESLENS と違う答えを返しうる状態でした（複製側は1,029件、本体は2,610件）。 複製を廃止し、根拠を検証済みの1つの知識ベースだけが答えるようにしています。 「要確認」の行き先も1つにまとめました — 2か所にあると、片方で答えても、もう片方は開いたままになります。
権限は混ぜていません。CRM の管理者は自社のCRMを管理する権限であって、 運営コンソール（全代理店の商材と価格が見える場所）には届きません。
CRM側のドメインが変わっていたため、CRMの中に出るSALESLENSの画面が空白になっていました。 埋め込みを許可する相手の指定を実際のドメインに合わせて修正しています。 なお、許可先からすでに使われていないドメインは削除しました。 許可の記載は「そのドメインを持つ相手に与えた権限」であり、手放したドメインを載せ続けるべきではないためです。
参照先リポジトリが別組織へ移管されていたため、全28ソースが解決できない状態でした。 移管を追従したうえで全件を照合し、2,684件の出典を検証。 うち32件が解決しないことが分かり、出典切れの画面に出しています （大半は、参照先の中身が別アプリに差し替わったことによるものです）。
規模が大きくなって初めて表に出た検索の誤りを3件修正しました。別名がカタカナ語の内部に一致する問題、 ありふれた語の別名が判定を奪う問題、カード名の一致が順位を付けられない問題です。
依存関係をたどって判定に反映する能力グラフ、標準価格ひな型、提案骨子と反論の切り返し、 そして実リポジトリに対する根拠の実地検証を追加しました。