仕入リスト → そのまま出品できるカタログ

導入の進め方

三つのフェーズ、それぞれが承認可能な成果物で終わります

導入プロジェクトが止まる原因は、多くの場合モデルではなく範囲です。以下の各フェーズは書面の成果物で締めくくられ、次のフェーズは推測ではなく合意から始まります。

1. 01

   要件の確定

   既存の帳票とシステムを棚卸しし、どの項目が重要でどう読み取るかを確認したうえで、人が確認する範囲とワークフローが判定する範囲の境界を引きます。

   このフェーズの成果物各項目、各読み取りルール、各確認ポイントを明記した書面の範囲定義。

2. 02

   短期での提供

   ワークフローは既存の汎用ツールを組み合わせて構成し、一社のためにプラットフォームを改変することはありません。まず実際のサンプル帳票で実行し、結果が安定してから件数を増やします。

   このフェーズの成果物実サンプルで動作するワークフローと、拡大前に計測した一回あたりのコスト。

3. 03

   継続的な安全性

   実行のたびにツール呼び出しの記録が残ります。保持期間、削除の扱い、サブプロセッサー一覧はいずれも公開ページであり、セキュリティ担当者は問い合わせずに確認できます。

   このフェーズの成果物実行ごとの監査証跡と、保持・削除・サブプロセッサーに関する書面の説明。

提供範囲

お預かりするものと、お返しするもの

商品カタログ案件の範囲は、受け取る元データの形式と、最終的にどの取り込みツールに通すかで決まります。着手前に、その両方を明記します。

想定される成果

仕入先からの一度の受領を、最初から最後まで

同じカタログについて、仕入先から実際に届いたファイルから、取り込みツールが受け付ける CSV までを示します。

システム連携

一度作れば、Web・API・SDK から同じワークフローを呼び出せます

ワークフローは Builder で一度作ります。3 つの呼び出し口はすべてその 1 本を指し、別々に保守するコピーではありません。

• 呼び出し方法

  Web 画面、REST · Python SDK · TypeScript SDK。エージェント型は WebSocket でイベントを配信し、決定的な変換はポーリングです。

• 実行場所

  ワークフローはクラウドで実行します。デスクトップ版 Ainalyn（beta）は画像・PDF・OCR の変換を端末内で行い、convilyn.local はキーもネットワークも不要でオフラインに変換します。

• 自社ツール

  自社でツールサーバーを用意し、プラットフォームから呼び出させられます。送信はすべて HMAC-SHA256 署名とタイムスタンプ付きで、送信元を検証できます。

URL 取り込みは https のみを受け付け、リダイレクトは追わず、内部ネットワークに解決されるアドレスは拒否し、サイズ上限もあります。ダウンロードリンクは短期の署名付き URL で、再発行できます。

Convilyn を選ぶ理由

ワークフロー基盤は自社のもので、約束は検証できます

文書自動化の導入はセキュリティ審査で止まります。この節の各項目は、ご相談の前に確認できます。

• プライバシーは既定値です。探して有効にする設定ではありません

  モデル提供者は貴社の内容を学習に使いません。API キーで開始した実行は、コード上で Convilyn 自身のモデル作業から除外され、fail-closed です。既定で拒否するので、方針の表明にとどまりません。

• 連携の柔軟性。制約は多くの場合、貴社側にあります

  接続方法は上の節で挙げました。もう一方をお伝えします。対応できない要件は、稼働後ではなく評価の段階で申し上げます。

• モデルの学習

  AWS Bedrock 経由で送信した入力と出力は、Anthropic のモデル学習には使いません（Bedrock のデータ保護条項をご参照ください）。API キーで開始した実行は、コードによって Convilyn の学習データから除外します。

• 削除

  ファイルは API で即時に削除できます。削除できるのはアップロードした本人のみです。実行中のワークフローに紐づくファイルは、その実行が終わるまで保護します。

• 暗号化と分離

  通信は TLS、保存データは暗号化します。保存パスはアカウントごとに分離し、読み取りと削除のたびに所有権を確認します。識別子を当てても、他のアカウントのファイルには届きません。

• 機微情報のマスキング

  項目名と値の形をルールで照合するため、resume_text のような項目の中身も検出します。機微かどうかの判断をモデルに委ねません。

• サブプロセッサー

  顧客コンテンツを扱うサブプロセッサーは、その役割と処理リージョンとともにすべて公開しています。当該ページは常に最新の一覧であり、問い合わせ用の連絡先もページに記載しています。

処理を行うリージョンは現在固定です。ファイルの保管とワークフローの実行は東京（ap-northeast-1）、モデル推論は us-east-1、OCR はシンガポール（ap-southeast-1）です。リクエストごとにリージョンを選ぶことはできません。データの所在に関する要件がある場合は相談の段階でお知らせください。対応できることとできないことを率直にご説明します。

• プライバシーポリシー
• サブプロセッサー一覧
• 利用規約

よくある質問

導入前によく寄せられる質問

• 導入までどのくらいかかりますか

  期間は商品点数ではなく、対象となる仕入先フォーマットの種類数に比例します。一社分のレイアウトは通常、最初の提供フェーズで動くようになります。以降は、すでに動いているワークフローの上に一形式ずつ積み増す形です。

• ストアやセラーセンターを変更する必要がありますか

  その必要はありません。ワークフローが読むのは貴社がセラーセンターから書き出した取り込み用テンプレートで、その実際の列に書き戻すため、モール側のレイアウトを前提にしません。成果物はそのままアップロードできるファイルです。この手順も自動化したい場合は REST API と SDK を利用できます。

• 仕入先の価格情報がモデルの学習に使われますか

  いいえ。仕入先の見積や原価データが学習データになることはありません。モデル提供者も、当社も使いません。

• 価格や単位を読み違えた場合はどうなりますか

  価格と単位は元データから転記するだけで再計算せず、判断がつかない項目は推測せずに例外として一覧化します。価格が読み取れない商品は報告され、作られた値で出品されることはありません。

• どのように始めればよいですか

  実際の仕入先ファイル 1 件と、セラーセンターから書き出した取り込みテンプレートをご用意ください。