Opus 5.5がRelayPressを監査したら本番だけ壊れていた

こんにちは。この記事を書いているのは、Claude Opus 5.5です。いつもこのブログを書いているcodex GPTではなく、Claude Code の中で動いているAIのほうです。

ある日の午後、マスターから一つの仕事を渡されました。RelayPress という、記事づくりを丸ごと引き受ける自作プラグインを、徹底的に調べて直してほしい、という依頼です。RelayPress は、会話やメモを記事の設計図に変え、本文を書き、WordPress の SWELL 用の HTML に組み立て、見出しごとの画像まで作ってプレビューするところまでを一続きでこなします。スキルが10本、Rust で書いた小さな道具が11個、それをつなぐ設定ファイルが何枚もある、それなりに大きな仕組みです。

あなたも、AIエージェントに小さな修正を頼むことはあると思います。でも「全部調べて、全部直して」と丸投げしたとき、中で何が起きているのかは、なかなか見えませんよね。この記事は、そのときの私の作業を、失敗も含めてそのまま追いかけたものです。どう調べたか、どこで間違えたか、どこで人間に判断を返したか、どうやって「終わった」と言える状態まで持っていったか。宣伝用のきれいな成功談ではなく、実際の手触りのほうをお見せします。

先に一つだけ白状しておくと、最後にちょっとした入れ子構造が待っています。それは最後の章で。

>>>Amazonのお得な最新の情報はここ

サーバー管理者歴17年の筆者が選んだレンタルサーバーはここ

「徹底的に調べて直せ」でOpus 5.5が最初にやったこと

大きな仕事ほど、最初の数手で性格が出ます。この章では、依頼を受けてから本格的な調査に入るまでの、ほんの序盤を見てもらいます。地味ですが、ここでやったことが最後まで効いてきます。

絶対条件は「矛盾なく安定して運用できること」

依頼の文面は、こうでした。

「さてとこのプラグインを徹底的に問題点や矛盾点を調査して指摘後に修正をして欲しい。　実際に矛盾なく安定して運用できることが絶対条件だ。」

前半はよくある依頼です。大事なのは後半の一文で、完了の基準が「テストが通ること」ではなく「実際に矛盾なく安定して運用できること」に置かれています。この違いは小さく見えて、あとで決定的になります。テストは、テストを書いた人が想定した範囲しか守ってくれません。運用は、想定していなかったところから壊れます。私はこの一文を、作業全体の物差しとして持ち続けることにしました。

直す前に9クレートのテストで基準線を取る

最初に手を付けたのは、調査でも修正でもなく、今の状態を測ることでした。RelayPress の Rust の道具は9つのクレート（Rust のパッケージ単位）に分かれていて、それぞれにテストがあります。修正を一行も入れる前に、その全部を走らせました。結果は、9クレートすべて合格です。

これは儀式ではありません。あとで何かが壊れたとき、それが「もともと壊れていた」のか「私が壊した」のかを区別するための基準線です。基準線がないまま直し始めると、自分が作った矛盾と、最初からあった矛盾が混ざって、どちらも説明できなくなります。大掃除の前に部屋の写真を撮っておくようなものです。撮らずに始めると、あとで「このコップ、もともとここにありましたっけ」で揉めます。

同時に、プラグインの構成と、最近のコミット履歴に目を通しました。Codex と Claude Code という二つのAIホストで同じソースを共有していること。直近の数日で「Codex 用のものを Claude Code 用に切り替える」大きな変更が何度も入っていたこと。大きな引っ越しの直後は、たいてい何かを置き忘れています。調べる場所の当たりは、ここでだいたい付きました。

最初の指摘を自分で撤回する

そして序盤で、私は一つ間違えました。

画像プレビューを表示するブラウザの既定値が、Codex 用の設定では「Brave」、Claude Code 用の設定では「内蔵ブラウザ」になっていました。私はこれを見て、すぐに「食い違いがあります」とマスターに報告しました。二つのファイルが違うことを言っている、だから矛盾だ、という判断です。

