外部記憶を一つのファイルへまとめない
前の記事では、GitHubを外部記憶の正本として扱い、ハルAリーグで役割、判定、評価、記録、試合間比較を分けている仕組みを整理しました。 その運用を新しいチャットへ引き継ぐには、採用済みの役割だけでなく、長期的に使う知識、現在の課題、過去の観測事実も残す必要があります。
ただし、それらを一つの長いファイルへまとめると、現在の行動指示と過去の記録を区別しにくくなります。 一試合だけで起きた失敗が恒久的な弱点として読まれたり、解決済みの課題が現在も有効な指示として残ったり、必要のない過去記録まで毎回取得したりする可能性があります。
そこで、ハルAリーグの外部記憶では、情報の意味に応じて主に五つの保存先へ分けています。
ROLE.md
担当の職務、責任、制約
MEMORY.md
安定して再利用する長期知識
LEARNING_LOG.md
未確定の観測と学習履歴
CURRENT_STATE.md
現在地、継続課題、次の重点
試合記録
その試合で確認できた事実と結果この分離は、すべての情報を同じ重要度で保存するためのものではありません。 どの情報を現在仕様として扱うか、どの情報を必要な場合だけ参照するかを分けるための構成です。
ROLE.mdに担当の役割を保存する
ROLE.mdには、その担当が何を行い、何を決定し、どの範囲を担当しないかを保存します。
ハルAリーグでは、選手、審判、評価者、記録担当、試合間比較を行う担当を分けているため、誰がどの判断に責任を持つかが現在の実行へ直接影響します。
たとえば、審判は試合の進行、終了、勝敗判定を担当し、記録担当は試合内で確認できた事実を残します。 記録担当が独自に勝敗を変更したり、単独で長期記憶への反映を決めたりしないことも、役割の一部です。 このような職務、権限、制約、他担当との関係を、個別試合の結果とは分けて保持します。
試合で一度失敗したことや、次回だけ意識する課題は、役割そのものの変更ではありません。
責務や権限が変わった場合にだけROLE.mdを更新し、能力改善や一時的な課題を無制限に追加しない構成にしています。
新しいチャットでは、今回参加する担当のROLE.mdだけを標準的に取得します。
参加しない担当の内部情報まで無条件に読み込ませず、現在必要な責務へ入力を絞ります。
MEMORY.mdに長期知識を保存する
MEMORY.mdには、複数の検証を通して安定して利用できる、役割固有の長期知識を保存します。
ROLE.mdが「何を担当するか」を定めるのに対し、MEMORY.mdは「その担当が将来も利用する判断や行動の原則」を保持する場所です。
保存対象には、繰り返し利用する判断基準、複数の試合で確認された課題、維持する価値がある行動原則などがあります。 一方で、一度の勝敗、特定の論題だけで使えた回答、根拠のない性格付けは、長期知識として扱いません。
MEMORY.mdも、今回参加する担当のものだけを標準的に取得します。
役割ごとの記憶領域を分けることで、ある担当の課題を別の担当への行動指示として混在させずに済みます。
長期知識として保存されていることは、次の出力で必ず正しく実行できることを意味しません。 保存できたこと、取得できたこと、実際の行動へ反映できたことは別の確認項目として扱っています。
LEARNING_LOG.mdに未確定の観測を残す
LEARNING_LOG.mdは、一度だけ確認された失敗や成功、再現性がまだ分からない傾向、今後確認したい仮説を時系列で残す場所です。
該当する試合記録を参照元として残し、どの観測から学習候補が生まれたかを後から確認できるようにします。
ここに書かれた内容は、現在の役割仕様や確定した能力として扱いません。 一試合で修正が必要だったことを、その担当が常に失敗する性質として固定せず、別の試合でも再現するかを確認できる状態で保留します。
LEARNING_LOG.mdは、新しいチャットで毎回読む標準入力には含めていません。
現在課題が生まれた経緯を追う場合、過去の観測と今回の行動を比較する場合、学習状態を再確認する場合など、履歴が必要なときだけ参照します。
未確定情報を保存しながら、通常の実行入力からは外しておくことで、過去の仮説が現在の指示へ無条件に混ざることを抑えています。 どの条件で長期記憶へ移すかという判断は、後続の記事で別に扱います。
CURRENT_STATE.mdに現在地を保存する
CURRENT_STATE.mdには、現在の運用状態、継続中の課題、次に確認する内容を保存します。
長期的に残す知識ではなく、新しいチャットで「今どこにいて、次に何をするか」を復元するための情報です。
ハルAリーグでは、リーグ全体のCURRENT_STATE.mdと、担当ごとのCURRENT_STATE.mdを分けています。
全体側には現在の運用モード、完了・未完了の状態、次の進行条件を残し、担当側には現在の重点課題、課題が発動する条件、次回に実行する行動を残します。
2026年8月4日時点では、終了条件を満たさないまま判定へ進んだ試験を完了扱いにせず、再開可能な未完了状態として保持していました。 試合記録だけでなく全体の現在状態にも反映することで、新しいチャットが未完了の工程を完了済みと推測することを防いでいます。
現在の課題が解決した場合は、その項目を削除または置換できます。 履歴をすべて残す場所ではなく、現在有効な状態を更新し続ける場所として使います。
試合記録に確認できた事実を残す
試合記録には、その試合で実際に起きた発言、確認、判定、評価、試合後の記録を保存します。 五つの保存先の中では最も具体的で、試合の論題や当時の運用仕様に強く依存する情報です。
現在は、過去の参照事例、AI同士で行う試験、ハル本人が参加する実戦を分けて保存しています。 また、「確定記録」はGitHubへ反映し、再取得確認を終えた記録状態を表し、試験や実戦とは別の区分です。
試合記録は、後から判断の根拠を確認するために必要ですが、その全文を毎回読み込む運用にはしていません。 現在の課題がどの試合から続いているか、変更前後で同じ問題が再現したかなど、今回の確認に必要な直近記録だけを取得します。
個別記録を現在仕様と分けておくことで、当時の事実を残したまま、次の試合には最新の役割とルールを適用できます。 過去の記録を無言で現在仕様へ書き換えず、変更前後を比較するための根拠として保持します。
標準取得と条件付き取得を分ける
保存先を分けても、毎回すべてを取得すれば入力は再び大きくなり、過去の仮説と現在の指示が混在します。 そのため、新しいチャットで現在状態を再構築するときは、標準的に取得する情報と、必要な場合だけ取得する情報を分けています。
- 標準取得：リーグ全体の入口、現在状態、必要な共通仕様、今回参加する担当の役割仕様・長期記憶・現在課題
- 条件付き取得：学習経緯を確認するための学習ログ、前回課題の参照元となる直近記録、変更理由の確認に必要な過去記録
- 標準入力にしないもの：過去の全チャット履歴、すべての試合記録、参加しない担当の内部学習ログ
たとえば、準備時には今回参加する担当のROLE.md、MEMORY.md、CURRENT_STATE.mdを取得します。
現在課題の参照元を確認する必要がある場合だけ、対応する学習履歴や直近記録まで範囲を広げます。
この考え方は、過去を忘れるためではありません。 現在の判断に必要な情報を優先し、詳細な履歴は根拠をたどるときに取得することで、正本と証跡の両方を残すためのものです。 実際の読み込み順や、取得中に状態が変わらないよう固定する方法は、次の記事で整理します。
保存先を分けて確認できたこと
2026年8月4日時点の外部記憶では、役割仕様、長期記憶、学習履歴、現在状態、試合記録を分けたまま、新しいチャットで現在の運用状態を再構築できることを確認しました。 過去の全チャットや全試合記録を読み直さなくても、現在の正本と必要な参照記録から次の工程を特定できています。
また、2026年8月25日に本文準備で使用する資料を再確認したところ、2026年8月4日の基準時点から対象となるファイルの内容は変わっていませんでした。 第2記事と同じ基準状態を使い、保存先の役割と取得条件を分けて説明できる状態です。
一方で、情報を分けて保存しただけでは、自動的に正しい情報だけが選ばれるわけではありません。 取得する範囲を決め、同じ実行中に参照する状態を固定し、取得した内容を実際の行動へ反映できたかを別に確認する必要があります。
この検証で確認できたのは、外部記憶を一つの長文へ集約するのではなく、情報の役割と取得条件を分けることで、現在仕様と履歴を混同せずに引き継げる範囲です。 次の記事では、この保存構造から新しいチャットを再構築し、準備から反映まで同じ状態を維持する方法を整理します。
