Kidswant は Qoder を使い、1週間かかっていたフルスタック要件を1日へ短縮し、400の業務シナリオと300の Agent が動く AI プラットフォーム Zhishu を構築しました。
他社が業務へ AI を追加する中、Kidswant はまず R&D チームを AI Native にした
多くの企業は、AI 変革を「業務にいくつかの AI 機能を追加すること」と捉えています。Kidswant は一歩先に進み、ソフトウェアを作る行為そのものを AI Native にしました。そのレバーが Qoder です。
フルスタック要件が1週間から1日へ
従来、フロントエンドとバックエンドを含む要件は、人がタスクを分解してコードを1行ずつ書き、ツールが補完を行っていました。Kidswant の開発チームは別の方法を選びました。Qoder に目標と受け入れ基準を明確に伝えて社内 AI プラットフォーム Zhishu を構築し、納期を半年近くから2か月へ短縮しました。
Qoder は実際のソフトウェア開発向け Agentic Coding プラットフォームです。通常のコード補完とは異なり、コードベース全体を理解してから、エンジニアのようにタスクを体系的に進めます。
複数モジュールとフロントエンド・バックエンドが絡むシステムでは、コードベースを理解することが大きな障壁です。Repo Wiki はコードに埋もれたアーキテクチャをドキュメントへ整理し、変更に合わせて更新し、Git でチーム共有できます。Zhishu の Agent オーケストレーションとナレッジベースの継続的な開発では、複数の開発者による協働を支えました。
実装には Quest Mode を利用しました。目標と受け入れ基準を説明すると、範囲を合わせ、設計し、エンドツーエンドでコードを書き、検証、修正します。Zhishu の Skills マーケットでは、画面と機能の要件を説明した後、フロントエンドとバックエンドを含む実装を約1日で完了できました。
生成コードを自社の業務に合わせるため、コーディング規約、業務コンテキスト、レビュー基準をプロジェクトレベルの Skills として蓄積し、MCP で社内ツールとシステムへ接続しました。
重要なのは、単にコードが速く書けることではありません。チームの標準的な働き方が「人が書き、AI が支援する」から「人が定義し、AI が納品する」へ変わったことです。
10以上の専門家 Agent は、10以上の実在チームを追加するようなもの
この方法で構築した最も重要な成果が、自社 AI プラットフォーム Zhishu です。Qwen を基盤に、ナレッジベース、ワークフロー、Skills を統合し、マルチ Agent 協働、長期・短期メモリ、DingTalk や H5 からの操作に対応します。
現在、Zhishu では400以上の業務シナリオと300以上の Agent が動き、データ分析、財務、サプライチェーン、カスタマーサービス、コンテンツ制作など10以上の専門家 Agent が蓄積されています。多くの Skills も Qoder で改善して作成されました。
「AI を使えるか」を評価へ組み込む
Kidswant は、CTO と HR が共同で変革を推進し、R&D の協働方法を高度化するとともに、AI を使う能力を評価へ組み込みました。
ツールが時間を節約しても、その時間を何に使うかが変革の深さを決めます。Qoder が節約した開発時間は、プラットフォーム、業務シナリオ、方法論を構築する時間になりました。
最後に
小売企業にとって最も難しいのは、高度なツールを購入することではなく、ツールを組織の能力へ変えることです。Kidswant が取り組んでいるのは後者です。
- R&D から始めるべき兆候： AI 要件が3か月以上滞留し、開発能力が業務需要に追いつかず、アイデアではなく生産能力がボトルネックになっている。
- 最初の試行要件： 最も単純でも最も複雑でもなく、境界が明確で複数技術スタックにまたがり、従来なら約1週間かかる要件を選ぶ。
- Repo Wiki の価値が高い条件： 数十万行以上のコード、多人数協働、新しいメンバーが既存コードを理解しにくい状況。
- 最初の Agent の選び方： AI ができることではなく、同じ作業を繰り返す実在チームから考える。人手が多く、ルールが明確で、出力が標準化されたチームから始める。
- 組織へ展開する時期： 最初から全社 AI 化を宣言せず、成功事例と数値を作ってから仕組みを展開する。