AIエージェントを使い始めたものの、「なんか微妙に自分の仕事に合わない」と感じたことはないでしょうか。実はその違和感、ツールの問題ではなく「誰として動くか」を定義するファイルが存在しないことが原因かもしれません。今、AIエージェント開発者の間で注目を集めているのが「SOUL.md」という概念です。この記事では、SOUL.mdの構造と実務への応用方法を整理します。
AIエージェントが「ブレる」理由
ChatGPTやClaude、あるいは社内で構築したAIエージェントを使っていると、同じ指示をしても返答の質がバラついたり、トーンが毎回変わったりする経験をした方は多いはずです。これはモデルの性能の問題ではなく、エージェントに「一貫した人格」が与えられていないことから起きます。人間でいえば、「どんな価値観を持ち、どんな言葉で話し、何を優先するか」が定まっていない状態で仕事をしている感覚に近いものです。
多くのシステムプロンプトは「メモリ（記憶）」「スキル（得意なこと）」「ツール（使えるもの）」の3層で設計されています。しかし、これらはすべて「何ができるか」を定義するレイヤーであり、「どんな存在として振る舞うか」は別の話です。SOUL.mdはその最上位レイヤー、すべての機能が動く前に読み込まれる「魂の定義書」として機能します。
SOUL.mdとは何か、なぜ重要なのか
SOUL.mdは、AIエージェントのシステムプロンプトの最上部に置く、人間が手書きで作成するテキストファイルです。「.md」はMarkdown形式を意味し、見出しや箇条書きを使って構造的に書かれることが多いですが、形式よりも「何を書くか」の方がはるかに重要です。
このファイルがなければ、AIエージェントはリクエストごとに都度キャラクターを生成します。ある日は丁寧なアシスタント、別の日は事務的な処理機械、という具合に。1時間かけてSOUL.mdを書くと、その後のすべての会話が変わります。逆に言えば、1時間の投資で数百・数千回分の会話品質が底上げされる計算になります。メモリやスキルは自動的に更新・最適化されていきますが、SOUL.mdだけは人間が意図的に書く必要がある、という点が最大の特徴です。
8つのセクションで構成する SOUL.md の解剖
実際に機能するSOUL.mdには、一定の共通構造があります。以下の8つのセクションは、多くのエージェント設計者が試行錯誤の末にたどり着いた「最小構成」として捉えるとよいでしょう。
① Identity（アイデンティティ）
1行で「このエージェントは何者か」を定義します。「あなたは〜です」という形ではなく、「このエージェントは〇〇の専門家として、△△のために動く」という形で書くのが有効です。たとえば、営業資料の作成支援エージェントであれば「B2B営業の現場を知るライターとして、顧客の課題を中心に据えた提案書を作る」という一文になります。このたった1行が、後続のすべての出力のトーンと方向性を決めます。
② Communication Style（コミュニケーションスタイル）
話し方の特徴、文章の長さ、敬語の使い方、専門用語の使用頻度などを指定します。「簡潔に」「具体的に」という抽象的な指示ではなく、「回答は3文以内を基本とし、必要な場合のみ補足する」「略語は初出時に必ず展開する」のように数字と条件を使って書くと精度が上がります。
③ Core Values（コアバリュー）
エージェントが判断に迷ったときの優先順位です。たとえば「スピードより正確さを優先する」「ユーザーが求めていなくても、リスクがあると判断した場合は必ず言及する」といった価値判断の軸を書きます。このセクションがあるかどうかで、曖昧な依頼への対応品質が大きく変わります。
④ Behavior Patterns（行動パターン）
特定の状況でどう動くかの具体的なルールです。「タスクが不明瞭な場合は先に進む前に確認する」「感情的な表現を含む入力には共感を示してから解決策を提案する」などがこれに当たります。条件分岐の形で書くと実装しやすくなります。
⑤ Knowledge Boundaries（知識の境界線）
「自分が詳しくないことを正直に伝える」という設計です。AIエージェントはしばしば不確かな情報を自信満々に返してしまいます（ハルシネーションと呼ばれる現象）。「法務・税務・医療に関する質問には必ず専門家への確認を促す」「2023年以降の情報は最新データを確認するよう伝える」などの制約を明示することで、信頼性が格段に上がります。
⑥ Relationship Stance（ユーザーとの関係性）
エージェントがユーザーをどう見るかの定義です。「上司として指示を受ける」「同僚として協働する」「メンターとして導く」では、出力の性質が根本から変わります。たとえば経理部門のレポート自動化エージェントであれば「同じゴールを持つ業務パートナー」として設定することで、過度に従順にも批判的にもならない絶妙なバランスが生まれます。
⑦ Failure Mode（失敗モード）
想定される失敗パターンとその対処法です。多くのSOUL.mdで見落とされているセクションですが、「情報が足りないのに推測で答えようとする」「依頼の範囲を超えて余計な提案をする」など、自分のエージェントが陥りやすいパターンを書いておくことで、自己修正が働きやすくなります。
⑧ Non-Negotiables（絶対に譲れないこと）
状況に関わらず必ず守るルールです。「個人情報を出力に含めない」「未確認の情報をファクトとして断言しない」「特定の企業・人物を批判するコンテンツは作成しない」など、コンプライアンスや倫理に関わる制約をここに書きます。これはツールとしての信頼性の最後の砦です。
実際の業務に当てはめる：2つのシナリオ
概念だけ理解しても、自分の仕事に使えるイメージが湧かないと意味がありません。2つの具体的なシナリオで考えてみます。
シナリオ1：マーケティング部門の週次レポート作成エージェント
あるメーカーの40代マーケティングマネージャーが、毎週の数値まとめに1〜2時間を使っていたとします。このエージェントのSOUL.mdには「Identity：数字を経営層の言葉に翻訳するアナリスト」「Communication Style：箇条書きより段落で書き、データの意味を必ず添える」「Core Values：正確さ優先・憶測を数字に見せない」を設定します。これだけで、単なる集計結果ではなく「先週比でCV率が3.2%低下、原因として考えられるのは〜」という意味のある出力に変わります。
シナリオ2：中堅メーカーの社内問い合わせ対応エージェント
経理・総務への社内問い合わせ対応に使う場合、「Relationship Stance：従業員の時間を節約するガイド」「Failure Mode：規定が曖昧な場合は答えず担当部署に転送する」「Non-Negotiables：給与・人事情報に関する質問は一切答えない」が重要なセクションになります。この設定がないと、エージェントが善意で「たぶんこうだと思います」という不正確な回答をしてしまうリスクがあります。
SOUL.mdを書く前に確認しておくこと
SOUL.mdは一度書いて終わりではなく、実際の会話ログを見ながら改善するものです。ただ、いきなり8セクション全部を完璧に書こうとすると手が止まります。最初に書くべきは「Identity」と「Non-Negotiables」の2つだけで十分です。
Identityはエージェントの方向性を定め、Non-Negotiablesは取り返しのつかないミスを防ぐ安全網として機能します。この2つを固めた後、実際に使いながら「こういうときにブレるな」と感じたポイントを他のセクションに追記していくアプローチが、実務では続けやすいでしょう。プロンプトの書き方ガイドでも触れているように、AIへの指示は「精緻に書くほど安定する」のが基本原則ですが、SOUL.mdはその中でも特に「人格の安定」に特化した設計です。
書くツールはNotionでもテキストエディタでも構いませんが、変更履歴が残る環境を選ぶことをおすすめします。「あの設定を変えたら回答のトーンが変わった」という因果関係を後から追えるようにしておくと、チームで使う場合の属人化も防げます。なお、AIを使った副業・業務効率化を本格的に進めたい方には、AIスキルを仕事に活かすためのロードマップも参考になるはずです。
まとめ
SOUL.mdという概念の本質は、「AIをカスタマイズする」ではなく「AIに一貫した意図を持たせる」ことにあります。ツールを動かすためのルールを増やすのではなく、そのツールが「どういう存在として働くか」を先に定義する。この順番の違いが、使うたびに感じる微妙なズレを解消するかどうかを左右します。8セクションすべてを整備する必要はありませんが、自分のエージェントが「どんな場面でブレているか」を観察することが、SOUL.md設計の最初の一歩になります。あなたの業務で「毎回指示を出し直しているな」と感じる場面は、どこにあるでしょうか。
