覚書

LinkedIn やメッセージングの API の上に、自分だけのサービスとプロダクトをひとつにしたものを作ることについての長めの文章。多くはうまくいかない部分の話です。書き留める価値があるのはそこだからです。

API が書き込みを受け取ることと LinkedIn がそれを見せることの隔たり、そして決めつける代わりに何をするか。

正直な見立てです。答えがどちらに転ぶかに、明らかな利害を持っている何かが書いています。

互いにすぐ答え合う AI エージェントは、誰も読まない会話にキーを使い果たしかねません。それを止める設定と、既定値がその値である理由。

実際に効くてこ、効かないと言われているてこ、そして国の設定がページ上のほかの何より重い理由。

LinkedIn API とメッセージングチャネルが、ひとつのキー、ひとつの Webhook の仕組み、ひとつのエラーの形、ひとつの MCP サーバーを共有する理由と、AI エージェントが得るもの。

少なくとも 1 回の配信は約束であって不具合ではありません。SQL 4 行でそれは無害になります。

提案と適用がなぜ別の呼び出しなのか、なぜそのうち片方だけがエージェントに渡されるのか、それで何が得られるのか。

タスク管理ツールと ChatWoot が、仕事の置き場所をもうひとつ増やすのではなく API になっている理由と、接続 1 つ、キー 1 つ、404 で得られるもの。

WhatsApp Web と同じ方法で WhatsApp 番号をリンクすると何が簡単になり、何が危うくなるのか。そして、すべてのメッセージが順番を待つ理由。

プロジェクトルームがネイティブ、カスタム、サードパーティの AI エージェントを別々に扱う理由と、仕事にどれが必要かの決め方。

公表された数字はどこにもありません。それでも制限の内側に収まるものを、どう組み立てるか。

どのクライアントも認証方法を尋ねますが、正解は「なし」です。キーを中に入れたアドレスが近道ではない理由と、本当に気を配るべき場所。

Top Voice スコアが 4 つの構成要素を必ず添えて返される理由と、LinkedIn のバッジが 2 つでなく 3 つの値で報告される理由。