1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

LLMのプロンプトを差し替えずに挑戦者として並走させ、同じ日の結果で比べる仕組みを作った話 〜「ペルソナを与える」より判断基準を書く〜

1
Posted at

みなさん、こんにちは!
「ALPHA FORGE 開発秘話」の第35話です。

「AIにペルソナを与えましょうか」。そう聞いたら、AIは「役柄は付けない方がいいです」と返してきました。
代わりに出てきたのは、今のプロンプトを1文字も変えずに、新しい版を横で走らせて成績で比べる案です🥊

日本株のデータ分析端末「ALPHA FORGE(アルファフォージ)」を、Claude Code と二人三脚で個人開発しています。今回はプロンプトの書き方の回。LLM への指示文を「良さそうだから」で差し替えてしまう方へ、差し替えずに比べる段取りをお届けします。

【要約:この記事で伝えたいこと】

  1. プロンプトの新しい版を、本番を置き換えずに同じ LLM モデルで並走させ、実際の結果で比べる仕組みを作った
  2. 言い出したのは人間、「役柄より判断基準を書こう」と返したのは AI。採用するかどうかは人間が決める
  3. 持ち帰り:新しいプロンプトは差し替えずに、印を付けて横で走らせる

※本記事はnote連載[ALPHA FORGE 開発秘話 #35]の技術的な部分を、エンジニア向けに再構成したものです。

🧭 「ベテラン役」を演じさせたら賢くなる?

ALPHA FORGE では、毎朝 LLM が候補の銘柄を1つずつ読み、採るか見送るかを判定しています。その判定プロンプトの1行目は、ずっと「分析を補助するアシスタントです」という短い役割の一文でした。

2026年9月26日の昼前、人間がふと聞きました。「LLMにペルソナを与えましょうか。」

「あなたは経験20年のファンドマネージャーです」と書くと答えが良くなる、というのはよく聞く話です。試す価値はありそうに見えました。

💥 AIの答えは「役柄は付けない方がいい」

AI(Claude Code)はすぐには答えず、まず今のプロンプトに役割の指定があるかを読みに行きました。そのうえで返ってきたのが、役柄を足さない方がいい理由3つです。

  1. 人物設定で変わるのは主に口調や自信の度合いで、判断の正しさにはあまり効かないことが多い
  2. 確度(LLM が付けた自信)は過去の出力をもとに事後較正している。性格が変わると、その較正が合わなくなる
  3. 「プロとして推奨する」口調は、外に出す文章で投資助言らしく見せない方針と相性が悪い

02_wall.jpg
変えたいのは口調ではなく、判断の仕方

2つ目が地味に効きます😅 確度は「この自信なら過去に何割当たったか」で較正してから画面に出しています。プロンプトの性格をいきなり変えると、この較正の前提が崩れるんです。

代わりに AI が勧めたのは、役柄ではなく「ふるまいの規則」を書くこと。そして今の判定と差し替えずに、挑戦者として横で走らせて比べることでした。

fig_chat_0926.jpg
「ペルソナを」から、並走の計画へ

ハマりどころ:プロンプトを変えると、後ろの較正も変わる
LLM の自信を較正して使っている場合、プロンプトの差し替えは「判定」だけでなく「較正の前提」も変えます。差し替えてから成績が落ちても、原因の切り分けができません。

🛠️ 判断基準を書いた「挑戦者」を、横で走らせる

新しい版の名前は persona-v1。名前に反して、中身は人物設定ではありません。冒頭の役割を「リスク管理を重視する検証担当」にして、判断基準を箇条書きで足しました。

実装の抜粋:版ごとに変えるのは冒頭の役割と判断基準だけ(コミット 3723c89 より)

backend/services/picks/prompt.py
# プロンプトの版。"v1" が champion(本番)の文面で、それ以外は挑戦者として shadow 並走させる版。
# 版ごとに変えるのは冒頭の役割・判断基準だけで、材料(銘柄以降)と「制約」は全版で共通にする
PROMPT_VARIANTS: tuple[str, ...] = ("v1", "persona-v1")


def _intro_lines(horizon_type: str, variant: str) -> list[str]:
    """版ごとの冒頭(役割と判断基準)を返す."""
    horizon = _HORIZON_LABEL.get(horizon_type, horizon_type)
    if variant == "v1":
        return [f"あなたは日本株の {horizon} 投資の分析を補助するアシスタントです。"]
    if variant == "persona-v1":
        return [
            f"あなたは日本株の {horizon} における、リスク管理を重視する検証担当アナリストです。",
            *_PERSONA_V1_RULES,
        ]
    raise ValueError(f"未知のプロンプト版です: {variant}")

判断基準の要点はこうです。

  • 定量分析と材料が同じ方向を向いているときだけ、確信度を高くする
  • 損切りの水準を先に決める
  • 想定リスクに対して想定リターンが見合わない(目安 1.5倍未満)なら見送る
  • 材料が乏しいときは、無理に採らず見送ってよい

「推奨する」「プロとして」のような言い回しは、わざと入れていません。

並走のさせ方にも、比べるための工夫があります。

  1. LLM モデルは本番と同じにする。違いをプロンプトだけの効果として測るため
  2. 本番が採ったかどうかに関係なく、同じ候補を全部、別々に判定する
  3. 応答の検証と採点は本番と同じ部品(judgment.judge)を通す。挑戦者だけ基準が甘くなることはない
  4. 成績は、挑戦者と同じ日に出した本番の判定とだけ比べる。相場の違いを拾わないため

03_fix.jpg
同じ候補・同じモデル・同じ採点で、プロンプトだけを変える

挑戦者は環境変数 PICK_PROMPT_CHALLENGER で有効にし(既定は無効)、失敗しても本番のピックには影響しないようにしました。採った判定は予測台帳に is_shadow=1 の印を付けて入れます。夜の答え合わせは挑戦者の分もしますが、画面の一覧・通知・確度の較正・成績の集計は、印の無い本番の行だけを読みます。

この「台帳を読むコードは既定で is_shadow=0 に絞る」は、AI への指示書(CLAUDE.md)にも書き足しました。台帳を読むコードを新しく書くたびに、混ぜてしまう危険があるからです。

fig_isolation.jpg
挑戦者の行は、読む場所を限る

テストは backend で1,117件が通り、そのうち20件が今回の新規です。コミットは昼の12時過ぎ。会話が始まってから、およそ30分でした。追加の費用は1日約0.33ドルの見込みで、これも計画の時点で AI が試算しています💸

⚖️ 1か月後の最初の判定は「保留」

週に1回、挑戦者が本番を上回ったかを機械が評価します。最初の判定は、2026年10月26日の早朝に出ました。

結果は「保留」。理由は「比べられる日が9日分しかなく、決まりの20日に届かない」です。

短期の判定で、挑戦者と本番の両方がそろった9日分(9月28日〜10月9日に出した判定)を、3営業日後の決着で比べた数字も残っています。

版 判定の件数 勝ち 勝ちの割合
挑戦者(persona-v1) 23 8 約35%
本番(v1) 53 17 約32%

fig_result.jpg
差はまだ小さく、件数も足りない

差は3ポイントほどで、件数も少なく、これだけでは何とも言えません。どちらも半分に届いていないのも、正直に書いておきます。挑戦者は採った件数が本番の半分以下で、「見送ってよい」が効いている可能性はあります🤔

もう1つ、計画の時点で決めていたことがあります。昇格が提案されても、画面のボタン1つでは差し替えません。実際のプロンプトはコードに書いてあるので、採用するなら人間がコードの既定の版を変えて出し直します。

🧰 新しいプロンプトを試すときの頼み方

今回の流れを、ほかの AI の仕事にも使える形に整理した例です。当時の人間の発言の引用ではありません。

いまのプロンプトを良くしたいです。
新しい版を作っても、いまの版は書き換えずに残してください。
新しい版は、いまの版と同じ材料・同じAIモデルで、横で並べて動かしてください。
新しい版の結果には印を付けて、いまの成績の集計には混ぜないでください。
どちらが良いかは、同じ日の結果どうしで比べ、判断できる件数がそろうまで結論を出さないでください。
採用するかどうかは、私が決めます。

最後の2行が大事です。良さそうに見える日が数日続いても、件数がそろうまでは「保留」が正しい答えになります。

🤝 誰が言い出し、誰が決めたか

言い出したのは人間です。「ペルソナを与えましょうか」の一言でした。

AI は、今のプロンプトを読んでから役柄を足さない理由を挙げ、判断基準と並走の案に組み替えています。計画、実装、テスト、費用の試算も AI です。人間が決めたのは次のことです。

  1. 役柄ではなく判断基準で試す、という方針
  2. 計画どおり進めるか
  3. 挑戦者を本番の設定で動かし始めるか

そして一番大事な「採用するか」は、まだ誰も決めていません。決めるのは、件数がそろったあとの人間です🙋

fig_checklist.jpg
プロンプトを差し替えずに比べるための点検

📌 保存用チェックリスト

  1. いまのプロンプトは書き換えずに残す
  2. 新しい版は、同じモデル・同じ材料で横に並べて動かす
  3. 新しい版の結果には印を付け、いまの成績の集計には混ぜない
  4. 比べるのは、同じ日に出した結果どうし
  5. 件数がそろうまでは「保留」で止める

🔜 次回予告

次回は、答え合わせの帳簿に開いていた3つの穴の話。上限の占領、1日ずれる日付、足りない足を扱います。

比べる日数を「20日」にしたものの、短期の候補が少ない時期は、なかなか日数がたまりません。みなさんなら、日数がそろうまで待つ派ですか? それとも、件数で区切って早めに判定する派ですか? コメントで教えてもらえるとうれしいです😊

☕ note.comで開発秘話と毎朝の検証ログを連載中

note.comでは、「ALPHA FORGE」の開発秘話と、毎朝のアルゴリズム検証ログを公開しています。

👉 元記事(note連載第35話):
https://note.com/featured_stocks/n/n402081ba031f

「シャドウ」で並走させていた別の LLM が、13日間黙っていた話は第22話です。並走の仕組みを見張る大切さが分かります。

エンジニアでない方向けに「AIへの仕事の頼み方」をまとめた連載(メンバーシップ「AIとつくるラボ」)もやっています。第0話は無料で読めます。


免責事項
本記事は個人開発およびAIエージェントを活用したシステム開発の技術記録です。特定の銘柄の売買推奨や投資助言を行うものではありません。本記事は2026年9月26日の実装記録と会話ログ、10月26日の評価の記録を、同じ10月26日に確認したものです。銘柄名と価格は掲載していません。勝ちの割合は短期の判定の一部の期間と件数によるもので、投資の判断基準や成果を保証するものではありません。本アプリは発注を行いません。

⚠️ 【システム検証記録に関する免責事項・注意事項】

  • 本記事は、独自開発アルゴリズム「ALPHA FORGE」の動作検証およびデータ分析過程を公開する技術・運用の個人的な記録ログです。
  • 掲載されているすべてのデータ(各スコア、基準観測値、統計的変動上限、シナリオ無効化水準など)は、過去の市場データに基づき数式(ATR等)により機械的に算出されたバックテスト・シミュレーション用のパラメータであり、特定の有価証券の売買勧誘、取引の推奨、投資助言・代理行為を目的としたものではありません。
  • また、将来の株価変動や運用成果を保証するものではありません。実際の投資判断および最終決定は、必ずご自身の責任と判断において行っていただけますようお願いいたします。
1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?