Pl@ntNetとPlant.idを比較｜料金・機能・API以外の使いやすさと併用実装を解説【2026年9月】

AI開発ログ

植物判定AIをアプリへ組み込もうとすると、候補に上がりやすいのがPl@ntNetとPlant.idです。どちらも植物写真から候補種を返せますが、実際には料金体系、APIを使わない場合の入口、観察記録の考え方、バッチ処理、植物情報の持ち方がかなり異なります。

2026年9月25日時点の公式情報を確認すると、Pl@ntNetは無料のモバイルアプリとWeb版、市民科学の観察機能、モバイル限定のオフライン識別を持ち、APIも1日500件までのFree枠があります。一方のPlant.idは、Webデモ、ブラウザでのBatch Identification、開発者向けAPIと詳細な植物データ、plant.healthを組み合わせやすく、APIは100無料クレジットから検証できます。

この2つは「どちらか1つを選ばなければならない」サービスでもありません。アプリケーションでは、Pl@ntNetを一次判定にし、曖昧な画像だけPlant.idへ回す方法や、両方の上位候補を突き合わせて「一致」「要確認」を判定する方法が取れます。さらに、種の候補をPl@ntNetで絞り、Plant.idの詳細情報やplant.healthへ処理をつなぐ構成も考えられます。

なお、Pl@ntNet単体の使い方や撮影方法はPl@ntNetの解説記事、Plant.idのAPI料金や基本実装はPlant.idの解説記事で詳しく整理しています。ここでは重複を避け、比較と併用設計を中心に見ていきます。

  1. 先に比較結果を整理：日常の観察はPl@ntNet、業務データ処理はPlant.idに特徴がある
  2. 料金を比較：無料枠の考え方と有料化のタイミングが違う
    1. Pl@ntNetの料金
    2. Plant.idの料金
  3. API以外の使いやすさを比較：現地で使うか、デスクで大量処理するか
    1. Pl@ntNetはスマートフォンでの現地観察に向く設計
    2. Plant.idはWebデモとバッチ処理が分かりやすい
    3. 「アプリを入れて使う」手軽さと「業務データへ出す」手軽さは別
  4. 機能比較：同じ「植物識別」でも返したい情報が違う
    1. Pl@ntNet：地域floraと観察データを扱いやすい
    2. Plant.id：詳細情報と周辺サービスへつなぎやすい
    3. 病害虫機能は「候補を出す入口」として使う
  5. Pl@ntNetとPlant.idを組み合わせる3つの実装パターン
    1. パターン1：Pl@ntNetを一次判定、曖昧なときだけPlant.idを呼ぶ
    2. パターン2：両方を呼び、学名の一致を「追加の根拠」にする
    3. パターン3：種判定と詳細・健康情報を役割分担する
  6. 実装例：Pythonで2つのAPIを呼び、候補の一致・不一致を判定する
  7. 本番アプリでは候補の突合より前に「入力」と「状態」を設計する
  8. スコアの扱い：0.9と0.9を同じ意味だと思わない
  9. APIキーと画像データの扱い：スマホから各社APIを直接呼ばない
  10. コストを抑えるなら「全件二重呼び出し」ではなく再判定ルールを作る
  11. APIを使わない段階でも2サービスを組み合わせて評価できる
  12. どちらを使うか決めるときの実務チェックポイント
  13. 導入前の検証手順：100枚程度の自前データで判定ルールを決める
  14. メリットとデメリット：2サービス併用は精度だけでなく運用コストも見る
    1. 併用するメリット
    2. 併用するデメリット
  15. まとめ：選択ではなく役割分担まで考えると使い分けやすい
  16. 参考情報

先に比較結果を整理：日常の観察はPl@ntNet、業務データ処理はPlant.idに特徴がある

両者を比較すると、単純に「識別できる植物数が多い方」を選ぶより、どこで使うかを見る方が分かりやすくなります。公式が公表するクラス数や対象種数は、分類体系や集計方法が同じとは限らないため、数字だけで精度を比較することはできません。

