どうも、大曲です。なんか今年は体調不良が多いです。もう35歳です。歳をとりました。
「AI Engineering Summit Tokyo 2026」で『ディスカバリーとデリバリーを繋ぐユーザーストーリーのAI化』というテーマで登壇してきました。この記事は、その登壇で話した内容をベースに、もう少し腰を据えて書き起こしたものです。
発表資料はこちらです。
過去に「CTOとしてAI導入での開発組織変化を振り返る」や「20周年を迎えたサービスでビジネスドメインと向き合いモダナイゼーションを推進」といった記事を書いてきましたが、今日はその続編にあたります。「コーディングが速くなった、その先で何が起きたか」 の話です。
話すこと
- AIで実装が速くなった結果、ユーザーストーリーの役割がどう変わったか
- その品質を「ハーネス」の発想で守ろうとして、何に挑戦し、どこで失敗したか
- ストーリーが変わると、チームの動き（合意・レビュー）がどう変わったか
話さないこと
- 個別ツール（Alloyなど）の細かい書き方・チュートリアル
- 具体的なプロダクトの仕様や、検出したバグの詳細
- これが「正解」だという主張（あくまで現場でやってみてどうだったか、の共有です）
前提：プロダクトチームの開発スタイル
本題の前に、私たちの開発の前提を共有させてください。
開発チームは、デザイナー・PdM・エンジニアが一体となった多様性のあるスクラムチームです。受発注の関係ではなく、3つのロールの3つのアウトプットが噛み合って初めてプロダクトの価値が決まる、と考えています。だから「誰か一人が要件を全部決める」という作り方はしていません。
デザイナー（ユーザー体験）／エンジニア（構築の困難さ）／マネージャー（ビジネス貢献）の3つの視点が重なるところに「プロダクト価値」がある。
開発プロセスはユーザーストーリーを軸にしています。作り方の流れはこうです。
- ソリューション決定 … 大枠の作るものを決める
- イベントストーミング … ビジネスドメインのイベントを洗い出して「軸」を作る
- ユーザーストーリー作成 … 軸を元に落とし込む
- 開発 … ストーリーを1つずつ作り上げてインクリメント
イベントストーミングを起点に、ユーザーストーリーを「WHYのループ（AIと並走する領域）」で作り、「HOWのループ（AIの完全領域）」で実装・受け入れチェックまで回す。
イベントストーミングは、過去のモダナイゼーション（Perl→Goのトラッキング刷新）でSWIFTメソッドとして取り入れてから、私たちの開発文化に根付いた手法です。ここで認識のズレやユビキタス言語をチームで揃えます。この「共通の言葉と軸を作る」作業が、後でAIに渡す軸としても、ハーネスの軸としても効いてきます。
ちなみにユーザーストーリーの形式は、価値を語る WHY（As / I want / So that） と、受け入れ基準の Acceptance Criteria（Given / When / Then） です。2024年頃は1ストーリー2〜3日で実装できる粒度が多く、受け入れ基準は1個、というのが標準でした。
1. ユーザーストーリーの役割の進化
実装が「2〜3日」から「数時間」になった
AIの一番直接的な効果は、1ストーリーの実装が2〜3日から数時間になったことです。
それで過去のストーリーを見返してみると、面白いことに気づきました。半分近くは、わざわざ細かくストーリーにせず、実装時にサクッとやった方がよかったものだったのです。例えば「成果通知のレスポンスで1×1pxの画像を返す」みたいな、数時間で終わる作業。これをわざわざ「価値の単位」として残す意味は薄い。
アジャイルの古典に「顧客にとっての価値の単位はフィーチャ（=ユーザーストーリー）であって、作業ではない」という話があります。今まさに、その『作業』だった部分がAIに吸収されていった、という感覚です。
ストーリーをリポジトリに入れ、抽象度が上がった
今のスタイルでは、ユーザーストーリーをリポジトリに入れ込んでいます。AIにコンテキストとして読ませるためです。詳細を詰めるストーリーやエラー系のストーリーは、開発担当（エンジニア）が書くことも増えました。仕組みとしては、SDD（仕様駆動開発）として OpenSpec を使っています。
イベントストーミングの結果もリポジトリに入れておくと、コンテキストさえ揃えばAIが一括でストーリー化してくれて、精度も高い。1ストーリー=1シナリオだったものが、1ストーリーに複数シナリオ・受け入れ基準が2〜4つへと、抽象度が一段上がりました。
現在のストーリーの一例（説明用の仮想ストーリー）。1本の中に正常系・部分確定・冪等・タイムアウト・観測の複数シナリオが束ねられ、受け入れ基準が増えている。
この発表のために、別角度で分析し直した
……正直なところ、ここまでで「いい感じに作れているな」と思っていました。
でも、この登壇のために、もう一段別の角度——ドメインの種類（DDDの中核 / 一般 / 補完）——で分析し直してみたんです。中核は事業の差別化になるロジック、一般はどこにでもある汎用、補完はその間です。このサブドメインの分類は、『ドメイン駆動設計をはじめよう ―ソフトウェアの実装と事業戦略を結びつける実践技法』（Vlad Khononov 著、増田亨・綿引琢磨 訳、オライリー・ジャパン） を参考にしています。
過去ストーリー（54本）をサブドメインで分類。中核＝事業の差別化、一般＝購入・標準で済む、補完＝方針を示せば任せられる。中核は約26%だった。
そうしたら、ちょっと思っていたのと違う結果が出ました。
- 全体で見ると、中核の比率は思ったより変わっていない（中核はだいたい25%前後）
- ただしプロジェクトごとに見ると大きく違う。トラッキング再構築のような事業の心臓に近いPJでは中核が80%にもなる一方、画面に一覧を出すだけのものは補完に寄る
プロダクト群ごとの中核/一般/補完の比率。トラッキングの再構築は83%が中核なのに対し、エンドユーザー向けの新機能開発は中核12.8%・補完71.8%。同じ「ストーリーを量産している」状態でも中身はまったく違う。
| 観点 | 過去（2024年頃） | 現在（2026年） |
|---|---|---|
| 粒度 | 2〜3日・受け入れ基準1個が多い | 2〜3日は維持・受け入れ基準2〜4個が当たり前・抽象度UP |
| 作成スタイル | PdMがライティング（週4個ほど） | PdM＋エンジニアが書いてそのまま開発も増加 |
| ドメイン分類 | 中核25% / 一般15% / 補完60% | 全体比率はほぼ変化なし／PJによって中核80%も |
ここで気づいたのは、「どれだけストーリーを量産しても、本質的な価値＝中核のストーリーが増えているとは限らない」 ということ。インフラ刷新や画面表示だけでは、真の差別化は生まれません。逆に言えば、中核に該当するストーリーがどれだけ生まれているかは、チームがアウトカムを出し続けているかの指標にもなりそうだと感じています。
実装が速くなって「ストーリーを作らなくていいパターン」も生まれた。残ったストーリーは抽象度が上がり、より濃いものとなった。そしてストーリーとして残すべきは、事業の中核を担うドメイン（差別化ロジック）。ここに注力して良いユーザーストーリーを作れるかどうかが勝負になる、と考えています。
2. ハーネスへの挑戦と失敗
ここからが、この登壇で一番話したかった「挑戦と、正直な失敗」の話です。
背景：結合部がバグの温床になる
AIで派生ストーリーやエラーケースの提案は、すごく楽になりました。ここはモデルが賢くなった恩恵が大きい。
一方で怖いのが結合部です。要件同士の矛盾、レガシーとモダンの境目、長年動いている特殊仕様。同じ仕様が複数のシステムに別々に実装されていて、その合流地点でズレてバグになる。人を減らした分、自律的に進む部分を全員がレビューできず、漏れが出る。
実装側はテスト・lint・CIで守られています。同じ「ハーネス」の発想を、要件・ストーリーの側にも持ち込めないか——それがこの挑戦の出発点でした。
WHYのループに Guide と Sensor を作り込んだ
ハーネスエンジニアリングの発想では、Agent = Model + Harness。モデルを直接いじるより、周りの仕組み（ハーネス）で守ります。守り方には2軸あって、Guide＝事前に方向づける予防と、Sensor＝事後に気づく検知です。
これをストーリーを作る側の「WHYのループ」に持ち込んで、自作のlintまで含めてガッツリ作り込んでみました。
WHYのループに組み込んだGuide/Sensor。ストーリー作成スキル・ユビキタス言語の注意点（Guide）、docs-lint／story-lint・集約不変条件の反例探索（Sensor）、複数リポジトリを横断するリサーチエージェント。構文・用語・構造のレベルはこれでかなり守れた。
構文・用語・構造のレベルは、これでかなり守れるようになりました。ここまでは成功です。
形式手法（Alloy / Z3）を試した
問題は「意味」のレベル——要件そのものの矛盾です。これを検証するために、形式手法のツールにも手を出しました。
試したのは Alloy / Z3 / TLA+ の3つです。それぞれの位置づけを整理すると、次のようになります。
| 観点 | Alloy | Z3（SMT） | TLA+ |
|---|---|---|---|
| 一言で | 関係の反例探索器 | 算術の確定ゲート | 時相・並行の振る舞い検証器 |
| ハーネス上の役割 | Guide（設計時・反例探索） | Sensor（CI・事後） | ※未導入 |
| 得意領域 | 関係・推移閉包（到達可能性）・状態の反例・越境整合 | 算術・カウント・集合等号・一意性・floor端数 | 時相論理・並行/分散プロトコル・安全性/活性 |
| 活用できそうな例（汎用） | ・権限ロールから「不正な状態」の確認 ・状態遷移図の到達性・デッドロック検出 ・参照整合（孤立した外部キーが無い） ・カテゴリ木/依存グラフに循環が無い |
・在庫数が負にならない ・割引後の金額 ≧ 0／料金の上限・下限 ・ポイント計算の floor 端数の保存則 ・採番IDの衝突なし（一意性） |
・並行処理で「二重確定／二重決済」を防止 ・リトライ（at-least-once）の冪等性 ・分散ロックのデッドロック非発生 ・リーダー選出/合意の安全性 |
| 世間一般の活用事例（実例） | ・Mondex ICカード（電子マネー）の検証 ・ファイルシステム/セキュリティプロトコルのモデル化 |
・記号実行ファザー SAGE で Windows/Office のセキュリティバグを発見 ・スマートコントラクト検査（Mythril 等） |
・AWS が S3 / DynamoDB の分散プロトコルを本番前に検証しバグ発見 ・Azure Cosmos DB / MongoDB の設計検証 |
実際にどんな感じか、簡単な例で示します。「注文は Active（有効） なときだけ Shipped（出荷） でき、Cancelled（キャンセル） した後は出荷できない」という、よくあるステータス遷移のルールです。
開発者が「こう書けばOKだろう」と書いたのが次のコードです。Active→Cancelled と Active→Shipped の遷移は許可していますが、in（「これ以外は禁止」とまでは言っていない）で書いているため、「Cancel後は出荷させない」を書き忘れています。
開発者が書いたつもりのルール。Active→Cancelled Active→Shipped は書いたが、「Cancelledを終端にする」一文が抜けている。
この仕様をAlloyに check させると、人が見落としていた反例——キャンセル後に出荷される経路——を、図として突きつけてくれます。
Alloyが提示した反例。Active→Cancelled→Shipped という、キャンセル後に出荷されてしまう経路が見つかった。
そこで「Cancelledは終端（その先に遷移しない）」という一文（no Cancelled.next）を足すと、反例は消えて健全になります。
no Cancelled.next を追加した修正版。check の結果は「No counterexample（反例なし）」になった。
Good な点：このように、Alloyで既存仕様を書き起こすと、過去に見落とされていた要件のズレや矛盾を実際に発見できました。複数サービスに多重実装されたロジックの結合部のズレが、反例として目に見える形で出てくる。これは新鮮でした。調べた範囲だと、DDD文脈ではAlloyの活用事例が多く、他はあまり見られませんでした。
そして More（失敗・課題） です。正直に書きます。
- AlloyやZ3はプロダクトコードとは別物で、放っておくとメンテナンスするものが増えるだけになる
- AIが言うがままになり、細かいロジックは人間の理解が追いつかない。チームに任せられる自信がない＝メンテナンス不可問題
- 計算周りは実コードのテストでも書けるので、Z3は無理に要らず、Alloyくらいで十分かもしれない
- サービス全体を対象にすると抽象が高すぎて当たり前のことしか出ない。逆に1リポジトリに絞ると細かすぎる、という粒度問題
「どこまでコード化すべきか」。サービス全体は抽象が高すぎる。効くのは境界づけられたコンテキスト（Bounded Context）の、中核に近いロジック（赤）。細かすぎる部分（灰色）は実コードのチェックで十分。
学びとしては、全部をコード化するのは失敗で、効くのは「コンテキスト単位（Bounded Context）の、事業の中核に近いロジック」に絞ること。特にリポジトリを跨ぐ重要なロジックは、結合の漏れ防止になります。そして大事な注記として、この取り組みはまだ未マージ・本番未稼働の実験段階です。「どの不変条件をコードに書くか」は、結局のところ人の設計判断でした。
ストーリーを「軸」に、AIとAlloyで挟む
ここまでを位置づけとして整理すると、こうなります。ユーザーストーリーが「作るべきものの軸」で、その軸をベースにAIが網羅的にストーリーを広げてくれる。そしてAlloyは、ユーザーストーリーの外側——既存ロジックやレガシーの謎仕様との矛盾——を受け持つ、というイメージです。
ユーザーストーリー（中央）を軸に、内側の網羅はAIが、外側＝既存・レガシーとの境界の矛盾検出はAlloyが担う、という役割分担のイメージ。
特に既存やレガシーの謎仕様と向き合うとき、Alloyに落とし込む価値は高いと感じました。逆に言えば、新規でゼロから作る部分はAIの網羅に任せられる。役割を分けるのがコツだと思います。
そしてこれは願望混じりですが——Claude Codeの ultracode のような、エージェントを束ねて深く検証する仕組みが当たり前になれば、こうした検証もサクッとカバーできる未来が来るかもしれない、とも思っています。
一番効いたのは「自由な環境提供」だった
ここが、今回一番の発見です。
要件をコード化することより、もっと効いたのは「自由な環境を提供すること」でした。
ユーザーストーリーを軸に、AIがテスト環境へデプロイして、テストDBにアクセスして、システム結合テストまで自分でやってくれる。APMで変なエラーが出ていないかを New Relic の MCP 経由でチェックする。静的に「正しく書けているか」を確かめるより、実際に動かしてからのフィードバックの方が、圧倒的に価値が高い。要件のチェックより、振る舞いのチェックをやり続けるDevOpsが重要になった、というのが実感です。
そして面白いのが、これを支えているのは、もともとセキュリティのためにやっていた整備だということ。
- テストと本番でAWSアカウントを分ける
- APMをテスト環境でもフルに使えるプランにする
- AWS SSOログインの短命トークンのプロファイルを使う
これらは元々コンプラ・セキュリティのための行動でした。でも、AIに安全に環境を触らせる土台としてそのまま効いて、恩恵がめちゃくちゃ上がった。本番には絶対に触らせない、という境界があるからこそ、テスト環境では思い切り自由に動かせる。セキュリティへの投資が、AI活用の前提条件にぴったり一致していたんです。これは想定外の嬉しい誤算でした。
結論として、リサーチやコンテキストの整備はもうSkillとモデルの力でかなり自然に作れる。その上で、人ですら気づけない矛盾を捕まえるには要件をコード化したSensorとGuideに価値があった。ただしドキュメント（Guide）だけでは限界があり、動かして確かめる（Sensor）とセットで初めて品質が守れる、というのがこの章の結論です。
3. チームでの変化
ハーネスを突き詰めているうちに、チームの文化の方が先に変わっていたことに気づきました。
合意の置き場所が変わり、レビュースルーが増えた
ストーリーの作成と開発を、同じ人が一緒にやることが増えました。「よしなに作っといて」で進む。すると、これまでプランニングで分けていたWHYのチェックとHOWのチェックがズレる。
そこで、合意の置き場所を使い分けるようにしました。
- アーキテクチャは事前に合意
- コアロジック＝ストーリーは必ずレビュー（要所は非同期じゃもったいないので対面で最速）
- 軽微なリファクタや微調整は、口頭で理解できればレビューをスルー
ポインティングのような見積りの儀式も、だんだん無くなってきました。
正直な反省：WHYの会話が減った
ここも正直に書きます。属人化も課題ですが、それ以上に「なぜ作るのか」というWHYの会話が、めっきり減りました。
「よしなに作る」で進んでしまう。重要なロジックはコードレビューで担保できる。でも、以前はストーリーを受け入れるときに、チームで「なぜこれを作るのか」を議論していたんです。その議論が減った。速くなった代償として、価値についての対話が痩せるリスクがある、ということです。
ユーザーストーリーを使ったWHYのコミュニケーションについては、過去に「ユーザーストーリーを元にした会話と定着」という記事でも書いているので、あわせて読んでみてください。
ずらせるもの・ずらせないものを明確にする
対策として、「ずらせるもの・ずらせないもの」を明確にするようにしました。
WHYの合意は、書く前にやらなくてもいい。でも、書いた後でもいいからストーリーレビューは必ずやる。タイミングはずらせるけど、レビュー自体はずらせない。むしろ、実装した後からストーリーを書き起こすハーネスがあってもいい——順番を逆にしてでも、軸は残す、という発想です。
やってみてどうだったか／まとめ
長くなりましたが、最後にまとめます。
一番強く感じたのは、ハーネスには「軸」が要るということ。そして軸として一番効いたのは、奇をてらった形式手法ではなく、イベントストーミングとユーザーストーリーでした。AIの時代でも——むしろAIの時代だからこそ——ビジネスから価値を捉える軸が効きます。
そして、ハーネスを追求してチーム開発を考えると、スクラムのイベントそのものにも影響が出る。実装のフィードバックループが、チームの動き方の方へ飛び出してくる。要件・実装・チーム運営が、だんだん地続きになっていく感覚です。
| 問い | やってみての答え |
|---|---|
| ① ストーリーの役割はどう変わったか | 約半分は実装に吸収。残るのは中核ドメイン＝価値の軸で、抽象度が上がった |
| ② 品質をどう守ろうとしたか | Guide/Sensorは作れた。形式手法は中核に絞れば有効だが未本番・実験。一番効いたのは「自由な環境提供」＝振る舞いの検証 |
| ③ チームの動きはどう変わったか | 合意の置き場が変わりレビュースルーが増えた。WHYの会話が減った反省。だから「ずらせる/ずらせない」を明確に |
繰り返しますが、これは正解ではありません。私たちの現場でやってみて、こうだった、という共有です。同じようにAIで開発が速くなって、「その先」を模索している方の何かのヒントになれば嬉しいです。
それでは、また。
この記事はAI Engineering Summit Tokyo 2026の登壇内容を再構成したものです。スライドは speakerdeck.com/oomatomo に公開しています。
