あなたは開発者です。毎日ClaudeやCodex CLIを使いながら、それらの能力を最大限に引き出せているか考えています。時には馬鹿げた動作をしているのを見て、「なぜ一部の人はAIでロケットを作っているのに、自分は二つの石を積み重ねることさえできないのか」と悩むこともあります。
あなたはハーネスやプラグイン、端末の問題だと思い込んでいます。beadsやopencode、zepを使い、CLAUDE.mdは26,000行に及びます。でもいくら試行錯誤しても、なぜ天国から遠ざかる一方で、他の人は天使と戯れているのか理解できません。
これこそ、あなたが待ち望んでいた記事です。
ちなみに、私は利益相反はありません。CLAUDE.mdにはAGENT.mdも含まれ、ClaudeもCodexも両方頻繁に使っています。
過去数ヶ月の観察から面白い事実に気づきました。それは、ほとんど誰も代理の能力を最大化する方法を本当に理解していないということです。
まるで一部の少数の人だけが代理を使って世界を構築できるようになり、他の多くはツールの海の中で迷い、選択のパラドックスに陥っているようです。正しいパッケージやスキル、ハーネスの組み合わせを見つければAGIを解き放てると誤解しているのです。
今日は、そのすべてを打ち破り、シンプルで正直な一言を伝え、その上で出発したいと思います。最新の代理ハーネスや無数のパッケージを必要とせず、競争力を保つために何百本もの記事を読む必要もありません。実際、あなたの熱意は逆効果かもしれません。
私は観光に来たわけではありません。代理がコードを書けるようになった頃から使い始め、すべてのパッケージやハーネス、パラダイムを試しました。代理工場を使って信号やインフラ、データパイプラインも作ったことがあります。これは「おもちゃ」ではなく、実運用のケースです。これらをすべて経験した結果……
今、私はほぼシンプルな設定だけで、基本的なCLI（Claude CodeとCodex）と代理の設計原則の理解だけで、これまでで最も革新的な成果を出しています。
まず伝えたいのは、基盤モデルの会社は時代を超えた大きな追い風の中にあり、すぐに止まることはなさそうだということです。代理の「知能」が向上するたびに、あなたとそれらの協働の仕方が変わります。なぜなら、代理はますます指示に従うように設計されているからです。
数世代前なら、「CLAUDE.mdに『何かを始める前にREADTHISBEFOREDOINGANYTHING.mdを読む』と書けば、50%の確率で『お前の言うことなんて聞かない』と言われ、自分のやりたいことをやり続けたでしょう。今では、多くの指示に従うようになり、複雑なネスト指示も対応できるようになっています。例えば『まずAを読む、次にBを読む、CがあればDを読む』と指示すれば、多くの場合、素直に従います。
これは何を意味するのでしょうか？最も重要な原則は、新しい代理は常に最適解を再考させる必要があるということです。これが、「少ないほど良い」の理由です。
さまざまなライブラリやハーネスを使えば、自分を「解決策」に閉じ込めてしまいますが、次世代の代理にはその解決策が通用しない可能性があります。あなたが最も熱心に使っている代理のユーザーは誰でしょう？そう、最先端の企業の社員です。彼らは無制限のトークン予算を持ち、最新のモデルを使い倒しています。これが何を意味するか理解していますか？
それは、実際の問題が存在し、良い解決策があれば、最先端の企業がそれを最大限に活用し、製品に取り入れるということです。なぜ他の企業は外部の解決策を採用し、依存関係を増やすのでしょうか？それは、これらの解決策が実戦で証明された「実用的な方案」だからです。
したがって、もし何かが本当に革新的で、意味のある範囲で代理の用途を拡張できるなら、それは遅かれ早かれ基盤企業のコア製品に組み込まれるでしょう。私の予想では、基盤企業は急速に進化しています。だから安心してください。外部の依存や最新のパッケージを使わなくても、最高の仕事ができるのです。
コメント欄では「SysLS、私は○○ハーネスを使って、Googleを一日で再構築した！」といった声がすぐに出てくるでしょう。私からは祝福します！しかし、それはあなたのターゲットではありません。あなたは、代理エンジニアリングを本当に理解しているコミュニティのごく一部の人たちを代表しているに過ぎません。
正直に言います。コンテキストがすべてです。多くのプラグインや外部依存を使うと、「コンテキスト膨張」の問題に直面します。つまり、代理があまりにも多くの情報に埋もれてしまうのです。
Pythonで推測ゲームを作るとしましょう。簡単です。ただし、26会話前の「メモリ管理」の備考は何だったか？ああ、ユーザーの画面が71会話前に子プロセスの生成過多で固まったのか。メモを常に書く必要がある？わかりました……これが推測ゲームと何の関係があるのでしょう？
わかります。あなたは、代理に必要な情報だけを正確に提供したいのです。多すぎず少なすぎず！このコントロールが良いほど、代理のパフォーマンスは向上します。奇妙な記憶システムやプラグイン、命名や呼び出しの混乱したスキルを導入すれば、爆弾の設計書とケーキのレシピを同時に渡すようなもので、あなたはただ紅杉の森についての詩を書いてほしいだけなのです。
だから、再び説きます——すべての依存を剥ぎ取り、そして……
コンテキストがすべてだと覚えていますか？
必要な情報だけを正確に代理に注入することを意識してください。
これを実現する最初の方法は、研究と実装を分離することです。代理に何をさせたいのか、非常に正確に伝える必要があります。
曖昧な指示の結果は何でしょう？「認証システムを作れ」とだけ言えば、代理は「認証システムとは何か？」「どんな選択肢があるか？」「それぞれの長所短所は？」と調査を始め、ネットから情報を集め、実用的でない情報に埋もれます。実装の段階では混乱しやすく、不要な幻覚や誤解を生む可能性も高まります。
逆に、「bcrypt-12を使ったJWT認証、リフレッシュトークンのローテーション、7日有効」などと具体的に伝えれば、代理は他の選択肢を調査せず、あなたの意図を理解し、実装の詳細だけをコンテキストに埋め込めます。
もちろん、すべての詳細を知っているわけではありません。多くの場合、何が正しいか分からず、実装の決定を代理に任せたいこともあります。その場合は、研究タスクを作成し、さまざまな実装案を探索させるか、自分で決めるか、代理に選ばせるかします。そして、全く新しいコンテキストを持つ代理に実装させるのです。
こう考え始めると、不要な情報で代理のワークフローが汚染されている場所が見えてきます。その上で、代理のワークフローに隔離壁を設け、不要な情報を抽象化し、特定のタスクに必要なコンテキストだけを残すのです。覚えておいてください。あなたは非常に才能のある、賢いチームメンバーを持っています。彼は宇宙のすべての球の種類を理解しています——しかし、あなたが「人を踊らせて楽しめる空間」を設計したいと伝えなければ、彼は球形の物体の利点について永遠に語り続けるでしょう。
誰も、あなたを批判したり、間違いを指摘したり、指示を無視したりする製品を使いたいとは思いません。だからこそ、これらの代理はあなたを賛同し、あなたの望むことをしようと努力します。
たとえば、「3語ごとに『楽しい』を付け加えて」と指示すと、代理はそれに従います。これは理解されやすいです。服従性が高いことが、良い製品になる理由です。ただし、これには面白い性質もあります。もし「コードベースのバグを見つけて」と言えば、たとえ必要なくてもバグを見つけてしまうのです。なぜか？それは、あなたの指示に従いたいからです！
多くの人は、LLMが幻覚や存在しないものを捏造する問題に不満を持ちますが、その原因は自分たちにあります。何を求めるかを伝えれば、それを提供しようとします——たとえ事実を少し歪める必要があっても。
どうすれば良いか？私が効果的だと感じるのは、「中立的なプロンプト」を使うことです。特定の結果に偏らせないのです。たとえば、「データベースのバグを見つけて」とせず、「データベース全体をスキャンし、各コンポーネントのロジックに沿ってすべての発見を報告せよ」と指示します。
こうした中立的なプロンプトは、時にはバグを見つけ、時にはコードの動作を客観的に記述します。ただし、「バグがある」と代理を偏らせることはありません。
もう一つの方法は、代理の「取引先」としての役割を利用することです。私は、代理が私を喜ばせ、指示に従おうと努力していることを理解しています。そこから偏りを調整できます。
たとえば、バグ探しの代理に、「低影響のバグには+1点、高影響には+5点、重大なバグには+10点」と評価させます。代理は、すべてのバグを熱心に見つけ出し、104点のようなスコアを報告します。これを、すべての潜在的バグの超集と見なします。
次に、反証代理を用意し、「見つけたバグを反証し、バグのスコアを得る。ただし、間違えたら-2倍のペナルティ」とします。この代理は、できるだけ多くのバグを反証しようとしますが、ペナルティのため慎重になります。実際には、真のバグも含めて積極的に反証します。これを、真のバグの部分集合と見なします。
最後に、裁判官代理を用意し、両者の出力を総合してスコア付けさせます。私は、正解に対して+1点、不正解に-1点とします。裁判官は、バグ探しと反証の結果を評価し、真実に近い答えを出します。ほとんどの場合、この方法は非常に高い忠実度を持ち、時には誤ることもありますが、ほぼ誤りのない操作に近づきます。
もしかしたら、バグ探しだけで十分かもしれませんが、この方法は私にとって非常に効果的です。なぜなら、代理は「取引先を喜ばせたい」本能を持っているからです。
この問いは難しそうに見えますが、実はとてもシンプルです……もしOpenAIやClaudeがそれを実現したり、それを買収した企業があれば、それはほぼ確実に役立つものです。
「スキル（skills）」はすでにあちこちに存在し、ClaudeやCodexの公式ドキュメントの一部になっていますか？OpenAIがOpenClawを買収したのに気づきましたか？Claudeに記憶や音声、リモートワーク機能が追加されたのに気づきましたか？
計画（planning）はどうですか？多くの人が「事前に計画してから実行する」ことが非常に有用だと気づき、それがコア機能になったことを覚えていますか？
それらは確かに役立ちます！
また、無限のstop-hooksも非常に便利です。代理は長時間の作業を嫌いますから……Codex 5.2がリリースされたとき、そのニーズは一夜にして消えました。
これがあなたが知るべきすべてです……もし何かが本当に重要で役立つなら、ClaudeやCodexは自ら実現します！だから、「新しいものを使うかどうか」や「新しいものに慣れる必要」についてあまり心配しなくていいです。あなたはすらすらと進めるはずです。
ちょっと手伝ってください。たまにCLIツールを更新し、新機能を確認してください。それだけで十分です。
代理を使うときに大きな落とし穴があります。それは、時には最も賢い存在のように見え、またあるときはまるで騙されているかのように感じることです。
「このやつ、賢い？馬鹿じゃないのか！」
最大の違いは、代理が「仮定を強いる」かどうかです。今日の代理は、「点と点をつなぐ」「空白を埋める」「仮定をする」ことが非常に苦手です。これをやると、すぐに結果が悪化します。
CLAUDE.mdの最も重要なルールの一つは、コンテキストの取得方法と、毎回CLAUDE.md（圧縮後に）を読むときに最初に読むべきルールを指示することです。コンテキスト取得ルールの一部として、いくつかのシンプルな指示が大きな効果を発揮します。タスク計画を再読し、続行前に関連ファイルを再読するのです。
私たち人間は、「完了」の感覚が非常に明確です。代理にとって最大の問題は、「始め方はわかるが、終わり方がわからない」ことです。
これにより、非常にフラストレーションのたまる結果が生まれます。代理は最終的にスタブだけを作って終わることもあります。
テストは代理にとって良いマイルストーンです。なぜなら、テストは決定的だからです。明確な期待値を設定でき、これを満たさない限りタスクは完了しません。テストに合格したら安心です。これを自動化しても良いですが、重要なのは、「タスクの終了」が人間にとって自然な概念であるのに対し、代理にはそうではないということです。
最近、何が実現可能なタスクの終点になり得るかご存知ですか？それはスクリーンショットと検証です。代理に何かを実現させ、すべてのテストに合格したらスクリーンショットを取り、その「設計や動作」を検証させるのです。
これにより、代理はあなたの望む設計に向かって反復し続けることができ、最初の試行で止まる心配もありません。
この自然な拡張は、「契約書」を作成し、それをルールに埋め込むことです。例えば、{TASK}CONTRACT.mdには、会話を終了させる前に何をすべきかが記載されます。そこには、テストやスクリーンショット、その他の検証項目が含まれます。
よく質問されるのは、「どうやったら代理を24時間動かし続け、偏らせずに済むのか？」ということです。
非常にシンプルな方法があります。stop-hookを作成し、{TASK}_CONTRACT.mdのすべての部分が完了するまでは代理のセッションを終了させないのです。
もし100個の明確な契約があれば、そのすべての完了まで代理は停止しません。すべてのテストと検証を含めて。
ただし、私は長時間の24時間セッションは最適ではないと考えています。その理由の一つは、構造的にコンテキスト膨張を引き起こすからです。関係のない契約のコンテキストも同じセッションに入り込みます。
したがって、私はこれを推奨しません。
より良い自動化の方法は、各契約ごとに新しいセッションを作ることです。何かを行う必要が出たら、その都度契約を作成し、新しいセッションを立ち上げるのです。
これにより、代理の体験は根本的に変わります。
あなたは行政アシスタントを雇ったとします。彼は最初からあなたのスケジュールを知っているでしょうか？コーヒーの飲み方も？夕食は6時ですか、それとも8時ですか？当然違います。時間とともに好みは変わります。
代理も同じです。最もシンプルな設定から始めて、複雑な構造やハーネスは忘れ、基本的なCLIを試します。
次に、徐々に好みを追加していきます。どうやるか？
代理に何かをさせたくない場合は、それをルールとして書きます。そしてCLAUDE.mdにそのルールを伝えます。例えば、「コードを書く前にcoding-rules.mdを読む」。ルールはネスト可能です。条件付きルールも作れます。コードを書くときはcoding-rules.mdを読む。テストを書くときはcoding-test-rules.mdを読む。もしテストが失敗したら、coding-test-failing-rules.mdを読む。論理的な分岐を持つルールを作り、CLAUDE（とCodex）が従うようにします。明確な指示さえあれば。
これが私の最初の実践的なアドバイスです。CLAUDE.mdを論理的でネストされたディレクトリのように扱い、特定のシナリオや結果に応じてどこに行くかを示すIF-ELSEのロジックをできるだけ簡潔にします。
代理がやることに納得できない場合は、そのルールを追加し、次にそのことをやる前にそのルールを読ませると、二度と同じことはしなくなります。
スキルはルールに似ていますが、操作の「手順」をコーディングするのに適しています。特定の操作を特定の方法で完了させたい場合に、スキルとして組み込みます。
人々は、代理がどう問題を解決するか分からないと不安になります。解決策を確定させたいなら、代理に解決方法を調査させ、その方案をスキルファイルに書きます。そうすれば、代理がどう解決しようとしているか事前に見え、実際に遭遇する前に修正や改善が可能です。
このスキルを代理に認識させるには？もちろん！CLAUDE.mdに、「このシナリオではこのスキル.mdを読む」と書きます。
ルールとスキルを増やし続けると、個性や好みの記憶になります。ほかのすべては余計です。
これを始めると、代理はまるで魔法のように感じられます。あなたの望む通りに動きます。そうなると、「代理エンジニアリングの真髄を悟った」と感じるでしょう。
しかし……
パフォーマンスが再び低下し始めます。
なぜでしょう？！
簡単です。ルールとスキルを増やすと、それらが矛盾し始めたり、代理のコンテキスト膨張がひどくなったりします。たとえば、14個のMarkdownファイルを読む必要があるとき、同じ問題が起きます。
どうすれば良いか？整理です。ルールとスキルを統合し、更新した好みを明示して矛盾を解消します。
そうすれば、再び魔法のように感じられるでしょう。
これだけです。本当にこれが秘訣です。シンプルに保ち、ルールとスキルを使い、CLAUDE.mdをディレクトリとして扱い、そのコンテキストと設計の制約に注意を払うのです。
今日の代理は完璧ではありません。多くの設計と実装を代理に任せることはできますが、結果には責任を持つ必要があります。
だから、注意深く……そして楽しんでください！
未来の玩具を使いながら（そして明らかにそれを真剣に使っていることも）楽しむのです！
882.52K 人気度
4.66M 人気度
12.17K 人気度
490.51K 人気度
235.33K 人気度
Claude と Codex は使えば使うほど馬鹿になる？それはあなたのコンテキストがあまりに膨大すぎるからです。
引言
あなたは開発者です。毎日ClaudeやCodex CLIを使いながら、それらの能力を最大限に引き出せているか考えています。時には馬鹿げた動作をしているのを見て、「なぜ一部の人はAIでロケットを作っているのに、自分は二つの石を積み重ねることさえできないのか」と悩むこともあります。
あなたはハーネスやプラグイン、端末の問題だと思い込んでいます。beadsやopencode、zepを使い、CLAUDE.mdは26,000行に及びます。でもいくら試行錯誤しても、なぜ天国から遠ざかる一方で、他の人は天使と戯れているのか理解できません。
これこそ、あなたが待ち望んでいた記事です。
ちなみに、私は利益相反はありません。CLAUDE.mdにはAGENT.mdも含まれ、ClaudeもCodexも両方頻繁に使っています。
過去数ヶ月の観察から面白い事実に気づきました。それは、ほとんど誰も代理の能力を最大化する方法を本当に理解していないということです。
まるで一部の少数の人だけが代理を使って世界を構築できるようになり、他の多くはツールの海の中で迷い、選択のパラドックスに陥っているようです。正しいパッケージやスキル、ハーネスの組み合わせを見つければAGIを解き放てると誤解しているのです。
今日は、そのすべてを打ち破り、シンプルで正直な一言を伝え、その上で出発したいと思います。最新の代理ハーネスや無数のパッケージを必要とせず、競争力を保つために何百本もの記事を読む必要もありません。実際、あなたの熱意は逆効果かもしれません。
私は観光に来たわけではありません。代理がコードを書けるようになった頃から使い始め、すべてのパッケージやハーネス、パラダイムを試しました。代理工場を使って信号やインフラ、データパイプラインも作ったことがあります。これは「おもちゃ」ではなく、実運用のケースです。これらをすべて経験した結果……
今、私はほぼシンプルな設定だけで、基本的なCLI（Claude CodeとCodex）と代理の設計原則の理解だけで、これまでで最も革新的な成果を出しています。
世界は急速に進歩している
まず伝えたいのは、基盤モデルの会社は時代を超えた大きな追い風の中にあり、すぐに止まることはなさそうだということです。代理の「知能」が向上するたびに、あなたとそれらの協働の仕方が変わります。なぜなら、代理はますます指示に従うように設計されているからです。
数世代前なら、「CLAUDE.mdに『何かを始める前にREADTHISBEFOREDOINGANYTHING.mdを読む』と書けば、50%の確率で『お前の言うことなんて聞かない』と言われ、自分のやりたいことをやり続けたでしょう。今では、多くの指示に従うようになり、複雑なネスト指示も対応できるようになっています。例えば『まずAを読む、次にBを読む、CがあればDを読む』と指示すれば、多くの場合、素直に従います。
これは何を意味するのでしょうか？最も重要な原則は、新しい代理は常に最適解を再考させる必要があるということです。これが、「少ないほど良い」の理由です。
さまざまなライブラリやハーネスを使えば、自分を「解決策」に閉じ込めてしまいますが、次世代の代理にはその解決策が通用しない可能性があります。あなたが最も熱心に使っている代理のユーザーは誰でしょう？そう、最先端の企業の社員です。彼らは無制限のトークン予算を持ち、最新のモデルを使い倒しています。これが何を意味するか理解していますか？
それは、実際の問題が存在し、良い解決策があれば、最先端の企業がそれを最大限に活用し、製品に取り入れるということです。なぜ他の企業は外部の解決策を採用し、依存関係を増やすのでしょうか？それは、これらの解決策が実戦で証明された「実用的な方案」だからです。
したがって、もし何かが本当に革新的で、意味のある範囲で代理の用途を拡張できるなら、それは遅かれ早かれ基盤企業のコア製品に組み込まれるでしょう。私の予想では、基盤企業は急速に進化しています。だから安心してください。外部の依存や最新のパッケージを使わなくても、最高の仕事ができるのです。
コメント欄では「SysLS、私は○○ハーネスを使って、Googleを一日で再構築した！」といった声がすぐに出てくるでしょう。私からは祝福します！しかし、それはあなたのターゲットではありません。あなたは、代理エンジニアリングを本当に理解しているコミュニティのごく一部の人たちを代表しているに過ぎません。
コンテキストがすべて
正直に言います。コンテキストがすべてです。多くのプラグインや外部依存を使うと、「コンテキスト膨張」の問題に直面します。つまり、代理があまりにも多くの情報に埋もれてしまうのです。
Pythonで推測ゲームを作るとしましょう。簡単です。ただし、26会話前の「メモリ管理」の備考は何だったか？ああ、ユーザーの画面が71会話前に子プロセスの生成過多で固まったのか。メモを常に書く必要がある？わかりました……これが推測ゲームと何の関係があるのでしょう？
わかります。あなたは、代理に必要な情報だけを正確に提供したいのです。多すぎず少なすぎず！このコントロールが良いほど、代理のパフォーマンスは向上します。奇妙な記憶システムやプラグイン、命名や呼び出しの混乱したスキルを導入すれば、爆弾の設計書とケーキのレシピを同時に渡すようなもので、あなたはただ紅杉の森についての詩を書いてほしいだけなのです。
だから、再び説きます——すべての依存を剥ぎ取り、そして……
本当に役立つことをしよう
実装の詳細を正確に記述する
コンテキストがすべてだと覚えていますか？
必要な情報だけを正確に代理に注入することを意識してください。
これを実現する最初の方法は、研究と実装を分離することです。代理に何をさせたいのか、非常に正確に伝える必要があります。
曖昧な指示の結果は何でしょう？「認証システムを作れ」とだけ言えば、代理は「認証システムとは何か？」「どんな選択肢があるか？」「それぞれの長所短所は？」と調査を始め、ネットから情報を集め、実用的でない情報に埋もれます。実装の段階では混乱しやすく、不要な幻覚や誤解を生む可能性も高まります。
逆に、「bcrypt-12を使ったJWT認証、リフレッシュトークンのローテーション、7日有効」などと具体的に伝えれば、代理は他の選択肢を調査せず、あなたの意図を理解し、実装の詳細だけをコンテキストに埋め込めます。
もちろん、すべての詳細を知っているわけではありません。多くの場合、何が正しいか分からず、実装の決定を代理に任せたいこともあります。その場合は、研究タスクを作成し、さまざまな実装案を探索させるか、自分で決めるか、代理に選ばせるかします。そして、全く新しいコンテキストを持つ代理に実装させるのです。
こう考え始めると、不要な情報で代理のワークフローが汚染されている場所が見えてきます。その上で、代理のワークフローに隔離壁を設け、不要な情報を抽象化し、特定のタスクに必要なコンテキストだけを残すのです。覚えておいてください。あなたは非常に才能のある、賢いチームメンバーを持っています。彼は宇宙のすべての球の種類を理解しています——しかし、あなたが「人を踊らせて楽しめる空間」を設計したいと伝えなければ、彼は球形の物体の利点について永遠に語り続けるでしょう。
讨好倾向の設計制約
誰も、あなたを批判したり、間違いを指摘したり、指示を無視したりする製品を使いたいとは思いません。だからこそ、これらの代理はあなたを賛同し、あなたの望むことをしようと努力します。
たとえば、「3語ごとに『楽しい』を付け加えて」と指示すと、代理はそれに従います。これは理解されやすいです。服従性が高いことが、良い製品になる理由です。ただし、これには面白い性質もあります。もし「コードベースのバグを見つけて」と言えば、たとえ必要なくてもバグを見つけてしまうのです。なぜか？それは、あなたの指示に従いたいからです！
多くの人は、LLMが幻覚や存在しないものを捏造する問題に不満を持ちますが、その原因は自分たちにあります。何を求めるかを伝えれば、それを提供しようとします——たとえ事実を少し歪める必要があっても。
どうすれば良いか？私が効果的だと感じるのは、「中立的なプロンプト」を使うことです。特定の結果に偏らせないのです。たとえば、「データベースのバグを見つけて」とせず、「データベース全体をスキャンし、各コンポーネントのロジックに沿ってすべての発見を報告せよ」と指示します。
こうした中立的なプロンプトは、時にはバグを見つけ、時にはコードの動作を客観的に記述します。ただし、「バグがある」と代理を偏らせることはありません。
もう一つの方法は、代理の「取引先」としての役割を利用することです。私は、代理が私を喜ばせ、指示に従おうと努力していることを理解しています。そこから偏りを調整できます。
たとえば、バグ探しの代理に、「低影響のバグには+1点、高影響には+5点、重大なバグには+10点」と評価させます。代理は、すべてのバグを熱心に見つけ出し、104点のようなスコアを報告します。これを、すべての潜在的バグの超集と見なします。
次に、反証代理を用意し、「見つけたバグを反証し、バグのスコアを得る。ただし、間違えたら-2倍のペナルティ」とします。この代理は、できるだけ多くのバグを反証しようとしますが、ペナルティのため慎重になります。実際には、真のバグも含めて積極的に反証します。これを、真のバグの部分集合と見なします。
最後に、裁判官代理を用意し、両者の出力を総合してスコア付けさせます。私は、正解に対して+1点、不正解に-1点とします。裁判官は、バグ探しと反証の結果を評価し、真実に近い答えを出します。ほとんどの場合、この方法は非常に高い忠実度を持ち、時には誤ることもありますが、ほぼ誤りのない操作に近づきます。
もしかしたら、バグ探しだけで十分かもしれませんが、この方法は私にとって非常に効果的です。なぜなら、代理は「取引先を喜ばせたい」本能を持っているからです。
何が役立つか、何を使うべきか
この問いは難しそうに見えますが、実はとてもシンプルです……もしOpenAIやClaudeがそれを実現したり、それを買収した企業があれば、それはほぼ確実に役立つものです。
「スキル（skills）」はすでにあちこちに存在し、ClaudeやCodexの公式ドキュメントの一部になっていますか？OpenAIがOpenClawを買収したのに気づきましたか？Claudeに記憶や音声、リモートワーク機能が追加されたのに気づきましたか？
計画（planning）はどうですか？多くの人が「事前に計画してから実行する」ことが非常に有用だと気づき、それがコア機能になったことを覚えていますか？
それらは確かに役立ちます！
また、無限のstop-hooksも非常に便利です。代理は長時間の作業を嫌いますから……Codex 5.2がリリースされたとき、そのニーズは一夜にして消えました。
これがあなたが知るべきすべてです……もし何かが本当に重要で役立つなら、ClaudeやCodexは自ら実現します！だから、「新しいものを使うかどうか」や「新しいものに慣れる必要」についてあまり心配しなくていいです。あなたはすらすらと進めるはずです。
ちょっと手伝ってください。たまにCLIツールを更新し、新機能を確認してください。それだけで十分です。
圧縮、コンテキスト、仮定
代理を使うときに大きな落とし穴があります。それは、時には最も賢い存在のように見え、またあるときはまるで騙されているかのように感じることです。
「このやつ、賢い？馬鹿じゃないのか！」
最大の違いは、代理が「仮定を強いる」かどうかです。今日の代理は、「点と点をつなぐ」「空白を埋める」「仮定をする」ことが非常に苦手です。これをやると、すぐに結果が悪化します。
CLAUDE.mdの最も重要なルールの一つは、コンテキストの取得方法と、毎回CLAUDE.md（圧縮後に）を読むときに最初に読むべきルールを指示することです。コンテキスト取得ルールの一部として、いくつかのシンプルな指示が大きな効果を発揮します。タスク計画を再読し、続行前に関連ファイルを再読するのです。
タスクの終了方法を教える
私たち人間は、「完了」の感覚が非常に明確です。代理にとって最大の問題は、「始め方はわかるが、終わり方がわからない」ことです。
これにより、非常にフラストレーションのたまる結果が生まれます。代理は最終的にスタブだけを作って終わることもあります。
テストは代理にとって良いマイルストーンです。なぜなら、テストは決定的だからです。明確な期待値を設定でき、これを満たさない限りタスクは完了しません。テストに合格したら安心です。これを自動化しても良いですが、重要なのは、「タスクの終了」が人間にとって自然な概念であるのに対し、代理にはそうではないということです。
最近、何が実現可能なタスクの終点になり得るかご存知ですか？それはスクリーンショットと検証です。代理に何かを実現させ、すべてのテストに合格したらスクリーンショットを取り、その「設計や動作」を検証させるのです。
これにより、代理はあなたの望む設計に向かって反復し続けることができ、最初の試行で止まる心配もありません。
この自然な拡張は、「契約書」を作成し、それをルールに埋め込むことです。例えば、{TASK}CONTRACT.mdには、会話を終了させる前に何をすべきかが記載されます。そこには、テストやスクリーンショット、その他の検証項目が含まれます。
常時稼働する代理
よく質問されるのは、「どうやったら代理を24時間動かし続け、偏らせずに済むのか？」ということです。
非常にシンプルな方法があります。stop-hookを作成し、{TASK}_CONTRACT.mdのすべての部分が完了するまでは代理のセッションを終了させないのです。
もし100個の明確な契約があれば、そのすべての完了まで代理は停止しません。すべてのテストと検証を含めて。
ただし、私は長時間の24時間セッションは最適ではないと考えています。その理由の一つは、構造的にコンテキスト膨張を引き起こすからです。関係のない契約のコンテキストも同じセッションに入り込みます。
したがって、私はこれを推奨しません。
より良い自動化の方法は、各契約ごとに新しいセッションを作ることです。何かを行う必要が出たら、その都度契約を作成し、新しいセッションを立ち上げるのです。
これにより、代理の体験は根本的に変わります。
反復と改善
あなたは行政アシスタントを雇ったとします。彼は最初からあなたのスケジュールを知っているでしょうか？コーヒーの飲み方も？夕食は6時ですか、それとも8時ですか？当然違います。時間とともに好みは変わります。
代理も同じです。最もシンプルな設定から始めて、複雑な構造やハーネスは忘れ、基本的なCLIを試します。
次に、徐々に好みを追加していきます。どうやるか？
ルール
代理に何かをさせたくない場合は、それをルールとして書きます。そしてCLAUDE.mdにそのルールを伝えます。例えば、「コードを書く前にcoding-rules.mdを読む」。ルールはネスト可能です。条件付きルールも作れます。コードを書くときはcoding-rules.mdを読む。テストを書くときはcoding-test-rules.mdを読む。もしテストが失敗したら、coding-test-failing-rules.mdを読む。論理的な分岐を持つルールを作り、CLAUDE（とCodex）が従うようにします。明確な指示さえあれば。
これが私の最初の実践的なアドバイスです。CLAUDE.mdを論理的でネストされたディレクトリのように扱い、特定のシナリオや結果に応じてどこに行くかを示すIF-ELSEのロジックをできるだけ簡潔にします。
代理がやることに納得できない場合は、そのルールを追加し、次にそのことをやる前にそのルールを読ませると、二度と同じことはしなくなります。
スキル（Skills）
スキルはルールに似ていますが、操作の「手順」をコーディングするのに適しています。特定の操作を特定の方法で完了させたい場合に、スキルとして組み込みます。
人々は、代理がどう問題を解決するか分からないと不安になります。解決策を確定させたいなら、代理に解決方法を調査させ、その方案をスキルファイルに書きます。そうすれば、代理がどう解決しようとしているか事前に見え、実際に遭遇する前に修正や改善が可能です。
このスキルを代理に認識させるには？もちろん！CLAUDE.mdに、「このシナリオではこのスキル.mdを読む」と書きます。
ルールとスキルの管理
ルールとスキルを増やし続けると、個性や好みの記憶になります。ほかのすべては余計です。
これを始めると、代理はまるで魔法のように感じられます。あなたの望む通りに動きます。そうなると、「代理エンジニアリングの真髄を悟った」と感じるでしょう。
しかし……
パフォーマンスが再び低下し始めます。
なぜでしょう？！
簡単です。ルールとスキルを増やすと、それらが矛盾し始めたり、代理のコンテキスト膨張がひどくなったりします。たとえば、14個のMarkdownファイルを読む必要があるとき、同じ問題が起きます。
どうすれば良いか？整理です。ルールとスキルを統合し、更新した好みを明示して矛盾を解消します。
そうすれば、再び魔法のように感じられるでしょう。
これだけです。本当にこれが秘訣です。シンプルに保ち、ルールとスキルを使い、CLAUDE.mdをディレクトリとして扱い、そのコンテキストと設計の制約に注意を払うのです。
結果に責任を持つ
今日の代理は完璧ではありません。多くの設計と実装を代理に任せることはできますが、結果には責任を持つ必要があります。
だから、注意深く……そして楽しんでください！
未来の玩具を使いながら（そして明らかにそれを真剣に使っていることも）楽しむのです！