2026 ~ 現在

enqor のアプリアイコン

enqor

1:1の専門家相談サービス

enqor

参加人数
3人
開発期間
2026.04 ~ 現在
担当
アプリおよびサーバーの開発
主な技術
Agora(ストリーミング), NestJS(GraphQL), Expo

Highlights

Motivation

最近は、悩みがあるとまず ChatGPT に聞きます。ところが、いざ心が乱れているときは AI 特有の心のこもらない受け答えにすぐ疲れてしまい、医療や受験のように責任の伴う相談では、AI の答えをそのまま信じるのも難しいものでした。人と話すべき会話は、まだ残っています。

医師のような専門家から恋愛経験の長い人まで、それぞれが自信のある分野で他の人の悩みを聞き、収益を得られる場が必要だと考えました。会話プラットフォームを開発するために Align Networks に参画し、アプリとサーバーの開発を担当しています。ただし、enqor は人が直接プログラミングしたものではありません。企画書とデザインを AI エージェントが読めるようにし、エージェントが出した成果物を検証する環境を作ることが私の仕事でした。

Architecture

安定して通話がつながっている間だけ、秒単位で課金する

enqor の中核となる機能は、ビデオ・音声通話です。ストリーミングは Agora を使ったので難しくありませんでしたが、課金のパイプラインは自分で作らなければならない課題でした。モバイルは通信状態が悪くなることが多いため、正常につながっていた時間の分だけ課金する必要があり、さらに秒単位の課金まで求められました。

ping で定義した安定した通話

まず、「安定した通話」とは何かを決めなければなりません。これは、サーバーとクライアントがやり取りする ping で定義しました。どちらか一方の参加者でも ping が3回届かなければ接続に問題があると判断し、課金を止めます。7回届かなければ通話が切れたと判断し、セッションを終了するようにしました。

次の問題は、毎秒課金という要件です。最初は、通話時間全体から不安定だった時間を引き、通話が終わった後にデータベースを一度だけ更新するつもりでした。ところが、要件が思った以上に複雑でした。通話中にアプリ内通貨のクラップをチャージできる必要があり、チャージしたクラップで互いにプレゼントもでき、通話可能な時間が20秒未満になれば、もうすぐ通話が終わることも知らせなければなりません。チャージ、消費、照会がすべてリアルタイムで行われる必要があるため、残りのクラップを読み書きの軽いどこかに保存して処理するのが簡単だと判断しました。

通話セッションの残高

通話が始まると、発信者のクラップ残高を変更できないようにします。現在の残高を読んで Redis の通話セッションに複製しておくと、この値が通話中に発信者が使える残高の基準になります。毎秒この値を減らして課金し、チャージやプレゼントがあればこの値を更新し続けます。チャージは決済の記録を残す必要があるので、DB にも別途残します。残りの通話時間も、この値をもとに計算してクライアントに返します。通話が終わったら、残高を DB に書き戻します。チャージとプレゼントを除けば、通話1件あたりの DB 操作は開始と終了の2回だけなので、複雑なロジックを直感的に実装できるようになりました。

AI の成果物を、人手をボトルネックにせずに検証する

企画チームが作成したファイルは、PDF の企画書と、Figma で作られたデザインファイルです。人が読んで直すには便利ですが、そのままエージェントに渡すと、どの Figma ノードにどんな説明が入っているのかがわかりません。そこで Figma のノードと PDF のページを自分で対応づけて Markdown で書き、ところどころにメモも書き込みました。

企画書からコードまで

こうして完成した約800行の企画書をもとに、AI エージェントにプロジェクトを最後まで完成させるよう指示しました。30分ほどでプロジェクトが一つできあがりましたが、実行してみると結果はめちゃくちゃでした。ある程度は予想していましたが、起動すらしないとは思わず、なんとか直してログイン画面に入ると、Figma で定義したデザインはまったく反映されていませんでした。ログインのような機能もすべてモックで実装された、まったくのでたらめなプロジェクトでした。

この問題を顧問に相談したところ、「ハーネスエンジニアリング」という概念を教わりました。ネットで検索してみると、「AI が正しい行動を取れるように環境を作ること」という曖昧な答えしか出てきませんでした。概念を完全には理解できませんでしたが、顧問の助言を受けてフック、批判的レビュアー、テスターを一つずつセットアップしていくうちに、いつの間にか自分だけのハーネスができあがっていました。

ハーネスで一番難しいのは、「成功条件」を定義することです。たとえば Figma で定義されたデザインどおりに画面を実装できたかを判定するには、そのデザインと実装された画面が一致しているかを評価するロジックが必要です。最初はアプリの画面をキャプチャして似ているかどうかだけを調べ、独立したサブエージェントがこの比較を担当しました。悪くはありませんでしたが、良い成果物とも言えませんでした。あちこちでアイコンが違い、テキストの位置がずれていました。何より、アプリの画面をキャプチャして Figma と照らし合わせる作業がとても遅く、トークンを大量に消費しました。

先にウェブで画面を組むハーネス

この問題は expo web で解決しました。まず実装したい画面を expo web で動かせば、ヘッドレスブラウザを開いて実装の状態を難なく確認できます。ウィンドウサイズを変えるだけで、モバイル・タブレットの解像度で崩れる部分がないかもすぐにわかります。こうしてウェブでの実装が終わったコードをアプリに移す順番に変えると、評価のコストが大きく下がりました。Figma とウェブ上の画面がどれだけ似ているかは批判的エージェントが判定しますが、アイコンを自分で生成できないようにルールを入れ、Figma MCP に問題が起きて動かない場合はハーネスがそもそも止まるようにする preflight の手順も追加しました。その結果、シンプルな画面はほぼ完璧なレベルで、複雑な画面も70%ほどの完成度で仕上がりました。

Retrospective

今回の経験で、AI に良い資料と環境を与えれば、それに見合う結果が出るとわかりました。そして AI が生み出した結果も、「どう」検証するかより「どこまで」検証するかを考えるほうが正しいと感じました。

金融、宇宙産業、防衛産業のように、一度の事故が惨事になるドメインでは、すべてのコードを隅々まで検証しなければならないでしょう。しかし今回のプロジェクトのように、ほとんどはそうではありません。開発者は、AI が今何をしていて、この作業が終わったらどこまで検証すべきで、どのファイルが変わることを期待しているのか、その程度を把握していれば十分だと考えています。その中でも、AI がしているのが単純な作業であれば何度か触ってみてテストを終えることもできますし、中核のロジックであれば設計まで細かく議論する必要があります。

開発者がコードを書く人から、判断して責任を負う人へと変わったことを、このプロジェクトで確かめました。