Obsidianのメモからブログ記事になるまでの、自分なりのゆるい書き方をまとめてみます。あわせて、その過程でAIとどう付き合っているかについても少しだけ触れてみます。

アウトプット大事なのは分かっているけど、どうやって記事を書いたら良いのか分からない、という人には参考になるかもしれません。

結論

最初から「記事を書くぞ」と構えず、Obsidianに雑メモを書くところから始めて、あとで「記事にしてもいいかも」と思えたものだけ少しずつ育てていく、というスタイルで書いています。

AIは本文を自動生成するのではなく、タイトル、slug、全体のチェックをお願いする“おまけツール”くらいの距離感で使っています。

まずはObsidianにメモを書く

普段は、記事にすることを一切考えずに、Obsidianにメモを書いています。

時間がかかった作業や、気になったところ、再現が面倒なコンソールの結果やエラー内容など、「もう一度やるのはしんどいもの」をとりあえず放り込んでおく感じです。

この段階のメモは、人に見せる前提ではなく完全に自分用なので、構成や文章としてのきれいさは気にしていません。

まずはメモをしていくのが大事だと思います。

「これは記事にするぞ」と決めるのは、そのあとでも十分間に合います。

「これ記事にできるかも」と思ったときにやること

色々やっていると「これは記事にしてもいいかもな」と思う瞬間がたまにあります。

たとえば、ものすごくハマったエラーの解決策や、「次同じことがあったら絶対にググり直したくない」系の内容などです。

そう思えたときに、Obsidianのメモにそのまま少し手を入れて、段落単位くらいの文章にしていきます。

この時点では、段落と段落のつながりや全体のストーリーはまだ気にせず、「ひとまとまりの話」ごとに雑に書いていくイメージです。

ここで言いたいことがバチッと決まると記事が書きやすくなります。

自分用の文章から、人に読んでもらう文章にする

断片的な段落がいくつかできたら、そこでようやく「これは誰に向けた文章にするか」を考え始めます。

自分だけが読み返せればよいメモとして残すのか、社内の人に共有するのか、完全に外向けの記事にするのかをざっくり決めます。

外向けにする場合は、「この前提を知らない人が読んだらどこで詰まるか」を想像しながら、少しだけ説明を足していきます。

環境情報や、専門用語の軽い補足、前後関係のつながりなど、「読者が迷いそうなところだけを埋める」くらいの調整にとどめることが多いです。

全体をざっと見て、最後にまとめを書く

ひと通り書き終わったら、最初から最後まで読み直して、流れが大きくおかしくないかだけを確認します。

チェックするときの基準は、「未来の自分が読んだときに、そのときの状況や判断をちゃんと思い出せるかどうか」です。

そのうえで、最後に短いまとめを書いて、「結局何が分かったのか」「次にやるなら何をするか」を簡単に整理して終わりにしています。

まとめも、きれいにオチをつけるというよりは、自分向けのメモを少し丁寧に言い換えるくらいの感覚です。

この書き方の良さと、いまのところの課題

このやり方の一番いいところは、「書くぞ」と決めてからネタを探すのではなく、メモが先にあるので心理的なハードルが低いところだと思います。

このやり方をし始めてから、まずは記事っぽいものを書くところまでは行けるようになりました。

一方で、課題もあります。

それぞれで書いている文章をうまくまとめることや、足りない部分を補うことが意外と大変です。

メモに残せていないコンソールの結果やエラー内容があったときに、「記事としては書いておきたいこと」が抜けてしまうことがあります。結果として、そのまま記事を出さないこともあります。

AIはタイトル、slug、チェックにだけ使う

AIは、本文を書くためではなく、周辺の「考えるのが面倒な部分」を手伝ってもらう用途で使っています。

たとえば、書き終わったあとに「この記事に合いそうなタイトル候補をいくつか出してもらう」「URLのslugを考えてもらう」といった使い方です。

また、たまに全体を貼り付けて「違和感があるところがあれば教えてください」といったざっくりしたチェックをお願いすることもあります。

最後に

こんな感じで、「最初はObsidianの雑メモから始めて、いけそうなものだけ少しずつ記事に育てる」「AIはあくまで外側だけ手伝ってもらう」というスタイルで書いています。

このやり方が正解というわけではないですが、「このくらいのゆるさでもブログを書いていいんだな」と思ってもらえたらうれしいです。