- どの程度まで間違ってよいかだけではない。 - どういう間違い方なら許容できるか。こちらの方が重要になる。
- どの程度まで間違ってよいかだけではない。 - どういう間違い方なら許容できるか。こちらの方が重要になる。
THE KNOWLEDGE LIBRARY
いまの仕事と、
つながる知恵。
ちゃんとした検索語がなくても、大丈夫。
場面や、得たいものからたどってみてください。
26 件の知恵
前半は、資料に用意する 項目と、その項目を書くための解説 です。後半に、架空の「問い合わせ対応支援AI」を用いた記載例をまとめています。
前半は、資料に用意する 項目と、その項目を書くための解説 です。後半に、架空の「問い合わせ対応支援AI」を用いた記載例をまとめています。
AI案件の進め方は、仕事・組織・AIの3変数のどこが未知かを見極めて決める
案件ごとに業務ヒアリングから始めたり、評価設計から始めたり、とりあえずプロトタイプを作ったりする。
提案に納得されたのに決まらない商談は、信用不足ではなく顧客の発注力の欠けを見る
新しい市場で営業をしていると、課題感はあるのに発注されないという状況によく出会います。
「良いとも悪いとも言えない」でPoCを止めない、評価設計書と進行フォーマット
生成AIやLLMを業務へ導入するとき、評価の失敗は「数字を間違えること」だけではない。
精度は測れたのに導入を判断できない。KPIより先に「誤評価の起き方」を並べる
精度は測れたのに導入を判断できない。KPIより先に「誤評価の起き方」を並べる
「次に何をすべきか」で詰まったら、目指す状態が成立しない理由を探す
状態設計というと、業務フローをきれいに書いたり、As-Is / To-Beを整理したりするための設計手法にも見える。
精度より先に「完成した翌日、誰が何に使うか」を決めてから作る
DXEの仕事は、AIを導入することでも、業務を自動化することでも、依頼されたシステムを正確につくることでもない。
「技術的にできそう」が出た時に、問題設定へ戻すための問い
内容としては、顧客から2D図面を受け取り、人間が3Dモデリングを行い、最終的に検図担当者がチェックする、という業務だった。
精度◯%の報告をやめ、失敗原因と次に必要な材料を書く評価レポート
生成AIプロジェクトでは、「評価」という行為が誤解されていることが多いです。
プロンプト修正に逃げず、AIの精度不良を「目的／役割分担／フロー／アルゴリズム／仕様」のどの層のズレかで切り分ける
しかし実際には、PoC止まり、現場定着せず、使われないシステムになるケースが非常に多い。
「見逃しを許容できるか」を先に決めないと、AIの評価指標も業務設計もぶれる
生成AIや機械学習を使ったDXプロジェクトで、最初に決めるべきことがあります。
エラーは出ないのに期待とズレるAI。評価を最終テストではなく能力設計として扱う
生成AIや大規模言語モデル（LLM）を使った実装が広がる中で、「評価」という行為の位置づけが誤解されていることが多いと感じています。
AIの出力に丸バツをつける前に、評価設計から原因分析まで通す進め方
Takeshi Senko お疲れ様です。 新條隼人 お願いします。 なんかあれでした。ごめんなさい。私の方で議事録が地味にのやつがあのメールに来ないなと思ったら線香さんのメールだったんですけど、主催者 なんか変えられるはずなんですけど、ちょっとイマイチ うまくいかなかったんですいません。カレンダーごと変えちゃいました。 はい、あの一応甘いアドレスとプラナーアドレス両方 招待してるんですけど、あの
問い合わせAIが事故るのは精度不足ではなく、「答えない」分岐を設計していないから
近年、生成AI（LLM）を活用したオペレーションDXは、カスタマーサポートを中心に急速に広がっている。
AIのQAは設計と切り離せる。だから少人数でも第三者として産業になる
AIが働く世界において、どの仕事が“切り出せて”、どの仕事が“産業として成立するのか”。
AIに答えさせる前に、情報が足りているかで処理を分ける
ネットプロテクションズ社（以下 NP社）が atone カスタマーセンターにおいて導入・実装を進めていた LLM（生成AI）活用システムに対し、 Pronoun社が第三者視点からレビュー・設計提案・改善助言を行う PoC 支援案件である。
AIを入れる前に状態・遷移・観測を固める順序で、ツールを選び分ける
AIX（AI Transformation）という言葉は、日本でも世界でも急速に広まりつつある。しかし現実の現場では、
AI評価市場の支配は「買えない壁」の突破から始まり、コスト優位が効くのは最後
- しっかりやってくれるし費用が十分な範囲であれば切り替える必要がない類
エンプラ案件の序盤、質問への回答を要求定義の材料に変える3つの整理軸
エンタープライズ系のBtoBプロジェクトでは、要求定義や要件定義が複雑かつ多岐に渡るため、プロジェクト最初の段階での「情報収集」が今後の成否を大きく左右します。特に「相手（クライアントやユーザー側）からの質問への回答」は単なる応答ではなく、後に「要求定義書」や「要件定義書」の中核となる情報群へと昇華されることを想定して臨む必要があります。
LLMが返す点数は定量値ではなく定性評価。そのまま使わず、再試行と評価軸の複数化で誤差を抑える
- dx界隈としてもaiがつけた絶対値をパラメータチューニングなくそのまま使う（KADOKAWAの初期でやっていたスコアリングやスイス式などの形式がそれにあたる）のは、ほぼ御法度として扱っている動きが国内でも既に多いと思います！ - あくまでも特徴量評価と分類タスク以外は実務上はさせないのが基本かと思います！
「精度の迷子」を防ぐ、問題設定→成果指標の公式→評価設計という要件定義の順序
- AIを用いた生成モデルの技術開発段階では、最終的な中長期的な品質や安定性よりも、新しいアイデアの探索やモデルの方向性の試行錯誤に重点を置くべきです。 - 生成AIの実装自体は比較的安価かつ素早く行えるため、頻繁にスクラップし再構築する開発サイクルが可能です。 - ただし、改善過程で「どの改善がどの性能向上に寄与しているか」が不明瞭になる「精度の迷子」の発生を避けることが重要です。 - 十分な探
LLM特化人材の前に、ML能力が本当に要る3論点で投資先を切り分ける
- 突き詰め、特定のドメインにおいてAIありきの本当に価値のあるサービスを構築できる権利は限られたプレイヤーにしかない。 - 既存のプレイヤーが侵食されるという論理と、持たざるものがBIGプレイヤーになれるという論理は全く接続性がない。 - 事実、時価総額100億円程度の期待を超えている新興スタートアップは、ドメイン知識や組織を作る力があるプレイヤーのみ。
- このページを読んでも日常的ななPdMのお仕事のHowはあまり書いていません。 - 本質的に重要なPdMが担うべき役割を言語化したものです。
- このページを読んでも日常的ななPdMのお仕事のHowはあまり書いていません。 - 本質的に重要なPdMが担うべき役割を言語化したものです。