開発ツール on KnightLiブログ

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

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

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

プロジェクトURL：safishamsi/graphify

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

解決する中核問題

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

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

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

最小構成での使い方

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

`1`	`/graphify .`

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

`1`	`graphify .`

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

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

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

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

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

`1`	`graphify export callflow-html`

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

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

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

`1`	`uv tool install graphifyy`

代替方法もあります。

1
2

pipx install graphifyy
pip install graphifyy

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

`1`	`graphify install`

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

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

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

`1`	`multi_agent = true`

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

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

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

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

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

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

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

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

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

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

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

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

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

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

よく使うコマンド

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

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

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

1
2

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

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

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

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

MCP、Neo4j、CIとの関係

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

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

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

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

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

1
2

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

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

`1`	`graphify hook install`

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

プライバシーとコスト

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

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

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

ANTHROPIC_API_KEY
GEMINI_API_KEY
GOOGLE_API_KEY
OPENAI_API_KEY
DEEPSEEK_API_KEY
MOONSHOT_API_KEY
OLLAMA_BASE_URL

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

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

向いている場面

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

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

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

まとめ

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

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

参考：

GitHub：safishamsi/graphify

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

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

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

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

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

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

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

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

たとえば：

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

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

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

統一 Provider アーキテクチャ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

UI 統合

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

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

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

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

Skill for Coding Agents

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

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

`1`	`npx skills add vercel/ai`

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

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

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

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

向いているプロジェクト

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

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

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

向いていない場面

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

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

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

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

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

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

使うときの注意点

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

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

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

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

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

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

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

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

まとめ

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

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

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

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

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

参考資料

Bun：JavaScript ランタイム、パッケージ管理、テスト、バンドルを一つにまとめる

Sun, 17 May 2026 17:42:25 +0800

Bun は oven-sh が開発する JavaScript / TypeScript の統合ツールチェーンです。

単に速い Node.js 代替を目指しているだけではありません。ランタイム、パッケージマネージャー、スクリプト実行、テストランナー、バンドラーを同じ bun コマンドにまとめます。フロントエンドや Node.js 開発者にとっての魅力は、ツールを減らし、インストールやビルドの待ち時間を減らし、多くの作業を一つのコマンドで済ませられることです。

プロジェクト：https://github.com/oven-sh/bun

まず結論

Bun は JavaScript ツールチェーンを簡素化したい人に向いています。

できることは次の通りです。

JavaScript、TypeScript、JSX、TSX を実行する。
Node.js 互換ランタイムとして使う。
npm / yarn / pnpm の代わりにパッケージ管理を行う。
package.json の scripts を実行する。
テストを実行する。
フロントエンドまたはバックエンドのコードをバンドルする。
bunx で npm パッケージ内のコマンドを実行する。
Bun.serve、bun:sqlite、Bun.sql、Bun.redis、Bun.s3 などの組み込み API を提供する。

最大の価値は開発体験です。依存関係のインストールが速く、起動も速く、コマンドが統一され、TypeScript と JSX がそのまま使えます。

ただし、すべてのプロジェクトがすぐに Bun へ切り替えるべきではありません。大規模 Node.js プロジェクト、ネイティブ拡張に強く依存するプロジェクト、安定性要求が高い本番サービスでは、互換性、ビルド、テスト、デプロイ方式を一つずつ検証する必要があります。

Bun とは

公式 README によると、Bun は JavaScript と TypeScript アプリケーション向けの統合ツールキットです。単一の実行ファイル bun として配布されます。

中心は Bun runtime です。これは Node.js の drop-in replacement を目指す高速 JavaScript ランタイムです。Bun は Zig で書かれ、JavaScriptCore をベースにし、起動時間とメモリ使用量を重視して最適化されています。

つまり、次のように直接実行できます。

`1`	`bun run index.tsx`

TypeScript と JSX は追加設定なしで動きます。

同じ bun コマンドには、test runner、script runner、Node.js 互換パッケージマネージャー、bundler、package runner も含まれます。

よく使うコマンドは次の通りです。

bun test
bun run start
bun install <pkg>
bunx cowsay 'Hello, world!'

従来は node、npm、pnpm、tsx、jest、vitest、webpack、esbuild、ts-node などが同じプロジェクトに並びがちでした。Bun は高頻度の作業を一つのツールにまとめようとしています。

インストール方法

Bun は Linux、macOS、Windows をサポートし、x64 と arm64 に対応しています。

公式の推奨インストールスクリプト：

`1`	`curl -fsSL https://bun.com/install \| bash`

Windows：

`1`	`powershell -c "irm bun.sh/install.ps1 \| iex"`

npm からもインストールできます。

`1`	`npm install -g bun`

macOS Homebrew：

1
2

brew tap oven-sh/bun
brew install bun

Docker：

1
2

docker pull oven/bun
docker run --rm --init --ulimit memlock=-1:-1 oven/bun

Linux ではカーネルバージョンに注意が必要です。README では Linux kernel 5.6 以上を強く推奨し、最低要件は 5.1 とされています。

なぜ Bun は速いのか

Bun の速さはいくつかの層から来ています。

第一に、ランタイムの起動が速いことです。多くの CLI ツールや開発スクリプトのボトルネックは長時間の CPU 処理ではなく、プロセス起動、モジュール読み込み、TypeScript 変換、依存関係解決です。Bun はこの経路を最適化しています。

第二に、パッケージ管理が速いことです。bun install は npm / yarn / pnpm の依存関係インストールを置き換えることを目指します。グローバルキャッシュと独自の lockfile により、大量の依存関係を扱うときに待ち時間を減らせます。

第三に、TypeScript / JSX がそのまま動くことです。.ts や .tsx のスクリプトを実行するだけでも、従来の Node.js では tsx、ts-node、Babel、ビルド手順が必要になりがちでした。Bun は直接実行でき、接着剤のようなツールを減らします。

第四に、組み込みツールによりプロセスと設定の切り替えが減ります。テスト、スクリプト、バンドル、実行が同じツール内にあります。

ただし、「Bun は速い」は「どのプロジェクトでも必ず速い」という意味ではありません。実際の効果は依存関係、スクリプト、テストフレームワーク、ビルド設定、Node.js API 利用、CI キャッシュに依存します。

パッケージ管理：npm / yarn / pnpm の代替

Bun は依存関係を直接インストールできます。

`1`	`bun install`

依存関係を追加：

`1`	`bun add react`

開発依存を追加：

`1`	`bun add -d typescript`

依存関係を削除：

`1`	`bun remove react`

なぜ依存しているかを見る：

`1`	`bun why react`

セキュリティチェック：

`1`	`bun audit`

npm や pnpm から移行する場合は、bun.lock をコミットするか、CI で bun install --frozen-lockfile を使うか、private registry と .npmrc が互換か、workspace の挙動が期待通りか、lifecycle scripts が安全リスクにならないかを確認します。

小さなプロジェクトなら直接試せます。大規模 monorepo は、一つの package や非ブロッキング CI job から始める方が安全です。

スクリプトと TypeScript の実行

Bun は package.json のスクリプトを実行できます。

`1`	`bun run start`

ファイルを直接実行することもできます。

1
2

bun run index.ts
bun run index.tsx

これは scripts/build.ts、scripts/seed.ts、scripts/migrate.ts、scripts/check.ts のようなツールスクリプトに便利です。

Node.js では TypeScript loader や事前コンパイルが必要になりがちですが、Bun なら軽くできます。

ただし、loader、ESM/CJS 境界、ネイティブモジュール、child process、ファイル監視、一部のエッジ API など Node.js 固有の挙動に依存する場合はテストが必要です。

テストランナー

Bun にはテストランナーがあります。

`1`	`bun test`

Jest / Vitest の設定を減らしたい小規模プロジェクトや、一部の単体テスト、ツールテスト、ライブラリテストを軽い実行方式へ移す用途に向いています。

移行時は、expect、mock API、snapshot、DOM テスト環境、テスト探索規則、coverage 出力、CI reporter の違いを確認します。

Jest の custom matcher、複雑な mock、jsdom、babel-jest、ts-jest に深く依存している場合は急がない方がよいです。新規モジュールだけ bun test を使い、既存テストは元のフレームワークに残せます。

バンドルとビルド

Bun には bundler もあります。

`1`	`bun build ./src/index.ts --outdir ./dist`

フロントエンド、バックエンドスクリプト、CLI、ライブラリのビルドに使えます。Bun のドキュメントは loaders、plugins、macros、CSS、HTML、HMR、minifier、single-file executable も扱います。

優先して試しやすいのは、小さなフロントエンドツール、Node.js CLI、内部スクリプト、単一ファイルサービス、複雑な webpack loader に依存しないプロジェクトです。

慎重に進めるべきなのは、複雑な webpack plugin chain、大量の Vite plugin、深い Babel 変換、特殊な CSS / asset pipeline、micro frontend、module federation、hash や chunk や互換性に厳しいプロジェクトです。

Bun bundler は魅力的ですが、ビルドツール移行のリスクはパッケージ管理より高いことが多いので、単独で検証した方がよいです。

HTTP サービスの実行

Bun は Bun.serve を提供します。

Bun.serve({
  port: 3000,
  fetch(req) {
    return new Response("Hello from Bun")
  },
})

小さな API、内部サービス、Webhook receiver、エッジ風サービスには便利です。WebSockets、Workers、Streams、SQLite、PostgreSQL、Redis、S3、TCP/UDP sockets などの API もあります。

すでに Express、Fastify、NestJS、Next.js、Hono、Elysia などを使っているなら、まず Bun 上での互換性を確認すれば十分です。Bun を使うためだけにサービスを書き直す必要はありません。

現実的な順序は、開発スクリプトとパッケージ管理、次にテスト、最後に本番ランタイム移行の評価です。本番挙動に直接影響するため、ランタイム移行が最も慎重に扱うべき部分です。

Node.js との関係

Bun の目標の一つは Node.js の drop-in replacement ですが、「互換」は「完全に同一」ではありません。

Node.js エコシステムには、CJS / ESM 相互運用、組み込みモジュール、ネイティブ拡張、npm lifecycle scripts、ファイルシステムの細かな挙動、stream と Buffer、worker / child_process、デバッグや profiling など、多くの細部があります。

Bun の互換性は速く改善していますが、本番移行はテスト結果を基準にすべきです。

確認すべきことは、テストが Bun で通るか、重要な依存関係が Bun をサポートするか、ビルド成果物が一致するか、CI とローカルの挙動が一致するか、本番に監視と rollback があるか、Docker イメージとデプロイスクリプトが安定しているかです。

パッケージマネージャーだけを置き換えるリスクは低めです。本番ランタイムを置き換えるリスクはかなり高くなります。

向いているプロジェクト

Bun は、新しい小規模 JavaScript / TypeScript プロジェクト、内部ツール、CLI、依存関係インストールを速くしたい CI、ツールチェーンを減らしたいフロントエンド、起動速度が重要なスクリプトやサービス、TypeScript をすぐ動かしたい開発者に向いています。

一方で、巨大 monorepo、pnpm workspace の挙動に深く依存するプロジェクト、多数の Node.js ネイティブ拡張を使うサービス、高度にカスタムされたフロントエンドビルド、本番ランタイムの一致性が極めて重要なバックエンド、Jest に深く依存するテストスイートでは慎重に進めるべきです。

保守的ですが実用的な方針は、まず Bun を開発ツールとして使うことです。いきなり全ての本番ランタイムを置き換える必要はありません。

移行のすすめ方

既存プロジェクトで Bun を試すなら、次の順序がよいです。

ローカルに Bun をインストールする。
bun install を実行し、依存関係の結果を見る。
bun.lock をコミットまたは一時保持し、既存 lockfile との混乱を避ける。
よく使うスクリプトを bun run <script> で試す。
少数のテストを bun test に移す。
CI に非ブロッキングの Bun job を追加する。
互換性に問題がなければ、主なインストールフローの置き換えを検討する。
本番ランタイム移行は最後に評価する。

チームプロジェクトでは rollback 経路を残すべきです。旧 npm / pnpm / yarn フローを保持し、CI でしばらく並走させ、ランタイム、パッケージマネージャー、テストフレームワーク、バンドラーを同時に変えないことが大切です。

よく使うコマンド

インストール：

`1`	`curl -fsSL https://bun.com/install \| bash`

アップグレード：

`1`	`bun upgrade`

依存関係のインストール：

`1`	`bun install`

依存関係の追加：

`1`	`bun add lodash`

スクリプト実行：

`1`	`bun run dev`

TypeScript を直接実行：

`1`	`bun run scripts/build.ts`

テスト：

`1`	`bun test`

バンドル：

`1`	`bun build ./src/index.ts --outdir ./dist`

パッケージコマンドを実行：

`1`	`bunx cowsay 'Hello, world!'`

まとめ

Bun の価値は「Node.js より速い」だけではありません。JavaScript / TypeScript 開発に散らばるランタイム、パッケージマネージャー、スクリプト実行、テスト、バンドルを一つの bun コマンドへまとめる点が重要です。

新規プロジェクトや内部ツールでは、速いインストール、速い起動、少ない設定、TypeScript / JSX の直接実行が快適です。既存の大規模プロジェクトでは、パッケージインストール、スクリプト、一部テストなど低リスクな部分から入り、ビルドとランタイムを段階的に検証する方が安全です。

Node.js ツールチェーンのインストール速度、設定の断片化、テスト起動時間に悩まされているなら、Bun は試す価値があります。ただし本番移行では、テスト、依存関係、CI、rollback という基本的な工学判断に戻るべきです。

参考リンク：

Godot ゲーム開発入門：ノード、シーン、最初の 2D ミニゲームまで

Sun, 17 May 2026 12:37:30 +0800

Godot はオープンソースのゲームエンジンで、2D ゲーム、インディーゲームのプロトタイプ、中規模 3D プロジェクトに向いています。

軽量で起動が速く、ノードとシーンの仕組みが分かりやすいのが特徴です。初心者には Unity より入りやすく、個人開発者にも扱いやすいエンジンです。

まず結論

Godot 入門では、最初から全機能を学ぼうとしないことが大切です。

おすすめの順序は次の通りです。

