定義： スペシャリスト（内部呼称：Bot）とは、繰り返し行われる仕事をどうやるべきかを記憶する名前付きの永続的な AI 設定である。毎回コンテキストを再説明する一般チャットセッションとは異なり、スペシャリストは方法論、必要スキル、行動制約を保存する。「この方法論に従うリサーチアシスタントが必要だ」と会話で作成し、名前で仕事を引き継ぐ。スペシャリストはあなたが仕事を教えるたびに成長し、同じ仕事を何度依頼しても一から説明する必要がない。会話だけで作れるため、設定ファイルの知識は一切不要だ。
一般チャットの問題
一般チャットは一回限りの質問に適したインターフェースだ。それは正しい用途であり、一般チャット自体は悪くない。しかし繰り返しの仕事には不向きだ。毎週金曜日に今週の進捗を AI に要約してほしいなら、フォーマットやソースや読者を毎回再説明するか、コンテキストから覚えていることを期待するしかない。後者の場合、前回と同じフォーマットで出力される保証はない。セッションが変わればコンテキストは失われ、一貫性は偶然に左右される。加えて、複数の異なる繰り返し作業を抱えている場合、それぞれの方法論を毎回思い出して伝えるのは認知的に大きな負担だ。
スペシャリストは「How」と「What」を分離することでこれを解決する。スペシャリストは仕方を知っていて、あなたは今回やることだけを伝える。これにより一貫性が生まれ、品質が安定する。複数の異なる仕事を並行して抱えていても、それぞれのスペシャリストが個別の方法論を保持しているため、混線することはない。例えば「週次リサーチ担当」と「コードレビュー担当」の 2 つのスペシャリストを作っておけば、それぞれが異なる方法論と制約のもとで独立して動く。
5 つの Bot 定義
スペシャリストは 5 つの要素を保存する。この 5 つは相互に関連し合い、スペシャリストの振る舞い全体を規定する：アイデンティティ（名前と説明、これによりスペシャリストの目的が明確になり、ユーザーがどのスペシャリストに仕事を依頼すべきか判断できる）、行動制約（すべきこととすべきでないこと、これにより過剰な振る舞いや逸脱を防ぎ、スペシャリストの行動範囲を明確に区切る）、必要スキルとツール（実際に使う能力の宣言で、欠けているスキルは事前に検出される）、方法論（仕事への取り組み方、段階や判断基準を含み、同じ仕事を繰り返しても同じ品質が出せるようにする）、デフォルトのワークスペースバインディング（どのプロジェクトやファイルと結びつくか）。この定義は会話で作られる——設定ファイルを書く必要はない。Bot Studio セッションがこれらの 5 つのパートをコンパイルし、各 Runtime セッションに注入される Harness になる。
Harness コンパイル
Harness は純粋な TypeScript 関数だ——モデル呼び出しもテキスト解析もない。コンパイルは決定論的であり、非決定的なモデルの出力に依存しない。各 Runtime ランの開始時に、コンパイラは公開済みの Bot 定義を受け取り、スペシャリストの方法論、制約、必要ツール、ワークスペースアクセスを含むコンテキストパックを生成する。ランはスペシャリストの知識がシステムプロンプトの一部であるかのように振る舞う。これは決定論的で、同じ定義は常に同じ Harness を生成する。言い換えれば、Harness の品質は Bot 定義の品質に直接依存し、モデルの気分やランダム性には左右されない。この決定論的なコンパイルにより、同じスペシャリストに同じ仕事を何度依頼しても一貫した振る舞いが得られる。
スキル依存チェック
スペシャリストがメッセージを送る前に、必要なスキルがインストールされて有効になっているかを確認する。スキルが欠けていれば、サイレントに失敗する代わりにワンクリックインストールが提案される。これにより、スペシャリストが実際に利用できない機能を使うよう設定されているというよくある失敗モードを防ぐ。メッセージと添付ファイルは保持されるため、スキルをインストールした後に同じタスクを再実行できる。この事前チェックにより、ランの途中での予期せぬ失敗を防ぎ、ユーザーの信頼を維持する。特に新しいスペシャリストを作成した直後や、スキルの更新があった場合に、このチェックが重要な役割を果たす。
Work Item ライフサイクル
スペシャリストに割り当てられた各作業は Work Item を作成する。Work Item は作業の状態を透明に追跡し、ユーザーが現在何が進行中かを把握できるようにする。Work Item は 5 つの状態を追跡する：active（作業中）、awaiting user（ユーザーの入力待ち）、waiting external（外部サービスの応答待ち）、completed（完了）、stopped（中止）。完了はモデルが「完了です」と言っただけでは決まらない——証拠が必要だ：成功したツール結果、準備完了の成果物、承認の完了、外部副作用の確認。これにより早まった完了宣言を防ぎ、作業が本当に終わったことを保証する。Work Item の履歴はセッションとともに保存され、後から振り返ることができる。
なぜスペシャリストが独立 Agent 種であるべきでないか
意図的な設計選択として、スペシャリストは独立したエージェントエンジンではなく、Main Runtime を再利用する。つまり他のセッションと同じツール、ファイルシステム、承認モデル、会話インターフェースにアクセスできる。トレードオフは、スペシャリストが完全には隔離されず、同じランタイム機能を共有することだ。メリットはシンプルさにある：別のエージェントインフラも、別のツールレジストリも、別の承認パスも不要。ユーザーが一度学んだ操作方法はスペシャリストにもそのまま通用する。複雑さを増さずに柔軟性を確保するという設計哲学の表れだ。エコシステム全体の保守コストを抑えつつ、機能の拡張性を維持するという判断だ。
この設計は、スペシャリストと通常のチャットの間に明確な境界線を引かないという哲学にも表れている。スペシャリストは特別な存在ではなく、仕事を覚えた普通のセッションだ。ユーザーはスペシャリストを特別扱いする必要がなく、通常の会話と同じ感覚で使える。このシームレスさが、スペシャリストの採用障壁を下げている。
限界
スペシャリストは強力な仕組みだが、いくつかの制約を理解しておく必要がある。以下は、スペシャリストを設計・運用する上で知っておくべき限界だ。これらは現時点の設計上の制約であり、将来改善される可能性がある：
- スペシャリストはワークスペースレベルではなくユーザーレベルの定義だ。Work Item を割り当てるまで特定のプロジェクトに束縛されない。プロジェクトごとに異なるスペシャリストが必要な場合は、明示的にバインディングを設定する必要がある。チーム全体で共有されるスペシャリストは将来的な拡張候補だ。
- Bot 定義のバージョン履歴はない。公開スナップショットは公開のたびに上書きされる。過去のランは凍結されたリビジョンを保持するが、変更の差分を後から確認する手段は現時点でない。重要な変更をする場合は、変更内容をメモしておくと安心だ。
- Harness コンパイラは意図的にシンプルだ——モデル呼び出しもツール検出もしない。複雑なルーティングロジックはコンパイラではなくメソッド記述に置く必要がある。これはシンプルさの代償であり、複雑な条件分岐が必要な場合は方法論の記述で対応する。
- 良いスペシャリストを作るには、方法論と制約を明確に伝える必要がある。曖昧な指示は曖昧なスペシャリストを生む。Bot Studio セッションでは、具体的な例やエッジケースを交えて説明することが品質に直結する。「この場合はこうする」「この場合はやらない」といった判断基準を具体的に伝えるほど、スペシャリストの振る舞いは洗練される。
完了判定：五条件の証拠ゲート
スペシャリストの定義それ自体が、制約されたデータ構造です。五つの部分（識別、責任境界、運用ガイド、能力参照、完了基準）はすべて自然言語のフィールドで、コード、スクリプト、プロンプト、ツールスキーマ、モデル設定、あらゆる資格情報の保存は設計上禁止されています。スペシャリストが記憶するのは権限ではなく「仕事のやり方」です。フィールド長と項目数には上限があり、超過したスナップショットは黙って切り詰められるのではなく、丸ごと拒否され前一版が保持されます。
一般チャットとの最大の機械的な違いは完了判定です。スペシャリストの作業項目が自動的に完了として扱われるには、五つの証拠条件を同時に満たす必要があります。最新のゴールが達成判定され結果が使用可能であること。完了基準が実行開始前にゴールへ凍結されていること（事後の基準変更の防止）。追跡可能な結果が一つ以上存在すること（読める成果物、ツールゲートウェイが確認した外部アクション、ユーザーの確認のいずれか）。保留中の承認、失敗した必須ツール、未知の配送、未検証の副作用がないこと。ファイル配送が完全性と可読性の検証を通過すること——ファイル名や Markdown リンクの報告は完了に数えません。モデルが「完了」と言っても、項目の状態は変わりません。この五条件は、完了を言語現象から証拠の主張へ変えます。
実行側も同じ精神で決定論を重んじます。各実行の指示文脈は純関数のコンパイラが生成し、モデルを呼ばず、チャットテキストを解釈せず、ハードな長さ上限を持ち（超過すれば黙って切り詰めず失敗）、コンパイル時間は p95 5 ミリ秒未満を目標とします。公開は楽観ロックのアトミックな交換で、競合は明示的なエラーになります。作業項目の重複排除はソースオブジェクトの安定ハッシュに基づき、「似た自然言語タイトル」はキーを生成しません。システムは進捗率や状態機械のノードを保持しません。項目は五つの利用者向けの値を持ち、それ以外は普通の会話で起きる普通の作業です。
FAQ
スペシャリストについてよく寄せられる質問とその回答をまとめる：
会話でスペシャリストを作れるか？
はい。Bot Studio セッションで作業内容、方法論、制約を説明すればいい。システムが会話から定義をコンパイルする。設定ファイルの知識は不要で、自然な会話だけでスペシャリストを構築できる。何を達成したいか、どうやるべきか、何をすべきでないかを話すだけで、スペシャリストは使えるようになる。
スペシャリストは通常のチャットと同じツールを使えるか？
はい。スペシャリストは同じツールレジストリと承認モデルを使う。別途ツール設定は不要だ。ユーザーが普段使っているツールがそのままスペシャリストにも使える。新しいツールをインストールした場合、すべてのスペシャリストがそのツールにアクセスできるようになる。
必要なスキルが足りなかったらどうなるか？
送信前にシステムが欠けているスキルを検出し、ワンクリックインストールを提案する。メッセージと添付ファイルは保持されるため、インストール後にやり直す手間がない。スキルの依存関係は事前にチェックされるため、ランの途中でスキル不足が原因で失敗することは基本的にない。もしインストールに失敗した場合も、エラーメッセージとともに解決策が提示される。
作成後にスペシャリストを修正できるか？
はい。Bot Studio セッションを開いて変更を説明し、再公開する。実行中のランは凍結リビジョンを維持し、新しいランは更新された定義を使う。これにより、修正が進行中の作業に影響しないことが保証される。テストと本番の使い分けと同じ考え方で、変更は新しいランから段階的に適用される。