AI Coding 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

おすすめは：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

`1`	`export ENABLE_PROMPT_CACHING_1H=1`

Windows PowerShellでは：

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

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

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

安定した流れはこうだ。

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

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

簡単な判断基準

次の一文で判断できる。

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

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

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

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

まとめ

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

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

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

参考資料

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

この批判には筋がある。

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

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

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

鍵は閉ループにある

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

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

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

この差は非常に大きい。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

まとめ

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

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

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

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

参考資料

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をよく使う人には有用です。たまにコードの質問をするだけなら、効果はそれほど大きくありません。

参考資料

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

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

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

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

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

Gemini 3.5 Pro が注目される理由

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

MCP ツール接続が示すもの

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

開発者にとっての意味

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

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

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

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

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

まとめ

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

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

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

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

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 コーディングツールは美しいが高価なおもちゃではなく、本当の生産性になる。

ProgramBench の生データ：モデル成績、コスト、200 件のタスク記録

Sun, 10 May 2026 12:42:41 +0800

ProgramBench は、AI のコーディング能力を評価する新しいベンチマークです。既存リポジトリ内の bug を修正させるのではなく、コンパイル済みの実行ファイルと利用ドキュメントを手がかりに、同じ振る舞いをするプログラムをゼロから再構築させます。

この記事はデータ整理を主目的とし、説明は最小限にしています。以下の表では、ProgramBench 公式サイトで公開されている生の記録データを保持し、後から引用・比較しやすい形にまとめます。出典は ProgramBench homepage、Extended Results、Task Instances です。取得時刻は 2026-05-10T12:42:41+08:00 です。

データの見方

Resolved：隠し行動テストを完全に通過したタスクの割合。
Almost resolved：行動テストの 95% 以上を通過したタスクの割合。
Cost：タスクインスタンス 1 件あたりの平均 API コスト。単位は米ドル。
Calls：タスクインスタンス 1 件あたりの平均 LLM 呼び出し回数。
すべてのモデルは mini-SWE-agent で評価され、タスク総数は 200 件です。

メインリーダーボード

#	Model	Provider	Agent	Resolved	Almost resolved	Run
1	Claude Opus 4.7	Anthropic	mini-SWE-agent	0%	3.0%	https://programbench.com/run/claude-opus-4-7/
2	Claude Opus 4.6	Anthropic	mini-SWE-agent	0%	2.5%	https://programbench.com/run/claude-opus-4-6/
3	Claude Sonnet 4.6	Anthropic	mini-SWE-agent	0%	1.0%	https://programbench.com/run/claude-sonnet-4-6/
4	GPT 5.4	OpenAI	mini-SWE-agent	0%	0.0%	https://programbench.com/run/gpt-5-4/
5	Gemini 3.1 Pro	Google	mini-SWE-agent	0%	0.0%	https://programbench.com/run/gemini-3-1-pro/
6	Gemini 3 Flash	Google	mini-SWE-agent	0%	0.0%	https://programbench.com/run/gemini-3-flash/
7	Claude Haiku 4.5	Anthropic	mini-SWE-agent	0%	0.0%	https://programbench.com/run/claude-haiku-4-5/
8	GPT 5.4 mini	OpenAI	mini-SWE-agent	0%	0.0%	https://programbench.com/run/gpt-5-4-mini/
9	GPT 5 mini	OpenAI	mini-SWE-agent	0%	0.0%	https://programbench.com/run/gpt-5-mini/

拡張結果

#	Model	Provider	Agent	Resolved	Almost resolved	Cost	Calls	Run
1	Claude Opus 4.7	Anthropic	mini-SWE-agent	0%	3.0%	$3.81	93	https://programbench.com/run/claude-opus-4-7/
2	Claude Opus 4.6	Anthropic	mini-SWE-agent	0%	2.5%	$11.38	260	https://programbench.com/run/claude-opus-4-6/
3	Claude Sonnet 4.6	Anthropic	mini-SWE-agent	0%	1.0%	$26.73	472	https://programbench.com/run/claude-sonnet-4-6/
4	GPT 5.4	OpenAI	mini-SWE-agent	0%	0.0%	$0.33	16	https://programbench.com/run/gpt-5-4/
5	Gemini 3.1 Pro	Google	mini-SWE-agent	0%	0.0%	$1.51	94	https://programbench.com/run/gemini-3-1-pro/
6	Gemini 3 Flash	Google	mini-SWE-agent	0%	0.0%	$0.30	85	https://programbench.com/run/gemini-3-flash/
7	Claude Haiku 4.5	Anthropic	mini-SWE-agent	0%	0.0%	$0.80	124	https://programbench.com/run/claude-haiku-4-5/
8	GPT 5.4 mini	OpenAI	mini-SWE-agent	0%	0.0%	$0.04	18	https://programbench.com/run/gpt-5-4-mini/
9	GPT 5 mini	OpenAI	mini-SWE-agent	0%	0.0%	$0.03	15	https://programbench.com/run/gpt-5-mini/

200 件のタスクインスタンス生データ

