Zhihui Science技術解説：QwenとManimがワンクリックAI動画モデルに挑む

Zhihui Scienceは、5段階のAIワークフローを通じて授業トピックを編集可能なアニメーションに変換し、農村教育部門で最優秀賞を獲得しました。このZhihui Science技術解説では、Qwen3.5、Manim、専門エージェント、自動コード修復など、その成果を支えたとされるシステムを検証します。

このプロジェクトは、第1回Xiaoyou Kewei AIオープンソース公益イノベーションチャレンジから誕生しました。このコンテストには約800チームが参加し、4つの公益分野で455件の応募が寄せられました。Zhihui Scienceは、農村教室向けAI教育アシスタント部門に出場しました。

その重要な競争相手は、別のコンテスト応募作品ではありません。教師がプロンプトを送信すると、制御の余地が限られた不透明な動画を受け取るという、よく知られたワンクリック生成モデルです。Zhihui Scienceは、計画、台本、コード、レビュー判断、編集可能なシーンファイルを生成するという異なるアプローチを取っています。

この選択により、プロジェクトは単なるAI生成メディアのデモンストレーションを超えたものになっています。構造化されたエージェントワークフローによって、教育コンテンツをより簡単に検査、修正、保守できるかどうかを検証しています。

Zhihui Scienceが実際に変えたこと

Zhihui Scienceは、AI動画生成を単一の創作依頼ではなく、監督可能な制作パイプラインとして再定義しています。

このプロジェクトは、中国科学院大学のTashan学際イノベーション協会によって開発されました。入手可能なイベント報道によると、コンテストの農村教育部門で最優秀賞を獲得しました。

チャレンジは2025年9月に始まり、12月29日に杭州で決勝が開催されました。報道によると、42組のファイナリストが最終審査に進み、4つの公益部門で16件のプロジェクトが受賞しました。

これらの詳細が重要なのは、Zhihui Scienceが明確に定義された教室の課題に対する解決策として評価されたからです。単なる実験的なアニメーション生成ツールとして発表されたわけではありません。

コンテストでは、農村教育、高齢者向けサービス、自閉症児支援、アクセシビリティに焦点が当てられました。ほかの受賞プロジェクトには、AI回想録ツール、子ども向け絵本プロジェクト、オープンソースの支援用メガネなどがありました。

あるコンテスト報告では、Zhihui Scienceは遠隔地のデジタルリソースと農村の教室をつなぐ架け橋と説明されています。この表現は、専任のアニメーション制作チームを持たず、教材を必要としている教師がプロジェクトの想定ユーザーであることを示しています。

その後、Qwen組織による技術記事で、アーキテクチャの詳細が報告されたとされています。その内容は、Qwen3.5-397B-A17B、Manimアニメーションエンジン、複数の協調エージェントを中心としています。

公開されている概要では、制作工程は計画、草案作成、実装、レビュー、合成という5つの段階に分かれています。各段階で、前段階の出力がより具体的な成果物へと変換されます。

プロセスは、完成した絵コンテではなく、知識トピックから始まります。計画エージェントがトピックを解釈し、概念を特定して、説明を複数のシーンに分割します。

次に、草案作成段階で、その計画を視覚的な物語へと変換します。何を表示するか、どの関係性を強調する必要があるか、各シーンをどのように進行させるかを決定します。

実装段階ではManimコードを生成します。Manimは、視覚要素と動きをプログラム可能なオブジェクトとして表現するPythonアニメーションエンジンです。

レビュー段階では、生成された結果またはその基礎となる仕様を評価します。その後、合成段階で承認されたシーンを最終的な教育動画にまとめます。

この分離こそが中心的な変化です。ワンステップ生成ツールでは、ほとんどの判断がモデルの応答内に隠されています。一方、Zhihui Scienceは、人間が検査できる中間計画やコードを公開するとされています。

このプロジェクトでは、レンダリングの周囲に修復ループも追加されています。Manimでエラーが発生すると、システムがエラー情報を抽出し、診断と修正のために送り返します。

したがって、最終出力には動画ファイルだけでなく、トピックからシーンに至る構造化された経路と、編集して再レンダリングできるコードも含まれます。

この違いが、本記事の中心的な緊張関係を生み出しています。制御性を高めるにはより多くのエンジニアリングが必要ですが、教育メディアではまさにその制御性が求められることが多いのです。

