AIの揺らぎに“コシ”を与える階層化品質設計

Transcript

1. AIの揺らぎに “コシ” を与える階層化品質設計 同人ソフトサークル Project ICKX 若葉 章 @effy_staffs (EFFY開発チーム)
2. 自己紹介 • 若葉 章（わかば あきら） • 2010年～ 同人ソフトサークル project ickx • プロデューサー / 営業 / インフラ / サーバサイド... / ゲームの実開発以外全部 • 本職はスタッフエンジニアっぽいこともするphpエンジニア • php続けてもうすぐ26年 php3の頃からお世話になっています • 最近の趣味は自転車とコーヒーとアマチュア無線 • tyrell iveで京阪や徳島から高松まで走ったり、icom ic-705やID-52で移動運用試したり • ボトルゲージ用のアルミステーやドリッパーホルダの自作を始めましたもうだめだ • Nintendo Switch で『VERTICAL STRIKE ENDLESS CHALLENGE』販売中 • Qiitaで『phpで高速に・省メモリ・確実に日本語csvを扱う方法』公開中 https://qiita.com/wakabadou/items/84b48ca12f25fb2fb69c 「composer require fw3/streams」をよろしくね。 「composer require tacddd/tacddd」もよろしくね。 「composer require bypassflow/crypt」もよろしくね。
3. Tyrell IVE Sports complete Santillo Cicli RB-01e
4. 「FIDLOCKさんボトルゲージマウンタ出して？」 「何？！やりたくない？！？！」 「ムムッ！なら作るしかないな！！」
5. 「SIMPLIFYはドリッパー史上最大の40mmの穴を持ちます！！」 「適合するホルダーねぇじゃねぇか作る！！」
6. 宣伝 SJIS CSVを直接扱えるライブラリ “fw3/streams“ 人類作成Object Collectionでは恐らく世界最速 “tacddd/tacddd” 来るべきAI化時代に輝く “bypassflow/*” をよろしくね
7. 資料１ PHPカンファレンス関西2024やPHPerKaigi2024で 発表した”「“品質”が高いコード」って何？”を 読むとより理解が深まります
8. 資料２ PHPカンファレンス新潟2025で発表した ”「兵法」から見る"質とスピード"”を 読むとより理解が深まります
9. 資料３ PHPカンファレンス関西2025で発表した ”階層化自動テストで開発に機動力を”を 読むとより理解が深まります
10. 用語・原則
11. “テスト”
12. • リスクベースのアプローチの下で静的および動的技法を 用いソフトウェアが仕様や要求事項を満たしていることを 検証（Verification）妥当性確認（Validation）する 一連のプロセス • 有限のテストケースによる実行や解析を通じて欠陥を検出 し、品質情報を提供するもの ISO/IEC/IEEE 29119-1:2022で定義される ソフトウェアテストでは
13. “品質”
14. “品質”とは “対象”に“本来備わっている特性”の 集まりが“要求事項”を満たす“程度” ISO 9000 (JIS Q 9000:2015)
15. ISO 25000で定義される “ソフトウェアの品質”では 明示された条件下で使用するとき、 明示的ニーズ又は暗黙のニーズを満たす ためのソフトウェア製品の能力 ISO/IEC 25000:2014 (JIS X 25000:2017)
16. つまり“品質”とは “要求を満たしていること”
17. “高品質”
18. “高品質”とは • “定められた要求事項”に対して“要求を満たしている”こと です。 • 超過でも未満でもなりません。 • めっぽう忘れられがちですが、 未満だけでなく、超過もダメです。
19. “高品質” を達成するには？
20. レイヤごとに要求を 明確化しそれを達成する
21. 単一責任原則
22. モジュール、クラスまたは関数は、 単一の機能について責任を持ち、 その機能をカプセル化するべきである
23. 開放閉鎖原則
24. ソフトウェア要素は、 拡張に対しては開いており、 修正に対しては閉じているべきである
25. テストにおける 単一責任原則
26. テストは単一のスコープについて 責任を持ち、その検証・妥当性確認を カプセル化すべきである
27. テストにおける 開放閉鎖原則
28. テスト内容は 階層の追加に対しては開いており、 修正に対しては閉じているべきである
29. 階層化自動テスト
30. 階層化自動テストとは • 境界付けられたコンテキストに応じてテストを分割する • テストの関心事を見るべきものと完結できる単位で分割する • テストで見るべきものをフローと状態に分割する • 階層テストはそれぞれ独立して機能する • 階層テストはプロセスに要求されるコンテキストの有無で増減する • ツールの謳う使い方に囚われない • 上記を満たし、実施される自動テストが階層化自動テストである
31. • セッション・永続化を伴う複数URLへの一貫した操作 • 単一URLリクエストに対するレスポンス • リクエスト受け付けから出力までの処理コールツリー • 単一URLリクエストにおける検証処理 • 単一URLリクエストにおける変数割り当て • クラス、関数に対する入力と出力 画面遷移 のみ担当 画面描画 のみ担当 プログラムコール ツリーのみ担当 HTTP入力検証 のみ担当 アクションが生成 する変数のみ担当 処理の入出力 のみ担当
32. • セ ッ シ ョ ン ・ 永 続 化 を 伴 う 複 数 U R L へ の 一 貫 し た 操 作 • 単 一 U R L リ ク エ ス ト に 対 す る レ ス ポ ン ス • リ ク エ ス ト 受 け 付 け か ら 出 力 ま で の 処 理 コ ー ル ツ リ ー • 単 一 U R L リ ク エ ス ト に お け る 検 証 処 理 • 単 一 U R L リ ク エ ス ト に お け る 変 数 割 り 当 て • ク ラ ス 、 関 数 に 対 す る 入 力 と 出 力 リリース前 受け入れ前 PR前 コミット 単位 作業 単位 作業 単位 上書き 保存単位 テストプロセスフロー
33. テスト内容は 階層の追加に対しては開いており、 修正に対しては閉じているべきである
34. 階層化自動テストとは • 境界付けられたコンテキストに応じてテストを分割する • テストの関心事を見るべきものと完結できる単位で分割する • テストで見るべきものをフローと状態に分割する • 階層テストはそれぞれ独立して機能する • 階層テストはプロセスに要求されるコンテキストの有無で増減する • ツールの謳う使い方に囚われない • 上記を満たし、実施される自動テストが階層化自動テストである
35. AIの揺らぎに “コシ” を与える階層化品質設計
36. この登壇で 大切なこと
37. プロンプトの 話はしません
38. LLM系生成AIの”本義”
39. 以降、LLM系AIを 単にAIと呼称します
40. 意味的制約の中で 揺らぎ を提供できること
41. AIは 決定装置”ではなく” 探索装置である
42. その価値は ただ一つの答えを 決めること”にはない”
43. その価値は 揺らぐ海の中から 文脈に応じて異なる切片を 引き上げられることにある
44. 一方で
45. AIはインターネット上に 公開されている知識や言説の分布を 強く反映します
46. そのため、多くの場合において 最大公約数に近い答えを返しやすい
47. この性質によってAIの出力は 一見すると一定の方向へ収束 しているように見えます
48. 故にAIは”決定装置”であると 誤解されやすい特性を持ちます
49. しかし その収束は真理への到達を 意味しません
50. それは学習された言説空間の中で もっとも選ばれやすい切片が 浮かび上がっているにすぎないからです
51. AI遣いに ”大切”なこと
52. 重要なのは 決定を委ねること ではないです
53. • どの制約で比較し • どの検査で退け • どの根拠で採用するのか 重要なのは AIが引き上げた切片を にあります
54. AIが引き上げた切片を 我々はどう受け止めるのか
55. AIの出力したものは 成果物ではなく 候補でしかありません
56. 候補である以上採用を 考える必要があります
57. 採用という行為は通常 ことを指します • 定められた制約や基準の元 • 優劣を比較、検査し • 根拠を持って採用を決心する
58. ではこの採用の構造を 持たない場合、何が壊れるのか
59. AI利用に限った場合に 何が壊れるのか
60. 壊れるのはコードだけ ではありません
61. 本当に壊れてしまうのは “保証の所在”です
62. xUnitやってるから 保証できてるもん
63. いつもの品質保証観点では いろいろ突っ込みどころに あふれる何かですが
64. 一般的にはこの延長で コードが保証している と考えられている訳です
65. コードがドキュメントである も類例の一つですね
66. このコードがドキュメントは 暗黙的に次の保証が 含まれています
67. ビジネスモデル・ルール 業務状態 受け入れ条件 安全境界 UX 要求・制約・状態 判定基準
68. これがあるので 企画と開発 が協働しやすい訳です
69. ここに無制約のAIを導入すると 暗黙の保証が破綻しはじめます
70. AIは既存のコードと同じ形で 出力する保証はないので
71. そもそも、AIの本義は 釜で踊るうどん同様 揺らぐことにこそに 価値があります
72. つまり大切なことは AIが”正しい”コードを書く かどうかにはありません
73. 大切なのは が定められていることです 何が変わってよくて 何が変わってはいけないか
74. 保証対象 の 転換
75. 我々が日常的にお世話になる ものの中に「金属ボルト」が あります
76. これはISOやJISで定められた 要求仕様に従って作られている 大量生産品 です
77. 我々はボルトを 購入・利用するにあたり 素体となる合金の組成を 意識するでしょうか
78. アルミや鉄などの 大まかな材質の違い くらいしか意識しないですよね
79. 我々が見出す価値は 何でどうやって作られているか ”ではなく” 何が出来るものなのか なのです
80. 例えば 適正締付トルクに対して どれだけの適正締付軸力 を得られるのか
81. これに照らし合わせると AIを利用するにあたり 保証するべきことが 見えてきます
82. コードの同一性”ではなく” 成立すべき状態を保証する
83. 成立すべき状態とは？
84. • ビジネスモデル・ルール • 業務状態 • 受け入れ条件 • 安全境界 • UX • 要求・制約・状態 • 判定基準
85. • ビジネスモデル・ルール • 業務状態 • 受け入れ条件 • 安全境界 • UX 要求・制約・状態 判定基準
86. ビジネスモデルから安全境界まで が保証されているのならば 全てを作り直してもよいのでは？
87. • どの制約で比較し • どの検査で退け • どの根拠で採用するのか
88. ではこれらをどこに置き どうAIと協働すればよいのか
89. あらかじめ用意しておきました （6か月煮たものがこちらです）
90. 八百万と御柱 (Yaoyorozu & Mihashira)
91. 八百万 (やおよろず)
92. 八百万とは原義的には 数え切れないほど 多くの神々・もの・働きが 世界に宿るという考え方です
93. ここで重要なのは 単一の絶対者がすべてを 決めるの”ではなく” 多数の観点や働きが 並び立つことです
94. つまり八百万は 多様な観点が 同時に存在する世界観です
95. 実装としてのYaoyorozuは AIの出力、人間の判断、REQ、UI契約、 テスト、証跡、検証器 など、多数の観点を集め ひとつの実装を審議するための基盤です
96. 重要な点として AIの応答や人間の感想を そのまま正解にしません
97. 正しさは 要求ごとに固定された契約と 再実行可能な証跡によって保証します
98. つまり八百万は 揺らぎを否定する場所ではなく 揺らぎを審議可能な形に置く場所です
99. 御柱 (みはしら)
100. 御柱とは原義的には 神域や共同体に 打ち立てられる柱として 場の中心・境界・支えを 示すものです
101. 一方でみはしらを「三柱」と 取るのなら、三つの柱 あるいは三柱の神を 数える言葉となります
102. このシステムでは、 mihashira は「三貴子判定核」 として実装されています
103. 三貴子とは に代表される三柱の神々です • 天照大御神 • 月読命 • 須佐之男
104. 実装としてのmihashira は、 三貴子判定核の実行入口です
105. 1つの要求に対してUI契約検証と L1からL6の階層化テストを実行し その結果をALLOWまたはDENY として判定します
106. mihashiraは 実行されたコマンドの終了コード xUnit XML、UI契約検証結果 gate JSONを ログとして残します
107. 判定はAIの返答でも 人間の雰囲気でも コードの見た目でもありません
108. つまりmihashiraは AIが出した候補を 要求の証跡として 採用してよいかを決める判定核 です
109. まとめると ⚫ 八百万 揺らぎ、すなわち多様な切片を集め 審議可能にする ⚫ 御柱 揺らいではいけないものを固定する ⚫ Mihashira 固定された要求に対して通過判定を出す
110. AIは候補を出す 御柱は通してよいかを決める
111. この分担によって AIの揺らぎは 統制された形で 利用可能になります
112. 要求・UI契約 証跡・判定核
113. 要求(REQ)
114. 要求とは 何を満たすべきかを 固定する単位です
115. 要求がなければ 何を比較し 何を検査し 何を根拠に採用するのかを 決められません
116. 要求は 見るべき階層を分けます
117. ⚫ L1：処理保証 要求・制約・状態、判定基準を見る ⚫ L2：状態生成保証 業務状態が正しく作られるかを見る ⚫ L3：境界保証 安全境界と受け入れ条件を見る ⚫ L4：フロー保証 ビジネスルールと処理順序を見る ⚫ L5：表現保証 UXとUI契約を見る ⚫ L6：体験保証 業務状態と画面遷移を見る
118. 階層 タイトル 見るもの 保証対象 L1 処理保証 処理の入出力 要求・制約・状態 / 判定基準 L2 状態生成保証 アクションが 生成する変数 業務状態 / 要求・制約・状態 L3 境界保証 HTTP入力検証 安全境界 / 受け入れ条件 L4 流れ保証 プログラム コールツリー ビジネスモデル・ルール / 業務状態 L5 表現保証 画面描画 UX / 受け入れ条件 / 安全境界 L6 体験保証 画面遷移 ビジネスモデル・ルール / UX / 業務状態
119. L1-L6は偉さの定義や テストの種類では ありません
120. 保証したいものを どの階層で見るかを 分けるための名前です
121. なので 要求が必要とする階層だけ を判定すればよい
122. これによりAIの出力を 「なんとなくレビュー」 せずに済みます
123. UI契約
124. UI契約とは ユーザーに見えるべきもの 操作できるべきもの 見えてはいけないもの を固定する契約です
125. UI契約は見た目そのものを 固定するものではありません
126. UI契約が固定するのは 見た目”ではなく” ユーザーが果たせることです
127. 押せるべき操作があること 判断に必要な情報があること 見えてはいけない情報が 見えないこと
128. つまりUI契約は 画面の見た目ではなく 体験の成立条件を固定します
129. 証跡
130. 証跡とは 要求を満たしていることを 後から確認できる形で 残したものです
131. AIの出力は その場ではもっともらしく 見えます
132. しかし、もっともらしさは 採用の根拠にはなりません
133. 採用の根拠になるのは です • 何を実行し • 何が通り • 何が落ち • どの要求を満たしたか
134. 証跡があることで採用判断は その場の納得”ではなく” 後から追える根拠になります
135. 証跡がなければ 判断はその場限りになります
136. 証跡があれば AIの揺らぎを履歴”ではなく” 判定対象として扱えます
137. 証跡としては 終了コード、xUnit XML UI契約検証結果、gate JSON ログなどを残します
138. • 終了コード 実行結果が成功したかを示します • xUnit XML どのテストが通りどのテストが落ちたかを示します • UI契約検証結果 画面が体験の成立条件を満たしたかを示します • gate JSON 要求ごとの判定結果を機械が読める形で残します • ログ なぜその判定になったのかを人間が追える形で残します
139. つまり証跡とは AIが正しそうに見えた記録 ではありません
140. 要求に対して 通してよいと判断しうる 根拠です
141. 判定核 (Mihashira)
142. 判定核は 正しそうかどうかを 見ません
143. 判定核が見るのは です • 満たすべき要求があるか • 要求に対応する検査があるか • 検査結果が証跡として残っているか • 必要な階層が通っているか
144. 判定核は ALLOWまたはDENYを 返します
145. ALLOWとは要求に対して 候補を採用してよい という判定です
146. DENYとは要求に対して 候補を採用してはいけない という判定です
147. ここで大事なのは DENYは失敗ではない ということです
148. DENYはAIの揺らぎを 安全に受け止めた結果です
149. 落とせるから 何度でも生成できます 通せるから 根拠を持って採用できます
150. この判定核があることで AIの出力は成果物”ではなく” 候補として扱えます
151. 不易と流行
152. 生成AIは現時点においてまだ 流行の品です 一方、品質構造は世紀を超えて なお続く不易です
153. 流行を使うには 不易を外に出す必要があります
154. コードは 流行に近づきます
155. 要求は 不易に近づきます
156. UXは 不易に近づきます
157. ビジネスモデルは さらに不易に近づきます
158. なのでAI時代において 固定すべきものは コードではなくなります
159. 固定すべきものは 要求、制約、検査 証跡、判定 です
160. AIが揺らぐなら 揺らぎを止めるの”ではなく” 揺らぎを受け止める構造を作る
161. それが
162. 階層化品質設計
163. です
164. 結び
165. AIは 決定装置”ではなく” 探索装置です
166. 品質とは 要求を満たしていることです
167. なのでAI時代の品質保証は になります • AIに決定させること”ではなく” • AIの候補を通す構造を設計すること
168. プロンプト”ではなく” 品質構造を持つ
169. コード”ではなく” 保証したい状態を見る
170. 組成”ではなく” 何が実現できるのかを見る
171. AIの揺らぎに “コシ”を与える
172. AIの揺らぎに “コシ”を与えるとは 揺らぎを消すこと”ではなく” 揺らいでも要求へ戻れる 復元力を設計することです
173. それが 階層化品質設計です
174. 実装とサンプル
175. 今日話したものは 概念だけではありません 実装・雛形・証跡サンプルを GitHubで公開しています
176. yaoyorozu-system/core • 八百万審議基盤の中核です • REQ、UI契約、証跡、判定核、CLIを扱います https://github.com/yaoyorozu-system/core composer require yaoyorozu/core
177. yaoyorozu-system/sample-template • 八百万を組み込むための Symfonyサンプル雛形です • 新しく始める場合はここから使います https://github.com/yaoyorozu-system/sample-template
178. yaoyorozu-system/sample-artifact • 実装済みサンプルアプリに REQ、UI契約、L1-L6テスト、証跡を 付与した成果物サンプルです https://github.com/yaoyorozu-system/sample-artifact
179. 見る順番 • 動く実例を見るなら => sample-artifact • 新しく始めるなら => sample-template • 仕組みを読む、導入するなら => core