コンテキストエンジニアリング × Decision Logで始めるアジャイル版仕様駆動開発のすすめ

リテールアプリ共創部のるおんです。

私はクラスメソッドのリテールアプリ共創部でプロジェクト立ち上げ専門のチームに所属しており、この1年弱で実際に顧客のいる3つの案件にてPMやリードエンジニアとしてアプリ開発の立ち上げに携わって来ました。AIによるコーディングの高速化は既に多くの場面で実現されていますが、要件定義やプロジェクト管理といった 「プロジェクト全体」の高速化 はまだこれからの領域です。そこで今回は、複数プロジェクトを並行して立ち上げてきた中で辿り着いたアプローチを紹介します。

以前、「全てのコンテキストを集約し真の仕様駆動を実現。プロジェクト全体の開発を高速化する方法」というテーマで登壇し、コンテキストエンジニアリングの実践についてお話ししました。

https://dev.classmethod.jp/articles/context-aggregation-for-true-spec-driven-development/

あれから数ヶ月、現在2つのプロジェクトでコンテキストエンジニアリングを実践しています。その中で、仕様駆動開発の根本的な課題である 「ドキュメントの陳腐化」 と、コンテキストエンジニアリングの弱点である 「過去の決定事項をAIが仕様の根拠として扱ってしまう」 という2つの問題に直面しました。

本記事の前提: 筆者は受託開発のプロジェクトでこのアプローチを実践しています。顧客・PM・複数ベンダーなど多くのステークホルダーが関わり、定例会やBacklog上のやり取りで要件が変化していく — そんな環境を想定しています。自社開発や個人開発での仕様駆動開発とは文脈が異なる部分がありますので、その点はご了承ください。

今回は、これらの問題を解決するために考案した Decision Log という仕組みと、コンテキストエンジニアリングとの組み合わせによる「アジャイル版仕様駆動開発」のアプローチを紹介します。

コンテキストエンジニアリングとは

まず、本記事で言う「コンテキストエンジニアリング」と「仕様駆動開発」について簡単に説明します。

AIのアウトプットの精度は、インプットするコンテキストの質と量で決まります。 コンテキストエンジニアリング とは、このインプットを設計・管理する技術であり、今回のアプローチではプロジェクトに関わるすべての情報を 1つのGitHubリポジトリに集約して管理 します。具体的には、BacklogやJiraなどの 課題管理ツール の情報、Google MeetやTeamsの文字起こし（SharePoint等で共有されるもの）と 議事録 、パワポやPDFなどの 共有ドキュメント などを、MarkdownやCSVといったプレーンテキスト形式でローカルのリポジトリにエクスポートして一元管理します。プレーンテキストで管理することで、AIが直接読み書きできるAIフレンドリーな形式になります。

project-context/
├── MTG/                  # 議事録・文字起こし
│   └── 20260326/         # 日付ごとの議事録・文字起こし
├── Backlog/              # Backlog課題・ドキュメント
│   ├── issues/           # 課題のMarkdownエクスポート
│   └── documents/        # 仕様書・シーケンス図等
├── GitHub/               # GitHub関連
│   ├── issues/           # IssueのMarkdownエクスポート
│   ├── src/              # ソースコード
│   └── wiki/             # Wiki
├── 共有資料/               # 顧客から受領したPDF・提案資料等
│   └── 提案資料.md        # Markdownに変換して管理
├── CLAUDE.md             # プロジェクト概要（AI向け）
└── .cursor/              # AIエージェント設定
    ├── rules/            # AIルール
    ├── skills/           # 自動化スキル
    └── commands/         # カスタムコマンド

そして、この蓄積されたコンテキストをもとに、AIと協働しながら仕様書や要件定義を導き出し、その仕様に基づいて開発を進めていく。これを本記事では 仕様駆動開発 と呼んでいます。KiroやGitHub Spec Kitのような仕様駆動ツールは「先に仕様を書き、それに基づいて実装する」というアプローチですが、本記事で紹介するのは、蓄積したコンテキストから仕様を導出し、変化に追従し続けるアプローチ です。

