コンテキストの使い捨てをやめる — ビジネスルール駆動開発と miko —

Transcript

1. BUSINESS RULE DRIVEN DEVELOPMENT コンテキストの使い捨てをや める - ビジネスルール駆動開発 と miko - miko ビジネスルール駆動開発 のためのフレームワーク github.com/studyplus/miko 01 / 19
2. 伊尾木 将之 Masayuki Ioki テックリード Studyplus, Inc. 江戸時代エンジニア。江戸時代の研究をしながら、エンジニアやって ます。前職はIBM、クックパッド。本業は川崎フロンターレのサポー ター X @ioki GitHub github.com/kikaineko 02 / 19
3. GIGO Garbage In, Garbage Out だから「良いコンテキストを渡す」ことが重要 渡す入力（コンテキスト）次第で出力は別物 GIGO は AI 以前、1960年代からあるコンセプト 03 / 19
4. 現状 毎回、こうしている 1 その時点の理解で、手でコンテキストを組む 2 AI に渡して、結果（コード）を得る 3 その過程で理解は深まる——が、セッションが終わると蒸発する 4 次のタスクは、また同じ不足から始まる 同じことを調べ、同じ説明を組み立てるコストが、毎回かかる 04 / 19
5. アイデア 良いコンテキストを残し、次のタスクのコンテキストにする 使うほど賢くなるシステムが欲しい 作るのが大変なコンテキストを、いまはタスクのたびに使い捨てている 事前に分からなかったことも、進める中で明らかになっている 残せば、タスクのたびにコンテキストが育つ SDD（仕様駆動開発）を色々試したけど、求めていたものと違った 05 / 19
6. 残すべきコンテキストはどこに？ コード 仕様書・要件定義書 AIメモリ ビジネスロジックが、意 図かバグか、たまたまな のか判断が難しい 意図が複数のコードに散 らばって、再構築コストが 高い場合が往々にしてあ る 書いた瞬間から実態と乖 離するリスクが高い（腐 りやすい） 何が残るか制御が難しい 古くなっても気づけない 06 / 19
7. ビジネスルール 「このビジネスで何が真か」の宣言 —— BR・仕様・ビジネスロジックは層構造 BR 「出荷済みの注文はキャンセルできない」 what の宣言 仕様 「キャンセル実行時に出荷済みならエラー文言を画面に 表示」 how （挙動の決 め） ビジネスロジッ ク order.cancellable? && !order.shipped? how （コード） 仕様や実装が変わっても、BR は残る BR はビジネスの判断が変わらない限り 不変 07 / 19
8. ビジネスルール例 ### レポート機能の権限管理 - ルール1 対象ユーザーの参照権限が有効でなければならない - ルール2 参照権限の有効期限は、1 年を超えて設定できない - ルール3 有効期限の指定がない場合、有効期限は付与から 1 ヶ月とする 汎用性のない、かつ、コードを読めばわかる情報は書かない 合理的な代替案テスト A案B案どっちでもいいのに、A案を選んでいるのは、ビジネス判断 A案しかないような状況なら書かない（A案じゃなければ、バグ） 08 / 19
9. miko Claude Code のスキル群 ビジネスルール駆動開発 のためのフレームワーク
10. miko ビジネスルール駆動開発（BRDD）のためのフレームワーク Claude Code のスキル群 ビジネスルールを開発の中心においた開発 ビジネスルールを変更し、その変更に従ってコードを変更する ケイパビリティという単位で BR を管理 システム全部の BR を 1 ファイルで管理しない 大機能みたいな単位 10 / 19
11. ビジネスルール駆動開発（BRDD）Flow BR から始まり、BR を更新して終わる 1 提案 /miko.propose 2 検証 /miko.harae 3 実装 /miko.quick_impl BR への変更を proposal ファイルとして定義 proposal の BR に攻撃的検証 proposal を元に実装し、BR を更新 11 / 19
12. 提案（propose） 「やりたいこと」を、BR の改訂案にする ❯ /miko.propose contract 有料契約に初期データをつくって /miko.propose [ケイパビリティ名] [やりたいこと] 人は、変えたいことを話すだけ。miko が質問してくれる miko は関係 BR を読み、どのルールがどう変わるかを proposal にまとめる 変更の背景・動機・ルールの差分が、そのまま変更履歴として残る ここではまだ実装しない —— 判断を固め、合意してから実装へ 12 / 19
13. proposal # 既存の有料契約アカウントに、初期のトライアルデータを付与する ## 背景・動機 トライアル機能のリリース前から有料契約のアカウントには... ## ビジネスルールの変更 （どの BR がどのように変更されるか） ## 機能仕様 ... ユーザーとの対話から得た背景などが記載される 仕様などの詳細な情報もここに記載される 13 / 19
14. 提案（propose）: よかったこと 「有料契約に初期データを作って」と依頼 miko は BR を読んで指摘： 「永久無料と検証用も必要ですか？」 契約種別ごとの扱いが、BR に決めごととして書いてあった コードにあるのは「現在の実装」だけ 14 / 19
15. 検証 祓え（harae） 書いた BR を、6 軸で AI に攻撃させる ❯ /miko.harae contract/proposals/2026-06-09-init-data-for-paid-contracts.md 検証軸 例 内部矛盾 ルール A と B が同時に成り立たないケース 不完全性 決まっていない境界条件 境界の曖昧さ 「出荷準備開始」の正確な定義は？ 時間軸の破綻 日付変更線をまたぐとどうなる？ ビジネス毀損 このルールで売上が減るシナリオは？ 悪用耐性 ルールの抜け穴を突く行動パターン 15 / 19
16. 検証 祓え（harae）: よかったこと 既存のメール送信機能で、予期しない問題が起きた その機能の BR を miko で書き起こし、祓えにかけると： 指摘の中に、その問題の再現フローが出てきた 実装の誤りではなく、決めごとの考慮漏れ —— コードを読んでも「仕様どおり」 にしか見えない BR と祓えが先にあれば、実装の前に潰れていた 16 / 19
17. 実装（quick_impl） proposal を入力にして、コードを書く ❯ /miko.quick_impl contract/proposals/2026-06-09-init-data-for-paid- contracts.md 「読んで始め、残して終わる」 BR の更新も同じ PR でマージ 次のタスクは、その更新された BR を読むところから始まる 17 / 19
18. ビジネスルール駆動開発（BRDD）Flow BR から始まり、BR を更新して終わる 1 提案 /miko.propose 2 検証 /miko.harae 3 実装 /miko.quick_impl BR への変更を proposal ファイルとして定義 proposal の BR に攻撃的検証 proposal を元に実装し、BR を更新 18 / 19
19. BRDD —— 変更を BR から始め、BR を残 して終える miko —— BRDD のためのフレームワーク github.com/studyplus/miko