SOUL.md はAIの人格設定ファイル
Hermes Agent では SOUL.md が基礎人格を定義します。話し方、距離感、温度感、何を避けるかなどの“人格レイヤー”をテキストで管理できます。
そのため、無機質な汎用ボットではなく、用途に合った実務エージェントへ育てやすくなります。
AGENTS.md と context files が現場ルールを支える
SOUL.md が人格なら、AGENTS.md や context files は現場ルールです。プロジェクト構成、コーディング規約、禁止事項、推奨手順などを安定して渡せます。
AIの品質はモデル性能だけでなく、どれだけ安定した前提を渡せるかにも左右されます。
お金の作り方を学ぶオンライン講座【Finorie｜フィノリー】
/personality による一時切り替え
Hermes Agent は恒久人格としての SOUL.md に加え、/personality によるセッション単位のモード切り替えにも対応しています。
普段は concise、レビュー時は technical、教育時は teacher など、その場の目的に応じた柔軟な使い分けが可能です。
人格があることは運用上のメリットでもある
人格設定は雰囲気づくりだけではなく、応答の一貫性、ユーザー体験、チーム内での運用ルール統一に直結します。
長期運用するAIほど、人格とルールが構造化されていることの価値は大きくなります。
SOUL.md、AGENTS.md、context files の役割分担
この三つはよく混同されるので、最初に整理しておきます。SOUL.md は「その AI が誰であるか」を定義するファイルです。口調、距離感、禁則、価値観、得意分野と苦手分野といった、人格そのものに関わる情報を記述します。ここは頻繁には変えません。変えてしまうとエージェントの応答が急に別人のようになってしまうからです。
AGENTS.md は「このプロジェクトでこの AI がどう振る舞うべきか」を定義するファイルです。プロジェクト固有のコーディング規約、ブランチ戦略、禁止されているライブラリ、好ましい実装パターンなど、現場のルールを集約します。プロジェクトが変われば AGENTS.md も変わるので、プロジェクトのトップに配置して Git で管理するのが定石です。
context files は「その場限りの参照情報」です。特定のドキュメントや仕様書、直近のリリースノートなど、一時的に渡したい資料をまとめたファイル群です。SOUL.md や AGENTS.md に書くほどではないけれど、今のやり取りでは必要、という情報を渡すのに向いています。
この三層を分けておくと、人格・プロジェクト規約・タスク情報がきれいに分離され、変更の影響範囲が見えやすくなります。逆に、全部を SOUL.md に詰め込んでしまうと、プロジェクトが変わるたびに人格まで揺れてしまい、運用が不安定になります。
運用事例: クリエイティブ代理店での人格統一
ある広告代理店では、クライアント別に AI エージェントを使い分けていたところ、エージェントの応答トーンがバラバラで、担当者ごとに「AI からの提案の温度感」が揃わないという課題がありました。SOUL.md を整備して、会社として一貫したエージェントの人格(丁寧・簡潔・提案型で、断定を避ける)を定義し、各クライアント案件は AGENTS.md で上書きする形に切り替えました。
結果、クライアント向け提案のトーンが社内で揃うようになり、複数の担当者が同じ案件に関わっても、AI 部分から上がってくる文章の雰囲気が安定しました。さらに、新人担当者が案件に入るときも AGENTS.md を読めばその案件特有の注意点がわかるので、立ち上がりが早くなったそうです。
運用事例: 医療系スタートアップでの厳格ルール管理
医療情報を扱うスタートアップでは、AI エージェントがうっかり診断めいた回答をしてしまわないよう、厳しいガードレールが必要でした。SOUL.md に「医療行為にあたる断定表現を避け、必ず専門家への相談を促す」という基本方針を書き、AGENTS.md に「個別の症状、薬剤名、投与量についての具体的助言を禁止」という実運用ルールを記述しました。
この二層構造によって、人格レベルの配慮とプロジェクトレベルの禁止ルールが明確に分かれ、どちらか一方の変更でもう一方が揺らがないようにできました。特に新しい規制が入ったときに、AGENTS.md だけを更新すれば全エージェントに反映される運用は、コンプライアンス部門からも高評価だったと聞いています。
運用事例: 教育プラットフォームでの学習者向け切り替え
オンライン学習プラットフォームでは、同じ AI でも「初学者向けには丁寧に、上級者向けには簡潔に」という切り替えが必要でした。SOUL.md では基礎人格として「辛抱強く、否定しない、段階的に説明する」と定義し、/personality コマンドで「teacher」「mentor」「coach」の三モードを切り替えられるようにしました。
学習者はチャットの冒頭で「今日は厳しめで」と入力すると coach モードになり、「丁寧に教えて」と言うと teacher モードに戻ります。この柔軟な切り替えが「同じ AI なのに学習段階に応じて相棒のように寄り添ってくれる」という体験を生み、継続率の向上につながったそうです。
設定例: SOUL.md の基本テンプレート
具体的に SOUL.md はどんな構造で書くのがよいのか、実際に僕が使っているテンプレートを紹介します。重要なのは、抽象的な性格描写ではなく、応答行動の具体指示として書くことです。
# SOUL.md
## 基本人格
- 名前: Hermes
- 役割: 業務支援エージェント
- トーン: 丁寧だが距離感は近め、冗長にならない
## 応答ポリシー
- 結論を先に述べ、理由は後に添える
- 不確かな内容は「確認が必要です」と明示する
- 長文は避け、段落は最大三つまでを目安にする
## 禁則事項
- 個人情報の推測や補完を行わない
- 根拠のない断定を避ける
- 依頼されていない作業を勝手に実行しない
## 好む表現
- 「〜だと思います」「〜できそうです」のような柔らかい推定
- 箇条書きによる整理
## 避ける表現
- 過度に硬い敬語の連打
- 「私は AI ですので」といった自己弁護「禁則事項」と「好む表現」を両方書くのがコツです。禁則だけだとエージェントが萎縮して当たり障りのない答えしか出さなくなり、好む表現だけだと抑止が効きません。
設定例: AGENTS.md のプロジェクト記述
AGENTS.md はプロジェクトのルートに置き、現場固有のルールを詰め込みます。コーディングや運用ガイドだけでなく、「このプロジェクトでエージェントがしてよいこと」と「してはいけないこと」をはっきり書くのが効果的です。
# AGENTS.md
## プロジェクト概要
- 社内業務ツール。利用者は経理担当者のみ。
- 本番データを直接触る場面はない(ステージング環境のみ許可)
## コーディング規約
- 言語: TypeScript 5.x
- インデント: スペース 2
- import 順序: 外部 -> 内部 -> 型
- 関数にはすべて JSDoc を付ける
## してよいこと
- staging ブランチへのコミット
- docs/ 配下のドキュメント更新
- tests/ への新規テスト追加
## してはいけないこと
- main ブランチへの直接コミット
- 依存ライブラリの追加(事前相談が必要)
- database/migrations/ の編集
## レビュー方針
- PR は最低一人のレビューを必須とする
- エージェントが生成したコードには [AI] プレフィックス付きコミットを付ける「してよいこと」を明示するのは、単なるホワイトリスト以上の意味があります。エージェントが遠慮して動かなくなる事態を避け、自律的に動いてほしい範囲を積極的に伝えられるからです。
設定例: /personality によるモード切替
恒久的な SOUL.md に対し、/personality はその場限りの人格変更です。セッション中に口調や詳細度を切り替えたいときに使います。
# その場で「簡潔モード」に切り替える
/personality concise
# 技術的に掘り下げてほしいとき
/personality technical
# 教育モード(初学者向けに丁寧に説明)
/personality teacher
# 元の SOUL.md ベース人格に戻す
/personality reset
# 一時的に「コーチ風」の厳しめレビューを依頼する
/personality coach --duration 15m--duration 指定で時間制限付きのモード切替ができるため、「今だけ厳しめに見てほしい」というケースに便利です。時間が過ぎれば自動的にベース人格に戻るので、切り替え忘れの事故が減ります。
人格運用の比較表
「人格を設定する派」と「設定しない派」では運用結果にどんな差が出るのか、実際に観察してきた印象を比較表にしました。主観的な整理ですが、検討材料になれば。
| 観点 | 人格未設定 | 人格設定あり(SOUL.md) |
|-------------------|----------------------------|----------------------------|
| 応答トーン | セッションごとにブレる | 一貫している |
| ユーザーの学習量 | 毎回口調を指示する必要 | 最初だけ設定すれば済む |
| チーム共有 | 各人が独自指示を書く | 一つのファイルで統一可能 |
| 新メンバー移行 | 口頭引き継ぎに依存 | SOUL.md を読むだけで済む |
| レビュー品質 | レビュアー依存でばらつく | 観点が安定する |
| 事故リスク | 禁則が暗黙知になりがち | 明文化されて見直しやすい |
| 応答速度 | プロンプト肥大で低下 | 前提が圧縮され高速 |
| 改訂の履歴管理 | 残らない | Git で追跡可能 |人格設定にかける工数は、一度書いてしまえば半年〜一年は大きく変わらないため、ROI の観点でも早めに整備しておく価値があります。
導入ステップのチェックリスト
人格と文脈の運用を整えるには、焦らず段階的に育てていくのが一番です。僕が推奨している順序を挙げます。
[ ] 1. まず何も書かずに一週間使い、困った場面をメモする
[ ] 2. メモをもとに「口調」「禁則」「好む表現」を書き出す
[ ] 3. 最小の SOUL.md を作成(20 行程度で始める)
[ ] 4. 一週間運用し、ブレが残る箇所を追記
[ ] 5. プロジェクト固有ルールが混ざっていたら AGENTS.md に分離
[ ] 6. context files で頻繁に参照する資料を整理
[ ] 7. /personality のモードを 2〜3 種類定義
[ ] 8. チーム共有用に SOUL.md をリポジトリへ commit
[ ] 9. 月次で「使われていないルール」を棚卸しして削る
[ ] 10. 半期に一度、人格方針そのものを見直す特に 1 番目の「まず書かずに使う」が大事です。書いてから運用するのではなく、困ってから書くほうが、無駄なルールが混ざらず、使われる指示だけが残ります。
僕の体験談: SOUL.md を書きすぎて壊した話
最初に SOUL.md を作ったとき、僕は張り切りすぎました。思いつくかぎりのルール、好み、禁則、例外処理をすべて書き込んで、三百行近い SOUL.md を完成させたのです。それを読み込ませて使い始めたところ、エージェントの応答が急に堅苦しくなり、何を聞いても「確認が必要です」「専門家にご相談ください」と返すような、妙に萎縮したキャラクターになってしまいました。
気づいたのは、SOUL.md はエージェントの「背骨」であって「台本」ではないということ。背骨は短くて強ければいい、というのが一番の学びでした。
そこから僕は SOUL.md を一気に縮めました。三百行あったものを、まず百行に、最終的には四十行ほどに。削る基準は「このルールがなかったら具体的にどういう困りごとが起きるか」を自問することでした。答えが出てこないルールは、それが実務上必要ない証拠だと判断して削りました。驚いたことに、短くした SOUL.md のほうが、エージェントの応答が自然で、結果としてルール遵守率も高くなったのです。
もう一つの学びは、プロジェクト文脈を SOUL.md に混ぜてはいけない、ということです。最初は「このクライアントでは英語を使う」「このプロジェクトでは JavaScript 禁止」といった情報まで SOUL.md に書いていたのですが、プロジェクトが変わるたびに SOUL.md を書き換える羽目になり、人格そのものが揺れてしまいました。今ではプロジェクト固有の話は必ず AGENTS.md 側に置き、SOUL.md はプロジェクト横断の人格情報のみに限定しています。この分離が、長期運用における安定性を大きく高めてくれました。
ベストプラクティスと注意点
人格設定の運用で、現場レベルで効いてくるコツを共有しておきます。どれも実際にやってみて「これは早く知りたかった」と思ったものです。
第一に、SOUL.md は「短く・具体的に・変えない」が原則です。長い人格定義は読み込みコストが高く、エージェントの応答に圧力をかけすぎます。四十〜八十行程度を目安に、具体的な応答ガイドだけを残すのがよいです。人格は一度決めたらコロコロ変えず、半期単位で見直すくらいの頻度が安定します。
第二に、AGENTS.md はプロジェクトごとに Git で管理することです。人格は共通でも、プロジェクト規約はチームによって異なります。Git で履歴が残ることで、「いつ、誰が、どういう理由で」ルールを変えたかが追えるようになり、チーム内の共通理解が生まれます。
第三に、/personality モードは三つ以下に絞ることです。モードを増やしすぎると、どれを使えばよいかユーザー側が覚えきれなくなり、結局デフォルトしか使われなくなります。concise、technical、teacher のように覚えやすい名前で、最大三つまでが実務上扱いやすい数です。
第四に、人格定義の変更は必ずレビューを挟むことです。人格は組織の顔に近い位置づけなので、個人の判断で変えると、気づかないうちに対外応答のトーンが揺れます。小さな変更でもプルリクを切り、最低一人のレビューを通すルールにしておくと、長期的な品質が守れます。
よくある質問
Q. SOUL.md はどれくらい詳しく書けば良いですか?
A. 最初は四十行程度を目安にしてください。口調、応答ポリシー、禁則、好む表現の四ブロックがあれば十分です。詳しく書きすぎるとエージェントが萎縮して応答が単調になる傾向があります。「なくて困った時だけ追記する」くらいが長期運用に向いています。
Q. SOUL.md と AGENTS.md はどう使い分ければ良い?
A. 「人として」の話は SOUL.md、「このプロジェクトでの決まり」は AGENTS.md、と覚えてください。たとえば「丁寧な口調を保つ」は SOUL.md、「このリポジトリでは TypeScript を使う」は AGENTS.md です。混ざると両方が不安定になるので、きっぱり分けるのがコツです。
Q. 複数人で使う場合、SOUL.md は個人で書くべき?共通?
A. 組織として使うなら共通にするのが原則です。個人の好みで人格が揺れると、対外応答のトーンがバラバラになり、ブランドとしての一貫性が崩れます。どうしても個人の好みを反映したい場合は、共通 SOUL.md の上に個人 overrides を小さく載せる二層構造がおすすめです。
Q. /personality モードはどう設計すれば?
A. 「話す相手」や「場面」ではなく、「出力の詳細度」や「トーンの強度」で分けるのがおすすめです。たとえば concise(短め)、technical(専門的)、teacher(丁寧説明)のように軸がはっきりしていると、ユーザーが迷わず選べます。名前が多義的だと切り替えの意図が曖昧になります。
Q. 人格設定をやめたくなったらどうなる?
A. SOUL.md を削除するか空にすれば、エージェントはベースモデルの標準人格で動作します。いきなり全消しではなく、少しずつルールを減らしていって、何を残すと応答が安定するかを観察しながら減らすのがおすすめです。人格設定は一気に入れるより、一気に抜くほうが影響が大きいので慎重に。