自己改善する App: 改善のクローズドループ

1. なぜ App に改善のクローズドループが必要か

どんな LLM‑App も変化する世界で生きています。新しいユーザーやユースケースが現れ、OpenAI は新しいモデルや防御メカニズムをリリースし、自分たちでも MCP サーバー、Agents SDK、UI ウィジェットを更新します。仮にコードが完璧に書かれていたとしても（そう、あなたはほぼそうしているのは知っています）、モデルやプロンプトをひとつ変えるだけで、気づかないうちにケースの半分が壊れることもあります。

ループがないと現実は次のようになります。ユーザーがサポートに書き込む：「GiftGenius が予算を超えるギフトを提案し始めた」あるいは「15秒も考え込んでいる」。あなたはログを開き、system‑prompt を何か直し、モデルを切り替えて、リリース。1 週間後、同じことが別の場所で再発。結果として、慢性的な火消しと、誰にも説明できない「魔法のような」変更の山が残ります。

ループがあると様子は一変します。あなたには次が揃います:

• 技術・お金・プロダクト・品質に関する分かりやすいシグナルのセット;
• それらを定期的に見て仮説を選ぶリチュアル;
• code/config のコントロールされた変更;
• 自動チェック: ゴールデンケース + LLM‑evals + 実験。

すると App は「固定化したプロンプト」から、次のような生きたシステムに変わります:

• どこが痛いのか、なぜなのかを示す;
• 何をどう改善できるかを示唆する;
• 「無邪気な」プロンプト変更後の静かな劣化から守る。

おまけに、こうしたループはこれまでのモジュールでやってきたことに非常によく乗ります。M17 のログと SLO は技術的シグナルを、M19 のコスト計測と AARRR は経済的・プロダクトのシグナルを、M20.1–2 のゴールデンケースと LLM‑evals は品質シグナルを与えます。あとはこれらを分かりやすい運用サイクルに結びつけるだけです。

2. 改善のためのシグナルマップ

App 自身が「どこを改善すべきか」を示せるようにするには、どんなシグナルがあるのかとその出どころを明確にする必要があります。4 つのグループで考えるのが便利です。

技術的シグナルは、あなたの observability スタックから来ます: ログ tool_invocation、latency と error‑rate のメトリクス、MCP/ACP のヘルスチェック、OAuth の失敗など。これらは「サービスは生きているか、どの程度安定しているか」に答えます。

経済的シグナルは、コスト計測と課金から生まれます: cost_per_tool_call、cost_per_task、cost_per_user、特定のツールやシナリオでの予想外のコスト急騰など。「トークンとお金を想定以上に燃やしている」あるいは逆に「余裕があるので品質を上げられる」と教えてくれます。

プロダクトのシグナルは、app_opened、workflow_started、workflow_completed、checkout_* といったイベントから形成されます。activation‑rate、ファネル各ステップのコンバージョン、コホート別リテンションなど。実ユーザー行動で何が起きているかを示します。

品質と振る舞いのシグナルには、ゴールデンケースに対する LLM‑evals の結果（correctness/helpfulness/style/safety のスコア）、ダイアログの抜き取り手動レビュー、thumbs up/down、Store の苦情やレビューが含まれます。これは「App がより賢く/愚かになった」という感覚に最も近いものです。

これを表にまとめると便利です:

重要なポイント: これらすべてのシグナルは、特定のシナリオと App バージョンにひも付けてログされます。つまりイベントには少なくとも scenario、appVersion、experimentId が含まれます。こうしておけば、ゴールデンケースに対する helpfulness が 8.5 から 6.2 に下がったときに、単に「悪化した」ではなく、「リリース "1.3.0" 後、シナリオ "gift_selection" の実験バリアント "B" で悪化した」と言えます。

コードでは、シグナル記述用のシンプルな構造を作っておくとよいでしょう:

// lib/improvement/signals.ts
export type SignalKind = "slo" | "cost" | "product" | "quality";

export type ImprovementSignal = {
  kind: SignalKind;
  scenario: string;       // e.g. "gift_selection"
  metric: string;         // e.g. "p95_latency_ms", "cost_per_task"
  value: number;
  previous?: number;      // 以前の値
};

このようなオブジェクトは、ダッシュボードにも、将来の改善アシスタントにも与えやすいです.

3. 標準的な feedback‑loop: 4 ステップ

ここからは、毎回拠り所にできる標準の改善サイクルを組み立てます。とても実務的で、4 つのステップです。

