総務省「全国型CTF」— AI Agentパイプライン運用の振り返り

総務省の全国型CTFに個人で参加した。確認済みの大会規則ではAI利用が認められていた。公式CTFdプロフィールには26位、5,701点と記録されている。この公式結果とローカルtrackerの集計は別の記録だ。

Event)

全国型CTFは、限られた時間内に多くの課題を集め、解き、検証し、提出する運用面の課題でもあった。この記事は各challengeの解答紹介ではなく、pipeline運用の振り返りだ。公式結果、ローカルtrackerの集計、event traceで確認できた事実、記録からは分からないことを分けて書く。

Result)

保存されたtrackerには110件のchallengeがあり、提出結果が記録された行は107件だ。そのうち101件がcorrect、6件がincorrectで、残る3行には結果が記録されていない。結果行の数は自動で解けた問題数を意味しない。

trackerでcorrectと記録された101件について、accepted pointを合計すると5,900点になる。これは公式scoreではない。CTFdプロフィールの5,701点との差は199点だが、保存されたevidenceから原因は特定できない。両者は別の値として扱う。

Approach)

ローカル記録には110件のchallenge recordと、20個のchallenge IDにまたがる21個のattachmentが残っている。セッションログにはlocal advisor/modelとremote APIの両方が現れる。並列作業の指示や、別のsubmission workerも記録されている。

保存されているchallenge recordと一部のeventから、完全なend-to-end実装までは確認できない。challengeごとのworker/model割り当て、人の介入時点、retry回数は結果記録と結び付いていない。

author提供のevent captureには、大会途中のCTFdプロフィール（29位・4,401点）が記録されている。同じcaptureのOMP画面と個別challenge履歴は、challengeごとの運用内容が映るため掲載しない。約13:53 JSTのさらに早いcaptureには302位・1点が写っていたが、図1の最終結果ではなく大会序盤の状態だ。

下の補足timelineは保存されたcontrol-plane eventと介入記録から再構成した。時系列を補う派生資料であり、OMP画面や実際のsolve時間を示すものではない。

Problem)

trackerだけではpipeline全体の状態は分からない。owner欄は空で、challengeごとの開始・終了時刻も十分に残っていない。HTTPリクエストの成功と、CTF側が正解と判定したことは別だ。

challengeを一つ解くことと、システム全体の正確な状態を把握することは別だ。たとえばqueue stateがworker間で複製され、提出結果の反映が遅れれば、重複作業や受付終了後の作業が起こり得る。保存されたevidenceだけでは、個々の運用事象の原因までは復元できない。

Bottleneck)

保存された記録から見える主な課題は、model inferenceよりもcontrol plane側にある。

• Ownershipとstate: challengeごとのowner/leaseがなく、重複作業や責任範囲を測れない。
• Artifact intake: tracker上のmanifestと取得済みファイルが一致するとは限らない。hashとprovenanceが必要だ。
• Verification: 提出前に結果の形式と意味を独立して確認する。
• Observability: challenge ID単位のevent記録がなければ、model性能とcontrol-plane遅延を分けて評価できない。
• Close control: 権威ある締切と公式result exportがなければ、遅い作業を安全に止め、trackerを照合しにくい。

Local vs API)

challengeごとのroute記録がないため、local computeでAPI利用がどれだけ減ったか、人が何件介入したかは算出できない。正確な自動化率や削減額も示せない。

Architecture v2)

次回はchallenge IDをキーに単一のcanonical queueとactive leaseを設ける。intake時にファイル形式とhashを確認し、まずローカルでdeterministicな解析を行う。必要な場合だけ、health check済みのlocal modelまたは予算を明示したremote APIに回す。候補はprivate evidence storeに保管し、independent verifierを通った結果だけをsingle submission brokerで一度提出する。公式cutoffでbrokerを閉じてからscoreを照合する。

この図は2026年の実装を示すものではない。左は保存されたevent evidenceから再構成したV1で、実装全体を検証した仕様ではない。右は提案するV2であり、実装完了前後の比較ではない。

Retrospective)

次回はworkerを増やす前に、challengeごとの実行記録と提出状態を残す。

Evidence / Notes)

• 最終順位・得点はFigure 1の公式CTFdプロフィールで確認できる。
• local trackerはchallenge 110件、提出結果107件（correct 101件、incorrect 6件、未記録3件）、合計5,900点だ。CTFdの5,701点とは別で、199点差の原因は未確認だ。
• Figure 4はauthor提供captureからCTFdプロフィールだけを残したcrop（29位・4,401点）だ。OMP画面と個別challenge履歴は掲載していない。約13:53 JSTの302位・1点はさらに早い状態で、最終結果ではない。
• 補足timelineは保存されたeventから再構成した派生資料だ。Figure 5のV1も保存されたevidenceからの再構成で、V2は提案である。
• challengeごとのmodel routeと人の介入記録は不完全だ。正確な自動化率は算出できない。