AIのエラーと対処

The 'gpt-6.1-sol' model is not supported when using Codex with a ChatGPT account.

起きたこと

2026年10月3日、コマンド版のCodex（Codex CLI）に任せていた画像作りが、サーバーに断られて止まりました。400は「リクエストの中身がおかしい」という番号です。

原因

設定ファイル ~/.codex/config.toml の model の行が変わっていました。入れたときは gpt-6-astra で、止まったあとに見ると gpt-6.1-sol です。CLIはデスクトップ版と同じファイルを読むので、デスクトップ版が書き換えたと見ています。契約のプランの問題ではありませんでした。

直し方

1. 実行のたびに codex exec -m gpt-5.6-luna のようにモデルを名指しする（その1回だけ設定を上書きする指定）
2. 設定ファイルは触らない。手順書や台本に、最初から -m を書いておく
3. モデル名は時期で変わるので、大きな仕事の前に「OKとだけ返して」と頼み、通るか確かめる

分かっていないことなぜこのモデルがCLIだと非対応になるのかは、つかめていません。

起きたこと

2026年9月26日、版 26.924.1866.0 に自動更新されてから、起動のたびに丸で止まるようになりました。再起動も入れ直しも、アプリのリセットも効きませんでした。

原因

根っこは分かっていません。同じ症状が GitHub の openai/codex に Issue #48333 として報告されていて、効いた手もそこに書かれていたものと同じでした。

直し方

1. 丸が出たまま、タスクマネージャーで codex.exe ... app-server と出ているものだけを終了する
2. アプリ本体は閉じない。数秒でチャットの画面に進む
3. 毎回起きるので、12秒たっても丸なら自動で止める見張り役のスクリプトを置いた（10月だけで17回動いた）

ChatGPT failed to start.
プロセスにパッケージ ID がありません。

起きたこと

2026年9月26日、Codex アプリの丸止まりを調べる途中で、GPU（画面を描く部品）を使わない起動を試しました。起動用のスクリプトで exe（プログラムの本体のファイル）を直接起動すると、小さな窓にこのエラーだけが出ました。押せるボタンは Quit だけです。ChatGPT は、スタートメニューでの Codex アプリの名前です。

原因

Codex アプリは、Store からパッケージという包みの形で入っています。包みには、1つに見分けるための ID が付いています。exe の置き場所を直接たたくと、Windows は Store アプリとしてではなく、ただのプログラムとして起動すると見ています。起動したプロセスに ID が付かず、アプリが自分で止まったという読みです。ここは推測で、開発元の説明は見つけていません。

直し方

1. exe を直接呼ばず、Store アプリの起動用の名前（AUMID）で起動する。Codex アプリは OpenAI.Codex_2p2nqsd0c76g0!App だった
2. 指定が要らないなら、explorer.exe に、shell:AppsFolder と AUMID をつないだ場所を開かせる。デスクトップのショートカットもこの形に付け替えた
3. --disable-gpu などの指定を付けたいときは、AUMID と一緒に渡す。渡し先は IApplicationActivationManager（Store アプリを起動する窓口）
4. AUMID は Get-StartApps で、アプリの名前と並べて出せる

分かっていないこと更新の前にも同じエラーが出たのかは、記録が無く分かりません。shell:AppsFolder の後ろに AUMID を付ける起動の仕方は、公式の文書では確かめていません。

Reading prompt from stdin...
No prompt provided via stdin.

起きたこと

2026年10月4日、部下役のAIに、Codex CLI（コマンド版のCodex）で記事のサムネイルを描き直してもらおうとしました。codex exec に -i（画像を渡す指定）で元の画像を付けると、1秒ほどで止まりました。指示文はコマンドの最後に書いてあったのに、指示文が無いと言われた形です。

原因

codex exec --help を開くと、-i は <FILE>... と、値を後ろにいくつも続けられる指定でした。画像の後ろに置いた指示文も、2つめの画像として受け取られたと見ています。指示文が無いので stdin（パイプなどで外から流し込まれる入力の入り口）から読みに行き、何も流れてこないまま止まったと考えています。

