# Midwest AI Summit 特別編：信頼できるAIワークフロー、現場と作るAI、チームに合ったAI自律度

- 番組: [Practical AI](https://ai-curator.jp/podcasts/shows/cmv3z5bzb00025o10lc2t7m3d)（Daniel Whitenack and Chris Benson）
- 元のタイトル: Abundant Intelligence at the Midwest AI Summit
- 配信日: 2026年10月29日
- 長さ: 54分
- 要約作成日: 2026年10月29日
- トピック: [#AIエージェント](https://ai-curator.jp/topics/AI%E3%82%A8%E3%83%BC%E3%82%B8%E3%82%A7%E3%83%B3%E3%83%88) [#評価(Evals)](https://ai-curator.jp/topics/%E8%A9%95%E4%BE%A1(Evals)) [#ガードレール](https://ai-curator.jp/topics/%E3%82%AC%E3%83%BC%E3%83%89%E3%83%AC%E3%83%BC%E3%83%AB) [#LLM](https://ai-curator.jp/topics/LLM) [#AI駆動開発](https://ai-curator.jp/topics/AI%E9%A7%86%E5%8B%95%E9%96%8B%E7%99%BA) [#データフライホイール](https://ai-curator.jp/topics/%E3%83%87%E3%83%BC%E3%82%BF%E3%83%95%E3%83%A9%E3%82%A4%E3%83%9B%E3%82%A4%E3%83%BC%E3%83%AB)
- URL: https://ai-curator.jp/podcasts/cmvtbw1ec00006y112ak25isy

## 要約

Midwest AI Summit の3講演のハイライト回。Heidi Porter は、評価・ガードレール・復旧を備えた信頼性の高いAI拡張ワークフローを、製造・農業・医療の実例で解説した。Kevin Solorio は現場作業員と一緒にAIエージェントを作り、評価データのフライホイールで信頼を築く方法を語った。SEP の Chris Shinkle と Andrew Dunlap は、6つの制約から自チームに合う自律度のモードを選ぶ考え方と5原則を紹介した。

## ポイント

- Heidi Porter は、ワークフローが失敗するのはモデルのせいではなくLLMに仕事を任せすぎるからだと述べ、タスクごとに最適な仕組み（ルール、従来型ML、決定モデル、LLM）を選ぶことを勧めた。
- プロンプト内のルールは決定論的に強制されないため、ゲート、チェック、人間の承認、コード上の制限といった本物のガードレールと、巻き戻しなどの復旧手段、平均に隠れない評価（eval）が必要だとした。
- ゴム製ホースの検査、Syngenta の CropWise AI、Stanford の手術共同管理ナビゲーターの例では、LLMは説明や基準適用に限られ、判断は人間が持ち、モデルや知識ベースは交換可能な部品として設計されていた。
- Kevin Solorio は、現場向けツールが使われないのは要件調査不足や他人のKPI向けの設計が原因だと指摘し、あえて間違ったたたき台を見せてフィードバックを得ること、評価なしのエージェントはPoCに過ぎないことを強調した。
- SEP は、トークン予算、組織の準備度、目標定義、ドメイン知識、検証可能性、コード監督の6つの制約が、個人利用から完全自律の「ダークファクトリー」までのどのモードが適するかを決めると説明した。
- 目標はダークファクトリーに到達することではなく「適合」であり、共有インフラ、意図的な反復、検証が先で速度は後、ボトルネックの継続的な解消、単純作業の排除という5原則はどのチームにも共通だと述べた。

## 章立て

- [00:00] **番組導入とサミット紹介** — 司会の Daniel Whitenack が Midwest AI Summit で登壇者のハイライトを紹介する回であることを説明し、3組の登壇者を紹介する。
- [01:48] **Heidi Porter：持続するAIワークフロー** — データ品質が信頼性の上限を決めること、仕組み・ガードレール・評価・可観測性という4つの要素、そして人間レビューの疲労や復旧の重要性を解説する。
- [09:04] **製造・農業・医療の事例** — ゴムホース生産ライン、Syngenta の CropWise AI、Stanford の手術共同管理ナビゲーターを例に、LLMの役割を限定し人間が判断を保つ設計と得られた教訓を紹介する。
- [18:59] **Kevin Solorio：現場と一緒にAIを作る** — ブルーカラー作業員向けエージェント開発の経験から、「のための」ではなく「と一緒に」作る意義、評価の重要性、データフライホイール、IKEA効果による支持者づくりを語る。
- [36:56] **SEP：AI自律度の制約とモード** — ダークファクトリーへの期待に対し、6つの制約で3チームの事例を分析し、個人から共有、さらにチーム全体の自律モードまでの適合を説明する。
- [50:00] **自律度を選ぶ5つの原則** — リーンやトヨタのアンドンの例を引き、原則は共通で実践は制約により異なると述べ、共有インフラ、意図的反復など5原則を示して番組を締める。

## 解説記事

Midwest AI Summit で行われた3つの講演のハイライトを、司会を務めた Daniel Whitenack がまとめて紹介した回である。Heidi Porter（Moyer Group AI）は信頼できるAI拡張ワークフローの作り方、Kevin Solorio（Focused）は現場作業員と共に作るAI、Chris Shinkle と Andrew Dunlap（SEP）はソフトウェアチームに適したAI自律度について語った。共通するのは、AIを導入する際は「何を任せ、どう検証し、誰が責任を持つか」を設計すべきだという視点だ。

#### LLMに任せすぎない：Heidi Porter のワークフロー設計

Porter は、AIパイロットが本番に進めない原因は、モデルの性能ではなくLLMに過大な役割を与えることにあると述べた。LLMはデータベースの代わりにはならず、判断と自己検証まで任せるべきでもない。そこで彼女は、タスクごとに「何が実行するか（ルール、従来型ML、決定モデル、LLM）」「どう調整するか」「何を実行してよいか」の3つを決めることを勧めた。

安全策としてはガードレール、評価（eval）、可観測性を挙げた。特に、プロンプトに書いたルールは強制されないため、ゲートやコード上の制限、人間の承認といった実体のある仕組みが必要だという。人間のレビューにも限界があり、大量の確認で「ゴム印」状態になる疲労に注意すべきだとした。さらに、いつか誤りは通り抜けるので、ロールバックなどの復旧手段を用意し、評価では平均値に隠れる悪い結果の程度を把握するよう促した。

#### 3つの事例が示す「LLMは説明役」

Porter は査読済み研究や公開事例から3つを紹介した。ゴムホースの生産ラインでは、欠陥検出は視覚モデルが担い、LLMはナレッジグラフから取得した根拠をもとに原因と対処案を下書きするだけだ。ルールベースの検査が根拠の範囲内かを確認し、根拠が薄ければ人に回す。この仕組みは52週間監視された。

Syngenta の CropWise AI では、ユーザー認証はアプリケーションコードで行い、予測は既存の農学モデルが出す。LLMはインターフェース、ルーター、説明役であり、判断は営業担当者や生産者が行う。100組の実際の質問と回答で評価し、モデルや知識ベースを差し替えやすいことが利点とされた。

Stanford の手術共同管理ナビゲーターは、機関が定めた基準をプロンプトに固定し、LLMは「はい・たぶん・いいえ」で答えるだけだ。5つのモデルを比較して O3 Mini を選び、過剰に該当と判定する傾向が設計上あり、医師は「いいえ」の判断に97%同意したという。不一致の理由を調べると、LLM以外のプロセスの問題も見つかった。

#### 現場と一緒に作る：Kevin Solorio

Solorio は、動作が不安定、仕事の助けにならない、手間が多いといった理由で現場に使われないツールは、他人のKPIのために作られがちだと指摘した。プロダクトオーナーなど仲介者を通すと情報が単純化され、「自分のほうが仕事を知っている」というメッセージにもなりかねない。

彼のチームは、肉挽き機からATMまで修理する技術者を相手に、まず合成データで間違いを含むたたき台を見せ、現場の指摘を得る方法を採った。「エージェントは評価がなければPoCにすぎない」と述べ、評価用の小さく精選したデータセットを育てるデータフライホイールを紹介した。オフラインの評価データで開発し、本番ではコードベースやLLM-as-judgeで抽出したケースをレビューして、評価データに戻す循環である。参加した人が自作の家具に価値を感じる「IKEA効果」で支持者になる、とも語った。

#### どこまでAIに任せるか：SEP の制約とモード

SEP の2人は、「ダークファクトリー」（人間が関与せずエージェントがすべてを行う開発）を求められる状況に疑問を呈した。複数の調査から、AIはチームの既存の特性を増幅するだけだという見方を示した。

適合を決めるのは、トークン予算、組織の準備度、目標定義、ドメイン知識、検証可能性、コード監督の6つの制約だ。2日で作ったプロトタイプは、本番化で予算の不足、暗黙知、数百万の入力の検証困難に直面した。建築部品の設計ソフトのチームは検証性を重視し、共有の知識を整えた段階で止めた。一方、フォーラム（地元の信用組合）のモバイルバンキングアプリのチームは、予算の制約がなくエージェントのワークフローを導入し、工数が6分の1になったと述べた。

実践は制約で変わるが原則は共通だとして、5原則を挙げた。共有インフラ、意図的な反復、速度の前に検証、ボトルネックの継続的な解消、単純作業の排除である。

#### まとめ

3講演に共通するのは、AIの能力を信じる前に、役割の限定、検証、人間の判断の位置づけを設計するという姿勢だ。日本の開発・事業の現場でも、導入の目標は「もっとAIを使う」ことではなく自分たちに合った適合を見つけることにあり、評価データの整備と現場の巻き込みが成否を分けるという示唆が得られる。

> この要約・解説記事は、元の音声の文字起こしをもとに AI（Claude）が日本語で作成したものです。出典: Practical AI「Abundant Intelligence at the Midwest AI Summit」