なぜこの順番で調べ、何が考えを変えたか。技術検証の結論そのものではなく、そこにたどり着くまでの判断の連鎖を記録したもの。個別の結論だけでは伝わりにくい、検証全体の必然性を補うために作成した。
この文章もAIとの壁打ちに使える。全文をコピーして貼り付ければ、検証の経緯を踏まえた議論ができる。
最初の関心は、情報活用基盤という構想そのものではなく、Snowflakeという環境に対する土地勘を得ることだった。SQLワークシートでのデータ操作、システム設定、Git連携の仕組みといった基本操作を押さえた上で、次の学習対象として「Streamlit(AIチャットのUIを作る部品)」に狙いを定めた。ここでのゴールは明確で、「Streamlit上でLLMを動かせるようにしたい」という一点だった。
基本的なStreamlit操作を学んだ後、AI機能(Cortex)を呼び出そうとしたところで、最初の障害に当たった。無料トライアルアカウントでは、Cortexの一部機能が利用できない、という制限である。これは権限設定の問題ではなく、アカウントの契約種別そのものに起因するものだと切り分けた上で、本登録によって解消することを確認した。この経験から、「モデル名や機能の可用性は、アカウントの状態によって変わりうる」という前提を持つようになり、以降の検証では常に実機で動作確認を取る、という姿勢につながった。
基本操作の学習が一段落した段階で、初めて「情報活用基盤」という構想そのものを言語化した。企画業務における相談・資料作成をAIチャットの中で完結させ、そこで生まれる暗黙知を自動的に蓄積し、組織全体で共有していく、というビジョンである。ここで重要だったのは、目的を「完成したシステムを作ること」ではなく、「Snowflakeの機能を使えば実現可能だと示す、技術的な裏付けを伴った提言を用意すること」と、早い段階で定義し直したことだった。この目的設定が、以降のすべての検証の基準になっている。
この構想を、検索・抽出・仕事の型・自動化・権限という6つのフェーズに分解し、どこから着手すべきかを検討した結果、「一番不確実で、コンセプトの成否を左右する部分から検証する」という方針を立て、まずRAG(検索拡張生成)の基礎から着手することにした。
Cortex Searchを使った検索の仕組みを構築する過程で、単純なキーワード一致ではなく、意味的な近さと再ランキングを組み合わせたハイブリッド検索であることが分かった。この理解が、「チャンク分割」「タグによる絞り込み」という、後の設計判断の土台になった。
ここで一つの分岐点があった。「非構造化データ(資料)をそのまま検索対象にできるか」という疑問に対し、テキスト化という前処理が必須であることが分かり、さらに「その前処理はどこまで技術的に成熟しているか」を検討した結果、マルチモーダル処理(画像として扱う手法)はまだ発展途上であり、まずは枯れた技術(テキスト抽出)から着手すべきだという判断に至った。この「枯れた技術から着手し、必要になったら拡張する」という考え方は、以降の判断で繰り返し立ち返る基準になった。
検索の基礎ができた後、会話から知見を自動的に抽出・タグ付けする仕組みを構築した。ここで技術的な実装自体は比較的スムーズに進んだが、その過程で「タグの分類軸をどう設計するか」が、Snowflakeの機能では代替できない、Canon固有の設計判断であるという理解に至った。これは、技術検証の途中でありながら、検証全体の結論の一つ(プラットフォームに委ねる部分と、自前で育てる部分の切り分け)を、先取りする形で得られた洞察だった。
検索と抽出の基礎ができたところで、これらを束ねて自動的に振る舞いを判断させる仕組み(Cortex Agent)の検証に進んだ。ここでの理解の核心は、「LLM自体は文字を入れると文字が返るだけの関数であり、会話の記憶や複数ステップの判断は、その外側の仕組みが担っている」という前提の確認だった。Cortex AgentやCopilot Studioのようなプラットフォームは、まさにこの"外側の仕組み"を、あらかじめ作り込んで提供するものである、という位置づけの理解が、以降の設計方針(汎用的な制御機構はプラットフォームに委ねる)の理論的な根拠になった。
Agentの仕組みを理解した後、これを自分のStreamlitアプリから呼び出そうとしたところで、これまでとは異なる種類の複雑さに直面した。Agent呼び出しには「コンテナランタイム」という、より本格的な実行環境への切り替えが必要で、依存関係の管理方式、外部ネットワークへの接続許可、認証情報の取得方法など、それぞれ個別に解決すべき技術的な壁があった。
この過程は、単に手間がかかったという以上の意味を持っている。「Snowflakeの標準機能に乗っかる」という方針が、実装コストゼロを意味するわけではないという、重要な実務的な教訓を、身をもって確認する機会になった。この経験が、後の提言における「実現可能だが、相応の実装コストを伴う」という、正直な評価につながっている。
Agentをアプリから呼び出す実装を進める中で、「このアプリのコードを、誰が編集できるのか」という、当初想定していなかった論点に気づいた。Streamlitアプリが「所有者の権限」で動くという仕組みを理解したことで、編集権限を持つ者が、事実上強い権限を行使できてしまうという、組織展開時のリスクが明確になった。これは技術検証の副産物として得られた、しかし提言全体にとって欠かせない論点である。
基本的な検索・抽出・応答生成の仕組みが検証できたところで、当初の構想にあった「仕事の型(スキル)」の実装に着手した。ここでは、単純な実装(都度プロンプトに埋め込む)を先に動かして検証しつつ、より洗練された実装(Agent自体の設定を書き換える、スキルごとに専用のAgentを用意する)との比較を通じて、「実装の完成度と、複雑さ・リスクのトレードオフ」を整理した。
続いて、自動化パイプラインの設計に進んだ際、「知見の自動蓄積」と「スキルの改善」という、性質の異なる2種類の自動化があることに気づいた。この整理から、「自動化するのは発見・提案までとし、実行・適用には人間の承認を必須とする」という、検証全体を貫く設計原則が生まれた。
技術的な実現性の検証が一通り済んだ段階で、「実際にどれくらいのコストがかかるか」という、実務上避けられない問いに向き合った。実運用データがない以上、仮説パラメータを積み上げて試算するしかないという前提を確認し、その過程で、プロンプトキャッシュやモデル選択といった、具体的な節約策も明らかになった。ここで得られた「キャッシュの効きやすさは、スキル実装パターン①(都度埋め込み)と相性が良い」という発見は、複数の検証テーマが後から繋がった、良い例である。
一連の検証を通じて、「Snowflakeの機能を組み合わせれば、構想は技術的に実現可能」という土台は、十分な裏付けを持って固まった。しかしその過程で、次に必要な問いが、技術的な検証ではなく、「企画業務の、どの場面に、AIがどう関わるべきか」という業務側の具体化であることが、自然と見えてきた。これは技術検証の限界であると同時に、次に取るべき行動が明確になった、という意味で、この検証の一つの到達点だと言える。