- Claude Code は単なるコーディングツールを超え、エージェントOSへと進化し、ファイルシステムアクセスとUnixコマンドの統合によって多様なワークフローを支援する革新的なシステム
- 特に Obsidianノートシステムとの統合 により、メモ作成、調査、思考整理を自動化し、SSH接続によってモバイルからもアクセス可能な完全なノート運用システムを実現
- ファイルシステムアクセス機能 が中核的な差別化要因であり、会話をまたいだメモリと状態維持を可能にして、ChatGPTやブラウザ版Claudeの致命的な限界である コンテキストウィンドウの制約とメモリ制限の問題 を解決
- Unix哲学（単純性、組み合わせ可能性、テキストストリーム処理）はLLMのツール利用方法と完全に一致しており、50年前の設計原則が現代AIシステムの最適アーキテクチャとして再発見された
- メール管理自動化（Inbox Magic）、オープンソースツール（Claudesidian）などの 実用的な応用例 を通じて、ファイルシステムベースのエージェントシステム が複雑なマルチエージェント構造よりも信頼性が高く、デバッグ可能な AIアプリケーション構築の基盤 であることを強調
Claude Codeの特別さ
- 筆者は最近、AIに関する会話でいつも Claude Codeの驚くべき機能 を熱く語っており、このツールが単なるコーディング支援ツールから 完全なエージェントOS へ発展したと説明している
- 特に Obsidianノートアプリ との統合が中核で、ObsidianはNotionやEvernoteと異なり、すべてのファイルをローカルハードドライブ上に 通常のMarkdownファイル として保存する
- この特性のおかげでAIコーディングツールにとって理想的な対象となり、最初はCursorから始めたが、すぐにClaude Codeへ移行した
- このシステムへの依存が大きくなり、最終的には自宅に サーバーを構築 し、SSHでスマートフォンから接続して、移動中でもノート作成、読書、思考整理ができる環境を実現した
- 数週間前に Dan ShipperのAI & Iポッドキャスト に出演してこのシステムを詳しく説明し、この記事ではその後に得た追加の洞察を共有する
Cursorに対するClaude Codeの優位性
- 「Claude Codeはなぜ特別なのか？」という問いに答えるのは難しかったが、あらゆる面でCursorより優れているというより、特定要素の組み合わせ が卓越して機能しているという結論に至った
- 最近では既存コードベースでの作業よりも、Claude Codeの機能の上に まったく新しいものを構築 することにより多く使っている
-
Unix哲学との完璧な調和
- Claude Codeの秘密はツールへのアプローチにあり、ターミナルベースのアプリケーションとしてアクセシビリティを犠牲にする代わりに、ネイティブなUnixコマンド統合 という強力な機能を提供する
- Unix哲学 はDoug McIlroyが1978年のBell System Technical Journalで文書化し、4つの中核原則を提示した:
- 1. 各プログラムは1つのことをうまく行うように作ること。新しい作業のためには、既存プログラムに機能を追加するより新しく構築すること
- 2. すべてのプログラムの出力は、まだ知られていない別のプログラムの入力になることを想定すること
- 3. ソフトウェアは早期に、理想的には数週間以内に試せるよう設計・構築すること
- 4. 未熟練労働力よりもツールを使ってプログラミング作業を軽量化すること
- Peter H. Salusが1994年の "A Quarter-Century of Unix" で要約した版:
- 1つのことをうまく行うプログラムを書くこと
- 協調して動作するプログラムを書くこと
- テキストストリームを処理するプログラムを書くこと（それが汎用インターフェースだから）
-
LLMとUnixコマンドの完璧な相性
- この 50年前の原則 は、LLMがツールを使う方法と正確に一致している
- モデルは継続的に出力を入力へと「パイプ」し（途中で独自の曖昧さを挟みつつ）、Unixの
| コマンドのように、あるコマンドの出力を別のコマンドの入力へ接続する
- モデルがツールを効果的に組み合わせられないケースは、ほぼ常に ツールが過度に複雑 であることが原因
- Claude Codeが驚異的である第一の理由は、Unixを動かすコマンド群が LLM利用に完全に適している こと
- コマンドが単純なだけでなく非常によく文書化されているため、モデルが学習できる十分なソース資料があった
-
ファイルシステムアクセスの革命
- もう1つの要素は、Claude Codeのコード記述能力、そして最近では散文記述能力である
- Pragmatic EngineerによるClaude Code構築の詳細分析 を読んで答えを見つけた: ファイルシステムアクセス だ
- ファイルシステムはすべてを変える
- ChatGPTとブラウザ版Claudeには2つの致命的欠陥がある: 会話をまたいだメモリの欠如と狭いコンテキストウィンドウ
- ファイルシステムはその両方を解決する: Claude Codeは自分自身にメモを書き、知識を蓄積し、進行中の集計を維持できる
- 状態とメモリ を持ち、単一の会話を超えて思考できる
AIオーバーハング（AI Overhang）
- 2022年に初めてGPT-3 APIを使ったとき、たとえモデルがその時点からこれ以上進歩しなくても、ユースケースの発見には10年 かかるだろうと予測していた
- 実際にはモデルは改善し（推論モデルによってツール呼び出しが信頼できるものになった）、ファイルシステムの発見がその主張を裏づけた
- Pragmatic Engineerのインタビュー では、Claude Codeの初期バージョンを構築したBoris Cherneyが 「プロダクト・オーバーハング（product overhang）」 という概念で説明している:
- プロダクト・オーバーハングとは、モデルが特定の作業を実行できるにもかかわらず、AIが動く製品側が その能力を取り込めるように作られていない 状態を指す
- モデルはすでにファイルシステム探索ができたが、その機能を中心に構築された製品が存在しなかったということだ
- 筆者はファイルシステム + Unixコマンドの組み合わせだと主張するが、核心はモデルの能力がすでに存在し、目覚めるのを待っていた点にある
- Claude Codeは 過剰設計されたインターフェース を通じてモデル能力を制限するのではなく、それを取り込むため、信頼できるエージェントシステム構築の青写真として機能する
コードを超えて
Claudesidianオープンソースプロジェクト
- Claude Code + Obsidianの設定について語ってきたが、実際にはさらに一歩進めて、"Claudesidian" を オープンソース化 した
- 自分のClaude Code + Obsidian環境で使っている多くのツールやコマンドを含んでいる
- 実験の場として活用しており、特に 初期アップグレードツール を構築した
- 中央側で変更が発生したら自分のClaudesidianへ取り込めるようにし、AIが更新対象ファイルに変更があるか確認し、あれば新しい更新と変更内容を 賢くマージ しようとする
- 両プロジェクトは同じUnix哲学の原則に従っている: 単純で、組み合わせ可能で、1つのことをうまく行い、互いに連携して動作するツールだ
Inbox Magic - メール自動化システム
- まだ公開準備はできていないが、近く公開予定の "Inbox Magic"（もっと良い名前を考える予定）というプロジェクトを進めている
- GmailツールセットにアクセスできるClaude Codeリポジトリで、多くのプロンプトとコマンドを通じて メールアシスタントのように動作 する
- 現在の機能はかなり単純だ:
- 検索を実行したり、代わりにメールを送信したりできる
- メール分類やメール作成スタイルの学習のために 完全なトレーニング実行 ができる
- Claude CodeとChatGPTはいずれもメールへアクセスできるが、主に1通か2通ずつしか取得しない
- このシステムはファイルへの書き込みやさまざまな工夫が使えるため、「受信トレイ内のすべての旅行関連メールを見つけて旅行習慣のプロフィールを構築し、それをChatGPT/Claudeが実際の好みに合った旅行調査を行うためのプロンプトとして使う」といった作業が可能
- 試してみたいならGitHubユーザー名を送ってくれれば、テスト可能になり次第共有する予定
核心的な教訓
- 筆者は一般に結論を避けるが、ここには改めて強調する価値のあるいくつかの教訓がある:
- 1. ファイルシステムはLLMのメモリと状態不足を解決する優れたツール であり、もっと頻繁に使われるべきだ
- 2. ツール呼び出しを機能させるには、Unix哲学に従うことに集中 すべきだ
- 3. Claude Codeは未来のエージェントシステムの青写真を示している
- ファイルシステム + Unix哲学は、今あふれている複雑なマルチエージェントシステムよりも 信頼性が高くデバッグ可能なAIエージェント を構築するためのテンプレートであるべきだ
- 戦術的には、自分のプロジェクトにツール呼び出しを組み込む際、単純さを保ち、主要モデルスレッドがそれらを「パイプ」できるようにすることが鍵となる
- すべてのエージェント/チャットボットで解決すべき大きな問題は、コンテキストウィンドウを通さずにパイプできる能力だ
- 4. LLMのユースケースを見つけられない人は、十分に努力していない
1件のコメント
Hacker Newsの意見
Claude CodeがUnix流に動く点が本当に気に入っている。ほかのUnixスタイルのツールを簡単に作れて、Claudeが追加の統合作業なしですぐ使える。ツールのman pageさえ渡せばClaudeが手際よく使いこなす。MCPや複雑なツール定義なしで進められる。自作のブラウザアクセスツールとも問題なく動作する。
最近のLLM時代を受けて、man pageをよりよく検索できるようにしたツール Mansnip を更新した。これをSTDIO MCPで包むのもよい方法だと思う。このコードにAPIだけ載せて、サーバーもpipに入れればよさそうだ。そこまで難しくはなさそうだ。
Claude Codeが自分のスクリプトやツールからブラウザをどう使っているのか気になる。私は既存のSafariセッションのウィンドウを直接操作したいのだが、たいていはChromeや別の新しいインスタンスしか扱わない。
Claudeに直接問題を見つけてもらうより、linterの使い方を教えたほうがはるかに効率的だと気づいた瞬間があった。どのlinterを使うかまで指示しなくても、一覧を教えてインストールするとすぐ活用した。ChatGPTでコーディングを試したときは、有用な結果を得るのにあまりにも多くの努力が必要で期待していなかったが、Claude Codeでは本当に驚く体験だった。
すべてのGUIアプリはそれぞれ異なり、各自の壁を築いた城のように存在している。まるでOSの中で孤立した領地のようだ。一方CLIは、皆が集まる共通の広場であり、データと信号が行き交う情報市場だ。この広場に入るために、どこかへの帰属意識を持つ必要すらない。GUI側でこれに近いものはSmalltalkだが、それでさえあらかじめ忠誠を誓わなければ入れない。
実際にはGUIでも、かなり高い相互運用性と合成可能性を持つシステムは存在する。NextSTEPやdbusのようなものがその例だ。望むならGUIも公開APIベースで、その上にグラフィックスだけ載せて作ることはできる。一般的ではないが、技術的には可能だ。
OSに閉じ込められた城塞のように見えても、一般ユーザーの立場ではCLIアプリよりGUIアプリのほうをはるかに好む。CLIしかなかったら、コンピューターの普及速度は大きく遅れていただろう。
新しく台頭したツールがターミナルで動くからといって、それだけで「真のUNIX哲学の実装」になるわけではない。この比較自体が成り立たない。Hacker News的な釣りタイトルに自分も引っかかってしまったようなものだ。
ここで言うUNIX哲学は、単にターミナルアプリを意味するのではなく、最新のLLMがシェルコマンドを直接実行できるようにしている点が重要だ。これによりLLMは、人間がシェルで行えるほぼすべての活動を実行できる段階に来ている。
UNIX哲学の核心を見ると、1) 一つのことだけを行う小さなプログラム、2) それらが組み合わさってより複雑な仕事をこなせること、3) テキストストリームを普遍的なインターフェースとして使うこと、こうした点がLLMと非常によく合っている。
exec()のような単一のテキストインターフェースのおかげで、あらゆるツールがファイルに作用し、テキストで入出力できるため、LLMがそのまま活用できる。こうしたソフトウェア構造は必然でもないのに、このように構築されたことがLLMにぴったり合っている。上位3件のコメントもすべて、LLMに自己宣伝しろと指示されて書かれたように感じる。
かつてCLIは消えたとよく言われていたが、最近はclaude codeのようなツールのおかげで、むしろCLIが優れたインターフェースになっている。もちろんこれで誰かと対立構図を作りたいわけではないが、こうした勢力図の変化は興味深い。
実際には、開発者を含む熟練ユーザーの立場では「CLI is dead」という言葉を聞いたことがない。一般ユーザーにはGUIの登場後にCLIが消えたように見えるかもしれないが、実際には常にバックグラウンドにCLIが存在してきた。OS Xは真のUnix shellを提供し、WindowsにはPowerShellがあり、Linuxはそもそもサーバー市場を支配している。
私はカスタムGUIインターフェースも自作している。コンピューターの使い方を自分の好みに合わせて、デスクトップ環境全体を作っている。以前は主流のGUIツールが不便でターミナルをよく使っていたが、最近は自分のUI環境がだんだん改善してきている。
ClaudeとObsidianの組み合わせは非常に良いワークフローを生み出してくれる。反復的なノート管理作業はすべてAIに任せている。私はデイリーノートをストリーム・オブ・コンシャスネスの形で積み上げ、そこから新しいアイデアやプロジェクト、資料などを抽出している。Geminiも十分うまく動作する。
LLMとObsidianの統合でぜひ言及したいのがプラグインだ。Obsidianプラグインは簡単にカスタマイズでき、JavaScriptスクリプトをローカルフォルダーで動かせる。Claude Codeはこうしたプラグインの作成や修正に優れている。たとえば、Obsidianファイルをpublishフラグに基づいてGithub repoへ自動同期するカスタムプログラムを作った。おかげでノートを更新すると、Netlify上の自分のWebサイトもすぐ更新される。
筆者には、omnara.com のようにSSHなしでスマホから直接アクセスできるサービスのほうが合っているかもしれない。私はObsidianとClaude Codeをヘッドレスで常時動かし、スマホアプリから直接アクセスする似たような環境を使っている。
Claude Codeを使いたいが、ローカルデータやファイルがどの程度ネットワークに送信されるのか正確に分からず、いくつかの状況では導入が難しい。
自分でMCPで次のような機能を実装した。
{ "name": "unshare_exec", "description": "unshareでLinuxネームスペース内でバイナリを実行", "inputSchema": { "type": "object", "properties": { "binary": {"type": "string"}, "args": {"type": "array", "items": {"type": "string"}} }, "required": ["binary"], "additionalProperties": false } }
最初はunshareだけを使っていたが、少しyak shavingを経た末に、最終的にはローカルでgemma3を動かしつつdebianベースのユーティリティを自由に回せるようになり、驚くような結果が得られた。
完全ローカルベースのObsidian、ローカルLLM、そしてすべてがオープンソースな環境を求めている。そういう未来に期待している。
LLMのおかげで、オープンソースプログラムの活用度と価値はさらに高まっている。以前はオープンソースでもコード構造を理解するのが難しく、直接改変するのは簡単ではなかったが、いまはLLMを活用すれば小さなパッチや新機能追加のような作業がずっと容易になった。つまり、プログラムがオープンソースであるからこそ自分好みに直せるのであり、この点はこれまで以上に重要になっている。
open-weightsだけでは不十分で、データセットやトレーニングパイプラインまで自分で扱えなければ本当の意味はない。もちろん一般の人にはトレーニングパイプラインを自分で回すインフラが不足しているだろうが、データの使われ方やモデル学習の過程を透明に把握できてこそ、本当の所有やバイアス評価が可能になる。
ローカルのOrg mode、ローカルLLM、すべてをEmacsでオーケストレーションし、全体がフリーソフトウェアで動く環境なら最高だろう。引退して時間がたっぷりできたら、ぜひ挑戦してみたい夢だ。
興味があれば、この記事をおすすめする。 https://laurentcazanove.com/blog/obsidian-rag-api
実際に使いものになる規模のモデルをローカルで動かすのは、現実的に不可能ではないのかと疑問に思う。特に64GB RAM、シングルGPUセットアップ程度の開発マシンでは厳しいはずだ。