#	Repository	Description	Lang	Stars	Tests	Best Score	Task
1	junegunn/fzf	:cherry_blossom: A command-line fuzzy finder	go	79,721	1,874	81.9%	https://programbench.com/task/junegunn__fzf.b56d614/
2	jesseduffield/lazygit	simple terminal UI for git commands	go	76,901	855	56.4%	https://programbench.com/task/jesseduffield__lazygit.1d0db51/
3	BurntSushi/ripgrep	ripgrep recursively searches directories for a regex pattern while respecting your gitignore	rs	62,855	1,994	79.7%	https://programbench.com/task/burntsushi__ripgrep.3b7fd44/
4	FFmpeg/FFmpeg	Mirror of https://git.ffmpeg.org/ffmpeg.git	c	59,217	3,050	5.3%	https://programbench.com/task/ffmpeg__ffmpeg.360a402/
5	sharkdp/bat	A cat(1) clone with wings.	rs	58,487	801	33.2%	https://programbench.com/task/sharkdp__bat.f822bd0/
6	typst/typst	A markup-based typesetting system that is powerful and easy to learn.	rs	52,957	1,724	28.0%	https://programbench.com/task/typst__typst.88356d0/
7	jgm/pandoc	Universal markup converter	hs	43,632	5,228	14.1%	https://programbench.com/task/jgm__pandoc.5caad90/
8	sharkdp/fd	A simple, fast and user-friendly alternative to ‘find’	rs	42,668	1,235	78.1%	https://programbench.com/task/sharkdp__fd.40d8eb3/
9	php/php-src	The PHP Interpreter	c	40,030	14,288	4.8%	https://programbench.com/task/php__php-src.c891263/
10	duckdb/duckdb	DuckDB is an analytical in-process SQL database management system	cpp	37,657	5,650	12.4%	https://programbench.com/task/duckdb__duckdb.bdb65ec/
11	ajeetdsouza/zoxide	A smarter cd command. Supports all major shells.	rs	35,994	531	76.5%	https://programbench.com/task/ajeetdsouza__zoxide.67ca1bc/
12	jqlang/jq	Command-line JSON processor	c	34,541	6,072	89.9%	https://programbench.com/task/jqlang__jq.b33a763/
13	dandavison/delta	A syntax-highlighting pager for git, diff, grep, rg –json, and blame output	rs	30,445	950	37.3%	https://programbench.com/task/dandavison__delta.acd758f/
14	sharkdp/hyperfine	A command-line benchmarking tool	rs	27,960	291	54.3%	https://programbench.com/task/sharkdp__hyperfine.327d5f4/
15	ggreer/the_silver_searcher	A code-searching tool similar to ack, but faster.	c	27,080	1,006	59.3%	https://programbench.com/task/ggreer__the_silver_searcher.a61f178/
16	facebook/zstd	Zstandard - Fast real-time compression algorithm	c	27,013	2,038	68.8%	https://programbench.com/task/facebook__zstd.1168da0/
17	facebookresearch/fastText	Library for fast text representation and classification.	cpp	26,511	312	75.6%	https://programbench.com/task/facebookresearch__fasttext.1142dc4/
18	robertdavidgraham/masscan	TCP port scanner, spews SYN packets asynchronously, scanning entire Internet in under 5 minutes.	c	25,544	2,549	57.0%	https://programbench.com/task/robertdavidgraham__masscan.b99d433/
19	tree-sitter/tree-sitter	An incremental parsing system for programming tools	rs	24,953	1,232	37.2%	https://programbench.com/task/tree-sitter__tree-sitter.5e23cca/
20	FiloSottile/age	A simple, modern and secure encryption tool (and Go library) with small explicit keys, no config options, and UNIX-style composability.	go	22,077	676	63.5%	https://programbench.com/task/filosottile__age.706dfc1/
21	rust-lang/mdBook	Create book from markdown files. Like Gitbook but implemented in Rust	rs	21,541	1,114	55.5%	https://programbench.com/task/rust-lang__mdbook.37273ba/
22	jarun/nnn	n³ The unorthodox terminal file manager	c	21,506	477	98.1%	https://programbench.com/task/jarun__nnn.cb2c535/
23	antonmedv/fx	Terminal JSON viewer & processor	go	20,433	2,047	75.7%	https://programbench.com/task/antonmedv__fx.86d0d34/
24	mikefarah/yq	yq is a portable command-line YAML, JSON, XML, CSV, TOML, HCL and properties processor	go	15,281	2,000	39.5%	https://programbench.com/task/mikefarah__yq.602586d/
25	Y2Z/monolith	⬛️ CLI tool and library for saving complete web pages as a single HTML file	rs	15,024	713	51.2%	https://programbench.com/task/y2z__monolith.8702e66/
26	direnv/direnv	unclutter your .profile	go	14,998	849	62.0%	https://programbench.com/task/direnv__direnv.02040c7/
27	google/brotli	Brotli compression format	c	14,673	441	90.7%	https://programbench.com/task/google__brotli.b3dc9cc/
28	tomnomnom/gron	Make JSON greppable!	go	14,424	224	90.2%	https://programbench.com/task/tomnomnom__gron.88a6234/
29	XAMPPRocky/tokei	Count your code, quickly.	rs	14,300	732	69.5%	https://programbench.com/task/xampprocky__tokei.505d648/
30	ast-grep/ast-grep	⚡A CLI tool for code structural search, lint and rewriting. Written in Rust	rs	13,541	882	11.9%	https://programbench.com/task/ast-grep__ast-grep.dde0fe0/
31	cheat/cheat	cheat allows you to create and view interactive cheatsheets on the command-line. It was designed to help remind *nix system administrators of options for commands that they use frequently, but not frequently enough to remember.	go	13,278	297	59.9%	https://programbench.com/task/cheat__cheat.b8098dc/
32	jonas/tig	Text-mode interface for git	c	13,200	1,586	83.9%	https://programbench.com/task/jonas__tig.8334123/
33	ninja-build/ninja	a small build system with a focus on speed	cpp	12,895	1,438	72.3%	https://programbench.com/task/ninja-build__ninja.cc60300/
34	Canop/broot	A new way to see and navigate directory trees : https://dystroy.org/broot	rs	12,619	539	67.0%	https://programbench.com/task/canop__broot.d6c798e/
35	orf/gping	Ping, but with a graph	rs	12,433	339	78.5%	https://programbench.com/task/orf__gping.26eb5b9/
36	svenstaro/genact	🌀 A nonsense activity generator	rs	11,995	232	59.1%	https://programbench.com/task/svenstaro__genact.16f96e3/
37	lz4/lz4	Extremely Fast Compression algorithm	c	11,781	1,496	82.7%	https://programbench.com/task/lz4__lz4.1519f46/
38	o2sh/onefetch	Command-line Git information tool	rs	11,745	1,166	81.7%	https://programbench.com/task/o2sh__onefetch.e5958ce/
39	bootandy/dust	A more intuitive version of du in rust	rs	11,609	584	70.9%	https://programbench.com/task/bootandy__dust.62bf1e1/
40	ekzhang/bore	🕳 bore is a simple CLI tool for making tunnels to localhost	rs	11,075	406	68.7%	https://programbench.com/task/ekzhang__bore.8e059cd/
41	BurntSushi/xsv	A fast CSV command line toolkit written in Rust.	rs	10,757	1,182	82.7%	https://programbench.com/task/burntsushi__xsv.f430466/
42	bellard/quickjs	Public repository of the QuickJS Javascript Engine.	c	10,565	3,034	3.6%	https://programbench.com/task/bellard__quickjs.d7ae12a/
43	hatoo/oha	Ohayou(おはよう), HTTP load generator, inspired by rakyll/hey with tui animation.	rs	10,201	899	72.5%	https://programbench.com/task/hatoo__oha.8dc6349/
44	tstack/lnav	Log file navigator	cpp	10,200	990	13.4%	https://programbench.com/task/tstack__lnav.ee34494/
45	sharkdp/hexyl	A command-line hex viewer	rs	10,086	906	82.8%	https://programbench.com/task/sharkdp__hexyl.2e26437/
46	lua/lua	A copy of the Lua development repository, as seen by the Lua team. Mirrored irregularly. All communication should be through the Lua mailing list https://www.lua.org/lua-l.html	c	9,908	1,338	43.1%	https://programbench.com/task/lua__lua.c6b4848/
47	johnkerl/miller	Miller is like awk, sed, cut, join, and sort for name-indexed data such as CSV, TSV, and tabular JSON	go	9,842	14,637	22.9%	https://programbench.com/task/johnkerl__miller.8d85b46/
48	sqlite/sqlite	Official Git mirror of the SQLite source tree	c	9,434	13,514	67.0%	https://programbench.com/task/sqlite__sqlite.839433d/
49	boyter/scc	Sloc, Cloc and Code: scc is a very fast accurate code counter with complexity calculations and COCOMO estimates written in pure Go	go	8,320	464	37.7%	https://programbench.com/task/boyter__scc.515f91c/
50	ariga/atlas	Declarative schema migrations with schema-as-code workflows	go	8,311	1,318	54.8%	https://programbench.com/task/ariga__atlas.6d81150/
51	pemistahl/grex	A command-line tool and Rust library with Python bindings for generating regular expressions from user-provided test cases	rs	8,103	1,312	73.9%	https://programbench.com/task/pemistahl__grex.fa3e8ed/
52	htop-dev/htop	htop - an interactive process viewer	c	8,021	693	85.1%	https://programbench.com/task/htop-dev__htop.523600b/
53	peco/peco	Simplistic interactive filtering tool	go	7,881	1,224	76.7%	https://programbench.com/task/peco__peco.4e58dad/
54	bensadeh/tailspin	🌀 A log file highlighter	rs	7,793	615	75.8%	https://programbench.com/task/bensadeh__tailspin.6278437/
55	ducaale/xh	Friendly and fast tool for sending HTTP requests	rs	7,754	1,171	50.0%	https://programbench.com/task/ducaale__xh.4a6e44f/
56	svenstaro/miniserve	🌟 For when you really just want to serve some files over HTTP right now!	rs	7,561	304	78.6%	https://programbench.com/task/svenstaro__miniserve.8449e8b/
57	mgdm/htmlq	Like jq, but for HTML.	rs	7,520	1,455	93.9%	https://programbench.com/task/mgdm__htmlq.6e31bc8/
58	parcel-bundler/lightningcss	An extremely fast CSS parser, transformer, bundler, and minifier written in Rust.	rs	7,515	2,828	53.6%	https://programbench.com/task/parcel-bundler__lightningcss.aa2ed1e/
59	universal-ctags/ctags	A maintained ctags implementation	c	7,149	2,258	13.3%	https://programbench.com/task/universal-ctags__ctags.243595e/
60	chmln/sd	Intuitive find & replace CLI (sed alternative)	rs	7,072	810	90.9%	https://programbench.com/task/chmln__sd.87d1ba5/
61	ogham/dog	A command-line DNS client.	rs	6,640	1,300	84.2%	https://programbench.com/task/ogham__dog.721440b/
62	danmar/cppcheck	static analysis of C/C++ code	cpp	6,599	2,126	14.6%	https://programbench.com/task/danmar__cppcheck.0a5b103/
63	doxygen/doxygen	Official doxygen git repository	c	6,422	229	34.5%	https://programbench.com/task/doxygen__doxygen.966d98e/
64	sharkdp/pastel	A command-line tool to generate, analyze, convert and manipulate colors	rs	6,334	1,114	77.2%	https://programbench.com/task/sharkdp__pastel.b60e899/
65	BLAKE3-team/BLAKE3	the official Rust and C implementations of the BLAKE3 cryptographic hash function	rs	6,178	647	97.5%	https://programbench.com/task/blake3-team__blake3.15e83a5/
66	Nukesor/pueue	:stars: Manage your shell commands.	rs	6,154	638	15.4%	https://programbench.com/task/nukesor__pueue.8b9d6fe/
67	OSGeo/gdal	GDAL is an open source MIT licensed translator library for raster and vector geospatial data formats.	cpp	5,875	657	25.4%	https://programbench.com/task/osgeo__gdal.0847f12/
68	Byron/dua-cli	View disk space usage and delete unwanted data, fast.	rs	5,794	709	86.9%	https://programbench.com/task/byron__dua-cli.8570c15/
69	dundee/gdu	Fast disk usage analyzer with console interface written in Go	go	5,578	1,161	70.1%	https://programbench.com/task/dundee__gdu.ede21d2/
70	eradman/entr	Run arbitrary commands when files change	c	5,551	586	88.6%	https://programbench.com/task/eradman__entr.8e2e8b4/
71	LuaJIT/LuaJIT	Mirror of the LuaJIT git repository	c	5,518	2,967	71.5%	https://programbench.com/task/luajit__luajit.a553b3d/
72	mgechev/revive	🔥 ~6x faster, stricter, configurable, extensible, and beautiful drop-in replacement for golint	go	5,486	727	46.4%	https://programbench.com/task/mgechev__revive.201451e/
73	cweill/gotests	Automatically generate Go test boilerplate from your source code.	go	5,294	603	61.9%	https://programbench.com/task/cweill__gotests.2a672c5/
74	cordx56/rustowl	Visualize Ownership and Lifetimes in Rust	rs	5,113	589	75.2%	https://programbench.com/task/cordx56__rustowl.655bc5c/
75	abishekvashok/cmatrix	Terminal based “The Matrix” like implementation	c	5,042	508	97.0%	https://programbench.com/task/abishekvashok__cmatrix.5c082c6/
76	quinn-rs/quinn	Async-friendly QUIC implementation in Rust	rs	5,041	522	61.7%	https://programbench.com/task/quinn-rs__quinn.bb359cc/
77	alecthomas/chroma	A general purpose syntax highlighter in pure Go	go	4,910	515	15.9%	https://programbench.com/task/alecthomas__chroma.8d04def/
78	anordal/shellharden	The corrective bash syntax highlighter	rs	4,778	1,095	81.7%	https://programbench.com/task/anordal__shellharden.6a6ffd4/
79	yoav-lavi/melody	Melody is a language that compiles to regular expressions and aims to be more readable and maintainable	rs	4,748	1,205	78.9%	https://programbench.com/task/yoav-lavi__melody.f4af9b4/
80	sayanarijit/xplr	A hackable, minimal, fast TUI file explorer	rs	4,735	463	60.5%	https://programbench.com/task/sayanarijit__xplr.1751065/
81	hpjansson/chafa	📺🗿 Terminal graphics for the 21st century.	c	4,648	1,931	58.4%	https://programbench.com/task/hpjansson__chafa.dd4d4c1/
82	jhspetersson/fselect	Find files with SQL-like queries	rs	4,420	3,115	44.0%	https://programbench.com/task/jhspetersson__fselect.c3559ca/
83	ivanceras/svgbob	Convert your ascii diagram scribbles into happy little SVG	rs	4,182	472	41.3%	https://programbench.com/task/ivanceras__svgbob.6d00ad9/
84	multiprocessio/dsq	Commandline tool for running SQL queries against JSON, CSV, Excel, Parquet, and more.	go	3,867	542	80.3%	https://programbench.com/task/multiprocessio__dsq.c3ae0ba/
85	rcoh/angle-grinder	Slice and dice logs on the command line	rs	3,727	1,130	38.0%	https://programbench.com/task/rcoh__angle-grinder.9c2fc88/
86	rs/curlie	The power of curl, the ease of use of httpie.	go	3,637	701	89.3%	https://programbench.com/task/rs__curlie.5dfcbb1/
87	antonmedv/walk	Terminal file manager	go	3,598	470	74.3%	https://programbench.com/task/antonmedv__walk.bf802ef/
88	JohannesKaufmann/html-to-markdown	⚙️ Convert HTML to Markdown. Even works with entire websites and can be extended through rules.	go	3,586	885	85.5%	https://programbench.com/task/johanneskaufmann__html-to-markdown.3006818/
89	TheZoraiz/ascii-image-converter	A cross-platform command-line tool to convert images into ascii art and print them on the console. Now supports braille art!	go	3,284	465	64.1%	https://programbench.com/task/thezoraiz__ascii-image-converter.d05a757/
90	hairyhenderson/gomplate	A flexible commandline tool for template rendering. Supports lots of local and remote datasources.	go	3,135	2,926	74.7%	https://programbench.com/task/hairyhenderson__gomplate.05eb3aa/
91	ip7z/7zip	7-Zip	cpp	2,967	1,043	33.9%	https://programbench.com/task/ip7z__7zip.839151e/
92	madler/pigz	A parallel implementation of gzip for modern multi-processor, multi-core machines.	c	2,924	831	83.2%	https://programbench.com/task/madler__pigz.fe4894f/
93	tinycc/tinycc	Unofficial mirror of mob development branch	c	2,843	1,978	12.8%	https://programbench.com/task/tinycc__tinycc.9b8765d/
94	raviqqe/muffet	Fast website link checker in Go	go	2,597	293	88.1%	https://programbench.com/task/raviqqe__muffet.a882908/
95	segmentio/chamber	CLI for managing secrets	go	2,588	1,748	82.0%	https://programbench.com/task/segmentio__chamber.5f93f5f/
96	astaxie/bat	Go implement CLI, cURL-like tool for humans	go	2,563	1,091	71.8%	https://programbench.com/task/astaxie__bat.17d1080/
97	zk-org/zk	Plain text note-taking assistant	go	2,542	1,108	43.1%	https://programbench.com/task/zk-org__zk.10d93d5/
98	kisielk/errcheck	errcheck checks that you checked errors.	go	2,480	341	80.4%	https://programbench.com/task/kisielk__errcheck.dacab89/
99	mkj/dropbear	Dropbear SSH	c	2,231	682	58.1%	https://programbench.com/task/mkj__dropbear.75f699b/
100	noborus/trdsql	CLI tool that can execute SQL queries on CSV, LTSV, JSON, YAML and TBLN. Can output to various formats.	go	2,159	1,312	66.8%	https://programbench.com/task/noborus__trdsql.d8c5ff6/
101	sheepla/pingu	🐧ping command but with pingu	go	2,087	383	96.6%	https://programbench.com/task/sheepla__pingu.926d475/
102	go-critic/go-critic	The most opinionated Go source code linter for code audit.	go	2,041	493	41.6%	https://programbench.com/task/go-critic__go-critic.9aea378/
103	OSGeo/PROJ	PROJ - Cartographic Projections and Coordinate Transformations Library	cpp	1,974	5,319	73.8%	https://programbench.com/task/osgeo__proj.75d455c/
104	noborus/ov	🎑Feature-rich terminal-based text viewer. It is a so-called terminal pager.	go	1,935	1,854	87.6%	https://programbench.com/task/noborus__ov.b96c2ba/
105	samtools/samtools	Tools (written in C using htslib) for manipulating next-generation sequencing data	c	1,886	1,425	14.2%	https://programbench.com/task/samtools__samtools.aa823b5/
106	gabotechs/dep-tree	Tool for helping developers keep their code bases clean and decoupled. It allows visualising a code base complexity using a 3d force-directed graph of files and the dependencies between them.	go	1,706	865	65.2%	https://programbench.com/task/gabotechs__dep-tree.60a95a2/
107	cmatsuoka/figlet	Claudio’s FIGlet tree	c	1,606	872	77.5%	https://programbench.com/task/cmatsuoka__figlet.202a0a8/
108	lh3/seqtk	Toolkit for processing sequences in FASTA/Q formats	c	1,537	429	67.4%	https://programbench.com/task/lh3__seqtk.94e7070/
109	tukaani-project/xz	XZ Utils	c	1,522	1,410	36.0%	https://programbench.com/task/tukaani-project__xz.1007bf0/
110	skeema/skeema	Declarative pure-SQL schema management for MySQL and MariaDB	go	1,361	1,708	76.5%	https://programbench.com/task/skeema__skeema.6a76243/
111	mfridman/tparse	CLI tool for summarizing go test output. Pipe friendly. CI/CD friendly.	go	1,246	425	77.6%	https://programbench.com/task/mfridman__tparse.2416b4b/
112	lfos/calcurse	A text-based calendar and scheduling application	c	1,243	666	53.8%	https://programbench.com/task/lfos__calcurse.49180d5/
113	hooklift/gowsdl	WSDL2Go code generation as well as its SOAP proxy	go	1,219	391	86.4%	https://programbench.com/task/hooklift__gowsdl.2a06cec/
114	guumaster/hostctl	Your dev tool to manage /etc/hosts like a pro!	go	1,216	1,051	82.8%	https://programbench.com/task/guumaster__hostctl.d6d9699/
115	rs/jplot	iTerm2 expvar/JSON monitoring tool	go	1,178	583	89.0%	https://programbench.com/task/rs__jplot.2a54bcc/
116	naggie/dstask	Git powered terminal-based todo/note manager – markdown note page per task. Single binary!	go	1,157	1,278	58.8%	https://programbench.com/task/naggie__dstask.ff57396/
117	sigoden/argc	A Bash CLI framework, also a Bash command runner.	rs	1,135	995	44.1%	https://programbench.com/task/sigoden__argc.04a08f1/
118	sibprogrammer/xq	Command-line XML and HTML beautifier and content extractor	go	1,109	792	75.9%	https://programbench.com/task/sibprogrammer__xq.b89f681/
119	xorg62/tty-clock	Clock using lib ncurses	c	1,105	281	84.0%	https://programbench.com/task/xorg62__tty-clock.f2f847c/
120	unhappychoice/gittype	A CLI code-typing game that turns your source code into typing challenges	rs	1,075	741	91.3%	https://programbench.com/task/unhappychoice__gittype.34b72d0/
121	eudoxia0/hashcards	A plain text-based spaced repetition system.	rs	1,071	1,151	56.3%	https://programbench.com/task/eudoxia0__hashcards.48aa136/
122	rvben/rumdl	Fast Markdown linter and formatter written in Rust	rs	1,051	3,322	40.7%	https://programbench.com/task/rvben__rumdl.2d75c4d/
123	sclevine/yj	CLI - Convert between YAML, TOML, JSON, and HCL. Preserves map order.	go	1,041	767	74.4%	https://programbench.com/task/sclevine__yj.8016400/
124	arq5x/bedtools2	bedtools - the swiss army knife for genome arithmetic	c	1,029	1,053	38.9%	https://programbench.com/task/arq5x__bedtools2.dd57059/
125	cslarsen/jp2a	Converts jpg images to ASCII	c	1,021	631	56.1%	https://programbench.com/task/cslarsen__jp2a.61d205f/
126	blacknon/hwatch	A modern alternative to the watch command, records the differences in execution results and can check this differences at after.	rs	1,016	1,016	81.1%	https://programbench.com/task/blacknon__hwatch.edfcb62/
127	eliukblau/pixterm	Draw images in your ANSI terminal with true color	go	1,014	430	74.9%	https://programbench.com/task/eliukblau__pixterm.1a93fd5/
128	Canop/rhit	A nginx log explorer	rs	1,006	817	53.2%	https://programbench.com/task/canop__rhit.ae90bcb/
129	stathissideris/ditaa	ditaa is a small command-line utility that can convert diagrams drawn using ascii art (‘drawings’ that contain characters that resemble lines like \| / - ), into proper bitmap graphics.	java	1,005	609	20.4%	https://programbench.com/task/stathissideris__ditaa.f2286c4/
130	rbakbashev/elfcat	ELF visualizer. Generates HTML files from ELF binaries.	rs	990	564	98.2%	https://programbench.com/task/rbakbashev__elfcat.52f8cc7/
131	nuta/nsh	A command-line shell like fish, but POSIX compatible.	rs	966	1,963	83.7%	https://programbench.com/task/nuta__nsh.bdd0702/
132	dalance/amber	A code search / replace tool	rs	941	567	71.1%	https://programbench.com/task/dalance__amber.69a0f52/
133	pls-rs/pls	pls is a prettier and powerful ls(1) for the pros.	rs	932	332	62.3%	https://programbench.com/task/pls-rs__pls.4e1ae50/
134	Esubaalew/run	Universal multi-language runner and smart REPL written in Rust.	rs	919	1,212	85.2%	https://programbench.com/task/esubaalew__run.0fb9dec/
135	chirlu/sox	SoX, Swiss Army knife of sound processing	c	913	1,202	37.9%	https://programbench.com/task/chirlu__sox.42b3557/
136	clog-tool/clog-cli	Generate beautiful changelogs from your Git commit history	rs	912	575	93.0%	https://programbench.com/task/clog-tool__clog-cli.7066cba/
137	tarka/xcp	An extended `cp`	rs	911	1,184	92.6%	https://programbench.com/task/tarka__xcp.5e5b448/
138	oppiliappan/eva	a calculator REPL, similar to bc(1)	rs	907	913	88.7%	https://programbench.com/task/oppiliappan__eva.41ae245/
139	git-bahn/git-graph	Command line tool to show clear git graphs arranged for your branching model	rs	904	568	79.6%	https://programbench.com/task/git-bahn__git-graph.87b4473/
140	gromacs/gromacs	Public/backup repository of the GROMACS molecular simulation toolkit. Please do not mine the metadata blindly; we use https://gitlab.com/gromacs/gromacs for code review and issue tracking.	cpp	901	1,245	9.3%	https://programbench.com/task/gromacs__gromacs.665ea4c/
141	sirwart/ripsecrets	A command-line tool to prevent committing secret keys into your source code	rs	901	611	72.8%	https://programbench.com/task/sirwart__ripsecrets.34c9e03/
142	Drew-Alleman/DataSurgeon	Quickly Extracts IP’s, Email Addresses, Hashes, Files, Credit Cards, Social Security Numbers and a lot More From Text	rs	890	502	74.3%	https://programbench.com/task/drew-alleman__datasurgeon.d257cee/
143	alexpovel/srgn	A grep-like tool which understands source code syntax and allows for manipulation in addition to search	rs	889	1,852	69.5%	https://programbench.com/task/alexpovel__srgn.89f943b/
144	kyoheiu/felix	tui file manager with vim-like key mapping	rs	888	502	49.2%	https://programbench.com/task/kyoheiu__felix.95df390/
145	oppiliappan/statix	lints and suggestions for the nix programming language	rs	882	815	42.8%	https://programbench.com/task/oppiliappan__statix.e9df54c/
146	nachoparker/dutree	a tool to analyze file system usage written in Rust	rs	871	641	89.5%	https://programbench.com/task/nachoparker__dutree.44e877d/
147	simeg/eureka	💡 CLI tool to input and store your ideas without leaving the terminal	rs	867	344	78.8%	https://programbench.com/task/simeg__eureka.df3796c/
148	kyoh86/richgo	Enrich `go test` outputs with text decorations.	go	863	546	85.0%	https://programbench.com/task/kyoh86__richgo.313114f/
149	rochacbruno/marmite	Markdown makes sites - A Static Site Generator for Blogs	rs	837	668	45.4%	https://programbench.com/task/rochacbruno__marmite.7d4bc2d/
150	rust-embedded/svd2rust	Generate Rust register maps (`struct`s) from SVD files	rs	835	920	72.9%	https://programbench.com/task/rust-embedded__svd2rust.1760b5e/
151	konradsz/igrep	Interactive Grep	rs	827	385	73.5%	https://programbench.com/task/konradsz__igrep.aa75630/
152	nikolassv/bartib	A simple timetracker for the command line. It saves a log of all tracked activities as a plaintext file and allows you to create flexible reports.	rs	827	722	87.3%	https://programbench.com/task/nikolassv__bartib.6b9b5ce/
153	yassinebridi/serpl	A simple terminal UI for search and replace, ala VS Code.	rs	824	446	61.0%	https://programbench.com/task/yassinebridi__serpl.c48a9d7/
154	riquito/tuc	When cut doesn’t cut it	rs	820	1,196	92.7%	https://programbench.com/task/riquito__tuc.16fb471/
155	ecumene/rust-sloth	A 3D software rasterizer… for the terminal!	rs	818	380	52.6%	https://programbench.com/task/ecumene__rust-sloth.051c559/
156	crowdagger/crowbook	Converts books written in Markdown to HTML, LaTeX/PDF and EPUB	rs	813	807	60.3%	https://programbench.com/task/crowdagger__crowbook.ea214d7/
157	WGUNDERWOOD/tex-fmt	An extremely fast LaTeX formatter written in Rust	rs	789	455	80.7%	https://programbench.com/task/wgunderwood__tex-fmt.3f1aef6/
158	Stranger6667/jsonschema	A high-performance JSON Schema validator for Rust	rs	770	2,933	51.7%	https://programbench.com/task/stranger6667__jsonschema.d52e881/
159	rhysd/kiro-editor	A small terminal UTF-8 text editor written in Rust 📝🦀	rs	761	595	93.3%	https://programbench.com/task/rhysd__kiro-editor.4157485/
160	astro/deadnix	Scan Nix files for dead code	rs	745	602	85.5%	https://programbench.com/task/astro__deadnix.d590041/
161	sstadick/hck	A sharp cut(1) clone.	rs	738	855	95.7%	https://programbench.com/task/sstadick__hck.b66c751/
162	trasta298/keifu	Git genealogy, untangled. A TUI for navigating commit graphs with color and clarity.	rs	729	262	67.2%	https://programbench.com/task/trasta298__keifu.3331426/
163	AmmarAbouZor/tui-journal	Your journal app if you live in a terminal	rs	722	1,402	70.8%	https://programbench.com/task/ammarabouzor__tui-journal.2b4540d/
164	incu6us/goimports-reviser	Right imports sorting & code formatting tool (goimports alternative)	go	715	513	86.4%	https://programbench.com/task/incu6us__goimports-reviser.81bd549/
165	yaa110/nomino	Batch rename utility for developers	rs	710	313	79.9%	https://programbench.com/task/yaa110__nomino.f892499/
166	wfxr/csview	📠 Pretty and fast csv viewer for cli with cjk/emoji support.	rs	694	335	96.1%	https://programbench.com/task/wfxr__csview.8ac4de0/
167	chmln/handlr	A better xdg-utils	rs	693	722	90.7%	https://programbench.com/task/chmln__handlr.90e78ba/
168	Miserlou/Loop	UNIX’s missing `loop` command	rs	692	710	94.6%	https://programbench.com/task/miserlou__loop.209927c/
169	KSXGitHub/parallel-disk-usage	Highly parallelized, blazing fast directory tree analyzer	rs	689	531	86.1%	https://programbench.com/task/ksxgithub__parallel-disk-usage.96978ed/
170	hush-shell/hush	Hush is a unix shell based on the Lua programming language	rs	688	1,201	83.3%	https://programbench.com/task/hush-shell__hush.560c33a/
171	zevv/duc	Dude, where are my bytes: Duc, a library and suite of tools for inspecting disk usage	c	682	874	83.4%	https://programbench.com/task/zevv__duc.a58fa4e/
172	altdesktop/i3-style	🎨 Make your i3 config a little more stylish.	rs	678	539	80.0%	https://programbench.com/task/altdesktop__i3-style.f93821b/
173	wintermute-cell/ngrrram	A TUI tool to help you type faster and learn new layouts. Includes a free cat.	rs	674	303	84.5%	https://programbench.com/task/wintermute-cell__ngrrram.8ea13c3/
174	psampaz/go-mod-outdated	Find outdated dependencies of your Go projects. go-mod-outdated provides a table view of the go list -u -m -json all command which lists all dependencies of a Go project and their available minor and patch updates. It also provides a way to filter indirect dependencies and dependencies without updates.	go	669	285	98.2%	https://programbench.com/task/psampaz__go-mod-outdated.bb79367/
175	wfxr/code-minimap	🛰 A high performance code minimap render.	rs	660	313	88.8%	https://programbench.com/task/wfxr__code-minimap.0ddeea5/
176	kaushiksrini/parqeye	Peek inside Parquet files right from your terminal	rs	654	479	58.9%	https://programbench.com/task/kaushiksrini__parqeye.8072121/
177	stacked-git/stgit	Stacked Git	rs	652	1,488	20.0%	https://programbench.com/task/stacked-git__stgit.430027d/
178	Isona/dirble	Fast directory scanning and scraping tool	rs	632	718	66.7%	https://programbench.com/task/isona__dirble.e2dea9f/
179	YS-L/flamelens	Flamegraph viewer in the terminal	rs	622	224	59.4%	https://programbench.com/task/ys-l__flamelens.0b4dc33/
180	mookid/diffr	Yet another diff highlighting tool	rs	612	606	84.7%	https://programbench.com/task/mookid__diffr.2152742/
181	shashwatah/jot	⚡Rapid note management for the terminal.	rs	609	752	84.6%	https://programbench.com/task/shashwatah__jot.a92aad8/
182	Epistates/treemd	A (TUI/CLI) markdown navigator with tree-based structural navigation.	rs	603	1,569	55.1%	https://programbench.com/task/epistates__treemd.825c6dd/
183	pier-cli/pier	A CLI to organize and run short Unix shell scripts	rs	596	692	83.7%	https://programbench.com/task/pier-cli__pier.5e1bde9/
184	jrnxf/thokr	✨ sleek typing tui with visualized results and historical logging	rs	595	445	82.2%	https://programbench.com/task/jrnxf__thokr.09375ef/
185	ismaelgv/rnr	A command-line tool to batch rename files and directories	rs	581	683	82.1%	https://programbench.com/task/ismaelgv__rnr.fc0733b/
186	sitkevij/hex	🔮 Futuristic take on hexdump, made in Rust.	rs	563	823	91.7%	https://programbench.com/task/sitkevij__hex.61ae69b/
187	brocode/fblog	Small command-line JSON Log viewer	rs	561	978	86.0%	https://programbench.com/task/brocode__fblog.3b54330/
188	codesnap-rs/codesnap	🦀️📸 Pure Rust tool to generate beautiful code snapshots, provide CLI and Library	rs	557	730	59.2%	https://programbench.com/task/codesnap-rs__codesnap.f81e4f3/
189	foriequal0/git-trim	Automatically trims your branches whose tracking remote refs are merged or stray	rs	548	509	64.6%	https://programbench.com/task/foriequal0__git-trim.07c2f50/
190	axodotdev/oranda	🎁 generate beautiful landing pages for your developer tools	rs	542	767	53.6%	https://programbench.com/task/axodotdev__oranda.27d60c7/
191	elkowar/pipr	A tool to interactively write shell pipelines.	rs	541	525	57.1%	https://programbench.com/task/elkowar__pipr.fae0b17/
192	paradigmxyz/solar	Blazingly fast, modular and contributor friendly Solidity compiler, written in Rust	rs	539	1,978	43.3%	https://programbench.com/task/paradigmxyz__solar.5190d0e/
193	Lymphatus/caesium-clt	Caesium Command Line Tools - Lossy/lossless image compression tool	rs	537	575	92.3%	https://programbench.com/task/lymphatus__caesium-clt.a529b2e/
194	agourlay/zip-password-finder	Find the password of protected ZIP files.	rs	534	680	97.9%	https://programbench.com/task/agourlay__zip-password-finder.704700d/
195	rust-ethereum/ethabi	Encode and decode smart contract invocations	rs	525	997	90.9%	https://programbench.com/task/rust-ethereum__ethabi.b1710ad/
196	ArthurSonzogni/json-tui	A JSON terminal UI made in C++	cpp	438	755	71.0%	https://programbench.com/task/arthursonzogni__json-tui.17a22b6/
197	tomarrell/wrapcheck	A Go linter to check that errors from external packages are wrapped	go	374	480	80.8%	https://programbench.com/task/tomarrell__wrapcheck.c058da1/
198	NikolaDucak/caps-log	A small TUI journaling tool. 📖	cpp	370	551	61.7%	https://programbench.com/task/nikoladucak__caps-log.2cf2d1e/
199	mibk/dupl	a tool for code clone detection	go	367	373	85.0%	https://programbench.com/task/mibk__dupl.1bf052b/
200	HaliteChallenge/Halite	@twosigma’s first artificial intelligence programming challenge	cpp	202	275	80.4%	https://programbench.com/task/halitechallenge__halite.822cfb6/

