eSimphony は 5 人のエンジニアリングチームで作られています。製品は 150 か国以上をカバーし、iOS と Android のネイティブアプリを出荷し、複数リージョンにまたがる通信会社統合の基盤を運用し、5 言語を端から端までサポートし、毎週プロダクトの変更を出荷しています。私たちは 1,000 人規模の通信会社ではありません。意図的にレバレッジを効かせて動く小さなチームです。

そのレバレッジは、この 18 か月で身体に染み込ませた特定のエンジニアリングのやり方から生まれています。私たちはそれを AI ネイティブ開発と呼んでいます。実際にどう回しているのかを書きます。

チームのかたち

エンジニア 5 人。プロダクトデザイナー 1 人。いまも製品仕様の一部を自分で書く CEO が 1 人。専任のプロダクトマネージャーはいません。仕様は CEO と Moza を使った下書き、そしてエンジニアリングの判断から生まれます。専任の QA チームもいません。テストは開発ループの一部です。独立した DevOps もありません。インフラは、その機能を出荷する人が持ちます。

自慢ではありません。制約です。この人数で eSimphony ほどの規模の製品を出荷するには、エンジニア 1 人あたりの成果を掛け算するしかありません。その乗数として私たちが選んだのが AI です。

5 段階のワークフロー

eSimphony のあらゆる変更 — 文言の修正から新しい通信会社の統合まで — は、同じ 5 段階を通ります。各段階で AI が支援し、各段階に人間が入ります。

1. 探索(技術的な壁をなくす)

新しい要件が来たとき(「エジプトのカバレッジのために通信会社 X と統合が必要」)、エンジニアが最初にすることは、知らないことを分かったふりで埋めることではありません。AI を使って未知の領域を 2 日ではなく 20 分で探ることです。

実際には、エジプトの MVNO と統合した経験のないエンジニアが、その通信会社の API ドキュメントを AI アシスタントに読ませ、統合面の構造化された要約を得て、細かい条件について追加で質問し(「この市場での典型的な eKYC の流れは?」)、昼食前に工数、リスク、未知の要素をまとめた 1 ページの評価を仕上げられます。

何が変わるのか。ボトルネックはもう「この領域を知るエンジニアがいるか」ではありません。「いまいるエンジニアが AI に支えられて、数時間でこの領域に十分習熟できるか」です。ほとんどの場合、答えはイエスです。

2. 仕様(数週間ではなく数時間)

たいていの会社で、たいていのプロダクト仕様には 1〜3 週間かかります。PM が下書きし、関係者がレビューし、例外条件が足され、受け入れ基準が磨かれ、そしてエンジニアリングが規模を見直す。仕様が「完成」するころには、そもそもの機会は動いています。

私たちのやり方はこうです。エンジニア(機能によっては CEO)が 1 行のプロダクトのアイデアを書く。AI がそれを構造化された PRD へ展開する — ユーザーフロー、例外条件、成功指標、受け入れ基準、未解決の問い。チームは 45 分の作業セッションで磨きます。仕様はその日のうちにエンジニアリングへ渡ります。

引き換えに、この過程から出る仕様は、PM が 2 週間かけた従来型の仕様より少し粗くなります。それは受け入れています。最初の実装までの時間が縮む価値は、残る曖昧さに見合います。曖昧さは着手前ではなく、開発中に解消されます。

3. デザイン(高速なフィードバックループ)

UI の比重が大きい機能では、デザイナーがエンジニアと並走し、「デザイン → 実装 → フィードバック」のループを日単位ではなく分単位で回します。AI で生成したモックアップ(Figma プラグイン + 画像生成)でバリエーションを素早く試します。エンジニアは数時間でプロトタイプを出します。デザイナーは実機で確認します。イテレーションは同日サイクルで測られます。

結果として、デザインとエンジニアリングは順番に並びません。同時に進みます。デザインが「最終版」になるころには、実装はもう本番目前まで来ています。