まず 2D から始める。
ノードとシーンを理解する。
最初は GDScript を使う。
開始、失敗、リスタートがある小さなゲームを作る。
その後でアニメーション、音、UI、ステージ、エクスポートを足す。

小さなゲームを 1 本完成させる方が、断片的なチュートリアルを大量に見るより効果的です。

Godot に向いている人

Godot は、ゲーム開発をゼロから学びたい人、2D インディーゲームを作りたい人、すばやくプロトタイプを作りたい人、大きな商用エンジンの複雑なワークフローを避けたい人に向いています。

大型商用パイプライン、豊富なアセットストア、モバイル広告 SDK、高品質 3D 表現が必要なら Unity や Unreal の方が成熟しています。ただし学習と個人制作には Godot で十分です。

インストールとプロジェクト作成

Godot は公式サイトからダウンロードし、解凍して実行するだけです。

最初のプロジェクトでは、デフォルト renderer、英語名、シンプルなパス、Git 管理をおすすめします。

`1`	`first-godot-game`

エディタでは Scene、FileSystem、Inspector、Script、2D / 3D ビューをまず覚えます。

ノードとシーン

Godot の中心概念はノードとシーンです。

代表的なノード：

Node2D：2D オブジェクトの基礎。
Sprite2D：画像表示。
CollisionShape2D：衝突形状。
CharacterBody2D：操作可能なキャラクター。
Camera2D：2D カメラ。
AudioStreamPlayer：音声再生。
Label：文字表示。

シーンはノードの組み合わせです。プレイヤー、敵、ステージをそれぞれシーンにできます。

Player (CharacterBody2D)
├── Sprite2D
├── CollisionShape2D
└── Camera2D

最初に作るゲーム

最初から RPG、オープンワールド、オンラインゲームを作らない方がよいです。

おすすめは 2D 回避ゲームです。

プレイヤーが上下左右に動く。
敵が画面端から出る。
敵に触れると失敗。
生存時間がスコア。
開始画面、ゲームオーバー、リスタートがある。

これだけで入力、移動、衝突、生成、UI、Timer、音、シーン再読み込みを学べます。

プレイヤー移動

プレイヤーには CharacterBody2D を使います。

extends CharacterBody2D

@export var speed := 300.0

func _physics_process(delta):
    var direction := Vector2.ZERO

    direction.x = Input.get_axis("move_left", "move_right")
    direction.y = Input.get_axis("move_up", "move_down")
    direction = direction.normalized()

    velocity = direction * speed
    move_and_slide()

入力 action：

move_left  -> A / Left
move_right -> D / Right
move_up    -> W / Up
move_down  -> S / Down

キーコードを直接書かず、action を使うとゲームパッドやキー変更に対応しやすくなります。

衝突と物理

よく使うノード：

CollisionShape2D：衝突範囲。
Area2D：重なり検出。
CharacterBody2D：操作キャラクター。
RigidBody2D：物理で動く物体。
StaticBody2D：壁や地面。

自分で移動を制御するなら CharacterBody2D、接触検出だけなら Area2D が分かりやすいです。

1
2
3

func _on_body_entered(body):
    if body.name == "Player":
        get_tree().reload_current_scene()

敵の生成

シーンは prefab のように実体化できます。

@export var enemy_scene: PackedScene

func spawn_enemy():
    var enemy = enemy_scene.instantiate()
    enemy.position = Vector2(800, randf_range(50, 550))
    add_child(enemy)

Timer と組み合わせれば、一定間隔で敵を生成できます。

UI、スコア、音

UI は Control 系ノードを使います。CanvasLayer、Label、Button、Panel がよく使われます。

スコア例：

var score := 0.0

func _process(delta):
    score += delta
    $CanvasLayer/ScoreLabel.text = str(int(score))

音は AudioStreamPlayer：

`1`	`$HitSound.play()`

ゲームは機能だけでなく、音、点滅、揺れ、ボタン状態などの反応で気持ちよくなります。

プロジェクト構成

最初から整理しておくと楽です。

res://
├── scenes/
├── scripts/
├── assets/
└── ui/

シーン、スクリプト、画像・音声、UI を分けておきます。

よくある失敗

ノード種類を間違える。
CollisionShape2D を忘れる。
キーを直接書く。
すべてを Main.gd に詰め込む。
最初のゲームを大きくしすぎる。

小さくても完成したゲームの方が、途中で止まった大作より価値があります。

学習順序

エディタ基本操作。
ノードとシーン。
GDScript。
入力 action。
2D 移動。
衝突と Area2D。
Timer と生成。
UI とスコア。
音とアニメーション。
デスクトップまたは Web へのエクスポート。

まとめ

Godot 入門の鍵は、全機能を覚えることではなく、ゲームの組み立て方を理解することです。ノードがシーンを作り、シーンがゲームを作り、スクリプトが動作を与え、シグナルがイベントをつなぎます。

まずは 2D ミニゲームを完成させましょう。移動、衝突、UI、音、リスタートまでできれば、次に TileMap、セーブ、状態機械、3D、Shader、エクスポート最適化へ進めます。

Ghostty ドキュメント速読：インストール、設定、日常利用の要点

Fri, 15 May 2026 14:50:11 +0800

Ghostty は新しいターミナルエミュレーターだが、単に「また一つ速いターミナル」が増えたという話ではない。公式ドキュメントによると、Ghostty は速度、機能、ネイティブなデスクトップ体験の三つを同時に満たそうとしている。つまり、GPU アクセラレーションと良好なレンダリング性能を目指しつつ、macOS と Linux ではできるだけ本物のローカルアプリのように振る舞い、すべての操作を独自描画 UI に押し込まない設計を目指している。

iTerm2、Kitty、Alacritty、WezTerm、あるいは OS 標準のターミナルを使っているなら、Ghostty で最も注目すべき点は単一の機能ではない。「すぐ使えること」と「深く設定できること」を同時に備えている点だ。デフォルト設定でもすぐ使える一方、さらに調整したくなったときには、設定ファイル、テーマ、キーバインド、フォント、Shell 統合、ターミナル制御シーケンスまで、公式ドキュメントが一通りの入口を用意している。

まず位置づけを見る

Ghostty の中核的な位置づけは、次の三点にまとめられる。

クロスプラットフォームなターミナルエミュレーターで、現時点では macOS と Linux に重点を置いている。
プラットフォームネイティブ UI を使う。macOS 版は Swift、AppKit、SwiftUI、Linux 版は Zig と GTK4 を使う。
ターミナルの中核は libghostty で、GUI アプリはこの共有コアを中心に構築されている。

この設計は日常体験に影響する。タブ、分割、エラーメッセージ、ウィンドウ状態の復元、システムショートカットなどは、単に「デスクトップアプリらしく見える部品」として作られているのではなく、各 OS の操作習慣にできるだけ近づけられている。macOS と Linux のデフォルトショートカットも、それぞれのプラットフォーム慣習に合わせて分けられている。

インストール：macOS は直接的、Linux はディストリビューション次第

公式のプリビルドバイナリは主に macOS 向けだ。もっとも一般的な方法は .dmg をダウンロードし、開いたあと Ghostty を Applications ディレクトリにドラッグすること。Homebrew ユーザーは、コミュニティが管理する cask も利用できる。

`1`	`brew install --cask ghostty`

Linux はより分散している。Ghostty のドキュメントでは、ディストリビューションごとのパッケージマネージャー、コミュニティバイナリ、ソースビルドが分けて説明されている。Arch、Alpine、Gentoo、NixOS、Snap、Solus、Void などにはそれぞれの経路がある。公式または信頼できるリポジトリがない場合、ドキュメントは第三者バイナリを気軽に入れるより、ソースからビルドする方向を勧めている。

これはサーバーや作業用マシンでは特に重要だ。ターミナルエミュレーターは大量の入出力、クリップボード、リンク、SSH セッション、ローカルファイルパスを扱う。インストール元は保守的に選び、公式 macOS パッケージ、ディストリビューションのリポジトリ、自分で出所を確認できるビルド手順を優先したい。

設定：いきなり大きな dotfiles をコピーしない

Ghostty の設定哲学は「ゼロ設定で使えること」だ。デフォルトフォントには JetBrains Mono が含まれ、Nerd Font もサポートされるため、多くのユーザーは最初に起動した時点で普通に作業できる。ドキュメントでは、主観的ではない設定を変えないと快適でない場合、それはデフォルト動作にすべきではないかと考えることさえ勧めている。

本当にカスタマイズが必要な場合、Ghostty はテキスト設定ファイルを使う。現在の設定ファイル名は config.ghostty で、旧バージョンでは config もサポートされる。代表的なパスは次の通り。

$XDG_CONFIG_HOME/ghostty/config.ghostty
$XDG_CONFIG_HOME/ghostty/config
$HOME/.config/ghostty/config.ghostty
$HOME/.config/ghostty/config

macOS では次の場所も読み込まれる。

1
2

$HOME/Library/Application Support/com.mitchellh.ghostty/config.ghostty
$HOME/Library/Application Support/com.mitchellh.ghostty/config

設定構文はとても直接的で、key = value という形だ。

font-family = JetBrains Mono
font-size = 14
theme = light:Rose Pine Dawn,dark:Rose Pine
keybind = ctrl+shift+t=new_tab

実用的な勧めとして、最初から他人の完全な設定をコピーしない方がよい。まず数日そのまま使い、最初はフォント、フォントサイズ、テーマの三つだけを変える。キーバインド、分割、ウィンドウ、Shell 統合で実際に摩擦を感じてから、必要な設定を一つずつ足していく方が安定する。

ドキュメント検索：ローカルでも完全な設定を確認できる

Ghostty には多くの設定項目があり、公式ドキュメントでは Option Reference にまとめられている。Web ページだけでなく、インストール後はローカルからも設定リファレンスを確認できる。

`1`	`ghostty +show-config --default --docs`

このコマンドはデフォルト設定とドキュメントを標準出力に出すため、ページャーにつなぐと検索しやすい。

`1`	`ghostty +show-config --default --docs \| less`

利用可能なフォントを見るには次を使う。

`1`	`ghostty +list-fonts`

内蔵テーマと利用可能なテーマを見るには次を使う。

`1`	`ghostty +list-themes`

デフォルトキーバインドを見るには次を使う。

`1`	`ghostty +list-keybinds --default`

これらのコマンドは、Web 上の断片をコピーするより信頼しやすい。自分が実際にインストールしている Ghostty のバージョンから出力されるからだ。

キーバインド：「アクション」を中心に考える

Ghostty のキーバインド設定形式は次の通り。

`1`	`keybind = trigger=action`

trigger はキー入力のトリガーで、action は Ghostty が実行する動作だ。新しいタブを作る、現在の surface を閉じる、設定を再読み込みする、プロンプトへジャンプする、といったものはすべて action になる。このモデルはわかりやすい。何かのメニュー項目を変更しているのではなく、入力シーケンスを一つの動作に紐づけている。

設定を変更した後は、実行中に再読み込みできる。デフォルトショートカットは次の通り。

Linux：ctrl+shift+,
macOS：cmd+shift+,

ただし、すべての設定が即時反映されるわけではない。新しく作るターミナルにだけ影響するものもあれば、完全な再起動が必要なものもある。「設定を書いたのに変わらない」と感じたら、構文を疑い続ける前に、その項目の説明を確認した方が早い。

テーマとフォント：まず内蔵を使い、その後で微調整する

Ghostty は多数のテーマを同梱しており、システムのライトモード、ダークモードに応じて別テーマへ切り替えることもできる。

`1`	`theme = light:Rose Pine Dawn,dark:Rose Pine`

テーマはカスタムファイルから読み込むこともできる。ドキュメントの注意は明確だ。テーマファイルは本質的には Ghostty の設定ファイルであり、多くの設定項目を指定できるため、信頼できない出所のテーマを安易に使うべきではない。

フォントについては、font-family を複数回指定して fallback フォントを設定できる。多言語環境では便利で、主フォントに英字や記号を担当させ、後続のフォントで中国語、日本語、その他の文字を補える。emoji、太字、斜体、リガチャなどの細部で問題が出たら、Option Reference で対応する項目を確認すればよい。

Shell 統合：SSH ユーザーは特に確認したい

Ghostty は bash、elvish、fish、nushell、zsh 向けに shell integration を自動注入できる。有効にすると、いくつかの体験が自然になる。

新しいターミナルを前のターミナルの作業ディレクトリから開ける。
複雑なプロンプトが resize 時に誤って回り込まず、再描画される。
プロンプトマーカーを使ってコマンド出力の間を移動できる。
プロンプト上で、編集習慣に合ったカーソル挙動が使える。

自動注入したくない場合は、設定で無効にできる。

`1`	`shell-integration = none`

さらに注意したいのは SSH だ。Ghostty は TERM として xterm-ghostty を使うが、多くのリモートホストにはまだ対応する terminfo がない。ドキュメントでは ssh-env と ssh-terminfo という二つの shell integration 機能が用意されており、デフォルトでは無効だが必要に応じて有効化できる。

`1`	`shell-integration-features = ssh-env,ssh-terminfo`

古いサーバー、コンテナ、踏み台、厳格に管理された本番環境へよく接続するなら、これらを有効にする前に公式の Terminfo と Shell Integration ドキュメントを読んでおきたい。ターミナル能力のネゴシエーションは地味だが、問題が起きると色の異常、ショートカットの不具合、全画面プログラムの表示崩れとして現れることがある。

私の試し方

Ghostty が自分に合うかだけを判断したいなら、次の順で試すとよい。

インストール後、設定を書かずに一日そのまま使う。
font-family、font-size、theme だけを調整する。
まず他人のショートカット表を取り込むのではなく、ghostty +list-keybinds --default でデフォルトを確認する。
SSH をよく使うなら、リモートホストの terminfo 互換性を先に確認する。
最後に分割、ウィンドウ、透明度、タイトルバー、背景画像などの見た目やワークフローの好みを調整する。

Ghostty のドキュメントはかなりエンジニアリング寄りで、「宣伝ページ」ではなく「設定リファレンスマニュアル」として読むのに向いている。多くのユーザーにとって、本当の判断基準は単純だ。デフォルト体験がすでに快適か、日常のエディタ、Shell、SSH、tmux、Zellij が安定しているか。このあたりがうまくいくなら、Ghostty は長期的なターミナル候補に入れる価値がある。

