企業でAIを活用するために最低限知っておきたい5つのこと

第1章｜なぜ「AIを導入したのに使われない」のか

「うちもChatGPT、契約したんですよ」と胸を張る経営者の隣で、現場のエンジニアが小さくため息をつく ―― この1〜2年、何度見た光景でしょうか。

契約しただけで業務が変わらない理由はシンプルです。LLMは、優秀だが権限ゼロの新人エンジニアだからです。会話能力は抜群、論理思考も悪くない。でも社内ドキュメントを読んだことがなく、業務システムにログインできず、実行権限も持たず、会社のルールも知らず、やってはいけない線引きも分かっていない。

この「権限ゼロの新人」を本物の戦力に育てるために、業界では今、5つのピースが整いつつあります。

ピース	与えるもの	問いかけ
RAG	知識	AIは何を知っているか？
MCP	手足	AIは何ができるか？
ローカルLLM	居場所	AIはどこにいるか？
Agent Skills	手順書	AIはどうやるか？
Policy as Code	越えてはいけない線	AIは何をしてはいけないか？

これらが揃って初めて、AIは「たまに便利なおもちゃ」から「本番業務の相棒」になります。本記事は、過去に書いた5本の記事を1本に圧縮した全体像マップです。気になるテーマは各章末のリンクから深掘りしてください。

RAG第2章｜AIに"知識"を与える

社内文書を検索してプロンプトに注入し、根拠付きで答えさせる仕組みです。

LLMは一般知識は山ほど持っていますが、あなたの会社の就業規則も製品マニュアルも知りません。学習データに入っていないからです。「全部学習させればいい」と考えるとコストと更新性で破綻するため、代わりに使うのがRAG（Retrieval-Augmented Generation）。質問を受けたら関連文書を検索し、それをプロンプトに埋め込んでLLMに渡す ―― この単純な仕組みが、コンプライアンスの厳しい業務で決定的に効きます。回答の根拠（出典）を明示できるからです。

典型例：「当社の有給休暇のルールは？」 → 就業規則PDFを検索 → 該当箇所を引用して回答。

落とし穴は「RAGを入れたのに精度が出ない」問題で、原因の8割はドキュメント品質です。文書がバラバラ、新旧混在、チャンク戦略が雑 ―― RAGはAIの問題ではなく情報整理の問題。AIを入れる前に、自社のナレッジが検索可能な状態に整っているか確認してください。

MCP第3章｜AIに"手足"を与える

LLMが業務システムを呼び出して、実際に処理を実行するためのプロトコルです。

RAGで「有給休暇のルール」が答えられるようになりました。でもユーザーが本当にやりたいのは「来週月〜水、有給で休みます。申請しておいて」です。ここで必要になるのがMCP（Model Context Protocol）。LLMが外部ツールやAPIを安全に呼び出すための共通規約で、人事APIで残日数を確認し、申請フォームを送信し、承認者にSlack通知する ―― これらを一連で実行できる「手足を持ったAI」を実現します。

RAGが「know more（知る）」ならMCPは「do more（やる）」。両者は競合せず、MCPエージェントが必要に応じてRAGを使う関係です。

落とし穴は、権限を渡した瞬間に攻撃面が一気に広がること。権限設計が甘いと「全部読めて、全部実行できて、全部消せる」状態になります。後述のプロンプトインジェクションで悪意ある指示に従ってしまうリスクも一気に上がる。権限は最小限から始め、「絶対に許可するもの」だけをホワイトリスト化するのが鉄則です。

ローカルLLM第4章｜AIを"自社の中"に置く

機密データを社外APIに送らず、自社環境でLLMを動かす選択肢です。

ChatGPTもClaudeも便利ですが、入力は基本的に外部クラウドへ送信されます。これが許されない領域 ―― 医療の診療情報、金融の信用情報、製造の設計図、各種個人情報 ―― では、「便利だから使いたい、でも社外には出せない」という矛盾が生まれます。これを解くのがローカルLLM。OllamaやvLLMが整備され、自社環境でLlamaやQwenを動かすのが現実的な選択肢になりました。

実務ではハイブリッドが現実解です。一般的な文章生成はクラウドのフロンティアモデル（速くて賢い）、機密データはローカルLLM（社外に出ない）。データの機密度で経路を分けるアーキテクチャ設計が肝になります。

落とし穴は、導入して終わりではないこと。GPUコストは想像以上にかかり、モデルは日進月歩で更新されるため追従の運用負荷が重く、クラウドの最新モデルとの性能差は複雑なタスクで広がりがちです。「機密データだけローカル」と割り切る方が運用は回ります。

Agent Skills第5章｜AIに"手順"を教える

業務手順をMarkdown1枚でAIに渡し、「やり方」を資産化する仕組みです。

