前回のノートで、半年分の英会話フィードバックを構造化したら同じことを30回以上指摘されていたという話を書きました。今回はその構造化を、どうやったかです。

特別なものは使っていません。Claude Code と、Gmail と、ブラウザと、Markdownのファイルだけです。ただ「一度動かして終わり」ではなく「毎週動き続ける」形にするために、いくつか決めたことがありました。書き残しておきたいのはそちらのほうです。

データは2か所にあった — Two Sources

レッスンの記録は、性質のまったく違う2か所に分かれていました。

ひとつは講師からのフィードバックメールです。レッスンが終わると届き、良かった点・改善点・次までの宿題・次回レッスンの焦点まで、すべて本文にテキストで入っています。しかも英語の原文とAIによる日本語訳が両方載っている。検索できて、消えなくて、構造が毎回同じです。

もうひとつはCamblyのサイト側です。こちらには録画・文字起こし・AIによる訂正（実際の発話と修正文の対）・統計（スピーキング率、1分あたりの語数、ユニーク語彙数）があります。情報としては濃いのですが、ログインが要るJavaScriptのアプリなので、取り出すにはブラウザを動かす必要があります。

メールのほうを主データソースに決めました。 理由は、Web側が取れなくてもノートが完成するからです。ブラウザ操作は壊れやすい。画面構造が変わる、ログインが切れる、読み込みが間に合わない。そこに依存させると、サイト側の都合でループ全体が止まります。メールだけで良かった点・改善点・宿題・次回の焦点は揃うので、まずそれでノートを作り切って、Web側は取れたら足す扱いにしました。

実装としては、Gmail MCP で subject:"担当の講師からフィードバックが届きました" を検索して本文をプレーンテキストで取り、Camblyのサイト側は Chrome DevTools MCP で開いています。

ログインは自分でやる — The Auth Boundary

サイトを見るにはログインが必要ですが、認証情報は一切渡していません。

Chrome DevTools MCP は永続プロファイルを使うので、一度ログインすればセッションが残ります。だから未ログインを検出したらブラウザのウィンドウを開いて「ここでログインしてください」と私に頼み、完了の合図を待つ、という手順にしました。スキルの手順書にも「自動ログインは絶対にしない」と明記してあります。

面倒に見えますが、実際にはほとんど手間になっていません。ログインが切れるのは数か月に一度で、そのとき10秒使うだけです。その代わり、パスワードをどこにも保存しない・スクリプトに書かない・履歴に残さない状態を保てます。自動化の範囲を「認証の手前まで」と決めておくと、あとの設計が素直になります。

46通を一度に処理しない — Backfill

半年分を最初にまとめて取り込むとき、40通を超えるメールがありました。これを一度に流すと、途中でコンテキストを使い切って中途半端に終わります。

そこで10通ずつに区切り、進捗を目次ファイルに書きながら進める形にしました。途中で止まっても次はそこから再開できます。

再開を安全にしているのは重複判定です。各ノートのフロントマターに、元になったGmailのメッセージIDを書いています。

---
type: note
date: 2026-08-09
tutor: （講師名）
source: gmail:19fe9bbf3112a20b
---

同じIDのノートが既にあれば作らない。これだけで、何度流し直しても結果が同じになります。最初の一括取り込みと、これから毎週動く差分更新を、同じ手順で書けるようにするためのキーでした。実際この2つは同じスキルの別モードになっていて、処理の中身は共通です。

成果物はノート46枚ではない — The Tracker

前回も触れましたが、実装の観点でも一番大事なので繰り返します。

レッスンごとのノートを46枚作っただけでは、何も分かりません。結局46枚を読み返すことになるからです。成果物は weak-points.md という1枚のファイルで、そこに指摘された弱点が累積され、それぞれ再発回数と初出レッスンへのリンクが並んでいます。

新しいノートを作るたびにこのファイルを更新します。既出の弱点なら出現リストに1件足し、新しければ節を追加する。判断の基準はひとつだけ決めてあって、「講師が繰り返し指摘しているか」を最重要のシグナルとして扱うことにしました。1回きりの指摘はその日の調子かもしれませんが、5回繰り返されていればそれは癖です。

置き場所の構成はこれだけです。

personal/projects/cambly/
├── index.md          目次（レッスン一覧・次回の予約・進捗）
├── weak-points.md    弱点トラッカー ← これが成果物
├── lessons/          復習ノート 46件
└── prep/             予習ノート

貯める場所と、見る場所 — Two Surfaces

前回の最後に書いた「貯める場所と、毎日見る場所は別でいい」を、もう少し具体的に書きます。

ノートはObsidianに置いていますが、私は普段Obsidianを開きません。メールも開きません。つまり置き場所として正しくても、そこに置いた時点では誰にも読まれない状態でした。だから読む側を別に用意しました。

  • 毎日21時ごろ、その週の宿題をドリルとして通知する
  • 日曜の夕方、その夜のレッスンの予習を通知する
  • スマホで開ける復習アプリに、直近の言い直しカードと弱点トップ3を出す

通知はクラウド側の定期実行に任せていて、毎回Gmailから最新のフィードバックを読み直します。 だから宿題が変わっても通知側の設定をいじる必要がありません。ここを「最新の宿題を通知文に焼き込む」形にしていたら、毎週手で書き換える羽目になっていたはずです。カレンダーにも同じ時刻に予定を入れて、説明欄から復習アプリへ飛べるようにしてあります。

Obsidianは原本のアーカイブ、日常のUIはアプリと通知、という分担です。

転用するときに効くこと — Reuse

同じことを別の習慣でやるなら、効いたのは次の3つでした。

  1. 壊れにくいほうを主データソースにする。 濃い情報より、確実に取れる情報を軸にする。濃いほうは取れたら足す
  2. 冪等にする。 元データのIDを成果物に書いておく。これがあると、初回の一括取り込みと毎回の差分更新を同じ手順で書ける
  3. 集計を1ファイルに持つ。 素材をどれだけ貯めても、順位のついた1枚がないと行動は変わらない

そして手順そのものは、Claude Code のスキルとして書いてあります。復習・予習・backfill の3モードがあり、/cambly-loop と打てば同じ手順が再現されます。毎回やり方を説明しなくてよくなったことが、続いている一番の理由かもしれません。仕組みが続くかどうかは、たいてい賢さではなく、起動にかかる摩擦の大きさで決まります。