技術ブログを運営する上で最大の悩みは「どうすれば継続的に質の高い記事を書けるか」です。多言語でコンテンツを提供したいなら、翻訳まで気にしなければならないので、負担が倍増しますよね。

/dev/writeはこうした悩みから生まれました。Hugo静的サイトジェネレーターにGitHub Copilotを組み合わせて、** 執筆に集中できる環境** を作ってみました。

なぜまたブログシステムなのか？

正直に言えば、既存のブログプラットフォームも十分優れています。Medium、Qiita、Zenn、どれも素晴らしい選択肢です。でも、いくつか物足りない点がありました。

まず、** 多言語対応** です。韓国語で書いた記事を英語と日本語でも提供したかったのですが、ほとんどのプラットフォームでは別アカウントや複雑な設定が必要でした。

次に、** AI学習データとして使用されることへの懸念** です。一生懸命書いた記事が同意なくAIモデルの学習に使われるのは、あまり気持ちの良いものではありませんよね。

そして、** 自動化されたワークフロー** です。記事を書いて、レビューして、翻訳して、公開するプロセスをできるだけ自動化したかったのです。

そこで、Hugo + PaperModテーマをベースに、この3つを解決するシステムを自作しました。

GitHub Copilotと一緒に執筆する

/dev/writeで最も面白い部分は、GitHub Copilotを執筆ツールとして活用する方法です。VS Codeで/コマンドを入力すると、様々なプロンプトを呼び出せます。

/create-draft Dockerコンテナネットワーキングについて書いて

こんな風にトピックだけ投げてもいいですし、もっと具体的にアウトラインを提供することもできます。

/create-draft
- トピック：Kubernetes入門
- 内容：Pod、Service、Deploymentの概念
- 対象読者：Dockerを知っている開発者

既存のREADMEやドキュメントがあれば、それをベースにチュートリアルを作ってもらうこともできます。

/create-draft このREADMEファイルを基にチュートリアル投稿を作って
#file:README.md

AIが全部書くわけじゃない

もちろん、AIに最初から最後まで任せることだけが答えではありません。むしろ** 自分でまず下書きを書いて、AIに肉付けしてもらう方式** の方が良い結果を出すことが多いです。

例えば、以前別のブログで書いた記事を持ってきて技術ブログスタイルで書き直したい場合：

/complete-manual-post この投稿を技術ブログスタイルで書き直して
#file:my-old-post.md

自分で書いた下書きがあれば、コード例を追加したり説明を補強してもらうこともできます。

私が書いたこの下書きを基に、内容をより豊かにしてください。
コード例を追加し、説明をより詳しくしてください。
#file:2025-12-05-my-draft.md

個人的な経験や意見が重要な記事、技術的な正確性を自分で検証したい記事は、このアプローチの方がはるかに効果的です。AIはあくまで助手であり、最終判断は人間がするものですから。

1つ書けば3つできる

/dev/writeのもう一つの特徴は** 自動翻訳** です。韓国語で記事を書くと、英語と日本語バージョンが自動的に生成されます。

もちろん機械翻訳には限界があります。でも、最初から3言語で書くよりはずっとマシですよね。翻訳結果をレビューして、必要な部分だけ修正すればいいのです。

翻訳過程で一貫性を維持するために、いくつかのルールがあります。

  • slug、translationKey、dateなどのメタデータはすべての言語で同一に維持
  • タイトル、タグ、要約、本文は各言語に翻訳
  • コードブロックは翻訳しない（当然ですよね！）

英語はAmerican Englishで、日本語はです/ます体で作成されます。技術用語は原語を維持するか、括弧で併記します。

翻訳が終わったら、検証スクリプトで3言語バージョンがちゃんと揃っているか確認します。

.\scripts\validate-translations.ps1

技術ドキュメントの正確性検証

技術ブログで最も重要なのは** 正確性** です。特にAzureや.NETなどMicrosoft技術を扱う時は、公式ドキュメントと一致するか確認するのが必須ですよね。

/dev/writeは** MS Learn MCPサーバー** を通じてこのプロセスを自動化しました。mcp.jsonファイルにMCPサーバーを登録して使用するように設定しています。

MCPサーバーがMicrosoft公式ドキュメントを照会して、最新APIバージョンか、非推奨の機能はないか、公式推奨事項と合っているかレビューしてくれます。ブログ記事に「この方法はもう推奨されていません」というコメントが付くのを事前に防げますよ。

予約投稿を実装してから廃止した理由

最初の実装では、未来のdateとGitHub Actionsのcronを組み合わせて予約投稿を行っていました。しかし実際に運用すると、GitHub Actionsが指定時刻どおりに開始するとは限りませんでした。ランナーの待機列やサービスの状況によって公開が遅れることがあります。

静的サイトの公開方式も予約投稿には合いませんでした。Hugoは未来の記事を一覧やビルド成果物から除外できますが、公開Gitリポジトリはサーバー認証や非公開コンテンツ保管の機能を提供しません。

そのため予約投稿を廃止しました。現在はdateに未来時刻を使わず、3言語すべてのdraftをfalseに変更したコミットをmainへ反映した時点で公開します。正確な公開時刻と公開前のアクセス制御が必要になった場合は、それらを提供する投稿プラットフォームの方が適しています。

AIクローラーの公開方針

/dev/writeは、公開コンテンツを検索や引用に利用できるように、主要なAIクローラーのアクセスを許可しています。robots.txtでは、GPTBot、Google-Extended、CCBot、anthropic-aiなどを明示的に許可しています。

robots.txtはクローラーに方針を伝えるためのものであり、アクセス制御を強制する仕組みではありません。この公開方針とは別に、コンテンツにはCC BY-NC 4.0ライセンスの条件が適用されます。

ローカルでプレビュー

投稿を公開する前にどう見えるか確認したいなら、Hugoサーバーをローカルで実行すればOKです。

hugo server -D

-Dオプションをつけるとdraft: trueの記事も見られます。ブラウザでhttp://localhost:1313にアクセスすると、リアルタイムでプレビューできます。ファイルを修正すると自動的にリフレッシュされるので、楽にチェックできますよ。

おわりに

/dev/writeはまだ完璧ではありません。でも、** 執筆に集中し、残りは自動化する** という目標はある程度達成できたと思います。

多言語対応、AIによる編集支援、翻訳検証、デプロイ自動化によって、公開に必要な基本の流れを整えました。プラットフォームに合わない機能は運用結果に基づいて取り除きながら、改善を続けていきます。

もし興味があれば、GitHubリポジトリを訪問してみてください。フィードバックはいつでも歓迎です。