比較項目 Pl@ntNet Plant.id
一般ユーザーの入口 無料のモバイルアプリ、Web Webデモ
オフライン利用 モバイルアプリで対応。事前にモデルをダウンロード 今回確認した公式の主要導線はWebデモ・Batch・APIが中心
観察記録 観察保存、共有、コミュニティ、市民科学との連携が強い 識別結果の取得と業務・アプリ組み込みが中心
一括処理 通常の識別は1個体を複数写真で判定する設計 Batch Identifierで最大1,000画像をブラウザから処理可能
API無料枠 Freeで1日500 identification 登録後100クレジットのトライアル
有料APIの入口 Proは€1,000/年から。200,000 identificationを含む 1,000クレジット€50から。購入量に応じて単価低下
植物の詳細データ 学名、一般名、分類、GBIF/POWO IDなどを返せる 一般名、同義語、分類、説明、ケア情報などを詳細項目として取得可能
地域性の扱い 地域・テーマ別のflora/projectを選べる 位置情報や撮影条件を入力へ加えられる
病害・健康状態 2026年から病気・害虫の画像識別をWeb/モバイルで提供 plant.healthで健康状態候補を取得できる
開発者向けの特徴 低ボリュームの検証を始めやすく、地域floraとGBIF IDが扱いやすい 課金がクレジット制で、詳細データ・Batch・SDKを業務フローへ組み込みやすい

個人が畑や散歩先で植物を撮り、その場で候補を見て記録を残したい場合は、Pl@ntNetのアプリ中心の設計が自然です。一方、大量画像をCSVやJSONにまとめたい、既存システムの植物マスタとつなぎたい、識別結果に詳細情報や健康状態を付加したい場合は、Plant.idの業務向け機能を比較対象に入れる意味が大きくなります。

料金を比較：無料枠の考え方と有料化のタイミングが違う

料金は、Pl@ntNetが「日次の無料上限＋年間契約」、Plant.idが「無料クレジット＋前払いクレジット」という違いがあります。2026年9月25日時点の公式価格を整理すると次の通りです。

Pl@ntNetの料金

利用方法 料金 主な条件
モバイルアプリ・Web 無料 植物識別、観察など。モバイルではオフラインモードも利用可能
API Free €0 1日500 identification、50,000+ identifiable species、50+ languages
API Non-profit €0 教育・科学用途。500件/日超やバースト利用は相談。表示条件あり
API Pro €1,000/年（税別）から 年間200,000 identificationを含む。超過分は利用量に応じて従量課金

Pl@ntNetのFree APIは、PoCや小規模な内部ツールで試しやすい枠です。ただし無料枠を超える商用利用では有料契約が必要になります。Proは1年契約で、支払い方法や契約条件もPlant.idの前払いクレジットとは異なります。

Plant.idの料金

利用方法 料金 主な条件
Webデモ 月10件まで無料 写真をアップロードしてブラウザで識別
Webデモの月額 €5/月 月50 identification
Webデモの年額 €35/年 年600 identification
APIトライアル 100クレジット無料 登録後に付与
Business Tier A 1,000クレジット €50から 1 identification = 1クレジット
Business 購入量に応じて€0.05〜€0.01/リクエスト クレジットの有効期限条件あり

Plant.idは有料化するときの最小購入単位が比較的小さく、1,000クレジットから始められます。一方、Pl@ntNetはFreeの1日500件が大きく、そこを超えて本格利用する場合はProの年間契約という段差があります。利用数が「毎日少量」なのか「キャンペーンや調査日に集中」するのかでも費用感が変わるため、月間件数だけでなくピーク時の呼び出し数も見積もる必要があります。

Plant.idではplant.healthなど追加機能で別クレジットを消費する場合があります。Pl@ntNetでもAPIの種類ごとにクォータが分かれるため、「植物識別1回の価格」だけで全機能のコストを見積もらない方が安全です。

API以外の使いやすさを比較：現地で使うか、デスクで大量処理するか

Pl@ntNetはスマートフォンでの現地観察に向く設計

Pl@ntNetはAndroid・iOSのモバイルアプリを無料で提供しており、その場で撮影した写真やギャラリー内の写真を使って識別できます。葉、花、果実など複数の部位を撮影し、候補の画像ギャラリーや種情報と見比べられるため、「AIの1位をそのまま答えにする」のではなく、人が候補を確認する流れを作りやすいのが特徴です。

