アルゴリズムとかオーダーとか

仕事で勉強したことなどをまとめてます

Spec Kit + Claude Codeを試してみた（感想雑記）

最近話題の Spec Driven Development を試してみた感想記。ツールはspec kit を利用した。

spec kitのインストール方法などは下記を参考に行った。
azukiazusa.dev

簡単なLLM Chatアプリを作成。コードは以下のリポジトリにアップしている。
github.com

spec kit利用で期待したことは以下の３つ。
1. ある程度大きなタスクをClaude Codeで自走できるようにしたい
2. 仕様を明確化してAIと共同作業ができること
3. TDD順守による仕様に準拠したコードをLLMが生成できること

以下、試してみた感想をつらつらと書いてみる。

自分のAI利用状況

自分はClaudeのMax Planに加入（chaintopeではAI補助で$100/月まで利用可能なので！）して、プログラムの8割ぐらいはClaude Codeで作成。仕様書の作成や工数見積もりなどもClaude Codeを使いながら作成するなど常に利用している。ただ、cursorやkiroなどのフルスペックなcoding アシスタント的なLLMツールは使ったことがない。

claude codeをかなり活用していて日頃から思うことは、LLMはサブタスクに分解が必要なまとまったタスクをお願いするにはまだまだそこまで頭がよくないということ。

とはいえ、AIができる範囲はどんどん広がっているので、可能ならば使い方の工夫で何とかシンプルなアプリをProduction品質を保ったまま作成できるぐらいにならないかな？と思っていた。
そのため、今回はspec kitを使って前述したことが可能なのかを試してみた。

率直な感想

spec kitでなんとなくいい感じに作業しているようには見えるが、その実中身は期待するほどのものではなかった。これならvibe codingのほうがマシかなと思う。

最近Antholopicから応答品質が低下していた原因についてアナウンスされて、体感でも頭が良くなった気がするが、上記を試したのは数週間前(2025年8月末ぐらい)なのであんまり頭が良くなかった時期ではある。

やったこと

最初はspec kitに雑に大まかな仕様を /specで投げた後、シンプルに /plan, /tasks を実行してほぼすべてをspec kit任せで作成した。
結果として、作成された単体テストが8割以上失敗するという壮大なごみが生成されたのでもう少しやり方を変えることにした。

２回目では先の失敗を踏まえて、/specで仕様を投げた後に、claude codeに「仕様にあいまいなものがないかチェックし、少しでもあいまいなものがあれば質問して」みたいなクエリを何度もなげて、claude codeと相談しながら仕様を細かく詰めていった。
また、claude codeは与えられた仕様を満たすアプリを一気に作り上げるようなplanを生成してしまうので、そうではなく複数のステージに分けて、段階的に実装すること、各ステージではそれぞれ稼働・利用できるアプリとなることを指示し、ステージごと１つの機能を作るように集中するよう指示を行いながら計画を作成した。

/spec, /plan, /tasksに費やした時間はおそらくだが6時間以上と思う。（暇なときに片手間でやってたので正確ではないが。。。）その結果出来上がったのが冒頭のリポジトリの内容である。
正直できたものだけを考えると、仕様書策定に使った時間を使ってvibe codingしたほうがもっといいものができたのでは？と感じた。

「現状の」LLMの限界

自分はLLMにほとんどの作業を任せているが、それでもやはり現状のLLMには明確な限界があると感じている。Cursorの紹介ページにも書いている通り、いわゆるジュニアエンジニア程度の能力しか持ち得ていない。場合によってはそれ以下と感じることが多い。

よくある事例だと

  • 失敗したテストの修正をお願いしたら、四苦八苦した挙句にテストコードをスキップするように修正して満足気に報告してくる
  • 複雑な対象のテスト作成をお願いしたら、テストの中にmockコードを作成して、そのmockをテストするコードを作成して満足気に報告してくる
  • ちょっと複雑なエラーの解決をお願いしたら、修正はできるがほかの部分でエラーが発生。その修正をまたお願いすると１つ前のエラーが復活など容易にデグレループを起こして解決できずに混乱する。

とかがある。これらは通常使っていると結構な割合で発生する。これは以下のLLMの弱点を裏付ける論文などからわかる通り、現状のLLMはコーディングの本質というか、ものごとの本質を理解しているわけではないことがうかがえる。
ledge.ai
gigazine.net

とはいえ、人間に比べてかなりのスピードでコードを作成できることに疑いはなく、軽微なエラーなどは爆速で修正してくれるので十分効率アップにはつながっている部分もある。
が、それと同時に感じるのはなんで自分がAIにコーディングの指導までしないといけないんだろうか？という何ともやるせない気持である。
ちょうど最近見た以下の記事がまさに感じていることを表現していた。

yamdas.hatenablog.com

LLMができること・できないこと

ここは本当に僕がただ漠然と感じていることを書いてみる。技術的根拠は一切ないので凡人のただの感想程度に読んでほしい。

現状のCoding LLMがどういうものかを自分なりに表現すると「超高性能で高速なコピペマシーン」なのかと感じている。コードの内容を理解しているわけではなく、質問に対してその内容を細かく構造分解し、それにマッチする「答えとしてのコード」を引っ張り出して張り付けているだけである。

