1. JustFit
  2. ブログ
  3. PDD Kit登場、AIのコードを仕様に照らして証明する

PDD Kit登場、AIのコードを仕様に照らして証明する

JustFit編集部（運営：株式会社LEGAREA）

GitHub NextとMicrosoft Researchが、AIが書いたコードを「仕様に照らして証明する」ツール「PDD Kit」を研究プレビューとして示しました。この記事では、公式の投稿で確認できた仕組みと対象の範囲を整理します。そのうえで、新規事業のシステム開発で何が変わりうるかを、事実と編集部の見方に分けて書きます。

10月21日に告知されたPDD Kitの中身

GitHub Nextは10月21日、Microsoft Research発の「Proof Driven Development Kit（PDD Kit）」を紹介しました。GitHubの公式アカウントは、PlanningツールのChopinとPDD Kitの組み合わせを研究プレビューとして案内しています。コードを1行ずつ読まなくても、AIが生成したコードを本番へ出せることを狙った取り組みです。

ここで出てくる「形式仕様」と「形式検証」を、先に短く説明します。形式仕様は、プログラムが満たすべき条件を数学的な書き方で厳密に書いたものです。形式検証は、その条件をコードが満たすことを機械で確かめる方法です。テストが「いくつかの入力で試す」確認なのに対し、形式検証は「条件を満たすすべての入力」を対象にします。

示された流れ：計画から、証明済みのプルリクエストまで

GitHub Nextの投稿は、アプリのログインの流れを例に、意図の整理から検証済みのプルリクエスト（コード変更の提案）までを示しています。PDD Kitはコードについて対話し、意図を推測しながら、Rust向けの証明言語「Verus」で形式仕様を提案します。流れを整理すると、次の5段階です。

  1. チームでChopinを使い、機能の計画を立てる。Chopinは、GitHub Nextの複数人で同時に使える計画ツールです。
  2. PDD Kitが、計画をもとに形式仕様の案を作る。
  3. 人が仕様を承認すると、Verusの検証器が、コードがその仕様を満たすことを自動で証明します。
  4. 証明が難しい部分は、テストや、画面を操作するAI（computer-use agents）による実測の確認で補います。
  5. 結果が、検証済みのプルリクエストとして出てくる。

投稿によると、新しい言語は不要で、コードの作り方も変えずに使えます。目指す姿は、エンジニアがコードの代わりに仕様をレビューする「検証済みのソフトウェア工場」です。

Microsoft Researchも、同じ考え方を説明しています。開発者の意図を形式仕様に変え、形式検証で生成コードがそれを満たすことを証明するもので、Rust向けのVerusと、ChopinをつなぐことでAI支援の開発の流れに形式手法を取り込むとしています。この連携は、10月28〜29日のGitHub Universeで披露される予定です。

対象はRustだけ、段階は研究プレビュー

実際に使えるかどうかは、対象と段階を分けて見る必要があります。

GitHub Nextの投稿は、対応しているのは現時点でRustだと書いています。TypeScriptやPythonでコードを書かせている場合は、今のところ入れられるものがない、という指摘もあります。段階についても、計画の土台になるChopinは、GitHub Nextのプロジェクト一覧で2026年9月付けの研究プロトタイプとされています。つまり現時点では、すぐ事業の標準にする道具というより、方向性を示す研究成果として見るのが妥当です。

なお、同じ「PDD Kit」という名前でも別のツールがあります。たとえば、別の開発者が公開しているOSSのpdd-kitは「Product-Driven Development」で、製品の内容を、人とAIが共有するモデルとして管理するものです。今回のGitHub Next・Microsoft Researchのものとは別物なので、検索するときは区別が必要です。また、一部の媒体は略称の中身を別の言葉で説明し、検証結果の数字も載せています。公式の投稿では確認できなかったため、この記事では使いません。

編集部の見方：確認の中心が、コードから仕様へ寄っていく

ここからは事実ではなく、JustFit編集部の見方です。

見方1：人に残る仕事は、仕様を読んで承認すること

PDD Kitの流れで人が承認するのは、コードではなく仕様です。ただし、証明できるのは「書かれた仕様をコードが満たすこと」までです。仕様が利用者の必要とするものと合っているかは、証明では確かめられないという指摘もあります。

そのため、AIが速く書くほど、「何を満たすべきか」を言葉にして決める工程の重みが増すと私たちは考えます。これは、AI要件定義で変わることや、AI開発の仕様の伝え方で整理してきた話の延長にあります。

見方2：間違いが事業の信用に響く部分から、条件を言葉にする

新規事業のシステムには、動いて見えても間違えると困る部分があります。たとえば、権限、予約の重複、金額の計算などです。こうした部分は、画面を触るだけでは条件の抜けに気づきにくい領域です。

PDD Kitのような仕組みが広がるかどうかにかかわらず、「この条件は常に成り立つ」という文を先に書いておく習慣は、AIが書くコードを確認する足場になります。AI生成コードのセキュリティで触れた「確認点を先に決める」考え方とも重なります。

見方3：証明・テスト・人の確認は、置き換えではなく使い分けになる

PDD Kit自身が、証明できない部分はテストと実測の確認に回す設計です。また、ある報道は、仕様の質、依存関係、セキュリティの境界、デプロイ時の挙動などは人のレビューの対象として残ると整理しています。

私たちも、確認を一つの方法に寄せるのではなく、部分ごとに使い分ける形になると見ています。テストの役割はAIのテスト自動生成、人の確認が必要な理由はAI開発でも品質には人の確認が必要な理由で整理しています。

公式の告知だけでは分からない点

次の点は、今回の調査では確認できていません。

  • 詳細な公式資料：確認できたのは、GitHub Next、GitHub、Microsoft Researchの公式アカウントの投稿と、それを解説した報道です。githubnext.comなどの詳細ページは開いて確認できていません。
  • 第三者による検証：GitHubの説明は、提供側が自分たちの研究プレビューを語ったもので、監査済みの結果ではないという指摘があります。実際のコードでの効果は、今後の実演や検証を待つ段階です。
  • 利用条件と一般提供の時期：使い方の条件や、研究プレビューから先の予定は確認できていません。

新規事業の判断に使うなら、まず10月28〜29日のGitHub Universeでの実演など、新しい情報を待つのが現実的です。

まとめ

PDD Kitは、AIが書いたコードを人が1行ずつ読む代わりに、仕様を人が承認し、検証器がコードを証明する流れを示した研究プレビューです。対応はRustのみで、計画ツールChopinも研究プロトタイプの段階です。一方で、AIがコードを書く量が増えるほど、確認の中心が「仕様を決めて読む」ほうへ寄っていく流れは、他のニュースとも共通しています。

私たちJustFitは、構想をもとに約1ヶ月で動くプロトタイプを先に作り、実物を見てから契約を判断していただく受託開発サービスです。AIを活用した開発基盤LAFを使う場合も、人の役割は「何を作るかを決めること」と「品質の最終判断」だと考えています。新規事業で仕様がまだ固まっていない段階でも相談できます。詳しくはJustFitのサービス紹介をご覧ください。

参考にした情報

← ブログ一覧へ