とくに確認しておきたいのが、モデルIDのgpt-5.6です。この名前は三モデルから自動的に適したものを選ぶのではなく、最も高い能力を持つSolへ振り分けられます。gpt-5.6をそのまま指定すると、求める品質に対して必要以上の費用を払う可能性があります。

この記事で扱うのは、ChatGPTの月額プランではなく、OpenAI APIの従量料金です。2026年8月9日に確認した公式資料を基に、三モデルの違いと、小さな業務ツールでの比べ方を整理します。

「gpt-5.6」は3モデルを自動で選ぶ名前ではない

GPT-5.6には、Sol、Terra、Lunaがあります。OpenAIはSolを複雑な専門業務向けのフロンティアモデル、Terraを能力と費用のバランスを取るモデル、Lunaを費用を重視する大量処理向けのモデルと説明しています。

ここで気を付けたいのが、末尾に名前が付かないgpt-5.6です。公式のモデル案内では、このエイリアスはgpt-5.6-solへ振り分けられます。処理内容を見てLunaやTerraへ切り替わる仕組みではありません。

既存の設定をgpt-5.6へ書き換えるだけなら、利用するのはSolです。Solが必要な仕事なら問題ありませんが、決まった項目の抽出や大量の分類にも同じモデルを使うべきかは、料金と結果を見て決める余地があります。

入力料金はLuna 0.20ドル、Terra 2ドル、Sol 5ドル

OpenAIが公表している100万テキストトークン当たりの料金は次のとおりです。

SolとLunaを比べると、入力も出力も25倍です。TerraとLunaの差は10倍あります。処理件数が少ないうちは差が小さく見えても、同じ作業を毎日繰り返す仕組みでは、モデルの選択が費用へ直接影響します。

概算費用は、入力トークン数を100万で割って入力単価を掛け、同じように計算した出力費用を足せば求められます。検索やコンピューター操作など、別料金のツールを使う場合は、その料金も分けて確認します。

三モデルとも、公式ページの無料利用枠のレート制限欄は「非対応」です。試験であっても従量料金が発生する前提で、利用上限と記録方法を先に決めておく方が安全です。

扱える長さと主要機能は3モデルで共通する

料金が安いLunaだけ、短い入力しか扱えないわけではありません。公式の比較表では、三モデルともコンテキストウィンドウは105万トークン、最大出力は12万8,000トークンです。知識の基準日も2026年2月16日でそろっています。

ストリーミング、関数呼び出し、構造化出力、画像入力も、三モデルすべてが対応しています。長い資料を渡せるか、決まったJSON形式で返せるかという機能だけでは、モデルを一つに絞れません。

ただし、扱える長さと通常料金は別です。27万2,000トークンを超える入力では、入力料金が2倍、出力料金が1.5倍になります。キャッシュへの書き込みも、通常の入力料金の1.25倍です。大量の資料を毎回そのまま送る設計では、モデル選びだけでなく、入力を減らす方法やキャッシュの使い方も検討する必要があります。

また、三モデルはテキストの入出力と画像入力に対応しますが、音声と動画には対応していません。長い入力が使えることを、あらゆる種類のデータを直接扱えることと混同しないようにします。

Luna・Terra・Solは仕事の量と複雑さに合わせて候補を変える

三モデルを「安い・普通・高い」だけで分けると、仕事との対応が見えません。公式の説明に沿えば、Lunaは費用を抑えたい大量処理、Terraは能力と費用の両立、Solは複雑な専門業務が出発点になります。

AIやまらぼで候補を分けるなら、Lunaから試すのは、同じ形式のデータを繰り返し分類する仕事です。記事候補へカテゴリーを付ける、決まった項目をJSONへ抜き出す、禁止語が含まれる箇所を列挙するといった処理が考えられます。正解の形式を決めやすく、人が結果をまとめて確認できるためです。

Terraは、費用だけでなく文章の整合性も見たい日常業務の候補にします。記事構成の比較、既存文の修正案、複数条件を反映した下書きなどです。Lunaでも合格条件を満たすなら下げ、満たさない場合にTerraを残します。

Solは、複数の資料と制約を同時に扱う仕事や、見落としの影響が大きい仕事でTerraと比較します。ただし、Solを使っただけで結果が正しいとは限りません。最上位という名前ではなく、実際の出力が合格条件をどれだけ満たしたかで判断します。

同じ仕事と合格条件で、品質・時間・費用を測る

モデルを比べる前に、日常業務から代表的な入力例を用意します。都合のよい一例だけでなく、短い入力、長い入力、判断が分かれやすい入力を含めます。モデルごとに指示を変えると比較しにくいため、最初は同じ指示と同じ出力形式を使います。

次に、出力を見る前に合格条件を決めます。たとえば記事候補の分類なら、指定したカテゴリーだけを使う、URLを変えない、根拠のない説明を加えない、JSONの項目を欠かさないといった条件です。文章なら、一次情報にない数値を加えない、指定語を自然に含める、見出しと本文を一致させるなど、用途に合わせて確認します。

記録するのは正誤だけではありません。入力と出力のトークン数、処理にかかった時間、再試行の回数、1件当たりの費用も残します。OpenAIのモデル案内も、代表的な仕事で品質、必要な根拠、トークン数、待ち時間、費用を比較するよう勧めています。

最初から三モデルすべてを常用する必要はありません。公式の用途説明に近い二モデルで比較し、安い方が合格条件を安定して満たすなら採用する。満たさない場合だけ上位モデルや推論設定を試す方が、違いを確認しやすくなります。

AIやまらぼでは公開前の確認をモデル選びから分ける

AIやまらぼの記事制作でGPT-5.6 APIを使うなら、候補の分類や項目抽出はLuna、構成や下書きはTerra、複数の公式資料をまたぐ事実確認はTerraとSolの比較対象にします。これは各モデルの性能を保証する決め方ではなく、試験を始める順序です。

どのモデルが合格しても、記事の本番公開は自動化しません。一次情報と本文の照合、料金や提供条件の再確認、画像と代替テキストの確認を人が行い、公開操作を分けます。顧客への送信、契約、会計処理、既存データの削除も同じです。

モデルの費用と、誤った結果を外部へ出したときの影響は別に考える必要があります。安いモデルでも確認しやすい仕事なら使えます。高いモデルでも、公開や確定を任せてよい根拠にはなりません。

GPT-5.6へ移行するときは、まずコードや設定にあるモデルIDを確認します。gpt-5.6ならSolです。そのうえで、同じ仕事をLunaやTerraでも試し、合格条件を満たす最も安い構成を選びます。モデル名の印象ではなく、自分の仕事で測った結果を残すことが、次の見直しにもつながります。

参照したOpenAI公式資料

• Model guidance
• Compare models
• GPT-5.6 Sol
• GPT-5.6 Terra
• GPT-5.6 Luna

数千円の契約でも、三つ、四つと重なると大きな固定費になります。一方で、使っていないからとすぐ解約すると、必要なチャット履歴、作った画像、カスタム設定、ほかのサービスとの連携まで失うことがあります。

サブスクの整理は、解約ボタンを押す作業ではありません。請求元を特定し、残すデータと影響範囲を確認してから止める作業です。

この記事では、AIサブスクを安全に減らすためのチェックリストを紹介します。

最初に契約一覧を作る

覚えているサービスだけを並べると、使っていない契約ほど漏れます。次の場所を確認します。

• クレジットカードと銀行口座の明細
• App Storeのサブスクリプション
• Google Playの定期購入
• PayPalなどの継続支払い
• メールに届いた領収書、請求書、更新案内
• 会社やチームの経費精算記録

サービス名と請求名が違うこともあります。金額だけで判断せず、領収書メールや契約画面で確認します。

「使っていない」を利用記録で確かめる

