# 情報活用基盤 技術検証まとめ

**目的**: 生産本部における「AIチャットを介した企画業務支援 × 組織知の自動蓄積」というコンセプトが、Snowflake上でどこまで技術的に実現可能かを検証し、実現に向けた構成案と論点を整理する。

**前提**: 本ドキュメントは「完成したシステムの仕様書」ではなく、「実現可能性を確認するためのプロトタイプ検証の記録」である。各所で複数の実装パターンを比較しているのは、どれか一つが正解というより、採用にあたって判断すべき論点がある、ということを示すため。

---

## 0. 前提:LLMとは何か

本題に入る前に、AIチャットの土台にある技術の本質を確認しておく。ChatGPTやCopilotのようなAIチャットは、なんでも自動でやってくれる箱のように見えるが、その中心にあるLLM(大規模言語モデル)という技術そのものは、実は極めてシンプルである。

> **文字列を入れると、文字列が返ってくる。ただそれだけの関数である。**

これだけでは、前回の会話を覚える・社内資料を自分で調べに行く・複数ステップの判断をする・画面に何かを表示する、といったことは一切できない。これらは全て、LLMという関数の**外側**に、人間が別途プログラムを書いて実現している部分である。

この「複雑な中身を隠し、外からは入出力だけ意識すればよい状態にする」考え方は、コンピューターサイエンスで**抽象化(abstraction)**と呼ばれる。中身が見えない状態を指して**ブラックボックス**とも言う。以下で説明するCortex AgentやCortex Searchは、この抽象化がすでに施された、完成度の高い部品として提供されている。この前提を踏まえると、以降の「なぜプラットフォームの機能に乗っかるべきか」という議論の理由が一貫して理解できる。

---

## 1. 全体構想

企画業務担当者が、日々の相談・資料作成をAIチャットの中で完結させる。その過程で生まれる暗黙知(進め方のコツ、リスク回避の知見、コミュニケーション上の工夫など)を自動的に抽出・蓄積し、他のメンバーが同じチャットを使う際に、その知見を踏まえた回答が得られるようにする。将来的には「仕事の型(スキル)」自体もシステム化し、AIが状況に応じて適切な型を踏まえて振る舞えるようにする。

### コアループ

```
ユーザーがAIチャットで相談
    → 会話の中から暗黙知を抽出
    → 共通データベースに蓄積
    → 別のユーザーの相談時に、その知見を検索して回答に活用
    → 使うほど、組織全体の回答品質が上がる
```

---

## 2. 全体アーキテクチャ

![情報活用基盤の全体アーキテクチャ](./architecture_diagram.svg)

上図は、企画担当者から知識蓄積ループまでの全体の流れを示したもの。「スキル(仕事の型)」の箱に記載の通り、ここは複数の実装パターンを比較検討した箇所であり、詳細は6章を参照。知識蓄積ループは、会話ログから暗黙知を抽出・タグ付けして知識ベースに保存し、その内容が再びCortex Searchの検索対象として反映される、というループ構造になっている(7章で詳述)。

検証した要素を、Snowflakeの機能にマッピングすると以下の通り。

| 情報活用基盤の要素 | 対応するSnowflakeの機能 | 検証状況 |
|---|---|---|
| AIチャットのUI | Streamlit in Snowflake | 実機検証済み |
| 資料の取り込み | ステージ、`AI_PARSE_DOCUMENT` | 概念検証済み |
| 暗黙知の検索(RAG) | Cortex Search | 実機検証済み |
| 暗黙知の抽出・タグ付け | `AI_COMPLETE`、`AI_CLASSIFY` | 実機検証済み |
| チャットの応答生成・ツール自動選択 | Cortex Agents | 実機検証済み |
| 会話の継続性 | Cortex Agents Threads | 実機検証済み |
| 仕事の型(スキル)の適用 | プロンプト注入 / Agent instructions 更新 / スキル別Agent切替 | 実機検証済み(1パターン)+設計比較 |
| 自動化パイプライン | Task、Stream | 設計検証済み(実装は今後) |
| 構造化データとの連携 | Cortex Analyst | 未検証(優先度低) |
| 権限・展開設計 | ロールベースアクセス制御、Row Access Policy | 設計整理済み |

