Developer Tools on KnightLiブログ

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 という基本的な工学判断に戻るべきです。

参考リンク：

Codexのモバイルリモートアクセス：ChatGPT AppでMac上の開発タスクを追跡する

Sat, 16 May 2026 17:42:40 +0800

OpenAIは2026年5月中旬、Codex remote accessをChatGPTモバイルアプリに追加しました。これはスマートフォンでコードを書く機能ではなく、Mac上で動くCodexをスマートフォンから追跡・操作するための機能です。

Codexは引き続きMac上でプロジェクトを読み、コマンドを実行し、ファイルを編集し、テスト結果を確認します。スマートフォン側は進捗確認、質問への回答、追加指示、操作承認を担当します。

できること

OpenAIのCodex remote connectionsドキュメントによると、モバイルアクセスでは次のことができます。

ホスト上のプロジェクトで新しいthreadを開始、または既存threadを継続
追加指示の送信、質問への回答、作業方向の調整
コマンドやその他の操作の承認
出力、diff、テスト結果、端末出力、スクリーンショットの確認
Codexの完了や注意が必要なタイミングで通知を受信
接続済みホストとthreadの切り替え

単なる小さなチャット画面ではなく、Codexの作業コンテキストに接続するモバイル操作面です。

必要条件

同じChatGPTアカウントとworkspaceでCodexを使える必要があります。スマートフォンには最新版のChatGPT Appが必要で、iOSとAndroidに対応します。

ホストは現時点ではMacです。Macは起動中、オンライン、Codex App実行中で、同じアカウントとworkspaceにログインしている必要があります。モバイル設定とデバイス制御には現在Codex App for macOSが必要で、Codex CLIやIDE Extensionからは設定できません。

MFA、SSO、passkeyが必要なアカウントでは、セットアップ中にその認証を完了する必要があります。ChatGPT workspaceでは、管理者がRemote Control accessを有効にする必要がある場合もあります。

制限

第一に、現在はmacOS hostが必要です。スマートフォンが接続するのはMac上のCodex Appであり、Codex CLI、IDE Extension、Linux / Windows開発機に直接接続するわけではありません。

第二に、ホストはオンラインでなければなりません。Macがスリープしたり、ネットワークを失ったり、Codex Appを閉じたりすると、リモートセッションは切断される可能性があります。

第三に、接続はQRコードのセットアップに依存します。Mac側でSet up Codex mobileを開き、スマートフォンでQRコードを読み取り、ChatGPTで連携を完了します。

第四に、遠隔操作にも承認フローがあります。端末コマンド、ファイル変更、テスト実行、外部アクセスに関わる操作は、内容を確認してから承認すべきです。

接続方法

MacでCodexを開きます。
サイドバーでSet up Codex mobileを選びます。
Codexがこのホストのリモートアクセスを有効化し、QRコードを表示します。
スマートフォンでQRコードを読み取り、ChatGPTのセットアップ画面に進みます。
同じChatGPTアカウントとworkspaceであることを確認します。
必要なMFA、SSO、passkeyを完了します。
成功すると、スマートフォンのCodexにMacが表示されます。

接続後はMac側のSettings > Connectionsで接続済みデバイスを管理できます。コンピューターをスリープさせない設定、Computer Use、Chrome extensionもここで確認できます。

スマートフォンでやるべきこと

スマートフォンに向いているのは、承認、方向修正、結果確認です。Codexがコマンド実行を求めたときに承認し、誤解やテスト失敗があれば短い指示で修正し、diffやテスト出力を確認できます。

価値があるのは「スマートフォンで開発する」ことではなく、ホスト上で動く開発タスクの携帯用コントローラーになることです。

よくある問題

ホストが表示されない場合は、MacでCodex Appが動いていること、Allow other devices to connectが有効であること、同じChatGPTアカウントとworkspaceを使っていることを確認します。

承認リクエストが表示されない場合は、ChatGPTモバイルアプリでCodexを開き、再度QRコードを読み取るか、ホスト側からセットアップをやり直します。workspaceでは管理者設定も確認します。

リモートセッションが切れる場合は、Macがスリープしていないか、ネットワークが切れていないか、Codex Appを閉じていないかを確認します。

向いている場面

長いCodexタスクをよく走らせる、席を離れても承認したい、複数のプロジェクトやthreadを扱う、Macを主開発機として使っている人に向いています。

WindowsやLinux中心、Codex CLIやIDE Extensionだけを使う、スマートフォンだけで完全な開発環境を期待する場合には向きません。

まとめ

Codexのモバイルリモートアクセスは、開発をスマートフォンに移す機能ではありません。Codexが止まりがちな承認、質問、テスト失敗、方向確認を、ChatGPT Appから処理できるようにする機能です。

Mac上でCodexをよく使う人には有用です。たまにコードの質問をするだけなら、効果はそれほど大きくありません。

参考資料

Claude Code + Ollama ローカル導入ガイド：CC Switch で無料の AI コーディングアシスタントを作る

Fri, 15 May 2026 23:27:50 +0800

最近、Claude Code のような AI コーディングアシスタントが注目されています。魅力は単にコードについて会話できることではなく、プロジェクトを読み、ファイルを編集し、コマンドを実行し、依存関係を入れ、エラーを見ながら修正を続けられる点にあります。かなり Agent に近い使い方ができます。

ただし問題はコストです。プロジェクトが大きくなるとコンテキストも長くなり、複数ターンの Agent 操作で API クォータを一気に消費します。試用、小さなツールの修正、スクリプト作成、ローカルのプライベートプロジェクトで使いたいだけなら、Claude Code の操作感を残したままモデルだけローカルにできないか、と考えるのは自然です。

この構成の鍵になるのが CC Switch です。Claude Code から OpenAI 互換 API としてローカルの Ollama サービスへ接続し、公式 Claude API ではなくローカルモデルへリクエストを転送できます。

この構成で解決できること

全体の流れは次のように考えると分かりやすいです。

1
2
3

Claude Code デスクトップ
+ CC Switch API 転送レイヤー
+ Ollama ローカルモデル

Claude Code は引き続きコーディングワークフローとプロジェクト操作を担当します。CC Switch はモデルプロバイダー設定と API 互換性を受け持ち、Ollama はローカルでモデルを動かします。

これはローカルモデルが突然 Claude と同等になるという意味ではありません。価値があるのは、Claude Code の Agent ワークフローを低コスト、オフライン、プライベートなローカル環境で使えるようにする点です。

基本準備

始める前に、次のものを用意します。

Git をインストールする。
Ollama をインストールする。
コーディング向きのローカルモデルを取得する。
CC Switch をインストールする。
Claude Code をローカルで使える状態にする。

モデルは、まずコード能力が比較的強いものから試すとよいでしょう。たとえば Qwen Coder、DeepSeek Coder、またはツール呼び出しとコード生成がある程度安定しているモデルです。大きいモデルほど結果は良くなりやすい一方、メモリや GPU への負荷も高くなります。

メモリに余裕がないマシンでは、小さめのモデルで流れを確認してから、徐々に大きいモデルを試すのがおすすめです。

CC Switch の重要設定

Ollama を起動すると、通常のローカル API アドレスは次のようになります。

`1`	`http://127.0.0.1:11434/v1`

CC Switch では OpenAI 互換のプロバイダー種別を選びます。よく使う選択肢は次のものです。

`1`	`OpenAI Chat Completions`

そのうえで base URL を Ollama のローカルアドレスに向けます。

API key はローカル Ollama では通常、本物のキーを必要としません。ただし多くのツールは環境変数やプレースホルダーを求めます。次のような値を使えます。

`1`	`ANTHROPIC_API_KEY`

または、手元のローカル設定で受け入れられる別のプレースホルダー変数でも構いません。

特に注意したい設定項目があります。

`1`	`"inferenceModels"="[\"haiku\",\"sonnet\",\"opus\"]"`

これは Claude Code が期待するモデルロールをローカルプロバイダーへマッピングする設定です。実際には haiku、sonnet、opus を Ollama または CC Switch 側で利用できるモデル名に対応させる必要があります。この対応が間違っていると、Claude Code がモデルを呼べなかったり、意図しない設定へ戻ったりします。

Claude Code の強み

Claude Code の一番の価値は、単発の補完ではなくコーディング全体のワークフローにあります。

プロジェクト構造を読み取って理解する。
タスクに応じて関連ファイルを見つける。
コードを直接編集する。
コマンドやテストを実行する。
エラーを観察して修正を繰り返す。
1 つのセッションで複数ステップの作業を進める。

多くの人が Claude Code を残したい理由もここにあります。通常のチャット UI でもコード片は生成できますが、リポジトリ内で自然に作業してくれるわけではありません。Claude Code は、実行できる開発アシスタントに近い存在です。

Ollama の役割

Ollama はローカルモデルの実行と管理を担当します。モデルのダウンロード、ロード、ローカル推論を扱います。

利点は明確です。リクエストは手元のマシンに残り、繰り返し使っても API 課金が発生せず、ネットワークが制限された環境でも使えます。プライベートなコードを扱う場合も、すべてのコンテキストをクラウドモデルに送るより受け入れやすいでしょう。

一方で代償もあります。ローカルモデルはハードウェアとモデル品質に大きく左右されます。小さいモデルでも簡単な修正、説明、スクリプト生成はできますが、大規模な複数ファイルリファクタリングや細かな設計判断では能力差が出やすくなります。

体験の限界

この構成は、Claude の強力なクラウドモデルを完全に置き換えるものとして考えるべきではありません。

次のような問題に遭遇する可能性があります。

長いコンテキストの理解が弱い。
複雑なタスクでツール呼び出しが不安定になる。
CPU のみの環境では推論が遅い。
存在しないファイルパスや API を幻覚しやすい。
複数ターンの計画が安定しにくい。
大規模リポジトリのリファクタリング成功率が低い。

したがって、期待値としては「無料で使えるローカル開発アシスタント」が現実的です。トップクラスのクラウドモデルの完全な代替ではありません。

マルチモーダル互換性はまだ不安定

