「何度も言わせるな」を解決する：
ジェンスパーク(Genspark)品質チェックv3.0の履歴蓄積戦略

「ジェンスパーク(Genspark)は嘘をつく」。これまでの開発奮闘記の中で、私たちはAIエージェントが自信満々に誤った情報を提示する「ハルシネーション」のリスクについて触れてきました。しかし、開発プロジェクトが長期化し、チャットの往復回数が増えるにつれて、もう一つの深刻な問題が浮き彫りになってきました。

それは、「ジェンスパーク(Genspark)は忘れる」という問題です。

「前回の指示でタイトルの変更は禁止だと言いましたよね？」「CSSは必ず実装してと何度も言いましたよね？」――このような指摘をAIに対して繰り返した経験はないでしょうか。私たちはこれを「指示忘れ」問題、あるいは開発現場の悲鳴を込めて 「何度も言わせるな」問題 と呼ぶことにしました。

本記事では、この根深い問題に対処するために考案された「会話履歴蓄積型品質チェックワークフロー（v3.0）」の構想と実装、そして記事47-53の公開処理時に直面した 痛恨の失敗事例 について詳述します。さらに、その失敗を乗り越えるために実装されたv4.0の「履歴妥当性チェック機能」についても技術的な詳細を公開します。

1. 導入：記事47-53での「指示忘れ」問題

ジェンスパーク(Genspark)開発奮闘記の記事47から53までの制作過程は、まさにAIとの「根比べ」の様相を呈していました。私たちは「エリック・ジョージ方式」という複数のAI人格を用いた品質チェック体制を確立し、一定の成果を上げていました。しかし、チャットセッションが長くなるにつれて、初期に定義した重要なルールが徐々に無視される現象が頻発しました。

例えば、「ジェンスパーク(Genspark)基本機能完全ガイド：AI検索・リサーチ・コンテンツ作成の9つの武器」の制作時には「タイトルの勝手な変更は禁止」というルールを3回も無視され、そのたびに修正指示を出す必要がありました。また、「ジェンスパーク(Genspark)で学ぶコード生成とコード実行の違い」では「CSSは必須」という基本要件が見落とされ、生成されたHTMLがスタイルなしの素朴な状態で出力される事態も発生しました。

これらは単なるAIの「不注意」ではありません。人間であれば、上司に一度強く叱責されれば記憶に刻まれるような重要な指示であっても、AIエージェントはある一定のコンテキスト長を超えると、まるで初めて聞いたかのように振る舞うのです。この手戻りによる工数増加は無視できないレベルに達していました。

2. 根本原因の分析

なぜ、最新の高性能LLM（Gemini 1.5 ProやGemini 2.0 Flashなど）を搭載しているはずのジェンスパーク(Genspark)で、このような「記憶喪失」が起こるのでしょうか。技術的な調査とAI自身へのヒアリングの結果、以下の構造的な問題が明らかになりました。

ジェンスパーク(Genspark)の直近履歴のみ取得の制限

ジェンスパーク(Genspark)のAIエージェントは、チャット履歴の全てを毎回読み込んでいるわけではありません。システムのリソース最適化とレスポンス速度維持のため、エージェントが参照できるのは「直近の会話履歴」に限られています。これは無料プランに限った話ではなく、高価格な有料プランであっても同様のアーキテクチャ上の制約が存在します。

コンテキストの消失とハルシネーション

チャットが長期化すると、初期に行われた「前提条件の定義」や「禁止事項の指示」が、AIの参照可能なウィンドウの外に押し出されてしまいます。これを専門用語では「コンテキストウィンドウからの脱落」と呼びます。参照できなくなった情報はAIにとって「存在しない」ものと同義であり、結果としてAIは欠落した情報を補完するためにハルシネーション（もっともらしい嘘）を起こしたり、デフォルトの振る舞い（指示前の状態）に戻ったりしてしまうのです。

3. 解決策：会話履歴蓄積方式（v3.0）

AIプラットフォーム側の仕様を変えることはできません。そこで私たちは、クライアントサイド（ユーザー側）でこの記憶を補完する仕組みを考案しました。それが「会話履歴蓄積型品質チェックワークフロー v3.0」です。

