AIで、開発の速さとコストの前提は変わりました。僕たちはホーチミンの開発チームごと、その前提に組み替えています。何をAIに任せ、何を人が握っているか——工程別の実測を、このページでそのまま公開しています。
ただ、オフショア開発がうまくいかない理由は、昔から変わっていません。ブリッジSEを置いた。日本語の窓口もいた。それでも動かなかった——問題は翻訳ではなく、PMの不在です。誰かが全体の責任を持って動かないと、「正しく作った」と「使えるものができた」が一致しない。リノエッジのITディレクターは、その役を担います。
関わり方は2つ。御社専属チームを持つラボ型と、プロジェクト単位で完結させる受託。どちらもPMをAIで拡張する同じ体制で、チーム組成は最短2週間、人月40万円からです。仕様が固まっていない段階からで構いません。

こんなお悩みありませんか
日本側の担当者が、画面遷移図も作り、備考欄に注意点も書き、ミーティングで口頭でも補足した。ブリッジSEは「わかりました」と言っている。議事録も上がってきた。
でも、本当に伝わっているか、確信が持てない。
実装が上がってくると、並び順が違う。ステータスの表示が違う。エラーメッセージが違う。一つひとつは小さい。でも積み重なると、1ヶ月のスケジュール遅延になる。
この話、オフショア開発を経験した人のほぼ全員がしてくれます。パターンは大体3つです。
01 / 仕様と品質
できあがったものを見たら、動いてはいる。でも「なんか違う」
ITディレクターがPMとして入るので、認識のずれを設計段階から潰せます。通訳係を挟まないから、技術的な議論が表面的にならない。「聞けなかった」が起きにくい構造です。
02 / チームの継続性
案件ごとにチームが変わって、毎回ゼロから説明する
受託開発の構造上の問題です。ラボ型は専属チームが固定されるので、文脈が途切れません。「また一から」がなくなります。
03 / コミュニケーション
海外チームに指示を出すのが不安で、結局うまくいかなかった
どこで認識がずれるかを知っているかどうかの差です。ホーチミンで開発を回し続けながら、ずれやすいポイントを先回りして設計に入れています。
AI-Driven Development
AIの世界では、大前提が一週間でひっくり返ることが、たびたび起きます。だから僕たちは、「最新のやり方」を売り物にするのをやめました。どんな手法も、すぐに古くなるからです。代わりに決めているのは、変わり続ける前提で、チームと工程を組むこと。下の表は、いま何をAIに任せ、何を人が握っているかの、今日時点の答えです。前提が変われば、書き直します。
| 工程 | AIに任せていること | 人が握っていること | 実測の変化(自社・直近の案件) |
|---|---|---|---|
| 要件定義 | ヒアリング内容の構造化・仕様書ドラフト・見落とし観点の列挙 | 「何を作らないか」の判断・優先順位 | 仕様書の初稿が3日 → その日のうちに |
| 設計・プロトタイプ | 動く画面の先行生成・技術選定の比較材料 | アーキテクチャの最終判断 | 初回ヒアリングから約1週間で動くデモが標準に |
| 実装 | コーディングの大部分(全エンジニアがClaude Code / Cursorを常用) | 仕様との一致確認・エッジケース | スプリント消化量は実質 約3倍(下記※) |
| レビュー・テスト | 静的検査・テスト観点の網羅チェック | テスト仕様書の設計・受け入れ判断 | 管理工数はむしろ増加(それでも差し引きで上の数字) |
| ドキュメント | 議事録・仕様書・引き継ぎ資料の生成と更新 | 「何を残すか」の基準 | 属人化リスクの低減(FAQ「退職時」参照) |
※ コードが出てくる速さだけなら、3倍どころではありません。ただ、テスト・セキュリティ確認・レビューの工数は逆に増えます。それを差し引いて「実質3倍」。速くなった分の一部を、確認の密度に払い戻しています。数字より大きいのは、仕事の質が「書く」から「確かめて判断する」に変わったことだと考えています。
僕たちも最初から線引きができていたわけではありません。実際に、事故を起こしています。
AIエージェントに任せていた作業で、ステージング環境のデータベースが丸ごと消えたことがあります。幸い本番ではなくステージングでしたが、画面が真っ白になったときの感覚は忘れられません。原因をたどると、AIの性能の問題ではなく、「AIが触ってはいけない領域」を人の注意力だけで守ろうとしていた僕たちの設計の問題でした。以来、AIが触ってはいけない領域は権限の仕組みで物理的に守り、その上で人の側の最終責任を明確にしています。ルールを増やすのではなく、事故が構造的に起きない形にする——このやり方は、僕たちの他の品質の仕組みと同じです。
線引きの根拠は、体験だけでなく2026年時点の数字とも一致しています。
「AIで人を減らす」ではなく、
「AIで、PMと品質の密度を上げる。」
AI導入・活用そのものの支援はAI内製化支援で。このページは「AIで開発チームがどう動くか」の話です。
「PMがいない」ことが、ここでの最大の問題です。
翻訳者ではなく、ITディレクターがPMとして直接動きます。仕様の決定から、チームへの指示、品質管理まで一本化。さらにAIツールでPMの質を担保することで、人依存のリスクを減らします。
Why Linnoedge
ベトナムのオフショア開発会社は、本当にたくさんあります。どこも「高品質」「低コスト」「日本語対応」と書いてある。違いが分かりにくいと思います。リノエッジが違うのは、以下の3つの構造です。
多くのオフショア会社では、日本側と開発チームの間にブリッジSE(通訳係)を挟みます。リノエッジのITディレクターは違います。スケジュール管理・要件整理・チームコントロール——プロジェクト全体の責任者として動きます。
「間に通訳がいます」ではなく、「PMがいます」という体制です。
ITディレクターがプロジェクトを管理するとき、AIドリブンのPMツールが並走しています。担当は開発ではなく、管理のほうです。お客様の要望の一つひとつが、いま調査中なのか、実装中なのか、受け入れ確認待ちなのか——ステータスを漏れなく追跡し、止まっているものを人より先に検知します。
効果が一番はっきり出るのは、複雑なプロジェクトです。上の「AIドリブン開発」がコードを書く速さの話だとすれば、こちらは「PMの見落とし」をなくすための仕組みです。
「この人が頑張るから品質が出る」は再現性がありません。担当者が変わったとき、チームが拡張したとき、同じ品質が出るかどうかが問題です。
リノエッジでは、要件整理の段階からテスト観点を設計し、テスト仕様書を作成したうえで開発を進めます。品質の判断基準を先に見える化することで、「人が変わったら品質が落ちた」を構造的に防ぎます。
構造の違い
一般的なオフショア会社
要件が層を経るたびに薄まる
リノエッジ
PMが全体責任を一本化する
規模は大きくありません。だから、PMが直接動けます。
Service
ラボ型は、御社専属のチームを海外に持つ形。チームが固定されるので文脈が積み上がり、開発力が資産になっていく——ストック型の関わり方です。受託は、決まった仕様をプロジェクト単位で完成させて納品する、フロー型の関わり方。どちらが上ということはなく、御社の案件がいまどの段階にあるかで決まります。
| 項目 | 受託開発 | ラボ型開発 |
|---|---|---|
| 契約形態 | 成果物に対する契約 | 人材 × 期間に対する契約 |
| 仕様変更 | 追加費用が発生しやすい | 契約期間内は柔軟に対応 |
| チーム | 案件ごとに編成・解散 | 専属メンバーが継続 |
| ノウハウ蓄積 | プロジェクト終了で失われやすい | チームに蓄積していく |
| コスト予測 | 見積もりベース(変動あり) | 月額固定 |
| 向いているケース | 仕様が確定した短期案件 | 継続的な開発・改善が必要な案件 |
迷ったときの目安。仕様が固まっていて、作るものと期限が明確——受託が向いています。作りながら育てたい、リリース後も保守・改善が続く——ラボ型が向いています。境目の案件も多いので、最初の相談で「どちらが現実的か」から一緒に整理します。
受託の場合も、進め方の骨格はラボ型と同じです。要件整理の段階からテスト観点を設計し、テスト仕様書を作ってから開発に入る。週次デモで途中経過を見てもらう。下の事例にあるクリニクイック(体制4名・6ヶ月で企画から導入まで)のように、期間を区切って一気通貫で完結させたプロジェクトは、この形で進めてきました。
ラボ型の体制は、3種類から選べます。
Type 01
御社のPMが、ベトナム側のITディレクターに直接指示を出す体制です。オフショアの経験がある方には、これが一番シンプルです。
Type 02
ベトナム人ITディレクターが日本に常駐します。御社PMとのやりとりは日本語です。海外チームとの仕事が初めてでも、進めやすい体制です。
Type 03
リノエッジの日本人PMが、御社PMと連携して動きます。上流の要件定義・設計から入るので、「何を作るべきかの整理から手伝ってほしい」というケースに向いています。
Process
最初のミーティングは、契約の場じゃありません。御社が今何に困っていて、何をやりたいのかを聞かせてもらう場です。
「要件がまだ固まっていない」「何から始めればいいか分からない」という段階でも構いません。むしろ、見えていないものに優先順位はつけられない。何が課題で、何から手をつけるべきか——それが整理できていない状態でコードを書き始めても、あとから「そもそも」が出てきます。
どのくらい現状が整理されているかによって、3つのレベルから選べます。いずれのレベルも最大4週間・費用ゼロで行います。「どれにするか」は最初の相談で一緒に決めます。
Level 1
初期適合性確認
Level 2
Rapid Discovery
Level 3
Strategic Discovery
話を聞いたら、AIを使って動くイメージを先に作ります。文字で100回やりとりするより、画面を1枚見るほうが早い。本格的にコードを書き始める前に「これでいいのか」を確認できるので、あとからの手戻りが大幅に減ります。
チーム構成が決まれば、最短2週間で動き出せます。開発中は週次で進捗を共有します。仕様変更やフィードバックには都度対応する。作って終わりではなく、一緒に育てていく形です。
コミュニケーションは、Slack・Teams・Chatwork・Google Chat、御社が普段使っているツールに合わせます。
実際にユーザーが使い始めてから見えることのほうが多い。ラボ型の一番の良さは、この改善サイクルを専属チームで回せることです。チームが変わらないから、文脈が途切れない。同じコードベースを同じメンバーが継続的に改善していくので、回すたびに理解が深くなり、スピードが上がります。
プロジェクトを「完了させる」だけなら、受託でもできます。でもリリース後にどれだけ速く改善できるか。そこが、事業の成果に直結するところです。
Cost
まず小さく始めて、進行に応じて体制を拡張することもできます。
人月 40万円 から
PM + 開発者1名の最小体制から対応。体制規模・スキルセット・日本語支援の有無で変動します。
一般的な体制はPM + ディレクター + シニアエンジニア + 開発者3名くらいの構成が多いです。新規開発か保守改善か、必要なスキルで実際の費用は変わります。
初回ヒアリングで、目的に合った現実的な体制と概算をお出しします。最初の相談に費用はかかりません。
コストについて、会社としての基準を先に書いておきます。
単価:リノエッジのエンジニア単価は人月40〜60万円。日本の国内受託相場(80〜120万円)のおおむね半分です。
総コスト:立ち上げ・コミュニケーション工数を含めた総コストでは、約35%の削減が実感値です。単価差ほどには縮まりません——それを含めてご判断ください。
| 雇用・調達形態 | 月額目安 | 費用の性質 | 採用コスト |
|---|---|---|---|
| 自社採用(国内) | 約70万円〜 | 固定費 | 約100〜150万円 |
| 派遣 | 約80万円〜 | 変動費 | 0円 |
| ラボ型開発(リノエッジ) | 40万円〜 | 変動費 | 0円 |
| 自社海外拠点設立 | 状況により変動 | 固定費 | 数百万〜 |
※ 月額は目安。スキルセット・体制規模により変動します。
| 体制 | 構成 | 月額目安 | 向くケース |
|---|---|---|---|
| スモールスタート | ITディレクター + エンジニア1名 | 70〜90万円 | PoC・MVP・まず試す |
| 標準体制 | PM + ITディレクター + エンジニア3名 | 160〜200万円 | 継続開発・機能拡張 |
| 中規模 | PM + ITディレクター + エンジニア5名 | 250〜300万円 | 並行開発・大規模改修 |
※月額は目安。スキルセット・日本語支援の範囲で変動します。初回ヒアリングで現実的な体制と概算をお出しします。
営業の場で必ず出る質問なので、先に書いておきます。
下がる部分と、下がらない部分があります。実装のスピードが上がった分は、同じ予算でより多く作れる方向に効きます。一方で、AIが速くなるほど「何を作るべきか」「できたものが本当に正しいか」を判断する人間の仕事は増えます。僕たちはそこ(PM・レビュー・テスト設計)に人の時間を寄せ直しています。
つまり「同じものを安く」より、「同じ予算で、より多く・より確かに」の方向です。時間を売るラボではなく、成功させるためのラボを選んだので、この配分を基本にしています。
Compare
選択肢は、僕たちを入れて4つあります。どれが向くかは、御社がいまどの段階にいるかで決まります。だから、リノエッジに不利なことも含めて、そのまま表にしました。
| 国内SIer | 大手オフショア | 社内でAIツール内製 | リノエッジ(ラボ型・受託) | |
|---|---|---|---|---|
| 得意 | 日本語で全部おまかせ | 大人数の確保 | 小さく速く試す | 仕様が固まる前からの伴走 |
| コスト構造 | 高単価・固定 | 中〜低単価・層が厚い分の間接費 | ツール代のみ・ただし人の時間 | 人月40万円〜・変動費 |
| 難しいところ | 費用と小回り | 担当が遠い・要件が層を経るたびに薄まる | 動くものはできるが、保守・品質・セキュリティを誰が握るか | 50名規模の大量確保・「技術に一切関わりたくない」案件 |
| 向くケース | 全部委任したい | 大規模・長期 | PoCを今週中に見たい | 継続開発・改善を回したい |
3列目は、実際に増えている選択肢です。AIコーディングツールで動くものは作れます。ただ、動いた後——保守・品質・セキュリティの責任を誰が持つかは、ツールでは解決しません。そこで詰まった段階でご相談いただくケースが増えています。
なお、この4類型の中間もよくある形です。受託契約での単発開発も、御社の内製チームとの併走も、実際にお受けしています。表は「どれか一つを選ぶ」ためではなく、話を始める前の地図として置いています。
Cases
詳細を公開できるものだけ掲載しています。
企画から設計・インフラ構築・導入サポートまで一気通貫(体制4名・6ヶ月)
ある医療施設では、ネット予約と来院予約が別々の仕組みで動いていました。現場のスタッフがそれを手作業で突き合わせていて、患者さんの待ち時間が長くなる。問い合わせの電話も鳴り止まない。
やったことは、ネット予約と来院予約を一つにまとめ、待ち状況をリアルタイムで患者さんに通知する仕組みを作ること。企画から設計、AWSのインフラ構築、導入のサポートまで担当しました。
PHP (Laravel) / MySQL / AWS
3年で40万組のマッチングが成立
経営者同士のビジネスマッチングは、それまで紹介ベースが中心でした。「会いたい人に会えるかどうか」が人脈の広さで決まってしまう。その構造を変えたいという相談から始まったプロジェクトです。
企画・UI設計からシステム全体の構築、運用保守まで担当しました。AIのマッチングアルゴリズムを作り、毎日5人の経営者を自動で紹介する仕組みにしています。3年で40万組のマッチングが成立しました。
Flutter / PHP / NoSQL / Firebase Auth / WebSocket
AI機能の実装から運用まで専属チームで対応(体制2名・8ヶ月)
オンライン教育って、コンテンツを並べるだけでは成り立たないんです。学習者一人ひとりの理解度に合わせて、次に何を学ぶべきかを提示できるかどうかが鍵になる。
AIを使って学習体験をパーソナライズする仕組みの開発を支援しました。EdTech領域で、新しい学びの形を技術面から作ったプロジェクトです。
Honest Note
合わない仕事を受けても、お互いの時間がもったいない。はっきり書きます。
01
僕自身、前の会社で150人の開発組織をゼロから作った経験があります。大きくすることはできます。ただ、規模を追うと一人ひとりのプロジェクトへの関与がどうしても薄くなる。それが嫌で、リノエッジを作りました。大規模な人員が必要な場合は、大手のオフショア開発会社のほうが向いています。
02
仕様が固まっている案件は、受託でお受けしています。ただ、最安値の入札競争には参加しません。テスト仕様書を先に作る・週次デモで確認するといった品質の構造は、受託でも外さないからです。価格だけで選ぶなら、もっと安い会社はあると思います。
03
リノエッジは、御社の担当者にも技術的な判断にある程度関わってもらうスタイルです。「全部おまかせ」がいいなら、国内のSIerのほうが期待に合うかもしれません。
04
AIで調べて、仮説を持って来ていただくのは歓迎です。話が早くなります。ただ僕たちは、AIの答えをそのまま検証するだけの仕事は受けないと決めています。中身を理解して答えるから、結果に責任が持てる——その分、時間はかかります。答え合わせの速さを最優先する場合は、合わないと思います。
AI & Offshore
最近、本当によく聞かれます。当事者として答えます。
半分はその通りです。「仕様書を渡してコードが返ってくるだけ」の開発は、AIで置き換わっていきます。指示待ちの人月商売は、たぶん要らなくなります。これは僕たち自身も例外ではありません。
でも実際に起きているのは、開発の外注が減ることではなく、外注に求められるものが変わることです。僕たちに来る相談も、AIが広がってから減ったのではなく、中身が変わりました。減ったのは「作業の切り売り」で、増えたのは「何を作るべきかから一緒に考え、AIを織り込んだ体制ごと提供するパートナー」への相談です。
もう一つ、現場で起きている変化があります。発注する側も、AIで動くものを作れるようになりました。前提が一つ変わったのだと思います。ただ、AIで「できそう」に見えるものと、事故なく運用し続けられるものの間には、まだ大きな距離があります。ちょっとしたミスが、AIのスピードのせいで、より大きな事故につながりやすくもなっている。だから僕たちは、お客様ができることが増えるスピード以上に、セキュアに運用する仕組みの側を先回りして作り続ける必要があると考えています。
デモまでなら、AIはほとんど何でもできます。事故なく運用し続ける段になると、何でもはできない。この距離を測った上で体制を組むのが、いまのオフショア開発の仕事だと考えています。
僕たちがこのページで工程やコストの中身まで見せているのは、その変化に賭けているからです。途中経過まで見てもらったほうが、判断が早いと考えています。
まず測ってみる
いきなり相談するのは気が重い、という方へ。御社がオフショア開発に向いているか、費用がどう変わるか。その場で測れる無料ツールを2つ用意しています。結果を持って壁打ちに来ていただくと、話が早く進みます。
御社に専属チームを置く——それが合う会社もあれば、まず要件整理から、という会社もあります。30分の壁打ちで「今どこが詰まっているか」を聞いて、どの進め方が現実的かを一緒に考えます。提案書より先に話します。