Claude Code にスクリーンショット、UI 画像、図、その他のマルチモーダル入力を扱わせたい人もいます。この部分はローカルモデルと転送レイヤーの対応状況に依存します。

選んだ Ollama モデルが画像入力に対応していない場合、または CC Switch がリクエスト形式を正しく変換できない場合、マルチモーダル機能は失敗する可能性があります。Vision モデルを使っても、公式 Claude API と同じ挙動になるとは限りません。

現時点では、この構成はテキストとコードのワークフロー向きです。マルチモーダル対応は実験的なものとして扱うのがよいでしょう。

試す価値がある人

この構成は次のような人に向いています。

Claude Code のワークフローを低コストで試したい開発者。
スクリプト、小さなツール、自動化をよく書く人。
コードをできるだけローカルに残したいチーム。
API コストを気にせず AI コーディングアシスタントを学びたい初心者。
さまざまなローカルコードモデルを検証している人。

長いコンテキスト、大規模 monorepo、厳密なコードレビュー品質、複雑なプロジェクト全体のリファクタリングに強く依存する場合は、まだ安定性が足りないかもしれません。

使い方のおすすめ

まずは小さなタスクから始めましょう。

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

1 つのファイルを説明させる。
小さな関数をリファクタリングする。
shell スクリプトを生成する。
単純なエラーを修正する。
小さな機能を追加する。
狭いモジュールに単体テストを追加する。

変更後は、自分でテストを実行するか、少なくとも diff を確認してください。ローカルモデルは便利ですが、生成された編集をすべて無条件に受け入れるべきではありません。

モデルがよくコンテキストを見失う場合は、タスク範囲を小さくします。「プロジェクト全体をリファクタリングして」ではなく、「この関数をリファクタリングして」や「このファイルにバリデーションを追加して」のように依頼すると安定しやすくなります。

まとめ

Claude Code + CC Switch + Ollama はかなり面白い組み合わせです。Claude Code の Agent 的な開発体験を保ちつつ、モデル推論をローカルへ移せます。

大きな利点は、コストの低さ、データのプライバシー、扱いやすい開発ワークフローです。一方で、モデル品質、ハードウェア性能、長いコンテキスト、ツール呼び出しの安定性が体験を左右します。

すでに Ollama を使っていて、より実践的なローカル AI コーディング環境が欲しいなら、この構成は試す価値があります。ただし小さな作業から始め、すべての変更を確認し、ローカルモデルを自動エンジニアではなくアシスタントとして扱うのが安全です。

Prompt-Vault：AI コーディング能力を測るための prompt 仕様集

Fri, 15 May 2026 09:00:52 +0800

w512/Prompt-Vault は小さいが有用な prompt リポジトリだ。万能の呪文を集めるのではなく、実行可能な coding prompt を難易度別に整理し、LLM や coding agent のテストに使えるようにしている。

プロジェクト：https://github.com/w512/Prompt-Vault

構造は Easy、Medium、Hard の三つ。各 Markdown ファイルが独立したタスクだ。README も、これらは大規模言語モデルのテストや練習プロジェクトに向くと説明している。

prompt スクラップブックではない

多くの prompt 集は数が多くても品質を判断しにくい。見出しは魅力的でも、受け入れ基準が足りない。

Prompt-Vault は仕様集に近い。各タスクは、作るアプリ、必須機能、UI スタイル、技術制約、単一ファイル実行か、外部依存の可否、永続化の有無を明確にしようとしている。

これは「きれいな看板を作って」よりもモデル評価に向いている。モデルが要件を理解しているかが見えるからだ。

Easy：基本的なインタラクション

Bubble_Sort_Visualizer.md は、単一 index.html でバブルソートを棒グラフ表示する。開始、リセット、速度スライダー、比較回数、ダークテーマが必要だ。

アルゴリズム状態を UI に結びつけられるか、アニメーションを制御できるか、リセットと実行状態を扱えるかを測れる。

ToDo_List.md は静的 HTML から始まり、タスク追加、完了状態、削除、カウンタ、Active / Completed 統計、localStorage を段階的に追加する。

単純だが、段階的にコードを進化させられるかを測るのに向いている。

Medium：状態とアニメーション

Sorting_Visualization.md は 6 種類のソートを同じページで扱う。Bubble Sort、Insertion Sort、Selection Sort、Merge Sort、Quick Sort、Heap Sort だ。

さらにアルゴリズム選択、速度、配列サイズ、リセット、開始 / 一時停止、統計パネルも必要になる。

ひとつのバブルソートは書けても、複数アルゴリズム、停止再開、統計を合わせると状態管理の弱点が出やすい。

Hard：製品としての完成度

Kanban_Board.md は、列追加、改名、空列削除、カードのタイトルと説明、優先度、期限、ドラッグ、検索、フィルタ、localStorage、統計、ダークな glassmorphism、横スクロール対応を求める。

これは単機能ではなく、製品としての完成度を測る prompt だ。

Markdown_Editor_Desktop.md は Tauri 2 のクロスプラットフォーム Markdown エディタを求める。分割編集とプレビュー、同期スクロール、ライブレンダリング、保存、未保存表示、ツールバー、ショートカット、テーマ、Vue 3、Pinia、marked.js、prism.js、Tauri plugins などを含む。

Web ページを超えて、デスクトップアプリの設計力を測れる。

価値

Prompt-Vault の価値は数ではなく、再利用できる評価サンプルにある。

同じ prompt を複数モデルで使えば、制約を守るか、機能漏れが少ないか、境界状態を扱えるか、コードが保守しやすいか、UI 細部に強いかを比較できる。

これは「賢そうに感じる」よりずっと信頼できる。

フロントエンドタスクでは、失敗は構文エラーだけではない。ボタン状態、アニメーション停止、永続化、ドラッグ対象、統計更新など、体験の細部が評価になる。

拡張案

より本格的な benchmark にするなら、受け入れチェックリスト、失敗ケース、採点軸、参照実装、モデル別の結果記録を追加できる。

たとえばソート可視化には「Start / Reset を連打しても複数ループが走らない」などのチェックを入れるとよい。

使い方

AI コーディングツールを試すなら、prompt をそのまま渡し、追加ヒントなしで出力を実行する。機能ごとに確認し、漏れと bug を記録し、一度だけ修正させる。最後に時間、token コスト、コード品質を比べる。

まとめ

Prompt-Vault は軽量な prompt 仕様集だ。AI コーディングのテストにも、フロントエンド練習にも使える。

良い prompt は願望ではなく、要件、制約、インタラクション、状態、受け入れ基準、実行方法を書くものだと教えてくれる。

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

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

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

それが Token Efficiency の価値だ。

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

DeepSeek V4 の位置づけ

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

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

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

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

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

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

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

最強モデルにすべてをさせない

従来は最も賢いモデルに、要件分析、実装、テスト、まとめを全部任せがちだった。

しかし多くの作業は最高レベルの推論を必要としない。高価なモデルは、重要な判断点だけに出る consultant、architect、planner のように使うべきだ。

大モデルは問題分解と重要判断。
小モデルは実行、バッチ処理、反復修正。
tool と harness はプロセス、状態、コンテキスト、検証。
人間は製品定義、受け入れ、取捨選択。

これで最先端推論を機械的な実行に浪費しにくくなる。

コンテキストは大きければよいわけではない

coding agent では、コード、文書、会話履歴、テスト出力、ログがコンテキストを消費する。上限に近づくと圧縮、忘却、誤判断が起きやすい。

しかし長いコンテキストは、すべてを詰め込んでよいという意味ではない。

各タスクは、必要ファイル、判断に関係する文書、現在段階に必要な履歴、明確な入出力、次ノードへ渡す構造化要約だけを持つべきだ。

安い context は無関係な情報を入れたくさせる。だがノイズはモデルを賢くしない。

Harness が単体モデルより重要

Claude Code、Codex、その他の coding agent を安いモデルにつなぐだけでは十分ではない。小モデルは長いタスクでずれやすく、強いプロセス制御が必要だ。

harness は調度システムであり、タスク分割、ノード実行、モデル選択、結果検証、失敗時の再試行、コンテキスト受け渡しを決める。

この層がなければ、小モデルは安いだけだ。この層があると、小モデルはレバレッジになる。

DAG でタスクを分ける

複雑なタスクは DAG に分けられる。たとえば機能開発は、要件確認、技術設計、タスク分解、実装、テスト補完、Code Review、修正、PR 提出にできる。

各ノードは独立した agent にできる。役割、prompt、tool 権限、出力形式を分け、長い会話ではなく構造化結果を渡す。

これによりノードは短くなり、小モデルで完了しやすくなり、どこが失敗しているかも測りやすくなる。

タスクは複数回走らせてもよい

token が十分安ければ、同じタスクを一度だけ走らせる必要はない。異なるモデル、prompt、編成で複数回走らせ、最良の結果を選ぶ、または有用部分を統合できる。

向いているのは設計案、文章、テストケース、bug 仮説、リファクタリング案、Code Review だ。共有状態を変える作業や外部副作用がある作業には向かない。

目的は運試しではなく、比較可能なサンプルを得て、編成とモデル選択を改善することだ。

評価体系が必要

Token Efficiency は価格だけでは測れない。安くても失敗率が高ければ、人間の時間を食って高くつく。

タスク完了率、人間の介入回数、tool call 失敗率、テスト通過率、review 指摘数、タスクごとの token コスト、時間、手戻り回数、モデル組み合わせの差を記録する。

このデータがあって初めて、小モデルでよい作業、大モデルが必要な作業、人間が判断すべき作業を分けられる。

業務フローを原子化する

全員が harness を自作する必要はない。しかし自分の業務を原子ノードに分解することは今からできる。

コンテンツ制作なら、企画、調査、アウトライン、初稿、ファクトチェック、スタイル調整、SEO タイトル、多言語翻訳、公開チェック。

ソフトウェア開発なら、要件確認、技術設計、データ構造、API 変更、単体テスト、実装、移行スクリプト、文書、Review。

各ノードは入力、出力、受け入れ条件、コンテキストを明確にする。harness が成熟すれば、そのまま接続できる。

