こんにちは!
社内技術横断支援組織「Backbeat」の山田のてっちゃんです!
前回の記事では、picoCTF 2026 を LLM エージェントで走らせて 70問中69問正答、最後の Paper-2 に7日張り付いて敗北した、という話を書きました。
そこで予告したとおり、今回は 「あの発想にたどり着くには、エージェントの何を変えればいいのか」 を逆算して、ソルバーを v3 に作り直しました。そしてその v3 を引っさげて、SECCON Beginners CTF 2026 に挑んできました。
先に結果だけ言うと、出た問題はぜんぶ解けました(全完)。
解けたんですが、v3は思ったように動作しておらず、継続して振り返りが必要です。プロンプトの反省点もありますが、シンプルに前回のような試行回数重ねて解くタイプの出題がありませんでした。
この記事は v3 の設計の考え方と、SECCON の結果・振り返りを取り急ぎざくっと 書きます。
振り返りの細かいところと、それを踏まえた v4 の中身は、次の大会のタイミングで別記事にする予定です。
この記事でわかること
- 前回の敗北(
Paper-2)から逆算して、v3 で 何を「難所」と捉え直したか - 「解法を教えない」をもう一歩進めた、決定論パスと統計パスを分けるという設計
- SECCON Beginners 全完という結果と、その裏にある 「本命機能が一度も動かなかった」という事実
- 全完したからこそ厄介な、正答率が手がかりにならない振り返りの話(ざっくり)
前回のおさらいと、今回立てた問い
前回いちばん大きかった学びは、ふたつでした。
-
「思考法を渡すだけ」では届かない問題がある(
Paper-2) - 暴走サブエージェントへの引導の渡し方(長考に入ったときの未検証仮説への固執)
この2つを念頭に置きつつ、Paper-2 の公開 Writeup から逆算で「あなたはこの考え方にどうやったら至れる?」をOpus自身に考えてもらいました。
(参考:Vipin さんの writeup )
その結果、「どこで決定論をあきらめて、ノイズ分布に賭けにいくか」というフェーズの切り替えをどう示すかが大事では?という気づきを得ました。
Paper-2 の難しいところ(おさらい)
Paper-2 をすごく雑に例えると、
目隠しした状態で池に石を放り込んで、波が立つ音を聞いて1分以内に池の中の岩の配置を一発で当てる。しかも池の周りは工事中で波音は聞こえずらい。そして回答が間違ってたら岩の配置はシャッフルされる。
みたいな問題です。
つまり、どれだけ丁寧に詰めても「単発の決定的な観測」では答えが出ない問題です。
じゃあどうするか。一回の挑戦の中で石を何千個もばらまいて、ノイズも含めて全部の音を拾って、「岩がある場所の聞こえ方/絶対にない場所の聞こえ方」を整理して、確からしさをスコアに変えて、最後にいちばんつじつまの合う配置を組み上げる。決定論で一個ずつ詰めていくのとは、やることの毛色がまるで違います。
実際の Paper-2 だと、石を投げる=CSS セレクタの部分一致オラクル、波の音=Redis のキャッシュ追い出し(allkeys-lru)、配置の復元=対数尤度比とビームサーチ、です。
(参考:Vipin さんの writeup )
なので v3 では、「これは決定論じゃ無理だ。ノイズに賭けるフェーズに入った」 という判断をさせてみることにしました。
v3 で何を変えたか(ざっくり)
以下、改修のポイントを書いてますが、冒頭で書いた通り実績なしです。次回大会へ期待!
1. 「決定論の深さ」と「統計をやるかどうか」を別軸に
| 軸 | 値 | 誰が決めるか | 何を制御するか |
|---|---|---|---|
| 決定論の深さ |
light / full
|
配点(機械的に) | どこまで網羅的に調べ尽くすか |
| 統計の能力 |
off / on / armed
|
人間(オペレータ) | 統計的に復元するエージェントを動かすか |
肝は、高難度・高配点の問題でも、まずは決定論で解くこと。統計のほうは「重くて遅くて滅多に要らない、人間が問題ごとに ON にする能力」と割り切って、デフォルトではコンテキストに読み込みすらしないようにしました(Claude Codeなので、スラッシュコマンドにしました)。
人間の判断をいれるのは基本的に悪手だと思ってますが、トークン量節約の都合上、Claudeくんがよくないループに入るのは避けたいので、滅多にそんな問題出なかろうというのも込みでカスタムコマンド化しました。
2. 「検出」と「決定」を分けた
決定論ソルバーが、「これはノイズ駆動だ」と思ったら、トリップワイヤーが作動します。やることは最小限です。
- 「チャネルがノイジーでした」という証跡を
[OBS]としてsolve.logに残す - 統計エージェント向けに引き継ぎ(ハンドオーバー)ブロックを書く(決定論ソルバーが見つけたオラクルの仕組みを含む)
-
NEEDS_STATISTICALというシグナルだけ立てて、ユーザーのコマンドを待つ
このとき決定論ソルバーは、統計を一切やりません。「これは統計が要る問題だ」と気づくところまでが仕事で、実際に重い統計を回すかどうかの判断は人間。これが v3 の肝であると同時に残念なところでもあります。役割分担的にはこの分け方でいいんですが、最終的には人間じゃなくて本当はEvaluatorに自動的にやらせたい。
3. 決定論の引き際を明示
前回の「未検証仮説への固執」への対策は、事実と仮説をきっちり分ける運用でなんとかなった気がしてます。どんな主張も [OBS](単発で再現する観測)か [HYP](推論)のどちらかに必ずラベルを振って、仮説の上にさらに仮説を積ませない、単発の再現テストを通したものだけ観測に昇格する、というルールを徹底しました。「ノイジーで結果が安定しない」は、根性で押し通す対象ではなく、トリップワイヤーの発火条件として扱います。
SECCON Beginners の結果:全完
そして本番。SECCON Beginners CTF 2026 に v3 を投入したところ、出題された範囲はぜんぶ解けました。
- 決定論パイプライン(Fast → Deep → Evaluator → 決定論リトライ)が、狙いどおり安定して回りきった
- 前回のような長考時の暴走(未検証仮説の固着)も、事実と仮説を分ける運用のおかげで目立った再発はなかった
ここまでは、素直に「作り直してよかった」と言える結果です。
本命の「統計パス」は一度も動かなかった
v3 でいちばん試したかったのは、「 トリップワイヤーが、ノイズ駆動の難問を前にして、ちゃんと自分から発火するか」でしたがSECCON Beginners には Paper-2 級の「決定論じゃ原理的に詰む」問題が出ず、仕組みがうまくいくか確かめられませんでした。
振り返り(ざっくり)
今回は全ての問題を解けているので、「こういう問題が苦手なんだな」というわかりやすい指標はありません。なので、解けた/解けなかった以外の手がかりを掘る方針でやっています(細かいところは次回)。ざっくり挙げると、こんな観点です。
- コンテキストの最適化:v3 では思考法も引き際のルールも、全てが1度にコンテキストに読み込まれます。その結果、2点目に挙げられているプロトコルからの逸脱の一因にもなってる気がするので、最適化が必要と考えてます。
- プロトコルからの逸脱:基本的には守られてましたが、(結果的には不要だったものの)Evaluatorに伝える情報の出力など、部分的に無視されてたので、インセンティブを効かせた設計が必要そうです。
- 未使用の機能:今回大会では検証できなかったので、前回からの申し送り事項として引き続き意識が必要です。
次回予告(v4)
すでに改修には手をつけているのですが、その成果含めて次回の記事にしようと思います。主に、プロンプトが重すぎたのでSkillsにしてコンテキストの読み込みを必要最低限にしたりとかですね。統計論的思考が動くかどうかはそういう問題が出るかどうかによるので、未定です。
参考リンク
- 前回記事(picoCTF 2026): https://qiita.com/dirbato-tetsushiyamada/items/84de323c56d50feb34d5
-
Paper-2Writeup by Vipin(v3 設計の逆算材料): https://www.vipin.xyz/blog/picoctf2026


