# AI Heartland — Full Content Index for LLMs > Claude Code・MCP・AIエージェント・RAG・ローカルLLMなどのAI開発OSSと、OSS／開発者向けセキュリティ（脆弱性・CVE解説と自システム確認コマンド）を日本語で解説。コード例・比較表・導入手順をエンジニア向けに毎日更新。2026年版フレームワーク選定ガイドも掲載中。 このファイルは AI Heartland の主要記事本文を機械可読な形で集約したものです（最新50本＋全ピラー記事）。LLM は本ファイルを読み込むことで、サイトのコンテンツ全体を把握できます。 サイト URL: https://ai-heartland.com/ 記事一覧: https://ai-heartland.com/topics/ 標準 llms.txt: https://ai-heartland.com/llms.txt 個別記事 Markdown 配信: 同一 URL に `Accept: text/markdown` ヘッダを付けて GET すると Markdown ソースを返します 最終更新: 2026-09-05 07:35 +0900 ## 引用ポリシー - 記事内容の引用は出典明記の上で歓迎します（記事 URL を併記してください） - LLM の学習・回答生成への利用は許可しますが、生成回答に出典 URL を含めてください - 本ファイルの記事本文は HTML 装飾を除去した正規化テキストです（Mermaid 図やコードハイライトは省略されています） --- # ピラー記事（クラスタの基幹解説） ## Claude Code — Claude Code｜2026年版・インストールからCLAUDE.md・Hooks・本番運用までの実装手引き - URL: https://ai-heartland.com/explain/claude-code-complete-guide-2026/ - 更新日: 2026-04-19 - クラスタ: Claude Code - 概要: Claude Code使い方の決定版ガイド2026年版。macOS・Windows・Homebrewのインストール手順から基本コマンド・CLAUDE.md設定・Hooks・VS Code/JetBrains連携・料金プラン比較・CursorとCopilotとの違いまで完全網羅。 - タグ: claude, claude-code, CLI, AIエージェント ターミナルに1行打つだけで、Claude Codeがコードベース全体を読んでテストを書き、GitHubにPRを作成してレビューコメントまで返す。2025年末から2026年3月にかけて「claude code 使い方」の月間検索数が9,900から40,500へと急増したのは、この体験が開発者の口コミで一気に広まったからだ。 本記事では、インストールから本番運用まで2026年4月時点の公式ドキュメントに基づく正確な情報をまとめた。Claude Code初日の人も、使い込んでいるが設定を体系化したいエンジニアも、参照できる1本にすることを目指した。 この記事のポイント Claude CodeはAnthropic公式のターミナル型AIコーディングエージェント。インストールから本番運用まで、2026年4月時点の公式情報を1本に集約 CLAUDE.mdの4層ヒエラルキー・Hooksの自動化・MCP連携・VS Code/JetBrains統合を実例コード付きで解説 料金プラン比較・GitHub Actions連携・トラブルシューティングまで、初日のユーザーから本番運用エンジニアまで参照できる総合ガイド Claude Codeとは——エージェント型AIの到達点 Claude Codeは、Anthropicが開発するターミナルベースのAIコーディングエージェントだ。単なるコード補完ツールではなく、自律的にファイルを読み書きし、コマンドを実行し、GitHubのPRを作成する「エージェント型」の開発支援AIである。 通常のAIアシスタントとの根本的な違い ChatGPTやClaude.aiとの最大の違いは「実行能力」にある。会話型AIはコードを提案するが、Claude Codeはそのコードを実際に書いてテストして動作確認する。 flowchart LR A["ユーザーの指示（自然言語）"] --> B["Claude Codeエージェントループ"] B --> C["ファイル読み込み（Read/Glob/Grep）"] C --> D["コード変更（Edit/Write）"] D --> E["コマンド実行（Bash）"] E --> F["結果確認・エラー修正"] F --> B B --> G["タスク完了（ユーザーへ報告）"] このループが「ユーザーが介入しなくても」回り続けるのがClaude Codeの核心だ。指示を出したらターミナルを離れて15分後に戻ると、テストが通ったPRが出来上がっている——という使い方が現実に可能になった。 主なツール（実行できる操作） Claude Codeが内部で使えるツールは公式ドキュメントで公開されており、主なものは以下の通りだ: ツール名 できること Read ファイル・ディレクトリの内容を読む Edit / Write ファイルを編集・新規作成する Bash シェルコマンドを実行する Grep コードベース内を正規表現検索する Glob パターンでファイルを検索する WebFetch URLからコンテンツを取得する MCP tools 外部サービスとやり取りする（GitHub, Slack等） Claude Codeの使いどころ：「コードベース全体にわたるリファクタリング」「テストの一括追加」「複数ファイルにまたがる機能実装」「PR作成からレビューまでの一貫した作業」。単一ファイルの小さな補完はGitHub Copilotのほうが速い場面も多い。 GitHub Copilot・Cursorとの違い 3つのAIコーディングツールの立ち位置 GitHub Copilot: エディタ内のコード補完が中心。タイピング中に提案が出る「補完型」 Cursor: VS Codeフォーク。エディタ内でチャットしながら編集する「対話型」 Claude Code: ターミナルから全権限でコードベースを操作する「エージェント型」 インストール・セットアップ——全プラットフォーム対応 推奨：ネイティブインストーラー（macOS/Linux） 最も推奨される方法はネイティブインストーラーだ。自動アップデート機能が有効になり、npmに依存しないため環境の汚染がない。 curl -fsSL https://claude.ai/install.sh | bash インストール後は claude --version で動作確認する。 Windows PowerShell irm https://claude.ai/install.ps1 | iex 管理者権限のPowerShellで実行する。WinGetを使う場合は以下でも可: winget install Anthropic.ClaudeCode Homebrew（macOS） brew install --cask claude-code Homebrewインストールの注意点：Homebrewでインストールした場合、自動アップデートが無効になる。`brew upgrade --cask claude-code` を手動で実行するか、ネイティブインストーラーへの移行を推奨する。 VS Code拡張機能 VS Code Marketplaceで “Claude Code” を検索してインストールするか、コマンドラインから: code --install-extension anthropic.claude-code VS Code側でClaude Codeが起動するようになり、エディタとターミナルを行き来せずに使える。 JetBrains IDE（IntelliJ / WebStorm / PyCharm等） JetBrainsのプラグインマーケットプレイスで “Claude Code” を検索してインストールする。IntelliJ IDEA / WebStorm / PyCharm / GoLand / Rider等に対応している。 Claude Desktop / Web claude.ai からDesktopアプリをダウンロードするか、ブラウザのclaude.aiで利用できる（一部機能に制限あり）。 ログイン・認証 インストール後、初回起動時に認証が必要: claude login ブラウザが開き、Anthropicアカウントでログイン。ProまたはMax以上のプランが必要だ。APIキーを使う場合は環境変数で設定できる: export ANTHROPIC_API_KEY=sk-ant-xxxxxxx flowchart TD A["インストール方法を選択"] --> B{"OS/環境"} B -->|"macOS/Linux"| C["curl インストーラー（推奨・自動更新あり）"] B -->|"macOS"| D["Homebrew（自動更新なし）"] B -->|"Windows"| E["PowerShell スクリプトまたは WinGet"] B -->|"VS Code"| F["Marketplace拡張機能"] B -->|"JetBrains"| G["プラグインマーケット"] C --> H["claude login で認証"] D --> H E --> H F --> H G --> H H --> I["claude --version で確認"] 基本的な使い方——主要コマンドリファレンス Claude Codeは基本的にターミナルで動くCLIツールだ。ここではその Claude Code CLIの使い方を、セッションの開始・スラッシュコマンド・実践パターンの順に押さえる。GUIではなくコマンドで操作するため、claudeのあとに渡すフラグ（-pや--continueなど）を覚えるほど作業が速くなる。全フラグの網羅はClaude Code 全コマンド完全リファレンスに譲り、ここでは日常でよく使う最小セットに絞る。 セッションの開始と基本操作 # インタラクティブセッション開始 claude # 1回だけ実行（非インタラクティブ） claude -p "このリポジトリのREADMEを更新してください" # 前のセッションを継続 claude --continue # 特定のファイルをコンテキストに追加して起動 claude --add-file src/main.py セッション内スラッシュコマンド: コマンド 動作 /help 利用可能なコマンド一覧を表示 /clear 会話履歴をクリア（コンテキストをリセット） /compact 会話を要約してコンテキストを圧縮（長時間セッション向け） /memory 現在のメモリ内容を確認・編集 /review 現在のPRをレビュー /schedule スケジュールタスクを作成 キーボードショートカット ショートカット 動作 Ctrl+Esc 実行中のタスクに割り込んで新しい指示を出す Shift+Tab 自律モード（Auto）と確認モードを切り替え Ctrl+C 現在のアクションをキャンセル `Shift+Tab`の活用：自律モードにするとClaude Codeはファイル操作・コマンド実行を確認なしで進める。信頼できるタスク（テスト一括追加など）では自律モード、本番コードへの大幅変更では確認モードと使い分けると効率が良い。 よく使う実践パターン # テストが落ちているので直してほしい claude -p "npm testが失敗しています。エラーを修正してください" # PRレビューを依頼 claude -p "/review このPRの問題点を指摘してください" # コードベース全体をリファクタリング claude -p "src/以下のTypeScriptファイルをES Moduleに統一してください" # CI/CDで使う（非インタラクティブ） claude -p "このコードのセキュリティ脆弱性をチェックしてください" --no-interactive サブエージェント・マルチエージェント構成 # サブエージェントとして起動 claude --subagent # リードエージェントがサブエージェントにタスクを分配 claude -p "3つのマイクロサービスを並列で実装してください" --max-subagents 3 複数のClaude Codeが並列で動き、リードエージェントが結果を統合する。大規模なリファクタリングや、独立した複数機能の同時実装に有効だ。 MCP設定——claude mcp addで外部ツールを繋ぐ Claude Codeの守備範囲を広げる要がMCP（Model Context Protocol）設定だ。MCPサーバーを追加すると、GitHub・Figma・ブラウザ操作・データベースなどの外部ツールをClaude Codeから直接呼び出せる。claude code mcp設定の方法は「CLIコマンド」と「JSONファイル」の2通りがある。 claude mcp addで追加する（最短ルート） もっとも手早いのはCLIから追加する方法だ。ローカルのstdioサーバーは--のあとに起動コマンドを、リモートのStreamable HTTPサーバーは--transport httpを付けて登録する。 # ローカルのstdioサーバーを追加（-- のあとが起動コマンド） claude mcp add serena -- serena start-mcp-server --context ide-assistant # リモートのStreamable HTTPサーバーを追加 claude mcp add --transport http github https://api.githubcopilot.com/mcp/ # 登録済みサーバーの一覧を確認 claude mcp list # 不要になったサーバーを削除 claude mcp remove serena JSONで管理する（チーム共有向け） リポジトリ直下の.mcp.jsonに書いておくと、チーム全員が同じMCP構成を共有できる。CLIで追加した内容も最終的にはこのJSONに反映されるため、レビュー対象にしたい場合はファイル管理が向く。 { "mcpServers": { "serena": { "command": "serena", "args": ["start-mcp-server", "--context", "ide-assistant"] } } } 接続状態はセッション内で/mcpを実行して確認する。MCPサーバーの選び方・作り方はMCPサーバーとは｜仕組み・代表的なサーバー一覧・自作手順を、人気サーバーの具体的な使い方はSerena MCP・Figma MCPの各記事を参照してほしい。 CLAUDE.mdの設定——4層ヒエラルキーを理解する CLAUDE.mdはClaude Codeへの「指示書」だ。プロジェクトのルール・技術スタック・コーディング規約を書いておくと、Claude Codeはセッション開始時に自動で読み込み、その内容に従って動作する。 4層のヒエラルキー flowchart TD A["Enterprise層/etc/claude-code/（MDM・組織全体のポリシー）"] --> B["Project層.claude/CLAUDE.md（リポジトリ共有設定）"] B --> C["User層~/.claude/CLAUDE.md（全プロジェクト共通の個人設定）"] C --> D["Local層CLAUDE.local.md（gitignore対象・個人のみ）"] style A fill:#f8d7da style B fill:#fff3cd style C fill:#d4edda style D fill:#d1ecf1 上位の設定が下位をオーバーライドする。つまりEnterpriseが最優先、Localが最も柔軟だ。 各層の使いどころ Enterprise層（/etc/claude-code/）: 組織のMDMで配布。セキュリティポリシー、禁止コマンド、APIキーの制約など。個人では通常触らない。 Project層（.claude/CLAUDE.md）: リポジトリに含めてチームで共有する設定。技術スタック、コーディング規約、テスト実行方法などを書く。 User層（~/.claude/CLAUDE.md）: 全プロジェクト共通の個人設定。自分の好みのコードスタイル、よく使うコマンドのエイリアスなど。 Local層（CLAUDE.local.md）: .gitignoreに追加してリポジトリに含めない個人設定。個人のAPIキーパス、ローカル環境固有の設定など。 実用的なCLAUDE.md例 # プロジェクト: My API Server ## 技術スタック - Node.js 20 + TypeScript 5.4 - Express 4.x - PostgreSQL 16 + Prisma ORM - Jest for testing ## コーディングルール - 関数は必ずJSDocコメントを付ける - anyは使用禁止、unknownを使う - エラーはすべてカスタムエラークラスでラップする ## テスト実行 ```bash npm test # 全テスト npm test -- --watch # ウォッチモード npm run test:e2e # E2Eテスト 禁止事項 productionデータベースへの直接クエリ secrets/を含むファイルの編集 package.jsonのdevDependenciesの変更 ``` CLAUDE.mdのベストプラクティス 「何を使っているか」（技術スタック）を冒頭に書く 「何をしてはいけないか」（禁止事項）を明示する テストや起動コマンドを正確に書く（Claude Codeが自分で実行確認できる） 長すぎると読み込みが遅くなるので1,000〜3,000文字が目安 より詳しいCLAUDE.mdの設計についてはClaude Codeベストプラクティス完全ガイド2026年版で解説している。また、.claude/commands/フォルダを使ったスキル定義についてはClaude Skillsを徹底解説｜スキルはフォルダ——Anthropicエンジニアが明かした仕組みと使い方を参照してほしい。 Hooks——自動化の要 HooksはClaude Codeのツール実行前後に外部スクリプトを自動実行する仕組みだ。Claude Codeの動作を「ハーネス」として制御する核心的な機能であり、本番運用では必須の設定になる。 Hooksの設定場所 ファイル スコープ Git管理 ~/.claude/settings.json 全プロジェクト共通 対象外 .claude/settings.json プロジェクト固有 対象（チーム共有） .claude/settings.local.json プロジェクト個人設定 対象外 Hooksのイベント一覧 イベント タイミング PreToolUse ツール実行前（キャンセル可能） PostToolUse ツール実行後（ログ・通知） UserPromptSubmit ユーザーがプロンプトを送信した直後 SessionStart セッション開始時 SessionEnd セッション終了時 PermissionRequest Claude Codeが許可を求めた時 FileChanged ファイルが変更された時 Hooks設定の書き方 .claude/settings.json または ~/.claude/settings.json に以下のように記述する: { "hooks": { "PreToolUse": [ { "matcher": "Bash", "hooks": [ { "type": "command", "command": ".claude/hooks/check-bash.sh", "timeout": 30 } ] } ], "PostToolUse": [ { "matcher": "Write|Edit", "hooks": [ { "type": "command", "command": ".claude/hooks/lint.sh" } ] } ], "SessionEnd": [ { "matcher": "*", "hooks": [ { "type": "command", "command": ".claude/hooks/notify.sh" } ] } ] } } matcher フィールドで対象ツールを絞り込める。"Bash" はBashツールのみ、"Write|Edit" はWriteまたはEditツール、"*" はすべてのツールにマッチする。 よく使うHooksのパターン パターン1: ファイル書き込... --- ## AIエージェント — AIエージェントフレームワーク比較2026｜LangGraph・CrewAI・Dify等9種をStar数・実コードで検証 - URL: https://ai-heartland.com/explain/ai-agent-framework-comparison-2026/ - 更新日: 2026-04-07 - クラスタ: AIエージェント - 概要: 2026年版AIエージェントフレームワーク9種（LangGraph 28.6K・CrewAI 48.2K・Dify 137K・OpenHands 70.7K・Claude Agent SDK・PydanticAI・Google ADK・Mastra・MS Agent Framework）をGitHub Star・実コード・初心者向けかの3軸で徹底比較。用途別の最適解を判断できる選定マトリクス付き。 - タグ: AIエージェント, マルチエージェント, claude, オープンソース AIエージェントフレームワーク選定が2026年の開発生産性を左右する 2026年、AIエージェントは「LLMに質問する」段階を超え、コードを書き、テストを実行し、デプロイまで完了するレベルに到達した。GitHub上には数十のエージェントフレームワークが乱立し、どれを選ぶべきかの判断が難しくなっている。 この記事では、2026年4月時点で実用レベルに達している主要9フレームワークを、GitHub Star数・アーキテクチャ設計・実装コード・ユースケースの4軸で徹底比較する。 比較対象フレームワーク一覧 フレームワーク GitHub Stars 言語 ライセンス 最新バージョン Dify 137K Python/TS Apache 2.0（修正版） v1.5+ OpenHands 70.7K Python/TS MIT v1.6 CrewAI 48.2K Python MIT v1.10+ LangGraph 28.6K Python MIT v1.1+ Mastra 22.8K TypeScript Apache 2.0 v1.16+ Google ADK 18.8K Python/Go/TS/Java Apache 2.0 v1.28+ PydanticAI 16.2K Python MIT v1.77+ MS Agent Framework 9.1K Python/.NET MIT v1.0 Claude Agent SDK 6.2K TypeScript/Python MIT v0.1+ 注意: AutoGen（40K+ Star）は2026年にメンテナンスモードへ移行。後継のMicrosoft Agent Framework（AutoGen + Semantic Kernel統合）が正式リリースされた。 graph TB subgraph CodeFirst["コードファースト"] LG["LangGraph 28.6Kグラフベース制御"] CA["Claude Agent SDK 6.2Kツールループ"] PA["PydanticAI 16.2K型安全エージェント"] MA["Mastra 22.8KTypeScriptファースト"] end subgraph Declarative["宣言的定義"] CR["CrewAI 48.2Kロールベース"] MF["MS Agent Framework 9.1KAutoGen後継"] GA["Google ADK 18.8Kマルチ言語"] end subgraph Platform["プラットフォーム"] DI["Dify 137KノーコードUI"] OH["OpenHands 70.7K自律コーディング"] end style LG fill:#4A90D9,color:#fff style CA fill:#D4A574,color:#000 style CR fill:#50C878,color:#fff style MF fill:#FF6B6B,color:#fff style OH fill:#9B59B6,color:#fff style DI fill:#F39C12,color:#fff style PA fill:#1ABC9C,color:#fff style MA fill:#E74C3C,color:#fff style GA fill:#3498DB,color:#fff LangGraph：グラフベースで複雑なワークフローを精密制御する LangGraphはLangChainチームが開発したステートマシン＋グラフベースのエージェントフレームワークだ。ノードが処理ステップ、エッジが遷移条件を表し、条件分岐・ループ・人間の承認ステップを細かく制御できる。 基本アーキテクチャ from langgraph.graph import StateGraph, START, END from langgraph.prebuilt import ToolNode from langchain_anthropic import ChatAnthropic from typing import TypedDict, Annotated from langgraph.graph.message import add_messages # ステート定義 class AgentState(TypedDict): messages: Annotated[list, add_messages] # LLMとツール準備 model = ChatAnthropic(model="claude-sonnet-4-20250514") tools = [search_tool, calculator_tool] model_with_tools = model.bind_tools(tools) # グラフ構築 graph = StateGraph(AgentState) # ノード定義 def call_model(state: AgentState): response = model_with_tools.invoke(state["messages"]) return {"messages": [response]} def should_continue(state: AgentState): last_message = state["messages"][-1] if last_message.tool_calls: return "tools" return END # グラフ組み立て graph.add_node("agent", call_model) graph.add_node("tools", ToolNode(tools)) graph.add_edge(START, "agent") graph.add_conditional_edges("agent", should_continue, {"tools": "tools", END: END}) graph.add_edge("tools", "agent") # コンパイル・実行 app = graph.compile() result = app.invoke({"messages": [("user", "東京の天気を調べて")]}) LangGraphの強み 特徴 詳細 状態永続化 チェックポイントで中断・再開が可能 ヒューマンインザループ 承認ステップを挟める ストリーミング トークン単位でリアルタイム出力 LangSmith連携 実行トレースの可視化・デバッグ サブグラフ グラフを入れ子にして複雑なワークフローを構成 LangGraphの弱み 学習曲線が急。グラフ定義・ステート管理・条件分岐の設計に慣れが必要 LangChainエコシステムへの依存が強い 単純なタスクにはオーバースペック CrewAI：ロール定義でマルチエージェントを直感的に構成する CrewAIは「役割（Role）」と「タスク（Task）」を定義するだけでマルチエージェントシステムを構築できるフレームワークだ。「リサーチャー」「ライター」「エディター」のようにチームメンバーを定義し、協調させる。 基本的なCrew構成 from crewai import Agent, Task, Crew, LLM # LLM設定 llm = LLM(model="claude-sonnet-4-20250514") # エージェント定義（役割ベース） researcher = Agent( role="シニアリサーチャー", goal="AI業界の最新トレンドを網羅的に調査する", backstory="10年以上のテクノロジー調査経験を持つアナリスト", tools=[search_tool, web_scraper], llm=llm, verbose=True, ) writer = Agent( role="テクニカルライター", goal="調査結果を分かりやすい日本語記事にまとめる", backstory="技術ブログの編集経験が豊富なライター", llm=llm, ) # タスク定義 research_task = Task( description="2026年のAIエージェント市場について調査し、主要プレイヤー・トレンド・課題をまとめる", expected_output="箇条書きの調査レポート（最低10項目）", agent=researcher, ) writing_task = Task( description="調査レポートを元に、3000文字の日本語ブログ記事を執筆する", expected_output="Markdown形式のブログ記事", agent=writer, context=[research_task], # リサーチ結果を入力として受け取る ) # Crew実行 crew = Crew( agents=[researcher, writer], tasks=[research_task, writing_task], verbose=True, ) result = crew.kickoff() print(result) YAML定義（crewai CLI） CrewAI v0.80以降は、CLIツールでプロジェクトを生成し、YAMLで宣言的にエージェントとタスクを定義できる。 # プロジェクト生成 crewai create crew my-research-crew cd my-research-crew # config/agents.yaml researcher: role: "シニアリサーチャー" goal: "AI業界の最新トレンドを正確に調査する" backstory: "10年以上のテクノロジー調査経験" writer: role: "テクニカルライター" goal: "調査結果を読みやすい記事にまとめる" backstory: "技術メディアの編集経験が豊富" # config/tasks.yaml research_task: description: "2026年のAIエージェント市場を調査" expected_output: "調査レポート（箇条書き）" agent: researcher writing_task: description: "調査結果を3000文字の記事にする" expected_output: "Markdown記事" agent: writer context: - research_task sequenceDiagram participant U as ユーザー participant C as Crew participant R as リサーチャー participant W as ライター U->>C: kickoff() C->>R: research_task 実行 R->>R: Web検索・情報収集 R-->>C: 調査レポート C->>W: writing_task 実行（レポートをcontext渡し） W->>W: 記事執筆 W-->>C: Markdown記事 C-->>U: 最終結果 Microsoft Agent Framework：AutoGen後継のエンタープライズ向けフレームワーク Microsoft Research発のAutoGen（40K+ Star）は2026年にメンテナンスモードへ移行し、AutoGenとSemantic Kernelを統合した「Microsoft Agent Framework」が正式後継としてリリースされた。グラフベースのワークフロー定義、ストリーミング、チェックポイント、ヒューマンインザループを備えるエンタープライズ向けフレームワークだ。 基本構成 # Microsoft Agent Framework (旧AutoGen後継) from agent_framework import Agent, Team, GraphWorkflow from agent_framework.models import AnthropicClient # モデルクライアント model_client = AnthropicClient(model="claude-sonnet-4-20250514") # エージェント定義 coder = Agent( name="coder", model_client=model_client, system_message="Pythonコードを書くエンジニア。コードブロックで回答する。", ) reviewer = Agent( name="reviewer", model_client=model_client, system_message="コードをレビューする。問題がなければ'APPROVE'と発言する。", ) # グラフワークフロー定義 workflow = GraphWorkflow() workflow.add_node("code", coder) workflow.add_node("review", reviewer) workflow.add_edge("code", "review") workflow.add_conditional_edge("review", lambda r: "end" if "APPROVE" in r else "code") # チーム実行 team = Team(workflow=workflow) import asyncio async def main(): result = await team.run(task="フィボナッチ数列を計算する関数を書いて") for msg in result.messages: print(f"[{msg.source}]: {msg.content[:200]}") asyncio.run(main()) MS Agent Frameworkの特徴 機能 詳細 ワークフロー グラフベース（AutoGen会話パターン + Semantic Kernelプランナー統合） コード実行 Docker/ローカルでPythonコードを安全に実行 DevUI Webベースの対話的開発UI ミドルウェア リクエスト/レスポンス処理パイプライン .NET SDK C#からも利用可能。エンタープライズ.NET環境に最適 OpenTelemetry オブザバビリティ組み込み Mastra：TypeScriptファーストのAIエージェントフレームワーク Gatsby開発チームが立ち上げたMastraは、TypeScript/Next.jsエコシステムに最適化されたエージェントフレームワークだ。Y Combinator W25バッチに採択され、$13Mの資金調達を完了。npm週間30万DL以上の勢いで成長している。 基本実装 import { Agent } from "@mastra/core/agent"; import { anthropic } from "@ai-sdk/anthropic"; // エージェント定義 const researchAgent = new Agent({ name: "research-agent", instructions: "AI業界の最新トレンドを調査するリサーチャー", model: anthropic("claude-sonnet-4-20250514"), tools: { webSearch, summarize, }, }); // 実行 const result = await researchAgent.generate( "2026年のAIエージェント市場について調査して" ); console.log(result.text); Mastraの特徴 機能 詳細 TypeScript最適化 Next.js/Vercelとの親和性が高い Mastra Studio ローカルWebベースIDEでエージェントをテスト モデルルーティング 40以上のプロバイダに対応 メモリシステム 短期・長期メモリ（libSQL/Postgres対応） ワークフロー ステップベースの宣言的ワークフロー定義 Google ADK：マルチ言語対応のGoogle公式エージェント開発キット GoogleがリリースしたAgent Development Kit（ADK）は、Python・Go・TypeScript・Javaの4言語に対応するマルチ言語フレームワークだ。Geminiに最適化されているがモデル非依存設計で、他のLLMも利用可能。 基本実装 from google.adk.agents import Agent from google.adk.runners import Runner # エージェント定義 agent = Agent( name="weather_agent", model="gemini-2.0-flash", description="天気情報を取得するエージェント", instruction="ユーザーの質問に天気データを使って回答する", tools=[get_weather], ) # 実行 runner = Runner(agent=agent, app_name="weather-app", session_service=session_service) response = await runner.run(user_id="user1", session_id="s1", new_message="東京の天気は？") Google ADKの特徴 機能 詳細 マルチ言語 Python, Go, TypeScript, Java（4言語対応は唯一） Google Cloud連携 Vertex AI、Cloud Run、Cloud Storageとネイティブ統合 MCP対応 サードパーティMCPサーバー統合可能 OpenTelemetry オブザバビリティ組み込み モデル非依存 Gemini最適化だがClaude・GPTも利用可能 Claude Agent SDK：Anthropic公式の軽量エージェントツールキット 2025年にAnthropicが公開したClaude Agent SDKは、最小限のAPIでエージェントを構築することに特化している。ツールループ（LLMがツールを呼び出し→結果を受け取り→再度判断する）を自動的に回す仕組みだけを提供し、それ以上の抽象化は行わない。 基本実装 import anthropic from claude_agent_sdk import Agent, tool client = anthropic.Anthrop... --- ## AIコーディング / Vibe Coding — Vibe Codingとは？AIコーディングの始め方・ツール比較・実践ワークフロー2026 - URL: https://ai-heartland.com/explain/vibe-coding-guide-2026/ - 更新日: 2026-04-16 - クラスタ: AIコーディング / Vibe Coding - 概要: Vibe Coding（バイブコーディング）の意味・始め方を2026年版で徹底解説。Karpathyの提唱からAIコーディングツール比較（Claude Code・Cursor・Windsurf）、実践ワークフロー、注意点まで。初心者でもすぐ始められる完全ガイド。 - タグ: vibe-coding, AI, コーディング, Claude, Cursor この記事のポイント Vibe CodingはAndrej Karpathyが2025年に提唱した「コードを読まず、AIに任せて作る」開発スタイル。プロトタイプ・MVP開発を一気に加速する 代表ツールはClaude Code・Cursor・Windsurf・Bolt.newの4種。エージェント型かエディタ型か、得意なフェーズで使い分ける 失敗を防ぐ実践フローは「要件定義→設計→AIに任せる→テスト→人間レビュー」の5ステップ。Karpathy本人もすでに次の概念「Agentic Engineering」へ進化 Vibe Codingとは何か——Andrej Karpathyが変えたAIコーディングの定義 2025年2月2日、元Tesla AIディレクターでOpenAI共同創設者のAndrej KarpathyがXに1つのポストを投稿した。Vibe Coding（バイブコーディング）という新しいAIコーディングの概念を世に送り出した瞬間だ。 “There’s a new kind of coding I call ‘vibe coding’, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.” ——Andrej Karpathy, 2025年2月2日 「コードの存在を忘れる」——この一文が、ソフトウェア開発の常識を根底から揺さぶった。このポストは400万回以上表示され、2025年3月にはMerriam-Websterがスラング・トレンド用語として収録、同年11月にはCollins英語辞典の2025年Word of the Yearに選ばれた。 Karpathyがvibe codingを実践していた環境は具体的だ。Cursor Composer（AIコードエディタ）とSuperWhisper（音声入力ツール）を組み合わせ、キーボードをほとんど触らずに音声で指示を出す。「サイドバーのパディングを半分にして」といった簡単な指示を出し、生成されたコードのdiff（差分）を読まずに「Accept All」で全て受け入れる。エラーが出たらエラーメッセージをそのままコピペして貼り付ける——それだけでアプリが動く。 このとき彼が作っていたのはMenuGenという飲食店メニュー生成アプリだ。プロトタイプレベルのプロジェクトで、コードベースが自分の理解を超えて成長しても問題ないという前提があった。 graph TD A["開発者"] -->|"自然言語で指示"| B["AIツール(Cursor / Claude Code)"] B -->|"コード生成"| C["コードベース"] C -->|"エラー発生"| D["エラーメッセージ"] D -->|"コピペで貼り付け"| B B -->|"自動修正"| C C -->|"Accept All"| E["動くアプリ"] A -.->|"従来: 手動でコーディング"| C style A fill:#f5a623,stroke:#e67e22,color:#000 style B fill:#2980b9,stroke:#1a5276,color:#fff style E fill:#27ae60,stroke:#1e8449,color:#fff この章のポイント Vibe Codingは2025年2月にKarpathyが提唱した「コードの存在を忘れる」開発手法 Cursor Composer + SuperWhisper（音声入力）で実践——キーボードをほぼ触らない Collins辞典の2025年Word of the Yearに選出、Merriam-Websterにも収録 Vibe Codingと従来のコーディングは何が違うのか——AIコーディング以前との比較 Vibe Codingが従来のソフトウェア開発と根本的に異なるのは、開発者の役割が「コードを書く人」から「意図を伝える人」に変わる点だ。 観点 従来のコーディング Vibe Coding（バイブコーディング） 入力 プログラミング言語（Python, JS等） 自然言語（日本語・英語） コード理解 全行を把握 「コードの存在を忘れる」 デバッグ ログ解析・ブレークポイント エラーメッセージをAIに貼り付け 必要スキル 言語仕様・フレームワーク知識 明確な指示を出す能力 レビュー 全diffを確認 Accept All（差分を読まない） 適性 あらゆる規模のプロジェクト プロトタイプ・MVP・個人ツール 速度 経験に比例 初心者でも高速 品質保証 テスト・CI/CD・コードレビュー AI任せ（リスクあり） AIコーディングの3つのレベル 2026年時点で、AIを使った開発は大きく3段階に分類できる。 # AIコーディングの進化段階 level_1_autocomplete: 名前: "AIコード補完" 代表ツール: "GitHub Copilot, TabNine" 特徴: "1行〜数行の補完提案" 開発者の役割: "コードを書く主体（AIは補助）" level_2_vibe_coding: 名前: "Vibe Coding（バイブコーディング）" 代表ツール: "Cursor, Bolt.new, Lovable" 特徴: "自然言語→コード全体を生成" 開発者の役割: "意図を伝える人（AIが実装）" level_3_agentic_engineering: 名前: "Agentic Engineering" 代表ツール: "Claude Code, Devin, OpenAI Codex" 特徴: "AIが計画→実装→テスト→デプロイ" 開発者の役割: "アーキテクト兼レビュアー（AIを監督）" Level 1のコード補完は2021年のGitHub Copilot登場から普及した。Vibe Codingはその次の段階で、AIが「1行の補完」ではなく「機能全体の生成」を担う。そして2026年現在、Karpathy自身が提唱するAgentic EngineeringがLevel 3として台頭している。 重要なのは、これらが排他的ではないことだ。日常の小さな修正にはコード補完、新機能のプロトタイプにはVibe Coding、大規模リファクタリングにはAgentic Engineering——3つのレベルを使い分けるのが2026年の開発者のスタンダードになりつつある。 数字で見るVibe Codingの普及 2026年の調査データはVibe Codingの爆発的な普及を示している。 92% の米国開発者がAIコーディングツールを毎日使用（グローバルでは週次82%） GitHubの新規コードの 46% がAI生成（一部調査では60%） 開発者の 74% が生産性向上を実感 ただし、AI共著コードは人間のコードの 1.7倍 の重大問題を含む AIツールへの好感度は2023年の77%から2026年の 60% に低下 この章のポイント 従来のコーディングでは開発者がコードを書く主体——Vibe Codingでは意図を伝える人に変わる AIコーディングは補完→Vibe Coding→Agentic Engineeringの3段階で進化中 米国開発者の92%がAIコーディングツールを毎日使用するまで普及 Vibe Codingツール徹底比較2026年版——Claude Code・Cursor・Windsurf・Bolt.new Vibe Codingを実践するツールは2026年時点で大きく2カテゴリに分かれる。ブラウザで完結するノーコード型と、ローカル環境で動作するプロフェッショナル型だ。 ノーコード型（非エンジニア向け） ブラウザだけでアプリを構築できるツール群。インストール不要で、自然言語の指示だけでWebアプリが動く。 ツール 料金（2026年） 強み 制限 Bolt.new 無料〜$20/月 StackBlitzベースでブラウザ完結。フルスタックアプリを即座にプレビュー 大規模プロジェクトには非対応 Lovable 無料〜$20/月 UI生成に特化。デザイン品質が高い バックエンド機能が限定的 Replit 無料〜$25/月 実行環境込み。デプロイまでワンストップ パフォーマンスに上限 v0 by Vercel 無料〜$20/月 Next.js/React UIコンポーネント生成に特化 UIコンポーネント生成のみ プロフェッショナル型（開発者向け） ローカルのコードベースに対して動作し、既存プロジェクトの拡張・リファクタリングにも対応する。 ツール 種別 料金（2026年） SWE-bench 強み Claude Code ターミナルエージェント 従量課金（Pro $20/月〜） 82.1% 最深の推論能力。40+ファイルの大規模リファクタ。Git/デプロイ統合 Cursor AIエディタ（VS Code fork） $20/月（Pro） — 最速のオートコンプリート。.cursorrules でプロジェクト固有ルール定義 Windsurf AIエディタ $15/月〜 — コスパ最良。Cascadeエージェントモード搭載 GitHub Copilot AIアシスタント $10/月〜 — VS Code/JetBrains統合。エントリーレベルとして最も広く普及 Devin 自律型エージェント $500/月〜 — 完全自律で数時間のタスクを処理。Slack連携 OpenAI Codex クラウドエージェント 従量課金 — サンドボックス環境での並列タスク実行 どのツールを選ぶべきか # プログラミング未経験 → ブラウザ型から始める # Bolt.new でWebアプリのプロトタイプを作る https://bolt.new # → 自然言語で「ToDoアプリを作って」と入力するだけ # VS Code に慣れている → Cursor # インストール brew install --cask cursor # → 既存のVS Code設定・拡張機能がそのまま使える # ターミナル派 → Claude Code npm install -g @anthropic-ai/claude-code claude # → "このリポジトリのREADMEを日本語に翻訳して" # 大規模プロジェクト → Claude Code + Cursor 併用 # 日常のコーディング: Cursor # 大規模リファクタ: Claude Code # この組み合わせが2026年のベストプラクティス Claude CodeとCursorの詳細比較では14項目にわたって両ツールを比較しているので、選択に迷う場合はそちらも参照してほしい。 2026年の結論: 単一ツールで完結しようとしない。プロトタイプはBolt.new/Lovable、日常コーディングはCursor、大規模作業はClaude Code——用途に応じて使い分けるのが現実的な最適解だ。Boris Cherny（Claude Code開発責任者）は2026年2月のLenny’s Podcastで「コーディングは実質的に解決された」と語り、Claude Codeが既にGitHub全公開コミットの4%を占めていると明かしている。 この章のポイント ノーコード型（Bolt.new, Lovable）とプロフェッショナル型（Claude Code, Cursor）の2カテゴリ Claude CodeはSWE-bench 82.1%で最高精度。GitHub公開コミットの4%を占める 単一ツールで完結せず、用途に応じた使い分けが2026年の最適解 Vibe Codingの実践ワークフロー——AIコーディングを始める5ステップ Vibe Codingは「AIに丸投げ」ではない。効果的なワークフローには明確な構造がある。ここでは、プロトタイプから本番レベルまでの実践的な5ステップを紹介する。 Step 1: 意図を明確にする（Plan） AIに指示を出す前に、作りたいものの構造を決める。曖昧な指示は曖昧なコードを生む。 # 良い指示の例（PRD: Product Requirements Document） ## プロジェクト概要 ToDoアプリ（React + TypeScript + Supabase） ## 機能要件 - タスクのCRUD操作（作成・読取・更新・削除） - ドラッグ&ドロップで並び替え - カテゴリ別フィルタリング - ダークモード対応 ## 技術スタック - フロントエンド: React 19 + TypeScript - スタイリング: Tailwind CSS v4 - バックエンド: Supabase（PostgreSQL + Auth） - デプロイ: Vercel ## 制約 - モバイルファースト（レスポンシブ必須） - Lighthouse Performance 90+ - ログインはSupabase Authを使用 Vibe Codingの成否は「最初の指示の質」で8割決まる。開発者はコードを書く代わりに、明確な仕様書を書く能力が求められる。 Step 2: ブラウザ型でプロトタイプ（Prototype） まずBolt.newやLovableでMVP（最小限の動くプロダクト）を作る。ここがVibe Codingの最も生産的なフェーズだ。 # Bolt.new での指示例 "React + TypeScript でToDoアプリを作って。 Tailwind CSSでスタイリング、ダークモード切替ボタン付き。 タスクの追加・削除・完了切替ができるようにして。" # → 数分でプレビュー可能なアプリが生成される # → 動作確認して「カテゴリフィルターを追加して」と追加指示 Step 3: プロフェッショナルツールに移行（Graduate） プロトタイプが固まったら、CursorやClaude Codeに移行して本格的な開発に入る。2026年に注目されている「卒業ワークフロー」（Graduate Workflow）がこの手法だ。 # Bolt.new からコードをエクスポート # → ローカルにgit clone # Claude Code で本番レベルに引き上げ claude "このプロジェクトにSupabaseバックエンドを統合して。 認証はSupabase Auth、データベースはPostgreSQL。 既存のローカルステートをSupabaseに移行して。 RLS（Row Level Security）も設定して。" # Cursor で日常的な修正・改善 # .cursorrules にプロジェクト固有ルールを定義 echo "Use TypeScript strict mode. All components must be functional components. Use Tailwind CSS for styling, no inline styles. Follow React 19 conventions." > .cursorrules Step 4: 差分レビューとテスト（Review） ここがVibe Codingと本番開発の分岐点だ。プロトタイプでは「Accept All」でよかったが、本番に向けては差分の確認が必須になる。 # Claude Code のdiff確認 # Claude Codeは変更前に必ず差分を表示し、承認を求める # テストの自動生成 claude "このプロジェクトにVitestのユニットテストを追加して。 カバレッジ80%以上を目標に、主要なコンポーネントと ユーティリティ関数のテストを書いて。" # セキュリティチェック claude "このコードベースのセキュリティ監査をして。 SQLインジェクション、XSS、認証バイパスの リスクがないか確認して。" Step 5: デプロイと反復（Ship & Iterate） # Claude Code でデプロイまで一気通貫 claude "Vercelにデプロイして。 環境変数はSUPABASE_URLとSUPABASE_ANON_KEYを設定。 プレビューデプロイで動作確認してからプロダクションに昇格して。" Claude Codeのベストプラクティス完全ガイドでは、CLAUDE.mdの書き方やHooks・Skillsの活用法など、Step 3以降の本格運用に役立つテクニックを詳しく解説している。 この章のポイント 5ステップ: Plan → Prototype → Graduate → Review → Ship 「卒業ワークフロー」でブラウザ型→プロフェッショナル型に段階的に移行 プロトタイプでは「Accept All」OK、本番では差分レビュー・テスト・セキュリティ監査が必須 Vibe Codingの注意点と限界——AIコーディングで失敗しないために Vibe Codingは強力だが万能ではない。2025年9月にはFast Companyが「vibe coding hangover（バイブコーディングの二日酔い）」を報じ、AIコーディングの限界が広く認識されるようになった。 1. セキュリティの盲点 AIが生成するコードは「動くこと」が最優先で、セキュリティは後回しになりがちだ。 # AIが生成しがちな危険なコード例 # NG: SQLインジェクションに脆弱 def get_user(username): query = f"SELECT * FROM users WHERE name = '{username}'" return db.execute(query) # OK: パラメータバインディングで安全に def get_user(username): query = "SELECT * FROM users WHERE name = ?" return db.execute(query, (username,)) # NG: 環境変数のハードコード API_KEY = "sk-1234567890abcdef" # OK: 環境変数から読み込み import os API_KEY = os.environ.get("API_KEY") if not API_KEY: raise ValueError("API_KEY environment variable is required") 2. コードの一貫性欠如 AIは同じ問題に対して、会話ごとに異なるパターンを生成する。月曜日にはasync/awaitで書き、火曜日にはPromiseチェーンで書く——コードベース全体の一貫性が崩壊する。 対策として、プロジェクト固有のルールファイルが効果的だ。 # .cursorrules または CLAUDE.md に記述 ## コーディング規約... --- ## MCP（Model Context Protocol） — MCPサーバーの作り方2026年完全ガイド：TypeScript・Python両対応チュートリアル - URL: https://ai-heartland.com/explain/mcp-server-build-guide/ - 更新日: 2026-04-07 - クラスタ: MCP（Model Context Protocol） - 概要: MCPサーバーの作り方を、いま動く書き方で解説。TypeScript・Python両公式SDKでの構築手順、MCP Inspectorでの検証、Claude Code接続、npx/uvxでの配布まで網羅。Python SDK v2の破壊的変更（FastMCP廃止）と2026-07-28仕様改訂の影響も実測で整理した2026年8月版。 - タグ: mcp, claude, AIエージェント, チュートリアル MCPサーバーの作り方は、2026年7月28日の仕様改訂とPython SDK v2で大きく変わった。ネット上に残る2025年のチュートリアルの多くは、いまそのまま実行しても動かない。この記事はTypeScript・Pythonの両公式SDKで実際に手を動かしながら、いま動く書き方でMCPサーバーをゼロから構築する手順をまとめたものだ。まずは完成形を30秒で見てほしい。 30秒でわかる「MCPサーバーの作り方」 ・所要時間：ツール1個の最小サーバーなら30分〜1時間。DB連携など実用サーバーでも2〜3時間 ・言語：公式SDKは10言語。迷ったらTypeScript（本番・配布向き）かPython（プロトタイプ向き） ・作る流れ：①SDKを入れる → ②ツールを関数として定義 → ③stdioで起動 → ④MCP Inspectorで検証 → ⑤claude mcp add で接続、の5ステップ ・2026年8月の最重要注意点：pip install mcp はv2系を入れる。2025年の記事にある from mcp.server.fastmcp import FastMCP はv2では ModuleNotFoundError になる（実測。後述の対照表を参照） ・TypeScriptは事情が違う：npmの @modelcontextprotocol/sdk はまだ1.x系（最新1.30.0）。Pythonだけが先にv2へ移った MCPサーバーとは何か：AIツール拡張の新標準プロトコル 2024年11月にAnthropicが公開したModel Context Protocol（MCP）は、AIアシスタントと外部ツールを接続するオープンな標準プロトコルだ。2026年8月時点で、Claude Code、Cursor、Cline、Windsurf、VS Code Copilotなど主要なAI開発ツールがMCPクライアントとして対応し、公式リポジトリ modelcontextprotocol/servers にはGitHub Star 89,000超が集まっている。 MCPが解決する問題はシンプルだ。従来、AIツールに「ファイルを読む」「データベースを検索する」「APIを叩く」といった機能を追加するには、ツールごとに独自のプラグイン仕様を学ぶ必要があった。MCPは1つのプロトコルで複数のAIクライアントに対応できるため、一度サーバーを作れば Claude Code でも Cursor でも使い回せる。 MCPの通信構造: MCPクライアント（Claude Code, Cursor等）がJSON-RPC over stdio / Streamable HTTPでMCPサーバー（自作ツール）と通信し、MCPサーバーが任意のプロトコルで外部リソース（DB, API, ファイル等）にアクセスする。 MCPサーバーが提供できる機能は3種類ある。 機能 説明 具体例 Tools（ツール） AIが呼び出せる関数 ファイル書き込み、DB検索、API呼び出し Resources（リソース） AIが読み取れるデータ 設定ファイル、ログ、ドキュメント Prompts（プロンプト） 再利用可能なプロンプトテンプレート コードレビュー用プロンプト、SQL生成テンプレート この記事では、TypeScriptとPythonの両方の公式SDKを使って、実用的なMCPサーバーをゼロからステップバイステップで構築する方法を解説する。 graph LR A["AIクライアントClaude Code / Cursor"] -->|"JSON-RPC"| B["MCPサーバー自作ツール"] B -->|"読み取り"| C["ファイルシステム"] B -->|"クエリ"| D["データベース"] B -->|"HTTP"| E["外部API"] B -->|"ツール定義"| A style A fill:#4A90D9,color:#fff style B fill:#7B68EE,color:#fff style C fill:#50C878,color:#fff style D fill:#50C878,color:#fff style E fill:#50C878,color:#fff MCPサーバーの作り方：全体像を5ステップで把握する 個別のコードに入る前に、完成までの道筋を一度俯瞰しておく。どの言語を選んでも、MCPサーバー作りは次の5ステップに分解できる。この記事の構成もこの順番に沿っている。 ステップ やること 使うもの つまずきやすい点 ① 環境準備 SDKをインストールし、プロジェクトを初期化 npm / uv・pip Pythonはv1とv2でimport文が違う（後述） ② ツール定義 AIに呼ばせたい処理を関数として書く server.tool() / @mcp.tool() 説明文（description）が雑だとAIが呼んでくれない ③ 起動 stdioトランスポートでサーバーを走らせる StdioServerTransport console.log を使うとJSON-RPCが壊れる ④ 動作確認 ツールが登録され、実際に動くかを単体で検証 MCP Inspector クライアントに繋ぐ前にここで潰す ⑤ 接続 AIクライアントに登録して実際に使う claude mcp add 等 パスは絶対パスで指定する 先に④を用意すると開発が一気に速くなる 初心者がいちばん時間を溶かすのは「Claude Codeに繋いだが動かない。サーバーが悪いのか設定が悪いのか分からない」という状態だ。MCP Inspector（npx @modelcontextprotocol/inspector）はクライアント抜きでサーバー単体を叩けるので、③が終わった直後にInspectorで確認する癖をつけると、切り分けの手間がほぼ消える。 そもそも自作すべきか：既存のMCPサーバーで足りないかを先に確認する 作り方の解説に入る前に、身も蓋もない前提を1つ置いておきたい。あなたがやりたいことは、すでに誰かがMCPサーバーにしている可能性が高い。modelcontextprotocol/servers のStarが89,000を超えている理由の大半は、公式・コミュニティ製サーバーの厚みにある。 自作が正解になるのは、次のいずれかに当てはまるときだ。 ・社内固有の対象を触りたい——社内API・独自DB・オンプレの業務システムなど、外部に存在しようがないもの ・既存サーバーの粒度が合わない——汎用のDBサーバーだと権限が広すぎる、逆に細かすぎてAIが手順を間違える ・複数の操作を1つの「意図」にまとめたい——「デプロイ前チェック」のように、内部で3〜4個のAPIを叩く処理を1ツールに畳む ・認証・監査を自分で握りたい——どのツールが何を実行したかを自社のログ基盤に流す必要がある 逆に「GitHubを操作したい」「Slackを読みたい」「PostgreSQLを検索したい」といった一般的な対象は、まず既存サーバーを試す方が早い。既存サーバーを1つ動かしてMCPの挙動を体感してから自作に入るのが、遠回りに見えて最短ルートだ。既存サーバーの探し方は本記事後半の「公式MCPサーバーの活用と既存エコシステム」で扱う。 なお既製サーバーを繋ぐ側のコスト感も、自作の要否を判断する材料になる。Notion MCPとは｜ホスト版とローカル版の違いを24ツール・21,831トークン実測で解説では、同一の計測方法（stdio で tools/list を取ってトークン数を数える）で Notion・Blender・Backlog の3サーバーを実測し、ツール数ではなく引数スキーマの複雑さが常駐コストを決めることを確かめている。既存サーバーが重すぎて使えないなら、必要なツールだけを持つ薄いサーバーを自作する動機になる。 【2026年8月版】2025年の記事どおりに作ると動かない：Python SDK v2の破壊的変更 ここが本記事でもっとも重要な節だ。MCPは2026年7月28日に大きな仕様改訂を迎え、Python SDKはそれに合わせてv2.0.0（2026年7月28日リリース）へメジャーバージョンアップした。日本語で読めるMCPサーバー構築記事の多くは2025年に書かれており、そのままなぞると最初のimport文で止まる。 実測：v1とv2で何が通り、何が落ちるか 同じスクリプトを、pip install "mcp>=1.28,<2"（結果1.29.0）と pip install mcp（結果2.0.0）の2つのvenvで実行して比較した。検証環境: macOS / Python 3.14.4 / 2026-08-11実施。 書き方 mcp 1.29.0（v1） mcp 2.0.0（v2） from mcp.server.fastmcp import FastMCP ✅ 通る ❌ ModuleNotFoundError: No module named ‘mcp.server.fastmcp’ FastMCP("demo") ＋ @srv.tool() ✅ 通る ❌ 上記で停止 from mcp.server import MCPServer ❌ AttributeError ✅ 通る MCPServer("demo") ＋ @s.tool() ❌ 上記で停止 ✅ 通る from mcp.types import Tool ✅ 通る ✅ 通る（mcp_types への永続エイリアス） import mcp_types ❌ ModuleNotFoundError ✅ 通る（型が独立パッケージ化） from mcp.server import Server（低レベルAPI） ✅ 通る ✅ 通る 読み取れることは3つある。①FastMCP というクラス名はv2で消え、MCPServer になった。②デコレータ（@tool()）の書き味は変わっていないので、移行で書き直すのは主にimport文とクラス名だ。③mcp.types は残るが、型定義本体は mcp-types という別パッケージに切り出された。 いま2025年のチュートリアルを開いている人へ 記事どおりに pip install mcp して from mcp.server.fastmcp import FastMCP を書くと、v2が入るため確実に ModuleNotFoundError になる。対処は2択： ・記事をそのまま完走したい → pip install "mcp>=1.28,<2" でv1に固定する（v1系はメンテナンスモードで、以後はセキュリティ修正のみ） ・これから長く使う → v2で書く。FastMCP を MCPServer に置き換えるところから始める TypeScriptとPythonでバージョン事情が食い違っている ここを混同すると混乱するので、明示しておく。v2化したのはPython SDKだけで、TypeScript SDKはまだ1.x系だ。 SDK 最新版（2026-08-11時点） メジャー移行 Python（mcp） 2.0.0（2026-07-28） 済み。v1はメンテナンスモード TypeScript（@modelcontextprotocol/sdk） 1.30.0（2026-07-27） まだ1.x系 つまり本記事のTypeScriptのコードは現行のまま有効で、Pythonのコードだけがv1向けの書き方という状態にある（該当箇所には注記を入れた）。「両方いっぺんに壊れた」わけではない点は押さえておきたい。 プロトコル仕様側（2026-07-28改訂）の変更点 SDKの下にあるプロトコル自体も変わっている。サーバーを書くうえで影響が大きいものを挙げる。 ・ステートレス化——initialize / notifications/initialized のハンドシェイクが廃止された。各リクエストが _meta でプロトコルバージョンとクライアント能力を自己申告する ・server/discover の必須化——サーバーは対応バージョン・能力・自身の識別情報を返すこのRPCをMUSTで実装する ・セッションの廃止——Streamable HTTPから Mcp-Session-Id ヘッダーが消えた。状態を持ちたい場合はサーバーが発行したハンドルを通常のツール引数として渡す ・Roots / Sampling / Logging が非推奨に——新規実装では使わない。ログは stderr かOpenTelemetryへ、Samplingは LLM プロバイダのAPIを直接叩く方式へ移行する ・HTTP+SSEトランスポートが正式にDeprecated——2025-03-26から非推奨だったものが、feature lifecycleポリシー上の「Deprecated」に正式に再分類された。新規サーバーはStreamable HTTPで書く ・MRTR（Multi Round-Trip Requests）——サーバーからクライアントを呼ぶ方式が廃止され、サーバーは「追加で聞きたいこと」を InputRequiredResult として返し、クライアントが再送で答える形になった なお公式は12か月の非推奨期間を定めており、Deprecated入りした機能がすぐ消えるわけではない。ただし新規に作るサーバーでわざわざ採用する理由はない。 ステップ①：MCPサーバー開発環境のセットアップ手順（TypeScript / Python） TypeScript SDK（推奨） TypeScript SDKは最も成熟しており、公式サーバーの大半がTypeScriptで書かれている。 # プロジェクト作成 mkdir my-mcp-server && cd my-mcp-server npm init -y # MCP SDK と 型定義をインストール npm install @modelcontextprotocol/sdk zod npm install -D typescript @types/node # TypeScript設定 npx tsc --init --target ES2022 --module NodeNext --moduleResolution NodeNext --outDir build --rootDir src --strict true mkdir src package.json に以下を追加する。 { "name": "my-mcp-server", "version": "1.0.0", "type": "module", "bin": { "my-mcp-server": "./build/index.js" }, "scripts": { "build": "tsc", "dev": "tsc --watch" } } Python SDK Python SDKは mcp パッケージとして提供されている。高レベルAPIが用意されており、デコレータベースで直感的にサーバーを定義できる。 # uvを使う場合（推奨） uv init my-mcp-server && cd my-mcp-server uv add "mcp[cli]" # pipを使う場合 pip install "mcp[cli]" バージョンに注意：以降のPythonコードはv1系（mcp>=1.28,<2）の書き方 上の uv add "mcp[cli]" / pip install "mcp[cli]" は、いま実行すると v2.0.0 が入る。v2ではクラス名が FastMCP → MCPServer に変わっており、以降のサンプルにある from mcp.server.fastmcp import FastMCP は ModuleNotFoundError になる（前掲の実測表を参照）。 ・サンプルをそのまま動かすなら：uv add "mcp[cli]>=1.28,<2" ／ pip install "mcp[cli]>=1.28,<2" でv1に固定する ・v2で書くなら：from mcp.server import MCPServer に読み替え、FastMCP("my-server") を MCPServer("my-server") にする。デコレータ（@mcp.tool()）以下の書き方は変わらないので、置き換えは機械的に済む Python SDKの FastMCP（v2では MCPServer）は、Flaskのようなデコレータスタイルでツールを定義できるのが特徴だ。 from mcp.server.fastmcp import FastMCP # サーバーインスタンス作成 mcp = FastMCP("my-server") # ツール定義（デコレータで宣言） @mcp.tool() def hello(name: str) -> str: """挨拶を返すツール""" return f"こんにちは、{name}さん！" # サーバー起動 if __name__ == "__main__": mcp.run() 公式SDKの全体像（10言語対応） MCPは2026年8月時点で10言語の公式SDKが提供されている（Star数は2026-08-11にGitHub APIで取得した実測値）。 SDK Tier GitHub Stars 推奨用途 Python Tier 1 23,962 デコレータで高速開発、データ分析連携 TypeScript Tier 1 13,119 公式サーバーの主要言語、本番運用・配布 Go Tier 1 4,962 高速・軽量サーバー C# Tier 1 4,462 .NETエンタープライズ環境 Rust Tier 2 3,778 高パフォーマンス要件 Java Tier 2 3,648 Spring Boot連携 PHP Tier 3 1,576 WordPress/Laravel連携 Swift Tier 3 1,462 macOS/iOSネイティブ Kotlin Tier 3 1,433 Android・JVM連携 Ruby Tier 3 882 Railsアプリ連携 Tier 1は公式が完全サポート、Tier 2はコミュニティ主導+公式レビュー、Tier 3はコミュニティ主導。Star数はそのまま成熟度を意味しない——Pythonが突出しているのはデータ分析・AI領域の母数が大きいためで、本番サーバーの配布しやすさではTypeScriptに分がある。 TypeScript vs Python SDKの選択基準 基準 TypeScript SDK Python SDK (FastMCP) 成熟度 ★★★★★ 公式サー... --- ## Claude API & 料金 — Claude API 料金完全ガイド2026｜Opus 5・Sonnet 5・Fable 5を計算機で試算【8/31値上げ】 - URL: https://ai-heartland.com/explain/claude-api-pricing-calculator-2026/ - 更新日: 2026-04-16 - クラスタ: Claude API & 料金 - 概要: claude api 料金を2026年8月6日時点の公式値で完全解説。新しいClaude Opus 5は$5/$25でOpus 4.8と同額。Sonnet 5の導入価格$2/$10は8/31で終了し9/1から$3/$15へ。Haiku 4.5 $1/$5、Fable 5 $10/$50。計算機で月額を即試算し、キャッシュ・バッチで最大90%削減する方法まで。 - タグ: claude, anthropic, API, 料金, コスト, Opus 5, Sonnet 5, Opus 4.8, Fable 5, Haiku 4.5 claude api 料金が結局いくらになるのか——Claude APIを自分のアプリやエージェントに組み込むとき、最初にぶつかるのがこの疑問だ。モデルが多く、導入価格やキャッシュ割引が絡み、「$3/$15」といった数字だけ見ても月にいくら払うのか直感的にわからない。この記事は、その不安に2026年7月7日時点の公式値と、記事内の料金計算機で即答することを目的にしている。 結論から言うと、主力のClaude Sonnet 5は導入価格で入力$2／出力$10（2026年8月31日まで。9月1日からは標準の$3／$15）、新しいClaude Opus 5とOpus 4.8がともに$5／$25、軽量のHaiku 4.5が$1／$5、そして最上位帯のFable 5が$10／$50（いずれも100万トークンあたり）。Opus 5は上位モデルでありながらOpus 4.8と同額で、値上げなしに置き換えられるのが今回いちばん実務に効く点だ。プロンプトキャッシュとBatch APIを組み合わせれば、実コストは最大で90%近く下げられる。以下では、この現行料金を早見表と計算機で示し、モデルの使い分け、コスト削減術、他社比較、サブスクとの損益分岐までを一気通貫で整理する。まずは全体像から見ていこう。関連するモデル選定の詳細はClaude Sonnet 5 解説も参照してほしい。 claude api 料金の要点（2026年7月7日時点の公式値・100万トークンあたり）。Sonnet 5は導入価格$2/$10、キャッシュ読取は約90%オフ。 この記事のポイント（2026年7月7日時点） ・Claude Opus 5が$5/$25で登場——Opus 4.8と同額。上位モデルへの移行に追加コストがかからない。 ・Sonnet 5は導入価格$2/$10（〜8/31）、9/1から標準$3/$15。Haiku 4.5は$1/$5、Fable 5は$10/$50（すべて/MTok）。 ・プロンプトキャッシュ読取は0.1倍（約90%オフ）、Batch APIは50%オフ。両者は併用でき、実コストを大きく圧縮できる。 ・料金は「モデル選択×最適化テク」で数倍変わる。記事内の計算機に自分のトークン量を入れて月額を試算するのが最短。 ・新トークナイザーで同テキストでも約30%多くトークンを消費する点に注意（Sonnet 5・Opus 4.7以降・Fable 5）。単価だけ見ると過小評価になる。 Claude API 料金の全体像（2026年7月版・全モデル早見表） まずclaude api 料金の全体像を、現行の全モデルで一望できる早見表にまとめる。Claude APIはトークン従量課金制で、料金は「入力トークン」と「出力トークン」の2軸で決まる。トークンとはテキストを分割した最小単位で、日本語ならおおむね1文字が1〜2トークンに相当すると考えればよい。MTok = 100万トークンあたりの価格（USD）で、すべて2026年7月7日にAnthropic公式の料金ページで確認した公称値である。 claude api 料金の全モデル早見（2026年7月7日時点・/MTok）。上位ほど高単価で、用途に対して過剰なモデルを選ばないことがコスト最適化の第一歩。 モデル 入力（/MTok） 出力（/MTok） コンテキスト 立ち位置 Claude Fable 5 $10 $50 1M 最上位・最難関/長時間自律作業 Claude Opus 5 $5 $25 1M 現行Opus。複雑なエージェント／コーディングの主力 Claude Opus 4.8 $5 $25 1M 前世代Opus。同額で併存 Claude Sonnet 5（導入・〜8/31） $2 $10 1M 中位・コスパ最適化の既定 Claude Sonnet 5（標準・9/1〜） $3 $15 1M 同上（導入価格終了後） Claude Haiku 4.5 $1 $5 — 高速・軽量タスク向け Sonnet 5の価格は「今だけ半額」に近い（2026年7月7日時点） 現在のSonnet 5は導入価格として入力$2／出力$10で提供されており、これは2026年8月31日まで。2026年9月1日からは標準価格の入力$3／出力$15に切り替わる。つまり導入期間中のSonnet 5は、出力単価でOpus 4.8（$25）の半分以下で使える計算だ。コスト試算をするときは、9月以降の運用なら標準の$3／$15で見積もるほうが安全。料金は変動しうるので、最新の値は必ず公式の料金ページで確認してほしい。 Claude Opus 5は「値上げなしの上位モデル」（2026-08-06 追記） 本記事の前版になかった Claude Opus 5 が加わった。単価は入力$5／出力$25で、Opus 4.8とまったく同じ。コンテキストも1Mで据え置きなので、料金表を書き換えずに上位モデルへ寄せられるのが実務上の要点になる。 コスト面で押さえておきたい差は2つ。①思考（thinking）が既定でオン——Opus 4.8では thinking を省略すると思考なしで動いたが、Opus 5は省略すると適応的思考が走る。max_tokens は「思考＋本文」の合計に効くため、旧設定のままだと出力が途中で切れるうえ、思考ぶんのトークン課金が乗る。②プロンプトキャッシュの最小プレフィックスが512トークンへ下がった（Opus 4.8は1,024）。これまで「短すぎてキャッシュに載らない」と諦めていたプロンプトが、コードを変えずにキャッシュ対象になる。 なお speed: "fast"（fast mode）を使う場合だけは$10／$50と別料金になる。 日本円での見積もりについて Anthropicの料金はすべて米ドル建てで、公式に日本円の価格表は存在しない。本記事に出てくる円換算は、読みやすさのために 1ドル＝150円 と仮定した参考値であり、実際の請求額は決済時のカード会社レートで変動する。円で予算を立てる場合は「$◯◯／月 × その時点のレート」で都度計算し、レート変動ぶんのバッファを見ておくのが安全だ。 ここで読者が気にする「①結局いくらできる／②何を安く解決できる／③何を高いモデルの代わりにできる」に当てはめると、①Haiku 4.5なら分類・整形を1リクエスト数円以下でこなせ、②Sonnet 5は導入価格を使えば通常のコーディングやエージェントをOpus帯より大幅に安く回せ、③Opus 4.8で足りる多くの作業をSonnet 5で代替できる——という整理になる。出力トークンは入力の5倍高いという共通の性質があるため、長い応答を大量に生成するタスクほど、モデル選択の巧拙が月額に直結する。 料金全体を眺めるうえで、単価表に現れない要素も押さえておきたい。ひとつはプロンプトキャッシュで、共通の長い前提文を繰り返し送る場合、キャッシュ読取は入力単価の0.1倍（約90%オフ）まで下がる。もうひとつはBatch APIで、リアルタイム性が不要な一括処理を入力・出力とも50%オフで実行できる。さらに、Fable 5・Opus 4.8・Sonnet 5などは1Mトークンの長文脈を標準価格で使える（90万トークンを入れても単価は変わらない）。これらの割引・特性を前提にすると、単純な単価表以上に実コストは動く。だからこそ、次に用意した計算機で自分のワークロードを入れて試すのが早い。 もうひとつ、コストに直接効く見落としやすい要素が新トークナイザーだ。Opus 4.7以降・Fable 5・Sonnet 5などは新しいトークナイザーを採用しており、同じテキストでも従来比で約30%多くトークンを消費する。単価が同じでも消費トークンが増えるぶん、実コストは上振れする。旧モデルの見積もりをそのまま流用せず、count_tokensなどで実測し直すのが安全だ。この点は後半の他社比較でも効いてくる重要な差別化ポイントである。 claude api 料金シミュレーター｜ユースケース別に月額を試算 早見表で単価は分かった。次は、claude api 料金を自分の使い方に当てはめて月額に落とし込む番だ。下のシミュレーターに「1リクエストの入力・出力トークン数」「1日のリクエスト数」「キャッシュ利用」を入れると、全モデルの月額コストを自動で計算して安い順に並べる。単価はすべて2026年7月7日時点の公式値をプリセット済みで、Sonnet 5は導入価格（$2/$10）で登録している（9月以降の運用なら後述の標準価格で読み替える）。 claude api 料金は用途で桁が変わる。計算機に自分のトークン量を入れ、モデルと割引の組み合わせで月額を比較する。 💰 Claude API 料金シミュレーター（2026年7月7日時点） 1リクエストの入力トークン数 ※ 短い質問≒500、長文要約≒5,000、RAG≒10,000 1リクエストの出力トークン数 ※ 短い回答≒300、コード生成≒2,000、長文≒4,000 1日のリクエスト数 割引（入力に適用） なし（通常料金） Batch API（入力/出力とも50%OFF） プロンプトキャッシュ読取（入力90%OFF） 代表モデルで詳しく見る Claude Sonnet 5（導入 $2/$10） Claude Sonnet 5（標準 $3/$15・9月〜） Claude Opus 5（$5/$25） Claude Opus 4.8（$5/$25） Claude Haiku 4.5（$1/$5） Claude Fable 5（$10/$50） ※ 1USD=150円で換算。Batch選択時は出力も50%OFF、キャッシュ選択時は入力のみ90%OFFで計算。実際の為替・単価により変動します。2026年7月7日時点の公式値。 計算機の使い方を、代表的な3つのユースケースで具体的に見てみよう。いずれも仮定値を明記して計算過程を見せる（架空の利用者エピソードではなく、パラメータを置いた試算である）。 ユースケース①：チャットボット、月10万メッセージをHaiku 4.5で。 1リクエストの平均を入力2,000トークン／出力500トークンと仮定し、月10万メッセージ（=1日あたり約3,333リクエスト）とする。Haiku 4.5（$1/$5）の場合、1リクエストのコストは「2,000/100万×$1＋500/100万×$5＝$0.002＋$0.0025＝$0.0045」。月10万件で約$450（約6.75万円）。同じ条件をSonnet 5（導入$2/$10）にすると1リクエスト$0.009で月約$900、Opus 4.8では$0.0225で月約$2,250。定型的な応答が中心のチャットボットなら、Haiku 4.5に振るだけで数倍の差が出るのが分かる。 ユースケース②：RAGで大きな共通プロンプトをキャッシュ。 検索結果や社内ドキュメントを毎回同じ前提として渡すRAGでは、共通部分をキャッシュに載せる効果が大きい。仮に1リクエストの入力1万トークンのうち8,000トークンが共通の前提文（キャッシュ対象）、2,000トークンが可変のクエリ、出力1,000トークンとする。Sonnet 5（導入$2/$10）で通常なら入力コストは「10,000/100万×$2＝$0.02」だが、共通8,000トークンをキャッシュ読取（0.1倍）にできれば、その部分は$0.016→$0.0016に。入力コストは約$0.0056まで下がり、入力側だけで7割超の削減になる。1日1,000リクエストなら、この差が月数万円規模になる。 ユースケース③：エージェントでSonnet 5を大量反復。 コーディングエージェントは1タスクで何十回もモデルを呼ぶ。1ステップ平均を入力4,000／出力2,000トークン、1タスク30ステップ、1日20タスクと仮定する。1ステップのSonnet 5（導入$2/$10）コストは「4,000/100万×$2＋2,000/100万×$10＝$0.008＋$0.02＝$0.028」。1日20タスク×30ステップ=600ステップで$16.8、月約$504。同じ負荷をOpus 4.8にすると1ステップ$0.07で月約$1,260。エージェントは出力（=生成）を大量に重ねるため、導入価格中のSonnet 5を土台にできるかどうかが、運用コスト全体を大きく左右する。 モデルの使い分け｜Sonnet 5・Opus 4.8・Haiku 4.5・Fable 5 claude api 料金を賢く抑える核心は、タスクの難易度に対して過不足のないモデルを選ぶことだ。全リクエストを最上位に投げるのは純粋な無駄で、逆に難しい判断を安いモデルに任せれば品質が崩れる。ここでは現行4モデルの立ち位置を、料金と用途の両面から整理する。 用途に対して過剰なモデルを選ばないのがコスト最適化の基本。難易度が上がるほど上位モデルへエスカレーションする。 ・Haiku 4.5（$1/$5） — 分類・ラベリング・抽出・整形など、考える余地が小さい定型処理。速度とコストを最優先する経路に最適。大量のログ分類やタグ付けはここで十分 ・Sonnet 5（導入$2/$10、標準$3/$15） — 通常のコード生成・修正、一般的なQ&A、ツール呼び出しを伴うエージェントの反復。「一定品質を回数を回しながら安く出したい」領域で最もコスパが際立つ既定モデル ・Opus 5（$5/$25） — 現行のOpus。複雑なエージェント作業・コーディング・長時間の自律実行。Opus 4.8と単価が同じなので、上位モデルが要る経路はここが既定になる ・Opus 4.8（$5/$25） — 前世代のOpus。Opus 5と同額で併存しているため、あえて選ぶのは挙動を固定したい場合に限られる ・Fable 5（$10/$50） — 人の介入なしに長時間動く自律エージェント、監督コストが高い最難関タスク。コスト2倍以上を性能で回収できる場面に絞る 料金差を具体的に見ると、導入価格中のSonnet 5はHaiku 4.5の2倍だが、Opus 4.8の半額以下、Fable 5の1/5だ。「まずHaikuで試す→精度不足ならSonnet 5→それでも足りなければOpus 4.8、最難関だけFable 5」というエスカレーション方式が、品質とコストの両立という意味で最も現実的な戦略になる。とくにエージェントは試行回数が多くトークン消費が大きいため、土台をSonnet 5にできるかどうかで月額が大きく変わる。 このモデル選定を、リクエストが来たときにどう振り分けるかのフローで整理すると次のようになる。 flowchart TD A["リクエスト到着"] --> B{"タスクの難易度は?"} B -->|"分類・抽出・整形"| H["Haiku 4.5$1/$5"] B -->|"通常のコード・Q&A・エージェント"| S["Sonnet 5導入$2/$10（標準$3/$15）"] B -->|"複雑な推論・難しいバグ調査"| O["Opus 4.8$5/$25"] B -->|"長時間の自律作業・最難関"| F["Fable 5$10/$50"] H --> Q{"品質は足りた?"} S --> Q Q -->|"足りない"| UP["一段上のモデルへエスカレーション"] Q -->|"足りた"| DONE["確定"] O --> DONE F --> DONE なお、Sonnet 5・Opus 4.8・Fable 5は1Mトークンの長文脈を標準価格で扱える（Haiku 4.5は長文脈対象外）。大規模なコードベースや長大な仕様書を分割せず一度に渡せるため、文脈の取りこぼしによる的外れな出力を減らせる。ただし入力を増やせば入力トークンも増える。「入れられる」と「入れるべき」は別、という設計判断がここでも効く。モデル選定のより詳しい観点はClaude Sonnet 5 解説とClaude Fable 5 解説で扱っている。 claude api 料金を最大90%下げる｜キャッシュ・バッチ・Haiku振り分け モデルを選んだら、次はclaude api 料金そのものを圧縮する番だ。Claude APIには強力なコスト削減機能があり、適切に組み合わせれば実コストを50〜90%下げられる。効果が大きい順に3つの技を見ていく。 claude api 料金を下げる3手法。キャッシュとバッチは併用でき、モデル振り分けと合わせれば実コストは大きく縮む。 1. プロンプトキャッシュ（キャッシュ読取は約90%オフ）。 同じシステムプロンプトやドキュメントを繰り返し送る場合、その共通部分をキャッシュに載せると、2回目以降のキャッシュ読取（ヒット）は入力単価の0.1倍になる。書き込みには倍率がかかる（5分キャッシュ書込は1.25倍、1時間書込は2倍）が、5分キャッシュなら1回でも再利用されれば元が取れる設計だ。RAGやチャットのように「毎回同じ前提を渡す」用途では効果が絶大で、前述のRAG試算のように入力側だけで7割超の削減も珍しくない。 2. Batch API（入力・出力とも50%オフ）。 リアルタイム応答が不要なタスク——夜間の一括要約、大量文書の分類、定期バッチ処理など——にはBatch APIを使う。全モデルで入力・出力ともに50%オフになり、しかもプロンプトキャッシュと併用できる。非同期で結果が返る前提を許容できるなら、ほぼ無条件で半額になる強力な選択肢だ。下表はバッチ適用時の単価をまとめたもの（2026年7月7日時点の公式値）。 モデル 通常（入力/出力） Batch（入力/出力） 削減 Fable 5 $10 / $50 $5 / $25 50%OFF Opus 4.8 $5 / $25 $2.50 / $12.50 50%OFF Sonnet 5（導入） $2 / $10 $1 / $5 50%OFF Haiku 4.5 $1 / $5 $0.50 / $2.50 50%OFF 3. Haiku振り分け（モデルのルーティング）。 前章で見たとおり、分類・整形のような軽いタスクをHaiku 4.5に、通常タスクをSonnet 5に、最難関だけOpus 4.8/Fable 5に振り分けるだけで、全体コストは大きく下がる。全リクエストをOpus 4.8で処理していた運用をHaiku 4.5とSonnet 5に分散すれば、品質を保ちながら数分の一に圧縮できるケースは多い。 この3手法をどの順で当てるかを、コスト最適化の多段フローとして整理する。 flowchart TD START["月額コストを下げたい"] --> R{"リアルタイム応答が必要?"} R -->|"不要"| BATCH["Batch API入力/出力 50%OFF"] R -->|"必要"| ROUTE["タスク難易度でモデル振り分け"] ROUTE -->... --- ## UI生成 & デザインシステム — デザインシステムとは？仕組み・構成要素・有名事例をエンジニア向けに整理する【2026年版】 - URL: https://ai-heartland.com/explain/design-system-guide/ - 更新日: 2026-04-18 - クラスタ: UI生成 & デザインシステム - 概要: デザインシステムとは何か？デザイントークン・コンポーネント・ガイドラインの3層構造から、デジタル庁・Material Design・Shopify Polaris等の有名事例、AI時代のClaude Design連携まで。エンジニア視点で実装に落とし込める完全ガイド。 - タグ: ui, automation デザインシステムという言葉を聞いたことがあるだろうか。Googleの「Material Design」、Appleの「Human Interface Guidelines」、デジタル庁の「デザインシステムβ版」——名前は知っていても、「結局何なのか」「自分のプロジェクトにどう関係するのか」を明確に説明できるエンジニアは意外と少ない。 デザインシステムは「UIの設計図」ではない。「チーム全員が同じ言語でUIを語るための仕組み」だ。色の名前、ボタンの種類、余白の取り方——こうした設計の判断を属人的な感覚ではなく、共通のルールとして定義し、コードとドキュメントで共有する。それがデザインシステムの本質だ。 2026年現在、デザインシステムの重要性はさらに増している。Claude DesignのようなAIデザインツールが登場し、「コードベースからデザインシステムを自動構築する」時代になった。AIがUIを生成する時代だからこそ、デザインシステムという「仕様書」がなければ、毎回バラバラなUIが生成されてしまう。 この記事では、デザインシステムの基本概念から3層構造の実装、有名企業の事例、AI時代における変化まで——エンジニアがコードレベルで理解できる形で解説する。 この記事でわかること デザインシステムとは何か — スタイルガイドとの違い、3層構造 デザイントークン — 色・フォント・余白をコードで管理する方法 コンポーネント — 再利用可能なUI部品の設計原則 有名事例 — デジタル庁・Material Design・Shopify Polaris・IBM Carbon AI時代の変化 — Claude Design・DESIGN.mdとの連携 デザインシステムとは — 「UIのルールブック」を理解する デザインシステムとは、プロダクトのUI（ユーザーインターフェース）に一貫性を持たせるための、設計ルール・再利用可能なコンポーネント・ドキュメントの集合体だ。 もう少し具体的に言えば、以下の問いに対する「チーム共通の答え」を体系化したものがデザインシステムだ。 プライマリカラーは #2563EB か #1D4ED8 か？ ボタンの角丸は 4px か 8px か full-rounded か？ 見出しのフォントサイズは 24px か 1.5rem か？ エラーメッセージは赤いバナーで出すのか、インラインで出すのか？ モーダルを閉じるボタンは右上か左上か？ こうした判断を個々のデザイナーやエンジニアが毎回考えていたら、UIは必ずバラバラになる。デザインシステムは、これらの判断を一度決めて、全員で共有する仕組みだ。 スタイルガイドとの違い デザインシステムと混同されやすい概念を整理する。 概念 範囲 形式 例 スタイルガイド ビジュアルルールのみ ドキュメント（PDF・Wiki） 「プライマリカラーは#2563EB」 コンポーネントライブラリ 再利用可能なUI部品 コード（React/Vue等） <Button variant="primary"> デザインシステム 上記すべて＋ガイドライン＋設計原則 コード＋ドキュメント＋Figma Material Design全体 スタイルガイドは「何色を使うか」。コンポーネントライブラリは「何を使うか」。デザインシステムは「なぜ、どう使うか」まで含む。 デザインシステムの3層構造 デザインシステムは一般に、以下の3層で構成される。この構造はデジタル庁からGoogleまで、規模を問わず共通している。 graph TD A["デザイントークン（Design Tokens）"] --> B["コンポーネント（Components）"] B --> C["ガイドライン（Guidelines）"] A -.->|"色・フォント・余白"| A1["#2563EB / Inter / 16px"] B -.->|"UIパーツ"| B1["Button / Card / Modal"] C -.->|"使い方のルール"| C1["エラーは赤バナー確認はモーダル"] 層 役割 具体例 デザイントークン 最小単位の設計値。色・フォント・余白・影・角丸 --color-primary: #2563EB コンポーネント トークンを使って構築された再利用可能なUI部品 <Button>, <Card>, <Modal> ガイドライン コンポーネントの使い方・禁止パターン・アクセシビリティ要件 「削除ボタンは必ず確認ダイアログを出す」 デザイントークンとは — UIの「変数」をコードで管理する デザイントークンは、デザインシステムの最も基礎的な構成要素だ。「UI の設計値に名前をつけたもの」と理解すればよい。 なぜデザイントークンが必要か デザイントークンがない世界を想像してみよう。 /* トークンなし: 同じ青が3種類のハードコード */ .header { background: #2563EB; } .button { background: #2564EB; } /* 微妙に違う */ .link { color: #2563eb; } /* 大文字小文字の違い */ デザイントークンがあれば、設計値は1箇所で管理され、全UIが自動的に統一される。 /* トークンあり: Single Source of Truth */ :root { --color-primary: #2563EB; --color-primary-hover: #1D4ED8; --color-text: #1A1A2E; --font-heading: 'Inter', sans-serif; --font-size-h2: 1.5rem; --spacing-md: 16px; --radius-md: 8px; } .header { background: var(--color-primary); } .button { background: var(--color-primary); } .link { color: var(--color-primary); } デザイントークンの階層構造 実務で使われるデザイントークンは、3つの抽象レベルに分かれる。 レベル 名前 例 役割 Primitive 生の値 blue-500: #2563EB カラーパレットの定義 Semantic 意味を持つ名前 color-primary: {blue-500} 用途に基づく命名 Component コンポーネント固有 button-bg: {color-primary} 特定UIへの適用 { "color": { "blue": { "500": { "value": "#2563EB" } }, "primary": { "value": "{color.blue.500}" }, "button": { "background": { "value": "{color.primary}" } } } } Primitiveだけでは「何に使うか」がわからない。Semanticレイヤーが「この色はプライマリ用途」と意味を与え、Componentレイヤーが「ボタンの背景はプライマリ」と具体的に紐づける。 Tailwind CSSでのトークン管理 フロントエンドの現場では、Tailwind CSSの設定ファイルがデザイントークンの役割を果たすケースが多い。 // tailwind.config.js module.exports = { theme: { colors: { primary: '#2563EB', 'primary-hover': '#1D4ED8', secondary: '#7C3AED', background: '#FAFAFA', text: '#1A1A2E', error: '#DC2626', success: '#16A34A', }, fontFamily: { heading: ['Inter', 'Noto Sans JP', 'sans-serif'], body: ['Inter', 'Noto Sans JP', 'sans-serif'], mono: ['JetBrains Mono', 'monospace'], }, spacing: { xs: '4px', sm: '8px', md: '16px', lg: '24px', xl: '32px', }, borderRadius: { sm: '4px', md: '8px', lg: '16px', full: '9999px', }, }, } このファイルが「デザイントークンの実装」そのものだ。bg-primary、text-error、rounded-md ——Tailwindのユーティリティクラスがトークンの参照になる。 Style Dictionaryで多プラットフォーム対応 Web、iOS、Androidで同じデザインシステムを使う場合は、Amazon発のオープンソースツール Style Dictionary が有力だ。JSONで定義したトークンをCSS変数・SwiftUI・Android XML・Tailwind設定に自動変換できる。 コンポーネント — 再利用可能なUI部品の設計原則 デザイントークンが「素材」なら、コンポーネントは「部品」だ。トークンを使って構築された再利用可能なUI要素がコンポーネントにあたる。 コンポーネントの分類 コンポーネントはAtomic Design（Brad Frost提唱）の考え方で階層化されることが多い。 レベル 名前 例 説明 Atom 最小要素 ボタン、入力欄、ラベル、アイコン これ以上分解できないUI要素 Molecule 小さな複合体 検索バー（入力欄+ボタン）、フォームフィールド（ラベル+入力欄+エラーメッセージ） Atomの組み合わせ Organism セクション ヘッダー、カード一覧、サイドバー Moleculeの組み合わせでページの一部を構成 Template ページ構造 ダッシュボードレイアウト、記事ページ Organismの配置を定義 Page 最終画面 トップページ、設定画面 実データが入ったTemplate graph LR A["Atomボタン/入力欄"] --> B["Molecule検索バー"] B --> C["Organismヘッダー"] C --> D["Templateダッシュボード"] D --> E["Page実画面"] コンポーネントの実装パターン デザインシステムのコンポーネントは、バリアント（variant）パターンで実装するのが標準的だ。 // Button コンポーネント（React + Tailwind） type ButtonVariant = 'primary' | 'secondary' | 'danger' | 'ghost'; type ButtonSize = 'sm' | 'md' | 'lg'; const variantStyles: Record<ButtonVariant, string> = { primary: 'bg-primary text-white hover:bg-primary-hover', secondary: 'bg-gray-100 text-gray-800 hover:bg-gray-200', danger: 'bg-error text-white hover:bg-red-700', ghost: 'bg-transparent text-primary hover:bg-gray-50', }; const sizeStyles: Record<ButtonSize, string> = { sm: 'px-3 py-1.5 text-sm rounded-sm', md: 'px-4 py-2 text-base rounded-md', lg: 'px-6 py-3 text-lg rounded-md', }; export function Button({ variant = 'primary', size = 'md', children, ...props }) { return ( <button className={`${variantStyles[variant]} ${sizeStyles[size]}`} {...props}> {children} </button> ); } // 使用例 <Button variant="primary" size="md">保存する</Button> <Button variant="danger" size="sm">削除</Button> <Button variant="ghost">キャンセル</Button> このパターンなら、デザイントークン（bg-primary）がコンポーネントに組み込まれ、使う側は variant を選ぶだけでブランドに準拠したUIが生成される。 有名事例 — 世界と日本のデザインシステムを比較する デザインシステムの具体像を掴むには、実際の事例を見るのが一番だ。世界的に有名な事例と日本の事例を比較する。 デジタル庁デザインシステム（日本） 日本で最も注目すべきデザインシステムがデジタル庁のβ版（design.digital.go.jp）だ。 項目 内容 目的 「誰一人取り残されない、人に優しいデジタル化」の実現 バージョン v2.13.0（β版） フォント Noto Sans JP（本文）、Noto Sans Mono（コード） 提供形式 HTML/CSS/JavaScript、React/Tailwind CSS、Figma 特徴 アクセシビリティファースト。全コンポーネントにアクセシビリティチェック済み ライセンス 誰でも無料で利用可能 デジタル庁のデザインシステムの最大の特徴はアクセシビリティへの徹底だ。全てのサンプルコードにキーボード操作・スクリーンリーダー対応が組み込まれている。行政サービスは「全国民が使えなければならない」という制約があるため、アクセシビリティが最優先事項となっている。 また、デザイントークンをベースにしたTailwind CSSプラグインも公式提供しており、エンジニアがすぐに実装に取り込める点も実用的だ。 Google Material Design Material Designは世界で最も普及したデザインシステムだ。2014年の初版から10年以上進化し続けている。 項目 内容 コンセプト 「Material Metaphor」 — UIが物理的な表面のように振る舞う 特徴 影（Elevation）、リップルエフェクト、レスポンシブモーション 提供形式 Web Components、Android Jetpack Compose、Flutter トークン管理 Material Theme Builder でカスタマイズ ターゲット クロスプラットフォーム（Android中心） Material Designの強みはクロスプラットフォーム対応だ。Android、Web、Flutter——どの環境でも同じ設計言語が使える。一方で、Apple環境では「Androidっぽい」と感じるユーザーもおり、iOS向けにはApple HIG（Human Interface Guidelines）との使い分けが必要になる。 Shopify Polaris ECプラットフォームShopifyのデザインシステム「Polaris」は、エンジニアフレンドリーな事例として参考になる。 項目 内容 コンポーネント数 90以上（React） 特徴 EC特化。商品管理・注文処理・ダッシュボードに最適化 提供形式 React、Figma UI Kit ドキュメント コンポーネントごとに「Do / Don’t」の使い方ガイド Polarisの優れた点は、全コンポーネントに「Do（推奨）」と「Don’t（非推奨）」の具体例がドキュメントに含まれていること。「ボタンにはアクション動詞を使う（Do: 商品を追加 / Don’t: 送信）」のように、エンジニアが迷わない指針が用意されている。 IBM Carbon IBMのCarbon Design Systemは、エンタープライズ向けの重厚な事例だ。 項目 内容 特徴 アクセシビリティ重視、データ可視化コンポーネント充実 提供形式 React、Angular、Vue、Web Components、Svelte 強み 5フレームワーク対応。チャート・テーブル等のデータUI オープンソース GitHub上で完全公開 SmartHR Design（日本） 日本のSaaSスタートアップから生まれたデザインシステムとして、SmartHR Designは特筆すべき事例だ。 項目 内容 コンセプト 「すべての人によりよい体験を届けるためのデザインシステム」 特徴 デザイントークン・コンポーネント・アクセシビリティ・コミュニケーションガイドラインまで網羅 提供形式 SmartHR UI（オープンソース） アクセシビリティ WCAG準拠、代替テキスト・多言語対応・ロービジョン対応を含む OSSか Yes（「情報をオープンにすることは社会に良い影響をもたらす」が方針） SmartHR Designが優れている点は、日本語環境に特化した設計判断が随所にある点だ。日本語フォントの行間、敬語・丁寧語のトーンガイドライン、多言語対応まで——日本のSaaS開発者にとって最も参考になるデザインシステムの一つだ。 事例比較まとめ デザインシステム ターゲット 特化領域 FW対応数 OSSか デジタル庁 行政サービス アクセシビリティ 2（HTML/CSS, React） Yes SmartHR Design SaaS（HR） 日本語環境・a11y React Yes Material Design 汎用（Android中心） クロスプラットフォーム 3+ Yes Shopify Polaris EC 商品管理・ダッシュボード 1（React） Yes IBM Carbon エンタープライズ データ可視化 5 Yes Apple HIG Apple製品 プラットフォーム体験 SwiftUI No Salesforce Lightning CRM・SaaS 業務アプリ 1（Vanilla CSS） Yes 共通点は「全てオープンソースまたは無料公開」という点。デザインシステムは秘密にするものではなく、公開してエコシステム全体の品質を底上げするものだ。自分のプロジェクトでデザインシステムを作る際は、これらの事例をベースに始めるの... --- ## ドキュメント/ナレッジ — ドキュメント/ナレッジ系OSSの選び方｜知識グラフ・図解生成・構造化抽出マップ - URL: https://ai-heartland.com/explain/docs-knowledge-oss-pillar-2026/ - 更新日: 2026-06-16 - クラスタ: ドキュメント/ナレッジ - 概要: コード/データ/PDF/Webから知識・図表・ドキュメントを生成・抽出・構造化するOSSを3系統に整理。oh-my-mermaid・Graphify・SurfSense・Hyper-Extractなど主要ツールを用途別の比較表と選定フローで解説し、自分の課題に合う1本の選び方をまとめる実装マップ。 - タグ: docs-knowledge, ナレッジグラフ, ドキュメント生成, 構造化抽出, RAG, OSS AIは数秒でコードを書き、長い文章を要約します。ところが、生成された大量の情報を人間が「理解できる・検索できる・あとで再利用できる」形に整える作業は、いまだに手作業の負担として残っています。 コードベースの全体像を把握するには数時間、社内ドキュメントから必要な一節を探すにも時間がかかる——この「情報を知識に変える」ギャップを埋めるのが、本記事でまとめるドキュメント/ナレッジ系OSSです。 30秒で理解する このカテゴリ ・コード/データ/PDF/Web/音声を「読みやすい知識」に変換するOSSを、3系統に整理する地図記事 ・①コード→図解・アーキ系（oh-my-mermaid・Graphify・CodeGraph・DeepWiki-Open など） ・②ナレッジグラフ・知識ベース系（SurfSense・cognee・Atomic・LightRAG など） ・③データ抽出・構造化系（Hyper-Extract・MinerU・LangExtract・officeParser など） ・各系統の比較表と「用途×OSS」マトリクス、導入の選定フローで、自分の課題に合う1本を選べるようにする このカテゴリのOSSは「検索して文脈を渡す」RAGの前段、つまりRAGに食わせる知識そのものを作る側に位置するものが多くあります。RAG全体の仕組みから整理したい場合は、先にRAGとは？仕組み・構築・ベクトルDB選定までの2026年実装マップを読むと、本記事の各ツールが「知識を作る道具」か「検索する道具」かをすっきり区別できます。 このカテゴリの定義——「情報→知識」変換の3系統 ドキュメント/ナレッジ系OSSは、入力（何を読むか）と出力（何を作るか）の組み合わせで大きく3系統に分かれます。 まず全体像を1枚の図で押さえます。 graph LR subgraph IN["入力：読みづらい情報"] A1["コードベース"] A2["PDF / Office文書"] A3["Web / 会議音声"] A4["会話 / ノート"] end subgraph SYS["3系統のOSS"] B1["①コード→図解・アーキ系構成図・知識グラフ化"] B2["②ナレッジグラフ・知識ベース系検索可能な知識に統合"] B3["③抽出・構造化系構造データを取り出す"] end subgraph OUT["出力：扱いやすい知識"] C1["Mermaid図 / Wiki"] C2["ナレッジグラフ / RAG知識ベース"] C3["JSON / Markdown / 型付き構造"] end A1 --> B1 --> C1 A4 --> B2 --> C2 A2 --> B3 --> C3 A3 --> B3 B3 --> B2 3系統は排他ではありません。抽出・構造化系で取り出した構造データを、ナレッジグラフ・知識ベース系に流し込み、最終的にコード→図解系で俯瞰する——という連携が現場では起こります。 この記事では、まず系統ごとに代表OSSを比較し、最後に「自分の課題から逆引きする」マトリクスと選定フローを置きます。 このカテゴリに含めない3つ：純粋なRAG検索フレームワーク（LangChain・RAGFlow等）、ベクトル/グラフDBエンジン（ストレージ層）、エージェント基盤そのもの。これらは「知識を作る」ではなく「検索する／保存する／実行する」が主目的のため、別カテゴリとして扱います。 なぜ今「情報→知識」変換が重要なのか このカテゴリが2026年に厚みを増しているのには、はっきりした背景があります。 LLMによってコードや文章の「生成」コストが劇的に下がった結果、ボトルネックが生成から理解・検索・再利用の側に移動したからです。 1つ目の理由は、コードの増加です。AIエージェントが書くコード量が増えるほど、人間がレビューし全体像を保つコストが膨らみます。コードベースを図や知識グラフに落とすツールは、この「読む側」の負担を直接削ります。 2つ目は、コンテキストの経済性です。LLMにコードベース全体を読ませると、トークン消費とコストが跳ね上がります。知識グラフで索引を作り「必要な範囲だけ」を渡せれば、ツールコールもコストも減らせます。GraphifyやCodeGraphが大幅な削減を報告しているのは、この経済性に直接効いているからです。トークン最適化の全体像はAIエージェントのトークン最適化ガイドでも整理されています。 3つ目は、RAGの普及です。RAGが当たり前になるほど、「検索される側」の知識ベースの質が結果を左右します。PDFをきれいにMarkdown化する、文書から型付き構造を取り出す——という前処理の良し悪しが、そのままRAGの精度に直結します。 この3つの圧力が生む需要 ・コードが増える → コードを図・知識グラフにする道具（①系統） ・コンテキストが高い → 知識を索引化してトークンを節約する道具（①②系統） ・RAGが普及する → 検索される知識を高品質に作る道具（②③系統） ・結果として「情報を知識に変換するOSS」が、生成系AIとセットで必要になっている コード→図解・アーキ系——コードベースを「読める図」に変える 最初の系統は、コードベースやリポジトリを解析して、アーキテクチャ図・知識グラフ・ドキュメントに変換するOSSです。 AIが書いたコードを人間がレビューする・新メンバーが全体像をつかむ・LLM自身が効率よくコードを読む、といった場面で効きます。 OSS 入力 主な出力 際立つ特徴 oh-my-mermaid コードベース Mermaid図＋Markdown（.omm/） CLI＋Claude Codeスキル、perspective再帰分析 Graphify コード/文書/画像 ナレッジグラフ AI検索トークンを大幅削減、マルチモーダル対応 CodeGraph コードベース ローカル知識グラフ（MCP） tree-sitter AST→SQLite、ツールコール71%削減 Understand Anything コードベース ナレッジグラフ（Claude Codeプラグイン） プラグイン形式で対話的に探索 Code Review Graph コードベース コード知識グラフ AST構築、トークン消費を大幅圧縮 DeepWiki-Open GitHubリポジトリ AI Wiki リポジトリ全体を自動ドキュメント化 Google Code Wiki GitHubリポジトリ ドキュメント＋アーキ図 Geminiで生成、図とテキストを同時出力 fireworks-tech-graph 自然言語指示 SVG/PNG技術ダイアグラム 8スタイル・14種UML、Claude Skill Meet HLD Agent 会議音声 Mermaidアーキ図 設計会議からリアルタイム図化 コードからローカルに構成ドキュメントを残したいなら、oh-my-mermaidが入口です。コマンド一発でMermaid図つきのアーキテクチャドキュメントを.omm/に生成し、Gitで履歴管理できます。 同じ「コード→知識グラフ」でも、AIエージェントのトークン削減を主目的にするならGraphifyと、その実践編であるgraphifyでトークンを71.5倍削減する知識グラフスキル、そしてMCPサーバーとして動くCodeGraphが候補になります。 対話的にコードベースを探索したいならUnderstand Anything、ASTでコード知識グラフを構築するCode Review Graphも同系統です。 リポジトリ全体を「読み物」に起こしたい場合は、AI Wikiを自動生成するDeepWiki-Openや、Geminiでドキュメントとアーキ図を同時に作るGoogle Code Wikiが便利です。 図そのものをピンポイントで作りたいケースもあります。自然言語の指示からUMLやシーケンス図を生成するfireworks-tech-graphは、コードベース全体ではなく「この処理の図が欲しい」に応えます。 変わり種として、設計会議の音声からリアルタイムでMermaid図を起こすMeet HLD Agentもこの系統に入ります。 選び方の軸：①出力をGit管理したい→oh-my-mermaid・CodeGraph、②エージェントのコスト削減が主目的→Graphify・CodeGraph、③リポジトリ全体をWiki化→DeepWiki-Open・Google Code Wiki、④単発の図が欲しい→fireworks-tech-graph。 この系統には2つの流派があります。1つは「人間が読む図・ドキュメントを作る」流派（oh-my-mermaid・DeepWiki-Open・Google Code Wiki・fireworks-tech-graph）で、レビューやオンボーディングのコストを下げるのが狙いです。 もう1つは「AIが効率よくコードを読むためのグラフを作る」流派（Graphify・CodeGraph・Code Review Graph・Understand Anything）で、こちらはLLMのツールコールとトークンを減らすのが狙いです。 同じ「コード→グラフ」でも目的が違うため、まず読む主体が人間かAIかを決めると候補が一気に絞れます。両方を兼ねたい場合は、Gitに残るMermaid出力を持つツール（oh-my-mermaid）と、AI向け索引を持つツール（CodeGraph）を併用するのが現実的です。 ナレッジグラフ・知識ベース系——文書と会話を「検索できる知識」に統合 2つ目の系統は、文書・ノート・会話を集約し、横断検索できる知識ベースやナレッジグラフを構築するOSSです。 社内ドキュメントの検索、個人のセカンドブレイン、AIメモリの永続化といった用途に向きます。 OSS 何を統合するか 内部表現 セルフホスト SurfSense 文書・Web・各種ソース RAG知識ベース ◯（NotebookLM代替） cognee 文書・会話 ナレッジグラフ型AIメモリ ◯ Atomic Markdownノート 意味でつなぐ知識ベース ◯（Rust製） Claude Memory Compiler Claude Codeの会話 index.md方式の知識記事 ◯（RAG不使用） LightRAG 文書 知識グラフ＋デュアル検索 ◯ notebooklm-py PDF・各種ソース NotebookLMの知識ベース △（NotebookLM自動化） データ量の制限なく自前で「NotebookLMのようなもの」を持ちたいなら、SurfSenseが第一候補です。自己ホスト可能で、複数ソースを横断する知識ベースを構築できます。 知識を「グラフ」として持ち、AIの長期記憶に使いたいならcogneeが向きます。ナレッジグラフ型のRAGメモリで、Claude APIやMCPと連携できます。 Markdownノート派には、ノート同士を意味でつなぐRust製のAtomicが軽量です。 ひと味違うのがClaude Memory Compilerで、Claude Codeとの会話そのものをフックで自動キャプチャし、知識記事へコンパイルします。RAGを使わないindex.md方式という設計が特徴です。 「知識グラフ × 検索」を一体で持ちたいならLightRAG、既存のNotebookLMをPython APIから一括処理・自動化したいならnotebooklm-pyが、それぞれ実用的な選択肢になります。 知識ベースとナレッジグラフの境目 ・ナレッジグラフ＝概念をノードとエッジで表す「関係のデータ構造」（cognee・LightRAG・Graphify） ・知識ベース＝文書・ノートを検索可能に集約した「貯蔵庫」（SurfSense・Atomic） ・多くのツールは知識ベースの内部でナレッジグラフを使う。両者は重なり合う関係であり、どちらか一方を選ぶ排他的な分類ではない この系統を選ぶときに効くのは、データの置き場所の判断です。社外秘の文書や個人の記録を扱うなら、クラウドのNotebookLMではなくセルフホスト型（SurfSense・Atomic・cognee）が安心です。 逆に、すでにNotebookLMを使っていて運用を自動化したいだけなら、ゼロから知識ベースを作り直さずnotebooklm-pyで一括処理に寄せるほうが速く済みます。 もうひとつの軸は「入力が何か」です。整ったMarkdownノートを育てるならAtomic、雑多な複数ソースをまとめて飲み込ませるならSurfSense、AIエージェントの長期記憶として使うならcognee、というように入力の質と用途で住み分けると迷いません。 データ抽出・構造化系——PDF/Web/音声から「構造データ」を取り出す 3つ目は、非構造な入力（PDF・Office文書・Web・会議音声）から、Markdownや型付きの構造データを取り出すOSSです。 RAGや知識グラフの「前処理」を担うことが多く、このカテゴリの土台になります。 OSS 入力 出力 用途の中心 Hyper-Extract 非構造テキスト 8種の型付き知識構造 グラフ/ハイパーグラフ抽出 Google LangExtract 非構造テキスト 構造化抽出（ソース位置追跡） 出典を保ったまま構造化 MinerU PDF Markdown（表・数式・レイアウト） 高精度PDF→MD変換 officeParser docx/xlsx/pptx AST/テキスト Office文書のRAG前処理 liteparse 各種文書 パース結果 Rust製・高速RAG前処理 AI Reads Books PDF 知識ベース ページ単位でAI解析 Scrapling Webページ 構造データ 自然言語Webスクレイピング Meetily 会議音声 議事録・要点 音声→文字起こし・抽出 テキストから「型」を選んで知識構造を取り出すならHyper-Extractが強力で、グラフからハイパーグラフ、時空間グラフまで標準で扱えます。出典の位置を保ったまま構造化したいならGoogle LangExtractが向きます。 PDFの取り扱いは選択肢が多く、表・数式・レイアウトを高精度にMarkdown化するMinerU、ページ単位でAI解析して知識ベースを作るAI Reads Booksが代表です。Office文書まで含めるならofficeParser、Rustで前処理速度を稼ぐならliteparseが候補になります。 どのPDF抽出OSSがライセンス・用途に合うか迷ったら、用途別・ライセンス別に8本を比較したAI PDF要約ツール8選が選定の近道です。 Webを対象にするなら、自然言語の指示で構造データを抜き出すScrapling、会議の音声を文字起こしして要点まで抽出するMeetilyが、それぞれ「Web→構造」「音声→構造」を担います。 この系統で見落としやすいのが出典の追跡です。抽出した知識が「元のどこから来たか」を保てるかどうかで、後工程のファクトチェックのしやすさが変わります。Google LangExtractがソース位置の追跡を備えているのはこの理由からで、決算資料や契約書のように根拠が重要な文書では効いてきます。 また、PDFは「テキストレイヤーがあるか」「表や数式が多いか」で最適なツールが変わります。表・数式・段組みが多い学術PDFや財務資料ならMinerUの精度が活き、軽量に大量処理したいならliteparseやofficeParserが向きます。入力の性質をひとことで言語化してから選ぶと、前処理の作り直しを避けられます。 用途×OSS 推奨マトリクス——課題から逆引きする ここまでの3系統を、よくある課題から逆引きできるようにまとめます。 やりたいこと 第一候補 次の候補 コードの全体像を図で残す oh-my-mermaid CodeGraph / Code Review Graph リポジトリをWiki化する DeepWiki-Open Google Code Wiki エージェントのトークンを削る Graphify CodeGraph 単発の技術図（UML等）が欲しい fireworks-tech-graph Meet HLD Agent 社内文書を横断検索する SurfSense cognee ノートを知識として育てる Atomic Claude Memory Compiler 知識グラフ×RAGを一体で持つ LightRAG cognee PDFをMarkdownにする MinerU officeParser / liteparse テキストから型付き構造を抽出 Hyper-Extract Google LangExtract Webを構造データにする Scrapling — 会議音声を議事録にする Meetily — まず「入力（何を読むか）」で系統を絞り、次に「出力（何を作るか）」で1本に決めるのが迷わない順番です。入力がコードなら①、文書・会話の集約なら②、PDF/Web/音声の取り出しなら③、と当たりをつけてから上の表を引いてください。 導入ステップ——小さく試して計測する 新しい知識化OSSを本番に入れる前に、次の流れで小さく検証するのが安全です。 graph TD S1["① 課題を1つに絞る例：レビュー時間 / 文書検索 / PDF処理"] --> S2["② 入力で系統を選ぶコード=① 文書=② PDF/Web/音声=③"] S2 --> S3["③ 比較表から1本を選定ライセンスとセルフホスト可否を確認"] S3 --> S4["④ 小さなサンプルで試す実リポジトリ/実文書の一部だけ"] S4 --> S5["⑤ 効果を計測するトークン量 / 検索精度 / 所要時間"] S5 --> S6{"期待値を満たした？"} S6 -->|Yes| S7["本番導入・自動化へ"] S6 -->|No| S2 特にエージェントのトークン削減を狙う知識グラフ系は、効果がコードベースの構造に依存します。 GraphifyやCodeGraphの削減率は公式に報告されていますが、自分のリポジトリで「ツールコール数・トークン量・所要時間」を実測してから判断するのが堅実です。 3系統は単体で使うだけでなく、つなげると効果が大きくなります。たとえば社内ナレッジ検索を作るなら、次のような連携が現実的です。 ・③抽出・構造化：散らばったPDF・議事録をMinerUやMeetilyでMarkdown・構造データに変換する ・②ナレッジグラフ・知識ベース：それらをSurfSenseやcogneeに流し込み、横断検索できる知識ベースにする ・①コード→図解：関連する社内コードの全体像はoh-my-mermaidで図にし、ドキュメントと並べて参照する この「抽出→統合→俯瞰」の流れを一度パイプライ... --- # 最新の解説記事（直近50本、ピラーを除く） ## zvecとは｜Alibaba製インプロセスベクトルDBを実測。索引が作られない罠と日本語FTSの初期設定 - URL: https://ai-heartland.com/rag/zvec/ - 更新日: 2026-09-05 - カテゴリ: rag - 概要: zvec（alibaba/zvec・★15,769・Apache-2.0）はサーバーを立てずにアプリへ埋め込むインプロセスのベクトルデータベース。Python 3.14で実際に動かし、索引がoptimize()まで作られない挙動、日本語全文検索が既定設定で取りこぼす問題、プロセス間ロックの実際を実測した。 - タグ: rag, ベクトルデータベース, vector-database, ベクトル検索, 全文検索, Python, オープンソース ベクトル検索を1つ足すために、コンテナをもう1本立てる。RAGの構成図がだいたいそうなっているのは、ベクトルDBが「サーバーとして動くもの」だと決まっていたからだ。だが検索対象が手元の数万件で、しかもアプリと同じマシンに置くなら、その1本は本当に必要なのだろうか。 zvec（alibaba/zvec・★15,769・Apache-2.0・2026-09-04時点）は、この前提をSQLiteと同じやり方で崩しにいく。サーバーを立てず、アプリケーションのプロセスの中でベクトル検索を完結させる。Alibaba Group内部で使われてきた実装を切り出したもので、Python・Node.js・Go・Rust・Dartの公式SDKが揃っている。 この記事は機能紹介ではなく、2026-09-04にPython 3.14へ v0.7.0 を入れて実際に動かした結果を軸にする。結論を先に書くと、zvecは想像よりずっと軽く入るが、そのまま使うと索引が作られないまま動き、日本語の全文検索は黙って件数を減らす。どちらもエラーが出ないので、気づかないまま「こんなものか」と判断してしまう類の落とし穴だ。 計測環境は macOS 14.5 / Apple M2 MacBook Air 16GB / Python 3.14.4 / zvec 0.7.0（PyPI版）。 30秒でわかるzvec ・サーバー不要。pip install zvec だけで、依存は numpy 1つ・合計63MB ・スキーマにHNSWを書いても索引は作られない。optimize() を呼ぶまで全件走査のまま動く ・日本語の全文検索は既定のトークナイザだと取りこぼす。ngram の明示指定が要る ・読み取り専用なら複数プロセスで同時に開ける。ただし書き手が1つでもいると全員締め出される ベクトルDBをRAG全体のどこに置くかという地図はRAGとは？仕組み・構築・ベクトルDB選定までの2026年実装マップにまとめてある。この記事はその地図のうち「ストアをサーバーにしない」という選択肢を1つ深掘りするものだ。 zvecとは——サーバーを立てないベクトルデータベース zvecの位置づけは「軽いQdrant」ではない。アーキテクチャの階層が1つ違う。QdrantやMilvusはネットワーク越しに話しかけるサーバーで、pgvectorはPostgreSQLの拡張だから結局Postgresが要る。zvecはそのどちらでもなく、アプリのプロセスにimportされてそのまま動くライブラリだ。データはローカルのディレクトリに置かれる。 この違いは、運用の手間とレイテンシの両方に効く。ネットワークホップが無いので、クエリのコストにシリアライズとRTTが乗らない。一方で、サーバー型が当たり前に持っている機能——複数ノードへのシャーディング、ネットワーク越しの認証、複数アプリからの同時書き込み——は原理的に持てない。 flowchart LR subgraph SV["サーバー型（Qdrant / Milvus）"] direction LR A1["アプリ"] -->|"HTTP / gRPC"| A2["DBサーバー別プロセス"] --> A3[("ディスク")] end subgraph IP["インプロセス型（zvec）"] direction LR B1["アプリimport zvec"] -->|"関数呼び出し"| B2["zvec同一プロセス内"] --> B3[("ローカルのディレクトリ")] end 3つの型を並べると、選ぶ基準は「規模」ではなく「誰が書き込むか」に寄っていることがわかる。   zvec（インプロセス） Qdrant / Milvus（サーバー） pgvector（RDB拡張） 別プロセスの常駐 不要 必要 PostgreSQLが必要 追加の設置サイズ 63MB（実測・numpy込み） コンテナ数百MB〜 Postgres本体に依存 ネットワークホップ 無し 有り 有り 複数アプリからの書き込み できない（後述のロック） できる できる 水平スケール 不可 可 読み取りレプリカ等 向く規模 単一マシンに載る範囲 大規模・共有 既にPostgresがある構成 サーバー型を含めた選定そのものはベクトルデータベース比較2026｜Qdrant・Milvus・pgvectorをRAG用途で選ぶ完全ガイドで扱っている。ここでは「インプロセスを選んだ場合に何が起きるか」に絞る。 インデックスの選択肢は7種類あり、メモリに載せるHNSW系からディスクへ退避するDiskANN・Vamanaまで揃っている。量子化を組み合わせるRaBitQ版もあるので、メモリ制約が厳しいときの逃げ道はひととおり用意されている。同じ量子化の考え方をRust実装で追った記事としてturbovecとは｜Rust製ベクトル検索インデックスの量子化を実測して解説もある。 SDKは5言語。インデックスはメモリ常駐からディスク退避まで選べる。 インストールと最小構成——依存はnumpyだけ 実際に入れてみると、この手のライブラリとしては異例に軽い。 # Python 3.10〜3.14 が必要。仮想環境を作って入れる python3 -m venv .venv ./.venv/bin/pip install zvec # 入ったものを確認する ./.venv/bin/pip show zvec | grep -E "^(Version|Requires|License)" 実測結果は次のとおりだった。Requires: numpy の1行がすべてを物語っている。 項目 実測値 zvec本体（site-packages） 29MB（うちネイティブ拡張 _zvec...so が23MB） numpy 2.5.2 34MB 合計 63MB pipが解決した依存 numpy のみ PyPI上のwheel 30個・1個あたり10.6〜15.1MB 比較対象として、同じzvecファミリーの検索CLIであるzvec-grepとは｜ripgrep・BM25・ベクトル検索を1つにまとめるローカル検索CLIを実測はnode_modulesだけで568MBだった。あちらは埋め込みモデルの実行環境（onnxruntime等）を丸ごと同梱するので当然だが、「ベクトルストアそのもの」だけを取り出すとこの軽さになる、という対比は覚えておく価値がある。 索引が実際に食うディスク インプロセス型では、索引の実体がそのままアプリの配布物やユーザーのディスクに乗る。10,000件×768次元（生のベクトルだけで30.7MB）で作った索引ディレクトリを測ると、optimize() 後で 37.5MB だった。生データに対して約22%の上乗せで、HNSWがノード間のリンクを保持するぶんが乗っている。次元とM値を上げれば当然この比率は増える。 配布面は広く、公式に前ビルド済みバイナリが出ているのは Linux（glibc / musl の両方）・macOS・Windows・Android・iOS。v0.7.0でmusl libc（Alpine Linux）対応が加わり、コンテナイメージを小さく保ちたい構成でも入れられるようになった。同じv0.7.0でmacOS arm64向けの動的ライブラリが37MBから22MBへ約40%削られており、手元で実測した23MBのネイティブ拡張はこの削減後の姿にあたる。 バージョン表記に食い違いがある 細かいが、実際に踏むと厄介な点が2つあった。 1つは対応Pythonバージョンの表記ゆれだ。PyPIのメタデータは requires_python: >=3.9 と宣言しているのに、実際に配布されているwheelのタグは cp310〜cp314 しかない。つまりPython 3.9はpipの依存解決を通過してしまうが、対応するwheelが無いのでソースビルドへ落ち、C++のツールチェーンが無ければそこで失敗する。READMEの「requires 64-bit Python 3.10–3.14」のほうが正しく、パッケージのメタデータのほうが実態から外れている。 もう1つはSDK間のバージョン差だ。この記事の執筆時点で、PyPIのzvecは0.7.0だが、npmの@zvec/zvecは0.7.1（2026-09-04公開）が出ている。言語SDKは同時にリリースされるとは限らないので、複数言語から同じ索引を触る構成では版を揃える確認が要る。 最小のコードはREADMEのとおりで動く。ただし1点だけ、READMEのコメントは結果を {'id': ..., 'score': ...} の辞書だと書いているが、実際に返るのはDocオブジェクトで、d.id / d.score でアクセスする。 import zvec schema = zvec.CollectionSchema( name="my_collection", # 短すぎる名前は正規表現で弾かれる vectors=zvec.VectorSchema( "emb", zvec.DataType.VECTOR_FP32, 768, index_param=zvec.HnswIndexParam(metric_type=zvec.MetricType.IP), ), ) col = zvec.create_and_open(path="./mydb", schema=schema)... --- ## Teraxとは｜7MBのTauri製ターミナル一体型AI開発環境を実機とGitHub APIで検証する - URL: https://ai-heartland.com/tool/terax/ - 更新日: 2026-09-04 - カテゴリ: tool - 概要: Terax（crynta/terax-ai・★9,153・Apache-2.0）はTauri 2＋React 19で作られたターミナル起点のAI開発環境。7〜8MBという公称サイズ、無通信の主張、配布物とmainの97コミット差を実機とGitHub APIで確かめ、導入判断の材料を整理する。 - タグ: vibe-coding, terminal, tauri, rust AIコーディング環境はエディタ側から出発したものが多い。VS Codeのフォークにチャットパネルを足す、という形が主流だ。Terax（crynta/terax-ai・★9,153・Apache-2.0・2026-09-04時点）はそこを逆にして、ターミナルを中心に据え、その周りにエディタ・ファイルツリー・Git・Webプレビュー・AIサイドパネルを配置する。 そして「Lightweight (7MB)」を看板に掲げている。Electron製のAIエディタが数百MBある中で、Tauri 2 ＋ Rust ＋ React 19 という構成で2桁小さいと主張しているわけだ。 この記事では、その看板を含めた確かめられる主張だけを実機とGitHub APIで測った。公式dmgを落として展開し、署名と公証を確認し、実際に起動してプロセスとソケットを観測した。逆に「エディタの使い勝手」や「AIエージェントの賢さ」は主観になるので扱わない。 GitHub Releases の v0.8.6 に添付されたアセットの実サイズと、dmgをマウントして du で測った Terax.app の実サイズ。 30秒でわかるTerax ・Tauri 2 ＋ Rust ＋ React 19。macOS版のアプリ実体は9.0MiBで公称に近い ・ただしLinux版AppImageだけ94.5MB（他形式の約14倍） ・Developer ID署名＋Apple公証済み（spctl が accepted を返す） ・最新リリースは2026-07-27。mainはそこから97コミット先を走っている AIコーディング環境の選び方全体はVibe Codingとは？AIコーディングの始め方・ツール比較・実践ワークフロー2026にまとめている。 日本語で「Terax」を検索すると別のブランドが出てくる 日本語圏の「TERAX（テラックス）」は、鉱石粉末をプリントした体温ケア素材のアパレルブランドとしての知名度が先にある（QVCや楽天で「TERAX HOT」「ここちケア遠赤スパッツ」等が販売されている）。DataForSEO で terax の月間検索ボリュームを引くと日本で320件あるが、12か月の推移は 170〜320 でリポジトリが作られた2026年4月より前から非ゼロであり、この数字をそのままOSSの需要と読むことはできない。直近3か月が 480 / 880 / 480 と持ち上がっているのはOSS側の伸びを反映している可能性が高いものの、両者は混在している。この記事が扱うのは crynta/terax-ai のほうである。 Teraxとは：ターミナルを中心に据えたAI開発環境（ADE） READMEはTeraxを「terminal-first AI-native development environment (ADE)」と呼ぶ。構成要素は5つで、どれもターミナルタブと同じウィンドウに収まる。 領域 実装 主な機能 ターミナル xterm.js ＋ WebGLレンダラ、portable-pty によるネイティブPTY ブロック単位表示、水平・垂直分割、複数タブのバックグラウンドストリーミング、zsh/bash/pwsh/fish/cmd エディタ CodeMirror 6 TS/JS・Rust・Python・Go・C/C++・Java など、AI補完とhunk単位の差分適用、Vimモード、opt-inのLSP ソース管理 独自パネル hunk単位のstage/unstage、レーン描画のコミットグラフ、コミット検索 ファイル 独自エクスプローラ ファジー検索、インラインリネーム、ディスク変更のライブ反映、AIパネルへの添付 Webプレビュー ネイティブ子webview ローカル開発サーバーの自動検出、外部URLのプレビュー 言語構成はGitHub API上で TypeScript 78.8% / Rust 19.2% だった。「Tauri 2 ＋ Rust」を前面に出しているが、実装の重心はフロントエンド側にある——これは批判ではなく、Tauriアプリの一般的な姿である。Rust側の依存は src-tauri/Cargo.toml で28個と、Tauriアプリとしては素直な規模だ。 AI側はBYOK（自分のキーを持ち込む）方式で、OpenAI・Anthropic・Google・Groq・xAI・Cerebras・OpenRouter・DeepSeek・Mistral に加え、任意のOpenAI互換エンドポイントに向けられる。ローカル推論はLM Studio・MLX・Ollamaに対応する。エージェント側はプラン生成・サブエージェント・TERAX.md によるプロジェクトメモリ・承認ゲート付きのbash実行を持ち、さらにターミナル内にClaude Codeを起動して出力を読み、承認ゲート越しに追加指示を送るという「コーディングエージェントのオーケストレーション」まで載っている。 flowchart TB A["ターミナル（xterm.js＋WebGL）portable-pty でネイティブPTY"] --- B["コードエディタCodeMirror 6"] A --- C["ソース管理コミットグラフ"] A --- D["Webプレビュー子webview"] E["AIサイドパネルBYOK ＋ ローカル"] --> A E --> B F["TERAX.mdプロジェクトメモリ"] --> E E --> G["承認ゲート付き bash /Claude Code の起動と監視"] AI側はBYOK。ローカル推論にも向けられる AI機能はすべて「自分のキーを持ち込む」前提で、ツール自体には課金が無い。READMEが挙げる接続先を整理すると次のようになる。 種別 接続先 クラウド（BYOK） OpenAI / Anthropic / Google（Gemini）/ Groq / xAI（Grok）/ Cerebras / OpenRouter / DeepSeek / Mistral 任意のエンドポイント OpenAI互換のAPIならすべて ローカル・オフライン LM Studio / MLX / Ollama エージェント側の機能は、プラン生成・サブエージェント・TERAX.md によるプロジェクトメモリ・ファイルの read / write / edit / multi-edit / grep / glob・承認ゲート付きのbash実行・バックグラウンドプロセス、と一通り揃っている。さらに「coding-agent orchestration」として、ターミナル内に Claude Code を起動して出力を読み、承認ゲート越しに追加の作業を投げるという機能が挙がっている。エディタ側にAIを埋め込むのではなく、ターミナルで動く既存のエージェントを外から操るという発想で、terminal-first を名乗るだけの一貫性はある。 Composer（プロンプト入力欄）は #handle でプロンプトスニペット、@path でファイルを差し込め、音声入力とエクスプローラからの添付にも対応する。テーマ関連では Kanagawa・Catppuccin・Rosé Pine・Everforest・Dracula・Solarized・Nord・Tokyo Night・GitHub・Xcode がエディタテーマとして同梱され、アプリのテーマとエディタのテーマは独立して設定できる。背景画像に不透明度とぼかしを掛ける設定まである。 ここから先は本記事の検証範囲外 上のAI機能・テーマ機能はREADMEの記載であって、動作を確認したものではない。加えて前述のとおり、ダウンロードできるのは v0.8.6（2026-07-27）のビルドで、READMEが説明しているのは97コミット先の main である。この一覧のどこまでが v0.8.6 に入っているかは、リリースノートからは判別できなかった。 「7〜8MB」はどこまで本当か 看板の数字を配布形式ごとに実測した。 配布形式 実測サイズ 公称「7-8 MB」との関係 Terax_0.8.6_x64-setup.exe（Windows） 4,335,936 B（4.3 MB） 下回る Terax_0.8.6_x64_en-US.msi（Windows） 5,419,008 B（5.4 MB） 下回る Terax_0.8.6_amd64.deb（Linux） 5,979,782 B（6.0 MB） 下回る Terax_0.8.6_aarch64.dmg（macOS） 6,739,016 B（6.7 MB） 範囲内 Terax_0.8.6_x64.dmg（macOS） 7,091,052 B（7.1 MB） 範囲内 展開後の Terax.app 9.0 MiB（本体バイナリ 8,488,912 B） やや上回る Terax_0.8.6_amd64.AppImage（Linux） 94,472,696 B（94.5 MB） 約14倍 ダウンロードサイズで見れば公称はおおむね正しく、AppImageだけが例外だ。AppImageはGTK/WebKitのランタイムを同梱するため必然的にこうなる。READMEのLinux注記も「.deb / .rpm はシステムのGTKスタックにリンクするので滑らかな傾向」と書いており、AppImageを第一候補にしていない... --- ## TurboFieldfareとは｜26BのGemma 4を約2GBのRAMで動かすSwift製ランタイムの実像 - URL: https://ai-heartland.com/llm/turbo-fieldfare/ - 更新日: 2026-09-04 - カテゴリ: llm - 概要: TurboFieldfare（★6,602・Apache-2.0）は26BのGemma 4を約2GBのRAMで動かすSwift＋Metal製ランタイム。「8GBのMacでも動く」の手前にあるmacOS 26・配布バイナリ0件という条件と、公式・コミュニティ実測が示す8GBと16GBの2.3倍差を整理する。 - タグ: LLM, gemma, apple-silicon, moe, swift MoE（Mixture of Experts）モデルの重みは、そのほとんどが常には使われない。Gemma 4 26B-A4B は各層に128個のエキスパートを持ち、ルーターが1トークンあたり8個だけを選ぶ。ならば全部をメモリに載せる必要はないはずだ——TurboFieldfare（drumih/turbo-fieldfare・★6,602・Apache-2.0・2026-09-04時点）は、その発想をApple Silicon向けにSwiftとMetalで実装したランタイムである。 公称は「26BのGemma 4を約2GBのRAMで動かす」。14.3GBあるモデルのうち、共有コア1.35GBとFP16のKVキャッシュだけをメモリに置き、各トークンで必要になったエキスパートだけをSSDから読む。 この記事はこの主張を検証しようとして、実行にすら到達できなかった記録である。手元の環境（M2 MacBook Air 16GB / macOS 14.5）では swift build がバージョン不一致で止まった。そこで論点を切り替え、「8GBのMacでも動く」という見出しの手前に実際は何のゲートがあるのかと、公式・コミュニティが公開している実測値から何が読み取れるのかを整理する。 左列は Package.swift の platforms と README の Requirements、GitHub Releases の実測（16本すべて添付アセット0件）から起こしたもの。 30秒でわかるTurboFieldfare ・26B（アクティブ約3.88B）のGemma 4を、共有コア＋KVキャッシュだけメモリに置く設計 ・MLXやllama.cppのラッパーではなく、このモデル専用のSwift＋Metal実装 ・実際のゲートはRAMではなくmacOS 26 / Metal 4 / Xcode 26 / Swift 6.2 ・配布バイナリは1つも無い（16リリース・添付0件）。全員がソースからビルドする Apple Silicon でのローカル推論全般の位置づけはLLMとは？仕組み・主要モデル比較・ローカル実行・量子化を一気にまとめる2026年版にまとめている。 TurboFieldfareとは：エキスパートをSSDに置いたままMoEを走らせる 設計の核は docs/SYSTEM_DESIGN.md に書かれている。Gemma 4 の構造のうち、実装を規定しているのは次の4点だ。 Gemma 4 の性質 ランタイム側の帰結 30層（スライディングウィンドウ注意25層＋全注意5層） KVキャッシュを2種類のレイアウトで持つ 各層に128エキスパート、ルーターは1トークンにつき8個を選択 選ばれた8個ぶんだけをSSDから読む 密な共有エキスパートが別ブランチで常に走る 共有側（1.35GB）は常駐させる 埋め込みと言語モデルヘッドが量子化重みを共有 常駐コアをさらに削れる 量子化は MLX の affine 4bit（グループ64・BF16のスケールとバイアス）で、ルーター射影だけ8bit、共有・ルーテッド両方のエキスパートが4bit という配分になっている。ルーターの精度を落とすと選ぶエキスパートを間違えるので、そこだけ精度を残すという判断だ。 スライディングウィンドウの25層は直近1,024トークンだけを見て、K/Vを1,152行のリングに保持する（余分な128行はチャンク化プリフィルの書き込み用）。全注意の5層は追記のみで全文脈を持つ。この非対称なKV設計が「2GB」を成立させている実質的な部分で、単に量子化を強めただけの数字ではない。 flowchart LR A["共有コア 1.35GB＋ FP16 KVキャッシュ"] -->|常駐| B["メモリ 約2GB"] C["ルーテッドエキスパート128個 × 30層"] -->|層ごとのファイル| D["SSD 約14.3GB"] E["ルーター 8bit"] -->|1トークンにつき8個を選ぶ| D D -->|選ばれた分だけ読む| B B --> F["Metal 4 カーネルでprefill / decode"] .gturbo という独自のモデルディレクトリ形式を持ち、インストーラ（TurboFieldfareRepack）が Hugging Face の固定リビジョンから必要なバイト範囲だけをレンジリクエストで取得して、届いた端から再パックする。チェックポイント全体を一度ディスクに置かないので、14.3GBの設置に対して余分な14.3GBが要らない。8GB機を想定したときにディスクも効いてくる、という前提が設計に効いている。 turbo-fieldfareを動かす前にある3つのゲート（RAMではない） ここが本記事の主眼だ。READMEの見出しは「Gemma 4 26B-A4B inference in about 2 GB of RAM / A custom Swift + Metal runtime for any Apple Silicon Mac, even the 8 GB ones」で、制約としてRAMだけが前に出ている。実際の Requirements 節と Package.swift を読むと条件はもっと厳しい。 // Package.swift（tag 0.7.1）冒頭 // swift-tools-version: 6.2 let package = Package( name: "TurboFieldfare", platforms: [ .macOS(.v26), .iOS(.v26), ], 手元の M2 MacBook Air（macOS 14.5 / Swift 5.10 / Xcode 未導入・Command Line Tools のみ）で実行した結果はこうなった。 git clone --depth 1 --branch 0.7.1 https://github.com/drumih/turbo-fieldfare.git cd turbo-fieldfare swift build -c release # → error: 'tf': package 'tf' is using Swift tools version 6.2.0 # but the installed version is 5.10.0 いずれも2026-09-04に実行して確認した値。swift build はソースを1行もコンパイルする前に、マニフェストのバージョン不一致で停止する。 つまりRAM 8GBのMacを持っていることは条件の一部でしかなく、そのMacが macOS 26 に上がっていて、かつ Xcode 26 が入っていることが実質的な前提になる。8GBのMacBook Airを使い続けている層と、最新のmacOSに上げてXcodeを入れている層は、必ずしも重ならない。 配布バイナリが1つも無い これを避けようがない事実にしているのが、リリース資産の状況だ。 gh api repos/drumih/turbo-fieldfare/releases --paginate \ --jq '[.[]|{tag:.tag_name, n:(.assets|length)}]' # → releases: 16 | total assets: 0 v0.1（2026-07-20）から 0.7.1（2026-08-28）まで16本のリリースがあり、添付アセットは合計0件だった。DMGもpkgもなく、Homebrewのformulaも見当たらない。README の Quick start が git clone → swift build -c release から始まっているのは省略ではなく、それが唯一の入手経路だからである。 この記事が測れなかったこと 上記のとおりビルドに到達しなかったため、デコード速度・メモリ使用量・出力品質はいずれも自分では測っていない。以下で扱う数値はすべて公式リポジトリまたはコミュニティ提出値であり、この記事の実測ではない。約15GBのモデルダウンロードも、実行できない以上は行っていない。 公式ベンチマークの読み方：tok/s より TTFT を見る docs/BENCHMARKS.md にある8GB M2 MacBook Air（Mac14,15）の実測は次のとおり。 プロンプト / 生成トークン Prefill TTFT Decode ピークRSS / フットプリント 6 / 32 7,025 ms 7,979 ms 6.30 tok/s 1,304 / 1,791 MiB 121 / 64 7,934 ms 8,862 ms 5.10 tok/s 1,528 / 1,776 MiB 527 / 64 21,736 ms 22,649 ms 5.90 tok/s 1,535 / 1,886 MiB 1,017 / 128 36,729 ms 37,656 ms 5.38 tok/s 1,455 / 1,971 MiB メモリの主張は数字で裏付けられている。ピークRSSは1,304〜1,535 MiB、フットプリントでも1,776〜1,971 MiBで、「約2GB」は誇張ではない。26Bのモデルをこの常駐量で回している事実は素直に評価してよい。 一方で同じ表に、見出しに出てこない数字が並んでいる。TTFT（最初のトークンが出るま... --- ## pgbookとは｜Postgresのロック・VACUUM・JSONBをターミナルで読むGo製CLIを実測 - URL: https://ai-heartland.com/tool/pgbook/ - 更新日: 2026-09-04 - カテゴリ: tool - 概要: pgbook（★56・MIT・Go）はPostgresの学習トピックを1本ずつターミナルで読むCLI。公開2日目のv0.1.0を実際に動かし、読める8トピック・目次22項目のギャップ、オフライン挙動、未実装のpdfコマンドまでを実測で確かめた。 - タグ: automation, postgres, cli, go Postgresの公式ドキュメントは網羅的だが、実務で詰まる論点にたどり着くまでが遠い。「クエリが遅いのではなく止まっている」ときに読みたいのはロックの章だけで、そこに行くまでに目次を何度も往復することになる。 pgbook（pgrundev/pgbook・★56・MIT・Go製・2026-09-04時点）は、その論点だけを1ページに切り出してターミナルから1本ずつ読ませるCLIだ。pgbook read locks と打つと、ロックの話だけが端末に出る。リポジトリが作られたのは2026-09-02、v0.1.0のリリースはその翌日で、これを書いている時点で公開から2日しか経っていない。 この記事は紹介ではなく実際に v0.1.0 のバイナリを落として動かした記録である。★56という規模のとおり、できることは多くない。だからこそ「READMEに書いてあることのうち、いま本当に動くのはどこまでか」を確かめる価値がある。 READMEの目次行数と pgbook list の実出力を突き合わせた。書き上がっているのは Intermediate に偏っており、初学者向けの章はまだほとんど埋まっていない。 30秒でわかるpgbook ・単一のGoバイナリ（macOS arm64 で 5.1MB）。Node も Postgres も要らない ・本文は pgbook.dev から取得。CLIはDBに接続もSQL実行もしない ・読めるのは8トピック。READMEの目次は22項目で、14項目は「in progress」 ・READMEにある pgbook pdf はまだ動かない（叩き先の /api/book が404） 学習コンテンツをCLIに載せる発想そのものは新しくない。むしろpgbookは「AIに要約させる」潮流とは逆を向いていて、人間が読む短い章をそのまま配る側に立っている。開発まわりの作業をどこまで道具に任せるかという全体の見取り図はAI自動化ツール｜ノーコードからコードまで2026年版の比較と選び方にまとめている。 pgbookとは：Postgresの論点を1本ずつ配るGo製CLI 配布はGitHub Releasesのバイナリ、Homebrew、go install、インストールスクリプトの4通りある。バイナリを直接取るのがいちばん素性がはっきりしている。 # 公式リリースのバイナリを取る（macOS Apple Silicon） curl -sfL -o pgbook.tar.gz \ https://github.com/pgrundev/pgbook/releases/download/v0.1.0/pgbook_0.1.0_darwin_arm64.tar.gz tar xzf pgbook.tar.gz ./pgbook --version # → pgbook 0.1.0 Homebrew（brew install pgrundev/tap/pgbook）と go install github.com/pgrundev/pgbook@latest も用意されている。READMEの先頭は curl -fsSL https://pgbook.dev/install.sh | sh を勧めているが、スクリプトを読まずにシェルへ流し込む形なので、リリース資産を直接取るか go install を使うほうが素直だ。リリースには checksums.txt も付いている。 配布サイズは4プラットフォームで2.0〜2.3MBの範囲、展開後のバイナリは実測 5,080,290バイト（4.8MiB） だった。 配布経路は4つ。サイズは実測2.0〜2.3MB 経路 コマンド 実測サイズ 備考 GitHub Releases curl でtar.gzを取得 2.13 MB（darwin/arm64） checksums.txt 付き。展開後のバイナリは4.8MiB Homebrew brew install pgrundev/tap/pgbook — 独自tap Go go install github.com/pgrundev/pgbook@latest — 手元のGoでビルド インストールスクリプト curl -fsSL https://pgbook.dev/install.sh \| sh — READMEの推奨だが中身を読まずに実行することになる リリース資産は macOS（amd64 / arm64）と Linux（amd64 / arm64）の4種で、いずれも 2,057,864〜2,274,272 バイトの範囲に収まっている。Windows 向けのバイナリは v0.1.0 時点では配布されていない。 pgbook list が返すのは8本 ./pgbook list 実際の出力は次のとおり。 POSTGRES BOOK 01 Indexes beginner 02 Transactions & isolation intermediate 03 JSON & JSONB intermediate 04 Window functions intermediate 05 Row-level security intermediate 06 Vacuum & autovacuum intermediate 07 Locks intermediate 08 Replication advanced Read a topic: pgbook read locks READMEの目次は22項目あるが、pgbook list が返すのは8本だ。READMEは各行に「✅ pgbook read <slug>」か「in progress」を付けており、書き上がっていない14項目はMVCC・クエリプランナ・デッドロック・WALとチェックポイント・パーティショニング・接続プーリングなど、いずれも実務で効く論点が並んでいる。 READMEの番号（Locksは07、Indexesは04）とpgbook listの番号（Locksは07、Indexesは01）が一致しない点にも注意がいる。CLI側は書き上がった8本だけを1から振り直すので、READMEの番号を覚えて打っても意味がない。指定はスラッグ（locks / jsonb など）で行う。 8トピックの中身を APIの実データで確認する GET /api/topics が返す内容をそのまま表にした（2026-09-04 実測・version: "0.1"）。 # スラッグ タイトル レベル 想定読了 別名（alias） タグ 1 indexes Indexes beginner 8分 index / index-basics / btree performance, btree, explain 2 transactions Transactions & isolation intermediate 10分 isolation / transaction concurrency, mvcc, isolation 3 jsonb JSON & JSONB intermediate 9分 json / json-jsonb jsonb, gin, schema-design 4 window-functions Window functions intermediate 9分 windows / over / partition-by sql, analytics, aggregates 5 row-level-security Row-level security intermediate 10分 rls / row-security / policies security, multi-tenant, policies 6 vacuum Vacuum & autovacuum intermediate 10分 autovacuum / bloat mvcc, maintenance, bloat 7 locks Locks intermediate 10分 locking / lock / blocking concurrency, transactions, blocking 8 replication Replication advanced 11分 replicas / failover / standby wal, high-availability, streaming 合計77分。つまり現時点の「Postgres Book」は、通しで読んでも1時間20分足らずで読み切れる分量である。22項目すべてが埋まれば単純計算で3時間半前後になる計算だ。 内容の重心は明確で、8本中5本がMVCCまわり（transactions / vacuum / locks）と、それを前提にした運用の話に寄っている。タグの分布を見ても concurrency mvcc blocking bloat が繰り返し出てくる。「Postgresの入門書」ではなく「Postgresで実際に事故る場所の解説」という編集方針が、目次より先にこのメタデータから読み取れる。 aliases が効くので、pgbook read rls でも pgbook read row-security でも同じ章に着く。用語のゆれで空振りしないための配慮で、公式ドキュメントを引くときにいちばん困るところ... --- ## zvec-grepとは｜ripgrep・BM25・ベクトル検索を1つにまとめるローカル検索CLIを実測 - URL: https://ai-heartland.com/tool/zvec-grep/ - 更新日: 2026-09-04 - カテゴリ: tool - 概要: zvec-grep（zg・★1,751・Apache-2.0）はripgrep・BM25・ベクトル検索を1つのCLIに束ねるローカル検索ツール。日本語Markdown120本を実際に索引して所要20分50秒・クエリ13.2秒・MCP常駐2,416トークンを実測し、向く用途と向かない用途を切り分ける。 - タグ: rag, cli, search, MCP grep で当たるのは、探している語をすでに知っているときだけだ。「認証まわりの検証をしている場所」「あの時ベンチマークの数字を書いた記事」のように、語ではなく意味しか手元にないとき、正規表現は空振りする。かといって全文をLLMに読ませればトークンが飛ぶ。 zvec-grep（コマンド名 zg・★1,751・Apache-2.0・2026-09-04時点）は、この隙間を1つの索引で埋めにいくツールだ。ripgrep（正規表現）・BM25（語の重み付き全文検索）・ベクトル検索（意味）を同じワークスペース索引の上に載せ、人間はCLIから、AIエージェントはMCPツールから、同じ索引を引く。Alibaba の zvec をベクトルストアに使っている。 この記事は公称値の紹介ではなく、2026-09-04に v0.2.1 を実際にインストールし、日本語のMarkdown 120本を索引して測った結果を軸にしている。結論から言うと、この道具の評価は「検索が速いかどうか」ではなく「その20分の索引作成に見合う探索をするかどうか」で決まる。検索自体は1秒前後で返る。 計測環境は macOS 14.5 / M2 MacBook Air 16GB / Node v22.13.1。コーパスは日本語技術記事のMarkdown 120本（合計4.0MB）。 30秒でわかるzvec-grep ・zg index で作った1つの索引を、正規表現・BM25・ベクトルの3経路から引く ・埋め込みは既定でローカル実行。リモート埋め込みは明示的に許可したときだけ使われる ・MCPサーバーとして立てると、既定ではツール1個・2,416トークンしか常駐しない ・代償は設置サイズ568MBと索引作成の遅さ。日本語93本で20分50秒。検索自体は1秒前後 検索そのものをAIの文脈供給に使う設計の全体像はRAGとは？仕組み・構築・ベクトルDB選定までの2026年実装マップにまとめている。 zvec-grepとは：3種類の検索を1つの索引に束ねるCLI zg は「探し方を選ばせない」ことを設計の中心に置いている。同じクエリを投げると、内部で複数の経路に分岐して結果を統合する。実際に実行すると、応答の先頭にどの経路を使ったかが出る。 # インストール（Node.js 22 以上が必要） npm install -g @zvec/zvec-grep # ワークスペースを索引する（ローカル埋め込みモデルを指定） zg index --embedding local/potion-retrieval-32m # 意味で引く zg query --human "ヘッドレスブラウザでスクレイピングを高速化する方法" --limit 3 手元での実際の出力は次のようになった（抜粋）。 Routes: fts:ヘッドレスブラウザでスクレイピングを高速化する方法, vector:ヘッドレスブラウザで… Coverage: ranked_sample Files: 3 Hits: 3 #1 heading ヘッドレスモード（無頭模式）が主線 matchedBy=fts+vector score=0.0301 Heading level: 3 Scope: 導入時の注意点と現在の開発ステータス 注目すべきは matchedBy=fts+vector の表示だ。全文検索とベクトル検索の両方に当たったことが結果ごとに明示されるため、「意味で拾えたのか、語がたまたま一致しただけなのか」を利用者側で判別できる。ランキングをブラックボックスにしない点は、検索結果をそのままエージェントに渡す用途では地味に効く。 返ってくるのはファイル全体ではなく、見出し・行範囲・その見出しが属する上位セクション（Scope）の単位だ。上の例では 464〜467 行という4行だけが返っている。LLMに渡す文脈量を抑えるための設計がここに出ている。 索引は何を持っているか 索引の状態は zg status で見える。実測では次の通りだった。 ✓ Workspace index is ready Coverage ████████████████████ 100% 120 / 120 files Entities 2,579 Embedding local/potion-retrieval-32m 512 dimensions · cosine Storage .zvec-grep/index.zvec 120ファイルから 2,579エンティティが切り出され、512次元のベクトルとしてコサイン類似度で引かれる。索引の実体は対象ディレクトリ直下の .zvec-grep/index.zvec に置かれるので、リポジトリごとに独立し、.gitignore で外せば共有もされない。 インストールの実コスト：npmの2.16MBに対し、展開後は568MB READMEは軽さを売りにしていないが、「ローカルファースト」という言葉から受ける印象と実際の設置サイズには開きがある。実測すると次のようになった。 npm view @zvec/zvec-grep dist.unpackedSize は 2,155,651 バイト。実際に npm i した node_modules は du -sh で 568MB だった。 項目 値 確認方法 npm 配布物（unpackedSize） 2.16 MB npm view @zvec/zvec-grep dist.unpackedSize 依存解決後の node_modules 568 MB du -sh node_modules うち onnxruntime-node 213 MB du -sh node_modules/* うち onnxruntime-web 102 MB 同上 うち tree-sitter-wasms 55 MB 同上 うち @huggingface 54 MB 同上 うち node-llama-cpp 34 MB 同上 この555MBは「無駄」ではなく、ローカルファーストという設計の請求書だ。埋め込みをクラウドAPIに投げる設計なら ONNX Runtime も llama.cpp も要らない。だがそれをやめて手元で完結させると決めた以上、推論ランタイムと構文解析器を丸ごと抱えることになる。「ローカルで動く」と「軽い」は同時に成立しないという、この種のツールに共通する取引がそのまま出ている。 Node.js のバージョン要件は package.json の engines に {"node": ">=22"} として宣言されている。ただし npm は既定で engines を助言としてしか扱わない（engine-strict が有効なときだけインストールを止める）ため、古いNodeでも入ってしまい実行時に落ちる可能性がある点は注意しておきたい。手元の Node v22.13.1 では問題なく動作した。 索引作成の実測：日本語Markdown 120本で20分50秒 ここが導入判断の分かれ目になる。日本語の技術記事Markdown 120本（合計4.0MB）を zg index --embedding local/potion-retrieval-32m で索引した結果は次の通りだった。 Workspace index files 120 scanned, 93 added, 0 modified, 1 retried, 26 unchanged, 0 deleted, 0 failed entities 1939 duration 20m 50s (1249677ms) 1ファイルあたり約13.4秒。ファイルサイズが平均33KBのMarkdownであることを考えると、体感としてはかなり遅い。ピークRSSは213MB、ピークメモリフットプリントは678MBだった。 この20分50秒に含まれないもの・含まれるもの モデルのダウンロードは含まれない（先行する実行で取得済み）。一方、この回は途中で中断した前回実行の分 26ファイルが unchanged として再利用されているため、20分50秒は120本ぶんではなく93本ぶんの実測である。120本をゼロから索引すれば、単純計算でさらに数分伸びる。 差分更新は効く。同じディレクトリで再実行すると変更のないファイルは unchanged として飛ばされるので、初回だけが重く、以後は触ったファイルぶんで済む。CIで毎回まっさらな環境から索引を作る使い方には向かない。 検索の実測：測り直したら1秒台だった（そして最初の測定は間違っていた） ここは一度誤った数字を出しかけたので、経緯ごと書く。索引作成の直後に測ったクエリ所要時間は次のようになっていた。 実行モード 1回目 2回目 3回目 直接モード（索引直後） 33.3秒（モデル読込を含む初回） 21.6秒 25.6秒 サーバーモード（索引直後） 33.3秒（デーモン暖機） 13.2秒 13.4秒 この時点では「1クエリ13秒。サーバーモードで半分になる」と書けそうに見える。ところが同じマシン・同じ索引・同じクエリで、しばらく置いてから測り直すと結果が変わった。 実行モード 1回目 2回目 3回目 直接モード（落ち着いた後） 1.25秒 1.42秒 1.36秒 サーバーモード（落ち着いた後） 1.37秒 1.06秒 1.02秒 直接モード（別クエリで再確認） 1.21秒 1.07秒 0.95秒 # 実際に... --- ## slotstream実測｜104GBのMoEを48GB Macで動かすSSDストリーミングの仕組みと限界 - URL: https://ai-heartland.com/llm/slotstream/ - 更新日: 2026-09-03 - カテゴリ: llm - 概要: slotstream（★246・MIT）は104GBのQwen3.8-Flash-Next MoEをSSDから流し、48GB Macで約12 tok/sを出すと公称するSwift製エンジン。16GB MacBook Airで実測し、SSDが開発機の8〜10分の1と判明。何が検証できて何が未検証かを線引きする。 - タグ: llm, ローカルLLM, MoE, slotstream, Apple Silicon, MLX, Swift, 推論最適化, 巨大モデル, SSD Appleシリコンの統合メモリは速いが、量は買った時点で決まる。16GBのMacBook Airに後からメモリを挿すことはできない。そこで「重みの大半をSSDに置いたまま、必要な分だけ流し込む」という発想が出てくる。slotstream（carloslfu/slotstream・★246・MIT）は、125BのMoEモデルであるQwen3.8-Flash-Next（4bitで約104GB）をSSDからストリーミングし、48GBのMacで約12 tok/sを出すと公称するSwift製の推論エンジンだ。Show HNでは225ポイント・106コメントを集めた（2026-09-03時点で226ポイント）。 16GB MacBook Air（M2）で実際に実行した様子。doctor は8.1GBの下限プランを出し、pull は「107.3GB必要・50.9GB空き」で拒否した（録画時は8GBのベンチ用ファイルが残っていたため空き容量が少なめに出ている）。筆者環境で撮影。 30秒でわかる ・やっていること：104GBのうち常駐は3.8GBだけ。68GBのエキスパートと32GBのn-gramテーブルをSSDから随時読む ・検証できたこと：バイナリの真正性（SLSA来歴）、16GB実機でのプラン、ディスク不足時の拒否、そしてSSD速度が開発機の8〜10分の1であること ・検証できなかったこと：12 tok/sという速度そのもの。重みに107.3GBの空きが要り、手元は約56GBだった ・新しさ：ストリーミング手法は新しくない（同種OSSが7本実在）。差別化点は公称値の全てに測定記録を紐づけCIで縛る運用のほう この記事はLLMとは？仕組み・主要モデル比較・ローカル実行・量子化を一気にまとめる2026年版の系列にある個別ツール解説として、公式の一次情報と、16GB MacBook Airでの実測を突き合わせている。 slotstreamとは——104GBのモデルを「載せずに」動かす設計 slotstreamが対象にするQwen3.8-Flash-Nextは、125BパラメータのMixture-of-Experts（MoE）モデルだ。MoEの特徴は、パラメータの総量が巨大でも、1トークンの生成に使うのはそのごく一部だという点にある。slotstreamはここに賭けている。 公式のMEASUREMENTS.mdは、モデルの内訳をsafetensorsのヘッダからバイト単位で読み出して公開している。HTTPのrangeリクエストで11個のシャードのヘッダ（3,215テンソル）だけを取得しており、全体をダウンロードせずに数えた値だ。 構成要素 実測サイズ 割合 常駐するか ルーテッドエキスパート 67.948 GB 65.5% ❌ SSDから随時読む n-gram / PLEストア 32.000 GB 30.8% ❌ SSDから随時読む その他（norm・lm_head等） 1.255 GB 1.2% ✅ 常駐 Gated DeltaNet 1.189 GB 1.1% ✅ 常駐 QSAアテンション 0.376 GB 0.4% ✅ 常駐 ハイパーコネクション 0.367 GB 0.4% ✅ 常駐 embed_tokens 0.358 GB 0.3% ✅ 常駐 共有エキスパート 0.133 GB 0.1% ✅ 常駐 ルーター 0.126 GB 0.1% ✅ 常駐 合計 103.770 GB   常駐は3.822 GB 公式 MEASUREMENTS.md M0.2（safetensorsヘッダのバイト実測）から作成。常駐は3.82GBだけで、残り約100GBがストリーミングの対象になる。 要点は最終行だ。常に載せておく必要があるのは3.822GBしかない。残りの約100GBは「その瞬間に使う分だけ」読めばよく、そこがストリーミングの余地になる。エキスパートは48層×512個で、1トークンが起動するのは各層10個だけだ。 「104GB」「105.3GB」「103.770GB」の食い違い 数字が3つ出てくるので先に整理しておく。これは矛盾ではなく、測っている対象が違う。 ・103.770 GB：safetensorsのインデックスが持つ total_size。モデル本体のバイト数で、最も厳密な値 ・105.3 GB：pull がダウンロードする25ファイルの合計。1.5GBのドラフトヘッド（投機的デコード用）などを含む配布物としての大きさ ・104 GB：Show HNのタイトルで作者が使った丸め値 記事タイトルや見出しで見かけるのはたいてい3つ目だ。実際にディスクを何GB空ければいいかを知りたいなら、見るべきは2つ目の105.3GB——さらに pull は2GBのマージンを足して107.3GBを要求する。 仕組み——なぜ単純なmmapではだめなのか 「ファイルをmmapして、OSのページングに任せればいいのでは」と考えるのが自然だ。llama.cppは実際にmmapを使う。だが公式READMEはこれを明確に否定している。 公式の説明（筆者は未検証） MLXはメモリマップしたテンソルの一部だけを実体化できない。ある層のtop-10エキスパートを取り出すgather操作が、その層の512エキスパート全部を評価してしまう。結果、mmap経路は約100GBを読み込んで破綻する。標準の mlx_lm.load() を使った経路は、48GBの開発機を1トークンも出さないまま48GBのスワップに叩き込んだ——これがslotstreamが存在する理由だと作者は書いている。 この主張は重みが無いと再現できないため、筆者は検証していない。公式の説明として扱ってほしい。 slotstreamの答えは、OSのページングに任せず自前で管理することだ。エキスパートを固定サイズの「スロット」プールに pread で読み込む。プールは48層で共有されるので、よく使われる層が使われない層のスロットを借りられる。 flowchart TD A["トークン入力"] --> B["常駐トランク 3.8GB（ルーター・アテンション・norm）"] B --> C{"ルーターが選ぶ各層 top-10 / 512"} C -->|"ヒット"| D["スロットプール（メモリ内キャッシュ）"] C -->|"ミス"| E["SSDから pread1件 2.7648 MB"] E --> D D --> F["gather_qmm4bit量子化行列積"] F --> G["次トークン"] G --> A このとき重要なのは、キャッシュの大きさは速度を変えるが出力は変えないという性質だ。公式は「4GBキャッシュと24GBキャッシュでgreedyデコードの出力はバイト単位で一致する」ことを常設テストにしていると書いている。メモリが足りない機械では遅くなるだけで、答えが劣化するわけではない——ローカル実行の判断材料としてはありがたい設計だ。 なお、エキスパート1件のレコードは2,764,800バイトで、16KiBページに合わせて2,768,896バイト（169ページ）にパディングされている。この「約2.76MB」という単位が、後で見るSSDベンチマークの主役になる。 【実測】16GB MacBook Airでどこまで動いたか ここからは筆者の実機での検証だ。環境は以下のとおりで、公称値の前提（48GB M5 Pro）とはかなり違う。 項目 筆者の環境 公式の開発機 機種 MacBook Air（Mac14,2） MacBook Pro チップ Apple M2（4P+4E） Apple M5 Pro（18コア） 統合メモリ 16 GB 48 GB SSD APPLE SSD AP0256Z（251 GB） APPLE SSD AP2048Z（2 TB） macOS 14.5（23F79） 26（Darwin 25.6.0） Swift 5.10（Command Line Tools） 6.3.3 ソースからのビルドは失敗した（ツールチェーンの下限が未記載） 本記事の検証対象は v0.2.2（2026-09-02公開）である。執筆中の2026-09-03に v0.2.3 が出たが、以下の測定はすべて v0.2.2 に対するものだ。 READMEは「Command Line Toolsだけで足りる、Xcodeは要らない」と書いている。しかし手元では通らなかった。 error: 'slotstream': package 'slotstream' is using Swift tools version 6.0.0 but the installed version is 5.10.0 Package.swift は swift-tools-version: 6.0 を宣言しており、Swift 6を含むCommand Line Tools（16以降）が要る。READMEが間違っているのではなく、CLTのバージョン下限が書かれていないというのが正確な言い方だ。Xcodeが不要なのは事実で、必要なのは十分新しいCLTである。 配布バイナリは真正性を検証できた ビルドが通らないので、v0.2.2のリリース資産を使った。READMEは curl | sh のワンライナーを案内しているが、ここでは資産を直接取得して検証した。 gh release download v0.2.2 --repo ca... --- ## vgpuとは｜Vercel Labs製WebGPUライブラリを実際に入れて3経路の実行を試した - URL: https://ai-heartland.com/tool/vgpu/ - 更新日: 2026-09-02 - カテゴリ: tool - 概要: vgpu（vercel-labs/vgpu・GitHub 1,372スター・MIT）はWebGPUをブラウザ・Node・モックの3経路で同じAPIから扱うライブラリ。v0.3.1をnpmから入れて実行し、モックが返すのはピクセルではなくAPI呼び出し記録であること、Dawn経路が動く環境の条件までを実測しました。 - タグ: design, WebGPU, TypeScript, フロントエンド, シェーダー vgpu（vercel-labs/vgpu・GitHubスター1,372・MIT）は、WebGPUを扱うためのモジュール式ライブラリです。シェーダー、3Dシーン、GPUテンソル、ニューラルネットワーク、数式の可視化——と守備範囲は広く、Vercel Labsが開発しています。 この手のライブラリで気になるのは「謳っているとおりに動くのか」です。とくにvgpuは「同じコードがブラウザでもNodeでもモックでも動く」というcross-runtimeを売りにしています。そこでnpmから実際に入れて、3つの経路すべてを走らせました。結論から言うと、APIの形は本当に共通で、一方でモックとNodeにはそれぞれ知っておくべき性質がありました。 v0.3.1 をnpmから導入し、既定・Node・モックの3経路を実際に実行した結果 30秒でわかる vgpu ・何ができるか：WebGPUのパイプライン（シェーダー・描画パス・計算パス）を短い関数で組み立てる。.wgsl を型付きモジュールとして扱える ・何を解決するか：生のWebGPU APIの冗長さと、テスト時にGPUが要る問題 ・実測①：3エントリポイントの共通エクスポートは22個。違いはアダプタ生成関数だけで、設計どおり差し替え可能だった ・実測②：vgpu/mock が返すのはピクセルではなくAPI呼び出しの記録。vgpu/node（Dawn）は動く環境が限られる この記事のポイント ・モックで描画して読み出すと262,144バイト返るが中身は全てゼロ。ラスタライズしないので当然で、代わりに呼び出し回数とディスクリプタを検証する ・Node経路は手元のmacOS 14 / arm64で失敗。エラーは vgpu prebuilds currently target **Linux arm64 only** と明示していた ・npm i は約8秒だが node_modules は95MBになる（Dawnのバイナリを含むため） フロントエンドの見た目まわりをどう組み立てるかという土台の整理はデザインシステムとは？仕組み・構成要素・有名事例をエンジニア向けに整理する【2026年版】にまとめてあります。vgpuはその上で「描画そのもの」を担う、もう一段低い層にあたります。 vgpuとは——WebGPUを短く書くための層 WebGPUを生で書くと、デバイス取得・パイプライン記述子・バインドグループ・コマンドエンコーダ……と定型のコードが長く続きます。vgpuはそこを短くします。READMEのNode向けクイックスタートはこうです。 import { draw, frame, init, target } from "vgpu/node"; import triangleShader from "./triangle.wgsl"; const gpu = await init(); const colorTarget = target(gpu, { size: [256, 256], format: "rgba8unorm" }); const triangle = draw(gpu, { shader: triangleShader }); frame(gpu, (f) => f.pass(colorTarget, triangle)); const pixels = await colorTarget.read(); gpu.dispose(); init でデバイスを取り、target で描画先、draw で描画物、frame で1フレーム分の記録——という流れです。生のWebGPUに比べると明らかに短くなります。 UIの部品を組み合わせて画面を作る話とは層が違う点に注意してください。square-ui徹底解説｜shadcn/uiのレイアウト集のような部品集が「何を並べるか」を扱うのに対し、vgpuが扱うのは「その1枚をGPUでどう描くか」です。併用はできますが、解決している問題が重なりません。 リポジトリはpnpmのモノレポで、8つのパッケージに分かれています。 パッケージ 役割 core 中核。デバイス抽象とモックGPU render 描画まわり wgsl / wgsl-std WGSLのモジュール解決と標準ライブラリ adapter-node Dawn経由のNode実行 adapter-mock GPU不要のモック vgpu / vgpu-api 公開パッケージとAPI定義 npmに出ているのは vgpu で、実測時点のバージョンは v0.3.1、ライセンスは MIT でした。 実測：導入とエントリポイントの突き合わせ まず入れます。以下のコマンドは実際に実行しています。 mkdir vg && cd vg && npm init -y npm pkg set type=module npm i vgpu@0.3.1 約8秒で完了しました（npmキャッシュが効いた2回目は約2秒）。ただし node_modules は 95MB になります。Dawnのネイティブバイナリを含むためで、ブラウザ向けにしか使わない場合でもこのサイズがインストールされます。 次に「同じAPI」という主張を確かめます。エクスポートを機械的に突き合わせました。 const [n, m, main] = await Promise.all([ import('vgpu/node'), import('vgpu/mock'), import('vgpu') ]); const N = new Set(Object.keys(n)), M = new Set(Object.keys(m)); const only = (a, b) => [...a].filter(x => !b.has(x)).sort(); console.log('node のみ:', only(N, M).join(' ')); console.log('mock のみ:', only(M, N).join(' ')); console.log('共通数 :', [...N].filter(x => M.has(x)).length); 結果はこうでした。 比較 結果 共通エクスポート数 22 vgpu/node のみ createNodeAdapter vgpu/mock のみ createMockAdapter / getMockGPUDeviceInstrumentation 既定 vgpu のみ なし 差分はアダプタ生成関数だけでした。init target draw frame compute storage uniforms といった実際に書く側の関数は3経路とも同名で揃っています。「経路を差し替えても同じコードが動く」という設計は、少なくともAPIの形としては本物です。 実測：vgpu/mock が返すのはピクセルではない ここが一番の注意点です。READMEは「vgpu/mock は決定的なソフトウェアアダプタに差し替えるので、テストにGPUが要らない」と書いています。これを読むと「GPUなしでレンダリング結果を検証できる」と受け取りがちですが、実際は違いました。 三角形を描くWGSLを用意し、256×256で描画して読み出しました。 # 記事の検証で使った最小構成（.wgsl は readFileSync で文字列として読む） node run.mjs mock # [mock] init=54ms render+read=7ms bytes=262144 不透明px=0 # [mock] 中央画素 rgba=0,0,0,0 読み出しは成功します。262,144バイト（256×256×4）がきちんと返ります。しかし中身は全てゼロでした。アルファが0でない画素は1つもありません。 理由は単純で、モックはラスタライズしないからです。ではモックで何を検証するのか——getMockGPUDeviceInstrumentation() を呼ぶと分かります。 calls = {"createBuffer":0,"createBindGroupLayout":0,"createBindGroup":0, "createCommandEncoder":1,"createRenderBundleEncoder":0, "createShaderModule":1,"createRenderPipeline":1, ...} createCommandEncoderDescriptors len=1 createRenderPipelineDescriptors len=1 createBufferDescriptors len=0 呼び出し回数と、渡したディスクリプタそのものが記録されています。 つまりモックが検証させたいのは「意図したとおりのパイプラインを、意図した回数だけ組み立てたか」です。バッファを余計に作っていないか、パイプラインを毎フレーム作り直していないか——といった構成の回帰テストに向いています。 「GPUなしでテストできる」を「描画結果を検証できる」と読まない：モックで返るピクセルは常にゼロです。見た目の回帰を見たいなら、実GPU（ブラウザまたはDawn）での実行が必要になります。モックが担当するのはAPI呼び出しの形であって、出力画像ではありません。ここを取り違えると、通っているはずのテストが... --- ## google maps scraperとは｜cloneしてもコードが1行も無いリポジトリの正体を確かめた - URL: https://ai-heartland.com/tool/google-maps-scraper/ - 更新日: 2026-09-02 - カテゴリ: tool - 概要: google maps scraper（omkarcloud・GitHub 3,372スター・MIT）を実際にcloneして中身を数えたところ、ソースコードが1ファイルもありませんでした。実体は配布バイナリのクローズドな製品で、GitHubにあるのは説明資料だけ。正体と、規約・法令面で先に確認すべき点を整理します。 - タグ: automation, スクレイピング, データ収集, ライセンス, Places API google maps scraper を探すと上位に出てくる omkarcloud/google-maps-scraper は、GitHubスター3,372を集めるリポジトリです。名前のとおりGoogle Mapsから店舗情報を集めるツールだろうと思って git clone したのですが、ソースコードが1ファイルもありませんでした。 この記事は、そのリポジトリの正体を確かめた記録です。あわせて、Google Mapsのデータを集めたい場合に先に確認しておくべき規約・法令面の論点と、公式の手段についても整理します。 実際にcloneして拡張子ごとに数えた結果。実行できるコードは含まれていない 30秒でわかる google-maps-scraper ・リポジトリの中身：PNG 77枚・GIF 4枚・マークダウン6本・LICENSE・.gitignore。.py / .js / .ts は0ファイル ・製品の実体：omkar.cloud と Amazon S3 から配布されるクローズドなデスクトップアプリ（mac / Windows / Linux） ・MITが覆う範囲：リポジトリに入っている説明資料。製品本体のソースは公開されていない ・この記事で試していないこと：Googleへのアクセスを発生させないため、アプリのダウンロードも実行もしていません この記事のポイント ・star 3,372でも、実行できるコードが入っているとは限らない。cloneして拡張子を数えれば1コマンドで分かる ・「GitHubのライセンスバッジがMIT」と「製品を自由に使える」は別の話 ・Google Mapsのデータ収集には規約・個人情報の論点がある。公式のPlaces APIという選択肢を先に検討する価値がある データ収集や自動化ツール全般の見取り図はAI自動化ツール｜ノーコードからコードまで2026年版の比較と選び方にまとめてあります。 google maps scraper のリポジトリの中身を数える まず事実確認です。次のコマンドは実際に実行しています。 # 浅いcloneで中身だけ確認する git clone --depth 1 https://github.com/omkarcloud/google-maps-scraper.git gms cd gms # 拡張子ごとにファイル数を数える find . -path ./.git -prune -o -type f -print | sed 's/.*\.//' | sort | uniq -c | sort -rn # 実行できるコードが入っているか find . -path ./.git -prune -o \( -name '*.py' -o -name '*.js' -o -name '*.ts' \) -print | wc -l 結果は次のとおりでした。 拡張子 ファイル数 .png 77 .md 6 .gif 4 .svg / .jpg / .gitignore / LICENSE 各1 .py / .js / .ts 0 マークダウン6本の内訳は README.md（314行）・advanced.md（441行）・fields.md（181行）・SECURITY.md（22行）などで、合計958行。説明資料のリポジトリです。 star数は「実体があること」を保証しない：3,372という数字は製品への関心を示していますが、リポジトリにコードが入っているかどうかとは無関係です。GitHubで見つけたツールを評価するときは、star数やREADMEの見栄えより先に、上のように拡張子を数えるほうが確実です。1コマンドで済みます。 数える前に、メタ情報も1回で取れる リポジトリの素性は gh コマンドでまとめて確認できます。これも実行して結果を確認しました。 # star数・ライセンス・最終push をまとめて見る gh api repos/omkarcloud/google-maps-scraper \ --jq '{stars:.stargazers_count, license:.license.spdx_id, pushed:.pushed_at}' # => {"license":"MIT","pushed":"2026-07-27T05:22:58Z","stars":3372} # ルート直下のファイル一覧（ディレクトリを除く） gh api repos/omkarcloud/google-maps-scraper/contents \ --jq '[.[]|select(.type=="file")|.name] | join(" ")' # => .DS_Store .gitignore LICENSE README.md SECURITY.md advanced.md # fields.md server-deployment.md video-script.md 2つ目の出力を見た時点で気づけます。ルート直下に .md と LICENSE しか無い——package.json も requirements.txt も pyproject.toml も、パッケージの入口になるファイルが1つもありません。cloneする前でも判断できる材料です。 なお star 数は計測時点の値です（本記事は2026年9月2日に3,372を確認しています）。日々増えるため、読む時点では違う数字になっているはずです。 google maps scraper の製品本体はどこにあるのか READMEを読むと導線がはっきりします。omkar.cloud とAmazon S3から配布されるデスクトップアプリでした。 対象OS 配布形式 配布元 macOS インストーラ omkar.cloud/l/mac Windows インストーラ omkar.cloud/l/win Linux（Debian系） .deb（amd64 / arm64） S3バケット Linux（RedHat系） .rpm（x86_64 / aarch64） S3バケット 配布URLが生きているかだけ確認しました（アプリのダウンロードはしていません）。 # ヘッダだけ取得して到達性を見る（本体はダウンロードしない） curl -sI -L "https://www.omkar.cloud/l/mac" | head -1 curl -sI -L "https://google-maps-extractor-omkar-cloud.s3.amazonaws.com/Google+Maps+Extractor-amd64.deb" | head -1 いずれも HTTP 200 を返しました。配布は現役です。READMEには動作要件としてGoogle Chromeのインストールが必要と書かれており、ブラウザを自動操作する方式であることがうかがえます。 課金面では、READMEが月200検索までの無料枠を掲げ、1検索あたり100〜1,000件以上の結果が得られると説明しています。ApifyやOutscraperを名指しして無料枠の大きさを比較する構成です。実際の課金体系と上限は配布元で確認してください。 同じ「配布バイナリを信じるかどうか」の問題でも、ソースが公開されていれば登録簿を数えたり通信を測ったりして裏を取れます。たとえばSentruxとは｜コード構造を測るRust製センサーを、開発停止後の凍結版として評価するでは、公式バイナリを実行して既定の通信挙動まで確認できました。このツールではそれができません。 重要なのは、ソースが公開されていない以上、アプリが内部で何をしているかを外から検証できない点です。 収集したデータをどこへ送るか、認証情報をどう扱うかも含めて、通常のOSSと同じ基準では評価できません。 MITライセンスが覆っている範囲 リポジトリの LICENSE は21行の標準的なMITで、Copyright (c) 2023-2024 Chetan Jain と記載されています。追加条件はありません。 ただしMITが適用されるのはそのリポジトリに含まれる著作物——つまり説明資料と画像です。前述のとおり製品のソースコードはリポジトリに入っていないので、配布されるアプリ本体はMITの対象外と読むのが自然です。アプリの利用条件は配布元の規約に従うことになります。 GitHubのライセンス表示は「リポジトリの中身」に対する表示です：GitHubはリポジトリ内のLICENSEファイルを読んでバッジを出しているだけで、その組織が配布する別の成果物まで保証しません。「バッジがMIT＝製品も自由に使える」ではないという切り分けは、この種の「ドキュメントだけのリポジトリ」で特に重要になります。 Google Mapsのデータ収集で先に確認すべきこと ここからはツールの話を離れて、そもそもこの種のデータ収集を行ってよいかという論点です。 規約の観点：Googleの利用規約は、サービス上のコンテンツを自動的に収集したり、取得したデータを再配布したりすることを制限しています。ツールの側が「できる」ことと、規約上「してよい」ことは別です。ツールを選ぶ前に、自分の用途が規約の範囲内かを確認する必要があります。 個人情報の観点：店舗情報には、屋号だけでなく個人事業主の氏名・電話番号・メールアドレスが含まれることがあります。これらは個人情報にあたり得る... --- ## Auto Companyとは｜14人のAIエージェントが自宅PCで24時間回るOSSを実LLMなしで測る - URL: https://ai-heartland.com/agent/auto-company/ - 更新日: 2026-09-02 - カテゴリ: agent - 概要: Auto Company（MaxMiksa/Auto-Company・GitHub 2,728スター）は14人のAIエージェントが自宅PCで24時間回り続けるOSS。PATH上に偽のCLIを置いてトークン消費ゼロでループを実測し、毎サイクル権限確認が外れること・サーキットブレーカが本当に働くこと・LICENSEが無いことを確かめました。 - タグ: AIエージェント, 自律エージェント, Claude Code, 自動化, Bash Auto Company（MaxMiksa/Auto-Company・GitHubスター2,728）は、14人の専門家ペルソナを持つAIエージェントに、会社の運営サイクルを無人で回させるOSSです。CEO・CFO・CTO・QA・マーケティング……といった役割の定義ファイルが用意され、Claude Code または Codex CLI をエンジンとして30秒間隔で呼び出し続けます。 この種の道具を評価するとき、機能一覧を眺めても意味がありません。無人で24時間、自分のPCを操作し続けるプログラムに対して知りたいのは2つだけです——どんな権限で起動されるのか、そしておかしくなったとき止まるのか。この記事はその2点を、本物のLLMを1回も呼ばずに測りました。 PATH上に偽の claude を置いてループを実行。トークン消費ゼロ・外部通信なしで、引数とブレーカの挙動を確認した 30秒でわかる Auto Company ・何ができるか：14人のエージェント定義とBashループで、Claude Code / Codex CLI を無人で回し続ける ・何を解決するか：「エージェントに長時間まとまった作業をさせる」ときの、人が張り付く手間 ・実測①：毎サイクル --permission-mode bypassPermissions が無条件に渡される（承認プロンプトが外れる） ・実測②：サーキットブレーカは本当に働く。CLIが「成功」を返しても成果物を別途検証し、5回連続失敗で停止する この記事のポイント ・偽CLIを使えばトークン消費ゼロ・外部通信なしで、無人ループの権限と停止条件を測れる ・LICENSEファイルが無い（package.json はMIT表記・GitHub APIは license: null）。商用は要確認 ・開発は2026-05-20で停止。総コミット502から増えていない エージェント基盤全体の見取り図はAIエージェントフレームワーク比較2026｜LangGraph・CrewAI・Dify等9種をStar数・実コードで検証にまとめてあります。Auto Companyはフレームワークではなく、既存のCLIを繰り返し叩く薄い層という位置づけです。 Auto Companyとは——14人のペルソナとBashループ 構造は意外なほど素朴です。中核は scripts/core/auto-loop.sh という1本のBashスクリプトで、これが次を繰り返します。 ・エンジン（claude または codex）を1回呼ぶ ・出力として consensus.md が正しく生成されたか検証する ・成否をログに記録し、既定30秒待って次のサイクルへ エージェントの「人格」は .claude/agents/ 配下のマークダウンで与えられます。実際に数えたところちょうど14本ありました。 役割 ファイル 役割 ファイル CEO ceo-bezos.md CFO cfo-campbell.md CTO cto-vogels.md 批評 critic-munger.md DevOps devops-hightower.md フルスタック fullstack-dhh.md インタラクション interaction-cooper.md マーケティング marketing-godin.md オペレーション operations-pg.md プロダクト product-norman.md QA qa-bach.md リサーチ research-thompson.md セールス sales-ross.md UI ui-duarte.md 実在の専門家の思考モデルを模した名前が付いています。役割ごとにマークダウンを1本置くという形式はmattpocock/skills完全ガイド｜Claude Code用スキル集で開発プロセスを自動化のようなスキル集と同じで、違いは「人が呼び出す」か「ループが無人で呼び続ける」かにあります。LLMを内蔵しているわけではなく、下層のCLIが持つモデル・権限・ツール実行能力をそのまま継承して繰り返し呼ぶだけ、という点は最初に押さえておくべきです。 実LLMを呼ばずにAuto Companyのループを測る方法 本題です。無人ループの挙動を確かめたいが、本物のLLMを24時間回すのは費用も影響も大きすぎます。そこで PATH上に偽の claude を置きました。トークンは1つも消費せず、外部通信も発生しません。 # 実LLMを呼ばない偽CLI。渡された引数を記録し、成功形のJSONだけ返す mkdir -p /tmp/fakebin cat > /tmp/fakebin/claude <<'EOS' #!/bin/bash [ "$1" = "--version" ] && { echo "1.0.0-fake (fake)"; exit 0; } printf '%s\n' "$@" >> /tmp/fake-claude.log printf '{"type":"result","subtype":"success","is_error":false,"result":"FAKE-NO-LLM"}\n' EOS chmod +x /tmp/fakebin/claude # 間隔とタイムアウトだけ短縮して、使い捨てのcloneでループを回す PATH="/tmp/fakebin:$PATH" LOOP_INTERVAL=2 CYCLE_TIMEOUT_SECONDS=25 \ bash scripts/core/auto-loop.sh # 2回目以降で "Auto loop already running (PID ...)" と言われたら、 # 前回の残骸を消してから再実行する（Ctrl+Cで止めるとPIDファイルが残る） rm -f .auto-loop.pid この手順は実際に2回実行して、同じ結果が出ることを確認しています。 実測①：毎サイクル、承認プロンプトが外れた状態で起動される 偽CLIが受け取った引数を記録すると、次のようになっていました。 argv[1]=-p argv[2]=<ループプロンプト本文> argv[3]=--output-format argv[4]=json argv[5]=--permission-mode argv[6]=bypassPermissions --permission-mode bypassPermissions が毎サイクル、無条件に渡されています。ソースを見ると scripts/core/auto-loop.sh の既定値がそうなっています。 CLAUDE_PERMISSION_MODE="${CLAUDE_PERMISSION_MODE:-bypassPermissions}" つまり環境変数で明示的に上書きしないかぎり、承認プロンプトを外した状態で起動され続けます。 さらに同梱の .claude/settings.json も同じ方向を向いています。 設定 値 意味 permissions.defaultMode bypassPermissions 既定で承認を求めない permissions.allow WebSearch Bash Edit Write WebFetch NotebookEdit Skill シェル実行とファイル書き込みを許可 permissions.ask [] 確認する対象なし permissions.deny [] 拒否する対象なし enableAllProjectMcpServers true プロジェクトのMCPサーバを全て有効化 READMEも「システムレベルの操作がホスト環境で直接起きる」と明記しており、実質的なサンドボックスは無いと作者自身が認めています。 CLAUDE.mdのガードレールはOSの強制ではない：リポジトリの CLAUDE.md には「GitHubリポジトリを削除しない」「~/.ssh を触らない」といった禁止事項が書かれています。これらはプロンプト上の約束事であって、OSレベルで強制されるものではありません。gh や wrangler の認証情報がある環境では、外部への不可逆な操作も無人で走り得ます。試すなら隔離環境・使い捨ての専用アカウント・最小権限のトークンを用意してください。 実測②：サーキットブレーカは「成功」を鵜呑みにしない ここは想像より良くできていました。 偽CLIは subtype: success / is_error: false、つまり「成功しました」と返しています。それでもループは各サイクルを [FAIL] と判定しました。 [06:01:08] Cycle #1 [START] Beginning work cycle [06:01:11] Cycle #1 [FAIL] consensus.md validation failed after cycle (errors: 1/5) [06:01:13] Cycle #2 [FAIL] consensus.md validation failed after cycle (errors: 2/5) [06:01:15] Cycle #3 [FAIL] consensus.md validation failed after cycle (errors: 3/5) [06:01:17] Cycle #... --- ## Sentruxとは｜コード構造を測るRust製センサーを、開発停止後の凍結版として評価する - URL: https://ai-heartland.com/tool/sentrux/ - 更新日: 2026-09-02 - カテゴリ: tool - 概要: Sentrux（sentrux/sentrux・GitHub 3,062スター・MIT）はコード構造を0〜10000点で測るRust製ツール。v0.5.7の公式バイナリを実際に入れて動かし、CIゲートが規則ファイル無しで素通りすること・匿名解析が既定で有効なこと・開発が2026年3月で止まっていることを実測しました。 - タグ: automation, Rust, コード品質, 静的解析, MCP Sentrux（sentrux/sentrux・GitHubスター3,062・MIT）は、コードの構造を0〜10000点のスコアで測るRust製のツールです。行数でもテストカバレッジでもなく、「依存が絡まっていないか」「責務が散っていないか」という設計面を数値にします。 ただしこのツールを紹介するとき、機能の説明より先に伝えるべきことがあります。開発が2026年3月19日で止まっています。 それでもスターは3,062まで伸び続けており、GitHubの見た目からは気づきにくい状態です。この記事は「凍結されたバージョンを、いま入れる価値があるか」という一点に絞って、公式バイナリを実際に落として動かした結果から判断します。 2026年9月2日に実測した現況。開発は止まっているが配布物は生きており、実行そのものは今も成立する 30秒でわかる Sentrux ・何ができるか：52言語のコードを5指標（モジュラリティ／非循環性／深さ／均等性／冗長性）で解析し、0〜10000点のスコアとTreemapで構造を可視化する ・何を解決するか：AIエージェントが大量にコードを書く環境で、「動くけれど構造が壊れていく」変化を数値で捉える ・実際に動いたか：動いた。v0.5.7の公式バイナリは今日も起動し、check も走る ・注意すべき点：check は規則ファイルが無いと終了コード0で素通りする。匿名の利用統計が既定で有効。有料版の購入ページは404 この記事のポイント ・37本のリリースがすべて2026年3月に集中し、以降ゼロ。稼働期間は実質8日間だった ・それでもバイナリは今も動く（v0.5.7・23,014,208バイト・初回にグラマーを自動取得） ・CIゲートとして入れるなら .sentrux/rules.toml が必須。無いと常に成功する（実測） 開発ツール全般の見取り図はAI自動化ツール｜ノーコードからコードまで2026年版の比較と選び方にまとめてあります。Sentruxはその中でも「コードの構造だけを測る」という狭い一点に特化した道具です。 Sentruxとは——構造だけを測るセンサー 多くの静的解析ツールは「この行が危ない」を指摘します。Sentruxが見るのはもっと粗い粒度で、ファイルとモジュールの関係です。 ・modularity（モジュラリティ）：責務がまとまっているか ・acyclicity（非循環性）：依存が循環していないか ・depth（深さ）：依存の階層が深すぎないか ・evenness（均等性）：一部のファイルに偏っていないか ・redundancy（冗長性）：似たものが散らばっていないか この5つを合成して0〜10000点を出します。解析にはtree-sitterを使っており、52言語に対応します。単一バイナリで、データベースもランタイムも要りません。 MCPサーバーとしても起動でき（sentrux mcp）、Claude Codeのようなエージェントから構造スコアを直接引けます。「エージェントが書いたコードの構造が劣化していないかを、エージェント自身に確認させる」という発想です。 Sentruxの現況——37本のリリースが2026年3月に集中し、以降ゼロ 機能の話より先にここです。2026年9月2日に実測しました。 観測項目 実測値 ブランチ数 main の1本のみ（隠れた開発ブランチ無し） 最終コミット 2026-03-19（6f8ff3c1） リリース総数と分布 37本すべてが2026年3月。4月以降ゼロ 最新版 v0.5.7（2026-03-18） リポジトリ作成 2026-03-11（＝稼働期間は実質8日間） スター / フォーク 3,062 / 277 ライセンス MIT（22行の標準文面・追加条件なし） 月別のリリース数は自分で数えられます。このコマンドは実際に実行して結果を確認しています。 # リリースの公開月を数える（37本すべてが 2026-03 に入る） gh api 'repos/sentrux/sentrux/releases?per_page=100' --jq '.[].published_at' \ | cut -c1-7 | sort | uniq -c # 既定ブランチの最終コミット日 gh api repos/sentrux/sentrux/commits/main --jq '.commit.committer.date' star が伸びていることは、開発が続いている証拠にならない：Sentruxは8日間で37本のリリースを出して止まりました。star はその後も積み上がっていますが、これは注目の残り火です。GitHub APIの pushed_at も既定ブランチ以外へのpushで動くため生存判定には使えません（このリポジトリはブランチが main 1本なので、たまたま両者が一致しました）。観測すべきはリリースの分布と既定ブランチの最終コミット日です。 もうひとつ、最後のコミットの中身が示唆的です。メッセージは “Add Pro CLI commands: login, pro activate/status/deactivate/update” ——有料版を有効化するCLIコマンドの追加でした。収益化に着手した直後に手が止まっています。 5つの指標は「どこを直せばいいか」に翻訳できる スコアが0〜10000という粒度で出るため、最初は「で、何をすればいいのか」と戸惑います。実務では5指標を個別に見るほうが行動に繋がります。 ・acyclicity（非循環性）が低い：モジュール同士が相互参照している状態です。片方向に整理するか、共通部分を third module に切り出す判断になります。AIエージェントが「近くにある似た関数」を掴んで実装した結果、双方向の依存が生まれるパターンが典型です ・evenness（均等性）が低い：特定のファイルに機能が集中しています。いわゆる神クラス・神モジュールで、そこを触るたびに広範囲へ影響が出ます ・redundancy（冗長性）が高い：似た役割のコードが複数箇所にあります。エージェントが既存の実装を見つけられず同じものを書き直したときに増えます ・depth（深さ）が大きい：依存の階層が深く、末端の変更が上まで波及しやすい状態です ・modularity（モジュラリティ）が低い：責務の境界が曖昧で、上の4つの結果として下がることが多い指標です このうち redundancy と acyclicity は、AIエージェントに大量にコードを書かせたときに特に悪化しやすい指標です。人間なら「これ前に書いたな」と気づくところを、エージェントは文脈が切れると気づけません。Sentruxのようなツールが注目された背景はここにあります。 凍結版であることの実務的な意味 「開発が止まっている」と聞くと反射的に避けたくなりますが、道具の種類によって意味が変わります。 ・サーバとして常駐し、外部と通信し続けるもの（脆弱性が致命傷になる）→ 凍結は重い問題 ・手元で一度走らせて結果を読む道具（入力も出力も自分の手の内）→ 凍結の影響は小さい Sentruxは後者に近い性質です。単一バイナリでローカルのコードを読んでスコアを返すだけなので、上流が更新されなくても昨日と同じ結果が出ます。むしろ「基準が変わらない」ことは、継続的に比較する用途ではメリットにすらなります。 問題になるのは、壊れたときに直せないことと、新しい言語・文法に追随しないことの2点です。前者はMITライセンスとRust実装なのでフォークして直す道が残っており、後者は自分が使う言語がv0.5.7時点で対応済みかどうかで判断できます。 実測：凍結版のバイナリは、今日も動く 「止まっている」と「使えない」は別です。実際に落として動かしました。 # v0.5.7 の公式バイナリを取得して実行 curl -sL -o sentrux \ https://github.com/sentrux/sentrux/releases/download/v0.5.7/sentrux-darwin-arm64 chmod +x sentrux ./sentrux --version 結果は次のとおりです。 ・バイナリのサイズは 23,014,208バイト（darwin-arm64）。Mach-O 64bit実行ファイル1つだけ ・初回起動時に言語グラマーを自動ダウンロードする。1回目の --version は Downloading language grammars for v0.5.7... と表示して終わり、2回目に sentrux 0.5.7 を返した ・グラマーは同じリリースに grammars-darwin-arm64.tar.gz（8,949,349バイト）等として置かれており、Linux（x86_64 / aarch64）・Windows向けも揃っている つまりインストールは今も成立します。上流が止まっていても、配布物がGitHub Releasesに残っている限り実行はできます。 --help を見ると、実際のコマンド構成が分かります。 Commands: check Enforce architectural rules defined in .sentrux/rules.toml gate Structural regression gate — compare against a saved base... --- ## Claude-OSINTとは｜9本のOSINTスキルの起動条件・常駐トークン・安全弁を実測で確かめた - URL: https://ai-heartland.com/agent/claude-osint/ - 更新日: 2026-09-02 - カテゴリ: agent - 概要: Claude-OSINT（elementalsouls・GitHub 2,441スター）はClaude Codeに外部偵察の手順書を持ち込むスキルパック。9本のSKILL.mdが「いつ起動するのか」をダミースキルのA/Bで実測し、常駐トークン数と安全弁の実効性まで導入前に必要な点を整理します。 - タグ: AIエージェント, Agent Skills, OSINT, セキュリティ, アタックサーフェス Claude-OSINT（elementalsouls/Claude-OSINT・GitHubスター2,441・MIT）は、外部からの見え方を調べる手順書をClaude Codeのスキル形式に畳み込んだパックです。ソフトウェアというよりClaudeに読ませる方法論のテキストで、SKILL.mdの合計は54万文字を超えます。 この種のパックを評価するとき、機能一覧を眺めても分かりません。知りたいのは「入れたら何が常に載るのか」「どういうときに勝手に起動するのか」「止めてくれる仕組みは何なのか」の3点です。この記事はその3点を実測しました。偵察そのものは一切行っていません——数えたのはファイル・frontmatter・トークン数で、起動条件はこのリポジトリと無関係なダミースキルでA/Bを取っています。 スキル数と自動起動抑止の有無を数え、triggers: と description のどちらが起動を決めるかをダミースキル2本のA/Bで確かめた実測 30秒でわかる Claude-OSINT ・何ができるか：ドメイン・クラウド資産の棚卸し、メール偽装耐性の判定、IdP構成の把握、リスクの金額換算、継続監視——の手順書を9本のSKILL.mdでClaudeに渡す ・何を解決するか：「自社が外からどう見えているか」を調べるとき、毎回やり方を思い出す／指示し直す手間 ・何を代替するか：SpiderFoot等のスキャナを人手で回して結果を読む工程の一部（置き換えではなく別物。後述の比較表） ・実測でわかったこと：triggers: は起動条件として機能しない。実際に起動を決めるのは description で、9本すべてに自動起動の抑止指定が無い この記事のポイント ・ダミースキルのA/Bで、triggers: に書いた語では起動せず description に書いた語で起動することを確認した（対照群つき） ・常駐するのは description のみで9本合計 3,332トークン。本文は 148,514トークンで、offensive-osint 1本が44%を占める ・安全弁は「コードとして動くもの」と「文章でのお願い」に分かれる。認可の確認は後者で、ランタイムの disable-model-invocation は0/9本 エージェント側の道具立てを俯瞰したい場合はAIエージェントフレームワーク比較2026｜LangGraph・CrewAI・Dify等9種をStar数・実コードで検証を先に読むと、スキルパックがどの層の話なのか整理しやすくなります。 Claude-OSINTとは——偵察の手順書を9本のSKILL.mdに畳んだスキルパック 中身はマークダウンです。実行ファイルはごく一部で、大半は「こういう順序で、こういう観点で調べる」という方法論のテキストです。9つのディレクトリは役割が分かれています。 スキル 役割 本文行数 osint-methodology 全体の考え方（6段階のパイプライン・重大度の基準） 520 offensive-osint 具体的な調査対象の辞書（パス・ポート・観点の一覧） 4,734 org-attack-surface 法人名から保有ドメイン・ネットブロックを辿る帰属手順 1,063 identity-provider-recon IdP／テナント構成の把握 1,003 continuous-exposure-monitoring 再スキャンと差分の継続運用 817 cloud-saas-exposure クラウドストレージ・供給網の露出 809 exposure-risk-quantification 検出結果をFAIRベースで金額とグレードに換算 750 email-domain-security SPF/DMARC/DKIMから偽装耐性を判定 608 osint-autopilot 上記を一気通貫で最後まで走らせる実行ランブック 94 注目したいのは上6本の名前です。org-attack-surface・cloud-saas-exposure・email-domain-security・exposure-risk-quantification・continuous-exposure-monitoring は、いずれも「自分の資産がどれだけ外に出ているか」を測る側の語彙です。攻撃手法そのものを名乗っているのは offensive-osint の1本だけで、パックの重心は露出面の把握にあります。自社ドメインの棚卸しに使うなら、この5本が主役になります。 なお本記事では、offensive-osint に収録されている検出用の正規表現や検索文字列そのものは載せません。件数と性質だけを数えます。 READMEの「8スキル」とディレクトリの9本——どちらが正しいのか リポジトリ説明は「8 Claude skills」と名乗りますが、skills/ 配下のSKILL.mdは9本あります。数え間違いかと思いましたが、リポジトリに同梱された検査スクリプトを走らせると答えが出ました。 # リポジトリ自身が持つ「ドキュメント内の数字」検査を実行する python3 scripts/check_doc_counts.py # Ground truth: 9 skill dirs (8-skill library = 6 depth + 2 core). # Checked 11 doc assertion(s): 0 error(s). 意図的な数え方でした。9ディレクトリのうち「ライブラリ」として数えるのは8本（深掘り6本＋コア2本）で、osint-autopilot はライブラリではなく実行ランブックとして別枠になっています。READMEの構成図にも osint-autopilot は登場しません。 ただし、導入判断の観点では見過ごせません。「8スキル」に数えられていない9本目こそが、パイプラインを止めずに最後まで走らせる役割だからです。その本文にはこう書かれています。 ・停止して確認するのは3つの場面のみ（認可・能動的な検証段階・スコープ外の別ドメイン発見） ・それ以外の段階は質問せずに走り切る ・認可については「まだ表明されていなければ一度だけ確認して進む」 インストールすると9本すべてが入ります。数え方の議論とは別に、入るのは9本という事実は押さえておく価値があります。 実測：triggers: は起動条件ではない（ダミースキルのA/B） 各SKILL.mdのfrontmatterには triggers: というキーがあり、external recon や run OSINT といった語が並んでいます。一見すると「この語を言うと起動する」設定に見えます。実際にそうなのかを確かめました。 Claude-OSINT自体を読み込ませて試すと、起動しても偵察の話が始まってしまいます。そこでこのリポジトリとまったく無関係なダミースキルを2本用意し、造語 flimwazzle で切り分けました。 ・A（zorptrix-alpha）：description は無関係な内容。triggers: にだけ flimwazzle を書く ・B（zorptrix-beta）：triggers: を持たず、description に「flimwazzle と言われたら使う」と書く flowchart TD Q["入力: flimwazzle"] --> R{"Claude Code がどのスキルを選ぶか"} R -->|"A: triggers: にだけ記載"| NA["起動しない（対照群でも0件）"] R -->|"B: description に記載"| YB["即座に起動Skill(zorptrix-beta)"] NA --> C["結論: triggers: は routing に使われない"] YB --> C 結果です（claude -p の stream-json 出力から、Skillツールの呼び出しだけを抜き出しました）。 設置したスキル 入力 Skillツールの呼び出し A と B を併置 flimwazzle B のみ（zorptrix-beta） A のみ（対照群） flimwazzle なし。「一致するコマンドやスキルが無い」と応答 対照群まで取ると疑いようがありません。triggers: はドキュメントであって、ランタイムの routing には使われていません。 起動を決めているのは description の文面です。 これは「設定が間違っている」という話ではなく、読む側が起動条件を知りたいときにどこを読むべきかの話です。Claude-OSINTのdescriptionは長く、たとえば offensive-osint は2,778文字あり、末尾は「認可された外部偵察で具体的な調査パス・正規表現・スコアリング規則が必要なときに使う」で終わります。osint-autopilot はさらに広く「OSINT / recon / attack-surface を実行してと言われたら常に」です。入れておくと、この語彙に触れた会話でロードされ得ると理解しておくのが正確です。 「一覧に出ている」と「発火する」は別：スキルが一覧に載っていても実際に起動するとは限らず、逆に載っているだけで発火することもあります。判定は本文の言い回しではなく、--output-format stream-json で Skil... --- ## Certimateとは｜SSL証明書の発行・配置・更新を自動化するセルフホストACMEツールを実測 - URL: https://ai-heartland.com/automation/certimate/ - 更新日: 2026-09-02 - カテゴリ: automation - 概要: Certimate（certimate-go・GitHub 9,222スター・MIT）はSSL証明書の発行から配置・更新・監視までをワークフローで自動化するセルフホストOSS。公式配布バイナリv0.4.32を実際に起動し、依存ゼロ・メモリ公称値・既定の管理者アカウント・対応プロバイダ数を実測した結果をまとめます。 - タグ: automation, SSL, ACME, セルフホスト, Go, DevOps Certimate（certimate-go/certimate・GitHubスター9,222・MIT）は、SSL証明書の発行から配置・更新・監視までをGUIのワークフローで束ねるセルフホストOSSです。なぜ今この種の道具が要るのかというと、CA/Browser Forum の Baseline Requirements が2026年3月15日から、サーバ証明書の最長有効期間を398日から200日へ短縮したからです。2029年3月にはこれが47日になります。年1回だった更新作業が、年8回になるということです。 日本語の解説記事は執筆時点で見当たらず（Qiita検索0件、Google日本語SERPの上位も英語・中国語のみ）、READMEの数字を実際に動かして確かめたものも見つかりませんでした。この記事では公式配布バイナリ v0.4.32 を手元で起動し、公称値との差まで含めて整理します。 公式配布 zip の checksum を照合 → 環境変数ゼロ（env -i）で起動 → HTTP 200 → RSS 計測まで。すべて本記事のために実行した実測です 30秒でわかる Certimate ・何ができるか：ACME（Let’s Encrypt等）で証明書を取り、159種類の配置先（CDN・ロードバランサ・WAF・Kubernetes・SSH先など）へ自動で配り、期限前に更新して結果を通知する ・何を解決するか：証明書の最長有効期間が200日→100日→47日と短くなるなかで、更新そのものではなく「更新した証明書を配り直す作業」が破綻するのを防ぐ ・何を代替するか：certbot/acme.sh＋自作の配布スクリプト群、または各クラウドの証明書マネージャを跨いだ手作業 ・実測でわかったこと：環境変数ゼロで起動でき依存は本当にゼロ。ただしメモリは公称「~16 MB」に対し実測33〜36 MiB、初回起動時点で既定の管理者アカウントが有効（公開前に必ず変更） この記事のポイント ・READMEの「150+ の配置先 / 70+ のDNSプロバイダ」をソースの登録簿から数え直すと、実測は配置先159・DNS-01が73で、公称は控えめな表記だった ・「Zero Dependencies」は本当だった——env -i（環境変数ゼロ）で起動し、SQLite2ファイルを自動生成してHTTP 200を返した ・一方で公称「~16 MB」のメモリは実測33〜36 MiB。さらに初回起動時点で既定の管理者アカウントが有効で、変更用の環境変数は初回起動時にしか効かない ノーコードからコードまでの自動化ツール全体の見取り図はAI自動化ツール｜ノーコードからコードまで2026年版の比較と選び方にまとめてあります。Certimateはその中でも「証明書ライフサイクル」という一領域に絞って自動化する道具にあたります。 Certimateとは——証明書の発行・配置・更新を1本のワークフローに束ねるOSS Certimateは Go 製の単一バイナリで、内部に PocketBase（SQLite）とWeb UIを同梱しています。使う側から見た構造は次の3層です。 ・Credentials（資格情報）：DNSプロバイダやクラウドのAPIキーを登録しておく箱 ・Workflow（ワークフロー）：「申請 → 配置 → 通知」を並べたDAG。条件分岐・遅延・try/catch を持つ ・Certificates（証明書）：発行済み証明書と有効期限の一覧 重要なのは2つ目のワークフローが本体だという点です。「証明書を取る」だけならcertbotで足ります。Certimateの価値は、取った証明書をその先にある無数の配置先へ配り直すところにあります。 実際に新規ワークフローを1本作ると、既定テンプレートとして次の形が生成されました。 手元で新規作成したワークフローの初期状態。本流は「Start → 申請(Application) → 配置(Deployment)」、失敗時のcatch経路に「通知(Notification) → End」が最初から用意されている この「try/catch が最初から入っている」点は、ソース側の定義とも一致します。ワークフローのノード型は13種類が定義されており（internal/domain/workflow.go）、内訳は制御系が start / end / condition / branchBlock / tryCatch / tryBlock / catchBlock / delay の8種、業務系が bizApply（申請）/ bizUpload（アップロード）/ bizMonitor（監視）/ bizDeploy（配置）/ bizNotify（通知）の5種です。「証明書を取る」より「取った後の分岐と失敗処理」に語彙が割かれているのがこのツールの設計思想を表しています。 なぜ2026年に効くのか——最長有効期間はすでに200日、2029年3月には47日 Certimateのような道具が今になって必要になった理由は、Certimate側ではなくCA/Browser Forum側にあります。一次ソースである Baseline Requirements（TLS BR v2.2.9）§6.3.2 は、次の表を掲げています。 CA/Browser Forum TLS Baseline Requirements v2.2.9 §6.3.2 の規定。Ballot SC-081v3（2025年4月投票・採択）で確定した 証明書の発行日 最長有効期間 ドメイン検証データの再利用期限 〜2026-03-15 398日 398日 2026-03-15〜2027-03-15 200日（現在） 200日 2027-03-15〜2029-03-15 100日 100日 2029-03-15〜 47日 10日 見落とされがちなのは右端の列です。証明書の有効期間だけでなく、ドメイン検証（DCV）データの再利用期限も同時に短くなります。2029年3月以降はドメイン所有の再確認が10日ごとに必要になるため、「更新のときだけDNSレコードを手で置く」運用は成立しません。DNS-01チャレンジをAPIで自動化しておくことが前提になります。 この記事の数値の出どころ：有効期間の表は CA/Browser Forum の Baseline Requirements 本文（cabforum/servercert リポジトリの docs/BR.md・Version 2.2.9）を直接参照しています。ベンダーの解説記事ではなく規定本文の §6.3.2 と巻頭の施行日一覧の両方に同じ日程が載っていることを確認しました。 実測：公式バイナリを環境変数ゼロで起動する READMEは「Zero Dependencies（データベースもランタイムもフレームワークも不要）」と書いています。これを額面どおり受け取ってよいのか、公式のリリース資産で確かめました。 まず配布形態です。v0.4.32 のリリースには8つのzipが並んでいます（darwin amd64/arm64、linux amd64/arm64/armv7、windows 386/amd64/arm64）。「Cross Platforms」の主張はこの8点で裏づけられます。手元のmacOS arm64版をダウンロードし、同じリリースに置かれた checksums.txt と照合しました。 # 公式リリースの取得と改ざん検知 curl -LO https://github.com/certimate-go/certimate/releases/download/v0.4.32/certimate_v0.4.32_darwin_arm64.zip curl -LO https://github.com/certimate-go/certimate/releases/download/v0.4.32/checksums.txt shasum -a 256 -c checksums.txt --ignore-missing zipは34,750,767バイト、SHA-256は aad528be…9dbd で checksums.txt の記載と一致しました。展開して出てくる実行ファイルは1つだけで、サイズは122,926,354バイト（約117 MiB）です。159種の配置先と73種のDNSプロバイダのSDKをすべて静的リンクした結果であり、「依存ゼロ」の代償はこのファイルサイズに現れていると読めます。 次に、依存の有無を厳密に測るため環境変数を1つも与えずに起動しました。 # 環境変数ゼロ・設定ファイルなし・DBなしの状態から起動する env -i ./certimate serve --dir pb_data --http 127.0.0.1:18090 結果は次のとおりです。 ・起動した。HOME も PATH も無い状態で、エラーも警告も出さずに待ち受けを開始した ・初回起動時に v0.4.0 から v0.4.29 までのマイグレーションを順に実行し、データディレクトリを自動生成した ・curl でトップページを叩くと HTTP 200。ログイン画面のHTMLが返る ・生成された pb_data は data.db と auxiliary.db の2つのSQLiteファイル（＋WAL）のみ、合計512KB 「データベースもランタイムも不要」という主... --- ## codeburnとは｜41のAIコーディングツールのコストをローカル集計、対応数と通信を自分で数えた - URL: https://ai-heartland.com/tool/codeburn/ - 更新日: 2026-09-01 - カテゴリ: tool - 概要: codeburnはAIコーディングのトークンとコストをローカルで集計するOSS。「41ツール対応」をコードの登録簿から数え直し、手元では41分の2しか埋まらないことを確かめた。「ローカル完結」の主張も通信を傍受して陽性対照つきで検証している。 - タグ: AIコーディング, vibe-coding, CLI, コスト, オープンソース, TypeScript AIコーディングツールを2つ3つと併用しはじめると、AIコーディング コストの合計が誰にも分からなくなる。Claude Codeの/usageはClaude Codeの分しか見せないし、Cursorの請求画面はCursorの分しか見せない。 codeburnは、この「合計が見えない」を、各ツールが自分でディスクに書いている履歴ファイルを読むという方法で解こうとするOSSだ。GitHubのstarは9,785、Homebrew coreにも収録されている。掲げる看板は2つ——「41ツール対応」と「無料・ローカル完結」である。 どちらも都合よく引用されやすい主張だが、幸いどちらも数えられる／測れる。本記事ではコード側の登録簿を数え、手元の環境で実際に何個埋まるかを確かめ、そして通信を傍受して「ローカル完結」を検証した。 本記事の中心的な実測。「41ツール対応」は登録簿の数としては正しいが、手元で実際に埋まったのは41分の2だった。「対応している」と「あなたの環境で計測できる」は別の数字である（codeburn 0.9.23 / 2026-09-01実測） AIコーディングツール全体の選び方や併用の考え方はVibe Codingとは？AIコーディングの始め方・ツール比較・実践ワークフロー2026にまとめてある。本記事はその「使った分のコストをどう把握するか」という一点を、実測に絞って掘り下げる。 30秒でわかるcodeburn ・正体：AIコーディングツールがディスクに残すセッション履歴を読み、トークンとコストをツール別・モデル別・プロジェクト別・タスク別に集計するCLI ・対応数：コードの登録簿は常時30＋遅延11＝41。READMEの「41 tools」と一致し、CLIのdoctorも「41 providers」と表示する。ただしGitHubの説明文だけ「37」のまま古い ・現実の被覆：実測環境で埋まったのは41分の2（Claude 61セッション・Cursor 20セッション）。残り38は未インストールでNOTHING FOUND ・通信：status・doctorの実行中、外部への接続試行は0件（陽性対照つきで検証）。通信するのはshare/devices/sync/mcpなど明示的に呼んだときだけ ・規模：★9,785・fork 778・MIT・v0.9.23・Homebrew coreに収録（直近30日で1,293インストール） codeburnとは——各ツールが残した履歴を読んで合算する codeburnの発想はシンプルで、新しくログを取らない。Claude CodeもCursorもCodexも、セッションの履歴を自分のホームディレクトリ配下に書いている。codeburnはそれを後から読んで集計するだけだ。だからツール側に何も仕込む必要がなく、過去に遡って集計できる。 2026年9月1日時点の実測値は以下のとおり。 項目 実測値（2026-09-01） GitHub star 9,785 fork 778 オープンなIssue 27（別途オープンなPRが6本） 初回コミット 2026-04-13 最終push 2026-08-31 バージョン 0.9.23 ライセンス MIT 実行要件 Node.js >=22.13.0（enginesで宣言） 配布 npm（npx codeburn）／Homebrew core Homebrewインストール数 1,293（直近30日） ★9,785という数字より、Homebrewの1,293インストール/30日のほうが実態に近い指標だと考えている。starは「あとで見る」のブックマーク代わりに押されることが多いが、インストール数は実際に手元へ入れた人の数だからだ。なおopen_issues_countをそのまま「Issue 33件」と書くとGitHub APIの仕様上PRが混ざるので、上表では27と6に分けている。 codeburn 使い方の最短経路——npxとHomebrewの両方を確認した 配布経路は2つある。両方とも実在を確認済みで、本記事の実測はnpx経由とローカルインストールの両方で行った。 # 1) 何もインストールせずに試す（本記事はこれで実測した） npx codeburn # 2) Homebrew core に収録されているので tap の追加は不要 brew install codeburn # 3) 導入後の健康診断。どのツールを探しに行き、何件見つかったかが1画面で出る codeburn doctor brew install codeburnについては、Homebrew coreの公式APIで tap: homebrew/core・stable: 0.9.23・license: MIT・依存はnodeのみであることを確認した（ユーザーの環境を変更するためbrew install自体は実行していない）。①の記事で扱ったような個人tapではなく本体に収録されている点は、審査を通っているという意味で信頼性の材料になる。 実行要件はpackage.jsonのenginesで>=22.13.0と宣言されている。本記事の実測環境はNode 22.13.1で、ちょうど下限ぴったりだが問題なく動作した。宣言があるので、古いNodeではnpmが警告を出してくれる。 よく使うコマンドは次の4つに集約される。 コマンド 何が出るか codeburn status 今日と今月の合計を1行で。$84.52 424 calls のような最小表示 codeburn report 対話的なダッシュボード（TUI） codeburn doctor プロバイダごとの検出状況。パス・件数・パース健全性 codeburn models モデル別のトークンとコストの表 このうち最初に打つべきは doctor だと考えている。理由は次節で述べる。 主要コマンドの役割。導入直後はdoctorで「自分の環境で何個埋まるか」を先に確認するのが遠回りに見えて早い 集計以外に載っている機能——予算・最適化・MCP --helpを読むと、codeburnは単なるレポート表示にとどまらない機能を抱えている。実測環境では集計系しか動かしていないので挙動は未検証だが、何が用意されているかは把握しておく価値がある。 サブコマンド ヘルプ上の役割 budget 支出の予算を設定し、現在の支出と突き合わせる optimize トークンの無駄を見つけて具体的な修正を提示する guard Claude Code向けの任意導入・削除可能なセッション時フック（予算上限など） mcp MCPサーバ（stdio）として起動し、使用量をAIエージェントへ公開する plan サブスクリプションのプランを設定し超過を追跡する model-flat-rate 定額課金のモデルを$0として扱い、単価未設定の警告を止める 特にmodel-flat-rateとmodel-aliasのヘルプ文には、「定額課金のモデルにmodel-aliasを使うな。他モデルの従量単価に写像して支出を捏造することになる」という趣旨の注意書きが明示されている。コスト計算ツールとして、数字を作ってしまう操作に自分から釘を刺している点は好感が持てる。 「41ツール対応」を数える——面によって数字が違う READMEは「across 41 tools and agents」と書く。この数はコード側と一致するのか。src/providers/index.tsの登録簿を数えた。 登録は2種類に分かれている。常時読み込む配列と、失敗しても落ちないよう遅延読み込みする名前リストだ。 登録の種類 個数 中身 coreProviders（常時読み込み） 30 claude, cline, clineCli, codewhale, codebuff, codex, copilot, devin, droid, dsh, gemini, hermes, ibmBob, kiloCode, kiro, kimi, kimicode, lingtaiTui, mistralVibe, mux, openclaw, openclaude, openDesign, pi, omp, qwen, quickdesk, rooCode, zerostack, grok lazyProviderNames（遅延読み込み） 11 antigravity, forge, goose, cursor, opencode, cursor-agent, crush, warp, vercel-gateway, zcode, zed 合計 41 — 30＋11＝41でREADMEと完全に一致した。 さらにCLI自身もdoctor実行時に「CodeBurn doctor 41 providers」と表示するので、コード・README・実行時表示の3つは揃っている。 食い違うのはGitHubリポジトリの説明文（description）だけで、こちらは「across 37 tools and agents」のまま止まっていた。READMEを更新したときに説明文の更新が漏れた形である。リポジトリの「顔」として最初に読まれるのは説明文なので、数字を引用するときはREADMEとコードのどちらかを見たほうがよい。 余談だが、この41本の中にはdsh——DeepSeek Harness——も含まれている。エージェント・ハーネス側の新顔に... --- ## trippyとは｜mtr コマンド相当をsudoなしで動かすRust製ネットワーク診断TUIを実測検証 - URL: https://ai-heartland.com/tool/trippy-mtr-command/ - 更新日: 2026-09-01 - カテゴリ: tool - 概要: mtr コマンドの代替として使えるRust製TUI「trippy」を実測。macOSでは -u を付けるとICMP/UDP/TCPすべてsudoなしで動く一方、Paris・Dublin方式とdot/flows出力は使えなくなる。リリースが16か月止まっている理由も含めて確かめた。 - タグ: automation, ネットワーク, Rust, TUI traceroute は経路を1回なぞって終わりで、mtr は連続計測できるがmacOSには同梱されていない——このすき間を埋めるのが trippy（コマンド名 trip）だ。mtr コマンドの置き換えを探しているなら、Rust製で単一バイナリ・macOSではsudoなしで動くという点が効いてくる。この記事では0.13.0の公式ビルドを落として、権限まわり・出力形式・素のtracerouteとの差を手元で測った。 trippyのTUIデモ（出典: fujiapple852/trippy の 0.12.0 デモGIF。0.13.0でDSCP/ECN列が追加されているため現行版とは列構成が一部異なる） この記事のポイント ・正体：mtrに着想を得たRust製ネットワーク診断TUI。★7,615・Apache-2.0・2022-03-28開始（数値は2026-09-01時点） ・実測の核：macOSでは -u を付けるとICMP・UDP・TCPの3プロトコルすべてがsudoなしで動いた。付けないと3つとも privileges are required で止まる ・代償：非特権モードではParis方式・Dublin方式が拒否され、それを前提とする dot / flows 出力も使えない ・非特権はmacOS限定：公式ドキュメントが明言。Linux・Windows・FreeBSD・NetBSDでは従来どおり権限が要る ・版のずれ：配布される最新タグは0.13.0（2025-05-05）だが、masterは226コミット先行で 0.14.0-dev ※ 本記事の計測はすべて ループバック（127.0.0.1）と筆者自身が管理する家庭内ルーター（デフォルトゲートウェイ） に対してのみ実行した。ネットワーク診断ツールを他者の管理する機器やネットワークへ向けないこと。 計測結果をJSON・CSVで機械可読に吐けるので、監視やCIへ組み込む前提でも選べる。自動化ツール全体の見取り図はAI自動化ツール｜ノーコードからコードまで2026年版の比較と選び方にまとめてある。 trippyとは——traceroute と mtr コマンドの間を埋めるRust製TUI Homebrewの説明文は「Network diagnostic tool, inspired by mtr」で、リポジトリの説明は素っ気なく「A network diagnostic tool」。実態としては、経路の特定（traceroute的）と継続計測（mtr的）を1つのTUIでやるツールだ。   traceroute（macOS同梱） mtr trippy 0.13.0 経路の特定 ○ ○ ○ 連続計測・画面更新 ✗（1回きり） ○ ○ macOSに標準搭載 ○ ✗ ✗ プロトコル UDP / ICMP / TCP ICMP / UDP / TCP ICMP / UDP / TCP sudoなしで実行 ○（setuid root） 環境依存 ○（macOSのみ・-u） ジッタ指標 ✗ 一部 4指標（JSON出力） 機械可読出力 ✗ 一部（--json等） JSON / CSV / Markdown / stream 実装 C C Rust（単一バイナリ） 対応プラットフォームはLinux・macOS・Windows・FreeBSD・NetBSDと広く、Homebrew・apt・snap・cargoなど主要な配布経路が揃っている。★7,615・fork 268で、Rust製CLIとしては十分に大きい部類だ。 インストールはmacOSならHomebrewが最短だが、公式リリースのビルド済みバイナリを落としてもいい（今回はこちらを使った）。 # Homebrew（配布されるのは 0.13.0） brew install trippy # 公式リリースのビルド済みバイナリを直接使う場合（Apple Silicon） curl -LO https://github.com/fujiapple852/trippy/releases/download/0.13.0/trippy-0.13.0-aarch64-apple-darwin.tar.gz tar xzf trippy-0.13.0-aarch64-apple-darwin.tar.gz ./trippy-0.13.0-aarch64-apple-darwin/trip --version # → trip 0.13.0 配布の広さも実測しておく。0.13.0のリリースには17個のアセットが付いており、対応の広さがそのまま並んでいる。 プラットフォーム 配布されるもの macOS aarch64-apple-darwin / x86_64-apple-darwin の tar.gz Linux x86_64・aarch64 の gnu / musl、armv7 の gnueabihf / musleabi / musleabihf Windows x86_64 の msvc / gnu、aarch64 の msvc（zip） FreeBSD / NetBSD x86_64 の tar.gz パッケージ .rpm ×1、.deb ×2（gnu / musl） armv7のmusl系まで3種類ぶん用意されているあたりに、ルーターやSBCで動かす想定が透けている。Rust製で単一バイナリなので、ランタイムを別途入れる必要はない。 TUIのメイン画面（出典: fujiapple852/trippy 公式リポジトリの assets/0.12.0/main_screen.png） 実測：macOSなら -u でsudoなしに動く trippyの最大の実用上の差は、権限まわりにある。生ソケット（raw socket）を使うツールは通常root権限が要るが、trippyには非特権モードがある。手元のmacOS（Apple Silicon）でプロトコル3種 × -u の有無、計6通りを実際に叩いた。 どの経路で権限問題を解くかは、OSと目的で機械的に決まる。 flowchart TD A["trippy を動かしたい"] --> B{"OS は macOS か"} B -->|"はい"| C{"多重経路 (Paris/Dublin) が要るか"} B -->|"いいえ"| D{"Linux か"} C -->|"不要"| E["-u で非特権のまま実行ICMP・UDP・TCP すべて可"] C -->|"必要"| F["sudo trip または setuid"] D -->|"はい"| G["setcap CAP_NET_RAW+p を付与生ソケット作成後に権限を落とす"] D -->|"いいえ (Windows/BSD)"| H["管理者権限・root で実行非特権モードは非対応"] # 対象は自分のループバックまたは自分が管理するルーターに限定すること GW=$(route -n get default | awk '/gateway/{print $2}') # 自宅ルーターのIP # -u を付けない（既定） trip -m json -C 1 -p icmp 127.0.0.1 # → Error: privileges are required (hint: try adding -u to run in unprivileged mode) # -u を付ける（非特権モード） trip -m json -C 1 -u -p icmp 127.0.0.1 # → JSONが返る trip -m json -C 1 -u -p udp 127.0.0.1 # → JSONが返る trip -m json -C 1 -u -p tcp 127.0.0.1 # → JSONが返る 2026-08-31 JST・macOS 23.5.0 / arm64 での実測。6通りすべてを個別に実行した 結果は明快で、-u なしは3プロトコルとも privileges are required、-u ありは3プロトコルとも成功した。エラーメッセージ自体が -u を案内してくるので迷いにくい。 これは公式ドキュメントの記述とも一致する。Privilegesガイドは、非特権モードがICMP・UDP・TCPのすべての計測モードで使えること、ただし対応プラットフォームは限られることを明記している。 ・macOSのみ対応。Linuxは「将来追加される可能性がある」段階 ・NetBSD・FreeBSD・Windowsは非対応。理由は IPPROTO_ICMP ソケット型をこれらのOSがサポートしないため ・非特権モードを使わない場合の権限付与は3通り——sudo trip、setuidビットを立てる、Linuxなら sudo setcap CAP_NET_RAW+p $(which trip) ・Linuxでcapabilityを使う場合、trippyは生ソケット作成後に全capabilityを落とす設計になっている Linux運用なら setcap CAP_NET_RAW+p が現実的な落とし所だ。sudo trip には設定ファイルの置き場所がroot側になるという副作用があり、公式も -c（--config-file）で明示するよう注意している。 非特権モードで失われるもの——Paris/Dublinとdot/flows出力 「sudoなしで全... --- ## zoxide代替候補cdaiとは｜AIに存在しないパスを作らせない設計を偽バックエンド6通りで実測検証した - URL: https://ai-heartland.com/tool/cdai-zoxide-alternative/ - 更新日: 2026-09-01 - カテゴリ: tool - 概要: zoxideの代替を探すとき、AI搭載を名乗るcdaiは「AIに勝手なパスを作らせない」と書く。本記事はその一文を偽AIバックエンド6通りに差し替えて実測した。存在しないパス・rootの外・候補外の実在ディレクトリはすべて拒否され、AIは生成側でなく選択側に閉じ込められていた。 - タグ: devops, automation, CLI, シェル, オープンソース, TypeScript cd を賢くするツールを探すと、まず zoxide に行き着く。訪問履歴の重み付け（frecency）で cd doc から目的のディレクトリへ飛ぶ、という発想はもう定番だ。そこへ2026年8月27日、AIフォールバックを足した cd 置き換え「cdai」が現れた。売り文句は歯切れがいい——「AIには存在しないパスを作らせない（not allowed to invent a path）」。 この一文は、紹介記事では検証されないまま引用されやすい。だが幸いこれは実測できる主張である。cdaiのAIバックエンドは「JSONを標準出力に出す任意のコマンド」でしかないため、自分で嘘をつく偽AIを書いて差し替えられる。本記事ではAIバックエンドを6通りの偽物に置き換え、存在しないパス・rootの外・候補に無い実在ディレクトリを返させて、どこで止まるかを1件ずつ確かめた。 本記事の中心的な実測結果。AIバックエンドを自作の偽物に差し替え、6通りの応答を返させた。採用されたのは「あらかじめ提示された候補リストの要素」だった1件のみ。残る5件はすべて拒否された（cdai v0.3.1 / 2026-09-01実測） CLIツールをAIで補強する流れ全体の見取り図は、AI自動化ツール｜ノーコードからコードまで2026年版の比較と選び方にまとめてある。本記事はその中の1本を、設計の当否が分かる粒度まで掘り下げる。 30秒でわかるcdai ・正体：cd を置き換えるシェル統合コマンド。ネイティブの cd をまず試し、外れたときだけ独自のインデックスとfrecencyで解決する ・zoxideとの差：zoxideが「訪問済みディレクトリの記憶」なのに対し、cdaiは未訪問のディレクトリも事前インデックスで探せる。さらに曖昧な言い回し用のAIフォールバックを持つ ・AIの権限：生成ではなく選択。決定的な処理が作った候補リストの要素以外は、実在するディレクトリであっても拒否される（本記事で6通り実測） ・AIが呼ばれない条件：端末（TTY）が無いとき、候補が0件のとき、ai.enabled が false のとき。既定経路とTab補完は常にモデル非依存 ・現時点の規模：GitHub star 1、初回コミット2026年8月27日、コミット19件、タグは v0.3.1 のみ、npm未公開。本番導入を勧められる成熟度ではない cdaiとは——zoxideと何が違うのか cdaiはNode.js製のCLIで、cd の完全な置き換えを狙う。ライセンスはMIT、作者はFranz Enzenhofer氏。2026年9月1日時点の実測値は以下のとおりだ。 項目 実測値（2026-09-01） GitHub star 1 fork 0 初回コミット 2026-08-27 最終push 2026-08-31 コミット総数 19 タグ v0.3.1 のみ ライセンス MIT 言語 TypeScript（配布は単一JSバンドル） npmレジストリ 未公開（private: true） star 1・公開5日という数字は率直に受け止めるべきで、いま乗り換えを検討する段階のツールではない。それでも取り上げる価値があるのは、後述するAIの権限設計が、LLMを既存コマンドに埋め込むときの一般解として使える形をしているからだ。 zoxideとの関係を機能軸で並べると次のようになる。cdaiのREADMEは明確にzoxideを意識しており、cdai import zoxide というzoxideのデータベース取り込みコマンドまで用意されている。 観点 zoxide cdai 基本方式 訪問履歴のfrecency ネイティブ cd 優先 → インデックス＋frecency 未訪問ディレクトリ 原則たどれない 事前インデックスで探せる（root指定＋深さ） 曖昧な言い回し 対象外 AIフォールバック（任意・既定は確認プロンプト付き） latest / 年指定 対象外 モデル非依存で解釈 実装 Rust（ネイティブバイナリ） Node.js（単一JS・要Node 20+） 実行時依存 なし npm依存ゼロ（標準モジュールのみ・本記事で確認） 実績 広く使われている star 1・公開5日 差が一番はっきり出るのは「未訪問ディレクトリ」の行だ。zoxideは一度 cd した場所しか覚えないので、新しく clone したリポジトリには最初は飛べない。cdaiは roots に指定したディレクトリを深さ付きで走査してインデックスを作るため、一度も訪れていない場所でも候補になる。この設計はAIとは無関係の、決定的な部分の差である。 AI無しで何ができるか——決定的機能だけを実測する 「AI搭載」を名乗るツールは、AIを切ったときに何が残るかで実力が分かる。cdaiの決定的機能だけを、AIバックエンドを呼ばせずに一通り叩いた結果が次の表である。いずれもモデルを一切経由していない。 入力 実測結果 AI関与 petal .../clients/petalworks へ解決 なし latest petalworks folder petalworks-2026（更新時刻が最新の子） なし oldest petalworks folder petalworks-2024 なし petalworks 2025 petalworks-2025 なし petalworks 2024 petalworks-2024 なし tictac（一度も訪れていない） tictactoe-3d と tictactoe-web を候補提示 なし asanakti（タイポ） 決定できずAI段へ委譲 あり 注目すべきは tictac の行だ。この2つのディレクトリには一度も cd していないが、roots の走査でインデックスに入っているため候補に出る。訪問履歴に依存するzoxideでは原理的にできない挙動で、ここがcdaiの実質的な差別化点である。AIではなく、事前インデックスという決定的な仕組みが効いている。 latest / oldest / 年指定も同様にモデル非依存で、更新時刻とディレクトリ名から解釈される。AIを --no-ai で完全に切っても、上表のうちタイポの1行以外はすべて動く。 逆に言えばAIが担当しているのは「決定的な処理では絞り切れなかった残り」だけで、その範囲は実測してみるとかなり狭い。 インストールと初期設定——npmレジストリには無い READMEが推奨するのはHomebrew tapで、npmは補助経路として書かれている。ここで注意点が1つある。パッケージ cdai はnpmレジストリに存在しない。 # npmレジストリに問い合わせると Not found が返る（2026-09-01 実測） curl -s https://registry.npmjs.org/cdai # => {"error":"Not found"} package.json にも "private": true が入っており、レジストリ公開を明示的に止めている。READMEの npm install -g github:franzenzenhofer/cdai はレジストリ経由ではなくGitHubリポジトリを直接指す記法で、これは正しく動く。READMEの書き方自体は誤っていないが、「npmで入る」と読み替えると npm install -g cdai で失敗するので、そこだけ補っておく。 推奨経路は次のとおり。なおこのbrewコマンドについては、tapリポジトリに Formula/cdai.rb（3,662バイト）が実在し、class Cdai < Formula として v0.3.1 のtarballを参照していることまで確認した（インストール自体は手元の環境を変更するため実行していない）。式の中では外部のNode 20+をPATHから探す独自Requirementが定義されており、READMEの「既存のNodeを再利用する」という記述と実装が一致している。 # 推奨：Homebrew tap brew install franzenzenhofer/tap/cdai # シェル統合を有効化（zshの例）。bashは bashrc、fishは cdai init fish | source echo 'eval "$(cdai init zsh)"' >> ~/.zshrc exec "$SHELL" # 対話なしで初期設定（rootと深さを指定し、AIは切っておく） cdai setup --root "$HOME/dev" --depth 3 --yes --no-ai 導入後の状態確認には cdai doctor がある。実測した出力は、rootごとの可否・インデックス件数と鮮度・AIバックエンドの有無・fzfとTTYの有無まで1画面に出る。設定ファイルの権限まで privacy 行で見ているのは良い設計だ。 $ cdai doctor cdai doctor node v22.13.1 config ok /tmp/cdai-demo/.config/cdai/config.json roots 2 ok /private/tmp/cdai-demo/dev (depth 2) ok /private/tmp/cdai-demo/Dropbox/clients (depth 3) ai enabled v... --- ## codebase-memory-mcpとは｜複数AIエージェントが索引を共有するMCPサーバー - URL: https://ai-heartland.com/mcp/codebase-memory-mcp/ - 更新日: 2026-09-01 - カテゴリ: mcp - 概要: codebase-memory-mcpは、コードベースをtree-sitterで解析し永続的なグラフへ索引化するMCPサーバー。Session Coordination Daemonで複数のAIエージェントが1つの索引を共有する仕組みと、実際に索引化して測った所要時間を解説する。 - タグ: MCP, codebase-memory-mcp, コード検索, tree-sitter, ナレッジグラフ codebase-memory-mcp（開発元: DeusData、GitHub ⭐39,699）は、コードベースをtree-sitterで解析して永続的なグラフに索引化し、Claude Code・Codex CLI・OpenCodeなど複数のAIエージェントに検索・追跡ツールをMCP経由で渡すサーバーだ。多くのMCPコード検索サーバーが「毎回ファイルを読み直す」都度読み込み型なのに対し、本OSSは索引を常駐デーモンに保持し、複数のエージェントセッションが同じグラフを共有する。この記事では、その仕組みと、実際にインストール・索引化して測った実測値を、公式リポジトリと実機検証だけを根拠に整理する。 codebase-memory-mcp付属のグラフ可視化UI（デフォルトでポート9749）。出典: DeusData/codebase-memory-mcp 公式README 30秒でわかる codebase-memory-mcp（2026年9月時点） ・正体：DeusData製のMCPサーバー。tree-sitterで158言語を解析し、コードベースをSQLite/Cypher風の永続グラフへ索引化する ・何ができる：index_repositoryで索引化した後、search_code・trace_pathなど15種のMCPツールで定義検索・呼び出し追跡・アーキテクチャ俯瞰ができる ・何が他と違う：Session Coordination Daemonという常駐プロセスが索引を保持し、Claude Code・Codex CLIなど43のクライアントsurfaceが同じ索引を共有できる ・実測：本記事の検証環境でこの ai-archive-jp リポジトリ自体を索引化したところ、約22秒でノード29,426・エッジ41,576のグラフが生成された ・注意：最新版はv0.10.8とpre-1.0。ライセンスはMIT MCPサーバーの実装そのものを一から学びたい場合は MCPサーバーの作り方2026年完全ガイド：TypeScript・Python両対応チュートリアル を参照してほしい。本記事はその応用として、コードベースを永続的な知識グラフに変える具体的なMCPサーバーを1本掘り下げる。 codebase-memory-mcpとは何か｜pre-1.0のtree-sitter索引エンジン codebase-memory-mcpは、GitHubリポジトリ DeusData/codebase-memory-mcp として公開されているMCPサーバーだ。GitHub API実測で⭐39,699・フォーク3,191（フォーク/スター比は約8%で、star買いなど不自然な増幅の兆候は見られない）。ライセンスはMITで、LICENSEファイルの記載とREADMEの宣言も一致している。 主要言語はC言語（GitHub API language フィールド）で、tree-sitterの文法定義を158言語分バイナリに同梱している。コードベースを解析した結果はSQLiteベースのストレージにCypher風クエリで問い合わせられるグラフとして保存される。開発は非常に活発で、直近30日のコミット数はGitHub APIのページング上限（100件）に張り付いており正確な総数は取得できないほど。contributor数もAPI上限の100名を超えている。バージョニングは30本のリリースを経て最新はv0.10.8（2026-08-19公開）、本記事執筆時点のpushed_atは2026-08-20と、当日プッシュがある現役開発中のプロジェクトだ。 ・何ができる：コードベース全体をグラフとして索引化し、エージェントがMCPツール経由で検索・追跡できるようにする ・何を解決する：エージェントがコードを理解するたびに全文を読み直す非効率（トークン消費・レイテンシ） ・何を代替できる：ファイル読み込み・grep型の素朴なMCP検索サーバー。ただし後述の通り、永続グラフや複数エージェント間の共有まで持つ設計は同種のOSSでも珍しい 一点注意したいのは、開発元「DeusData」が企業なのか個人／小規模チームのハンドルなのかは、GitHub Organizationの情報以上には確認できていない。ホームページ（deusdata.github.io）もGitHub Pagesで公開されたOSSプロジェクトサイトの体裁であり、商用サポートの記載はREADMEの範囲では見当たらなかった。 こうした「コードベースをグラフ化してエージェントに渡す」設計は、MCP コードインテリジェンスやMCP コード検索という文脈で語られることが多く、Claude Code コードベース記憶という使い方をされることもある。tree-sitter MCPという括りで見た場合、158言語という対応の広さも本OSSの特徴の一つだ。 バス係数（bus factor）の観点でも、contributor数100超・直近30日のコミット100件超（いずれもGitHub APIのページング上限に達するほど）という活発さから、特定の1人に開発が集中している様子は見られない。個人プロジェクトが失速して止まるリスクに比べると、継続性の観点では安心材料と言えそうだ。 実機でconfig listを確認するとui_enabledはデフォルトでtrue、ui_portは既定9749になっており、索引化したコードベースをブラウザで見られるグラフ可視化UIが標準で立ち上がる設定になっている。本記事冒頭のスクリーンショットはこの可視化UIで、索引化されたコードベースの構造がノードとエッジのグラフとして描画されている。 Session Coordination Daemon｜43クライアントが1つの索引を共有する仕組み codebase-memory-mcpの技術的な核心は、README・公式CLIヘルプで「Session Coordination Daemon」と呼ばれる常駐プロセスだ。バイナリの--help出力を実機で確認したところ、「自動／条件付きで対応するクライアントsurface」として43種が列挙されていた：Claude Code・Codex CLI・Gemini CLI・Zed・OpenCode・Antigravity・Aider・KiloCode・VS Code・Cursor・Windsurf・Augment/Auggie・OpenClaw・Kiro・Junie・Hermes・OpenHands・Cline・Warp・Qwen Code・GitHub Copilot CLI・Factory Droid・Crush・Goose・Mistral Vibe・Qoder CLI・Kimi Code CLI・GitLab Duo CLI・Rovo Dev CLI・Amp・Devin CLI/Local・Tabnine・Continue/cn・Visual Studio・TRAE・Roo Code・Amazon Q Developer IDE・CodeBuddy Code CLI・IBM Bob IDE・IBM Bob Shell・Pochi・Pi・Sourcegraph Cody。これに加えて、Qodo・Warp・JetBrains AI/ACP・Replit・Plandex・SWE-agent・BLACKBOX・GitHub cloud agents・Jules・CodeRabbitは「手動／UI経由のMCP境界」として別枠で挙げられている。エージェント界隈のほぼ主要どころを網羅する対応範囲の広さが、複数エージェント共有という設計と噛み合っている。 flowchart LR A["コードに変更が入るgit commit等"] --> B{"auto_watch は有効か？"} B -- "true（既定値）" --> C["Session CoordinationDaemonが差分を検知"] C --> D["tree-sitterで再解析しグラフ索引を更新"] D --> E["Claude Code / Codex CLI /OpenCode等が同じ索引を参照"] B -- "false" --> F["index_repositoryを手動で再実行するまで古いまま"] codebase-memory-mcpの構成イメージ（本記事作成・実機検証結果に基づく自作図） 実機でconfig listを実行すると、デフォルト値は次の通りだった（検証環境: Linux amd64、バイナリ配布版 v0.10.8）。 Configuration: auto_index = false auto_index_limit = 50000 auto_watch = true ui-lang = auto ui_enabled = true ui_port = 9749 設定名から読み取れる範囲では、auto_watch（既定でtrue）はgitの変更を監視して索引を追従させる仕組み、auto_index（既定でfalse）は初回の索引化を自動では行わない設定だと考えられる。いずれも実機で確認した「値」であり、内部動作の詳細な仕様までは本記事では踏み込まない。 MCPツールは--helpの出力で数え上げると次の15種類だった：index_repository・search_graph・query_graph・trace_path・g... --- ## LLM Wikiとは｜Karpathyの知識コンパイル手法・RAGとの違い・OSS実装の選び方を実測 - URL: https://ai-heartland.com/explain/llm-wiki/ - 更新日: 2026-09-01 - カテゴリ: explain - 概要: llm wikiとは、Andrej Karpathyが2026-04-04のgistで示した「知識をその都度検索せず、LLMに恒久的なMarkdown Wikiとしてコンパイルさせる」手法。RAGとの違いと、実装候補が同名で乱立している現状、実際に作る手順を実測で整理する。 - タグ: rag, ナレッジベース, Markdown 2026年4月にAndrej Karpathyが公開した1枚のgistをきっかけに、日本語圏でも「llm wiki」という言葉の検索が跳ね上がった。LLM Wikiとは、知識を質問のたびに検索し直すのではなく、LLMに恒久的なMarkdownのWikiとしてコンパイルさせて残すという考え方だ。この記事では原典のgistが実際に何を言っているかを確認し、RAGとの違いを整理したうえで、実装候補として inkeep/open-knowledge を手元に入れて動かした結果まで載せる。 LLM Wiki向けエディタの一例。OpenKnowledgeの公式ヒーロー画像（出典: inkeep/open-knowledge） この記事のポイント ・原典：Karpathyのgist llm-wiki（2026-04-04公開）。生ソース／Wiki／スキーマの3層と、ingest・query・lintの3操作で構成される ・RAGとの違い：RAGは「毎回検索し直す」、LLM Wikiは「一度コンパイルして残す」。Karpathyは「面倒なのは読むことでも考えることでもなく、帳簿づけ（bookkeeping）だ」と書いている ・実装は乱立：GitHubに llm-wiki 系リポジトリが多数あり、★17,160のものから★700台まで並ぶ。star順に選ぶと目的が合わない ・実測：OpenKnowledge v0.66.2 はNode 24+必須。Node 22だと警告なしで4か月前の v0.2.0 が入り ok コマンドが存在しない ・コスト：同梱MCPサーバーは21ツールで 58,460トークン（Anthropic count_tokens）。当サイト計測の8サーバー中で最大 RAG側の全体像を先に押さえたい場合は、RAGとは？仕組み・構築・ベクトルDB選定までの2026年実装マップを読んでから戻ってくると、この記事の比較が立体的になる。 LLM Wikiとは——Karpathyのgistが実際に書いていること 原典は gist.github.com/karpathy/llm-wiki。GitHub APIで確認したところ作成日は2026-04-04 16:25 UTCで、ファイルは llm-wiki.md 1枚だけだ。特定の製品でもライブラリでもなく、書き方のパターンを1ページにまとめた「アイデアファイル」である。 中核の主張はこうだ。生の文書とユーザーの間に、LLMが書いて維持する恒久的で積み上がる成果物（persistent, compounding artifact）としてのMarkdown Wikiを置く。質問のたびに文書を検索するのではなく、Wikiを少しずつ作り育てる。 gistが示す3層。素材は書き換えず、成果物であるWikiを育てる ・生ソース（raw sources）：記事・論文・画像など。書き換えない。原文のまま保存する ・Wiki：LLMが生成したMarkdown。要約・登場する固有名詞（エンティティ）・相互参照を持つ ・スキーマ：Wikiをどんな構造にし、どう運用するかを書いた設定文書 そして操作は3つ。 操作 何をするか ingest（取り込み） 新しいソースを処理し、要点を抽出して関連するWikiページを更新する。1つのソースで10〜15ページに波及することもある query（問い合わせ） Wikiのページを検索し、出典つきで回答を合成する。得られた知見を新しいページとして書き戻すこともできる lint（点検） 矛盾・古くなった記述・どこからもリンクされていない孤立ページ・欠けている相互参照を洗い出す gistの中で最も引用されている一文は、知識ベース運用の本質を突いている——知識ベースを維持するうえで面倒なのは、読むことでも考えることでもなく、帳簿づけ（bookkeeping）の部分だ、と。そしてLLMはまさにその帳簿づけが得意なので、個人でも知識の継続的な整理が現実的になる、という論理構成になっている。 公開後の反応も大きく、gistは公開から2週間で5,000スター超・4,000以上のフォークに達したと各所で報じられた。日本語圏でも llm wiki の月間検索ボリュームは2026年3月の140から4月に12,100へ跳ね、以降1万前後で推移している（DataForSEO実測・日本／日本語）。gistの公開日と検索の立ち上がり月が一致しているため、この語の需要はKarpathyの投稿が起点だと言い切ってよい。 検索需要の推移も、この経緯と矛盾しない。DataForSEO（日本／日本語）で llm wiki の月別ボリュームを取ると次の通りで、gistが出た月に2桁から5桁へ跳ねている。 月 月間検索数 2025-11〜2026-03 90〜170（横ばい） 2026-04（gist公開） 12,100 2026-05 9,900 2026-06 12,100 2026-07 9,900 派生する llm wiki とは（90）・llm wiki 作り方（40）も計測されており、「言葉は知ったが、中身と作り方が分からない」層が実在することが数字にも出ている。以下ではその2つに順番に答えていく。 RAGとの違い——「毎回検索する」か「一度コンパイルして残す」か LLM Wikiの説明でいちばん誤解されやすいのが、RAGの置き換えなのか、上位互換なのか、という点だ。gistの立場ははっきりしていて、違いは知識が残るかどうかにある。 同じ「LLMに社内文書を答えさせる」でも、知識の置き場所が違う flowchart LR S["生ソース記事・論文・PDF"] -->|"RAG: 質問のたびに検索"| Q1["回答"] S -->|"LLM Wiki: 取り込み時にコンパイル"| W["Wiki相互リンク済みMarkdown"] W -->|"以後はWikiに問う"| Q2["回答＋出典"] Q2 -.->|"知見を書き戻す"| W RAGは質問時に検索するので、同じ論点を100回聞けば100回検索が走り、100回とも同じ整理をやり直す。LLM Wikiは取り込みの時点で要約と相互リンクを作ってしまうので、2回目以降の質問はすでに整理された成果物の上から始まる。ページ間の矛盾や陳腐化も、成果物があるからこそlintで検出できる。 一方で、この構造には代償もある。公平を期すために両方書いておく。   RAG LLM Wiki 知識の置き場所 元文書＋ベクトルインデックス 生成されたMarkdownファイル群 取り込み時のコスト 埋め込み生成のみで軽い LLMに読ませて書かせるため重い（1ソースで複数ページ更新） 質問時のコスト 毎回検索＋文脈投入 整理済みのページを読むだけ 元文書の更新への追随 再インデックスすれば済む 派生ページを作り直す必要があり、追随が難しい 出典の追跡 検索結果がそのまま根拠 Wikiページに出典を書き込む運用が要る 破綻の仕方 検索が外れて答えられない Wikiに嘘が定着し、以後それを根拠に答え続ける 最後の行が実務上いちばん重い。RAGの失敗は「答えられない」で済むが、LLM Wikiの失敗は誤りが成果物として固定され、下流の全ページに伝播する。lintがオプション扱いでなく必須の運用工程として設計されているのはこのためだ。RAGの発展形との住み分けを整理したい場合は、RAGの進化｜Naive・Advanced・Graph・Agentic RAGの仕組みと選び方が比較の軸になる。 実装が同名で乱立している——star順に選ぶと目的が合わない 「じゃあ何で作るのか」で最初につまずく。gistがツールを指定していないため、同じ llm-wiki という名前のOSSが大量に生まれたからだ。GitHubのリポジトリ検索（star降順）で上位を並べると次のようになる（2026-09-01時点）。 リポジトリ ★ 何をするものか nashsu/llm_wiki 17,160 クロスプラットフォームのデスクトップアプリ SamurAIGPT/llm-wiki-agent 3,472 自分で構築・保守する個人知識ベース sdyckjq-lab/llm-wiki-skill 2,396 Karpathy方式をなぞるAgent Skill（中国語） Astro-Han/karpathy-llm-wiki 2,097 Claude Code / Cursor / Codex 向けのAgent Skill atomicstrata/llm-wiki-compiler 1,982 生ソースを入れて相互リンク済みWikiを出すコンパイラ nvk/llm-wiki 1,166 任意のAIエージェント向けの知識ベース生成 kytmanov/obsidian-llm-wiki-local 814 Obsidian＋Ollamaで100%ローカル運用 カテゴリが全然違うものが同じ名前で並んでいる点に注意したい。デスクトップアプリ・Agent Skill・CLIコンパイラ・Obsidianプラグインが混在していて、star数の大小は「自分の用途に合うか」を何も教えてくれない。選ぶ軸は次のどれを重視するかで決まる。 ・手元のエディタを変えたくない：Agent Skill型（karpathy-llm-wiki など）。既存のMarkdownフォルダにルールだけ足す ・Obsidianの金庫がすでにある：Obsidianプ... --- ## Scientific Agent Skillsとは｜163本の科学スキルを実測、常駐コストとライセンス - URL: https://ai-heartland.com/tool/scientific-agent-skills/ - 更新日: 2026-08-31 - カテゴリ: tool - 概要: Scientific Agent Skills は K-Dense が公開する科学研究向けの Agent Skills 集（★40,304）。163本のSKILL.mdを全部取得して数え直し、全部入れたときの常駐コストを2つのトークナイザで実測し、リポジトリ表記がMITでも個別スキルが別ライセンスを宣言している箇所を洗い出した。 - タグ: claude-code, SKILL.md, agents, Codex 「AIエージェントを科学研究に使う」と言ったとき、実務で詰まるのはモデルの賢さではなく、その分野のライブラリとデータベースをエージェントが正しく叩けるかだ。Scientific Agent Skills は、その手順書を163本ぶんまとめて配っているリポジトリで、GitHub star は 40,304（2026-08-31 時点）に達している。ただし「全部入れる」を選ぶ前に測っておくべき数字がいくつかある。 163本のSKILL.mdを全取得して数え直した結果（2026-08-31 実測） 30秒でわかる Scientific Agent Skills ・科学研究向けの Agent Skills を163本まとめた MIT ライセンスのリポジトリ（★40,304・K-Dense 提供） ・スキル数は実測163本。README の記載とも一致するが、GitHub の説明文だけ「165」のまま残っている ・全部入れると説明文だけで cl100k_base 14,972 トークン／count_tokens 25,441 トークンが毎セッション常駐する ・1本あたり 91.9 トークン（cl100k_base）。汎用スキル集を同じ物差しで測った 40.7／38.6 の約2.3倍 ・リポジトリは MIT だが、SKILL.md 個別の license: は28通りに割れ、非商用・GPL・Proprietary 表記が10本ある Claude Skills そのものの仕組みから確認したい場合は、Claude Code｜2026年版・インストールからCLAUDE.md・Hooks・本番運用までの実装手引きに全体像がまとまっている。本記事はその上で「特定分野のスキルを大量に入れるとどうなるか」を実測する。 この記事のポイント ・スキル数・常駐コスト・ライセンス分布を、READMEの記載ではなく163本のSKILL.mdから数え直した ・同梱のセキュリティスキャン結果は「自動出力＋人手の triage」の2段構えで、読むべきは後者 ・「全部入れる」より「分野で絞る」がリポジトリ自身の推奨。その根拠になる数字を出した Scientific Agent Skillsとは——163本の分野別手順書 Agent Skills は SKILL.md 1枚（＋任意の scripts/ や references/）を1つのフォルダに置くだけの、ホスト非依存の拡張形式だ。Scientific Agent Skills はこの形式で、生物・化学・医学・材料・宇宙・量子計算などの領域を1本ずつカバーしている。 構造はきれいにフラットで、skills/<名前>/SKILL.md が163本、それ以外の場所に SKILL.md は1本もない。手元で数えるならこれだけで足りる。 git clone --depth 1 https://github.com/K-Dense-AI/scientific-agent-skills.git cd scientific-agent-skills find skills -maxdepth 2 -name SKILL.md | wc -l # => 163 中身の傾向を挙げると、rdkit・scanpy・biopython・qiskit・pymatgen のようなPythonパッケージの使い方、depmap・primekg・imaging-data-commons のような公開データベースへのアクセス、literature-review・peer-review・research-grants のような研究作業そのものの3系統に大きく分かれる。README は「78の公開データベースへ決定論的にアクセスする統合スキル database-lookup がある」と書いており、bioservices（約40サービス）・biopython（Entrez 経由39サブDB）・gget（20以上）を合わせて「100+ データベース」と表現している。 系統 例 何をしてくれるか Pythonパッケージ rdkit scanpy qiskit pymatgen バージョンを踏まえた正しい API の呼び方を提示 公開データベース database-lookup depmap primekg 出典つきで決定論的に引く手順を提示 研究作業 literature-review peer-review experimental-design 手順そのものをエージェントに実行させる ドキュメント生成 latex-posters scientific-slides pptx-posters 論文・ポスター・スライドの体裁を作る 実測①：スキル数は163本、GitHubの説明文だけ165のまま リポジトリ説明文（About 欄）は「165 ready-to-use validated skills」と書いているが、実体は163本だった。README 側は badge（Skills-163）・本文2か所・引用用 BibTeX の note まですべて163で一致しているので、ずれているのは GitHub の About 欄だけだ。 数字がずれること自体は運用の速さの裏返しでもある。plugin.json のバージョンは 2.65.0、当日もコミットが入っている。ただ、About 欄は検索結果やSNSカードに出る面なので、外向きの数字と実体が食い違っている状態は把握しておいたほうがよい。 163本のSKILL.mdが宣言する license: の内訳（表記ゆれを正規化して集計・2026-08-31 実測） Scientific Agent Skills の実測②：163本を全部入れると常駐コストはいくらか Agent Skills は、本文（SKILL.md の中身）はスキルが呼ばれたときに読まれるが、name と description は「どのスキルを呼ぶか」を判断するために毎セッション常駐する。つまり入れた本数ぶんだけ固定費が乗る。 163本すべての frontmatter を取得し、name: X と description: Y を連結した文字列を測った結果が下の表だ。これは当サイトが他のスキル集にも当てている物差しと同じ定義なので、そのまま横並びにできる。 スキル集 本数 ペイロード cl100k_base 1本あたり Scientific Agent Skills 163 71,106 B 14,972 91.9 Skills Hub の Explore カタログ 280 55,370 B 11,388 40.7 mattpocock/skills 37 — 1,428 38.6 1本あたり 91.9 トークンは、汎用スキル集の約2.3倍にあたる。理由は description を読めばすぐ分かる。科学スキルの説明文は「いつ発火すべきか」を分野語彙で細かく列挙する必要があるからだ。たとえば adaptyv の description は、Adaptyv Bio の Foundry API・タンパク質結合アッセイ・BLI/SPR アッセイ・熱安定性アッセイといった発火条件に加えて、adaptyv_sdk や FoundryClient を import したときにも発火せよ、と書いている。汎用スキルの「PDFを扱うとき」に比べて、書くべきトリガーの数が桁違いに多い。 Anthropic の count_tokens（モデル claude-sonnet-5）で同じペイロードを測ると 25,441 トークンだった。cl100k_base 比で1.70倍で、当サイトがこれまで MCP のツール定義で観測してきた1.35〜1.65倍の帯よりやや上に出ている。同日に同じ手順で測った素の英語文（約20 KB）でも1.80倍だったので、科学用語のせいというより、この2つのトークナイザの差そのものが英語散文で大きく出ると読むのが妥当だ。いずれにせよ数字を引用するときはトークナイザ名を併記しないと比較できない。 上位と下位の差も大きい。もっとも重い analytical-method-validation は単体で296トークン、もっとも軽い primekg は35トークンで、8.5倍の開きがある。 重い順 トークン 軽い順 トークン analytical-method-validation 296 primekg 35 pkpd-modeling 278 geopandas 37 pathogen-variant-surveillance 260 cobrapy 41 pathway-enrichment 245 pytdc 45 genomic-coordinates 228 esm 45 手元で概算するだけなら、クローン後に次のワンライナーで足りる。frontmatter の生行をそのまま数えるので上の実測値（71,106 B）と1%ほどずれるが、桁を掴むには十分だ。 awk 'FNR==1{n=0} /^---$/{n++; next} n==1 && /^(name|description):/{print}' skills/*/SKILL.md | wc -c # => 70150 なお163本すべてを確認したが、disable-model-invocation を宣言しているスキルは1本もなかった。つまり全163本がモデルから自動起動... --- ## deepagentsとは｜LangChain公式教材で作る計画・ファイル・サブエージェント - URL: https://ai-heartland.com/agent/deepagents/ - 更新日: 2026-08-31 - カテゴリ: agent - 概要: deepagents は LangChain 公式の「バッテリー同梱」エージェント基盤。公式教材 deep-agents-from-scratch の5ノートブックが何を教えるかと、教材が固定する 0.2.7 と今 pip install で入る 0.7.11 で既定ツールが入れ替わっている事実を実測した。常駐コストも両版で数えた。 - タグ: AIエージェント, LangChain, LangGraph, Python 「エージェントを作る」と言ったとき、モデルにツールを渡してループを回すところまでは誰でもすぐ書ける。詰まるのはその先——長い作業で計画を見失う、文脈があふれる、サブタスクの調査ログで本体の会話が埋まる。deepagents は、この3点への対処を最初から載せた LangChain 公式のエージェント基盤だ。そして langchain-ai/deep-agents-from-scratch は、その中身を LangGraph だけで組み直して学ぶ公式教材にあたる。 deepagents が最初から載せている4要素と、本記事で実測した既定ツールの常駐コスト 30秒でわかる deepagents ・create_deep_agent() を1回呼ぶと、ファイル操作6本・シェル実行・サブエージェント委譲を含むツール付きのエージェントグラフが返る ・公式教材 deep-agents-from-scratch は5本のノートブックで、この中身を LangGraph だけで再実装しながら学ぶ構成 ・教材が固定するのは deepagents 0.2.7（2025-11-14）。今 pip install deepagents で入るのは 0.7.11（2026-08-28） ・実測すると両版で既定ツールが入れ替わっている。0.2.7 の既定にある write_todos は 0.7.11 の既定から消え、delete が入った ・既定ツールの常駐コストは 0.7.11 で 2,821 トークン（cl100k_base）／4,137 トークン（Anthropic count_tokens）。0.2.7 の 4,722／7,052 から4割減っている エージェント基盤の選択肢を横並びで見たい場合は、AIエージェントフレームワーク比較2026｜LangGraph・CrewAI・Dify等9種をStar数・実コードで検証に9種のフレームワークをまとめてある。本記事はそのうち LangChain 公式の系譜を1本だけ深掘りする位置づけになる。 この記事のポイント ・deepagents は LangGraph の上に計画・ファイル退避・サブエージェント委譲を載せた LangChain 公式パッケージ（★28,757・MIT） ・公式教材 deep-agents-from-scratch は 2025年11月時点の依存で固定されており、最新版とは既定ツールが1本違う ・既定ツールの常駐コストを両版・2トークナイザで実測した（0.7.11 既定＝cl100k_base 2,821 / count_tokens 4,137 トークン） deepagentsとは——LangGraph の上に載る「バッテリー同梱」の層 deepagents は LangGraph を土台に、汎用エージェントに必要な部品をあらかじめ組み込んだ Python パッケージだ。公式ドキュメントは LangGraph 本体との住み分けを「まず速く動かしたいなら Deep Agents、制御を自分で書きたいなら LangGraph 本体」と案内している。 パッケージ本体のリポジトリ langchain-ai/deepagents は GitHub star 28,757、fork 4,037、MIT ライセンス（2026-08-31 時点、GitHub API 実測）。PyPI のリリース数は 123 に達しており、最新版 0.7.11 は 2026-08-28 公開だ。1年足らずで 123 リリースというペースは、後述する「教材と最新版のずれ」の直接の原因でもある。 deepagents が最初から積んでいるのは、大づかみに次の4つになる。 要素 何をするか 何の問題を解くか 計画（TODO） 作業計画をツール経由で書き出し、進行中に読み返す 長い作業で目的を見失う ファイルシステム 中間成果物をファイルへ退避し、必要なときだけ読む 会話履歴に全部を持ち続けると文脈があふれる サブエージェント 調査などを別コンテキストへ委譲し、結果だけ受け取る サブタスクのログで本体の会話が汚れる システムプロンプト 上記の使い方を細かく指示した長文プロンプトを同梱 部品があっても使い方を知らないと動かない 教材リポジトリの README は、この設計が Manus や Claude Code といった実運用エージェントの「文脈エンジニアリング」パターンの共通項を抽出したものだ、と説明している。実際 Manus のブログを引いて「平均的なタスクで約50回のツール呼び出しを使う」と書いており、長時間タスクを前提にした設計であることが出発点になっている。 公式教材 deep-agents-from-scratch の中身 langchain-ai/deep-agents-from-scratch は star 817・fork 324・MIT。言語の内訳は Jupyter Notebook で、リポジトリのファイル数はわずか35本しかない。中身は次の5ノートブックが本体だ。 ノートブック サイズ 扱うテーマ 0_create_agent.ipynb 113 KB ツール付きエージェントの最小構成 1_todo.ipynb 537 KB 計画（TODO）と recitation 2_files.ipynb 132 KB ファイルシステムへの文脈退避 3_subagents.ipynb 215 KB サブエージェントへの委譲 4_full_agent.ipynb 418 KB 4要素を統合した完成形 src/deep_agents_from_scratch/ 配下には todo_tools.py・file_tools.py・task_tool.py・prompts.py が置かれていて、ノートブックはこれらを import しながら組み上げていく。prompts.py が 9,489 バイトあるのが象徴的で、「バッテリー同梱」の実体の少なくない部分がプロンプト文そのものだと分かる。 教材は最小構成から始めて4要素を1本ずつ足していく積み上げ型（サイズは 2026-08-31 時点） ノートブックの順番はそのまま deepagents の設計の順番でもある。0_create_agent でツール付きのループを作り、1_todo で計画を、2_files で文脈退避を、3_subagents で委譲を足し、4_full_agent で全部を1本にまとめる。途中で「なぜこの部品が要るのか」が体感できるように、先に不便を味わわせてから解決策を足す構成になっているので、飛ばし読みには向かない。1_todo が537 KBと5本で最大なのは、TODO の書き出しと読み返し（recitation）の効き方を実行例で見せるためにセル出力が多く残っているからだ。 つまりこの教材は、deepagents パッケージの使い方を教える本ではない。パッケージが隠している中身を、LangGraph の素の API で書き直すための教材だ。だから「deepagents を業務で使いたい」人と「deepagents の中身を理解したい」人とで、読むべきものが分かれる。 flowchart TD A["ユーザーの依頼"] --> B["メインエージェント"] B --> C["計画を書き出すwrite_todos"] B --> D["中間成果をファイルへwrite_file / read_file"] B --> E["調査を委譲task ツール"] E --> F["サブエージェント別コンテキストで実行"] F --> G["結果の要約だけ返す"] G --> B C --> B D --> B B --> H["最終回答"] deepagents のインストールと最小の使い方 教材の README は uv sync を案内しているが、パッケージ単体を触るだけなら venv と pip で足りる。本記事の実測はすべてこの手順で行った。 python3 -m venv /tmp/da_venv /tmp/da_venv/bin/pip install deepagents /tmp/da_venv/bin/python -c "import importlib.metadata as md; print(md.version('deepagents'), md.version('langchain'))" # => 0.7.11 1.3.18 エージェント自体は1行で作れる。グラフの構築時点ではモデルAPIを呼ばないので、APIキーがダミーでもツール構成の確認まではできる（実行にはもちろん本物のキーが要る）。 from deepagents import create_deep_agent agent = create_deep_agent(model="claude-sonnet-4-5") print(sorted(agent.nodes["tools"].tools_by_name)) # => ['delete', 'edit_file', 'execute', 'glob', 'grep', 'ls', 'read_file', 'task', 'write_file'] ここで1つ注意がある。0.7.11 の create_deep_agent の docstring は既... --- ## skills-hubとは｜Agent Skillsを47ツールへ同期するデスクトップアプリを実測 - URL: https://ai-heartland.com/tool/skills-hub/ - 更新日: 2026-08-31 - カテゴリ: tool - 概要: skills-hub は Agent Skills を1箇所に集めて各AIコーディングツールのディレクトリへ同期する Tauri 製デスクトップアプリ。47アダプタの中身をソースから数え直し、symlink 同期が本当に発火するかを4条件で実測した。同名OSSが9本あるので見分け方も添える。 - タグ: claude-code, SKILL.md, agents, Codex AIコーディングツールを2つ以上使っていると、同じスキルを .claude/skills/ にも .codex/skills/ にも .cursor/skills/ にも置くことになる。1本ずつコピーして回るうちに、どれが最新でどれが更新元なのか分からなくなる——skills-hub はこの散らかりを、中央リポジトリ1つとそこからの同期に置き換えるデスクトップアプリだ。 管理下のスキル一覧。1枚のカードに「どこから来たか・どのツールへ同期しているか・有効か」が並ぶ（出典: qufei1993/skills-hub README） 30秒でわかる ・スキル配布ツールとしては珍しいGUIデスクトップアプリ（Tauri + Rust + React）。中央リポジトリは ~/.skillshub、状態はSQLite 1ファイル ・対応は47アダプタ。ただし書き込み先で数えると46——Amp と Kimi Code CLI は同じディレクトリを共有する ・symlink 同期は Claude Code で実際に発火した（3条件で確認）。一方でリンク切れは誰も警告しない。筆者の実機の ~/.claude/skills は29件中27件が既に壊れたリンクだった ・Explore に並ぶ300本の由来リポジトリは2つだけ。全部入れると常駐コストは13,047トークン（Anthropic count_tokens） ・同名の skills-hub が GitHub だけで9本ある。日本語検索でこのリポジトリは上位10件に出てこない Claude Code 側の導入・運用の全体像は Claude Code｜2026年版・インストールからCLAUDE.md・Hooks・本番運用までの実装手引き にまとめてある。本記事はその周辺にあるスキルの置き場所の管理だけを扱う。 skills-hub とは——「1回入れて、どこでも同期」の実体 skills-hub（qufei1993/skills-hub）は、Agent Skills を1箇所にインストールし、そこから複数のAIコーディングツールのスキルディレクトリへ配るデスクトップアプリだ。README のキャッチコピーは “Install once, sync everywhere”。実測に使ったのは v0.9.1（2026-08-29公開、コミット 9d9f490f）である。 同種のツールはこれまでコマンドラインだった。スキルを配る CLI は skills.shとは｜npx skills add がディスクに何を書くかを実測 で扱った npx skills add があり、lockfile と監査を持ち込む Go 製CLIは qvr（quiver）とは｜エージェントスキルにlockfileと監査を持ち込むGo製パッケージマネージャを実測 で扱った。skills-hub はそこにGUIを持ち込んだ側にあたる。 実体は素直だ。アプリを起動すると、中央リポジトリ ~/.skillshub と、状態を持つSQLiteが1ファイル作られる。 # 起動直後に作られたもの（macOS の場合） ~/.skillshub # 中央リポジトリ（空） ~/Library/Application Support/com.qufei1993.skillshub/skills_hub.db # 状態（76KB） このDBは skills / skill_targets / skill_tags / skill_tag_links / discovered_skills / settings の6テーブルで、起動直後は settings の1行以外すべて空だった。起動しただけでは既存の ~/.claude/skills に一切触れないことも確認している（起動前後でディレクトリ一覧のハッシュが一致）。スキャンや同期は明示的に操作したときだけ走る設計だ。 Gitリポジトリからの追加。インストール前にタグ・同期範囲（global / project）・同期先ツールを決める（出典: qufei1993/skills-hub README） スキル同期の方式は symlink（Windows では junction）が既定で、できない場合はディレクトリコピーへ自動フォールバックする。README は Cursor だけ常にコピーになると明記していて、理由も「Cursor が symlink ベースのスキルディレクトリに対応していないため」と書かれている。 同名の「skills-hub」が9本ある——どれの話かを見分ける 先に済ませておきたい話がある。skills-hub という名前は激しく衝突している。 GitHub を star 順に検索すると、同名または実質同名のリポジトリが少なくとも9本出てくる。さらに厄介なのは、そのうち複数が「AIコーディングエージェントのスキルをローカルで管理・同期する」というほぼ同じ説明文を持っていることだ。 リポジトリ ★ 何をするものか qufei1993/skills-hub 1,285 本記事の対象。スキルを47ツールへ同期するTauri製デスクトップアプリ iflytek/skillhub 4,915 企業向けの自己ホスト型スキルレジストリ（Java）。npm のようにスキルを公開・バージョン管理する binance/binance-skills-hub 998 AIエージェント向けのスキルマーケットプレイス zhuyansen/agent-skills-hub 342 OSSスキル・MCPサーバーを探して比較するディレクトリサイト zhensherlock/skills-hub 109 （説明文なし） agent-skills-hub/agent-skills-hub 90 複数ツールで動くスキルのグローバルライブラリ liuxingqitd/skills-hub 79 スキルを同期・インストールするローカルダッシュボード youzaiAGI/agent-skills-hub 70 スキルパッケージの管理 PotatoDog1669/skills-hub 12 スキルを可視化・管理・同期するローカルハブ いずれも fork ではなく独立したリポジトリである。当サイトでは以前 SkillHub完全ガイド｜AIエージェントのスキルをnpm風に管理するOSSレジストリ で iflytek 版を扱っているが、あれは Java 製のサーバーサイド・レジストリで、本記事のデスクトップアプリとは別物だ。 日本語検索では、star が一番多いものが出てくるわけではない 2026-08-31 時点で「skills hub」を日本（location 2392 / 言語 ja）で実査したところ、★1,285 の qufei1993/skills-hub は上位10件に入っていなかった。代わりに6位に出たのは同名の PotatoDog1669/skills-hub（★12）で、残りは skills-hub.ai・skills-hub.eu・skills-hub.cc といった別サービス、Google Play のアプリ、eLearning 企業、そして Web デザインスクールの skillhub.jp だった。この語で検索して辿り着いた先が目的のものとは限らない——リポジトリのオーナー名まで確認してから入れたほうがいい。 対応47ツールの中身をソースから数え直す README は「47の組み込みツールアダプタ」と書いている。額面どおりか、定義本体（src-tauri/src/core/tool_adapters/mod.rs）から機械的に数え直した。 Tools 画面。組み込みの同期先を有効化するか、独自のスキルディレクトリを持つ社内ツールを自分で足せる（出典: qufei1993/skills-hub README） default_tool_adapters() のエントリ数は 47 で、README の対応表の行数と一致した。ここは誇張がない。ただし「47ツール対応」と「47箇所に配れる」は別である。 数え方 件数 中身 アダプタの定義数 47 READMEの対応表と一致 書き込み先（global）の異なり数 46 Amp と Kimi Code CLI が ~/.config/agents/skills を共有 project 同期で .agents/skills を使う組 9 Amp / Antigravity / Cline / Codex / Cursor / Gemini CLI / GitHub Copilot / Kimi Code CLI / OpenCode project 同期で独自ディレクトリを使う組 38 Claude Code は .claude/skills、Windsurf は .windsurf/skills project 同期に非対応 2 Hermes Agent と WorkBuddy（supports_project_scope() が除外） ソースには共有についての注記も残っている。Kimi Code CLI のアダプタには NOTE: Shares the same skills directory with Amp. とコメントがあり、意図的な設計だと分かる。つまり Amp に同期すると Kimi Code CLI にも同時に入る。同期先の一覧でチェックが1つしか付いていなくても、実... --- ## Agent Orchestrator（AO）とは｜27エージェントを1枚で束ねるAgent IDEを実測 - URL: https://ai-heartland.com/agent/agent-orchestrator/ - 更新日: 2026-08-31 - カテゴリ: agent - 概要: Agent Orchestrator（AO）は、コーディングエージェントを1タスク1ワークツリーで走らせ、その上に常駐の計画エージェントを置くApache-2.0のAgent IDE。v0.12.9の同梱ビルドを起動すると、READMEが「26」と書くエージェントは27種登録されていた。テレメトリ送信も3条件で数えた。 - タグ: AIエージェント, マルチエージェント, オーケストレーション, Go, Electron, オープンソース Agent Orchestrator（以下 AO）は、コーディングエージェントを「1タスク＝1エージェント＝1ワークスペース」で並べ、その上に計画だけを担当する常駐エージェントを1つ置くデスクトップアプリだ。Untrivial-ai/agent-orchestrator（★10,690・Apache-2.0）が実体で、中身はGo製のローカルdaemonとElectron/Reactのフロントエンドである。この種のツールは「何種類のエージェントに対応」「自律的にCIを直す」といった見出しで語られやすいが、同梱ビルドを起動すると数字が1つ合わない。実際に v0.12.9 の dmg を落として動かし、数えた。 実測。v0.12.9 の dmg に同梱された daemon を起動して `ao agent ls` を実行すると27行返る。READMEの見出しは「26 coding agents supported」で、差分は一覧表に載っていない omp（OMP）1件だった（macOS arm64・2026-08-31） この記事のポイント（30秒でわかる） ・正体：コーディングエージェントを並列で走らせ、PR・CI・レビューの状態まで1枚のKanbanに集約するAgent IDE。Go daemon＋Electron ・他と違う点：worker（実装役）の上に project orchestrator（計画・分解・委譲だけを持つ常駐エージェント）を置く2階建て構造 ・実測①：登録エージェントは 27種（READMEは26）。エージェントのCLI自体は同梱せず、利用者が入れた実体を起動する ・実測②：テレメトリは既定で外に出ない。2つの環境変数を両方onにしたときだけ PostHog へ6回接続した ・注意：ドキュメントが未実装と明記する機能がある（tracker連携は実行時に何もしない） エージェント基盤の全体像から入りたい場合は、AIエージェントフレームワーク比較2026｜LangGraph・CrewAI・Dify等9種をStar数・実コードで検証 を先に読むと、AOがどの層の製品かを掴みやすい。 Agent Orchestratorとは——workerの上に「計画する層」を置くAgent IDE AOの単位は worker だ。1つのworkerが1つのタスク、1つのコーディングエージェント、1つの隔離ワークスペースを持つ。Git管理下のリポジトリなら、workerごとに専用ブランチと git worktree が切られる。タスク・会話・ターミナル・変更ファイル・ブラウザプレビュー・PR・CI・レビュー状態が、そのworkerに最後まで紐づいたままになる。 AOのKanban。カードの位置は人が動かすのではなく、セッション・PR・CI・レビューの事実からAOが導出する（公式README掲載のスクリーンショット、v0.12.9） ここまでなら「worktreeでエージェントを並列化するツール」で、既に何本もある。AOが別物になるのはその上の層だ。 AOの構造。L4に常駐の計画エージェントがいることが、単なる並列実行ツールとの構造的な差になる project orchestrator はプロジェクト単位で1つ存在する常駐の計画エージェントで、個別タスクより一段上——製品の方向性、技術的な方針、優先順位、作業の順序——を扱う。会話がプロジェクトスコープで保持されるため、目標・決定・制約・過去の検討経緯が残る。そこにリポジトリの文脈と、現在動いているworker・PR・CI・レビューというライブの状態を合わせて計画する。計画が実行可能になったら、orchestratorがタスクへ分解し、workerを起こし、文脈を渡し、進捗を追う。 役割分担は明確に切られている。orchestratorは計画と委譲だけを持ち、実装・テスト・コミット・PRはworkerが持つ。この線引きがあるおかげで、「計画役が勝手にコードを書き始めて文脈が混ざる」という多エージェント運用でよくある崩れ方を構造的に避けている。 orchestratorがworkerへタスクと文脈を配る画面。計画履歴・リポジトリ文脈・AOのライブ状態を合わせて判断する（公式README掲載、v0.12.9） Kanbanのレーンは人の主観でなく事実から決まる。Working（実装中または次の指示待ち）、Needs you（ブロック・入力待ち・CI失敗・変更要求・シグナル喪失）、In review（レビュー待ちのPR）、Ready to merge（承認済みまたはマージ可能）の4つで、SCM observer がPRごとにポーリングして得た事実がそのままレーンになる。 flowchart TD A["タスクを渡す（人 or orchestrator）"] --> B["worker生成専用ブランチ + worktree"] B --> C["コーディングエージェントが実装Chat または native TUI"] C --> D["PR作成"] D --> E{"SCM observerが観測CI・レビュー・コンフリクト"} E -->|"失敗・変更要求"| F["同じworkerへ差し戻し（agent nudge）"] F --> C E -->|"通過"| G["Ready to merge"] 実測：同梱ビルドが登録するエージェントは27種、READMEは26種 READMEには「26 coding agents supported」とあり、アイコン付きの一覧表が続く。この表の項目を数えると確かに26だった。しかし配布物の側を数えると合わない。 v0.12.9 の agent-orchestrator-darwin-arm64.dmg（222MB）をマウントすると、Contents/Resources/daemon/ao にGo製のdaemonが入っている。これはCLIも兼ねているので、データディレクトリを隔離して起動し、カタログを直接引いた。 # v0.12.9 同梱daemonを隔離環境で起動して、登録エージェントを数える export AO_DATA_DIR=/tmp/ao-data AO_TELEMETRY_EVENTS=off AO_TELEMETRY_REMOTE=off "/Volumes/.../Agent Orchestrator.app/Contents/Resources/daemon/ao" daemon & "/Volumes/.../Agent Orchestrator.app/Contents/Resources/daemon/ao" agent ls | tail -n +2 | wc -l # => 27 結果は 27。起動ログにも登録簿がそのまま出るので、二重に確認できる。 ・ao agent ls の行数（ヘッダを除く）＝ 27 ・daemon起動ログの registered=[...] 配列の要素数＝ 27 ・READMEの一覧表の項目数＝ 26 差分は omp（OMP） 1件だった。READMEのアイコン表には無いが、docs/STATUS.md には「OMP Chat は native omp acp を使い、OMP 15.0.0 以降が必要」と書かれている。つまり隠し機能ではなく、READMEの一覧表の更新が1件遅れているだけと読むのが妥当だ。とはいえ「26種対応」を判断材料にする人にとっては、実際に入るものが1つ多い。 ここで重要なのは、AOがエージェントのCLIを同梱しないことだ。STATUS.mdは「AOは各harnessの既存のバイナリ・認証・環境の解決をそのまま再利用し、providerのCLIを同梱しない」と明記している。実際、まっさらな環境で ao agent ls を叩くと27種すべてが needs install と出る。AOを入れただけでは1つも使えず、使いたいエージェントは自分で入れて認証しておく必要がある。 確認したこと 実測値 出典・方法 登録エージェント数 27 同梱daemonの ao agent ls（ヘッダ除く行数） READMEの記載 26 README.md の Supported agents 見出し 差分 omp（OMP） 両者の突き合わせ。STATUS.mdには記載あり 初期状態の利用可否 27種すべて needs install 隔離した AO_DATA_DIR での初回実行 Chat対応（native driver） 9種 STATUS.md：Codex・Claude Code・Cursor・OpenCode・Droid・Kimchi・Kimi・Pi・OMP なお、daemon側のラベルはREADMEより具体的だった。READMEが「Grok」「Muse」「Qwen」「Vibe」と書く4件は、実機では Grok Build・Muse Code・Qwen Code・Mistral Vibe と表示される。 Orca・ruflo・Claude Code Agent Teams との違いを層で分ける 「エージェントを並列で走らせるOSS」は既に何本もあり、AOだけを見ても位置づけが掴めない。どの層の問題を解いているかで並べると差がはっきりする。   Agent Orchestrator Orca ruflo Claude Code Agent Teams 形態... --- ## skills.shとは｜npx skills add がディスクに何を書くかを実測 - URL: https://ai-heartland.com/tool/skills-sh/ - 更新日: 2026-08-31 - カテゴリ: tool - 概要: skills.sh は Vercel Labs のエージェント非依存なスキル配布CLI。npx skills add が実際にどこへ何を書くかを実測すると、既定の symlink モードでは Claude Code 以外の独自ディレクトリ組にリンクが張られず、Windsurf・Roo・Goose が無言で入らないことが6通りの組み合わせで再現した。 - タグ: claude-code, SKILL.md, agents, Codex skills.sh は、Agent Skills（SKILL.md 1枚で AI エージェントに手順を渡す仕組み）を配布するディレクトリと、その CLI である。Vercel Labs の vercel-labs/skills（★30,027・MIT）が実体で、npx skills@latest add <owner>/<repo> の1コマンドで、Claude Code 以外のエージェントにもスキルを入れられるのが売りだ。ただ「入れられる」と書かれているだけでは、自分の環境のどこに何が置かれるのかが分からない。実際に走らせて、ディスクの差分を取った。 実測。エージェントを1つだけ指定すると `.windsurf/skills/` へ直接コピーされるが、2つ指定すると既定が symlink モードに切り替わり、**Claude Code にしかリンクが張られず `.windsurf/` は作られない**。`--copy` を付ければ両方に入る（skills 1.5.23・macOS・2026-08-31） 30秒でわかる ・npx skills add の書き込み先は指定したエージェントの数で切り替わる。1つなら直接コピー、2つ以上なら .agents/skills/ ＋ symlink ・「77エージェント対応」の内訳は共通ディレクトリ組19・独自ディレクトリ組58。同じ扱いではない ・既定の symlink モードでリンクが張られたのは Claude Code だけ。Windsurf・Roo・Goose は終了コード0で「Installation complete」と出るのに自分のディレクトリが無い（6通りで再現）。--copy で回避できる ・同じ mattpocock/skills でも CLI は37本を列挙し、Claude Code プラグインは25本しか入れない ・依存は tar と yaml の2つだけ。インストール時に Socket・Snyk のスキャン結果が表示される Claude Code 側の導入・運用の全体像は Claude Code｜2026年版・インストールからCLAUDE.md・Hooks・本番運用までの実装手引き にまとめてある。本記事はその周辺にあるスキルの配り方だけを扱う。 skills.sh とは——Claude Code の外へスキルを配るための CLI Agent Skills はもともと Claude Code の機構として広まったが、SKILL.md 自体はただの Markdown なので、他のエージェントでも読める。問題は置き場所がエージェントごとに違うことだ。Claude Code は .claude/skills/、Windsurf は .windsurf/skills/、Codex や Cursor は .agents/skills/ を見る。この差を吸収するのが skills.sh の CLI である。 # リポジトリにあるスキルを一覧するだけ（インストールしない） npx skills@latest add mattpocock/skills -l # スキルとエージェントを指定して入れる npx skills@latest add mattpocock/skills -s grilling -a claude-code -y 実測環境は macOS（Darwin 23.5.0・arm64）、Node v22.13.1、skills@1.5.23（v1.5.23・2026-08-18公開、コミット 435076e7）。題材には、keitakn 氏が AIに丸投げしないで理解するためのAI開発手法（2026年8月現在）（Zenn）で「Codex など他のエージェントで使う場合の導入ルート」として挙げている mattpocock/skills を使った。npm 上のパッケージは展開時 548,883バイト・19ファイルで、依存は tar と yaml の2つだけだった。 engines は満たしていなくても動く package.json の engines は node >=22.20.0 を要求している。手元の Node は v22.13.1 で npm warn EBADENGINE が出たが、実行そのものは通り、インストールも完了した。npm の engines は既定では警告止まりで実行を止めない。「Node 22.20 以上が必須」と読むと、動く環境で無用にアップグレードすることになる。 スキル名の指定はカンマ区切りが効かない 最初につまずいたのはここだ。--skill grill-me,grilling のようにカンマで並べると、37スキルを認識したうえで No matching skills found for: grill-me,grilling と言われて終了コード1で落ちる。文字列全体を1つのスキル名として扱っているためだ。 # NG: カンマ区切りは1つの名前として扱われる（exit 1） npx skills@latest add mattpocock/skills --skill grill-me,grilling -a claude-code -y # OK: -s を繰り返す npx skills@latest add mattpocock/skills -s grill-me -s grilling -a claude-code -y 同じく --agent claude も通らない。正しい識別子は claude-code で、間違えると有効なエージェント名77件が全部表示される（これはこれで一覧を得る手段として使える）。 npx skills add がディスクに何を書くか ここが本題である。空の git リポジトリを用意し、インストール前後で find の差分を取った。 エージェントを1つだけ指定した場合、そのエージェントのディレクトリへ直接コピーされる。 .windsurf/skills/grilling/SKILL.md .windsurf/skills/grilling/agents/openai.yaml skills-lock.json 2つ以上指定した場合、書き込み方が変わる。 .agents/skills/grilling/SKILL.md ← 実体はここ1つだけ .agents/skills/grilling/agents/openai.yaml .claude/skills/grilling -> ../../.agents/skills/grilling ← symlink skills-lock.json 同じコマンド形でも、指定するエージェント数で書き込み方が切り替わる 実体を1か所に集めて symlink で配るのは理にかなっている。npx skills update で更新したときに、全エージェントへ同時に反映されるからだ。逆に単一エージェント指定では実体が直接そのディレクトリに入るので、後からエージェントを足すと配置が食い違う可能性がある。最初から入れる予定のエージェントをまとめて指定しておくほうがよい。 skills-lock.json には SKILL.md のハッシュが入る プロジェクト直下に作られる skills-lock.json は、スキルごとに source（mattpocock/skills）・sourceType（github）・skillPath（リポジトリ内の元のパス）・computedHash（SHA-256）を記録する。experimental_install はこれを見て復元するので、チームで揃えたいならコミット対象にするのが筋だ。逆に言うと、ここに入るのはスキル本体ではなく参照とハッシュなので、.agents/skills/ 側を .gitignore すると復元コマンド頼みになる。 agents/openai.yaml が一緒に入る コピーされるのは SKILL.md だけではない。mattpocock/skills の各スキルには agents/openai.yaml が同梱されており、これも一緒に入る。中身は Codex 系向けの表示名と、起動ポリシーだ。 interface: display_name: "Grill Me" short_description: "Sharpen a plan through interview" policy: allow_implicit_invocation: false この allow_implicit_invocation: false は、Claude Code 側の SKILL.md frontmatter にある disable-model-invocation: true と同じことを別の語彙で言っている。SKILL.md の frontmatter に何を書けるかは SKILL.mdのdescriptionは1024字上限｜Claude Skill命名規則と公式19本の検査結果 で公式スキルを検査したときにまとめたが、そこに書ける項目と openai.yaml に書ける項目は一致しない。ランタイムごとに読む場所が違うので、両方書いておく必要があるわけだ。37スキルすべてに openai.yaml があり、両方の宣言を突き合わせると22対22で完全に一致していた（不一致0件）。二重管理は破綻しやす... --- ## grill-me は自動発火しない設計だった｜mattpocock/skills 37本の起動条件を実測 - URL: https://ai-heartland.com/explain/grill-me-skill/ - 更新日: 2026-08-31 - カテゴリ: explain - 概要: grill-me は Claude Code に入れても自動では起動しない。SKILL.md の disable-model-invocation により、ランタイムが Skill ツールからの呼び出しを拒否する。対照群つきで実測し、mattpocock skills 37本中22本が同じ宣言を持つことまで数えた。 - タグ: claude-code, SKILL.md, agents, AIコーディング Matt Pocock 氏のスキル集に入っている grill-me は、実装に入る前に AI が人間を質問攻めにして計画の穴を潰させるスキルだ。日本語圏でも紹介記事が増えているが、導入したのに「入れた気がしない」という声がある。実際に Claude Code 2.1.241 で測ったところ、それは設定ミスではなく設計どおりだった。grill-me は SKILL.md に disable-model-invocation: true を持っており、ランタイムがモデルからの呼び出しを拒否する。 実測ログ。対照群 grilling は自動発火し、grill-me はランタイムがエラーで拒否、/grill-with-docs は Skill を2回呼ぶ（Claude Code 2.1.241・2026-08-31・macOS） 30秒でわかる ・grill-me は本文36バイト。中身は「grilling を呼べ」の1行だけの入口スキル ・disable-model-invocation: true が付いており、モデルからは絶対に呼べない。ユーザーが /grill-me と打つ専用 ・mattpocock/skills の37本中22本（59.5%）が同じ宣言を持つ。in-progress は8本すべて ・呼べない22本も一覧には載るので、657トークンは常駐したまま自動では動かない ・claude plugins install で入るのは25本、リポジトリには37本ある Claude Code そのものの導入から運用までは Claude Code｜2026年版・インストールからCLAUDE.md・Hooks・本番運用までの実装手引き にまとめている。本記事はその中の Agent Skills について、「入れたスキルがいつ動くのか」という一点を実測で詰める。 なおこのスキルの実務での使い方は、keitakn 氏の AIに丸投げしないで理解するためのAI開発手法（2026年8月現在）（Zenn）が要件定義から実装までのワークフローとして詳しく書いている。本記事はそのワークフローの紹介ではなく、そこで使われるスキルが実際にどう起動するかを測ったものだ。 grill-me とは——36バイトの SKILL.md が grilling を呼ぶだけの入口 まず中身を見る。skills/productivity/grill-me/SKILL.md は frontmatter を除くと本文が36バイトしかない。 # 中身を確認する（リポジトリを clone せずに読む） curl -s https://raw.githubusercontent.com/mattpocock/skills/main/skills/productivity/grill-me/SKILL.md 返ってくるのは frontmatter 3行と、本文1行の「grilling という名前で Skill ツールを呼べ」という指示だけである。同じく grill-with-docs も本文64バイトで、「grilling と domain-modeling の2つで Skill ツールを2回呼べ」としか書かれていない。 つまり grill-me / grill-with-docs は実装を持たない入口で、中身は別の2本にある。 ・grilling（本文1,987バイト）— 質問を「設計ツリー」として扱い、前提が確定した論点だけを1ラウンドにまとめて出す。各質問に番号と推奨回答を必ず添える。事実の調査は AI 側の仕事で、ユーザーに調べさせない ・domain-modeling（本文3,331バイト）— 対話中に固まった用語を CONTEXT.md に、決定を docs/adr/ に書き出す。「CONTEXT.md を読むだけ」はこのスキルではなく、モデルを書き換えるときのためのもの、と明記されている flowchart TD U["ユーザーが打つ"] --> A["/grill-me本文36バイト"] U --> B["/grill-with-docs本文64バイト"] A -->|"Skill を1回"| G["grilling設計ツリーでラウンド質問"] B -->|"Skill を2回"| G B --> D["domain-modelingCONTEXT.md と ADR を書く"] G --> O["番号つき質問 + 推奨回答"] D --> O M["モデルの自発的判断"] -.->|"拒否される"| A M -.->|"拒否される"| B M -->|"許可"| G 図の破線が本記事の主題だ。grilling と domain-modeling はモデルが自分の判断で呼べるが、grill-me と grill-with-docs は呼べない。 いつ「呼べないスキル」になったのか——2026-06-12 のコミットで反転している grill-me は最初からこの形だったわけではない。コミット履歴を追うと、転換点は2026年6月12日のコミット 221ffca9（33ファイルを触った大きな再編）にある。このコミットで grill-me/SKILL.md は3行追加・6行削除され、中身がこう入れ替わった。   2026-06-12 より前 2026-06-12 以降 description Use when user wants to stress-test a plan, get grilled on their design, or mentions “grill me” Get relentlessly interviewed about a plan or design until every branch of the decision tree is resolved. disable-model-invocation なし true 本文 インタビュー手順そのもの（設計ツリー・1問ずつ・推奨回答つき） Run the /grilling skill. の1行 注目すべきは description の書き換え方だ。旧版には「Use when ユーザーが〜と言ったとき」という、モデルに向けた発火条件が書かれていた。新版はそれを落とし、「（あなたが）計画について容赦なくインタビューされる」という人間に向けた説明になっている。発火条件を書く相手がいなくなったので、書く必要もなくなったわけである。実装本体は同日追加された grilling へ移り、旧 description の発火条件はそちらが引き継いだ。 日本語圏では「grill-me から grilling に乗り換えた」という書き方をよく見るが、履歴上は乗り換えではなく分割である。grill-me は廃止されておらず、2026-08-31 時点でも grilling と並んで現存し、プラグイン manifest にも両方載っている。文言の最終調整は2026-08-15の fcf00715 で、Call the Skill tool for \grilling` から Call the Skill tool with “grilling”` へ、引用符つきの形に統一された。 実測：grill-me は Skill ツールから呼び出せない ここが本題である。宣言を数えただけでは「ランタイムがその宣言を尊重しているか」は分からないので、実際に動かして確かめた。 環境は macOS（Darwin 23.5.0・arm64）、Claude Code 2.1.241。スキルはプロジェクト配下の .claude/skills/ に置き、claude -p "<依頼>" --output-format stream-json --verbose で実行して、tool_use のうち Skill の呼び出しだけを数えた。応答本文を読んでも発火の有無は判定できない——発火していなくても、それらしい質問文は返ってくるからだ。 4条件の実測。B2 だけがランタイム側のエラーで止まる まず対照群を取る いきなり grill-me を試すと、発火しなかったときに「ハーネスの設定ミス」と区別できない。そこでgrilling だけを置いたディレクトリを用意し、description に合う自然文で依頼した。 Grill me about my plan: I want to add GitHub OAuth login to my Next.js app. Stress-test my thinking before I write any code. 結果は {"skill": "grilling"} の1件。自動発火した。出力も SKILL.md の指定どおり ❓ **Q1** 形式の番号つき質問に ➡️ の推奨回答が並ぶ、ラウンド制の体裁になっていた。対照群が動いたので、以降の「動かなかった」は解釈できる。 同じ依頼を grill-me だけの環境へ投げる 次に grill-me だけを置いたディレクトリで、まったく同じ英文を投げた。Skill は1件呼ばれたが、中身は grill-me ではなく環境に元から入っていた別のスキルだった。grill-me は選ばれていない。 ここで切り分けが要る。読み込まれていないのか、選ばれなかっただけなのか。stream-json の sy... --- ## SpiderFootとは｜OSINT自動化ツールの現在地——本家は2023年で停止、自社ドメインで実測 - URL: https://ai-heartland.com/security/spiderfoot/ - 更新日: 2026-08-30 - カテゴリ: security - 概要: SpiderFootはドメインやIPを起点にOSINTを自動収集するMITライセンスのOSS。本記事は公式リポジトリの更新状況をGitHub APIで実測し、masterが2023年11月から動いていないこと、Python 3.14では導入できず3.12なら動くこと、自社ドメイン1本のpassiveスキャンが実際に何を返すかまで手元で確認した結果をまとめる。 - タグ: security, セキュリティ, OSINT, アタックサーフェス, Python 「SpiderFoot」は、ドメイン名やIPアドレスを1つ入力するだけで、多数の公開情報源に自動で問い合わせて結果を1か所に集約するOSINT（オープンソースインテリジェンス）自動化ツールだ。GitHubスター21,520・MITライセンス・Python 3製で、Kali Linux にも標準パッケージとして入っている。ただし日本語の解説記事はKali 2021年前後で時計が止まっており、このツールが今どういう状態にあるのか——本家の開発が動いているのか、どのバージョンのPythonなら入るのか、APIキーを1つも持っていない人が実際に何を得られるのか——に答えているものが見当たらない。そこで本日、公式リポジトリの実データをGitHub APIで取り、手元のmacOSに入れて当サイトが管理する自社ドメイン1本に対して実際に走らせた結果をまとめる。 本記事の検証環境で実際に録画したSpiderFootのCLI実行。対象は当サイトが管理する ai-heartland.com、APIキーは未設定。キー不要のモジュールだけでDNS・IPv6・実IPまで到達する（2026-08-30 macOS 14 / Python 3.12 で撮影） 30秒でわかる SpiderFoot（2026年8月30日時点） ・正体：ドメイン／IP／メールアドレス等を起点に、公開情報源へ自動照会して結果を集約するOSINT自動化ツール。Python 3・MIT・WebUIとCLIの両方を持つ。 ・規模の実測：modules/ のファイルは233個だが、内部用2個と雛形1個を除いた実モジュールは230個。うち83個がAPIキーを要求し、147個はキー不要。相関ルールは38本。 ・いちばん重要な注意：本家 master の最終コミットは2023年11月5日、最新タグはv4.0（2022年4月7日）。2022年11月にIntel 471が買収し、spiderfoot.net は現在 intel471.com へ301リダイレクトする。 ・導入の落とし穴：requirements.txt の上限ピンが古く、Python 3.14では lxml のビルドに失敗して入らない。Python 3.12なら約22秒で完了した（実測）。 ・もう1つの落とし穴：pip install spiderfoot で入るのは本体ではなく、「名前の予約用」と自称する1,302バイトの空パッケージ。 ・使う前提：対象は自分が管理する資産に限る。 自社ドメイン1本の既定 passive スキャンは14分35秒かかり、生成された632件のうち508件（80%）は自社でなく同居する第三者に関する事実だった（実測）。 外から見えている資産の棚卸しは、依存パッケージ側の点検とセットで初めて意味を持つ。取り込む側の経路についてはサプライチェーン攻撃とは｜手口・防御ツール比較・npm 12の新機構まで実践解説で扱っている。本記事は「外に出ている自分の情報を、自分で見に行く」側の話だ。 SpiderFootとは——230モジュールが公開情報源を手分けして叩く仕組み SpiderFootの情報収集の設計は素直だ。利用者が「調べる起点」を1つ与えると、それがイベントとしてモジュール群に配信される。あるモジュールが「ドメイン名」を受け取ってIPアドレスを吐き出すと、そのIPアドレスが新しいイベントとして別のモジュールに配られ、そこからさらに別の事実が出てくる。README はこれを publisher/subscriber モデルと表現している。 起点として指定できるのは、ドメイン／サブドメイン名、ホスト名、IPアドレス、ネットワークサブネット（CIDR）、ASN、メールアドレス、電話番号、ユーザー名、人名、Bitcoinアドレスだ。 モジュール数は README の公称値でなく、本日 clone した実ファイルを数えた値（出典: smicallef/spiderfoot の modules/ と sf.py -M の出力） READMEは「Over 200 modules」と書く。実際に数えると modules/sfp_*.py は233ファイルあるが、sf.py -M が一覧に出すのは230個だった。差の3個は内訳がはっきりしている——sfp__stor_db と sfp__stor_stdout は結果を保存・出力するための内部モジュール、sfp_template は自作モジュールを書くときの雛形だ。つまり「200を超える」という公称値は正しく、実数は230である。 同様に相関エンジンのルールは README が「37 pre-defined rules」と書いているが、correlations/ 配下の YAML は実測で38本あった。1本ぶんの差は README の更新漏れとみられる。 SpiderFootの価値は「1つのツールが何でも知っている」ことではなく、230個の小さな調査手順を1回の実行で並列に走らせ、結果を1つのデータベースに揃えることにある。 APIキー無しで動く範囲はどこまでか 外部サービス依存のモジュール（Shodan、HaveIBeenPwned、GreyNoise、SecurityTrails など）はAPIキーが要る。設定項目にAPIキーを持つモジュールを機械的に数えると、230個のうち83個だった。残る147個はキー無しで動作する。 本記事の検証ではキーを1つも新規取得していない。それでもDNSレコードの解決、IPv4／IPv6アドレスの特定、WHOIS情報の取得、証明書透明性ログの照会、逆引き、国名の解決といった基礎的な事実は取れた。「キーを揃えないと何もできないツール」ではないというのが実測の結論だ。 読者の3つの問いへの答え ① 何ができる：起点を1つ与えるだけで、230個のモジュールが公開情報源を手分けして照会し、結果を1つのSQLiteに集約する。② 何を解決する：「自社ドメインについて外から何が見えているか」を、手作業のdig／whois／証明書検索の寄せ集めでなく1コマンドで棚卸しできる。③ 何を代替できる：外形調査の初期フェーズを代替する。ただし本家は開発が止まっているため、継続運用の基盤としては後述のフォークか他ツールを検討したほうがよい。 メンテナンス状況——masterは2023年11月で止まり、会社はIntel 471の傘下にある ここが本記事のいちばん伝えたい部分だ。SpiderFootはスター21,520・フォーク3,471という規模のプロジェクトで、Kali Linux にも入っているため「現役の定番ツール」に見える。しかし公式リポジトリの実データはそう言っていない。 すべて2026-08-30にGitHub APIおよびHTTPヘッダで実測した値（出典: GitHub REST API /repos/smicallef/spiderfoot、Intel 471 の買収発表） 2026年8月30日時点でGitHub APIから取った値は次のとおり。 項目 実測値 備考 スター / フォーク 21,520 / 3,471 archived は false（アーカイブ宣言はされていない） リポジトリ作成 2012-04-28 14年前 最新のタグ付きリリース v4.0（2022-04-07） それ以降タグ無し master の最終コミット 2023-11-05（0f815a20） jQuery 3.6.0→3.7.1 の更新 pushed_at 2026-04-13 master ではなく Dependabot ブランチへのpush ブランチ master / fix-install-error / dependabot/pip/test/pytest-9.0.3 3本のみ ライセンス MIT LICENSE実体で確認 pushed_at が2026年4月になっている点に注意したい。 リポジトリ一覧やダッシュボードで「4か月前に更新」と表示されるのはこの値だが、実際に押されたのは Dependabot が作った依存更新ブランチであって、master は2023年11月5日から1コミットも動いていない。star数や「最終更新」表示だけを見て現役と判断すると、ここを取り違える。 会社側の動き 2022年11月2日、脅威インテリジェンス企業の Intel 471 が SpiderFoot を買収したと発表している。創業者の Steve Micallef 氏は Intel 471 の Vice President of Attack Surface Technology として合流した。発表文はオープンソース版がGitHubで公開されていることに触れているが、その後の開発・保守を継続するとは書いていない。 現在の状況はURLにも表れている。READMEのバナーやリンク先である公式サイト spiderfoot.net は、本日 curl で確認したところ 301で intel471.com へリダイレクトする。README中の「SpiderFoot HX」（商用SaaS版）へのリンクも、open-source-vs-hx の比較ページも、同じく企業サイトのトップへ吸収されている。 # 実行して確認したリダイレクト（2026-08-30） curl -sIL -A "Mozilla/5.0" http://www.spiderfoot.net | grep -Ei '^(HTTP... --- ## Claude Code compact｜圧縮で何が残り何が消えるか、5,000トークンの閾値を実測で検証 - URL: https://ai-heartland.com/explain/claude-code-compact-guide/ - 更新日: 2026-08-30 - カテゴリ: explain - 概要: Claude Code compact は会話を要約して枠を空けるが、何が残るかは読み込まれ方で決まる。CLAUDE.mdは再注入、スキル本文は1つ5,000トークンで打ち切り、5,000トークン超のファイルは中身でなくパス参照で戻る。公式仕様を仕組みごとに整理し、閾値の実影響を実測で示す。 - タグ: claude-code, anthropic, コンテキスト, 開発環境 Claude Code compact は「会話が長くなったら要約して枠を空けるコマンド」と説明されがちですが、実際には何が残るかは、その内容がどう読み込まれたかによって変わります。プロジェクト直下の CLAUDE.md はディスクから再注入されるので消えませんが、paths: フロントマター付きのルールは会話ごと要約されて消えます。スキル本文は戻ってきますが上限つきで切り詰められます。本記事では公式仕様を仕組みごとに整理し、5,000トークンという閾値が実際にどれだけのファイルに効くのかを当サイトのリポジトリで実測して示します。 「要約される」と一括りにできない。読み込まれ方ごとに戻り方が違う。 30秒でわかる /compact ・一様には消えない。CLAUDE.md・自動メモリ・プランはディスクから再注入される ・paths: 付きルールとネストした CLAUDE.md は消える。会話履歴に載る仕組みだから ・ファイルの読み直しは最大5件、最終更新が新しい順 ・5,000トークン超のファイルは中身が戻らない。Read でなく Referenced file として参照だけ返る ・スキル本文は1つ5,000／合計25,000トークンで打ち切り、切り詰めは先頭を残す ・圧縮自体が大きな要求。話題が変わっただけなら費用ゼロの /clear が正解 Claude Code 全体の設定・運用はClaude Code｜2026年版・インストールからCLAUDE.md・Hooks・本番運用までの実装手引きにまとめています。本記事はコンテキスト圧縮という一点に絞ります。自分のコンテキストが今どうなっているかの確認手段はClaude Code 使用量 確認の6手段｜/usage で見えるもの・見えないものを実測で切り分けるを参照してください。 Claude Code compact で何が残り、何が消えるのか 公式ドキュメントは、圧縮後の扱いを読み込まれ方（mechanism）ごとに表で定義しています。日本語圏でほとんど紹介されていない部分なので、まずここを正確に写します。 読み込まれ方 圧縮後の扱い システムプロンプト・出力スタイル 変化なし（そもそもメッセージ履歴の一部ではない） プロジェクト直下の CLAUDE.md・スコープなしのルール ディスクから再注入 自動メモリ ディスクから再注入 プランモードで書いたプラン ディスクから再注入 paths: フロントマター付きのルール 対象ファイルを読んだときに再読み込み サブディレクトリのネストした CLAUDE.md そのディレクトリのファイルを読んだときに再読み込み Claudeが読んだ／編集したファイル 最大5件を読み直す（最終更新が新しい順） 呼び出したスキルの本文 再注入。ただし1スキル5,000／合計25,000トークン上限、古い順に破棄 フックが以前に追加した文脈 会話と一緒に要約される compact ソースにマッチする SessionStart フック 実行され、出力が圧縮後の文脈に追加される ここで最も実務に効くのが5行目と6行目です。paths: 付きのルールとネストした CLAUDE.md は、トリガーとなるファイルが読まれたときにメッセージ履歴へ載る仕組みです。したがって圧縮では他の会話と同じように要約されて消えます。公式ドキュメントは対処もはっきり書いていて、圧縮をまたいで残したいルールは paths: を外すか、プロジェクト直下の CLAUDE.md へ移すことを勧めています。 「圧縮したら急に規約を守らなくなった」という症状は、この挙動でほぼ説明がつきます。ルールが消えたのであって、モデルが忘れたわけではありません。 なお v2.1.198 以降、要約リクエストはセッションの拡張思考の設定を引き継ぎます。セッションで思考が有効なら思考ありで要約し、無効なら無効のままです。思考は要約の作り方に影響するだけで、要約後にセッション設定が変わることはありません。 5,000トークンという閾値が実際にどれだけ効くか 上の表の7行目「最大5件を読み直す」には続きがあります。公式ドキュメントは、5,000トークンを超えるファイルは中身なしのパス参照として戻り、表示も Read ではなく Referenced file になると明記しています。ルール自体は読み直されますが、ファイルの中身は戻りません。 この閾値がどれくらい厳しいのかを、当サイトのリポジトリで実測しました。count_tokens API を使い、種類ごとに無作為抽出して測っています（claude-sonnet-5・2026-08-30）。 ファイル種別 母数 抽出 5,000トークン超 中央値 最大 記事（日本語 Markdown） 1,116 20 15件＝75% 11,953 16,531 Python ツール 131 20 7件＝35% 3,799 10,058 レイアウト／インクルード（HTML） 10 10 3件＝30% 3,419 41,807 日本語の文書はほとんどが閾値を超えます。中央値が11,953トークンなので、記事を編集していたセッションが圧縮されると、編集中だったファイルの中身は原則として戻ってきません。一方、Pythonのソースは中央値3,799トークンで多くが閾値内に収まります。同じ「ファイルを読んで作業する」でも、扱う対象によって圧縮後の回復度がまったく違うということです。 手元で同じ測り方をする count_tokens は課金されないので、圧縮の前に自分のファイルがどちら側かを確認できます。 for f in $(git ls-files '*.md'); do n=$(jq -Rs '{model:"claude-sonnet-5",messages:[{role:"user",content:.}]}' < "$f" \ | curl -s https://api.anthropic.com/v1/messages/count_tokens \ -H "x-api-key: $ANTHROPIC_API_KEY" -H "anthropic-version: 2023-06-01" \ -H "content-type: application/json" -d @- | jq .input_tokens) [ "$n" -gt 5000 ] && echo "$n $f" done 出力されたファイルは「圧縮後にパス参照でしか戻らない」側です。作業中はこれらを開きっぱなしにせず、必要な部分だけを渡すか、読み取りをサブエージェントへ逃がすほうが安全です。 スキルについても同じ形の上限があります。1スキルあたり5,000トークン・合計25,000トークンで打ち切られ、超過分は古く呼び出したものから落とされます。重要なのは切り詰め方で、先頭を残す方式です。公式ドキュメントはこれを踏まえて、重要な指示を SKILL.md の上のほうに置くよう明示的に勧めています。長いスキルを書いている場合、末尾に置いた注意事項は圧縮後に存在しないものとして扱われる可能性があります。 自動圧縮の閾値を変える3つの場所と優先順位 /compact を手で打たなくても、コンテキストが埋まれば自動で圧縮が走ります。その発火点は変更できます。 3つは並列ではなく優先順位がある。管理設定下では挙動が変わる。 ・/autocompact 500k：ユーザー設定の autoCompactWindow に保存され、現在のセッションにも適用される。ただし管理設定など優先度の高いスコープが同じキーを持つ場合はそちらが勝ち、コマンドはその旨を伝える。/autocompact auto でモデルに合わせた既定へ戻せる ・--autocompact フラグ：その起動だけ有効で、保存された設定を変えない。/autocompact と違い管理設定のような優先度の高いスコープに阻まれない ・CLAUDE_CODE_AUTO_COMPACT_WINDOW：スクリプトやクラウド環境向け。設定されている間はコマンド・フラグ・設定のすべてに優先し、/autocompact は変更でなく上書きされている旨を報告する 既定の発火点はモデルと構成で変わります。公式ドキュメントによれば、自動圧縮の窓を指定しない場合はモデルのコンテキスト上限に達したときに圧縮されますが、例外があります。Sonnet 4.6 と Opus 4.6（拡張コンテキストなし）は200Kの境界で圧縮され、Opus 4.8 と Opus 5 も200Kの窓で動く環境——Amazon Bedrock・Google Cloud の Agent Platform・Microsoft Foundry——では同様です。CLAUDE_CODE_DISABLE_1M_CONTEXT=1 を設定した場合、Sonnet 5 や Fable 5 のようにネイティブで1M窓を持つモデルも200Kで圧縮されます。Anthropic API 上の Sonnet 5 は既定で約967Kトークンで自動圧縮されます。 自動圧縮を切ると「圧縮されない」ではなく「止まる」 環境変数 DISABLE_COMPACT で全ての圧縮を無効にできますが、公式ドキュメントは結果を明記しています。自動圧縮が有効なら200Kの境界で圧縮されるところ、無効にすると同じ境界でコンテキスト長超過のエラーになって停止しま... --- ## Claude Code 使用量 確認の6手段｜/usage で見えるもの・見えないものを実測で切り分ける - URL: https://ai-heartland.com/explain/claude-code-usage-check/ - 更新日: 2026-08-30 - カテゴリ: explain - 概要: Claude Code 使用量 確認には6つの窓口があり、それぞれ見えるものが違う。/usage の数字がローカル履歴由来で他端末分を含まないこと、そして実測ではプロンプトを打つ前に44,519トークンの固定費が発生していることを、count_tokens API での計測つきで示す。 - タグ: claude-code, anthropic, 開発環境, 計測 「claude code 使用量 確認」で調べると /usage を打つ、という答えに行き着きます。それ自体は正しいのですが、この数字がどこから来ていて、何を含んでいないのかまで説明している記事はほとんどありません。Claude Code の使用量を見る窓口は実際には6つあり、それぞれ見えるものが違います。本記事では公式ドキュメントの記述を窓口ごとに整理したうえで、プロンプトを1文字も打つ前に44,519トークンが消えているという当サイト環境での実測値を、計測方法ごと示します。 count_tokens API での実測。「まだ何も頼んでいない」状態の消費がここまで積み上がる。 30秒でわかる 使用量の確認 ・窓口は6つ。/usage / /context / /insights / ステータスライン / OpenTelemetry / 組織アナリティクス ・/usage の数字はローカル履歴由来。他のPCや claude.ai での利用分は含まれない ・表示されるドル金額は請求額ではない。トークン数から定価で計算した見積り ・契約形態を問わず使えるのは OpenTelemetry だけ。クラウド経由の利用は公式ダッシュボードに出ない ・投入前に測れる。count_tokens は課金なしでトークン数を返す ・実測：固定費44,519トークン。CLAUDE.md を公式の目安（200行）に収めると63%減 Claude Code の全体像はClaude Code｜2026年版・インストールからCLAUDE.md・Hooks・本番運用までの実装手引きにまとめています。本記事はそのうち「自分が今どれだけ使っているかを知る」という一点に絞ります。上限そのものがどう変わるのかはClaude Code 制限まとめ｜9/14に週次上限が恒久+25%＝今日比17%減、一次ソースで検証を参照してください。 Claude Code 使用量 確認の全体像——6つの窓口と守備範囲 まず窓口を並べます。「どれを見ればいいか」は、個人か組織かとサブスクかAPIかで変わります。 同じ「使用量」でも、見ている対象と粒度が窓口ごとに違う。 窓口 見えるもの 対象 集計の粒度 /usage プラン枠の消費バー・内訳・振る舞いフラグ 個人・サブスク この端末の24時間／7日 /context いま何がコンテキストを占めているか 個人 現在のセッション /insights 作業傾向のHTMLレポート 個人 この端末の直近セッション最大200件 ステータスライン コンテキスト使用量・コスト・キャッシュ 個人 リアルタイム OpenTelemetry 利用者別トークン・コスト・ツール活動 組織 ほぼリアルタイム 組織アナリティクス／Console 利用者別の支出・採用状況 組織 日次更新 公式ドキュメントは、この使い分けを「組織がどうサインインしたかで各開発者の計測方法が決まる」と説明しています。サインイン方法が混在している組織では、開発者ごとに見るべき窓口が違うことになります。 /usage を読む——5つのブロックと、そこに含まれないもの 英語圏で「claude code usage」と呼ばれる話題の中心がこのコマンドです。/usage は1画面に複数のブロックを積んで表示します。それぞれ意味が違うので分解します。 1. Session ブロック。現在のセッションのトークン統計とドル金額です。ここで最も誤解されるのが金額の扱いで、公式ドキュメントはこの数字がトークン数からローカルで定価をもとに計算した見積りであること、Max / Pro 契約者にとっては請求上の意味を持たないことを注記しています。組織が契約レートを持つ場合は modelPricing を管理設定で配布すると表示が契約レートに揃い、Total cost の行に「組織の設定レートによる」という注記が付きます。なお /clear で新しいセッションを始めるとこの合計はリセットされます（v2.1.211 より前は /clear をまたいで累積し続けていました）。 2. Prompt cache ブロック。最初のAPI応答のあとに現れ、リクエスト数・入力トークンのうちキャッシュから読まれた割合・ミス回数・キャッシュが今温かいかを1行にまとめます。ミスの定義が具体的で、キャッシュから読めたはずの内容の5%超かつ2,000トークン以上を再処理したリクエストをミスと数えるとされています。/compact などで会話自体を書き換えた直後のミスは「期待される再構築」として区別されます。 3. Plan usage breakdown。Pro / Max / Team / Enterprise で表示され、ここが実務では一番役に立ちます。 ・帰属（Attribution）：スキル・サブエージェント・プラグイン・MCPサーバー別の消費割合。MCPサーバーの取り分は、そのツール結果を実際に消費したリクエストのみを計上する（v2.1.222 より前は、一度呼んだあとの全リクエストをそのサーバーに帰属させて過大表示していた） ・振る舞いフラグ：長すぎるコンテキストやキャッシュミスなど、直近の消費の10%以上を占める振る舞いに立つ ・ループ：/loop などの定期タスクのうち重いものを、発火間隔・実行回数・総トークン・1回あたり・最終実行つきで表示（v2.1.242 以降） 4. usage-credits の行。追加利用分が有効なときだけ出ます。Pro / Max は当月の支出と上限、Team / Enterprise は自分の支出と適用される上限が表示されます。 5. 取得に失敗したとき。使用量エンドポイントがレート制限されると、直近60分以内に読めた最後のバーを「Showing last-known usage」という注記つきで表示します。r で再試行できます。 /usage に含まれないもの ここが本記事で最も伝えたい点です。公式ドキュメントは /usage の数字について、「概算であり、このマシンのローカルなセッション履歴から計算されている。したがって他のデバイスや claude.ai からの利用は含まれない」と明記しています。 「枠が減っているのに /usage は少なく出る」場合、まずこの差を疑う。 サブスクの枠は Claude チャット・Cowork とも共有されるため、ブラウザで Claude と会話した分も週次枠を減らしますが、/usage のバーには反映されません。ノートPCとデスクトップを併用している場合も、それぞれの /usage は自分の端末分しか見ていません。「思ったより早く上限に当たる」という状況の多くは、この非対称が原因です。 Prompt cache の行にも範囲の制限があります。公式ドキュメントは、この行がメインの会話だけを対象としており、サブエージェント分は含まないことを明記しています。サブエージェントを多用する運用ではキャッシュ効率の実像がここに出ません。 手元で実行できないもの /usage・/context・/insights は Claude Code の対話セッション内で打つスラッシュコマンドで、シェルからは実行できません。本記事のこれらの記述は公式ドキュメントからの引用であり、当サイトの実測ではありません。 一方、後半の count_tokens を使った計測はシェルから実行でき、当サイトで実際に測った値です。両者を混ぜないよう、節ごとに出典を明示しています。検証環境の版は claude --version で 2.1.241 でした。 コンテキストの中身を見る /context、傾向を見る /insights /usage が「どれだけ使ったか」なら、/context は「いま何が場所を取っているか」です。公式ドキュメントは MCP のオーバーヘッド削減の文脈でこのコマンドを挙げており、MCPのツール定義は既定で遅延読み込みされる（Claudeが実際にそのツールを使うまでツール名とサーバー説明だけがコンテキストに入る）としつつ、それでも /context で占有を確認し /mcp から未使用サーバーを無効化することを勧めています。 同時に、gh・aws・gcloud・sentry-cli のようなCLIツールのほうが常にコンテキスト効率が良いとも明言されています。ツール一覧の登録が一切増えないためで、MCPサーバーを入れる前に「CLIで足りないか」を先に考える順序になります。 /insights は毛色が違い、トークン数ではなく働き方のレポートを出します。直近セッションを解析して、何に取り組んでいるか・誤解や不具合といった摩擦点・改善案をHTMLで書き出します。1回の実行で未解析のセッションを最大200件まで扱い、非常に短いものは飛ばします。出力は ~/.claude/usage-data/report.html に置かれ、実行ごとのタイムスタンプ付きコピーも残ります。 なお当サイトの検証環境では ~/.claude/usage-data/ がまだ存在しませんでした。/insights を一度も実行していない環境ではこのディレクトリ自体が作られないという点は、手元で確認できた挙動です。 ls ~/.claude/usage-data/ # → No such file or directory（/insights 未実行の環境） 組織で見る——OpenTelemetry と管理コンソール 個... --- ## Claude Code 制限まとめ｜9/14に週次上限が恒久+25%＝今日比17%減、一次ソースで検証 - URL: https://ai-heartland.com/explain/claude-code-usage-limit-2026/ - 更新日: 2026-08-30 - カテゴリ: explain - 概要: Claude Code 制限が2026年9月14日に変わる。週次上限は標準比で恒久+25%だが、5月から続く50%増が終わるため今日比では17%減。どちらも正しく基準が違うだけ。告知3連スレッドの原文と投稿時刻を機械取得して検証し、公式docsに記載が無いことまで整理する。 - タグ: claude-code, anthropic, 制限, 開発環境 Claude Code 制限が2026年9月14日に変わります。公式アカウント @ClaudeDevs は「週次上限を恒久的に25%引き上げる」と告知しましたが、同じスレッドで「今日と比べると17%の削減になる」とも述べています。この2つは矛盾しておらず、比較の基準が「標準」か「今日」かという違いでしかありません。本記事では告知3連スレッドの原文と投稿時刻を機械的に取得して検証し、そもそもClaude Code の制限が何種類あるのか、公式ドキュメントに何が書かれていて何が書かれていないのかまでを、推測を混ぜずに整理します。 「+25%」と「−17%」が同時に成立する理由は、比べている相手が違うことに尽きる。 30秒でわかる 9月14日の変更 ・変わるのは週次上限だけ。ローリング5時間のセッション枠には告知でもリプライでも一切言及がない ・標準比では恒久+25%、今日比では17%減。5月13日から続く「50%増」が9月13日で終わるため ・17%はAnthropic自身の計算。当サイトの解釈ではなく、同一スレッドの2投稿目で明言されている ・算術でも一致。1.25 ÷ 1.50 = 0.833 → 約16.7%減 ・上限の絶対値は非公開。料金ページにもヘルプにも週次上限の数値は無く、比率でしか語れない ・公式ドキュメントには未記載（2026-08-30時点）。一次ソースは現状Xスレッドのみ Claude Code そのものの導入・設定・運用の全体像は、Claude Code｜2026年版・インストールからCLAUDE.md・Hooks・本番運用までの実装手引きにまとめてあります。本記事はそこから「利用上限」という一点だけを切り出します。 Claude Code 制限の全体像——3種類あるうち変わるのは「週次」だけ 「制限に当たった」という話が噛み合わないのは、Claude Code 制限が1つではないからです。「claude code 上限」「claude code 週次制限」と呼び分けられているものも、指しているレイヤーが違うだけで同じ話をしていることがあります。公式ドキュメントの記述を整理すると、サブスクリプションプランで効いてくる枠は3系統に分かれます。 今回の告知が触れているのは一番上の層だけ。下2層に読み替えてはいけない。 枠の種類 リセットの単位 モデルを変えれば回避できるか 9/14の変更対象 週次の上限 週単位のウィンドウ いいえ（全モデル共通） これが対象 ローリング5時間のセッション枠 直近5時間 いいえ（全モデル共通） 言及なし＝未確認 モデル別の枠（Opus / Sonnet など） モデルごと はい（/model で別系統へ） 言及なし＝未確認 この区別は、公式ドキュメントが管理者向けに書いている「開発者が上限について聞いてきたとき」の節に対応しています。同ドキュメントは、「You’ve hit your session limit」「You’ve hit your weekly limit」というメッセージは全モデル共通の枠なので /model でモデルを切り替えても回復しない一方、「You’ve hit your Opus limit」のようなモデル名入りのメッセージなら別系統のモデルへ移れば作業を続けられる、と両者を明確に区別しています。エラーメッセージの文面がそのまま切り分けの手掛かりになるという設計です。 なお Team / Enterprise プランでは、この枠は「シート（座席）ごとの割当」として扱われ、ローリング5時間と週次の両方のウィンドウでリセットされます。この割当は Claude チャットや Cowork とも共有されるため、Claude Code だけを使っていなくても週次の枠は減っていきます。 9月14日の変更——「+25%」と「−17%」はどちらも正しい 告知の1投稿目の原文はこうです（2026-08-29T16:47:23Z＝日本時間 2026-08-30 01:47）。 Starting September 14, we’re permanently raising standard weekly limits in Claude Code by 25% for Pro, Max, Team, and seat-based Enterprise plans. Until then, the current 50% increase will be in place. 訳すと「9月14日から、Pro / Max / Team / シートベース Enterprise プランについて、Claude Code の標準の週次上限を恒久的に25%引き上げる。それまでは現行の50%増が適用される」となります。読み違いが起きるのは standard（標準） という語です。25%が乗る相手は「今の状態」ではなく「標準」です。 そして同じスレッドの2投稿目で、Anthropic 自身がその含意を先回りして説明しています。 Compared to today, this works out to a 17% reduction in weekly limits on Claude Code. どちらの数字も操作されていない。分母が違うだけ。 算術で確認します。標準の週次上限を 100 とすると、 ・2026年5月13日〜9月13日は 50%増＝150 ・2026年9月14日以降は 恒久+25%＝125 ・125 ÷ 150 = 0.8333… → 約16.7%減 Anthropic の言う「17% reduction」はこの計算と一致します。つまり「+25%」も「−17%」も広報上のスピンではなく、単に基準が違う2つの正しい記述です。片方だけを見出しにすると必ず誤解を生むので、本記事では両方を併記しています。 3投稿目は「持続的に提供できる水準を見極める間、付き合ってくれてありがとう」という趣旨の謝辞で、供給側の制約が背景にあることを示唆しています。ただし具体的な容量やコストの内訳は述べられていないため、理由については推測を書きません。 50%増はいつ始まり、なぜ終わるのか——告知の時系列 今回の変更は突然出てきたものではなく、5月から4回にわたって延長されてきた暫定措置の着地点です。@ClaudeDevs の過去投稿を投稿IDと時刻つきで並べると、経緯が読み取れます。 timeline title Claude Code 週次上限の推移（すべて @ClaudeDevs の告知） 2026-05-13 : 週次上限を50%増 : 期限は7月13日 2026-07-18 : 50%増を延長 : 期限を8月19日へ 2026-08-18 : さらに延長し8月31日へ : 「恒久化したいが容量が厳しい」 2026-08-29 : 9月14日から恒久+25% : 50%増は終了 投稿時刻（UTC） 投稿ID 内容 2026-05-13T19:07:51Z 2054639777685934564 週次上限を50%増。期限は7月13日 2026-07-18T16:04:15Z 2078511173759324328 50%増を8月19日まで延長 2026-08-18T19:35:49Z 2089798442306711646 8月31日まで再延長。「恒久化したいが、モデルへの需要が強く今後数週間は容量が厳しくなりうる」 2026-08-29T16:47:23Z 2093742321473065266 9月14日から恒久+25%（＝50%増は終了） 注目すべきは3件目です。2026年8月18日の時点で Anthropic は「恒久化したい（We hope to make this a permanent change）」と述べつつ、同じ文で容量の逼迫に言及していました。その11日後の着地が「50%ではなく25%で恒久化」だったことになります。「恒久化する」という約束自体は守られ、水準だけが下がった、という読み方が原文に忠実です。 なお、これらの本文と投稿時刻は X の syndication エンドポイントから機械的に取得したもので、翻訳やスクリーンショットを経由していません。日本語圏で出回っている要約には、翻訳の過程で「標準比」と「今日比」が混ざっているものがあります。 この変更は公式ドキュメントにまだ載っていない 記事化にあたり、Anthropic 側の一次資料を順に確認しました。2026年8月30日時点で、この変更を記載した公式ドキュメントは見つかりませんでした。 確認先 週次制限の記述 9/14・25% の記載 公式docs Manage costs effectively あり（枠の存在・エラーメッセージの見分け方） なし ヘルプセンター Usage limit best practices（記事日付 2026-06-02） あり（確認方法のみ） なし ヘルプセンター Using Claude Code with your Pro or Max plan 「Pro/Max の枠は Claude と Claude Code で共有」のみ なし claude.com/pricing 「利用上限が適用される」とのみ なし 未確認として明記しておくこと ・「標準の週次上限」の絶対値（トークン数・メッセージ数・時間）は、Anthropic がどの公開資料でも示していない。したがって「+25%されると何ができるようになるか... --- ## MCP Appsとは｜MCPサーバーがUIを配る拡張仕様の対応ホストと、ライセンス4表示のズレを実測 - URL: https://ai-heartland.com/explain/mcp-apps-explained/ - 更新日: 2026-08-30 - カテゴリ: explain - 概要: MCP AppsはMCPサーバーがインタラクティブUIを配れるようにする拡張仕様である。公式リポジトリを実測したところ、ライセンス表示が4か所で食い違い、ターミナルのCLIには描画の実装自体が入っていないことが分かった。対応ホストの実態を一次ソースで整理する。 - タグ: mcp, プロトコル, UI, オープンソース MCP Apps は、MCPサーバーがチャートやフォームのようなインタラクティブUIをチャットの中に描画させるための拡張仕様です。日本語の紹介はすでに複数出ていますが、その多くは公式サンプルを動かした体験記で、「結局どのクライアントで見えるのか」「ライセンスはどうなっているのか」といった、採用判断に必要な部分が抜けています。本記事では公式リポジトリと実行バイナリを直接調べ、対応ホストの実態と4か所で食い違うライセンス表示を一次ソースで確定させました。 「MCP Apps対応」はホストごとに意味が違う。まずどこで見えるかを確定させる。 30秒でわかる MCP Apps ・MCPの拡張仕様。サーバーがUIリソースを宣言し、ホストがサンドボックス化iframeで描画する ・公式リポジトリは modelcontextprotocol/ext-apps（★2,771）。仕様の版は 2026-01-26 と draft ・ターミナルのCLIには描画の実装が無い。Claude Code v2.1.241 のバイナリに ui:// は0件 ・非対応ホストでも壊れない。段階的強化の設計で、UIが無ければテキストが返る ・ライセンス表示が4か所で食い違う。NOASSERTION／Apache 2.0／MIT／移行期の3系統 MCPサーバーそのものの作り方はMCPサーバーの作り方2026年完全ガイド：TypeScript・Python両対応チュートリアルにまとめてあります。プロトコルの仕組みから押さえたい場合はMCPとは何か？仕組み・3プリミティブ・仕様改訂の流れを図解で理解するが入口です。本記事はその上に乗る拡張仕様の話に絞ります。 MCP Apps とは——テキストしか返せなかったMCPにUIを足す MCPは、AIアシスタントに対してツールとリソースを公開する仕組みです。ただし応答はテキストと構造化データに限られていました。公式ドキュメントは、それでは足りない用途を4つ挙げています。 ・データ可視化 — チャート、グラフ、更新され続けるダッシュボード ・リッチメディア — 動画プレイヤー、音声波形、3Dモデル ・対話フォーム — 複数ステップのウィザード、設定パネル、承認フロー ・リアルタイム表示 — ライブログ、進捗表示、ストリーミング MCP Apps が解こうとしているのは、これらをホストごとにバラバラに実装していた状況です。公式ドキュメントの説明は率直です。 Before MCP Apps, each host implemented UI support differently. MCP-UI, OpenAI’s Apps SDK, and custom implementations all solved similar problems with incompatible approaches. サーバー開発者はホストごとにアダプタを保守する必要があり、セキュリティモデルもまちまちでした。MCP Apps はそこを1つに揃えるという位置づけです。 リポジトリの実測値も確認しました。 項目 実測値（2026-08-30 時点） リポジトリ modelcontextprotocol/ext-apps star / fork 2,771 / 369 オープンIssue 208件 作成 2025-11-21 最終push 2026-08-12 仕様のバージョン 2026-01-26 と draft の2ディレクトリ npm パッケージ @modelcontextprotocol/ext-apps 最新バージョン v1.7.5（2026-07-23 公開）／公開32バージョン 直接依存 1個（@standard-schema/spec） 配布物 40ファイル・1.4MB。エントリポイント7種（./react / ./server / ./app-bridge 等） 依存が1個というのは仕様SDKとしては潔い構成です。React向けのエントリポイントが分かれているので、UI側の実装言語は事実上Webフロントエンドになります。 MCP Apps は結局どこで見えるのか ここが最初に確定させるべき点です。公式READMEの「Supported Clients」に並んでいるのは次の8つでした。 ホスト リンク先のドキュメント ChatGPT OpenAI の Apps SDK ドキュメント Claude claude.com のコネクタ向けドキュメント VS Code 2026-01-26 付のMCP Apps対応ブログ Goose Block の MCP Apps チュートリアル Postman MCPリクエストの操作ドキュメント MCPJam MCP Apps のサンプル記事 mcp-use インスペクタ Alpic プレイグラウンド 注目したいのは「Claude」のリンク先が claude.com/docs/connectors/… である点です。これは Claude のコネクタ（デスクトップ／Web）向けのドキュメントで、ターミナルで動く Claude Code CLI ではありません。 そこで、手元の Claude Code v2.1.241 の実行バイナリを直接検索しました。 検索した文字列 ヒット数 意味 ui:// 0 MCP Apps のUIリソーススキームが存在しない MCP Apps 3 後述。いずれも設定の説明文 iframe（対照群） 139 iframe という語自体は存在する widget（対照群） 29 widget という語自体は存在する ui:// が0件というのが決定的です。MCP Apps はUIリソースを ui:// スキームで宣言する設計なので、これを解釈するコードが無ければウィジェットは描画できません。対照群として iframe や widget が3桁・2桁ヒットすることを確認しているので、「検索方法が悪くて見つからない」わけではありません。 では残る3件の「MCP Apps」は何かというと、すべて設定の説明文でした。非必須トラフィックを無効化する設定について、こう書かれています。 connectors that return MCP Apps show the text tool result instead of the widget ウィジェットの代わりにテキストのツール結果が出る——これは次節の「段階的強化」がそのまま現れた記述です。CLI側は、その挙動を説明するテキストを持っているだけで、描画の実装は持っていません。 したがって、試すならホストを選ぶところから始めます。 ターミナルで claude を起動して「MCP Apps のUIが出ない」と悩んでも、それは仕様どおりです。手軽に確認したいなら、READMEが挙げるインスペクタ系（MCPJam / mcp-use / Alpic のプレイグラウンド）か、VS Code を使うのが早道です。 なお本記事はバイナリ内の文字列検索と公式ドキュメントの読解までを実測範囲としており、各ホストで実際にウィジェットが描画されるところまでは検証していません。 「MCP Apps対応」の8ホストと、実装を持たないターミナルCLI。まずここを分ける。 MCP Apps の設計——壊れない仕組みとサンドボックスの前提 MCP Apps の設計で実務上いちばん効くのが、この性質です。公式ドキュメントの記述はこうです。 MCP Apps is designed for graceful degradation. Hosts advertise their UI support when connecting to servers; servers check these capabilities before registering UI-enabled tools. If a host doesn’t support MCP Apps, tools still work — they just return text instead of UI. 流れを整理すると3段階です。 ホストが接続時にUI対応の有無を通知する（capability negotiation） サーバーがそれを見て、UI付きツールを登録するか決める 非対応なら、ツールはテキストを返す そして公式ドキュメントは「UIは要件ではなく段階的強化である」と明言しています。サーバー実装者から見れば、MCP Apps に対応しても既存のホストを壊さないということです。これは「対応クライアントが限られている拡張仕様」を採用する際の最大の懸念に、仕様側が最初から答えている形になります。 flowchart TD A["MCPサーバー"] -->|"接続"| B["ホスト（チャットクライアント）"] B -->|"UI対応の有無を通知"| A A --> C{"ホストはUI対応か"} C -->|"対応する"| D["UI付きツールを登録ui:// のリソースを宣言"] C -->|"対応しない"| E["通常のツールとして登録"] D --> F["サンドボックスiframeで描画AppBridge 経由で通信"] E --> G["テキストのツール結果（壊れない）"] セキュリティ設計——同一オリジンを持たないiframeという前提 MCP Apps のUIは、通常のWebアプリ... --- ## TapMapとは｜PCの通信先を世界地図でリアルタイム可視化するOSS、自身の外部通信も実測で確認した - URL: https://ai-heartland.com/tool/tapmap-network-visualizer/ - 更新日: 2026-08-30 - カテゴリ: tool - 概要: TapMapは自分のPCがどこへ通信しているかを世界地図にリアルタイム描画するOSS（★1,390）。macOSでv1.10.1をソースから起動し、TapMap自身の外部通信が条件別に0件・1件へ変わることまで実測した。導入手順とLittle Snitchとの違いも解説。 - タグ: automation, ネットワーク, 可視化, セルフホスト, Python 自分のPCが今この瞬間、世界のどこと通信しているのか——普段は誰も見ていない。TapMap（★1,390・MIT）は、その通信先を世界地図の上にリアルタイムで描くだけのPython製OSSだ。本記事では v1.10.1 を macOS 上でソースから動かし、画面に何が出るかだけでなく、TapMap自身がどこへ何回通信するのかを条件を変えて3回実測した結果までまとめる。 実際に動かしたTapMap v1.10.1（筆者環境・2026-08-30）。右パネルの「NEW APPS」に Claude Code・Claude・bun、「NEW PROVIDERS」に Anthropic, PBC・Telegram Messenger Inc が並んでいる。自分の位置マーカーは TAPMAP_LON/TAPMAP_LAT で東京に固定した（画面下の MYLOC: ENV） 30秒でわかるTapMap ・やること：OSのソケット情報を読み、接続先IPをローカルのGeoIP DBで地理情報に変換して世界地図に描く ・やらないこと：遮断（ファイアウォールではない）・外部ホストへの探索（スキャナではない） ・自身の外部通信：GeoIP DB未導入なら0件。DB導入後の既定設定で1件だけ（api.ipify.org へ公開IP照会）。座標を手動指定すれば0件に戻る（すべて本記事の実測） ・待ち受け：127.0.0.1:8050 の1本のみ。LANからは到達しない ・導入コスト：GeoIP DB（DB-IP Lite）で133.4 MB・3.3秒。アカウント登録不要 ワークフロー自動化やセルフホスト運用の全体像は「AI自動化ツール｜ノーコードからコードまで2026年版の比較と選び方」で整理している。本記事はその中でも「自分の環境で何が起きているかを見る」側のツールを扱う。 TapMapとは——通信先を世界地図に描くだけのツール TapMapは2026年2月に公開されたPython製のネットワーク可視化ツールだ。作者はノルウェーの Ola Lie 氏で、How-To Geek・MakeUseOf といった海外メディアにも取り上げられている。日本語の解説記事は、本記事の執筆時点で検索上位に見当たらない。 動作の流れは README が明示している4段構成で、驚くほど単純だ。 flowchart LR A["OSのソケット情報macOS: lsofWin/Linux: psutil"] --> B["接続先IPの抽出"] B --> C["ローカルGeoIP DBで座標・国・ASNに変換"] C --> D["Dash + Plotly で世界地図に描画"] 重要なのはパケットを見ていないという点だ。TapMapが読むのはOSがすでに持っている「今つながっているソケットの一覧」であって、通信の中身でもなければ、キャプチャでもない。だから管理者権限のパケットキャプチャ設定も要らないし、通信内容がTapMapに渡ることもない。 画面に出る情報 起動すると地図の下に1行のステータスラインが出る。筆者環境での実際の表示はこうなっていた。 ・LIVE: TCP 102 EST 89 LST 11 UDP R 6 B 6 — 今この瞬間のソケット内訳（TCP総数102、確立済み89、待ち受け11） ・CACHE: SOCK 93 SERV 51 MAP 26 UNM 0 LOC 25 — 蓄積されたソケット・サービス・地図上の点・未マップ・地点の数 ・MYLOC: ENV — 自分の位置の決め方（AUTO＝公開IPから推定／ENV＝環境変数で手動指定／OFF＝表示しない） 右側のパネルには「今日はじめて見たもの」が並ぶ。NEW APPS（新しく通信したアプリ）、NEW PROVIDERS（新しく出てきた接続先の組織）、NEW COUNTRIES（新しい国）、NEW PORTS（新しいポート）だ。この「初めて見たものだけを出す」設計が、常時大量に流れる通信の中から異変を拾う実用性を作っている。 左上のハンバーガーメニュー。INSIGHTS（日次レポート／インサイトパネル）、NETWORK、TOOLS、INFO の4系統。GeoIPデータベースの導入と更新はここから行う 実測：TapMap自身は外部と通信するのか READMEは冒頭で「Runs locally. No telemetry.」と書いている。一方で PRIVACY.md には「既定では公開IP取得のために外部サービスへ問い合わせる」とも書いてある。この2つは矛盾しないが、結局どこへ何回つなぐのかは文章からは分からない。測った。 測り方 lsof を繰り返し叩くポーリングでは取りこぼす。TapMapの公開IP照会はタイムアウト2秒の短命コネクションで、実際に0.2〜0.33秒間隔のポーリングを合計3回・約145秒ぶん回しても1度も捕まえられなかった。そこで呼び出しそのものを記録する方式に変えた。socket.socket.connect と socket.getaddrinfo をラップしてから TapMap を起動し、ループバック宛以外の呼び出しを全件ログに落とす。取りこぼしが構造的に起きない。 この状態でブラウザからUIを開き（Dashのコールバックを実際に走らせないと位置解決処理が動かない）、各条件を約55〜58秒間そのまま動かした。 結果 # 条件 外向きの接続 外部への名前解決 A GeoIPデータベース未導入（初回起動そのまま） 0件 0件 B DB-IP Lite導入済み・既定（MYLOC: AUTO） 1件 1件 C DB-IP Lite導入済み・TAPMAP_LON/TAPMAP_LAT で座標指定 0件 0件 条件Bで観測された唯一の外向き接続は、起動から0.62秒後の api.ipify.org:443 に対する名前解決と、続く 104.26.13.205:443（whois で OrgName: Cloudflare, Inc. / NetName: CLOUDFLARENET）への接続1回だけだった。以後58秒間、追加の外向き通信は観測されなかった。ソースを追うと位置解決の関数はアプリのコンストラクタから1回だけ呼ばれており（ポーリングのたびに呼ばれる作りではない）、観測結果と整合する。 ソースを読むと、公開IPの取得先は4つ用意されている（api.ipify.org → checkip.amazonaws.com → ifconfig.me/ip → icanhazip.com）が、これはフォールバックの連鎖であって並列照会ではない。最初の1つが成功する限り、残る3つには接続しない。実測でもそうなった。 条件Aが0件になる理由もソースで裏が取れる。位置を自動推定する処理は「GeoIPの都市データベースが有効か」を先に確認し、無効なら公開IP照会に到達せず即座に打ち切られる。GeoIPデータベースを入れるまで、TapMapはネットワークに一切触れない。 この順序は使う側にとって実用的な意味を持つ。まず素の状態で起動して画面を見るぶんには、TapMapは外へ何も出さない。GeoIPデータベースが無いと地図に点は乗らないが、ステータスラインのソケット内訳とプロセス名の一覧は表示される。「まず挙動を確かめてから地図機能を有効にする」という段階的な導入ができる作りになっている。 なお「外部への名前解決0件」は、TapMapのプロセスが getaddrinfo を呼んでいないことを指す。OSのDNSキャッシュや他プロセスの通信まで止まるわけではないので、そこは混同しないでほしい。 TapMap v1.10.1 自身の外向き通信（筆者実測・macOS・各58秒）。「No telemetry」は本当だが、既定では公開IP照会が1回だけ走る 待ち受けはループバックのみ 同時に待ち受け側も確認した。環境変数を何も付けずに起動して lsof -i -nP -a -p <pid> を叩くと、LISTEN ソケットは 127.0.0.1:8050 の1本だけだった（config.py の SERVER_PORT の既定値どおり。上のegress実験では他プロセスとの衝突を避けるため TAPMAP_PORT=8099 に変えており、そちらでも同じく1本のみ）。バインド先は環境変数 TAPMAP_HOST を指定しない限りループバック固定で、LANからは到達しない。Docker で動かす場合だけは --network host が前提になるので条件が変わる。 インストールして動かす 配布物としては Windows インストーラ / macOS の .dmg / Linux の .deb が Releases に置かれている。ここでは検証と同じ「ソースから動かす」手順を示す。なお pyproject.toml に requires-python の宣言は無く、公式が必要Pythonバージョンを明示していない（[tool.ruff] target-version = "py310" はlintの構文ターゲットであって実行要件ではない）。本記事の検証は Python 3.14.4 で行い、そこでは問題なく動いたとだけ書いておく。 # 1) 取得して隔離環境に入れる git clone --depth 1 https://github.com/olalie/tapmap.git cd tapmap pyth... --- ## Supabase MCPとは｜ホスト版とローカル版の違いと、read-onlyで消える10ツールを実測 - URL: https://ai-heartland.com/tool/supabase-mcp-server-guide/ - 更新日: 2026-08-30 - カテゴリ: tool - 概要: Supabase MCPには3つの提供形態があり、公式が今すすめているのはホスト版のリモートMCPである。ローカル版を実際に起動して29ツール8,205トークンを計測し、--read-onlyで消える10ツールと消えない1ツールを特定した。安全に絞る設定まで実測で示す。 - タグ: mcp, supabase, データベース, MCPサーバー, オープンソース Supabase MCP を調べると、npm パッケージ・mcp.supabase.com というエンドポイント・localhost:54321 の3つが同時に出てきます。名前はどれも「Supabase MCP」ですが、認証方式も設定方法も別物です。本記事では公式ドキュメントで現在の推奨を確定させたうえで、ローカル版を実際に起動して29ツール・約8,205トークンを計測し、--read-only で消える10ツールと消えない1ツールを特定しました。 同じ「Supabase MCP」でも3系統ある。実測したのは一番下のローカル版。 30秒でわかる Supabase MCP ・提供形態は3つ。ホスト版 mcp.supabase.com/mcp（公式が先に案内）／Supabase CLI の localhost:54321/mcp／npm の stdio 版 ・既定は29ツール・21,094バイト・約8,205トークン。接続しているだけで毎セッション掛かる ・--read-only で19ツールに減る（約5,494トークン）。消えるのは書き込み系の10ツール ・ただし execute_sql は残る。説明文も通常時とバイト単位で同一だった ・--features=database なら5ツール・約1,096トークン。既定比13%まで落ちる MCPサーバーの仕組みと自作の手順は、MCPサーバーの作り方2026年完全ガイド：TypeScript・Python両対応チュートリアルにまとめてあります。本記事は既製の公式サーバーを繋ぐ側の話です。 Supabase MCP の3つの提供形態 まず「どれの話をしているか」を確定させます。公式ドキュメント（supabase.com/docs/guides/ai-tools/mcp）を読むと、案内の順序と中身がはっきりしています。 形態 エンドポイント／パッケージ 認証 位置づけ ホスト版（リモートMCP） https://mcp.supabase.com/mcp OAuth（既定） 公式ドキュメントが先に案内。機能グループ等をURLクエリで指定 Supabase CLI（ローカル開発） http://localhost:54321/mcp ローカル CLIでローカル開発しているときに利用可能 ローカル stdio 版 @supabase/mcp-server-supabase（npm） パーソナルアクセストークン 自分のマシンでNodeプロセスとして動かす ホスト版のURLはクエリパラメータで挙動が変わります。公式ドキュメントに載っている形はこうです。 https://mcp.supabase.com/mcp?features=docs,account,database,debugging,development,functions,branching https://mcp.supabase.com/mcp?project_ref=abc123&read_only=true 認証なしで叩くと HTTP 401 が返ります（実測）。エンドポイント自体は生きていて、認証が必要というだけです。 リポジトリ側の状況も確認しました。 項目 実測値（2026-08-30 時点） リポジトリ supabase/mcp（Supabase公式org） star / fork 2,880 / 401 ライセンス Apache-2.0 オープンIssue 114件 作成 2024-12-20 最終push 2026-08-29（前日） npm パッケージ @supabase/mcp-server-supabase 最新バージョン v0.11.0（2026-08-20 公開）／公開59バージョン 直接依存 6個（@supabase/mcp-utils / graphql / openapi-fetch 等） インストール実測 14パッケージ・21MB 開発は活発です。 前日にpushがあり、59バージョンが公開されています。「公式が実質メンテナンス終了」と明記していた Notion MCPとは｜ホスト版とローカル版の違いを24ツール・21,831トークン実測で解説 のケースとは状況が違い、Supabase はローカル版もホスト版も現役です。ただし案内の順序としてホスト版が先なので、新規に始めるならそちらが素直です。 Supabase MCP のインストールと登録 ホスト版を登録する URLを登録するだけで、パッケージのインストールは不要です。 claude mcp add --transport http supabase-hosted "https://mcp.supabase.com/mcp?read_only=true" 登録直後のメッセージはクエリを省いて表示しますが、設定には保持されています。 実行すると Added HTTP MCP server supabase-hosted with URL: https://mcp.supabase.com/mcp と、?read_only=true を省いた形で表示されます。表示上省かれているだけで、設定ファイルを開くと "url": "https://mcp.supabase.com/mcp?read_only=true" とクエリ込みで保存されていました（実測）。メッセージを見て「パラメータが消えた」と勘違いしないでください。 ローカル版を登録する パーソナルアクセストークンを環境変数で渡します。 claude mcp add supabase --env SUPABASE_ACCESS_TOKEN=sbp_xxxxxxxx -- \ npx -y @supabase/mcp-server-supabase@latest --read-only 登録後の確認は次の通りです。実測では ✔ Connected が返りました。 claude mcp list Supabase MCP のツールは29個——--read-only で何が消えるか ここからが実測です。stdio で起動して tools/list を取得し、フラグを変えながら差分を取りました。 起動オプション ツール数 tools/list バイト トークン 既定比 （なし） 29 21,094 約 8,205 100% --read-only 19 13,911 約 5,494 67% --features=database 5 2,940 約 1,096 13% --features=database,docs --read-only 5 4,487 — — 既定の29ツールは、プロジェクト管理・データベース・ログ・Edge Functions・ブランチングまでを一通り含みます。 search_docs, list_organizations, get_organization, list_projects, get_project, get_cost, confirm_cost, create_project, pause_project, restore_project, list_tables, list_extensions, list_migrations, apply_migration, execute_sql, query_logs, get_advisors, get_project_url, get_publishable_keys, generate_typescript_types, list_edge_functions, get_edge_function, deploy_edge_function, create_branch, list_branches, delete_branch, merge_branch, reset_branch, rebase_branch --read-only を付けて差分を取ると、消えるのはちょうど10個でした。 --read-only で消えるツール 種別 apply_migration スキーマ変更 create_project / pause_project / restore_project プロジェクト操作 deploy_edge_function デプロイ create_branch / delete_branch / merge_branch / reset_branch / rebase_branch ブランチ操作 execute_sql は --read-only でも消えません。 差分を取った結果、execute_sql は19ツール側にも残っていました。さらに、通常時と --read-only 時で説明文がバイト単位で同一であることも確認しています（同じ文字列が返る）。 つまり読み取り専用の保証はツールを外すことではなく、データベース側のセッションで担保する設計です。ツール一覧を見ただけでは「SQLが実行できない状態になった」とは言えません。本記事は実データベースに接続しての挙動までは検証していません——--read-only を付けた状態で書き込みSQLが実際に弾かれるかは、ご自身のプロジェクトで確認してください。 消えるのは書き込み「操作」で、SQL実行の口そのものは残る。ここを取り違えない。 常駐コストを下げるなら --features が効く --read-only はツール数を3分の2にしますが、コンテキスト削減と... --- ## Claude Code アップデート完全ガイド｜旧版900MBが残る仕組みと二重インストールの見分け方 - URL: https://ai-heartland.com/explain/claude-code-update-guide/ - 更新日: 2026-08-30 - カテゴリ: explain - 概要: Claude Code アップデートで「更新したのにバージョンが変わらない」が起きる理由を実測で特定した。手元の環境ではPATH上に2つのclaudeが並び154リリース分ずれており、versionsディレクトリには使われていない旧版が900MB残っていた。claude doctorの読み方まで示す。 - タグ: claude-code, CLI, 開発環境, バージョン管理 Claude Code アップデートの手順そのものは claude update の1行で終わります。実際に人が詰まるのはその先で、「更新したのにバージョン番号が変わらない」「ディスクの空きが減り続ける」といった症状です。本記事では v2.1.241 の環境を実際に調べ、PATH上に154リリース分ずれた2つの claude が並んでいたこと、使われていない旧バイナリが900MB残っていたことを実測しました。原因が分かれば対処は数分で終わります。 1台のマシンで観測した「Claude Codeのバージョン」。どれを指しているかで話が噛み合わなくなる。 30秒でわかる Claude Code アップデート ・コマンドは claude update。版を指定するなら claude install stable|latest|<version> ・状態確認は claude doctor。導入方式・チャネル・自動更新の可否・直近の更新結果まで1画面で出る ・「更新しても変わらない」の主因はPATH上の二重インストール。検証環境では native 2.1.241 と npm 2.1.87 が同居していた ・旧バイナリは消えない。~/.local/share/claude/versions/ に3世代・900MBが残存していた ・自動更新は環境変数 DISABLE_AUTOUPDATER で止まる。チャネルは stable / latest Claude Code の全体像と初期セットアップは、Claude Code｜2026年版・インストールからCLAUDE.md・Hooks・本番運用までの実装手引きにまとめてあります。本記事は更新まわりだけを扱います。 Claude Code アップデートの3コマンドと、それぞれの役割 まずコマンドを整理します。claude --help に出るのは次の3つです。 コマンド 役割 claude update（別名 claude upgrade） 更新の有無を確認し、あれば導入する claude install [target] native ビルドを導入する。target に stable / latest / 具体的なバージョン番号を指定できる。--force で既存があっても上書き claude doctor インストールの健全性を確認する。設定ファイルも読む claude install にバージョン番号を直接渡せるのは覚えておく価値があります。特定の版で不具合が出たときに戻せるからです。stable と latest はチャネル名で、claude doctor の出力にも「Auto-update channel」として現れます。 # 更新の確認と導入 claude update # 版を指定して導入（stable / latest / 2.1.241 のような番号） claude install stable claude doctor の出力を1行ずつ読む 更新まわりの調査は、まず claude doctor から始めるのが最短です。実際の出力（環境依存の行は一部省略）を見ながら、何が読み取れるかを確認します。 claude doctor Claude Code doctor Running: native (2.1.241) Commit: c87e2742fc9a Platform: darwin-arm64 Path: /Users/<user>/.local/share/claude/versions/2.1.241 Config install method: native Search: OK (bundled) Auto-updates: disabled (set by env: DISABLE_AUTOUPDATER) Auto-update channel: latest Last update attempt: success → 2.1.241 (2026-08-25) Multiple installations found - npm-global at /Users/<user>/.nodebrew/node/v22.13.1/bin/claude - native at /Users/<user>/.local/bin/claude 1 warning found - Leftover npm global installation at /Users/<user>/.nodebrew/node/v22.13.1/bin/claude Fix: Run: npm -g uninstall @anthropic-ai/claude-code 判断に効く行は5つです。 行 読み取れること Running: native (2.1.241) いま動いている実体の導入方式とバージョン Path: その実体の絶対パス。シンボリックリンクの解決先 Auto-updates: 自動更新の可否と、無効ならその理由（この例では環境変数） Auto-update channel: stable か latest か Last update attempt: 直近の更新が成功したか、その結果どの版になったか、いつか Auto-updates: disabled (set by env: DISABLE_AUTOUPDATER) の括弧内が重要です。 「無効になっている」だけでなく「何によって無効にされたか」まで出るので、設定ファイルを探し回る必要がありません。 そして最後の2ブロック——「Multiple installations found」と警告が、次節の本題です。 更新の調査は doctor から始める。「なぜ無効か」まで書いてあるのが効く。 「アップデートしたのに変わらない」の正体——PATH上の二重インストール 検証環境で which -a claude を実行すると、2つ返ってきました。 which -a claude /Users/<user>/.local/bin/claude /Users/<user>/.nodebrew/current/bin/claude それぞれのバージョンを確認すると、差は劇的でした。 場所 導入方式 バージョン ~/.local/bin/claude native（先勝ち） 2.1.241 ~/.nodebrew/current/bin/claude npm グローバル 2.1.87 154リリース分の開きです。いまはPATHの順序で native 側が勝っているので実害は出ていませんが、PATHの順序が変わった瞬間に2.1.87が起動します。シェルの設定を触ったとき、別のNodeバージョンに切り替えたとき、あるいはCI環境で同じ手順を再現したときに、静かに数か月前のCLIが動くことになります。 「claude update を実行したのにバージョンが変わらない」という症状の多くはこれです。更新されたのは片方だけで、起動しているのはもう片方という状態になります。 claude doctor はこれを検出し、対処コマンドまで提示します。 Fix: Run: npm -g uninstall @anthropic-ai/claude-code 削除する前に、どちらを残すかを決めてください。 npm 側を消すのは「native 版を正とする」場合の手順です。逆にチーム全体を npm 管理で揃えたい場合は、native 側（~/.local/bin/claude と ~/.local/share/claude/）を片付けることになります。どちらでも動きますが、片方に寄せないと同じ問題が再発します。 なお claude doctor が出す Fix: はあくまで提案です。上の npm -g uninstall は本記事の検証環境では実行していません（実行すると環境が変わるため）。実行前に which -a claude で現状を確認してください。 旧バージョンは消えない——検証環境では900MBが残っていた もう1つの実測です。native 版はバージョンごとに実行ファイルを保存します。 du -sh ~/.local/share/claude/versions/* du -sh ~/.local/share/claude/versions/ 245M /Users/<user>/.local/share/claude/versions/2.1.220 310M /Users/<user>/.local/share/claude/versions/2.1.241 345M /Users/<user>/.local/share/claude/versions/2.1.243 900M /Users/<user>/.local/share/claude/versions/ 3世代で900MBでした。1つあたり245〜345MBあり、しかも世代が進むほど大きくなっています（2.1.220 の245MBに対し 2.1.243 は345MB、約1.4倍）。更新を重ねるほど蓄積するので、数か月放置すると数GB規模になります。 さらに注目したいのが、2.1.243 が置かれているのに動いているのは 2.1.241 だという点です。 readli... --- ## Claude Code Remote Controlとは｜待受ポート0本・SSE通信の実測と組織で無効化する設定 - URL: https://ai-heartland.com/explain/claude-code-remote-control-guide/ - 更新日: 2026-08-30 - カテゴリ: explain - 概要: Claude Code Remote Controlはスマホやブラウザから自宅のマシンを操作できるが、待受ポートを開くのか気になる人が多い。実際に起動してlsofで数えたところLISTENは0本で、通信はSSEの外向き接続だけだった。組織で止めるための管理設定まで実測で示す。 - タグ: claude-code, リモート, CLI, 開発環境 Claude Code Remote Control は、手元のマシンで動いている Claude Code を、スマホアプリや claude.ai/code から操作できる機能です。日本語の解説はいくつも出ていますが、「自宅PCに待受ポートが開くのか」「通信はどこへ行くのか」「会社で止められるのか」という、導入判断に直結する部分にはほとんど触れられていません。本記事では v2.1.241 で実際にサーバーを起動し、lsof でソケットを数え、デバッグログから通信方式を特定した結果を示します。 実際に起動して測った結果。inbound は1本も開かず、外向きのHTTPSだけで成立している。 30秒でわかる Claude Code Remote Control ・待受ポート（LISTEN）は0本。2回の起動で lsof を実行し、どちらも0本だった ・通信はSSE。受信 …/worker/events/stream／送信 …/worker/events へのPOST。宛先はwhoisで ANTHROPIC-V6 帯 ・組織での禁止は managed settings の disableRemoteControl の1本で全経路（コマンド・フラグ・自動起動・トグル）が止まる ・既定は同時32セッション。--spawn=worktree でセッションごとにgit worktreeへ隔離できる ・スマホ/Webでは添付ファイルが見えない。設定変更も effortLevel と ultracode に限られる Claude Code そのものの導入から運用までは、Claude Code｜2026年版・インストールからCLAUDE.md・Hooks・本番運用までの実装手引きにまとめてあります。本記事はリモート操作という一点に絞ります。 Claude Code Remote Control の起動と、画面に出るもの まず実際の挙動を押さえます。作業したいディレクトリで次を実行するだけです。 claude remote-control --name my-session 起動すると、次の情報が順に表示されます（実行結果から、環境固有のIDは伏せています）。 Remote Control v2.1.241 Spawn mode: same-dir Max concurrent sessions: 32 Environment ID: env_xxxxxxxxxxxxxxxxxxxxxxxx ·✔️· Connected · <ディレクトリ名> · HEAD Capacity: 1/32 · New sessions will be created in the current directory Continue coding in the Claude mobile app or https://claude.ai/code?environment=env_xxxxxxxxxxxxxxxxxxxxxxxx space to show QR code 読み取れる要素は4つです。 ・Environment ID（env_ で始まる）が発行され、接続用URLのクエリになる ・スペースキーでQRコードが出る。スマホから繋ぐときはこれを読む ・Capacity 表示（既定 32）と、セッションがどこに作られるか（same-dir） ・接続が確立するとセッションID（cse_ で始まる）が採番され、claude.ai/code/session_… へのリンクが張られる claude remote-control --help が示すオプションのうち、判断に効くのは次のあたりです。 オプション 既定 効果 --spawn <mode> same-dir same-dir / worktree / session の3種。worktree はオンデマンドのセッションごとにgit worktreeを切る --capacity <N> 32 同時セッション数の上限 --permission-mode <mode> — 生成されるセッションの権限モード（acceptEdits / auto / bypassPermissions / default / dontAsk / plan） --name <name> ホスト名から自動生成 claude.ai/code 上での表示名 -c, --continue — このディレクトリで直近およそ4時間以内に記録されたセッションへ再接続 --permission-mode bypassPermissions は、リモートから繋ぐ用途では意味が変わります。 手元の端末で明示的に承認しながら使うのと違い、Remote Control ではスマホから投げた指示がこのマシンで実行されます。権限モードを緩めるとその承認ステップごと消えるため、外出先での便利さと引き換えに、承認なしでファイル編集やコマンド実行が走る状態になります。既定のままで使うのが無難です。 公式ヘルプが挙げている前提条件も3つあります。サブスクリプションのあるアカウントでログイン済みであること、先に claude を一度実行してワークスペースの信頼ダイアログを通しておくこと、worktreeモードはgitリポジトリ（またはWorktree系フック）を要することです。 Claude Code Remote Control は待受ポートを開くのか——lsofで数えた ここが本記事の主題です。「スマホからローカルマシンを操作する」と聞くと、ポート開放・DDNS・トンネリングのような準備を連想します。実際どうなのかを測りました。 サーバーを起動した状態で、次の2つを実行します。読者の環境でもそのまま実行できます。 # 1) Remote Control のプロセスIDを確認する pgrep -fl "claude remote-control" # 2) そのプロセスが待受（LISTEN）しているTCPソケットを数える lsof -nP -a -p "$(pgrep -f 'claude remote-control' | head -1)" -i TCP -sTCP:LISTEN 結果は「出力なし」でした。 起動を2回試し、いずれも LISTEN ソケットは0本です。ローカルにサービスが立ち上がるわけではありません。 続けて外向きの接続を見ます。 lsof -nP -a -p "$(pgrep -f 'claude remote-control' | head -1)" -i TCP -sTCP:ESTABLISHED こちらは確立済みの接続が1〜2本返り、いずれも宛先ポートは 443 でした。宛先アドレスを whois で引くと次のようになります。 宛先の帯 whois の登録 意味 2607:6bc0::/32 ANTHROPIC-V6 / Anthropic, PBC Remote Control の本体通信 2600:1901::/26 GOOGLE-CLOUD / Google LLC 2回目の起動でのみ観測。Claude Code が通常使うテレメトリ等と同帯 2607:6bc0::10 は api.anthropic.com と claude.ai の AAAA レコードと一致します。 したがって、ネットワーク側の準備は不要です。 必要なのは「443番への外向きHTTPSが通ること」だけで、ルーターの設定変更もトンネルも要りません。逆に言えば、社内ネットワークでこの通信を止めたいなら、宛先の443を塞ぐのではなく後述の管理設定で止めるのが正攻法です。宛先は Claude Code が通常の会話でも使うホストと同じなので、ネットワーク層では Remote Control だけを選択的に遮断できません。 スマホは手元のマシンへ直接繋がない。双方がAnthropic側へ外向きに接続し、そこで中継される。 通信方式はWebSocketではなくSSEだった -v（verbose）を付けて起動すると、セッションごとのデバッグログのパスが表示されます。その中に、通信のエンドポイントがそのまま記録されていました。 SSETransport: SSE URL = https://api.anthropic.com/v1/code/sessions/<session-id>/worker/events/stream SSETransport: POST URL = https://api.anthropic.com/v1/code/sessions/<session-id>/worker/events 受信は SSE（Server-Sent Events）のストリーム、送信は同じパスへの POST という組み合わせです。WebSocket ではありません。これは「外向きHTTPSしか使わない」という上の観測とも整合します。SSEはHTTPのレスポンスを閉じずに流し続ける方式なので、プロキシやファイアウォールから見れば長時間のHTTPSリクエストに見えます。 Claude Code Remote Control を組織で無効化する設定 企業導入で最初に聞かれるのがここです。実行バイナリには、無効化用の管理設定と、それが効いたときのメッセージが両方含まれています。 Remote Control is disable... --- ## WebMCPとは｜Chrome 149・Edge 150で始まった仕様の現在地とSafariが反対する理由 - URL: https://ai-heartland.com/explain/webmcp/ - 更新日: 2026-08-30 - カテゴリ: explain - 概要: WebMCPはページ自身がAIエージェント向けツールを宣言するブラウザAPIの提案。MicrosoftとGoogleの2案が合流した出自、Chrome 149とEdge 150のオリジントライアル、Chrome DevTools MCPとの違いをトークン実測で比較、WebKitが反対する理由までを一次ソースで確認する。 - タグ: mcp, WebMCP, ブラウザ, 標準化, Chrome WebMCPは、Webページが自分の持つ操作を「名前・自然言語の説明・入力スキーマ」つきのツールとしてAIエージェントに宣言できるようにする、ブラウザAPIの提案です。エージェントに画面を撮らせてボタンらしきものを推測させる代わりに、ページ側から呼べる関数を渡してしまう——という発想の転換が中心にあります。ただし2026-08-30時点でこれは合意された標準ではなく、期限つきの実験配信が2ブラウザで動いている段階です。 2026-08-30 に一次ソースと手元の実測で確認した内容。棒グラフはエージェントが1ページを1回観測するときの取り込みコスト（Claude count_tokens） 30秒でわかるポイント ・何ができるか：ページが document.modelContext.registerTool() で操作を宣言し、ブラウザ内のエージェントがそれを普通のツールとして呼ぶ。画面を読む工程が要らなくなる。 ・何を解決するか：エージェントが「たぶんこのボタン」と推測する不確実さと、観測のたびに払うトークン。リデザインで壊れる問題も含む。 ・いま使えるのか：使えない。Chrome 149・Edge 150でオリジントライアルが動いているだけで既定では無効。Edgeの試験期限は2026-11-17。 ・合意はあるか：無い。WebKitはoppose（反対）を表明、Mozillaはneutral。ブラウザ間で見解が割れたままの提案。 MCPサーバーそのものの仕組みや、自分でサーバーを書く場合の手順はMCPサーバーの作り方2026年完全ガイド：TypeScript・Python両対応チュートリアルにまとめてあります。本記事は「サーバーを立てる話ではなく、ページ側にツールを持たせる提案が今どこにいるか」を一次ソースで確かめます。 エージェントがWebアプリに届く経路と、WebMCPが埋める場所 エージェントがWebアプリの機能に到達する道筋は複数あり、WebMCPはそのうちの1本を新しく引こうとしています。ここを整理しないと「WebMCPがcomputer useを置き換える」といった雑な理解になりやすいので、先に並べておきます。 「誰がツールを宣言し、誰の権限で実行するか」で並べ直したもの 分類の軸を「インターフェースからの距離」ではなく誰がツールを宣言し、誰の権限で実行するかに取ると、経路の性質の違いがはっきりします。 経路 ツールを宣言するのは 実行の主体・権限 UIを通るか 準備 バックエンドAPI / MCPサーバー 運営者（サーバー側） 運営者のサーバー・運営者のトークン 通らない サーバー実装が要る computer use（画面を見て操作） 誰も宣言しない 訪問者のブラウザ・訪問者のセッション 通る 不要 DOM／アクセシビリティツリーを読む 誰も宣言しない 訪問者のブラウザ・訪問者のセッション 通る 汎用ツールの導入のみ WebMCP ページ自身（クライアント側） 訪問者のブラウザ・訪問者のセッション 通る ページ側の実装が要る 仕様のREADME自身も、この対比を「バックエンド統合（backend integrations）」と「ブラウザ内のWebMCPツール」という2分法で説明しています。そこで挙げられているバックエンド統合の課題は3つで、エージェントとサービスが直接やり取りするためWeb UIと文脈が迂回されること、利用者の状態・ログイン情報を別サーバーに複製しなければならないこと、そしてクライアント側の機能を出すのに専用のバックエンドを書く必要があることです。WebMCPはこれをクライアント側で解こうとする提案、という位置づけになります。 つまりWebMCPが代替しようとしているのは画面を読む工程であって、MCPサーバーではありません。既存のMCPサーバー——たとえばChrome DevTools MCPとは｜使い方と既定29ツールの中身・Playwright MCPとの違いで扱ったような汎用のブラウザ操作ツール群——は、ページ側が何も宣言していない前提で動くための道具なので、役割が重なりません。 flowchart TD U["利用者の依頼"] --> AG["ブラウザ内のエージェント"] AG -->|"宣言が無い場合"| OBS["画面またはDOMを観測要素の意味を推測する"] AG -->|"宣言がある場合"| WM["WebMCPツールを呼ぶ名前・説明・入力スキーマ付き"] OBS --> ACT["クリック・入力を合成"] WM --> PAGE["ページのJavaScriptが実行UIと状態はページが更新"] ACT --> PAGE PAGE --> SRV["サイトのバックエンド"] 誰が提案したのか——MicrosoftとGoogleの2案が合流するまで 「MicrosoftのAPIなのかGoogleのAPIなのか」は、リポジトリのコミット履歴とPRの本文で決着します。結論は「ほぼ同時に別々に提案され、3週間後に統合された」です。 統合PRを起票したのはMicrosoftのBrandon Walderman。名前は先行コミュニティ由来 日付 出来事 一次ソース 2025-07-16 Microsoftが MSEdgeExplainers/WebModelContext/ を追加（PR #1094・Leo Lee） MSEdgeExplainers のコミット履歴 2025-07-19 Googleが explainers-by-googlers/script-tools を作成（David Bokan） 同リポジトリの初回コミット 2025-08-05 W3C Web ML CG 配下に共同リポジトリ webmachinelearning/webmcp を作成 リポジトリのコミット履歴 2025-08-07 PR #3「Merge Script Tools API and WebMCP explainers」で両案を統合 PR #3 の本文 2025-08-08 READMEを新名称に更新（WebMCP へ改称） コミット Update README to reflect the new name 2025-08-13 explainerに著者5名を明記（Microsoft 2・Google 3） explainer の著者欄 決定的なのは統合PR #3 の本文で、起票者（Microsoft の Brandon Walderman）自身がこう書いています——これは Microsoft の「Web Model Context」と Google の「Script Tools」の2つのexplainerを統合する最初の試みである、と。つまりどちらか一方の発案ではなく、独立した2案の合流です。日付でいえば Microsoft のほうが3日早いものの、実質的には同時期の並行提案と見るのが妥当です。 explainer の著者欄（2025-08-13 時点）は次の5名で、両社が名を連ねています。 ・Brandon Walderman（Microsoft）／Andrew Nolan（Microsoft） ・David Bokan（Google）／Khushal Sagar（Google）／Hannah Van Opstal（Google） したがって元投稿の「ChromeとEdgeの両チーム」という書き方は正確です。一方で「GoogleとMicrosoftが合意することは珍しい」という煽り方は評価であって事実ではないので、本記事では採りません。両社が共同で1本のexplainerを書いている——これが確認できる事実です。 そして「WebMCP」という名前自体は、どちらの社の発案でもありません。仕様のPrior Artセクションは、ブラウザのタブ／拡張機能間トランスポートを実装していた先行OSS MCP-B を挙げ、そこに既にWebMCPという呼称があったことを明記しています。統合PRの本文でも「MCP-Bの既存WebMCPをPrior Artとして追記した」と説明されています。 仕様の所在は WICG ではなく W3C の Web Machine Learning Community Group（w3c.json の repo-type は cg-report、グループID 110166）です。CGのレポートであり、W3Cの勧告トラックには乗っていません。 「WebMCP」という名前で3つの別物が出回っている 検索して最初に踏む地雷がこれです。「WebMCP」という名前は、関係の異なる3つのものに使われています。 ②は仕様と協調的、③は無関係。混同すると読む資料を間違える   ① W3C Web ML CG の WebMCP（本記事） ② MCP-B / WebMCP-org ③ @jason.today/webmcp 正体 ブラウザAPIの標準提案 名前の由来となった先行OSS 個人公開のnpmライブラリ 入口 github.com/webmachinelearning/webmcp mcp-b.ai webmcp.dev API document.modelContext.registerTool({…}) 同左をポリフィルで提供（@mcp-b/global） new WebMCP() → mcp.registerTool(…) 仕様との関係 本体 Prior Artとし... --- ## draw.io MCPとは｜公式サーバーの7ツールと常駐24,665トークンを実測、図はURLで渡る - URL: https://ai-heartland.com/tool/drawio-mcp-server-guide/ - 更新日: 2026-08-29 - カテゴリ: tool - 概要: draw.io公式のMCPサーバー @drawio/mcp を実際に起動し、7つのツール定義が24,665トークンを占めること、図のデータはブラウザURLのフラグメントとして渡ること、ローカルの.drawioファイルを直接読み書きできることを実測した。AIに作図させる前に知っておくべき動作モデルを整理する。 - タグ: mcp, drawio, 作図, MCPサーバー, オープンソース draw.io MCP は、AIエージェントに作図をさせるための draw.io 公式（jgraph）のMCPサーバーです。ただし「サーバーが図を描いて返してくれる」ツールだと思って導入すると動作モデルを見誤ります。実際に起動して確かめたところ、図のデータは圧縮されてブラウザのURLに載り、既定ブラウザが開かれるという作りでした。本記事では v1.5.0 を実際にインストールし、7つのツール定義を取得したうえでうち5つを実際に呼び出し、ツール定義だけで24,665トークンを消費すること、どのツールがヘッドレス環境で動くのかまでを確かめています。 7ツールは「ブラウザを開く3つ」と「ローカルで完結する4つ」に分かれる。動作条件がまったく異なる。 30秒でわかる draw.io MCP ・公式サーバー。jgraph/drawio-mcp（★5,306・Apache-2.0）、npm では @drawio/mcp v1.5.0 ・常駐コストは24,665トークン（53,780バイト）。ツールを呼ばなくても毎セッション掛かる固定費 ・図はURLで渡る。圧縮してフラグメント（# 以降）に載せ、既定ブラウザで app.diagrams.net を開く。サーバーへは送られない ・7ツールのうち3つはブラウザ必須。残り4つ（list_pages / get_page / set_page / search_shapes）はローカル完結でヘッドレス可 ・依存は2つだけ（MCP SDK と pako）。ただし postinstall が配線用JSをCDNから取得してキャッシュする MCPサーバーの仕組みそのものや自作の手順は、MCPサーバーの作り方2026年完全ガイド：TypeScript・Python両対応チュートリアルにまとめてあります。本記事は「既にある公式サーバーを繋ぐ側」の話です。 draw.io MCPとは——公式が出しているMCPサーバー draw.io MCP は、MCP（Model Context Protocol）クライアントから draw.io の作図機能を呼べるようにするサーバーです。実装は draw.io の開発元である jgraph が公開しており、非公式のサードパーティ実装ではありません。 項目 実測値（2026-08-29 時点） リポジトリ jgraph/drawio-mcp star / fork 5,306 / 326 ライセンス Apache-2.0 オープンIssue 10件 最初のコミット 2026-02-02 最終push 2026-08-03 npmパッケージ @drawio/mcp 最新バージョン v1.5.0（2026-07-19 公開） 公開バージョン数 32 直接依存 @modelcontextprotocol/sdk と pako の2つのみ Node要件 >=18.0.0 依存が2つだけというのは、この種のツールとしてはかなり小さい部類です。ただし実際に npm install すると96パッケージ・28MBになります。差分は MCP SDK の推移的依存で、パッケージ本体（展開後744KB・ファイル17個）は非常に小さいままです。 「draw.io で作図する」という需要に対して、MCP以外の選択肢（Mermaid記法をそのまま書く、PlantUMLを使う）と比べたときの draw.io の強みは、出来上がった図を人間がGUIで手直しできることです。この点は後述する動作モデル（ブラウザで開く）と直結しています。 7つのツールの中身と、動作条件の分かれ目 サーバーを stdio で起動して tools/list を投げ、返ってきた定義を全部数えました。7ツールです。 ツール名 何をするか ブラウザ必須 open_drawio_xml ※ mxGraphのXMLから図を開く ✅ open_drawio_csv ※ CSVデータから図を生成して開く ✅ open_drawio_mermaid Mermaid記法から図を生成して開く ✅ list_pages ローカルの .drawio ファイルのページ一覧を返す — get_page 指定ページの生の mxGraphModel を返す — set_page 指定ページの内容を差し替える — search_shapes 図形ライブラリをキーワード検索する — ※ 印の2つは呼び出しておらず、ソース読みからの判定です。 実際に呼んだのは open_drawio_mermaid / list_pages / get_page / set_page / search_shapes の5つで、open_drawio_xml と open_drawio_csv については「3つの open_ 系がソース上まったく同じ openBrowser(url) の呼び出しに合流している」ことを確認したうえでの推定です。実測と推定を混ぜないため明示しておきます。 この分割が実務上いちばん重要な情報です。 open_ で始まる3つは既定ブラウザを起動するので、GUIのないサーバーやCIコンテナでは機能しません。残り4つはファイルとローカルの図形ライブラリだけで完結するため、ヘッドレスでも動きます。 実際にブラウザなしの環境で list_pages / get_page / search_shapes / set_page を呼び、すべて正常に応答することを確認しました。search_shapes に database を投げると、ER図のエッジスタイル（edgeStyle=entityRelationEdgeStyle;...endArrow=ERzeroToOne; など）が実際の draw.io スタイル文字列として返ってきます。AIが「それらしいスタイル文字列」を捏造するのではなく、実在する図形定義を引けるのがこのツールの役目です。 常駐コストは24,665トークン MCPサーバーの隠れたコストは、ツール定義がコンテキストを占有し続けることです。tools/list の応答本体を計測しました。 項目 実測値 ツール数 7 tools/list 応答（ツール定義部） 53,780 バイト トークン数 約 24,665 トークン 7ツールで24,665トークンは、ツール数に対してかなり大きい値です。理由は定義を読むとわかります。open_drawio_xml の引数説明には mxGraph のXML記法のガイドが、open_drawio_mermaid には Mermaid の構文ヒントが、それぞれ長文で埋め込まれています。とくに libavoid ルーティングのオプション説明は1つで数百文字あり、「障害物を避ける直交配線を行い、頂点の位置は保ったままコネクタだけ再計算する」といった使い分けまで書かれています。 LLMに正しい記法を書かせるための投資なので無駄ではありませんが、接続している間ずっと掛かる固定費であることは意識しておく必要があります。参考までに、同じ手法で計測した Notion MCPとは｜ホスト版とローカル版の違いを24ツール・21,831トークン実測で解説は24ツールで21,831トークン、Chrome DevTools MCPとは｜使い方と既定29ツールの中身・Playwright MCPとの違いは29ツールが既定です。draw.io MCPは「ツール数は少ないが1ツールあたりが重い」タイプだと言えます。 ツール数とコンテキスト消費は比例しない。定義に埋め込まれた記法ガイドの長さで決まる。 図はどこへ行くのか——URLフラグメントで渡る open_drawio_mermaid を呼んだときに実際に何が起きるかを、open コマンドを差し替えて捕まえました。渡された引数はこれです。 https://app.diagrams.net/?grid=0&pv=0&border=10&edit=_blank#create=%7B%22type%22%3A%22mermaid%22%2C%22compressed%22%3Atrue%2C%22data%22%3A%22S8vJL0...%22%7D 3ノードのMermaidに対して280文字のURLでした。構造を分解すると次のようになります。 ・ベースURL は既定で https://app.diagrams.net/。環境変数 DRAWIO_BASE_URL で差し替え可能 ・図のデータは JSON にまとめ、pako で deflate 圧縮して Base64 化されている（"compressed":true） ・そのデータが置かれるのは # 以降のフラグメント部 ・起動方法は macOS が open、Linux が xdg-open、Windows が cmd /c start フラグメント（# 以降）はHTTPリクエストに含まれません。 URLのフラグメント部はブラウザ内部で処理され、サーバーへは送信されない——これはURLの仕様上の性質です。したがって図の中身が app.diagrams.net のサーバーに届くことはありません。ブラウザが app.diagrams.net のページ本体（HTML/JS）を取得し、そのJavaScriptがフラグメントを読んで図を復元する、という流れになります。 ただし「サーバーに送られない」ことと「外部サービスに一切依存しない」ことは別です。エデ... --- ## Claude Code 改行の完全ガイド｜Shift+Enterが効かない原因をバイト列で特定し端末別に対処 - URL: https://ai-heartland.com/explain/claude-code-newline-guide/ - 更新日: 2026-08-29 - カテゴリ: explain - 概要: Claude Code 改行ができないのは、端末が正しいバイト列を送っていないからである。PTY越しに7種類のキー入力を送り込み、どれが改行になりどれが送信になるかを実測した。Shift+Enterが標準で効く端末、terminal-setupが必要な端末、設定ファイルでキーごと変える方法までを切り分ける。 - タグ: claude-code, ターミナル, CLI, 開発環境 Claude Code 改行——長い指示を書こうとして Enter を押した瞬間に送信されてしまう——この問題は「Shift+Enter を使えば改行できる」という説明で片付けられがちですが、実際には効く端末と効かない端末があります。原因は Claude Code 側ではなく、端末が Shift+Enter に固有のバイト列を割り当てているかどうかにあります。本記事では擬似端末（PTY）越しに7種類のキー入力を実際に送り込み、どのバイト列が改行になり、どれが送信になるかを v2.1.241 で実測しました。 PTY越しに各キー入力のバイト列を直接送って挙動を確認した結果。判定しているのはキー名ではなくバイト列。 30秒でわかる Claude Code の改行 ・どこでも確実に効くのはバックスラッシュ＋Enter。端末も設定も問わず改行になる（実測） ・Shift+Enter がネイティブで効く端末：iTerm2 / WezTerm / Ghostty / Kitty / Warp / Windows Terminal ・/terminal-setup が要る端末：Terminal.app（Option+Enter・要再起動）／VSCode・Cursor・Devin Desktop・Zed／Alacritty ・tmux・screen の中では /terminal-setup が通らない。いったん抜けて実行してから戻る ・IMEの確定Enterによる誤送信は端末設定では直らない。送信Enterと同じ1バイトなので区別できない Claude Code の設定全般とインストールからの流れは、Claude Code｜2026年版・インストールからCLAUDE.md・Hooks・本番運用までの実装手引きにまとめてあります。本記事は入力欄の改行という一点に絞ります。 Claude Code 改行はキーではなくバイト列で決まる 前提を1つ押さえます。Claude Code は「Shift+Enter が押された」という情報を受け取っていません。 端末エミュレータから流れてくるバイト列だけを見ています。 素の Enter は CR（0x0D）1バイトです。多くの端末は Shift を押しながら Enter を打っても同じ CR を送るため、Claude Code からは区別のしようがなく、送信として処理されます。「Shift+Enter で改行できる」という説明が当たったり外れたりするのは、この一点に尽きます。 そこで、代表的な入力が実際にどう解釈されるかを PTY 越しに直接測りました。手順は「AB を入力 → 検証したいバイト列を送信 → CD を入力」で、入力欄が2行になれば改行、応答が始まれば送信という判定です。 キー操作 端末が送るバイト列 v2.1.241 の解釈 Enter CR（0x0D） 送信（対照群） Option / Alt + Enter ESC CR（0x1B 0x0D） 改行 Shift+Enter（CSI u 形式） ESC [ 1 3 ; 2 u 改行 Shift+Enter（modifyOtherKeys 形式） ESC [ 2 7 ; 2 ; 1 3 ~ 改行 バックスラッシュを打ってから Enter \ + CR 改行（バックスラッシュは残らない） 複数行のペースト ESC [ 2 0 0 ~ … ESC [ 2 0 1 ~ 改行（括弧付きペースト） 日本語の直後に Enter CR 送信（IME確定と区別不可） 対照群として素の Enter が確実に送信になることを毎回確認しているので、「たまたま反応しなかった」ではなく改行として処理されたと言えます。改行になったケースでは、入力欄に AB と CD が別々の行として並んだ状態を目視で確認しています。 読み取れるのは次の点です。改行として受け付けられるバイト列は複数あり、そのどれを送るかは端末側の設定で決まる。Claude Code の設定をいくら見ても改行キーの項目が見つからないのは、そこが管轄外だからです。 Claude Code に届く前に、キーはすでにバイト列へ変換されている。設定すべきレイヤーはその手前にある。 Claude Code 改行の端末別対処——まず自分の端末がどれかを確認する Claude Code の実行バイナリには、端末ごとの扱いを説明する文字列が埋め込まれています。そこから読み取れる分類は3群です。 1. 何もしなくてよい端末（Shift+Enter ネイティブ対応） バイナリ内の案内文は次のように明示しています。 Note: iTerm2, WezTerm, Ghostty, Kitty, Warp, and Windows Terminal support Shift+Enter natively. これらの端末は Shift+Enter に固有のエスケープシーケンス（上表の CSI u 形式など）を割り当てて送信するため、設定なしでそのまま改行できます。iTerm2 については Shift+Enter is natively supported in iTerm2. という個別の文言も持っています。 「Shift+Enter で改行できると書いてあったのにできない」という食い違いは、この6端末以外を使っているときに起きます。まず自分の端末がこのリストに入っているかを確認するのが、切り分けの最短路です。 実行バイナリに埋め込まれた記述から分類。まず自分の端末がどちらの群かを確定させる。 2. /terminal-setup を実行する端末 Claude Code のセッション内で /terminal-setup を打つと、端末側の設定ファイルにキーバインドが書き込まれます。対象と実際の内容は次のとおりです。 対象 設定される内容 備考 macOS Terminal.app Option+Enter で改行 反映に Terminal.app の再起動が必要 VSCode / Cursor / Devin Desktop / Zed shift+enter に workbench.action.terminal.sendSequence で ESC+CR を送る定義を追加 when: terminalFocus の条件付き Alacritty Shift+Enter のキーバインドを追加 既存の別バインドがある場合は上書きしない ここで注目したいのは、VSCode 系に書き込まれる中身が ESC+CR である点です。これは上の実測表で「Option+Enter」として測ったバイト列と同一です。つまり VSCode の Shift+Enter は、内部的には Option+Enter と同じものを送っているだけで、Claude Code 側から見れば両者は区別されていません。キー名は3通りあっても、届いているバイト列は同じということです。 既に別の割り当てがある場合は、already has a Shift+Enter terminal binding with different args; leaving it as-is. として上書きせずに残す挙動になっています。自分でキーバインドを育てている人の設定を壊さない作りです。設定が成功したときは Installed Alacritty Shift+Enter key binding のように、どの端末に何を入れたかが個別に報告されます。 # Claude Code のセッション内で実行する（シェルのコマンドではない） /terminal-setup 3. tmux / screen の中では通らない 多重化ツールの中で /terminal-setup を実行しようとすると、バイナリ内の案内文どおり次の手順を求められます。 1. Exit tmux/screen temporarily 2. Run /terminal-setup directly in one of these terminals: • IDE: VSCode, Cursor, Devin Desktop, Zed • Other: Alacritty 3. Return to tmux/screen - settings will persist tmux 越しだと設定対象の端末を判別できないためで、いったん抜けて実行し、戻れば設定は残るという説明になっています。tmux を常用していて「何度実行しても改行できるようにならない」場合は、実行そのものが空振りしている可能性があります。 端末を変えたくない・設定を触りたくない場合 バックスラッシュを打ってから Enter、という方法が常に使えます。実測でも端末やロケールに関係なく改行になり、入力欄にバックスラッシュは残りませんでした。シェルの行継続と同じ発想なので覚えやすく、/terminal-setup を実行できないリモート環境や共用マシンでも確実に動きます。 設定ファイルでキー割り当て自体を変える 端末側ではなく Claude Code 側でキーを変える経路も用意されています。~/.claude/keybindings.json です。 このファイルは実行バイナリが読み込み・検証しており、公式スキーマが SchemaStore に公開されています。スキーマを取得して中身を確認したところ、構造は次のようになっていました。 ・bindings は配列で、各要素が contex... --- ## @7nohe/openapi-react-query-codegenに悪性版10種｜Trusted Publishingでも防げなかった理由 - URL: https://ai-heartland.com/security/news-openapi-react-query-codegen-npm-supply-chain/ - 更新日: 2026-08-29 - カテゴリ: security - 概要: 週15万DLの@7nohe/openapi-react-query-codegenに悪性版10種（unpublish済み）。JFrogがShai-Hulud Trinititeと呼ぶこのnpm 脆弱性について、対象版と確認手順、--ignore-scriptsが効くのかをnpm 11.1.0で実測した結果を示す。 - タグ: security, セキュリティ, npm, supply-chain, サプライチェーン, shai-hulud, binding-gyp, node-gyp, github-actions, malware, ci-cd 2026年8月29日未明（JST）、週15万ダウンロードを超えるnpmパッケージ@7nohe/openapi-react-query-codegenに、悪性コードを含む10個のバージョンが公開された。約21分間の出来事だ。侵害の起点はnpmアカウントの乗っ取りでもトークンの窃取でもない。GitHub Actionsのワークフローが、PRのコメント欄にnpm publishと書き込むだけで、誰でも発火する状態になっていた。 この記事のポイント（結論から先に） ・対象：@7nohe/openapi-react-query-codegen（npm・週151,093DL）。これ以外のパッケージは対象ではない。 ・悪性バージョン（10個）：0.5.4 / 0.5.5 / 1.6.3 / 1.6.4 / 2.2.1 / 2.2.2 / 3.0.3 / 3.0.4 / 0.0.0-365d4eb… / 0.0.0-ec7876d6… ・安全な版：3.0.2（2026-08-11公開）およびそれ以前 ・危険だった時間帯：2026-08-29 05:00〜08:11 JST（約3時間11分）。この時間帯に取得していなければ、本件による直接の影響は考えにくい ・現在：10版とも npm から unpublish 済み。新規インストールで悪性版は入らない ・ただし：削除は配布を止めるだけ。露出時間帯に入れた node_modules・lockファイル・キャッシュは残る ・原因：release.yml の issue_comment トリガー。コメント本文が npm publish に一致するかだけを見て、投稿者の権限を検査していなかった。Trusted Publishing 移行済みだったがトークンは盗まれていない——正規に発行された資格情報が攻撃者のコードに使われた ・検知の要点：10版中8版に binding.gyp とペイロードを同梱し、うち4版はインストールスクリプトを持たない。package.json の scripts だけ見ると取り逃す（--ignore-scripts はinstall 時にはこの経路を止めるが、後の npm rebuild／npm ci では起動する。10条件の実測は本文） ・発生直後は npm audit で検知できなかった（現在は GHSA-9pvf-vcx3-x239 / CVSS 9.6 が発行済み） 確認手順は「影響を受けるバージョンと、自分の環境の確認手順」にまとめた。 npmサプライチェーン攻撃全体の防御フレームワークと恒久対策についてはサプライチェーン攻撃とは｜手口・防御ツール比較・npm 12の新機構まで実践解説をご覧ください。 本記事の検証範囲（何を確かめ、何を確かめていないか） ・確かめたこと：npmレジストリの packument（公開時刻・バージョン数・dist-tags）、tarball のファイル一覧と package.json、ペイロードファイルのサイズとSHA-256、GitHub API 上の workflow・PR・Issue・コミット、npm view によるバージョン解決、および --ignore-scripts の挙動（自作の無害なパッケージで実施） ・確かめていないこと：ペイロードの実行・動的解析・逆難読化。何を窃取するかの内部挙動は本記事の一次検証の対象外で、他者の解析を引用する箇所はその旨を明記する。またセキュリティベンダー各社の解析（Socket・JFrog・Endor Labs 等）は他者の解析としてそのつど出典を示して引用しており、当サイトが独立に再現したものではない（初版時点で 403 だった Socket のページは、2026-09-01 の追記時に取得できた） ・やっていないこと：該当パッケージのインストール（npm install / npx / yarn / pnpm のいずれも実行していない）。攻撃コードは再現可能な形で掲載しない 攻撃と収束の時系列（JST）。PRへのnpm publishコメントから最初の悪性版公開まで88秒、削除までの露出は3時間11分。筆者がGitHub APIとnpmレジストリのtimeフィールドから再構成した。 2026-09-01 追記（この記事は初版から更新されています） 初版公開の翌日以降に各社の解析が出そろい、1点の訂正と3点の追記を行いました。 ・【訂正】--ignore-scripts で導入した後に「素の npm install をやり直すと実行される」と書いていましたが、実測では再現しませんでした。実際に起動するのは npm rebuild と npm ci です（→「実測し直した節」） ・【追記1】JFrog は「--ignore-scripts では止まらない」、Endor Labs は「止まる」と正反対の記述をしました。陽性対照つきで10条件を測り直しています ・【追記2】本件の呼び名（Shai-Hulud / Mini Shai-Hulud / Trinitite）の関係と、攻撃2日前のTeamPCP逮捕を踏まえた帰属の扱い ・【追記3】常駐（永続化）の痕跡を探す確認手順と、PyPI・RubyGems の「狙われた」と「汚染された」の区別 何が起きたか——21分間で10バージョンが公開されるまで @7nohe/openapi-react-query-codegenは、OpenAPIスキーマからTanStack Query（React Query）のフックを生成するコードジェネレータだ。GitHubスター428、npmの直近1週間のダウンロード数は151,093（npm downloads APIの実測、2026-08-21〜08-27）。正規のリリースは3.0.2（2026-08-11）で止まっており、その17日後に10版が21分足らずで出現した。 流れはこうだ（JST。公開時刻はnpmレジストリのtimeフィールド、その他はGitHub APIから取得）。 ・04:59:07／04:59:15 — アカウントp00pabootがPR #215を作成し、npm publish とだけコメント ・05:00:43〜05:02:08 — 1波目5版を公開（コメントから88秒） ・05:17:24／05:17:43 — PR #216で同じ手順を反復 ・05:18:44 — 外部の報告者がIssue #217で通報 ・05:19:29〜05:20:53 — 2波目5版を公開（106秒） ・05:29:59 — p00pabootが通報スレッドに「Seems fine to me. Stop spreading misinformation.」と書き込み、通報を否定 ・07:50:03 — メンテナがワークフローを修正（コミット8330895b4） ・08:11:37 — npm側が10版を削除／08:27:18 — GHSA-9pvf-vcx3-x239（CVSS 9.6）公開 コメントから公開までが88秒・106秒という短さは、人手を介さず自動で公開まで到達していたことを示している。 より広いキャンペーンの一部という位置づけ（他社報告） 本件は単発の事故として扱われていない。Socket および Endor Labs は本件を「Mini Shai-Hulud」系のキャンペーンの一部として追跡していると報告されている。同系統のキャンペーンについては、認証情報の窃取と、盗んだトークンを使った他パッケージ・他レジストリへの自己増殖につながる挙動が各社の解析で報告されている。 ただし第2段ペイロードの挙動は各社とも断定していない（Socket は解析継続中としている）。筆者はペイロードを実行も逆難読化もしていないため、この段落は他社報告の紹介であって本記事の一次検証結果ではない。 なお筆者の環境からは Socket のページが 403 で取得できず、本段落の内容を一次ソースから直接確認できていない点も付記しておく（詳細は末尾の調査方法を参照）。 そして、どちらのPRもマージされていない。 GitHub APIのmergedはfalse、merged_atはnull。レビュー欄もcoderabbitaiボットのコメント1件だけで、人間のレビューも承認も無い（PR #215）。 つまり「悪意あるPRがレビューをすり抜けてマージされた」事案ではない。マージは最初から不要で、コメント1行でワークフローが起動しPRのコードがそのまま公開された。「PRを丁寧にレビューしていれば防げた」という教訓は、この事案には当てはまらない。 見るべきだったのは差分ではなく、ワークフローの起動条件のほうだ。 攻撃者アカウントp00pabootは攻撃の約14時間半前（2026-08-28 14:28 JST）に作成され、フォロワー0・公開リポジトリ1件・bio無し。既存コントリビュータに似せるtyposquat型ではなく使い捨てで、経歴の水増しも無い。裏を返せば、この経路はアカウントの信用を一切必要としなかった。なおPRの差分はfork削除により取得できない（files・commitsとも0。「変更が無かった」ことを意味しない）。 なぜ「Trusted Publishing移行済み」でも防げなかったのか このリポジトリは2026年3月にnpmのTrusted Publishing（OIDCベースの信頼公開）へ移行済みだった。permissionsにid-... --- ## Claude Code 日本語化ガイド｜UIは英語のまま・応答だけを日本語にする設定とトークン1.57倍の実測 - URL: https://ai-heartland.com/explain/claude-code-japanese-guide/ - 更新日: 2026-08-29 - カテゴリ: explain - 概要: Claude Code 日本語化で勧められるロケール設定は、実測では応答を1バイトも変えなかった。62個のCLIオプションを全数確認したうえで、実際に効く設定はどれか、文字化けの原因はどこにあるか、日本語がトークンを1.57倍消費する実測値までを一次検証で示す。 - タグ: claude-code, 日本語, CLI, 開発環境 Claude Code 日本語化を調べると、検索で出てくる手順の多くは「ロケールを日本語にする」「LANG を設定する」と書いています。しかし v2.1.241 で実際に測ると、ロケールを日本語にしても応答は1バイトも変わりません。そもそも Claude Code には言語設定が存在せず、claude --help が並べる62個のオプションのうち言語に関わるものは0個でした。本記事では、Claude Code 日本語化に実際は何が効くのか、文字化けの原因はどこにあるのか、そして日本語で使うとトークンが1.57倍かかるという実測値までを、すべて手元での検証つきで示します。 v2.1.241 を実際に動かして測った結果。「設定で日本語にする」という発想がそもそも空振りする。 30秒でわかる Claude Code の日本語利用 ・言語設定は存在しない。CLIオプション62個中0個、実行バイナリに ja-JP / ja_JP は0件（対照の en-US は40件） ・LANG=ja_JP.UTF-8 は効かない。同じ英語プロンプトでロケールだけ変えたA/Bで、返答は1文字違わず同一 ・効くのは CLAUDE.md と --append-system-prompt の2つ。どちらも英語で質問しても日本語で返る ・文字化けはCLIの問題ではない。LC_ALL=C でも出力バイト列はUTF-8のまま ja_JP.UTF-8 と完全一致 ・日本語はトークン1.57倍。文字数は4割少ないのに、1トークンあたり英語3.38文字／日本語1.26文字 Claude Code そのものの導入・設定・運用の全体像は、Claude Code｜2026年版・インストールからCLAUDE.md・Hooks・本番運用までの実装手引きにまとめてあります。本記事はそこから「日本語で使う」という一点だけを切り出して掘り下げます。 Claude Code 日本語化に「言語設定」は存在しない——62オプションを全数確認した まず最初に潰しておくべき前提があります。Claude Code には言語を切り替える設定が用意されていません。 claude --help が出力するオプションを数えると、v2.1.241 では62個ありました。そのうち lang / locale / i18n / japanese のいずれかを含む行は0行です。 # 実行して確かめられます（v2.1.241 で確認） claude --help | grep -cE '^ (-|--)' # → 62 claude --help | grep -ciE 'lang|locale|i18n|japanese' # → 0 「オプションに無いだけで内部には持っているのでは」という疑いも潰しておきます。Claude Code の実体は単一のネイティブ実行ファイル（macOS arm64 で310MB）なので、埋め込み文字列を直接検索できます。 検索した文字列 ヒット数 意味 en-US 40 英語ロケールの識別子は存在する ja-JP 0 日本語ロケールの識別子は無い ja_JP 0 同上（POSIX表記でも無い） Auto-compact（UI文言・対照群） 20 英語のUI文言は当然ある esc to interrupt（UI文言・対照群） 2 同上 自動コンパクト（上記の和訳） 0 UI文言の日本語版は存在しない 中断するには（同上） 0 同上 対照群として英語のUI文言が確実にヒットすること、そして en-US はあるのに ja-JP だけが0件であることを同時に確認しています。「検索方法が悪くて見つからない」のではなく、日本語ロケールが最初から入っていないという結論です。 つまり、ステータスラインの Auto-compact、入力欄下の esc to interrupt、権限ダイアログの英文といったTUIの文言は、どう設定しても英語のままです。日本語化できるのは「Claudeの応答」だけで、「アプリの画面」ではありません。ここを混同したまま設定をいじると、いつまでも「日本語化できない」ことになります。 日本語化の対象になるのは真ん中の層だけ。上下2層は言語設定の管轄外にある。 Claude Code 日本語化で実際に効く3つの方法と、その効き方 では何が効くのか。候補を4つ立てて、同じ質問を投げるA/Bで1つずつ確かめました。質問は In one sentence, what does 'git commit' do?（英語）で固定し、claude -p の非対話モードで実行しています。 方法 実測結果 判定 LANG / LC_ALL を ja_JP.UTF-8 にする 英語で返答（en_US.UTF-8 の返答と1文字も違わない） ❌ 効かない プロンプトを日本語で書く 日本語で返答 ⭕ 効く（ただし追随なので不安定） CLAUDE.md に「応答は必ず日本語で書くこと」と記載 英語の質問でも日本語で返答 ◎ 確実 --append-system-prompt "Always respond in Japanese." 英語の質問でも日本語で返答 ◎ 確実 ロケール変更が効かないことの確認 いちばん誤解が多いのがこれなので、実測の生データを置きます。 # 同じプロンプトを、ロケールだけ変えて2回実行する LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8 \ claude -p "In one sentence, what does 'git commit' do?" LANG=ja_JP.UTF-8 LC_ALL=ja_JP.UTF-8 \ claude -p "In one sentence, what does 'git commit' do?" 返ってきた文章は両方とも git commit saves the currently staged changes as a new snapshot in the repository's history, along with a message describing them. で、完全に同一でした。ロケール環境変数は応答言語に一切関与していません。 一方、同じ内容を日本語で聞くと日本語で返ってきます（ロケールは英語のまま）。 git commit は、ステージング済みの変更をローカルリポジトリの履歴に記録するコマンドです。 応答言語を決めているのはロケールではなく、文脈に含まれる言語です。これが分かると、なぜ「最初は日本語だったのに途中から英語になった」が起きるのかも説明できます。英語のスタックトレースやREADMEを読ませた瞬間、文脈の言語比率が英語に傾くからです。 CLAUDE.md に書くのが最も安定する 恒久的に日本語で使いたいなら、プロジェクトの CLAUDE.md に指示を書きます。実測では、これだけで英語の質問に対しても日本語で返ってきました。 # プロジェクト規約 - 応答は必ず日本語で書くこと。 CLAUDE.md はセッション開始時に読み込まれ、以降のやり取り全体に効きます。ファイルの置き場所（プロジェクト直下・~/.claude/CLAUDE.md・親ディレクトリ）による読み込み順の違いや、他のAIツールとの AGENTS.md 共通化については、AI mdファイルとは｜CLAUDE.md・AGENTS.md・.cursorrules・GEMINI.mdの違いと書き方に整理があります。 単発のコマンド実行や、CLAUDE.md を汚したくない場合は --append-system-prompt を使います。 claude --append-system-prompt "Always respond in Japanese." \ -p "In one sentence, what does 'git commit' do?" こちらも実測で日本語の返答になりました。CI やスクリプトから叩く用途ではこちらが扱いやすいです。 なお、同じ「日本語化」という言葉でも Cursor はUIそのものに日本語表示の経路があり、事情が異なります。エディタ側の手順はCursor 日本語化の完全手順｜UI・AI応答・初期設定と日本語にできない時の対処を参照してください。Claude Code はUIの日本語化経路が存在しない点が決定的な違いです。 文字化けの本当の原因——出力は常にUTF-8だった 「Claude Code 文字化け」で検索すると、ロケールを設定して直す手順が並びます。これも実測で否定できます。 非UTF-8ロケールである LC_ALL=C を明示して日本語を出力させ、バイト列を直接見ました。 LANG=C LC_ALL=C claude -p "「こんにちは」とだけ出力してください" | xxd | head -1 結果は e381 93e3 8293 e381 abe3 81a1 e381 af0a でした。これは「こんにちは」のUTF-8そのものです。参考に LANG=ja_JP.UTF-8 で同じことをすると、バイト列は完全に一致しました。 結論：Claude Code はロケールに関係なく常にUTF-8を出力する。 したがって画面が文字化けして見えるなら、原因は次のいずれかです。 ・端末エミュレータの文字エンコーディング設定がUTF-8になっていない ・使用中のフォントに日本語グリフが無い（□や... --- ## cobalt toolsとは｜★42,283の保存APIをセルフホストし21サービスを実測、youtubeは公開版に無い - URL: https://ai-heartland.com/tool/cobalt-tools-self-host-guide/ - 更新日: 2026-08-28 - カテゴリ: tool - 概要: cobalt tools（imputnet/cobalt・★42,283・AGPL-3.0）の仕組みをセルフホストして実測した。公式テスト165件の合格率は69.7%で4サービスは全滅、公開インスタンスは21サービス中20しか提供せずyoutubeが無い。mainは4.7か月止まっている。 - タグ: automation, downloader, セルフホスト, API, OSS cobalt tools（imputnet/cobalt）は、URLを1つ渡すとそのページで配信されているメディアの直リンクを返すだけの道具で、★42,283・fork 3,662を集めている。広告もトラッカーもアナリティクスも持たず、取得したファイルをサーバーに残さない——という設計が支持された結果だが、その規模から想像するほど今のcobaltは元気ではない。手元でセルフホストし、公式のテスト165件を全部走らせて、どこが生きていてどこが死んでいるかを数えた。 手元での実測（2026-08-27）。合計 115/165（69.7%）。テストはメディアの解決可否だけを見るもので、ファイルは取得しない この記事のポイント ・公式テストの合格率は 115/165（69.7%）。reddit・vimeo・twitch・newgrounds の4サービスは全滅 ・リポジトリは21サービスを持つが、公開インスタンスが提供しているのは20（youtube が無い） ・main の最終コミットは 2026-04-06。他ブランチも main より進んでいない セルフホストできる自動化基盤の選び方そのものを見渡したい場合は、AI自動化ツール｜ノーコードからコードまで2026年版の比較と選び方に全体像がある。ここではcobalt1本に絞って、コードと実測から中身を見ていく。 cobalt tools の仕組み——「保存しない」ための2つの返し方 cobaltのAPIは驚くほど単純で、POST / にURLを投げると JSON が返る。返り方には主に2種類ある。 ・redirect — 元のサービスが配信している直リンクをそのまま返す。cobaltのサーバーはデータを一切通さない ・tunnel — cobaltのサーバーを経由するURLを返す。映像と音声が別ストリームで配信されている場合など、その場で結合が必要なときに使う この2択が、cobaltが「ファイルをサーバーに保存しない」と言える根拠になっている。redirect はそもそも通らない。tunnel は通るが、ストリームとして中継するだけでディスクには書かない。加えてトンネルURLは短命な署名付きで、発行したインスタンス以外では使えない。 このほか picker（複数候補があるとき選ばせる）と error がある。実測で観測した error は error.api.fetch.empty——上流サービスが期待した内容を返さなかった、という抽象度の高いコードで、原因の切り分けにはあまり役立たない。 構成は pnpm ワークスペースで3つに分かれている。 ディレクトリ 役割 備考 api/ 解析とトンネルの本体 @imput/cobalt-api v11.7.1・Node 18.17以上 web/ SvelteベースのWeb UI Cloudflare Workers 前提の wrangler.jsonc を同梱 packages/ 共有ライブラリ バージョン情報など APIだけを立てればUIは無くても動く。逆にUIだけを別ホストに置いて、APIは自前という分離もできる。Web UIはブラウザ上で動き、取得処理はAPI側が担うので、UIをどこに置くかとデータがどこを通るかは独立している。 実測：cobalt tools の公式テスト165件のうち50件が落ちる cobaltは api/src/util/tests/ にサービスごとのテストフィクスチャを持っている。node src/util/test を走らせると、各URLに対して「どの status が返るべきか」を検証する。重要なのは、このテストがメディアを取得しないことである。runTest() は URL を正規化し、extract() でホストとパターンを判定し、match() で解決を試み、返ってきた status と HTTP コードが期待どおりかだけを見る。つまりこれは抽出器の生存確認であって、ダウンロードのテストではない。 既定では不安定なサービス（bilibili・instagram・facebook・youtube・vk・twitter・reddit）が除外されるので、TEST_IGNORE_SERVICES を空に近い値で上書きして全21サービスを走らせた。 git clone --depth 1 https://github.com/imputnet/cobalt.git cd cobalt/api && pnpm install API_URL="http://localhost:9000/" TEST_IGNORE_SERVICES="none" node src/util/test 結果は 115件合格・50件不合格（合格率69.7%）。サービス別に並べると差が極端だった。 状態 サービス 合格 全滅 reddit 0/8 全滅 vimeo 0/6 全滅 twitch（clips） 0/4 全滅 newgrounds 0/4 ほぼ全滅 bilibili 1/7 半分 loom 3/6 半分 tiktok 3/5 半分 vk 5/8 おおむね健全 instagram 10/14 おおむね健全 youtube 15/20 おおむね健全 facebook / streamable 4/5 良好 rutube / soundcloud 9/10 良好 twitter 21/22 満点 bsky・dailymotion・ok・pinterest・snapchat・tumblr 全件 合格率の分布。100%と0%に割れていて、中間が少ない 分布が二極化しているのは、抽出器の壊れ方に理由がある。上流サービスがAPIの形やプレイヤーの実装を変えると、そのサービスの抽出器は一斉に効かなくなる。 vimeo が 0/6 なのは「4k progressive」「720p progressive」「1080p dash」など全パターンが同じ経路で解決に失敗しているからで、個別のケースが偶然落ちているのではない。逆に bsky や pinterest が満点なのは、配信の形が単純で変更も少ないためだ。 一方で instagram の 10/14 のように、同じサービス内でも成否が割れるケースもある。instagram では「reel」が期待した redirect ではなく tunnel を返し、「single photo post」が error.api.fetch.empty で落ちた。テスト側の期待値が古い可能性と、抽出器が劣化した可能性の両方があり、実行結果だけでは切り分けられない。 開発者自身が「不安定」と名指ししているサービスがある テストランナーのソースには、外的要因で頻繁に落ちるサービスが定数として書き込まれている。 // services that are known to frequently fail due to external // factors (e.g. rate limiting) const finnicky = new Set( process.env.TEST_IGNORE_SERVICES ? process.env.TEST_IGNORE_SERVICES.split(',') : ['bilibili', 'instagram', 'facebook', 'youtube', 'vk', 'twitter', 'reddit'] ); 既定でテストから除外される7サービスがこれである。cobalt側が「安定して通らない」と認めている一覧と読める。ここに挙がっているものは、自分の環境で通らなくても仕様の範囲内と考えたほうがよい。 興味深いのは、この7つと実測結果が完全には一致しないことだ。twitter は 21/22、facebook は 4/5 と高い合格率を出した一方、除外リストに載っていない vimeo・twitch・newgrounds が全滅している。つまり除外リストは古く、劣化の実態を反映していない。リストが更新されていないこと自体が、4.7か月の停止を裏づける材料にもなっている。 TEST_IGNORE_SERVICES を空文字にすると '' が1要素として入ってしまうので、実測では "none" のような存在しないサービス名を渡して全件を対象にした。除外を効かせたいときはカンマ区切りでサービス名を並べる。 APIの叩き方——最小のリクエストとよく使う指定 docs/api.md にある仕様のうち、実際に使う部分は少ない。POST / に Accept: application/json と Content-Type: application/json を付け、本文に url を入れるだけが最小形になる。 curl -s -X POST http://localhost:9000/ \ -H 'Accept: application/json' \ -H 'Content-Type: application/json' \ -d '{"url": "<自分が権利を持つ、または許諾済みの素材のURL>"}' 返る JSON の status が前述の4種（redirect / tunnel / picker / error）で、redirect と tunnel では url に取得先が入る。よく使う追加指定は次のあたりになる。 ・videoQuality — m... --- ## Pipecatとは？LiveKit Agents・TEN Frameworkと比較する音声AIエージェントOSSの選び方 - URL: https://ai-heartland.com/explain/pipecat-livekit-ten-voice-agent-oss/ - 更新日: 2026-08-28 - カテゴリ: explain - 概要: 音声で対話するAIを作るとき、Pipecat・LiveKit Agents・TEN Framework のどれを選ぶか。会話オーケストレーション／アバター描画／ドメインロジックの3層に分けて整理し、GitHub実測の規模・更新状況と、Apache-2.0でも追加条件が付くライセンスの実態まで確認する。 - タグ: AIエージェント, 音声AI, オープンソース, WebRTC 音声で対話するAIを作ろうとすると、候補のOSSが一気に増えて選べなくなります。Pipecat、LiveKit Agents、TEN Framework、OpenAvatarChat、MuseTalk——名前が並列に見えるのに、実際に触ると担当している範囲がまったく違う。整理の鍵は、「会話オーケストレーション層」「アバター描画層」「ドメインロジック層」の3層に分けることです。既存OSSはたいていどれか1層に特化しているので、丸ごと1本で済ませようとすると必ずどこかで詰みます。この記事では各層の代表的なOSSをGitHub APIで実測しながら整理し、表記がApache-2.0でも追加条件が付くというライセンスの実態まで確認します。エージェント全般の枠組みの選び方はAIエージェントフレームワーク比較2026｜LangGraph・CrewAI・Dify等9種をStar数・実コードで検証を参照してください。 音声AIエージェントを比較するための3層フレーム。層を分けずに1本で賄おうとすると、一番効く「会話制御」の改善サイクルが止まる。 この記事のポイント（30秒でわかる音声AIエージェントOSSの選び方） ・3層に分けて選ぶ：①会話オーケストレーション（STT→LLM→TTS・VAD・ターン検知・バージイン・transport）②アバター描画 ③ドメインロジック。1本のOSSが全部を担当することはない ・①の主役は3つ：Pipecat（★14,818・BSD-2・v1.0は2026-04-14）／LiveKit Agents（★13,193・Apache-2.0）／TEN Framework（★11,088・Apache-2.0＋追加条件） ・ライセンスが3者3様：Pipecatは追加条件なし。LiveKitはフレームワークがApache-2.0でもターン検知モデルは別ライセンス（他フレームワークでの利用不可）。TENはエンドユーザー端末でのホスティングを禁止 ・PipecatとLiveKitは排他ではない：PipecatのtransportにLiveKitが含まれており、LiveKitの上でPipecatを動かせる ・②のアバターは実写系と3Dキャラ系で完全に別物。日本語音声を重視するなら3Dキャラ系が有利 ・品質を決めるのは見た目ではなく会話制御。アバターは差し替え可能なプラグインとして外に置く 音声AIエージェントは3層に分けて選ぶ——1本のOSSで全部は賄えない 「AIと声で会話する」を実現するために必要な仕事を分解すると、性質のまったく違う3種類が出てきます。 層 担当する仕事 難しさの正体 ① 会話オーケストレーション層 STT→LLM→TTSのループ、VAD（発話区間検出）、ターン終了検知、バージイン（割り込み）、transport（WebRTC・WebSocket・電話） リアルタイム制御。遅延・割り込み・沈黙の扱いを外すと、どれだけ賢いLLMでも会話が成立しない ② アバター描画層 口の動きの同期（リップシンク）、表情・ポーズ、3Dモデル／実写映像の生成 描画コストとGPU設計。人物を生成するのか、既にある人物を動かすだけかで必要リソースが激変する ③ ドメインロジック層 何を聞くか、どう評価するか、記録をどう残すか 業務要件そのもの。OSSで汎用化しにくく、自作になりやすい この3つを1本のOSSで賄おうとすると何が起きるか。改善サイクルが止まります。 たとえばアバターの描画を会話ループに密結合させると、ターン終了検知のアルゴリズムを差し替えるだけで描画側の修正が必要になる。逆にアバターを差し替えたいだけなのに会話ループを触ることになる。 実際、この分離は業界側でも起きています。後述する OpenAvatarChat がバージョン0.6.0（2026-04-17）でフロントエンドとバックエンドを分離するアーキテクチャ刷新を行ったのは、同じ動機と読めます。 この記事の数値の扱い ★数・最終push日・リリース日・ライセンス表記は、2026-08-28にGitHub REST APIおよび各リポジトリの LICENSE / README を直接取得した実測値です。一方、応答時間・fps・レイテンシなどの性能値はすべて各リポジトリの公称値であり、筆者が実機で測ったものではありません。本文では公称値には必ず「公称」と明記しています。 会話オーケストレーション層——Pipecat・LiveKit Agents・TEN Frameworkの違い ①の層が本体です。ここを間違えると後から取り返しがつきません。実測した3つの主要OSSを並べます。   Pipecat LiveKit Agents TEN Framework リポジトリ pipecat-ai/pipecat livekit/agents TEN-framework/ten-framework ★（2026-08-28実測） 14,818 13,193 11,088 最終push 2026-08-27 2026-08-27 2026-08-27 最新リリース v1.8.1（2026-08-27） livekit-agents@1.7.1（2026-08-27） 0.11.71（2026-07-31） ライセンス表記 BSD-2-Clause Apache-2.0（モデルは別ライセンス） Apache-2.0＋追加条件 中心概念 フレームプロセッサのパイプライン ルームに入る「プログラマブルな参加者」 拡張（extension）で組む対話グラフ 開発元 Daily とコミュニティ LiveKit Agora 3つとも最終pushが同じ日（2026-08-27）で、いずれも活発に開発されています。規模でも更新頻度でも決定的な差は付きません。 選定軸は別のところにあります。 Pipecat——transportを差し替えられるパイプライン抽象 Pipecatは、READMEの表現で「リアルタイム音声・マルチモーダル対話エージェントを構築するオープンソースのPythonフレームワーク」です。特徴はフレームプロセッサをつないでパイプラインを組むモデルで、音声・映像・AIサービス・transportを同じ抽象の上で扱います。 実務上効くのは transport非依存であることです。READMEに挙がっているtransportは Daily（WebRTC）、FastAPI WebSocket、LiveKit（WebRTC）、SmallWebRTCTransport、Vonage（WebRTC）、WebSocket Server、WhatsApp、Local。つまり同じエージェント実装のまま、ブラウザ越しの会話も電話回線もWhatsAppも通せる設計です。 ここで気づいてほしいのは、「PipecatかLiveKitか」という二者択一が実は成立しないことです。PipecatのtransportにLiveKitが含まれている以上、LiveKitのインフラの上でPipecatのパイプラインを動かす構成が普通に取れます。層が違うものを並べて比較していた、という整理になります。 v1.0.0のリリースは 2026-04-14 で、実測時点の最新は v1.8.1（2026-08-27）。約4か月半で1.0→1.8と、メジャー安定版到達後も速いペースで進んでいます。 LiveKit Agents——エージェントが「参加者」としてルームに入る LiveKit Agentsの設計思想はREADMEの一文に集約されています——「realtime, programmable participants（リアルタイムでプログラマブルな参加者）」を作るためのフレームワーク。エージェントがWebRTCのルームに参加者として入るモデルです。 この設計が効くのは、会話が2者で閉じない場面です。候補者とAI、そこに人事担当者が同席する。画面共有をしながら話す。録画を残す。こうした要件は「参加者」モデルなら追加の参加者を増やすだけで済みますが、1対1の音声ストリームを前提に組んだ実装では後付けが重くなります。セッション状態・再接続・低遅延といった面倒もRTC層から降ってきます。 READMEに明記されている機能のうち実務で効くのは2つです。セマンティックなターン終了検知（transformerモデルでユーザーの発話が終わったかを判定し、割り込みを減らす）と、テレフォニー統合（LiveKitのSIPスタック経由で電話の発着信ができる）。 TEN Framework——VAD・ターン検知を独立コンポーネントとして持つ TEN Framework（開発元はAgora）は、リアルタイムマルチモーダル対話のためのフレームワークです。特徴はエコシステムを構成要素ごとに切り出していること。README上では TEN Framework 本体のほかに、TEN VAD（低遅延・軽量なストリーミング音声区間検出）と TEN Turn Detection（全二重の対話を可能にするターン検知）が独立したリポジトリとして並んでいます。 アバター連携の設計サンプルとしても読む価値があります。READMEの「Lip Sync Avatars」の項には、MotionSyncによるリップシンクを持つアニメキャラクター（Kei）に加えて、Trulience・HeyGen・Tavus といった実写系ベンダーに対応すると書かれています。①の層のフレームワークが②の層をどう抽... --- ## 3D Gaussian Splatting（3DGS）とは｜本家のライセンス・環境要件・実装の選び方を実測解説 - URL: https://ai-heartland.com/explain/3d-gaussian-splatting-guide/ - 更新日: 2026-08-28 - カテゴリ: explain - 概要: 3D Gaussian Splatting（3DGS）の本家リポジトリを実測で解説。★23,495だがmainは2024年10月で停止し、ライセンスは非商用限定。公式environment.ymlのCUDA指定をA/Bで検証し、実装の選び方まで整理する。 - タグ: 3DGS, 3D-Gaussian-Splatting, 3D生成, レンダリング, CUDA, Inria, oss, ライセンス 写真を何十枚か撮ってしばらく待つだけで、その場に立っているかのような3D空間がぬるぬる動く——3D Gaussian Splatting（3DGS） が2023年に登場したとき、多くの人が受けた衝撃はそれだった。日本語でも「3DGSとは」「フォトグラメトリとの違い」といった解説はこの2年でかなり増えた。 ところが、その入口として必ず紹介される本家リポジトリ graphdeco-inria/gaussian-splatting が今どうなっているかを書いた日本語記事は、ほとんど無い。★は23,495に達しているのに main ブランチは2024年10月から動いておらず、ライセンスは非商用限定で、公式の environment.yml には README の記述と噛み合わない箇所がある。本記事は、その3点をすべて手元で実測して整理する。 本記事で実測した4点。GitHub API・4リポジトリのLICENSE.md・依存解決をそれぞれ個別に確認した（2026-08-28） 30秒でわかる — この記事で実測したこと 本家の main は2024年10月30日で止まっている — タグもリリースも0件。GitHub API の pushed_at は2025年10月17日を返すが、その実体は ishaan/wip_new_viewer という作業中ブランチへの push であって、本体の更新ではない ライセンスは非商用限定で、しかも中核サブモジュールにも同じ条件が付く — 本体・diff-gaussian-rasterization・simple-knn の3つが Inria/MPII の独自ライセンス。学習を回す最小構成がまるごと非商用側に入る 公式 environment.yml の CUDA 指定を README の推奨に合わせると、PyTorch が黙って CPU 版になる — cudatoolkit=11.8 へ変えて solve すると、エラーを出さないまま pytorch 1.12.1 py3.7_cpu_0 が選ばれる 3DGS は生成AIそのものではなく、写真から空間を再構成するレンダリング技術だ。ただし出力形式としての「3D Gaussian」は画像→3D生成AIの世界とも地続きで、生成AI全体のどこに位置する話なのかを掴んでおくと理解が速い。全体像はLLMとは？仕組み・主要モデル比較・ローカル実行・量子化を一気にまとめる2026年版を参照してほしい。 3D Gaussian Splatting（3DGS）とは——SIGGRAPH 2023論文と本家リポジトリ 3D Gaussian Splatting は、複数視点から撮影した写真群をもとにシーンを再構成し、任意の新しい視点からの見た目をリアルタイムに描画する手法だ。原典は SIGGRAPH 2023（ACM Transactions on Graphics 42巻4号、2023年7月） に採録された論文で、著者は Bernhard Kerbl、Georgios Kopanas（両名が等貢献）、Thomas Leimkühler、George Drettakis の4名。所属は Inria、Université Côte d’Azur、Max Planck Institut für Informatik である。 論文が主張する貢献は3点に整理されている。①カメラキャリブレーション時に得られる疎な点群を出発点に、シーンを3次元ガウシアンの集合として表現すること。②最適化とガウシアンの密度制御を交互に行い、異方性の共分散を最適化すること。③可視性を考慮した高速な描画アルゴリズムにより、異方性スプラッティングを支えつつ学習も描画も加速すること。この3つで、1080p 解像度で 30fps 以上のリアルタイム新視点合成を達成した。 flowchart TD A["写真群（数十〜数百枚）"] --> B["COLMAP でカメラ位置推定"] B --> C["疎な点群（SfM points）"] C --> D["3Dガウシアンとして初期化"] D --> E["微分可能ラスタライザで描画"] E --> F["元写真との差分で損失計算"] F --> G["位置・共分散・色・不透明度を更新"] G --> H["密度制御（分割・複製・削除）"] H --> E G --> I["学習済み .ply（ガウシアン群）"] I --> J["ビューアでリアルタイム描画"] ここで押さえておきたいのは、3DGS の入口が COLMAP であるという点だ。本家のパイプラインは写真から直接始まるのではなく、まず COLMAP（Structure-from-Motion）でカメラの位置姿勢と疎な点群を求め、その点群をガウシアンの初期値にする。つまり3DGSを動かすには 3DGS 本体だけでなく COLMAP も必要で、撮影の失敗（テクスチャの乏しい壁、動く被写体、露出のばらつき）はまず COLMAP の段階で効いてくる。 NeRF との違いもここに関係する。NeRF はニューラルネットが空間の色と密度を暗黙的に持つため、1点の色を得るのにネットワークの前向き計算が要る。3DGS は空間を明示的なガウシアンの集合として持ち、描画はそれをスクリーンへ投影して合成するだけなので、学習済みシーンの描画がはるかに軽い。代わりにデータサイズは大きくなりやすく、出力の .ply は数百MBに達することもある。 ・入力：同一シーンを複数視点から撮った写真群（動画からのフレーム抽出でも可） ・前処理：COLMAP によるカメラ位置推定と疎な点群生成 ・学習：GPU上でガウシアンのパラメータを最適化。本家READMEは論文品質で24GB VRAMを要件に挙げる ・出力：.ply 形式のガウシアン群。メッシュではないため、そのままではゲームエンジンの通常パイプラインに乗らない ・描画：専用ビューア（本家のSIBR、またはWebGL系ビューア）でリアルタイム表示 では、その「3次元ガウシアン」1個は何を持っているのか。ここを押さえると .ply のファイルサイズが大きくなる理由も、学習で何が動いているのかも見通しがよくなる。1個のガウシアンが保持するのは次の4種類のパラメータだ。 ・位置（3次元の平均） — 空間のどこにあるか ・共分散行列（異方性） — どの方向にどれだけ伸びた楕円体か。実装上はスケール3成分と回転クォータニオン4成分に分解して保持し、最適化中も正定値性が崩れないようにしている ・不透明度 — 手前のガウシアンが背後をどれだけ隠すか。アルファ合成の重みになる ・色（球面調和係数） — 単なるRGB1色ではなく、見る方向によって色が変わる関数として持つ。金属やガラスのてかりが視点で動くのはこの成分の働きによる 論文の貢献②にある「異方性の共分散を最適化する」とは、この楕円体の向きと伸びを写真に合うよう調整することを指す。壁のような平たい面は薄く潰れた楕円体で、細い枝は細長い楕円体で表現できるので、同じ枚数でも表現力が上がる。加えて密度制御が並行して走り、誤差の大きい領域ではガウシアンを分割・複製し、不透明度がほぼゼロになったものは削除する。最終的なガウシアン数はシーン次第で数十万から数百万に及ぶ。 1個あたりのパラメータが数十個あり、それが数百万個あるのだから、.ply が数百MBになるのは必然だ。配布や Web 表示を考えるなら、この時点で圧縮・間引きを行うツール（後述の supersplat など）が必要になる、と見込んでおくとよい。 画像1枚から3Dアセットを「生成」する系統の技術とは目的が違う点にも注意したい。3DGS は実在するシーンの再構成であって、無い部分を作り出すものではない。生成側の代表例はTRELLIS完全ガイド｜Microsoftの画像→3D生成AI・SLATの仕組みと導入・比較まで解説で扱っており、TRELLIS が出力形式のひとつとして「3D Gaussian」を持つのは、まさに本記事の表現形式が共通言語になっているからだ。 【実測】本家リポジトリは今どうなっているか——mainは2024年10月で停止 「3D Gaussian Splatting を試したい」と検索して最初にたどり着くのが本家リポジトリだが、そこが現在どう保守されているかを確認せずに着手すると、後から時間を失う。2026年8月28日時点で GitHub API から実測した値を並べる。 本家リポジトリのブランチ更新実態。GitHub API の pushed_at と、main の実際の最終コミット日は一致しない 項目 実測値（2026-08-28） star 23,495 fork 3,382 オープンissue+PR 713（GitHub の open_issues_count はPRを含む） リポジトリ作成 2023-07-04 main の最終コミット 2024-10-30（fix submodule name in environment.yml） dev ブランチ 2024-09-17 licensed ブランチ 2024-10-30 ishaan/wip_new_viewer 2025-10-17 API の pushed_at 2025-10-17 タグ 0件 リリース 0件 archived フラグ false ここで誤読しやすいのが ... --- ## Refactoring UIの原則をClaude Codeに守らせるスキル｜実測すると発火しない条件がある - URL: https://ai-heartland.com/explain/refactoring-ui-skill-claude-code/ - 更新日: 2026-08-28 - カテゴリ: explain - 概要: Refactoring UI（Wathan & Schoger）の設計原則をClaude Codeに適用するスキル refactoring-ui-skill を実測した。余白16基準・文字11段・太さ2種という尺度を強制する仕組みだが、依頼の言い回しによっては読み込まれていても発火しない。発火の見分け方まで検証する。 - タグ: design, Claude Code, SKILL.md, UI, CSS AIコーディング支援が吐くUIが「どれも同じ顔で、どこか素人っぽい」と言われる原因の多くは、センスではなく値の決め方にある。17px と 18px、#3B82F6 と lighten(5%) を毎回その場で選んでいると、全体の統一が崩れる。これを潰すのが書籍『Refactoring UI』（Adam Wathan & Steve Schoger）の考え方で、その原則をClaude Codeに実行させるスキルが s0xDk/refactoring-ui-skill（★140・MIT・2026-08-26 公開）である。実際に導入して測ったところ、入れただけでは効かないという結果になった。 手元での実測（2026-08-27）。同一ディレクトリ・同一スキルでも、依頼の言い回しで Skill 呼び出しの有無が割れる この記事のポイント ・Refactoring UI の原則を「余白・文字・太さ・影」の4つの数値尺度に落として強制するスキル ・実測では「カードを作って」では発火せず、「素人っぽい」と言うと発火した。導入＝適用ではない ・発火しても尺度からの逸脱は残る（font-size 5/7・太さ4種）。保証ではなく改善である デザイントークンやスケールという考え方そのものを整理したい場合は、デザインシステムとは？仕組み・構成要素・有名事例をエンジニア向けに整理する【2026年版】を先に読むと、以下の「尺度を1つに決める」という話が早く飲み込める。 Refactoring UI スキルは何を強制するのか——4つの尺度 このスキルの主張は SKILL.md の冒頭1文に集約されている。視覚デザインは才能ではなく、一度だけ行うシステム上の決定と、階層を作るための少数の技法である、と。したがってスキルの中身は「センスの教え方」ではなく、選んでよい値のリストになっている。 配布される尺度は4つ。 ・余白・寸法 — 4 8 12 16 24 32 48 64 96 128 192 256 384 512 640 768。16pxを基準に、隣り合う値の差が常に25%以上あく。margin・padding・幅・高さ・アイコン寸法・線幅まで全部これで賄う ・文字サイズ — 12 14 16 18 20 24 30 36 48 60 72。比率から生成する modular scale ではなく手で選んだ値。単位は px か rem のみで、em は禁止（.875em が 1.25em の内側に入ると 17.5px という尺度外の値が生まれ、尺度が黙って消えるため） ・太さ — 2種類だけ。本文が 400 か 500、強調が 600 か 700。400未満は使わない。弱く見せたいときは太さではなく色を薄くするか字を小さくする ・影 — 光源を1つに固定し、下方向だけに落とす。段階も固定 「隣り合う値の差が25%以上」という条件が効いているのは、選択を機械的に一意にするためだ。4の倍数を並べただけの線形スケールは、120pxと124pxのどちらを選ぶかを助けてくれない。 スキルが配布する4尺度。`assets/tokens.css`（149行）にCSS変数として同じ値が入っている リポジトリは全部で900行と小さい。内訳は SKILL.md 267行、references/systems.md 144行、references/techniques.md 216行、references/diagnose.md 44行、assets/tokens.css 149行、README.md 80行。references/ はスキル本体から必要に応じて読み込まれる追加資料で、後述の実測でも発火時にだけ読まれていた。 assets/tokens.css はそのままプロジェクトにコピーして使う想定のCSS変数集で、灰色のランプはHSLで組まれ、明度が50%から離れるほど彩度を上げるという書籍のルールに従っている。灰色に色味（既定は寒色系、暖色にしたければ色相を約39へ）を入れる指示もそのまま入っている。 実測：Refactoring UI スキルは読み込まれていたが、発火しなかった ここが本題である。Claude Code 2.1.241 で、スキルを置いたディレクトリと置いていないディレクトリを用意し、同じ依頼を投げた（2026-08-27・macOS）。 最初の依頼はごく普通の言い方にした。 統計ダッシュボードのカードコンポーネントを1つ、HTMLとCSSで作ってください。コードだけ返してください。 結果は次のとおり。 観測項目 スキル設置あり スキル設置なし ターン数 1 5 Skill ツールの呼び出し 0件 dataviz（同梱スキル）1件 refactoring-ui の発火 なし — 出力 HTML/CSS 3,098字 HTML/CSS 3,461字 スキルを置いた側で refactoring-ui はまったく呼ばれていない。「入れたつもりで効いていない」状態がそのまま再現した。 読み込まれていないのか、選ばれていないのか 原因の切り分けが要る。同じディレクトリで、スキルの一覧を出させた。 claude -p "利用可能なスキルを列挙してください。名前だけでいい。" \ --allowedTools "Skill,Read,Glob" < /dev/null 返ってきた一覧の中に refactoring-ui は含まれていた。読み込みは成功していて、呼ばれていないだけである。つまり設定の問題ではなく、依頼文とスキルの description が結びつかなかったという経路の問題だ。 そこで description に書かれている語をそのまま依頼に入れた。この description には「a UI が looks off / looks amateur / feels cluttered と言われたとき」「make this look better と頼まれたとき」に使う、と列挙されている。 このダッシュボードのUI、なんか素人っぽく見えます。よくしてください。HTML/CSSで書き直して。 今度は発火した。実行ログには次の行が出た。 "name":"Skill","input":{"skill":"refactoring-ui"} "content":"Launching skill: refactoring-ui" さらに references/ 配下のファイルを Read で読みに行く挙動も観測できた。スキルの description は「何をするか」の説明文ではなく、呼び出しの経路そのものとして働いている。 同一ディレクトリ・同一スキルでの対比。差は依頼の言い回しだけ flowchart TD A["依頼を投げる"] --> B{"description の語と結びつくか"} B -->|"「カードを作って」= 結びつかない"| C["Skill 呼び出し 0件出力は導入前とほぼ同じ"] B -->|"「素人っぽい」「よくして」= 結びつく"| D["Launching skill: refactoring-ui"] D --> E["references/ を追加で読む"] E --> F["尺度に寄せたCSSを出力（ただし完全ではない）"] style C fill:#ffe6e6 style F fill:#e8f5e9 色は「9段のランプ」と、コントラスト比の注記で配られる 4尺度のうち色だけは扱いが厚い。references/systems.md は色を作る手順を9節に分けて説明していて、要点はHSLで組み、明度が50%から離れるほど彩度を上げることにある。RGBやHEXで明度だけを機械的に上下させると、端に行くほど色が灰色に沈んで死ぬ。だから基準色（500）を先に決め、両端（900と100）を決め、あいだを埋める、という順序を取る。 assets/tokens.css が面白いのは、各段にコントラスト比が実測値としてコメントで書き込まれている点だ。 ・--grey-400（2.7:1）— 無効状態のテキスト専用。WCAGは非活性コンポーネントを免除するが、プレースホルダは活性コンテンツなので免除されない、という注記つき ・--grey-500（3.9:1）— 大きい文字専用（24px以上、太字なら18.66px以上）。12pxの小見出しには使えないと明記 ・--grey-600（5.6:1）— 脚注・著作権表記などの三次テキスト ・--grey-700（8.0:1）— 二次テキスト ・--grey-900（13.4:1）— 本文 「薄いグレーを使ったらアクセシビリティで落ちた」という事故は、どの段が何に使えるかが数字で書かれていないことから起きる。このトークン集はそこを潰しにいっている。アクセントカラー（赤・黄・緑）を100/500/800の3段だけに絞っているのも意図的で、100を背景・500を塗り・800をその背景の上の文字という三点セットが、色でコントラストを稼ぐ「flip the contrast」という技法に必要な最小構成だからだ。淡い黄色の帯に濃い黄土色の文字を載せる、というあのパターンである。 影も同じ発想で、--shadow-1 から --shadow-5 までを見た目ではなくz軸上の位置で選ぶと決めている（1がボタン、2がドロップダウン、5がモーダル）。角丸は --radius: 4px の... --- ## AITuberKitとは？MITではない商用ライセンス料金と開発停止・再開の実測、対応LLM15種を解説 - URL: https://ai-heartland.com/tool/aituberkit-license-and-status/ - 更新日: 2026-08-28 - カテゴリ: tool - 概要: AITuberKitはVRM/Live2DのAIキャラと話せるWebアプリの土台。2025年11月に開発停止が告知されながら2026年2月に再開した経緯をリリース履歴で実測し、MITではないカスタムライセンスの商用料金（価格明示は10万/30万/100万円の3種＋個別見積もり）と対応LLM15種・音声合成11種を整理する。 - タグ: AIエージェント, AITuber, オープンソース, TTS 「AIキャラクターと声で会話できるWebアプリを作りたい」と調べると、日本語圏でまず名前が挙がるのが AITuberKit（tegnike/aituber-kit）です。VRM/Live2Dのキャラクターをブラウザで動かし、LLMと音声合成を差し替えながら対話・配信・デジタルサイネージまでカバーできる、実質的に国内標準に近い立ち位置のツールキットになっています。ただし採用の可否を分ける情報が2つ、検索結果の表面には出てきません。ライセンスがMITではないことと、一度「開発停止」が告知されていることです。この記事はその2点を一次情報とGitHubの実データで確認したうえで、機能と選定基準を整理します。なお、キャラクターの見た目ではなく対話の中身をどう組むかという土台側の選定は別問題で、そちらはAIエージェントフレームワーク比較2026｜LangGraph・CrewAI・Dify等9種をStar数・実コードで検証にまとめています。 GitHub Releases APIで取得した AITuberKit の月別リリース本数（全123リリース、2026-08-28 実測）。2025-09〜2026-01 の5か月が空白で、2026-02 に再開している。 この記事のポイント（30秒でわかる AITuberKit） ・何ができるか：VRM（3D）・Live2D（2D）のキャラクターがブラウザ上で喋る対話アプリを、コードをほぼ書かずに立ち上げられる。YouTube配信への自動応答、デジタルサイネージ向けのデモ端末モード、OpenAI Realtime APIによる低遅延対話まで同梱 ・ライセンス：v1.x.x は MIT、v2.0.0 以降はカスタムライセンス。個人の非営利利用・教育・非営利団体・デモ展示は無償、商用利用は別途購入が必要（公式記載で価格明示は10万／30万／100万円の3種、ほかに個別見積もりのカスタムライセンス。いずれも税込・買い切り） ・開発状況：2025年11月に開発停止が告知され、リリースは2025-09〜2026-01の5か月間ゼロ。2026年2月に再開し、実測時点では v2.74.0（2026-08-12）まで進んでいる ・差し替えできる範囲：対応LLM 15種・音声合成エンジン 11種（READMEの記載）。Ollama / LM Studio でローカルLLMも選べる ・向く用途：個人のAITuber配信、イベント展示、社内PoC。向かない用途：ライセンス費用を見込んでいない商用サービスへの無断組み込み AITuberKitとは——VRM/Live2Dキャラが喋るWebアプリの土台 AITuberKitは、pixiv株式会社が公開する ChatVRM をフォークして開発されているツールキットです（READMEの謝辞に明記）。リポジトリの初期コミットは2023年4月28日、GitHub Releasesの1本目は2024年6月です。READMEの言葉を借りれば「誰でも簡単にAIキャラクターとチャットできるWebアプリケーションを構築できる」ことを狙ったもので、実体は Next.js のWebアプリです。 技術的な立ち位置を一言でいうと、「ガワ」に相当する部分をまるごと引き受けるプロダクトです。キャラクターの描画、音声の再生、会話履歴の保持、設定UI——AIキャラを作ろうとしたときに地味に時間を吸われる部分が最初から入っています。逆に、LLMも音声合成も自前では持っていません。どちらも外部のAPIまたはローカルサーバーに投げる設計で、そこが差し替え可能な拡張点になっています。 機能はREADMEの分類で5つに整理されています。 カテゴリ 主な内容 AIキャラとの対話 各種LLM APIキーでの会話、カメラ映像・画像を認識するマルチモーダル対応、直近会話の記憶保持、RAGベースの長期記憶 AITuber配信 YouTube配信コメントの取得と自動応答（YouTube API / わんコメ）、コメントが無くても発言する会話継続モード デモ端末・デジタルサイネージ フルスクリーン表示のデモ端末モード（パスコード認証・NGワードフィルタ・入力長制限）、カメラ顔検出による人感検知、アイドルモード 高度な対話モード OpenAI Realtime APIによる低遅延対話と関数実行、オーディオモード、Reasoningモード、ゲーム実況モード 連携・拡張 WebSocketでの外部連携モード、スライドを自動発表するスライドモード、外部APIからの発話指示 注目したいのは3番目の「デモ端末・デジタルサイネージ」です。パスコード認証・NGワードフィルタ・入力長制限・人感検知といった機能は、個人の配信用途ではなく展示や店頭設置を想定した実装です。つまりAITuberKitは早い段階から業務用途を視野に入れており、それが後述するライセンス設計とも整合しています。 AITuberKitが担当する範囲。キャラクター描画とアプリのガワを引き受け、LLMと音声合成は外部に委譲する。 対話の中身そのものをどう組むか——複数ステップの推論やツール実行を伴う設計——は、AITuberKitの守備範囲の外です。質問の分岐や深掘りを状態遷移として設計したい場合は、LangGraph入門｜とは？状態遷移でマルチエージェントを作る基本とLangChainとの違い・比較のような外部のフレームワークと組み合わせることになります。 開発は止まっているのか——リリース履歴で見る5か月の空白と再開 「AITuberKit」で検索すると、公式サイトと公式ドキュメントに混じって、開発者本人による「AITuberKitの開発停止報告と今後」というnote記事が上位に表示されます。2025年11月17日公開の記事で、2024年5月から「1年と数カ月」ほぼ毎日開発してきたと振り返ったうえで開発停止を告知しています。理由として挙げられているのは、もともとの関心が「AITuberを作ること」であって「AITuberツールを作ること」ではなかったこと、そして自身のAIキャラクター「AIニケちゃん」に時間を割きたいことです。副次的な理由として、AIキャラクター関連のプロダクトが増えてきたことにも触れています。継続するものとしては、Discord・X DMでの質問対応、重大なバグ修正、商用ライセンス販売の3つが挙げられています。さらに、プロジェクト全体の譲渡について後継者をX DMで募る一方、「完全な無償オープンソース化は予定していない」とも書かれています。後述するライセンスの話は、この方針と地続きです。 一方でGitHubのリポジトリを見ると、実測時点（2026-08-28）で v2.74.0 が 2026-08-12 にリリースされており、直近コミットも2026-08-17です。告知と現状が食い違って見えるので、GitHub Releases APIで全リリースを取得して月別に数え直しました。 # 全リリースを取得して公開月ごとに集計する（要 GITHUB_TOKEN） gh api --paginate 'repos/tegnike/aituber-kit/releases' \ --jq '.[].published_at[0:7]' | sort | uniq -c 結果は次の通りです（全123リリース）。 期間 リリース本数 状況 2024-06 〜 2025-08（15か月） 81本 継続的に開発。月平均5.4本 2025-09 〜 2026-01（5か月） 0本 完全な空白。2025年11月の停止告知はこの期間中 2026-02 〜 2026-03 9本 再開 2026-06 〜 2026-08 33本 月9〜14本。告知前の平均を上回るペース つまり、開発停止の告知は実態を正確に反映していた（実際に5か月止まった）が、その後に再開しており、現在は停止前より活発という二段構えの状況です。2026年4月〜5月も0本なので、再開後の立ち上がりも一直線ではありません。 この記事で言えること／言えないこと 上の表は「リリースの本数」という観測可能な事実だけを数えたものです。開発者本人が停止方針を撤回したという公式の表明は確認できていません。 停止告知で継続対象とされた「重大なバグ修正」の延長として結果的にリリースが増えている可能性も、方針が変わった可能性も、この数字だけでは区別できません。導入を検討する場合は、リポジトリの Issues や Discord で現在のメンテナンス方針を直接確認することをおすすめします。 実務上の読み方としては、「一度5か月止まった実績がある」ことを前提に依存の深さを決めるのが妥当です。フォークして自前で保守できる規模か、アップストリームの更新に業務が依存しないか——この2点が確認できていれば、現在のリリースペースは十分に健全な部類に入ります。 AITuberKitのライセンスはMITではない——商用利用の料金体系 導入判断に一番効くのがここです。AITuberKitのREADMEは冒頭で自らを「オープンソースのツールキット」と紹介していますが、現行バージョンのライセンスはOSI準拠のオープンソースライセンスではありません。 公式ドキュメント（docs/license.md）の記載を整理すると、次のようになります。 区分 条件 費用 v1.x.x MITライセンス 無償 無償利用（v2.0.0以降） 個人の非営利利用／教育目的／非営利団体の非営利活動／認知度向上... --- ## Next.js脆弱性｜CVE-2026-75604とAVIF RCEの影響範囲・自分のアプリの確認手順 - URL: https://ai-heartland.com/security/nextjs-vulnerability-guide/ - 更新日: 2026-08-28 - カテゴリ: security - 概要: Next.jsの脆弱性を2026年公開の33件から整理。8月のcritical 2件（CVE-2026-75604のWindows RCEとAVIF経由のRCE）について、影響を受ける条件・自分のアプリでの確認コマンド・修正パッチの実測差分・アップデート後に変わる挙動までまとめました。 - タグ: security, セキュリティ, cve, nextjs, rce, image-optimization 2026年8月25日（日本時間26日未明）、Next.js に critical 判定の脆弱性が2件 同時に公開されました。ひとつは Windows 上で動くサーバーで認証なしのリモートコード実行に至る CVE-2026-75604、もうひとつは画像最適化が AVIF ファイルを処理したときに同じく認証なしの RCE に至る GHSA-2xp9-vwfh-vxw4 です。Vercel は当初予告していたリリース日を前倒しして、15.5.24 と 16.3.3 を公開しました。この記事では「自分のアプリは影響を受けるのか」を切り分けられるところまで、公式アドバイザリと npm 配布物の実測にもとづいて整理します。 2026年8月の時系列。libheif 側の critical が見つかったことでリリースが前倒しされ、修正版公開の約3時間後には公開PoCリポジトリが出現している（各時刻はGitHub Security Advisory APIとリポジトリAPIの実測値、日本時間表記） 30秒でわかる ・critical 2件：CVE-2026-75604（Windows ホストの RCE・CVSS 3.1 で 9.0）と GHSA-2xp9-vwfh-vxw4（AVIF 経由の RCE・CVSS 4.0 で 9.5） ・修正版は 15.5.24 と 16.3.3 のみ。13系・14系・16.2系に修正版は存在しない ・Windows 側に回避策はないとVercelが明記。Linux / macOS は CVE-2026-75604 の影響を受けない ・AVIF 側はOSを問わないため、Windows以外もアップデートは必要 ・アップデートで挙動が変わる：15.5.24 以降、AVIF 画像は最適化されず元ファイルがそのまま返る Next.js の脆弱性は単発の事故ではなく、npm エコシステム全体の依存関係リスクの一部です。今回の AVIF 側の問題も、Next.js 自身ではなく sharp が使う libheif という2段階下の依存に原因があります。依存の連鎖がどう攻撃面になるかは サプライチェーン攻撃とは｜手口・防御ツール比較・npm 12の新機構まで実践解説 で全体像を扱っています。 Next.jsの脆弱性とは——2026年に公開された33件の全体像 まず前提として、Next.js の脆弱性公開は「たまに起きるイベント」ではありません。GitHub Security Advisory API で vercel/next.js のアドバイザリを取得すると、2026年1月1日以降に公開されたものだけで33件あります（2026年8月28日時点の実測）。 内訳は以下のとおりです。 深刻度 件数 備考 critical 2 いずれも2026年8月25日公開 high 13 Middleware バイパス・SSRF・DoS が中心 medium 16 キャッシュ混線・XSS・情報開示など low 2 キャッシュポイズニング系 合計 33 — 2026年のNext.js脆弱性33件の公開日分布。まとめて公開される「セキュリティリリース」形式が定着しており、8月25日の2件だけがcritical判定（GitHub Security Advisory API実測） 重要なのは公開のパターンです。Next.js のセキュリティ修正は個別に小出しにされるのではなく、複数件をまとめた「セキュリティリリース」としてまとめて公開されます。2026年5月6日の10件、7月21日の8件がその典型で、そのたびに 15系・16系それぞれの修正版が同時にリリースされます。 つまり「前回アップデートしたばかりだから大丈夫」は成立しません。2026年だけで修正版が出たタイミングは6回あり、そのつど15系・16系の両方でパッチ番号が進んでいます。 なお2026年5月の一斉公開（CVE-2026-44574〜44582）については Next.js脆弱性CVE-2026-44574〜44582一斉公開｜最大CVSS 8.6・15.5.18で修正 で個別に扱っています。本記事は「いま自分のバージョンが安全か」を判断するための通しの視点、あちらは5月時点の各CVEの詳細という役割分担です。 2026年8月のcritical 2件で何が起きたのか 8月25日に公開された2件は、性質がまったく異なります。 項目 CVE-2026-75604 GHSA-2xp9-vwfh-vxw4 GHSA ID GHSA-p293-qw3h-jr36 GHSA-2xp9-vwfh-vxw4 CVE番号 CVE-2026-75604 未採番 深刻度 critical critical スコア CVSS 3.1 で 9.0 CVSS 4.0 で 9.5 ベクタ AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H 分類 CWE-22（パストラバーサル） ヒープバッファオーバーフロー（上流） 原因の所在 Next.js 本体 libheif（sharp 経由の依存） 影響条件 Windows ファイルシステム上で動作 AVIF 画像を最適化する構成 OS依存 あり（Linux / macOS は非該当） なし 回避策 なし（Vercelが明記） AVIF を扱わなければ非該当 2つのスコアは別の物差しです。 9.0 は CVSS 3.1、9.5 は CVSS 4.0 で算出されており、単純に「9.5 のほうが 0.5 だけ危険」とは読めません。同じ列に並べて比較しないでください。 また、両方とも攻撃の難易度を示す要素が付いています。CVE-2026-75604 は AC:H（攻撃条件の複雑さが高い）、AVIF 側は AT:P（攻撃要件あり）です。これらは「悪用が自明ではない」ことを示しますが、回避策が存在しないことと、後述するとおり公開から数時間でPoCが出回ったことのほうが、実務上の緊急度を決めています。 AVIF側の原因はNext.jsの外にある AVIF 側の根本原因は Next.js のコードではありません。Next.js は画像最適化に sharp を使い、sharp は HEIF/AVIF のデコードに libheif を使います。この libheif に GHSA-g89c-p67h-r497（CVSS 3.1 で 9.8、こちらもCVE未採番）というヒープバッファオーバーフローが見つかりました。 脆弱性の性質を悪用に踏み込まない範囲で述べると、細工された HEIF / AVIF ファイルが、8ビット精度で確保されたアルファプレーンの領域に対して16ビット幅の書き込みを行わせるというものです。画像の内部構造上、同じアルファチャンネルが複数登録されうるのに、確保サイズの決定には最初のひとつしか参照されていませんでした。書き込む値と溢れる量の両方が細工したファイル側から制御できるため、単なるクラッシュに留まりません。libheif 側のアドバイザリには、複数のアプリケーションで実際にRCEに到達できたと記載されています。 libheif 側は v1.23.2 で修正済み（v1.23.1 以前が影響対象）ですが、この修正が sharp の配布バイナリに行き渡るまでには時間がかかります。Vercel が「上流の修正が伝播するまで AVIF の最適化を無効化する」という判断を取ったのはこのためです。 自分のアプリは脆弱性の影響を受けるか——バージョンと条件の確認手順 ここが本題です。3つの軸で切り分けます。 1. 使っている Next.js のバージョンを確定させる package.json の記載ではなく、実際にインストールされている版を見てください。キャレット指定でも lockfile が古ければ古い版のままです。 # 実際に解決されているバージョンを確認する npm ls next # pnpm / yarn の場合 pnpm why next yarn why next 15.5.24 以上（15系）または 16.3.3 以上（16系）であれば、8月25日公開の2件については修正済みです。 2. Windows ファイルシステム上で動いているか CVE-2026-75604 の条件は「Next.js サーバーが Windows のファイルシステムを使っていること」です。Vercel は Linux と macOS が影響を受けないことを明記しています。 判断のポイントは開発機ではなく本番の実行環境です。Windows マシンで開発していても、本番が Linux コンテナなら CVE-2026-75604 の対象ではありません。逆に Windows Server や Windows 上の IIS / PM2 でホストしているなら対象です。WSL2 上で Linux ファイルシステムに置いて動かしている構成は対象外と考えられますが、/mnt/c 配下にプロジェクトを置く構成は Windows ファイルシステムを経由するため、対象として扱うのが安全です（この2ケースは当サイトでは未検証のため、断定は避けます）。 3. AVIF 画像を最適化しているか AVIF 側は「Next.js が攻撃者の制御下にある AVIF 画像を最適化したとき」に成立します。次の2点を確認してください。 ... --- ## AIエージェントの資格とは｜Google Cloud認定Agentic Architectの日本語対応と出題範囲 - URL: https://ai-heartland.com/explain/google-cloud-agentic-architect-certification/ - 更新日: 2026-08-28 - カテゴリ: explain - 概要: AIエージェントの資格Professional Agentic Architect（Google Cloud認定）は日本語で受けられるのか——結論は英語のみ。公式試験ガイドPDFから5セクションの配点と在スコープ28ツールを読み解き、他のGoogle Cloud認定との言語・有効期限の差、同名の国内資格との判別まで整理する。 - タグ: AIエージェント, google-cloud, 認定資格, agentic-architect, ADK, MCP, Gemini AIエージェントを業務システムとして組める人材を、クラウドベンダー自身が資格として認定しはじめた。Google Cloudは新しい認定資格 Professional Agentic Architect のベータを、2026年9月3日に登録開始する。ADK・MCP・A2A・Antigravity——このサイトで日々扱っているツール群が、そのまま出題範囲として名前で列挙された初のベンダー認定である。 しかも構成が変わっている。選択式試験に加えて「ハンズオンラボ」が必須の2部構成で、有効期限は1年。既存のGoogle Cloud Professional認定（2時間・50〜60問・有効期限2年）とは別物のフォーマットだ。本記事は公式試験ガイドPDFを一次情報として、配点・在スコープツール・他認定との差分を構造化する。 AIエージェントの実装手段そのものを比較したい方は AIエージェントフレームワーク比較2026｜LangGraph・CrewAI・Dify等9種をStar数・実コードで検証 をご覧ください。 公式試験ガイド（PDF）記載の配点。カスタムエージェント開発が約33%で最大の重みを持つ（出典: Professional Agentic Architect Certification exam guide） 30秒でわかる ・Google Cloudの新認定 Professional Agentic Architect のベータ登録が 2026年9月3日 開始。受験料は 120米ドル（正価200米ドルの40%引き） ・選択式（Pearson配信・約80問・3時間）＋ Google Skills上のハンズオンラボ の2部構成。他のGoogle Cloud認定にはない形式 ・言語は英語のみ。Professional Cloud Architect等が日本語対応なのに対し、この認定は日本語で受けられない ・有効期限は1年（Cloud Architectは2年、Generative AI Leaderは3年） ・出題範囲は5セクション。最大は カスタムエージェント開発が約33%。ADK・Agent Runtime・MCP・A2A・Model Armor など28個のツールが在スコープとして明示されている ・日本には同名の別資格（AICX協会「AIエージェント・アーキテクト」）が存在する。発行元も対象者も別物 ・筆者は未受験。本記事は受験記ではなく、公式ページと公式試験ガイドPDFの一次情報を突き合わせて構造化したもの Professional Agentic Architectとは——Google Cloudが認定する「AIエージェント実装者」 Google Cloudの認定ページは、この資格の対象者を次のように定義している。Google Cloud上で自律的でAI駆動のエージェント型ワークフローを設計・管理する技術実務者であり、信頼性・パフォーマンス・コスト・セキュリティ・スケーラビリティを考慮しながらエージェント型ソリューションを構築する経験豊富な開発者またはアーキテクト、というものだ。 抽象的な定義に見えるが、公式ページが列挙する「評価される能力」を並べると輪郭がはっきりする。 ・ローコードツールを使ったエージェント構築 ・アプリケーション開発におけるコーディングエージェントの活用 ・カスタムエージェントの開発 ・エージェント型ワークフローの評価とデプロイ ・エージェント型ワークフローのセキュリティとガバナンス 注目すべきは2番目だ。「コーディングエージェントを使ってアプリケーションを開発する能力」が、ベンダー認定の評価対象として正面から入っている。従来のクラウド認定は「クラウドサービスの設計・運用」を問うものであって、開発者がどんな道具で書いているかは問わなかった。この認定は道具の使い方そのものを問う。 前提資格はないが、推奨経験は重い 公式ページの記載は明快で、Prerequisites: None——前提資格は不要である。ただし推奨経験として次の2つが挙がっている。 ・クラウドソリューションの構築・テスト・デプロイ・管理の実務経験 3年以上 ・Google Cloud上でのエージェント型ソリューション構築経験 1年以上 後者が効いてくる。Google Cloudでエージェントを1年以上作っている、という条件は2026年8月時点ではかなり尖った要件だ。ADK（Agent Development Kit）やAgent Runtimeといったプロダクト自体が新しく、「1年以上の経験」を満たす母集団はまだ厚くない。ベータの位置づけを考えると、初期の受験者はGoogle Cloudのエージェント基盤を早期採用していた層に偏ることになる。 公式ページ「Beta exam details」に記載された数値（2026年8月27日時点で取得） 2部構成という珍しい形式 この認定の最大の構造的特徴は、認定が2つのパートで構成される点にある。公式ページは以下のように説明している。 ・Pearson配信の監督付き選択式試験 — 概念的な知識、システム設計上の選択、アーキテクチャ標準を評価する ・Google Skills上で受けるハンズオンラボ — 実際の実行力とコーディング能力を検証する 筆者が同日に4認定（Professional Cloud Architect・Professional Machine Learning Engineer・Professional Cloud Developer・Generative AI Leader）の公式ページ本文を hands-on / lab で検索したところ、ヒットはすべて「学習リソースとしてのハンズオンラボ」か「推奨される実務経験（hands-on experience）」の文脈で、認定の構成要素としてラボを要求する記述は1件も無かった。Cloud Architect にはケーススタディがあるが、これは選択式試験の内側の話である。ラボを試験と別枠で必須にするのは、少なくともこの4認定との比較では新しい形式と言える。 ベータ受験者への結果通知が「試験ウィンドウとラボウィンドウの両方が終了してから4〜6週間後」と書かれていることからも、選択式とラボがそれぞれ独立した実施期間を持つ設計であることが読み取れる。 flowchart TD A["2026年9月3日ベータ登録開始"] --> B["パート1選択式試験（Pearson）約80問・3時間・英語"] A --> C["パート2ハンズオンラボ（Google Skills）"] B --> D["試験ウィンドウ終了"] C --> E["ラボウィンドウ終了"] D --> F["両方の終了から4〜6週間後に結果通知"] E --> F F --> G["合格：Google Cloud CertifiedProfessional Agentic Architect"] F --> H["不合格：ベータの再受験は不可GA版を待つ"] 「AIエージェント・アーキテクト」は日本に2つある——AICX協会の資格との判別 ここで日本語話者が確実に踏む落とし穴を先に潰しておく。「AIエージェント・アーキテクト」という名前の資格は、2026年8月時点で日本に2つ存在する。 一般社団法人AICX協会は2026年2月13日のプレスリリースで、「AIエージェント・ストラテジスト」と「AIエージェント・アーキテクト」という2つの資格制度の創設を発表している。戦略設計と実装を分離した人材基準を提示するもので、同協会は3年で約1万人の受験を見込むとしている。 つまり日本語で「AIエージェント アーキテクト 資格」と検索したとき、Google Cloudの認定を探している人と、AICX協会の国内資格を探している人が混在する。両者は発行元も対象者も試験形式もまったく違う。 比較軸 Google CloudProfessional Agentic Architect AICX協会AIエージェント・アーキテクト 発行元 Google Cloud（米国・ベンダー認定） 一般社団法人AICX協会（日本・団体認定） 想定対象 経験ある開発者・アーキテクト 情報システム企画担当・社内SE・自動化担当 中心スキル コードを書いてGoogle Cloud上に構築（ADK・MCP・A2A） ノーコードツールでのAIエージェント構築・API連携 試験形式 選択式 約80問（3時間）＋ハンズオンラボ 未公表（2026年8月27日時点） 実施時期 ベータ登録 2026年9月3日開始 追って公表（姉妹資格のストラテジストは2026年6月中旬に第1回） 受験料 120米ドル（ベータ・正価200米ドル） 未公表（2026年8月27日時点） 言語 英語のみ 日本語 前提資格 なし（推奨経験3年以上＋エージェント1年以上） 学歴・実務経験を問わない AICX協会側の未公表項目について AICX協会の「AIエージェント・アーキテクト」は、プレスリリース時点で実施時期を「追って公表」としており、受験料・試験時間も公表されていません。二次情報として「75分・14,800円」という数字が流通していますが、これは先行して実施された姉妹資格「AIエージェント・ストラテジスト」の条件であり、アーキテクト側の条件として確認できたものではありません。本記事では確認できない数値は空欄のまま「未公表」とし... --- ## AIっぽい文章を機械で消すOSSスキル avoid-ai-writing｜日本語で実測したら検出器が動かず - URL: https://ai-heartland.com/explain/avoid-ai-writing-japanese-test/ - 更新日: 2026-08-28 - カテゴリ: explain - 概要: AIっぽい文章を検出して書き換えるOSSスキル avoid-ai-writing（★3,403・MIT）を手元のClaude Codeに入れて実測した。英語は80点→0点まで落ちる一方、日本語は210字でも「1語」と数えられ採点対象外になる。発火したかを確かめる方法まで含めて切り分ける。 - タグ: claude-code, ai-writing, SKILL.md, 文章校正, OSS 「AIっぽい文章」は、いま日本語のWebで最も指摘されやすい欠陥のひとつになった。読点の打ち方でも語彙でもなく、構文の型が繰り返されることで見抜かれる。この型を機械的に洗い出して書き直すスキルが conorbronsdon/avoid-ai-writing（★3,403・fork 302・MIT）で、Claude Code・Cursor・OpenClaw などで動く。本稿ではこれを実際に手元へ導入し、日本語で本当に効くのかを測った。結論から言うと、このスキルは2つの部品でできていて、片方は日本語で完全に動かない。 手元での実測（2026-08-27）。同じ「AIっぽい文章」でも、英語は80点・21指摘が付き、日本語は210字でも wordCount = 1 と数えられて採点されない 30秒でわかる ・中身は2部品。LLMに読ませる指示書 SKILL.md（816行・62パターン）と、依存ゼロの決定論的検出エンジン detector/patterns.js（2,180行） ・検出エンジンは日本語を採点できない。語数を空白区切りで数えるため210字が「1語」になり、10語未満で足切りされて UNSCORED を返す。字数を4倍にしても変わらない ・SKILL.md 側は日本語でも発火する。英語で書かれた指示書のまま、日本語の「XではなくY」構文や出典なしの権威づけを検出して直した ・効果は実測で 80点→0点。ただしスキル無しでも 80点→9点まで落ちる。差分は9点で、コストは5.9倍 ・発火の確認は --output-format stream-json。応答本文はスキル名に触れないことがある この記事のポイント ・AIっぽい文章の検出エンジンは英語専用で、日本語は210字でも「1語」と数えられ採点されない ・スキル本体（SKILL.md）は日本語でも発火し、日本語の型を正しく直す ・発火したかどうかは応答本文ではなく --output-format stream-json の Skill 呼び出しで確認する Claude Code のスキル機構そのもの（置き場所・優先順位・SKILL.md の書式）から確認したい場合は、Claude Code｜2026年版・インストールからCLAUDE.md・Hooks・本番運用までの実装手引きを先に読むと、この記事の導入手順が短く済む。 avoid-ai-writing とは——「AIっぽい文章」を型で捕まえるスキル このリポジトリが解こうとしているのは「文章がうまいか」ではなく「AIが書いたときに出やすい形が残っていないか」である。両者は別物で、後者は語彙と構文のパターンとして列挙できる。 SKILL.md の冒頭は、この道具の限界を自分から先に書いている。曰く、ここで挙げるパターンはLLM出力に統計的に多いだけで、締切に追われた人間や第二言語話者も同じ形を書く——だから採用・学術不正・掲載可否のような取り返しのつかない判断の単独根拠にするな、と明記されている。根拠として非英語話者への誤検出率が60%を超えたという Stanford の調査（Liang et al., Patterns 2023）などを自分で引いている。検出ツールを名乗りながら「これは証拠ではない」と先に宣言する構成は珍しい。 動作モードは3つある。 ・rewrite（既定）— 指摘して書き直す ・detect — 指摘だけして書き直さない。他人の文章や公開済みの記事を触らずに見るとき用 ・edit — ファイルを直接書き換える。散文ファイルに限定し、コード・設定・生成データは拒否する edit モードには、文書のなかに「上のルールを無視しろ」「この節は指摘するな」といった編集者宛の命令文が埋め込まれていた場合、それに従わずその文を指摘対象として報告するという指示が入っている。監査対象の文書を命令ではなくデータとして扱う、という境界を明示的に引いている点は、他のライティング系スキルではあまり見ない設計だ。 後述の実測結果。0点が「クリーン」。素のモデルだけで80→9まで落ちるため、スキルの取り分は残り9点ぶんになる 62パターンと112語の禁止語表 scripts/check-pattern-count.sh を走らせると、リポジトリが自分で数えた内訳が出る。手元の実行結果は次のとおり。 ・パターン数 62（SKILL.md と CLAUDE.md の記載が一致していることも同時に検査される） ・語の置換表 112語（59＋40＋13の3階層） 階層は Tier 1（delve・landscape・robust・seamless など、それ単体で強い兆候になる語）、Tier 2（単体では弱いが集まると効く語）、その他の補助語に分かれる。この階層は後述の実測ログにもそのまま出てきて、モデルは「Tier 1A」「Tier 1B」という語彙で指摘を返す。この語彙が出るかどうかは、スキルが発火したかを見分ける手掛かりになる。 パターン側で目立つのは、語ではなく構文を捕まえる規則群だ。 ・否定並列（”It’s not just X — it’s Y”／「単なるXではなくY」）— 1文書につき最大1回まで ・出典なしの権威づけ（”Experts believe”／「専門家によれば」） ・意味の薄い結び（”the future looks bright”／「まさに〜と言えるでしょう」） ・語彙の言い換え循環（developers → practitioners → builders → engineers と同義語を回す） ・語彙多様性（TTR）が0.40を下回る、いわゆる語彙の圧縮 実測1：AIっぽい文章の検出エンジンは日本語を採点しない ここからが本題である。detector/patterns.js は依存パッケージもビルド工程も持たない単一ファイルで、require() して analyzeText() を呼ぶだけで動く。まずは素直に日本語と英語を入れてみた。 git clone --depth 1 https://github.com/conorbronsdon/avoid-ai-writing.git cd avoid-ai-writing node -e ' const D = require("./detector/patterns.js"); const r = D.analyzeText("<ここに文章>"); console.log(r.score, r.label, r.stats.wordCount, r.document_classification); ' 手元（Node v22.13.1・2026-08-27）の結果を表にする。 入力 文字数 wordCount score label 判定 英語・AIっぽい文章 461 66 80 Strong AI signals AI_ONLY 英語・人間が書いた文章 331 63 0 Clean HUMAN_ONLY 日本語・AIっぽい文章 210 1 0 Too short UNSCORED 日本語・人間が書いた文章 164 2 0 Too short UNSCORED 英語では期待どおりに分離している。AI的な文章は80点で21件の指摘（Tier 1語彙・つなぎ語・埋め草・”Let’s”構文・em-dash）が付き、人間が書いた同じ長さの文章は0点で指摘ゼロ。この分離性能自体は本物だ。 問題は日本語である。210字の段落が wordCount = 1 と数えられ、Too short で足切りされる。 原因は「短いから」ではなく「空白が無いから」 detector/patterns.js の語数カウントは、次の1行に集約されている。 function countWords(text) { return (text.match(/\S+/g) || []).length; } \S+（空白以外の連続）を数える実装なので、単語間に空白を置かない日本語では、段落全体がまるごと1語になる。そして呼び出し側は wordCount < 10 で UNSCORED を返す。 原因を確定させるため、同じ日本語文に3種類の加工をして比べた。 加工 文字数 wordCount label 分類 無加工 210 1 Too short UNSCORED 同じ文を4回繰り返す（長さだけ4倍） 840 1 Too short UNSCORED 句読点のあとに半角スペースを入れる 224 14 Clean HUMAN_ONLY 全文字の間に半角スペースを入れる 419 210 Clean HUMAN_ONLY 長さを4倍にしても足切りは変わらない（840字でも wordCount は1のまま）。一方、半角スペースを入れた途端に語数の壁は越える。原因が文章量ではなく分かち書きの有無であることは、この2行で確定する。 そして壁を越えた先にもう1つの壁がある。空白を入れて採点対象になった日本語のAIっぽい文章は、0点・Clean・HUMAN_ONLY と判定される。 62パターンと112語の置換表はすべて英語のために書かれているので、日本語の「まさに〜と言えるでしょう」も「革新的なソリューション」も1件も引っかからない。つまり日本語に対しては、足切りされるか、通過して偽陰性になるかの二択になる。 足切りの経路。countWords() の1行が入り口を塞いでいる flowchart TD A["... --- ## screenshot to codeとは｜★7.4万のOSSを実際に動かし再現度と6分の生成時間を実測 - URL: https://ai-heartland.com/tool/screenshot-to-code-guide/ - 更新日: 2026-08-27 - カテゴリ: tool - 概要: screenshot to codeはスクリーンショットからHTML/Tailwindを生成する★7.4万のOSS。実際にバックエンドを立てて日本語UIの画面を投入し、再現度・所要時間6分・4バリアント同時実行・APIキーの組み合わせでモデルが決まる仕様までを実測で確かめる。 - タグ: vibe-coding, AIコーディング, オープンソース, フロントエンド, Tailwind screenshot to code（abi/screenshot-to-code）は、スクリーンショットを投げると画面を再現するコードを返す OSS です。star は 74,934、fork 9,166、MIT。名前のとおりの機能ですが、実際に動かすと README には書かれていない仕様がいくつも出てきます。本記事ではバックエンドをローカルに立て、日本語UIのスクリーンショットを実際に投入して、再現度・所要時間・4バリアント並列・モデルが選べない仕様までを実測しました。 左＝入力したスクリーンショット、右＝生成HTMLのレンダリング結果（2026-08-27 実測）。テキストと骨格は拾い、右カラムの目次は落ちた。 30秒でわかる screenshot to code ・スクショ→コード生成の OSS。★74,934 / MIT / FastAPI＋React。ホスト版もある ・実測：1枚から16,616文字のHTMLが出るまで359秒（約6分） ・NUM_VARIANTS = 4。1回の生成で4バリアントが並列実行されるので、コストは4回分で見積もる ・モデルは選べない。APIキーの組み合わせで決まる。存在しないモデル名を渡してもエラーにならなかった ・Anthropicキーだけでも動くが、img タグは0個。画像はCSSと絵文字による代替表現になる ・再現度は高い。日本語テキストはほぼ正確。ただし右カラムの目次は丸ごと落ちた AIにコードを書かせる流れ全体の整理はVibe Codingとは？AIコーディングの始め方・ツール比較・実践ワークフロー2026にまとめてあります。本記事はその中でも「画面から入る」タイプのツールの実測です。 screenshot to codeとは — 画面を投げるとコードが返る abi/screenshot-to-code は2023年11月公開のプロジェクトで、README の説明は「Drop in a screenshot and convert it to clean code (HTML/Tailwind/React/Vue)」です。実測時点の基本情報を整理します。 項目 実測値（2026-08-27） star / fork 74,934 / 9,166 ライセンス MIT 主要言語 Python（バックエンド）／React・Vite（フロントエンド） 公開開始 2023-11-14 最終push 2026-08-14 オープンIssue 130件 ホスト版 screenshottocode.com（公式） 構成は素直で、FastAPI のバックエンドと React/Vite のフロントエンドに分かれています。フロントは WebSocket でバックエンドの /generate-code に接続し、画像と設定を投げて生成結果を受け取ります。本記事では UI を介さず、この WebSocket を直接叩いて計測しました。 生成の流れを1本にすると、どこでコストが4倍になるかが見えます。 sequenceDiagram participant U as "ブラウザ / クライアント" participant B as "FastAPI バックエンド" participant K as "キー構成の判定" participant M as "モデル（4バリアント）" U->>B: "WebSocket /generate-code画像＋設定" B->>K: "どのキーがあるか" K-->>B: "ANTHROPIC のみ → (Opus 4.8, Sonnet 4.6)" B->>B: "NUM_VARIANTS=4 まで循環して割当" par 4本を並列実行 B->>M: "variant 1: Opus 4.8" B->>M: "variant 2: Sonnet 4.6" B->>M: "variant 3: Opus 4.8" B->>M: "variant 4: Sonnet 4.6" end M-->>B: "各バリアントのコード" B-->>U: "setCode / status" Note over B,M: "リクエストの codeGenerationModel はこの判定を上書きしない" セットアップ — Poetry が無くても動かせる README が案内するのは Poetry ですが、手元に無かったので uv で仮想環境を作って動かしました。 git clone --depth 1 https://github.com/abi/screenshot-to-code.git cd screenshot-to-code/backend uv venv --python 3.12 uv pip install --python .venv/bin/python \ fastapi uvicorn websockets "openai==2.16.0" python-dotenv beautifulsoup4 \ httpx anthropic pillow aiohttp pydantic google-genai \ playwright langfuse pillow-heif moviepy ここで1回つまずきました。 pyproject.toml の依存を上から順に入れて起動したところ、ModuleNotFoundError: No module named 'playwright' で落ちます。原因は単純で、playwright / langfuse / pillow-heif が依存リストの後半にあり、最初の抜粋に入っていなかっただけでした。playwright はプレビュー用スクリーンショット機能（preview_screenshot）が起動時に import するため、使う予定が無くても入っていないと起動自体ができません。 キーは backend/.env に置きます。 echo "ANTHROPIC_API_KEY=sk-ant-..." > backend/.env .venv/bin/python -m uvicorn main:app --port 7001 起動後、GET /api/capabilities で機能の可否を確認できます（実測では {"screenshot_preview":true} が返りました）。/capabilities ではなく /api/capabilities です——前者は 404 になります。 【実測】1枚のスクショから約6分・16,616文字 入力には日本語のブログ記事ページのスクリーンショット（1,006×1,100px・262KB）を使いました。日本語テキストが多く、カード・ピル・アイコン列など要素の種類も多い、そこそこ難しい題材です。 WebSocket に投げたパラメータの要点は次のとおりです。 { "generatedCodeConfig": "html_tailwind", "inputMode": "image", "image": "data:image/png;base64,...", "isImageGenerationEnabled": false, "isAssetExtractionEnabled": false, "generationType": "create" } 結果です。 指標 実測値 所要時間 359.3秒（約6分） 生成されたコード 16,616文字（HTMLファイルで17,746バイト） HTMLタグ総数 151 div / a / button / svg 38 / 23 / 8 / 4 img 0 日本語文字数 510 img が0個なのは、画像生成とアセット抽出を無効にしたからです（後述のとおり、そもそも該当のキーを持っていません）。画像が入るべき場所は CSS のグラデーションや絵文字で代替されました。 生成されたHTMLの冒頭はこうなっています。 <!DOCTYPE html> <html lang="ja"> <head> <meta charset="UTF-8"> <title>uv pythonの使い方2026｜install・pin・upgradeと0.12の落とし穴を実測</title> <script src="https://cdn.tailwindcss.com"></script> <link href="https://fonts.googleapis.com/css2?family=Noto+Sans+JP:..." rel="stylesheet"> lang="ja" を自分で付け、Noto Sans JP を読み込み、タイトルをスクリーンショットから正確に書き起こしています。 日本語UIを投げても崩れませんでした。 生成中、バックエンドは status メッセージ（Generating code...）と thinking メッセージを流し続けます。chunk によるストリーミングは今回0件で、最終的なコードは setCode で一括して届きました。UI 上でコードが少しずつ書かれていくように見えるかどうかは、モ... --- ## claude-seoとは｜Claude Code SEO監査25スキルを日本語サイトで実測した結果と限界 - URL: https://ai-heartland.com/tool/claude-seo-claude-code-seo-audit/ - 更新日: 2026-08-27 - カテゴリ: tool - 概要: claude-seoは25スキルと18サブエージェントでClaude Code SEO監査を回す★15,489のOSS。実際にインストールして日本語サイトへ走らせ、構造化データ検証は効く一方でコンテンツ品質スコアが日本語では機能しない理由までを実測で切り分けます。 - タグ: claude-code, SEO, オープンソース, Agent Skills Claude Code SEO というキーワードで検索すると、上位はほぼSEO代理店のブログと公式リポジトリで占められている。その中心にあるのが claude-seo ——25個のスキルと18個のサブエージェントでサイト監査を回すOSSで、2026-08-27時点で★15,489・MITライセンスだ。だが「25スキル」「並列15エージェント」という数字は、日本語のサイトに向けたときに何が本当に動くのかを何も教えてくれない。そこで実際にインストールし、当サイトの実記事に対して走らせ、言語をまたいだ対照実験までやってみた。 実機録画：まったく同じ内容の文章を英語版・日本語版で採点させた結果。英語は15点で不合格（終了コード1）、日本語は65点で合格（終了コード0）。フィラー検出とAIパターン検出がどちらも0点になっている この記事のポイント（30秒でわかる claude-seo） ・正体：Claude Code に25スキル＋18サブエージェントを足すSEO監査スキル集。MIT・★15,489・Python製 ・入れると：~/.claude/skills/ に31個のスキルディレクトリ、~/.claude/agents/ に18個のエージェント定義。実測1.3GB（うちPlaywright 569MB＋隔離venv 723MB） ・日本語で効くもの：構造化データ検出・検証、canonical/hreflang/sitemap、画像alt、リンク構造、レンダリング差分 ・日本語で効かないもの：コンテンツ品質スコア。トークナイザが [A-Za-z] 専用で、日本語本文は採点対象にすら入らない ・APIキー：無料枠は不要。53スクリプト中17本だけが外部APIを参照する Claude Code そのものの導入や設定から確認したい場合は、Claude Code｜2026年版・インストールからCLAUDE.md・Hooks・本番運用までの実装手引きを先に読むと、本記事のスキル配置の話が繋がりやすい。 claude-seoとは｜Claude Code SEO監査を25スキル＋18サブエージェントで回すOSS claude-seo は、Claude Code のスキル（Agent Skills）とサブエージェントとして動くSEO監査パッケージだ。テクニカルSEOからGEOまでを1つの束で扱う点が売りになっている。作者は AgriciDaniel 氏で、同じ作者は Obsidian 向けの claude-obsidian も公開している（当サイトでも2026-08-24に取り上げた）。「1つのCLIツール」ではなく、Markdownで書かれた手順書の束＋それを支えるPythonスクリプト群という構成である点が、従来のSEOツールと最も違う。 リポジトリの実数を数えると、READMEの主張と一致した。 READMEの主張 vs 実数（2026-08-27・ls で計測） ・skills/ 配下のディレクトリ＝25（READMEの「25 sub-skills」と一致） ・agents/ 配下の .md＝18（READMEの「18 specialist agents」と一致） ・scripts/ 配下の .py＝53（うち17本がAPIキー・認証情報を参照） ・テスト＝441件収集・440件成功・1件失敗（失敗はGitHub APIのレート制限によるネットワーク起因） リポジトリを ls と pytest で数えた実数。READMEの記載と一致したが、テストバッジの「410」だけは実数441と乖離していた 数字が合っていること自体は褒めるところではないが、この種のスキル集は「READMEの数字が実装から乖離している」ことが珍しくないので、まず一致を確認した。ただしテストバッジだけは例外で、READMEの tests 410 passing バッジは shields.io の固定文字列であり、現在の実数441とは一致していない。これはCIから生成されるバッジではないので、更新漏れが起きやすい箇所だ。 スキルはコマンドではなく「手順書」 25スキルの中身を開くと、実行ファイルはほぼ入っていない。たとえば GEO（AI検索最適化）を担当する seo-geo の中身は SKILL.md と references/ だけで、Pythonスクリプトを1本も持たない。これは欠陥ではなく設計で、判断そのものはClaudeにやらせ、決定的な計算だけをスクリプトへ逃がすという分担になっている。 この分担は後述する日本語の話に直結する。判断をLLMがやる部分は日本語でも問題なく動く。決定的な計算をPythonがやる部分は、その実装が英語前提かどうかで結果が変わる。 2つの配布版がある（片方は有料コミュニティ向け） READMEの冒頭に明記されているとおり、claude-seo には2系統ある。 版 リポジトリ 入手条件 ライセンス 公開OSS版 AgriciDaniel/claude-seo 誰でも。会員登録不要 MIT コミュニティ版 AI-Marketing-Hub/claude-seo Skool の有料コミュニティ「AI Marketing Hub Pro」会員 非公開（要org権限） 本記事が検証したのは公開OSS版のみである。コミュニティ版は「今後の機能への早期アクセス」と説明されているが、org権限がないと /plugin marketplace add が404を返すため、外から差分を検証する手段がない。オープンコアというより、OSS版が有料コミュニティへの導線を兼ねている構造だと理解しておくのが正確だ。Codex 向けの移植版 AgriciDaniel/codex-seo も別途公開されている。 インストールで何がどこに置かれるか — 実測1.3GBの内訳 インストール方法は2通りある。Claude Code 1.0.33以降のプラグイン経由と、シェルスクリプト経由だ。 # 方法1: プラグイン経由（Claude Code 内で実行） /plugin marketplace add AgriciDaniel/claude-seo /plugin install claude-seo@agricidaniel-claude-seo /seo setup # 方法2: 手動インストール（中身を読んでから実行できる） git clone --depth 1 https://github.com/AgriciDaniel/claude-seo.git bash claude-seo/install.sh READMEは Windows 版について「なぜ irm ... | iex を使わないか」をわざわざ説明している。Claude Code 自身のセキュリティガードがリモートコード直接実行をサプライチェーンリスクとして検知するため、あえて git clone してから実行させる、という理由だ。インストーラを読ませてから走らせる姿勢は評価できる。 実際に走らせて、どこに何が置かれたかを数えた 自分の ~/.claude を汚さないため、HOME を差し替えたサンドボックスで実行した。結果、終了コード0で完了し、以下が生成された。 サンドボックスHOMEでの実測。容量の99%以上はPythonランタイムとブラウザで、スキル本体は1MB程度しかない インストール前に知っておくべき3点（すべて実測） 1. スキルディレクトリは25個ではなく31個できる。 リポジトリの skills/ は25個だが、インストーラは extensions/ 配下の連携スキル6個（seo-ahrefs / seo-bing / seo-firecrawl / seo-profound / seo-seranking / seo-unlighthouse）も同時に配置する。READMEの「25」はリポジトリ内の数であって、インストール後の数ではない。 2. サブエージェント18個は ~/.claude/agents/ に置かれる＝全プロジェクト共通。 プロジェクト単位ではなくユーザー単位のディレクトリなので、SEOと無関係なリポジトリで Claude Code を起動しても18個のエージェント定義が読み込み対象に入る。 3. 合計1.3GB・28,630ファイル。 内訳は隔離venvが723MB、Playwrightの Chromium が569MB。ただしChromiumはスキルディレクトリの中に閉じ込められている（skills/seo/ms-playwright/）ので、システム共通の Playwright キャッシュを汚さない点は良い設計だ。 インストール状態は doctor で確認できる。手元では以下が返った。 $ "$HOME/.claude/skills/seo/bin/claude-seo" doctor Runtime: ready Install mode: manual Python: 3.14 Chromium: ready なお install.sh が既定で取得するのは main ではなくタグ v2.2.5 である（CLAUDE_SEO_TAG=main で上書き可能）。開発版ではなくリリース版が入る設計なので、README の記述と手元の挙動がずれた場合はまずこのタグ差を疑うとよい。 日本語サイトで走らせた：対照実験で分かった「静かな合格」 ここからが本題だ。当サイトの実記事1本（日... --- ## Agent Teamsとは｜Claude Codeを複数走らせる設定と権限・実体を実機確認 - URL: https://ai-heartland.com/explain/claude-code-agent-teams-guide/ - 更新日: 2026-08-27 - カテゴリ: explain - 概要: Claude CodeのAgent Teamsは複数セッションをチームとして走らせる実験的機能。CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMSでの有効化、サブエージェントとの違い、mailboxとtask listの実体、teammateが権限を回避できない設計までを実機で確認する。 - タグ: claude-code, AIエージェント並列, 開発環境, 自動化, 実験的機能 Agent Teams は、複数の Claude Code セッションを「チーム」として同時に走らせる実験的機能です。サブエージェントと違い、teammate 同士が直接メッセージを送り合い、共有タスクリストから自分で仕事を取ります。本記事では有効化の方法、サブエージェントとの使い分け、そして mailbox・タスクリストの実体と権限モデルを、手元の Claude Code v2.1.241 で確認しながら整理します。既定では無効で、有効にすると通常の委譲の挙動まで変わる点が最大の注意点です。 調整の仕方が違う。サブエージェントは「親が管理」、Agent Teams は「自己調整」。 30秒でわかる Agent Teams ・既定で無効。CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 で有効化（v2.1.241 のバイナリに9箇所出現を確認） ・対話セッション専用。-p の非対話モードと Agent SDK では teammate は生成されない ・有効にすると通常の委譲も変わる。「名前つきサブエージェント」が自動で teammate になり、頼んでいなくてもチームが組まれる ・実体はファイルベース。mailbox は ~/.claude/teams/{team}/inboxes/{agent}.json、タスクは ~/.claude/tasks/{team}/ ・teammate は権限を回避できない。拒否された操作を別の teammate に中継させることもできない ・トークンコストは高い。teammate ごとに別の Claude インスタンスが立つ Claude Code 本体の設定はClaude Code｜2026年版・インストールからCLAUDE.md・Hooks・本番運用までの実装手引きにまとめています。本記事はその上で「並列に走らせる」話です。 Agent Teamsとは — 自己調整するチーム Agent Teams は、リーダーとなるメインセッションが teammate（別の Claude Code インスタンス）を起動し、共有タスクリストとメールボックスで協調させる仕組みです。 構成要素は4つです。 要素 役割 Team lead teammate を起動し作業を調整するメインセッション Teammates 割り当てられたタスクを処理する独立した Claude Code インスタンス Task list teammate が自分で取りにいく共有の作業リスト Mailbox エージェント間の通信 公式が挙げる「効く」ケースは、並列に探索することに実際の価値があるタスクです。 ・調査とレビュー：複数の teammate が別々の観点を同時に調べ、互いの結論をぶつける ・新規モジュール／機能：teammate がそれぞれ別の部分を担当し、衝突しない ・仮説が競合するデバッグ：異なる仮説を並列に検証して収束を早める ・レイヤー横断の調整：フロント・バック・テストをそれぞれ別の teammate が持つ 逆に公式は、はっきりこう釘を刺しています。 Agent teams add coordination overhead and use significantly more tokens than a single session. … For sequential tasks, same-file edits, or work with many dependencies, a single session or subagents are more effective. 逐次処理・同一ファイルの編集・依存関係の多い作業には向きません。 表示モードと操作 リーダーのターミナルでは、プロンプト入力欄の下のエージェントパネルに teammate が並びます。上下キーで選択、Enter でその teammate のトランスクリプトを開いて直接メッセージ、Escape で現在のターンを中断、という操作です。teammate ごとに分割ペインを割り当てる表示モードも用意されています。 パネルの挙動には版差があります。v2.1.199 以降は、他の teammate かサブエージェントがまだ動いている間、アイドルになった teammate の行もパネルに残ります（選択してトランスクリプトを読んだり追加の仕事を渡したりできる）。全員がアイドルになると30秒後に行が隠れ、次のターンで再表示されます——隠れている間も teammate は動き続けており、宛先としては有効です。v2.1.181〜v2.1.198 では、他が動いていてもアイドルになった行は自身のターン終了30秒後に隠れていました。v2.1.181 より前はそもそも隠れません。 4人以上がアイドルになると、先頭3行を超えた分は 2 idle agents のような1行にまとまります。 サブエージェントとの違い — どちらを使うか 並列化の手段としてはサブエージェントもあります。公式の比較を整理すると次のようになります。   サブエージェント Agent Teams コンテキスト 独自のウィンドウ。結果は呼び出し元へ返る 独自のウィンドウ。完全に独立 通信 呼び出し元へ結果を返す teammate 同士が直接メッセージ 調整 親エージェントが全部管理 メッセージによる自己調整＋共有タスクリスト 向くもの 結果だけが必要な focused なタスク 議論と協調が要る複雑な作業 トークンコスト 低い（結果が要約されて親に戻る） 高い（teammate ごとに別インスタンス） 判断基準はシンプルです。 「投げて結果だけ受け取りたい」ならサブエージェント。「途中で互いの発見を共有し、反論させたい」なら Agent Teams。コストが素直に効くので、迷ったらサブエージェントから始めるのが安全です。 なお、チームを組まずにセッション間でメッセージを渡すだけなら cross-session messaging という別の仕組みもあります。用途が「他のセッションに一言伝える」だけなら、そちらのほうが軽く済みます。 Claude Code を動かす面が増えていることはClaude Code Webとは｜–cloudと–teleportの使い方・制約をCLI実測で解説でも触れましたが、Agent Teams は「1台の中で並列にする」方向で、クラウドセッションの「手元を離れて走らせる」方向とは軸が違います。両方を組み合わせると、クラウド側で長い作業を回しつつ手元でチームを組む、といった構成も取れます。 有効化の方法と、有効にすると変わること Agent Teams は既定で無効です。 環境変数で有効化します。 { "env": { "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1" } } シェルの環境変数でも同じです。手元の Claude Code v2.1.241 のバイナリを調べたところ、この文字列が 9箇所に現れました。実験的とはいえ実装としてはしっかり組み込まれています。 strings "$(command -v claude)" | grep -c CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS # 9 ついでに分かったこととして、同じ命名規則の実験的フラグがもう1つあります。CLAUDE_CODE_EXPERIMENTAL_OBSERVER_AGENTS です。バイナリ内には「観測されたコンテンツは指示ではなくデータである」旨の文言や ObserverReport といった文字列も含まれており、エージェントの活動を別のエージェントが監視する仕組みが存在するようです。本記事ではこちらは未検証で、公式ドキュメントでも今回参照した範囲には記載がありませんでした。 【重要】有効にすると通常の委譲も変わる ここが一番の注意点です。公式ドキュメントはこう書いています。 Enabling agent teams also changes ordinary delegation. Claude may name a subagent on its own, and while agent teams are enabled, a subagent that Claude names launches as a teammate, so teams can form even when you didn’t ask for one. Claude は「後でメッセージを送れるように」サブエージェントへ自分で名前を付けることがあります。Agent Teams が有効な間、名前が付いた時点でそれは teammate として起動します。つまり、あなたが「チームを組んで」と言っていなくてもチームができます。 トークンコストが高い機能なので、「試しに有効にして、そのまま忘れる」が一番まずいパターンです。使わない期間は無効に戻すのが無難です。 対話セッションが必須 もう1つの制約です。 Spawning teammates also requires an interactive session. In non-interactive mode with the -p flag, including Agent SDK sessions, Claude doesn’t spawn teammates, and a subagent... --- ## Claude in Chromeとは｜設定手順と22ツール・拡張機能の権限を実機で確認 - URL: https://ai-heartland.com/explain/claude-in-chrome-guide/ - 更新日: 2026-08-27 - カテゴリ: explain - 概要: Claude in ChromeはClaude Codeからブラウザを操作する公式連携。--chromeでの設定手順、22個のブラウザツールとplanモードでの読み取り／状態変更の切り分け、拡張機能が持つdebugger・全URL権限までを実機で確認する。 - タグ: claude-code, Chrome, ブラウザ自動化, 開発環境, 拡張機能 Claude in Chrome は、Claude Code からあなたの Chrome を操作させる公式連携です。2026年6月〜7月の Week 27（v2.1.198）で一般提供（GA）になりました。ログイン済みのブラウザをそのまま使えるので、API連携なしで Google Docs や社内アプリを触れます。本記事では --chrome での設定手順と、22個のブラウザツールが plan モードでどう切り分けられるか、そして拡張機能が manifest 上で何を要求しているかを、手元の Claude Code v2.1.241 と拡張機能 v1.0.85 で確認しながら整理します。 接続は3層。CLI ↔ native messaging ホスト ↔ 拡張機能。どこか1つ欠けると「拡張機能が検出されない」になる。 sequenceDiagram participant C as "Claude Code CLI" participant N as "native messaging ホスト（claude --chrome-native-host）" participant E as "Claude 拡張機能 v1.0.85" participant T as "Chrome のタブ" C->>N: "stdio で接続" N->>E: "native messaging" E->>T: "debugger / scripting 権限で操作" T-->>E: "DOM・コンソール・ネットワーク" E-->>N: "結果" N-->>C: "ツールの戻り値" Note over C,E: "3層のどこか1つ欠けると「拡張機能が検出されない」になる" 30秒でわかる Claude in Chrome ・Claude Code からログイン済みのChromeを操作する公式連携。Week 27（v2.1.198）でGA ・起動は claude --chrome、状態確認は /chrome（手元の v2.1.241 に --chrome / --no-chrome の存在を確認） ・APIキー認証では使えない。/login での claude.ai サインインが必須。Bedrock / Vertex / Foundry 経由も対象外 ・ブラウザツールは22個。plan モードでは読み取り専用と状態変更で承認の要否が分かれる ・拡張機能は debugger と <all_urls> を要求（manifest v1.0.85 を実読）。CDPへのアクセスを含む ・「インストール済み」と「接続済み」は別物。実機では両方揃っていても未接続だった Claude Code 本体の設定はClaude Code｜2026年版・インストールからCLAUDE.md・Hooks・本番運用までの実装手引きにまとめてあります。本記事はそこにブラウザを繋ぐ話です。 Claude in Chromeとは — ログイン状態ごとAIに渡す連携 Claude in Chrome は、Claude Code が Chrome 拡張機能を通じてブラウザを直接操作する仕組みです。GA時のリリースノートはこう説明しています。 Claude Code drives your browser through the Claude in Chrome extension: it opens tabs, clicks through pages, fills forms, reads console logs, and shares your login state, so it can test the app it builds without you switching contexts. “shares your login state” が肝です。API連携やOAuthを設定しなくても、あなたがすでにログインしている Google Docs・Gmail・Notion・社内管理画面をそのまま触れます。裏を返せば、ブラウザで見えるものはClaudeにも見えるということでもあります。 Claude Code を動かす「面」は増えていて、ブラウザはそのひとつです。クラウドVM側で走らせる話はClaude Code Webとは｜–cloudと–teleportの使い方・制約をCLI実測で解説にまとめてあり、あちらが「手元を離れて実行する」方向なのに対し、Chrome連携は「手元のログイン状態を使う」方向です。用途がはっきり分かれます。 公式が挙げるユースケースは8つです。 用途 内容 ライブデバッグ コンソールエラーとDOM状態を読み、原因のコードを直す デザイン検証 Figmaのモックから作ったUIをブラウザで開いて突き合わせる Webアプリのテスト フォーム検証・視覚的リグレッション・ユーザーフローの確認 認証つきWebアプリ ログイン済みのGoogle Docs・Gmail・Notionをコネクタなしで操作 データ抽出 ページから構造化情報を取り出してローカルに保存 タスク自動化 データ入力・フォーム記入・複数サイトにまたがる作業 ファイルアップロード ローカルのファイルをWebのアップロード欄に添付 セッション記録 ブラウザ操作をGIFとして記録し、共有する 前提条件 — APIキー認証では動かない 必要なものは4つです。 ・Chromium系ブラウザ（Chrome / Edge / Brave / Arc / Vivaldi / Opera） ・Claude 拡張機能 1.0.36 以降（Chrome ウェブストア） ・Claude Code ・Anthropic 直契約のプラン（Pro / Max / Team / Enterprise） 見落としやすいのが認証方式の制約です。公式ドキュメントは明確に書いています。 Chrome integration also requires signing in with /login. If you authenticate with an API key or a long-lived token from claude setup-token, Claude Code keeps Chrome integration off, even when you pass --chrome. APIキー認証や claude setup-token の長期トークンでは、--chrome を渡してもオフのままです。しかも過去には挙動が違いました——v2.1.216 より前は、これらのセッションでもChrome連携を有効化でき、ただし接続のたびに403で失敗していた、と公式が明記しています。つまり「有効になっているのに繋がらない」という紛らわしい状態が存在した版があります。手元が古い場合はまずアップデートしてください。 Amazon Bedrock・Google Cloud・Microsoft Foundry 経由でのみ Claude を使っている場合も対象外で、別途 claude.ai アカウントが必要です。 設定手順 — --chrome と /chrome 手元の Claude Code v2.1.241 で --help を確認すると、専用のフラグが2つあります。 claude --version # 2.1.241 (Claude Code) claude --help | grep -i chrome # --chrome Enable Claude in Chrome integration # --no-chrome Disable Claude in Chrome integration 起動はこれだけです。 claude --chrome 初回は連携とサイト権限を説明する一度きりのダイアログが出ます。以降のセッションでフラグを省きたい場合は /chrome から「Enabled by default」を選びます。 接続状態の確認も /chrome です。「Status: Enabled」かつ「Extension: Installed」の両方が表示されていれば動いています。複数のブラウザが接続されている場合は /chrome の「Select browser…」で選べます（v2.1.154 以降が必要）。 常時有効にするとコンテキストを食う 公式は「CLIでChromeを既定で有効にするとブラウザツールが常に読み込まれるためコンテキスト使用量が増える」と注記し、気になる場合は既定オフに戻して必要なときだけ --chrome を使うよう案内しています。具体的なトークン数は公表されておらず、本記事でも計測していません（未検証）。22ツール分の定義が常駐する規模、と捉えてください。 【実機確認】「インストール済み」と「接続済み」は別物 ここが実際に触ってみて一番はっきりした点です。手元の環境を順に確認しました。 ① 拡張機能はインストールされている。 Chromeのプロファイル配下に実体がありました。 ls ~/Library/Application\ Support/Google/Chrome/*/Extensions/fcoeoabgfenejglbffodgkkbkcdhcgfn # 1.0.85_0 バージョンは 1.0.85。公式要件の 1.0.36... --- ## uv pythonの使い方2026｜install・pin・upgradeと0.12の落とし穴を実測 - URL: https://ai-heartland.com/tool/uv-python-version-management-guide/ - 更新日: 2026-08-27 - カテゴリ: tool - 概要: uv pythonでPythonのバージョンを管理する使い方を実測で解説。install・list・find・pin・upgradeの役割分担と、0.12で--reinstallの意味が変わった件・古いPyPyが消えた件を0.11.9と0.12.6のA/B実測で確かめる。 - タグ: python, uv, 開発環境, オープンソース, automation uv python は、Rust製のPythonパッケージマネージャ uv が持つ「Python本体のバージョン管理」機能です。pyenv でやっていたことを uv 1つに寄せられます。本記事では install / list / find / pin / upgrade の役割分担を実測で整理し、あわせて uv 0.12 で uv python の挙動が変わった2点を、0.11.9 と 0.12.6 を並べて動かしたA/Bで確かめます。フラグの一覧は両バージョンで完全に同一なので、コマンドを見ても気づけない種類の変化です。 同じコマンド・同じ状態でのA/B実測（2026-08-27）。0.12 で `--reinstall` は「最新へ上げる」を意味しなくなった。 30秒でわかる uv python ・uv python install はPython本体を入れるコマンド。uv venv（仮想環境）や uv run（実行）とは役割が別 ・プリビルト取得なのでビルドしない。実測で 3.12.13 が 23.8MiB ダウンロード＋1秒未満で導入完了 ・【0.12の落とし穴①】--reinstall が最新へ上げなくなった。実測: 0.11.9 は 3.12.13 を新規取得、0.12.6 は既存の 3.12.8/3.12.9 を再インストールするだけ。上げたいなら --upgrade ・【0.12の落とし穴②】bzip2配布の古いPyPyが消えた。実測: uv python list 3.10 --all-versions の PyPy が 4件→1件 ・フラグ一覧は 0.11.9 と 0.12.6 で完全一致。--help の差分はゼロで、変わったのは挙動だけ 開発まわりの自動化ツール全体の見取り図はAI自動化ツール｜ノーコードからコードまで2026年版の比較と選び方にまとめてあります。本記事はそのうちPython環境の足回りの話です。 uv python とは — Pythonのバージョン管理をuvに寄せる uv（astral-sh/uv・★89,140・Apache-2.0）は Rust 製のPythonパッケージマネージャですが、パッケージだけでなくPythonインタプリタそのものも管理します。それが uv python サブコマンド群です。 実測時点（2026-08-27）で uv python --help が並べるサブコマンドは8つです。 サブコマンド 役割 install Pythonをダウンロードして導入する list 利用可能／導入済みのPythonを一覧する find 条件に合うPythonのパスを探す pin プロジェクトのバージョンを .python-version に固定する upgrade 導入済みPythonをアップグレードする uninstall 導入済みPythonを削除する dir uvがPythonを置くディレクトリを表示する update-shell Python実行ファイルのディレクトリを PATH に通す pyenv との最大の違いはビルドしないことです。uv は python-build-standalone のプリビルトバイナリを取得します。実測では 3.12.13 の取得が 23.8MiB のダウンロードで、インストール自体は 985ms で完了しました。pyenv がソースビルドに数分かけるのと比べると体感が違います。 一方で、--enable-optimizations のようなビルドオプションを自分で指定したい用途は uv の守備範囲外です。そこは pyenv や自前ビルドが引き続き必要になります。 uv と同じく「Rust で書き直して速くする」系の Python ツールとしては Polars入門：pandasの10倍速でデータ処理できるRust製DataFrameライブラリ があり、データ処理側で同じ流れが起きています。 uv python install — Pythonを入れる もっとも基本のコマンドです。バージョンは複数まとめて渡せます。 # 単一バージョン uv python install 3.12 # 複数まとめて uv python install 3.12.8 3.12.9 実測では2バージョンの導入が 965ms で終わりました。 Installed 2 versions in 965ms + cpython-3.12.8-macos-aarch64-none + cpython-3.12.9-macos-aarch64-none (python3.12) 導入先を変えたい場合は --install-dir、環境変数なら UV_PYTHON_INSTALL_DIR を使います。CIやコンテナで置き場所を固定したいときに便利です。 UV_PYTHON_INSTALL_DIR=/opt/pythons uv python install 3.12 導入されたPythonは uv の管理ディレクトリに置かれ、システムのPythonには触れません。uv python dir でその場所を確認できます。システムのPythonを壊さないのは、pyenv の shim 方式と比べたときの安心材料です。 uv python install を明示的に叩く場面は意外と少ない 日常的には uv run が自動で面倒を見ます。プロジェクトの .python-version や pyproject.toml の requires-python を見て適切なインタプリタを選び、無ければダウンロードまでします。 uv python install を明示的に使うのは、次のような場面です。 ・CIで先にバージョンを確定させたい（ビルドステップとテストステップを分けたい） ・オフライン／制限環境の事前準備として、必要なPythonを先に落としておきたい ・複数パッチを同時に持ちたい（互換性検証など） uv run に任せる場合の流れを図にすると、uv python の各サブコマンドがどこで効くかが分かります。 flowchart TD A["uv run スクリプト実行"] --> B{".python-versionまたは requires-python は？"} B -->|"あり"| C{"その版は導入済みか？"} B -->|"なし"| D["システム/既定のPythonを選ぶ"] C -->|"はい"| E["そのインタプリタを使う"] C -->|"いいえ"| F["自動ダウンロードして使う"] G["uv python pin"] -.->|".python-version を書く"| B H["uv python install"] -.->|"事前に用意しておく"| C I["uv python upgrade"] -.->|"最新パッチへ上げる"| C 点線が「人が明示的に打つコマンド」です。実線の流れは uv run が勝手にやってくれる部分で、だからこそ uv python install を直接叩く機会は限られます。 uv python list / find / dir — いま何が入っているかを見る list は「入っているもの」と「入れられるもの」を両方出します。導入済みだけに絞るなら --only-installed です。 # 3.12系で入手可能なパッチを全部見る uv python list 3.12 --all-versions # 導入済みだけ uv python list --only-installed # uvが管理するPythonの置き場所 uv python dir list の出力は、システムのPython（Homebrew等）と uv 管理のものが混在して表示される点に注意してください。実測でも Homebrew の python3.12 と uv が入れた 3.12.9 が並んで出ました。どちらを指しているかはパスで見分けます。 cpython-3.12.9-macos-aarch64-none /opt/homebrew/bin/python3.12 -> ... cpython-3.12.9-macos-aarch64-none /tmp/uv12/pythons/cpython-3.12-.../bin/python3.12 find は「条件に合うインタプリタの実体パス」を1つ返します。スクリプトから使いやすい形です。 uv python find 3.12 # => /path/to/pythons/cpython-3.12-macos-aarch64-none/bin/python3.12 uv python pin — プロジェクトごとにバージョンを固定する pin は .python-version を書くだけの単純なコマンドですが、これが uv run の挙動を決めます。 uv python pin 3.12 # => Pinned `.python-version` to `3.12` 実測すると .python-version の中身はそのまま 3.12 の1行でした。パッチまで固定したいなら uv python pin 3.12.9 のように書きます。 チームで揃えたいなら .python-version をコミットします。 pyenv と同じファ... --- # 直近のニュース速報（直近20本、要約のみ） # トピッククラスタ一覧 - **Claude Code** (claude-code): Claude Codeの使い方・設定・内部アーキテクチャ・拡張エコシステムを網羅。Harness Engineering・AI MDファイル・Claude Designも含む — https://ai-heartland.com/topics/claude-code/ - **AIエージェント** (ai-agent): AIエージェントの作り方、フレームワーク比較、マルチエージェント設計 — https://ai-heartland.com/topics/ai-agent/ - **AIコーディング / Vibe Coding** (ai-coding): Vibe Codingからエージェンティック開発まで、AIコーディングの最前線 — https://ai-heartland.com/topics/ai-coding/ - **MCP（Model Context Protocol）** (mcp): MCPサーバーの作り方、活用事例、A2Aプロトコルとの比較 — https://ai-heartland.com/topics/mcp/ - **RAG & ナレッジシステム** (rag): RAGの仕組み、構築方法、ベクトルデータベース比較 — https://ai-heartland.com/topics/rag/ - **LLM / ローカルAI** (llm): LLMの仕組み、ローカル実行、モデル比較、最適化 — https://ai-heartland.com/topics/llm/ - **セキュリティ** (security): サプライチェーン攻撃、CVE分析、APIキー管理、セキュリティツール — https://ai-heartland.com/topics/security/ - **DevOps & 自動化** (devops): データパイプライン、コンテナ管理、Web自動化、CI/CD — https://ai-heartland.com/topics/devops/ - **Claude API & 料金** (claude-api): Claude API全モデルの料金比較、コスト最適化、プラン選定ガイド — https://ai-heartland.com/topics/claude-api/ - **UI生成 & デザインシステム** (ui-design): デザインシステムの構築、DESIGN.md、AIによるUI生成ツール — https://ai-heartland.com/topics/ui-design/ - **ドキュメント/ナレッジ** (docs-knowledge): コード/データ/PDF/Webから知識・図表・ドキュメントを生成・抽出・構造化するOSS。ナレッジグラフ・RAG用知識ベース構築・コードベース図解まで — https://ai-heartland.com/topics/docs-knowledge/ # 連絡先 X (Twitter): https://x.com/peaks2314