Agentのデモでは「何ができるか」が分かります。継続して使うには、顧客情報、製品ポリシー、確認済みの判断がどこに保存され、別のツールに替えても使い続けられるかを確かめる必要があります。
今のAgentが使う業務資料を一つ開いてください。GPTにアップロードしたファイル、Skillに同梱した参考資料、外部システムから取得するレコードでは、更新と引き継ぎの方法が違います。マーケットの掲載数より、まずその資料のライフサイクルを見ます。
一覧に並ぶものの中身を区別する
Agentは仕事を担う実行設定、Skillは再利用する指示とリソース、テンプレートは開始時の構成、コネクターは他のシステムへの接続です。一つの商品に複数が含まれていても、インストールしただけでは業務情報の保存先は分かりません。
AnthropicのSkills文書では、SKILL.md、スクリプト、テンプレート、参考ファイルをファイルシステム上にまとめ、必要に応じて読む仕組みを説明しています。カスタムSkillsは製品間で自動同期されません。手引きを同梱すると特定時点のコピーが配布されるため、各環境の更新方法を決める必要があります。
既存のカスタムGPTは別の方式です。OpenAIの設定ガイドは、アップロードしたKnowledgeを参考資料、Instructionsを動作の指示として区別しています。編集内容はUpdateで適用します。これはそのGPTの設定に資料を置く方法であり、他のツールの業務記録まで自動で揃える仕組みではありません。作成や移行の可否はアカウントとワークスペースで異なるため、現在利用できる画面を確認してください。
安定した書式ルールはSkillと一緒に配布できます。一つの既存GPTだけで使う、変更の少ない手引きはKnowledgeに置けます。複数の実行環境で繰り返し更新する業務情報には、共有する保存先の検討が必要です。
一つの資料について四つを確認する
正式な保存先はどこか。 ファイル、文書、レコードの場所と編集責任者を確認します。「記憶がある」という説明だけでは、会話履歴なのか、プロジェクトのファイルなのか、外部の情報源なのか分かりません。
どう読み取るか。 ローカルファイル、アップロード、API、MCPなど、実際の製品が使える経路を確認します。どの利用者に権限を与えるのか、交換するツールも同じ対象を読めるのかを確かめます。同じプロトコルに対応していても、接続済みとは限りません。
更新はいつ反映されるか。 元資料を直したあと、再アップロード、再インストール、索引更新が必要でしょうか。コピーが複数あれば、誰が版を確認するのでしょうか。顧客への約束に影響する内容は、利用前に誰が受け入れるかも決めます。
交換後に何が残るか。 指示、元ファイル、成果物、履歴を別々に確認します。プロンプトのコピーだけでは、接続設定や承認履歴まで移行したことにはなりません。
回答は小さな資料台帳にまとめます。資料名、正式な場所、読み取り方、更新責任者、反映手順、交換時の扱いがあれば、単なる「知識ベース対応」のチェックより選択に役立ちます。
現在の保存先で足りるなら、そのまま使う
一つのAgentが少数の安定したファイルを使うだけなら、製品内のファイル管理と履歴で十分な場合があります。編集権限、バックアップ、更新後の回答を確認してから、新しいシステムの必要性を判断します。
二つ目のツールが同じポリシーを必要とする、コピー同士が食い違う、変更に明確な受け入れ判断が必要になる。そのような状況では共有層に具体的な役割があります。一方で、接続、権限、障害時の扱いという運用も増えます。実際に繰り返す問題と比較してください。
Busabaseで共有資料の最小構成を作る
Busabaseでは利用者が管理する業務資料と変更を保存できます。ノードの説明に従い、構造化した情報はBase、長い文書はDoc、繰り返す手順はSkillに置きます。すべてを表へ変換する必要はありません。
次は調整して使う開始案です。既製の業務テンプレートではありません。
| ノード | 内容の例 | 目的 |
|---|---|---|
| Folder：業務資料 | レコード、確認ルール、手順 | 一か所から参照 |
| Base：製品ポリシー | 名前、対象製品、本文、根拠URL、適用日、責任者 | 後の仕事も同じ正式資料を読む |
| Doc：変更ルール | 事実の確認者、要審査の変更 | 人の判断基準 |
| Skill：資料の利用手順 | 読む順序、根拠、提案、読み直し | 実行担当が共通の方法を使う |
実際のクライアントが対応するMCPとOAuth、またはAPIで接続します。編集を許す前に本人、ワークスペース、読み取りを確認してください。変更を人の確認に回す通常のAgentにはchangeRequest権限を選びます。write権限では即時にマージされる場合があります。
接続したAgentへの指示は、次のように具体化できます。
現在の製品ポリシーを読み、回答に根拠を添えてください。資料が矛盾する場合、正式な本文は残し、旧文、新しい提案、根拠を含むChangeRequestを提出してください。責任者の判断を待ち、マージ後にレコードを読み直してから次の仕事に使ってください。
出力は確認できるレコードと差分です。ChangeRequestのマージで現在のレコードが進みます。実行側が以前のコピーを保持していれば、そのクライアントの方法で読み直します。
全件移す前に、一つの正式資料で試す
ツールAとBが同じ承認済みポリシーを読むか確認します。識別できる変更を提案し、想定した担当者の審査を待つかを確かめます。マージ後、両方から読み直します。一方の権限を取り消したあと、もう一方が自分の許可で動くかも確認します。
独立した保存、制御できる変更、交換可能な実行担当が必要な形で成立してから、移行を広げます。
Skillの参考ファイルは全部外へ出すべき？
安定した方法、書式の例、一般資料は同梱できます。継続更新、責任者、ツール横断の再利用が必要な業務資料を選び、Skillに読む場所を記します。
MCPの接続成功だけで資料は共通になる？
対象ワークスペース、権限、実際のレコード、キャッシュを確認します。接続表示より、同じレコードを読み、更新後も同じ内容を取得できるかを試す方が確実です。