--- title: "プロンプトを磨いても安定しないので、ループで回すことにした" description: "プロンプトの工夫だけでは出力がブレ続ける問題に対して、生成、評価、フィードバック、再生成のループで対処する考え方を整理しました。手動で始める最小ステップも書いています。" lang: "ja" canonical: "https://llm-lab.dev/posts/llm-loop-engineering-first-step/" source: "https://llm-lab.dev/posts/llm-loop-engineering-first-step.md" publishedAt: "2026-06-03" updatedAt: "2026-06-03" category: "設計" tags: - "agentops" - "eval" - "agent" - "loop-engineering" --- # プロンプトを磨いても安定しないので、ループで回すことにした import LinkCard from "../../components/LinkCard.astro"; > [!NOTE] > この記事で確認したこと > > プロンプトを詳しくするだけでは、繰り返し発生するAIタスクの品質は安定しにくいです。まず手動で生成、評価、フィードバック、再生成の小さなループを回し、3〜5個の具体的な評価基準で未達項目だけを返すと、どこで出力が崩れているかを見つけやすくなります。 > > 最初からAPI化やエージェント基盤を作るより、手元で2〜3回だけ回して「そのタスクはループに向くのか」「評価基準は判定できる粒度か」を確認するほうが、後の自動化で無駄なコストを増やしにくいです。 正直、プロンプトの工夫にどれだけ時間を使っても、出力が安定しないことに疲れていました。 より詳しく書く、例を増やす、役割を与える、出力形式を指定する。どれも効果はあります。ただ、一定以上の品質を安定して出そうとすると、プロンプト改善だけではすぐに壁にぶつかります。 個人的に違和感を覚えたのは、自分が「一回の指示で完璧な答えを出させよう」としている点でした。冷静に考えると、人間同士の仕事でも一発で完成品が出ることはほとんどありません。レビューして、直して、また確認する。それと同じことをAIとの間でもやればいいのでは、という発想がループ設計の出発点です。 ![一発指示 vs ループ設計の比較](/images/posts/llm-loop-engineering-first-step/one_shot_vs_loop_comparison.svg) ## ループとは何か ここで効いてくるのが、実行、評価、修正、再実行のループです。 ```text AIを実行する ↓ ルーブリックで評価する ↓ 何が足りないかを具体的にフィードバックする ↓ 再実行する ↓ 条件を満たすまで繰り返す ``` ![ループ設計の全体フロー](/images/posts/llm-loop-engineering-first-step/loop_flow_diagram.svg) AIに「もっと賢く答えて」と頼むのではなく、賢く振る舞いやすい環境を設計する。この発想を、ここではループ設計と呼んでいます。 言い換えると、AIの出力品質をプロンプトの巧みさに賭けるのではなく、評価と修正の仕組みで底上げする考え方です。 ## 誰がループを回すか 最初は人間が手動で回せば十分です。 AIの出力を見て、「ここが足りない」と伝え、再実行させる。正直、それだけでも出力はかなり変わります。自分の場合、ブログの下書きをClaude Codeに書かせて、読み返して「結論が冒頭にない」「具体例がゼロ」とフィードバックを返すだけで、2回目の出力がかなりマシになりました。 慣れてきたら、AI自身に自律的にループさせることもできます。たとえばClaude Codeのような環境では、「この条件を満たすまで確認と修正を繰り返して」といった指示で、ある程度まで自動化できます。 本格的に安定させるなら、APIを呼び出すコードを書き、評価関数に通し、条件を満たすまで再実行する形になります。 ただし、最初からそこまで作る必要はありません。まずは手動で2〜3回回して、どの評価基準が効くのかを見るほうが早いです。個人的には、最初からAPIで自動化しようとして評価基準の設計が雑になり、ループ自体の良し悪しが分からなくなった経験があるので、手動から入ることを推奨します。 ## ルーブリックが品質を決める ループの効果は、評価基準の質でほぼ決まります。 ここが荒削りだと、ループを回しても出力が良くなったのかどうか判断できません。曖昧な基準をAIに渡しても、AIは判定しようがないからです。 たとえば「読みやすい文章」という基準は、評価しづらいです。何をもって読みやすいとするのかが人によって違うため、AIが採点しても結果がブレます。 一方で、次のような条件なら評価しやすくなります。 - 一文が60字以内 - 専門用語には初出時に短い説明がある - 結論が冒頭3段落以内にある - 次に取る行動が最後に書かれている ![ルーブリックの良し悪し比較](/images/posts/llm-loop-engineering-first-step/rubric_good_vs_bad.svg) 良いルーブリックは、最初から完成させるものではありません。 「良い出力とは何か」を3〜5項目で書き出し、AIに叩き台を作らせます。実際の出力に当てて、曖昧な項目を削ります。これを繰り返すと、評価基準そのものが育っていきます。個人的には、最初に作ったルーブリックの半分くらいは、実際の出力を見た後に「これでは判定できないな」と気づいて書き直しています。 ## 評価は独立した文脈でやる ループ設計でよくある落とし穴は、生成したAIにそのまま自己採点させることです。 自分が作ったものを自分で採点すると、どうしても甘くなります。AIでも同じことが起きます。生成した直後のコンテキストで「これは合格ですか？」と聞くと、自分の出力を肯定する方向にバイアスがかかりやすいです。 評価は、生成とは別の文脈で行うほうが信頼できます。 実装上は、生成用の呼び出しと評価用の呼び出しを分けます。評価側には、元の指示、生成結果、ルーブリックだけを渡し、「合格か、不合格ならどの項目が未達か」を返させます。 同じモデルを使っていても、文脈を分けるだけで評価の意味が変わります。ぼやかせてもらうと、この「文脈の分離」に最初は懐疑的でしたが、実際にやってみると自己採点との差がはっきり出ました。 ## 「やり直して」は指示ではない フィードバックの渡し方も重要です。 「前回の出力は不合格です。もう一度やり直してください」は、指示としてほとんど機能しません。AIは、どこを直せばいいのか分からないからです。 正直、自分も最初はこの罠にハマっていました。「もっと良くして」「もう少し具体的に」といった曖昧なフィードバックを渡して、出力がほとんど変わらず困るという経験を何度もしています。 代わりに渡すべきなのは、具体的な未達項目です。 ```text 項目3が未達です。 具体例が0件でした。実務に置き換えられる例を2件追加してください。 項目4が未達です。 最後の段落が感想で終わっています。次に試せる手順を3ステップで追加してください。 ``` 「やり直して」ではなく、「何が、どれだけ、足りないか」を返す。この差だけで、再実行後の出力はかなり変わります。 ## 全てのタスクに使わない ループ設計にはコストがかかります。 評価基準を作る必要がありますし、再実行のたびにAPIコストもレイテンシも増えます。自動化するなら、無限ループを防ぐ上限回数や、失敗時に人間へ戻す設計も必要です。 だから、全てのタスクに使うべきではありません。個人的には、この判断を最初に間違えて、単純な変換処理にまでループを入れて無駄にコストを増やした反省があります。 向いているのは、次のようなタスクです。 - 繰り返し発生する - 評価基準を言語化できる - 初回出力に改善余地がある - 失敗理由を次の実行に渡せる たとえば、記事下書き、SQL生成、コード修正、構造化データ抽出、問い合わせ返信案の作成などは相性がいいです。 一方で、単純なバリデーション、計算、正規表現で済む変換、1回限りの小さな作業には向きません。これらはループを回すよりも、コードで検証を書いたほうが速くて安いです。 判断に迷ったら、「生成は難しいが、チェックはできるか」を見てみてください。チェックできるなら、ループ化の候補になります。 ## 今日からできる最小ループ いきなりエージェント基盤を作る必要はありません。 まずは、手動で小さく始めれば十分です。 1. 繰り返しているAIタスクを一つ選ぶ 2. 良い出力の条件を3〜5項目書く 3. AIに一度出力させる 4. ルーブリックに照らして未達項目だけを返す 5. 2〜3回だけ再実行する この時点で、一発指示との差は体感できるはずです。 もし差が出ないなら、ルーブリックが曖昧すぎるか、そのタスクがループに向いていない可能性が高いです。どちらにせよ、最初の数回で「このタスクにループが効くかどうか」の感覚は掴めます。 ## まとめ プロンプトを一発で当てる発想から、評価して直す発想に切り替えるだけで、AI活用の景色はかなり変わります。 今回は考え方の整理に寄せましたが、個人的には、手動ループを2〜3回やった時点で「これは効く」と実感できました。最初から自動化やエージェント基盤を作る必要はありません。まず手元で回してみて、ルーブリックの良し悪しを体感するところが出発点です。 次回以降は、Claude Codeで手動ループを実際に回す実践編、APIでの最小実装、ルーブリックの育て方、Langfuseでの観測あたりを順に書いていく予定です。 API実装へ進み、最小ループをコードにした検証結果はこちらです。