AIにアプリを作らせ、そのアプリに動画を作らせた——MOPRO AI OSを形にするまで

生成AIにコードを書かせること自体は、もう珍しくない。今回やってみたかったのは、その一歩先だった。AIに業務用の小さなアプリを作らせ、できたアプリに実際の仕事をさせる。最初の題材には、テーマを渡すと台本、字幕、絵コンテ、音声、動画までを組み立てる「トレンド動画制作オペレーター」を選んだ。

そのアプリが最後に作ったのは、MOPRO AI OS自身を紹介する60秒のデモ動画だった。

もっとも、これは完成した社内サービスの紹介ではない。2026年8月現在、MOPRO AI OSは社内リリース前のローカル実証段階にある。この記事は、動く範囲を一つずつ増やしながら「AIを相談相手ではなく、仕事を進める仕組みにできるか」を確かめた個人の制作記録である。

出発点はCloudflare OSだった

ゼロからすべてを設計したわけではない。出発点は、Cloudflareがオープンソースで公開しているCloudflare OSだ。

Cloudflare OSには、AIエージェントとの対話画面だけでなく、AIが利用者専用の小さなアプリ「Gadget」を作る仕組みがある。Gadgetは隔離された環境で動き、外部サービスへのアクセスは最初から与えられない。必要な接続だけを明示的に渡し、外部への書き込みのような副作用を伴う操作は、Gatekeeperを通じて人が確認する。このGadget、Blueprint、sandbox、Gatekeeperという基本構造はCloudflare OS由来である。

私が作っているMOPRO AI OSは、その基盤をMOPROの仕事で試せる形へ拡張したフォークだ。今回加えた主な要素は、日本語の業務エージェントカタログ、利用者の役割分け、業務知識と実行手順を扱うContext & Skills、ローカルのCodexを使う経路、既存業務システムとの接続口、そしてローカル動画生成の仕組みである。

Nnetは私が代表を務める会社であり、MOPRO AI OSの将来の社内利用先だ。ただし、現段階の制作と検証は私個人がローカル環境で進めている。Nnetですでに全社導入・運用している、という話ではない。

25種類を「完成品」ではなく、仕事の始め方として設計した

最初に悩んだのは、何でもできるチャット画面を、どうすれば実際の仕事の入口にできるかだった。

そこで、経営、営業、マーケティング、カスタマーサポート、EC・販売、プロジェクト管理、開発・IT、人事・業務運用という8領域に、25種類の日本語エージェントを並べた。たとえば、経営デイリーブリーフ、営業フォローアップ管理、問い合わせ回答オペレーター、進行リスク管理、障害一次対応オペレーターなどだ。

ここで重要なのは、25種類が完成済みの実行物ではないことだ。カタログの各項目は「実装スターター」である。

利用者が「このエージェントを構築」を選ぶと、名前だけでなく、業務目的、進め方、必要になり得る接続、人が確認すべき操作、測定したい指標をまとめた実装契約が、最初の指示として専用ワークスペースへ渡される。そこからAIがGadgetを作り、テストし、用途に合わせて直していく。

つまりカタログは、完成品の棚というより「この仕事を、どんな境界でアプリ化するか」を揃えた設計図の棚だ。数を増やすより、曖昧な依頼を実装可能な仕事へ変換できることを重視した。

最初の実証に動画制作を選んだ理由

代表例として選んだのが「トレンド動画制作オペレーター」だった。

動画制作は、AIエージェントの実証に都合がいい。調査だけ、文章生成だけでは終わらない。テーマを受け取り、構成を決め、台本と字幕を作り、素材の権利を整理し、音声と映像を合成し、最後に人がプレビューする。複数の工程と成果物があり、どこをAIに任せ、どこで人が止めるべきかが見えやすい。

また、成否をごまかしにくい。最終的に再生できるMP4が出なければ、仕事は完了していない。

専用Gadgetには、テーマ、対象視聴者、尺といった入力に加え、台本、字幕、絵コンテ、素材と権利、制作進捗、品質確認、最終プレビューを一つの画面へまとめた。動画レンダラーはローカルで動き、ナレーション、字幕カード、映像を組み合わせてMP4を書き出す。レンダリング自体も承認対象で、生成後に勝手に外部公開する機能は持たせていない。