---

## 3. フェーズ1: RAG(検索拡張生成)の基礎

### 3.1 何を検証したか

社内の暗黙知をテーブルに保存し、Cortex Search Serviceでインデックス化。ユーザーの質問に対して意味的に近い知見を検索し、その検索結果を踏まえてLLMに回答させる、という基本ループを構築・動作確認した。

### 3.2 分かったこと

- Cortex Searchは、単純なベクトル類似度だけでなく、**キーワード一致度(text_match)と専用の再ランキングモデル(reranker_score)を組み合わせたハイブリッド検索**で、最終的な検索順位を決定している。単純な類似度が高くても、再ランキングで順位が入れ替わることがある
- 埋め込みモデルには**512トークン程度の壁**があり、これを超える長文はチャンク分割(`SPLIT_TEXT_RECURSIVE_CHARACTER`)が必要
- チャンクの文脈維持には「オーバーラップ(前後のチャンクを少し重複させる)」という標準機能が用意されており、栄さん側で「チャンクの先頭に文書全体の要約を付与する」といった追加実装は、Snowflakeの提供する仕組みだけで基本的には不要と考えられる

### 3.3 検討した実装パターン(比較)

**非構造化データ(PDF/PPTX)のテキスト化について**

| パターン | 内容 | 評価 |
|---|---|---|
| A. テキスト抽出のみ | `AI_PARSE_DOCUMENT`でテキスト化してからチャンク化 | 技術的に成熟。まずここから着手すべき |
| B. マルチモーダル(ページを画像として埋め込み) | OCRを介さず、ページ全体を画像として意味空間に埋め込む(`voyage-multimodal-3`等) | 発展途上の技術。グラフ・図表の情報を落とさないメリットはあるが、本格導入は時期尚早 |

**結論**: まずはパターンAで基盤を作り、精度に不満が出た場合にパターンBへの拡張を検討する、という段階的な採用を推奨。

---

## 4. フェーズ2: 暗黙知抽出

### 4.1 何を検証したか

チャットの会話履歴から、`AI_COMPLETE`を使って「他者にも役立つ知見」を抽出し、`AI_CLASSIFY`でタグ付けした上で、知識ベースのテーブルに保存する、という一連の処理を実機で確認した。ボタン押下によるオンデマンド実行と、コンテナランタイム環境の両方で動作を確認済み。

### 4.2 タグ設計という、Canon固有の設計ポイント

Cortex Searchの`ATTRIBUTES`や`AI_CLASSIFY`は、Snowflakeが提供する汎用的な"仕組み"に過ぎない。**「どんなタグの分類軸を用意するか」は、生産本部の業務理解に基づいて栄さん(あるいはチーム)が設計すべき、汎用ベンダーが代替できない部分**である。

検討したタグの種類:
- 機械的に決まるもの(ファイル名、日時、プロジェクト名)
- 意味づけが必要なもの(事業グループ、知見の性質、企画のフェーズ、機密度・共有範囲)

### 4.3 前処理コストという、見落としがちな論点

チャンク数 × タグ付けの回数、という掛け算でLLM呼び出し回数が線形に増える。資料が増えるほど、前処理コストが積み上がる。対策として、軽量モデルの活用、差分のみの処理、`SNOWFLAKE.ACCOUNT_USAGE.CORTEX_FUNCTIONS_USAGE_HISTORY`によるコスト可視化が有効。

---

## 5. Cortex Agentsによるオーケストレーション

### 5.1 何を検証したか

ツールの自動選択(検索すべきか、直接回答すべきか)、複数ターンにわたる会話の継続(Threads)を、実際にStreamlitアプリ(コンテナランタイム)から呼び出して検証した。

### 5.2 分かったこと

