巨大ファイルの丸読みによるコンテキスト即死（セッション崩壊）とスライス読み込み（Pointer-then-Fetch）設計
1. 概要
AIエージェントの動作において、LLMのコンテキストウィンドウ（Context Window）は最も貴重かつ高価な共有メモリリソースである。 Claude Code（anthropics/claude-code#12133）等で報告された「巨大ファイルを丸ごと読み込んだことによるコンテキスト制限クラッシュと、そこからの復旧不可能性（セッション死）バグ」は、エージェントがファイルの読み込みにおいて「全量ロード」をナイーブに行うことの致命的な危険性を示している。 本稿では、このコンテキスト崩壊のメカニズムを分析し、shiori（RAG）および sunaba（コンテナツール）が協調して実現している「スライス読み込み（Pointer-then-Fetch）」設計の有効性を考察する。
2. インシデントの分析：claude-code#12133
2.1. 回復経路のない「セッション即死」の発生
AIエージェントが、プロジェクト内の巨大なソースコード、自動生成ファイル、または数万行のログファイルを解析しようとする際、ファイル全体をそのまま全量読み込む（cat 相当の操作）と、以下の不可逆なシステム障害が発生する。
- 読み込んだファイルサイズがモデルのコンテキスト制限（Token limit）を越える、または上限の大部分を占拠する。
- APIが「Context limit reached（トークン制限超過）」のエラーを返して即座にクラッシュする。
- セッション死（ゾンビ化）の発生: 一度このエラーが発生すると、エージェントの会話履歴（Context History）に「その巨大なファイルの中身」が残ってしまいます。そのため、ユーザーがその後に「今の読み込みはキャンセルしてくれ」等のいかなる指示を送っても、API送信のたびに毎回トークン制限超過エラーが返り続け、セッションを強制破棄（削除）して最初からやり直す以外の復旧方法がなくなる。
2.2. 後付の対策とその限界
このクラッシュを防ぐために、UI側で「ファイルを読み込む際は offset と limit を使って部分的に読み込んでください」とAIプロンプトでお願いする（指示する）対策が取られた（claude-code#11616）。 しかし、このアプローチはエージェント（LLM）の「自律的な判断力」に依存しており、AIが「ファイルを詳しく調べたい」と焦って全量ロードを選択した瞬間に、やはりセッションが崩壊する脆弱性を残している。
2.3. 実体験：チャットUI時代に踏んだ「5時間制限とサルベージ地獄」
本稿の著者も、開発の初期段階（Claude Desktop等のチャットUIを使用していた時期）に、このセッション即死による深刻なトラブルに直面した。
複雑なコードベースのデバッグや調査をチャットUIで進めていた際、膨大なログやファイルを流し込んだことで、会話履歴が限界まで肥大化した。その状態で「5時間のメッセージ制限（時間制限によるロック）」に達した。
ここからの復旧がまさに地獄（サルベージ地獄）であった。
- チャットUIには CLI のような
/compact（会話履歴の圧縮）コマンドが存在しないため、過去の巨大なデータがすべて履歴に載ったままになる。 - 5時間の制限解除後、作業を再開させるために指示（1言のチャット）を入力した瞬間、AIはその1言に回答するためにこれまでの超巨大な全履歴（何万トークン）をすべてインプットとして再送信した。
- 結果、入力がモデルの限界値を超えて即死し、APIエラーになるか、あるいは無駄なログを出力し直してメッセージ上限を瞬時に食い尽くし、再び5時間ロックされるという無限ループが発生した。
- 途中の調査結果やコードを「要約して出力（サルベージ）」させようとするたびに、巨大なトークンが消費されてロックされ、金銭と時間（5時間待ち）だけが無駄に消費される悲惨な状況に陥った。
この「チャットUIでのサルベージ地獄」という痛烈な実体験こそが、「AIに無駄なコンテキストを抱えさせないための、厳格なRAG（shiori）とスライス読み込み（sunaba）」を開発する強力な原動力（着火点）となった。
3. shiori ＆ sunaba による「Pointer-then-Fetch（ポインター・フェッチ）」設計
これらの「コンテキスト即死リスク」に対し、shiori と sunaba の連携は、AIに巨大なファイルを丸ごと見せない「物理的なスライス読み込み（Denu-sification）」を構造的に強制している。
3.1. Shioriによる「ポインター（行番号）」の特定
shioriは、リポジトリ全体をインデックス（ctags等によるシンボル抽出）し、事前にデータベース化している。- AIは、ファイル全体を読み込むことなく、
shiori_keyword_searchやshiori_reportを使って、「目的の関数やクラス定義が、どのファイルの何行目から何行目に存在するか」という 「ポインター（位置情報）」 だけを正確に取得する。
3.2. Sunabaによる「スライス読み込み（read_file_range）」の執行
- 位置情報を得たエージェントは、
sunabaのread_file_range（行範囲指定読み込み） ツールを使用し、「指定したファイルの120行目から160行目の40行だけ」をピンポイントでフェッチする。 - コンテナ側ツールが「開始行（StartLine）」と「終了行（EndLine）」の指定をアサーション（強制）するため、エージェントは自動的に必要最小限のトークンだけをコンテキストに格納する。
4. 結論
AIエージェントにとって、ファイルの「全量読み込み」は、セッションを修復不可能なゾンビ状態に陥らせる露出した急所（脆弱性）である。 shiori（目）と sunaba（手足）が協調して実現する 「Pointer-then-Fetch（位置を特定してから、その範囲だけをスライスして吸い上げる）」 アーキテクチャは、
- APIトークン消費を極限まで節約し、月額定額サブスクの枠内に動作を収める。
- 巨大ファイル読み込みによる「コンテキスト即死バグ」を構造的に100%防止する。
という、エージェントを長期間、安価かつ安定して自律稼働させるために必要不可欠な、最も頑丈で美しい「知能の制御システム」であるといえる。