Frontier AI Nexus

社内文書を対象とした Agentic RAG コンペ（SIGNATE）に取り組んだ記録です。
方針から設計、実装の2経路（API版と完全ローカル版）、現場で踏んだ罠、PDCA、工夫まで、一本で追えるようにまとめました。
これから同種のシステムを作る人が、読んでそのまま再現できることを目指して作成しました。
長編です。笑

課題は、架空のデータ分析コンサル会社「データアステル社」の共有ドライブを対象に、寄せられる質問へ根拠に基づいて日本語で回答する RAG システムを作り、回答精度を競うものです。

今回のRAG コンペにおいて重要視されている点としては、
新規の案件フォルダ・新規の資料の追加によって、回答精度が変わらないこと。

つまり「既存データによって最適化された検索」ではなく、「未知のデータでも同じ検索結果を出力する汎用システムを作る」ことがゴールとなります。

0. 全体アーキテクチャ

まず完成形の全体像です。Store / Retrieve / Agent / Output の4層構成で、LLM バックエンドは OpenAI API とローカル Ollama を設定1つで切り替えられます。

この構成に至るまでの判断を、順に説明していきます。

1. 方針 — コードより先に、評価コードと論文を読む

最初に着手したのは実装ではなく、配布された評価コードの解読でした。

1-1. 採点 LLM は「質問文を見ない」

本コンペの評価は Meta の CRAG ベンチマーク [1] に準拠した LLM 採点で、回答を Perfect(+1) / Acceptable(+0.5) / Missing(0) / Incorrect(-1) に分類し、平均をスコアとします。評価コードを読むと、採点プロンプトに渡されるのは

ground_truth: {模範解答} answer: {提出回答}

のみで、質問文は渡されません。「契約金額はX円です。契約書第5条に記載され…」のような丁寧な回答は、模範解答「X円」との文字列比較で不利になり得ます。回答は”値そのもの”だけを、模範解答と同じ形式で出すのが最適解となります。

1-2. 得点の非対称性から「賭け方」を決める

重要な非対称性が2つ。要素列挙問題は部分一致でも即 Incorrect(-1)、Acceptable なし。そしてMissing は 0 点。誤答の -1 に対し、自信がないときの「わかりません」は 0 で止血できます。

1-3. 方針の4原則

1. 評価仕様からの逆算 — 回答は値のみ・1行・列挙は「、」区切り・不確実なら「わかりません」
2. 汎用性最優先 — フォルダ名・ファイル名・値からのハードコードをなくす。実行時にドライブから機械検出を行う。
3. 検索＋計算 — 「CSV を条件抽出して集計」「版間差分」型の問題が確実に存在。LLM の暗算ではなくコード生成＋実行で計算
4. 再現性 — temperature=0・seed 固定・全 LLM 呼び出しの JSONL ログ・使用モデル名の記録

2. 設計 — 4層それぞれの中身

2-1. Store — パース品質が RAG 全体の性能を決める

「OCR・パースの品質が下流性能をどれだけ律速するか」は OHRBench が体系的に示した論点で、Store の手抜きは後段で取り返せないという本設計の前提を裏付けます。本件は配布データが Office 系中心（構造化 API で正確に読める）なので、pptx/docx/xlsx はライブラリで直接パースし、PDF・画像のみ VLM 読解に回すハイブリッドにしました。

画像・グラフの扱いは設計の分岐点でした。ページ画像そのものを検索対象にする方式と、VLM でテキスト化してからテキスト検索に載せる方式がありますが、本パイプラインは後者を採りました。(a) 既存の BM25+密ベクトル・増分インデックスをそのまま活かせる、(b) 生成キャプションを画像バイト列の sha1 でキャッシュでき再実行時の再課金・再計算がゼロ、(c) 重い検索モデルを持ち込まずに済む、が理由です。ページ画像検索の利点は、後述の view_page ツールで補完します。

インデックスは増分設計です。ファイルごとの台帳を持ち、追加・変更分だけをパース・埋め込みします。「新規フォルダを追加しても既存チャンクの埋め込みが1ビットも変わらない」ことをテストで実証しており、検収時のデータ追加が既存の検索品質を揺らさない根拠になっています。
失敗したファイル（未復号・画像読解失敗）は台帳に載せない＝次回実行時に自動リトライという一貫した規則で、中断・再開にも同じ仕組みで対応します。

さらに各チャンク本文に 《案件名｜ファイル名｜位置》 という出典コンテキストを前置してから索引化します。チャンク単体で失われる文書レベルの文脈を埋め込み・BM25 双方に効かせるこの手法は、Anthropic の Contextual Retrieval の軽量版です。原典は LLM でチャンクごとの説明文を生成しますが、メタデータの機械的前置だけでも「案件名＋項目名」型クエリのマッチが明確に改善しました。

暗号化 Office ファイルへの対応は、ハードコード禁止下では「実行時にドライブから候補を機械生成して試す」一択です。候補生成は4段＋LLM導出の5段構えにしました。⑤が効くのは「パスワードそのものはどこにも書かれていないが、導出規則の文書は存在する」ケースです。規則文書の内容は実行時に読むため、新規案件にも同一処理で一般化されます（特定パスワードの埋め込みではないのでルール適合です）。

2-2. Retrieve — スコアではなく「順位」で融合する

日本語×専門用語×英字識別子（列名やタスクID）が混ざるコーパスなので、キーワード検索（BM25、形態素解析器なしで動く文字 bigram+英数語トークナイザ）と意味検索（埋め込み）のハイブリッドにし、RRF（Reciprocal Rank Fusion） で融合しました。

RRF は学習不要・スコア校正不要で個別ランカーを上回るという原論文の性質が「新規フォルダ耐性」に直結します。BM25 のスコア分布はコーパス増加で変わりますが、順位ベースの融合はスケール変化に影響されません。

2-3. Agent — 静的パイプラインではなくツールループ

「検索して詰めて生成する」静的 RAG に対し、計画・ツール使用・自己修正を行う Agentic RAG の枠組みは Singh らのサーベイ に整理されています。本件は単一資料の読解から複数案件の照合・集計まで難度の幅があり、固定フローでは過不足が出ます。そこで ReAct 型の「思考→行動→観察」ループに6つのツールを持たせました。

list_files / read_file で構造メタデータを辿ってから中身に踏み込む設計は PDFTriage と同じ発想。計算を LLM にさせず python へ委譲するのは PAL / PoT の直系です。view_page は M3DocRAG・ViDoRAG が示した「曖昧なときはページを直接見る」能力の実装で、キャプション索引（安価・網羅）とページ直接参照（高精度・オンデマンド）の二段構えになっています。