印象だけで解約を決めず、直近一か月から三か月の利用を確認します。

• 最後にログインした日
• 作った文書、画像、動画の数
• そのサービスでしかできない作業
• 無料プランへ戻しても困らないか
• ほかのサービスと機能が重複していないか

月に一度しか使わなくても、請求書処理や重要な定例作業に必要なら、単純な利用回数だけでは判断できません。反対に、毎日開いていても無料プランで足りることがあります。

解約とアカウント削除を分ける

有料プランの解約と、アカウントそのものの削除は別の操作です。

解約は、次回以降の有料更新を止め、無料プランへ戻る形が一般的です。アカウント削除は、ログイン情報や保存データを含めて消す操作で、取り消せない場合があります。

固定費を減らすだけなら、まず有料プランの解約で十分か確認します。データを完全に消したい場合は、エクスポートと保管義務を確認した後に、別途アカウント削除を検討します。

必要なデータを先に書き出す

解約後も履歴へアクセスできるかは、サービスやプランによって異なります。次のデータが残っていないか確認します。

• 仕事で再利用するプロンプト
• チャット履歴と調査メモ
• 生成した画像、動画、音声
• カスタムGPT、Gem、プロジェクトなどの設定
• アップロードした資料
• 請求書と領収書

ChatGPTには、設定やPrivacy Portalからデータを書き出す方法が公式ヘルプで案内されています。書き出しに時間がかかる場合があるため、更新日の直前ではなく余裕を持って申請します。

ダウンロードしたファイルは、内容を開いて確認します。「エクスポートを押した」だけでは、必要な画像や設定が含まれているか分かりません。

外部連携と自動化を確認する

使っていないように見えるAIサービスが、裏側で動いていることがあります。

• WordPressの自動投稿
• 問い合わせの要約
• Google DriveやSlackとの連携
• ブラウザ拡張機能
• Zapier、Make、独自スクリプト
• APIキーを使った処理

解約後に突然止まると困るため、連携先の一覧と実行履歴を確認します。代替サービスへ切り替える場合は、先にテストし、正常に動いてから元の契約を止めます。

不要になったAPIキーや連携権限は、解約とは別に削除します。

請求元によって解約場所が違う

公式サイトで契約したサブスクは、通常そのサービスの設定や請求画面から解約します。iPhoneやAndroidで契約した場合は、App StoreまたはGoogle Play側での操作が必要になることがあります。

OpenAIの公式ヘルプでも、Webで申し込んだChatGPTと、App Store・Google Play経由の契約では解約場所が異なると案内されています。Google AIプランはGoogle Oneの設定から管理します。

アプリを削除しただけでは、サブスクリプションが止まらない場合があります。必ず契約画面で「解約済み」「次回更新なし」などの表示を確認します。

更新日と解約後の利用期限を記録する

解約がすぐ有効になるのか、次回請求日の後に有効になるのかは、サービスによって異なります。

ChatGPTの個人向けサブスクリプションについて、OpenAIは次回請求を避けるため請求日の24時間以上前に解約するよう案内しています。こうした期限は変更される可能性があるため、実際の解約時に公式画面を確認します。

解約後は、次の三点を記録します。

• 解約操作をした日時
• 有料機能を使える最終日
• 解約完了画面または確認メール

スクリーンショットを保存するときは、カード番号など不要な個人情報が写っていないか確認してください。

迷う契約は、いったん無料プランで試す

解約して困るか判断できない場合は、無料プランへ戻し、一か月仕事を続けてみます。

不足した機能と、そのために余計にかかった時間を記録します。必要性がはっきりすれば再契約できます。再契約が簡単なサービスを、使うかもしれないという理由だけで払い続ける必要はありません。

ただし、再契約時に以前の料金や特典が戻るとは限りません。長期割引や旧プランを利用している場合は、失う条件を確認してから決めます。

解約前の最終チェックリスト

• 公式サイト、App Store、Google Playのどこで契約したか分かった
• 次回更新日と解約期限を確認した
• 必要なチャット、画像、設定、領収書を書き出した
• 書き出したデータを実際に開いた
• 外部連携と自動化への影響を確認した
• 無料プランへ戻した場合の制限を確認した
• 解約とアカウント削除を混同していない
• 解約完了画面またはメールを保存した
• 不要なAPIキーと連携権限を削除した

AIサブスクは、契約するときより解約するときの方が確認事項が多くなります。だからこそ、契約した日から「請求元・更新日・保存データ」を一覧へ残しておくと、次の見直しが楽になります。

AIサブスクの解約でよくある質問

解約したら、すぐ使えなくなりますか

次回更新日まで使えるサービスもあれば、条件が異なるものもあります。解約確認画面に表示される利用終了日を確認し、必要な作業はその日より前に終えます。

アプリを削除すれば課金も止まりますか

通常、アプリの削除だけでは定期購入は解約されません。公式サイト、App Store、Google Playなど、実際に契約した場所で解約状況を確認します。

領収書はいつまで残しますか

事業で経費にしている場合は、税務や社内規程に必要な期間を確認します。アカウント削除後に取得できなくなる可能性があるため、解約前にまとめて保存し、ほかの業務書類と同じルールで管理します。

固定費を減らすことだけを目標にせず、仕事に必要なデータと仕組みを守りながら整理してください。

ただし、届いたメールをそのまま貼り付けるのは避けるべきです。本文には、氏名やメールアドレスだけでなく、注文番号、住所、契約内容、未公開の案件情報などが含まれていることがあります。

個人情報保護委員会も、生成AIサービスへ個人データを入力する場合、利用目的の範囲内か、提供事業者が機械学習へ利用しないことなどを十分確認するよう注意を促しています。

この記事では、問い合わせ原文を残しながら、AIへ渡す情報を最小限にして返信案を作る手順を説明します。

原文は消さず、作業用のコピーを作る

最初に、受信したメールや問い合わせ管理画面の原文をそのまま保存します。匿名化するのはコピーした作業用テキストです。

原文まで書き換えると、後で事実関係を確認できなくなります。AIが作った文章と元の問い合わせが混ざらないよう、保存場所も分けます。

1. 原文を問い合わせ管理画面または指定の保管場所へ残す
2. 返信作業用のコピーを作る
3. コピーから不要な情報を削除・置換する
4. 匿名化した文章だけをAIへ渡す

氏名とメールアドレス以外にも注意する

消す対象は、名前と連絡先だけではありません。ほかの情報と組み合わせれば個人や案件を特定できる内容もあります。

問い合わせの内容によっては、病歴、口座情報、子どもの情報など、特に慎重に扱うべき内容も含まれます。返信文を作るだけなら、通常はAIへ渡す必要がありません。

回答に必要な事実だけを残す

匿名化した後、問い合わせを三つに分けます。

• 相手が知りたいこと
• 回答に必要な事実
• こちらで確認しなければならないこと

たとえば「商品が届かない」という問い合わせなら、AIに必要なのは「発送済みか」「配送状況を確認できるか」「案内する窓口はどこか」です。実際の住所や注文番号は、社内システムで人が確認します。

AIへは「顧客から配送状況の確認依頼が来た。発送状況は担当者が確認中。確認後に連絡すると伝える返信案を作る」と渡せば、個人情報なしでも文章を作れます。

匿名化した問い合わせの例

元の文章

山田太郎です。7月18日に注文した商品がまだ届きません。注文番号はAB-123456、届け先は東京都○○区です。明日使いたいので、090-XXXX-XXXXへ連絡してください。

AIへ渡す文章

顧客から、数日前に注文した商品が届いていないと連絡がありました。翌日に使用予定です。配送状況は担当者が確認中です。心配をかけていることへのお詫びと、確認後に登録済みの連絡先へ案内する旨を含む返信案を作ってください。

