④AI駆動開発 × システム工学　商用プロダクトをつくるための Why・What・How ｜ 文系の方にも分かるように

うさうさ研修工房 分析ノート AI駆動開発 × システム工学 商用プロダクトをつくるための Why・What・How ｜ 文系の方にも分かるように WHY：Sculley et al. 2015 WHAT：Amershi et al. 2019 HOW：Mitchell et al. 2019 なぜAI開発は「借金」しやすいのか 商用AI開発は何をする9工程か どう安全に届けるか＝モデルカード 査読済み国際会議録・学術誌に基づく一次情報のみを使用｜出典は各スライド末尾に明記

Why → What → How で読み解く 「AIだから難しい」を、 3つの問いに分けると驚くほど整理できます WHY WHAT HOW Sculley et al. (2015) Amershi et al. (2019) Mitchell et al. (2019) なぜAI開発は普通のソフト開発より 「借金」しやすいのか？ 商用AIプロダクトづくりは、実際どんな 作業の連続なのか？ 作ったAIを、どう安全に・誠実に届け るのか？ 隠れた技術的負債という考え方 データ3工程＋モデル6工程＝9工程 モデルカード＝AIの成分表示ラベル

WHY：AI開発はなぜ「借金」を抱えやすいのか Sculley, D., et al. (2015) ｜ Advances in Neural Information Processing Systems 28 (NeurIPS 2015), 2503–2511 たとえ話： AIモデルは「リボ払い」に似ている クレジットカードのリボ払いのように、 「今すぐ動くAI」は一瞬で手に入るが、後から利息（保守コスト）が静 かに膨らんでいく。 論文が指摘する「隠れた利息」の正体 絡み合い (Entanglement) だからシステム工学の視点が要る 普通のソフトはコードを見れば動きが分かる。 だがAIモデルは「コード＋データ＋学習結果」が一体化していて、 後から一部だけ直すのが難しい（＝本連載スライド 1で扱った Simon の“近可分解性 ”が壊れやすい）。 だからこそ、 「作って終わり」ではなく「壊れ方まで含めて設計する」というシステ ム工学的な発想が必要になる。 1つの入力データを変えただけで、関係ないはずの予測結果まで変わってしまう 隠れたフィードバックループ AIの出力が、知らぬ間に次の学習データに混ざり込み、自己強化してしまう 見えない利用者 (Undeclared Consumers) 他の誰かが無断でこのAIの出力を使い始め、変更できなくなる 境界のにじみ (Boundary Erosion) 「ここまでがAI」という境界があいまいになり、影響範囲が読めなくなる 要点： AIの「速さ」は借金でできている。返済計画（＝設計・監視・文 書化）を最初から織り込むのが商用開発の鉄則

WHAT：商用AI開発、実際は何をする 9工程か Amershi, S., et al. (2019) ｜ IEEE/ACM 41st ICSE: Software Engineering in Practice (ICSE-SEIP), 291–300 Microsoftの開発チーム観察調査から得られた 9段階のワークフロー データ指向 (Data-Oriented) → ① 収集 → ② 洗浄 ③ ラベル付け モデル指向 (Model-Oriented) ④ 要件定義 ⑤ 特徴量設計 ⑥ 学習 ⑦ 評価 ⑧ デプロイ ⑨ 監視 ※ 直線的に見えるが、実際は評価や監視の結果が①〜③のデータ収集に何度も差し戻される反復プロセス 商用開発での読み方： 「モデルを学習させる（⑥）」はAI開発の一部にすぎない。商用プロダクトとして成立させるには、データ収集〜監視までの全 9工程に人手と体制が要る— これが従来のソフ ト開発と最も違う点 出典: Amershi, S., et al. (2019). Software Engineering for Machine Learning: A Case Study. IEEE/ACM 41st International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP), 291–300.

HOW：モデルカード＝ AIの「成分表示ラベル」 Mitchell, M., et al. (2019) ｜ Proceedings of the Conference on Fairness, Accountability, and Transparency (FAT* '19), 220–229 食品の栄養成分表示のように、 AIにも「表示義務」を モデルカード ① モデル詳細（誰が・いつ・どんな種類のモデルか） なぜ商用プロダクトに必須なのか 説明責任 「なぜこの判断をした AIか」を後から説明できないと、商用サービスとして信頼を失 う ② 想定用途（何に使うために作られたか） ③ 要因（性能に影響する属性・条件） 誤用の防止 ④ 評価指標（何をもって「良い」とするか） 「想定用途」を明記することで、想定外の使われ方によるトラブルを未然に防ぐ ⑤ 評価データ／⑥ 学習データ（何で試験・学習したか） ⑦ 定量分析結果（実際の数値） チーム間の共通言語 ⑧ 倫理的配慮（想定されるリスク） 作った人（技術者）と使う人（営業・法務・顧客）の間の情報格差を埋める ⑨ 注意点と推奨事項（使う上での留意点） 個人開発でも：本格的な 9項目は重くても、「①②③⑧」の 4項目だけでも READMEに書け ば、利用者への誠実な情報開示になる 出典: Mitchell, M., et al. (2019). Model Cards for Model Reporting. Proceedings of the Conference on Fairness, Accountability, and Transparency (FAT* '19), 220–229.

Why・What・How をつなぐ — 商用AI開発の全体像 なぜ難しいかを理解し（ Why）→ 何をする仕事か把握し（ What）→ どう届けるか設計する（ How） WHY WHAT HOW 隠れた技術的負債を知る 9工程のワークフローで動く モデルカードで誠実に届ける Sculley et al. 2015 Amershi et al. 2019 Mitchell et al. 2019 AIは「速いが後で利息がつく」— まず危険 性の正体を理解する データ3工程＋モデル6工程を反復する — 学習はごく一部でしかない 成分表示のように用途・限界・リスクを開 示し、信頼される商用プロダクトにする 要点：AI駆動開発も特別な魔法ではなく、システム工学と同じ「境界を見極め・反復し・誠実に開示する」という型で乗り越えられる

出典一覧（査読済み国際会議録・学術誌） すべて査読済みの一次資料。孫引き・未検証情報は含まない 1 Sculley, D., Holt, G., Golovin, D., et al. (2015). Hidden Technical Debt in Machine Learning Systems. Advances in Neural Information Processing Systems 28 (NeurIPS 2015), 2503–2511. 2 Amershi, S., Begel, A., Bird, C., et al. (2019). Software Engineering for Machine Learning: A Case Study. IEEE/ACM 41st International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP), 291–300. 3 Mitchell, M., Wu, S., Zaldivar, A., et al. (2019). Model Cards for Model Reporting. Proceedings of the Conference on Fairness, Accountability, and Transparency (FAT* '19), 220–229. 作成：うさうさ研修工房｜たとえ話（リボ払い・成分表示ラベル等）と個人開発への適用は作成者による独自の解釈です。原典の精読を推奨します。 出典: Sculley, D., et al. (2015). Hidden Technical Debt in Machine Learning Systems. Advances in Neural Information Processing Systems 28 (NeurIPS 2015), 2503–2511.