開発効率化

Xで見つけたAI Skillを、GitHubで確認してからブログ運用に入れる流れ

AI 系の便利そうなツールは、X で流れてくることが多いです。ただ、見つけた勢いのまま自動インストールすると、後で「何を読ませたのか」「どこまで権限を渡したのか」が分かりにくくなります。

今回も、X で fireworks-tech-graph という Claude Code 向けの図解生成 Skill を見つけました。面白そうだったので、その場で使うのではなく、まず X の投稿内容と GitHub リポジトリを確認し、ローカルコピーに固定してから ichigoro.com の図解改善に使いました。

Xの投稿で知ったAI Skillを、GitHubリポジトリで確認し、ローカルコピー、外部import削除、ブログ図解への適用まで進める流れの図解
Xで見つけたAI Skillは、話題性よりも中身の確認とローカル固定を先に置く。

見つけたもの

今回見たのは、Berryxia.AI さんの X 投稿で紹介されていた fireworks-tech-graph です。

X 投稿では、Multi-Agent、RAG、Tool Call のような技術構成図を、Claude Code の Skill として自然言語から作れる、という趣旨で紹介されていました。手作業で図を揃えたり、色を整えたり、PNG として書き出したりする手間を減らす狙いです。

GitHub 側を見ると、README では「自然言語から SVG を作り、rsvg-convert で PNG にする」流れが説明されていました。図の種類は、Architecture、Data Flow、Flowchart、Agent Architecture、Memory Architecture、Sequence、Comparison、Mind Map などを想定していました。

すぐに入れなかった理由

こういう Skill は、普通のライブラリとは少し違います。実行コードが少なくても、AI エージェントに読ませる指示文として働くからです。

つまり、見るべきなのは「悪意あるスクリプトがあるか」だけではありません。次のような点も見た方がいいです。

  • 外部 URL を勝手に読ませる指示がないか
  • ローカルファイルや秘密情報に触れる指示がないか
  • 任意コマンド実行を広く促していないか
  • 出力先が雑で、既存ファイルを上書きしやすくないか
  • 変換時に外部フォントや CDN に依存していないか

今回見た範囲では、主な実行系の指示は SVG を作って rsvg-convert で PNG にすることでした。秘密情報を送るような明示的な指示は見当たりませんでした。

気になった点

一点だけ気になったのは、参照ファイルの中に Google Fonts の @import 例が残っていたことです。

README やメインの Skill では「外部 @import は使わない」「rsvg-convert と互換性を保つ」という方針が書かれていました。そのため、ここは方針とテンプレート例が少しズレていました。

セキュリティ事故というほどではありません。ただ、ブログ図解として使うなら、外部フォントに依存しない方が再現性は高いです。そこで、ローカルコピー側では Google Fonts の import 例を削って、システムフォントだけで生成する形にしました。

どう取り込んだか

自分の環境では、いきなり Claude Code のグローバル Skill として入れるのではなく、まず作業用ディレクトリに clone しました。

git clone https://github.com/yizhiyanhua-ai/fireworks-tech-graph.git /Users/yu/Dev/tools/fireworks-tech-graph

その上で、参照ファイルを見て、外部 @import の例だけローカルコピーで削りました。これなら、元リポジトリの内容と自分が変更した内容を分けて見られます。

また、図解の出力先は記事作業用のディレクトリに寄せました。ichigoro.com の記事では、本文の正本を article-drafts/fragments/ に置き、図解を article-drafts/assets/ に置く運用にしています。

実際に使った流れ

図解の生成と公開反映は、次のように進めました。

  1. 記事の中で図解が効く場所を選ぶ
  2. ローカルで SVG を作る
  3. rsvg-convert で PNG にする
  4. PNG を Xserver に転送する
  5. wp-cli で WordPress メディアへ import する
  6. 本文 HTML の画像 URL を WordPress のメディア URL に差し替える
  7. 公開 HTML と iPhone 幅の表示を確認する

この流れで、すでに公開済みだった 3 本の記事に図解を追加しました。

最初は横長図も試しましたが、スマホ表示では弱かったので、最終的には 1200 x 1600 の縦長図に寄せました。比較表の前や工程説明の前に置くなら、縦積みの図の方が読みやすいです。

取り込む時の判断基準

今回のような AI Skill を使う時は、次の順番が現実的だと思います。

  1. X では「候補を見つける」だけにする
  2. GitHub で README と Skill 本文を見る
  3. 外部通信、実行コマンド、出力先を確認する
  4. ローカルコピーに固定する
  5. 気になる参照やテンプレートを小さく直す
  6. 本番記事ではまず 1 枚だけ試す

これなら、話題になっているものを取り入れつつ、サイト運用としての安全性も保ちやすいです。

全部を自動化しない

今回よかったのは、AI に「図解を全部いい感じにして」と丸投げしなかったことです。

図の内容、モバイルでの読みやすさ、WordPress に入れた後の URL、公開 HTML、secret scan、iPhone 幅の表示確認は、人間側でチェックしました。

AI Skill は、作業を速くする道具としては便利です。ただし、ブログの公開物として残すなら、最後の責任は運用フロー側で持った方がいいです。

まとめ

X で見つけた AI Skill は、面白そうならすぐ使いたくなります。ただ、AI エージェントに読ませるものは、普通のリンク集より少し慎重に見た方がいいです。

今回の fireworks-tech-graph は、ローカルで確認して小さく直してから使う分には、ブログ図解の改善にかなり使いやすいものでした。大事なのは、X で見つける、GitHub で確認する、ローカルに固定する、小さく記事へ入れる、という順番です。

関連記事

この Skill を使って図解をブログへ入れた流れは、AIでブログ図解を作るなら、最初からモバイル前提にした方がいい にまとめています。運用側の基盤は、Codex と wp-cli でブログ運用を自動化する考え方 と WordPress 記事をローカルで書いてから下書き投入する方法 がつながります。

-開発効率化