参考リンク

VS Code の表示言語を切り替える方法：中国語、英語、その他の言語

Fri, 08 May 2026 13:18:57 +0800

VS Code は多くの表示言語に対応しています。一般的には、対象の言語パックを先にインストールし、その後コマンドパレットから表示言語を選択します。特定の言語に固定したい場合は、argv.json の locale を手動で変更することもできます。

この方法は簡体字中国語だけでなく、英語、繁体字中国語、日本語、韓国語、フランス語、ドイツ語、スペイン語などにも使えます。

対応する言語パックをインストールする

英語以外のインターフェイスに切り替える場合は、通常、先に言語パックをインストールします。

VS Code 左側の拡張機能パネルを開きます。ショートカット Ctrl+Shift+X も使えます。
検索ボックスに対象言語を入力します。例：Chinese、Japanese、Korean、French。
対応する言語パックを選び、Install をクリックします。
インストール完了後、案内に従って VS Code を再起動します。

簡体字中国語では Chinese (Simplified)、繁体字中国語では Chinese (Traditional) がよく使われます。

コマンドパレットから言語を切り替える

ほとんどのユーザーには、この方法がおすすめです。

コマンドパレットを開きます：Ctrl+Shift+P。
Configure Display Language と入力します。
Configure Display Language コマンドを選択します。
一覧から使用したい言語を選びます。
案内に従って VS Code を再起動します。

再起動後、メニュー、設定画面、一般的なメッセージが選択した言語に切り替わります。対象言語が一覧にない場合は、先に拡張機能パネルから対応する言語パックをインストールしてください。

argv.json で言語を手動指定する

コマンドパレットで切り替えられない場合や、表示言語を明示的に固定したい場合は、VS Code のランタイム引数ファイルを直接編集できます。

コマンドパレットを開きます：Ctrl+Shift+P。
Preferences: Configure Runtime Arguments と入力して選択します。
locale 設定を探すか追加します。
値を対象の言語コードに変更します。
保存して VS Code を再起動します。

英語に切り替える例：

1
2
3

{
  "locale": "en"
}

簡体字中国語に切り替える例：

1
2
3

{
  "locale": "zh-cn"
}

日本語に切り替える例：

1
2
3

{
  "locale": "ja"
}

argv.json は JSON ファイルなので、カンマと引用符に注意してください。設定が間違っていると、VS Code が言語設定を正しく読み取れないことがあります。

よく使う表示言語コード

表示言語	locale
English (US)	`en`
簡体字中国語	`zh-cn`
繁体字中国語	`zh-tw`
French	`fr`
German	`de`
Italian	`it`
Spanish	`es`
Japanese	`ja`
Korean	`ko`
Russian	`ru`
Portuguese (Brazil)	`pt-br`
Turkish	`tr`
Bulgarian	`bg`
Hungarian	`hu`

言語が反映されない場合

次の順番で確認してください。

対象の言語パックがインストール済みか確認します。
locale に正しい言語コードを書いているか確認します。たとえば簡体字中国語は zh-cn で、zh-CN ではありません。
言語を変更した後、VS Code を完全に終了してから再度開きます。
argv.json を手動で編集した場合は、JSON 構文が正しいか確認します。
設定が混乱している場合は、locale 項目を削除してから Configure Display Language で選び直します。

通常は Configure Display Language で切り替えるのが最も簡単です。特定の言語を強制したい場合や、コマンドパレットでの切り替えが反映されない場合だけ、argv.json の手動編集を検討するとよいでしょう。

参考資料

VScode：VS Code の表示言語を簡体字中国語に変更し、表示言語を切り替える

opencode、Claude Code、Codex の違いとは？オープンソース AI コーディングツールガイド

Fri, 08 May 2026 08:33:37 +0800

opencode は anomalyco が公開しているオープンソースの AI Coding Agent だ。位置づけは明確で、開発者がターミナル内で、プログラム可能で拡張しやすく、複数のモデル提供元に接続できるコードアシスタントを使えるようにする。

Claude Code や Codex と並べて見ると、3つはいずれも同じ種類の問題を解こうとしている。AI を実際のコードベースに入れ、コンテキストを理解し、ファイルを変更し、コマンドやテストを実行できるようにすることだ。ただし、製品としての向きは異なる。

opencode はオープンソース、複数モデル対応、ターミナル TUI を重視する。Claude Code は Anthropic のモデルエコシステムとローカルでの開発協業を重視する。Codex は OpenAI の AI coding agent であり、ターミナル、IDE、Codex app、クラウドタスクから利用できる。

opencode が向いている人

opencode は次のような開発者に向いている。

ターミナル内でコード変更、プロジェクト分析、エンジニアリングタスクを進めたい人。
AI Coding Agent を単一のモデル提供元に縛られたくない人。
オープンソースツールを好み、自分で監査、拡張、二次開発したい人。
Neovim、TUI、コマンドラインワークフローに慣れている人。
将来的にデスクトップ、モバイル、その他のクライアントから同じコーディングエージェントをリモート操作したい人。

重要なのは、単なるチャットウィンドウを作ることではない。開発者が普段使っているターミナルとプロジェクトディレクトリの中に、AI コーディング能力を入れることだ。

インストール方法

公式 README には複数のインストール方法が用意されている。

# 直接インストール
curl -fsSL https://opencode.ai/install | bash

# npm
npm i -g opencode-ai@latest

# Windows
scoop install opencode
choco install opencode

# macOS と Linux
brew install anomalyco/tap/opencode
brew install opencode

# Arch Linux
sudo pacman -S opencode
paru -S opencode-bin

# その他
mise use -g opencode
nix run nixpkgs#opencode

公式 README では、古いバージョンの残存による問題を避けるため、インストール前に 0.1.x より前のバージョンを削除することも推奨している。

インストールスクリプトは次の優先順位でインストール先を選ぶ。

$OPENCODE_INSTALL_DIR
$XDG_BIN_DIR
$HOME/bin
$HOME/.opencode/bin

パスを指定したい場合は、次のように書ける。

1
2

OPENCODE_INSTALL_DIR=/usr/local/bin curl -fsSL https://opencode.ai/install | bash
XDG_BIN_DIR=$HOME/.local/bin curl -fsSL https://opencode.ai/install | bash

デスクトップアプリはまだ Beta

コマンドラインツールに加えて、opencode はデスクトップアプリも提供している。ただし現在は Beta 扱いだ。GitHub Releases または opencode.ai/download からダウンロードできる。

デスクトップ版は次のプラットフォームに対応している。

プラットフォーム	ファイル
macOS Apple Silicon	`opencode-desktop-mac-arm64.dmg`
macOS Intel	`opencode-desktop-mac-x64.dmg`
Windows	`opencode-desktop-windows-x64.exe`
Linux	`.deb`、`.rpm` または `.AppImage`

macOS と Windows では、パッケージマネージャーからデスクトップ版をインストールすることもできる。

# macOS
brew install --cask opencode-desktop

# Windows
scoop bucket add extras
scoop install extras/opencode-desktop

2つの内蔵 Agent モード

opencode には2つの内蔵 Agent があり、Tab キーで切り替えられる。

build はデフォルトモードで、完全な開発権限を持つ。コードを直接変更し、コマンドを実行し、エンジニアリングタスクを進める用途に向いている。

plan は読み取り専用モードだ。未知のコードベースを分析し、プロジェクト構造を理解し、変更方針を立てる用途に向いている。デフォルトではファイル編集を拒否し、bash コマンドを実行する前に確認する。

さらに、opencode には複雑な検索や多段階タスクのための general サブ Agent もある。ユーザーはメッセージ内で @general と入力して呼び出せる。

この設計は実用的だ。実際に手を動かす前に plan でプロジェクトを把握し、コードを変更する必要が出たら build に切り替える。大規模リポジトリでは、読み取り権限と書き込み権限を分けることで誤操作を減らせる。

Codex とは

Codex は OpenAI の AI coding agent で、開発者がコードを書き、コードレビューを行い、bug を修正し、エンジニアリングタスクを出荷するのを支援する。

単なるコード補完ツールとは異なり、Codex はコードベースを操作できる Agent に近い。ローカルツール内で開発者とペアになって作業することも、クラウドにタスクを委任することもできる。OpenAI の公式資料では、Codex は CLI、IDE、Codex app、ChatGPT/Codex クラウドなど複数の入口から利用できると説明されている。

開発者にとって、Codex のポイントは次の通りだ。

コードベースを読み、ファイルを編集し、コマンドとテストを実行できる。
ターミナル、IDE、アプリ、クラウドなど複数のインターフェースに対応する。
bug 修正、機能開発、リファクタリング、移行、コードレビュー、テスト補完に向いている。
OpenAI アカウント、モデル、Codex 製品体系との結びつきが強い。
クラウドタスクは、比較的明確な複数のエンジニアリングタスクを並行処理するのに向いている。

opencode が開かれたターミナルエージェントフレームワークに近いとすれば、Codex は OpenAI が提供する一式の AI コーディングワークベンチに近い。ローカルでペア作業でき、クラウドに委任でき、チームはそれをより長いエンジニアリングフローへ組み込める。

3つの主な違い

opencode、Claude Code、Codex はいずれも AI コーディングツールだが、選ぶときはまず次の観点を見るとよい。

ツール	中心的な位置づけ	主な強み	向いている用途
`opencode`	オープンソース AI Coding Agent	オープンソース、複数モデル、TUI、クライアント/サーバー構成	開かれたツールチェーン、交換可能なモデル、ターミナル中心のワークフローを求める開発者
`Claude Code`	Anthropic のコマンドライン型コーディングツール	Claude モデル体験、コード理解、長いコンテキスト、エンジニアリングタスク協業	Claude/Anthropic エコシステムを使っていて、ローカルでコードタスクを進めたい開発者
`Codex`	OpenAI の AI coding agent	CLI、IDE、Codex app、クラウドタスク、複数 Agent ワークフロー	ChatGPT/OpenAI を使っていて、ローカルでのペア作業とクラウド委任を併用したいチーム

簡単に言えば、opencode のキーワードは「オープン」と「交換可能」、Claude Code のキーワードは「Claude エコシステム」と「ローカル開発エージェント」、Codex のキーワードは「OpenAI エコシステム」と「複数入口の協業」だ。

Claude Code との違い

opencode の公式 FAQ は Claude Code と直接比較している。両者の能力はかなり近いが、主な違いは次の通りだ。

第一に、opencode は 100% オープンソースプロジェクトで、コードは GitHub にホストされ、MIT license で提供されている。

第二に、opencode は単一のモデル提供元に縛られない。OpenCode Zen が提供するモデルを推奨しているが、Claude、OpenAI、Google、またはローカルモデルとも組み合わせられる。開発者にとっては、モデルのコスト、能力、可用性が変わっても、特定のプラットフォームにロックインされにくいという意味がある。

第三に、opencode は任意の LSP サポートを内蔵している。コード補完、ジャンプ、診断、プロジェクト理解にとって、LSP は非常に重要な基盤だ。

第四に、opencode は TUI を重視している。Neovim ユーザーと terminal.shop の作成者によって作られており、製品の重心は明らかにターミナル体験にある。

第五に、opencode はクライアント/サーバー構成を採用している。つまり、opencode を自分のコンピューター上で動かし、将来的に TUI、デスクトップ、モバイル、その他のクライアントから制御できる。TUI はそのうちの一つのフロントエンドにすぎない。

opencode、Claude Code、Codex をいつ選ぶか

すでに Claude Code や Codex を使っている場合、opencode がすぐにそれらを置き換える必要はない。より自然な見方は、opencode がオープンで、モデルを交換でき、ターミナル寄りの選択肢を提供しているというものだ。

opencode を優先して検討したい場面は次の通り。

AI コーディングツールをできるだけオープンソースにしたい。
ワークフローを特定のモデル提供元に縛られたくない。
同じツールで Claude、OpenAI、Google、またはローカルモデルを試したい。
TUI が好きで、主要な作業フローをデスクトップアプリやWebアプリに中断されたくない。
クライアント/サーバー構成によるリモート制御能力に関心がある。

Claude Code を優先して検討したい場面は次の通り。

主に Claude モデルを使っている。
長いコンテキスト、コード理解、複雑なエンジニアリングタスク協業を重視している。
ローカルリポジトリ内で変更、テスト、リファクタリングを継続的に進めたい。
Anthropic による Claude Code のデフォルト製品体験を信頼している。

Codex を優先して検討したい場面は次の通り。

すでに ChatGPT または OpenAI アカウント体系を使っている。
同じ coding agent をターミナル、IDE、デスクトップアプリ、クラウドタスクで使いたい。
明確な bug 修正、機能開発、移行、テスト補完をクラウドに委任して並行処理したい。
コードレビュー、バックグラウンドタスク、チーム協業、複数 Agent ワークフローが必要だ。

公式の一体化された体験、デフォルトのモデル設定、企業管理、既製の統合を重視するなら、Claude Code や Codex のほうが楽な場合がある。制御性、オープン性、provider-agnostic を重視するなら、opencode は注目に値する。

注意点

opencode、Claude Code、Codex はいずれも変化が速い。GitHub release、インストールコマンド、デスクトップ版のファイル名、モデルの可用性、プラン権限は変わる可能性がある。インストールや選定の前には、それぞれの公式 README、ドキュメント、リリースページを直接確認するのがよい。

また、opencode のデスクトップアプリはまだ Beta と表示されており、安定した本番用ツールとして最初から扱うべきではない。日常的なエンジニアリングタスクでは、ターミナル版が引き続き主な入口になる。

ツールの流れとして見ると、opencode は AI Coding Agent のオープンツールチェーン方向を代表している。モデルを交換でき、クライアントも交換でき、コアの代理能力をできるだけ開く方向だ。一方、Codex と Claude Code は、モデル企業が coding agent を完成度の高い製品入口として作る方向に近い。開発者にとって、この2つの流れは長く併存するだろう。

参考リンク

