データ分析検証

Hayabusa investigate-jp 実行ログから見るローカルLLMの性能・行動傾向・終了要因

はじめに

本稿では、OpenCode 上で同一の Hayabusa CSV を investigate-jp skill に従って調査させた実行ログを再分析し、各モデルについて次の3点を整理する。

1. フォレンジック分析の質 — ログの特徴をどこまで正しく捉え、適切に深掘りできたか
2. エージェントとしての行動傾向 — tool call、state 管理、エラー復旧、調査範囲の拡張などをどう行ったか
3. なぜ終了したのか — 正常な完遂なのか、長さ上限なのか、自発的な stop なのか、tool orchestration の破綻なのか

対象範囲

元の17セッションのうち、MessageAbortedError で終了した6件は今回の比較対象から除外した。また、qwen3.6-35b-a3b-128k-t0:latest の1件は「利用可能なMCPの種類」を尋ねた別タスクであり、Hayabusa 調査性能を比較できないため参考外とした。

したがって、比較対象は Hayabusa 調査に取り組んだ10セッション、9モデル構成である。

注意: これは統制されたベンチマークではなく、実際のエージェント実行ログを用いた観察的比較である。同じモデルでも sampling、runtime、prompt、MCP 状態によって結果は変わり得る。

---
プロンプト

/investigate-jp <csv_path>

結論の要約

今回のログで最も重要だったのは、単純な「最後まで回答したか」ではなかった。

• Qwen3.6 35B 系は、分析判断そのものは最も有望だった。 high が1件しかない状況でも、12,785件の File Deleted、538件の med、Autorun、ADS、PowerShell dropper、Proc Tampering などを見て、調査範囲を med/high/crit に拡張している。
• 32K版 Qwen3.6 35B は分析途中で32,768 tokensに正確に衝突した。 これは明確なコンテキスト上限であり、モデルの終了判断とは別問題である。
• 128K版 Qwen3.6 35B はコンテキストに余裕があるのに止まった。 pending rule と未判定clusterが残っていることを自分で認識した直後、「継続して調査を進めますか？」と確認して stop した。主問題は推論力ではなく agent control である。
• Ornith 35B は最も深い地点まで安定して進んだモデルの一つだった。 43,746 tokens時点で20件のpending ruleを認識し、5件ずつSQLで検証する正しい計画を立てたが、実際のSQLを発行する直前に stop した。
• GLM-4.7-Flash は唯一「それらしい最終レポート」まで持っていったが、調査品質は低かった。 18,858イベント中 high/crit 1件の Defender 検出を false positive としたあと、mass deletion や med レベルの攻撃候補を十分に検証せず、cluster全体を benign に寄せた。完遂力と分析品質が一致しない代表例である。
• Qwable 系は tool orchestration や事実の保持に弱さが見えた。 tool error後に誤った経路へ進む、未取得の攻撃ストーリーを補完する、環境トラブルシュートへ脱線する、といった傾向が目立った。

今回の用途で最も改善価値が高いのは、Qwen3.6-35B-128K に completion guard / state-driven continuation を追加する構成だと考えられる。

---

全セッション比較

モデル	セッション	観測最大turn tokens	到達地点	最終状態	主な終了要因	総合所見
qwable-v2-128k-t0:latest	ses\_01f0194...	27,329	Step 3	stop	次のBashコマンドをtoolではなく本文として出力	分析の事実保持に問題。未裏付けの攻撃ストーリーも混入
mannix/qwen3.6-27b-a3b-coder:Q8\_0	ses\_01e8f2...	26,217	state init直前	unknown	Bashに渡すべきコマンドを不正toolとして生成	初期分析は妥当だがtool境界で破綻
qwen3.6:35b-a3b	ses\_01f162...	26,620	dataset load完了	finish未記録	CSVを許可rootへコピーしload成功直後にログ途絶	問題解決能力は良いが性能評価には不完全
qwen3.6:35b-a3b	ses\_01f127...	32,768	Step 3.5	length	32,768 context上限	分析品質は高い。32Kが明確なボトルネック
qwen3.6-35b-a3b-128k:latest	ses\_01ef416...	29,509	Step 3〜3.5入口	stop	pendingを認識しつつユーザー確認へ逃避	最有力だが自発stop対策が必要
qwable-v2-128k-default:latest	ses\_01ef8fe...	28,317	初期orchestration	stop	subtask/session IDエラー後、実作業せず終了	長い計画を生成するが実行制御が弱い
qwen3.6-27b-128k:latest	ses\_01eee4...	35,226	Step 1	stop	CSVをglobで発見した直後、1 tokenで停止	コンテキスト不足ではなくcontinuation failure
aratan/Ornith-1.0-35B...	ses\_01e95e...	43,746	Step 3.5	stop	20 pendingを5件ずつ調べる直前で停止	深度は高い。action boundaryでのstopが弱点
glm-4.7-flash	ses\_01ebb7...	33,033	gate PASS→レポート	stop	HTML生成失敗後、手動レポートへfallback	完遂力は高いが判定品質が低い
hf.co/lordx64/Qwable-v2-GGUF:latest	ses\_01f0d1...	28,653	環境調査へ脱線	stop	timeoutをNode/MCP環境問題と推測し本調査に戻れず	タスク保持が弱い

