登録した資料の内容を、AIが提案に使える形で読み取れているかを確認します。文章の抜けや読み違いがあれば、元の資料と照合して修正します。

出所や資料の日付など、判断に必要な情報もそろっているかを確かめます。読み取れなかった内容を曖昧なまま使わず、確認を済ませてから分析や提案に進みます。

正式に反映され、現在の運用で参照している内容を「現行版」と呼びます。新しい判断材料や変更案は、現行版とは別の「見直し中の版」で扱います。

それぞれの版に、使用した判断材料を結び付けます。これにより、現在の運用を保ったまま、何を追加し、どこを変更しようとしているのかを比較できます。

追加・差し替えた判断材料を、現在の判断と比べます。AIは、影響がありそうな箇所と、その理由、参照した材料を示します。

人は、AIの説明を元の材料と照合し、実際に見直しが必要かを検討します。AIの分析結果は判断を助ける情報として扱い、その結果だけで承認や反映を進めないようにします。

人は、新しい判断材料とAIが示した影響を確かめ、提案を作り直すかを決めます。判断に必要な情報が足りなければ、追加の材料をそろえます。

現状を維持すると決めた場合も、見直しを進める場合も、その理由を残します。見直しを始めることと、現在の運用を変更することは、別の段階として扱います。

見直し中の版に、引き継いだ判断材料と新しく加えた材料がそろっているかを確認します。何が変わり、なぜ見直しが必要になったのかも分かるようにします。

別の業務の資料や古い情報を取り違えていないかを確かめたうえで、AIによる提案へ進みます。

業務で使う提案は、一つの観点だけでは判断しきれないことがあります。ここでは、運用の準備、期待する効果、モデルの選び方、取り組みの優先順位という四つの観点で整理します。

運用の準備では、利用前に整えることや、対応が必要な問題を確認します。期待する効果では、どのような改善を見込み、その効果をどう確かめるかを考えます。

モデルの選び方では、用途に必要な性能や費用を踏まえて、適したモデルや使い分けを検討します。取り組みの優先順位では、何を先に進め、何を保留・見直しするかを考えます。

提案には、何を行うのかだけでなく、なぜその対応が必要なのかを添えます。現在の運用から変える点と、根拠となった判断材料も一緒に確認できるようにします。

効果の見込みや優先順位を示す場合は、その前提も明らかにします。人が案の妥当性を判断できるよう、結論に至る理由を残します。

提案から元の判断材料へ戻り、AIの説明が資料の内容に沿っているかを確認します。資料に書かれた事実と、AIがそこから推測したことを分けて読みます。

参照先が示されていても、それだけで説明が正しいとは限りません。理由に飛躍がないか、重要な前提が抜けていないかを人が確かめます。

AIが生成した提案は、人の確認を待つ状態で保存します。対応案と根拠を一緒に示し、何について判断が必要なのかを分かるようにします。

生成が完了した時点では、まだ承認も運用への反映も済んでいません。次の段階で、人が内容を確かめ、承認の可否を判断します。

AIが担うのは、判断材料を分析し、対応案を示すことです。提案を承認する判断と、承認された内容を運用へ反映する手続きは、人の責任で進めます。

提案を生成したことを、そのまま業務の実行許可として扱わないようにします。実行できる操作や範囲は、承認された内容に基づいてシステムが確かめます。

提案に誤りや説明の不足がある場合は、人が内容を確認して修正します。何を直したかが分かるよう、変更前後の内容と、修正した人を記録します。

修正を保存することと、その内容を承認することは別の手順です。修正後の案を改めて確認し、承認の可否を判断します。

人は、提案内容と根拠を確認し、承認または拒否を決めます。承認した提案は、反映の段階へ進められます。拒否した提案は、運用へ反映しません。

どちらの判断をした場合も、その理由を残します。後から読んだ人にも判断の経緯が伝わるよう、重視した情報や懸念した点を具体的に記録します。

承認は、提案内容を確認した人が、その内容を採用してよいと判断することです。反映は、承認された内容を、運用で使う正式な内容として適用することです。

承認を終えても、反映を行うまでは現在の運用で使う内容は変わりません。この二つを分けることで、承認後に適用する時点や業務への影響を確認できます。

判断の記録には、対象の提案、承認・拒否の結果、理由、判断した人と時刻を残します。その時に参照した判断材料も、合わせて確認できるようにします。

次に見直すときは、以前の結論だけでなく、その時点の材料と理由を読み返します。どの前提が変わったのかが分かれば、判断を見直す必要があるかを検討できます。

反映へ進む前に、提案の内容と版、承認結果を照合します。承認されていない変更や、拒否した提案が混ざっていないかを確かめます。

承認後に修正が必要になった場合は、修正した内容について改めて承認を得ます。反映する時点や事前準備は、次の段階で確認します。

システムは、反映しようとしている内容が人の承認を得ているかを確認します。未承認や拒否された提案は反映せず、承認済みの内容だけを正式な判断記録として保存します。

反映後は、人が記録を確認し、意図した内容が適用されたかを確かめます。何をいつ反映したかも、履歴として残します。

反映を終えたら、正式な判断記録の内容と、元になった提案を確認します。承認した内容が欠けたり、別の内容に置き換わったりしていないかを確かめます。