- Agentは「指示(instructions)」+「Snowflakeが内部に持つ隠蔽された基盤指示」を合成した上で、ツール呼び出しの判断・実行・振り返りという反復ループを回している。このループの制御自体はSnowflakeに一任できる
- オーケストレーション用モデルは、個別に選ぶより`auto`(Snowflakeが自動で最適なモデルを選択)が公式に推奨されている
- 会話の継続性は、`Thread`という仕組みにより、開発側で会話履歴を毎回組み立てる必要がない
- ただし、**アドホックなファイル添付(Copilotのような「今この場でファイルを渡して聞く」体験)に相当する、専用の仕組みは見当たらなかった**。事前にテキスト化してプロンプトに埋め込む、という代替実装が必要

### 5.3 構造化データとの連携(応答の出力形式)

Cortex Analystと組み合わせることで、構造化データを使った回答も、以下のように段階的に高度化できることが分かった(概念確認、実機未検証)。

| レベル | できること | 必要な設定 |
|---|---|---|
| 1 | 数値を文章に埋め込んで回答 | Cortex Analystの標準機能 |
| 2 | 実際にグラフを生成して表示 | `Data to Chart`ツールを追加 |
| 3 | より柔軟な計算・加工 | `Code execution`ツールを追加 |

単純な数値埋め込みだけでなく、グラフ生成まで、ゼロからの作り込みではなく「部品を追加するだけ」で実現できる可能性がある。

### 5.4 業界的な位置づけ

「LLMを自作のロジックで制御する」のではなく「オーケストレーション機構自体をプラットフォームに委ねる」という設計方針は、Snowflake固有の話ではなく、Microsoft Copilot Studioなど業界全体で共通する潮流と考えられる。一方で、独自に頑張って作り込んだ制御ロジックが、後にプラットフォームの標準機能に置き換えられ陳腐化する、といった現象(いわゆる"GPTラッパー問題"、"Sherlocking")も広く議論されている。この観点からも、**汎用的なオーケストレーション部分は極力プラットフォームに委ね、Canon固有の業務ロジック・タグ設計にこそ独自の投資を割く**、という方針は妥当と考えられる。

### 5.5 品質担保の考え方

Agentの内部処理は基本的にブラックボックスであり、「どう組まれているか」を覗き込むことはできない。この前提のもと、Snowflakeは「Tool selection accuracy」「Groundedness」「Logical consistency」といった評価指標(Evaluations機能)を提供しており、**中身を検査する代わりに、出力を継続的に評価する**、という業界標準的なアプローチ(LLM-as-a-Judge)に沿っている。ただしこの手法自体にも既知のバイアス(長さ・順序・自己好み)があるため、自動評価と人手によるレビューを組み合わせる必要がある。

---

## 6. フェーズ3: スキル(仕事の型)の実装

「進め方のコツ」のような知見だけでなく、「企画立案はこう進める」という手順そのものをシステムに組み込み、AIの振る舞いに反映させる仕組みを検証した。ここでは3つの実装パターンを比較検討した。

| パターン | 概要 | 持続性 | 実装コスト | 検証状況 |
|---|---|---|---|---|
| ① 都度プロンプト注入 | 選択したスキルの手順を、毎回の質問文に埋め込んで送信 | その場限り(会話ターンごとに再送が必要) | 低い | **実機検証済み・動作確認済み** |
| ② Agent instructions の動的書き換え | `ALTER AGENT`でAgent自体の恒久設定にスキルを書き込む | Agentが存在する限り持続 | 中(共有オブジェクトのため、セッションごとの専用Agent生成が必要になり得る) | 未実装(設計のみ) |
| ③ スキルごとの事前作成Agent+スレッド共有 | スキルごとに個別のAgentを事前に用意し、共通のthread_idで呼び出し先を切り替える | Agent単位で持続、切替時も文脈維持を期待 | 中〜高 | 未実装。構造的には妥当と考えられるが、Snowflakeでの公式サポートは未確認 |

**論点**: パターン①はCopilotのような「セッション開始時に一度設定すれば、以降ずっと効き続ける」体験とは異なり、都度の指示文再送が必要になる。パターン②・③はより自然な体験に近づくが、Agentが複数ユーザーで共有されるオブジェクトであることに起因する競合リスク・実装コストが伴う。**初期導入は①で十分に機能性を示せるが、UXの質を追求する場合は②③への発展余地がある。**

