「仕様書が新しいコードになる」AIがプログラムを書く時代、開発者に求められる能力とは

Kaseyaの最高技術責任者（CTO）を務めるPratik Wadher氏が、AIを活用してストレージ層をわずか6週間で再設計し、コードの実装からテストまで完了させたと明かした。10月21日に公開されたThe Registerのインタビューで語ったもので、人間が仕様書を作成・検証し、AIがそれに基づいてコードを生成する新たな開発手法について説明している。Wadher氏は「仕様書が新しいコードになる」と述べ、今後の開発者にはプログラミング言語の知識だけでなく、業務への深い理解と、設計意図を明確な文章で伝える能力が重要になると指摘した。

ただし、6週間という開発期間の背景には、長年にわたって蓄積された専門知識がある。AIに指示するだけで複雑なシステムを短期間で構築できたわけではなく、仕様書を保存すれば常に同じ品質のコードを再生成できると実証されたわけでもない。今回の事例が示唆するのは、AIによってコードを書く作業が効率化されるにつれ、開発者の役割が設計条件の明確化や生成結果の検証へと移りつつあることだ。

ストレージ層の再設計から実装・テストまで6週間で完了

Wadher氏が紹介したのは、Kaseyaのストレージ製品を支えるバックエンドの再設計だ。同社は、ZFSやAmazon S3など、異なる仕組みの保存先に対応できる共通のストレージエンジンを開発した。従来の構成を見直し、データの読み書きに関わる処理を再設計したうえで、コードの実装とテストまでを6週間で終えたという。この期間はストレージ層の開発に関するものであり、Kaseyaが提供するすべての製品やシステムを6週間で統合したという意味ではない。

また、Wadher氏は、どのような仕組みを構築すべきかを理解するためには、何年にもわたる専門知識の蓄積が必要だったと説明している。ストレージ技術への理解に加え、既存製品の構造や顧客が求める機能を把握していたからこそ、AIに適切な設計条件を示すことができたというわけだ。6週間という数字は、こうした知識や経験を持つ技術者が設計上の判断を行ったうえで、再設計から実装・テストまでを進めた期間を指している。AIがゼロから要件を理解し、短い指示だけでシステムを完成させた事例として受け取るべきではない。

なお、従来の手法で同じ作業に何週間かかっていたのか、開発に何人が参加したのか、総工数や欠陥率がどの程度変化したのかは明らかにされていない。そのため、今回の事例からAIによって開発速度が何倍になったかを算出することはできない。あくまでKaseyaのCTOが紹介した個別の開発事例であり、同じ方法を採用すれば他の組織でも同様の期間で開発できるとは限らない。それでも、設計から実装・テストまでの工程にAIをどのように組み込んだかは、企業がAIによるソフトウェア開発を検討するうえで参考になる。

コードを書く前に仕様書を作成・レビューする開発手法

Kaseyaが採用した開発手法の特徴は、AIにコードを書かせる前に、仕様書の作成とレビューに十分な時間をかけることだ。同社では、まず人間がAnthropicのコーディングエージェントの支援を受けながら仕様書を作成し、その内容を繰り返し修正する。さらに、開発者同士のレビューに加え、仕様の問題点を指摘する批評用のAIエージェントも活用し、内容を検証したうえでコード生成へ進むという。The Registerによると、AnthropicのClaudeはKaseya社内でコードを生成する際の事実上の標準になりつつある。

この手法では、開発者が確認すべき対象が、完成したコードだけでなく、その前段階にある仕様書にも広がる。AIに実装を任せる前に、何を作るのか、どのような動作が必要なのか、どの制約を守るべきなのかを明確にする必要があるためだ。Wadher氏が業務知識と文章力の重要性を強調するのも、この開発工程の変化と関係している。文章が明確であっても、対象となる業務や製品の仕組みを理解していなければ、必要な動作や制約を正しく指定できない。

Wadher氏は、今後の開発者には批判的思考力と文章力が特に重要になると指摘する。従来、開発者が負担に感じることも多かった設計書や機能仕様書の作成が、AIによる開発ではむしろ中心的な作業になるという見方だ。AIを使えば仕様書の作成や修正を支援してもらえるが、何を実現するべきかを判断するには、依然として人間の専門知識が欠かせない。同氏は、AIにコードを生成させるだけでは、開発者としての価値も生成されるコードの有用性も高まらないと説明している。

Kaseyaがこうした開発手法を採用する背景には、同社が進める製品群の統合もある。Kaseyaは2026年4月28日の公式発表で、IT運用、サイバーセキュリティ、バックアップなどのデータを統合し、AIが状況を判断して自律的に処理を実行するプラットフォーム構想を示した。バックアップ分野でも、オンプレミス環境、SaaS、端末、クラウドのデータ保護を単一のポータルで管理する仕組みを打ち出している。Wadher氏も今回のインタビューで、データとAPIの統一に加え、製品間で共通する業務フローを集約することを目的に挙げた。

今回のストレージ層の再設計が4月に発表された構想と同じ開発成果に当たるかは確認できないものの、両者は製品間で共通する機能を整理するという方向性で一致している。異なる保存先に対応するストレージエンジンを設計するには、どの機能を共通化し、保存先ごとの違いをどのように扱うかを決めなければならない。こうした判断には既存システムへの理解が必要であり、コードの生成をAIに任せられるとしても、設計上の判断まで自動的に解決されるわけではない。

