昔話 設計地蔵と働く人

AGI福岡 第10回 LT資料

Transcript

1. アーキテクチャが守ってくれていたもの MAY 2026 at AGI-FUKUOKA Y. Ebihara - coding agent と設計 -
2. 「設計地蔵と働く人」 ＊この物語はフィクションです
3. pylance strictで出てる 指摘は処理しやすか？ むかしむかし(3か月前)、 働く人は、 AIを利用していました。 use subagent searcher 完了しやした！ あるところに「働く人」がいました。 内製ソフトウェア構築に
4. coding agent による、 違和感がありました。 「壊れた実装」「低い追従性」は、 世間で語られる失敗談に、 これまでほぼ発生しておらず、 全部見えてるんで！ ここのreposは 問題ないっす
5. ある日、 働く人は、小規模な新規プロダクトの 指令を受信します。 use subagent searcher 実行していいすか？ 軽めのETLっすね
6. 働く人は片手間ながらも いつも通り、coding agent を動かした。 use subagent tester いつも通り とりあえず頑張る！ use subagent researcher use subagent planner use subagent plan checker use subagent programmer 次々と成果物が出力されてゆきます。 :
7. 一時の後…
8. そこには、想定外の実装が広がっていました。 sql conn, ddlの再開発 normalizeの処理機能重複 pandas 2～3系を網羅する後方互換 type hintすらない関数定義 野ざらしのpyとjsx 必要そうだったので 頑張って作りました これ(新規)はこれ。 それ(既存)はそれ。 地獄のような光景が広がっていたのです・・
9. 失意の中、 働く人は、原因を探り始めました。 subagent / skills / hooks / rules.. いつものハーネスが呼び出されている。 ？？ ？？ ・・となると、違いは？！ 相違点は・・
10. 既存 : 機能追加が主 - modular monolithによる機能の区画分け - port & adaptorsによる依存方向の固定化 vs 今回 :まっさらな新規プロダクト - monolith かつ 手続きスパゲッティ 設計が根本から違っていたのです！！ という事は、
11. プロダクトを守ってくれていたのです！！ アーキテクチャ(設計のお地蔵さん)が、
12. 原因が判明した後、 MVC → Layered → port & adaptors アーキテクチャを組み直し、 普段の生活を取り戻したのでした。 ありがてぇ！ めでたしめでたし。 monolith → modular monolithと
13. 問題の正体 既存プロダクトでは、 設計上のガードレールが常時発動 A : 「設計境界がない状態でcoding agent を動かした」 ことに起因 - modular monolith による区画分け - ヘキサゴナルアーキテクチャport & adaptorsによる依存方向の統一/外部の隔離 - 豊富なdocsによる判断材料の明示 一方、 新規プロダクトでは上記3点が無く、 観点不足により、 設計起因の齟齬が表面化した。 → 参照先の特定容易性がcoding agentにも適用されていた。
14. まとめ AA : 今まで私たちは、 規模に応じた設計を行ってきました。 BB : 設計による機能境界と依存方向は、 人間～AIの共通言語となる。 CC : ハーネスエンジニアリングに “何をどこまで含めるか?” これらも明示しなければ、 暗黙知と化してしまう。 という議論がありますが、 設計も重要な要素であると考えます。 初心忘るべからず。
15. - 三国間海外取引～国内取引～倉庫～営業～業務 を経験 - 社内効率化 & フロー改善の情報系部署 About 「働く人」 ・ Name : エビハラ ヨシタカ X @kuro_yos ・ 最近ハマっているもの : ebhr-san - ベランダ菜園楽しい。 イタリアンバジル育成中 ・ 船舶業界の独立系専門商社 - 業界歴 19 年
16. Thank you for your attention ご清聴ありがとうございました。
17. Appendix