Qoder の5つの中核機能を活用して開発効率を高める方法と、Credits を節約する6つの実践的なヒントを紹介します。
皆さん、こんにちは。Cainiao 越境物流で技術開発を担当している Ren Fu です。本日はユーザー体験の視点から、私たちのチームが Qoder を使って研究開発効率を高めてきたベストプラクティスをご紹介します。
私たちは昨年、あるいはそれ以前から AI プログラミングを模索してきました。その過程で、Aone Copilot、Suite Copilot、GitHub Copilot、Claude Code など、主流の AI プログラミングツールを幅広く試しました。
この1年で、AI プログラミングツールは急速に変化しました。初期のコード支援ツールから、より知的で自律的な Agentic プログラミングツールへと進化しています。それに伴い、AI Coding の研究開発パラダイムも変化しました。自然言語で指示して期待する結果を得る初期の Vibe Coding から、明確な仕様制約に基づいて高品質な本番コードを生成する Spec Coding へと移行しています。
その中核にある考え方は、ソフトウェアエンジニアリングで問題が表面化してから介入するのではなく、アーキテクチャ設計を含む仕様であらかじめ制約を設け、開発プロセス全体を固めたうえで、明確な条件の下でより高品質な本番コードを生成することです。
一方、この1年余りの実践を通じて、従来のツールには共通する課題も見えてきました。
これは私が最も気に入っている機能です。アイコンを1回クリックするだけで、プロジェクト概要、技術アーキテクチャ、開発ガイド、デプロイガイド、開発規約を網羅した詳細な説明が生成されます。シーケンス図やフローチャートまで含まれます。システムに詳しくない人でも、すぐに開発へ参加できます。さらに、Git のコード変更に基づいて継続的に更新する動的リフレッシュにも対応しています。
大規模モデルは一般知識には強い一方、個別のコンテキストを持っていません。Rules 機能では、事前定義したコンテキストや、コード品質の好みなどの研究開発・コーディング規約をディレクトリに設定できます。手動で記述することも、オープンソースサイトのベストプラクティスを利用することもできます。開発中に Qoder にルールを生成させることもでき、たとえば単体テストのルールを作成できます。
複数ラウンドの対話では、Qoder がコミュニケーションスタイルや個人の好み（ユーザーの役割、専門領域、よく使う技術スタック、環境設定など）に基づいてメモリ一覧を生成し、以降の会話で継続的に読み込みます。
MCP は主に、LLM を外部データソースや外部ツールと連携するときの接続プロトコルの課題を解決します。ブラウザー機能、作図ツール、ほかのシステムの MCP サービスなどを登録すると、Qoder が対話中に必要なツールを自律的に選択します。
Skills は、ドメイン固有の知識を備えた、モジュール化され再利用可能な SOP ワークフローと考えることができます。
開発者であるか、コードを書けない人であるかを問わず、機能をゼロから実装したい場合は、「要件 → アーキテクチャ設計 → 開発とテスト」という流れで進められます。
Repo Wiki のコードマッピング機能を活用し、まず Qoder と実装方法を検討します。役割、目標、参考事例を指定するプロンプトエンジニアリングによって Qoder を Plan フェーズに移行させます。Qoder は現在のアーキテクチャを分析し、ソリューション設計を提案します。最後に納得できる案を選び、To-do を生成して開発へ進みます。
開発者として効率的な体験を享受する一方で、コストの節約にも注意する必要があります。私がまとめた6つのベストプラクティスは次のとおりです。
この1年余りの AI プログラミングの実践を通じて、私たちは「従来型プログラミング」から支援型プログラミング、そして Agentic 自律プログラミングへと進化してきました。これは単なるツール機能の向上ではなく、試しに結果を出すだけの段階から、本番環境に到達できる Spec Coding モデルへの研究開発パラダイムの転換です。
MCP と Skills の登場によって、今後のシステム設計やインターフェース設計では、AI がエコシステムへより適切に統合できるよう、汎用性と再利用性をこれまで以上に重視する必要があります。
AI が本番環境へ入ると、コードに対する説明責任が重要になります。AI が生成したコードに対する可観測性、追跡可能性、セキュリティレビューの仕組みを整え、企業の機密データを保護し、セキュリティ上の防衛線を守る必要があります。
最近は QoderWork も試しています。QoderWork は、MCP や組み込み Skills を通じて、ブラウザーやソフトウェアシステムなど、さまざまな機能をすでに取り込んでいます。文書やファイルを作成したい場合は要件を説明するだけで、同僚のように協力して成果物を作成してくれます。
現在の AI Coding は、もはやコーディングだけを意味しません。技術的な観点でも、開発から、業務や運用など、より多くの人が利用する幅広いシナリオへと広がっています。将来、私たちは AI を受け入れるだけでなく、AI の波を積極的に迎えることになるでしょう。
Qoder が研究開発生産性をさらに大きく飛躍させることを期待しています。よりスマートな未来を一緒に築きましょう。
AI プログラミングの進化
私たちは昨年、あるいはそれ以前から AI プログラミングを模索してきました。その過程で、Aone Copilot、Suite Copilot、GitHub Copilot、Claude Code など、主流の AI プログラミングツールを幅広く試しました。
この1年で、AI プログラミングツールは急速に変化しました。初期のコード支援ツールから、より知的で自律的な Agentic プログラミングツールへと進化しています。それに伴い、AI Coding の研究開発パラダイムも変化しました。自然言語で指示して期待する結果を得る初期の Vibe Coding から、明確な仕様制約に基づいて高品質な本番コードを生成する Spec Coding へと移行しています。
その中核にある考え方は、ソフトウェアエンジニアリングで問題が表面化してから介入するのではなく、アーキテクチャ設計を含む仕様であらかじめ制約を設け、開発プロセス全体を固めたうえで、明確な条件の下でより高品質な本番コードを生成することです。
- 場当たり的な生成：明確な計画や説明がないため、Agent が業務を理解したりコードを生成したりする際にハルシネーションが発生します。
- 効率の低さ：複雑な業務コンテキストに対して十分なコードを生成できません。開発者側にも設計された指示や標準的な制約がないため、AI は要件を明確に理解できず、効果的なソリューション設計やタスク分解を行えません。
- 重要情報の欠落：以前の大規模モデルではコンテキスト長に制限があり、AI との複数ラウンドの対話で情報が蓄積すると、AI の理解力が低下します。
Qoder の中核機能と体系的なアプローチ
Qoder の5つの中核機能
01 中核機能 1：Repo Wiki
これは私が最も気に入っている機能です。アイコンを1回クリックするだけで、プロジェクト概要、技術アーキテクチャ、開発ガイド、デプロイガイド、開発規約を網羅した詳細な説明が生成されます。シーケンス図やフローチャートまで含まれます。システムに詳しくない人でも、すぐに開発へ参加できます。さらに、Git のコード変更に基づいて継続的に更新する動的リフレッシュにも対応しています。
02 中核機能 2：Rules
大規模モデルは一般知識には強い一方、個別のコンテキストを持っていません。Rules 機能では、事前定義したコンテキストや、コード品質の好みなどの研究開発・コーディング規約をディレクトリに設定できます。手動で記述することも、オープンソースサイトのベストプラクティスを利用することもできます。開発中に Qoder にルールを生成させることもでき、たとえば単体テストのルールを作成できます。
03 中核機能 3：Memory
複数ラウンドの対話では、Qoder がコミュニケーションスタイルや個人の好み（ユーザーの役割、専門領域、よく使う技術スタック、環境設定など）に基づいてメモリ一覧を生成し、以降の会話で継続的に読み込みます。
04 中核機能 4：MCP
MCP は主に、LLM を外部データソースや外部ツールと連携するときの接続プロトコルの課題を解決します。ブラウザー機能、作図ツール、ほかのシステムの MCP サービスなどを登録すると、Qoder が対話中に必要なツールを自律的に選択します。
05 中核機能 5：Skills
Skills は、ドメイン固有の知識を備えた、モジュール化され再利用可能な SOP ワークフローと考えることができます。.qoder/skills ディレクトリに保存され、特定のタスクを完了する方法を Qoder に教えます。
Qoder の Quest モードと Agent モードの比較
- Quest モード：Spec 駆動型の自律プログラミングです。ユーザーが入力した要件に基づいて、構造化された要件文書、アーキテクチャ設計、To-do List を生成します。内容を確認した後は、残りのタスクを AI に引き渡し、エンドツーエンドのデリバリーを自律的に完了させます。
- Agent モード：日常の開発でより頻繁に使用するモードです。ダイアログボックスに要件を入力すると、AI が意図を認識して実行計画を生成します。Repo Wiki、Rules、Memory などをコンテキストに読み込み、内容を理解したうえでコードを出力します。
日常業務での実践例
事例 1：ローカル動画プレーヤーをゼロから構築する
開発者であるか、コードを書けない人であるかを問わず、機能をゼロから実装したい場合は、「要件 → アーキテクチャ設計 → 開発とテスト」という流れで進められます。
- 要件フェーズ：プロンプトで役割、内容、成果物を指定し、製品 PRD 文書を出力します。
- アーキテクチャ設計フェーズ：PRD をコンテキストに取り込み、Qoder に PRD と組み合わせて Spec 仕様と To-do 項目を設計させます。
- 開発・テストフェーズ：技術選定、リスク、アーキテクチャを含む仕様を確認した後、コード生成フェーズに入ります。機能の実装に問題があれば修正します。
事例 2：レポートメニューを追加する
Repo Wiki のコードマッピング機能を活用し、まず Qoder と実装方法を検討します。役割、目標、参考事例を指定するプロンプトエンジニアリングによって Qoder を Plan フェーズに移行させます。Qoder は現在のアーキテクチャを分析し、ソリューション設計を提案します。最後に納得できる案を選び、To-do を生成して開発へ進みます。
Credits を節約するためのベストプラクティス
- 関係のない話題は新しいウィンドウで始める：誤った入力によってコンテキストに冗長な情報が増えた場合、Qoder が内容を誤解した場合、または話題が無関係な場合は、トークンの浪費を避けるため速やかに終了します。
- 必要に応じてモデルのレベルを選ぶ：単純な要件には軽量モードを使い、複雑な機能にのみ Auto または最上位モードを使うことで、コストと成果のバランスを取ります。
- コードリポジトリの構造を最適化する：不要な出力を減らします。Qoder は単体テストや Markdown の説明文書をデフォルトで生成する場合があります。不要なら、指示の中で明確に除外します。
- 期待する動作を明確にする：設定で無関係なディレクトリを除外し、コンテキストへ読み込まれないようにします。
- 方向がずれたらすぐに停止する：対話中、業務コンテキストの入力不足によって結果が誤った場合は、Qoder が過度に発散しないよう速やかに停止します。
- エンジニアリングの方法でロールバックする：良い例を提示して Qoder に直前の出力を修正させる方法と、Git でバージョンを直接ロールバックして再生成する方法があります。