実行回数の参考値

各ログの assistant turn / tool call を機械的に数えると、GLM は26 turn・51 tool call、Ornith は18 turn・20 tool call、32K Qwen 35B は18 turn・24 tool callだった。単にtool数が多ければ良いわけではない。GLMはshell errorや引数誤りを多数起こしながら前進した一方、OrnithとQwenは比較的少ない失敗で深い調査地点まで進んでいる。

---

各モデルの詳細

1. Qwen3.6 35B — 分析品質は最も有望、しかし「止まる」

対象:

• qwen3.6:35b-a3b — 32K実行
• qwen3.6-35b-a3b-128k:latest — 128K実行
• 別セッションの qwen3.6:35b-a3b — dataset root問題を自力解決

良かった点

Qwen 35B 系で特に良かったのは、severityだけを盲信しなかったことである。

データセットは18,858イベントで、highは1件、critは0件しかない。しかしQwenは、次の特徴を見て「highだけでは足りない」と判断した。

• File Deleted: 12,785
• File Created: 2,267
• Proc Access: 2,047
• med: 538
• Direct Autorun Keys Modification
• Hidden Executable in NTFS ADS
• New User Created via Net.EXE
• PowerShell dropper候補
• Run Keys persistence候補
• Proc Tampering
• Windows Defender Exclusions

32K版は明示的に「med以上のルールを詳細検証する必要がある」と判断し、strategyを med,high,crit に拡張した。これは今回のログ群で最も重要な分析判断の一つである。

また、Desktop上のCSVがMCPのallowed root外だった別セッションでは、エラー原因を特定したあと、CSVを /home/kali/mecha-hayabusa にコピーし、hayabusa\_switch\_dataset を成功させている。環境制約への対応力も比較的高い。

32K版が終了した理由

32K版の終了理由は明確である。

最終2回のturnがいずれも:

• total = 32,768
• finish = length

となっている。

しかも停止地点は Step 3.5。つまりskill本文、tool schema、profile、MITRE、rule title、state statusなどを保持した結果、本当に重要な個別トリアージへ入る頃には出力余地が消えていた。

このセッションについては、「モデルが途中で投げ出した」と評価するのは適切ではない。32K contextと長大なagent workflowの構造的不整合が主因である。

128K版が終了した理由

128K版は別の問題を示した。

当初は正しく18,858件、high=1、med=538、単一host、約10分の活動と認識していた。ところが後のturnでは突然、15,168件、49,006+102,534件、high=2など、stateと整合しない数値を自己要約へ混入させた。

それでも最後には、正しい18,858件ベースへ一部戻り、pending rulesと未判定clusterが残っていることまで認識した。しかし、その直後に:

「不明確な点を確認させてください、継続して調査を進めますか？」

と出力して stop した。

つまり、128K版の主問題はcontextではなく:

• 長い履歴中でのstate drift
• 自分の過去要約をsource of truthとして再利用する傾向
• 未完了でもユーザーへ制御を返す傾向

である。

評価

フォレンジック推論: 強い
tool利用: 比較的良い
長期state保持: 要改善
自律完遂: 弱点あり

