ローカルで動かすLLM（大規模言語モデル）エージェントの状態管理に関心があるSRE・インフラ担当者に向けた内容です。2026年10月に公開された「bio.md」という設計パターンを、可用性設計とオブザーバビリティ（システム内部の状態を外部から観測できるようにする仕組み）の視点から整理します。
bio.mdは、エージェントの人格設定・スキル・記憶・実行時状態・会話履歴を、1つのMarkdownファイルに集約する設計です。Hermes、Pi、Ghostyy、OpenClawといったローカルエージェント実行基盤（ハーネスと呼ばれる、モデルに入出力やツール呼び出しの枠組みを与える層）が乱立するなかで、状態が複数のファイルやDBに散らばる問題への対策として提案されています。設計そのものはシンプルですが、本番運用を見据えると可用性・監視・コストの観点で検討すべき点がいくつもあります。
bio.mdが解決しようとしている問題
まず前提を整理します。LLMのAPI呼び出しは基本的にステートレス（状態を保持しない）です。
会話を継続させるには、毎回の呼び出し時に過去の文脈をプロンプトとして渡し直す必要があります。これをコンテキスト注入と呼びます。
多くのエージェントハーネスは、この文脈情報を人格設定ファイル・スキル定義・長期記憶DB・セッションログなど複数の場所に分割して保存しています。bio.mdはこれを1本化し、SOUL（人格と行動制約）・SKILLS（再利用可能な能力）・MEMORY（長期記憶）・CONTEXT（実行時状態）・SESSION TREE（会話分岐の履歴）という5つのセクションを持つ単一ファイルにまとめます。
運用上の推奨構成は次の形です。
~/.my-agent-harness/
├── bio.md
└── data/
├── logs/heartbeat.log
├── skills/
├── sessions/
├── memory_index/
└── context/ハートビートと自動統合の仕組み
ユーザーとの1回のやり取りを「ハートビート」と呼び、heartbeat.logに追記します。
このログは生ログなので、放置すると肥大化します。そこでmemory-sync.shのようなスクリプトをcronで定期実行し、小型ローカルモデル（例としてqwen2.5:0.5bのような0.5Bパラメータ規模のモデル）に要約させ、MEMORYセクションに統合してから生ログを刈り込む運用が提案されています。
この「要約してから元ログを間引く」流れは、Prometheusのレコーディングルールでメトリクスを事前集計し、生の時系列データの保持期間を短く設定する運用と似た発想です。生データを無限に残すとストレージコストが線形に増えるため、集計済みデータに寄せてコストを抑える考え方は、オブザーバビリティ基盤の設計で既に馴染みのある手法です。
bio.md全体、またはその主要セクションは、Ollama（ローカルでLLMを動かすランタイム）への呼び出しのたびにsystemロールのメッセージとして注入されます。
BIO_CONTENT=$(cat bio.md)
curl -s http://localhost:11434/api/chat -d "{
\"model\": \"qwen2.5:0.5b\",
\"messages\": [
{\"role\": \"system\", \"content\": $(jq -Rs . <<< \"$BIO_CONTENT\")},
{\"role\": \"user\", \"content\": \"Your user message here\"}
]
}"毎ターンでファイル全体を読み直す設計のため、ファイルサイズが肥大化するとプロンプトの長さとレイテンシ（応答までの遅延）に直結します。SREの視点では、ここが最初に監視すべきポイントになります。
可用性設計から見た論点
bio.mdは単一ファイルという設計ゆえのシンプルさが利点ですが、同時に単一障害点（SPOF）にもなり得ます。
複数プロセスやcronジョブが同じファイルに同時書き込みする状況を想定すると、ファイルロックの仕組みがないと内容が壊れるリスクがあります。公開情報では「全文書き換えより差分編集を優先する」という指針が示されていますが、具体的な排他制御の実装方法までは定義されていません。
本番導入を検討するなら、以下を自分たちの責任で設計する必要があります。
- 書き込み時のファイルロック（flockなど）の有無
- 破損時のリストア手順（バックアップの頻度とリテンション）
- ハートビートログとMEMORY統合処理が失敗した場合のアラート経路
- bio.md自体をGitなどのバージョン管理下に置き、差分を追跡できるようにするか
これはTerraformやPulumiといったIaC（Infrastructure as Code、インフラ構成をコードで管理する手法）ツールの状態ファイル（tfstateなど）が抱える課題と構造が似ています。
tfstateもリモートバックエンドでのロックと差分管理が運用の要になっているので、同じ発想をbio.mdの運用にも持ち込むと設計しやすくなります。
オブザーバビリティとコストの観点
bio.mdはすべての処理をオフライン・サンドボックス内で完結させる前提で設計されています。クラウドAPIのようなリクエスト課金は発生しませんが、代わりにローカルの計算資源（CPU/メモリ、場合によってはGPU）を消費します。
qwen2.5:0.5bのような小型モデルを使う設計自体が、計算コストを抑える工夫と読めます。ただし要約処理を毎時cronで走らせる場合、ホストのCPU使用率やメモリ使用量をiotopやhtopで定点観測し、他のワークロードと競合していないか確認しておくと安心です。
監視の観点では、bio.mdの運用に最低限次のメトリクスを押さえておくことを勧めます。
| 観測項目 | 確認方法の例 | なぜ見るか |
|---|---|---|
| bio.mdのファイルサイズ | cronでwc -cを定期記録 | プロンプト長増加によるレイテンシ悪化を検知 |
| heartbeat.logの増加速度 | logrotateの対象に追加し監視 | 要約処理が止まっていないかの確認 |
| memory-sync.shの実行結果 | cronログまたはsystemdタイマーの終了コード | 要約失敗による記憶の欠落を防ぐ |
今日確認できること
導入を検討するなら、まず自分の環境で次を確認してみてください。
- Ollamaのバージョンと
/api/chatのsystemロール仕様が、利用中のモデルで想定通り動くか - bio.mdのファイルサイズ上限をどこに設定するか（トークン数換算での試算が必要です）
- cronまたはsystemdタイマーで要約処理を回す場合、失敗時の通知先（Slack webhookなど）を用意できるか
- 既存の監視基盤（Prometheus/Grafanaなど）にログサイズやジョブ成功率を取り込めるか
これらはいずれも公式の実装詳細としては明示されていない部分なので、導入前に自前で設計・検証する前提で臨むのが安全です。
まとめ
bio.mdは、散らばりがちなエージェント状態を1ファイルに集約するという発想自体は明快です。
ただし単一ファイル運用である以上、排他制御・バックアップ・肥大化対策は利用者側で設計する必要があります。IaCのstateファイル管理で培われた知見がそのまま応用できる場面が多いので、tfstateのロック設計やバックアップ運用と並べて考えると導入判断がしやすくなります。
まずはls -la bio.mdでファイルサイズの推移を1週間ほど記録し、heartbeatの頻度とプロンプト長の相関を確認するところから始めてみてください。