---

## 7. フェーズ4: 自動化パイプラインの設計(概念整理)

自動化には性質の異なる2種類があり、明確に区別して設計すべきという結論に至った。

### 7.1 知見(データ)の自動蓄積

- 会話ログをテーブルに記録し、Snowflakeの`Stream`(差分検知)と`Task`(定期実行)を組み合わせ、新しい会話から自動的に知見を抽出・保存する
- リスクが比較的低い(悪くても質の低い知見が1件混ざる程度)ため、完全自動化に適する

### 7.2 スキル(振る舞い)の改善

- ユーザーからのフィードバック(👍👎などの簡易評価)を蓄積し、AIに改善案を定期的に生成させることまでは自動化する
- ただし、**実際にスキルの手順やAgentの instructions を書き換える最終判断は、必ず人間の承認を経る**設計とする。スキルはAgent全体・全ユーザーに影響する共有設定であるため、自動書き換えのリスクが高いことがその理由

### 7.3 蓄積後のデータメンテナンス(検討した選択肢)

長期運用で知見が蓄積した後の「整理」については、以下のような方向性が考えられるが、いずれも実際に運用しながら知見を積み上げる必要がある未解決の課題である。

1. **重複・類似の検出と統合**: Cortex Searchで類似知見を検出し、統合候補をAIに提示させ、人間が承認して統合する
2. **利用実績に基づく棚卸し**: 検索でヒットした実績を追跡し、長期間参照されていない知見を洗い出す
3. **矛盾の検出**: 新規追加時に、既存知見との矛盾をAIに判定させ、疑わしい場合はレビューキューに回す
4. **タグ体系自体の見直し**: データが増えるにつれ、当初設計した分類軸が実態に合わなくなる可能性があり、定期的に分類軸そのものの妥当性を評価する
5. **鮮度の考慮**: 情報の種類によって「古さ」の重要性が異なるため、一律の消滅ではなく、知見の性質に応じた扱いが必要

**共通する設計原則**: 自動化するのは「発見・提案」までとし、「実行・適用」には常に人間の承認を介在させる。

---

## 8. 権限・セキュリティ設計上の重要な論点

### 8.1 Streamlitアプリは「所有者の権限」で動く

ストアドプロシージャと同様、Streamlitアプリはデフォルトで「アプリ作成者の権限」で実行される。閲覧者自身の権限では動かないため、**組織横断でのアクセス制御(誰がどの情報を見られるか)を、Snowflakeネイティブの行アクセス制御だけに任せることはできない**。

### 8.2 検討した対応パターン

| パターン | 概要 | 評価 |
|---|---|---|
| A. READ SESSION権限の付与 | コンテキスト関数に本当の閲覧者情報を反映させる | アカウント全体への強い権限付与が必要で、慎重な検討を要する |
| B. Restricted Caller's Rights | 閲覧者自身の権限でクエリを実行する(コンテナランタイム) | プレビュー機能のため、本番設計への採用は時期尚早 |
| C. アプリケーション層でのフィルタ | `st.user`で閲覧者を識別し、Cortex Searchの検索フィルタと組み合わせて絞り込む | 現状もっとも確実で統制しやすい。タグ設計を権限制御にも転用できる |

### 8.3 編集権限の重大なリスク

アプリの編集権限を持つ者は、所有者の権限(検証時はACCOUNTADMIN相当)を事実上行使できてしまう。本番設計では、**アプリ運用に必要な最小限の権限だけを持つ専用ロールを作成し、そのロールにアプリを所有させる**という「最小権限の原則」の徹底が必須。

---

## 9. コストの考え方

実運用データがない段階では、仮説パラメータを積み上げて試算するしかない。

### コストの構成要素

2026年4月からSnowflakeは、AI関連の課金を「AI Credits」という、通常のウェアハウス課金(Platform Credits)とは別建ての通貨に分離した。本基盤は両方にまたがってコストが発生する。

