2026.08.10

APIで取れないチャットを集めて、案件ごとに仕分ける

Ryosuke Ishii

複数のチャットに散らばったやりとりを集めて、案件ごとにまとめています。集める側は正式な受け口が使えないものが半分あり、集めたあとは「どの案件の話か」を決める必要がありました。

散らばったやりとりを1か所に集めるところまでは、わりとすぐ動きました。そこから2ヶ月半かかったのは、集めたものがどの案件の話なのかを決めるところです。

プロジェクト台帳の作り方ノート②です。取り方の勘所と、仕分けの設計を書きます。長くなります。

先に、動いているところをご覧ください。

デモ動画（48秒）受け口があるものと無いもの → 案件を決める手順 → やりとりが案件ページに入るところ → 知らない部屋を聞いてきて、答えると登録されるところ。画面はすべてダミーです

この機能で何がよくなったか
前半：集める
後半：どの案件の話かを決める
0件は、平和なのか、壊れているのか
まとめ

この機能で何がよくなったか

全部のチャットを毎日は見ていません。動きの少ない部屋もありますし、しばらく開いていない部屋もあります。

それでも困らなくなりました。集めることだけは毎晩しているので、案件のページを開けば、そこに何が来ていたかが載っています。見ていないものを、見なくてよくなりました。

前半：集める

受け口があるチャットの取り方

正式な受け口（API）があるものは、そこから取ります。決めることは4つです。

1. どの単位で取るか。 部屋（チャンネル）単位で取ります。スレッドがあるものはスレッドの中も取ります。部屋のIDと案件の対応表を1つ持って、そこに書いてある部屋だけを見に行きます。全部の部屋を舐めると、関係ない社内の雑談まで入ってきます。

2. どこまで遡るか。 既定は14日です。毎日動かすので本来は1日分でいいのですが、前日に失敗していても翌日に取り戻せるように幅を持たせています。取り込み済みかどうかは、メッセージのIDで判定します。時刻で判定すると、同じ秒に複数来たときに落ちます。

3. 権限を分ける。 会話を読む権限と、発言者の名前を調べる権限が別物でした。読む権限だけでは名前が引けず、IDのままになります。2種類を使い分けて、本文中のメンションのIDも人の名前に直しています。

4. 自分の発信だけを取らない。 これは最初に間違えました。日々の記録として自分の送信メッセージは保存していたので、それを流し込めば済むと思っていたのです。使えませんでした。案件の文脈は、相手の発言のほうに入っています。

受け口が無いチャットの取り方

ここからが本題です。正式な受け口が使えないものが、うちには半分あります。理由は権限で、取引先の側に入って仕事をしていると、連携の許可を出す立場に自分がいません。

やり方は、ブラウザを人の代わりに動かして、画面から読むというものです。ただしこれは素直には動きません。踏んだ落とし穴の順に書きます。

① ログイン状態を、毎回作り直さない。
毎晩ログインからやり直す作りにすると、二段階の確認が飛んできて止まります。ログイン済みのブラウザの状態（プロファイル）をそのまま保存しておいて、毎晩それを使います。人が普段使っているブラウザとは別に、この用途専用のものを1つ持ちます。

② ログインが切れても、エラーにならない。
これがいちばん厄介でした。切れるとログイン画面が返ってくるだけで、そこから読み取れる会話は0件です。仕組みとしては「今日は何もなかった」と同じ形で終わります。取れなかったことと、無かったことが区別できません。

対策として、ログイン状態を保つ処理を別に走らせています。ただしこれも1回失敗しました。裏で開いていたタブが省エネ機能で眠っていて、保つ処理が空振りしていたのです。タブを読み込み直す方式に変えて直しました。

③ 会話を切り替えたつもりで、切り替わっていない。
一覧から次の部屋を押しても、画面が入れ替わる前に読み取ると、前の部屋の中身を次の部屋の記録として保存してしまいます。同じ発言が2つの案件に入ります。

直したのは、押したあとに2段階で確認することです。会話の見出しが期待したものに変わっているか。本文の中身が、押す直前と変わっているか。この2つが両方そろって初めて「切り替わった」と認めます。 片方だけだと通ってしまいます。確認に失敗したらその部屋は飛ばして、記録の末尾に残します。黙って間違ったものを保存するより、取れなかったと分かるほうがいいからです。