農村の教師がワークフローに厳しい条件を突きつける理由

教室向けアニメーションシステムが成功するのは、教師が授業全体を作り直すことなく修正できる場合に限られます。

農村教育は、このプロジェクトに社会的な説得力のある背景を与える一方で、厳しいプロダクト要件も生み出します。学校によって、人員、接続環境、デバイス、技術サポートへのアクセスには大きな差があります。

完成度の高いデモンストレーションだけでは、そうした違いを解消できません。最終的には、日常的な授業、限られた準備時間、不安定なインフラの中でも機能する必要があります。

直接的な負担は、従来のコンテンツ制作ワークフローにかかります。教師は多くの場合、静的な教材、一般的なオンライン動画、そして制作に多大な時間を要するカスタム教材の中から選択しています。

一般的な動画は適切な教科内容を説明できても、各クラス固有の学習目標を外す可能性があります。馴染みのない表記を使ったり、概念を不適切な順序で紹介したり、生徒が持っていない知識を前提としたりすることがあります。

カスタムアニメーションはより高い制御性を提供しますが、アニメーションコードの作成には専門的なスキルが必要です。手作業による動画編集には、素材、タイムライン、ナレーション、修正に関する別のコストも発生します。

テキストから動画を生成するシステムは、制作作業の一部を軽減します。しかし通常は、記号間の正確な関係性よりも、視覚的なもっともらしさを優先します。

このトレードオフは、数学や科学で顕著になります。図では、フレームをまたいでラベル、幾何学的構造、順序、縮尺、因果関係を維持しなければなりません。

視覚的に魅力的な誤りは、簡素なスライドよりも大きな害を及ぼす可能性があります。生徒は動きを記憶する一方で、誤った関係性を身につけてしまうかもしれません。

Zhihui Scienceは、教師の依頼を仕様として扱うことで対応します。エージェントは、最終的なアニメーションを生成する前に、その仕様を中間文書へと変換します。

このアプローチは正確性を保証するものではありません。しかし、教師、レビュー担当者、または将来の検証システムが介入できる複数のポイントを生み出します。

計画成果物からは、欠けている概念を発見できます。シーンの草案からは、分かりにくい説明を見つけられます。コードからは、誤った数式や視覚的変換を特定できます。

これにより、編集可能性は単なる利便性を超えたものになります。教育上のリスクを制御する手段となるのです。

このプロジェクトは、出力がプログラム可能な状態を保つため、ワンクリックの教育メディアツールにも圧力をかけます。教師や開発者は、すべてのシーンを再生成することなく、ラベル、再生時間、色、数式、順序を変更できます。

プログラム可能な出力は、再利用にも役立ちます。レビュー済みのシーンテンプレートを関連する授業に適用し、承認済みの視覚的ロジックを維持できます。

ただし、この利点はインターフェースにも左右されます。ほとんどの教師は、Pythonをデバッグしたり、生のシーンクラスを調べたりしたいとは思わないでしょう。

導入を成功させるには、意味のある制御機能へのアクセスを維持しながら、不要な複雑さを隠す必要があります。難しい設計上の問いは、その境界をどこに置くべきかということです。

教師はフォームを通じて、学習目標、用語、シーンの順序、進行速度を編集できるかもしれません。技術スタッフは、生成されたコードやレンダリングログへのアクセスを維持できます。

接続環境が限られた学校では、別の制約が生じます。報告されている3970億パラメータのモデル使用を考えると、生成にはホスト型推論または大規模なリモートインフラが必要になる可能性があります。

このモデルは、すべてのパラメータを同時に使用するのではなく、各トークンにつき170億パラメータを活性化します。これにより、同じ総パラメータ数を持つ密なモデルと比べて計算量は減りますが、導入が容易になるわけではありません。

より重要なのは、Zhihui Scienceが制作インフラを排除するのではなく、そのインフラを教師向けワークフローを中心に再編成しているという点です。

それでも十分に意義があります。教育チームはすでに、原資料、授業計画、例題、評価、レビューコメントを管理しています。

構造化されたナレッジワークフローなら、それらの教材を相互に関連づけたまま維持できます。検索可能なナレッジベースのためのツールは、情報源と改訂履歴を保持するうえで関連するパターンを提供します。