日本語パス照合の落とし穴は、(1) NFC→実パスのマップを起動時に構築、(2) python ツールに正規化差異を吸収する find("キーワード", suffix=".csv") ヘルパーを注入、の2段でシステム側に吸収しました。エージェントが生成するコードも必ず踏む罠だからです。

2-4. 検証ゲート — 「出す前に、根拠と突き合わせる」

最重要の安全弁が final 直前の根拠ゲート付き検証です。ループ中に蓄積した「根拠トレース」と回答案を照合する検証 LLM を1回だけ呼び、採点の非対称性（誤答-1/棄権0）を明示したうえで判定させます。

生成後に自己批評・修正を挟む設計は Self-RAG 、Corrective RAG 、CRAG-MM 上位解の検証中心アーキテクチャに連なります。特に列挙問題（部分一致=-1）への「1要素でも怪しければ棄権」は、期待値上もっとも効く場所に置いた安全弁です。後述のローカル 7B 構成では、モデルが弱くなるほどこのゲートの価値が上がります。誤答 -1 を量産する代わりに棄権 0 で守れるためです。

3. マルチエージェントや FastMCP は使うべきか

設計中に検討し、どちらも採用しませんでした。判断基準は一つ、「その仕組みがこの採点仕様で期待スコアを上げるか」です。

FastMCP はツールをプロセス外のクライアントに公開する仕組みですが、本コンペの実行モデルは「predictions.csv を作る単一プロセスを審査側が再現できること」で、公開する相手がいません。挟むと通信・サーバ起動・スキーマ層が増え、再現性を損ない障害点が増えるだけ。これは「運用化フェーズ」の選択肢です。

マルチエージェントの利点（コンテキスト分離・並列化） は、本件では別手段で達成済みでした。案件ごとの情報分離は search(folders=[...]) のフォルダ絞り込みで、集計の正確性は pandas への委譲で担保。むしろエージェントを増やすと出力のばらつき・伝言ゲームの劣化・再現性低下・呼び出し数の増加を招きます。誤答 -1 を避けたいタスクでは「単一の統制されたループが、根拠を確かめてから、怪しければ棄権する」ほうが期待値が高く、CRAG 系上位解 も制御性重視の比較的単純な構成でした。

4. 実装 — 2つの実行経路（API版／完全ローカル版）

本体は単一の rag_pipeline.py（約1,500行）で、LLM 呼び出しを1つのクラスに集約してあります。そのため実行経路は設定1つで切り替えられます。

4-1. API 版（OpenAI）

OPENAI_API_KEY を設定し、Colab または任意の Python 環境で「Drive マウント → ZIP 展開 → パス確定 → インデックス構築 → 検証30問 → 本番100問 → zip」の順に実行します。残高切れ（429 insufficient_quota）は専用例外として検知し、インデックス構築・回答生成のどちらでもそこまでの成果を保存して中断→残高補充後に同じセルを再実行すれば差分から再開されます。構築前には estimate_index_cost() でファイル数・画像数（＝API 呼び出し回数の目安）を課金なしで確認できます。

4-2. 完全ローカル版（APIキーが発行できない場合）

組織の規程で外部 API キーを発行できない——今回まさにこの制約に直面しました。コンペ規約は「商用API、ローカルLLM、…を自由に利用できます」「使用可能なツールは、商業利用が可能でオープンなものに限定」と明記しており、オープンウェイトモデルのローカル実行は規約が名指しで認める王道です。

すべて Colab 無料枠（T4 16GB）の VM 内で完結し、データは一切外に出ません。ローカル小型モデルは出力に前置きを混ぜて JSON を崩しがちなので、寛容 JSON パーサ（「まず検索します。{…}」のような出力から JSON 部分を救済）も入れました。再現性は API より強く、モデル重み固定＋seed 固定で完全に同じ出力を再現できます。

正直なトレードオフも書いておきます。7B は gpt-4o クラスより品質が落ちます（計算コード生成の粗さ・グラフ数値読解の精度）。目安時間はインデックス構築1〜3時間、検証30問1〜2時間、本番100問4〜8時間。この前提で、全工程を「1問ごとに Drive へ進捗保存 → 切断されても再実行で続きから」のレジューム設計にしました。無料枠のセッション切断は「起きるもの」として設計に織り込むのが正解です。

5. 現場で踏んだ罠と、その一般化

設計どおりに書いて終わり、にはなりませんでした。重要なのは、遭遇した問題を「このファイル・この環境だけの応急処置」ではなく「同じ性質を持つ未知の状況にも効く一般規則」として実装し直すことです。汎用性が検収要件そのものだからです。

罠1: API 残高切れ（429 insufficient_quota）が大量発生。 画像 OCR のたびに弾かれ、放置するとグラフ・書式の情報が全部欠けたインデックスができてしまう。→ 一般規則: 回復不能なエラーは専用例外として検知し、途中保存して中断、再実行で差分再開。一時的エラー（500等）のリトライとは明確に区別する。

罠2: 組織で API キーを発行できない。 → 一般規則: モデル依存を1クラスに集約しておけば、バックエンド追加（Ollama）だけで全機能がローカルへ移行できる。埋め込みは最初からローカルフォールバックを用意しておく。

罠3: Ollama インストーラが zstd を要求して失敗（Colab 標準環境に未導入。インストーラ側の配布形式変更が原因）。→ 一般規則: 実行環境の前提は変わるもの。セットアップは冪等な「復旧セル」（本体確認→再インストール→サーバ起動→モデル確認→不足分 pull）として1つにまとめ、セッション切断後はそれ1つで戻れるようにする。

※OllamaのRAG作成には1時間近くかかった。

罠4: ローカル VLM への画像送信が 400 Bad Request。 原因は Office 埋め込み画像に多い WMF/EMF 形式（Windows メタファイル）を VLM が受け付けないこと。→ 一般規則: VLM へ渡す前に PIL で PNG へ統一変換・長辺縮小。デコード不能な装飾画像は恒久スキップ、読めたはずの画像で失敗したファイルは manifest 除外で次回リトライ。エラーメッセージにはレスポンス本文を含めて原因を特定可能にする。

罠5: パスワードそのものはどこにも書かれていない暗号化ファイル。 社内規定には「導出規則」だけがある。→ 一般規則: 規則文書を実行時に読み、LLM に機械適用させて候補を生成（前掲⑤）。規則の中身をコードに書かないので新規案件にも一般化される。

罠6: 日本語ファイル名の NFC/NFD ゆれ。 → 一般規則: 正規化を1箇所（パス解決マップと find ヘルパー）に集約し、エージェント生成コードにも同じヘルパーを使わせる。

6. PDCA — 6サイクルの反復

