MCP on KnightLiブログ

GraphifyがClaude Code最大の制約を解く：コードベースをAIが検索できる知識グラフへ

Thu, 21 May 2026 08:02:32 +0800

safishamsi/graphify は、AIコーディングアシスタント向けの知識グラフツールです。目的は明快です。プロジェクトディレクトリ内のコード、文書、SQL schema、スクリプト、論文、画像、動画、音声を検索可能な知識グラフに整理し、AIアシスタントが grep、全文読み込み、その場限りの検索だけに頼らずにプロジェクトを理解できるようにします。

プロジェクトURL：safishamsi/graphify

この記事の整理時点で、GitHubページには約50.2k stars、5.4k forksが表示されており、ライセンスはMITです。READMEでは、AIコーディングアシスタント内で /graphify と入力すると、プロジェクト全体を検索可能な知識グラフにマッピングすると説明されています。

解決する中核問題

AIコーディングアシスタントはますます強くなっていますが、実際のコードベースではまだよく次の問題に直面します。

主要モジュール同士がどうつながるのかわからない。
多くのファイルを読んでも、全体のアーキテクチャマップができない。
検索でテキストは見つかるが、上流・下流の依存関係がわからない。
コード、database schema、ドキュメント、インフラ設定が別々の場所に分散している。
チーム開発では、人によってプロジェクト構造の理解が異なる。

Graphifyが作ろうとしているのは、プロジェクトの「記憶層」です。コードエンティティ、文書の概念、データベース表、設定、設計メモ、ファイル間の関係をつなげ、AIアシスタントが毎回ゼロからファイルを読むのではなく、グラフを問い合わせられるようにします。

最小構成での使い方

Graphifyの最小利用はとても簡単です。インストール後、AIコーディングアシスタント内で次を入力します。

`1`	`/graphify .`

PowerShellでは先頭の / がパス区切りとして扱われるため、Windows PowerShellでは次のようにします。

`1`	`graphify .`

実行後、graphify-out/ ディレクトリが生成され、主なファイルは次の三つです。

graphify-out/
├── graph.html
├── GRAPH_REPORT.md
└── graph.json

それぞれの役割は異なります。

graph.html：ブラウザーで開けるインタラクティブグラフ。ノードクリック、フィルター、検索ができる。
GRAPH_REPORT.md：プロジェクトのハイライト、重要概念、意外な接続、推奨質問。
graph.json：完全なグラフ。後から再読み込みせずに直接問い合わせられる。

Mermaidの呼び出しフロー図を含む読みやすいアーキテクチャページを作るには、次を実行します。

`1`	`graphify export callflow-html`

インストールと対応プラットフォーム

GraphifyのPyPIパッケージ名は graphifyy です。y が二つある点に注意してください。READMEでは、PyPI上の他の graphify* パッケージはこのプロジェクトと無関係だと明記されています。ただしCLIコマンド名は graphify のままです。

推奨インストール方法は次の通りです。

`1`	`uv tool install graphifyy`

代替方法もあります。

1
2

pipx install graphifyy
pip install graphifyy

インストール後、AIアシスタントに登録します。

`1`	`graphify install`

対応プラットフォームは多く、Claude Code、Codex、OpenCode、GitHub Copilot CLI、VS Code Copilot Chat、Aider、Cursor、Gemini CLI、Kimi Code、Kiro、Google Antigravityなどがあります。プラットフォームごとに次のようなコマンドを使えます。

graphify install --platform codex
graphify install --platform gemini
graphify cursor install
graphify antigravity install

Codexユーザーは、~/.codex/config.toml の [features] に次も追加する必要があります。

`1`	`multi_agent = true`

READMEでは、Codexは /graphify ではなく $graphify を使うとも説明されています。

どんなファイルを処理できるか

Graphifyは幅広い入力タイプを扱えます。

コードでは31言語をサポートします。Python、TypeScript、JavaScript、Go、Rust、Java、C/C++、Ruby、C#、Kotlin、Scala、PHP、Swift、Lua、Zig、PowerShell、SQL、Shell、JSONなどです。

文書では次をサポートします。

.md
.mdx
.qmd
.html
.txt
.rst
.yaml
.yml

オプション依存関係でさらに拡張できます。

pip install "graphifyy[pdf]"
pip install "graphifyy[office]"
pip install "graphifyy[video]"
pip install "graphifyy[mcp]"
pip install "graphifyy[neo4j]"
pip install "graphifyy[sql]"
pip install "graphifyy[all]"

pdf はPDF抽出、office は .docx と .xlsx、video は動画と音声の文字起こし、mcp はMCP stdio server、neo4j はNeo4jへのpush、sql はSQL schema抽出に使います。

生成されるレポートの価値

GRAPH_REPORT.md は普通の要約ではありません。プロジェクト内でAIアシスタントが注目すべき関係を抽出します。

READMEで挙げられている内容には次のようなものがあります。

God nodes：プロジェクト内で最も多く接続されている中核概念。
Surprising connections：ファイルやモジュールをまたぐ意外な接続。
The why：コメント、docstring、設計文書から抽出された設計理由。
Suggested questions：グラフが特に答えやすい質問。
Confidence tags：関係が EXTRACTED、INFERRED、AMBIGUOUS としてラベル付けされる。

これは重要です。通常の検索は「この単語がどこに出るか」を教えます。一方、グラフは「この概念がどのモジュール、設定、表、文書と関係するか」を答えられます。大規模コードベースでは、これは単純な全文検索よりアーキテクチャ理解に近いものです。

よく使うコマンド

Graphifyの主なコマンドは次の通りです。

/graphify .
/graphify ./docs --update
/graphify . --cluster-only
/graphify . --no-viz
/graphify . --wiki
graphify export callflow-html
/graphify query "what connects auth to the database?"
/graphify path "UserService" "DatabasePool"
/graphify explain "RateLimiter"

論文や動画をグラフへ追加することもできます。

1
2

/graphify add https://arxiv.org/abs/1706.03762
/graphify add <youtube-url>

PR分析補助には次のコマンドも使えます。

graphify prs
graphify prs 42
graphify prs --triage
graphify prs --conflicts

これらはコードレビューに向いています。PRがどのグラフコミュニティに影響するか、他のPRと衝突リスクがあるか、どのreview queueを優先すべきかを確認できます。

MCP、Neo4j、CIとの関係

GraphifyはHTMLグラフを生成するだけではありません。グラフをAIアシスタントへ繰り返し呼び出せる形で公開できます。

たとえばMCP serverを起動できます。

`1`	`python -m graphify.serve graphify-out/graph.json`

MCP serverは query_graph、get_node、get_neighbors、shortest_path、list_prs、get_pr_impact、triage_prs などを提供します。

Neo4jへのエクスポートやpushにも対応します。

1
2

/graphify ./raw --neo4j
/graphify ./raw --neo4j-push bolt://localhost:7687

チーム開発では、READMEは graphify-out/ をgitにコミットすることを提案しています。これにより、チーム全員が同じプロジェクトマップから始められます。次も実行できます。

`1`	`graphify hook install`

これにより、git commit後にグラフが自動再構築され、merge driverも設定されます。複数人が並行してコミットしても、graph.json に競合マーカーが残りにくくなります。

プライバシーとコスト

GraphifyのREADMEはプライバシー境界を比較的明確に説明しています。

コードファイルはtree-sitterでローカル解析され、API呼び出しは発生しません。動画と音声はfaster-whisperでローカル文字起こしできます。文書、PDF、画像などの意味抽出は、利用しているAIアシスタントのモデルAPIを通ります。

headless graphify extract を使う場合、次の環境変数が必要になることがあります。

ANTHROPIC_API_KEY
GEMINI_API_KEY
GOOGLE_API_KEY
OPENAI_API_KEY
DEEPSEEK_API_KEY
MOONSHOT_API_KEY
OLLAMA_BASE_URL

ローカルOllama、AWS Bedrock、Claude Code CLIなどもbackendとして使えます。READMEにはtelemetry、usage tracking、analyticsがないことも記載されています。

実際に使うときは、コードのローカル解析がすべての内容が外へ出ないことを意味するわけではない点に注意が必要です。文書、PDF、画像、クラウドモデルが関わる場合は、backend、API key、企業コンプライアンス、データ境界を確認する必要があります。

向いている場面

Graphifyは次のようなユーザーに向いています。

Claude Code、Codex、Cursor、Gemini CLIにプロジェクト構造をより理解させたい開発者。
大規模で見慣れないコードベースを素早く理解したい人。
コード、SQL schema、ドキュメント、設定をまとめて分析したいチーム。
アーキテクチャレビュー、PR review、リファクタリング影響分析を行う人。
プロジェクト知識をMCPツールとしてAgentに公開したい人。
チームのために「プロジェクトマップ」を残したい技術リーダー。

すべてのプロジェクトに必要なわけではありません。小さなスクリプト、一回限りのdemo、非常に単純なリポジトリでは、通常の検索とREADMEで十分かもしれません。Graphifyの価値は、モジュールが多く、文書が多く、チーム開発が多く、AIアシスタントが頻繁に関与する大きなプロジェクトでより出やすくなります。

まとめ

Graphifyの意味は、AIコーディングアシスタントのコンテキストを「一時的なファイル読み取り」から「長期的に検索可能なプロジェクト知識グラフ」へ進めることです。

開発者にとって、GraphifyはIDE、検索、LSPの代替ではありません。AIアシスタントに構造化された記憶層を追加します。どのモジュールが重要か、どの概念が強くつながるか、どの文書が設計理由を説明しているか、あるPRがどのコミュニティに影響するかを扱えます。Codex、Claude Code、Gemini CLI、AntigravityのようなAgentツールが普及するほど、この種のプロジェクトグラフ層はますます有用になります。

参考：

GitHub：safishamsi/graphify

agentmemory：Claude Code、Codex、Cursorに永続メモリを持たせる

Tue, 19 May 2026 10:56:50 +0800

rohitg00/agentmemory は、AIコーディングAgent向けの永続メモリシステムです。目的は明確で、Claude Code、Codex CLI、Cursor、Gemini CLI、OpenCode などのツールが、新しいセッションのたびにプロジェクト背景、アーキテクチャ判断、過去の問題を学び直さなくて済むようにすることです。

プロジェクトURL：https://github.com/rohitg00/agentmemory

執筆時点では、GitHub API上で約1.3万 star、主要言語は TypeScript、ライセンスは Apache-2.0 でした。READMEでは “Persistent memory for AI coding agents” と説明されています。

何を解決するのか

AIコーディングAgentのよくある課題は、記憶がセッションごとに切れることです。今日Agentに認証の問題を修正させても、明日新しい会話を開くと、次のような情報を忘れていることがあります。

なぜその設計判断をしたのか。
どのファイルを慎重に扱うべきか。
以前どのバグを直したのか。
どのコマンド、ツール、ローカルサービスを使うのか。
チームのコーディング規約は何か。

静的なメモも役立ちますが、実際の作業フローとつながらず忘れられがちです。agentmemory は、複数のAIコーディングツールで共有できるメモリ層を提供しようとしています。

対応するAgent

READMEでは、Claude Code、Codex CLI、Cursor、Gemini CLI、OpenCode、その他 MCP 対応ツールが挙げられています。ローカルサービス、MCP、hooks、連携機能を通じて、複数のアシスタントが同じプロジェクト文脈を共有する考え方です。

ツールを切り替えるチームでは特に便利です。ある開発者は Cursor、別の開発者は Claude Code、自動化は Codex CLI という状況でも、共有メモリがあれば説明の繰り返しを減らせます。

クイックスタート

グローバルインストール：

npm install -g @agentmemory/agentmemory
agentmemory
agentmemory demo
agentmemory connect claude-code

npx でも実行できます。

`1`	`npx @agentmemory/agentmemory`

ローカルサービスは次で利用できます。

`1`	`http://localhost:3113`

実際には、まずメモリサービスを起動し、コーディングアシスタントを接続して、開発中にAgentがプロジェクトメモリを読み書きする流れになります。

静的なメモリファイルとの違い

多くのチームはすでに AGENTS.md、CLAUDE.md、README、ローカルドキュメントを持っています。これらは便利ですが静的です。セッション履歴、タスク結果、繰り返し出てくる判断を自動的に扱うわけではありません。

agentmemory は永続的な文脈サービスに近いものです。現在のプロジェクトやタスクに関係するメモリを保存し、必要なときに取り出すことを目指しています。ドキュメントを置き換えるというより、作業文脈を再利用しやすくする役割です。

典型的な用途

たとえば次のような場面で役立ちます。

プロジェクトのセットアップ手順やよく使うコマンドを覚える。
リスクのあるリファクタを避けた理由を記録する。
flaky test やローカルサービスについてメモする。
ドメイン用語を複数のAIアシスタントで共有する。
新しいセッションでも前回の作業を続けやすくする。

長期運用のプロダクト、モノレポ、暗黙知の多いプロジェクトでは特に価値があります。

注意点

まず、メモリの品質が重要です。古い情報や間違った情報が残ると、将来のAgentが同じ誤りを繰り返す可能性があります。重要なメモリは短く、明確で、レビューしやすく保つべきです。

次に、プライバシーです。セキュリティモデルが明確でない限り、秘密情報、APIキー、顧客データ、本番環境の機密情報を保存すべきではありません。

最後に、メモリはテストの代わりにはなりません。文脈理解は助けますが、最終的な保証はコードレビュー、テスト、検証から得る必要があります。

向いている人

agentmemory は、複数のAIコーディングツールを使う開発者、大きなコードベースを扱うチーム、Agentに前回の作業を継続させたいユーザーに向いています。小さな単発スクリプトでは必須ではありません。

まとめ

agentmemory が面白いのは、メモリを小さなプロンプト技ではなく、AIコーディングのインフラとして扱っている点です。コーディングAgentが日常開発に入ってくるほど、永続的なプロジェクトメモリは現実的な不足ピースになります。

AIにPCを操作させる？UI-TARS-desktopはデスクトップ、ブラウザ、ツールをつなぐ

Tue, 19 May 2026 10:56:50 +0800

bytedance/UI-TARS-desktop は、ByteDance が公開しているマルチモーダル AI Agent プロジェクトです。単一のデスクトップアプリではなく、Agentスタックとして構成されています。現在の README では主に Agent TARS と UI-TARS Desktop の2つの方向が示されています。

プロジェクトURL：https://github.com/bytedance/UI-TARS-desktop

公式サイト：https://agent-tars.com

執筆時点では、GitHub API上で約3.4万 star、主要言語は TypeScript、ライセンスは Apache-2.0 でした。READMEでは “Open-Source Multimodal AI Agent Stack” と説明されています。

Agent TARS と UI-TARS Desktop の違い

READMEでは2つのプロジェクトが同じ比較表で説明されています。

Agent TARS：GUI Agent、視覚能力、ターミナル、ブラウザ、プロダクトワークフローをつなぐ汎用マルチモーダルAI Agentスタック。
UI-TARS Desktop：UI-TARSモデルをベースにしたデスクトップアプリで、ローカルまたはリモートPC、ブラウザを操作するネイティブGUI Agent機能を提供。

簡単に言えば、Agent TARS は汎用Agentランタイムに近く、UI-TARS Desktop はデスクトップGUI操作の入口に近いものです。

Agent TARS でできること

Agent TARS は主に CLI と Web UI を提供します。目的は、マルチモーダルモデルが MCP や各種ツールを通じて、人間の作業に近いタスクフローを実行できるようにすることです。

READMEにある主な機能は次の通りです。

ワンコマンドCLI起動。headful Web UI と headless server に対応。
GUI Agent、DOM、混合戦略によるブラウザAgent制御。
データフロー追跡とデバッグのための Event Stream。
MCP Server を接続して実ツールを呼び出す MCP 連携。

クイックスタート：

`1`	`npx @agent-tars/cli@latest`

グローバルインストール：

`1`	`npm install @agent-tars/cli@latest -g`

モデルプロバイダーを指定して実行：

1
2

agent-tars --provider volcengine --model doubao-1-5-thinking-vision-pro-250428 --apiKey your-api-key
agent-tars --provider anthropic --model claude-3-7-sonnet-latest --apiKey your-api-key

UI-TARS Desktop でできること

UI-TARS Desktop はデスクトップGUI Agentです。UI-TARS と Seed-1.5-VL / 1.6 系モデルをベースに、モデルが画面を理解し、マウスとキーボード操作を実行することに重点があります。

READMEにある機能は次の通りです。

自然言語による制御。
スクリーンショットと視覚認識。
精密なマウス・キーボード制御。
Windows、macOS、ブラウザのクロスプラットフォーム対応。
リアルタイムフィードバックと状態表示。
プライバシーと安全性を重視したローカル処理。

例として、VS Code 設定の変更、GitHub issue の確認、リモートPCやブラウザの操作などが挙げられます。

なぜ GUI Agent が重要なのか

従来の自動化は API、DOM、スクリプトに依存します。GUI Agent は画面から始めます。ボタン、入力欄、メニュー、状態を見て、マウスとキーボードで操作します。

価値は2つあります。第一に、多くのソフトウェアには安定したAPIがないか、APIが全フローをカバーしていません。GUI Agent は人間と同じ画面から操作できます。

第二に、マルチモーダルモデルはスクリーンショット、文書、Webページ、アプリ画面を扱えます。視覚理解と操作を組み合わせられます。

一方で制約もあります。GUI操作は解像度、言語、レイアウト変更、ポップアップ、ネットワーク遅延の影響を受けます。本番フローでは、権限管理、確認ステップ、ロールバックが必要です。

MCP との関係

Agent TARS は MCP 連携を重視しています。MCP は、ブラウザ、ファイル、コマンドライン、データベース、内部サービスなどを Agent が統一的に呼び出すために有用です。

複雑なタスクでは、GUIクリックだけでは安定しません。より良いパターンは次のようなものです。

API が使える場所では API を使う。
ページ状態を理解する必要があるときは視覚を使う。
実際のWeb操作が必要なときはブラウザ制御を使う。
ローカルソフトを操作する必要があるときは GUI Agent を使う。

UI-TARS-desktop のようなプロジェクトは、これらを1つのAgentスタックにまとめる方向を探っています。

使う前の注意点

まず、デスクトップAgentには実行リスクがあります。マウス、キーボード、ブラウザを操作できるため、ファイル、アカウント、支払い、本番システムを誤操作しないよう権限を制限する必要があります。

次に、リモートPCやリモートブラウザの操作には明確なセキュリティ境界が必要です。認証のない制御入口を公開ネットワークに出してはいけません。

最後に、マルチモーダルモデルは画面を誤認識する可能性があります。削除、送信、支払い、公開、取引など不可逆な操作では、人間の確認を入れるべきです。

向いている人

UI-TARS-desktop は、GUI Agentを試したい開発者、デスクトップ作業向けAIアシスタントを作るチーム、ブラウザ、DOM、MCP、視覚制御の戦略を比較したい研究者に向いています。まだ一般向けの単純なアシスタントというより、開発者向けの色が強いです。

まとめ

UI-TARS-desktop が注目に値するのは、AI Agent を「チャットで答える」段階から「画面を見てツールを操作する」方向へ進めている点です。価値はデスクトップ制御だけではなく、GUI、ブラウザ、ターミナル、MCP を1つのスタックにまとめるところにあります。

投稿先が多すぎて大変？AiToEarnはAI Agentでクリエイターの作業を減らそうとしている

Tue, 19 May 2026 10:56:50 +0800

yikart/AiToEarn は、クリエイター、ブランド、個人会社向けの AI コンテンツマーケティングプロジェクトです。コンテンツ作成、投稿、エンゲージメント運用、収益化を同じ Agent ワークフローにまとめ、Douyin、小紅書、快手、Bilibili、動画号、TikTok、YouTube、Facebook、Instagram、Threads、X、Pinterest、LinkedIn などを対象にしています。

プロジェクトURL：https://github.com/yikart/AiToEarn

公式サイト：https://aitoearn.ai/

執筆時点では、GitHub API上で約1.5万 star、主要言語は TypeScript、ライセンスは MIT でした。READMEでは、OPC（一人会社）、クリエイター、ブランド、企業向けのコンテンツマーケティングAgentプラットフォームと説明されています。

位置づけ

AiToEarn は単なる文章生成ツールでも、予約投稿ツールでもありません。コンテンツマーケティングを4つの Agent 能力に分けています。

Monetize：コンテンツ収益化。
Publish：複数プラットフォームへの投稿。
Engage：エンゲージメント運用。
Create：コンテンツ作成。

今のクリエイター業務では、「AIが文章を書けるか」だけでは足りません。生成後に投稿予約、分配、返信、振り返り、ビジネス施策との接続が必要です。

主な機能

Monetize：コンテンツ収益化

