Canon 生産本部 企画センター / 技術検証レポート

情報活用基盤
技術検証レポート

AIチャットを介した企画業務支援と、組織知の自動蓄積というコンセプトが、Snowflake上でどこまで実現可能かを検証した記録。何を検証し、何が分かり、何がまだ分かっていないかを、そのままの道のりで残している。

→ なぜこの順番で検証したか(検証の道筋)を読む ・ → 資料をダウンロード

この資料は、AIとの壁打ちのために作られています。
下のボタンで全文をコピーし、Claude等のAIチャットに貼り付ければ、この検証について深掘りの質問ができます。

0. この資料の使い方

この資料は、情報活用基盤というコンセプトの技術的な実現可能性を検証した記録である。完成したシステムの仕様書ではなく、「何を試し、何が分かり、何がまだ分からないか」という検証の道のりそのものを残すことを目的としている。そのため、一つの結論だけでなく、比較検討した複数の実装パターンや、判断しきれなかった論点も、あえてそのまま記載している。

全文をコピーしてAIに渡せば、この検証の背景・意図・到達点を一度に共有した状態から、深掘りの議論を始められる。

1. 前提:LLMとは何か

本題に入る前に、AIチャットの土台にある技術の本質を確認しておく。

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

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

これだけでは、次のようなことは一切できない。

  • 前回の会話を覚えている(呼び出すたびに、まっさらな状態からのスタート)
  • 社内の資料を自分で調べに行く
  • 「まず調べて、その結果を見てから次を考える」といった複数ステップの判断
  • 画面に何かを表示する

これらは全て、LLMという関数の外側に、人間が別途プログラムを書いて実現している部分である。この「外側の仕組み」を作り込む代わりに、Snowflakeがあらかじめ用意してくれている部品(Cortex Agent、Cortex Search)に乗っかれないか、というのが、この検証全体を貫く問いになる。

この「複雑な中身を隠し、外からは入出力だけ意識すればよい状態にする」考え方は、コンピューターサイエンスで抽象化(abstraction)と呼ばれる。中身が見えない状態を指してブラックボックスとも言う。今回のCortex AgentやCortex Searchは、この抽象化がすでに施された、完成度の高い部品として提供されている。

2. 検証の目的

生産本部の企画業務において、AIチャットの中で相談・資料作成を完結させ、その過程で生まれる暗黙知(進め方のコツ、リスク回避の知見、コミュニケーション上の工夫など)を自動的に抽出・蓄積し、他のメンバーが使う際にその知見を踏まえた回答が得られる基盤を作りたい、という構想が出発点である。

ゴールは、完璧に動く本番システムを作ることではなく、「Snowflakeの機能●●と●●を、こういう構成で組み合わせれば実現可能」という、技術的実現性の検証と具体的な構成案を伴った提言を用意することにある。

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

3. 全体アーキテクチャ

情報活用基盤の全体アーキテクチャ 企画担当者からStreamlitチャットUI、Cortex Agentによるオーケストレーション、Cortex Searchとスキルというツール、会話ログから知識ベースへの蓄積ループ、権限・展開設計までの全体構成を示す図 企画担当者 Streamlit チャットUI 利用者との唯一の接点 AIオーケストレーション Cortex Agent ツール自動選択・会話継続 Cortex Search 社内知見をRAG検索 スキル(仕事の型) 実装3パターンを比較検討 人による承認 改善提案 → 承認 → 反映 知識蓄積ループ 自動化(Task/Stream) 会話ログ 暗黙知抽出・タグ付け AI_COMPLETE / AI_CLASSIFY 知識ベース ↻ 検索に反映 資料取り込み(PDF等) 権限・展開設計 アプリは所有者権限で動作、最小権限の原則を徹底
企画担当者からのチャット入力が、Cortex Agentを介してCortex Search(知見検索)とスキル(仕事の型)という2つのツールに振り分けられ、会話ログは自動的に暗黙知抽出・タグ付けを経て知識ベースに蓄積され、再び検索に反映される。スキルの改善は人の承認を経て反映する。

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

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

4. RAGの基礎(Cortex Search)

社内の暗黙知をテーブルに保存し、意味検索で引き出せるようにする、基盤の土台部分。

分かったこと

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

非構造化データの取り込み、検討した2パターン

