Convilyn 通関前パケット・エージェント

導入の進め方

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

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

1. 01

   要件の確定

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

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

2. 02

   短期での提供

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

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

3. 03

   継続的な安全性

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

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

提供範囲

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

通関前業務の範囲は、書類の種類と誰が承認するかで決まります。着手前に、その両方を明記します。

想定される成果

一件の貨物を、最初から最後まで

同じ貨物について、実際に届く状態から、通関担当者が確認を始められる書類束までを示します。

システム連携

一度作れば、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）です。リクエストごとにリージョンを選ぶことはできません。データの所在に関する要件がある場合は相談の段階でお知らせください。対応できることとできないことを率直にご説明します。

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

よくある質問

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

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

  多くの場合いちばん長いのは要件の確定で、対象となる書類の種類と例外の多さに比例します。提供フェーズは試験環境ではなく実際の貨物書類で進めるため、すべての書類種別を網羅する前に使える成果物が出ます。

• 既存の申告システムを変更する必要がありますか

  その必要はありません。書類はアップロード、クラウドストレージ取り込み、URL、専用の受信用メールアドレスから受け取れます。書類束は現在申告に使っている様式で返却し、PDF と JSON も併せて出力します。直接つなぎたい場合は REST API と Python・TypeScript の SDK を利用できます。

• 取引先の貨物書類がモデルの学習に使われますか

  いいえ。請求書・船荷証券・取引先データが学習データになることはありません。モデル提供者も、当社も使いません。

• 読み取りが誤っていた場合はどうなりますか

  食い違う値は黙って解決せず対照として提示し、原文に根拠のない項目は空欄のまま残します。有資格の通関担当者が確認または修正し、その判断はすべて記録されます。

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

  実際の出荷数件分の書類と、現在申告に使っているパケットの様式をご用意ください。