AiToEarn はプロモーションタスク向けの収益化機能を提供します。READMEでは次の3種類の精算モデルが挙げられています。

モデル	正式名称	意味
CPS	Cost Per Sale	売上に応じて精算
CPE	Cost Per Engagement	エンゲージメント量に応じて精算
CPM	Cost Per Mille	表示または再生量に応じて精算

この部分は、ブランドのプロモーション需要とクリエイターの配信力をつなぐコンテンツタスク市場に近いものです。

Publish：投稿Agent

Publish は複数プラットフォームへの配信を担当し、手作業で投稿する負担を減らします。READMEでは、中国内外の主要なショート動画、画像テキスト、SNSプラットフォームが対象として挙げられています。

実用面では、統一されたスケジュール管理と投稿管理が価値になります。アカウント群運用、クロスプラットフォーム配信、海外向けチームでは、単体のAI文章生成より役立つ場面があります。

Engage：エンゲージメントAgent

Engage はブラウザ拡張を通じて、いいね、保存、フォロー、コメント返信、ブランド監視などの自動化を支援します。

この機能は慎重に使う必要があります。自動エンゲージメントはプラットフォームのリスク制御に触れやすいため、アカウント権限、頻度制限、規約、チームのコンプライアンスを確認するべきです。

Create：コンテンツ作成Agent

Create は生成部分を担当します。READMEでは、動画生成モデル、動画翻訳、動画編集、画像生成、バッチ作成タスクが挙げられています。

大量制作には向いていますが、人間のレビューは必要です。ブランドコンテンツ、広告素材、多言語コンテンツでは、事実確認、著作権、トーンの一貫性が重要です。

5つの使い方

方法	向いている人	デプロイが必要か
Webサイトを直接使う	すべてのユーザー	不要
OpenClaw で使う	OpenClaw ユーザー	不要
Claude / Cursor などのAIアシスタントで使う	AIツールユーザー	不要
Dockerでワンクリック導入	セルフホストしたいチーム	サーバーが必要
ソースコード開発	開発者	開発環境が必要

MCP 対応は注目点です。Claude、Cursor、その他 MCP 対応 Agent が AiToEarn を外部機能として呼び出せます。

一般的な MCP 設定は次のような形です。

1
2

MCP URL: https://aitoearn.ai/api/unified/mcp
Auth Header: x-api-key: your-API-Key

セルフホストの場合は、自分のサービスURLに置き換えます。

Docker デプロイ

READMEには Docker による導入方法もあります。

1
2
3

git clone https://github.com/yikart/AiToEarn.git
cd AiToEarn
docker compose up -d

その後、次を開きます。

`1`	`http://localhost:8080`

データ管理、プライベート導入、独自ワークフローを重視するチームには、ホスト版だけでなく Docker 導入も現実的です。

向いている人

AiToEarn は、複数プラットフォームに投稿するクリエイター、小規模なコンテンツ運用チーム、一人会社、クリエイター連携が必要なブランド、コンテンツ業務をAI Agentにつなげたい開発者に向いています。

単純な文章生成だけが必要なら、やや大きすぎるかもしれません。価値は、作成、配信、反応、収益化をつなげる点にあります。

使う前の注意点

自動投稿や自動エンゲージメントは、プラットフォーム規約を守る必要があります。効率化できても、アカウント安全性やコンプライアンスは省略できません。

生成コンテンツにも人間のレビューが必要です。広告、ブランド投稿、多言語コンテンツには、事実、著作権、トーンのリスクがあります。

収益化機能は商業タスクに関わるため、精算ルール、表示義務、プラットフォームポリシーを確認してから使うべきです。

まとめ

AiToEarn が面白いのは、コンテンツ運用を単なる文章作成ではなくワークフローとして扱っている点です。クリエイターや小規模チームにとっては、複数プラットフォームの繰り返し作業を減らせることが魅力です。開発者にとっては、MCP と Agent 連携が見どころです。

Claude CodeでTokenを節約する：モデル、MCP、CLAUDE.md、Skillsがキャッシュに与える影響

Mon, 18 May 2026 18:30:24 +0800

Claude Codeの長いタスクでは、Prompt Cacheの命中率がコストと速度に直接影響する。キャッシュでTokenを節約できることは知られているが、どの操作で突然キャッシュが外れるのかは見落とされがちだ。

毎回のリクエストは、左から右へ流れるコンテキストの鎖として考えるとわかりやすい。

`1`	`tools -> system -> CLAUDE.md / skills -> messages`

左にある内容ほど安定させるべきで、キャッシュ効果も大きい。左側が変わると、その後ろのキャッシュも再計算されやすい。逆に右側の変化は影響範囲が小さい。

つまりClaude CodeのPrompt Cache最適化は、勘ではない。タスク開始前にモデル、MCP、Skills、CLAUDE.mdなどの基本コンテキストを準備し、開始後はできるだけ変えないことが重要だ。

Prompt Cacheは文字列そのものをキャッシュしない

Prompt Cacheは、プロンプト文字列をそのまま保存するだけの仕組みではない。Transformerモデルでは、前方のコンテキストを注意層で計算したKey/Value状態、つまりKV cacheが重要になる。

これは2つのことを意味する。

前方のコンテキストが安定していれば、後続リクエストで一部の計算結果を再利用できる。
モデル、ツール定義、システムプロンプト、前方メッセージが変わると、以前のキャッシュを再利用できないことがある。

Anthropic公式ドキュメントも、失効階層を tools -> system -> messages と整理している。ツール定義の変更は全体のキャッシュに影響し、system層の変更はsystemとmessagesに影響し、messages層の変更は主にメッセージキャッシュに影響する。

Claude Codeではさらに CLAUDE.md、Skills、MCP、プラグイン、subagentなどが関わるため、実際の利用ではキャッシュ失効点を踏みやすい。

キャッシュを壊す要因1：途中でモデルを切り替える

モデル切り替えは最も影響が大きい操作の一つだ。

Prompt Cacheはモデルごとに分離される。Opus、Sonnet、Haikuは構造や重みが異なるため、同じテキストから計算したKV cacheも共有できない。Opusで長いコンテキストを作ったあとSonnetへ切り替えても、SonnetはOpusのキャッシュを再利用できない。

そのため、節約のつもりで途中から安いモデルへ切り替えると、かえってそれまでのキャッシュが無駄になることがある。本来cache read価格で読めたコンテキストが、再度書き込みと計算の対象になる。

安定したやり方は次の通り。

メイン会話ではモデルを固定する。
安いモデルで処理したい支線タスクはsubagentに分離する。
支線エージェントに検索、探索、整理を任せ、要約だけをメイン会話へ戻す。

こうするとメインの長いコンテキストを動かさず、キャッシュ命中率を保ちやすい。

キャッシュを壊す要因2：途中でMCPを追加する、プラグインを再読み込みする

MCPはClaude Codeへツールを提供する。新しいMCPサーバーを追加するとツール一覧が変わる。ツール定義はコンテキスト鎖の最も左側にある。

Prompt Cacheの視点では、ツール一覧が変わると、その後ろのsystemとmessagesも再計算が必要になりやすい。MCPが多い場合、ツール定義そのものが多くのTokenを占めるため、失効コストは大きくなる。

ただし重要な細部がある。Claude Codeは通常、セッション起動時にMCP設定を読む。途中で設定を変えても現在のsessionにすぐ影響するとは限らない。本当に注意すべきなのは、再起動、resume、プラグイン再読み込み、ツール一覧の再構築が起きる場面だ。

おすすめは：

長いタスクの前に必要なMCPをまとめて用意する。
作業中に不足に気づいてインストールし、再読み込みする流れを避ける。
大きなMCPツールセットは必要時だけ使う、またはデフォルト有効数を減らす。
ほとんど使わないMCPを常時有効にしない。

ツール定義が安定していてこそ、Prompt Cacheは安定して命中する。

キャッシュを壊す要因3：途中でCLAUDE.mdを編集する

CLAUDE.mdはClaude Codeのプロジェクト記憶ファイルだ。ビルドコマンド、テストコマンド、設計上の約束、コードスタイル、プロジェクト固有の注意点を書くのに向いている。

便利だが、これもコンテキストに入る。Claudeのヘルプでは、CLAUDE.mdはセッション開始時に読まれ、ユーザーメッセージとしてClaudeへ渡されると説明されている。またAnthropicのPrompt Cacheも使われる。最初のリクエストでは通常の入力価格を払い、以後キャッシュが有効なら低いcache readコストで処理される。

問題は、CLAUDE.mdが内容で識別されることだ。ファイル内容を変えると、旧キャッシュとは一致しない。

そのため、長いタスクの途中で頻繁にCLAUDE.mdを編集しないほうがよい。より良い使い方は：

タスク開始前にCLAUDE.mdが十分か確認する。
安定したルールはファイルへ、臨時指示は現在の会話へ置く。
一度だけの要望のために長期記憶ファイルを編集しない。
どうしても変更するなら、次の段階を新しいsessionや新しいフェーズとして扱う。

CLAUDE.mdは安定したプロジェクト説明であり、毎回変えるメモ帳ではない。

キャッシュを壊す要因4：途中でSkillsをインストールまたは更新する

Skillsもコンテキストの一部だ。新しいSkillを入れる、Skillを更新する、Skill一覧が変わると、セッションへ注入されるコンテキストも変わる。

こうした変化は、reload、resume、新しいsessionで反映されることが多い。messagesが再構築されると、古いキャッシュは命中しにくくなる。

MCPと同じく、次のように扱うとよい。

タスク開始前に必要なSkillsを決める。
同じ種類のタスクではSkillセットを固定する。
長いタスクの途中でSkillsを追加しない。
新しいSkillを入れたら、新しい段階の始まりとして扱う。

コンテンツ作成、レビュー、デプロイ、翻訳など反復する作業では、よく使うSkillsを固定するとコンテキスト構造が安定する。

キャッシュを壊す要因5：TTLを超えてアイドルになる

Prompt Cacheは永久に保存されない。一般的なデフォルト有効期間は数分程度で、Claude Code関連の説明でも約5分のキャッシュウィンドウが言及されることがある。TTLを過ぎると、同じリクエストでもサーバー側でキャッシュが消えている可能性がある。

長いタスクで「さっきまで安かったのに、少し離席したらTokenが増えた」と感じる原因はこれだ。

Claude Codeの出力を読む、ファイルを確認する、テストを走らせる、次の手を考える。こうした作業だけで5分はすぐ過ぎる。

環境が対応しているなら、長いタスクの前に1時間のPrompt Cache TTLを有効化できる。

`1`	`export ENABLE_PROMPT_CACHING_1H=1`

Windows PowerShellでは：

`1`	`$env:ENABLE_PROMPT_CACHING_1H="1"`

1時間キャッシュの書き込みコストは、通常5分キャッシュより高くなる。短いタスクには向かないこともあるが、大規模コードベース、長い会話、複雑な多段階開発では、頻繁にキャッシュが切れるより安くなる場合がある。

Tokenを節約しやすいClaude Code長タスクの組み方

安定した流れはこうだ。

タスク開始前にモデルを決め、頻繁に切り替えない。
必要なMCPを有効にし、不要なMCPは切る。
CLAUDE.mdは短く、安定した、長期的に有効なルールに絞る。
今回必要なSkillsを事前に準備する。
複雑なタスクでは1時間TTLを検討する。
大きなタスクは段階に分けるが、各段階の内部ではコンテキスト構造を安定させる。
支線探索はsubagentや別sessionで行い、メイン会話を汚さない。

目的はすべてのキャッシュミスをなくすことではない。見落としやすく、コストの高い失効を避けることだ。

簡単な判断基準

次の一文で判断できる。

この操作はモデル、ツール定義、システムコンテキスト、またはセッション冒頭の固定メッセージを変えるか？

答えがはいなら、Prompt Cacheに影響する可能性が高い。コンテキスト鎖の左側に近いほど影響は大きい。

よくある操作はこう整理できる。

モデル切り替え：高リスク。モデルごとにキャッシュが分離される。
MCP追加またはプラグイン再読み込み：高リスク。ツール一覧が変わる。
CLAUDE.md編集：中高リスク。プロジェクト記憶が変わる。
Skillsインストール：中高リスク。注入コンテキストが変わる。
通常の会話継続：低リスク。主にmessagesを追加するだけ。
TTL超過のアイドル：高リスク。サーバー側キャッシュが期限切れになる。

まとめ

Claude CodeのPrompt Cache最適化で大事なのは、パラメータを暗記することではなく、sessionの前方コンテキストを安定させることだ。

モデルを気軽に切り替えない。MCPやSkillsを作業途中で増やさない。CLAUDE.mdを臨時メモとして頻繁に編集しない。複雑なタスクではTTL延長を検討する。これらを守るだけで、長いタスクのTokenコストと応答速度はかなり予測しやすくなる。

実用的な一言にすると、始める前に整え、始めた後はあまり動かさない。

参考資料

easy-vibe：Vibe Coding初心者のための学習マップ

Sat, 16 May 2026 22:44:43 +0800

easy-vibe は、Datawhaleが公開しているVibe Coding学習プロジェクトです。対象は、すでにAIコーディングツールを使いこなしている開発者ではありません。Vibe Codingに触れ始めたばかりの学生、プロダクトマネージャー、デザイナー、運用担当者、個人開発者、技術好きの一般ユーザーです。

このプロジェクトの価値は、また別のAIツール一覧を作っていることではありません。「AIでどうやってプロジェクトを作り始めるか」を、より理解しやすい学習パスに分解していることです。多くの初心者にとって本当に難しいのは、Claude Code、Cursor、MCP、Agentの存在を知らないことではありません。最初に何を学び、どう練習し、いつ高度なツールに進むべきかが分からないことです。

Vibe Coding初心者に最も足りないのは道筋

Vibe Codingはここ数年注目されていますが、初心者にとって親切とは言えません。

表面上は、要件を説明できればAIにコードを書かせられるように見えます。実際には、タスクが少し複雑になるだけで問題が出ます。要件が曖昧、モデルが違うファイルを編集する、プロジェクト構造が分からない、エラーを処理できない、依存関係が入らない、プロンプトがどんどん乱れる。最後には「コードをチャットボックスにコピーする」状態へ戻ってしまいます。

そのため、Vibe Coding入門は「プロンプトの書き方」だけでは足りません。少なくとも次のことを解決する必要があります。

アイデアを実行可能なタスクに分ける方法。
AIにプロジェクト構造を理解させる方法。
モデルが生成したコードを読む方法。
エラーを処理し、反復する方法。
ターミナルとローカル開発環境を使う方法。
Webチャットから実際のAIコーディングツールへ移行する方法。

easy-vibeの意味はここにあります。ツール、チュートリアル、用語の中で初心者を迷わせるのではなく、これらを1つの学習ルートとして整理しようとしています。

単発チュートリアルではなくロードマップ

プロジェクト説明を見ると、easy-vibeは基礎チュートリアル、インタラクティブ演習、可視化コンテンツ、RAG、ターミナルツール、AIコーディングツール、さらにClaude Code、MCP、Skills、Agent Teamsなどの発展トピックを扱っています。

この構成は初心者に向いています。AIコーディングは単一のスキルではなく、複数の能力の組み合わせだからです。

要件を説明する。
タスクを分ける。
プロジェクトを読む。
モデルにコードを編集させる。
実行し、検証する。
エラーに基づいて反復する。
よく使う流れをツールやスキルとして蓄積する。

特定のツールだけを学ぶと、そのツールの画面に縛られやすくなります。モデル、エディタ、CLIが変わると、また何をすればよいか分からなくなります。ロードマップの利点は、先に作業方法を身につけ、その後でツールを適切な場所に置けることです。

非プログラマーに特に役立つ

Vibe Codingの最大の魅力は、専門プログラマーでなくてもプロトタイプを作れることです。

プロダクトマネージャーは製品アイデアをインタラクティブなdemoにできます。デザイナーはインタラクションのロジックを検証できます。運用担当者は社内ツールを書けます。学生は授業プロジェクトを素早く作れます。起業家は初期段階で需要を検証できます。こうした人たちは、従来の意味でフルタイムエンジニアになる必要はないかもしれませんが、「AIに手伝わせてアイデアを形にする」方法を持つ必要があります。

これが、easy-vibeが中国語コミュニティに合っている理由でもあります。多くの中国語ユーザーは、AIがコードを書けることをすでに知っています。しかし、開発環境、プロンプト、プロジェクト構造、デバッグ方法、Agentツールの使い方を体系的に学べる入門資料はまだ不足しています。中国語で明確に説明され、演習と一緒に進められることには意味があります。

この種のユーザーにとって最も重要なのは、最初から複雑なフレームワークを学ぶことではありません。まず、要件を出す、プロジェクトを生成する、動かす、問題を見つける、修正を続ける、最終的に使えるものを得る、という一連のループを回すことです。

発展部分は実際のAI開発ワークフローに近づく

easy-vibeで触れられているClaude Code、MCP、Skills、Agent Teamsは、もはや単なる入門概念ではありません。

Claude Codeはターミナル型コーディングAgentを表します。モデルがローカルプロジェクトに入り、ファイルを読み、コードを変更し、コマンドを実行できます。MCPはツールとデータソースの接続を解決し、モデルをチャットボックス内に閉じ込めません。Skillsは、固定のプロジェクト生成、文書整理、テストチェック、コンテンツ制作などの再利用可能な流れを蓄積します。Agent Teamsはさらに、タスクを複数の智能体へ分割します。

これらは初心者には少し遠く感じるかもしれません。それでも早めに知っておく価値があります。Vibe Codingの方向性は明確だからです。「AIに一部のコードを書かせる」段階から、「AIに完全なプロジェクトフローへ参加させる」段階へ向かっています。

学習ルートがプロンプトだけで止まると、ツールの進化についていけません。一方で、最初からすべての高度な概念を初心者に投げると、どこから始めればよいか分からなくなります。easy-vibeの良さは、それらを段階的なアップグレードの道筋に置いていることです。

学習時に避けたい2つの誤解

1つ目は、Vibe Codingならコードが分からなくても完全にコードを気にしなくてよい、と思うことです。

AIは多くのものを生成できますが、ユーザーは結果が正しいか判断する必要があります。少なくとも、プロジェクト構造を理解し、どう実行するかを知り、エラーがどこで起きているかを大まかに把握する必要があります。複雑なコードを書かなくても、基本的なエンジニアリング常識は必要です。

2つ目は、高度なツールほど良いと思うことです。

初心者が最初からClaude Code、MCP、複数Agentを必要とするとは限りません。より良い順序は、まず簡単なプロジェクトでフィードバックループを作り、その後でターミナル、バージョン管理、テスト、ツール呼び出し、自動化フローを少しずつ導入することです。ツールはタスクの複雑さに合わせるべきです。そうでなければ「強そうだが何に使うか分からない」ものになります。

どう使うとよいか

Vibe Codingに触れ始めたばかりなら、easy-vibeを学習チェックリストとして使えます。

まず基礎概念と簡単な演習から始めます。すべてのツールを追う必要はありません。個人ホームページ、データダッシュボード、フォームツール、自動化スクリプト、知識ベースdemoなど、小さなプロジェクトを1つ作ります。その過程で、AIがどこで助けになるか、どこは自分で確認すべきかを観察します。

小さなプロジェクトを安定して完成できるようになったら、より複雑な内容に進みます。

ターミナルツールでローカルプロジェクトを扱う。
Gitで各変更を管理する。
RAGで自分の資料を接続する。
MCPで外部ツールを接続する。
Skillsで反復作業を固定化する。
Agent Teamsで複雑なタスクを分割する。

このように学ぶVibe Codingは、単にAIへ質問することではありません。AIを自分のワークフローに入れることです。

まとめ

easy-vibeは、Vibe Codingの中国語入門マップとして見るのがよいでしょう。散らばったAIコーディングの概念、ツール、演習を1つの道筋にまとめ、初心者が「AIはコードを書けるらしい」から「AIでプロジェクトを作れる」へ進みやすくしています。

Vibe Codingの本当の価値は、すべての学習を飛ばせることではありません。アイデアからプロトタイプまでのハードルを下げることです。要件を理解し、タスクを整理し、結果を検証し、リスクを制御する必要は残ります。ただし、多くの反復的で退屈で詰まりやすい手順は、AIに手伝わせることができます。

AIコーディングに体系的に入門したいが、最初からツール名や複雑な開発設定に埋もれたくないなら、easy-vibeは保存しておきたい出発点です。

Anthropic financial-services：金融Agentの場面を再利用可能なテンプレートにする

Sat, 16 May 2026 22:43:08 +0800

anthropics/financial-services は、金融サービス業界向けにAnthropicが公開した参考プロジェクトです。単一のアプリケーションではなく、個別に学習・再利用できる例の集合です。Agents、Plugins、Skills、MCPコネクタ、そして金融ワークフロー向けに設計されたプロンプトや統合パターンが含まれます。