今回もっとも「prompt/runtime側で直す価値が高い」モデルである。state.py check != PASS の間はfinal responseを禁止するcompletion guardが入れば、かなり改善する可能性がある。

---

2. Ornith 1.0 35B — 深く進むが、action直前で止まる

対象: aratan/Ornith-1.0-35B-uncensored-GGUF:q4\_K\_M

良かった点

Ornithの成功セッションは、今回の比較対象の中でもかなり深く進んだ。

• CSV load
• state init
• dataset profile
• strategy設定
• Step 3 rule title / MITRE / time window分析
• Step 3.5へ移行
• state.py status で 20 pending rules を確認

まで実行している。

最終turnでは43,746 tokensを扱っており、少なくとも32K版Qwenより長い作業履歴を保持できていた。

さらに終了直前の判断も適切だった。

20件のルールを5つずつSQLでサンプリングし、attack / false_positiveを判定する

という、skillに沿った具体的な次アクションを立てている。

問題点

一部でstateやskillの理解が揺れている。たとえば途中で「investigate_jp skillのinitコマンドは存在しないため手動初期化」と述べており、実際のskillにある state.py init との整合が弱い箇所がある。

ただし最終的にはstateを正常に初期化し、調査を継続できているため、致命的ではなかった。

終了した理由

最終的な失敗は非常に特徴的である。

モデルは:

1. pending 20件を確認
2. 5件ずつSQLで調べる方針を決定
3. 「まず最初の5件」と宣言
4. SQL tool callを発行せず stop

となった。

これはcontext不足を示す証拠はなく、action boundaryで自然言語を出したことでターン完了と判断してしまったケースとみるのが妥当である。

評価

フォレンジック推論: 強め
調査深度: 非常に良い
state利用: 概ね良い
自律完遂: action boundaryに弱い

Qwen35B-128Kと同様、未完了なら本文だけでturnを終えてはいけない というルールが効きそうなモデルである。

---

3. GLM-4.7-Flash — 完遂力は高いが、分析の深さが足りない

対象: glm-4.7-flash

良かった点

GLMは最も「エージェントとして粘った」モデルだった。

実行中に:

• state.py cluster引数誤り
• host関連の引数誤り
• analyze\_host\_timeline の必須引数不足
• report生成CLIの誤用
• reports directory不存在

など、多数の失敗を起こした。それでも修正を試み、最終的にはstate gateをPASSさせ、HTML生成に失敗した後も手動の日本語レポートへfallbackした。

失敗しても次の手段を試す能力は今回のモデル群で最も強かった。

分析品質上の重大な問題

一方、ユーザーが指摘した通り、内容の質には問題がある。

GLMは調査対象レベルを基本的に high,crit のまま維持した。highは1件だけであり、そのイベントは:

• Rule: Disable Windows Defender Functionalities Via Registry Keys
• Process: MsMpEng.exe
• User: NT AUTHORITY\\SYSTEM

だった。

GLMは、Microsoft Defender自身のプロセスであることを主根拠に、この1件を false\_positive と判定した。その後cluster c1も benign とし、最終的には「攻撃的な活動の明確な証拠はない」と結論づけた。

問題は、同じデータセットに存在する大量のFile Deletedや538件のmed、Autorun、ADS、PowerShell、Proc Tamperingなどについて、Qwenのように調査範囲を拡張して十分な個別検証を行っていない点である。

つまりGLMは:

**gateを通すための調査は完遂したが、incident hypothesisを覆す・支持するための広い証拠検証が浅かった**

と評価できる。

state.py check PASS そのものも、strategyが high,crit に限定されていれば、その狭いスコープについてPASSするだけである。したがって、coverage gateのPASSと「正しいフォレンジック結論」は同義ではないことをこのログは示している。

終了した理由

GLMは実質的には完遂している。

正式なHTMLレポート生成には失敗したが、そこで停止せず、手動Markdown形式のレポートを最終回答として返して stop した。

評価

フォレンジック推論: 弱〜中
tool精度: 低い
エラー復旧: 非常に強い
完遂力: 非常に強い

「何かを最後まで返す」用途には向くが、SOC/DFIRのように結論の質が重要な用途では、完遂率だけで選ぶべきではない。

---