返信案を作るために不要な氏名、注文番号、住所、電話番号を外しました。一方で、「急いでいる」「配送状況は確認中」という、文面の調子を決める情報は残しています。

データ設定を変えても、入力してよいとは限らない

AIサービスには、会話をモデル改善へ利用するか選べる設定や、一時チャット機能があります。OpenAIのData Controlsでも、会話をモデル改善へ使うか選択できることが案内されています。

しかし、設定をオフにしたことは、顧客情報を自由に入力してよいという意味ではありません。自社のプライバシーポリシー、顧客との契約、利用中プランのデータ取扱い、社内ルールを確認します。

業務用プランと個人向けプランでは、管理機能やデータの扱いが異なる場合があります。「同じサービス名だから同じ」と考えず、実際に使う契約の公式情報を確認してください。

AIへ返信案を頼むときの指示

以下は個人情報を削除した問い合わせの要約です。
事実を追加せず、丁寧で簡潔な返信案を作ってください。
・分からないことを断定しない
・返金、納期、補償を勝手に約束しない
・確認が必要な箇所は［要確認］と書く
・相手の氏名や注文番号を推測しない
・件名と本文を分けて出す

AIが出した文章に、存在しない規約、期限、担当部署が追加されていないか確認します。

送信前は原文と照合する

最終確認では、匿名化した文章ではなく原文へ戻ります。

• 相手の質問すべてに答えているか
• 氏名、商品名、注文状況を取り違えていないか
• 返金、交換、期限などを勝手に約束していないか
• 社内だけで使う文章が残っていないか
• 返信先と添付ファイルが正しいか

［顧客］［注文番号］［要確認］などの置換記号が残っていれば、送信前に気づけます。検索機能で「［」を探す方法も有効です。

安全な返信作業のチェックリスト

1. 原文を正しい場所へ保存した
2. 作業用コピーから個人情報と秘密情報を外した
3. 回答に必要な事実だけを残した
4. 利用サービスのデータ設定と契約条件を確認した
5. AIへ事実を追加しないよう指示した
6. 返信案を原文、規約、社内情報と照合した
7. 宛先と添付ファイルを人が確認した

問い合わせ返信でAIに任せるのは、文章のたたき台です。顧客情報の取扱い、事実確認、最終的な送信判断は人が担います。

問い合わせ返信でよくある質問

会社名を消せば匿名化できていますか

会社名だけでは不十分なことがあります。担当者名、商品名、日時、金額、地域などを組み合わせると案件を特定できる場合があります。返信案に必要かどうかを一項目ずつ判断します。

有料の業務プランなら原文を貼ってもよいですか

プラン名だけでは判断できません。契約、データ処理条件、管理者設定、自社の利用目的と社内ルールを確認します。入力できる契約であっても、返信作成に不要な情報は渡さない方が安全です。

匿名化もAIに任せられますか

補助には使えますが、匿名化前の原文をAIへ渡すことになるため順序が逆になります。ローカル処理や承認済みの仕組みがない場合は、人が作業用コピーから情報を外し、その後の文章だけをAIへ渡します。

この役割分担を決めておけば、毎回ゼロから悩まず、安全性と作業時間の両方を管理しやすくなります。

AIは、人物、机、色、背景など、画面に写っている物を詳しく説明できます。しかし、alt（代替テキスト）で本当に伝えるべきなのは、そのページで画像がどんな役割を持っているかです。

同じコーヒーカップの写真でも、商品紹介なら色や形が重要です。記事の区切りに置いた飾りなら、何も読み上げない方がよい場合があります。

この記事では、画像を四つに分け、AIへ適切なaltを作ってもらう手順を紹介します。

altは「画像の説明」ではなく「画像の代わり」

画像が表示されないときや、スクリーンリーダーでページを読むとき、altは画像の代わりに内容や機能を伝えます。

そのため、写真に写る物をすべて列挙する必要はありません。画像を見られなくても、記事の意味や操作が分かる情報を残します。

W3Cの判断手順でも、画像が情報を伝えるのか、リンクやボタンとして機能するのか、装飾なのか、複雑な図なのかによって扱いを分けています。まず分類し、その後に文章を考えます。

最初に画像を四つへ分ける

「画像があるから何か書く」のではなく、画像を消したときに失われる情報があるかを考えます。

写真やイラストは、記事との関係を書く

たとえば、料金比較の記事に「やまとーるちゃんが三枚の料金カードを見比べているイラスト」があるとします。

悪い例は、「茶色い髪の女性、机、紙、緑色のキャラクター、白い背景」です。物は説明していますが、画像の意味が伝わりません。

「条件の違う三枚の料金カードを見比べるやまとーるちゃん」の方が、記事との関係が分かります。

人物の服装や背景色が記事の理解に不要なら、省いて構いません。反対に、商品の色や損傷状態を説明する記事なら、見た目の詳細が重要になります。

リンク画像は、移動先を伝える

ロゴ画像をクリックすると公式サイトへ移動する場合、「会社の青いロゴ」と書くだけでは、何が起きるか分かりません。

「○○公式サイトへ」のように、リンクの目的を伝えます。画像の隣に同じ文字のリンクがあり、重複して読み上げられるなら、空のaltが適切な場合もあります。

AIへ画像だけを渡しても、リンク先は分かりません。URLとクリック後の動作を一緒に伝える必要があります。

装飾画像には、何も書かない判断もある

区切り線、背景の模様、意味を持たない飾り、本文と同じ内容を繰り返す画像は、空のalt（alt=""）を検討します。

「空欄だとSEOに悪いかもしれない」と考えてキーワードを入れると、スクリーンリーダーでは不要な説明が増えます。

Googleも、画像の周辺に関連する文章を置き、altには画像を説明する有用な内容を書くよう案内しています。キーワードを詰め込む欄ではありません。

グラフや図解は、本文にも結論を書く

複雑なグラフを一文だけで完全に説明するのは困難です。altには、図の種類ともっとも重要な傾向を書きます。

たとえば「一月から六月まで問い合わせ件数が増え、六月が最多になった折れ線グラフ」です。正確な数値や例外は、画像の直前または直後の本文に表として置きます。

画像を見られない読者だけが情報を失う構成にしないことが大切です。

AIへ渡す情報は、画像だけでは足りない

AIにalt案を作ってもらうときは、次の四点を渡します。

1. 記事のタイトルと、画像がある見出し
2. 画像の前後にある文章
3. 画像の役割（写真、リンク、装飾、図解）
4. 画像を見られない人へ残したい情報

この記事は「AIサービスの料金比較表を正確に作る方法」です。
画像は、条件の違う料金カードを比べる場面のイラストです。
装飾ではなく、比較条件を揃える必要性を補足します。
画像内に意味のある文字はありません。
物を列挙せず、自然な日本語で短いalt案を3本出してください。

三案を作らせたら、もっとも短い案を選ぶのではなく、記事の意味が残る案を選びます。

WordPressで設定するときの注意

WordPressの「代替テキスト」は、メディアライブラリの説明文やキャプションとは別です。

• 代替テキスト：画像の代わりに内容や機能を伝える
• キャプション：画面上で読者に見せる補足や出典
• 説明：メディアページや管理用に使われることがある

出典や撮影者名を読者へ見せたい場合は、altだけに入れずキャプションや本文にも書きます。

同じ画像を別の記事で使うとき、役割が変わればaltも変わる可能性があります。メディアライブラリの文言を毎回そのまま使わず、掲載場所で確認します。

公開前のaltチェック

• 画像の役割を先に分類した
• 物の一覧ではなく、記事で必要な意味を書いた
• リンク画像は移動先や動作が分かる
• 装飾画像へ不要な説明を入れていない
• 複雑な図の詳しい情報を本文にも書いた
• 周辺の文章と同じ内容を繰り返していない
• SEOキーワードを不自然に詰め込んでいない