各サイクルの Act が次の Plan になっています。特に v4 は「自分の実装を先行研究に照らして棚卸しする」回で、(a) 検証ゲート未実装、(b) ページ直接参照 の欠落、(c) チャンク文脈付与 未適用、の3ギャップを特定して埋めました。文献レビュー自体を Check 工程に組み込むと、改善の打ち手が経験則ではなく再現された知見から出せます。v6 は「環境が理想でなくても動かし切る」回で、罠1〜5 の一般規則化がここに入ります。

次のサイクルは精度チューニングです。検証30問（正解つき）をローカル採点し、誤答の型（検索ミス／計算ミス／形式ズレ／棄権すべきだった誤答）を分類 → パラメータとプロンプトを調整 → 再計測。「特定の質問に合わせた調整」はルール違反なので、誤答の”型”への一般的な改善だけを行うのが鉄則です。

7. 工夫すべきポイント（まとめ）

評価器を最初に読む。 最大のレバレッジは「採点 LLM が質問文を見ない」「列挙の部分一致は -1」「Missing は 0」の把握でした。CRAG [1] が示すとおり最先端の産業 RAG でもハルシネーションなしは6割程度。何を正解とするかを先に固定するのは実務でも同じです。

期待値で棄権を設計し、検証ゲートで守る。 誤答-1/棄権0 の非対称性がある以上「自信のない列挙は答えない」は合理的で、KDD Cup 上位解 の定石。生成→検証→棄権を最後に1段入れるだけで、最も高くつく失敗を系統的に減らせます。モデルが小さいほど効きます。

LLM に算術をさせない。 集計・件数・平均・差分は必ずコード実行に落とす（PAL / PoT）。pandas を渡すだけで計算問題の信頼性が桁違いに上がります。

パースを軽視しない。 OCR・抽出のノイズは下流で増幅される（OHRBench）。形式ごとに最も正確な読み方を選び、キャプション索引＋ページ直接参照 で視覚情報を拾う。VLM へ渡す画像は形式・サイズを正規化してから。

チャンクに文脈を前置する。 《案件｜ファイル名｜位置》の機械的前置だけでも検索が安定します（Contextual Retrieval の軽量版）。

順位ベースの融合（RRF）を使う。 学習不要・校正不要でコーパス規模の変化に強い。汎用性要件と相性が良い。

増分性と再開性を同じ仕組みで。 台帳の「失敗は載せない＝次回リトライ」という1規則が、データ追加・中断再開・部分失敗のすべてを賄います。加えて回答側も1問ごと進捗保存にすれば、セッション切断が怖くなくなります。

道具立てはスコアで選ぶ。 マルチエージェントや MCP は「使えるから使う」ではなく「この採点でスコアを上げるか」で判断。今回はどちらも見送りが正解でした。

環境の罠も一般規則で潰す。 依存の変化（zstd）、形式の癖（WMF/EMF）、規程の制約（APIキー不可）——すべて「次も起きる」前提で、冪等な復旧手順・正規化層・バックエンド抽象化として実装に落とす。

8. 実装環境まとめ

• 開発・検証: Ubuntu 24 / Python 3.12。LLM・埋め込みをモックにしてネットワークなしで結合テスト（モック Ollama サーバを立て、実 HTTP 経路まで検証）
• API 版: 任意の Python 3.10+ 環境。OPENAI_API_KEY と残高が必要。gpt-4o + text-embedding-3-large
• ローカル版: Google Colab 無料枠（T4 GPU 16GB）で動作。Ollama + Qwen2.5-7B / Qwen2.5-VL-7B + e5-large + bge-reranker。APIキー・課金・外部送信なし
• 評価: 配布のローカル評価環境で提出前にスコアを見積もり可能。検証30問（正解つき）→ 本番100問の順で回すのが安全
• 規模感: 約400ファイル（docx/pptx/xlsx/pdf/ipynb/py/png等）から約1.2万チャンク。コード本体は単一ファイル約1,500行

9. 今後の拡張候補（文献ベースの伸びしろ）

意図的に採らなかった選択肢のうち、要件が変われば有力になるもの。ページ画像を直接インデックスする ColPali 系検索 は、スキャン中心・レイアウト依存の強いコーパスなら乗り換える価値があります。案件間・人物間の関係を問う質問が増えるなら GraphRAG や階層要約木の RAPTOR。巨大帳票が主戦場なら SpreadsheetLLM のシート圧縮。xlsx のセル塗り色・文字ハイライトの構造抽出（openpyxl の fill 情報等）は、書式を問う質問への次の一手です。常設ツール化するなら MCP でのサーバ公開。文書中心マルチモーダル RAG の全体像はサーベイ が出発点です。

参考文献

[1] Yang, X. et al. “CRAG — Comprehensive RAG Benchmark.” arXiv:2406.04744 (2024). [2] Xia, Y., Chen, J., Gao, J. “Winning Solution For Meta KDD Cup’24.” arXiv:2410.00005 (2024). [3] Ouyang, J. et al. “Revisiting the Solution of Meta KDD Cup 2024: CRAG.” arXiv:2409.15337 (2024). [4] “Multi-Stage Verification-Centric Framework for Mitigating Hallucination in Multi-Modal RAG”（KDD Cup 2025 CRAG-MM）. arXiv:2507.20136 (2025). [5] Yao, S. et al. “ReAct: Synergizing Reasoning and Acting in Language Models.” arXiv:2210.03629 (2022). [6] Singh, A. et al. “Agentic Retrieval-Augmented Generation: A Survey on Agentic RAG.” arXiv:2501.09136 (2025). [7] Liang, J. et al. “Reasoning RAG via System 1 or System 2: A Survey on Reasoning Agentic RAG for Industry Challenges.” arXiv:2506.10408 (2025). [8] Gao, L. et al. “PAL: Program-aided Language Models.” arXiv:2211.10435 (2022). [9] Chen, W. et al. “Program of Thoughts Prompting.” arXiv:2211.12588 (2022). [10] Faysse, M. et al. “ColPali: Efficient Document Retrieval with Vision Language Models.” arXiv:2407.01449, ICLR 2025. [11] Yu, S. et al. “VisRAG: Vision-based Retrieval-augmented Generation on Multi-modality Documents.” arXiv:2410.10594, ICLR 2025. [12] Cho, J. et al. “M3DocRAG: Multi-modal Retrieval is What You Need for Multi-page Multi-document Understanding.” arXiv:2411.04952 (2024). [13] Wang, Q. et al. “ViDoRAG: Visual Document Retrieval-Augmented Generation via Dynamic Iterative Reasoning Agents.” arXiv:2502.18017, EMNLP 2025. [14] Zhang, J. et al. “OCR Hinders RAG: Evaluating the Cascading Impact of OCR on Retrieval-Augmented Generation.” arXiv:2412.02592, ICCV 2025. [15] “SERVAL” — VLM生成キャプションをテキストエンコーダで索引する generate-then-encode 方式 (2025). [16] Poznanski, J. et al. “olmOCR: Unlocking Trillions of Tokens in PDFs with Vision Language Models.” arXiv:2502.18443 (2025). [17] Niu, J. et al. “MinerU2.5: A Decoupled Vision-Language Model for Efficient High-Resolution Document Parsing.” arXiv:2509.22186 (2025). [18] Ouyang, L. et al. “OmniDocBench: Benchmarking Diverse PDF Document Parsing with Comprehensive Annotations.” arXiv:2412.07626, CVPR 2025. [19] Dong, H. et al. “SpreadsheetLLM: Encoding Spreadsheets for Large Language Models.” arXiv:2407.09025 (2024). [20] Anthropic. “Introducing Contextual Retrieval.” Engineering blog (2024). [21] Cormack, G., Clarke, C., Buettcher, S. “Reciprocal Rank Fusion outperforms Condorcet and individual Rank Learning Methods.” SIGIR 2009. [22] Asai, A. et al. “Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection.” arXiv:2310.11511 (2023). [23] Yan, S. et al. “Corrective Retrieval Augmented Generation.” arXiv:2401.15884 (2024). [24] Saad-Falcon, J. et al. “PDFTriage: Question Answering over Long, Structured Documents.” arXiv:2309.08872, EMNLP 2024 Industry. [25] “Scaling Beyond Context: A Survey of Multimodal RAG for Document Understanding.” arXiv:2510.15253 (2025). [26] Edge, D. et al. “From Local to Global: A Graph RAG Approach to Query-Focused Summarization.” arXiv:2404.16130 (2024). [27] Sarthi, P. et al. “RAPTOR: Recursive Abstractive Processing for Tree-Organized Retrieval.” arXiv:2401.18059 (2024).

