AI時代の認知負荷との向き合い方

Nagoya Tech Talk #2

Transcript

1. Motty AI 時代の認知負荷との向き合い方 Nagoya Tech Talk #2
2. 東京オフィス 東京都新宿区新宿1-23-1 THE PORTAL 新宿御苑3F 名古屋本社 愛知県名古屋市中村区名駅3 丁目2-22 エスカ名駅東ビル 401 設立 2020 年3 月 共同創業者 代表取締役CEO 渡邉 昂希 取締役CTO 荒川 準也 従業員数 33 名（アルバイト/ 業務委託含めず） 事業内容 AI でジム運営が180° 変わる「GYM DX 」 プライバシー配慮の見守りAI カメラ「KAIGODX 」 等 株式会社Opt Fit Nagoya Tech Talk 1 / 14
3. ジム内に専用カメラを設置し ジム運営をAI 化するDX サービス GYMDX Nagoya Tech Talk 2 / 14
4. 介護・福祉施設内に見守りカメラを設置し 業務負担の軽減とQOL 向上を目指すDX サービス KaigoDX Nagoya Tech Talk 3 / 14
5. 社員数人に対し、15 人程度の業務委託  正社員 業務委託1 業務委託2 業務委託3  弊社のエンジニア組織の構成 外部の実装パワーが強い反面、最終責任と コンテキスト把握は少数の正社員に集中 − 社員側に認知負荷が集中しがち − Nagoya Tech Talk 4 / 14
6. AI エージェントも優秀な外部リソース 1. 自律性の限界 2. 責任の所在 3. コンテキストの欠如 手を動かす人（AI/ 外部）から、指示・確認する人（正社員）へボトルネックが移動 AI と業務委託（外部リソース）の類似点 能力はあるが、権限が不足 − 最終的な責任は負えない − 詳細な要件を伝える必要がある − Nagoya Tech Talk 5 / 14
7. 全員がAI を活用すると 未来のエンジニア組織？  正社員  AI 業務委託1 業務委託2 業務委託3  弊社のエンジニア組織の構成（AI 導入） アウトプット速度の爆発的向上 − レビュー地獄 − 認知負荷の爆発 − Nagoya Tech Talk 6 / 14
8. 扱うプロジェクトが増加する 「保証」を委託できない なぜ認知負荷が増えるのか？ プロジェクトの詳細知識 人間の認知範囲 − 検証 ≠ 保証: 動くことと仕様として正しいことは 別物 − AI は現実の要件を完璧に理解していない − 上流工程の要件定義を伝えるだけでは足りない − Nagoya Tech Talk 7 / 14
9. 事例：要求仕様をAI エージェントに渡し実装させた バイブコーディングの失敗例 外部依存の強いサービスの修正 − AI は与えられた情報内で完璧なコードを書いた − 連携先のデータ仕様の伝達漏れがあり、不整合発生 1 行1 行詳細にレビューすれば気づけたが、認知負荷がさらに増大 − Nagoya Tech Talk 8 / 14
10. 関係するシステムの技術仕様まで要件として含める必要性 インテグレーションの壁 特に技術的負債が大きいシステムだと把握が困難 − そもそも考慮に入れるべきかどうかの判別すら困難 − 仕様駆動でもAI が完璧に整理してくれるとは限らない アーキテクチャが複雑で、情報が散乱しているとAI 活用のメリットが小さい − Nagoya Tech Talk 9 / 14
11. AI の出力は信頼できないが、人間でも同じ 初歩に立ち返る 1. シフトレフト 2. 標準化 3. 情報の整理・構造化 ソフトウェアエンジニアリングの重要性 テスト・検証前提で開発し「人間が保証する範囲」を狭める − レビュー観点を絞り、認知負荷を下げる − コンテキストや詳細仕様を把握可能に − Nagoya Tech Talk 10 / 14
12. PR に「どのような検証を行ったか」 の記載を必須化 レビュワーの確認事項を圧縮 将来的にはCI に統合する予定 画像はイメージです 取組み例1: 検証した内容の明示 Nagoya Tech Talk 11 / 14
13. ADR × AI Reviewer 取組み例2: 標準化とAI による自動化 設計判断やルールをADR として ドキュメント化 (Git 管理) − PR で、ADR に基づいてAI が自動で指摘 − 人間はロジックや仕様の正当性の レビューに集中 − Nagoya Tech Talk 12 / 14
14. GitHub Project やマイルストーンの活用 取組み例3: コンテキスト構造化 プロジェクトと各Issue 、PR を 紐付ける − タスクのコンテキストを探索可能 にし、レビュワーが要求仕様を把 握可能にする − Nagoya Tech Talk 13 / 14
15. AI は増幅器である 人間が「保証」しやすい仕組みを作るべき まとめ 良いプロセスがあれば、速度と品質を増幅する − 悪いプロセス（曖昧な要件・テスト不足）があれば、技術的負債を増幅する − どのような検証が成功しているのか把握しやすくする − 意思決定やコンテキストを整理・構造化し、仕様を把握しやすくする − Nagoya Tech Talk 14 / 14