ThariqがXで断言「全エージェントはファイルシステムを使え」｜状態管理5メリットを解説

Claude Code全体の使い方は Claude Code完全ガイド2026：インストールから本番運用まで をご覧ください。

01 Thariqが「絶対譲らない」と宣言した一行

2025年9月22日、AnthropicのClaude Codeチームに所属するThariq（@trq212）が、Xにわずか数十文字のポストを投じた。表示数は17万を超え、AIエージェント設計の議論を一気に焚きつけた。

“This is a hill I will die on. Every agent can use a file system.” （これは私が絶対に譲らない論点だ。全てのエージェントはファイルシステムを使える）

「Hill I will die on」は英語圏で「これだけは死んでも譲らない原則」を意味する強い慣用句だ。Claude Codeを最前線で開発しているエンジニアが、外部アプリ連携でも、ベクトルDBでも、複雑なステートマシンでもなく「ファイルシステム」という40年以上前から存在するプリミティブを、現代エージェントの最重要要素として挙げた。

なぜここまで強く言い切るのか。Thariqのスレッドと付随画像で示された主張は、おおむね4点に集約できる。

• ファイルシステムは状態（state）を表現する優雅な方法である
• エージェントが「自分の作業を確認」できる仕組みになる
• コンテキストに読み込む内容を選択的に管理できる
• ファイルとフォルダは人類が数十年扱ってきたプリミティブで誰でも理解できる

この主張はClaude Code本体の設計とも完全に一致する。Claude CodeはRead/Write/Editという3つのツールでローカルファイルを直接操作し、そこにTODO、ノート、生成中のコード、テスト結果、すべてを書き出す。会話履歴という揮発的なバッファに状態を閉じ込めず、ファイルという永続層に押し出す——これが2025年以降のエージェント設計の主流となった。

Claude Code開発者Thariqが語るエージェント設計の全貌 でもThariqの設計哲学を扱ったが、本記事では「ファイルシステムを使う」という一点に絞って、なぜ・どう実装するかを掘り下げる。

02 ファイルシステム＝エージェント状態の最適表現

エージェントの「状態」をどこに置くかは、長く議論されてきた問題だ。会話履歴のみで状態を管理する設計、外部DBに書き込む設計、Redux的な集中ステートストアを使う設計——いずれも一長一短がある。Thariqが推すのはこれらすべての中間にあたる「ファイルシステム」だ。

会話履歴のみで状態を管理する場合、エージェントは1ターン前の自分の出力を「思い出す」ためにコンテキスト窓全体を毎回再読する必要がある。100ターン会話が続けば、100ターン分のtoken（数十万トークン）を毎回再送信することになる。コストもレイテンシも、そして肝心の精度も劣化する。

外部DBに書き込む方法はスケールするが、エージェントが状態を変更するたびにスキーマ設計、マイグレーション、トランザクション、権限制御といった重厚な仕組みが必要になる。プロトタイプ段階では完全にオーバーキルだ。

その点ファイルシステムは、スキーマレス・トランザクションレス・人間可読という3つの特徴を持つ。エージェントはwork_in_progress.mdという名前で気軽にメモを残せるし、results/2026-05-10.jsonにその日の処理結果を保存できる。明示的なスキーマ定義は不要で、ファイル名とディレクトリ階層が自然な構造を与える。

実装イメージは次のように極めて単純だ。

# エージェントが現在の進捗を書き出す
write_file("state/progress.md", """
# 進捗ログ

## 完了
- [x] requirements.txtを解析
- [x] 既存テストを実行（passed: 24, failed: 2）

## 進行中
- [ ] failed: test_auth_login の原因調査

## メモ
- bcryptのバージョン不整合の可能性
- 対象ファイル: src/auth.py 行42-58
""")

# 次のターンでエージェントが進捗を再読
state = read_file("state/progress.md")
# stateを読んで「次に何をすべきか」を判断する

会話履歴ではなく独立したファイルに状態を置くことで、コンテキスト窓を圧縮するときも、別のセッションで継続するときも、進捗が「失われない」。Thariqが「state（状態）の優雅な表現」と呼ぶのはこの性質だ。