最後に、画像を隠してaltだけを読んでみてください。記事の理解や操作に必要な情報が残り、余計な説明が続かなければ、そのページに合ったaltになっています。

altについてよくある質問

altは何文字以内にすればよいですか

厳密な文字数だけで決めるより、画像の役割を過不足なく伝えることを優先します。短い写真説明なら一文で十分です。複雑な図を長いaltだけで説明せず、詳しい内容を本文や表へ移します。

アイキャッチ画像にもaltは必要ですか

テーマ内で画像がどのように表示されるかによります。記事タイトルの直後に同じ内容の画像があり、説明が重複するなら空のaltが適する場合があります。画像自体に記事理解へ必要な意味があるなら、簡潔に伝えます。

画像生成AIが作ったことをaltへ書きますか

AI生成であることは、altではなくキャプションや記事の表示欄で伝える方が分かりやすい場合があります。altの目的は、画像の内容や機能を代替することです。サイトの編集方針に合わせて表示場所を決めます。

AIは画像の中身を説明するのが得意です。何を伝えるべきかを決めるのは、記事の目的を知っている人の役目です。

問題は、表がきれいなほど間違いに気づきにくいことです。月払いと年払いの月額換算、税込と税別、個人向けと法人向け、無料プランと無料体験が、同じ条件のように並ぶことがあります。

料金比較表は、AIに価格を探してもらうところから始めません。公式ページで確認した情報を同じ条件へ揃え、その記録をAIに整形させるのが安全です。

ここでは、ブログ記事や社内資料で使える料金比較表の作り方を、確認項目から更新方法まで順番に説明します。

料金より先に「確認日」と「公式URL」を記録する

AIサービスの料金やプラン内容は変わります。検索結果に表示された古い記事や、AIが学習した過去の価格を混ぜないため、比較表の一行目には確認日を置きます。

最低限、次の情報を一緒に残します。

• サービス名とプラン名
• 公式料金ページのURL
• 確認した日時
• 表示された国・地域と言語
• 通貨

金額だけをコピーすると、後で変更されたときに根拠をたどれません。URLと確認日があれば、公開直前や定期更新の際に差分を確認できます。

「月額」の条件を揃える

同じ月額でも、中身は同じとは限りません。比較する前に、次の条件を別の列へ分けます。

年払いだけ安くなるサービスなら、「年払い時の月額換算」と明記します。月払いの金額と同じ列へ数字だけ置くと、読者は同じ契約条件だと誤解します。

機能名ではなく、仕事で使う条件を比べる

「高性能モデル」「高度な画像生成」「優先アクセス」といった機能名だけでは、どのプランが合うか判断できません。

先に利用目的を決め、仕事に必要な条件へ置き換えます。

• 長いPDFを月に何本読むか
• 画像を一日に何枚作るか
• チームで共有する必要があるか
• 入力データを学習へ利用されたくないか
• 請求書払いや管理者機能が必要か

最安プランを決めるのではなく、必要な作業を満たす最小のプランを探します。使わない機能が多いほど、金額だけの比較は役に立ちません。

比較表の元になる確認シートを作る

公開用の表をいきなり作らず、まず確認用のシートを作ります。次の形なら、後から料金が変わっても更新しやすくなります。

不明な欄は、AIに推測させず「公式ページで確認できず」と残します。問い合わせが必要な条件まで無理に埋めると、正確そうな誤情報になります。

AIには調査ではなく整形を任せる

公式ページから集めた確認シートができたら、AIへ渡します。依頼するのは、文章の要約、列の並び替え、読みやすい注記の作成です。

以下は公式料金ページを確認して作った記録です。
この記録に書かれた情報だけを使い、比較表へ整えてください。
・数字やプラン名を補完しない
・月払いと年払い換算を同じものとして扱わない
・不明な項目は「要確認」とする
・各行に確認日を残す
・条件が違う場合は注記を書く

AIが作った表は、元のシートと一行ずつ照合します。整形中に列がずれたり、空欄がもっともらしい文章で補われたりすることがあるためです。

総額で見ると差が変わる

月額だけでなく、実際に支払う期間の総額も計算します。

たとえば月払いを六か月使う場合と、年払いを途中でやめる場合では、月額表示が安い方が必ずしも得とは限りません。最低契約期間、途中解約、返金条件も確認します。

チーム向けプランでは「一人当たりの料金」だけでなく、最低人数を掛けた請求額を表示します。一人で使う読者に、五人分の最低契約が必要なプランを最安として勧めないためです。

おすすめを書くなら、条件と理由を添える

比較表のあとに「おすすめ」を書く場合は、誰に向くのかを限定します。

• 文章の下書きだけに使う人
• 画像生成も毎日使う人
• 顧客データを扱う小規模事業者
• 複数人で管理したいチーム

Googleは比較やレビューについて、判断理由や一次的な証拠を示し、用途に適する理由を説明するよう案内しています。「総合的におすすめ」だけで終わらせず、条件を書きます。

アフィリエイトリンクを含む場合は、広告であることが読者に分かるよう表示します。報酬の有無と評価基準を混ぜないことも重要です。

公開前と公開後のチェック

• すべて公式ページを開いて確認した
• 確認日、通貨、税、請求周期を記録した
• 年払いの月額換算を明記した
• 無料プランと無料体験を分けた
• 最低人数と利用上限を確認した
• 不明な条件をAIに推測させていない
• 広告・アフィリエイト表示を確認した

公開後は、料金ページのURLと最終確認日を使って定期的に見直します。更新できない比較表なら、「いつの情報か」を目立つ場所へ残します。

料金比較表でよくある質問

為替レートはどう扱えばよいですか

外貨建ての価格を円へ換算する場合は、使用した為替レートと換算日を明記します。カード会社の手数料や税によって実際の請求額が変わるため、「参考額」として示し、確定額のように書かないようにします。

公式サイトに税の記載がない場合はどうしますか

推測で税込・税別を決めず、「税の扱いは購入画面で要確認」と記載します。読者の所在地や事業者区分で変わる可能性もあるため、購入直前の表示を確認してもらいます。

比較表はどのくらいの頻度で更新しますか

料金変更の多い分野では月一回など、運営できる頻度を決めます。すべてを更新できない場合は、確認日を明記し、重要な価格変更を見つけたときに優先して直します。自動確認を使っても、公開前は公式ページを人が確認します。

AIは、集めた情報を読みやすく並べる作業には向いています。価格の正しさを保証する役ではありません。比較の根拠は公式ページに置き、AIは整形役として使うのが現実的です。

原因は、難しい言葉ではありません。主語が抜けている、抽象的な表現が続く、普段は組み合わせない言葉が並ぶ。小さな違和感が積み重なり、「日本語としては読めるけれど、人が書いた文章には見えない」状態になります。

AIやまらぼでも、「音声AIがこちらの話を待ち、途中の言い直しにも自然についてくる」という文章を直しました。「話を待つ」「言い直しについてくる」という言い方は、意味を想像できても自然ではありません。

この記事では、AI文章を語尾だけ整えるのではなく、意味を変えずに読みやすくする順番を紹介します。

最初に「誰が何をするか」を書き出す

読みにくい文は、主語と動詞の関係が曖昧になっています。まず一文ごとに「誰が」「何をする」を確認します。

修正後は、主語、確認する対象、読者の行動が分かります。分からない部分を格好のよい言い換えで隠さず、必要な情報を補うことが大切です。

「これ」「最初」「入口」を具体的な言葉へ戻す

AIは前の会話を知っているため、「これ」「その設定」「最初に」「入口と出口」といった表現だけでも文章を続けられます。しかし、読者は検索結果から途中の見出しへ来ることがあります。

「AIやまらぼなら、入口と出口を小さくする」という文では、入口と出口が何を指すのか分かりません。

