Tencent の teamai-cli を 1 日触ってみた — 「チームで AI の学びを共有する」CLI は何がすごいのか

1. teamai-cli は何をするものか

Claude Code や Cursor、Codex のような AI コーディングツールを使っていると、自分の手元に少しずつ「資産」が育ちます。よく使う手順をまとめた skill、AI に常に読ませる指示書 (rule)、特定のタイミングで自動実行するコマンド (hook)、外部ツールにつなぐ MCP の設定。どれも便利ですが、全部自分のマシンの ~/.claude/ や ~/.cursor/ の中にあります。

つまり、自分の AI が今日覚えたことは、隣の席の人の AI には伝わりません。チームに 5 人いれば、5 通りの環境が別々に育っていきます。teamai-cli はこの問題を解くために、Tencent が 2026 年 4 月に公開したコマンドラインツールです。GitHub の星は 1.9k、毎日コミットが積まれています。

解き方はシンプルです。チーム用の git リポジトリを 1 つ作り、そこを唯一の置き場にします。管理者がそのリポジトリに skill・rule・hook・MCP 設定を置くと、メンバーの Claude Code・Codex・Cursor が起動するたびに自動で取り込みます。逆に、メンバーが自分のマシンで作った skill は teamai push で PR になり、レビューして merge すればチーム全員に広がります。

図 1 の右側、「メンバー 1 人のマシン」の枠に注目してください。Claude Code は ~/.claude/、Codex は ~/.codex/、Cursor は ~/.cursor/ と、ツールごとに設定の置き場も書式も違います。teamai-cli はこの違いを吸収して、リポジトリに置いた 1 つの skill を 3 か所すべてに正しい形で書き込みます。対応ツールは公式には 10 以上で、OpenCode や社内向けの CodeBuddy なども含まれます。

図の下にある赤い矢印も覚えておいてください。会話から生まれた「学び」(AI が会話を要約して書く Markdown 1 枚。詳しくは §2) や利用統計は、PR を通らずに main に直接 commit されます。この点は §4 で注意点として取り上げます。

リポジトリの箱の中に「teamwiki (コードの地図)」ともあります。ソースコードを読んで部品と依存関係を書き出す付随機能で、学びと一緒に検索の材料になります。3 つの主機能とは別扱いなので、この記事では §4 で 1 回試すだけにします。

規模感としては TypeScript で 6.1 万行、テストが 2,696 件あります (15 秒で全部通りました)。ライセンスは MIT で、外部にテレメトリを送るコードはありません。LLM の API も直接叩かず、手元の claude -p や codex exec を起動して使います。

2. 何がうれしいのか — 3 つの機能

機能は「配る」「集める」「探す」の 3 つに整理できます。

配る

一度リポジトリに置けば、全員の Claude Code・Codex・Cursor に同じ skill・rule・hook・MCP が届きます。ツールごとの設定ファイルの違い、たとえば Cursor の rule は .mdc という独自形式で、Codex の MCP 設定は config.toml に書く、といった差は teamai が変換します。管理者は 1 つの書式だけ覚えればいい。地味ですが、これが無いと「レビュー前に必ず走らせる hook が A さんのマシンには入っていない」「rule の版が人によって違うので AI の答えが揃わない」といったことが起きます。ツールが 3 つ以上あるチームでは特に効きます。

配る対象は役割 (roles) やタグで絞れます。バックエンド担当には backend/ 配下の skill だけ、といった配り方ができます。他チームの公開リポジトリを「購読」して、そのチームの skill を自分たちのツールに流し込むこともできます。

集める

ここが teamai-cli の一番面白いところです。会話が終わるたびに Stop hook (AI が応答を終えた瞬間に走る hook) が、その会話の「つまずき度」を採点します。ユーザーの中断・ツール実行の拒否・言い直しといった信号を数え、閾値を超えたら AI に次のように言わせます。「この会話には記録する価値のある問題が含まれているかもしれません。学びを残しませんか」。