実際、Claude Codeに搭載されているTodoWriteツールは、内部的にこの考え方を実装している。エージェントは大きなタスクを細かいTODOに分解し、進捗を構造化された形で保持する。ユーザーから見ればチェックボックス付きのリストだが、エージェントから見れば「次に読むべき自分用メモ」だ。

03 検証可能性——エージェント自身が出力を再読する

Thariqの主張で特に重要なのが「エージェントが自分の作業を確認できる」という点だ。これはエージェント工学において「self-verification（自己検証）」と呼ばれる重要な能力で、ファイルシステムなしでは事実上実装できない。

会話履歴中心の設計では、エージェントは「自分が10ターン前にどんなコードを書いたか」を覚えているようで、実際には覚えていない。長い文脈の中ほど精度が落ち、しばしば自分の以前の出力を都合よく書き換えて再現してしまう（hallucinationの一種）。

ファイルシステムを使うと、この問題が劇的に改善する。エージェントは自分が書いたファイルをいつでも再オープンして「正確な内容」を確認できる。

# 1. エージェントがコードを書く
write_file("src/auth.py", generated_code)

# 2. テストを走らせて結果をファイルに記録
run_tests(output_path="test_results/run_20260510.json")

# 3. エージェントが両方のファイルを再読して整合性を検証
code = read_file("src/auth.py")
results = read_file("test_results/run_20260510.json")

# 4. 「自分が書いたコード」と「実際の挙動」を突き合わせて改善

このフローのポイントは、ステップ3でエージェントが「自分の記憶」ではなく「ファイルという外部証跡」を頼りに判断していることだ。これによりhallucinationの余地が大幅に減る。

Claude Codeの実装では、Editツールが特に厳格にこの原則を要求する。Editは変更前に必ずReadを実行することを要求し、エージェントが「ファイルの現在の内容」を理解せずに変更することを禁じている。これはまさに自己検証の強制実装だ。

警告： 検証可能性は「ファイルに書いただけ」では発生しない。エージェントに「書いた後で必ず読み返す」ワークフローを明示的に教える必要がある。プロンプト設計で「Write後にRead、Read結果と意図の差分を確認」というステップを組み込むことで、初めて自己検証が機能する。

Agentハーネスの基礎 で扱ったように、エージェントの信頼性はツール提供だけでは決まらず、ハーネス側のループ設計が決定打になる。ファイルシステムは「再読可能性」という性質を持つので、ハーネス設計者にとって扱いやすい一級市民だ。

04 コンテキスト窓を守る選択的Readパターン

LLMのコンテキスト窓は2026年時点で100万トークン級まで拡大したが、それでもタダではない。トークン数が増えるほど料金が上がり、レイテンシが伸び、しかも長文脈での精度劣化（lost in the middle問題）が顕在化する。

Thariqが指摘する「コンテキストに読み込む内容を選択的に管理できる」という性質は、この問題への回答だ。エージェントは必要な情報だけを必要なタイミングでReadし、それ以外はファイルシステムに置いたままにできる。

たとえば1万行のコードベースを扱うエージェントを考えよう。会話履歴に全コードを毎ターン載せる設計なら、コンテキスト消費は破滅的だ。一方ファイルシステム＋Readツールがあれば、エージェントは：

• まずディレクトリ構造をlsで確認（数十トークン）
• 該当しそうなファイルだけReadで読む（数百〜数千トークン）
• 修正後、変更箇所のみEditで書き戻す（差分のみ）

という極めて効率的なパターンが取れる。コンテキストは「全部入れる」ではなく「必要な分だけ呼び出す」——これが現代エージェントの基本姿勢だ。

# アンチパターン：全ファイルを最初に読み込む
all_code = ""
for path in glob("src/**/*.py"):
    all_code += read_file(path)
# → コンテキスト窓を一気に圧迫、精度劣化

# 推奨パターン：必要なときだけRead
files = list_directory("src/")
target = identify_relevant_file(user_query, files)
content = read_file(target)
# → トークン消費を最小化、精度維持

