Skip to content

DNET_AIProjectManagement

Jump to bottom
nishi_74322014 edited this page Sep 11, 2026 · 1 revision

AIプロジェクトのマネジメント

概要

ルールベース → 機械学習、深層学習

詳細

違い

企画

PoC的

色々な難しさ

実値＼予測値 異常がある（Positive） 異常がない（Negative）
異常がある（Positive） 真陽性（TP：True Positive） 偽陰性（FN：False Negative）
異常がない（Negative） 偽陽性（FP：False Positive） 真陰性（TN：True Negative）

※ メトリック

  • 中身を説明できない。

  • 倫理的・法的・社会的課題
    （ELSI：Ethical, Legal and Social Issues）

開発の流れ

→ AIの開発

保守・運用（違い）

AIの運用と更新があるので、
保守・運用の重要性が高い（→ ポイント）。

組織と文化

AI活用を拡大するための組織
主な挑戦は技術ではなく文化

体制

  • チームの構築
    強いマトリックス型

    • Hub（中心となるグループ）
    • Spoke（ビジネスユニット）
    • Gray Area（繋ぐ領域）

  • CTO直下

    • 決裁権がある。
    • ビジネスインパクトが解る。
    • 技術もプロダクトも解る。

成功例と失敗例

  • 失敗した企業の例

    • 発注ベースで取り組んでいる。
    • 技術やプロダクトが解っていない。
    • 現場の理解が得られずデータが集まらない。

  • 成功する企業の例

    • 内製化に成功している。
    • 人材の戦略的育成
    • 担当者と現場の協力体制
    • スピード感のある柔軟な進め方

AIの開発

ステップ

アルゴリズムの選択

アルゴリズムのアーキテクチャをデザイン

  • 確認事項

    • タスク要件の確認

    • データ要件の確認

      • データ取得が可能か？
        運用でないと or 運用ですらデータ取得できない。

      • ラベル定義が可能か？
        ・人間すら正解が解らない。
        ・学習方法の選択肢（機械学習（machine learning）の該当節を参照）も検討

    • 説明性の要件を確認
      ただし、以下は異なる可能性。

      • 研究領域の説明性
      • 事業領域の説明性

  • 組み合わせも可能。

データの収集

  • 中長期的なデータ収集設計の重要性

    • 取得に時間がかかる。
    • 後戻りができない。

  • 設計の手順

    • 実現したいことを整理

    • 実現に向けて必要なデータを整理

    • データを取得できるシステムを構築

      • 重要要素
        ・データセットの収集方法
        　・画像認識で言うと撮影方法等
        　・画角、照明、距離、画質 / FPS
        ・教師データ（機械学習（machine learning）の該当節を参照）の質の担保

試作モデルの開発と評価

指標 説明
IoU 物体検出の指標
AP 物体検出の各クラスのクラス分類の指標
mAP 物体検出の全クラスのクラス分類の指標（= (AP1 + AP2 + ... + APn) / n）

  • 精度とどう向き合うか？

    • 精度 ≠ 100％
      ・PM
      　・スコープの定義
      　・期待値のコントロール
      ・実装
      　UI / UX、運用でカバー
      　・確信度毎に通知方法を変える。
      　・確信度と判断基準を出力する。

    • 追加学習（機械学習（machine learning）の該当節を参照）の重要性

ポイント

PoC（概念実証）

  • PoC（Proof of Concept：概念実証）

  • ステップ

    • PoCの前の課題分析・仮説構築
      必須で最重要

      • 課題の特定

      • 不確実性の特定
        ・技術的に解決
        ・運用で解決

      • 仮説を持つ
        ・解かり易い仮説
        ・YES / NO、数値で答えられる。

      • 最小工数で検証

    • PoCとはリスクヘッジ
      投資の意思決定に資するインサイトが収集できたか
      （洞察ができたか、本質を見抜けたか）が重要

      • 仮説を検証可能なサンプル・データを収集する。
      • 簡易なモデルを用いて結果を見てみる。
      • 仮説のTrue / Falseが明らかになる。
      • 新たに発生した不確実性 / 問題点を整理
      • 上記の不確実性 / 問題点を解決できるか検討する（PoC2）。

    • PoC後に投資の意思決定をする。

    • 本開発・導入、運用

アジャイル

  • 試してみないと解らない（仮説検証の試行錯誤を含む）。
  • 適応型ライフサイクル（アジャイル手法、変化駆動型手法）が基本。

評価方法の決定

プロジェクト目標を明確化して共有する。

