← 2026-03-08 の一覧へ戻るホーム
ファイルシステムが注目されつつある。

2026/03/07 19:48

ファイルシステムが注目されつつある。

RSS: https://news.ycombinator.com/rss

元のHacker News記事へ ↗
要約▶

Japanese Translation:

要約

AIエージェントはツール中心のワークフローから、コンテキストとメモリにファイルシステムを利用する方向へ移行しており、ファイルベースのAPIが商業的な実現可能性と長期的データ永続化の重要な推進力となっています。

  • 証拠・例

    • LlamaIndex の「Files Are All You Need」 はファイルシステム中心のエージェントへの傾向を示しています。
    • Anthropic が開発した CLI ツール Claude Code はローカルファイルの読み書きを行い、同社が収益性に近づく手助けとなり、ファイルベースのエージェントの商業的価値を強調しています。
    • ETH Zürich の研究では、リポジトリレベルのコンテキストファイル（例：CLAUDE.md）を提供するとタスク成功率が低下し、推論コストが20％以上増加することが判明し、不十分または過剰なコンテキストがパフォーマンスに悪影響を与えることを示しています。

  • コンテキスト対永続化
    LLM の短期的「ホワイトボード」コンテキストウィンドウは、ファイルが提供するエージェントメモリの持続的長期保存とは別物です。

  • ファイルフォーマットを API として利用
    現在のフォーマットには CLAUDE.md、AGENTS.md、copilot‑instructions.md、.cursorrules、そしてオープン標準 SKILL.md があり、多くのベンダーが採用しています。これらの Markdown ファイルはエージェントに対して直接 API として機能します。

  • 補完概念

    • Dan Abramov の social filesystem はユーザーデータを個人リポジトリ内の名前付きファイルとして扱い、アプリが「post」の定義に合意せずとも読み書きできるようにしています。
    • NanoClaw は「機能よりスキル」モデルを示し、各スキルは編集可能な SKILL.md ファイルで表され、ポータブルかつ監査可能なエージェント能力を実現します。

  • ボトルネックのシフトとアーキテクチャ
    AI エージェントのボトルネックは計算からコンテキストへ移行し、ファイルシステムは開発者環境に合った効果的なローカル永続化レイヤーを提供します。ディレクトリ→ファイルの自然なグラフ構造はエージェントに有用ですが、データベースは同時アクセス、スケールでの意味検索、および重複排除には依然として必要です。

  • 潜在的影響
    ファイルシステムは個人コンピューティングを再定義し得る可能性があり、データ・好み・スキル・メモリをユーザー所有のフォーマットで保持し、任意のエージェントにアクセス可能にすることで壁付き SaaS モデルに対抗します。また、長期的な人間知識を個々のソフトウェアプラットフォームを超えて保存できる相互運用層も提供します。

この改訂要約は主要ポイントをすべて網羅し、根拠のない推測を避け、読者にとって明瞭さを保っています。

本文

🌱 芽生える思考の集まり

以前、ベクトルデータベース企業で働いていました。私の仕事は、人々に AI 専用データベース（埋め込み、セマンティック検索など）が必要な理由を説明することでした。そんな中でこの記事を書いている自分を見ると、ちょっと面白い気がします。しかしここにいます――AI エコシステムの皆さんが突然ファイルシステムという謙虚な存在に再び目覚めており、実はそれよりも大きな何かを掴んでいるように思えるからです。

データベースより大きいわけではない。データベースとは違う。
ここで言っておくと、誰かが「ファイルが良い、データベースは悪い」と読んでしまうかもしれません。そんなことはありません。どうぞ最後までご覧ください。

みんながファイルについて語る

過去数ヶ月間 AI エージェント領域を注視していると、不思議な点に気づくでしょう：

  • LlamaIndex が 「Files Are All You Need」 を発表。
  • LangChain はエージェントがファイルシステムを文脈設計に利用できることを書いた。
  • Oracle（そう、Oracle です――誰かが何か作っているとき） が エージェントメモリとしてのファイルシステムとデータベースを比較した記事を公開。
  • Dan Abramov は AT プロトコル上に構築されたソーシャルファイルシステムについて語った。
  • Archil はエージェントが POSIX ファイルシステムを欲しがるため、クラウドボリュームを特別に構築中。

