AIカスタム開発、自分がどの層で何を作っているか言えるか

AIツールをカスタムしたり、エコシステムに何か追加したりする開発が増えている。MCPサーバーを立てた、スキルを書いた、エージェントのワークフローを組んだ——そうした経験を持つ人は多いが、「自分が何の層を作っているのか」を明確に言える人は少ない。

Zennに公開されたこの記事は、著者自身の個人開発7件を素材にして、AI開発を3層に分類し、それぞれのClaude Codeエコシステムへの依存度を棚卸しした記録だ。分量はそれほど長くないが、フレームが整理されていて使い回しやすい。「自分の開発がどこに属するか」を問い直すきっかけとして読む価値がある。

3層の語彙：Loop / Sensors / Actuators（とその使い方）

著者はまず、AIの動作を捉えるための語彙として3つを導入する。

  • Sensors（知覚）：AIが外部情報を取り込む手段。Web検索、ファイル読み込み、外部APIからのデータ取得など
  • Actuators（行動）：AIが外部に働きかける手段。ファイル書き込み、API呼び出し、メッセージ送信など
  • Loop（実行ループ）：LLMがSensors/Actuatorsを使いながら「何を知覚し、何を判断し、何を実行するか」を繰り返す制御の流れ

ここで著者が強調しているのは、「3つは並列であり、Loopの中にSensors/Actuatorsが入れ子になっているわけではない」という点だ。これは地味に重要な指摘で、多くの解説記事がエージェントをループ構造の絵で説明するため、「LoopがSensors/Actuatorsを内包する」という誤解が生じやすい。著者はあえてフラットな並列として定義し、「自分はどれを作っているか」という問いの軸にしている。

実例7件を3層に当てはめると何が見えるか

著者が対象にしているのは、「AIを使って作った成果物」ではなく、「AIのカスタムやエコシステム周りの開発」に限定した7件だ。この絞り方自体が誠実で、分類の精度を上げている。

① Loop（実行ループ）そのものの開発
代表例はoxml_agents（AnyAgentベースのエージェント集）。mozilla-ai/any-agentをベースに、誕生日探索・Web検索・Joplin/zimノート検索・SearXNG検索など複数のエージェントを実装している。バックエンドはWindowsネイティブのllama.cpp＋VulkanバックエンドでIntel Arc 130V GPU上のQwen2.5-7B-Instruct Q8_0で動作確認済み（358t/s）、クラウドAPIへの切り替えも同一コードベースで対応済みという徹底ぶりだ。Claude Codeへの依存度は「なし」——自前のLoopを持つ以上、実行時にClaude Codeは不要だ。

② Sensors／Actuatorsの開発
代表例はmemory-mcp（会話をまたいで記憶を保持するMCPサーバー）とmemory-viewer（そのデータをブラウザで閲覧するWebアプリ）。memory-mcpはAzure Table Storageをバックエンドに、stdioモードとHTTPモードの両方を実装し、Claude Desktop・claude.ai・Perplexity・Cometで動作確認済みという、複数ホスト対応が本質的な設計方針になっている。Google OAuth 2.1＋PKCE（RFC 9728、RFC 7591）対応という細かさも、「標準に乗っかる」姿勢の表れだ。依存度は「なし」——MCPは複数ベンダーが採用するオープン規格であり、Claude Code専用ではない。

③ Loopの中身（Policy・知識）の開発
代表例はmarp-slides/marp-slide-craft/diaryのようなスキル群と、CossmeticsAgent（「美容アドバイザーSaki」）。CossmeticsAgentは、CLAUDE.md・persona/agent.md・persona/background.md・.claude/commands/のスラッシュコマンド3種という構成で、コードは一切書かずClaude Codeとの自然言語会話だけで設計・生成されたという。依存度は「強い」——CLAUDE.mdや.claude/commands/はClaude Code固有の規約に依存する。