なので「全件テストがパスすること」という指示に、「テストをスキップさせることでパスする」という結果を導き出す。これはLLMがQ&Aの結果として対象コードを導き出すと考えると辻褄があうと感じている。LLMが学習時に参考にしたコーディング記事などは膨大と考えると、その中にはもちろんテストを一時的にスキップしてfailureを消すというものも含まれる。LLMとしてはテストの失敗ログからその解決策を記憶を頼りに探しはするが、そのものずばりの解決策が記憶から引っ張り出せない場合は、時点の解決策を持ってくるため上記のようにスキップすることでテストをパスさせてしまうのではないかと思う。

つまるところ「ポチョムキン理解」と揶揄されるように現状のLLMは指示やコードの内容を理解しているわけではなく、膨大な記憶の中から現状に一番即した丸暗記したコードをコピペしているだけである。それはそれで指示内容はエラーの内容をより微細に分解したうえでのコピペを行うため、大概のものは解決できるので便利ではあるが、一方で本質的に理解してるわけではないのでイライラすることも多いのである。

LLMのコードはなぜに読みにくいのか？

上述した「超高性能で高速なコピペマシーン」であるLLMが生成するコードは非常に読みづらいと感じることが多い。これは単にコード量が多いからというだけではない。その理由はLLMが行っているのは高度に洗練されたコードのコピペなので、LLMが生成したコードの全体にいわゆる「癖」みたいなのがなく、非常につぎはぎだらけのコードに感じるからなのではと思っている。

ある程度シニアエンジニアになり多くのライブラリなどのコードを読んできた人だと、コードを読むだけでその人の癖や何を意図していたのかなどをなんとなく読み取れるものである。かの有名なBPSでもそんなエピソードがあるし。
しかしLLMが記述するコードは本質的にコピペなので、数行単位でその「癖」がコロコロ切り替わり、一貫性がないコードが生成される。人間は文章やコードを読むときはその「癖」のようなものを読み取り、そこから少し先を予測しながら文章を読むことで理解を進める。そのため、癖がコロコロと変わるようなものは非常に理解しにくいと感じるのである。これがLLMが生成したコードが読みにくいと感じる本質的な原因で、また「超高性能で高速なコピペマシーン」であるLLMが生成するコードがそのようになってしまうのはしょうがないのかもしれない。
2年ぐらい前に、AIイラストに対して絵描きの人が「いろんな人の絵をつぎはぎしたような違和感」と表現してて（具体的に何がおかしいか指摘してたツイートなんだけど、探しても見つからなかった。。）、LLMが生成するコードにも同様の違和感を感じる。

今のagentやcontextを与える方法の限界

上記のようなLLMの限界みたいなものはいろんなところでみんなが感じているとは思っており、それゆえに今回試したようなspec kitなどが開発されていると思っている。要は使い方を工夫することでもっとLLMを活用できないか？という試作である。

ただ、これにも自分はすぐに行き詰るんじゃないかな？と感じている。理由は２点。

  • LLMが生成するコードは事前学習で得られた知識からしか生まれない
  • Contextや指示を与えることで強制できるのは限定的

いわゆる、今のLLMがリアルタイム学習機能を持ち得ていないことにすべては起因しているというものである。現状のLLMの大きな限界は「忘れっぽいこと」である。なので、Contextや背景などをmdファイルで用意して、毎回LLMに読み込ませることで「忘れっぽい」を克服しようとしている。
ただ、これは容易に限界を迎えると思っている。理由は最終的にLLMが生成するコードは事前学習で得られた知識の範囲からしか生まれないためである。Contextや詳細な指示を与えることで一時的に新しい知識を与えられたように感じるが、これはLLMとやり取りをしていくことでだんだんと薄れていってるように感じる。また、より複雑な指示についてはその内容を詳細に分解し、個別の課題として処理していくことで対応しようとするが、このように複雑な課題を処理するときに探すいわゆるAnswerはどうしても事前学習で得た知識からしか得られないと感じる。なので、より大きなタスクをこなすことがLLMは苦手としているのではないかなというのが、今回spec kitを試してみて改めて感じたこと。

coding LLMは使えない？

とはいえ、coding系のLLMはすごく便利なことには変わりない。おそらくなんだかんだでvibe codingが一番適した使い方に感じる。小さく作り、人間のサポートに徹する使い方が現状のLLMの適切な使い方に思う。
サンプルやPoCなどの使い捨てコードならコードの中身を見ずにLLMにすべて作らせても問題ないが、productionレベルのコードはやはり基本は人間がチェックできる範囲でLLMに生成させないととてもじゃないがメンテナンスができない。
とはいえ、詳細に分割したタスクをvibe coding的にLLMに作成してもらいそれを人間が少しだけ修正する使い方であれば十分に作業効率を向上できる。

あと、LLMはレビューはとても得意と思う。自分が見落としているコードや仕様のあいまいな個所を探してもらうのにはとても適していると感じる。
つまるところは適材適所を考えて使えばいいというありきたりな結論に落ち着く。

画像生成系AIの進化を見るに、上記のような課題もおそらく１年後にはほとんど解決されているんだと思う。あとなんかそもそも今はclaude codeじゃなくてGPT5-codexのほうがいいみたいなのでそっちも試してみよう。