ソフトウェア工学 on KnightLiブログ

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 を保守可能で検証可能な工学体系に組み込めるかどうかだ。

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% を取ったことではありません。問題集がすでに置かれたことです。