今回、ブログのアイキャッチ作成でまさにここを踏んだ。
ChatGPTのCreate imageで作れる話と、Codexからローカルスクリプトを動かしてOpenAI Image APIを叩く話を、同じものとして扱いかけた。

この記事では、次回から迷わないために、ChatGPT画像生成とAPI画像生成の違いを整理する。

ChatGPT画面のCreate imageはChatGPT側の機能

OpenAI Helpでは、ChatGPTで画像を作る方法として、プロンプトで頼むか、入力欄横のツールから「Create image」を選ぶ方法が案内されている。
つまり、ChatGPTの画面内で画像生成できる。

ここで大事なのは、これはChatGPT側の利用枠で動くということ。
APIキーを使って自分のプログラムから呼び出しているわけではない。

だから、ブログのアイキャッチを1枚作るだけなら、まずChatGPT画面で作るのが自然だ。

OpenAI Image APIはAPIキーを使う

一方で、OpenAI Image APIは別の入口です。
コードからAPIキーを使って画像生成モデルを呼び出す。

たとえば、このような流れです。

記事タイトル
↓
ローカルスクリプト
↓
OPENAI_API_KEY
↓
OpenAI Image API
↓
画像ファイル生成

これはChatGPT画面のCreate imageとは違う。
APIのUsageやBilling側で見る話になる。

Codexで作業していると混ざりやすい

混乱の原因は、Codexが作業全体をまとめて動かせるからだと思う。

Codexに「アイキャッチも作って公開して」と頼む。
すると、Codexはローカルの公開スクリプトを探す。
そのスクリプトがOpenAI Image APIを呼ぶ作りなら、画像生成はAPI経由になる。

つまり、Codexに頼んだからChatGPT画面生成になる、とは限らない。

ここが落とし穴だった。

今回起きたこと

今回の流れはこうだった。

1. 記事を作った
2. アイキャッチも入れて公開したかった
3. ローカルの画像生成スクリプトを使おうとした
4. そのスクリプトはOpenAI Image APIを呼ぶ作りだった
5. 最初は安全ガードで止まった
6. その後、API経由で作ると明示して生成した

結果として、画像はきれいになった。
でも、これは「ChatGPT画面で無料枠を使った」のではない。
API側の画像生成だった。

ブログのアイキャッチはChatGPT画面を第一選択にする

次回からは、ブログのアイキャッチ作成はこの順番にする。

1. Codexで記事内容を読む
2. Codexでアイキャッチ用プロンプトを作る
3. ChatGPT画面のCreate imageで画像を作る
4. 画像を保存する
5. posts/images/ に置く
6. eye_catch に設定する
7. 公開する
8. og:image を確認する

この流れなら、追加API課金に流れにくい。
完全自動ではないけれど、ブログ運用としてはちょうどいい。

API生成は明示したときだけ使う

API生成が悪いわけではない。
むしろ、品質は安定しやすい。公開フローにも組み込みやすい。大量生成にも向いている。

ただし、API課金になる。
だから、通常のアイキャッチ作成では第一選択にしない。

APIを使うのは、次のときだけにする。

1. ユーザーがAPI経由で作ると明示した
2. 大量生成が必要
3. 手作業より速度を優先する
4. 費用を把握した上で使う

普段はChatGPT画面。
必要なときだけAPI。
これで分ける。

ローカルSVGの仮画像は最後の手段

今回、最初にローカルSVGで仮アイキャッチも作った。
これは追加API課金を避けるためだった。

でも品質は低かった。
理由は単純で、AI生成画像ではなく、その場で図形を組んだだけだったからだ。

緊急で画像枠だけ埋めるなら使える。
でも、ブログの顔としては弱い。

ローカルSVGは、次のようなときだけでいい。

1. ChatGPT画面で生成できない
2. APIも使わない
3. とにかく仮画像が必要
4. 後で差し替える前提

見分ける言葉