opencode GitHub：https://github.com/anomalyco/opencode
opencode 公式サイト：https://opencode.ai
opencode ドキュメント：https://opencode.ai/docs
opencode Releases：https://github.com/anomalyco/opencode/releases
OpenAI Codex：https://openai.com/codex/
Using Codex with your ChatGPT plan：https://help.openai.com/en/articles/11369540-codex-in-chatgpt
OpenAI Codex CLI Getting Started：https://help.openai.com/en/articles/11096431-openai-codex-ci-getting-started

uv インストールガイド：macOS、Linux、Windows、pipx、Homebrew、WinGet の選び方

Thu, 07 May 2026 23:23:58 +0800

uv は Astral が提供する Python ツールチェーンマネージャーです。Python バージョン、仮想環境、依存関係、スクリプト、プロジェクト、ツールを管理できます。インストール方法は多く、公式ドキュメントではスタンドアロンインストーラーのほか、PyPI、Homebrew、WinGet、Scoop、Docker、GitHub Releases、Cargo が案内されています。

すばやく入れたいだけなら、まず公式のスタンドアロンインストーラーを使うのがおすすめです。システムのパッケージマネージャーでバージョンを管理したいなら Homebrew、WinGet、Scoop を選びます。Python ツールを隔離環境に入れる運用に慣れているなら pipx が向いています。

すばやく選ぶ

シーン	推奨方法	コマンド
macOS / Linux で素早くインストール	公式スタンドアロンインストーラー	`curl -LsSf https://astral.sh/uv/install.sh \| sh`
macOS / Linux に curl がない	公式スクリプト + wget	`wget -qO- https://astral.sh/uv/install.sh \| sh`
Windows で素早くインストール	PowerShell インストーラー	`powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 \| iex"`
Python ツールを隔離して入れる	pipx	`pipx install uv`
一時的または従来型の Python インストール	pip	`pip install uv`
macOS のパッケージ管理	Homebrew	`brew install uv`
macOS の MacPorts ユーザー	MacPorts	`sudo port install uv`
Windows のパッケージ管理	WinGet	`winget install --id=astral-sh.uv -e`
Windows の Scoop ユーザー	Scoop	`scoop install main/uv`
Rust ユーザー	Cargo	`cargo install --locked uv`

汎用的におすすめしやすい選択肢は次の通りです。

macOS / Linux：公式スタンドアロンインストーラー；
Windows：公式 PowerShell インストーラー、または WinGet；
pipx で Python CLI ツールを管理している場合：pipx install uv。

macOS と Linux：公式インストーラー

公式でもっとも直接的な方法は、curl でスクリプトを取得して sh に渡す方法です。

`1`	`curl -LsSf https://astral.sh/uv/install.sh \| sh`

システムに curl がない場合は wget を使えます。

`1`	`wget -qO- https://astral.sh/uv/install.sh \| sh`

特定バージョンをインストールしたい場合は、URL にバージョン番号を含めます。たとえば公式例の 0.11.11 は次のようになります。

`1`	`curl -LsSf https://astral.sh/uv/0.11.11/install.sh \| sh`

この方法は、ほとんどの個人開発環境に向いています。シンプルでクロスプラットフォームであり、uv 公式の更新機構とも相性が良いからです。

インストーラーは uv、uvx などのバイナリをユーザーディレクトリ配下に配置し、コマンドをターミナルから直接使えるように shell profile を変更する場合があります。PATH を変更されたくない場合は、公式 installer オプションを確認し、たとえば UV_NO_MODIFY_PATH=1 を設定します。

Windows：PowerShell インストーラー

Windows の公式インストール方法は、PowerShell でインストーラースクリプトを実行する方法です。

`1`	`powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 \| iex"`

特定バージョンをインストールする場合も、URL にバージョン番号を含めます。

`1`	`powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/0.11.11/install.ps1 \| iex"`

ここでの ExecutionPolicy ByPass は、インターネットから取得したインストーラースクリプトを実行できるようにするための指定です。安全のため、実行前にスクリプト内容を確認することもできます。

`1`	`powershell -c "irm https://astral.sh/uv/install.ps1 \| more"`

Windows のパッケージマネージャーに慣れているなら、WinGet や Scoop を優先してもよいでしょう。

pipx でインストールする

公式ドキュメントでは、uv が PyPI に公開されていることも説明されています。PyPI からインストールする場合は、pipx などで隔離環境に入れることが推奨されます。

`1`	`pipx install uv`

この方法は、pipx を Python CLI ツールマネージャーとして使っている人に向いています。uv を現在のプロジェクト環境と混ぜずに済みます。

pipx がない場合は、pip を直接使うこともできます。

`1`	`pip install uv`

ただし、uv は多くのプラットフォーム向けに事前ビルド済み wheel を提供していますが、対象 platform の wheel がない場合はソースからビルドされます。その場合は Rust ツールチェーンが必要です。

私のおすすめは、個人マシンでは pip install uv より pipx install uv のほうがきれい、というものです。プロジェクト環境の中では、uv をプロジェクト依存関係として入れないほうがよいでしょう。

Homebrew、MacPorts、WinGet、Scoop

システムのパッケージマネージャーを好む場合、uv は一般的な配布経路にも対応しています。

macOS では Homebrew を使えます。

`1`	`brew install uv`

MacPorts ユーザーは次のコマンドです。

`1`	`sudo port install uv`

Windows では WinGet を使えます。

`1`	`winget install --id=astral-sh.uv -e`

Scoop ユーザーは次の通りです。

`1`	`scoop install main/uv`

これらの方法の利点は、システムのパッケージマネージャーに一元管理できることです。欠点は、更新タイミングが uv 公式インストーラーではなく、各パッケージソースに依存することです。

Docker、GitHub Releases、Cargo

uv は GitHub Container Registry で Docker イメージも提供しています。

`1`	`ghcr.io/astral-sh/uv`

これは CI、Dockerfile、イメージビルド、一時的な実行環境に向いています。実際に使う場合は、公式の Docker 統合ドキュメントも確認するのがおすすめです。

バイナリを手動でダウンロードしたい場合は、GitHub Releases を使えます。各 release ページには通常、対応プラットフォーム向けのバイナリが含まれ、GitHub URL を使ってスタンドアロンインストーラーを呼び出す方法も説明されています。

Rust ユーザーは crates.io からもインストールできます。

`1`	`cargo install --locked uv`

ただし、この方法はソースからビルドするため、互換性のある Rust ツールチェーンが必要です。Rust エコシステムからインストールする明確な理由がない限り、一般ユーザーが Cargo を優先する必要はありません。

uv をアップグレードする

uv を公式スタンドアロンインストーラーで入れた場合は、自己更新コマンドを使えます。

`1`	`uv self update`

公式ドキュメントでは、uv の更新時にインストーラーが再実行され、shell profile が変更される可能性があると説明されています。更新時に PATH を変更されたくない場合は、次を設定します。

`1`	`UV_NO_MODIFY_PATH=1`

別の方法でインストールした場合は、その方法に対応するパッケージマネージャーでアップグレードします。たとえば pip で入れた場合は次の通りです。

`1`	`pip install --upgrade uv`

Homebrew、WinGet、Scoop、MacPorts も、それぞれのアップグレードコマンドを使います。

shell 補完を有効にする

uv は shell 補完に対応しています。公式ドキュメントでは、まず現在の shell を確認することが推奨されています。

`1`	`echo $SHELL`

Bash：

`1`	`echo 'eval "$(uv generate-shell-completion bash)"' >> ~/.bashrc`

Zsh：

`1`	`echo 'eval "$(uv generate-shell-completion zsh)"' >> ~/.zshrc`

fish：

`1`	`echo 'uv generate-shell-completion fish \| source' > ~/.config/fish/completions/uv.fish`

PowerShell：

if (!(Test-Path -Path $PROFILE)) {
  New-Item -ItemType File -Path $PROFILE -Force
}
Add-Content -Path $PROFILE -Value '(& uv generate-shell-completion powershell) | Out-String | Invoke-Expression'

uvx もよく使う場合は、uvx の補完を別途有効にできます。

Bash：

`1`	`echo 'eval "$(uvx --generate-shell-completion bash)"' >> ~/.bashrc`

Zsh：

`1`	`echo 'eval "$(uvx --generate-shell-completion zsh)"' >> ~/.zshrc`

fish：

`1`	`echo 'uvx --generate-shell-completion fish \| source' > ~/.config/fish/completions/uvx.fish`

PowerShell：

if (!(Test-Path -Path $PROFILE)) {
  New-Item -ItemType File -Path $PROFILE -Force
}
Add-Content -Path $PROFILE -Value '(& uvx --generate-shell-completion powershell) | Out-String | Invoke-Expression'

設定後は shell を再起動するか、対応する設定ファイルを再読み込みします。

uv をアンインストールする

uv をアンインストールする場合は、まずキャッシュと uv が保存しているデータを削除できます。

1
2
3

uv cache clean
rm -r "$(uv python dir)"
rm -r "$(uv tool dir)"

その後、バイナリを削除します。

macOS / Linux：

`1`	`rm ~/.local/bin/uv ~/.local/bin/uvx`

Windows：

1
2
3

rm $HOME\.local\bin\uv.exe
rm $HOME\.local\bin\uvx.exe
rm $HOME\.local\bin\uvw.exe

公式ドキュメントでは、0.5.0 より前の uv は ~/.cargo/bin にインストールされていた点も注意されています。古いバージョンからアップグレードした場合、古いバイナリが残っていることがあるため、手動で削除する必要があります。

インストール後に最初にすること

インストール後は、まずバージョンを確認します。

`1`	`uv --version`

その後、いくつかのよく使うタスクから始められます。

uv python install
uv venv
uv pip install requests
uvx ruff --version

新規プロジェクトなら、次も確認するとよいでしょう。

uv init：プロジェクトを初期化する；
uv add：依存関係を追加する；
uv sync：環境を同期する；
uv run：プロジェクト環境でコマンドを実行する；
uvx：Python CLI ツールを一時的に実行する。

私のおすすめ

個人の開発マシンでは、公式スタンドアロンインストーラーを優先するのがおすすめです。uv 公式ドキュメントにもっとも近く、uv self update も使えるためです。

Windows ユーザーでリモートスクリプトを実行したくない場合は、WinGet や Scoop を使えます。macOS ユーザーでツールをすべて Homebrew に任せたい場合は、brew install uv で問題ありません。

すでに pipx で Python CLI ツールを管理している人は、pipx install uv を使うとよいでしょう。ただし、具体的なプロジェクトの仮想環境内で pip install uv するのはおすすめしません。ツールチェーンとプロジェクト依存関係が混ざりやすくなるからです。

CI やコンテナビルドでは、Docker と GitHub Releases を優先的に確認し、イメージビルドの流れに合わせてバージョンを固定します。

Awesome Codex Skills：Codex CLI を拡張するコミュニティ製スキルカタログ

Thu, 07 May 2026 20:19:15 +0800

ComposioHQ の awesome-codex-skills は、Codex CLI 向けのコミュニティ製スキルカタログです。単なるプロンプト集ではなく、繰り返し使う作業手順をインストール可能で、再利用しやすく、保守しやすい Skill として整理している点に価値があります。

Codex を日常の開発パートナーとして使っているなら、この種のリポジトリの意味はかなり分かりやすいはずです。毎回説明していたルール、コマンド、参照資料、操作手順を一度 Skill にまとめておけば、次回から Codex は同じ文脈で作業を始められます。

このリポジトリが解決すること

Codex Skills は、Codex CLI に「専用の作業モード」を追加する仕組みだと考えると分かりやすいです。通常のプロンプトは一度きりの指示に向いていますが、Skill は長く再利用する作業に向いています。

たとえば、次のような作業です。

決まった形式でコミットメッセージを生成する。
特定の API ドキュメントを参照する。
プロジェクト固有のテストやデプロイコマンドを実行する。
チーム規約に沿って記事を書き直す、翻訳する、資料を整理する。
外部ツールを呼び出して反復的な開発補助作業を行う。

こうした内容を毎回入力するのは負担になります。Skill はそれらのルールを独立したディレクトリに置き、中心となる SKILL.md に手順を書きます。必要に応じてスクリプト、テンプレート、参考資料、アセットも添えられます。Codex は呼び出されたときにその説明を読み、定義された流れに従って作業します。

通常のプロンプトとの違い

通常のプロンプトは「今回はこうしてほしい」という一回限りの指示に近いものです。Skill は「この種類のタスクでは今後この手順で進める」という小さな運用マニュアルに近いものです。

主な利点は次の三つです。

再利用できる：よく使う作業手順を何度も貼り付ける必要がありません。
レビューしやすい：スキルファイルは通常ローカルの Markdown で、直接開いて編集し、バージョン管理できます。
拡張できる：複雑な Skill は自然言語の説明だけでなく、スクリプト、テンプレート、参考資料を含められます。

awesome-codex-skills のようなカタログの価値もここにあります。既存の Skill を探し、自分の作業スタイルに合わせて選び、インストールし、改造できます。

インストールと使い方

リポジトリにはインストールスクリプトが用意されており、手動インストールにも対応しています。典型的な流れは次の通りです。

1
2
3

git clone https://github.com/ComposioHQ/awesome-codex-skills.git
cd awesome-codex-skills
python install.py

少数の Skill だけを試す場合は、各スキルディレクトリの SKILL.md を先に読み、どの資料を読むのか、どのスクリプトを実行するのか、どのファイルを変更する可能性があるのかを確認してから、ローカルの Codex skills ディレクトリへ入れるのがよいでしょう。

インストール後、Codex はタスクに応じて Skill を自動的に使うこともできますし、明示的に名前を指定して呼び出すこともできます。長く使うなら、まずコミュニティ製 Skill を入れ、その説明を自分のプロジェクト規約に合わせて書き換えるのが実用的です。

注目したい Skill

この種のリポジトリで最初に見るべきなのは、名前が派手な Skill ではなく、反復作業を安定して減らしてくれる Skill です。

優先して見たいのは次のようなものです。

開発フロー系：コードレビュー、テスト、コミット、リリース、依存関係チェック。
ドキュメント処理系：書き直し、翻訳、要約、構造化整理。
ツール連携系：Codex を外部サービス、API、CLI ツールにつなぐもの。
プロジェクト規約系：チームの約束、ディレクトリ構成、命名規則、デプロイ手順を固定フローにするもの。

