タスク管理ツールがAIの「がくしゅうそうち」に化けるまで　Encraft #22 レポート

こんにちは！UPSIDER PRのAyaです！

2025年12月23日(火)に開催された(株)ナレッジワーク様主催のイベント『Encraft #22 AIプロダクトを支えるアーキテクチャ設計ー理論と実践』に、UPSIDER AI事業部・プロダクトマネージャーであるKiyotoが登壇しました。

AIを「学習する存在」としてプロダクトに組み込むための設計思想を実際の内製タスクツールでの実践例を元に紹介しました。本記事では、その登壇内容をレポートします。

knowledgework.connpass.com

改善が止まるAIプロダクトに共通する構造

Kiyotoは、セッション冒頭で次のように投げかけました。

「あなたのAIプロダクトは、本当に改善されていますか？」

多くのAIプロダクトでは、AIが出力した結果はログとして保存されています。

しかしそのログが、ユーザーの行動変化や業務成果、さらには事業上のアウトカムとどのようにつながっているかまで追えているケースは多くありません。

結果として、モデル改善やプロンプト改善を行う際の判断は、限られたサンプルや属人的な感覚に依存しがちになります。

ここで問題になるのは、データの量ではなく構造です。

アウトプット、アウトカム、フィードバックが分断されていることが、AIプロダクトの改善を止めてしまう最大の要因だと語られました。

UPSIDER AI経理を支える、内製タスク管理ツールの実態

この構造的課題を、UPSIDERではどのように乗り越えようとしたのか。その具体例として紹介されたのが、「UPSIDER AI経理」というサービスを支える内製タスク管理ツールです。

UPSIDER AI経理について
AI技術と人の協業により、経理業務の代行、月次決算の自動締め、試算表や経営レポートの提供、さらにはAIエージェントによる経営サポートを行う業務支援サービスです。 ai-keiri.up-sider.com

UPSIDER AI経理では、請求書や領収書の処理、仕分け、振込、請求書作成といった業務を、AIと人間のオペレーターが役割分担しながら進めています。

そのすべての作業はタスクとして管理され、月次では2万件を超えるタスクが流れています。

しかし、このツールにも当初は明確な限界がありました。

AIの判断結果は残っているものの、それが業務品質として正しかったのかは分からない、タスクは完了しているが、それが本当に「良いアウトカム」だったのか評価できない。

さらに、オペレーターからの指摘や顧客によるフィードバックは、ツールの外に散在していました。

つまり、データは存在しているのに、学習に使える形になっていなかったのです。

①アウトカムとして「成果物」をタスクに紐づける

この状況を変えるために行われた最初の設計変更は、アウトカムの捉え方そのものを変えることでした。従来は、タスクが完了すればそれで良しとしていました。しかしそれでは、品質も正しさも検証できません。

そこでUPSIDERでは、「業務の結果として何が残るのか」をアウトカムとして再定義しました。

仕分けであれば、その結果を示すスクリーンショット。
振込代行であれば、実行済みのファイル。
請求書作成であれば、完成したドキュメント。

こうした検証可能な成果物を、必ずタスクに紐づける設計に変更したのです。

この時点で、AIの判断と人間の作業結果、そして業務アウトカムが、1タスク単位で追跡可能になりました。

②「成果物レビュー」という評価工程を必ず組み込む

次に行われたのが、タスクの状態遷移そのものの見直しです。タスクを「完了」にする前に、必ず「成果物レビュー」という工程を挟む。提出された成果物に対し、まずAIが一次判定を行い、問題がある場合のみ人間がレビューとラベリングを行うといったものです。

重要なのは、このプロセスを例外なく必須にした点です。

運用ルールではなく、プロダクトの構造として組み込んだことで、日々処理されるすべてのタスクが、評価済みデータとして蓄積されるようになりました。

タスク管理ツールが「がくしゅうそうち」に変わる瞬間

この設計変更によって、タスク管理ツールの性質は大きく変わりました。オペレーターは、特別な評価作業をしている意識はありません。いつも通り業務を進めているだけです。

それでも裏側では、運用すればするほど高品質なデータが自動的に蓄積されます。修正された失敗事例でも、次の学習のための重要な資源になります。

これにより、人的コストを増やさず、評価量を増やせます。この状態こそが、Kiyotoの言う「がくしゅうそうち」でした。

勝てるAIプロダクトに共通する設計思想

UPSIDER AI経理の事例で紹介した設計構想は多くのAIプロダクトに転用可能です。

その根底にあるのは「AIのアウトプットは、プロダクトにとっての中間生成物にすぎない」という考え方です。ユーザーや業務にとって価値があるのは、アウトプットそのものではなく、それによってどのような状態変化が起きたのかという点にあります。

そのため、まず行うべきはアウトカムの定義が必要です。AIが何をアウトプットしたかではなく、その結果としてユーザーは自己解決できたのか、業務は正しい状態で前に進んだのか、本来発生すべき修正や問い合わせは抑制されたのかという「達成された状態」を、検証可能な形で定義し、計測可能にすることがべての設計の起点になります。

また、フィードバックは後付けの分析対象ではなく、業務フローのコア機能として組み込むべきものだと示されました。評価・確認・修正の導線をプロセスに自然に組み込むことで、評価は意識せずとも必ず行われる構造になります。

そして、使えば使うほどデータの質が上がる構造を意図的に作ることが重要です。

AIプロダクトの設計とは、モデル選定やプロンプト設計だけを指すものではありません。評価・学習・改善が必然的に回り続ける構造を、いかにプロダクトに埋め込むかが大切です。

勝てるAIプロダクトとは、モデルの差ではなく、こうした構造設計の差によって生まれることを強く印象づける内容でした。