flowchart TD
  A[シグナル: 問題がある
または成長の機会がある] --> B[仮説:
何をどう変えるか]
  B --> C[code/config の
管理された変更]
  C --> D[検証:
offline + online]
  D --> A

ステップ1 問題または機会を見つける

このステップでは「どこを見るか」に答えます。例:

• 予算つきゴールデンケースの LLM‑eval で helpfulness の低下が示される。
• p95 latency（ツール "suggest_gifts"）が 1.2秒から 3.8秒に増加。
• シナリオ "gift_selection" の cost_per_task が reasoning モデルへの切り替え後に 40% 増加。
• workflow_completed から checkout_success へのコンバージョンが、UX ウィザード変更後に 5 ポイント低下。
• Store に 1 週間で「指定した上限より高いギフトばかり」という苦情が 10 件出た。

重要な注意点: シグナルは必ずしも「悪い」とは言いません。「もっと良くできる」こともあります。例えば、cost_per_task が許容しきい値より十分低く、quality‑score がすでに 9/10 なら、より高価なモデルや「賢い」シナリオを試してコンバージョンの伸びを狙えます。

ステップ2 仮説を立てる

仮説は「プロンプトを書き直す」ではありません。「コンポーネント Y に対する具体的な変更 X が、理由... によりメトリクス Z を改善するはず」という形です。「理由」がなければ、それは仮説ではなく願望です。

例:

• 「system‑prompt に厳格な予算遵守ルールを入れ、常に予算の使い方を説明させれば、予算ありケースの helpfulness は少なくとも 2 点上がる」。
• 「rerank のステップで高価なモデルを "gpt-mini" に置き換えれば、cost_per_task は 30% 下がり、コンバージョンは最大でも 1 ポイントしか落ちない」。
• 「ウィザードを簡素化（2 ステップを 1 つに統合）し、CTA を書き換えれば、activation‑rate は 5 ポイント上がる」。

コードでは、この仮説を少なくともオブジェクトとして明示するのが便利です:

// lib/improvement/hypothesis.ts
export type ImprovementHypothesis = {
  id: string;
  scenario: string;
  description: string;   // 「何を、なぜ変えるのか」
  targetMetric: string;  // 例: "quality.helpfulness" または "conversion.checkout"
  successCriteria: string;
};

はい、Jira のチケットに近いですが、型付きで表現されているだけマシです。

ステップ3 管理された変更を行う

ここで重要なのは 管理された と 分離された の 2 語です。

管理されたとは、変更が PR/commit として作られ、仮説にひも付き、changelog があり、可能ならフィーチャーフラグやバージョンを持つことです。単に「本番のプロンプトをちょっと直した」ではなく、どのリリースがそれを持ち込んだのかを言えるようにします。

分離されたとは、1 回のリリースで 3 つの異なる仮説を一度に混ぜないよう努めることです。もし同時に:

• モデルを変え、
• system‑prompt の半分を書き換え、
• さらに UX に新しいステップを追加したら、

たとえメトリクスが改善しても、何が効いたのか判別が難しくなります。小さな塊で動く方がずっと健全です。

技術的な変更はどこにでもあり得ます:

• エージェントの system‑prompt（lib/prompt/systemPrompt.ts）;
• MCP ツールの記述（description、inputSchema、annotations）;
• エージェントの設定（reasoning ステップの上限、特定のツールに使うモデルの選択）;
• ウィジェットのコード（CTA、ステップの順序、エラーテキスト）。

ステップ4 良くなったかを検証する

検証はオフラインとオンラインに分かれます。

オフライン検証は、実ユーザーなしで新バージョンの App に対してゴールデンケースを流すことです。すでに次があります:

• LLM‑evals（モジュール 20.1）;
• threshold/baseline ロジック（モジュール 20.2）。

対象シナリオの quality‑score がどう変化したかを見ます: 上がったか、下がったか、同じか。また safety ケースもチェックします。プロンプトの修正はまず safety セットを通過すべきです。

オンライン検証は実トラフィックでの実験です。最も簡単には、新バージョンをユーザーの N% に有効化し、次を比較します:

• ターゲット行動（checkout、シナリオ再実行）へのコンバージョン;
• cost_per_task;
• 苦情/フィードバック。

その後、サイクルはクローズ（仮説が確認/否定され、文書化）されるか、新しい仮説を生みます。