Claude Codeはこの「選択的Read」を徹底している。ユーザーが「authロジックを直して」と頼んだとき、ClaudeはまずGlobやGrepで関連ファイルを絞り込み、該当ファイルだけをReadする。何百個もあるファイルを全部開くようなことはしない。

Claude Skillsを徹底解説 で扱ったSkills機構も、この思想を継承している。Skillsはフォルダにまとめられた「呼び出し可能な専門知識」で、必要なときだけロードされる。常時CLAUDE.mdに全部書く設計より圧倒的にトークン効率が良い。

05 Progressive DisclosureとSkillsの根本設計思想

ファイルシステムが優れている理由のひとつに「Progressive Disclosure（漸進的開示）」という設計原則がある。これはUI/UXの世界で長く使われてきた概念で、「最初は最小限の情報を見せ、必要に応じて詳細を開示する」というアプローチだ。

エージェント設計でこの原則を実装する手段こそファイルシステムだ。エージェントは最初にディレクトリ構造という「目次」だけを見て、興味のあるサブツリーだけを掘り下げる。フォルダ階層は自然なProgressive Disclosureの装置になる。

project/
├── README.md          ← トップレベルの概要（最初に読む）
├── docs/
│   ├── architecture.md ← 必要なら掘る
│   └── api-spec.md
├── src/
│   ├── auth/          ← 関連あるならこのフォルダだけ開く
│   └── billing/
└── tests/

ClaudeはまずREADME.mdとディレクトリ構造を見て全体像を掴み、ユーザーの質問が認証関連ならsrc/auth/配下だけを掘る。Thariqの言う「人類が数十年扱ってきたプリミティブ」とはこういう構造化された情報空間のことだ。

実は、AnthropicがClaude Skillsで採用した設計思想はまさにこのProgressive Disclosureだ。Skillsはフォルダに格納され、SKILL.mdの先頭にあるdescription（数十トークン）だけが常時ロードされる。Claudeは「このスキルが今のタスクに必要だ」と判断したときに初めて中身全体を読む。

つまりSkillsはThariqの主張する「ファイルシステム＋選択的Read」を、Anthropic公式が製品レベルで実装した一例に他ならない。Skillsの動作原理を一言で表すなら「フォルダ＋遅延ロード」であり、それはThariqの哲学を体現している。

エンジニアがエージェントを設計する際は、次のような階層を意識すると良い。

この階層を「ファイルシステム」というプリミティブだけで表現できるのが大きな強みだ。RDBやベクトルDBを持ち出すまでもなく、自然な遅延ロードが組める。

06 マルチエージェントの共有ホワイトボード活用

ファイルシステムの真価がさらに発揮されるのがマルチエージェント環境だ。複数のエージェントが協調作業する際、状態を共有する手段が必要になる。ここでも会話履歴を共有する設計はうまくいかない。

理由はシンプルだ。エージェントAが10万トークンの作業履歴を持っていて、それをエージェントBに渡す場合、Bは10万トークン全部を読むハメになる。タスクが進むほど履歴は雪だるま式に膨張し、最終的にどのエージェントも実質的に何もできなくなる。

ファイルシステムを共有ストレージに使えばこの問題は解消する。エージェントAは作業結果を構造化されたファイル（JSON、Markdown、CSVなど）に書き出し、エージェントBはそのファイルだけを読む。ファイルシステムは「ホワイトボード」になる——これがマルチエージェントにおける最重要パターンだ。

# エージェントA：データ収集担当
data = fetch_external_api(query)
write_file("shared/raw_data.json", json.dumps(data))
write_file("shared/handoff.md", """
# データ収集完了
- 件数: 1,247
- 期間: 2026-04-01 〜 2026-05-09
- ファイル: shared/raw_data.json
- 次の担当: 分析エージェント
""")

# エージェントB：分析担当（別セッション）
handoff = read_file("shared/handoff.md")
# handoffを読んで何をすべきか把握
data = json.loads(read_file("shared/raw_data.json"))
analysis = analyze(data)
write_file("shared/analysis_results.csv", to_csv(analysis))

# エージェントC：レポート作成担当
results = read_file("shared/analysis_results.csv")
report = generate_report(results)
write_file("output/final_report.md", report)

