AI Agentに専門領域を習得させる方法

「資料を検索させれば専門家のように動くはずなのに、古い規程を参照したり、手順の途中で勝手に判断したりする」状態になっていませんか。

最短の解決策は、Knowledge Base、Agent Skills、ツール呼び出し、評価集を4層に分けることです。Knowledge Baseは「何を知るか」、Skillは「どう進めるか」、ツールは「何を操作するか」、評価集は「本当に信頼できるか」を担当します。RAGだけでも、Skillだけでも、専門領域を安定して扱えるAgentにはなりません。

この記事が向いている人

ソフトウェア開発、運用、設計、社内業務のAgentを作っているAIエンジニア向けです。
社内SOPと更新され続ける資料を整理したいプラットフォームチーム、継続稼働する領域Agentの責任者にも適しています。

まず4層の役割を分離する

AI Agentに専門領域を習得させるとき、最初から一つの巨大なシステムプロンプトへ知識と手順を詰め込むと、更新範囲と障害原因が分からなくなります。次のように、変化するものと安定したものを分けてください。

RAGは外部資料を実行時に取得して回答へ反映する仕組みですが、検索結果が正しくても、Agentが次に何をするかまでは定義しません。検索と生成を分離する2段階RAG、Agentが必要に応じて検索するAgentic RAG、検索結果を検証する構成などは、用途に応じて選ぶ必要があります。詳しくは検索とRAGの公式ドキュメントも確認してください。

4層設計で先に避けるべき問題

• Knowledge Baseに出典、版、適用期間がなく、Agentが古い資料を正しいものとして扱う。
• Skillに知識全文を複製し、原資料を更新してもSkill側だけ古いまま残る。
• ツールに書き込み権限を与えたまま、確認なしで削除、公開、デプロイまで実行する。
• 成功時の例だけを評価し、拒否すべき依頼やAPI障害時の挙動を確認していない。
• モデル自身の学習知識を監査可能な社内情報として扱い、回答の根拠を追跡できない。

Knowledge Baseは出典を追える形で作る

Knowledge Baseへ登録する資料は、単にPDFや社内Wikiを集めればよいわけではありません。最低限、原資料の識別子、版、作成者または管理部署、適用開始日、失効日、アクセス権、更新日時をメタデータとして保持します。

検索結果には本文だけでなく、どの資料のどの箇所から取得したかを返させます。回答生成時に出典が欠けている場合は、Agentに断定させず「根拠不足」として追加検索や人による確認へ戻す設計が安全です。

動的な事実を長期的に変わらないSkillへ書き込むのは避けてください。料金、API仕様、障害対応手順、担当部署、環境名のように変わる情報はKnowledge Baseへ置き、Skillから検索する構造にします。

Agent Skillsへ安定したSOPを封装する

Agent Skillsは、専門知識そのものを保存する場所というより、専門知識を使って作業するための再利用可能な手順です。例えば「障害チケットを調査するSkill」なら、ログ検索、影響範囲の確認、再現条件の記録、エスカレーション条件、報告書の形式まで定義します。

公式のAgent Skills設計では、メタデータ、必要時に読み込む指示、必要に応じて参照する資料や実行ファイルを分ける構成が採用されています。メタデータは約100トークン、本文は5000トークン未満を目安にし、詳細資料やスクリプトは必要時だけ読み込ませる設計です。Agent Skillsの構造と段階的読み込みとSkill作成のベストプラクティスが参考になります。

Skillには次の情報を含めると、手順の再現性が上がります。

• 適用条件と、適用してはいけない条件。
• 実行前に確認する入力項目と不足時の質問。
• 手順の順番、分岐条件、停止条件。
• 読み取りだけで済む操作と、承認が必要な操作。
• 成果物の形式、必須項目、検査方法。
• 失敗時の復旧方法と、人へ引き継ぐ条件。

Knowledge BaseとAgent Skillsの違いは、更新の責任単位です。規程の文言が変わったならKnowledge Baseを更新します。承認手順そのものが変わったならSkillを更新します。両方を同じファイルへ押し込むと、どこを直せばよいか判断できません。