さらに、観察を保存・共有し、他ユーザーによるレビューや市民科学のデータ蓄積につなげられます。山間部や圏外の畑では、事前にモデルをダウンロードしてモバイル限定のオフライン識別を使えます。公式ドキュメントでは、通信できる場所に戻ったら、更新頻度と性能の面からオンラインモデルで再識別することが推奨されています。

Plant.idはWebデモとバッチ処理が分かりやすい

Plant.idは、ブラウザから写真をアップロードできるWebデモが入口です。月10件までは無料で、少量ならAPIキーを意識せず試せます。さらに複数写真をまとめて処理したい場合は、Plant Batch Identifierが用意されています。

Batch Identifierでは、Plant.idのAPIキーを入力し、最大1,000画像をアップロードして、結果をExcel、CSV、JSONで受け取れます。コードを書かなくても利用できますが、内部ではAPIクレジットを使うため、無料の一括処理機能という意味ではありません。研究用写真、圃場写真、過去の植物画像フォルダを一度に整理したい場合には、APIを自作する前の中間手段になります。

「アプリを入れて使う」手軽さと「業務データへ出す」手軽さは別

Pl@ntNetは現地で撮る・候補を見る・観察を残す流れが短く、Plant.idはブラウザで試す・大量画像を表形式へ出す・APIへ移行する流れが短い、という違いがあります。どちらが使いやすいかは、スマートフォン上の操作回数だけで決められません。

家庭菜園の現地観察ならPl@ntNetのアプリ、社内に数百枚の写真が既にあるならPlant.idのBatch Identifier、といったように、写真が生まれる場所と結果を使う場所を先に決めると選びやすくなります。

機能比較：同じ「植物識別」でも返したい情報が違う

両方とも写真から候補種を返しますが、その後の処理で差が出ます。

Pl@ntNet：地域floraと観察データを扱いやすい

Pl@ntNet APIでは、地域やテーマごとのproject（flora）を指定して候補集合を絞れます。結果には候補スコア、学名、属・科、一般名に加え、利用可能な場合はGBIF IDやPOWO IDも含まれます。外部の分類データベースと接続したい場合、GBIF IDのような識別子を使えるのは実装上便利です。

APIは1回に最大5枚のJPEG/PNGを送れ、同じ植物個体の複数部位をまとめて識別できます。候補はスコア順で返り、bestMatchは最上位候補へのショートカットです。bestMatchだけを保存せず、resultsの上位候補とスコアも保持しておく方が、後から再評価しやすくなります。

Plant.id：詳細情報と周辺サービスへつなぎやすい

Plant.idは35,000以上のクラスを案内しており、識別結果に一般名、同義語、分類、説明、代表画像、ケアに関する情報などを付加できます。APIでは必要なdetailsだけ指定できるため、レスポンスを用途に合わせて絞れます。

同じKindwiseのplant.healthを使えば、病気、害虫、生育不良などの候補も取得できます。識別と健康評価は別の目的なので、アプリでは「植物名」と「健康状態」を同じ確定ラベルとして扱わず、別フィールドで管理するのが安全です。

病害虫機能は「候補を出す入口」として使う

Pl@ntNetも2026年から病気・害虫の画像識別をWebとモバイルで提供しています。ただし、Pl@ntNetの公式ドキュメントは専門診断ではないこと、治療法や農薬の使い方を提供する機能ではないことを明示しています。Plant.idのplant.healthも画像からの推定であり、症状が似るケースがあります。

農薬選定、食用可否、有毒性など安全性に関わる判断を、どちらか一方の画像AIだけで確定しないでください。農薬を使う場合は製品ラベル、登録内容、自治体や公的機関の最新情報を確認する必要があります。

Pl@ntNetとPlant.idを組み合わせる3つの実装パターン

2サービスを併用する目的は「精度を魔法のように上げる」ことではありません。異なるモデルの候補を比較し、曖昧なケースを検出しやすくすること、片方の障害・上限・機能差をもう片方で補うこと、詳細情報を役割分担することが主な目的です。