ユーザーが応じると、AI が会話を要約して「学び」(Markdown 1 枚。実物は次の節) を書き、リポジトリに投稿します。残した学びには自動で票が付きます。検索でヒットするたびに「引かれた」が 1 票、AI が回答の末尾で「この学びを使った」と申告すると「使われた」が 1 票。人は何もしません。よく使われるものが上に、使われないものが下に沈んでいきます。十分に使われた学びは、AI が skill や rule に書き直して「格上げ」する仕組みもあります。採点の式は §3 で詳しく説明します。

探す

作業を始める前に、AI 自身がチームの学びを検索します。検索専用の subagent (AI が呼び出す小さな AI) と、「まず検索しろ」という rule がリポジトリから配られるので、人が「そういえば誰かが同じ問題を踏んでいたな」と思い出す必要がありません。

「学び」とは具体的に何か

ここで言う「学び」は、AI が会話を要約して書く Markdown ファイル 1 枚です。先頭に題名・著者・日付・タグの frontmatter があり、本文は「背景 / 解決策 / 教訓」の 3 節。リポジトリの learnings/ に溜まっていきます。試しに投稿した実物はこんな形です。

---
title: "macOS で git clone が固まるのは credential-osxkeychain のせい"
author: (投稿者の GitHub ID)
date: 2026-09-08
tags: [git, macos, troubleshooting, credential]
---
## 背景
検証用に HOME を切り替えた環境で git clone がハングした。ps を見ると
git credential-osxkeychain store が残っていた。
## 解決策
gitconfig に credential.helper を空で追加して helper の連鎖を切る。
## 教訓
- keychain helper はダイアログ待ちで無限に止まる

この 3 つで一巡します。DB も常駐サーバも持たず、git と Markdown だけで完結するのが設計の特徴です。teamai をやめても、リポジトリの中身はそのまま人が読める Markdown として残ります。

3. 何がすごいのか — つまずきの採点

「集める」の中核である採点の仕組みを、もう少し詳しく見ます。ここが、他の「設定共有ツール」と teamai-cli を分ける部分です。

発想は「長いだけの会話」と「本当に何かにつまずいた会話」を区別したい、というものです。長い会話でも順調に進んだなら学びは少ない。逆に、ユーザーが途中で止めたり、言い直したり、ツールが何度も失敗したりした会話には、次に同じ問題を踏む人のための情報が眠っています。だから、つまずきの信号だけを数えて点にします。

図 2 を補足します。左の 4 つは強い信号で、1 回につき 20 点。1 つ起きただけで閾値の 20 点に届きます。一方、ツールの失敗回数・Skill の使用・ツールの種類数は弱い信号です。加点はされますが、積み上げだけでは閾値に届きません。例外は失敗 8 回以上 (+25) で、これだけは単独で超えます。

閾値を超えても、すぐには助言を出しません。もう 1 つの条件「ツール呼び出しが 15 回以上」を満たす必要があります。これは短い会話を除くための足切りで、実際に試すと、ツール呼び出しが 15 回未満の会話は 58 点あっても何も出ませんでした。そして助言は会話につき 1 回だけ。記録ファイルに「助言済み」のフラグを立てて、2 回目以降は黙ります。

「言い直した」の検知方法も面白くて、AI の応答が終わってから 60 秒以内に、次のユーザー発言に「違う」「そうじゃなくて」「やり直して」のような訂正語が含まれていたら数えます。試しに日本語で「違う、そうじゃなくて別のファイルを直して」と送ったら、言い直し 1 回として数えられました。

うまいと思ったのは、閾値の設計そのものです。「短い会話では黙る」「同じ会話で 2 回言わない」が実測でも効いていて、うるさくならないように作られています。閾値 20 を選んだ理由もコードの注釈に書いてあり、「強い信号 1 つで届き、加点の積み上げだけでは届かない」という意図が読めます。

