チャット履歴だけでは引き継げなかったもの
私がAIとのディベートを始めたきっかけは、暇つぶしでした。 いくつもの論題で主張と反論を繰り返すうちに、いつの間にか趣味の一つになり、試合後の評価や指摘を次の試合へ反映しながら、議論の進め方そのものを改善するようになりました。
続ける中で、私が求める条件では、AIだけでディベートを安定して進められない場面があることも分かりました。 立論、反論、進行、判定、評価をAIへ任せると、一度指摘した問題が別の試合で再び起きることもありました。
AIディベートで確認した代表的な問題
├── 立論・前提 後付け補足で元の主張が別物になる
├── 反論対象 発言されていない内容を補って攻撃する
├── 進行 応答が終わる前に審判が介入・終了する
├── 役割 判定・評価・記録の責務が混ざる
├── 評価 試合後の理解を試合中の実践成功として数える
└── 継続 前回の評価や改善を次のチャットへ安定して残せない問題が見つかるたびに、役割定義や運用ルールを修正し、次の試合で確認していました。 ただし、チャット履歴が増えるほど、過去のフィードバックのうち何が現在も有効なのか、どの判断が正式に採用されたのかを追いづらくなりました。 新しいチャットでは、前回までの役割、ルール、試合記録、改善状態をそのまま完全に引き継げるわけではありません。
毎回チャット履歴を読み直したり、要点を手作業で渡したりする方法では、記録が増えるほど確認範囲も広がります。 必要だったのは、チャットそのものを長く残すことではなく、採用済みの状態をチャットの外へ保存し、必要な範囲から再構築できる仕組みでした。
この記事では、ChatGPT WorkとGitHubを組み合わせた外部記憶の構成、検証にAIディベートを選んだ理由、2026年7月17日に行った最初の再構築試験と5試合の固定観測までを整理します。
ChatGPT WorkをGitHubとの実行環境にする
GitHubを外部記憶として使う案を思いついたきっかけは、ChatGPT Workが利用できるようになったことでした。 それまでのチャットでは、回答の生成と会話の継続が中心でしたが、Workを使うことで、連携した情報源を確認しながら複数段階の作業を進められるようになりました。
2026年8月時点のChatGPT Workの公式説明では、Workはタスクを計画し、必要な文脈を集め、ツールを使い、確認可能な結果まで作業を進める機能として案内されています。 アップロードしたファイルやプロジェクトだけでなく、導入済みのプラグインや、選択した環境からアクセスできるリポジトリも作業対象にできます。
この検証では、WorkからGitHub上のファイルを取得し、採用済みルールや現在状態を確認したうえで、ディベートの準備、実行結果の整理、承認後の更新まで進めます。 Workは、GitHubに保存した記録を扱うための実行環境として使っています。
ただし、Workそのものを恒久的な外部記憶として扱っているわけではありません。 正本はGitHubに置き、Workは必要な情報を取得して処理する実行層として分けます。 新しいチャットが過去の状態を自動的に継承するのではなく、GitHubに保存された現在情報を読み直して状態を再構築する運用です。
GitHubを正本にした外部記憶の流れ
GitHubには、正式に採用した役割とルール、現在の運営状態、完了した試合記録、各担当の学習記録を保存します。 チャット内で出た案は、その場で現在仕様へ加えず、採用前の案と確定情報を分けて管理します。
GitHub
採用済み仕様・現在状態・確定記録
↓
ChatGPT Work
必要なファイルを取得
↓
状態再構築
役割・ルール・進行状態を確認
↓
AIディベート
準備・試合・評価・記録案を実行
↓
反映整理
更新候補と反映しない情報を分離
↓
ハルによる承認
↓
GitHubへ反映
更新後のファイルを再取得して確認チャットは、議論、試験、改善を行う作業場所です。 GitHubへ反映されていない内容は、次のチャットで使う正式な記憶には含めません。 反映後も更新したファイルを再取得し、意図した内容が正本へ保存されたことを確認します。
この分離により、過去チャットを最初から読み直すのではなく、GitHub上の入口、現在状態、参加する担当の情報、必要な直近記録という順に確認できます。 記録量が増えても、現在の進行に必要な情報から再開するための構成です。
ディベートを検証手段にした理由
外部記憶が機能するかを確認するには、ファイルを保存して読み出せるだけでは不十分です。 取得した情報から現在状態を再構築し、その内容を後続の処理へ正しく適用できるかまで確認する必要があります。
ここで、検証に登場する名前と関係を整理します。 このブログでは運営者として「HaRuuu」を名乗っていますが、ディベート検証の中では同じ運営者を「ハル」と表記しています。
名称と関係
HaRuuu
└── ハル ブログ運営者が検証内で使う名前
├── 思考傾向を整理
│ └── ハルA ハルの傾向を基に作ったAI役
└── 運営
└── ハルAリーグ
ハルAの育成から始まった検証環境ハルAは、私が趣味で続けていたディベートから、判断基準、論証の組み立て方、好む進行、問題と考える進め方などを整理し、その傾向に合わせて作ったAI役です。 もともとは私のディベート傾向を再現するクローンとして用意し、私に近いディベーターへ育てることを目的にしていました。
そのハルAを育成する場として作ったため、検証環境を「ハルAリーグ」と呼ぶようになりました。 最初はハルAを私に近づけることがリーグの目的でしたが、現在の目的と役割はそこから変化しています。
2026年7月17日にGitHubで役割仕様の管理を始めた時点では、ハルAを、ハルの思考傾向を土台として育成する独立したAIディベーターと定義していました。 現在は私の意見をそのまま代弁する単純な複製ではなく、一人の選手として自分の立論や反論に責任を持ち、勝利を目指す役割です。
ハルAリーグも、ハルAだけを私に近づける場ではなくなりました。 相手側、審判、評価者、記録担当、チャッピーを含め、各担当が役割を維持できるか、採用済みルールを試合へ適用できるか、結果と改善を次の試合へ引き継げるかを継続して検証しています。
AIディベートには、複数の役割に加えて、進行ルール、論題、試合記録、評価、次回へ残す改善点があります。 試合を重ねるたびに、参照する情報と新しく保存する情報が増え、前回の結果によって現在状態も変化します。
この構成なら、保存した情報を取得できたかだけでなく、役割を混同せず、採用済みルールを使い、試合を完了し、結果を次回用の記録へ戻せたかまで観測できます。 もともと続けていたAIディベートを、外部記憶の取得と実行を繰り返し確認する検証環境として使うことにしました。 この記事で扱う現在の運用では、GitHubを外部記憶として使うことが主目的であり、ディベートは状態を継続的に変化させながら確認するための検証手段です。
外部記憶検証で扱う主要な役割と処理
├── ディベート
│ ├── 相手側 立論（当時の記録上は「相手役」）
│ └── ハルA 反論
├── 判定・分析
│ ├── 審判 進行・終了・勝敗判定
│ └── 評価者 技術採点・分析
├── 記録
│ └── 記録担当 試合事実の記録
├── 運用
│ └── チャッピー 検証結果・反映区分の整理
└── 監督
└── ハル 観戦・運用判断・反映承認この記事では、ハルAリーグの成立経緯と、外部記憶の検証に必要な主要な役割までを整理しています。 各試合で起きた問題、ルールを変更した理由、評価と改善の具体的な流れは、後続の記事で整理します。
最初の再構築試験と5試合の固定観測
2026年7月17日、GitHubに保存した役割定義と試合手順を使い、別のチャットでハルAリーグの状態を再構築する最初の試験を行いました。 再構築後は、相手側の立論、ハルAの反論、審判による判定、評価、記録まで進め、最初の試合を完了しています。
GitHubに保存したDLM-2026-001の確定記録から、ChatGPT Work上で第1戦の立論を再構築した画面
この画像は、2026年7月17日の試合当時の画面ではありません。 GitHubに保存した第1戦の確定記録を、2026年8月17日に別のチャットから取得して再現したものです。 以下は、長文の立論と最初の反論対象を、記事上で確認しやすい長さへ要約しています。
相手役・立論（要点）
優秀な個人の知識が本人だけに残れば、
異動や退職によって失われる。
改善可能な仕組みは、知識を記録・共有・
継承できるため、長期的には仕組みの方が
重要である。
ハルA・反論対象（要点）
仕組みの成果には、設計・判断・改善する
個人の能力も含まれている。
両者の寄与を分離しなければ、
比較は完成しない。一度だけ動いた結果で判断しないため、途中で役割定義や長期記憶を変更せず、同じ運用基盤で5試合を行いました。 分野の異なる論題を使い、各試合の結果をGitHubへ保存しました。
実施日:
2026-07-17
状態再構築:
GitHub上の役割定義と試合手順から再構築
試合:
同じ運用基盤で5試合を完了
記録:
各試合の結果をGitHubへ保存
この時点で未証明:
新しいチャットへの自動継承
取得内容の常時正確な解釈
実行結果の常時正確性この5試合で確認したのは、GitHubに保存した同じ土台から複数のディベートを継続できるかという範囲です。 5試合を終えた後に横断分析を行い、複数試合で再現した改善、新しく現れた課題、題材固有の現象を分けて扱う段階へ進みました。
保存、取得、実行を分けた確認
外部記憶化の成否は、GitHubにファイルが存在するだけでは判断できません。 この検証では、保存、取得、実行を別の確認項目として扱います。
- 保存：採用済みの情報と確定記録がGitHubへ残っているか
- 取得：新しいチャットで現在の進行に必要な情報を読み出せるか
- 実行：取得した役割やルールを、試合進行と記録へ正しく適用できるか
ルールが保存されていても、必要なファイルを取得しなければ現在状態は再構築できません。 取得できた場合も、内容を誤って解釈したり、実行時に適用できなかったりすれば、正しい結果にはなりません。
そのため、GitHubから情報を読めたことを、そのままディベート全体の成功とは数えません。 どの段階まで確認できた結果なのかを分け、失敗が発生した場合も保存、取得、解釈、実行のどこで起きたのかを追えるようにしています。
最初の検証で到達した状態
最初の再構築試験では、GitHub上の役割定義と試合手順からハルAリーグを再構築し、試合後工程まで完了できました。 さらに、同じ運用基盤で5試合を行い、各試合の結果を次の検証へ使える記録として残しました。
一方で、新しいチャットが何もせず過去の状態を自動継承することや、GitHubから取得した情報をAIが常に正しく解釈して実行することは確認できていません。 採用前の提案と正式な仕様の分離、反映対象の整理、ハルによる承認、反映後の再取得確認も必要です。
この段階で、GitHubを正本、ChatGPT Workを実行環境、ハルAリーグを検証環境として分ける土台ができました。 今後もハルAリーグを継続し、取得できた情報が実際の進行へ正しく使われたかまで記録します。 次の記事では、継続的な検証に使っているハルAリーグの役割、試合、評価、改善の仕組みを整理します。