したがって、競争圧力は長期的なものです。AI動画プロダクトは、生成を最終段階として扱うのではなく、出所の追跡、修正、再利用をサポートする必要があります。

Zhihui Science技術解説：1つのレンダラーを取り巻く5つのエージェント

このプロジェクトの主要な仕組みは、創作作業を機械で検証可能な出力を持つ、範囲の明確な段階に分割することです。

公開されている説明では、マルチエージェントシステムという用語が使われています。ここでいうエージェントとは、特定のタスク、ツール、期待される出力を割り当てられた、モデル駆動型のソフトウェアコンポーネントです。

これは必ずしも、5つの異なるモデルを意味するわけではありません。複数のエージェントが、異なるプロンプト、ツール、コンテキスト、検証ルールとともに、同じ基盤モデルを使用することもできます。

Qwen3.5-397B-A17Bが言語処理と推論のレイヤーを担っていると報告されています。公式のモデルカードには、総パラメータ数3970億、推論時に活性化されるパラメータ数170億と記載されています。

このモデルは、Mixture-of-Expertsアーキテクチャを採用しています。この設計では、パラメータセット全体を活性化する代わりに、各トークンを選択されたエキスパートネットワークに振り分けます。

モデルカードには、512個のエキスパートがあり、そのうち10個のルーティング対象エキスパートと1個の共有エキスパートが活性化されることも記載されています。ネイティブコンテキストウィンドウは262,144トークンとされています。

これらの仕様は、原資料、計画メモ、シーン説明、コード、エラーログを含む長大な制作コンテキストを扱ううえで役立ちます。ただし、それだけで生成コンテンツの教育的な正確性が証明されるわけではありません。

報告されている最初のエージェントは、計画を担当します。幅広いトピックを、学習目標と視覚的な単位の連続へと変換します。

投射運動に関する授業を考えてみましょう。有用な計画では、速度成分、座標軸、方程式、物理的な例のどれから始めるかを決める必要があります。

この判断は、その後のすべてのシーンに影響します。計画が視覚的な基準枠を定義する前に数式を導入してしまえば、アニメーションの品質を向上させても、教える順序の問題は修復できません。

2番目のエージェントは草案を作成します。この段階では、教育計画を視覚的な動作、ナレーションの構想、シーン単位の構成へと変換します。

計画と草案作成の区別は、カリキュラムの意図とメディアでの表現を分離することに似ています。一方は生徒が何を理解すべきかを定義し、もう一方はそれをどのように見せるかを決定します。

3番目のエージェントは、Manimでシーンを実装します。公式のManimクイックスタートによると、スクリプトではSceneクラスとそのconstructメソッド内にアニメーションを構成します。

視覚要素は数学的オブジェクトとなり、一般にmobjectsと呼ばれます。開発者はコードを通じて、図形、方程式、ラベル、グラフ、変換を作成できます。

この表現により、ワークフローの一部に決定性がもたらされます。コードで定義された円は円のままであり、数式は明示的な座標を使って配置できます。

また、出力を編集可能にします。アニメーションの再生時間やラベルの位置を変更する際に、プロンプトから動画全体を作り直す必要はありません。

そしてManimは、実行環境であると同時に初期検証レイヤーとして機能します。コードは正常に動作するか、周囲のシステムが取得できるエラーを生成します。

この区別は重要です。大規模言語モデルは、もっともらしく見えても正しく実行できないコードを生成することがあるからです。構文エラー、importの不足、無効なオブジェクト参照、互換性のない呼び出しは、依然として一般的な障害要因です。

報道によると、Zhihui Scienceは自動修復によってこれらの障害に対処しています。システムはレンダリングログを収集し、障害の原因と考えられる箇所を特定してコードを修正し、再試行します。

このループは、受動的なモデル応答を反復的なソフトウェアプロセスへと変えます。モデルは一度回答するだけではなく、外部ツールからフィードバックを受け取ります。

また、レンダリングエラーは、品質改善を求める一般的な指示よりも具体的な対応につながります。障害に関係するファイル、操作、または行を特定できるからです。

したがって、自動修復は範囲こそ限定的ですが、有用な問題群に対処できます。教師にスタックトレースの解釈を求めることなく、実行時の障害を修正できます。

第4段階では出力をレビューします。公開されている概要だけでは、このレビューがコード、レンダリングされたフレーム、教育上の論理、あるいはそのすべてを検査するのかを判断するには情報が不十分です。

