原稿を渡すと公開直前まで進む――AIとの技術ノート運用が楽になった
Markdownから記事ページを作る仕組みを使い続ける中で、原稿を渡した後の重複確認、編集、追加、ビルドと検査までAIへ任せられるようになりました。AGENTS.mdで現在の運用を共有し、Skillやプラグインへの展開も考えています。
以前、この技術ノートの記事をMarkdownからHTMLへ変換し、既存の会社サイトへ追加する仕組みを、ChatGPTやCodexと一緒に作ったことを書きました。Markdownは、見出しや箇条書きを文字の記号で表せる文書形式です。
その仕組みを作った時点で、記事ごとのページや一覧を手作業で組み立てる必要はなくなりました。記事を増やすための土台は、8月にできていました。
最近、さらに楽になったと感じているのは、その仕組みを使うときの私自身の作業です。
私は新しい記事の原稿をテキストでAIへ渡し、「いつもの感じでお願いします」と頼みます。するとAIが、過去記事の確認から文章の調整、記事ファイルの追加、サイトの生成と検査まで進めます。できあがった記事と作業結果を私が確認すれば、残るのはWebサイトへのアップロードです。
私が「次は過去記事を探して」「今度はビルドして」と一工程ずつ指示しなくても、アップロード直前まで作業がつながる。そこを、今とても楽に感じています。
私は原稿を渡し、できあがった記事を確かめる
記事の題材は、日々の仕事で試したことや、AIとのやり取りから生まれます。最初から公開用のきれいな文章になっているとは限りません。自分の体験と、そのとき考えたことをテキストにして渡します。
まず内容への意見だけが欲しいときには、「新記事です。どうだろう」と聞きます。その段階では、過去記事との重複や説明の不足を見てもらい、文章の方向を考えます。記事として追加したいと決めたら、修正と公開準備を頼みます。
一方、「いつもの感じでお願いします」と渡したときは、記事の追加からビルド後の確認まで進めてもらう運用です。短い依頼でも作業の範囲が伝わるよう、フォルダー内に手順を残しています。
できあがったら、私は本文を読みます。実際の経験と合っているか。自分の考えが違う意味に変わっていないか。社外に出してよい内容か。違和感があれば、その場で直してもらいます。
原稿を用意し、できあがりを読むことに集中できる。 記事を続けるうえで、私にはこれが大きな変化でした。
過去記事との重複を、作成前に確認する
記事が増えると、新しい原稿に出てきた体験を、以前にも書いていたということがあります。AIには、新しい文章だけで判断せず、公開記事の一覧と内容の近い記事を先に確認してもらいます。
たとえば、AIに新しいチャットを作ってもらい、引き継ぎ内容を渡した体験は、Local Workのエラーを調べた記事の「2026年10月10日追記」ですでに扱っていました。その後、チャットや会社の情報をどう引き継ぐかという別の記事を書くとき、引っ越しの手順をもう一度詳しく説明すると、読者には似た話が続きます。
そこで、新しい記事では、引っ越しができたことから情報管理への考えが広がった部分を中心にしました。詳しい検証は前の記事へつないでいます。
重複確認では、同じ単語が出ているかだけを見ているわけではありません。前の記事では何を試し、どこまで確認し、何を結論にしたのか。今回の原稿には、その先の出来事や判断の変化があるのか。そこまで読んで、新しい記事の中心を決めます。
ただし、毎回すべての記事を精読すると、記事を一つ追加するための調査が大きくなりすぎます。普段は公開記事の一覧で題材を探し、内容が近い数本を重点的に確認します。この範囲も、現在の作業ルールに書いてあります。
過去の記録と食い違わないようにする
重複の確認とあわせて、以前の記事に書いた事実との整合も見ます。
Knowledge OSへ情報を保存する取り組みでは、以前、候補をMarkdownとして保存し、正式登録まで一度通して確認できたことを書いていました。その後の試行では、同じように進まない場合もありました。
後の失敗だけを取り上げて「まだ保存できていない」と書けば、一度成功した事実が見えなくなります。以前の成功を根拠に「安定して使える」と書くのも、現状に合いません。
そこで、過去記事を確認し、「以前に一度成功したが、その後は完了できない場合もあった」という時間の流れを残しました。前の記事を今の結論に書き換えるより、新しい記事で変化の理由を説明したいからです。
AIが下調べを進めてくれるので、私は示された説明が自分の経験に合っているかを確認できます。滑らかな文章でも、「考えた」「一度試した」「安定して運用できる」は違う段階です。そこは完成した記事を読むときにも気をつけています。
原稿から公開用ファイルまで、一つの依頼で進む
記事の方向が決まると、AIは原稿と過去記事を照らし合わせながら本文を整えます。製品の機能や制度など、後から変わる情報が含まれていれば、公開時点の公式情報も確認します。私の環境で起きたことと、公式に確認できること、そこから考えた仮説を混ぜないためです。
文章がまとまったら、タイトルや概要、公開日、分類、URLに使う名前を設定し、記事用のMarkdownファイルとして追加します。Astroでサイトを生成する仕組み自体は、以前の記事で紹介したものを使っています。
生成後は、新しいページができているか、記事一覧とサイトマップに載ったか、本文中や前後記事へのリンクがつながっているかを確かめます。公開用ではないメモが混ざっていないかも見ます。Markdown上では太字にしたつもりの記号が、実際のページでは文字として見えたこともあったため、生成されたHTMLも確認します。
画面については、記事のタイトルがスマートフォンの幅から大きくはみ出さないか、横スクロールが起きないか、記事末尾のリンクが読めるかを簡単に見ます。
ここまで終わると、AIから記事ファイルと確認結果が返ってきます。公開用のフォルダーも、私がアップロードできる状態です。私は記事の中身を最終確認し、自分でアップロードします。
8月に作ったページ生成の仕組みを、今はAIが作業の一工程として使っている。このつながりが、今回書きたかった変化です。
AGENTS.mdに「いつもの感じ」を残してきた
この一連の作業を、毎回長い指示文で説明しているわけではありません。今は、作業フォルダーの AGENTS.md と、記事作成の標準運用をまとめた文書でAIへ伝えています。AGENTS.md は、そのフォルダーで作業するAIに、確認するものや進め方を知らせるファイルです。
そこには、依頼が記事への意見なのか、追加まで求めているのかを読み分けることを書いています。内容が近い過去記事を数本確認すること、既存の公開記事は明示的に頼まれない限り変更しないことも決めています。
文章については、私の実体験と考えが動いた順番を残すこと。未確認の内容を断定しないこと。きれいに短くまとめるために、試した経緯や判断の変化を削らないこと。最近は、似た形の対比表現を繰り返さないという好みも加えました。
サイト生成後の検査項目も入っています。一方、通常の記事追加で全記事を毎回調べ直したり、記事管理表を更新したりはしません。確認すべきところを残しながら、記事一つにかける作業を必要な範囲へ絞っています。
この文書は、最初から完成していた手順書ではありません。「ここはAIが確認してほしい」「この説明は私の経験と違う」「その確認は毎回しなくてよい」と分かるたびに、少しずつ直してきました。
その結果、「いつもの感じで」という短い言葉の後に、AIが進める仕事の順番ができています。
次はSkillやプラグインにもできるだろうか
現在動いているのは、ローカルの作業フォルダーにあるルールをAIが読み、記事の作成から公開準備まで進める方法です。私は最近、この流れを別の形でも使えるのではないかと考えています。
たとえばSkillは、繰り返す仕事の手順や期待する完成形をAIに伝えるための仕組みです。原稿の確認から記事の追加、ビルド後の検査までを、技術ノート用のSkillとしてまとめることも考えられます。
さらにプラグインなら、Skillと必要なツールを組み合わせ、一つのまとまりとして扱う方法もあります。これらは公式資料で確認できる仕組みですが、当社の技術ノート運用を移して試したわけではありません。今は可能性を考え始めた段階です。
私にとって大事なのは、使う仕組みの名前よりも、原稿を渡した後の負担が実際に減ることです。記事の中身を考え、できあがりを確かめる時間を持てる。現在の AGENTS.md による運用でも、それを感じています。
最初は、Markdownから記事ページを作れるようになりました。今は、原稿を渡すとAIがアップロード直前まで作業を進めてくれます。記事を出すたびに生まれた気づきをルールへ戻しながら、この楽さを、無理なく続けられる運用にしていきたいと思っています。