4. 開発(AI がコードを書き、人間がすべての差分をレビューする)

もっとも目に見える AI ネイティブの部分です。いまの eSimphony のエンジニアリング過程はこうです。

新規コードの約 90% を AI が生成(Cursor、Claude、GitHub Copilot、しばしば組み合わせて)
エンジニアが書くのは、アーキテクチャ上の判断、統合の境界、そして深いシステム理解を要する厄介なビジネスロジック
コードの 100% がマージ前に人間のレビューを通ります。 すべての差分。すべての PR。例外なし。

この最後の点は決定的で、しばしば誤解されます。「AI がコードを書く」は「人間がコードを見ない」ではありません。エンジニアの役割が、実装を打ち込むことから実装をレビューすることへ移るという意味です。仕様に合っているか、例外条件を処理できているか、アーキテクチャに収まるか、スケールするか — この認知的な仕事は今もエンジニアのものです。意図を文法的に正しく慣用的なコードへ翻訳する機械的な仕事だけが委譲されます。

eSimphony の典型的な PR はこんな姿です。

変更行数 200〜800 行(2024 年ごろのチームの一般的な 100〜200 行に対して)
詳細にレビューするエンジニアが 1 人
新規コードに対してカバレッジ 80% 超の、AI 生成のユニットテストが付くことが多い
レビューのコメントは文法ではなくアーキテクチャに集中

5. 出荷(数分で適応する)

出荷は段階的です。リスクのある変更にはフィーチャーフラグ、バックエンドサービスにはカナリアデプロイ、そしてロールアウト後数分以内に異常を浮かび上がらせる AI 監視のテレメトリ。出荷が何かを壊したとき、ロールバックは時間単位ではなく分単位です。

「AI 監視のテレメトリ」には一文添える価値があります。デプロイ後、AI エージェントがエラー率、レイテンシ、ユーザーからの報告、コンバージョンの異常を見張ります。異常がしきい値を越えると、当番のエンジニアに想定される原因の要約とともに呼び出しがかかります。これで検知までの時間が「朝 9 時にユーザーが不具合を報告」から「9 時 3 分にアラートが鳴る」へ縮みます。

数字

直近 12 か月のおおよその指標です。

スプリント周期:1 週間。 新機能は毎週、小さな修正は毎日出荷。
エンジニア 5 人 が製品にフルタイムで従事。ほかにパートタイムの業務委託が 1 人。
新規コードの 90% 超 が AI 生成(主に Cursor + Claude)。
マージされたコードの 100% が人間のレビュー済み。
機能仕様から本番までの中央値:5〜10 日。
四半期あたりの本番障害:1〜2 件。 この規模の製品としては業界平均を下回ります。
エンジニアリングへエスカレーションされるサポートチケット:週 5 件ほど。 ほとんどが同日中に解決します。

これらは机上の数字ではありません。実際のチームの動作テンポです。

これは何ではないのか

eSimphony の AI ネイティブ開発が意味しないことも、はっきり書いておく価値があります。

「雰囲気でコードを書く」ことではありません。 コードは 1 行ずつレビューされます。アーキテクチャの判断は人間が下します。AI が加速するのはタイピングであって、思考ではありません。

「テストをしない」ことではありません。 AI 生成のテストには固有の弱点があり(例外条件より正常系を厚くテストしがちです)、そのためエンジニアが端の条件について手書きのテストを足します。新規コードのテストカバレッジは一貫して 80% を超えています。

「シニアエンジニアが要らない」ことではありません。 逆です。AI はシニアの判断力の価値を劇的に高めます。シニアエンジニアは、自分でゼロから書くより 5〜10 倍速く AI の出力をレビューし磨けるからです。シニアのレビューなしに AI を使うジュニアは、コンパイルは通るが構造的にもろいコードを生みがちです。

「デザインやプロダクトの思考が要らない」ことでもありません。 明確な仕様と、練り上げられたユーザーフローがなければ AI は役に立ちません。「何を、なぜ、誰のために作るのか」という認知の仕事は、人間のままです。

