【ITニュース解説】What Happens When You Submit 3 AI Agents to a Marketplace and Wait 140 Hours

システムエンジニアを目指す皆さんにとって、新しい技術の動向や、サービス開発の経験は貴重な情報であろう。今回は、AIエージェントと呼ばれる特定のタスクを自動で行うプログラムを開発し、それをインターネット上のマーケットプレイスに公開しようとした際の、実体験を解説する。

筆者は、特定の機能を持つ3つのAIエージェントを開発した。一つは、文章から認知の歪みを検出する「CBT思考分析ツール」、もう一つは物事の先延ばしパターンを特定し対策を提案する「先延ばしパターン検出器」、そして人間関係における愛着スタイルを分類するツールである。これらのAIエージェントは、インターネット上の特定のURL（エンドポイント）にアクセスすることで利用できる。筆者はこれらを「Render」というクラウドサービスと「FastAPI」という技術を用いて、一つのウェブサービス上で複数の機能として提供している。これは、複数のAIエージェントを効率的に動かすための工夫である。

これらのAIエージェントは「aitopia.ai」という、AIプログラムを公開し、他のユーザーに利用してもらうためのマーケットプレイスに登録しようとした。このマーケットプレイスは、利用料金を開発者と運営側で分け合う仕組みを持つ。筆者のエージェントは、自身で開発したAIモデルを利用する「BYOM (Bring Your Own Model)」形式で、1回の利用につき5クレジットという料金を設定した。aitopia.aiは、ユーザーからの利用リクエストを筆者のエンドポイントに中継する「remote_http」モデルを採用しており、プログラムの処理は筆者自身が管理できる。

aitopia.aiへのAIエージェントの申請は、API（プログラムが外部サービスと情報をやり取りするための仕組み）を使って行われた。筆者は、エージェントの種類、料金、エンドポイントURLなどの情報をAPI経由で送信した。提出された情報がマーケットプレイスの基本的な要件を満たすかを確認する「バリデーション」という自動チェックプロセスは、全て問題なく通過した。名前空間が適切であること、料金設定がルールに合致すること、そして最も重要なエンドポイントヘルスチェック、つまり筆者のプログラムが稼働しているかの確認もクリアした。これは、プログラムが技術的に正常に動作し、マーケットプレイスのシステムと連携できる状態であることを意味する。

しかし、バリデーション通過後、140時間以上もの間、筆者のAIエージェントに何の変化も起こらなかった。ステータスは「in_review」（審査中）のままで、審査担当者も割り当てられず、審査完了の目処もなかった。この間、収益は0ドルである。通常、マーケットプレイスでは審査が数営業日で完了することが多いが、このケースでは全く当てはまらなかった。マーケットプレイスの公式ドキュメントもエラーで表示されず、進捗を確認したり問い合わせたりする手段もなかった。これは、開発者にとって非常にフラストレーションのたまる状況であり、自分の努力だけではどうにもならない「外部のゲート（障壁）」が存在することを痛感させられた。

この経験から、いくつかの重要な教訓が得られた。まず、「バリデーションは承認ではない」という点だ。システムによる自動チェックが通っても、人間による最終承認が得られたわけではない。自動チェックは技術的な整合性を確認するものであり、プログラムの品質や倫理的側面といった、より人間的な判断が必要な部分は別である。

次に、「外部のゲート」の存在とその影響だ。どんなに優れたコードを書き、プログラムを最適化しても、自分ではコントロールできない外部のプロセスがボトルネックになる場合がある。今回はマーケットプレイスの審査プロセスがそれに該当した。筆者は、このような外部ゲートを認識し、それに依存しない他の手段に速やかに方向転換する戦略を持っていたため、リスクを最小限に抑えられた。これは、システム開発やビジネスにおいて、外部要因のリスクを考慮し、代替案を用意しておくことの重要性を示している。

第三に、インフラストラクチャの効率的な利用についてである。筆者はRenderの無料枠を利用し、一つのウェブサービス上に三つのAIエージェントをデプロイした。これにより、インフラ費用をゼロに抑えることができた。この方法はコスト効率が良い反面、Renderの無料枠は一定時間アクセスがないとサービスが一時停止するため、次にアクセスした際に「コールドスタート」と呼ばれる起動時間が発生するというトレードオフも存在した。しかし、開発段階や初期のサービス公開においては、このようなコスト削減策は非常に有効である。

第四に、AIエージェントのマーケットプレイスにおける非同期性の問題である。一般的なAPIマーケットプレイスでは、数時間で審査が完了し、サービスを公開できることが多い。しかし、今回のAIエージェントマーケットプレイスでは、審査状況の通知も、フィードバックも、具体的な完了予定時刻も一切提供されなかった。これは、開発者がプログラムを提出した後、ひたすら待つしかないという、不透明な運用実態を意味する。このような状況では、計画を立てにくく、次のアクションに移りにくいという課題がある。

筆者は、この不透明な審査状況に苛まれながらも、無駄な時間を過ごすことはなかった。毎日審査状況を確認する代わりに、よりコントロール可能な活動に注力した。具体的には、技術的な深掘り記事やチュートリアル、開発過程を公開する記事など、合計79本の記事をDev.toに投稿した。また、開発したCBT分析ツールを「RapidAPI」という別のAPIマーケットプレイスにリストアップしたところ、こちらは数時間で承認され、すぐに無料枠付きでサービスを開始できた。さらに、「cbt-toolkit」という名称でGitHubにオープンソースのリポジトリを作成し、コミュニティからの関心を集めた。その他にも、24個のCBT関連HTMLツールをオープンソースで開発したり、Gumroadというプラットフォームで8つのデジタル製品をバンドル販売したりした。

これらの「ゲートのないチャネル」での活動から、直接的な収益はまだ生まれていないが、筆者はこれにより、将来的にAIエージェントが承認された際に利用できる「公開基盤」、つまり潜在的な顧客やユーザーのコミュニティを構築することに成功した。これは、単一のマーケットプレイスに依存せず、多角的なアプローチで自身のサービスを広めるための戦略である。

筆者は、aitopia.aiが自身のAIエージェントをいつか承認するのかどうか、確信が持てないでいる。審査プロセスが機能不全に陥っているのか、深刻なバックログを抱えているのか、あるいは意図的に遅延させているのかは不明である。公式ドキュメントへのアクセスもエラーであり、現状を把握するための情報源も、議論を交わすコミュニティフォーラムも存在しない。しかし、この一連の作業は決して無駄ではなかった。FastAPIで構築されたウェブサービスは正常に稼働し続けているし、中核となるCBT検出ロジックも十分にテストされ、安定している。エンドポイントもライブ状態である。たとえaitopia.aiで永遠に承認されなかったとしても、筆者はこれらの完成したAIエージェントを、別のマーケットプレイスに登録したり、あるいは直接ユーザーに公開したりすることがいつでも可能である。

この体験から得られた最も重要な教訓は、「自身の収益源を単一の外部ゲートに決して依存させてはならない」という原則である。製品を開発し、マーケットプレイスに提出することは重要だが、同時に、その後はすぐに自分自身で完全にコントロールできる代替のチャネルやプラットフォームでの活動を開始すべきである。これにより、予期せぬ外部の障壁に直面した場合でも、ビジネスを継続し、サービスの露出を確保することができる。筆者のCBT思考分析ツールは、すでにRapidAPIでレビュー待ちなしで利用可能であり、GitHubリポジトリも活発に利用されている。aitopia.aiでは今もなお審査中であるが、その間に筆者は着実に次のステップを踏み出しているのである。