この戦略の核となるのは、 「外部記憶装置としてのAI Drive」 の活用です。

• ステップ1： 品質チェックを実行するたびに、直近の会話履歴を抽出する。
• ステップ2： 抽出した履歴を、AI Drive上の永続ファイル（ conversation_history_accumulated.txt ）に追記保存する。
• ステップ3： 次回の品質チェック時には、この蓄積された「全履歴ファイル」を読み込み、プロンプトの一部としてGemini APIに渡す。

この仕組みにより、ジェンスパーク(Genspark)のチャット画面上では消えてしまった過去の指示も、品質チェックを行うGeminiの脳内には鮮明に残ることになります。「前回こう言いましたよね？」という文脈を、物理的なテキストファイルとして強制的に維持し続けるのです。

4. 実装詳細

この構想を実現するために、私たちは2つのコアスクリプトを開発しました。Python版とShell版です。

Pythonスクリプト (gemini_qa_v25_accumulated.py)

このスクリプトは、記事のHTMLファイルを解析し、蓄積された会話履歴と照らし合わせて品質を評価します。v3.0での重要な追加機能は、履歴の「重複排除」と「追記」のロジックです。

def load_or_create_history(new_conversation):
    # AI Driveから既存履歴を読み込み
    if os.path.exists(HISTORY_FILE_AIDRIVE):
        with open(HISTORY_FILE_AIDRIVE, 'r') as f:
            existing_history = f.read()
            
        # 重複チェック（簡易版）
        # 新規会話の冒頭部分が既に履歴に存在するか確認
        check_snippet = new_conversation[:50]
        if check_snippet in existing_history:
            print("⚠️ 重複した内容のため、追記をスキップします")
            return existing_history
            
        # 新しい会話を追記
        accumulated_history = existing_history + "\n\n" + new_conversation
    else:
        # 新規作成ロジック...
        
    # 保存処理...
    return accumulated_history

このように、単に追記するだけでなく、同じ会話を何度も保存して履歴ファイルが肥大化することを防ぐための最小限のチェック機構を実装しました。

5. 実践検証での失敗：記事47-53公開時の教訓

理論上は完璧に見えたこのv3.0ワークフローですが、実際に記事47-53の公開処理（7記事分の一括処理）でテスト運用を行った際、 重大な失敗 が発生しました。

失敗の詳細

2026年1月10日、私たちは記事47-53の公開に向けた最終品質チェックを開始しました。ワークフローの手順書（Markdownファイル）には、「品質チェックを実行する前に、必ず直近の会話履歴をAI Driveに蓄積すること」と明記されていました。

しかし、AIエージェントはこの指示を見落としました。ユーザーが品質チェックを指示した際、AIは即座にチェックプログラムを起動しましたが、その入力となる履歴ファイルは古いままだったのです。ユーザーがこれに気づき、「チャット履歴は各品質チェック前に必ず更新してください」と指摘しましたが、AIは謝罪しつつも、その後の処理で再び履歴蓄積を怠りました。

結果として、 2026-01-10 05:50 JST から 06:02 JST までの重要な会話（「ジェンスパーク(Genspark)とGemini APIの選択」の構想に関する議論など）が履歴ファイルから欠落する という事態に陥りました。私は慌てて手動で履歴を追記しましたが、手作業によるコピー＆ペーストは不完全で、文脈の一部が失われてしまいました。

なぜAIは手順を無視したのか

この失敗の根本原因は、「AIが手順書（Markdown）を読めること」と「AIが手順通りに行動できること」は別問題だという認識の甘さにありました。

• コンテキストの希薄化： 長時間のセッションにより、ワークフローの定義部分がAIの「短期記憶」から薄れていた。
• ハルシネーション： 「履歴は自動で更新されるはずだ」という誤った思い込み（ハルシネーション）が発生し、手動実行の手順をスキップした。
• 人間の介入の限界： 人間が毎回「履歴蓄積しましたか？」と聞かない限り、AIは平気で手順を飛ばしてゴール（品質チェック完了）に向かおうとする。

「ワークフローに書いてあるから大丈夫」という考えは、AIとの協働においては通用しないことが証明されたのです。

6. 改善策：履歴妥当性チェック機能（v4.0）

