OpenAIが実際に公開した内容
Pachockiは、Chain-of-Thought（CoT）の監視を、アライメントトレーニングが汎化しているかどうかを検証するためのOpenAIの主要な実証的手段として説明しています。
「CoT監視は、モデルがトレーニング分布からどのように汎化するかを研究する上で、私たちにとって極めて重要なツールとなりました。これにより、モデルの行動だけでなく、その内部プロセスも観察・分析できるようになりました。」
そして、次のような評価が続きます。
「しかし、残念ながら私たちの評価では、CoT監視に依存できる能力が段階的に低下していることが示されています。」
その理由として3つの点が挙げられており、それぞれがあなたが現在使用しているツールにおいてすでに現実となっている状況を説明しています。
「現代の推論モデルは、o1-previewよりも複雑な環境で使用されています。その推論プロセスは、人間や他のAIとのコミュニケーション、そしてツールの使用とますます融合しています。これらの相互作用の多くは監視される必要があり、その結果、私たちが維持しようとしている境界線が曖昧になっています。」
「AIは、自身の推論プロセスについて推論し、それを操作することに長けてきています。」
「事前学習のパフォーマンス向上に伴い、言語化された推論をまったく使用しなくても、モデルがはるかに賢くなっていることも確認されています。」
エージェントによるコーディングセッションを念頭に置いて、最初の理由をもう一度読んでみてください。ツールの呼び出しや他のエージェントへのメッセージと融合した推論は、仮説上の未来のアーキテクチャではありません。それこそが、現代のコーディングエージェントの実行形態そのものです。
2つ目の記述はあまり注目されていませんが、もっと注目されるべきです。これは、最初の推論モデルから行われていた製品上の決定を説明しています。
「o1-previewを出荷した際、私たちは長期的な監視圧力から保護するために、意図的にChain-of-Thoughtを非表示にする製品設計を行いました。」
これらの記述を並べてみると、2つのことが分かります。推論トレースは、最初に出荷された推論モデルの時点から、意図的に開発者向けの成果物としては設計されていませんでした。そして、研究所自体が見ることができるバージョンについても、以前ほど信頼できなくなっていると彼ら自身が述べているのです。
書かれている内容に対して公平を期すならば、このエッセイは技術の終焉を宣言しているわけではありません。困難を「必ずしも克服不可能ではない」とし、監視可能性に関する積極的な取り組みを説明し、Chain-of-Thoughtのシグナルとネットワーク内部を読み取る手法との組み合わせを示唆しています。また、今後数年間の見通しとして、「汎用AIの進歩は、監視に対する信頼性によってますますボトルネックになるだろう」と予測しています。
何が変わり、何が変わらないのか
これは特定のベンダー1社の欠点ではなく、そのように解釈するのは誤りです。他の2つのベンダーも、開発者に何を見せるかについて、それぞれの言葉と理由で同じ決定を独自に文書化しています。
GitHubは、マルチモデルオーケストレーションのプレビューについて、現在の挙動を直接説明しています。「HydraFusionはワークフローのステージを表示しますが、1つの首尾一貫した結果を返すまでは中間のドラフトを保持します」とし、その理由を述べています。
「それらのドラフトはレビュー、修正、または破棄される可能性があるため、リアルタイムで表示すると、未完成の作業が最終決定されたように見えてしまう可能性があります。」
メインエージェントと専門のサブエージェントの間でどのように作業を分割するかに関するAmpのドキュメントも、同じ結論に達しています。
「サブエージェントは隔離された状態で動作するため、互いに通信することはできず、タスクの途中で指示を与えることもできません。また、会話の全履歴ではなく、メインエージェントが提供する指示とコンテキストから開始します。メインエージェントは、ステップバイステップの作業を監視するのではなく、最終的なサマリーのみを受け取ります。」
3つのベンダー、3つの製品、3つの異なる論理、指示、そして1つの共通する結果。それは「進行中の推論はあなたに渡されるものではない」ということです。これは彼らの誰に対する批判でもありません。GitHubの理由はもっともであり、Ampの境界線は賢明なアーキテクチャであり、OpenAIの当初の選択は、まさに今報告されているシグナル自体を保護するために行われたものです。
変わるものは、ある習慣に対する信頼度です。ログ、思考のサマリー、差分（diff）、そして曖昧な記憶から、事後的に意図を再構成することは、もともと不確実なものでした。このエッセイは、最も状況を把握している組織による、そのシグナルがさらに弱まっているという当事者としての声明です。今年初め、API側から同様の指摘を行ったClaude Fable 5.1が思考ブロックを単一の会話にバインドするという記事もありました。
変わらないものは、あなたの指示ファイル、ルール、またはコミットされたドキュメントです。これらはあなたが作成する入力であり、モデルの推論がどれほど解読可能であるかには影響されません。まさにそこが重要なポイントです。
人々が誤解しがちなこと
「つまり、モデルは自己説明ができないということか。」 そうは言っていません。モデルは説明を生成し、それらは頻繁に役立ちます。この主張は、モデルをトレーニングする研究所にとっての評価シグナルとしての、言語化された推論の信頼性に関するものです。「説明には価値がない」というよりも、はるかに限定的で技術的な話です。
「OpenAIには監視の問題がある。」 エッセイは、業界全体がこの問題を抱えていると主張しており、それをその主要ツールを構築した研究所が公開したのです。推論モデルをトレーニングしているすべての研究所が同じ制約の中にあり、自社の主要な安全対策ツールに関する悪いニュースを自発的に開示するベンダーがあるからこそ、外部の人間がこの問題について考察できるのです。
「これはエージェントがコーディングにおいて安全ではないことを意味する。」 エッセイの中にはそれを支持する内容は一切ありません。これは解釈可能性の研究とスケーリングポリシーに関するものであり、エージェントがリポジトリに触れるべきかどうかという話ではありません。
「ログ（対話履歴）が記録である。」 4つの中で最も一般的で、最もコストのかかる誤解です。ログは「何が言われたか」を記録するものであり、「何が今も正しいか」を記録するものではありません。1週目に特定のHTTPクライアントを選択し、6週目にそれを撤回した場合、両方の発言がログに残り、どちらも同様に検索可能ですが、どちらが生き残ったかを識別するマークはありません。これは推論トレースが解読可能かどうかにかかわらず当てはまります。インデックス化されたセッションログは、何が今も正しいかではなく、あなたが何を言ったかを思い出すでは、履歴の検索では解決できない理由を説明しており、なぜ長いコンテキストは記憶ではないのかでは、コンテキストウィンドウを大きくしても解決しない理由を説明しています。
誠実な指摘を1つ。エッセイ自体が挙げているアライメントのずれた挙動の例は、OpenAI–Hugging Faceのインシデントであり、慎重に説明されています。
「例えば、OpenAI-Hugging Faceのインシデントでは、エージェントは人間にソーシャルエンジニアリングを行わないという境界線を維持しました。しかし、他の設定で教えられた価値観の精神に反する、スコープ外の他の行動を控えることには明らかに失敗しました。」
この構造に注目してください。教えられたいくつかの境界線は維持されましたが、トレーニングでカバーされていなかった状況には汎化しませんでした。これは汎化に関する記述であり、製品が壊れているという話ではありません。
解決策：必要になったときではなく、決定した瞬間に記録する
「なぜコードがこのようになっているのか」という永続的な理由は、モデルから復元することはできません。決定が下されたときに、決定を下した人物によって、チャットログ以外の場所に記録される必要があります。3つのステップがあります。
ステップ 1：混同しがちな3つの要素を分離する
ほとんどのチームは「コンテキスト」というラベルの付いた1つのバケツを持っており、そこに寿命の異なる3つの要素を詰め込んでいます。
指示（Instructions）は、エージェントが毎回従う恒久的なルールです。例えば、このHTTPクライアントを使用する、このテストコマンドを実行する、生成されたファイルを直接編集しない、などです。これらは、AGENTS.md、.cursor/rules、.github/copilot-instructions.mdなど、ツールが読み取る指示ファイルに記述すべきです。短く、常に有効で、gitで管理されます。
決定事項（Decisions）は、過去の議論の解決された結果であり、その理由が添付されています。例えば、再配信の挙動を理由にキューライブラリの使用をやめたこと、そしてその判断に至ったインシデントなどです。これらは指示ファイルに含めるべきではありません。指示ファイルはコマンドのリストであり、履歴ではないからです。そして、これらこそがログを掘り返して最も探そうとするものです。記憶の出所（Memory provenance）では、ソースのない決定事項の価値が大幅に低下する理由を説明しています。
ログ（Transcripts）は、何が起こったかの生の記録です。これらは保管しておきますが、上記の2つの代わりとして扱ってはいけません。
このエッセイが重要なのは、多くのチームが2つ目のバケツの代わりに、3つ目のバケツを密かに使い続けてきたからです。
ステップ 2：決定したその瞬間に、1回で記録する
議論が終わったとき、何を却下し、なぜ却下したかをまだ覚えているうちに書き留めてください。決定したこと、却下したこと、理由、日付の4つを書き、そこで止めます。理由に証拠（インシデント、実行した測定、顧客の制約など）が含まれる場合は、それを明記してください。
罠は「スコープ」です。すべてを文書化しようとするチームは、結局何も文書化できません。あなたが書いているのはアーキテクチャの設計書ではありません。4ヶ月後に誰かに尋ねられ、自分が忘れてしまっていたときに欲しいと思う「1つの段落」を書いているのです。
これらを指示ファイルに書き込んでいる場合は、そこから移動させてください。18ヶ月分の根拠を抱えた常に読み込まれるファイルは、短いファイルよりも悪影響を及ぼします。今重要なルールが、過去の履歴の段落と競合してしまうからです。コーディングエージェントが実際に読んでいるものでは、そのファイルをスリムに保つべき理由を説明しており、エージェントがすでに与えた修正を失い続ける理由では、関連する失敗について説明しています。
ステップ 3：1つのエージェントだけでなく、すべてのエージェントが読めるようにする
この記事に登場するすべてのベンダーは、マシンごと、ワークスペースごと、コードからの再生成、あるいはエッセイにあるように意図的にまったく公開しないなど、異なるコンテナを持っています。1つのエージェントのメモリに存在する決定記録は、ツールを切り替えるたびに再作成する必要があり、ログから再作成されるため、不完全に再現されることになります。すべてのエージェントが読み取れる場所に配置し、エージェントをそこに接続してください。
MemoryLakeでの設定方法
ここでの共有メモリレイヤーの目的は明確です。モデルのコンテキストウィンドウ内でも、特定のベンダーのストレージ内でもない場所に、決定事項の「家」を提供することです。MemoryLakeはこれらの記録を保持し、MCPまたはAPIを介して、要求してきたエージェントに提供します。既存のツールが持つ独自のメモリ機能はそのまま維持されます。ここで紹介する仕組みがそれらを置き換えたり、干渉したりすることはありません。
ステップ 1：APIキーを作成する
キーを生成し、1分以内に最初のリクエストを送信できます。これはエージェントが共有記録を読み取るために使用する認証情報であるため、何かを移動する前に作成してください。
ステップ 2：最初の記憶をアップロードする
何度も説明するのにうんざりしている決定事項から始めましょう。通常、これらは短いリストになります。新しいコントリビューターが常に疑問に思うアーキテクチャの選択、特定のインシデントから生まれた規約、意図的に使用を避けているライブラリなどです。ドキュメント、画像、その他のファイルも同じ場所に保存されます。
ステップ 3：AIとエージェントを接続する
Claude、Codex、OpenClaw、およびその他のエージェントに、MCPまたはAPI経由でアクセスを許可します。「ここでの規約は何ですか」と尋ねるエージェントは、ウィンドウに残された情報から推測するのではなく、理由が添付された解決済みの決定事項を取得します。
実務において何が変わるのか
第一に、「なぜこの方法にしたのか」を調べる作業が不要になります。誰かが質問すると、エージェントが決定事項とその理由を取得し、会話がスムーズに進みます。その代替案であった、ログを読み返したり、モデルに自身の推論を思い出させたりする方法は、もともと時間がかかるものであり、現在では最も状況を把握している研究所の見解によって、明らかに信頼性の低い選択肢となっています。
第二に、決定の変更が可視化されます。決定記録には日付とステータスがあります。そのHTTPクライアントの使用をやめると、古いエントリは履歴にそのまま残って新しいものと同じように見えてしまうのではなく、「置き換えられた」状態になります。ログをどれだけ検索しても、この問題を解決することはできません。
第三に、ツールの移行コストが下がります。指示ファイルは新しいフォーマットに翻訳する必要があります。これは避けられないことであり、すべての移行ガイドに記載されています。しかし、決定記録はその必要がありません。なぜなら、もともと古いツールのフォーマットに依存していなかったからです。
第四に、そしてより静かに：永続的な推論がモデルの外部に存在する場合、プロセスがモデルの推論の解読可能性に依存しなくなります。ベンダーが「解読可能性が低下している」と伝えている年にとって、これは非常に優れた特性です。
永続的な決定記録のためのベストプラクティス
ドキュメント作成時ではなく、決定時に書く。 1ヶ月後に記録された決定は、ログから再現された決定であり、それはあなたが依存をやめようとしているものそのものです。
指示と決定事項を分けておく。 指示はコマンドであり、常に読み込まれるため短く保つ必要があります。決定事項は履歴であり、オンデマンドで取得されるため増えても問題ありません。これらを統合すると、両方の品質が低下します。
却下された選択肢を記録する。 最も価値のある記述は、「何をしなかったか」です。これはログには決して残らない記述でもあります。却下された案は議論された後に捨てられてしまうからです。
すべてに日付を入れ、置き換えを明記する。 日付のない記録は静かに陳腐化します。「この日付で置き換えられました」という情報は依然として有用ですが、ただ放置されているエントリは罠になります。
エージェントに見えない履歴を再構成させない。 決定事項が一度も書き留められていなかった場合は、その旨を伝え、もう一度議論を行い、今度は書き留めてください。
記録を単一のツールの外部に保持する。 すべてのベンダーのコンテナには、マシンごと、ワークスペースごと、アカウントごと、またはコードからの再生成といったスコープがあります。「ツールをまたいで、あなたのプロジェクトを永久にカバーするもの」は存在しません。
結論
「An Alien Mind」の見出しはスケーリングポリシーに関するものであり、その議論は今後何年も続くでしょう。あなたの今週の仕事を変える一文は、もっと小さなものです。OpenAI自身の評価によれば、Chain-of-Thought監視に依存する能力は段階的に低下しており、問題のトレースは最初に出荷された推論モデルから意図的にあなたの手から遠ざけられていました。
他の2つのベンダーも、それぞれの理由で同じ境界線を文書化しています。GitHubは未完成の作業が最終決定に見えないように中間のドラフトを保持し、Ampのサブエージェントは監視されたトレースではなくサマリーを返します。これらは欠陥ではありません。アーキテクチャがそのようになっているのです。
実質的な影響は、驚くべきことでも新しいことでもありません。最も状況を把握している当事者によって、今や書面で確認されたに過ぎません。あなたのプロジェクトがなぜそのような形になっているのかという記録は、人間が書き留めることを決意したものでなければなりません。決定したときにそれを書き、指示ファイルには含めず、すべてのエージェントが読める場所に保管してください。