すべてのソフトウェアプロジェクトには、間違ったものを作っていたと気づく瞬間がある。メッセージルーター、ツール実行エンジン、会話状態マネージャー、リトライシステムを何週間もかけて書いた——そしてAIプロバイダーがそのすべてを、自分よりもうまく、単一のAPI呼び出しとして処理していることに気づく。
その瞬間がNanoClawのアーキテクチャにつながった。コア全体——WhatsAppメッセージをツール使用、Web閲覧、ファイルアクセス、マルチターン会話を備えたAIエージェントのレスポンスに変換する部分——は約500行のTypeScriptだ。50,000行のフレームワークをインポートする500行のグルーコードではない。AnthropicのClaude Agent SDKの上に構築された、合計500行だ。
初めてソースを読んだ開発者の反応は、たいてい信じられないという顔で、次に本質的な質問が来る：「残りはどこにあるんだ？」
Claude Agent SDKが実際にやっていること
ほとんどのAIエージェントフレームワークが存在するのは、歴史的に言語モデルAPIがステートレスでシンプルだったからだ。プロンプトを送り、レスポンスを受け取る。ツール使用が必要なら、ツール実行ループを自分で構築しなければならなかった。マルチターン会話が必要なら、メッセージ履歴を自分で管理しなければならなかった。モデルに複数のツールから選択させたいなら、ルーティングロジックを自分で構築しなければならなかった。
Claude Agent SDKはその方程式を根本的に変える。SDKは単にClaude APIを呼び出すのではなく、エージェントループを実行する。システムプロンプト、ツールセット、ユーザーメッセージを渡せば、SDKが残りすべてを処理する：メッセージをClaudeに送り、レスポンスを受け取り、Claudeがツールを使いたいかチェックし、ツールを実行し、結果をClaudeに送り返し、Claudeが最終レスポンスを生成するまで繰り返す。ほとんどのフレームワークが数千行かけて実装するツール使用ループ全体が、単一の関数呼び出しだ。
これは薄いラッパーではない。SDKはストリーミング、リトライロジック、トークンカウント、会話状態を処理する。複数ターンにわたるClaudeとツール間のやり取りを管理し、ツール実行の失敗やコンテキストウィンドウの制限といったエッジケースも処理する。NanoClawが実装する必要のない複雑さは、欠落しているのではなく、Anthropicのエンジニアリングチームが保守する十分にテストされたSDKに押し下げられているのだ。
NanoClawが実際に構築しているもの
SDKがエージェントループを処理するなら、NanoClawの500行は実際に何をしているのか？答えは、ループの周辺すべて——単にAPIを呼び出すのではなく、パーソナルAIアシスタントを運用するために固有の部分だ。
第一の責務はチャンネル統合だ。NanoClawはBaileyライブラリ経由でWhatsAppに接続し、メッセージを受信し、適切なエージェントコンテナにルーティングする。これは「誰かがWhatsAppでメッセージを送った」と「エージェントがこのメッセージを処理する必要がある」の間のグルーだ。複雑なコードではないが、不可欠なコードだ——これがなければ、エージェントはユーザーがすでにいる場所に到達する手段がない。
第二の責務はコンテナオーケストレーションだ。すべてのエージェント会話は独自のLinuxコンテナ内で実行される——macOSではApple Container、LinuxではDocker。NanoClawはコンテナを起動し、適切なディレクトリをマウントし、stdin経由でシークレットを渡し、レスポンスを収集する。これは、侵害されたエージェントがサンドボックス外のものにアクセスすることを防ぐセキュリティ境界だ。コンテナライフサイクル管理はおそらく80行のコードだが、その80行が、実際の認証情報を任せられるエージェントとそうでないエージェントの違いを生む。
第三の責務は永続メモリだ。NanoClawは会話、グループ状態、スケジュールタスクのSQLiteデータベースを維持する。各WhatsAppグループは、そのグループのエージェントの長期記憶として機能する独自のCLAUDE.mdファイルを持つ。メモリシステムは意図的にシンプルだ——メモリの複雑な部分（何が関連するか、何を想起するか、コンテキストをどう使うか）はClaude自身が処理するからだ。
第四の責務はスケジュールタスクだ。ユーザーは特定の時間にエージェントに何かをさせることができる——「午後3時にリマインドして」や「毎朝このウェブサイトをチェックして」。NanoClawのcronライクなスケジューラーが適切なタイミングでエージェントコンテナをトリガーする。小さいが本当に便利な機能で、受動的なチャットボットを能動的なアシスタントに変える。
なぜ500行が重要なのか
行数はバニティメトリクスではない。メンテナンス面、バグ面、システムを理解するために必要な認知負荷の直接的な指標だ。
NanoClawのコアにバグが現れた場合、それが存在しうるのは500行の中だ。開発者は1時間以内にコードベース全体を読み、すべての判断を理解できる。50,000行のコアコードを持つフレームワークと比較してほしい——バグを見つけるには、抽象化をナビゲートし、プラグインシステムを理解し、使ってもいない機能をサポートするために存在する間接層を通じて実行をトレースする必要がある。
セキュリティへの影響も同様に具体的だ。すべてのコード行は潜在的な脆弱性だ。NanoClawの500行のコアは、ほとんどのフレームワークの設定パーサーよりも小さな攻撃対象面を持つ。コンテナ隔離、stdinシークレット受け渡し、マウント許可リスト——これらのセキュリティ機能は、午後の数時間で完全に監査できるほど小さなコードで実装されている。
アップグレードの話もシンプルだ。Anthropicがより良いツール使用、より高速なストリーミング、新しい機能を備えたClaude Agent SDKの新バージョンをリリースすると、NanoClawは単一の依存関係を更新するだけでその改善を得る。新しいSDK機能を公開するために更新が必要なフレームワーク抽象層はない。SDKがフレームワークなのだ。
作らないという哲学
NanoClawのアーキテクチャで最も難しかったのは構築することではなく、何を作らないかを決めることだった。カスタムツール実行エンジン、洗練されたメモリ検索システム、マルチプロバイダー抽象層、プラグインマーケットプレイスを追加したいという誘惑——これらはすべて他のフレームワークが構築したものであり、NanoClawが意図的に持たないものだ。
それらの機能のそれぞれが数千行のコード、数十の潜在的バグ、数週間のメンテナンス負担を追加する。そしてそれぞれが、Claude Agent SDKがすでに提供している機能か、Claude自身が手書きのコードよりもうまく処理する機能を複製することになる。
結果として、興味深い判断が実装ではなくアーキテクチャにあるプロジェクトになった。コンテナはどう隔離すべきか？シークレットはどう渡すべきか？メモリはグループごとにどうスコープすべきか？これらがパーソナルAIアシスタントにとって重要な問いであり、NanoClawの500行が答えることに専念している問いだ。
次にAIエージェントフレームワークを評価するとき、機能を数えるのではなく行数を数えてほしい。最も行数の少ないフレームワークは最も能力が低いのではなく、AIプロバイダーに重い仕事を任せるほど問題を十分に理解しているフレームワークかもしれない。