一文のプロンプトを包んだだけの Skill なら価値は限られます。調査、判断、実行、検証、出力までを安定した流れにできる Skill なら、長く残す価値があります。

注意点

コミュニティ製 Skill は便利ですが、ブラックボックスとしてそのまま実行するべきではありません。特にスクリプトを含む Skill は、インストール前に次の点を確認したいところです。

SKILL.md が Codex に何をさせようとしているか。
ネットワークアクセス、ファイルの読み書き、外部サービス呼び出しを行うスクリプトが含まれているか。
デフォルトのパス、コマンド、権限が自分の環境に合っているか。

Skill は Codex の行動範囲を広げます。よく書かれた Skill は、Codex をプロジェクトに詳しい同僚のようにしてくれます。雑に書かれた Skill は、合わないルールを作業フローへ持ち込むこともあります。理想は大量に入れることではなく、少数を入れ、自分に合うよう調整し、長く保守することです。

所感

awesome-codex-skills はブックマークする価値があります。特に Codex CLI を実際の開発、ドキュメント作成、自動化に使い始めている人には役立ちます。これは公式機能そのものではなく、コミュニティが整理した Skill の入口です。そこから着想を得ることも、普段の作業を自分用のローカル Skill に変えることもできます。

ヘビーユーザーにとって、Codex Skills の重要点は AI に多くを記憶させることではありません。同じ種類のタスクで回り道を減らすことです。ルールを Skill として書くことは、一度きりの説明を再利用可能な作業基盤に変えることでもあります。

Warp オープンソース化：ターミナルから Agentic Development Environment へ

Thu, 07 May 2026 20:15:08 +0800

warpdotdev/warp は Warp のオープンソースクライアントリポジトリです。Warp は現在、自身を「ターミナルから生まれた agentic development environment」と位置付けています。つまり、ターミナルを土台にしながら、AI coding agent、コードベース索引、タスク管理、開発ワークフローを同じ環境に統合しようとしています。

これは普通のターミナルエミュレータのオープンソースリポジトリではありません。むしろ、Claude Code、Codex、Gemini CLI のような agent が一般化する中で、ターミナル自体が agent を調整し、観察し、管理する開発環境になるべきか、という問いへの答えに近いものです。

Warp の答えは「なるべき」です。

現在のリポジトリ状況

2026年5月7日時点で、warpdotdev/warp は公開リポジトリで、GitHub では約 56k stars、4.1k forks が表示されています。README では、Warp のクライアントコードがオープンソース化され、コミュニティからの貢献を歓迎すると説明されています。

主要言語は Rust です。GitHub の言語統計では Rust が 98% 以上を占めています。これは Warp の位置付けと合っています。Web のラッパーではなく、クロスプラットフォームのネイティブ開発ツールです。

README で重要な点は次の通りです。

Warp は agentic development environment, born out of the terminal。
内蔵 coding agent を使えるだけでなく、Claude Code、Codex、Gemini CLI などの外部 CLI agent にも接続できる。
OpenAI は新しくオープンソース化された Warp リポジトリの founding sponsor。
リポジトリ内の agentic management workflows は GPT models によって駆動される。
Warp UI framework 関連 crate は MIT license、それ以外のコードは AGPL v3。

これらを見ると、Warp のオープンソース化は単にターミナルを公開しただけではなく、agent ワークフローの実験場として運営していることが分かります。

Warp は単なるターミナルではない

従来のターミナルが主に解決していたのは次の三つです。

shell を起動する。
コマンドを実行する。
出力を表示する。

初期の Warp の差別化は、ターミナルをより現代的にすることでした。コマンドブロック、補完、履歴、コラボレーション、UI 的な操作、クロスプラットフォーム体験などです。現在はさらに進み、AI agent を中心に開発フローを組み立てようとしています。

README から見ると、Warp はもはや「より使いやすい terminal」だけを強調していません。次の要素を重視しています。

内蔵 coding agent。
外部 CLI agent 対応。
issue triage。
spec 作成。
PR review。
contributor coordination。
観察可能な agent sessions。

つまり Warp は、ターミナルを「コマンドを入力する場所」から「複数の agent と一緒に働く場所」へ変えようとしています。

Oz とオープンソース管理

README では Oz が何度も登場します。

Warp の contribution overview では、多数の Oz agents が issue triage、spec 作成、実装、PR review に取り組んでいる様子が示されています。これは興味深い設計です。AI agent を「個人のコード作成支援」から「オープンソース協作の管理支援」へ広げているからです。

従来のオープンソースプロジェクトで難しいのは、コードを書くことだけではありません。むしろ維持管理です。

issue が多すぎて分類されない。
bug と feature request が混在する。
新規貢献者が取り組みやすいタスクを見つけにくい。
PR review の負担が大きい。
メンテナーがコミュニティ議論を継続的に追いにくい。

Warp の考え方は、agent にプロジェクト管理と協作作業の一部を先に担わせることです。README には Oz for OSS も登場します。これはメンテナー向けのプログラムで、同様の agentic open-source management workflows をほかのリポジトリへ持ち込むためのものです。

つまり Warp の狙いはターミナル製品だけではなく、AI 時代のオープンソース維持管理モデルの探索にもあります。

リポジトリ構成と技術スタック

リポジトリ構成を見ると、Warp は大規模な Rust プロジェクトです。

ルートには次のようなものがあります。

app/：メインアプリケーション関連コード。
crates/：中核 Rust crates。
assets/：リソースファイル。
command-signatures-v2/：コマンドシグネチャ関連。
docker/、script/、resources/、specs/ などのエンジニアリング用ディレクトリ。
.claude/、.warp/、.agents/skills などの agent 関連設定。

WARP.md にはより詳しいエンジニアリング説明があります。Warp は Rust-based terminal emulator で、自社製 UI framework WarpUI を使っていると説明されています。

主要モジュールはおおよそ次のように理解できます。

app/：ターミナルエミュレーション、shell 管理、AI 統合、Drive、認証、設定、workspace、session。
crates/warp_core/：中核ユーティリティとプラットフォーム抽象。
crates/editor/：テキスト編集機能。
crates/warpui/ と crates/warpui_core/：自社製 UI framework。
crates/ipc/：プロセス間通信。
crates/graphql/：GraphQL client と schema。

WARP.md ではさらに次のような特徴も挙げられています。

Entity-Handle system。
モジュール化された workspace 構造。
macOS、Windows、Linux クロスプラットフォーム、および WASM target。
Agent Mode、文脈認識、コードベース索引を含む AI integration。
Warp Drive クラウド同期。

この複雑さは、従来の軽量 terminal よりも、ほぼ完全な IDE に近いものです。

ローカルビルド

README のローカルビルド手順は簡潔です。

1
2
3

./script/bootstrap
./script/run
./script/presubmit

それぞれ次の役割です。

./script/bootstrap：プラットフォーム別の初期化。
./script/run：Warp をビルドして実行。
./script/presubmit：フォーマット、clippy、テストなどの提出前チェック。

WARP.md にはさらに細かいコマンドもあります。

cargo run
cargo bundle --bin warp
cargo nextest run --no-fail-fast --workspace --exclude command-signatures-v2
cargo fmt
cargo clippy --workspace --all-targets --all-features --tests -- -D warnings

Warp にコードを貢献するなら、./script/presubmit は基本的に必須です。

貢献フロー

Warp の貢献フローは、単に「PR を出せばよい」ではありません。

README では issue から PR までの軽量な流れが説明されています。

まず既存 issue を検索する。
重複がなければ bug または feature request を提出する。
メンテナーが issue を review し、readiness label を付けることがある。
ready-to-spec は、設計を spec として展開できる状態。
ready-to-implement は、設計が比較的明確で実装 PR に進める状態。
貢献者はラベル付き issue を引き受けられる。

この流れは大規模オープンソースに向いています。「アイデア」「設計」「実装」を分けることで、貢献者が最初から違う方向へ実装してしまうリスクを減らせます。

AI agent にも相性が良い流れです。agent はまず issue を整理し、spec を書き、テストを追加してから実装に進めます。Warp 自身もこの方式で agentic project management を示しています。

ライセンス：MIT + AGPL v3

Warp は二つのライセンス構成を採っています。

README では次のように説明されています。

Warp UI framework、つまり warpui_core と warpui crates は MIT license。
リポジトリのそれ以外のコードは AGPL v3。

これは重要です。AGPL v3 はネットワークサービスや配布に対して、より強いオープンソース要件を持ちます。学習、研究、貢献であれば大きな問題はありませんが、Warp のコードを商用製品やクローズドソース派生物に使いたい場合は、license を慎重に読み、必要なら法務相談が必要です。

簡単に言えば、Warp はオープンソースですが、「自由に持っていって閉源商用化できる」タイプの緩いライセンスではありません。

注目すべき点

第一に、Warp はターミナル、agent、プロジェクト管理を一つにまとめようとしています。

多くの AI coding ツールはまだ CLI かエディタプラグインです。Warp はターミナルという入口から、agent タスク、コード実行、コマンド出力、PR ワークフロー、チーム協作を統合しようとしています。

第二に、Warp のオープンソース化は agent ワークフロー観察に向いています。

コードを公開するだけでなく、contribution overview、agent session、issue triage、spec フローも見せています。AI がオープンソース協作にどう参加できるかを研究したい人にとって、このリポジトリ自体がサンプルです。

第三に、Warp は複雑な Rust デスクトップアプリケーションです。

Rust GUI、ターミナルエミュレータ、クロスプラットフォームアプリ、GraphQL client、クラウド同期、AI 統合を学びたいなら、読むべき構造が多くあります。ただし小さなプロジェクトではないため、新規貢献者はまずドキュメントと issue フローを読むべきです。

第四に、Warp は「内蔵 agent」と「bring your own CLI agent」の両方を支援しています。

これは現実的です。開発者が一つの agent だけを使うとは限りません。Claude Code、Codex、Gemini CLI、OpenCode、OpenClaw などは共存し続けるでしょう。Warp がそれらの作業台になれるなら、単一目的のターミナル以上の価値があります。

誰が注目すべきか

通常のターミナルユーザーにとって、Warp に注目する意味は、ターミナルがコマンドラインツールから AI ワークベンチへ変わりつつあるかもしれない点です。

AI coding agent をよく使う人にとって、Warp は複数 agent を管理しようとしている点で注目に値します。単なるチャット入口ではありません。

オープンソースメンテナーなら、Oz for OSS の流れを見る価値があります。agent による issue triage、PR review、コミュニティ協作、貢献者案内を試みています。

Rust 開発者にとって、Warp は大型の実例デスクトップアプリです。UI、ターミナル、クラウド同期、AI 統合、クロスプラットフォームコードの構成を研究できます。

単に従来のターミナルをすぐ置き換えたいだけなら、まず正式版をダウンロードして使い、その後でソースを読むか決めるのがよいでしょう。ソースから直接ビルドするのは、貢献者や深いユーザー向けです。

短評

Warp のオープンソース化の要点は、「現代的なターミナルがオープンソースになった」だけではありません。

より正確には、Warp はターミナルを agentic development environment へアップグレードしようとしています。ターミナルが shell、コードベース、コマンド実行、agent、issue、PR、協作フローをつなぐ役割を担う、という考え方です。

AI coding agent がさらに増える中で、開発環境の入口は変わるかもしれません。以前は IDE が開発体験を支配し、ターミナルはコマンド実行を担っていました。今後はターミナルが agent 協作の中心になる可能性があります。Warp のリポジトリは、その可能性を探っています。

UEFI プログラムのコンパイル入門：uefi-simple から最初の .EFI まで

Thu, 30 Apr 2026 19:53:08 +0800

最初の UEFI プログラムをコンパイルするのは、思ったほど簡単ではありません。環境構築には時間がかかり、リンカーエラーも多く、.EFI プログラムは通常のデスクトップアプリのように直感的に編集して実行できるものではありません。

この記事では、入門者向けに整理します。まず自分の最初の UEFI プログラムをコンパイルしたいだけなら、どこから始めるべきか、どの概念を先に理解すべきか、どこで詰まりやすいかを見ていきます。

UEFI プログラムとは何か

UEFI プログラムは通常、.EFI ファイルです。

Windows でダブルクリックして実行する普通の .exe ではありません。UEFI ファームウェア環境で動作する PE/COFF 実行ファイルです。よくある用途には次のようなものがあります。

ブートマネージャー
ハードウェア初期化ツール
ファームウェア更新ツール
起動前診断ツール
カスタムブートフロー

システム起動の早い段階で見える多くの機能は、UEFI アプリケーション、ドライバー、またはファームウェアサービスと関係している場合があります。

初心者は、最初から完全なファームウェア開発を理解する必要はありません。まずは UEFI Shell またはエミュレーターから読み込める .EFI ファイルをコンパイルすることを目標にします。

最初から EDK II に入らないほうがよい理由

本格的な UEFI 開発では EDK II に出会うことがよくあります。

EDK II は機能が充実しており、実際のファームウェア開発にも近いものです。ただし初心者にはあまり優しくありません。

プロジェクト構造が複雑
ビルドシステムに学習コストがある
環境変数やツールチェーン設定が多い
コンパイルエラーを読み解きにくい
コードを書く前に環境構築で詰まりやすい

目的が「最小の UEFI プログラムをまず動かす」ことであれば、軽量なサンプルから始めるほうが向いています。

pbatard/uefi-simple はそのようなプロジェクトです。目的は明確で、シンプルな UEFI Hello World サンプルを提供し、まず .EFI をコンパイルできるようにすることです。

`uefi-simple` は何に向いているか

uefi-simple は UEFI 入門の最初の足場として向いています。

主に 3 つの問題を解決します。

最小限のコンパイル可能な UEFI アプリケーション構造を提供する
最初から大規模なファームウェア工程に触れる複雑さを避けられる
コンパイル、リンク、実行の流れが通るかを先に確認できる

このプロジェクトは Visual Studio 2022 や MinGW/gcc など複数のビルド方法に対応しており、QEMU と OVMF を使ったテストもできます。

つまり、初期段階から実機を何度も再起動して試す必要はありません。まずエミュレーターで動かすほうが安全です。

入門前に用意するもの

最低限、いくつかの種類のツールが必要です。