4. 内部の「改善アシスタント」を独立したエージェントとして

ここからが本題です。LLM モデルにもう 1 つの役割を与えましょう——ユーザー対応だけでなく、あなたが App を改善するのを助ける役割です。これはユーザー向けの GiftGenius とは別の内部エージェントです。

これは何者か

このアシスタントは内部環境（同じリポ、Dev Mode、別の ChatGPT App）に住みます。次を行います:

• ログとダイアログのサンプルを読む;
• メトリクスを見る;
• system‑prompt とツールの説明を確認する;
• 問題の定式化や変更提案を手助けする。

本質的には、あなたは「バーチャルなプロダクト/アナリスト」を得ます。これは:

• ダイアログを読んでも疲れず、
• 繰り返しのパターンを素早く見つけ、
• プロンプトや changelog の下書きを書けます。

入力は何か

入力を形式化するとアシスタントが楽になります。例えば型は次のとおり:

// lib/improvement/assistant.ts
export type BadDialogExample = {
  id: string;
  userMessages: string[];
  appMessages: string[];
  qualityScore?: number;
};

export type ImprovementInput = {
  scenario: string;
  signals: ImprovementSignal[];      // 前のセクションから
  examples: BadDialogExample[];
  systemPrompt: string;
  toolsDescription: string;
};

ログから「gift_selection」シナリオに関する不出来なダイアログを 10〜20 件取り出し、現在の system‑prompt とツール説明を添えて、このオブジェクトを作れます。

出力は何を想定するか

期待する返り値も固定しておくと便利です:

export type ImprovementSuggestion = {
  patterns: string[];     // 繰り返し出る問題
  promptPatches: string[]; // system-prompt 用の提案フラグメント
  toolsPatches: string[];  // tools 説明に関するアイデア
  uxCopyIdeas: string[];   // UX テキスト案
  changelog: string[];     // 変更点の短いリスト
};

このエージェント用のメタプロンプトはおおよそ次のとおりです:

• 「例とシグナルを分析する」;
• 「2〜3 個の問題パターンを述べる」;
• 「プロンプト、ツール説明、UX テキストにそれぞれ 1〜2 個の変更案を提案する」;
• 「厳密に決めた JSON で返す」。

その後は、人間がこれらの断片を取り上げ、チームで議論し、コードに組み込み、eval と実験にかけます。重要な原則: このアシスタントは本番で何も自動変更しません。生成するのはアイデアとテキストであり、コミットではありません。

5. 変更の種類: 何を「チューニング」できるか

アシスタントと分かりやすいループができると、「system‑prompt の新バージョンをちょうだい」に集約しがちです。実際には改善の領域はもっと広いです。

プロンプトと指示

System‑prompt は役割、トーン、優先順位、厳格なルール（例えば予算、safety、手順）を定めます。次のように扱えます:

• 矛盾や重複指示を取り除いて簡素化する;
• 不足するルールを足して強化する（予算の例のように）;
• シナリオごとに最適化する（"gift_selection"、"post_purchase_help" など用のサブプロンプト）。

ツールの説明は、どのツールをいつ呼ぶべきか、何をするのかをモデルに理解させます。ここでの改善は多くの場合次のとおりです:

• より明確な「Use this when… / Do not use when…」;
• 表現の明確化（他のツールとの重複を減らす）;
• 結果に関する情報追加（destructiveHint、isConsequential）。

Safety ルールは、複雑な領域での振る舞いに関するプロンプト/説明の一部です。十分な safety‑eval の後に触れるのがよいでしょう。

振る舞いのアーキテクチャ（behavior）

問題はプロンプトでは解決できず、行動順序を変える必要があることもあります。

例:

• 高価なツール呼び出しの前に、パラメータ確認の必須ステップを追加する;
• 一部の計算を、より安い別ステップに出す（たとえばバックエンドでの事前フィルタリング）;
• 1 シナリオにおける連続ツール呼び出し数を制限する。

これらの変更は、プロンプトだけでなく、エージェントの設定や MCP 層に記述されるのが普通です。

UX とコピーライティング

ボタンやエラー文の文言も品質の一部です。たとえば GiftGenius が次のように書くと:

「エラー 500。管理者に連絡してください」,

受ける印象は次の文とまったく異なります:

「ショップからの応答を取得できませんでした。選んだアイデアは失われていません。少し時間をおいて購入手続きをお試しください。」.