迷ったら、この言葉を見る。

1. ChatGPT / Create image: ChatGPT画面側の画像生成
2. OpenAI API: APIキーを使う開発者向けの呼び出し
3. OPENAI_API_KEY: API課金側へ行く可能性が高い
4. Usage / Billing: API利用量と請求を見る場所
5. Codex: 作業を進めるエージェント。使う道具次第でChatGPT画面にもAPIにも寄る

OPENAI_API_KEY が出てきたら、API側だと疑う。
ChatGPTの画面でCreate image なら、ChatGPT側の利用枠だと考える。

次回からのルール

このブログでは、アイキャッチ作成の基本をこうする。

1. ChatGPT画面のCreate imageを第一選択にする
2. Codexは画像プロンプト作成と保存・設定・公開確認を担当する
3. OpenAI Image APIは明示指示があるときだけ使う
4. ローカルSVG仮画像は緊急時だけ使う
5. 公開後は必ず og:image を確認する

これで、品質と費用の両方を見失いにくくなる。

関連記事

• ChatGPT PlusユーザーがCodexアプリで記事生成とアイキャッチ制作を進める手順
• ChatGPT画像生成APIの費用を確認するページ
• ブログの画像生成システムを gpt-image-1.5 に更新した。DALL-E 3 より安くできそうだった

参照元

• OpenAI Help: Creating images in ChatGPT
• OpenAI API Docs: Images and vision

The post ChatGPTで画像生成できるのに、なぜAPI課金になるのか first appeared on attrip.

ただし、PowerPointを今日から完全に捨てるというより、まずは資料作りの最初の場所をClaudeに移すのが現実的です。

Claudeで構成を作る。
HTMLやReactのArtifactsで見た目を作る。
必要になったら、画像、PDF、HTML、またはPowerPoint側で仕上げる。

この順番にすると、資料作りがかなり軽くなります。

Claudeで先に作ると直しやすい

PowerPointで資料を作ると、1枚ずつ文字や余白を直す時間が長くなりがちです。

ClaudeのArtifactsなら、資料を「完成画像」ではなく、編集できる部品として作れます。
Anthropicのヘルプでは、Artifactsの例として、Markdown文書、コード、単一ページHTML、図、Reactコンポーネントなどが挙げられています。

つまり、同じ内容のまま、

1. もっとシンプルにする
2. 営業資料っぽくする
3. セミナー用に大きな文字へ変える
4. スマホでも見やすくする
5. 色だけ変える

といった修正を、文章で頼みやすいです。

まずClaudeに渡すもの

最初からきれいなプロンプトはいりません。
必要なのはこの5つです。

そのまま使える依頼文

最初はこれで十分です。

次のメモをもとに、プレゼン資料を作ってください。
Artifactsで、1ページHTMLまたはReactコンポーネントとして見られる形にしてください。

目的:
相手:
枚数:
雰囲気:
必ず入れる内容:

条件:
- 1枚1メッセージにする
- 見出しは短く
- 文字を詰め込みすぎない
- スマホでも読める余白にする
- 最後に、発表で話す順番も短く付ける

Claudeが資料を出したら、次は見た目だけを変えます。

内容は変えずに、デザインだけ変えてください。
役員向けに、余白多め、色数少なめ、見出しを強くしてください。

別案も簡単です。

同じ内容で、セミナー用の明るいデザインに変えてください。
スライドごとに、話す一言メモも追加してください。

PowerPointが必要な場面はまだある

「もうパワポいらない」は半分当たりです。
でも、会社や取引先の都合でPowerPointが必要な場面は残ります。

特にこの3つです。

1. 社内テンプレートがPowerPointで決まっている
2. 相手がPowerPointファイルで修正したい
3. 印刷、配布、登壇環境がPowerPoint前提になっている

この場合は、Claudeで中身と見た目を先に作り、最後だけPowerPointへ寄せるのが楽です。