④ 発言者の名前が、途中から消える。
同じ人が続けて発言すると、2回目以降は名前が表示されません。画面の見た目どおりに取ると、2件目以降が「発言者不明」になります。

対策は、画面に並んでいる順に読んで、名前が出てきたらそれを次の名前が出るまで引き継ぐことです。これをやらないと、誰が何を言ったかが半分消えます。

⑤ 引用返信が、その人の発言として混ざる。
相手のメッセージを引用して返信すると、画面上は引用部分も同じ吹き出しの中に入ります。素直に取ると、引用された他人の言葉が、返信した人の発言として記録されます。 案件のまとめに、言っていないことが書かれてしまいます。

引用の部分を見つけて、〔引用 ◯◯さん「…」〕のような印を付けて本文と分ける形にしました。

⑥ 時刻が「3時間前」としか書いていない。
画面の表示は相対時刻のことが多いものです。そのまま保存すると、あとから並べ直せません。取り込んだ時点の日付と突き合わせて、絶対時刻に直してから保存します。

⑦ 過去の分は、勝手には出てこない。
古いメッセージは、上にスクロールして初めて読み込まれます。折り畳まれた返信も開かないと出てきません。日が経つほど取りこぼすので、遡って取り直すときは早いほうがいいということになります。

そして、そもそも外から読めないもの。
個人向けのチャットのように、ブラウザからも読む手段がないものがあります。これはグループに業務用のアカウントを1つ入れてもらって、その画面を読む形にしました。参加者の一覧に出ている状態で読んでいます。隠して録っているわけではありませんし、自分が入れないグループのやりとりを取る手段は持っていません。

複数の組織に所属している場合。
取引先ごとに別の組織として招かれていると、同じサービスでも組織を切り替えないと会話が見えません。切り替えの操作も自動化の対象に入れて、組織ごとに順番に回しています。

受け口があるものは正式な口から、無いものは画面から読むか記録役を置く。時刻を決めて寄せる

毎晩の巡回の組み方

動く時刻を決めて、そこに全部寄せています。

やりとりの収集は深夜2時。台帳の組み直しは朝6時。通知は7時。人は起動しません。

時刻を分けているのは、収集が終わっていないのに組み直しが走ると、前日のデータで作り直してしまうからです。間を空けています。

後半：どの案件の話かを決める

集めるのは半分でしかありませんでした。

記録に残っている改修は全部で47件。そのうち15件がこの部分です。 しかも最初の週から最後まで、途切れずに出続けている唯一のテーマでした。

材料が3種類あって、手がかりが全部違った

同じ「振り分ける」でも、材料ごとに別の作りが要りました。

打ち合わせ。 予定に付けた題名が第一の手がかりです。これは社内のルールとして決めました。出席者と、話された中身で補います。この方式にするために、会議の題名の付け方そのものを全件見直して統一しました。 道具を直すのではなく、入力する側のルールを変えた例です。

チャット。 部屋の名前と相手で決まります。部屋が案件に対応していることが多いので、強い手がかりになります。

AIとの作業。 手がかりがありません。作業の中身を読んで判定するしかありません。しかも1つの作業が複数の案件にまたがります。

実際に使っている呼び方を、案件ごとに持たせる

正式な案件名では当たりません。

案件の正式名が「◯◯株式会社データ基盤刷新プロジェクト」だとして、実際のやりとりでそう呼ぶ人はいません。「基盤の件」「刷新PJ」「◯◯さんの案件」になります。

だから案件ごとに、実際に使われている呼び方を登録して増やし続けています。 ここがいちばんオリジナルになる部分で、他社の設定をそのまま持ってきても意味がありません。

点数を付けて、しきい値で切る

やりとりの本文と、各案件の呼び方を突き合わせて点数を付けます。いちばん高い案件に紐付けます。

そのうえで2つの制御を入れています。

識別する力のない言葉を外す。 これがいちばん多い失敗の原因でした。会社名が入っているというだけで、まったく別の案件に入ります。定例会議の名前に共通の単語があるだけで取り違えます。よく使う言葉ほど、強く当たってしまいます。

