provisioning は既存の資料を読み取り、エンジン設定へ変換します。結果を最も大きく左右するのは、リクエストの sources 配列に何を入れるかです。返ってくるエンジンの質は、何を渡すかで決まります。
各エントリは 2 種類のいずれかです。link ソースはプラットフォームが取得してクロールする URL、content ソースは直接渡す生のテキストまたは markdown です。1 つのリクエストで両方を組み合わせることができ、合計 10 ソースまで指定できます。このページでは、この 2 種類の違い、プラットフォームがそれぞれをどう扱うか、そして空っぽの設定ではなく役に立つ設定を得るためのソースの選び方を説明します。sources フィールド自体は create リクエストにあります。完全なペイロードと 202 レスポンスについては、プロビジョニングジョブを作成する を参照してください。
2 種類のソース#
すべてのソースは、type と payload を持つオブジェクトです。type が、プラットフォームが payload をどう読み取るかを決めます。
| 種類 | ペイロード | 使いどころ |
|---|---|---|
link | クロール対象の URL | 必要なコンテキストがすでに Web 上にあるとき。たとえば、ブランドページ、公開ドキュメント、公開済みのスタイルガイド、用語集ページなどです。 |
content | 生のテキストまたは markdown | 必要なコンテキストが頭の中や非公開ドキュメントにあるとき。たとえば、用語リスト、トーンのルール、製品名の命名規則、翻訳時の注意事項などです。 |
{
"sources": [
{ "type": "link", "payload": "https://acme.com/brand-guidelines" },
{ "type": "link", "payload": "https://acme.com/docs/style-guide" },
{
"type": "content",
"payload": "Brand name 'Acme' is never translated. Use formal tone in German (Sie-form). Product names: AcmeFlow, AcmeSync, AcmeVault - always keep in English."
}
]
}同じ配列に、リンク 2 つとコンテンツブロック 1 つを一緒に入れられます。リンクはすでに必要なコンテキストを持つページを指し、コンテンツブロックは公開されていないルールを載せます。どちらも同じ抽出ステップに渡されます。
プラットフォームがそれぞれに対して行うこと#
この 2 種類の違いは 1 ステップだけです。つまり、AI agent に渡す前にどうやってテキストを用意するか。そしてその先は同じ流れになります。
link ソースは、分析前に取得されて markdown に変換されます。プラットフォームはリンクソースを並列でクロールするため、10 個の URL が 10 回の順番待ちになるわけではありません。並行して読み取られ、その後テキストとして agent に渡されます。あなたは URL を渡すだけで、取得から HTML を markdown に落とす処理までをプラットフォームが担うため、agent はページのマークアップではなく本文を読めます。
content ソースはそのステップを飛ばします。送ったテキストは、書かれたとおりそのまま AI agent に直接渡されます。クロールも変換もなく、あなたの言葉と agent の間に何も入りません。だからこそ、content ソースは、すでに分かっているルールを最も正確に伝える方法です。
そこから先は、どちらの種類も同じ入力です。agent はそのすべてを読み取り、ブランドボイス、用語集項目、指示を抽出します。そのテキストから何が生成されるのか、またどんな要約が返るのかについては、AI が抽出する内容 を参照してください。
リンクのクロールはどこまで進みますか？
link ソースは、agent が分析する前に取得されて markdown に変換されます。指定した URL の先まで crawler がリンクをたどるのか、またどの深さまでたどるのかは、ここでは明記されていません。特定のページ群を確実に分析したいなら、1 つの URL から広がることに頼るのではなく、それぞれを個別の link ソースとして列挙するのが確実です。
意味のあるシグナルを持つソースを選ぶ#
ここが、provisioning を実行する価値があるかどうかを分けるポイントです。抽出の質は入力次第であり、ここでの失敗は静かに起こります。弱いソースでもジョブは完了し、エンジンも作られます。けれど中身はほとんど空で、そのことに気づくのは後になって、翻訳が取り込まれているはずのルールを無視したときです。完了通知も通常どおり届きます。Webhook delivery を参照してください。つまり、その抜け漏れを知らせてくれるものはありません。
意味のあるソースを用意する
抽出される設定の質は、入力の質に左右されます。リンクソースは、有用なコンテキストを含むページを指すべきです。たとえば、ブランドガイドライン、スタイルガイド、製品ドキュメント、用語集などです。生のコンテンツソースには、具体的な用語、トーンのガイド、翻訳ルールを含める必要があります。ありきたりなマーケティングページやログイン画面からは、役に立つ設定はほとんど得られません。
このコールアウトのポイントはシンプルです。agent が抽出するのは、明示されていることであって、暗黙のことではありません。「私たちは親しみやすく直接的なドイツ語で書き、Du ではなく Sie を使う」と書かれたページからは、ブランドボイスが抽出されます。「workspace → Arbeitsbereich」と並んだ用語集ページからは、用語集項目が抽出されます。優れたトーンを体現しているだけで、ルールを 1 つも明文化していない洗練されたランディングページからは、ほとんど何も得られません。持ち上げられるルールがそこにないからです。迷ったら、agent が推測してくれることを期待するページより、ルールをはっきり文章で書いてあるソースを優先してください。多くの場合、それはページではなく、自分で 1 文書いた content ブロックです。
1 つの弱いソースでジョブ全体は沈まない#
複数のソースを一度に渡すと、自然とこんな不安が湧きます。1 つの URL が無効だったり、1 つのブロックの中身が薄かったりすると、リクエスト全体が失敗するのではないか、と。しかし実際にはそうなりません。ソースは個別に読み取られ、各項目ごとの失敗は致命的エラーではなく記録されます。無効なリンクや読み取れないブロックはスキップされ、agent は読めたものをもとに処理を進めます。ジョブ全体が失敗するのは、どのソースもまったく読み取れず、分析するものが何も残らなかった場合だけです。こうした結果の正確な形、つまり成功時に記録される各項目ごとの失敗や、何も読み取れなかったときの失敗ペイロードについては、AI が抽出する内容 と Webhook delivery を参照してください。
だから、すべての URL を事前に監査しなくても、候補をまとめて並べられます。強いソースは効き、弱いソースは落ちる。そして実際に何が取り込まれたかは、出力サマリーを見れば分かります。まずは手元にあるものを渡して、何が返ってきたかを確認してください。