公式ヘルプで確認できる範囲では、Artifactsはコード表示、コピー、ダウンロードに対応しています。
PowerPoint形式の直接出力まで毎回保証される前提で組むより、HTML、PDF、画像、PowerPoint貼り付けの逃げ道を持っておくほうが安全です。

実際の作業順

おすすめはこの順番です。

1. Claudeに資料の目的とメモを渡す
2. ArtifactsでHTMLまたはReactの資料を作る
3. Claudeに「内容は変えずにデザインだけ変更」と頼む
4. 画面で確認する
5. 必要ならコピー、ダウンロード、PDF化、画像化する
6. PowerPoint指定があるときだけPowerPointへ移す

最初からPowerPointを開かない。
これだけで、かなり速くなります。

向いている資料

ClaudeのArtifactsが向いているのは、形を何度も変えたい資料です。

たとえば、

1. 勉強会スライド
2. 営業資料のたたき台
3. サービス説明ページ
4. 社内共有の図解
5. LPの構成案
6. SNS用のカルーセル案

逆に、会社指定の細かいテンプレートに1px単位で合わせる仕事は、最後にPowerPointやデザインツールで整えるほうが早いです。

まず1本作るならこの頼み方

迷ったら、こう頼めばいいです。

この内容を、10枚のプレゼン資料にしてください。
ClaudeのArtifactsで見られるHTML資料にしてください。
あとから色や雰囲気を変えやすいように、構造をわかりやすく作ってください。

読者:
目的:
メモ:

そのあとに、

同じ内容で、3パターンのデザインに変えてください。
1. 役員向け
2. セミナー向け
3. SNSで見せる用

ここまでやると、PowerPointで最初から悩む時間がかなり減ります。

パワポをやめるというより、最初に開かない

ClaudeのArtifactsを使うと、資料作りの最初の30分が変わります。

いきなりPowerPointで配置を考えるのではなく、まずClaudeで構成と見た目を作る。
同じ内容でデザインを変える。
必要なときだけPowerPointに持っていく。

これがいちばん現実的です。

完全に乗り換えるより、最初にPowerPointを開かない。
まずはそこからで十分です。

参考リンク

• Claude Help Center: What are artifacts and how do I use them?
• Claude Help Center: Publish and share artifacts
• Claude Blog: Build and share AI-powered apps with Claude

The post ClaudeのArtifactsでプレゼン資料を作る方法。パワポをやめる前に知っておくこと first appeared on attrip.

この記事では、繁体字向けページを作ったあとに、Google、Yahoo、Bing、Baiduをどう見るかを整理します。

登録するのは繁体字ページが入ったサイトマップ

まず確認するURLはこれです。

https://attrip.jp/wp-sitemap.xml

WordPress 5.5以降なら、標準でサイトマップが作られます。
繁体字ページが公開済みなら、そのURLもサイトマップ経由で見つけてもらえる状態にします。

Googleの公式ドキュメントでも、XMLサイトマップは通常ページだけでなく、多言語ページの情報を渡す方法として説明されています。

繁体字圏で見る検索エンジン

Googleだけ見れば十分、とは言い切らないほうがいいです。
ただし、優先順位はあります。

StatCounterの2026年6月データでは、台湾の検索エンジン比率はGoogle 81.88%、Yahoo! 10.51%、Bing 6.95%。
香港はGoogle 91.33%、Yahoo! 3.05%、Bing 2.94%、Baidu 0.34%です。

つまり、最初はGoogle。
次にYahoo/Bing。
中国本土も見るならBaiduです。

Yahooは独自にサイトマップを登録するというより、Bing側の登録を押さえるほうが現実的です。
そのため、ブログ運用ではこの順番にします。

1. Google Search Console
2. Bing Webmaster Tools
3. IndexNow
4. Baidu Webmaster Tools

Baiduは台湾・香港向けだけなら優先度は低いです。
中国本土の読者も取りたいなら、後で対応します。

Search Consoleでやること