この記事でわかること

• Ollama とは何か、なぜ注目されているのか
• クラウドLLM（ChatGPT / Claude / Gemini など）と比べた メリット・デメリット
• Ollama が どういう仕組み（アーキテクチャ） で動いているか（ネットワーク構成込み）
• macOS / Windows / Linux での 導入手順（画面キャプチャつき）
• 使う上での セキュリティ上の注意点

1. Ollama とは

Ollama（オラマ） は、大規模言語モデル（LLM）を 自分のPC上でローカルに動かす ためのオープンソースツールです（MITライセンス、Go 言語製）。よく「LLM 版の Docker」と表現されます。docker run のように ollama run <モデル名> と打つだけで、モデルのダウンロードから起動、対話までを一気にやってくれるからです。

ollama run llama3.1:8b

これ一行で、Meta の Llama 3.1（8B）が手元のマシンにダウンロードされ、その場でチャットが始まります。クラウドにも API キーにも一切つながず、インターネットが切れていても動く のが最大の特徴です。

利用できるモデルは Llama、Gemma、Qwen、DeepSeek、Phi、Mistral、gpt-oss、埋め込み用の nomic-embed-text など多岐にわたり、公式の ollama.com/library から探せます（ラインナップは頻繁に更新されるので、最新は公式ライブラリを確認してください）。

2. クラウドLLM との比較 ― どちらを選ぶべきか

まず結論を表で示します。

2-1. コスト ― 従量課金 vs 固定費

クラウドLLMは 入力・出力トークンごとの課金 です。個人利用なら安価でも、社内ツールやバッチ処理で 大量のリクエストを回すと料金が跳ね上がります。

Ollama は逆で、モデルを動かすハードウェアさえ用意すれば、その後の推論は何回実行しても追加料金ゼロ。「同じ処理を毎日大量に回す」「開発中に何百回も試行錯誤する」といった使い方では、ローカル実行のコスト優位が効いてきます。

2-2. プライバシーとセキュリティ ― “外に出ない” という価値

Ollama の推論は すべて手元のマシンで完結 します。入力したプロンプト・社内文書・ソースコード・個人情報が、外部のサーバーに送られることはありません。

• 医療・法務・金融など、機密データを外部に出せない現場
• 未公開の製品情報やソースコードを扱う 開発現場
• 顧客情報を含む文書の要約・分類

こうしたユースケースでは、「データが外に出ない」こと自体が、クラウドでは代替しにくい価値になります。

2-3. どちらを選ぶ？ ― 使い分けの指針

• クラウドLLMが向く：最高難度の推論、最新モデルをすぐ使いたい、手元にGPUがない、少ない手間で始めたい、大量同時アクセスをさばきたい。
• Ollama が向く：機密データを扱う、オフライン環境で使う、大量リクエストを低コストで回す、モデルを細かく制御・実験したい、ネット接続に依存したくない。

実務では「日常の下書きや軽い分類はローカル、難しい仕上げだけクラウド」というハイブリッド運用も有力です。

3. Ollama が向かない・注意すべきケース（デメリット）

公平のために、Ollama が万能ではない点も挙げます。

• 最先端モデルの絶対性能では、依然クラウドが優位。ローカルで動く量子化モデルは軽快ですが、最難関のタスクではフロンティアモデルに一歩譲る場面があります。
• 大量同時アクセス・高スループット本番運用には不向き。多人数へ同時提供する本番APIや、最大スループットが要るバッチ処理では、vLLM や TGI のような専用サーバーが適しています。Ollama は「個人〜小チームの手元実行」に最適化されています。
• 相応のハードウェアが要る。大きいモデルほど GPU の VRAM やメインメモリを消費します（後述の目安を参照）。
• 運用は自己責任。モデル更新、監視、バックアップ、そして後述の ネットワーク公開時のセキュリティ は自分で面倒を見る必要があります。

4. 動作の仕組み（ネットワーク構成込みアーキテクチャ）

Ollama は クライアント／サーバー型 で動きます。全体像は次の図のとおりです。

図：Ollama アーキテクチャ（ネットワーク構成込み）。編集可能な draw.io ソース ollama-architecture.drawio を同梱しています。

4-1. 処理の流れ

1. ① クライアント：ollama CLI、各言語のSDK、Open WebUI のようなチャットUI、IDE拡張（Continue / Cursor）、curl や自作アプリなどが、HTTPリクエスト（REST API） を送ります。
2. ② Ollama サーバー（デーモン）：ollama serve が常駐し、127.0.0.1:11434 で待ち受けます。ここには次の層があります。
   • HTTP API 層（内部で web フレームワークと CORS 制御）
   • OpenAI 互換 / Anthropic 互換ミドルウェア … 既存のSDKを エンドポイントのURLを差し替えるだけ でそのまま使えます
   • ルートハンドラ（Chat / Generate / Embed / Pull / Push / Create）
   • スケジューラ → メモリマネージャ … モデルをどこ（VRAM か RAM か）にどれだけ載せるかを判断し、GPUに乗り切らない層は自動的にCPU側に振り分け（レイヤーオフロード） ます
