藤岡達也 — 統計的推論の設計 / 機械学習基盤・MLOps

設計思想

仕事の中核。個々の手法より上位にある判断

原則 01 — 記録

徹底的に記録する

「この結果はどこから来たのか」に即答できない実験は、再現できないという意味で検証されていないのと同じです。必要な記録は四種類あり、どれか一つでも欠けると後から辿れなくなります。私はこれをログ運用の心がけではなく、 実装として残る仕組みで担保します。

記録の四分類
分類	何に答えるための記録か	実装
依存の記録	この成果物は、どの入力・どの設定・どのコードから出たのか。入力が変わったとき、何が古くなるのか。	typed-lineage — 依存関係を型付きグラフとして表現する基盤 canonical_panel — 成果物そのものに来歴を埋め込む正準スキーマ
実験の記録	どの仮説を、どう試し、どう判定したのか。採用されなかった案と、判定できなかった案を捨てないこと。	astraloop-store — 仮説と、それを支持／反証する証拠の登録簿 pool — 実験とランの登録簿。外部参照の解決先 MLflow — 学習ジョブの記録
デプロイの記録	いま何が動いていて、どうしてそれが動くことになったのか。昇格の履歴と、その昇格を許した根拠。ある変更が、動いているどれを揺るがすのか。	typed-lineage の deployment 層 — 環境・束縛・契約・検査を型で表し、昇格の履歴と、昇格を支えた契約検査を辿れるようにする。環境間で変わってはいけない設定は、変わり得ないものとして検証する stock-trader-deploy — その日どのモデルを採用したかを日付ごとに残す
計測の記録	実行がどれだけの時間とコストを使い、どう振る舞ったのか。障害時に何が起きていたかを復元でき、運用中の性能の変化に気づけること。	forward-testing — 運用中の予測を単一の真実として記録し続ける追跡基盤 ordinaryMemory — リクエスト単位の利用量とコスト、実行ステップの永続化 swiper — 人の評価を追記専用で蓄積するストア

記録は欠けたことも記録します。外部参照が解決できなかった場合も、来歴の生成を諦めて例外で握り潰すのではなく、 不完全であることとその理由を構造化して残す。「記録がない」と「記録できなかった、その理由はこれ」は、後から辿るときに全く別物です。

原則 02 — 分離

分離の徹底— 安全なブラックボックス

中身を人が納得できる言葉で説明できることと、それが正しいことは別問題です。事後的な説明はいくらでも作れてしまい、作れてしまうがゆえに検証を緩めます。だから私は内部の解釈で安心を得ようとせず、分離を徹底することで安全を作ります。答えや未来の情報が届き得る経路を断ち、学習と判定の期間を切り、分離が守られたことを検定で確かめる。ここまで揃えば、 中身を問わずに使ってよいと言い切れます。原則01 の記録が揃っているからこそ、この三層を積めます。

分離の三層
分類	何を分離するのか	実装・手法
経路の分離	そもそもその情報が、ここに届き得るのか。届き得ないことを運用の注意ではなく、型と契約で示す。入力・時点・単位・不変条件までを契約に含め、後から解釈でごまかせないようにします。	typed-lineage — どの成果物が、どのデータの、どの時点の状態から出たかを型で保持 canonical_panel — 物理スキーマだけでなく意味・単位・timezone・不変条件まで規定する契約
期間の分離	判定に使う情報が、学習に使った情報から本当に切り離されているか。見かけ上の分割ではなく、実質的に切れていることをコードの側で保証します。	パージ／embargo 付き walk-forward — 学習期間と検証期間の間に空白を挟み、ラベル生成に使う先読み分の重なりを物理的に切断
分離の検証	上の二層が本当に効いていたのかを、事後に確かめる。分離を破って入り込んだものは、不自然な強さとして表に出ます。偶然でないか、既存の焼き直しでないか、特定の時期にしか成り立たないかを、それぞれ別の帰無仮説で潰します。	置換検定 / スパニング回帰 / 年次分解 / ブロックブートストラップ — 個々の検定が何を疑い、どう潰したかは次節「統計的推論・実験設計」に記載

この立場の実利は、説明できないという理由で有効な手法を捨てずに済むことです。深いモデルでも大きなアンサンブルでも、三つを通れば同じ土俵で比較できる。逆に、どれだけ解釈しやすい線形モデルでも、通らなければ採用しません。ただしこれは分析能力の放棄ではなく、寄与度分解や要因分析は必要な局面—— 混入の疑いが出たときの原因の切り分けや、意思決定者への説明——では実施します。実際、株式案件で置換検定を日付内シャッフルとして設計できたのは、「開示カレンダーが業種を代理している」という具体的な機序を想定できたからでした。違いは、その理解を検定の設計に使うのか、採否の理由に使うのかにあります。