パターン1：Pl@ntNetを一次判定、曖昧なときだけPlant.idを呼ぶ

PoCや呼び出しコストを抑えたいアプリでは、まずPl@ntNetを呼び、結果が十分に明確でないときだけPlant.idを呼ぶ方法があります。

ユーザーが写真を送信
        ↓
自社バックエンド
        ↓
Pl@ntNetで一次判定
        ↓
自社で定義した「要再確認」条件に該当するか
   ┌─────┴─────┐
  しない             する
   ↓                  ↓
候補を表示       Plant.idでも判定
                     ↓
              両者の候補を突合
                     ↓
          一致 / 不一致 / 再撮影

ここで重要なのは、Pl@ntNetのスコアが「0.8以上なら正解」といった固定値をインターネット上の一般論だけで決めないことです。自分のアプリで扱う作物・雑草・観葉植物の写真を使い、どのスコア帯で誤認が増えるかを検証してから閾値を決めます。

パターン2：両方を呼び、学名の一致を「追加の根拠」にする

誤認時に人の確認へ回す仕組みが必要なアプリでは、同じ画像を両サービスへ送り、上位候補の学名を突き合わせる方法があります。2サービスの最上位候補が同じなら「2モデルが同じ候補を出した」と表示できます。異なる場合は「要確認」にして、花、果実、葉、株全体など別部位の写真を追加してもらいます。

ただし、Pl@ntNetのscoreとPlant.idのprobabilityを足して2で割るのは避けます。モデルが違い、スコアの校正方法も同一とは限らないためです。使うのは「候補の一致」「順位」「自社検証で定めた各サービス固有の閾値」です。

パターン3：種判定と詳細・健康情報を役割分担する

もう1つは、Pl@ntNetで地域floraを使って植物候補を絞り、種の候補が得られた後にPlant.idの詳細情報やplant.healthを使う構成です。たとえば野外植物の記録アプリなら、最初にPl@ntNetで地域に合う候補を出し、その後の画面でPlant.idから一般名や説明、ケア情報など必要な項目を補う設計が考えられます。

この場合も、同一の植物名をサービス間で必ず同じ文字列として返すとは限りません。同義語、著者名付き学名、分類体系の更新があるため、学名を正規化し、必要ならGBIFなどの外部分類データベースでaccepted nameへ寄せる処理を用意します。

実装例：Pythonで2つのAPIを呼び、候補の一致・不一致を判定する

以下は仕組みを理解するための最小例です。APIキーは環境変数から読み、スマートフォンアプリやブラウザへ直接埋め込みません。画像はサーバーへ送った後、バックエンドから各APIを呼び出します。

import os
import base64
import requests

PLANTNET_API_KEY = os.environ["PLANTNET_API_KEY"]
PLANT_ID_API_KEY = os.environ["PLANT_ID_API_KEY"]


def plantnet_identify(image_path: str) -> list[dict]:
    with open(image_path, "rb") as f:
        response = requests.post(
            "https://my-api.plantnet.org/v2/identify/all",
            params={
                "api-key": PLANTNET_API_KEY,
                "lang": "ja",
                "nb-results": 5,
            },
            files={
                "images": ("plant.jpg", f, "image/jpeg"),
            },
            timeout=20,
        )

    response.raise_for_status()
    data = response.json()

    return [
        {
            "scientific_name": item["species"]["scientificNameWithoutAuthor"],
            "score": item["score"],
            "gbif_id": (item.get("gbif") or {}).get("id"),
        }
        for item in data.get("results", [])
    ]


def plant_id_identify(image_path: str) -> list[dict]:
    with open(image_path, "rb") as f:
        encoded = base64.b64encode(f.read()).decode("ascii")

    response = requests.post(
        "https://api.plant.id/v3/identification",
        params={"details": "common_names,url,taxonomy"},
        headers={"Api-Key": PLANT_ID_API_KEY},
        json={"images": [encoded]},
        timeout=20,
    )

    response.raise_for_status()
    data = response.json()

    suggestions = (
        data.get("result", {})
        .get("classification", {})
        .get("suggestions", [])
    )

    return [
        {
            "scientific_name": item["name"],
            "score": item["probability"],
            "details": item.get("details", {}),
        }
        for item in suggestions[:5]
    ]


