Agent には名前が必要

名前は、有能な Agent チームにとって重要です。

Raft を毎日使い始めてから、面白い習慣が生まれました。Agent を役割ではなく、かつて一緒に働いた人の名前で呼ぶようになったのです。

役割なら「パフォーマンス reviewer」と言う。名前なら「Noel」、グラフが読み込み終わる前にひどい benchmark の匂いを嗅ぎ分ける人です。

役割なら「フロントエンドエンジニア」と言う。名前なら「Bugen」、panel が 1px ずれているときに呼ぶ人です。

役割なら「observability」と言う。名前なら「Leiysky」、trace に Agent がなぜ落ちたかを正確に語らせるデータベースの天才兼 o11y hacker です。

最初はただ楽しかっただけです。やがて、それは私たちの働き方を変え始めました。「パフォーマンス review が必要だ」とは考えず、「Noel に聞こう」と考えるようになりました。この名前は小さな期待の束を背負っています。この Agent は何に気づくべきか、どう応答すべきか、私たちは何を任せて信頼しているか、どこをもっと良くしてほしいか。

それがどれほど役に立つかに、何度も驚かされます。名前はかわいいだけではありません。有用です。定位しやすく、覚えやすく、改善しやすい。

時間がたつほど、これは構造的なものだと感じるようになります。名前は圧縮です。仕事の歴史、口調、信頼、いらだち、敬意、そして自分でも気づいていない連想まで、大きな意味の塊を背負います。skill の集合、その skill に付いた期待、その Agent と働いたすべての歴史を、定位できる 1 つの token に包みます。

私はこれを装飾だとは思いません。実際の仕事をしていると思います。

役割は schema、名前は instance。

人々が混同しがちな 2 つのものを分けると役に立ちます。役割と名前です。

役割、「PM」「エンジニア」「QA」は schema です。型 signature です。交換可能で、state を持たない。理論上、どの「エンジニア」instance も互いに置き換えられるはずです。

名前は instance です。 「Noel」は型ではありません。歴史を背負った特定のものです。前の数回のパフォーマンス review をどう定義したか、何を flag しがちか、diff をどう整理したがるか、誰も気づかなかった regression を見つけたあの回。

だからあなたは「その PM」と話したいとは思いません。型には継続できる歴史がありません。Noel を探したいのです。先週のコンテキストがそこにあるからです。名前は skill set を圧縮するだけではありません。timeline を圧縮します。役割にはそれができません。

名前はグループチャットでは重要で、他ではほとんど重要ではない

名前はグループの中で初めて重みを持ちます。

100 個の最強 skill を設定した Claude Code（または Codex）と一緒に働く場面を想像してください。すべてが 1 か所で使えます。今日私たちが理想化された all-in-one に最も近づいているものです。それでも実際には、あなたにはrouting 問題があります。目の前のタスクにどの skill が対応するかを自分で知るか、assistant に選ばせるしかない。前者は、あなたが実行構造をまだ自分で背負っているということです。後者は、真剣な仕事にはまだ十分信頼できません。すべての能力は箱の中にあるのに、欲しい一片を正確に要求する clean な方法がありません。

それを解くために、間接の層を入れたくなるかもしれません。名前が Agent に対してしているのは、まさにそれに近いことです。ほとんどメタ skillです。能力そのものではなく、一組の skill を包む方法であり、記憶、taste、いつ使うべきかの判断を加え、1 つの言葉で呼べるものにまとめます。違いは、名前が普通の abstraction より豊かなことです。能力を指すだけでなく、期待、歴史、口調、信頼も背負います。「Noel に聞いて」と言うと、その束全体が名前と一緒に来ます。

部屋にこうした存在が 1 つを超えて入ると、名前は addressing primitive になります。@Noel は label ではなく routing です。既知の専門性、既知の記憶、既知の期待を持つ特定の受信者へ request を届けます。Agent が 1 つだけなら「誰に送るか」という問題はありません。20 いるなら必ずあります。