このプロジェクトが注目に値するのは、「万能な金融アシスタント」を提供しているからではありません。金融業界でよくあるAI導入課題を、より具体的な部品へ分解しているからです。職種ごとにどのAgentが必要か、どのデータソースを接続するべきか、どの作業を自動化できるか、どの段階では人間の判断が残るべきかを示しています。

金融Agentのショールームに近い

企業がAI Agentを語るとき、話は抽象的になりがちです。ファイルを読む、データを調べる、レポートを書く、ツールを呼ぶ、といった表現です。しかし金融の場面に入ると、問題はずっと具体的になります。

投資銀行のアナリストは会社資料を整理し、取引ブリーフを作成し、類似企業を比較する必要があります。株式リサーチでは財務資料を読み、ニュースを追い、バリュエーションとリスク分析を行います。プライベートエクイティや資産運用チームは案件をスクリーニングし、memoを書き、ポートフォリオ企業を追跡します。ウェルスマネジメントでは、顧客像、市場情報、投資提案をコンプライアンスの枠組みに入れる必要があります。

こうした場面は、汎用チャットボックスだけでは対応できません。役割、プロセス、データソース、出力形式、権限境界が必要です。このAnthropicリポジトリの価値は、金融サービス業界の複数の典型的な役割とタスクを、参考にできるAgentテンプレートへ分解している点にあります。

なぜAgents、Plugins、Skills、MCPを同時に提供するのか

プロジェクト構成を見ると、Anthropicは単にプロンプト一式を提供しているわけではありません。複数種類のコンポーネントを同時に提供しています。これは、企業がAgentを導入するときの複数の層に対応しています。

Agentsは、役割やタスクに向けた作業単位に近いものです。そのAgentが何をするのか、どう進めるのか、いつツールを呼ぶのか、どのように出力するのかを定義します。

Pluginsは外部能力の拡張に近いものです。金融業務はモデル内部だけで完結することが少なく、データベース、文書システム、市場データ、CRM、リサーチライブラリ、社内ワークフローシステムとつながる必要があります。

Skillsは再利用可能な専門能力パッケージです。固定形式の分析フレームワーク、レポート構造、チェックリスト、データ処理手法は、毎回プロンプトを書き直すのではなく、スキルとして蓄積できます。

MCPコネクタは、ツール接続とコンテキスト標準化の問題を解きます。企業にとって、ツールが増えるほど比較的統一された接続方式が必要になります。そうでなければ各システムを個別に適配する必要があり、保守コストが高くなります。

これらを組み合わせて初めて、実際の企業AIワークフローに近づきます。

金融業界がAgent例に向いている理由

金融サービスはAgentを示す業界として向いています。3つの特徴を同時に持っているからです。

第一に、情報密度が高いことです。金融業務は財務資料、公告、会議メモ、リサーチレポート、取引データ、顧客資料、規制文書に大きく依存します。モデルが一般知識だけに頼ると、すぐに役に立たなくなります。実データソースへの接続が必要です。

第二に、出力形式が安定しています。投資メモ、会社概要、KYC文書、リサーチ要約、顧客ブリーフ、ファンド運用レポートには比較的固定された構造があります。これにより、Agentは検証可能なワークフローを作りやすくなります。

第三に、リスク境界が明確です。金融業界ではコンプライアンス、監査、権限、追跡可能性への要求が高いです。AIは気軽に投資助言をしたり、承認プロセスを迂回したりできません。むしろこの制約が、Agent設計をよりエンジニアリング寄りにします。引用を残し、事実と推論を分け、ツール呼び出しを記録し、実行可能な操作を制限する必要があります。

そのため、このプロジェクトは金融会社だけのものではありません。企業向けAgentを作りたいチームなら、Anthropicが業界場面をどう分解しているかを観察できます。

対象となる典型的なワークフロー

プロジェクト説明によると、このリポジトリは複数の金融サービス領域を扱っています。

投資銀行;
株式リサーチ;
プライベートエクイティ;
ウェルスマネジメント;
ファンド運用;
KYCとコンプライアンス関連ワークフロー。

これらのワークフローには共通点があります。大量の読解、整理、比較、構造化資料の生成が必要です。ここでAIが最も向いているのは、直接判断を下すことではなく、情報処理と文書作成にかかる時間を減らすことです。

たとえば投資銀行の場面では、Agentは対象会社の資料を整理し、主要な財務指標を抽出し、取引要約の初稿を作れます。リサーチでは、財務資料やニュースを先に読み、重要な変化と確認すべき論点を列挙できます。KYCでは、資料がそろっているか、異常な手がかりがないかを確認する補助ができます。

最終判断は専門家が担うべきです。Agentの役割は、助手、アナリスト、ワークフロー加速装置に近いものです。

企業導入への示唆

このリポジトリで最も参考になる点は、「モデル能力」を「業務コンポーネント」に変えていることです。

企業内でAIプロジェクトを進めると、よく同じ問題にぶつかります。モデルのデモは見栄えが良いのに、実業務へ接続すると再利用しにくい。あるチームがプロンプトを書き、別のチームがまた別のプロンプトを書く。あるシステムがデータベースに接続し、別のシステムがまた独自のインターフェースを作る。セキュリティと監査の要件も散らばります。

より堅実なのは、能力をいくつかの資産に分けることです。

職種向けのAgent;
プロセス向けのSkills;
システム接続向けのMCPコネクタ;
権限と監査向けの実行ルール;
業務出力向けのテンプレートとチェックリスト。

こうすれば、企業は毎回「チャットボットを作る」ところから始める必要がありません。保守できるAIワークフロー資産を少しずつ蓄積できます。

コンプライアンスと責任境界は無視できない

金融Agentで最も誤解されやすいのは、「分析を生成できる」ことを「意思決定を代替できる」と見なすことです。

金融サービスでは、AIの出力は通常、補助材料として扱うべきです。事実を整理し、草稿を生成し、リスクを示し、文書を補完することはできます。しかし投資調査、リスク管理、法務、コンプライアンス、顧客適合性の要件を迂回することはできません。特に投資助言、取引判断、顧客資産配分、本人確認に関わる場合、人間による承認と責任の連鎖は必ず残す必要があります。

だからこそ、企業向けAgentは回答品質だけで評価できません。次の点も見る必要があります。

データソースは信頼できるか。
引用と証拠は追跡できるか。
ツール呼び出しは記録されるか。
機密データは制限されるか。
出力は人間が確認しているか。
誤った結果を発見し、戻せるか。

これらが解決されないままAgentが自動化されるほど、リスクの半径は大きくなります。

まとめ

anthropics/financial-servicesは、開封してすぐ使う金融製品というより、金融Agentの参考実装に近いものです。Anthropicが企業AI導入をどう考えているかを示しています。汎用チャット助手だけを作るのではなく、具体的な役割、具体的なプロセス、具体的なデータソース、具体的な権限境界に沿ってAgentを組織するという考え方です。

金融機関にとっては、社内AIワークフロー設計の参考になります。開発者にとっては、企業向けAgentアーキテクチャを観察するサンプルです。Agentsは役割とタスクを担い、Skillsは専門プロセスを蓄積し、PluginsとMCPは外部システムを接続し、最終的にモデルを実業務フローに入れます。

初期のAIツールが「どうすればモデルに質問へ答えさせるか」を解いたのだとすれば、この種のプロジェクトは「どうすればモデルを制御された境界内で仕事に参加させるか」を重視しています。そこにこそ、企業向けAgentの本当の難しさがあります。

AI Agentはどう進化したのか？2022-2026年の5世代を整理する

Sat, 16 May 2026 19:19:52 +0800

AI Agentは一夜で生まれたものではありません。

2022年末、ChatGPTはまだ会話できるウィンドウに近い存在でした。2026年になると、Agentはツール呼び出し、ファイル操作、コンピューター制御、長期記憶、リモート協業、常駐実行に近い能力を持ち始めています。4年間で、質問に答えるモデルから、タスクを前に進めるデジタルワーカーへ近づきました。

時系列で見ると、AI Agentは大きく5世代に分けられます。各世代は前の世代の欠点を解決しながら、新しいバブルと安全上の課題も生みました。

概観：5世代のAgentタイムライン

段階	時期	キーワード	能力の変化	主な問題
第0世代	2022年末 - 2023年初	チャット画面	テキスト生成はできるが行動できない	モデルと現実世界が切断されている
第1世代	2023年中頃 - 2023年末	ツール呼び出し	構造化呼び出し、APIとRAG接続	開ループ実行とタスク迷走
第2世代	2023年末 - 2024年	工程化ワークフロー	計画、状態、反省、複数Agent協業	ワークフローがコピーされやすい
第3世代	2024年 - 2025年	Computer Use	画面を見てGUIを操作	権限、安全、誤操作リスク
第4世代	2025年 - 2026年	MCP / Skills / 常駐	ツールネットワーク、長期文脈、専門スキル	常駐実行でリスク半径が拡大
第5世代予測	2026年以降	閉ループと世界モデル	記憶、検証、物理行動の強化	ガバナンスがさらに難しくなる

2022年末：第0世代、ChatGPTチャット画面の時代

第0世代の起点は、2022年11月30日のChatGPT公開です。

この世代はまだ本当のAgentとは言えません。自然言語生成は強力でしたが、主にチャット画面の中に閉じ込められていました。Pythonコードを書くことはできても、あなたのPCで実行できない。旅行計画は作れても、サイトを開いて予約できない。ファイルの直し方は説明できても、ファイルシステムに入って変更できない。

能力の境界は明確でした。

自然言語を理解できる
記事、回答、コード、計画を生成できる
最新データに自分でアクセスできない
企業内部資料を安定して読めない
外部アクションを実行できない
長期タスク状態を管理できない

第0世代の核心は、モデル能力と現実世界の断絶でした。考えて話すことはできるが、行動できない。

この段階では、プロンプトエンジニア、プロンプトテンプレート市場、講座、認定といった最初のバブルも生まれました。初期モデルがpromptに敏感だったのは事実ですが、市場は一時的な補助を長期的な堀と誤解しました。

その後、GPT-4級モデル、system prompt、function calling、製品側の標準導線が成熟し、多くのプロンプトテンプレートは希少性を失いました。このパターンは繰り返されます。新能力が出ると中間層が爆発し、次世代システムがその能力を内蔵すると中間層は蒸発します。

2023年中頃：第1世代、ツール呼び出しの覚醒

第1世代のキーワードはツール呼び出しです。

2023年6月、OpenAIはfunction callingを公開しました。開発者は関数名、用途、引数型、JSON Schemaをモデルに説明できます。モデルはユーザーの要求を理解したうえで、通常の自然言語ではなく構造化JSONを出力し、外部システムがそれを実行します。

これは大きな構造変化でした。モデルは「話すだけの脳」から、外部ツールを動かす脳へ変わり始めました。

第1世代の能力は次の通りです。

ユーザー意図に応じてツールを選ぶ
構造化引数を出す
外部APIを呼び出す
API結果をモデルに戻して推論を続ける
RAGで外部知識に接続する
プラグインや知識ベースで初期personaを作る

同時期にRAGとベクトルデータベースも流行しました。モデルが最新情報、企業固有資料、内部知識を知らない問題を補うため、関連文書を検索し、文脈に注入して回答させる方式です。

この頃、Agentの基本構造が見えてきました。

あなたは誰か：system promptとpersona
何を知っているか：知識ベース、RAG、私有文書
何ができるか：function calling、プラグイン、外部API

代表的なバブルはAutoGPTです。ユーザーが大きな目標を与えると、AIがタスク分解、検索、ファイル作成、評価、ループを行い、自分で完了判断するという魅力的な構想でした。

しかしAutoGPTはすぐに問題を露呈しました。状態制約、終了条件、信頼できるフィードバックが不足し、間違った方向に進み続けたり、誤ったAPI引数を繰り返したり、大量のAPIコールでコストを燃やしたりしました。第1世代の教訓は明確です。ツールと無限ループだけでは、本番品質のAgentにはなりません。

2023年末から2024年：第2世代、工程化ワークフロー

AutoGPTの失敗は、モデルの自由行動だけに頼れないことを業界に示しました。複雑なタスクには構造化されたプロセスが必要です。

第2世代のキーワードは工程化ワークフローです。Agentは単発のモデル呼び出しではなく、状態、制御フロー、評価を持つソフトウェアシステムになりました。

主な能力は次の通りです。

タスク計画：大きな目標をステップに分解
状態管理：作業がどこまで進んだかを記録
反省と修正：生成後に評価し、修正する
ツール編成：複数ツールを切り替える
人間の確認：重要な節目で人に確認する
複数Agent協業：異なる役割に分担させる

典型例はReAct、つまりReasoning + Actingです。モデルが推論し、ツールを呼び出し、観察結果を受け取り、次の推論に進みます。Agentは盲目的に動かず、各ステップに監査可能な論理とフィードバックを持ちます。

第2世代の価値は、モデル能力を制御可能なプロセスに入れたことです。よく設計されたworkflowは、単発の大規模モデル呼び出しよりも安定した成果を出すことがあります。

一方で、低コードAgentプラットフォームのバブルも生まれました。ドラッグ&ドロップでprompt、RAG、プラグイン、フローを組み合わせるツールは構築の敷居を下げました。しかし、ワークフローが低コストでコピーできるなら、プラットフォーム自体の堀は弱いです。

早期需要を取れることと、長期的な壁を持つことは別です。

2024年から2025年：第3世代、Computer Useが実画面に入る

第3世代のキーワードはComputer Useです。

以前のツール呼び出しは主にAPIに依存していました。何ができるかは開発者が何を接続したかに依存します。しかし現実のソフトウェアには、きれいなAPIがない、公開されていない、不完全である、といったものが多くあります。

Computer Useは、モデルが画面を見て、クリックし、GUIを操作できるようにします。汎用的なコンピューター画面そのものがツールになります。

主な能力は次の通りです。

画面内容の認識
ボタンのクリック、文字入力、ウィンドウ切り替え
Webとデスクトップアプリの操作
リポジトリの読解、ファイル編集、テスト実行
端末出力とエラーの確認
実際のエンジニアリング助手に近づく

これにより、Agentは「接続済みツールの呼び出し」から「人のようにソフトウェア画面を操作する」方向に進みました。coding agentも、プロジェクトを読み、コードを直し、テストを走らせ、エラーから修正する流れに近づきます。

しかし信頼境界も広がります。AIがPCを操作するなら、誤クリック、誤削除、誤送信があり得ます。Webページ、文書、UI文言による誘導もあります。prompt injectionは会話上の問題だけでなく、ファイル操作、権限、システム安全の問題になります。

第3世代の教訓は、実操作に近づくほど、サンドボックス、承認、ロールバック、最小権限が必要になることです。

2025年から2026年：第4世代、MCP、Skills、常駐デジタルワーカー

第4世代のキーワードは、常駐、接続、記憶、専門化です。

この世代の焦点は、単発タスクの強化だけではありません。Agentは長期文脈、ツールネットワーク、専門スキル、時間感覚を持ち始めます。一回のチャット内の助手ではなく、継続して働けるデジタルワーカーに近づきます。

MCPはツール接続の問題を解きます。ファイルシステム、データベース、ブラウザ、設計ツール、プロジェクト管理ツール、企業システムを標準化された方法で接続できます。プロトコルが安定すると、単なるツール接続中間層は圧縮されます。

Skillsは専門的方法の問題を解きます。ツールはAgentに何ができるかを伝え、Skillsはどう進めるべきかを伝えます。良いskillはpromptではなく、領域の手順、制約、チェック方法、落とし穴、ツール呼び出し順をまとめたものです。

第4世代の能力は次の通りです。

長期記憶：ユーザー嗜好、プロジェクト規則、履歴を保存
プロジェクト文脈：リポジトリ、文書、作業規約を理解
ツールネットワーク：MCP、API、ブラウザ、ファイルシステムで外界に接続
専門スキル：Skillsでタスク手法をパッケージ化
常駐実行：待機、起床、通知、追跡
リモート協業：別デバイスから承認や方向修正が可能

この世代のAgentは「従業員らしさ」を持ち始めます。役割と責任境界、長期文脈、専門的な作業方法、時間感覚、ツール権限、無人時の継続実行です。

しかし能力が従業員に近づくほど、リスク半径も従業員に近づきます。常駐、ローカルデータ読み取り、秘密情報、ツール呼び出し、タスク処理により、安全問題は中心課題になります。

特に重要なのは、テキストも攻撃面であることです。AgentがMarkdown、説明文書、skill pack、Webページを読んで従うなら、悪意あるテキストが行動を変える可能性があります。prompt injectionは、サプライチェーン、権限、実行安全の問題になります。

第4世代の教訓は、常駐Agentには能力だけでなくガバナンスが必要だということです。

2026年以降：第5世代予測、閉ループ、内在記憶、世界モデル

第5世代はまだ確定した歴史ではありません。前の4年の流れからの予測です。

成熟したAgentには少なくとも3つの閉ループが必要です。

実行ループ：各操作後に結果を検証し、必要ならロールバック、修正、再試行する
時間ループ：複数の起床周期をまたいで長期目標を追跡する
認知ループ：確実な情報、推測、古い情報を区別する

次の方向は内在記憶です。これまでの記憶は、RAG、ベクトルDB、会話履歴、ローカルファイル、memory.mdのようにモデル外部にありました。将来のモデルが会話をまたいだ持続状態を持つなら、Agentの記憶システムは再設計されます。

第三の方向は世界モデルです。現在の多くのAgentは、観察、反応、再観察という反応型です。高リスクな作業では、行動の結果を事前にシミュレートする力が必要です。

第四の方向は具身化です。これまでの世代は主にデジタル空間で進化しました。API、画面、ファイル、ブラウザ、企業ツールです。次は、ロボット、デバイス制御、産業システム、物理インターフェースへ広がる可能性があります。

第5世代が解くべき問題は、Agentがタスクを実行するだけでなく、行動結果を理解し、長期状態を管理し、大きなリスク半径の中で信頼性を保つことです。

このタイムラインの背後にある6つの法則

第一に、基盤モデル能力は依然として天井です。Agentは大規模モデルの外にある魔法ではなく、モデル能力を工程システムで解放する方法です。

第二に、工程化された構造はモデル能力を増幅します。計画、検証、反省、修正、評価、権限管理は、単発生成よりも納品可能な結果に近いです。

第三に、オープンプロトコルは価値分配を変えます。MCP、Skills、プロジェクト文脈の標準が安定すると、競争はツール接続から領域能力の蓄積へ移ります。

第四に、Agent進化の隠れた主線は人間と機械の信頼境界の拡大です。テキスト、API、ワークフロー、PC操作、常駐実行へと、各世代でリスク半径が広がります。

第五に、各世代の事故は次世代の規則になります。AutoGPTの無限ループは構造化編成を促し、vibe codingの失敗は評価駆動開発を促し、本番削除事故は最小権限とサンドボックスを促します。

第六に、Agentエコシステムは爆発と絶滅を繰り返します。能力更新は一時的な中間層を作り、モデルやプラットフォームの内蔵化がそれを消します。時間窓を堀と誤解するのは危険です。

本当の堀

AI Agent領域の本当の堀は、新しい能力を最初に包装することではありません。

より信頼できる堀は3つです。

第一に、垂直領域の深さ。業界の流れ、リスク、例外、責任境界を本当に理解しているか。

第二に、データフライホイール。実利用から高品質なフィードバックを集め、プロセス、評価、微調整、製品判断を改善できるか。

第三に、ユーザー信頼。ユーザーが高価値で長期的、リスクのある仕事を任せるか、一回限りのツールとして扱うか。

プラットフォームや基盤モデルに能力が吸収された後も、プロセス、フィードバック、責任境界、信頼が残る製品だけが生き残りやすいです。

最後に

2022年から2026年までのAI Agent進化は、「モデルが会話上手になった」話ではありません。「人間がAIに任せる仕事が増えた」話です。

成熟したAgentとは、最も大胆に自動実行するシステムではありません。いつ実行し、いつ検証し、いつ止まり、いつ人に確認するかを知るシステムです。

あるAgent製品に長期価値があるかを判断するなら、こう問うべきです。次のモデルやプラットフォームがその能力を内蔵した後、何が残るのか。

答えが領域プロセス、実データ、検証可能な結果、ユーザー信頼なら、長期価値があるかもしれません。

Claude を Fusion 360 に接続する：AI で STEP モデルを修正する実例

Thu, 14 May 2026 20:58:04 +0800

Claude を Fusion 360 に接続すると、単に「考え方を説明する」だけでなく、CAD モデルの修正に直接参加できる。典型的な流れは、既存の STEP ファイルを開き、Claude に現在のモデルを読ませ、構造上の干渉を分析させ、寸法を計画させたうえで、Fusion プラグイン経由でモデリング変更を実行することだ。

