TL;DR
- 「綺麗じゃない」実践知が山盛り。課題定義・責任境界・計測を先に決めることが成否を分けると再確認。
- 生成 AI は“使いどころ”の設計が命。UX 起点で仮説 → プロトタイプ → 学習ループを高速に回す文化が要。
- モデル/外部 API への依存は前提。互換レイヤ・フェイルセーフ・コスト監視をプロダクション設計に埋め込む。
- 「学びの KPI」を置くと探索が楽になる。小さく泥臭く試し、ユーザー接点で早めに擦るのが結局近道。
参加イベント
2025 年 11 月 25 日（火）に Forkwell 社より主催された、『どろんこ AI 話〜綺麗じゃない AI の苦労話〜』を視聴しました。
どろんこAI話〜綺麗じゃないAIの苦労話〜 ー 現場で泥を被った6社が語る、リアルなAI開発の裏側 AI活用が当たり前になった今、成功事例やHow-to記事は溢れています。しかし、実際の開発現場では、データが汚い、精度が出ない、コストが膨らむ、ステークホルダーを説得できない…そ …
視聴した感想や、自身に置き換えて役に立てそうだと思ったことを書いていきたいと思います。
印象に残ったこと
まず、登壇全体を通じて強く感じたのは、AI プロジェクトほど「前提を揃えること」が効くという点でした。
解くべき課題を丁寧に言葉にし、PoC を卒業したと見なす基準を最初に置いておく。ここには精度やコストだけでなく、説明可能性、運用に必要な手間、組織としての責任の持ち方まで含めるべきだという示唆がありました。
意思決定の単位 『 誰が何をいつ承認するのか 』 を明文化しておくと、試行錯誤が迷走せず、泥臭い実験を健全な速度で続けられるのだと理解しました。
フロントエンドと生成 AI の接点についても多くの学びがありました。
LLM の応答は“そのまま見せるテキスト”ではなく、アプリケーションのいち機能として扱うべきです。
ストリーミング表示は待ち時間の心理的負担を軽くし、キャンセルや再実行は失敗を前提にした健全な操作感を生みます。
さらに、要約や根拠の提示を UI に組み込むことで、幻覚や遅延がユーザー体験を損なうリスクを和らげられると感じました。
技術選定の観点では、モデルや外部 API の進化速度に抗わない設計が重要だと再確認しました。
プロバイダ適配のレイヤを用意し、プロンプト資産はバージョンを明確に管理する。
コスト・品質・レイテンシの三点を儀式化してダッシュボードで見える化し、劣化や偏りを早期に捕捉できるようにしておく。
これらは “差し替えが常態” である時代の基本動作だと感じます。
また、「たくさん作って早く捨てる」プロトタイピングの姿勢には頷く点が多くありました。
評価すべきは 完成度ではなく、得られた学びの量 です。
小粒な実験を並走させ、レビューでは「何がわかったのか」「次に何を捨てるのか」を必ず言語化する。
このリズムが、未知に向き合うときの全体効率を引き上げるのだと思います。
運用の話も示唆に富んでいました。
まずはユーザー価値の有無を確かめ、価値が立ったあとに精度や効率を磨く。
入力・出力・評価を記録できる最小限のログ基盤を早めに用意しておくと、後からの検証が格段にやりやすくなるという指摘は、実務の手触りに直結します。
最後に、越境の重要性です。ドメイン知識、ML、SRE を跨いで対話できる人と場があると、転び方が浅くなります。あらかじめ責務の境界や SLI
Service Level Indicator。ユーザー価値に直結する“計測指標”。例: 成功率、p95 レイテンシ、データ鮮度。
/SLO
Service Level Objective。SLI に対する “目標値”。例: 28 日間で成功率 99.9% 以上。
、エスカレーションの経路を引いてから“泥”に入ると、後々の摩擦や手戻りが小さくなる ──
この実感は、多くの現場で共有できるはずです。
明日から試すこと（自分向け）
インフラ/SRE の相談で回答精度を上げるために “お題”の書き方を AWS/ECS 前提で標準化” することで、業務や個人学習での AI 活用が活性化するのではと考えました。
今後は以下のお題テンプレートとサマリーを参考に活用をしていきたいと思います。
お題テンプレートとサマリー
## 目的
インフラ/SRE の相談で回答精度を上げるために、“お題”の書き方を AWS/ECS 前提で標準化する。
## お題の作り方（1 行フォーマット）
- 形式: 行動/対象 + 症状/状態 + 範囲・制約
- 例: 「ECS サービスのスケールが失敗（ap-northeast-1、Fargate、最小 2 タスク）」
## 実践テンプレート（コピペ用）
お題: <一言で/例: ECS サービスのスケール失敗>
現状の連携:
- 環境/制約: <リージョン/バージョン/権限など>（例: ap-northeast-1, Fargate platform 1.4.0）
- 実行コマンド/操作: <具体的な 1〜2 行>
- エラーログ: <最大 3 行>
解決したいこと（ピンポイント）:
- <Yes/No または 選択式で 1〜3 問>
期待値（出力形式/粒度）:
- <手順を 3 ステップ/`aws` CLI とコンソールの両方/ロールバック 1 行 など>
除外してほしい範囲:
- <例: ベンダー比較、組織運用ポリシーの一般論 など>
完了定義:
- <どのコマンドが 0 exit なら完了か>
## サンプルお題（ECS/周辺）
- 「ECS サービスのデプロイが `SERVICE_STABILIZATION_TIMEOUT` で停止（ap-northeast-1、Fargate、最小 2 タスク）」
- 「ECS タスク起動が `RESOURCE:CPU` 不足で失敗（Capacity Provider: FARGATE_SPOT 併用）」
- 「ALB ターゲット登録後に 502/504 が散発（ターゲットは ECS、ヘルスチェックは `/healthz`）」
- 「ECR からの `ImagePull` が失敗（プライベートサブネット、NAT 有/無の切り分け）」
- 「CloudWatch Logs が出力されない（`awslogs` ドライバ設定済みのはず）」
## 使い方メモ
1. 上のテンプレートを貼り付けて空欄を埋める（固有名詞・バージョン・ログを最小限に）。
2. 期待値と完了定義を必ず書く（回答の粒度と着地点を固定）。
3. 作成した“お題”は Issue/日報/チャットに流用できるよう短文化する。
個人的には、「実験の速度 × 学びの質」を同時に守るための設計と文化に焦点が当たっていた点がとても印象的でした。
明確な成功基準を持ち、小さく速く学ぶ。
そのうえで、差し替え前提の実装と、ユーザー体験での緩和策を丁寧に積み上げていく。
業務においては、この順番を意識して臨もうと思います。