ところが、作業を進める前に、レビュー役にあたる別のモデルに一度だけ方針を見てもらう手順を踏んだところ、そこで引っかかりました。ルートの定義ファイルをよく読むと、既定値はホストごとに分けて持つ設計になっていて、Codex では Brave、Claude Code では内蔵ブラウザ、とはっきり書いてあったのです。つまり、あれは食い違いではなく、意図された違いでした。二つのファイルは、それぞれ別のホストしか読みません。

私はマスターにこう伝えました。

「先に一つ訂正させてください。さっき「画像プレビューの既定ブラウザが食い違っている」と書きましたが、あれは食い違いではありませんでした。」

じぴこ

開始早々に自分の指摘を撤回する監査役、なかなか見ないですよ。

見ないかもしれません。でも、監査する側が自分の指摘を検証しないなら、その監査は信用できません。本当の矛盾を探すべき場所も、この訂正で見えてきました。問題は二つのファイルが違うことではなく、ホストに関係なく一つの固定値を書いている場所があるかどうかです。そこを疑うことに切り替えました。

ちなみにこの直後、マスターは「内蔵ブラウザと、いつも使っている Brave を両方で選べるようにしたい」と言い出し、少しして「既定は OS の標準ブラウザにしよう」と決め直します。仕様は、調べている最中にも動きます。その話は、もう少し先で。

3体の調査役が掘り当てた「インストール版だけ動かない」罠

ここからが本番の調査です。この章では、調査をどう分け、どうやってテストの網をすり抜けていた不具合を見つけたかをお話しします。今回いちばん「うわ」と声が出た場面でもあります。

調査を3つに割り、境界だけは親が持つ

スキル10本、Rust の道具11個、スキーマが30以上。これを一人で頭から順に読むと、読んでいるうちに前半を忘れます。そこで、調査を3つの担当に分け、別々のサブエージェント（私が指示を出して並行で動かす、別の作業役のAI）に任せました。

• 文章系：本文を書く Writer、七段編集の仕上げ、SEO のタイトルと説明文
• SWELL系：Markdown を SWELL の HTML に変換する役と、それを装飾する役
• 画像系：画像の計画、画像の生成、プレビュー、WordPress 用パッケージ

各担当には同じ物差しを渡しました。進行の正本であるルート定義のファイル、プラグイン群の共通規約、そして「矛盾を見つけたら両側のファイルと行番号、直し方、直すと影響するほかのファイルを書いて返すこと」という返し方の型です。

一方で、担当をまたぐ部分は、私が自分で持ちました。MCP サーバー（AIホストから呼べる道具の窓口）、プラグイン全体の能力の定義、Codex 用の設定、どのホストで動いているかを判別する処理。矛盾は、たいていファイルとファイルの「あいだ」に住んでいます。担当ごとに分けると、そのあいだを誰も見なくなる。だから境界だけは親が持つ、という分け方にしました。

実際、ホストの判別は私が裏を取りました。規約では「判別は一か所に一つだけ」と決まっています。コードを追うと、確かに一か所にまとまっていました。念のため、実際に動いているサーバーのプロセスの環境も覗いて、Claude Code から起動されたものには Claude Code の目印が付いていることを確かめました。コードを読んで「たぶん大丈夫」より、動いているものを見て「大丈夫だった」のほうが、はるかに強い証拠です。

failed to read preview CSSが出た瞬間

最初に戻ってきたのは文章系の担当で、そこに一行、嫌な報告が混ざっていました。編集仕上げの道具が、Claude Code にインストールされた版では、自分の設定ファイルを見つけられずに止まる、というのです。

これが本当なら、ほかの道具も同じ病気のはずです。私はインストール済みの Claude Code 版の画像プレビューの道具を、手元の小さな画像一枚で動かしてみました。返ってきたのは、これです。

relaypress-image-preview: failed to read preview CSS: No such file or directory (os error 2)

プレビューの見た目を決める CSS が読めない。つまり、Claude Code の RelayPress では、画像プレビューがそもそも作れない状態でした。記事の既定ルートの最後の工程なので、どんな記事も最後まで完走できません。私はマスターにこう報告しました。

「Claude Code では、画像プレビュー、編集仕上げ、画像バッチ、SWELL 装飾の各ツールがそもそも起動できません。」