原則 03 — 計測

徹底的に計測する

何を測るか、何回測ったか、いつまで有効か。この三つが揃って初めて、その数字を判断に使えます。どれか一つでも欠けたまま出た結論は、欠けた面について推測を含みます。

計測の三分類
分類	何のための計測か	実装
指標の設計	KPI に直結する指標を、最終の判断基準に置く。そのうえで、そこへ至る途中で見る代理指標を別に設計する。最終指標は検出力が低いことが多く、それだけでは探索が進まないためです。代理指標は候補を絞る道具であって、結論を出す場所ではありません。	最終 — 損益・CAGR・最大ドローダウン。運用構成の採否はこの水準で決める代理 — 全銘柄横断の順位相関。日次で数百の観測が集まり、平均 / t値 / ICIR / 年次に分解して原因を切り分けられる
試行の計上	当たりだけを数えると、偶然の当たりを実力と取り違えます。棄却された案も、判定できなかった案も、同じ台帳に載せて分母を保つ。何回試したのかが分かって初めて、その当たりが偶然かどうかを評価できます。	astraloop-store — 仮説と、それを支持／反証する証拠を同じ台帳に記録。改善しなかった試行もスコア差分とともに残し、交絡の記録を添える。台帳に残すことと、証拠として数えることは別に判定する（完走しなかった試行は記録はするが、証拠には数えない）
鮮度の維持	一度良かったものが、良いままとは限らない。運用中の性能を測り続け、劣化に気づき、切り替える。モデルは据え置く資産ではなく、計測の結果として選び直されるものとして扱います。	forward-testing — 運用中の予測を単一の真実として記録し続ける日次の再選択 — 最新の計測に基づき、その日どのモデルの出力を採るかを選び直す。切り替えの履歴は原則01 の「デプロイの記録」として残る

三分類は分野に依存しませんが、答えは依存します。 1件あたりの効果が小さく件数を稼げるのか、逆に1件が重く回数を稼げないのかで、代理指標をどこまで信じてよいかも、何回の試行までなら偶然を疑わずに済むかも、鮮度をどの頻度で測るべきかも変わる。だから既存の指標をそのまま持ち込むのではなく、 最終的に何で判断するのか、そこへ至る途中で何を見るのかを分けて組み立てます。前職で担当した「実験評価のための統計的検定の提案」も、突き詰めればこの工程です。

実務での適用

株式会社PALTAC 研究開発本部／守秘義務に配慮した概要

2024年から2025年にかけて、物流倉庫の最適化と需要予測・在庫発注の研究開発に従事しました。共通して担当したのは、業務上の問いを評価可能な形へ整理し、分析・実装・検証までつなぐことです。

Case 01 / Warehouse optimization

ピッキング施策を、比較できる実験へ

課題: 動線短縮と生産性向上が同じとは限らず、既存シミュレータにも異常な出力がありました。
アプローチ: 中間生成物まで追跡して異常を調査。処置群・対照群と実験前後を分け、DIDなどによる効果検証を実装しました。
提案: 出荷順位だけでなく、同じオリコンへ入りやすい商品の共起性も配置最適化の予測対象として整理しました。
成果物: 評価・可視化コード、動線図の自動生成、共起行列の次元削減・クラスタリング、配置手法の試作。

Case 02 / Demand & inventory

予測精度の先にある、発注判断を扱う

課題: 需要予測は精度だけでなく、欠品、在庫金額、保管体積、リードタイムを同時に考える必要がありました。
実装: 既存在庫シミュレータを読解し、通常発注と長いリードタイムを併用する早期発注機能を追加しました。
分析: 発注グループと価格・体積・出荷傾向、保有日数、入荷頻度などの関係をLightGBMや相関分析で調査しました。
基盤検討: 学習環境の再現性・保守性を整理し、Feastを試作。ZenMLやSageMakerを含むMLOps基盤を比較しました。

統計的推論・実験設計

三原則を支える道具。すべて自作システムで実装・運用

手法を知っていることと、目の前の問いに対して正しい検定を組み立てられることは別物です。重要なのはたいてい「何を帰無仮説に置くか」であり、その設計を誤ると、どれだけ厳密に計算しても答えは意味を持ちません。以下は既存コードで実際に使っている道具と、それぞれが潰しにいった具体的な疑いです。

背景大学での専攻はデータサイエンス。統計検定データサイエンス発展（2023年）。前職では研究開発本部で実験評価のための統計的検定の提案と実施を担当。