| 費目 | 課金基準 |
|---|---|
| AI_COMPLETE / AI_CLASSIFY(抽出・タグ付け) | 処理トークン数(モデルにより10〜40倍の単価差) |
| Cortex Agents(チャット応答) | 同上 |
| Cortex Searchのサービング | インデックスのデータ量(GB)に対する月額固定費、常時課金 |
| Cortex Searchの埋め込み計算 | データ追加・更新時のトークン量 |
| AI_PARSE_DOCUMENT | 処理ページ数 |
| ウェアハウス/コンピュートプール | 秒単位のPlatform Credits |

### 試算に必要な仮説パラメータ

利用規模(利用者数、1人1日あたりの往復数)、知識蓄積(1日あたりの新規知見件数、抽出・タグ付けのトークン数)、モデル選択、インフラ稼働時間、といった仮説値を置いて積み上げる。実際にパラメータを調整しながら比較できる、インタラクティブな試算ツールを別途用意した。

### 見つかった節約策

- **プロンプトキャッシュの活用(最大90%引き)**: 同じ文脈(システムプロンプトやスキルの手順文)を繰り返し送ると、2回目以降はキャッシュ扱いになり通常単価の約10%で課金される(1回あたり1,024トークン以上の再利用が条件)。フェーズ3のスキル実装パターン①(都度プロンプト注入)は、この恩恵を受けやすい構造でもある
- **モデル選択(最大10〜40倍の差)**: Snowflakeネイティブの軽量モデルは、抽出・分類のようなバッチ的作業に対して、上位モデルより明確に安い
- **出力トークンの抑制**: 上位モデルほど出力トークンは入力の3〜6倍のコスト。JSON形式で簡潔に答えさせる設計自体がコスト対策になる
- **その他**: `TRY_COMPLETE`/`TRY_CLASSIFY`でエラー時の無駄な課金を回避、`CORTEX_MODELS_ALLOWLIST`で高額モデルへの誤アクセスを制限、`AUTO_SUSPEND`を短く設定

### 実測・監視の方法

Snowsightの「管理者 > コスト管理」ダッシュボードでAI支出だけを絞り込んで確認できるほか、`SNOWFLAKE.ACCOUNT_USAGE`スキーマのビューで詳細分析ができる。

```sql
SELECT function_name, model_name, user_name, warehouse_name,
       DATE_TRUNC('day', start_time) AS usage_date,
       SUM(credits_used) AS total_credits
FROM SNOWFLAKE.ACCOUNT_USAGE.CORTEX_AI_FUNCTIONS_USAGE_HISTORY
WHERE start_time >= DATEADD(month, -1, CURRENT_TIMESTAMP())
GROUP BY 1,2,3,4,5 ORDER BY usage_date DESC;
```

Resource Monitorで消費上限を設定し閾値超過時に通知・強制停止させることもでき、Snowflakeによるコスト異常検知機能もある。運用開始後は、試算ツールの前提値を実測値で定期的に更新していく想定。

---

## 10. 検討した実装パターン一覧

検証の過程で、唯一解ではなく複数の選択肢を比較した箇所を、ここに集約する。

| 論点 | 選択肢 | 本検証での判断 |
|---|---|---|
| 非構造化データの取り込み | ①テキスト抽出のみ / ②マルチモーダル(画像埋め込み) | ①から着手、精度不足なら②を検討 |
| スキルの実装 | ①都度プロンプト注入 / ②Agent instructions書き換え / ③スキル別Agent+スレッド共有 | ①を実装・検証、②③は設計のみ |
| 権限・アクセス制御 | ①READ SESSION付与 / ②Restricted Caller's Rights / ③アプリ層でのフィルタ | ③が現状もっとも確実 |
| 質問のルーティング | ①事前分類してから検索 / ②両方検索してAIに取捨選択させる | ②から着手が無難(取りこぼしリスクが低い) |
| システム構成全体 | ①自前構築 / ②Copilot Studio等の標準機能 / ③外部委託 / ④ハイブリッド | 業務内容の具体化後に判断(12章) |

