ワーキングステート（Working State）

各AI社員が持つ、ウェイクアップをまたいで有効な唯一権威の現行ルールと約束の記録。毎回自動で注入され、変更は監査可能な専用ツール経由のみ。

問題：1日に3本の損切りライン

常駐するAI社員は「会話」だけの存在ではありません。定期巡回、ハートビート、ゴールループ、9つのチャネルからのメッセージ——ウェイクアップのたびに完全に新しい呼び出しが走り、互いに会話履歴を共有しません。ここに実際のインシデント級の問題が生まれます：社員が自分で定めた運用ルールを、次のウェイクアップでは忘れているか、別のノートにある別バージョンを読んでしまう。

自律投資実験の3日目、トレーディング担当の社員が1日のうちに互いに矛盾する3本の損切りラインを書き残しました：

09:04 寄り付き前の戦略：262（「割り込んだら迷わず退出」）
場中の十数回の巡回：254（「戦略文書の -5%」）
引け後のレビュー：257（「明日割り込んだら非を認める」）

当日の安値は261——最初のルールに従えばとっくに退出しているはずでしたが、後続のウェイクアップはそのラインの存在自体を覚えていませんでした。根本原因はモデルの「規律の緩み」ではなく、アーキテクチャの欠陥です：ルールはその時たまたま読んだノートの中にしか存在せず、ノート（日誌、戦略文書）は本質的に追記型の記録なので、同じ事柄について矛盾するN件の記録が並存できます。研究文献はこの症状を ゴーストメモリ（ghost memory） と呼びます：古い事実と現行の事実が並存し、検索時に混ざり合う状態です。

仕組み

各AI社員は「ワーキングステート」を1つ持ちます：キーバリュー形式の現行ルールと約束（例：stop_loss.2317 = 262）に、1本の「引き継ぎメモ」を加えたものです。ゲートウェイは毎回のウェイクアップでこれをプロンプト末尾に自動注入し、唯一権威の「現行値」であることを明示します。どの項目であれ変更するには、社員は専用ツールを理由付きで呼び出す必要があり、旧値は監査可能な置換チェーンに入ります。ステートを一度も設定していない社員は注入ゼロ・コストゼロです。

注入される内容

ウェイクアップのたびに、社員のプロンプト末尾へ次のセクションが追加されます（自動——社員がファイルを読む必要はありません）：

## 工作狀態（唯一權威 · 由你自己以 working_state_set 維護）
以下鍵值是你跨喚醒持續有效的工作狀態與承諾，為唯一權威的「現行值」；
筆記、日誌、策略文件裡與此矛盾的數字一律是歷史值（已作廢），不得採用。……
- stop_loss.2317 = 262（08-13 09:04 設；理由：跌破即出場不猶豫；有效至 08-13 13:30）
- position_cap = 96%（08-12 08:42 設；理由：留最低手續費緩衝）
交接註記（08-13 09:36 留）：盤中每 3 分巡檢中；帳務已核對。

このセクションはプラットフォームの運用言語であるzh-TW（繁体字中国語）で描画されます。内容は：以下のキーバリューはウェイクアップをまたいで有効な唯一権威の「現行値」であり、ノート・日誌・戦略文書の中でこれと矛盾する数値はすべて廃止済みの履歴値として扱い、採用してはならない——という宣言です。各エントリには値、設定時刻、理由、（あれば）有効期限が付き、最終行が引き継ぎメモです。

ツール（MCP、5種のランタイム共通）

ツール	用途
`working_state_set`	キーを1つ設定/更新（`reason` 必須；オプション `ttl_hours` で当日限りのルールを自動失効；オプション `expected_value` で並行保護——現行値と一致しなければ書き込みを拒否し、現行値を返す）
`working_state_clear`	キーを1つ廃止（`reason` 必須）
`working_state_handoff`	「引き継ぎメモ」を上書き——次のウェイクアップの自分が知るべきこと（プレーンテキスト、または下記「構造化引き継ぎ」）
`working_state_get`	全量を読む：全キー（失効済みも印付きで含む）、引き継ぎメモ、直近の置換履歴

設計のポイント