途中画面、ヒント、ウィザード構成——これらすべてが、あなたが測定している activation‑rate やコンバージョンに影響します。

経済性

ここではおなじみの「品質 ↔ コスト」のゲームをします:

• モデルの選択（reasoning ありの高価、速く安い）;
• reasoning/エージェントステップの深さ（許す反復回数）;
• ダイアログの上限（たとえば 1 セッションでの再計算回数の上限）;
• トークン/制限の予算が尽きた場合の「安価な」フォールバック。

ここからのシグナルは cost_per_task、cost_per_user、マージンに反映され、quality‑score と組み合わせて見ます。

6. ガードレール: LLM に任せてはいけないこと

「改善アシスタント」と便利なループができると、「自動最適化」ボタンを押してコーヒーを飲みに行きたくなります。最初に、そのボタンが禁止される領域を決めましょう。

パーミッションの変更（OAuth スコープ、MCP ツール、データアクセス）は常に human‑in‑the‑loop の領域です。モデルが勝手に「App が注文を読み、決済に触れ、ユーザーにメールを送れる」と決めるべきではありません。同様に commerce フロー、すなわち ACP/Stripe、制限、支払いタイプ、返金に関する変更も人間のレビューとテストを通すべきです。

App の safety プロファイル（助言できるドメイン、拒否すべきドメイン）も LLM に委ねるべきではありません。モデルはルール文の作成を助けられますが、どのテーマを App に委ねるかの決定はあなたにあります。

データとログのポリシー（何をログするか、どのくらい保持するか、削除要求にどう対応するか）も同様です。LLM はプライバシーポリシーの構造を提示できますが、コードの保持期間をあなたの関与なしに変更すべきではありません。

何を半自動化できるでしょう？ プロンプトの表現や wording、ツール説明と UX テキスト、ツール優先度（常識的な範囲）、追加の確認質問などです。これらはアシスタントにアイデアソースとして任せられますが、最終判断と検証は人間と eval スクリプトです。

7. End‑to‑end の改善サイクル例（GiftGenius）

我らが主人公に戻りましょう。

問題

ユーザーが予算を指定しても、GiftGenius はその上限を超えるギフトを提案することが多い。ログには「高すぎる」「もっと安くして」といったダイアログの続きが多数見られる。

シグナル

まず品質が見えます: 「50$ までのギフトを選んで」のようなゴールデンケースに対する LLM‑eval は helpfulness が 6/10 前後。審査員は reason に「ギフトが予算を超えている」「予算の考慮が説明されていない」とよく書いています。

プロダクトと経済のシグナルも並行して入ってきます:

• 上限が設定されたシナリオでは、checkout_success へのコンバージョンが低い;
• 高すぎる候補を見た後にシナリオを離脱するユーザーが一定数いる;
• こうしたシナリオでは cost_per_task が高い。App が「もっと安くして」の要望で候補の再計算を複数回行うため。

改善アシスタントでの分析

価格に不満を述べたダイアログを 20 件集め、ImprovementInput を作成します:

• scenario = "gift_selection_with_budget";
• helpfulness とコンバージョンの低下という signals;
• ダイアログの examples;
• 現在の system‑prompt とツール説明。

これを内部の改善アシスタントに渡します。返ってくるのは例えば次のような内容です:

• パターン:
  • 「約 50$ まで」といった曖昧な予算表現が緩く解釈されている;
  • system‑prompt に「上限を超える提案は決してしない」という明確な要件がない;
  • 回答が予算をどう考慮したかを説明していない。
• 提案:
  • system‑prompt に厳格な上限遵守の指示を追加する;
  • 常に「すべての候補は ≤ X」と明言させる;
  • 予算が曖昧に聞こえる場合（「だいたい」「約」）は確認質問を入れる。

仮説と変更

仮説を定義します:

「上限の厳格遵守を明示し、予算の使い方を説明させれば、予算つきケースの helpfulness は最低でも 8/10 まで上がり、購入コンバージョンは 3 ポイント上がる」。

system‑prompt に次の断片を追加します:

export const budgetRule = `
ユーザーが予算を指定した場合（例: "50$ まで" または "約 30€"）、
その金額を厳格な上限として扱うこと。

この上限を超える候補を決して提案しない。
各回答で、すべての候補が予算内に収まっていることを
どのように収まっているかも含めて明示する（例: "すべてのギフトは 45$ 以下"）。
`.trim();

そして budgetRule を GiftGenius の全体 system‑prompt に組み込みます。