---

## 11. 未検証・今後の課題

- **Cortex Analyst(構造化データとの自然言語連携)**: 優先度を下げて後回しにしており、未検証
- **スキルの実装パターン②③**: 設計は整理したが、実機での動作検証は未実施
- **蓄積データのメンテナンス手法**: 複数の方向性を洗い出したが、どれが最適かは実際の運用データを見ながらでないと判断できない
- **組織展開時のコスト試算**: 前処理コスト(チャンク化・タグ付け)は資料量に比例して増加するため、本格導入前に対象範囲(全社か、本部内限定か、過去資料をどこまで遡るか)のスコープ確定と、それに基づくコスト試算が必要

---

## 12. 次のアクション:技術から業務への橋渡し

技術的に「作れる」という土台は固まった。次に必要なのは、企画業務のどこにAIが関わるかの具体化である。

### 業務棚卸しの必要性

システム構成(自前で作るか、外部に頼むか、Copilot Studio等の標準機能で一部を賄うか)は、「AIに何をさせたいか」が決まって初めて判断できる。企画業務を時系列で棚卸しし、各ステップで「今どんな情報を、どこから得ているか」「そこにどんな"痛み"があるか」「その痛みはAIチャット+蓄積知見で解消されそうか」を洗い出す必要がある。

```
① 案件の着手 → ② 情報収集 → ③ 論点整理・仮説立て
→ ④ 関係部署への根回し → ⑤ 資料作成
→ ⑥ 上申・承認プロセス → ⑦ 実行・フォローアップ
```

この棚卸しは一人の経験だけでなく、他の企画メンバーにも行ってもらい、共通する痛みと個人差のある痛みを仕分けるのが理想的である。

### Build vs Buy の判断軸

| 選択肢 | 向いているケース | リスク・制約 |
|---|---|---|
| Copilot Studio等、既存の標準機能 | 単純な壁打ち、汎用的な資料生成支援 | Canon固有のタグ設計のような資産を積み上げにくい可能性 |
| Snowflakeベースで自前構築 | 暗黙知の蓄積、タグ設計、社内固有の検索基盤 | 実装・運用コストは決して軽くない |
| 外部ベンダーに委託 | 自部門にエンジニアリングリソースがない場合 | Canon固有の知識を外部にどこまで正確に伝えられるかが成否を分ける |
| ハイブリッド | 現実的には最も多くの企業が採る形 | 「どこを自前にするか」の切り分け自体が設計判断 |

「AIの制御機構」は買う(任せる)、「Canon固有の知識体系」は自分たちで育てる、という整理が、判断軸の土台になる。

---

## 13. 全体としての結論

情報活用基盤という構想は、Snowflakeの標準機能(Cortex Search、Cortex Agents、AI_COMPLETE/AI_CLASSIFY、Task/Stream)を組み合わせることで、**技術的には十分に実現可能**であることが、一連のプロトタイプ検証によって確認された。

設計上の要点は以下の通り:

1. **汎用的なAI制御機構(検索、オーケストレーション、会話継続)は、プラットフォームの標準機能に委ねる**。自作の制御ロジックは、将来的な標準機能への置き換わり(陳腐化)のリスクを負う
2. **Canon固有の価値は、タグ・分類体系の設計と、暗黙知抽出のルール設計に宿る**。ここは汎用ベンダーが代替できない領域であり、意図的に投資すべき部分
3. **自動化は「発見・提案」と「実行・適用」を分離し、後者には人間の承認を必須とする**。特にスキル(Agentの振る舞い)は共有設定であり、不用意な自動書き換えは組織全体に影響するリスクを持つ
4. **権限設計は、Streamlitの「所有者権限」という前提を踏まえ、アプリケーション層での明示的な制御と、最小権限の原則を徹底する必要がある**
5. **次に必要なのは技術検証ではなく、企画業務そのものの棚卸しであり、そこからシステム構成(自前/標準機能/外部委託/ハイブリッド)を判断する**