この不確実性は重要です。レンダリングの成功が示すのは、アニメーションが実行されたことだけです。説明が科学的に正しいことまでは示しません。

レビューエージェントは、スクリプトを原資料と照合したり、必要な概念を検査したり、視覚機能を使用してレンダリングされたフレームを分析したりできます。それぞれの手法で検出できる誤りは異なります。

テキストレビューでは数式やナレーションを検証できます。コードレビューでは実装上の問題を特定できます。視覚レビューでは、要素の衝突、読みにくい文字、分かりにくい動きを検出できます。

第5段階では、承認されたシーンを合成します。合成では、順序、トランジション、音声、最終的なレンダリングパッケージを管理できます。

合成を独立させることで、部分的な再生成が可能になります。失敗したシーンや品質の低いシーンだけを、承認済みのすべてのシーンを破棄することなく修正できます。

このモジュール性こそ、Zhihui Scienceの技術解説における最も優れたエンジニアリング上の発想です。各エージェントは、次の段階が利用し、評価できる成果物を生成します。

また、監査証跡も作成されます。チームは、最初の依頼、計画、草稿、生成コード、レビュー結果、修復履歴、最終出力を保存できます。

こうした記録は、教育者が主張に疑問を呈したり、変更を求めたりする際に有用です。開発者は、エラーを制作工程の特定の段階まで追跡できます。

このシステムは、メディア向けの継続的インテグレーションパイプラインに似ています。コード生成、実行、検査、修正、組み立てが、連続した処理として行われます。

ただし、この類比には限界があります。ソフトウェアテストでは正確な出力を検証できますが、教育上の分かりやすさや概念理解を自動的に測定することは、はるかに困難です。

したがって、このアーキテクチャは、決定論的な検証と人間によるレビューを組み合わせたときに最も力を発揮します。レンダリングテストが実行を確認し、教育者が教育方法と適切性を判断します。

レンダリングの成功は、授業の正しさを意味しない

自動修復は壊れたコードを直せますが、アニメーションの内容が真実であることや、教育の質を保証することはできません。

公開されている報道では、コンテストの結果が確認され、アーキテクチャが説明されています。しかし、正確性、教師の作業負担、生徒の学習成果、導入後の信頼性を網羅する公開ベンチマークは提示されていません。

この検証上の空白を踏まえて、プロジェクトを評価する必要があります。Zhihui Scienceは有望なエンジニアリング事例ですが、エージェントが生成したアニメーションによって学習効果が高まることを示す確立された証拠ではありません。

最も明白なリスクは、事実誤認です。モデルは、誤った方程式を提示したり、関係性を逆転させたり、必要な条件を省略したりする、有効なManimシーンを生成する可能性があります。

レンダラーはそのシーンを受け入れます。コードが記述どおりに正しく動作するため、自動修復は介入しません。

レビューエージェントはこのリスクを軽減できますが、生成エージェントと同じ盲点を共有している可能性があります。同じモデルを基盤とするエージェント同士が、同じ誤った解釈を自信を持って補強することもあり得ます。

したがって、外部情報による根拠付けが不可欠です。ワークフローでは、主張、数式、定義、例を、承認済みの教科書や教師が提供した参考資料と結び付ける必要があります。

教師もレビュー時に、それらの情報源を確認できなければなりません。出典情報を検索サービスやシステムプロンプトの内部に隠したままにしてはいけません。

視覚品質は、第2のリスクを生みます。プログラムによるアニメーションは精密な表現を可能にしますが、生成されたレイアウトが過密になったり、進行のテンポが悪くなったり、読みにくくなったりする可能性は残ります。

数式が正しくても、表示時間が短すぎることがあります。動くラベルが別のオブジェクトに重なることもあります。教室のプロジェクターでは、色のコントラストが不足する可能性もあります。

これらは、ささいな見た目上の欠陥ではありません。提示方法の選択は、生徒が画面上の論理展開を追えるかどうかに影響します。

ローカライゼーションには、さらに別の課題があります。農村部の教室を単一の対象として扱うことはできず、教育コンテンツには地域固有の用語、身近な事例、言語サポートが必要になる場合があります。

広範なインターネットデータで学習したモデルは、生徒の日常生活からかけ離れて感じられる例をデフォルトで選ぶ可能性があります。また、専門用語を一貫性なく翻訳することもあります。

