AIプロダクトの改善ループを設計する — ループエンジニアリング入門

こんにちは、カイです。

プロダクト改善にAIをどう組み込むかを、AimanaVo（エーアイマナボ）で連載しています。

ChatGPTやClaudeに一度プロンプトを投げて、その場では満足。

でも翌週、同じ課題で最初からプロンプトを書き直している。

そんな経験はないでしょうか。

個別のプロンプトを磨くだけでは届かない場面が増えていて、これからは「実行→評価→修正→再実行」の流れをシステムとして設計する話に重心が移っています。

ループエンジニアリングという言葉を、エンジニアリングの話としてではなくプロダクト改善の文脈で読み直してみます。

ループエンジニアリングがプロダクト改善の話になる理由

ループエンジニアリングは、Addy Osmaniさんがコーディングエージェントの設計手法として整理した概念です。

自分でプロンプトを書き続ける代わりに、それを行うシステムを設計する。

そちらに重心を移すのが要点です。

なぜこれがプロダクトの話に直結するのか。

AIプロダクトの価値は、もう最初の出力の質だけでは決まらないからです。

CSが受けた問い合わせをAIが分類し、開発が次のスプリントに織り込む。

マーケが施策を実行し、結果がAIに戻って次の打ち手が出る。

プロダクト側で起きていることは、すべて実行から次の判断へのループです。

ループの巧拙が、プロダクトの改善速度をそのまま決める段階に入ってきました。

ではそのループ、プロダクト側で何を設計すべきか。

6つの要素から整理します。

Loop Engineering

You don't really need to be good at prompting anymore. The thing to get good at is the loop that does the prompting for you. It's five building blocks plus s...

addyosmani.com

プロダクト改善ループを構成する6つの要素

この概念をプロダクト改善に持ち込む形で、私なりに6つの要素に整理してみます。

ゴール定義、入力コンテキスト、実行環境、評価基準、フィードバック設計、停止条件と人間承認。

実行環境と入力コンテキスト（どのモデルを使うか、何を渡すか）は技術側で詰める領域です。

プロダクト側で握るのは残り4つです。

ゴール定義 — 「何が改善か」を先に決める

ループを回す前に「何をもって改善とするか」を言語化します。

当然のようでいて、これを飛ばすチームは多いんですよ。

「とりあえずAIで自動化してみよう」で始めて、3ヶ月後に「で、これって何が良くなったんだっけ」になる。

「問い合わせ一次対応の自動化率を50%まで上げる」くらい具体的にする。

評価基準 — KPIをループの合否判定に翻訳する

評価基準は、KPIをループが自動判定できる形に書き直す作業です。

「CS満足度を上げる」では機械が回せないので、「解決率80%以上、一次回答までの時間60秒以内」のように合否判定できる粒度に落とす。

ここがKPIとループの接続点で、プロダクトの数字を握る人の仕事です。

フィードバック設計 — 結果がループに戻る経路を整える

実行結果がどう次のループに戻るか、経路を設計します。

これがフィードバックループの起点になります。

ユーザーのフィードバック、運用ログ、CSが追記したコメント。

これらをループに戻す仕組みがないと、何度回しても出力は変わりません。

ダッシュボードはあるけれど結果が次回入力に流れていない、という状態が意外と多いんです。

停止条件と人間承認 — ループを止める閾値を定義する

ループが暴走しないように、どこで止めるかを閾値として先に定義します。

コスト上限、評価スコアの下限値、エラー率の上限、ユーザー影響の大きさ。

これらを「止める条件」として書き出しておく。

閾値が先にあるから、承認フローを設計できます。

止める条件を定義せずに走らせると、いつ止めるかをその都度判断することになります。

この4要素を基盤にして、設計時に特に意識したい観点が3つあります。

ループ設計でプロダクト責任者が握る3つの観点

KPIとループを接続する — 「回した数」ではなく「動いた指標」

ループが回ったかどうかではなく、どのKPIが動いたかを見ます。

「今月ループを200回回した」は実績ではなく、「ループを200回回して解決率が72%から81%に上がった」が実績になります。

ステークホルダーに動いた指標で報告できる設計にしておきたいですね。

承認ゲートを設計する — 誰がどのタイミングで判断するか

ループを止める閾値を決めたら、次は誰がどのタイミングで判断するかを設計します。

スプリントレビューやステークホルダー承認に慣れているなら、その経験はそのまま使えます。

ループの承認ゲートは、本質的に同じ構造だからです。

「ユーザー体験に直接出る変更はプロダクト責任者がリリース前に承認」「コスト上限に触れたら翌朝の定例でレビュー」のように、誰がいつ判断するかを設計図に書き込む。

これをやっておくと、運用が止まる事故が格段に減ります。

ロードマップに「ループ改善スプリント」を組み込む

ループは作って終わりではありません。

評価基準も承認ゲートも、運用しながら更新が必要になります。

四半期に1回でも、ループ自体を再設計するスプリントをロードマップに組み込む。

見直し時に確認するのは3点です。

KPI閾値が現状の運用実態と合っているか、承認待ちが詰まっていないか（承認ゲートが厳しすぎるサイン）、停止条件が過剰に働いていないか（逆に緩すぎて素通りしていないか）。

これがないとループは静かに陳腐化していきます。

3つの観点が実際の設計でどう機能するか、具体例で確認してみます。

表に起こしてみると、抜けている要素が明確になります。

プロダクトに実装する改善ループの設計例

CSフィードバックを起点にしたループを設計すると、こんな形になります。

ポイントはステップ4です。

AIが優先度を出したとしても、最終確定は人間が行う設計にする。

ここを抜くと、AIの誤判定がそのままロードマップを汚します。

ループは自動で回るほど良く見えますが、回り続けるためには「止める設計」が要るんですよね。

こうした設計を1度組み立てると、プロダクトに関わる仕事の重心は自然と変わってきます。

ループを設計することがプロダクトを育てることになる

AIが業務に入ってくると、プロダクトに関わる仕事の重心は明らかに動きます。

プロンプトを書くから、ループを設計するへ。

プロンプトはその場で消費されますが、ループは資産として残る。

1度設計したループは、評価基準と承認ゲートを更新するだけで何ヶ月も走り続けます。

自分の判断をループに織り込んでおくことが、これからのプロダクト改善のレバレッジになっていきます。

明日からできる第1歩は、いま動いているAI業務を1つ取り上げて、6要素のうち何が決まっていないかを書き出すこと。

たぶん「評価基準」と「停止条件」が空欄のはずです。

そこを埋めるところから、ループ設計は始まります。