3. ③ llama.cpp ランナー：実際の推論を担う C++ 製の推論エンジン。CPU・Apple Metal・NVIDIA CUDA・AMD ROCm に対応します。
4. ④ ハードウェア：GPU / CPU / メモリ。GPUがあれば自動検出して高速化します。
5. ⑤ モデルストレージ：ダウンロード済みモデルは ~/.ollama/models に GGUF 形式（量子化済みの blobs） と manifest として保存されます。推論時はここから重みを読み込みます。

4-2. ネットワーク面のポイント（ここが重要）

• 待受は既定でループバック（127.0.0.1）。つまり 既定では同じマシンからしかアクセスできず、外部ネットワークからは到達できません。
• 外部との通信が発生するのは「モデル取得（ollama pull）」のときだけ。公式レジストリ（ollama.com/library、Docker Hub のような配布元）からモデルをダウンロードします。一度落とせば、あとはオフラインで動作 します。
• 推論データは外に出ません。プロンプトも文書も生成結果も、すべてマシン内で完結します（＝プライバシー保護・オフライン動作の根拠）。
• LANの他端末から使いたい場合 は、環境変数 OLLAMA_HOST=0.0.0.0:11434 で待受を開放できますが、Ollama は既定で認証を持ちません。開放する場合は ファイアウォールやリバースプロキシ（認証付き）で必ず保護 してください（詳細は §7）。

5. 導入手順（キャプチャつき）

キャプチャについての注記：以下のうち ターミナル画面はコマンドの実挙動を再現 したものです。ダウンロードページやアプリ常駐アイコンの図は 実画面に近い再現イメージ で、レイアウトはOSやバージョンで多少異なります。ご自身の環境で公開・共有する際は、実際の画面に差し替えてご利用ください。

5-0. 動作環境と必要スペックの目安

目安として、4bit量子化（Q4_K_M 等）で 10億パラメータあたり約0.6〜0.7GB のメモリを見込みます（8Bなら概ね5〜6GB前後）。GPUがなくても CPUのみで動作 しますが、速度は数倍遅くなります。

5-1.【macOS / Windows】公式サイトからダウンロード

ブラウザで ollama.com/download を開き、OSタブ（macOS / Windows / Linux）を選んで ダウンロードボタン を押します。

図：ダウンロードページ。OSタブを切り替えると各OS向けの入手方法が表示されます（再現イメージ）。

ダウンロードしたインストーラーを実行し、画面の指示に従ってインストールします（macOS はアプリを「アプリケーション」へドラッグ、Windows はインストーラーを実行するだけ）。

5-2.【macOS / Windows】起動している状態を確認

インストールすると Ollama は バックグラウンドのデーモンとして自動起動 します。起動中は、macOS はメニューバー右上、Windows はタスクトレイ（右下） に Ollama のアイコンが常駐します。

図：起動中はアイコンが常駐します（左：macOS、右：Windows。再現イメージ）。

5-3.【Linux】ワンライナーでインストール

Linux は公式のインストールスクリプトが手軽です。ターミナルで次を実行します。

curl -fsSL https://ollama.com/install.sh | sh

スクリプトが依存関係の導入、ollama ユーザーの作成、systemd サービスの登録・起動 までを行い、最後に API が 127.0.0.1:11434 で利用可能 になった旨が表示されます。NVIDIA GPU があれば自動検出されます。

図：curl … | sh の実行結果。systemd サービスとして起動し、11434 ポートで待受を開始します。

※ パイプ実行に抵抗がある場合は、スクリプトを一度ダウンロードして中身を確認してから実行しても構いません。

5-4. インストールの確認

OS共通で、バージョン表示とローカルAPIの疎通を確認します。

ollama --version
curl http://localhost:11434/api/version
curl http://localhost:11434          # → Ollama is running

図：ollama --version と 127.0.0.1:11434 への疎通確認。Ollama is running が返れば正常です。

5-5. 初めてのモデル実行

いよいよモデルを動かします。ollama run は、モデルが未取得なら 自動でダウンロードしてから 対話モードに入ります。

ollama run llama3.1:8b

ダウンロード完了後、>>> プロンプトが出たら日本語でそのまま話しかけられます。入力内容は一切外部に送信されません。 対話を終えるときは /bye と入力します。

図：初回は自動でモデルを取得し、そのまま対話に入ります。日本語での応答も問題ありません。

5-6. モデルの管理

取得済みモデルの一覧や、いまメモリに載っているモデルは次のコマンドで確認できます。

ollama list      # 取得済みモデル一覧
ollama ps        # メモリにロード中のモデル
ollama pull qwen3:14b   # モデルだけ先に取得
ollama rm gemma3:4b     # モデルを削除

図：ollama list で取得済み一覧、ollama ps で現在ロード中のモデルとGPU使用状況を確認できます。

5-7. REST API から使う（アプリ組み込み）

Ollama はローカルにREST APIを立てているので、自作アプリやスクリプトから直接叩けます。ネイティブAPI（/api/chat）に加え、OpenAI互換エンドポイント（/v1/chat/completions） も用意されているため、既存のOpenAI向けSDKは接続先URLを差し替えるだけ で流用できます。

図：/api/chat（ネイティブ）と /v1/chat/completions（OpenAI互換）の両方が使えます。

Python から使う例（OpenAI互換）:

from openai import OpenAI
client = OpenAI(
    base_url="http://localhost:11434/v1",  # ← ここをローカルに向けるだけ
    api_key="ollama",                       # 任意の文字列でOK（既定は認証なし）
)
resp = client.chat.completions.create(
    model="llama3.1:8b",
    messages=[{"role": "user", "content": "自己紹介して"}],
)
print(resp.choices[0].message.content)

5-8. （おまけ）ブラウザUIで使いたいなら

CLIではなくブラウザのチャット画面で使いたい場合は、Open WebUI などのフロントエンドを Ollama（11434）に接続すると、ChatGPT風のUIでローカルモデルを扱えます。

6. よく使うコマンド早見表

7. セキュリティ上の注意点（重要）