LlamaIndex の Jerry Liu は率直にこう述べています：百ものツールを持つ単一のエージェントではなく、ファイルシステムへアクセスでき、5〜10個程度のツール（ファイルシステム、コードインタープリター、ウェブアクセス）しか持たない世界へ移行している。これが、100以上の MCP ツールを持つエージェントと同じか、それ以上に汎用的なのです。

Karpathy が添えた隣接した観察も私の心に残りました：Claude Code はあなたのコンピュータ上で動き、あなたの環境、データ、文脈を利用しているために機能します。ウェブサイトにアクセスするものではなく、マシン上に存在する小さな精神です。OpenAI はクラウドコンテナで ChatGPT を統括しようとした結果、本来の localhost 上で単純に動かすことを見失ってしまったと言えるでしょう。

そして商業的に重要なのは、コーディングエージェントが現在の AI 利用ケースの大半を占めている点です。Anthropic は利益率に近づいており、その主な推進力は Claude Code ― CLI ツールでありチャットボットではなく、あなたのファイルシステム上でファイルを読み書きするもの ― にあります。

文脈ウィンドウは記憶ではない

多くの議論が見落としている深いポイントがあります。心理学的に言えば、記憶は我々が機能するための基盤です。意思決定を行うたびに人生全体を再読するわけではありません。長期ストレージ、選択的回想、重要でないものを忘れ、必要なものだけを取り出すという仕組みがあります。LLM の文脈ウィンドウはそのような機能を持っていません――むしろ誰かが何度も消しているホワイトボードのようです。

Claude Code を実際に使ったことがあるなら、「context left until auto‑compact」 という通知がどんどん近づく恐怖を体験したでしょう。エージェントが構築したコードベースや好み、意思決定に関する全文脈は圧縮または失われるリスクにさらされています。

ファイルシステムは最も退屈で明白な方法でこれを解決します：書き留め、ファイルに保存し、必要になったときに読み戻すだけです。

  • Claude の 
    CLAUDE.md
     がプロジェクトに関する永続的な文脈を提供。
  • Cursor は過去のチャット履歴を検索可能なファイルとして保持。
  • 人々は 
    aboutme.md
     を作成し、どんなエージェントでも読み取れるポータブルなアイデンティティ記述子（好み・スキル・作業スタイル）としています――API を調整する必要がありません。

ただし！必ずしもそれほど単純ではないかもしれません

ETH Zürich の最近の論文は、リポジトリレベルのコンテキストファイルが実際にコーディングエージェントのタスク完了を助けるかどうかを評価しました。驚くべき結論は、複数のエージェントとモデルで、コンテキストファイルはタスク成功率を低下させつつ推論コストを 20 % 超増加させるというものでした。ファイルを与えられたエージェントはより広く探索し、テストを多く実行し、修正が必要なコードに到達するまで遅延しました。ファイルはチェックリストのように機能し、エージェントがそれを真剣に受け止めすぎた結果です。

このことは前提全体を否定するものではありません。論文の結論は「コンテキストファイルを使わないでください」というものではなく、「不要な要件はタスクを難しくし、コンテキストファイルは最小限の制約のみを記述すべきだ」という点にあります。問題はファイルシステム自体の永続化層ではなく、人々が 

CLAUDE.md
を 2,000 語のオンボーディングドキュメントとして扱い、むしろ簡潔な制約セットとするべきだという点です。

ファイルフォーマットこそ API（ただしどのファイルか？）

現在私たちが持っているものは：

  • CLAUDE.md
  • AGENTS.md
  • copilot-instructions.md
  • .cursorrules
  • そして読むまでにさらに五つくらい増えるでしょう

エージェントには永続的なファイルベースの文脈が必要であることは誰もが認めますが、ファイル名や内容について合意がありません。統一を目指す動きは良い方向です。

Dan Abramov のソーシャルファイルシステムに関する記事は重要な点を固めました：AT プロトコルではユーザーデータを個人リポジトリ内のファイルとして扱います。構造化され、所有者が管理し、フォーマットを理解できるあらゆるアプリが読み取れるものです。重要な設計選択は「投稿」が何であるかを異なるアプリが合意する必要はなく、名前空間（ドメイン名、Java パッケージのように）を使って衝突しないようにすれば良いという点です。各アプリはファイルに反応します。データベースは派生データ―誰もが持つフォルダのキャッシュ化されたマテリアライズドビューになります。