このパターンでは、各エージェントは「自分の責任範囲」のファイルだけを読み書きする。会話履歴を共有する必要がないため、エージェント間の結合度が下がり、再起動・並列化・置き換えも容易になる。

クラシックなコンピュータサイエンス理論で「Blackboard Architecture（黒板アーキテクチャ）」と呼ばれる古典的なパターンが、まさにこれだ。1970年代の音声認識システムHearsay-IIで提案された設計が、2026年のLLMエージェントで再評価されている。

Agentハーネスの基礎 で触れたように、エージェントハーネスは結局のところ「ループ＋ツール＋状態」の3要素で構成される。マルチエージェント設計においては、この「状態」をファイルシステムに集約することで、各エージェントを独立に開発・テスト・デプロイできるようになる。

07 非コーディングエージェントへの応用パターン

「ファイルシステムはコーディングエージェントの話でしょ」と思う読者もいるかもしれないが、Thariqの主張は明確に「Every agent」だ。コードを書かないエージェントでもファイルシステムを使うべき、と言っている。

たとえばデータ分析エージェントを考えよう。ユーザーから「このCSVを分析して」と頼まれたとき、ファイルシステムを使わない設計だと、エージェントは中間結果を全て会話履歴に文字列として保持することになる。100MBのCSVを分析した後、フィルタしたサブセット、ピボットテーブル、グラフ用の集計データ、すべてを会話に詰め込むのは現実的でない。

ファイルシステムを使えば話は変わる。

# データ分析エージェント
raw = read_file("input/sales_2026q1.csv")  # ユーザー入力

# フィルタ結果を保存
filtered = filter_q1_north_america(raw)
write_file("intermediate/filtered_q1_na.csv", filtered)

# ピボット結果を保存
pivot = pivot_by_product_category(filtered)
write_file("intermediate/pivot_by_category.csv", pivot)

# 最終レポート
report = render_report(pivot)
write_file("output/q1_north_america_report.md", report)

# サマリーだけを会話に返す
return "レポートをoutput/q1_north_america_report.mdに書き出しました（サマリー：北米Q1売上は前年比+12%）"

エージェントは中間結果を全てファイルに書き、会話で返すのは「サマリーとファイルパス」だけだ。コンテキストは最小限に保たれ、ユーザーは必要に応じて中間ファイルを開いて検証できる。

この発想はリサーチエージェント、メール処理エージェント、カスタマーサポートエージェントなど、ありとあらゆるドメインに応用できる。「中間生成物をすべてファイルに残す」という設計指針を持つだけで、エージェントの保守性・デバッグ性・再現性が劇的に向上する。

特にデバッグの観点では、ファイルシステムの恩恵は計り知れない。エージェントが想定外の挙動をしたとき、開発者は単に該当ディレクトリを覗けば「何を読み、何を書いたか」がすべて分かる。tail -fでログを追えるし、diffで変更内容を比較できる。Unixが何十年も育ててきた強力なツール群がそのまま使える。

会話履歴中心の設計と、ファイルシステム併用の設計を比較すると差は歴然だ。

最後に、Thariqがファイルシステムを使ったエージェント設計の流れをMermaid図で整理しておこう。

このフローの本質は「情報をファイルに置き、会話には要約だけを流す」という分業だ。Thariqの言葉を借りれば、ファイルシステムはエージェントにとって「拡張された記憶」かつ「自己検証の基盤」かつ「協業のホワイトボード」でもある。

Claude Skillsを徹底解説、Agentハーネスの基礎、Claude Code開発者Thariqが語るエージェント設計の全貌 と合わせて読むと、Anthropicが描くエージェント設計の世界観がより立体的に理解できる。「全エージェントはファイルシステムを使え」というシンプルな宣言の裏には、何十年にわたるソフトウェア工学の蓄積と、最先端LLMハーネス設計の知見が凝縮されている。これからエージェントを設計する人は、まずこの一行を心に刻んでおきたい。

参照ソース

• Thariq氏のX投稿（17万imp）
• Anthropic Claude Code Read/Write/Edit ドキュメント