プライバシーにも注意が必要です。報告されているワークフローは知識トピックから始まるため、個人を特定できる生徒の記録を処理するシステムよりもリスクは低くなっています。

しかし、将来のバージョンでは、生徒からの質問、評価データ、授業の録画、教師の文書を受け入れる可能性があります。こうした入力には、明確な保存方針とアクセス方針が必要です。

UNESCOの教育ガイダンスは、人間中心の検証、プライバシー保護、年齢に適した生成AIの利用を求めています。

このガイダンスは、このプロジェクトにとって最も現実的な導入方針と合致します。エージェントが準備と修正を迅速化する一方で、教師は授業に対する責任を引き続き負うべきです。

インフラも現実的な懸念事項です。代表的なQwenモデルは、mixture-of-experts設計によってネットワークの一部だけを有効化するとはいえ、依然として大規模です。

リモート推論では、接続性、サービスの可用性、データ転送ポリシーへの依存が生じます。ローカル推論には、多くの学校が保有していないハードウェアと運用の専門知識が必要です。

したがって、十分なサービスを受けにくい教室を対象とするプロジェクトでは、コンテンツ制作と教室での再生を区別する必要があります。教師は接続可能な場所で教材を生成し、動画とソースパッケージをエクスポートしてオフラインで利用できます。

ソースパッケージは特に重要です。通常のMP4はオフラインで再生できますが、教師が問題を発見した際に簡単に修正することはできません。

編集可能なプロジェクトの配布には、独自の保守負担も伴います。Manimのバージョン、フォント、メディアアセット、ソフトウェア依存関係は、時間とともに変化する可能性があります。

チームには、再現可能な環境、バージョン管理されたテンプレート、信頼できるエクスポート形式が必要です。そうでなければ、昨日は編集できた授業が、明日には壊れたプロジェクトになりかねません。

また、5段階のワークフローが、より単純なモデルとテンプレートの組み合わせを一貫して上回るという証拠も公開されていません。エージェントを増やせば修正の機会は増えますが、遅延や障害点も増えます。

計画エージェントがトピックを誤解する可能性があります。草稿エージェントが計画を歪める可能性があります。実装エージェントが草稿を誤って簡略化する可能性もあります。

レビューエージェントが誤検知を発生させたり、微妙な間違いを承認したりすることもあります。修復ループが、ある欠陥を直す一方で別の欠陥を持ち込む可能性もあります。

このアーキテクチャでは、各境界で測定を行う必要があります。チームは、計画の承認率、初回レンダリング成功率、修復成功率、事実修正件数、手作業による編集時間、教師による最終承認率を追跡すべきです。

生徒の学習成果は、別途評価する必要があります。コンテンツ制作が速くなっても、理解や定着が自動的に向上するわけではありません。

信頼できる実証実験では、同一の目標を設定し、同程度の教師が担当する授業を比較する必要があります。そのうえで、準備時間、エラー率、理解度、遅延再生を測定します。

これらの制約はいずれも、プロジェクトを無効にするものではありません。コンテストで優勝したプロトタイプから、信頼できる教育システムへ移行するために必要な作業を明確にするものです。

重要なのは、制御可能性と正確性を混同しないことです。編集可能なコードによって修正は可能になりますが、その修正を有意義なものにするのは、適格なレビュー担当者と検証済みの情報源です。

モデルの汎用性を示す3つのシグナル

次の試金石は、Zhihui Scienceが説得力のあるアーキテクチャを、再現可能な授業制作へと転換できるかどうかです。

第1のシグナルは、公開された実装パッケージです。これには、ソースコード、エージェントプロンプト、スキーマ、サンプルプロジェクト、評価スクリプト、導入手順などが含まれます。

このコンテストは、オープンソースによる公益的イノベーションを重視していました。実用的なリリースがあれば、独立した開発者が、エージェント間で責務がどのように受け渡されるかを調査できます。

また、どのコンポーネントを再利用できるかも明確になります。チームは、修復ループがManimでのみ機能するのか、他のコード駆動型メディアツールにも対応するのかを判断できます。

公開パッケージは、このシステムが演出されたデモンストレーションではなく、エンジニアリングパターンであることを示し、中心的な主張を補強します。

