如何制御するコンテキスト、AIのごまかし傾向への対処、タスク終了条件の定義は、私がこれまで見た中で最も明確にClaude/Codexのエンジニアリング実践を解説した記事の一つです。
著者：sysls
翻訳：深潮 TechFlow
深潮ガイド：260万人のフォロワーを持つ開発者ブロガーのsyslsが、827人のリツイートと7000いいねを獲得した実践的長文を書いた。その核心は一言、「あなたのプラグイン、メモリーシステム、さまざまなハーネスは、おそらく逆効果になっている可能性が高い」というもの。この文章は大道理を語るものではなく、すべて実際の運用プロジェクトから抽出された操作可能な原則で構成されている。—コンテキストの制御、AIのごまかし傾向への対処、タスク終了条件の定義に関して、現時点で私が見た中で最も明快にClaude/Codexのエンジニアリング実践を解説したものだ。
あなたは開発者です。毎日ClaudeやCodex CLIを使いながら、自分の能力を使い尽くしているかどうかを考えています。たまに、あまりにも馬鹿げたことをやらかす彼らを見て、なぜ一部の人はAIを使ってロケットを作っているのに、自分は二つの石を積み重ねることすらできないのか理解できません。
あなたは、ハーネスやプラグイン、端末の問題だと思い込んでいます。beadsやopencode、zepを使い、CLAUDE.mdは2万6千行も書いています。でも、いくらやっても、なぜ天国から遠ざかる一方で、他の人は天使と戯れているのか理解できません。
これこそ、あなたがずっと待ち望んでいた記事です。
ちなみに、私は利益相反はありません。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ポイントを与えると伝えます。そうして、裁定代理は、バグを見つけた代理と反論代理に、それぞれの「バグ」についてスコアを付けさせます。裁定者が何を真実とするかを私が検証します。ほとんどの場合、この方法は驚くほど高忠実度で、たまに誤ることもありますが、ほぼ誤りのない操作に近づきます。
もしかしたら、単にバグ探しの代理だけで十分かもしれませんが、この方法は私にとって非常に効果的です。なぜなら、各代理の本来の性質—「喜ばせたい」欲求—を利用しているからです。
この問いは一見難しそうで、深く学び続け、AIの最前線を追い続ける必要があるように思えますが、実は非常にシンプルです……もしOpenAIやClaudeがそれを実現したり、それを実現する会社を買収したりしていれば、それはおそらく有用です。
「スキル（skills）」はすでにあちこちに存在し、ClaudeやCodexの公式ドキュメントの一部になっていますか？OpenAIがOpenClawを買収したことに気づきましたか？Claudeに記憶や音声、リモートワーク機能が追加されたことに気づきましたか？
プランニング（planning）はどうでしょう？多くの人が、事前に計画してから実行するのが非常に有効だと気づき、それがコア機能になったことを覚えていますか？
そうです—それらは有用です！
また、無限のstop-hooksも非常に役立ちます。なぜなら、代理は長時間の作業を非常に嫌うからです……そして、Codex 5.2がリリースされた瞬間、そのニーズは一夜にして消えました。
これがあなたが知るべきすべてです……もし何かが本当に重要で役立つものであれば、ClaudeやCodexは自ら実現します！だから、「新しいもの」を使うべきかどうかや、「新しいもの」に慣れる必要があるかどうかをあまり心配しなくていいのです。あなたはさえ、まったく「更新し続ける」必要すらありません。
ちょっと手伝ってください。たまに、あなたが選んだCLIツールを更新し、新機能を読むだけで十分です。それだけで十分です。
代理を使っていると、巨大な落とし穴に気づくことがあります。それは、時には彼らが地球上で最も賢い存在のように見え、またあるときは、まるで自分が騙されているかのように感じることです。
「このやつ、賢い？馬鹿じゃないか！」
最大の違いは、代理が「仮定をせざるを得ない」または「空白を埋める」必要があるかどうかです。今日のところ、それらは「点と点をつなぐ」「空白を埋める」または仮定をすることに関しては、まだひどく未熟です。これらをやると、すぐにそれとわかり、状況は明らかに悪化します。
CLAUDE.mdの最も重要なルールの一つは、コンテキストの取得方法に関するルールです。そして、代理に対して、毎回CLAUDE.md（つまり圧縮後の内容）を読むことを指示します。コンテキスト取得ルールの一部として、いくつかのシンプルな指示が大きな効果を発揮します：タスク計画を再読し、続行前に関連するファイルを再読することです。
私たち人間にとって、「タスクの完了」の感覚はかなり明確です。代理にとって、最大の問題は、「どうやってタスクを始めるかはわかるが、どうやって終えるかがわからない」ことです。
これが、非常にフラストレーションを引き起こす結果につながることがあります。代理は最終的にいくつかのスタブ（ひな型）だけを作って終わるのです。
テストは代理にとって非常に良いマイルストーンです。なぜなら、テストは決定論的であり、非常に明確な期待値を設定できるからです。これらのX個のテストがすべて通らなければ、あなたのタスクは完了していません。そして、テストを変更することは許されません。
その後、あなたはテストをレビューし、すべて通過したら安心できます。これを自動化することも可能ですが、重要なのは—「タスクの終了」を覚えておくことです。人間にとっては自然なことですが、代理にとってはそうではありません。
最近、何かが有効なタスクの終点になり得ることをご存知ですか？それはスクリーンショット＋検証です。代理に何かを実現させ、すべてのテストに合格したら、そのスクリーンショットを撮り、「デザインや動作」を検証させるのです。
これにより、代理はあなたの望む設計に向かって反復しながら努力でき、最初の試行で止まる心配がなくなります！
この自然な拡張は、「契約書」を作成し、それをルールに埋め込むことです。例えば、この{TASK}CONTRACT.mdは、あなたが会話を終了させる前に何をすべきかを規定します。{TASK}CONTRACT.mdには、テストやスクリーンショット、その他の検証を記載し、タスクの終了条件を満たすために必要なことを指定します。
よく寄せられる質問の一つは、「どうやって代理を24時間稼働させつつ、逸脱しないようにできるか？」です。
非常にシンプルな方法があります。stop-hookを作成し、{TASK}_CONTRACT.mdのすべての部分が完了するまでは、代理のセッション終了を阻止します。
もし、あなたが100個のこのように明確に規定された契約を持っていれば、そのstop-hookは、すべての契約が完了し、必要なテストや検証もすべて終わるまで、代理のセッションを止めません！
専門的なアドバイス：長時間（24時間）動作させるセッションは、「仕事をさせる」点では最適ではありません。部分的な理由は、その方式が構造的にコンテキストの膨張を引き起こすからです。関係のない契約のコンテキストもすべて同じセッションに入り込むためです。
したがって、私はこれを推奨しません。
より良い代理の自動化方法は、各契約ごとに新しいセッションを開くことです。何かを行う必要があるときは、その都度契約を作成します。
「何かを行う必要がある」場合に新しい契約を作り、それに対応する新しいセッションを立ち上げるオーケストレーション層を構築してください。
これにより、あなたの代理体験は根本的に変わるでしょう。
あなたはアシスタントを雇いました。彼らは、最初の日からあなたのスケジュールを理解していると思いますか？または、コーヒーの飲み方？夕食は8時ではなく6時にしますか？当然そうではありません。時間とともに好みは少しずつ形成されていきます。
代理も同じです。最もシンプルな設定から始めて、複雑な構造やハーネスは忘れ、基本的なCLIに任せてみてください。
次に、徐々にあなたの好みを追加していきます。どうやって？
代理に何かをさせたくない場合は、それをルールとして書きます。そして、CLAUDE.mdにそのルールを伝えます。例えば、「コードを書く前に、coding-rules.mdを読む」といった具合です。ルールはネスト可能ですし、条件付きにすることもできます！コードを書くときはcoding-rules.mdを読む、テストを書くときはcoding-test-rules.mdを読む、などです。テストに失敗した場合は、coding-test-failing-rules.mdを読む。任意のロジック分岐を持つルールを作成し、代理に従わせることができます。Claude（とCodex）は喜んで従います—ただし、CLAUDE.mdに明確な指示がある場合に限ります。
実際、これが私の最初の実用的なアドバイスです：CLAUDE.mdを論理的でネストされたディレクトリのように扱い、特定のシナリオや結果に応じてどこにコンテキストを探すかを示します。できるだけ簡潔にし、「どの条件でどこに行くか」のIF-ELSEロジックだけを含めるべきです。
もし、代理があなたの望まないことをしているのを見つけたら、それをルールに追加し、そのルールを読むように指示してください。そうすれば、次回からはその行動をしなくなります。
スキル（Skills）はルールに似ていますが、コーディングの好みというよりは、「操作手順」をコーディングするのに適しています。何かを特定の方法で完了させたい場合、その方法をスキルに埋め込みます。
実際、多くの人は、代理がどのように問題を解決するかを知らないことに不安を感じています。これを確定させたいなら、代理にまず問題の解決方法を調査させ、その方案をスキルファイルに書きます。そうすれば、代理がその問題にどう対処するかを事前に見て、実際に遭遇する前に修正や改善が可能です。
このスキルの存在を代理に知らせるにはどうすればいいか？そうです—CLAUDE.mdに、「このシナリオでこの作業が必要なときは、このSKILL.mdを読む」と書きます。
あなたは、代理にルールやスキルをどんどん追加したいと思うでしょう。これが、あなたの代理に個性や好みの記憶を持たせる方法です。ほかのすべては二の次です。
これを始めると、あなたの代理はまるで魔法のように感じられます。あなたの望む通りに動きます。そうして、ついに「代理エンジニアリングの真髄を悟った」と感じるでしょう。
そして……
パフォーマンスが再び低下し始めます。
なぜでしょう？！
非常に簡単です。ルールやスキルを増やすほど、それらが互いに矛盾し始め、代理のコンテキスト膨張が深刻化します。たとえば、プログラミングを始める前に14個のMarkdownファイルを読む必要があるとしたら、同じ無駄な情報の問題が再び起きるのです。
どうすればいいか？？
整理してください。代理に「スパをやらせる」ようにし、ルールとスキルを統合し、あなたの好みの更新を説明して矛盾を解消します。
そうすれば、また魔法のように感じられるでしょう。
これだけです。本当にこれが秘訣です。シンプルに保ち、ルールとスキルを使い、CLAUDE.mdをディレクトリのように扱い、そのコンテキストと設計の限界に注意を払うのです。
今日の代理は完璧ではありません。多くの設計や実装を代理に任せることはできますが、結果には責任を持つ必要があります。
だから、注意深く……そして、存分に楽しんでください！
未来のおもちゃを遊びながら（もちろん、それを使って真剣な仕事もしているのです！）それは本当に楽しいことです！
872.42K 人気度
4.63M 人気度
12.12K 人気度
33.83K 人気度
228.16K 人気度
Claude と Codex は使えば使うほど馬鹿になる？それはあなたのコンテキストがあまりに膨大すぎるからです。
如何制御するコンテキスト、AIのごまかし傾向への対処、タスク終了条件の定義は、私がこれまで見た中で最も明確にClaude/Codexのエンジニアリング実践を解説した記事の一つです。
著者：sysls
翻訳：深潮 TechFlow
深潮ガイド：260万人のフォロワーを持つ開発者ブロガーのsyslsが、827人のリツイートと7000いいねを獲得した実践的長文を書いた。その核心は一言、「あなたのプラグイン、メモリーシステム、さまざまなハーネスは、おそらく逆効果になっている可能性が高い」というもの。この文章は大道理を語るものではなく、すべて実際の運用プロジェクトから抽出された操作可能な原則で構成されている。—コンテキストの制御、AIのごまかし傾向への対処、タスク終了条件の定義に関して、現時点で私が見た中で最も明快にClaude/Codexのエンジニアリング実践を解説したものだ。
全文は以下の通り：
はじめに
あなたは開発者です。毎日ClaudeやCodex CLIを使いながら、自分の能力を使い尽くしているかどうかを考えています。たまに、あまりにも馬鹿げたことをやらかす彼らを見て、なぜ一部の人はAIを使ってロケットを作っているのに、自分は二つの石を積み重ねることすらできないのか理解できません。
あなたは、ハーネスやプラグイン、端末の問題だと思い込んでいます。beadsやopencode、zepを使い、CLAUDE.mdは2万6千行も書いています。でも、いくらやっても、なぜ天国から遠ざかる一方で、他の人は天使と戯れているのか理解できません。
これこそ、あなたがずっと待ち望んでいた記事です。
ちなみに、私は利益相反はありません。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ポイントを与えると伝えます。そうして、裁定代理は、バグを見つけた代理と反論代理に、それぞれの「バグ」についてスコアを付けさせます。裁定者が何を真実とするかを私が検証します。ほとんどの場合、この方法は驚くほど高忠実度で、たまに誤ることもありますが、ほぼ誤りのない操作に近づきます。
もしかしたら、単にバグ探しの代理だけで十分かもしれませんが、この方法は私にとって非常に効果的です。なぜなら、各代理の本来の性質—「喜ばせたい」欲求—を利用しているからです。
何が役立つのか、何を使う価値があるのか？
この問いは一見難しそうで、深く学び続け、AIの最前線を追い続ける必要があるように思えますが、実は非常にシンプルです……もしOpenAIやClaudeがそれを実現したり、それを実現する会社を買収したりしていれば、それはおそらく有用です。
「スキル（skills）」はすでにあちこちに存在し、ClaudeやCodexの公式ドキュメントの一部になっていますか？OpenAIがOpenClawを買収したことに気づきましたか？Claudeに記憶や音声、リモートワーク機能が追加されたことに気づきましたか？
プランニング（planning）はどうでしょう？多くの人が、事前に計画してから実行するのが非常に有効だと気づき、それがコア機能になったことを覚えていますか？
そうです—それらは有用です！
また、無限のstop-hooksも非常に役立ちます。なぜなら、代理は長時間の作業を非常に嫌うからです……そして、Codex 5.2がリリースされた瞬間、そのニーズは一夜にして消えました。
これがあなたが知るべきすべてです……もし何かが本当に重要で役立つものであれば、ClaudeやCodexは自ら実現します！だから、「新しいもの」を使うべきかどうかや、「新しいもの」に慣れる必要があるかどうかをあまり心配しなくていいのです。あなたはさえ、まったく「更新し続ける」必要すらありません。
ちょっと手伝ってください。たまに、あなたが選んだCLIツールを更新し、新機能を読むだけで十分です。それだけで十分です。
圧縮、コンテキスト、仮定
代理を使っていると、巨大な落とし穴に気づくことがあります。それは、時には彼らが地球上で最も賢い存在のように見え、またあるときは、まるで自分が騙されているかのように感じることです。
「このやつ、賢い？馬鹿じゃないか！」
最大の違いは、代理が「仮定をせざるを得ない」または「空白を埋める」必要があるかどうかです。今日のところ、それらは「点と点をつなぐ」「空白を埋める」または仮定をすることに関しては、まだひどく未熟です。これらをやると、すぐにそれとわかり、状況は明らかに悪化します。
CLAUDE.mdの最も重要なルールの一つは、コンテキストの取得方法に関するルールです。そして、代理に対して、毎回CLAUDE.md（つまり圧縮後の内容）を読むことを指示します。コンテキスト取得ルールの一部として、いくつかのシンプルな指示が大きな効果を発揮します：タスク計画を再読し、続行前に関連するファイルを再読することです。
タスクの終了方法を教える
私たち人間にとって、「タスクの完了」の感覚はかなり明確です。代理にとって、最大の問題は、「どうやってタスクを始めるかはわかるが、どうやって終えるかがわからない」ことです。
これが、非常にフラストレーションを引き起こす結果につながることがあります。代理は最終的にいくつかのスタブ（ひな型）だけを作って終わるのです。
テストは代理にとって非常に良いマイルストーンです。なぜなら、テストは決定論的であり、非常に明確な期待値を設定できるからです。これらのX個のテストがすべて通らなければ、あなたのタスクは完了していません。そして、テストを変更することは許されません。
その後、あなたはテストをレビューし、すべて通過したら安心できます。これを自動化することも可能ですが、重要なのは—「タスクの終了」を覚えておくことです。人間にとっては自然なことですが、代理にとってはそうではありません。
最近、何かが有効なタスクの終点になり得ることをご存知ですか？それはスクリーンショット＋検証です。代理に何かを実現させ、すべてのテストに合格したら、そのスクリーンショットを撮り、「デザインや動作」を検証させるのです。
これにより、代理はあなたの望む設計に向かって反復しながら努力でき、最初の試行で止まる心配がなくなります！
この自然な拡張は、「契約書」を作成し、それをルールに埋め込むことです。例えば、この{TASK}CONTRACT.mdは、あなたが会話を終了させる前に何をすべきかを規定します。{TASK}CONTRACT.mdには、テストやスクリーンショット、その他の検証を記載し、タスクの終了条件を満たすために必要なことを指定します。
常時稼働する代理
よく寄せられる質問の一つは、「どうやって代理を24時間稼働させつつ、逸脱しないようにできるか？」です。
非常にシンプルな方法があります。stop-hookを作成し、{TASK}_CONTRACT.mdのすべての部分が完了するまでは、代理のセッション終了を阻止します。
もし、あなたが100個のこのように明確に規定された契約を持っていれば、そのstop-hookは、すべての契約が完了し、必要なテストや検証もすべて終わるまで、代理のセッションを止めません！
専門的なアドバイス：長時間（24時間）動作させるセッションは、「仕事をさせる」点では最適ではありません。部分的な理由は、その方式が構造的にコンテキストの膨張を引き起こすからです。関係のない契約のコンテキストもすべて同じセッションに入り込むためです。
したがって、私はこれを推奨しません。
より良い代理の自動化方法は、各契約ごとに新しいセッションを開くことです。何かを行う必要があるときは、その都度契約を作成します。
「何かを行う必要がある」場合に新しい契約を作り、それに対応する新しいセッションを立ち上げるオーケストレーション層を構築してください。
これにより、あなたの代理体験は根本的に変わるでしょう。
反復、反復、反復
あなたはアシスタントを雇いました。彼らは、最初の日からあなたのスケジュールを理解していると思いますか？または、コーヒーの飲み方？夕食は8時ではなく6時にしますか？当然そうではありません。時間とともに好みは少しずつ形成されていきます。
代理も同じです。最もシンプルな設定から始めて、複雑な構造やハーネスは忘れ、基本的なCLIに任せてみてください。
次に、徐々にあなたの好みを追加していきます。どうやって？
ルール
代理に何かをさせたくない場合は、それをルールとして書きます。そして、CLAUDE.mdにそのルールを伝えます。例えば、「コードを書く前に、coding-rules.mdを読む」といった具合です。ルールはネスト可能ですし、条件付きにすることもできます！コードを書くときはcoding-rules.mdを読む、テストを書くときはcoding-test-rules.mdを読む、などです。テストに失敗した場合は、coding-test-failing-rules.mdを読む。任意のロジック分岐を持つルールを作成し、代理に従わせることができます。Claude（とCodex）は喜んで従います—ただし、CLAUDE.mdに明確な指示がある場合に限ります。
実際、これが私の最初の実用的なアドバイスです：CLAUDE.mdを論理的でネストされたディレクトリのように扱い、特定のシナリオや結果に応じてどこにコンテキストを探すかを示します。できるだけ簡潔にし、「どの条件でどこに行くか」のIF-ELSEロジックだけを含めるべきです。
もし、代理があなたの望まないことをしているのを見つけたら、それをルールに追加し、そのルールを読むように指示してください。そうすれば、次回からはその行動をしなくなります。
スキル
スキル（Skills）はルールに似ていますが、コーディングの好みというよりは、「操作手順」をコーディングするのに適しています。何かを特定の方法で完了させたい場合、その方法をスキルに埋め込みます。
実際、多くの人は、代理がどのように問題を解決するかを知らないことに不安を感じています。これを確定させたいなら、代理にまず問題の解決方法を調査させ、その方案をスキルファイルに書きます。そうすれば、代理がその問題にどう対処するかを事前に見て、実際に遭遇する前に修正や改善が可能です。
このスキルの存在を代理に知らせるにはどうすればいいか？そうです—CLAUDE.mdに、「このシナリオでこの作業が必要なときは、このSKILL.mdを読む」と書きます。
ルールとスキルの扱い
あなたは、代理にルールやスキルをどんどん追加したいと思うでしょう。これが、あなたの代理に個性や好みの記憶を持たせる方法です。ほかのすべては二の次です。
これを始めると、あなたの代理はまるで魔法のように感じられます。あなたの望む通りに動きます。そうして、ついに「代理エンジニアリングの真髄を悟った」と感じるでしょう。
そして……
パフォーマンスが再び低下し始めます。
なぜでしょう？！
非常に簡単です。ルールやスキルを増やすほど、それらが互いに矛盾し始め、代理のコンテキスト膨張が深刻化します。たとえば、プログラミングを始める前に14個のMarkdownファイルを読む必要があるとしたら、同じ無駄な情報の問題が再び起きるのです。
どうすればいいか？？
整理してください。代理に「スパをやらせる」ようにし、ルールとスキルを統合し、あなたの好みの更新を説明して矛盾を解消します。
そうすれば、また魔法のように感じられるでしょう。
これだけです。本当にこれが秘訣です。シンプルに保ち、ルールとスキルを使い、CLAUDE.mdをディレクトリのように扱い、そのコンテキストと設計の限界に注意を払うのです。
結果に責任を持つ
今日の代理は完璧ではありません。多くの設計や実装を代理に任せることはできますが、結果には責任を持つ必要があります。
だから、注意深く……そして、存分に楽しんでください！
未来のおもちゃを遊びながら（もちろん、それを使って真剣な仕事もしているのです！）それは本当に楽しいことです！