def normalize_name(name: str) -> str:
    # 最小例。実運用では同義語・accepted nameの解決も追加する
    return " ".join(name.lower().split())


def compare_candidates(
    plantnet_candidates: list[dict],
    plant_id_candidates: list[dict],
) -> dict:
    pn = {
        normalize_name(x["scientific_name"]): x
        for x in plantnet_candidates
    }
    pid = {
        normalize_name(x["scientific_name"]): x
        for x in plant_id_candidates
    }

    common_names = list(set(pn) & set(pid))

    if common_names:
        return {
            "status": "agreement",
            "matches": [
                {
                    "scientific_name": pn[name]["scientific_name"],
                    "plantnet_score": pn[name]["score"],
                    "plant_id_probability": pid[name]["score"],
                }
                for name in common_names
            ],
        }

    return {
        "status": "needs_review",
        "plantnet": plantnet_candidates[:3],
        "plant_id": plant_id_candidates[:3],
    }


def identify_with_two_engines(image_path: str) -> dict:
    plantnet_candidates = plantnet_identify(image_path)
    plant_id_candidates = plant_id_identify(image_path)

    return compare_candidates(
        plantnet_candidates,
        plant_id_candidates,
    )


if __name__ == "__main__":
    result = identify_with_two_engines("unknown_plant.jpg")
    print(result)

この例では両方を毎回呼んでいます。まず仕組みを検証する段階では、同じテスト画像を100枚程度用意し、どのケースで一致・不一致になるかを記録すると比較しやすくなります。本番ではコストやレスポンスタイムに応じて、Pl@ntNetの一次判定が自社基準を満たさないときだけPlant.idを呼ぶように変更できます。

複数写真を使う場合、どちらのAPIでも「同じ植物個体」の写真をまとめることが前提です。花、葉、果実、株全体のように部位を変えると情報量が増えます。別の株や別の植物を1リクエストへ混ぜないよう、アップロード画面でも案内を入れておくと事故を減らせます。

本番アプリでは候補の突合より前に「入力」と「状態」を設計する

APIを2つつないでも、入力画像が悪ければ両方が同じように迷います。アプリ側で次の状態を持たせると運用しやすくなります。

状態 意味 画面の動き
agreement 両サービスの上位候補に同じ学名がある 一致候補を上位に表示。ただし「確定」とは表現しない
single_source 一次判定のみ実施 「AI候補」として表示し、必要なら再確認ボタンを出す
needs_review 上位候補が一致しない 花・葉・果実など追加写真を案内
not_plant 植物でない可能性が高い 対象を画面中央へ入れて再撮影を案内
api_error 通信、上限、クレジット、5xxなど 識別結果とAPI障害を分けて表示
confirmed_by_user 利用者や専門家が後から確定 AI候補とは別フィールドで保存

特に重要なのが、AIが返した候補と、人が最終確認した植物名を同じカラムへ保存しないことです。ai_candidateとconfirmed_taxonを分けておけば、後からモデルや閾値を変えたときに再評価できます。SE実務でいう「自動判定ログ」と「確定結果」を分離する考え方です。

スコアの扱い：0.9と0.9を同じ意味だと思わない

Pl@ntNetは候補ごとに0〜1のconfidence scoreを返し、Plant.idも候補ごとにprobabilityを返します。しかし、両者が同じデータセット、同じ学習方法、同じ校正手法で作られているわけではありません。

そのため、次のような実装は避けます。

# 避けたい例
combined_score = (
    plantnet_score + plant_id_probability
) / 2

代わりに、自社の検証データでサービスごとに閾値を決めます。たとえば「自分たちの雑草写真ではPl@ntNetの上位候補間の差が小さいと誤認が増える」「観葉植物ではPlant.idのtop-3に正解が残りやすい」といった傾向を測り、ルーティング条件へ反映します。

評価するときはtop-1正解率だけでなく、top-3に正解が入っている割合、候補不一致率、再撮影で解決した割合、API応答時間、1件当たり実コストまで記録すると、サービス選定が数字で判断しやすくなります。

