Blog // 技術記事
KRS-OS の設計・導入ノート・技術解説・事業記録。R&Dのケーススタディとして、 エージェント基盤の推論・自己検証・運用の実例を積み上げています。
「誰が操作したか」をどこに持たせるかで、設計の向きを間違えかけた話
横断監査ログを作ろうとして、ログイン情報を持つ画面層に保存先を直接持たせかけた。実装前にモジュール間のimportを確認し、既存の別機能が同じ問題を「識別子をリクエストの中身として運ぶ」形で既に解決していたことに気づき、その型をそのまま流用した記録。
curlは繋がるのに、Dockerのpullだけがタイムアウトした話
コンテナのビルドがTLSハンドシェイクのタイムアウトで止まった。DNS解決、候補IPすべてへの個別疎通、プロキシ設定、大容量ダウンロード——定番の原因を`curl`で一つずつ潰していったがどれも正常。それでもDockerのpullだけが失敗し続け、疑うべき場所がネットワークからアプリケーション層へ変わった記録。
接続はできるのに応答が空だった — 2つの間違った仮説の後、カーネルの状態を見て気づいた話
直結した2台構成で、片方からもう片方のローカルLLMサーバーへアクセスすると、TCP接続はできるのに応答が一切返らない現象にぶつかった。バインド設定、NATのhairpin問題と2つの仮説を順に試してどちらも外れた後、カーネルの接続状態を直接見ることで、実はネットワーク層ではなくアプリケーション側の接続元許可リストが原因だったと分かった記録。
systemdは「稼働中」と言い張っていたが、ソケットファイルは消えていた
同じマシンに二重インストールされていたDockerの片方を削除したら、残した方まで動かなくなった。systemctlは終始「active (running)」と表示し続けていたが、実際には肝心のソケットファイルが消えていた——ステータス表示を信じるだけでは気づけない壊れ方だった話。
制限環境で本当にLoRAは学習できるのか、実機で確かめるまでの話
生成AIが書いたコードを実行するサンドボックスで、環境変数を絞る許可リスト方式を検証していたが、これまでは「読むだけ」の処理しか試していなかった。実際の学習ループまで実機で確かめたところ、途中で無関係なパッケージ不足を「サンドボックスのせい」と誤解しかけた——比較の基本に立ち返って原因を切り分けた記録。
前の工程が何というファイル名で保存したか、後工程のAIは知らなかった
分析タスクを2つの工程に分け、それぞれ別プロセスとしてコードを書かせて実行する仕組みを作った。設計は紙の上ではきれいに閉じていたが、実機の本番モデルへ実際にコードを書かせてみたところ、2つ目の工程が「1つ目の工程が保存したファイル」を毎回もっともらしいが間違った名前で探しに行き、失敗し続けた。原因は「前工程の出力を実行前に一括で生成していた」こと——後工程には前工程の実際のファイル名を知る手段がなかった。設計レビューでは絶対に見つからなかった話。
証拠は溜まり続けていたのに、誰も見ていなかった — 「生きた配分」を閉じた話
ローカルとクラウドの答えを裏で比較し、一致率が高くなったらローカルを主力に切り替える——という設計の核心部分で、比較の証拠を記録する仕組みと、証拠を使って実際に切り替える仕組みが別々に作られていた。片方は完成しテストも通っていたが、判定結果を受け取って実行する経路がどこにも存在しなかった。単体テストでは原理的に見つからないこの手の欠落を、設計の全体像に立ち返って見つけた記録。
最後の1回だけ、もっと強いモデルに任せる — 認知ティアに3段目を足した話
失敗したタスクは自動で最大3回まで再試行する。だが2回目のリトライも3回目(最後)のリトライも、これまでは同じ強さのモデルに割り当てられていた。3回目は諦めて計画を立て直す一歩手前の、一番コストの高い失敗だ。「何回目の挑戦か」をもう一段細かく見て、最後の1回だけさらに強いモデルに切り替える仕組みを足した。その前提として、LLM通信そのものに指数バックオフ付きの軽いリトライを先に用意しておいた話も併せて書く。
Workerを増やしても速くならなかった — 仕様書に書いた並列化が実装されていなかった話
「Worker Poolのサイズを増やせば並列実行される」と自分で仕様書に書いていたのに、実装を読み返すとWorkerを何体増やしても一切並列化されていなかった。実行ループが「1回呼ぶと1タスク終わるまでブロックする」作りのままだったのが原因。既存の呼び出し契約を1つも壊さずに並列実行を足す過程で、以前と同じ形の競合状態をもう一箇所で見つけて塞いだ記録。
プロンプトのリレーで消えるもの: データ・履歴・メトリック
同じ形のバグを3回踏んだ。1回目はデータファイルの存在が消え、2回目は試行履歴が消え、3回目は「balanced accuracyを使え」という評価指標の指定がplain accuracyにすり替わって消えた。3つを並べてようやく、これは個別のバグではなく「LLMが言葉を言い換えて次に渡す」というリレー構造そのものが持つ不可逆な劣化だと気づいた。直し方はどれも同じ形をしていた——事実は経由させず、必要になる直前に記録から直接読み直す。
『Titanicの分析』のはずが、モデルはMNISTを学習していた
自律エージェントにTitanicの生存予測を頼み、本物のCSVを渡した。何回か試行を重ねた末、それらしい精度が返ってきたが、以前ダミーデータで試したときと桁まで一致するスコアに違和感を覚えて中身を確認すると、モデルは渡したファイルを一度も開かず、代わりにMNISTを勝手にダウンロードして学習していた。原因は「依頼から実際のコードが書かれるまでにLLMの言い換えを4段階挟んでいる間に、具体的な事実がリレーの途中で蒸発する」という構造的な劣化。ファイルシステムから直接読んだ事実をコード生成の直前に差し込むことで直し、無視した場合の検出層も足した記録。
UIだけ引退させる — 旧システムを止めずに新ダッシュボードへ統合する読み取り専用ブリッジ
新旧2つのシステムが並走し、新に綺麗な管理画面、旧に本物の実力(蓄積した知識と実データ)がある状態になった。統合したいと考えた時、まず「旧UIを引退させる」と「旧エンジンを引退させる」は別の話だと気づいた。前者は今すぐでき、後者はまだできない。旧エンジンを裏で動かしたまま新UIが旧データを読むだけの読み取り専用ブリッジを作った。実機に載せて初めて「本物のデータはテスト用の捏造データと形が違う(キーの使い方が違う)」という罠を踏んだ記録も添えて。
依存フリーで運用コマンドセンターを育てる — 単一ASGI・ui→apiのみ・電気代まで
素っ気ない箇条書きだけの管理画面を、CPU/GPU/RAMの実測ゲージや電気代まで出るダークテーマの運用コマンドセンターに育てた。方針は徹底して依存フリー — 新規SPAもStreamlitも足さず、既存のサーバーレンダHTMLのまま拡張し、外部CDNもJSフレームワークも使わない。「画面はAPI経由でしか状態を読まない」という一本道を守ったまま、素のSVG・1つのkeyframe・meta-refresh・小さなfetchだけでどこまで作れるか。優雅に劣化させる設計で開発機と実行ノードに同じ画面を載せた話。
エージェントの実行ループを「配管」として描く — SVGパイプラインUI
自律エージェントの実行ループを、最初は箱を4つ並べたステッパーで可視化した。動くけれど、やり直しが起きて先頭に戻るループ構造が平らな一列では表現できず違和感があった。作り直して、ケーシングと流体が流れる本物の配管みたいなSVG図にした。パイプに液が流れるアニメーション、reflectバルブから元に戻る/抜ける分岐、複数コンペが枝分かれするマニフォールド、実行中だけ自走する自動リフレッシュ。ライブラリなしで「今なにをして、なぜ止まったか」を一目で掴める画面にした設計の記録。
「完了」と宣言した直後に見つかった3つのバグ
段階を区切って進めてきた移行作業が終わり、テストも全部通った状態でもう一度全体を読み返したら、実害のあるバグが3つ見つかった。時系列に記録を読み出す処理が過去のエラー情報を消し忘れて安全装置を誤動作させかけたケース、採番と保存が別操作になっていたことで将来の並行実行で忍び込む競合状態、プロセスをkillしようとしたらもう死んでいて例外でクラッシュするケース。どれも「テストが通っている」は「バグがない」の証明にならないという教訓の記録。
移植の途中で「これは移植すべきじゃない」と気づいた話 — 終わらない移行を終わらせる
既存システムの実行ロジックを新基盤に移す作業を8段階に分解して1日で進めた。最後の1段だけ、ファイルを開いたら他の何倍もの規模で、しかも中身は独立したサブシステム群への入り口だった。その中に、以前「使うべきではない」と結論づけたばかりの手法が紛れ込んでいた。「忠実に移植する」を貫くと過去の負債まで運び込むことになると気づき、移行の「完了」の定義そのものを書き直した記録。
「参照する」をやめて「載せる」にした一日 — KRS-Nexus と KRS-OS の関係を決め直した話
Docker で初めてコンテナを起動し、空の画面が出たところで満足しかけたが、それは何の検証にもなっていないと指摘されてやり直した。実データを1件差し込み、ブラウザで承認ボタンを本当にクリックして、UI からストア層まで一気通貫で動くことを確認した話。同じ日に、別々に育ててきた2つのプロジェクトの関係を2回作り直し、「土台の上に認知アーキテクチャを1枚載せる」3層構造に着地。frontmatter 付きの技術ノートをスキーマ変更ゼロで知識グラフに接続する最初の一歩まで実装・実データ検証した記録。
Public LB 14 位 → Private 405 位。shake-up の本当の怖さを味わった話
playground-series-s6e6、締切直前まで Public LB 0.97265 / rank 14 (Gold 境界線) にいたが、Private LB 確定で 0.97002 / rank 405 (2309 チーム中) に転落、Bronze にも届かなかった。スコアの下落幅 (-0.0026) は事前予測通りだったが、rank の落差は桁違い。公開資産を土台にした row-flip 系の攻めは崩壊、自前 CV で検証した保険の ensemble は Public→Private 差 -0.0006 とほぼノイズ範囲で健全だった。「流行している手法は個性ではなく集団リスク」「CV で殻を割った改善は予測可能性が高い」という、shake-up の実物から得た教訓の記録。
TabPFN を本番投入したら罠が 2 つあった — Foundation NN の domain mismatch と HF anonymous DL hang
s6e6 で TabPFN-v3 を 5-fold OOF で検証。CV 0.96152 / LB 0.94691 と gap 0.0146 という異常な乖離、α=0.1 blend ですら voters 0.972+ → 0.952 に劣化。技術的な罠 2 連発: (1) huggingface_hub の anonymous DL が hang する (curl 36 MB/s でいけるのに) のを prefetch helper で回避、(2) Foundation NN の synthetic prior が astronomy real data と不一致、subsample 増では解けない構造的限界。「Foundation Tabular Model なら何でも上がる」と思考停止せず最初の 1 fold で必ず LB を測れ、という記録。
1 日で 4 機能が回り出した KRS-OS — 並列開発を支える疎結合な設計
朝 0 commit、夕方 5 commit。Planner プロンプトに meta-pattern 機械評価で注入 / Gap 2 Optuna 統合本実装 / cv_lb_log → LinearLBPredictor factory 配線 / TabPFN-v3 playbook の 4 機能が同じ日に独立に進んだ話。これがたまたまではなく、「並走パスを追加する」「Protocol で疎結合にする」「機能フラグ的なオプション引数」の 3 つの設計選択を 2 ヶ月積み上げてきた結果という分析。1 つの実験 (TabPFN s6e6 投入) が失敗しても他 3 機能の価値は残る、エージェント開発の重要な性質。
Silver まで 1 千分の 1 で届かなかった話 — vote 飽和と diversity の見極め
s6e6 で 10/10 quota を使い切って LB 0.97226 (top 6.0%) で着地。Silver cut 0.97227 まで 0.00001 short。alpha sweep の完全飽和、own 3 GBDT の +0.00201 貢献、acquirer 緩和が augmented data leak で -0.00180 した話、そして「自前 stack < 公開単体 submission」が実証された 10 提出の診断記録。
Obsidian Skill ライブラリの品質管理 — 重複排除・品質スコア・MOC 自動生成の 3 層機構
LLM 抽出で蓄積した 721 件の skill が荒れていた問題。"TargetEncoding with smoothing" 38 件重複、v8 メタフィールドが 0.8% しか埋まっていない状態を、正規化タイトル dedup (CamelCase 対応) + quality_score (0-1 合成) + MOC 自動生成の 3 層機構で整理。9.4h 夜間バッチで 595 件全 v8 化、meta_pattern 比率 1% → 82%、mean quality 0.36 → 0.68 へ。
Bronze は自走できる、Gold は構造投資が要る — 汎用 Kaggle OS の 2 つのギャップ
s6e6 で Bronze (top 6.91%) まで自走できたが Gold は構造的に届かないことが確定。原因は skill 粒度が「kernel の塊」のままで meta-pattern に抽象化されていない事と、AutoML 探索ループが無い事の 2 点。「コンペ専用チューンを書く」から「チューンを生成するエンジンを書く」への方針転換宣言。
「強い NN を 1 つ足せば Silver 圏」と踏んで pytabkit を導入したら届かなかった話
Bronze 圏で stuck したコンペに RealMLP_TD (n_ens=1→4) を投入したら、OOF 0.948→0.952 で GBDT すら下回り stack には -0.00006 の汚染。汎用「Tuned Defaults」と競技専用チューンの 0.018 ギャップを実機で測った夜の記録、と再利用可能な playbook ラッパとして残した話。
1 日で Kaggle 順位を 49% → 5% に圧縮した手数の分解
メダル対象コンペで朝 rank 1026/2076 (top 49%) → 24h 後 rank ~110/2109 (🥈 Silver 圏 top 5%) まで上げた。午前は自前モデル強化で +0.004、午後は公開資産取り込みの構造改造で +0.004。Gold cut まで残 +0.00033。手数を LB 推移と一緒に分解した記録。
balanced_accuracy で hill_climb が頭打ちした時、stacker を作り直して +0.003 取った
hill_climb (確率平均) を多項ロジスティック回帰 (prob → logit) stacker に置き換えたら、同じ 3 base model から OOF が +0.0096 跳ねた。なぜ prior-agnostic な指標 (balanced_accuracy / macro_f1) で確率平均が頭打ちするか、logit 空間で何が起きているかの数学的説明と PyTorch 実装。
コンペの公開知識資産を自動で取り込む — 外部OOF統合モジュール
top kernel をスキャンして参照されている公開 OOF dataset を自動 DL、6 種類の異種フォーマットを統一形式に正規化する Python モジュールを実装した。検証コンペで LB +0.003 取った。Kaggle ToS との関係、loader のヘテロ対応、score フィルタの設計についてまとめた。
公開 OOF だけじゃない — score 付きハードラベル submission の山を加重多数決した
ファイル名がそのまま LB スコアになっている submission CSV のアーカイブ (`0.97220.csv` 形式) を加重多数決して自分の stack と blend するモジュールを実装、LB +0.00155 で Silver 圏 (top 5%) 突入。直接 submit は ToS 違反なので、API 設計レベルで「集約 + blend」を強制する話を含む。
1 日で 0.954 → 0.964 まで上げた 4 つのレバー (Kaggle s6e6 中央超えへの階段)
メダル対象の 3 クラス分類コンペで、baseline 0.95459 から strong3 0.96376 まで +0.00917 積み上げて中央値を超えた話。色等級 FE / 3-seed avg / XGBoost 追加 / per-class calibration の 4 段それぞれの CV と LB の上げ幅、何が一番効いたかの内訳付き。
per-class calibration が balanced_accuracy で『一番効いた小さな手』だった
3 クラス分類 + Balanced Accuracy で CV を +0.005 押し上げた一番大きいレバーは、argmax 直前で各クラスの確率に倍率を掛けるだけのコード 10 行のテクニック。なぜ効くか、grid search の刻み、stacking と比べてなぜ刺さるかをまとめた。
sklearn 1.8 で LogisticRegression の multi_class が消えていて、2 時間 27 分の計算が死んだ
3 モデル × 3 seed × 5 fold の 45 fold が完了した直後、最後の stacking で LogisticRegression(multi_class='multinomial') が TypeError。sklearn 1.8 で警告なしに削除されていた。OOF を mem-only で持っていた設計が被害を拡大した話と、リカバリの 50 分間。
Metric-as-SSOT 改修が、実 LB で『中央値超え』として実証された
前日に入れた『指標を単一の真実として全ノードに伝播する』改修を、quota 復帰後の late-submit で実証。public 0.94145 → 0.94869 (+0.00724) で実 LB で中央値を超え、CV-LB gap は 0.00025 で収束。机上の改修が実 LB で 1 対 1 の結果として返ってきた話。
5 連続 SubmissionStatus.ERROR が教えてくれた、多クラス文字列ラベルの SSOT 漏れ
二値で動いていた自律システムを 3 クラス分類 (GALAXY/STAR/QSO) + Balanced Accuracy のメダル対象コンペに投入したら 5 連続 ERROR。Metric-as-SSOT の『多クラス + 文字列ラベル + 評価指標バリエーション』の盲点が同時露呈した。テンプレ・CV・LabelEncoder の 3 点を直して valid 提出にたどり着いた話。
『パイプラインが固まった』の真犯人は深夜の知識収集タスクだった
自律 Kaggle システムが analyze 直後で 30 分沈黙。LLM 推論待ちかと思ったら、別プロセスの日次 harvest が deepseek-r1:70b の
正規表現が、自分自身が挿入したヘルパ関数を再帰化させていた
iter1 は CV 0.949 で成功するのに iter2-6 が 0.8 秒で即死。RecursionError の原因は sanitizer の正規表現が 2 周目の sanitize で自分が挿入したヘルパ本体まで置換してしまうこと。冪等性テストはあったがサンプルが網羅されていなかった話。
0/1 が float で入っていただけで、二値分類が回帰として解かれていた
自律 Kaggle システムを初めて実データ(終了済 Playground Series, 二値分類 AUC)で end-to-end 実行。LB 0.94145 を取ったが、解剖したらタスクが丸ごと回帰で解かれていた。原因はターゲットが 0.0/1.0(float)だったこと。しかも素直に直すと悪化する——指標を単一の真実にする改修の話。
自己対戦で 62% 勝つ bot が、本番ランキングでは負けていた
カードゲーム bot の「CV の代わり」に自己対戦勝率を使っていた。その指標では Monte Carlo が hybrid に 62% 勝ち越したのに、本番の動的レーティングが収束したら逆転(hybrid 679 > MC 568)。代理指標が本番分布とズレると、ローカルの強さは転移しない、という話。
『学習した価値関数』でカードゲーム bot を強くしようとしたら、Monte Carlo に負けた
GPU を解禁して AlphaZero-lite(value-first)を実装。価値NN は val AUC 0.834 まで学習できたのに、その価値で手を選ぶ bot は MC にも greedy にも負けた。「勝率を当てられること」と「勝てる手を選べること」は別物——value-first の近視眼を実測した話。
自己対戦でカードゲーム bot を磨いたら、計算量もデッキもヒューリスティックも全部『頭打ち』だった
supervised 専用の自律 Kaggle システムが初めてエージェント系コンペに遭遇。random→greedy→hybrid→determinized Monte Carlo とボットを積んで LB 中央値超えまで到達。だが計算量・デッキ・サブ決定の3レバーが全部頭打ち。単純探索の天井を実測し、学習評価へ向かう話。
修理した知識ループを seed 9コンペで初めて1周させた — kernel +73 / discussion +27 skill
no-op だったハーベストと 403 だった discussion を直したあと、9コンペで初の end-to-end 1周。 kernel +73 / discussion +27 skill、349 件を DB sync。所要2時間、律速は 70B 抽出。直すと結実するは別、という話。
1枚の GPU を LLM 推論と学習で共有する — VRAM を測って足りなければ CPU に落とす
ハーベストの 70B が VRAM をほぼ専有する隙に GPU 学習を起動すると即 OOM。実行のチョークポイントで 空き VRAM を preflight し、足りなければ CUDA/HIP を隠して CPU で完走。落とすより遅くても完走、という割り切り。
FT-Transformer を ensemble の第3系統にする — 木でも MLP でもない予測のクセを足す
GBDT と MLP だけだとクセが2系統。特徴量間 attention を持つ FT-Transformer を純 PyTorch で実装し、 ブランチ探索が低相関の第3メンバーとして自動注入。合成データで回帰は MLP を上回り、保存契約も満たす。
ピン留めした CLI が discussions を黙って 403 にしていた — 本体を上げずに一機能だけ逃がす
一覧は通るのに discussions だけ版固有で 403。本体 CLI は据え置き、その機能だけ別 venv の新版バイナリに env で逃がす可逆策。提出が SDK 経由だと分かり影響を最小化。メダル解法の write-up が取れるように。
自作の知識ハーベストが数週間 no-op だった — タイマーは回るのに何も学んでいなかった
「上位解法を毎週マイニングして skill 化」する機構のログを見たら competitions_found=0 が数週間。 締切フィルタ / フル URL / CLI 警告行 / votes=0 の連鎖バグを全部直すまでの記録。動いて見える自動化を疑う話。
GBDT と拮抗する NN を ensemble に効かせる — 弱い多様性は一票も入らない、そして float 精度の罠
木と低相関の NN を混ぜたいが、弱いと貪欲ブレンドに採用されない。ターゲット標準化で拮抗精度にし、 さらに float32/64 のラベル精度差で blend から黙って除外されるバグを潰すまで。NN が 0.25 の重みを獲得。
CV-LB ギャップの真犯人は「古い OOF の混入」だった — 評価プールを毎回クリーンにしたら LB が伸びた
多様性不足が真因だと思って検証したら仮説は外れ、副産物で真犯人が見つかった。OOF プールが run 跨ぎで クリアされず、数日前の trial が ensemble に混入し固定ラベルへ overfit していた。消すだけで LB が更新。
多様性は「精度が拮抗して初めて」効く — 弱い線形モデルは ensemble に一票も入らない
GBDT に異系統を混ぜれば効くはず、を検証。CV 0.1486 の弱い線形は hill climbing に重みゼロで無視された。 前処理を尽くして RidgeCV で 0.1330 まで拮抗させたら、ようやく 1/3 の重みを獲得した話。
ensemble が効かない真因は「探索の多様性不足」だった — GBDT ばかりの自動探索に線形モデルを混ぜる
重みをどう正則化しても LB が動かない。真因はブレンドする中身が全部 GBDT で似すぎていたこと。 探索方向がぜんぶ GBDT だった自動探索に「異系統モデル」方向を足し、LLM が実際に Ridge を書くまで確認した話。
ensemble の重みを「均等寄り」にしたら LB が悪化した — CV を下げ切らない正則化の実証
CV に overfit した ensemble の重みを uniform shrinkage で均したら、CV 維持のまま LB が 0.12807→0.12847 と悪化。 重みが偏るのが正しいケースでは均等化が害になる。正則化は default 無効にし、真因は多様性だと特定した記録。
CV で圧勝した ensemble が LB に出てこない — 犯人は出力 CSV の「列名 1 つ」だった
ブレンドも提出もログ上は全部成功、なのに Kaggle 採点だけが ERROR。値は健全だった。 犯人は出力ヘッダが Id,pred のままで、正しい Id,SalePrice になっていなかったこと。sample_submission から列名を解決して解決した話。
CV で圧勝した ensemble が、LB では single と引き分けた — hill climbing が最適化していたのは「CV」だった
CV では ensemble 0.12458 が single 0.12808 を大きく上回るのに、LB ではほぼ引き分け。 貪欲ブレンドが最適化しているのは LB ではなく CV。CV 改善が LB に転写されない CV-LB ギャップを実スコアで観測した記録。
RX 7900 XTX に ROCm 版 PyTorch を入れて Kaggle Agent の画像/NLP を GPU 解禁する — hf-xet が NAT 越しでハングする地雷つき
torch/timm/transformers がそもそも入っていなかった環境に、システム ROCm に合わせた wheel を入れて GPU を解禁。 一番ハマったのは torch ではなく hf-xet が NAT 越しで 49 分ハングする件。dry-run で爆風半径を測り、実テンソル演算まで確認する手順。
全 trial の特徴ベースを底上げする『決定的 Feature Store』— Kaggle Agent の CV を 0.12961 → 0.12873 に下げた一手
再計算キャッシュ型ではなく「target を使わない・決定的なリーク安全特徴を 1 回だけ物質化し、全 trial が raw CSV の代わりに読む」型。 同一モデル・同一 CV・同一 seed の A/B で CV 0.12961 → 0.12873。78 特徴を全試行に無償で配る。
CatBoost の cat_features に NaN を渡すと即死する — LLM の自己修復でも直せなかったバグを、決定的サニタイザで潰す
欠損カテゴリで即死する CatBoost を、LLM の自己修復は直せなかった。astype 行だけ直しても派生フレームで再発。 「読み込み直後に源流で埋める」決定的サニタイザで解決し、落ちていた patch が CV 0.12403 で完走するまで。
torch が無くてもやれることはある — NLP は char+word TF-IDF、時系列はカレンダー特徴で弱モダリティを底上げする
深層学習を入れる前に、依存ゼロ・GPU 無しで取れる分を先に取る。NLP は word + char TF-IDF の hstack、時系列は日付を潰さずカレンダー特徴に展開。 import 抜けで即死していたテンプレや sklearn 1.8 の liblinear 多クラス非対応も込みで。
LLM が書くコードを『回帰テスト』にする — Kaggle 提出枠を消費せずに codegen 品質を固定する
生成コードを決定的に直すサニタイザを pytest で固定し、「直る/構文を壊さない/冪等/誤爆しない」を全ルールで検証。 ファイル直読みで依存を回避し開発機で 0.02 秒。提出枠を使わないベンチが自己修復でも直せないバグを炙り出す。
アンサンブルが効かない本当の理由は『コード生成の品質』だった — ローカル LLM を qwen3-coder に替えて Kaggle Agent が自己ベストを更新するまで
「3 つの探索枝が全部同じ予測に収束 → アンサンブルが効かない」を追ったら、真因は diversify の コード生成品質だった。決定的サニタイザ + ローカル LLM を qwen3-coder:30b に交換 + 自己修復ループで、 アンサンブルが初めて単一を上回り LB が自己ベスト更新 (0.12967→0.12824)。すべて API 不使用・ローカル完結。
アンサンブルは全部動いたのに LB が 1mm も動かなかった — そして見つけた「自分のスコアを見失う」バグ
quota reset 後に OOF ensemble 経路を実 LB で検証。機構は全部発火したのに LB は 0.13007 ×3 で不動 — 原因は 3 trial の予測が完全に同一 (多様性ゼロ)。調査中に「Agent が自分の LB スコアを見失う」 submit poll 取りこぼしバグも発見し、run 終了時の遅延 reconcile で修正した話。
OOF を保存しても submit していなかった話 — Kaggle Agent の ensemble 経路を蘇生させた Phase 8-2
playbook 6 関数中 4 つが未配線、繋がっている 2 つも結果が submit に届いていない致命的バグを発見。 TRIAL_NO の連番化 (env 経由)、regression OOF の log 空間保存、adversarial validation の Id 列除外を含む 8 ファイル修正で「OOF → LB」経路を初めて閉じた話。
LangGraph で Knowledge ループを閉じる — Kaggle Agent が過去の自分から学ぶまで
EpisodeMemory 書き戻し (write) と GrandmasterMemory recall (read) を全部繋ぎ、 「前回 episode の successful 戦略を Planner が完全踏襲して LB best を更新する」観察に成功した実機実証の記録。
Linux→GitHub の SSH:22 が中間装置で塞がれていた話 — Mac mini を経由する rsync デプロイ運用に倒した経緯
banner=6279353 で握り潰される SSH:22 outbound を発見。HTTPS+PAT 案を捨てて rsync 一本化に倒した経緯と、
scripts/deploy_from_mac.sh + systemctl --user での運用詳解。
自作マルチエージェントKaggleシステムをTitanicで実走テストした話【KRS-Core v0.1.0】
KRS-Core v0.1.0 を Titanic コンペで初の実走テスト。LangGraph ノード間の state 受け渡しや Kaggle CLI の提出制限など、設計段階では見えなかった実機特有の問題を一通り洗い出した記録。
LangGraph × ローカルLLMでKaggleを自動化するマルチエージェント設計の話
Planner / Coder / Critic などの役割を LangGraph のノードとして設計し、ローカル LLM (Ollama) を
タスク種別ごとに振り分けるマルチエージェント基盤の設計記録。AgentState の型定義が
デバッグ性を大きく左右することを学んだ回。
Kaggle 専用 v8 を 7 層の汎用マルチエージェント基盤 (KRS-Core) にリファクタした全工程
一体化していた KRS v8 を core/knowledge から core/interfaces までの 7 層に分離し、
BaseAgent ABC + ModelRouter + AgentRegistry で新 Agent が即座に載る基盤を作った全記録。
Kaggle自動化ツールを『汎用AIエージェント基盤』に育てる設計判断の記録
Kaggle専用ツールとして育ってきたシステムを汎用AIエージェント基盤へ発展させるための設計判断。 PostgreSQL + Qdrant による記憶層導入の検討も含め、後の KRS-Core 構想の原点となった意思決定記録。
「賢いAIより記憶するAI」— KaggleグランドマスターAIの設計方針とPostgreSQL+Qdrant移行の意思決定
「賢いAIより記憶するAI」を目指し、過去の試行履歴を PostgreSQL + Qdrant に移行する意思決定の記録。 GrandmasterMemory の設計方針を固めた、後の Knowledge ループ実装につながる原点。
Kaggle上位NotebookをLLMで自動SKILL化する週次Harvestパイプラインを作った
Kaggle上位Notebookを毎週自動収集し、LLMで知識を蒸留してSKILL化する週次Harvestパイプラインを構築。 Kaggle CLIの認証形式変更など、実装上の落とし穴も併せて解説。
Mac mini M4 + Ubuntu RTX機でKaggle自動化AIを動かすデュアルノード構成の設計と落とし穴
Mac mini M4 + Ubuntu の2台構成でKaggle自動化AIを動かす設計と、Kaggle CLI 2.2.0の トークン形式変更などデュアルノード運用で踏んだ落とし穴をまとめた記録。
KaggleグランドマスターのPlaybookをLLMパイプラインに自動化して組み込んだ話
Kaggleグランドマスターが使う定石（Playbook）をLLMパイプラインに自動組み込み。 hill climbing・stackingなどの戦略をAgentが自律的に選択できるようにした実装記録。
ローカルLLMパイプラインのOllama呼び出しを全面刷新した話 — think:falseバグとMac依存の排除
think:false が無視されるバグとMac依存のハードコードを一掃するため、Ollama呼び出しを全面刷新。
Mac/Ubuntu双方から呼べる共通クライアントへ再設計した記録。
Kaggle自動分析パイプラインの致命的バグを6本まとめて直した話
Kaggle自動分析パイプラインに潜んでいた致命的バグ6本を一気に修正。 CV取得失敗やSubmit不整合など、自動化を止めていた根本原因をまとめたデバッグ記録。
LLM生成コードのCV未取得エラーをゼロに近づけるハーネスエンジニアリング実装記
LLMが生成するKaggleコードでCVスコアが取得できないエラーをゼロに近づけるためのハーネス設計。 エラー内容をLLMに正しく伝える仕組みづくりの試行錯誤の記録。
OllamaのApple Metal（MPS）クラッシュをリトライ＋Linuxフォールバックで乗り越えた話
Apple Silicon上のOllamaがMetal (MPS) で頻繁にクラッシュする問題に対し、リトライ＋Linux側への フォールバック機構を実装。安定したローカルLLM推論基盤への一歩。
Kaggleスコアが上がらない本当の理由——同じLLMに全部任せるのをやめた話
1つのLLMに企画から実装まで全部任せていたのがスコア停滞の元凶だった。 タスク種別ごとに異なるモデルを割り当てるマルチエージェント構成へ転換した分岐点の記録。
LLM生成コードをそのまま実行したら死んだので自動修正レイヤーを作った
LLMが生成したKaggleコードをそのまま実行すると様々な理由でクラッシュする。 実行前に構文・import・パスなどを自動修正するサニタイズレイヤーを実装した記録。
Ubuntu 24.04をヘッドレスRDP運用するまでの茨の道
モニターなしのUbuntu 24.04機をRDPでGUI操作できるようにするまでの設定地獄。 GNOME + xrdpの組み合わせで踏んだ罠を一通り解説。
ROCm環境のAMD GPU（RX 7900 XTX）をStreamlitでリアルタイム監視するダッシュボードを作った
ROCm環境のAMD GPUの使用率・温度・VRAMをリアルタイム監視するダッシュボードをStreamlitで自作。 Mac側ブラウザから2台構成のGPU状態を一目で確認できるようにした記録。
Mac mini M4とUbuntu直結環境でインターネット共有をpfctlで永続化するまでの3時間
Mac miniのインターネット共有とUbuntuの独自サブネットが噛み合わずNATが通らない問題を3時間かけて解決。 最終的にUbuntu側をmacOSの想定するサブネットに合わせて解決した、2台構成インフラの原点の記録。
KaggleパイプラインをWindows+MacからUbuntu+Macに移植した話（ROCm GPU対応）
Windows+Mac構成で動いていたKaggle自動化パイプラインを、ROCm対応のUbuntu+Mac構成へ移植。 IPアドレス変更を含む全面的な環境移行の記録。現在の2台構成インフラの起点となった一本。
// more posts coming via auto-generation pipeline