--- title: "安定して3位に入る" author: "Shawn Jiang" lang: ja date: 2026-09-14 canonical: https://tplog.dev/ja/essay/consistent-third-place/ translations: en: https://tplog.dev/en/essay/consistent-third-place/ zh: https://tplog.dev/zh/essay/consistent-third-place/ --- # 安定して3位に入る AI製品を評価するとき、私たちは最高点に目を向けすぎていないだろうか。 コードを読み書きし、ツールを使うCoding Agentが、複雑なリファクタリングを自力で終える。モデルが、それまでどうしても解けなかった問題を解く。Agentが数時間働き続け、エンジニアなら丸一日かかる仕事を仕上げる。 こうした瞬間にはわくわくする。試合での優勝のように、どこまでできるのかを見せてくれるからだ。 ただ、AIを実際の仕事に組み込むと、もっと地味で、もしかするともっと大切な問いがある。安定して3位に入れるか、ということだ。 ## 「安定して3位」とは何か ここでいう「3位」は、3位で満足しようとか、優勝を諦めようという意味ではない。この順位で表したいのは、すでに十分よくできていて、使えて、そのまま納品できる水準の結果だ。 つまり「3位」が指すのは能力の上限ではなく、あてにしたい品質の下限だ。もっと大事なのは「安定して」のほうである。 今日、ある問題を渡すと3位になる。明日、別の問題を渡しても3位になる。来週、初めて見るが能力の範囲には収まる問題が来ても、ちゃんとやり遂げる。 同じ問題を100回解いて、毎回同じ答えを出すという話ではない。次々と変わる新しい仕事に対しても、結果が簡単には許容範囲を外れないということだ。 私がコーチで、2人の選手を抱えているとする。 1人目は優勝することもあれば、5位、10位になることもあり、次の試合では突然また優勝する。2人目はめったに優勝しないが、長く見れば2位、3位、3位、4位、3位といった成績を残す。 ハイライトだけなら、1人目のほうがずっと華やかだ。だが、長いシーズンを戦うなら、2人目にはとても大切なものがある。任せたら何が返ってくるか、おおよそわかる。 日本語に「計算が立つ」という、私の好きな表現がある。見通しがつき、あてにできるということだ。選手について使うなら、コーチはその選手を出せばどれくらい貢献してくれるかがわかっている。 この予測できること自体が、一つの能力なのだ。 ## Workflowの制約も製品の一部 あらかじめ手順を組んだWorkflowとAIを組み合わせる価値の一つも、ここにある。Difyで人が組んだフローを例にすると、自分で次の行動を決められるAgentに比べて、少し「不器用」に見える。 最初に何をするか、次に何をするか。どの条件ならAへ進み、どの条件ならBへ進むか。どこでツールを呼び、どこで結果を確認し、どのデータを次の工程へ渡してよいか。必要なら、重要な箇所に人の承認も挟む。 自由度を、人が意図的に制限している。 これは能力面での妥協にも見えるが、制約そのものが製品の一部なのだ。手順を固定し、入出力やツールを制限し、条件判定を加える。通常、その目的は誰も思いつかなかった天才的な答えをたまに出すことではなく、結果のばらつきを減らすことにある。 自由に探索するAgentの成績が、50点から100点の間で変動すると仮定しよう。適切に設計されたWorkflowなら、その幅を70点から85点に狭められるかもしれない。 100点を取る機会を一部失う代わりに、突然50点まで落ちる可能性も減らす。上限の一部と引き換えに、下限を引き上げるわけだ。 ただし、手順が固定されていれば結果も信頼できるとは限らない。確認条件が間違っていたり、ある種類の入力をフローが扱えなかったりすれば、安定して間違えることもある。下限が本当に上がったかは、実際の仕事で検証する必要がある。 本番環境では、この予測しやすさが、たまに出る高得点より重要かもしれない。企業が本当に恐れるのは、AIの賢さが足りないことよりも、「次に何をするかわからない」ということだ。 ## Coding Agentには「コーチ」という変数がある CodexやClaude CodeのようなCoding Agentに惹かれるのは、まさに優勝できる可能性があるからだ。 複雑な問題に対して、コードベース、要件、背景情報を渡す。その後も対話し、方向を調整し、結果を確かめていく。ときには、期待を大きく超える成果が出る。決められたフローに沿って仕事を進めるのとは、かなり違う体験だ。 ただ、ここには見落とされがちな変数がある。コーチだ。 同じCoding Agentでも、使う人によって結果はまったく違うことがある。優れたエンジニアは、いつ自分で探索させ、いつ止めるべきかを知っている。何を背景情報として渡すか、結果のどこに違和感があるかもわかる。プロンプトを書き直し続けるより、問題そのものを変えるべきときも見極められる。 だから最終的な成果は、Agentだけで決まるわけではない。能力の一部は、人とAgentが実行、確認、調整を繰り返すHuman-Agent Loopの中にある。 選手の基礎能力は高い。だが、コーチにも状況を読む力が要る。優れたコーチなら、その選手と何度も優勝を狙える。コーチが何をしているかわかっていなければ、強い選手でも進む方向を誤る。 コーチの役割は高得点を狙うことだけではない。間違いに早く気づき、仕事の範囲を絞り、検証を求めることも、下限を守る働きだ。 ## 重視する目標が違う こう考えると、「DifyとCoding Agentはどちらが先進的か」という問いは、あまり役に立たない。比べているのは、実際には2つの使い方が何を重視しているかだ。 あらかじめ組まれたWorkflowは、繰り返し発生しながら具体的な内容は変わる仕事で、十分に信頼できる品質の下限を維持することを重視する。 人と一緒に探索するCoding Agentは、その場でモデルが判断する余地を広く取り、あらかじめ定義されていなかった成果に届く可能性をつくる。 一方は「次もできるか」をより重視し、もう一方は「今回はどこまでできるか」を探ろうとする。どちらにも価値がある。 これは製品間の越えられない境界ではない。Workflowの途中でAgentを呼ぶこともできるし、Coding Agentも手順の固定、テスト、人の承認によって安定性を高められる。 ## いつ優勝を狙うべきか 「安定して3位」は、すべてのAIをWorkflowにすべきだという意味ではない。優勝の見返りが大きく、失敗のコストが小さいなら、私は喜んでばらつきを受け入れる。 Coding Agentには有利な条件がある。開発環境をすぐに再構築できるなら、大きな試行錯誤の余地が生まれる。 Agentが間違ったコードを書いても、diff、つまりコードの差分を見られるし、テストも実行できる。変更を戻すこともできる。本番から隔離され、すぐに再構築できる開発環境なら、環境自体を壊してしまっても、作り直してまた試せる。 やり直しは無料ではない。それでも復旧が十分に速ければ、大胆に探索させたい。複雑なリファクタリングに成功すれば、数時間の節約になるかもしれない。その範囲なら、たまに10位になることも受け入れられる。優勝による見返りが、試行錯誤のコストを上回る可能性があるからだ。 だが、会社は開発環境ではない。壊したあと、すぐにもう一つ作り直して、何もなかったことにはできない。 誤って支払ったお金は回収しなければならない。顧客に送った誤った情報には説明が要る。損なわれた信頼も、システムを再構築しただけでは戻らない。AIのWorkflowが毎日1万件の業務を処理し、たった一つの異常がこうした結果につながるとしたら、たまに見事な成果を出しても、その損失を埋め合わせることにはならない。 これはCoding Agentの境界でもある。環境を再構築できることと、コードが引き起こした結果を取り消せることは別だ。本番データを直接操作できたり、十分に検証されないまま変更が業務に入ったりすれば、失敗はもう安く済むとは限らない。 そこで価値を持つのは、明日もおそらく3位に入ってくれるとわかることだ。異常を見つけ、危険な操作を止め、必要なときには人へ渡す。それらはすべて、あてにできる品質の下限を守るためにある。 ## 一番よかった一回だけを見ない AIについて話すとき、私たちは一番よかった瞬間に惹かれやすい。ランキングの高得点、デモの最もきれいな進行、SNSで話題になる驚きの事例。 それらは大切だ。技術の限界がどこへ広がっているかを教えてくれる。ただ、きれいな点数と成功例だけを見ていると、仕事ごとの差や、どこで失敗しているかを見落としやすい。 AIがデモから実際の仕事へ進んだとき、一番悪い結果はどこまで悪くなるのか。 そして、次の仕事を任せたら何が返ってくるか、おおよその見当はつくのか。 成熟したAI製品は、毎回優勝する必要はない。次に来る初めての問題にも、安定して3位に入る。そのほうが難しいこともある。