技術ブログの課題をGitHub Copilotで解決

技術ブログの課題をGitHub Copilotで解決 - ブログをCopilot に定期レビューさせて最新を維持する -

PLAYER PROFILE CAREER 1st STAGE SIer ソースコード解析・開発環境構築 ▼ 2nd 某 Windows OS の会社で Azure 技術サポート ▼ NOW DJ SIer で SE / システムアーキテクト PLAYING NAME iboy Yohei Iwasaki S E / システムアーキテクト SKILL SET ☆12 Azure .......... AAA ☆8 フットサル ...... A ☆10 音ゲー ........ AA ☆7 ランニング ...... A X: @I_BOY_1204 | Qiita: iboy OUTPUT Qiita で Azure VM / Storage / Azure Files の検証・ノウハウを発信

TOPI C Qiitaの技術ブログを Copilot で定期レビュー 公開中の記事を、技術的な正しさの観点から定期的にチェックする話 記事はこちら iboyのマイページ – Qiita

やり始めたきっかけ 技術ブログを書くとき、こんなモヤモヤ、ありませんか？ 01 02 技術的に、本当にあってる？ 公開前にレビューしてほしい 自分が書いた記事の技術的な正しさを、誰か に確認してほしい 世に出す前に、第三者の目でひと通り読んで もらいたい そう思ったところから、自分で仕組みを作り始めた

レビューしてほしい観点 こだわりたい 3つの観点 ── その裏にある気持ちと一緒に 01 技術的な正しさ 02 ガイドライン準拠 03 読みやすさ 記載している仕様・手順が、最新 の事実と合っているか 投稿先（Qiita 等）のコミュニ ティガイドラインに沿っているか 読み手にすっと届く、わかりやす い日本語になっているか M OOD M OOD 「自信が無い…」 「炎上させたくない」 M OOD 「ちゃんと伝わってほ しい」

最初にやったこと 観点ごとに役割を分けた「ブログレビューエージェント」を作った ブログレビューオーケスト レーター AG ENT 01 AG ENT 02 技術レビュー Qiita ガイドライン MS Learn を参照しながら、技術 的正しさをチェック Qiita のコミュニティガイドライン に沿っているかチェック

最初に作ったレビュー Agent DIRECTORY リポジトリ構成 / └── .github/ └── agents/ ├── blog-review-orchestrator.agent.md ├── qiita-review.agent.md │ # Qiitaガイドラインに沿っているかをレビュー └── review-mslearn.agent.md # MS Learn に沿っているかをレビュー ORCHESTRATOR blog-review-orchestrator.agent.md

Next Step 観点ごとに役割を分けた「ブログレビューエージェント」を作った ブログレビューオーケスト レーター AG ENT 01 AG ENT 02 AG ENT 03 技術レビュー Qiita ガイドライン 読みやすさ MS Learn を参照しながら、技術 的正しさをチェック Qiita のコミュニティガイドライン に沿っているかチェック 日本語としての読みやすさを チェック（後から追加） POINT 『技術記事を書く技術（伊藤 淳一）』を読み、読みやすさの重要性に気づいて 03 を追加

• https://www.shoeisha.co.jp/book/detail/9784798177045

Agent 化して気づいたこと 運用してみたら見えてきた、3つのモヤモヤ 01 毎回はいらない 02 何度も呼びたい 03 選ぶのが手間 Qiita ガイドラインは、毎回 チェックする必要までは無い 技術レビューは、推敲のたびに何 度もかけ直したい どのエージェントを呼ぶか、毎回 自分で考えて起動するのが地味に つらい M OOD M OOD M OOD 「毎回はやりすぎ…」 「もっと気軽に呼びたい」 「めんどくさい…」 RESU LT 繰り返し使うものは、Skill 化しよう

現在の Agent/Skills の構造 Skill 化した新構成 DIRECTORY / └── .github/ ├── agents/ └── skills/ ├── reference/ │ ├── review-mslearn.md # 技術レビューの方法 │ │ │ ├── review-qiita.md │ │ │ └── review-readability.md │ # 日本語の読みやすさ # Qiita ガイドラインのレビュー方法 └── SKILL.md SKILL SKILL.md の中身

一つできるともっと欲が出る ISSUE 技術記事は仕様変更で正しくなくなることがある 定期的にレビューして正しさを担保したい 今やっている 3つのこと 01 定期的に一括でレビュー 02 直すところを Issue 化 03 記事ごとに Issue を分けたい 記事を放っておかず、定期的にまとめてチェックしたい レビュー結果をそのままタスクとして残せるようにしたい 全記事を一つにまとめられるとつらいので、記事単位で起票

実際に GitHub 上で動かすとこうなる 実際にGA時に変更された仕様

今直面している課題 GitHub Copilot の課金体系の変更への対応 IS SU E AC TIO N 01 AC TIO N 02 AI Credit の消費問題 定型処理のスクリプト化 GitHub Actions 起点化 今の構造だと、簡単に AI Credit を消費してしまう 記事の抜き出し、レビュー対象の リスト化、GitHub Issue 作成等、 固定化された処理はスクリプト化 レビューを GitHub Actions 起点 にするように検討中 「コストを抑えたい…」 「AI を使わない処理に」 「自動化で効率アップ」 NEXT 使いどころを見極めて、賢く節約

まとめ GitHub Copilot で Qiita 記事を定期レビューする仕組みを作った話 WHA T LEA RN NEXT やったこと 気づいたこと これからやること カスタム Agent で技術ブログをレ ビューする仕組みを構築 毎回 Agent を呼ぶのは重い・選ぶの も手間 GitHub Actions 起点で定期レ ビュー + 記事ごとに Issue 化 技術正確性 + Qiita ガイドライン + 読みやすさを観点に 繰り返し使う観点は Skill 化すると 軽くて再利用しやすい 定型処理はスクリプト化して AI Credit を節約 TAKEAW AY 小さく始めて、育てて、自動化していく

宣伝① YonaAz Infrastructure Night 日時：2026/06/30 21:00 から 形式：オンライン

宣伝② YonaAz Build Update Night 日時：2026/07/16 21:00 から 形式：オンライン

宣伝③ YonaAz オフラインイベント開催決定 日時：2026/08/27 19:00 ごろから 内容： AI x AVDに関連するトピック特集 登壇予定： 日本マイクロソフト 牛上様 Microsoft MVP 複数名 場所：gusuku Ashibinaa OSAKA 様 gusuku Ashibinaa OSAKA - アールスリーインスティテュート ｜R3 Institute ※懇親会もある予定です！

• https://www.r3it.com/ashibinaa?r34icsym=202608

宣伝④ Tokyo Jazug Night #61 日時：2026/07/10 19:00 から 形式：マイクロソフト品川本社＋Youtube

宣伝⑤ AI Dev Day 2026