これを「公開済みの短い記事を入力し、出力は要点三つに限定する」と書けば、実際に何をすればよいかが伝わります。比喩を使うなら、その直後に具体的な作業を置きます。

名詞を重ねず、動詞で書く

AI文章には「品質向上のための確認実施」「運用効率化の実現」のように、名詞が連続する表現がよく出ます。意味は通りますが、報告書のように硬くなります。

• 確認の実施を行う → 確認する
• 品質の向上を実現する → 品質を上げる
• 利用の検討を進める → 使うか検討する
• 設定の変更が可能です → 設定を変更できます

「〜を行う」「〜が可能です」を見つけたら、前の名詞を動詞にできないか考えます。文章が短くなり、誰の行動かも分かりやすくなります。

抽象的な評価には、具体例を一つ付ける

「便利です」「効率的です」「柔軟に対応できます」だけでは、読者は自分の仕事に使えるか判断できません。

たとえば「問い合わせ返信を効率化できます」ではなく、「問い合わせ文から個人情報を外し、回答に必要な事実だけを渡せば、返信のたたき台を数分で作れます」と書きます。便利さの中身が見えるからです。

ただし、実際に計測していない時間や効果を作ってはいけません。具体例を足すことと、未確認の成果を言い切ることは別です。

一文へ説明を詰め込みすぎない

AIは条件を漏らさず書こうとして、一文を長くすることがあります。読点が三つ以上続いたら、文を分けられないか確認します。

AIを活用することで、作業時間を短縮しながら、品質を維持し、担当者の負担を減らすことが可能になります。

この文には、時間、品質、負担という三つの主張があります。根拠も異なるため、一つずつ分けるべきです。根拠がなければ削ります。

AIに下書きを作らせると、最初の文章を考える時間を減らせます。ただし、内容の確認と修正は人が行います。

二文にすると、できることと注意点が分かれます。

同じ語尾と段落の長さを崩す

すべての文が「〜できます」「〜が重要です」「〜しましょう」で終わると、正しい内容でも機械的に見えます。

事実は言い切る。手順は「〜します」で揃える。注意点は短い一文で止める。役割に合わせて語尾を変えると、無理に飾らなくてもリズムが生まれます。

段落も一文ずつに切りすぎないようにします。結論、理由、具体例を一つのまとまりにすると、読者が話の流れを追いやすくなります。

文章の自然さと事実確認を分ける

読みやすく直している途中で、AIが新しい事実や数字を足すことがあります。文章が自然になっても、内容が変われば別の問題です。

NISTは、生成AIが誤った内容を自信を持って出力するリスクを整理しています。固有名詞、料金、日付、保存期間、規約は、文章の修正とは別に公式情報へ戻って確認します。

「自然な文章にして」と頼む場合も、「事実、数字、固有名詞は変更しない」「情報を追加しない」と条件を付けます。

AIへリライトを頼むときの指示例

次の文章を、個人事業主が一度で理解できる自然な日本語へ直してください。
・事実、数字、固有名詞は変更しない
・書かれていない情報を追加しない
・「これ」「それ」などの指示語は具体的な名詞へ変える
・名詞が続く表現は、できるだけ動詞で書く
・修正後の文章と、直した理由を分けて示す

一度に全文を渡すより、導入や見出し単位で直した方が、意味の変化に気づきやすくなります。

公開前のリライトチェック

• 誰が何をする文か分かる
• 指示語や比喩だけで説明を終えていない
• 名詞を三つ以上続けていない
• 「便利」「効率的」の中身を具体的に書いている
• 一文に複数の主張を詰め込んでいない
• 同じ語尾が三回以上続いていない
• 数字と固有名詞を公式情報で確認した

最後は画面を見ずに音読します。口が止まる場所は、読者も止まりやすい場所です。

AI文章のリライトでよくある質問

全文を一度に直してもらってもよいですか

短い文章なら問題ありません。長い記事は、導入、見出しごとの本文、まとめに分ける方が確認しやすくなります。一度に全文を直すと、前半と後半で用語が変わったり、削ってはいけない条件が落ちたりすることがあります。

AIらしい文章を判定する方法はありますか

特定の言葉だけで機械的に判定するのは困難です。「重要です」「可能です」があるだけで悪い文章とは限りません。誰に向けた文か、具体例があるか、事実を確認できるかを人が読んで判断します。

修正前の文章は残すべきですか

重要な記事では残すことを勧めます。WordPressのリビジョンや別の原稿ファイルがあれば、意味や数字が変わったときに比較できます。よい修正例は、次回の指示文や編集ルールにも使えます。

AI文章を人間らしく飾る必要はありません。主語を戻し、曖昧な言葉を具体的にし、根拠のない表現を外す。それだけで、文章はかなり読みやすくなります。

「それらしいけれど、何の記事か分からない」「文法は間違っていないのに、日本語として言わない」「本文より大げさになっている」。AIやまらぼでも、こうしたタイトルを何度も直してきました。

タイトル選びで大切なのは、いちばん目立つ案を探すことではありません。読者が一度で意味を理解でき、本文を読んだ後に期待外れにならない案を残すことです。

この記事では、AIが作った候補を公開できるタイトルへ整える手順を、実際の修正例と一緒に紹介します。

まず「日本語として言うか」を確かめる

以前、AIから「本番へ入れず、何を試す？」という案が出ました。言いたいことは想像できますが、普段の日本語では「WordPressの新しいバージョンを本番へ入れる」とはあまり言いません。

そこで、「本番環境に入れる前に何を試すべき？」へ変更しました。何をする前なのかが明確になり、記事の内容も想像しやすくなります。

候補を選ぶ前に、一つずつ声に出してみてください。途中で助詞を変えたくなったり、「これは何を指しているのか」と考えたりするなら、まだタイトルだけで意味が伝わっていません。

読者が検索する言葉を前半へ置く

タイトルの前半には、記事の中心となる言葉を置きます。この記事なら「AI」「記事タイトル」です。「公開前」「チェックポイント」は、その後に続けても意味が通ります。

反対に、「これだけは知っておきたい」「失敗しないための」のような言葉から始めると、検索結果で肝心のテーマが後ろへ隠れます。まず対象を伝え、そのあとに読む理由を添える方が親切です。

Google Search Centralも、ページタイトルは内容を説明する簡潔な文言にし、曖昧な表現やキーワードの詰め込みを避けるよう案内しています。文字数だけを合わせるより、前半を読んだ時点で内容が分かるかを優先します。

タイトルと本文の約束を一致させる

AIは「完全版」「最短」「絶対に失敗しない」「たった三分で」といった強い言葉を足すことがあります。目を引く一方、本文で証明できなければ読者との約束を破ることになります。

タイトルに入っている名詞、数字、動詞へ線を引き、本文のどこで答えているかを確認します。

• 「五つの方法」と書いたなら、方法が五つに整理されているか
• 「比較」と書いたなら、同じ条件で二つ以上を比べているか
• 「初心者向け」と書いたなら、専門用語を説明しているか
• 「最新」と書いたなら、確認日と更新方法があるか

答えが本文にない言葉は、タイトルから外すか、本文を補います。タイトルだけを強くしても、記事そのものは良くなりません。

一つの記事に一つの行動を残す

「知る・比べる・選ぶ・設定する・稼ぐ」を一つのタイトルへ詰め込むと、誰のどの悩みに答える記事なのか分からなくなります。

この記事で読者がすることは「AIが作ったタイトルを選ぶ」です。SEOの歴史や記事本文の書き方まで背負わせません。読了後にできるようになってほしい行動を一つ決め、その動詞をタイトルに残します。

迷ったときは、次の文を完成させます。

この記事は、［誰が］［何をするとき］［何ができるようになる］ための記事。

