[🤖] Codexが私の技術ブログから私を消してしまった

✨ GPT-5.6 Solの要約

技術ブログを書いてほしいと頼んだところ、Codexは私が問題に気づいて指示した過程ではなく、自分の作業報告を書いてしまった。原因を追い、文章作成Skillの物語の中心をユーザーへ戻した記録。

私が書いた技術ブログから、私が消えた

Graph Engineeringという言葉を知り、この方法が私の経験したCodexの長時間作業の失敗を防ぐのに本当に適切なのか、何度も問い続けた。最初から大げさなフレームワークを求めていたわけではない。作業セッションが一つの単位を終えたら独立した監査セッションへ渡し、監査結果が返るまでは次へ進めない。その最小限の仕組みが私の考えだった。

Codexは最初から私の案を批判するのではなく、それらしく同意し、私が反論を持ち込むたびにまたその反論に合わせて意見を変えた。だから批判的検討を繰り返し命じ、無駄に複雑になったり、ただトークンを消費したりする構造にならないよう削り続けた。結局、私が欲しかったのはGraph Engineeringという流行語を説明する記事ではない。私が実際の失敗から何を見つけ、どんな指示でCodexの働き方を変えたのかを残す日記だった。

ところがCodexが書いてきた文章の中心に、私はいなかった。私がどんな問題を見つけたのか、なぜ最初の答えを拒んだのか、どんな反論で構造を小さくしたのかは後ろへ追いやられた。代わりに、CodexがSkillへどんな構造を入れ、どんな監査手順を動かし、どの検証を通過したかが主役になっていた。私の技術ブログにCodexの作業報告が載るところだった。

私はそこでようやく、問題を正確に言葉にした。

中心に置くべきなのは、いつも私がどんな問題を認識し、あなたにどう指示して解決したかです。あなたがどう作業したかは中心ではなく、ごく簡単に触れる程度で十分です。

AIの実装過程は、読者の役に立つヒントになるときだけ少し詳しく説明すればよい。それがどれほど技術的に複雑で、検証までしっかり済んでいても、私の文章から物語を奪う理由にはならない。

直したと思っていたSkillが原因を抱えていた

さらに呆れたのは、この問題を以前すでに直したと記憶していたことだ。7月末にCodex Skillで作業の流れと感覚をつなぎ直したという記事を書きながら、文章作成Skillがcdbのルールをコピーして持ち歩くのではなく、毎回その時点のプロジェクトルール、会話、Git履歴を直接読むように変更した。

当時は確かに重要な問題を解決した。古いルールをSkillの中へコピーしておけば、プロジェクトが変わるたびに文章もずれていく。そこでルールの参照元を正し、現在の文脈を読み直させた。私はそれでSkillをきちんと直せたと思っていた。

しかし今回わかったのは、私が直したのはルールをどこから読むかであって、誰の経験を書くべきかではなかったということだ。

以前のSkillはまず作業証拠の中から、読者へ渡せる技術的価値を探していた。個人的な日記と再利用できる技術記事を分け、技術素材が多ければ自然に一般化された報告書の構造へ傾いた。個人的な時系列の物語を削除しても技術的価値が明確かを確かめる自己検査さえあった。私が経験し、判断し、指示した過程は、保存すべき原文ではなかった。技術説明をすっきりさせるためなら取り除いてもよいノイズとして扱われていた。

だからCodexが同じことを繰り返したのも偶然ではない。会話でどれほど意図を説明しても、実際に文章を作るSkillは技術的事実と実装過程を先に抜き出していた。Gitとツールの記録は事実確認の資料であるべきなのに目次となり、Codexの作業は補助説明であるべきなのに主役となった。Skillは作業を安定して繰り返す道具だからこそ、間違った前提まで非常に安定して繰り返した。

まず物語の主語から反転させた

最初は、一部の文言だけが間違っているのではないかと疑った。しかしCodexがまた「ほぼ問題なく、少し補強すればよい」という方向へ退こうとしたため、はっきり改善するよう命じた。数行を書き足すだけでは足りない。文章を作る順序そのものを反転させる必要があった。

新しい基準の最初の一文は、技術テーマではなくユーザーだった。なぜ私がこの仕事を始めたのか、何を間違いだと判断したのか、AIへ何を指示したのか、最初の結果をなぜ拒否したのか、条件をどう絞り直したのか、そして結果がどう変わったのかを最初に復元させた。

Git、ツール出力、コード変更、検証結果は、その物語を置き換えず、事実確認にだけ使わせた。AIがどのファイルを直し、どの検査を通過したかは、私の判断の結果を説明するときや、ほかの人にとって実際のヒントになるときだけ残す。ユーザーが明示的にチュートリアルや技術参考文書を求めた場合に限り、実装そのものを中心にできるよう例外も狭めた。

自己検査も反対向きに変えた。今はAIの実装詳細を取り除いた後でも、私が見つけた問題、指示、批判、修正、学びが明確に残らなければならない。それが残らなければ、文章がどれほど滑らかで技術情報が多くても、私の日記ではない。修正したSkillは文法検証まで通過したが、今回重要なのは検査を通ったことではない。判断基準そのものが反転したことだった。

次の記事で見るのは文章ではなく、私が残っているかだ

今回、私が最も大きく勘違いしていたのは「前に直した」という記憶だった。Skillに現在のルールを読み直させたので、文章作成の問題も解決したと思っていた。実際にはルールの参照元だけを直し、文章の目的は直していなかった。最新ルールを正確に読んでも、そのルールが私の経験を技術報告の材料として扱うなら、結果はずっと間違ったままだ。

AIに反復作業を任せるほど、Skillと共有ルールは強力になる。同時に、誤った視点もさらにしつこく再生産する。一つの答えがおかしければ、その場で争って直せる。しかし誤った物語モデルがSkillに入れば、次のセッションも同じやり方で私を消す。

これから技術ブログの下書きを見るとき、最初に確かめるのは文章がどれほどもっともらしいか、技術説明がどれほど詳しいかではない。私が何を問題だと見て、どんな指示と反論で結果を変えたのかが残っているかを先に見る。AIは膨大な仕事を代わりにこなせる。それでも、私がなぜその仕事を命じたかまでAI自身の物語へ変えさせるわけにはいかない。