保険金支払システム
判断業務を任せるAIエージェント ATLS
概要
ATLSは、Lazarusが提供するAIエージェントのサービスです。指示を受けると、推論に必要となるツールを自律的に選択し、それぞれの結果をつなぎ合わせ、最終的な回答と、すべてのプロセスの記録を返します。ATLSの価値が最も出るのは、多くのドキュメントを確認し、社内外の情報や規程と突き合わせ、複雑なプロセスを経ながら判断・決定を下す業務です。業界を問わず大きなインパクトをもたらすことが可能です。担当者は、ATLSが提供する情報と根拠を確認し、最終的な判断を従来の何十倍もの速さで迅速に下すことができるようになります。
本書の前半ではATLSの仕組み、強み、活用できる業務を、後半では保険金審査を例に、導入の効果、リスク、進め方を説明します。要点は、ATLSに任せる範囲、人に残す範囲、効果、投資の4つに分けられます。
- ATLSに任せる範囲は、書類の読み取り、社内外のデータとの照合、規程やルールへの当てはめ、報告書や判断案の下書きです。
- 人に残す範囲は、最終的な判断、顧客や取引先への通知、途中の承認です。
- 経営上の効果は、作業時間の短縮、判断のばらつきの抑制、判断理由の説明しやすさ、見落としの防止の4つで現れると考えています。
- 主な投資は、既存のシステムとの接続と、規程や基準をルールとして整理する作業です。
ATLSの強みは、自社のクラウド環境の中で動くこと、手順を自律的に組み立てて結果が出るまで繰り返すこと、すべての手順が記録に残ること、社内システムを自社が決めた範囲でつなげられることです。本書では、この強みを生む仕組みと、保険金審査でのユースケースを説明します。
ATLSとは
AIエージェントは、目的を伝えると、必要な作業の順序を自律的に組み立て、ツールを使い分けて結果を導き出すAIです。従来の自動化は、人が決めた手順をそのとおりに繰り返すルールベースでした。AIエージェントは、思考とその結果を常に分析しながら最適な次の作業を自律的に決め、実行します。
ATLSが使うツールには、書類の文字読み取り（OCR）、画像や手書きの読み取り、計算、社内規程の検索（RAG）などがあります。自社のシステムを呼び出すツールを追加することもできます。
| 使用時の観点 | 定型業務の自動化（RPA） | チャット型の生成AI | AIエージェント（ATLS） |
|---|---|---|---|
| 指示の仕方 | 手順を事前に細かく設定する | 1問ずつ質問する | 目的と守るべき条件を伝える |
| 扱える情報 | 決まった画面や帳票 | 貼り付けた文章やファイル | PDF、画像、手書きの書類を多数まとめて |
| 社内システムとの関係 | 画面操作でつなぐ | つながらないことが多い | 自社が用意した窓口だけを通して照会する |
| 作業の記録 | 操作のログ | 会話の履歴 | どのツールを何に使い、何が返ったかの全手順と履歴 |
| 向いている業務 | 手順が決まった大量の処理 | 文章の作成や要約 | 複数の情報を集めて突き合わせ、判断の材料を作る業務 |
ATLSには、経営の立場から見て大事な特徴が3つあります。自社のクラウド環境（VPC）の中で動くので、書類や契約情報を社外のサービスに預けずに済みます。どのツールを、何のために使い、何が返ったかが、すべて記録に残ります。社内システムには自社が用意した窓口を通してだけアクセスするので、AIに渡す情報の範囲は自社で決められます。
ATLSの強み
ATLSの強みは、非定型の書類を扱う判断業務を、自社の管理下に置いたままAIエージェントに任せられることです。従来の自動化は定型の手順に、チャット型の生成AIは1問ずつのやりとりに向いていました。ATLSは、書類を読み、調べ、計算し、結果をまとめるところまでを一続きで行います。
| 強み | ATLSができること | お客様が得る価値 |
|---|---|---|
| 手順を自律的に組み立てる | 目的を受け取り、次に使うツールを選び、最終回答が出るまで繰り返す | 案件ごとに手順が違う業務でも、手順書を作り込まずに任せられる |
| 非定型の書類に強い | OCR、画像と手書きの読み取り、数百ページの文書の並列処理を、設定なしで使える | 契約書、報告書、写真などをそのまま渡せる |
| 自社の環境で動く | 自社のクラウド環境（VPC）に置き、利用者ごとにデータを分ける | 個人情報を社外のサービスに預けずに済む |
| 社内システムを安全につなぐ | 自社が用意した窓口を、ATLSが必要なときに利用する。実際の照会は自社のプログラムが行う | 社内システムの認証情報をATLSに渡さず、渡す項目も自社が決められる |
| すべてが記録に残る | どのツールを、どの条件で呼び、何が返ったかを、所要時間とともに件ごとに記録する | 判断の経緯を監査や苦情対応で示せる |
| 人の判断を組み込める | 自社の窓口を呼ぶところで作業を止め、結果が返るまで待つ | 承認や調査依頼といった人の判断を、流れの途中に入れられる |
アーキテクチャと技術的な優位性
ATLSの中心にあるのは、判断とツールの実行を最終的な回答が出るまで自律的に繰り返す仕組みです。ATLSが、これまでのプロセスの経過を分析しながら次に使うツールを決め、その結果をまたメモリーに加え更新しながら、また次の実行タスクを決めていきます。
組み込まれているビルトインツールはATLSの中で並列に動き、作業を止めません。自社の窓口を呼ぶときは、ATLSは作業を一旦止めて自社のプログラムからの結果を待ちます。この結合ポイントがあるので、社内システムへの照会や人間による承認を、システムの処理途中でも安全に挟むことができます。
前述のエージェントループを支える技術と、それぞれの利点をまとめました。
| 技術 | 仕組み | 利点 |
|---|---|---|
| 2つのAIモデルの使い分け | 流れを決める判断用のモデルと、ツールの中で文章や画像を処理するモデルを分け、使用量も別々に記録する | どの作業にどれだけ計算資源を使ったかが分かり、費用を管理しやすい |
| 長い文書の並列処理 | 数百ページの文書を数ページずつに分けて同時に処理し、最後に1つの結果にまとめる。同じ文書のOCR結果は再利用する | 分厚い記録や契約書も扱える。同じ文書を何度も分析するときに速い |
| 表や手書きの読み取り | ページの画像とOCRの文字を両方使って読む | 帳票、チェック欄、手書きの記入も拾える |
| サブエージェント | 大きな作業を子エージェントに分けて任せる | 書類の種類ごとに並行して処理できる |
| 隔離した計算環境 | 集計や照合は、外部ネットワークにつながらない使い捨ての環境でPythonを動かして行う | 計算が正確で、データが外に出ない |
| 自社の窓口を標準形式で定義 | 社内システムを呼ぶツールを、広く使われている OpenAI の関数呼び出しの形式で定義する | 既存の開発資産や知識を活かして窓口を作れる |
| 利用者ごとのデータ分離 | 利用者ごとに専用の保管場所を用意し、アクセス権をその場所だけに限る | 他の利用者の書類や結果が混ざらない |
| 全手順の記録と稼働監視 | 各手順のツール、条件、結果、所要時間、使用量を記録し、稼働状況を標準の監視ツール（Prometheus）で見られるようにする | 監査に必要な証跡と、運用に必要な数字がどちらも残る |
| 障害からの回復 | 処理の時間切れや、AIモデルが一度に扱える量を超えたときに、自動で立ち直る | 長い作業の途中で止まりにくい |
標準ビルトインツール
ATLSは、標準的に組み込まれたビルトインツールを設定をしなくてもすべて使えます。ツールの名前と数はバージョンによって違います。v1.2.0では30個以上のツールを用意しており、セッション中のメモやExcelの構造確認なども含まれます。導入する環境でツールが使えるかどうかは、担当者へご確認ください。
| 分類 | 主なツール | できること |
|---|---|---|
| 文書とOCR | pdf_get_metadata、ocr_document、ocr_get_pages | PDFのページ数の確認、OCR、ページを指定した文字の取り出し。同じ文書のOCR結果は再利用する |
| 長い文書の処理 | llm_process_document_with_ocr、llm_process_pdf_with_vision_and_ocr | 数百ページの文書を分割して並列に処理し、結果をまとめる。表や手書きは画像も使って読む |
| 画像と手書き | llm_process_image、llm_process_pdf_page、llm_process_pdf_with_vision | 写真、手書きの書類、表、図を画像として読み取る |
| 文章の処理 | llm_process_text、llm_process_text_file、read_text_file | 要約、抽出、翻訳、整形。前のジョブの結果を読む |
| 計算 | python_exec | 外部ネットワークにつながらない環境でPythonを動かし、集計や照合を正確に行う |
| ファイルの保管 | PutObject、ListObjects、HeadObject、CopyObject、MoveObject、DeleteObject | 利用者ごとの専用ストレージで、ファイルを保存、一覧、コピー、移動、削除する |
| 社内規程の検索 | vector_store_search | 事前に用意した知識ベースから、規程やマニュアルの該当箇所を探す |
| 作業の分担 | spawn_sub_agent | 子のエージェントに作業を任せ、並行して処理する |
システム要件
ATLSは自社の環境で動かすため、GPUサーバーとDockerの実行環境を自社で用意します。最小構成は、NVIDIA H100を8基搭載したサーバーです。
必須の要件
| 項目 | 要件 |
|---|---|
| CPUアーキテクチャ | x86_64 |
| コンテナの実行環境 | DockerとDocker Compose。ホストでDockerデーモンが動いていること（Pythonの実行環境がDockerソケットを使って、隔離したコンテナを起動するため） |
| GPU関連のソフトウェア | NVIDIAドライバ（バージョン580以上）、NVIDIA Container Toolkit、NVIDIA Fabric Manager（バージョン580以上） |
| ライセンス | Lazarusのライセンスファイル |
| 運用の技能 | Dockerの扱いに慣れていること |
最小要件
| 項目 | 要件 |
|---|---|
| ディスク容量 | 使い方によって変わる。最小250GB、推奨は1〜2TB |
| GPU | ATLS、RikAI、VKGを合わせて、NVIDIA H100を8基（HBM3メモリは合計640GB）。ATLSとRikAIを一緒に動かしても、この8基より多いGPUは不要。VKGは、ATLSとRikAIのシステムのCPUで動作する。 |
活用できる業務
ATLSは特定の業界に限らず、書類を読み、複数の情報を突き合わせて判断の材料を作るような少量多品種な業務や、ベテラン社員による属人性の高い業務で高い効果を発揮します。
| 分野 | 業務の例 | ATLSが行うこと |
|---|---|---|
| 法務 | 契約書の確認 | 契約日や当事者の抽出、条項の比較、社内基準との照合 |
| 金融・経理 | 請求書や財務報告書の確認 | 明細の抽出、数値の集計と照合、報告書の要約 |
| 医療関連 | 診療記録の整理 | 長い記録からの病名、治療期間、処置の抽出 |
| 製造・サポート | 製品に関する問い合わせへの回答 | 製品マニュアルの検索と、仕様に基づく回答の作成 |
| 保険 | 保険金請求の審査 | 書類の読み取り、契約・約款との照合、判断案の作成（本書で詳しく説明） |
以降の章では、この条件がすべてそろう例として保険金請求の審査を取り上げ、業務がどう変わるか、投資対効果、リスク、導入の進め方を説明します。保険金審査では、診断書、見積書、事故写真などの多様な書類を、契約、約款、社内規程、外部の事実と突き合わせる必要があります。
保険金審査の課題
保険金の審査では、判断を下す前に、多数の書類を確かめ、契約内容、約款、社内規程と突き合わせる作業が必要です。この突き合わせは担当者の経験に頼る部分が大きく、件数が増えるほど時間と判断のばらつきが問題になります。
審査担当者が継続的に抱えている課題を、作業ごとに整理しました。
| 作業 | 中身 | 起きやすい問題 |
|---|---|---|
| 書類を読む | 診断書、見積書、事故写真、通話録音など、形式の違う書類を読む | 読み取りに手間がかかり、見落としが起きる |
| 社内の情報を調べる | 契約内容、保険料の払込状況、過去の請求を、別々のシステムで照会する | 照会のたびに画面を行き来する |
| 約款と規程を当てはめる | 事故日に適用される約款のバージョンを確かめ、支払事由と免責事由を判定する | 約款のバージョンの取り違えや、担当者ごとの解釈の違いが出る |
| 外部の事実を確かめる | 気象記録、事故証明、医療機関の実在などを調べる | 確認の深さが担当者によって変わる |
| 判断を説明する | 否認や一部支払の理由を、書類と条項を示して説明する | 根拠を後から集め直す手間がかかる |
これらの作業は、手順が毎回同じではありません。請求の種類や書類の中身によって、調べる先も順序も変わります。そのため、手順を決めて繰り返す従来の自動化では任せにくい領域でした。AIエージェントは、書類の中身を読んで次に何を調べるかを自律的で決めるので、この領域に最適です。
ユースケース: 保険金審査はどう変わるか
導入後は、書類の読み取りから判断結果の下書き作成までをATLSが行い、担当者は判断結果とその根拠を確認する役割に変わります。決裁者が承認して支払いを実行する流れは、これまでと同じです。
導入前は、担当者が書類を読み、社内システムを個別に照会し、約款と規程を調べ、計算し、報告書を書いていました。導入後は、この材料集めと突き合わせをATLSが行い、担当者の手元には判断結果の下書きとその根拠が届きます。
構成例では、審査を次のステップに分け、各ステップでATLSに作業を依頼します。各ステップでは、そのステップに必要な社内外のデータのみを使用させます。
- 契約と約款の確認（事故日に契約が有効か、どのバージョンの約款が適用されるか）
- 書類がそろっているかの確認
- 全書類の読み取り
- 書類同士、外部の事実との突き合わせ
- 不正の兆候と反社会的勢力の確認
- 支払事由と免責事由の判定
- 支払額の算定
- 判断案、報告書、通知文の下書きの作成
書類が足りないときは、ATLSが顧客への依頼メールの文章を下書きし、担当者がそれを確認して送信します。不正の疑いがあれば、調査会社への依頼を担当者が承認します。どちらも、応答が届いたらATLSが自律的に作業を再開する仕組みです。各ステップの作業と、繋ぎこむデータの連携先は、をご確認ください。
次に示すスイムレーンは、左から右へ審査が進む様子と、各ジョブで人間が対応する場面、つなぐツールのデータソース（連携先）を示しています。ツール61個のうち、25個は既存の社内システムへの窓口で、最初の検証はここから始められます。
ジョブの分け方
各ジョブには、そのステップで使用するツールのみを渡します。1つのジョブに渡すツールは最大14個で、ATLSがツールを選び間違えにくくなります。
| ジョブ | 作業 | 主なクライアント側ツール | 個数 | 主な組み込みツール |
|---|---|---|---|---|
| 1 契約・約款の確認 | 事故日に契約が有効か、適用される約款のバージョン | get_claim、get_policy、get_applicable_terms ほか | 9 | PutObject |
| 2 書類の網羅性 | 必要書類と提出状況、過去・他社への請求 | get_required_documents、query_industry_claim_exchange ほか | 4 | ListObjects |
| 3 書類の読み取り | 全書類の OCR、構造化、文字起こし | extract_medical_record、transcribe_with_domain_dict | 2 | ocr_document、視覚系、spawn_sub_agent |
| 4 事実の突き合わせ | 書類間の矛盾、外部の事実との照合 | get_weather_history、lookup_medical_codes、analyze_dashcam ほか | 14 | python_exec |
| 5 不正・コンプライアンス | 不正スコア、反社・制裁の照合、書類と画像の真正性 | get_fraud_score、check_antisocial_forces、image_forensics ほか | 9 | read_text_file |
| 6 補償の判定 | 支払事由・免責事由の判定と、約款と規程による裏付け | check_coverage_rules、get_terms_clause、search_case_law ほか | 9 | vector_store_search |
| 7 支払額の算定 | 損害額の推定と、支払額の計算 | calculate_payout、calc_fault_ratio、estimate_vehicle_damage ほか | 7 | python_exec |
| 8 判断案の作成 | 報告書と判断案の作成、承認待ちでの登録 | propose_claim_decision、draft_decision_letter、check_approval_authority ほか | 7 | python_exec |
各ジョブは結果をストレージに保存し、次のジョブがそれを読み込みます。
ツールの連携先
61個のクライアント側ツールは、接続先のデータソースによって準備の進め方が異なります。既存の社内システムへの窓口が25個あり、最初に手を付けやすい部分です。
| 連携先 | ツール数 | 主な接続先 | 進め方 |
|---|---|---|---|
| 社内既存システム | 25 | 契約管理、保険金支払、収納、CRM、約款の文書管理、承認ワークフロー | APIの口と、データの絞り込み・マスクを作成する。最初に手を付けやすい |
| 社内新規開発 | 11 | ルールエンジン（支払事由、過失割合、時価）、判断事例DB、不正検知モデル | 約款や査定基準をルールやデータに置き換える。査定の専門家と進める |
| 業界団体 | 1 | 生命保険協会の支払査定時照会制度、損保協会の情報交換制度 | 利用条件と自動照会の可否を確認する |
| 公的機関 | 12 | 気象庁、自動車安全運転センター、厚生労働省、国税庁の法人番号Web-API、金融庁の監督指針 | APIがないものは社内に取り込んでAPIを用意する |
| 商用サービス | 12 | AI損害査定、画像・書類鑑定、判例DB、修理見積システム、音声認識 | 契約が必要。個人情報を渡すので、委託先管理と同意の範囲を確認する |
団体、公的機関、製品の名前は連携先の例であり、連携の可否および利用条件については確認が必要です。
プロンプト設計
ATLSへの指示（プロンプト）には、各ツールの使い方ではなく、審査の手順、守るべき制約、出力の形を書きます。ツールの使い方は、各ツールの説明文に記載されています。
| 書くこと | 例 | ねらい |
|---|---|---|
| 役割と責任の範囲 | 「最終判断を確定させるのは人間の決裁権限者であり、あなたではない」 | 書き込み系のツールを「提案」として扱わせる |
| 手順の順番 | 「先に適用される約款のバージョンを確定し、以降はそのバージョンで参照する」 | 約款の取り違えを防ぐ |
| 計算の禁止 | 「金額の計算を自分で行ってはならない。必ずツールの結果を使う」 | 支払額の揺れを防ぐ |
| 判断保留の区分 | 「書類の不足や重大な矛盾があれば、判断保留とする」 | 情報が足りないときに無理に選ばせない |
| 事実と推測の区別 | 「不正の疑いは事実と推測を分け、推測だけで否認の根拠にしない」 | 不当な否認を防ぐ |
| 根拠の形式 | 「書類名とページ、約款のバージョンと条項番号、規程名と項番」 | 監査や顧客への説明にそのまま使える |
| 出力 | report.md（人が読む）、decision.json（システムが取り込む）、最終回答（結論と未解決事項のみ） | 用途ごとに形を分ける |
判断の最終案には、「全額支払」「一部支払」「支払不可」「判断保留」のいずれかを回答し、支払額、理由と根拠、未解決事項、必要な決裁者、確信度なども含むことができます。
人とATLSの役割分担（保険金審査の例）
AIには材料集めと最終案の作成を任せ、支払いの確定と顧客への通知は人間が行います。この線引きは運用の約束ではなく、仕組みとして組み込みます。支払いの実行や否認の確定を行うツールは、そもそもATLSに渡しません。
| ステップ | ATLSが行うこと | 人間が行うこと |
|---|---|---|
| 書類の確認 | 書類を読み、不足を見つけ、依頼文を下書きする | 依頼文を確かめて顧客に送る |
| 事実の確認 | 書類どうしの食い違いと、外部の事実との食い違いを探す | ATLSからの質問に答える |
| 不正の兆候 | 不正スコア、反社会的勢力との照合、画像や書類の真偽を確かめる | 調査会社への依頼を承認する |
| 補償の判定 | 社内のルールで判定し、約款の条文と社内規程で裏付ける | 判断案の中で確かめる |
| 支払額 | 社内の計算システムに計算させる | 判断案の中で確かめる |
| 最終判断 | 判断案、根拠、通知文の下書きを作り、承認待ちとして登録する | 承認または差し戻しを行い、支払いと通知を実行する |
判断の質を守るために、ATLSには4つのルールを守らせます。
- 金額を自分で計算しない。支払額、免責の適用、過失割合は、社内のルールと計算システムによって決定される。
- 不正の疑いは事実と推測を分けて記録し、推測だけを否認の理由にしない。
- 書類の不足や重大な食い違いが残るときは、「判断保留」として人間に戻す。
- すべての判断に、書類のページや約款の条項番号といった根拠を付ける。
この仕組みにより、担当者はAIの判断案の根拠をたどって確認できます。
投資対効果の考え方
保険金審査の場合、効果は「作業時間」「判断のそろい方」「説明のしやすさ」「見落としの防止」の4つで現れると考えています。効果の源泉と検証で測る指標の例は次のとおりです。これは本書での整理です。
| 効果の源泉 | なぜ効くか | 測る指標の例 |
|---|---|---|
| 作業時間 | 書類の読み取りと社内外への照会をATLSが行う | 1件あたりの審査にかかる日数と、担当者の作業時間 |
| 判断のそろい方 | 同じ手順と同じルールで判断案を作る | 似た案件での結論のばらつき、決裁での差し戻しの割合 |
| 説明のしやすさ | 根拠が書類のページと約款の条項で残る | 苦情や監査で判断理由を示すまでの時間 |
| 見落としの防止 | 必要書類、外部の事実、二重請求を毎回同じように確かめる | 支払いの後で見つかった誤りの件数 |
コストには、ATLSの利用料のほかに、社内の仕組みを整える費用が加わります。構成例で用意した61のツールのうち、25は既存の社内システムへの窓口、11は新しく作るルールやデータベースです。
| コストの項目 | 中身 |
|---|---|
| ATLSの利用と運用 | 自社のクラウド環境での稼働と管理。 |
| 社内システムとの接続 | 契約管理、支払いシステムなどに、ATLSから照会できる窓口を作る |
| ルールの整備 | 約款や査定基準を、計算可能なルールに置き換える。査定の専門家の工数がかかる |
| 外部サービス | 損害の推定、画像の鑑定、判例検索などの契約料 |
| 運用体制 | 承認の流れ、稼働の監視、ルールと規程の更新 |
社内システムへの窓口とルールは、一度作れば他の保険種目や他の業務でも使えます。最初の検証は、既存システムへの窓口を数個設けるだけで始められます。
リスクと対策
最も大きなリスクは、AIによるエラーがそのまま最終判断に反映されることです。ここでは保険金審査を例に整理します。本書の構成では、最終判断を人に残し、金額を社内の計算システムに任せることで、このリスクを抑えます。
| リスク | 起きること | 対策 |
|---|---|---|
| 不当な支払拒否と支払漏れ | AIの誤りや推測が判断に影響する | 最終判断は人間が行う。事実と推測を分け、情報が不足していれば判断を保留とする。金額は計算システムが出す |
| 個人情報の扱い | 病歴などの要配慮個人情報をAIが扱う | 自社のクラウド環境内で動かす。渡す項目を窓口の側で絞り、口座番号は渡さない。外部サービスには委託先の管理と同意の範囲を確かめる |
| 説明責任 | 判断の理由を顧客や監査に示せない | 根拠を書類のページと約款の条項で残す。ATLSの作業は全手順が記録に残る |
| 監督上の要請 | 保険金支払いに関する監督指針や業界ガイドラインとの整合 | 検証の段階から法務とコンプライアンスの部門を加える |
| 無断アクセス | 管理画面から他の利用者の情報が見える。開発環境では認証のない管理画面を確認している | 本番では、認証の仕組みとネットワークの制限で管理用の機能を守る |
| 製品の変化 | バージョンによって使える機能の構成が違う | 契約の前に、自社の環境で提供される機能を提供元と確かめる |
| 過度な期待 | 音声や映像の解析など、まだ確かめていない機能を前提に計画する | 検証で、任せられる範囲を実際の請求で確かめる |
導入ロードマップ
導入は3段階で進め、各段階の終わりに次の段階に進むかどうかを判断します。最初の段階は、既存システムへの窓口を数個作り、匿名化した1件の案件で試すのみとなります。
各段階の期間は、対象とする業務と、つなぐ社内システムの数によって変わるため、本書では示しません。判断の基準は例です。実際の基準は、第1段階を始める前に経営部門と審査部門で決めておきます。
経営判断のためのチェックリスト
検証に着手する前に、次の7点を決めておくと、検証の結果を導入の判断にそのまま活かせます。
- 対象とする業務と書類の種類を決めた
- 検証に使う匿名化済みの書類を用意できる
- ATLSからの照会を許可する社内システムと項目を決めた
- 最終判断の権限と承認の流れを変えずに組み込めることを確かめた
- 個人情報の扱いについて、法務とコンプライアンスの部門の確認を取った
- 効果を測る指標と、その現状の値を決めた
- 提供元に、自社の環境で使える機能、費用、支援の体制を確かめた
前提と出典
- ATLS API リファレンス v1.2.0（2026年10月23日）
- ATLS データシート（技術者向けの詳細）
- 保険金審査ジョブ設計図（各ステップの作業、ツール、データの連携先）