同じ緊張感はエージェントコンテキストファイル領域にも存在します。

CLAUDE.md
と 
AGENTS.md
と 
copilot-instructions.md
を一つにまとめる必要はなく、衝突せず共存できれば十分です。一部統合が進んでいます：Anthropic は Agent Skills をオープンスタンダードとして公開し、Microsoft、OpenAI、Atlassian、GitHub、Cursor が採用した 
SKILL.md
フォーマットを提供しています。Claude Code 用に書いたスキルは Codex でも Copilot でも動作します。ファイルフォーマットが API です。

NanoClaw は軽量な個人 AI アシスタントフレームワークで、機能拡張よりも skills over features モデルを採用しています。Telegram サポートが欲しい？ Telegram モジュールは無い。

/add-telegram
スキル――本質的には Claude Code に統合方法を書いたマークダウンファイルです。スキルは単なるファイル ― ポータブル、監査可能、組み合わせ可能です。MCP サーバー不要、プラグインマーケットプレイスも不要。
SKILL.md
が入ったフォルダだけで完結します。

これは調整なしの相互運用性です。私が言いたいことを明確にするのは重要です――それは強い主張です。技術的には、競合製品同士が連携するためには通常：

  1. 標準化プロセスに数年かけて承認される正式な標準
  2. ある支配プラットフォームが互換性を強制

ファイルは両方を回避します。二つのアプリがマークダウンを読めれば文脈を共有できますし、

SKILL.md
フォーマットを理解すれば機能を共有できます。パートナーシップ契約や標準化委員会に参加する必要はありません。ファイルフォーマット自体が調整役です。

ボトルネックは移動した

インフラストラクチャから有用なアナロジーがあります。従来のデータアーキテクチャは「ストレージがボトルネックだ」という前提で設計されました。CPU はメモリやディスクからデータを待ち、演算は提供されたストレージに反応していました。しかし処理能力がストレージ I/O を上回るとパラダイムは変わりました。業界はストレージとコンピュートを分離し、それぞれ独立してスケールさせる方向へ移行しました―S3 とエフェメラルな計算クラスターの組み合わせです。ボトルネックが移動し、すべてが新しい制約に沿って再編成されました。

AI エージェントでも同様の事象が起きています。ボトルネックはモデル能力やコンピュートではなく「文脈」です。モデルは十分に賢いものの、忘却性があります。ファイルシステムはその単純さにもかかわらず、エージェントが実行される正確な場所―開発者のマシン上、既に存在するデータと環境―で永続的文脈を管理する非常に効果的な手段です。

あなたはグラフを使っている、しかしそれに気づいていない

Twitter で誰かが冗談めかして「ファイルシステムを使用しながらもグラフを必要としないと主張するあなたは、実際にはグラフを否定的に受け止めているだけだ」と言った人もいます。そうです、彼らは正しい。ファイルシステムは木構造です：ディレクトリ、サブディレクトリ、ファイル――有向非循環グラフ（DAG）です。エージェントが 

ls
、
grep
を実行し、ファイルを読み取り、別のファイルへの参照を辿るとき、それはグラフを走査しているのです。

Oracle の記事で Richmond が最も鋭い区別を示しました：「ファイルシステムはインターフェースとして勝っており、データベースはサブストレートとして勝っています。」同時アクセスが必要になったり、大規模なセマンティック検索や重複排除、最新性の重み付けを行いたい場合、自前でインデックスを構築する必要があります。正直言ってそれは結局データベースです。

Weaviate で働いてきた経験から、これは「どちらか一方」という状況ではありません。ファイルインターフェースは普遍性と LLM が既に理解しているため強力です。データベースサブストレートは保証を提供し、実務が真剣になった時に必要なものです。興味深い未来は「ファイル vs データベース」ではなく、「人間とエージェントが相互作用するインターフェースとしてのファイル、そしてユースケースに応じて最適なサブストレートで裏付けられる」という点です。

これは本当にパーソナルコンピューティングについて