もう 1 つ、設計として感心したのは hook の書き方です。teamai は既存の hook には触らず、自分の分だけを末尾に追記します。差分が無ければファイルに書き込みません。書き出す内容はテストでバイト単位に固定してあるので、CLI を更新しても無駄な書き換えが起きない。「ツールを入れたら自分の設定が消えた」が起きないよう、かなり気を使っています。

4. 動かして分かった注意点

README の説明が本当かどうか、実際に動かして確かめました。自分の本当の ~/.claude/ を汚さないよう、隔離した HOME ディレクトリを用意し、GitHub に試験用の private リポジトリを作って、管理者とメンバーの両方の立場で初期化から uninstall まで 15 の操作を試しました。

配る側は、本番で使える品質でした

表の 1〜3 と 10 がそれです。隔離した HOME で本物の Claude Code を起動しました。未ログインのため即終了しましたが、起動時の hook は発火し、teamai のダッシュボードにセッションが記録されました。hook の配線が本物で動く証拠です。

検索は、まだ弱い

日本語の学びを 4 件投稿して、日本語と英語で 13 問検索した内訳が表 2 です。

答えがある 12 問のうち、正解が 1 位に来たのは 6 問でした。検索は単語の一致だけで、意味の近さは見ていません。同じ内容を別の言葉で聞くと別の学びが出てきますし、コードの地図 (ソースコードから部品と依存関係を書き出す機能) を混ぜると、その概要ページが学びを押しのけて 1 位になります。日本語の単語の切り方が中国語向けなので、「クローン」が「ク」と「ローン」に割れる、といったことも起きます。

助言の文面と、学びを書く skill の出力は中国語固定です。日本語に対応しているのは言い直しの検知語だけで、これも 2026 年 9 月に外部の貢献者が入れたばかりでした。日本語チームで使うなら、この 2 つは自分で差し替える前提になります。

導入前に決めておくこと 4 点

第一に、学びと統計がレビューなしで main に入ります。学びは AI が書いた文章で、次の pull で全員の AI が検索して読みます。つまり、誰も確認していない文章が全員の AI の回答に混ざります。業務リポジトリをそのままチーム用にするモードなら学びも PR を通りますが、製品のコードに AI のメモを混ぜたくないなら、専用リポジトリにして「学びは誰が見るか」を決めておく必要があります。

第二に、チームの hook は任意のシェルコマンドです。リポジトリに push できる人なら誰でも、次の pull で全員のマシンで実行させられます。初期設定では確認なしで適用されます。設定で「pull では適用せず、明示的な inject コマンドを要求する」に変えられるので、導入時に切り替えたほうがいいでしょう。

第三に、環境変数の値が平文で git に commit され、clone したリポジトリの .git/config には GitHub のトークンも平文で残ります。シークレットはここに置かないルールが要ります。

第四に、uninstall しても Claude Code の hook が 1 本残ります。teamai は自分が足した hook を settings.json の description 欄の文字列で見分けます。ところが Claude Code は設定を書き直すときにこの欄を消します。目印を失った teamai は自分の hook を見分けられず、消し残します。Codex と Cursor は別の方法で管理しているので、こちらはきれいに戻りました。

5. まとめ

teamai-cli は「チームの AI 設定を配る」道具としては、もう十分に使えます。既存の設定を壊さない hook の書き方、ツールごとの書式変換、役割やタグで配る範囲を絞れる点は、同じことを自作するならそのまま参考にしていい水準です。

本当に新しいのは「集める」側、つまり会話のつまずきを採点して学びを残すよう促す仕組みです。ただし、集めた学びを検索する部分は単語一致で言い換えに弱く、生成される文書は中国語固定なので、日本語チームがそのまま使うにはまだ早い。そして学びが PR を通らず全員の AI に読まれる作りは、導入前に運用ルールを決めておかないと事故の元になります。

個人的には、採点の式と閾値の設計だけでも読む価値がありました。「強い信号 1 つで届く、弱い信号の積み上げでは届かない、短い会話は足切り、1 会話 1 回だけ」という 4 つの原則は、自分のツールに hook を加えるときにそのまま使えます。