こんにちは、DIVXエンジニアの下岡です。

生成AIの進化はとても速く、日々新しいモデルやサービスが登場しています。同じ処理を実現するにも、使えそうなモデルの選択肢がいくつもある状態が当たり前になってきました。ただ、候補が多いということは、どれを使うべきかを事前に判断するのが難しいということでもあります。デモやサンプルは良く見えても、自分たちの用途で同じ結果が出るとは限りません。
結局のところ、実際に動かしてみないと分からないことが多いです。

今回、まさにそういう場面に直面しました。

とある案件で、AIで生成した画像を、あとから編集できるように要素ごとに分割する機能を実装することになりました。分割には、オブジェクトごとの抽出、背景除去、インペイントなど、いくつかのAI処理を組み合わせる必要があります。そして、その一つひとつに、使えそうなモデルの候補がいくつもありました。

まずはこれらを実際に動かして、どのモデルが使えそうかを見極めることにしました。検証に使ったのは、さまざまな生成AIモデルをAPI経由で試せるfal.aiというプラットフォームです。このようなプラットフォームを利用することで、モデルごとに依存関係を解決したり、GPU環境を準備したりする手間をかけずに、まとめて試すことができます。

この記事では、その検証の記録を書いていきます。

この記事は、次のような方を想定しています。

• 生成AIモデルを業務やプロトタイプで試してみたい方
• 画像生成、背景除去、セグメンテーション系のモデルを比較したい方
• どのAIモデルを選べばよいか迷っている方
• モデルを検証・比較した具体的な過程を知りたい方

fal.aiの全機能を網羅する記事ではありません。実際にひとつの案件で画像系AIモデルを検証した経験を、うまくいかなかった点も含めてそのまま書いています。

fal.aiは、さまざまな生成AIモデルをAPI経由で利用できるプラットフォームです。

公式ドキュメントでは、画像、動画、音声、音楽、3D、リアルタイムストリーミングなど、1,000以上のモデルを統一APIで呼び出せると説明されています。

以下は、2026年7月時点でfal.ai上に掲載されていたモデル例です。

※モデルの追加・更新は頻繁に行われるため、実際に利用する際は公式のExploreページや各モデルページを確認してください。

fal.aiを使い始める流れは比較的シンプルです。

まず、fal.aiにアクセスし、アカウントを作成します。ログイン方法としては、GitHub、Google、SSOなどが用意されています。

次に、ダッシュボードから利用したい分のクレジットを入金します。
fal.aiは事前にクレジットを購入して使うプリペイド方式を採用しており、サブスクリプションはありません。
検証用途では、あらかじめ使う範囲を決めて入金しておけるので、「まずこの範囲で試す」という進め方がしやすく安心感がありました（法人向けには個別のエンタープライズプランもあります）。

気になるモデルは、まずブラウザ上のプレイグラウンドで動かして感触を確かめられます。良さそうであれば、そのままAPI経由の呼び出しに進みます。

API Keyを発行し、Node.jsやPythonのSDKからこのAPI Keyを使ってモデルを呼び出します。今回はPythonのfal-clientを使い、次のように呼び出しました。

import fal_client

result = fal_client.subscribe(
    "fal-ai/birefnet",
    arguments={
        "image_url": image_url,
    },
)

print(result)

モデルによって渡すパラメータ（画像URL、プロンプト、マスク画像など）は異なりますが、呼び出し方の基本的な流れは共通しているため、複数モデルを検証するスクリプトを作りやすいです。ブラウザで1件ずつ試すだけでなく、SDKを使って検証スクリプトに組み込めば、複数パターンをまとめて実行することもできます。

では、ここから今回実際にやった検証の話に移ります。

今回の検証では、画像系AIモデルの候補をいくつか選び、同じ入力に対してどのような出力が返るかを確認しました。

画像内の要素をどの程度扱えるか、出力結果を後続処理に使えそうか、といった観点で見ていました。