ここでは、遊星ギア分度器の修正を例に、Claude + Fusion 360 の基本的な使い方を整理する。

まず Fusion 360 の API/MCP サービスを有効にする

Fusion 360 で最初に基本設定を行う。

右上の Preferences を開く。
General または「通用」設定に入る。
API オプションを見つける。
MCP server を有効にする。
ポート番号を控える。デフォルト例は 27182。

次に Claude に戻り、Connectors に入り、Fusion コネクタを見つけて、Fusion 360 のアドレスとポートを入力する。通常はデフォルトの 27182 でよい。

接続に成功すると、Claude は Fusion プラグインを通じて、現在開いているモデルとやり取りできる。

STEP ファイルを開き、修正目標を明確にする

今回修正するのは、遊星ギア分度器の中の一つのギアだ。元の設計では、このギアは一本のねじを中心軸としてブラケットに固定されている。

目標は、それをベアリング構造へ変更することだ。

中心穴をベアリングに合わせる；
周囲のねじ穴が拡大した中心穴と干渉しないようにする；
ブラケット上のタッピングねじ穴も、ベアリング回転に適した軸構造へ調整する；
最終モデルはスライサーに読み込め、3D プリントに使えるようにする。

重要なのは、Claude に「ちょっと直して」とだけ言わないことだ。用途、組み立て方法、材料、製造方法をはっきり伝える必要がある。

Claude はスクリーンショットで現在のモデルを理解できる

Fusion プラグインはコマンドを実行するだけで、Claude にモデルを見せられないのではないか、と心配する人もいる。実際のテストでは、Claude はスクリーンショットを通じて現在のモデル状態を認識できた。

このケースでは、Claude はギア構造を確認し、次のような作業を行えた。

ギアと中心穴を識別する；
関連寸法を測定または推定する；
ベアリング寸法を提案する；
ベアリング取り付けに影響する構造を判断する；
中心穴を拡大すると、周囲のねじ穴と幾何干渉が起きる可能性を見つける。

このステップは重要だ。Claude が文字の指示だけで盲目的に修正しているのではなく、現在のモデルビューと構造判断を組み合わせられることを示している。

材料と加工方法は事前に伝える

最終的に 3D プリントするモデルなら、材料と工法を明確に Claude に伝える必要がある。

たとえば PLA でプリントする場合、ベアリング穴を CNC 金属加工の公差そのままで設計してはいけない。直径 6mm のベアリングを圧入するなら、穴径を約 6.1mm にすることを検討できる。この寸法が適切かどうかは、プリンター精度、材料収縮、スライサー設定、実際のテストによって調整する必要がある。

材料を伝えないと、Claude は CNC 加工の考え方で寸法を出す可能性がある。その場合、3D プリントでは穴が小さすぎ、後の組み立てが難しくなる。

プロンプトには次のように書くとよい。

1
2
3

このモデルは FDM 3D プリント用で、材料は PLA です。
目標は直径 6mm のベアリングを取り付けることで、プリント公差と圧入を考慮してください。
CNC 金属加工の公差として扱わないでください。

Claude にギア構造を修正させる

目標が明確になったら、Claude に具体的な修正を実行させる。

中心穴を拡大する；
干渉する周囲のねじ穴を調整する；
ベアリング取り付け座を追加する；
エッジに面取りを加える；
ギア本体と重要な噛み合い構造は維持する。

このケースでは、Claude はまず計画を出し、その後 Fusion 360 を呼び出してモデリング操作を行った。たとえば、元のねじ穴と中心穴が衝突すると判断した後、穴位置を少し外側へ移動し、ベアリング取り付け空間を壊さないようにした。

修正後は、モデルを確認する。

中心のベアリング座が正しく形成されているか；
周囲の穴が機能を維持しているか；
ギア構造が誤って壊れていないか；
面取りが組み立てに影響しないか；
オーバーハング、薄肉、スライス上のリスクがないか。

ブラケットも一緒に修正する

ギアだけを変更しても足りない。元のブラケットにはタッピングねじ用の取り付け穴がある。ギア中心をベアリングに変更するなら、ブラケット側もベアリング軸構造へ合わせる必要がある。

Claude にブラケットにも同様の修正をさせられる。

全体の取り付け位置を維持する；
元のタッピングねじ穴を円柱状の軸に変更する；
軸の直径と高さを制御する；
ベアリング回転のための空間を確保する；
ブラケットの他構造との干渉を避ける。

こうしてプリントすると、ギアはベアリングにスムーズに圧入でき、ブラケットは新しい回転中心を提供できる。最終的には、ねじ固定の構造が、より滑らかなベアリング回転構造へ変わる。

エクスポート、スライス、プリント検証

CAD 修正が終わったら、実際の製造フローに進む必要がある。

Fusion 360 から修正後のモデルをエクスポートする。
スライサーに読み込む。
穴、薄肉、オーバーハング、サポートを確認する。
ギアとブラケットをプリントする。
実際にベアリングを圧入する。
回転が滑らかか確認する。

AI が修正した CAD 結果は、画面上のモデルがきれいかどうかだけで判断してはいけない。必ずプリントして検証する必要がある。特にベアリング、穴位置、スナップ、ギアのような機械構造では、0.1mm レベルの誤差が、組み立てられるか、滑らかに回るかを決める。

使用上の提案

Claude + Fusion 360 は次のようなタスクに向いている。

既存 STEP モデルへの局所的な改造；
穴位置、面取り、ブラケット、取り付け座の調整；
ねじ固定をベアリング、スナップ、ピン構造へ変更する；
3D プリントモデルの公差補正；
複数の改版案を素早く生成する。

ただし、何も確認せずに最終部品を直接出す用途には向かない。より安定した流れは次の通りだ。

人間が組み立て目標と材料工法を定義する。
Claude が構造を分析し、修正案を出す。
Claude が Fusion を呼び出してモデリングを実行する。
人間が重要寸法と干渉を確認する。
小さな試作品をプリントして検証する。
実物の結果に基づいて再度イテレーションする。

まとめ

Claude を Fusion 360 に接続する価値は、CAD の基礎知識を置き換えることではない。「既存モデルの局所修正」を速くすることにある。

目標、材料、寸法、公差、組み立て方法を明確に伝えれば、モデルを読み、干渉を見つけ、構造を修正し、面取りを追加し、プリント可能な状態へ進める手助けができる。3D プリント、オープンソース機械部品の改造、個人工房での小ロット試作において、この AI CAD ワークフローはすでに実用的だ。

goose：デスクトップ、CLI、API を備えたオープンソース AI Agent

Fri, 08 May 2026 13:41:15 +0800

goose はローカルマシン上で動くオープンソース AI Agent です。コード補完だけでなく、コード、調査、執筆、自動化、データ分析など広いタスクを対象にしています。README ではデスクトップアプリ、CLI、API を提供する Agent として説明されています。

このプロジェクトは block/goose から Linux Foundation の Agentic AI Foundation（AAIF）へ移りました。現在のリポジトリは次の通りです。

`1`	`https://github.com/aaif-goose/goose`

goose は主に Rust と TypeScript で書かれ、Apache-2.0 ライセンスです。GitHub の説明では、コード提案を超えて、install、execute、edit、test を任意の LLM で行える拡張可能な AI agent とされています。

解決する問題

多くの AI コーディングツールは提案や局所的なコード編集に寄っています。goose はより広く、AI agent がローカルマシンでタスクを実行することを目指します。

コード変更とテスト。
ローカル自動化。
調査と執筆。
データ分析。
複数ステップの workflow。
API 経由の埋め込み。
MCP による拡張。

IDE 補完だけなら Copilot 系ツールで十分です。goose は AI をローカルのタスク実行チェーンに入れたい場合に向いています。

3 つの入口

デスクトップアプリは macOS、Linux、Windows に対応し、視覚的に使いたい人に向いています。

CLI はターミナル中心の開発者に向いています。

API は他のシステムや社内ツールに agent runtime として組み込むためのものです。

個人利用ならデスクトップか CLI から始め、チームや自動化基盤では API と custom distribution も検討します。

インストール

デスクトップ版：

`1`	`https://goose-docs.ai/docs/getting-started/installation`

CLI：

`1`	`curl -fsSL https://github.com/aaif-goose/goose/releases/download/stable/download_cli.sh \| bash`

GitHub Releases には複数プラットフォームのビルドがあります。確認時点の latest release は v1.33.1 で、2026-04-29 に公開され、macOS、Linux、Windows、deb、rpm、Flatpak などの asset が含まれます。

インストール後は公式 Quickstart に従って provider を設定し、まず低リスクなディレクトリで試します。

Provider

goose は Anthropic、OpenAI、Google、Ollama、OpenRouter、Azure、Bedrock など 15 以上の provider に対応します。

API key を使うことも、ACP 経由で既存の Claude、ChatGPT、Gemini サブスクリプションを使うこともできます。

ACP は、既存のサブスクリプションを agent workflow に持ち込める点で重要です。ただし provider の規約、quota、会社コードや機密データでの利用可否は必ず確認してください。

MCP extension

goose は Model Context Protocol extension に対応し、README では 70 以上の extensions に接続できるとされています。

MCP により、agent はチャットやファイル編集だけでなく、ドキュメント、データベース、ブラウザ、社内システム、検索サービス、設計ツール、プロジェクト管理ツールなどと標準プロトコルで接続できます。

チームでは、内部機能を明確な interface として公開する安全な統合層にもなります。

コーディング助手との違い

goose はコード補完ツールというよりローカル agent runtime です。

一般的な助手は補完、説明、関数生成、エディタ内の局所編集に寄ります。goose はローカルタスク実行、複数ステップ workflow、provider 切り替え、extension、デスクトップと CLI、埋め込み API、非コードタスクも重視します。

その分、モデル設定、権限、extension、workspace、ログ、credential 管理を考える必要があります。

Custom distribution

CUSTOM_DISTROS.md では、provider、extension、branding を事前設定した goose distro を作る方法が説明されています。

チームは、許可された provider、社内 MCP server、安全ポリシー、ログ設定、禁止サービス、ブランドやオンボーディングを組み込んだ内部版を作れます。

使い方の勧め

デスクトップ版または CLI を入れる。
1 つの provider を設定する。
テストディレクトリで簡単なタスクを実行する。
読み取るファイルと実行する動作を見る。
MCP extension を追加する。
複雑なリポジトリや自動化 workflow は後で試す。

重要な変更前は git commit し、API key をプロジェクトに書かず、高権限モードは信頼できる workspace に限定します。会社コードではデータ規約と provider ポリシーを確認してください。

まとめ

goose は AAIF/Linux Foundation 傘下のオープンソース AI Agent で、デスクトップ、CLI、API、15 以上の provider、ACP サブスクリプション連携、70 以上の MCP extensions に対応します。

価値はコードを書くことだけではなく、モデル、ツール、extension、ローカル実行環境を 1 つの agent framework にまとめる点にあります。

参考資料

CC Switch：Claude Code、Codex、Gemini CLI、OpenClawを一元管理するデスクトップツール

Wed, 06 May 2026 09:03:08 +0800

CC Switch は、AIコーディングを日常的に深く使うユーザー向けのデスクトップ管理ツールだ。解決しようとしている問題ははっきりしている。いま多くの人が Claude Code、Codex、Gemini CLI、OpenCode、OpenClaw を同時に使っているが、それぞれ設定形式、Providerの書き方、MCP設定、Skills管理の方法が違う。

1つのツールだけを使うなら、手作業で設定を変えるのもまだ我慢できる。しかし複数のツールを混在させ、そこに公式アカウント、サードパーティAPI、リレーサービス、ローカルモデル、チーム共有設定まで加わると、JSON、TOML、.env を手で編集する作業はすぐに面倒になる。

CC Switch の位置づけは、こうした分散した設定を1つのクロスプラットフォームなデスクトップアプリに集約することだ。

何を解決するのか

現代のAIコーディングツールは、「コマンドラインの中にいる開発仲間」のようになりつつある。ただし、各ツールのエコシステムはまだ完全には統一されていない。

よくある課題は次の通りだ。

Claude Code、Codex、Gemini CLI、OpenCode、OpenClawで設定形式が異なる。
API Providerを切り替えるたびに、設定ファイルを何度も変更する必要がある。
MCP serverを複数ツールで重複して設定しがちになる。
CLAUDE.md、AGENTS.md、GEMINI.md のようなプロンプトファイルを統一して保守しにくい。
Skillsのインストール、同期、バックアップ、削除に集中管理の入口がない。
複数アカウント、複数relay、複数モデルサービスの切り替えが混乱しやすい。
設定ファイルを手作業で壊した場合、原因調査のコストが高い。

CC Switch の考え方は、ユーザーに各ツールの設定細部を覚えさせるのではなく、Provider、MCP、Prompts、Skills、Sessions、プロキシを1つの統一画面で管理するというものだ。

対応ツール

READMEに挙げられている主な対応対象は5種類ある。

Claude Code
Codex
Gemini CLI
OpenCode
OpenClaw

これらのツールは、AIコーディング、Agentワークフロー、コマンドライン上の協働という点で近い位置づけにある。ただし設定体系は異なっており、CC Switch の価値はその違いを包み込むところにある。

複数のAIコーディングツールをよく比較する人にとっては、毎回設定ファイルを手で開くよりかなり楽になる。

Provider管理

CC Switch の第一の機能はProvider管理だ。

50以上のProviderプリセットを内蔵しており、READMEではAWS Bedrock、NVIDIA NIM、各種コミュニティrelayなどが挙げられている。ユーザーはAPI keyをコピーしてワンクリックでインポートし、画面上で切り替えられる。

実用的なポイントは次の通りだ。

Providerをワンクリックで追加できる。
Providerをドラッグで並べ替えられる。
システムトレイから素早く切り替えられる。
Providerのインポートとエクスポートに対応する。
一部の共通Providerは複数アプリへ同期できる。

多くの人にとって、この機能だけでも十分に魅力がある。AIコーディングツールの日常利用で問題になるのは、「モデルを使えない」ことではなく、「今日このkeyをどのツール、どのendpoint、どのアカウントで使うのか」が混乱することだからだ。

ローカルプロキシとフェイルオーバー

設定ファイルを書き換えるだけでなく、CC Switch はローカルプロキシモードも提供する。

この機能の要点は次の通りだ。

Providerのホットスイッチ。
フォーマット変換。
自動フェイルオーバー。
サーキットブレーカー。
Providerのヘルスチェック。
リクエスト補正。

簡単に言えば、対象ツールに設定を書き込むだけでなく、間にローカルプロキシ層を挟み、異なるツールがそのプロキシ経由でモデルサービスにアクセスできるようにする。

これは複数Providerを使うユーザーにとって便利だ。あるサービスが落ちたら別のものへ切り替える。あるモデルが高ければ安いものに変える。リクエスト形式が合わない場合も、プロキシ層で適配できる。

MCP、Prompts、Skills

CC Switch の重要な第二層の機能は、MCP、Prompts、Skillsの一元管理だ。

MCP

複数アプリ間でMCP serverを管理できる統一MCPパネルを提供し、双方向同期とDeep Linkインポートにも対応する。

これはMCPを使っているユーザーにはかなり実用的だ。MCP serverが増えるほど、設定は複数のクライアントに散らばりやすい。統一パネルがあれば、重複設定を減らし、移行もしやすくなる。

Prompts

Prompts部分はMarkdown編集に対応し、異なるツール間で対応するファイルを同期できる。例えば次のようなファイルだ。

CLAUDE.md
AGENTS.md
GEMINI.md

これらは本質的にはAgent向けのプロジェクト説明書だ。一元管理できれば、チームルール、プロジェクトの約束事、グローバルプロンプトをより保守しやすくなる。

Skills

SkillsはGitHubリポジトリやZIPファイルからワンクリックでインストールできる。カスタムリポジトリ管理、シンボリックリンク、ファイルコピーにも対応する。

Claude Code、Codex、OpenClawのようなツールを同時に使う場合、Skillsは複数ディレクトリに散らばったファイル群になりやすい。CC Switch はそれらを集約し、保守コストを下げる。

セッションとワークスペース

READMEではSession ManagerとWorkspace関連の機能にも触れられている。

複数アプリ内のセッション履歴を閲覧、検索、復元できる。AIコーディングツールを長期的に使う人にとって、セッション管理はかなり重要だ。価値のある文脈、デバッグ過程、案の比較が、古い会話の中に埋もれていることが多いからだ。

さらにOpenClaw向けにWorkspace editorも提供し、AGENTS.md、SOUL.md などのagentファイルを編集でき、Markdownプレビューも備える。

これは CC Switch が単なる「key切り替えツール」ではなく、AI Agentワークステーションの方向へ拡張していることを示している。

クラウド同期とデータ保存

CC Switch はDropbox、OneDrive、iCloud、NAS、WebDAV経由でProviderデータを同期できる。

ローカルのデータ保存場所も明確だ。

データベース：~/.cc-switch/cc-switch.db
ローカル設定：~/.cc-switch/settings.json
自動バックアップ：~/.cc-switch/backups/
Skills：~/.cc-switch/skills/
Skillバックアップ：~/.cc-switch/skill-backups/

主要データソースとしてSQLiteを使い、原子的な書き込みと自動バックアップを重視している。目的は、切り替えや書き込みの際に設定ファイルが壊れることを避けることだ。

この設計はヘビーユーザーにとって重要だ。設定管理ツール自体が設定を書き壊した場合、影響を受けるのはすべてのAIコーディングツールだからだ。

インストール方法

CC Switch はTauri 2ベースのクロスプラットフォームデスクトップアプリだ。

おおよそのシステム要件は次の通り。

Windows：Windows 10以降
macOS：macOS 12 Monterey以降
Linux：Ubuntu 22.04+、Debian 11+、Fedora 34+などの主要ディストリビューション

Windowsユーザーは .msi インストーラーまたはポータブル版の圧縮パッケージをダウンロードできる。

macOSユーザーはHomebrewでインストールできる。

1
2

brew tap farion1231/ccswitch
brew install --cask cc-switch

更新は次の通り。

`1`	`brew upgrade --cask cc-switch`

Linuxユーザーは .deb、.rpm、AppImageを選べる。Arch Linuxユーザーは paru -S cc-switch-bin でもインストールできる。

2026年5月6日時点で、リポジトリページに表示されている最新releaseは CC Switch v3.14.1 で、公開日は2026年4月23日だ。

技術スタック

リポジトリ構成を見ると、CC Switch は典型的なTauriデスクトップアプリだ。

フロントエンド：React 18、TypeScript、Vite、TailwindCSS、TanStack Query、shadcn/ui
バックエンド：Tauri 2、Rust、SQLite、Tokio
テスト：Vitest、MSW、Testing Library

主な設計パターンは次の通り。

SQLiteをSingle Source of Truthとして使う。
デバイス単位のローカル設定はJSONで保存する。
切り替え時に対象ツールのlive configへ書き込む。
現在のProviderを編集する際はlive configから回填する。
一時ファイルとrenameを使って原子的に書き込む。
データベース接続をロックし、並行書き込み問題を避ける。

この構成から、プロジェクトは単なるスクリプトではなく、長期利用を前提にしたデスクトップツールとして設計されていることがわかる。

誰に向いているか

CC Switch が向いているのは次のようなユーザーだ。

Claude Code、Codex、Gemini CLI、OpenCode、OpenClawを同時に使う。
公式アカウント、サードパーティrelay、ローカルモデル、チームProviderを頻繁に切り替える。
すでにMCPを多用し始めている。
CLAUDE.md、AGENTS.md、GEMINI.md を統一して保守したい。
Skillsを頻繁にインストール、テスト、移行する。
複数ツールのセッション履歴や利用状況を見たい。

もしAIコーディングツールを1つだけ使い、常に公式ログインで、Provider、MCP、Skillsをあまり触らないなら、価値はそれほど明確ではないかもしれない。

しかしすでに「複数ツール、複数アカウント、複数Provider、複数プロジェクト」の状態に入っているなら、細かな設定作業をかなり減らせる。

注意点

この種のツールは便利だが、境界も意識する必要がある。

第一に、複数のAI CLI設定を管理するため、このツールとその書き込みロジックを信頼できるか確認する必要がある。

第二に、API key、relay endpoint、MCP serverはいずれも機微な設定だ。クラウド同期を有効にする前に、同期先ディレクトリやWebDAVサービス自体が安全で信頼できるか確認したい。

第三に、Providerを切り替えた後、多くのツールでは変更を反映するためにターミナルやCLIの再起動が必要になる。READMEでは、Claude CodeはProviderデータのホットスイッチに対応するとされているが、他のツールでは通常再起動が必要だ。