直し方

1. 指示文をパイプで渡し、最後に - を置く（echo "<指示>" | codex exec ... -i <画像> -）
2. 長い指示文はファイルに書いておき、cat prompt.txt | で流すか、最後の - と < prompt.txt で読ませる
3. 指示文を -i より前に置くか、-- で区切ってから書いても通る（11月10日に確かめた）

分かっていないこと2枚以上の画像を付ける書き方（-i の繰り返しやカンマ区切り）は、まだ試していません。

HTTP 429 Rate limit exceeded for model gemini-3.8-flash-tts (limit: 100 requests per day on Tier 1). Please retry in 22h45m11s

起きたこと

2026年9月26日、動画の声を台本158行ぶん作っている途中、81行目のあとで止まりました。429は「呼び出しの回数が上限を超えた」という番号です。

原因

上限は Tier 1 で1日100回でした。同じ日の朝にあった試し録りの19回と、本番の81回で、ちょうど100回です。上限はAPIキーごとではなく、Googleのプロジェクトごとにかかります。

直し方

1. できた音声はファイルに残るので、作り直さずに続きを翌日に回す（翌日に158行がそろった）
2. 文言が「per minute」なら待てば戻る。「per day」なら翌日に回す
3. 声を作る日は同じプロジェクトでテストしない。送る回数に90の天井を付ける

分かっていないこと1日の枠がいつ戻るのかは、決着していません。上限に当たったあとも3行は通っていて、枠がどう数えられているのかも分かっていません。

起きたこと

2026年10月、英会話ドラマの第1話で、日本語のナレーションが「1行ずつ」を「いちゆきずつ」と読みました。英語の「hand in」は「ハンロイン」でした。読んだのは Gemini TTS ではなく、Google Cloud の Chirp 3 HD の声です。

原因

ナレーションの文を、画面に出す漢字の文のまま声に渡していました。「1行」を「いちぎょう」と読むか「いちゆき」と読むかは、声の側が決めていたわけです。聞き取りの照合も英字の部分を比べる対象から外していたので、「ハンロイン」に印が付きませんでした。

直し方

1. 漢字・数字には {1行|いちぎょう}、英字には {hand in|ハンド イン} の形で読みを書き、声にはかなの文だけを渡す
2. ルビの外に漢字や数字が残っていたら、組み立てを止める
3. できた音声を聞き取りにかけ、台本の読みとの食い違いの印が0になってから出す

起きたこと

2026年8月19日、Claude Code の WebFetch（URLを開いて読む機能）に逐語で抜き出すよう頼みました。返ってきた引用に、原文に無い「全粒粉」という語が入っていました。

原因

WebFetchが返すのは原文ではなく、別のモデルがまとめた結果です。生のページはClaudeに届いていません。公式ドキュメントにも、そういう仕組みだと書かれていました。

直し方

1. 引用と数値は、URLを1本ずつブラウザで開くか、curlで生のまま取ってから使う
2. 引用したい文字列でページ内を検索し、一致するかを見る
3. 文字だけでなく、どこに書かれた誰の言葉か（帰属）も確かめる

分かっていないことなぜ「全粒粉」だったのかは分かりません。

起きたこと

2026年10月28日の点検で、Claudeの定期タスクが何本も止まっていたと分かりました。定期タスクは、決まった時刻にClaudeが自分で作業を始める機能です。毎朝の再生数の記録や、年に1回の統計データの更新が抜けていました。

原因

定期タスクには、Claudeが何をするときに人の確認を求めるかを決める、権限モードがあります。既定のモード（Manual）では、ファイルを書く・書き換えるときや、作業フォルダの外を読み書きするときに確認が出ます。無人で動いているので誰も答えず、その回は確認を待ったまま止まっていました。止まった回も、実行の一覧では succeeded（成功）か running（実行中）と出ていました。

直し方

