Hisense は Qoder を活用して完全な AI ネイティブ開発システムを構築し、新規システム開発の効率を3〜4倍に向上させました。
Hisense Group の Digital Quality Center は、グループ内の46社の製品会社にサービスを提供し、研究開発、製造、サプライチェーン、マーケティングなどの領域で100を超える自社開発システムを担当しています。技術スタックは多様で、レガシー資産も多く、1つの開発モデルですべてに対応することはできませんでした。
研究開発チームが最も悩んでいたのは「コードを書けない」ことではありません。新しいメンバーがレガシープロジェクトを引き継ぐと、文書が不足し、知識が分散し、学習のハードルが高いこと、反復作業に多くの時間を費やすこと、オンライン障害の調査に時間がかかり、コードレビューでもすべての潜在的なリスクを検出できないことでした。
2023年に大規模言語モデルが急速に普及したとき、私たちはこれらの問題を解決できる可能性を感じました。しかし当時のプログラミングツールは「局所的な補完」の段階にとどまり、ネットワークの安定性とセキュリティコンプライアンスも大きな障壁でした。
2025年1月、SDD 開発モデルの成熟に伴い、Qoder チームとの製品検討を開始しました。2月には約100人でパイロットを実施し、3月に Qoder を正式導入しました。現在では900人以上が利用しています。
Qoder と従来のツールの本質的な違いは、単なる補完エンジンではなく、完全な AI ネイティブ開発ワークベンチであることです。Rules、Skills、Memory、Repo Wiki、Experts モードによる協調が、AI ネイティブ開発の導入に必要なインフラストラクチャを構成しています。
Qoder の機能体系を中心に、109のシステムで AI を安定して動かすための社内エンジニアリングシステム「Harness」を構築しました。
● ハイコードシナリオ（70%以上） — さらに次の3種類に分類しました。
● カテゴリ A：ゼロからの新規システム開発。Qoder が全工程に参加します。
● カテゴリ B：レガシーシステム上の新規モジュール開発。Repo Wiki で既存コードを理解してから生成します。
● カテゴリ C：レガシーシステムの既存モジュール改修。Agent が作業を始める前に、大量の履歴知識を注入する必要があります。
● ローコードシナリオ — 主に Qoder で設定ロジックとグルーコードを生成します。
● その他のシナリオ — 文書、テストスクリプトなどの補助成果物です。
Qoder の Quest-SDD（Spec-Driven Development）は、要件を直接、実行可能な開発仕様へ変換します。Spec の粒度と明確さは、最初のコード生成の品質を直接決定し、その後に必要な人間と AI の対話回数にも影響します。私たちは2つの実践を行いました。
実践 1：大きな Spec と小さな Spec。 大きな Spec は300行、75タスク、小さな Spec は70行、12タスクでした。結果として、大きな Spec の初回完了率は60%にとどまり、完成までに数十回の追加対話が必要でした。小さな Spec の初回完了率は95%に達しました。
実践 2：同じ PRD を3通りで処理。 Qoder に直接 Spec を生成させると、初回完了率は70%で、その後50回以上の確認が必要でした。エンジニアとプロダクトマネージャーが行ごとに確認して Spec を更新すると、完了率は大幅に向上しました。さらに、人間と AI の認識合わせ（Qoder Agent に質問させて理解を確認する）を加えると、完了率はほぼ100%となり、その後の修正はほとんど不要でした。
この結果から、次の Spec 品質基準を定めました。
● 現在の主流モデルの能力では、1つの Spec は原則として100行以内、最大でも150行以内にします。
● すべての制約をテストケースへ変換できるようにし、要件の明確性と検証可能性を確保するとともに、その後の AI 検証の根拠にします。
● コード生成後、1つの Spec に10回を超える人間と AI の修正が必要な場合、元の Spec の品質が不十分である可能性が高いため、Spec フェーズへ戻って認識を合わせ直します。
AI Coding は AI 自律フェーズへ入りつつあります。その特徴は、フィードバックループを構築して「Human on the loop」を実現し、複数 Agent の協調によって長期タスクを実行し、人間を反復作業から解放することです。Qoder と各種オープンソース Skills により、複数 Agent のフィードバックループを短期間で構築できました。ループ内では AI がアプリケーションを検証・レビューし、自動修正によってソフトウェアを徐々に要件へ収束させます。同時に、ワークフローの各工程から知識を蓄積し、Harness を最適化できます。
モデルのハルシネーションは客観的に存在するため、AI 開発ではテストがさらに重要になります。AI が Spec を生成したら、テストケースも同時に生成し、特に境界条件の網羅性を厳密にレビューする必要があります。テストケースは Harness の重要な構成要素として Git リポジトリへ保存します。テスト Agent はコーディング Agent と異なるモデルを使用する必要があります。実践では、Qoder Agent にすべての欠陥を一度に修正させると結果が悪くなりやすい一方、1回に1つだけ修正させると非常に良い結果が得られました。
同様に、100件のテストケースを1つのコンテキストでまとめて実行するより、10件ずつ10個の独立したコンテキストで実行した方が、より多くの欠陥を発見でき、見逃し率も低下します。
そのため、フィードバックループでは常にタスクを最小粒度まで分解し、小さなバッチで実行し、1件ずつ修正し、継続的に検証します。Qoder の Agent 機能によって、この高頻度の反復が可能になりました。
109のシステムと多様な技術スタックを長期間反復してもアーキテクチャを逸脱させないためには、能力と同じくらい制約が重要です。中核原則は単純です。ガードレールがなければ、AI の出力が増えるほどコードベースのエントロピーも速く増大します。
この原則に基づき、開発チェーン全体をカバーする仕様と Skills の体系を構築し、優先度で階層管理しました。P0 はアーキテクチャ境界とコンプライアンス基準を固定し、P1 はコーディングの中核をカバーし、P2 は保守性に焦点を当てます。各段階で必要な制約の組み合わせを注入し、Agent の動作境界を限定して、AI が正しい枠組みの中で作業するようにします。
知識ガバナンスは、前の3つの能力の価値を継続的に高める基盤です。私たちは AGENTS.md + Repo Wiki + Skills の3層システムでこれを実現しています。
AGENTS.md は、プロジェクトレベルの構造化された知識マップです。約100行のエントリーファイルをディレクトリナビゲーターとして使用し、巨大で網羅的なマニュアルを適切に置き換えます。段階的開示により、タスクの各段階で AI が必要とする情報をオンデマンドで提供し、コンテキストの冗長性を減らします。各プロジェクトのアーキテクチャ上の意思決定、コーディング標準、技術スタックの規約、既知の注意点を構造化して蓄積するため、新しいメンバーと新しい Agent が同じ AGENTS.md を読めば、一貫したプロジェクト理解を得られます。
Repo Wiki はプロジェクト文書を自動生成し、継続的に維持します。構造が完全で、コード参照を含み、直感的で分かりやすい文書です。コード変更をコミットすると Wiki も同期更新され、設計と実装の整合性を維持します。これは以前にはほぼ不可能でした。
Skills は個人の経験を再利用可能な組織能力へ変えます。単なる「設定ファイル」ではなく、企業が AI を利用するときの真の競争力です。この知識があれば、AI は新人ではなく、企業に育成された熟練者になります。
パイロットでは10件の先行プロジェクトを選びました。
● 新規システム開発では、控えめな推定でも効率が3〜4倍に向上し、本番リリースまでの期間が大幅に短縮されました。年末までには5〜6倍を見込んでいます。
● 既存システムの開発では向上幅が限定的でした。主なボトルネックは、レガシー資産に含まれる暗黙知であり、Qoder Rules を通じて段階的に抽出・注入する必要があります。
効果が高かったプロジェクトには共通点がありました。開発初期に急いでコードを生成せず、Qoder Spec で要件を合わせることに多くの時間を使っていました。要件フェーズが開発プロセス全体の40%以上を占め、要件品質が基準に達してから生成フェーズへ進みました。
AI ネイティブ開発の最大効率を引き出すには、ツールの改善だけでなく、プロセスの適応も必要です。Qoder を中心に、次の新しいプロセスを模索しています。
従来は、要件 → 設計 → 開発 → テスト → デプロイという線形プロセスで、各段階に引き継ぎがありました。現在は Qoder 内でコーディング、テスト、レビューが継続的なループを形成し、「小さく速く進める」が日常的な実践になっています。制約とコンテキストが維持されるため、長期タスクの反復でもアーキテクチャが逸脱しません。
要件フェーズで Qoder を使用して、境界条件を含むテストケースを生成します。Spec のすべての制約に、検証可能なテストケースを対応させる必要があります。これは後続工程でモデルのハルシネーションを防ぐ重要な防衛線です。テストエンジニアの重点は「バグを見つける」ことから「テストケースの品質をレビューする」ことへ移ります。
開発エンジニアはコードを1行ずつ書くのではなく、結果のレビュー、アーキテクチャ逸脱の検出、知識の蓄積に注力します。テストエンジニアはテストケースの品質と結果レビューに注力し、プロダクトマネージャーは Spec の品質管理に深く参加します。
プロセスの再構築は、最も大きな成果をもたらす取り組みです。私たちはまだ模索中ですが、方向性は明確です。Qoder を中心に、「人間が行うこと」と「AI が行うこと」の境界を再定義します。
最初から全員へ展開しないでください。まず AI を積極的に受け入れる小規模チームを見つけ、新規プロジェクトを開始点にします。新規プロジェクトにはレガシー資産がなく、要件からデリバリーまでのチェーン全体を通しやすく、チームが AI の能力に対する感覚を身につけやすいからです。まず使い、成果を確認してから展開を検討します。
パイロットが動き始めたら、業務シナリオごとに Harness エンジニアリングシステムを段階的に構築します。Harness のない AI 開発は、出力を制御できず、アーキテクチャが逸脱しやすく、品質が運に左右されます。Harness の価値は、仕様、制約、フィードバックループで AI の動作境界を定め、すべての出力を安定し、予測可能で、レビュー可能にすることです。
Rules、Skills、AGENTS.md、Repo Wiki は単なる「設定ファイル」ではなく、企業が AI を利用する際の真の競争力です。Qoder の知識システムを使い、チームのアーキテクチャ上の意思決定、業務ルール、過去の経験、技術標準をデジタル資産として蓄積します。AI ツール間の差は徐々に縮小しますが、企業のプライベートドメイン知識の蓄積は代替できません。知識ガバナンスが適切に行われれば、AI は新人ではなく、企業が体系的に育成した熟練者になります。これが真の長期的な競争力です。
私たちの仕事は、以前の「人間主導、ツール支援」から「人間と Qoder の共同生産」へ変わりつつあります。
エンジニアにとって最も重要な能力は、コードを書くことから、意図を明確にし、要件を分解し、環境を構築することへ変わります。Qoder は煩雑で反復的な実行を担い、「特定のコードの書き方を知らない」ことに創造性を制限されないようにします。
私たちはすでに方向性を確認しています。Spec の品質がソフトウェア品質を決め、プロセスの適応が効率向上の上限を決め、Qoder に蓄積した知識が長期的な競争力を決めます。研究開発の未来は、人間と AI が共に進化するプロセスです。
転機：Qoder を導入し、「支援型プログラミング」から「自律型プログラミング」へ
2025年1月、SDD 開発モデルの成熟に伴い、Qoder チームとの製品検討を開始しました。2月には約100人でパイロットを実施し、3月に Qoder を正式導入しました。現在では900人以上が利用しています。
Qoder と従来のツールの本質的な違いは、単なる補完エンジンではなく、完全な AI ネイティブ開発ワークベンチであることです。Rules、Skills、Memory、Repo Wiki、Experts モードによる協調が、AI ネイティブ開発の導入に必要なインフラストラクチャを構成しています。
Qoder を活用して Harness エンジニアリングシステムを構築
Qoder の機能体系を中心に、109のシステムで AI を安定して動かすための社内エンジニアリングシステム「Harness」を構築しました。
最初に、109のシステムをシナリオ別に分類
● ハイコードシナリオ（70%以上） — さらに次の3種類に分類しました。
● カテゴリ A：ゼロからの新規システム開発。Qoder が全工程に参加します。
● カテゴリ B：レガシーシステム上の新規モジュール開発。Repo Wiki で既存コードを理解してから生成します。
● カテゴリ C：レガシーシステムの既存モジュール改修。Agent が作業を始める前に、大量の履歴知識を注入する必要があります。
● ローコードシナリオ — 主に Qoder で設定ロジックとグルーコードを生成します。
● その他のシナリオ — 文書、テストスクリプトなどの補助成果物です。
多様な研究開発シナリオから、Harness の4つの中核要素を整理
1. Spec-Driven Development
Qoder の Quest-SDD（Spec-Driven Development）は、要件を直接、実行可能な開発仕様へ変換します。Spec の粒度と明確さは、最初のコード生成の品質を直接決定し、その後に必要な人間と AI の対話回数にも影響します。私たちは2つの実践を行いました。
実践 1：大きな Spec と小さな Spec。 大きな Spec は300行、75タスク、小さな Spec は70行、12タスクでした。結果として、大きな Spec の初回完了率は60%にとどまり、完成までに数十回の追加対話が必要でした。小さな Spec の初回完了率は95%に達しました。
実践 2：同じ PRD を3通りで処理。 Qoder に直接 Spec を生成させると、初回完了率は70%で、その後50回以上の確認が必要でした。エンジニアとプロダクトマネージャーが行ごとに確認して Spec を更新すると、完了率は大幅に向上しました。さらに、人間と AI の認識合わせ（Qoder Agent に質問させて理解を確認する）を加えると、完了率はほぼ100%となり、その後の修正はほとんど不要でした。
この結果から、次の Spec 品質基準を定めました。
● 現在の主流モデルの能力では、1つの Spec は原則として100行以内、最大でも150行以内にします。
● すべての制約をテストケースへ変換できるようにし、要件の明確性と検証可能性を確保するとともに、その後の AI 検証の根拠にします。
● コード生成後、1つの Spec に10回を超える人間と AI の修正が必要な場合、元の Spec の品質が不十分である可能性が高いため、Spec フェーズへ戻って認識を合わせ直します。
2. Harness フィードバックループ
AI Coding は AI 自律フェーズへ入りつつあります。その特徴は、フィードバックループを構築して「Human on the loop」を実現し、複数 Agent の協調によって長期タスクを実行し、人間を反復作業から解放することです。Qoder と各種オープンソース Skills により、複数 Agent のフィードバックループを短期間で構築できました。ループ内では AI がアプリケーションを検証・レビューし、自動修正によってソフトウェアを徐々に要件へ収束させます。同時に、ワークフローの各工程から知識を蓄積し、Harness を最適化できます。
モデルのハルシネーションは客観的に存在するため、AI 開発ではテストがさらに重要になります。AI が Spec を生成したら、テストケースも同時に生成し、特に境界条件の網羅性を厳密にレビューする必要があります。テストケースは Harness の重要な構成要素として Git リポジトリへ保存します。テスト Agent はコーディング Agent と異なるモデルを使用する必要があります。実践では、Qoder Agent にすべての欠陥を一度に修正させると結果が悪くなりやすい一方、1回に1つだけ修正させると非常に良い結果が得られました。
同様に、100件のテストケースを1つのコンテキストでまとめて実行するより、10件ずつ10個の独立したコンテキストで実行した方が、より多くの欠陥を発見でき、見逃し率も低下します。
そのため、フィードバックループでは常にタスクを最小粒度まで分解し、小さなバッチで実行し、1件ずつ修正し、継続的に検証します。Qoder の Agent 機能によって、この高頻度の反復が可能になりました。
3. 制約とガードレール
109のシステムと多様な技術スタックを長期間反復してもアーキテクチャを逸脱させないためには、能力と同じくらい制約が重要です。中核原則は単純です。ガードレールがなければ、AI の出力が増えるほどコードベースのエントロピーも速く増大します。
この原則に基づき、開発チェーン全体をカバーする仕様と Skills の体系を構築し、優先度で階層管理しました。P0 はアーキテクチャ境界とコンプライアンス基準を固定し、P1 はコーディングの中核をカバーし、P2 は保守性に焦点を当てます。各段階で必要な制約の組み合わせを注入し、Agent の動作境界を限定して、AI が正しい枠組みの中で作業するようにします。
4. 知識の体系化：Qoder Repo Wiki で実現
知識ガバナンスは、前の3つの能力の価値を継続的に高める基盤です。私たちは AGENTS.md + Repo Wiki + Skills の3層システムでこれを実現しています。
AGENTS.md は、プロジェクトレベルの構造化された知識マップです。約100行のエントリーファイルをディレクトリナビゲーターとして使用し、巨大で網羅的なマニュアルを適切に置き換えます。段階的開示により、タスクの各段階で AI が必要とする情報をオンデマンドで提供し、コンテキストの冗長性を減らします。各プロジェクトのアーキテクチャ上の意思決定、コーディング標準、技術スタックの規約、既知の注意点を構造化して蓄積するため、新しいメンバーと新しい Agent が同じ AGENTS.md を読めば、一貫したプロジェクト理解を得られます。
Repo Wiki はプロジェクト文書を自動生成し、継続的に維持します。構造が完全で、コード参照を含み、直感的で分かりやすい文書です。コード変更をコミットすると Wiki も同期更新され、設計と実装の整合性を維持します。これは以前にはほぼ不可能でした。
Skills は個人の経験を再利用可能な組織能力へ変えます。単なる「設定ファイル」ではなく、企業が AI を利用するときの真の競争力です。この知識があれば、AI は新人ではなく、企業に育成された熟練者になります。
実測値：Qoder による効率向上
パイロットでは10件の先行プロジェクトを選びました。
● 新規システム開発では、控えめな推定でも効率が3〜4倍に向上し、本番リリースまでの期間が大幅に短縮されました。年末までには5〜6倍を見込んでいます。
● 既存システムの開発では向上幅が限定的でした。主なボトルネックは、レガシー資産に含まれる暗黙知であり、Qoder Rules を通じて段階的に抽出・注入する必要があります。
Qoder が開発プロセスを変える
AI ネイティブ開発の最大効率を引き出すには、ツールの改善だけでなく、プロセスの適応も必要です。Qoder を中心に、次の新しいプロセスを模索しています。
1. 線形デリバリーを反復サイクルへ変える
従来は、要件 → 設計 → 開発 → テスト → デプロイという線形プロセスで、各段階に引き継ぎがありました。現在は Qoder 内でコーディング、テスト、レビューが継続的なループを形成し、「小さく速く進める」が日常的な実践になっています。制約とコンテキストが維持されるため、長期タスクの反復でもアーキテクチャが逸脱しません。
2. テストを要件フェーズへシフトレフト
要件フェーズで Qoder を使用して、境界条件を含むテストケースを生成します。Spec のすべての制約に、検証可能なテストケースを対応させる必要があります。これは後続工程でモデルのハルシネーションを防ぐ重要な防衛線です。テストエンジニアの重点は「バグを見つける」ことから「テストケースの品質をレビューする」ことへ移ります。
3. 役割の重点を変える
開発エンジニアはコードを1行ずつ書くのではなく、結果のレビュー、アーキテクチャ逸脱の検出、知識の蓄積に注力します。テストエンジニアはテストケースの品質と結果レビューに注力し、プロダクトマネージャーは Spec の品質管理に深く参加します。
プロセスの再構築は、最も大きな成果をもたらす取り組みです。私たちはまだ模索中ですが、方向性は明確です。Qoder を中心に、「人間が行うこと」と「AI が行うこと」の境界を再定義します。