「.NET 開発基盤部会 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
ルールベース → 機械学習、深層学習
詳細 †
違い †
開発の流れ †
色々な難しさ †
- エラー（侵入検知でもあったアレ）の責任
- TP：True Positive
- FP：False Positive
- TN：True Negative
- FN：False Negative
- 倫理的・法的・社会的課題
（ELSI：Ethical, Legal and Social Issues）
組織と文化 †
AI活用を拡大するための組織
主な挑戦は技術ではなく文化
体制 †
- チームの構築
強いマトリックス型
- Hub（中心となるグループ）
- Spork（ビジネスユニット）
- Gray Area（繋ぐ領域）
- CTO直下
- 決裁権がある。
- ビジネスインパクトが解る。
- 技術もプロダクトも解る。
成功例と失敗例 †
- 失敗した企業の例
- 発注ベースで取り組んでいる。
- 技術やプロダクトが解っていない。
- 現場の理解が得られずデータが集まらない。
- 成功する企業の例
- 内製化に成功している。
- 人材の戦略的育成
- 担当者と現場の協力体制
- スピード感のある柔軟な進め方
ポイント †
アジャイル †
- PoC（Proof of Concept：概念実証）
- 試してみないと解らない（仮説検証の試行錯誤を含む）。
- 適応型ライフサイクル（アジャイル手法、変化駆手法）が基本。
評価方法の決定 †
プロジェクト目標を明確化して共有する。
- 難易度への理解
- ベンチマーク方法の策定
- 指標の決定
自社オペレーション †
- データセットの収集・ラベリングの質を担保（✕：業務委託
- MLOps（Machine Learning Operations）を運用するための作業が必要。
PDCA速度の向上 †
リリース後の改善する計画も必要
アンチパターンの理解 †
- 実現可能性を見誤る。
- 特定の手法に入れ込み過ぎない。
- 高度な手法が良いとは限らない。
- 試してみないと解らない
（仮説検証の試行錯誤を含む）。
事例 †
- ビジネス価値があり、経営層からの理解とバックアップがあった。
- 足りないAIスキルは外部ベンダーをパートナーに選定し適切に協業する。
- AIベンダーは技術よりコンセプトを固めるところのパフォーマンスを重視した。
- オペレーターとディスカッションしシステムに反映して行くプロセスを繰り返した。
- AI開発が必要な部分をできるだけコンパクトにしてスピーディーに開発した。
- コンセプトで教師データを用意してしてトライ・アンド・エラー
- AIの眼から判断した情報とクレーンを操作するロジックの結合部分を開発
参考 †
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