1 つ目はコンパイラーツールチェーンです。

Windows では、まず次のどちらかを検討できます。

Visual Studio 2022
または MinGW/gcc

2 つ目は UEFI 実行環境です。

主な選択肢は 2 つあります。

実機の UEFI Shell で .EFI を実行する
QEMU + OVMF を使って仮想環境でテストする

3 つ目はサンプルプロジェクトです。

初心者は空ディレクトリからビルドスクリプトを手書きするより、uefi-simple のような最小サンプルを使うほうが、ビルドシステムで詰まる可能性を減らせます。

大まかな流れ

最小 UEFI プログラムの入門手順は、次のように考えると分かりやすいです。

まず、サンプルプロジェクトを取得します。

`1`	`git clone https://github.com/pbatard/uefi-simple.git`

次に、ビルドツールチェーンを選びます。

Visual Studio を使う場合は、プロジェクト内の Visual Studio ソリューションに従ってビルドします。
MinGW/gcc を使う場合は、プロジェクトが提供する Makefile や説明に従います。

次に、.EFI ファイルを生成します。

ここで重要なのは対象アーキテクチャを確認することです。一般的な PC は通常 x86_64、つまり 64 ビット UEFI 環境です。

次に、UEFI Shell からアクセスできる場所へ .EFI を置きます。

実機を使う場合は、通常 FAT32 パーティションまたは USB メモリを用意します。
QEMU を使う場合は、ディレクトリやディスクイメージをマウントできます。

最後に、UEFI Shell で実行します。

実行結果は通常、Hello World のような最小限の出力です。

詰まりやすいところ

UEFI プログラムのコンパイルで詰まりやすいのは、C 言語そのものではなく、環境とリンクです。

よくある問題は次の通りです。

コンパイラーのアーキテクチャが違う
ターゲット形式が違う
リンカー引数が不足している
UEFI エントリーポイントがない
UEFI が読み込める .EFI ではなく通常の実行ファイルを生成している
QEMU または OVMF の設定ができていない
実機の Secure Boot が未署名プログラムの実行を止める

特にリンカーエラーは、初心者にコードの間違いだと思わせがちです。
実際には、エントリー関数、サブシステム、対象アーキテクチャ、リンクスクリプト設定が原因であることも多いです。

そのため最初の段階では、複雑なロジックに急いで進まないほうがよいです。まず元のサンプルがコンパイルでき、実行できることを確認してから、少しずつ出力内容を変えていきます。

テストに QEMU + OVMF をすすめる理由

実機で UEFI プログラムをテストすることはできますが、初心者の段階ではあまり便利ではありません。

何度も次の流れを繰り返すことになります。

コンパイル
USB メモリへコピー
再起動
UEFI Shell に入る
実行
エラーを記録
OS に戻って修正

このループはかなり遅いです。

QEMU + OVMF を使うと、OS の中で直接 UEFI 環境をシミュレートできます。.EFI が読み込めるかをより速く確認でき、実機のブート項目へ影響を与える可能性も低くなります。

プログラムが基本的に動くようになってから実機で試すほうが安定します。

初心者はまずどこを変えるべきか

サンプルプロジェクトで最初の .EFI をコンパイルできたら、すぐに複雑な機能を書き始めないほうがよいです。

おすすめの順番は次の通りです。

まず出力テキストを変え、再コンパイル後のプログラムが本当に反映されているか確認する。
次に UEFI が提供する簡単な情報を読んでみる。
エントリー関数、出力プロトコル、基本サービスを理解する。
最後にファイルシステム、グラフィック出力、ブート項目管理などの複雑な機能を考える。

この順番なら、各ステップを確認できます。
最初から多くを変えると、問題がコードなのか、ビルドなのか、実行環境なのか判断しにくくなります。

普通の C プログラムとの違い

UEFI プログラムは C で書けますが、通常の C プログラムとは実行環境がまったく違います。

通常の C プログラムは OS 上で動き、標準ライブラリ、ファイルシステム、プロセスモデル、システムコールに依存できます。

UEFI プログラムは OS が起動する前に動作します。利用するのは UEFI ファームウェアが提供するサービスです。通常のプログラムで当たり前に使っているものの多くは、ここでは自然に使えるわけではありません。

そのため UEFI プログラムを書くときは、いくつかの違いに慣れる必要があります。

エントリー関数が違う
出力方法が違う
利用できるライブラリが違う
メモリーやファイルアクセスの方法が違う
デバッグ方法が違う

だからこそ、普通の C プログラムの感覚で直接書くのではなく、最小サンプルから始めるのがおすすめです。

現実的な学習ルート

入門だけなら、次の流れが現実的です。

第 1 步：uefi-simple をコンパイルする
第 2 步：QEMU + OVMF で実行する
第 3 步：Hello World の出力を変更する
第 4 步：UEFI Shell が .EFI をどう読み込むか理解する
第 5 步：UEFI のエントリー関数と基本的な出力プロトコルを学ぶ
第 6 步：その後で EDK II やより完整な UEFI 開発資料を見る

このルートの重要点は、まずフィードバックループを作ることです。

ソースから .EFI を生成し、UEFI 環境で出力を確認できれば、最初の大きな壁は越えています。

参考

最後に

最初の UEFI プログラムをコンパイルするときの難しさは、多くの場合「C コードを書くこと」ではなく、ツールチェーン、リンク形式、実行環境をつなげることにあります。

複雑な機能へ急ぐ必要はありません。
uefi-simple のような最小サンプルから始め、まず実行できる .EFI を得てから、UEFI のエントリーポイント、プロトコル、ビルド方法を少しずつ理解していくほうが楽です。

GoAccess最新版の自前ビルドと利用メモ: ソース導入からリアルタイムHTMLレポートまで

Wed, 29 Apr 2026 00:08:00 +0800

整理時点は 2026-04-29 です。
現時点で公式 README に載っている最新安定版は 1.10.2 です。

1. まずビルド依存を入れる

1
2
3

sudo apt-get update
sudo apt-get install -y build-essential wget tar \
  libncurses-dev libmaxminddb-dev libssl-dev zlib1g-dev

2. 最新ソースパッケージを取得する

cd /usr/local/src
sudo wget https://tar.goaccess.io/goaccess-1.10.2.tar.gz
sudo tar -xzvf goaccess-1.10.2.tar.gz
cd goaccess-1.10.2

3. ビルドオプションを設定する

`1`	`sudo ./configure --enable-utf8 --enable-geoip=mmdb --with-zlib`

リアルタイムHTMLレポートで TLS も使いたいなら、こちらでもよいです。

`1`	`sudo ./configure --enable-utf8 --enable-geoip=mmdb --with-zlib --with-openssl`

4. ビルドしてインストールする

1
2

sudo make
sudo make install

5. バージョンを確認する

1
2

goaccess --version
which goaccess

6. 端末でそのままレポートを見る

Nginx や Apache の一般的な combined ログなら、まずはこれでよいです。

`1`	`goaccess /var/log/nginx/access.log --log-format=COMBINED`

Apache のログパスならこちらです。

`1`	`goaccess /var/log/apache2/access.log --log-format=COMBINED`

7. 静的な HTML レポートを生成する

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -a \
  -o /usr/share/nginx/html/goaccess-report.html

カレントディレクトリに出しても構いません。

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -a \
  -o report.html

8. リアルタイム HTML レポートを生成する

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -a \
  -o /usr/share/nginx/html/goaccess-report.html \
  --real-time-html

ポートを変えるなら:

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -a \
  -o /usr/share/nginx/html/goaccess-report.html \
  --real-time-html \
  --port=7891

ローカルホストだけにバインドするなら:

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -a \
  -o /usr/share/nginx/html/goaccess-report.html \
  --real-time-html \
  --addr=127.0.0.1

9. ログを追い続ける

`1`	`tail -f /var/log/nginx/access.log \| goaccess --log-format=COMBINED -`

ファイル先頭から読んで、そのままリアルタイムで追うなら:

tail -f -n +0 /var/log/nginx/access.log | goaccess \
  --log-format=COMBINED \
  -o report.html \
  --real-time-html -

10. 特定のリクエストだけを見る

たとえば firefox を含むリクエストだけ:

1
2

tail -f /var/log/nginx/access.log | grep -i --line-buffered 'firefox' | goaccess \
  --log-format=COMBINED -

たとえば 5xx と 3xx だけ:

1
2
3

tail -f -n +0 /var/log/nginx/access.log | awk '$9~/3[0-9]{2}|5[0-9]{2}/' | goaccess \
  --log-format=COMBINED \
  -o out.html -

11. 複数ログをまとめて解析する

`1`	`goaccess /var/log/nginx/access.log /var/log/nginx/access.log.1 --log-format=COMBINED`

圧縮済みと未圧縮をまとめて読むなら:

`1`	`zcat --force /var/log/nginx/access.log* \| goaccess --log-format=COMBINED -`

12. マルチスレッドを使う

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -o report.html \
  -j 4

chunk を大きくするなら:

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -o report.html \
  -j 4 \
  --chunk-size=8192

13. 増分処理

まず古いログを永続化しておく:

`1`	`goaccess /var/log/nginx/access.log.1 --log-format=COMBINED --persist`

次に現在のログを追加する:

`1`	`goaccess /var/log/nginx/access.log --log-format=COMBINED --restore --persist`

永続化済みデータだけを読む:

`1`	`goaccess --restore`

14. 自分なら最初に流すコマンド

sudo apt-get update
sudo apt-get install -y build-essential wget tar \
  libncurses-dev libmaxminddb-dev libssl-dev zlib1g-dev

cd /usr/local/src
sudo wget https://tar.goaccess.io/goaccess-1.10.2.tar.gz
sudo tar -xzvf goaccess-1.10.2.tar.gz
cd goaccess-1.10.2
sudo ./configure --enable-utf8 --enable-geoip=mmdb --with-zlib --with-openssl
sudo make
sudo make install

goaccess --version

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -a \
  -o /usr/share/nginx/html/goaccess-report.html \
  --real-time-html

だいたいこれで十分です。
やることが明確なら、最新版をソースから入れて、まず --log-format=COMBINED と --real-time-html を通すところまで進めれば、あとはログパス、出力先、ポートを調整していくくらいです。

2026年の組み込み開発環境はどう選ぶべきか: Keil、STM32CubeIDE、VS Code、そして AI 協調

Wed, 22 Apr 2026 23:05:00 +0800

マイコンや組み込み開発を続けていると、すぐにひとつの現実的な問いにぶつかります。2026 年になり、AI によるコーディング支援がかなり一般化してきた今、開発環境は結局どう選ぶのがよいのか、という問いです。

表面的にはこれは IDE 同士の比較に見えます。しかし実際に問われているのは別のことです。つまり、単に「プロジェクトを動かせる道具」が欲しいのか、それとも「既存エコシステム、コーディング体験、AI 協調」を両立できるワークフローが欲しいのか、ということです。

その観点で見ると、答えは Keil、STM32CubeIDE、VS Code、CLion のどれかひとつを選ぶことではなく、それぞれが得意な部分を組み直すことになりやすいです。

まず主な選択肢を見て、それぞれ何を解決しているのかを整理する

組み込み分野で長く見かける環境は、だいたい次のようなものです。

Keil
STM32CubeIDE
VS Code
CLion

さらに遡れば IAR を挙げる人もいます。ただ、今の議論で重要なのは「誰が一番古くからあるか」ではなく、「今の開発現実に誰が一番合っているか」です。

Keil: エコシステムは強いが、編集体験は明らかに古い

Keil は今でも避けて通りにくい存在です。理由は単純で、とにかく使われているからです。

会社に残っている古いプロジェクト、オンライン上の教材、サンプルコード、共有されている既存資産の多くが、今でも Keil を中心に組まれています。ビルド、書き込み、デバッグという一連の流れも依然として成熟しており、とにかく基板を動かすことが最優先なら、非常に短い道筋で済みます。

その一方で、弱点もかなりはっきりしています。

UI が古い
編集体験が平凡
AI 支援コーディングの主戦場にはなりにくい

つまり Keil は、「プロジェクトの入口とデバッグ基盤」としては強いものの、2026 年の編集体験を担う理想的な環境とは言いにくいです。

STM32CubeIDE: STM32 には親切だが、どちらかといえば学習と立ち上げ向き

STM32 のエコシステムを主に使っているなら、STM32CubeIDE は最初に触れる環境になりやすいです。

長所は非常にわかりやすいです。

入門しやすい
ペリフェラル設定やプロジェクト生成がしやすい
デバッグ系の流れも比較的そろっている

学生や初心者、立ち上げフェーズのプロジェクトには十分に直感的です。

ただし、長期運用、チーム協業、より複雑なワークフローに入っていくと、徐々に限界が見えてきます。特に商用プロジェクトや重めのチーム開発では、必ずしも最も快適な主環境ではありません。

そのため、これは「すばやく始めるための環境」であって、長期的な主力エディタとは限りません。

VS Code: 厳密には IDE ではないが、AI 時代では優位性が増している

VS Code は厳密には従来型の IDE ではなく、拡張可能なコードエディタです。

だからこそ、最初から二面性があります。

弱点は次の通りです。

プラグインや設定が必要
初心者にはあまり親切ではない
組み込み IDE の全工程をそのまま置き換えるわけではない

しかし、その同じ特徴がそのまま強みにもなります。

拡張性が高い
編集体験がかなり現代的
ハイライト、ジャンプ、検索、リファクタリングが強い
AI ツールや Agent ワークフローとの相性が良い

今や多くの開発者が欲しいのは、単に「コードが書けること」ではなく、「AI 協調を自然に入れられること」です。その意味で、VS Code の優位性はかなり明確です。

CLion: 体験は良いが、組み込みの主流ワークフローの中心ではない

CLion が話題に出ることはよくあります。C/C++ の編集体験が良いからです。

ただ、組み込み開発者にとって本当の問題は「良いか悪いか」より、「移る価値があるか」です。

組み込みでは利用者が比較的少ない
既存の組み込みエコシステムとの接続が Keil ほど直接的ではない
AI 協調という観点でも、VS Code より現実的な優位があるとは限らない