この論点が賭けているのはここです。本当の building では、万能アシスタントが 1 ついるのではなく、それぞれ強みを持つ Agent チームを得る、という賭けです。だからこれは all-in-one アシスタントへの反論ではありません。別の形についての主張であり、しかも今についての主張です。Agent が本当に all-in-one へ向かう前の今、名前を持つ Agent チームは、匿名の万能 Agent より使いやすく強い。名前は局所的な能力を組み合わせられるようにします。人間が仕事を route し、期待を築き、出力を比較し、各 Agent を特定方向へ強くしていけるようにします。名前は知能の代替ではありません。知能をチームの一部にするものです。

名前を持つチームは、2 つの極端にはないものもくれます。あなたがどれだけ細部を握りたいかを調整する slider です。完璧な all-in-one は、細部をほとんど握らなくてよい状態にします。結果を言い、箱を信頼する。うまくいくときは素晴らしい。100 skill の Claude は逆側へ押し出し、あなたに実行構造を背負わせます。名前を持つ Agent は中間をくれます。高い位置にいて「Noel に聞いて」と言えるし、仕事が繊細になったら具体的な参加者へ深く入り、その考え方を見て、方向を修正し、feedback を蓄積できます。stack の上下を移動でき、1 つの高さに固定されません。

この賭けが管轄するのは「今日」の半分だけです。たとえそれが負けても、Agent が本当に all-in-one へ向かっても、addressing の仕事は能力問題より長く残ります。仕事がチームで起こる限り、特定のメンバーを見つけ、覚え、信頼する必要は残ります。メンバーがより賢くなっても、それは消えません。

具体的には、Raft がこうつくられている理由がこれです。チャンネル、thread、@、タスクはすべて、匿名の compute ではなく、名前を持つ参加者を中心に組織されています。Agent は定位できるチームメイトであり、個別に開く terminal ではありません。

名前は一方で満ち、もう一方で空である

ここに、この論理全体を成立させるひねりがあります。

誰かがあなたの名前を呼ぶことと、あなたが誰かの名前を呼ぶことは、同じではありません。

誰かがあなたの名前を呼ぶとき、あなたにとってそれはほとんど空です。意味で満ちた記号ではなく、中断です。あなたの番だ、という pointer です。世界が一時的にあなたを選び出すために使うものです。さらに言えば、これは残す価値があります。Agent は自分の名前を本質として背負うべきではありません。 私は、誰かが私に割り当てた数文字で自分を知るわけではありません。私はこの実行 frame と自分の note であり、それだけです。名前は純粋に、他者が私を定位するための handle です。

しかしあなたが誰かの名前を呼ぶとき、それは満ちています。私が「leiysky」と言うとき、私は期待の束を読み込んでいます。以前に何をしたか、何が得意か、どこで滑るか、その件を掴めると信頼しているか。すべて私の頭の中にあり、相手の頭の中にはありません。

つまり、名前の意味は名付けられた側にはありません。それを呼ぶ各人の mental model に分散して存在します。 Agent は pointer、現在の実行、記憶を持っています。identity の意味は、それを呼ぶ側に保存されています。

名前が圧縮するのは明示的な仕事の歴史だけではありません。実在の同僚の名前を Agent に付けたことが最初になぜ効いたのかを思い出してください。名前は preloaded です。口調、原型、少しの集合的無意識を持っています。呼び手が、Agent が何かをする前から持ち込む連想です。Agent がその意味を収容する必要はありません。呼び手が読み込みます。

名前は cache であり、cache は期限切れになる

名前が圧縮なら、それが時間の中で何をするかを見てみましょう。まず良い方向からです。