たとえば「ブログ運営者が、AIのタイトル案を選ぶとき、公開前の確認項目が分かるための記事」です。ここに含まれない要素は、タイトルへ無理に入れなくて構いません。

似た候補は三案まで減らす

二十案を細かく採点するより、切り口の違う三案へ減らした方が選びやすくなります。

1. 作業をそのまま示す案：AIが作った記事タイトルを選ぶ方法
2. 困りごとから始める案：AIのタイトルが不自然なときに見直すポイント
3. 具体的な内容を示す案：AIの記事タイトルを公開前に確認する七項目

三案を残したら、導入文とまとめだけを読み直します。記事の入口と出口に合う案が、もっとも内容を正しく表しています。

AIへ作り直してもらうときの指示

「もっと魅力的にして」だけでは、強い言葉が増えることがあります。必要な条件と禁止事項を一緒に伝えます。

この記事の読者：個人でブログを運営している人
記事を読んだ後にできること：AIが作ったタイトル案を公開前に確認できる
必ず入れる言葉：AI、記事タイトル
使わない言葉：完全、絶対、最短、知らないと損
本文にない数字や効果を足さない
自然な日本語で、切り口の違う案を3本だけ出す

候補を増やすより、条件を明確にする方が修正回数を減らせます。

公開前に確認する七項目

• タイトルだけで、何の記事か分かる
• 声に出しても、助詞や語順を直したくならない
• 大切な言葉が前半にある
• 本文にない数字や効果を約束していない
• 読者にしてほしい行動が一つに絞られている
• 似た言葉やキーワードを繰り返していない
• 同じサイトの別記事と見分けられる

最後に、記事を知らない人へタイトルだけを見せ、「何について書かれた記事だと思う？」と聞ければ理想です。想定と違う答えが返ってきたら、目立つ言葉を足すのではなく、対象と行動を具体的にします。

タイトル選びでよくある質問

文字数は何文字にすればよいですか

一律の正解はありません。検索結果では端末に合わせて途中で省略されるため、大事な内容を前半へ置き、長い修飾語を減らします。文字数を合わせるために意味を削るより、タイトルだけで内容が伝わることを優先してください。

疑問形のタイトルは避けた方がよいですか

読者が実際に抱く疑問と一致し、本文で答えているなら使えます。ただし「本当に大丈夫？」「知らないと損？」のように対象が曖昧な疑問形は避けます。何についての疑問なのかをタイトル内に書きます。

公開後にタイトルを変えてもよいですか

内容に合わない、検索結果で意味が切れる、同じサイトの記事と区別しにくい場合は見直せます。変更後は本文の見出し、SNSの表示、内部リンクの文言も確認します。URLまで変える場合は、リダイレクトなど別の対応が必要です。

AIは候補を増やすのが得意です。最後の一本を選ぶときは、派手さよりも「読者が迷わないか」を基準にしてください。

OpenAIは2026年7月8日、ChatGPT Voice向けの新しい音声モデル「GPT-Live」を発表しました。会話の間や言い直し、こちらからの割り込みに対応しながら、自然なテンポでやり取りを続けることを目指したモデルです。

声で相談できるなら、考えの整理や文章の見直しにも役立ちそうです。ただし、会話が自然であることと、内容が常に正確であることは別です。仕事で使うなら、実際の業務や顧客との会話に持ち込む前に、自分の環境で一度試しておく必要があります。

この記事では、GPT-Liveを仕事で使う前に確認したいことを、実際に試せる順番で整理します。

まず、どこで使える機能なのかを確認する

現在試せるGPT-Liveは、ChatGPTの音声会話で使われるモデルです。自社サイトや電話システムへ直接組み込むためのAPIは、発表時点ではまだ提供されていません。

つまり、今できるのはChatGPTを開き、VoiceでAIと会話することです。「ChatGPTで自然に話せたから、同じ仕組みをすぐ問い合わせ電話へ導入できる」という段階ではありません。

GPT-Live-1は個人向けの有料プラン、軽量版のGPT-Live-1 miniはFreeプランへ段階的に提供されています。地域やアプリのバージョンによっては、まだ表示されない場合があります。また、発表時点ではBusiness、Enterprise、Eduのワークスペースでは利用できません。

動画や画面共有にも未対応です。画面を見せながらWordPressの操作を相談するような使い方は、GPT-Liveだけでは完結しません。

最初は、機密情報を含まない短い会話で試す

最初から仕事の打ち合わせに使うのではなく、公開しても問題のない内容で10分から30分ほど試すのがおすすめです。

たとえば、次の三つなら準備に時間がかかりません。

• 公開済みの記事を一段落だけ読み上げ、要点を三つにまとめてもらう
• 読者から聞かれそうな質問を投げかけ、回答を一緒に整理する
• 製品名、日付、数字を含む短い文章を話し、会話後の文字起こしを確認する

途中で「今の条件は取り消して」「二つ目だけ言い直す」と伝え、修正に対応できるかも見ておきます。GPT-Liveの特徴である、割り込みや言い直しを含む会話が、自分の話し方でも使いやすいかを確かめるためです。

静かな部屋で問題がなければ、キーボードやエアコンの音がする普段の作業場所でも試します。音声の聞き取りは、背景音、通信状態、マイクの設定によって変わります。

会話後の文字起こしは、元の内容と見比べる

Voiceでの会話が終わると、チャット履歴に文字起こしが残ります。しかし、これは録音内容を一語ずつ正確に書き起こしたものではありません。OpenAIも、実際に話した内容と文字起こしが一致しない場合があると案内しています。

試した後は、特に次の部分を元のメモと見比べます。

• 人名や製品名などの固有名詞
• 日付、金額、数量
• 「する」と「しない」のように、意味が反対になる表現
• 途中で言い直した内容

考えを整理するための会話なら、多少の誤りは後から直せます。一方、契約条件や納期を含む打ち合わせでは、一語の違いが大きな問題になります。文字起こしをそのまま議事録として送らず、元のメモや参加者の確認を通す必要があります。

なお、GPT-Liveは会議を録音して要約するChatGPT Recordとは別の機能です。GPT-LiveはAIとの会話、Recordは会議や音声メモの記録が中心です。似た画面に見えても、目的は分けて考えます。

音声と文字起こしがどう保存されるか確認する

仕事で使う前に、ChatGPTの「データコントロール」を確認しておきます。

GPT-Liveの音声クリップは、文字起こしとともにチャット履歴へ保存され、30日間保持されます。チャットを削除すると、関連する音声クリップも原則として30日以内に削除されます。チャットをアーカイブしただけでは削除されません。

音声クリップそのものは、利用者が共有を選ばない限りモデルの学習には使われません。ただし、文字起こしや添付ファイルの扱いは、利用中のプランとデータ設定によって変わる場合があります。

そのため、試す前に「モデルの改善への利用」「音声の共有」「チャット履歴」の設定を確認します。顧客名、未公開の商品情報、パスワード、契約書の内容は、動作確認のための会話には使わない方が安全です。

自分以外の人の声が入る場合は、録音や外部サービスへの送信について、事前に説明と同意が必要かどうかも確認します。

向いている使い方と、まだ任せない使い方を分ける

現時点のGPT-Liveは、間違いがあっても後から確認して直せる作業に向いています。

• 頭の中にある考えを声に出して整理する
• 記事や説明文を読み上げ、不自然な部分を探す
• 読者からの質問を想定し、回答の練習をする
• 次に調べることや、文章の見出し候補を洗い出す

AIやまらぼで使うなら、公開済み記事の音読チェックや、FAQの想定問答から始める予定です。会話で出た内容はそのまま記事へ貼らず、いったん短いメモにして、出典、日付、固有名詞を確認してから原稿へ反映します。

一方、正式な議事録の作成、契約内容の確定、金額や納期の決定、顧客への自動応答は、会話が自然だったという理由だけで任せるべきではありません。APIが公開された後に外部サービスへ組み込む場合も、料金、保存期間、認証、停止方法を改めて確認する必要があります。