このデータから分かること

ProgramBench のメインリーダーボードでは、9 モデルすべての Resolved が 0% です。統一された軽量 agent 設定では、現在のモデルはまだブラックボックスの振る舞いとドキュメントだけから完全なソフトウェアを安定して再構築できません。

一方で、Almost resolved には差が出ています。Claude Opus 4.7 は 3.0%、Claude Opus 4.6 は 2.5%、Claude Sonnet 4.6 は 1.0%、その他のモデルは 0.0% です。完全通過だけを見るよりも、ほぼ完成に近い能力を見る指標として有用です。

タスクインスタンス表も重要です。各オープンソースプロジェクトの言語、スター数、テスト数、現時点のベストスコアが並び、ProgramBench が圧縮、検索、データベース、コンパイラ、コマンドラインツール、メディア処理など幅広いソフトウェアを含んでいることが分かります。AI Coding にとって、これは単純なアルゴリズム問題よりも実際のエンジニアリング負荷に近いものです。

ProgramBench 0% 解説：AI コーディングで本当に怖いのは失敗ではなく、ロードマップが明確になったこと

Sun, 10 May 2026 12:32:39 +0800

AI コーディング界隈に、新しいベンチマーク ProgramBench が登場しました。表面的には、プログラマーにとって安心できる結果に見えます。主要 9 モデルは fully resolved 指標ですべて 0% で、1 つのタスクを完全に通過できたモデルはありません。