1. その回の会話記録が道具の呼び出し（tool_use）で終わり、結果（tool_result）が無ければ、止まった回と見る
2. 抜けた分は手でやり直す（年に1回のデータは10月28日、毎朝の記録は11月2日に埋めた）
3. 読む場所も書く場所も作業フォルダの中で終わらせ、結果を信じる前に、できたはずのファイルがあるかを見る

分かっていないことモードを Auto にするか、書き込み先ごとに許可を足すかは、まだ決めていません。10月30日と31日に全部の定期タスクが動かなかった原因も、つかめていません。

SyntaxError: unterminated string literal (detected at line 42)

起きたこと

2026年11月10日、Claude Codeにこのサイトの生成スクリプトを直してもらっていたら、Pythonが止まりました。書いたはずの \n（改行を表す2文字の記号）が、ファイルの中では本物の改行に変わっていました。同じ止まり方は、9月4日と11月8日にも起きていました。

原因

直し用のPythonには、バックスラッシュと n の2文字を書き出すため、\\n と2本重ねて書いてありました。それが1本に減って届き、改行の1文字になっていました。Windowsで使っている Bash ツール（コマンドを動かす機能で、中身は Git Bash）に渡すと、2本が1本に減ります。引用符付きのヒアドキュメント <<'EOF' でも同じでした。ヒアドキュメントは、何行ものコードをコマンドへ直接書き込む書き方です。

直し方

1. 直し用のPythonはコマンドの中に書かず、Write（コマンドを通さずにファイルを書く機能）でファイルに保存してもらう
2. そのファイルを python fix.py のように実行する
3. 書き換えた側のファイルは、python -m py_compile 対象.py で構文を確かめてから動かす

分かっていないことGitHubの報告には、n本のバックスラッシュが、nを2で割って切り上げた本数で届くとあります。僕が確かめたのは、2本が1本になるところまでです。

"3" 個の引数を指定して "AppendAllText" を呼び出し中に例外が発生しました: "パス '…\繝・せ繧ｯ繝医ャ繝予菴懈･ｭ逕ｨ\run.log' の一部が見つかりませんでした。"

文字列に終端記号 " がありません。

起きたこと

2026年10月10日、部下役のAI（Claude Code）に書かせたPowerShellのスクリプトが、何も言わずに失敗していました。切り離して走らせていたので、エラーの表示も見当たりません。ログに書き足すはずの区切りの行が、いつまでも残りませんでした。

原因

部下役のAIは、.ps1をBashのヒアドキュメント（複数行をそのままファイルへ流し込む書き方）で作っていました。こうして作ったファイルは、BOMの付かないUTF-8になります。BOMは、中身がUTF-8だと読み手に知らせる、先頭の3バイトの印です。PowerShell 5.1は、BOMのない.ps1を、日本語版Windowsの古い文字コード（cp932）で読みます。中に書いた日本語のパスが化け、[IO.File]::AppendAllText が黙って失敗していました。

直し方

1. スクリプトの先頭に、BOMの3バイト EF BB BF を足す。PowerShellの中なら、New-Object Text.UTF8Encoding $true で書き直す
2. Get-Content -Encoding Byte -TotalCount 3 で先頭を見て、239 187 191 と出ればBOMが付いている
3. 部下役のAIの作業メモに、.ps1はBOM付きで保存する、という決まりを残す

分かっていないこと公式の説明でBOMなしでも正常に動くとされる新しい版（7など）では、試していません。

起きたこと

2026年8月17日、WordPressの記事に埋め込んでいる無料の診断ツールのデータを更新しました。変わるのは3行のはずが、公開中の本文と比べると、全69行が違うと出ました。どの行も、違うのは行の終わりの見えない1文字だけでした。

原因

公開中の本文に入っているJavaScriptは、改行コード（行の終わりを示す見えない文字）が、CRとLFの2文字を続けるCRLFでした。WindowsのPythonは、open(path) で読むと、CRLFをLFに置き換えます。読み直した手元はLFになっていたので、全行で行末のCRが1文字ずつ足りない形でした。