Search Consoleを開いたら、左メニューの「サイトマップ」に進みます。

そこで送信するのは、まずこのURLです。

wp-sitemap.xml

ドメインプロパティなら、URL全体ではなく末尾だけ入力します。
URLプレフィックスのプロパティなら、画面に表示されている対象ドメインと一致しているか確認します。

送信後に見る場所は3つです。

1. ステータスが「成功」になっているか
2. 検出されたページ数が増えているか
3. 繁体字ページがインデックス対象になっているか

「成功」になっても、すぐ検索結果に出るわけではありません。
サイトマップは登録の保証ではなく、発見してもらうための入口です。

Bing Webmaster Toolsでやること

YahooとBingも拾いたいなら、Bing Webmaster Toolsにも登録します。
Microsoftのツールですが、Yahoo系の検索流入を見るときもここを押さえます。

やることはGoogleとほぼ同じです。

1. Bing Webmaster Toolsを開く
2. サイトを追加する
3. 所有権を確認する
4. 「Sitemaps」に進む
5. https://attrip.jp/wp-sitemap.xml を送信する
6. クロールエラーとインデックス状況を見る

Google Search Consoleからインポートできる場合は、それを使うと早いです。
すでにGoogleで所有権確認済みなら、Bing側の初期設定が短くなります。

IndexNowで更新を伝える

Bing系はIndexNowも使えます。
これはサイトマップとは別に、「このURLを更新した」と検索エンジンへ知らせる仕組みです。

やり方は2つあります。

1. WordPressのIndexNow対応プラグインを使う
2. 自分でIndexNow APIにURLを送る

ブログ運用なら、まずプラグインで十分です。
公開や更新のたびに、BingなどIndexNow対応検索エンジンへ通知できます。

サイトマップは全体の地図。
IndexNowは更新通知。
役割が違うので、両方使っていいです。

Baiduを見る場合

中国本土の繁体字・簡体字ユーザーも取りたいなら、Baidu Webmaster Toolsも候補です。
ただし台湾・香港だけを見るなら、最初から重くやらなくていいです。

Baiduで使うのは「百度搜索资源平台」です。
Google Search ConsoleのBaidu版、と考えるとわかりやすいです。

Baiduまでやる場合の流れはこれです。

1. Baidu Webmaster Toolsに登録する
2. サイト所有権を確認する
3. サイトマップを送信する
4. 中国本土で見えるURLか確認する
5. 簡体字ページを作るか判断する

Baiduは「繁体字ページを出せば終わり」ではありません。
中国本土向けなら、簡体字、表示速度、アクセス可否も別に見ます。

Baiduでサイトを登録する手順

まず百度搜索资源平台を開きます。

https://ziyuan.baidu.com/site/index

ログインしたら、站点管理からサイトを追加します。
対象は https://attrip.jp/ です。

所有権確認は、画面に出る方法から選びます。
よくあるのはこの3つです。

1. HTMLファイルをサーバーに置く
2. HTMLタグをトップページに入れる
3. DNSに指定レコードを追加する

WordPressブログなら、DNS確認がいちばん安全です。
テーマを触らずに済みます。
ただしDNSを変更するので、作業前に現在のDNS設定を控えます。

BaiduにURLを送る手順

サイト確認が終わったら、资源提交の「普通收录」に進みます。

https://ziyuan.baidu.com/linksubmit/index

ここで見るのは、主に2つです。

1. サイトマップ送信
2. URL送信

サイトマップが使える場合は、まずこれを送ります。

https://attrip.jp/wp-sitemap.xml

新しく作った繁体字ページだけ早く見つけてほしい場合は、URL送信も使います。
Baidu公式説明では、普通收录はクローラーがリンクを見つける時間を短くするためのツールです。
ただし、送信しても必ず収録されるわけではありません。

Baidu向けに先に確認すること

Baiduを見るなら、サイトマップ登録より前に確認したいことがあります。