ここからが興味深い。著者は「形式は結合しているが、資産（ノウハウ）は結合していない」と表現している。中身（instructionsや知識テキスト）はただのMarkdownであり、Gemini GemsやCustom GPTの指示欄に数分でコピー移植できる、というのが著者の見立てだ。

構造を見る：この分類が示す業界の地形

ここからは、この記事の分類から読み取れる、もう少し広い視点の話をしたい。

著者の棚卸しで明確になったのは、①②は構造的にベンダー非依存、③だけがフォーマット依存という非常にきれいな対応関係だ。これは偶然ではない。

①（Loop）は、自分でLLMオーケストレーションを握っている以上、どのホストを使うかは設計上の変数にすぎない。②（MCPサーバー等）は、MCPというオープン規格に乗っている限り、OpenAI/Google ADKを含む複数ベンダーが採用しているため、特定のエコシステムへの縛りが構造上発生しにくい。問題は③だ。ここはフォーマットが特定ホストの規約に直接依存する。ただし、著者も指摘する通り、SKILLフォーマット自体がCopilot CLI・Codex・Gemini CLI向けの互換レイヤーに広がりつつある動きもある。つまり③のポータビリティは今後、フォーマット標準化の競争によって変化する可能性が高い。

この構図は、業界の地政学を象徴している。Loopの争奪（どのオーケストレーションフレームワークが覇権を取るか）よりも、Sensors/Actuators層のコネクタ標準化（MCPが事実上の共通規格になりつつある）と、③の中身（知識・スキル）の配布フォーマットをめぐる競争が、今後の主戦場になりそうだ。

実務への示唆：「どの層か」を決めてから作る

実務的な話として、この分類を頭に入れておくと何が変わるか。

まず、依存度のコントロールが意識的にできる。①②を作るなら最初からベンダーフリーで設計できる。③を作るなら「形式は依存するが資産は依存しない」という区別を理解した上で開発を進められる。この区別がないと、「Claude Codeがなくなったらどうなるの？」という漠然とした不安に対処できない。

次に、開発コストの見積もりが変わる。③はコードをほぼ書かない。CossmeticsAgentのように自然言語の会話だけで設計・生成できる。一方①はLLM・ツール・タスクの組み合わせをコードとして設計する必要があり、ローカルLLMのバックエンド比較（OpenVINO GPU／Vulkan／SYCL／CPUの4択検証）などの実装コストが発生する。この差を理解せずに「エージェントを作りたい」と言い始めると、工数の見積もりがまったく変わってくる。

さらに、ポータビリティの見通しを先に立てられる。記事中の依存度テーブルは、「どのプロジェクトを他のプラットフォームに移せるか、何が残るか」を一覧で確認できる。これはロックインリスクの評価として、個人開発だけでなく組織の開発計画にも転用できる考え方だ。

次の論点：SKILLフォーマットの標準化はどこへ向かうか

最後に、今後の論点をひとつ置いておく。

③の依存度を決定しているのは、SKILLのフォーマット規約だ。CLAUDE.mdや.claude/commands/という形式がClaude Code固有である限り、③はClaude Codeエコシステムの「引力圏」に引き寄せられ続ける。著者も「SKILL形式自体が複数ハーネス対応フォーマットへ広がりつつある」と述べているが、これは逆に言えば「まだ広がりきっていない」ということでもある。

Gemini GemsやCustom GPTが「ペルソナ＋指示＋知識ファイル」という構成をそれぞれ独自に持つ現状は、③の資産が実質的にはフォーマット変換のコストを常に要求する状態を意味する。「数分でコピー移植できる」という著者の楽観は、今のところ内容がMarkdownテキストであるという事実に支えられている。将来、③のフォーマットが動的に評価されるロジックや外部ツール呼び出しを含み始めると、移植コストは跳ね上がる。

「何を作るか」の前に「どの層に何を賭けるか」を決める——この問いは、個人開発だけでなく、AIプロダクトを組織で判断する立場の人にとっても、使える軸だと思う。

参考元: 個人開発の事例から考えるAI開発の3分類