10個のAIアプリケーションと3個のAIエージェントを1人で開発してみた
こんにちは！逆瀬川 ( https://x.com/gyakuse )です！
さいきんあんまり記事を上げたりできていなかったのですが、この半年程度、何をしていたかというと、アプリケーションとエージェントとアシスタント開発をしてました。
今日はそれらの紹介を行い、それらをどうやって作ったかというのを書ければと思っています。身を粉末状にして頑張って作りました。ぜひ、読んでもらえれば嬉しいです。
作ったエージェント、アプリケーション
- Agent
- Task Agent: Pythonのライブラリで動作するコンパクトなエージェント
- Computer Agent: Mac/Windows/Linux上のソフトウェアを使い任意のタスクを実行するエージェント
- RPA Agent: Mac/Windows/Linux上で録画された作業をもとにその作業の続き (または定期的な反復) を行うエージェント
- Application
- AI Study: 資料等をアップロードするとそれをもとにチャットやレクチャーやスライドや動画等を生成
- AI Translator: 任意のファイルをアップロードすると、特定言語への翻訳版へと即時に変換
- AI Video Translator: 任意の動画を特定言語の吹替や字幕版に変換
- AI Video Edit Assistant: クリップ自動生成、動画編集
- AI Slide Generator: スライド爆速生成
- AI Stylist Assistant: バーチャル試着
- AI Chat: 一般的なAIチャット
- AI Search: 一般的なAI検索
- AI Article Assistant: 記事作成支援
- AI Data Analysis Assistant: データ分析支援
開発の背景
今回10個のアプリケーションと3個のAIエージェントを作ったのは、第一に、『AIパートナー』という、開発中のAIアシスタントの手足となるようなものがほしかったからです。私の夢は、すべての活動をAIとともにこなすことができるようになることです。文章を書くとき、調査をするとき、動画を作るとき、デザインを考えるとき、PCで作業をするときなど、それらの活動をAIと共同で行うのはもはや一般的になりつつあります。
しかし、その体験は良いものとは言えません。横断的にコントロールするためのプロトコルとしてはMCPがあり、MCPサーバー群が多数開発されていますが、すべてをMCPで賄うことは難しく、まだ近未来的な体験を提供できる時代がきたとは言いづらいです。
そのため、必要なアプリケーション群、エージェント群を自前で実装することにしました。これは、Googleのような巨大企業が取るべき戦略ですし、実際彼らもそのような戦略を取りつつあります。ですが、勝てないと決まったわけではありません。たぶん。体験で戦うとき、常にひとつの体験戦略だけが正しいとは限らないと考えます。
3個のAgentの紹介
タスクを実行するAgentは、どんなものを作るべきでしょうか？
Agentの種類について
Agentには環境別に考えると、大まかにわけて以下の4つのタイプがあると思います。
- ツールベースAgent: 事前に用意されたツール群を組み合わせてタスクをこなすAgent
- 計算をするツール、画像を生成するツール、ニュースを取得するツール等、シンプルなツール群からタスク解決をするAgentです。
- プランニングのコストだけでほぼ運用でき、ブラウザAgent、PC Agent のような視覚的な推論が要求されません。
- MCPベースのAgentもここに分類されます。
- ブラウザAgent: ブラウザの操作を通じて、ブラウザでできるタスクをこなすAgent
- ヒトの作業はおおむねブラウザ上で完結することが多く、またブラウザに世界 (環境) を閉じることで情報の管理や推論が比較的しやすくなります。
- 作り方によっては視覚的な推論を行う必要があり、MLLMの性能に依存します
- PC Agent: PCの操作を通じて、PCでできるタスクをこなすAgent
- ブラウザを超えたファイル操作、アプリケーション操作等もすべてこなせるAgentです。
- 可用性が高い一方、視覚的な推論がほぼ必須となり、難易度が上がります。
- 物理世界Agent: 実世界に影響を及ぼすハードウェア (ロボットアーム等) を通じて、実世界のタスクをこなすAgent
- 掃除、洗濯、調理、各種労働など、実世界の作業を行うAgentです。
- 視覚的な推論に加え、ハードウェアの制限も非常に重要な問題です。
- 現状ではAIの能力不足やハードウェアの制限のため、タスク自体を簡単な問題にするという前処理も重要になってきます
それぞれ可能な範囲や精度、コストの差があり、たとえば完璧に人間のようなロボットを作ったとしても、タスクによってはツールベースのAgentがコスト面や安定性で勝るシーンが多くあると思います。
※Agentの分類や方法論については以下のサーベイ論文に詳しい
また上記論文の分かりやすいまとめをLINEヤフーの北田さんが作成してくれています
Agentの考え方 (タスク解決戦略)
Agentの設計方法は様々なアプローチがあり、ReActフレームワーク等が有名なものとしてあります。これらは概ね以下のように区分可能できます。
- Planをつくり、分解されたタスクをもとにタスク解決するもの
- 適応的にタスク解決するもの
実際はこの中間のようなものをつくっていくことになります。
難しいのは、LLMはPlanをひとたび作ってしまうと、それを修正するにしても逸脱することが難しい、ということです。一方で適応的にタスク解決すると、大きすぎるステップ幅を計画しようとしたりもします。いい塩梅にするには割と秘伝のタレ的な技法が必要になってきます。
PC Agentについて
PC AgentのアプローチとしてはOmniParserのようなモデルでUI検出を行うものやMLLMを用いて画像をそのまま入力して操作を推論するタイプのものがあります。前者のほうが軽量で理想的な速度で実行できるためまずこちらを検証しましたが、検出漏れが多く断念しました。
後者のモデル選定においては、いくつかのベンチマークを参考にしました。ScreenSpot-Proベンチマークは従来のScreenSpotベンチマークと比べ、高解像度かつ複雑な操作を対象としており、非常に参考になります。なお、こうした一方でベンチマークを動作させるときのプロンプトが適切でない場合も散見されるので注意が必要 (例えばGeminiの場合 [0-1000] の矩形を出力するようにトレーニングされている) です。
また、今回はcomputer-use系のライブラリをそのまま用いず、ゼロベースで実装しました。ここで気づいたことは、操作ミスのループからどうやって抜け出すか、という問題が思ったより難しいということです。そうしたミスは大きく分けてプランに依るもの、操作推論時に環境やLLMの事前知識から引き起こされるものがあります。前者においてプランに誤りがあると抜け出すのは非常に難しいものになります。LLMの性質上、前提として提示されたものは疑うことが難しいのです。そうしたミスを抜け出しやすくするため、連続して近いアクションを取った (つまりループと判定される状況) 場合、プランを疑ったり事前知識を疑うフィードバック機構を設けました。こうしたものは別立てで用意することで自己改善されていきやすくなります。
文字入力についてはかなり厄介なのですが、起動時にキーボード配列やIMEを検出し、keyboardライブラリ、pyautogui、pyperclipを環境やOS等によって動的に選択する形を取りました。
今回作ったAgent
今回はツールベースAgentのTask Agent、PC AgentのComputer Agent、およびRPA Agentを開発しました。
Task Agent
- 特徴・主な機能
- ツールベースのAgent
- 20種類以上のツールを実装済み
- ライブラリ / API / ターミナルでの実行等に対応
- DeepResearchのように自動調査してNotionに保存したり、旅行日程を作ったり、スライドを作ったり様々な複雑なタスクが実現可能
- 頑張ったところ
- 設計を柔軟にしたので、先ほどのタスク解決戦略を切り替えられるようになっています
- また、ツールを追加しやすい形状にしたので、ツールの追加・単体テスト・結合テストはめちゃくちゃ容易に追加できます。エージェントシステムとは独立しているため、LLMを使ったコーディングを使うと一発でテストまで作れます。
以下のデモは天気と傘などを持っていくべきかを確認する簡単な処理をターミナル上でしています。
Computer Agent
- これはどういうもの？
- Mac/Windows/Linux上で任意のタスクを解決するためのエージェント
- 特徴・主な機能
- タスク依頼を記述するとまず作業の詳細化のためのチェックを行う。それが終わればすぐ実行可能となる
以下のデモはarxiv.orgから論文を探し、Notionにまとめるという作業となります。
RPA Agent
- これはどういうもの？
- Mac/Windows/Linux上で録画された作業をもとにその作業の続き (または定期的な反復) を行うエージェント
- 特徴・主な機能
- PCでの反復的かつ従来のRPAで達成不可能な作業 (例えば、ファイルに同じような編集を加えて特定のフォルダに移動しExcelに作業記録をつける、競合企業を調査しプレゼンにまとめるなど) を、1度の作業収録にて反復的に作業してくれるAgent
- 「作業の続きをやってほしい」「定期的に反復してほしい」というニーズに柔軟に対応できる
- 作業内容を自動的に手順書にもしてくれる
- 頑張ったところ
- RPA AgentではComputer Agent以上に複雑な操作を達成したいというモチベーションがある
- 詳細にステップを定義し逐次達成検証をする方法やチェックポイントのみを抽出する方法など、いくつかのアプローチを検証し、最も安定しやすい手法を選んだ
- 地味にネストされたメニューの選択が難しかった (直線的にマウスを動かすと失敗してしまう)
以下のデモはAIベンチャーの資金調達を調査してSpreadsheetにまとめた動画をもとに自動的に手順抽出を行いタスク化されたものを実行した動画です。ちゃんと作業の「続き」をやってくれています。
10個のアプリの紹介
アプリケーションでのAIの組み込み方について
機械学習のモデルやMLLMを利用したアプリケーションを開発する際は、期待する出力品質、速度、自動化の割合などをよく検討する必要があります。完全に自動化する仕組みを狙うのは無謀な領域もありますが、最初からそう割り切ってやったほうがフォーカスが絞りやすい (何を洗練させれば良いかわかりやすい) という場合もあります。また、多くの場合は人間の関与を必要とするアプリケーションとなりますが、この場合は人による入力をどう心地いいものにするか、というUXが非常に重要になってきます。
多くの場合はMLLMをそのまま使いがちですが、速度または精度が十分でない・安定しない場合は単純な分類器や古典的なアプローチが役立ったりします。
アプリケーション開発におけるLLMの使い方について
Coding 系の支援ソリューションは多くありますが、開発中は手動実装と以下のシンプルなLLMの利用にとどめました。
理由としては、まだ現時点では手で書いたほうが単純に早かったり、LLMを使う場合は入出力を常時ハックしたほうが無駄な経路ロスを防げるためです。個人的に既存のCoding Agentよりうまく動きそうなアイデアもあるので、次はCoding Agentを開発してみようと思っています。
アプリケーション開発フロー
多くのアプリケーションを個人開発するときはフローを安定化させたほうが作りやすいです。
おすすめの開発フローは以下のとおりです。
- アイデア: 思いついたアイデアをNotionのデータベースに追加します
- 検証: google colab等で軽い検証を行います
- 仕様ラフ: ざっくり考えていることやニーズ、なぜ作るか等をまとめます
- 仕様策定: LLMを使って細かい仕様やデータベース仕様を作り手で直します
- 開発: がっと書いていきます. 悩んだり面倒なところをLLMに頼ります
TODOリストは以下のように一つのNotionデータベースにアプリケーション毎のviewを作り分けています。個人開発には結構便利です。
以下では作成したアプリケーションを紹介します。
01. AI Study
- これはどういうもの？
- 資料等を雑にアップロードするとそれをもとにチャットやレクチャーやスライドや動画等が作られる便利アプリケーションです。
- 特徴・主な機能
- 資料をベースにしたチャット
- レクチャーノート作成
- 講義スライド作成
- 動画レクチャー作成
- 頑張ったところ
- 動画レクチャーが見たい、というときにめっちゃ待つとしんどいです。なので、このあと紹介するAI Slide Generatorと組み合わせて、動画レクチャー生成にかかる時間を3秒程度にしました。ほぼ待ち時間を感じずに済みます。
02. AI Translator
- これはどういうもの？
- 任意のファイルをアップロードすると、特定言語への翻訳版へと即時に変換されるアプリケーション
- 特徴・主な機能
- ファイルの自動翻訳
- 100以上の言語対応
- 対応ファイル: 画像, pptx, xlsxなど
- 頑張ったところ
- 画像やPDF等はレイアウトの維持をしながらの翻訳に特に力を入れました。
03. AI Video Translator
- これはどういうもの？
- 動画を任意の言語に吹替したり字幕つき動画にしたりするアプリケーション
- 特徴・主な機能
- 動画吹替生成
- 動画字幕生成
- 吹替/字幕は50言語対応
- 頑張ったところ
- 吹替をするとき、特定の音声区間でうまくマッチする発話内容・発話量、話速にする必要があります。しかし、単純に発話内容を翻訳すると、翻訳後の言語の特性によっては短すぎたり、長すぎたりしてしまいます。それを考慮して翻訳し、かつ話速を調整する必要がありました。
字幕例(スペイン語->日本語): 吹替例(スペイン語->日本語): 吹替例(ドイツ語->韓国語):
04. AI Video Edit Assistant
- これはどういうもの？
- もともとクリップを自動編集するためのアプリケーションでした
- 現在は字幕をいじったり、より高度な動画編集が可能になっています
- 特徴・主な機能
- 動画のチャプター生成
- チャプターや特定の動画の尺をベースとした字幕付きクリップ生成
- 頑張ったところ
- クリップをWebで編集するときは動画データの特定の尺にブラウザ上で自然に見せないといけません。一方で、区間クリップ処理は重い操作なので、
- 「ちゃんとした動画らしさ」には字幕のクオリティが非常に重要です。そのため、字幕のパターンを20種類以上プリセットとして用意しました。
生成された動画:
05. AI Slide Generator
- これはどういうもの？
- スライドを瞬時に作ってくれるアプリケーションです
- 自動で調査し、必要に応じて画像を生成したりデータを処理してスライドに組み込みます。
- 特徴・主な機能
- スライドの自動生成
- 自動調査・自動挿絵生成・自動データ処理
- 頑張ったところ
- 既存のスライド生成システムは非常に動作が緩慢である場合が多いです。このアプリケーションでは軽量なモデルを使い、瞬時に1ページ目を出すように工夫しました
ポップスライド例 (ポップに, と指示)
真面目スライド例 (クールな, と指示)
06. AI Stylist Assistant
- これはどういうもの？
- 外出時に手持ちの服から天候や季節を考慮して自動的に組み合わせてくれるシステム
- 事前にアイテムを大量に登録しておくことで店舗向けのバーチャル試着システムにもなります。
- 特徴・主な機能
- 衣服の登録 (トップス、ボトムス、アウトフィット、シューズ)
- 仮想試着・組み合わせ提案
- リアルタイム仮想試着
- 頑張ったところ
- 多くのVTON (Virtual Try-on) 系のモデルは非商用ライセンスになります。これはデータセットがNCライセンスであるためです。最近のモデルを使うと (gpt-image-1など) 仮想試着のようなものは可能ですが、容姿がいくばくか変わってしまい、かつ推論に時間がかかり、コストも高くつきます。そのため、独自手法を用いてリアルタイムにバーチャル試着できるようにしました。なお、より自然な試着体験のために30FPSが目標ですが、現状はまだ達成できていません。
07. AI Chat
- これはどういうもの？
- 一般的なAIチャットアプリケーション
- 特徴・主な機能
- ファイル添付、検索対応
08. AI Search
- これはどういうもの？
- 一般的な検索+LLMアプリケーション
- 特徴・主な機能
- 検索
- 頑張ったところ
- 初期レスポンスが250ms以内になるように高速化に注力しました
09. AI Article Assistant
- これはどういうもの？
- 執筆支援用AI
- 特徴・主な機能
- 文献登録
- 自動加筆
- 挿絵生成
10. AI Data Analysis Assistant
- これはどういうもの？
- 任意のファイル (pdf, excel, pptx等) からデータを抽出し, チャットベースで分析したり予測モデルを自動構築するデータ分析アシスタント
- 特徴・主な機能
- ファイルからのデータ抽出
- グラフでの視覚的な表現
- 予測モデルの自動構築
- 頑張ったところ
- 単純にLLMに投げ抽出処理をするとハルシネーションが起こります。また、非常に長大なファイルではコストもかかりすぎます。これをうまく処理しています。
- またレイアウトを考慮したデータ抽出のために、Excelを一度描画して画像形状にするのが通常のライブラリでは難しかったため内部的にレンダリングするシステムを作りました。
協力のお願い
私はこれをもっと洗練させて商品として提供し、みんなに触ってもらいたいなと思っています。
しかし、個人でやっているため、推論用のサーバーすら十分に用意するのが難しいのが現状です。
もし、一緒にやってくれたり興味をもってくださる企業の皆様がおられましたら、ぜひ、以下アドレスまでご連絡をいただければ幸いです。
nyosegawa@gmail.com
また、この製品群が一定の形になったので、お仕事も絶賛大募集しております。
ここまで読んでくださりありがとうございました！
オマケ: 軽量なASRモデルを作る
リアルタイム音声対話はMLLMを用いて音声をエンコードしてモデルに入力し音声トークンを出力するような現代的アプローチとASR->LLM->TTSでごまかす旧式のアプローチの大きく分けて2つのアプローチがあります。後者の実装は以下を参考にできるでしょう。
また、24時間フル稼働できるものを考えると、現時点では後者が必須となります。
この仕組みを作っていて一番厄介なのがASR部分です。ローカルで動作できるほど軽量で推論速度が非常に早く高精度なモデルはあまり多くありません。
一方で、ASRは必ずしも日本語として出力する必要はありません。whisperのようにtransformerベースのくっついたモデル等は強力な補完能力がありますが、それゆえに書き起こしにおいてハルシネーションが発生します。もっとシンプルな音響ベースの書き起こしがあってもよいと思い、ローマ字出力する軽量なモデルを作っています。reazonspeechさんのjapanese-wav2vec2-baseにCTCをつける簡単なものです。japanese-wav2vec2-baseのエンコーダとしての能力に依存して少ないサンプルでもそこそこな音響的推論ができると考えております。現状、5000サンプル程度でトレーニングしていますが、良い兆候が見えています。後日、トレーニング済みのモデルを公開予定です。
Discussion