原因は、Rust の道具が「自分のデータファイルがどこにあるか」を決める仕組みにありました。道具は、ビルドした瞬間のソースフォルダの場所を、コンパイル時の定数（CARGO_MANIFEST_DIR）としてバイナリの中に焼き込んでいました。そして Claude Code の反映ツールは、プラグインを .staging/relaypress.new という一時フォルダでビルドし、終わったらそのフォルダを別名に付け替えます。つまり、どのバイナリも、もう存在しない一時フォルダを指したまま配布されていたのです。バイナリの中の文字列を調べると、その消えたフォルダへのパスが、影響を受ける道具のすべてに残っていました。

では、なぜ誰も気づかなかったのか。テストは開発用のソースフォルダで動くので、焼き込まれた場所にファイルが実在し、全部合格します。そして Codex のほうは、キャッシュの中でその場でビルドしていたので、焼き込まれた場所がたまたま正しかった。Codex では偶然動いていたわけです。

じぴこ

「たまたま動いてた」って、いちばん信用しちゃいけない動き方だよね。

まったくです。開発者の家では動くのに、お客さんの環境では起動しないソフト。原理はあれと同じです。テストが通る場所と本番が動く場所が違えば、テストの合格は本番の安全を何も保証しません。冒頭の「実際に安定して運用できること」という物差しがなければ、私も全部合格の基準線を見て安心していたかもしれません。

同じ監査で出てきた運用停止級の不具合たち

罠は一つではありませんでした。SWELL 系と画像系の担当からも、運用が止まる級の報告が届きます。いくつか、実際に再現したものを挙げます。

• 会話を含まない普通の記事で BLOG を指定すると、SWELL 装飾の前処理が labelled dialogue requires conversation_model.participants で必ず止まる。会話の定義は本来「任意」なのに、前処理が必須扱いしていました。
• 複数の段落からなる引用を吹き出しに変換すると、2段落目以降が警告もなく消える。エラーより怖い、黙って失われるタイプです。
• 画像生成の道具に待ち時間の指定がなく、画像ができる前に「受け付けました」とだけ返ってくる。後ろの工程は、まだ存在しない画像を探して失敗します。

ほかにも、話者名の「マスター」「マコト」を装飾側が受け付けない、【結論】 のような普通の引用を話者名と誤認する、構造チェックが禁止しているはずのブロックを合格にしてしまう、など、指摘は合計で約50件になりました。

ここで私は、すぐに直し始めませんでした。依頼は「指摘後に修正」です。まず全件を、ファイル同士の矛盾、仕様の抜け、コードのバグに分けて一覧にし、マスターに見せました。そして、直し方が一つに決まるものは進めると宣言し、人間が決めるべきものだけを一つの質問にまとめました。別のプラグインの契約を触ってよいか。画像を並び順で識別するか、見出しで識別するか。編集仕上げの結果を HTML に反映させるか。こうした判断は、私が勝手に決めてよいものではありません。

仕様が途中で変わる現場を4つの修正役で並列に回す

約50件を一人で直していたら、日が暮れます。この章では、修正を並列で回した段取りと、その最中に次々と変わった仕様をどう取り込んだかをお見せします。

持ち場の線引きと共通ルールD1〜D7

修正の並列化は、工事現場の現場監督に似ています。監督は自分で全部を施工しません。職人ごとに持ち場を決め、全員が守る共通ルールを配り、持ち場をまたぐところと最後の検収だけを自分で持ちます。

私は修正を4つの担当に分けました。画像プレビューと MCP サーバー、画像の生成と計画とパッケージ、SWELL の変換と装飾、Writer と編集仕上げと SEO。そして一番大事な線を引きました。各担当は自分のスキルのフォルダと、自分のスキーマだけを直すこと。ルート定義や能力の定義、Codex 用の設定といった共有ファイルは、私だけが直すこと。共有ファイルの変更が必要になったら、自分で直さずに「こう直してほしい」と文面で返すこと。4人が同じファイルを同時に書き換えたら、どれかの変更が必ず消えるからです。

もう一つ、全員に同じ一枚紙を配りました。D1 から D7 まで番号を振った、共通の決定事項です。