コンテキストがリポジトリにあるので、AIは過去のミーティングの議事録やBacklog課題のやり取りを即座に参照でき、さまざまな場面で活用できます。

実際のプロジェクトでは、コンテキストを活用したAIエージェントのスキルをいくつも作っています。例えば、Backlog課題に対して過去の議事録やコメントを踏まえた返信を生成する reply-to-issue、Google Meetの文字起こしから構造化された議事録を自動生成する create-minute、要件をもとにGitHub Issueを作成する create-issue-from-requestなどなどです。コンテキストが蓄積されているからこそ、これらのスキルが根拠に基づいた精度の高いアウトプットを出せるようになっています。

先に結論

仕様書は「作って維持する」のではなく、 Decision Log（決定事項の時系列ログ）を蓄積し、そこから仕様は自動的に導き出される という発想です。

Decision Logのイメージは以下の通りです。

#1 → #3、#2 → #4 のように、同じ機能でも過去の決定と最新の決定が両方残ります。例えば #2 では3/13にマイページをアプリ内で新規構築すると決めていますが、わずか10日後の #4 で既存の外部サービス画面を使う方針に変わっています。AIはレコード番号と日時から #4 が 最新の正しい決定だと判断 でき、その背景や詳細を知りたければ、根拠に記載された定例会の議事録やBacklog課題のコメントを辿る ことができます。

従来の仕様駆動開発との比較

コンテキストエンジニアリングでプロジェクトの全情報をローカルに集約し、Decision Logで意思決定の鮮度を管理する。これにより、エンジニアだけでなくPMや要件定義を行うメンバーもAIと協働できる仕組みが実現できます。

仕様駆動開発の2つの課題

課題1: ドキュメントの陳腐化

KiroやGitHub Spec Kitなどの仕様駆動ツールが登場し、AIに「仕様を先に作らせてからコードを書かせる」アプローチが広まっています。しかし、実際のアジャイル開発プロジェクトでは、仕様は 毎週の定例会で変わります 。

• 先週「通知はメールとプッシュ通知の両方で送る」と決めたのに、今週「コストの問題でプッシュ通知のみに変更」になった
• 「マイページはアプリ内で新規構築する」はずが、「既存の外部サービス画面へのリンク遷移にする」に変わった

こうした変更のたびに仕様書を更新し続けるのは現実的ではありません。結果として、仕様書とプロジェクトの実態が乖離し、 AIが古い仕様書を参照して的外れな実装や提案をしてしまう という問題が起きます。

課題2: 根拠の不在

仕様書には「何を作るか」は書かれていても、 「なぜそう決まったのか」 が書かれていないことがほとんどです。

• なぜ機能Aはリンク遷移のみにしたのか？
• なぜ機能Bはログイン不要にしたのか？
• なぜ通知はユースケースXに限定したのか？

根拠がなければ、仕様変更があったときに「前の決定と矛盾するけど本当にいいのか？」という判断ができません。これは人間にとってもAIにとっても同じです。
これ自体は情報を集約するコンテキストエンジニアリングで解決可能ですが、コンテキストエンジニアリングにも以下のような弱点があります。

コンテキストエンジニアリングの弱点

前回の登壇でお話しした通り、コンテキストエンジニアリングでは プロジェクトの全情報をGitHubリポジトリに集約 します。

これにより、AIがBacklogの課題や過去の議事録を参照して、バックログへの返答や仕様書の作成、技術的なインターフェースの設計などを支援できるようになります。

現在、この仕組みを2つのプロジェクトで実践しており、要件定義を進める中でとてつもない威力を発揮しました。

プロジェクト開始から1〜2ヶ月の間は、これで全く問題ありませんでした。コンテキストの量が適度で、AIが全体を把握しやすかったからです。しかし、プロジェクトが進むにつれて定例会の議事録は積み上がり、Backlog課題のコメントは増え続け、コンテキストは肥大化していきます。そうなると、2つの問題が顕在化してきました。

1つ目は、コンテキストの肥大化による検索時間とトークン消費の問題です。