Research Note 01 誰に、どのデータを任せるか。 卒業研究を自己査読し、旧実験3,125件を棚卸し。入力依存の分業を20 seedで追試しました。読む →

実装している検証手法
手法	何を疑い、どう潰したか
置換検定（日付内シャッフル）	観測された効果が「企業ごとの実質」なのか「開示カレンダーがセクターやレジームを代理しているだけ」なのかを弁別。特徴量を日付内でのみ銘柄間シャッフルすることで、リークが利用しうる日次の周辺分布・欠測構造・カレンダー相関は保存したまま、本物の効果に必要な「どの企業のものか」だけを破壊。効果が消えれば実質、生き残ればリーク。全体シャッフルでは帰無仮説が「効果ゼロ」ではなく「日付構造ごとランダム」にすり替わり、リークの弁別には使えません。日付内であることが要点です。
パージ付き walk-forward 検証	学習期間と検証期間の間に embargo 期間を挟み、ラベル生成に使う先読み分の重なりを物理的に切断。見かけ上の分割ではなく実質的なパージになっていることをコードレベルで保証。比較実験を甘い条件で走らせてしまう事故を構造的に防いでいます。
スパニング回帰（Newey-West）	全15ファクターのうち、あるひとつの収益を残る14に回帰し、切片が有意に正なら他に張られない独立アルファ、 R² が高ければ冗長と判定。系列相関を考慮して Newey-West（lag 5）で t 値を補正。「新しく見える指標が既存の焼き直しでないか」を機械的に判定する装置。
循環移動ブロックブートストラップ	金融時系列は自己相関を持つため、通常のブートストラップは標準誤差を過小評価し、区間が過度に狭くなります。系列構造を保つブロック法で 1,000 回リサンプルし、OLS 係数の 95% 区間を推定。
指標の検出力設計（rank IC 主義）	探索段階の指標を全銘柄横断の rank IC（平均・t値・ICIR）に据える判断。最終的な採否は損益水準で行います。原則03 の「検出力」の条件を、この案件で適用したものです。
年次分解による頑健性検査	全期間の t 値は、たまたま強かった1年に牽引されている可能性があります。保存済みの out-of-sample 予測を再フィットなしで年ごとに分解し、効果が特定レジーム依存でないことを確認。
MCTS / UCB	探索と活用のトレードオフを統計的意思決定として扱い、限られた試行予算をどの仮説に配分するかを決定。後述の astraloop で、LLM が生成した改善案の探索順序制御に適用しています。

主要プロジェクト

すべて個人開発・現在も運用中

stock-trading / alpha-fusion 日本株の予測から執行までを繋ぐMLパイプラインと、その検証基盤

前節の検証手法群はすべてこの案件で実装したものです。パイプラインを 取得・学習・選択・配信を独立に更新／巻き戻しできる単位へ分割し、毎日 18:14 JST に日次フローが起動して翌営業日の注文シートを出力するところまで自動化しています。

stock-tradingの置換検定結果。baseline、gating、revision、allのrank ICのt値と、allの信号を置換した結果を比較し、置換後だけが採用基準を下回っている。 — 統合案は通常データでは **t = 4.66** まで伸びますが、信号を置換すると **t = −0.58** へ落ちます。見た目の改善ではなく、企業固有の信号が残っているかで採否します。

取得 J-Quants API → fetcher (systemd timer) → GCS → reader writer/reader がスキーマ契約を共有し、無言のドリフトを防ぐ学習 purge/embargo 付き walk-forward で52本のモデルを学習しプール化検証 rank IC (平均・t値・ICIR) を主指標 / 置換検定・スパニング回帰ブロックブートストラップ区間 / 年次分解による頑健性検査選択メタランカー層が「今日どのモデルのピックを採るか」を決定配信日次フローが4ステップをフォールト分離して実行記録 FastAPI + Mongo を単一の真実として予測を追跡・可視化

この構成で一貫しているのは、採否を人の直感に委ねないことです。新しい特徴量を入れるかどうかは、置換検定を通り、他ファクターに張られず、年次分解でも消えないという条件で機械的に決まります。バックテストと実運用成績の乖離は隠さず記録し続けています。

astraloop LLMエージェントによる機械学習実験の自動探索

統計的意思決定とエージェントが交わる中核プロジェクト。 LLMエージェントがモデル改善案を提案し、MCTS が限られた試行予算をどの案に配分するかを決める 自動実験ループです。結果はスコアとして木にバックプロパゲーションされ、有望な枝が深掘りされます。

