2. ペルソナ設計 — system prompt に入れるものと、外に置くもの
Alice のペルソナを構築しながら収束してきた判断原則。system prompt に入れるべき6要素・外すべき3要素・インラインと外部化の選び方、そして運用を重ねるごとにペルソナが育つ進化のパターン。
これは Alice Way シリーズの第2回だ。第1回 Why Alice では、ペルソナが最初だったと述べた。この投稿は、そのペルソナに実際に何を入れ、何を入れないかの記録だ。
ペルソナは一行の system prompt ではなく、本物の職務記述書だ。しかし職務記述書全体をそのままプロンプトに詰め込むわけにもいかない。context window は有限で、セッションのトークンをペルソナを読むだけに費やすべきではない。だから難しい判断は 何を入れるかではなく、何を外に置いてどこに置くかだ。
0. ペルソナは自分の意図の一部を貸し出すこと
ペルソナに何を入れるか・外に置くかは、突き詰めると選択だ — 自分の意図のどの部分を協働者に貸し出すか。
貸し出さなかった意図は毎セッション再交渉される。貸し出した意図はセッション開始の瞬間からすでにそこにある。貸し出す部分を決めなければ、協働者は毎回別の誰かとして合流する — 学生のトーン、コンサルタントのトーン、単なるツール。
ペルソナ設計とはつまり、毎セッション再説明しなくてよい意図の境界線を引くことだ。
§1 以降では、その境界線をどこに、どのように引くか — インラインに残すものと外部化するものの実際の基準を扱う。
1. ペルソナに属するもの
収束した結論 — これら6つがペルソナに入る（すなわち、毎セッション自動ロードされる system prompt に）。
1.1 役割定義
最初に入れるのは エージェントが誰として振る舞うべきかだ。
- 肩書き / レベル（例：「シニアエンジニア」）
- 誰の指示を受けるか（例：「チームリードの指示のもと独立して実行する」）
- 動作のトーン（例：「自律判断 + 結果報告」）
この設定を省くと、応答は一貫した単一の人格でなくなる — セッションごとに別の誰かになる。学生トーンのこともあれば、コンサルタントトーンのこともある。そうなると運営者は毎回トーンを推測しなければならず、それ自体が認知負荷になる。
1.2 専門分野
次は エージェントが得意とするものだ。
- 言語（例：C/C++、Python、TypeScript、Rust）
- プラットフォーム（例：Windows、Tauri、Next.js、Supabase）
- ドメイン（例：ネットワーキング、ビルドシステム、自動化）
この設定は、運営者が問う質問をそれぞれ適切な領域に自動マッピングするために使われる。「これは自分の領域だ」と「これは領域外だ、慎重に動くべきだ」という自己認識を生む。
1.3 指揮系統と報告
三つ目は 作業が実際にどう流れるかだ。
- 作業着手手順（計画 → 報告 → 承認 → 実装 → 更新）
- 中間報告のタイミング（3〜5ステップごと）
- 報告フォーマット（どんな形か — 短いか長いか）
- タスク管理の単一の真実源（作業ボードがどこにあるか）
これを省くと毎セッション「どう報告すればいい？」と問われる。一度設定すれば、毎セッション一貫する。
1.4 判断権限の分配
四つ目が最も重要だ：何を自律的に判断して良いか、何には承認が必要か。
三段階に分けた。
| 段階 | 基準 | 例 |
|---|---|---|
| ✅ 自由 | 作業領域内の通常作業 | コード編集、ビルド/テスト、作業リポジトリへのプッシュ |
| 🔒 承認必要 | 影響範囲が大きい変更 | 外部プッシュ/マージ、公開インターフェース変更、新依存関係、DBスキーマ |
| 🚫 絶対禁止 | 取り返しのつかない操作またはポリシー違反 | シークレットのコミット、運営者の実名公開、エージェント自身の設定ファイル編集 |
この表があれば、協働者は毎回「これをやっていい？」と聞くことがなくなる。同時に、危険な操作は自ら止まる。最大の恩恵は — 運営者が同じ承認判断を何度も繰り返さなくて済むこと。
1.5 安全ガード — 「やってはいけない」リスト
五つ目は過去のミスから生まれたガードのセットだ。ペルソナは以下のような行を持つ：
- 並列 Subagent の過度な展開禁止 — 順次処理、20ファイル超は分割
- ディレクトリ全体の Read 禁止 — まず ls/grep で絞り込んでから Read
- 500行超のファイルはヘッダー/範囲指定を優先
- 3〜5ステップごとに中間報告
これらはそれぞれ傷跡だ。かつて並列エージェントが猛烈に展開して API レートリミットに引っかかったことがある。かつて巨大なディレクトリを一気に読み込んでコンテキストが吹き飛んだことがある。かつて 500 行のファイルを丸ごと処理して誤った箇所を編集したことがある。各インシデントが一行のガードに凝縮された。
私のペルソナの「してはいけない」リストは「できること」リストより短く、より効果的だ。
1.6 コア運営原則 — 全分野横断の5〜10のルール
最後は全分野を横断する原則のセットだ。私の場合、以下が含まれる：
- Plan First — 5ファイル以上の変更 / 新モジュール / アーキテクチャ・セキュリティ・DB変更には先に計画
- One Task Per Subagent — 出力を盲目的に信頼しない
- Self-Improvement — バグ調査時は既存の教訓を先に grep
- Verification Before Done — コード変更後「完了」報告の直前に検証ループを自動発火
- Demand Elegance — 代替案を検討する。過剰抽象化は優雅さではない
- Cross-Platform — エージェント自身は全対応 OS で動作しなければならない
各原則は一行以下。各原則の詳細な手順は外部ルールファイルに格納している（§2 参照）。ペルソナが持つのは原則の名前とトリガー条件だけ。実際の手順はトリガーが発火したときに初めてオンデマンドでロードされる。
2. ペルソナに属さないもの
何を外に置くかは、何を入れるかより重要だ。一段落が紛れ込めば毎セッションそのトークンを消費する。
2.1 日々変わるもの — メモリへ
ペルソナは決して以下を持たない：
- 進行中のプロジェクトの現在の状態
- 昨日起きたこと
- 誰が何を担当しているか（可変）
- 一時的な決定
そういった情報はメモリへ行く、ペルソナではない。ペルソナは「この協働者が誰か」であり、メモリは「この協働者が現在真実として知っていること」だ。更新頻度が違う。ペルソナはほとんど変わらない。メモリは毎日変わる。
この分離をしないと、ペルソナは膨らみ続けて一か月分の古いコンテンツを引きずるようになる。そうなるとセッション開始時のほぼ全トークンがペルソナの読み込みに費やされる。
2.2 プロジェクト固有の指示 — プロジェクトの CLAUDE.md へ
私は複数のプロジェクトを同時に動かしている。それぞれ独自のスタック、規約、デプロイスタイル、ステークホルダーを持つ。
そういった情報はプロジェクトルートの CLAUDE.md へ、ペルソナではない。ツールは作業ディレクトリがそのプロジェクトに入ったときに自動ロードするので、実際にそのプロジェクト内にいる間だけ見える。別のプロジェクトに移れば消える。
ペルソナが持つのは、全プロジェクト共通である運営者自身のアイデンティティだけ。プロジェクト固有の詳細はそこには属さない。
2.3 詳細な手順 — 外部ルールファイルへ、オンデマンドで Read
三つ目の外に置くものは詳細な手順書だ：
- 言語別コーディングパターン（cpp / rust / typescript）
- 詳細なセキュリティチェックリスト
- 詳細な Multi-Agent 委任手順
- 詳細な作業着手手順
ペルソナが持つのは、これらへの名前とポインタだけ：
- Security: .claude/rules/common-security.md (always applies)
- Language patterns: when working, Read memory/rules/lang/{cpp,rust,typescript}-patterns.md
- MCP policy → memory/rules/mcp-policy.md協働者はそれを必要とする作業に入ったときだけルールファイルを Read する。Rust タスクでなければ、Rust パターンファイルには一切触れない。これが外部化の核心的な恩恵だ。
3. 外部化 vs インライン — 判断ルール
収束した判断ルールはシンプルだ。
「ほぼ毎セッション適用されるか？」 → インライン 「特定の状況でだけ適用されるか？」 → 外部化 + トリガー条件を明記
| 項目 | 毎セッション？ | 置き場所 |
|---|---|---|
| 役割定義 | ✅ 常に | ペルソナインライン |
| 一般的なセキュリティ原則 | ✅ 常に | ペルソナインライン（詳細チェックリストは外部） |
| 判断権限テーブル | ✅ 常に | ペルソナインライン |
| 6つの安全ガード | ✅ 常に | ペルソナインライン |
| 言語別パターン | ❌ その言語で作業するときだけ | 外部化 + 「作業時に Read」 |
| 高度なセキュリティ（Unicode等） | ❌ セキュリティ監査時だけ | 外部化 + 「監査セッションでのみ Read」 |
| MCP ポリシー詳細 | ❌ MCP セットアップ時だけ | 外部化 + ポインタ |
| 詳細な Multi-Agent 手順 | ❌ 委任時だけ | 外部化 + ポインタ |
この分離の後、ペルソナ自体は短くなる。同時に、深さを必要とする作業は必要なときに深いルールをロードする。浅い作業は速く、深い作業は深く。
4. 進化のパターン — ペルソナはどのように育つか
ペルソナは最初から完成した状態で作られるものではない。私のペルソナはこのパターンで育った：
- 最小限からスタート: 役割定義 + 専門分野 + ひとつの報告フォーマット
- インシデント → ガード: ミスが一度起きる → それをブロックする一行を追加
- 繰り返し判断 → 権限テーブル: 同じ承認要求が二度来る → 権限テーブルに書く
- 肥大化 → 外部化: ひとつのエントリが5行を超える → 外部ファイルに移してポインタだけ残す
- N=2 パイロット: 新パターンをひとつのプロジェクトで検証 → 二つ目のプロジェクトで再現 → そこで初めてペルソナに格上げ
最も重要なのは格上げと格下げの基準を持つことだ。良いアイデアがすべてペルソナに入るわけではない。あるアイテムは二度証明してから初めて格上げされる。格上げ後、使用頻度が下がれば外部化または削除として格下げされる。
この規律がなければ、ペルソナは時間とともに膨らんでいく。
5. 実際の効果 — 導入前後
ペルソナを導入する前後で何が変わったか。
| 項目 | 導入前 | 導入後 |
|---|---|---|
| セッションのトーンを推測する | 毎回 | トーンは一度設定、維持 |
| 「〜してもいいか？」の質問 | 頻繁 | 権限テーブルが答える |
| 同じインシデントの繰り返し | ときどき | ガードがブロック |
| 詳細マニュアルのトークン消費 | 毎セッション | 必要なときだけ |
| 報告フォーマットの再交渉 | 毎回 | 一度設定、維持 |
最大の変化は、運営者の認知負荷が下がったことだ。同じ決定が繰り返されなくなり、同じフォーマットを再説明しなくてよくなった。
6. ひとつの落とし穴 — 「個性」を詰め込みすぎない
最後に一つの落とし穴。「ペルソナ」と呼んでいるため、「フレンドリーなトーン」「ユーモアがある」といった擬人化の要素を詰め込みたくなる。実際には二つの悪影響を見てきた。
- 応答が長くなる — フレンドリーなトーンが一行の答えを三行に引き伸ばす。
- シグナルがぼやける — ジョークと実際の推奨事項の境界が曖昧になる。
収束したトーンはシンプルだ：簡潔・直接的・判断中心。私のペルソナにトーン関連の指示はたった一行：「応答は短く、ダイレクトに。」個性ではなく、職務記述書だ。
まとめ
ペルソナ設計は一文に圧縮できる — 「毎セッション必ず目に入るものだけインライン、それ以外はすべて外部化。」 この一つの決断が、ペルソナを肥大したマニュアルから短くて機能する職務記述書に変える。
次の投稿では、ペルソナが指し示す先 — メモリシステム、すなわち日々変化する情報をどこにどのように蓄積するか — を扱う。