ここで私が実際に考えていること――人々が回避しているが直接は言わないポイントを述べます。

ファイルシステムは AI 時代におけるパーソナルコンピューティングの意味を再定義できます：

  • 「すべてローカルで動く」 という意味ではありません（ただし…？）。
  • あなた自身が所有するフォーマットにデータ、文脈、好み、スキル、記憶が存在し、どんなエージェントでも読み取れる。特定のアプリ内に閉じ込められない。

aboutme.md
は今日あなたの OpenClaw/NanoClaw 風味とともに動き、明日来るものとも互換性があります。スキルファイルはポータブルです。プロジェクト文脈はツール間で継続します。

これはすべてがウォールド・ガーデン SaaS アプリや専有データベースへ移行した以前に想定されていたパーソナルコンピューティングの姿でした。ファイルは元々オープンプラットフォームです。そして AI エージェントが計算への主要インターフェースになるにつれ、ファイルはツール切替、ワークフロー構成、アプリ間で継続性を保つ相互運用層へと進化しています――誰かの許可なしに。

理想主義的な部分もあることを認めます。オープンフォーマットの歴史は紙面上では勝利したが実務では失敗した標準でいっぱいです。企業はコンテキストファイルを少し変えて、切替コストを高く保とうと強いインセンティブがあります。既に 

CLAUDE.md
、
AGENTS.md
、
.cursorrules
が共存している事実は分断がデフォルトであることの証拠です。そして ETH Zürich の論文は、フォーマットが存在する場合でも良いコンテキストファイルを書くことが難しいと示しています。多くの人が悪いものを書き、悪いコンテキストファイルは実際には無いよりも悪いという事実です。

しかし私は Dan Abramov が書いた言葉に戻ります：「私たちの記憶、思考、設計はそれを作るために使ったソフトウェアを超えて生き続けるべきだ。」 これは技術的な議論ではなく価値観の議論です。そしてファイルシステムは、その年齢と単純さにもかかわらず、唯一その役割を果たす立場にあります。最良のテクノロジーである必要はありません――ただあなたのものだからです。

同じ日のほかのニュース

一覧に戻る →

2026/03/08 5:43

CAS番号（化学物質登録番号）

## Japanese Translation: CasNumは、コンパスと定規を用いた幾何学的構成により任意精度算術を実装するPythonライブラリです。数値は平面上の点としてエンコードされ、加算・乗算・除算・論理ゲートなどの演算は、線/点、円、直線と円の交点などの5つの基本的な幾何学プリミティブから構築されます。最適化には、2倍による特殊ケース乗算や剰余計算で最高位ビット（2のべき乗）を除去する手法が含まれています。 このライブラリはGame BoyエミュレータのALUに組み込むことを想定しています。CasNumを統合するには、PyBoy の `opcodes_gen.py` を編集するだけで、他のエミュレータコードは変更されません。使用例としては、単純なRSA実装（`python3 -m examples.rsa`）や、幾何学ベースの算術のみで動作させるポケットモンスター 赤版（`python3 -m examples.basic`）があります。初回起動に約15分かかりますが、その後はPython の `lru_cache` によりほぼ 0.5–1 FPS で再起動できます。 ビュアースクリプト (`casnum/cas/viewer.py`) は幾何学的構成を可視化し自動ズームします。RSA例では手動ズームが必要になる場合があります。依存関係は、sympy（コア）、可視化用のオプション pyglet、テスト用 pytest‑lazy‑fixtures、RSA 用 pycryptodome、および任意で Euclid Postulate V です。インストールは `git clone --recursive` の後に `pip install -r requirements.txt` を実行します。使用している ROM（`2048.gb`）は zlib ライセンス、CasNum コアコードは MIT ライセンス、PyBoy は LGPL v3.0 でライセンスされており、このプロジェクトはオープンソースや教育プロジェクトに適しています。

2026/03/08 6:56

3T ブラインドスポット：米国の非営利団体