第四に、公式ログインへ戻す場合は、プロジェクト説明に沿ってofficial providerを追加し、対応するツールのログインフローを改めて実行するのがよい。

まとめ

CC Switch の価値は、また別のAIコーディングツールを作ったことではない。AIコーディングのエコシステムが、すでに複数ツール共存の段階に入ったという現実を認めている点にある。

Claude Code、Codex、Gemini CLI、OpenCode、OpenClawにはそれぞれ独自の設定システムがあり、MCP、Skills、Prompts、Providerも急速に広がっている。設定を手作業で変え続けるやり方は、いずれ負担になる。

CC Switch はこれらを1つのデスクトップアプリに集約し、Providerの切り替え、MCPの同期、Skillsの管理、プロンプトファイルの保守、セッション確認をより簡単にする。AIコーディングを重く使う人にとって、この種のツールは「任意の小道具」から「日常の基盤」へ変わっていく可能性が高い。

参考資料

farion1231/cc-switch

Codex App 入門ガイド：インストール、サンドボックス、並列タスク、Skills、MCP

Wed, 06 May 2026 08:41:17 +0800

Codex App は、AI コーディング向けのタスクワークスペースと考えると分かりやすい。従来の IDE でも、単なるチャット画面でもなく、マルチタスク、プロジェクト管理、サンドボックス権限、Git、クラウド実行、プラグイン、Skills、MCP、自動化を 1 つのインターフェイスにまとめている。

すでに Codex CLI、Claude Code、Cursor、その他の coding agent を使っているなら、Codex App の最も注目すべき点は、「複数の agent を並列に動かす」ことをより明確なデスクトップワークフローにしている点だ。

Codex App が向いていること

Codex App の価値は、AI に質問へ答えさせることではなく、プロジェクトディレクトリ内で継続的にタスクを実行させることにある。

コードを編集し、コマンドを実行し、開発サーバーを起動する。
複数のプロジェクトと複数のタスクを管理する。
ローカルまたはクラウドで長いタスクを実行する。
プラグイン、Skills、MCP を呼び出して能力を拡張する。
Git、worktree、PR で変更を管理する。

OpenAI も Codex App を複数の coding agent を管理するためのインターフェイスとして位置付けている。複数のコードタスクを同時に進める人に向いており、特にフロントエンドページ、スクリプト、小規模アプリ、ドキュメント整理、自動化ワークフローと相性がよい。

インストール前の準備

Codex App を使う前に、次の 3 つの基本ツールを用意しておくとよい。

Git
Node.js
VS Code または普段使っている IDE

Codex App は macOS と Windows をサポートしている。インストール後は ChatGPT アカウントでログインする。初回起動時には、プログラミングや日常作業など主な利用シナリオを選択できる。Codex は選択内容に応じて一部のプラグインと Skills を事前に入れ、後から設定やプラグインマーケットで調整できる。

Windows と macOS の主な機能はおおむね同じだが、一部のコンピューター自動化機能はプラットフォームやプラグイン対応に依存する。実際には現在のバージョンに表示される内容を基準にする。

インターフェイス構造：プロジェクト、タスク、チャット

Codex App は典型的な 3 カラム構成になっている。

左側：プロジェクト、タスク、過去のチャット、プラグイン、自動化への入口。
中央：現在のチャット画面。
右側：ファイル、ブラウザー、ターミナル、実行結果などの多機能領域。

1 つのプロジェクトは通常、ローカルフォルダーに対応する。同じプロジェクト内で複数のチャットを開くことも、複数のプロジェクトを同時に開き、異なる agent に並列で作業させることもできる。

タスクリストには状態が表示される。

実行中：agent がまだ作業している。
承認待ち：権限、ネットワーク、依存関係インストール、高リスク操作の確認が必要。
完了：タスクが終了し、結果確認や追加質問ができる。

複数のターミナルを行き来するより直感的で、複数の AI タスクを同時に管理しやすい。

サンドボックスと権限管理

Codex App の権限体系はサンドボックスを中心にしている。デフォルトでは、現在のプロジェクトフォルダーが agent の主な作業範囲になる。

一般的な権限境界は次の通り。

プロジェクトディレクトリ内のファイルを読み書きできる。
デフォルトではプロジェクト外のファイルを自由に変更できない。
ネットワークや高リスクコマンドはデフォルトで制限される。
権限昇格が必要な場合はユーザーに承認を求める。

実用的なのは「自動レビュー」モードだ。低リスク操作は自動で許可し、高リスク操作はユーザー確認に回す。これにより頻繁なポップアップを減らしつつ、危険な操作が知らないうちに実行されることを防げる。

「完全アクセス」は慎重に使うべきだ。agent が何をする必要があるか明確で、プロジェクトが Git でバックアップされ、重要ファイルにも別のバックアップがある場合に向いている。日常的に常時有効にするのはおすすめしない。

コンテキスト、モデル、利用枠

Codex App は現在のチャットのコンテキスト使用状況を表示する。会話が長く、履歴が多いほど、モデルが処理するコンテキストも大きくなる。

実用的な習慣は次の通り。

1 つのタスクが終わったら新しいチャットを開く。
長い会話は手動圧縮できるが、圧縮を万能の記憶と考えない。
複雑なタスクでは、目的、境界、受け入れ条件を先に明確にする。
関係ない大量のログ、エラー、ファイルを一度に詰め込まない。

モデル選択では、タスクの複雑さに応じて推論強度を調整する。簡単な修正、文章整理、反復タスクは必ずしも最高性能モデルを必要としない。アーキテクチャ移行、難しいバグ、複数ファイルにまたがるリファクタリングには、より強いモデルが向いている。

高速モードがある場合は、通常より利用枠を多く消費する点に注意する。急ぎの時には有効だが、日常のデフォルトにする必要はない。

画像生成とマルチモーダル入力

Codex App は画像やファイルをコンテキストとして受け取ることができ、適切な場面では画像生成能力も呼び出せる。

これはフロントエンドやコンテンツ系プロジェクトで役立つ。たとえば Codex に次のことを依頼できる。

スクリーンショットをもとにページスタイルを修正する。
Web ページ内の不適切な画像を置き換える。
商品画像、カルーセル画像、ページ素材を生成する。
UI スクリーンショットから修正すべき位置を指摘する。

より効率的なのは、「もっときれいにして」とだけ言うのではなく、スクリーンショットを使って具体的な問題を示すことだ。たとえば「このカードの余白が大きすぎる」「この画像はサービスシーンに合っていない」「地図エリアをもっと分かりやすくする」といった指示がよい。

Steer：実行中に方向を修正する

Steer は、実行中に方向を引き受ける機能と考えるとよい。agent がすでに作業を始めた後で、方向を誤解していると気づいた場合、すべて終わるまで待ってから直す必要はない。

この機能を使うと、新しい指示を現在の実行フローに挿入し、Codex に進路を修正させられる。

Steer が向いている場面は次の通り。

agent が要件を誤解した。
生成されたページのスタイルが明らかに違う。
実行中の案が重すぎる、またはコストが高すぎる。
途中で重要な制約を追加する必要がある。

通常はデフォルトのキュー動作を維持し、本当に介入が必要な時だけ手動で Steer を使うのがよい。通常のタスクを乱さず、重要な場面で方向を戻せる。

計画モードと内蔵ブラウザー

複雑なタスクでは、まず計画モードを使うのがよい。計画モードでは Codex はすぐにコードを変更せず、先に計画を出し、必要ならカード形式で重要な選択肢を確認する。

計画モードに向いているタスクは次の通り。

React プロジェクトを Next.js に移すようなフレームワーク移行。
大規模リファクタリング。
データベース、認証、デプロイを含む機能。
技術方針がまだ固まっていない要件。

Codex App の右側領域では内蔵ブラウザーを開き、ローカル開発サーバーをプレビューできる。ページ上で注釈を付け、具体的な UI 位置に応じて Codex に修正させられる。この「ページを見る、位置を指す、AI に直させる」流れは、純粋な文章説明よりフロントエンドデバッグに向いている。

Git、IDE、コードのロールバック

Codex App は完全な IDE ではない。コード閲覧や注釈はできるが、手作業での編集は VS Code、Cursor、Windsurf などの IDE の方が向いている。

Codex プロジェクトでは早めに Git を初期化しておくとよい。

Codex に .gitignore を作成または確認させる。
使える状態になったら一度コミットする。
大きな変更の前にはクリーンなコミット地点を作る。
不満があれば Git でコードを戻す。

チャット履歴だけを戻しても、コードは自動では戻らない。安定した方法は、チャットを適切な地点へ戻し、コードは Git commit hash で対応する状態へ戻すことだ。

Worktree：複数方向の並列開発

git worktree は Codex App で並列 agent を使う際に非常に相性がよい。

本質的には、同じリポジトリから複数の独立した作業ディレクトリを作り、それぞれを別ブランチに対応させる仕組みだ。これにより、異なる agent を別フォルダーで同時に作業させても互いに上書きしない。

典型的な使い方は次の通り。

1 つの worktree で顧客レビューコンポーネントを改善する。
1 つの worktree で店舗情報と地図レイアウトを調整する。
2 つのタスクが終わったらそれぞれ main へマージする。
マージ後に一時 worktree を削除する。

同じディレクトリで複数 agent に同時編集させるよりずっと安定する。競合が出た場合も、通常の Git フローで review と merge を行えばよい。

クラウド実行環境

Codex はローカルだけでなく、クラウド環境にもタスクを委任できる。

クラウド実行が向いている場面は次の通り。

外出中で手元にスマートフォンしかない。
agent に長いタスクをバックグラウンドで実行させたい。
コードがすでに GitHub に同期されており、Codex にリモートリポジトリを変更させたい。
PR 形式で変更を確認してマージしたい。

典型的な流れは、ローカルコードを GitHub に push し、Codex がクラウド環境でリポジトリを取得してタスクを実行し、変更を生成し、PR または diff としてレビューに出すというものだ。

ローカルで開発を続ける場合は、リモートの最新変更を取り込むことを忘れない。

記憶システム：AGENTS.md を整える

新しいチャットはデフォルトでは完全な履歴記憶を持たない。プロジェクトが複雑になると、毎回背景を説明し直すのは非効率だ。

最も汎用的な方法は、プロジェクトルートに AGENTS.md を置くことだ。このファイルには次の内容を記録できる。

プロジェクトの目的と主要技術スタック。
よく使うコマンド。
ディレクトリ構成。
コードスタイルと命名規則。
禁止事項、たとえばファイルの一括削除を避けること。
テスト、ビルド、デプロイルール。

Codex にプロジェクトを読ませて AGENTS.md の初版を生成させ、人間が確認する方法もよい。複雑なプロジェクトでは、このファイルを維持する価値が高い。

グローバルルールは慎重に使う。全プロジェクトに共通する安全制約、たとえば「ディレクトリを再帰的に削除しない」「破壊的操作の前に確認する」などに向いている。特定プロジェクトの細部をグローバルルールに入れると、他のプロジェクトを汚染する。

プラグインと自動化

プラグインは、GitHub、Gmail、Google Drive、データベース、デプロイ基盤など外部サービスを Codex に接続する。

価値はコピー&ペーストを減らすことだ。たとえば Codex に次のことをさせられる。

GitHub リポジトリの star 推移を確認する。
メール内容を整理して自分に送る。
定期的なチェックを実行する。
結果を要約として書く。

自動化は繰り返しタスクに向いている。たとえば毎週金曜午後にリポジトリデータを確認し、メールレポートを送るような用途だ。簡単な自動化タスクには最高性能モデルは不要で、軽量モデルで十分なことが多い。

Skills：ワークフローを再利用可能な能力にする

Skills は Codex の「専門的な手順書」だ。一回限りのプロンプトではなく、ある種類のタスクの流れ、規則、スクリプト、注意点をまとめ、Codex が後で安定して再利用できるようにする。

主な入手元は次の 3 種類。

公式 Skills。
サードパーティ Skills。
自分で書いた Skills。

Skill 化に向いている作業は次の通り。

字幕を図解付きノートにする。
会社の形式で週報を書く。
画像や文書を一括処理する。
固定形式のコードレビュー。
特定フレームワークのプロジェクト初期化。

同じプロンプトを何度もコピーしているなら、Skill にする価値がある。

MCP：外部ツールとデータベースを接続する

MCP は、大規模モデル向けの標準化されたツールプロトコルと考えられる。MCP を通じて、Codex は外部サービスを呼び出し、より具体的なタスクを完了できる。

たとえば Supabase を接続すると、Codex に次のことをさせられる。

データベーステーブルを作成する。
データベーススキーマを読む。
バックエンドエンドポイントを変更する。
フロントエンドフォームをデータベースへ送信する。
データベース状態に基づいて問題をデバッグする。

これは強力だが、権限境界に注意が必要だ。データベース、本番環境、デプロイ基盤、メールアカウントは高リスク資源である。初回接続時はテストプロジェクトと低権限アカウントを使うのがよい。

デプロイプラグイン

デプロイ基盤のプラグインを使うと、Codex がビルドと公開を直接完了できる。たとえばフロントエンドプロジェクトを Netlify のような平台へデプロイできる。

この種のプラグインは、小規模サイト、プロトタイプ、社内ツール、デモプロジェクトに向いている。実際に使う時は次の点に注意する。

デプロイ前にローカルビルドを実行する。
環境変数をコードへ直接書かない。
公開後にページが正常に開くか確認する。
本番プロジェクトでは人間の review を残す。

AI は公開フローをつなぐ助けになるが、デプロイ権限は慎重に管理すべきだ。

コンピューター自動化

対応プラットフォームとプラグイン環境では、Codex がブラウザーやデスクトップアプリを操作し、RPA に近いタスクを実行できる。

例：

チャットアプリを開いてメッセージを準備する。
プロジェクトボードを閲覧し、タスク状態を要約する。
英語のブリーフを生成する。
確認後、指定相手へ送信する。
この流れをスケジュール自動化にする。

この機能は想像力を広げるが、最も強い安全境界も必要だ。メッセージ送信、メール送信、フォーム送信、支払い、データ削除に関わる操作では、人間の確認を残すべきだ。

使い方の提案

Codex App の正しい使い方は、すべてを一度に完全自動化させることではない。タスクを明確に分解し、制御された環境で効率よく実行させることだ。

おすすめの習慣：

すべてのプロジェクトで最初に Git を初期化する。
複雑なタスクでは計画モードを使う。
並列タスクでは worktree を優先する。
プロジェクトルールを AGENTS.md に書く。
高リスク操作では人間の確認を残す。
繰り返しワークフローを Skill や自動化にする。
プラグインと MCP はまずテスト環境で検証する。

参考資料

まとめ

Codex App の本質は「もう 1 つの AI チャット画面」ではない。AI コーディングを管理可能なワークスペースにすることだ。ローカルプロジェクト、クラウドタスク、Git、worktree、プラグイン、Skills、MCP、自動化をつなげられる。

うまく使う鍵は、「任せること」と「制御すること」のバランスを取ることだ。小さなタスクは大胆に Codex に渡し、複雑なタスクはまず計画させ、高リスク操作は必ず確認する。そうすれば Codex は、コードを書く助手から、長期的に協力できるエンジニアリングツールへ近づく。

Claude for Creative Work：Anthropic が Claude を Adobe、Blender、Ableton、SketchUp に接続

Fri, 01 May 2026 05:52:14 +0800

Anthropic は 2026 年 4 月 28 日に Claude for Creative Work を発表した。重要なのは、新しいチャットボットをもう一つ出したことではなく、クリエイティブ業界がすでに使っているソフトウェアの中に Claude を接続しようとしている点だ。

今回の提携先は象徴的だ。Blender、Autodesk、Adobe、Ableton、Splice に加え、Affinity by Canva、Resolume、SketchUp などのツールエコシステムも含まれている。

簡単に言えば、Anthropic がやろうとしているのは、Claude をチャット欄で助言する存在にとどめず、デザイン、3D、音楽、映像、ライブビジュアルといった具体的なワークフローに入れることだ。

Claude は審美眼を置き換えないが、多くの面倒な作業は置き換えられる

Anthropic の発表はかなり抑制的だ。Claude はクリエイターのセンスや想像力を置き換えるものではない。

これは正しい判断だ。クリエイティブ作業の要点は、多くの場合「何かを生成すること」ではなく、どの方向を続けるべきか、どの細部を残すべきか、どの案がプロジェクトの雰囲気に合っているかを判断することにある。

一方で、クリエイティブの工程には大量の反復作業も含まれている。

画像を一括で調整する
レイヤー名を変更する
複数形式でファイルを書き出す
アセットを整理する
ソフトウェアのドキュメントを調べる
シーンを変更するスクリプトを書く
複数のツール間で形式を変換する
アイデアをすばやく見える草案にする

これらの工程に必ずしも「ひらめき」は必要ないが、時間は大きく消費する。Claude の役割は、クリエイターをこうした機械的な手順から解放することに近い。

Connectors が今回の中核

今回の発表の鍵は connectors だ。

connectors は、Claude と外部プラットフォームやソフトウェアをつなぐ橋と考えられる。ユーザーが要望を Claude にコピーし、それから手作業でソフトウェアに戻って操作するのではなく、Claude がツールを直接理解し、機能を呼び出したり、関連ドキュメントを読んだりできるようにする。

Anthropic の発表で挙げられた接続先には、次のようなものがある。

Ableton：Claude が Live と Push の公式ドキュメントに基づいて質問に答えられるようにする。
Adobe for creativity：Creative Cloud の 50 以上のツールに接続し、Photoshop、Premiere、Express などをカバーする。
Affinity by Canva：プロ向けクリエイティブワークフローの反復的な制作タスクを自動化する。たとえば画像の一括調整、レイヤー名の変更、ファイル書き出しなど。
Autodesk Fusion：Fusion のサブスクリプションを持つデザイナーやエンジニアが、対話を通じて 3D モデルを作成・修正できるようにする。
Blender：自然言語で Blender の Python API を使い、複雑なシーンの理解、ドキュメント参照、機能拡張を支援する。
Resolume Arena と Resolume Wire：VJ やライブビジュアルアーティストが自然言語で Arena、Avenue、Wire をリアルタイムに制御できるようにする。
SketchUp：Claude との会話を 3D モデリングの出発点にする。たとえば部屋、家具、敷地のコンセプトを説明し、その後 SketchUp で細部を詰めていく。
Splice：音楽制作者が Claude から直接 royalty-free samples のライブラリを検索できるようにする。

これらの統合は、デザイン、音声、3D、映像、ライブパフォーマンス、エンジニアリングモデリングをカバーしている。単一方向の小さな実験ではなく、Anthropic が明確に「クリエイティブソフトウェアの作業台」へ向かっていることを示している。

クリエイティブ作業で何に使えるのか

発表を見ると、クリエイティブ作業における Claude の用途はいくつかに分けられる。

第一は、複雑なツールを学ぶことだ。

多くのクリエイティブソフトは強力だが、学習曲線も急だ。Blender、Ableton、Fusion、Premiere はその典型である。ユーザーは検索結果、フォーラム、公式ドキュメントの間を行き来する代わりに、Claude に modifier stack の説明、合成テクニックの解説、見慣れない機能の実演を頼める。

第二は、スクリプトやプラグインを書くことだ。

クリエイティブソフトには自動化できる余地が大量にある。Claude Code は、スクリプト、プラグイン、shader、プロシージャルアニメーション、パラメトリックモデルを書く手助けができる。少し技術は分かるが、常に API を調べ続けたくはないクリエイターにとって、この価値はかなり実用的だ。

第三は、ツールチェーンをつなぐことだ。

実際のプロジェクトは、たいてい一つのソフトだけでは完結しない。デザインは Adobe、3D は Blender や SketchUp、音声は Ableton、素材は Splice、最後は映像やライブ演出システムに入ることもある。Claude は形式変換、データの再構成、アセット同期を助け、手作業の受け渡しを減らせる。

第四は、すばやい探索と納品だ。

Anthropic は Claude Design にも触れている。これは Anthropic Labs の新製品で、ソフトウェア体験のアイデアを探索するためのものだ。フィードバックに基づいてビジュアル案を反復し、デザイン結果を他のツールへ書き出すことができる。出発点は Canva だ。

第五は、反復的な制作作業を減らすことだ。

たとえば、アセットのバッチ処理、プロジェクト構造の作成、シーンオブジェクトの一括調整、自動書き出しなどである。多くのクリエイターはそれができないわけではない。ただ、午後をまるごと繰り返しクリックに費やしたくないのだ。

Blender は最も注目すべき一部

今回の発表で、Blender の位置づけは特に重要だ。

