10月16日、Meta Engineeringが「How Meta Built Forum With AI-Native Engineering」と題した記事を公開した。この記事では、MetaがAIエージェントを開発サイクルの参加者として組み込む新しい手法で、新アプリ「Forum」をゼロから構築した取り組みについて詳しく紹介されている。

エンジニアが「コードを書く人」から「AIエージェントが生み出すアウトカムを所有する人」へと役割を変えた実例として、業界全体の関心を集める内容だ。

Forumとは何か、なぜスタンドアロンアプリとして作られたか

Forumは、Facebookグループでの会話をより深く楽しむためのスタンドアロンアプリだ。Metaはかねてより、Facebookのモノリシックなアプリ体験から特定ユースケースを切り出し、専用アプリとして独立させる戦略を取ってきた（InstagramやMessengerもその流れの産物だ）。Forumもその延長線上にある。グループ機能に特化した体験をFacebook本体から分離することで、コミュニティ利用者のエンゲージメントをより深く引き出すことが狙いとされている。少人数のチームがゼロから構築した。

このプロジェクトで注目すべきは、AIをコード補完ツールとして使うのではなく、エンジニアリングプロセスの参加者として扱ったことだ。成功の指標として「生成したコード量」は採用せず、「ビルドが通り、テストを通過し、レビューを生き延びた変更」＝本番投入可能なアウトカムだけを数えた。

「Human-in-the-Loop」から「Human-on-the-Loop」へ

この取り組みの核心となる概念がある。いずれもAI・自動化の分野で広く使われる用語だが、Metaはその対比を自社の開発実践に当てはめている。

Human-in-the-Loop（従来型）では、エンジニアがすべてのステップを主導し、AIはその内側でアシストする。関数の補完や修正提案がそれにあたる。人間がループの「中」にいて、各判断を担う形だ。

Human-on-the-Loop（新しい形）では、エージェントが「計画→実装→ビルド→テスト→修正→繰り返し」のループを自律的に回す。人間はループの「外」＝監視層に立ち、ゴールを設定し、実行を観察し、逸脱があれば介入し、結果を承認する。エンジニアの仕事が「ステップを実行すること」から「アウトカムを所有し品質基準を守ること」に移る。

ただし記事は、これが完成した状態ではないとも明記している。今日時点で自律的に動くステージもあれば、まだエンジニアが各ループに入るステージもある。

完成の定義も厳格だ。コンパイル通過ではなく、自動テストとビジュアルチェックの通過をもって「完了」とした。エージェントがレビュー前に自分の仕事を検証するため、エンジニアのレビューキューに届くのは「確認済みの小さなセット」になる。

環境をモデルに合わせて変えた

記事が強調するのが「プロンプトよりもコードとツールの改善の方が大きな成果をもたらした」という点だ。

アーキテクチャの明快さを優先

Forumのコードベースをできるだけシンプルに保ち、キーとなる部分をモジュール化した。実績ある共通インフラの恩恵を受けながら、エージェントが差し込みやすい構造にした。容易にモジュール化できない箇所はあえてゼロから作り直し、再利用性よりもエージェントのスループットを取った。

コードのパターンも重要だという。弱いパターンを一度修正すれば、以降のすべてのエージェントセッションがその改善を引き継ぐ。逆に放置すれば、エージェントが書くものに同じ悪いパターンが繰り返し現れる。

「説明」ではなく「ツール」を与える

主な失敗パターンは、エージェントがアプリ内の自分の位置を見失うことだった。グループホーム画面の変更を依頼したのに、ホームフィードを編集してしまうといったケースだ。

解決策は、アプリをエージェントに「説明する」のをやめ、エージェントが直接状態を確認できるツールを与えることだった。シミュレータからのライブビュー階層の読み取り、画面上の要素のリストアップ、対象ビューへのパス検索といったツールを用意した。的外れな編集が大幅に減少したという。

プロトタイプと本番を分離するビルドフレーバー

Forumが本番に近づくにつれ、AIが生成した実験的なコードと、レビュー済みの本番コードを明確に分離したくなった。フィーチャーフラグでの管理だと、プロトタイプコードが本番ビルドに残り続ける。

そこで採用したのが別のビルドフレーバー（サンドボックスアプリ）だ。本番と同じコードベース、フレームワーク、デザインシステムを共有しながら、プラグイン/ソケットアーキテクチャを通じてプロトタイプコードを本番ビルドから物理的に除外する。

これにより3つのメリットが同時に得られた。

• デザイナーや他部門のメンバーが、エンジニアを介さずAIツールで自由にプロトタイプを作れる
• サンドボックスで作ったものは再ビルド不要で本番に移植できる
• プロトタイプコードは本番ビルドに物理的に存在しないため、本番アプリをクラッシュさせ得ない

AIによるストレステストで実際のバグを発見

環境の整備はエージェントを「テスター」にもした。特定の不具合を狙うのではなく、実際のユーザー行動を模した繰り返し可能なストレスシナリオ（激しいスクロール、ランダムなグループ閲覧、高速なナビゲーション、連続したメディア読み込み）を定期実行した。

あるランでメモリの問題が発見された。エージェントは再現手順を特定し、修正を提案し、検証した。これはすべてユーザーへのリリース前の開発段階で行われた。この修正によって、繰り返しのストレスセッションにおける端末上のメモリ増大とページフォルトが大幅に改善された。

結果

• 品質の早期担保： 前述のメモリ問題を開発中に検出・修正。メモリ使用量とページフォルトをおよそ半減させた
• 開発速度： Forumは8週間でFacebookグループとのコア機能パリティに到達。AIが定型的な実装の多くを担い、エンジニアはアーキテクチャ、プロダクト判断、品質に集中できた
• ローンチ後の持続性： リリース後も、エージェント主導の調査がユーザーフィードバックのトリアージと根本原因分析を支援している

うまくいったこと・うまくいかなかったこと

記事では「What Worked / What Didn't」を図にまとめているが、本文中に言及された内容から主要な項目を以下に補足する。

うまくいったこととしては、モジュール化された明快なアーキテクチャの維持、エージェントに「説明」ではなく「ツール」を与えるアプローチ、ビルドフレーバーによるプロトタイプと本番の物理的分離、そしてストレスシナリオによる自動テストの定期実行が挙げられている。これらはいずれも「プロンプトを工夫する」方向ではなく、エージェントが動く環境そのものを整えるという発想に基づく。

うまくいかなかったことの代表例が、エージェントがアプリ内の自分の位置を見失う問題だ。コンテキストが不十分なまま指示を出すと、意図とは異なる画面やコンポーネントを編集してしまう。また、弱いコードパターンを放置すると同じ問題がセッションをまたいで繰り返される点も課題として挙げられている。

一方で、製品として何が良い状態かを定義することは人間が担い続けたと明記されている点が重要だ。「何を目指すか」はエンジニアリングではなくプロダクト判断であり、システムに自己定義させるものではないという姿勢が一貫している。

詳細はHow Meta Built Forum With AI-Native Engineeringを参照していただきたい。