「LINE WORKSに​流れて​消える​知識」を、​AIで​取り戻す——社内ナレッジBotを​数日で​本番投入した​話

チャットは速い。速いがゆえに、知識が川のように流れ去る。決定事項も、顧客のアカウント情報も、「あれ、どこで決まったっけ？」という大事な一行も——みんな時系列のトークに溶けて、翌週には誰も見つけられない。今回は、46万社が使うLINE WORKSの上で起きるその"知識の流出"を、AIで堰き止めた話だ。会話を勝手にナレッジ化し、根拠つきで答える社内Botを、人月ではなくフルAI駆動で、数日で本番投入するまでの実装記録を、設計判断ごと開示する。

01LINE WORKSは、もは​や"​使われすぎ"ている

LINE WORKSを使っている会社は、とても多い。数字で見ると、その普及ぶりは明確だ。主な指標を表に整理する^[1][2]。

指標	数値
導入社数（2024年）	46万社 を突破
導入社数（2025年）	52万社 に到達
利用者数	500万人 超
国内シェア	有料ビジネスチャットの国内シェアNo.1を7年連続で獲得（富士キメラ総研の調査）

LINEの操作感そのままに、掲示板・カレンダー・アドレス帳まで揃う——だから現場に刺さる。

私たち自身も、日々の業務はLINE WORKS上でフル回転している。だが、毎日その中で生活していると、ある問題が静かに、しかし確実に積み上がっていくことに気づく。会話が、流れて消えるのだ。

決定事項も、顧客のアカウント情報も、「あれ、どこで決まったっけ？」という大事な一行も——すべてが時系列のトークに溶け、翌週には誰も見つけられない。チャットは速い。速いがゆえに、知識が"川"のように流れ去る。検索しても、引っかかるのは断片だけ。結局「あの件、誰か覚えてる？」と人に聞き直す。その一往復のたびに、時間が溶けていく。便利なツールほど、この"流出"は静かに大きくなる。そこで私たちはこう考えた——会話を止めずに、知識だけを掬い上げる仕組みを、AIで作れないか。

02つくった​もの​：会話が、​勝手に​ナレッジに​なる

できあがったのは、LINE WORKSに常駐する社内ナレッジBotだ。理念はシンプルで、「AIで人の"時間"を取り戻す」。やることは4つ。表に整理する。

機能	何をするか
① 自動ノート	毎晩、その日のトークをルームごとにAIが要約し、固定テンプレ（トピックス／決定事項／タスク）に整えてグループノートへ投稿。朝には、昨日の議論が"読める形"で残っている
② 台帳	アカウント情報のような"ストック情報"は、流れるノートとは別に1枚の台帳ページとして常設し、更新があるたびに上書きし続ける。タイトルにハッシュタグを付けるので、新着に埋もれても検索一発で出る
③ Q&A	溜まった知識をAIが検索し（RAG）、「どの要約・どの台帳に基づくか」を示しながら回答。グループで @Bot、1:1のDM、/ask 〇〇——3つの呼び出し口に対応
④ タスク起票	要約の過程で見つけた「やること」を、LINE WORKSのタスクに期限つきで自動登録。担当者のカレンダーにそのまま乗る

つまり、人は普段どおり喋るだけ。知識化・整理・検索・タスク化は、Botが裏で回す。 これが完成形の姿だ。が、ここに至るまでには、LINE WORKSという"巨大な現場"ならではの壁が、いくつもあった。

03難所①：APIの​"壁"を、​設計で​迂回する

最初の壁は、LINE WORKSの認証の仕組みだった。Botがメッセージを受け取って返信するのは、Service Account（サービス用の機械アカウント）の権限でできる。ところが——ノートやタスクへの書き込みは、Service Accountでは呼べない。 これはLINE WORKS側の公式な制約で、いくら権限を足しても、機械アカウントのままではノートAPIが通らない。

ここで安易に「じゃあ機能を諦めよう」とはしない。迂回路を設計する。一度だけ管理者がOAuthで認可し、そのトークンでBotがNote/Taskを書き込む方式を採った。問題は、この認可が90日で切れること。毎回人手で再認可させるのは、それこそ"時間泥棒"だ。

そこで、毎晩動く定時処理が、リフレッシュトークンを自動でローテーションし続けるように組んだ。トークンは使われ続ける限り更新され、90日の再認可は実質的に発生しない。一度通せば、あとは放っておいても動く。「人の手を増やさず、仕組みで吸収する」——この姿勢が、運用を軽くする。

04難所②：AIに、​嘘を​つかせない

社内ナレッジBotで一番怖いのは、それっぽい嘘だ。実在しない決定事項を自信満々に答えたり、別の部署の機密が混ざって出てきたり。便利さよりも先に、ここを設計で潰す必要があった。

まず、トークルーム単位の厳格な分離。 各Botは、自分のルームの知識しか参照しない。検索時には必ず「このルーム」という条件を付け、その条件が渡せない場合は——検索そのものを実行しない。いわゆるフェイルクローズ（迷ったら閉じる）だ。「うっかり他のルームの情報が混ざる」事故を、仕組みとして起こせなくしている。

次に、メタ会話を知識化しない。 Botへの質問やコマンド、Bot自身の返信は、要約や台帳の材料から除外する。知識として残すのは、あくまで人と人の会話だけ。Botの独り言が"事実"として再学習されていく、という汚染を防ぐ。