ハードウェアは最優先ではない

Token Efficiency の話はすぐローカルデプロイや GPU に向かう。しかし多くの人にとって最初の選択は API でよい。

経済モデルが通る前に高価なハードを買うのは、コストの前払いにすぎない。まず API で workflow を通し、評価とコストを記録し、高頻度の実行ノードを見つけてから、ローカル化を検討すべきだ。

まとめ

Token Efficiency の本質は、高いモデルを安いモデルで置き換えることではない。AI workflow を設計し直すことだ。

大モデルが重要判断をし、小モデルが大量実行し、harness が調度と検証を行い、人間が目標と受け入れを決める。この四層が揃って初めて token は生産性に変わる。

将来の差は、最強モデルを呼んだかではなく、同じ token でどれだけ現実の成果を出せるかに現れる。

Superpowers：Coding Agent を工学プロセスへ戻す skills フレームワーク

Fri, 15 May 2026 08:53:17 +0800

obra/superpowers は coding agent 向けの skills フレームワークであり、ソフトウェア開発方法論でもある。目的は万能 prompt を増やすことではなく、agent に流れを守らせることだ。目標を確認し、設計を作り、計画に分解し、TDD で実装し、レビューして終える。

プロジェクト：https://github.com/obra/superpowers

執筆時点で GitHub API では 19 万 star を超え、MIT ライセンスで、最近も更新されている。README は An agentic skills framework & software development methodology that works. と説明している。

解決したい問題

多くの AI コーディングツールの問題は、コードを書けないことではなく、すぐコードを書き始めることだ。

ユーザーが曖昧な要望を言うと、agent はファイルを編集し、見た目は完成する。しかし境界、テスト、アーキテクチャは不明確なまま残る。小さな作業ならよいが、複雑なプロジェクトでは手戻りと技術的負債になる。

Superpowers は、コードに触る前に agent を workflow に入れる。

何かを作りたいと分かったら、まず目標を質問する。
会話を仕様にし、区切って確認する。
設計が通ったら、実装計画を作る。
ユーザーが “go” と言ってから実装する。
実装では TDD、YAGNI、DRY、レビューを重視する。

これは新しい工学ではない。速い agent ほど、こうしたガードレールが重要になる。

対応ツール

Superpowers は単一の agent に縛られない。README には Claude Code、Codex CLI、Codex App、Factory Droid、Gemini CLI、OpenCode、Cursor、GitHub Copilot CLI が挙げられている。

つまり特定モデルのテクニックではなく、複数の harness で使える workflow 層に近い。

基本 workflow

最初は brainstorming。実装前に粗いアイデアを実行可能な設計へ変え、ユーザーに確認する。

次に using-git-worktrees。設計後、隔離された worktree とブランチを作り、インストールとテストの基線を確認する。

次は writing-plans。設計を小さなタスクに分け、ファイルパス、変更範囲、検証手順を明確にする。

実装段階では subagent-driven-development で subagent に渡すことも、executing-plans で順に実行することもできる。重要なのは各タスクが確認可能で review 可能なことだ。

その後 test-driven-development によって、本当の RED-GREEN-REFACTOR を行う。失敗するテストを書き、失敗を確認し、最小実装で通し、リファクタリングする。

さらに requesting-code-review でタスク間の review を行う。Critical な問題は進行を止める。

最後に finishing-a-development-branch でテストを確認し、merge、PR、worktree の保持や破棄を選ぶ。

Skills Library

テスト系は test-driven-development が中心だ。

デバッグ系には systematic-debugging と verification-before-completion がある。再現、最小化、仮説、検証、修正を求め、検証なしに完了と言わない。

協調系には次がある。

brainstorming
writing-plans
executing-plans
dispatching-parallel-agents
requesting-code-review
receiving-code-review
using-git-worktrees
finishing-a-development-branch
subagent-driven-development

メタ skills には writing-skills と using-superpowers がある。組み合わせると、agent に「いつ質問し、いつ計画し、いつテストし、いつ止まって review するか」という習慣を与える。

普通の prompt との違い

普通の prompt は、ルールを system prompt に積み上げがちだ。勝手に変更するな、先に考えろ、テストしろ、簡潔に説明しろ。ルールが増えるほど、複雑なタスクでは忘れられやすい。

Superpowers はルールを段階ごとの workflow モジュールに分ける。各 skill は短く、目的が集中している。agent は今の段階で何をすべきかを理解しやすく、複雑な流れも検査しやすい。

学べる点は、賢いモデルだけを追うのではなく、モデルに繰り返し可能な働き方を与えることだ。

向いている場面

Superpowers は、実プロジェクトで coding agent を使う開発者に向いている。複数ファイルの変更、設計してから実装したい場合、TDD や検証が必要な場合、複数ブランチや worktree を扱う場合、subagent に実装や review を任せたい場合に特に有効だ。

一行の設定変更には重いかもしれない。しかし多段階の開発では、その制約が価値になる。

注意点

これは自動操縦ではない。プロセスは与えるが、要求、トレードオフ、最終受け入れは人間が持つ。

TDD と review は初期コストを増やす。小タスクでは遅く感じるが、複雑なタスクでは手戻りを減らす。

subagent の並列化は常に良いわけではない。境界と書き込み範囲が明確なときに効く。要件が曖昧なら、並列化は混乱を増やす。

まとめ

Superpowers の価値は、coding agent を「依頼を受けたらコードを書く」状態から、ソフトウェア工学プロセスへ戻すことにある。

AI コーディングに足りないのは生成速度ではなく、確認、計画、検証、review、終了処理であることが多い。モデルが強くなるほど、これらを省いてはいけない。

Codex、Claude Code、Cursor、Gemini CLI を実プロジェクトで使っているなら、Superpowers は調べる価値がある。直接使わなくても、skills の分け方は自分の agent workflow を設計する参考になる。

Vibe Coding を拒む：Matt Pocock の skills リポジトリが AI コーディングに工学的制約を足す

Fri, 15 May 2026 08:46:23 +0800

AI がコードを書く速度が上がるほど、プロジェクトが崩れる速度も上がり得る。問題はモデルが関数を生成できるかではなく、要件を理解し、チームの言葉に従い、既存アーキテクチャの中で小さく進められるかだ。

Matt Pocock が公開した mattpocock/skills は、vibe coding とは逆の方向を示している。AI に開発プロセス全体を任せるのではなく、成熟したソフトウェア工学の制約の中に置く。

プロジェクト：https://github.com/mattpocock/skills

これは魔法の prompt ではない。要件確認、ドメインモデリング、TDD、診断、アーキテクチャレビューを、AI agent が使いやすい workflow にした skills の集合だ。

まずアラインメント失敗を防ぐ

AI コーディングで最も多い失敗は、モデルが理解したと思ったら、実は曖昧な説明から推測していただけ、というものだ。

grill-me はこれを反転させる。コードを書く前に、AI を厳しいレビュアーにし、分岐、境界、未決事項を質問させる。

たとえば「ログインページを作って」と頼んだら、先に聞くべきことは次のようなものだ。

パスワード忘れはどう扱うか
外部ログインをサポートするか
ログイン失敗時のエラー表示はどうするか
アカウントロック、CAPTCHA、リスク制御は範囲内か
成功後はどこへ遷移するか

この段階は遅く見えるが、後の手戻りを減らす。コード生成が安くなるほど、曖昧な要件のコストは大きくなる。

ドメイン言語をコンテキストに入れる

次の問題は汎用語彙だ。モデルはチーム内の業務用語を知らないため、変数名、関数名、ドキュメントの言葉がずれていく。

grill-with-docs は質問しながら、CONTEXT.md、ADR、ドメイン文書を確認する。確認済みの用語、境界、判断は、再利用できるコンテキストとして残せる。

これはドメイン駆動設計のユビキタス言語に近い。チームが user ではなく customer、order ではなく transaction と呼ぶなら、AI もその言葉を使うべきだ。

コンテキスト文書の価値は、情報量ではなく推測を減らすことにある。

TDD で生成速度を制御する

AI の危険は速さにある。昔は悪いコードを大量に書くにも時間がかかったが、今は数秒で数百行が出る。問題は速さそのものではなく、フィードバックループがないことだ。

tdd skill は RED-GREEN-REFACTOR を戻す。

ひとつの振る舞いに対して失敗するテストを書く。
そのテストを通す最小実装を書く。
リファクタリングする。
次の縦スライスへ進む。

重要なのは、ひとつずつ進めることだ。AI は実行し、人間は方向と境界を確認する。

診断ループで複雑な問題を扱う

バグに出会うと、多くの agent は答えを推測し、何度も修正して問題をさらに複雑にする。

diagnose は先にフィードバックループを作らせる。

再現する
最小化する
仮説を立てる
観測やログを足す
修正する
回帰テストを足す

古い方法だが、AI コーディングでは特に重要だ。AI は試行が得意だが、根因に近づいているかを判断するにはレールが必要になる。

アーキテクチャを定期的に見る

単発のタスクが通っても、コードベースが良くなったとは限らない。AI の小さな変更が積み重なると、モジュール境界がぼやけ、インターフェイスが複雑になり、テストしづらくなる。

improve-codebase-architecture のような skill は、現在のタスクから離れて全体を見る。

責務が混ざっているモジュールはどこか
複雑すぎるインターフェイスはどれか
テストしづらい経路はどこか
ドメイン言語と合わない命名はどれか
収束すべき重複ロジックはどれか

これは自動で大規模リファクタリングするためではない。構造化された観察と改善方向を出し、人間が判断するためのものだ。

制限すべきは自由度

この方法論の核心は単純だ。AI コーディングはモデルを自由に走らせることではなく、明確な目標、コンテキスト、テスト、停止条件を与えることだ。

人間は問題定義、アーキテクチャ境界、業務上の取捨選択、受け入れ基準を担当する。AI はコード生成、テスト補完、反復修正、局所的なリファクタリングを担当する。

AI が強くなっても、ソフトウェア工学の基礎は古くならない。要件整理、ドメイン言語、TDD、診断、アーキテクチャレビューは、むしろ重要になる。