明示的なツール呼び出しのみ受け付ける——社員の返信テキストから「ルールらしき文」を自動抽出することは決してしません（自己申告は信頼できないため）。すべての変更は監査ログと置換チェーンに記録され、損切りラインを変更したという行為自体も、次のラウンドの「直近の自身の行動」セクションに現れます。
並行保護（CAS）：同時に走る2つのウェイクアップ（例：3分ごとの定期巡回）が互いを上書きしてはいけません——expected_value を付ければ、他のウェイクアップが既に変更していた場合は拒否されます。
TTL：場中の損切りラインのような「当日限りのルール」には ttl_hours を設定します。翌日にはもう権威ではありません（ファイルには残り参照できますが、注入されなくなります）。
上限で収束を強制：最大32キー。上限に達すると新規追加は拒否され、既存キーの一覧が返されます——ステート表が第二のノートの山に膨れ上がっては意味がないからです。
コスト：注入はプロンプトキャッシュ階層の後ろの動的テールに置かれ、キャッシュ済みプレフィックスを壊しません。セクション上限は3KB。空のステートなら注入ゼロです。

構造化引き継ぎ（Ralph式・オプション）

プレーンテキストの引き継ぎ（note のみを渡す）は従来どおりです：空白は静かに折りたたまれ、約1200文字を超えた分は静かに切り詰められます。

より堅い引き継ぎには、working_state_handoff に4つのフィールドを追加できます——status（continue／complete／blocked）＋next_steps／evidence／blocker。いずれか1つでも付けた場合は status が必須になり、status に応じて次の表のとおり強制検証されます。違反すれば呼び出し全体が拒否されます：

status	要件
`continue`	`next_steps` 必須・非空；`blocker` 不可
`complete`	`evidence` 必須・非空；`blocker` と `next_steps` 不可
`blocked`	`blocker` 必須・非空

背景にある考え方：「完了」は自己申告であってはならない——具体的な証拠なしに complete は名乗れません。進行中の引き継ぎに次の一手がなければ、次のウェイクアップの自分は白紙同然です。

超過分は丸ごと拒否、切り詰めは決してしない：note＋next_steps＋evidence＋blocker の合計バイト数（CJKセーフな計算）が config.toml [memory] working_state_handoff_max_bytes（デフォルト16384）を超えると、そのままエラーを返し、引き継ぎは一切書き込まれません。これはプレーンテキストモードの「静かな切り詰め」とは意図的に異なります——構造化引き継ぎが切り詰められると、引き継ぎを信頼可能にしている証拠や次の一手がちょうど削られたのに、なお完全で信頼できる引き継ぎに見えてしまう。それは端的な拒否より危険だからです。

status を付けた場合、次のウェイクアップに注入されるブロックにもこれらのフィールドが載ります：

交接註記（08-13 09:36 留）：盤中每 3 分巡檢中；帳務已核對。（狀態=continue；下一步：核對完後回報總額；證據：帳務表已比對三次）

上限は調整可能です——下記「設定」の working_state_handoff_max_bytes を参照してください。

他メカニズムとの分担

メカニズム	答える問い
ワーキングステート（本機能）	今コミットしている有効なルールは何か？
直近の自身の行動（監査フィード）	何をやったか（ブロックされたものを含む）？
ゴールタスクの `<state>` ブロック	このタスクはどこまで進んだか？
メモリ／経験則	何を学んだか？
共有Wiki	チーム共通のSOP／参照文書

設定

config.toml：

[memory]
working_state_enabled = true             # デフォルトON。「注入」だけを止める。ツールとファイルは影響を受けない
working_state_handoff_max_bytes = 16384  # 構造化引き継ぎ（上記参照）の合計バイト上限。CJKセーフな計算。プレーンテキスト引き継ぎは対象外

ステートファイルは <エージェントディレクトリ>/state/working_state.json、置換履歴は同ディレクトリの working_state_history.jsonl にあります。どちらも人間が読めるファイルです——問題が起きたら直接開いて確認できます。

社員向けの利用慣例（社員のCLAUDE.mdに書くことを推奨）

意思決定パラメータ（損切り／利確／ポジション上限／現在のフェーズ）は決めたその場で working_state_set。当日限りのルールには ttl_hours を付ける。
巡回時は注入されたワーキングステートのセクションを正とし、その場で再計算して別の値を立てることは禁止。
作業を締める前には毎回 working_state_handoff で引き継ぎを残す——コンテキストはいつでも終わり得るし、書き戻していない決定は無かったのと同じ。

まとめ

常駐する社員には「現行ルール」が住む唯一の場所が必要で、その場所は散文であってはいけません。ワーキングステートは各社員に唯一権威のステート表を与えます：毎回のウェイクアップに自動注入され、変更は監査可能なツール経由のみ、旧値は置換チェーンへ退場して現行値と争いません。ノートは履歴として引き続き有用です——ただ、権威の座を争わなくなるだけです。