Codexとローカル動画生成をつなぐ

制作では、ローカルで認証済みのCodexを、アプリを作る側のAIとして使える経路を加えた。認証情報をMOPRO AI OSへコピーせず、ローカル環境の中だけで橋渡しする。これは開発・実証用の構成で、クラウド上へそのまま持ち出せるものではない。

一方、作られたGadgetが動画を生成するために、別のローカル動画レンダラーを用意した。Gadgetはレンダラーの能力を確認し、制作プランを組み立て、人の承認後にレンダリングを依頼する。処理が完了し、動画ファイルと制作メタデータ、素材権利の記録が揃って、初めて完了とみなす。

最初の動画生成は、ローカル音声とローカルレンダリングだけで成立させた。そのうえで今回の製品デモでは、聞き取りやすさを調整するため、最終ナレーションをElevenLabs v3で作り直した。ElevenLabsはMOPRO AI OSの基盤機能ではなく、この60秒デモの仕上げに使った外部音声サービスである。

アプリが自分自身のデモを作るまで

実証の流れは、次のようになった。

1. 25種類のカタログから、動画制作の実装スターターを選ぶ。
2. AIが実装契約を引き継ぎ、専用の動画制作Gadgetを作る。
3. Gadgetに「MOPRO AI OSでできること」をテーマとして渡す。
4. 台本、字幕、絵コンテ、素材権利、制作プランを整理する。
5. 人が内容と権利を確認し、ローカルで動画をレンダリングする。
6. 実画面を使った構成へ調整し、ElevenLabsの日本語ナレーションを合わせる。
7. 1280×720、60秒の日本語字幕・ナレーション付きデモとして完成させる。

結果だけを見ると「AIが自分の紹介動画を作った」と一行で言える。ただ、実際に価値があったのは、その間にある工程をGadgetへ落とし込み、再実行できる形にしたことだった。

チャットで一度だけ良い回答が出ても、同じ仕事を翌週もう一度できるとは限らない。入力欄、状態、成果物、エラー、承認、完了条件を持つアプリにすると、試行錯誤が次回の業務資産として残る。

自律化より先に、承認境界を決める

今回、意識して残したのが人の確認だ。

MOPRO AI OSでは、エージェントやGadgetは初期状態で外部サービスへの権限を持たない。必要な接続だけを明示的に渡す。外部システムの更新、メッセージ送信、公開などは人の承認対象にする。動画制作でも、素材の権利、制作プラン、最終プレビューを確認し、公開は自動化していない。

これは「AIが全部やる」という見栄えのよいデモからは遠回りに見える。しかし、業務で繰り返し使うなら、できることの広さより、どこで止まり、誰が決めるかのほうが重要になる。

Cloudflare OS由来のGatekeeperとsandboxは、その境界を作る土台になった。MOPRO側の拡張では、各エージェントの実装スターターにも承認条件を含めた。安全性を後付けの注意書きにせず、仕事の設計そのものへ入れるためだ。

いま完成したもの、まだ完成していないもの

現時点で動作確認できている代表例は、トレンド動画制作オペレーターと、そのGadgetから生成した動画である。25種類すべてについて、個別Gadgetの実装と業務システムを含む一連の動作確認が終わったわけではない。

また、今回のローカル実証が、そのまま社内運用の完成形になるわけでもない。利用者管理、接続先ごとの運用、バックアップ、監査、社内で使う情報の範囲など、リリース前に確認すべきことは残っている。

それでも、「AIにアプリを作らせ、そのアプリに実際の成果物を作らせる」という一周は通せた。さらに、その成果物がMOPRO AI OS自身の60秒デモになったことで、抽象的だった構想を、他の人が見て話せるものへ変えられた。

AIで会社の仕事を変えるとき、最初から大きな自動化を目指す必要はないのかもしれない。まず一つの仕事を選び、必要な知識、接続、承認、完了条件を小さなアプリに閉じ込める。そのアプリをAIと一緒に直し、次も使える形にする。

MOPRO AI OSは、まだその実験の途中にある。

※ 本記事は2026年8月時点のローカル実証に基づく制作記録です。MOPRO AI OSは社内リリース前であり、記載内容は今後変更される可能性があります。Cloudflare OS由来の機能と、筆者によるMOPRO向け拡張を区別して記載しています。