同点なら、紐付けない。 迷ったら決めません。間違って入るより、空欄のほうが害が小さいからです。誤って入った1件は、あとから見つけるのが難しいものです。

1つの部屋が、2つの案件に関係していた

部屋と案件は1対1ではありませんでした。同じ相手と、複数の案件の話を1つの部屋でしていることがあります。

最初は1つの部屋に1つの案件しか割り当てられない作りにしていました。あとから、1つの部屋を複数の案件に配れるようにして、全部の入口に標準で備えました。値を1つ書くか、複数書くか、どちらでも受け付ける形にしています。

名前の照合には、2つの落とし穴があった

人の名前を手がかりに使うとき、2回つまずきました。

敬称。 「田中さん」と「田中」が別物として扱われます。呼び方の揺れは、思っているより多いものです。

字体の違い。 見た目がほぼ同じで、コード上は別の文字になっているものがあります。これは目視では気づけません。

どちらも、比較する前に形をそろえる処理を入れて直しました。

案件に親子を作ったら、照合が壊れた

案件が増えてきたので、まとめ役の案件を作って個別の案件をぶら下げました。整理としては正しかったのですが、自動処理が壊れました。

まとめ役の名前は、ぶら下がる案件より短くて一般的な言葉になります。 すると子と同点になって保留が増えたり、識別力のない言葉だけでまとめ役が単独で勝ってしまったりします。

直し方は、まとめ役かどうかを表す印を台帳に持たせて、照合の対象から外すことでした。ここで1つ判断が要りました。「子を持っているかどうか」で外すと、もともと子ページを持ちながら議事録が紐づいていた案件まで外れてしまいます。だから「子を持つか」ではなく「まとめ役の印が付いているか」で判定するようにしました。

整理のために作ったものが、機械の判断を狂わせる。作ってみるまで気づけない類のことでした。

結局、ここだけずっと直していた

なぜ終わらないのか、理由ははっきりしています。案件が増える。呼び方が増える。材料の種類も増える。

だから、育てる手段のほうが大事になります。人が「新しい部屋ができたから登録しないと」と気づいて手を入れる運用は続きません。忙しい時期ほど気づけないからです。

いまは、知らない部屋を見つけたら向こうから聞いてきます。 毎晩集めるときに名簿にない部屋を拾って、最初のメッセージを1行添えて「どの案件に入れますか」とチャットに出ます。答えるだけで済みます。一度答えれば、その部屋は二度と聞かれません。

振り分けが終わらない仕組みなら、終わらせないための入口を用意しておく。そういう考え方です。

0件は、平和なのか、壊れているのか

集める仕組みには、独特の弱点があります。うまくいっていないことが、平穏に見えます。

ここが設計の分かれ目でした。

ある部屋が毎日0件で記録されていました。静かな部屋だと思っていたのです。実際は取り込みが壊れていて、契約に関するやりとりが1件も残っていませんでした。

いまは、一定の期間なにも届かない状態を異常として扱っています。何も起きていないことと、届いていないことは、区別しないといけません。

判定はシンプルで、その部屋の直近の記録がどれだけ空いたかを見ます。空きすぎたら通知に出します。復旧したら静かに戻ります。

まとめ

集めるのは半分です。残りの半分は「どの案件の話か」を決めること
材料ごとに手がかりが違います。打ち合わせは題名、チャットは部屋、AIとの作業は中身
実際に使っている呼び方で照らします。正式名では当たりません
識別する力のない言葉は外します。同点なら紐付けません
振り分けは作り切れません。育て続けるものなので、育てる入口を作ります
0件は正常と区別がつきません。届いていないことを検知します

同じシリーズ

考え方のほうはこちら 👉 業務をシステムに合わせるのを、やめました
作り方ノート①「AIの要約が浅いのは、渡している材料が足りないから」 👉 AIの要約が浅いのは、渡している材料が足りないから
作り方ノート③「案件・人・会社の3つの名簿を、1つの台帳につなぐ」 👉 案件・人・会社の3つの名簿を、1つの台帳につなぐ
体験談はXに書きました 👉 案件の状況を、自分で思い出すのをやめた話（X）

ABOUT ME