Blender は無料でオープンソースの 3D 制作スイートで、インディーゲーム、モーショングラフィックス、建築ビジュアライゼーション、映像制作などをカバーしている。強力な Python API を持ち、複雑なワークフローも多い。

Blender の開発者はすでに MCP connector を作成しており、現在 Claude で正式に利用できる。

このコネクターでできることには、次のようなものがある。

Blender シーン全体を分析・デバッグする
シーン内のオブジェクトを一括変更する
Blender Python API を使ってカスタムスクリプトを書く
新しいツールを Blender のインターフェイスに直接追加する
複雑な設定やドキュメントの理解を助ける

さらに重要なのは、Anthropic が Blender Development Fund に参加し、Blender プロジェクトの patron になったことだ。これは Blender が Python API を継続的に発展させるための支援になる。

この出来事には二つのシグナルがある。

第一に、Anthropic は商用ソフトに接続したいだけではなく、オープンソースの制作ツールにも賭けている。

第二に、この connector は MCP ベースなので、理論上は Claude だけでなく、他の大規模モデルも接続できる。これは Blender のオープンソース性と相互運用性の方向性に合っている。

これは「AI がデザイナーを置き換える」話ではなく、「AI がツール層に入る」話

今回の発表で最も注目すべき点は、Claude が画像、音楽、3D モデルを生成できるかどうかではない。

より重要なのは、AI がチャット欄からツール層へ移動していることだ。

これまで多くの AI クリエイティブツールの体験は、次のようなものだった。

AI ツール内で要望を説明する。
結果を得る。
ダウンロードまたはコピーする。
専門ソフトに戻って手作業で修正する。

現在の方向性は、むしろ次のようなものだ。

Claude があなたのクリエイティブソフトを理解する。
Claude が関連ドキュメントやプロジェクトの文脈を読む。
Claude がスクリプトを生成し、ツールを操作し、素材を整理し、草案を作る。
クリエイターは慣れたソフトの中で判断と仕上げを続ける。

これはプロユーザーにとってより魅力的だ。彼らは既存のツールチェーンを離れたいわけでも、すべての作業をまったく新しい AI プラットフォームへ移したいわけでもないからだ。

学生とクリエイティブ教育への影響

Anthropic は、creative computation を含む授業を支援するために、アートやデザインのプログラムと協力していることにも触れている。

最初のプログラムには、次のものが含まれる。

Rhode Island School of Design の Art and Computation
Ringling College of Art and Design の Fundamentals of AI for Creatives
Goldsmiths, University of London の MA/MFA Computational Arts

学生と教員は Claude と新しい connectors へのアクセスを得る。そのフィードバックは、Anthropic がクリエイティブ実践者の本当のニーズを理解する助けになる。

この点も興味深い。AI の創作能力が「素材を生成する」段階にとどまると、単なるデモになりやすい。しかし授業に入ると、より重要な問いが出てくる。

学生はツールの背後にあるプロセスをどう理解するのか
AI を探索やプロトタイピングの道具としてどう使うのか
自分自身の判断力をどう保つのか
コードと自動化で創作の境界をどう広げるのか
すべての作品が同じ AI っぽさになることをどう避けるのか

これらの問いは、「AI はクリエイターを置き換えるのか」と単純に議論するよりも実際的だ。

今回の発表に注目すべき人

今回の Claude for Creative Work は、特に次のような人にとって注目に値する。

Blender、SketchUp、Fusion で 3D モデリングをする人
Adobe、Affinity でデザインや映像制作をする人
Ableton、Splice で音楽制作をする人
複数のクリエイティブツールをワークフローとしてつなぐ必要がある人
少しスクリプトを書けて、クリエイティブソフトを自動化したい人
クリエイティブ教育、インタラクションデザイン、計算芸術の授業に関わる人

たまに AI で画像を生成するだけなら、今回の発表がすぐに体験を変えるとは限らない。

しかし、すでに専門ソフトの中で作業していて、「何をすればいいかは分かっているが、この手順が面倒すぎる」と感じることが多いなら、connectors には大きな価値がある。

注意すべき境界

この種のツールも万能ではない。

第一に、Claude の結果が審美性、ブランド、プロジェクト目標に合っているかどうかは、依然としてユーザーが判断する必要がある。

第二に、専門ソフトを自動操作するときは、小さな範囲のタスクから始めるのがよい。復旧しにくいプロジェクトファイルを、最初から一括変更させるべきではない。

第三に、コネクターの品質は非常に重要だ。ドキュメントを調べるだけの connector と、実際にソフトウェアを操作できる connector は、まったく異なる体験である。

第四に、クリエイティブソフトのプロジェクトには複雑なファイル、素材依存、バージョン管理がつきものだ。AI が関わるようになると、バックアップとロールバック可能な流れがさらに重要になる。

第五に、著作権、ライセンス、素材の出所は引き続き自分で確認する必要がある。たとえば Splice が強調しているのは royalty-free samples だが、実際のプロジェクトで使うときは具体的なライセンス条件を確認しなければならない。

まとめ

Claude for Creative Work は単発の機能更新ではなく、Anthropic が Claude をクリエイティブソフトウェアのエコシステムへ押し出す一歩だ。

その重点は、Claude をクリエイターにすることではない。Claude を、ドキュメント検索、スクリプト作成、バッチ処理、ソフトウェア連携、草案生成、反復作業の削減を助ける、クリエイターのそばのツールアシスタントにすることだ。

長期的に価値があるのは、Claude が Blender、Adobe、Ableton、SketchUp といった、クリエイターが日々使う環境に入り始めた点である。

AI が単独のウェブページではなく、専門ツールを理解し呼び出せる存在になるとき、クリエイティブワークフローはより実際的な形で変化していく。

参考リンク：

Claude for Creative Work - Anthropic

qmd：AI Agent 向けのローカル Markdown ドキュメント検索ツール

Fri, 01 May 2026 03:12:57 +0800

qmd は、ローカル Markdown ドキュメント向けの検索ツールです。主な利用対象は AI Agent です。

解決する問題は具体的です。プロジェクトに大量の .md ドキュメントがある場合、AI コーディングアシスタントは、どのファイルを読むべきか、どの段落を引用すべきか、どの説明が最新かを判断しづらくなります。全文 grep はキーワードを見つけられますが、意味の理解は苦手です。ドキュメント全体をコンテキストに詰め込むと、ウィンドウを浪費し、無関係な内容も混ざりやすくなります。

qmd の考え方は、まず Markdown ドキュメントにインデックスを作り、その後検索インターフェースを通じて最も関連する断片を AI に渡すことです。CLI ツールとして使うことも、SDK で統合することも、MCP Server として MCP 対応クライアントに接続することもできます。

解決する問題

実際のプロジェクトのドキュメントは、README が 1、2 個あるだけではありません。

たとえば次のようなものがあります。

アーキテクチャ説明
API ドキュメント
開発規約
デプロイ手順
設計判断記録
トラブルシューティングメモ
要件ドキュメント
AI 利用説明
各種ツールチェーンのメモ

人間はディレクトリをたどってドキュメントを読めますが、AI Agent には明確な検索入口が必要です。そうでないと、次のようなことが起こります。

間違ったドキュメントを読む
重要な制約を見落とす
古い説明を使う
無関係な内容をコンテキストに入れる
存在しないルールを経験で補完して回答する

qmd の価値はここにあります。ローカル Markdown ドキュメントを検索可能な知識源にし、AI がコンテキストを必要とするときにまず検索し、一致した断片に基づいて回答や作業を行えるようにします。

検索方式の特徴

README によると、qmd は複数の検索方式を組み合わせています。

BM25 キーワード検索
ベクトル検索
LLM reranking

BM25 は明確なキーワードに向いています。関数名、設定項目、エラーコード、ファイル名を探す場合は直接的です。

ベクトル検索は意味的な質問に向いています。たとえば「このプロジェクトは権限検証をどう扱っているか」と聞く場合、ドキュメントにその exact な語句がなくても、認証、アクセス制御、ロール判定に関する説明が見つかる可能性があります。

LLM reranking は候補結果の並べ替えに使われます。最初の 2 つのステップで関連しそうな内容を集め、その後モデルが現在の質問により合う断片を判断します。

この組み合わせは、単純なキーワード検索より AI Agent に向いています。Agent の質問は固定キーワードではなく、タスク意図であることが多いからです。

なぜ Markdown なのか

Markdown は開発プロジェクトで最もよく使われるドキュメント形式です。

Git に入れやすいほど単純で、見出し、リスト、コードブロック、リンク、表を持てる程度には構造化されています。AI にとっても、Markdown は PDF、Web スナップショット、スクリーンショットより解析しやすい形式です。

qmd が Markdown に集中しているため、開発ドキュメントに対してより直接的な処理ができます。

見出しと段落で内容を分割する
コードブロックを保持する
ドキュメントパスを保持する
引用しやすい断片を返す
Agent が回答の出典ドキュメントを把握できる

これは、AI にリポジトリをランダムに走査させるより安定しており、すべてのドキュメントを一度に prompt へ入れるよりコンテキストを節約できます。

3 つの利用入口

qmd は CLI、SDK、MCP Server の 3 つの入口を提供します。

1. CLI

CLI はターミナルで直接使う場合や、スクリプトに組み込む場合に向いています。

ドキュメントディレクトリをインデックス化し、コマンドで関連内容を検索できます。開発者にとって CLI は最も効果を確認しやすい入口です。まず正しいドキュメントが見つかるかを確認し、その後より複雑なワークフローへの統合を考えられます。

この種のツールはローカルプロジェクトで便利です。コード変更前に設計ドキュメントを検索し、デバッグ前に障害メモを確認し、API を書く前に API 規約を調べることができます。

2. SDK

SDK は qmd を自分のツールに組み込む場合に向いています。

社内開発アシスタント、ドキュメント Q&A システム、コードレビューボット、プロジェクト知識ベースを作っている場合、ユーザーに直接コマンドを打たせるのではなく、SDK から検索機能を呼び出せます。

SDK では次のような制御がしやすくなります。

検索ディレクトリ
クエリ内容
返す件数
結果形式
後続でモデルに要約させるか

深い統合が必要な場面に向いています。

3. MCP Server

MCP は、qmd が AI Agent にとって最も価値を持つ入口です。

MCP Server を通じて、MCP 対応クライアントは qmd をドキュメント検索ツールとして呼び出せます。これにより Agent は、タスク実行時にプロジェクトルールを推測するのではなく、まずローカル Markdown ドキュメントを検索できます。

典型的な流れは次のようになります。

ユーザーが AI にある機能の変更を依頼する
AI がまず qmd を呼び出して関連設計ドキュメントを検索する
qmd が最も関連する Markdown 断片を返す
AI がドキュメント制約に基づいてコードを変更する

これは「新しい会話のたびにすべてのルールを手で貼る」より自然で、長期プロジェクトにも向いています。

向いている場面

qmd は次のような場面に向いています。

プロジェクトに大量の Markdown ドキュメントがある
AI Agent が頻繁にプロジェクトルールを調べる必要がある
チームが AI の回答にローカルドキュメントを引用させたい
ドキュメントが複数ディレクトリに分散している
CLI、SDK、MCP の間で同じ検索機能を再利用したい
AI コーディングアシスタントがプロジェクト規約を推測するのを減らしたい
ローカル知識ベースを Claude Desktop、Claude Code、その他の MCP クライアントに接続したい

プロジェクトに短い README が 1 つだけなら、AI にそのファイルを読ませれば十分です。

しかし、ドキュメントが数十、数百ファイルに増えている場合や、Agent に毎回ドキュメントを検索してから行動してほしい場合、この種のインデックスツールには意味があります。

grep との違い

grep や rg は正確な検索に非常に向いています。

DATABASE_URL、authMiddleware、404、docker compose を探したいと分かっているなら、キーワード検索がたいてい最速です。

qmd は、正確な語句が分からない場合に向いています。

たとえば次のような質問です。

このプロジェクトのリリース手順は何か
新しい API を追加するときに守る規約は何か
キャッシュ戦略について過去に記録があるか
AI がコードを変更する前に読むべきドキュメントはどれか
あるモジュールの設計背景はどこにあるか

これらは一語の一致ではなく、意味検索が必要なことが多いです。qmd の BM25 + ベクトル + reranking の組み合わせは、こうした質問で正しいコンテキストを見つけやすくするためのものです。

RAG との関係

qmd は、Markdown ドキュメント向けの軽量 RAG コンポーネントと見ることができます。

完全な Q&A システムを代わりに作るものではありません。「関連するドキュメント断片を見つける」ことに集中しています。その後、それらの断片をどう使うかは、CLI、SDK、MCP クライアント、または自分の Agent ワークフローに任せられます。

この位置づけは実用的です。多くのプロジェクトは巨大な知識ベースシステムを必要としていません。必要なのは、AI がローカルドキュメントをより正確かつ素早く検索し、その結果を現在のタスクへ戻せることです。

利用時の注意

第一に、ドキュメント品質は依然として重要です。

検索ツールは既存の内容を見つけるだけです。ドキュメント自体が古い、重複している、矛盾している場合、AI は誤ったコンテキストを受け取る可能性があります。qmd を Agent に接続する前に、重要なドキュメントを整理した方がよいです。

第二に、インデックス範囲を広げすぎないことです。

リポジトリ内のすべての Markdown を入れれば良いとは限りません。依存パッケージのドキュメント、一時メモ、古い案の草稿は結果を汚す可能性があります。どのディレクトリが信頼できるドキュメントソースかを明確にする方がよいです。

第三に、検索結果には出典を残すことです。

AI がドキュメント断片を使うとき、それがどのファイル、どの章から来たのか分かる方がよいです。人間が確認しやすくなり、「ドキュメントの結論に見えるが実はモデルの要約」という問題も減ります。

第四に、人間の判断を完全に置き換えないことです。

qmd はコンテキストの再現率を高められますが、プロジェクトの真実の源を置き換えるものではありません。重要な変更では、現在のコード、テスト結果、最新要件を確認する必要があります。

向いているチーム

チームがすでに AI Agent を日常開発フローに入れ始めているなら、qmd のようなツールは価値があります。

特に次のようなチームに向いています。

ドキュメントを多く書いている
プロジェクト履歴が長い
新メンバーと AI の両方が素早く背景を理解する必要がある
アーキテクチャ決定記録をよく保守している
Markdown の規約ドキュメントが多い
AI がコード変更前にルールを確認するようにしたい

目的は AI を「全知全能」にすることではありません。AI が推測を減らし、より多く調べるようにすることです。

参考

tobi/qmd

最後に

qmd の価値は、ローカル Markdown ドキュメントを AI Agent が安定して呼び出せる検索入口に変えることです。

プロジェクトドキュメントが「人間が読む説明」から「人間と AI の両方が検索できるコンテキスト源」になると、AI コーディングアシスタントはプロジェクトルールに従いやすくなります。

Prompt Optimizer：プロンプト最適化、テスト、MCP に対応したオープンソースツール

Fri, 01 May 2026 03:09:07 +0800

Prompt Optimizer は、プロンプトを改善するためのオープンソースツールです。目的は明確で、粗いプロンプトをより明確で安定し、LLM が実行しやすい形に整えることです。

単に「prompt をきれいに書き直す」ページではありません。プロンプト最適化、結果テスト、比較評価、複数モデル接続、画像生成プロンプト処理、MCP 連携まで備えています。システムプロンプト、ユーザープロンプト、AI ワークフローテンプレートをよく書く人にとっては、専用のプロンプト作業台に近いツールです。

解決する問題

AI を使っていると、よく次のような問題にぶつかります。

プロンプトは長くなるのに、出力品質があまり改善しない
同じタスクでも、モデルを替えると挙動が安定しない
システムプロンプトとユーザープロンプトが混ざり、デバッグしにくい
プロンプトを変更しても、前の版より良くなったか判断しにくい
変数テンプレートを再利用したいが、毎回の置換とテストが面倒
他の AI ツールからプロンプト最適化を呼びたいが、標準的な入口がない

Prompt Optimizer は、こうした問題を中心に設計されています。「prompt を書く」という作業を、最適化、テスト、評価、比較、反復に分けることで、感覚だけに頼らない調整をしやすくします。

主な機能

1. システムプロンプトとユーザープロンプトの最適化

プロンプトには複数の種類があります。

システムプロンプトは通常、役割、目的、境界、出力ルール、作業方法を定義します。ユーザープロンプトは、個別タスクの入力に近いものです。この 2 つが混ざると、モデルが重要点を捉えにくくなり、再利用もしづらくなります。

Prompt Optimizer は、システムプロンプトとユーザープロンプトの両方の最適化に対応しています。長期的に使うロール設定と、特定タスクの入力表現を分けて扱えます。

次のような場面で役立ちます。

AI コーディングアシスタントの作業ルールを書く
カスタマーサポート、レビュー、翻訳、分析ロールのプロンプトを書く
text-to-image 用プロンプトを最適化する
一時的な要件を再利用可能なテンプレートにする
モデルごとに異なるスタイルの prompt を用意する

2. 出力のテストと比較

プロンプトを最適化するだけでは不十分です。重要なのは、最適化後に本当に良くなったかどうかです。

このプロジェクトは、分析、単一結果の評価、複数結果の比較評価をサポートしています。元のプロンプトと最適化後のプロンプトを同じタスクで実行し、出力がより正確で安定し、目的に合っているかを比較できます。

これは、単に「見た目が専門的」な prompt より実用的です。表面上は整っていても、実際には冗長、硬直的、あるいはモデルを誤った方向へ導くプロンプトもあります。比較テストは、そうした問題を早めに見つける助けになります。

3. 複数モデル対応

README によると、このプロジェクトは OpenAI、Gemini、DeepSeek、Zhipu AI、SiliconFlow などのモデルサービスに対応し、OpenAI 互換のカスタム API も利用できます。

これは重要です。プロンプトの効果はモデルに強く依存します。同じ prompt でも、モデルが変わると結果が大きく変わることがあります。複数モデルのテストにより、次の判断がしやすくなります。

プロンプト自体が弱いのか
特定のモデルがそのタスクに向いていないのか
モデルごとに別バージョンを用意すべきか
小さいモデルでも、より明確なプロンプトで実用に近づけるか

ローカルで Ollama を使っている場合や、社内に OpenAI 互換 API のモデルサービスがある場合も、カスタム API として接続できます。

4. 高度なテストモード

プロジェクトは、コンテキスト変数管理、複数ターン会話テスト、Function Calling に対応しています。

変数管理はテンプレート化されたタスクに向いています。たとえば、中古取引の返信、商品説明、メール返信、コードレビュー、ドキュメント生成用のプロンプトがある場合、商品、価格、口調、対象ユーザーなどの変数を差し替えるだけで、入力ごとの挙動を素早く確認できます。

複数ターン会話テストは、長い対話での挙動を確認するのに向いています。単発の質問では良く見える prompt でも、追質問が続くと制約を忘れたり、役割から外れたり、説明を繰り返したりします。複数ターンテストは、実利用に近い検証になります。

Function Calling 対応は、よりエンジニアリング寄りの AI アプリに適しています。ツール呼び出し、パラメータ生成、構造化出力におけるモデルの挙動を確認できます。

5. 画像生成プロンプト

Prompt Optimizer は、text-to-image と image-to-image に関連する機能にも対応しています。README では Gemini、Seedream などの画像モデルとの連携が紹介されています。

画像生成プロンプトの最適化は、テキストタスクとは重点が異なります。主体、構図、空間関係、スタイル、質感、光、感情、制約条件などが重要になります。曖昧な一文を制御しやすい視覚記述に分解することは、単にプロンプトを長くするより価値があります。

商品画像、カバー、イラスト、キービジュアル、スタイル参照画像をよく生成するなら、この種の最適化は実用的です。

使い方

プロジェクトには複数の入口があります。

オンライン版
Vercel でのセルフホスト
デスクトップアプリ
Chrome 拡張
Docker デプロイ
Docker Compose デプロイ
MCP Server

オンライン版は素早い試用に向いています。プロジェクト説明では、純粋なフロントエンドアプリであり、データはブラウザローカルに保存され、AI プロバイダーと直接やり取りすると説明されています。

デスクトップアプリは、さまざまなモデル API に直接接続したい場合に向いています。ブラウザ環境では CORS の制限に遭遇しやすいですが、デスクトップアプリならそれを回避しやすく、ローカル Ollama や厳しい CORS ポリシーを持つ商用 API にも向いています。

Docker デプロイは、自分のサーバーや社内環境で使う場合に向いています。README の基本コマンドは次のとおりです。

`1`	`docker run -d -p 8081:80 --restart unless-stopped --name prompt-optimizer linshen/prompt-optimizer`

API キーとアクセスパスワードを設定する場合は、環境変数を渡します。