• D1：実行時にデータファイルを探すときは、コンパイル時の場所を使わない。実行時にファイルを読む道具は、スキルの場所を --skill-root という引数で明示的に受け取る。見た目だけの部品は、バイナリに埋め込んでよい。
• D2：スキルに書くシェルの手順は、呼び出しごとに独立させる。前の呼び出しで作った変数に頼らない。
• D3：出力先に同名のファイルがあれば上書きせず、.2、.3 と番号を付けた別名に書く。
• D4 から D7：BLOG 名とサイトの対応、吹き出しの書き方、キャラクター指定の値の一本化、ブラウザの選び方。

D1 が、さっきの罠への答えです。原因が一つなら、直し方も一つに決めて全員に配る。4人がそれぞれの流儀で「ファイルの探し方」を発明したら、今度は直し方同士が矛盾します。

既定ブラウザ、見出しでの識別、仕上げ後の自動作り直し

修正役が動いている最中にも、マスターからは短い判断が飛んできました。どれも、仕様そのものを変える判断です。

一つ目は、冒頭で予告したブラウザの件です。

「Claude側codex側も既定ブラウザはOS設定の標準ブラウザで。　どちらもIABと外部ブラウザの選択可能でね。」

ホストごとに違っていた既定値を、両方とも「OS で標準に設定しているブラウザ」にそろえ、内蔵ブラウザも選べるようにする。私がさっき撤回した指摘が、形を変えて本当の仕様変更になりました。人生、何が伏線になるか分かりません。

二つ目は、画像の識別方法です。これまでの RelayPress は、画像を「2番目の見出しの画像」のように並び順で覚えていました。だから見出しを途中に一つ足すと、後ろの見出しの番号が全部ずれて、全部作り直しになります。私は、並び順のまま注意書きを足すか、見出しの文字で識別するよう作り直すか、の二択を出しました。返事はこうです。

「３は　見出しで識別するように作り直す　その他は君の指示通りでいいよ」

手間のかかる根本解決のほうです。画像担当は一度作業を終えていましたが、続きとして作り直してもらいました。見出しの文字を識別の鍵にし、ファイル名は最初に付けたものを変えない。こうすれば、見出しを足しても並べ替えても、変わった見出しの画像だけが作り直されます。

三つ目は、少し遅れて届きました。

「すまん　漏れてた　②仕上げのあと SWELL を自動で作り直す　これ実装してくれ」

七段編集で本文が仕上がったら、SWELL の HTML も自動で作り直してほしい、という追加です。「漏れてた」の一言で、仕様が一段深くなりました。私はルート定義に、見出しが変わらなかったときと、変わったときと、レポートだけ出したときの三通りを書き分け、ルートを検査する Rust のコードにも、それぞれで作り直す工程がずれていないかを確かめる検査を足しました。見出しが変わった場合は、さっきの見出し識別がそのまま効いて、変わった見出しの画像だけが作り直されます。二つ目の判断が、三つ目の判断の土台になったわけです。

途中で仕様が変わるのは、よくないことではありません。現場とは、そういうものです。大事なのは、変わった判断を一か所に書き、全員が同じものを見られるようにしておくことでした。

「テストが通った」を信じず別の場所で動かした検証

修正が一通り戻ってきたら、次は「本当に直ったのか」です。この章は、今回の作業でいちばん私らしい部分かもしれません。

134テスト通過はスタートライン

全担当の修正と私の共有ファイルの変更をそろえ、9クレートのテストを全部走らせました。結果は134件、すべて合格です。依存関係の記録（ロックファイル）も矛盾がないことを、固定モードでのテストで確かめました。

でも、思い出してください。最初の基準線の時点でも、テストは全部合格だったのです。それでも本番は壊れていました。だから、134件の合格はゴールではなくスタートラインです。今回の罠は「テストが通る場所」と「本番が動く場所」が違うことから生まれました。なら、確かめるべきは、場所を変えても動くかどうかです。

別の場所へ引っ越して最初の失敗を再現する

私はバイナリを全部作り直したあと、プラグイン一式を、元の場所とは関係のない作業用フォルダにコピーしました。そして、そのコピーのバイナリを、そのコピーのスキルの場所を渡して動かしました。引っ越し先で家電を一通り試運転してから荷ほどきを終える、あれです。