運用で参照するときは、反映済みであることに加えて、今回の業務で使う版かどうかも確認します。未承認の提案や、承認済みでも未反映の内容とは分けて扱います。

見直し中の版を現行版へ切り替える前に、必要な承認と反映が済んでいるかを確認します。一部の提案を反映したことと、新しい版全体を運用で使い始めることを分けて確かめます。

切り替えた後は、利用者が新しい版を参照できるようにします。以前の版は履歴として残し、現在使う内容と取り違えないようにします。

反映した内容を、判断材料、AIの提案、人の判断と結び付けて残します。変更前後を比べ、何を根拠にどこを変えたのかを確かめられるようにします。

後から新しい判断材料が加わったときは、この履歴をもとに見直します。以前の判断を消さずに残すことで、その時点では何を前提に決めたのかを確認できます。

複数の取り組みがある場合は、運用の準備状況、期待する効果、対応が必要な問題などを比べます。それぞれの判断が、いつ、どの情報をもとに行われたかも確認します。

人は、正式に反映された判断と現在の業務の状況を踏まえ、何を先に進めるかを決めます。AIが示した優先度の数値だけで決めず、その理由や前提が今も妥当かを確かめます。

承認・反映された内容に基づいて、実際に誰が何を行うかを決めます。人が行う作業とシステムに任せる処理を分け、それぞれに必要な権限と実行範囲を確認します。

実行前に人の確認が必要な場面や、問題が起きたときの連絡先も定めます。判断記録を残すだけで終わらせず、担当者が次の行動に移れるようにします。

承認・反映された内容をもとに、利用できる操作、処理する対象、必要な権限などを実行条件として定めます。システムは、実行しようとする処理がその条件を満たすかを確かめます。

条件を満たさない場合は、その処理を止めます。人の判断が必要な場合は、止めた理由と確認すべき内容を伝えます。会話の中で同意しただけで、実行できる範囲が広がらないように設計します。

どの判断材料から提案が作られ、誰が何を承認し、いつ反映したのかをたどれるようにします。判断の理由と、その時点の内容も一緒に確認できるように残します。

システムによる実行では、何を実行したか、何を止めたか、その理由や結果を記録します。判断・反映の記録と実行の記録を結び付けることで、承認された内容に沿って処理されたかを確かめられます。

ここまでの流れを、自社の具体的な業務に当てはめます。材料を登録する人、提案を確認・承認する人、承認内容を反映する人を定め、担当者が迷わず進められる手順にします。

通常の処理に加え、情報が足りない場合、実行条件を外れた場合、障害が起きた場合も確認します。誰が対応し、何を確かめれば再開できるか、記録をどこに残すかまで準備します。

利用者は、Streamlit in Snowflakeの画面から判断材料を登録し、提案の確認、承認・反映、履歴の確認を行います。Snowflake Cortex AIは、材料の影響分析と提案生成を担います。

拡大

提案は、Governance（運用の準備）、Value（期待する効果）、Model Routing（モデルの選び方）、Portfolio（取り組みの優先順位）の四つに分かれ、全体をDecision Packと呼びます。

SQLの処理は、入力と承認状態を確かめ、正式な判断記録への反映を行います。テーブルと内部ステージには、登録情報、提案、判断記録、元ファイルを保存します。TXT・PDFの元ファイルと、取り出した文章を関連付けて扱います。

AIが生成した提案は、人の確認待ちになります。この状態では、提案の見出しと説明文を修正できます。修正を保存しても承認にはならず、内容を確かめた人が承認または拒否を決めます。

拡大

画面上の状態名は、確認待ちがREVIEW_REQUIRED、承認済みがAPPROVED、拒否がREJECTEDです。承認だけでは正式な記録へ反映されません。

反映処理を終えるとPUBLISHEDとなり、正式な判断記録が作られます。拒否した提案は反映しません。

反映処理では、提案が承認済みかを確認し、未承認や拒否された内容の書き込みを防ぎます。同じ提案から正式な記録を重複して作らないための確認も行います。

拡大

反映済みの内容を見直すときは、新しい版で変更を扱います。以前の内容を履歴として残し、どの版の提案を承認・反映するのかを確かめます。

この実装例は、サンプルデータを使って流れを検証する構成です。提案生成に使うモデルは、現在の処理内で固定されています。Snowflake Native Appとして配布する構成にはなっていません。

拡大

提案の修正、承認・拒否、反映の履歴を記録しますが、保存された履歴を誰も変更できないことまでは保証していません。判断理由を必ず残すには、入力を求める運用や仕組みも整える必要があります。

外部業務での実行や停止、その結果の記録は、接続先に合わせて追加します。業務利用に向けて、担当者ごとの権限、記録の保存・保護、障害への対応を具体化します。

実装の全体像と現在の制約は、GitHubの説明からも確認できます。処理の条件を詳しく知りたい場合は、構成資料と実装コードを参照してください。Snowflakeの機能そのものの仕様は、公式資料で確認可能です。

開発中のGoogle Cloud版などへのリンクは、ページ下部の「関連資料」にまとめています。必要がある場合は、メールにてお問い合わせください。

このガイドのWebMCP機能は、内容の参照や項目の移動を補助するためのものです。必要に応じ、お手元のAI環境のブラウザにてご利用ください。

WebMCP公式資料