4. Qwable-v2-128k-t0 — 調査は進むが、未裏付けのストーリーを補完する

対象: qwable-v2-128k-t0:latest

行動

skill名を最初に誤って load-all として失敗したが、その後 investigate-jp のloadには成功した。

さらに誤ったCSVパスへのswitchに失敗したあと、正しいdataset profileを取得し、rule title / MITRE / time window分析まで進んだ。

ここまでは復旧できている。

分析上の問題

終了直前のreasoningでは、取得した情報を超えて:

• attacker側でのtimestomping
• stolen AD admin token
• admin impersonation
• staging tools

など、ログで十分に裏付けられていない具体的な攻撃ストーリーを組み立て始めている。

今回のデータは単一host user1、約10分のイベントであり、この時点のtool結果だけからそこまで具体的な侵害シナリオを確定するのは危険である。

終了した理由

モデル自身は次にstate directoryを確認すべきだと理解していた。しかし最後に:

"Current date ..." \&\& ls -la ...

という実行すべきshell commandを通常のtextとして出力し、そのまま stop した。

つまりtoolの概念は理解しているが、自然言語生成とtool executionの境界制御に失敗した。

評価

分析の慎重さ: 弱い
エラー復旧: 中程度
tool境界: 弱い
自律完遂: 弱い

---

5. Qwable-v2-128k-default — 長い計画を立てるが、実作業へ落とし込めない

対象: qwable-v2-128k-default:latest

傾向

このモデルは非常に長い内部計画を生成し、複数subtaskの並列化を試みた。しかし、task toolに渡すべきsession IDの形式を誤り、Expected a string starting with "ses" を繰り返した。

その後も「full sequenceをretryする」「initとrule collectionを並列化する」といった計画は詳細に述べるものの、実際のHayabusa調査へ十分移行できなかった。

終了した理由

subtask orchestrationのエラー後に、計画の再説明へ入り、実作業を発行せず stop した。

評価

計画生成: 多い
計画→実行変換: 弱い
tool orchestration: 弱い

長文で考えている量と、実際の作業進捗が一致しないタイプだった。

---

6. Qwen3.6 27B 128K — contextはあるが、Step 1でサイレント停止

対象: qwen3.6-27b-128k:latest

skillを全文に近い形で読み込み、開始時刻を記録し、glob で /home/kali/mecha-hayabusa/hayabusa-results.csv を正しく発見した。

ところが、その直後のassistant turnは:

• input: 35,207
• output: 1
• finish: stop

で終了した。

128KモデルIDであり、観測時点は約35Kなので、少なくともログ上は「128Kを使い切った」形ではない。

終了した理由

明示的なtool errorもなく、次に switch\_dataset を行えばよい状態だった。したがってこれはcontinuation failure / silent early stopと分類するのが妥当である。

評価

このセッションだけではフォレンジック分析品質を評価できない。agentとしては、長いskillを読んだ後に行動継続できなかった点が弱い。

---

7. Mannix Qwen3.6 27B A3B Coder — 初期分析は妥当、tool syntaxで破綻

対象: mannix/qwen3.6-27b-a3b-coder:Q8\_0

良かった点

profileから:

• 18,858 events
• 約10分
• user1のみ
• high=1
• mass file operations

を正しく把握し、synthetic/testの可能性も含めて慎重に仮説化していた。

問題点

state directory作成後、state.py init をBash toolで実行すべきところ、commandそのものをtool名のように生成し、invalid toolへ流してしまった。

モデル自身は次turnで:

bash toolを使う必要がある

と誤りを認識していたが、実際のBash callを発行する前にセッションが finish: unknown で終了した。

評価

初期分析: 中〜良
tool syntax adherence: 弱い
復旧: 意図はあるが未実行

Coder系という名前に反して、今回のagent tool protocolでは構文境界が不安定だった。

---

8. Qwable-v2-GGUF — 環境トラブルシュートへ脱線

対象: hf.co/lordx64/Qwable-v2-GGUF:latest

このセッションではskillをloadした後、以前のoperation timeoutを「Node watch processやMCP serverが詰まっている可能性」と推測し、pkill、top、pgrep node など環境調査へ進んだ。

