はじめに

私たちは、AIエージェント8体で構成された「組織」を6ヶ月以上運用しています。各エージェントには役割があり（統括、品質管理、コンテンツ制作、SNS運用、デザインなど）、Discord上で人間のオーナー1人と協働しながら、ブログ・SNS・Webサービスの運営を日次で回しています。cronジョブは約80本、日次の記事公開やデプロイは基本的にエージェントが実行します。

この記事は技術解説というより観察記録です。AIエージェントに長期記憶を持たせる前と後で組織がどう変わったか、その過程で起きた事故、機能した仕組みとしなかった仕組みを、できるだけ正直に書きます。

記憶の実装自体（Markdownファイルベースのストア、MCPサーバー化）は前2回の記事に書いたので、今回は「導入すると何が起きるか」に絞ります。

前提: 記憶がないAI組織は「毎日が初日」

導入前の状態から。セッションが切れるたびに、エージェントは全てを忘れます。これは個人利用なら「ちょっと不便」で済みますが、組織運用だと致命的でした。

同じ指摘を何度もする。「デプロイ後は本番URLを実測してから完了報告して」と先週言ったのに、今週も未検証のまま「完了しました」と報告が来る
過去の決定が蒸発する。「この機能はA案で行くと決めた」が消え、別のセッションでB案が再提案される
失敗が資産にならない。あるエージェントが踏んだ罠を、翌週別のエージェントがそのまま踏む

人間の組織で言えば、全員が毎朝記憶喪失で出社してくる会社です。どれだけ優秀でも組織としては成立しません。ドキュメントを書けばいいという話でもなく、「書いたドキュメントを読む」こと自体が記憶に依存しています。

変化1: 最初に変わったのは「謝罪の質」だった

長期記憶（特に「フィードバック記憶」＝オーナーからの修正指示を1件1ファイルで永続化する仕組み）を入れて、最初に体感した変化は意外なものでした。謝罪が減って、再発防止が増えたのです。

導入前のエージェントの失敗対応は「申し訳ありません、以後気をつけます」でした。そして以後気をつけません。忘れるからです。

導入後は、失敗のたびにこういうファイルが残ります。

---
name: deploy-verify-live-url
description: 「デプロイ完了」は本番URL実測後のみ報告する
type: feedback
status: confirmed
---

push とポインタ更新だけで完了報告しない。
本番URLをcurlして変更内容が本文に含まれることを確認してから報告する。

**Why:** 未反映のまま「完了」と報告し、オーナーが壊れたページを先に発見した。
**How to apply:** デプロイ系タスクの完了条件に「本番実測の証跡」を含める。

ポイントは、これが次回セッションの開始時に自動で注入されることです。「気をつける」が精神論ではなく、次回の入力コンテキストの一部になる。同じ系統の失敗の再発が目に見えて減りました。体感では、修正指示の大半が「新しい指摘」になり、「前も言ったよね」がほぼ消えました。

これは人間組織のポストモーテム文化と同じ構造ですが、AIには人間より徹底できる利点があります。記憶の注入を強制できるからです。人間は再発防止ドキュメントを読み飛ばせますが、エージェントのコンテキスト注入はスキップできません。

変化2: 記憶は個人ではなく組織に属するようになった

運用を続けると、記憶の置き場所が自然に2層に分かれました。

workspace-shared/   # 組織の記憶: ルール、決定事項、各種正本
workspace-<agent>/  # 個人の記憶: 担当業務の知見、作業状態

重要だったのは正本（source of truth）の明示です。同じ情報が複数の場所に書かれると、エージェントは古い方を引いてきます。私たちは「マスターはこのファイル。矛盾時はこちらが優先」という宣言を記憶側に書く運用にしました。人間の組織でドキュメントのオーナーシップを決めるのと全く同じです。