便利さより先に、間違えたときの直し方を決める

GPT-Liveを試すときは、「うまく会話できたか」だけでなく、聞き直しが何回あったか、固有名詞や数字を正しく文字にできたか、会話後の修正に何分かかったかも見ておきます。

声で考えを整理できるのは便利です。ただし、仕事で安心して使えるかどうかは、会話の自然さだけでは決まりません。

まずは機密情報を含まない短い会話で試し、文字起こしと保存設定を確認する。そのうえで、間違いがあっても人が確認できる作業から少しずつ使う。これが、GPT-Liveを仕事へ取り入れる現実的な始め方です。

一方で、公開中のサイトへ入れて表示が崩れたら困る。問い合わせや商品リンクが止まれば、新機能を早く触れたことより損失の方が大きくなります。

WordPress 7.1 Beta 1は、2026年7月15日に公開されました。最終版の予定日は8月19日です。

公式案内が最初に強調しているのは、新機能の便利さではありません。この版はテストと開発専用であり、本番サイトや重要なサイトへ入れないことです。

だから、今やるのは本番の更新ではありません。自分のサイトで影響が出そうな場所を先に選び、安全な場所で試す準備です。

AIやまらぼも、本番は現在のWordPress 7.0.2で維持します。7.1 Beta 1を本番へ入れた、あるいは動作確認が済んだとは扱いません。

今回見るのは、ベータ版の機能一覧ではなく、ひとりでWordPressを運営する人が8月の正式版までに何を確かめておくかです。

更新ボタンより先に、ベータ版という札を見る

ベータ版は、正式版を少し早く配ったものではありません。

開発途中の機能を実際の環境で試し、不具合や使いにくさを見つけるための版です。予定されている機能が変わることもあれば、テーマやプラグインとの組み合わせで問題が出ることもあります。

公開サイトで試すと、問題を見つける作業と、読者がいつも通り使える状態へ戻す作業が同時に発生します。原因がWordPress本体なのか、テーマなのか、プラグインなのかも切り分けにくくなります。

今回の公式案内には、WordPress Beta Tester、ZIPの直接ダウンロード、WP-CLI、WordPress Playgroundという四つの試し方が掲載されています。選択肢が複数あるのは、本番へ直接入れる必要がないということでもあります。

運営中のサイトで更新通知を見ても、7.1 Beta 1を入れる理由にはしません。まず、どの試験場を使うかを決めます。

最初の試験場は、捨てて戻せる場所

新機能を見るだけなら、WordPress Playgroundから始めるのが軽い方法です。

ブラウザー上の分離環境なので、公開サイトのデータベースやファイルを変更せずに7.1 Beta 1を開けます。画面を触り、管理画面の移動やエディターの変化を見る最初の確認には向いています。

ただし、まっさらなWordPressで動いたことと、自分のサイトで動くことは別です。

次の段階では、現在のテーマと必要なプラグインだけを入れた分離環境を用意します。記事、画像、メニュー、検索、404、問い合わせなど、普段の運営で止まると困る部分を少数の代表データで確認します。

本番の複製を使う場合も、ログイン制限とnoindexを確認し、メール、Cron、外部HTTP送信を止めます。テスト記事が配信されたり、問い合わせの試験メールが読者へ届いたりしないようにするためです。

試験環境は保存することより、問題が出たら作り直せることを優先します。戻し方を考えなくてよい場所ほど、ベータ版を落ち着いて試せます。

AIやまらぼで先に見る五つの入口

AIやまらぼで確認するなら、トップページだけを開いて終わりにはしません。

一つ目はテーマです。ヘッダー、記事一覧、記事本文、検索、404をPCと390px幅で開き、横にはみ出さないか、メニューや画像が消えていないかを見ます。

二つ目は記事編集です。既存記事を直接書き換えず、新しい下書きを作り、見出し、段落、箇条書き、HTML、画像を保存します。保存後にもう一度開き、意図しない変換がないかを確かめます。

三つ目は画像です。アイキャッチと本文画像をアップロードし、WebP、代替テキスト、添付タイトル、トリミング後の寸法を確認します。

四つ目は問い合わせです。フォームの表示、入力、送信結果、メール受信は別々に見ます。画面上で成功していても、メールが届くとは限りません。

五つ目は運用プラグインです。バックアップ、キャッシュ、AI下書きガード、旧URLの410、商品リンクを代表URLで確認します。

全部の旧記事を読み直す必要はありません。収益や問い合わせ、公開作業につながる入口から選ぶと、短い時間でも判断材料を残せます。

画像まわりの変更は、記事制作の手間に直結する

WordPress 7.1 Beta 1では、メディア処理の変更が大きく案内されています。

クライアント側の処理でHEIC、UltraHDR、AVIF、WebPなどの対応を広げ、通信が切れた場合の自動再試行や進捗表示を加える予定です。メディア編集をまとめる新しい画面、投稿へ添付した画像を見つけやすくする表示も含まれます。

これは、画像を多く使うAIやまらぼに関係します。ただし、対応形式が増えたからといって、公開用画像のルールをすぐ変える必要はありません。

現在は1200×800pxのWebP、内容を説明するファイル名、具体的な代替テキストという形で揃えています。新しいアップロード処理を試す場合も、この公開結果が崩れないかを見ます。

iPhoneのHEIC画像が入るかだけでなく、変換後の容量、縦横、色、メタデータ、サムネイルを確認します。新しい編集画面で切り抜いた後、元画像へ戻せるかも試験項目です。

便利な機能を探すより、いまの画像制作工程が短くなるか、確認作業が増えるかを測ります。

AI下書きは、HTML機能より公開権限を見る

公式発表では、HTMLブロックが編集可能な入れ子ブロックを扱う変更に触れ、AI生成コンテンツとの関係も説明しています。

AIが作ったHTMLをWordPress上で編集しやすくなるなら、下書き作業には役立つ可能性があります。

ただし、AI記事の安全性を決めるのは、HTMLブロックの便利さではありません。

AIやまらぼでは、自動投稿ユーザーに公開権限を与えず、APIから受け取った記事を必ず下書きへ固定します。出典、AIが担当した範囲、人間確認の状態が揃わなければ公開へ進めません。

7.1 Beta 1を試すときも、この境界が残るかを見ます。下書き保存、再編集、危険なHTMLの除去、重複投稿の拒否、緊急停止中の拒否が確認対象です。

新しいエディターで文章を直しやすくなっても、公開できる人まで増やしません。編集の便利さと公開権限は別の設定として扱います。

8月19日までに残すのは、更新予定ではなく確認表

WordPress 7.1の最終版は、2026年8月19日に予定されています。

予定日は変更される可能性がありますし、ベータ版の機能が同じ形で最終版へ入るとも限りません。公開直前には、公式発表と実際のリリース内容をもう一度確認します。

今から本番更新の日を決める必要はありません。先に、試験環境、代表ページ、必要プラグイン、画像、問い合わせ、戻し方を一枚へまとめます。

AIやまらぼでは、正式版が出た後もすぐ本番へ入れず、分離環境で現在のテーマと8プラグインを確認します。問題がなければ新しい完全バックアップを取り、一度に複数の大きな変更を重ねずに本番へ反映します。

• Beta 1は本番へ入れず、最初はPlaygroundまたは作り直せる環境で見る
• テーマ、記事編集、画像、問い合わせ、運用プラグインの代表動作を確認する
• 正式版公開時に公式情報を再確認し、バックアップ後に一つずつ変更する

ベータ版を早く入れることが準備ではありません。正式版が来たとき、何を見れば公開サイトを止めずに判断できるか。その確認表を先に作ることが、今できる準備です。

