私はこのサイトを英語と日本語の2か国語で運営しています。長い間、記事づくりでいちばん大変だったのは、書くことではありませんでした。書いた後のすべての作業です。画像のコピー、フロントマターの記入、次に何を公開するかの判断、翻訳を忘れないこと、そしてその半分をもう一方の言語でもう一度やることでした。
ここ数か月で、その作業の大半をClaudeに任せるようになりました。ただし、一度にではありません。ワークフローは3つの段階を経ました。手作業での公開、いくつかのClaude Codeスキルで組んだ最初のAIを介したワークフロー、そして最後に、ObsidianのVaultを唯一の情報源とし、残りを1つのClaudeルーティンが引き受ける統合パイプラインです。
本稿では、それぞれの段階で何が解決し、何が解決しなかったかを順に紹介します。結論を先に言うと、各ステップを速くすることは役に立ちましたが、本当の解決策は、記事の状態をどこに置くかを決めることでした。
第1段階:手作業での公開
AI以前の記事公開はこうでした。リポジトリで下書きを書き、フロントマターを設定し、見直し、コミットしてデプロイする。4つのステップです。手順としては単純ですが、ほぼどのステップにもそれぞれの手間がありました。
アセットは手作業でコピーしていました。 画像は1枚ずつリポジトリ内の専用ディレクトリにコピーし、ファイル名が記事内の参照と一致しているかを確認する必要がありました。1つでも間違えると、公開されたページで画像が表示されません。面倒なうえに、まさに起こしやすく気づきにくい種類のミスです。
下書きには本当の意味でのステータスがありませんでした。 記事は執筆中か、公開準備ができているか、公開済みかのいずれかでしたが、それを実際に記録しているものは何もありませんでした。執筆中の記事が公開されないよう、gitで無視する別のディレクトリに置いておき、次に何を公開するかを決めるには、下書きを開いて手作業で見比べるしかありませんでした。
エディタは文章ではなくコードのためのものでした。 VS Codeはコードを書くには素晴らしい環境です。しかし文章を書くとなると、他のノートとの相互参照、画像の埋め込み、フォルダの管理のどれもが、必要以上に手間のかかるものでした。
翻訳は後回しでした。 時間がかかるうえ、原文がすでに公開された後にしか行われませんでした。すべての記事に2つ目の言語が必要なわけではなく、どの記事に必要かを記録するものもなかったので、翻訳そのものを忘れてしまうこともよくありました。
予約投稿はできず、何も1か所にまとまっていませんでした。 記事を予約投稿できないことは、おそらくいちばん大きな問題でした。さらに、記事のアイデアはまた別のツールにあったので、バックログ、公開準備のできた記事、公開済みの記事が完全に同期していることはありませんでした。
第2段階:繰り返し作業をClaudeに任せる
最初に取り組んだのは、繰り返しの作業を2つのカスタムスキルでClaude Codeに任せることでした:
publish-postは、gitで無視される_draftsディレクトリから、フロントマターの予定日をもとに次の下書きを選び、誤字を直し、アセットの欠落などの問題を指摘し、記事を所定の場所に移動しました。translateは、私が引数として渡した公開済み記事のスラッグを受け取り、その翻訳をもう一方の言語のディレクトリに保存しました。
3つ目のスキル new-draft は、Obsidianのノートを _drafts 内の下書きに変換するもので、望めばObsidianで書き始められるようになりました。各実行の後、結果の確認、コミット、デプロイは引き続き私自身が行っていました。
良くなった点
公開作業は、手作業のチェックリストから、いくつかのスキルの実行に変わりました。次の記事はClaudeが見つけてくれるので手作業で見比べる必要がなくなり、翻訳もずっと速くなりました。
同じくらい重要なのは、公開を妨げる問題があれば、Claudeが見逃さずに指摘してくれるようになったことです。そして、すべての変更を私自身が確認してデプロイしていたので、Claudeが見落としたものを拾う人間がループの中にいました。
変わらなかった点
スキルによって各ステップは速くなりましたが、構造的な問題はすべて残っていました:
- アセットは相変わらず手作業で管理していました。
- 下書きには相変わらず本当の意味でのステータスがありませんでした。
- 下書きは相変わらず複数の場所にありました。Obsidianのノート、
_draftsの変換済み下書き、そして別のツールのアイデアです。 - どの記事に翻訳が必要か、どの記事にすでに翻訳があるかを記録するものはありませんでした。
- 翻訳は相変わらず、私が忘れずに開始しなければならない別の実行でした。
- 予約投稿はできませんでした。どの実行も、相変わらず私が始めていました。
このリストを見ると、残ったものはほぼすべて状態に関するものでした。下書きがどこにあるか、どんなステータスか、翻訳が必要かどうかです。ステップを速くしても、これは解決できません。次の段階では、状態を置く場所そのものを変える必要がありました。
第3段階:1つの情報源、1つのパイプライン
これが現在の姿です。ObsidianのVaultがすべてを保持しています。記事のアイデア、下書き、公開準備のできた記事、公開済みの記事とその翻訳です。1つのClaudeルーティンが1つのカスタムスキル publish-pipeline を実行し、ノートを拾って公開したり、翻訳したり、プロパティを更新したりします。私が確認するのは、Claudeが指摘した翻訳だけです。コミットやデプロイも含め、それ以外はすべてパイプラインが自動で処理します。
そこに至るまで
これは一度に実現したわけではありません。小さなステップをいくつか重ね、そのたびに状態が置かれている場所を1つずつ減らしていきました。
まず、下書きがリポジトリを離れました。 _drafts ディレクトリと new-draft スキルを廃止しました。公開スキルはVault内のノートのパスを受け取るようになり、そのノートを変更することは一切ありませんでした。
次に、キューノートが役割を引き継ぎました。 下書きがVaultに移ったことで、どの下書きが準備できていて、どの順番で公開するかを示す方法が必要になりました。そこで新しいスキル publish-blog-post が、Publish Queue.md という1つのノートをもとに動くようになりました。これはチェックリストで、先頭の行が次の記事、📅の日付は「この日以降」を意味し、公開済みの記事は ## Log セクションに移されます。そこでは require translation ラベルが、次に何を拾うかを translate スキルに伝えていました。このバージョンでは、予約実行、PIIチェック、そしてビルド・マージ・プッシュもスキル自体に組み込まれました。skill-creatorの最初の評価ラウンドでは、スキルなしのClaudeが28項目中18項目だったのに対し、28項目中27項目に合格しました。
キューノートからBaseへ
キューノートは機能しましたが、それはコピーでした。どの記事も、状態が2か所にあることになりました。ノート自体と、キューの中の行です。記事を先に進めるにはキューを編集する必要があり、それは私(行の並べ替え、日付の追加)とスキル(行のログへの移動、ラベルの切り替え、ブロック時の⚠️の追加)の両方が行っていました。ノートの名前を変えると、キュー内のリンクが壊れます。つまり、同期を保たなければならないものをまた1つ作ってしまったわけで、それこそが私が取り除こうとしていた問題そのものでした。
そこで、キューをノート自体に移しました。キューの次のような行は:
- [ ] [[My next post]] 📅 2026-11-02 | require translationノートのプロパティになりました:
status:
- Ready
scheduledAt: 2026-11-02
requireTranslate: trueキューを見るには、今はObsidianのBaseを使っています。小さな .base ファイルで定義するビューで、プロパティをもとにノートを抽出します。私の Posts.base は、status プロパティを持つすべてのノートを拾い、カンバンボードにグループ分けします:
views:
- type: kanban
name: Status
filters:
and:
- file.hasProperty("status")
groupBy:
property: statusこの違いは見た目以上に大きなものです。キューノートは、私とスキルが維持しなければならない文書でした。Baseはノートに対する単なるビューなので、同期すべきものは何も残りません。ノートの status を変えれば、ボード上でカードが移動します。スキルは共有ファイルへの書き込みをやめ、代わりに各ノート自身のプロパティを読み書きするようになりました。
すべての状態が1か所に集まると、最後の2つのステップは自然に決まりました:
- 公開と翻訳が統合されました。 翻訳に専用のスキルや専用のリストは必要なくなりました。
publish-blog-postとtranslateは1つのスキルpublish-pipelineになり、翻訳はそのステージの1つになりました。 - 名前の変更をやめました。 パイプラインは以前、公開済みのノートのファイル名に✅の接頭辞を付けて印にしていました。これが他のノートからのリンクを壊していたので、今ではすべてをプロパティだけに記録しています。
すべてを1か所に
今では、ノートのフロントマターがそのままパイプライン上の状態そのものであり、Baseはすべてのノートを Drafting、Review、Ready、Published の4列のボードに表示します。この記事もそのカードの1枚で、書いている今は Drafting の列にあります。
私が自分で設定するプロパティは一握りです。status、scheduledAt(記事を公開してよい最も早い日付で、キュー内の順番も決める)、requireTranslate、series、project、そしてClaudeへの追加の指示を書く自由記述の note です。残りは、各実行の後にパイプラインが書き戻します。リポジトリ内の記事のパス、公開日と言語、そして原文と翻訳の間のリンクです。
この1つの変更で、それまでの問題の大半が一度に解決しました。下書きのステータスは、ノートのプロパティです。記事に翻訳が必要か、すでに翻訳があるかは、ノートにもボードにもすぐに表れています。アイデアも下書きも公開済みの記事も、すべて同じ場所にあります。そしてObsidianで書いているので、相互参照、画像の埋め込み、フォルダの整理はもう面倒な作業ではありません。画像は、公開時にパイプラインがリポジトリにコピーし、サイトの形式に変換してくれます。
1つのスキル、3つのステージ
publish-pipeline は毎回、Vault内のすべてのノートのフロントマターを読み、それぞれの次のアクションを判断するところから始まります。原文の公開、確認済みの翻訳の公開、公開済み記事の翻訳、不足しているプロパティの補完、あるいは何もしない、のいずれかです。その後、最大3つのステージを実行します:
- Publish は、Ready のノートをMDX記事に変換します。画像をコピーし、Obsidianの構文を変換し、校正し、サイトのフロントマターを書いてから、ビルド、マージ、プッシュを行います。
- After-publish は、パイプラインのプロパティをノートに書き戻し、
statusを Published にします。 - Translate は、翻訳を原文の隣に新しいノートとして書きます。ノートではなく公開済みの記事から翻訳するので、Publishステージでの修正も翻訳に反映されます。
進捗はフロントマターに記録されるので、途中で止まった実行は、次回最初の未完了のステージから再開します。また、翻訳が失敗しても、公開済みの原文が取り消されることはありません。
私が関わる場面
これはヒューマン・イン・ザ・ループのワークフローですが、人の手はできるだけ少なくしています。主なチェックポイントは翻訳の確認です。記事を翻訳した後、スキルは翻訳を原文とセクションごとに比較し、人間の判断が必要な箇所だけを一覧にします。2つの解釈から1つを選ばなければならなかった箇所、慣用句を意訳した箇所、サイト上に定訳のない用語を使った箇所などです。
その一覧が空なら、翻訳は同じ実行の中で公開されます。空でなければ、翻訳ノートは指摘箇所をフロントマターに記した状態で Review 列で待機します。私はその箇所を確認し、必要に応じてノートを編集して Ready にするか、Claudeに適用してもらう指示を note に残します。必ず確認したい記事や、確認がまったく不要な記事については、記事ごとにこの設定を上書きできます。
スケジュールによる公開
これこそ、最初からずっと欲しかった部分です。公開は今や、Claudeルーティンの「Run now」を押すだけ、さらに言えば、ルーティンにスケジュールでパイプラインを実行させるだけになりました。スケジュール実行では、scheduledAt の順に新しい原文を最大1本と、確認済みの翻訳を公開し、何もすることがなければ静かに終了します。記事を予約するには、ノートに scheduledAt の日付を設定して Ready にするだけ。それだけです。
スキルがしないこと
公開はするが、執筆はしない。 下書き、推敲、手直しは、意図的にスキルの対象外にしています。それらは公開の段階ではなく、執筆の段階に属するものだからです。ノートにプレースホルダーのテキスト、見出しだけのセクション、文章があるべき場所に箇条書きの骨組みだけがあれば、スキルはそれを埋めません。作業を止め、何が未完成かを私に伝えます。編集は校正と軽い推敲までで、主張、意見、文体には手を加えません。1つの仕事を、きちんとこなす。
必要以上のものには触れない。 私のノートの本文を編集することは決してなく(作成中の翻訳ノートを除く)、ノートの名前を変えたり移動したりすることもなく、Vaultのものをリポジトリにコミットすることもありません。
黙って失敗しない。 どの実行も最後にレポートを出します。どのノートを処理したか、各記事がどこに配置されたか、公開日、軽微でない修正や個人情報の置き換え、確認待ちの翻訳、そしてスキップしたものとその理由です。下書きが未完成だったり、個人情報について確信が持てなかったり、ビルドが失敗したりしてノートがブロックされた場合は、ノートに手を付けずに理由を報告し、次のノートに進みます。手動実行の場合は、代わりに私に確認します。
まとめ
当初の問題が3つの段階でどうなったかをまとめます:
| 問題 | 手作業 | 最初のAIを介したワークフロー | 統合パイプライン |
|---|---|---|---|
| アセット管理 | 手作業でコピーし命名 | 手作業のまま | パイプラインがコピーし変換 |
| 下書きのステータス | 実質なし。執筆中の記事は別フォルダ | 変化なし | status プロパティ、カンバンボードに表示 |
| 次の記事の選定 | 手作業で見比べる | Claudeが選ぶ | フロントマターからキューを読む |
| 執筆環境 | コードエディタ | コードエディタ、またはObsidianで書いて変換 | Obsidian |
| 翻訳の手間 | 別作業で遅く、公開後 | 速くなったが別の実行 | 同じパイプラインのステージの1つ |
| 翻訳の管理 | 見落としやすい | 見落としやすい | requireTranslate とリンクされた翻訳ノート |
| 予約投稿 | 不可 | 不可 | scheduledAt とルーティンのスケジュール実行 |
| すべてを1か所に | いいえ | いいえ | ObsidianのVault |
振り返ると、最初のAIを介したワークフローは各ステップを速くしましたが、ステップ同士をつなぎ止める役は相変わらず私でした。本当の変化が訪れたのは、次にどのステップを自動化するかではなく、状態をどこに置くべきかを問うようになったときです。すべての記事、そのステータス、その翻訳が1か所に集まると、残りは1つのスキルが引き受けられるようになり、私の役割は、本当にやりたいこと、つまり書くことと、本当に人間が必要な少数の確認だけに縮まりました。