仕様・技術計画・検証を分けることが重要に

仕様書を中心に据える開発手法は、Kaseya独自のものではない。GitHubは2025年9月、AIを活用した仕様駆動開発（Spec-Driven Development）を支援するオープンソースツール「Spec Kit」を公開している。GitHubの公式解説では、まずソフトウェアの目的や必要な機能を仕様として定義し、その後に技術的な実装計画を作成する。さらに、計画を検証可能な小さなタスクへ分解し、AIによる実装へ進むという工程を紹介している。

これはKaseyaがSpec Kitを採用したという意味ではないが、AIにコードを生成させる前に仕様を明確にするという考え方は共通している。仕様書には利用者の要求や期待する動作を記述し、技術計画にはシステム構成や既存環境との接続条件、実装上の制約をまとめる。そのうえで、実装した機能が期待どおりに動作するかをテストなどで確かめる。目的の定義、実装方法の選択、動作の検証を分けることで、それぞれの段階で何を確認すべきかが明確になる。

GitHubの開発手法とAnthropicが公開するClaude Codeの公式指針を踏まえると、開発工程で残すべき成果物と、その役割は次のように整理できる。

成果物	確認・判断する内容	それだけでは判断できないこと
仕様書	誰のために何を作り、どのような状態を成功とするか	実装が期待どおりに動作するか
技術計画	どのような構成で実装し、既存システムの制約をどう満たすか	実際の環境で想定どおりの結果が得られるか
検証結果	テストやビルド、画面比較などで期待する動作が確認できたか	試験していない条件でも正しく動作するか

この表は、両社が示す開発手法を基に、各成果物の役割を整理したものだ。仕様書は目的と要求を明確にし、技術計画はそれを実装するための構成や制約を定める。そして検証結果は、完成した実装が実際に期待する動作を満たしているかを判断する材料となる。GitHubは各段階で人間が成果物を確認する重要性を強調しており、AnthropicもAIにテストやビルド、画面比較などの検証手段を与え、生成結果を自ら確認できるようにすることを推奨している。

例えば、ストレージへのデータ書き込みに失敗した場合を考えてみよう。仕様書に単に「データを保存する」と書くだけでは、保存に失敗した際にどのような処理を行うべきかが明確ではない。エラーを利用者にどう通知するか、再試行を認めるか、どの状態を正常と判断するかといった条件を仕様として定めれば、生成されたコードが要求を満たしているかを検証しやすくなる。これはKaseyaが実際に採用した仕様の説明ではなく、業務上の要求を検証可能な条件へ落とし込むための例だ。

ただし、仕様書の内容が正しいことと、生成されたプログラムが正しく動作することは別の問題である。仕様書に必要な条件が欠けていれば、AIがその指示どおりにコードを生成しても、利用者が求める動作を満たさない可能性がある。一方、仕様書が十分に整理されていても、実装時に不具合が生じることはあり、実際にテストしなければ動作の正しさは確認できない。また、テストが成功したとしても、その結果が検証していない条件での動作まで保証するわけではない。仕様のレビューと実装の検証は、どちらも欠かせない工程となる。

「仕様書が新しいコード」でも、再生成の正確性は保証されない

Wadher氏は、AIによる開発が普及すれば、GitHubに保存する重要な成果物がコードから仕様書へと移っていくとの見方を示している。仕様書を保存しておけば、それを基準にAIが繰り返し同じ種類のコードを生成できるという考え方だ。ただし、同氏自身も、AIが生成する結果にはばらつきがあることを経験したと認めている。「仕様書が新しいコード」という表現は、仕様書がプログラミング言語のように実装を一意に決定するという意味ではなく、開発の基準として仕様が重要になることを表している。

そのため、実務では仕様書を保存するだけでなく、再生成された実装が期待する動作を満たしているかを確かめる仕組みが必要になる。仕様書に加えて技術計画やテスト結果を残しておけば、AIが前回とは異なるコードを生成した場合でも、設計上の制約を守っているか、必要な機能が動作するかを比較できる。重要なのは同じコードが生成されることではなく、異なる実装であっても、求められる条件を満たしているかを判断できることだ。コードの行数や生成速度だけでは、その品質を評価することはできない。

Kaseyaが報告した6週間という開発期間も、AIによるソフトウェア開発の可能性を示す一方、その効果を評価するには追加の情報が必要となる。従来の開発に要した期間や総工数に加え、生成したコードがどのようなテストに合格し、どの程度の修正を必要としたのかが分かれば、他の開発手法との比較もしやすくなる。仕様を中心に据えた開発が本当に効率的かどうかは、コードを生成する速さだけでなく、要求を満たしたソフトウェアを安定して完成させられるかによって判断すべきだ。

今回の事例が示すのは、AIによって開発者の仕事がなくなるというより、求められる専門性が変化しているということだ。コードの記述をAIに任せられる範囲が広がるほど、業務上の要求を理解し、適切な設計条件を定め、生成結果を検証する能力が重要になる。Kaseyaの取り組みが他の開発現場でも再現可能かは今後の検証を待つ必要があるが、仕様書と検証結果を開発の中心に据える考え方は、AIを使ったソフトウェア開発の品質を確保するうえで重要な方向性といえる。