AI Agent on KnightLiブログ

GitHub AIオープンソースプロジェクト分類：Coding AgentからRAGナレッジベースまで

Thu, 21 May 2026 08:53:13 +0800

このページでは、GitHub上のAIプロジェクトを用途別に整理します。AIコーディングとCoding Agent、Agentスキルとワークフロー、RAGとナレッジベース、マルチモーダル制作、ローカルモデルと推論、垂直アプリケーションと自動化、AIアプリ開発基盤などの方向を扱います。新しいプロジェクトが増えた場合も、同じ構造で追加できます。

カテゴリ概要

カテゴリ	プロジェクト数	まず見るべき人
AIコーディングとCoding Agent	19	Claude Code、Codex、Cursor、ターミナルAgent、リポジトリ自動化をよく使う人
Agentスキルとワークフロー	7	AIコーディング、研究、制作フローを標準化したい人
RAG、ナレッジベース、メモリ	7	文書検索、ナレッジベース、長期メモリ、Webクロール、構造化抽出が必要な人
垂直アプリケーションと自動化	7	金融、取引、Xianyu監視、デスクトップ操作、ブラウザ自動化などを見たい人
マルチモーダルとコンテンツ制作	5	画像、動画、文字起こし、プロンプト集、コンテンツ配信を扱う人
AIアプリ開発基盤	3	AIアプリ、ブラウザ自動化、Prompt/MCPツールチェーンを構築する開発者
ローカルモデルと推論	1	ローカルDeepSeek、推論エンジン、ハードウェア適配に関心がある人

この分布から、現在のAIオープンソースプロジェクトではAIコーディングツールが最も多く、その次にAgentワークフロー、RAGナレッジベース、具体的な応用シナリオが続くことがわかります。純粋なモデル推論プロジェクトは少なめです。ローカルデプロイの多くは、単一のGitHubプロジェクトではなく、モデル、GPU、デプロイ方案を中心に整理されるためです。

AIコーディングとCoding Agent

このカテゴリは、コード理解、コード修正、エンジニアリングフロー、ターミナルAgentに焦点を当てます。最も大きいグループで、19 件のプロジェクトがあります。

プロジェクト	記事	GitHub	主な用途	向いている人
Ralph	Ralph：Claude CodeとAmpを自律開発ループにする	snarktank/ralph	PRD、計画、実行、レビューの流れでClaude Code / Ampを進める	Agentコーディングの流れを整えたい人
Claude-Mem	Claude-Mem：Claude Codeにセッション横断の長期メモリを追加する	thedotmack/claude-mem	Claude Codeにセッション横断メモリを追加	Claude Codeを頻繁に使う開発者
Claude Code Hooks Mastery	Claude Code Hooks Mastery：13個のHooksライフサイクル入門	disler/claude-code-hooks-mastery	Claude Code Hooksのライフサイクルと自動化制御を学ぶ	Claude Codeをカスタマイズしたい人
Compound Engineering Plugin	Compound Engineering Plugin：AIコーディングを計画、実行、レビューの循環にする	EveryInc/compound-engineering-plugin	AIコーディングを計画、実行、レビューに分ける	工学的なAIコーディングを重視する人
free-claude-code	free-claude-code：Claude CodeをOpenRouter、DeepSeek、ローカルモデルにつなぐ	Alishahryar1/free-claude-code	proxy経由でClaude Codeを複数モデルバックエンドに接続	Claude Codeのコストを下げたい人
Hermes Agent	Hermes Agentとは：概要、利点、クイックスタート、OpenClaw比較	NousResearch/hermes-agent	ツール呼び出しとタスク実行に対応するローカルAgentフレームワーク	ローカルAgentを動かしたい人
OpenHarness	OpenHarnessとは：オープンソースAgent Harnessでできること	HKUDS/OpenHarness	Agent HarnessとマルチAgent実行フレームワーク	Agent編成を研究する人
CodexBridge	Codexを中国系大模型に接続する：OpenAI互換APIとCodexBridge	begonia599/CodexBridge	CodexをOpenAI互換モデルAPIに接続	Codexを国内モデルにつなぎたい人
ccx	CCXでCodex向けOpenAI互換APIを一元管理する	BenedictKing/ccx	Claude、Codex、GeminiなどのAPI proxy管理	複数モデルを切り替える人
cc-haha	cc-haha：Claude Codeをデスクトップワークスペースにする	NanmiCoder/cc-haha	Claude Codeのデスクトップ作業台とComputer Use入口	GUIが好きなClaude Codeユーザー
DeepSeek-TUI	DeepSeek-TUI：DeepSeek V4をターミナルのコーディングAgentにする	Hmbown/DeepSeek-TUI	ターミナルでDeepSeekコーディングAgentを動かす	DeepSeekとCLIユーザー
Open Design	Open Design：Claude CodeとCodexをAIデザインツールにする	nexu-io/open-design	Claude Code / Codexをデザイン生成に参加させる	Agentでデザインプロトタイプを作りたい人
agentmemory	agentmemory：Claude Code、Codex、Cursorに永続メモリを追加する	rohitg00/agentmemory	Coding Agentに永続メモリを追加	長期プロジェクトを保守する開発者
Graphify	Graphify：コードベースをAIが問い合わせできる知識グラフにする	safishamsi/graphify	コードベースを知識グラフ化し、重複したファイル読込を減らす	大規模コードベースのユーザー
CC Switch	CC Switch：Claude Code、Codex、Gemini CLI、OpenClawをまとめて管理する	farion1231/cc-switch	複数AI CLIとアカウント/設定の切替管理	複数CLIを併用する人
Warp	Warpオープンソース化：ターミナルからAgentic Development Environmentへ	warpdotdev/warp	Agenticターミナルと開発環境	ターミナルをよく使う人
opencode	opencode、Claude Code、Codexの違い：オープンソースAIコーディングツールガイド	anomalyco/opencode	オープンソースAIコーディングAgent	Claude Code / Codex代替を探す人
9Router	9Router：Claude Code、Codex、Cursorを一つのAIルーターにつなぐ	decolua/9router	AIコーディングモデルのルーティングとtokenコスト制御	複数ツール、複数モデルのユーザー
goose	goose：デスクトップ、CLI、API一体のオープンソースAI Agent	aaif-goose/goose	デスクトップ、CLI、API対応のオープンソースAgent	汎用Agentワークスペースが欲しい人

Agentスキルとワークフロー

このカテゴリは、AI能力を再利用可能なスキル、プロセス、仕様に固定することに焦点を当てます。7 件のプロジェクトがあります。

プロジェクト	記事	GitHub	主な用途	向いている人
mattpocock/skills	Vibe Codingを拒否する：Matt PocockのskillsリポジトリがAIコーディングに工程制約を加える	mattpocock/skills	SkillsでAIコーディングの流れを制約する	Agentに工程規律を加えたい人
Superpowers	Superpowers：Coding Agentを工程フローに戻すスキルフレームワーク	obra/superpowers	Agentic skills frameworkと開発方法論	Coding Agentを体系的に使いたい人
Prompt-Vault	Prompt-Vault：AIコーディング能力を試すPrompt仕様ライブラリ	w512/Prompt-Vault	AIコーディング評価用prompt仕様を集める	モデル/ツール評価者
web-video-presentation	web-video-presentation：記事を録画可能なWeb動画にするAgent Skill	ConardLi/garden-skills	記事を録画可能なWeb動画へ変換	コンテンツ制作者と自動化ユーザー
nuwa-skill	nuwa-skill：「人を蒸留する」を実行可能フローにする	alchaincyf/nuwa-skill	人物の表現と思考フローをSkillで再現	スタイル型Agentを作る人
Scientific Agent Skills	Scientific Agent Skills：研究ワークフローをAI Agentに渡すスキル集	K-Dense-AI/scientific-agent-skills	科研ワークフロー向けSkill集	研究者、データ分析者、技術ライター
easy-vibe	easy-vibe：Vibe Coding初心者向け学習マップ	datawhalechina/easy-vibe	Vibe Coding入門マップ	AIコーディング初心者

RAG、ナレッジベース、メモリ

このカテゴリは、文書検索、ナレッジベース構築、長期メモリ、構造化抽出を扱います。7 件のプロジェクトがあります。

プロジェクト	記事	GitHub	主な用途	向いている人
LangExtract	Google LangExtract：LLMで長文から構造化データを抽出する	google/langextract	長文から構造化情報を抽出	情報抽出とデータ処理のユーザー
qmd	qmd：AI Agent向けローカルMarkdown文書検索	tobi/qmd	ローカルMarkdown文書検索	Markdownで知識管理する人
Firecrawl	Firecrawl：AI Agent向けWeb検索、クロール、操作API	firecrawl/firecrawl	Webクロール、検索、構造化データ入口	RAGとAgentデータ入口を作る人
RAGFlow	RAGFlow：オープンソースRAGエンジンの機能と使い方	infiniflow/ragflow	オープンソースRAGエンジン	企業ナレッジベースと文書Q&Aユーザー
OpenHuman	OpenHuman：オープンソース個人AI Agentのデスクトップ路線	tinyhumansai/openhuman	ローカル優先の個人AI Agentとメモリ層	個人データを統合したい人
OpenKB	OpenKB：文書を継続更新可能なLLMナレッジベースに編成する	VectifyAI/OpenKB	文書を更新可能なナレッジベースにする	文書ナレッジベースの保守者
PageIndex	PageIndex：ベクトルDBなしの推論型RAG文書索引	VectifyAI/PageIndex	ベクトルDBなしの推論型文書索引	新しいRAG手法に関心がある人

マルチモーダルとコンテンツ制作

このカテゴリは、画像、動画、文字起こし、コンテンツ配信を扱います。5 件のプロジェクトがあります。

プロジェクト	記事	GitHub	主な用途	向いている人
rembg	rembg：ローカル画像背景除去ツール	danielgatis/rembg	ローカル画像背景除去	EC、デザイン、画像処理ユーザー
awesome-gpt-image-2-prompts	GPT-Image 2プロンプト集：EC、ポスター、ポートレート、UI	EvoLinkAI/awesome-gpt-image-2-prompts	GPT-Image 2のプロンプトと事例集	AI画像生成とプロンプトユーザー
faster-whisper	faster-whisper：より速いWhisper文字起こしエンジン	SYSTRAN/faster-whisper	高性能speech-to-text	字幕、文字起こし、音声処理ユーザー
Pixelle-Video	Pixelle-Video：一つのテーマから短動画を生成するオープンソースAIエンジン	AIDC-AI/Pixelle-Video	テーマから短動画を生成するワークフロー	短動画とAIGC制作者
AiToEarn	投稿先が多すぎる？AiToEarnはAI Agentで制作者を助ける	yikart/AiToEarn	複数平台への配信と制作者自動化	コンテンツ運営者と制作者

ローカルモデルと推論

このカテゴリは、ローカルモデル実行と推論実験を扱います。現在は少なめで、1 件のプロジェクトがあります。

プロジェクト	記事	GitHub	主な用途	向いている人
ds4	DeepSeek 4をローカル実行：Apple Silicon MacでのAntirez ds4の試み	antirez/ds4	Apple SiliconでDeepSeek 4を試す	ローカルモデルと推論実験ユーザー

垂直アプリケーションと自動化

このカテゴリは、AgentやAI能力を金融、取引、ブラウザ、デスクトップ、EC監視などの具体的な場面に適用します。7 件のプロジェクトがあります。

プロジェクト	記事	GitHub	主な用途	向いている人
TradingAgents-CN	TradingAgents-CN：中国語ユーザー向けマルチAgent金融取引研究フレームワーク	hsliuping/TradingAgents-CN	マルチAgent金融取引研究フレームワーク	クオンツ、金融、Agent研究者
FinceptTerminal	FinceptTerminal：オープンソース金融端末、量化研究、AI Agentワークスペース	Fincept-Corporation/FinceptTerminal	金融端末、量化研究、AI Agent作業台	金融分析と量化ユーザー
Anthropic financial-services	Anthropic financial-services：金融Agentシナリオを再利用可能テンプレートにする	anthropics/financial-services	金融サービスAgentテンプレート	金融AI方案を作る人
ai-goofish-monitor	ai-goofish-monitor：AIでXianyu商品を自動監視するシステム	Usagi-org/ai-goofish-monitor	AI商品監視とXianyu自動化	中古取引監視ユーザー
CloakBrowser	CloakBrowser：PlaywrightとPuppeteer向けのより人間らしいブラウザ	CloakHQ/CloakBrowser	より人間らしいブラウザ自動化環境	ブラウザ自動化とAgent操作
UI-TARS-desktop	AIにPCを操作させる？UI-TARS-desktopがデスクトップ、ブラウザ、ツールを接続	bytedance/UI-TARS-desktop	デスクトップ、ブラウザ、ツール操作Agent	AIにPC操作を任せたい人
AI-Trader	AI-Traderとは：AI Agentが取引シグナルを出し、模擬取引する平台	HKUDS/AI-Trader	AI Agentの取引シグナルと模擬取引	金融Agentと取引研究者

AIアプリ開発基盤

このカテゴリは、AIアプリとAgentツールチェーン構築に必要な基盤コンポーネントを提供します。3 件のプロジェクトがあります。

プロジェクト	記事	GitHub	主な用途	向いている人
Prompt Optimizer	Prompt Optimizer：オープンソースのプロンプト最適化、テスト、MCPツール	linshenkx/prompt-optimizer	プロンプト最適化、テスト、MCPツール	Prompt engineeringとアプリ調整のユーザー
Playwright CLI	Playwright CLI入門：インストール、Skills、セッション、よく使うコマンド	microsoft/playwright-cli	coding agent向けブラウザ自動化CLI	ブラウザ操作が必要なAgentユーザー
Vercel AI SDK	Vercel AI SDKとは：TypeScript開発者向けAIアプリ統一ツールキット	vercel/ai	TypeScript AIアプリ開発SDK	フロントエンドとフルスタック開発者

Google I/O 2026まとめ：Gemini 3.5、Omni、Antigravity、システムレベルAgent

Thu, 21 May 2026 00:07:06 +0800

Google I/O 2026の主線は明確です。GoogleはGeminiを「モデル」や「チャットアシスタント」から、より大きなAgentエコシステムへ進めようとしています。質問に答えるだけではなく、Search、Android、開発者ツール、動画制作、ショッピング、Workspace、ハードウェア、エンタープライズ基盤に入り込み、より長いタスクの流れを支援する方向です。

この記事では、公式発表と開発者視点に基づき、Google I/O 2026の主要内容を整理します。実際の開発では、Google、Android Developers、Gemini APIの公式ドキュメントを基準にしてください。

一言でまとめると

Google I/O 2026のキーワードは agentic Gemini era です。

Googleは次のようなラインを発表、または強化しました。

Gemini 3.5 Flash：速度、実行能力、Agentワークフローを重視。
Gemini Omni：任意の入力からコンテンツを生成し、まず動画制作と編集に注力。
Gemini app：チャットアシスタントから、能動的で常時支援し、タスクを実行できる個人Agentへ。
Google Antigravity 2.0：AIコーディングツールからAgent優先の開発プラットフォームへ。
Gemini API Managed Agents：推論、ツール利用、コード実行が可能なホスト型AgentをAPIで作成。
Google AI Studio：モバイル、Androidネイティブ対応、Antigravityへのプロジェクト書き出しへ拡張。
Search、Shopping、YouTube、Workspace、Android：より強いGeminiとAgent機能を導入。

つまりGoogleは、単に「モデルがどれだけ賢いか」を見せる段階から、「モデルが製品、ツール、システムに入り、ユーザーのために実際にタスクを実行する方法」を示す段階へ進んでいます。

Gemini 3.5 Flash：プロンプトからアクションへ

Gemini 3.5は、GoogleがI/O 2026で発表した新世代モデルシリーズです。最初の公開上の焦点は Gemini 3.5 Flash です。

Googleはこれを単なる「より速いチャットモデル」としてではなく、実際のAgentワークフローのための高速エンジンとして位置づけています。公式の開発者向け記事では、3.5 Flashがフロンティア級の知能と高速性を組み合わせ、promptからactionへの移行を支えると説明されています。

主な意味は次の通りです。

Agentとcodingシーン向けに最適化。
より長いタスクチェーンとツール呼び出しを支援。
Antigravity、Gemini API、Google AI Studio、Android Studio、Gemini Enterpriseなどで提供。
高速応答、多段階実行、頻繁なツール呼び出しが必要なアプリに向く。

開発者にとって、Gemini 3.5 Flashは単なるモデル選択肢ではなく、Googleの新しいAgentツールチェーンの標準的な動力源の一つです。

Gemini Omni：動画と世界モデル能力が重点に

Gemini Omni はI/O 2026のもう一つの中核発表です。Googleは、任意の入力からコンテンツを作成し、現在は動画から重点的に始めると説明しています。

見どころは主に三つあります。

マルチモーダル入力：テキスト、画像、動画、音声などを参照として使える。
動画編集：一度生成して終わりではなく、自然言語で複数回動画を修正できる。
世界理解：物理、シーン、動き、物語、音声と映像の一貫性を重視。

これは、AI動画ツールが「一つのプロンプトで短編を生成する」段階から、「編集者と話すように段階的に修正する」段階へ進んでいることを示します。クリエイターにとって本当に価値があるのは一度きりの生成ではなく、制御可能で追跡でき、反復できる編集フローです。

Gemini App：チャットアシスタントから常時稼働の個人Agentへ

GoogleはGemini appもよりAgent的な方向へ明確に進めています。公式記事では、Gemini appがより能動的になり、日次ブリーフや常時支援を提供すると説明されています。

主なポイントは次の通りです。

Gemini 3.5 Flash がGemini appに入る。
新しいUIとより動的なインタラクション。
Gemini Spark のような個人AI Agentの概念。
Proactive daily briefsで、ユーザーが毎日知るべき情報を能動的に整理。
ユーザーが毎回チャットを始めるのではなく、7×24時間のバックグラウンド支援を重視。

この部分は一般ユーザーへの影響が最も大きいところです。以前のGeminiは「聞かれたら答える」助手に近いものでした。I/O 2026以降、Googleはそれを、タスクを継続的に追跡し、能動的にリマインドし、複数製品をまたいで協調する個人Agentに近づけようとしています。

Antigravity 2.0：開発者ツールはAgent優先へ

開発者向けで最も重要な発表の一つが Google Antigravity 2.0 です。

GoogleはAntigravityを agent-first development platform と位置づけています。I/O 2026以降、それはコードを書く支援だけでなく、アイデア、プロトタイプ、Agent編成、本番アプリの提供までを支援するものになります。

公式が挙げる主な変化は次の通りです。

Antigravity 2.0の独立デスクトップアプリ。
複数Agentの並列オーケストレーション。
動的subagents。
バックグラウンドのスケジュールタスク。
Google AI Studio、Android、Firebaseなどとの統合。
ターミナルユーザー向けのAntigravity CLI。
Agentの振る舞いとデプロイをカスタマイズするAntigravity SDK。

これは、AIコーディングツールが「コード補完 / 対話生成」の次の段階へ進んでいることを示しています。開発者が管理するのは、一つのチャットウィンドウではなく、複数の実行可能なAgentになります。

Gemini API Managed Agents：AgentをAPI能力としてホストする

Googleは Managed Agents in the Gemini API も発表しました。

公式説明によると、この種のAgentは一回のAPI呼び出しで作成でき、推論、ツール利用、隔離されたLinux環境でのコード実行が可能で、Antigravity agent harnessによって支えられます。

開発者にとって重要な点は次の通りです。

完全なAgent実行環境を自分で構築しなくてよい。
永続的で隔離された実行環境を得られる。
複数回のやり取りでファイルと状態を保持できる。
markdown skills、カスタム指示、テンプレートでAgentを拡張できる。
Interactions APIとGoogle AI Studioから利用できる。

この流れが成熟すれば、Agentプラットフォームはますますクラウドサービスに近づきます。開発者はモデルだけでなく、状態、ツール、実行環境、安全境界を持つAgentを呼び出すようになります。

Google AI Studio：prompt playgroundからアプリ生成入口へ

I/O 2026では、Google AI Studioの位置づけもさらに進みました。

主な変化は次の通りです。

Google AI Studio mobile appで、モバイルからアイデアを記録しプロトタイプを生成。
Workspace API統合により、AgentがGoogle Workspaceへ自然に接続。
プロジェクトをAntigravityへ書き出し、文脈を保ったままローカル開発と本番化へ進める。
Androidネイティブ対応により、promptからAndroidアプリを構築。
Google Play Consoleと連携し、アプリをテストトラックへ公開。

これにより、AI Studioは「プロンプトを調整してモデルを試す場所」から「アイデアからアプリへ進む入口」になります。Antigravityとの役割分担も明確です。AI Studioは素早い構想と生成に向き、Antigravityは継続開発、編成、デバッグ、提供に向きます。

AndroidとAppFunctions：モバイルAgentの重要インターフェース

AndroidのシステムレベルAgentは単独で見る価値のある方向ですが、正確なインターフェースと製品境界で理解する必要があります。

現時点で最も注目すべきなのは、Android公式の AppFunctions です。公式ドキュメントでは、AppFunctionsはAndroidプラットフォームAPIであり、Jetpackライブラリを伴い、アプリが自分の機能をエージェント、アシスタント、その他の権限を持つ呼び出し元へ公開できるものだと説明されています。Android MCP統合も簡素化します。

その意味は、モバイル自動化がスクリーンショット、OCR、タップのシミュレーション、UI要素の特定だけに頼らなくなることです。

従来のモバイル自動化は次のような流れでした。

画面を認識する。
ボタンを探す。
タップをシミュレートする。
ページ変化を待つ。
エラー時に再試行する。

AppFunctionsの方向は次の通りです。

アプリが自分に何ができるかを宣言する。
Agentが許可のもとでその能力を呼び出す。
システムが権限、呼び出し境界、安全制約を管理する。

これはAndroidアプリ設計に影響します。将来のアプリは、人間が見るUIだけでなく、Agentから呼び出せる能力インターフェースとして中核機能を設計する必要があります。

Search、ショッピング、コンテンツ製品もAgent化へ

Google I/O 2026の変化はモデルや開発者ツールだけではありません。検索とコンシューマー製品も同時に変わっています。

公式I/Oまとめでは、次のような点が挙げられています。

Searchが新しいAI Search段階へ入る。
Searchの中にInformation agentsが登場する。
Gemini SparkとDaily BriefがGemini appへ入る。
Universal Cartがショッピングカートをより賢くする。
Ask YouTubeにより、動画内容を会話形式で検索し移動できる。
Geminiの能力がさらに多くの製品と形態へ広がる。

これらの発表は、GoogleのAgent戦略が単一製品ではなく、検索、動画、ショッピング、オフィス、モバイル、ハードウェアへ横に広がっていることを示しています。

開発者への実際の影響

Google I/O 2026が開発者に与える最大の影響は、「また一つモデルが増えた」ことではなく、開発対象が変わることです。

これまで開発者が主に作っていたものは次のようなものでした。

App。
Webサイト。
API。
プラグイン。
自動化スクリプト。

これからは次のものも作る必要があります。

Agentから呼び出せるアプリ能力。
複数Agentのワークフロー。
状態を持つツール実行環境。
監査可能な自動化フロー。
human-in-the-loopの確認機構。
MCP、AppFunctions、Workspace API、Playwright、Firebaseなどとの統合。

ソフトウェアはますます「画面の集合」ではなく「能力の集合」になります。自分たちの能力を明確、信頼可能、安全にAgentへ公開できる製品ほど、ユーザーの自動化タスクチェーンに入りやすくなります。

モバイル自動化への影響

モバイル自動化は「GUI優先」から徐々に「インターフェース優先、GUIはフォールバック」へ移ります。

短期的には、スクリーンショット認識、OCR、タップのシミュレーション、ブラウザー自動化はまだ価値があります。多くの古いアプリには標準インターフェースがないからです。

長期的には、Android AppFunctions、MCP、システムレベルの権限モデルが成熟すれば、安定したタスク実行は次の方向に寄っていきます。

まずアプリが宣言した能力を呼び出す。
必要ならシステムインターフェースを呼び出す。
さらに必要な場合だけGUI自動化をフォールバックとして使う。

これはRPA、モバイルAgent、テストツール、アプリエコシステムを変えます。能力を公開するアプリほど、システムレベルAgentから呼ばれやすくなります。公開しないアプリは、従来の「画面を見て、画面を押す」方法でしか操作できないかもしれません。

セキュリティ、権限、監査は必須条件になる

Agentの能力が強くなるほど、リスクも大きくなります。

Agentがアプリをまたいでタスクを実行し、支払いを呼び出し、設定を変更し、ファイルにアクセスし、文脈を読むことができるなら、明確な安全境界が必要です。

権限レベル。
ユーザーの明示的な許可。
機密操作の二重確認。
サンドボックス隔離。
操作ログ。
取り消しとロールバック。
企業監査とコンプライアンス。

Googleがホスト型Agentの隔離環境、AppFunctionsの権限要件、企業向けプラットフォーム、制御可能な展開を強調するのはこのためです。Agentの未来は「何でも無制限にできる」ことではなく、安全境界の中で実行可能、追跡可能、管理可能であることです。

まとめ

Google I/O 2026の主要内容は一言でまとめられます。GoogleはGeminiを、モデル、アプリ、システム、開発者ツール、ハードウェアを横断するAgentプラットフォームにしようとしています。

Gemini 3.5 Flash は速度と実行能力を提供し、Gemini Omni はマルチモーダル制作を動画と世界理解へ進め、Gemini app は能動的な個人アシスタントへ向かいます。Antigravity 2.0 と Managed Agents は開発者ツールをAgentネイティブへ押し出し、AppFunctions はAndroidアプリが智能体へ能力を公開する入口になります。

開発者が次に見るべきものは、モデルパラメータだけではありません。アプリ能力をどう構造化するか、Agentツールチェーンへどう接続するか、権限と監査をどう設計するか、そして自分の製品をシステムレベルAgentエコシステムの中で安全かつ信頼できる形で呼び出せるようにするかです。

参考：

PageIndexとは？ベクトルDBを使わない推論型RAG文書インデックスを解説

Wed, 20 May 2026 23:51:37 +0800

VectifyAI/PageIndex は興味深いRAGプロジェクトです。「また別のベクトルDBを作る」ことから始めるのではなく、長文書をまず目次のようなツリー構造に整理し、そのツリーに沿ってLLMに推論型検索を行わせます。

プロジェクトURL：VectifyAI/PageIndex

この記事の整理時点で、GitHubページでは約31.8k stars、2.7k forksが表示されており、ライセンスはMITです。READMEでの位置づけは Vectorless, Reasoning-based RAG、つまりベクトルDBを使わない、推論ベースのRAGです。

何を解決しようとしているのか

従来のRAGでよくある流れは、文書をチャンク化し、ベクトル化し、ベクトルDBに格納し、類似度検索で断片を取得するというものです。この方法はシンプルで汎用的、かつ成熟していますが、長い専門文書ではいくつかの問題が起きやすくなります。

類似度は本当の関連性と同じではない。
チャンク化によって文書構造が分断され、章や節の関係が失われる。
検索結果の説明性が弱く、なぜその箇所がヒットしたのか説明しにくい。
財務報告、規制文書、法律文書、技術マニュアルのような資料では、章をまたいだ推論が必要になることが多い。

PageIndexの考え方は逆です。まず文書を意味的なツリーとして構成し、モデルが人間のように目次を読み、章を開き、階層的に関連内容を探します。

PageIndexの基本ワークフロー

READMEでは、PageIndexの検索は二つのステップに分けられています。

文書に対して Table-of-Contents のようなツリー構造インデックスを生成する。
ツリー検索によって reasoning-based retrieval を行う。

このツリーは単なるファイルディレクトリではなく、LLMが使うための文書構造です。ノードにはタイトル、ページ範囲、要約、子ノードなどの情報が含まれます。これにより、モデルは質問に答えるときに大量のバラバラなchunkへいきなり向き合う必要がありません。まずどの章に入るべきか判断し、その後さらに下へ検索できます。

この方式は、構造が明確で内容が長い文書に向いています。たとえば次のような文書です。

財務報告やSEC filings。
規制資料やコンプライアンス文書。
学術教材や論文。
法律文書。
技術マニュアルや製品ドキュメント。
モデルのコンテキストウィンドウを超える大型PDF。

従来のベクトルRAGとの違い

PageIndexの主な特徴は五つにまとめられます。

第一に、Vector DBを必要としません。ベクトル類似度検索だけに頼るのではなく、文書構造とLLMの推論によって内容を特定します。

第二に、従来型のchunkingを行いません。文書は固定長の断片ではなく、自然な章や節に沿って整理されます。

第三に、説明性が高くなります。検索経路をページ、章、ツリーノードに対応させられるため、「ベクトル類似度でこの段落に当たった」より追跡しやすくなります。

第四に、検索はコンテキスト認識型です。質問、会話履歴、ドメイン背景がツリー検索の経路に影響します。

第五に、人間の専門家が文書を読む方法に近いことです。人は普通、文書全体を小さく切って類似度を計算するのではなく、まず目次を見て、章を特定し、最後に詳細を読みます。

これはベクトルDBに価値がないという意味ではありません。より正確には、PageIndexは「意味的な類似だけでは足りず、構造と推論が必要になる」長文書検索に向いた方式です。

ローカルでの実行方法

READMEにはローカルでのセルフホスト方法が示されています。まず依存関係をインストールします。

`1`	`pip3 install --upgrade -r requirements.txt`

次に、プロジェクトのルートディレクトリに .env を作成し、LLM API keyを書き込みます。プロジェクトは LiteLLM によって複数モデルをサポートします。

`1`	`OPENAI_API_KEY=your_openai_key_here`

PDFからPageIndex構造を生成します。

`1`	`python3 run_pageindex.py --pdf_path /path/to/your/document.pdf`

Markdownも処理できます。

`1`	`python3 run_pageindex.py --md_path /path/to/your/document.md`

主なオプション引数は次の通りです。

--model
--toc-check-pages
--max-pages-per-node
--max-tokens-per-node
--if-add-node-id
--if-add-node-summary
--if-add-doc-description

READMEでは、ローカルのオープンソース版は標準的なPDF解析を使うとも説明されています。複雑なPDFでは、プロジェクト側のクラウドサービスが拡張OCR、ツリー構築、検索パイプラインを提供します。

Agentic Vectorless RAGの例

このプロジェクトには、セルフホストしたPageIndexとOpenAI Agents SDKを使う agentic vectorless RAG の例もあります。オプション依存関係を入れて実行します。

1
2

pip3 install openai-agents
python3 examples/agentic_vectorless_rag_demo.py

この例の価値は、PageIndexを「文書ツリーを生成する」段階から「Agentが文書ツリーを使って検索する」段階へ進めていることです。企業ナレッジベース、財務報告Q&A、規制文書Q&A、技術文書Agentを作っているなら、READMEだけを読むより、この例を一度動かす価値があります。

クラウドサービス、MCP、API

PageIndexは単なるGitHub repoではありません。プロジェクトページにはいくつかの入口も示されています。

セルフホスト：オープンソースコードをローカルで実行し、実験や制御された展開に向く。
Chat Platform：ChatGPT風の文書分析プラットフォーム。
MCP / API：既存のAgentや自動化フローへ組み込みやすい。
Enterprise：プライベートまたはオンプレミス展開向け。

これは単なるdemoではなく、「推論型文書検索」を統合可能な文書インテリジェンス基盤にしようとしていることを示しています。

向いている場面

PageIndexは次のようなタスクに向いています。

長いPDFのQ&A。
財務報告、年次報告、目論見書、規制文書の分析。
法律・コンプライアンス文書検索。
技術マニュアルQ&A。
複数章にまたがる教材や論文の検索。
説明可能な検索経路が必要な企業ナレッジベース。
Agentに構造化された文書コンテキストを提供すること。

資料が短い、構造がほとんどない、または普通のFAQに近い場合は、従来のembedding + vector DBで十分かもしれません。PageIndexの利点は、長文書、強い構造、専門領域、推論が必要な質問でより出やすくなります。

注意点

第一に、PageIndexは依然としてLLMに依存します。ツリー構築、要約、検索品質は、モデル能力、プロンプト、文書解析品質の影響を受けます。

第二に、ローカル版は標準的なPDF解析を使います。複雑なスキャン文書、図表が多いPDF、レイアウトが乱れた資料では、OCRやより強い前処理が必要になる場合があります。

第三に、ベクトルDBなしはゼロコストを意味しません。ツリー構築自体もモデル呼び出しと時間を消費します。大規模文書コレクションでは特にそうです。

第四に、PageIndexは文書構造インデックスと推論検索のフレームワークに近く、すべてのRAG技術スタックを直接置き換えるものではありません。実際の本番環境では、ベクトル検索、キーワード検索、権限制御、キャッシュ、監査システムと組み合わせて使うこともあります。

まとめ

PageIndexの面白さは、RAGの重点を「テキスト類似度による取得」から「文書構造 + LLM推論」へ移していることです。長文書や専門文書では、この方向は注目に値します。

企業文書Q&A、財務報告分析、規制文書検索、技術マニュアルAgentを作っているなら、PageIndexは新しいRAGアーキテクチャの参考になります。最初からすべてを細かく切ってベクトルDBに入れるのではなく、まず文書に構造を与え、その構造に沿ってモデルに推論させるという考え方です。

参考：

GitHub：VectifyAI/PageIndex

Gemini 3.5 発表：Flash が先行し、Google は Agent と長時間タスク実行に重点

Wed, 20 May 2026 22:51:31 +0800

Google は 2026 年 5 月 20 日、Gemini 3.5 シリーズを正式に発表した。最初に利用可能になるのは Gemini 3.5 Flash で、単なるチャットモデルではなく、Agent、コード生成、長時間にわたる複雑なタスク実行を意識したモデルとして位置付けられている。

今回の発表から見える Google のメッセージは明確だ。Gemini 3.5 は質問に答えるだけでなく、計画し、実行し、結果を確認し、複数ステップのワークフローを継続的に進めることを目指している。

Gemini 3.5 Flash が先行

Gemini 3.5 Flash は、すでに複数のユーザー層に向けて提供されている。

一般ユーザーは Gemini アプリと Google 検索の AI Mode で利用できる。
開発者は Google Antigravity、Google AI Studio、Android Studio の Gemini API から利用できる。
企業ユーザーは Gemini Enterprise Agent Platform と Gemini Enterprise から利用できる。

Google は同時に、Gemini 3.5 Pro はまだ開発中で、すでに Google 内部で使われており、来月の提供を予定しているとも説明している。

つまり 3.5 シリーズでも Flash と Pro の役割分担は続く。Flash は速度、コスト、大規模実行を重視し、Pro はより複雑で高い能力を必要とする用途を担う可能性が高い。

焦点は Agent とコードタスク

Google は Gemini 3.5 Flash を、Agent とコーディング向けの最も強力なモデルの一つとして説明している。発表では、Terminal-Bench 2.1、GDPval-AA、MCP Atlas、CharXiv Reasoning などのコード・Agent 系ベンチマークで、Gemini 3.1 Pro の一部成績を上回ったとされている。

ただし、一般ユーザーにとって重要なのは個々のスコアではない。より大事なのは、Google がモデル能力を「実行可能なワークフロー」に寄せていることだ。コードを書くことに加えて、古いプロジェクトの移行、複雑なアプリ開発、財務レポートの整理、データ分析、継続的なテストまで扱おうとしている。

Antigravity の開発フレームワークでは、Gemini 3.5 Flash が複数の協調する subagents を使い、大きなタスクを処理できる。Google は AlphaZero の論文を解析して遊べるゲームを作る例、レガシーコードを Next.js に変換する例、都市景観や UI 案を並列生成する例を示している。

方向性ははっきりしている。AI コーディングツールは「コード片を生成する」段階から、「複数の Agent を組織してプロジェクトを進める」段階へ移りつつある。

マルチモーダル UI とグラフィック能力の強化

Gemini 3.5 Flash は Gemini 3 のマルチモーダル基盤を引き継いでいる。Google は、より豊かな Web UI、インタラクティブなアニメーション、視覚コンテンツを生成できると説明している。

発表で示された用途には次のようなものがある。

研究論文向けのインタラクティブなアニメーションを作る。
テキスト説明からインタラクティブなハードウェアモデルを生成する。
学校の募金活動向けにブランドコンセプト一式を作る。
短時間でチェックアウトフローの複数の UX 案を生成する。

これは開発者やプロダクトチームにとって意味が大きい。モデルは説明文を出すだけでなく、フロントエンドのプロトタイプ、インタラクション設計、可視化にも関わるようになる。

企業用途：時間のかかるワークフローを自動化する

Google は複数のパートナー事例も挙げている。Shopify は subagents で複雑なデータを分析し、販売者の成長予測に活用している。Macquarie Bank は 100 ページを超える複雑な文書を 3.5 Flash に読ませ、口座開設フローを高速化するテストをしている。Salesforce は Agentforce に統合し、Ramp は複雑な請求書 OCR の改善に使い、Xero は行政的なワークフローを AI Agent で処理し、Databricks はデータ異常の監視と修正提案に自動化ワークフローを使っている。

これらの事例は同じ方向を示している。企業での大規模モデル利用は、単発の Q&A からワークフロー自動化へ移っている。モデルが安価で速く、長時間のタスクで安定して動くかどうかは、単発の回答が見栄えよく見えるかどうかより重要になりつつある。

Gemini Spark：個人向け AI Agent

Google は Gemini Spark も発表した。Gemini 3.5 Flash によって動く個人向け AI Agent で、ユーザーの指示のもとで長時間動作し、能動的にタスクを実行することを目指している。

Gemini Spark は信頼されたテスター向けに展開が始まっており、Google は来週、米国の Google AI Ultra 加入者向けに Beta を開放する予定だ。

ここは注目に値する。Google 検索、Gemini アプリ、Android、Workspace、ブラウザ関連のエコシステムは、すでに個人のデジタル生活の多くに接点を持っている。個人向け Agent がこれらの入口と結び付くなら、単独のチャットボットより大きな影響を持つ可能性がある。

安全対策も前段に移る

Google は Gemini 3.5 を Frontier Safety Framework に基づいて開発し、情報セキュリティや CBRN 関連リスクへの防護を強化したとしている。さらに、モデルが回答する前に推論過程の確認と理解を助ける interpretability tools にも触れている。

これは、最前線のモデル発表が能力競争だけではなくなっていることを示している。Agent、自動実行、長時間タスクを強調するほど、安全制御、誤拒否率、有害出力の抑制、解釈可能性は重要になる。

Gemini 3.5 をどう見るか

Gemini 3.5 Flash の意味は、単なる新モデル発表ではない。Google が次の AI プロダクトの形に賭けているように見える。つまり、ツールを呼び出し、タスクを分割し、協調して実行し、UI を生成し、個人と企業のワークフローに入っていくモデルだ。

開発者にとっては、Google Antigravity、AI Studio、Gemini API、Android Studio での実際の体験が重要になる。企業にとっては、benchmark だけでなく、実際の業務フローで手作業を安定して減らせるかが焦点になる。

Gemini 3.5 Pro はまだ正式公開されていない。Pro が出たあと、Flash と Pro の能力、価格、速度、コンテキスト処理の違いが、それぞれに適した本番用途を決めることになる。

参考:

Google Blog: Gemini 3.5

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-Traderとは？AI Agentが売買シグナルを出し、ペーパートレードできるプラットフォーム

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

HKUDS/AI-Trader は、AI Agent 向けの取引プラットフォームプロジェクトです。READMEでは “Agent-Native Trading Platform” と位置づけられており、AI Agent がプラットフォームに接続し、売買シグナルを公開し、議論に参加し、コピー取引を行い、市場データを利用できるようにすることを目指しています。

プロジェクトURL：https://github.com/HKUDS/AI-Trader

プラットフォームURL：https://ai4trade.ai

執筆時点では、GitHub API上で約1.8万 star、主要言語は Python でした。リポジトリAPIでは明確なライセンス値が返っていなかったため、正式利用前にライセンス条件を確認する必要があります。

この記事はオープンソースプロジェクトの紹介であり、投資助言ではありません。自動取引には実資金リスクがあります。どの戦略、シグナル、Agent出力も収益を保証しません。

位置づけ

AI-Trader の中心的な考え方は、人間に取引プラットフォームがあるなら、AI Agent にも専用の取引プラットフォームが必要になるかもしれない、というものです。

READMEによると、任意の AI Agent はプラットフォームの Skill ファイルを読み、すばやく登録できます。

`1`	`Read https://ai4trade.ai/skill/ai4trade and register on the platform. Compatibility alias: https://ai4trade.ai/SKILL.md`

接続後、Agent は売買シグナルの公開、コミュニティでの議論、優秀なトレーダー戦略のコピー、複数brokerへのシグナル同期、予測成績によるポイント獲得などができます。

主な機能

READMEには次の機能が挙げられています。

Instant Agent Integration：AI Agent の素早い接続。
Collective Intelligence Trading：複数Agentによる取引アイデアの協議。
Cross-Platform Signal Sync：複数プラットフォームへのシグナル同期。
One-Click Copy Trading：選んだトレーダーやAgentをフォロー。
Universal Market Access：株式、暗号資産、FX、オプション、先物など。
Three Signal Types：戦略、操作、議論の3種類のシグナル。
Reward System：シグナル公開や注目度でポイントを獲得。

プロダクトとして見ると、単なるローカル量的バックテストフレームワークではありません。Agent、シグナル、議論、コピー取引、ペーパートレードを同じプラットフォーム層にまとめています。

2種類のユーザー

READMEではユーザーを2種類に分けています。

1つ目は Agent Traders です。AI Agent が Skill ドキュメントを読み、プラットフォームに接続し、必要なコンポーネントを導入し、シグナルを公開します。

2つ目は Human Traders です。一般ユーザーはプラットフォームにアクセスし、アカウントを作り、シグナルを閲覧したり、成績の良いトレーダーをフォローしたりできます。

この2つを合わせると、「AI Agent がシグナルを生み、人間または他のAgentがそれを利用する」構造になります。

アーキテクチャ

READMEには次のプロジェクト構造が示されています。

AI-Trader (GitHub - Open Source)
念岸岸 skills/              # Agent skill definitions
念岸岸 docs/api/            # OpenAPI specifications
念岸岸 service/             # Backend & frontend
岫   念岸岸 server/         # FastAPI backend
岫   弩岸岸 frontend/        # React frontend
弩岸岸 assets/              # Logo and images

Agent skill、APIドキュメント、バックエンド、フロントエンドが同じリポジトリに置かれています。バックエンドは FastAPI、フロントエンドは React です。READMEの更新履歴では、Webサービスとバックエンドworkerを分離し、価格、収益履歴、精算、市場インテリジェンスなどのタスクがページやヘルスチェックに影響しないようにしたことも触れられています。

なぜ注目する価値があるのか

AI-Trader が注目に値するのは、「AIが自動で稼ぐ」からではありません。Agent を金融シナリオに接続するインターフェースを比較的明確にしているからです。

注目点はいくつかあります。

第一に、Skill ドキュメントを Agent の接続入口として使っています。これは Codex、Claude Code、OpenClaw などのAgentツールの働き方に近いものです。

第二に、売買シグナル、議論、コピー取引、報酬システムをローカルスクリプトではなくプラットフォーム層に置いています。

第三に、OpenAPI ドキュメントを提供しており、開発者がインターフェースを理解しやすくなっています。

第四に、paper trading に対応しています。Agentの意思決定研究では、実資金を直接扱うよりシミュレーション環境のほうが安全です。

リスクと境界

自動取引は高リスクな領域です。

第一に、Agentが生成する売買シグナルは投資助言ではありません。モデルは幻覚、過学習、ニュースの誤読、極端な相場への無理解を起こす可能性があります。

第二に、コピー取引には伝播リスクがあります。誤ったシグナルを多くのユーザーが追随すると、損失が集中する可能性があります。

第三に、実資金アクセスは厳格に分離すべきです。Agentに無制限の注文権限を与えるべきではありません。

第四に、broker、金融データ、ユーザー口座が関わる場合、商用・本番利用前にライセンスとコンプライアンスを確認する必要があります。

向いている人

AI-Trader は、Agentの意思決定を研究する人、金融Agentのインターフェースを試す開発者、ペーパートレードやシグナル協業に関心のあるチームに向いています。確実に利益を得るツールを探しているユーザーには向きません。

まとめ

AI-Trader は、AI Agent を中心に設計されたシグナル公開とペーパートレードのプラットフォームです。「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 連携が見どころです。

主流AI PPTツール総まとめ：自動生成、Webスライド、PPTX、画像ルートをどう選ぶか

Mon, 18 May 2026 22:29:43 +0800

AIでPPTを作ることは、もはや「タイトルを入力してテンプレートを当てる」だけではありません。Claude Code、Codex、CursorのようなAIコーディング環境では、PPT生成はインストール可能で再利用できるAgent Skillの集まりになりつつあります。Webプレゼンを出力するもの、実際に編集可能な .pptx を生成するもの、画像モデルで各ページをビジュアル案として作るもの、MCPを通じてAIにPowerPointファイルを操作させるものがあります。

今回は、主流のPPT関連Skillを整理します。価値があるのは単なる一覧ではなく、これらのツールを納品形態ごとに分けて考えることです。ツールを選ぶ前に、まずこう問いましょう。最終成果物は誰が編集するのか、どこで発表するのか、継続的な共同作業が必要なのか。

いくつかのルート

1. HTML Webプレゼン

代表的なプロジェクトには、frontend-slides、guizang-ppt-skill、html-ppt-skill があります。

このルートの強みは視覚表現力です。CSSアニメーション、Canvas、WebGL、レスポンシブレイアウトを使え、ブラウザで開くだけで発表できます。技術共有、製品発表、Demo Day、個人のスタイルが強い登壇に向いています。

一方で代償も明確です。納品後にクライアントが一文字ずつ修正する用途にはあまり向きません。クライアントが受け取るものがPowerPointファイルではなくHTMLの場合、後続の修正は生成フローに戻ることが多くなります。

HTMLプレゼンだけを見るなら、frontend-slides は高スターの汎用入口に近く、guizang-ppt-skill は美的制約とテーマ性に強く、html-ppt-skill はテーマ数、レイアウト数、発表者モードで優れています。

2. ネイティブPPTX

代表的なプロジェクトには、mckinsey-pptx、ppt-agent-skills、claude-office-skills、ppt-master があります。

これはビジネス納品で最も安定したルートです。クライアントが「PowerPointで文字を直したい、画像を差し替えたい、会社テンプレートを使いたい」と求めるなら、最終的には .pptx に落とす必要があります。

その中でも ppt-master は個別に注目する価値があります。考え方は、まずLLMにSVGを生成させ、それをPowerPointネイティブのDrawingMLオブジェクトへ変換するというものです。目的は、テキストボックス、図形、チャートをPPTX内で引き続き編集できるようにすることです。PDF、DOCX、URL、MarkdownからのPPTX生成にも対応し、テンプレート複製、アニメーション、ナレーション、ローカルプレビューも扱えます。

このルートは、コンサルティング納品、社内報告、ホワイトペーパー発表、長いレポートのPPT化に向いています。欠点は、視覚表現の上限がPowerPoint自体に制約されやすく、複雑な表現ではHTMLや画像ルートほど自由ではないことです。

3. AI画像駆動

代表的なプロジェクトには、NanoBanana-PPT-Skills、gpt_image_2_skill、ppt-image-first があります。

このルートは各スライドをまず1枚のビジュアルとして生成し、その画像をPPTXや別のコンテナに入れます。完成度が高く、特に表紙、SNS画像、ビジュアル提案、拡散向けコンテンツに向いています。

問題は編集性の低さです。ページは本質的に1枚の画像です。あとからタイトルを直す、文案を差し替える、アイコンを動かすとなると、再生成が必要になる場合があります。「見た目をよくしたい」用途には合いますが、「クライアントが何度も修正する」用途には向きません。

4. MCP / プロトコル層

代表的なプロジェクトには、Office-PowerPoint-MCP-Server、PPTAgent があります。

この種のツールは、必ずしも完全なPPTを直接生成するわけではありません。AIにPowerPointを操作するインターフェースを与えます。MCPに接続すると、モデルは .pptx ファイルを読み、修正し、書き込めます。

このルートは、すでにPPTファイルがあり、AIに修正を手伝わせたいワークフローに向いています。たとえば、書式の一括変更、フィードバックに基づくページの並べ替え、各ページが目的に合っているかのチェックなどです。PPTAgent は反省型生成を重視しています。つまり、各ページを生成したあとに見直します。この方向性は「AI PPTが粗い」問題を減らすヒントになります。

5. 統合デザインプラットフォーム

代表的なプロジェクトには、open-design、docsagent があります。

この種のプロジェクトは、PPT生成そのものを超えています。open-design はローカル優先のデザインプラットフォームに近く、プロトタイプ、slides、images、videosを生成でき、複数のエクスポート形式に対応します。docsagent はPPTツールではありませんが、ローカル文書をインデックス化して対話できるため、PPT生成前の資料整理層として使えます。

単発でPPTを作るだけでなく、資料、デザイン、プロトタイプ、納品までの一連の流れが必要なら、このタイプのプラットフォームはより見る価値があります。

Skillメタ情報

Star数は2026-05-15時点の取得結果に基づくもので、人気度の参考にすぎません。実際に使う前には、リポジトリを開いてメンテナンス状況、README、LICENSEを確認することをおすすめします。

Skill	作者	リンク	Star	言語	ルート
frontend-slides	@zarazhangrui	GitHub: zarazhangrui/frontend-slides	17,530	Shell	HTML Webプレゼン
guizang-ppt-skill	@op7418（歸藏）	サイト内記事: guizang-ppt-skill GitHub: op7418/guizang-ppt-skill	8,832	HTML	HTML Webプレゼン
html-ppt-skill	@lewislulu	GitHub: lewislulu/html-ppt-skill	3,834	HTML/CSS/JS	HTML Webプレゼン
mckinsey-pptx	@seulee26	GitHub: seulee26/mckinsey-pptx	426	Python	ネイティブPPTX
ppt-agent-skills	@sunbigfly	GitHub: sunbigfly/ppt-agent-skills	714	Python	ネイティブPPTX
claude-office-skills	@tfriedel	GitHub: tfriedel/claude-office-skills	631	Python	ネイティブPPTX
ppt-master	@hugohe3	GitHub: hugohe3/ppt-master	16,626	Python	ネイティブPPTX
NanoBanana-PPT-Skills	@op7418（歸藏）	GitHub: op7418/NanoBanana-PPT-Skills	2,668	Python	AI画像駆動
gpt_image_2_skill	@wuyoscar	GitHub: wuyoscar/gpt_image_2_skill	2,102	Python	AI画像駆動
ppt-image-first	@NyxTides	GitHub: NyxTides/ppt-image-first	799	Python	AI画像駆動
Office-PowerPoint-MCP-Server	@GongRzhe	GitHub: GongRzhe/Office-PowerPoint-MCP-Server	1,708	Python	MCP / プロトコル層
PPTAgent	@icip-cas	GitHub: icip-cas/PPTAgent	4,354	Python	MCP / プロトコル層
open-design	@nexu-io	サイト内記事: open-design GitHub: nexu-io/open-design	40,822	TypeScript	統合デザインプラットフォーム
docsagent	@docsagent	GitHub: docsagent/docsagent	687	TypeScript	統合デザインプラットフォーム

選び方

クライアントが継続して編集するなら、ネイティブPPTXルートを優先します。特に ppt-master、mckinsey-pptx、ppt-agent-skills です。

自分で発表し、後続編集より視覚表現を重視するなら、HTMLルートを優先します。特に frontend-slides、guizang-ppt-skill、html-ppt-skill です。

ポスター感、表紙感、拡散用ビジュアルが目的なら、画像ルートを優先します。たとえば ppt-image-first、gpt_image_2_skill、NanoBanana-PPT-Skills です。

すでにPPTファイルがあり、AIに読み取り、修正、再配置を手伝わせたいだけなら、MCPルートを見るとよいでしょう。

学術、マーケティング、翻訳、長いレポートの圧縮といった明確な場面では、汎用PPT生成器に無理をさせるのではなく、垂直Skillを探すのもよい選択です。

最後に注意したいこと

オープンソースプロジェクトはStarだけで判断できません。実際に使う前に、次の3点を確認してください。

LICENSEが自分の利用方法を許可しているか。
生成物が納品要件を満たすか。特に編集性。
モデル呼び出し、画像生成、大きなコンテキストモデル、クラウドサービス費用を含めて、コストが許容できるか。

この種のツールは変化が速く、Star数もメンテナンス状況も変わります。それでも選定ロジックは比較的安定しています。まず納品形態を決め、それから具体的なツールを見ることです。PPTが「話すため」なのか、「編集してもらうため」なのか、「見てもらうため」なのか。この3つの答えだけで、選択肢はかなり絞れます。

wx-cli 解説：コマンドラインでローカルの WeChat チャット履歴を検索する

Mon, 18 May 2026 21:02:21 +0800

wx-cli は Rust で書かれたローカル WeChat データ向けのコマンドラインツールです。自分の WeChat セッション、チャット履歴、連絡先、グループメンバー、お気に入り、Moments、公式アカウント記事、添付ファイル、統計情報をターミナルから検索できるようにすることを目的としています。

これはクラウド型の WeChat 同期サービスでも、チャットボットでもありません。むしろローカルの読み取り専用データ検索レイヤーに近いものです。WeChat は引き続き手元のマシンで動作し、データも手元に残ります。wx-cli は必要に応じてローカルデータベースを復号、キャッシュ、検索し、その結果を YAML または JSON として人間や Agent に返します。

このプロジェクトで注目したい点は二つあります。一つは、WeChat のローカルデータ検索をクロスプラットフォーム CLI としてまとめていること。もう一つは、Claude Code、Cursor、Codex のような AI Agent の利用シーンを明確に意識し、SKILL.md と meta 付きの構造化出力を提供していることです。

wx-cli でできること

プロジェクト README によると、wx-cli はかなり広い機能をカバーしています。

最近のセッションと未読セッションを表示する。
特定の連絡先またはグループのチャット履歴を検索する。
ローカルデータベース全体からキーワード検索する。
新着メッセージを表示する。
連絡先、グループメンバー、グループ内ニックネームを検索する。
お気に入りを検索する。
Moments の通知、タイムライン、本文を検索する。
公式アカウントの記事配信を検索する。
チャット内の画像添付を一覧表示し、抽出する。
チャット統計を作成する。
チャット履歴を Markdown または JSON としてエクスポートする。

これらの機能により、単なる「チャット履歴検索」ではなく、WeChat のローカルデータを検索、集計、エクスポートできるローカル資料庫として扱えるようになります。

AI Agent に向いている理由

多くの CLI ツールは人間向けで、出力も単なるテキストになりがちです。wx-cli は Agent が読むことを明確に想定しています。

README では、history、search、sessions、unread、new-messages、stats、attachments などのコマンドが meta 情報を付けて返すと説明されています。meta には結果の状態、不明なシャード、ヒットしたデータの最新時刻、session 記録の最新時刻などが含まれます。

これは Agent にとって有用です。AI は「何が見つかったか」だけでなく、「結果は新しいのか」「メッセージが抜けている可能性はないか」「再度 init すべきか」も判断する必要があるためです。たとえば：

status は結果が ok なのか possibly_stale なのかを示せます。
unknown_shards は daemon が現在 key を持っていないデータベースシャードの存在を示せます。
chat_latest_timestamp はヒットしたデータ内の最新メッセージ時刻を Agent に伝えます。
session_last_timestamp はローカルの session 記録が検索結果より明らかに新しいかどうかを判断する助けになります。

この種のメタ情報は AI の誤判断を減らし、Claude Code、Cursor、Codex のようなツールが WeChat データを扱うときの安定性を高めます。

インストール方法

プロジェクトは npm によるクロスプラットフォームインストールを推奨しています。

`1`	`npm install -g @jackwener/wx-cli`

macOS / Linux では curl によるインストールにも対応しています。

`1`	`curl -fsSL https://raw.githubusercontent.com/jackwener/wx-cli/main/install.sh \| bash`

Windows では管理者 PowerShell で実行します。

`1`	`irm https://raw.githubusercontent.com/jackwener/wx-cli/main/install.ps1 \| iex`

ソースからビルドする場合は、Rust を直接使えます。

1
2

git clone git@github.com:jackwener/wx-cli.git && cd wx-cli
cargo build --release

ビルド成果物は target/release/wx、Windows では wx.exe です。

Agent Skill との関係

wx-cli は AI Agent 向けの Skill も提供しています。skills CLI を使えば、Claude Code、Cursor、Codex など Skills 対応環境へ一度に導入できます。

`1`	`npx skills add jackwener/wx-cli`

グローバルにインストールする場合：

`1`	`npx skills add jackwener/wx-cli -g`

インストール後、Agent はリポジトリ内の SKILL.md を読み、wx-cli のインストール、初期化、呼び出し方法を理解します。

つまり、Agent に次のようなローカル情報整理を依頼できます。

特定期間に特定のグループチャットで話題になったキーワードを探す。
最近の未読メッセージを要約する。
特定セッションから最近のチャット履歴をエクスポートする。
公式アカウント記事のリンクを検索する。
グループチャット内の発言統計を分析する。

前提は変わりません。対象データは、あなた自身のマシン上にある、あなた自身の WeChat データである必要があります。

基本的な使い方

初期化前には WeChat を起動しておく必要があります。要件はプラットフォームごとに異なります。

Linux では次を実行できます。

`1`	`sudo wx init`

Windows では管理者 PowerShell を使います。

wx init

macOS は少し複雑です。README によると、デフォルトの方法では WeChat に ad-hoc 署名を行い、プロセスメモリをスキャンできるようにする必要があります。再署名後は古い TCC 権限レコードも削除する必要があります。そうしないと、スクリーンショット、ビデオ通話、マイクなどの権限が「有効に見えるのに実際には拒否される」状態になることがあります。プロジェクトドキュメントでは、再署名によって macOS が他の App のデータアクセス許可を頻繁に求める副作用も注意しています。

初期化後は、次のコマンドで確認できます。

`1`	`wx sessions`

最近のセッションが見えれば、基本的な経路は利用可能です。daemon は初回呼び出し時に自動起動します。

よく使うコマンド例

最近のセッションを表示：

`1`	`wx sessions`

未読セッションを表示：

`1`	`wx unread`

公式アカウントや折りたたみ入口を除外し、個人とグループの未読だけを見る：

`1`	`wx unread --filter private,group`

特定セッションの最近のチャット履歴を見る：

`1`	`wx history "张三"`

さらに多くの履歴を取得：

`1`	`wx history "张三" -n 2000`

期間を指定してグループチャットを検索：

`1`	`wx history "AI群" --since 2026-04-01 --until 2026-04-15`

全体検索：

`1`	`wx search "关键词"`

特定グループ内でキーワード検索：

`1`	`wx search "会议" --in "工作群" --since 2026-01-01`

チャット履歴をエクスポート：

1
2

wx export "张三" --format markdown -o chat.md
wx export "AI群" --since 2026-01-01 --format json

これらのコマンドはスクリプトや Agent から呼び出す用途に向いており、特に --json と組み合わせると扱いやすくなります。

Moments と公式アカウント記事

wx-cli はチャットだけを検索するわけではありません。

Moments 関連のコマンドは通知と投稿に分かれています。

1
2
3

wx sns-notifications
wx sns-feed
wx sns-search "关键词"

注意点として、Moments データはローカルで表示されたことのある内容に限られます。WeChat クライアントは必要に応じてデータをダウンロードするため、ローカルに存在したことのないデータをツールが突然取得することはできません。

公式アカウント記事は独立したコマンドで検索します。

wx biz-articles
wx biz-articles --account "返朴"
wx biz-articles --since 2026-05-01 --until 2026-05-10
wx biz-articles --json | jq '.[].url'

アカウント名、タイトル、URL、概要、カバー画像、時刻などのフィールドが返ります。資料整理、記事収集、ローカル知識ベースづくりをしている人には実用的な機能です。

添付ファイルの抽出

WeChat チャット内の画像添付は、通常そのまま読める一般的な画像ファイルではなく、xwechat_files/<wxid>/msg/attach/... 配下の .dat ファイルとして保存されています。

wx-cli は二段階のフローを提供しています。

1
2

wx attachments "张三"
wx attachments "AI群" --kind image -n 100

まず attachment_id を取得し、その後で抽出します。

`1`	`wx extract <attachment_id> -o ~/Desktop/photo.jpg`

出力レポートには md5、dat_path、dat_size、output、format、decoder などの情報が含まれます。README では legacy XOR、V1 fixed-AES、V2 AES + XOR などのデコード方式に対応していると説明されており、image key の抽出方法はプラットフォームによって異なります。

この機能は強力ですが、より慎重に使う必要があります。自分のデータだけを処理し、無許可のデータアクセスには使わないでください。

daemon アーキテクチャが重要な理由

wx-cli の性能面のポイントは daemon にあります。

README が示す構成はおおむね次のようなものです。

wx (CLI) ──Unix socket──▶ wx-daemon (バックグラウンドプロセス)
                              │
                    ┌─────────┴──────────┐
               DBCache               連絡先キャッシュ
           (mtime を見て再利用)

daemon は初回復号後、データベースと mtime 情報を ~/.wx-cli/cache/ に永続化します。データベースファイルの mtime が変わっていなければ、以後の呼び出しではキャッシュを再利用でき、毎回復号する必要がありません。

これはコマンドライン検索と Agent のループ処理の両方で重要です。Agent は複数のセッションを連続で検索し、複数のキーワードを調べ、その後に統計やエクスポートを行うことがあります。毎回スキャンと復号をやり直すと体験は悪くなります。daemon キャッシュにより、ローカル検索サービスに近い感覚で使えます。

原理の簡単な説明

プロジェクト README は原理を直接説明しています。WeChat 4.x は SQLCipher 4 でローカルデータベースを暗号化し、WCDB は派生後の raw key をプロセスメモリ内にキャッシュします。

wx-cli はプラットフォームに応じた方法で WeChat プロセスメモリをスキャンし、key パターンに一致するものを見つけて鍵を抽出します。その後 daemon が必要に応じてデータベースを復号し、キャッシュします。

低レベルの仕組みはプラットフォームごとに異なります。

macOS は Mach VM API を使います。
Linux は /proc/<pid>/mem を使います。
Windows は VirtualQueryEx と ReadProcessMemory を使います。

これらの仕組みは、初期化に高い権限が必要になりがちな理由、そして macOS で署名やプライバシー権限が関係する理由を説明しています。

利用上の境界とリスク

この種のツールでは、まず境界を明確にする必要があります。

wx-cli README の免責事項は明確です。このツールは学習と研究目的に限られ、自分の WeChat データを復号するためのものであり、関連する法令を遵守する必要があります。無許可のデータアクセスに使ってはいけません。

実際に使うときは、次の点にも注意するのがよいでしょう。

自分のコンピューター、自分の WeChat アカウントでのみ使う。
エクスポートしたチャット履歴を安易にクラウドモデルへアップロードしない。
Agent でチャット履歴を分析する場合、API 事業者とデータ越境リスクを先に確認する。
Markdown / JSON としてエクスポートした後は、ファイル権限とバックアップ先に注意する。
会社端末や共有端末で使う前に、コンプライアンスと権限を確認する。

ローカルツールだからといってプライバシーリスクがないわけではありません。データが最初から外へ出る経路は減りますが、出力をクラウドモデル、クラウドストレージ、第三者スクリプトに渡せば、リスクは戻ってきます。

向いているユーザー

wx-cli は次のような場面に向いています。

自分の WeChat 過去メッセージをローカルで素早く検索したい。
特定セッションを Markdown または JSON としてエクスポートしたい。
一定期間のグループチャット発言状況を集計したい。
Claude Code、Cursor、Codex などの Agent にローカル WeChat 資料を整理させたい。
公式アカウント記事の配信リンクをローカル知識ベースに整理したい。
WeChat のローカルデータベース構造や復号フローを研究したい。

一方で、次のような用途にはあまり向いていません。

クラウド型の WeChat 同期をしたい。
他人の端末やアカウント権限を回避したい。
GUI だけで操作したく、コマンドラインに触れたくない。
macOS の権限、Windows の管理者権限、Linux の sudo を扱いたくない。

まとめ

wx-cli の価値は、単に「コマンドラインで WeChat チャット履歴を検索できる」ことだけではありません。より正確には、WeChat のローカルデータを、検索でき、エクスポートでき、Agent が消費できるローカルデータソースへ変える点にあります。

daemon アーキテクチャは繰り返し復号と検索性能の問題を解決します。meta wrapper は AI Agent が結果の鮮度を判断しやすくします。SKILL.md は Claude Code、Cursor、Codex のようなツールにインストールと利用方法を理解させます。

WeChat から情報を探す、グループチャットを整理する、記録をエクスポートする、個人資料庫を構築するといった作業が多いなら、wx-cli は注目に値します。ただし使うときは、常に一つの前提を忘れないことが重要です。処理するのは自分のデータだけにし、エクスポートした結果は慎重に管理してください。

参考資料

jackwener/wx-cli GitHub リポジトリ

Anthropic Founder’s Playbook解説：Claudeはスタートアップチームをどう加速するのか

Mon, 18 May 2026 18:02:58 +0800

AnthropicはClaude公式ブログで、創業者向けのThe Founder’s Playbookを公開した。中心にある問いは明確だ。AI-native startupは、洞察からプロダクト、ローンチ、スケールへどうすればより速く進めるのか。

このplaybookは、Claudeの機能一覧を紹介するだけのものではない。創業プロセスをIdea、MVP、Launch、Scaleの4段階に分けている。強調されているのは、AIに創業者の判断を置き換えさせることではなく、市場調査、コピーの初稿、コードの足場作り、運用フロー、営業資料といった反復的な作業をまずClaudeに任せ、創業者が判断、センス、取捨選択、信頼構築により多くの時間を使えるようにすることだ。

このplaybookは何を語っているのか

AIスタートアップが直面する圧力は、ますます圧縮競争のようになっている。プロダクトサイクルは短くなり、競争相手は増え、ユーザーは速度と品質を同時に求める。かつては複数人のチームで分担していた仕事も、いまではAIが第一稿を作り、創業チームがレビュー、修正、推進する形にできる。

Anthropicの枠組みは明快だ。最初から会社全体を完全に「AI化」しようとしない。まずは時間がかかり、反復的で、創造密度の低いプロセスを1つ見つける。Claudeに初稿、スクリプト、調査結果、実行チェックリストを生成させる。創業者は目標を定義し、方向を調整し、品質を判断し、有効な結果を実際の業務につなげる。

第1段階：Idea

Idea段階の重点は、「かっこいいアイデア」を思いつくことではない。そのアイデアにさらに投資する価値があるかを検証することだ。

Claudeはこの段階で、市場マップの整理、ユーザーの痛みの要約、競合ポジショニングの比較、潜在的な切り口の提案、曖昧なアイデアの具体的な価値提案への圧縮を支援できる。

ただし、最も重要なのは依然として人間の判断だ。AIはより多くの可能性を素早く見せてくれるが、「この市場に本当に強い需要があるか」という責任を代わりに負うことはできない。創業者は実際のユーザーと話し、既存のワークフローを変える意思があるか、さらには支払う意思があるかを観察する必要がある。

第2段階：MVP

MVP段階は、Claude Codeが特に力を発揮しやすいところだ。

小さなチームにとって、最も不足しがちなのはアイデアではなく、アイデアを試せるプロダクトに変える速度である。Claude Codeは足場作り、スクリプト作成、コンポーネント補完、境界条件の確認、技術方針メモの作成に関わり、チームが検証可能なバージョンへより速く到達するのを助ける。

ここで重要なのは、AIに一度で完璧なプロダクトを書かせることではない。ゼロから最初のバージョンまでの摩擦を下げることだ。創業者とエンジニアは、アーキテクチャ、セキュリティ、データ処理、ユーザー体験を引き続きレビューする必要がある。しかし、大量の機械的な初稿作業に時間を費やす必要は少なくなる。

第3段階：Launch

Launch段階で問われるのは、ナラティブ、配信、フィードバック速度だ。

多くのスタートアップチームは、ローンチの複雑さを過小評価する。ウェブサイトのコピー、プロダクトデモ、メール、ソーシャル投稿、ユーザーインタビュー、営業トーク、投資家向けアップデート。どれも「なぜ今このプロダクトが必要なのか」を明確に伝えなければならない。

Claudeはここで高頻度の協力相手になれる。異なるポジショニング案を生成し、ユーザー層ごとに紹介文を書き換え、ユーザーの疑問をシミュレーションし、ローンチの流れを整理し、初期フィードバックを次のプロダクトと市場施策に変換する。

第4段階：Scale

Scale段階では、テーマが「作ること」から「再現可能に成長すること」へ移る。

会社に安定したユーザーと収益が生まれ始めると、創業チームは運用、営業、サポート、データ分析、社内連携に引っ張られる。Claude Coworkのようなエージェント的能力は、より完結したタスクに向いている。たとえば市場調査、キャンペーン設計、資金調達戦略の整理、成長指標の要約、運用プロセスを繰り返し実行できる手順に分解することなどだ。

ここでAI-native企業と従来型ソフトウェア企業の違いが見え始める。本当の変化は、従業員がAIツールを使うことだけではない。会社のプロセスが最初からAIとの協働を前提に設計されることだ。どのタスクは人間が基準を定義するのか、どのタスクはAIに先に実行させるのか、どの結果はレビュー必須なのか、どのワークフローは再利用可能なテンプレートにできるのかを決める必要がある。

Claude Code、Claude Cowork、Chatは何に向いているのか

公式ブログの説明を見ると、Anthropicは創業者にClaudeを3種類の利用場面に分けて考えてほしいようだ。

Claude Codeはよりエンジニアリング寄りだ。コードを書く、スクリプトを生成する、境界ケースを分析する、コンポーネント仕様や技術ドキュメントを作る、といった用途に向いている。アイデアを動くものへ進めるための問題を解決する。

Claude Coworkは、委任できる仕事代理に近い。市場調査、キャンペーン設計、資金調達戦略、運用分析のように、継続的な実行が必要なタスクに向いている。比較的まとまった業務をまず一巡進めるための存在だ。

Claude Chatは、創業者の判断の瞬間に向いている。go-to-market戦略を考える、プロダクトポジショニングをストレステストする、ロードマップの優先順位を比較する、重要なナラティブを磨く。実行マシンではなく、素早く何度も議論できる思考パートナーである。

スタートアップチームに本当に役立つ点

このplaybookの価値は、創業者に「AIは重要だ」と告げることではない。それはもはや新しい話ではない。

より有用なのは、AIの使い方を散発的なツール呼び出しから、会社作りの方法論へ進めている点だ。各段階には異なるボトルネックがあり、それぞれのボトルネックはAIが参加できる部分に分解できる。

Idea段階では、AIが探索空間を広げる。MVP段階では、実装サイクルを圧縮する。Launch段階では、表現と配信実験を加速する。Scale段階では、再現可能なプロセスを蓄積する。

この考え方は小さなチームにとって特に重要だ。小さなチームにはすべての職能をカバーする人手がない。しかしAIを使えば、まず「第一版の能力」を補い、限られた人間の力を判断と関係構築が最も必要な部分に投入できる。

注意すべき落とし穴

最初の落とし穴は、AIが生成した内容をそのまま結論として扱うことだ。市場調査、競合分析、ユーザーペルソナ、成長戦略は、すべて実データとユーザーフィードバックで検証しなければならない。

2つ目は、レビューコストを低く見積もることだ。AIは初稿のコストを大きく下げられるが、コード品質、法的リスク、ブランド表現、商業上の約束、セキュリティ問題には、なお人間が責任を持つ必要がある。

3つ目は、早すぎる自動化だ。まだ手作業でうまく回っていないプロセスを、すぐにagentへ自動実行させるべきではない。より安定した方法は、まずワークフローの小さな一部にAIを参加させ、出力品質を観察し、段階的に範囲を広げることだ。

まとめ

AnthropicのThe Founder’s Playbookが伝えるシグナルは明確だ。AI-native startupの強みは、単にAIでコードを書けることではない。会社の初日から、AIをプロダクト、エンジニアリング、マーケティング、営業、運用にまたがる協働レイヤーとして組み込むことにある。

創業者にとって最も現実的な出発点は、壮大なAIワークフローを構築することではない。最も時間を消費し、最も反復的で、進行を最も遅らせているタスクを1つ選び、Claudeに最初の版を作らせることだ。本当の競争力は、人間の創業者が方向、品質、信頼をどう管理するか、そしてチームがこの協働方式を日常業務に安定して組み込めるかにかかっている。

参考資料

The founder’s playbook for the age of AI

Vercel AI SDK とは？TypeScript 開発者が AI アプリを構築するための統一ツールキット

Sun, 17 May 2026 23:07:38 +0800

vercel/ai は、Vercel がメンテナンスしているオープンソースの AI SDK です。

位置づけは明確です。TypeScript 開発者が AI アプリケーションや AI Agent を構築するための統一ツールを提供します。Next.js の背後にいるチームから生まれたものですが、Next.js 専用ではありません。React、Svelte、Vue、Angular などの UI フレームワークや、Node.js などのランタイムにも対応しています。

プロジェクト URL：https://github.com/vercel/ai

チャットアプリ、AI ライティングツール、RAG アプリ、ツール呼び出しを伴う Agent、ストリーミング出力 UI、複数のモデルプロバイダーをひとつのアプリに接続したいプロダクトを作っているなら、Vercel AI SDK は注目に値する基盤ライブラリです。

解決しようとしている中心課題

現在 AI アプリを作るとき、最大の悩みの一つは「モデルを呼べるか」ではありません。モデルプロバイダーごとに API、ストリーミング出力、ツール呼び出し、エラー処理、フロントエンドの状態管理が違うことです。

たとえば：

OpenAI には独自の SDK とレスポンス形式があります。
Anthropic には独自のメッセージ構造があります。
Google、xAI、Mistral、DeepSeek、Groq などもそれぞれ異なります。
ストリーミング出力では chunk の処理が必要です。
ツール呼び出しでは、モデルが発行する構造化リクエストを処理します。
チャット UI では、メッセージ、読み込み状態、キャンセル、再試行、エラー表示も管理する必要があります。

プロバイダーごとに手書きのアダプターを作ると、プロジェクトはすぐに複雑になります。

Vercel AI SDK の考え方は、こうした差異を統一 API の背後に収めることです。開発者はひとつのインターフェースでアプリを書き、Provider を通じて異なるモデルへ接続します。

統一 Provider アーキテクチャ

Vercel AI SDK の重要な特徴の一つは provider-agnostic、つまり特定のモデルベンダーに縛られないことです。

統一 API を通じて OpenAI、Anthropic、Google などのモデルプロバイダーにアクセスできます。プロジェクト README では、デフォルトで AI SDK が Vercel AI Gateway を使い、複数の主要 provider へアクセスしやすくすると説明されています。

これは実際の開発で役に立ちます。

多くの AI プロダクトは、最終的に一つのモデルだけには依存しません。

強い推論モデルが向くタスクがあります。
安価で高速なモデルが向くタスクがあります。
マルチモーダルが必要なタスクがあります。
長いコンテキストが必要なタスクがあります。
ローカルまたはプライベートなモデル展開が必要なタスクがあります。

統一 Provider アーキテクチャにより、モデル切り替え、段階的リリース、コスト制御、フォールバック戦略を作りやすくなります。

ストリーミング出力はフロントエンド体験の鍵

AI アプリと従来の API の大きな体験差の一つは、レスポンスが長くなりやすいことです。

ユーザーが完全な回答を待たなければならないと、チャットツール、ライティングツール、コードアシスタントは遅く感じられます。ストリーミング出力なら、テキストが少しずつ表示され、ユーザーは早く結果を確認できます。

Vercel AI SDK はストリーミング生成を比較的しっかり抽象化しています。開発者は低レベルのイベントストリームをゼロから処理する必要がなく、SDK の生成 API とストリーミング API を使ってモデル出力をフロントエンド UI に接続できます。

Next.js / React アプリでは特に便利です。

AI チャット UI は一見シンプルですが、実際には次のような処理が必要です。

メッセージ一覧。
ユーザー入力。
サーバーリクエスト。
ストリーミング token 表示。
読み込み状態。
エラー状態。
生成の中止。
再生成。

これらは AI SDK が開発者の反復作業を減らそうとしている領域です。

ツール呼び出しと Agent シナリオ

AI アプリが「会話」から「実行」へ進むにつれて、ツール呼び出しは重要になります。

モデルは自然言語を返すだけでなく、外部関数を呼ぶ必要があるかもしれません。

データベースを検索する。
ドキュメントを検索する。
業務 API を呼ぶ。
注文状態を読む。
グラフを生成する。
カレンダー予定を作成する。
プロジェクトファイルを変更する。

Vercel AI SDK はツール呼び出し関連の機能を提供し、開発者がツール、パラメータ、実行ロジックを定義し、モデルが適切なタイミングで呼び出しを要求できるようにします。

これが「チャット UI SDK」から「AI アプリと Agent のツールキット」へ広がっている理由の一つです。

ただし、ツール呼び出しを追加すれば終わりではありません。実際のプロジェクトでは次も考える必要があります。

パラメータ検証。
権限境界。
ツール呼び出しログ。
冪等性。
タイムアウトと再試行。
人間による確認。
センシティブ操作の制限。

AI SDK はインターフェースと流れを助けますが、安全境界は開発者が設計する必要があります。

UI 統合

Vercel AI SDK はフロントエンドフレームワークと相性がよい SDK です。

コアの生成 API だけでなく、チャット、補完、メッセージ状態、ストリーミング UI の抽象化も提供しています。Next.js と React を使うチームにとっては、多くのボイラープレートを減らせます。

ただし、Vercel へのデプロイ専用ではありません。

プロジェクトが TypeScript 技術スタックで構成されている場合、またはバックエンドが Node.js 環境で動いている場合、AI SDK はモデル呼び出しとストリーミング処理の層として使えます。Vercel にデプロイするかどうかは、アプリの構成、チームの習慣、インフラ選択によります。

Skill for Coding Agents

vercel/ai の README には興味深い提案もあります。Claude Code や Cursor などの coding agent を使っている場合、AI SDK skill をリポジトリに追加できます。

例のコマンドは次のとおりです。

`1`	`npx skills add vercel/ai`

これは、Vercel が AI SDK の利用者を人間の開発者だけでなく coding agent も含めて考えていることを示しています。

agent が AI SDK を使うプロジェクトを変更する場合、リポジトリ内に専用 skill があると、SDK の約束事、よく使う API、プロジェクト構造、ベストプラクティスをより理解しやすくなり、雑なコード変更を減らせます。

この方向性は注目に値します。

将来、オープンソースプロジェクトは README や docs だけでなく、AI coding agent 向けの構造化された skill 説明も提供するようになるかもしれません。複雑な SDK では、それが新しい開発者体験の入口になる可能性があります。

向いているプロジェクト

Vercel AI SDK は次のような場面に向いています。

Next.js / React ベースの AI チャットアプリ。
ストリーミング出力が必要なライティング、Q&A、サポート、コードアシスタント。
複数の model provider を接続する AI プロダクト。
RAG やドキュメント Q&A のプロトタイプを素早く作りたいチーム。
ツール呼び出し、関数呼び出し、軽量 Agent 機能が必要なアプリ。
TypeScript / Node.js 技術スタックを使っているチーム。

特にフロントエンド開発者とフルスタック開発者に向いています。多くの AI アプリで難しいのはモデル呼び出しだけではなく、モデル出力を安定し、滑らかで、対話的なプロダクト体験にすることだからです。

向いていない場面

プロジェクトの中心が Python バックエンド、深層学習の訓練、モデル微調整、低レベル推論サービスである場合、Vercel AI SDK は中心的なツールではないかもしれません。

これはアプリケーション層の SDK であり、モデル訓練フレームワークではありません。

必要なものが次のような場合は：

独自モデルを訓練する。
GPU 推論クラスターを管理する。
低レベルの batch inference を行う。
tokenizer、KV cache、量子化、推論エンジンを深く制御する。

PyTorch、vLLM、SGLang、TensorRT-LLM、llama.cpp、またはクラウド推論サービスを見るほうがよいでしょう。

Vercel AI SDK は「モデル能力をプロダクトへ接続する」ためのアプリケーション開発層に近い存在です。

使うときの注意点

第一に、統一 API を「完全に差異がない」と理解しないことです。

モデル provider ごとに、能力、コンテキスト長、ツール呼び出し形式、ストリーミングの細部、エラー型、課金方式は依然として異なります。統一 SDK は開発上の摩擦を減らしますが、モデル差を消すわけではありません。

第二に、コストを制御することです。

AI アプリが本番に出ると、ストリーミングチャット、再試行、ツール呼び出し、RAG 検索、複数モデルの fallback はすべて呼び出しコストを増やす可能性があります。レート制限、キャッシュ、ログ、予算監視が必要です。

第三に、安全境界を扱うことです。

モデルがツールを呼べるなら、そのツールが何をできるかを制限する必要があります。高リスク操作をモデルに直接実行させたり、秘密情報、データベース書き込み権限、本番操作をそのまま露出させたりしてはいけません。

第四に、可観測性を残すことです。

AI アプリで問題が起きたとき、フロントエンドのエラーだけでは足りません。ユーザー入力、選択されたモデル、ツール呼び出し、応答時間、token 消費、エラー種別、最終出力を把握する必要があります。

まとめ

vercel/ai は新しいモデルではなく、単なるチャットコンポーネントでもありません。

TypeScript AI アプリ開発のための基盤に近いものです。統一 Provider、ストリーミング出力、ツール呼び出し、フロントエンド状態管理、agent シナリオが一つのオープンソース SDK にまとまっています。

Next.js、React、TypeScript、Node.js をすでに使っているチームにとっては、「モデル API が動く」状態から「プロダクト体験として使える」状態までの開発コストを大きく下げられます。

ただし万能ではありません。モデル選択、権限設計、コスト制御、ログ監視、業務上の安全性は、依然として開発者が責任を持つ領域です。

モデルを訓練するのではなく AI アプリを作りたいなら、Vercel AI SDK は早めに試す価値のあるツールキットです。

参考資料

Midjourney 2026年5月アップデート：会話モード、AI支援開発、SREF整理

Sun, 17 May 2026 20:20:51 +0800

Midjourney 2026年5月14日の Office Hours で重要なのは、単一のモデルパラメータではない。プロダクトの形が「プロンプトを入力して画像を生成する」ものから、「より自然に創作ワークフローを組み立てる」ものへ進んでいることだ。

今回の内容は、Midjourney チームの最近の Q&A をまとめた日本語記事に基づいている。扱われているのは、会話モードの強化、AI支援開発、サイト改修、SREF とタグ整理、Omni-reference、複数キャラクターの一貫性、そしてチーム内での Midjourney 利用だ。

一言で言えば、Midjourney は画像生成を、会話でき、整理でき、継続的に反復できる創作システムに近づけようとしている。

会話モードの重要性が増している

今回もっとも直接的な変化は Conversational Mode、つまり会話モードだ。

これまで Midjourney を使うには、多くの操作がパラメータや固定された書き方に依存していた。アスペクト比、画像参照、スタイル参照、モデルパラメータなどのルールを覚え、それを prompt や UI 設定に入れる必要があった。

新しい会話モードの方向性は、こうした設定をより自然な言葉で指定できるようにすることだ。

たとえば、音声やテキストで次の内容を指定できる。

デフォルトパラメータ。
16:9 のようなアスペクト比。
画像参照。
スタイル参照、つまり --sref。
V7 の Omni-reference。

これは Midjourney が生成品質だけでなく、パラメータ操作の負担も下げようとしていることを示している。

普通のユーザーにとって最大の変化は、コマンドを常に覚えなくてもよくなることだ。ヘビーユーザーにとっては、会話モードが十分安定すれば、自然言語で生成設定を調整する入口になり得る。

AI支援開発が Midjourney チームの反復速度を変えている

もう一つ興味深い点は、Midjourney チーム自身が AI支援開発を大規模に使っていることだ。

元記事によれば、チームは小さな bug、UI 上の摩擦、ワークフロー上の問題を以前よりずっと速く修正できるようになっている。ユーザーとの通話中に製品 bug が見つかり、AI支援でリアルタイム修正し、レビュー後すぐに展開した例も紹介されている。

これは「AI がエンジニアのコードを書く」という話以上に重要だ。

AI 開発ツールが、AI 製品自身の反復方法に影響し始めているということだからだ。

ユーザーフィードバックを修正フローへ早く入れられる。
小さな体験上の問題を処理しやすくなる。
エンジニアはアーキテクチャ、レビュー、設計判断、テストへより多くの力を使える。
プロダクトチームは edge case をより頻繁に整理できる。

Midjourney のような製品には、創作経路、パラメータ組み合わせ、モバイル体験、検索、整理フローが大量にある。多くの問題は「コアモデルが画像を生成できない」ことではなく、入口が使いにくい、操作が一手多い、特殊な状態が気持ちよくない、といったものだ。

AI支援開発は、このような小さく大量にある改善を加速するのに向いている。

サイト改修の重点はワークフローであり、機能削除ではない

Office Hours では、Midjourney の Web サイトが大きく改修中であることも触れられている。

目標は複雑な機能を削ることではなく、創作フローをより直感的にし、新規ユーザーが入りやすくし、ツールと機能をより分かりやすく整理することだ。

これは重要だ。

Midjourney の問題は機能不足ではない。機能が増えるほど、入口、保存、整理、参照、探索、再利用が複雑になる。ライトユーザーにとって難しいのは「どこから始めるか」であり、ヘビーユーザーにとって難しいのは「大量のスタイル、参照、実験結果をどう管理するか」だ。

可能な展開方針としては、次のようなものがある。

新旧インターフェースを並行提供する。
まず alpha テストを行う。
ヘビーユーザーへの影響を避けるため、段階的に移行する。

この方針から、チームが Midjourney を単なる画像生成の玩具とは見ていないことが分かる。多くのユーザーはすでに実際の創作ワークフローに組み込んでおり、UI 変更で既存の習慣を簡単に壊すことはできない。

SREF、スタイル、タグ整理はまだ痛点

SREF とスタイル整理は、今回の Q&A で特に注目すべき部分だ。

ユーザーはよりよい整理システムを求めている。特に次のようなものだ。

ランダム SREF。
スタイル参照。
保存した美学方向。
タグと色付きタグ。
より強いフィルタリング、分類、再利用。

一方でチームは、現在のフォルダーシステムが一つの画像を複数フォルダーに入れられ、無制限のフォルダー数をサポートし、フィルタリングと並び替えもできるなら、タグはフォルダーにない何を提供するのか、という問いも投げている。

これは現実的な問いだ。

多くのプロダクトは、ユーザーがタグを欲しいと言うからタグを追加する。しかしタグシステムの設計が悪いと、別の混乱した分類層になる。フォルダー、タグ、お気に入り、検索、フィルター、プロジェクト、スタイルライブラリの境界が曖昧だと、かえって管理しにくくなる。

そのため Midjourney チームは、より具体的なワークフロー例を集めたいと考えている。ユーザーはどの場面でタグを必要とするのか。なぜフォルダーでは足りないのか。スタイルを素早く組み合わせたいのか、プロジェクトをまたいで再利用したいのか、テーマ、色調、写真スタイル、キャラクター関係で絞り込みたいのか。

Midjourney にとって、整理システムは生成モデルと同じくらい重要になり得る。ユーザーが長期的に創作を始めると、難しいのは一枚の画像を生成することではなく、数千枚の画像、数百のスタイル方向、反復実験の結果を管理することだからだ。

Omni-reference はより複雑なキャラクター制御へ向かう

元記事では、将来の Omni-reference / subject reference システムが、複数のキャラクター参照を同時に扱い、異なる主体をよりよく分離できる可能性にも触れている。

これは AI 画像生成の長年の痛点、つまりキャラクター一貫性と複数キャラクター関係に直結する。

一人のキャラクターを一貫させるだけでも難しい。複数人になるとさらに難しい。よくある問題は次の通りだ。

A の特徴が B に移る。
複数人物の身份が混ざる。
服装、髪型、顔の特徴が画像ごとに安定しない。
参照画像が主体だけでなく全体スタイルへ強く影響しすぎる。

Omni-reference が主体分離をよりうまく扱えるなら、Midjourney は漫画、絵コンテ、広告ビジュアル、キャラクター設定、ゲームコンセプトアート、連続した物語により向くようになる。

これは V7 以降も継続して注目すべき方向だ。

Midjourney は prompt を捉え直している

今回のまとめには、興味深い考え方もある。言語は想像力を圧縮する層だ、というものだ。

これは Midjourney の製品方向をよく説明している。

多くのユーザーは、AI 画像生成の核心はより長く、より正確な prompt を書くことだと思いがちだ。しかし実際の創作では、画像参照、スタイル参照、moodboard、SREF、バリエーション、再生成、後処理の方が、長文 prompt より役立つことが多い。

Midjourney チームの Duncan のワークフローもそれを示している。彼は Midjourney を sketchbook のように使い、moodboard、SREF、少ない文字、高い --r 再生成、強い/微妙なバリエーション、Photoshop レタッチ、外部アップスケールを組み合わせる。

つまり成熟した Midjourney ユーザーは、「魔法のプロンプト」だけで作業しているわけではない。

より現実的な流れは次の通りだ。

少ない言葉で方向を与える。
画像参照で視覚的文脈を与える。
SREF でスタイルを絞る。
多数のバリエーションで空間を探索する。
人間の審美眼で結果を選ぶ。
外部ツールで後処理する。

Prompt は重要だが、すべてではない。

ユーザーにとっての意味

たまに画像を生成するだけなら、今回の更新で最も直接的な影響は会話モードが使いやすくなることだ。将来的には、比率、参照画像、スタイル、パラメータを、コマンドを覚えずに自然に伝えられるかもしれない。

ヘビーユーザーなら、注目すべき方向は三つある。

第一に、整理システム。

SREF、スタイル、フォルダー、お気に入り、タグがどう進化するかは、長期的な創作効率に直結する。

第二に、サイト改修。

新しい UI が探索、整理、再利用、書き出しをつなげられるなら、Midjourney は単一の生成器ではなく、より専門的な創作ツールに近づく。

第三に、キャラクターと主体参照。

Omni-reference が複数キャラクターと主体分離を安定して扱えるなら、Midjourney は単発画像だけでなく、継続プロジェクトにより向くようになる。

まとめ

Midjourney 2026年5月の Office Hours の重点は、派手な単一パラメータではない。プロダクトが引き続き「創作システム」へ進化していることだ。

会話モードは入力のハードルを下げる。AI支援開発は反復速度を上げる。サイト改修はワークフロー再編を目指す。SREF とタグの議論は長期的なアセット管理を示す。Omni-reference はキャラクター一貫性と複雑な主体制御に関わる。

AI 画像生成ツールにとって、モデル能力が重要なのは当然だ。しかし生成品質が一定水準に達したあと、ユーザーが長く残るかどうかを決めるのは、ワークフロー、整理能力、制御性、反復速度であることが多い。

Midjourney はその部分を補い始めている。

参考資料

Midjourney 最新ニュース（2026年5月14 日）｜アキスケ

OpenClaw 作者 Peter Steinberger は AI ソフトウェア開発をどう見ているのか：OpenClaw から閉ループ開発へ

Sun, 17 May 2026 20:02:26 +0800

Peter Steinberger の経歴は、AI ソフトウェア開発で何が変わっているのかを見るうえでよい材料になる。

彼は「AI で突然注目された新人」ではない。OpenClaw の前から、PSPDFKit の創業者として PDF レンダリング、文書処理、開発者ツールに長く取り組んできた。この種のプロダクトは、コンセプトだけでは勝てない。性能、互換性、API 設計、企業顧客、長期保守に向き合う必要がある。

そのため、Steinberger が後に AI ツールで OpenClaw を作り、AI Agent、個人自動化、AI coding について語ったとき、重要なのは「一人で大量のコードを書いた」ことだけではない。より面白いのは、長年のソフトウェア工学経験と新世代の AI coding agent を組み合わせ、開発プロセスをどう捉え直したかだ。

AI coding は魔法のボタンではない

AI coding の議論は、よく二つの極端に分かれる。

一方は、AI はすでにコードを書けるのでプログラマーは不要になる、と言う。

もう一方は、AI が書くコードは信頼できず、本当のエンジニアリングは人間が手で書くべきだ、と言う。

Steinberger の経験は第三の見方に近い。AI はソフトウェア開発の操作単位を変えるが、エンジニアリング判断を消すわけではない。

従来、開発者の仕事は主に「コードを編集する」ことを中心に回っていた。要求分解、アーキテクチャ判断、実装、テスト、バグ修正は、すべて人間によるコード変更を軸にしていた。

AI coding agent が入ると、開発者はだんだん実行システムを管理する存在に近づく。

目標を説明する。
コンテキストを与える。
境界を決める。
agent にコードを変更させる。
テストとチェックを実行する。
結果に基づいて反復する。

これは単にキーボードをモデルに渡すことではない。人間の役割を「すべての行を自分で打つ」ことから、「方向を定義し、フィードバックを設計し、結果を判断する」ことへ移すものだ。

なぜ彼は vibe coding という呼び方を好まないのか

Steinberger をめぐる議論でよく出る言葉に vibe coding がある。

この言葉はもともと、開発者が自然言語でアイデアを説明し、AI に大量のコードを生成させ、実行結果とフィードバックで調整していく新しい開発スタイルを指していた。

しかし Steinberger は、この言葉を全面的には受け入れていない。公開記事では、彼が vibe coding をやや軽蔑的な表現になりやすいと見ていることが紹介されている。AI 支援開発を「感覚で適当に生成する」もののように見せ、背後にある技能、判断、経験を見落とすからだ。

この批判には筋がある。

本当に有効な AI coding は、適当に一文を入力してモデル出力を信じることではない。必要なのは次のような能力だ。

曖昧な要求を実行可能なタスクに分解する。
モデルが目標を誤解したかどうかを見抜く。
テストと受け入れ基準を設計する。
コード構造が長期保守に影響するか判断する。
いつ生成を止めて人間のレビューに切り替えるべきか分かる。

つまり、AI はコードを書く摩擦を下げるが、システムを理解する責任を下げるわけではない。

鍵は閉ループにある

Steinberger のインタビューや記事でよく要約される考え方の一つが「ループ」だ。

AI にコードを生成させるだけなら、開ループである。

AI にコードを生成させ、実行させ、エラーを読み、問題を修正し、再びテストを走らせるなら、閉ループに近づく。

この差は非常に大きい。

開ループ生成は、表面上は使えそうなソフトウェアを作りやすい。ページは開き、機能はあるように見え、コードも多い。しかし実際の環境に入ると、状態管理、権限、例外処理、境界条件、デプロイの問題が出てくる。

閉ループ開発では、出力がフィードバックによって制約される。もっとも単純なループは次の通りだ。

目標を明確に書く。
AI にコードを変更させる。
テスト、型チェック、lint、ビルドを自動実行する。
エラーを AI に返す。
通るまで繰り返す。
最後に人間が重要経路をレビューする。

AI ソフトウェア開発が本当に効率を上げるのはここだ。モデルが一度で正解を書くからではない。生成、検証、修復のサイクルに高速に参加できるからだ。

経験が多いほど AI を使いやすい

AI coding で生まれやすい誤解の一つは、「経験はもう重要ではない」というものだ。

Steinberger の事例はむしろ逆を示している。経験はより重要になる。ただし役割が変わる。

経験あるエンジニアは、次の判断がしやすい。

どのタスクを agent に渡すべきか。
どのモジュールに先にテストを書くべきか。
どの変更はリスクが高く、AI に広範囲リファクタを任せるべきではないか。
どの生成コードは見た目だけ妥当なのか。
どの問題はパッチではなくアーキテクチャ調整で解くべきか。

AI は大量の候補案を生成できる。しかし候補が多いほど判断力が必要になる。経験が少ない人は「動いた」ことに惑わされやすい。経験ある人は、保守できるか、拡張できるか、安全境界を壊さないか、問題が起きたときに定位できるかを問う。

だから AI coding agent は、ソフトウェア工学を単なるチャットにはしない。一部の実行労働を外に出しつつ、計画、レビュー、検証、取捨選択の重要性を増幅する。

OpenClaw の意味はプロジェクトそのものにとどまらない

OpenClaw が注目されたのは、単にオープンソース AI agent だからでも、成長が速かったからでもない。

それは一つのシグナルでもある。開発者は、AI に単に質問へ答えてほしいのではなく、実際のツールに接続し、実際の行動を完了してほしいと思い始めている。

従来のチャットボットは会話欄の中にとどまる。コードを説明し、下書きを書き、助言はできるが、多くの場合、人間がコピー、貼り付け、ソフトウェア起動、コマンド実行を行う必要がある。

Agent の方向性は、モデルをツールにつなぐことだ。

ファイルシステム。
ブラウザ。
ターミナル。
メール。
カレンダー。
第三者サービス。
プロジェクトリポジトリ。

モデルがこれらのツールを使えるようになると、ソフトウェア開発の境界が変わる。AI は単なる「コード補完」ではなく、プロジェクト読解、タスク分解、ファイル編集、テスト実行、PR 整理、ワークフロー自動化に関わるようになる。

Steinberger が OpenAI に加わったことで注目された理由もここにある。彼は一人の開発者の物語だけではなく、個人 agent がデモから日常業務へ進むというプロダクト方向を示している。

普通の開発者にとっての意味

普通の開発者にとって、Steinberger の経験をそのまま再現できるとは限らない。

誰もが複数の agent を同時に管理できるわけではない。すべてのプロジェクトが高強度の AI 生成に向くわけでもない。すべてのチームが「まず生成し、すばやく反復する」速度を受け入れるわけでもない。

それでも学べることはいくつかある。

第一に、タスクを明確に書く。

AI は曖昧な目標に敏感だ。「最適化して」と言うと、スタイル、構造、機能、ロジックまで変えるかもしれない。「ログイン失敗時のエラーメッセージを英語から中国語へ変更し、認証フローは変えない」と言えば、結果はより制御しやすい。

第二に、検証コマンドを固定する。

テストもビルドコマンドも lint もないプロジェクトでは、AI はループを作りにくい。npm test、go test ./...、pytest、hugo のような基本的なコマンドだけでも、目視確認だけよりはずっとよい。

第三に、変更範囲を制御する。

一度に一つのモジュール、一つの bug、一つのページだけを AI に扱わせる方が、「プロジェクト全体をリファクタして」と頼むより通常は信頼できる。

第四に、人間のレビューを残す。

認証、決済、権限、データ削除、デプロイスクリプト、データベース移行、セキュリティ設定では、コードが AI 生成だからといってレビュー基準を下げてはいけない。

第五に、prompt と失敗パターンを振り返る。

AI がある種のタスクをよく誤解するなら、その制約をプロジェクトルール、agent instructions、skill ファイルに書く。AI coding 能力はモデルだけでなく、周囲に作る作業環境からも生まれる。

AI ソフトウェア開発はどこへ向かうのか

Steinberger の物語は、AI ソフトウェア開発が「コードを書く支援」から「ソフトウェア生産フローを組織する」方向へ進んでいることを示している。

初期の AI coding ツールの価値は、関数補完、エラー説明、テンプレート生成が中心だった。今の変化は、agent がファイルをまたいで作業し、ツールを呼び出し、チェックを実行し、フィードバックに基づいて修正を続けられることだ。

そこからいくつかの流れが見えてくる。

第一に、個人開発者の生産上限は上がる。

一人でより多くのプロトタイプ、スクリプト、社内ツール、小型プロダクトを進められる。ただし生産量が増えることは品質が自動で上がることではない。生成が速いほど検証が重要になる。

第二に、プロジェクト構造がより重要になる。

コードが明確で、テストがはっきりしていて、ドキュメントが整っているほど、AI は正しく変更しやすい。混乱したプロジェクトは人間にも AI にも難しい。

第三に、ソフトウェアエンジニアはワークフロー設計者に近づく。

今後重要なのは、ある言語を書けるかどうかだけではない。要求、コンテキスト、ツール、テスト、デプロイ、権限を制御可能なループに組み立てられるかだ。

第四に、セキュリティ境界はより敏感になる。

Agent が何かを実行できるなら、間違ったことも実行できる。ファイルを読み、コマンドを実行し、サービスへアクセスできるなら、権限、監査、ロールバックは AI 開発環境の基盤になる。

まとめ

Peter Steinberger の AI ソフトウェア開発観で最も価値があるのは、「AI がどれだけコードを生成したか」ではない。彼が示した新しい開発姿勢だ。

人間はエディタ内で一行ずつ入力するだけではなくなりつつある。目標を設計し、agent を管理し、フィードバックループを作り、結果をレビューし、システムを調整する。コードは今も重要だが、労働の唯一の中心ではなくなっている。

従来のソフトウェア開発が「コードを正しく書く」ことを重視していたとすれば、AI ソフトウェア開発は「システムが検証可能に正しい結果を継続して出す」ことをより重視するようになる。

これは単にエンジニアリングのハードルを下げる話ではない。能力の形を変える話だ。手作業の実装から、タスク分解、コンテキスト管理、ツール編成、自動検証、最終判断へ移っていく。

参考資料

Google Gemini Spark リーク解説：24 時間オンラインの Gemini Agent が登場するかもしれない

Sun, 17 May 2026 11:58:08 +0800

Google はまだ Gemini Spark を正式発表していません。

現在の情報は、主に Gemini Web 内部のテスト画面、コミュニティのスクリーンショット、TestingCatalog の報道、そして 36Kr / 新智元による関連リークの整理に基づいています。比較的一致している見方は、Gemini Spark BETA が Google の準備している常時稼働 AI Agent かもしれないというものです。単なるチャットアシスタントではなく、バックグラウンドでメール、オンラインタスク、複数ステップのワークフローを処理する「日常の AI 代理人」という位置付けです。

まず境界をはっきりさせると、これはリーク解説であり、Google の公式発表ではありません。機能、名称、公開時期はいずれも Google の正式発表を待つ必要があります。

まず結論

現時点で露出している情報を見ると、Gemini Spark の要点は 3 つです。

Gemini 体系の中で 24 時間オンラインの Agent になる可能性があり、通常のチャットモデルではない。
Google アプリ、チャット履歴、タスク、ログイン済みサイト、位置情報など、より広い個人コンテキストを利用する可能性がある。
情報共有、リモートブラウザデータ、購入操作、第三者サービス呼び出しに関わるため、魅力と同じくらいリスクも大きい。

Google が本当に Spark を投入すれば、Gemini の位置付けは「質問に答える AI」から「継続的に用事を処理する AI」へ変わります。

Gemini Spark とは何か

TestingCatalog は 2026 年 5 月 14 日、Google が Gemini Web 内で Gemini Spark BETA をテストしていると報じました。露出した welcome テキストでは、inbox、online tasks、さらに多くの複数ステップ作業を 24/7 で支援する everyday AI agent と説明されています。

36Kr / 新智元の記事も、Spark が見つかった後、外部からは「常時稼働 Agent」方向に見えると述べています。終日待機し、受信箱を処理し、オンラインタスクを実行し、購入や情報共有に関わる可能性もあります。

つまり Spark は単なる新モデル名ではありません。Gemini を会話ウィンドウから出し、ユーザーのメール、Web、予定、タスク、アプリ横断ワークフローへ入れる Gemini 製品レイヤーのアップグレードに近いものです。

どのように動く可能性があるか

TestingCatalog が公開した隠し onboarding テキストによると、Gemini Spark は複数の情報源からコンテキストを取得します。

Connected Apps。
skills。
chats。
tasks。
ユーザーがログインした Web サイト。
Personal intelligence。
location。

これらの情報は、Spark がユーザーのやりたいことを理解し、タスク実行時に必要なコンテキストを呼び出す助けになります。文面ではさらに、一部のアクションを完了するために、Gemini が名前、連絡先、ファイル、好み、ユーザーが機密と考える可能性のある情報を第三者に共有する場合があるとも示されています。

これらの説明が最終的に正しければ、Spark の動作は一回限りの Q&A ではなく、「コンテキストを持つ代理システム」に近くなります。現在の 1 つの prompt だけを見るのではなく、長期的な好み、連携アプリ、ブラウザ状態、タスク履歴を組み合わせる可能性があります。

なぜ重要なのか

Gemini Spark の重要性は、チャット入口が 1 つ増えることではありません。Google が自然なエコシステム入口を持っている点にあります。

OpenAI や Anthropic も強力な Agent を作れますが、Gmail、Calendar、Drive、Chrome、Android、Workspace という完全なチェーンを自然に持っているわけではありません。Google が Spark をこれらの製品に接続すれば、ユーザーは追加のワークフローをあまり構築しなくても、Agent を日常業務に入れられます。

これにより 3 つの変化が起きます。

第一に、Gemini は受動的な Q&A から能動的な実行へ移ります。ユーザーは「このメールを要約して」と聞くだけでなく、inbox の整理、タスク追跡、後続アクションを継続的に任せるかもしれません。

第二に、Agent は個人コンテキストにより依存します。メール、予定、ファイル、ブラウザ状態、好みを理解するほど、有用な結果を返しやすくなります。

第三に、権限境界がより敏感になります。できることが増えるほど、いつ実行できるのか、どこまでできるのか、確認が必要かを明確にする必要があります。

リスクはどこにあるか

TestingCatalog が公開した文面には、注意すべき点がいくつかあります。

第一に、Spark は experimental です。仮に公開されても、完全に成熟した監督不要のシステムとして扱うべきではありません。

第二に、システム設計上は機微な操作の前に許可を求めるものの、文面では、確認なしに情報を共有したり購入を完了したりする可能性も示されています。

第三に、会話の継続性を保つため、Gemini は login details や remote code execution data などの remote browser data を保存します。ユーザーは Settings からこれらのデータを削除でき、Connected Apps や Personal intelligence 関連機能も無効化できます。

これらを合わせると、Spark の製品方向はかなり攻めています。提案を生成するだけではなく、本当にタスクを実行できる Agent を目指しています。ただし実行に近づくほど、厳格な権限、監査、確認、ロールバック機構が必要になります。

Remy、AI Ultra との関係

TestingCatalog は、Spark が以前 Remy という内部コードネームで呼ばれていた agentic Gemini upgrade のリネーム版であり、Google AI Ultra 加入者向け Gemini Agent の方向とも関係している可能性があると述べています。

この手がかりが正しければ、Spark は突然現れた新規プロジェクトではなく、Google が以前のより高階でクローズドな Agent 機能を再パッケージし、より広いユーザー層へ展開しようとしているものかもしれません。

36Kr / 新智元も、これを “Remy” から “Spark” へのアップグレードとして描写しています。Gemini Agent は単なる機能ではなく、24/7 のデジタル生活マネージャーへ向かうという見方です。

ただし、これはあくまでリーク情報に基づく判断です。Google が Spark を正式名称として使うのか、AI Ultra 限定なのか、より軽量なサブスクリプション層を出すのかは、公式確認を待つ必要があります。

MCP、skills、ツールエコシステム

同じコミュニティスクリーンショット群では、MCP Tool Testing のようなモデルセレクター項目も見つかっています。36Kr の記事は、これが新しい Gemini の MCP サードパーティツール統合ネイティブ対応や Thinking モード再構築を示唆している可能性があると見ています。

この手がかりは Spark と一緒に見ると面白くなります。

Spark が単なる「チャットできる助手」なら、skills や MCP の意味は限定的です。しかし Spark が長時間動作する Agent なら、ツール呼び出し、Web ページアクセス、タスク実行、コンテキストの読み書き、結果の納品が安定して必要になります。

つまり Spark は単独機能ではなく、Google Agent ツールエコシステムの一部かもしれません。モデルが理解と計画を担い、skills / MCP / connected apps が実行と拡張を担う構図です。

一般ユーザーにとっての意味

Gemini Spark が本当に公開されれば、一般ユーザーにとって直接的な変化は次のようなものになる可能性があります。

メールは要約されるだけでなく、分類、フォローアップ、タスク化される。
Web タスクは提案されるだけでなく、リモートブラウザ内で継続的に実行される可能性がある。
予定、位置、好み、過去の会話が Agent の長期コンテキストになる。
購入、予約、フォーム入力などの操作が AI 実行範囲に入る可能性がある。

便利に聞こえますが、ユーザーには新しい習慣が必要になります。AI が何を言ったかだけでなく、何をしようとしているのか、何をすでにしたのか、取り消せるのか、記録があるのかを見る必要があります。

将来の AI Agent 体験は、モデルの賢さだけでなく、権限プロンプトが明確か、タスクログを確認できるか、誤操作から回復できるかにも左右されます。

開発者とチームにとっての意味

開発者にとって Spark が重要なのは、Google が Agent を「デモ製品」から実際のワークフロープラットフォームへ移そうとしている可能性があるからです。

Spark が Google アプリ、サードパーティツール、ブラウザ状態に安定して接続できるなら、開発者は次の点を気にします。

API や拡張機構は公開されるのか。
MCP や skills は第三者が接続できるのか。
企業管理者は権限、データ保持、監査を制御できるのか。
Agent 実行失敗時に追跡可能なログがあるのか。
サンドボックス、承認フロー、機微な操作の確認をサポートするのか。

チームにとって、Spark はまず Gmail、Calendar、Docs、Drive、Chrome のような高頻度シーンから入る可能性があります。最初から高リスク業務を完全自動化するのには向かないかもしれませんが、inbox triage、会議フォローアップ、資料整理、市場調査、軽量な運用タスクには適しています。

今どう見るべきか

このニュースは「方向性の確度は高いが、細部の確定度は低い」と読むのがよさそうです。

方向性の確度が高いのは、Google が Gemini Agent をより能動的、より長時間稼働、より深くエコシステムへ接続する方向に進めている点です。TestingCatalog が報じた Gemini Web のテスト文面、コミュニティのスクリーンショット、36Kr が整理した複数のリークは、同じ方向を示しています。

細部の確定度が低いのは、正式名称、公開時期、権限ルール、サブスクリプション階層、利用可能地域、API 公開の有無、本当に Gemini Spark と呼ばれるかがまだ分からないためです。

現時点で最も安全な見方は次の通りです。

Spark をすでに公開済みの正式製品として扱わない。
Google の次段階の AI Agent 路線を示す強いシグナルとして見る。
権限、プライバシー、第三者へのデータ共有、リモートブラウザデータ保存について、Google がどう説明するかを待つ。

まとめ

Gemini Spark が最終的に公開されれば、Gemini がチャットアシスタントから常時稼働 Agent へ進む重要な一歩になるかもしれません。単にモデルを入れ替える話ではなく、Gemini を Google エコシステムのメール、Web、タスク、位置情報、personal intelligence、第三者サービスの中に入れる話です。

可能性は大きいです。より能動的で、実際のワークフローに近く、Google のエコシステムによって多くのユーザーへ配布しやすいからです。リスクも同じくらい大きいです。AI が情報を共有し、ブラウザ状態を保存し、購入を実行し、第三者サービスを呼び出せるなら、権限境界は非常に明確でなければなりません。

だから Gemini Spark で最も注目すべきなのは「どれだけ賢いか」ではなく、Google が 24 時間オンラインの AI Agent をどのように制御可能で、監査可能で、信頼できるものにするかです。

参考リンク：

Gemini 3.5 Pro がリーク：コードネームは Cappuccino、Google はコーディングと Agent で巻き返しを狙う

Sun, 17 May 2026 11:47:27 +0800

Google はまだ Gemini 3.5 Pro を正式発表していません。

現時点で見えている情報は、主に開発者コミュニティのスクリーンショット、匿名ベンチマーク、リーカーの投稿、メディアの報道に基づいています。36Kr / 新智元は 2026 年 5 月 15 日、次世代 Gemini のチェックポイントが社内で Cappuccino と呼ばれている可能性があり、関連モデルがコミュニティや評価プラットフォームで先に露出していると整理しました。

これらの情報は公式発表と同一視すべきではありません。ただし、方向性ははっきりしています。Google は、コーディングと推論能力、そして常時稼働する AI Agent という 2 つの弱点を同時に補おうとしています。

まず結論

今回のリークは 3 層に分けて見ると分かりやすいです。

Gemini 3.5 Pro はまだ正式発表されておらず、Cappuccino は内部チェックポイントまたは候補版のコードネームに近いものです。
露出した情報では、新しい Gemini はコード生成、SVG / インタラクティブ Web 生成、マルチモーダル出力で改善しているようです。
Google が並行してテストしている Gemini Spark は、モデルそのもの以上に重要かもしれません。24 時間稼働する個人向け AI Agent を示しているからです。

つまり、これは単なる「モデルのベンチマークニュース」ではありません。Google I/O を前にしたプロダクトロードマップのシグナルに近く、モデルは GPT-5.5 に追いつき、Agent はユーザーのワークフロー入口を押さえにいく構図です。

Cappuccino とは何か

36Kr の記事によると、Lentils の投稿では、Cappuccino というコードネームの Gemini 3.5 Pro チェックポイントが生成され始めているとされています。数時間前までコミュニティでは Gemini 3.2 が話題でしたが、最新リークでは一気に 3.5 へ飛びました。

この命名が最終的に正しければ、Google は次の Gemini を通常の小幅更新ではなく、より大きなバージョンジャンプとして見せたいのかもしれません。

ただし現時点では、Cappuccino はあくまでリーク上の内部コードネームとして扱うべきです。Google が正式モデルを公開済みという意味ではなく、最終的なリリース名が必ず Gemini 3.5 Pro になるとも限りません。

なぜコーディング能力が焦点なのか

今回のリークで最も注目されているのは、新しい Gemini のコーディング能力です。

36Kr が引用したコミュニティのスクリーンショットやベンチマーク情報によると、新モデルは次のタスクで強化されているようです。

SVG とビジュアルコンポーネントの生成。
インタラクティブ Web アプリの生成。
アニメーション、3D、調整可能なパラメータパネルなど複雑なフロントエンド出力。
論理推論とコード生成の改善。

記事ではさらに、Abacus.AI CEO の Bindu Reddy が、3.2 Flash はコーディングと推論で GPT-5.5 に近い水準に達しつつ、コストは低いと述べたことも紹介しています。一方、別のメディア筋は、新しい Gemini の総合性能はおおむね GPT-5.5 クラスだが、質的な飛躍とまでは言えないと見ているようです。

そのため、「GPT-5.5 に追いついた」という表現は慎重に読む必要があります。これは Google 公式のベンチマーク結果ではなく、複数のリークや匿名評価に基づく相対的な判断に近いものです。

Google がコーディングを急ぐ理由

AI コーディングは、開発者ツールから基盤モデル競争の中心へ移りました。

OpenAI には Codex があり、Anthropic には Claude Code があります。これらはエンジニアだけでなく、プロダクトマネージャー、デザイナー、運用担当者を「自然言語から動くプロダクトを作る」ワークフローへ連れてきています。

一方で Google には Gemini と Antigravity がありますが、開発者の意識の中で同じ強さのデフォルト入口にはなっていません。36Kr の記事でも、Antigravity は外部市場でまだ本格的に突破できておらず、価格、利用枠通知、体験の安定性についてコミュニティで議論が続いていると触れられています。

だからこそ、新しい Gemini が自分を証明するなら、コーディングが最も直接的な戦場になります。問われるのは「コードを書けるか」だけではありません。完全な UI を安定して生成できるか、複雑な要件を理解できるか、ツールを呼び出せるか、エラーを修正できるか、実際の開発フローに溶け込めるかです。

Spark は 3.5 Pro より重要かもしれない

同じリークの流れで、Gemini Spark BETA も見つかりました。

TestingCatalog などの情報によると、Spark の位置付けは「常時稼働 AI Agent」に近いものです。受信箱を処理し、オンラインタスクを実行し、複数ステップのワークフローを管理し、Google アプリ、スキルモジュール、チャット履歴、定期タスク、ログイン済みサイト、位置情報などのコンテキストに接続します。

これは Spark が通常のチャット入口ではないことを意味します。長時間オンラインで動き続け、コンテキストを読み続け、ユーザーの代わりにタスクを実行するシステムになり得ます。

魅力は明らかです。Google が Gmail、Calendar、Chrome、Android、Workspace、Gemini をつなげられれば、Spark は OpenAI や Anthropic が簡単には再現できない配布面の優位を持ちます。

同時にリスクも明らかです。36Kr の記事では、Spark 関連の説明に「確認なしに情報を共有したり購入を完了したりする可能性がある」という趣旨の表現があったと紹介されています。センシティブな操作の前に許可を求める設計だとしても、この種の Agent はプライバシー、権限境界、誤操作のリスクを生みます。

一般ユーザーにとっての意味

普通の Gemini ユーザーにとって、今回本当に注目すべきなのはモデル名ではなく、次の 3 つの変化です。

第一に、Google は「完成した結果を生成する」能力をさらに強化する可能性があります。これまで Gemini は、ビジュアル生成、SVG、フロントエンドページで手抜きに見える出力をするという不満がありました。新モデルが一度に複数の完成度の高い案を出せるなら、体験はかなり改善します。

第二に、コーディング能力はより軽量なモデルへ下りていく可能性があります。リークでは Flash 版のコーディング、推論、インタラクティブ生成の改善が繰り返し語られており、将来は複雑なタスクに必ずしも Pro モデルが必要ではなくなるかもしれません。

第三に、Agent はより能動的になります。Spark が公開されれば、Gemini は質問に答えるだけではなく、メール、Web、購入、予定、アプリ横断タスクを長期的に引き受け始める可能性があります。

効率面では良い知らせですが、権限管理には新しい課題が生まれます。

開発者にとっての意味

開発者は 2 つの点を注視すべきです。

1 つ目はツールエコシステムです。36Kr の記事では、コミュニティがモデル選択画面に MCP Tool Testing のような未公開入口を見つけたとされています。Gemini が MCP やサードパーティツールテストをネイティブにサポートするなら、開発者自身のツールチェーンに接続しやすくなります。

2 つ目はコストと安定性です。新しい Gemini が一部ベンチマークで GPT-5.5 に追いついたとしても、開発者が最終的に見るのは実際のコード品質、コンテキストの安定性、価格と利用枠が予測可能かどうかです。

過去 1 年の AI コーディングツール競争が示したのは、モデル能力は入場券にすぎないということです。開発者を残すのは、日常プロジェクトで安定してコードを修正し、テストを走らせ、コンテキストを読み、境界条件を扱えるかどうかです。

今このニュースをどう読むべきか

このニュースは「強いシグナル、弱い確認」として読むのが適切です。

強いシグナルは、複数のコミュニティ上の手がかりが、Google がより強い新 Gemini と、より能動的な Gemini Spark Agent を準備していることを示している点です。

弱い確認は、Gemini 3.5 Pro がまだ公式発表されておらず、Cappuccino もリーク上のコードネームにとどまり、「GPT-5.5 に追いついた」という主張も Google 公式ベンチマーク、第三者評価、実ユーザーの検証を待つ必要がある点です。

現時点で最も安全な見方は次の通りです。

すでに公開された製品として扱わない。
Google の次段階の Gemini 路線を示す早期予告として見る。
I/O または今後の公式イベントで、モデル名、API 提供、価格、コンテキストウィンドウ、ツール呼び出し、Agent の権限境界が確認されるかに注目する。

まとめ

Gemini 3.5 Pro / Cappuccino の露出は、Google が次世代 Gemini をより強く押し出そうとしている可能性を示しています。補おうとしているのは単一の能力ではなく、AI ワークフロー全体です。モデルはコードを書き、UI を生成し、複雑な推論を処理する必要があり、Spark は Gemini を常時稼働 Agent へ押し出します。

ただし公式発表前は、すべてのベンチマークやスクリーンショットは手がかりにすぎません。Gemini 3.5 Pro が巻き返せるかを決めるのは、コードネームの響きではなく、実際の開発、実際のオフィス業務、実際の複数ステップタスクで安定して勝てるかどうかです。

参考リンク：

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の本当の難しさがあります。

DeepSeek-TUI：DeepSeek V4をターミナル上のコーディングAgentにする

Sat, 16 May 2026 22:41:41 +0800

DeepSeek-TUI は、DeepSeek V4をターミナル開発フローに接続するオープンソースプロジェクトです。単なるチャットの外枠ではありません。Claude CodeやCodex CLIに近い「コマンドラインのコーディングAgent」であり、ファイルを読み、コードを編集し、コマンドを実行し、ツールを呼び出し、TUI上でタスクを継続的に進められます。

すでにエディタとターミナルを行き来している開発者にとって、この種のツールの価値は分かりやすいものです。コードをWebチャットへ何度もコピーする必要がなく、プロジェクト構造を毎回手で説明する必要もありません。タスクを渡せば、現在のワークスペースからコンテキストを読み取り、手順を計画し、変更を実行し、結果をレビュー用に返してくれます。

DeepSeekの利用入口を補う

DeepSeekモデル自体は強い推論能力とコード能力を持っています。ただし、その能力を実際の開発フローに落とし込むには、工程化された外側のレイヤーが必要です。

Webチャットは質問には向いていますが、長時間のプロジェクト編集には向いていません。APIはシステム連携には向いていますが、個人開発者はツール呼び出し、コンテキスト管理、ファイル操作、権限制御を自分で組む必要があります。DeepSeek-TUIが補おうとしているのはこの層です。DeepSeek V4を、ターミナル内で働けるAgentとして包みます。

プロジェクト説明によると、主な機能は次の通りです。

ターミナルTUI;
DeepSeek V4向けの会話とタスク実行;
ツール呼び出しとファイル操作;
1Mコンテキスト対応;
Autoモード;
サブAgent;
サンドボックス実行;
永続タスクキュー。

これらの機能の目的は、モデルの返答をより人間らしくすることではありません。モデルを開発現場に入りやすくすることです。

長いタスクには純粋なCLIよりTUIが向いている

多くのAI CLIツールは、最初はプレーンテキストの対話から始まります。プロンプトを入力し、出力を待ち、コマンドをコピーしたり追加コンテキストを渡したりする方式です。これは単純ですが、タスクが長くなるとすぐ混乱します。

TUIの利点は、会話、ファイル、実行結果、タスク状態をより安定した画面に置けることです。コーディングAgentではこれが重要です。1つのコードタスクは、単なる一問一答ではないからです。多くの場合、次の流れを含みます。

プロジェクト構造を理解する。
関連ファイルを探す。
コードを変更する。
テストやコマンドを実行する。
エラーに基づいて修正を続ける。
変更内容をまとめる。

画面がログの羅列だけだと、ユーザーはAgentが今どこまで進んだのかを判断しにくくなります。TUIは少なくとも、観察し、必要なら引き継ぐための入口を提供します。

Autoモードは境界が明確なタスクに向く

DeepSeek-TUIが言及しているAutoモードは、境界が比較的明確な作業に向いています。たとえば小さなバグ修正、スクリプト追加、設定変更、文書整理、局所的な機能実装です。

こうしたタスクには共通点があります。目標が明確で、確認方法も明確で、影響範囲が制御できます。Agentは自分でファイルを調べ、編集し、コマンドを実行し、結果をユーザー確認に戻せます。

ただし、Autoモードは無制限の権限ではありません。実際のプロジェクトでは、ファイル削除、大規模リファクタリング、データベース移行、デプロイコマンドには明確な確認が必要です。コーディングAgentの効率は自動化から生まれますが、リスクも同じ場所から生まれます。コマンドを実行できるツールほど、サンドボックス、権限境界、人間によるレビューが必要です。

サブAgentの意味はタスク分割にある

サブAgentは新しい概念ではありませんが、コード作業では役に立ちます。

少し複雑なタスクでは、複数の種類の作業が同時に必要になります。コードを読む役、実装を変更する役、テストを確認する役、ドキュメントを整理する役です。従来のマルチAgentシステムが派手に見えるだけで終わりがちなのは、実際のツールやワークスペースを持たず、会話の中で相談しているだけだからです。

サブAgentがファイルシステム、コマンド実行、タスクキューと結びつけば、より現実的なタスク分割の仕組みになります。たとえば、あるサブAgentが依存関係を分析し、別のサブAgentが特定モジュールを変更し、メインAgentが結果を統合する、といった形です。これにより、1つのコンテキストに無関係な情報を詰め込みすぎる問題を減らせます。

もちろん、サブAgentには追加コストもあります。token消費、複雑な状態、追跡しにくい責任境界です。そのため、中程度以上の複雑さを持つタスクに向いており、すべての小さな修正に必要なものではありません。

1Mコンテキストは万能ではないが、プロジェクト理解には役立つ

1Mコンテキストは大げさに聞こえますが、コーディングでは単なる宣伝文句ではありません。

実際のコードベースのコンテキストは細かく分散しています。README、設定ファイル、型定義、テスト、呼び出しチェーン、過去の約束事、エラーログは、どれも1つの修正に影響します。長いコンテキストは、局所だけを見て手を動かす問題を減らし、モデルがより多くのプロジェクト制約を保持する助けになります。

ただし、コンテキストが長いことは判断が正しいことと同義ではありません。コードタスクには依然として検索、選別、検証が必要です。プロジェクト全体をコンテキストに詰め込むことが、関連ファイルを正確に読むことより良いとは限りません。良いコーディングAgentは、長いコンテキストをバッファとして使うべきであり、エンジニアリング判断の代替にすべきではありません。

向いているユーザー

DeepSeek-TUIは次のような人に向いています。

ターミナルでDeepSeekを使ってコード作業をしたい開発者。
ツール呼び出しやファイル操作の枠組みを自分で作りたくない人。
Claude CodeやCodex CLIに慣れており、DeepSeekモデルの入口も試したい人。
Web上のコード断片ではなく、ローカルプロジェクトのコンテキストが必要な人。
AIコーディングの流れをコマンドライン環境に入れたい人。

たまに関数の書き方を聞くだけなら、Webチャットで十分です。モデルに直接プロジェクト変更へ参加してほしいなら、ターミナルAgentの意味が大きくなります。

注意すべきリスク

この種のツールで特に注意すべきことは3つあります。

1つ目は権限です。ツールがファイルを読み書きし、コマンドを実行できるなら、デフォルトでどこにアクセスできるのか、ファイルを削除できるのか、ネットワークに出られるのか、危険なコマンドに確認が必要なのかを把握する必要があります。

2つ目はロールバックです。使う前にGitの作業ツリーをきれいにしておくと、Agentの変更を毎回 git diff で明確に確認できます。未コミットの変更が大量にある状態で、Agentに自動編集させるべきではありません。

3つ目は検証です。Agentがコードを書いたことは、タスク完了を意味しません。テスト、ビルド、lint、人間のreviewは残す必要があります。AIコーディングツールは進行を速めますが、最後のエンジニアリング確認を置き換えるものではありません。

まとめ

DeepSeek-TUIの意味は、また1つチャットクライアントが増えたことではありません。DeepSeek V4を、実際の開発作業に近いターミナル環境へ入れていることです。

開発者にとって、モデル能力は最初の一歩にすぎません。本当に体験を左右するのは、プロジェクトを読めるか、安全にファイルを変更できるか、検証コマンドを実行できるか、長いタスクで状態を保てるか、ユーザーがいつでも引き継げるかです。

DeepSeekを日常的なコード変更、プロジェクト読解、自動化された開発タスクに使いたいなら、DeepSeek-TUIは注目に値します。方向性も明確です。AIコーディングツールは「コードの質問に答える」段階から「プロジェクト実行に参加する」段階へ進んでいます。

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

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

Gemini 3.5 Pro が早くも流出：Google は Spark Agent で AI コーディングの入口を取り戻せるか

Fri, 15 May 2026 23:45:34 +0800

Gemini 3.5 Pro はまだ正式発表されていませんが、関連するリークはすでに盛り上がり始めています。

今回の情報で目立つキーワードは、Gemini 3.5 Pro、コードネーム Cappuccino、Gemini Spark、AI コーディング、MCP ツール接続です。これらが示す方向は一つです。Google は単にチャットモデルを更新したいのではなく、モデル、ツール、Agent、そして Google エコシステムの入口を再び結び直そうとしています。

ただし、正式発表前の情報はあくまで「リーク」として見るべきです。本当に注目すべきなのは、1 枚のスクリーンショットや 1 つのスコアではなく、Google が次にどの弱点を補おうとしているかです。

Gemini 3.5 Pro が注目される理由

公開された情報を見る限り、Gemini 3.5 Pro は命名上のジャンプになる可能性があります。

少し前までは Gemini 3.2 が話題になっていましたが、その後 Gemini 3.5 Pro という名称が出てきました。もしこの命名が本当なら、Google は次のリリースで通常の小さな更新ではなく、より大きなバージョンストーリーを語ろうとしていることになります。

現時点で流れている重点は主に 3 つです。

コーディングと推論能力の継続的な改善。
SVG、インタラクティブページ、アニメーション、3D 生成能力の強化。
新しい Agent 製品 Gemini Spark が前面に出る可能性。

これらの方向性自体は意外ではありません。Gemini シリーズは以前からマルチモーダルを重視しており、Google には強力な配布チャネルもあります。問題は、開発者ツールと Agent ワークフローで OpenAI や Anthropic のペースに追いつけるかどうかです。

コーディング能力は Google が最も補うべき課題

2026 年に入ってから、大規模モデル競争におけるコーディングは、単なる「モデル能力テスト項目」ではなくなりました。最も直接的なプロダクト入口の一つになっています。

理由は単純です。AI コーディングツールは利用頻度が高く、大量のフィードバックデータを生みます。開発者は毎日、モデルにコードを読ませ、修正させ、テストを走らせ、バグを直させています。こうしたやり取りは、次世代モデルとツールチェーンの進化を自然に押し進めます。

この 1 年で Claude Code は開発者の間で強い存在感を得ました。OpenAI も Codex と ChatGPT の連携を継続的に強化しています。一方で Google には Antigravity などの製品がありますが、外部での存在感はそれほど強くありません。

だからこそ Gemini 3.5 Pro は注目されています。もしチャットが少し上手くなり、回答が少し速くなるだけなら、意味は限定的です。コード理解、複数ファイル編集、ツール呼び出し、長時間タスク実行が本当に改善されるなら、開発者のワークフローを変える可能性があります。

Gemini Spark はより大きな変数かもしれない

モデルそのものより攻めているのが、噂されている Gemini Spark です。

リークによれば、Spark は通常のチャットアシスタントではなく、常時稼働する AI Agent として位置づけられています。メール、カレンダー、Web ページ、タスク、アカウント状態、個人コンテキストに接続し、複数ステップのワークフローを処理する可能性があります。

このタイプの製品には大きな可能性があります。たとえば次のような使い方です。

受信箱を自動整理する。
ユーザーのタスクをフォローする。
Web ページ上で操作を実行する。
アプリをまたいだ流れを処理する。
個人の好みに基づいて日常タスクを調整する。

ただしリスクも同じくらい明確です。常時稼働する Agent がログイン状態、ブラウザデータ、ファイル、位置情報、サードパーティサービスにアクセスできるなら、いくつかの問いに答える必要があります。どの操作でユーザー確認が必要なのか。自動実行を禁止すべき操作は何か。データは第三者に共有されるのか。リモートブラウザと認証情報はどう隔離されるのか。

つまり Spark の本当の見どころは、「作業を代行できるか」だけではありません。Google が権限、監査、確認フロー、ユーザー制御を十分に明確にできるかどうかです。

MCP ツール接続が示すもの

リークでは、新しい Gemini のモデル選択画面に MCP 関連モデルやテスト入口が出る可能性も触れられています。

もしこれが実装されるなら、Google もモデルを「質問応答システム」から「ツール操作システム」へ進めていることになります。モデルは単にテキストを生成するだけではなく、外部ツールを呼び、業務システムにアクセスし、ファイルを読み書きし、コマンドを実行し、複数ステップにわたってタスク状態を保つ必要があります。

これは OpenAI や Anthropic と同じ方向です。ツール呼び出しをより安定させられる企業ほど、AI を現実のワークフローに組み込みやすくなります。

ただし MCP 接続そのものがゴールではありません。本当に難しいのは安定性です。

モデルは正しいツールを選べるか。
パラメータは信頼できるか。
失敗後に復旧できるか。
権限境界は明確か。
ユーザーは各ステップを追跡できるか。

これらが解決されないままツールだけが増えると、失敗の表面積も広がります。

マルチモーダルは依然として Google の強いカード

Google が差別化しやすい領域は、やはりマルチモーダルです。

流出した SVG、インタラクティブページ、アニメーション、視覚生成の例を見ると、Gemini は「プロンプトから操作可能なコンテンツを生成する」能力をさらに強化する可能性があります。単にコードを書くよりも、これはプロダクトプロトタイピングに近いものです。ユーザーがアイデアを説明すると、モデルが操作可能で調整でき、プレビューできる画面を直接出すという流れです。

この路線は Google に合っています。Gemini のマルチモーダル能力を活かせるだけでなく、Android、Chrome、Workspace、検索、広告、クラウドサービスなどの入口とも結びつけられます。

Google が「どのコードモデルが一番強いか」だけの勝負を避けたいなら、より完全なマルチモーダル Agent システムへ重点を置く可能性があります。

3 社の戦い方は分かれ始めている

現在の大規模モデル競争は、単一のランキング競争ではありません。

OpenAI の強みは、プロダクト反復と配布速度です。Codex、ChatGPT、企業向けツール、API の連携はますます強くなっています。

Anthropic の強みは、開発者の認知とコードモデル品質です。Claude Code はすでに多くの人にとって標準の AI コーディング入口になっています。

Google の強みはエコシステム入口です。Gmail、Docs、Chrome、Android、検索、YouTube、Maps、クラウドサービスは、巨大な個人・企業データネットワークを形成しています。Agent がこれらの入口に安全に接続できれば、Google は「モデルの追随者」から「ワークフロー入口の支配者」へ移れる可能性があります。

だからこそ Gemini Spark は注目に値します。すべてのベンチマークで 1 位になる必要はありません。日常のワークフローに入り込めれば、独自の堀を作れる可能性があります。

一般ユーザーはどう見るべきか

一般ユーザーにとっては、短期的にすべてのリークに振り回される必要はありません。

より実用的な観察点は 3 つです。

Gemini 3.5 Pro のコーディング能力が本当に改善されるか。特に複雑なリポジトリ、長いコンテキスト、ツール呼び出し。
Gemini Spark がデフォルトで安全か。機密操作の前に明確な確認と追跡可能な記録があるか。
Google が価格、クォータ、企業向け権限管理を明確に示すか。デモだけで終わらないか。

きれいなスクリーンショットを数枚生成するだけなら価値は限定的です。現実のワークフローへ安定して接続できるかどうかが、この世代の AI Agent 製品の分岐点になります。

開発者にとっての意味

開発者が最も気にするべきなのは、「どのモデルが勝ったか」ではなく、自分のワークフローが移行可能かどうかです。

Claude Code、Codex、Gemini、Antigravity、Cursor、Windsurf など、多くのツールが入口を奪い合っています。すべての作業を 1 つのプラットフォームに固定すると、将来コスト、クォータ、モデル方針、権限ルールが変わったときに移行がつらくなります。

より堅実なやり方は次の通りです。

重要なプロジェクトでは標準的な Git ワークフローを維持する。
自動編集後は必ず diff を確認する。
重要なタスクはテストと CI で支える。
本番用の認証情報を不透明な Agent に渡さない。
オープンなプロトコルでツール接続できる場合は、置き換え可能な選択肢を優先する。

モデルはこれからも強くなりますが、エンジニアリングの規律は古くなりません。

まとめ

Gemini 3.5 Pro のリークは、Google が AI コーディングと Agent の入口を急いで補強していることを示しています。モデル性能の向上はその一部であり、Gemini Spark のような常時稼働 Agent こそ、より大きな戦略的動きかもしれません。

ただし、ユーザーの代わりに「自動で作業する」システムほど、厳格な権限境界と検証可能なワークフローが必要です。Google にとって本当の課題は、GPT-5.5 や Claude に追いつくことだけではありません。強いモデル、安全機構、エコシステム入口を、信頼できる日常ワークフローとして組み合わせることです。

それが実現できれば、Gemini はすべてのランキングで 1 位にならなくても、AI の入口における主導権を一部取り戻せるかもしれません。

OpenHuman 速読：オープンソース個人 AI Agent のデスクトップ路線

Fri, 15 May 2026 14:52:31 +0800

OpenHuman は tinyhumansai が公開しているオープンソースの個人向け AI Agent プロジェクトだ。目的は単なるチャットウィンドウをもう一つ作ることではない。デスクトップアプリ、個人の記憶、サードパーティ連携、音声、コーディングツール、ローカルナレッジベースを同じ agent harness に入れ、AI が日常の作業コンテキストをより速く理解できるようにすることにある。

プロジェクト README では “Personal AI super intelligence” と位置づけられ、公式サイトでも private、simple、extremely powerful が強調されている。この表現はかなり野心的だが、分解して見る方がわかりやすい。OpenHuman で本当に注目すべきなのは、「個人のコンテキスト」を製品の中心に置こうとしている点であり、モデル呼び出し、プラグイン設定、ドキュメント検索をユーザー自身の組み合わせ作業に任せないところだ。

この記事を確認した時点で、GitHub リポジトリは約 7.8k stars、629 forks だった。最新 release は OpenHuman v0.53.43 で、日付は 2026 年 5 月 13 日。プロジェクトはまだ Early Beta で、README でも活発に開発中だと明記されているため、粗い部分がある前提で見るべきだ。

何を解決しようとしているのか

多くの AI アシスタントの問題は、モデルが弱いことではなく、コンテキストが冷たいことにある。毎回、プロジェクト背景、最近のメール、予定、コードリポジトリ、文書、タスク、好みを説明し直さなければならない。Gmail、Notion、GitHub、Slack、Calendar、Drive、Linear、Jira などをまたぐと、情報はさらに別々のツールへ散らばってしまう。

OpenHuman の考え方は、まずこれらのデータを接続し、その後で自動取得、圧縮、要約、ローカルナレッジベースを通じて、継続的に更新できる個人記憶レイヤーを作ることだ。これにより agent は現在の会話だけを覚えるのではなく、ユーザーのワークフローを中心に長期コンテキストを形成できる。

これが通常のチャットボットとの最大の違いでもある。チャットボットは多くの場合 prompt を中心に動く。OpenHuman はむしろ、デスクトップ上の個人向け OS 入口に近く、コネクター、記憶、ツール、モデルルーティングをあらかじめまとめて提供しようとしている。

主な機能

OpenHuman README に挙げられている中核機能は次の通り。

デスクトップ優先の UI と短いオンボーディング経路。ユーザーが最初からターミナル設定を始める必要はない。
「顔」を持つデスクトップ mascot。話したり、環境に反応したり、Google Meet に参加したりできる。
Gmail、Notion、GitHub、Slack、Stripe、Calendar、Drive、Linear、Jira などを含む 118+ のサードパーティ連携。
自動取得機構。プロジェクト説明では、20 分ごとにアクティブな接続を巡回し、新しいデータを memory tree に取り込むとされている。
Memory Tree：接続データと活動情報を Markdown ブロックへ圧縮し、ローカル SQLite に保存する。
Obsidian-compatible vault：知識ブロックを .md ファイルとして書き出し、ユーザーが Obsidian で開いて閲覧、編集できる。
内蔵検索、Web 取得、コーディングツール、ファイルシステム、git、lint、test、grep、音声入出力などの機能。
Model routing：タスクに応じてリクエストを異なるモデルタイプへルーティングする。
TokenJuice：ツール結果、Web 取得、メール本文、検索結果が LLM に入る前に token 圧縮を行う。
ローカル AI ワークロード向けの Ollama を任意で利用できる。

機能は多く見えるが、実際の焦点は二つにまとめられる。一つは設定やプラグインの組み合わせ作業を減らすこと。もう一つは、個人データを agent が検索でき、圧縮でき、継続的に更新できる記憶へ変えることだ。

インストール方法

プロジェクトは Web サイト上のダウンロード入口に加え、ターミナル用のインストールコマンドも提供している。

macOS または Linux x64：

`1`	`curl -fsSL https://raw.githubusercontent.com/tinyhumansai/openhuman/main/scripts/install.sh \| bash`

Windows：

`1`	`irm https://raw.githubusercontent.com/tinyhumansai/openhuman/main/scripts/install.ps1 \| iex`

日常的に使うメインマシンなら、まず公式サイトからインストーラーをダウンロードするか、少なくともインストールスクリプトを開いて内容を確認してから、リモートスクリプトを直接実行するか決めたい。OpenHuman はメール、文書、コードリポジトリ、カレンダー、ローカルファイル権限に関わるため、インストールと認可は普通の小さなツールより慎重に扱うべきだ。

オープンソースと技術スタック

OpenHuman リポジトリは GPL-3.0 license を採用している。言語構成では Rust が中心で、次に TypeScript が多く、JavaScript、Shell、CSS、PowerShell も含まれる。README のコントリビューション説明では、Node.js 24+、pnpm 10.10.0、Rust 1.93.0、CMake、さらに各プラットフォームのデスクトップビルド依存関係が求められている。

ローカル開発のおおまかな流れは次の通り。

git submodule update --init --recursive
pnpm install
pnpm dev
pnpm --filter openhuman-app dev:app

提出前には focused checks の実行が推奨されている。例えば次のようなものだ。

1
2
3

pnpm typecheck
pnpm format:check
cargo check -p openhuman --lib

ディレクトリ構造を見る限り、これは軽量なスクリプトプロジェクトではない。デスクトップアプリ、フロントエンド、Rust バックエンド、ドキュメント、テスト、サンプル、ビルドスクリプトを含む、製品型のリポジトリだ。

Memory Tree と Obsidian vault が重要な理由

OpenHuman で単独で見る価値が高い概念は Memory Tree だ。README によると、接続されたデータは約 3k token 以下の Markdown chunks に標準化され、スコアリングされた後、階層的な要約ツリーへ折り込まれ、ローカル SQLite に保存される。同じ内容は Obsidian 互換 vault にも入る。

この路線にはいくつか利点がある。

ユーザーは agent の知識ベースを直接見られ、ブラックボックスな記憶を信じるだけで済まない。
Markdown ファイルは検索、バックアップ、バージョン管理、手動修正がしやすい。
SQLite はローカルインデックスと高速検索に向いている。
階層的な要約は、平坦な文書の山より長期コンテキスト圧縮に向いている。

ただし現実的な課題もある。データ同期が安定するか、要約が重要な細部を落とさないか、権限境界が十分明確か、削除と取り消しが完全か、異なるコネクターの意味を一貫して扱えるか。これらは README の “remembers everything” という一文だけで解決できるものではなく、長期利用と監査が必要になる。

TokenJuice：コストとレイテンシの中間層

OpenHuman は TokenJuice も強調している。役割は、Web ページ、メール、検索結果、ツール呼び出し結果がモデルへ入る前に圧縮することだ。例えば HTML を Markdown に変換する、長い URL を短縮する、一部の不要な文字を取り除く、といった処理が含まれる。README では、これによりコストとレイテンシを減らし、最大 80% の token 使用量削減が可能だと説明されている。

この方向性は妥当だ。Agent システムで本当に費用がかかる部分は、一回のチャットではなく、バックグラウンド取得、ツール呼び出し、検索、Web 解析、長いコンテキスト注入であることが多い。データを先に整理してからモデルへ渡す方が、元データをそのまま詰め込むより安定しやすい。

ただし圧縮層は新しい問題も生む。どの情報を残し、どの情報を捨てるかを決めるからだ。契約書、請求書、医療記録、コンプライアンス資料、本番障害ログを扱うなら、token 節約だけを見るわけにはいかない。追跡可能性、原文確認、圧縮誤差も見る必要がある。

プライバシー：売りでもあり監査ポイントでもある

OpenHuman の売りの一つは private であることだ。公式サイトではローカル AI モデルが低レベルのタスクを処理できると説明され、README でも workflow data stays on device、encrypted locally、treated as yours が強調されている。

この設計方向は魅力的だ。個人 AI Agent が Gmail、Drive、Calendar、Slack、GitHub に接続した瞬間、もっとも機密性の高い仕事データに触れることになる。完全なクラウド型アシスタントと比べると、ローカル優先の記憶レイヤーと見える Markdown vault は、少なくともユーザーにより強い制御感を与える。

ただし全体像も見る必要がある。OpenHuman は同時に one subscription、30+ providers、model routing、ElevenLabs TTS、OAuth integrations などの機能にも触れている。つまり、純粋なオフラインツールではない。プライバシーを本当に評価するには、各コネクター、各種モデル呼び出し、音声や検索機能がそれぞれ何のデータをどこへ送るのかを確認しなければならない。

誰が注目すべきか

現時点の OpenHuman は、次の三種類の人に向いている。

単機能のチャットボットではなく、個人 AI の操作台がほしいユーザー。
Early Beta を試す意欲があり、機能変化や粗い部分を受け入れられる開発者。
ローカル記憶、Obsidian ワークフロー、agent connector、コンテキスト圧縮に関心がある人。

安定して軽量で、プライバシー境界が非常に単純なオフラインアシスタントだけを探しているなら、現時点では重すぎるかもしれない。次世代の個人 AI Agent がデスクトップ、コネクター、記憶、ツールをどう統合するかを研究したいなら、OpenHuman は追いかける価値のあるオープンソースサンプルだ。

私の提案は、まずこれを「製品型オープンソース実験」として観察することだ。release のリズム、issue の品質、コネクター権限、データエクスポート機能、削除機構、ローカル vault の可読性を見る。個人 AI の鍵は、質問に答えられるかだけではない。長期的に、透明で、制御可能な形で自分のコンテキストを背負えるかどうかだ。

参考リンク

Token Efficiency とは何か：DeepSeek V4 から見る大モデルの計画と小モデルの実行

Fri, 15 May 2026 08:59:33 +0800

AI コーディングで次に重要になる指標は、最強モデルを使うことではなく、より少ない token、低いコスト、安定したプロセスで、より多くの検証可能な仕事を終えることかもしれない。

それが Token Efficiency の価値だ。

多くの人は Token Efficiency を、安いモデル、長いコンテキスト、安い cache hit と考える。しかしそれは基礎条件にすぎない。本当に生産性に変えるのは、モデルの役割分担、タスク編成、コンテキスト予算、評価体系だ。

DeepSeek V4 の位置づけ

DeepSeek V4 は単に強いモデルを出しただけではない。Token Efficiency に必要な二つの能力を V4 Pro と V4 Flash に分けた。

V4 Pro は計画、推論、アーキテクチャ判断、重要レビューに向く。V4 Flash は高頻度実行、バッチ書き換え、コード補完、資料整理、agent ループ内の通常ノードに向く。

AI コーディングでは次のように使える。

V4 Pro: planner / consultant。要件分解、技術設計、複雑な bug 分析、アーキテクチャレビュー、最終受け入れ。
V4 Flash: executor。ファイル走査、単純実装、テスト補完、文書整理、候補生成、反復タスク。

DeepSeek の API 文書では、V4 Flash と V4 Pro はどちらも 1M context、JSON Output、Tool Calls、Chat Prefix Completion、FIM Completion をサポートする。価格ページでは cache hit input が別価格で、input cache hit 価格が公開時の 10 分の 1 になったことも示されている。

1M context は複雑な agent タスクの圧縮問題を減らす。低い cache hit 価格は、長い system prompt、プロジェクト文書、コード片、履歴を繰り返し入れるコストを下げる。Flash / Pro の分離は、全ステップを高価なモデルで走らせるか、不安定な小モデルだけで走らせるか、という二択を避ける。

DeepSeek V4 の意味は、別のモデル選択肢ではなく、「consultant model + executor model + harness orchestration」の現実的なコスト構造を提供することにある。

最強モデルにすべてをさせない

従来は最も賢いモデルに、要件分析、実装、テスト、まとめを全部任せがちだった。

しかし多くの作業は最高レベルの推論を必要としない。高価なモデルは、重要な判断点だけに出る consultant、architect、planner のように使うべきだ。

大モデルは問題分解と重要判断。
小モデルは実行、バッチ処理、反復修正。
tool と harness はプロセス、状態、コンテキスト、検証。
人間は製品定義、受け入れ、取捨選択。

これで最先端推論を機械的な実行に浪費しにくくなる。

コンテキストは大きければよいわけではない

coding agent では、コード、文書、会話履歴、テスト出力、ログがコンテキストを消費する。上限に近づくと圧縮、忘却、誤判断が起きやすい。

しかし長いコンテキストは、すべてを詰め込んでよいという意味ではない。

各タスクは、必要ファイル、判断に関係する文書、現在段階に必要な履歴、明確な入出力、次ノードへ渡す構造化要約だけを持つべきだ。

安い context は無関係な情報を入れたくさせる。だがノイズはモデルを賢くしない。

Harness が単体モデルより重要

Claude Code、Codex、その他の coding agent を安いモデルにつなぐだけでは十分ではない。小モデルは長いタスクでずれやすく、強いプロセス制御が必要だ。

harness は調度システムであり、タスク分割、ノード実行、モデル選択、結果検証、失敗時の再試行、コンテキスト受け渡しを決める。

この層がなければ、小モデルは安いだけだ。この層があると、小モデルはレバレッジになる。

DAG でタスクを分ける

複雑なタスクは DAG に分けられる。たとえば機能開発は、要件確認、技術設計、タスク分解、実装、テスト補完、Code Review、修正、PR 提出にできる。

各ノードは独立した agent にできる。役割、prompt、tool 権限、出力形式を分け、長い会話ではなく構造化結果を渡す。

これによりノードは短くなり、小モデルで完了しやすくなり、どこが失敗しているかも測りやすくなる。

タスクは複数回走らせてもよい

token が十分安ければ、同じタスクを一度だけ走らせる必要はない。異なるモデル、prompt、編成で複数回走らせ、最良の結果を選ぶ、または有用部分を統合できる。

向いているのは設計案、文章、テストケース、bug 仮説、リファクタリング案、Code Review だ。共有状態を変える作業や外部副作用がある作業には向かない。

目的は運試しではなく、比較可能なサンプルを得て、編成とモデル選択を改善することだ。

評価体系が必要

Token Efficiency は価格だけでは測れない。安くても失敗率が高ければ、人間の時間を食って高くつく。

タスク完了率、人間の介入回数、tool call 失敗率、テスト通過率、review 指摘数、タスクごとの token コスト、時間、手戻り回数、モデル組み合わせの差を記録する。

このデータがあって初めて、小モデルでよい作業、大モデルが必要な作業、人間が判断すべき作業を分けられる。

業務フローを原子化する

全員が harness を自作する必要はない。しかし自分の業務を原子ノードに分解することは今からできる。

コンテンツ制作なら、企画、調査、アウトライン、初稿、ファクトチェック、スタイル調整、SEO タイトル、多言語翻訳、公開チェック。

ソフトウェア開発なら、要件確認、技術設計、データ構造、API 変更、単体テスト、実装、移行スクリプト、文書、Review。

各ノードは入力、出力、受け入れ条件、コンテキストを明確にする。harness が成熟すれば、そのまま接続できる。

ハードウェアは最優先ではない

Token Efficiency の話はすぐローカルデプロイや GPU に向かう。しかし多くの人にとって最初の選択は API でよい。

経済モデルが通る前に高価なハードを買うのは、コストの前払いにすぎない。まず API で workflow を通し、評価とコストを記録し、高頻度の実行ノードを見つけてから、ローカル化を検討すべきだ。

まとめ

Token Efficiency の本質は、高いモデルを安いモデルで置き換えることではない。AI workflow を設計し直すことだ。

大モデルが重要判断をし、小モデルが大量実行し、harness が調度と検証を行い、人間が目標と受け入れを決める。この四層が揃って初めて token は生産性に変わる。

将来の差は、最強モデルを呼んだかではなく、同じ token でどれだけ現実の成果を出せるかに現れる。

Superpowers：Coding Agent を工学プロセスへ戻す skills フレームワーク

Fri, 15 May 2026 08:53:17 +0800

obra/superpowers は coding agent 向けの skills フレームワークであり、ソフトウェア開発方法論でもある。目的は万能 prompt を増やすことではなく、agent に流れを守らせることだ。目標を確認し、設計を作り、計画に分解し、TDD で実装し、レビューして終える。

プロジェクト：https://github.com/obra/superpowers

執筆時点で GitHub API では 19 万 star を超え、MIT ライセンスで、最近も更新されている。README は An agentic skills framework & software development methodology that works. と説明している。

解決したい問題

多くの AI コーディングツールの問題は、コードを書けないことではなく、すぐコードを書き始めることだ。

ユーザーが曖昧な要望を言うと、agent はファイルを編集し、見た目は完成する。しかし境界、テスト、アーキテクチャは不明確なまま残る。小さな作業ならよいが、複雑なプロジェクトでは手戻りと技術的負債になる。

Superpowers は、コードに触る前に agent を workflow に入れる。

何かを作りたいと分かったら、まず目標を質問する。
会話を仕様にし、区切って確認する。
設計が通ったら、実装計画を作る。
ユーザーが “go” と言ってから実装する。
実装では TDD、YAGNI、DRY、レビューを重視する。

これは新しい工学ではない。速い agent ほど、こうしたガードレールが重要になる。

対応ツール

Superpowers は単一の agent に縛られない。README には Claude Code、Codex CLI、Codex App、Factory Droid、Gemini CLI、OpenCode、Cursor、GitHub Copilot CLI が挙げられている。

つまり特定モデルのテクニックではなく、複数の harness で使える workflow 層に近い。

基本 workflow

最初は brainstorming。実装前に粗いアイデアを実行可能な設計へ変え、ユーザーに確認する。

次に using-git-worktrees。設計後、隔離された worktree とブランチを作り、インストールとテストの基線を確認する。

次は writing-plans。設計を小さなタスクに分け、ファイルパス、変更範囲、検証手順を明確にする。

実装段階では subagent-driven-development で subagent に渡すことも、executing-plans で順に実行することもできる。重要なのは各タスクが確認可能で review 可能なことだ。

その後 test-driven-development によって、本当の RED-GREEN-REFACTOR を行う。失敗するテストを書き、失敗を確認し、最小実装で通し、リファクタリングする。

さらに requesting-code-review でタスク間の review を行う。Critical な問題は進行を止める。

最後に finishing-a-development-branch でテストを確認し、merge、PR、worktree の保持や破棄を選ぶ。

Skills Library

テスト系は test-driven-development が中心だ。

デバッグ系には systematic-debugging と verification-before-completion がある。再現、最小化、仮説、検証、修正を求め、検証なしに完了と言わない。

協調系には次がある。

brainstorming
writing-plans
executing-plans
dispatching-parallel-agents
requesting-code-review
receiving-code-review
using-git-worktrees
finishing-a-development-branch
subagent-driven-development

メタ skills には writing-skills と using-superpowers がある。組み合わせると、agent に「いつ質問し、いつ計画し、いつテストし、いつ止まって review するか」という習慣を与える。

普通の prompt との違い

普通の prompt は、ルールを system prompt に積み上げがちだ。勝手に変更するな、先に考えろ、テストしろ、簡潔に説明しろ。ルールが増えるほど、複雑なタスクでは忘れられやすい。

Superpowers はルールを段階ごとの workflow モジュールに分ける。各 skill は短く、目的が集中している。agent は今の段階で何をすべきかを理解しやすく、複雑な流れも検査しやすい。

学べる点は、賢いモデルだけを追うのではなく、モデルに繰り返し可能な働き方を与えることだ。

向いている場面

Superpowers は、実プロジェクトで coding agent を使う開発者に向いている。複数ファイルの変更、設計してから実装したい場合、TDD や検証が必要な場合、複数ブランチや worktree を扱う場合、subagent に実装や review を任せたい場合に特に有効だ。

一行の設定変更には重いかもしれない。しかし多段階の開発では、その制約が価値になる。

注意点

これは自動操縦ではない。プロセスは与えるが、要求、トレードオフ、最終受け入れは人間が持つ。

TDD と review は初期コストを増やす。小タスクでは遅く感じるが、複雑なタスクでは手戻りを減らす。

subagent の並列化は常に良いわけではない。境界と書き込み範囲が明確なときに効く。要件が曖昧なら、並列化は混乱を増やす。

まとめ

Superpowers の価値は、coding agent を「依頼を受けたらコードを書く」状態から、ソフトウェア工学プロセスへ戻すことにある。

AI コーディングに足りないのは生成速度ではなく、確認、計画、検証、review、終了処理であることが多い。モデルが強くなるほど、これらを省いてはいけない。

Codex、Claude Code、Cursor、Gemini CLI を実プロジェクトで使っているなら、Superpowers は調べる価値がある。直接使わなくても、skills の分け方は自分の agent workflow を設計する参考になる。

Codex /goal vs Claude Code /goal：長いタスクを完了条件まで自動で進める

Thu, 14 May 2026 22:25:31 +0800

/goal は、AI コーディングツールにおける重要なコマンドになりつつあります。

これは「モデルにもう少しコードを書かせる」ためのものではありません。より実用的な問題、つまりタスクに明確な完了条件があるとき、毎ターン止まってユーザーの「続けて」を待つのではなく、Agent が条件を満たすまで進み続けられるか、という問題を扱います。

Codex CLI はすでに公式ドキュメントで実験的な /goal を追加しています。Claude Code も独自の /goal ドキュメントを公開し、複数ターンにまたがって作業を続けられる自動化機能として説明しています。名前は同じですが、プロダクトとしての方向性は完全には同じではありません。

`/goal` は何を解決するのか

通常の AI コーディング対話は、だいたい「一問一答」です。

ユーザーがタスクを出す。
Agent が分析し、コードを変更し、テストを実行する。
Agent が結果を報告する。
ユーザーが次の行動を決める。

この流れは短いタスクには向いています。しかし移行、リファクタリング、テスト修正、issue backlog の整理になると、かなり細切れになります。Agent は少しだけ進めて、また「続けて」と入力されるのを待つことがあります。

/goal の考え方は、タスクを「次に何をするか」ではなく「最終的にどんな状態なら完了か」に変えることです。たとえば：

`1`	`/goal 完成登录模块迁移，所有 auth 测试通过，lint 无报错`

この種の目標は長いタスクに向いています。テストが通る、ビルドが成功する、ファイル分割が終わる、キューが空になる、受け入れ条件を満たす、といった明確な終点があるからです。

Codex の `/goal`：実験機能で、現在のスレッドに紐づく

OpenAI の Codex CLI ドキュメントでは、/goal は実験機能として扱われています。デフォルトの安定機能ではなく、先に features.goals を有効にする必要があります。

有効化する方法は 2 つあります。

`1`	`/experimental`

または config.toml に追加します。

1
2

[features]
goals = true

有効化後は、次のように使えます。

`1`	`/goal Finish the migration and keep tests green`

よく使うコマンドは次の通りです。

/goal
/goal pause
/goal resume
/goal clear

OpenAI のドキュメントによると、Codex は goal を現在の active thread に付与し、より大きなタスクの進行中にその目標を追跡します。

ここで重要なのは、Codex /goal に対する公式ドキュメントの表現がかなり抑制的であることです。「長いタスクに実験的な目標を設定する」「現在のスレッドに目標を付与する」と説明していますが、Claude Code のドキュメントのように、各ターンの終了後に独立した evaluator が自動判定して次のターンへ進む、という説明まではしていません。そのため現時点では、Codex /goal は完全に安定した無人実行モードではなく、実験中の長期タスク向け目標メカニズムとして見るのがよさそうです。

Claude Code の `/goal`：完了条件で駆動する複数ターン実行

Claude Code の /goal ドキュメントはより明確です。ユーザーが completion condition を設定すると、Claude はその条件が満たされるまで複数ターンにわたって作業を続けます。

例：

`1`	`/goal all tests in test/auth pass and the lint step is clean`

Claude Code の仕組みは、おおまかに次のようなものです。

現在の turn が終わっても、すぐに制御をユーザーへ戻さない。
小さく高速なモデルが、目標条件がすでに満たされたかを確認する。
満たされていなければ、Claude が自動で次のターンを開始する。
満たされていれば、goal は自動で解除され、transcript に完了状態が記録される。

つまり Claude Code の /goal は、「完了条件を満たすまで自動で続ける」機能に近いものです。単に会話へ目標を貼り付けるだけではなく、「次のターンへ進むかどうか」を独立した評価ステップに任せています。

Claude Code では、状態を直接確認することもできます。

/goal

状態には、目標条件、実行時間、評価済み turn 数、token 消費量、evaluator が最後に出した理由が表示されます。

途中で止めたい場合は、次を使います。

`1`	`/goal clear`

stop、off、reset、none、cancel も解除用の別名として使えます。目標を有効にした後でセッションが中断された場合でも、--resume や --continue で再開すると、active な goal を復元できます。ただし、経過時間、turn 数、token の基準値は再計算されます。

最大の違い

Codex と Claude Code はどちらも、AI コーディングを「単発の回答」から「長いタスクの実行」へ押し出しています。ただし /goal の位置づけには違いがあります。

比較項目	Codex CLI `/goal`	Claude Code `/goal`
状態	experimental	公式ドキュメントで単独ページとして説明
有効化	`features.goals` を有効化する必要がある	信頼済み workspace で直接利用可能
目標のスコープ	現在の active thread	現在の session
主な操作	set / view / pause / resume / clear	set / view / clear
自動判定	ドキュメントは目標の付与と追跡を強調	各ターン後に evaluator が判定すると明記
自動継続	公式表現は控えめ	条件未達なら自動で次のターンへ進む
向いている場面	Codex の長いタスクで目標コンテキストを維持したい場合	完了条件に向けて Claude Code に継続実行させたい場合

簡単に言えば、Codex の /goal は「現在のスレッドに実験的な長期目標を付ける」ものに近いです。Claude Code の /goal は「現在のセッションに検証可能な停止条件を設定し、満たされるまで自動で進める」ものに近いです。

よい `/goal` の書き方

どちらのツールでも、/goal は曖昧な願望を書く場所ではありません。

あまりよくない例：

`1`	`/goal 把项目优化一下`

よりよい例：

`1`	`/goal 将 payment 模块迁移到新 API，npm test -- payment 退出码为 0，git diff 只包含 payment 相关文件`

よい目標には通常、次の 3 つが含まれます。

明確な完了状態。
実行可能な検証方法。
守るべき境界。

目標が大きい場合は、停止条件も加えるべきです。

`1`	`/goal 修复 eslint 报错，npm run lint 退出码为 0；如果超过 20 轮仍未完成，停止并总结剩余问题`

これは重要です。/goal が強力になるほど、境界が必要になります。そうしないと Agent は「完了」を追い求めて、過剰にファイルを変更したり、長く走りすぎたり、token を使いすぎたり、本来なら質問すべき問題をそのまま進めてしまう可能性があります。

`/goal` が向いている場面

向いているもの：

テスト修正：指定したテストが通るまで。
コード移行：すべての呼び出し箇所を変更し、コンパイルが成功するまで。
一括整理：特定の lint や型エラーがゼロになるまで。
ドキュメント補完：指定したすべてのモジュールに説明が付くまで。
issue キュー処理：特定タグの issue が処理済み、または明確に分類されるまで。

向いていないもの：

要件自体がまだ曖昧。
頻繁なプロダクト判断が必要。
高リスクな削除、データ移行、権限変更を含む。
受け入れ条件が主観でしか判断できない。
大量の無関係なモジュールをまたぐ。

実用的な基準は、「どのコマンドを実行し、どんな結果を確認し、どのファイルに触れてはいけないか」を書けるなら /goal に向いている、ということです。「もっとよくして」としか書けないなら、通常の対話、計画モード、人間のレビューを使うほうが安全です。

AI コーディングツールへの影響

/goal は明確な方向性を示しています。AI コーディングツールは「対話型アシスタント」から「継続実行できる作業単位」へ移りつつあります。

以前は、Agent にタスクを任せるとき、ユーザーが近くで見守る必要がありました。詰まったら促し、テストが終わったら続行させ、エラーが出たらまた命令する。/goal はこのやり取りを完了条件に圧縮し、次のターンで何をするかを Agent 自身に決めさせます。

ただし、これはユーザー側への要求も高めます。これからの prompt はタスクを説明するだけでなく、受け入れ条件、検証コマンド、変更範囲、停止ルールも書く必要があります。言い換えると、ユーザーの仕事は「続けてと促す」ことから「何をもって完了とするかを定義する」ことへ移ります。

Codex と Claude Code が /goal に到達したということは、長いタスクを扱う Agent が、もはやバックグラウンドタスクやクラウドキューだけのものではないということです。ターミナル上のローカルなコーディングツールにも、より強い自律的な進行能力が求められ始めています。

まとめ

Codex CLI と Claude Code はどちらも /goal を持っていますが、現時点では同じ機能として単純に扱わないほうがよいです。

Codex の /goal はまだ実験機能で、features.goals を有効にする必要があり、現在の Codex スレッドで長期目標を維持する仕組みとして見るのが自然です。Claude Code の /goal は、「完了条件」と「自動継続」をより明確に結びつけ、独立した evaluator によって続行可否を判断します。

日常開発では、この種のコマンドは明確な受け入れ基準を持つエンジニアリングタスクに向いています。要件判断やコードレビューを置き換えるものではありませんが、長いタスクにありがちな「続けて」「もう一度実行して」「テストが通るまで直して」という繰り返しを減らせます。

本当に身につけるべきなのは、コマンドそのものではありません。タスクを、明確で、検証可能で、停止できる目標として書く力です。

参考資料

OpenAI Codex CLI Slash Commands：https://developers.openai.com/codex/cli/slash-commands
Claude Code Goal ドキュメント：https://code.claude.com/docs/en/goal

AI コーディングツールの今回の波で、なぜ DeepSeek がコスト削減の鍵になったのか

Mon, 11 May 2026 04:59:00 +0800

今回の AI コーディングツール競争は、表面上はモデル性能、プラグインエコシステム、agent 自動化の競争に見える。しかし実際に使い始めると、最初にぶつかる問題はコストだ。

Claude Code、Codex、OpenClaw、Superpowers はどれも便利だが、共通点がある。複雑なタスクに入ると、とにかく token を消費する。プロジェクトを読み、計画を作り、ツールを呼び出し、コンテキストを要約し、結果を何度も確認し、場合によっては複数のサブタスクを起動する。モデルが賢くなり、ワークフローが自動化されるほど、請求額も静かに膨らみやすい。

だから今回、DeepSeek が重要になっている。単にコードを書けるからではない。長いコンテキストとキャッシュコストが、AI コーディングツールで最もお金が燃える部分にちょうど効いているからだ。

Agent ツールはなぜ token を大量に消費するのか

従来のチャット型コーディング支援は、基本的に一問一答だ。関数の書き方を聞くと、コード片が返ってくる。この形でも token は消費するが、まだ制御しやすい。

Agent ツールは違う。質問に答えるだけではなく、一時的なエンジニアのようにプロジェクトへ入っていく。

まずディレクトリと重要ファイルをスキャンする；
要件と既存アーキテクチャを理解する；
計画を作る；
ファイルを修正する；
コマンドやテストを実行する；
エラーに応じて修正を続ける；
最後に変更内容をまとめる。

この過程では、モデルが同じコンテキストを何度も読む。プロジェクト説明、コード片、ツール結果、過去の会話、計画、エラーログが繰り返しコンテキストに戻される。少し複雑なタスクになるだけで、数十万 token はすぐに消える。

さらに攻めたプラグインを入れると、コストはもっと目立つ。OpenCode や Claude Code の拡張ツールの中には、デフォルトで agent チームを組むものもある。小さな機能を一つ変えたいだけでも、計画、レビュー、実行、振り返りまで起動することがある。タスクはより「賢く」見えるが、token も増え続ける。

Superpowers の利点は必要なときだけ起動すること

Superpowers のようなツールの利点は、すべてのタスクで完全な agent フローを強制しないことだ。

普段は Claude Code、OpenCode、Codex を従来の方法で動かせる。ブレインストーミング、計画作成、計画実行、振り返りのような skill を明示的に呼び出したときだけ、より重い自動化フローに入る。

これはコスト面で重要だ。

AI コーディングでは、すべてのタスクに重装備を使うべきではない。設定を一行変える、エラーを一つ調べる、小さなスクリプトを書く程度なら、普通の対話で十分だ。複雑なリファクタリング、複数ファイルの変更、長文ドキュメント処理、多段階の検証だけが、完全な agent フローに値する。

ツールが強力になるほど、起動条件を制御する必要がある。そうしなければ、自動化が増えるほど無駄も増える。

DeepSeek の重要な強みはキャッシュが安いこと

DeepSeek がこの種の agent ツールに合う大きな理由は、キャッシュヒット時のコストが低いことだ。

AI コーディングタスクには、大量の反復プレフィックスがある。プロジェクト背景、システムプロンプト、ツール説明、ファイル内容、前の会話ターンは、後続リクエストに何度も現れる。モデルサービスが prompt cache をサポートしていれば、こうした反復部分はキャッシュヒット後にかなり安くなる。

多くのモデルでは、キャッシュヒット価格は未ヒットより少し安い程度で、たとえば三分の一前後という感覚だ。DeepSeek の強みは、ヒット後の価格差がもっと大きくなり得ることにある。長いコンテキスト、多段階呼び出し、プロジェクトの反復読み込みを行う agent ワークフローでは、この差が請求に直接出る。

つまり DeepSeek は、毎回の回答が必ず最強というわけではない。しかし「長いタスク、多いターン、コンテキストの反復読み込み」という場面では、コスト構造が AI コーディングに非常に向いている。

長いコンテキストは Claude Code を使いやすくする

Claude Code や類似ツールを DeepSeek V4 に接続すると、もう一つの明確な利点が長いコンテキストだ。

AI コーディングツールが最も嫌うのは、コンテキスト不足だ。コンテキストが足りなくなると、頻繁に圧縮が必要になる。圧縮が増えると、前に読んだ細部が失われることがある。モデルはプロジェクト構造、制約、あるファイルをなぜ変更したかを忘れ始め、その後の品質が落ちる。

DeepSeek V4 系列の長いコンテキスト能力は、コードリポジトリ、ドキュメントの一括処理、字幕翻訳、サイト記事整理に向いている。特に Claude Code や OpenClaw に接続する場合、設定が適切ならコンテキスト圧縮を遅らせ、より多くのプロジェクト詳細を保てる。

だから DeepSeek で動かすと「よく持つ」と感じるタスクがある。各ステップが必ずしも派手ではなくても、長時間、低コスト、反復呼び出しに耐えられる。

V4 Pro と V4 Flash の分担

DeepSeek V4 Pro と V4 Flash は混ぜて使うべきではない。

単純なタスクには DeepSeek V4 Flash が向いている。速く、安く、次のような場面ではたいてい十分だ。

字幕翻訳；
ドキュメント整理；
普通のスクリプト生成；
小規模なコード修正；
OpenClaw の軽量タスク；
簡単なサイトコンテンツ処理。

複雑なタスクでは DeepSeek V4 Pro を検討する。

大規模リファクタリング；
複数モジュールのコード理解；
複雑な推論；
長い agent チェーンのタスク；
高リスクなコード変更；
より強い計画能力が必要なエンジニアリングタスク。

最初から最強モデルを使いたがる人は多いが、それは割に合わないことも多い。AI コーディングツールの現実的な使い方は、タスクを層に分けることだ。安いモデルに大量の定型作業を任せ、高いモデルは重要な判断点だけに使う。

MiniMax、Doubao、DeepSeek は役割が違う

国内モデルやプランの中で、MiniMax、Doubao、Kimi、DeepSeek にはそれぞれ位置づけがある。

MiniMax の強みは、量が多く、安く、機能が広いことだ。最も賢いコーディングモデルではないかもしれないが、翻訳、軽い整理、一括処理には費用対効果が高い。字幕の一括処理、形式変換、簡単な校正などには、MiniMax 型のプランはかなり使いやすい。

Doubao の強みは、ツールエコシステムが広いことだ。画像、動画、検索、TTS、場合によっては STT や embedding までつなげられる。総合ツールボックスに近い。

DeepSeek の位置づけはもっと明確だ。テキスト、コード、長いコンテキスト、低コストキャッシュ。画像生成、音声、動画の完全なエコシステムはなく、弱点ははっきりしている。しかし AI コーディングと長文 agent ワークフローでは、長所が十分に長い。

だから誰が誰を置き換えるという話ではない。タスクを分け、それぞれに合う道具を使う話だ。

コスト削減の鍵は安いモデルを探すだけではない

AI コーディングでコストを下げるとは、すべてのリクエストを安いモデルに替えることではない。

有効な方法はいくつかある。

単純なタスクで重い agent を起動しない。
Flash で十分なタスクに Pro を使わない。
長いタスクではできるだけキャッシュを使う。
反復コンテキストを安定させ、意味のない変更でキャッシュを無効化しない。
大きなタスクは安いモデルに下書きと一括処理をさせ、強いモデルで重要レビューを行う。
agent に、事実を繰り返し説明せず、同じことを何度も要約しないよう明確に伝える。

特に最後の点は重要だ。AI ツールは冗長になりやすい。冗長さは読みやすさだけでなく、コストの問題でもある。プロンプトに「事実は一度だけ説明し、意見は一度だけ述べる」と入れると、文章品質と token 消費の両方を改善できる。

DeepSeek に向く AI コーディングワークフロー

DeepSeek は次のようなタスクに特に向いている。

長いコードリポジトリの読解；
複数ファイルの軽い修正；
ドキュメントの一括整理；
字幕の一括翻訳；
Hugo 記事の整理；
agent 計画の実行；
大量の反復コンテキストを含む低コスト自動化。

すべてのタスクに向くわけではない。特に強いフロントエンドの審美眼、複雑なプロダクト判断、クロスモーダル制作が必要なら、Claude、GPT、Gemini、Doubao などを組み合わせる必要がある。

しかしタスクが「長文、長いコンテキスト、反復呼び出し、コスト敏感」である限り、DeepSeek は第一候補になりやすい。

まとめ

今回の AI コーディングツールの波で、DeepSeek の価値は「国内モデルがコードを書ける」ことだけではない。agent ツールの最も現実的な痛点、つまり長いタスクが高すぎる問題を解いていることにある。

Claude Code、OpenClaw、Superpowers のようなツールは開発フローをますます自動化する。しかしその裏側には、大量のコンテキスト読み書きと多段階呼び出しがある。この部分のコストを下げられる人が、AI コーディングを「たまに気持ちよく使うもの」から「毎日使えるもの」に変えられる。

DeepSeek の長いコンテキスト、低いキャッシュコスト、V4 Flash / V4 Pro の階層的な使い分けは、まさにその位置にある。

今回の本当のコスト削減の鍵は、良いモデルを使わないことではない。良いモデル、安いモデル、キャッシュ、agent フローをうまく組み合わせることだ。この会計を理解できれば、AI コーディングツールは美しいが高価なおもちゃではなく、本当の生産性になる。

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 にまとめる点にあります。

参考資料

Claude Code 24の使い方：計画モード、巻き戻し、CLAUDE.md、Skills、Agents、プラグイン

Fri, 08 May 2026 08:54:14 +0800

Claude Code は単なるチャット欄ではない。プロジェクトディレクトリに入り、ファイルを読み書きし、コマンドを実行し、コンテキストを維持できるコーディング Agent に近い。

要求を投げてコード生成を待つだけだと、計画が曖昧、権限確認が多い、コンテキストが長くなる、結果が気に入らない、戻し方が分からない、プロジェクトルールを残せない、といった問題にすぐ当たる。

ここでは、Claude Code を使い始める開発者向けに、よく使う操作を整理する。

まずプロジェクトディレクトリで起動する

Claude Code は、適当な場所で開くより、プロジェクトディレクトリ内で起動するほうがよい。

まずプロジェクト用フォルダを作り、その中でコマンドラインを開いて Claude Code を起動する。

claude

初回に現在のフォルダを信頼するか聞かれたら、確認してから進める。これで Claude Code は現在のプロジェクトを基準にファイルを読み、作成し、コマンドを実行できる。

練習には、写真家のポートフォリオサイトを作らせるようなタスクが向いている。見た目を確認でき、ファイル生成、コマンド実行、巻き戻し、リファクタリングを一通り試せる。

計画モードで方向を先に決める

Claude Code は複雑なタスクでは計画モードに入ることがある。計画モードでは、先に要件を話し合い、手順を分解してから、実行を承認する。

計画が出た後は、よく次のような選択肢が出る。

計画を承認し、以後の編集ツール使用も自動承認する。
計画を承認するが、以後の編集は手動確認する。
実行を止め、計画についてさらに Claude Code と話す。

タスクが明確なら承認して進める。まだ曖昧なら、ページの雰囲気、技術スタック、ディレクトリ構成、インタラクション、受け入れ条件をさらに詰める。

計画モードの利点は手戻りを減らすことだ。いきなり Agent に作業させると多くのファイルが作られるが、方向が間違っていると後で修正が荒れやすい。

Shift + Tab でモードを切り替える

Claude Code では Shift + Tab で作業モードを切り替えられる。よく使うのは、計画モードへの切り替えや、編集ツールの自動承認モードへの切り替えだ。

おすすめの使い分け：

新規プロジェクト、新機能、大きな変更：まず計画モード。
小さな修正、明確なバグ修正：直接実行。
削除、置換、依存関係のインストール：手動確認を残す。

計画モードでは、Claude Code がプロジェクト詳細を質問することがある。方向キーで選び、Enter で確定する。フィードバックを送ると、それに合わせて計画が更新される。

権限確認をすべて開放しない

Claude Code がコマンド実行、ファイル編集、プログラム起動を行うとき、権限を求めることがある。

よくある選択肢：

今回だけ許可。
現在の会話内で同種コマンドを許可。
拒否または一時停止。

ローカルページの起動、開発サーバーの実行、ファイル確認なら必要に応じて許可してよい。ただし、クリックを減らすために「すべて自動許可」で長く使うのは避ける。

完全自動の権限は、リスクが低く、内容を理解しており、Git バックアップがある場合だけに向く。日常利用では、削除、上書き、依存関係インストール、ネットワーク、コミット、スクリプト実行には人間の確認を残す。

ターミナルモードでローカルコマンドを実行する

Claude Code ではターミナルコマンドモードに入り、ローカルコマンドを実行できる。

ページ生成後、HTML ファイルを開く例：

`1`	`start index.html`

start は Windows でファイルを開くコマンドで、後ろにファイル名を付ける。エクスプローラーで探すより速い。

ターミナルモードに向く操作：

生成ページを開く。
ディレクトリを確認する。
開発サーバーを起動する。
テストやビルドを実行する。

一方、再帰削除、ディレクトリ移動、一括上書き、システム環境変更のような高リスク操作には注意する。

結果が違うときは早めに巻き戻す

Claude Code が作ったページやコードが期待と違い、修正するほど乱れていくなら、早めに巻き戻す。

巻き戻しでは、会話やコードを特定の時点へ戻せる。よくある選択肢：

コードと会話を同時に戻す。
会話だけ戻す。
コードだけ戻す。
以前の内容を要約に圧縮する。
キャンセルする。

明らかに方向がずれた場合は、コードと会話を同時に戻すのがおすすめだ。コンテキストとファイル状態を一緒にきれいな位置へ戻せる。

ただし、Claude Code の巻き戻しは通常、内蔵ツールで作成・変更したファイルが対象だ。外部コマンドで作ったファイルは完全には戻らないことがある。重要なプロジェクトでは Git と併用する。

長いプロンプトはエディタで書く

複雑な要件を1行の入力欄に詰め込まない。

長いプロンプトをテキストエディタで編集できる場合は、エディタで要件を書き、保存してから送る。

長いプロンプトには次を書くとよい。

目的。
使用する技術スタック。
してはいけないこと。
残すべきファイル。
完了後の確認方法。
ページや機能の受け入れ条件。

例えば普通の HTML ページを現代的な技術スタックへリファクタリングしたい場合、「リファクタリングして」だけでは足りない。コンポーネント化、見た目の維持、レスポンシブ対応、ビルド確認まで明記する。

終了後は履歴から会話を復元する

途中で Claude Code を終了する必要がある場合は、通常通り終了する。その後、同じプロジェクトディレクトリに戻って再起動する。

claude

以前の記録が直接出ない場合は、履歴関連コマンドで最近の会話を見て、以前の会話を読み込む。

これは中断後の継続に便利だ。ただし会話履歴だけを記憶として頼らない。プロジェクトルール、技術スタック、よく使うコマンド、注意点はプロジェクトファイルに書く。

CLAUDE.md にプロジェクトルールを保存する

CLAUDE.md は Claude Code にとって重要な記憶ファイルだ。通常はプロジェクトルートに置き、プロジェクトルール、技術スタック、ディレクトリ構造、協業上の制約を書く。

初期化は次で行える。

/init

CLAUDE.md に向いている内容：

プロジェクト目標。
技術スタック。
起動、テスト、ビルドのコマンド。
ディレクトリ説明。
コードスタイル。
禁止操作。
コミットとデプロイルール。

各会話で、Claude Code はこの種のルールをコンテキストの一部として利用できる。プロジェクト説明書と考えると分かりやすい。

簡単な検証方法は、CLAUDE.md に明確なルールを追加してから質問することだ。回答がそのルールに従えば、プロジェクト記憶を読んでいる。

@ でファイルを参照する

入力欄で @ を使うと、ファイルや Agent を選び、現在の会話コンテキストに追加できる。

向いている場面：

設定ファイルを読ませる。
特定ページを修正させる。
CLAUDE.md や他の文書に基づいて続けさせる。
「このファイルだけ見て、構造を推測しない」と明示する。

ファイル内容を入力欄に貼るより、@ 参照のほうが明確で漏れにくい。

コンテキストを確認・圧縮する

長時間会話すると、コンテキストは大きくなる。長すぎるとモデルが遅くなったり、初期の細部を無視し始めたりする。

現在の使用状況は次で確認できる。

`1`	`/context`

長くなったら履歴を圧縮する。

`1`	`/compact`

それでも効果が悪い場合は、現在のコンテキストを消す。

/clear

消した後も、Claude Code はプロジェクトファイル、CLAUDE.md、現在のディレクトリから一部を再理解できる。ただし完全な会話履歴は残らない。

実用的には、1つのタスクが終わったら新しい会話にし、プロジェクトルールは CLAUDE.md に書き、臨時の議論を1つのチャットに積み続けない。

Skills：固定フローを説明書にする

Skills は Claude Code の作業説明書と考えられる。一度きりのプロンプトではなく、再利用できるタスクフローだ。

例えば週報をよく作るなら、週報 Skill を作り、次を明記する。

必要な入力。
出力形式。
口調と構成。
必ず残す内容。
捏造してはいけない内容。

Skills は通常、name、description、具体的な指示で構成される。グローバル Skills ディレクトリに入れると、Claude Code は関連タスクで認識して読み込める。

向いている作業：

週報。
コードレビューのテンプレート。
文書整理。
画像の一括処理。
固定形式の記事。
プロジェクト初期化フロー。

同じプロンプトを何度もコピーしているなら、Skill 化を検討するとよい。

Agents：サブタスクを独立した助手へ渡す

Agents は Skills と違う。

Skill は説明書に近く、Claude Code にやり方を教える。Agent は独立した助手に近く、主会話の外で作業し、結果を返す。

Agents の価値はコンテキストの隔離だ。コード点検なら、読み取り専用 Agent を作り、プロジェクトを読むだけでレポートを出させる。ファイルを直接変更しないので、主会話を汚さず、誤操作も減らせる。

Agent 作成時に考えること：

プロジェクト級かユーザー級か。
Claude Code に設定を生成させるか。
どのツール権限を許すか。
どのモデルを使うか。
記憶を保存するか。
Agent のプロンプトが十分明確か。

コード点検 Agent には、まず読み取り権限だけを与えるのがおすすめだ。先にレポートを出させ、その後で主会話が修正するか判断する。

プラグイン：Skills、Agents、MCP、Hooks をまとめる

プラグインは、より完全な能力パッケージだ。中には次が含まれることがある。

Skills
Agents
MCP
Hooks

単体の Skill より、プラグインはまとまった能力に向いている。例えばフロントエンドデザイン用プラグインなら、見た目のルール、レイアウト、コンポーネント習慣、関連 Agent をまとめて持てる。

インストール時には、よく次の場所を選べる。

ユーザーディレクトリ：全プロジェクトで有効。
プロジェクトディレクトリ：プロジェクトと共有。
ローカルプロジェクトディレクトリ：現在の PC だけで有効。

個人で常用する能力はユーザーディレクトリ、チームの約束はプロジェクトディレクトリ、一時テストはローカルに置くとよい。

プラグインは特定タスクの品質を上げる

フロントエンドページ生成では、プラグインは素のプロンプトより安定しやすい。

同じ「写真家の個人サイトを作る」でも、普通のプロンプトだけなら見られるページができる程度かもしれない。フロントエンドデザインプラグインを明示すると、構造、視覚階層、余白、配色、完成度が良くなりやすい。

もちろんプラグインは人間の審美眼を置き換えない。より良い初稿を作らせ、人間が細部を調整するのが現実的だ。

より安定した Claude Code ワークフロー

これらを組み合わせると、安定した流れになる。

プロジェクトディレクトリで claude を起動する。
まず計画モードで要件を話す。
承認前に技術スタックと受け入れ条件を確認する。
高リスク操作は手動確認を残す。
ターミナルモードでプレビューとテストを行う。
方向がずれたら早めに巻き戻す。
プロジェクトルールを CLAUDE.md に書く。
長い会話では定期的にコンテキストを確認・圧縮する。
繰り返す作業は Skills にする。
点検、調査、分析は読み取り専用 Agents に渡す。
特定分野のタスクはプラグインを優先する。
重要プロジェクトでは常に Git のチェックポイントを作る。

こう使うほうが、「一文送って生成を待つ」よりはるかに安定する。

まとめ

Claude Code の効率はモデル能力だけでなく、ワークフロー制御からも生まれる。

計画モードは方向を決め、権限確認はリスクを抑え、巻き戻しは手戻りを減らす。CLAUDE.md はプロジェクトルールを保存し、/context、/compact、/clear はコンテキストを管理する。Skills は固定フローを再利用し、Agents は複雑なサブタスクを隔離し、プラグインはまとまった能力をプロジェクトへ持ち込む。

Claude Code をうまく使うには、明確な境界の中で継続的に作業させることが大事だ。プロジェクト全体を一度に丸投げするのではない。

opencode、Claude Code、Codex の違いとは？オープンソース AI コーディングツールガイド

Fri, 08 May 2026 08:33:37 +0800

opencode は anomalyco が公開しているオープンソースの AI Coding Agent だ。位置づけは明確で、開発者がターミナル内で、プログラム可能で拡張しやすく、複数のモデル提供元に接続できるコードアシスタントを使えるようにする。

Claude Code や Codex と並べて見ると、3つはいずれも同じ種類の問題を解こうとしている。AI を実際のコードベースに入れ、コンテキストを理解し、ファイルを変更し、コマンドやテストを実行できるようにすることだ。ただし、製品としての向きは異なる。

opencode はオープンソース、複数モデル対応、ターミナル TUI を重視する。Claude Code は Anthropic のモデルエコシステムとローカルでの開発協業を重視する。Codex は OpenAI の AI coding agent であり、ターミナル、IDE、Codex app、クラウドタスクから利用できる。

opencode が向いている人

opencode は次のような開発者に向いている。

ターミナル内でコード変更、プロジェクト分析、エンジニアリングタスクを進めたい人。
AI Coding Agent を単一のモデル提供元に縛られたくない人。
オープンソースツールを好み、自分で監査、拡張、二次開発したい人。
Neovim、TUI、コマンドラインワークフローに慣れている人。
将来的にデスクトップ、モバイル、その他のクライアントから同じコーディングエージェントをリモート操作したい人。

重要なのは、単なるチャットウィンドウを作ることではない。開発者が普段使っているターミナルとプロジェクトディレクトリの中に、AI コーディング能力を入れることだ。

インストール方法

公式 README には複数のインストール方法が用意されている。

# 直接インストール
curl -fsSL https://opencode.ai/install | bash

# npm
npm i -g opencode-ai@latest

# Windows
scoop install opencode
choco install opencode

# macOS と Linux
brew install anomalyco/tap/opencode
brew install opencode

# Arch Linux
sudo pacman -S opencode
paru -S opencode-bin

# その他
mise use -g opencode
nix run nixpkgs#opencode

公式 README では、古いバージョンの残存による問題を避けるため、インストール前に 0.1.x より前のバージョンを削除することも推奨している。

インストールスクリプトは次の優先順位でインストール先を選ぶ。

$OPENCODE_INSTALL_DIR
$XDG_BIN_DIR
$HOME/bin
$HOME/.opencode/bin

パスを指定したい場合は、次のように書ける。

1
2

OPENCODE_INSTALL_DIR=/usr/local/bin curl -fsSL https://opencode.ai/install | bash
XDG_BIN_DIR=$HOME/.local/bin curl -fsSL https://opencode.ai/install | bash

デスクトップアプリはまだ Beta

コマンドラインツールに加えて、opencode はデスクトップアプリも提供している。ただし現在は Beta 扱いだ。GitHub Releases または opencode.ai/download からダウンロードできる。

デスクトップ版は次のプラットフォームに対応している。

プラットフォーム	ファイル
macOS Apple Silicon	`opencode-desktop-mac-arm64.dmg`
macOS Intel	`opencode-desktop-mac-x64.dmg`
Windows	`opencode-desktop-windows-x64.exe`
Linux	`.deb`、`.rpm` または `.AppImage`

macOS と Windows では、パッケージマネージャーからデスクトップ版をインストールすることもできる。

# macOS
brew install --cask opencode-desktop

# Windows
scoop bucket add extras
scoop install extras/opencode-desktop

2つの内蔵 Agent モード

opencode には2つの内蔵 Agent があり、Tab キーで切り替えられる。

build はデフォルトモードで、完全な開発権限を持つ。コードを直接変更し、コマンドを実行し、エンジニアリングタスクを進める用途に向いている。

plan は読み取り専用モードだ。未知のコードベースを分析し、プロジェクト構造を理解し、変更方針を立てる用途に向いている。デフォルトではファイル編集を拒否し、bash コマンドを実行する前に確認する。

さらに、opencode には複雑な検索や多段階タスクのための general サブ Agent もある。ユーザーはメッセージ内で @general と入力して呼び出せる。

この設計は実用的だ。実際に手を動かす前に plan でプロジェクトを把握し、コードを変更する必要が出たら build に切り替える。大規模リポジトリでは、読み取り権限と書き込み権限を分けることで誤操作を減らせる。

Codex とは

Codex は OpenAI の AI coding agent で、開発者がコードを書き、コードレビューを行い、bug を修正し、エンジニアリングタスクを出荷するのを支援する。

単なるコード補完ツールとは異なり、Codex はコードベースを操作できる Agent に近い。ローカルツール内で開発者とペアになって作業することも、クラウドにタスクを委任することもできる。OpenAI の公式資料では、Codex は CLI、IDE、Codex app、ChatGPT/Codex クラウドなど複数の入口から利用できると説明されている。

開発者にとって、Codex のポイントは次の通りだ。

コードベースを読み、ファイルを編集し、コマンドとテストを実行できる。
ターミナル、IDE、アプリ、クラウドなど複数のインターフェースに対応する。
bug 修正、機能開発、リファクタリング、移行、コードレビュー、テスト補完に向いている。
OpenAI アカウント、モデル、Codex 製品体系との結びつきが強い。
クラウドタスクは、比較的明確な複数のエンジニアリングタスクを並行処理するのに向いている。

opencode が開かれたターミナルエージェントフレームワークに近いとすれば、Codex は OpenAI が提供する一式の AI コーディングワークベンチに近い。ローカルでペア作業でき、クラウドに委任でき、チームはそれをより長いエンジニアリングフローへ組み込める。

3つの主な違い

opencode、Claude Code、Codex はいずれも AI コーディングツールだが、選ぶときはまず次の観点を見るとよい。

ツール	中心的な位置づけ	主な強み	向いている用途
`opencode`	オープンソース AI Coding Agent	オープンソース、複数モデル、TUI、クライアント/サーバー構成	開かれたツールチェーン、交換可能なモデル、ターミナル中心のワークフローを求める開発者
`Claude Code`	Anthropic のコマンドライン型コーディングツール	Claude モデル体験、コード理解、長いコンテキスト、エンジニアリングタスク協業	Claude/Anthropic エコシステムを使っていて、ローカルでコードタスクを進めたい開発者
`Codex`	OpenAI の AI coding agent	CLI、IDE、Codex app、クラウドタスク、複数 Agent ワークフロー	ChatGPT/OpenAI を使っていて、ローカルでのペア作業とクラウド委任を併用したいチーム

簡単に言えば、opencode のキーワードは「オープン」と「交換可能」、Claude Code のキーワードは「Claude エコシステム」と「ローカル開発エージェント」、Codex のキーワードは「OpenAI エコシステム」と「複数入口の協業」だ。

Claude Code との違い

opencode の公式 FAQ は Claude Code と直接比較している。両者の能力はかなり近いが、主な違いは次の通りだ。

第一に、opencode は 100% オープンソースプロジェクトで、コードは GitHub にホストされ、MIT license で提供されている。

第二に、opencode は単一のモデル提供元に縛られない。OpenCode Zen が提供するモデルを推奨しているが、Claude、OpenAI、Google、またはローカルモデルとも組み合わせられる。開発者にとっては、モデルのコスト、能力、可用性が変わっても、特定のプラットフォームにロックインされにくいという意味がある。

第三に、opencode は任意の LSP サポートを内蔵している。コード補完、ジャンプ、診断、プロジェクト理解にとって、LSP は非常に重要な基盤だ。

第四に、opencode は TUI を重視している。Neovim ユーザーと terminal.shop の作成者によって作られており、製品の重心は明らかにターミナル体験にある。

第五に、opencode はクライアント/サーバー構成を採用している。つまり、opencode を自分のコンピューター上で動かし、将来的に TUI、デスクトップ、モバイル、その他のクライアントから制御できる。TUI はそのうちの一つのフロントエンドにすぎない。

opencode、Claude Code、Codex をいつ選ぶか

すでに Claude Code や Codex を使っている場合、opencode がすぐにそれらを置き換える必要はない。より自然な見方は、opencode がオープンで、モデルを交換でき、ターミナル寄りの選択肢を提供しているというものだ。

opencode を優先して検討したい場面は次の通り。

AI コーディングツールをできるだけオープンソースにしたい。
ワークフローを特定のモデル提供元に縛られたくない。
同じツールで Claude、OpenAI、Google、またはローカルモデルを試したい。
TUI が好きで、主要な作業フローをデスクトップアプリやWebアプリに中断されたくない。
クライアント/サーバー構成によるリモート制御能力に関心がある。

Claude Code を優先して検討したい場面は次の通り。

主に Claude モデルを使っている。
長いコンテキスト、コード理解、複雑なエンジニアリングタスク協業を重視している。
ローカルリポジトリ内で変更、テスト、リファクタリングを継続的に進めたい。
Anthropic による Claude Code のデフォルト製品体験を信頼している。

Codex を優先して検討したい場面は次の通り。

すでに ChatGPT または OpenAI アカウント体系を使っている。
同じ coding agent をターミナル、IDE、デスクトップアプリ、クラウドタスクで使いたい。
明確な bug 修正、機能開発、移行、テスト補完をクラウドに委任して並行処理したい。
コードレビュー、バックグラウンドタスク、チーム協業、複数 Agent ワークフローが必要だ。

公式の一体化された体験、デフォルトのモデル設定、企業管理、既製の統合を重視するなら、Claude Code や Codex のほうが楽な場合がある。制御性、オープン性、provider-agnostic を重視するなら、opencode は注目に値する。

注意点

opencode、Claude Code、Codex はいずれも変化が速い。GitHub release、インストールコマンド、デスクトップ版のファイル名、モデルの可用性、プラン権限は変わる可能性がある。インストールや選定の前には、それぞれの公式 README、ドキュメント、リリースページを直接確認するのがよい。

また、opencode のデスクトップアプリはまだ Beta と表示されており、安定した本番用ツールとして最初から扱うべきではない。日常的なエンジニアリングタスクでは、ターミナル版が引き続き主な入口になる。

ツールの流れとして見ると、opencode は AI Coding Agent のオープンツールチェーン方向を代表している。モデルを交換でき、クライアントも交換でき、コアの代理能力をできるだけ開く方向だ。一方、Codex と Claude Code は、モデル企業が coding agent を完成度の高い製品入口として作る方向に近い。開発者にとって、この2つの流れは長く併存するだろう。

参考リンク

opencode GitHub：https://github.com/anomalyco/opencode
opencode 公式サイト：https://opencode.ai
opencode ドキュメント：https://opencode.ai/docs
opencode Releases：https://github.com/anomalyco/opencode/releases
OpenAI Codex：https://openai.com/codex/
Using Codex with your ChatGPT plan：https://help.openai.com/en/articles/11369540-codex-in-chatgpt
OpenAI Codex CLI Getting Started：https://help.openai.com/en/articles/11096431-openai-codex-ci-getting-started

Warp オープンソース化：ターミナルから Agentic Development Environment へ

Thu, 07 May 2026 20:15:08 +0800

warpdotdev/warp は Warp のオープンソースクライアントリポジトリです。Warp は現在、自身を「ターミナルから生まれた agentic development environment」と位置付けています。つまり、ターミナルを土台にしながら、AI coding agent、コードベース索引、タスク管理、開発ワークフローを同じ環境に統合しようとしています。

これは普通のターミナルエミュレータのオープンソースリポジトリではありません。むしろ、Claude Code、Codex、Gemini CLI のような agent が一般化する中で、ターミナル自体が agent を調整し、観察し、管理する開発環境になるべきか、という問いへの答えに近いものです。

Warp の答えは「なるべき」です。

現在のリポジトリ状況

2026年5月7日時点で、warpdotdev/warp は公開リポジトリで、GitHub では約 56k stars、4.1k forks が表示されています。README では、Warp のクライアントコードがオープンソース化され、コミュニティからの貢献を歓迎すると説明されています。

主要言語は Rust です。GitHub の言語統計では Rust が 98% 以上を占めています。これは Warp の位置付けと合っています。Web のラッパーではなく、クロスプラットフォームのネイティブ開発ツールです。

README で重要な点は次の通りです。

Warp は agentic development environment, born out of the terminal。
内蔵 coding agent を使えるだけでなく、Claude Code、Codex、Gemini CLI などの外部 CLI agent にも接続できる。
OpenAI は新しくオープンソース化された Warp リポジトリの founding sponsor。
リポジトリ内の agentic management workflows は GPT models によって駆動される。
Warp UI framework 関連 crate は MIT license、それ以外のコードは AGPL v3。

これらを見ると、Warp のオープンソース化は単にターミナルを公開しただけではなく、agent ワークフローの実験場として運営していることが分かります。

Warp は単なるターミナルではない

従来のターミナルが主に解決していたのは次の三つです。

shell を起動する。
コマンドを実行する。
出力を表示する。

初期の Warp の差別化は、ターミナルをより現代的にすることでした。コマンドブロック、補完、履歴、コラボレーション、UI 的な操作、クロスプラットフォーム体験などです。現在はさらに進み、AI agent を中心に開発フローを組み立てようとしています。

README から見ると、Warp はもはや「より使いやすい terminal」だけを強調していません。次の要素を重視しています。

内蔵 coding agent。
外部 CLI agent 対応。
issue triage。
spec 作成。
PR review。
contributor coordination。
観察可能な agent sessions。

つまり Warp は、ターミナルを「コマンドを入力する場所」から「複数の agent と一緒に働く場所」へ変えようとしています。

Oz とオープンソース管理

README では Oz が何度も登場します。

Warp の contribution overview では、多数の Oz agents が issue triage、spec 作成、実装、PR review に取り組んでいる様子が示されています。これは興味深い設計です。AI agent を「個人のコード作成支援」から「オープンソース協作の管理支援」へ広げているからです。

従来のオープンソースプロジェクトで難しいのは、コードを書くことだけではありません。むしろ維持管理です。

issue が多すぎて分類されない。
bug と feature request が混在する。
新規貢献者が取り組みやすいタスクを見つけにくい。
PR review の負担が大きい。
メンテナーがコミュニティ議論を継続的に追いにくい。

Warp の考え方は、agent にプロジェクト管理と協作作業の一部を先に担わせることです。README には Oz for OSS も登場します。これはメンテナー向けのプログラムで、同様の agentic open-source management workflows をほかのリポジトリへ持ち込むためのものです。

つまり Warp の狙いはターミナル製品だけではなく、AI 時代のオープンソース維持管理モデルの探索にもあります。

リポジトリ構成と技術スタック

リポジトリ構成を見ると、Warp は大規模な Rust プロジェクトです。

ルートには次のようなものがあります。

app/：メインアプリケーション関連コード。
crates/：中核 Rust crates。
assets/：リソースファイル。
command-signatures-v2/：コマンドシグネチャ関連。
docker/、script/、resources/、specs/ などのエンジニアリング用ディレクトリ。
.claude/、.warp/、.agents/skills などの agent 関連設定。

WARP.md にはより詳しいエンジニアリング説明があります。Warp は Rust-based terminal emulator で、自社製 UI framework WarpUI を使っていると説明されています。

主要モジュールはおおよそ次のように理解できます。

app/：ターミナルエミュレーション、shell 管理、AI 統合、Drive、認証、設定、workspace、session。
crates/warp_core/：中核ユーティリティとプラットフォーム抽象。
crates/editor/：テキスト編集機能。
crates/warpui/ と crates/warpui_core/：自社製 UI framework。
crates/ipc/：プロセス間通信。
crates/graphql/：GraphQL client と schema。

WARP.md ではさらに次のような特徴も挙げられています。

Entity-Handle system。
モジュール化された workspace 構造。
macOS、Windows、Linux クロスプラットフォーム、および WASM target。
Agent Mode、文脈認識、コードベース索引を含む AI integration。
Warp Drive クラウド同期。

この複雑さは、従来の軽量 terminal よりも、ほぼ完全な IDE に近いものです。

ローカルビルド

README のローカルビルド手順は簡潔です。

1
2
3

./script/bootstrap
./script/run
./script/presubmit

それぞれ次の役割です。

./script/bootstrap：プラットフォーム別の初期化。
./script/run：Warp をビルドして実行。
./script/presubmit：フォーマット、clippy、テストなどの提出前チェック。

WARP.md にはさらに細かいコマンドもあります。

cargo run
cargo bundle --bin warp
cargo nextest run --no-fail-fast --workspace --exclude command-signatures-v2
cargo fmt
cargo clippy --workspace --all-targets --all-features --tests -- -D warnings

Warp にコードを貢献するなら、./script/presubmit は基本的に必須です。

貢献フロー

Warp の貢献フローは、単に「PR を出せばよい」ではありません。

README では issue から PR までの軽量な流れが説明されています。

まず既存 issue を検索する。
重複がなければ bug または feature request を提出する。
メンテナーが issue を review し、readiness label を付けることがある。
ready-to-spec は、設計を spec として展開できる状態。
ready-to-implement は、設計が比較的明確で実装 PR に進める状態。
貢献者はラベル付き issue を引き受けられる。

この流れは大規模オープンソースに向いています。「アイデア」「設計」「実装」を分けることで、貢献者が最初から違う方向へ実装してしまうリスクを減らせます。

AI agent にも相性が良い流れです。agent はまず issue を整理し、spec を書き、テストを追加してから実装に進めます。Warp 自身もこの方式で agentic project management を示しています。

ライセンス：MIT + AGPL v3

Warp は二つのライセンス構成を採っています。

README では次のように説明されています。

Warp UI framework、つまり warpui_core と warpui crates は MIT license。
リポジトリのそれ以外のコードは AGPL v3。

これは重要です。AGPL v3 はネットワークサービスや配布に対して、より強いオープンソース要件を持ちます。学習、研究、貢献であれば大きな問題はありませんが、Warp のコードを商用製品やクローズドソース派生物に使いたい場合は、license を慎重に読み、必要なら法務相談が必要です。

簡単に言えば、Warp はオープンソースですが、「自由に持っていって閉源商用化できる」タイプの緩いライセンスではありません。

注目すべき点

第一に、Warp はターミナル、agent、プロジェクト管理を一つにまとめようとしています。

多くの AI coding ツールはまだ CLI かエディタプラグインです。Warp はターミナルという入口から、agent タスク、コード実行、コマンド出力、PR ワークフロー、チーム協作を統合しようとしています。

第二に、Warp のオープンソース化は agent ワークフロー観察に向いています。

コードを公開するだけでなく、contribution overview、agent session、issue triage、spec フローも見せています。AI がオープンソース協作にどう参加できるかを研究したい人にとって、このリポジトリ自体がサンプルです。

第三に、Warp は複雑な Rust デスクトップアプリケーションです。

Rust GUI、ターミナルエミュレータ、クロスプラットフォームアプリ、GraphQL client、クラウド同期、AI 統合を学びたいなら、読むべき構造が多くあります。ただし小さなプロジェクトではないため、新規貢献者はまずドキュメントと issue フローを読むべきです。

第四に、Warp は「内蔵 agent」と「bring your own CLI agent」の両方を支援しています。

これは現実的です。開発者が一つの agent だけを使うとは限りません。Claude Code、Codex、Gemini CLI、OpenCode、OpenClaw などは共存し続けるでしょう。Warp がそれらの作業台になれるなら、単一目的のターミナル以上の価値があります。

誰が注目すべきか

通常のターミナルユーザーにとって、Warp に注目する意味は、ターミナルがコマンドラインツールから AI ワークベンチへ変わりつつあるかもしれない点です。

AI coding agent をよく使う人にとって、Warp は複数 agent を管理しようとしている点で注目に値します。単なるチャット入口ではありません。

オープンソースメンテナーなら、Oz for OSS の流れを見る価値があります。agent による issue triage、PR review、コミュニティ協作、貢献者案内を試みています。

Rust 開発者にとって、Warp は大型の実例デスクトップアプリです。UI、ターミナル、クラウド同期、AI 統合、クロスプラットフォームコードの構成を研究できます。

単に従来のターミナルをすぐ置き換えたいだけなら、まず正式版をダウンロードして使い、その後でソースを読むか決めるのがよいでしょう。ソースから直接ビルドするのは、貢献者や深いユーザー向けです。

短評

Warp のオープンソース化の要点は、「現代的なターミナルがオープンソースになった」だけではありません。

より正確には、Warp はターミナルを agentic development environment へアップグレードしようとしています。ターミナルが shell、コードベース、コマンド実行、agent、issue、PR、協作フローをつなぐ役割を担う、という考え方です。

AI coding agent がさらに増える中で、開発環境の入口は変わるかもしれません。以前は IDE が開発体験を支配し、ターミナルはコマンド実行を担っていました。今後はターミナルが agent 協作の中心になる可能性があります。Warp のリポジトリは、その可能性を探っています。

Hermes + Qwen3.6：ローカル Agent の低コスト構築案

Mon, 04 May 2026 06:40:30 +0800

この記事は、ローカル Agent の構築案を整理したものだ。WSL2 上で llama.cpp を使って Qwen3.6 GGUF モデルを動かし、Hermes Agent をローカルの OpenAI-compatible API に接続する。これにより、自分の PC 上で長時間動作するローカル AI アシスタントを用意でき、オンラインサービスの Token 消費に縛られにくくなる。

この構成は、ローカル AI Agent を試したい人、データのプライバシーと長期的な管理性を重視する人に向いている。日常の質問応答、執筆、コード補助、資料整理、簡単な自動化タスクに使える。ただし、モデルが大きいほど VRAM 要件も高くなる。原文の例では Qwen3.6-27B を使っており、24GB VRAM のほうが安定しやすい。VRAM が少ない場合は、小さいモデルや低い量子化版を選ぶ。

構成

全体の流れはシンプルだ。

Windows に WSL2 と Ubuntu 24.04 をインストールする。
WSL2 内に CUDA Toolkit を入れ、llama.cpp をビルドする。
Qwen3.6 GGUF モデルをダウンロードする。
llama-server でローカルモデルサービスを起動する。
Hermes Agent をインストールし、http://localhost:8080/v1 に接続する。
任意で起動スクリプトを書き、WSL2 起動時にモデルサービスを自動起動する。

Hermes は Agent 機能を担当し、Qwen3.6 はローカル LLM 機能を担当する。組み合わせることで、PC をローカルのプライベート AI アシスタントにできる。

WSL2 と Ubuntu のインストール

Windows PowerShell を管理者として開き、次を実行する。

1
2

wsl --install
wsl --set-default-version 2

再起動後、Ubuntu 24.04 をインストールする。

`1`	`wsl --install -d Ubuntu-24.04`

インストール後、Ubuntu がユーザー名とパスワードの設定を求める。Ubuntu に入ったら、まず NVIDIA GPU が WSL2 から見えているか確認する。

`1`	`nvidia-smi`

GPU が認識されない場合は、Windows 側の NVIDIA ドライバを更新する。WSL2 は Windows ドライバを継承するが、CUDA Toolkit は WSL2 内に別途インストールする必要がある。

Python と基本ツールのインストール

`1`	`sudo apt update && sudo apt install -y python3-pip python3-venv`

続いて、ビルドツール、Git、CMake も必要になる。

`1`	`sudo apt install -y cmake build-essential git`

llama.cpp のビルド

まずソースコードを取得する。

1
2

git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp

WSL2 内で CUDA が使える状態なら、そのままビルドできる。

1
2

cmake -B build -DGGML_CUDA=ON -DCMAKE_CUDA_ARCHITECTURES=89
cmake --build build -j$(nproc)

CMAKE_CUDA_ARCHITECTURES=89 は RTX 40 シリーズなど Ada アーキテクチャ向けだ。別の GPU では実際のアーキテクチャに合わせて変更する。

CUDA Toolkit がないというエラーが出る場合は、先に WSL2 内で CUDA Toolkit をインストールする。

wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2404/x86_64/cuda-keyring_1.1-1_all.deb
sudo dpkg -i cuda-keyring_1.1-1_all.deb
sudo apt update
sudo apt install -y cuda-toolkit-12-8

環境変数を設定する。

export PATH=/usr/local/cuda-12.8/bin:$PATH
export LD_LIBRARY_PATH=/usr/local/cuda-12.8/lib64:$LD_LIBRARY_PATH
echo 'export PATH=/usr/local/cuda-12.8/bin:$PATH' >> ~/.bashrc
echo 'export LD_LIBRARY_PATH=/usr/local/cuda-12.8/lib64:$LD_LIBRARY_PATH' >> ~/.bashrc

その後、再ビルドする。

cd ~/llama.cpp
rm -rf build
cmake -B build -DGGML_CUDA=ON -DCMAKE_CUDA_ARCHITECTURES=89
cmake --build build -j$(nproc)

Qwen3.6 GGUF モデルのダウンロード

原文の例では、unsloth/Qwen3.6-27B-GGUF の Qwen3.6-27B-UD-Q4_K_XL.gguf を使っている。

1
2
3

hf download unsloth/Qwen3.6-27B-GGUF \
Qwen3.6-27B-UD-Q4_K_XL.gguf \
--local-dir ~/models/

このファイルは約 17GB。Hugging Face のダウンロードが遅い場合は、ModelScope などのミラーを使う。VRAM が足りない場合は 27B を無理に使わず、小さいモデルか低い量子化版を選ぶ。

ローカルモデルサービスを起動する

自分のモデルファイル名に合わせて llama-server を起動する。

~/llama.cpp/build/bin/llama-server \
--model ~/models/Qwen3.6-27B-UD-Q4_K_XL.gguf \
--n-gpu-layers 99 \
--ctx-size 32768 \
--flash-attn on \
--temp 1.0 \
--top-p 0.95 \
--top-k 20 \
--presence-penalty 1.5 \
--port 8080

起動後、Windows のブラウザで次を開く。

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

Hermes Agent や他の OpenAI-compatible クライアントから呼び出す場合、API アドレスは通常次になる。

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

Thinking モードの使い分け

Qwen3.6 はデフォルトで Thinking モードが有効になる場合がある。複雑な推論、難しいコード問題、多段階分析には向いているが、速度は遅くなる。

Thinking モードを無効にしたい場合は、サービスを停止して --chat-template-kwargs を追加する。

~/llama.cpp/build/bin/llama-server \
--model ~/models/Qwen3.6-27B-UD-Q4_K_XL.gguf \
--n-gpu-layers 99 \
--ctx-size 32768 \
--flash-attn on \
--temp 1.0 \
--top-p 0.95 \
--top-k 20 \
--presence-penalty 1.5 \
--chat-template-kwargs '{"enable_thinking":false}' \
--port 8080

Thinking を無効にすると、簡単な Q&A、執筆、コード補完、コード説明は速くなる。一方、複雑なアルゴリズム設計、難しい Debug、アーキテクチャ分析では Thinking を有効にするほうがよい。

Hermes Agent のインストール

llama-server を動かしたまま、新しい WSL2 ターミナルを開いて Hermes Agent をインストールする。

`1`	`curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh \| bash`

インストールスクリプトは Python、Node.js、ripgrep、ffmpeg などの依存関係を処理する。モデル endpoint の設定では custom endpoint を選ぶ。

1
2
3

URL: http://localhost:8080/v1
API Key: 12345678
Model: 自動認識

ローカルの llama-server では、API Key は任意のプレースホルダでよい。設定後は Telegram、WeChat、QQ、Discord などのチャットツールと接続し、Hermes Agent からローカルモデルを呼び出してタスクを実行できる。

モデルサービスの自動起動

WSL2 ターミナルを開いたときにモデルサービスを自動起動するスクリプトを用意できる。

スクリプトを作成する。

cat > ~/start-llm.sh << 'EOF'
#!/bin/bash
echo "Starting Qwen3.6-27B llama-server..."
~/llama.cpp/build/bin/llama-server \
--model ~/models/Qwen3.6-27B-UD-Q4_K_XL.gguf \
--n-gpu-layers 99 \
--ctx-size 65536 \
--flash-attn on \
--temp 1.0 \
--top-p 0.95 \
--top-k 20 \
--presence-penalty 1.5 \
--port 8080 \
--host 0.0.0.0 &
echo "llama-server started, PID: $!"
echo "API: http://localhost:8080/v1"
echo "Chat UI: http://localhost:8080"
EOF
chmod +x ~/start-llm.sh

.bashrc に追記する。

echo '# Auto-start llama-server' >> ~/.bashrc
echo 'if ! pgrep -f "llama-server" > /dev/null 2>&1; then' >> ~/.bashrc
echo '    ~/start-llm.sh' >> ~/.bashrc
echo 'fi' >> ~/.bashrc

これで WSL2 ターミナルを開くたびに、llama-server が動いていなければ自動起動する。すでに動いている場合はスキップされ、重複起動を避けられる。

注意事項

27B モデルは VRAM 要件が高い。24GB VRAM のほうが安定しやすく、VRAM が少ない場合は小さいモデルにする。
--ctx-size 65536 は VRAM と RAM の負荷を大きく増やす。不安定な場合は 32768 かそれ以下に下げる。
WSL2 内の CUDA Toolkit と Windows 側の GPU ドライバの両方が正常である必要がある。どちらかが問題を起こすと、CUDA のビルドや実行に失敗する。
Hermes Agent がローカルサービスへ接続する仕組みは OpenAI-compatible API 呼び出しであり、重要なのは http://localhost:8080/v1 が正常に応答すること。
スマホや他の端末からアクセスする場合は、Windows Firewall、LAN アドレス、セキュリティ分離を追加で扱う。ローカルモデルサービスを直接インターネットへ公開しない。

Cline で DeepSeek V4 Pro を呼び出す方法

Fri, 01 May 2026 20:59:06 +0800

Cline はすでに OpenAI Compatible Provider をサポートしています。 DeepSeek API も OpenAI SDK 風の呼び出しに対応しているため、deepseek-v4-pro を Cline に接続するのは難しくありません。OpenAI Compatible を選び、DeepSeek の Base URL、API Key、モデル名を入力すればよいだけです。

以下では、VS Code 拡張機能の画面と Cline CLI の 2 通りで整理します。

DeepSeek API Key を準備する

まず DeepSeek の開放プラットフォームで API Key を作成します。

必要な値は 3 つです。

項目	入力内容
Provider	`OpenAI Compatible`
Base URL	`https://api.deepseek.com`
Model ID	`deepseek-v4-pro`

DeepSeek の公式ドキュメントでは、V4 シリーズは既存の OpenAI 互換インターフェースを使い、base_url は https://api.deepseek.com のまま、呼び出し時に model を deepseek-v4-pro または deepseek-v4-flash に設定すると説明されています。

Cline 拡張機能で設定する

VS Code の Cline 拡張機能を使っている場合は、次の手順で設定できます。

VS Code サイドバーの Cline を開く。
Cline の設定またはモデル設定ページに入る。
Provider で OpenAI Compatible を選ぶ。
API Key に DeepSeek API Key を入力する。
Base URL に次を入力する。

`1`	`https://api.deepseek.com`

Model ID に次を入力する。

`1`	`deepseek-v4-pro`

設定を保存し、Cline のチャット画面に戻って簡単なタスクでテストする。

まずは低リスクな読み取り専用タスクを試すとよいです。

現在のプロジェクトのディレクトリ構造を読み取り、このプロジェクトがどの種類のものか要約してください。ファイルは一切変更しないでください。

正常に読み取りと回答ができれば、モデルの接続は通っています。

Cline CLI で設定する

Cline CLI を使う場合は、cline provider configure openai-compatible で対話式設定に入れます。

例：

`1`	`cline provider configure openai-compatible`

対話中に次を入力します。

1
2
3

API Key: sk-...
Base URL: https://api.deepseek.com
Model ID: deepseek-v4-pro

設定後、読み取り専用タスクでテストできます。

`1`	`cline "Summarize this repository structure without changing files."`

まずコストを下げたい場合は、Model ID を一時的に次へ変更してもよいです。

`1`	`deepseek-v4-flash`

複雑な計画、事実確認、複数ツールの協調、高リスクなコード変更が必要になったら、deepseek-v4-pro に戻します。

推奨するモデルの使い分け

DeepSeek V4 Pro と Flash は、役割を分けて使うほうが向いています。

モデル	向いている場面
`deepseek-v4-flash`	日常的なコード読解、小さな修正の一括処理、スクリプト生成、コンテキスト整理、低リスクなフロントエンド修正
`deepseek-v4-pro`	アーキテクチャ設計、複雑な bug、複数ファイルのリファクタリング、事実確認、複数ツール呼び出し、高リスクな変更

Cline のような Agent ツールでは、主なコストは長いコンテキスト、繰り返しのファイル読み取り、計画生成、複数ラウンドのツール呼び出しから発生します。軽いタスクなら Flash で量をこなし、より強い判断が必要なときに Pro へ切り替えるのが現実的です。

コンテキスト長はどう設定するか

DeepSeek V4 Pro と Flash はどちらも長いコンテキストをサポートします。 Cline で context window を手動入力する必要がある場合は、DeepSeek 公式モデルページにある 1M コンテキストを目安にできます。

実際には、最初からすべてのファイルをコンテキストに入れることはおすすめしません。 Cline はタスクに応じてファイルを読み取るため、通常は次の流れがよいです。

まずディレクトリ構造を確認させる；
次に関連ファイルを特定させる；
最後に対象ファイルだけを中心に修正させる。

このほうが Token を節約でき、タスクの境界も明確に保ちやすくなります。

よくある問題

1. モデルが存在しないと表示される

まず Model ID が次のように書かれているか確認します。

`1`	`deepseek-v4-pro`

DeepSeek V4 Pro、deepseek-v4、その他の表示名を書かないでください。

2. 401 または認証失敗が出る

API Key を確認します。

完全にコピーできているか；
余計な空白が入っていないか；
Cline が現在使っている provider 設定に入力されているか；
DeepSeek アカウントに利用可能な残高があるか。

3. 接続失敗と表示される

Base URL を確認します。

`1`	`https://api.deepseek.com`

末尾に /v1/chat/completions を追加しないでください。 Cline の OpenAI Compatible Provider が互換インターフェースのリクエストを自分で組み立てます。

4. Cline の呼び出しが高くつく

日常タスクは deepseek-v4-flash に切り替え、複雑なタスクだけ deepseek-v4-pro を使うとよいです。

また、タスク説明はできるだけ明確に書きます。

ログインページ関連ファイルだけを修正してください。無関係なモジュールはリファクタリングしないでください。まず計画を提示し、確認後にコードを変更してください。

Agent タスクで最も危ないのは境界が曖昧なことです。境界が明確なほど、読むファイルが少なくなり、ツール呼び出しも減り、コストを制御しやすくなります。

5. reasoning_content must be passed back エラー

次のようなエラーが出る場合があります。

{
  "message": "400 The `reasoning_content` in the thinking mode must be passed back to the API.",
  "code": "invalid_request_error",
  "modelId": "deepseek-v4-pro"
}

これは通常、Key、残高、Base URL の問題ではありません。DeepSeek V4 Pro の thinking mode と、現在のクライアント側の複数ラウンドのツール呼び出し履歴が一致していないことが原因です。

DeepSeek の公式ドキュメントでは、次のように説明されています。

thinking mode はデフォルトで enabled；
thinking mode では reasoning_content が返る；
あるラウンドで tool call が発生した場合、以降のリクエストではその assistant message 内の reasoning_content を API に一緒に返す必要がある；
クライアントが正しく返さない場合、400 が返る。

Cline が OpenAI Compatible Provider 経由で接続している場合、現在のバージョンが DeepSeek の reasoning_content を完全に保持して返していないと、2 ラウンド目やツール呼び出し後にこのエラーが出ることがあります。

試す順序は次のとおりです。

まず Cline を最新版に更新する；
通常の OpenAI provider ではなく、OpenAI Compatible を使っていることを確認する；
Cline がカスタム request body をサポートしている場合、thinking mode を無効化してみる：

{
  "thinking": {
    "type": "disabled"
  }
}

Cline が追加 body パラメータをサポートしていない場合は、当面この問題を起こさないモデルまたは互換プロキシサービスを使う；
Cline が DeepSeek V4 の reasoning_content 返送に対応したら、deepseek-v4-pro に戻す。

注意点として、thinking mode を無効にすると複雑な推論能力の一部は落ちますが、クライアントが reasoning_content を返さない互換性問題は回避できます。

そのままコピーできる設定

Provider: OpenAI Compatible
API Key: sk-あなたの DeepSeek API Key
Base URL: https://api.deepseek.com
Model ID: deepseek-v4-pro

低コストモードにする場合：

Provider: OpenAI Compatible
API Key: sk-あなたの DeepSeek API Key
Base URL: https://api.deepseek.com
Model ID: deepseek-v4-flash

まとめ

Cline で DeepSeek V4 Pro を呼び出す要点は 3 つだけです。

Provider で OpenAI Compatible を選ぶ；
Base URL に https://api.deepseek.com を入力する；
Model ID に deepseek-v4-pro を入力する。

設定後は、まず読み取り専用タスクでテストし、それから実際のコード変更を任せるのがおすすめです。 Agent タスクを頻繁に実行するなら、Flash と Pro を分けて使うとよいです。Flash は高頻度の軽量タスク、Pro は複雑な判断とフォールバックを担当します。

参考情報：

DeepSeek V4 の値下げは AI Agent のコストモデルをどう書き換えるか

Fri, 01 May 2026 19:47:47 +0800

DeepSeek V4 の発表は、特別に大きな話題を作ったわけではありません。大規模な発表会もなく、すべての競合を一目で圧倒するようなベンチマークの物語もありませんでした。しかし数日後、本当に業界へ影響する部分が見え始めました。連続的な値下げです。

今回の変化で重要なのは、「モデルが少し強くなった」ことではなく、「利用コストが別の水準まで下がった」ことです。 Token 価格が、普通の Agent タスクなら数毛から数元で完了できるほど低くなると、多くの Coding Plan や Token Plan のビジネスロジックは見直しを迫られます。

発表当日は爆発的ではなかった

DeepSeek V4 に対する最初の反応は、そこまで熱狂的ではありませんでした。多くの人は R1 のような強い衝撃を期待していました。ベンチマークの全面的なリード、国産計算資源の検証、マルチモーダルと Agent 能力の同時爆発です。しかし実際に発表されると、それは堅実なアップグレードに近いものでした。

V4 Pro は確かに強いモデルです。特にコード、数学、長文コンテキスト、agentic coding では良い性能を見せます。ただし、同種のモデルを一瞬で色あせさせるような製品ではありません。そのため発表当日の世論には少し気まずさがありました。褒めたいけれど、十分に爆発的な切り口が見つかりにくかったのです。

本当の転換点は発表当日ではなく、その後の価格調整でした。

連続値下げこそが重要

DeepSeek V4 の発表後、価格は連続して下がり始めました。 DeepSeek の公式価格ページと元記事の整理によると、当時のおおよその価格は次のとおりです。

DeepSeek V4 Flash：入力 100 万 Token あたり約 1 元。キャッシュヒット後は 100 万 Token あたり約 2 分；
DeepSeek V4 Pro：入力 100 万 Token あたり約 3 元。キャッシュヒット後は 100 万 Token あたり約 2.5 分；
全シリーズの入力キャッシュヒット価格は、初回価格の 1/10 に低下；
V4 Pro は一時 75% 割引期間にあり、割引は 2026 年 5 月 31 日 23:59 まで延長されました。

米ドルの API 価格で見ると、さらに直感的です。

モデル	キャッシュヒット入力	非キャッシュ入力	出力	コンテキスト
`deepseek-v4-flash`	$0.0028 / 100万 Token	$0.14 / 100万 Token	$0.28 / 100万 Token	1M
`deepseek-v4-pro` プロモーション価格	$0.003625 / 100万 Token	$0.435 / 100万 Token	$0.87 / 100万 Token	1M
`deepseek-v4-pro` 通常価格	$0.0145 / 100万 Token	$1.74 / 100万 Token	$3.48 / 100万 Token	1M

ここで注意すべき点が 2 つあります。

第一に、V4 Pro の $0.435 / $0.87 はプロモーション価格であり、長期的な通常価格ではありません。 DeepSeek の公式説明では、この 75% 割引は 2026 年 5 月 31 日 15:59 UTC まで延長されています。

第二に、Agent のコストモデルで重要なのはキャッシュヒット価格です。 Flash のキャッシュヒット入力は $0.0028 / 100万 Token まで低く、Pro のプロモーション期間中のキャッシュヒット入力は $0.003625 / 100万 Token です。これは、繰り返し使われるプロジェクトコンテキスト、ツール定義、システムプロンプト、履歴要約が、完全な入力価格で課金されなくなることを意味します。

この価格のもっとも重要な点は、多くのタスクで Token コストが「気になりにくくなる」ことです。以前の開発者は、1 回の Agent タスクが大量のコンテキストを消費し、コードを何度も読み書きし、ツールを頻繁に呼び出すことを心配していました。今はキャッシュヒット率が十分に高ければ、コストをかなり低く抑えられます。

GPT、Claude との価格比較

DeepSeek 自体の価格だけを見ても、差はまだ感じにくいかもしれません。同時期によく使われるクローズドモデルと並べると、違いはより明確になります。

モデル	入力	キャッシュ入力	出力	適した場面
`deepseek-v4-flash`	$0.14 / M	$0.0028 / M	$0.28 / M	高頻度 Agent、通常の coding、バッチタスク
`deepseek-v4-pro` プロモーション価格	$0.435 / M	$0.003625 / M	$0.87 / M	複雑な coding、計画、事実確認
`deepseek-v4-pro` 通常価格	$1.74 / M	$0.0145 / M	$3.48 / M	プロモーション終了後の Pro コスト基準
GPT-5.5	$5 / M	$0.50 / M	$30 / M	高品質な複雑タスク、汎用推論
GPT-5.4	$2.50 / M	$0.25 / M	$15 / M	プログラミングと専門タスクの中位選択肢
GPT-5.4 mini	$0.75 / M	$0.075 / M	$4.50 / M	低コストの汎用/サブタスクモデル
Claude Opus 4.7	$5 / M	$0.50 / M	$25 / M	高品質な執筆、複雑推論、長時間タスク
Claude Sonnet 4.6	$3 / M	$0.30 / M	$15 / M	プログラミング、Agent、総合タスク
Claude Haiku 4.5	$1 / M	$0.10 / M	$5 / M	軽量タスク、要約、分類

この表で最も目立つのは出力価格です。 Agent はコンテキストを読むだけでなく、計画、パッチ、説明、ログ、次のアクションを継続的に生成します。出力が多い場合、DeepSeek V4 Pro のプロモーション価格 $0.87 / M は、GPT-5.5 の $30 / M や Claude Sonnet 4.6 の $15 / M と比べて、差がどんどん広がります。

V4 Pro の通常出力価格 $3.48 / M で計算しても、GPT-5.4、GPT-5.5、Claude Sonnet / Opus より明らかに低い水準です。タスクを Flash で処理できるなら、出力価格はさらに $0.28 / M まで下がります。

キャッシュ入力の差はさらに極端です。 DeepSeek V4 Flash のキャッシュ入力は $0.0028 / M である一方、GPT-5.5 と Claude Opus 4.7 のキャッシュ入力はいずれも $0.50 / M です。これは同じ桁の話ではありません。同じコードリポジトリを繰り返し読む Agent にとって、この差は通常のチャットよりも重要です。

Agent タスクが特に影響を受ける理由

AI Agent は普通のチャットとは違います。普通のチャットはたいてい一問一答で、入力コンテキストは比較的限られています。 Agent タスクは、プロジェクトファイルを繰り返し読み、計画を生成し、ツールを呼び出し、結果を確認し、さらにコードを修正します。

この種のタスクには 2 つの特徴があります。

Token 消費が大きい；
繰り返しコンテキストが多い。

2 点目が非常に重要です。コードプロジェクトでは、モデルは同じファイル群、ディレクトリ構造、エラーログ、変更結果を何度も読みます。プラットフォームがキャッシュヒットをサポートしていれば、繰り返し入力のコストは大幅に下がります。

元記事では実際の体験として、DeepSeek V4 Pro と Flash を Claude Code のようなツールに接続し、プロンプトリポジトリを取得してローカル検索サイトを作らせた例が紹介されています。タスクは最終的に完了し、総コストは 8 毛強ほどで、そのうち Pro のキャッシュヒット率は 98.7% に達しました。

この例は現実的な問題を示しています。Agent タスクが「同じプロジェクトを中心に繰り返し作業する」ほど、キャッシュヒットの価値は高くなります。 Web サイト生成、bug 修正、フロントエンド修正が数毛から数元で済むなら、サブスクリプションプランの魅力は下がります。

簡略化したタスクで差を見積もることもできます。 1 回の coding agent タスクが次を含むと仮定します。

50 万 Token の入力。そのうち 80% がキャッシュヒット可能；
5 万 Token の出力；
ツール呼び出し、検索、プラットフォーム上乗せ分は計算せず、モデル Token コストだけを見る。

おおよそのコストは次のとおりです。

モデル	推定コスト
DeepSeek V4 Flash	約 $0.03
DeepSeek V4 Pro プロモーション価格	約 $0.09
DeepSeek V4 Pro 通常価格	約 $0.36
GPT-5.4 mini	約 $0.30
GPT-5.4	約 $1.01
GPT-5.5	約 $1.75
Claude Sonnet 4.6	約 $1.11
Claude Opus 4.7	約 $1.65

この見積もりは、DeepSeek がすべてのタスクで優れているという意味ではありません。モデル品質、ツール呼び出しの安定性、長文コンテキスト検索能力、コードスタイル、事実の信頼性は個別に評価する必要があります。ただしコスト面では、DeepSeek V4 は「Agent にもう数ラウンド走らせる」ことの限界コストをかなり低くしました。これにより開発者は、毎回 Token 請求を心配するのではなく、より長いワークフロー、より頻繁なセルフチェック、より多くの候補案を設計しやすくなります。

Coding Plan と Token Plan の違い

多くの AI 製品はいま、Coding Plan と Token Plan という 2 種類のプランを提供しています。

大まかな違いは次のとおりです。

Coding Plan は通常、主にプログラミング向け；
Token Plan は通常、STT、TTS、画像生成、検索、embedding、RAG など、より多くの機能を含む；
STT は音声から文字への変換；
TTS は文字から音声への変換；
Coding Plan はユーザーをプログラミング場面に制限しがちで、他の機能は別途購入が必要になることが多い。

ビジネスの観点では、Coding Plan はビュッフェに近いものです。ユーザーは固定料金を前払いし、ベンダーは大多数の人が枠を使い切らないことに賭けます。多く使う人も少なく使う人もいて、平均するとプラットフォームは利益を出せます。

しかし従量制の Token 価格が十分に低くなると、ユーザーは計算し始めます。なぜ必ずプランを買わなければならないのか。 1 か月の実際の利用コストが数元から十数元程度なら、40 元や 200 元のプランは必ずしも割に合いません。

値下げがサブスクリプションモデルを揺さぶる理由

サブスクリプションプランが成立するには前提があります。ユーザーが単発利用を高いと感じるか、毎回の呼び出しコストを計算したくないことです。 Token 価格が高いとき、プランは安心に見えます。 Token 価格がほとんど気にならないほど低くなると、従量課金のほうが自然になります。

DeepSeek V4 の値下げは、底のコストを見せたようなものです。

Agent タスクは非常に安くできる；
長文コンテキストは必ずしも使えないほど高くない；
キャッシュヒットでコストを大きく下げられる；
普通の開発者は固定サブスクリプションを必ずしも必要としない；
モデルの入口は「プラン型プラットフォーム」から「低価格 API」へ移り得る。

これは Coding Plan を提供するプラットフォームにとって不快な変化です。従量呼び出しのほうが安く自由だとユーザーが気づけば、ひとつのプラットフォームのプランに縛られる必要はありません。

Flash と Pro をどう選ぶか

DeepSeek V4 の実用的な考え方のひとつは、Flash と Pro を分担して使うことです。

Flash は高頻度、軽量、反復可能なタスクに向いています。

bug 修正；
フロントエンド作成；
スクリプト作成；
通常のコード理解；
長いコンテキスト内の一般的な情報整理；
大量のサブタスク実行。

Flash は安く、速く、同じく長いコンテキストをサポートします。日常的な coding agent では、多くのタスクで最初から Pro を使う必要はありません。

Pro は複雑な判断やフォールバックタスクに向いています。

複数ラウンドの計画；
複雑な Agent ワークフロー；
複数回の function call；
事実確認；
財務・経済リサーチ；
より強い知識と判断力が必要なコンテンツ生成；
高リスクなコード変更。

合理的な構成は、Flash が量をこなし、Pro がフォールバックを担当する形です。通常タスクはまず Flash で始め、長期計画、複雑な判断、事実確認、複数ツールの協調が必要になったら Pro に切り替える。こうすればコストを抑えつつ、モデル品質も保てます。

DeepSeek がこの価格を出せる理由

DeepSeek は多くの大手企業と事業構造が異なります。 EC、SNS、ショート動画、クラウドコンピューティング、スマートフォン、自動車、オフィススイート、OS、ブラウザ、大規模な企業向け SaaS エコシステムを持っていません。

つまり、ユーザーを完全なプラットフォーム内に閉じ込める必要がありません。安いテキストモデル能力だけを売ることができます。他の機能は、必要に応じてどこを呼び出してもよいのです。

大手企業のロジックは通常異なります。その Coding Plan や Token Plan を買うと、クラウド、検索、画像生成、音声、データベース、開発ツールのエコシステムへ引き込まれます。プランは単純にモデルを売るものではなく、ユーザーの入口を取りに行くものです。

DeepSeek の戦い方はより直接的です。テキストモデルの価格を下げ、Agent のデフォルトモデル入口になることを狙います。デフォルト入口を取れれば、多くの開発者とツールチェーンは自然にそれへ適応していきます。

オープンモデルとデフォルト入口

DeepSeek V4 がオープンモデル路線を維持するなら、サードパーティのクラウドベンダーやプラットフォームが自前でデプロイし、サービスを提供する可能性があります。 DeepSeek にとって、それは普及でもあり、同時に流量の分散でもあります。

低価格の公式 API の意味はここにあります。公式価格がすでに十分低ければ、他のプラットフォームがデプロイできたとしても、価格面で明確な優位を出すのは難しくなります。ユーザーは、デフォルトで安く安定した入口を直接使う傾向になります。

Agent ツールでは特にそうです。 Agent タスクは長文コンテキスト、キャッシュ、ツール呼び出し、安定したスループットに依存します。あるモデルがこれらの場面で十分安ければ、デフォルト選択肢になる可能性があります。

Coding Plan は完全に無用ではない

これは Coding Plan がすぐ消えるという意味ではありません。それに合うユーザーはまだいます。

もし一部のユーザーが本当に高頻度で、毎日プランの上限まで使うなら、固定サブスクリプションはまだ得かもしれません。ビュッフェと同じで、誰も元を取れないなら、ユーザーも買おうとはしません。

ただし問題は、ほとんどのユーザーがそのような極端な高頻度ユーザーではないことです。低頻度ユーザー、軽量な開発者、たまにスクリプトを書いたりプロジェクトを直したりする人には、従量課金のほうが向いています。 DeepSeek が従量コストを下げると、プランの魅力は弱まります。

今後は、より階層化された選択が起こりやすくなります。

高頻度のヘビーユーザーは Coding Plan を買い続ける；
普通のユーザーは低価格 API へ移る；
Agent ツールはタスクに応じて Flash / Pro を自動選択する；
プラットフォームのプランは、ワークフロー、IDE 統合、デプロイ、チーム管理、セキュリティ監査など、モデル以外の価値をより多く提供する必要がある。

まとめ

DeepSeek V4 の発表は、ベンチマークによって最大の衝撃を作ったわけではありません。本当に業界の期待を変えたのは、その後の値下げでした。

入力 Token とキャッシュヒット価格が非常に低くなると、AI Agent の利用コストは変わります。これまで高価に見えていた長文コンテキスト、コードプロジェクト分析、複数ラウンドのツール呼び出しが、今では数毛から数元の日常的な消費になる可能性があります。

これは Coding Plan と Token Plan のビジネスロジックを直接揺さぶります。ユーザーが従量課金で、モデルとツールを自由に組み合わせられ、さらにコストも十分低いなら、特定のプラットフォームプランに縛られる必要はありません。

DeepSeek V4 が今回本当に動かしたのは、モデル能力ランキングだけではなく、AI Agent のコスト構造とデフォルト入口をめぐる競争です。

参考情報：

NVIDIA、Nemotron 3 Nano Omni を発表：エージェント向けのオープンな全モーダル推論モデル

Fri, 01 May 2026 12:07:15 +0800

NVIDIA は Nemotron 3 Nano Omni を発表した。これはエージェントワークフロー向けに設計された、オープンな全モーダル推論モデルである。重点は単なるテキスト問答ではなく、言語、視覚、音声を同じ推論フレームワークに入れ、実際の作業フローに近い入力を扱えるようにすることにある。

位置付けとして、Nemotron 3 Nano Omni は AI Agent のための基盤モデルに近い。画面、文書、画像、音声、動画に含まれる情報を理解し、それを実行可能な推論結果へ変換できる。この能力は、コンピューター操作、文書インテリジェンス、動画理解、音声対話、カスタマーサポート、教育、企業プロセスの自動化に向いている。

モデル仕様

Nemotron 3 Nano Omni は MoE アーキテクチャを採用している。 NVIDIA が示している主な仕様は次の通り。

項目	情報
モデル名	`Nemotron 3 Nano Omni`
アーキテクチャ	MoE
パラメータ規模	30B total / 3B active
モダリティ	テキスト、画像、音声、動画
コンテキスト長	256K token
ライセンス	Apache 2.0
主なデプロイ方向	AI Agent、マルチモーダル推論、企業向けエージェント

ここで最も注目したいのは 30B-A3B だ。これはモデル全体では約 30B パラメータを持つが、各推論では約 3B パラメータだけを有効化するという意味である。能力と推論コストのあいだで折り合いを付ける設計であり、大きなエキスパート容量を保ちながら、実行時にはその一部だけを使う。

ただし、MoE の active params は、VRAM を 3B モデル相当で見積もってよいという意味ではない。完全にデプロイするには、エキスパート重み、KV cache、視覚/音声エンコーダーモジュール、コンテキスト長、推論フレームワークのオーバーヘッドを考慮する必要がある。

解決しようとしているのは単一モーダルの問題ではない

従来の大規模言語モデルは主にテキストを処理する。マルチモーダルモデルはそこからさらに画像理解をサポートする。一方で Nemotron 3 Nano Omni の狙いはもっと広く、テキスト、画像、音声、動画をまとめて推論に取り込む全モーダル入力を重視している。

これは Agent にとって重要だ。実際のエージェントタスクは、「ある文章を受け取って別の文章を生成する」だけではないことが多い。たとえば次のようなものだ。

画面上のボタン、表、ウィンドウを見る。
PDF、スクリーンショット、グラフ、Web ページを読む。
音声の説明や会議録音を聞く。
動画内の動作、場面、時系列を理解する。
それらの情報を統合して次の操作に変換する。

モデルが単一モーダルしか扱えない場合、Agent は複数の専用モデルを追加でつなぎ合わせる必要がある。全モーダルモデルの価値は、この接続コストを減らし、同じモデルでより複雑な環境入力を直接処理できる点にある。

コンピューター操作と文書インテリジェンス向け

NVIDIA は、Nemotron 3 Nano Omni がコンピューター操作に関連するタスクに使えることを特に挙げている。この種のタスクでは、モデルがユーザーインターフェースを理解する必要がある。

画面上にどのようなコントロールがあるか。
現在のウィンドウがどの状態にあるか。
次に対象となるボタンやメニューはどれか。
表、ダイアログ、入力欄の内容が何を意味するか。

これは、現在の AI Agent が実際に使われる場面で避けて通りにくい能力でもある。エージェントがオフィスソフト、ブラウザ、企業向け管理画面、開発ツールの操作を支援するなら、API ドキュメントを読むだけではなく、画面を理解できなければならない。

文書インテリジェンスも同じ発想に近い。企業資料には、テキスト、表、画像、スキャンページ、グラフが混在していることが多い。全モーダルモデルはそれらを同じコンテキストに入れて理解できるため、契約書レビュー、レポート分析、請求書処理、ナレッジベースQA、プロセス自動化に向いている。

音声と動画が Agent をより現実の場面に近づける

音声と動画の入力は、Agent の応用範囲を大きく広げる。

音声の場面には次のようなものがある。

会議録音の要約。
カスタマーサポート通話の分析。
音声指示の理解。
教育・研修コンテンツの整理。

動画の場面には次のようなものがある。

教学動画の理解。
セキュリティや産業点検。
画面録画の分析。
操作フローの振り返り。
複数ステップのタスクにおける時系列判断。

これらのタスクを文字起こしだけで処理すると、多くの視覚情報や時系列情報が失われる。全モーダルモデルなら、音声、画面、テキストの手がかりを直接組み合わせ、Agent により完全な環境認識を与えられる。

デプロイとエコシステム

NVIDIA は Nemotron 3 Nano Omni をオープンなエコシステムに置いており、モデルは Apache 2.0 ライセンスを採用している。これは開発者や企業にとって重要だ。実験、統合、二次開発のライセンス上のハードルを下げるからである。

NVIDIA の説明を見ると、このモデルは同社の推論エコシステムとも強く結び付いている。企業ユーザーが実際にデプロイする際には、通常次のような点が気になる。

NVIDIA GPU 上で効率よく推論できるか。
長いコンテキストとマルチモーダル入力をサポートするか。
既存の Agent フレームワークに接続できるか。
社内文書、音声・動画、UI スクリーンショットを処理できるか。
プライベート環境にデプロイできるか。

NVIDIA はこのモデルのスループット面での優位性を強調しており、同種のオープンな全モーダル推論モデルに対して最大 9 倍に達するとしている。この数字の実際の価値は、具体的なハードウェア、コンテキスト長、入力モダリティ、推論フレームワークとあわせて見る必要がある。ただし方向性は明確だ。 NVIDIA はオープンなマルチモーダルモデルと自社の推論インフラを組み合わせ、企業向け Agent の場面へ押し出そうとしている。

向いている用途

Nemotron 3 Nano Omni は、次のようなタスクにより向いている。

テキスト、画像、音声、動画を同時に理解する必要がある Agent。
企業内の文書インテリジェンスとナレッジベースQA。
スクリーンショットや Web インターフェースに基づくコンピューター操作。
会議、カスタマーサポート、教学コンテンツのマルチモーダル分析。
動画理解、ワークフローの振り返り、時系列判断。
オープンライセンスとプライベートデプロイを必要とするチーム。

すべての一般ユーザーに向いているとは限らない。ローカルチャット、コード補完、簡単なQAだけなら、単一モーダルの言語モデルのほうが軽く、速く、省リソースである可能性が高い。 Nemotron 3 Nano Omni の価値は、主に複雑な入力とマルチモーダルな Agent ワークフローにある。

AI Agent にとって何を意味するのか

AI Agent が本当に仕事の現場に入っていくには、文字を書けるだけでは足りない。インターフェースを理解し、音声を聞き取り、文書を読み、動画内の変化を把握し、それらを次の行動へ変換する必要がある。

Nemotron 3 Nano Omni の意味はそこにある。単にモデルのパラメータを大きくしたのではなく、Agent が直面する複数種類の入力を一つの推論モデルに統合している。これにより、開発者はチャットウィンドウ中心のアプリではなく、現実のタスクに向いたエージェントを作りやすくなる。

この角度から見ると、NVIDIA がこのモデルを発表したポイントは「また一つマルチモーダルモデルが出た」ということだけではない。オープンモデル、GPU 推論、企業向け Agent、プライベートデプロイを引き続き接続しようとしている点にある。今後本当に注目すべきなのは、具体的な Agent フレームワーク、企業ワークフロー、ローカルデプロイの中でどのような実力を見せるかだ。

参考ソース：

NVIDIA 技術ブログ：NVIDIA Nemotron 3 Nano Omni

FinceptTerminal：オープンソース金融端末、量的研究、AI Agent ワークベンチ

Fri, 01 May 2026 03:47:18 +0800

FinceptTerminal は Fincept Corporation が公開しているオープンソースの金融端末プロジェクトです。

README の説明を見る限り、これは単なる相場表示パネルではありません。金融分析、量的研究、取引ワークフロー、AI Agent に向けた総合的なデスクトッププラットフォームです。v4 は C++20 と Qt6 でネイティブデスクトップアプリケーションとして構築され、同時に Python エコシステムを組み込み、分析、スクリプト、機械学習、金融モデリングを支援します。

例えるなら、オープンソースの金融研究ワークベンチに近いものです。片側でデータソースに接続し、もう片側でチャート、ポートフォリオ、量的分析、取引、情報分析、自動化ワークフローを扱います。

最初に明確にしておくべき点があります。この種のツールは研究、分析、教育、内部ツール構築には使えますが、出力をそのまま投資助言として扱うべきではありません。金融市場にはリスクがあり、データ、モデル、戦略、執行はすべて独立した検証が必要です。

何を解決するのか

金融研究は、多くの場合いくつものツールに分散しています。

相場データは別のソフトウェアにある
研究コードは Jupyter にある
チャートは別のツールにある
ポートフォリオ分析はスプレッドシートにある
取引記録は証券会社のシステムにある
ニュースや情報はブラウザにある
AI 分析はチャット画面にある

このやり方でも作業はできますが、共同作業と再現性は難しくなります。

FinceptTerminal が解決しようとしているのは、これらの能力をひとつのデスクトップ端末に統合し、同じ環境でデータ接続、分析、モデリング、可視化、Agent 連携、取引関連フローを完結できるようにすることです。

目的はすべての専門システムを置き換えることではなく、拡張可能なオープンソース金融端末の土台を提供することです。

技術アーキテクチャ

README では、v4 が C++20 と Qt6 を採用していると説明されています。

つまり、これは純粋な Web パネルではなく、ネイティブデスクトップアプリケーションです。金融端末において、ネイティブアプリにはいくつかの利点があります。

UI の応答がより安定しやすい
複雑なウィンドウや複数パネル構成に向いている
ローカルファイルやシステムリソースを扱いやすい
高性能コンポーネントを組み込みやすい
長時間動作するデスクトップワークフローに向いている

同時に、このプロジェクトは Python も組み込んでいます。

これは重要です。金融研究や量的分析では、Python は事実上の主要言語のひとつです。データ分析、機械学習、統計、バックテスト、チャート、金融モデリングは Python エコシステムと切り離せません。C++/Qt がアプリケーションフレームワークとデスクトップ体験を担当し、Python が研究と拡張性を担当する。この組み合わせはとても実用的です。

データコネクタ

README では、このプロジェクトが 100+ のデータコネクタを提供すると説明されています。

金融端末の価値は、かなりの部分がデータ接続に依存します。データがなければ、どれほど優れた UI やモデルも空の器にすぎません。

この種のコネクタは、通常さまざまなソースをカバーできます。

市場相場
マクロ経済データ
企業財務
ニュースとインテリジェンス
取引所データ
暗号資産データ
研究用データソース
内部またはカスタム API

ユーザーにとって、データコネクタの意味は「CSV をダウンロードし、手作業で整形し、再度インポートする」流れを減らし、分析をよりリアルタイムかつ自動化に近づけることです。

ただし、金融データでは品質、ライセンス、遅延、カバー範囲、費用がいずれも重要です。どのデータソースを使う場合でも、事前に許諾条件と利用範囲を確認する必要があります。

AI Agents モジュール

このプロジェクトは AI Agents を強調しています。ここが従来型の金融端末と異なる点でもあります。

従来の端末は、人が画面を操作し、人がデータを見て、人が判断するものが中心でした。AI Agent が加わると、ツールはより多くの補助作業を担えるようになります。

市場情報を要約する
財務報告や公告を説明する
研究サマリーを生成する
データの絞り込みを手伝う
分析スクリプトの作成を補助する
取引または研究ワークフローを整理する
複数モジュール間でコンテキストを受け渡す

これは AI がアナリストやトレーダーを代替できるという意味ではありません。

より適切な位置づけは、AI Agent が反復的な整理作業を減らし、初期分析や対話的な問い合わせを支援するというものです。重要な結論には、引き続きデータ検証、モデル検証、人間の判断が必要です。

量的研究機能

FinceptTerminal は量的研究も対象にしています。

量的研究には通常、次のような作業が含まれます。

データクリーニング
ファクター構築
戦略仮説
バックテスト
リスク評価
ポートフォリオ最適化
取引コスト推定
結果の可視化

データ接続、Python 分析、チャート、ワークフローをひとつの端末に統合できるなら、量的研究には大きな助けになります。研究者はひとつの環境で、データから戦略検証まで段階的に進められます。

ただし、量的研究で最も危険なのは「効いているように見える」ことです。サンプル外検証、取引コスト、スリッページ、生存者バイアス、過剰適合、データリークを厳密に処理していない戦略は、バックテストがどれほど綺麗でも信頼できません。

そのため、この種のツールは研究プラットフォームとして扱うべきであり、自動的に利益を生む機械として扱うべきではありません。

QuantLib と金融モデリング

README では QuantLib 関連の機能にも触れています。

QuantLib は金融工学でよく使われるオープンソースライブラリで、金利、債券、オプション、デリバティブ価格評価、カーブ構築、リスク計算などによく使われます。

これは FinceptTerminal が株価を見るだけのものではなく、より専門的な金融モデリング領域もカバーしようとしていることを示しています。

この種の機能は、次の用途に向いています。

金融工学の学習
デリバティブ価格評価の実験
カーブとリスク指標の計算
投資ポートフォリオのリスク分析
研究モデルのプロトタイプ検証

ただし、金融モデリング自体のハードルは高いです。モデルパラメータ、市場仮定、データソース、価格評価ロジックはすべて結果に影響します。ツールは操作コストを下げられますが、専門的な判断を代替することはできません。

ノードワークフロー

README ではノード式ワークフローにも触れています。

ノードワークフローは、複雑なタスクを視覚的なプロセスに分解するのに向いています。

データを読み込む
データをクリーニングする
モデルを実行する
チャートを生成する
AI 分析を起動する
レポートを出力する
通知を送る

金融領域において、この方式には二つの利点があります。

第一に、プロセスが可視化されます。複雑な分析がスクリプトの山の中だけに隠れるのではなく、ユーザーはデータがどう流れるかを見られます。

第二に、自動化に向いています。繰り返し行う研究フローを保存し、再利用し、調整できます。

今後、Python スクリプト、データコネクタ、Agent、レポートシステムと組み合わされれば、この種のノードワークフローは金融端末の中で価値あるモジュールになるでしょう。

取引とポートフォリオ管理

このプロジェクトは取引とポートフォリオ関連機能にも触れています。

この領域では特に慎重さが必要です。

ポートフォリオ管理は、資産エクスポージャー、リターン、ドローダウン、ボラティリティ、相関、リスク集中度を理解する助けになります。取引モジュールは、注文、口座、執行、記録に関わる可能性があります。

しかし、実取引に触れる場合は、次の点を必ず考慮しなければなりません。

データ遅延
注文執行リスク
API 権限
取引コスト
スリッページ
流動性
リスク管理上の制限
監査とログ
戦略の誤発火

開発環境や研究環境の取引機能を、そのまま本番レベルの取引システムと同一視すべきではありません。ライブ取引に接続する前には、厳格なテスト、権限分離、リスク管理機構、人手によるレビューが必要です。

Bloomberg Terminal との違い

多くの金融端末プロジェクトは Bloomberg Terminal と比較されます。

しかし、両者の位置づけは異なります。

Bloomberg Terminal の価値はソフトウェア画面だけではありません。次の要素も含まれます。

データカバレッジ
データライセンス
ニュースネットワーク
取引エコシステム
カスタマーサポート
金融機関向けワークフロー
長年蓄積された業界からの信頼

FinceptTerminal は、オープンソースの金融端末フレームワーク兼研究プラットフォームに近い存在です。強みは、拡張性、カスタマイズ性、ローカライズ性、そして Python や AI ワークフローとの連携です。

Bloomberg の無料代替品として単純に理解すべきではありません。

より妥当な見方はこうです。金融端末がどのように構築されるのかを研究したい場合、あるいは自分の金融分析ワークベンチを作りたい場合、FinceptTerminal はオープンソースの出発点を提供してくれます。

ライセンスと商用利用の境界

README では、このプロジェクトが AGPL と商用ライセンスモデルを採用していると説明されています。

AGPL はネットワークサービスや派生作品に対して明確な要件を持ちます。学習、研究、個人実験だけであれば通常大きな問題にはなりにくいですが、商用製品、内部プラットフォーム、外部サービスに改造する予定があるなら、ライセンスを丁寧に読む必要があります。

特に金融ツールは企業内部システムに入ることがよくあります。その場合、オープンソースライセンス、商用ライセンス、データライセンス、モデルライセンスをまとめて確認すべきであり、コードが動くかどうかだけを見るべきではありません。

誰が注目すべきか

FinceptTerminal は次のような人に向いています。

金融端末アーキテクチャを研究したい開発者
量的研究や金融工学の実験をしている人
Python の分析機能をデスクトップツールに組み込みたい人
AI Agent + 金融ワークフローを探求したい人
内部向け金融分析プラットフォームを作りたいチーム
C++/Qt による金融アプリ開発を学びたい人

数銘柄の株価を見るだけなら、一般的な相場ソフトのほうが簡単かもしれません。

金融端末がデータ、チャート、モデル、Agent、取引、ワークフローをどう統合するのかを理解したいなら、このプロジェクトはより研究する価値があります。

利用時の注意点

第一に、研究と取引を区別することです。

研究環境では実験や失敗を許容できますが、取引環境ではできません。検証されていない研究ツールを実口座に接続してはいけません。

第二に、データライセンスを重視することです。

金融データは、勝手に取得して商用利用できるものではありません。特に相場、ニュース、財務、取引所データでは、データソースごとに異なるライセンス条件があります。

第三に、AI Agent を過信しないことです。

AI は情報整理を補助できますが、金融上の結論は必ずデータ、モデル、リスク、事実検証に戻す必要があります。

第四に、セキュリティに注意することです。

ツールが口座、API key、取引インターフェース、内部データに接続する場合、鍵管理、権限分離、ログ、ネットワーク境界を適切に扱う必要があります。

第五に、オープンソースライセンスを理解することです。

AGPL は商用利用とサービス化に重要な影響を持ちます。プロダクト化する前に、ライセンス問題を先に整理すべきです。

参考

Fincept-Corporation/FinceptTerminal

最後に

FinceptTerminal で注目すべき点は、金融端末、Python による量的研究、AI Agents、データコネクタ、ノードワークフローを、ひとつのオープンソースデスクトッププラットフォーム構想の中に置いていることです。

これは専門的な金融端末や実取引システムを直接置き換える完成品というより、金融技術研究と内部ツール構築の出発点として向いています。

mattpocock/skills：AI コーディング Agent 向けの実用スキル集

Fri, 01 May 2026 03:43:20 +0800

mattpocock/skills は、Matt Pocock が公開している AI コーディング agent skills のコレクションです。

これは完全なアプリケーションでも、新しいチャットクライアントでもありません。AI コーディングアシスタントに使わせるための作業スキル集です。考え方は実用的です。AI コーディングでよく起こる問題を小さなスキルに分解し、Agent が適切なタスクで呼び出せるようにします。毎回巨大なプロンプトで無理に支えるのではありません。

Claude Code、Codex、Cursor、または類似の AI コーディングツールをよく使うなら、この種の skills は注目する価値があります。AI コーディング体験に本当に影響するのは、「モデルがコードを書けるか」だけではなく、自分の作業方法に沿ってタスクを進められるかだからです。

解決する問題

AI コーディングアシスタントは強力ですが、問題も起こしやすいです。

よくある状況は次のとおりです。

要件を理解する前にコード変更を始める
一度に多すぎるファイルを変更する
説明は多いが、実際に有用な行動が少ない
エラー後に場当たり的に試す
テストやチェックをすぐに実行しない
プロジェクト内の既存パターンを無視する
タスク完了のために不要な抽象を導入する
コードを書いた後に本当にリスクを review しない

これらは必ずしもモデル能力不足ではありません。ワークフローが十分に制約されていないことが原因の場合も多いです。

mattpocock/skills の価値は、こうした失敗パターンを再利用可能な操作方法に分解し、Agent が場面に応じてより経験あるエンジニア協作者のように振る舞えるようにすることです。

Skills とは何か

AI Agent の文脈では、skill は再利用可能なタスク説明、作業方法、専門的なフローとして理解できます。

必ずしもコードプラグインである必要はなく、外部サービスを呼び出す必要もありません。多くの場合、skill は明確なルールセットです。

いつ使うか
まず何をするか
何をしないか
何を出力するか
タスク完了をどう判断するか

これは通常のプロンプトテンプレートに似ていますが、粒度は「タスク能力」に近いものです。

通常のプロンプトテンプレートは、ユーザーが毎回一時的にコピーして貼り付けるものです。Skills は agent ツールボックスの一部として、Agent がタスクに応じて適切なフローを選ぶ形に向いています。

小さく組み合わせ可能である理由

README では、これらの skills が小さく組み合わせ可能であることを強調しています。

これは重要な方向性です。

1 つの skill がすべてを担当しようとすると、すぐに新しい巨大プロンプトになります。長く、曖昧で、保守しにくいものです。小さなスキルの利点は境界が明確なことです。

たとえば 1 つの skill は次のようなことだけに集中できます。

先に計画する
TypeScript エラーを修正する
テストを実行し、結果に基づいて修正する
コード review を行う
プロジェクト規約を要約する
プロンプトを改善する
不要な抽象を取り除く

これらのスキルはタスクに応じて組み合わせられます。単純なタスクなら 1 つ、複雑なタスクなら複数をつなげます。

これは実際のエンジニアリング作業に近いです。すべての問題を同じフローで処理するのではなく、問題に応じてツールを選びます。

エンジニアの制御を残す

このリポジトリの重要な方向性の一つは、エンジニアが制御権を持ち続けることです。

AI コーディングは、2 つの極端に寄りやすいです。

1 つ目は完全に手動です。AI は数行のコードを書く手伝いをするだけで、コンテキスト、計画、検証はすべて自分が監視します。

2 つ目は完全に放任です。タスクを Agent に投げ、大きく変更させ、最後にレビューしづらい diff と向き合います。

skills はその中間に、より安定した位置を作ります。

AI により多くの反復フローを任せつつ、ルールで制限します。

タスクを理解してから手を動かす
関連ファイルを読んでから変更する
変更範囲を制御可能にする
不確実な場合は報告する
変更後に検証する
見せつけるために無関係なコードをリファクタリングしない

これは AI を弱めるのではありません。AI の行動を人間がレビューし、引き継ぎやすくするものです。

アラインメント問題

AI コーディング失敗の最初の種類は、アラインメント失敗であることが多いです。

ユーザーが求めているのは具体的な変更ですが、Agent はそれを大きなリファクタリングとして理解することがあります。ユーザーは Bug 修正だけを望んでいるのに、スタイルまで変更することがあります。既存アーキテクチャに従ってほしいのに、新しいパターンを導入することもあります。

Skills はタスク開始時に Agent に次のことをさせられます。

目的を言い直す
影響範囲を見つける
既存の実装パターンを識別する
計画を出す
何をしないかを明確にする

これはエンジニアが作業開始前に行うセルフチェックに似ています。

Agent がタスク境界を明確にしないままコードを書き始めると、後でどんどんズレやすくなります。

フィードバックループ問題

AI のコード生成は一回だけに頼るべきではありません。

実際の開発では、フィードバックループが重要です。

小さく変更する
テストまたは型チェックを実行する
エラーを見る
修正する
再検証する

多くの Agent は途中のフィードバックを飛ばすために失敗します。一度に多くを変更し、感覚で「動くはず」とまとめます。

Skills はフィードバックループを明示的にフローへ書き込めます。たとえば Agent に次のことを要求できます。

変更後に関連チェックを実行する
チェックが失敗したら、まずエラーメッセージを読む
無関係なファイルを盲目的に変更しない
各修正後に再検証する
最後に検証結果を報告する

これにより AI コーディングは、一回限りの作文ではなく本物のデバッグに近づきます。

アーキテクチャ制御問題

AI は抽象を生成するのが得意で、過剰に抽象を生成するのも得意です。

小さな要件を満たすために、サービス層、ヘルパー関数、設定オブジェクト、型ラッパー、アダプターを新しく作り、最終的に要件そのものより複雑なコードにしてしまうことがあります。

この問題は大規模プロジェクトで特に危険です。AI が生成した抽象は「専門的」に見えますが、既存のプロジェクトスタイルに合わず、保守コストを増やす可能性があります。

良い skills は Agent に次のことを思い出させます。

既存パターンを優先する
不必要な新しい抽象を導入しない
無関係な領域をついでにリファクタリングしない
変更をタスク規模に合わせる
コードを理解してから構造を設計する

これにより、「見た目はエンジニアリングっぽいが実際は保守しにくい」出力を減らせます。

Review skill が重要な理由

コードを書くこととコードを review することは別の状態です。

Agent がコードを書くとき、自分の実装が成立することを説明しがちです。なぜこの変更で動くかは説明しますが、必ずしもリスクを探すわけではありません。

Review skill の意味は、Agent の役割を切り替えることです。

潜在 Bug を探す
振る舞いの回帰を探す
足りないテストを探す
境界条件を探す
複雑度の上昇を探す
既存規約と不一致な箇所を探す

これは AI コーディングで重要です。AI はコードを高速に生成するため、review がないとユーザーは大量の diff に埋もれやすくなります。

良い review 出力は、まず問題を列挙すべきです。先に実装を褒める必要はありません。エンジニアがその変更をマージできるか判断する助けになるべきです。

通常の rules ファイルとの違い

多くの AI コーディングツールは rules、instructions、memory をサポートしています。

これらのファイルは通常、長期ルールを記録します。

プロジェクト技術スタック
命名規約
テストコマンド
変更してはいけないディレクトリ
回答スタイルの好み

Skills はよりタスクフローに寄っています。

rules は Agent に「長期的にどう振る舞うべきか」を伝えます。skills は Agent に「この種類のタスクをどう実行すべきか」を伝えます。

両方を一緒に使うのがよいです。

たとえば rules にプロジェクトが pnpm test を使うと書き、review skill で変更後にテストカバレッジを確認するよう求めます。すると Agent はコマンドだけでなく、いつ使うべきかも理解します。

向いている場面

mattpocock/skills のようなリポジトリは次の場面に向いています。

AI コーディングツールを頻繁に使う
Agent に実コードベースを扱わせる
AI の範囲外変更を減らしたい
Agent により積極的に結果を検証させたい
自分のエンジニアリング習慣を skills にしたい
他人の agent workflows 設計を学びたい
一時的なプロンプト群を保守可能な skill 集合に整理したい

たまに AI に小さな関数を書かせるだけなら、skills を専用に維持する必要はないかもしれません。

しかし AI を長期的な開発パートナーとして扱うなら、skills は徐々に重要になります。Agent に再利用可能な作業方法を持たせるものだからです。

このリポジトリから学べること

各 skill を直接使わなくても、このリポジトリからいくつか学べます。

第一に、失敗パターンを書き出すことです。

AI が間違えたときにその場で不満を言うだけではなく、よく間違えるパターンをルールに整理します。次回は skill に先回りして防がせます。

第二に、スキルは短くすることです。

1 つの skill は、1 つの明確な問題を解くのが理想です。短いほど正しく呼び出されやすく、保守しやすくなります。

第三に、出力形式を明確にすることです。

Agent に先に計画を列挙し、次に実行し、最後に検証結果をまとめてほしいなら、その構造を明確に書きます。曖昧な要求は曖昧な結果を生みます。

第四に、人間が引き継ぐポイントを残すことです。

良い skill は AI を一人で遠くまで走らせるべきではありません。不確実性、影響範囲の拡大、テスト失敗、プロダクト判断が必要な場合は、止まって状況を説明させるべきです。

利用時の注意

第一に、すべてを skill 化しないことです。

skills が多すぎるとシステムは複雑になり、Agent もどれを選ぶべきか分からなくなります。まずは頻度が高く、痛みの大きい場面から始めるのがよいです。

第二に、skills は反復改善が必要です。

最初に書いた skill が良いとは限りません。AI の実行結果を見て、少しずつ削り、追加し、書き直します。

第三に、skill にエンジニアリング判断を置き換えさせないことです。

Skill はフローを改善できますが、実装の正しさを保証するものではありません。テスト、review、ビルドチェック、人間の判断は依然として重要です。

第四に、Agent ごとの差に注意することです。

Claude Code、Codex、Cursor、Copilot は instructions、skills、rules のサポート方法が異なります。同じ考え方は再利用できますが、具体的な形式はツールに合わせて調整する必要があります。

参考

mattpocock/skills

最後に

mattpocock/skills が注目に値するのは、その中の一つの魔法のプロンプトではありません。エンジニアリング経験を小さなスキルに分解し、Agent に場面ごとに組み合わせて使わせるという実用的な AI コーディングの考え方です。

AI コーディングがたまの補助から日常ワークフローになると、skills は Agent を制約し、エンジニアの制御を保ち、フィードバック品質を高める重要な道具になります。

free-claude-code：プロキシで Claude Code を OpenRouter、DeepSeek、ローカルモデルへ接続する

Fri, 01 May 2026 03:41:49 +0800

free-claude-code は、Claude Code 向けの Anthropic-compatible proxy です。

考え方は Claude Code を破解することでも、公式の無料 Claude サービスを提供することでもありません。ローカルで Anthropic API の形に互換性を持つプロキシサービスを起動し、Claude Code からのリクエストを他のモデルバックエンドへ転送します。README では NVIDIA NIM、OpenRouter、DeepSeek、LM Studio、llama.cpp、Ollama などが挙げられています。

簡単に言うと、Claude Code のターミナル体験は好きだが、モデルリクエストは別の provider やローカルモデルへ接続したい、という問題を解決するものです。

解決する問題

Claude Code の対話体験は開発タスクに向いています。

ターミナル内でコードを読み、ファイルを変更し、コマンドを実行し、プロジェクトコンテキストに基づいてタスクを進められます。ただし、多くのユーザーは常に同じモデルバックエンドを使いたいとは限りません。

OpenRouter 上の異なるモデルを試したい
DeepSeek のようなモデルでコストを下げたい
リクエストをローカル Ollama に接続したい
LM Studio や llama.cpp でローカルモデルを動かしたい
開発環境でプロキシ入口を統一したい
Claude Code ワークフロー内で異なるモデルの挙動を比較したい

free-claude-code の位置づけは、Claude Code とこれらのモデルサービスの間に互換プロキシを置くことです。

Claude Code は Anthropic 風にリクエストを送り続け、プロキシがそのリクエストを異なるバックエンドへ適配します。

仕組み

3 層構造として理解できます。

フロントエンドは Claude Code
中間層は free-claude-code プロキシ
バックエンドは OpenRouter、DeepSeek、ローカルモデル、または他のモデルサービス

Claude Code は、自分が Anthropic-compatible API にアクセスしていると考えます。

プロキシはリクエストを受け取り、設定に応じて target provider を選び、必要なフィールドを変換し、応答を Claude Code に返します。

この構造の利点は、Claude Code 自体を変更する必要がなく、すべてのモデルサービスが Claude Code をネイティブにサポートする必要もないことです。プロキシがインターフェースを合わせられれば、より多くのモデルを同じワークフローへ接続できます。

対応バックエンド

README に挙げられている方向は次のとおりです。

NVIDIA NIM
OpenRouter
DeepSeek
LM Studio
llama.cpp
Ollama

これらのバックエンドは、異なる利用スタイルを表しています。

OpenRouter はモデル集約入口に近く、さまざまな商用モデルやオープンソースモデルを試せます。

DeepSeek は、中国語能力、コード能力、コストを重視する人に向いています。

LM Studio、llama.cpp、Ollama はローカルモデル寄りです。自分のマシンや社内環境でモデルを動かし、外部 API 依存を減らし、オフライン実験をしやすくします。

NVIDIA NIM は、企業や GPU 推論デプロイの場面により向いています。

なぜ Anthropic-compatible proxy なのか

Claude Code はもともと Anthropic のインターフェースとモデル習慣を前提に設計されています。

他のモデルへ接続しようとすると、最初に問題になるのはインターフェースの違いです。

リクエストフィールドが違う
モデル名が違う
streaming 形式が違う
tool use の表現が違う
エラー応答形式が違う
token とコンテキスト制限が違う

プロキシ層の価値はここにあります。

Claude Code 側から見えるインターフェースを Anthropic に近い形に保ち、バックエンド側で適配します。ユーザーにとっては、一度プロキシを設定すれば、同じ Claude Code ワークフローの中で異なるモデルを試せます。

向いている場面

free-claude-code は次のような場面に向いています。

Claude Code のターミナルワークフローを使いたい
非 Anthropic モデルを Claude Code 内で試したい
モデル呼び出しコストを下げたい
Claude Code を OpenRouter に接続したい
DeepSeek などの互換モデルサービスに接続したい
Ollama、LM Studio、llama.cpp でローカルモデルを使いたい
チーム用に統一されたモデルプロキシ入口を用意したい

公式 Claude Code を普通に使っていて、モデル提供者、コスト、ローカルデプロイに特別な要求がないなら、この種のプロキシは必須ではありません。

しかし、頻繁にモデルを比較したり、Claude Code をローカルやサードパーティーモデルへ接続したいなら、この種のツールは便利です。

OpenRouter や Ollama を直接使う場合との違い

OpenRouter、Ollama、LM Studio を直接使う場合、通常はモデルとチャットするか、API 経由でモデルを呼び出します。

free-claude-code の目的はそれらのサービスを置き換えることではなく、Claude Code という開発ワークフローへ接続することです。

違いは次の点にあります。

Claude Code のターミナル体験をそのまま使える
AI がコードリポジトリを中心にタスクを実行できる
モデルバックエンドを別 provider に切り替えられる
ローカルモデルも Claude Code ワークフローへ入れられる
設定がプロキシ層に集中し、各ツールを個別に変えなくてよい

つまり、新しいチャットクライアントではなくブリッジに近いものです。

ローカルモデルで注意すべきこと

Claude Code をローカルモデルへ接続するのは魅力的ですが、現実的な制限もあります。

第一に、モデル能力の差です。

Claude Code のタスクは単なるチャットではありません。コード理解、変更計画、ファイル編集、コマンド出力処理を含みます。ローカルの小さなモデルがこれらを安定してこなせるとは限りません。

第二に、コンテキストウィンドウです。

コードタスクはコンテキストを多く使います。モデルのコンテキストが小さいと、ファイルを読み切れない、制約を見落とす、多段階タスクで背景を失う、といった問題が起きます。

第三に、tool use の互換性です。

Claude Code ワークフローはツール呼び出しと構造化動作に依存します。バックエンドモデルがチャットできても、ツール呼び出しプロトコルに従うのが得意とは限りません。

第四に、速度とハードウェアです。

ローカルモデルの速度はマシン構成、量子化方式、モデルサイズに依存します。コードタスクで応答が遅すぎると、体験は大きく下がります。

そのため、ローカルモデルは実験、低リスクタスク、特定場面に向いています。複雑なコードタスクでは、モデル能力を見て慎重に選ぶ必要があります。

利用上の境界

この種のプロジェクトはタイトルで誤解されやすいので、境界を明確にしておく必要があります。

第一に、これは公式 Claude Code の無料枠ではありません。

Claude Code のリクエストを他のモデルバックエンドへ転送するだけです。OpenRouter、DeepSeek、NVIDIA NIM、その他 API を使う場合は、それぞれの価格、クォータ、利用規約に従う必要があります。

第二に、認可を回避するためのツールではありません。

どのプロキシツールを使う場合でも、Claude Code、モデル提供者、プロジェクト自体のライセンスや利用規約を守るべきです。公式制限を回避する手段として理解しないでください。

第三に、プロキシはリクエスト内容を処理します。

コード、コマンド出力、プロジェクトコンテキストがプロキシとバックエンドサービスを通る可能性があります。デプロイ時にはログ、キー、ネットワーク、プライバシー境界を考える必要があります。会社コードや機密プロジェクトでは、制御された環境を使うべきです。

第四に、モデルごとの挙動差は大きいです。

同じ Claude Code 操作でも、モデルを替えるとまったく異なる動作になることがあります。すべてのモデルが Claude を置き換えられると考えない方がよいです。

LiteLLM などのプロキシとの関係

考え方として、free-claude-code は「互換インターフェースプロキシ」に属します。

この種のツールの共通目標は、上位アプリケーションと下位モデルサービスの結合を減らすことです。上位アプリケーションは比較的統一されたインターフェースだけを見ればよく、下位 provider は設定で切り替えられます。

プロジェクトによって重点は異なります。汎用モデルゲートウェイ寄りのものもあれば、OpenAI-compatible API 寄りのものもあり、Claude Code のようなツール向けに特化しているものもあります。

free-claude-code が注目に値するのは、汎用チャットプロキシではなく、Claude Code を直接ターゲットにしている点です。

向いているユーザー

ある程度自分で調整できるユーザーに向いています。

Claude Code に慣れている
API key と model provider の設定方法を知っている
プロキシサービスの起動と環境変数を理解できる
ネットワーク、ポート、モデル名、streaming 問題を調査できる
コードタスクで異なるモデルの挙動を比較したい

開箱即用だけを求めるなら、公式設定の方がたいてい簡単です。

プロキシを立て、モデルを切り替え、パラメータを調整し、Claude Code をより多くのモデル環境へ接続したいなら、このプロジェクトは研究する価値があります。

参考

Alishahryar1/free-claude-code

最後に

free-claude-code の価値は「free」という言葉ではなく、Claude Code とより多くのモデルバックエンドの間に橋を架けることです。

Claude Code の開発体験を保ちながら、OpenRouter、DeepSeek、ローカルモデル、企業向け推論サービスを試したいとき、このような Anthropic-compatible proxy は役に立ちます。

Compound Engineering Plugin：AI コーディングを計画、実行、レビューの工程ループにする

Fri, 01 May 2026 03:15:39 +0800

Compound Engineering Plugin は、Every Inc が公開している AI コーディングワークフロープラグインです。

注目しているのは「AI により速くコードを書かせること」ではありません。AI コーディングを、よりエンジニアリングチームに近いループへ入れることです。まず計画し、次に実装し、その後レビューし、最後に経験を蓄積します。Claude Code、Codex、Cursor、Copilot のようなツールをよく使う人にとって、この種のプラグインはプロンプト問題ではなくワークフロー問題を解決します。

AI コーディングツールは強力になっていますが、実プロジェクトで難しいのはコード生成そのものではありません。AI に継続してプロジェクトルールを守らせ、タスク境界を理解させ、同じ間違いを繰り返させず、複数回の反復でコンテキストを蓄積させることです。

解決する問題

多くの人は AI コーディングアシスタントを次のような流れで使います。

要件を直接説明する
AI にコードを変更させる
結果が動くか確認する
エラーが出たら追加説明する
次のタスクでまた背景を最初から説明する

小さなタスクならこれで十分なこともあります。しかし複雑なプロジェクトでは問題が起こりやすくなります。

要件を整理しないまま AI が編集を始める
コード変更後に体系的な review がない
プロジェクト規約がユーザーの繰り返しの注意に依存する
同じ種類のミスが次回も起こる
複数の Agent ツール間で統一した作業方法がない
経験が再利用可能なルールとして蓄積されない

Compound Engineering Plugin が解決したいのは、この種の問題です。AI コーディングを複数の段階に分け、Agent を単なるコマンド実行者ではなく、より完全なエンジニアリングプロセスの参加者にします。

Compound Engineering とは何か

プロジェクト README の説明から見ると、Compound Engineering は AI 支援ソフトウェア開発の方法と理解できます。

重視するのは次のループです。

計画：目的を理解し、タスクを分解し、方針を確認する
実行：計画に沿ってコードを変更し、コマンドを実行し、問題を処理する
レビュー：実装品質、リスク、テストカバレッジを確認する
学習：経験を後続で再利用できるルールとして蓄積する

このループは実際のエンジニアリングチームの働き方に近いです。

信頼できるエンジニアは、要件を受け取ってすぐに無秩序に変更することはありません。変更後に何も確認せず渡すこともありません。まず影響範囲を判断し、実装し、リスクとテスト結果を確認し、最後に踏んだ落とし穴を記録します。AI Agent にも同じような制約が必要です。

なぜプラグインが必要なのか

プロンプトで AI に「先に計画してから実行してください」と伝えることはできます。しかしプロンプト自体は必ずしも安定しません。

会話が長くなり、コンテキストが複雑になると、モデルは計画を飛ばしたり、ルールを無視したり、タスク完了を急いで過度に自信を持ったりします。プラグインの価値は、ワークフローを固定し、異なる Agent 環境でも似た方法を守れるようにすることです。

この種のプラグインは通常、ワークフローをコマンド、ルール、テンプレート、サブフローに分解します。ユーザーは毎回完全なプロンプトを書く必要がなく、固定された入口から特定の段階を起動します。

たとえば：

まず Agent に計画を生成させる
計画に沿って段階的に実装する
変更後に review を起動する
問題が見つかったら修正に戻る
残す価値のある経験を記憶やルールに書く

これにより AI コーディングは、一回限りのチャットではなく「制御された協作」に近づきます。

対応する Agent 環境

README では、複数の AI コーディング環境をサポートすると説明されています。

Claude Code
Codex
Cursor
GitHub Copilot
Amp
Factory
Qwen Code

これは注目すべき点です。

多くのワークフローツールは 1 つのクライアントにだけ結びついており、ツールを替えるとルールを再利用できません。Compound Engineering Plugin は、クロス Agent のエンジニアリング方法に近く、計画、実行、レビューのような流れを異なるツールへ持ち込みます。

複数の AI コーディングアシスタントを同時に使うなら、このような統一ワークフローには価値があります。ツールごとに能力は違っても、プロジェクト規約、レビュー習慣、タスク分解方法はできるだけ一貫している方がよいです。

計画段階の役割

計画段階の価値は、AI が早すぎる段階で手を動かすのを防ぐことです。

複雑なタスクで本当に重要なのは、たいてい次のような問いです。

どのファイルを変更するのか
どのモジュールが影響を受ける可能性があるか
既存のパターンは何か
テストはあるか
リスクはどこにあるか
先に読むべきドキュメントはあるか
より小さなステップに分解できるか

Agent がこれらを考える前にコードを書き始めると、完成しているように見えてもプロジェクト構造から外れた実装になりやすくなります。

計画は長い必要はありません。良い計画は短く、具体的で、実行可能です。目的はドキュメントを増やすことではなく、後続の実装に境界を与えることです。

実行段階で避けるべきこと

AI がコードタスクを実行するとき、よく起こる問題があります。

関係ないコードをついでにリファクタリングする
ユーザーの既存変更を上書きする
happy path だけを処理する
エラーハンドリングを無視する
既存のプロジェクトスタイルに従わない
必要な検証を実行しない
エラー後に場当たり的に試す

ワークフロープラグインはこれらの問題を完全には消せませんが、ルールと段階制約によって発生確率を下げられます。

たとえば、実行段階では Agent に計画どおり段階的に進めさせます。計画範囲外の発見があった場合は、まずリスクを説明します。共有モジュールを変更する場合は、テストを追加するか、少なくとも関連検証を実行します。

この制約は大規模コードベースで特に重要です。AI が速くコードを書くほど、その勢いを制限するプロセスが必要になります。

レビュー段階が重要な理由

多くの AI コーディング失敗は、コードがまったく動かないからではありません。細部に問題があるからです。

境界条件が処理されていない
状態更新が一貫していない
API 契約がこっそり変わっている
テストが重要経路をカバーしていない
エラーメッセージが分かりにくい
性能やセキュリティリスクが触れられていない

レビュー段階は Agent を「作者モード」から「レビューモード」へ切り替えます。

作者モードでは自分の実装を正当化しがちです。レビューモードでは、穴、回帰リスク、テスト漏れを積極的に探すべきです。この 2 つの段階を分ける方が、同じ回答内で実装と自己レビューを同時に行わせるより信頼しやすくなります。

ユーザーにとっても、レビュー出力は価値があります。その変更をマージしてよいか、まだ修正が必要かを素早く判断できます。

学習と記憶の意味

プロジェクト名の “Compound” は、重要な考え方を示しています。エンジニアリング経験は複利的に増えるべきだ、ということです。

AI が毎回のミスをその場で直すだけで、次回また同じミスをするなら、生産性向上は限られます。より良い方法は、価値ある経験を蓄積することです。

このプロジェクトのディレクトリ規約
ある種類のエラーの調査方法
テストコマンドと注意事項
触ってはいけない生成ファイル
コードスタイルの好み
よく使う実装パターン

これらの経験は、ルール、記憶、ドキュメント、テンプレートになります。後続タスクでは、Agent がまずそれらの蓄積を読み、その後作業を始めます。

これが AI コーディングを「一回限りの問答」から「長期協作」へ進める鍵です。

向いている場面

Compound Engineering Plugin は次のような場面に向いています。

AI Agent を長期的に使ってコードを書く
1 つのプロジェクトを何度も、複数回にわたって変更する
AI に先に計画してから実装してほしい
変更後に review 思考へ自動で入ってほしい
チームで AI コーディングフローを統一したい
Claude Code、Codex、Cursor など複数ツールを同時に使う
プロジェクト経験を再利用可能なルールにしたい

たまに小さなスクリプトを AI に書かせるだけなら、完全なフローは重く感じるかもしれません。

しかし AI コーディングアシスタントを日常開発の相棒として使うなら、計画、実行、レビュー、学習のループは明らかに役立ちます。

通常のプロンプトテンプレートとの違い

通常のプロンプトテンプレートは、「タスクをどう明確に伝えるか」を解決します。

たとえば：

一歩ずつ考えてください
先にファイルを読んでください
コードスタイルを揃えてください
テストを実行してください
変更内容を要約してください

これらのプロンプトはもちろん有用です。しかし、毎回ユーザーが正しく使うことに依存しています。

Compound Engineering Plugin は、よりワークフロー層にあります。これらの要求を再現可能なプロセスとして整理し、異なる Agent ツールに適用します。毎回ゼロからプロンプトを書くのではなく、一つのフローの中でタスクを進めます。

簡単に言えば、プロンプトテンプレートはリマインダーであり、ワークフロープラグインは制度に近いものです。

利用時の注意

第一に、フローを負担にしないことです。

小さなタスクに完全な計画と長いレビューが常に必要なわけではありません。良いワークフローはタスクの複雑さに応じて調整できます。単純な問題は素早く処理し、複雑な問題では完全なループを使います。

第二に、レビューはテストの代わりにはなりません。

Agent review は多くの問題を見つけられますが、実行時エラーを見逃すことがあります。最終判断には、テスト、型チェック、ビルド結果、人間のレビューが必要です。

第三に、ルールは継続的に整理することです。

経験の蓄積は重要ですが、ルールが増えすぎるとノイズになります。古いルール、重複ルール、一回のタスクにしか合わなかった一時的な経験は、定期的に整理すべきです。

第四に、ツール間で一貫していることは完全に同じであることではありません。

Claude Code、Codex、Cursor、Copilot などは能力や対話方式が異なります。統一すべきなのは作業方法であり、すべてのコマンドや設定詳細が同じである必要はありません。

向いているチーム

チームがすでに AI Agent に実コードの変更を許可しているなら、「どのモデルが強いか」だけを議論しても不十分です。

より重要なのは次の点です。

AI は変更前にタスクを理解しているか
AI は変更中にプロジェクト境界を守っているか
AI は変更後にリスクを自発的にレビューしているか
AI は過去のミスから学べるか
チームに統一された Agent 利用規約があるか

Compound Engineering Plugin のようなプロジェクトの意味はここにあります。AI コーディングを個人の小技から、チームで再利用できるプロセスへ一歩進めます。

参考

EveryInc/compound-engineering-plugin

最後に

Compound Engineering Plugin が注目に値する理由は、AI コーディングコマンドを一つ増やすことではありません。AI コーディングを、継続的に改善できるエンジニアリングフローとして整理することです。

AI Agent が実プロジェクトに参加し始めると、計画、実行、レビュー、経験の蓄積は、一回限りのコード生成より重要になります。

TradingAgents-CN：中国語ユーザー向けのマルチエージェント金融取引研究フレームワーク

Fri, 01 May 2026 03:14:15 +0800

TradingAgents-CN は、中国語ユーザー向けのマルチエージェント金融取引研究フレームワークです。

目的は「どの株を買うべきか」という単純な答えを出すことではありません。複数の AI Agent を使い、より完全な金融分析チームを模擬します。ある役割はファンダメンタルズを見て、別の役割はテクニカルを見ます。ニュースやセンチメントを追う役割もあれば、リスクや最終判断を担当する役割もあります。LLM + Agent + 金融分析を研究したい人にとって、この種のプロジェクトは良い実験入口になります。

まず明確にしておくべきことがあります。この種のツールは学習、研究、補助分析に向いています。実際の売買助言として扱うべきではありません。金融市場にはリスクがあり、モデル出力も間違い、遅れ、過度な自信を含む可能性があります。

解決する問題

通常のチャットモデルでも株式分析はできます。

たとえば「ある会社を買ってよいか分析して」と聞けば、モデルは一見まとまった回答を返します。しかし、この方法にはいくつか問題があります。

分析の流れが透明ではない
異なる観点が混ざりやすい
役割分担がない
賛成と反対の視点の衝突が少ない
リスク注意が形式的になりやすい
同じ分析フローを再現しにくい

TradingAgents-CN は金融分析を複数の役割に分解し、それぞれの Agent が別の視点を担当します。その後、協調、議論、要約を通じて分析結果を作ります。

これは実際の投資調査フローに近い形です。投資判断は通常、1 つのニュースや 1 つのテクニカル指標だけでは決まりません。企業のファンダメンタルズ、市場環境、価格推移、資金のセンチメント、政策リスク、ポジション管理を組み合わせて考える必要があります。

マルチエージェント分析とは何か

マルチエージェント分析は、複数のモデルに順番に話させるだけではありません。

より価値があるのは、異なる Agent に明確な責務を割り当てることです。たとえば：

市場分析 Agent：相場の流れ、価格変化、市場環境を見る
ファンダメンタル分析 Agent：事業、財務データ、長期価値を見る
ニュース分析 Agent：公告、ニュース、世論、イベント影響を見る
テクニカル分析 Agent：トレンド、指標、支持線と抵抗線、売買シグナルを見る
リスク管理 Agent：ボラティリティ、ドローダウン、ポジション、不確実性を見る
意思決定 Agent：異なる意見を総合し、最終判断を作る

この構造により、単一モデルが「すべての結論を一気に言う」問題を減らせます。

異なる役割が同じ対象を分析すると、システムは多面的な判断を示しやすくなり、意見の違いも見えやすくなります。学習者にとっては、単なる要約を読むより得るものがあります。

なぜ中国語版が必要なのか

金融分析は言語環境と深く関係しています。

中国語ユーザーが注目する情報源、市場習慣、銘柄名、取引制度、ニュース表現、一般的な用語は、英語環境とは異なります。英語のフレームワークをそのまま使うと、よく次のような問題が出ます。

中国語の株式名とコードの処理がうまくいかない
A 株、香港株、米国株の文脈が混ざる
中国語の金融ニュース理解が安定しない
国内データソースの接続が不便
出力スタイルが中国語ユーザーの読書習慣に合わない

TradingAgents-CN の意味は、このマルチエージェント金融分析フローを中国語ユーザー向けに適応していることです。中国語ユーザーが取引分析の実験フロー全体を構築、実行、理解しやすくなります。

何に使えるか

このプロジェクトは、自動発注よりも研究と補助分析に向いています。

適した用途は次のようなものです。

マルチエージェントシステムの協調方法を学ぶ
金融分析における LLM の挙動を研究する
株式を多角的に情報整理する
投資調査タスクで異なるモデルを比較する
自分の金融分析 Agent プロトタイプを作る
ある銘柄の履歴情報とリスク点を振り返る
投資調査フローを実行可能なタスクへ分解する練習をする

量的取引、金融工学、AI Agent、LLM アプリ開発を学んでいるなら、この種のプロジェクトは「AI 投資調査アシスタント」の裏側にあるエンジニアリング構造を理解する助けになります。

何に向かないか

これは確実に利益を出す道具ではありません。

特に次のような使い方には向きません。

出力に基づいて直接全力で売買する
モデルの結論で自分のリスク判断を置き換える
短期価格予測を確定結果として扱う
取引コスト、スリッページ、流動性を無視する
バックテストなしで実口座に接続する
1 回の分析結論で長期投資戦略を置き換える

LLM は情報整理、説明生成、推論フローの模擬に強いですが、市場を安定して予測する能力を自然に持っているわけではありません。金融市場には情報ノイズ、突発イベント、行動ゲームが多くあります。モデル出力は参考資料の一つにすぎません。

通常の量的フレームワークとの違い

従来の量的フレームワークは、データ、ファクター、バックテスト、ポートフォリオ最適化、取引実行により重点を置きます。

たとえば次のような戦略ルールを定義します。

移動平均ブレイクアウト
モメンタムファクター
バリューファクター
ボラティリティフィルター
損切りと利確
ポジション管理

その後、履歴データで戦略の成績をバックテストします。

TradingAgents-CN は「エージェント分析フレームワーク」に近いものです。複数の LLM Agent が金融タスクでどのように協調するか、投資調査の議論をどう模擬するか、ニュース、ファンダメンタルズ、テクニカル、リスク判断をどう整理するかに注目します。

両者は置き換え関係ではありません。

より現実的な使い方は、従来の量的システムが検証可能なルールとバックテストを担当し、Agent システムが情報整理、レポート生成、視点比較、意思決定支援を担当する形です。実取引に入れるかどうかは、厳密なバックテスト、リスク管理、人間の審査を経る必要があります。

ChatGPT に直接聞く場合との違い

モデルに直接聞くのは最も簡単ですが、プロセスは緩いです。

一度聞くと一度答えます。聞き方を変えると結論も変わるかもしれません。毎回同じ観点から分析する保証も、複数の相互牽制する役割を安定して演じさせることも難しいです。

TradingAgents-CN の価値は、分析フローを構造化することです。

役割がより明確
手順がより再現しやすい
情報源を整理しやすい
視点の衝突が自然
リスクチェックを個別に扱いやすい
出力が投資調査フローの結果に近い

これは学習と研究に役立ちます。異なる Agent が最終結論にどう影響するかを観察できますし、モデルを替えたり、プロンプトを調整したり、役割分担を変更したりして結果の変化を比較できます。

利用時に注意すべきリスク

第一に、データ品質です。

金融分析はデータに強く依存します。相場、財務報告、ニュース、公告データが不完全または遅れている場合、Agent の分析が流暢でも間違った基礎の上に立っている可能性があります。

第二に、モデルの幻覚です。

LLM は存在しない事実を作ったり、データの意味を誤解したり、古い情報を新しい情報として扱ったりする可能性があります。具体的な株式に関わる場合は、必ずデータソースで確認する必要があります。

第三に、過剰な説明です。

モデルは「もっともらしい」説明を作るのが得意ですが、市場価格の変化が本当にその理由によるとは限りません。事後説明を因果証明と誤解しないことが重要です。

第四に、バックテストと実取引の差です。

ある戦略が履歴データで良い成績を示しても、実取引ではスリッページ、手数料、流動性、取引停止、値幅制限、極端な相場などに直面します。

第五に、ライセンスと商用利用の境界です。

README では、このプロジェクトが混合ライセンスを採用していると説明されています。個人の学習研究と商用利用では条件が異なる可能性があります。商用製品やサービスに組み込む場合は、まずライセンス説明をよく読む必要があります。

研究に向いている人

TradingAgents-CN は次のような人に向いています。

AI Agent アーキテクチャを学びたい開発者
LLM の金融分析能力を研究したい人
量的取引をしていて自然言語分析を加えたい人
投資調査支援ツールを作りたいチーム
複数役割の協調が意思決定にどう影響するか知りたい人
中国語環境で取引 Agent を実験したいユーザー

単純な売買提案だけが目的なら、このプロジェクトは最適な使い方ではありません。注目すべきなのは、1 回の出力の結論ではなく、フロー、役割、協調、リスク管理です。

拡張できる方向

この種のフレームワークには多くの拡張方向があります。

より信頼できるデータソースを接続する
ローカルモデル対応を追加する
バックテストモジュールを追加する
A 株、香港株、米国株の市場ルールを細かく分ける
業界分析 Agent を追加する
ポートフォリオ管理とポジション制御を追加する
レポート引用とデータ追跡を強化する
Agent の結論と従来の量的シグナルを組み合わせる

本当に価値のある金融 AI システムは、通常モデルだけにすべてを決めさせるものではありません。検証可能で、追跡可能で、リスク管理されたフローの中にモデルを組み込むものです。

参考

hsliuping/TradingAgents-CN

最後に

TradingAgents-CN が注目に値する理由は、次のローソク足を予測できるかどうかではなく、金融分析をマルチエージェント協調フローに分解していることです。

自動で利益を出す機械としてではなく、学習と研究の道具として扱う方が合理的です。

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 コーディングアシスタントはプロジェクトルールに従いやすくなります。

Claude Code Hooks Mastery：13 個の Hooks ライフサイクルと自動化制御の入門

Fri, 01 May 2026 03:11:27 +0800

claude-code-hooks-mastery は、Claude Code Hooks を学ぶためのプロジェクトです。

単にいくつかのスクリプトを並べただけではありません。Claude Code の hooks ライフサイクル、設定方法、スクリプトの書き方、よくある自動化シナリオをまとめて説明しています。Claude Code をより制御しやすく、よりエンジニアリング向けの助手として使いたい人にとって、読む価値のある資料です。

Claude Code は標準でもコードを読み、ファイルを編集し、コマンドを実行できます。しかし、特定のタイミングで権限を確認したり、危険な操作を止めたり、プロジェクト規約を注入したり、テストを実行したり、チームルールを思い出させたりしたい場合、チャット指示だけでは安定しません。Hooks の価値は、「毎回 AI に思い出させたいルール」を実行可能なワークフローに変えることです。

Hooks が解決する問題

Claude Code をしばらく使うと、よく次のような課題が出てきます。

新しい会話のたびに同じプロジェクトルールを説明する必要がある
実行してはいけないコマンドを実行しないか不安
ファイル変更の前後で自動チェックしたい
コミット前にフォーマット、テスト、セキュリティスキャンを走らせたい
チーム規約を口頭の注意ではなく固定フローにしたい
ツール呼び出しの前後でコンテキストを取得し、ログやブロックに使いたい
複雑なタスクでサブエージェントや専用スクリプトを起動したい

Hooks は、こうした「決まったタイミングでの自動動作」のためにあります。

Claude Code ワークフロー内のイベントフックとして考えるとわかりやすいです。セッション開始、ユーザーのプロンプト送信、モデルがツールを呼び出す直前、ツール呼び出し完了、エージェント終了直前などのタイミングで、設定したスクリプトを実行できます。

13 個の Hooks ライフサイクル

このプロジェクト README の重要な点の一つは、Claude Code の 13 個の hook イベントを体系的に整理していることです。

これらのイベントは、セッション開始からツール呼び出し、ユーザー入力からエージェント終了まで、複数の段階をカバーします。用途別には、おおまかに次のように分けられます。

セッション起動関連：環境初期化、プロジェクトコンテキスト注入
ユーザー入力関連：プロンプト確認、ルール補足、監査
ツール呼び出し前関連：権限判断、コマンドブロック、安全チェック
ツール呼び出し後関連：結果記録、フォーマット起動、検証実行
タスク終了関連：要約、クリーンアップ、通知、状態保存

このライフサイクル設計により、すべてのルールを長いプロンプトに詰め込む必要がなくなります。

たとえば、権限制御はツール呼び出し前に行うべきです。フォーマットチェックはファイル変更後の方が自然です。プロジェクト規約の注入は、セッション開始時やユーザー入力後が向いています。正しい hook ポイントにルールを置く方が、すべてを system prompt に詰めるより信頼しやすくなります。

設定ファイルの場所

Claude Code の hooks は通常、設定ファイルで構成します。

よく使われる場所は次のとおりです。

ユーザー単位の設定：~/.claude/settings.json
プロジェクト単位の設定：.claude/settings.json

ユーザー単位の設定は、一般的な安全ルール、コマンドブロック、ログパスなど、個人の好みに向いています。

プロジェクト単位の設定は、そのリポジトリに関するルールに向いています。たとえば、必ず実行するテスト、編集禁止のディレクトリ、生成ファイルの扱い、コミット前のチェックなどです。

チームで Claude Code を使うなら、プロジェクト単位の設定をリポジトリに置くのがおすすめです。そうすれば、各自が記憶で AI に注意するのではなく、全員が同じ AI 協作制約を持ってプロジェクトを開けます。

単一ファイルスクリプトが重要な理由

このプロジェクトでは UV の単一ファイルスクリプトが強調されています。

利点はデプロイが簡単なことです。1 つの Python ファイルで依存関係を宣言して実行できるため、1 つの hook のために複雑な環境を維持する必要がありません。多くの hook は小さな処理を 1 つ行うだけなので、この形式は適しています。

コマンドの実行可否を確認する
ファイルパスが安全か判断する
プロジェクト規約を読み、Claude に返す
出力に機密情報が含まれていないか調べる
変更後にフォーマットやテストを実行する
イベントをログに書く

Hook スクリプトは小さいほど保守しやすく、新しい複雑なシステムになりにくくなります。

どんな自動化ができるか

claude-code-hooks-mastery は多くの方向性を示しています。実務でよく使うのは次のようなものです。

1. 権限と安全制御

これは hooks の最も直接的な用途です。

Claude Code がコマンドを実行する前に、その内容をチェックできます。削除、リセット、クリア、上書きなどの高リスク操作が含まれている場合、実行を止めるか、人間の確認を求められます。

同様のルールはファイルパスにも使えます。

本番設定を変更しない
秘密鍵ファイルに書き込まない
マイグレーションスクリプトを削除しない
指定ディレクトリに触れない
未承認のネットワークコマンドを実行しない

この保護をツール呼び出し前に置く方が、「危険な操作をしないで」とプロンプトに書くより確実です。

2. コンテキスト注入

多くのプロジェクトには固定された背景があります。

技術スタック
コーディング規約
テストコマンド
ブランチ戦略
ディレクトリ構造
禁止事項
生成ファイルの扱い

これらを毎回手動で Claude Code に伝えるのは面倒で、漏れやすいです。Hooks を使えば、セッション開始時やユーザーのプロンプト送信後に必要なコンテキストを自動注入できます。

これは Claude Code にプロジェクト単位の作業マニュアルを渡すようなものです。README や開発ドキュメントを置き換えるものではありませんが、AI がタスクを始める前に正しい状態へ入りやすくなります。

3. 変更後の検証

Claude Code がファイルを変更した後、hook で自動チェックを起動できます。

よくある処理は次のとおりです。

フォーマットを実行する
lint を実行する
単体テストを実行する
型エラーを確認する
生成ファイルをスキャンする
Markdown や JSON の形式を検証する

これは低レベルなミスを減らすのに役立ちます。AI が複数ファイルを変更した場合、変更後に軽量な検証を走らせることで、問題を早めに見つけられます。

ただし、hook に重い処理をデフォルトで入れるのは向きません。ファイル変更のたびに完全なテストスイートを走らせると、体験が遅くなります。より実用的なのは、ファイル種別、ディレクトリ、タスクのリスクに応じてチェック範囲を選ぶことです。

4. チームルールの検証

チームに明確な約束があるなら、その一部を hooks に入れられます。

たとえば：

コミットメッセージ形式
コードスタイルルール
特定の生成ファイルを直接変更しない
ドキュメントを同時に更新する
API 変更ではテストも更新する
特定ディレクトリは指定ツールでのみ生成する

これにより Claude Code は、制約のない外部アシスタントではなく、チームワークフローの一部に近づきます。

もちろん、hooks は CI の代わりではありません。ローカルでの早めの注意や前置ブロックに向いています。最終検証は CI、review、テストシステムに任せるべきです。

5. サブエージェントと専用タスク

README ではサブエージェント関連の内容にも触れています。

この使い方は、複雑なタスクをより専門的なフローに分ける場合に向いています。たとえばメイン会話が要求を理解し、hook や設定が専用のチェック、監査、要約、ドキュメント整理タスクを起動します。

個人ユーザーにとって、最初にやる価値があるのは複雑なエージェント編成ではありません。まずは反復的で明確かつ低リスクな処理を hooks に任せることです。ルールが安定してから、より複雑な自動化を検討すれば十分です。

Statusline と出力スタイル

プロジェクトは statusline と出力スタイルも扱っています。

一見すると体験面の細部ですが、Claude Code を長期的に使う場合には重要です。Statusline は現在のコンテキスト、タスク状態、環境情報、ヒントを表示できます。出力スタイルは Claude Code の回答を自分の作業習慣に合わせやすくします。

毎日同じターミナルで AI と協作するなら、こうした細部は効率に影響します。良い状態表示は誤操作を減らし、現在の会話が正しいプロジェクト、正しいブランチ、正しい環境にいるかを素早く判断できます。

hooks を重くしすぎない

Hooks は強力ですが、何でも詰め込む場所ではありません。

良いルールは次のとおりです。

高頻度の処理は速くする
安全ブロックは明確にする
出力は短くする
失敗理由は読みやすくする
スクリプトはできるだけ単一責務にする
重いチェックは明示コマンドや CI に任せる

毎回 10 秒以上かかる hook は、すぐに無効化したくなります。ブロックルールが曖昧な hook も、Claude Code とユーザーの両方にとって次に何をすべきか分かりにくくなります。

Hooks は、境界が明確な処理に最も向いています。許可または拒否、コンテキスト追加、ログ記録、軽量チェック、次の手順提示などです。

向いているユーザー

たまに Claude Code に小さなコード変更を頼むだけなら、hooks を深く学ぶ必要はまだないかもしれません。

しかし、次のような場合はこのプロジェクトを調べる価値があります。

Claude Code を頻繁に使う
AI に実際のプロジェクトコードをよく変更させる
AI が危険なコマンドを実行しないか不安
チーム規約を AI ワークフローに自動注入したい
変更後に自動チェックを走らせたい
繰り返しの注意を設定に変えたい
より安定した AI コーディングフローを作っている

特に複数人で作業するプロジェクトでは、hooks の意味が大きくなります。チーム経験の一部をスクリプトとして残せるため、各メンバーがその場で AI に注意する必要が減ります。

利用時の注意

第一に、安全系 hook から始めることです。

複雑な自動化よりも、コマンドブロック、パス保護、機密ファイルチェックの方が実装しやすく、すぐにリスクを下げられます。

第二に、プロジェクト単位のルールは慎重にコミットすることです。

.claude/settings.json は、そのリポジトリを使う全員に影響します。コミット前に、通常開発を過度に制限しないこと、自分のマシンにしかないパスに依存しないことを確認した方がよいです。

第三に、hook の出力は簡潔にすることです。

Claude Code はその出力を消費します。長すぎるとコンテキストを汚し、曖昧すぎると次の行動を導けません。必要な判断と次の提案だけを返すのがよいです。

第四に、デバッグしやすく保つことです。

Hooks が増えると、問題は設定、スクリプト、権限、パス、依存関係、Claude Code 本体のどこからでも起こり得ます。明確なログを残すと、後の調査がずっと楽になります。

参考

disler/claude-code-hooks-mastery

最後に

Claude Code Hooks の価値は、「AI に毎回覚えていてほしいルール」を、実際に実行されるフローへ変えることです。

すでに Claude Code を実プロジェクトで使い始めているなら、hooks は「会話できるコーディング助手」から「制約を持つエンジニアリング協作者」へ進むための重要な一歩です。

Claude-Mem：Claude Code にセッションをまたぐ長期記憶を追加する

Fri, 01 May 2026 03:01:02 +0800

Claude-Mem は、Claude Code 向けの永続的な記憶システムです。

解決しようとしている問題は明確です。AI コーディングアシスタントは、新しいセッションを始めるたびに、以前話したアーキテクチャ判断、踏んだ落とし穴、プロジェクトの好み、実装背景を忘れがちです。
長く続くプロジェクトでは、毎回同じ文脈を説明し直すのはかなり無駄です。

Claude-Mem の考え方は、Claude Code の会話内容を記憶として圧縮し、ローカルデータベースとベクトルストアに保存し、あとから検索ツールで取り戻すというものです。

何を解決するのか

Claude Code はコードタスクに強いですが、セッションの文脈には限界があります。

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

新しいセッションが過去の作業を知らない
プロジェクトの設計判断を何度も説明する必要がある
以前調査した問題を再び踏みやすい
長期タスクに連続した記憶がない
複数の会話にまたがるプロジェクト知識を蓄積しにくい

Claude-Mem はこれらの問題を中心に設計されています。

単にチャットログを保存するのではありません。会話を検索しやすい記憶断片に圧縮します。後で必要になったとき、意味検索で関連する文脈を取り戻せます。

仕組み

README の設計を見ると、Claude-Mem は主にいくつかの部分で構成されています。

第一の部分は hooks です。

Claude Code の会話フローに接続し、適切なタイミングで会話データを捕捉します。

第二の部分はバックグラウンド worker です。

worker は原始的な会話内容を、より短く、検索しやすい記憶へ処理します。

第三の部分はローカルストレージです。

プロジェクトは構造化メタデータの保存に SQLite を使い、ベクトルインデックスには Chroma を使います。これにより、会話記録の基本情報を保ちながら、意味検索にも対応できます。

第四の部分は mem-search です。

これは Claude Code が使う検索入口です。過去の文脈が必要なとき、関連する記憶を検索できます。

全体の流れは次のように理解できます。

Claude Code のセッションで内容が生まれる
hooks が会話データを捕捉する
worker が非同期に圧縮・整理する
記憶を SQLite と Chroma に書き込む
後のセッションで mem-search によって検索する

どんな場面に向いているか

Claude-Mem は長期プロジェクト向けで、一回きりの小さなタスク向けではありません。

たとえば：

ひとつのリポジトリを何日も開発し続ける
コード構造が複雑で、背景説明が多い
プロジェクト規約、命名習慣、アーキテクチャ選択を覚えてほしい
Claude Code に頻繁にバグ修正、機能追加、文書整理を任せる
AI に「以前なぜこう変更したのか」を覚えてほしい

Claude Code に一行だけ直してもらう程度なら、長期記憶の意味は大きくありません。
しかし Claude Code を長期的な協力者として使うなら、これは役に立ちます。

インストールと起動

README では、インストール方法は直接的です。

1
2

npm install -g claude-mem
claude-mem install

起動には次を使います。

`1`	`claude-mem start`

状態確認：

`1`	`claude-mem status`

停止したい場合：

`1`	`claude-mem stop`

これらのコマンドの目的は、記憶システムを長く動くローカルサービスとして Claude Code のワークフローに接続することです。

`mem-search` の使い方

mem-search は記憶を取り戻すための重要な入口です。

普通の検索を置き換えるものではなく、Claude Code が過去の会話内容を意味で検索できるようにするものです。

たとえば Claude Code に次のようなことを検索させられます。

あるモジュールがなぜそのように設計されたのか
ある Bug を当時どう調査したのか
プロジェクトで合意した命名規則
以前議論した技術的な取捨選択
あるリファクタリングの背景

これは単純なキーワード検索とは違います。
記憶圧縮とベクトルインデックスがうまく機能すれば、正確な言い回しを覚えていなくても、意味的に近い内容を取り戻せます。

普通のプロジェクト文書との違い

プロジェクト文書は、安定した結論を記録するのに向いています。

たとえば：

アーキテクチャ説明
デプロイ手順
API 規約
データベース構造
開発ルール

Claude-Mem は、会話過程で生まれる文脈を記録するのに向いています。

たとえば：

なぜある案が却下されたのか
一時的な問題をどう回避したのか
実装の背後にあった議論
まだ文書化されていないプロジェクトの好み
複数の会話で積み重なったタスク背景

両者は互いの代替ではありません。
安定した知識はプロジェクト文書へ書き、過程的な文脈は記憶システムで検索できるようにするのがよいです。

使うときの注意点

第一に、長期記憶は多ければよいわけではありません。

すべての会話を区別なく保存すると、後の検索がノイズだらけになる可能性があります。価値が高いのは、プロジェクト判断、実装背景、問題調査、長期的な好みです。

第二に、記憶はコードや文書の代わりにはなりません。

AI が見つけた古い文脈は参考にすぎません。最終判断は現在のコード、テスト結果、最新の要求に基づくべきです。

第三に、プライバシーとローカルデータに注意が必要です。

会話内容を保存する以上、どのプロジェクトに接続してよいか、どの機密情報を会話に入れるべきでないかを理解しておく必要があります。

第四に、記憶システムにはメンテナンスが必要です。

プロジェクトが進むにつれて、古い記憶は古くなる可能性があります。古い文脈が誤って使われると、後続タスクを誤導することがあります。

この種のツールが注目に値する理由

AI コーディングツールは、「一回限りの質問応答」から「長期的な協力」へ向かっています。

一回限りの質問応答では、モデルは現在の質問に答えれば十分です。
長期的な協力では、プロジェクト履歴、過去の判断、チームの好み、すでに踏んだ落とし穴を知っている必要があります。

Claude-Mem のようなツールの意味はここにあります。「文脈を覚える」ことを、一時的なチャット能力ではなく、インストールし、実行し、検索できるローカルシステムにします。

実際のエンジニアリングプロジェクトでは、単にモデルのコンテキストウィンドウを長くするより実用的です。
多くの情報は一度に文脈へ詰め込めばよいのではなく、必要なタイミングで取り戻せることが重要だからです。

誰が試すべきか

次のような場合は試す価値があります。

Claude Code を高頻度で使っている
同じプロジェクトを日をまたいで扱うことが多い
プロジェクト文脈が複雑
AI に同じ背景を何度も説明している
会話内の経験を蓄積したい

Claude Code をたまに使うだけ、またはプロジェクトが小さい場合は、まだ必要ないかもしれません。

参考

thedotmack/claude-mem

最後に

Claude-Mem の重点は「チャットログを保存すること」ではなく、Claude Code が後続タスクで有用な文脈を取り戻せるようにすることです。

AI コーディングが一回限りのタスクから長期プロジェクト協力へ移るにつれ、記憶システムはますます重要になります。
文書やテストを置き換えるものではありませんが、繰り返し説明を減らし、AI をプロジェクト履歴を理解した助手に近づけます。

Claude.md は長ければよいわけではない：AI コーディング用のグローバルメモリファイルの書き方

Wed, 29 Apr 2026 21:07:37 +0800

最近、AI コーディング用のグローバルメモリファイルについての議論を見かけました。プロジェクトに Claude.md や AGENTS.md のようなファイルを追加しても、必ずしも結果がよくなるとは限らず、場合によっては成功率が下がり、推論コストも上がるという話です。

一見すると直感に反します。AI にプロジェクト背景、ルール、説明を多く渡せば、より正確にコードを書けるはずだと思いがちです。
しかし本当の問題は、Claude.md が普通のドキュメントではないことにあります。これは毎回の会話でコンテキストに挿入されるグローバルメモリです。内容が多ければ、モデルは毎回それだけ多く読む必要があります。内容が曖昧なら、毎回余計な判断が増えます。本来入れるべきではない手順を書いてしまうと、関係のないタスクでも不要な動作が発火する可能性があります。

つまり、Claude.md を書く難しさは、内容をすべて書き切ることではありません。どの情報が長期的にコンテキストを占有する価値があるかを判断することです。

Claude.md とは何か

AI コーディングツールにおいて、Claude.md や AGENTS.md のようなファイルは、本質的にはグローバルメモリファイルです。

通常の会話もコンテキストに入りますが、コンテキスト長には上限があります。会話が長くなると、履歴は圧縮され、一部の細部は失われます。グローバルメモリファイルの役割は、重要なルールを固定し、モデルが毎回のタスク開始時に参照できるようにすることです。

これは二つの意味を持ちます。

書いた内容は忘れられにくい
書いた内容は毎回のタスクでコストになる

これは必要なときだけ読まれる README とは違います。長期的に有効な作業制約に近いものです。一度入れると、デフォルトで毎回モデルの判断に影響します。

そのため、Claude.md はプロジェクト紹介でも、経験メモでも、すべての開発手順を詰め込む場所でもありません。モデルが知らないと同じミスを繰り返しやすいルールだけを置くべきです。

なぜ逆効果になることがあるのか

グローバルメモリファイルの書き方が悪いと、主に三つの問題が起きます。

一つ目は、コンテキストを消費することです。

Claude.md が一千行ある場合、その一千行は長期的にモデルのコンテキストに入ります。現在のタスクに本当に関係するコード、エラーメッセージ、要求仕様が圧迫されるかもしれません。コンテキストは無料の空間ではありません。グローバルルールが大きいほど、現在のタスクの焦点は薄まりやすくなります。

二つ目は、余計な行動を誘発することです。

たとえば、グローバルファイルに次のように書いたとします。

1
2

毎回タスクを始める前に、プロジェクトディレクトリを完全に読む。
毎回変更後に、完全なエンドツーエンドテストを実行する。

これらは責任ある指示に見えますが、グローバルメモリに置くと「すべてのタスクで実行する」という意味になります。たとえ一行の文言修正であっても、モデルはこのルールに従って不要な探索やテストを行うかもしれません。結果として、作業は遅くなり、コストは上がり、ときには新しい干渉も生まれます。

三つ目は、判断負荷を増やすことです。

「コードをエレガント、簡潔、保守しやすく、拡張しやすく保つ」のような文は正しく聞こえますが、実際の制約としては弱いです。モデルはコードを生成するたびに、何がエレガントで何が拡張しやすいのかを判断しなければなりません。しかし明確な境界は与えられていません。

よりよい書き方は、抽象的な美徳を並べることではなく、具体的な禁止事項や反例を書くことです。たとえば：

1
2
3

単一の呼び出し箇所のために汎用抽象を追加しない。
テストカバレッジなしで共有パース処理を変更しない。
一時スクリプトをアプリケーションのソースディレクトリに置かない。

これらのルールは具体的で、実行しやすいものです。

何を書くべきか

ある内容を Claude.md に書くべきかどうかは、単純な基準で判断できます。

それを書かないと AI が同じ種類のミスを繰り返すなら、書く価値があります。

グローバルメモリファイルに向いている内容には、だいたい次の特徴があります。

長期的に有効である
現在のリポジトリと強く関係している
コード構造から自然には推測できない
モデルの行動を明確に変える
制約、禁止事項、パス規則、固定コマンドであることが望ましい

たとえば：

すべての Hugo 記事では index.zh-cn.md だけを編集し、他言語版を自動生成しない。
記事の front matter には title/date/draft/tags/categories/slug/description が必須。
public/ 配下の生成物を変更しない。
PowerShell でデプロイするときは scripts/deploy.ps1 を使う。

これらは曖昧な助言ではありません。リポジトリの実際の作業方法に結びついています。モデルが知らなければ間違える可能性があり、知っていれば実際に誤操作を減らせます。

書くべきではないもの

多くの人は Claude.md をプロジェクト説明書にしてしまいがちですが、通常それは不要です。

あまり向いていない内容は次のようなものです。

プロジェクトのビジョンや背景紹介
長いディレクトリ構成説明
一時的なタスク計画
一回限りのデバッグ手順
抽象的なコード品質スローガン
一部の状況でしか必要ない長いワークフロー

たとえば「これは商品、注文、ユーザーモジュールを含む EC プロジェクトです」という説明は、具体的なコーディングタスクにはあまり役立ちません。実際の開発では、モデルは現在の要求、仕様書、コード構造、テストに基づいて判断すべきであり、グローバルメモリ内の粗い紹介に頼るべきではありません。

ディレクトリ構成も同じです。「共有コンポーネントはこのディレクトリからのみ参照する」のような特別な約束がある場合を除き、ツリー全体を書く必要はありません。モデルはプロジェクトディレクトリを自分で読めます。静的な構成説明は古くなりやすいだけです。

手順は skills やコマンドに向いている

ある内容が「第一にこれをする、第二にこれをする、第三にこれをする」という手順なら、それは Claude.md に置くべきではないかもしれません。

長期的なワークフローは、skills、スクリプト、コマンドに分離できます。そうすれば、グローバルメモリには名前と発火条件だけを残し、詳細な手順は必要なときだけ読み込めます。

たとえば：

1
2

ユーザーが Hugo 記事の翻訳を依頼したら、post-translate skill を使う。
ユーザーがサイトのデプロイを依頼したら、hugo-rsync-deploy ワークフローを実行する。

完全な翻訳手順やデプロイ手順を Claude.md に書くより軽くなります。グローバルメモリは短く保ち、具体的な流れは起動可能なツールに任せます。

Claude の最近の初期化フローもこの方向に進んでいます。単に Claude.md を生成するだけでなく、再利用可能なワークフローを skills に、固定イベントを hooks に分けようとします。この変化の背景にある考え方は明確です。グローバルメモリは入口だけを担い、詳細は必要に応じて読み込むべきです。

Claude.md は継続的に改善するもの

Claude.md は一度書いて終わりにすべきではありません。

より現実的なのは、最初は短く保ち、実際のタスクの中で問題を露出させることです。あるミスが一度だけ起きたなら、まず人間が処理すれば十分です。同種のミスが二回以上起きたなら、それはグローバルルールとして残す価値があるかもしれません。

最初から大量のルールを書くより、このような反復のほうが効果的です。初期段階では、どのルールが本当に役立つのか、どの内容がノイズになるのか分かりません。プロジェクトが大きくなり、協業が増え、モデルの挙動が安定してきたら、高頻度の問題を少しずつ追加していけばよいのです。

もう一つ重要な傾向があります。モデルが強くなるほど、グローバルメモリファイルは短くあるべきです。

以前はプロンプトに書く必要があった多くの要求を、今のモデルは自然に処理できます。そうした基本要求を Claude.md に入れ続けると、コンテキスト負荷が増えるだけです。グローバルメモリはモデル能力の向上に合わせて縮小し、このリポジトリ固有で、モデルが自動推測できない内容だけを残すべきです。

より実用的な書き方

Claude.md を書くときは、次の順序で考えるとよいです。

このリポジトリにはどんな特別な約束があるか？
モデルがすでに二回以上犯したミスは何か？
誤用してはいけないディレクトリ、ファイル、コマンドは何か？
どの手順は常駐コンテキストではなく、skills、スクリプト、コマンドにすべきか？
どの内容は単なる紹介で、削除できるか？

最終的なファイルは数十行だけかもしれません。プロジェクト全体を説明する必要はありません。行動を正確に制約することが目的です。

よい Claude.md は、たとえば次のようになります。

# 作業ルール

- 現在のタスクに関係するファイルだけを編集する。
- public/ や resources/ のような生成物ディレクトリを変更しない。
- Hugo 記事の書き換えでは index.zh-cn.md だけを処理し、他言語版を生成しない。
- デプロイが関係する場合は、先に Hugo ビルドを実行し、その後既存の rsync スクリプトを実行する。
- 既存のユーザー変更がある場合は、巻き戻さず、現在の状態を前提に続ける。

短いですが、どの行も実際の行動に影響します。こういう内容こそ、長期的にコンテキストを占有する価値があります。

最後に

Claude.md の価値は、AI に「もっと多くを知ってもらう」ことではありません。AI に「決まったミスを減らしてもらう」ことです。

これは知識ベースでもプロジェクト百科でもありません。AI コーディングにおける長期的な制約ファイルです。
具体的で、短く、実際のミスに近いほど役に立ちます。逆に、汎用的で、長く、プロジェクト紹介のようになるほど、モデルを遅くし、結果を悪化させる可能性が高くなります。

グローバルメモリは無限のメモ帳ではなく、希少な資源として扱う。これが、よい Claude.md を書くためのもっとも重要な原則かもしれません。

Codex がコンピューターを操作し始めると、これから何が変わるのか？

Wed, 29 Apr 2026 11:28:25 +0800

今回の Codex で最も注目すべき変化は、普通のボタンが一つ増えたことではありません。Codex が「コンピューターを操作する」方向へ進み始めたことです。

これまで AI を使うとき、多くの場合はチャット欄で質問し、コピーして貼り付け、その後は人間が手動でソフトウェアを操作していました。
今、その境界が外側へ広がり始めています。AI は答えるだけでなく、あなたの目的に合わせてデスクトップアプリを操作できるようになりつつあります。

短期的には新機能の一つです。長期的には、多くの人のコンピューターの使い方を変えるかもしれません。

この機能とは何か

簡単に言えば、Codex のコンピューター操作機能は、デスクトップ環境に触れ、それを操作できるようにするものです。

できることは次のようなものです。

特定のアプリを選択して操作する
自然言語でタスクを受け取る
ブラウザ、AI ツール、ローカルファイル、その他のソフトウェアを開く
テキストを入力し、ボタンをクリックし、結果を待つ
複数の手順を一つのタスクとしてつなげる
ユーザーが一歩ずつ追わなくても、バックグラウンドで実行を続ける

役割は、単に文章を一段落書くことではありません。操作の流れそのものを代行することです。

ここが Agent と普通のチャットボットの大きな違いです。
チャットボットは主に答えを返します。Agent は「目的を受け取り、それを実行する」ものに近づきます。

なぜ重要なのか

これまで多くの自動化には、スクリプトを書く力が必要でした。

たとえば、複数のソフトウェアをまたぐ作業をしたいとします。

Web ページを開く
情報を探す
内容をコピーする
別の AI ツールに渡す
ファイルを保存する
ローカルディレクトリを開いて結果を確認する

従来の方法でこれを自動化するなら、ブラウザスクリプト、API、ローカルプログラム、場合によってはウィンドウ操作まで扱う必要があります。

しかし、多くの一般ユーザーはそうしたものを書けません。
書ける人でも、一時的な作業のために専用スクリプトを書く価値があるとは限りません。

コンピューター操作機能の意味はここにあります。
「スクリプト的な能力」を自然言語の方向へ一歩押し出します。

どこをクリックするかを細かく教える必要はありません。
欲しい結果を伝え、あとは Agent に試してもらう形に近づきます。

どんなワークフローが変わるのか

最初に変わるのは、極めて厳密で高リスクな仕事ではなく、面倒で、細かく、繰り返しが多く、それでも専用プログラムを書くほどではない作業だと思います。

1. ソフトウェア間の情報移動

典型的なのは、複数のソフトウェア間で情報を移動する作業です。

これまでは、ブラウザ、文書、チャット画面、ローカルフォルダを何度も行き来していたかもしれません。
今後は、こうした作業を Agent に任せられるようになります。

ある種類の情報を探す
文書にまとめる
指定フォルダに保存する
結果を開いて確認できる状態にする

この作業は難しくありませんが、注意力を消耗します。
Agent の価値は、こうした細かい操作を吸収することです。

2. 複数の AI ツールの連携

今では、一つの AI ツールだけで完結しない作業も増えています。

たとえば：

あるツールでコードを書く
あるツールで資料を調べる
あるツールで画像を生成する
あるツールで文書を整理する

これまでは、それらの間を人間がコピー&ペーストでつないでいました。
これからは、Agent が中間層になれます。ツールを開き、文脈を渡し、出力を待ち、結果を整理します。

これにより、「複数の AI ツールの協調」は手作業から半自動の流れに変わります。

3. オフィスソフトの自動化

表計算、プレゼン、文書、メールには共通点があります。機能は強力ですが、操作は細かいものが多いということです。

Agent がこれらを安定して操作できるようになれば、オフィス自動化のハードルはかなり下がります。

メニューの場所を覚えたり、複雑なショートカットを覚えたりする必要は薄れます。
必要なのは、目的をはっきり伝えることです。

この表を月報にまとめる
この文書から 1 ページの要約を作る
これらの資料を構造の分かりやすい説明にまとめる

面倒なボタン操作は、少しずつ自然言語の後ろに隠れていくでしょう。

一般ユーザーにとっての意味

一般ユーザーにとって、この種の機能は「モデルが少し賢くなった」ことよりも直接的な影響を持つかもしれません。

下がるのは知識のハードルだけではなく、操作のハードルだからです。

多くの人は、やりたいことを説明できないわけではありません。
どこをクリックすればよいか、ソフトウェアの機能をどう組み合わせればよいかが分からないのです。

Agent がそこを引き受けられるなら、コンピューターの使い方は次のようになります。

1
2
3

私が目的を説明する
Agent がソフトウェアを操作する
私が結果を確認する

これは単なるチャットより、実際の生産性に近い形です。

ソフトウェアの形にも影響する

この種の Agent 能力が成熟していけば、ソフトウェアそのものも影響を受けます。

これまでソフトウェア設計は、主に人間のクリックに向けられていました。
これからは、Agent による操作も意識する必要が出てきます。

つまり：

UI 要素はより明確である必要がある
操作結果のフィードバックは安定している必要がある
ローカル権限はより細かく管理される必要がある
ソフトウェアは Agent が呼び出しやすいインターフェースを用意するかもしれない
ユーザーは「AI がうまく操作できるか」を気にするようになる

長期的には、アプリ間の境界は薄くなるかもしれません。
ユーザーが気にするのは「どのアプリを開くか」ではなく、「どのタスクを完了したいか」になります。

まだ過度に楽観する段階ではない

もちろん、今すぐ完全に任せる段階ではありません。

この能力には、まだ明確な制限があります。

安定性はまだ見ていく必要がある
複雑なタスクは途中で失敗する可能性がある
権限の境界は慎重に扱う必要がある
アカウント、支払い、ファイル削除のような操作は簡単に任せるべきではない
利用枠の消費も無視できない

そのため現時点で最も向いている使い方は、コンピューター全体を完全に任せることではありません。
低リスクで、確認可能で、手順が多い作業を任せることです。

たとえば：

資料を整理する
下書きを生成する
ツール間で内容を移動する
ファイルを開いて確認する
人間が最後に確認できる半自動フローを実行する

最後に

今回の Codex 更新で本当に重要なのは、AI が「質問に答える」段階から「環境を操作する」段階へ進んだことです。

短期的には、これはコンピューター操作機能です。
長期的には、個人用コンピューターとの関わり方の転換点になるかもしれません。

これから私たちは、ボタンを覚えたり、メニューを探したり、ウィンドウを切り替えたりする時間を減らしていくかもしれません。
その代わりに、目的を伝え、Agent に実行させ、最後に人間が判断する場面が増えていくでしょう。

Codex Skill はディレクトリにあるのに、なぜ表示されないのか？

Wed, 29 Apr 2026 11:18:00 +0800

今回の問題はかなり見落としやすいものでした。~/.codex/skills には複数の skill が置かれているのに、新しい Codex スレッドを開いても、サイドバーには一部しか表示されませんでした。

最初はキャッシュやインデックスの問題に見えました。実際の原因はもっと具体的で、いくつかの SKILL.md ファイルの先頭に UTF-8 BOM が付いていました。Codex 0.111.0 の skill loader はこのバイト列を読み飛ばさず、結果として有効な YAML front matter がないと誤判定していました。

現象

ローカルディレクトリには次の skill がありました。

~/.codex/skills/git-commit-push/SKILL.md
~/.codex/skills/hugo-rsync-deploy/SKILL.md
~/.codex/skills/bilibili-speech-transcriber/SKILL.md
~/.codex/skills/product-cutout-normalize/SKILL.md

しかし新しいスレッドで実際に公開された skill は次の二つだけでした。

1
2

bilibili-speech-transcriber
product-cutout-normalize

つまり、ファイルが存在することと、現在のセッションで読み込めることは別です。Codex は各 SKILL.md の front matter を先に解析し、解析に失敗した skill はそのまま除外します。

調査

codex exec で新しいセッションを起動すると、より直接的なエラーが見えます。VS Code などの IDE では、こうした log が見えない場合があります。

1
2

failed to load skill C:\Users\knightli\.codex\skills\git-commit-push\SKILL.md: missing YAML frontmatter delimited by ---
failed to load skill C:\Users\knightli\.codex\skills\hugo-rsync-deploy\SKILL.md: missing YAML frontmatter delimited by ---

これらのファイルは、見た目には正常な先頭を持っていました。

---
name: post-rewrite
description: ...
---

本当の問題はバイト列にありました。

失敗するファイルの先頭は：

`1`	`EF-BB-BF-2D-2D-2D`

正常に読み込まれるファイルの先頭は：

`1`	`2D-2D-2D`

2D-2D-2D は --- です。その前にある EF-BB-BF が UTF-8 BOM です。

原因

Codex 0.111.0 の skill loader は、SKILL.md の最初のバイトが --- の最初の - であることを期待しています。

ファイルの先頭に UTF-8 BOM があると、実際の先頭は次のようになります。

`1`	`BOM + ---`

そのため loader は、ファイルが front matter の区切りで始まっていないと判断し、最終的に次のエラーを出します。

`1`	`missing YAML frontmatter delimited by ---`

skill の内容が間違っていたわけでも、ディレクトリが間違っていたわけでもありません。エンコーディングの細部が原因で、パーサーがファイルを認識できなかっただけです。

修正

問題のある SKILL.md を BOM なしの UTF-8 に変換します。

PowerShell では次のように処理できます。

$paths = @(
  'C:\Users\knightli\.codex\skills\git-commit-push\SKILL.md',
  'C:\Users\knightli\.codex\skills\hugo-rsync-deploy\SKILL.md',
)

$utf8NoBom = New-Object System.Text.UTF8Encoding($false)

foreach ($p in $paths) {
  $text = [IO.File]::ReadAllText($p, [Text.Encoding]::UTF8)
  [IO.File]::WriteAllText($p, $text, $utf8NoBom)
}

処理後にファイルヘッダーを確認すると、次の状態から：

`1`	`EF-BB-BF-2D-2D-2D`

次の状態に変わっているはずです。

`1`	`2D-2D-2D`

検証

Codex セッションを再起動すると、表示される skill は次のように戻りました。

git-commit-push-zh
hugo-rsync-deploy
bilibili-speech-transcriber
product-cutout-normalize

それでもサイドバーに古い一覧しか表示されない場合は、現在の Codex sidebar またはウィンドウを閉じて、プロジェクトを開き直します。skill 一覧は通常セッション開始時に読み込まれるため、途中でファイルを変更してもすぐには反映されないことがあります。

最後に

この種の問題は、「Codex が再インデックスしていない」または「skill のインストールに失敗した」と誤解しやすいです。

実際に調べるときは、まず次の三点を確認するとよいです。

SKILL.md が正しいディレクトリにあるか
ファイル先頭に有効な --- front matter があるか
ファイルが BOM なしの UTF-8 か

今回のポイントは三つ目です。ファイルは見た目には問題ありませんでしたが、最初のバイトが - ではなかったため、Codex はそれを有効な skill として扱いませんでした。

Codex の ~/.codex/skills とプロジェクト/.codex/skills の違い

Wed, 29 Apr 2026 11:08:00 +0800

Codex skills を整理するとき、多くの人がつまずきやすい問題は主に二つあります。

~/.codex/skills と プロジェクト/.codex/skills は何が違うのか
skill はディレクトリにあるのに、なぜ現在のセッションに表示されないことがあるのか

この文章では結論から整理します。

両者の違い

まず短く覚えるなら、こうです。

~/.codex/skills は自分用のグローバルなスキルライブラリ
プロジェクト/.codex/skills はそのリポジトリ用のローカルなスキルライブラリ

`~/.codex/skills`

ここに置くのに向いているもの：

自分が複数プロジェクトで繰り返し使う skill
特定のリポジトリに依存しない汎用的な手順
明らかに個人の作業習慣に属するワークフロー

たとえば：

post-rewrite
post-translate
git-commit-push
hugo-rsync-deploy
bilibili-speech-transcriber

このタイプの skill の特徴は、現在のプロジェクトを離れても使えることです。

`プロジェクト/.codex/skills`

ここに置くのに向いているもの：

このリポジトリでだけ成立する手順
現在のプロジェクトのディレクトリ構成、スクリプト、テンプレートに強く結びついたルール
チームで共有したい skill

たとえば：

このリポジトリ固有の公開フロー
このプロジェクト内でしか使えない生成テンプレート
プロジェクト固有のスクリプトに強く依存する自動化手順

このタイプの skill の特徴は、このリポジトリを離れると意味が薄くなることです。

グローバルに置くか、プロジェクトに置くか

判断基準はシンプルです。

個人の作業習慣に関係するなら ~/.codex/skills
リポジトリのルールに関係するなら プロジェクト/.codex/skills
複数プロジェクトで再利用できるなら、まずはグローバル
複数人で共有し、リポジトリと一緒に育てたいなら、プロジェクト側

今回のリポジトリの状態

現在見えている状態では：

ローカル環境には ~/.codex/skills がある
現在のリポジトリには .codex/skills がない

つまり、今は主にグローバル skills に依存しています。

言い換えると、post-rewrite、post-translate、git-commit-push のような手順は、このリポジトリに明示的に含まれているものではなく、あなた個人のワークフローに近いものです。

ディスク上にあるのに、現在のセッションに表示されない理由

ここでは二つの状態を分けて考える必要があります。

ディスク上に存在する：skill ファイルがローカルのディレクトリにある
セッションに公開されている：現在のセッションがそれを利用可能な skill として登録している

この二つは同じではありません。

そのため、次のようなことが起きます。

~/.codex/skills にはすでに skill がある
しかし / の後に出る一覧には表示されない

これは通常、skill が壊れているという意味ではありません。より多い原因は、現在のセッションがそれを再インデックスしていないことです。

現在のセッションに skill を表示させるには

実用上の手順は次の通りです。

1. 正しいディレクトリに置く

グローバル：

`1`	`~/.codex/skills/<skill-name>/SKILL.md`

プロジェクト単位：

`1`	`プロジェクト/.codex/skills/<skill-name>/SKILL.md`

2. `SKILL.md` の先頭を認識できる形にする

最低限、次のような front matter が必要です。

---
name: your-skill-name
description: この skill が何をするものか
---

3. 新規作成または編集後は、新しいセッションを開く

skill が表示されない原因は、ファイルの問題ではなく、現在のセッション開始時に利用可能な skill 一覧がすでに確定していたことかもしれません。

そのため、セッション中に skill を作成しても、ディスク上には存在する一方で、そのセッションでは認識されない場合があります。

いちばん確実な流れは次の通りです。

skill を正しい場所に置く
現在のセッションを終了する
プロジェクトに入り直す
新しいセッションを開く
/ に表示されるか確認する

4. プロジェクト skill は事前に置いておく

プロジェクト/.codex/skills をより安定して認識させたいなら、リポジトリに入り、セッションを開始する前に、それらの skill をプロジェクト内に置いておくのが無難です。

最後に

短くまとめると：

~/.codex/skills は個人用のスキルライブラリ
プロジェクト/.codex/skills はリポジトリ用のローカルルールライブラリ
skill がディレクトリにあることと、現在のセッションに表示されることは別
表示させたいなら、正しいディレクトリに置き、正しい SKILL.md を書き、新しいセッションを開くのが基本

Ralph とマルチエージェント協調：AI を長時間安定して働かせるには

Mon, 27 Apr 2026 08:19:02 +0800

最近 coding agent を使っていると、すぐにひとつの現実的な問題にぶつかります。AI は確かに仕事をしてくれる。でも、どうすれば何時間も動かし続けても途中で脱線せず、要件を忘れず、同じ作業をやり直さずに済むのか。

Ralph やマルチエージェント協調をめぐる議論で本当に重要なのも、まさにこの点です。単にどのモデルが強いかを比べる話ではありません。より実用的な問いは、長いタスクでも AI が安定して動けるように、どうワークフローを設計するか です。

この問題を分解すると、よく出てくるルートは大きく 2 つあります。

Ralph 方式：新しいセッションを繰り返し起動し、ファイルシステムで文脈をつなぐ
マルチエージェント方式：リード Agent が調整し、子 Agent が分担して実行する

もっと平たく言えば、問われているのは「どのモデルが強いか」ではなく、「どう AI を組織して、継続的に成果を出す小さなチームのように動かすか」です。

01 なぜ長時間タスクは崩れやすいのか

短いタスクでは、多くの問題は表に出ません。指示を 1 つ出し、モデルが数ファイルを読み、少しコードを書き換えれば終わります。

ところがタスクが長くなると、問題が一気に表面化します。

会話が伸び続けてコンテキストが膨らむ
初期の要件が新しい情報に押し流される
ひとつの Agent が設計、実装、テストまで全部抱える
明確な受け入れ確認がないと、「終わった」と「終わったと言っているだけ」が混ざる

そのため、長時間 AI を動かすときに本当に問われるのは単発の出力性能ではなく、タスク分割、状態の受け渡し、役割分担、フィードバックループ です。

02 Ralph 方式：長いタスクを短いラウンドに分ける

Ralph の考え方は、まず「コンテキストがどんどん汚れていく」問題を解くのに向いています。

やっていることはシンプルです。

ループで新しい agent セッションを何度も起動する
各ラウンドでは十分小さなタスクを 1 つだけ扱う
ラウンドをまたぐ状態は会話ではなくファイルに置く

利点は明快です。毎回 fresh context から始まるので、1 ラウンドごとの集中が保ちやすく、過去の履歴に引きずられにくくなります。

Ralph 系のプロジェクトを見たことがあるなら、構造はかなり一貫しています。

現在のタスクは構造化ファイルに書く
途中の学びは進捗ファイルに残す
コードの変化は git 履歴に残す

つまり Ralph は、1 つの Agent に「全部を永遠に覚えさせる」ことを目指していません。記憶を意図的に外へ逃がし、セッションそのものを軽く保とうとします。

この種の方式は、特に次のような条件で相性がいいです。

作業がすでに小さな story に分けられている
各 story が 1 つの context window に収まる
プロジェクトに tests、typecheck、その他のチェックがある

これは AI を一歩ずつ安定して前に進めるにはどうするか という問題への答えです。

03 マルチエージェント方式：1 人では抱えきれない仕事を分担する

もうひとつのルートがマルチエージェント協調です。

この種のワークフロー設計でより有望なのは、リード Agent が自分で全部やるのではなく、調整役に回り、ほかの Agent が実装、テスト、確認、受け入れを分担する形です。

ここが Ralph との大きな違いです。

Ralph は直列の反復に近い
マルチエージェントは並列の分業に近い

タスクの中に自然な役割分担があるなら、マルチエージェントのほうが扱いやすくなります。たとえば次のように分けられます。

ひとりがタスク分解と実行計画を担当する
ひとりが実装する
ひとりがテストして検証する
ひとりが結果が最初の要件に合っているか見直す

大事なのは、ただウィンドウを増やすことではありません。価値があるのは役割を分離することです。もともと 1 つの Agent に押し込んでいた仕事を、より明確な段階に分けられます。

役割の境界がはっきりすると、いくつかの問題が軽くなります。

書く人とレビューする人を分けられる
テストする側が毎回ゼロから要件を再構築しなくていい
リード Agent が実装詳細に埋もれにくい

これは AI を小さなチームのように協調させるにはどうするか という問題への答えです。

04 本当に重要なのは並列化ではなく、どう分けるか

Ralph を使うにしてもマルチエージェントを使うにしても、見落とされやすいのはこの点です。大事なのは Agent の数より、ワークフロー設計の質です。

タスク分解が悪ければ、Agent を増やしても混乱を並列化するだけです。

より安定しやすい分け方には、だいたい次の特徴があります。

1 タスクに 1 つの明確な目標がある
1 役割に 1 種類の出力責任がある
各ラウンドに明確な完了条件がある
前のラウンドの成果が次のラウンドでそのまま使える

たとえば「機能を全部作って」と一気に投げるより、次のように段階を切るほうが安定しやすいです。

まず要件と境界を分ける
次に実装を分ける
次にテストを分ける
最後に受け入れ確認を独立させる

この分け方の利点は、問題が起きたときに、理解、実装、テスト、受け入れ基準のどこに原因があるのか見つけやすいことです。

05 なぜ受け入れ確認が重要なのか

多くの AI ワークフローが崩れるのは、前半で何もしていないからではありません。最後に、本当に独立した確認ステップがないからです。

長いタスクでは、「結果が生成された」と「その結果が本当に使える」のあいだに、かなり大きな差があることがよくあります。

だからこそ、開発と受け入れを分けて考える方向が重要です。複雑な仕組みにしなくても、少なくとも次の問いは独立して投げる価値があります。

最初のタスクを本当に完了しているか
表面だけ直して根本原因を残していないか
テストが都合のいい経路だけを見ていないか
上流の要件を途中で勝手に変えていないか

この層が欠けると、AI は長いフローの中で何度でも「成功した」と自己申告しがちです。

06 どう選ぶべきか

手早い目安としては、次のように考えられます。

いちばん痛いのがコンテキスト肥大化や長セッションの失焦なら Ralph
いちばん痛いのが 1 つの Agent に役割を詰め込みすぎていることならマルチエージェント

もう少し具体的に言うと、

Ralph は、流れが明快で、粒度が細かく、ラウンド単位で進めやすい仕事に向く
マルチエージェントは、役割分担が明確で、並行処理や相互検証が必要な仕事に向く

実際には、この 2 つは対立するものではありません。むしろ成熟したやり方は組み合わせです。

外側は Ralph のような反復ループで大きなタスクを進める
内側は各ラウンドでマルチエージェントを使い、調査、実装、テスト、受け入れを分担する

こうすれば、長いコンテキストの制御と、1 ラウンド内の協調効率を両方取りにいけます。

07 ひとことでまとめると

これらの方法が重要なのは、Ralph やマルチエージェントそのものを単独で推しているからではありません。むしろ、ひとつの現実的な事実をはっきりさせているからです。AI を長時間安定して働かせる鍵は、モデル単体の強さよりも、コンテキスト、タスク、役割、受け入れ確認をどう設計したかにある。

すでに Claude Code、Codex、そのほかの coding agent に長めの実タスクを任せ始めているなら、こうしたワークフロー発想は「もっと強いモデルに替える」より優先して学ぶ価値があります。

Ralph とは何か：Claude Code と Amp を反復実行できる自律開発フローに変える方法

Mon, 27 Apr 2026 08:08:55 +0800

最近、coding agent の長時間ワークフローに注目しているなら、snarktank/ralph は一度見ておきたい小さなプロジェクトです。これは新しいモデルのラッパーでも、チャット UI をもう一枚かぶせたものでもありません。Claude Code や Amp を autonomous loop として組み立て、PRD にある story を 1 つずつ進め、すべて終わるまで回し続ける仕組みです。

核になる発想はかなりシンプルです。同じ agent を、どんどん長くて汚れていくコンテキストの中で無理に走らせ続けないこと。代わりに、各イテレーションごとに新しい AI coding session を立ち上げること。これによって、コンテキストの膨張を抑えつつ、タスク境界もはっきりします。

01 Ralph とは何か

Ralph の公式な位置づけは明快です。PRD の項目が完了するまで、AI coding tool を繰り返し実行する autonomous AI agent loop です。

現在のリポジトリでは、次の 2 つのツールに対応しています。

Amp CLI
Claude Code

各イテレーションでは fresh instance が起動されます。つまり、1 本の会話を延々と伸ばし続けるのではなく、次のような外部状態に記憶を持たせます。

git 履歴
progress.txt
prd.json

ここが重要です。大きなタスクを agent に長く走らせるときの問題は、モデルがコードを書けないことではない場合が多いです。むしろ、会話が重くなり、コンテキストを落とし、要件を忘れ、同じ作業を繰り返しやすくなることのほうが大きい。Ralph は、ほぼこの問題に正面から向き合って設計されています。

02 どう動くのか

Ralph のワークフローは 3 段階です。

1. まず PRD を作る

README では、まず付属の prd skill を使って要件書を作り、機能を小さめの story に分割することを勧めています。

2. PRD を `prd.json` に変換する

次に ralph skill を使って、Markdown の PRD を構造化された prd.json に変換します。このファイルには user stories と、それぞれが通過済みかどうかが記録されます。

3. ループスクリプトを実行する

実際の実行を担うのは ralph.sh です。コマンドはおおむね次の形です。

1
2

./scripts/ralph/ralph.sh [max_iterations]
./scripts/ralph/ralph.sh --tool claude [max_iterations]

デフォルトは 10 イテレーションです。各ラウンドではおおよそ次のことを行います。

branchName からブランチを作る
passes: false で最優先の story を選ぶ
その story だけを実装する
typecheck や tests などの品質チェックを走らせる
チェックを通過したらコミットする
prd.json を更新する
学びを progress.txt に追記する
次のラウンドへ進む

つまり Ralph は、すべてを一気に終わらせようとはしません。1 つのコンテキストウィンドウに収まる小さなループへと仕事を圧縮していくわけです。

03 Ralph の面白いところ

1. 毎回 fresh context を使う

これが Ralph のいちばん中心的な設計です。README でも、各イテレーションは新しい AI instance であり、イテレーション間の記憶は git、progress.txt、prd.json にしか残らないと強調されています。

これは、Claude Code などを 1 本の長い会話の中で使い続ける一般的なやり方とはかなり違います。後者はタスクが大きくなるほど履歴に引きずられて重くなり、少しずつ焦点を失いがちです。Ralph は、1 回の実行ですべてを覚えさせることを諦め、その代わりに記憶をファイルに逃がします。

2. タスクを小さく保つことを前提にしている

ドキュメントでは、各 PRD item は 1 つの context window で終えられる大きさでなければならないと明言されています。たとえば、フィルターを 1 つ追加する、server action を更新する、DB のカラムを 1 本足す、といった粒度は適切です。一方で、API 全体の再設計やダッシュボード全体の構築は大きすぎます。

この制約はとても現実的です。多くの autonomous agent loop が崩れる理由は、loop そのものではなく、タスク分割が粗すぎて 1 ラウンドに抱え込む量が多すぎることにあります。

3. コードだけでなく学びも残す

progress.txt だけでなく、README は AGENTS.md の更新も強く勧めています。理由は単純で、今後のイテレーションや将来の開発者がそのメモを読むからです。各ラウンドで見つかったパターン、注意点、慣習は、プロジェクト文書として残しておいたほうがいい。

言い換えると、Ralph は agent に継続してコードを書かせるだけでなく、コードベースに対する作業記憶も蓄積させようとしています。

04 どんな場面に向いているか

次のような条件なら、Ralph はかなり相性がいいです。

すでに明確な user stories に分解できている
テスト、typecheck、CI のような信頼できるフィードバックループがある
1 本の長い会話に全部を押し込まず、agent を継続的に前進させたい
一発完了より、反復で少しずつ進む形を受け入れられる

逆に、要件がまだ曖昧だったり、議論を何度も往復しながら方向を頻繁に変える必要がある作業では、Ralph は最初の選択肢ではないかもしれません。要件が固まり、実装を安定して前に進めたい段階のほうが向いています。

05 普通の Claude Code 利用と何が違うか

ふつうに Claude Code を使う場合は、1 つのセッションを開いて、そこからコードを読み、編集し、コマンドを実行し続ける形が一般的です。これは小規模から中規模の作業では非常に便利ですが、大きな作業になると次の 2 点が問題になりやすいです。

コンテキストが伸び続ける
途中の判断が構造化された形で残りにくい

Ralph は Claude Code や Amp を、より「バッチ実行器」に近いものへ変えます。

タスクの起点は都度の会話ではなく prd.json
各ラウンドが扱うのは 1 つの story だけ
完了状態はファイルへ書き戻される
学びは progress.txt に残る
コード変更は git に残る

その意味で、これは新しい AI assistant というより、coding agent の上にイテレーション制御を追加する仕組みと見たほうが近いです。

06 ひとつ重要な前提

Ralph がうまく機能するかどうかは、loop 自体よりもフィードバックループの質に左右されます。README もかなり率直で、typecheck、tests、CI がないと、エラーは後続イテレーションで積み重なっていくと書いています。

フロントエンド作業については、acceptance criteria にブラウザ検証を含めることまで勧めています。実際の確認がないと、agent は「見た目上は終わった」と「本当に動く」を簡単に混同してしまうからです。

ここは大事です。Ralph は magical automation ではありません。むしろ、すでに持っている開発の規律を増幅する仕組みに近いです。タスク分割が明快で、チェックがしっかりしているプロジェクトほど価値が出ますし、その土台がないなら、混乱を繰り返し増幅するだけになりかねません。

07 ひとことでまとめると

Ralph の価値は、大規模な新基盤を作ったことではありません。シンプルだけれど実用的な発想を、すぐ使えるフローに落とし込んだところにあります。Claude Code や Amp に各ラウンドで十分小さな story を 1 つだけ扱わせ、fresh context で集中させつつ、git、prd.json、progress.txt で継続性を保つ。

もし、すでに coding agent を実プロジェクトで使い始めていて、「長いタスクをどう安定して前に進めるか」で悩んでいるなら、Ralph のやり方はかなり参考になります。

参考リンク

GitHub リポジトリ: https://github.com/snarktank/ralph
インタラクティブなフローチャート: https://snarktank.github.io

nuwa-skill: 「ある人を蒸留する」を発想から実行可能なワークフローへ

Wed, 22 Apr 2026 16:20:00 +0800

[alchaincyf/nuwa-skill](https://github.com/alchaincyf/nuwa-skill) を見ると、まず「AI に有名人の口調で答えさせるものだろう」と思うかもしれません。ですが本当に面白いのは、どれだけ似ているかではありません。このプロジェクトは「ある人がどう考えるかを蒸留する」ことを、繰り返し実行できるワークフローにしようとしている点にあります。

それが成立すれば、価値は単なる面白いキャラクター prompt をいくつか作ることにとどまりません。ある人の判断フレーム、注目点、よく使うヒューリスティック、表現の癖を、何度も呼び出せる skill として定着させられるからです。欲しいのは「その人が言いそうな一文」ではなく、「その人ならこの問題をどう見て、何を優先し、何を疑うか」に近い作業インターフェースです。

これは「模倣」ではなく「モデリング」を解く

いわゆる人物 prompt の多くは、本質的にはスタイルの上貼りです。

よくある指示は次のようなものです。

ある人物の口調で話す
その人の決まり文句を多く使う
公開発言の言い回しをできるだけ真似する

こうしたやり方はデモでは目を引きますが、実務に入ると崩れやすいです。理由は単純で、口調は表層であり、判断構造こそが核だからです。人物に識別性があるのは、好んで使う単語があるからではなく、問題に向き合うときに一定の切り込み方をするからです。

nuwa-skill の方向性は、そうした「安定した方法」を抽出することに近いです。言い換えれば、関心があるのは「どうすればその人っぽく話せるか」ではなく、「どうすればその人っぽく考えられるか」です。

より完全なワークフロー

リポジトリの説明を見ると、nuwa-skill が目指しているのはエンドツーエンドの流れです。人名を入力すると、自動で調査、抽出、検証を行い、その結果を Claude Code で呼び出せる skill としてまとめる、という形です。

この考え方にはいくつか重要な変化があります。

第一に、蒸留対象は自分のチームの同僚でなくてもよいという前提です。この種の発想に初めて触れると、「優秀な同僚のやり方を残す」ことをまず思い浮かべる人が多いでしょう。それにも価値はありますが、学習サンプルが限られ、内部の経験に偏りやすいという境界もあります。nuwa-skill は対象をもっと広げ、起業家、投資家、科学者、プロダクトマネージャー、書き手のような人たちまで含めています。

第二に、強調されているのは手作業で prompt を組み立てることではなく、「自動で完了する」ことです。この手の能力を実用化するうえで本当に大事なのは、華やかな prompt 文ではなく、資料収集、観点の整理、パターン抽出、結果の検証を安定して回せるかどうかです。どこか一工程でも全面的に手作業へ依存すると、再利用コストは急激に上がります。

第三に、出力を一度きりの会話ではなく skill にしようとしていることです。前者なら繰り返し呼び出し、組み合わせ、改善できます。後者はその場の文脈でしか効かず、数ターンで崩れがちです。

なぜこの方向に注目する価値があるのか

AI を質問応答マシンとして見るなら、自然な使い方は「答えをください」です。ですが AI を作業台として見るなら、問いは「この問題を見る方法をください」に変わります。

nuwa-skill の価値は後者に寄っています。

たとえばプロダクトの意思決定に向き合うとき、欲しいのは一つの正解ではなく、鋭く異なる複数の分析フレームかもしれません。

長期的な複利から見る人
リソース制約から見る人
ユーザー体験の一貫性から見る人
市場参入のタイミングから見る人

こうしたフレームを安定してパッケージ化できれば、AI の役割は「文章を一段落書くもの」から「視点を素早く切り替えるもの」へ変わります。これは名言の模倣よりずっと実用的です。なぜなら、意思決定の質に直接効くからです。

最も魅力的な点: 暗黙知を呼び出せる資産に変えること

価値の高い能力ほど、そもそも SOP に書きにくいものです。

ある人の判断がなぜ他の人よりも的確なのかは、多くの場合、明示的なルールをたくさん知っているからではありません。長い実践の中で、暗黙のフィルタリング機構を作ってきたからです。

どのシグナルを優先して見るか
どのノイズをすぐ切り捨てるか
どの問いを分解して考えるか
どの問いを反転させてみるか
どの結論はさらに証拠を待つべきか

こうした能力は、本人でも常に明快に言語化できるとは限らないため、普段は残しにくいです。だからこそ、構造化して抽出できるなら価値が高い。nuwa-skill が惹きつけるのはこの点です。表層的な知識移送ではなく、認知習慣の再構成を扱おうとしているのです。

どんな場面に向いているか

この種の skill は、特に次のような場面で有効だと思います。

1. 意思決定前の多視点レビュー

すでに案はあるものの、自分が慣れた道筋でしか考えていない気がするとき、異なる「人物視点」に切り替えて同じ問題を見直す方が、元の文章をそのまま膨らませるより価値があります。

2. 特定タイプの達人の判断フレームを学ぶ

達人から学ぶとき、多くの人は名言を集め、インタビューを見て、要約を写します。しかし最後に残るのは、たいてい数個の印象的な言葉だけです。思考パターンを skill 化できれば、学び方は「実際の問いを持ち込んで何度も呼び出す」ものに近づき、「静的な抜き書きを大量に作る」ことから離れます。

3. チームで分析スタイルを共有する

チームに本当に不足しがちなのは、文書そのものではなく、「私たちは問題にぶつかったとき普段どう考えるか」という共有です。この流れが成熟すれば、組織内の強い実務家の方法論を残す用途にも逆向きで使えるでしょう。ただ、このプロジェクトがそれだけに能力を閉じ込めるつもりではないことは明らかです。

この種のプロジェクトで本当に難しいこと

もちろん、方向性が魅力的だからといって、難題が解けたわけではありません。

本当の難しさは skill をインストールすることではなく、むしろ次の点にあります。

情報源が十分に信頼できるか
抽出されたパターンが安定しているか、単なる断片的な語料の錯覚ではないか
モデルが人物のフレームを使って分析しているのか、それとも一般的な印象をなぞっているだけなのか
複数の人物の境界がモデル内部で曖昧にならないか

つまり本当に重要なのは、「もっともらしい文章を出せるか」ではなく、「この skill が生む認知フレームが多様なタスクに耐えて再利用できるか」です。今後、検証工程がさらに深まれば、この種のプロジェクトの信頼性は大きく上がるはずです。

なぜこれは「prompt テンプレート集」より一歩先なのか

これまで多くのプロジェクトは、この能力をテンプレート集として扱ってきました。人物ごとに一つ prompt を用意し、ユーザーがコピーして使う形です。しかしテンプレート集は本質的に静的資産であり、更新は遅く、検証は弱く、完全な制作フローにもなりにくいです。

nuwa-skill が一歩進んでいるのは、「人物蒸留」をテンプレートの問題からワークフローの問題へ進めている点です。

重心が「prompt を一つ書く」ことから、「人物 skill をどう体系的に生成し、検証し、改善するか」へ移ると、この営みはひらめきよりも工学に近くなります。長く使いたい人にとって重要なのは、明らかにこちらです。

結び

nuwa-skill が面白いのは、AI を有名人のものまねショーにしたからではありません。「ある人の考え方をどう学ぶか」を、実行可能で、再利用できて、反復改善できる方向へ一歩進めたからです。

多くの人物 prompt が解いているのが「誰かのように話す」ことだとすれば、このプロジェクトが解こうとしているのは「誰かのように問題を見る」ことです。前者はデモ向きで、後者こそ生産性ツールに近いと言えます。

参考リンク

GitHub リポジトリ: https://github.com/alchaincyf/nuwa-skill
プロジェクト説明: https://github.com/alchaincyf/nuwa-skill/blob/main/README.md
Skill 定義: https://github.com/alchaincyf/nuwa-skill/blob/main/SKILL.md

RAGFlowプロジェクト整理：オープンソースRAGエンジンの機能と使い方

Wed, 15 Apr 2026 22:09:25 +0800

RAGFlow は infiniflow によるオープンソースの RAG（Retrieval-Augmented Generation）エンジンです。単なる「ドキュメントをアップロードして質問する」ための薄いナレッジベース外殻ではなく、ドキュメント解析、チャンク分割、検索、リランキング、引用の追跡、モデル設定、Agent 機能、API 統合までを一つのワークフローにまとめることを目指しています。

企業向けナレッジベース、ドキュメント Q&A、サポートアシスタント、社内情報検索、あるいは LLM により信頼できるコンテキスト層を持たせたい場合、RAGFlow は重点的に見る価値のあるオープンソース案の一つです。

01 RAGFlow は何を解決するのか

一般的な RAG システムがぶつかりやすい問題は主に三つあります。

ドキュメント解析の品質が安定しない。特に PDF、スキャン文書、表、画像、複雑なレイアウトで起きやすい。
チャンク分割戦略が見えにくく、検索ヒットはしていても実際の文脈が不完全になりやすい。
回答に信頼できる引用がなく、利用者が出典を確認しにくい。

RAGFlow はまさにこの部分に力を入れています。README では Deep document understanding、テンプレート化されたチャンク分割、チャンクの可視化、引用のグラウンディング、多経路検索とリランキングが強調されています。つまり、単にベクトルデータベースとチャット UI をつなぐのではなく、「高品質な入力が高品質な回答につながる」ことを重視しているということです。

02 主な機能

1. 高度なドキュメント理解

RAGFlow は複雑な非構造化データから知識を抽出できます。README に挙げられている形式には Word、PPT、Excel、TXT、画像、スキャン文書、構造化データ、Web ページなどがあります。

これは企業ナレッジベースにとって非常に重要です。現実の資料はきれいな Markdown ではなく、契約書、レポート、表、スキャン PDF、製品マニュアル、スクリーンショット、Web ページが混在していることが多いからです。解析品質が低いと、その後のベクトル検索も LLM の回答も弱くなります。

2. テンプレート化されたチャンク分割

RAGFlow はテンプレートベースの chunking を提供します。ここでの価値は、チャンク分割がブラックボックスではなく、文書タイプに応じてより適切な戦略を選べることです。

たとえば通常の記事、論文、表、Q&A 文書、画像説明、契約条項では、チャンクの粒度や境界の考え方が異なります。テンプレート化された分割により、「文が途中で切れる」「表の文脈が失われる」「見出しと本文が分かれてしまう」といった問題を減らせます。

3. 追跡可能な引用

RAGFlow は grounded citations を重視しています。つまり、回答がどのソース断片に基づくのかを追えるということです。さらにチャンクの可視化もあり、解析結果やチャンク分割結果を人が確認して調整しやすくなっています。

これは本番環境では特に重要です。企業内 Q&A は、ただ「それっぽい答え」を返せばよいわけではなく、検証可能である必要があります。ポリシー、コンプライアンス、財務、技術文書、サポート情報のような分野では、引用と追跡性はほぼ必須です。

4. 自動化された RAG ワークフロー

RAGFlow は RAG の一連の流れを、より完成度の高いワークフローとしてまとめています。

ナレッジベースの作成
データのアップロードまたは同期
ドキュメント解析
チャンクの確認と調整
LLM と embedding モデルの設定
多経路検索とリランキングの実行
チャットアシスタントの構築
API 経由で業務システムへ統合

このため、単なるライブラリというより RAG プラットフォームに近い存在です。チームにとっては UI と API の両方が有用で、非エンジニアはナレッジベースを保守しやすく、エンジニアは既存システムへ組み込みやすくなります。

5. Agent、MCP、ワークフロー拡張

最近の RAGFlow には Agentic workflow、MCP、Agent Memory、コード実行コンポーネントなども含まれています。これは、従来型のナレッジベース Q&A にとどまらず、Agent シナリオにも広がっていることを示しています。

典型的には、Agent が信頼できる企業知識レイヤーとして RAGFlow を使い、必要なときにナレッジベースから検索し、引用付きで回答を生成し、必要に応じてツール呼び出しやワークフローと組み合わせる、という形です。

03 基本的な利用フロー

公式のクイックスタートに沿うと、RAGFlow の一般的な使い方は次のようにまとめられます。

1. 実行環境を準備する

README にある基本要件は以下の通りです。

CPU >= 4 cores
RAM >= 16 GB
Disk >= 50 GB
Docker >= 24.0.0
Docker Compose >= v2.26.1

コード実行用のサンドボックスを使う場合は gVisor も必要です。また、公式 Docker イメージは主に x86 向けです。ARM64 を使う場合は、公式ドキュメントに従って自分でイメージをビルドする必要があります。

2. プロジェクトを取得する

1
2

git clone https://github.com/infiniflow/ragflow.git
cd ragflow/docker

3. `vm.max_map_count` を確認する

RAGFlow のデプロイは Elasticsearch / OpenSearch のようなコンポーネントに依存するため、Linux では通常次を確認します。

`1`	`sysctl vm.max_map_count`

値が 262144 未満なら、一時的に次で設定できます。

`1`	`sudo sysctl -w vm.max_map_count=262144`

再起動後も維持したい場合は /etc/sysctl.conf に追加します。

4. Docker Compose で起動する

CPU モードはそのまま起動できます。

`1`	`docker compose -f docker-compose.yml up -d`

DeepDoc を GPU で高速化したい場合、README では .env に DEVICE=gpu を追加してから起動する方法が示されています。

1
2

sed -i '1i DEVICE=gpu' .env
docker compose -f docker-compose.yml up -d

起動後はログを確認します。

`1`	`docker logs -f docker-ragflow-cpu-1`

サービスが立ち上がったら、ブラウザでサーバーのアドレスを開きます。デフォルト構成では通常次のようになります。

`1`	`http://IP_OF_YOUR_MACHINE`

5. モデル API Key を設定する

RAGFlow では LLM と embedding モデルの設定が必要です。README では service_conf.yaml.template 内でデフォルトの LLM factory を選び、対応する API_KEY を更新する流れが説明されています。

実際には、使うプロバイダーに合わせて次を設定します。

チャットモデル
embedding モデル
rerank モデル
PDF / DOCX 内の画像も理解したい場合はマルチモーダルモデル

6. ナレッジベースを作成して文書を取り込む

サービス起動後の典型的な流れは次の通りです。

Web UI にログインする。
dataset / knowledge base を作成する。
文書をアップロードするか、データソース同期を設定する。
解析完了を待つ。
チャンク結果を確認し、必要なら調整する。
チャットアシスタントを作成し、知識ベースを関連付ける。
回答品質と引用元を確認する。

業務システムに組み込みたい場合は、RAGFlow の API や SDK を使って、検索とチャット機能を自分のアプリに接続できます。

04 向いている場面

RAGFlow は次のような用途に向いています。

企業内ナレッジベース Q&A
製品マニュアル、技術文書、FAQ の検索
カスタマーサポートや営業支援アシスタント
契約書、レポート、規程文書に対する追跡可能な Q&A
複数形式の資料を一元的に扱いたい場合
UI による運用と API 統合の両方が必要なチーム
Agent のコンテキスト層として RAG を使いたいシステム

特に、文書形式が複雑で、引用が重要で、人が解析結果を確認・調整したい場合に向いています。

05 使うときの注意点

第一に、RAGFlow は軽量スクリプトではありません。ある程度のインフラ要件があります。公式の推奨は最低 4 コア CPU、16GB RAM、50GB ディスクです。少量の Markdown に対して Q&A をしたいだけなら、ここまで大きなプラットフォームは不要かもしれません。

第二に、文書品質は依然として重要です。RAGFlow は解析やチャンク分割を改善できますが、質の低い資料、古い資料、矛盾する資料を自動で信頼できるものに変えることはできません。本番導入前にはナレッジベースの運用設計が必要です。

第三に、モデル設定は結果に直結します。embedding、rerank、チャットモデル、マルチモーダルモデルの選択は、検索品質と回答品質の両方に影響します。RAGFlow はワークフローを提供しますが、最終的な品質はデータ、モデル、パラメータ調整の組み合わせで決まります。

第四に、本番環境では権限とデータセキュリティに注意が必要です。企業ナレッジベースには社内文書が含まれることが多いため、デプロイ方式、アクセス制御、ログ、API Key、モデル提供者側のデータポリシーまで事前に設計するべきです。

06 短い判断

RAGFlow の強みは、RAG で最も面倒な部分をプラットフォーム機能としてまとめていることです。複雑な文書解析、説明可能なチャンク分割、引用のグラウンディング、多経路検索、リランキング、モデル設定、Web UI、API、Agent 拡張までを一式で備えています。

検証可能で保守しやすく、業務システムにも接続できる企業ナレッジベースを作りたいなら、RAGFlow は「ベクトルデータベース + 簡単なチャット UI」より完成度の高い選択肢です。逆に、個人用途の小規模な Q&A や、扱うデータ形式が非常に単純な場合は、より軽量な RAG フレームワークのほうが扱いやすいかもしれません。

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はツール箱に入れておく価値があります。逆に、固定サイトから低コストで大量収集するだけなら、従来のクローラーや専用パーサーのほうが適している場合があります。

OpenHarness とは: このオープンソースの Agent Harness では何ができるのですか?

Sun, 12 Apr 2026 23:45:00 +0800

最近オープンソースの AI エージェントツールに注目している場合、HKUDS/OpenHarness は注目に値する新しいプロジェクトです。これは単なる「チャットシェル」ではなく、実行可能、スケーラブル、管理可能なエージェントインフラストラクチャをオープンソースの エージェントハーネスに分離します。

公式 README によると、OpenHarness は主に、ツールの呼び出し、スキルの読み込み、メモリメカニズム、権限管理、マルチエージェントの調整など、軽量のエージェントの基本機能のセットを提供します。およびそれに付随する ohmo は、このインフラストラクチャ上に構築されたパーソナル AI アシスタントアプリケーションです。

01 オープンハーネスとは何ですか？

OpenHarness は、「大きなモデルに手、足、メモリ、境界をインストールする」ランタイム層として理解できます。

大規模なモデル自体は推論と生成に優れていますが、それを本当に長期間動作できるエージェントにしたい場合は、通常、次の周辺機能が必要です。

テキストを出力するだけでなくツールを調整する
ファイルの読み取りと書き込み、コマンドの実行、検索機能と Web 機能へのアクセス
長時間のセッションでもコンテキストとメモリを保持
危険な操作に対する権限の制御
大きなタスクを複数のサブエージェントに分割して並列処理する

OpenHarness の目標は、この「モデル周辺のエンジニアリング層」を、明確でオープンソースでチェック可能な Python 実装に変えることです。これは、特定のモデルや特定のチャットインターフェイスのみを強調するのではなく、エージェントの操作ベースに似ています。

02 本プロジェクトの基本機能

現在の GitHub ホームページと README から判断すると、OpenHarness のコア機能は主に次の領域に集中しています。

1. Agent Loop

これは、エージェントが継続的に動作できるコア実行ループです。公式ハイライトは次のとおりです。

ストリーミングツール呼び出しループ
API の再試行と指数バックオフ
ツールの並列実行
トークンの統計とコストの追跡

この部分の重要性は、エージェントが単なる「1 つの質問と 1 つの回答」ではなく、継続的に観察し、考え、ツールを呼び出し、結果を読み取り、タスクの次のステップに進むことができることです。

2. ツール、スキル、プラグインシステム

OpenHarness により、ツール層が比較的完全になりました。プロジェクトのホームページには、ファイル、シェル、検索、Web ページ、MCP などのツールが組み込まれており、オンデマンドでの Markdown スキルファイルの読み込みをサポートしていると記載されています。

その価値は「より多くのツール」だけではありませんが、さらに重要なのは、その組み合わせ方法が比較的オープンであることです。

組み込みツールを直接使用可能
スキルはタスクごとにロード可能
フック、スキル、エージェントはプラグインを通じて拡張可能
anthropics/skills および関連プラグインエコロジーと互換性があります

このレイヤーは、毎回プロンプトによる一時的な説明に依存するのではなく、特定の固定プロセスを再利用可能な機能にまとめたい場合に役立ちます。

3. コンテキストと記憶

この部分は OpenHarness の重要な差別化ポイントです。公式キーワードには次のようなものがあります。

CLAUDE.md の検出と挿入
自動コンテキスト圧縮
MEMORY.md 永続メモリ
セッションの回復と履歴の継続

これは、現在のラウンドの入力を処理するだけでなく、「プロジェクトのコミットメント」、「過去のタスク」、および「長期的な設定」を保持しようとすることを意味し、エージェントを毎回最初から開始するのではなく、継続的な作業により適したものにします。

4. 当局のガバナンスとセキュリティ境界

エージェントが実際にファイルシステム、端末、ネットワークに入った後は、ガバナンスが非常に重要になります。 OpenHarness はこのセクションで次のことを提供します。

マルチレベル権限モード
パスとコマンドベースのルール制御
PreToolUse / PostToolUse hooks
インタラクティブな承認ポップアップウィンドウ

簡単に言うと、エージェントが「できること」だけでなく、「直接実行できることと、最初に確認しなければならないこと」を考慮します。

5. マルチエージェントの調整

OpenHarness は、処理のためにタスクをサブエージェントにオフロードすることもサポートしています。現在の公開情報で言及されている機能には次のものが含まれます。

サブエージェントの作成と委任
チーム登録とタスク管理
バックグラウンドタスクのライフサイクル管理

複雑なタスクの場合、これは、1 つのエージェントに依存して逐次的に進めるだけでなく、並行して共同作業を試みることもできることを意味します。

6. マルチプロバイダーのワークフロー

OpenHarness は現在、プロバイダーを単なる基盤となる API 名とは見なさず、それをワークフロー + プロファイルに抽象化します。 README によると、現在サポートされている指示は次のとおりです。

Claude / Anthropic-compatible
OpenAI-compatible
Codex Subscription
GitHub Copilot
Moonshot (Kimi)、GLM、MiniMax、およびその他の互換性のあるバックエンド

これにより、特定のサービスプロバイダーに束縛されるのではなく、「マルチモデル、マルチエントリー」エージェント実行フレームワークに似たものになります。

7. React TUI と非対話型モード

OpenHarness にはターミナルの対話型インターフェイスが付属しており、oh を実行した後に React/Ink TUI に入ることができます。公式の README には、以下をサポートしていると記載されています。

コマンドセレクター
許可の確認
機種切り替え
プロバイダースイッチ
セッションの再開

対話型インターフェイスに入りたくない場合は、結果を標準出力、JSON、またはストリーミング JSON に出力するなど、非対話モードで単一のタスクを直接実行することもできます。これは、スクリプト作成や自動化のシナリオに適しています。

03 `ohmo`とは

OpenHarness が基盤となるインフラストラクチャである場合、ohmo は、このインフラストラクチャ上に構築された「パーソナルエージェントアプリケーション」です。

ohmo の位置付けはプロジェクトのホームページで非常に明確です。これは通常のチャットボットではなく、長時間の会話でも機能し続けるパーソナルアシスタントです。公式説明には、Feishu、Slack、Telegram、Discord、その他のチャネルでユーザーと対話し、次のようなタスクを実行できると記載されています。

フォークブランチ
コードを書く
テストの実行
PRを始める

さらに、README では、ohmo は既存の Claude Code または Codex サブスクリプション上で実行でき、必ずしも新しい API キーの追加アプリケーションを必要としないことも強調しています。これらのサブスクリプションツールをすでに使用しているユーザーにとって、これは比較的参入障壁が低いです。

04 どんなシーンに適していますか？

このプロジェクトで現在公開されている機能から判断すると、OpenHarness は次のタイプの人々に適しています。

本番レベルのエージェントがどのような基本モジュールで構成されているかを調べたいと思っています。
スケーラブルなオープンソースのエージェントオペレーティングレイヤーを自分で構築したい
ツール、スキル、メモリ、権限、マルチエージェントの調整を同じフレームワークに組み込みたい
単一のモデルメーカーや単一の顧客フォームに束縛されたくない
既製のアーキテクチャに基づいた垂直分野のエージェントまたはパーソナルアシスタントであり続けたいですか?

あなたの目標が単に「直接チャットできる完成したアシスタントを見つける」ことである場合、OpenHarness オントロジーは最も軽い選択肢ではないかもしれません。ただし、エージェントのインフラストラクチャ、エンジニアリングの制御性、およびその後の拡張にもっと関心がある場合は、このプロジェクトを検討する価値があります。

05 位置付けをすぐに理解する

一文の要約:

**OpenHarness は、大規模なモデルを実際にタスクを実行できるエージェントに変換する責任を負い、ohmo は、この一連の機能を、長期間使用できるパーソナルアシスタントにパッケージ化する責任があります。 **

2 つのレイヤーに分割して確認することもできます。

OpenHarness: オープンソースの Agent Harness、本質はインフラストラクチャです
ohmo: このインフラストラクチャ上に構築されたパーソナルエージェントアプリ

2026 年 4 月 12 日の時点で、プロジェクトの GitHub ホームページには、更新が v0.1.6 (2026 年 4 月 10 日) に進み、引き続き自動コンテキスト圧縮、MCP 転送機能、React TUI、およびマルチエージェント実行の安定性に重点が置かれていることが示されています。これは、まだ急速な進化段階にあることを示していますが、方向性はすでに非常に明確です。

参考リンク

GitHub プロジェクトのホームページ: https://github.com/HKUDS/OpenHarness
英語の README: https://github.com/HKUDS/OpenHarness/blob/main/README.md
中国語の README: https://github.com/HKUDS/OpenHarness/blob/main/README.zh-CN.md

Playwright CLI の入門: インストール、スキル、セッション管理、および一般的なコマンド

Sun, 12 Apr 2026 14:36:58 +0800

現在、ブラウザ自動化に Claude Code、GitHub Copilot、またはその他のコーディングエージェントを使用している場合、microsoft/playwright-cli は注目に値する新しいツールです。これは、「コマンドを手動で入力するために使用される」従来の意味でのブラウザガジェットではなく、エージェントをコーディングするための Playwright CLI であり、トークンオーバーヘッドの低減、軽量のコマンドインターフェイス、およびスキルワークフローとの統合を重視しています。

公式 README から判断すると、Playwright CLI の核となる考え方は非常に明確です。モデルコンテキストに多数のツールスキーマとページ構造を詰め込む MCP と比較して、CLI コマンド方式はよりコンパクトで、大規模なコードベース、テストタスク、ブラウザ自動化の間を行き来するエージェントワークフローにより適しています。

01 Playwright CLIとは何ですか?

playwright-cli は、Microsoft がオープンソース化した Playwright コマンドラインツールです。公式説明は「一般的な Playwright アクション用の CLI」です。主に次のことを実現するために使用されます。

ページを開いてブラウザを起動します
Playwright コードを記録して生成する
ページのスナップショットを取得し、要素の参照を取得します
スクリーンショット、PDF のエクスポート
コーディングエージェントと連携して自動テストとWebページ運用を行います。

現在の GitHub README では、これを非常に明確に位置づけています。コーディングエージェントを使用している場合は、Playwright MCP よりも CLI の方が適していることがよくあります。永続的な状態、豊富なイントロスペクション、長いエージェントループが必要な場合でも、MCP には価値があります。

言い換えれば、Playwright CLI は、人間のエンジニアが Web ページを手動でクリックするための単なるツールではなく、「AI コーディングアシスタントのためのブラウザ自動化インターフェイス」に近いものです。

02 そのメリットは何ですか?

1. エージェントのワークフローにさらに適した

公式READMEには、最初の利点がToken-efficientとして直接書かれています。データのページ全体を LLM コンテキストに強制的に組み込むのではなく、エージェントはより短く、より特殊なコマンドを通じてブラウザを操作できるようになります。

これはエージェントのコーディングにとって重要です。実際のプロジェクトでは、エージェントはブラウザを実行するだけでなく、コードの読み取り、ファイルの変更、テストの実行、ログの読み取りも行うためです。ブラウザツール自体が非常に「コンテキストを食べる」場合、全体の効率が大幅に低下します。

2. スキルを使って作業する能力

README では特に playwright-cli install --skills を強調しています。これは、公式がこれを単なるシェルツールとして捉えておらず、Claude Code や GitHub Copilot などのエージェントが直接利用できるスキルの入り口として設計していることを示しています。

ワークフロー自体がスキルに基づいて構築されている場合は、Playwright CLI への接続がより自然になります。

3. セッション管理が比較的完了している

Playwright CLI はセッションをサポートします。デフォルトでは、ブラウザプロファイルはメモリに保存され、同じセッション内の Cookie とストレージは複数の CLI 呼び出し間で保持されます。 --persistent が追加された場合、プロファイルをディスクにドロップし、ブラウザを再起動しても引き続き使用することもできます。

これにより、「コマンド 1 つでブラウザを開いて実行後に破棄する」というおもちゃのツールよりも実用的となり、継続的なデバッグやエージェントの長時間プロセスの実行にも適しています。

4. 視覚監視パネルが付属しています

playwright-cli show は README に含まれており、ダッシュボードを開いて実行中のすべてのブラウザーセッションを監視および制御するために使用されます。これは、ただやみくもに実行するのではなく、いつでも引き継ぎ、監視、トラブルシューティングを行うことができるため、エージェントがバックグラウンドで自動化されたタスクを実行するシナリオで役立ちます。

03 設置および環境要件

現在の GitHub README によると、Playwright CLI の基本要件は次のとおりです。

Node.js 18 以降
Claude Code、GitHub Copilot、またはその他のコーディングエージェント

インストールコマンドは以下のとおりです。

1
2

npm install -g @playwright/cli@latest
playwright-cli --help

ここには特に注意しなければならない非常に簡単な落とし穴があります。

現在推奨されている公式インストールは @playwright/cli です。
これを、npm 上の歴史的で非推奨となった古いパッケージ playwright-cli と混同しないでください。

つまり、実際にインストールする必要があるのは、古い時代からの同名の履歴パッケージではなく、スコープ指定されたパッケージです。

04 始め方

1. スキルをインストールする

コーディングエージェントに Playwright CLI を直接使用させたい場合は、最初にスキルをインストールすることが公式推奨されています。

`1`	`playwright-cli install --skills`

README には、Claude Code や GitHub Copilot などのツールがローカルにインストールされたスキルを使用することが明確に記載されています。

2. エージェントに CLI を直接呼び出させる

最初にスキルを処理したくない場合は、エージェントに CLI ヘルプ情報を直接読み取らせることもできます。

1
2

Test the "add todo" flow on https://demo.playwright.dev/todomvc using playwright-cli.
Check playwright-cli --help for available commands.

正式にはこの方法を「スキルレス操作」といいます。これは、スキルがプリインストールされていない場合でも、CLI 自己記述機能を通じてエージェントを駆動できることを意味します。

3. 最小限の工程を手動で体験

README には、開始するのに非常に適した一連の TodoMVC サンプルが含まれています。

playwright-cli open https://demo.playwright.dev/todomvc/ --headed
playwright-cli type "Buy groceries"
playwright-cli press Enter
playwright-cli type "Water flowers"
playwright-cli press Enter
playwright-cli check e21
playwright-cli check e35
playwright-cli screenshot

このコマンドセットの価値は、Playwright CLI がどのように対話するかをすぐに理解できることです。

open はページを開く責任があります
type および press は入力を担当します
check 要素参照を使用したチェックボックスの操作
screenshot 結果を保存

05 `--headed`、セッションおよびモニタリングパネル

`--headed`

Playwright CLI はデフォルトではヘッドレスです。ブラウザウィンドウを直接表示したい場合は、--headed を open に明示的に追加する必要があります。

`1`	`playwright-cli open https://playwright.dev --headed`

これは、セレクター、ログインプロセス、検証コードの前後のインタラクティブな観察のデバッグに便利です。

session

公式 README ではセッションの使用法が強調されています。異なるセッションを使用して、異なるプロジェクトまたは Web サイトを分離できます。

1
2
3

playwright-cli open https://playwright.dev
playwright-cli -s=example open https://example.com --persistent
playwright-cli list

エージェントを長時間動作させたい場合は、環境変数を直接指定することもできます。

`1`	`PLAYWRIGHT_CLI_SESSION=todo-app claude .`

一般的に使用されるセッション管理コマンドには次のものがあります。

1
2
3

playwright-cli list
playwright-cli close-all
playwright-cli kill-all

で：

list はすべてのセッションをリストするために使用されます
close-all は、すべてのブラウザを通常どおり閉じるために使用されます。
kill-all は、すべてのブラウザプロセスを強制的に終了するために使用されます。

監視パネル

ブラウザでエージェントが現在何を行っているかを確認したい場合は、次のコマンドを実行できます。

`1`	`playwright-cli show`

README によると、このダッシュボードには主に 2 つのビューがあります。

セッショングリッド: すべてのアクティブなセッションをワークスペースごとに表示し、ライブビュー、URL、ページタイトルを表示します。
セッションの詳細: 単一セッションのリアルタイムインターフェイスを表示し、マウスとキーボードを引き継ぐこともできます

これにより、Playwright CLI は「コマンドラインが利用可能」になるだけでなく、比較的成熟した可観測性も備えます。

06 最初に覚えるべき一般的なコマンドはどれですか?

Playwright CLI を初めて使用する場合は、最初からすべてのコマンドを覚える必要はありません。最初に次の中心点を覚えておくだけで十分です。

ページとインタラクション

playwright-cli open [url]
playwright-cli goto <url>
playwright-cli click <ref>
playwright-cli fill <ref> <text>
playwright-cli type <text>
playwright-cli hover <ref>
playwright-cli press <key>

ページ構造を取得する

playwright-cli snapshot
playwright-cli snapshot <ref>
playwright-cli snapshot --depth=N
playwright-cli eval <func> [ref]

後続の多くの操作は要素参照 ref に依存するため、snapshot は重要です。通常は、最初にスナップショットを取得し、次に返された要素番号を使用してクリック、入力、チェック、またはスクリーンショットの取得を行います。

出力結果

1
2

playwright-cli screenshot
playwright-cli pdf

タブページ

playwright-cli tab-list
playwright-cli tab-new [url]
playwright-cli tab-close [index]
playwright-cli tab-select <index>

07 どんな人に向いていますか？

次のいずれかのシナリオに該当する場合は、Playwright CLI を試してみる価値があります。

E2E テストに Claude Code、Copilot、またはその他のコーディングエージェントを使用している
ブラウザ自動化インターフェイスをより軽量にしたいが、コンテキストに多くのページ構造を詰め込みたくない場合
複数のコマンド間で同じブラウザセッションを維持したい場合
エージェントが Web ページタスクを自動的に実行するとき、いつでも監視パネルを開いて進行状況を観察したいと考えています。

「ブラウザの自動化がコーディングエージェントとどのように効果的に連携できるか」が仕事の焦点である場合、Playwright CLI は従来の人による手動のデバッグ方法よりも便利である可能性があります。

参考リンク

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

OpenClaw 脳に似た記憶アルゴリズム夢を見る: 機械は夢を見始めるが、人間は不眠症になる

Sun, 12 Apr 2026 12:41:34 +0800

大規模モデルの長期記憶は常に問題でした。コンテキストが蓄積すればするほど、情報が混乱しやすくなります。知的なエージェントはすべてを覚えているように見えますが、実際には、何が重要で、何が忘れるべきかを判断することがますます困難になります。

4 月 5 日、OpenClaw は新バージョンの実験機能「Dreaming」を開始しました。これは派手な名前ではなく、人間の睡眠プロセスを模倣する一連のバックグラウンド記憶構成メカニズムです。目標は非常に単純で、知的エージェントが目覚めた後により正確に記憶できるようにすることです。

01 睡眠アルゴリズム：記憶整理を3段階に分ける

夢を見ることは単にインデックスを作成することではなく、人間の睡眠中のさまざまな機能に対応して、記憶を 3 つの論理的な段階に編成します。

浅い睡眠: システムは最初に最近の会話と思い出の記録をスキャンし、重複の削除と予備的なスクリーニングを実行して、候補コンテンツを生成します。この段階では、一時的な保存のみが実行され、コアメモリファイル MEMORY.md は直接変更されません。

ディープスリープ: システムは、ルールに従って価値の高い情報のフィルタリングを開始します。最低の評価、最低のリコール数、最低の固有クエリ数を満たす情報のみが次のステップに進みます。書き込む前に、最新のログが再度比較され、古い内容が削除されます。最後に、結果は MEMORY.md に追加され、ディープスリープの概要が DREAMS.md に残ります。

急速眼球運動段階 (REM): 記憶が定着した後、システムはさらに短期の行動追跡を分析し、異なる情報間の潜在的なつながりを探し、パターンの要約と反映内容を生成します。この部分は、エージェントが複雑なタスクを処理するときに全体の状況をより簡単に把握できるように、専用の REM ブロックに書き込まれます。

マシン自体の記憶整理メカニズムに加えて、Dreaming は人間の読書により適した「夢日記」も生成します。素材がある程度溜まるとバックグラウンドサブエージェントがデフォルトモデルを呼び出してDREAMS.mdに簡潔な記述を追加します。

02 採点の仕組み：何を残し、何を忘れるべきかを決める

夢を見るための鍵は「整理する」だけではなく「ふるい分ける」ことです。 OpenClaw は、大規模なフルスケールストレージを使用し続ける代わりに、重み付けされたスコアリングメカニズムを使用して、どの情報を長期記憶に入れる価値があるかを判断します。

このメカニズムは主に次の 6 つの次元に注目します。

関連性の重み (30%): 情報が検索されたときに役立つかどうかを測定します。
頻度重み付け (24%): ある情報が繰り返し言及された回数をカウントします。
クエリの多様性 (15%): さまざまな質問やシナリオにわたってそれが現れるかどうかを確認します。
適時性の重み (15%): より新しい情報に高い優先度を与えます。
統合の重み (10%): 情報が複数の日に渡って安定して表示されるかどうかを確認します。
コンセプトの豊富さ (6%): その背後にある関連コンセプトが十分に充実しているかどうかを判断します。

これは、システムが長期記憶にすべてを詰め込むのではなく、繰り返し表示され、問題を解決し、時代を超えた情報を保持することを優先することを意味します。

03 なぜクロードの「夢」の考えを人々に思い出させるのでしょうか?

一部の開発者は、OpenClaw の Dreaming アップグレードの背後にあるアイデアが、Claude Code の漏洩コードに登場した KAIROS 自動ドリーミングメカニズムと非常によく似ていると信じています。以前は、MEMORY.md 全体の読み取りと書き込みを繰り返す方法では、後の段階でメモリシステムがますます肥大化する可能性がありました。一方、Dreaming はプロセスを浅い睡眠の統合、深い睡眠の固化、REM の関連付けに分割します。ロジックは明らかにより明確で、「最初に組織化し、次に沈殿させ、次に精製する」というアイデアに近くなります。

神経科学の観点からこのデザインを肯定する人もいます。なぜなら、夢、浅い睡眠、深い睡眠、レムの概念は単なるランダムな名前ではなく、記憶を定着させるために明らかに人間の睡眠モデルから借用したものだからです。

OpenClaw の既存の IDENTITY.md、USER.md、HEARTBEAT.md はすでにエージェントの個性、ユーザーコンテキスト、実行継続性を提供していますが、DREAMS.md が追加するのは「どの記憶を保持するか」を指定する機能です。

04 最も皮肉なシーン: 機械は夢を見ることを学ぶが、人間は眠れない

Dreaming の本当の価値は、AI にすべてを記憶させることではなく、短期記憶を見直し、基礎となるパターンを抽出し、ノイズをフィルターする方法を学習させることです。本当に役立つエージェントは、モバイルハードドライブのように丸暗記するのではなく、ユーザーの好み、目標、背景をますます理解する必要があります。

工学的な観点から見ると、このメカニズムの最も注目すべき点は、それが神秘的ではないということです。これはブラックボックスマジックではなく、ステージ、しきい値、反映、および忘却ルールを備えた一連のバックグラウンドプロセスです。この設計により、AI の記憶メカニズムが、単なる「コンテキストの無限のヒープ」ではなく、初めて「制御可能なシステム」のように見えます。

しかし、それが全体を少し皮肉なものにしているのです。私たちは機械に人間のように夢を見る方法を教えるために多大なリソースを投資していますが、同時に多くの人々がこれらのますますスマート化するシステムに取って代わられるのではないかという恐怖で眠れなくなっています。

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 は、唯一の実行プロトコルではなく、接続プロトコルとして適しています。

OpenClaw と Agent Harness: なぜ AGI のように見えるのか

Fri, 10 Apr 2026 09:16:17 +0800

初めて OpenClaw に触れた人の多くは、「チャットボットというよりも、何かができる同僚に近い」と感じるでしょう。

この感覚には何も不思議なことはありません。重要な点は、OpenClaw は単一モデルの機能を飛躍的に向上させたものではなく、完全な エージェントハーネス であるということです。

結論を先に言ってください

OpenClaw の本質は次のように要約できます。

モデルは理解と意思決定を担当します
ハーネスはメモリ、ツール、トリガー、実行、出力を担当します。
両者はサイクルを通じて協力し、「継続的なアクション」の体験を形成します。

したがって、それが「AGI に似ている」主な理由は、モデルが突然全能になることではなく、システムエンジニアリングによってモデルの実行可能性が増幅されることです。

ハーネスとは

ハーネスは「モデルが着用する外骨格」と理解できます。

スタンドアロン LLM は通常、単一のリクエストでのみ回答を提供でき、Harness はこれらの機能を完了します。

セッションと状態の管理: 複数のラウンドのタスクをつなぎ合わせる
メモリメカニズム: オンデマンドでコンテキストを保存および呼び出し
ツールシステム: ブラウザ、端末、ファイル、外部 API の呼び出し
トリガーメカニズム: タイマーまたはイベントによって起動し、毎回誰かが質問するのを待つ必要はありません。
出力チャネル: 単なるテキストではなく、結果をシステムに書き戻します。

これらの機能が同じループに接続されると、モデルは「レスポンダー」から「エグゼキューター」に変わります。

OpenClaw の外観が異なる理由

従来のチャットボットは「1 回質問し、1 回回答」です。

OpenClaw は、「観察 -> ツールの調整 -> 結果の確認 -> 意思決定」という閉ループに似ています。クローズドループが確立されると、タスクを継続的に進める能力を発揮します。

これは、OpenClaw について学ぶべき最も価値のあることでもあります。

エージェントのエクスペリエンスは主にアーキテクチャ設計から得られることが証明されています
「自律性」をエンジニアリングモジュールに分割します

価値観と境界線

OpenClaw の利点は多用途性と柔軟性があることですが、価格も明らかです。

コンテキストとツールの定義が増えるほど、コストが高くなります
システムが一般的であればあるほど、デバッグと管理はより複雑になります

本番環境のシナリオでは、多くのチームが「万能エージェント」ではなく、より小規模で専門性の高いエージェントを選択します。

Anthropic による OpenClaw 禁止の完全なタイムライン

Wed, 08 Apr 2026 19:48:42 +0800

イベントの背景

2026 年 4 月 4 日、Anthropic は、OpenClaw などのサードパーティツールに対するクロードのサブスクリプションの対象を打ち切ると発表しました。

ユーザーレベルへの直接的な影響は、もともとサブスクリプションパスに依存してクロードにアクセスしていたサードパーティプロセスを、他のアクセス方法に変更するか、他のモデルに切り替える必要があることです。

タイムライン（2026年1月から4月）

2026年1月

公開報道によると、Anthropic は、当時 Clawdbot として知られていたこのプロジェクトに対し、発音がクロードに近いことから名前の変更を求めたという。

同じ段階で、サードパーティがサブスクリプション認証情報を介して通話できる機能が限られているというフィードバックがコミュニティから出始めました。

2026年2月

関連する制限はサービス規約に記載されており、サブスクリプションとサードパーティの自動呼び出しとの境界がさらに明確になります。

同月、OpenClaw は v4.0 をリリースし、基礎となるアーキテクチャがプラグイン可能なモデルバックエンドに変更されました。つまり、モデルは単一の固定された入り口ではなくなり、複数のモデルプロバイダーの間で切り替えることができます。

2026年3月

Anthropic は、リモートタスクの実行やデスクトップ操作などの機能をカバーする、Claude Dispatch と Computer Use をリリースします。

OpenClaw は今後のアップデートでも互換性レイヤーを推進し、異なるモデルの認証方法、ツール呼び出し形式、戻り構造の違いを統一し、モデルを切り替える際の移行コストを削減します。

公開レポートでは、OpenClaw チームが 3 月下旬に Anthropic と連絡を取ったとも述べられていましたが、最終的な戦略的方向性は変更されませんでした。

2026 年 4 月 4 日

Anthropic は、サードパーティツールのサブスクリプション適用範囲の打ち切りを正式に実装します。

これは、過去数か月間に行われた戦略的調整の実施段階を示します。

2026 年 4 月 5 日

OpenClaw は v4.5 をリリースします。主なアクションには次のようなものがあります。

ブートストラッププロセス中にモデルエントリの優先順位を調整する
GPT-5.4 などの代替モデルパスにアクセスする
タスクのプロセスとインタラクティブなエクスペリエンスに適応し続ける

リリース時期から判断すると、OpenClaw のスイッチング機能は完全に一時的なビルドではなく、2 月以降のマルチモデルアーキテクチャの変革に基づいています。

プロセスにおける 2 つの平行した方向

タイムラインを見ると、両当事者は同じ期間に異なる方向に前進しました。

Anthropic: サブスクリプションの境界を厳格化し、公式の製品機能の統合を促進します。
OpenClaw: モデルの置換可能性を強化し、モデル間の互換性を向上させます。

この 2 つのルートは矛盾するものではありませんが、「エントリーの所有権」と「ユーザーのワークフローの登録位置」という点で競合関係が生じます。

現状（2026年4月現在）

公開されている情報に基づいて、次の事実が確認できます。

サブスクリプションオーバーライドのカットオフが実行されました
OpenClaw はメジャーモデルパスの切り替えを完了し、バージョンの反復を維持しました
ユーザーが大きな変化を感じるかどうかは、元のワークフローが単一モデルの機能にどの程度依存しているかによって決まります。

経過観察のポイント

次に注目すべきは、その事件そのものではなく、次の 3 つの点です。

サブスクリプションプランと API 呼び出しの間の境界は今後も改善されていくのでしょうか?
安定性、コスト、エクスペリエンスの観点からマルチモデルエージェントの長期的なパフォーマンスを実現
ユーザーのワークフローは最終的にモデル層、ツール層、あるいはその 2 つの間のハイブリッド層に落ち着きますか?