そのため、CLion は「理屈上はかなり良い選択肢」ではあっても、今の組み込み主流ワークフローの自然な中心とは言いにくいです。

より現実的な答え: ビルドとデバッグは Keil、日常のコーディングは VS Code

それぞれの道具を役割ごとに分けて考えると、かなり実務的な結論が見えてきます。

Keil には既存プロジェクト互換、ビルド、書き込み、デバッグを任せる
VS Code には日常のコーディング、検索、ジャンプ、AI 協調を任せる

この組み合わせの価値は、ひとつの道具ですべてをやろうとしない点にあります。それぞれを、本当に得意な位置に戻してあげるわけです。

多くの組み込み案件では、Keil のエコシステム自体を避けることができません。ならば、すべてを Keil に押し込めるより、Keil をビルド・デバッグのバックエンド入口と割り切り、実際の編集体験は VS Code に任せる方が自然です。

なぜこの組み合わせが AI 時代に向いているのか

今や環境の違いは、「エディタが気持ちよく使えるか」だけではありません。「AI を自然に接続できるか」が大きな分かれ目です。

VS Code にはこの点でかなり実務的な強みがあります。

AI プラグインや Agent の動きが活発
AI がプロジェクトを読み、変更するのに向いた閲覧体験
現代的なプラグイン群と組み合わせやすい

つまり、組み込み開発で面倒になりがちな作業の一部を AI に肩代わりさせやすくなります。

既存プロジェクト内の関数や呼び出し関係を探す
初期化コードを素早く生成する
簡単な UART 出力を足す
古いプロジェクト構造を説明させる
既存ファイルの一部だけを小さく直す

こうしたことは昔も不可能ではありませんでした。ただ、とにかくやりにくかったのです。VS Code の価値は、見た目がよいことではなく、AI 協調の作業台になりやすいことです。

重要な補助線: プラグインで VS Code と Keil プロジェクトをつなぐ

このワークフローが現実に機能するかどうかは、VS Code と Keil プロジェクトをつなげられるかにかかっています。

実用的な方向性のひとつは、VS Code から Keil のプロジェクト構造を読み取り、エディタ内部から Keil のバックエンドを呼び出して次のような操作を行えるようにすることです。

プロジェクトを開く
ビルドする
書き込む

そうすれば、日常のコーディングで二つの画面を行ったり来たりする必要が減ります。重いデバッグ、つまりステップ実行、ブレークポイント、レジスタ確認が必要なときだけ Keil に戻ればよくなります。

この種のプラグインの価値は、単に画面切り替えが減ることではありません。ワークフロー自体を途切れさせないことにあります。

C/C++ の基本プラグイン設定を軽視しない

VS Code を組み込みの主エディタとして使うなら、見落とされがちですが非常に重要な点があります。C/C++ の基本プラグインとプロジェクト索引をきちんと設定することです。

これが整っていないと、体験を壊す問題が次々に起きます。

定義ジャンプが効かない
赤線の誤検知が多い
補完の精度が低い
ヘッダ関係が崩れる

この状態を見て、「やはり VS Code は組み込みに向かない」と判断してしまう人もいます。ですが実際には、プラグインと索引の接続が不十分なだけであることが少なくありません。

この部分がきちんと整えば、VS Code は大規模プロジェクトの読解、シンボル検索、AI を使った局所的なコード修正でかなり強さを発揮します。

このワークフローが特に向いている人

この組み合わせは、特に次のような人に向いていると思います。

1. すでに Keil ベースの資産が大量にある人

会社の案件、教材、過去コードがすべて Keil 中心なら、見た目を現代化したいだけでその資産を捨てる必要はありません。Keil を残し、VS Code を前段に足す方が、移行コストははるかに低いです。

2. AI に組み込みコードを手伝ってもらいたい人

関数の説明、ひな形コードの生成、局所ロジックの修正などを AI に任せたいなら、従来型の組み込み IDE より VS Code の方が自然にその役割を引き受けやすいです。

3. 学習資料と実案件の両方をつなぎたい人

学習資料は今でも Keil ベースのものが多いですが、自分の作業環境までその時代に留まる必要はありません。Keil を互換層、VS Code を生産性層として分けて考える方が、全体としてバランスが取れます。

結び

2026 年の組み込み開発環境で本当に問われているのは、「どの IDE が最も多機能か」ではなく、「どの組み合わせが今の仕事のしかたに最も合っているか」です。

素早く始めたいだけなら STM32CubeIDE には今でも価値があります。大量の既存資産を受け継ぐなら Keil は依然として避けられません。ですが、現代的な編集体験と AI 協調まで取り込みたいなら、より現実的な答えは次の形になりやすいです。

Keil にビルドとデバッグを任せ、VS Code にコードを書く仕事を任せる。

唯一の正解ではないとしても、今ある選択肢の中ではかなり無理の少ない答えだと思います。

8つの代表的な設定ファイル形式はどう選ぶべきか: INI、XML、JSON、YAML、TOML から Markdown まで

Wed, 22 Apr 2026 21:48:37 +0800

コードを書く人、サーバーをいじる人、ゲーム設定を調整する人、あるいは各種ツールチェーンを保守する人にとって、設定ファイルは避けて通れません。

実際、プログラムを本当に壊すのはアルゴリズムでもフレームワークでもなく、設定の 1 行であることが少なくありません。スペースが 1 つ足りない、カンマが 1 つ多い、あるいは値の書き方がシステムの想定から外れている。代表的な設定ファイル形式を並べて考えると、自然と次の問いに戻ってきます。

人間が書きやすい形式はどれか
機械が読みやすい形式はどれか
AI Agent の時代に、設定ファイルそのものの役割は変わるのか

この記事は、その問いを簡潔に整理したものです。

01 設定ファイルとは、結局「人」と「機械」の調停である

設定ファイルをうまく言い表すなら、人間とプログラムの間で交わされる一種の「行動契約」だと言えます。

その価値は明快です。業務ロジックを書き直さなくても、再コンパイルしなくても、数行のテキストを書き換えるだけで、サイトの挙動、アプリのロジック、デプロイ方法、あるいはゲームのグラフィックや隠し設定まで変えられます。

ただし、その契約には最初から矛盾があります。

人間が欲しいのは、たとえば次のようなものです。

読みやすく、書きやすく、階層がわかりやすいこと
コメントを書けて、あとから見返しやすいこと
できるだけ重複を減らし、再利用やモジュール化がしやすいこと
小さなミスで即死しないこと

しかし機械が気にするのは、ほぼ次の 2 点です。

解析が速いこと
ルールが厳密で、型が明確で、曖昧さが少ないこと

だから設定ファイル形式は常に「人間に優しいか」「機械に優しいか」の間で引っ張られます。人間に読みやすい形式ほど、機械にとっては解析が面倒になりやすい。機械にとって処理しやすい形式ほど、人間には編集時の事故が起こりやすいのです。

02 INI: 単純でわかりやすいが、表現力は低い

まずは INI です。

長所はとてもわかりやすいです。

構造が単純
セクションとキー・バリューの組み合わせで直感的
コメントを書ける
ゲーム設定や基本的な環境変数のような軽量設定に向く

古いゲーム設定をいじったことがある人や、手動でツールのパラメータを触ったことがある人なら、一度は見たことがあるはずです。

ただし INI には明確な限界もあります。構造が平坦すぎるため、複雑なネストや配列を自然に表現しにくいのです。加えて、厳密な型システムを持たないことが多く、多くの値は結局ただの文字列として扱われ、最終的な解釈はプログラム側に委ねられます。

そのため INI は、軽作業には便利な古い道具車のようなものです。小さな用途なら快適ですが、複雑なプロジェクトになると急に力不足になります。

典型的な INI 設定はこんな形です。

[server]
host=127.0.0.1
port=8080

[feature]
enable_cache=true

03 XML: 厳密で安定しているが、とにかく書くのが重い

次は XML です。

古い Java プロジェクトを保守したことがある人や、閉じタグだらけの巨大設定ファイルを見たことがある人にはおなじみでしょう。

XML の長所は次の通りです。

階層構造が明確
コメントが書ける
ルールが厳密
schema と組み合わせると強力な検証ができる

つまり、機械は実際に読み込む前に、型、出現回数、構造制約などをかなり正確に把握できます。安全性の感覚はとても強いです。

一方で、人間にとっての負担も非常に大きいです。

タグが冗長
視覚ノイズが多い
ファイルがすぐ膨らむ
閉じタグを 1 つ落とすだけで全体が壊れやすい

XML は、印鑑が揃った正式な契約書のようなものです。機械には好かれますが、人間の保守はしんどい。最近の新規プロジェクトでは優先されにくくなりましたが、古いシステムや厳密性重視の場面ではまだ完全には消えていません。

同じ設定を XML で書くと、たとえばこうなります。

<config>
  <server>
    <host>127.0.0.1</host>
    <port>8080</port>
  </server>
  <feature>
    <enable_cache>true</enable_cache>
  </feature>
</config>

04 JSON: データ交換の王者だが、手書き設定には少し窮屈

現代開発で JSON を避けて通るのはほぼ不可能です。

JSON に対する典型的な評価はこうです。データ交換形式としては非常に強い。しかし、人間が手で保守する設定ファイルとしてはやや窮屈です。

その強みは次の通りです。

オブジェクトと配列の構造が明確
ネットワーク送信に向く
パーサーが成熟している
Web API やフロントエンド・バックエンド通信に適している

特に XML と並べると、その軽さは非常に目立ちます。同じ構造なら JSON のほうが短く、ネットワーク上でやり取りしやすいことが多いです。

ただし弱点もはっきりしています。標準 JSON はコメントを書けません。

加えて、文法も厳格です。

key は必ずダブルクォート
最後の要素に trailing comma は不可
記号を 1 つ落としただけで壊れる

そのため JSON は API やサービス間通信には最適でも、人間が説明を書きながら頻繁に編集する設定ファイルには必ずしも向きません。

たとえばこんな形です。

{
  "server": {
    "host": "127.0.0.1",
    "port": 8080
  },
  "feature": {
    "enable_cache": true
  }
}

05 YAML: 読みやすいが、インデントと暗黙型変換が怖い

Docker、CI/CD、Kubernetes、自動デプロイに触れたことがあるなら、YAML と無縁ではいられません。

最大の魅力は、見た目のきれいさです。

波括弧や引用符が少ない
インデントで階層を表せる
コメントを書ける
anchor による再利用もできる

そのため第一印象の読みやすさでは、YAML は JSON よりずっと人間向きに感じられることが多いです。

しかし問題もまさにそこにあります。複雑さを隠してしまうため、実運用では次の 2 つの事故が頻発します。

インデント地獄
暗黙の型変換

インデントの問題はわかりやすく、スペースが 1 つ多い・少ないだけで設定が壊れます。さらに厄介なのは暗黙型変換で、普通の文字列に見える値が勝手に真偽値などに解釈されることがあります。

だからこそ YAML は「見た目はいいのに、触ると痛い」形式として語られがちです。人間の可読性は高い一方で、機械の解析は意外に複雑で、パーサー実装差も起こりやすいのです。

同じ設定を YAML で書くと、たとえばこうなります。

server:
  host: 127.0.0.1
  port: 8080

feature:
  enable_cache: true

06 TOML: 可読性と確定性のバランスを取る形式

TOML はしばしば「現代的なバランス解」と見なされます。

魅力は、INI の直感性と JSON の型の明確さをある程度両立している点です。

コメントを書ける
構造がわかりやすい
型が比較的明示的
日付や時刻の表現が自然
YAML のような暗黙型変換の罠が少ない

現代のツールチェーンでも採用例が増えており、Python の pyproject.toml はその代表です。

もちろん万能ではありません。深いネストになるとやや冗長になり、パス形式の表記を何度も書くのが面倒です。ただし中小規模のプロジェクト設定、ツール設定、パッケージ管理設定なら、かなり安定した体験が得られます。

コメントを書けて、意味が明確で、機械にも無理がない形式を探すなら、TOML はかなり有力です。

典型的な TOML はこんな形です。

[server]
host = "127.0.0.1"
port = 8080

[feature]
enable_cache = true

07 `.conf` と Apache 設定: 汎用形式ではなく、ドメイン固有の文法

強調しておきたいのは、.conf を見て「統一された形式」だと思ってはいけない、ということです。

.conf は単に configuration の拡張子であって、中身の書き方はシステムごとの流儀に依存します。つまり .conf は広いカテゴリ名であって、ひとつの標準構文ではありません。

その例として Apache 設定は非常にわかりやすいです。

一部は単純な 1 行ディレクティブ
一部はスコープ付きタグ構造
Web サーバーという特定領域では非常に自然

強みは運用現場との相性の良さで、権限、ルーティング、VirtualHost などを自然に記述できます。ただし自分のエコシステム向けの性格が強く、汎用設定形式としての広がりはあまりありません。

この種の設定は、汎用フォーマットというより、特定ドメイン向けの DSL に近いものです。

たとえば最小の Apache 風設定は次のようになります。

Listen 80

<VirtualHost *:80>
    ServerName example.com
    DocumentRoot "/var/www/html"
</VirtualHost>

08 Protocol Buffers: 工業級の強い型、安全性は高いが敷居も高い

Protocol Buffers は、もはや「手で設定ファイルを書く」というより、正式なデータ定義とシリアライズ方式です。

強みは非常に大きいです。

強い型
明確な schema
前方・後方互換性が高い
バイナリ転送がコンパクト
機械処理が高速

その代わり、導入コストも高いです。

まず .proto を書く必要がある
ツールとコンパイル工程が必要
小さなプロジェクトにはやや重い

そのため「小さなツールの設定をしたいだけ」という用途には向きませんが、大規模システム、RPC、分散システム、長期進化するプロトコルには非常に向いています。

書き方も「構造を定義し、そこからコードを生成する」前提です。

syntax = "proto3";

message ServerConfig {
  string host = 1;
  int32 port = 2;
  bool enable_cache = 3;
}

09 AI Agent時代には、Markdownが再び「設定方式」になるかもしれない

この話の中で最も面白いのは、Markdown まで設定形式の候補に入ってくることです。

従来のプログラマ視点では奇妙に聞こえるかもしれません。Markdown は普通、文書形式だからです。しかし対象が厳密なパーサーではなく、大規模言語モデルや AI Agent になると、この考え方は意外と筋が通っています。