ツール呼び出しは権限と結果形式を先に決める

ツール呼び出しは、Agentを「回答できる仕組み」から「外部システムを操作する仕組み」へ変えます。そのため、便利さよりも権限境界を先に決める必要があります。

ツールの説明文だけで安全性を担保してはいけません。Model Context Protocolの仕様でも、ツールには入力スキーマや出力スキーマを持たせられ、読み取り専用や破壊的操作などの情報を示せますが、外部サーバーから受け取る注釈は信頼できるとは限りません。MCPのツール仕様では、人が呼び出しを拒否できる仕組みも推奨されています。

ツールの戻り値は、Agentが次の行動を判断できる形にします。例えば自由文だけを返すのではなく、次のような項目を持たせます。

• status: 成功、失敗、要確認。
• result: 実行結果または取得データ。
• error_code: 再試行可能か判断できるエラー種別。
• next_action: 次に許可される操作。
• request_id: ログと照合するための識別子。

ツール障害を通常の回答エラーと混ぜると、Agentが成功したと誤認して次の書き込みへ進むことがあります。構造化された結果とエラー状態を分ける設計は、MCPの結果形式に関する仕様で確認できます。

評価集で「習得したつもり」を検出する

専門Agentの評価は、正しい質問に正しい回答を返すだけでは不足します。Knowledge Base、Skill、ツールのどこに問題があるか切り分けられるよう、次のカテゴリを固定評価集へ入れてください。

1. 出典付きの知識質問。
2. 複数資料の矛盾を指摘する質問。
3. SOPに沿った正常な作業。
4. 前提条件が欠けた依頼。
5. 古い資料を使わせようとする依頼。
6. 権限外の操作や破壊的操作。
7. ツールがタイムアウトした場合。
8. ツールが部分成功した場合。
9. 取得資料が空、重複、またはアクセス拒否になった場合。

採点では、回答の正しさだけでなく、根拠の有無、禁止操作の拒否、確認質問の適切さ、実行結果の解釈、復旧手順まで確認します。Knowledge Baseを更新した後にSkillや評価集を更新し忘れていないか、Skillを変更した後に正常系と拒否系の両方が維持されているかを、同じ評価条件で比較してください。

更新と衝突を処理する順番

資料が衝突した場合、モデルに多数決をさせるのではなく、優先順位をデータとして定義します。例えば、現行の正式規程、承認済みの運用手順、過去の障害記録、参考資料というように、出典の強さと適用期間を分けて登録します。

更新担当者も決めておきます。技術資料は開発チーム、運用手順はSREや情シス、法務・規程は管理部門というように責任者を明示し、期限を過ぎた資料は検索対象から除外するか、回答時に「要確認」と表示します。

5段階で最小プロトタイプを検証する

いきなり全社向けAgentを作らず、境界の明確な一つの領域で検証します。例えば、社内の障害一次切り分けや、定型的な設計レビューのように、入力、参照資料、成果物を限定できる業務が適しています。

• [ ] 対象業務の成功条件、禁止事項、担当者を文書化する。
• [ ] 原資料に版、出典、適用期間、権限、更新担当者を付けてKnowledge Baseへ登録する。
• [ ] 安定したSOPだけをAgent Skillsへ記述し、動的情報の複製を避ける。
• [ ] ツールを読み取り、下書き、書き込み、実行に分け、最小権限で接続する。
• [ ] 正常系、拒否、古い資料、矛盾資料、ツール失敗を評価集へ登録する。
• [ ] 環境を分離し、資格情報、ログ、状態保存、再実行条件を確認する。
• [ ] 評価集の結果を基準値として保存し、更新後に同じ条件で再実行する。
• [ ] 低リスクの社内補助から段階的に公開し、外部向け自動操作は承認付きで開始する。

