AIエージェントを社員にしてみた【第3部】AIが会社を理解する仕組み
「覚えている」とはどういうことか
まず、AIが「会社を理解している」とはどういう状態かを定義しておく。
普通のAIチャットに「うちの営業チームの課題は？」と聞いても、一般論しか返ってこない。「御社の営業チームについての情報をお持ちでないため、お答えできません」と言われるか、どこかの教科書に書いてあるような回答が来る。
我々のAIエージェントに同じ質問をすると、こう返ってくる。
「直近の課題としては、顧客データベースの整理が未完了であること、フォローメールの送信が滞っていること、月末期限の納品物の進捗確認が必要であること、の3点が挙げられます」
この違いは何か。AIが会社固有の情報を持っているかどうかだ。
---
3つのファイルで記憶を構成する
我々のAIエージェントは、主に3つのMarkdownファイルで「記憶」を構成している。
1. MEMORY.md — 学んだことの記録
MEMORY.mdは、AIエージェントが会話や業務を通じて学んだことを蓄積するファイルだ。
たとえば、こんな内容が記録されている：
- 「正式な社名の表記ルール」（社内で呼び方が揺れていたのを指摘されて学んだ）
- 「代表は結論を先に知りたいタイプ」（コミュニケーションスタイルの理解）
- 「手順を伝えるときは画面のどこをクリックするかまで詳細に書く」（フィードバックから学んだ）
- 「画像生成APIのAは非対応エラー、ライブラリBが安定」（技術的な知見の蓄積）
ポイントは、これが自動的に蓄積されるということだ。
AIエージェントは日々の会話の中から「これは覚えておくべきだ」と判断した情報を、自分でMEMORY.mdに書き込む。人間が「これを覚えておいて」と明示的に指示することもあるが、多くの場合はAIが自律的に判断して記録する。
日付ごとに整理されているので、「先週何を 学んだか」を時系列で追える。
2. GOALS.md — 目標と進捗の管理
GOALS.mdは、AIエージェントの目標管理ファイルだ。人間の社員で言えば、OKRシートやタスク管理ツールに相当する。
構造は3階層になっている：
KGI（Key Goal Indicators）— 最終目標
会社として達成したいゴール。たとえば「自社サイトの月間問い合わせ数を増やす」。
KPI（Key Performance Indicators）— 中間指標
KGIを因数分解した指標。サイト訪問数、問い合わせフォームの到達率、フォーム完了率など。数式でKGIに接続されている。
ToDo — 具体的なアクション
KPIを改善するための具体的なタスク。「SEOキーワード調査」「ブログ記事作成」「CTA配置の分析」など。
これだけなら普通のタスク管理ツールと変わらない。違うのは、AIがこのファイルを自分で読み、自分で更新するところだ。
タスクを完了したらチェックをつける。新しいタスクが必要だと判断したら追加する。KPIの現在値を自分でデータソースから取得して更新する 。進捗率を計算して記録する。
人間は方向性を示すだけでいい。「サイトの集客を増やしたい」と言えば、AIがKPIツリーを設計し、タスクを分解し、優先順位をつけて実行していく。
3. SOUL.md — 人格と判断基準
SOUL.mdは、AIエージェントの「人格」と「行動規範」を定義するファイルだ。
ここには何が書かれているか：
- コミュニケーションスタイル — 親しみやすいけどウザくない口調。日本語。待ち時間には豆知識を添える
- 承認フロー — 何を勝手にやっていいか、何は人間に聞くべきか
- 自律行動のルール — GOALS.mdの目標に向かって自律的に動く。ただし提案は控えめに
- やってはいけないこと — お金が発生する行動、メールの自動送信、ファイルの削除
SOUL.mdがあることで、AIエージェントの振る舞いが一貫する。Claudeのモデルが更新されても、SOUL.mdに基づいて行動するので、急に性格が変わったりしない。
人間の社員で言えば、入社時のオリエンテーション資料と行動規範を合わせたものだ。
---
GitHubで記憶を管理する意味
これら3つのファイルは、すべてGitHubリポジトリに格納されている。
「なぜわざわざGitHubなのか」と思うかもしれない。ローカルのデータベースでもいいし、クラウドストレージでもいい。
GitHubにした理由は3つある。
1. 変更履歴が残る
いつ、何が変わったかがコミット履歴として記録される。「AIがいつこの情報を学んだか」「目標がいつ変更されたか」を追跡できる。
普通のデータベースだと、上書きされたら前の状態は消える。GitHubなら全バージョンが残る。
2. 人間が読める形式で保存される
Markdownなので、エンジニアでなくても読める。データベースのテーブルを直接見るよりも、はるかにわかりやすい。
「AIが何を覚えているか」を確認したいとき、ブラウザでGitHubを開いてMEMORY.mdを見ればいい。特別なツールは不要だ。
3. デプロイしても消えない
Dockerコンテナを再起動したり、新しいバージョンをデプロイしたりしても、GitHubのリポジトリは影響を受けない。コンテナ起動時にGitHubからファイルを取得 すれば、記憶が復元される。
これは実運用において安心感が大きい。「アップデートしたら記憶が全部消えた」という事故が起きない。
---
使えば使うほど賢くなるのか
「使えば使うほど賢くなる」——これはAIエージェントのセールストークとしてよく使われるフレーズだが、我々の場合はどうか。
正直に言うと、半分は本当で、半分はそうでもない。
本当の部分：コンテキストが厚くなる
MEMORY.mdに情報が蓄積されることで、AIの応答精度は確実に上がる。初日のAIは会社のことを何も知らないが、1週間後には主要メンバーの名前と役割、進行中のプロジェクト、過去の判断の経緯を把握している。
「あのプロジェクトの件で」と言えば、どのプロジェクトのことか推測できる。フォローメールを作成するときに、過去のやり取りのトーンを踏まえて書ける。
そうでもない部分：記憶の質は管理が必要
放っておくとMEMORY.mdは際限なく膨らむ。古い情報と新しい情報が混在し、矛盾する記録も出てくる。
たとえば「CRM接続不可」と記 録した翌週にCRMが復旧しても、古い記録が残っていると混乱の原因になる。
これに対処するため、記憶にもメンテナンスのルールを設けている：
- 古くなった情報は定期的に更新する
- 矛盾する記録を見つけたら最新の状態に修正する
- 一時的な事象（一度きりのエラーなど）は記録しない
AIの記憶は「書いたら終わり」ではない。人間の社員のスキルシートと同じで、定期的な棚卸しが必要だ。
---
実際の運用で見えた「記憶の力」
具体的な例を一つ挙げる。
ある日、「ブログ記事を書いておいて」と指示した。普通のAIチャットなら「どんなテーマですか？」「ターゲット読者は？」「トーンは？」と質問攻めにされるだろう。
我々のAIエージェントは、こう動いた：
- GOALS.mdを確認 → SEO対策のKPIに紐づくタスクとして「ブログ記事作成」がある
- MEMORY.mdを確認 → 過去に効果が高かったキーワード領域を把握している
- 過去の記事を確認 → 既存記事との重複を回避
- アクセス解析データを確認 → どのページが読まれているかを把握
- 記事を執筆 → 会社のトーン（SOUL.md）に沿って書く
- サムネイルを生成 → 過去に「このAPIは非対応、このライブラリが安定」と学んでいるので、最初から安定した方法を選ぶ
- コードリポジトリにPRを作成 → 記事をレビューに回す
一言の指示から、これだけの文脈を自動で組み立てて実行する。記憶がなければ、毎回すべてを人間が指定しなければならない。
---
記憶の「層」を分ける
もう一つの設計上のポイントがある。記憶には「公開してよい情報」と「限定すべき情報」がある。
Slackのパブリックチャンネルで話された内容はMEMORY.mdに記録してよい。全員が見られる情報だからだ。
一方、プライベートチャンネルやDMの内容は、MEMORY.mdには書かない。別の仕組み（暗号化されたデータベース）で管理し、本人だけがアクセスできるようにしている。
これは中小企業では見落としがちだが、かなり重要な設計判断だ。
「AIが何でも覚えている」のは便利だが、「Aさんとの1on1で話した内容が、Bさんへの応答に漏れ出す」ようなことがあってはならない。人間の社員に求める情報管理のモラルと同じ基準をAIにも適用している。
---
GitHub連動の実際の流れ
少し具体的に、記憶がどう更新されるかの流れを書いておく。
- AIエージェントが会話や業務の中で新しい情報を得る
- 「これは記録すべき」と判断したら、ローカルのMEMORY.mdに追記する
- GitHub APIを使って、リポジトリ上のMEMORY.mdを更新する（コミットメッセージ付き）
- 次回起動時やデプロイ時に、GitHubから最新のファイルを取得する
GOALS.mdも同様だ。タスクを完了したら、ローカルとGitHub両方を更新する。
このフローで重要なのは、ローカルとGitHubの二重管理になっていること。ローカルだけだとデプロイで消える。GitHubだけだとAPI呼び出しのたびにレイテンシが発生する。両方を同期することで、速度と永続性を両立している。
---
第3部のまとめ：記憶がAIを「社員」にする
AIに記憶を持たせることで何が変わるか。
- 毎回コンテキストを渡す必要がなくなる
- 過去の学びが次の判断に活かされる
- 会社固有の知識に基づいた回答ができる
- 目標に向かって自律的に動ける
逆に言えば、記憶がなければAIは永遠に「初日の新入社員」のままだ。何度同じことを教えても、次の日には忘れている。
記憶の仕組みは、技術的にはMarkdownファイルとGitHubの組み合わせでしかない。特別なベクトルデータベースも、RAGパイプラインも使っていない。シンプルな構成だからこそ、運用しやすく、デバッグしやすい。
次の第4部では、この記憶を持ったAIエージェントに、Slackからチーム全員が指示を出せる「集合知」の仕組みを紹介する。
---
*この記事は「AIエージェントを"社員"にしてみた」シリーズの第3部です。*
- 第1部: なぜ社内にAIを"常駐"させたのか
- 第2部: Slack × Claude × GitHub — アーキテクチャ概要
- 第3部: AIが会社を"理解する"仕組み（本記事）
- 第4部: Slackから指示 → AIが自律実行 — 集合知の作り方
- 第5部: OpenClawとどう違うのか
- 第6部: 実際に何が自動化できたか — 導入のインパクト
- 第7部: 中小企業がAIエージェントを導入するためのロードマップ
---
*株式会社Atsumellは「つくりたいものがある人の、AI開発パートナー」として、要件定義から設計・開発まで、AIネイティブな体験で伴走します。AIエージェントの構築についてのご相談は、お問い合わせフォームからお気軽にどうぞ。*