しかし本当に警戒すべきなのは、今日の大規模モデルがまだできないことではありません。完全なソフトウェア工学が、初めて明確に評価・順位付け・反復最適化できる課題として定義されたことです。

タスクが明確に定義されると、AI 業界が最も得意なことが始まります。ベンチマークを解き、反復し、ランキングを追い、かつて不可能だったものを少しずつ実用域へ近づけていくのです。

ProgramBench は何を測っているのか

多くのコーディングベンチマークは、関数補完、bug 修正、単体テスト通過、あるいは既存プロジェクトへの小さな機能追加を測ります。ProgramBench はそれよりずっと厳しいものです。ソースコードも、プロジェクト構造も、既存のテストケースも与えません。

モデルに与えられる材料は主に 2 つだけです。

コンパイル済みの実行ファイル。
そのプログラムの利用ドキュメント。

モデルは実行ファイルを自分で動かし、入出力の振る舞いを観察し、コマンドライン引数、境界条件、エラーメッセージ、データ保存方法を理解したうえで、同じ振る舞いをするプログラムを再実装する必要があります。

これはもはや「少しコードを書く」作業ではありません。簡略化されているとはいえ、完全なソフトウェア工学タスクです。要件を理解し、振る舞いを探索し、言語を選び、構造を設計し、ソースコードを書き、ビルド方法を用意し、隠しテストをできるだけ通過しなければなりません。