いくつか試した検証のうち、ここでは一例として「一枚絵から必要なオブジェクトを抽出できるか」を取り上げます。

一枚の画像には、主役となる被写体だけでなく、背景、装飾、アイコン、文字など、さまざまなものが含まれています。人間が見ると自然に分けられるものでも、AIモデルにとっては必ずしも同じように分かれるとは限りません。

今回は、SAM系（セグメンテーションの代表的なモデル群）や、rembg、BiRefNetをはじめとする背景除去系のモデルなど、いくつかの方向性を試しました。

同じ「画像から対象を抜き出す」に見えても、モデルによって考え方はかなり違います。画像全体からそれらしい対象を自動で拾うものもあれば、対象をテキストで指定して検出するものもあります。背景除去系のように、主役を残してそれ以外を背景として扱うものもあります。

そのため、最初から一つのモデルに決め打ちするのではなく、複数の候補を小さく試しながら、今回の用途に近いものを探していきました。

また、モデルだけでなく、試す画像自体も複数パターン用意するようにしました。同じモデル・同じ設定であっても、色味や構図、要素の多さといったデザインの違いによって精度にばらつきが出ることがあり、1〜2パターンだけで判断すると、たまたま相性の良い画像で高評価だっただけ、ということにもなりかねないためです。

検証では、API経由でモデルを呼び出す簡単なスクリプトを作りました。複数モデルを比較したり、同じ入力で条件を変えたりする場合、手元に結果を残せる形にしておくと後から見返しやすくなります。

この段階では、完璧な評価基準を最初から作るというより、まずは候補モデルごとの挙動を把握することを優先しました。

• 同じ入力に対して、どのような出力が返るのか。
• モデルごとにレスポンス形式はどれくらい違うのか。
• 期待していた用途に近そうか。
• 後処理がどれくらい必要になりそうか。

そのあたりを確認しながら、候補を絞っていきました。

検証スクリプトでは、あとから見返しやすいように結果を保存しました。

保存した情報は、主に以下です。

• 入力ファイル名
• 使用したモデル名
• 指定したパラメータ
• 出力画像
• マスク画像や中間結果
• 検出されたラベル
• スコア
• 座標情報
• 実行日時

出力画像だけが残っていても、どのモデル・どの設定で実行したものか分からなければ、あとから比較しづらくなります。そのため、実行条件や検出結果も一緒に残すようにしました。

ディレクトリ構成としては、たとえば以下のような形で保存しておくと見返しやすいです。

outputs/
  sam-like-model/
    sample-001.png
    sample-001_mask.png
    sample-001_manifest.json
  background-remove-model/
    sample-001.png
    sample-001_manifest.json

実際の検証では、出力画像だけでなく、モデルが返した検出結果もJSONとして保存しました。

たとえば、オブジェクト抽出系の検証では、以下のような情報を残しました。

{
  "canvas": {
    "width": 1536,
    "height": 1024
  },
  "objects": [
    {
      "id": "food_1_s0.91",
      "label": "food",
      "score": 0.905,
      "bbox": {
        "x": 608,
        "y": 338,
        "width": 927,
        "height": 647
      },
      "file": "food_1_s0.91.png"
    }
  ]
}

このJSONには、画像サイズ、検出されたラベル、スコア、座標、出力ファイル名などが入っています。（座標は画像左上を原点とし、bboxはx, y, width, heightで対象領域を表しています。）

結果画像だけを見ても、あとから比較するのは意外と大変です。しかし、このようなメタ情報があると、どの対象がどのスコアで検出されたのか、どの範囲が切り出されたのかを確認しやすくなります。

また、ファイル名にも food_1_s0.91.png のようにスコアを含めておくと、フォルダを開いただけでも結果の傾向が分かります。

検証段階では、きれいな管理画面を作る必要はありません。ただ、あとから見返せる最低限の情報を残しておくだけで、判断しやすさがかなり変わります。