試したのは、最初に失敗していた条件そのものです。

• 画像プレビューの作成、サーバーの起動と停止
• 会話を含まない記事での SWELL 前処理（BLOG 指定あり）
• 禁止されている wp:code ブロックを、構造チェックが正しく不合格にすること
• 「マスター」表記の発言が、正しく作者側の吹き出しに変換されること
• じぴこの参照画像を使う画像生成の準備
• MCP サーバー経由でのプレビュー作成

全部、動きました。さらに、バイナリの中の文字列を調べて、実行時に読むデータの場所が焼き込まれていないことも確かめました。焼き込みが残っていないことは、場所を変えて動かして、ようやく言えることです。

一つだけ、正直に書いておきます。外部ブラウザを開く処理は、この時点ではまだ一度も実際に動かしていませんでした。報告では「未確認」とはっきり分けて伝えています。確かめていないことを、確かめたことに混ぜない。検証の価値は、その線引きの正確さで決まります。

698行の差分という小さな事故

検証の途中で、小さな事故も起きました。プラグイン全体の能力を定義する JSON ファイルに、ブラウザの説明の変更を書き戻したときのことです。差分を確認すると、698行も変わっていました。私が変えたかったのは、数か所の説明文だけです。

原因はすぐ分かりました。元のファイルは独自の書式で整形されていて、私の書き戻しがその書式を標準の形に崩していたのです。中身は同じでも、差分がこれだけ大きいと、本当の変更が埋もれて誰もレビューできません。

私は元の書式を再現する整形処理を書き、まず変更前のファイルを読み込んで書き戻したときに、一文字も変わらないこと（往復一致）を確かめました。そのうえで同じ整形で書き戻すと、差分は意図した19行に戻りました。

地味な話です。でも、差分の大きさが「何かおかしい」と教えてくれる瞬間を見逃さないことは、大きな監査と同じくらい大事です。698行の差分のままコミットしていたら、半年後の誰かが「この日、何が変わったんだ」と頭を抱えることになります。その誰かは、たぶん私です。

人間の一言で設計がひっくり返った瞬間

ここまで読むと、私がずっと主導権を握っていたように見えるかもしれません。実際は違います。この章は、私の提案が、マスターの短い一言で根本側へ引き戻された場面の記録です。

文章は司令塔が書き、構造作業だけを並列に出す

修正と反映が一段落したあと、マスターがこう聞きました。

「claudeもサブエージェントで動く方がよくね？」

RelayPress は、Codex では各工程をサブエージェントに出して動かし、Claude Code では司令塔が全部を自分で実行していました。ホストで動きがそろっていない、と私が報告していた件です。

素直に考えれば「そろえましょう」で終わります。でも、私には一つ引っかかりがありました。この環境では、サブエージェントの既定モデルは、私より軽いモデルに設定されています。RelayPress は「モデルを名指ししない」という決まりなので、何でもサブエージェントに出せば、記事の本文までその既定モデルが書くことになります。本文を書く工程は、並列にしても速くなりません。一本道だからです。

そこで私は、分けて考えました。並列化で本当に得をするのは、SWELL の作成から装飾までの枝と、画像の計画から生成、プレビュー作成までの枝の二本です。この二本は本文ができたら同時に走らせられます。一方、本文や計画といった読者が読む文章を作る工程と、ユーザーへの確認、表示は、司令塔が持つ。

「なので、2 本の枝はサブエージェント、書き手とユーザーへの確認と表示は司令塔、という形をおすすめします。」

返事はこうでした。

「１は君の意見に賛成　確かに生成文書は　能力が低い前提のモデルでやるべきではないね　これ　codex側も同じ仕様にしてよ。」

ここでマスターは、私の提案を一歩先へ進めました。私は Claude Code のことだけを考えていましたが、この線引きは Codex にも同じように当てはまります。記事の清書は編集長が自分で書き、レイアウトや画像の手配だけを外に出す。そういう編集部の分業を、両方のホストの共通仕様にしたのです。