astraloopの1実験ランで生成された95ノード、56イテレーションの探索木。円の大きさが訪問回数、同心円が木の深さ、色がラン内のスコア順位を示す。 — 同心円は木の深さ、円の大きさは訪問回数、色はラン内のスコア順位です。提案を一列に試すのではなく、**結果を木へ戻しながら試行予算の配分を変えている**ことが見えます。

提案エージェントが設定差分を JSON 契約で生成 ↓ 契約フィールド検証・重複案の除去（dedupe）探索 MCTS 木に配置 → UCB で選択 exploit 信号は部分木の最大スコア（最大化問題のため） ↓ 多様性ポリシーが探索フェーズに応じて候補を動的に取捨評価試行を実行 → スコアを親方向へ伝播 ↓ effective_change が「提案が実際に効いたか」を判定記憶反証された案を蓄積し、次の提案文脈へ注入

エージェントに自由生成させるだけでは、似た案の反復と「変更したつもりで何も変わっていない」試行に探索予算を溶かします。そこで重複検知・多様性ポリシー・実効変化判定の三つを挟みました。ノードは部分木集約値と自ノード固有値を分離して保持し、無関係な子孫の成績で親の評価が汚れないようにしています。探索の再現性を保つため、乱数は固定シードから決定的に導出しています。エージェント協働の観点からの位置づけは Page 02 — LLMエージェント / 協働UI・UX に記載しています。

typed-lineage / canonical_panel / pool 依存と実験の記録を、成果物そのものに持たせる基盤

原則01 の「依存の記録」と「実験の記録」を実装した基盤群。外付けのログではなく、成果物のファイル単体で「何から作られたか」に答えられる状態を作ります。他プロジェクトへ持ち出せるよう、ドメイン非依存の層として切り出しています。

typed-lineageで表現した日次フローのDAG。J-Quantsの日次四本値から取得、canonical panel、学習と検定、モデル選択、翌営業日の注文シート、本番昇格の根拠までを10ノード11エッジで接続している。 — 入力データから学習・検定・選択・注文シート・本番昇格の根拠までを、 **data / function / claim の部分型を持つ一枚のDAG**として記録しています。

設計判断として効いたのは canonical_panel です。以前は同じ「選択」を二通りに書き出していました。予測値の行列と、実際に採った1日1行の結果表。 2ファイルに1つの真実を持たせると必ず乖離します。 規約は暗黙のまま残り、後続の分析が毎回それを推測し直していました。そこで両者の上位集合となる1つのスキーマへ統合し、選択を単一の真偽値列に。「最大値を採る」という約束が、復元ではなく構造として保証されるようになりました。規約自体もファイルのメタデータに埋め込み、単体で解釈できるようにしています。

他人が保守できる形にすることを前提に、仕様書・CI・テストを整備しています。スキーマ変更時は writer を先行させず、旧 reader のフィクスチャと新旧ラウンドトリップを同一変更内で用意する規則にしました。読み手を壊さずに進化させるための制約です。

ordinaryMemory / swiper / Tray LLM・画像生成エージェントと、人が協働するためのインターフェース

推論設計を LLM エージェント領域へ適用した成果物群。会話から wiki を蒸留し続けるマルチエージェント知識システム、スワイプ評価で育つ画像生成スタジオ、キーボード駆動のアウトライナー。いずれも日常的に自分で使い続けています。

プロバイダ固有の破綻を吸収する信頼性設計、エージェントに書き込み権限を渡さない二段の承認経路、人の判断をどこに残すかの比較設計については、 Page 02 — LLMエージェント / 協働UI・UX に詳述しています。

技術スタック

実運用しているものに限定

機械学習	LightGBM・CatBoost・scikit-learn／モデルプール運用、メタランカーによるモデル選択、MLflow
LLM / エージェント	DeepSeek・OpenAI・Gemini・xAI・Cerebras・OpenRouter・Alibaba・Z.AI・Ollama を共通抽象の背後に実装／ツール実行ループ、マルチエージェント委譲、構造化出力（zod → JSON Schema）、利用量とコストの計測
画像生成	ComfyUI API 連携、ワークフロー制御、生成物の GCS 配信
データ処理	polars、pandas、PyArrow / Parquet、GCS、PostgreSQL、MongoDB、SQLite
アプリケーション	TypeScript（Hono / Node）、Python（FastAPI）、Preact、Vite／キーボード駆動UI
基盤・運用	Docker Compose、systemd（service / timer）、Wasabi + restic、セルフホスト運用全般
テスト	Vitest（testcontainers で使い捨てPostgres）、pytest、Playwright