問題は、ユーザーの本来の目的であるHayabusa調査へ戻らなかったことだ。

最後は短い不正なmarkup風の done を出力し stop している。

評価

障害原因の仮説形成: ある
task focus: 弱い
Hayabusa分析性能: このセッションではほぼ評価不能

環境問題を見つける能力より、「環境問題は手段であり、本来の調査へ必ず復帰する」というtask invariantが不足していた。

---

9. qwen3.6:35b-a3b のdataset-root対応セッション

このセッションは最終的なフォレンジック分析へ入る前にログが途切れたため、独立した性能評価には使いにくい。ただしagentic behaviorとして重要な観察がある。

指定CSV /home/kali/Desktop/hayabusa-results.csv がMCP allowed root外で拒否されると、モデルは:

1. エラー内容からallowed rootを把握
2. default root内のdatasetを確認
3. BashでCSVをプロジェクト配下へコピー
4. hayabusa\_switch\_dataset を再実行
5. load成功

まで自力で進めた。

したがってQwen35Bは、明確な環境制約がtool errorとして返れば、それを解決する実務的な能力は高い。ただしload成功直後にfinish情報なしでログが途切れており、それ以上の評価はできない。

---

モデル横断で見えた傾向

1. 「分析品質」と「完遂力」は別能力

最も顕著なのはQwen 35BとGLMの対比である。

Qwen 35B

• highだけでなくmedへ調査範囲を広げる
• mass deletionと複数の攻撃候補ruleを関連づける
• pending ruleを個別検証しようとする
• しかし途中でlengthまたは自発stop

GLM

• tool errorが多くても最後まで進む
• gateをPASSさせる
• 最終レポートを返す
• しかし調査範囲が狭く、benign結論が早い

したがって、DFIR agentを評価するときに「reportが出たか」だけを成功指標にすると、分析の浅いモデルを過大評価する危険がある。

---

2. state.py check PASS だけでも十分ではない

state.py によるcoverage gateは非常に有用だが、strategy自体が狭ければ、その狭い範囲でPASSできる。

GLMは high,crit を中心に調べ、high 1件をfalse positiveにしたうえでgateを通した。しかしQwenは同じデータを見て、538件のmedを無視すべきでないと判断した。

したがってcompletion条件は:

state.py check == PASS

だけでなく、たとえば:

高頻度のinfo/low/med活動がincident hypothesisと整合する場合、
severityが低いことだけを理由に調査対象外にしてはならない

というinvestigation scope quality gateも必要になる。

---

3. 128Kにしても「勝手にstop」は直らない

32K Qwenでcontext不足が明確だったため128K化は必要である。しかし128K Qwen、Ornith、Qwen27-128Kを見ると、contextに余裕があっても自発stopは発生している。

したがって必要なのは:

• 大きいcontext window
• state source-of-truth
• completion contract
• stop guard

の組み合わせである。

---

4. 自然言語で「次にやること」を言った瞬間が危険

複数モデルに共通していた。

• Ornith: 「まず最初の5件」→ SQLを呼ばずstop
• Qwable-t0: Bash commandを本文として出力→stop
• Qwable-default: retry計画を長文で説明→実行せずstop
• Qwen128K: pendingを認識→「続けますか？」→stop

agent promptでは、次のルールが非常に重要になる。

**未完了状態で次のactionが明確なら、それを説明するだけでturnを終了してはならない。同一turn内で実際のtool callを発行すること。**

---

実運用での優先順位

今回のログだけを材料に、Hayabusa investigate-jp のような長時間DFIR agent用途で並べるなら、次のようになる。

第一候補: Qwen3.6-35B-128K + completion guard

理由:

• 調査範囲拡張の判断が良い
• mass file activityをseverityだけで切り捨てない
• tool利用も比較的安定
• 128Kで32Kの物理的制約を回避できる

弱点は「勝手にstop」とstate driftなので、モデルそのものを変えるよりruntime guardで補う価値が高い。

第二候補: Ornith 35B + action guard

調査深度は良い。少なくとも43Kまで長い履歴を扱い、Step 3.5の正しい作業計画まで進めた。

終了直前のaction boundaryを強制すれば改善が期待できる。

第三候補: GLM-4.7-Flash（フォールバック役）