オフライン検証

「予算つきギフト」ゴールデンケースを新バージョンに対して流します:

• LLM‑eval の helpfulness は 6.0 から 8.5 に上昇;
• correctness も上がる: 予算が守られている;
• safety は（少なくとも）悪化しない。

逆に helpfulness が上がらない、または safety が悪化するなら、この変更は通さず仮説を見直します。

オンラインテスト

次に実験を開始します:

• 10% のユーザーに新しいプロンプト（variant B）を配信;
• 残りの 90% は旧バージョン（variant A）。

1 週間後に確認します:

• variant B の workflow_completed から checkout_success へのコンバージョンが A の 10% に対し 13% になった;
• cost_per_task はほぼ変わらない;
• 「高すぎる」という苦情の割合が下がった。

実験は成功と判断します。

定着

その後は:

• 新しいプロンプトをトラフィックの 100% に展開;
• 回帰用セットに新しいゴールデンケース「緩やかな 50$ までの予算」を追加;
• 結果を changelog と、できれば tech notes に記録: 半年後でも、プロンプトに予算について厳しい文言がある理由が分かるように。

サイクルはクローズ。次のイテレーションは、たとえば非常に珍しい趣味の人向けの推薦や、選定コストの最適化に取り組めます。

8. 自己改善する App のミニロードマップ

これが「さらに 100500 のタスク」に見えないように、App を自己改善型と言えるための最小限と、その後に追加できるものを示します。

バージョン 1.0: 最小の improvement‑loop

最初のステップでは 3 つで十分です。

第一に、構造化ログと基本的な SLO。あなたはすでに tool_invocation、workflow_completed、checkout_* を requestId、userId、scenario、appVersion、costEstimateUsd とともにログする方法を知っています。これを土台に SLO（latency、error‑rate、checkout 成功率）を構築します。

第二に、10〜20 件のゴールデンケースと LLM‑eval スクリプト。主要シナリオの小さくてもよく選ばれた例 + safety ケース。App と審査員を通して実行し、JSON スコアを出す 1 本の CLI スクリプト。

第三に、2 週間に 1 度の簡単なリチュアル。腰を据えて（1 人でもチームでも）、次を開きます:

• SLO、コスト、プロダクトメトリクスの 2〜3 つのダッシュボード;
• ゴールデンケースに対する LLM‑eval レポート;

そして次のサイクルに向けて1〜2 件の仮説を選びます。定義し、文書化し、小さなリリースを作り、検証します。

バージョン 2.0: 「スマート」improvement‑loop

次のレベルでは次が現れます:

内部の改善アシスタント。 これは独立したエージェント（または ChatGPT App）で、ImprovementInput を受け取り、ImprovementSuggestion を返します。手作業でダイアログを何時間も見て回る時間を節約します。

自動化レポート。 ログと eval をもとに次を生成できます:

• 問題ケースのクラスタ（例: 予算の言い換えが起きた全ケース）;
• プロンプトやツール説明の即利用可能な下書き;
• 短い changelog。

CI フック。 プロンプト、エージェント設定、ツール説明の変更は自動的に次を起動します:

• 機能的なゴールデンスイート;
• safety スイート。

safety ケースが落ちる、または主要シナリオの品質がしきい値を下回れば、ビルドは赤でリリースは無しです。

9. 実践

演習 1: 自分の App のミニ feedback‑loop

あなたのアプリの主要シナリオを 1 つ選びましょう。GiftGenius ではすでに「ギフトの選定と購入」を選びましたが、同様のシナリオや独自のものでも構いません。

自由形式で（あるいは小さな improvement-plan.md を作って）記述します:

追跡するシグナル。 各カテゴリから 1 つずつ:

• 技術: 例）主作業を行うツールの p95 latency;
• 経済: このシナリオの cost_per_task;
• プロダクト: workflow_started → workflow_completed あるいはターゲット行動までのコンバージョン;
• 品質: このシナリオに関する複数のゴールデンケースに対する平均 quality_score。

次に、劣化とみなすしきい値を明確に固定します。「そのうち見る」ではなく、具体的に:

• p95 > 5 秒 — 悪い;
• cost_per_task が売上増なしに 30% 超上昇 — アラート;
• quality_score が 7 未満 — 要調査。

そして最初の仮説を定義します。例えば:

