SCC Field Report — AI導入支援編
GPT、Claude、Gemini——モデルの進化は止まらない。
その波の中で、SCCのコンサルタントは今日も顧客の現場に入り、
「AI基盤をどう設計するか」「社内にどう展開するか」を一緒に考えている。
提案書を渡して終わりではない。キックオフから社内展開まで、
コンサルタントが居続して動かす。それが、SCCの仕事です。
Day 1 — Project Kickoff
Section 01
プロジェクト参画初日。まずホワイトボードにPO・Tech Lead・Business Analyst・Data Engineerの役割分担を書き出し、クライアントのIT部門・業務部門・経営企画の担当者と体制を合意する。
続いてシステム構成を描く。API Gateway・Vector DB・Auth Layer・LLMの接続関係、データソースの種類と権限スコープ、監査ログの保存先。6スプリントのタイムラインと各フェーズのデリバラブルを一枚に落とし込む。
この日だけで意思決定すべき事項は20を超える。「後で決める」を極力なくすのが、SCCのキックオフの流儀です。
キックオフ当日に決めること
Section 02
システム設計が決まった後、最初に山積みになるのが「社内調整」だ。IT部門・法務・コンプライアンス・業務部門、それぞれの要件と優先度が違う。
ホワイトボードに論点を書き出す。データ連携方針・セキュリティ要件・権限管理マトリクス・運用体制・部署間API仕様——各項目に対して「誰が決めるか」を明確にすることが目的だ。
この調整作業をサボらないと、技術的に正しい設計も現場で実行できなくなる。コンサルタントの仕事は、コードを書く前にここで決まる。
社内調整で浮上する主な論点
データ連携方針
システム間のデータ連携ルールが未整備。マスターデータの統合方針が不明確。
セキュリティ要件
アクセス制御の要件が不明確。外部連携におけるセキュリティ基準が未策定。
権限管理マトリクス
部署ごとの権限整理が未実施。最小権限の設計方針が必要。
運用体制
システム運用の責任分界が曖昧。障害対応フローが未定義。
部署間API仕様
API仕様の認識・認可方式を検討中。各部署の要件が未実装。
変更管理・ロールバック
モデル・プロンプトのバージョン管理と本番切り戻し手順が未定義。
Section 03
大手金融・事業会社からの依頼。「部門ごとにPoC（実証実験）はやっているが、全社展開できない」——その一言から始まった支援の記録です。
SCENE 01 — ユースケース整理
各部門の担当者を集めて、「今どんな業務にAIを使いたいか」を付箋で出してもらうところから始めた。最初は「議事録自動化」「問い合わせbot」など個別の要望が並ぶだけ。
そこから「データ種別」「セキュリティ要件」「優先度」の軸で整理し直す。PoC止まりになっていた本当の理由は、利用ルールとデータ連携の設計が抜けていたことだった。
この整理に、丸2日かかった。
SCENE 02 — 調査・資料作成
RAGの権限管理、プロンプト管理の設計、ログ監査の要件——クライアントの情報システム部門から次々と専門的な質問が飛んでくる。
分からないことは「分からない」と言う。そして夜中に調べて、翌朝の打ち合わせまでに整理してExcelにまとめる。部門・ユースケース・データ種別・セキュリティ要件・優先度を一覧化した管理表が、最終的に100行を超えた。
格好いい資料ではない。でも、これが経営判断の材料になる。
SCENE 03 — 経営層への提案
RAG構成・権限管理・ログ管理・プロンプト管理・モデル利用方針——全社AI基盤のロードマップを経営層に説明する場。資料は何度も作り直した。
「PoCから全社展開まで、フェーズ別に何をするか」を明確にすることが求められた。「PoC、基盤構築、業務展開」の3フェーズに整理し、各フェーズの判断基準と予算規模を一枚に収めた。
経営判断に必要な材料を揃えること——それがこの支援の最後の仕事だった。
OUTCOME
Section 04 — AI Infrastructure
AI基盤の設計は、PoC段階とは別次元の難易度がある。Vector DB選定、チャンキング戦略、トークン制限、プロンプトインジェクション対策——一つ設計を誤れば、全社展開後に取り返しがつかない。
SCCは、クラウドベンダー・セキュリティ専門家・MLエンジニアとのパートナー連携を持ち、アーキテクチャレビューから権限マトリクス設計・ログ監査要件の策定まで、技術的な議論に直接入る。
「コンサルが要件を書いて、あとはSIerに丸投げ」ではない。設計の根拠を問われたとき、その場で答えられる体制で臨む。
Section 05 — All-Hands Presentation
Preparation — 3週間の準備
全社展開の発表は、プレゼン当日より準備の方が長い。各部門のユースケースヒアリングを引き続き、「自分たちの業務でどこに使えるのか」を具体化する作業から始まる。
セキュリティチームとのレビューで「許可できるデータ」と「許可できないデータ」を分類。権限マトリクスはスプレッドシートで管理し、全部門長に確認を取る。
スライドは最終的に40枚超。「技術説明」ではなく「自分たちの仕事が変わる」と実感できる構成にするため、メッセージを何度も書き直した。
On the Day — 発表当日
なぜ今、AI基盤が必要なのか「経営層の言葉」で開始
PoCが止まる理由、部門ごとの個別展開の限界をデータで示し、「全社横断」でなければならない理由を説明。
RAG構成と権限設計を「具体例」で説明
議事録自動化・問い合わせbot・在庫予測の3ユースケースをデモ。「自分の業務に使える」と実感できる構成にする。
質疑応答：「データ流出しないか」「誤回答するか」
セキュリティ・プライバシー・誤回答リスクについて、技術的な説明と具体的な対策をその場で答える。
ロードマップと各自のアクションを共有して終わる
PoC・基盤構築・全社展開の3フェーズを示し、各部門が「次のアクション」を持って退場できる状態で終わる。
Ongoing — Phase 2+ Support
Section 06
初期リリースはゴールではない。全社展開後に浮上する追加要件、利用部門の拡大、モデルのバージョンアップ——システムは常に変化する。SCCはその変化に対応する体制ごと支援する。
コア機能の安定化と並行して、社内の営業・カスタマーサポート・経営企画各チームに対して「このシステムで何ができるか」を説明する内部展開も支援する。
ツールを渡して終わりではなく、現場が自分たちで回せる状態になるまで。それが私たちの支援の終点です。
Phase 2以降の支援内容
SCC — AI導入支援
提案書を渡して終わりではない。キックオフから社内展開まで、コンサルタントが居続して動かす。それが、SCCの仕事です。
今すぐ知るべき3つの変化
LLMのコスト構造が崩壊した
GPT-4クラスの推論コストは1年前の100分の1以下。「PoCは高い」と言っていた時代は終わった。
RAGからAgentへの移行が加速
検索して答えるだけでなく、自律的にタスクを実行するAI Agentが業務プロセスに入り始めた。設計思想が根本から変わる。
社内展開の失敗パターンが明確化
導入企業の分析から「権限設計の甘さ」「利用ルールの不備」「社内説明の不足」の3点が失敗の9割を占める。
最初の一歩を踏み出す
「自社に合うのか分からない」と思っている企業ほど、早めに話してほしいです。トレンドの読み方と自社の現状を照らし合わせるだけで、次の手が見えてくる。
最初の30分は無料。売り込みはしません。まず、現在地点を聴かせてください。