コードを書ける人は増える。差がつくのは、AI を保守可能で検証可能な工学体系に組み込めるかどうかだ。

cc-haha とは？Claude Code をデスクトップ作業台にするプロジェクト

Thu, 14 May 2026 22:38:04 +0800

cc-haha は、Claude Code のワークフローを中心に改造されたプロジェクトです。正式なリポジトリ名は NanmiCoder/cc-haha です。プロジェクトページでは、2026-03-31 に Anthropic npm registry から流出した Claude Code のソースコードを修復したものをベースにしており、現在の主な形はデスクトップ版 Claude Code ワークベンチだと説明されています。

プロジェクト URL：https://github.com/NanmiCoder/cc-haha

この説明には重要な点が 2 つあります。

1 つ目は、これは Anthropic 公式の Claude Code ではないということです。README でも、元のソースコードの著作権は Anthropic にあり、学習と研究目的に限ると明記されています。

2 つ目は、今の重点が単なる「Claude Code CLI をローカルで動かすこと」ではないということです。README と最新 release を見ると、cc-haha は Claude Code のセッション、プロジェクト、権限、Diff、Computer Use、リモートアクセス、モデルプロバイダー設定をまとめるデスクトップアプリに近いものになっています。

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

Claude Code はもともとターミナル寄りのツールです。セッション、コマンド実行、権限確認、ファイル編集、コンテキスト切り替えはターミナル内で行われます。CLI に慣れた人には問題ありませんが、長く使うといくつか不便な点が出てきます。

複数のプロジェクトやセッションを同時に管理しづらい。
AI がどのファイルを変更したかを見るには、Git やエディタに切り替える必要がある。
権限承認、コマンド実行、ファイル Diff が別々の画面に分散する。
スマホや別端末から現在のセッションを見たい場合、追加の仕組みが必要。
Anthropic 以外のモデルを使うには、プロトコル互換を自分で処理する必要がある。

cc-haha は、これらをグラフィカルなワークベンチとしてまとめようとしています。Claude Code に見た目を付けただけではなく、「セッション管理」と「ローカル開発フローの制御」をデスクトップ側に移しています。

デスクトップワークベンチ：ターミナルからコントロールセンターへ

README によると、cc-haha のデスクトップ版は macOS / Windows App の中に次の機能を集約しています。

複数セッションのワークベンチ：タブ、プロジェクト切り替え、ターミナル入口、セッション履歴でタスクを管理。
ブランチ / Worktree 起動：新しいセッションでリポジトリブランチを選び、現在の作業ツリーか隔離 Worktree かを選択。
右側のコード変更パネル：チャットしながら変更済みファイル、追加削除行、ワークスペース状態を確認。
コード変更の可視化：AI による編集、Diff、実行過程を表示。
権限と確認フロー：危険なコマンド、ツール呼び出し、AI の確認質問をデスクトップで承認。
複数モデルプロバイダー：Anthropic 互換 API、第三者モデル、WebSearch fallback、ローカル設定をサポート。
H5 リモートアクセス：一度きりの token でスマホや別端末から現在のデスクトップセッションへ接続。
IM 連携：Telegram、Feishu、WeChat、DingTalk からリモート対話、プロジェクト切り替え、権限承認。
スケジュールタスクと token 使用量：デスクトップで計画タスクを作成し、ローカル token 使用傾向を確認。

これらの機能を見ると、単なるコマンドライン代替ではなく「AI コーディングワークベンチ」に近いことがわかります。チャット、ファイル変更、権限、プロジェクト、リモート入口、モデル設定を同じ場所に置こうとしているわけです。

インストールと起動方法

一般ユーザーは Releases からデスクトップ版インストーラーをダウンロードするのが向いています。

README のデスクトップ版インストール手順は次の通りです。

GitHub Releases から macOS または Windows のインストーラーをダウンロードする。
初回起動後、デスクトップ設定でモデルプロバイダー、API Key、デフォルトモデルを設定する。
macOS でアプリを開けないと表示された場合は、インストールガイドに従って Gatekeeper 権限を処理する。

最新 release ページでは、v0.2.6 が 2026-05-13 に公開されています。このバージョンは主に H5 モバイルアクセスの安全な復旧、デスクトップセッション管理、ファイル mention 検索、デスクトップ体験の細部改善を扱っています。

ソースから CLI を起動したい場合、README には次のコマンドが示されています。

1
2
3

bun install
cp .env.example .env
./bin/claude-haha

この方法は、低レベル CLI、サーバー、自前の開発を調べたい人向けです。普通に使うならデスクトップ版のほうが直接的です。

v0.2.6 の変更点

v0.2.6 の重点は、H5/LAN アクセスを一時的な開放状態から、明示的な有効化と token ペアリングモデルへ戻したことです。

注目点は次の通りです。

H5/LAN アクセスはローカルで明示的に有効化する必要がある。
QR リンクには一度だけ表示される token が含まれる。
リモート API、proxy、WebSocket は裸で公開されなくなった。
Settings に独立した H5 Access ページが追加された。
デスクトップのサイドバーに複数選択とセッション削除のための一括管理モードが追加された。
デスクトップのファイル mention 検索が git-first になり、ignore ルールを守り、node_modules やビルド成果物のノイズを減らす。
ピュアホワイトテーマが追加され、長い URL がチャットレイアウトを壊す問題や、複数 tab 間で下書きが混ざる問題が修正された。

これは、プロジェクトが「動く」段階を越えて、デスクトップ製品として必要な安全境界と日常的な使い勝手を補い始めていることを示しています。

特に H5 アクセスについて、作者は release で明確に注意しています。H5 は個人または信頼できるチーム向けのブラウザアクセス入口であり、公開マルチテナントログインシステムではありません。実際に使うときは、インターネットに公開する SaaS 管理画面のように扱うべきではありません。

Computer Use：Agent にデスクトップを操作させる

cc-haha のもう一つの大きな特徴は Computer Use です。

プロジェクト文書によると、この機能は流出した Claude Code ソース内の Computer Use 内部実装を大きく改造したものです。公式実装は @ant/computer-use-swift や @ant/computer-use-input といった Anthropic 内部の非公開ネイティブモジュールに依存しており、公開入手できません。cc-haha は低レベル操作層を Python bridge に置き換え、pyautogui、mss、pyobjc などの公開ライブラリでシステム操作を実現しています。

Computer Use が対応する操作には次のようなものがあります。

スクリーンショット：screenshot、zoom
マウス：クリック、ドラッグ、移動、スクロール、カーソル位置取得
キーボード：文字入力、キー入力、キー長押し
アプリ：アプリ起動、ディスプレイ切り替え
権限：アプリ権限要求、許可済みアプリ一覧
クリップボード：読み取りと書き込み
その他：待機、バッチ操作

動作は「スクリーンショット - 分析 - 操作」のループです。

モデルがユーザーの依頼を受け取る。
screenshot を呼び出して画面を取得する。
モデルが視覚能力でボタン、入力欄、座標を識別する。
クリック、入力、アプリ操作ツールを呼び出す。
再度スクリーンショットを取り、結果を確認して次へ進む。

文書を見る限り、完全対応している主なプラットフォームは macOS で、Apple Silicon と Intel の両方を含みます。Windows / Linux は理論上可能ですが、pyobjc に関わるアプリ管理部分を各プラットフォーム向けに置き換える必要があり、現時点では完全対応ではありません。

実行要件は次の通りです。

Bun >= 1.1.0
Python >= 3.8
macOS Accessibility 権限
macOS Screen Recording 権限

この種の機能は強力ですが、権限リスクも高くなります。AI にデスクトップアプリを操作させる場合、必要なアプリだけを明示的に許可し、関係ないウィンドウに機密情報を開いたままにしないほうがよいです。

複数モデル接続：Anthropic 互換レイヤーを使う

cc-haha の通信基盤は引き続き Anthropic Messages API プロトコルです。プロジェクト文書では、LiteLLM をプロトコル変換プロキシとして使う方法が推奨されています。

基本構造は次の通りです。

`1`	`claude-code-haha ──Anthropic协议──▶ LiteLLM Proxy ──OpenAI协议──▶ 目标模型 API`

つまり、cc-haha は Anthropic Messages API リクエストを送り、LiteLLM がそれを OpenAI Chat Completions などの形式へ変換し、OpenAI、DeepSeek、Ollama、その他のモデルサービスへ転送します。

文書にある LiteLLM のインストール方法は次の通りです。

`1`	`pip install 'litellm[proxy]'`

その後、litellm_config.yaml で OpenAI、DeepSeek、Ollama などのモデルを設定できます。プロキシ起動後、.env または ~/.claude/settings.json に次を設定します。

ANTHROPIC_AUTH_TOKEN=sk-anything
ANTHROPIC_BASE_URL=http://localhost:4000
ANTHROPIC_MODEL=gpt-4o
ANTHROPIC_DEFAULT_SONNET_MODEL=gpt-4o
ANTHROPIC_DEFAULT_HAIKU_MODEL=gpt-4o
ANTHROPIC_DEFAULT_OPUS_MODEL=gpt-4o
API_TIMEOUT_MS=3000000
DISABLE_TELEMETRY=1
CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1

実用上の注意点もあります。

drop_params: true が重要です。Anthropic の thinking や cache_control などのパラメータは OpenAI API には存在しないためです。
Extended Thinking は Anthropic 固有機能なので、第三者モデルでは使えません。
Prompt Caching も Anthropic ネイティブの形では機能しません。
ツール呼び出しは Anthropic tool_use から OpenAI function calling へ変換されるため、複雑なツール呼び出しでは互換性問題が出る可能性があります。
ローカル Ollama の小さなモデルでは、このツール呼び出し中心の流れを安定して処理できない場合があります。

したがって、複数モデル接続は可能ですが、すべてのモデルで同じ体験になるわけではありません。cc-haha はモデルに対して、ツール呼び出し、コード理解、長いコンテキスト処理の能力をかなり要求します。

向いている人

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

