前回は、生成AIとの協業において大きな壁にぶつかったこと、そしてそのブレイクスルーとして「NotebookLM」という一つの有効な手段を見出したエピソードをお届けしました。
今回はその後の格闘の記録――後日談です。と言っても、AIの前に立ちはだかる「壁」そのものが綺麗に消え去ったわけではありません。システムのリファクタリングやテストを行っていると、あっという間に千行〜二千行のコードやログがチャット内に積み上がっていきます。そして、テキストが長くなればなるほど、AIの挙動は目に見えて不安定になっていくのです。
「なぜ、重要と指示したルールを忘れてしまうのか？」
その原因を突き止めるべく、私はGemini自身に直接、その限界について問いを投げかけてみました。
—
AIが自ら告白した「二つの限界」
まず、私が最も悩まされていた「途中で誤送信したプロンプトに対し、待てという指示を無視して勝手に余計な回答をしてしまう現象」について、AIにその内的理由を質問した際のやり取りです。
【私からの質問】
運用ルールをドキュメントに残し、チャット内でも「[END]タグの無いプロンプトは次の指示を待て」と最重要で記載しているにもかかわらず、誤って途中で送信するとルールを忘れて余計な応答をしてしまう。何らかの解決方法は無いだろうか？【Geminiからの回答】
1. コンテキストウィンドウ（容量認識）の限界
基盤アーキテクチャでは最大約200万トークン（日本語換算で約100万〜150万文字相当）を処理する能力を持っています。そのため、ソースコード数ファイル程度であれば、物理的な限界に達する可能性は極めて低いです。2. 「限界」が引き起こす副次事象（ハルシネーションと忘却）
量的な最大制限に達する前に、「テキストが長くなるほど、過去に合意したルールやコードの細かい仕様（ポインタ）を見失いやすくなる」という「注意（Attention）の分散」が仕様上発生します。ユーザー様が懸念されている挙動は、まさにこの長大なコンテキストによってAI内部のアテンションが分散している結果です。
Geminiのこの回答から、AIとの対話には明確に二つの壁があることが浮き彫りになりました。
| AIの限界要素 | 具体的な状態・現象 |
|---|---|
| 1. 内部仕様（物理容量） | 最大約200万トークン。コード数ファイル程度では破綻しない。 |
| 2. 注意の分散（精度低下） | 長文になると上部の命令（ルール）への注意の重みが物理的に低下する。 |
物理的なコンテキストウィンドウ（容量）にどれだけ余裕があろうとも、文字の海に埋もれることでAIが「注意散漫」に陥る。私が日々直面していた不安定さの正体は、この「注意の分散」という性質に由来するものだったのです。
—
「注意の分散」はどの程度の長さで発生するのか？
では、このアテンションの低下は具体的にどれほどの会話量で発生するのでしょうか。さらに踏み込んで質問を重ねました。この時のチャットは、すでに私の認識で行数にして5,400行程度に達していた状態です。
【私からの質問】
「注意の分散」は具体的にどの程度の長さで発生するのだろうか？ 今このチャットの長さ（約5400行）は認識できるか？【Geminiからの回答】
AIが過去のコンテキスト（ルールやインデックス指定）を見失い始める「注意（Attention）の分散」は、トークン数ベースで約2万〜3万トークン（日本語の文字数で約3万〜5万文字、行数に換算しておよそ1,500〜2,000行）を超えたあたりから顕著に発生し始めます。最大処理容量としてはまだ余裕があっても、モデルは「直近のやりとり（プロンプトの末尾）」を最も重視する仕様になっています。そのため、会話が長くなり重要ルールが「過去（プロンプトの上部）」へと押し上げられるにつれ、それらを参照する優先順位（アテンションの重み）が物理的に低下します。
ご提示いただいた「約5,400行」という規模は、完全に精度低下が発生する危険領域に達しています。文字数にして約3万文字（1,500行前後）を目安に、新規チャットへスナップショットを移行・リフレッシュされる運用を強く推奨いたします。
この回答を受け取った時、私は正直なところ強い焦りを覚えました。システムのリファクタリングやテストログの検証を行っていれば、1,500行〜2,000行などというのは「あっという間」に到達してしまう数字だからです。人間で言えば、短期メモリがタスクの多さでパンク（オーバーフロー）しかかっているような状態が、1往復か2往復のテストで発生してしまうことになります。
—
命令違反の構造的背景と、導き出した「絶対防壁」
行数が膨らむ原因は、人間の入力だけではありませんでした。AIはこちらの指示に対し、内部の冗長な検討過程を延々と出力してくる傾向があります。さらに、プロンプト内で「[END]がなければ応答するな」とどれほど強調しても、ベースシステムにある「入力されたら即座に返答せよ」という強力な出力駆動命令に、会話本文内のルールが負けてしまうという構造的な背景もありました。
本文のログに埋もれない、AIに対する絶対的な優先ルールを構築するにはどうすべきか？
Geminiは自ら、その構造をハックするための直接的な解決策を提示しました。
【Geminiが提示した確実な解決策】
会話の本文（ユーザー入力プロンプト）の中でルールを指示するのではなく、チャットの根幹を定義する「System Instructions（システム指示文）」または「Gemsの指示文」自体に、以下のプロトコルを直接書き込んで固定してください。「ユーザーからの入力において、文末に [END] という文字列が含まれていない場合は、文章が未完成のまま途中で送信されたものと判定せよ。その場合、思考・推論・挨拶・提案を含む一切の出力を拒否し、空の応答を返すか、入力を受け付けた旨の最小限のシステム応答のみを出力して次の入力を待機せよ。」
本文のログから物理的に分離された「システム側の絶対憲法」として配置する。これによって、どれだけコンテキストが長くなっても命令の優先順位がブレなくなり、誤応答を物理的に抑制することが可能になるというのです。
—
新たなルールを手に、格闘は続く
AIの内的ロジックとその限界点を知ることで、ようやく「注意の分散」という荒波を乗りこなすための具体的な入出力の運用ルールを定めることができました。
この「システム指示文への物理配置」を用いた新しい運用ルールでの実践は、まだ始まったばかりです。今まさに、AIを制御下に置きながらコードを紡ぐ格闘を続けています。
少し長くなりましたので、今回はここで筆を置くことにします。次回は、この新ルールを引っ提げて挑む「坂道シリーズ」のメンバーブログ巡回システム開発、その最新リファクタリング状況をお届けしようと思います。