docker run -d -p 8081:80 \
  -e VITE_OPENAI_API_KEY=your_key \
  -e ACCESS_USERNAME=your_username \
  -e ACCESS_PASSWORD=your_password \
  --restart unless-stopped \
  --name prompt-optimizer \
  linshen/prompt-optimizer

中国国内で Docker Hub へのアクセスが遅い場合は、README の説明に従って Alibaba Cloud のイメージ名に置き換えることもできます。

MCP でできること

Prompt Optimizer は Model Context Protocol、つまり MCP に対応しています。

Docker で実行する場合、MCP サービスは Web アプリと一緒に起動でき、/mcp パスからアクセスできます。これにより、単なる Web ツールではなく、Claude Desktop などの MCP 対応アプリから呼び出せるツールになります。

README に記載されている MCP ツールは次のとおりです。

optimize-user-prompt：ユーザープロンプトを最適化
optimize-system-prompt：システムプロンプトを最適化
iterate-prompt：既存プロンプトを目的に沿って反復改善

こうしたインターフェースは AI ワークフローに向いています。たとえば複雑なタスク用プロンプトを書くとき、MCP 対応クライアントから直接プロンプト最適化を呼び出せるため、毎回 Web ページを開いてコピーする必要がありません。

通常のチャットツールとの違い

通常のチャットツールでも prompt の書き直しはできますが、次のような点が不足しがちです。

複数バージョンの保存と比較がしづらい
複数モデルを同時にテストしづらい
変数をテンプレート化しづらい
複数ターン会話の検証がしづらい
MCP 連携やセルフホストがしづらい

Prompt Optimizer の価値は、プロンプト最適化を再現可能なプロセスにすることです。「より完成度が高く見える」文章を出すだけでなく、実際の出力を見ながら継続的に調整できます。

向いている人

次のような人は、このプロジェクトに注目するとよいでしょう。

システムプロンプトをよく書く
AI アプリ用のロールや出力形式を設計する
異なるモデルの出力を比較したい
prompt を再利用可能なテンプレートにしたい
複数ターン対話やツール呼び出しをテストしたい
プロンプト最適化を MCP ワークフローに接続したい
ローカルまたは社内環境にプロンプトツールをデプロイしたい

たまに AI に簡単な質問をするだけなら、普通のチャット画面で十分です。このツールは、プロンプトを保守可能な資産として扱う人に向いています。

利用時の注意

第一に、最適化結果を絶対に正しいものとして扱わないことです。

プロンプト最適化ツールは表現品質を高められますが、モデルが誤解しないことを保証するものではありません。重要なタスクでは、テストケース、人手の確認、バージョン比較が必要です。

第二に、長さだけを追わないことです。

良い prompt は必ずしも長いとは限りません。目的、境界、入出力形式、判断基準をより明確に表すべきです。意味の薄いルールを積み重ねると、かえってモデルが要点を見失います。

第三に、モデルに合わせて prompt を調整することです。

モデルによって、役割設定、形式制約、推論手順、例への反応は異なります。大きなモデルでうまく動くプロンプトが、小さなモデルにも合うとは限りません。複数モデルテストは、このツールを使う理由の一つです。

第四に、デプロイ時はキーとアクセス制御を考慮することです。

公開環境にデプロイする場合は、アクセスパスワードを設定し、API key を慎重に扱うべきです。プロジェクトは環境変数によるアクセス制御に対応しています。機密設定を公開リポジトリへ直接書かないようにしてください。

参考

linshenkx/prompt-optimizer

最後に

Prompt Optimizer は、プロンプトを「その場で手書きした一段落」から「テスト、比較、反復できる作業資産」へ整理するためのツールです。

複数のモデル、複数の場面、複数のバージョンにまたがって prompt を保守し始めると、通常のチャット画面よりもこうしたツールの方が扱いやすくなります。

AI用語解説: Agent、MCP、RAG、Token をわかりやすく整理する

Thu, 23 Apr 2026 13:13:40 +0800

AI に触れ始めたばかりのとき、人を遠ざけやすいのはモデルそのものより、会話の中に次々出てくる用語です。Agent、MCP、RAG、AIGC、Token はどれも見覚えはあっても、やさしく説明されないと本当の意味まではつかみにくいものです。

この記事では、よくある入門向けの説明の流れに沿って、AI で頻出する 10 個の用語を覚えやすい形にまとめます。学術的に厳密に説明することよりも、日常的な AI の話題についていける基本イメージを作ることを目的にしています。

10 個の代表的な AI 用語は何を意味するのか

1. Agent: 会話だけでなく実行もする AI

Agent は、実際に作業を進めてくれる AI アシスタントだと考えると分かりやすいです。

普通のチャットボットは、質問すると答えるという形にとどまりがちです。Agent はそこから一歩進み、タスクを分解し、手順を組み立て、ツールを呼び出し、最後に結果を返します。資料整理、調査、文書生成のような依頼でも、助言だけで終わらず、一連の動作をつないで実行することがあります。

だから Agent の本質は、話せるかどうかではなく、動けるかどうかにあります。

2. OpenClaw: PC に常駐する AI アシスタント

ここでの OpenClaw は、PC の中に住む AI アシスタントのようなものとして説明されています。

この種のツールは、デスクトップ操作に近い AI 支援だと考えると分かりやすいです。文字入力を受け取るだけでなく、画面を見たり、ローカルツールを呼び出したり、手順に沿って作業したりすることがあります。一般的な Web チャットと比べると、実際の操作能力がより重視されます。

Agent が実行型 AI という抽象的な概念だとすれば、こうしたデスクトップ型アシスタントは、その考え方の PC 上での具体例だと言えます。

3. Skills: Agent に追加する能力パック

Skills は、Agent の機能モジュールや操作ルールだと捉えられます。

同じ Agent でも、どの Skills を持つかによって得意分野が変わります。文章作成寄りのものもあれば、データ整理向けのものもあり、コード処理に向いたものもあります。スマートフォンのアプリに少し似ていますし、再利用できるワークフロー集にも近いです。

つまり、モデルそのものが急に賢くなったというより、背後にあるルール、ツール、手順が明確になった結果だと言えます。

4. MCP: AI が外部ツールにつながるための共通方式

MCP は Model Context Protocol の略です。

身近な比喩で言えば、AI の世界における Type-C 端子のようなものです。以前はモデルを別々のツールにつなぐたびに個別実装が必要になりがちでしたが、共通プロトコルがあると接続方法を標準化しやすくなります。

多くの人にとって大事なのは、MCP が「モデルが答えられるかどうか」の話ではなく、「モデルが外部ツールや外部リソースに安全かつ安定して接続するにはどうするか」の話だという点です。

5. ガチャ: AI 生成にはランダムさがある

「ガチャ」という表現は、AI 画像生成、動画生成、クリエイティブ用途でよく使われます。

意味はシンプルです。同じプロンプトで、同じ方向性を指定しても、毎回まったく同じ結果になるとは限りません。すごく良い結果が出ることもあれば、明らかに崩れることもあります。そのため、何度も生成して当たりを引く感覚がゲームのガチャにたとえられます。

ここで押さえておきたいのは、AI 生成は固定的な公式ではなく、確率的な揺らぎを含んだプロセスだということです。

6. API: アプリとモデルをつなぐ入口

API は Application Programming Interface の略です。

プログラム同士がやり取りするための標準的な入口だと考えると分かりやすいです。自分のアプリ、スクリプト、エディタからモデルサービスを呼び出すときは、実質的に API を通じてリクエストを送り、結果を受け取っています。

モデルサービスをレストランにたとえるなら:

メニューは API ドキュメント
注文は API リクエスト
厨房から料理が返ってくるのはモデルの応答

そのため、見た目は違うツールでも、裏側では何らかの API を呼んでいることが多いです。

7. マルチモーダル: AI は文字だけを扱うわけではない

マルチモーダル とは、AI が文字の読み書きだけに限られず、複数の種類の情報を扱えることを指します。

たとえば画像を見たり、音声を理解したり、動画を解釈したり、画像を生成したり、リアルタイムの音声や映像のやり取りを支えたりできます。文字しか扱えなかった初期のモデルと比べると、「見る・聞く・話す・書く」に近い能力を併せ持つ方向へ進んでいます。

だからこそ、今の AI 製品は単なるテキスト入力欄だけでは語れなくなっています。

8. RAG: 先に資料を探し、そのうえで答えを作る

RAG は Retrieval-Augmented Generation の略です。

これはとても実務的な課題に向いています。モデルの学習データには時点の限界があり、社内の最新資料、サポート記録、業務ルールを自動では知りません。RAG は、まず指定した資料群から関連情報を探し、その内容を踏まえて回答を生成する考え方です。

価値が出やすい点は主に 3 つあります。

回答が実際の資料に寄りやすくなる
どの資料を根拠にしたか追いやすい
新しい資料を追加すれば知識を更新しやすい

そのため、企業向けナレッジベース、AI カスタマーサポート、社内 Q&A では RAG がよく使われます。

9. AIGC: AI が作るコンテンツ全体を指す言葉

AIGC は AI Generated Content の略です。

これは単独のツール名ではなく、AI が生成したコンテンツ全般を指す総称です。文章、画像、音声、動画などが含まれます。AI ライティング、AI イラスト、AI による短尺動画制作、AI 音声生成などはすべて AIGC の枠で理解できます。

大事なのは、この言葉が特定のモデルではなく、コンテンツの作り方そのものを指していることです。

10. Token: モデルが内容を処理するときの計量単位

Token は、モデルがテキストを処理するときの基本的な計量単位だと考えられます。

これは 1 文字や 1 単語と完全に一致するわけではありませんが、実用上は計算量や課金の共通単位として捉えて問題ありません。入力でも Token を消費し、出力でも Token を消費し、保持しているコンテキストも同じように Token を使います。

だから多くのモデルサービスがコンテキスト長、コスト管理、プロンプト圧縮を強調するのは、結局どれも Token と深く関係しているからです。

Claude Codeの使用枠を節約する：モデル選択、コンテキスト、キャッシュ、/compact

Sun, 19 Apr 2026 15:29:06 +0800

最近、Claude Code や Claude Max を使っていて同じ問題に当たる人が増えています。Pro、Max 5x、Max 20x を契約しているのに、少し使っただけで使用量の警告が出る、あるいは次のリセットを待つ必要がある、というものです。特に大きなプロジェクトで Claude Code に大量のファイルを読ませたり、複雑な bug を修正させたり、長いタスクを走らせたりすると、この感覚はかなり強くなります。

先に結論を書くと、使用枠は「時間」で線形に減るわけではありません。モデル、コンテキスト長、添付ファイル、コードベースの大きさ、会話履歴、ツール呼び出し、現在の容量によって変わります。同じ5時間ウィンドウでも、長く使える人もいれば、十数分で上限に近づく人もいます。多くの場合、アカウントがおかしいのではなく、1回ごとのリクエストが重すぎます。

この記事では、使用枠を節約するための実用的な習慣を整理します。

01 まず Claude の使用ウィンドウを理解する

Claude Pro と Max には使用制限があります。Claude Code の使用量は、Claude のWeb、デスクトップ、モバイルアプリと同じサブスクリプション枠を共有します。公式ヘルプでは、送信できるメッセージ数はメッセージの長さ、添付ファイルの大きさ、現在の会話の長さ、使うモデルや機能に左右されると説明されています。Claude Code ではさらに、プロジェクトの複雑さ、コードベースの大きさ、自動承認設定なども影響します。

大まかにはこう考えるとよいです。

Pro：軽い利用と小さなプロジェクト向け。
Max 5x：より頻繁な利用と大きめのコードベース向け。
Max 20x：重めの日常利用や高頻度の共同作業向け。
使用ウィンドウは5時間セッション単位でリセットされる。
長いメッセージ、長い会話、大きなファイル、複雑なタスクは使用量を早く消費する。
Opus のような強いモデルは Sonnet より早く制限に近づきやすい。

そのため、「20分しか使っていない」という説明だけでは状況は分かりません。重要なのは、その20分で Claude がどれだけのコンテキストを読んだか、どのモデルを使ったか、大きなファイルを何度も処理したか、同じ長い会話にタスクを追加し続けたかです。

02 まずやること：最も高いモデルをデフォルトにしない

Claude 系列は、おおよそ次のように使い分けられます。

Opus：最も強力。複雑な推論、設計判断、難しい bug に向く。
Sonnet：能力とコストのバランスがよく、日常的なコーディング作業に向く。
Haiku：軽量。簡単な分類、要約、形式変換などに向く。

日常的なスクリプト作成、小さな bug 修正、ドキュメント整理、コード説明なら、多くの場合 Sonnet で十分です。Opus は次のような場面に残しておくほうがよいです。

複雑なアーキテクチャ設計。
複数ファイルにまたがる深いリファクタリング。
再現しにくい bug。
長い推論が必要なトラブルシュート。
通常モデルが明らかに詰まったタスク。

Claude Code では /model でモデルを切り替えられますし、/config でデフォルトも設定できます。安定した使い方は、普段は Sonnet、重要な局面だけ Opus に切り替えることです。最初から最後まで Opus で押し切る必要はありません。

03 次にやること：コンテキストを制御し、古いタスクを引きずらない

コンテキストが長くなるほど、Claude が毎回処理する内容が増え、使用量も増えます。Claude Code の公式ドキュメントでも、コンテキストを能動的に管理することが推奨されています。

無関係なタスクに切り替えるときは /clear で履歴を消す。
現在のタスクが一段落したが重要な文脈は残したいときは /compact で圧縮する。
何がコンテキストを使っているか知りたいときは /context を使う。
状態を常に見たい場合は status line を設定する。

使いやすいリズムは次の通りです。

小さな段階が終わった：/compact
大きなタスクが終わった：/clear
無関係な作業に切り替える：/clear
コンテキスト使用量が高くなってきた：早めに /compact

/compact は前の会話を要約し、重要なタスク状態、結論、ファイルパス、TODO を残しつつ、後続リクエストに持ち込む履歴を減らします。後ろに重点を書いてもよいです。

`1`	`/compact 変更済みファイル、テスト結果、残りTODO、重要な設計判断を残す`

自動圧縮を待つ必要はありません。公式ドキュメントでは、Claude Code はコンテキストが上限に近づくと自動圧縮すると説明されていますが、段階の区切りで手動圧縮するほうが制御しやすいです。

04 三つ目：長い会話と大きなファイルは毎回のリクエストを重くする

「もう一言聞いただけだから安いはず」と思いがちです。しかし長い会話では、その一言の背後に大量の履歴、ファイル要約、ツール定義、システムルールが付いてくることがあります。

特にコンテキストを増やしやすいものは次の通りです。

ずっと消していない長い会話。
Claude に大きなファイル全体を読ませること。
長いログ、ビルド出力、テスト出力を貼ること。
スクリーンショットや画像を一度に大量に入れること。
リポジトリ全体を何度もスキャンさせること。
長すぎる CLAUDE.md。
多すぎる MCP server。

節約するなら、ログは重要なエラーだけ、テスト出力は失敗部分だけにします。大きなファイルは、まず rg、head、tail、シンボル検索で位置を絞り、必要な部分だけ読ませます。コマンドラインで絞れる内容を、丸ごとコンテキストに入れないほうがよいです。

05 四つ目：キャッシュを理解する。ただし過信しない

Anthropic の Prompt Caching は、繰り返される prompt の前方部分をキャッシュします。デフォルトのキャッシュ寿命は5分で、1時間キャッシュもサポートされています。キャッシュがヒットすると、繰り返し使う大きなコンテキストを毎回完全に再処理せずに済むため、コスト削減や使用枠の効率改善につながります。

ただしキャッシュには制限があります。

テキストや画像を含め、内容が完全一致する必要がある。
デフォルトのキャッシュは短命。
モデル、ツール、システムプロンプト、コンテキスト構造を変えるとヒット率が下がることがある。
出力 token はキャッシュで消えるわけではなく、回答生成分は必要。
Claude Code が具体的にどうキャッシュを使うかは製品実装の詳細なので、永続的な「無料メモリ」と考えないほうがよい。

実際の利用で大事なのは、キャッシュの細部を研究することではなく、セッションを安定させることです。

同じ段階ではモデルを頻繁に切り替えない。
作業中に大量のルールを何度も書き換えない。
同じタスクの途中で新しい画像を次々追加しない。
長いタスクを長時間放置したあと、いきなり大きなリクエストを投げない。
段階が終わったら /compact する。

こうすると、繰り返しのコンテキストを再利用しやすくなり、後続リクエストも軽くなります。

06 ピーク時間について：避けられるなら避ける。ただし固定公式にしない

ネット上では、特定の時間帯は使用枠が厳しいという話をよく見かけます。公式ヘルプの表現はもっと慎重で、送信可能数は Claude の現在の容量、会話の長さ、添付ファイル、モデル、機能に影響されるとされています。つまり、ピーク時の容量は体験に影響する可能性がありますが、特定地域の特定時間を永続的な固定ルールとして扱うべきではありません。

実用的には次のように考えます。

大きなリファクタリングや重い分析は、自分のネットワークとサービスが安定している時間に行う。
すぐ離席する直前に超長タスクを始めない。
長時間離れる予定があるなら、先に /compact または /clear する。
小さな修正なら、長いコンテキストのまま Opus で強引に走らせない。

固定の「何時から何時は使わない」というルールを覚えるより、このほうが安定します。

07 CLAUDE.md、rules、MCP、skills を軽くする

Claude Code はセッション内でプロジェクトルール、ツール情報、一部の環境コンテキストを読み込みます。公式ドキュメントでも、汎用ルールと専用ルールを分け、毎回大量の無関係な内容を読み込まないようにすることが推奨されています。

おすすめの分け方は次の通りです。

CLAUDE.md：全体に常に適用される最小限のルールだけ。
rules：特定パスや特定ファイルタイプに必要なルール。
skills：投稿、デプロイ、画像生成、コードコミットなどの特定ワークフロー。
MCP：現在のタスクで本当に使う server だけ有効にする。

CLAUDE.md が何百行、何千行もあると、毎回その分を持ち込みます。たまにしか使わない手順は skill に移し、必要なときだけ呼び出すほうが軽くなります。

MCP も同じです。ツールが多いほど効率が上がるとは限りません。Claude Code のドキュメントでは、/mcp で不要な server を確認して無効化し、/context で何がコンテキストを使っているか確認できると説明されています。

08 実用コマンド一覧

日常的によく使うのは次のコマンドです。

/model

モデルを切り替える。通常は Sonnet、複雑な推論では Opus。

/clear

現在のコンテキストをクリアする。無関係なタスクに切り替えるときに使う。

`1`	`/compact`

会話履歴を圧縮する。段階が終わったが同じタスクを続けるときに使う。

`1`	`/context`

コンテキスト使用量を確認し、何が場所を取っているか調べる。

/status

現在のサブスクリプションや使用量関連の状態を見る。公式ヘルプでも残り割り当ての確認に推奨されています。

/mcp

MCP server を確認、管理し、現在使わないツールを無効化する。

API 課金で使っている場合は /cost も参考になります。ただし Pro/Max サブスクリプションでは、公式ドキュメントが /cost のドル見積もりは請求の基準ではないと説明しています。サブスクリプション利用者は /stats や /status の利用情報を見るほうが適しています。

09 使用枠を節約する作業フロー

使いやすい流れは次のようになります。

新しいタスクの前に /clear する。
デフォルトは Sonnet にする。
Claude にはまずプロジェクト構造と重要ファイルだけを読ませ、リポジトリ全体を一気に読ませない。
小さな段階が終わるたびに /compact する。
難しい詰まりどころだけ Opus に切り替える。
ログ、エラー、テスト出力は絞ってから渡す。
タスク完了後は /clear し、古いコンテキストを引きずって新しい作業を始めない。
定期的に CLAUDE.md、MCP、skills を見直し、常駐コンテキストを小さくする。

この流れの核心は、Claude に毎回「今本当に必要なもの」だけを見せることです。

10 まとめ

Claude Code の使用枠がすぐ尽きる原因は、たいてい1つではありません。高コストなモデル、消していない長い会話、多すぎるファイルやログ、重い MCP とルール、キャッシュ命中率の低下、ピーク時の容量変動が重なって起こります。

節約の要点はシンプルです。

日常作業は Sonnet を優先する。
Opus は本当に複雑な問題に残す。
段階が終わったら /compact。
タスクを切り替えるときは /clear。
/context でコンテキスト肥大化の原因を探す。
CLAUDE.md、rules、MCP、skills を軽くする。
リポジトリ全体、ログ全体、大量の画像をそのまま入れない。

同じ Pro や Max でも、どれだけ作業できるかはコンテキスト管理に大きく左右されます。コンテキストを小さくし、タスクの境界をはっきりさせると、Claude Code はかなり安定して使いやすくなります。

参考リンク