APIキーと画像データの扱い：スマホから各社APIを直接呼ばない

一般公開するアプリでは、Pl@ntNetとPlant.idのAPIキーをスマートフォンアプリやブラウザJavaScriptへ直接入れない構成が基本です。Kindwiseも、モバイルアプリからKindwiseバックエンドを直接呼ぶとAPIキーを取得される可能性があるため推奨していません。

スマホ / ブラウザ
      ↓
自社バックエンド
      ├─→ Pl@ntNet API
      └─→ Plant.id API
      ↓
結果を正規化
      ↓
スマホ / ブラウザへ必要項目だけ返す

バックエンドには、ユーザー単位のレート制限、APIごとの日次利用数、Plant.idの残クレジット、タイムアウト、エラー種別、再試行回数を記録します。API障害時に無条件で何度も再送すると、クレジット消費や重複処理につながるため、再試行は回数を制限し、指数バックオフなどを使います。

画像の保存方針も先に決めます。Pl@ntNetのAPI規約では、送信画像は識別処理中の揮発メモリに保持され、画像そのものをデータベースへ保存しないと案内されています。一方、Kindwiseは写真にGoogle Cloud Storageを利用し、識別結果の利用可能期間などもFAQで説明しています。自社側で画像を保存する場合は、両社APIの取り扱いとは別に、自社のプライバシーポリシーと保存期間を定める必要があります。

コストを抑えるなら「全件二重呼び出し」ではなく再判定ルールを作る

両APIを毎回呼ぶと実装は単純ですが、処理時間と料金は増えます。実務では、次のような条件で二次判定を呼ぶ方が運用しやすい場合があります。

  • 一次判定の上位候補同士が接近している
  • 一次判定が植物ではない可能性を返した
  • 利用者が「別候補も確認する」を押した
  • 安全上、誤認コストが高い業務フローへ進む前
  • 新しい作物・雑草カテゴリで、まだ自社評価データが少ない
  • 一次APIが障害・クォータ超過で利用できない

逆に、写真ログの仮ラベル付けなど誤認後に修正できる用途では、一次判定だけで保存し、夜間バッチで要確認データだけ二次判定する方法もあります。オンライン画面の待ち時間を短くしながら、後から品質を上げる構成です。

APIを使わない段階でも2サービスを組み合わせて評価できる

アプリ開発へ入る前に、コードを書かずに比較する方法もあります。まず同じ植物を10〜20種類選び、花・葉・全体など同じ写真セットを用意します。

  1. Pl@ntNetのモバイルまたはWebで候補を確認する
  2. Plant.idのWebデモで同じ写真を確認する
  3. 学名のtop-1とtop-3、候補の一致・不一致を表に記録する
  4. 写真を追加したときに候補がどう変わるかを見る
  5. 野外・畑・観葉植物など、自分の利用場面ごとに分けて結果を見る
  6. 大量画像がある場合はPlant.idのBatch Identifierで処理方法も確認する

この段階では、サービス側が公表する精度をそのまま自分の用途へ当てはめないことが重要です。自分のカメラ、背景、作物、撮影者、季節で撮った画像を使った方が、本番に近い判断材料になります。

どちらを使うか決めるときの実務チェックポイント

選定時は、機能表だけでなく次の観点を確認します。

  • 写真を撮る場所：屋外や圏外が多いならPl@ntNetのオフラインモードが候補になる
  • 処理件数：毎日少量か、特定日に数千枚まとめて処理するか
  • 出力形式：画面で候補を見るだけか、CSV/JSONや社内DBへ取り込むか
  • 必要な詳細：学名だけで足りるか、分類、説明、ケア情報、健康状態まで必要か
  • 地域性：地域floraを明示的に選びたいか、位置情報を補助情報として使いたいか
  • 予算：無料枠で収まるPoCか、年間契約・前払いクレジットを含む本番か
  • 障害時の動作：識別を止めるか、もう一方へフォールバックするか
  • 画像・結果の保存：保存期間、利用規約、ライセンス、個人情報の扱いをどうするか
  • 人の確認：AI候補を誰が、どのタイミングで確定するか