ここまででAIは「知識」「手足」「居場所」を手に入れましたが、まだ問題があります。毎回違うやり方で動くのです。プロンプトの書き方一つで挙動が変わり、業務に乗りません。そこで登場したのがAgent Skills。SKILL.mdという1枚のMarkdownに業務手順を書いておき、AIは必要に応じてそれを読み込んでその通りに動く ―― という仕組みです。

プロンプトが「使い捨ての指示」なら、Skillsは「再利用可能な資産」。今この一回の会話のための指示ではなく、組織として再現性のある業務手順として残せる。バージョン管理もできます。

落とし穴は、Skillsを書ける人材です。業務を理解していて、かつAIに何を伝えれば動くか分かっている人 ―― これは現場に意外と少ない。業務担当者がいきなり書こうとすると「曖昧で動かない手順書」になります。業務担当者×AIエンジニアのペアで書くのが現実解です。

Policy as Code第6章｜AIに"越えてはいけない線"を引く

やってはいけないことをコードで定義し、AIを物理的に囲い込む仕組みです。

ここまでの4つで、AIはかなり優秀な業務担当者になりました。でも規制業界の現場担当者はこう聞きます。「で、このAI、規則に反して顧客の信用情報を参照しないって保証はあるんですか？」 LLMは確率的に動き、指示はほぼ守る。でも「ほぼ」では済まない世界 ―― 医療、金融、政府、重要インフラ ―― では、一度の違反で即アウトです。

Skillsが「やり方（推奨）」を教えるのに対し、Policy as Codeは「やってはいけないこと（強制）」をフェンスとして実装します。OPA（Open Policy Agent）が業界標準で、AIが何かしようとするたびOPAが「OK／NG」を判定。AIはポリシーの中身を理解する必要すらなく、判定結果に従うだけ。AIの善意に頼らず、破るという選択肢自体を物理的に消すのが本質です。

落とし穴はポリシーの陳腐化。規制が変わったのに更新されない、厳しすぎて現場が回避策を編み出す、責任所在が曖昧 ―― 導入より運用が9割の世界です。

第7章｜5つをつなぐと、何が見えるか

実務では5つを組み合わせて初めて意味を持ちます。具体的に3つのケースで考えます。

業務の性質によって必要な組み合わせは変わります。すべてを一度に揃える必要はありません。

第8章｜成熟度モデル ―― どこから手をつけるか

Lv	状態	やること	起きがちな問題
1	個人がChatGPTを使う	利用ガイドライン整備	シャドーAI、機密情報流出
2	社内ナレッジに答えさせたい	RAG導入	ドキュメント品質不足
3	機密データも扱いたい	ローカルLLM併用	GPU調達と運用負荷
4	業務を実行させたい	MCP + Agent Skills	権限設計と暴走時の被害
5	規制業界の本番投入	Policy as Code	監査・Observability

Lv.1なのにいきなりLv.5を目指すのは無謀です。私の経験では、多くの日本企業はLv.1とLv.2の間で停滞しています。「ChatGPTは入れたけど社内のことは答えられない」状態。ここを抜けるには、まずRAG。そしてその前に、ドキュメント整理を覚悟することです。

第9章｜次に向き合うべき課題（予告編）

5つを揃えても終わりではありません。本番運用に入った瞬間、新しい課題が出てきます。

課題1：プロンプトインジェクション ―― MCPで権限を渡した瞬間、攻撃面が爆発します。特に怖いのが「間接的プロンプトインジェクション」。メール本文やWebページに埋め込まれた指示にAIが従ってしまうケースで、対策していないエージェントは本当に顧客リストを社外送信しかねません。

課題2：AI Observability / AgentOps ―― Policy as Codeで線を引いても、AIが実際に何をしたか追跡できなければ違反検出も改善もできません。OpenTelemetry GenAI semantic conventions、Langfuse、Arizeといったツールが急速に整備されています。

課題3：評価（Evalops） ―― 「うまく動いている」をどう測るのか。LLM-as-a-Judge、ゴールデンデータセット、リグレッションテスト ―― ソフトウェアのユニットテストに相当する仕組みが必要です。

これら3つは「5要素の次の階」。本シリーズで順次深掘りしていく予定です。

結び｜AIは"賢さ"ではなく"運用"で勝負が決まる時代

冒頭でAIを「優秀だが権限ゼロの新人エンジニア」と表現しました。今、その新人を戦力に変える道筋が見えていると思います。知識を与えるためにRAGを設計し、手足を与えるためにMCPを設計し、居場所を考えるためにローカルLLMを検討し、手順を渡すためにSkillsを書き、越えてはいけない線を引くためにPolicy as Codeを定義する。

派手なテーマではありません。GPT-5やマルチモーダルのような華やかさはない。でも、PoC止まりのAIと本番で価値を出すAIの差は、ここで決まります。

技術導入はその後でも遅くありません。むしろ、この3つができていない状態で技術を入れると、ほぼ確実にPoC止まりになります。AIの賢さはベンダーが進化させてくれます。でもAIをどう運用するかは自社の責任。