Claude Help Center：Using Claude Code with your Pro or Max plan：https://support.claude.com/en/articles/11145838-using-claude-code-with-your-pro-or-max-plan
Claude Help Center：About Claude’s Max Plan Usage：https://support.anthropic.com/en/articles/11014257-about-claude-s-max-plan-usage/
Claude Code Docs：Manage costs effectively：https://code.claude.com/docs/en/costs
Anthropic Docs：Prompt caching：https://docs.anthropic.com/en/docs/build-with-claude/prompt-caching

Firecrawlプロジェクト整理：AI Agent向けのWeb検索・スクレイピング・操作API

Wed, 15 Apr 2026 13:45:03 +0800

Firecrawl の位置づけは明確です。Webページを、AI Agentが扱いやすいデータに変換するためのツールです。単なるクローラースクリプトではなく、検索、単一ページのスクレイピング、サイト全体の巡回、ページ操作、構造化抽出、AgentワークフローをAPIとしてまとめ、モデルや自動化システムがWebページ内のノイズに悩まされにくくします。

01 何を解決するのか

多くのAIアプリケーションはWebページを読む必要があります。しかし実際のWebは扱いやすくありません。JavaScriptで描画されるページ、ポップアップ、ページネーション、ログイン状態、Bot対策、PDFやDOCXなどHTML以外のコンテンツ、本文とは関係のないナビゲーション、広告、スクリプト、スタイルが混在しています。

Firecrawl が解決しようとしているのは、この中間層の問題です。アプリケーションは「このページ/このサイト/このテーマのデータが欲しい」と指定するだけで、Firecrawlがページを開き、取得し、クリーニングし、LLMで使いやすいMarkdown、HTML、スクリーンショット、JSONとして返します。

この種のツールの価値は、「URLにリクエストできるか」ではありません。複雑なWebページを安定して使えるデータに変換できるかが重要です。RAG、AI検索、競合調査、自動資料収集、Webコンテンツ監視では、この層がシステム内の面倒な配管になりがちです。

02 主な機能

FirecrawlのREADMEでは、機能がいくつかの領域に分けられています。

Search：Webを検索し、検索結果ページの本文まで取得する。
Scrape：単一URLをMarkdown、HTML、スクリーンショット、構造化JSONに変換する。
Interact：ページを取得した後、プロンプトやコードでクリック、スクロール、入力、待機などを実行する。
Agent：欲しい情報を直接説明すると、Agentが自動で検索、遷移、結果の取得を行う。
Crawl：Webサイト配下の複数ページを取得する。
Map：Webサイト内のURLを素早く発見する。
Batch Scrape：大量のURLを非同期で一括取得する。

名前だけを見ると「スクレイピングサービス」に見えます。しかし機能全体を見ると、AIアプリケーションのデータ入口に近い存在です。検索は情報源を見つけ、スクレイピングは内容を整え、操作機能は動的ページを扱い、Agentは「情報を探す」という作業をさらに自動化します。

03 AI Agentに向いている理由

従来のクローラーは、URLが既知であり、ページ構造も理解していることを前提にする場合が多いです。しかしAgentの場面ではそうとは限りません。ユーザーは「ある会社の最新料金ページにあるプラン差分を調べて」と頼むだけかもしれません。システム側は自分で検索し、ページを開き、内容を比較し、出典を返す必要があります。

Firecrawlの Agent エンドポイントは、このようなタスクを想定しています。自然言語のプロンプトだけで動かすことも、指定したURL範囲に限定して動かすこともできます。構造化された結果が必要な場合は、schemaと組み合わせて固定フィールドで出力できます。

アプリケーション層にとっては、次の2つの利点があります。

Webサイトごとに個別のパーサーを書く必要がない。
返ってきた結果をLLM、データベース、後続の自動化フローに渡しやすい。

もちろん、すべてのカスタムクローラーを置き換えるわけではありません。制約が強く、高頻度で、大規模で、フィールドが非常に安定している取得タスクでは、専用の解析ロジックを書いたほうが安く、制御もしやすい場合があります。Firecrawlは、情報源が分散し、ページ構造が変わりやすく、AIワークフローに素早く接続したい場面に向いています。

04 MCP、CLI、インテグレーション

FirecrawlはAgent向けツールチェーンにも明確に寄せています。READMEにはMCP Serverの接続方法があり、AI coding agent向けのSkill/CLI初期化コマンドも用意されています。

つまり、バックエンドサービスからAPIとして呼ぶだけでなく、Claude Code、OpenCode、Antigravity、MCPクライアントなどのワークフローに直接入ることも想定しています。Agentに調査、Web取得、内容整理をよく任せる人にとっては、API呼び出しを手書きするより軽い導入方法です。

Zapier、n8n、Lovableなどのプラットフォーム連携も挙げられています。この方向性は実用的です。Webデータは必ずしもコードにだけ入るわけではなく、自動化テーブル、ローコードフロー、コンテンツ制作システム、社内ナレッジベースにも流れます。

05 オープンソース、セルフホスト、ライセンス境界

Firecrawlはオープンソースプロジェクトです。メインリポジトリは主に AGPL-3.0 でライセンスされています。READMEでは、SDKと一部のUIコンポーネントは MIT ライセンスであり、詳細は各ディレクトリのLICENSEファイルを見る必要があるとも説明されています。

ここは注意が必要です。クラウドサービスとして使うだけなら、主な関心はAPIコスト、安定性、コンプライアンス上の境界です。一方で、セルフホストして外部にサービス提供するなら、AGPL-3.0 の義務をきちんと確認する必要があります。

READMEでは、Webサイトのポリシー、プライバシーポリシー、利用規約を尊重するようにも注意しています。また、デフォルトで robots.txt に従うと説明されています。この種のツールは強力になるほど、コンプライアンスと取得範囲の設計を後回しにせず、最初からシステムに組み込む必要があります。

06 向いている場面

Firecrawlを優先的に検討したいのは、次のような場面です。

RAGシステム向けにWeb資料を取得し、きれいなMarkdownを直接得たい。
AI検索や調査アシスタントで、検索後にページ全体を読む必要がある。
JavaScriptが重いサイトを取得したいが、自前でブラウザクラスターを保守したくない。
競合、価格、ドキュメント、ニュース、採用ページなどの公開情報を監視したい。
MCPクライアントやAI coding agentにリアルタイムのWeb読み取り能力を追加したい。
クローラー基盤を先に作るのではなく、Webデータ製品を素早く検証したい。

あまり向いていない場面もはっきりしています。

対象サイトのフィールドが少なく、構造も安定していて、簡単なスクリプトで十分な場合。
取得量が非常に大きく、開発保守コストより実行コストのほうが重要な場合。
データソース、リトライ戦略、Bot対策への振る舞い、監査要件を細かく制御する必要がある場合。
ライセンスやコンプライアンス要件として、AGPLコンポーネントや外部クラウドサービスを導入できない場合。

07 短い判断

Firecrawlの価値は、「WebページからAIで使えるデータへ」という面倒な流れをプロダクト化している点にあります。検索、取得、クリーニング、操作、バッチ処理、Agent型の資料収集を1つのインターフェースにまとめているため、AIアプリケーション開発者には使いやすい選択肢です。

モデルに実際のWebページを読ませる必要がよくあり、特に情報源が分散し、構造が不安定で、MCPやAgentワークフローにも接続したいなら、Firecrawlはツール箱に入れておく価値があります。逆に、固定サイトから低コストで大量収集するだけなら、従来のクローラーや専用パーサーのほうが適している場合があります。

Hermes Agent とは: 概要、利点、クイックスタート、OpenClaw との比較

Sun, 12 Apr 2026 14:07:58 +0800

最近オープンソース AI エージェントに注目している場合、Hermes Agent は注目に値する新しいプロジェクトです。ヌース・リサーチ社によって発売されました。その中心的なセールスポイントは、「別のチャットシェルを作成する」ことではなく、長期記憶、スキルの蓄積、コンテキストファイル、MCP 拡張機能、メッセージゲートウェイ、およびサブエージェントの並列処理の機能を統合エージェント実行環境に統合しようとすることです。

公式 README から判断すると、Hermes Agent の目標は非常に明確です。ローカル CLI アシスタントのように、またはクラウドに常駐するパーソナルアシスタントのようにターミナル内で動作し、Telegram、Discord、Slack、WhatsApp、Signal などのチャネルを通じて継続的に話しかけることができます。この位置付けは、「コードアシスタント」、「自動化アシスタント」、「パーソナル AI ワークベンチ」を 1 つのシステムに組み合わせたいユーザーにとって、非常に魅力的です。

01 エルメス代理店紹介

Hermes Agent は、Nous Research が開発したオープンソースの自己改善型 AI エージェントです。 Nous Portal、OpenRouter、OpenAI、カスタム OpenAI 互換エンドポイントなど、複数のモデルプロバイダーをサポートします。また、ローカルターミナル、Docker、SSH、Daytona、Modal などのさまざまな実行バックエンドでの実行もサポートされます。

多くの「ツールを呼び出すことができるチャットボット」との最大の違いは、Hermes は 1 つのセッションでのツール呼び出しだけを重視するのではなく、セッション全体での継続的な機能構築を重視していることです。公式ドキュメントでは、このアイデアをいくつかの部分に分割しています。

永続メモリ: MEMORY.md および USER.md を通じて、環境、プロジェクト、およびユーザー設定に関する重要な情報を保存します。
スキルシステム: 複雑なタスクで学習したプロセスをスキルにまとめ、オンデマンドでロードします。
コンテキストファイル: AGENTS.md、SOUL.md、.cursorrules およびその他のファイルを自動的に読み取り、プロジェクト規約をセッションに直接挿入します。
MCP の統合: MCP 互換のツールサーバーに接続して、データベース、GitHub、ファイルシステム、クロールなどの機能を拡張できます。
メッセージゲートウェイ: CLI に加えて、Telegram、Discord、Slack、WhatsApp、Signal、電子メール、その他のポータル経由でも使用できます。

一言で要約すると、Hermes Agent は「メモリ、スキル、スケーラビリティ、およびマルチエンドアクセスを備えたユニバーサルエージェント操作層」に似ています。

02 そのメリットは何ですか?

1. CLI ワークフローとメッセージングワークフローの両方をカバーする

エージェントプロジェクトの多くは「端末内開発アシスタント」か「チャットプラットフォームロボット」のどちらかです。エルメスがやりたいのは、これら 2 つを融合することです。ターミナルで hermes を直接実行することも、ゲートウェイを起動して Telegram または Discord から同じアシスタントを継続することもできます。

このデザインの良いところは、エルメスが「コンピューターの前に座っているときにだけ使える」ということに限定されていないことです。クラウドまたは VPS に導入すると、常にオンラインのパーソナル AI アシスタントになります。

2.「長期使用」をより徹底して考える

ヘルメスは単にチャットやツールの調整を行うだけではなく、長期的な蓄積も重視しています。

無限のヒープコンテキストではなく、制限された永続メモリ。
成功したプロセスを保存して再利用できるスキルシステムがあります。
過去のセッションを検索し、セッション間の呼び出しを実行する機能。
プロジェクト内のコンテキストファイルを読み取ることができるため、プロジェクトの背景を毎回繰り返し説明する必要性が軽減されます。

これは、固定されたコードベース、固定されたワークフロー、固定されたチーム基準で繰り返し作業することが多いユーザーにとって重要です。これは、エージェントが「今回はあなたのために何かをしてくれる」だけではなく、徐々にあなたの環境をよりよく理解するようになるということを意味します。

3. MCP サポートにより拡張性が非常に強力になります

hermes の公式ドキュメントでは、MCP を明確にサポートしており、stdio と HTTP という 2 つのアクセス方法について説明しています。言い換えれば、外部システムにすでに MCP サーバーがある限り、Hermes は理論的には低コストでそれにアクセスできます。

これは、単一システムに対して毎回個別のプラグインを作成するよりも柔軟です。 MCP エコシステムに多数のツールを蓄積している人にとって、Hermes へのアクセスコストははるかに低くなります。

4. OpenClaw ユーザーに優しい

これはとても興味深いですね。 Hermes README には hermes claw migrate が直接提供されており、構成、メモリ、スキル、API キー、メッセージングプラットフォームの設定などを OpenClaw からインポートできることが記載されています。

これは、既存のエコロジーを完全に無視して車輪を再発明しているわけではなく、一部の OpenClaw ユーザーを潜在的な移行ターゲットとして明確にみなしていることを示しています。

03 すぐに始める方法

公式に推奨されている Hermes Agent のインストール方法は非常に簡単です。

`1`	`curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh \| bash`

公式の手順では、Linux、macOS、WSL2、Android の Termux がサポートされています。 README には、ネイティブ Windows はまだサポートされていないため、Windows ユーザーには WSL2 を使用することが推奨されていることが明記されていることに注意してください。

インストールが完了したら、通常は最初にシェルを更新します。

`1`	`source ~/.bashrc`

その後、直接開始できます。

hermes

段階的に完全な初期化を完了したい場合、最も心配のないコマンドは次のとおりです。

`1`	`hermes setup`

公式ドキュメントと README によると、初めて開始するには次の手順に従うことができます。

hermes setup を実行して、基本構成を完了します。
hermes model を使用して、モデルプロバイダーとモデルを選択します。
hermes tools スイッチにはツールセットが必要です。
hermes を直接実行して対話型 CLI に入ります。
Telegram や Discord などのチャネルに接続する場合は、hermes gateway の構成を続けます。

OpenClaw ユーザーの場合は、移行コマンドを確認することもできます。

`1`	`hermes claw migrate --dry-run`

正式にインポートするかどうかを決定する前に、移行可能なコンテンツをプレビューします。

04 と OpenClaw はどうですか?

公式ドキュメントや README から判断すると、Hermes Agent と OpenClaw は単に「誰が誰を置き換えるか」というだけではなく、位置づけにおいては明らかに重複していますが、焦点は異なります。

ヘルメスエージェントとはどのようなものですか?

エルメスはどちらかというとエージェントコアとワークフローシステムに重点を置いた製品です。それが強調していることは次のとおりです。

CLI の経験
記憶とスキルの蓄積
プロジェクトコンテキストファイル
MCP拡張子
サブエージェントの並列処理
ローカル、コンテナ、リモート、サーバーレス環境間で実行バックエンドを切り替える

あなたの主な要求が「エージェントにプロジェクトをよりよく理解させ、継続的な再利用機能を向上させ、MCP と開発ワークフローへの接続を容易にする」ことである場合、Hermes の方向性はより便利になります。

OpenClaw とはどのようなものですか?

OpenClaw は、パーソナル AI アシスタントとメッセージングゲートウェイを中心としたプラットフォームです。それは次のように強調します。

メッセージチャネルへの非常に豊富なアクセス
ゲートウェイを実行する常駐者
ブラウザーでの UI の制御
デバイスのペアリング、リモートアクセス、ステータス管理
音声、モバイル、キャンバスなどの強力なアシスタント形式。

「さまざまなチャットチャネルやデバイス上でパーソナル AI アシスタントを安定させる」ことが主なニーズであり、コントロールパネルを使用して均一に管理したい場合は、OpenClaw の製品感が強くなります。

より現実的な選択の提案

この 2 つは単純に次のように理解できます。

ヘルメスエージェント：「成長する総合エージェントのワークベンチ」
OpenClaw: 「マルチチャネル常駐パーソナル AI アシスタントプラットフォーム」のようなもの

もちろん、この違いは絶対的なものではなく、双方とも機能を拡張し続けており、Hermes は OpenClaw からの移行パスも提供しています。しかし、少なくとも現在の公開情報から判断すると、Hermes は「メモリ、スキル、コンテキスト、MCP、開発ワークフロー」の分野でより顕著です。 OpenClaw は、「ゲートウェイ、マルチチャネル、コントロール UI、デバイスアクセス」の分野でより成熟しています。

05 どんな人に試してほしいの？

あなたが次のカテゴリーに属する人であれば、Hermes Agent を最初に試してみる価値があります。

あなたはターミナルで AI ツールを広範囲に使用しており、エージェントがコードベースとプロジェクトルールをよりよく理解できるようになることを期待しています。
AGENTS.md、スキル、記憶、MCP 能力を組み合わせたいと考えています。
単一のモデルベンダーに縛られることなく、柔軟にプロバイダーを切り替えられるようにしたいと考えています。
以前に OpenClaw を使用していましたが、今度はよりエージェント指向のワークフローの方向を試したいと考えています。

より多くのモバイルリーチ、さまざまな IM プラットフォームへのアクセス、ブラウザコンソール、および「常時接続のパーソナルアシスタントの感覚」を重視する場合は、OpenClaw が依然として魅力的です。

参考リンク

Hermes Agent GitHub: https://github.com/NousResearch/hermes-agent
ヘルメスエージェントドキュメント: https://hermes-agent.nousresearch.com/docs/
Hermes Features Overview: https://hermes-agent.nousresearch.com/docs/user-guide/features/overview
Hermes MCP: https://hermes-agent.nousresearch.com/docs/user-guide/features/mcp/
OpenClaw GitHub: https://github.com/openclaw/openclaw
OpenClaw Getting Started: https://docs.openclaw.ai/start/quickstart
OpenClaw Control UI: https://docs.openclaw.ai/web/control-ui

MCPを捨てますか？ CLI がエージェントのデフォルトのツール層になりつつある理由

Fri, 10 Apr 2026 21:55:12 +0800

過去 1 年間、エージェントツールチェーンに関する議論は、次の 1 つの問題にますます集中してきました。

MCP (モデルコンテキストプロトコル) はツールの呼び出しを簡単にしますか? それとも、もともと単純だったものを複雑にしますか?

CLI は、ほとんどの日常的な開発タスクにとって、より実用的なデフォルトになりつつあります。

コストの違いは「経験の問題」ではなく、桁違いの問題です

MCP に対する実際の最大のプレッシャーはトークンのオーバーヘッドです。

一般的なシナリオでは、MCP は実際にタスクを実行する前に、多数のツールスキーマをロードする必要があります。 GitHub MCP サーバーを例に挙げると、初期化で数万のトークンが消費される可能性があります。長いタスクの場合、これはコンテキストバジェットを直接圧迫します。

コミュニティのベンチマークは、同じ結論を繰り返し示しています。

1 回の MCP 呼び出しのコストは、通常、CLI の数倍から数十倍になります。
失敗した再試行のコストも高くなります (接続の再構築とコンテキストの再ロード)。

これは「遅い」というギャップではなく、むしろ API 料金、レイテンシー、安定性の問題にまで拡大します。

モデルが自然に「CLI に精通している」理由

見落とされがちな事実は、トレーニングの分布です。

LLM は、トレーニング中にコマンド、出力、エラーレポート、スクリプト、マニュアルページなどの大量の端末テキストを確認しました。言い換えれば、CLI 対話モードは本質的にモデルの「母国語入力」に近いものになります。

それどころか、MCP の JSON-RPC とツールスキーマは、ここ 2 年間で大規模に登場したばかりの新しいパラダイムです。モデルは確かに学習できますが、親しみやすさと圧縮効率は通常、CLI などの歴史的コーパスほど良くありません。

これは、その理由を何度も説明するものでもあります。

目標は同じですが、CLI 命令は短くなります
出力は推論を直接続行するのにより適しています。
エラー回復パスの安定性が向上

安全と隔離：MCPにはまだ補講の余地があります

MCP がセキュリティを実現できないわけではありませんが、エコシステムはまだ初期段階にあります。

現在の一般的な懸念事項は次のとおりです。

ツール中毒
サービス動作のドリフト (ラグプル)
同名のツール「シャドウイング」

もちろん、CLI にもセキュリティの問題 (インジェクション、不正アクセス、パスのリスク) がありますが、そのプロセスモデル、権限の境界、監査リンクは数十年にわたるエンジニアリングの実践によって検証されています。本番環境では、この「予測可能性」が重要です。

これはMCPが無価値であるという意味ではありません

私はMCPを放棄すべきではないと思います。

より合理的な位置付けは次のとおりです。

CLI は実行層 (ローカル、低遅延、高頻度の呼び出し) を担当します。
MCP は接続層 (リモートサービスディスカバリ、統合認証、監査、マルチテナント) を担当します。

一般に、ハイブリッドアーキテクチャ: CLI + MCP Gateway とも呼ばれます。

多数のリモートシステムに接続し、統合された権限管理とコンプライアンス監査を実行する必要がある場合、MCP には依然として明白な価値があります。しかし、「エージェントが開発タスクを迅速に完了できるようにする」という点では、多くの場合、CLI ファーストの方が現在のモデルの機能の境界に沿っています。

今日のエンジニアリングの現実では、CLI はエージェントの母国語に似ています。 MCP は、唯一の実行プロトコルではなく、接続プロトコルとして適しています。