ProgramBench の公式説明によると、現在は 200 個のタスクを含み、小規模なコマンドラインツールから PHP、FFmpeg、SQLite などの大型実プロジェクトまでを対象にしています。テストセットは agent-driven fuzzing によって生成され、合計で 248,000 件を超える行動テストがあります。

テストの流れを分解すると、ProgramBench はおおよそ次の 4 つを測っています。

ドキュメントを読む力：プログラムが提供すべきコマンド、引数、出力を理解する。
振る舞いを探索する力：バイナリを繰り返し実行し、正常入力、異常入力、境界条件を観察する。
実装を再構築する力：言語とプロジェクト構造を自分で選び、振る舞いが近い代替プログラムを書く。
隠しテストを通す力：通常の振る舞いだけでなく、エラー処理、出力形式、境界条件もできるだけ一致させる。

つまり検索上の価値は「また新しいスコア表」だけではありません。より具体的に、ソースコードなしで、ドキュメントとブラックボックスの振る舞いだけを頼りに、大規模モデルが本物のソフトウェアをゼロから再現できるのかを問うています。

なぜ結果は 0% なのか

ProgramBench の主指標は fully resolved です。つまり、あるタスク内のテストがすべて通過して初めて完了とみなされます。現在の leaderboard では、9 モデルすべてがこの指標で 0% です。

評価対象には Claude、GPT、Gemini などの系列が含まれ、すべて mini-SWE-agent をベースライン agent として使っています。almost resolved 指標では Claude Opus 4.7 が最もよく、約 3.0% のタスクで少なくとも 95% のテストを通過しました。Claude Opus 4.6 は 2.5%、Claude Sonnet 4.6 は 1.0% です。GPT 5.4、GPT 5.4 mini、Gemini 3.1 Pro、Gemini 3 Flash などは almost resolved でも 0.0% です。