なぜなら、従来のプログラムは厳密な構文と固定フィールドに依存していましたが、大規模モデルは意味、構造、文脈の理解を得意とするからです。彼らにとっては、

見出しは階層
箇条書きは手順
太字は強調
自然言語そのものがルールの器

になります。

つまり設定対象が「融通の利かないパーサー」から「意味を理解できる Agent」へ変わると、Markdown のような人間向けの構造化テキストこそ、より自然な設定手段になり得るのです。

これはとても重要な転換です。従来のソフトウェア時代では、人間が機械に合わせるために設定形式が存在していました。しかし AI の時代には、機械のほうが人間の表現へ寄ってきています。

たとえば Agent へのタスク設定は、こんなふうにそのまま書けてしまいます。

# 任务目标

为新用户写一封欢迎邮件。

## 要求

- 语气友好
- 不超过 150 字
- 提到产品的 3 个核心功能

## 禁止事项

- 不要承诺不存在的功能
- 不要使用夸张营销语气

10 では、どう選べばいいのか

ここまでの話を圧縮すると、だいたい次のように整理できます。

とにかく単純で軽く、平坦な設定がほしい: INI
強い構造、強い検証、旧システム互換がほしい: XML
ネットワーク転送や API 交換が中心: JSON
高い可読性とクラウドネイティブな運用設定がほしい: YAML
現代的で安定した汎用設定体験がほしい: TOML
特定システム内部のルールを書く: .conf / Apache 系 DSL
工業級のプロトコル設計と長期進化を重視する: Protocol Buffers
AI Agent 向けに自然な表現で指示したい: Markdown

つまり「最良の設定ファイル形式」は 1 つではありません。誰のために書くのかで変わります。

人間の保守のためか
機械の高速解析のためか
サービス間通信のためか
あるいは AI Agent の理解と実行のためか

まとめ

設定ファイルの歴史は、結局のところ、人間と機械が「理解コスト」をどちらに載せるかを何度も再配分してきた歴史です。

昔は人間が機械に合わせるしかなかったため、括弧、インデント、引用符、厳密な構文を覚える必要がありました。今は大規模言語モデルや Agent システムが成熟しつつあり、機械のほうが自然な表現を理解し始めています。その結果、「設定」という行為そのものも変わり始めています。

将来、多くの場面で設定ファイルは固定構文ではなく、構造化された意図の記述へと変わっていくかもしれません。それでも当面は、JSON、YAML、TOML、INI、XML が共存し、それぞれ最も向いた役割を担い続けるでしょう。

WindowsでVS CodeからDockerイメージをビルドする方法

Thu, 16 Apr 2026 10:20:00 +0800

Windows環境でVS CodeからDockerイメージを作る流れはシンプルです。基本は3ステップだけです。環境準備、Dockerfile作成、イメージビルドの順で進めます。

01 事前準備

まず次の2点を確認します。

Docker Desktopをインストールし、起動しておく。
VS CodeでMicrosoft公式のDocker拡張機能を入れる。

WindowsではDocker DesktopのWSL 2バックエンド（Settings > Resources > WSL Integration）を使うと、安定性と速度の面で有利です。

02 Dockerfileを用意する

まだDockerfileがない場合は、VS Codeで自動生成できます。

VS Codeでプロジェクトフォルダを開く。
F1またはCtrl+Shift+Pでコマンドパレットを開く。
Docker: Add Docker Files to Workspaceを実行する。
Node.js、Python、.NETなど対象プラットフォームを選び、案内に従う。

通常は次のファイルが生成されます。

Dockerfile
.dockerignore

まずは動く雛形を作り、あとで調整するのが効率的です。

03 イメージをビルドする3つの方法

方法A: Dockerfileを右クリック

エクスプローラーでDockerfileを右クリックし、Build Image...を選択してタグ名を入力します。

方法B: コマンドパレット

F1でDocker: Build Imageを実行し、コンテキストとタグを選びます。

方法C: 統合ターミナル

`1`	`docker build -t your-image-name .`

現在のディレクトリをビルドコンテキストとして、your-image-nameタグでイメージを作成します。

04 よくある問題の確認ポイント

Docker Desktopが起動していない: 先に起動状態を確認する。
ビルドが遅い: WSL 2バックエンドが有効か確認する。
ファイルが見つからないエラー: 実行場所がプロジェクトルートか確認する。
VS CodeでDocker項目が出ない: VS Code再起動とdocker version確認を行う。

まとめ

WindowsでVS CodeからDockerイメージを作る作業は、初期セットアップができれば難しくありません。Docker Desktopと拡張機能を整え、必要ならDockerfileを自動生成し、UIまたはdocker buildでビルドすれば運用できます。

CH347 開発用の共通リソースのコレクション: ドライバー、ツール、SPI フラッシュフラッシュ

Fri, 03 Apr 2026 10:00:00 +0800

この記事では、箱から出してすぐにデバッグとフラッシュを開始できるようにすることを目的として、CH347 を使用するときに最も頻繁に使用する一連のリソースをコンパイルします。

CH347 を初めて使用する場合は、次の順序で環境を準備することをお勧めします。

まずは公式商品ページをご覧いただき、記載内容をご確認ください
目的に応じて対応するドライバーをインストールしてください
SPI Flash フラッシュツールを準備し、接続検証を実行する

正式な入り口

CH347商品ページ：https://www.wch.cn/products/CH347.html

不明なソースや古いバージョンからドライバーパッケージを入手することを避けるために、最初に公式ページからダウンロードエリアにアクセスすることをお勧めします。

よく使用されるドライバー

1) `CH341PAR.EXE`

使用：

USB to JTAG / SPI / I2C / パラレルポート / GPIO およびその他のインターフェイスドライバー

該当するシナリオ:

マルチプロトコル通信や低レベルインターフェースのデバッグにCH347を使用する必要がある場合

2) `CH343SER.EXE`

使用：

USB から高速シリアルポートへの Windows 製造元のドライバー

該当するシナリオ:

主に CH347 をシリアルポートツールとして使用し、より高いシリアルポートレートを必要とします。

SPIフラッシュフラッシュツール

AsProgrammer：https://github.com/nofeletru/UsbAsp-flash

一般的な用途:

SPI NOR フラッシュの識別
チップIDの読み取り
元のファームウェアをバックアップする
ファームウェアの消去/書き込み/ベリファイ

推奨される操作順序 (落とし穴を避けるため)

ドライバーのインストール後、デバイスを抜き差しし、デバイスマネージャーを開いて正常に認識されるか確認してください。
初めてフラッシュする前に、「読み取り + バックアップ」を実行して元のコンテンツを保持します。
書き込み後は必ずご確認ください。「書き込みが成功しました」というプロンプトだけを見てはいけません。
チップが認識できない場合は、電源、レベル、配線を確認し、その後ソフトウェア構成を確認してください。

FFmpeg の `-map` パラメータの詳細な説明: ビデオ、オーディオ、および字幕ストリームの正確な選択

Thu, 02 Apr 2026 23:14:03 +0800

マルチオーディオトラックおよびマルチ字幕ビデオ処理では、-map は FFmpeg の最も重要で最も誤用されやすいパラメータの 1 つです。

-map を明示的に指定しない場合、FFmpeg はデフォルトのルールに従ってストリームを自動的に選択するため、多くの場合、期待した結果が得られません。例えば：

エクスポートすると字幕が失われる
間違ったオーディオトラック言語が選択されました
不要なデータストリームが混入している

この記事では、最も一般的なシナリオを使用して、-map の使用方法を説明します。

まずは「流れ」とは何かを理解する

通常、コンテナーファイルには複数のコンテンツストリーム (ストリーム) が存在します (mp4、mkv など)。一般的なものには次のようなものがあります。

ビデオストリーミング (v)
オーディオストリーム (a)
字幕ストリーム (s)
添付ファイル/データストリーム (フォント、表紙、章など)

まず ffprobe を使用して、ファイル内にどのようなストリームがあるかを確認できます。

`1`	`ffprobe -hide_banner input.mkv`

`-map` の基本構文

最も一般的な書き方は次のとおりです。

`1`	`-map input_index[:stream_type][:stream_index]`

例えば：

0:v: 1 番目の入力ファイルのすべてのビデオストリーム
0:a:0: 入力ファイル 1 のオーディオストリーム 1
1:s:1: 2 番目の入力ファイルの 2 番目の字幕ストリーム

例証します:

input_index は 0 から始まり、-i のシーケンスに対応します。
stream_index も 0 で始まります

実践例

1) ビデオは A から、音声は B から来ます

ffmpeg -i english.mp4 -i french.mp3 \
  -map 0:v:0 -map 1:a:0 \
  -c:v copy -c:a aac \
  french.mp4

意味：

english.mp4 の最初のビデオストリームを取得します
french.mp3 の最初のオーディオストリームを取得します
結合された出力は french.mp4 です。

2) 最初の入力のすべてのストリームを保持し、追加のオーディオトラックを追加します。

ffmpeg -i english.mp4 -i french.mp3 \
  -map 0 -map 1:a:0 \
  -c copy \
  english-french.mp4

意味：

-map 0 まず、すべてのストリームを最初の入力ファイルに取り込みます
2 番目の入力の最初のオーディオストリームを追加します

非常に実践的な 2 つの高度なテクニック

1) ネガティブマッピング: 不要なフローを除外します。

たとえば、最初の入力のすべてのストリームを保持しますが、2 番目のオーディオストリームを削除します。

`1`	`ffmpeg -i input.mkv -map 0 -map -0:a:1 -c copy output.mkv`

2) オプションのマッピング: ストリームは存在せず、中断されません。

一部のファイルには字幕がない場合があります。その場合は、? を使用できます。

`1`	`ffmpeg -i input.mp4 -map 0:v -map 0:a -map 0:s? -c copy output.mp4`

0:s? は、「字幕がある場合はマップし、字幕がない場合はスキップし、エラーは報告されない」ことを意味します。

一般的なピットの位置

-map を使用すると、FFmpeg はデフォルトでストリームを自動的に選択しなくなるため、必要なものをすべて書き出す必要があります。
-c copy は、トランスコーディングを行わずにカプセル化とコピーのみを行います。ターゲットコンテナが特定のエンコーディングをサポートしていない場合でも、失敗します。
複数の入力を入力するときに最もよくある間違いは、シリアル番号を入力することです。シリアル番号は -i の順序にのみ依存することに注意してください。
安定したスクリプトを作成したい場合は、まず ffprobe を作成し、次に手書きよりも安定した -map を生成します。

要約する

-map の中核は 1 つの文です。「どの入力から、どのタイプのストリームを取得し、どのストリームを取得するか」を FFmpeg に明確に指示します。

マスタリング後は、複数のオーディオトラック、複数の字幕、ファイル間の結合などの複雑なシーンを安定して処理できるようになり、「エクスポート結果が間違っているが原因がわからない」という問題を回避できます。

プラグインによって引き起こされる VS Code の高い CPU 使用率をトラブルシューティングする方法

Wed, 01 Apr 2026 00:00:00 +0000

VS Code が突然フリーズしたり、ファンが激しく回転したり、CPU が長時間占有されたりした場合、最も一般的な原因は通常、エディタ自体ではなく、拡張プラグインの競合またはプラグインの異常な動作です。

この記事では、問題を特定するために最も時間を節約できる方法を優先して、すぐに実行できる一連のトラブルシューティングパスを示します。

最初に最速の位置決めを実行します: Extension Bisect を開始します

Start Extension Bisect の核となるアイデアは次の二項対立です。各ラウンドでは、拡張機能の半分が一時的に無効になり、再起動されます。「問題がまだ存在するかどうか」というフィードバックを通じて、疑わしいプラグインが見つかるまで範囲がすぐに狭められます。

操作手順:

Ctrl+Shift+P (macOS では Cmd+Shift+P) を押してコマンドパネルを開きます。
Start Extension Bisect を入力して実行します。
再起動するたびに、CPU 使用率とフリーズが再発するかどうかを観察します。
数回繰り返すと、VS Code によって疑わしい拡張機能のリストが表示されます。

位置決め後に何をするか

疑わしいプラグインを見つけたら、次の順序で対処することをお勧めします。

まずプラグインを最新バージョンに更新してください。
改善が見られない場合は、プラグインを一時的に無効にして 1 ～ 2 日間観察してください。
置き換え可能な機能を持つプラグインについては、より軽量なソリューションへの置き換えが優先されます。
このプラグインを使用する必要がある場合は、その詳細設定を確認し、不要なリアルタイム分析、インデックス作成、または監視機能をオフにしてください。

見落とされがちな2つの「増幅器」

主な原因がプラグインである場合でも、次の構成により CPU の問題が増幅されます。

検索範囲が大きすぎます
たとえば、ビルド製品、依存関係ディレクトリ、ログディレクトリをグローバル検索に含めると、引き続きプラグインとファイルインデックスに高い負荷がかかります。
ファイル監視には大きなディレクトリまたはソフトリンクが含まれています
ソフトリンク、キャッシュディレクトリ、および自動生成されたディレクトリは、簡単に多数のファイルイベントをトリガーし、拡張機能が繰り返し動作する可能性があります。

ディレクトリは、settings.json で適切に除外できます。たとえば、次のようになります。

{
  "search.exclude": {
    "**/node_modules": true,
    "**/dist": true,
    "**/build": true
  },
  "files.watcherExclude": {
    "**/.git/objects/**": true,
    "**/node_modules/**": true,
    "**/dist/**": true
  }
}

提案をレビューする

問題のあるプラグインを見つけた場合は、プラグイン名、トリガーとなるシナリオ、最終的な処理方法の 3 つの情報を記録することをお勧めします。
このようにして、次回環境を移行するかシステムを再インストールするときに、同様の問題をすぐに回避できます。

要約する

VS Code の高い CPU 使用率をトラブルシューティングするには、最初に Start Extension Bisect を使用して迅速に特定し、次に検索範囲とファイル監視範囲を組み合わせて収束させるのが最も効果的です。
最初に配置を決めてから最適化する方が、「多数のプラグインをやみくもに無効にする」よりも時間を節約でき、安定性も高くなります。