パターン内容評価
A. テキスト抽出のみAI_PARSE_DOCUMENTでテキスト化してからチャンク化技術的に成熟。まずここから着手すべき
B. マルチモーダル(ページを画像として埋め込み)OCRを介さず、ページ全体を画像として埋め込む発展途上の技術。本格導入は時期尚早

5. 暗黙知抽出

チャットの会話履歴から、他者にも役立つ知見をAIに抽出・タグ付けさせ、知識ベースに保存する。

会話履歴からAI_COMPLETEで知見を抽出し、AI_CLASSIFYでタグ付けした上で保存する一連の処理を、ボタン押下によるオンデマンド実行と、コンテナランタイム環境の両方で動作確認済み。

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

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

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

6. Agentによるオーケストレーション

ツールの自動選択、複数ターンにわたる会話継続を、実機で検証した。

分かったこと

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

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

Cortex Analystと組み合わせることで、構造化データを使った回答も、以下のように段階的に高度化できることが分かった。

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

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

業界的な位置づけ

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

品質担保の考え方

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

7. スキル(仕事の型)

「進め方のコツ」のような知見だけでなく、「企画立案はこう進める」という手順そのものをAIの振る舞いに反映させる。

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

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

コスト面の副産物:①のように同じスキルの手順文を繰り返し送る構成は、後述するプロンプトキャッシュ(繰り返す文脈が最大90%引きになる仕組み)の恩恵を受けやすい構造でもある。

8. 自動化パイプライン

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

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

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

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

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

蓄積後のデータメンテナンス(未解決の課題)

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

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

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

9. 権限・セキュリティ設計

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

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

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

編集権限の重大なリスク

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

10. コストの考え方

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

コストの構成要素

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トークン以上の再利用が条件)。前章のスキル実装パターン①は、この恩恵を受けやすい構造でもある
  • モデル選択(最大10〜40倍の差):Snowflakeネイティブの軽量モデルは、抽出・分類のようなバッチ的作業に対して、上位モデルより明確に安い
  • 出力トークンの抑制:上位モデルほど出力トークンは入力の3〜6倍のコスト。JSON形式で簡潔に答えさせる設計自体がコスト対策になる
  • その他:TRY_COMPLETE/TRY_CLASSIFYでエラー時の無駄な課金を回避、CORTEX_MODELS_ALLOWLISTで高額モデルへの誤アクセスを制限、AUTO_SUSPENDを短く設定

実測・監視の方法

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

-- AI関数の消費(関数・モデル・ユーザー別)
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によるコスト異常検知機能もある。運用開始後は、試算ツールの前提値を実測値で定期的に更新していく想定。

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

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

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

12. 未検証・今後の課題

  • Cortex Analyst(構造化データとの自然言語連携)、Data to Chartによるグラフ生成の実機検証
  • スキル実装パターン②③の実機検証
  • 蓄積データのメンテナンス手法(重複統合・矛盾検出等)の試作
  • 権限設計(専用ロールでのアプリ所有への切り替え)の実機検証
  • 組織展開時のコスト試算の精緻化(実測値による前提値の更新)

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

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

業務棚卸しの必要性

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

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

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

Build vs Buy の判断軸

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

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

14. 結論

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

  1. 汎用的なAI制御機構(検索、オーケストレーション、会話継続)は、プラットフォームの標準機能に委ねる。自作の制御ロジックは、将来的な標準機能への置き換わり(陳腐化)のリスクを負う
  2. Canon固有の価値は、タグ・分類体系の設計と、暗黙知抽出のルール設計に宿る。ここは汎用ベンダーが代替できない領域であり、意図的に投資すべき部分
  3. 自動化は「発見・提案」と「実行・適用」を分離し、後者には人間の承認を必須とする
  4. 権限設計は、Streamlitの「所有者権限」という前提を踏まえ、アプリケーション層での明示的な制御と、最小権限の原則を徹底する必要がある
  5. 次に必要なのは技術検証ではなく、企画業務そのものの棚卸しであり、そこからシステム構成(自前/標準機能/外部委託/ハイブリッド)を判断する
本資料は情報活用基盤の技術検証記録であり、完成したシステムの仕様書ではない。記載の単価・機能仕様はSnowflakeの提供状況により変わる可能性があるため、本格導入前には公式ドキュメントおよび実測値での再確認を推奨する。