Qoder を活用して AI ネイティブな開発システムを構築し、1人と Qoder で、従来20人が3か月かけていた MES 製品を2か月で完成させた実践を紹介します。
皆さん、こんにちは。Guanjiapo Huihuang AIMES で製品技術責任者を務めている Li Yuzhong です。AI がプログラミングの世界を席巻する現在も、多くの開発者は様子を見続けているか、「AI が生成するコードは不安定だ」と不満を感じています。22年の経験を持つ「ベテランプログラマー」として、私は、以前なら20人のチームが3か月かけていた仕事を、1人で完成できると考えています。これは空想ではなく、AI 時代の「エンジニアリング規律」を再構築した結果です。
初めて AI プログラミングを使う人の多くが不満を抱くのは、AI を「神」のように扱うからです。しかし実際には、AI は非常に強力な能力を持ちながら、業務上の直感をまったく持たない「インターン」です。
AI にコーディング指示だけを投げ、意図を推測させれば、通常は混乱した結果になります。AI はあなたの業務も、企業が30年間蓄積してきたロジックも理解していません。そのため、「コーダー」から「アーキテクト」への移行は、すべての開発者が通るべき道です。仕事の中心は、コードを書くことから「指揮すること」と「定義すること」へ変わります。
使い始めた当初、私は多くの遠回りをしました。高速に動くことしか理解しておらず、Rules や Skills の書き方を知りませんでした。最初は10万を超える Credits を消費し、1日に8,000元以上使ったこともあり、その時は素晴らしいと感じました。しかし後になると、AI は自分で作ったものすら修正できず、作業を続けられなくなりました。前段階の準備がほとんどできていなかったためです。
その後、ERP の非常に重要な一部である MES（Manufacturing Execution System）を再構築しました。私1人と Qoder だけで2か月かけて製品を作り、すでにデモと販売を始めています。
Qoder の利点は次のとおりです。
企業が AI を導入する際の最大の問題は「AI が不安定」であることではなく、「人間の指揮能力」です。
社内で「AI は不安定だ」と言う人がいる場合、多くは AI を使いこなせていません。AI は仕様に従って実行するツールであり、出力品質は入力するルール（Spec）の精度に直接左右されます。AI は強力な「インターン」ですが、信頼できる「エンジニア」ではありません。実行能力は非常に高い一方、業務経験と全体的な視点が不足しています。したがって、信頼しつつ必ず検証してください。AI に意図を推測させてはいけません。新しいチームメンバーとして扱い、制度化・標準化された方法で管理して初めて、「1人が10人分の仕事をする」という効率変革を実現できます。
最初は SDD が何か分かりませんでした。しかし使ってみると、仕様を書かなければ後で AI が役に立たなくなることが分かります。修正を依頼しても直せません。ルールのない古い「スパゲッティコード」を AI に渡しても、内部がすべて誤っているため正しく処理できません。ソフトウェアエンジニアリングの本質は何でしょうか。ルールに従って作業することです。コンピューターの中核は入力、計算、出力です。ルールに基づく入力がなければ、ルールに基づく出力を得ることはできません。
AI コーディングの中核は「仕様の精度」です。SDD は、従来の開発要件を極めて正確なエンジニアリング仕様書へ変換します。
コードを生成する前に、フィールド型、検証ルール、UI 表示などを定義する必要があります。提供する「制約」が詳細であるほど、AI の成果物の品質は高まります。Spec を作成した後は、完全なテストケース一式も同時に生成するよう AI に要求します。自動化されたクローズドループ検証を実現し、人間がバグを繰り返し探す作業を避けます。
明確な Spec で AI の動作を制約すると、抽象的な要件が実行可能な境界になります。これは AI の規制だけでなく、チームの開発ロジックの再編でもあります。制約がなければ品質はなく、ルールがなければ AI はあなたの誤りを繰り返すだけです。
個人ツールからチームのインフラストラクチャへ進むには、Skills が不可欠です。ERP は結局、基本情報、伝票、レポートの3つに集約できます。新入社員が来たら、製品情報を完成させ、「取引先については私の例に従ってください」と伝えます。これが Skill です。
Skills は複雑な業務ロジックを、AI が呼び出せる「モジュール化されたスキル」として抽象化します。その本質は、長年蓄積してきた業界経験、コーディング習慣、アーキテクチャ上の意思決定を、AI が理解して実行できる「エンジニアリング運用マニュアル」に固定することです。構築方法は、まず深い対話によって AI に1つの伝票（購買発注など）を完成させ、そこから汎用的な Skill を抽出します。後で類似タスク（販売注文など）を行う際は、その Skill を直接呼び出し、数分で完了させます。
Skills は固定されたものではありません。週次のまとめと振り返りを通じて改善し続ける、個人とチーム双方の中核資産です。
Memory は、異なる業務シナリオ間で AI の「コンテキストが途切れる」問題を解決します。
人間の従業員と同じように、AI にもプロジェクトの「記憶」が必要です。プロジェクトが複雑になるほど、Memory によって AI はバージョン10.0と11.0の違いを理解し、忘却や論理的な混乱を避けられます。
Memory は本質的に、特定のフォルダ構成などの構造化データです。この Memory をコピーすれば、新しいプロジェクトに古いプロジェクトの業務能力をすばやく継承し、シームレスに知識を移転できます。
個人の Memory からチームの Memory へ：Memory は個人だけに属するのではなく、チームで共有する知識資産であるべきです。
Rule で最低限の境界を守り、Memory で基準を記録し、Skill で能力を提供します。この3層が連携して初めて、完全な AI Coding エンジニアリングになります。
● コンテキスト汚染：プロジェクトの反復に伴い、長期間続く会話には冗長な情報や矛盾が生じます。教訓：定期的に整理し、現在の Rule、Memory、Skills に基づいて再構成するよう AI に要求します。
● AI のハルシネーション修正ループ：同じ問題を3回試しても解決できない場合、AI は思考の行き止まりに陥っています。教訓：適切なタイミングで会話ウィンドウを切り替え、頑固に続けず、「別の角度から伝える」ことを学びます。
● ルールの逸脱：監督されていない AI は、あらかじめ定めたコーディング標準から簡単に外れます。教訓：SQL インジェクション防止やコーディング標準など、必須の「レッドライン」ルールを設定し、速度のために最低限の境界を破らないようにします。
● 過度な依存：AI が書いたものに誤りはないと考えるのは非常に危険です。教訓：必須の Review プロセスと、重要モジュールに対する人間のレビューを徹底します。
AI に意図を推測させてはいけません。伝票を作る際、私は構造、型、検証ルール、割引の表示方法を定義します。その後 Qoder に読み込ませ、ルールに従ってフロントエンド、バックエンド、インターフェースを作成し、テストを実行させます。これはコードを書くだけではありません。最も素晴らしいのは、現在では業界ソリューションもすべて AI と一緒に作成していることです。AI が私の知識体系全体を持っているからです。
多くの人は AI が不安定だと言います。同僚がまだ「AI は頻繁にハルシネーションを起こす」と言っていても、それだけを信じないでください。使い手が AI を指揮できていない可能性があります。Spec を適切に書けば、出力品質は非常に高く、従来のチームを上回ることさえあります。基準に従って作業するとき、AI の実行能力は極めて強力です。
私1人と Qoder で、20人が3か月かける仕事に相当する成果を出しました。長年この道を歩いてきて最も強く感じるのは、人生の次元が拡張されたことです。以前は80歳になってようやくできると思っていたことを、50歳までに終えられるかもしれません。以前は5年かけてプロジェクトを検証して失敗していましたが、今は数か月で成功の可能性を判断できます。
技術の変化はビジネスの変化をもたらし、ビジネスが変化して初めて機会が生まれます。20年前は夜更かししてコードを書き、10年前はクラウド移行を進め、そして今日、技術は再び変わりました。起業家の方は覚えておいてください。AI Coding の本質は指揮です。自分の Memory と知識を「プライベートドメインの知識」として AI に与えれば、AI は最強のインターンになります。
アイデアがあれば、多くのものを創造できます。エンジニアリング記録はこれまで以上に重要です。AI の能力が強くなるほど、制約や規約がなければ、期待する方法で動作しなくなるからです。
1. 発想の転換：AI は「万能の神」ではなく「インターン」
初めて AI プログラミングを使う人の多くが不満を抱くのは、AI を「神」のように扱うからです。しかし実際には、AI は非常に強力な能力を持ちながら、業務上の直感をまったく持たない「インターン」です。
2. Qoder を選んだ理由
使い始めた当初、私は多くの遠回りをしました。高速に動くことしか理解しておらず、Rules や Skills の書き方を知りませんでした。最初は10万を超える Credits を消費し、1日に8,000元以上使ったこともあり、その時は素晴らしいと感じました。しかし後になると、AI は自分で作ったものすら修正できず、作業を続けられなくなりました。前段階の準備がほとんどできていなかったためです。
その後、ERP の非常に重要な一部である MES（Manufacturing Execution System）を再構築しました。私1人と Qoder だけで2か月かけて製品を作り、すでにデモと販売を始めています。
- 「モデル選択」より「ソリューションのパッケージ化」が重要 モデル自体は単なるツールであり、Qoder の中核的な価値は「私に代わって選択してくれる」ことです。Qoder チームは市場にある最も強力な大規模モデルを継続的に評価・統合し、成熟したエンジニアリング製品としてパッケージ化しています。この「実践経験のパッケージ」によって、モデルを頻繁に切り替えたり基盤技術を研究したりする手間を省き、現在利用できる最先端の技術を直接使えます。
- 「エンジニアリングによるラッピング」がもたらす効率 AI 開発は本質的にエンジニアリングの問題です。Qoder はモデルのインターフェースにとどまらず、アプリケーション層で深いエンジニアリングを行い、AI の能力と開発者の IDE 環境、プロジェクトのコードベースを密接に結び付けます。この「エンジニアリングによるラッピング」により、AI の出力は単なる会話の水準を超えて高い生産性を持ちます。
- 「費用対効果」の詳細な評価 Qoder を選んだのは、海外製品を崇拝したり流行に追随したりしたからではなく、最適なコストの選択肢だったからです。 時間コスト：最も強力なツールの組み合わせによってコーディング速度が大幅に向上し、バグ数を大きく減らせます。機会コスト：1人が使える時間は1日24時間で一定です。モデルのサブスクリプション費用にこだわるより、可能な限り短期間で製品を作り、市場機会をつかむことがはるかに重要です。導入コスト：人件費と納期を考慮すると、Qoder の計算資源消費は実際のエンジニアを雇うより大幅に安く、合理的なビジネス判断です。
- 先進的な「Experts モード」（Agent）の協調メカニズム Qoder の Experts モード（Agent）は、生産関係を根本から変えました。Leader が指揮し、メンバーが報告し、レビューと修正を行う、実際の人間チームの協調ロジックを再現します。 作業パラダイム：以前は複数のウィンドウを手動で開いて並行作業していましたが、現在は Agent がタスクを自動的に割り当て、内部で検証できます。価値：この仕組みは、複雑なソフトウェア開発タスクを分解、実行、レビューし、人間チームの厳密さを大きく再現します。計算資源の消費は増えますが、出力の安定性と高い品質を考えると、手動で誤りを修正するより経済的です。
3. エンタープライズ導入における中核的な矛盾
企業が AI を導入する際の最大の問題は「AI が不安定」であることではなく、「人間の指揮能力」です。
社内で「AI は不安定だ」と言う人がいる場合、多くは AI を使いこなせていません。AI は仕様に従って実行するツールであり、出力品質は入力するルール（Spec）の精度に直接左右されます。AI は強力な「インターン」ですが、信頼できる「エンジニア」ではありません。実行能力は非常に高い一方、業務経験と全体的な視点が不足しています。したがって、信頼しつつ必ず検証してください。AI に意図を推測させてはいけません。新しいチームメンバーとして扱い、制度化・標準化された方法で管理して初めて、「1人が10人分の仕事をする」という効率変革を実現できます。
4. 中核となる方法論
SDD（Spec-Driven Development）：仕様駆動開発
最初は SDD が何か分かりませんでした。しかし使ってみると、仕様を書かなければ後で AI が役に立たなくなることが分かります。修正を依頼しても直せません。ルールのない古い「スパゲッティコード」を AI に渡しても、内部がすべて誤っているため正しく処理できません。ソフトウェアエンジニアリングの本質は何でしょうか。ルールに従って作業することです。コンピューターの中核は入力、計算、出力です。ルールに基づく入力がなければ、ルールに基づく出力を得ることはできません。
AI コーディングの中核は「仕様の精度」です。SDD は、従来の開発要件を極めて正確なエンジニアリング仕様書へ変換します。
Skills：再利用可能な行動パターン
個人ツールからチームのインフラストラクチャへ進むには、Skills が不可欠です。ERP は結局、基本情報、伝票、レポートの3つに集約できます。新入社員が来たら、製品情報を完成させ、「取引先については私の例に従ってください」と伝えます。これが Skill です。
Skills は複雑な業務ロジックを、AI が呼び出せる「モジュール化されたスキル」として抽象化します。その本質は、長年蓄積してきた業界経験、コーディング習慣、アーキテクチャ上の意思決定を、AI が理解して実行できる「エンジニアリング運用マニュアル」に固定することです。構築方法は、まず深い対話によって AI に1つの伝票（購買発注など）を完成させ、そこから汎用的な Skill を抽出します。後で類似タスク（販売注文など）を行う際は、その Skill を直接呼び出し、数分で完了させます。
Memory：企業の永続的なナレッジベース
Memory は、異なる業務シナリオ間で AI の「コンテキストが途切れる」問題を解決します。
人間の従業員と同じように、AI にもプロジェクトの「記憶」が必要です。プロジェクトが複雑になるほど、Memory によって AI はバージョン10.0と11.0の違いを理解し、忘却や論理的な混乱を避けられます。
Rule + Memory + Skill の3層システム
Rule で最低限の境界を守り、Memory で基準を記録し、Skill で能力を提供します。この3層が連携して初めて、完全な AI Coding エンジニアリングになります。
5. 失敗と学び
遭遇した問題
学んだこと
AI に意図を推測させてはいけません。伝票を作る際、私は構造、型、検証ルール、割引の表示方法を定義します。その後 Qoder に読み込ませ、ルールに従ってフロントエンド、バックエンド、インターフェースを作成し、テストを実行させます。これはコードを書くだけではありません。最も素晴らしいのは、現在では業界ソリューションもすべて AI と一緒に作成していることです。AI が私の知識体系全体を持っているからです。