ハポソフトの​​ブログへようこそ

Claude Codeのような​AIコーディングツールを​使えば、​数分で​機能全体を​生成できますが、​基盤と​なる​ビジネスロジックに​欠陥が​あれば、​生成速度が​どれほど​速くても​意味が​ありません。​根本的な​原因は​モデル自体に​あるのではなく、​むしろ、​暗黙の​前提に​満ちた​人間中心の​要件を​依然と​して​AIに​与えている​ことに​あります。​AIは​曖昧な​点に​遭遇すると、​明確化を​求める​ことなく​推測するだけであり、​その​推測が​最終的に​本番環境で​障害を​引き起こします。​ この​記事では、​AIコーディングの​仕様記述技術を​習得する​ことで、​この​ギャップを​埋める​方​法を​解説します。​従来の​PRDが​自律型エージェントでは​十分に​機能しない​理由、​曖昧さを​解消する​ための​6つの​要素からなる​CafeKitフレームワークの​使い方、​そして​複雑な​エッジケースを​処理する​ための​EARSや​Example Mappingと​いった​実践的な​テクニックに​ついて​詳しく​解説します。​この​記事を​読み終える​頃には、​漠然とした​アイデアを​Claude Codeが​初回で​完璧に​実行できる、​厳密で​機械可読な​仕様に​変換する​方​法を​正確に​理解できるようになっているでしょう。​ AIコーディングの​仕様書作成が​他と​異なる​理由 従来の​PRD​（プロダクト要件定義書）は​開発者が​膨大な​量の​暗黙的な​コンテキストを​共有している​ため、​人間の​開発チームでは​十分に​機能します。​開発者は​行間を​読み、​簡単な​質問を​し、​短い​会話の​中で​ビジネス目標に​ついて​合意する​ことができます。​しかし、​AIエージェントは、​こうした​共有された​背景知識を​持たない​状態で​動作します。​ 人間に​曖昧な​要件を​伝えると、​コードを​書く​前に​立ち止まって​内容を​明確にします。​しかし、​同じ​要件を​AIに​伝えると、​統計的な​推測に​基づいて​すぐに​コードの​生成を​開始します。​この​根本的な​違いは​要件定義書の​作成方​法を​完全に​変えてしまいます。​ AIは​人間のように​要件を​解釈しない​ 人間の​開発者は​文脈を​踏まえて​要件を​解釈できます。​「注文が​発送されたら​ユーザーに​通知する」と​いう​記述を​見れば、​その​ドメインの​文脈を​理解します。​「通知」とは、​B2Bシステムでは​メール、​モバイルアプリでは​プッシュ通知を​意味する​可能性が​高い​ことを​認識します。​既存の​コードを​チェックして​パターンを​探し、​不明な​点が​あれば​プロダクトオーナーに​質問します。​ AIは​これらの​ことを​一切​行いません。​訓練データから​パターンを​処理し、​統計的に​最も​可能性の​高い​実装を​生成します。​必ずしも​正しい​実装とは​限りません。​単に、​AIが​これまで​見てきた中で​最も​一般的な​実装を​生成するだけです。​ 人間の​開発者 AIコーディングエージェント 不明点に​ついて​確認する​ 利用​可能な​コンテキストに​基づいて​推測する​ ドメイン知識を​活用する​ 文書化された​情報しか​参照できない​ 不明確な​要件に​疑問を​呈する​ 要件を​文字通りに​解釈する​ チームでの​話し合いに​頼る​ 文書化されていない意思決定には​アクセスできない​ クーポンに​関する​要件を​考えてみましょう。​「システムは​注文に​割引を​適用する​ものとする。」AIは、​パーセンテージ割引、​固定金額割引、​または​注文金額に​基づく​段階的割引を​実装する​可能性が​あります。​割引を​税引前に​適用するのか、​税引後に​適用するのか、​あるいは​特定の​カテゴリの​商品のみに​適用するのかも​明確では​ありません。​明示的な​指示が​ない​場合、​AIは​オープンソースコードで​頻出する​実装パターンに​基づいて、​いずれかの​方式を​選択します。​この​決定は​うまくいく​場合も​あれば、​ビジネスロジックに​全く​合わない​場合も​あります。​ 曖昧さは​そのまま​実装に​なる​ AI仕様に​おける​重要な​ルールは​要件の​曖昧な​部分は​すべて​AIが​決定すると​いう​点です。​「注文が​出荷されたら​ユーザーに​通知する」と​記述した​場合、​AIは​配信チャネル、​メールテンプレート、​送信者アドレス、​再試行ロジック、​オプトアウト処理、​レート制限ルールなどを​選択する​必要が​あります。​AIは、​これらの​項目を​ユーザーに​確認する​ことなく​独自に​決定します。​その際、​自らの​前提を​明示したり、​不確実な​点を​警告したりする​ことは​ありません。​ 人間の​開発者に​とって、​曖昧さは​質問に​つながります。​一方、​AIに​とっては​コード生成に​つながります。​その​コードは​コンパイルされ、​テストに​合格し、​一見​正常に​動作しているように​見えますが、​不足していた​エッジケースが​本番環境で​表面化する​ことがあります。​ コンテキストの​欠如は​誤った​推測を​生み出す AIエージェントは​与えられた​コンテキストのみを​参照して​動作します。​コードベースを​調査して​既存の​パターンを​把握する​ことは​できますが、​明示されていない​アーキテクチャ上の​制約までは​推測できません。​仕様書に​すべての​データベース操作で​リポジトリパターンを​使用する​旨の​記載が​ない​場合、​AIは​コントローラーに​SQLを​直接記述する​可能性が​あります。​JWTベースの​認証を​指定しなければ、​AIが​セッションCookie方​式を​実装する​可能性が​あります。​タイムスタンプを​UTCで​保存するよう​指定していない​場合、​サーバーの​ローカル時間が​使用されます。​ 人間の​開発者は​周囲の​コードを​見て、​確立された​慣習に​従います。​一方、​Claude Codeは​仕様書を​見ます。​仕様書に​記載されていない​ものは​存在しない​ものとみなされます。​その​ため、​仕様書は​AIに​とっての​完全な​判断基盤と​なる​必要が​あり、​すべての​前提を​明示しなければなりません。​ シフトレフトの​原則は​仕様策定から​始まる​ 従来の​開発手法では、​シフトレフトとは​テストを​サイクルの​早い​段階に​移動させる​ことを​意味します。​AIコーディングに​おいては、​曖昧さの​解消を​仕様策定段階まで​前倒しする​ことを​意味します。​AI生成コードの​修正コストは、​デバッグよりも​コードの​再生成に​かかります。​問題点を​特定し、​要件を​書き直し、​エージェントを​再実行します。​この​各イテレーションには​時間と​トークン予算が​かかります。​ 厳密な​仕様は​このような​悪循環を​防ぎます。​「注文ステータスが​『出荷済み』に​変更されたら、​システムは​顧客の​メールアドレスに​メールを​送信する」と​記述すれば、​AIが​独自の​判断を​差し挟む余地が​ありません。​入力に​解釈の​余地が​ないため、​出力は​意図と​一致します。​これが​AIコーディングの​生産性を​左右する​本質的な​ポイントです。​つまり、​より​良い​プロンプトではなく、​より​良い​仕様です。​そして、​これほど​正確な​仕様を​記述する​最も​実用的な​方​法は、​曖昧さを​排除するように​設計された​構造化構文である​EARSを​使用する​ことです。​ EARSを​使用して​AI要件の​曖昧さを​軽減する​ EARSとは​何ですか？​ EARSは​「Easy Approach to Requirements Syntax」の​略称です。​これは​ロールス・ロイス社の​アリスター・マビン氏と​その​同僚に​よって、​航空宇宙および​防衛システム向けに​開発された​もので、​これらの​分野では、​誤った​解釈が​数百万ドル規模の​損失に​つながる​可能性が​あります。​この​構文では、​要件を​厳格かつ​予測可能な​構造で​記述する​ため、​人間の​言語に​固有の​曖昧さを​抑える​ことができます。​EARSの​すべての​要件は​明確な​パターンに​従い、​何が​アクションを​トリガーするのか、​どのような​条件が​適用されるのか、​そして​システムが​それに​応じて​何を​しなければならないのかを​正確に​規定します。​ この​構造は​AIコーディングエージェントに​とって​特に​価値が​あります。​なぜなら、​AIは​意図を​解釈するよりも​パターンを​処理する​方がはるかに​効率的だからです。​要件を​自然言語の​英語で​記述する​場合、​AIは​どの​単語が​トリガーで、​どの​単語が​条件で、​どの​単語が​アクションなのかを​推測しなければなりません。​EARS形式で​記述すると、​役割は​構文自体に​よって​明確に​示されます。​AIは​推論する​必要は​なく、​構造化された​入力を​構造化された​出力に​マッピングするだけです。​ EARSが​AIエージェントに​うまく​機能する​理由 AIコーディングエージェントは​指示が​予測可能な​パターンに​従う​場合に​最高の​パフォーマンスを​発揮します。​人間は​漠然とした​記述の​要件から​意味を​推測できる​ことが​多い​ものの、​AIモデルは​要件が​構造化され、​明確に​記述されている​場合にはるかに​信頼性が​高まります。​ 開発者が​通常、​PRD​（プロダクト要件定義書）で​どのように​要件を​記述するかを​考えてみましょう。​ 注文が​発送されたら、​ユーザーに​通知を​送信する​必要が​あります。​ 多くの​関係者は​この​要件文の​意図を​理解できます。​しかし、​いく​つかの​重要な​点には​解釈の​余地が​残ります。​どの​種類の​通知を​送るべきでしょうか。​誰に​送るべきでしょうか。​いつ送信すべきでしょうか。​配信に​失敗した​場合は、​どのように​処理すべきでしょうか。​ EARSを​使用すると、​同じ​要件は​次のようになります。​ 注文ステータスが​「発送済み」に​変更された​場合 システムは、​5分以内に​顧客の​登録済みメールアドレスに​電子メール通知を​送信する​ものとする。​ ビジネス上の​意図は​変わりませんが、​実装の​詳細がはるかに​明確に​なります。​AIに​漠然とした​記述を​解釈させるのではなく、​要件に​よって​トリガー、​アクション、​および​期待される​結果が​明確に​定義されます。​この​構造に​より​曖昧さが​軽減され、​Claude Codeは​初回で​正しい​実装を​生成する​ためのより​強固な​基盤を​得る​ことができます。​ EARSの​主要要件タイプ EARSは​少数の​要件パターンに​基づいて​構築されています。​これらの​パターンは​ソフトウェア開発中に​遭遇する​ほとんどの​シナリオを​網羅し、​チームが​仕様全体に​わたって​一貫性を​維持するのに​役立ちます。​AI支援開発に​おいては、​これらの​パターンに​よって​予測可能な​構造が​構築され、​要件の​解釈と​実装が​容易に​なります。​ パターン 構造 適用場面 例 常時要件 システムは​ する​ 状態や​イベントに​関係なく​常に​適用される​動作 システムは​すべての​支払い​取引を​記録する​ものとする​ イベント駆動型 が​発生した​場合、​システムは​ を​実行する​ ある​特定の​時点で​発生する​特定の​出来事に​よって​引き​起こされる​行動 ユーザーが​パスワードリセット要求を​送信すると、​システムは​リセットリンクを​送信する​ 状態駆動型 の​間、​システムは​ を​行う​ものとする​ 連続期間または​持続状態中に​適用される​動作 ユーザーセッションが​アクティブな間、​システムは​15分ごとに​認証トークンを​更新する​ものとする​ オプション機能型 の​場合、​システムは​ を​行う​ものとする​ 特定の​機能または​条件が​有効に​なっている​場合に​のみ​利用​可能な​動作 ユーザーが​管理者権限を​持っている​場合、​システムは​監査ログを​表示する​ものとする​ 望ましくない​動作 もし ならばシステムは​ する​ エッジケース、​障害、​または​望ましくない​状況に​おける​動作 決済ゲートウェイが​タイムアウトエラーを​返した​場合、​システムは​最大3回まで​再試行する​ものとする​ 従来の​要件と​EARS要件の​比較 従来型の​要件と​EARS要件の​違いは​単なる​書式の​違いでは​ありません。​AIに​推測させる​内容と​仕様と​して​明示すべき内容の​違いです。​ 従来の​要件​「注文が​発送されたら、​ユーザーに​通知を​送るべきである。」AIは​この​記述を​読み取り、​「通知」の​意味、​「発送済み」の​意味、​対象ユーザー、​使用する​チャネル、​通知内容、​通知が​失敗した​場合の​処理​​方​法などを​判断しなければなりません。​これらは​すべて、​実際の​システム要件ではなく、​トレーニングデータに​基づいて​AIが​行う​判断です。​ EARSの​要件：​「注文ステータスが​『出荷済み』に​変更された​場合、​システムは​ステータス変更後5分以内に​顧客の​登録済みメールアドレスに​メール通知を​送信する」。​これに​より、​AIは​実装すべき内容を​正確に​把握できます。​トリガーは​ステータスが​特定の​値に​変更される​こと、​応答は​特定の​アドレスへの​メール送信です。​実行タイミングも​明示されており、​解釈の​余地は​ほとんど​ありません。​メール送信が​失敗した​場合の​動作を​指定したい​場合は、​エラー処理要件を​追加します。​ 以下に、​それぞれの​ケースで​AIが​判断しなければならない​内容を​並べて​比較した​表を​示します。​ 従来型の​要件 EARS要件 顧客は​チェックアウト時に​割引コードを​適用できる。​ 顧客が​チェックアウト時に​有効な​割引コードを​入力した​場合、​システムは​最終的な​注文合計を​計算する​前に、​該当する​割引を​適用する​ものとする。​ 無効な​割引コードは​エラーメッセージを​表示するべきだ。​ 割引コードが​存在しない​場合、​または​有効期限が​切れている​場合は、​システムは​エラーメッセージを​表示し、​割引を​適用しない​ものとする。​ プレミアム会員は​ロイヤリティ割引を​利用できる。​ 顧客が​プレミアム会員である​場合、​システムは​ロイヤルティ割引と​プロモーション割引コードを​併用できるように​する​ものとする。​ どちらの​バージョンも​同じ​ビジネスアイデアを​伝えています。​違いは​EARSでは​実装時に​必要な​解釈の​多くを​排除している​点です。​人間の​開発者に​とっては、​これに​より​明確性が​向上します。​Claude Codeに​とっては、​生成すべき動作に​ついてより​明確な​シグナルが​得られます。​ EARSは​テストに​適した​入力を​提供する​ EARSの​もう​一つの​利点は​テスト手法との​自然な​整合性です。​多くの​チームは​既に、​Given-When-Thenシナリオを​通して​受入基準を​定義する​ために、​振る​舞い​駆動開発​（BDD）を​使用しています。​EARSは、​トリガー、​条件、​および​期待される​結果を​明確に​する​ことで、​同様の​考え方に​基づいています。​ 例えば、​次のような​要件が​あります。​顧客の​サブスクリプションの​有効期限が​切れた​場合、​システムは​プレミアム機能への​アクセス権を​取り消さなければなりません。​ 以下のような​Given-When-Then形式の​テストシナリオに​変換できます。​ Given​（前提条件）​：有効な​プレミアムサブスクリプションを​持つ顧客が​いる​ When​（操作）​：サブスクリプションが​有効期限に​達する​ Then​（期待結果）​：プレミアム機能に​アクセスできなくなる​ この​関係性は​AIコーディングツールを​使用する​際に​特に​役立ちます。​Claude Codeは​実装、​単体テスト、​統合テスト、​および​受入基準の​基礎と​して、​同じ​要件を​使用できます。​曖昧な​記述から​コードを​生成するのではなく、​AIは​期待される​動作を​既に​定義した​仕様に​基づいて​動作します。​ EARSは​AI実行向け仕様書を​作成する​ための​完全な​フレームワークでは​ありません。​ビジネスコンテキスト、​ドメイン用語、​技術的な​制約、​エッジケースなどは​定義していません。​しかし、​システム動作を​曖昧さを​最小限に​抑えつつ実装精度を​高める​形で​記述する​ための​強力な​基盤を​提供します。​ 詳しく​見る​：Claude Codeの​ための​仕様駆動​開発：CafeKit、​GitHub Spec Kit、​BMAD、​claude-code-spec-workflowの​比較 AI実行向け仕様書の​構成 EARSは​システム動作を​明確に​定義するのに​役立ちますが、​AIコーディングの​仕様書を​作成するには、​構造化された​要件だけでは​不十分です。​Claude Codeが​ビジネス上の​課題、​対象ドメイン、​遵守すべき​技術的制約を​理解するには、​十分な​コンテキストが​必要です。​ よく​ある​間違いは、​EARS要件の​集合体だけで​実装が​十分だと​考えてしまう​ことです。​実際には、​2つの​チームが​全く​同じ​要件を​提示しても、​周囲の​状況に​よって​全く​異なる​結果が​得られる​可能性が​あります。​その​ため、​AI活用に​成熟した​開発チームは​人間に​よる​レビューだけでなく​AIに​よる​実行も​想定した、​AI実行向け仕様書へと​移行しつつあります。​ フォーマットは​組織に​よって​異なりますが、​効果的な​AI実行向け仕様書には、​いく​つかの​共通する​中核要素が​あります。​ 背景と​目標 要件を​定義する​前に、​仕様書では​その機能が​存在する​理由と、​それが​解決する​問題を​明確に​する​必要が​あります。​この​セクションは、​AIが​より​適切な​実装判断を​下すために​必要な​ビジネスコンテキストを​提供します。​コンテキストが​なければ、​モデルは​個々の​要件を​満たすことに​集中し、​機能の​背後に​あるより​広範な​目的を​見失ってしまう​可能性が​あります。​ 例えば、​いきなり​「顧客が​割引コードを​入力したら、​システムは​対応する​割引を​適用する」と​いった​個別要件を​列挙するのではなく、​まず​機能の​目的を​簡潔に​説明します。​例えば、​「この機能の​目的は、​顧客が​チェックアウト時に​割引コードを​利用できるように​する​ことで​プロモーションキャンペーンの​利用率を​高め、​同時に​割引ルールが​ウェブと​モバイルプラットフォーム全体で​一貫している​ことを​保証する​ことです。」と​いった​具合です。​これに​より、​Claude Codeは​その機能が​実現しようと​している​ビジネス成果を​より​明確に​理解できます。​ ドメイン用語集 AI生成コードで​混乱が​生じる​主な​原因の​一つが​用語の​不統一です。​多くの​組織では、​議論の​中で​似たような​用語を​区別なく​使用していますが、​こうした​違いは​実装時に​大きな​影響を​及ぼす​可能性が​あります。​例えば、​仕様書の​中で​「ユーザー」​「顧客」​「会員」​「購読者」と​いった​用語が​使われている​場合、​それぞれ業務上の​異なる​エンティティを​表しているにも​かかわらず、​混乱が​生じる​可能性が​あります。​ AI実行向け仕様書には、​実装開始前に​主要な​ドメイン概念を​定義する​用語集を​含める​必要が​あります。​ 用語 意味 顧客 注文できる​登録ユーザー ゲストユーザー 商品を​閲覧する​ことは​できるが、​注文履歴に​アクセスできない​訪問者 割引コード 利用条件を​満たした​場合に​注文金額が​割引される​プロモーションコード プレミアム顧客 ロイヤルティプログラムに​登録した​顧客 EARSを​使用した​機能要件 文脈と​用語が​確立されたら、​一貫した​構造を​用いて​機能要件を​定義する​必要が​あります。​ここで​EARSが​システム動作を​記述する​ための​主要な​メカニズムと​なります。​自由形式の​記述に​頼るのではなく、​各要件は​トリガー、​条件、​および​期待される​応答を​明確に​定義します。​ EARSの​5つの​パターンは​ソフトウェア開発で​一般的に​発生する​シナリオを​網羅しています。​常に​適用される​普遍的な​動作、​特定の​アクションに​よって​トリガーされる​イベント駆動型の​動作、​システムの​状態に​依存する​状態駆動型の​動作、​特定の​条件下で​のみ​適用される​オプション機能、​そして​問題が​発生した​場合の​エラー処理です。​ エラー処理要件は​特に​重要です。​チームは​正常系に​意識が​偏り、​例外処理を​見落としが​ちだからです。​クーポンコードが​無効な​場合に​何が​起こるかを​指定しないと、​AIは​ケースを​無視するか、​ビジネスルールに​合わない​動作を​生成してしまう​可能性が​あります。​イベント駆動型の​要件ごとに、​操作が​失敗した​場合に​何が​起こるかを​示す対応する​IF条件を​少なくとも​1つ​記述してください。​ 割引システムの​要件例： 顧客が​チェックアウト時に​有効な​割引コードを​入力した​場合、​システムは​最終的な​注文合計を​計算する​前に、​該当する​割引を​適用する​ものとする。​ 割引コードの​有効期限が​切れている​場合、​システムは​エラーメッセージを​表示し、​割引を​適用しない​ものとする。​ 割引コードの​使用制限を​超えた​場合、​システムは​その​操作を​拒否し、​「この​クーポンは​使用制限に​達しました」と​表示する。​ 注文が​確定済みの​状態で​顧客が​クーポンを​適用した​場合、​システムは​変更を​拒否し、​「確定済みの​注文は​変更できません」と​表示する。​ 2人の​顧客が​同時に​同じ​クーポンを​適用した​場合、​システムは​それらの​処理を​順次実行し、​使用制限を​正しく​適用する​ものとする。​ これらの​要件は​予測可能な​構造に​従っている​ため、​レビュー担当者と​AIコーディングエージェントの​両方に​とって​理解しやすくなっています。​例外処理の​方法を​AIが​推測する​必要は​ありません。​例外は​明示的に​文書化されているからです。​ 受入基準 要件は​システムが​何を​行うべきかを​定義します。​受入基準は​成功を​どのように​測定するかを​定義します。​この​セクションは、​異なる​関係者が​同じ​要件を​異なる​方法で​解釈する​ことを​防ぐのに​役立ちます。​また、​AIが​生成した​実装の​明確な​検証目標も​提供します。​多くの​チームは、​人間が​読みやすく​テストしやすいと​いう​理由から、​BDDスタイルの​形式を​使用しています。​ 例： Given​（前提条件）​：有効な​割引コードが​存在する​ When​（操作）​：顧客が​チェックアウト時に​その​コードを​適用する​ Then​（期待結果）​：正しい​割引額が​注文合計金額に​反映される​ 受入基準 は​ビジネス上の​期待と​実装結果との​間に​直接的なつながりを​生み出します。​ 技術的な​制約 AIが​生み出す不必要な​複雑さの​最大の​原因の​一つは​技術的な​ガイダンスの​欠如です。​制約が​与えられていない​場合、​Claude Codeは​システムの​他の​部分とは​異なる​新しい​パターン、​依存関係、​または​アーキテクチャアプローチを​導入する​可能性が​あります。​専用の​技術的制約セクションを​設ける​ことで、​この​リスクを​大幅に​軽減できます。​ 例と​しては​以下のような​ものが​あります。​ 既存の​リポジトリパターンを​使用する​こと 顧客との​すべての​コミュニケーションには、​既存の​通知サービスを​再利用する​こと​ 新しい​サードパーティ依存関係を​追加しない​こと​ プロジェクト既存の​APIレスポンス形式に​従う​こと​ 通常負荷時の​レスポンスタイムを​500ms未満に​抑える​こと バリデーションルールと​ビジネスルール ​多くの​要件が​失敗する​原因は​バリデーションロジックが​明文化されず、​暗黙の​前提と​して​扱われている​ことに​あります。​例えば、​仕様書に​「割引コードの​入力を​検証する」とだけ​記載されている​場合、​解釈の​余地が​大きすぎます。​ より​厳格な​仕様では、​ルールが​明確に​定義されています。​ 割引コードの​長さは​50文字以内である​必要が​あります。​ 割引コードの​照合では、​大文字と​小文字を​区別しません。​ 有効期限切れの​コードは​使用できません。​ 割引コードは​併用可能と​明示されている​場合を​除き、​他の​割引コードと​併用できません。​ ビジネスルールが​具体的で​あれば​ある​ほど、​AIが​実装時に​推測する​必要の​ある​部分は​少なくなります。​ テストシナリオと​完了の​定義 最終セクションでは、​その機能が​どのように​検証されるか、​そしていつ​完成したとみなされるかを​定義する​必要が​あります。​ これに​より、​開発者と​AIコーディングエージェントの​双方に​明確な​完了条件を​提示できます。​ 完了の​定義には​以下が​含まれる​場合が​あります。​ すべての​EARS要件が​実装されている​こと 単体テストおよび​統合テストに​合格している​こと​ 受入基準を​満たしている​こと 重大な​セキュリティ上の​問題が​ない​こと​ 関連ドキュメントが​更新されている​こと​ これらの​要素を​組み合わせる​ことで、​従来の​要件定義書を​AI実行向け仕様書へと​変換できます。​EARSは​動作を​記述する​ための​構造を​提供し、​コンテキスト、​用語、​制約、​バリデーションルールは、​Claude Codeが​ビジネス上の​期待に​沿った​コードを​生成する​ために​必要な​情報を​提供します。​しかし、​最も​構造化された​仕様書であっても、​重要な​エッジケースが​見落とされると​失敗する​可能性が​あります。​その​ため、​例外、​障害シナリオ、​境界条件を​文書化する​ことが、​次の​重要な​ステップと​なります。​ CafeKitを​使用して​AI実行向け仕様書を​構築する​ 優れた​仕様書を​作成する​ことは​課題の​一部に​過ぎません。​エンジニアリングチーム全体で​AIの​導入が​進むに​つれて、​組織は​すぐに​別の​問題に​気づきます。​それは、​要件、​ビジネスコンテキスト、​アーキテクチャ上の​決定、​および​ドメイン知識を​長期に​わたって​一貫性を​保つことです。​ 単一の​機能仕様には、​数十もの​EARS要件、​バリデーションルール、​エッジケース、​および​受入基準が​含まれる​場合が​あります。​これを​複数の​チームや​プロジェクトに​またがらせると、​信頼できる​唯一の​情報源を​維持する​ことが、​ますます困難に​なります。​情報が​文書、​チケット、​会議メモ、​チャットの​会話などに​分散している​場合、​AIコーディングエージェントは​不完全または​古い​コンテキストを​受け取る​ことが​よく​あります。​ そこで​価値を​発揮するのが、​CafeKitのような​プラットフォームです。​ CafeKitは​仕様書を​独立した​文書と​して​扱うのではなく、​AIコーディングエージェントが​依存するより​広範な​コンテキストを​チームが​管理できるように​支援します。​要件、​ビジネスルール、​ドメイン用語、​および​関連知識を​構造化された​形式で​整理できる​ため、​人間と​AIの​両方が​同じ情報に​容易に​アクセスできます。​ CafeKitに​ついて​詳しく​見る​：｢Vibe Coding」を​超えて​：CafeKitが​AI自動化にもたらす仕様駆動開発​（SDD）​ ビジネスコンテキストの​一元化 AI実装エラーの​最も​一般的な​原因の​一つは​コンテキストの​断片化です。​ビジネス要件は​一つの​ドキュメントに、​アーキテクチャ上の​決定事項は​別の​ドキュメントに、​そして​専門用語は​全く​別の​場所に​記載されていると​いった​具合です。​経験豊富な​開発者で​あれば​こうした​ギャップを​うまく​処理できますが、​重要な​情報が​複数の​ソースに​分散している​場合、​AIエージェントは​困難に​直面します。​ 一元化された​ナレッジベースは​要件と​関連コンテキストに​関する、​信頼できる​唯一の​情報源を​構築する​ことで、​この​問題を​軽減します。​Claude Codeは​推測に​頼るのではなく、​既に​文書化されレビュー済みの​情報に​基づいて​作業できます。​これに​より、​AIが​分散した​情報源から​不完全な​情報を​つなぎ合わせて​推測する​必要が​なくなります。​ 一貫した​ドメイン知識の​維持 システムが​大きくなるに​つれて、​用語の​重要性はますます高まります。​顧客、​会員、​購読者、​ユーザーと​いった​概念は​似ているように​見えますが、​実際には​異なる​ビジネスエンティティを​表している​場合が​少なく​ありません。​共通の​用語集が​ないと、​不整合が​要件、​コード、​API、​ドキュメントに​急速に​広がる​可能性が​あります。​AIに​よる​実装は、​モデルが​用語を​文字通りに​解釈する​傾向が​ある​ため、​特に​この​問題の​影響を​受けやすいと​言えます。​ ドメイン定義を​一元的に​管理する​ことで、​チームは​曖昧さを​減らし、​AI支援開発ワークフロー全体の​一貫性を​向上させる​ことができます。​AIが​「プレミアム顧客」の​意味を​正確に​理解すれば、​微妙な​エラーを​発生させる​ことなく、​関連する​ビジネスルールを​正しく​実装する​コードを​生成します。​ アーキテクチャ上の​意思決定の​維持 要件は​システムが​何を​行うべきかを​説明する​ものであり、​アーキテクチャ上の​決定事項は​システムを​どのように​構築すべきかを​説明する​ものです。​これらの​決定事項は、​設計パターン、​インフラストラクチャの​選択、​統合アプローチ、​パフォーマンス制約などの​トピックを​網羅した​アーキテクチャ決定記録​（ADR）に​よって​文書化される​ことが​よく​あります。​開発者は​これらの​決定事項を​既に​理解しているかもしれませんが、​AIエージェントは​実装時に​アクセス可能な​場合に​のみ、​それらに​従うことができます。​ AIに​アーキテクチャに​関する​ガイダンスを​提供する​ことで、​確立された​エンジニアリング標準からの​不必要な​逸脱を​減らし、​一貫性の​ない​ソリューションを​導入する​リスクを​低減できます。​Claude Codeは​チームが​リポジトリパターンを​使用し、​特定の​API規約に​従っている​ことを​認識すると、​リファクタリングを​必要と​する​新しい​パターンを​導入するのではなく、​既存の​コードベースや​設計方​針と​整合する​コードを​生成します。​ Claude Codeの​ワークフローを​改善する​ 現在、​多くの​チームが​単純な​プロンプトベースの​開発から、​仕様主導型の​ワークフローへと​移行しつつあります。​Claude Codeに​単に​「機能を​作ってください」と​指示するのではなく、​開発プロセスを​次のように​構造化します。​ ビジネス目標と​要件を​定義する。​ EARSの​要件と​受入基準を​文書化する。​ エッジケースと​バリデーションルールを​整理・文書化する。​ アーキテクチャ上の​制約と、​それを​裏付ける​背景情報を​提供する。​ 仕様に​基づいて​実装と​テストを​生成する。​ この​アプローチは​モデルに​よる​推測を​減らし、​明確に​定義された​要件の​実装に​集中できる​ため、​AI支援開発の​基盤を​大幅に​強化します。​その​結果、​コード生成の​質が​向上するだけでなく、​実装の​一貫性が​高まり、​手戻りが​減り、​ビジネス上の​期待と​エンジニアリングの​成果との​整合性が​向上します。​最終的に、​Claude Codeのような​ツールは、​構造化された​仕様環境内で​動作する​ことで、​その​効果を​飛躍的に​高めます。​ 結論​ AIコーディングの​仕様書を​作成する​ことは​人間の​開発者向けの​要件書を​作成する​こととは​根本的に​異なります。​人間の​開発者は​仕様書を​解釈し、​質問、​不足している​部分を​補います。​Claude Codeは​ユーザーが​指定した​内容を​実行します。​仕様や​周辺コードが​曖昧な​場合は、​利用​可能な​コンテキストに​基づいて​最適な​推論を​行います。​EARSは、​トリガー、​条件、​応答を​明示する​ための​構造を​提供し、​要件の​曖昧さを​抑えます。​CafeKitは、​AIエージェントが​ビジネスの​期待に​沿った​コードを​生成する​ために​必要な​ワークスペースと​ワークフロー​（コンテキスト、​用語、​制約、​バリデーションルール）を​提供します。​ Haposoftでは、​これらの​手法を​プロジェクトで​積極的に​活用しており、​コード品質と​開発速度の​向上に​取り​組んでいます。​CafeKitは​オープンソースと​して​早期利用が​可能です。​ぜひインストールして、​AIが​実行しやすい​仕様書の​作成を​体験してみてください。​ご質問や​ご相談が​ございましたら、​お気軽に​ご連絡ください。​弊社が​得た​知見も​喜んで​共有いたします。​ これを​実践に​移す準備は​できましたか？​ CafeKitは​オープンソースであり、​早期利用が​可能です。​インストールして、​実際に​動作する​AIコーディングの​仕様書を​作成しましょう。​ bash npx @haposoft/cafekit GitHub Repository →