## Japanese Translation: **概要** 米国の非営利セクターは年間 **3兆ドル** を管理しており、これはイギリスのGDPを上回る金額ですが、そのうち実際にプログラム費用に充てられるのは **約36％（1,800億ドル）** に過ぎません。残りはオーバーヘッド、スタッフ給与、資金調達に使われています。登録済み非営利団体は **180万人以上** であり、その多くは収益が5万ドル未満の場合 IRS Form 990 の提出義務から免除されているため、セクター全体の大部分が公衆の監視から隠れています。 寄付者の信頼感は低下しています。**米国の寄付者の32％が5年以上前よりも慈善団体に不信感を抱いています**（BBB Wise Giving Alliance）、世界的にも三分の一が非営利団体への信頼を失っています（Gallup）。財務的負担は顕著で、**調査対象の非営利団体の36％が2024年末に営業赤字を報告し、10年間で最高水準となりました**。また **41％しか全職員に生活賃金を支払えません**。資金提供者は通常オーバーヘッドを約15 % に抑えるよう指示しますが、多くの非営利団体は管理費に **31 % 近くを使っており、過小報告やコーナーカットが頻発する** ― これは「非営利組織の飢餓サイクル」と呼ばれる現象です。 企業会計との大きな違いは顕著です。IRS Form 990 は年間一度提出され、公開までに **12–18か月** を要し、監査済み財務諸表や詳細なプログラム内訳が欠如しています。一方で公的企業は **10-K（年次）、10-Q（四半期）、8-K（重要事象）** を提出し、60日以内に監査済みの声明を求められます。このコンプライアンス中心の枠組みが可視性の問題を生み出し、寄付者の信頼を侵食しています。 国際的には、英国で実施された研究で **ウガンダの井戸の45％が非営利団体によって資金提供されましたが、機能していませんでした**。これにより 2億1,500万〜3億6,000万ドル相当のリソースが無駄になっています—非効率性の重大さを示しています。既存技術（カメラ・センサー・衛星画像）はリアルタイムで成果を追跡できる可能性がありますが、現在の報告規則ではそのような機能は義務付けられていません。 非営利セクターの将来は、コンプライアンス重視から真の透明性と説明責任への転換にかかっています。この変革なしには、非営利団体は営業赤字と寄付者の懐疑心を続けるでしょう。変革が実現すれば、信頼を回復し持続可能な資金調達を確保できる可能性があります。

2026/03/06 16:17

既存のブリックからLEGO NXTファームウェアをダンプする（2025）

## Japanese Translation: > 著者はPybricksプロジェクトで作業している際、オリジナルのファームウェアバージョン 1.01を動作させていた中古Lego NXTを入手し、このファームウェアの保存コピーが存在しないこと（利用可能なのは新しい 1.03のみ）に気づきました。 > > NXTのAT91SAM7S256 MCU上では、SAM‑BA PEEK/POKE を呼び出すことはできますが、それを行うとファームウェアを書き換えてしまい、古いMCUにはモダンなデバッグインターフェースが欠けているためJTAGも実用的ではありません。ロボットのプログラムは制限付きメモリ内で動作するバイトコードVMで走るので、著者は低レベル機能に焦点を当てました。 > > PyUSB を介して USB 「Read IO Map」コマンドを送信し、`0x100d3d`（フラッシュの約 3 KiB）に位置するVMの書き込み可能な関数ポインタ `pRCHandler` を読み取りました。32 KiB の書き込み可能 MemoryPool は NOP とカスタム ARM コードで埋めることができ、`pRCHandler` をこのプール内のアドレスにリダイレクトすることで任意の直接コマンドをそのコードとして実行させることができます。 > > 著者は、受信パケットから4バイトのアドレスを読み取り、そのアドレス上のワードを返す組み込みアセンブリを挿入し、元のハンドラを置き換えました。この乗っ取られたハンドラを利用して、USB経由で「direct」コマンドをバイト単位で送信し、フラッシュ領域全体（`0x00100000–0x00200000`）を読み取り、完全なファームウェアとユーザーデータを `nxtpwn-dump.bin` にダンプしました。 > > この脆弱性は、ストックファームウェアを実行している任意のNXTで機能し、未改変デバイス上でもベアメタルコードが動作できることを示しています。これにより、保存ツールや自己複製型マルウェアなどの可能性が開かれ、NXTファームウェアの整合性チェックにおける脆弱性も浮き彫りになっています。

ファイルシステムが注目されつつある。 | そっか～ニュース