• 既定はローカル専用・認証なし：127.0.0.1:11434 で待ち受け、認証はありません。同じマシン内だけで使う分には外部から到達できず安全です。
• LAN / インターネットへ公開するときは要注意：OLLAMA_HOST=0.0.0.0 などで待受を開放すると、認証なしのまま外部からアクセス可能 になってしまいます。実際に、設定を誤って公開されたOllamaサーバーが第三者に無断利用される事例も報告されています。公開が必要な場合は、
  • ファイアウォールで接続元を制限 する、
  • 認証付きのリバースプロキシ（Nginx / Caddy 等）を前段に置く、
  • VPN や SSH ポートフォワード経由に限定する、 といった対策を 必ず 併用してください。
• モデルの入手元に注意：モデルは信頼できる公式ライブラリから取得しましょう。

8. まとめ

Ollama は、LLMを自分のマシンで手軽に動かすための決定版ツールです。クラウドLLMと比べたときの核心は次の3点に集約されます。

1. プライバシー：データが外に出ない。
2. コスト：ハードウェアさえあれば推論は使い放題（従量課金なし）。
3. オフライン & 制御：ネット不要で動き、モデルを細かく制御・実験できる。

一方で、最先端の絶対性能や大規模同時アクセス はクラウド／専用サーバーに分があります。両者は排他ではなく、「軽い・機密・大量はローカル、難しい仕上げはクラウド」 と使い分けるのが賢い付き合い方です。

まずは ollama run llama3.1:8b の一行から、ローカルLLMの世界を体験してみてください。

本記事の図版のうち、アーキテクチャ図は同梱の ollama-architecture.drawio を draw.io（diagrams.net） で開くと自由に編集できます。ターミナル画面はコマンドの実挙動を、GUI画面は実画面に近い再現イメージを示しています。公開時はご自身の環境のスクリーンショットへの差し替えを推奨します。

【実装ガイド】Dataiku Cloudで作る R&D Value Navigator

前提

1. Dataiku DSS 14 の管理者アカウント（プラグイン、LLM接続、Agent Hub の設定で必要）

2. プロジェクト作成権限と Managed Folders 作成権限

3. LLM API キー（OpenAI 等）を Dataiku に登録済み（Agentが使う場合）

4. Code env（プロジェクト）に以下パッケージをインストールしておく（Designer/Modeler/Reporter 用）:

pandas, numpy, scipy, statsmodels, pyDOE2, scikit-learn, lightgbm, shap, python-pptx, matplotlib, dataiku

構成の要点

データフロー（raw_* のデータ群→前処理→feature→ROI/score→agent用ビュー）を Dataiku Flow として再現し、その上に Visual/Code Agent を配置して Agent Hub / Agent Connect で研究者がチャット操作できるようにします。

目次

1. データセット（名称とスキーマ）

2. Flow：レシピ（SQL / Prepare / Group / Join）一覧と実装コード

3. Agent 用ビュー（SQL） — agent_historical_search 等

4. Code Agent 実装（Experiment Designer / Simulation / Modeler / Reporter） — Dataiku 用 process() コード

5. Visual Agent（Historical / Knowledge）設定（Agent Tools / Prompt）

6. Agent Hub & Agent Connect 設定手順（Intent / Conversation profile）

7. テスト手順 & デバッグチェックリスト

8. 付録：よく使う Dataiku 操作のショートカット

1. データセット — 作成しておくもの

• raw_employees.csv employee_id, role, annual_cost
• raw_projects.csv project_id, project_title, start_date, end_date, status, project_lead
• raw_labor_hours.csv labor_id, employee_id, project_id, hours, date
• raw_expenses.csv expense_id, project_id, expense_type, amount
• raw_products.csv product_id, project_id, product_name
• raw_sales.csv sale_id, product_id, year, revenue
• raw_market.csv market_id, product_id, growth_rate
• raw_patents.csv patent_id, project_id, patent_score

2. Flow：レシピの順番と具体的SQL / Prepare 設定

各ステップは Flow で新規 Recipe（Prepare / Join / Group / SQL / Python）を作成して下さい。SQL は SQL レシピで実行可能です。

2.1 labor_cost_per_project の作成

操作：Join + Prepare

説明：raw_labor_hours JOIN raw_employees → 労務コスト算出（hours * annual_cost / 2000）

手順

Join Recipe: raw_labor_hours (left) JOIN raw_employees on employee_id Prepare Recipe: 新しいカラム labor_cost を追加（式）: labor_cost = hours * annual_cost / 2000

出力 dataset：labor_cost_per_project

2.2 labor_cost_project（プロジェクト別人件費集計）

操作：Group Recipe

Group by: project_id

Aggregation:SUM(labor_cost) -> total_labor_cost

出力 dataset：labor_cost_project

2.3 other_cost_project（外注等の経費集計）

操作：Group Recipe on raw_expenses

Group by: project_id

Aggregation:SUM(amount) -> total_other_cost

出力 dataset：other_cost_project

2.4 project_total_cost（総コスト）

操作：Join labor_cost_project LEFT JOIN other_cost_project on project_id → Prepare: total_cost = total_labor_cost + total_other_cost

出力 dataset：project_total_cost

2.5 project_revenue（製品売上をプロジェクト集約）

操作：Join raw_products JOIN raw_sales on product_id → Group by project_id:SUM(revenue) -> total_revenue AVG(revenue) -> avg_annual_revenue

出力 dataset：project_revenue

2.6 project_roi（ROI算出）

操作：Join project_revenue JOIN project_total_cost on project_id → Prepare:

roi = (total_revenue - total_cost) / total_cost revenue_cost_ratio = total_revenue / total_cost

出力 dataset：project_roi

2.7 raw_roi_summary（Success/Strategic Score算出） — PDFロジックそのまま

操作：Join project_roi JOIN raw_patents on project_id → Prepare（SQL または Prepare）

式（SQL 表現推奨）:

-- SQL recipe: create raw_roi_summary SELECT p.project_id, p.total_revenue, c.total_cost, ROUND((p.total_revenue - c.total_cost)/c.total_cost, 4) AS roi, r.patent_score, CASE WHEN ( (p.total_revenue - c.total_cost)/c.total_cost ) > 1.5 AND r.patent_score > 80 THEN 5 WHEN ( (p.total_revenue - c.total_cost)/c.total_cost ) > 1.2 THEN 4 WHEN ( (p.total_revenue - c.total_cost)/c.total_cost ) > 1.0 THEN 3 WHEN ( (p.total_revenue - c.total_cost)/c.total_cost ) > 0.8 THEN 2 ELSE 1 END AS success_score, ROUND( (CASE WHEN ( (p.total_revenue - c.total_cost)/c.total_cost ) > 1.5 AND r.patent_score > 80 THEN 5 WHEN ( (p.total_revenue - c.total_cost)/c.total_cost ) > 1.2 THEN 4 WHEN ( (p.total_revenue - c.total_cost)/c.total_cost ) > 1.0 THEN 3 WHEN ( (p.total_revenue - c.total_cost)/c.total_cost ) > 0.8 THEN 2 ELSE 1 END) * 0.6 + r.patent_score * 0.4, 2) AS strategic_score FROM project_revenue p LEFT JOIN project_total_cost c ON p.project_id = c.project_id LEFT JOIN raw_patents r ON p.project_id = r.project_id