Claude Code に慣れていて、デスクトップでセッション管理したい人。
複数のリポジトリ、ブランチ、AI セッションを同時に扱う人。
AI のファイル変更、Diff、ワークスペース状態を右側で直接見たい人。
Computer Use を試し、Agent にデスクトップアプリを操作させたい人。
Anthropic プロトコル経由で OpenAI、DeepSeek、Ollama などを接続したい人。
スマホや IM からリモートでセッション確認や権限承認をしたい人。

あまり向いていないのは次のような場合です。

安定した公式 Claude Code だけを使いたい。
流出ソースという背景や著作権の不確実性を受け入れられない。
ローカルツールに高いシステム権限を与えたくない。
企業のコンプライアンス、監査、公式サポートが必要。
API key、プロキシ、モデル互換、ローカルサービス設定に慣れていない。

リスクと境界

この話では機能だけでなく、リスクも扱う必要があります。

cc-haha の由来を考えると、これは普通のコミュニティ再実装プロジェクトではありません。README には、流出した Claude Code ソースコードをベースにしており、元のソースコードは Anthropic に帰属すると明記されています。これは著作権、コンプライアンス、長期保守の不確実性につながります。

また、Computer Use、H5 リモートアクセス、IM 連携、ローカル権限承認はいずれも高い権限を持つ機能です。便利であるほど、境界を明確にする必要があります。

信頼できないネットワークで H5 アクセスを開放しない。
token を長期公開ログイン資格情報として扱わない。
Agent に無関係な機密アプリを操作させない。
本番環境や企業コンプライアンス環境で安易に使わない。
第三者モデルプロキシ設定や API key を公開リポジトリに置かない。

AI コーディングツールの構造、デスクトップワークフロー、Computer Use 実装を学ぶ目的なら、とても参考になります。長期の本番ワークフローに入れるなら、先に法務、権限、セキュリティ、保守のリスクを評価すべきです。

まとめ

cc-haha で最も注目すべき点は、「Claude Code を再現できるか」ではありません。Claude Code 型の AI コーディングツールを、デスクトップワークベンチの形へ押し出していることです。

セッション、プロジェクト、Worktree、Diff、権限、リモートアクセス、Computer Use、複数モデルプロバイダー、スケジュールタスク、token 使用量統計が、1 つのデスクトップ体験にまとめられています。これは、AI コーディングツールの次の一歩が、モデル性能だけでなく、より完成度の高いワークフロー UI にもあることを示しています。

ただし境界も明確です。これは Anthropic 公式製品ではなく、出自に敏感な背景があり、高権限機能は慎重に扱う必要があります。公式 Claude Code を安易に置き換えるものとしてではなく、AI コーディングツールの進化方向を観察するプロジェクトとして見るのが適切です。

参考資料

GitHub リポジトリ：https://github.com/NanmiCoder/cc-haha
最新 Release：https://github.com/NanmiCoder/cc-haha/releases/tag/v0.2.6
Computer Use ドキュメント：https://github.com/NanmiCoder/cc-haha/blob/main/docs/computer-use.md
第三者モデルドキュメント：https://github.com/NanmiCoder/cc-haha/blob/main/docs/guide/third-party-models.md

Codex /goal vs Claude Code /goal：長いタスクを完了条件まで自動で進める

Thu, 14 May 2026 22:25:31 +0800

/goal は、AI コーディングツールにおける重要なコマンドになりつつあります。

これは「モデルにもう少しコードを書かせる」ためのものではありません。より実用的な問題、つまりタスクに明確な完了条件があるとき、毎ターン止まってユーザーの「続けて」を待つのではなく、Agent が条件を満たすまで進み続けられるか、という問題を扱います。

Codex CLI はすでに公式ドキュメントで実験的な /goal を追加しています。Claude Code も独自の /goal ドキュメントを公開し、複数ターンにまたがって作業を続けられる自動化機能として説明しています。名前は同じですが、プロダクトとしての方向性は完全には同じではありません。

`/goal` は何を解決するのか

通常の AI コーディング対話は、だいたい「一問一答」です。

ユーザーがタスクを出す。
Agent が分析し、コードを変更し、テストを実行する。
Agent が結果を報告する。
ユーザーが次の行動を決める。

この流れは短いタスクには向いています。しかし移行、リファクタリング、テスト修正、issue backlog の整理になると、かなり細切れになります。Agent は少しだけ進めて、また「続けて」と入力されるのを待つことがあります。

/goal の考え方は、タスクを「次に何をするか」ではなく「最終的にどんな状態なら完了か」に変えることです。たとえば：

`1`	`/goal 完成登录模块迁移，所有 auth 测试通过，lint 无报错`

この種の目標は長いタスクに向いています。テストが通る、ビルドが成功する、ファイル分割が終わる、キューが空になる、受け入れ条件を満たす、といった明確な終点があるからです。

Codex の `/goal`：実験機能で、現在のスレッドに紐づく

OpenAI の Codex CLI ドキュメントでは、/goal は実験機能として扱われています。デフォルトの安定機能ではなく、先に features.goals を有効にする必要があります。

有効化する方法は 2 つあります。

`1`	`/experimental`

または config.toml に追加します。

1
2

[features]
goals = true

有効化後は、次のように使えます。

`1`	`/goal Finish the migration and keep tests green`

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

/goal
/goal pause
/goal resume
/goal clear

OpenAI のドキュメントによると、Codex は goal を現在の active thread に付与し、より大きなタスクの進行中にその目標を追跡します。

ここで重要なのは、Codex /goal に対する公式ドキュメントの表現がかなり抑制的であることです。「長いタスクに実験的な目標を設定する」「現在のスレッドに目標を付与する」と説明していますが、Claude Code のドキュメントのように、各ターンの終了後に独立した evaluator が自動判定して次のターンへ進む、という説明まではしていません。そのため現時点では、Codex /goal は完全に安定した無人実行モードではなく、実験中の長期タスク向け目標メカニズムとして見るのがよさそうです。

Claude Code の `/goal`：完了条件で駆動する複数ターン実行

Claude Code の /goal ドキュメントはより明確です。ユーザーが completion condition を設定すると、Claude はその条件が満たされるまで複数ターンにわたって作業を続けます。

例：

`1`	`/goal all tests in test/auth pass and the lint step is clean`

Claude Code の仕組みは、おおまかに次のようなものです。

現在の turn が終わっても、すぐに制御をユーザーへ戻さない。
小さく高速なモデルが、目標条件がすでに満たされたかを確認する。
満たされていなければ、Claude が自動で次のターンを開始する。
満たされていれば、goal は自動で解除され、transcript に完了状態が記録される。

つまり Claude Code の /goal は、「完了条件を満たすまで自動で続ける」機能に近いものです。単に会話へ目標を貼り付けるだけではなく、「次のターンへ進むかどうか」を独立した評価ステップに任せています。

Claude Code では、状態を直接確認することもできます。

/goal

状態には、目標条件、実行時間、評価済み turn 数、token 消費量、evaluator が最後に出した理由が表示されます。

途中で止めたい場合は、次を使います。

`1`	`/goal clear`

stop、off、reset、none、cancel も解除用の別名として使えます。目標を有効にした後でセッションが中断された場合でも、--resume や --continue で再開すると、active な goal を復元できます。ただし、経過時間、turn 数、token の基準値は再計算されます。

最大の違い

Codex と Claude Code はどちらも、AI コーディングを「単発の回答」から「長いタスクの実行」へ押し出しています。ただし /goal の位置づけには違いがあります。

比較項目	Codex CLI `/goal`	Claude Code `/goal`
状態	experimental	公式ドキュメントで単独ページとして説明
有効化	`features.goals` を有効化する必要がある	信頼済み workspace で直接利用可能
目標のスコープ	現在の active thread	現在の session
主な操作	set / view / pause / resume / clear	set / view / clear
自動判定	ドキュメントは目標の付与と追跡を強調	各ターン後に evaluator が判定すると明記
自動継続	公式表現は控えめ	条件未達なら自動で次のターンへ進む
向いている場面	Codex の長いタスクで目標コンテキストを維持したい場合	完了条件に向けて Claude Code に継続実行させたい場合

簡単に言えば、Codex の /goal は「現在のスレッドに実験的な長期目標を付ける」ものに近いです。Claude Code の /goal は「現在のセッションに検証可能な停止条件を設定し、満たされるまで自動で進める」ものに近いです。

よい `/goal` の書き方

どちらのツールでも、/goal は曖昧な願望を書く場所ではありません。

あまりよくない例：

`1`	`/goal 把项目优化一下`

よりよい例：

`1`	`/goal 将 payment 模块迁移到新 API，npm test -- payment 退出码为 0，git diff 只包含 payment 相关文件`

よい目標には通常、次の 3 つが含まれます。

明確な完了状態。
実行可能な検証方法。
守るべき境界。

目標が大きい場合は、停止条件も加えるべきです。

`1`	`/goal 修复 eslint 报错，npm run lint 退出码为 0；如果超过 20 轮仍未完成，停止并总结剩余问题`

これは重要です。/goal が強力になるほど、境界が必要になります。そうしないと Agent は「完了」を追い求めて、過剰にファイルを変更したり、長く走りすぎたり、token を使いすぎたり、本来なら質問すべき問題をそのまま進めてしまう可能性があります。

`/goal` が向いている場面

向いているもの：

テスト修正：指定したテストが通るまで。
コード移行：すべての呼び出し箇所を変更し、コンパイルが成功するまで。
一括整理：特定の lint や型エラーがゼロになるまで。
ドキュメント補完：指定したすべてのモジュールに説明が付くまで。
issue キュー処理：特定タグの issue が処理済み、または明確に分類されるまで。

向いていないもの：

要件自体がまだ曖昧。
頻繁なプロダクト判断が必要。
高リスクな削除、データ移行、権限変更を含む。
受け入れ条件が主観でしか判断できない。
大量の無関係なモジュールをまたぐ。

実用的な基準は、「どのコマンドを実行し、どんな結果を確認し、どのファイルに触れてはいけないか」を書けるなら /goal に向いている、ということです。「もっとよくして」としか書けないなら、通常の対話、計画モード、人間のレビューを使うほうが安全です。

