02 / 07GRADUATION PROJECT · TEAM OF 4
NOTERA AI
授業・動画・画像の情報を、AIで読みやすいノートへ。
01
IDEA
最初にあったのは、ひとつの方向だけ。
授業や動画、画像の中の情報を、AIが読みやすいノートに整理できたら。
作ってみて分かったのは、難しいのは「AIに要約させること」ではないということ。何を残すか、画像をどう理解するか、コードをどう保つか、そしてチームで時間内に終わらせることだった。
発想の流れ
VIDEO / IMAGE / SLIDE → AI → NOTE- 01
Video / Image / Slide
映像・画像・スライド
- 02
AI
AIによる読み取り
- 03
Note
読みやすいノート
三つの要素
01VIDEO / IMAGE / SLIDE
映像・画像・スライド
授業で扱った素材をそのまま持ち込む。
02AI
AIによる読み取り
文字と見た目を一緒に読み、内容を整理する。
03NOTE
読みやすいノート
構造化されたノートに整える。
章の結論最初の方向はひとつでも、難しいのはその中身を決めることだった。NOTERA / 01 · IDEA
02
SCOPE
やりたいことは多い。だから、まず選ぶ。
WANT / MUST / LATER に分け、限られた時間で終わる範囲を先に決めた。
全部はできない。だから、残すものと後回しにするものを最初に分けた。
範囲シート
WANT / MUST / LATER| WANTやりたいこと |
|
|---|---|
| MUST必須 |
|
| LATERあとで |
|
範囲の決め方
WANT / MUST / LATER01WANT
やりたいこと
最初の広い方向。ここから範囲を絞る。
02MUST
時間内に終えるための条件
画像・動画の処理、構造化ノート、多言語とコード、そしてデモ。
03LATER
今はやらないこと
範囲の外に置いた三つ。あとで戻る。
章の結論機能は多いほど良いわけではない。まず、主要な流れを本当に走らせることが先だった。NOTERA / 02 · SCOPE
03
TEAM
4人の卒業制作で、チームリーダーとして方向を整理し、開発に参加。
チームリーダーとして、題目の提案と全体設計を整理し、自分の担当部分を実装した。メンバーは資料整理、レポート、発表を支えた。
最初から全員が同じ作業をする必要はない。先に、何を作るか、どこまで作るかを言葉にした。
役割の地図
4人の卒業制作私の担当(チームリーダー)
- 01IDEA題目の提出
- 02ARCHITECTURE全体アーキテクチャ
- 03INTEGRATION統合の判断
メンバーの担当
- 01DOCUMENT資料整理
- 02TEST提出の確認
- 03PRESENTATIONPPTと発表
担当の内訳
開発と資料の担当01私の担当(チームリーダー)
IDEA / 題目の提出
問いを立て、主要な構想をまとめる。
02私の担当(チームリーダー)
ARCHITECTURE / 全体アーキテクチャ
設計と開発の方向を決める。
03私の担当(チームリーダー)
INTEGRATION / 統合の判断
つなぎ目を合わせ、最後を判断する。
04メンバーの担当
DOCUMENT / 資料整理
資料を整理し、報告にまとめる。
05メンバーの担当
TEST / 提出の確認
提出物の確認を支える。
06メンバーの担当
PRESENTATION / PPTと発表
PPTと発表資料を作る。
章の結論私の仕事は、全部を一人でやることではない。題目とアーキテクチャを先に固め、4人の仕事を同じ成果へ向けることだった。NOTERA / 03 · TEAM
04
PLAN
時間内に終わる大きさに、先に切る。
最初から各自で書き始めるのではなく、資料がどう入り、どう処理され、最後にどう見えるかを先に確かめた。
進行の区切り
RESEARCH → UI → CORE → DOCS → PRESENTATION01RESEARCH
資料の入り口を確かめる。
02UI
見せ方を実装する。
03CORE
全体をつなぐ。
04DOCS
資料と報告をまとめる。
05PRESENTATION
PPTと発表資料をまとめる。
先に決めた三つ
IN / PROCESS / VIEW01IN
資料はどう入るか
入力の形を先に決める。
02PROCESS
どう処理されるか
読み取りと整理の流れ。
03VIEW
最後にどう見えるか
ノート画面まで含めて考える。
章の結論順番を決めると、限られた時間でも前に進めた。NOTERA / 04 · PLAN
05
BUILD
入力からノートまでの流れ。
作ったのは、INPUT → UNDERSTAND → ORGANIZE → OUTPUT の一本の流れ。
技術名を並べるより、どこでつながっているかを見える形にした。
構築の流れ
INPUT → UNDERSTAND → ORGANIZE → OUTPUT- 01
INPUT
映像・画像の入力
- 02
UNDERSTAND
文字と画像の読み取り
- 03
ORGANIZE
要点整理と重複の削除
- 04
OUTPUT
構造化ノート
Vue 3 / FastAPI / Local AI / Docker
四つの工程
01INPUT
映像・画像の入力
動画と画像をそのまま読み込む。
02UNDERSTAND
文字と画像の読み取り
OCR + VLM(Vision-Language Model)で、文字と画像を一緒に読む。
03ORGANIZE
要点整理と重複の削除
残す内容を選ぶ。
04OUTPUT
構造化ノート
読みやすい形に整える。
章の結論つなぎ目が見えると、どこで詰まっているかも分かった。NOTERA / 05 · BUILD
06
DECISIONS
OCR-First から VLM-First へ。音声はやめてスライドだけに。
価値があったのは、最後に何を使ったかではなく、途中でどう変えたかだった。
読み取りの中心を替え、材料も絞った。どちらも、限られた時間で主要な流れを守るための変更だった。
二つの転換OCR中心 → VLM-First
音声+スライド → スライドのみ
判断 01
OCR中心 → VLM-First変更前
- OCR
- 言語/文字の判定
- ノート
変更後
- 画像とOCR文字
- VLM 分析
- ノート
コードや英語、混在した言語の内容が、誤って落ちやすかった。
判断 01 の理由
OCR中心 → VLM-First01
何が問題だったか
コード・英語・混在言語が落ちやすい。
02
どう変えたか
Screenshot + OCR を VLM で分析し、文字と見た目を一緒に読む。
判断 02
音声+スライド → スライドのみ変更前
- 音声+スライド
- 判定
変更後
- スライド
- 出力
音声は収音の状態が悪く、効果が出なかった。
判断 02 の理由
音声+スライド → スライドのみ01
何が問題だったか
音声とスライドの両方で判断しようとしたが、音声の状態が悪かった。
02
どう変えたか
スライドだけで出力する形に変えた。
章の結論主経路を先に動かすと決めたことが、いちばん大きい判断だった。NOTERA / 06 · DECISIONS
07
RESULT
実際のデモで締める。
動画の入力、処理状態、ノートの出力まで、実際の画面で流れを示す。
卒業制作として発表し、実際にデモできる版まで作った。Ollama で qwen3-vl:4b をローカル実行し、PaddleOCR-VL と合わせて素材を処理する。短い動画は処理できるが、長い動画は手元の計算資源に制約がある。
デモの記録
INPUT / VIDEO LIST / NOTE


残ったもの
確認済み01SUPPORTED
入力から構造化ノートまでの流れ
Vue 3 と FastAPI、Docker でつないだ。
確認済み02SUPPORTED
4人の分担と統合の判断
範囲を切り、読み取りの方向を決め、つなぎ目で合わせた。
確認済み03SUPPORTED
卒業制作としての発表
発表スライドと技術レポートをまとめ、発表した。
確認済み
記録状況
NOTERA / 07入力から構造化ノートまで、確認できた範囲とチームの判断を中心にまとめる。
章の結論画面より、入力からノートまでの流れのほうが、この制作の成果だった。NOTERA / 07 · RESULT