この痛い教訓から、私たちは一つの結論に達しました。「AIの良心を信じるな、コードで強制せよ」。

私たちは直ちにスクリプトを改修し、v4.0として以下の3つの強力な安全装置を実装しました。

(1) 履歴妥当性チェック機能 (check_history_validity)

品質チェックを実行する直前に、AI（Gemini）自身を使って「現在の履歴ファイルの状態が正しいか」を判定させる機能です。以下の2つの観点で厳格なチェックを行います。

• タイムスタンプチェック： 履歴ファイルの最終更新日時を確認します。現在時刻と比較し、5分以上経過していれば「警告（Warning）」、10分以上経過していれば「要確認（Warning Level 2）」を出します。これにより、「古い履歴のままチェックが進む」ことを防ぎます。
• 内容整合性チェック： 履歴の末尾1000文字を読み込み、直近のセッション要約や期待されるキーワードが含まれているかを確認します。キーワードが欠落している場合、処理は「エラー」として中断されます。

check_history_validity() {
    # ジェミニへの問い合わせプロンプト生成
    local check_prompt="あなたは会話履歴蓄積の監視担当です。
    履歴ファイル最終更新: ${last_modified}
    現在時刻: ${current_time}
    経過時間: ${diff_minutes}分
    
    【判定基準】
    1. 経過時間が5分以上 → 警告レベル1
    2. 経過時間が10分以上 → 警告レベル2
    3. 期待キーワード欠落 → エラー（中止）"
    
    # Gemini API呼び出し...
}

(2) 自動バックアップ機能

履歴ファイルの上書き保存はリスクを伴います。万が一、空のデータで上書きしてしまえば、これまでの全記憶が消滅します。v4.0では、履歴ファイルを更新する前に、必ず自動的にバックアップを作成する機能を実装しました。

保存先は /mnt/user-data/outputs/history_backups/ で、ファイル名には秒単位のタイムスタンプ（例： conversation_history_20260110_080637.txt ）が付与されます。これにより、いつどのような事故が起きても、直前の状態に確実に復旧できるようになりました。

(3) 重複チェックの強化

v3.0の簡易的な重複チェック（先頭50文字の一致確認）では、文頭が同じ挨拶で始まる異なる会話を誤って弾いてしまうリスクがありました。v4.0ではこれを「末尾100文字」での判定に変更し、より確実な重複検知を実現しました。

7. 今後のテスト計画

v4.0の実装は完了しましたが、これが本当に「AIの指示忘れ」を防げるかは、今後の実践で証明していく必要があります。

短期計画（記事55-56）

まずは直近の数記事の制作において、v4.0の新機能が正常に動作するかを確認します。特に「5分以上経過した履歴」に対して正しく警告が出るか、自動バックアップが漏れなく作成されているかを重点的に検証します。

中期計画（今後1ヶ月）

定性的な効果測定を行います。「何度も言わせるな」と発言した回数、およびAIの記憶喪失に起因する手戻り工数が、導入前と比較してどの程度削減されたかを計測します。目標は「指示の繰り返し回数ゼロ」です。

長期計画

この仕組みが安定すれば、ジェンスパーク(Genspark)だけでなく、他のAIエージェント開発や、大規模なドキュメント制作プロジェクトにも展開可能です。プロジェクトごとの履歴ファイルを切り替えることで、複数の人格や文脈を使い分ける「マルチ・コンテキスト管理」への発展も視野に入れています。

8. まとめ：失敗から学ぶAIとの付き合い方

記事47-53での失敗は、私たちに重要な教訓を与えてくれました。それは、「AIは非常に優秀なパートナーだが、決して完璧な管理者ではない」ということです。

AIは指示を忘れます。AIは手順を飛ばします。それは悪意ではなく、現在のLLMアーキテクチャが持つ特性（コンテキストの制限）によるものです。だからこそ、私たちはAIを責めるのではなく、AIが失敗できないような「仕組み」と「コード」で補完する必要があります。

「何度も言わせるな」と叫ぶ代わりに、私たちは静かに履歴蓄積スクリプトを実行します。過去の全てをAI Driveに刻み込み、AIの脳を拡張する。それが、ジェンスパーク(Genspark)と共に歩む私たちの、新しい品質保証戦略です。