※この記事は、2026年7月時点の自分のAI学習メモです。特定の講座内容を紹介する記事ではなく、AI講座を受けた後に、自分のObsidianやCodex運用へどう戻すかを考えた実運用メモとして書いています。
AI系の講座を受けました。
内容としては、かなり実践寄りでした。
Codexのセットアップから始まり、資料を読み込ませ、文字起こしや議事録のような材料をもとに、問題点を洗い出すUIやモックを作る流れもありました。
最初はセットアップで少しまごつきました。
でも、やっていること自体はかなり面白かったです。
資料を渡す。
AIに読ませる。
画面案を出す。
モックにする。
そこから自分の作業に応用できないか考える。
この流れを見ると、単なる勉強というより、「自分の作業をAIでどう組み替えるか」の入口に近いと感じました。
ただ、そこで少し引っかかったこともあります。
講座を受けた後、その内容をそのままブログに書けばいいのか。
自分の答えは、たぶん違います。
講座の中身を紹介するよりも、自分の運用にどう移すかを残した方がいい。
今回はその話です。
講座の内容をそのまま書くと、自分の記事ではなくなりやすい
講座を受けた直後は、いろいろ書けそうな気がします。
こんなことをやった。
こんな流れだった。
このツールを使った。
この手順が面白かった。
そういうメモは当然残したくなります。
ただ、それをそのまま公開記事にすると、少し危ないと思いました。
まず、有料講座や配布資料の具体的な中身に踏み込みすぎる可能性があります。
それは自分のブログでやりたいことではありません。
もう一つは、講座内容の紹介に寄りすぎると、自分の記事ではなくなることです。
自分がこのブログで書きたいのは、講座レビューではありません。
AIをどう使っているか。
Obsidianに何を残しているか。
Codexに何を渡しているか。
何で詰まって、どう運用を変えたか。
そこが中心です。
だから、講座を受けた後に残すべきなのは、講座の再現ではなく、自分の側に起きた変化だと思いました。
どこで手応えがあったのか。
どこで詰まったのか。
何を復習すべきなのか。
どの作業に応用できそうなのか。
こっちを残した方が、後からAIにも読ませやすいし、自分のブログにもつながります。
受けた直後ほど、分かった気になりやすい
講座中は、流れに乗るとそれなりに分かった気になります。
画面が動く。
モックが出る。
AIがそれっぽいものを作る。
講師の説明を聞くと、なるほどと思う。
その瞬間は、かなりできるようになった気がします。
でも、家に帰ってから同じことを一人でやれるかというと、たぶん別です。
特に今回、自分は最初のセットアップでも少しまごつきました。
資料を読ませてUIを作る流れも、見ている時は分かる。
でも、自分の材料でやるなら、何を入力として用意するのか。
どこまでAIに任せるのか。
出てきた画面案をどう確認するのか。
できたモックを何に使うのか。
そこまで考えないと、自分の運用にはなりません。
講座を受けた直後に必要なのは、「面白かった」という感想だけではないと思います。
むしろ、分かった気になっているうちに、何を再現できて、何を再現できないのかを分けた方がいい。
ここを曖昧にすると、数日後にはかなり薄れます。
「あれ、結局何をやったんだっけ」になりやすい。
だから、受講直後のログはかなり大事だと感じました。
自分に必要なのは、講座メモではなく復習ログだった
今回、自分が残したいと思ったのは、講座メモというより復習ログです。
講座メモは、何を教わったかを記録するものです。
復習ログは、それを自分の作業に戻すためのものです。
この違いは大きいです。
たとえば、単に「資料をAIに読ませてUIを作った」と書くだけなら、講座メモです。
でも、自分の運用に戻すなら、もう少し分ける必要があります。
自分のブログ運用なら、どの資料をAIに読ませるのか。
INBOX整理なら、どのメモを入力にするのか。
WordPress貼り付けHTMLなら、どこまで自動化できるのか。
関連記事のURLミスのような確認作業は、どこで止めるのか。
こう考えると、講座で見た流れをそのまま使うのではなく、自分の作業単位に変換する必要があります。
自分の場合、今の作業はかなりObsidianに寄っています。
INBOX。
raw。
workbench。
daily。
blog_ideas。
公開直前セット。
このあたりをAIに読ませながら、ブログや自動化を少しずつ進めています。
だから、講座で学んだことも、最終的にはここへ戻さないと意味が薄い。
講座の内容を覚えることより、自分の運用にどう接続するか。
そこを残す方が、自分には合っていそうです。
復習ログは、できたこと・詰まったこと・次に使う場所で分けたい
今のところ、講座後に残すログは3つに分けるのがよさそうです。
1つ目は、できたことです。
どの作業を見たのか。
どこまで動いたのか。
自分でも再現できそうな部分はどこか。
これは単純な記録です。
2つ目は、詰まったことです。
セットアップでまごついた。
用語が分からなかった。
どのファイルを渡せばいいのか迷った。
出てきたものをどう評価すればいいか分からなかった。
こういうところです。
たぶん、こっちの方が大事です。
スムーズにできたことより、詰まったところの方が、次にAIへ相談しやすいからです。
3つ目は、次に使う場所です。
ブログで使うのか。
Obsidian整理に使うのか。
WordPress用HTMLの確認に使うのか。
小さい自動化のモック作成に使うのか。
仕事の資料整理へ応用できるのか。
ここまで書いておくと、講座が「楽しかった」で終わりにくくなります。
AIに復習を手伝わせる時も、かなり頼みやすいです。
「この講座を要約して」ではなく、
「この講座で自分が詰まった点を、次に試す作業に分けて」
と頼めるようになります。
この差は大きいです。
用語で落ちたところも、AIに渡せるメモになる
講座とは別に、リスキリング系のテストも受けました。
そこでかなり感じたのは、用語の穴です。
実際に手を動かす感覚は少しずつ出てきている。
でも、英語3文字や4文字の略語、デザイン手法、データ関連の用語になると、急に弱くなる。
見たことはある。
聞いたこともある。
でも、意味を正確に説明しろと言われると止まる。
こういうものが結構ありました。
逆に、セキュリティ系は比較的点が取れました。
これはたぶん、普段からAI安全性やローカルLLM、PDFの扱い、権限、確認点の話をしているからです。
要するに、何度も文脈の中で触れているものは残りやすい。
一方で、単語だけ見たことがあるものは、思ったほど身についていない。
そう考えると、用語で落ちたこともただの反省ではなく、AIに渡せるメモになります。
分からなかった用語。
見たことはあるけど説明できなかった概念。
デザインやデータ関連で弱かった範囲。
これをObsidianに残しておけば、次にAIへ聞けます。
「この用語を暗記したい」ではなく、
「自分の作業とつなげて説明して」
と頼める。
そこまで行けば、テストで落ちた部分も次の材料になります。
講座を受けっぱなしにしないために、AIに読ませる形で残す
今までも、ブログ運用ではAIに読ませる形を意識してきました。
INBOXに放り込む。
rawに退避する。
workbenchで記事候補にする。
dailyに何をやったか残す。
blog_ideasで状態を追う。
この流れがあるから、後からCodexに「整理して」「ネタ出しして」「下書きにして」と頼めます。
講座の復習も、同じ形に寄せたいです。
受けた内容をノートにきれいにまとめるだけではなく、AIが読みに行ける場所へ置く。
できたことはできたこととして残す。
詰まったことは詰まったこととして残す。
次に試す作業は、作業候補として残す。
公開できない具体内容は raw や private に置く。
公開できる芯だけ workbench に救出する。
こうしておけば、講座の内容を直接公開しなくても、自分の運用には残せます。
むしろ、その方が安全です。
講座の具体的な手順や配布資料を出さずに、自分が何を学び、何を変えようとしているかを書けるからです。
学んだことは、自分の作業に戻して初めて効いてくる
AI講座を受けると、どうしても「何を教わったか」に目が行きます。
もちろん、それも大事です。
でも、自分にとって本当に大事なのは、そこから何を自分の作業に戻せるかです。
ブログ運用に戻す。
Obsidian整理に戻す。
Codexへの頼み方に戻す。
自動化の小さい試作に戻す。
分からなかった用語を、次の学習メモに戻す。
ここまでやって、ようやく講座が自分のものになる気がします。
受けて終わりではなく、残して、分けて、次に渡す。
それをAIにも読める形で置く。
今の自分には、その方が合っています。
AI講座を受けた後は、内容紹介より「自分の運用に移すログ」を残した方がよさそうです。
講座で何をやったかより、そこから自分の作業がどう変わるか。
そこを残せるかどうかで、学びが一回きりで終わるか、次の作業につながるかが変わってくるのだと思います。
コメント