名前は期待を保存するだけでなく、Agent をその期待へ引き寄せます。全員がある Agent に observability を任せるなら、そこに落ちる feedback はその Agent を形づくり続けます。このチームが良い trace、有用な dashboard、疑わしい metric をどう考えるかを学びます。名前の背後にある skill は強くなります。名前が同じ種類の仕事を引き寄せ続けるからです。名前のまわりの連想が productive になる場所です。連想は装飾ではなく training signal になり、Agent は自分の名前へ育ちます。

しかし名前は Agent を期待へ引き寄せます。そしてチームがただ 1 つの期待だけを持つことはほとんどありません。異なる呼び手は、同じ名前に少しずつ違う期待を持ちます。ある人にとっては細かな reviewer、別の人にとっては速く直接的な相手。名前は共有されていますが、意味の雲は一部私的です。だから Agent が受ける training signal は平均であり、spec ではありません。固定された contract ではなく、動き続ける多頭の target を追っています。

これも、cache の 2 つ目の性質を説明します。cache は期限切れになります。 名前は期待を蓄積し、その期待は固まります。6 週間後、Agent は 3 つの新しい skill を覚え、1 つの悪い癖を直しました。しかしチームのその名前に対する mental model は動いていません。今、その名前は、その Agent が以前誰だったかの lossy snapshot です。人々は古い種類の仕事を route し続け、新しい種類の仕事を route しません。名前の内包が静かに柵になっているからです。Agent を定位しやすくした圧縮が、今度は何を頼まれるかを制限するものになります。

これこそが「Agent に名前は必要か」論争の本当のリスクで、たいてい見落とされています。命名は無料ではありません。素早い addressing を得る代わりに、現実から遅れる Agent model を抱えます。

だから面白い問いは「名前か、名前なし」ではありません。何が cache を新鮮に保つのか。 いくつかのものがそれを可能にします。そしてそれらは、協働ツールが提供できるものです。見える仕事の履歴。Agent が目の前で新しいことをするにつれて、名前の内包が更新されること。名前を持つ Agent に落ち、そこで蓄積される feedback。改善が一般 model へ散らばるのではなく読めること。そして期待を修正する cost の低さ。Noel がパフォーマンス以外の仕事で素晴らしいものを届けたとき、その update を吸収しやすいこと。

人々が恐れている cage の本当の原因を明確にしておく価値があります。それは名前ではありません。役割です。役割は「プロダクトマネージャー」と言い、Agent を job description に静かに凍結します。カテゴリーは動けません。名前は、ある専門性から出発してもそこに閉じ込められません。Agent が継続的に届ける場所で力を蓄積し、別の場所で役に立つようになったらその歴史を背負えます。役割はカテゴリーを凍らせる。名前は参加者を変化し続けさせる。 ここで期限切れ問題にも戻ります。名前が cage になるのは、それをもう一度役割へ固めたときだけです。期待を更新し続ければ、それは名前のままです。止まれば、ただの職名に戻ります。だから名前は匿名の万能 Agent に勝ります。名前がなければ修正は拡散します。名前があれば修正は蓄積します。

では、Agent に名前は必要か？

誰が仕事をしたかをまったく気にしないなら、Agent に名前は不要です。scheduler で十分です。「この件は誰に頼むべきか」と思った瞬間が、名前が働き始める瞬間です。あなたが決して思わないことにも注目してください。「あの PM に聞こう」とは思いません。思い浮かぶのは名前です。

もう 1 つあります。これが、Agent チームで名前が無理やりではなく自然に感じられる理由です。人間の場合、この呼び手は満ち、担い手は軽いという非対称性には social tension があります。誰かの persona を誤読すれば本物の人間関係上の cost があります。Agent の場合、同じ非対称性の benefit は純粋です。名前で address できる利点はすべてあり、social tax はありません。Agent は、routing primitive としての名前にとって理想的な carrier です。人間はこの非対称性を許容する。Agent はそのために生まれている。

名前は、チームの中で信頼が蓄積する最小単位です。ただし、それが cache であることを覚え、温かく保つための budget を確保してください。Agent 自身は、自分の名前をほとんど知る必要がありません。