例えば、「通知機能の要件を抜け漏れなく洗い出してほしい」とAIに依頼するとき、コンテキストリポジトリ全体を全文検索やセマンティック検索で横断させることになります。しかし、プロジェクトが進むにつれてMDファイルは増え続け、AIが確認すべきファイル数も膨大になります。AIがGrep検索を繰り返し、ヒットしたファイルを片っ端から読み込んでいく — この検索と読み込みだけで 相当な時間がかかります 。さらに、議事録、Backlog課題のコメント、過去のドキュメントをすべて読み込むことで 大量のコンテキストトークンを消費 してしまい、肝心の推論や生成に使えるトークンも圧迫されます。

2つ目は、覆された過去の決定事項を仕様の根拠として扱ってしまう問題です。

例えば、3月11日のキックオフで「通知はメールとプッシュ通知の両方で送る」と決定し、3月17日に「プッシュ通知のみに変更」されたとします。議事録やBacklog課題の両方にこの情報が存在する場合、AIがどちらを「現在の仕様」として扱うかは保証されません。

コンテキストが豊富であるがゆえに、 情報量が膨れ上がり、矛盾する情報が共存してしまう 。これがコンテキストエンジニアリングの弱点です。

Decision Logという解決策

この問題を解決するために、一方のプロジェクトで Decision Log という仕組みを導入しました。

Decision Logとは

ソフトウェア開発の世界には、アーキテクチャの意思決定を記録する ADR（Architecture Decision Records） という手法があります。Decision Logはこれに着想を得ていますが、対象が異なります。ADRが「技術的な意思決定」を開発チーム向けに記録するのに対し、Decision Logは 「機能要件に関する意思決定」 を記録します。要件定義フェーズで使うものなので、顧客やPMなど非エンジニアのステークホルダーにも共有できる内容にしています。

Decision Logは、機能要件に関する全決定事項を時系列順に記録するテーブルです。手戻りや意思決定の変更も含めてすべてログとして残します。

Decision Logの設計原則

1. 追記のみ、削除しない

過去の決定事項は絶対に変更・削除しません。「1週間前はこう言っていたが、今日は違うことを言っている」場合も、両方のレコードが残ります。AIは # 番号が大きい（= より新しい）レコードを最新の決定として判断できます。

先ほどの例では、#2（マイページをアプリ内で新規構築）と #4（既存の外部サービス画面に遷移）の両方が残っており、#4 に「#2の方針を変更」と明記されています。

2. 根拠を必ず記録する

各レコードには 根拠（Source） を記録します。「第2回定例会」「PROJ-7 コメント11」のように、具体的な情報源を書きます。

これにより、「なぜそう決まったのか」を知りたいときに、根拠となる議事録やBacklog課題のローデータを辿ることができます。Decision Logには決定した内容の要約だけを書き、前後の文脈や議論の詳細はローデータ（議事録の文字起こしやBacklog課題のコメント）を参照する設計です。

3. 選択肢と理由を記録する

「何に決まったか」だけでなく、「何と比較して」「なぜそちらを選んだか」も記録します。

これにより、AIが仕様に関する質問に答えるとき、単なる結論だけでなく 意思決定の背景 まで説明できるようになります。

よくある「言った言わない」問題の解決

プロジェクトでありがちな「言った言わない」問題も、Decision Logで防ぐことができます。

• 「いつ」：日時カラムで決定日が明確
• 「どこで」：根拠カラムで情報源が明確
• 「誰が」：根拠のローデータ（議事録・コメント）を辿れば発言者が特定可能
• 「なぜ」：理由カラムで意思決定の背景が明確

そしてこれができるのは、コンテキストエンジニアリングを実践しているからこそです。議事録の文字起こし、Backlog課題のコメント、すべてのローデータがリポジトリに蓄積されているため、根拠となるソースが常に参照可能な状態にあります。

仕様書は管理せず、都度導き出す

Decision Logを導入して気づいた重要なことがあります。それは、 仕様書を別途作る必要がそもそもない ということです。

従来の仕様駆動開発では、仕様書を作成し、それをAIに読み込ませて実装させます。しかしこのアプローチには前述の 仕様書の陳腐化問題 がつきまといます。

