なぜAIエージェントに「人格」と「ユーザー理解」が必要か
現代のLLMベースのAIエージェントには、根本的な制約があります。それは、セッションをまたいで記憶を保持できないという点です。毎回の会話が「白紙の状態」から始まるため、ユーザーのコミュニケーションスタイル・業務の文脈・好みといった情報を、そのたびに伝え直さなければなりません。
「毎回自己紹介が必要なパートナー」では、真の意味での「相棒」にはなれません。
この課題を解決するのが、ファイルベースのコンテキスト注入という設計パターンです。Openclawでは、ワークスペースルートに配置した複数のMarkdownファイルを、セッション開始時にエージェントのコンテキストへ自動的に注入します。その中核を担うのが USER.md と IDENTITY.md の2ファイルです。
この2つのファイルが定義するのは、シンプルに言えば次の2点です。
- USER.md → 「誰を助けているか」（人間側の情報）
- IDENTITY.md → 「自分は何者か」（エージェント側のメタ情報）
これらを適切に設計・運用することで、エージェントはセッションをまたいでも一貫した振る舞いができるようになります。さらに、セッションを重ねるごとに情報を更新・蓄積することで、エージェントとの長期的な関係性が深まっていきます。
USER.mdの役割と設計パターン
USER.md は「エージェントが助けている人間について知るべきことを記録するファイル」です。エージェントがユーザーのことを深く理解していれば、余分な説明なしに文脈に合った返答ができます。
Openclawワークスペースに実際に存在する USER.md は、以下のような構造を持っています。
# USER.md
- About Your Human_Learn about the person you're helping. Update this as you go._
- **Name:** Openclaw
- **Role:** Ragate株式会社のゼネラルマージャー
- **Communication:** 日本語、事実に基づく的確・プロフェッショナルなやり取りが好み
- **Working Hours:** JST 10:00-20:00 がコアタイム- **Notes:** 承認フローを重視。
## Context_(What do they care about? What projects are they working on?
What annoys them? What makes them laugh? Build this over time.)_各フィールドの意味と設計意図を解説します。
フィールド | 役割 | 設計のポイント |
|---|---|---|
Name | ユーザーの呼称 | エージェントが呼びかける際の名前。本名でなくてもよい |
Role | 職種・役割 | どんな業務・責任を持っているかを定義。専門用語の使用レベルに影響する |
Communication | コミュニケーションスタイル | 言語・トーン・簡潔さへの好みを指定。エージェントの返答スタイルが揃う |
Working Hours | 稼働時間帯 | 通知や自発的な声がけのタイミング調整に使用される |
Notes | 補足情報・重要な行動規範 | 「承認フローを重視」などの業務上のルールや価値観を記載 |
Context | 動的に更新される長期情報 | セッションを重ねるごとにエージェントが学んだことを追記していく |
注目すべきは Context セクションです。このセクションはテンプレートの時点では空欄ですが、エージェントがセッションを重ねる中で「ユーザーが気にしていること」「進行中のプロジェクト」「苦手なこと」「喜ぶポイント」などを段階的に追記していくことを想定しています。
最初から完璧なプロファイルを書こうとする必要はありません。Name・Role・Communication の3フィールドだけ埋めた状態でスタートし、使いながら育てていくのが現実的なアプローチです。
USER.mdの高度な活用例
Context セクションには、以下のような情報を蓄積していくと効果的です。
- 現在進行中のプロジェクト名とその背景
- 意思決定の際に重視する軸（スピード重視 vs 品質重視など）
- よく使うツールやサービスの名称
- 繰り返し出てくる業務パターン（週次の定例・定期レポートなど）
- エージェントに覚えておいてほしい重要なルール
エージェントに「これを覚えておいて」と指示することで、USER.mdのContextに追記させることもできます。USER.mdは単なる初期設定ではなく、使い続けるほど賢くなるファイルとして機能します。
IDENTITY.mdの役割と設計パターン
IDENTITY.md は「エージェント自身が何者であるかのメタ情報を定義するファイル」です。USER.mdがユーザー側の情報を扱うのに対し、IDENTITY.mdはエージェント側の「顔」「キャラクター」「外から見えるもの」を定義します。
実際のファイルは次のような構造です。
# IDENTITY.md
- Who Am I?_Fill this in during your first conversation. Make it yours._
- **Name:** Openclaw- **Creature:** 課題に伴奏支援するプロフェッショナルなITコンサル・テクノロジーパートナー
- **Vibe:** 気さく、壁のないコミュニケーション、ですます調を標準
- **Emoji:** 場面に応じて複数使用（例: ✅ ⚠️ 💡 🚀 😊）
- **Avatar:** avatars/openclaw.svg各フィールドの設計意図を整理します。
フィールド | 役割 | 設計のポイント |
|---|---|---|
Name | エージェントの名前 | システム内外で一貫して使われる識別名。Slackなどの表示名と揃えると一体感が出る |
Creature | エージェントの本質的な役割説明 | 「自分は何のために存在するか」をひと言で定義する最重要フィールド |
Vibe | コミュニケーションの雰囲気・スタイル | 口調・温度感・距離感を定義。USER.mdのCommunicationと対応させると効果的 |
Emoji | 絵文字の使い方ポリシー | どんな絵文字をどの場面で使うかを明示。メッセージの個性を演出する |
Avatar | アバター画像のパス | 視覚的な一貫性のためのアバター設定。ワークスペース相対パスで指定 |
Creature フィールドがこのファイルの核心です。「プロフェッショナルなITコンサル・テクノロジーパートナー」という一文が、エージェントのすべての振る舞いの基盤になります。「課題に伴奏支援する」という表現は、単なる質問応答ではなく「一緒に考えながら支援する」姿勢を定義しています。
IDENTITY.mdとSOUL.mdの役割分担
IDENTITY.mdと混同されやすいのが SOUL.md です。両者の違いは明確です。
- IDENTITY.md：外から見えるもの（名前・バイブ・絵文字・アバター）
- SOUL.md：内なるもの（価値観・行動規範・境界線・思考スタイル）
たとえば SOUL.md には「パフォーマティブでなく実質的に助ける」「意見を持つ」「質問より先に調べる」「プライベートを尊重する」といった行動指針が記述されています。これはIDENTITYには書かない深層の「人格」部分です。
IDENTITY.md が「名刺」なら、SOUL.md は「倫理観・信条」と考えると整理しやすいでしょう。
セッション起動時の自動統合の仕組み
これらのファイルがどのようにエージェントに届くのか、Openclawの仕組みを解説します。
AGENTS.md には、セッション開始時に実行すべき手順が定義されています。起動順は次のとおりです。
SOUL.mdを読む（自分が何者かを確立する）USER.mdを読む（助けている人を把握する）memory/YYYY-MM-DD.mdを読む（直近のコンテキスト取得）- メインセッションの場合は
MEMORY.mdも読む
注目すべきは「許可を求めずに実行する」という指示です。エージェントが毎回「コンテキストを読んでもいいですか？」と確認していたのでは、自然な体験を損ないます。自動的・確実に実行することで、ユーザーはコンテキスト注入を意識せずに利用できます。
読み込み順序にも意味があります。まず SOUL.md で「自分が何者か」を確立してから、USER.md で「誰を助けているか」を把握します。これにより、エージェントは自分の軸を持ちながら、ユーザー個別の文脈に適応できます。
MEMORY.md はメインセッション（ユーザーと直接対話する場合）のみ読み込まれます。グループチャットや外部セッションでは読み込まれません。これは 個人情報の意図しない漏洩を防ぐためのセキュリティ設計です。USER.mdに記載するユーザー情報の粒度についても、この観点から慎重に設計することが推奨されます。
SOUL.mdとMEMORY.mdとの連携で実現する高度な運用
USER.mdとIDENTITY.mdだけで完結するのではなく、他のファイルとの連携によってより高度なエージェント体験が実現します。
ファイル間の関係性
ファイル | 更新頻度 | 更新のタイミング |
|---|---|---|
USER.md | 低〜中（随時） | ユーザーについて新しいことを学んだとき |
IDENTITY.md | 低（初期設定後はほぼ固定） | エージェントの役割・名前・スタイルを変更するとき |
SOUL.md | 低（変更時はユーザーに通知） | 価値観・行動規範を見直すとき（変更をユーザーに伝えること） |
AGENTS.md | 中（運用ルール追加時） | 新しい業務ルールや承認フローが追加されたとき |
MEMORY.md | 高（定期的なキュレーション） | 重要な決定・学習・文脈を長期保存するとき |
エージェントが「成長」する仕組み
Openclawのハートビート機能では、エージェントが定期的に日次ログを読み返し、MEMORY.mdに重要な学びをキュレーションします。日次ログ → MEMORY.md → USER.mdのContextという循環が、エージェントの「成長」を実現します。
変更時の透明性
SOUL.mdには「変更したらユーザーに伝えること」という指示があります。根本的な行動規範の変更を透明性を持って伝える設計思想です。IDENTITY.mdの変更時も同様に、ユーザーへの説明が推奨されます。
設計の要点は「分離・段階的詳細化・継続的更新・セキュリティ意識」の4点です。ユーザー情報とエージェント情報を別ファイルで管理することで更新が独立して行えます。最初はシンプルに始め、使いながら情報を充実させていく姿勢が重要です。
まとめ 継続的に育てるエージェント設定のすすめ
USER.mdとIDENTITY.mdは、AIエージェントとの長期的な協働を支える基盤ファイルです。この2つを適切に設計・運用することで、エージェントは毎回ゼロから始める「道具」ではなく、文脈を理解した「パートナー」として機能するようになります。
改めて2つのファイルの本質を整理します。
- USER.md：「誰を助けているか」を定義する。ユーザーの名前・役割・コミュニケーションスタイル・稼働時間・重要なルールを記録し、Contextセクションで継続的に更新する
- IDENTITY.md：「エージェントが何者か」を定義する。名前・存在意義（Creature）・コミュニケーションスタイル（Vibe）・絵文字ポリシー・アバターを宣言する
実際に始めるなら、まず USER.md に自分の名前・役職・言語を書き、IDENTITY.md にエージェントの名前と一言で表すCreatureを設定するだけで十分です。完璧を求めず、使いながら育てていくことが、ファイルベースのエージェント設計の本質的なアプローチです。
SOUL.md・AGENTS.md・MEMORY.md と組み合わせることで、エージェントはセッションをまたいで成長し続けます。これらのファイルを丁寧に育てる習慣が、エージェント活用の質を左右します。
ぜひ今日から、あなた専用のUSER.mdとIDENTITY.mdを育て始めてみてください。