出力 dataset：raw_roi_summary

3. Agent 用ビュー（SQL） — agent_historical_search

目的：過去のプロジェクトを検索・類似抽出するためのビューを作成。Agent が参照します（Historical Agent 用）。

SQL レシピ（そのまま貼れる）:

-- agent_historical_search SELECT project_id, project_title, roi, strategic_score, total_revenue, total_cost, patent_score FROM raw_roi_summary WHERE roi IS NOT NULL

出力 dataset：agent_historical_search

この dataset を Knowledge Bank 的に Visual Agent の「Dataset Lookup」ツールで参照します。

4. Code Agent 実装

以下は Dataiku Code Agent にそのまま貼れる process() の骨子です。Dataiku の Code Agent 作成時に process(inputs, outputs) を実装します（ファイル入出力は Dataiku API を使用）。

注意：Dataiku の Code Agent 環境では dataiku モジュールが利用可能です。Managed Folder や Dataset の読み書きは dataiku.Folder / dataiku.Dataset を使ってください。

4.1 Simulation Agent（Code Agent） — PDF準拠の NPV / IRR 計算

# simulation_agent.py (Code Agent: process) import json import numpy as np def process(inputs, outputs): # inputs: expect json with "cashflows" (list), "discount_rate" payload = inputs.get("payload") if isinstance(payload, str): payload = json.loads(payload) cashflows = payload.get("cashflows", []) # e.g., [-1000, 300, 400, 500] discount = payload.get("discount_rate", 0.08) if not cashflows: raise ValueError("cashflows missing") # NPV npv = sum(cf / ((1+discount)**i) for i, cf in enumerate(cashflows)) # IRR (numpy.irr may be deprecated; use numpy_financial if available; fallback: np.irr) try: irr = np.irr(cashflows) except Exception: try: import numpy_financial as nf irr = nf.irr(cashflows) except Exception: irr = None outputs["simulation_json"] = json.dumps({"npv": float(npv), "irr": float(irr) if irr is not None else None})

4.2 Experiment Designer Agent — サンプルサイズ算出（Code Agent）

# experiment_designer_agent.py import json import math from statsmodels.stats.power import TTestIndPower import dataiku def process(inputs, outputs): planner = inputs.get("planner_json") if isinstance(planner, str): planner = json.loads(planner) # extract params or defaults baseline = planner.get("baseline", 0.2) min_effect = planner.get("min_effect", 0.05) alpha = planner.get("alpha", 0.05) power = planner.get("power", 0.8) # For proportions you'd use proportion_effectsize, but we default to Cohen's d approximation effect_size = planner.get("effect_size", min_effect) analysis = TTestIndPower() n_per_group = math.ceil(analysis.solve_power(effect_size=effect_size, alpha=alpha, power=power, alternative='two-sided')) protocol = { "design_type": "two_group_ttest", "n_per_group": n_per_group, "total_n": n_per_group * 2, "alpha": alpha, "power": power, "variables": planner.get("required_data", []), "hypothesis": planner.get("hypothesis", "") } outputs["protocol_json"] = json.dumps(protocol)

4.3 Modeler Agent — LightGBM + SHAP（Dataiku 用。Managed Folder へ保存）

# modeler_agent.py import json, os import pandas as pd import numpy as np import dataiku from lightgbm import LGBMRegressor from sklearn.model_selection import train_test_split import shap import matplotlib.pyplot as plt def process(inputs, outputs): # inputs: "experiment_csv_path" or Dataiku dataset name csv_path = inputs.get("experiment_csv_path") dataset_name = inputs.get("dataset_name") project_id = inputs.get("project_id", "proj_unknown") # load data if dataset_name: ds = dataiku.Dataset(dataset_name) df = ds.get_dataframe() else: df = pd.read_csv(csv_path) # target must be "measurement" per schema if "measurement" not in df.columns: raise ValueError("measurement column required") y = df["measurement"] X = df.drop(columns=["measurement"]) X = X.fillna(X.median()) X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.2, random_state=42) model = LGBMRegressor(n_estimators=200) model.fit(X_train, y_train) preds = model.predict(X_test) rmse = float(np.sqrt(((preds - y_test)**2).mean())) r2 = float(model.score(X_test, y_test)) # SHAP explainer = shap.TreeExplainer(model) shap_values = explainer.shap_values(X_test) out_folder = dataiku.Folder("reports_folder_id") # create in Dataiku and replace ID # save shap figure plt.figure() shap.summary_plot(shap_values, X_test, show=False) shap_path = f"/tmp/{project_id}_shap.png" plt.savefig(shap_path, bbox_inches="tight", dpi=150) # write shap to managed folder with out_folder.get_writer(f"{project_id}_shap.png") as w: with open(shap_path, "rb") as r: w.write(r.read()) importance = dict(zip(X.columns.tolist(), model.feature_importances_.tolist())) analysis = {"metrics": {"rmse": rmse, "r2": r2}, "importance": importance, "plots": {"shap": f"{project_id}_shap.png"}} outputs["analysis_json"] = json.dumps(analysis)

重要：reports_folder_id は Dataiku 内で作成した Managed Folder の ID に置換してください（Folder の設定 → Advanced → ID で確認できます）。

4.4 Reporter Agent — pptx 生成（Dataiku Managed Folder へ保存）

# reporter_agent.py import json from pptx import Presentation from pptx.util import Inches import dataiku def process(inputs, outputs): analysis_json = inputs.get("analysis_json") project_id = inputs.get("project_id", "proj_unknown") if isinstance(analysis_json, str): analysis = json.loads(analysis_json) else: analysis = analysis_json prs = Presentation() # Title slide slide = prs.slides.add_slide(prs.slide_layouts[0]) slide.shapes.title.text = f"R&D Navigator Report - {project_id}" # Metrics slide slide = prs.slides.add_slide(prs.slide_layouts[1]) slide.shapes.title.text = "Key Metrics" tf = slide.shapes.placeholders[1].text_frame tf.clear() tf.add_paragraph(f"RMSE: {analysis['metrics']['rmse']}") tf.add_paragraph(f"R2: {analysis['metrics']['r2']}") # Importance slide slide = prs.slides.add_slide(prs.slide_layouts[1]) slide.shapes.title.text = "Feature Importance" tf = slide.shapes.placeholders[1].text_frame tf.clear() for k, v in analysis['importance'].items(): tf.add_paragraph(f"{k}: {v}") # insert SHAP image from managed folder reports_folder = dataiku.Folder("reports_folder_id") shap_fname = analysis['plots']['shap'] # Download shap into temp file and insert local_shap = f"/tmp/{shap_fname}" with reports_folder.get_download_stream(shap_fname) as stream: with open(local_shap, "wb") as f: f.write(stream.read()) slide = prs.slides.add_slide(prs.slide_layouts[5]) slide.shapes.add_picture(local_shap, Inches(1), Inches(1), width=Inches(8)) # Save PPTX to managed folder fname = f"report_{project_id}.pptx" with reports_folder.get_writer(fname) as w: prs.save(w) outputs["report_path"] = f"{reports_folder.get_path()}/{fname}"

