Education Review Desk

Education Review Desk は、intake 以外の強い例です。ユーザーはすでに artifact を持っていて、agent の仕事は承認済みの rubric や標準に沿って review し、役立つ feedback と revision plan を返すことです。

これはシンプルですが根拠のある review の形です。承認済みの rubric を Attachments に置き、draft を Live Test にアップロードして、agent に feedback と revision plan を返させます。

このパターンが向いている場面

• ユーザーが draft、case write-up、assignment をアップロードまたは貼り付ける
• チーム側に承認済みの rubric や review standard がある
• 出力は feedback、revision guidance、または human reviewer への escalation であるべき

Agent がすること

• 何を review しているのか、どの rubric を使うべきかを確認する
• 承認済みの criteria に沿って内容を評価する
• 強み、抜け、最優先で直すべき点を示す
• 範囲外なら revision plan を示すか、human reviewer に escalate する

承認済みの outcome

• Feedback Summary
• Revision Plan
• Human Reviewer Escalation

してはいけないこと

• 承認されていない rubric や grading standard を作り出す
• artifact から裏づけできない問題を断定する
• judgment を説明せずに全体を書き換える
• human reviewer が必要な場面で最終的な academic / policy decision を出す

相性のよいツールとデータ

• Attachments: 小さな rubric、checklist、exemplar を常時参照させる時
• Knowledge Base: rubric library、policy note、curriculum guidance が大きい時
• Request Form: 後続フローで student や reviewer から structured follow-up が必要な時だけ使う
• HTTP Request: review result を LMS や内部 system に送る必要が出た時に追加する

会話例

User: climate policy essay を見てもらえますか？ conclusion が弱い気がします。

Agent: はい。Ms. Chen の persuasive writing rubric に沿って review します。thesis clarity、evidence quality、counterarguments、conclusion impact を中心に見ます。

User: その rubric で合っています。

Agent: evidence section は強く、支えも十分です。ただ、conclusion は前半の繰り返しが多めです。いちばん大きい改善点は "so what?" をもっと直接答えることです。短い revision plan をまとめます。1) 主張を 1 文で言い直す、2) 現実の影響を明示する、3) 読者に支持してほしい policy action で締める、です。

このパターンが重要な理由

• Codeer が単なる first-touch intake ではなく、expert judgment を扱えることが伝わります。
• 教育、QA、compliance review、社内の expert feedback loop に向いています。
• 承認済みの基準と、境界を守った判断の見え方がより明確になります。