Decision Log駆動のアプローチでは、仕様書の代わりにDecision Logが「信頼できる唯一の情報源（Single Source of Truth）」として機能します。

従来:  仕様書（手動メンテ）→ AI が参照 → 実装
今回:  Decision Log（自動蓄積）→ 必要に応じて仕様を導出 → 実装

もちろん仕様書を作ることもできます。ただし、それは Decision Logから自動的に導出される ものです。例えば、「通知機能の現在の仕様を教えて」とAIに聞けば、Decision Logから 機能 = 通知 のレコードを時系列で抽出し、最新の決定事項をまとめた仕様書を生成できます。

この仕組みの最大のメリットは、 仕様書が陳腐化しても、Decision Logから何度でも最新の仕様を再生成できる ことです。仕様書はキャッシュのようなもので、古くなったら捨てて再生成すればいい。Decision Logこそが本体です。

Decision Logの自動更新

Decision Logを手動でメンテナンスするのは現実的ではありません。そこで、Decision Logの更新をAIエージェントのスキルとして定義し、定期実行する仕組みを構築しました。

update-decision-logスキル

Decision Logの更新ロジックをAIエージェント向けのスキル（Markdownファイル）として定義しています。やっていることはシンプルで、Backlog課題のコメントやMTGの議事録から新しい決定事項を抽出し、Decision Logのテーブル末尾に追記するだけです。抽出対象のパターン（確定表現・合意表現）や除外条件（未確定・非機能要件）、テーブルの各カラムの記入ルール、追記前の承認フローまでをスキルに定義しています。

---
description: 最新のBacklog課題・議事録からDecision Logにレコードを追加する
---
Backlog課題のコメントや議事録から新たな決定事項を抽出し、`Backlog/documents/Decision_Log.md`に追記します。

## 前提

- Decision Logは**機能要件に関する決定事項のみ**を記録する
- アカウントセットアップ・環境構築等は対象外
- 手戻りや意思決定の変更も含めてすべてログとして残す

## 実行手順

### 1. 最新のBacklog課題情報を取得

pnpm dlx backlog-exporter@latest update --issuesOnly --force

### 2. 既存のDecision Logを読み込む

`Backlog/documents/Decision_Log.md`を読み込み、以下を把握する：

- 現在の最大の`#`番号（次に追加するレコードの番号を決定するため）
- 既に記録済みの決定事項（重複追加を防ぐため）
- 各レコードの根拠（課題キー・コメント番号・定例会名）
- **最終更新日時**（`更新日時`フィールドから取得する）

### 3. 更新対象の課題・コメントを特定する

以下の2つの方法を併用して、Decision Logの最終更新日時以降に新しい決定が含まれる可能性がある課題を特定する。

#### 3-1. コメント日時による全文検索（推奨）

`Backlog/issues/`配下の`.md`ファイルに対して、Decision Logの最終更新日以降の日付を含むコメントを検索する。

これにより、最終更新日以降に投稿されたコメントを含む課題ファイルを特定できる。

#### 3-2. backlog-update.logによる補完

`Backlog/issues/backlog-update.log`を読み込み、3-1で漏れた課題がないか補完する。

#### 3-3. ユーザーから指定された情報源

`$ARGUMENTS`にファイルパスや課題キーが指定された場合は、そのファイルも優先的に確認対象に追加する。

### 4. 各課題のコメントから決定事項を抽出する

3で特定された各課題のMDファイルを読み込み、**最終更新日時以降のコメント**から以下のパターンに該当するものを抽出する：

**抽出対象**:
- 「〜で決定」「〜にします」「〜で進めます」「〜で合意」「〜方針とする」等の確定表現
- 「〜でお願いします」等、選択肢に対する明確な回答
- 質問→回答の流れで方針が確定しているやり取り
- 「承知しました」等の合意表現が続くやり取り

**除外するもの**:
- 質問のみで回答がないもの（未確定）
- 「確認中」「検討中」等の未確定表現
- アカウントセットアップ・環境構築等の非機能要件