直し方

1. 読むときも書くときも、open() に newline="" を付けて、改行を変換させない
2. ブラウザで行を差し替えるときは、元の行が \r で終わっていれば、新しい行にも \r を足す
3. 改行がどちらかは、ファイルをバイトのまま読み、CRLFとLFだけの数を数えて確かめる

CERTIFICATE_VERIFY_FAILED: unable to get local issuer certificate

起きたこと

僕のWindowsのPCでは、PythonからHTTPSにつなぐ処理が、軒並み証明書のエラーで止まります。pip（Pythonの部品を入れる道具）も、yt-dlp（YouTubeの字幕などを取る道具）も同じでした。見た目は、ネットにつながらないときのエラーに近いものです。

原因

ウイルス対策ソフトのNorton（ノートン）が、通信の中身を調べるため、相手の証明書を自分で作ったものに差し替えていました。Nortonの大元の証明書（ルート証明書）は、Windowsの証明書ストア（Windowsが信頼する証明書の置き場）には入っています。ところが、pipやrequests（Pythonで通信をするときの定番の部品）、yt-dlpが見ていたのは certifi でした。certifi は、信頼する証明書の一覧をPythonの部品として配っているもので、Nortonの証明書は入っていません。

直し方

1. certifi の一覧（cacert.pem）の後ろに、Nortonの証明書 wscert.pem をつなげたファイルを作る
2. pip には --cert でそのファイルを渡す。requests なら、環境変数 REQUESTS_CA_BUNDLE に入れる
3. yt-dlp は --compat-options no-certifi を付けて、Windowsの証明書ストアを使わせる

分かっていないことpip は24.2から、システムの証明書も既定で使います。手元の22.2.1より新しい pip なら、このエラー自体が出ないかもしれません（推測です）。

閲覧できません (Forbidden access)

Powered by SiteGuard Lite

起きたこと

2026年7月から10月まで、scriptタグ入りの記事や追加CSSの保存が何度も止まりました。REST APIからの保存では、403や「正しいJSONではない」という趣旨のエラーになりました。

原因

止めていたのはWordPressではなく、レンタルサーバーのWAF（攻撃らしい通信を止める門番）でした。サーバーの管理画面の「XSS対策」が、正当な保存を攻撃と見なしていました。「Powered by SiteGuard Lite」の一行が、その目印です。

直し方

1. サーバーの管理画面で、WAF（XSS対策）を一時的にOFFにする
2. 止まっていた保存を、まとめて済ませる
3. 終わったらすぐにONに戻す（引っかかる語句を探して書き換えるのは、守りの回避になるのでしない）

分かっていないことどの文字列に反応したのかは、最後まで分かりませんでした。

SyntaxError: Invalid or unexpected token

起きたこと

2026年7月22日の朝、WordPressの記事に埋め込んだ無料の診断ツールが、公開ページでだけ動きませんでした。入力してボタンを押しても、結果の欄は空のままです。公開ページの中では、&&（「かつ」を表す記号）が && に変わっていました。その時点で公開していた8本のうち、3本で起きていました。

原因

WordPressが記事を表示するたびに通す、wptexturize という処理でした。本文を、< から次の > までのタグらしい部分と、それ以外に切り分けます。タグらしい部分の & は、script の中でも & に置き換えられます。比較の <= や < が、その始まりになっていました。保存された本文は無傷で、表示のたびに書き換わるので、保存し直しても直りません。

直し方

1. script の中の比較の < を、すべて > の向きに書き直す。i < list.length なら list.length > i、a <= 20 なら 20 >= a にする
2. タグを組み立てる文字列の途中に && を置かない。条件は先に変数へ出してから、文字列につなぐ
3. 出す前に、WordPressと同じ区切り方で & が書き換わる行を探す。入れたあとは、公開ページで動かして確かめる

分かっていないこと11月11日の再現は、WordPressのコードの区切り方を写したものです。WordPress本体や、テーマとほかのプラグインの処理までは見ていません。

