独自データ囲い込み型の LLM API による差別化
Slack と AI を利用したツールを作成していく中で、Open AI の利用を前提にすることで話が難しくなることがあった。例えば Youtube を要約させようとすると非公式の YouTube 字幕 API や有料の API を利用したり、動画をダウンロードして文字起こししたりして、AI に動画内容を渡すまでが複雑化しやすい。
しかしながら、Google が提供する Gemini API においては、YouTube の URL を理解して要約ができる機能を備えており、これを使うことで簡単に動画の要約を実行するエージェントを実装できる。LLM の基盤モデル自体の差別化が難しくなってきているからか、Youtube に限らずとも Google 検索であれば Gemini を使うべきだし、X（Twitter） の情報を得るなら Grok API 経由がもっともリーズナブルとなってくるようなシステム構造になる。
モデルの性能や価格の違いによって、マルチモデルやマルチエージェントに切り分ける対応は複雑性を闇雲にあげるし、基盤モデルのコストパフォーマンス向上と機能の収斂で意味がなくなると踏んでディスコンにしたのだけど、内包しているデータが異なる前提に立つと複数のモデルを組み合わせて利用するアーキテクチャが必要になってくる。特にメディア各社や SaaS 各社は「自社コンテンツや自社データ特化型の LLM」を API への課金や広告枠の対象としてマネタイズしていくのではないかと予想している。
Vertex AI を利用した Gemini による Youtube 要約
Gemini API を利用した Youtube 要約の実装内容としてはこちらにある通りなのだが、Google Cloud Functions で起動しているのであれば Vertex AI を経由させたい。Vertex AI は LLM や画像モデルなどを Google Cloud 上で安全に運用するための統合サービス群であり、Google Cloud の課金や IAM と統合されている。
このため、プロジェクトのサービスキーの IAM 設定で Vertex AI ユーザー権限を付与しておくことで、 Google Cloud Function 側の IAM 認証が透過的に利用され、API キー不要で課金明細をプロジェクトにまとめられるメリットがある。
def __init__(self, context: Dict[str, Any]): super().__init__(context) self._project = context.get("GCP_PROJECT") self._location = context.get("GCP_LOCATION", "us-central1") self._model = "gemini-2.0-flash" self._client = genai.Client( vertexai=True, project=self._project, location=self._location, )
プログラム的にもこんな感じでキーを渡さなくて良い安心感がある。ちなみにローカル試験をする際には gcloud auth application-default login を叩くことで認証を通して実行できる。そんなことを知ることができたのも「面倒さ」のおかげだ。こっちにはこっちの良さもある。
prompt_messages: list[types.Part] = [ types.Part(file_data=types.FileData(file_uri=url, mime_type="video/mp4")), types.Part(text=prompt), ]
実際に Youtube を指定するには file_data で URL を指定するだけだが、mime_type を指定しないとエラーになるようだ。チュートリアルに記載がなくてちょっとハマってしまった。また model 名も 'models/gemini-2.0-flash' ではなく 'gemini-2.0-flash' などと指定する必要がある。
Vertex AI の料金体系はこちら。API キー直接利用と比較すると無料 Tier がなくて単価がやや高いことに気づいてしまったが、そう頻繁に使うものでもなく他の Google Cloud の利用費に合算すれば誤差の範囲なので一旦はこの方式とする。プログラムの構造自体は OpenAI 版とやっていることとそう変わらない。
PEV アーキテクチャのマルチエージェントモデルの実装
ここまでで Youtube 要約エージェントができたが、これを透過的に活用したり複数処理を組みあわせたバッチ処理に組込みたい。これを実現するための方法として Manus が採用している PEV (Planning / Execute / Verification)アーキテクチャがある。
Manus は中国のスタートアップである Butterfly Effect AI が開発した汎用エージェントであり、思考だけでなく実際の行動までを自律的にこなすことを目標としている。Devin が開発者体験の向上に特化しているのに対し、Manus はもっと汎用的に非同期クラウド環境での Web 操作や API 操作を自律的にやり切らせるために PEV アーキテクチャを考案したと思われる。
Manus 通过规划-执行-验证（PEV）多代理架构实现任务闭环，核心技术突破如下：
- 规划层（Mind）：动态任务拆解与资源优化
动态任务拆解：生成多层子任务链（如股票分析拆解为数据采集 → 建模 → 报告生成） 多模态理解：支持文本/图像/语音输入，生成任务依赖图谱（如将"日本赏樱旅行"映射为预算分配 → 酒店比价 → 路线规划）
- 执行层（Hand）：复杂操作链式调用
云端虚拟化引擎：云端虚拟机集群（4 核 CPU/4G 内存/12G 硬盘）支持跨平台调用 300+agent 工具（Python/浏览器/ERP 系统） 跨平台操作：自动登录企业系统抓取数据、调用脚本生成可视化图表并部署交互网站
- 验证层（Verifier）：双重校验机制保障输出可靠性
最近は中国系の記事を AI で読むことが改めて大事になっているが、やっているのはユーザー要求 → プランニング → 実行 → 検証 → 成果納品 → ユーザーフィードバック → 履歴・ユーザー嗜好データの更新といったサイクルを回すことで、ユーザーの要望に応えられるようにする仕組みだ。このうち、プランニング(Mind) → 実行(Hand) → 検証(Verifier)の部分が PEV であり、それぞれに独立したエージェントが担当している。
今回であれば、Slack の会話内容から「GPT で Youtube 要約が必要だからタスク化する」と判断するのが Planning エージェント、「Gemini で Youtube 要約を実施して Slack する」までをするのが Execute エージェントで、タスク定義に基づき「複数の実行結果をまとめて通知する LLM を使わない処理」を Verification エージェントとみなして実装している。Verification はもっとちゃんとしたいが。
Markdown 唯一神と八百万の神々
Planning でやっているのはルールベースおよび Open AI API の Tools によるタスクキュー登録。Execute においてはタスクキューを順番に実行していき、全て終われば結果を通知という感じなのだけど、ここで際立つのが Open AI の新 API による Funciton Calling 定義から Tools による複数定義・複数選択への転換だ。tool_choice を "auto" として「サイコロを 10 回振って」といえば 10 回分の実行定義が戻ってくるので、例えば「Manus について検索して、そこからアイディアを議論して」なんて要望をすればちゃんと順序立てて処理をしてくれる。
そして、それぞれのエージェントが独立して存在しているため、エージェントごとに適したモデルや外部 API を起動し、場合によってはエンジニアリング的なアルゴリズムやブラウザ操作などに委譲する。ここまでくると、 Open AI API の Tools 機能は "関数の呼び出し" ではなく、外部 Executor への命令インタフェースのオーケストレーターという捉え方が正しい。
我々がしていくのは、そのような用途特化型エージェントで MCP 経由でアクセスできるようにしたり、必要に応じてバイブコーディングしたり、オープンソースを利用して足していく LLM 多神教の受け入れであり、八百万の神々の作り込みだ。複数のシンプルなコマンドをパイプ実行していく UNIX の哲学に戻ってきたとも言える。プランニングエージェントはシェルスクリプト生成器である。
- 定理 1: スモール・イズ・ビューティフル
- 定理 2: 一つのプログラムには一つのことをうまくやらせる
- 定理 3: できるだけ早く試作を作成する
- 定理 4: 効率より移植性
- 定理 5: 数値データは ASCII フラットファイルに保存する
- 定理 6: ソフトウェアの挺子を有効に活用する
- 定理 7: シェルスクリプトを使うことで挺子の効果と移植性を高める
- 定理 8: 過度の対話的インタフェースを避ける
- 定理 9: すべてのプログラムをフィルタにする
Obsidian や MarkItDown などによってコンテキストに必要な全データを Markdown で集合化すればあとは便利なインターフェイスと単一の高精度 LLM があれば良いという一神教的な話をしている一方で、独自データ囲い込み型の LLM 提供やログインウォール等の API 制限によって多神教的な複数 AI 混在のマルチエージェント対応をやらざるを得ないことになっているのが良いのか悪いかと思いつつ、営利企業としての勝ち筋が残されているからこそ研究投資や浸透価格が提示されるわけだし、唯一神に囲い込まれない多神教的な状況が技術発展や経済的に今のところは良いのかもしれない。