### 5. 議事録からも決定事項を抽出する

`MTG/`配下の議事録ファイルのうち、Decision Logの最終更新日時以降に作成されたものの「決定事項まとめ」セクションから抽出する。

### 6. 決定事項をDecision Logに追記

抽出した決定事項を、テーブル形式で`Decision_Log.md`の末尾に追記する。

各カラムの記入ルール：

| カラム | ルール |
|--------|--------|
| # | 現在の最大番号+1から連番 |
| 機能 | 機能名。機能横断の場合は`全体` |
| コンテキスト | 何についての決定か（短い見出し） |
| 決定内容 | 何が決まったか（具体的に） |
| 選択肢 | 検討された選択肢（①② 形式）。特になければ`-` |
| 理由 | なぜその決定に至ったか |
| 根拠 | 情報源（例: `第2回定例会`, `PROJ-7 コメント11`） |
| 日時 | 決定日（`YYYY/M/D`形式） |

### 7. 追記前の確認

追記する内容をユーザーに提示し、承認を得てからファイルに書き込む。

### 8. ファイルへの書き込み

承認を得たら、`Decision_Log.md`のテーブル末尾に新しいレコードを追記する。

## 注意事項

- 既存のレコードは絶対に変更・削除しない（追記のみ）
- 同一の決定事項が異なる表現で記録されることを避けるため、既存レコードとの重複チェックを必ず行う
- 未確定の議論・検討中の事項は追加しない。確定した決定事項のみを対象とする
- 機能要件に関する決定事項のみ対象。インフラ・アカウント等は対象外
- **課題の「詳細」セクション（質問文）だけでなく、「コメント」セクション（回答・やり取り）を必ず確認する**

スケジュール実行で鮮度を保つ

このスキルは手動で実行することもできますが、定期実行することでDecision Logの鮮度を自動的に保つことができます。

例えば、GitHub Actionsの schedule トリガーを使って毎日21時にClaude Codeを起動し、update-decision-log スキルを実行させるといった構成が考えられます。Claude Codeのスケジュール済みタスク機能を使えば、Cloudスケジュール済みタスクやDesktopスケジュール済みタスクとして定期実行を設定することも可能です。

毎日21:00 → AIがBacklog課題やMTG内容を巡回 → 新しい決定事項を抽出 → Decision Logに追記

こうすることで、日々のBacklog上でのやり取りで決まったことが、翌朝にはDecision Logに反映されている状態を作れます。

エンジニアだけじゃない、PMも活用できる

コンテキストエンジニアリング × Decision Logの仕組みは、エンジニアだけのものではありません。むしろ、 PMや要件定義を行うメンバーにこそ大きな価値 があります。

PMの活用例

実際に、Backlog課題に対する返答をAIに生成させる場面では、コンテキストが蓄積されているため、過去の議事録やコメントのやり取りを踏まえた的確な回答がすぐに出てきます。「先週の定例で〜と決まりましたので、〜の方針で進めます」といった根拠付きの返答を、手動で議事録を探すことなく生成できます。

2つのプロジェクトでの実践比較

現在、Decision Logを導入しているプロジェクトと導入していないプロジェクトの2つでコンテキストエンジニアリングを実践しています。

Decision Logなしのプロジェクトでも、コンテキストエンジニアリング自体の効果は十分に出ています。議事録やBacklog課題が蓄積されているため、AIが過去の文脈を参照して作業を支援してくれます。ただし、仕様を抽出する際にはAIが議事録やBacklog課題のMDファイルを何十件も横断検索する必要があり、時間もトークンも大量に消費します。Decision Logがあれば、まずDecision Logを参照し、詳細が必要なときだけローデータを辿ればよいため、この差は歴然です。

しかし、決定事項が変更される頻度が高いプロジェクトでは、Decision Logがあることで 情報の鮮度管理 が格段に楽になります。特に、複数のベンダーやステークホルダーが関わる要件定義フェーズでは、決定→変更→再決定のサイクルが頻繁に発生するため、Decision Logの恩恵が大きいです。

始め方

Decision Log駆動のアプローチを始めるのに、大掛かりな準備は必要ありません。