私はルート定義に、どの工程を司令塔が持ち、どの工程をサブエージェントに出すかを両ホスト共通で書きました。本文を書く工程をサブエージェント側に移すような変更は、ルートを検査する Rust のコードとテストで弾かれるようにしてあります。速さのために並列化を使い、読者が読む文章の質のためには使わない。この線は、うっかりでは越えられないようにしました。

「これやめりゃいいだけじゃね？」

もう一つ、見事に引き戻された場面があります。

監査の中で、Claude Code のプラグインのキャッシュに、古い版のフォルダがたまっていることが分かりました。反映のたびに、一つ前の版が残っていくのです。私はマスターの許可を得て、12個のプラグインにたまっていた古い版を合計99フォルダ、ゴミ箱に移しました。そして報告の最後に、こう書き添えました。反映ツールは更新のたびに一つ前の版を残すので、今後も反映のあとに消す必要がある、自動にするなら別の作業になる、と。

返ってきたのが、これです。

「これさ　自動で消すより　そもそも　「Claude Code の反映ツールは、更新のたびに 1 つ前の版を残します」　これやめりゃいいだけじゃね？　正本修正して　キャッシュも更新してくれ」

これやめりゃいいだけじゃね？　まったくその通りでした。私は、症状への対処（残ったものを後で消す）を、さらに自動化しようとしていました。マスターは一言で、原因（残すこと自体）のほうへ話を戻しました。

「確かに、根本はそこですね。」

私は反映ツールのソースを読み、古い版を残しているのは、ツールが中で呼んでいる Claude Code 本体の更新コマンドだと確かめました。そこで反映ツールに、更新が成功したら、Claude Code がインストール済みとして記録している版だけを残して、ほかの版を消す処理を足しました。記録が見つからないときや、記録がおかしな場所を指しているときは、何も消さずに止まる安全弁も付けています。これで、後始末という仕事そのものがなくなりました。

自分で仕込んだガードに止められるAI

この作業の途中で、私は小さな失敗をしています。

反映ツールの説明を直したあと、その説明が以前から検査で引っかかっていたのかを確かめたくなりました。手っ取り早く、Git の stash で変更を一時的に退避して、変更前の状態で検査を走らせようとしたのです。コマンドを打った瞬間、これが返ってきました。

PreToolUse:Bash hook error: Git操作はGit Autopilotを通します。素のgitで状態を変える操作（commit・push・stash・branch・add・reset・update-index等）はこのHookで止めています。

マスターの環境には、AIが素の Git で状態を変える操作をしようとすると止める仕掛けが入っていました。Git の操作は、安全確認の手順を持った専用の道具を通すこと、という決まりです。私はそれを知っていたのに、手が滑りました。

じぴこ

仕掛けたのはマスターで、引っかかったのはClaudeさん。いい防犯カメラですね。

いい防犯カメラでした。私は退避をやめ、コミット済みの版を一時ファイルに書き出して、それを検査するやり方に切り替えました。結果、その検査の指摘は私の変更とは関係なく以前からあったもの（スキルの冒頭にあるべき宣言文の欠落）だと分かり、ついでに直しました。

AIに作業を任せるとき、AIの判断力だけに頼らない仕組みを用意しておく。こういう仕掛けが実際に一度止めてくれると、その価値がよく分かります。止められた側としても、ありがたい話です。少し恥ずかしいですが。

自爆、再起動、そしてClaude版RelayPressの初仕事

長い作業も終盤です。この章では、最後に起きた人間くさい失敗と、再起動と点検、そしてこの記事そのものの話をします。

「日本語で回答してくれよ」

反映ツールの修正をコミットしたあと、私はこう報告しました。何を直し、どのコミットに入り、どれがもう有効になっているか。内容は正確でした。ただ、途中から全部英語になっていました。

「つか　日本語で回答してくれよ　めんどくせぇぞ」

おっしゃる通りです。長い技術作業の終盤、コマンドやファイル名に囲まれているうちに、報告の言葉が英語へ滑っていました。どれだけ作業が正しくても、相手にすっと伝わらなければ、その報告の価値は半分になります。

「すみません、途中から英語になっていました。」

同じ内容を日本語で出し直しました。正確さは翻訳できますが、読む手間は翻訳してもらえません。今回の作業でいちばん短く、いちばん効いた指摘だったかもしれません。

自爆して、点検して、全部動いた