そして、答えるときは根拠つきで。 回答には出典を明示し、関連する情報が見つからなければ「該当なし」と正直に返す。知ったかぶりをさせない。これがハルシネーション（もっともらしい嘘）への、もっとも効く処方だ。

05難所③：自動分類は​"間違える​前提"で​組む

会話を自動で「これは決定事項」「これは台帳行き」と振り分ける以上、分類は必ず間違える。 完璧を狙うのではなく、間違えても安全に戻せるように設計する方が、現場では遥かに信頼される。具体的には3つ。

• 出所タグ。 自動登録した項目には「いつ・自動で入った」という印を付け、後から人が直せるようにする。
• 【要確認】ブロックへの隔離。 確信度の低い情報は専用ブロックに隔離し、確定情報を汚さない。
• 確定値の破壊を、コードで禁じる。 一度「確定」とマークされた具体的な値を、曖昧な新情報や質問文で「不明」に上書きしてしまわないよう、保護ガードをかける。

AIに任せると、つい「全自動・全信頼」を夢見てしまう。だが本当に使われるツールは、AIの誤りを前提に、人が主導権を握り続けられるように作られている。

06技術選定の​裏側：少ない​部品で、​深く​作る

土台は Supabase一本に寄せた。データベースも、サーバー処理（Edge Functions）も、毎晩の定時実行（cron）も、すべて同じ基盤の上で完結する。部品点数を増やさないことは、そのまま運用の軽さと、壊れにくさになる。

要約・Q&A・翻訳の頭脳は Claude。検索のための埋め込み（ベクトル化）は Gemini Embedding を採用した。ここでも一つ、技術的な"詰まり"があった。使いたいモデルの出力は3072次元——ところが、データベースのベクトル索引には2000次元という上限がある。そこで halfvec（半精度ベクトル）＋ hnsw 索引という構成で、3072次元をそのまま高速検索できる形に収めた。さらに「文書を入れるとき」と「質問するとき」で埋め込みの種類を非対称に使い分け、検索の精度を上げている。

「文書を入れるとき」と「質問するとき」で種類を変える、というのは少し直感に反する。だが検索の世界では、知識を蓄える側と、問いを投げる側で最適な表現は違う。ここを揃えてしまうと、それらしく似た文章ばかりがヒットして、肝心の"答え"が埋もれる。非対称にすることで、質問の意図に沿った知識が上位に来るようになった。

派手さはない。だが、こういう地味な詰まりを一つずつ正しく解くことが、"動くデモ"と"本番で使える道具"を分ける。誰も褒めてくれない部分にこそ、本番運用の堅さは宿る。

07​何日で​できたか​——人月では、​たどり着けない​速度

ここまで読んで、こう思った人もいるはずだ。「それ、作るのに何ヶ月かかるの？」と。従来のやり方——人月で見積もるなら、要件定義・設計・実装・テストを積み上げて、軽く数ヶ月、数百万円のレンジに入る規模の機能群だ^[3]。認証の壁、RAGの分離、自動分類の安全設計……どれも"考えるべきこと"が多い。

私たちはこれを、フルAI駆動で、数日で本番稼働まで持っていった。設計判断は人間が握り、実装はAIが一気に通し、要所だけ人がレビューする。基盤・認証・受信・自動要約・台帳・タスク・RAGまで、段階を踏んで積み上げ、すでに実環境で動いている。

速さの正体は、魔法ではない。「人数 × 時間」で価値を測るのをやめたことだ。AIが時間を圧縮し、人は判断に集中する。だから、同じ成果物に、桁違いに少ないコストでたどり着ける。そして下がったコストは、隠さずお客様に返す——それが私たちの流儀だ。

08取り戻したのは、​"時間"だった

このBotが現場にもたらしたものを一言で言えば、時間だ。「あの件どこだっけ」が消える。新しく入った人が、過去の文脈を自分で引ける。決定事項が、流れずに残る。人に聞き直す一往復が、AIへの一言で終わる。——チャットの速さはそのままに、流れて消えていた知識だけが、手元に残るようになった。

便利なツールは、使うほどに知識を飲み込んでいく。その流れに、小さなダムを一つ作る。それだけで、現場の時間は驚くほど戻ってくる。

「AIで人の"時間"を取り戻す」——掲げた理念は、現場のチャットの中で、ちゃんと形になった。「こういうものが、自分の会社にもあったら」と思った方へ。言語化できるものは、すべて作ります。 まずは、つくりたいものを言葉にしてみてください。

従来（人月・外注）vs 私たち（AI駆動）。最後に、この社内ナレッジBotを「従来の人月・多重下請け」で受けた場合と、電脳技巧集団（AI職人ギルド）で作った場合を並べておく。違いは速さや値段だけではない。見積りの単位そのものが違う。

観点	従来（人月・多重下請け）	電脳技巧集団（AI職人ギルド）
見積りの単位	人数 × 時間（成果と非連動）	成果物 × 定価 ＋ AI実費パススルー
この規模の納期	数ヶ月（要件定義から積み上げ）	数日で本番稼働
コスト感	数百万円レンジ	AIで圧縮した分を開示・還元
内訳の見え方	「開発一式」＝ブラックボックス	工程・API実費まで開示
誰が作るか	多重下請け・分業	AI駆動の職人が一気通貫、要所は人間が判断（HITL）

※ 従来側は本機能群の規模（要件定義〜実装〜テスト〜PM）と公開相場の人月単価から置いた概算。CAG側は本事例の実働を基にした目安。数値はいずれもv0・公開時点で再確認する。