ステップ1: コンテキストリポジトリを作る

まずは、プロジェクトの情報をローカルに集約するリポジトリを作ります。

my-project-context/
├── MTG/              # 議事録
├── Backlog/          # 課題管理ツールのエクスポート
├── CLAUDE.md         # プロジェクト概要
└── .cursor/
    └── rules/        # AIルール

本記事ではBacklogを例にしていますが、重要なのは 使っているツールの情報をプレーンテキストとしてローカルに集約できること です。JiraであればAPIやCLIでのエクスポート、Notionであればエクスポート機能やAPI経由でのMarkdown取得、議事録もGoogle Meet以外にTeamsやZoomの文字起こしをテキストで保存するなど、それぞれの環境に合わせた集約方法を検討してみてください。

Backlogの場合は、backlog-exporter でエクスポートできます。

pnpm dlx backlog-exporter@latest update

https://github.com/ShuntaToda/backlog-exporter

ステップ2: Decision Logを作る

Decision_Log.md をリポジトリのルートに作成します。

my-project-context/
+├── Decision_Log.md
 ├── MTG/              # 議事録
 ├── Backlog/          # 課題管理ツールのエクスポート
 ├── CLAUDE.md         # プロジェクト概要
 └── .cursor/
     └── rules/        # AIルール

# Decision Log

| # | 機能 | コンテキスト | 決定内容 | 選択肢 | 理由 | 根拠 | 日時 |
|----|------|--------|------|-----|----|----|----|

最初は空でOKです。定例会やBacklog課題で決定事項が出るたびに、レコードを追加していきます。

ステップ3: 更新を自動化する

AIエージェントのSkillを作成し、Decision Logの更新を半自動化します。Skillには以下のルールを定義します。

• 既存のDecision Logを読み込み、最終更新日時以降の新しい決定事項を探す
• Backlog課題のコメントや議事録から決定事項を抽出する
• 重複チェックを行い、新しいレコードのみを追記する
• 追記前にユーザーの承認を得る

ステップ4: 仕様はDecision Logから導出する

仕様書を別途メンテナンスするのではなく、必要なときにDecision Logから生成します。

「通知機能の現在の仕様を、Decision Logから整理してください」

AIがDecision Logの該当レコードを抽出し、最新の決定内容を整理した仕様書を出力してくれます。

実践の全体フロー

本記事のタイトルにある3つの要素は、そのまま実践フローに対応しています。

ポイントは、③の仕様書やPBIが Decision Logから自動的に導出される ことです。仕様書を別途メンテナンスする必要はなく、Decision Logが更新されれば、常に最新の仕様を生成できます。

プロダクトの品質は、仕様の正しさで決まる

この連鎖は、プロダクトの 「品質」や「信頼性」 の向上にまで波及します。

AIエージェント時代のプロダクト開発では、テスト駆動開発（TDD） の考え方に基づき、テストケースによってAIの出力を検証することが重要視されています。しかし、そのテストケース自体が正しいかどうかは、何をもって担保されるのでしょうか。

答えはシンプルで、 テストケースは仕様から導出され、仕様はDecision Logから導出される。そしてDecision Logはコンテキストから導き出される ということです。

コンテキストの蓄積 → 正確なDecision Log → 正確な仕様 → 正確なテストケース → AIが書くコードの検証も正確

つまり、コンテキストエンジニアリングによって蓄積されたローデータが正確であり、そこからDecision Logが正確に導出されていれば、仕様もテストケースも正確になります。逆に言えば、上流が曖昧なままテストを書いても、「間違った仕様を正しく検証する」という本末転倒な状態に陥ります。

コンテキストの蓄積こそが、プロダクトの品質を左右する すべての大元 なのです。
そして、これは最近注目されている ハーネスエンジニアリング の考え方にも通じるものだと考えます。

ハーネスエンジニアリングとしての側面

最近、AIエージェントの信頼性を高めるための技術として ハーネスエンジニアリング という概念が注目されています。ハーネスエンジニアリングとは、AIモデルそのものではなく、モデルの外側にあるすべて — コンテキスト管理、ツール連携、出力検証、安全装置、フィードバックループ — を設計する技術です。