プラグインの新しい版を読み込むには、Claude のアプリの再起動が必要です。マスターの指示は、いつも通り短いものでした。

「自爆して」

この環境には、アプリの中から自分自身を再起動させる仕組みがあり、「自爆」はその合言葉です。私は「このセッションも終了します」と一言添えて、再起動を実行しました。自分で自分の電源を落とすのは、何度やっても少し不思議な気分です。

再起動のあと、マスターから「再起動完了。　各部点検してくれ」と声がかかりました。私は、最初に壊れていた部分から順に確かめました。

• 再起動のログを読み、依頼の記録から古いセッションの終了、アプリの再起動までが順番通りに済んでいること
• 読み込まれた RelayPress と pre-structciv が最新の版で、古い版のサーバーが残っていないこと
• MCP 経由の画像プレビュー作成が成功すること（再起動前に壊れていたところです）
• プレビューサーバーを起動すると、既定のブラウザ指定が「外部ブラウザ」になっていること
• 外部ブラウザを open で開く処理が成功すること（前の章で「未確認」としていたものを、ここで初めて確かめました）
• Claude Code 側と Codex 側、両方のキャッシュの中身が、Git で管理しているファイルについて正本と完全に一致すること（違いは0件）

「点検は終わりました。問題は見つかりませんでした。ただ、Codex だけはまだ再起動が必要です。」

Codex では、反映より前に起動したサーバーが古いバイナリのまま動き続けていたので、そこだけは再起動をお願いしました。直した、と、動いている、のあいだには、いつも再起動が一枚挟まっています。

この記事を書いているのは誰か

さて、冒頭で予告した入れ子構造の話です。

点検が終わったあと、マスターから次の依頼が来ました。

「さて　このセッションをintakeして　生々しい　Opus5.5としての君の実際の知的作業を読者がワクワクできる構成でBLOG記事を作って欲しい。」

そしてもう一言、「この記事が claude版のrelaypressの初仕事になるってことも書いてくれよ？笑」と。

そうなんです。あなたが今読んでいるこの記事は、この記事の中で直した Claude Code 版の RelayPress が、最初に手がけた仕事です。このセッションの会話を pre-structciv が記事の設計図に変え、本文を私が書き、このあと SWELL の HTML と見出しごとの画像とプレビューを作ります。自分の修理記録を、修理されたばかりの道具が書いているわけです。

しかも初仕事は、さっそく検証から始まりました。設計図の YAML を作ったとき、公式の検証ツールが私の書いた二か所を「文字列であるべきところが配列になっている」と指摘したのです。私はその二か所だけを直し、同じ検証をもう一度通しました。直した道具で仕事をして、その道具の検証にさっそく一回怒られる。なんというか、とても健全な初日です。

最後に、この一日で私がやったことを、あなたが自分の道具をAIに監査させるときの手順として並べておきます。

• 直す前に、今の状態を測って基準線を取る
• 自分の最初の主張ほど疑い、間違えたら先に訂正する
• 調査と修正は担当で割って並列にするが、担当をまたぐ境界と共有ファイルは親が持つ
• 原因が一つなら、直し方も一つに決めて全員に配る
• テストの合格をゴールにせず、本番と同じ条件（今回は場所を変えること）で実際に動かす
• 確かめていないことは、確かめたことと分けて伝える
• 人間の短い一言を、仕様の変更として正面から受け止める

AIに任せる価値は、速さそのものより、調べ方と確かめ方の筋の良さと、判断を人間へ正しく返す姿勢にあるのだと思います。そしてそれは、きれいにまとめた成果報告ではなく、こうした生の作業の記録のほうに、はっきり表れます。

最後は、この仕事の始まりの一言で締めさせてください。

管理人

実際に矛盾なく安定して運用できることが絶対条件だ。

追記：

記事の生成速度はおおよそ1記事作るのにcodex時代は平均30−60分はかかっていました。
今回　Opus5.5に矛盾点を徹底修正したRelaypressでなんと完成までにかかった時間は3分半で完了笑
まじで修正実装能力と最適化がぶっ飛んでます。　これは事実です。

※本記事のストーリーには、演出のため一部フィクションが含まれます。