説明可能なAI

  • XAI（Explainable AI、説明可能なAI）

  • 例えば「人への高度な提案」のようなケースで要求される。

    • 疾患の発見
    • 与信審査
    • 新商品開発
    • 火災、犯罪、交通事故予測

  • 参考：AIのアルゴリズム・モデル

自社オペレーション

（✕：業務委託）

保守・運用（ポイント）

PDCA速度の向上

リリース後の改善する計画も必要

品質保証

  • 5つの軸とそのバランスで品質保証の活動を評価

    • Data Integrity

      • 質においても量においても適切かつ充分なデータの確保と、
      • 学習用データと検証用データが独立しているかどうかなどについて考慮

    • Model Robustness
      モデルの精度と頑健性、デグレードなどについて考慮

    • System Quality
      AI プロダクト全体の品質の確保について考慮

    • Process Agility
      プロセスの機動性について考慮する（アジャイル、MLOps的）。

    • Customer Expectation
      よい顧客との関係性について考慮

  • 検証技術のツール化（DeepSaucer）
    https://github.com/hitachi-rd-yokohama/deep_saucer

    • 形式手法活用網羅検証
      機械学習モデルを論理式にエンコードし、形式手法によって網羅検証
    • ニューロンカバレッジ
      与えられたテストケースの集合によりどのニューロンがテストされたかを可視化
    • リファレンスモデル照合テスト
      正解値のついていないテストケースに疑似的な正解値を付与しテスト自動実行
    • メタモルフィックテスト
      テストケースの入力値に微細な変更を加えても出力値が変わらないことを検査
    • 外れ値自動生成テスト
      人手では作成困難な外れ値・異常値を自動生成することでロバスト性を効率的に検査
    • 不確実性ベーステスト
      訓練データの不足などに起因する認識論的不確実性のロバスト性評価・改善

アンチパターン

組織と文化（アンチパターン）

  • 主な挑戦は技術ではなく文化

  • ビジネス上の価値を見誤る。

    • 技術はオープン化の流れ。
    • データに価値がある。

  • 実現可能性を見誤る。

    • 特定の手法に入れ込み過ぎない。
    • 高度な手法が良いとは限らない。

  • 時間軸を見誤る。

    • 試してみないと解らない
      （仮説検証の試行錯誤を含む）。

    • 見切りをつける。

      • データと精度
      • 可能性の検討

  • 少数のケースを超える戦略がない。

ポイント（アンチパターン）

事例

AI原料検査

  • ビジネス価値があり、経営層からの理解とバックアップがあった。

    • 自社の理念に結びついている
    • 現場が苦労し困っている
    • 業界に共通の課題

  • 立上げプロセスはテクニカル・フェロー自身が担当

    • アプリは自社、AIは協業（覚悟のある２社）、設備は中小企業。
    • 経営層、幹部には丁寧に解説・説明。
    • その他、公募制度などを作った。

  • 試作機は２ヶ月程度でできた。

    • （最初は）工場では全く見向きもされなかった
    • （最初の）テストで200以上の指摘事項を受け不合格
    • 一生懸命やっていると現場の人たちが助けてくれるようになった。
    • （良品の）撮影のフィジカル系（撮影環境）の模索
      （AIの活用例の該当節を参照）がポイントだった。

ゴミ識別AI搭載自動運転クレーン

画像処理とコンピュータビジョン（AI）の該当節も参照。

  • ビジネス価値があり、経営層からの理解とバックアップがあった。

  • 足りないAIスキルは外部ベンダーをパートナーに選定し適切に協業する。

  • AIベンダーは技術よりコンセプトを固める所のパフォーマンスを重視した。

  • オペレーターとディスカッションしシステムに反映して行くプロセスを繰り返した。

  • AI開発が必要な部分をできるだけコンパクトにしてスピーディーに開発した。

    • コンセプトで教師データを用意してトライ・アンド・エラー
    • AIの眼から判断した情報とクレーンを操作するロジックの結合部分を開発

参考

移行メモ

  • 組織の体制の「Spork（ビジネスユニット）」は、 Hub and Spoke 型の組織を指すと判断し「Spoke（ビジネスユニット）」に正した。
  • 「変化駆手法」は「変化駆動型手法」、 「教師データを用意してしてトライ」は「用意してトライ」、 「公募精度」は「公募制度」、 「テスト与えられたテストケースの集合により」は 「与えられたテストケースの集合により」に正した。
  • 混同行列の表および「（✕：業務委託」「（DeepSaucer」などで 閉じ括弧が欠けていた箇所を補い、 「画像認識で言うと撮影方法等）」の余分な閉じ括弧を除いた。

Tags: 移行, 人工知能, プロジェクトマネジメント, PoC, MLOps, 品質保証, XAI

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally