Object Convertor
https://github.com/yama-is-bocchi/object-convertor
OPENAI_APIの環境変数をOllamaにすることでGPUがあれば誰でも利用できます。
基盤モデル、拡散モデル、VLMを活用し自然言語だけで物体を置き換えることができる実験アプリです。
技術力アピールのためにあえてオーバースペックなシステムにしています。
また大規模アプリケーションの設計の実験も兼ねています。
ログイン画面
Section titled “ログイン画面”プロジェクトを用意すれば、Google OAuthでログインすることが可能です。
チャット画面
Section titled “チャット画面”UIはChat GPTライクに作成しました。
ログイン時にサーバーとWebSocket接続するので非同期でメッセージを受け取れます。
画像、メッセージ入力
Section titled “画像、メッセージ入力”置き換えたい画像を送信して対象を記述します。
今回は昔飼っていた猫ちゃんをネズミにします。
置き換え対象が抽出されたら生成が始まります。
生成が完了するとページが更新されます。
別スレッドを開いてる場合は通知が表示されます。
Fooocusからのレスポンスは横向きになりましたが置き換えが完了しました。
 |  |
大前提としてこのシステムはかなりオーバースペックです。
オブジェクト置き換えだけをするのであればそもそもUI自体も不要です。
このリポジトリは現時点（2026-06）での私の技術力アピールを目的としています。
サーバーサイド
Section titled “サーバーサイド”| 言語 | Python |
| 主要フレームワーク、ライブラリ | FastAPI、Fooocus API、SAM3 |
| データベース | PostgreSQL、JSONファイル |
サーバーサイドは3層アーキテクチャ + ドメインモデルで設計しました。
これは「現場で役立つシステム設計の原則」という参考書を参考にして設計しました。
今回はシステムが全体的にデータソースの処理に偏っていたのでそこまで真価を発揮できませんでした。
とはいえコードは全体的にリポジトリインターフェースなどの適切なDI設計がされていて、機能追加が容易になっています。
フロントエンド
Section titled “フロントエンド”| 言語 | TypeScript |
| 主要フレームワーク、ライブラリ | Vite+React、Mantine |
クライアントサイドはBulletproof Reactを参考にして設計しました。
これは少し前に話題になった設計思想です。
簡単に説明すると機能単位で分割する設計方法です。
PostgreSQLでアカウントを管理し、JWT + Cookie でセッション管理をしています。
Googleでキーを発行すればOAuthで認証することもできます。
チャット機能
Section titled “チャット機能”ログインが完了するとWebSocketが接続されます。
これにより非同期でメッセージが受け取れます。
処理の流れは以下の通りです。
画像、メッセージを送信↓VLMで置き換え対象を読み取り、構造化出力↓キューに追加
キュー取り出し↓SAM3でマスク作成↓Fooocus APIでマスクから画像生成↓保存、メッセージングSAM3は自然言語で対象のオブジェクトをセグメントすることができる基盤モデルです。
Fooocus APIは拡散モデルを使った画像生成ツールのAPIサーバーです。
この2つを組み合わせることで、自然言語だけで今回のような物体の置き替えができます。
このアプリの開発では特に設計に力を入れて作りました。
改修しやすい、実装しやすい設計を心がけ、実際に参考書や記事で読んだ手法が大規模なアプリで通用するのか確かめました。
サーバーサイドの3層アーキテクチャ + ドメインモデル はあまり真価を発揮できませんでしたが、 リポジトリインターフェースとドメイン知識をドメイン層にまとめることで改修しやすいことを実感しました。
具体的なエピソードとしては、何かの機能にエラーが発生したときにドメイン層から遡って確認することが多かったことです。
例えば、画像生成時にエラーが発生したらdomain/chat/base/image_generationを確認。
アカウントのエラーなら domain/accountを確認するといった具合にドメイン層に知識がまとまっていて実装しやすかったです。
クライアントサイドのBulletproof Reactはかなりよい設計思想であることがわかりました。
改修しやすいアプリになったのはもちろんのこと、業務知識が完成しきってない状態でもある程度完成された構造になる点が素晴らしいと思いました。
というのも先述のドメインモデルは最初から完成されたものを目指すのではなく、実装が進むにつれてドメイン知識が身に付き、完成されたものになります。
対してBulletproof Reactでは機能単位で設計するので、ドメイン知識が育っていない状態でも機能として完成されたものになりやすいと感じました。
Bulletproof ReactはUIの設計に集中できるSPAなどで真価を発揮する設計思想だと感じました。
このアプリ作成を通じて設計とフレームワークの選定について見えてきたものがあるので、また後日ブログで発信したいと思います。