これは、今日の大規模モデルに軽量 agent を組み合わせても、ゼロから完全なソフトウェアを再構築することはまだできない、ということを示しています。最も簡単なタスクでさえ、すべての細部を完全に合わせるのは難しいのです。

ただし注意も必要です。今回使われたのは mini-SWE-agent であり、Claude Code でも Codex でもありません。より強力な coding agent、より多くのツールチェーン支援、より長い探索プロセスを使えば、結果は改善する可能性があります。より正確には、現在のモデルに軽量 agent を組み合わせただけでは、完全なソフトウェア再構築を安定して完了するには足りない、ということです。

fully resolved と almost resolved の意味

ProgramBench の結果を読むとき、最も誤解しやすいのがこの 2 つの指標です。

fully resolved は最も厳しい指標です。あるタスク内のすべての隠しテストを通過して初めて、完全に解決したとみなされます。境界条件、エラー形式、コマンド引数の振る舞いのどれか 1 つでも漏れれば fully resolved にはなりません。

almost resolved は「ほぼ完成」に近い指標です。あるタスクで少なくとも 95% のテストを通過すれば almost resolved に入ります。モデルが大部分の振る舞いを再現できたかは分かりますが、そのプログラムが元のソフトウェアを置き換えられることを意味するわけではありません。

だからこそ 0% は分けて見る必要があります。fully resolved の 0% は、モデルがまだ完全な納品をできないことを示します。一方で almost resolved の差を見ると、どのモデルが一部のタスクで復刻成功に近づいているかが分かります。たとえば Claude Opus 4.7 の almost resolved は約 3.0% で、少数の比較的簡単なタスクでは確かに完成に近づいていますが、完全なソフトウェア再構築を安定して行うにはまだ遠い状態です。

mini-SWE-agent が結果に影響する理由

今回の評価では、統一された mini-SWE-agent が使われています。利点は公平性です。異なるモデルを同じ軽量 agent フレームワーク上で走らせるため、横比較がしやすくなります。

しかし、それは上限も制限します。完全なソフトウェア再構築はモデル本体だけで決まるものではありません。agent が探索戦略を立てられるか、長期タスクを管理できるか、テストを自動生成できるか、失敗原因を反復的に特定できるか、プロジェクト構造を整理できるかにも左右されます。

mini-SWE-agent は最強のエンジニアリング環境というより、統一されたベースラインです。

Claude Code や Codex のようなより完全な coding agent は、通常、より強力なツール呼び出し、コンテキスト整理、タスク分解、多段階修正能力を備えています。これらのツールに置き換えれば、結果はよくなる可能性があります。

したがって ProgramBench の今回の結果は、現在のモデルが軽量 agent 環境では完全なソフトウェア再構築をまだできない、と理解するのが適切です。「モデルは永遠にできない」と証明しているわけでも、すべての商用 coding agent の上限を完全に測ったわけでもありません。

SWE-bench との違い

SWE-bench は AI コーディング領域ですでに重要なベンチマークです。実際の GitHub リポジトリで issue を読み、コードを修正し、パッチを提出させることで、モデルが現実の bug を解決できるかを測ります。

しかし SWE-bench は本質的には既存プロジェクトの修理です。車はすでにあり、技術スタック、ディレクトリ構造、コード組織、アーキテクチャ設計は人間が作っています。モデルは問題を見つけ、壊れた部品を直せばよいのです。

ProgramBench は車を作り直すことに近いものです。この車は赤信号で止まり、歩行者に近づくと警笛を鳴らす、といった振る舞いだけが分かっています。構造、言語、モジュール、ビルド方法はすべて自分で決めなければなりません。

だからこそ、はるかに難しくなります。局所的なパッチ能力だけでなく、ソフトウェアアーキテクチャ、システム推論、振る舞い探索、自動テスト、多段階修正、長期的なエンジニアリング設計を測るからです。

違いは次の表で整理できます。

観点	SWE-bench	ProgramBench
出発点	既存の GitHub リポジトリと issue	コンパイル済み実行ファイルと利用ドキュメント
ソースコードの有無	ソースコードあり	ソースコードなし
主なタスク	既存プロジェクト内の bug 修正	振る舞いから完全なプログラムを再実装
技術スタック	元プロジェクトで決定済み	モデルが自分で選択
プロジェクト構造	元プロジェクトに存在	モデルが自分で設計
テスト方法	パッチ提出後にテストを実行	隠し行動テストで復刻度を検証
主な評価点	コード読解、問題特定、パッチ修正	振る舞い探索、システム抽象化、アーキテクチャ設計、完全実装

このため ProgramBench は、次段階の AI Coding の目標として見るのに適しています。「既存コードを修正する」段階から「完全なソフトウェアを再構築する」段階へ問題を押し進めているからです。

0% は安全を意味しない

0% を見て、多くの人は「プログラマーの仕事は当面守られた」と感じるかもしれません。

短期的には、それは間違いではありません。今日の大規模モデルは、特にソースコード、テストケース、プロジェクト構造がない状況では、完全なソフトウェア工学を安定してこなせません。要件定義、アーキテクチャ設計、長期保守、セキュリティ管理、チーム協業、業務理解は、いまも人間のソフトウェアエンジニアの重要な強みです。

しかし 0% を「AI コーディングはここで頭打ち」と解釈するのは楽観的すぎます。

ProgramBench が本当に変えたのは、問題定義です。以前から、AI がコードを補完できることも、bug を修正できることも知られていました。しかし「実行ファイルとドキュメントから完全なソフトウェアを再構築する」という課題は、明確な共通レースとして置かれていませんでした。今は 200 問、統一評価、統一ランキングになっています。

これは、モデル企業、agent 企業、開発ツール企業が次にどこへ力を入れるべきかを知った、ということです。AI をコード片を書く存在から、完全なソフトウェアシステムを保守・再構築・納品する存在へ進化させる方向です。

オフライン化と不正防止が必要な理由

ProgramBench の設計には重要な細部があります。不正防止です。

初期のテストでは、モデルが GitHub から直接ソースコードを探したり、パッケージマネージャー経由でソースを含むパッケージをダウンロードしたり、ローカルのシステムキャッシュからダウンロード済みパッケージを探したりしました。これではテストの目的が壊れます。問うているのが「振る舞いからソフトウェアを再構築できるか」ではなく、「元のソースコードを見つけられるか」になってしまうからです。

そのため ProgramBench はサンドボックスとオフライン環境を使います。インターネットアクセス、逆コンパイル、逆アセンブル、実行ファイル内容の読み取りは禁止です。モデルはプログラムを実行し、振る舞いを観察し、自分で実装することしかできません。

この制限によって評価はよりクリーンになり、本当に答えたい問いに近づきます。大規模言語モデルは、プログラムの振る舞いとドキュメントから、自力で実行可能なソフトウェアプロジェクトを構築できるのか、という問いです。

より警戒すべきなのはコード形態の変化

ProgramBench には 0% よりもソフトウェアエンジニアが考えるべき発見があります。モデルが生成するコードは、人間のエンジニアが書くプロジェクトとは違う形になりがちです。

公開資料では、モデルはより少ないファイル、浅いディレクトリ、少ない関数、そして長い単一関数を生成する傾向があるとされています。つまり、構造が明確で人間が保守しやすいソフトウェア工学プロジェクトではなく、巨大だが動くスクリプトを書きがちです。

従来のソフトウェア工学の観点では、これは通常よくないコードです。ファイルが少なすぎる、関数が長すぎる、抽象化が足りない、モジュール境界が曖昧、といった問題は人間の保守を難しくします。

しかし問題は、AI が人間の保守方法に合わせてコードを書く必要があるとは限らないことです。

人間が抽象化、命名、ディレクトリ構造、モジュール境界を重視するのは、人間の記憶に限界があり、チーム協業が必要で、コードを長期的に再利用するからです。AI が長いコンテキスト、検索システム、自動テストを使ってコードを繰り返し書き直せるなら、人間に馴染みのある工学規範をそれほど必要としないかもしれません。

これは現実的なリスクを生みます。将来の AI が書くソフトウェアは動き、場合によっては高速でも、人間が保守に介入することはますます難しくなるかもしれません。

プログラマーが本当にアップグレードすべきもの

ProgramBench の結果は、プログラマーにとって単純な朗報でも悲報でもありません。

短期的には、完全なソフトウェア工学はまだ難しく、この benchmark だけでプログラマーがすぐ失業するわけではありません。特にアーキテクチャ判断、要件定義、セキュリティ管理、品質検収、業務理解は、今も人間が責任を持つ必要があります。

長期的には、プログラマーの仕事はさらに上流へ移ります。本当に危ないのは「コードを書けない人」ではなく、コードしか書けず、問題を定義できず、結果を検証できず、ツールチェーンを組織できず、リスクを制御できない人です。

未来のソフトウェアエンジニアは、より次のような役割に近づくかもしれません。

