APIとブラウザ自動操作を比較する——権限・対象照合・保存結果で接続を選ぶ

既存の画面へAIをつなぐ、二つの入口

担当者が毎月の申請内容を既存システムへ転記している場面を考えます。AIで項目を整理できても、最後に人が全部入力し直すなら、連携の方法を決める必要があります。接続先にAPIがあればデータを直接渡せる場合があり、APIがない機能では画面の操作が候補になります。どちらが新しいか、簡単そうかで選ぶより、必要な操作ができるか、権限を分けられるか、結果を取得できるかを比べます。接続する方法は、業務の完成条件から選ぶことが大切です。

申請内容から候補を作り、担当者の確認後に登録する場面を考えます。APIで扱える項目と、ブラウザでしか確認できない警告があるなら、読み取り、登録、照合を分けて接続方法を選びます。申請文を整理するAIと、指定された項目を送るプログラムにも役割の違いがあります。どの入力から何を取得し、確認後にどの結果を残すかを先に定める設計です。一つの接続方式に全工程を合わせるより、各段階の権限と失敗時の対応をそろえることが重要です。

APIがあるなら必ず全てを任せられるわけではなく、画面を使うなら必ず人と同じ確認ができるわけでもありません。接続先が提供する機能と実際の操作を調べ、読取り、候補作成、更新、結果照合をそれぞれ検討します。

ブラウザ自動操作を含む、ヤクモ提供の医療系業務代行の実装では、Python、pydantic、pytestが使われています。Pythonは処理を組み立て、pydanticは構造や型の条件を扱い、pytestは検査を実行する道具です。申請登録への設計では、まず必要項目と型を定め、保存先の応答と照合結果を検査できる形にします。接続先のAPI仕様や操作ライブラリは別に調べる必要があり、技術構成だけから保存の挙動は決まりません。登録が成立したと判断できる条件を小さな試験で確かめます。

APIは、項目と結果を明確に扱いやすい

APIは、定められた項目を渡し、応答を受け取る接続です。申請の対象、金額、日付を送る方法が公式に提供されていれば、画面の配置に依存せず扱える場合があります。必須項目や型を事前に検査し、応答に含まれる受付結果を保存する設計ができます。ただし返ってきた「受付」の意味を確認する必要があります。更新が完成したのか、処理を受け付けただけなのかで、次に状態を取得するかが変わります。応答が正常だったことを業務完了へ直結させないようにします。

APIの存在だけで選ばず、今回の操作が公開されているか、必要な権限を限定できるか、重複を防ぐ識別を扱うか、結果を再取得できるかを調べます。読取りのAPIはあっても登録は画面だけ、という場合があります。利用回数や入力サイズの制約も、対象業務の規模へ照らします。仕様書にある機能と、今回の環境で使える機能が一致するかを小さな試験で確かめます。画面を飛ばせることを利点にする前に、画面にしかない業務の確認をどこで行うかも決めます。

APIの認証情報は、AIの自由な文章や公開の図へ含めません。接続担当が管理し、必要な操作だけを呼べる入口を渡す方法があります。AIの判断と、実際に送信するデータの検査を分けることが接続の境界になります。

APIを試す際は、登録を伴わない参照から始める方法があります。実際に取得する項目、対象の選び方、応答の不足を確かめ、後で更新に必要な情報と比較します。接続が動いたという一件の結果を全操作へ広げず、参照と更新の試験をそれぞれ用意します。

画面操作は、実際の業務画面を使う接続

APIで扱えない機能が、既存の画面にある場合があります。画面操作では、対象を探し、欄へ入力し、保存の結果を確認します。人の業務に近い順序で進められますが、画面の配置、表示の遅延、確認用の小窓、ログインの状態などに影響されます。ボタンを押した記録だけでは、保存が終わったかを判断できません。結果の表示や保存先の値を確認する工程を別に置きます。画面を使うことを、人と同じ理解がある証明にはしないようにします。

画面変更へどう気付くかも重要です。欄の名前や入力順が変わった場合、従来の操作を続けると別項目へ値を入れる可能性があります。対象の画面、欄の説明、登録前の内容を確かめ、想定と違えば止める条件を設けます。操作の一部が成功しても、後の画面で確認が必要なら完了としません。人が使う画面を利用する接続は、既存の業務を大きく変えずに試せる場合がありますが、その利点と保守の負担を合わせて判断します。表示の成功を内容の正しさへ広げないことが必要です。

ログインや追加の確認が必要な場面では、人へ返す経路を設計します。確認を回避するために権限や保護を広げることは、連携の修復とは別です。許された操作で再開できる条件と、未対応の状態を利用者へ示します。

画面で人が普段行う確認が何かも聞き取ります。入力欄の横の注意文、保存前の対象確認、登録後に番号を控える作業などです。自動操作の順序だけを再現しても、その判断が抜ける場合があります。画面を使う理由を、クリックの代替より必要な情報の取得へ結び付けます。

比較表には、業務の結果を並べる

二つの方法を比べるなら、読取り、更新、対象の選び方、結果の照会、重複時の扱い、権限、保守を項目にします。例えばAPIで正式な受付結果を取得できるなら、その点は強みです。画面にしか表示されない警告を確認する必要があるなら、画面操作や人の確認が必要かもしれません。どちらか一方へ全てを寄せる必要はありません。APIで候補を作り、画面で人が最終確認する組合せも考えられます。方法の名前より、必要な条件を満たす経路を選びます。

申請番号で一意に対象を選べるAPIと、氏名で検索する画面では、対象照合の負担が違います。一方でAPIの対象番号が入力にないなら、先に番号を取得する工程が必要です。「APIなら確実」と決めつけるより、入力から保存結果までを追います。画面で対象の名前が見えても、同名の別人かもしれません。どちらも対象を特定する条件を持ち、登録前に一致を確認します。接続の評価を速度だけにせず、担当者が誤りを見つけ、原因を調べられるかを含めます。

