ブログ記事に図解を入れるなら、AI で作ること自体よりも「公開したあとに読める形まで持っていく流れ」の方が大事だと感じました。今回、技術図を作るための Claude Code Skill を試しながら、ichigoro.com の既存記事に図解を追加してみました。
結論から言うと、AI 図解はかなり使えます。ただし、横長のきれいな図をそのまま貼るだけだと、スマホでは読みにくくなります。ブログ用なら、最初からモバイルで読める縦長図として作り、WordPress に入れたあと実表示まで確認する方が安全です。
今回やったこと
きっかけは、X で見かけた fireworks-tech-graph というリポジトリです。Claude Code 向けに、技術図や構成図を作るための Skill として公開されていました。
そのまま自動インストールするのではなく、まず中身を確認しました。見た範囲では、主な処理は SVG を作って rsvg-convert で PNG 化する流れでした。秘密情報を読むような指示や、外部に送信するような明示的な処理は見当たりませんでした。
一方で、参照ファイルの一部に Google Fonts の @import 例が残っていたので、ローカルコピー側では外部フォント import を使わない形に直しました。図解生成は便利ですが、AI に読ませる Skill はプロンプトでもあるので、ここは少し慎重に見た方がいいです。
Skill を見つけてからローカル運用に入れるまでの確認手順は、Xで見つけたAI Skillを、GitHubで確認してからブログ運用に入れる流れ に分けてまとめています。
最初に横長図で失敗した
最初は、よくある 16:9 の横長図として作りました。PC で見ると悪くなかったのですが、iPhone 幅で確認するとかなり小さく見えました。図全体は表示されていても、文字を読むには弱い状態です。
ブログ記事では、図があることより、本文の理解が速くなることの方が大事です。特にスマホで読む人が多い前提なら、横長の技術図は意外と相性が悪いです。
そこで、途中から方針を変えました。図を 1200 x 1600 の縦長にして、カードを縦に積む形にしました。すると iPhone 幅でも文字が読みやすくなり、本文の途中に入れても自然に読めるようになりました。
実際に差し替えた記事
今回は、開発効率化カテゴリの記事を中心に 3 本更新しました。
1 本目は、Codex と wp-cli の役割分担を図にしました。本文生成、ローカル原稿、下書き投入、公開前確認を分ける流れです。
2 本目は、ChatGPT、Claude、Cursor、GitHub Copilot を「ブラウザ中心か IDE 中心か」で選ぶ図にしました。比較表の前に置くことで、読者が自分の分岐を先に判断しやすくなります。
3 本目は、ブログ運用の有料ツールを「詰まっている工程ごとに足す」図にしました。ChatGPT、Notion、Canva、Rank Math、Buffer、Ahrefs を、用途ごとに整理しています。
ローカルで作ってから WordPress に入れる
今回の流れは、いきなり WordPress の投稿画面で画像を作るのではなく、ローカルで正本を作る形にしました。
- SVG をローカルで作る
rsvg-convertで PNG にする- PNG を Xserver に転送する
wp-cliで WordPress メディアに import する- 本文 HTML の画像 URL を WordPress のメディア URL に差し替える
- 公開 HTML とスマホ表示を確認する
この流れにすると、本文と図版の差分が手元に残ります。WordPress 側では、最後に media import と本文更新だけを行えばいいので、壊れた時にも戻しやすいです。
確認で見たポイント
図解を入れたあと、最低限見たのは次の点です。
- 画像 URL が公開ページに反映されているか
- 画像 URL が
200で返るか - 公開 HTML にローカルパスが残っていないか
- secret scan に引っかからないか
- iPhone 幅で図の文字が読めるか
特に最後のモバイル確認は重要でした。最初の横長図は、HTML としては正しくても記事中では弱かったからです。AI 図解では、生成結果を見て終わりにせず、記事の中で読めるかまで見る必要があります。
AI 図解を使う時の注意点
便利だった一方で、気をつけた方がいい点もあります。
Skill はコードではなくても確認する
Claude Code Skill のようなものは、実体としては指示文と参照ファイルです。直接の実行コードが少なくても、エージェントに読ませる以上、何を指示しているかは確認した方がいいです。
外部リソースを使わない
ブログ用の図解は、再現性が大事です。フォントやアイコンを外部 URL に寄せると、変換時や表示時に崩れる原因になります。今回は外部 @import を使わず、システムフォントだけに寄せました。
横長図を前提にしない
技術図は横長にしたくなりますが、ブログ本文では縦長の方が読みやすいことが多いです。特に工程図や選び方の図なら、スマホ幅に合わせて縦に積んだ方が自然です。
今後の使いどころ
この流れは、開発効率化カテゴリの記事と相性がいいです。たとえば、AI エージェントの止まり方、ブログ下書き投入、WordPress 運用、ツール比較のような記事は、文章だけより図がある方が理解しやすくなります。
一方で、すべての記事に図解を入れる必要はありません。読者の判断が早くなる場所、比較表の前、工程説明の前、失敗しやすいポイントの整理などに絞って入れる方が良さそうです。
まとめ
AI でブログ図解を作るなら、単に「きれいな図が作れるか」ではなく、「公開後にスマホで読めるか」まで含めて考えた方がいいです。
今回の作業で一番効いたのは、ローカルで SVG と PNG を作り、WordPress にはメディアとして登録し、最後に iPhone 幅で確認する流れでした。AI 図解は、この確認フローまでセットにすると、ブログ運用にかなり組み込みやすくなります。
関連記事
今回図解を入れた記事は、Codex と wp-cli でブログ運用を自動化する考え方、エンジニア向けAIツールおすすめ比較、ブログ運用を効率化する有料ツールまとめ です。WordPress へローカル原稿を入れる流れは、WordPress 記事をローカルで書いてから下書き投入する方法 もつながります。