不完全なリリースは、その主張を弱めます。スクリーンショットや完成動画からは、生成が失敗する頻度や、どの程度の手動介入が必要だったかは分かりません。

第2のシグナルは、教師による継続的な利用から得られる証拠です。最も有用な数値は、完成した授業数、継続利用者数、編集時間、却下率、対応教科を網羅するものです。

1回限りのワークショップでは、教師が概念を理解していることは示せます。継続的な利用によって、このワークフローが通常の締め切りのある授業準備に適合するかどうかが分かります。

教師による編集には、特に注目する必要があります。教育者が計画を繰り返し書き直す一方で、生成コードにはほとんど触れないのであれば、製品は計画機能の制御を優先すべきです。

コード修復がワークフローの大半を占めるのであれば、チームには、より厳格なテンプレートや制約付き生成が必要かもしれません。事実修正が大半を占めるのであれば、より強力な根拠付けを最優先すべきです。

利用実績には、オフライン環境や低帯域幅環境も含めるべきです。農村部の教育システムは、安定したクラウド接続下で行われるデモンストレーションだけに依存することはできません。

第3のシグナルは、独立した教育品質評価です。レビュー担当者は、事実の正確性、カリキュラムとの整合性、読みやすさ、進行速度、アクセシビリティ、年齢への適合性を評価すべきです。

その評価では、承認された出力と却下された試行の両方を検査する必要があります。公開された例だけを見ても、システムの実際のエラー分布は隠されたままです。

教師がわずかな修正だけで大半の出力を承認できれば、独立したレビューはプロジェクトの妥当性を高めます。専門家による大規模な介入が依然として必要であれば、その主張は弱まります。

これらのシグナルは、1つのコンテストを超えて重要です。5段階のパターンは、科学的可視化、公衆衛生の解説、アクセシビリティ教材、その他の構造化メディアにも応用できます。

その移植性は、各段階の間にあるインターフェースに由来します。計画、草稿、実装、レビュー、合成は、汎用的な制作機能です。

具体的なツールは変更できます。別のワークフローでは、Manimを図表レンダラー、スライドフレームワーク、シミュレーションエンジン、Webコンポーネントライブラリに置き換えることもできます。

同じ修復原理も応用できます。AIシステムが決定論的なツールを操作する場合、実行時のフィードバックを次の試行に活用できます。

ただし、新しい分野ごとに、その分野独自の正しさの定義が必要です。コード修復ループは、医療レビュー、アクセシビリティテスト、カリキュラム検証の代わりにはなりません。

Zhihui Scienceは、この制約を踏まえて見ると最も興味深い存在です。1つのより大規模なモデルによって、教育コンテンツ生成の問題を解決するものではありません。

その代わりに、大規模モデルを、計画、コード、ログ、修正が可視化された成果物となるプロセスの中に組み込んでいます。

これは、AI支援型の知識労働にとって、より現実的な方向性です。モデルが複数の限定されたタスクを実行し、外部ツールと人間のレビュー担当者がフィードバックを提供します。

開発者がまず学ぶべきことは、エージェントを増やす前に中間成果物を設計することです。各段階には、明確な入力、出力、検証方法、復旧経路が必要です。

教育分野の購入担当者にとって、重要なのは管理と根拠に関する問いです。誰がコンテンツを承認するのか、どの部分が編集可能なままなのか、主張はどの情報源に基づいているのか、そして不具合がどのように記録されるのかを確認してください。

教師にとって、決定的な評価基準はもっとシンプルです。システムは、技術的なトラブル対応を教室に持ち込むことなく、授業準備の負担を軽減できなければなりません。

したがって、Zhihui Scienceの技術分析は、検証可能なリリース、教師による継続的な導入、独立した教育的評価という3つの具体的なテストで締めくくられます。

こうした兆候が現れるまでは、このプロジェクトを、重要なエンジニアリング上の主張を備えた、よく構成されたプロトタイプとして捉えるべきです。編集可能な生成は、不透明な生成よりも安全になり得ますが、それは学校側がシステムの生成物を検証できる場合に限られます。

次の一手は、教育者と導入担当者に委ねられています。あなたの環境では、初稿をより速く作成できること、情報源をより明確に追跡できること、生成後により簡単に修正できることのうち、どれが最も重要でしょうか。まずその制約から出発し、段階的なエージェントワークフローが、それに伴う作業を本当に軽減するかどうかを評価してください。