今、自分の会社をAI実装の実験台にしています。経営のほぼ全部をAIと組んで回す試みを始めて数ヶ月。一日の仕事でAIを使わない時間の方が少なくなっています。
何が動いて、何が動かないか——自分たちで先に試して、先に失敗してから御社に持っていく。それが原則です。
FAQ
比較検討の初期段階でよく聞かれる順に並べました。
このサービスは「作って納品して終わり」にも、「御社チームだけで回せる状態まで伴走する」形にもできます。内製化まで持っていきたい場合 → AI内製化支援
We use cookies to improve your experience on our site. By using our site, you consent to cookies.
Manage your cookie preferences below:
Essential cookies enable basic functions and are necessary for the proper function of the website.
These cookies are needed for adding comments on this website.
Statistics cookies collect information anonymously. This information helps us understand how visitors use our website.
Google Analytics is a powerful tool that tracks and analyzes website traffic for informed marketing decisions.
Service URL: policies.google.com (opens in a new window)
Marketing cookies are used to follow visitors to websites. The intention is to show ads that are relevant and engaging to the individual user.
Google Maps is a web mapping service providing satellite imagery, real-time navigation, and location-based information.
Service URL: policies.google.com (opens in a new window)
You can find more information in our Cookie Policy and Privacy Policy (ja).