AI コーディングツールへの影響

/goal は明確な方向性を示しています。AI コーディングツールは「対話型アシスタント」から「継続実行できる作業単位」へ移りつつあります。

以前は、Agent にタスクを任せるとき、ユーザーが近くで見守る必要がありました。詰まったら促し、テストが終わったら続行させ、エラーが出たらまた命令する。/goal はこのやり取りを完了条件に圧縮し、次のターンで何をするかを Agent 自身に決めさせます。

ただし、これはユーザー側への要求も高めます。これからの prompt はタスクを説明するだけでなく、受け入れ条件、検証コマンド、変更範囲、停止ルールも書く必要があります。言い換えると、ユーザーの仕事は「続けてと促す」ことから「何をもって完了とするかを定義する」ことへ移ります。

Codex と Claude Code が /goal に到達したということは、長いタスクを扱う Agent が、もはやバックグラウンドタスクやクラウドキューだけのものではないということです。ターミナル上のローカルなコーディングツールにも、より強い自律的な進行能力が求められ始めています。

まとめ

Codex CLI と Claude Code はどちらも /goal を持っていますが、現時点では同じ機能として単純に扱わないほうがよいです。

Codex の /goal はまだ実験機能で、features.goals を有効にする必要があり、現在の Codex スレッドで長期目標を維持する仕組みとして見るのが自然です。Claude Code の /goal は、「完了条件」と「自動継続」をより明確に結びつけ、独立した evaluator によって続行可否を判断します。

日常開発では、この種のコマンドは明確な受け入れ基準を持つエンジニアリングタスクに向いています。要件判断やコードレビューを置き換えるものではありませんが、長いタスクにありがちな「続けて」「もう一度実行して」「テストが通るまで直して」という繰り返しを減らせます。

本当に身につけるべきなのは、コマンドそのものではありません。タスクを、明確で、検証可能で、停止できる目標として書く力です。

参考資料

OpenAI Codex CLI Slash Commands：https://developers.openai.com/codex/cli/slash-commands
Claude Code Goal ドキュメント：https://code.claude.com/docs/en/goal

Codex は中国系 LLM とどう接続する？OpenAI 互換 API と CodexBridge の使いどころ

Wed, 13 May 2026 23:08:28 +0800

CodexBridge は、Codex CLI/SDK を OpenAI 互換の HTTP サービスとして公開するローカルブリッジです。これにより、これまでターミナル中心だった Codex を、OpenWebUI、Cherry Studio、スクリプト、自動化システム、または OpenAI Chat Completions 互換クライアントから呼び出せます。

中心となるエンドポイントは /v1/chat/completions と /v1/models です。前者は会話を処理し、通常の同期レスポンスと SSE ストリーミングをサポートします。後者は OpenAI 風のモデル一覧として利用できます。すでに OpenAI API に対応しているツールなら、基本的には base URL、API key、モデル名を変更するだけで済みます。

プロジェクト：https://github.com/begonia599/CodexBridge

向いている用途

CodexBridge は、Codex を既存の AI クライアントやワークフローに組み込みたい場合に向いています。たとえば：

OpenWebUI や Cherry Studio で Codex を直接選びたい。
curl、Python、Node.js などのスクリプトからローカル Codex を呼びたい。
1 つのフロントエンドから OpenAI、Ollama、他の互換 API、Codex を同時に扱いたい。
Codex のローカルスレッド、サンドボックス、作業ディレクトリ、承認ポリシーを維持したい。
社内ツールに統一された /v1/chat/completions 入口を提供したい。

これは新しい LLM ではなく、Codex CLI を完全に置き換えるフロントエンドでもありません。より正確にはアダプター層です。上流はあくまで Codex で、ブリッジが OpenAI 風のリクエストを Codex が扱える会話入力に変換します。

基本環境

必要なもの：

Node.js 18 以上。
インストール済みでログイン済みの Codex CLI。
npm。好みに応じて pnpm / yarn でも構いません。

ソースからの基本的なデプロイ手順：

git clone https://github.com/begonia599/CodexBridge
cd codexbridge
npm install
cp .env.example .env
cp .env .env.local

その後、.env または .env.local を編集し、API key、デフォルトモデル、作業ディレクトリ、サンドボックスモード、ネットワーク権限などを設定します。

HTTP サービスを起動します：

`1`	`npm run codex:server`

デフォルトポートは 8080 で、PORT で変更できます。起動後は次のエンドポイントを利用できます：

1
2
3

GET /health
POST /v1/chat/completions
GET /v1/models

CLI 会話モード

HTTP サービスのほかに、軽量な CLI も用意されています。

`1`	`npm run codex:chat`

CLI では自然言語を直接入力して Codex と対話できます。よく使うコマンドは次の 2 つです：

/reset: 新しい Codex スレッドを作成する。
/exit: CLI を終了する。

現在のスレッド ID は .codex_thread.json に保存されます。次回 CLI を起動したときにこのファイルが残っていれば、以前の会話を続けられます。

HTTP 呼び出し例

最小構成のリクエストは次のようになります：

curl http://localhost:8080/v1/chat/completions \
  -H "content-type: application/json" \
  -H "authorization: Bearer 123321" \
  -d '{"model":"gpt-5-codex:medium","session_id":"demo","messages":[{"role":"user","content":"ls"}]}'

注意点：

authorization の token は CODEX_BRIDGE_API_KEY と一致している必要があります。
model には gpt-5-codex:medium や gpt-5-codex:high のように推論レベルを付けられます。
session_id は会話を紐付け、同じ Codex スレッドを再利用するために使います。

ストリーミング出力が必要な場合は stream: true を追加します：

curl -N http://localhost:8080/v1/chat/completions \
  -H "content-type: application/json" \
  -H "authorization: Bearer 123321" \
  -d '{"model":"gpt-5-codex:high","session_id":"stream","stream":true,"messages":[{"role":"user","content":"Node.js プロジェクトの作り方を段階的に説明してください"}]}'

OpenAI のストリーミング応答に対応したクライアントなら、通常のチャットに近い体験になります。

セッション永続化

CodexBridge の重要な機能の 1 つがセッションマッピングです。リクエストでは次のフィールドからセッション ID を渡せます：

session_id
conversation_id
thread_id
user

ヘッダーから渡すこともできます：

x-session-id
session-id
x-conversation-id
x-thread-id
x-user-id

本番環境では次を有効にするのがおすすめです：

`1`	`CODEX_REQUIRE_SESSION_ID=true`

これによりすべてのリクエストにセッション ID が必須となり、別ユーザーや別チャットウィンドウの文脈が混ざるのを避けられます。ブリッジ側のマッピングは .codex_threads.json に保存されます。このファイルを削除するとブリッジ側の対応関係をリセットできますが、Codex 自体のスレッドは ~/.codex/sessions に残ります。

CODEX_REQUIRE_SESSION_ID=false でリクエストにセッション ID がない場合、ブリッジは現在の messages を一回限りの入力として Codex に渡します。これは一時的な呼び出しには便利ですが、長い会話には向きません。

マルチモーダル入力

CodexBridge は OpenAI 風の content block をサポートし、画像を Codex が扱える local_image 入力に変換します。

リモート画像：

{
  "type": "image_url",
  "image_url": {
    "url": "https://example.com/demo.png"
  }
}

ローカル画像：

{
  "type": "local_image",
  "path": "./images/demo.png"
}

リモートリソースは一時ディレクトリへダウンロードされ、ターン終了後に削除されます。実運用ではリクエスト本文のサイズに注意してください。特に画像を base64 で送る場合は、CODEX_JSON_LIMIT を増やす必要があるかもしれません。

構造化出力

クライアントが response_format に対応している場合、CodexBridge はそれを Codex の outputSchema にマッピングできます。チェック結果、要約、分類結果、自動化レポートなど、固定 JSON 構造を返したいときに便利です。

最小例：

{
  "model": "gpt-5-codex",
  "session_id": "lint",
  "response_format": {
    "type": "json_schema",
    "json_schema": {
      "name": "lint_report",
      "schema": {
        "type": "object",
        "properties": {
          "summary": { "type": "string" },
          "status": {
            "type": "string",
            "enum": ["ok", "action_required"]
          }
        },
        "required": ["summary", "status"],
        "additionalProperties": false
      }
    }
  },
  "messages": [
    {
      "role": "user",
      "content": "src/ の lint 問題を確認し、結果を JSON で返してください"
    }
  ]
}

type: "json_schema" では schema が必須です。ない場合、サービスは 400 を返します。

主な環境変数

よく使う設定は次のように分けられます。

サービスと認証：

1
2
3

PORT=8080
CODEX_BRIDGE_API_KEY=123321
CODEX_JSON_LIMIT=10mb

デフォルトモデル：

1
2

CODEX_MODEL=gpt-5-codex
CODEX_REASONING=medium

Codex 実行環境：

CODEX_WORKDIR=
CODEX_SANDBOX_MODE=read-only
CODEX_APPROVAL_POLICY=never
CODEX_SKIP_GIT_CHECK=true

ネットワーク機能：

1
2

CODEX_NETWORK_ACCESS=false
CODEX_WEB_SEARCH=false

フロントエンドチャット用途だけなら、デフォルトでネットワークを閉じておくほうが安全です。Codex に curl、git clone、Web 検索を明確に実行させたい場合だけ、対応するスイッチを有効にします。

Docker とインストールスクリプト

長時間常駐させたい場合は Docker 方式も使えます：

1
2

docker compose up -d
docker compose logs -f codexbridge

Linux 用のインストールスクリプトもあります：

`1`	`curl -fsSL https://raw.githubusercontent.com/begonia599/CodexBridge/master/scripts/install.sh \| bash`

このスクリプトは依存関係をインストールし、リポジトリを clone または更新し、.env.example をコピーして Docker Compose でサービスを起動します。sudo 権限が必要なので、クリーンなサーバーでの素早いデプロイに向いています。すでに複雑な Node.js、Docker、Codex 環境がある場合は、実行前にスクリプト内容を確認してください。

