「Claude Code」と「Dify」の違いとは？AIエージェントの2タイプを学ぶ
冒頭、吉田氏は自身と本セッションを提供するPE-BANKの関係について触れた。現在、ジェネラティブエージェンツで取締役COO、セクションナインで取締役を務める吉田氏だが、フリーランスエンジニアをしていた際にPE-BANKの前身である首都圏コンピュータ技術者協同組合に所属。そこから今に至るまでのつながりにより、本セッションが実現した。
Claude Codeによる開発の前提として、まずはAIエージェントの性質を知る必要がある。そこで吉田氏は、AIエージェントの基本的な定義から振り返った。
AIエージェントには、2つのタイプが存在する。ひとつは、Difyやn8nに代表される「事前定義型ワークフロー」と呼ばれるもので、人間があらかじめ処理フローを定義しておく方式だ。LLMはワークフローの中での条件判断や処理に部分的に活用されるに留まるが、広義のAIエージェントに分類される。
もうひとつが、Claude Codeに代表される「適応型ワークフロー」だ。現在の環境を知覚し、次に取るべきアクションを判断して環境に働きかける。その結果生じた変化を観察し、再び次のアクションを決定する。このようなエージェンティックループを繰り返しながら、ゴールに向かって自律的に動作するタイプだ。ループの過程でAIエージェントは、自らの手足となるツールまたは機能を呼び出し、アクションを実行に移す。
例えばコーディングエージェントであれば、bashやgrepといったコマンドを実行できるようになっており、ファイルの読み書きや検索といった操作を状況に応じて自律的に選択しながら、目的の達成へと進んでいく。吉田氏自身は、このような「目標に向けて環境と相互作用しながらタスクをこなす知能システム」こそがAIエージェントだと定義する。
ただし吉田氏は、事前定義型と適応型に優劣があるわけではないと付け加える。事前定義型の場合、処理内容を状況に応じて柔軟に変化させることはできないが、動作の再現性が保証されるというメリットがある。一方で適応型のエージェントは、柔軟性に優れるが、その分大きなリスクを伴う。例えばユーザーの曖昧な指示を取り違え、重要なファイルを削除してしまうような事態も起こりうる。
そこで、適応型のエージェントを利用する際には、事前に明確な運用ルール集（ステアリングポリシー）を準備しておくことが重要だ。ステアリングポリシーがあれば、どのようなタスクが来てもエージェントはそのルールを踏まえてワークフローを自ら構築し、適切に動いてくれる。
こうした前提を踏まえ、吉田氏は仕様駆動開発の概念を紹介した。Thoughtworks Technology Radarは、仕様駆動開発を「仕様書を信頼できる唯一の情報源（Single Source of Truth）として、コーディングエージェントに実装生成を委ねる開発手法」だと定義している。
仕様駆動開発における「仕様書」に明確な決まりはないものの、一般的には要件定義書（PRD）、設計書、タスクリストを含むとされている。さらに、ドメインのユビキタス言語（用語集）や開発ルールなども仕様の構成要素に含まれる。
「仕様駆動開発」と「Vibe Coding」は何が違う？
セッションの冒頭で吉田氏は「今日のゴールは、みなさんが仕様駆動開発を今日から始めてみたいと思うことです」と宣言した。そこで吉田氏は、著書『実践Claude Code入門』第4章の内容をもとに、仕様駆動開発を体験できるシンプルなデモを行った。
デモはまず、CLAUDE.mdに記載する開発ルールを、Claude Code自身に生成させるところから始まった。生成されるルールは250行ほどで、必要なドキュメントの種類や、作業ごとに専用フォルダを作るといった規約が定義されている。このルールに基づき、要件定義、設計書・タスクリストの生成、アーキテクチャ仕様書の作成と進んでいき、内容を確認した上で実装に移る、という流れだ。
作業単位のファイル管理とマスター仕様書の継続的なメンテナンスという2点を押さえるだけで、コーディングやテストを着実に進められる、とてもシンプルな方法だ。
仕様駆動開発のメリットを実感するには、併せてVibe Codingも試してみてほしいと、吉田氏は勧める。Vibe Codingとは、音声や自然言語による指示でLLMにコードを生成させ、成果物を詳しくレビューせずに進める方法だ。スキルのあるエンジニアであればプロトタイピングの手段として活用の余地があるが、慣れていないと成果物の動作が不安定な、いわば「ガチャを引く」ような開発手法でもあると、吉田氏は言う。
「エンジニアであれば、何をどのように開発すべきかを明確にし、ねらい通りに開発を進めたいはずです。つまり、ソフトウェアエンジニアリングをしっかりとやりたいのです」と、仕様駆動開発の優位性を説明する。
しかし一方で、「現実の複雑な開発に適用するにはシンプルすぎるかもしれない」と仕様駆動開発の課題についても率直に語る。第1の課題は、ステアリングポリシーをCLAUDE.mdに集中させることによるコンテキストの浪費だ。すべてのルールを1つのファイルに書き込むとメモリーファイルが肥大化し、Claude Codeが動作するたびに全内容を読み込むため、コンテキストウィンドウを圧迫してしまう。さらにCLAUDE.mdに詳細なルールを書いてしまうと、そこに書かれていない動きを自律的に行わなくなる傾向があるという。ルールは必要なタイミングで必要な分だけ読み込む構造にしておく方が望ましい。
第2の問題は、状態管理と監査証跡の不十分さだ。書籍のアプローチでは作業単位のタスクリストが事実上の状態管理を兼ねているが、ユーザーがどのような入力を行い、AIがどう判断したかというやり取りの詳細までは記録されない。すると開発が進むにつれて、過去の意思決定の根拠を辿れなくなるリスクが高まる。本格的な仕様駆動開発で求められるトレーサビリティの確保には、より体系的な仕組みが必要になると吉田氏は指摘する。
OSSのプロンプト集も！今日から始める仕様駆動開発
そこで、より実践的な仕様駆動開発の手法として、吉田氏が紹介したのがAI-DLC（AI-Driven Development Life Cycle）だ。これはAWSが提唱・公開しているAI駆動の開発ライフサイクルフレームワークであり、リファレンス実装がOSSのプロンプト集としてGitHubで公開されている。
AI-DLC自体は単なるツールではなく、AIが開発をリードして人間が支援する新しいソフトウェア開発ライフサイクル（SDLC）のためのフレームワーク、つまり考えかたや実践方法のセットだ。
これを推進するうえで用いるツールがAI-DLCワークフロー（プロンプト集）だが、吉田氏はこの出来がとても良いと話す。特徴的な部分として、かつてプログラマがモブプログラミングをしながら実装、レビュー、ナレッジ共有などすばやいコンテキスト共有を実現していたのと同様に、ボトルネックになりがちな要件整理・要求開発フェーズにおける意思決定や制約条件の詳細化を、AIが中心になってリードする「モブエラボレーション」で実現できる点がある。
『実践Claude Code入門』との違いは、開発フェーズが体系的に定義されている点だ。Inception（計画・分析）、Elaboration（要求の詳細化）、Construction（実装）という3フェーズが定義されており、各フェーズで求められる成果物や判断基準が明確に規定されている。同書籍の方法では仕様に曖昧さが残っていても実装に進んでしまいがちだが、AI-DLCでは曖昧なままで次のフェーズに進まないよう、プロンプトが整備されているのだ。
吉田氏はデモとして、AI-DLCベースでの開発の流れを実演した。「ECサイトを作りたい」と入力すると、何を作りたいかを具体化するための的確な質問集が提示される。これはInceptionフェーズに対応するもので、これらに回答しなければ、次のフェーズへ進むことはできない。
AI-DLCのリファレンスには、コアワークフローとInceptionやConstructionなどフェーズごとのルール集が整備されており、これがまさにAIエージェントの振る舞いを制御するステアリングポリシーとして機能している。そしてAI-DLCでは、フェーズごとに別々のルールファイルが用意され、必要な部分を必要に応じて読み込む設計のため、コンテキストの浪費も抑えられている。
加えて、状態管理や監査証跡のためのファイルも用意されており、すべてのやり取りがタイムスタンプ付きで記録される。このように、書籍の方法で課題となっていた点が、AI-DLCではいずれも体系的に解決されているのだ。
「実は、仕様駆動開発において最も大事な要素は、仕様書ではなくステアリングポリシーの整備です。AI-DLCを知っているだけで、仕様駆動開発のレベルが一気に上がるはずです」（吉田氏）
最後に吉田氏は、この半年でベストプラクティスのレベルは明らかに向上しており、仕様駆動開発はもはや「やってみる」段階を過ぎて「やるのが当たり前」の時代に突入したと総括した。「『実践Claude Code入門』を入り口としつつ、AI-DLCのような発展的フレームワークも視野に入れながら、ぜひ仕様駆動開発に取り組んでほしい」と呼びかけ、講演を終えた。
PE-BANKからのお知らせ
本セッションでご紹介したサービスにご興味を持たれた方は、ぜひ公式サイトをご覧ください。
