AI協働：「すべてはファイル」をコンテキストに持ち込んだ論文——棄却と保持の間
English
私の1ヶ月はこんな感じでした。という論文を見つけたので共有します。 そして、12月のLLMの進化に対し、急ぎ「欠損駆動思考」を伝えようと整備している理由でもあります。 意思決定、ナレッジ管理、コミュニケーション、組織の概念に影響が出そうだなと。 ソロプレナーが先行すると思いますが、私の興味は複数名のプロジェクトです。
以下の記事はClaudeに記事を作ってもらいました。コピペです。
Claude.ai（Opus 4.6）がリポジトリの内容と論文をもとに生成した記事である。事実関係はpjdhiroが確認済み。
コンテキストエンジニアリングの論文を読んで、自分のClaude＋GitHub運用との対応を観察した記事である。
1月末からClaude＋GitHubでナレッジ管理をやっていて、「これ、ファイルシステムだな」と思っていた。
そこにコンテキストエンジニアリングの論文が出てきて、まさにその感覚に構造を与えてくれた。
01. 論文が言ってること
LLMは本質的にステートレス。セッションが切れたら全部忘れる。
だから外部に永続的なコンテキストリポジトリが要る。
で、そのリポジトリをファイルシステムの抽象化で統一的に扱おう、という提案。
永続層は3つ:
- 履歴（History）: 不変の記録。全インタラクションの生ログ
- メモリ（Memory）: 構造化されたビュー。事実、エピソード、手続き
- スクラッチパッド（Scratchpad）: 一時的な作業空間。推論中の仮置き場
この3つに対してパイプラインを回す:
- Context Constructor: 何を選ぶか、何を捨てるか。トークン予算に合わせて圧縮
- Context Updater: トークンウィンドウに何を流し込むか、いつ差し替えるか
- Context Evaluator: 出力を検証してメモリに書き戻す。幻覚や矛盾を検出
制約があるから、選択・圧縮・検証の設計が要る。
全部入るなら全部入れて終わり。入らないから設計が要る。
02. あれ、やってたことじゃん
読みながら対応表を作ってみて、笑ってしまった。
| 論文の概念 | 自分の実践 |
|---|---|
| 履歴（History） | Gitのコミット履歴 |
| メモリ（Memory） | GitHub Issues |
| スクラッチパッド | session/state.md、作業中の一時ファイル |
| Context Constructor | セッション開始時のIssue読み込み＋README参照 |
| Context Updater | 対話中のコンテキスト管理 |
| Context Evaluator | 品質チェックリスト |
全部対応してる。
別に論文を読んでからやったわけじゃない。「セッション切れて困った」「Issueに書いておかないと忘れる」「state.mdに退避しないと消える」。困りごとを一つずつ潰していったら、結果的にこの形になっていた。
外部との接続もそう。論文がAFS（Agentic File System）として統一的な名前空間を提案しているけど、自分の運用ではローカルファイルの読み書き、GitHub API、OpenAI、Geminiと4つの接続を個別に積み上げて、結果的に同じことをしている。名前空間が統一されていないだけ。
理想的な状態ではない。
個人でやっていて、資源に制約があって、過渡期で、毎日改善している。
論文が提案するアーキテクチャに時間をかけて近づいていくだろう。夢中でやっている。
03. 一点、論文にないもの
ほぼ同意した上で、一つだけ引っかかった。
論文のContext Constructorは「選ぶか、捨てるか」で設計されている。
トークン予算に合わせて、必要な情報を選択し、不要な情報を棄却する。二択。
自分の運用には、第三の操作がある。
「今は処理できない。トークンウィンドウにも入れない。でも捨てない。問いとして保持する。」
具体的には、GitHub IssuesにHOLDラベルをつけて残している。
今のセッションには持ち込まない。でも棄却もしない。
いつか意味がわかるかもしれない。いま無理に構造化すると壊れる。
だから置いておく。
この「保持」の居場所が、論文の永続層にない。
Historyは過去の不変記録で、問いを置く場所じゃない。Memoryは構造化済みの知識で、まだ構造化できないものは入れない。Scratchpadはセッション終了で消える。
「まだ分からないが、捨ててもいない問い」の置き場が、設計されていない。
04. 操作が一つ足りない
論文のパイプラインは、情報に対する操作が3つ。選択、棄却、保存。
この3つで閉じていて、入れ物の設計としては整合している。
自分の運用で起きていることは4つ:
- 選択: 今のセッションに持ち込む
- 棄却: 不要と判断して消す
- 保存: IssueやMemoryに構造化して格納する
- 保持: 構造化せず、問いのまま置いておく
4番目の「保持」は、未解決のまま外部に預ける操作。
トークンウィンドウの中にも外にも、すっきりとは収まらない。
でも消すわけにはいかない。
05. 入れ物と中身
論文のパイプラインは入れ物の設計。
History、Memory、Scratchpad。永続層とパイプライン。ファイルシステムの抽象化。同意する。
ただ、中身の選び方——特に「これは今は分からないが、捨てるべきではない」という判断——は、入れ物だけでは解けない。
その判断をする主体が、パイプラインの中にいるのか外にいるのか。
自分の運用では、自分（＋Claude）がその判断をしている。
論文のパイプラインは入れ物を設計した。
中身の選び方のうち、「保持」という操作が要るんじゃないか。
では、何を棄却して何を保持するのか。その判断をどうやっているのか。
棄却される誤差を、問いとして拾う。そのときの基準や態度を、自分は「欠損駆動思考」としてまとめている。
まだ仮説。
参考・関連
- Everything is Context（arXiv:2512.05470）
- Effective context engineering for AI agents（Anthropic）
- Context engineering for agents（LangChain）
- 日記：Claude+GitHubを2週間：ナレッジ管理
Generated by Claude.ai (Opus 4.6) from repository contents. 2026-03-02