よくある問題

リクエストが 413 を返す

通常はリクエスト本文が大きすぎます。base64 画像でよく起きます。次を増やします：

`1`	`CODEX_JSON_LIMIT=20mb`

API key が無効と表示される

リクエストヘッダーに次があるか確認します：

`1`	`Authorization: Bearer <your CODEX_BRIDGE_API_KEY>`

または x-api-key を使います。

Codex が Git リポジトリ制限を報告する

実行ディレクトリが信頼済みリポジトリではない場合、Codex のチェックに引っかかることがあります。安全を確認した環境でのみ使ってください：

`1`	`CODEX_SKIP_GIT_CHECK=true`

会話をリセットしたい

ブリッジ側のマッピングは .codex_threads.json、Codex 自身のスレッドは ~/.codex/sessions にあります。サービスを停止して該当ファイルまたはディレクトリを削除すればリセットできます。

使い方のすすめ

ローカルで試すときは、まずデフォルト API key と read-only サンドボックスで流れを確認します。OpenWebUI、Cherry Studio、スクリプトから正常に呼び出せることを確認してから、CODEX_WORKDIR、CODEX_SANDBOX_MODE、CODEX_NETWORK_ACCESS、CODEX_APPROVAL_POLICY を段階的に調整します。

複数人で使う場合は、少なくとも次の 3 点を行うべきです：

session_id を必須にする。
デフォルト API key を変更する。
作業ディレクトリとサンドボックス権限を明確に制限する。

CodexBridge の価値は機能の多さではなく、Codex を既存の OpenAI 互換エコシステムに入れられる点にあります。クライアントが base URL を変更できるなら、Codex を通常のチャットモデルのように扱いつつ、ローカルスレッド、サンドボックス、ツール利用といった Codex 本来の機能を維持できます。

AI コーディングツールの今回の波で、なぜ DeepSeek がコスト削減の鍵になったのか

Mon, 11 May 2026 04:59:00 +0800

今回の AI コーディングツール競争は、表面上はモデル性能、プラグインエコシステム、agent 自動化の競争に見える。しかし実際に使い始めると、最初にぶつかる問題はコストだ。

Claude Code、Codex、OpenClaw、Superpowers はどれも便利だが、共通点がある。複雑なタスクに入ると、とにかく token を消費する。プロジェクトを読み、計画を作り、ツールを呼び出し、コンテキストを要約し、結果を何度も確認し、場合によっては複数のサブタスクを起動する。モデルが賢くなり、ワークフローが自動化されるほど、請求額も静かに膨らみやすい。

だから今回、DeepSeek が重要になっている。単にコードを書けるからではない。長いコンテキストとキャッシュコストが、AI コーディングツールで最もお金が燃える部分にちょうど効いているからだ。

Agent ツールはなぜ token を大量に消費するのか

従来のチャット型コーディング支援は、基本的に一問一答だ。関数の書き方を聞くと、コード片が返ってくる。この形でも token は消費するが、まだ制御しやすい。

Agent ツールは違う。質問に答えるだけではなく、一時的なエンジニアのようにプロジェクトへ入っていく。

まずディレクトリと重要ファイルをスキャンする；
要件と既存アーキテクチャを理解する；
計画を作る；
ファイルを修正する；
コマンドやテストを実行する；
エラーに応じて修正を続ける；
最後に変更内容をまとめる。

この過程では、モデルが同じコンテキストを何度も読む。プロジェクト説明、コード片、ツール結果、過去の会話、計画、エラーログが繰り返しコンテキストに戻される。少し複雑なタスクになるだけで、数十万 token はすぐに消える。

さらに攻めたプラグインを入れると、コストはもっと目立つ。OpenCode や Claude Code の拡張ツールの中には、デフォルトで agent チームを組むものもある。小さな機能を一つ変えたいだけでも、計画、レビュー、実行、振り返りまで起動することがある。タスクはより「賢く」見えるが、token も増え続ける。

Superpowers の利点は必要なときだけ起動すること

Superpowers のようなツールの利点は、すべてのタスクで完全な agent フローを強制しないことだ。

普段は Claude Code、OpenCode、Codex を従来の方法で動かせる。ブレインストーミング、計画作成、計画実行、振り返りのような skill を明示的に呼び出したときだけ、より重い自動化フローに入る。

これはコスト面で重要だ。

AI コーディングでは、すべてのタスクに重装備を使うべきではない。設定を一行変える、エラーを一つ調べる、小さなスクリプトを書く程度なら、普通の対話で十分だ。複雑なリファクタリング、複数ファイルの変更、長文ドキュメント処理、多段階の検証だけが、完全な agent フローに値する。

ツールが強力になるほど、起動条件を制御する必要がある。そうしなければ、自動化が増えるほど無駄も増える。

DeepSeek の重要な強みはキャッシュが安いこと

DeepSeek がこの種の agent ツールに合う大きな理由は、キャッシュヒット時のコストが低いことだ。

AI コーディングタスクには、大量の反復プレフィックスがある。プロジェクト背景、システムプロンプト、ツール説明、ファイル内容、前の会話ターンは、後続リクエストに何度も現れる。モデルサービスが prompt cache をサポートしていれば、こうした反復部分はキャッシュヒット後にかなり安くなる。

多くのモデルでは、キャッシュヒット価格は未ヒットより少し安い程度で、たとえば三分の一前後という感覚だ。DeepSeek の強みは、ヒット後の価格差がもっと大きくなり得ることにある。長いコンテキスト、多段階呼び出し、プロジェクトの反復読み込みを行う agent ワークフローでは、この差が請求に直接出る。

つまり DeepSeek は、毎回の回答が必ず最強というわけではない。しかし「長いタスク、多いターン、コンテキストの反復読み込み」という場面では、コスト構造が AI コーディングに非常に向いている。

長いコンテキストは Claude Code を使いやすくする

Claude Code や類似ツールを DeepSeek V4 に接続すると、もう一つの明確な利点が長いコンテキストだ。

AI コーディングツールが最も嫌うのは、コンテキスト不足だ。コンテキストが足りなくなると、頻繁に圧縮が必要になる。圧縮が増えると、前に読んだ細部が失われることがある。モデルはプロジェクト構造、制約、あるファイルをなぜ変更したかを忘れ始め、その後の品質が落ちる。

DeepSeek V4 系列の長いコンテキスト能力は、コードリポジトリ、ドキュメントの一括処理、字幕翻訳、サイト記事整理に向いている。特に Claude Code や OpenClaw に接続する場合、設定が適切ならコンテキスト圧縮を遅らせ、より多くのプロジェクト詳細を保てる。

だから DeepSeek で動かすと「よく持つ」と感じるタスクがある。各ステップが必ずしも派手ではなくても、長時間、低コスト、反復呼び出しに耐えられる。

V4 Pro と V4 Flash の分担

DeepSeek V4 Pro と V4 Flash は混ぜて使うべきではない。

単純なタスクには DeepSeek V4 Flash が向いている。速く、安く、次のような場面ではたいてい十分だ。

字幕翻訳；
ドキュメント整理；
普通のスクリプト生成；
小規模なコード修正；
OpenClaw の軽量タスク；
簡単なサイトコンテンツ処理。

複雑なタスクでは DeepSeek V4 Pro を検討する。

大規模リファクタリング；
複数モジュールのコード理解；
複雑な推論；
長い agent チェーンのタスク；
高リスクなコード変更；
より強い計画能力が必要なエンジニアリングタスク。

最初から最強モデルを使いたがる人は多いが、それは割に合わないことも多い。AI コーディングツールの現実的な使い方は、タスクを層に分けることだ。安いモデルに大量の定型作業を任せ、高いモデルは重要な判断点だけに使う。

MiniMax、Doubao、DeepSeek は役割が違う

国内モデルやプランの中で、MiniMax、Doubao、Kimi、DeepSeek にはそれぞれ位置づけがある。

MiniMax の強みは、量が多く、安く、機能が広いことだ。最も賢いコーディングモデルではないかもしれないが、翻訳、軽い整理、一括処理には費用対効果が高い。字幕の一括処理、形式変換、簡単な校正などには、MiniMax 型のプランはかなり使いやすい。

Doubao の強みは、ツールエコシステムが広いことだ。画像、動画、検索、TTS、場合によっては STT や embedding までつなげられる。総合ツールボックスに近い。

DeepSeek の位置づけはもっと明確だ。テキスト、コード、長いコンテキスト、低コストキャッシュ。画像生成、音声、動画の完全なエコシステムはなく、弱点ははっきりしている。しかし AI コーディングと長文 agent ワークフローでは、長所が十分に長い。

だから誰が誰を置き換えるという話ではない。タスクを分け、それぞれに合う道具を使う話だ。

コスト削減の鍵は安いモデルを探すだけではない

AI コーディングでコストを下げるとは、すべてのリクエストを安いモデルに替えることではない。

有効な方法はいくつかある。

単純なタスクで重い agent を起動しない。
Flash で十分なタスクに Pro を使わない。
長いタスクではできるだけキャッシュを使う。
反復コンテキストを安定させ、意味のない変更でキャッシュを無効化しない。
大きなタスクは安いモデルに下書きと一括処理をさせ、強いモデルで重要レビューを行う。
agent に、事実を繰り返し説明せず、同じことを何度も要約しないよう明確に伝える。

特に最後の点は重要だ。AI ツールは冗長になりやすい。冗長さは読みやすさだけでなく、コストの問題でもある。プロンプトに「事実は一度だけ説明し、意見は一度だけ述べる」と入れると、文章品質と token 消費の両方を改善できる。

DeepSeek に向く AI コーディングワークフロー

DeepSeek は次のようなタスクに特に向いている。

長いコードリポジトリの読解；
複数ファイルの軽い修正；
ドキュメントの一括整理；
字幕の一括翻訳；
Hugo 記事の整理；
agent 計画の実行；
大量の反復コンテキストを含む低コスト自動化。

すべてのタスクに向くわけではない。特に強いフロントエンドの審美眼、複雑なプロダクト判断、クロスモーダル制作が必要なら、Claude、GPT、Gemini、Doubao などを組み合わせる必要がある。