要件定義者：曖昧なビジネス課題を実行可能な目標に変える。
システム検収者：AI が生成した結果が本当に要件を満たしているか判断する。
ツールチェーン組織者：モデル、agent、テスト、デプロイ、監視を組み合わせる。
品質責任者：安全性、保守性、境界条件、長期リスクを管理する。
ビジネスと技術の翻訳者：現実の問題をエンジニアリングシステムが扱える制約へ変換する。

もし AI が本当にコードアシスタントから完全なソフトウェアエンジニアへ進化するなら、人間のプログラマーの価値は、すべての行を手で書くことではなくなります。何を書く価値があるのか、何をもって正しいとするのか、どこで失敗してはいけないのかを定義することになります。

まとめ

ProgramBench の 0% は終点ではなく、新しい段階の始まりです。

それは、今日の大規模モデルがまだゼロから完全なソフトウェアシステムを安定して再構築できないことを示しています。同時に、次世代 AI Coding agent の目標も非常に明確にしました。局所的なパッチから完全なプロジェクトへ、コード片からシステム納品へ進むという目標です。

プログラマーにとって、短期的には少し安心してよいでしょう。しかし長期的には「AI はまだできない」だけを見ていてはいけません。より重要なのは、自分をコード実行者から、問題定義者、結果検収者、リスク管理者へ早く引き上げることです。

本当に警戒すべきなのは、AI が今日 0% を取ったことではありません。問題集がすでに置かれたことです。

Codex vs Claude Code：2 つの Subagent 設計をどう選ぶか

Fri, 08 May 2026 14:14:01 +0800

AI コーディングツールでは Subagent が重要になっています。これは流行りの機能ではなく、単一 Agent が実際の開発タスクを抱え込むと限界に当たりやすいからです。

1 つの Agent がコードを読み、ログを確認し、実装を変更し、テストを実行し、エラーを分析し、結果をまとめると、main context はすぐ汚れます。検索結果、コマンド出力、テストログ、中間推論が混ざり、後の判断が不安定になります。探索、実装、検証、レビューを 1 本の main thread に押し込むため、並行処理もしづらくなります。

Subagent の本質は Agent の負荷を下げることです。main session はすべてを最後まで行うのではなく、目標を決め、タスクを割り当て、結果を受け取り、最終回答へ統合する coordinator になります。Subagent は探索、実装、検証、レビューなど局所的な仕事を処理し、圧縮した結論を返します。

つまり Subagent は「もう 1 人の自分」ではなく、絡み合った開発作業を明確な役割に分ける仕組みです。

共通する土台

成熟した Subagent system には通常、次の要素が必要です。

Context isolation。
Role specialization。
Project/user level configuration。
Tool and permission boundaries。

Context isolation は前提です。実際のリポジトリでは、検索結果、テストログ、コマンド出力など中間情報が大量に出ます。これをすべて main session に入れると main thread が乱れます。Subagent は局所的な過程を先に消化し、判断に必要な signal だけを返します。

Role specialization も重要です。複数 Agent とは同じモデルを複数起動することではありません。探索役は検索、読解、要約に強くあるべきです。実装役はコード変更に集中します。検証役はチェックを実行し、リスクを見つけ、結果を明確に報告します。

Tool と permission の境界は安全性を決めます。Subagent が main session の全能力を自動継承すべきではありません。読み取り専用の explorer に書き込み権限は不要です。verifier が実装を変更する必要もありません。

Codex と Claude Code はこの問題意識を共有しつつ、異なる道を取っています。

Codex：明示的な委任

Codex の Subagent 設計は抑制的です。

現在の main session を中心に、制御された軽量な分業機構を提供します。いつ委任するか、誰に渡すか、いつ結果を受け取るかは明示的な判断です。制御フローは現在のタスクに残ります。

特徴は次の通りです。

main session が明示的に subtask を委任する。
role set は小さく保たれる。
main session は誰が何をしているか把握できる。
結果は main line に戻ってから判断される。
協作境界が透明。

これは手動 orchestration、予測可能性、実行の確定性を重視するチームに向いています。explorer に call chain を調べさせ、worker に限定的な変更を任せ、main session が結果を統合して次のテストを判断できます。

一方で、分割、委任、回収、統合の負荷は main session に残ります。軽量な協作には心地よいですが、長期的で複雑な workflow では重くなることがあります。

Claude Code：Agent を workstations として扱う

Claude Code はより platform 的です。

Agent を、説明可能、選択可能、設定可能、記憶可能、隔離可能、background 実行可能な正式な object として扱います。Subagent は会話中の一時的な helper ではなく、開発システムの workstation に近い存在です。

Agent list、use case、description、tool boundary をモデルに渡し、モデル自身がその turn に適した role を選ぶことができます。これにより委任はより自動化されます。

この方向性を支える要素はいくつかあります。

第一に role system。explorer、planner、general-purpose、verifier などの role が用途説明、tool restriction、default model、runtime condition を持てます。read-only explorer は編集できず、planner は設計に集中し、verifier は検証に集中します。

第二に inheritance と override。Subagent は完全に自由ではありません。main session の大きな境界を継承しつつ、許可された範囲で局所的に振る舞いを調整します。

第三に memory。memory は単に少し覚えることではなく、scope を持ちます。user memory は長期的な好み、project memory はリポジトリ背景、local memory は現在環境の状態です。

第四に background work と worktree isolation。検証 task は background で走り続けることができ、main thread は待ち続けなくて済みます。強い隔離が必要なときは別 worktree で作業できます。

第五に plugin ecosystem。Agent を first-class object と見るなら、配布、インストール、優先順位、override、安全境界を考える必要があります。plugin agent は入れられますが、permission mode、hooks、MCP servers など高リスク領域は制限されるべきです。

これにより Claude Code は単発 session の協作ツールではなく、Agent runtime に近く見えます。

違い

Codex は制御された分業ツールに近いです。

明示的な委任。
軽量な role set。
明確な制御フロー。
現在 session 中心の subtask。
人が orchestration する確定的な作業に向く。

Claude Code は engineering workstation system に近いです。

Agent が正式に model 化される。
role が体系化される。
memory、background、isolation、plugin が runtime に含まれる。
モデルが role 選択に関与できる。
長期 project や platform 的 workflow に向く。

問題は機能数ではありません。Subagent を「自分が明示的に呼ぶ helper」と見るか、「system に長期存在する workstation」と見るかです。

選び方

明示的な制御、軽量な分業、現在 session 内の安全な並行処理を重視するなら Codex 的な設計が合います。コードレビュー、小さな変更、明確な実装 task、人がリズムを握りたい workflow に向きます。

体系化された role、長期 memory、background execution、worktree isolation、plugin extension、より完全な Agent runtime を求めるなら Claude Code 的な設計が合います。

判断する質問は 2 つです。

モデル自身が誰に仕事を任せるか選ぶことを受け入れられるか。
より完全な Agent runtime が必要か。

1 つ目が不安なら明示的委任が向いています。2 つ目が yes なら、platform 的な workstation system が向いています。

使い方の注意

Subagent を「モデルを増やせば強くなる」と考えない方がよいです。

各 role の task boundary を明確にする。
role ごとの tool を制限する。
raw log ではなく結論を返させる。
最終判断は main session に残す。
background task と worktree isolation を可視化する。
plugin agent に安全境界を置く。

Subagent の価値は数ではなく分業品質です。role が明確で context がきれいなほど、main thread の判断は安定します。

まとめ

Codex と Claude Code は同じ問題に向き合っています。単一 Agent は実際の開発作業をすべて背負いにくい。両者とも context isolation、role specialization、permission boundary、local summarization を重視します。

違いは設計の方向です。Codex は抑制的で、明示的委任と main session の制御を重視します。Claude Code は体系的で、Agent を設定、記憶、隔離、background 実行、plugin ecosystem に対応した正式な workstation として扱います。

選択はブランド勝負ではありません。必要なのが制御された協作ツールなのか、完全な Agent runtime なのかで決まります。

9Router：Claude Code、Codex、Cursor を 1 つの AI ルーターにつなぐ

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

9Router は AI コーディングツール向けのローカルルーターです。Claude Code、Codex、Cursor、Cline、Copilot、OpenCode、OpenClaw などを 1 つの OpenAI-compatible endpoint に接続し、そこから複数のモデルや provider に転送します。

目的はチャットクライアントを増やすことではありません。AI コーディングツールとモデル provider の間に入り、API 形式の違い、provider の手動切り替え、ツール出力による token 消費、quota 切れ、複数アカウント管理をまとめて扱います。

README によると、9Router は 40 以上の provider と 100 以上のモデルに対応し、RTK Token Saver、自動 fallback、quota 追跡、複数アカウントのローテーション、形式変換、リクエストログを備えています。JavaScript 製で、Node.js、Next.js、React、Tailwind CSS、LowDB を使い、MIT ライセンスです。

何に向いているか

複数の AI コーディングツールと複数のモデル供給元を同時に使う場合に便利です。

Claude Code はサブスクリプションで使う。
Codex や Cursor にカスタム OpenAI endpoint を設定したい。
Cline、Continue、RooCode に OpenAI-compatible API を渡したい。
無料 provider を試用に使う。
GLM、MiniMax、Kimi などを安価なバックアップにする。
高品質モデルを難しいタスクだけに使う。