現在のハーネスエンジニアリングの議論は、リンターやテストでAI生成コードの品質を守るといった 実装フェーズ の話が中心です。しかし、本記事で紹介した仕組みは、同じ原理を 要件定義フェーズ に適用したものとも言えます。

ハーネスエンジニアリングはまだ新しい概念であり、何を指すかは人によって異なります。ただ、コンテキストを蓄積し、Decision Logで意思決定の履歴を構造化し、AIエージェントによるプロジェクト管理を安定させる — これも一つの「ハーネス」と言えるかもしれません。

コンテキストリポジトリがもたらす副次的なメリット

ここまでAIとの協働を中心に話してきましたが、コンテキストエンジニアリング × Decision Logの仕組みは、人間同士のコミュニケーションにも大きなメリットをもたらします。

• 過去の判断を素早く振り返れる — 定例会のたびに「なぜこうなっているのか？」という問いに時間を割かなくて済む
• 無駄な議論やコミュニケーションを削減できる — 決定の理由が明確になることで、同じ議論を何度も繰り返すことがなくなる
• 新メンバーが早くキャッチアップできる — 過去の意思決定の背景を短時間で把握でき、業務への適応がスムーズになる

特に3つ目は、運用保守フェーズでの引き継ぎ時に威力を発揮します。新しく参画したメンバーがコンテキストリポジトリに対してClaude Code等で「この機能の現在の仕様と、その経緯を教えて」と質問するだけで、Decision Logとローデータから根拠付きの回答が返ってきます。引き継ぎ資料を別途作る必要もなく、リポジトリそのものが生きたナレッジベースとして機能するのです。

おわりに

今回は、コンテキストエンジニアリング × Decision Logで実現する「アジャイル版仕様駆動開発」のアプローチを紹介しました。

仕様駆動開発の課題は、ドキュメントが陳腐化し、その根拠がわからなくなることです。コンテキストエンジニアリングの課題は、過去の決定事項も含めてすべてが「事実」として扱われてしまうことです。

Decision Logはこの2つの課題を同時に解決します。決定事項を時系列で追記し続けることで、AIが「最新の決定」を判断できるようになり、仕様書は必要に応じてDecision Logから導出できるようになります。

大事なのは、 仕様書を「作る」のではなく、意思決定のログを「蓄積」すること 。そして、そのログがコンテキストエンジニアリングの蓄積されたローデータと紐づくことで、根拠のある仕様として機能するということです。

また、今後AWSのDevOps Agentのようなエージェントがさらに成長したとき、このコンテキストリポジトリが新たな可能性を開くと考えています。現在のDevOpsエージェントはシステムのエラー検知や自動修復が中心ですが、コンテキストリポジトリを渡すことで「なぜこの機能がこう設計されているのか」「過去にどんな意思決定があったのか」まで理解した上で判断できるようになります。システムだけでなく プロジェクト全体を理解したDevOpsエージェント — そんな未来に向けて、今からコンテキストを蓄積しておくことには大きな意味があるはずです。

以上、どなたかの参考になれば幸いです。

お知らせ

本記事で紹介したアプローチを実践しているクラスメソッドのリテールアプリ共創部「ビルドチーム」では、Webアプリ開発エンジニアを募集しています。

アセット × 生成AI（Cursor、Claude Code等）を活用した高速なプロジェクト立ち上げを行うチームで、本日紹介したコンテキストエンジニアリングやAI駆動開発を日常的に実践できる環境です。エンジニアでありながら顧客と直接対話し、要件定義からリリースまでを一貫して担当できます。

興味のある方はぜひご覧ください。

https://careers.classmethod.jp/requirements/web-engineer-build-team/

参考

https://dev.classmethod.jp/articles/context-aggregation-for-true-spec-driven-development/

https://dev.classmethod.jp/articles/simple-method-to-record-project-decisions/

https://github.com/ShuntaToda/backlog-exporter

https://code.claude.com/docs/ja/scheduled-tasks