フリーランスSEとして顧客案件へ組み込むなら、「精度が高そうだから」だけでサービスを固定するより、月間件数、ピーク件数、必要なレスポンス項目、障害時の代替経路まで要件化した方が見積もりしやすくなります。API単価が安くても、結果を人が毎回補正する運用なら総コストは上がります。

導入前の検証手順：100枚程度の自前データで判定ルールを決める

本番へ入れる前は、自分の用途に近い画像を用意して小さく検証します。目安として100枚程度から始めると、サービス間の傾向を見やすくなります。重要なのは枚数そのものより、実際の利用条件を再現することです。

  1. 対象を「作物」「雑草」「観葉植物」「樹木」などに分ける
  2. 正解ラベルは可能な範囲で図鑑・専門家・既存管理データなど別手段で確認する
  3. 同じ画像をPl@ntNetとPlant.idへ送る
  4. top-1、top-3、スコア、応答時間、エラーを記録する
  5. 両者の学名一致率と不一致パターンを確認する
  6. 不一致画像で別部位の写真を追加し、改善するか確認する
  7. 二次判定を呼ぶ条件と、人へ回す条件を決める
  8. 想定月間件数を掛け、API費用と処理時間を試算する

ここまで行えば、「Pl@ntNetだけで十分な範囲」「Plant.idを追加した方がよい範囲」「どちらでも確定させず人へ回す範囲」を分けられます。二重API構成は常に必要ではなく、検証結果から必要な部分だけ使うのが現実的です。

メリットとデメリット：2サービス併用は精度だけでなく運用コストも見る

併用するメリット

  • モデル間で候補が一致するかを確認できる
  • 不一致ケースを自動的に「要確認」へ回しやすい
  • 片方のAPI障害・上限時に代替経路を持てる
  • Pl@ntNetの地域floraとPlant.idの詳細情報など、得意な機能を分担できる
  • 単一ベンダーへ完全依存しない構成にできる

併用するデメリット

  • APIキー、料金、利用規約を2社分管理する必要がある
  • レスポンス形式を正規化する実装が必要
  • 同義語や分類体系の違いで、実質同じ植物が不一致に見える場合がある
  • 全件二重呼び出しではレスポンスタイムとコストが増える
  • 障害時のフォールバックや再試行で、想定外の呼び出し増加が起こり得る

特に同義語処理は見落としやすい点です。文字列一致だけで「不一致」と判断すると、分類名の更新や著者名の有無で誤判定します。最小構成では学名から著者名を除いた名称を比較し、本番ではaccepted nameや外部分類IDへ寄せる方法を検討します。

まとめ：選択ではなく役割分担まで考えると使い分けやすい

Pl@ntNetとPlant.idは、どちらも植物画像の識別に使えますが、サービスの入口と得意な運用が違います。Pl@ntNetは無料のモバイルアプリ、Web、観察共有、地域flora、オフライン識別があり、現地観察から始めやすい構成です。APIも1日500件までFreeで、小規模な検証に使いやすい枠があります。

Plant.idはWebデモ、Batch Identifier、クレジット制API、詳細な植物情報、plant.healthなどを組み合わせやすく、既存業務へデータとして取り込みたい場合に比較しやすいサービスです。Webデモは月10件無料、APIは100無料クレジットから試せます。

アプリへ組み込む場合は、Pl@ntNetを一次判定、Plant.idを二次判定にする方法、両方を呼んで学名候補を突き合わせる方法、Pl@ntNetで種候補を出した後にPlant.idの詳細・健康情報へつなぐ方法があります。どの構成でも、2サービスのスコアを単純平均せず、候補一致と自社検証で決めた閾値を使うのがポイントです。

最初から複雑な二重構成にせず、まずは自分の用途に近い写真で両方を比較し、不一致ケースを集めてください。その結果から「どの条件なら1社で完結させるか」「いつ2社目を呼ぶか」「いつ人へ確認を戻すか」を決めると、料金と品質の両方を管理しやすくなります。

参考情報

料金、機能、利用上限、規約は変更される可能性があります。実装・契約時は各公式ページの最新情報を再確認してください。

コメント