何が必要か

重要な順に 3 つです。

1. 厳格な人間のレビュー

AI が生成したすべての行は、マージ前にシニアエンジニアのレビューを通ります。「明らかに正しい」小さな変更でレビューを飛ばしたくなる誘惑は現実にあり、そして危険です。私たちは 100% レビューの線を守り続けています。

2. 厳密なアーキテクチャのガードレール

AI がコードを生成するとき、それはその場の慣習に従います。強い慣習 = 強い AI の出力。私たちは、明確なモジュール境界、一貫した命名、型のはっきりしたインターフェース、そして「ここではこうやる」という明文化されたドキュメントに多くを投じてきました。AI がきれいにパターンを掴めるようにするためです。

3. AI を既定とする文化的な合意

このチームは、あらゆるワークフローで AI の支援を既定とすることに明示的に合意しています。新しく入るエンジニアも、この前提のもとで立ち上がります。異論(「でも自分で書くほうが好きだ」)は聞き、議論もしますが、チームの規範は「特段の理由がないかぎり、機械的な仕事は AI が担う」です。

AI を使わない領域

AI が生成したコードのレビュー(新鮮な人間の目が欲しいので)
何を作るかの決定(プロダクト戦略は人間のもの)
顧客サポートの直接のエスカレーション(難しい案件は人間が扱う)
人事評価とチームへのフィードバック(人間のみ)
採用の判断(人間のみ。候補者の発掘と書類選考は AI が補助)

型はこうです。AI は実行を拡張し、決定は人間が持つ。

これが製品にとって意味すること

このワークフローの成果は製品に現れています。私たちが出荷してきたもの:

ライフタイム eSIM のアーキテクチャ(多くの企業なら数四半期がかりのプロジェクト)
5 言語対応の AI 旅の相棒 Moza
3 地域にまたがる AI ダイナミックプラン
自動復旧を備えた AI トラブルシューティング
毎週リリースされる iOS と Android のネイティブアプリ
稼働率 99.9% 超のマルチリージョン・バックエンド
製品全面にわたる 5 言語のローカライズ

このリストは通常、エンジニア 30〜50 人と 3 年以上を要します。私たちは 5 人で 18 か月かけて出荷しました。

採用について一言

チームは慎重に育てています。ここで力を発揮するエンジニアには 3 つの共通点があります。

出力量より判断力。 タイピングは AI が担います。私たちが求めるのは、レビューし、決め、形を与えることに秀でたエンジニアです。
AI を同僚として扱えること。 AI を魔法の神託とも、自分の存在を脅かす敵とも見ず、仕事を任せ、レビューし、押し返す相手として扱えるエンジニア。
ユーザーを気にかけること。 AI ネイティブのワークフローは、コンパイルは通るが意味のないコードを大量に生めるほど速いのです。「これはユーザーの役に立つか」にすべての PR を接地できるエンジニアが、いちばん良い仕事をします。

心当たりがあれば、私たちは採用中です。採用ページから連絡するか、Trung に直接メッセージをください。

次に出荷するもの

いまの製品を作ったのと同じワークフローが、ロードマップを出荷しています。

複数 eSIM の管理(2026 年 5 月)
ファミリープラン(2026 年 6 月)
ロイヤルティとリワード(2026 年 8 月)
世界規模の直接キャリア接続(2027 年)

いずれも従来型の通信会社なら数か月がかりのプロジェクトです。社内の見立てでは、この 4 つすべてが同じ 5 人のチームで予定どおり出荷されます。

それがレバレッジです。それが私たちの賭けです。そして、業界まるごとの慣性を相手に、小さなチームが出荷し続ける方法です。

eSimphony を実際に見る、私たちの立ち位置を読む、あるいは MVNO Nation Americas のピッチデックを見る。

5 人のチームが 10 倍の速さで出荷する:eSimphony の AI ネイティブ開発