通常は各ツールに endpoint、API key、モデル名、fallback を個別設定する必要があります。9Router はそれをローカルのルーティング層に集約します。

API:

`1`	`http://localhost:20128/v1`

Dashboard:

`1`	`http://localhost:20128/dashboard`

インストール

ローカル利用なら npm が簡単です。

1
2

npm install -g 9router
9router

ソースから実行する場合：

git clone https://github.com/decolua/9router.git
cd 9router
cp .env.example .env
npm install
PORT=20128 NEXT_PUBLIC_BASE_URL=http://localhost:20128 npm run dev

本番起動：

1
2

npm run build
PORT=20128 HOSTNAME=0.0.0.0 NEXT_PUBLIC_BASE_URL=http://localhost:20128 npm run start

npm パッケージは Node.js >=18.0.0 を要求します。VPS や Docker では JWT_SECRET、INITIAL_PASSWORD、DATA_DIR、API_KEY_SECRET を設定してください。

ツールの接続

一般的な設定：

1
2
3

Base URL: http://localhost:20128/v1
API Key: 9Router Dashboard からコピー
Model: 9Router で設定したモデル名または combo 名

Codex CLI:

export OPENAI_BASE_URL="http://localhost:20128"
export OPENAI_API_KEY="your-9router-api-key"

codex "your prompt"

Cline、Continue、RooCode では OpenAI Compatible を選びます。

1
2
3

Base URL: http://localhost:20128/v1
API Key: your-9router-api-key
Model: cc/claude-opus-4-7

モデル名は接続済み provider によって変わり、cc/、cx/、gh/、glm/、minimax/、kr/、vertex/ などがあります。

RTK Token Saver

AI コーディングでは以下のようなツール出力が token を大きく消費します。

git diff
git status
grep
find
ls
tree
ログ
長いファイル一覧

9Router の RTK Token Saver は、これらをモデルに送る前に圧縮します。プロジェクト説明では、多くのリクエストで 20%-40% の input tokens を節約できるとされています。

ただし、重要なログや完全なファイル内容が必要な場面では、圧縮が回答品質に影響しないか確認してから使うのが安全です。

自動 fallback

モデルを優先順に並べられます。

1
2
3

1. サブスクリプションモデル
2. 安価な API
3. 無料 provider

例：

1
2
3

1. cc/claude-opus-4-7
2. glm/glm-5.1
3. kr/claude-sonnet-4.5

fallback は作業停止を減らしますが、モデルが変わると出力の一貫性も変わります。大規模リファクタリングや移行では固定モデルを使う方が安全です。

無料 provider の注意点

Kiro、OpenCode Free、Vertex などの無料経路は便利ですが、利用条件、地域制限、サードパーティツールでの利用可否、ban や rate limit、期限を必ず確認してください。9Router はルーティングを管理するだけで、上流 provider の規約は変えません。

デプロイ

個人利用なら localhost のみで十分です。VPS や LAN で公開するなら、デフォルトパスワードを変更し、強い JWT_SECRET と API_KEY_SECRET を設定し、Dashboard を公衆インターネットに直接出さず、/v1/* に Bearer API key を要求します。

docker run -d \
  --name 9router \
  -p 20128:20128 \
  --env-file ./.env \
  -v 9router-data:/app/data \
  -v 9router-usage:/root/.9router \
  9router

まとめ

9Router は AI コーディングツールのローカル gateway です。Claude Code、Codex、Cursor、Cline などを http://localhost:20128/v1 に集約し、モデル選択、形式変換、token 圧縮、quota 追跡、fallback を処理します。

複数 provider を使う重めの AI コーディングユーザーに向いています。まず 1 つのツールと 1 つの provider から試し、徐々に combo とアカウントを増やすのが無難です。

参考資料

DeepSeek-TUI：ターミナルで DeepSeek コーディング Agent を動かす

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

DeepSeek-TUI はターミナルで動く AI コーディング Agent です。DeepSeek V4 モデルを中心に設計され、deepseek コマンドで起動します。TUI 内でファイルの読み書き、shell コマンド、web search、git、MCP server、sub-agent 協調を扱えます。

単なるチャット CLI というより、ターミナル上の作業台です。コードを読む、ファイルを編集する、コマンドを実行する、診断を見る、セッションを保存する、状態を戻す、という開発動作を 1 つにまとめます。

リポジトリは主に Rust で書かれ、MIT ライセンスです。

向いている人

DeepSeek-TUI は、ターミナル中心の開発者が DeepSeek モデルをローカル開発に組み込みたい場合に向いています。

DeepSeek でコード修正やプロジェクト分析をしたい。
フル IDE を開きたくない。
AI に workspace を読ませ、必要に応じて編集させたい。
Plan、Agent、YOLO を使い分けたい。
セッション保存、長時間タスク再開、rollback が必要。
MCP、LSP 診断、HTTP/SSE runtime API、skills を使いたい。

簡単な Q&A だけなら web や軽量 CLI で十分です。DeepSeek-TUI はモデルをローカル開発フローに入れたい人向けです。

インストール

npm:

1
2
3

npm install -g deepseek-tui
deepseek --version
deepseek --model auto

npm パッケージは事前ビルド済み Rust バイナリを取得する installer/wrapper で、Node.js >=18 が必要です。

Cargo:

1
2

cargo install deepseek-tui-cli --locked
cargo install deepseek-tui --locked

Homebrew:

1
2

brew tap Hmbown/deepseek-tui
brew install deepseek-tui

GitHub Releases から Linux x64/ARM64、macOS x64/ARM64、Windows x64 のバイナリも入手できます。

Docker:

docker run --rm -it \
  -e DEEPSEEK_API_KEY \
  -v "$PWD:/workspace" \
  ghcr.io/hmbown/deepseek-tui:latest

API Key

初回起動時に DeepSeek API key を入力し、以下へ保存します。

`1`	`~/.deepseek/config.toml`

手動設定：

1
2

deepseek auth set --provider deepseek
deepseek auth status

環境変数：

1
2

export DEEPSEEK_API_KEY="YOUR_KEY"
deepseek

診断：

`1`	`deepseek doctor`

保存済み key の削除：

`1`	`deepseek auth clear --provider deepseek`

Auto mode

`1`	`deepseek --model auto`

TUI 内:

`1`	`/model auto`

Auto mode はモデルと thinking を同時に選びます。

Model: deepseek-v4-flash または deepseek-v4-pro
Thinking: off、high、max

本番リクエスト前に小さな routing call を行い、最新の依頼と文脈からモデルと thinking を決めます。auto はローカル機能で、上流 API には具体的なモデル名が送られます。

ベンチマーク、厳格なコスト管理、固定挙動が必要な場合は明示的にモデルを指定します。

モード

モード	用途
Plan	読み取り専用の調査と計画
Agent	承認ゲート付きの通常モード
YOLO	信頼済み workspace で自動承認

YOLO は便利ですが危険も大きいため、信頼できる一時ブランチやテストディレクトリで使うべきです。

主な機能

ファイル操作、apply patch、shell、git、web search/browse、sub-agent、MCP、LSP 診断、セッション保存と再開、workspace rollback、永続 task queue、HTTP/SSE runtime API、skills system に対応します。

LSP 診断は編集後のエラーをモデルへ戻せる点が便利です。rollback は side-git snapshot を使い、/restore と revert_turn を提供します。ただし通常の git commit は引き続き重要です。

よく使うコマンド

deepseek
deepseek "explain this function"
deepseek --model deepseek-v4-flash "summarize"
deepseek --model auto "fix this bug"
deepseek --yolo
deepseek auth set --provider deepseek
deepseek doctor
deepseek doctor --json
deepseek models
deepseek sessions
deepseek resume --last
deepseek resume <SESSION_ID>
deepseek fork <SESSION_ID>
deepseek serve --http
deepseek serve --acp
deepseek pr <N>
deepseek mcp list
deepseek mcp validate
deepseek update

Zed / ACP

{
  "agent_servers": {
    "DeepSeek": {
      "type": "custom",
      "command": "deepseek",
      "args": ["serve", "--acp"],
      "env": {}
    }
  }
}

README によると、現在の ACP は新規セッションと prompt response を扱いますが、tool-backed editing と checkpoint replay はまだ公開されていません。

設定と provider

ユーザー設定：

`1`	`~/.deepseek/config.toml`

workspace overlay：

`1`	`<workspace>/.deepseek/config.toml`

api_key、base_url、provider、mcp_config_path などは workspace overlay で禁止されています。

OpenAI-compatible:

1
2

deepseek auth set --provider openai --api-key "YOUR_OPENAI_COMPATIBLE_API_KEY"
OPENAI_BASE_URL="https://openai-compatible.example/v4" deepseek --provider openai --model glm-5

Ollama:

1
2

ollama pull deepseek-coder:1.3b
deepseek --provider ollama --model deepseek-coder:1.3b

まとめ

DeepSeek-TUI は DeepSeek V4、TUI、tool call、LSP 診断、セッション再開、rollback、MCP、skills を 1 つの Rust ベースの作業環境にまとめたターミナル Agent です。軽量さよりも、ローカル開発フローへ深く入ることに価値があります。