比較の段階では、更新せずに読取りや候補表示を試す方法があります。正常例と、対象が複数の例を使い、どちらの経路なら確認材料がそろうかを見ます。実データの操作を始める前に、取り消しやすい範囲で接続の不確実性を減らせます。

AIの判断を、そのまま操作にしない

申請の文章からAIが「交通費」と分類したとしても、その結論をそのまま登録要求に変えるとは限りません。必須項目、対象、金額の単位、参照した規則を通常のプログラムで検査し、必要な判断を人へ渡します。APIなら送信する項目、画面なら入力する欄を固定して、AIが不要な操作を追加しない入口を設計します。分類の候補を作る役割と、許された更新を実行する役割を分けます。自由な文章の回答を読むだけで登録の許可が成立する構成は避けます。

取り消せない操作を人が行うなら、その直前に対象、変更内容、根拠、未確認をまとめます。医療系業務代行のヤクモ提供の実装にも、取り消せない操作を人へ残す分担があります。ただし工程数の概数だけから、全ての接続に同じ分担を適用できるとは言えません。申請登録では、宛先を誤ったときに戻せるか、通知が同時に送られるかなど、操作の影響を確認して担当を定めます。判断、実行、照合がどこにあるかを示すことで、確認者も今回行う操作を理解しやすくなります。

操作前の確認が終わった後に、元資料が変わる場合もあります。確認した対象と値を結び付け、更新された内容へ古い承認を使わないようにします。接続方法が違っても、確認済みの情報を後段へ渡す条件は必要です。

結果不明のときは、別経路へすぐ切り替えない

APIの更新後に通信が切れた場合、保存が成立している可能性があります。画面の保存後に表示が止まった場合も同様です。「APIが失敗したので画面で入力する」と直ちに切り替えると、同じ申請が二重に登録されることがあります。先に保存先を照会し、実施済みかを確かめます。代替の経路を用意するなら、元の操作結果が不明なときの条件も含めます。単なる通信失敗と、更新の結果不明を別の状態として残すことが重要です。

接続先が同じ受付を識別できるなら、同じ依頼の再送に以前の結果を返す仕組みを利用できます。しかし識別を送るだけで成立するわけではありません。保存先が値を扱うこと、結果を取得できることを試します。画面操作でも申請番号や保存結果を照合できるかを確認します。結果を探せない場合は、人へ返す条件を決めます。処理をやり直す回数だけでは、二重登録を防ぐ設計になりません。どこまで実施したかを説明できる記録が、障害時の判断を支えます。

読み取るだけの失敗なら、上限付き再試行が候補になります。情報不足は入力の追加へ返します。接続方法ごとに全て同じエラー扱いをせず、操作の影響と分かっている事実から次の行動を選びます。

検査は、変更と遅延を含めて行う

接続の検査には、正常な対象、対象がない例、複数の候補、権限不足、途中の遅延、保存後の応答喪失を含めます。APIでは必要な項目が不足した応答や、受付後に処理が続く場合を確かめます。画面では入力欄が変わった例、確認の小窓が出る例、保存結果が遅れて表示される例を試します。期待結果を先に決め、誤った対象へ更新しないこと、結果を不明のまま完了としないことを見ます。操作できた一例だけで連携全体を受け入れないようにします。

連携の検証では、コードがあること、試験したこと、完成物を確認したこと、継続運用を分けます。申請候補を画面へ表示する試験だけでは、保存後の照会や翌日の再開は未確認です。試作の成功を全機能へ広げず、確認した対象と経路を記録します。接続先のAPIや画面が更新されたら、影響する経路を再検査する必要があります。項目名の変更なら入力先の確認へ、受付結果の変更なら保存成立の判定へ戻します。こうした保守の負担も方法を選ぶ際の比較へ含めます。

確認画面の表示が変わった場合、内部の保存だけでなく利用者への説明も点検します。「受付済み」と「登録完了」が同じ表示になっていれば、担当者は次の確認を省いてしまうかもしれません。接続の結果を業務の言葉へ正しく翻訳できることも受入条件です。

選ぶ基準を、将来の保守へ残す

最初の選択では、なぜAPIを使うか、なぜ画面操作が必要か、組み合わせる箇所はどこかを記します。公式の登録機能を使える、必要な警告は画面にある、結果の照会はAPIで行える、といった理由です。後から新しいAPIが追加されたとき、画面の変更が増えたときに見直す条件も決めます。方法を一度選んだことを固定した正解にせず、業務の完成条件と保守の負担へ照らして判断します。接続の仕組みより、何を確認して運用できるかが選択の中心です。

残る制約は、接続先の権限や結果取得の機能です。必要な操作を安全に限定できないなら、対象を狭める、参照だけにする、人の操作へ戻す選択があります。使える入口があることと、任せてよい条件がそろうことは別です。小さな読み取り試験から始め、候補作成、確認後の更新、事後照合へ段階的に進めます。APIと画面操作を比べる価値は、一般的な優劣を決めることより、自分の業務で説明できる入出力と失敗時の経路を選ぶことにあります。

工程図では、APIやブラウザという技術名を必要に応じて説明し、どの仕事に使うかを示します。内部の操作名を並べるだけでは、利用者は結果を理解できません。担当者が確認する入力、操作、結果を一続きに見せることで、選んだ理由を共有できます。

接続の切替えを計画する場合は、移行中に同じ対象を二つの経路で更新しない条件を定めます。旧経路で受付済みの処理を確認し、新経路へ渡す対象を分けます。保守のための変更でも、現在の保存結果と進行中の仕事を確認してから切り替えることが必要です。