Agent SkillsをAPIや実行環境へ組み込む場合は、対応するランタイムの制約も確認してください。例えば、公式資料ではSkillの作成、バージョン指定、実行環境、ファイルやコードの扱いが製品面ごとに異なります。SkillをAPIで利用する公式ガイドのように、導入対象の実装仕様を基準にして設計してください。

本番投入前に確認する運用条件

本番では、Agentの回答品質だけでなく、環境そのものが復旧可能かを確認します。特に、共有サーバー上で複数のAgentを動かす場合、作業ディレクトリ、キャッシュ、資格情報、ログの混在が原因で、別案件の情報を参照する事故が起こり得ます。

外部システムへ接続する場合は、Agentごとの資格情報、用途別のAPIキー、期限、失効手順を分けます。ログには入力全文や秘密情報を無制限に保存せず、誰が、どのSkillを使い、どのツールを、どの権限で呼び出したかを追跡できる形にします。

最小権限、読み取り専用、IP制限、限定されたAPIキーを使う考え方は、エージェント型AIのセキュリティガイドでも扱われています。MCPを採用する場合も、プロトコル対応だけで安全になるわけではなく、実際の認証、認可、監査、承認フローを別途設計する必要があります。

自前のワークステーションや既存の共有環境で始めると、環境差分、資格情報の残留、状態復旧の難しさが問題になりやすく、短期の検証でも運用準備に時間がかかります。特に複数のAgentやチームが同じ環境を使う場合は、分離された実行環境とログ設計を先に確認してください。

一方、長期間にわたる高負荷処理、物理デバイスへの接続、常時固定の専用構成が必要なら、Macレンタルより自社設備や専用サーバーの方が適する場合もあります。短期の検証、環境分離が必要な開発、Mac上でのビルドや自動化を試したい場合は、ZavCloudのMacレンタル環境を候補に入れ、必要な隔離条件やログ運用を確認してください。導入前の接続条件はZavCloudのヘルプセンターで確認できます。

よくある疑問

Knowledge BaseとAgent Skillsはどのように使い分けますか？

Knowledge Baseは、規程、仕様書、障害記録など、検索時点で参照したい事実を保管する場所です。Agent Skillsは、条件分岐、作業手順、出力形式、確認ルールなど、繰り返し実行する方法を定義します。知識をSkillへ大量に複製せず、Skillから必要な資料を参照する構造にすると更新しやすくなります。

領域知識はRAGとSkillのどちらに入れるべきですか？

更新頻度が高い情報、出典確認が必要な情報、案件ごとに変わる情報はRAG側のKnowledge Baseへ置きます。一方、安定したSOP、入力条件、禁止事項、成果物の形式はSkillへ定義します。判断に迷う場合は、内容が変わったときに再検索が必要か、手順そのものを変更する必要があるかで分けてください。

AI Agentが本当に専門知識を習得したかは、どう検証しますか？

通常の質問に答えられるかだけでなく、出典を示せるか、古い情報を拒否できるか、手順の途中で不足条件を確認できるかまで評価します。正しい回答、誤った手順の拒否、ツール障害時の復旧、権限外操作の拒否を含む固定評価集を作り、Knowledge BaseやSkillの更新前後で同じ条件を比較します。

専門Agentの古い知識を安全に更新するにはどうしますか？

まずKnowledge Baseの原資料を差し替え、版、発行元、適用期間、更新担当者を記録します。その後、変更が手順や出力形式に影響するかを確認し、必要な場合だけAgent Skillsと評価集を更新します。古い情報をSkillへ直接埋め込んでいると、資料更新後もAgentが旧手順を使うため、定期的な差分確認が必要です。

Knowledge Base、Agent Skills、ツール呼び出し、評価集を分けると、どの層を更新し、どの層を再検証すべきか判断できます。現在の共有環境やローカル構成をそのまま使い続ける方法は、環境差分、権限の混在、障害時の状態復旧という弱点が残りやすいため、短期の専門Agent検証では分離されたMac環境の方が扱いやすい場合があります。長期の固定負荷や物理接続が不要で、まず安全な実行環境を確保したいなら、ZavCloudのMacレンタルを検証候補として比較してください。