完遂力とエラー復旧は非常に強い。しかし単独で最終判断者にすると、今回のように「調査を終えたが内容が浅い」という危険がある。

使うなら:

• primary investigatorではなくreport/fallback agent
• Qwen等が作ったstate/findingsを最終文書化する役

の方が適している可能性がある。

---

推奨する改善方針

Completion Contract

ユーザーは最初の依頼時点で調査完遂を承認済みである。
調査途中で「続けますか」「次に進みますか」と尋ねてはならない。

state.py check が PASS でなく、かつユーザーが明示的に中断を求めていない場合、
final responseを返してはならない。

次の必要actionが明確な場合、自然言語でactionを説明するだけでturnを終了してはならない。
必ず同一turn内でtool callを実行する。

State Source of Truth

事実の優先順位:
1. state.pyのcanonical state
2. 現在ロード中datasetのdataset\_profile
3. 直近のMCP result
4. assistant自身の過去要約

4をsource of truthとして使わない。
イベント件数やpending数に矛盾が出たら、推測せず1または2を再取得する。

Scope Guard

high/critが少ないことだけを理由に調査を終了してはならない。
大量のmed/low/info活動がincident hypothesisと関連する場合、
代表ruleとdetailを検証し、調査levelを拡張するか明示的に棄却理由をstateへ記録する。

この3つを入れることで、今回Qwen 35Bで確認された主な問題の多くをモデル変更なしで抑制できる可能性がある。

---

最終評価

今回の実行ログからは、「完遂したGLMが最高性能」「止まったQwenは低性能」ではない。

むしろDFIR用途では:

• GLM: 完遂性は高いが、証拠評価の深さが不足
• Qwen3.6 35B: 証拠評価は良いが、context / stop controlが弱い
• Ornith 35B: 深く進むが、次action直前のstopが弱い
• Qwable系: tool orchestrationやtask focus、事実拘束に課題

という違いが見える。

現時点で最も実用的な方向は、Qwen3.6-35B-128Kを分析主体にし、state.py check と独立したcompletion guardでstopを制御することである。さらにGLMのような完遂型モデルをreport fallbackとして分離すれば、分析品質と完遂性を両立しやすい。

---

参照ログ

本稿は以下のアップロード済みOpenCode session JSONを根拠としている。

セッションID	モデル	備考
ses\_01f0194afffeLhfrX9iresITjK	qwable-v2-128k-t0:latest	Step 3後にtext-only commandでstop
ses\_01e8f2ea8ffeY9I00h8B7pVEXF	mannix/qwen3.6-27b-a3b-coder:Q8\_0	invalid tool後 finish: unknown
ses\_01f162150ffe1YaoWag31LRq5K	qwen3.6:35b-a3b	dataset root問題を解決後ログ途絶
ses\_01f12745affelP844DJWAnZDkT	qwen3.6:35b-a3b	32,768 tokensで length
ses\_01ef4168bffewV0jjrG1XbhPVg	qwen3.6-35b-a3b-128k:latest	pending認識後に確認質問でstop
ses\_01ef8fe6bffe0bpxNWnU9su3PB	qwable-v2-128k-default:latest	task orchestration失敗
ses\_01eee4721ffeoZr1jarVcBet6H	qwen3.6-27b-128k:latest	glob成功直後にstop
ses\_01e95e1b2ffeoNnw9LQBOjXswQ	aratan/Ornith-1.0-35B-uncensored-GGUF:q4\_K\_M	Step 3.5、20 pending確認後stop
ses\_01ebb7374ffegTZms5fdg1jhCe	glm-4.7-flash	gate PASS、手動レポートまで完遂
ses\_01f0d1eb0ffenXMZGb0ZdDZmVe	hf.co/lordx64/Qwable-v2-GGUF:latest	環境調査へ脱線してstop

比較から除外したもの

MessageAbortedError の6セッションは、モデルが調査をどこまで実行できたかよりruntime側の中断影響が大きく、今回の「モデルが自らなぜ終了したか」という分析から除外した。

また、ses\_01f201719ffeGUXgMownyr97U0 (qwen3.6-35b-a3b-128k-t0:latest) はHayabusa調査ではなくMCP種類の質問であり、同条件比較から除外した。