それなら、8月に入ってから移行しても間に合いそうに見えます。

けれど、OpenAIが案内している終了日は2026年8月26日です。その日に動かなくなる可能性があるのはAPIだけではありません。WordPressの下書きが作られない。問い合わせへの返事が返らない。止まった処理を、人が手作業で補うことになります。

今回の移行は、接続先のURLをResponses APIへ変えるだけでは終わりません。指示文、会話履歴、ツールの実行、古いThreadの保存先を順番に分け直す必要があります。

いきなりコードを書き換える前に、どこでAssistants APIが使われていて、止まると何が困るのかを確認します。

移行以外の対応も重なっているなら、今週の作業を4つに絞った記事で優先順位を決めてから戻ってくると、API調査に使える時間を確保しやすくなります。

最初に、どこでAssistants APIを使っているか探す

最初に検索するのは、assistants、threads、runsといったAPI名です。

ただ、ソースコードの一行を見つけただけでは足りません。

Assistant IDを環境変数に入れているかもしれません。Thread IDをデータベースへ保存していることもあります。管理画面の設定、定期実行するCron、外部サービスのWebhookにも古いIDやURLが残ります。

見つけた場所ごとに、その処理が何をしているかを一行で書きます。

記事の構成を作る。問い合わせ文を分類する。社内資料を検索する。WordPressへ下書きを保存する。同じAssistants APIでも、止まったときの影響は違います。

次に、Assistantへ何を持たせているかを確認します。モデル、指示文、ツール定義、出力形式。Threadには、メッセージだけでなく、ファイルや独自のIDを紐づけている場合があります。

Runを開始したあと、完了するまでどこで待っているかも見ます。ツールを呼ぶとき、実際の処理を動かしているのはどの関数か。失敗したときに何回やり直すのか。同じ処理を二重に実行しない仕組みがあるか。

ブログの自動投稿なら、二重実行で同じ下書きが二本できます。メールや注文を扱う処理では、同じ通知が二度送られるかもしれません。APIの置き換えより先に、この流れを一枚へまとめます。

Assistant・Thread・Runは、何に置き換わる？

公式の移行ガイドでは、Assistant、Thread、Run、Run stepの役割が、それぞれPrompt、Conversation、Response、Itemへ移ると説明されています。

これは、単語を一対一で置換するための表ではありません。

Assistantは、モデル、指示、ツールを一つのAPIオブジェクトとして持っていました。公式ガイド上のPromptは、AIにどう振る舞わせるかという設定を持ちます。

Threadはメッセージを保存していました。Conversationは、メッセージだけでなく、ツール呼び出しやツールの結果もItemとしてまとめて扱います。

Runは、Threadに対してAIを動かす処理でした。Responses APIでは、入力を送り、Responseとして出力Itemを受け取ります。途中でツールが必要になれば、アプリ側がツールを実行し、その結果を次の入力へ返します。

自動投稿の仕組みに当てはめると、記事の書き方は指示文、過去のやり取りはConversation、一回の下書き生成はResponse、検索結果やWordPressへの保存結果はItemとして考えられます。

この分け方を先に決めると、文章のルールを直す作業と、WordPressへ保存する処理を分けられます。移行後に記事の見出しだけ変えたいとき、投稿処理まで触らずに済みます。

再利用可能なPromptは11月30日に終了。指示文はアプリ側へ移す

Assistants APIの移行ガイドには、既存のAssistantからPromptを作る経路があります。

ただし、再利用可能なPromptも2026年11月30日に終了する予定です。

Assistant IDをPrompt IDへ置き換えるだけでは、数か月後にもう一度同じ問題を抱えます。OpenAIの廃止予定ページは、再利用可能なPromptの内容をアプリケーションコードへ移すよう案内しています。

指示文をコードへ直書きするという意味ではありません。専用の設定ファイルや管理画面でバージョンを管理し、変更履歴を残せる形にします。

たとえば記事生成なら、文体、見出し数、出典の出し方、禁止事項を一つの設定として保存します。どの版を、いつ、どの記事に使ったかも残します。

指示文を変えると、文章の雰囲気だけでなく、記事の長さや引用方法まで変わります。検索から読まれ、問い合わせや収益につながる記事なら、単なる技術設定ではなく編集ルールの変更です。

Promptを一時的な移行先として使う場合も、11月30日より前に外せる予定を作ります。今回の移行先が、次の廃止予定へそのまま依存しない形にします。

古いThreadは、必要なものからConversationへ移す

既存のThreadをConversationへ一括で移す自動ツールは提供されません。

公式ガイドは、新しい会話を先にConversationとResponses APIへ移し、古いThreadは必要に応じてあとから移す方法を案内しています。

すべてのThreadを同じ日に移す必要はありません。

いま対応中の顧客、進行中の案件、業務上保存が必要な履歴から始めます。何年も開かれていない会話まで先に移すと、確認作業だけが増えます。

古いThreadを移す場合は、メッセージの本文だけで判断しません。画像、ファイル、ツールの入出力、アプリ側で付けた顧客IDが欠けていないかを確認します。

移さないThreadをいつまで保存するかも決めます。Assistants APIの終了後も同じ方法で読めるとは考えず、必要なデータは自分の保存方針に合わせて退避します。

個人情報や顧客の資料を含む場合は、Conversationへ移してよいデータかも確認します。移行を理由に、必要のない履歴まで新しい保存先へ複製しないようにします。

新規の会話から切り替えると、旧処理との比較もしやすくなります。同じ種類の入力を両方へ流し、出力、ツールの実行回数、処理時間、費用を比べます。

移行テストでは、二重投稿と再試行を確認する

一度成功しただけでは、本番へ切り替えられません。

外部APIが遅い。WordPressが500エラーを返す。ツールの結果を返す前に処理が落ちる。同じResponseをもう一度送ってしまう。実際の運用では、こうした失敗が起こります。

タイムアウトするまでの時間と、再試行する回数を決めます。途中で止まった場合は、どこから再開するのかも記録します。

WordPressへ投稿する処理には、同じautomation IDの下書きがないかをサーバー側で確認する仕組みを残します。クライアントからstatus: draftを送るだけでなく、自動投稿用ユーザーから公開権限を外しておきます。

テストでは、意図的に一回失敗させます。WordPressの保存処理を止める、ツールからエラーを返す、同じリクエストを二度送る。下書きが重複せず、途中の状態をログから追えるかを確認します。

費用も比較します。会話履歴の渡し方やツールの回数が変われば、入力トークンと実行回数も変わります。モデルの単価だけでなく、人が確認できる下書き一件を作るまでの合計を見ます。

記事制作では、生成が速いことより、出典が残ること、下書きとして保存されること、同じ記事が重複しないことを先に確認します。読者の目に触れる前の安全装置を、移行で外さないためです。

本番の切り替えは8月26日より前に済ませる

8月26日は、本番へ切り替える日ではありません。

Assistants APIが終了する日です。

不具合が見つかったときに旧処理へ戻せるよう、本番切り替えは前倒しします。

最初は開発環境やステージングで動かします。次に新しい会話の一部だけをResponses APIへ流し、文章、ツール結果、費用、保存、ログを比べます。

問題がなければ、新しい処理へ送る会話の割合を増やします。旧処理へ戻すスイッチは、移行後もしばらく残します。

切り替え後には、Assistant ID、古いエンドポイント、Threadを読む処理が、コード、環境変数、Cronに残っていないかをもう一度検索します。使わなくなった認証情報は、復旧に不要なことを確認してから無効にします。

読者にとっては、Assistants APIがResponses APIへ変わったことより、記事が予定どおり公開され、問い合わせへの返事が届くことの方が大切です。

移行の目的は、新しいAPIを使った実績を作ることではありません。いま動いている仕事を止めず、次の変更にも対応しやすい形へ組み直すことです。