新しいチャットをGitHub正本から再構築する
前の記事では、GitHub上の情報を役割仕様、長期記憶、学習履歴、現在状態、試合記録へ分け、必要な範囲だけを取得する構成を整理しました。 今回は、その保存構造から新しいチャットへ現在の運用状態を再構築し、準備から反映まで同じ状態を使う方法を扱います。
新しいチャットには、前のチャットで確定した役割や、途中まで進んだ工程が自動的に含まれるわけではありません。 過去のチャット履歴だけを頼りにすると、採用済みの仕様と検討中の案、完了した工程と未完了の工程を区別しにくくなります。
そこでハルAリーグでは、チャットを議論と実行の場、GitHubを採用済み仕様と確認済み記録の正本として分けています。 新しいチャットを始めるときは、会話の続きを推測するのではなく、GitHub上の入口と現在状態から必要な情報を取得し直します。
ここでいう再構築は、過去の会話をすべて再現することではありません。 現在有効な役割、共通仕様、継続課題、次に実行できる工程を特定し、同じ条件で運用を再開できる状態を作ることです。
必要な情報を順番に取得する
新しいチャットでは、最初から個別の試合記録を探すのではなく、正本の入口から現在状態へ進み、共通仕様と参加担当を確認した後、必要な直近記録だけへ範囲を広げます。
正本の入口
目的と現在の運用範囲
↓
全体の現在状態
未完了の工程と次の重点
↓
共通仕様
全担当へ適用するルール
↓
参加担当
役割、長期知識、現在課題
↓
必要な直近記録
継続課題の参照元だけ正本の入口では、このリポジトリが何を管理し、どのファイルを現在仕様として扱うかを確認します。 次に全体の現在状態を読み、反映済みで待機しているのか、未完了の試合や未反映の工程が残っているのかを特定します。
その後、全担当へ共通する仕様とルールを確認し、今回参加する担当の役割仕様、長期知識、現在課題だけを取得します。 直近記録は、継続課題の根拠や変更経緯を確認する必要がある場合に限り、対応する記録だけを読みます。
過去の全チャット履歴、すべての試合記録、参加しない担当の内部情報は標準入力にしません。 読み込む量を減らすことだけが目的ではなく、過去の観測や未確定情報を現在の行動指示へ無条件に混ぜないための順序です。
使用する状態をコミットSHAで固定する
GitHubの正本は継続的に更新されます。 準備時には同じ内容だったとしても、試合中に参照先のブランチが更新されれば、担当ごとに異なる時点の役割やルールを使う可能性があります。
そのため、試合前の準備で使用するコミットSHAを一つに固定します。 コミットSHAは、その時点のファイル構成と内容を示す識別子です。 開始済みの試合では同じSHAを参照し続け、準備後に追加された変更を途中から混在させません。
固定する利点は、どの状態を使って出力したかを後から確認できることです。 一方で、準備後に正本へ重要な修正が追加されても、その試合には自動で反映されません。 試合開始前なら準備をやり直し、開始後なら固定した条件を維持して、次の準備から新しい状態を使用します。
最新状態を常に混ぜることより、開始済みの一つの試合で同じ条件を保つことを優先する設計です。 これにより、結果の違いが役割やルールの途中変更によるものか、実際の応答によるものかを分けて確認しやすくなります。
AI同士と対話式実戦で取得方法を分ける
固定したコミットを使う点は共通ですが、AI同士の一括試合と、ハル本人が参加する対話式実戦では、試合中の取得方法を分けています。
- AI同士の一括試合：準備時に取得した情報だけを使用し、生成中はGitHubから再取得しません。
- ハル本人参加の対話式実戦：各AI担当の発言前に、同じ固定SHAから役割、長期知識、現在課題、適用ルールを必要な範囲だけ再取得します。
- 共通する制御：現在の試合発言はチャットで追い、過去の仕様と役割はGitHubを参照し、試合中はGitHubを書き換えません。
一括試合は、準備と生成を分けることで、試合中の取得待ちを増やさずに同じ入力状態を使えます。 対話式実戦は取得回数が増えますが、複数の発言へ分かれた場合も、各担当が同じ正本状態を参照したことを確認できます。
対話式実戦で必要な情報を取得できなかった場合は、内部記憶で補って発言を続けません。 取得できないことを報告して停止します。 また、ハル本人が現在のチャットで明示した指示や訂正は優先し、試合後に正本へ反映する候補として分けて扱います。
準備から反映までを四段階に分ける
外部記憶から情報を取得できても、試合生成とGitHub更新を同じ工程で行うと、途中の出力がいつ正式記録になったのか分かりにくくなります。 ハルAリーグでは、準備、試合出力、反映整理、反映開始を別の合図で進め、未反映状態と反映済み状態を分けています。
反映済み・待機
↓ 「チャッピー、準備して」
準備済み
↓ 「審判、お願いします」
試合出力済み・未整理
↓ 「反映整理」
反映整理済み・未反映
↓ 「反映開始」
反映済み・待機- 準備：GitHub正本と参加担当を取得し、使用するコミットSHAを固定します。論題決定、試合開始、GitHub更新は行いません。
- 試合出力：準備済みの状態から試合と試合後工程を進めます。記録ファイル、学習履歴、現在状態は更新しません。
- 反映整理：確定記録へ残す事実、学習履歴と現在状態の候補、反映しない項目を分けます。この段階でもGitHubは更新しません。
- 反映開始：整理済みの対象だけをGitHubへ反映し、更新後のファイルを再取得して保存内容を確認します。
試合を出力した時点では、結果がチャットに存在していても、GitHub正本へ保存された確定記録ではありません。 反映対象を整理し、実際に書き込み、再取得で確認できた時点で「反映済み・待機」へ戻ります。
前段階が終わるまで次へ進まない
四段階は表示上の区切りだけではありません。 現在の状態に合わない合図を受けた場合は、足りない工程を推測で飛ばさず、次の条件で停止します。
- 準備が完了していない場合は、試合を開始しません。
- 反映整理が完了していない場合は、GitHubへの反映を開始しません。
- 前の試合が未反映の場合は、破棄が明示されない限り次の試合を準備しません。
- 試合後工程に未完了の担当がある場合は、反映整理より先に欠けている工程を完了します。
- 対話式実戦で固定SHAからの取得に失敗した場合は、内部記憶で代用せず停止します。
この制御には、確認する工程が増えるという負担があります。 その代わり、未整理の出力を確定記録として扱ったり、保存されていない試合を完了済みと推測したりすることを抑えられます。
停止後に同じ状態から復旧する
停止条件を設ける目的は、処理を中止したままにすることではありません。 どの状態まで完了したかを保ち、再開に必要な情報が揃った時点で、同じ条件から続けられるようにすることです。
- 準備後にGitHubが更新された場合：開始済みの試合は固定SHAを維持し、開始前なら新しい状態で準備をやり直します。
- 対話式実戦が中断した場合：同じチャット内に状態が保持されていれば、現在の工程位置から未完了の発言や試合後工程を順に再開します。
- 取得に失敗した場合：固定SHAの必要情報を再取得できるまで停止し、取得後に止まった工程から再開します。
- 試合出力後、反映前にチャット状態を失った場合：その試合はGitHub正本に存在しません。保持している出力を再提示して復旧するか、破棄を明示します。
固定SHAから復元できるのは、準備時点でGitHubに保存されていた仕様と状態です。 反映前の試合出力や、チャット内だけの訂正までは自動で復元できません。 正本へ保存済みの状態と、チャット上にだけ存在する一時状態を分けることで、復旧できる範囲を誤認しないようにしています。
状態を固定して確認できたこと
2026年7月17日の外部記憶再構築試験第1回では、新しいチャットでGitHub上の役割と運用手順を取得し、進行、判定、評価、記録まで一試合の工程を完了しました。 この試験で確認できたのは、過去のチャットをすべて読み直さなくても、正本から必要な担当と手順を再構築できる範囲です。
その後は、準備時のコミットSHAを固定し、試合中の生成とGitHub反映を分ける運用へ更新しました。 2026年8月27日に本文の基準資料を再確認した時点でも、基準日から中核となる五つのファイルの内容は変わっておらず、同じ状態を根拠として読み込み順と四段階を整理できました。
また、準備済み、試合出力済み・未整理、反映整理済み・未反映、反映済みという状態を分けることで、チャットに出力された内容とGitHubへ保存された内容を同じものとして扱わずに済みます。 反映後の再取得までを一つの工程にすることで、書き込み操作の成功だけでなく、正本へ保存された内容を確認できます。
一方で、正しいコミットから情報を取得できたことは、その内容を必ず正しく解釈し、実行できることを意味しません。 固定SHAは途中の状態混在を防ぎますが、準備後の変更や反映前に失われたチャット内容を自動で補うものでもありません。
この検証で確認できたのは、GitHubを正本として取得順と使用状態を固定し、実行と反映を分けることで、新しいチャットでも確認可能な状態から運用を再開できる範囲です。 保存、取得、解釈、実行、反映は別の検証項目として扱い、成立した範囲と残る制約を分けて確認していきます。