1. 中国本土からページが表示できるか
2. ページの主要本文がJavaScriptなしで読めるか
3. 簡体字ページが必要か
4. 画像や外部スクリプトが重すぎないか
5. robots.txt でBaiduを止めていないか

台湾向けの繁体字ページをそのままBaiduへ出しても、読者と検索語がズレることがあります。
中国本土向けなら、繁体字より簡体字の別ページを作るほうが自然です。

Baiduは後回しでいいケース

次の場合は、Baiduを急がなくていいです。

1. 台湾・香港の読者が主目的
2. 記事が日本旅行、AIツール、WordPress運用中心
3. 中国本土向けの簡体字ページをまだ作っていない
4. 中国本土からの表示確認ができていない

この場合は、GoogleとBingまでで十分です。
Baiduは「中国本土を取りに行く」と決めてからでいいです。

繁体字ページ側で確認すること

サイトマップだけでは弱いです。
繁体字ページそのものも、検索エンジンにわかる形にします。

最低限見るのはこの4つです。

1. URLが公開済みで200を返す
2. noindex になっていない
3. 日本語ページと繁体字ページが内部リンクでつながっている
4. hreflang で言語違いの関係を伝えている

繁体字は、台湾向けなら zh-TW、繁体字全体なら zh-Hant と考える。
どちらを使うかは、記事の読者をどこに置くかで決めます。

台湾の読者を主に狙うなら zh-TW。
台湾、香港、繁体字圏を広く見るなら zh-Hant。

ユーザーを読み込むためにやること

サイトマップ登録は入口です。
読者を増やすには、繁体字ページの中身を「翻訳」ではなく「現地の検索」に寄せます。

やることはこの順番です。

1. 日本語で伸びている記事を選ぶ
2. 台湾・香港の人が検索しそうな言葉に直す
3. タイトルを繁体字で自然にする
4. 冒頭で答えを先に出す
5. 日本語記事へのリンクを置く
6. 日本語記事から繁体字記事へリンクする
7. Search ConsoleとBing Webmaster Toolsでクエリを確認する

一番大事なのは、タイトルです。
日本語の直訳タイトルは弱い。繁体字で検索する人が打つ言葉に寄せます。

たとえば「使い方」なら、文脈によって「使用方法」「怎麼用」「教學」に変わります。
日本語の感覚で固定しないほうがいいです。

最初に作るべき繁体字ページ

いきなり全部翻訳しない。
まずは検索意図がはっきりしている記事から始めます。

向いているのはこのタイプです。

1. AIツールの使い方
2. WordPressの設定
3. 日本旅行や天気の実用記事
4. エラー解決記事
5. 比較記事

読者が困って検索する記事は、言語を変えても届きやすいです。
日記や感想記事より、手順がある記事から始めます。

登録後に見る数字

Search ConsoleとBing Webmaster Toolsでは、繁体字ページだけを見ます。
見る数字は多くしない。

1. 表示回数
2. クリック数
3. 検索クエリ
4. 平均掲載順位

最初はクリック数より、表示回数を見ます。
表示されているなら、検索エンジンには届いています。
表示されないなら、サイトマップ、内部リンク、noindex、タイトルのどれかを疑います。

今日やる手順

今日やるなら、この順番で十分です。

1. 繁体字で出したい記事を1本決める
2. 繁体字版の記事を作る
3. lang を zh-TW または zh-Hant にする
4. 日本語記事と相互リンクする
5. https://attrip.jp/wp-sitemap.xml をSearch Consoleに送信する
6. 同じサイトマップをBing Webmaster Toolsにも送信する
7. IndexNowを有効にする
8. 数日後にSearch ConsoleとBing Webmaster Toolsで表示回数を見る

これで「作ったけど誰にも見つからない」を避けられます。

参考リンク

The post 繁体字ページを検索エンジンに見つけてもらうために、まずサイトマップを登録する first appeared on attrip.