people-context：Agent の対人記憶を、review できる一つの local SQLite に戻す
agent に codebase を覚えさせる方法は、すでにかなり揃っている。難しいのは「人」を覚えさせることだ。同僚の呼び名と role、前回約束したこと、相手が email を好むか meeting を好むか。こうした情報は inbox、calendar、自分の note に散らばっている。全部を汎用 memory に入れるのは手軽だが、data はどこに置かれるのか、model はどの record を見られるのか、誰かを忘れたいとき本当に消えるのか、という基本的な問いには答えにくい。
今日見る JinyangWang27/people-context は、local-first の MCP server と CLI だ。「人」を query 可能な local record として扱うことに焦点を置き、name、alias、relationship、organisation と role、interaction summary、reminder、timeline、communication preference を、自分の machine の一つの SQLite database に置く。個人 knowledge base の代わりではなく、agent により狭く、より明確な people context を渡す project だ。
GitHub repository page、README、LICENSE、main commit feed、Releases page を 2026-09-19 18:05 Asia/Shanghai 時点で確認すると、JinyangWang27/people-context は 52 stars、2 forks。主要 language は Python、license は MIT。repository は 2026-07-16 16:08:36 UTC に作成された。main の latest HEAD は f16c758、latest push/commit は 2026-09-19 09:49:49 UTC で、pctx browse に browser batch review flow を加える内容だ。最新 GitHub Release は v1.2.1、published at は 2026-09-14 17:20:11 UTC。main では import review 関連の改善が続いているので、integration では無条件に main を追わず release か明示した version を pin したい。
プロジェクト概要
| 項目 | 内容 |
|---|---|
| リポジトリ | JinyangWang27/people-context |
| 位置づけ | 対人情報向けの local-first MCP server と CLI |
| Stars / Forks | 52 / 2 |
| 主要 language | Python |
| ライセンス | MIT |
| 作成日 | 2026-07-16 16:08:36 UTC |
| Latest push / main HEAD | 2026-09-19 09:49:49 UTC / f16c758 |
| 最新 Release | v1.2.1、2026-09-14 17:20:11 UTC |
| local storage | 一つの SQLite database。MCP または pctx CLI で操作 |
「誰」を first-class data にしているのが効く
一般的な note memory は text を探し直すのは得意でも、同じ名前の人を扱うのは得意とは限らない。people-context の README は name、nickname、alias、handle を explainable な name resolution に入れている。同名の候補は match reason と一緒に返り、model が黙って一人を推測しない。relationship、organisation、role、interaction summary、trait、reminder、timeline も別々の field として置かれ、agent は request に必要な範囲の context を取れる。
これは日常の具体的な摩擦に効く。たとえば partner との meeting 前に「何を知っておくべきか」を聞く。遅延連絡を書くとき、記録された communication preference を使って tone の案を出す。あるいは pctx stale で長く follow-up できていない関係を探す。contact system を chat に移すのが本質ではない。回答が model の即席の印象だけでなく、structured record に戻れることが重要だ。
import と sensitive data を自動化の副作用にしない
project は email、mbox、vCard、calendar、LinkedIn、Outlook、WhatsApp export を、まず review 対象の candidate として stage できる。人が review してから commit する流れだ。README は raw source content を保持しない、通常 command は network に出ない、write は audit されると明記している。過去の材料から連絡先情報を抽出するような、過剰収集になりやすい場面では、agent がそのまま長期 memory に書くより staged flow のほうが予測しやすい。
ordinary context と sensitive record も分けている。sensitive data は operator-only gate が必要で、prompt 自身がそれを有効にすることはできない。forget は本当の delete として扱われ、audit 内の private value も対象にする。これだけで万能な privacy 保証になるわけではない。import 前に、材料を処理する権利があるかは依然として判断が必要だ。それでも data flow に human confirmation と明示的な deletion semantics が残るのはよい。
まず fictional data で境界を確認する
project は Python 3.11+ と uv を要求する。最も慎重な試し方は、実際の inbox をすぐにつなぐことではなく、uvx --from people-context pctx demo --reset を先に走らせることだ。専用の fictional database が作られ、MCP client でそのまま使える server command と sample call が表示される。name resolution、get_relationship_graph、disclosure の response shape を確認してから pctx init を実行するか、uvx --from people-context pctx setup <client> で editor の設定を書くとよい。
注意したいのは、local が自動的に encryption を意味しないことだ。README によれば default は plaintext SQLite。Unix では新しい file の permission が 0600 になり、SQLCipher の optional encryption path も用意されている。顧客、同僚、親しい人の情報を実際に記録するなら、device disk encryption、backup location、shared account、retention policy を先に確認したい。MCP server は起動 user の filesystem permission を引き継ぐ。tool の範囲制御は host-level security governance の代わりにはならない。
まとめ
people-context を試す価値は、もっと賢い contact app を作ろうとしていることではない。agent の対人 memory を点検可能な local model に分けている点にある。同名の曖昧さは明示的に返り、import は stage してから review し、sensitive data には別の gate があり、deletion にも意味がある。agent に meeting preparation、follow-up、writing で関係の背景を理解させたいが、この種の情報を default で cloud memory に預けたくないなら、まずは用意された fictional demo から始め、低い sensitivity の record に限って自分の境界を作るのがよさそうだ。