船会社・フォワーダーから届く日英混在のブッキング確認書を読み取り、本船名・航海番号・カット日・コンテナ本数を輸出案件の台帳に転記して、搬入の段取りに響く変更を拾う
船会社やフォワーダーから届くブッキング確認書のPDFを読み取り、本船名・航海番号・カット日・コンテナの本数などを輸出案件の台帳に転記します。差し替え版が届いたときは前の版と比べ、搬入の段取りに響く変更だけを担当に知らせます。
- 生成AI
- Azure OpenAI Service/Claude/Gemini
- AIサービス
- AWS Textract/Azure AI/Google Document AI
- 連携・自動化
- Google Apps Script/Make/n8n/Power Automate/Python
- 対象業界
- 商社/物流/製造
- 対象部門
- 物流
- 対象業務
- データ入力・転記/台帳・マスタ管理
- 主な課題
- 入力作業が多い/期限・対応漏れが起きる/確認ミスが多い
- AIで行う処理
- 読み取り(OCR)
- 主な効果
- 入力漏れ削減/対応スピード向上/工数削減
- 導入難易度
- ★★★☆☆
- 実装レベル
- 本格構成
- 費用感
- API連携(中)
- 人間の確認
- 条件付き
01導入前 / 導入後の業務フロー
- メールに添付された確認書のPDFを開く
- ブッキング番号で台帳の行を探す。新規なら行を作る
- 本船名、航海番号、積み地と揚げ地、出港予定日、各種カット日、コンテナの種類と本数、空コンテナの引き取り場所、搬入先を台帳に写す
- 差し替え版なら、前の版のPDFを開いて見比べ、変わった項目を探す
- 変わった項目が搬入や手配に響く場合は、ドレージの手配担当と工場に連絡する
- PDFを案件のフォルダに保存する
- 自動輸出課の共有アドレスに届いたメールから、確認書のPDFを受信フォルダに保存する
- 自動Azure AI Document Intelligence のレイアウトモデルに、問い合わせの項目(本船名、航海番号、カット日など)を付けて読み取らせる
- 自動値が取れなかった項目だけ、読み取った全文から Azure OpenAI に探させる
- 自動日付・本数・コンテナの種類を決めた書式にそろえる
- 自動ブッキング番号で台帳の行を探し、新規なら行の下書きを作り、既存なら台帳の現在の値と比べる
- 自動変わった項目を「段取りに響く変更」と「記録だけの変更」に分ける
- 自動段取りに響く変更があれば、担当者とドレージの手配担当に Teams で知らせる
- 人担当者が、信頼度の低い項目と変更のあった項目を確かめ、台帳に反映する
- 人必要な手配の変更を行う
各工程の詳しい説明を読む
- メールに添付された確認書のPDFを開く
- ブッキング番号で台帳の行を探す。新規なら行を作る
- 本船名、航海番号、積み地と揚げ地、出港予定日、各種カット日、コンテナの種類と本数、空コンテナの引き取り場所、搬入先を台帳に写す
- 差し替え版なら、前の版のPDFを開いて見比べ、変わった項目を探す
- 変わった項目が搬入や手配に響く場合は、ドレージの手配担当と工場に連絡する
- PDFを案件のフォルダに保存する
(a)様式が12社分ある。 本船名が上にある様式、表の中にある様式、項目名が「Vessel」「本船」「VSL/VOY」とまちまちです。カット日は「CY CUT」「搬入締切」「Closing」と呼び方が違い、日付の書き方も「2026/10/14」「14-OCT-26」「Oct 14」と揃いません。 写すたびに読み替えています。
(b)差し替え版の変更に気づかない。 差し替え版には変更箇所の印が無いことが多く、担当者は前の版と1項目ずつ見比べています。 本数が「2×40HC」から「1×40HC」に変わった、搬入先のターミナルが変わった、といった変更は、本船名と日付が同じだと見落とされます。
(c)カット日の写し間違いがいちばん重い。 日付の書き方が様式ごとに違うので、月と日を入れ違える、年をまたぐ確認書で年を誤ることがあります。カット日を過ぎて搬入しようとすれば、その本船には積めません。
(d)確認書が届いたことに気づかない。 個人のアドレスに届き、担当者が不在なら止まります。差し替え版で搬入締切が2日早まったのに、気づいたのが締切の前日ということが起きます。
- 【自動】 輸出課の共有アドレスに届いたメールから、確認書のPDFを受信フォルダに保存する
- 【自動】 Azure AI Document Intelligence のレイアウトモデルに、問い合わせの項目(本船名、航海番号、カット日など)を付けて読み取らせる
- 【自動】 値が取れなかった項目だけ、読み取った全文から Azure OpenAI に探させる
- 【自動】 日付・本数・コンテナの種類を決めた書式にそろえる
- 【自動】 ブッキング番号で台帳の行を探し、新規なら行の下書きを作り、既存なら台帳の現在の値と比べる
- 【自動】 変わった項目を「段取りに響く変更」と「記録だけの変更」に分ける
- 【自動】 段取りに響く変更があれば、担当者とドレージの手配担当に Teams で知らせる
- 【人】 担当者が、信頼度の低い項目と変更のあった項目を確かめ、台帳に反映する
- 【人】 必要な手配の変更を行う
人が見るのは、すべての項目ではありません。 読み取りの信頼度が高く、台帳の値と変わらない項目は、そのまま流します。担当者が開くのは、信頼度の低い項目と、変わった項目だけです。 全件を開く設計にすると、40.0時間はあまり減りません。
6番目の振り分けは、規則で行います。 カット日の繰り上げ、本船の変更、本数の減少、搬入先の変更は段取りに響き、ブッキング担当者名や備考の言い回しの変更は記録だけで足ります。 AIに「重要かどうか」を判断させず、項目ごとに決めておきます。
02今回想定するシステム構成
船会社・フォワーダーからのメール(確認書のPDF) │ 輸出課の共有アドレス ▼【トリガー】メールの受信 → 受信フォルダへ保存 Azure AI Document Intelligence(レイアウトモデル+問い合わせの項目) │ 全文・テーブル・項目の値と信頼度を返す ▼ Azure OpenAI ── 値が取れなかった項目だけを全文から探す ▼ Python ── 日付・本数・種類の書式をそろえ、台帳の現在の値と比べる ▼ 変更の振り分け(段取りに響く/記録だけ) ├──▶ Teams で担当者とドレージの手配担当に通知 ▼ 【担当者が信頼度の低い項目と変更点を確かめる】 ▼ 輸出案件の台帳に反映
| 役割 | 想定する製品 | 代替候補 |
|---|---|---|
| OCR | Azure AI Document Intelligence(レイアウトモデルと問い合わせの項目) | Google Document AI(Form Parser)。AWS Textract は英文の確認書に限る |
| 生成AI | Azure OpenAI(Microsoft Foundry) | Claude API、Gemini API |
| 差異計算 | Python(書式の統一と、台帳の値との比較) | Google Apps Script |
| 連携 | Power Automate(メールの受信、フォルダへの保存、Teams への通知) | Make、n8n |
輸出案件の台帳は、新しく作るものではありません。 今の台帳に「確認書の版」「最終確認日時」「変更の有無」の列を足し、読み取り結果を書く下書きのシートを別に置くのが最初の準備です。台帳そのものへの反映は、担当者が確かめてから行います。
読み取りの中心は、レイアウトモデルです。 テキスト、テーブル、選択マーク、ドキュメントの構造を抽出し、単語ごとに信頼度が返ります。 テーブルのセルには行と列のインデックスが付くので、コンテナの種類と本数が表になっている確認書でも、行ごとに取り出せます。
項目の名前のゆれは、問い合わせの項目(query fields)で吸収します。 問い合わせの項目は、追加の学習なしに抽出する項目を足せるアドオンの機能で、1回の要求で最大20項目まで指定できます。 「VesselName」「VoyageNumber」「CyCutOffDate」のように項目名を付けて渡すと、確認書の側の呼び方が「本船」でも「VSL」でも同じ項目として返ってきます。 ただし問い合わせの項目はほかのアドオンとは別の料金体系のプレミアムな機能とされているので、費用を見てから使う範囲を決めます。
03どうやって実装するのか
処理の起点を決める
輸出課の共有アドレスにメールが届いたことを起点にします。 担当者の個人のアドレスに届く確認書は、船会社とフォワーダーに送り先を共有アドレスへ変えてもらいます。 変えてもらえない相手の分は、個人のアドレスから共有アドレスへの自動転送を設定します。確認書が担当者の不在で止まらないようにすることが、この構成の最初の効果です。
Power Automate がメールを受け取ったら、添付のPDFを受信フォルダに保存し、読み取りを始めます。1日1回の定時処理にはしません。 差し替え版の変更は、届いたその時から段取りに響くからです。
処理が終わったPDFは処理済みのフォルダへ移し、失敗したものは受信フォルダに残します。 受信フォルダに残っている数が、そのまま未処理の数になります。
添付の無いメールにも気をつけます。 「本船遅延のため搬入締切を変更します」といった連絡が、確認書の差し替えより先にメール本文だけで届くことがあります。この構成は添付のPDFを読むものなので、本文だけのメールは読み取りの対象外です。ブッキング番号を含み添付の無いメールは、「本文のみの連絡」として担当者に転送するルールだけを Power Automate に置きます。
入力データを集める
| データ | 中身 | 取得元 |
|---|---|---|
| 確認書のPDF | ブッキング番号、本船名、航海番号、積み地・揚げ地、出港予定日、各種カット日、コンテナの種類と本数、空コンテナの引き取り場所、搬入先、備考 | メールの添付 |
| 読み取り結果 | 全文、テーブルとセル、問い合わせの項目の値、単語ごとの信頼度 | Azure AI Document Intelligence |
| 台帳の現在の値 | ブッキング番号ごとの、いま台帳にある各項目の値と、最後に反映した確認書の版 | 輸出案件の台帳 |
| 送り主の一覧 | 船会社・フォワーダーごとのメールアドレス、確認書の言語、日付の書き方の型 | 自社で用意する一覧 |
| 変更の振り分け表 | 項目ごとに、変わったら段取りに響くか、記録だけか | 輸出課で決める表 |
質を決めるのは、送り主の一覧の「日付の書き方の型」です。 「10/14/2026」は米国式なら10月14日ですが、「04/10/2026」は日・月の順なら10月4日、月・日の順なら4月10日です。 確認書の上では区別がつきません。送り主ごとに型を決めておき、書式をそろえるときに使います。
変更の振り分け表は、輸出課で決めます。 どの変更で誰に連絡するかは会社ごとに違い、AIに判断させると、日によって通知したりしなかったりします。
データの取得方法を決める
レイアウトモデルを、問い合わせの項目を付けて呼びます。 言語は指定しません。ドキュメントの言語を確信していない限り、言語コードを指定しないことが勧められています。日英が混在する行も含めて、言語の指定なしで抽出されるとされています。
| 取るもの | どこから | 何に使うか |
|---|---|---|
| 問い合わせの項目の値 | 問い合わせの項目の返却 | 本船名、航海番号、カット日など、台帳の列に当たる値 |
| テーブルとセル | レイアウトの tables | コンテナの種類と本数、複数の搬入先 |
| 単語ごとの信頼度 | レイアウトの words | 人が確かめる項目の選別 |
| 全文 | レイアウトの content | 値が取れなかった項目を探す材料 |
問い合わせの項目は、次の17項目にします。 上限の20項目に収め、台帳の列と1対1にします。
| 項目名 | 内容 |
|---|---|
| BookingNumber | ブッキング番号 |
| CarrierName | 船会社 |
| VesselName | 本船名 |
| VoyageNumber | 航海番号 |
| PortOfLoading / PortOfDischarge | 積み地/揚げ地 |
| Etd / Eta | 出港予定日/到着予定日 |
| CyOpenDate | 搬入開始日 |
| CyCutOffDateTime | 搬入締切の日時 |
| DocCutOffDateTime | 書類の締切の日時 |
| VgmCutOffDateTime | VGM(総重量の確定値)の締切の日時 |
| ContainerTypeAndQuantity | コンテナの種類と本数 |
| EmptyPickupPlace | 空コンテナの引き取り場所 |
| ReturnTerminal | 搬入先のターミナル |
| BookingIssueDate | 確認書の発行日 |
| Remarks | 備考 |
台帳の現在の値は、ブッキング番号で引きます。 ブッキング番号が読めなかったときに、本船名と出港予定日で探すことはしません。同じ本船に複数のブッキングがあるので、取り違えます。
AIへ渡す前に整形する
- 送り主の特定 … メールアドレスから送り主の一覧を引き、日付の書き方の型を決めます。一覧に無い送り主は「送り主未登録」で人に回します
- 添付の選別 … 確認書以外の添付(会社案内、約款の抜粋、署名の画像)を外します。ファイル名とページ数で選び、迷うものは読み取って項目がほとんど取れなければ外します
- パスワードの確認 … パスワードでロックされたPDFは、提出前に解除が必要です。解除できないものは送り主に依頼します
- ページの絞り込み … 確認書の後ろに約款が何ページも付いている様式は、
pagesで確認書のページだけを読みます - 同じ版の重複の確認 … 同じブッキング番号・同じ発行日のPDFが二度届いたら、2通目は読み取らずに記録だけ残します
読み取った後の書式の統一は、次の決まりで行います。
| 対象 | 決まり |
|---|---|
| 日付の順序 | 送り主の一覧の型(年月日/日月年/月日年)で解釈する |
| 年の無い日付 | 確認書の発行日以降で最も近い日付にし、出港予定日より後の締切は ambiguous |
| 時刻 | 「12:00」「NOON」「正午」をそろえる。時刻の無い締切は時刻を空にする |
| コンテナの種類 | 「40HC」「40' HQ」「40ft ハイキューブ」を自社の種類コードに直す |
| 本数 | 種類ごとに整数で持つ。「2×40HC+1×20GP」は2行にする |
4番目は費用に効きます。 読み取りはページ単位で数えられ、問い合わせの項目は別の料金体系です。裏面の約款まで毎回読むと、確認書1通の費用が何倍にもなります。
AIに処理させる
読み取りは Azure AI Document Intelligence、値が取れなかった項目の補いは Azure OpenAI、比較と振り分けは Python と分けます。
| させること | 担当 | 判断できないときの扱い |
|---|---|---|
| 17項目の値と信頼度の読み取り | Azure AI Document Intelligence | 値が無ければ空のまま返す |
| 値が取れなかった項目を全文から探す | Azure OpenAI | 全文に無ければ not_found |
| 日付・本数・種類の書式の統一 | Python | 型で解釈できなければ ambiguous |
| 台帳の現在の値との比較 | Python | 台帳に行が無ければ新規 |
| 変更の振り分け | Python(振り分け表) | 表に無い項目は「記録だけ」にして人へ |
Azure OpenAI に渡すのは、取れなかった項目の名前と全文だけです。 取れた項目まで渡して「確かめて」と頼むと、信頼度の高い値を書き換えてきます。
| させないこと | 理由 |
|---|---|
| 日付の月と日の順序の推測 | 送り主の型で決める。推測は月日の入れ違いを生む |
| 本数の合計・換算 | 「2×40HC」を「2本」にまとめない。種類ごとに持つ |
| 変更が重要かどうかの判断 | 振り分け表で決める |
| 台帳への直接の書き込み | 担当者が確かめてから反映する |
| 本船名の表記の補正 | 読み取った文字列をそのまま持つ。名寄せは一覧で行う |
1行目がいちばん起きやすい失敗です。 「04/10」を見た生成AIは、文脈からそれらしい順序を選びます。選んだ根拠は残りません。 日付の解釈は、送り主ごとの型という決まった規則に置きます。
指示内容を固定する
値が取れなかった項目を、Azure OpenAI に全文から探させるときの指示です。
あなたは輸出業務の担当者です。
下の【確認書の全文】は、船会社またはフォワーダーから届いた
ブッキング確認書をOCRで読み取ったものです。日本語と英語が混在しています。
【探す項目】に挙げた項目だけについて、全文の中から値を探してください。
【厳守事項】
- 全文に書かれている文字列を、そのまま value に写してください。
日付の書き方を直す、月と日を入れ替える、年を補うことをしないでください。
- 見つからない項目は status を not_found にしてください。推測で埋めないでください。
- 候補が2つ以上あって1つに決められない場合は、status を ambiguous にし、
candidates にすべての候補を写してください。
例:搬入締切が2か所に違う日付で書かれている場合。
- 値の根拠にした行を evidence にそのまま写してください。
- 【探す項目】以外の項目について書かないでください。
- 変更があったかどうか、重要かどうかを判断しないでください。
【探す項目】{missing_fields}
【項目の説明と、確認書での呼び方の例】{field_glossary}
【確認書の全文】{content}
「年を補わない」を書いているのは、年をまたぐ時期の確認書のためです。 12月に届いた確認書の「JAN 08」に、生成AIは届いた年を補います。年の補い方は、出港予定日との前後関係で Python が決めます。
「候補が2つ以上なら ambiguous」も大事です。 差し替え版には、旧い締切が取り消し線で残り、新しい締切が横に書かれている様式があります。OCRには取り消し線が見えないことがあり、片方だけを選ばせると旧い日付を拾います。
出力形式を固定する
次の形のJSONで受け取ります。
{
"booking_number": "",
"fields": [
{ "name": "CyCutOffDateTime", "value": "", "status": "found | not_found | ambiguous",
"candidates": [], "evidence": "" }
]
}
Azure OpenAI の Structured Outputs で形を固定します。すべての項目を必須にし、additionalProperties を false にすることが求められていて、status に決めていない値が返ってこなくなります。
Python は、レイアウトモデルの結果と合わせて、台帳と比べる形にそろえます。
| 列 | 中身 |
|---|---|
| ブッキング番号 | 台帳を引くキー |
| 項目 | 17項目のどれか |
| 確認書の値(そろえた後) | 日付は YYYY-MM-DD HH:MM、本数は種類ごと |
| 確認書の値(元の文字列) | 読み取ったままの文字列 |
| 信頼度 | 読み取りの信頼度。補った項目は空 |
| 取り方 | 問い合わせの項目/テーブル/生成AIの補い |
| 台帳の現在の値 | 比べる相手 |
| 変更 | なし/あり |
| 振り分け | 段取りに響く/記録だけ |
元の文字列を残すのは、書式をそろえる処理の誤りを人が見つけるためです。 そろえた後の値だけだと、月日の入れ違いが起きても、整った日付に見えます。
「取り方」の列で、生成AIが補った値を分けます。 補った値は、信頼度にかかわらず人が確かめる対象にします。
変更の振り分け表は、たとえば次のようにします。
| 項目 | 変わったとき | 知らせる相手 |
|---|---|---|
| 本船名・航海番号 | 段取りに響く | 担当者、ドレージの手配担当、通関業者の窓口 |
| 搬入締切 | 繰り上げなら段取りに響く、繰り下げなら記録だけ | 担当者、ドレージの手配担当 |
| コンテナの種類と本数 | 段取りに響く | 担当者、工場の出荷担当 |
| 搬入先のターミナル・空コンテナの引き取り場所 | 段取りに響く | 担当者、ドレージの手配担当 |
| 出港予定日 | 2日以上の変更なら段取りに響く | 担当者 |
| 備考 | 記録だけ。文字列が変わったら担当者が読む | 担当者 |
システムへ連携する
| つなぎ先 | 方式 | 内容 |
|---|---|---|
| 共有アドレス | Power Automate のメール受信 | 添付を受信フォルダに保存 |
| Azure AI Document Intelligence | API呼び出し | レイアウトと問い合わせの項目 |
| Azure OpenAI | API呼び出し | 取れなかった項目を全文から探す |
| 輸出案件の台帳 | Python の読み取りと、下書きのシートへの書き込み | 現在の値との比較 |
| Teams | Power Automate の投稿 | 段取りに響く変更の通知 |
台帳そのものには書き込みません。 書くのは下書きのシートまでで、担当者が確かめて反映します。台帳は物流部の全員が見て手配を決める場所で、未確認の値が入ると後ろの工程がそれを信じて動きます。
人が確認する
担当者が見るのは、次のどれかに当たる項目だけです。
- 段取りに響く変更があった項目 … 確認書の該当箇所と、台帳の値を並べて見ます
- 信頼度が低い項目 … 読み取りの信頼度が決めた値を下回る項目
- 生成AIが補った項目と、
ambiguousの項目 … 元の文字列と根拠の行を見ます - 新規のブッキング … 初回だけは全項目を流し見ます
信頼度の基準値は、最初は高めに置きます。 信頼度は予測が正しい確率の推定で、精度が重要な場面では自動で受け入れるか人の確認に回すかの判断に使えるとされています。運用の初めの1か月は、人が見た結果と信頼度を並べて記録し、基準値を決め直します。
1番目は、通知を受けた担当者がその日のうちに見ます。 変更の確認が遅れると、通知した意味がありません。通知には確認書のPDFと、変わった項目の新旧の値を並べて載せます。
4番目の新規を全項目見るのは、以後の比較の基準になるからです。 新規の確認書で台帳に入った値が、差し替え版と比べる相手になります。最初の値が誤っていると、以後の比較はずっと誤った値との比較になります。
目標は、300通をならして1通2分です。 変更も信頼度の低い項目も無い確認書は、一覧で確かめるだけになります。
例外に対処する
| 起きること | 対応 |
|---|---|
| ブッキング番号が読めない | 台帳を引かずに人へ。本船名と日付で探さない |
| 台帳に無いブッキング番号の差し替え版 | 新規として作らず、人へ。番号の付け替えを疑う |
| 送り主が一覧に無い | 日付の型が決まらないので、人へ。一覧に足す |
| 日付が型で解釈できない | ambiguous として人へ |
| 確認書以外の書類だった | 処理済みに移さず、別のフォルダへ。人が仕分ける |
| 取り消し線などで値が2つある | ambiguous。人が新しいほうを選ぶ |
| 1通に複数のブッキングが載っている | ブッキング番号ごとに分けて比べる。分けられなければ人へ |
| 読み取りが応答しない | 受信フォルダに残す。処理済みへ移すのは成功時だけ |
2行目を軽く見ないでください。 船会社によっては、本船の変更でブッキング番号を振り直します。新規として台帳に行を作ると、同じ貨物の行が2つでき、古い行の締切で手配が進みます。
記録を残す
- 元のPDFと、受け取った日時・送り主
- 読み取り結果のJSONの全文
- 生成AIが補った項目と、その根拠の行
- 比較の結果(項目ごとの新旧の値と振り分け)
- 通知した日時と相手
- 担当者が確かめた日時と、台帳に反映した値
4つ目の新旧の値は、後から「いつ締切が変わったのか」を答えるためです。 搬入が間に合わなかったとき、変更の確認書がいつ届き、いつ誰に知らせたかが残っていないと、原因を追えません。
送り主ごとの変更の回数も集計します。 差し替え版が特に多い送り主は、ブッキングの段階での条件の詰め方を見直す材料になります。
04実装レベルの3段階
最小構成では、件数がさばけません。 1通ずつ Studio で開くので、確かめるための段階です。 半自動化で、1通8分が4分程度になります。 写す作業は無くなりますが、差し替え版の見比べは人に残ります。本格構成で2分になり、この段階が本記事の想定です。 差が大きいのは、見比べと連絡先の判断が、1通ずつの手作業だからです。 段階を飛ばさないでください。 半自動化の1か月で、送り主ごとの取れ方の差が分かります。取れにくい送り主には、項目名の説明を足すか、確認書の送り方を相談してから本格構成に進みます。
05工数削減シミュレーション
導入後 300件 × 2分 ÷ 60 = 10 時間/月
自社条件で導入効果を整理したい方へ
このユースケースを自社に当てはめた場合の前提値と削減見込みを、業務ヒアリングをもとに整理します。
06向いている企業・向いていない企業
- 海上コンテナで輸出していて、船会社やフォワーダーから月に数百通のブッキング確認書(差し替え版を含む)を受け取り、輸出案件の台帳へ手で写している商社・メーカーの輸出部門・フォワーダー。船会社が複数あり、確認書の様式が日本語・英語・日英混在とばらばらな場合。本船の変更やカット日の繰り上げに気づくのが遅れ、バンニングや搬入の手配をやり直した経験がある場合。
- 船会社が1〜2社で、ブッキングの内容をシステム連携やCSVで受け取れる場合(読み取りの工程そのものが要りません)。輸出が月に数件で、担当者が全件を覚えていられる規模。航空便や混載(LCL)が中心で、コンテナ単位の搬入の段取りが無い場合。なお、搬入や通関の手配そのものを自動で変える設計にはしていません。
07最小構成で試す方法
- 先月の確認書から50通を選ぶ(12社すべてを含め、差し替え版を20通以上入れる)
- Document Intelligence Studio でレイアウトモデルを開き、問い合わせの項目を付けて読み取る
- 読み取った値を、台帳に当時写した値と並べる
- 差し替え版について、前の版の読み取り結果と項目ごとに比べ、変わった項目を表にする
- その表を、当時担当者が気づいた変更と比べる
確かめたいのは、日付の読み取りと、差し替え版の変更が拾えるかの2つです。
| 出てきた内容 | 判断 |
|---|---|
| 日付と本数がほぼ正しく取れ、変更も拾えた | メール受信からの連携に進む |
| 特定の送り主だけ項目が取れない | 問い合わせの項目の名前と説明を見直す。その送り主だけカスタムモデルを検討 |
| 担当者が気づかなかった変更が見つかった | この構成の効果そのもの。 振り分け表の作成を急ぐ |
3行目が出ることは珍しくありません。 備考欄の「搬入先変更」や本数の変更は、見比べで落ちやすいものです。見つかった件数が、この構成を入れる理由になります。
2行目のカスタムモデルは、最後の手段にします。 決まった様式で届く送り主なら、カスタムテンプレートモデルで項目の位置を学習させる方法もあります。ただし船会社が様式を変えるたびに学習し直す手間が生まれます。まずは問い合わせの項目の名前と説明を工夫し、それでも取れない送り主だけに絞ってください。
08実装時につまずきやすいポイント
| 問題 | 対策 |
|---|---|
| 日付の月と日が入れ替わる | 送り主ごとに型を決め、推測させない。元の文字列を残す |
| 年をまたぐ確認書で年を誤る | 出港予定日との前後関係で年を決める |
| 差し替え版を新規として登録する | ブッキング番号で引き、無ければ人へ。番号の付け替えを疑う |
| 取り消し線の旧い値を拾う | 値が2つあれば ambiguous にして人へ |
| 言語を指定して読み取り、英語か日本語が欠ける | 言語コードを指定しない |
| 問い合わせの項目が20を超える | 台帳の列と1対1にして17項目に収める |
| 裏面の約款まで読んで費用が膨らむ | pages で確認書のページだけを読む |
| 生成AIが信頼度の高い値を書き換える | 取れなかった項目だけを渡す |
| 通知が多すぎて読まれなくなる | 振り分け表で「記録だけ」を分ける |
| 個人のアドレスに届き続ける | 送り主に共有アドレスへの変更を依頼する |
上の2行が、この構成の失敗のほとんどです。 日付の誤りは、整った書式に直された瞬間に人の目から消えます。元の文字列を並べて表示することが、最後の守りです。
下の2行は、運用が回り始めてから効いてきます。 通知が多すぎると、段取りに響く変更の通知まで読まれなくなります。 振り分け表は、最初の1か月の通知を見て絞り直してください。
09セキュリティ・AIガバナンス上の注意点
この構成で扱うデータ: 荷主と荷受人の名称、貨物の品名と数量、仕向地、本船と日程です。個人情報はほとんど含みませんが、取引先と仕向地と数量は、競合に知られたくない営業情報です。
- 確認書を扱う範囲を物流部に限る … 受信フォルダと下書きのシートの閲覧権限を、輸出課と手配担当に絞ります
- 読み取りと生成AIの処理場所を揃える … Azure AI Document Intelligence と Azure OpenAI を同じテナントで使い、確認書の内容を社外の別のサービスに渡す経路を作りません
- 台帳への反映を人が行う … 未確認の値で手配が動く経路を作りません。台帳は物流部の判断の土台です
- 通知に載せる内容を絞る … Teams の通知には変わった項目の新旧の値とPDFへのリンクだけを載せ、貨物の品名や取引条件を書きません
- 安全保障輸出管理の判断と切り離す … 仕向地や品名から輸出の可否を判断することは、この構成の役割ではありません。該非判定や取引審査は、別の手順で行ってください
誤りが起きた場合のリスクは、誤った締切で手配が進むことと、変更に気づかないことの2つです。 前者は元の文字列と信頼度で、後者は台帳の値との機械的な比較で止めます。どちらも、人が台帳に反映する前に気づける設計にしておきます。
10まず何から始めるか
1週目:送り主の一覧を作る
12社の送り主ごとに、メールアドレス、確認書の言語、日付の書き方の型を表にします。型が分からない送り主は、過去の確認書で確かめます。
2週目:50通で試す
先月の確認書から50通を選び、Document Intelligence Studio で問い合わせの項目を付けて読み取ります。日付が正しく取れているかを最優先で見ます。
3週目:変更の振り分け表を作る
17項目のそれぞれについて、変わったら段取りに響くか、記録だけかを決め、知らせる相手を書きます。 ドレージの手配担当と工場の出荷担当にも見てもらいます。
4週目:共有アドレスから下書きのシートまでをつなぐ
Power Automate でメールの受信から読み取り、下書きのシートへの書き出しまでを作ります。船会社とフォワーダーに、送り先を共有アドレスに変えてもらう依頼もこの週に出します。
2か月目: 台帳の値との比較と振り分けを足し、通知はまず担当者だけに送ります。3か月目以降: ドレージの手配担当への通知を足し、1通8分が何分になったかを実測します。差し替え版の変更に、届いたその日のうちに全件気づけるようになった時点で、この構成は完成です。
11関連ユースケース
12この仕組みを理解するための記事
13技術仕様の確認日・参考情報
| 確認した内容 | 情報源 | 確認日 |
|---|---|---|
レイアウトモデルがテキスト・テーブル・選択マーク・ドキュメント構造を抽出すること。単語ごとに confidence が返ること。テーブルの各セルに行と列のインデックスが含まれること。pages クエリパラメーターでページを指定できること。PDFとTIFFで最大2,000ページ、有料(S0)で500MB。パスワード付きPDFは提出前に解除が必要なこと。画像サイズと最小の文字高の要件 | Microsoft Learn: ドキュメント レイアウト分析 | 2026-10-06 |
| 問い合わせの項目(query fields)が追加の学習なしに抽出項目を足せるアドオンで、1回の要求で最大20項目まで指定できること。プレミアムなアドオンで、ほかのアドオンとは別の料金体系であること。レイアウトと事前構築済みモデルの 2024-11-30(GA)で使えること。複数語の項目名はキャメルケースかパスカルケースが勧められること | Microsoft Learn: Add-on capabilities | 2026-10-06 |
| 読み取りとレイアウトが、混在する言語の行を含めて言語コードの指定なしに抽出すること。言語を確信していない限り言語コードを指定しないことが勧められること。印刷文字の対応言語に日本語と英語が含まれること | Microsoft Learn: Language support for Read and Layout | 2026-10-06 |
| 信頼度が予測が正しい確率の推定で、精度が重要な場面では自動で受け入れるか人の確認に回すかの判断に使えること。人による確認を工程に組み込むことが勧められていること | Microsoft Learn: Interpret and improve model accuracy and confidence scores | 2026-10-06 |
Azure OpenAI の Structured Outputs が JSON スキーマへの準拠をさせ、Chat Completions API と Responses API の両方で使えること。すべての項目を必須にし additionalProperties を false にすること | Microsoft Learn: Azure OpenAI の structured outputs | 2026-10-06 |
ブッキング確認書の様式と項目の呼び方は、船会社とフォワーダーごとに異なります。 本記事の17項目は一例です。自社の台帳の列に合わせて決めてください。
実装ステータス:構成例。 公開仕様に基づいて設計した構成であり、当社で実際に構築・検証したものではありません。工数の数値はモデル条件による試算です。
自社の業務に使えるAI活用候補を整理します
このユースケース(UC-0544)についてのご相談はこちらから。
