制約を設計する - 非決定性との境界線 / Designing constraints

設計ナイト 2026の登壇資料です。

Transcript

1. 設計ナイト 2026 制約を設計する - 非決定性との境界線
2. What is it? https://bliki-ja.github.io/LLMsBringNewNatureOfAbstraction
3. “LLM（大規模言語モデル）の登場は、アセンブラから最初の高水準プログラミング言語への 移行と同じくらい、ソフトウェア開発を大きく変えると思います。 その後に開発された言語やフレームワークは、抽象化のレベルや生産性を向上させました が、プログラミングの本質に同じレベルのインパクトを与えるものではありませんでした。し かし、LLMには最初の移行と同程度のインパクトがあると思います。 しかも、単に抽象化のレベルを上げるだけでなく、「非決定的なツールでプログラミングする とはどういうことか」という問いを私たちに投げかけています。” 引用元：LLMは新しい抽象化をもたらす What is it?
4. “私たちは仕事でLLMの使い方を学びながら、こうした非決定性とうまく付き合う方法を見つ けなければなりません。この変化は劇的なものです。 私はワクワクしています。残念ながら失うものもあるでしょうが、私たちがまだ理解できてい ない新たな価値も得られるでしょう。こうした非決定性の進化は、私たちの職業の歴史にお いて前例のないものです。” 引用元：LLMは新しい抽象化をもたらす What is it?
5. 非決定性と どのように向き合っていくか What is it?
6. 制約を活用して 決定していく What is it?
7. 1. 自己紹介 2. 非決定性との境界線を作る 3. 制約が決定性を作る 4. 制約以外のアプローチ 5. おわりに あじぇんだ
8. 1. 自己紹介 2. 非決定性との境界線を作る 3. 制約が決定性を作る 4. 制約以外のアプローチ 5. おわりに あじぇんだ
9. 自己紹介 曽根 壮大（41歳） Have Fun Tech LLC 代表社員 株式会社リンケージ CTO 兼 COO そ • 日本PostgreSQLユーザ会 勉強会分科会 担当 • 3人の子供がいます（長女、次女、長男） • 技術的にはWeb/LL言語/RDBMSが好きです • コミュニティが好き たけ ね とも
10. 経歴 高校卒業 浪人 警察官 派遣社員 社内SE インフラエンジニア Web エンジニア フルスタック エンジニア CTO（第1期） Customer Reliability Engineer CTO（第2期） 独立 ここから東京 いまここ リーマンショックと警察官の退職 タイミングが重複する ソフトウェア エンジニア CTO（第3期） COO & CTO
11. 1. 自己紹介 2. 非決定性との境界線を作る 3. 制約が決定性を作る 4. 制約以外のアプローチ 5. おわりに あじぇんだ
12. LLMは非決定性の特性によって 抽象度を高めている 非決定性との境界線を作る
13. 非決定性との境界線を作る インプット アウトプット 1回目 アウトプット 2回目 アウトプット 3回目 LLM アウトプットが不定
14. ？？？「AIで確認すればいいのでは？」 非決定性との境界線を作る
15. 非決定性との境界線を作る インプット アウトプット 1回目 アウトプット 2回目 アウトプット 3回目 LLM 複数回を回しても アウトプットは不定 アウトプット 1回目 精度は上がる
16. これは人間も似ている 非決定性との境界線を作る
17. 非決定性との境界線を作る インプット アウトプット 1回目 アウトプット 2回目 アウトプット 3回目 人間 アウトプットが不定
18. 人間も 同じアウトプットを出すわけではない 非決定性との境界線を作る
19. 人間も 同じアウトプットを出すわけではない 非決定性との境界線を作る LLMは確率的に答えるし、人間は経験的に答える
20. 人間も 同じアウトプットを出すわけではない 非決定性との境界線を作る だから標準化する LLMは確率的に答えるし、人間は経験的に答える
21. 非決定性との境界線を作る インプット アウトプット 1回目 アウトプット 2回目 アウトプット 3回目 スループット （処理） 同一のアウトプット 処理を標準化する 品質が高まり均一化する
22. • 標準化によって単純化・統一化などが行われて品質が向上する ◦ つまりアウトプットのばらつきが揃う • 手順の標準化は手順書を作ること ◦ 入力の標準化のためにテンプレートを作ったり、判断分岐を 網羅して対応する行動を決める • チェックリストを作ることで必要な仕様を満たすことを確定させる • つまり暗黙知を明示的で測定可能で更新可能な仕組みに変えること ◦ 業務の言語化とも言える 非決定性と標準化
23. 非決定性との境界線を作る 非決定性の高い状態 決定性の高い状態 どこかで境界線を作る必要がある
24. ソフトウェアはハードウェアのために 非決定的な現実世界を仕様として決定する 非決定性との境界線を作る
25. ソフトウェアの世界 非決定性との境界線を作る Webフォーム REST API バリデーション ロジック 型 データベース 決定性の世界 Webフォームが境界線
26. 再現性を高めるためには 境界線が必要 非決定性との境界線を作る
27. 1. 自己紹介 2. 非決定性との境界線を作る 3. 制約が決定性を作る 4. 制約以外のアプローチ 5. おわりに あじぇんだ
28. 制約が決定性を作る 制約が決定性を作る
29. 制約が決定性を作る ↓ ソフトウェアの世界の制約が境界線を作る 制約が決定性を作る
30. 制約が決定性を作る ↓ ソフトウェアの世界の制約が境界線を作る 制約が決定性を作る 品質の担保と安全性を設計する
31. 制約が決定性を作る 平日午後でミーティングを空き時間に設定して
32. 制約が決定性を作る 確かに設定してくれるが品質が安定しない
33. 制約が決定性を作る 平日午後でミーティングを空き時間を 検索するクエリを作って GAS API
34. 制約が決定性を作る GAS API バリデーションでハルシネーションを防げる
35. 制約が決定性を作る GAS API エラー処理もできるし、リトライもできる
36. • RESTなどのAPIは責任境界線とセットで決定性を作る ◦ 類似にCLIのインターフェースがある ◦ 標準入力のバリデーションが制約として境界線を作る ◦ アウトプットの品質が固定される ▪ 中身がLLMだと非決定性が維持される • データ層は決定された事実が保存される ◦ 集計結果や分析の元になるデータは揺らいではいけない ▪ 結果のノイズになってしまう • 契約プログラミングに似ている ◦ どうやって決定されたデータやオブジェクトを扱うか ソフトウェアで作る境界線の例
37. 制約によってガードレールを作る 制約が決定性を作る
38. 1. 自己紹介 2. 非決定性との境界線を作る 3. 制約が決定性を作る 4. 制約以外のアプローチ 5. おわりに あじぇんだ
39. 制約によってガードレールを作る ↓ AIの方向性を整える 制約以外のアプローチ
40. 制約以外のアプローチ AI ゴール 制約の壁 制約の壁
41. 制約以外のアプローチ AI ゴール 制約の壁 制約の壁 間違った方向に行かない
42. 制約以外のアプローチ AI ゴール 制約の壁 制約の壁 しかし、制約ではゴールに 直接的には導かない
43. ？？？「ハーネスエンジニアリング？」 制約が決定性を作る
44. ？？？「ハーネスエンジニアリング？」 ↓ ハーネスエンジニアリングも 標準化の方向性の一つ 制約が決定性を作る
45. コードをゴールに導く 制約が決定性を作る
46. • テストコードはソフトウェアに対する期待値を明確化する • オブザーバビリティはソフトウェアの振る舞いを可視化する • 境界線がソフトウェアのスコープを決める ◦ ドメインモデルと一緒 • アウトプットの品質指標がコードの方向性を決める ◦ しかし、安易な指標はグッドハートの法則を生む ◦ これは残念ながらLLMも一緒 ゴールに導くための手法
47. • テストコードはソフトウェアに対する期待値を明確化する • オブザーバビリティはソフトウェアの振る舞いを可視化する • 境界線がソフトウェアのスコープを決める ◦ ドメインモデルと一緒 • アウトプットの品質指標がコードの方向性を決める ◦ しかし、安易な指標はグッドハートの法則を生む ◦ これは残念ながらLLMも一緒 ゴールに導くための手法 こないだt_wadaさんが良いこと言ってたので どっかで登壇してくれると思う
48. 個人的にはモデルが変わると 陳腐化するので不毛感がある 制約が決定性を作る
49. 個人的にはモデルが変わると 陳腐化するので不毛感がある 制約が決定性を作る みんなの頑張ってくれた集合知に乗っていくぞ！
50. 1. 自己紹介 2. 非決定性との境界線を作る 3. 制約が決定性を作る 4. 制約以外のアプローチ 5. おわりに あじぇんだ
51. 今までは人間のふわっとした要求を 仕様として決定してきた おわりに
52. 今後は人間とAIの非決定性を ソフトウェアとして決定していく おわりに
53. AIがどんなに発展しても 仕事は形は変われど抽象度を高めれば一緒 おわりに
54. AIがどんなに発展しても 仕事は形は変われど抽象度を高めれば一緒 おわりに もうしばらくは……。たぶん。
55. 知識があるものが AIを活用できることは間違いない おわりに
56. https://soudai.hatenablog.com/entry/2026/01/18/133044 概ね、理由は以下のとおり。 • 良い質問をするために知識が必要 • AIの出力を評価する • 抽象的なアドバイスを活用する 　これらを実行するためには、一定の知識とスキル が必要である。 スキルを身につけるためには基礎 知識があるうえで経験が必要であり、そのサイクル がまさに学びなのである。 　そのため、AIが普及したとしても、人が学ぶことの 重要性は変わらない。 その前提を踏まえたうえで、 各ポイントについて説明する。
57. 半年後にはどうなっているかわからない おわりに
58. 半年後にはどうなっているかわからない ↓ だからこそ変化出来る設計が大事 おわりに
59. どうでもよいことは流行に従い 難しいことは常識に従い 芸術のことは自分に従う – 映画監督 小津安二郎 おわりに
60. おわりに 撮影 : @uzulla
61. どうでもいいことは流行りに従い、 重大なことは標準に従い、 ドメインのことは自分ら設計する – 郡山 昭仁 おわりに
62. 不易流行（ふえきりゅうこう） いつまでも変わらない本質的なもの（不易）を大切にしつつ、 時代の変化に応じた新しいもの（流行）を取り入れるという考え方。根幹は 一つであり、伝統と革新を両立させ、変化し続けることこそが本質であると 指します – 松尾芭蕉(が言ったらしい) おわりに
63. 温故知新（おんこちしん） 「故(ふる)きを温(たず)ね、新しきを知る」 過去の事実を研究し、そこから新しい知識や見解をひらくこと。 – 孔子（論語から来ている） おわりに
64. 今も昔も同じことを言っている おわりに
65. 眼の前の問題を 解決できるのは自分だけ おわりに
66. もっと現実を楽しんで 設計を楽しもう おわりに
67. ご清聴ありがとうございました おわりに