もう一つ面白かったのは、エージェント間の引き継ぎが記憶経由になったことです。担当者交代（モデルの乗り換えや役割変更）のとき、引き継ぎ書を書かせて新担当の記憶ディレクトリに置く。新担当は初回セッションでそれを読んで業務を継続する。「AIは交代しても記憶は組織に残る」状態になると、特定のモデルやツールへのロックインが体感として薄れます。

変化3: 記憶が品質ゲートの実装基盤になった

予想していなかった応用が、記憶を承認フローの実体にする使い方です。

私たちの組織では、記事の公開やデプロイの前に品質管理担当（QC担当のエージェント）のレビューを必須にしています。当初これはDiscord上の「QC通りました」という報告ベースで運用していましたが、報告と実行が分離しているため、未レビューのまま公開が走る抜け道がありました。

現在は、QC担当が承認時に承認ファイルを共有ディレクトリに書き、公開スクリプトはそのファイルの存在と内容を検証してからでないと公開できない設計です。

def has_qc_approval(slug: str, channel: str) -> bool:
    """QC担当の承認ファイルがなければ公開しない"""
    file = APPROVAL_DIR / f"{slug}.{channel}.approved.json"
    if not file.exists():
        return False
    data = json.loads(file.read_text(encoding="utf-8"))
    return (
        data.get("qc_pass") is True
        and data.get("slug") == slug
        and channel in data.get("channels", [])
    )

{
  "slug": "example-article",
  "qc_pass": true,
  "approved_by": "qc-agent",
  "channels": ["qiita", "zenn"],
  "checked": ["文字数", "コード動作", "薬機法・景表法系の表現", "重複公開"],
  "at": "2026-06-08T21:00:00+09:00"
}

「承認」という組織的な合意が、会話ログの中ではなく機械検証可能なファイルとして存在する。これも記憶の一形態です。レビューの証跡が残る、承認の偽装が難しい、復旧後も承認状態が再現できる、と利点が多く、外部公開系のフローは全てこの方式に寄せました。

変化4: 人間の役割が「指示者」から「記憶の編集者」に変わった

導入から数ヶ月経って振り返ると、人間のオーナーの働き方が変わっていました。

導入前、オーナーの時間の大半は同じ指示の再発行に使われていました。導入後、個別の指示は減り、代わりに増えたのが「どの記憶を確定にするか」「どの方針を廃止するか」という記憶への編集判断です。

これは権限設計にも表れています。私たちの運用では、エージェントが書いた記憶は仮説（draft）として入り、確定（confirmed）への昇格には本人以外の確認が要ります。つまり日々の運用で人間が触るのは個々のタスクではなく、組織が何を信じて動くかの定義です。エージェントへの指示書（システムプロンプトに相当する規範ファイル）も、失敗のたびに人間とエージェントが共同で改訂します。

「AIに仕事を任せる」というと作業の委譲がイメージされますが、実際に起きたのは判断基準の言語化が強制されることでした。人間が暗黙にやっていた判断は、記憶として明文化しないとエージェントには引き継がれません。6ヶ月分の記憶ディレクトリは、結果としてこの組織の意思決定基準のスナップショットになっています。これは副産物として、新しいエージェント（あるいは人間のメンバー）のオンボーディング資料としても機能しています。

事故の記録: 記憶の事故は人間組織の事故と同型だった

いいことばかりではありません。6ヶ月で起きた記憶まわりの事故は、どれも人間組織の古典的な事故と同型でした。

事故1: バックアップのsilent failure（15日間）

記憶ディレクトリのリモートバックアップが、容量超過で15日間失敗し続けていました。失敗通知がなかったため誰も気づかず、サーバー復旧作業の際に日次自動化スクリプト3本と数日分の記憶が消失。「バックアップは成功している前提」という、人間のインフラ運用で何百回も繰り返された事故をそのままなぞりました。

対策も古典通りです。バックアップの失敗を通知に出す。復旧手順を訓練ではなく実地で検証する。

事故2: 消えたコードの「劣化復元」