5. Visual Agent の設定（Historical / Knowledge） — 手順とプロンプト

5.1 Historical Agent（Visual Agent）作成手順

1. Project → + → Generative AI → Visual Agent を選択

2. 名前: Historical_Agent（説明に用途）

3. LLM 接続: 管理者が用意した OpenAI / Claude の connection を選択

4. Agent Tools に Dataset Lookup を追加 → dataset に agent_historical_search を指定（上で作成）

5. Retrieval 設定: top_k = 5、スコア閾値を適宜設定

6. Prompt / Instructions（例）:

You are Historical Agent for R&D Navigator. Given a query about a project or a new idea, search the agent_historical_search dataset and return: - top 3 similar projects (project_id, roi, strategic_score) - short summary (1-3 sentences) of why they are similar - any lessons learned (from project metadata) Output as JSON: { similar_projects: [...], summary: "...", lessons: [...] }

この Visual Agent は PDF の Historical Agent の役割（過去事例検索）に直接対応します。

5.2 Knowledge / RAG Agent（もし使う場合）

• Knowledge Bank に PDF や社内の報告書をアップロードし、Embedding Search ツールを設定する。
• Visual Agent の Tool に Knowledge Bank Search を追加し、ユーザーの問い合わせに対して参照文献を返すように設定。

6. Agent Hub（Orchestrator）設計・設定

6.1 Agent の登録

Agent Hub で次を登録：

Historical_Agent（Visual） Experiment_Designer（Code） Simulation_Agent（Code） Modeler_Agent（Code） Reporter_Agent（Code）

6.2 Orchestrator のルール（Intent → Agent）

例ルール（Agent Hub の routing 設定で作成）：

• Intent contains “過去” or “similar” → Historical_Agent
• Intent contains “サンプルサイズ” or “power” or “実験設計” → Experiment_Designer
• Intent contains “シミュレーション” or “NPV” or “IRR” → Simulation_Agent
• Intent contains “解析” or “モデル” or “学習” → Modeler_Agent
• Intent contains “レポート” or “報告” → Reporter_Agent

6.3 シーケンス（Pipeline）例

Orchestrator が Planner の出力を受け、次に Designer、次に Modeler、最後に Reporter を順に呼ぶようパイプライン定義を行う（Agent Hub の Pipeline 機能で可視化）。

7. Agent Connect / Dataiku Answers 設定（研究者向けチャットUI）

7.1 Agent Connect インストール（管理者）

Plugin ストアから Agent Connect をインストール（管理者のみ）

7.2 Conversation Profile（例）

名前: R&D_Navigator_Profile

説明: “研究目的を入力すると Planner→Designer→Modeler→Reporter を順に実行します”

Profile 設定項目

• Default Orchestrator: Agent Hub の Orchestrator（上で作成）
• Available Agents: Historical_Agent, Experiment_Designer, Simulation_Agent, Modeler_Agent, Reporter_Agent
• File upload enabled: yes (uploads go to inputs Managed Folder)
• Conversation store: ON (保存先と保持ポリシーを設定)

7.3 UI カスタマイズ（推奨）

ファイルアップロードボタン（inputs folder） 「実行」ボタン（Orchestrator に run コマンド） 「状況確認」ボタン（projects dataset の status を表示）

8. テスト手順 & デバッグチェックリスト

単体テスト（Agentごと）

• Historical Agent: 入力例「似たプロジェクトを教えて」→ agent_historical_search から3件返るか確認
• Experiment Designer: 固定 planner_json を投げ、n_per_group が妥当か（期待値）
• Modeler: サンプル CSV（小規模）で学習→analysis_json が返るか、plots が managed folder に保存されるか

E2E テスト

1. Agent Connect で converse: 「新触媒Xで歩留まりを10%改善したい。予算50万円。」

2. Orchestrator が Planner → Designer → （ユーザー同意）→ Modeler（dummy）→ Reporter を順に実行。

3. projects dataset の status が reported になり、reports/ Managed Folder に PPTX が生成されることを確認。

デバッグのポイント

• Code Agent 実行時のエラーログは Agent Hub の実行ログで取得（Stacktrace を確認）
• Managed Folder ID の不一致 → ファイル入出力で「Folder not found」エラーが出る（ID確認）
• LLM のレスポンスが想定外 → Visual Agent の Prompt を修正（Instruction を具体化）

9. セキュリティ & ガバナンス（必須）

• Managed Folder 書き込み権限は研究者/開発者のみ付与
• LLM に送る入力は PIIや企業機密を除去するフィルタを作る（Code Agent で sanitize）
• Conversation の保存・アクセスログを有効にし、保持期間とアクセス権を制定

10. 付録：よく使う Dataiku 操作ショートカット（UI手順）

• Managed Folder ID 確認：Folder → Settings → Advanced → ID
• Code Env パッケージ追加：Project → Settings → Code env → Edit → Add packages
• Code Agent 作成：Flow → + → Generative AI → Code Agent → Create → paste process()
• Visual Agent 作成：Flow → + → Generative AI → Visual Agent → configure Tools & Prompt
• Agent Hub 設定：Administration → Generative AI → Agent Hub → Create Team / Pipeline

11. まとめ（実装の流れ・優先度）

1. Raw datasets を Flow に追加（names/columns を PDF 準拠で）

2. 前処理（Join / Group / Prepare）を順に作る → raw_roi_summary まで構築（SQLレシピを活用）

3. agent_historical_search の dataset を作る（Agent 用ビュー）

4. Managed Folders（inputs, plans, protocols, reports）を作る

5. Code Agent（Simulation, Designer, Modeler, Reporter）を作成して process() を実装

6. Visual Agent（Historical）を作って dataset lookup を設定

7. Agent Hub にエージェントを登録・Orchestrator ルールを作る

8. Agent Connect（Answers）でチャット UI を公開し E2E テスト