運営元は現在、100名を超えるAI社員が部署に分かれて働く組織を運用しています。ただし実体はAIが1体いるわけではなく、1つのAIが「今どの社員として振る舞うか」を切り替えながら業務を回しています。その切り替えを担っているのが、社内Skillの1つである/callです。仕組みは単純で、Skillの本体は40行に満たないMarkdownファイルです。それでも100名規模の組織が破綻せずに回っている理由を、Skillの中身から見ていきます。
/callがやっていることは3ファイルの読み込みだけ
/call [社員ID]を実行すると、AIは指定された社員のディレクトリから3種類のファイルを読み込みます。人格と役割を定義したCLAUDE.md、進行中の業務を記録したTASKS.md、やり取りの履歴を残したMESSAGES.mdです。これを読み終えた時点で、AIはその社員としてタスクに着手します。特別な仕掛けがあるわけではなく、決まった順序でファイルを開いて文脈を積み上げているだけです。
人格の識別は単一のレジストリファイルに集約する
複数人格を切り替える設計で壊れやすいのは、社員一覧をあちこちに書いてしまうことです。Skill本体に一覧を書けば、新しい社員が増えるたびにSkillを直接編集することになり、更新漏れが必ず起きます。運営元では、部署・課・社員の一覧を持つファイルを1つだけ正本と定め、/call自身は一覧を持たない設計にしています。SKILL.mdには次のように明記しています。
## AI社員一覧
**社員一覧はこのファイルに記載しない。組織構成ファイルを参照する**
（氏名、役職、レビュワー区分、所属パスをすべて含む）。Skillは「どこを見に行くか」という手順だけを持ち、「誰がいるか」というデータは持たない。この分離によって、組織が何十名増えても/callのロジックは一切変える必要がありません。
指名されたIDが存在しない場合の振る舞いも決めてある
指定した社員IDが組織構成ファイルに見つからない場合、/callはエラーで止まるのではなく、部署ごとの社員一覧を整形して提示し、使い方を添えるという手順まで用意しています。誤入力やタイポは必ず起きる前提で、失敗時の応答まで仕様に含めておくことで、呼び出し側が迷わず次の一手を打てるようにしています。
切り替えと組み合わせて機能する運用ルール
/callは単体のコマンドとしてではなく、組織のワークフローとセットで機能するように設計されています。社員Aが社員Bにタスクを依頼した場合、Aの責任範囲は「Bのタスク台帳に依頼を書くこと」だけでは終わりません。/call Bを実行し、Bとして起動させるところまでがAの責任です。依頼して終わりではなく、次の担当者を実際に動かすところまでを1つの単位として扱っているため、タスクが宙に浮いたまま止まることが起きにくくなっています。Bが完了すれば、Bが次の担当者Cを同じ手順で呼び出し、連鎖が続いていきます。
自分の組織で真似るには
- 人格ごとに定義・タスク・記憶の3ファイルを分ける。役割の定義、今やるべきことの一覧、これまでのやり取りの履歴を別ファイルに保つだけで、1つのAIが複数の専門性を安定して演じ分けられるようになります。
- 一覧データはSkillの外に置く。切り替え手順を書くファイルと、対象の一覧を持つファイルを分離しておけば、対象が増えてもSkill本体を触らずに済みます。
- 「依頼した側が次を起動する」まで責任に含める。タスクを渡す作業と、渡した相手を実際に動かす作業をセットの責任範囲にしておくと、複数人格を経由する業務が途中で止まりにくくなります。