テックブログ始めました

まとめ

• ウェザーニューズのテックブログを開設しました
• エンジニア、広報、法務による多角的なレビューを導入します
• 一連の流れをシステマチックにするため、GitHub Actions を利用した自動化を図っています
• システム構築にあたり Vibe/Agentic Coding を最大限活用しました

はじめに

はじめまして、株式会社ウェザーニューズ陸上気象事業部の Hoshock です。
全社のモダン開発・クラウド化を推進しており、直近では新卒の開発研修リーダーを務めています。

この度、表題の通りウェザーニューズのテックブログを開設しました。
このブログでは、ウェザーニューズの開発チームの日々の開発や技術的な取り組みを共有していきます。

テックブログ

目的

まず、第一に組織のナレッジ資産化と人材育成を目的としています。
テックブログがあることで、個々のエンジニアが持つ暗黙知を、組織全体で共有可能なナレッジ資産へと転換できます。
また記事執筆のプロセス自体が、エンジニア自身の学びを深化させ、思考を整理する良質な機会となります。

技術ブランディングの確立、という点も重要です。
自社の技術や開発プロセスを公開することで、専門性と信頼性を社外に発信することができ、ウェザーニューズは「技術に力を入れている会社」である、とより多くの方に知っていただけることを期待しています。

スコープ

テックブログで投稿する記事の内容は、世の中一般のテックブログ同様、技術的な内容の多岐にわたります。
ウェザーニューズといえば気象ですので、気象に関連する技術はもちろんのこと、社内の開発プロセスやツール、インフラ、アーキテクチャ、最新の技術を使って〇〇してみた、などの実験的な取り組みも含みます。
エンジニアが自由な発想で気軽に記事を投稿できるように、トピックの制限はなるべくしない方針です。

プラットフォーム選定

プラットフォーム選定においては、以下の要素を重視しました。

• エンジニアに馴染みのある Markdown での執筆
• GitHub 連携
• SEO
• コミュニティの成熟度

これらの観点を総合的に検討した結果、最終的に Zenn を採用することにしました。

レビューシステム

テックブログの執筆を推進するにあたり、投稿される記事のレビューは必須です。
エンジニアによる技術的なレビューはもちろん、広報や法務の観点からのレビューも重要です。
Zenn は GitHub 連携が可能ですが、GitHub アカウントはエンジニアしか持っていないため、全員が GitHub 上でレビューすることができません。
そこで、GitHub 上では最低限のバリデーションのみ実行し、記事の内容自体は Zenn 上でレビューしてもらう方針にしました。
以下で詳しく見ていきます。

アーキテクチャ概要

テックブログの運用における全体的なアーキテクチャは以下のようになっています。

一連の流れ

記事の執筆

エンジニアは新しい記事を執筆する際、以下の手順で進めます。

1. Zenn CLI を使用してローカル環境で記事を執筆・プレビュー
2. main ブランチに向けた PR を作成

自動バリデーション

PR が作成されると、GitHub Actions により frontmatter に Zenn で必要なメタデータが揃っているかチェックします。

たとえば published: false の状態で PR が作成されていることを確認します。
記事自体は一旦下書きとして公開し、レビューを経てから世に公開するためです。

万が一のミスを防ぐため、バリデーションをパスしないと PR はマージできないように設定されています。

main マージによる GitHub Actions のトリガー

バリデーションをパスしたら、レビュイーが自分自身で PR をマージします。
PR が main ブランチにマージされると、以下の処理が自動で実行されます。

1. 下書き記事の公開。Publication のメンバーのみ閲覧可能
2. レビュアーに対し、Slack 上で下書き URL を通知
3. published: true に変更する PR を自動生成

レビュー

上記で通知された下書き記事に対し、エンジニア・広報・法務によるレビューが行なわれます。
Zenn のレビューシステムを利用しつつ、必要に応じて Slack 上でのやりとりも活用します。

記事の公開

全てのレビューが完了したら、自動作成されている記事公開 PR をレビュイーがマージし、正式な公開となります。

技術スタック

このテックブログシステムの実装には、以下の技術スタックを採用しました。

技術	説明
GitHub Actions	ワークフローの自動化と CI/CD パイプライン
Deno	モダンで安全な JavaScript/TypeScript ランタイム
TypeScript	型安全性による品質向上と開発効率化
Slack Incoming Webhook	レビュアーへの通知とワークフロー連携

GitHub Actions といえば yaml ファイルにコードを書くことが一般的ですが、メンテナンス性を考えコアな実装部分は TS で書きつつ、Deno 上で実行しています。
また、Deno には dax というライブラリがあり、これによりシェルスクリプトの辛さからも解放される点も大きなメリットです。

Vibe/Agentic Coding

このシステムの構築においては、Vibe/Agentic Coding を最大限に活用しました。
Github Copilot が全社的に導入されているため、Copilot Agent を Claude Sonnet 4 モデルで動かし、大部分のコードを生成しています。

大まかな開発のフローとしては

1. copilot-instructions.draft.md に実装計画（ドラフト）を記述
2. Anthropic のベストプラクティスに則り、copilot-instructions.md を作成させる
3. copilot-instructions.md をもとにタスクリスト copilot-tasks.md を作成させる
4. タスクリストをもとに自走してもらう
5. ユーザからフィードバックがあった場合、実装が完了したら copilot-adhoc-changes.md にその内容を記述させる

という感じです。
理想的には最初の段階ですべてのタスクを列挙しておくべきですが、実際にはアドホックな変更が多くなってしまいました。
すでに世の中の記事で取り上げられている内容ではありますが、重要だった点としては下記のとおりです。

• 曖昧さを避け具体的に指示する
• 実装前に計画をさせる
• t-wada メソッドの TDD を明示的に指定する
• linter, formatter, type checker を定期的に実行させる
• 暴走しそうだったらユーザが早めに止める（後の祭りになる前に）

今回のシステム実装は丸 2 日くらいでしたが、基本的に自分は軌道修正の役割に注力しました。
Claude Sonnet 4 を使い倒した結果、プレミアムリクエストを 80 % ほど消費することになりましたが、非常に大きな知見を得ることができました。

今後について

システマチックなテックブログ運用の下地ができたと思うので、あとはエンジニアが記事を書きやすい雰囲気を醸成し、持続的な投稿を促進していきたいと思います。
これからのウェザーニューズのテックブログにご期待ください！