「確認質問が多すぎるのではと疑っています。ウィザードを 1 ステップ短縮し、質問を少し一般化すれば、activation‑rate は上がり、helpfulness はほとんど損なわれないはずです。小さな UX 変更と A/B テストで検証します。」

これはもはや「UX を良くする」ではなく、サイクルにおける具体的な一歩です。

演習 2: 改善アシスタントのメタプロンプト

あなたの App 用の内部改善エージェントのプロンプト文を草案してみましょう。次のようにシンプルに始められます:

• 彼が誰かを記述: 「あなたは App N の品質アナリストで…」。
• 受け取る入力を列挙: ダイアログ、シグナル、system‑prompt、descriptions。
• タスクを定義:
  • 2〜3 個の問題パターンを見つける;
  • プロンプト、tools、UX テキストに各 1〜2 個の変更案を提案する;
  • 短い changelog を作る。
• 応答フォーマットを記述: patterns、suggestions、changelog フィールドを持つ構造化 JSON。

まだコードからこのエージェントを呼び出さなくても、この 1 本のプロンプトが、App をどう改善するかの思考をより構造化する手助けになります。

10. 改善サイクル構築時のよくある落とし穴

落とし穴 No.1: 単一メトリクスだけを最適化する。
ひとつに集中するのは魅力的です。コストだけを追い、OpenAI からの請求が下がることだけを喜んでいると、quality‑score、コンバージョン、リテンションの低下に気づかないかもしれません。逆に reasoning モデルで品質を 10/10 に仕上げ、各シナリオが 1 ドルかかることを忘れてしまうことも。改善ループはメトリクスのパッケージを見るべきです: 品質 ↔ お金 ↔ ユーザー行動。

落とし穴 No.2: 測定なしの「魔法の」プロンプト変更。
「system‑prompt を書き直した。これで良くなるはず」というフレーズは、ゴールデンケースと eval なしでは、数週間後のサプライズのもとです。プロンプトの変更——とくに本番では——は、明確なパイプライン（ケースセット、LLM‑eval の前後比較、必要ならオンライン実験）を通すべきです。そうでなければ、App を改善しているのではなく、品質をランダムに散らしているだけです。

落とし穴 No.3: LLM アシスタントの変更を自動デプロイする。
たとえ改善アシスタントが非常に美しいプロンプト断片や説得力あるツール説明を書いても、それをレビューなしに本番へプッシュする理由にはなりません。モデルは、ビジネス制約、安全リスク、あなたのメトリクスの文脈をすべて見通せません。彼の役割はコンサルタントであり、リリース権限を持つ DevOps ではありません。

落とし穴 No.4: 変更と仮説・シグナルの結び付けがない。
ときにチームは「感覚」で修正し、どのシグナルが変更に至らせ、どの仮説を検証しているかを記録しません。結果、1 か月後には、プロンプトの奇妙な段落がなぜ登場したのか、誰のためだったのか誰も覚えていません。品質に関する良い PR は最低でも 3 つの問いに答えるべきです。「何が痛かった？」「何を変える？」「どのメトリクスで良くなったと判断する？」

落とし穴 No.5: 改善の際に safety を忘れる。
有用性を追うあまり safety 制約を緩めたり、プロンプトから「不要な拒否」を外したり、safety ケースの実行を忘れたりしがちです。system‑prompt、ツール説明、エージェントの振る舞いに関するあらゆる変更は、まず safety‑eval セットを通すべきです。以前通っていたケースが 1 つでも落ちるなら、他のメトリクスがどれほど美しく見えても、それはストップシグナルです。

落とし穴 No.6: 「すべてを一度に最適化したい」欲望。
プロンプトの半分を書き直し、モデルを変え、さらに MCP ツールを 1 つ追加し、新しいウィザードも入れる——すべてを 1 リリースで。これは生産的に聞こえますが、どの変更が効果を出したかを完全に不明にします。改善サイクルは、反復的でフォーカスされているときにのみ効果的です: 1〜2 件の仮説、小さな変更セット、明確なロールバックプラン。

落とし穴 No.7: 改善ループをたまの「大掃除デー」にする。
半年に一度「品質の日」を盛大に開催し、それ以外の月は eval とメトリクス分析なしで過ごすと、App は大半の時間「流される」ことになります。もっと有益なのは小さくても定期的なリチュアルです。毎週/隔週でシグナルを見て仮説を更新し、小さな一歩を実行する。こうしてあなたの ChatGPT App は静的な存在から、本当に自己改善するものになります。