しかしタスクが「長文、長いコンテキスト、反復呼び出し、コスト敏感」である限り、DeepSeek は第一候補になりやすい。

まとめ

今回の AI コーディングツールの波で、DeepSeek の価値は「国内モデルがコードを書ける」ことだけではない。agent ツールの最も現実的な痛点、つまり長いタスクが高すぎる問題を解いていることにある。

Claude Code、OpenClaw、Superpowers のようなツールは開発フローをますます自動化する。しかしその裏側には、大量のコンテキスト読み書きと多段階呼び出しがある。この部分のコストを下げられる人が、AI コーディングを「たまに気持ちよく使うもの」から「毎日使えるもの」に変えられる。

DeepSeek の長いコンテキスト、低いキャッシュコスト、V4 Flash / V4 Pro の階層的な使い分けは、まさにその位置にある。

今回の本当のコスト削減の鍵は、良いモデルを使わないことではない。良いモデル、安いモデル、キャッシュ、agent フローをうまく組み合わせることだ。この会計を理解できれば、AI コーディングツールは美しいが高価なおもちゃではなく、本当の生産性になる。

AI Coding プランの選び方：ライトユーザーは使いやすさ、ヘビーユーザーは柔軟性

Sun, 10 May 2026 08:20:58 +0800

AI Coding のプランは、この半年でかなり速いペースで変わっています。多くのツールが「回数ベース」から「使用量ベース」に移行し、無料または低価格プランの枠は締まり、海外サービスの一部では本人確認、地域制限、より厳しい利用ルールも増えました。

開発者にとって問題は、もはや「どのモデルが一番強いか」だけではありません。毎月いくら払うのか、枠は十分か、ツールは使いやすいか、そしてプランが突然値上げされたりルール変更されたりしたときに、スムーズに乗り換えられるかも重要です。

実用的な結論としては、ライトユーザーは使いやすさを買い、中程度のユーザーはコストパフォーマンスを買い、ヘビーユーザーは柔軟性を買うべきです。使い方が重くなるほど、モデルとツールを一つのプランに固定しないほうがよくなります。

プラン選びで見るべき 4 つのポイント

以前の AI Coding プラン選びでは、通常は 3 つのことを見れば十分でした。

モデルの性能が十分に強いか。
応答速度が安定しているか。
プランの枠が足りるか。

今はこれに 4 つ目を加える必要があります。モデルとツールを分けて使えるかどうかです。

モデルは推論能力を担い、ツールはコンテキスト管理、ファイル編集、Agent の編成、ワークフロー体験を担います。どちらも重要ですが、完全に結びつけないほうが安全です。たとえば Claude 系モデルが好きなら公式プランを使ってもいいですし、API を別のツールに接続しても構いません。あるエディタや Agent ツールが気に入っているなら、それが自社モデルしか使えないのではなく、複数モデルをつなげられるかを見たほうがよいです。

ここで大事なのは、複雑にすること自体ではなく、リスクを減らすことです。AI Coding は業界の中でも変化が最も速い分野の一つです。今は枠が緩いプランでも、数か月後には課金方式が変わるかもしれませんし、今は使いやすいツールでも、モデル連携の変更で体験が落ちるかもしれません。モデルとツールを分けておくことは、移行の余地を残すことでもあります。

海外プランは全体として締まりつつある

GitHub Copilot、Cursor、Windsurf、Claude Code のようなツールは今でも多くの人の主力ですが、流れはかなり明確です。安くて枠が大きいプランは維持しにくくなり、使用量ベース課金が一般化しています。

GitHub Copilot のようなサービスが使用量課金を強めるほど、プランそのものの「割安感」は薄くなります。ライトユーザーにはまだ便利ですが、Agent、長いコンテキスト、複雑なコードタスクを高頻度で使う人にとっては、実際の消費は本物の API コストにかなり近づいていきます。

Cursor と Windsurf は、要するにモデル能力を IDE 体験にまとめているツールです。強みは導入のしやすさと成熟したエディタ体験ですが、弱みはツールへのロックインが強めなことです。専用 Agent、インデックス、自動化フローに依存するほど、後から移るコストは高くなります。

Claude Code は体験面でも注目度でも魅力がありますが、海外サブスクリプション、本人確認、地域制限、中継サービスの安全性は、中国国内のユーザーにとって無視できないリスクです。特に第三者の中継サービスは、モデルの混在、安定性不足、データ安全性、サービス終了といった問題を抱えやすく、重要な仕事の長期基盤には向きません。

国内プランの強みと弱み

国内の AI Coding プランの利点は、多くが API 形式で提供されているため、特定のツールに強く縛られにくいことです。OpenCode、Cline、Continue、自作スクリプト、社内 Agent などに接続できます。

一方で弱点もはっきりしています。モデルが強く、速く、枠も大きい、という条件を同時に満たすプランはあまり多くありません。

GLM 系は国内モデルの中では強い部類ですが、ピーク時間帯にはスループットが不安定になり、重いタスクでは速度が足かせになることがあります。Kimi も能力は高いですが、価格と枠のルールは継続的に確認が必要で、特にバックエンドの枠がどれだけ透明かが重要です。MiniMax のようなモデルは速度と枠の面では使いやすく、日常の軽いタスクやバッチ処理、比較的単純なコード支援に向いていますが、難しいエンジニアリング推論では一段落ちることがあります。DeepSeek の新モデルは、キャンペーン価格のうちは非常にコスト効率が高く見えることがありますが、終了後は通常価格で改めて評価し直す必要があります。

そのため国内プランは、一つの万能パッケージとして使うより、「モデルプール」として運用したほうが向いています。タスクごとにモデルを使い分けるほうが現実的です。

ライトユーザー：使いやすさを優先し、API 構築にこだわりすぎない

週に数回、AI にスクリプト修正、ドキュメント補完、エラー説明、小さなツール作成を頼む程度なら、複雑な構成は不要です。

このタイプのユーザーは、まず使いやすい製品を選ぶのが正解です。Cursor、Windsurf、Trae、CodeBuddy、通義霊碼、GitHub Copilot などはどれも試す価値があります。大切なのは最安値ではなく、摩擦が少ないことです。普段使うエディタで安定して動き、補完品質が悪くなく、失敗したときに戻しやすい。それで十分です。

少し安くするためだけに、多段の API、中継、複雑なプロキシ構成を組むのは、ライトユーザーにはあまりおすすめできません。時間コスト、アカウントリスク、トラブル対応の手間のほうが、節約額より大きくなりがちです。

中程度のユーザー：コスパだけでなく、移行しやすさも見る

毎日 AI を使ってコードを書き、プロジェクトを直し、テストを作り、ドキュメントを整理するようになると、枠と実際の消費量をより真剣に見る必要が出てきます。

このタイプのユーザーには、主力ツールと予備モデルを分けておく構成が向いています。たとえば、使いやすい IDE プランで日常の編集を行い、別に複数ツールへ接続できる API や集約プランを用意して、長いコンテキストや複雑な Agent タスクに使う、といった形です。

選ぶときに見るべきポイントは主に 3 つです。

外部ツールへ接続できるか。
token や枠の消費が見えるか。
超過時の挙動が、速度制限、機能劣化、停止、純粋な従量課金のどれか。

見た目は安くても、そのツールの中でしか使えないプランなら、移行コストまで含めて考える必要があります。逆に少し高くても複数ツールで使えるなら、長期的にはそちらのほうが主力に向く場合があります。

ヘビーユーザー：モデルとツールを固定しない

ヘビーユーザーにとっての核心は柔軟性です。

個人やチームが毎日大量に AI Agent を使うようになると、消費量はすぐ大きくなります。コードベース検索、長いコンテキストでの修正、多段のデバッグ、自動テスト修復などは、token 消費を一気に増やします。その状態で単一プランに依存すると、次の 3 つの問題が起きやすくなります。

枠が急に足りなくなる。
課金ルールが突然変わる。
あるツールやモデルが一時的に使えなくなる。

より安定したやり方は、層を分けた構成にすることです。主力 Agent ツールを一つ、差し替え可能なモデル接続先を一つ以上、軽い仕事をさばく低コストモデルを一つ、難しい仕事を担う高性能モデルを一つ、という形です。日常の軽い仕事を全部いちばん高いモデルに投げる必要はありませんし、重要な仕事を最安モデルだけに頼るのも危険です。

ヘビーユーザーにとっては、「どのツールにもモデルをつなげられる」「どのモデルも別ツールで使える」という柔軟性のほうが、月数十ドルの差額より重要です。本当に高いのはサブスク料金そのものではなく、一つのエコシステムに閉じ込められたあとで、ワークフローを作り直すコストだからです。

より安定した組み合わせ方

比較的安定した構成は、次のように考えられます。

軽いタスクは低コストモデルに任せる。コード説明、小さなスクリプト、整形、簡単な文書生成など。
中程度のタスクはコスパ重視モデルに任せる。通常の機能開発、テスト補完、リファクタリング提案など。
難しいタスクは強いモデルに任せる。複雑な設計変更、複数ファイルの修正、難しいバグ、長いコンテキスト推論など。
ツール層は開いておく。API 接続、設定の持ち出し、モデル切り替えができるツールを選ぶ。
予備ルートを残す。主力プランのルールが変わったときに、別のモデルやツールへすぐ切り替えられるようにする。

これが最安とは限りませんが、変化にはかなり強くなります。AI Coding の価格や枠は今後も変わり続けるはずです。長期的に価値があるのは、短期的にお得に見えるプランそのものではなく、持ち運びできるワークフローです。

まとめ

AI Coding のプランは、月額だけで判断すべきではありません。ライトユーザーはシンプルさと使いやすさを優先し、中程度のユーザーは枠、消費量、移行しやすさを見て、ヘビーユーザーはモデルとツールを切り離して単一エコシステムへの依存を避けるべきです。

覚えておきたいのは、プランもモデルもツールも変わる、ということです。選択権を自分の手元に残しておくことが、長く AI Coding を使ううえで最も重要なコスト管理になります。