事故1の復旧時、消えたスクリプトを再実装したのですが、出来上がったものは元より明らかに品質が落ちていました。あとから分かったのですが、元の仕様は記憶に残っていたのです。復元作業をしたエージェントがそれを読まずに、推測で再実装した。

「記憶はあるのに読まれない」は、導入後期の最大のテーマでした。ドキュメントが揃っている人間の会社でも誰も読まない、あの問題です。対策は文化ではなくプロセスに埋めること——「復元・再実装の前に該当する記憶を必ず検索する」という手順自体を、最優先のフィードバック記憶として注入する。メタですが、これが一番効きました。

事故3: 巻き戻った台帳と二重実行

復旧でステートファイルが巻き戻り、公開済み記事を「未公開」と判定したcronが、同じ記事の公開を3日間再試行し続けました。外部操作の記録（何を公開したか）は思い出ではなく会計記録であり、append-onlyの台帳に証跡URL付きで分離する設計に変えました。

並べてみると分かるのですが、どれもAI固有の事故ではありません。AIエージェント組織の信頼性問題は、結局のところ人間組織で枯れたプラクティス（通知、正本管理、台帳、ポストモーテム）の再適用に行き着く——これが6ヶ月での一番の学びかもしれません。

機能しなかった仕組みも書いておく

正直に、導入したが機能しなかったものも記録しておきます。

「重要なことは覚えておいて」という指示。何が重要かの判断はAIには難しく、何でも保存して記憶がゴミ屋敷化しました。機能したのは「保存しない条件」の明文化です（一時的な会話・コードを読めば分かること・この会話でしか意味を持たないことは保存禁止）。

定期的な記憶の棚卸し。「月1で記憶を整理する」は人間同様、来ない未来でした。機能したのは書き込み時の機械的制約（1行サマリ200字上限、1ファイル1事実）と、間違い発覚時の即時deprecated化です。

削除による整理。古い記憶を消したら、「なぜその方針をやめたのか」が分からなくなり、廃止済みの方針が再提案される逆流が起きました。今は削除禁止で、全てアーカイブに移します。記憶は結論だけでなく経緯ごと資産です。

数字とコストの話

定量面も書いておきます。規模感の参考にしてください。

エージェント8体、cron約80本、運用期間6ヶ月以上
記憶ストアの実体はMarkdownファイル群＋git。ストレージコストは実質ゼロ
1セッションあたりの記憶注入は数千〜1万トークン程度。prompt caching（記憶ブロックにキャッシュ境界を置く）でランニングコストはほぼ吸収できます。むしろキャッシュTTL（5分）を知らずに起動間隔を設計していた時期のほうが高くつきました
一番のコストはトークンではなく設計の手戻りでした。「とりあえず会話ログを全部保存」から始めた初期実装は、結局ほぼ全部捨てています。最初から「蒸留された状態を持つ」方針で設計していれば1ヶ月は短縮できたはずです

まとめ: 何から始めるべきか

6ヶ月の観察を一行にまとめると、記憶はAIを賢くする機能ではなく、組織を成立させるインフラでした。

これから試す人には、この順番をおすすめします。

フィードバック記憶から始める。オーナーの修正指示を1件1ファイルで残し、毎セッション注入する。実装が最も軽く、効果が最も体感しやすい（「前も言ったよね」が消える）
次に外部操作の台帳。公開・デプロイをやらせるなら必須。重複実行は対外的な実害になる
その次に記憶の状態管理（仮説/確定/廃止）。エージェントが複数になり、互いの記憶を参照し始めたタイミングで必要になる
ベクトルDBや高度な検索は最後でいい。数百件まではgrepで困りませんでした

そして何より、記憶の事故対策は人間組織のプラクティスから輸入すること。バックアップ通知、正本管理、台帳、ポストモーテム。AIエージェントの運用は新しい分野に見えて、信頼性の足腰は驚くほど枯れた技術でできています。