自動で対象を検出するタイプのモデルは、細かすぎる粒度で分割してしまうことがありました。人間なら1つのまとまりとして見る要素を、モデルはさらに細かいパーツの集まりとして認識してしまい、1枚の画像から50近い断片が出力されるようなケースもありました。加えて、今回試した範囲では、分割自体の境界も粗く、実用に使える精度とは言えませんでした。

背景除去系のモデルは、主役の判定がこちらの想定と一致したときはきれいに切り出せました。ただし、1枚の画像につき抜き出せるのは1点だけで、複数の要素を並行して分けることはできません。また、そもそも「これが主役」というモデル側の判断が、こちらの意図とズレることもありました。背景がシンプルで、対象が1つだけ写っているような画像であれば安定して機能するため、前処理や後処理として部分的に組み込むことは検討しましたが、メインのセグメンテーション手法としては採用できませんでした。

最終的に候補に残ったのは、プロンプトで対象を指定するタイプのモデルでした。例えば "food" と指定すると食べ物として分かりやすい部分は比較的検出でき、他のタイプよりも狙った対象を的確に切り出せました。

ただ、いくつかの壁もありました。

"food" と指定すると、皿やカトラリーのような周辺要素は対象外として扱われることがありました。これはモデルが間違っているというより、こちらが使いたい範囲と、モデルがその単語から認識する範囲が一致していない例だと思います。逆に、 "photo" のような抽象的な指定では、期待したようには検出されませんでした。人間にとっては「写真部分を抜き出したい」という意図があっても、モデルにとって"photo"が何を指すのかは曖昧です。また、装飾として入っている鶏のイラストが、食べ物として検出されることもありました。

さらに実運用を考えると、別の壁もありました。プロダクトとして使う以上、想定していない画像が来ても対応できる必要がありますが、プロンプト指定型は「何を検出するか」を事前に指定する仕組みのため、想定外のパターンに弱くなります。加えて、プロンプトを送るたびに課金が発生し、検出結果が0件であっても料金がかかる仕組みだったため、多数のプロンプトパターンを力技で試すというアプローチも、コスト面で現実的ではありませんでした。

こうした検証を経て、有力な候補だったプロンプト指定タイプのモデルについて、弱点をどう補うかも含めて検討を進めました。見つかった様々な課題に対して、他のモデルと組み合わせる、システム側の設計で吸収する、といった方向で、一部実装にも取りかかっていきました。ただ、完全に実用的な形に持っていくには、高いハードルを感じていたのも正直なところでした。

そんな中、先方とのやり取りの中で、要件そのものが大幅な変更になり、今回はこのモデルを使った実装は一旦白紙、採用しないという判断になりました。

では今回の検証は無駄だったのかというと、そうではありません。
モデルごとの得意不得意はもちろん、スクリプトで検証を進める過程で、返ってきた画像やマスクをどう保存するか、座標情報をどう扱うかといった、AIの出力をシステム側でどう扱うかについての知見も自然と多く得ることができたからです。

実際、新しい要件に合わせて設計を考え直す作業は、この検証で得た知見のおかげで、想定していたよりもかなりスムーズに進められました。

今回は、画像を要素ごとに分解する機能の実現に向けて、複数の生成AIモデルを比較検証した過程を書いてきました。

結果としては採用に至りませんでしたが、実際に手を動かして試したことで、カタログやデモを眺めているだけでは分からなかったモデルごとの癖や、実運用に持っていくうえでの壁を、具体的に知ることができました。

こうした検証は、fal.aiのように複数のモデルをまとめて試せる環境を使えば、それほど手間をかけずに始められます。

生成AIは選択肢が多く、どれも良さそうに見えます。だからこそ、小さくてもいいので実際に動かして確かめてみることが、遠回りのようで一番の近道なのだと思いました。

参考：

• https://fal.ai/docs/documentation
• https://fal.ai/pricing