起きたこと

2026年11月1日、日本語学習チャンネルの動画2本に、英語の吹き替え音声が付いて公開されていました。ショートの題名のローマ字も、英訳に書き換わっていました。

原因

「設定 → チャンネル → 詳細設定」の「オートダビングを許可する」がオンでした。10月3日に見たときは無効で、いつ切り替わったのかは分かりません。11月2日に、このチェックを外しました。

直し方

1. YouTube Studioで動画を開き、左のメニューの「言語」に入る
2. 「英語」の行の音声の▼を開き、「公開停止」を選ぶ（削除すると再公開できない）
3. 「設定 → チャンネル → 詳細設定」の「オートダビングを許可する」のチェックを外して保存する
4. 題名は「詳細」で元の文に打ち直す。設定を外したあとも、予約した動画は公開の直後に「言語」ページの音声の列を見る

利用資格あり

動画をショート動画にリンクするには、電話番号の確認手続きを行ってください。

起きたこと

2026年10月29日、前の日に作ったYouTubeチャンネルで、MVのサムネイル画像を4回入れて、4回とも何も起きませんでした。サムネイルの枠は空のままで、「保存」も押せないままです。エラーの文も、保存の知らせも出ていません。画像は部下役のAIが、ページの中の見えないファイル選択の欄へ直接渡していました。

原因

Studioの「設定」→「チャンネル」→「機能の利用資格」で、カスタム サムネイルを含む「中級者向け機能」の横が「利用資格あり」でした。言葉だけ見ると使えそうですが、公式ヘルプでは、使える機能の横には「有効」と出るとされています。ヘルプによると、中級者向け機能には電話番号の確認が要ります。新しいチャンネルでは、まだ済ませていませんでした。

直し方

1. 「設定」→「チャンネル」→「機能の利用資格」で、「中級者向け機能」の横が「有効」かを見る（「利用資格あり」なら、まだ使えない）
2. 有効でなければ、その段を開き、案内に沿って電話番号を確認する（11月1日に確認したあとは、同じ画像が1回で入った）
3. 確認を待てないときは、Studioが動画から切り出した候補の画像から1枚を選んで出しておく
4. 「保存」を押したら、ボタンが押せない状態に戻るまで待ち、一覧の画像が替わったかを見る

分かっていないこと確認のあとに「機能の利用資格」の表示が「有効」に変わったかは、見ていません。人が手でサムネイルのボタンを押していれば、関連動画のときのような小窓が出たのかも分かりません。

字幕を自動生成しています

起きたこと

2026年9月25日、日本語学習チャンネルの動画に、日本語字幕を srt（セリフと時刻を並べた文字のファイル）で入れました。読み込んで「完了」を押し、4秒後に見ると、字幕の行は「追加」のままでした。10月28日には、あとから入れた字幕が、エディタを開くと音声から自動で起こした字幕のままでした。

原因

1回目が保存されなかった理由は、分かっていません。1回目はAIがページに命令を送る形で「完了」を押し、入れ直した2回目は画面のボタンを押していました。10月28日は、YouTubeが音声から字幕を自動で起こしている最中に、ページ上部の「手動でアップロード」から入れていました。

直し方

1. アップロードの画面なら、「完了」のあと字幕の行が「日本語（あなたが翻訳）」と「編集」に変わったかを見る。「追加」のままなら入れ直す
2. 「字幕を自動生成しています」と出ている間は、エディタの右上の、縦に点が3つ並んだメニューの「ファイルをアップロード」から入れる
3. エディタの1行目が、自分のファイルの1行目と同じになったかを見てから、「公開」を押す
4. 「日本語の字幕を公開しました」と出たのを確かめる。一覧の表示だけでは、公開か下書きか見分けられなかった

分かっていないこと押し方の違いが効いたのか、人が手で同じ操作をしても起きるのかは、確かめていません。「手動でアップロード」で入らなかった理由も、分かっていません。